Не согласен в целом. Всё зависит от архитектуры — если она сильно завязана на схему данных, то вы правы. Если она, как говорится, storage agnostic, то выбор конкретной системы хранения не повлияет на функциональность. Не знаю как сейчас обстоят дела в той же 1С, но помнится были времена, когда она предлагала несколько вариантов хранения данных на выбор.
Качество базы данных — это не СУБД, а качество логической структуры (ER диаграммы). Если структура хорошая, то её можно для начала хоть на SQLite реализовать, а потом переносить на другие субд, и все обойдется относительно небольшими переделками. А если структура базы плохая — такую ERP ничего не спасет.
Мне кажется, что во втором списке «бизнес любит» все пункты ошибочные. :))
Если бы бизнес любил — он бы платил за пункты именно из второго списка. Но это не так.
Успешные проекты есть. Действительно успешные. Их не много, но есть. Некоторые из этих успешных проектов даже с использованием 1С. :)))
А то, что успешных проектов мало — так руководство в этом не очень заинтересовано.
Тут ведь дело не в том, чтобы рассуждать — чего мы хотим. А в том, чтобы действительно этого хотеть и действовать в этом направлении. Если директор «суррогат» — он будет много говорить о вещах из списка 2, но делать вещи из списка 1. И все остальные сотрудники тоже.
Так что не надо рассуждать о мифическом «бизнесе». Есть вполне реальные люди, с именами и фамилиями, которые принимают решения. И они в большинстве своем хотят вещей из списка 1, так как только в этом случае будут находиться в зоне комфорта.
Чем сложнее задача, тем больший кайф в ней разобраться и найти ее решение.
Кстати, это очень неплохая мотивация. По крайней мере для меня.
Если будет две работы с примерно одинаковой зарплатой и условиями, но на одной сложные задачи, а на другой рутинные — выберу сложные.
От работы надо ловить кайф, ведь это как минимум 1/3 всей твоей жизни.
Наиболее правильный подход, по моему мнению — изначально считать, что ноут сотрудника не защищен. И исходить из этого. Всё корпоративное ПО и конфиденциальная инфа — не серверах.
А ты прости меня кто такой, чтобы МНЕ советы давать?
Я — специалист, который знает, почему прибыль / убытки находятся в капитале (пассиве) баланса.
А ты — человек, который взялся писать статью об учете, при этом утверждая, что
«убытки от кражи» это актив
Более того, когда указали на ошибки и дали ссылки на книги и стандарты, вместо того, чтобы их прочитать и повысить свой уровень знаний, начал переходить на личности, и доказывать, что все вокруг в гуано, а один ты — д’Артанья́н.
International GAAP? Я вот прям вижу как человек которому нужно автоматизировать финансы фирмочки с десятком «батискафов» или оффшорного ресселинг-хостера с полсотней серверов, или маленький интернет-магазин на пару сотен продаж в месяц (не важно будет это программист или владелец бизнеса) — берет в библиотеке англоязычный трехтомник с рекомендациями по организации учета в рамках МСФО… вот прям так и вижу, ага.
Так я об этом чуть выше и написал:
А всем остальным и картинки хватит — многа букаф все равно не осилят.
Только вы немного не так расставили акценты. Если профессионалу, далекому от учета, надо «автоматизировать финансы фирмочки с десятком «батискафов» или оффшорного ресселинг-хостера с полсотней серверов, или маленький интернет-магазин на пару сотен продаж в месяц» — то он:
1. возьмет учетный софт, который написали люди, которые разбираются в учете.
или
2. прочитает, к примеру, «Концептуальные основы финансовой
отчетности» на русском языке (регистрация на том ресурсе бесплатная), почитает еще некоторые стандарты (если читать для небольших фирм — там чуть больше 200 страниц — не очень много) — и реализует сам модуль фин учета.
А вот если это будет человек «с пониженным уровнем профессионализма», он…
Не буду детализировать, но «кварковые проводки» и «убытки от кражи — актив» очень хорошо вписываются именно в этот вариант.
Еще раз повторю свой совет, который я дал в первом комментарии: Разберитесь для начала, что такое фин отчетность, для чего она нужна, из чего состоит и какие к ней существуют требования. У вас большие пробелы в базовых знаниях в области учета и отчетности.
А зачем её писать? :)))
Если человек умеет и любит читать — он и так сможет почитать книжки по учету и отчетности, по крайней мере несколько ссылок я оставил.
А всем остальным и картинки хватит — многа букаф все равно не осилят. :)))
Я рад, что картинка вас рассмешила. А то вы столько анекдотов написали, а мне и ответить нечем. Придумать что-то из серии «убыток от кражи — актив» не так то легко… :)))
Что такое накопленная амортизация? Это же чистый хак, не более. По сути это фонд амортизации, на который мы накидываем амортизацию, чисто чтобы не делать переоценку балансовой стоимости, но для удобства, чтобы видеть реальную картину (а именно стоимость основных) мы пишем его в активах.
А можно поподробнее? Что такое (в вашей интерпретации) фонд амортизации, амортизация, стоимость основных, переоценка балансовой стоимости… Хочется обогатиться новыми «академическими» терминами.
Вот прям оба счета пассив?
или может у нас активно-пассивный счет который в отчете хочется вывести только один раз, поэтому засунем в ту сторону
:)))
Таки да. Вот прям оба счета — пассив, раздел капитал.
Даже если мы вместо одного активно — пассивного счета «прибыль / убытки» сделаем два счета — оба эти счета будут в пассиве баланса.
Я об этом и говорю — пока не понимаешь экономического смысла разных статей отчетности, все рассуждения об учете, двойной записи и т.п. — не более чем карго культ.
Активы <> активный счет. Например, накопленная амортизация это классический пример пассивного счета, который расположен в активах баланса.
Еще раз советую почитать книжки про учет и отчетность. Если нет желания читать стандарты и комментарии к ним четверки — почитайте того же Баффета.
Зазубривают только те, кто не понимает базовых понятий в области учета и отчетности. И, если уж на то пошло, прибыль / убытки — это пассив баланса.
Погуглите еще термин «карго культ». Именно этим вы сейчас страдаете. Назначение фин учета — получение фин отчетности. Всё. Фин счета, двойная запись, проводки и т.п. — не более чем средство получения отчетности. И без понимания того, какой именно должна быть отчетность, не будет понимания, каким должен быть учет.
А у вас, судя по фразам
Например «убытки от кражи» это актив.
просто напросто нет понимания того, что такое фин отчетность, зачем она нужна и, соответственно, какой она должна быть.
Почему это я сторонник неакадемической терминологии? Например, академический термин «кварковые проводки» мне очень нравится… :)))
Я рад, что вы умеете строить корреспонденции счетов. Когда реализуете свой блок фин учёта с аналитическими измерениями и корреспонденцией, напишите ещё одну статью. Всем будет интересно. :)))
Чушь. Представьте себе что вы каким-то образом сохранили только одну вашу «кварковую» проводку (часть проводки где один счет). Представили? Нет? А зачем мне тогда представлять в моей системе то, что вы не хотите представлять в вашей?
См. статью — все проводки одного документа должны проводиться в одной транзакции.
Потому что в среде финансистов / разработчиков учетного софта минимальной (атомарной) операцией принято считать как раз проводку. Именно проводка обязательно должна учитываться в одной транзакции, а не «все проводки одного документа должны проводиться в одной транзакции». Это — вопрос знания профессиональной терминологии.
Кстати, в большинстве систем проводки одного документа мало того, что учитываются не в одной транзакции, так они еще могут учитываться разными датами :))) Типичный пример — себестоимость продаж по инвойсу.
В том то и дело, что «ядро» фин учета должно корректно работать с самыми разными документами, которые генерируются в разных модулях, написанных разными программистами. Ну и, например, есть еще проводки, учитываемые из журналов.
То, что вы собираетесь вводить дополнительное понятие «операция» (транзакция), которая объединяет в себе несколько проводок, которые должны учитываться одновременно и представляют из себя одно целое — как раз и показывает, что проводка, состоящая только из одного дебета и одного кредита — неудобна.
Намного проще сразу сказать, что проводка = транзакция, которая состоит из некоторого множества строк главной книги, которые всегда учитываются как одно целое (в одной транзакции БД). И не надо придумывать дополнительных сущностей.
«Кварковые» проводки — крутой термин, надо будет запомнить. :)))
По поводу создания отдельного «транзитного» фин счета, сальдо по которому всегда равно нулю (просто для того, чтобы смотреть, какие суммы меняли)… Спорить не буду — если очень хочется создавать кучу транзитных счетов с сомнительными целями, то почему бы и нет? :)))
Действительно, крайне мало людей способны грамотно продумать архитектуру, в том числе и правильно построить корреспонденцию. Поэтому регулярно городят лишние надстройки, без которых можно обойтись если хорошо понимать суть процессов, но проще ведь велосипед изобрести.
Ну и да, классическая структура баланса подразумевает что у нас только одна, заранее зафиксированная иерархия счетов, одна валюта и т.п. Вместе с тем компьютерная реализация дает много большую гибкость. Собственно ее то я и хочу реализовать. Отчасти ради этих обсуждений и затевалась статья).
Про велосипеды очень хорошо сказано. Я именно поэтому и советую посмотреть, как это всё уже реализовано. И сап для новой главной книги, и микрософт для 2013 навика реализовали фактически одну и ту же модель хранения данных об аналитических разрезах фин проводок. Поэтому высока вероятность, что именно такая модель близка к оптимальной (у оебса эта же модель была изначально, и, подозреваю, именно с оебса идею и скопировали).
Почитайте о том, как это в навике сделали и почему именно так сделали. А потом начинайте изобретать свои велосипеды.
Объяснить очень легко. :)))
Двойная запись выполняет те же функции, что и ограничения целостности данных (Constraints) в базах данных ну или бекапы для сисадминов. До тех пор, пока учет (работа с БД, работа сервера) ведется без ошибок (сбоев), без двойной записи (Constraints, бекапов) можно обойтись. Но, как говорится, все люди делятся на тех, кто не делает бекапов, и на тех, кто уже делает. :)))
Плохой дизайн и усложнение логики…
Странно слышать от вас такие обвинения. :)))
Давайте я еще раз объясню, как именно хранится информация о фин проводках в нормальных ERP системах. Если отбросить все накопившиеся «какашки мамонтов», то в основной таблице фин проводок есть такие поля:
— номер записи — целое (автоинкремент)
— номер транзакции (проводки) — целое
— дата учета
— код набора аналитик — целое (фин счет — одна из аналитик, когда номер именно фин счета выделяют в отдельное поле, то это скорее унаследованный код, хотя для некоторых ситуаций и полезно)
— признак реверсивности (красное сторно) — булево
— сумма операции в функциональной валюте — decimal
Также есть два ограничения:
1. Дата учета должна быть одной и той же для всех записей с одинаковым номером транзакции (проводки).
2. Сумма поля «сумма операции в функциональной валюте» (на английском понятнее — там это sum and amount — разные слова))) всех записей с одним и тем же номером транзакции (проводки) должна быть равна нулю.
Номер записи обычно идет без пропусков, это облегчает аудит, но само по себе отсутствие пропусков не обязательно, как и само поле «номер записи» :))) Но с этим полем работать намного удобнее.
И это ВСЁ, что нужно собственно для учета. Заметьте, вообще нет никаких дебетов / кредитов, деления счетов на активные / пассивные или на балансовые счета / счета прибылей и убытков. Очень простая логика, которую легко реализовать.
Разумеется, в реальных системах обычно есть дополнительные поля:
— справочная информация (номер и дата документа, описание проводки и т.п.)
— техническая информация (из какого модуля «пришла» проводка а также ключи, помогающие связать между собой записи в главной книге и прочих модулях)
— поля, упрощающие ряд расчетов (денормализация). например, сумма дебита и сумма кредита — их можно вычислить по другим полям — при «признак реверсивности» = ложь если поле сумма больше нуля то дебет, если меньше нуля то кредит; при «признак реверсивности» = истина если поле сумма больше нуля то кредит, если меньше нуля то дебет, но для многих задач удобнее хранить в явном виде.
А теперь сравните с теми ограничениями, которые надо реализовать в вашем варианте дизайна. :)))
Например, подробнее разберем мой пример с переброской денег с еврового счета на долларовый (конвертация денег в другую валюту).
Предположим, что функциональная валюта у нас — евро. Для учета мы используем курсы центробанка, а банк для конвертации — спотовый курс. И эти курсы, как правило, разные.
Как я уже сказал, банк конвертировал 1000 евро в 1100 долларов. А курс центробанка для 1100 долларов — 1005 евро.
То есть итог на фин счетах должен выглядеть следующим образом:
— Банк счет (евро): -1000 (-1000 евро)
— Банк счет (доллар): +1005 (+1100 долларов)
— Реализованная прибыль от курсовых разниц: -5
Если мы допускаем в системе сложные проводки, то можем прямо в таком виде и записать проводку в главную книгу и успокоиться.
А вот если нам надо разбить операции «попарно» — все сильно усложняется.
Например, мы учитываем операцию следующим образом:
Проводка 1
— Банк счет (евро): -1000 (-1000 евро)
— Банк счет (доллар): +1000 (+1100 долларов)
Проводка 2
— Банк счет (доллар): +5 (+0 долларов)
— Реализованная прибыль от курсовых разниц: -5
Итоговый результат тот же самый, но у нас вылазит сразу ДВЕ проблемы.
Проблема 1.
Мы в первой проводке учитываем сумму в валюте (доллары) не по курсу на дату выполнения операции. Это, в свою очередь, приводит к целому букету проблем, начиная от того, что сложнее выполнять банальные проверки корректности пересчета сумм из валюты операции в функциональную валюту и заканчивая СУЩЕСТВЕННЫМ усложнением логики различных расчетов. Ведь мы не можем для расчета суммы в функциональной валюте везде вызывать одну простую процедуру, которая просто находит курс на дату учета операции и умножает сумму в валюте операции на этот курс.
Проблема 2.
Нарушаются базовые принципы фин учета. Фин проводки являются ОЧЕНЬ близкими аналогами ACID транзакций баз данных (собственно говоря, при начале разработки баз данных фин учет был одной из основных сфер применения). То есть, каждая фин проводка должна преобразовывать фин учет из одного корректного состояния в другое корректное состояние. А теперь представим, что по какой-то причине мы зафиксировали в базе только одну из этих проводок. В таком случае мы получим некорректные данные в отчетности. То есть нам надо вводить дополнительную группировку проводок в «транзакции», что в свою очередь усложняет систему.
И самое главное, что подобное деление на простые проводки не дает никакого реального выигрыша. Многие теоретики любят рассуждать о ценности отчетов на основе корреспонденции счетов, но на практике необходимость в этой информации возникает КРАЙНЕ редко.
Вернее не совсем так. Необходимость в данных о «корреспонденции» проводок возникает регулярно, но корреспонденция в том виде, в каком она обычно реализована, не дает нужной детализации. А реализовать её на нужном уровне весьма сложно. Например, у сапа есть очень полезная функциональность — Document Splitting, которая и делает нужные «связки» (об этой функциональности можно почитать здесь и, например, здесь). Но это, мягко говоря, «немножко сложнее» той корреспонденции, которая есть в той же 1С. :)
Mendel, один совет — посмотрите, как реализован модуль главной книги в любой из нормальных ERP систем (не 1С) — навик, аксапта, оебс, сап…
И подумайте, почему именно так.
То, как вы описываете проводки — не очень корректно и неудобно в реализации.
Достаточно часто надо делать проводки с тремя, четырьмя и более фин счетами.
Например, вы перебрасываете 1000 евро с еврового счета на долларовый и приходит 1100 долларов. Попробуйте записать это проводками, и поймете, почему удобны проводки с тремя и более фин счетами.
Ну и остальные ваши измышления, например записывать в каждой проводке текущее сальдо по счету :)))
Технически, вроде бы да, можно. Но — зачем? Вы про материализованные (индексированные) представления слышали?
Просто если человек, не разбирающийся в бух учете, начнет изучать тему по этой статье — ему будет сложно потом разбираться с реальными задачами в этой области.
Честно, очень смешные аргументы. Особенно «усложняем логику, в том числе логику контроля, логику отображения и т.п. Значительно усложняем, фактически в два раза усложняем» :)))
Возможно, вы сами до конца не понимаете предназначение именно фин счетов (синтетический учет).
А пруфы будут?
Качество базы данных — это не СУБД, а качество логической структуры (ER диаграммы). Если структура хорошая, то её можно для начала хоть на SQLite реализовать, а потом переносить на другие субд, и все обойдется относительно небольшими переделками. А если структура базы плохая — такую ERP ничего не спасет.
habrastorage.org/storage1/f3aa6ba3/3b986cea/836df5db/596c49be.jpg
И удивляются — почему не летают? :)))
Если бы бизнес любил — он бы платил за пункты именно из второго списка. Но это не так.
Успешные проекты есть. Действительно успешные. Их не много, но есть. Некоторые из этих успешных проектов даже с использованием 1С. :)))
А то, что успешных проектов мало — так руководство в этом не очень заинтересовано.
Тут ведь дело не в том, чтобы рассуждать — чего мы хотим. А в том, чтобы действительно этого хотеть и действовать в этом направлении. Если директор «суррогат» — он будет много говорить о вещах из списка 2, но делать вещи из списка 1. И все остальные сотрудники тоже.
Так что не надо рассуждать о мифическом «бизнесе». Есть вполне реальные люди, с именами и фамилиями, которые принимают решения. И они в большинстве своем хотят вещей из списка 1, так как только в этом случае будут находиться в зоне комфорта.
Кстати, это очень неплохая мотивация. По крайней мере для меня.
Если будет две работы с примерно одинаковой зарплатой и условиями, но на одной сложные задачи, а на другой рутинные — выберу сложные.
От работы надо ловить кайф, ведь это как минимум 1/3 всей твоей жизни.
Я — специалист, который знает, почему прибыль / убытки находятся в капитале (пассиве) баланса.
А ты — человек, который взялся писать статью об учете, при этом утверждая, что
Более того, когда указали на ошибки и дали ссылки на книги и стандарты, вместо того, чтобы их прочитать и повысить свой уровень знаний, начал переходить на личности, и доказывать, что все вокруг в гуано, а один ты — д’Артанья́н.
Для того, чтобы осилить — нужно желание учиться.
«Конечно, необходимо признать и существование того, что старожилы называют ламерством, то есть навязчивое желание малообразованных неофитов навязать свою точку зрения на проблему, с которой тот недавно познакомился «на лету». »
— Олег Татарников, 1997г., Компьютерра.
«Есть 2 типа людей: чайники и ламеры.
Из первых вырастают гуру, а вторые так и остаются ламерами.»
— Анонимус.
Ламер (от пиндосск. lame — хромой, калечный; от исп. lamér — лизать, (реже) ягненок, что тоже как бы намекает; в переводе с недословного жаргона — унылый, или также — «криворукий» (комп. сленг)) — человек, абсолютно некомпетентный в той или иной сфере, обычно в компьютерной, но твёрдо уверенный в обратном и не предпринимающий абсолютно никаких попыток что-нибудь узнать.
Так я об этом чуть выше и написал:
Только вы немного не так расставили акценты. Если профессионалу, далекому от учета, надо «автоматизировать финансы фирмочки с десятком «батискафов» или оффшорного ресселинг-хостера с полсотней серверов, или маленький интернет-магазин на пару сотен продаж в месяц» — то он:
1. возьмет учетный софт, который написали люди, которые разбираются в учете.
или
2. прочитает, к примеру, «Концептуальные основы финансовой
отчетности» на русском языке (регистрация на том ресурсе бесплатная), почитает еще некоторые стандарты (если читать для небольших фирм — там чуть больше 200 страниц — не очень много) — и реализует сам модуль фин учета.
А вот если это будет человек «с пониженным уровнем профессионализма», он…
Не буду детализировать, но «кварковые проводки» и «убытки от кражи — актив» очень хорошо вписываются именно в этот вариант.
Еще раз повторю свой совет, который я дал в первом комментарии: Разберитесь для начала, что такое фин отчетность, для чего она нужна, из чего состоит и какие к ней существуют требования. У вас большие пробелы в базовых знаниях в области учета и отчетности.
Если человек умеет и любит читать — он и так сможет почитать книжки по учету и отчетности, по крайней мере несколько ссылок я оставил.
А всем остальным и картинки хватит — многа букаф все равно не осилят. :)))
Я рад, что картинка вас рассмешила. А то вы столько анекдотов написали, а мне и ответить нечем. Придумать что-то из серии «убыток от кражи — актив» не так то легко… :)))
drive.google.com/file/d/0B68s1C8n6aJCM2JPVTEwTDBlNUtYWHBHUmQxcHZZZm9qRTBF/view?usp=sharing
А можно поподробнее? Что такое (в вашей интерпретации) фонд амортизации, амортизация, стоимость основных, переоценка балансовой стоимости… Хочется обогатиться новыми «академическими» терминами.
:)))
Таки да. Вот прям оба счета — пассив, раздел капитал.
Даже если мы вместо одного активно — пассивного счета «прибыль / убытки» сделаем два счета — оба эти счета будут в пассиве баланса.
Я об этом и говорю — пока не понимаешь экономического смысла разных статей отчетности, все рассуждения об учете, двойной записи и т.п. — не более чем карго культ.
RTFM
Еще раз советую почитать книжки про учет и отчетность. Если нет желания читать стандарты и комментарии к ним четверки — почитайте того же Баффета.
Зазубривают только те, кто не понимает базовых понятий в области учета и отчетности. И, если уж на то пошло, прибыль / убытки — это пассив баланса.
Погуглите еще термин «карго культ». Именно этим вы сейчас страдаете. Назначение фин учета — получение фин отчетности. Всё. Фин счета, двойная запись, проводки и т.п. — не более чем средство получения отчетности. И без понимания того, какой именно должна быть отчетность, не будет понимания, каким должен быть учет.
А у вас, судя по фразам просто напросто нет понимания того, что такое фин отчетность, зачем она нужна и, соответственно, какой она должна быть.
Сразу вспоминается креативная бухгалтерия, описанная Баффетом…
Вы не пробовали в гугле поискать «критерии признания активов МСФО»? :)))
Я рад, что вы умеете строить корреспонденции счетов. Когда реализуете свой блок фин учёта с аналитическими измерениями и корреспонденцией, напишите ещё одну статью. Всем будет интересно. :)))
Потому что в среде финансистов / разработчиков учетного софта минимальной (атомарной) операцией принято считать как раз проводку. Именно проводка обязательно должна учитываться в одной транзакции, а не «все проводки одного документа должны проводиться в одной транзакции». Это — вопрос знания профессиональной терминологии.
Кстати, в большинстве систем проводки одного документа мало того, что учитываются не в одной транзакции, так они еще могут учитываться разными датами :))) Типичный пример — себестоимость продаж по инвойсу.
В том то и дело, что «ядро» фин учета должно корректно работать с самыми разными документами, которые генерируются в разных модулях, написанных разными программистами. Ну и, например, есть еще проводки, учитываемые из журналов.
То, что вы собираетесь вводить дополнительное понятие «операция» (транзакция), которая объединяет в себе несколько проводок, которые должны учитываться одновременно и представляют из себя одно целое — как раз и показывает, что проводка, состоящая только из одного дебета и одного кредита — неудобна.
Намного проще сразу сказать, что проводка = транзакция, которая состоит из некоторого множества строк главной книги, которые всегда учитываются как одно целое (в одной транзакции БД). И не надо придумывать дополнительных сущностей.
По поводу создания отдельного «транзитного» фин счета, сальдо по которому всегда равно нулю (просто для того, чтобы смотреть, какие суммы меняли)… Спорить не буду — если очень хочется создавать кучу транзитных счетов с сомнительными целями, то почему бы и нет? :)))
Про велосипеды очень хорошо сказано. Я именно поэтому и советую посмотреть, как это всё уже реализовано. И сап для новой главной книги, и микрософт для 2013 навика реализовали фактически одну и ту же модель хранения данных об аналитических разрезах фин проводок. Поэтому высока вероятность, что именно такая модель близка к оптимальной (у оебса эта же модель была изначально, и, подозреваю, именно с оебса идею и скопировали).
Почитайте о том, как это в навике сделали и почему именно так сделали. А потом начинайте изобретать свои велосипеды.
Двойная запись выполняет те же функции, что и ограничения целостности данных (Constraints) в базах данных ну или бекапы для сисадминов. До тех пор, пока учет (работа с БД, работа сервера) ведется без ошибок (сбоев), без двойной записи (Constraints, бекапов) можно обойтись. Но, как говорится, все люди делятся на тех, кто не делает бекапов, и на тех, кто уже делает. :)))
Странно слышать от вас такие обвинения. :)))
Давайте я еще раз объясню, как именно хранится информация о фин проводках в нормальных ERP системах. Если отбросить все накопившиеся «какашки мамонтов», то в основной таблице фин проводок есть такие поля:
— номер записи — целое (автоинкремент)
— номер транзакции (проводки) — целое
— дата учета
— код набора аналитик — целое (фин счет — одна из аналитик, когда номер именно фин счета выделяют в отдельное поле, то это скорее унаследованный код, хотя для некоторых ситуаций и полезно)
— признак реверсивности (красное сторно) — булево
— сумма операции в функциональной валюте — decimal
Также есть два ограничения:
1. Дата учета должна быть одной и той же для всех записей с одинаковым номером транзакции (проводки).
2. Сумма поля «сумма операции в функциональной валюте» (на английском понятнее — там это sum and amount — разные слова))) всех записей с одним и тем же номером транзакции (проводки) должна быть равна нулю.
Номер записи обычно идет без пропусков, это облегчает аудит, но само по себе отсутствие пропусков не обязательно, как и само поле «номер записи» :))) Но с этим полем работать намного удобнее.
И это ВСЁ, что нужно собственно для учета. Заметьте, вообще нет никаких дебетов / кредитов, деления счетов на активные / пассивные или на балансовые счета / счета прибылей и убытков. Очень простая логика, которую легко реализовать.
Разумеется, в реальных системах обычно есть дополнительные поля:
— справочная информация (номер и дата документа, описание проводки и т.п.)
— техническая информация (из какого модуля «пришла» проводка а также ключи, помогающие связать между собой записи в главной книге и прочих модулях)
— поля, упрощающие ряд расчетов (денормализация). например, сумма дебита и сумма кредита — их можно вычислить по другим полям — при «признак реверсивности» = ложь если поле сумма больше нуля то дебет, если меньше нуля то кредит; при «признак реверсивности» = истина если поле сумма больше нуля то кредит, если меньше нуля то дебет, но для многих задач удобнее хранить в явном виде.
А теперь сравните с теми ограничениями, которые надо реализовать в вашем варианте дизайна. :)))
Например, подробнее разберем мой пример с переброской денег с еврового счета на долларовый (конвертация денег в другую валюту).
Предположим, что функциональная валюта у нас — евро. Для учета мы используем курсы центробанка, а банк для конвертации — спотовый курс. И эти курсы, как правило, разные.
Как я уже сказал, банк конвертировал 1000 евро в 1100 долларов. А курс центробанка для 1100 долларов — 1005 евро.
То есть итог на фин счетах должен выглядеть следующим образом:
— Банк счет (евро): -1000 (-1000 евро)
— Банк счет (доллар): +1005 (+1100 долларов)
— Реализованная прибыль от курсовых разниц: -5
Если мы допускаем в системе сложные проводки, то можем прямо в таком виде и записать проводку в главную книгу и успокоиться.
А вот если нам надо разбить операции «попарно» — все сильно усложняется.
Например, мы учитываем операцию следующим образом:
Проводка 1
— Банк счет (евро): -1000 (-1000 евро)
— Банк счет (доллар): +1000 (+1100 долларов)
Проводка 2
— Банк счет (доллар): +5 (+0 долларов)
— Реализованная прибыль от курсовых разниц: -5
Итоговый результат тот же самый, но у нас вылазит сразу ДВЕ проблемы.
Проблема 1.
Мы в первой проводке учитываем сумму в валюте (доллары) не по курсу на дату выполнения операции. Это, в свою очередь, приводит к целому букету проблем, начиная от того, что сложнее выполнять банальные проверки корректности пересчета сумм из валюты операции в функциональную валюту и заканчивая СУЩЕСТВЕННЫМ усложнением логики различных расчетов. Ведь мы не можем для расчета суммы в функциональной валюте везде вызывать одну простую процедуру, которая просто находит курс на дату учета операции и умножает сумму в валюте операции на этот курс.
Проблема 2.
Нарушаются базовые принципы фин учета. Фин проводки являются ОЧЕНЬ близкими аналогами ACID транзакций баз данных (собственно говоря, при начале разработки баз данных фин учет был одной из основных сфер применения). То есть, каждая фин проводка должна преобразовывать фин учет из одного корректного состояния в другое корректное состояние. А теперь представим, что по какой-то причине мы зафиксировали в базе только одну из этих проводок. В таком случае мы получим некорректные данные в отчетности. То есть нам надо вводить дополнительную группировку проводок в «транзакции», что в свою очередь усложняет систему.
И самое главное, что подобное деление на простые проводки не дает никакого реального выигрыша. Многие теоретики любят рассуждать о ценности отчетов на основе корреспонденции счетов, но на практике необходимость в этой информации возникает КРАЙНЕ редко.
Вернее не совсем так. Необходимость в данных о «корреспонденции» проводок возникает регулярно, но корреспонденция в том виде, в каком она обычно реализована, не дает нужной детализации. А реализовать её на нужном уровне весьма сложно. Например, у сапа есть очень полезная функциональность — Document Splitting, которая и делает нужные «связки» (об этой функциональности можно почитать здесь и, например, здесь). Но это, мягко говоря, «немножко сложнее» той корреспонденции, которая есть в той же 1С. :)
И подумайте, почему именно так.
То, как вы описываете проводки — не очень корректно и неудобно в реализации.
Достаточно часто надо делать проводки с тремя, четырьмя и более фин счетами.
Например, вы перебрасываете 1000 евро с еврового счета на долларовый и приходит 1100 долларов. Попробуйте записать это проводками, и поймете, почему удобны проводки с тремя и более фин счетами.
Ну и остальные ваши измышления, например записывать в каждой проводке текущее сальдо по счету :)))
Технически, вроде бы да, можно. Но — зачем? Вы про материализованные (индексированные) представления слышали?
Просто если человек, не разбирающийся в бух учете, начнет изучать тему по этой статье — ему будет сложно потом разбираться с реальными задачами в этой области.
Возможно, вы сами до конца не понимаете предназначение именно фин счетов (синтетический учет).