Двойная бюстгалтерия* глазами программиста

  • Tutorial


Большинство из нас сталкивались с бухгалтерами. Многим их терминология кажется китайской грамотой, как для гуманитария обратная польская запись. Однако разобравшись, понимаешь насколько это удобный и мощный инструмент.

Статья не академическая, а отражает сугубо мой упрощенный взгляд, и для тех кто уже осилил академические статьи — будет неинтересной. Тех же кому интересно понять такой простой и мощный инструмент как «двойная запись» — прошу под кат.

Давайте представим себе некую структуру ведущую деятельность, имеющую взаимоотношения с окружающим миром, владеющую некоей собственностью. Не важно что это за структура. Это может быть фирма, домохозяйство, веб-сайт или простой гражданин. Допустим это будет интернет-стартап. Скажем мы сделаем площадку по торговле слонами. Назовем этот проект «Слономаркет».

Мы не будем регистрировать никакие юрлица, ИП/ФОП и прочие юридические действия. Представим себе что просто несколько друзей договорились запустить подобный стартап, и ведут свою деятельность «в гараже».

Баланс


Для того чтобы понимать общую картину финансов в нашем Слономаркете, мы заводим табличку, в которой пишем что у нас есть, что нам должны, что мы должны и т.п. Назовем эту табличку "баланс", а строчки в нашей табличке "счетами баланса".

Очевидно что не все йогурты одинаково полезны существует большая разница между счетами отражающими деньги в «кассе» от того сколько мы должны денег поставщикам. Соответственно мы разделяем нашу табличку на две. В одной будут так называемые "активные счета", отражающие то что у нас есть, чем мы можем распоряжаться и т.п., во вторую половину мы занесем "пассивные счета", где мы будем отражать наши долги перед кредиторами, поставщиками и т.п.

На самом деле активы и пассивы (Ржевский молчать!) это не совсем собственность и долги, но для начала предлагаю такое определение, чтобы не запутываться. Для запоминания можно использовать такую ассоциацию — активами мы можем активно распоряжаться. Отдать деньги случайному знакомому или потратить. Простить долг клиента (долг клиента перед нами — актив, наш долг перед поставщиком — пассив), разломать станок или отдать автомобиль на металлолом. Все зависит только от нас. А с пассивами возможны только пассивные операции. Мы не можем взять и отдать случайному бомжу наш долг перед поставщиком. Нужно согласие как бомжа так и поставщика.

Пример баланса Слономаркета:

Активы:

  • ЯндексДеньги: 1000руб
  • Пейпел: 500руб
  • Наличка у Феди: 1000руб
  • Слоны на складе: 600руб (из них уже проданных но не отгруженных — 500руб)
  • Сайт Слономаркета: 400руб
  • Хостинг на год: 1000руб
  • Задолженность клиентов за слонов: 1000руб
  • Не покрытые убытки (от кражи слонов): 500руб

Пассивы:

  • Уставной капитал (то что внесли учредители): 2000руб
  • Нераспределенная прибыль (от продажи слонов): 1000руб
  • Кредит в вебмани: 1000руб
  • Проданные но не поставленные клиенту слоны: 500руб
  • Долг перед поставщиком Васей: 500руб
  • Долг перед программистом Федей: 500руб
  • Начисленные и не выплаченные дивиденды: 500руб

Некоторые счета вызывают удивления, например не понятно почему прибыль в пассивах а убытки в активах. Это нормально, я объясню чуть ниже.

Хочу обратить ваше внимание на тот факт что сумма пассивных счетов равна сумме активных счетов. Это свойство баланса является фундаментальным. Отсюда происходит и само название — баланс. Если бухгалтер говорит что у него не сходится баланс, то обычно он имеет ввиду именно то, что у него активы и пассивы не равны, что является первым признаком ошибки.

Еще один взгляд на то какой счет будет пассивным или активным:


Активы это то что у нас есть, на что мы потратили деньги, а пассивы это то откуда эти деньги взялись.

С этой точки зрения мы не можем отразить прибыль в активах, ведь по сути она уже там есть — либо в виде денег в кассе, либо в виде долга клиента либо еще в какой форме. Даже если клиент рассчитался и мы сразу эти деньги потратили на покупку слонов на склад — прибыль будет лежать в виде новых слонов, но она у нас уже отражена в активах. Но откуда она у нас взялась? Ее происхождение мы записываем в пассивах — прибыль.

Аналогично с убытками. Если у нас произошли убытки, например у нас украли слонов, то происхождение этих слонов у нас уже отражено в пассивах. Если это были те слоны которых мы уже продали но не отгрузили, то они видны в оплаченных но не отгруженных слонах. Если мы купили их из денег учредителей, то в уставном капитале, если нам дали их под реализацию или с отсрочкой, то в виде долга перед поставщиком. Но куда эти деньги(слоны) ушли? Это наш убыток от кражи.

С точки зрения возможности распоряжаться этими убытками, и того что они у нас «есть» тут тоже нет противоречия — мы можем простить вору. Мы можем «повесить долг» на охранника который проворонил воров, и высчитывать из его зарплаты. Мы можем обменять эти убытки на страховую выплату (если была страховка). Ну или банально «покрыть» убыток из прибыли, уменьшив прибыль и убыток на одну сумму.

Почему уставной капитал/собственный капитал отражается в пассивах?

По происхождению — мы получили деньги от учредителя, значит мы как-бы «должны» эти деньги ему. Также по функциям — мы можем распределить прибыль например на дивиденды, или на увеличение уставного капитала. Дивиденды подразумевают что учредитель их заберет у фирмы (в виде активов, деньгами или продукцией или еще как), а если мы увеличим из прибыли уставной капитал, то это будет будто учредитель отдал часть причитающейся ему прибыли на увеличение активов стартапа.

Если же у нас нет «лишней» прибыли, но есть убытки, и мы хотим покрыть эти убытки, то нам ничего не останется как уменьшить капитал. Это примерно соответствует «поскольку у фирмы денег нет, то я прощаю ей часть долга». Т.е. если наш Слономаркет заработал прибыль, то он становится должен учредителю больше денег, а если потерял денег, то становится должен меньше.

Зачем такие сложности? Потому что у нас должен быть баланс. Обе стороны баланса должны быть равны, так что просто так взять и выкинуть некоторые статьи баланса (счета) мы не можем.

Шпаргалка по тому что куда относится:

Имущество, то чем мы можем распоряжаться — активные счета
Обязательства перед нами, то что нам должны — активные счета
Наши обязательства, то что мы должны — пассивные счета
Прибыль — пассивные счета
Убытки — активные счета
Доходы — пассивные счета
Расходы — активные счета
Капитал, т.е. вложения учредителей, уставной капитал и т.п. — пассивные счета

Проводки


Здесь мы плавно подошли ко второму фундаментальному свойству баланса — любые изменения у нас касаются минимум двух счетов. Данное утверждение является прямым следствием из основного свойства баланса — обе стороны баланса (активы и пассивы) в сумме должны быть равны. Соответственно если мы уменьшаем или увеличиваем одну сторону, то должны изменить аналогично и другую сторону. Или должны изменить другой счет того же типа (активный или пассивный) но с другим знаком (т.е. если мы увеличили какой-то актив, и не изменили пассивы, то должны уменьшить какой-то другой актив… аналогично с пассивами).

Чтобы убедиться что нам этого достаточно вспомним, что активы это то что у нас есть, а пассивы это то откуда оно взялось. Соответственно в подобных терминах если у нас появился какой-то актив, то он должен откуда-то взяться, и соответственно появится аналогичная запись и в пассивах, или уменьшится другой актив.

Допустим у нас появился товар на складе. Но он не может появиться просто так. Либо мы его купили, и тогда у нас уменьшились какие-то активы (деньги в кассе, деньги на счету и т.п.), либо нам его дали в долг (с отсрочкой платежа, под реализацию и т.п.) и тогда у нас появился новый пассив на ту же сумму. У нас украли деньги? Уменьшились деньги, возросли расход убытки. Мы отдали кредит? Мы не можем отдать кредит, не уменьшив наши активы или не увеличив другие пассивы. Ведь мы что-то отдали. Это или деньги, или что-то одолженное в другом месте (например у учредителя) или в счет долга дали какой-то товар (тогда уменьшились запасы на складе) или мы вернули товар взятый под реализацию (уменьшили колво товара, уменьшили долг перед поставщиком за этот товар). Всегда изменяется два счета.

Так мы подошли ко второму фундаментальному понятию — проводка.

Проводка это «атомарная» операция изменения двух счетов на одну и туже сумму. В бумажном учете используют большие книги в которых записывают различные счета и операции с ними. Каждую проводку нам нужно записать дважды — у первого счета и у второго. Это называется двойной записью, и дало название методу учета являющемуся базой для любого учета в наше время.

Любая операция в которой затрагивается только один счет — ошибочна (да, я знаю про забалансовые счета, но это рудимент регламентированного учета являющийся следствием того что бухгалтера не программисты и в этой статье я их не рассматриваю, как и активно-пассивные). Если вы хотите сделать одиночную запись, то либо вам ее не нужно делать, либо вы где-то потеряли ее вторую половинку, либо вам нужно делать запись не в тот баланс (например когда люди начинают смешивать деньги бизнеса и личные деньги, что характерно для людей у которых в бизнесе нет других учредителей и нет хорошего понимания учета).

Теоретически в одной проводке могло бы быть например три счета, но это слишком затруднит контроль правильности и т.п., поэтому атомарная операция влияет на два счета и только на два.

Итак, у нас есть баланс, который состоит из счетов. Счета бывают двух видов — активные и пассивные. Изменения в балансе производятся проводками. Проводка это атомарная операция с балансом, она затрагивает два счета и меняет их на одинаковую сумму.

Операция


С каждой операцией связана одна или несколько проводок. По сути операция это набор проводок связанных единым смыслом, единым событием (плюс информация описывающая само событие но для баланса нам она не нужна).
Операция это некая сущность отражающая события реального мира. Перемещение товара, заказ, выплату дивидендов и т.п. Т.е. реальная операция.
Проводки одной операции должны находиться в одной транзакции СУБД, и если одна проводка не прошла, то не прошла и вся операция, т.е. у операции присутствует атомарность.

Допустим, мы получили партию слонов. Сибирских слонов на 100рублей, африканских на 400рублей и американских на 500рублей. В результате у нас появилось несколько проводок:

1) увеличение долга перед поставщиком на 100рублей (пассив), увеличение сибирских слонов на складе на 100рублей (актив)
2) увеличение долга на 400 рублей, увеличение на ту же сумму африканских слонов на складе
3) увеличение долга на 500 рублей и аналогичное увеличение американских слонов на складе
4) уменьшение долга поставщика за предоплату 500рублей, и уменьшение на ту же сумму нашего долга поставщику (в идеале такие вещи делаются отдельным служебным документом, и да я знаю что счет взаимоотношения с контрагентами активно-пассивный, но пусть будет тут).

Все эти проводки привязаны к одной операции, и связанны с одним событием, а именно получением товара от поставщика, происходят одновременно и т.п.

Документ


Обычно в любом учете каждое событие мы отображаем в виде одного или нескольких документов. Если какой-то документ отражает изменение в балансе, то они отражаются в виде одной или нескольких операций. Разделение проводок связанных с одним документом на различные операции не имеет четких правил и зависит от конкретных целей учета.

Дебет и кредит


Давайте рассмотрим какие у нас бывают проводки.

1) Увеличение активного счета, увеличение пассивного (А+П+)
2) Уменьшение активного счета, уменьшение пассивного (А-П-)
3) Уменьшение и увеличение двух активных счетов (А+А-)
4) Уменьшение и увеличение двух пассивных счетов (П+П-)

Получается четыре вида проводок. Остальные не удовлетворяют требованию сохранения баланса. Можем ли мы это упростить?

Поскольку мы пока не вкладывали никакого смысла в порядок счетов, то запишем их в другом порядке:

А+П+
П-А-
А+А-
П-П+

Что мы можем заметить общего в тих проводках?

1) Если на первом месте находится активный счет, то он увеличивается, если пассивный, то он уменьшается
2) Если на втором месте находится активный счет, то он уменьшается, если на втором месте находится пассивный счет, то он увеличивается
Т.о. у нас получается один вид проводки, в которой указывается два счета, назовем их дебетуемый счет, и кредитуемый счет, и суммы проводки.
Ну и соответственно записываем наши правила действия проводки:
1) Если дебит активного счета, то он увеличивается, если пассивного, то он уменьшается
2) Если кредит активного счета, то он уменьшается, если пассивного счета, то он увеличивается

На этом именно бухгалтерская форма ведения баланса заканчивается.

Еще немного нормализуем


Давайте попробуем еще упростить.

Давайте будем записывать значение активного счета положительным числом, а пассивного отрицательным. Упрощенно структура таблицы баланса будет выглядеть так:

ИД,
Название,
Тип (пассив/актив),
Значение
А структура таблицы проводок соответственно:
ИД,
Дебет (ид дебетуемого счета),
Кредит (ид кредитуемого счета,
Сумма

Проверка целостности баланса у нас становится еще проще — сумма всех счетов должна быть равна нулю.

Правила выполнения проводок тоже просты:

1) Прибавляем сумму проводки к дебетуемому счету
2) Если счет пассивный, то проверяем не стал ли он положительным, если да, то прерываем операцию и откатываем транзакцию
3) вычитаем сумму из кредитуемого счета.
4) Если счет активный, то проверяем не стал ли он отрицательным, и если да, то прерываем операцию и откатываем транзакцию.

Всё. Все основные свойства учета у нас уже есть.

Конечно в реальной базе у нас добавятся различные поля связанные с предметной областью, например у проводок нужна дата/время и связь с документом породившим проводку. У счетов нужна информация о том что то за счет такой, и связи на другие связанные с ним объекты (контрагентов, товары и т.п.), но это уже другая история.

Пожалуй на этом пока закончим, если будет интересно, то дальше расскажу как по максимуму извлекать информацию из баланса, разберу немного примеров операций и т.п.

АПД: Разделил понятие операции и документа. Во время обсуждения статьи здесь было написано, что операция и документ это одно и тоже.
Поделиться публикацией
Комментарии 266
    +6

    Если уж мы программисты — надо упрощать модель, а не молиться на ее сложность. Достаточно сменить знак у всех пассивных счетов, и правила проводки упростятся до простого "дебит — всегда увеличивает, кредит — всегда уменьшает".

      0
      Я об этом написал в конце под заголовком «еще немного нормализуем».
      Вообще я когда начинал писать статью, то думал опустить стандартное описание дебета и кредита, но решил оставить для лучшего понимания бухгалтеров.
        0

        А, вижу. Тогда у меня есть еще вопросы.


        Рассмотрим ситуацию, когда некоторому контрагенту был выплачен аванс, ставший долгом контрагента — активом. Далее по договору контрагентом были оказаны какие-то услуги, в результате чего уже мы оказались ему должны — пассив.


        Как такое отражать? Заводить два счета — или лучше вернуть тип счета "активно-пассивный" и разрешить его балансу "скакать" в обе стороны от нуля?

          0
          Я считаю что забалансовые счета и активно-пассивные счета это плохая архитектура, и вот почему:
          Бизнеслогику активно-пассивных счетов мы легко можем реализовать шаблоном Наблюдатель, подписанным на оба счета, и создающим служебный документ с проводкой осуществляющей взаимозачет.
          При этом если у нас будет активно-пассивный счет, то мы:
          1) вносим лишнюю сущность
          2) усложняем логику, в том числе логику контроля, логику отображения и т.п. Значительно усложняем, фактически в два раза усложняем
          3) у нас исчезает возможность бизнес-логики при которой возможно что одновременно и мы должны контрагенту и он нам, например когда система налогообложения требует избегать взаимозачетов а только прямого расчета или сложные расчеты связанных компаний, когда фактические долги например в разных валютах и мы хотим согласовать курс, который может отличатся от балансового. Вариантов много где нужно отдельно иметь такие счета. Причем может оказаться что мы хотим такую логику ввести уже постфактум, когда уже несколько лет работали по простой. Такое изменение с активно-пассивными будет неудобно.
          4) движения по счетам смешивается, мы не можем вести отдельный учет по оборотам. С двумя счетами у нас есть два дебетовых оборота и два кредитовых, а с одним — только по одному, а значит и информации меньше.

          В общем не стоит смешивать сущности, не стоит. Не SOLIDно.

          С забалансовыми сложнее, там больше случаев может быть, но по возможности я бы от них тоже отказывался. Если мы сами строим учет, у нас нет регламентированного плана счетов и т.п., то лучше без этих рудиментов.
            0

            А разве такой "наблюдатель" — не лишняя сущность?

              0
              Мой бухгалтер только что задала мне тот-же вопрос, только другими словами).
              Нет, не лишняя, а «отдельная».
              Если не выделять ее в отдельную сущность, то она никуда не девается, просто размазывается по множеству других сущностей.
              Где отображать наш счет? В правой части или в левой?
              С раздельными счетами просто, а тут нужно писать логику.
              Дополнительный тип счета отражаемый в базе, в логике проверки целостности и т.п.
              –2
              Честно, очень смешные аргументы. Особенно «усложняем логику, в том числе логику контроля, логику отображения и т.п. Значительно усложняем, фактически в два раза усложняем» :)))
              Возможно, вы сами до конца не понимаете предназначение именно фин счетов (синтетический учет).
                +1
                Ок, вам смешно. Отлично. Смех это прекрасно. Не жадничайте. Аргументируйте. Я тоже хочу поржать вместе с Вами.
                  +1
                  Полностью согласен с Менделем. Активно-пассивные счета -костыль.
          –2
          А давайте еще упростим. Дебет всегда увеличивает дебет. Кредит всегда увеличивает кредит.
            –1
            А давайте… почитаем статью?
            дебет увеличивает дебет, а кредит увеличивает кредит… гениально.
            А кредит соответственно уменьшает дебет, а дебет соответственно уменьшает кредит?
            где-то я это уже видел… постойте… а ну да, положительные и отрицательные числа.
            Это я уже молчу что вы над терминологией надругались как над портовой девкой.
            У нас тут спор между западной и советской школами, отчасти терминологический — на сотню страниц разросся, а вы тут «есть устоявшаяся терминология в несколько веков, но мне так удобнее, так что привыкайте»… Ну а про такие мелочи как проверка целостности базы и т.п. я вообще молчу… почитайте статью, почитайте, коль перешли сюда.
          0

          Довольно быстро разобрался с этим когда начал записывать расходы в GnuCash

            0
            Тоже использую GnuCash. Довольно топорный и примитивный, с дизайном из начала 2000-х, но блин, ничего больше нет. Жаль что ничего более современного и симпатичного на эту тему нет, чтобы не грузился 20-30 с (при том что на С написан), не требовал бы кучи ручных настроек (биржи, тикеры акций, валюты нужно руками подключать) и не использовал бы perl для синхронизации с внешними сервисами (курс валют, цена акций, и т.д.)
              0

              Перешел несколько лет с GnuCash на YNAB и очень рад. Он просто работает, никаких зависимостей и в комплекте с программой идёт идеология работы, помогающая тебе организовать свои финансы.

                +1
                Более 10 лет пользуюсь AceMoney. Первая программа, которую без сожаления купил.
                А GnuCash оттолкнул как раз «бухгалтерским» подходом при занесении записей.
                  0
                  Да, AceMoney отличная. Люто плюсую :) купил когда-то, лет 10 уже использую.
                  0
                  Ну как это нет. Есть:
                  Money Manager Ex (http://www.moneymanagerex.org) — бесплатная, открытая, в т.ч. есть клиенты для мобильных платформ. Сначала пользовался им, но в какой-то момент меня перестала устраивать не достаточная глубина анализа (нет возможности создавать разветвленную аналитику).
                  AbilityCash (https://dervish.ru/) — бесплатная, закрытая. Разрабатывается с начала 2000-х, поэтому интерфейс немного не свеж. По части глубины анализа существенно превосходит предыдущую, но нужно разобраться и настроить под себя.
                  1С: Деньги (http://v8.1c.ru/money/) — не бесплатная (но дешевая), «полуоткрытая» (поставляется только в базовом варианте, версии проф не бывает, поэтому править конфу нельзя, но внешние отчеты — пожалуйста). Есть какой-то мобильный клиент. Настраиваемая как душе угодно аналитика, хорошие отчеты (если знаете СКД, отчеты можно гнуть для себя как хочешь).
                  Для домашней бухгалтерии самое то.
                    0
                    Ну не знаю, эта вся бухгалтерия слишком домашняя, тупо записывать траты. Я такими пользовался, рано или поздно начинается рассинхрон, где-то что-то не сходится. Вот в случае с двойной записей, все четко, к тому же хочется гибкости, чтобы одной транзакцией записать что-то типа: купил что-то со своей карточки, с комиссией за конвертацию, всю суму нужно разделить на 2-3 человека. Ничто кроме Gnucash из того что пробовал, не позволить такое записать, нужно будет вбивать несколько транзакций. Или одной транзакцией записать доход, где чистый доход идет на счет а налоги в траты. Чтобы capital gain по-нормальному считало, а не только FIFO в лучшем случае. Да и вообще приятно из коробки работать с вот этой структурой (assets, liabilities, income, expanses) пропагандируемой от Киосаки до более фундаментальных специалистов.
                  +2
                  Раз уж подняли эту тему, много лет всё пытался завести учёт финансов семьи, но с рядом требований (думаю, многим семейным будет полезно):
                  1) непосредственный учёт, причём для двоих (муж-жена), доходы-расходы обоих
                  2) персональные счета, которые никак не светятся у второго участника, это может быть как что-то сберегательное, так и рабочее (выдали на закупку чего-либо), и с фиксацией, кто, когда, на что выдал и когда вернуть/отчитаться
                  2а) сбережения в наличке и их движение
                  3) поддержка обязательных платежей (ЖК, ипотека), с возможностью корректировки сумм и предупреждением что «скоро пора»
                  4) кредитки. Ставка, беспроцентный период каждой покупки, обязательные платежи к дате,…

                  Желательно онлайн, но можно и стационарно. Можно платную.
                  Крайне желательна поддержка банков или хотя бы их смс, автоматом вносить инфу в базу, для смс это получается нужен андроид клиент. Есть что-то такое?
                    0
                    Дзен мани? zenmoney.ru
                      0
                      1 — не вижу как сделать несколько логинов с общими счетами
                      2 — отсутствует
                      4 — отсутствует (счет, названный кредиткой, это не 4)

                      Для одиночки или фрилансера без ипотек и кредиток может и норм.
                        0
                        1. support.zenmoney.ru/topics/9-semejnyij-byudzhet-dlya-vsej-semi
                        2. Там же, плюс «Долги», плюс «Проекты»
                        4. support.zenmoney.ru/topics/5-nastrojka-kreditnyih-kart-i-kreditov

                        btw, не имею к ним отношения, просто нравится продукт :)
                          0
                          То есть ряд операций можно только через приложение, часть только через веб… Очень непроработан этот момент.
                          4 — для кредиток нет отслеживания платежей, например у сбера «до 50 дней» идут на каждый из платежей, и нужно отслеживать каждую транзакцию. Условно, при общем долге 100к — с процентами может быть только 10к, а через 2 дня их станет 60к, потому что через 2 дня у них «дата Х» и спишет процент за 50к.
                          Также, в поддержке банков есть всякий левак, но нет ни альфы, ни сбера.
                          В веб для кредиток нет такого ВАЖНОГО поля как процентная ставка.
                          И 100р в месяц это как-то дохрена (да, видел и другие тарифы)
                            0
                            там за 1500 пожизненная подписка (купил пару лет назад, полет нормальный).
                      +1
                      Я пользуюсь Sanuel Family. Платная. Есть клиент десктопный, есть мобильный.
                      Позволяет работать с несколькими пользователями, со своим набором счетов у каждого. Можно создать бюджет, можно расписать платежи по датам, которые будут отображаться на главной странице и позволят о них не забыть. Есть много отчётов, при помощи которых анализируются доходы, расходы, динамика их изменений (легко посмотреть на сколько выросли расходы на бензин за год-два, например).
                      Есть калькулятор стоимости кредитов, можно просчитать выгоду от досрочного погашения. Есть возможность создать финансовую цель (накопить на машину за год, например), и отслеживать прогресс в её достижении (с подсказками, сколько надо в этом месяце на неё отложить, чтобы достичь к запланированному сроку). И ещё масса другого функционала.
                      Пользуюсь ей уже много лет, весьма доволен. Счета в разных банках и разных валютах, кредиты, кредитные карты (правда эта часть не всегда корректно работает в плане расчётов ежемесячных минимальных платежей, но тут могут быть виноваты мои руки), всё под контролем.
                    0
                    А как учитывается уплата всяких налогов?
                      +1
                      Пассивный счет «задолженность по налогам».
                      Ну или пачка таких счетов под каждый налог (субсчетов скорее, но ту тему пока не затрагиваем).
                      При операции продажи мы кидаем часть на прибыль, часть на себестоимость, часть на налоги.
                      –1

                      Меня всегда удивляло, когда так называемая "двойная запись" преподносится как преимущество. Везде говорят, что для минимизации ошибок нужно избегать дублирования информации, а здесь наоборот, даже поощряется. Как у кого-то после этого язык поворачивается назвать систему удобной или понятной — ума не приложу. Причем, я ещё понимаю, если бы записи для разных счетов вносились разными системами или транзакциями — тогда имеет смысл проверять друг друга (хотя тоже сложный вопрос, на чьей стороне правда). Но когда это делает одна и та же система, за одно действие — верх театра абсурда. А потом начинаются проблемы, что что-то там не сходится, наверное при записи ошиблись — в одном месте записали 10, а в другом --100. Сами создали проблему, сами героически решаем. А было бы это одно поле а не 2, такого бы не случилось. Поправьте меня, если я ошибаюсь.

                        +3
                        Если бы поле было одно, то не ошибались бы никогда на 100 вместо 10?
                          –4

                          Очевидно, расхождения бы были бы невозможны. Пока у меня складывается впечатление, что сначала пишут разные числа, а потом пишут другие разные числа, чтобы избавиться от расхождений и жалуются, что приходится писать вот эту вторую пару. А о том, что и первую можно не писать и избавить себя от дальнейшей работы почему никто не упоминает, словно все поголовно владеют каким то тайным знанием, зачем это нужно.

                            +4
                            «Тайное знание» подробно описано в статье. Мне даже кажется очень подробно.
                            Плюс я планирую во второй части в основном его повторять (вернее расписать подробнее несколько относительно реальных примеров применения данного подхода). Плюс ниже я еще раз повторил.
                            Вот честно — я уверен что несмотря на то что я звучу как попугай, я считаю что действительно оно сложно понимается и стоит несколько раз повторить, а потом еще раз повторить, но у меня твердая уверенность что вы или не читали статью вообще, или пробежали по заголовкам и даже не попытались в нее вникнуть.
                            Я очень хочу слышать вопросы, но вопросы конкретные и осмысленные а не какие-то абстрактные высказывания ходящие по кругу. ПРОЧТИТЕ СТАТЬЮ.
                            Специально для вас я приведу абзац который я выкинул из окончательной версии статьи (был в середине):
                            Советую взять листик в клеточку или ексель/гугл-таблицу, нарисовать таблицу «баланса», таблицу для проводок и расписать все проводки для всех примеров которые я приводил в тексте. Какой счет дебетуется, какой кредитуется, на какую сумму и т.п. Дополнительно было бы неплохо попробовать построить цепочку проводок которые могли привести из нулевого баланса (в начале проекта на всех счетах у нас ноль) нашего Слономаркета к балансу приведенному в начале статьи.
                              +1
                              Я очень хочу слышать вопросы, но вопросы конкретные и осмысленные а не какие-то абстрактные высказывания ходящие по кругу.
                              Да с «абстрактными высказываниями» тоже нормально.

                              У нас есть абстрактное высказывание:
                              Везде говорят, что для минимизации ошибок нужно избегать дублирования информации, а здесь наоборот, даже поощряется.
                              Примем его на веру и напишем пару следствий:
                              1. Бекапы — это категорически неправильно. Нельзя их делать. А бэкапы бэкапов в другом — это вообще смерть.
                              2. Системы логирования — это вообще катастрофа. Их быть не должно. Ни в коем случае. Вся имеющаяся в них информация поступила туда из основной системы и, разумеется, там уже есть — а копии нам не нужни никогда и нигде.

                              Ну и другие подобные же выводы можно сделать. Нравится? Применимо на практике?

                              Правда заключается в том, что у людей, высказывающих подобные вещи просто каша в голове и они не то, что бухгалтерии не понимают — они в принципе и программирования-то не понимают и того как IT-системы (а бухгалтерия — это «родоначальная» IT-система, ради них и предки компьютеров, собственно, выпускались).

                              Все современные файловые системы и базы данных, блин, к «двойной записи» пришли — все данные пишутся в лог и на диск/базу. И «подведение баланса» у них тоже есть — это когда вы завершаете транзакцию. Почему бухгалтерия «подводит баланс» раз в месяц, а базы данных сотни раз в секунду — вопрос интересный, но базовых принципов не меняющий.
                                0

                                Вы правда не видите никаких изъянов в своих рассуждениях? Подумайте еще раз.


                                Подумали?


                                Бекап — это по определению неактуальные данные. Когда у вас противоречие в бекапе и оригинальных данных, то при накате бекапа у вас нет вопросов, как его разрешать. Используются значения из бекапа. Накат исходных изменений в бекап (т.е. создание нового бекапа) тоже не предполагает, что вы вдруг начнете сомневаться, обновлять или не обновлять?


                                Лог — вообще ни к селу ни к городу. Вы сами то поняли, что сказали?


                                Вся имеющаяся в них информация поступила туда из основной системы и, разумеется, там уже есть — а копии нам не нужни никогда и нигде.

                                Строчка в логе 01.01.2017 00:00 Access denied где именно хранится в основной системе? Для определености можете считать, что система — это компьютер, в который была совершена попытка логина.


                                Кеш — тоже вторичные данные. Если данные в кеше противоречат основным данным, вы инвалидируете кеш.


                                Логгирование в базах данных и в файловых системах не пишет одинаковые данные в лог и основное хранилище. В этом нет смысла. Там то данные как раз разные и естественно, никому в голову не приходит это называть двойной, тройной или какой еще записью. Кроме того, лог не работает для восстановления данных — если данные повреждены, то они утеряны. Он лишь позволяет сказать, были они записаны или нет и вернуться к одному из состояний в хранилище. А не состояний в хранилище или логе


                                А из названия термина "двойная запись", я, как всякий здравомыслящий человек, подразумеваю, что это не просто так и действительно пишутся одинаковые данные в 2 разных места. Точнее, предполагается, что они будут одинаковыми, а что на самом деле получится, непонятно. И таки между завершением транзакции и "подведением баланса" в бухгалтерии чудовищная разница. В первом случае снаружи никто не видит несогласованного состояния. А во втором несогласованность уже есть, непонятно, сколько народу ее увидело и тут она мучительно ищется и устраняется, причем еще почему-то автоматически это не делается.


                                Вообщем, я понимаю, что очень хотелось блеснуть остротой ума, только каша чуть на пол не выплеснулась. Впредь будьте аккуратнее.

                                  0
                                  А из названия термина «двойная запись», я, как всякий здравомыслящий человек, подразумеваю, что это не просто так и действительно пишутся одинаковые данные в 2 разных места.

                                  Вы ошибаетесь. Здравомыслящий человек не подразумевает, а читает статью в которой несколько раз написано что данные РАЗНЫЕ.
                                    0

                                    Хм… А здесь вы с пеной у рта утверждаете, что одинаковые.

                                      –1
                                      Вы опять путаете теплое с мягким. Не может быть разных ЧИСЕЛ, но данные РАЗНЫЕ. Вот скажите, у вас ночной дожор? Вы пришли вечером сюда покушать? Не потроллим не уснем? Или вы действительно такой?
                                        –2

                                        Простите, что? Числа — это не данные? В учете? Вы серьезно? непроизвольно пытается пощупать лоб

                              +1
                              В данном случае дублирование информации используется для выявления ошибок. А требование к отсутствию дублирования это немного о другом. Дело в том, что считать ошибкой.
                              Допустим, возьмём классический реляционный подход. Состояние базы данных корректно, если оно внутренне непротиворечиво. То есть, ошибка, и внутреннее противоречие, здесь, по сути, синонимы. Но это так только с точки зрения математики. Если добавить к рассмотрению связь с реальным миром, то отсутствие противоречий не гарантирует нам корректность данных. Любое внутренне противоречие является ошибкой, но не любая ошибка выражается во внутреннем противоречии.
                              Рассмотрим простейший пример. Допустим, у нас есть одна таблица с контактными данными людей. И в ней указано, что телефон Васи — 555-77-77. Там же есть поле, в котором указаны адреса, и там записано, что Вася живет в доме номер 1 по улице Ленина, в 77-й квартире. Теперь представим, что у нас есть вторая таблица, в которой указаны номера телефонов, закрепленных за адресами. И там есть запись, указывающая что в той самой 77-й квартире, в доме номер 1 по улице Ленина, подключен совсем другой телефон — 777-55-55.
                              Очевидно, что в записях ошибка. Но это нам мало чего даёт, ведь мы не знаем какая из записей верна. Мы теперь не можем сказать, то ли Вася живет по другому адресу, то ли у него другой номер телефона. Но если бы у нас не было таблицы, в которой телефонные номера связаны с адресами, разве это гарантировало бы нам корректность телефонного номера, или адреса Васи? Конечно же нет. Тот кто записал эту информацию, мог указать что угодно. Никакого Васи вообще может не существовать. И квартиры такой в том доме может не быть.
                              Зато, наличие дубликата позволило нам выявить тот факт, что ошибка в принципе существует. В случае с описанной БД, нам это мало что даёт. Но когда все ходы записаны, а в случае с бухгалтерией это именно так, это даёт нам повод перепроверить операции, и выяснить, откуда взялась ошибка. Баланс работает как контрольная сумма. А история операций, как информация для восстановления.
                              Если в нашу БД из примера добавить данные о том, кто вносил каждое изменение, а так же хранить все предыдущие записи, то мы могли бы, выявив ошибку, найти того, кто её внёс, и каким было последнее непротиворечивое состояние. В таких системах дублирование помогает искать и устранять ошибки, от которых невозможно формально защититься, например ошибочный пользовательский ввод.
                                +1
                                Спасибо за комментарий. Отчасти Вы правы. Но в контексте фин.учета это не совсем верно. Двойная запись не удваивает информацию. Двойная запись лишь требует ПОЛНОТУ информации. Она немного ограничивает нас в том какую информацию мы можем игнорировать, но по факту у нас здесь нет такого чтобы одна и та же информация повторялась дважды.

                                В программировании, и в особенности в проектировании структур данных есть два процесса: нормализация и денормализация БД.
                                На первый взгляд это взаимно противоположные действия, но немного не так.
                                Нормализация это процесс уменьшения избыточности, с целью уменьшения количества логических ошибок, упрощения и т.п.
                                Денормализация это процесс целенаправленного внесения избыточности для решения каких-то конкретных задач — увеличение надежности, улучшение производительности и т.п.
                                Ключевой момент который упускают те кто считают эти процессы противоположными — денормализацию можно проводить ТОЛЬКО ПОСЛЕ ТОГО КАК была проведена нормализация. Эти процессы не противоположны, а взаимно-дополняющие. Случайно денормализованная структура несет в себе хаос. Специально денормализованная — гармонию :)
                                  0
                                  Очевидно, что в записях ошибка. Но это нам мало чего даёт, ведь мы не знаем какая из записей верна.

                                  Вот-вот, о чем я и говорю. Так называемая "двойная запись" делает 2 записи, из которых непонятно, какая из них верна, если там ошибутся и в одно место запишут одно, а в другое — другое.


                                  Возможно, это просто некорректная терминология, тянущаяся из дремучего бумажного легаси, и на самом деле операция делает одно изменение + 2 изменения в кешах (суммы на задействованных счетах). Но тогда я не понимаю, зачем ее (терминологию) применять, да еще и с каким-то придыханием рассказывать всем вокруг, какое же это благо — "двойная запись". Если это не более, чем обновление кеша — то что в этом особенного?


                                  Кроме того, раз сумма счета всего лишь кеш при совершении операций, то при наличии расхождений исправление элементарно — нужно лишь инвалидировать кеш и посчитать его заново. Это автоматическая операция, но судя по количеству мемов про рвущих волосы бухгалтеров в последний день месяца из-за не сходящихся балансов, что-то тут не то.

                                    0
                                    В огороде бузина, в Киеве дядько.
                                    Прочтите уже статью.
                              +3
                              А было бы это одно поле а не 2, такого бы не случилось.

                              Нет, такое бы все равно случилось. Просто оно не было бы замечено — и это куда хуже.

                                –4

                                Ну заметите вы расхождение и на что его исправлять? Можете посчитать правильным число 100, а на самом деле правильное было 10. И в чем выгода, если опять результат неправильный будет?

                                  +4

                                  С вашим подходом лучше от бухгалтерии держаться по-дальше. Числа-то не из головы придумываются вообще-то.

                                    0

                                    Какая разница, откуда числа приходят? Вот у вас есть факт: 2 разных числа, когда должны быть одинаковые. Что вы будите с этим делать? Если у вас нет никаких сторонних источников данных (типа товара на складе), как вы поймете, чему верить?

                                      0
                                      У вас не может быть РАЗНЫХ чисел.
                                      Они по определению одинаковые.
                                      Разные числа не разрешит записать программа или злой главбух.
                                      Двойная запись это не про копию информации а про закон сохранения.
                                      Если бы третий закон Ньютона назвали бы «закон двух сил», то вы бы тоже предполагали что они должны быть одинаковые, но кто-то по ошибке может сделать их разными а потом не понятно будет какой вариант правильный?
                                        –1
                                        У вас не может быть РАЗНЫХ чисел.

                                        Как не может, когда ветка у нас начинается с обсуждения такой ситуации. И не спрашивайте, как она появилась — анекдот про русского и титановые шарики знаете? Вот это эта ситуация и есть.

                                          +1
                                          Понятно. Ночной дожор. Заканчиваю кормить.
                                        0

                                        А куда, собственно, они делись, сторонние источники-то?

                                          0

                                          Сгорели или утонули :)

                                      +1
                                      Вообще вопрос не такой уж глупый как кажется.
                                      На самом деле 99% возможных ошибок будут обнаружены прямо в момент их совершения. Вы просто не сможете записать неправильно. Получите сообщение об ошибке или еще как, но вам не нужно будет выискивать в чем именно ошибка поскольку как правильно заметил mayorovp на момент внесения данных в систему учета у вас перед глазами будет само событие которое вы описываете. Проданный товар, купленные запчасти, зарплатная ведомость или счет на оплату налогов. Не суть, но само событие предметной области будет на виду, а значит угадывать какой ответ правильный будет не нужно.
                                      Однако даже если ошибка пройдет дальше, то ее будет проще локализовать и исправить поскольку у нас будет несколько фактических показателей которые не сходятся. Например у нас на складе излишки сигарет с ментолом и нехватка денег в кассе. Значит мы можем предположить что мы забыли оформить какую-то закупку сигарет. Начинаем поднимать закупки. Документы, поставщиков, все операции связанные с ментоловыми сигаретами и оказывается что мы ошиблись, с ментоловыми сигаретами все в порядке, а потерялась накладная на вишневые сигареты. Просто товаровед посчитала что в кассовой зоне пересортица и перебросила часть ментоловых сигарет на счет вишневых поскольку вишневых по факту продавалось больше чем было в базе. (Реальный случай).
                                      В одиночной записи мы бы не смогли так просто отследить эту связь, ведь у нас не было бы проводки которая затрагивала бы и ментоловые и вишневые сигареты.

                                      Случай с пересортицей был сложным. А вот случай когда реально потерялась накладная именно на ментоловые, и мы сразу подняли все движения по ментоловым и увидели что был заказ на такую сумму, что не пляшут и деньги и сигареты и стали звонить поставщику и т.п. — более частый. Без двойной записи пришлось бы перебирать все операции в поисках проблемной.

                                      ПС: вообще поиск нестыковок в большом сложном балансе, когда все очевидные вещи уже исправлены автоматически за счет двойной записи, а ошибка не одна, а множество мелких — очень сложное занятие сродни искусству.
                                    +2
                                    Ошибаетесь.
                                    Я понимаю что статья длинная и легко потерять нить или прочитать через строчку, так что остановлюсь на том моменте еще раз.
                                    Минимальная операция в двойной записи это проводка.
                                    У проводке грубо говоря есть три поля — два поля указывают номера счетов где отражаются изменения, третье поле это сумма изменения.
                                    Эти счета РАЗНЫЕ, а сумма одна. Поэтому сделать так чтобы в одном месте 10 а в другом 100 — не получится. В бумажном виде такое изредка случалось, но с появлением в бухгалтерии компьютеров — полностью исчезло.

                                    Давайте рассмотрим случай который я наблюдал пару дней назад.
                                    Две девушки открыли стартап.
                                    Они делают бижутерию ручной работы.
                                    Одна из них закупала материалы. Делала несколько закупок в разных местах. Плюс у нее были некоторые материалы закупленные еще до того как они стали работать вместе, и они договорились что она вносит эти материалы в общак, и берет за них оговоренную стоимость из кассы. Девочки пользуются простым, тупым учетом — у них есть несколько табличек примерно аналогичных счетам баланса (материалы, деньги в кассе, товар на складе и т.п.) изменения в которых они ведут одиночными записями. Когда девочка записывала эти операции в кассу она по ошибке указала стоимость принесенного ей товара не как расход из кассы (выплату ей стоимости товара) а как доход. А поскольку она делала другие закупки, покупала из своих денег а потом забирала из кассы разницу, то ошибка не была замечена сразу, она взяла денег за вычетом двойной стоимости принесенных ею материалов.
                                    Ошибка всплыла только потому что ее партнерша перечитывала все записи внимательно и дотошно и увидела что тут явно ошибка.
                                    Если бы у них использовалась двойная запись, то ей нужно было бы записать не только факт ухода или прихода денег, но и вторую запись за что эти деньги пришли или на что были потрачены. В данном случае должны были бы увеличится суммы в таблице «материалы на складе». В принципе в автоматическом варианте тут ошибки не могло бы быть просто потому что раз материалы актив, и он увеличился а второй записью идет касса которая тоже актив, то она может только уменьшится. Но если даже опустить эту проверку и записать вручную в таблицу неверную запись — мы нарушим баланс. Активные счета сразу перестанут совпадать с пассивными, ведь у нас одной операцией увеличилось сразу два активных счета.

                                    Ну и еще раз — двойная запись не записывает одну операцию дважды. Она просто записывает связанные вещи как единую запись. Примерный аналог, чтобы понять в чем она двойная — банковские счета (на самом деле там все так же — активы, пассивы, дебет и кредит, но это уже в следующих частях). Если мы переводим деньги с одного счета на другой счет в том же банке, то при одиночной записи мы сделаем две записи — одной записью мы уменьшим счет источника, второй записью увеличим счет получателя. При двойной записи мы просто запишем — взять столько-то денег с такого-то счета и положить на такой-то. Одной, ДВОЙНОЙ записью. Согласитесь что так ошибиться сложнее.
                                      0

                                      Пока я вижу, что вы описываете ситуацию, что реальные суммы есть только в одном объекте — в проводке. То, что на счету — это кеширование, счета вообще бы могли ничего не хранить и считать свой баланс каждый раз при доступе к нему, последовательно применяя все проводки. Я не понимаю, почему такой кеш надо как-то по-особому называть, да еще и таким сбивающем с толку названием.


                                      Если мы переводим деньги с одного счета на другой счет в том же банке, то при одиночной записи мы сделаем две записи — одной записью мы уменьшим счет источника, второй записью увеличим счет получателя. При двойной записи мы просто запишем — взять столько-то денег с такого-то счета и положить на такой-то. Одной, ДВОЙНОЙ записью. Согласитесь что так ошибиться сложнее.

                                      Не знаю, кто придумал всю эту терминологию с одиночными/двойными записями, но она ужасна. А если это легаси, тянущееся с бумажных времен, то непонятно, почему его давно не переименовали во что-то более интуитивно понятное.

                                        0
                                        Пока я вижу, что вы описываете ситуацию, что реальные суммы есть только в одном объекте — в проводке. То, что на счету — это кеширование, счета вообще бы могли ничего не хранить и считать свой баланс каждый раз при доступе к нему, последовательно применяя все проводки. Я не понимаю, почему такой кеш надо как-то по-особому называть, да еще и таким сбивающем с толку названием.

                                        Я вам больше скажу. У вас нет никакого кошелька, и нет никаких банковских счетов, нет кредитных и дебетовых карточек, нет счетов в вебмани. Ничего этого нет. Это просто кеш. А на самом деле существуют только транзакции которые касаются данных сущностей. Непонятно зачем столько всего придумали когда реальные деньги есть только в операциях. Вот вам подарили первый кошелек в десять лет? Вот с тех пор все приходы и расходы посчитайте, и будете знать сколько денег в кошельке…
                                          0

                                          Да, это будет единственно гарантированно ТОЧНЫЙ способ узнать, сколько там денег. Кстати, в криптовалютах вроде такой способ сейчас и применяется — в самом деле, не можете же вы доверять тому, что сказал Вася о содержимом своего кошелька.

                                            0
                                            Такой, да не такой. Там как раз обычно промежуточные значения материализуются в промежуточных транзакциях, так что если у вас блокчейн доверенный (раньше проверили), то все дерево просматривать необязательно — хватит последнего места где встречается нужный выход. Ну и другие костыли, чтобы не слишком терять производительность. Но такой подход там не от хорошей жизни. Как минимум там заранее неизвестен список всех «счетов». Ну и другие особенности.
                                              0

                                              Я же не настаиванию на неиспользовании кеша. Разумеется, он нужен. Однако нужно понимать, что это всего лишь кеш, его можно в любой момент забыть и посчитать заново. Да, это может быть накладно, но ведь нас в первую очередь интересует корректность, а во вторую производительность.


                                              Материализация транзакции — это кеш. Использовать его или нет — дело желания. Конечно, в повседневности его используют, но это не обязательно.


                                              Как минимум там заранее неизвестен список всех «счетов»

                                              Не понял, как это влияет. У нас первичны операции, т.е. проводки. Вы и в "обычном" случае их список заранее не знаете.

                                      0
                                      На самом деле, на уровне БД создаётся одна запись в таблице транзакций: с полями: дата, сумма, счётДт, счётКт, описание. Для того чтобы получить баланс того или иного счёта нам надо просто отобрать все транзакции, где этот счёт фигурирует в Кт или Дт. Из проверок только проверить, что оба счёта указаны, ну и ряд бизнес-проверок (чтобы проводка имела смысл, чтобы не выпрыгивала из временного периода итд)
                                      Такая подход позволяет вам в любой момент времени изменить как сумму, дату транзакции, так и сами счета между которыми осуществялется эта транзакция, без боязни, что вы нарушите целостность итогового баланса (т.е. что сальдо активных счетов всегда будет равно сальдо Пассивов)
                                        0
                                        Есть такой подход.
                                        Но у него есть несколько недостатков.
                                        Главный минус вашего подхода это «можно изменить не опасаясь нарушить». Это ошибка.
                                        Изменяя что-то задним числом вы рискуете нарушить целостность проводок которые были после того, ведь ваше изменение могло повлиять на условия при которых последующие проводки не имели бы смысла. Так что нет, это не преимущество а недостаток. Лучше отменять все что было после измененной записи и осуществлять изменения заново.
                                        Это называется «отмена проведения документа» и «перепроведение документа» в терминах 1С, да и в других системах вроде тоже.
                                        Так что «изменять задним числом» я вам не советую даже рассматривать.
                                        А вот с тем чтобы складывать все проводки это да, идея верная.
                                        Но у нее есть один жЫрный минус который делает ее в чистом виде не рабочей:
                                        Такие операции слишком накладны. Вместо одного SELECT который вернет нам множество интересующих нас счетов отбирая нужные данные по условию используя индекс мы будем выполнять множество групповых операций проходя по всей базе.
                                        В больших объемах это не просто накладно а неподъемно по производительности.
                                        Вместе с тем если мы отказываемся от «изменить задним числом», а мы от него и так отказались, то можно к проводке добавить еще два поля — значение дебетуемого счета после проводки и значение кредитуемого счета после проводки.
                                        В таком виде мы можем сразу получать состояние счетов на разную дату (сортировка по дате и условие что меньше или равно искомой дате), избавляемся от дополнительной таблицы, легко считаем обороты по счету, изменения за период и т.п.
                                          0
                                          Изменяя что-то задним числом вы рискуете нарушить целостность проводок которые были после того, ведь ваше изменение могло повлиять на условия при которых последующие проводки не имели бы смысла

                                          Я говорил про нарушение целостности итогового баланса. Вопрос же права пользователя вносить сумятицу в его собственную бухгалтерию это скорее вопрос дизайна системы.
                                          Такие операции слишком накладны

                                          Не буду спорить. Всё зависит от масштаба и процесса. Мы используем двойной учёт для управленческих операций и у нас вопрос внесения изменений в большей степени актуален, чем вопрос производительности.
                                            0
                                            Я не против внесения изменений задним числом. Иногда конечно лучше сторно, но если это не регламентированный учет и легитимность правок решена на другом уровне абстракции, то пусть себе правят. Я о другом. Не стоит давать пользователю возможность отстрелить себе ногу. Максимум тестов которые могут быть, должны быть. Соответственно я против того чтобы были правки «по тихому», не трогая последующие транзакции.
                                            В очень простой логике это может сработать, но по мере роста объем логики для проверки таких вот изменений чтобы они не вызвали лавину проблем вам придется писать код который будет проходить все транзакции (не только проводки но и документы их вызвавшие) которые были после исправленной, и проверять что они будут нормально проходить в условиях изменений. А в таком случае смысл «тихой» правки исчезает. Вы все равно проходите всех «потомков».
                                              +1

                                              Смысл "тихой" правки — в возможности длительных исправлений. Скажем, отдел неделю расследует что натворили предшественники и исправляет ошибки — так что, все это держать в памяти?


                                              Случается-то всякое, вряд ли разумно запрещать исправлять найденную ошибку только из-за того что это исправление выявляет еще три. Скажем, в базе записано что продали 600 слонов — а тут выяснилось, что этих слонов у нас на складе никогда не было. Что лучше: запретить вносить в базу поправку об отсутствии слонов на складе пока не выяснится чего же на самом деле продали — или внести информацию об отсутствии слонов, сохранить — и подсветить красным продажу того, чего не существовало?

                                                0
                                                Да, со скрипом соглашусь, что такой подход имеет право на жизнь.
                                                Со скрипом потому что я бы предпочел при проведении правки об отсутствии слонов откатил бы все документы которые не проводятся в новых условиях (накладные на продажу слонов), а оперативную задачу «работаем хоть как-то» закрывал бы внеочередной инвентаризацией и продажей по состоянию из инвентаризации. Но Ваш подход да, имеет свои плюсы в этом случае.
                                                Минус тут вполне существенный — вы не видите реальной картины. Что реально у вас не пляшет, ведь вслед за отменой проведения продаж у нас начнут не плясать деньги и т.п., и по результатам вполне может оказаться что на самом деле те слоны все-таки были, но получены были на день раньше или еще каким образом.
                                                Разбор работы «папиредныков» лучше начинать с инвентаризации. И уже когда есть инвентаризация, то тебе не важно что было раньше. От инвентаризации до инвентаризации склад зависит только от правильности текущего учета (не только склад конечно). А значит проводить частичное исправление которое тянет за собой кучу красного нет смысла.
                                                Но в целом — ок, согласен, возможен случай когда мы живем с красным.
                                                Но все равно предвычисления счетов лучше делать. Отвечу ниже об этом.
                                            0

                                            Дополнительные поля с балансом — это лишние трудности по их поддержке в актуальном состоянии. Лучше уж вот так:


                                            create view dbo.Баланс1 with schemabinding as
                                            select Дебет AS Счет, SUM(Сумма) AS Баланс, COUNT_BIG(*) AS К
                                            from dbo.Проводки
                                            group by Дебет
                                            go
                                            create view dbo.Баланс2 with schemabinding as
                                            select Кредит AS Счет, SUM(Сумма) AS Баланс, COUNT_BIG(*) AS К
                                            from dbo.Проводки
                                            group by Кредит
                                            go
                                            create unique clustered index КЛЮЧ_Баланс1 on dbo.Баланс1(Счет)
                                            create unique clustered index КЛЮЧ_Баланс2 on dbo.Баланс2(Счет)
                                            go
                                            create view dbo.СчетаСБалансом as
                                            select Счета.*, 
                                                ISNULL(Баланс1.Баланс, 0) - ISNULL(Баланс2.Баланс, 0) AS Баланс
                                            from Счета
                                            left join Баланс1 with(noexpand) on Счета.ИД = Баланс1.Счет
                                            left join Баланс2 with(noexpand) on Счета.ИД = Баланс2.Счет
                                            go

                                            Извиняюсь за русский язык перед теми кому он режет глаза, но мне лень искать правильный перевод терминов на английский

                                              +1
                                              Вьювы, жоины, агрегация, сложные индексы, и все это для того чтобы уйти от денормализации? Зачем? Вот зачем так утяжелять логику?
                                              «потому что так правильно»? Нет, не правильно.
                                              Сначала мы делаем нормализацию, потом ПРИ НЕОБХОДИМОСТИ делаем денормализацию, и это нормально.
                                              Поддержка такой денормализации ничуть не сложна.
                                              Если мы делаем изменение старых проводок, то у нас есть сумма на которую было изменение. Оно касается ВСЕХ состояний счетов (дебетуемого и кредитуемого) ПОСЛЕ даты изменения. Так что просто делаем один апдейт (или два, если мы делали в лоб как я писал — один для кредита, другой для дебета), с одним условием, который просто добавляет всем сумму изменения (если сумма отрицательная, то уменьшает). Всё.
                                                0

                                                В чем вы видите утяжеление логики? И где тут сложные индексы?

                                                  0
                                                  Вот это вот всё, что вы нагородили это утяжеление логики. Вынос логики в базу это тоже не лучший паттерн. Но этот холивар не по теме статьи.
                                                  Я не уверен насколько адекватны по скорости будут индексы у вьювов с агрегирующими функциями. И не хочу этого узнавать.
                                                  Все это делается 1-2 апдейтами в тех редких случаях когда надо править логику.
                                                  Я соглашусь вынести состояния счетов из проводок в отдельную таблицу, со ссылкой на проводку которая к этому состоянию привела, но городить вот такое — я против, да.
                                                  0
                                                  Если мы делаем изменение старых проводок, то у нас есть сумма на которую было изменение.
                                                  Да, сумма есть, и ее нужно записать во все 10 000 последующих проводок.
                                                  Если нужно поправить 10 проводок, то 10 раз перезапишется «пол базы»?
                                                    0
                                                    А в чем проблема? Ну перезапишем десять раз «полбазы» и что? Тут предлагают при каждом просмотре считать всю сумму всех проводок, а вы боитесь разово, при редком изменении сделать один запрос? ОДИН, не пачку. Ну десять изменений, десять запросов. В любом случае нагрузка ниже на порядки.
                                                      0
                                                      1) чтение не запись, тем более для SSD
                                                      2) mayorovp предлагает индексированное представление. Об этом говорит with schemabinding и unique clustered index.
                                                      Индексированное представление автоматически перевычисляется при изменении исходных данных.
                                                      3) не нравится Индексированное view, можно использовать тригеры БД или просто считать итоги в логике и писать в таблицу итогов. (но я не уверен что не потерял какую то вашу суть, почему вы именно так сделали)
                                                        0
                                                        1) чтение совсем не запись, поскольку в реальных кейсах выполняется не в разы, а на порядки чаще. Счет идет реально на порядки, так что некоторое удорожание за счет более дорогой записи — ничтожно. В особенности если учесть тот факт что запись затрагивающая значительное колво строк — исчезающе редкое явление связанное с ошибками учета. Штатная запись затрагивает лишь текущие единицы строк
                                                        2) Я понимаю что у mayorovp речь идет об индексированных данных. Однако я не знаю как конкретно такие сложные индексы поведут себя в различных СУБД. И знать не хочу. Зато я знаю что простое обновление руками будет дешевым и простым. Подумайте еще раз. В идеальном случае, если СУБД идеально решит вторую фундаментальную проблему программирования (инвалидация кеша) — мы получим ровно тоже количество операций записи что и в моем варианте. Вам надо будет обновить все индексы связанные с этим конкретным счетом, и только их. Что я делаю вручную, напрямую указав это в запросе. Вместе с тем далеко не факт что СУБД сможет понять этот факт и не начнет пересчитывать индекс при каждом изменении а не только при тех которые нужны.
                                                        3) Да, я храню предвычисленные значения на каждый момент времени в отдельной таблице итогов и обновляю ее в логике. Да, я не люблю нагружать логикой базу, и по возможности избегаю вьювов и тригеров там где этого можно избежать без существенных потерь в производительности или архитектурных сложностей. Но дело не в этом. Нить данной дискуссии началась на том что кто-то здесь предложил отказаться от таблицы счетов вообще и хранить всю информацию только в проводках, а значения счетов вычислять каждый раз суммируя. Я предложил вариант который тоже будет с одной таблицей, но без чрезмерных вычислений — добавление результирующих значений прямо в таблицу проводки. mayorovp на это предложил вместо денормализации сделать вьюв…
                                                          +1
                                                          вторую фундаментальную проблему программирования (инвалидация кеша)
                                                          Подскажите, какие первая и третья фундаментальные проблемы программирования? А четвертая и пятая есть? Я не троллю.
                                                            +1
                                                            Классика:
                                                            В программировании существует лишь два характерных затруднения: инвалидация кеша, наименование сущностей и ошибка на единицу
                                                            0
                                                            Вместе с тем далеко не факт что СУБД сможет понять этот факт и не начнет пересчитывать индекс при каждом изменении а не только при тех которые нужны.

                                                            Тем не менее, это факт. MS SQL (а я писал используя его синтаксис) просто не позволит вам создать такой индекс который не cможет потом эффективно поддерживать при обновлениях.

                                                              0
                                                              А Мускул? А SQLite3? А…
                                                              Ну это же не серьезно. Ну вот честно.
                                                              Есть готовое решение в одну строку, которое использует минимальный синтаксис и заведется даже на СУБД на файлах, при этом имеет идеальную эффективность.
                                                              Вы предлагаете заменить это решение на другое. Новое решение работает только на некоторых СУБД. Оно занимает экран кода. При этом ПРЕДПОЛОЖИТЕЛЬНО может достигать почти такую же эффективность как у первого решения. Плюсы? Плюс только один — «потому что могу!».
                                                              И да ваш вариант даже чисто теоретически не сможет быть равным по скорости с моим. Как внутри работает индекс? Ведь любая СУБД работает с файлами, в которых существуют таблицы, а индексы это просто особая форма таблицы (да, деревья тоже выглядят как таблица). Фактически добавляя индекс мы создаем некую служебную таблицу которая обновляется по определенным правилам. Чтобы понять что его нужно обновлять СУБД вешает некий триггер (не совсем, но суть похожая) на те таблицы что участвуют в индексе. При изменении тех таблиц запускается наш триггер который проверяет должен ли текущий запрос повлиять на данные которые отражены в индексе, потом определяет какие именно поля он должен затронуть, и изменяет индекс (если нужно). Другого варианта особо то и нет. В вашем случае если даже допустить что СУБД сможет построить идеальное условие и идеально определить какие записи в этой служебной таблице индекса (полный аналог моей кстати), то все равно она будет выполнять этот анализ при КАЖДОМ изменяющем запросе. Это абсолютно принебрежимый оверхед, но он есть, да.
                                                                0
                                                                Интересно, вы на каком языке пишите, со сборкой мусора? У вас между запросами от UI приложение умирает, или есть какое то «статическое» поле, которое содержит данные между запросами?
                                                                У вас случайно нет тяжелых структур в памяти которые приходится создавать/обновлять при каждом запросе?
                                                                Как вы поддерживаете иерархию итогов по счетам/субсчетам и по каталогу товаров с группами?
                                                                  0
                                                                  А как все эти вопросы влияют на обсуждаемую тему и тем более на основную тему данной статьи?)
                                                                  Я ведь не затрагиваю вопрос того что вьюв mayorovp не особо красив, равно как и не спрашиваю цвет ваших глаз :)
                                                                  Единичный апдейт вызываемый раз в день а то и раз в пару месяцев будет много проще и быстрее чем вьюв на полстраницы вызываемый постоянно по тысяче раз за один отчет. Всё.
                                                                  0

                                                                  А теперь сравните затраты на чтение данных из базы.

                                                                    0
                                                                    Сравнить с чем? У меня они на несколько порядков меньше чем у вас.
                                                                      0

                                                                      Не верю.


                                                                      Вспоминая основную задачу, ради которой все и затевалось — понимание общей картины финансов, предлагаю подумать как будет выполняться запрос "получить текущий баланс по каждому счету".


                                                                      В моем случае это будет merge join трех индексов. Если счета не все, а только часть — то будет два уточняющих nested loops join с выбором конкретного элемента из индексов.


                                                                      А у вас что получится?

                                                                        –1
                                                                        Вы хотите прям живую структуру и живые запросы?
                                                                        Причем универсальную структуру, под основной типовой набор?
                                                                        Ну ок, давайте набросаем. Единственное что — предвидя что мы скатимся на бенчмарк, причем mayorovp будет настаивать на MS SQL — я бы сразу попросил тех кто с ней дружит и имеет среду под это дело — отписаться тут, ибо мне понадобится «адвокат» — не буду я его ставить, настраивать и создавать условия для тестирования. Нет времени, и я уверен в своей правоте, хотя и допускаю что где-то ошибся. Ну и синтаксис редких СУБД знаю плохо, подсказать по тонкостям если что, но вообще я планирую что полностью уложусь в ANSI SQL.
                                                                        Для начала давайте определимся с ТЗ. Предлагаю оставить только самый костяк, без «документов/операций», без описаний самих счетов и т.п. чистая математика. Потом навешаем доп.операции.
                                                                        0) Мы не будем повторяться с общими принципами которые мы уже обсуждали тут
                                                                        1) Предмет разработки
                                                                        1.1) Структура данных и набор операций к ней (с структурой запросов) отражающая «баланс» (а именно набор состояний «счетов», характеризующихся ИД счета, тип (пассивный/активный) и текущим значением на заданный момент времени.
                                                                        1.2) Также данная структура должна предоставлять доступ к набору проводок которые вносят изменения в наш баланс. Проводка классическая — ИД дебетуемого счета, ИД кредитуемого, сумма операции, таймштамп операции.
                                                                        1.3) любая информация подразумевающаяся доступной из 1.1 и 1.2 должна быть теоретически доступна в нашей реализации
                                                                        2) Пожелания по окружению
                                                                        2.1) Все пожелания являются рекомендательными, и не соблюдение оных не повод для дисквалификации решения
                                                                        2.2) Решение желательно должно быть кроссплатформенным, а именно по возможности иметь минимальную зависимость от конкретной ОС, СУБД и т.п. Отход от этого пожелания возможен, но желательно чтобы был какой-то дополнительный выигрыш от этого
                                                                        2.3) Решение должно предусматривать проверку корректности проводки на момент ее осуществления (проверку что активный счет не свалился в минус а пассивный в плюс)
                                                                        2.4) Решение подразумевает сырые запросы, без ORM, хотя возможность использования ORM будет важным плюсом
                                                                        2.5) Решение предусматривает указание всех необходимых индексов
                                                                        3) Список обязательных АПИ для которых необходимо прописать схему получения или отражения информации
                                                                        3.1) Приоритетные методы требующие наибольшей производительности
                                                                        3.1.1) Получение состояний всех счетов на текущую дату
                                                                        3.1.2) Получение состояний всех счетов на произвольную дату
                                                                        3.1.3) Получение текущего состояния одного конкретного счета
                                                                        3.1.4) Получение состояния одного конкретного счета на конкретный таймштамп
                                                                        3.1.5) Добавление проводки с текущим таймштампом (будет самой последней, автоинкрементальный ид проводки используем как неявное время)
                                                                        3.1.6) Получение состояний счетов удовлетворяющих условию — на конкретную дату
                                                                        3.1.7) Проверка факта баланса (сумма всех счетов равна нулю)
                                                                        3.2) Значимые методы, требующие хорошей производительности, но не самые частые
                                                                        3.2.1) Добавление проводки «задним числом», т.е. добавление проводки не с текущим таймштампом, а с произвольным
                                                                        3.2.2) Получение изменений всех счетов за заданный период (всех, как кредитовых, так и дебетовых в сумме)
                                                                        3.2.3) Получение изменений всех счетов удовлетворяющих определенному условию — за заданный период
                                                                        3.2.4) Получение дебетовых оборотов всех счетов за указанный период
                                                                        3.2.5) Получение кредитовых оборотов всех счетов за указанный период
                                                                        3.2.6) Получение общих оборотов за период для конкретного счета
                                                                        3.2.7) Получение дебетовых оборотов за период для конкретного счета
                                                                        3.2.8) Получение кредитовых оборотов за период для конкретного счета
                                                                        3.3) Дополнительные методы, которые просто должны быть выполнимы, но их производительность не имеет значения
                                                                        3.3.1) Полная проверка целостности, подтверждающая что текущие значения счетов напрямую выходят из наших проводок (нет разбалансировки). Проверка должна быть реализованна даже если мы доверяем часть работы СУБД
                                                                        3.3.2) Проверка того, что все проводки были «законными» на любой момент времени (на случай изменения задним числом — того самого «тихого» варианта, ну или возможных технических сбоев)

                                                                        Вроде ничего не забыл? Подходит такое ТЗ? Есть пожелания, дополнения?
                                                                          –1
                                                                          UPD: Вспомнилось, добавить еще:
                                                                          2.6) Если задача не решается одним лишь запросом, то написать код обвязки на псевдокоде или одном из языков программирования
                                                                          3.2.9) Список всех проводок по конкретному счету за период
                                                                          3.2.10) Список всех значений конкретного счета за период (в виде таймштамп- значение)
                                                    +1
                                                    Так что «изменять задним числом» я вам не советую даже рассматривать.
                                                    На самом деле тут есть важный момент, который вы подразумеваете, который нигде не упомянули явно, но который принципиально важен.

                                                    Дело в том, что есть бухгалтерия и «бухгалтерия за 10000 рублёв раз в неделю». Последнее — это особый жанр, собственно к бухгалтерии имеющий мало отношения. Это, грубо говоря, когда вы получаете раз в неделю кучку проводок (но не все!) и задание — «изобразить что-нибудь для налоговой».

                                                    Вот тут и изменение сумм задним числом и перенос дат транзакций (чтобы счета «посредине» не становились отрицательными) и многое другое — невероятно востребовано и полезно.

                                                    Но к тому, что обычные люди, не «мелкие предприниматели на карман» понимают под словом «бухгалтерия» это имеет мало отношения.
                                                      0
                                                      А потом через полгода всплывает накладная на полмиллиона на которую ты налоговую накладную в базу не занес. Ага. Видели.
                                                      Приходящий бухгалтер хорош когда на предприятии есть кто-то, кто и без бухгалтера следит за фин.дисциплиной. Или внятная управленческая система учета которая делает это автоматически. А иначе — хаос.
                                                      Но я говорю о другом.
                                                      Исправления задним числом нужны, без них никуда. Сторно это мучение.
                                                      Но плохо как раз делать исправления не проверив что оно не покалечило другие операции.
                                                  +1
                                                  Везде говорят, что для минимизации ошибок нужно избегать дублирования информации,


                                                  В этом месте всем передает привет CRC, ECC, и прочие способы избыточно кодировать информацию, что бы было легко обнаруживать ошибки, корректировать и так далее.
                                                    –1

                                                    Избыточное кодирование — это все-таки не просто дублирование. Помимо собственно дополнительных данных важное значение имеет алгоритм, примешивающий их к исходным данным. Вот, недавно на хабре была прекрасная статья о кодах Рида-Соломона. Представте, на примере из этой статьи, что для вектора из 3-й чисел мы хотим найти 3 избыточных значение. Казалось бы, чего проще — просто продублировать исходные? Но что будет, если в получившемся векторе [A, B, C, A, B, C] мы потеряем оба элемента A? Мы ведь можем потерять как минимум любые 2 элемента. Их будет не восстановить. А алгоритм Рида-Соломона такой ситуации не допускает.


                                                    Так что сравнивать дублирование и избыточное кодирование некорректно. Первое плохо. Второе хорошо.

                                                      0
                                                      Вы забыли народную мудрость — если несешь чушь, то главное не расплескать.
                                                      Извините за грубость, но это уже просто троллинг какой-то. Я наверное уже двадцатый раз повторяю — В ДВОЙНОЙ ЗАПИСИ НЕТ НИКАКОЙ ИЗБЫТОЧНОЙ ИНФОРМАЦИИ.
                                                      Двойная запись требует писать всю информацию. Один раз, но всю.

                                                      В супермаркете нам всем дают фискальный чек.
                                                      В фискальном чеке есть информация о продавце (том кто получил деньги) и о сумме которую он от нас получил. Это одинарная запись, в ней есть информация куда пришли деньги, и сколько этих денег.
                                                      Также в нем написано допустим «молоко — 1 штука, 5 рублей» и «хлеб — 2 штуки, 10 рублей». Это тоже одинарная запись, вернее две одинарные записи — со счета «склад Рога и Копыта, молоко на складе» ушли 5 рублей, а куда неизвестно, и «со счета хлеб на складе Рога и Копыта» ушло 10 рублей, а куда неизвестно.
                                                      Вы приходите домой и записываете себе в тетрадку — потратил в магазине 15 рублей. Это одинарная запись, ибо известно откуда ушли деньги (кошелек), и сколько их, но неизвестно кому они ушли. Также вы записываете «купил молоко за 5 рублей». Это одинарная запись — увеличение счета «молоко в холодильнике» на 5 рублей. Ну и третья одинарная запись «хлеб в хлебнице» — плюс десять рублей.
                                                      Тут у нас записывается по одну счету денег, и по одному счету товаров.
                                                      По сути мы получили шесть одиночных записей. Но сопоставить их между собой сложно Они не связаны воедино. И когда их будет тысяча, и потом мы увидим ошибку, то отследить ее происхождение будет невозможно.
                                                      А теперь представьте себе не чек, а накладную. Стандартную, какими обмениваются юрлица. В накладной есть продавец и покупатель, ну и хлеб с молоком и их цены.
                                                      Тут уже прямая связь — хлеб из магазина перекочевал в хлебницу, а молоко из магазина перекочевало в холодильник. Ну и до кучи платежку добавим, где есть номер счета плательщика и номер счета получателя. И если вдруг у нас не хватит хлеба в холодильнике то мы сразу подумаем — либо мы не записали операцию когда он у нас был потрачен, либо что-то не то с операцией когда он у нас поступил, и сразу окажется что мы забыли его на кассе.
                                                      Информации во втором случае больше не стало, информации столько-же, но в первом случае это шесть одиночных записей, а во втором — три двойных. И сразу проще найти ошибки.
                                                        0

                                                        Я не понимаю, зачем вам в вашем примере знать что-о о счетах продавца (оставим в стороне вопрос, вообще позволит ли продавец вам знать эту информацию)? Какая разница, молоко со склада пришло, с молокозавода или напрямую из-под коровы? Что то вы усложняете. У нас есть 2 операции:


                                                        • +молоко в холодильнике, эквивалент 5 рублей — -5 рублей в магазине "Рога и копыта"
                                                        • +хлеб в холодильнике, эквивалент 10 рублей — -10 рублей в магазине "Рога и копыта"

                                                        При желании можете у этих двух операций хранить ссылку на чек, что вам дали в магазине, таким образом они будут объединены. В чем тут запутаться, я не пойму. А вот в вашем описании действительно черт ногу сломит.


                                                        Кстати, не очень понятно, зачем продукты в деньгах учитывать и что будет, если завтра я продам молоко, но по 10 рублей...

                                                          +1

                                                          Это не две операции, а две пары связанных операций по разным счетам учёта на равные по модулю, но противоположные по сумме. Запутаться можно если перепутать суммы или знаки. Чтобы этого не было и делается двойная запись (и для холодильника, и для кошелька) с обязательным условием равентства по модулю со сверкой итогового баланса и желательной сквозной ссылкой на чек или на вторую запись, для упрощения поиска ошибки, когда она обнаружится.

                                                            –1

                                                            Нет, это именно 2 операции. Под операцией а подразумеваю перенос денег с одного места (счета, если вам так понятнее) в другое, возможно, с трансформацией (деньги -> молоко, деньги -> хлеб).




                                                            • Перепутать знаки
                                                            • Перепутать модули
                                                            • Забыть сделать вторую операцию

                                                            Многовато что-то случаев, когда можно что-то сделать не так против железобетонной одной операции, с одной суммой и одним знаком (определяющем, куда идут деньги (причем именно сами деньги, а не их эквивалент в виде молока или хлеба) — к нам или от нас), где просто нечего путать. Можно лишь ввести неправильные данные, ну так от этого никакая система не застрахована, она не может понять, какие данные правильные, а какие нет. Если вы ей говорите, что купили по 100 рублей, хотя стоило 10 — у вас в любом случае будут отражены 100 рублей, а не правильные 10.

                                                              0

                                                              Я смотрю то, что вы написали: "+молоко в холодильнике, эквивалент 5 рублей — -5 рублей в магазине "Рога и копыта"":
                                                              два счёта, (холодильник и кошелек), по одной операции на каждый с равным модулем и противоположным знаком — типичная двойная запись. Суть двойной записи в том, что каждая операция проходит по двум счетам одновременно с одной суммой.

                                                        +1
                                                        Избыточное кодирование — это все-таки не просто дублирование.


                                                        RAID 1 — просо дублирование.
                                                          0

                                                          Дублирование, по сути — простейший вариант избыточного кодирования.

                                                            –1

                                                            Не понимаю, что вы хотите сказать. Да, RAID 1 — просто дублирование, поэтому его надежность меньше, чем у методов с избыточным кодированием. Тут на хабре недавно была статья, где говорилось об этом, и в частности для RAID делался парадоксальный вывод, что надежность хранения данных тем меньше, чем больше дисков.

                                                              +1
                                                              хочу сказать, что ваш начальный тезис — ошибочен.

                                                              Везде говорят, что для минимизации ошибок нужно избегать дублирования информации,


                                                              1. непонятно что такое «везде»
                                                              2. вот я привел несколько примеров, когда наоборот — избыточная информация позволяет не только выявлять ошибки (CRC) но и корректировать их (ECC и прочие), или даже просто примитивное дублирование (RAID 1) повышает надежность хранения информации — то есть, в случае возникновения ошибок на этом уровне, это не приводит к ошибкам далее — используют ту копию, которая осталась целой.

                                                              На статью с парадоксальным выводом хотелось бы ссылку.

                                                              Что же касательно двойной записи в бухгалтерии, то судя по вашим комментариям к этой статье, вы не разобрались, и даже желания разобраться не видно.
                                                        +1
                                                        Двойная запись — это термин из времён бумажной бухгалтерии, когда агрегацию по счетам (само слово «счёт» намекает, что это агрегат каких-то первичных данных) из единой «базы» в виде «амбарной книги» делать было весьма затруднительно, а значит нельзя было контролировать остатки по счетам, особенно в момент проведения операции. Придумали «материализованные вьюхи» в виде карточек счетов с текущим балансом, на которые ссылаются записи в «амбарной книги». Но поскольку в проводке участвует два счёта (откуда-то взяли и куда-то положили), то балансы счетов нужно менять одновременно в двух карточках. Отсюда и «двойная запись». Сейчас это актуально при, например, использовании реальных материализованных представлений, когда СУБД изменяет две записи вьюхи при добавлении проводки в таблицу.
                                                          +2
                                                          > Везде говорят, что для минимизации ошибок нужно избегать дублирования информации

                                                          Правильно говорят. Только двойная запись — это не дублирование информации.
                                                          Бухгалтерия отражает движение материальных ценностей, выраженных в денежных единицах. Любое движение имеет две точки — начало и конец, ушли и пришли, источник и назначение. В обывательской логике привычно думать, что бывают операции, которые имеют одну точку — но это неверно. Точек всегда две и только две. И даже обыватель всегда фиксирует обе точки, только одну из них «держит в уме», и делает вид, что её не существует.
                                                          +5

                                                          Статья читается тяжеловато, в ней излишне упрощено всё что можно и нельзя и вместе с упрощением выкинут смысл бухучета. Эти же упрощения приводят к явно неправильным аналогиям.


                                                          Примерно так:


                                                          1. Аналогия "активные — распоряжаемся, пассивные — не можем распоряжаться" не отражает сути. Например смотрим на амортизацию: в РСБУ и МСФО это же пассивный счет, а "распоряжаться" мы им можем. А вот каким нибудь счетом "Общепроизводственные расходы" (который активный) мы вряд ли можем распорядиться.
                                                          2. А почему пришлось вводить эту аналогию? А потому что цели и принципы бухучета выкинули. Зачем мы вообще считаем эти "счета" и "проводки"? Чтобы бухгалетру было чем заняться? "Понимать общую картину финансов" это и звучит неопределённо и, если уж честно, то бухучет часто скрывает ключевые показатели "общей картины". И, да, упомянутые забалансовые счета, как раз один из компромиссов можду "учесть" и "не укладывается в модель". Потому что там есть например что-нибудь типа "товары на реализации", которые как бы и не наши, но если мы их потеряем, то платить придётся.
                                                            В современном мире у бухучета дофига смысловой нагрузки, конечно, это и "стандартный язык" и учет всякой ереси и фискальные учеты, но, насколько я понимаю, главная цель бухучета — посчитать финрез и объяснить из чего он сложился. Мы заработали или угорели? Нам вообще есть из чего дивиденды платить? А из чего складывается финрез?
                                                          3. Но чтобы учет был учетом, а не фантазией фаундера стартапа, нужны принципы.
                                                            • Непрерывность (мы не можем пропустить годик и сделать вид что всё ОК, остатки на конец года и на начало следующего — равны),
                                                            • объективность (все записи должны подтверждаться бумажкой),
                                                            • своевременность (его назвают принцип "начисления", если сделка заключена в январе, то и проводки в январе),
                                                            • единая "единица измерения" — деньги, причем в одной валюте. На самом деле принципов больше, но я их не помню :)
                                                          4. Ага, у нас есть цели и принципы-правила. А вот теперь из принципов-правил мы приходим к инструментам. Из того, что мы считаем "финрез" мы получаем формулу ФинРез=Наше-НеНаше, или если перенести, то Наше=НеНаше+Финрез. А теперь Наше назовём активы, а НеНаше+Финрез — пассивы. Осталось ввести правило двойной записи, т.е. у нас проводки могут быть только такие что меняется одинаково пассив и актив, либо внутри пассива и актива "переносится". Осталось назвать "плюс" по активам "Дебетом", по пассивам "Кредитом" (и наоборот).
                                                          5. А дальше надо построить систему счетов и допустимых проводок, которые будут строить наш учет. Тут уже придётся продумать, как сделать такие счета, чтобы учитывать, например, оборудование, которое куплено явно не на один год так, чтобы одновременно знать сколько оно стоило, сколько оно стоит, и если считать, что затраты на это оборудование должны "отбиться" за 5 лет, то насколько эти затраты уже "отбились". Здесь, кстати, если аккуратно разбирать вопрос, то становится абсолютно понятно, что амортизация и срок службы оборудования вещи вообще говоря слабо связанные. Аналогично надо придумать схему проводок и счетов для отражения, например, товара на складе и проводок при его покупке (чтобы отразить финрез). А чтобы бухучет одной организации можно было сравнить с другим, появились стандарты учета (РСБУ, МСФО, GAAP), которые состоят как из "паттернов", так и из конкретных требований по использованию "паттернов".

                                                          Дальше. Два счета в проводке — это конечно хорошо, но почему "три счета слишком затруднит контроль правильности"? Да хоть 8, если в сумме по дебету и кредиту одинаково. Это весьма синтетическое ограничение, которое может быть полезно (например, появляется возможность оперировать показателем "обороты между счетами"), а может быть очень неудобно. И в этом же месте можно ввести название: часть проводки по одному счету по одной "стороне" (дебет или кредит) с суммой — корреспонденция или в крайнем случае "полупроводка".
                                                          Вообще есть нюанс, что принцип двойной записи, как ни странно, в бумажном виде это скорее три записи, чем две ("главная книга" и суммы в дебет и в кредит), а "двойная" скорее относится к тому, что у проводки есть 2 стороны. В компьютерном мире, конечно, записей может быть как одна, так и много.


                                                          Проводки одного документа должны находиться в одной транзакции СУБД — почему? Про одну проводку вопросов нет — она должна быть в одной транзакции. Причем в большинстве систем проводка это относительно сложная сущность которая отражается в несколько таблиц. А почему все проводки документа должны (вот так вот безаппеляционно) быть в одной транзакции СУБД? А как быть если в накладной 20 слонов, а у нас вместо пары слонов жирафы у забора дерево обгладывают или еще что-то подобное? Ситуаций в учете много и вот так железобетонно говорить вешать учетные принципы на некие "транзакции СУБД" неправильно.


                                                          Самое смешное, что всё это разжёвано и пережёвано в куче книг, статей и курсов. На книжку по основам бухучета у среднего программиста, который (для примера) разобрался, как внутри работает git или даже может написать неблокирующий стек и может вспомнить все паттерны GoF, уйдет 2-4 часа, если не начинать укуриваться деталями. За столько же времени на пальцах и с коньяком объяснит суть учета хороший замглавбух (главбух слишком усложнит, рядовой не объяснит).

                                                            –1
                                                            Спасибо за объемный комментарий. Давайте обсудим.
                                                            Аналогия «активные — распоряжаемся, пассивные — не можем распоряжаться» не отражает сути.

                                                            В статье их несколько. Даже Ржевского я не случайно упомянул, и отдельно привел шпаргалку с тем что куда относится. На самом деле дать «правильное» определение бесполезно. Подавляющее большинство полноценных бухгалтеров (я имею ввиду главного или единственного а не «участкового») сути не понимают, а работают исключительно за счет того что у них есть регламентированный план счетов, и в нем все расписано. Помнят какие-то ассоциации, но именно самую суть не улавливают и как только отходишь от регламентированного и можешь составлять полностью свой план счетов — начинают нести полную ахинею. Недавно слышал от главбуха определение от ликвидности. Мол ликвидное активное, неликвидное пассивное.
                                                            Например смотрим на амортизацию: в РСБУ и МСФО это же пассивный счет, а «распоряжаться» мы им можем.

                                                            Как мы можем распоряжаться амортизацией? Могу копать, могу не копать Могу амортизировать, могу не амортизировать, или амортизировать дольше? Это пассивная форма «распоряжения» сродни «могу вернуть кредит дострочно, могу не вернуть вообще, а могу попросить реструктуризацию на больший срок».
                                                            А вот каким нибудь счетом «Общепроизводственные расходы» (который активный) мы вряд ли можем распорядиться.

                                                            Общепроизводственные расходы это чертов «божественный объект» или папка «неперебранное», и вот так вот им целиком распорядиться сложно. А вот конкретными благами которые туда попали — да, можно распоряжаться. Конечно если мы сдадим секретаршу и ксерокс в аренду, то регламентрированный учет заставит нас перенести эти активы на другой счет, но да, мы можем ими распоряжаться. См. мой пример со счетом «Убытки (украли слонов)» — можно простить, «повесить» на охранника, получить страховку и т.п…
                                                            Ну не получится такие фундаментальные понятия описать коротким и емким определением чтобы человек не понявший самого принципа двойной записи смог его понять. Не получится.
                                                            Понятия активных/пассивных счетов, дебета/кредита и т.п. контринтуитивны, пока не начинаешь мыслить в терминах баланса/проводок.
                                                            И да, еще раз повторюсь — это не академическая статья, и не бай Боже не статья по регламентированному учету. Только про основы. Чтобы ПРИНЦИПЫ люди могли использовать в биллингах, ERP и т.п.
                                                            А почему пришлось вводить эту аналогию? А потому что цели и принципы бухучета выкинули.

                                                            Статья и так вышла огромной, при том что содержит лишь треть от того что я хотел, и все равно находятся те кто не понимает, и нужно еще разжевать. Вводить дискуссию на тему зачем оно нужно? Это Хабр а не Талмуд.)
                                                            И, да, упомянутые забалансовые счета, как раз один из компромиссов можду «учесть» и «не укладывается в модель». Потому что там есть например что-нибудь типа «товары на реализации», которые как бы и не наши, но если мы их потеряем, то платить придётся.

                                                            Забалансовые счета это рудимент, поскольку когда бухучет зарождался еще не было программистов, архитекторов и внятных принципов проектирования.
                                                            Сделайте два счета — пассивный «Обязательства по товарам на реализации» и активный «товары на реализации» (скорее всего субсчетом «товары на складе»). Всё. Двойная запись, баланс, единообразие архитектуры — всё есть. «Нельзя отражать на балансе то что не наше»? Почему? «Потому что оно отражено на чужом балансе». Но почему черт побери? Они мне его отдали, как оно может у него на балансе быть? Да, у него есть актив «реселлер должен нам товар или деньги», но товар у кого? Кто должен быть балансодержателем? Нет, я знаком с регламентированным учетом, но «по совести»? Но даже если и так, даже если мы не хотим раздувать валюту баланса (не вижу причин — единственный случай когда я использовал валюту так это при анализе устойчивости бизнеса и качества структуры активов при анализе потенциальных заемщиков в банке, и там я бы предпочел видеть такие заемные активы как арендованное оборудование и т.п. в балансе а не за балансом, но черт с ним, хотите за балансом — допустим) — сделайте все счета вложенными в «папочки» (на подобии счет/субсчет) и верхними папками сделайте баланс и забаланс. Всё.
                                                            главная цель бухучета — посчитать финрез и объяснить из чего он сложился. Мы заработали или угорели? Нам вообще есть из чего дивиденды платить? А из чего складывается финрез?

                                                            Что собственно и есть «общая картина финансов» :)
                                                            Я не заикаюсь о различных коэффициентах оценки активов, но даже просто если кратенько описать все виды балансовв (просто скопировав статью из википедии), то у многих читателей закипит мозг. Давайте сначала научимся получать нашу «общую картину» а потом уже будем учиться ее правильно читать.
                                                            Но чтобы учет был учетом, а не фантазией фаундера стартапа, нужны принципы

                                                            Стоп, стоп. Это статья не про принципы и бухучет, а лишь про двойную запись. Напишите статью про принципы, киньте ссылку здесь, наверняка кто-то даст вам инвайт за нее. Я еще раз повторюсь — я не ставил себе цель уложить пять лет обучения бухгалтера в одну статью.
                                                            Из того, что мы считаем «финрез» мы получаем формулу ФинРез=Наше-НеНаше, или если перенести, то Наше=НеНаше+Финрез. А теперь Наше назовём активы, а НеНаше+Финрез — пассивы.

                                                            А убытки то наше или ненаше? а финрез это что? А зачем двойная запись если можно одинарной? Ой, а амортизация это финрез или актив, ведь амортизация же наша?.. Это только кажется что так проще, потому что на самом деле у вас уже есть в голове готовая картина и понятные термины, а когда видишь это впервые — будут миллионы вопросов, вы будете разжевывать и получите тоже что у меня, только еще в пять раз больше текста потому что будете рассказывать о принципах (на которых 90% айтишников бросят читать ибо нудятина и капитанство).
                                                            А дальше надо построить систему счетов и допустимых проводок, которые будут строить наш учет. Тут уже придётся продумать, как сделать такие счета, чтобы учитывать, например, оборудование, которое куплено явно не на один год так, чтобы одновременно знать сколько оно стоило, сколько оно стоит, и если считать, что затраты на это оборудование должны «отбиться» за 5 лет, то насколько эти затраты уже «отбились». Здесь, кстати, если аккуратно разбирать вопрос, то становится абсолютно понятно, что амортизация и срок службы оборудования вещи вообще говоря слабо связанные. Аналогично надо придумать схему проводок и счетов для отражения, например, товара на складе и проводок при его покупке (чтобы отразить финрез).

                                                            Вот про это я честно говоря боюсь даже начинать писать. Напишите. Честно.
                                                            Будет интересно всем. Даже если будет сумбурно. Нормального материала по тому как разрабатывать собственный план счетов и собственный регламент — просто нет. Оно размазано по частям по миллионам книг и теорий, но даже плохенькие статьи на эту тему всегда интересны.
                                                            А чтобы бухучет одной организации можно было сравнить с другим, появились стандарты учета (РСБУ, МСФО, GAAP), которые состоят как из «паттернов», так и из конкретных требований по использованию «паттернов».

                                                            Вот не хочу я за регламентированный учет вообще говорить. Он есть. Он такой как есть. Он имеет кучу плюсов, и кучу минусов. По нему написано очень много материала. Бери, изучай, копируй, улучшай. Разве что вскользь упомянуть что сравнивать можно только сделанное по одинаковым стандартам, и для этого существует регламентный учет, но раскрывать тему — фи. Для этого есть нархоз и пять лет учебы.
                                                            Дальше. Два счета в проводке — это конечно хорошо, но почему «три счета слишком затруднит контроль правильности»? Да хоть 8, если в сумме по дебету и кредиту одинаково. Это весьма синтетическое ограничение, которое может быть полезно (например, появляется возможность оперировать показателем «обороты между счетами»), а может быть очень неудобно. И в этом же месте можно ввести название: часть проводки по одному счету по одной «стороне» (дебет или кредит) с суммой — корреспонденция или в крайнем случае «полупроводка».
                                                            Вообще есть нюанс, что принцип двойной записи, как ни странно, в бумажном виде это скорее три записи, чем две («главная книга» и суммы в дебет и в кредит), а «двойная» скорее относится к тому, что у проводки есть 2 стороны. В компьютерном мире, конечно, записей может быть как одна, так и много.

                                                            Меньше чем два нельзя ибо не будет баланса, больше не стоит поскольку усложняет архитектуру. Я не буду углубляться в то почему усложняет ибо это не по теме будет.
                                                            Проводки одного документа должны находиться в одной транзакции СУБД — почему? Про одну проводку вопросов нет — она должна быть в одной транзакции. Причем в большинстве систем проводка это относительно сложная сущность которая отражается в несколько таблиц. А почему все проводки документа должны (вот так вот безаппеляционно) быть в одной транзакции СУБД? А как быть если в накладной 20 слонов, а у нас вместо пары слонов жирафы у забора дерево обгладывают или еще что-то подобное? Ситуаций в учете много и вот так железобетонно говорить вешать учетные принципы на некие «транзакции СУБД» неправильно.

                                                            Нет, и не может быть никаких ситуаций в которых можно «провести» заведомо неверный документ (неверный с точки зрения текущего учета). Если у нас вместо 20 слонов оказывается 18 слонов и два жирафа, а жирафов у нас нет, то мы переделываем документ который вызвал проводки которые вызвали проблему, и проводим уже исправленный документ. Нельзя быть «чуточку беременной», нельзя быть «частично проведенным документом». Нельзя.
                                                            Самое смешное, что всё это разжёвано и пережёвано в куче книг, статей и курсов. На книжку по основам бухучета у среднего программиста, который (для примера) разобрался, как внутри работает git или даже может написать неблокирующий стек и может вспомнить все паттерны GoF, уйдет 2-4 часа, если не начинать укуриваться деталями. За столько же времени на пальцах и с коньяком объяснит суть учета хороший замглавбух (главбух слишком усложнит, рядовой не объяснит).

                                                            Вам шашечки или ехать? 90% программистов не пойдут тратить 4 часа своей жизни чтобы узнать нужен ли им бухучет и правильная ли это вещь.
                                                            Я видел колоссальное количество различных биллингов и прочих приложений где можно было обойтись парой таблиц в духе баланса и проводок а городили адский ад, а потом на него нагораживали еще кучу костылей, и все равно получалась каша.
                                                            Казалось бы, зачем программисту которому заказали простенький биллинг для хостинга — читать учебник по бухучету? Где бухучет а где биллинг? А мою статью прочесть за 10 минут с комментариями — вполне реально.
                                                              –1

                                                              Вот как раз для биллинга все эти двойные записи и проводки — лишнее.

                                                                0
                                                                Это пока вы не начинаете развивать бизнес-логику.
                                                                Как только вы хотите видеть и «кредит пока не оплатит», и прибыльность клиента, и можем ли мы дать клиенту скидку (по чем мы брали этот сервер) и т.п.
                                                                Слишком, слишком много сущностей выплывает.
                                                                  0
                                                                  Как только вы хотите видеть и «кредит пока не оплатит»

                                                                  Если у нас учёт с персонализацией по клиентам — тогда надо создавать автоматически индивидуальный план счетов для каждого клиента (типа кредит там, на роутер, типы счетов по видам услуг и т. д и т. п.).
                                                                  Но далее — в не очень крупной организации потребуется анализировать, как минимум, внутриорганизационные движения денег между подразделениями, и, в итоге, потребуется ERP-система.
                                                                  Поэтому, по видимому, ERP-системы и являются эволюционным развитием классической бухгалтерии.
                                                                  И, даже в "простых" случаях лучше попробовать внедрить на вырост ADempiere, чем баловаться самописами.

                                                              +3
                                                              Очевидно что не все йогурты одинаково полезны существует большая разница между счетами отражающими деньги в «кассе» от того сколько мы должны денег поставщикам. Соответственно мы разделяем нашу табличку на две.

                                                              Нет, не очевидно.
                                                              Один счёт — одна таблица. Потратил деньги — минус, заработал — плюс.


                                                              Счетов должно быть несколько, вот это очевидно. В вашем примере это ЯндексДеньги, пейпал, наличка,...

                                                                0
                                                                Спасибо за ваш вопрос.
                                                                Вы совершаете самую распространенную ошибку.
                                                                Вы предлагаете выкинуть часть счетов считая что они придуманы искусственно.
                                                                На самом деле все они всегда существуют, просто в неправильном учете их «держат в уме».
                                                                В уме держат сколько должен клиент. В уме держат сколько мы должны поставщику, в уме держат сколько кто из учредителей внес в проект, в уме держат на что пошли эти деньги.
                                                                Всё это держат в уме.
                                                                А потом получается хаос.
                                                                Потом это «в уме» забывается, запутывается и все эти ошибки всплывают лишь тогда, когда уже слишком поздно.
                                                                  +2

                                                                  Дал деньги в долг — это потратил? Получил долг назад — это заработал? А если не деньги дал, а клиенту товар или услугу в кредит предоставил? А обналичка ЯДа? Вроде потратил, вроде заработал, но заработал меньше чем потратил.

                                                                    0

                                                                    А уж если дал в долг в одной валюте, получил в другой, и частями, и при этом курс обмена все время плавает по разным причинам...

                                                                    0
                                                                    ой).
                                                                    На самом деле еще дольше, и это наверное уже четвертая или пятая версия статьи которую я начинал писать. Спасибо что напомнили, надо будет и ту ветку перечитать когда буду писать продолжение, и старые версии статей поднять.
                                                                    0
                                                                    Простите, статью пробежал вскользь.
                                                                    У вас есть ситуации когда на одном и том же счете, в остатках есть суммы как по дебиту так и по кредиту?
                                                                    Давно не работал с бухгалтерией, вроде это активно пассивный счет называлось.
                                                                    Кстати, а кроме суммы, количество у вас можно считать?
                                                                    И еще, поиск по статье не находит слово «субконто».
                                                                      0
                                                                      На активно-пассивном счете теоретически может быть либо кредитовое сальдо, либо дебетовое. На практике у нас есть такое понятие как счет и субсчет, где счет агрегирует в себе значения нескольких разных субсчетов, например счет взаимоотношения с контрагентами будет агрегировать как счета где нам должны клиенты так и счета где мы должны поставщикам (или клиентам оплатившим предоплату), так что в реальном учете такое бывает.
                                                                      И именно по этой причине я против активно-пассивных счетов. В статье я такие счета не описываю, и в своих системах учета такие счета не ввожу. Но в регламентированном учете такие счета существуют.
                                                                        +1
                                                                        в своих системах учета такие счета не ввожу. Но в регламентированном учете такие счета существуют.
                                                                        Вот в чем дело, мне казалось что нужно решать задачи бизнес требований (требований бух. учета, например).

                                                                        В голове такая картина — подходит ко мне бухгалтер и говорит: «мне вот нужна такая проводка и такой активно пассивный счет», а я такой бухгалтеру — «обломиська! Я не завожу такие счета, которые вам нужны».

                                                                        Мне интересно, как вы обходите требования бухгалтеров, нагибаете их что бы они прогнулись под вас? И что, никогда расхождений с законодательством не бывает?
                                                                          0
                                                                          Активно-пассивный счет легко реализуется парой активного и пассивного с помощью автоматического перебрасывания с одного на другой. В начале комментариев более подробное обсуждение.
                                                                          Плюс я не пишу (пока) конкурента 1С, и не занимаюсь регламентированным учетом.
                                                                          Бухгалтеру он понадобится однозначно, а финансисту — не факт.
                                                                          Ну и да, если честно то по результатам текущей оффлайновой дискуссии по этому поводу, я над своей позицией по активно-пассивному начинаю слегка сомневаться.
                                                                          0
                                                                          А если по одному договору у клиента дебет, а по другому кредит? Вообще как договора сопрягаются со счетами?

                                                                          p.s. может сморозил глупость т.к. не разобрался в учете…
                                                                            0
                                                                            В таком случае зависит от того что прописано в договорах, или от того как конкретно тот кто-то самый наглый решает считать :)
                                                                            Реально можно как зачитывать так и не зачитывать.
                                                                            По хорошему надо делать сверку и предлагать делать зачет.
                                                                            Вопрос только кажется простым. Вроде договора однородные, сроки по обоим вышли, процентов нет, валюта одна, штрафных санкций нет, чего бы и не зачесть?
                                                                            Однако моментов бывает множество.
                                                                            Например в системах налогообложения основанных на обороте — прямо запрещены бартеры, взаимозачеты и т.п. Только прямая денежная оплата.
                                                                            Мне несколько раз приходилось гонять десятки миллионов (не рублей и не гривен) по кругу между связанными организациями поскольку чисто по требованиям гос.органов нельзя было делать взаимозачеты (большие суммы касались операций со ценными бумагами, но не суть, по требованиям фискалов тоже бывает такое). Но если контрагент не против, то делать взаимозачет хорошая практика.
                                                                          0

                                                                          Он активно-пассивные счета разбивает на связанные активный и пассивный. Так что технически ничего не мешает в таком составном счете иметь одновременно остатки и в активе, и в пассиве.


                                                                          А вот для представления более логичного объекта — активно-пассивного счета с односторонним сальдо (который, между прочим, в том же биллинге встречается чаще чем все остальные типы счетов) предполагается вводить дополнительный модуль, который будет автоматически сокращать остатки.

                                                                            0
                                                                            Примерно так да. Но не целый модуль а маленькое поведение.
                                                                          –1
                                                                          А почему не рассматриваете активно-пассивный счет?
                                                                          Мне интересно для себя, в мире бухгалтерии либо законодательстве может что то изменилось?
                                                                            0
                                                                            По общему правилу МСФО (и не только МСФО), дебиторская задолженность (долг нам) и кредиторская задолжность (наш долг другим) должны показываться отдельно: дебиторка в активе, кредиторка в пассиве — даже если это один и тот же контрагент (но два разных договора). Свернуть дебиторку и кредиторку между собой можно, только если в обоих договорах с данным контрагентом прямо указано, что стороны согласились не рассматривать задолженности по этим договорам раздельно.
                                                                            Т.е. по умолчанию, учет задолженностей по разным договорам с одним и тем же контрагентом всегда расматриваются раздельно.
                                                                            Если сворачивать — будет происходить занижение нашей реальной задолженности перед третьми лицами, которая публикуется во внешней отчетности или показывается банкам при получении кредитов.

                                                                            Пример: мы должны Васе 100 рублей по кредиту, обеспеченный залогом и штрафными процентами, а Вася нам должен за товар 120 рублей. Если свернуть, то мы можем расслабиться — у нас нет долгов. Но на самом деле долг есть: мы должны Васе 100 рублей. И если мы про это забудем, то нам выставят штрафные проценты по кредититу и/или заберут залог. При этом Вася может продолжать тянуть с погашением своего долга 120 рублей нам.
                                                                            Свернуть долг может принудительно только суд: мы подаем на Васю в суд на 120 рублей, а Вася выставляет встречный иск нам на 100 рублей. Суд сворачивает оба долга и выносит решение: Вася должен выплатить нам 20 рублей.
                                                                              0

                                                                              Это вы рассматриваете ситуацию с разными договорами. Разные договора — разные счета, это очевидно.


                                                                              Но такая ситуация может быть и в рамках одного договора. Например, при авансовых платежах. Вы же не станете утверждать что авансовый платеж нельзя "сократить" с более поздней задолженностью?

                                                                                0
                                                                                Юридически можно. Но бухгалтерии все равно их не сворачивают. Если заказов десятки и сотни по договору, то при таком соврачивании потом концов не найдешь — из чего сложился итоговый долг покупателя или поставщика на дату сверки. Итог сверки между поставщиком и покупателем должен быть легко проверяемым, т.е. равен сумме их взаимных долгов по всем заказам данного договора.
                                                                                  0

                                                                                  И в чем же сложность "нахождения концов"?


                                                                                  Если "сворачивание" — отдельная операция, то да — она будет чисто визуально мешаться (потому мне и не нравится предложение автора о "наблюдателе"). Но если структура базы выстроена так, чтобы отдельное "сворачивание" просто не требовалось — то в чем сложность взять проводки по условию и посмотреть их?

                                                                                0
                                                                                Если свернуть, то мы можем расслабиться — у нас нет долгов. Но на самом деле долг есть: мы должны Васе 100 рублей.
                                                                                Вы подразумеваете что сальдо по счету в разрезе контрагента всегда либо дебетовое либо кредитовое?
                                                                                А разве нельзя сальдо по субконто не сворачивать, а так и оставить:
                                                                                «счет: 33.6, субконто: ЧП Иванов, Дт: 100, Кт: 120»
                                                                                вместо
                                                                                «счет: 33.6, субконто: ЧП Иванов, Кт: 20»
                                                                                То есть, сворачивание, это обязательное свойство счета?
                                                                                  +1

                                                                                  Полный нарастающий итог за всю историю постоянно показывать при просмотре баланса счёта? Или каким-то специальным обязательным признаком в проводке указывать дебетуем/кредитуем мы активную или пассивную часть? Во втором случае это мало чем, по-моему, отличается от двух раздельных счетов.

                                                                                    +1
                                                                                    Вопрос не в сворачивании собственно. Вопрос на самом деле такой:
                                                                                    1) показать в отчетности актив 120 рублей и долг 100 рублей;
                                                                                    2) показать только актив в размере 20 рублей.
                                                                                    Ответ такой: правильный вариант — это №1, если это разные договоры. Или вариант №2, если это один договор (цепочка поставок и платежей по ним).
                                                                                      0
                                                                                      Вроде в 1С был отчет «карточка счета» или еще какой то, и мне казалось в отчете на некоторых счетах можно было увидеть одновременно и дебетовый остаток и кредетовый, но возможно не в разрезе конкретного субконто.
                                                                                      Мне хотелось бы знать, нелогично ли, хотя бы у некоторых счетов, не «сворачивать» сальдо автоматически, а показывать оба остатка.
                                                                                      Например завести какой то флаг у счета, и назвать этот флаг "автоматически сворачивать сальдо".
                                                                                      А когда необходимо свернуть остатки, то тогда для этого делать специальную какую то проводку с одинаковым счетом по Дт и Кт, типа:
                                                                                      «счет Дт: 33.6, счет Кт: 33.6, субконто: ЧП Иванов, Сумма: 100»
                                                                                      где сумма 100 это min(120, 100)

                                                                                      Хотя, похоже что да, это скорее свойство не счета, а отчетной системы по счету.

                                                                                      Или флаг можно установить на комбинацию счета и субконто, например не сворачивать для комбинации счет+типСубконто1+типСубконто2 — «счет 33.6, Контрагент, договор»
                                                                                        0
                                                                                        Вам не кажется что вы сейчас изобрели тот самый вариант который я озвучил в самом начале комментариев и который вы критикуете уже пол дня как?
                                                                                        Два раздельных счета, которые при необходимости (ваше «если есть галочка») сворачиваются автоматически.
                                                                                          0
                                                                                          Понятно.
                                                                                          Дело в том что меня как раз интересуют всякие возможности учетных систем и для чего, в каких случаях, эти возможности применяются на практике.
                                                                                          Значит вы у себя задумали «возможность»-флаг «автоматически сворачивать сальдо».
                                                                                          Теперь мне бы еще узнать на каких счетах вы его включаете, а на каких выключаете, и зачем.
                                                                                          Если уже писали простите, длинный текст читаю бегло, если в нем обсуждают что то, что я уже долго не использовал.
                                                                                            0
                                                                                            Очень зависит от конкретной задачи. Тут ведь уже отвечали — обычно в рамках одного счета «сворачивают», а в рамках разных — только по сверке.
                                                                                            Вместе с тем если это простая логика, например биллинг хостера, где есть счет клиента и его движения, то никто не заморачивается с разделением а делают активно-пассивный счет или в моем случае прописывают событие сворачивания при сохранении проводок на эти счета (в ваших терминах — стоит галочка).
                                                                                0
                                                                                Если разница между активом и пассивом равна 10 рублей — значит бухгалтер ошибся один раз на 10 рублей.
                                                                                А вот разница между активом и пассивом равна нулю, то значит бухгалтер ошибся два раза: первый раз на +1000000000 рублей, а потом второй раз на -1000000000 рублей :)
                                                                                  0
                                                                                  Не всегда.
                                                                                  А если один раз ошибся на 1000, а второй раз на 990? Или ошибок было три и более?
                                                                                  0

                                                                                  Как-то по статье вроде показалось, что она вообще о принципе двойной записи в учёте, типа подсказка для желающих биллинг или домашнюю бухгалтерию на коленке написать, не натыкаясь на камни, которые люди научились обходить если не несколько тысячилетий назад, то пятьсот лет назад точно, но по комментариям уже кажется, что она именно о регламентированном бухгалтерском учёте. Как впечатление правильнее?

                                                                                    0
                                                                                    Первое. Я не люблю регламентированный учет, и чуть ли не в каждом комментарии говорю что я его не затрагиваю. Но те для кого эта тема новая комментируют мало, в основном пишут те кто уже знаком с темой, так что в комментариях упорно скатываемся к регламентированному, как бы я от него не открещивался.
                                                                                      –2
                                                                                      Я не люблю регламентированный учет
                                                                                      Следует ли добавить "и моя система не реализует его"… и тогда я задамся вопросом: «хм, а какое тогда есть моральное право у этого человека вообще учить как делать бух учет, он же похоже подлость делает новичкам учя их плохому»
                                                                                        +1
                                                                                        хотя… комментарии для того и есть что бы обсудить/поспорить
                                                                                          0
                                                                                          В том то и дело. Я ведь в самом начале написал что статья не академическая, а по основам. И везде говорю что в регламентированном учете немного не так, хоть принципы и сохраняются, но вы не можете произвольно организовывать логику, а должны пользоваться теми шаблонами что за вас придумали законодатели.
                                                                                          Что никак не отменяет того факта что активно-пассивные и забалансовые счета — лютый легаси, который нельзя бросить в регламентированном, но не стоит начинать в своем собственном управленческом.
                                                                                    +2
                                                                                    История в тему: «В одной бухгалтерии работал самый лучший бухгалтер. Все его считали самым умным. Каждое утро он открывал ящик стола и заглядывал в него. А потом закрывал ящик на ключ. И никто не знал что у него в ящике. Наконец, самый лучший бухгалтер ушел на пенсию. И вся бухгалтерия бросилась открывать его ящик чтобы посмотреть что у него там. А там была только одна надпись на дне: „Дебет — слева, кредит — справа“ :)
                                                                                      –3
                                                                                      >Так мы подошли ко второму фундаментальному понятию — проводка.
                                                                                      Какая проводка? Электрики что ли? это «бухгалтерская запись»
                                                                                        –2
                                                                                        есть такое слово «крыжить»
                                                                                          –2
                                                                                          *удаки, которые минусуют поди вики пончитались ))
                                                                                            +1
                                                                                            "бухгалтерская запись" — 85тыс
                                                                                            "бухгалтерская проводка" — 146тыс
                                                                                            Ну и расшифровка терминов в словарях:
                                                                                            Запись
                                                                                            Проводка
                                                                                            Но даже если бы вы каким-то чудесным образом были правы — минусы вы бы получили чисто за форму подачи вашего мнения.
                                                                                            Большинство комментариев от ридонли которые я тут одобрил — противоречили моей позиции, но в основном к ним шла аргументация…
                                                                                              +1
                                                                                              Не следуйте принципу «толпа леммингов не может ошибкаться», посмотрите англоязычную литературу (accounting record, accounting transaction)
                                                                                                –1
                                                                                                Это исключительно терминологический вопрос. Мы обсуждаем русскоязычный термин, на русскоязычном ресурсе и во всех странах где русский язык имеет существенное хождение — преобладает советская терминология.
                                                                                                Вы ведь не станете называть леммингами тех кто предпочитает понятие астронавт понятию космонавт? При этом термины при их семантической близости имеют определенные различия.
                                                                                                В данном случае между советской и западной школой есть такое же существенное различие — колво участвующих в операции счетов. Так что различие терминологии это как раз благо а не зло.
                                                                                                Да и вместе с этим. Черт с ним, называйте как хотите. В вашей позиции возмущает не это, а то что вы критикуете академически принятую позицию, поддерживаемую большинством, при этом позиция эта относится исключительно к терминологии.
                                                                                          +1
                                                                                          Наброшу немного математики.
                                                                                          Если обобщать, то двойная запись — это частный случай «балансового вектора», — то есть вектора, сумма компонент которого равна нулю. Такие векторы удобны тем, что их можно складывать/вычитать — результатом снова является балансовый вектор.

                                                                                          Поэтому думаю, что должны существовать такие хозяйственные операции, которые удобно отражать «балансовой проводкой», а не двойной записью. В том смысле, что их принципиально нельзя свести к двойной записи.

                                                                                          Примером балансовой проводки на 4-х счетах может быть что-то типа (+50 Cч1, -40 Сч2, -20 Сч3, +10 Сч4).
                                                                                            0
                                                                                            В таких случаях в бухучёте обычно делается несколько проводок…
                                                                                              0

                                                                                              Да, конечно, но тогда часть информации теряется. Например, о корреспонденции. Если приведенный выше вектор интерпретировать как результаты преферанса (двое выиграли 50 и 10 рублей, а двое проиграли 40 и 20), то в принципе можно сделать обычные проводки через доп. счёт (игральный стол), но тогда сложно извлечь инфу, кому именно проиграли (или выиграли) игроки.

                                                                                                0
                                                                                                А что сложного? У проводок всегда есть некий общий контейнер. Я называю его "документ". Каждая проводка ссылается на то какой документ ее породил, так что пройдя по одной проводке мы видим всю картину документа «результат преферанса».
                                                                                                Оффтоп: Сомневался стоит ли писать про документ, не усложнит ли… Оказалось что актуально. Уже несколько раз всплывал в этом обсуждении.
                                                                                                  0

                                                                                                  В нашей системе проводки объединятся в операции (в одном документе может быть несколько операций), но это не решает проблему корреспонденции, например. Как по итогам месяца посмотреть, кто у кого выигрывал в преферанс? Запрос будет сложным и неудобным.

                                                                                                    0
                                                                                                    В одной известной бух. системе, Операция это Документ.
                                                                                                    В одной Операции может быть несколько Проводок.
                                                                                                    А для чего в вашей системе несколько Операций для одного Документа?
                                                                                                    Может у вас Операция это всего лишь одна Проводка?
                                                                                                      0

                                                                                                      Ну например операции "Реализация товара" и "Реализация услуг" могут выполняться в рамках одного документа. И состоять при этом из разных проводок…

                                                                                                        0
                                                                                                        В рамках какого документа? Чем руководствуетесь делая единый документ? Может лучше делать несколько документов, а общее для них называть «сделка» или что-то вроде?
                                                                                                          0

                                                                                                          Конкретно в этой ветке мне бы не хотелось это обсуждать. Мы на эти вопросы ответили ещё 20 лет назад. Триада — "проводка, операция, документ" — универсальная модель организации учета.

                                                                                                            0
                                                                                                            Триада — «проводка, операция, документ» — универсальная модель организации учета
                                                                                                            Гуглится что то не то, есть ссылка?
                                                                                                              0
                                                                                                              Ну если уж говорить об универсальной триаде, то это вопрос сугубо терминологический. Триада «проводка, документ, сделка» ничем собственно не отличается. Единственное что — да, по результатам этой ветки я себе выберу более нейтральные названия чтобы не было «документ» в этой цепочке.
                                                                                                                0

                                                                                                                Делал "документ-транзакция-операция".

                                                                                                        0
                                                                                                        А с проводками у которых есть множество счетов запрос будет простым?
                                                                                                        Для начала мы будем вынуждены дробить такую проводку на единичные записи, поскольку нельзя сделать запись с переменным количеством полей (только давайте без NoSQL, она здесь только внесет еще больше сложностей ибо до N-ной части проводки будет сложно добраться).
                                                                                                        Потом из этих осколков проводки нам нужно будет как-то собрать общую картину. Ну ок, собрали. Но что мы увидим? По факту то все выигравшие выиграли у всех проигравших. Так что если мы хотим не просто узнать кто у кого, а получить это в денежном выражении (а мы хотим, иначе нечего было начинать), то нам придется как-то эти суммы делить.
                                                                                                        Для примера возьмем ваш случай с двумя победителями и двумя проигравшими.
                                                                                                        двое выиграли 50 и 10 рублей, а двое проиграли 40 и 20

                                                                                                        Распишем это так:
                                                                                                        В1: 50 руб
                                                                                                        В2: 10 руб
                                                                                                        П1: -40 руб
                                                                                                        П2: -20 руб
                                                                                                        Но кто кому сколько проиграл? Как посчитать?
                                                                                                        Если же мы хотим расписать это группой двойных проводок, то у нас выйдет четыре проводки. Простейший случай это через вспомогательный счет. Но что если без него? Давайте пропорционально разделим деньги напрямую от проигравших к победителям, чтобы сохранялась общая сумма.
                                                                                                        Тогда мы получим:
                                                                                                        1) П1: — 33.33 руб, В1: 33.33 руб
                                                                                                        2) П2: — 16.67 руб, В1: 16.67 руб
                                                                                                        3) П1: — 6.67 руб, В2: 6.67 руб
                                                                                                        4) П2: — 3.33 руб, В2: 3.33 руб
                                                                                                        Данные из таких проводок легко извлекаются и агрегируются.
                                                                                                          0
                                                                                                          Немного позанудствую.
                                                                                                          Разве так делают, а как на самом деле правильно делать проводки?
                                                                                                          10 лет не в бухгалтерии, но вроде бы, сначала насчитывают долг, а потом по проводкам поступают «бумажные» денежки.
                                                                                                          И вроде напрямую так не делают, а то если П1 дал деньгу В1, то получается что создался долг как будто В1 теперь должен П1, но ведь он не должен и не вернет никогда долг, проводки как то по другому принципу пишутся, через «вспомогательные» счета.
                                                                                                            0
                                                                                                            Проводки пишутся так как записано в вашей учетной политике. Если мы говорим о регламентированном учете, то там мест для маневра не очень много, но они тоже есть. А для управленческого вы вольны строить как хотите.
                                                                                                            Что касается последовательности проводок, то тут особой проблемы нет, ведь они у нас идут пачкой в одной операции/документе, и единой транзакцией.
                                                                                                            Собственно поэтому я и говорю что все проводки одного документа лежат в одной транзакции, чтобы не было вот таких вот смущающих вас моментов «между».
                                                                                                            А так то вообще задача у нас тут сугубо теоретическая ибо мне сложно понять что это за учет преферанса такой мы строим, а вы еще и регламентированный учет пришить хотите).
                                                                                                            0
                                                                                                            Это, конечно, возможный вариант, но здесь вам пришлось сделать дополнительное допущение о принципе распределения долга. И выше правильно заметили, что участники могут и не придти к согласию об именно таком распределении долга. А если участников много, то замучаетесь распределять суммы и считать погрешности.
                                                                                                            Обычно все же такое делают через доп. счет. Все проигравшие корреспондируют с ним с одной стороны, а выигравшие — с другой. Но там другое неудобство.

                                                                                                            Я не уверен, что балансовые проводки нужны, — и лишь размышляю об этом.
                                                                                                            Если в одной проводке допустить корреспонденцию нескольких счетов одновременно, то тогда при запросах о корреспонденции счетов следует, видимо, уточнять в какой стороне группировать счета — по дебету или кредиту.
                                                                                                            Если, например, по дебету, то корреспонденция счетов в примере должна выглядеть примерно так:
                                                                                                            В1 получил 50 руб. от П1 и П2
                                                                                                            В2 получил 10 руб. от П1 и П2
                                                                                                            А если по кредиту, то:
                                                                                                            П1 отдал 40 руб. В1 и В2
                                                                                                            П2 отдал 20 руб. В1 и В2
                                                                                                            Тут нет никаких допущений о распределении сумм.
                                                                                                              –1
                                                                                                              Вы хотите изобрести «лямбда-счета»?) Ведь по сути в множественной проводке есть некий общий счет этой проводки просто он не занимает адресное пространство на подобии лямбда-функций/классов.
                                                                                                              У вас либо есть общий счет, тогда его можно указать явно, либо его нет, тогда есть логика распределения долгов (как вариант — та что я привел, пропорциональная). Третьего не дано.
                                                                                                              Я сделал предположение о распределении долгов поскольку вы захотели узнать «кто кому», а значит логично что еще и «сколько».
                                                                                                              А так то «операции» или у меня «документы» это как раз такие «метапроводки» которые имеют много входов-векторов и остаются балансовыми векторами.
                                                                                                              При этом их обслуживание остается простым.
                                                                                                                +1
                                                                                                                Из вопроса «кто — кому» далеко не всегда следует, что надо распределять «кто сколько».
                                                                                                        0
                                                                                                        Бухучёт и не ставит своей целью сохранение этой информации. Для этого ещё есть управленческий учёт.
                                                                                                          0

                                                                                                          Да ладно ). Нормальная цель хорошего учета. Просто обычно извращаются различными способами, пытаясь ответить на подобные вопросы..

                                                                                                            0
                                                                                                            Хм… я возможно не сказал это прямо, но я настаиваю, что в основе управленческого учета должен тоже лежать свой баланс и свой специфический «управленческий» план счетов. Конечно это все обвешивается кучей доп.полей, кучей субконто, разными ценами (баланс, закупка, продажа) и кучей всего, но в основе — та же двойная запись.
                                                                                                              0
                                                                                                              Не получится управленческий учёт построить на основе только баланса.
                                                                                                                0
                                                                                                                Я не сказал «только», я сказал «на основе».
                                                                                                        0
                                                                                                        Можно. Но не нужно.
                                                                                                        Двойную запись проще контролировать чем множественную. Проще заносить в базу (иначе выходит EAV, что плохо).
                                                                                                        Вместе с тем если уж совсем строго то вектор у нас N-мерный, где N равно количеству счетов в нашем балансе (всех, как активных так и пассивных, а не только тех по которым мы делаем операцию). А вектор соответствующий проводке это такой вектор у которого все измерения равны нулю кроме двух, обозначенных в проводке.
                                                                                                        При этом аналогом вашей «балансовой проводки» в моих терминах является "документ" с которым связаны одна или несколько проводок. Их сумма (у которой остальные измерения равны нулю) и будет таким множественным вектором.
                                                                                                          0

                                                                                                          По поводу n-мерных векторов. Если задать матрицу расстояний между счетами, то оказывается, что проводка может быть описана двояким образом — контравариантным (обычным) и ковариантным (термины из тензорной алгебры). Обе проводки будут балансовыми и описывать один и тот же вектор, но когда у обычной проводки ненулевыми являются только две компоненты (двойная запись), то у аналогичной ей ковариантной звенят все компоненты.

                                                                                                            0
                                                                                                            Вот за что я люблю тензорную алгебру… а собственно ни за что не люблю))).
                                                                                                            Но в качестве разминки для ума можно подумать об этом. Опишите плиз пример обеих записей применительно к счетам и проводкам, думаю многим будет интересно это увидеть.
                                                                                                              +1
                                                                                                              Да я сам сильно удивился, обнаружив связь бухгалтерии и тензоров ). В результате и задумался о «балансовых проводках».
                                                                                                              Но как просто описать в двух словах — пока не знаю. Возможно, как-нибудь в отдельной статье опишу.
                                                                                                                0
                                                                                                                Для начала надо в двух словах объяснить тензорное исчисление, потом в двух словах рассказать бухгалтерию, а уже потом…
                                                                                                                  0
                                                                                                                  «Тензорное исчисление для главбухов», ага ). Хм, может, и подойдет в качестве заголовка ).
                                                                                                              0

                                                                                                              В ортонормированном базисе ковариантные координаты совпадают с контрвариантными :-)

                                                                                                                0
                                                                                                                Круто, что есть люди, которые об этом знают ). А можете догадаться, при каком условии бухгалтерские счета являются «ортонормированными»? То есть контравариантные проводки совпадают с ковариантными.
                                                                                                                  0

                                                                                                                  Зависит от того, какой смысл вкладывается в скалярное произведение двух счетов.


                                                                                                                  Лично я считаю, что смысла в таком произведении — нет, а потому для разных счетов там должен быть ноль, а для одинаковых — квадрат баланса. Значит, базис у нас ортонормированный.


                                                                                                                  Впрочем, если есть желание всех запутать — можно определить скалярное произведение как-нибудь по-другому. Только мне почему-то кажется, что бухгалтера такое не оценят.

                                                                                                                    0
                                                                                                                    Ну, если говорить конкретно про «ортонормированный базис», то все проще ).
                                                                                                                    В том плане, что тут можно пока и без скалярного произведения обойтись.

                                                                                                                    Бух. счета — это вершины графа (если определять систему координат через связи между вершинами), или вершины симплекса (если определять ее через расстояния между вершинами). Так вот, если все расстояния (или связи) между вершинами одинаковы, то такой набор вершин (счетов) и соответствует «ортонормированному базису». В котором контравариантные и ковариантные проводки совпадают ).

                                                                                                                    А скалярное произведение везде одинаково определяется — через билинейную форму произведения векторов на метрический тензор.
                                                                                                                      0

                                                                                                                      Метрический тензор — это и есть скалярные произведения базисных векторов. Я о нем и говорил, только другими словами.

                                                                                                                        0
                                                                                                                        Да, конечно. Просто для набора бух. счетов сложно определить именно скалярные произведения между ними — никакой бух не ответит на такой вопрос ). А вот связи (или расстояния) между счетами — оценить можно. Поскольку логично предположить, что корреспондирующие счета расположены ближе друг к другу (связаны), чем некорреспондирующие.

                                                                                                                        Далее зная дистанционную матрицу (или матрицу смежности), можно построить метрический тензор. Даже два — ковариантный и контравариантный. Тогда скалярные произведения сами определятся.