Большинство из нас сталкивались с бухгалтерами. Многим их терминология кажется китайской грамотой, как для гуманитария обратная польская запись. Однако разобравшись, понимаешь насколько это удобный и мощный инструмент.
Статья не академическая, а отражает сугубо мой упрощенный взгляд, и для тех кто уже осилил академические статьи — будет неинтересной. Тех же кому интересно понять такой простой и мощный инструмент как «двойная запись» — прошу под кат.
Давайте представим себе некую структуру ведущую деятельность, имеющую взаимоотношения с окружающим миром, владеющую некоей собственностью. Не важно что это за структура. Это может быть фирма, домохозяйство, веб-сайт или простой гражданин. Допустим это будет интернет-стартап. Скажем мы сделаем площадку по торговле слонами. Назовем этот проект «Слономаркет».
Мы не будем регистрировать никакие юрлица, ИП/ФОП и прочие юридические действия. Представим себе что просто несколько друзей договорились запустить подобный стартап, и ведут свою деятельность «в гараже».
Баланс
Для того чтобы понимать общую картину финансов в нашем Слономаркете, мы заводим табличку, в которой пишем что у нас есть, что нам должны, что мы должны и т.п. Назовем эту табличку "баланс", а строчки в нашей табличке "счетами баланса".
Очевидно что
На самом деле активы и пассивы (Ржевский молчать!) это не совсем собственность и долги, но для начала предлагаю такое определение, чтобы не запутываться. Для запоминания можно использовать такую ассоциацию — активами мы можем активно распоряжаться. Отдать деньги случайному знакомому или потратить. Простить долг клиента (долг клиента перед нами — актив, наш долг перед поставщиком — пассив), разломать станок или отдать автомобиль на металлолом. Все зависит только от нас. А с пассивами возможны только пассивные операции. Мы не можем взять и отдать случайному бомжу наш долг перед поставщиком. Нужно согласие как бомжа так и поставщика.
Пример баланса Слономаркета:
Активы:
- ЯндексДеньги: 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) Если счет активный, то проверяем не стал ли он отрицательным, и если да, то прерываем операцию и откатываем транзакцию.
Всё. Все основные свойства учета у нас уже есть.
Конечно в реальной базе у нас добавятся различные поля связанные с предметной областью, например у проводок нужна дата/время и связь с документом породившим проводку. У счетов нужна информация о том что то за счет такой, и связи на другие связанные с ним объекты (контрагентов, товары и т.п.), но это уже другая история.
Пожалуй на этом пока закончим, если будет интересно, то дальше расскажу как по максимуму извлекать информацию из баланса, разберу немного примеров операций и т.п.
Комментарии (123)
Randl
30.08.2017 19:06Довольно быстро разобрался с этим когда начал записывать расходы в GnuCash
NIKOSV
31.08.2017 01:55Тоже использую GnuCash. Довольно топорный и примитивный, с дизайном из начала 2000-х, но блин, ничего больше нет. Жаль что ничего более современного и симпатичного на эту тему нет, чтобы не грузился 20-30 с (при том что на С написан), не требовал бы кучи ручных настроек (биржи, тикеры акций, валюты нужно руками подключать) и не использовал бы perl для синхронизации с внешними сервисами (курс валют, цена акций, и т.д.)
Kane
31.08.2017 11:13Перешел несколько лет с GnuCash на YNAB и очень рад. Он просто работает, никаких зависимостей и в комплекте с программой идёт идеология работы, помогающая тебе организовать свои финансы.
ilialin
31.08.2017 13:04Ну как это нет. Есть:
Money Manager Ex (http://www.moneymanagerex.org) — бесплатная, открытая, в т.ч. есть клиенты для мобильных платформ. Сначала пользовался им, но в какой-то момент меня перестала устраивать не достаточная глубина анализа (нет возможности создавать разветвленную аналитику).
AbilityCash (https://dervish.ru/) — бесплатная, закрытая. Разрабатывается с начала 2000-х, поэтому интерфейс немного не свеж. По части глубины анализа существенно превосходит предыдущую, но нужно разобраться и настроить под себя.
1С: Деньги (http://v8.1c.ru/money/) — не бесплатная (но дешевая), «полуоткрытая» (поставляется только в базовом варианте, версии проф не бывает, поэтому править конфу нельзя, но внешние отчеты — пожалуйста). Есть какой-то мобильный клиент. Настраиваемая как душе угодно аналитика, хорошие отчеты (если знаете СКД, отчеты можно гнуть для себя как хочешь).
Для домашней бухгалтерии самое то.
playnet
31.08.2017 14:24+2Раз уж подняли эту тему, много лет всё пытался завести учёт финансов семьи, но с рядом требований (думаю, многим семейным будет полезно):
1) непосредственный учёт, причём для двоих (муж-жена), доходы-расходы обоих
2) персональные счета, которые никак не светятся у второго участника, это может быть как что-то сберегательное, так и рабочее (выдали на закупку чего-либо), и с фиксацией, кто, когда, на что выдал и когда вернуть/отчитаться
2а) сбережения в наличке и их движение
3) поддержка обязательных платежей (ЖК, ипотека), с возможностью корректировки сумм и предупреждением что «скоро пора»
4) кредитки. Ставка, беспроцентный период каждой покупки, обязательные платежи к дате,…
Желательно онлайн, но можно и стационарно. Можно платную.
Крайне желательна поддержка банков или хотя бы их смс, автоматом вносить инфу в базу, для смс это получается нужен андроид клиент. Есть что-то такое?
AEP
30.08.2017 19:41А как учитывается уплата всяких налогов?
Mendel Автор
30.08.2017 20:18+1Пассивный счет «задолженность по налогам».
Ну или пачка таких счетов под каждый налог (субсчетов скорее, но ту тему пока не затрагиваем).
При операции продажи мы кидаем часть на прибыль, часть на себестоимость, часть на налоги.
Mingun
30.08.2017 19:42-1Меня всегда удивляло, когда так называемая "двойная запись" преподносится как преимущество. Везде говорят, что для минимизации ошибок нужно избегать дублирования информации, а здесь наоборот, даже поощряется. Как у кого-то после этого язык поворачивается назвать систему удобной или понятной — ума не приложу. Причем, я ещё понимаю, если бы записи для разных счетов вносились разными системами или транзакциями — тогда имеет смысл проверять друг друга (хотя тоже сложный вопрос, на чьей стороне правда). Но когда это делает одна и та же система, за одно действие — верх театра абсурда. А потом начинаются проблемы, что что-то там не сходится, наверное при записи ошиблись — в одном месте записали 10, а в другом --100. Сами создали проблему, сами героически решаем. А было бы это одно поле а не 2, такого бы не случилось. Поправьте меня, если я ошибаюсь.
Larrikin
30.08.2017 20:16+3Если бы поле было одно, то не ошибались бы никогда на 100 вместо 10?
Mingun
30.08.2017 21:18-4Очевидно, расхождения бы были бы невозможны. Пока у меня складывается впечатление, что сначала пишут разные числа, а потом пишут другие разные числа, чтобы избавиться от расхождений и жалуются, что приходится писать вот эту вторую пару. А о том, что и первую можно не писать и избавить себя от дальнейшей работы почему никто не упоминает, словно все поголовно владеют каким то тайным знанием, зачем это нужно.
Mendel Автор
30.08.2017 22:01+4«Тайное знание» подробно описано в статье. Мне даже кажется очень подробно.
Плюс я планирую во второй части в основном его повторять (вернее расписать подробнее несколько относительно реальных примеров применения данного подхода). Плюс ниже я еще раз повторил.
Вот честно — я уверен что несмотря на то что я звучу как попугай, я считаю что действительно оно сложно понимается и стоит несколько раз повторить, а потом еще раз повторить, но у меня твердая уверенность что вы или не читали статью вообще, или пробежали по заголовкам и даже не попытались в нее вникнуть.
Я очень хочу слышать вопросы, но вопросы конкретные и осмысленные а не какие-то абстрактные высказывания ходящие по кругу. ПРОЧТИТЕ СТАТЬЮ.
Специально для вас я приведу абзац который я выкинул из окончательной версии статьи (был в середине):
Советую взять листик в клеточку или ексель/гугл-таблицу, нарисовать таблицу «баланса», таблицу для проводок и расписать все проводки для всех примеров которые я приводил в тексте. Какой счет дебетуется, какой кредитуется, на какую сумму и т.п. Дополнительно было бы неплохо попробовать построить цепочку проводок которые могли привести из нулевого баланса (в начале проекта на всех счетах у нас ноль) нашего Слономаркета к балансу приведенному в начале статьи.
khim
31.08.2017 13:22+1Я очень хочу слышать вопросы, но вопросы конкретные и осмысленные а не какие-то абстрактные высказывания ходящие по кругу.
Да с «абстрактными высказываниями» тоже нормально.
У нас есть абстрактное высказывание:
Везде говорят, что для минимизации ошибок нужно избегать дублирования информации, а здесь наоборот, даже поощряется.
Примем его на веру и напишем пару следствий:
1. Бекапы — это категорически неправильно. Нельзя их делать. А бэкапы бэкапов в другом — это вообще смерть.
2. Системы логирования — это вообще катастрофа. Их быть не должно. Ни в коем случае. Вся имеющаяся в них информация поступила туда из основной системы и, разумеется, там уже есть — а копии нам не нужни никогда и нигде.
Ну и другие подобные же выводы можно сделать. Нравится? Применимо на практике?
Правда заключается в том, что у людей, высказывающих подобные вещи просто каша в голове и они не то, что бухгалтерии не понимают — они в принципе и программирования-то не понимают и того как IT-системы (а бухгалтерия — это «родоначальная» IT-система, ради них и предки компьютеров, собственно, выпускались).
Все современные файловые системы и базы данных, блин, к «двойной записи» пришли — все данные пишутся в лог и на диск/базу. И «подведение баланса» у них тоже есть — это когда вы завершаете транзакцию. Почему бухгалтерия «подводит баланс» раз в месяц, а базы данных сотни раз в секунду — вопрос интересный, но базовых принципов не меняющий.
Cryvage
31.08.2017 17:28В данном случае дублирование информации используется для выявления ошибок. А требование к отсутствию дублирования это немного о другом. Дело в том, что считать ошибкой.
Допустим, возьмём классический реляционный подход. Состояние базы данных корректно, если оно внутренне непротиворечиво. То есть, ошибка, и внутреннее противоречие, здесь, по сути, синонимы. Но это так только с точки зрения математики. Если добавить к рассмотрению связь с реальным миром, то отсутствие противоречий не гарантирует нам корректность данных. Любое внутренне противоречие является ошибкой, но не любая ошибка выражается во внутреннем противоречии.
Рассмотрим простейший пример. Допустим, у нас есть одна таблица с контактными данными людей. И в ней указано, что телефон Васи — 555-77-77. Там же есть поле, в котором указаны адреса, и там записано, что Вася живет в доме номер 1 по улице Ленина, в 77-й квартире. Теперь представим, что у нас есть вторая таблица, в которой указаны номера телефонов, закрепленных за адресами. И там есть запись, указывающая что в той самой 77-й квартире, в доме номер 1 по улице Ленина, подключен совсем другой телефон — 777-55-55.
Очевидно, что в записях ошибка. Но это нам мало чего даёт, ведь мы не знаем какая из записей верна. Мы теперь не можем сказать, то ли Вася живет по другому адресу, то ли у него другой номер телефона. Но если бы у нас не было таблицы, в которой телефонные номера связаны с адресами, разве это гарантировало бы нам корректность телефонного номера, или адреса Васи? Конечно же нет. Тот кто записал эту информацию, мог указать что угодно. Никакого Васи вообще может не существовать. И квартиры такой в том доме может не быть.
Зато, наличие дубликата позволило нам выявить тот факт, что ошибка в принципе существует. В случае с описанной БД, нам это мало что даёт. Но когда все ходы записаны, а в случае с бухгалтерией это именно так, это даёт нам повод перепроверить операции, и выяснить, откуда взялась ошибка. Баланс работает как контрольная сумма. А история операций, как информация для восстановления.
Если в нашу БД из примера добавить данные о том, кто вносил каждое изменение, а так же хранить все предыдущие записи, то мы могли бы, выявив ошибку, найти того, кто её внёс, и каким было последнее непротиворечивое состояние. В таких системах дублирование помогает искать и устранять ошибки, от которых невозможно формально защититься, например ошибочный пользовательский ввод.Mendel Автор
31.08.2017 18:36Спасибо за комментарий. Отчасти Вы правы. Но в контексте фин.учета это не совсем верно. Двойная запись не удваивает информацию. Двойная запись лишь требует ПОЛНОТУ информации. Она немного ограничивает нас в том какую информацию мы можем игнорировать, но по факту у нас здесь нет такого чтобы одна и та же информация повторялась дважды.
В программировании, и в особенности в проектировании структур данных есть два процесса: нормализация и денормализация БД.
На первый взгляд это взаимно противоположные действия, но немного не так.
Нормализация это процесс уменьшения избыточности, с целью уменьшения количества логических ошибок, упрощения и т.п.
Денормализация это процесс целенаправленного внесения избыточности для решения каких-то конкретных задач — увеличение надежности, улучшение производительности и т.п.
Ключевой момент который упускают те кто считают эти процессы противоположными — денормализацию можно проводить ТОЛЬКО ПОСЛЕ ТОГО КАК была проведена нормализация. Эти процессы не противоположны, а взаимно-дополняющие. Случайно денормализованная структура несет в себе хаос. Специально денормализованная — гармонию :)
mayorovp
30.08.2017 20:26+2А было бы это одно поле а не 2, такого бы не случилось.
Нет, такое бы все равно случилось. Просто оно не было бы замечено — и это куда хуже.
Mingun
30.08.2017 21:20-4Ну заметите вы расхождение и на что его исправлять? Можете посчитать правильным число 100, а на самом деле правильное было 10. И в чем выгода, если опять результат неправильный будет?
mayorovp
30.08.2017 21:22+4С вашим подходом лучше от бухгалтерии держаться по-дальше. Числа-то не из головы придумываются вообще-то.
Mendel Автор
30.08.2017 22:22+1Вообще вопрос не такой уж глупый как кажется.
На самом деле 99% возможных ошибок будут обнаружены прямо в момент их совершения. Вы просто не сможете записать неправильно. Получите сообщение об ошибке или еще как, но вам не нужно будет выискивать в чем именно ошибка поскольку как правильно заметил mayorovp на момент внесения данных в систему учета у вас перед глазами будет само событие которое вы описываете. Проданный товар, купленные запчасти, зарплатная ведомость или счет на оплату налогов. Не суть, но само событие предметной области будет на виду, а значит угадывать какой ответ правильный будет не нужно.
Однако даже если ошибка пройдет дальше, то ее будет проще локализовать и исправить поскольку у нас будет несколько фактических показателей которые не сходятся. Например у нас на складе излишки сигарет с ментолом и нехватка денег в кассе. Значит мы можем предположить что мы забыли оформить какую-то закупку сигарет. Начинаем поднимать закупки. Документы, поставщиков, все операции связанные с ментоловыми сигаретами и оказывается что мы ошиблись, с ментоловыми сигаретами все в порядке, а потерялась накладная на вишневые сигареты. Просто товаровед посчитала что в кассовой зоне пересортица и перебросила часть ментоловых сигарет на счет вишневых поскольку вишневых по факту продавалось больше чем было в базе. (Реальный случай).
В одиночной записи мы бы не смогли так просто отследить эту связь, ведь у нас не было бы проводки которая затрагивала бы и ментоловые и вишневые сигареты.
Случай с пересортицей был сложным. А вот случай когда реально потерялась накладная именно на ментоловые, и мы сразу подняли все движения по ментоловым и увидели что был заказ на такую сумму, что не пляшут и деньги и сигареты и стали звонить поставщику и т.п. — более частый. Без двойной записи пришлось бы перебирать все операции в поисках проблемной.
ПС: вообще поиск нестыковок в большом сложном балансе, когда все очевидные вещи уже исправлены автоматически за счет двойной записи, а ошибка не одна, а множество мелких — очень сложное занятие сродни искусству.
Mendel Автор
30.08.2017 20:36+2Ошибаетесь.
Я понимаю что статья длинная и легко потерять нить или прочитать через строчку, так что остановлюсь на том моменте еще раз.
Минимальная операция в двойной записи это проводка.
У проводке грубо говоря есть три поля — два поля указывают номера счетов где отражаются изменения, третье поле это сумма изменения.
Эти счета РАЗНЫЕ, а сумма одна. Поэтому сделать так чтобы в одном месте 10 а в другом 100 — не получится. В бумажном виде такое изредка случалось, но с появлением в бухгалтерии компьютеров — полностью исчезло.
Давайте рассмотрим случай который я наблюдал пару дней назад.
Две девушки открыли стартап.
Они делают бижутерию ручной работы.
Одна из них закупала материалы. Делала несколько закупок в разных местах. Плюс у нее были некоторые материалы закупленные еще до того как они стали работать вместе, и они договорились что она вносит эти материалы в общак, и берет за них оговоренную стоимость из кассы. Девочки пользуются простым, тупым учетом — у них есть несколько табличек примерно аналогичных счетам баланса (материалы, деньги в кассе, товар на складе и т.п.) изменения в которых они ведут одиночными записями. Когда девочка записывала эти операции в кассу она по ошибке указала стоимость принесенного ей товара не как расход из кассы (выплату ей стоимости товара) а как доход. А поскольку она делала другие закупки, покупала из своих денег а потом забирала из кассы разницу, то ошибка не была замечена сразу, она взяла денег за вычетом двойной стоимости принесенных ею материалов.
Ошибка всплыла только потому что ее партнерша перечитывала все записи внимательно и дотошно и увидела что тут явно ошибка.
Если бы у них использовалась двойная запись, то ей нужно было бы записать не только факт ухода или прихода денег, но и вторую запись за что эти деньги пришли или на что были потрачены. В данном случае должны были бы увеличится суммы в таблице «материалы на складе». В принципе в автоматическом варианте тут ошибки не могло бы быть просто потому что раз материалы актив, и он увеличился а второй записью идет касса которая тоже актив, то она может только уменьшится. Но если даже опустить эту проверку и записать вручную в таблицу неверную запись — мы нарушим баланс. Активные счета сразу перестанут совпадать с пассивными, ведь у нас одной операцией увеличилось сразу два активных счета.
Ну и еще раз — двойная запись не записывает одну операцию дважды. Она просто записывает связанные вещи как единую запись. Примерный аналог, чтобы понять в чем она двойная — банковские счета (на самом деле там все так же — активы, пассивы, дебет и кредит, но это уже в следующих частях). Если мы переводим деньги с одного счета на другой счет в том же банке, то при одиночной записи мы сделаем две записи — одной записью мы уменьшим счет источника, второй записью увеличим счет получателя. При двойной записи мы просто запишем — взять столько-то денег с такого-то счета и положить на такой-то. Одной, ДВОЙНОЙ записью. Согласитесь что так ошибиться сложнее.
tefarov
30.08.2017 22:57На самом деле, на уровне БД создаётся одна запись в таблице транзакций: с полями: дата, сумма, счётДт, счётКт, описание. Для того чтобы получить баланс того или иного счёта нам надо просто отобрать все транзакции, где этот счёт фигурирует в Кт или Дт. Из проверок только проверить, что оба счёта указаны, ну и ряд бизнес-проверок (чтобы проводка имела смысл, чтобы не выпрыгивала из временного периода итд)
Такая подход позволяет вам в любой момент времени изменить как сумму, дату транзакции, так и сами счета между которыми осуществялется эта транзакция, без боязни, что вы нарушите целостность итогового баланса (т.е. что сальдо активных счетов всегда будет равно сальдо Пассивов)Mendel Автор
30.08.2017 23:07Есть такой подход.
Но у него есть несколько недостатков.
Главный минус вашего подхода это «можно изменить не опасаясь нарушить». Это ошибка.
Изменяя что-то задним числом вы рискуете нарушить целостность проводок которые были после того, ведь ваше изменение могло повлиять на условия при которых последующие проводки не имели бы смысла. Так что нет, это не преимущество а недостаток. Лучше отменять все что было после измененной записи и осуществлять изменения заново.
Это называется «отмена проведения документа» и «перепроведение документа» в терминах 1С, да и в других системах вроде тоже.
Так что «изменять задним числом» я вам не советую даже рассматривать.
А вот с тем чтобы складывать все проводки это да, идея верная.
Но у нее есть один жЫрный минус который делает ее в чистом виде не рабочей:
Такие операции слишком накладны. Вместо одного SELECT который вернет нам множество интересующих нас счетов отбирая нужные данные по условию используя индекс мы будем выполнять множество групповых операций проходя по всей базе.
В больших объемах это не просто накладно а неподъемно по производительности.
Вместе с тем если мы отказываемся от «изменить задним числом», а мы от него и так отказались, то можно к проводке добавить еще два поля — значение дебетуемого счета после проводки и значение кредитуемого счета после проводки.
В таком виде мы можем сразу получать состояние счетов на разную дату (сортировка по дате и условие что меньше или равно искомой дате), избавляемся от дополнительной таблицы, легко считаем обороты по счету, изменения за период и т.п.tefarov
30.08.2017 23:24Изменяя что-то задним числом вы рискуете нарушить целостность проводок которые были после того, ведь ваше изменение могло повлиять на условия при которых последующие проводки не имели бы смысла
Я говорил про нарушение целостности итогового баланса. Вопрос же права пользователя вносить сумятицу в его собственную бухгалтерию это скорее вопрос дизайна системы.
Такие операции слишком накладны
Не буду спорить. Всё зависит от масштаба и процесса. Мы используем двойной учёт для управленческих операций и у нас вопрос внесения изменений в большей степени актуален, чем вопрос производительности.Mendel Автор
31.08.2017 09:10Я не против внесения изменений задним числом. Иногда конечно лучше сторно, но если это не регламентированный учет и легитимность правок решена на другом уровне абстракции, то пусть себе правят. Я о другом. Не стоит давать пользователю возможность отстрелить себе ногу. Максимум тестов которые могут быть, должны быть. Соответственно я против того чтобы были правки «по тихому», не трогая последующие транзакции.
В очень простой логике это может сработать, но по мере роста объем логики для проверки таких вот изменений чтобы они не вызвали лавину проблем вам придется писать код который будет проходить все транзакции (не только проводки но и документы их вызвавшие) которые были после исправленной, и проверять что они будут нормально проходить в условиях изменений. А в таком случае смысл «тихой» правки исчезает. Вы все равно проходите всех «потомков».mayorovp
31.08.2017 09:37+1Смысл "тихой" правки — в возможности длительных исправлений. Скажем, отдел неделю расследует что натворили предшественники и исправляет ошибки — так что, все это держать в памяти?
Случается-то всякое, вряд ли разумно запрещать исправлять найденную ошибку только из-за того что это исправление выявляет еще три. Скажем, в базе записано что продали 600 слонов — а тут выяснилось, что этих слонов у нас на складе никогда не было. Что лучше: запретить вносить в базу поправку об отсутствии слонов на складе пока не выяснится чего же на самом деле продали — или внести информацию об отсутствии слонов, сохранить — и подсветить красным продажу того, чего не существовало?
Mendel Автор
31.08.2017 11:33Да, со скрипом соглашусь, что такой подход имеет право на жизнь.
Со скрипом потому что я бы предпочел при проведении правки об отсутствии слонов откатил бы все документы которые не проводятся в новых условиях (накладные на продажу слонов), а оперативную задачу «работаем хоть как-то» закрывал бы внеочередной инвентаризацией и продажей по состоянию из инвентаризации. Но Ваш подход да, имеет свои плюсы в этом случае.
Минус тут вполне существенный — вы не видите реальной картины. Что реально у вас не пляшет, ведь вслед за отменой проведения продаж у нас начнут не плясать деньги и т.п., и по результатам вполне может оказаться что на самом деле те слоны все-таки были, но получены были на день раньше или еще каким образом.
Разбор работы «папиредныков» лучше начинать с инвентаризации. И уже когда есть инвентаризация, то тебе не важно что было раньше. От инвентаризации до инвентаризации склад зависит только от правильности текущего учета (не только склад конечно). А значит проводить частичное исправление которое тянет за собой кучу красного нет смысла.
Но в целом — ок, согласен, возможен случай когда мы живем с красным.
Но все равно предвычисления счетов лучше делать. Отвечу ниже об этом.
mayorovp
31.08.2017 09:30Дополнительные поля с балансом — это лишние трудности по их поддержке в актуальном состоянии. Лучше уж вот так:
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
Извиняюсь за русский язык перед теми кому он режет глаза, но мне лень искать правильный перевод терминов на английский
Mendel Автор
31.08.2017 11:41+1Вьювы, жоины, агрегация, сложные индексы, и все это для того чтобы уйти от денормализации? Зачем? Вот зачем так утяжелять логику?
«потому что так правильно»? Нет, не правильно.
Сначала мы делаем нормализацию, потом ПРИ НЕОБХОДИМОСТИ делаем денормализацию, и это нормально.
Поддержка такой денормализации ничуть не сложна.
Если мы делаем изменение старых проводок, то у нас есть сумма на которую было изменение. Оно касается ВСЕХ состояний счетов (дебетуемого и кредитуемого) ПОСЛЕ даты изменения. Так что просто делаем один апдейт (или два, если мы делали в лоб как я писал — один для кредита, другой для дебета), с одним условием, который просто добавляет всем сумму изменения (если сумма отрицательная, то уменьшает). Всё.mayorovp
31.08.2017 12:07В чем вы видите утяжеление логики? И где тут сложные индексы?
Mendel Автор
31.08.2017 12:20Вот это вот всё, что вы нагородили это утяжеление логики. Вынос логики в базу это тоже не лучший паттерн. Но этот холивар не по теме статьи.
Я не уверен насколько адекватны по скорости будут индексы у вьювов с агрегирующими функциями. И не хочу этого узнавать.
Все это делается 1-2 апдейтами в тех редких случаях когда надо править логику.
Я соглашусь вынести состояния счетов из проводок в отдельную таблицу, со ссылкой на проводку которая к этому состоянию привела, но городить вот такое — я против, да.
Varim
31.08.2017 14:45Если мы делаем изменение старых проводок, то у нас есть сумма на которую было изменение.
Да, сумма есть, и ее нужно записать во все 10 000 последующих проводок.
Если нужно поправить 10 проводок, то 10 раз перезапишется «пол базы»?Mendel Автор
31.08.2017 15:00А в чем проблема? Ну перезапишем десять раз «полбазы» и что? Тут предлагают при каждом просмотре считать всю сумму всех проводок, а вы боитесь разово, при редком изменении сделать один запрос? ОДИН, не пачку. Ну десять изменений, десять запросов. В любом случае нагрузка ниже на порядки.
Varim
31.08.2017 15:211) чтение не запись, тем более для SSD
2) mayorovp предлагает индексированное представление. Об этом говорит with schemabinding и unique clustered index.
Индексированное представление автоматически перевычисляется при изменении исходных данных.
3) не нравится Индексированное view, можно использовать тригеры БД или просто считать итоги в логике и писать в таблицу итогов. (но я не уверен что не потерял какую то вашу суть, почему вы именно так сделали)Mendel Автор
31.08.2017 18:521) чтение совсем не запись, поскольку в реальных кейсах выполняется не в разы, а на порядки чаще. Счет идет реально на порядки, так что некоторое удорожание за счет более дорогой записи — ничтожно. В особенности если учесть тот факт что запись затрагивающая значительное колво строк — исчезающе редкое явление связанное с ошибками учета. Штатная запись затрагивает лишь текущие единицы строк
2) Я понимаю что у mayorovp речь идет об индексированных данных. Однако я не знаю как конкретно такие сложные индексы поведут себя в различных СУБД. И знать не хочу. Зато я знаю что простое обновление руками будет дешевым и простым. Подумайте еще раз. В идеальном случае, если СУБД идеально решит вторую фундаментальную проблему программирования (инвалидация кеша) — мы получим ровно тоже количество операций записи что и в моем варианте. Вам надо будет обновить все индексы связанные с этим конкретным счетом, и только их. Что я делаю вручную, напрямую указав это в запросе. Вместе с тем далеко не факт что СУБД сможет понять этот факт и не начнет пересчитывать индекс при каждом изменении а не только при тех которые нужны.
3) Да, я храню предвычисленные значения на каждый момент времени в отдельной таблице итогов и обновляю ее в логике. Да, я не люблю нагружать логикой базу, и по возможности избегаю вьювов и тригеров там где этого можно избежать без существенных потерь в производительности или архитектурных сложностей. Но дело не в этом. Нить данной дискуссии началась на том что кто-то здесь предложил отказаться от таблицы счетов вообще и хранить всю информацию только в проводках, а значения счетов вычислять каждый раз суммируя. Я предложил вариант который тоже будет с одной таблицей, но без чрезмерных вычислений — добавление результирующих значений прямо в таблицу проводки. mayorovp на это предложил вместо денормализации сделать вьюв…Varim
31.08.2017 19:11+1вторую фундаментальную проблему программирования (инвалидация кеша)
Подскажите, какие первая и третья фундаментальные проблемы программирования? А четвертая и пятая есть? Я не троллю.Mendel Автор
31.08.2017 19:18+1Классика:
В программировании существует лишь два характерных затруднения: инвалидация кеша, наименование сущностей и ошибка на единицу
mayorovp
31.08.2017 20:38Вместе с тем далеко не факт что СУБД сможет понять этот факт и не начнет пересчитывать индекс при каждом изменении а не только при тех которые нужны.
Тем не менее, это факт. MS SQL (а я писал используя его синтаксис) просто не позволит вам создать такой индекс который не cможет потом эффективно поддерживать при обновлениях.
Mendel Автор
31.08.2017 22:33А Мускул? А SQLite3? А…
Ну это же не серьезно. Ну вот честно.
Есть готовое решение в одну строку, которое использует минимальный синтаксис и заведется даже на СУБД на файлах, при этом имеет идеальную эффективность.
Вы предлагаете заменить это решение на другое. Новое решение работает только на некоторых СУБД. Оно занимает экран кода. При этом ПРЕДПОЛОЖИТЕЛЬНО может достигать почти такую же эффективность как у первого решения. Плюсы? Плюс только один — «потому что могу!».
И да ваш вариант даже чисто теоретически не сможет быть равным по скорости с моим. Как внутри работает индекс? Ведь любая СУБД работает с файлами, в которых существуют таблицы, а индексы это просто особая форма таблицы (да, деревья тоже выглядят как таблица). Фактически добавляя индекс мы создаем некую служебную таблицу которая обновляется по определенным правилам. Чтобы понять что его нужно обновлять СУБД вешает некий триггер (не совсем, но суть похожая) на те таблицы что участвуют в индексе. При изменении тех таблиц запускается наш триггер который проверяет должен ли текущий запрос повлиять на данные которые отражены в индексе, потом определяет какие именно поля он должен затронуть, и изменяет индекс (если нужно). Другого варианта особо то и нет. В вашем случае если даже допустить что СУБД сможет построить идеальное условие и идеально определить какие записи в этой служебной таблице индекса (полный аналог моей кстати), то все равно она будет выполнять этот анализ при КАЖДОМ изменяющем запросе. Это абсолютно принебрежимый оверхед, но он есть, да.Varim
31.08.2017 23:00Интересно, вы на каком языке пишите, со сборкой мусора? У вас между запросами от UI приложение умирает, или есть какое то «статическое» поле, которое содержит данные между запросами?
У вас случайно нет тяжелых структур в памяти которые приходится создавать/обновлять при каждом запросе?
Как вы поддерживаете иерархию итогов по счетам/субсчетам и по каталогу товаров с группами?Mendel Автор
31.08.2017 23:19А как все эти вопросы влияют на обсуждаемую тему и тем более на основную тему данной статьи?)
Я ведь не затрагиваю вопрос того что вьюв mayorovp не особо красив, равно как и не спрашиваю цвет ваших глаз :)
Единичный апдейт вызываемый раз в день а то и раз в пару месяцев будет много проще и быстрее чем вьюв на полстраницы вызываемый постоянно по тысяче раз за один отчет. Всё.
khim
31.08.2017 13:32+1Так что «изменять задним числом» я вам не советую даже рассматривать.
На самом деле тут есть важный момент, который вы подразумеваете, который нигде не упомянули явно, но который принципиально важен.
Дело в том, что есть бухгалтерия и «бухгалтерия за 10000 рублёв раз в неделю». Последнее — это особый жанр, собственно к бухгалтерии имеющий мало отношения. Это, грубо говоря, когда вы получаете раз в неделю кучку проводок (но не все!) и задание — «изобразить что-нибудь для налоговой».
Вот тут и изменение сумм задним числом и перенос дат транзакций (чтобы счета «посредине» не становились отрицательными) и многое другое — невероятно востребовано и полезно.
Но к тому, что обычные люди, не «мелкие предприниматели на карман» понимают под словом «бухгалтерия» это имеет мало отношения.Mendel Автор
31.08.2017 14:36А потом через полгода всплывает накладная на полмиллиона на которую ты налоговую накладную в базу не занес. Ага. Видели.
Приходящий бухгалтер хорош когда на предприятии есть кто-то, кто и без бухгалтера следит за фин.дисциплиной. Или внятная управленческая система учета которая делает это автоматически. А иначе — хаос.
Но я говорю о другом.
Исправления задним числом нужны, без них никуда. Сторно это мучение.
Но плохо как раз делать исправления не проверив что оно не покалечило другие операции.
bormotov
30.08.2017 23:22+1Везде говорят, что для минимизации ошибок нужно избегать дублирования информации,
В этом месте всем передает привет CRC, ECC, и прочие способы избыточно кодировать информацию, что бы было легко обнаруживать ошибки, корректировать и так далее.
VolCh
31.08.2017 09:43Двойная запись — это термин из времён бумажной бухгалтерии, когда агрегацию по счетам (само слово «счёт» намекает, что это агрегат каких-то первичных данных) из единой «базы» в виде «амбарной книги» делать было весьма затруднительно, а значит нельзя было контролировать остатки по счетам, особенно в момент проведения операции. Придумали «материализованные вьюхи» в виде карточек счетов с текущим балансом, на которые ссылаются записи в «амбарной книги». Но поскольку в проводке участвует два счёта (откуда-то взяли и куда-то положили), то балансы счетов нужно менять одновременно в двух карточках. Отсюда и «двойная запись». Сейчас это актуально при, например, использовании реальных материализованных представлений, когда СУБД изменяет две записи вьюхи при добавлении проводки в таблицу.
Eldhenn
31.08.2017 12:45+2> Везде говорят, что для минимизации ошибок нужно избегать дублирования информации
Правильно говорят. Только двойная запись — это не дублирование информации.
Бухгалтерия отражает движение материальных ценностей, выраженных в денежных единицах. Любое движение имеет две точки — начало и конец, ушли и пришли, источник и назначение. В обывательской логике привычно думать, что бывают операции, которые имеют одну точку — но это неверно. Точек всегда две и только две. И даже обыватель всегда фиксирует обе точки, только одну из них «держит в уме», и делает вид, что её не существует.
speshuric
31.08.2017 09:13+4Статья читается тяжеловато, в ней излишне упрощено всё что можно и нельзя и вместе с упрощением выкинут смысл бухучета. Эти же упрощения приводят к явно неправильным аналогиям.
Примерно так:
- Аналогия "активные — распоряжаемся, пассивные — не можем распоряжаться" не отражает сути. Например смотрим на амортизацию: в РСБУ и МСФО это же пассивный счет, а "распоряжаться" мы им можем. А вот каким нибудь счетом "Общепроизводственные расходы" (который активный) мы вряд ли можем распорядиться.
- А почему пришлось вводить эту аналогию? А потому что цели и принципы бухучета выкинули. Зачем мы вообще считаем эти "счета" и "проводки"? Чтобы бухгалетру было чем заняться? "Понимать общую картину финансов" это и звучит неопределённо и, если уж честно, то бухучет часто скрывает ключевые показатели "общей картины". И, да, упомянутые забалансовые счета, как раз один из компромиссов можду "учесть" и "не укладывается в модель". Потому что там есть например что-нибудь типа "товары на реализации", которые как бы и не наши, но если мы их потеряем, то платить придётся.
В современном мире у бухучета дофига смысловой нагрузки, конечно, это и "стандартный язык" и учет всякой ереси и фискальные учеты, но, насколько я понимаю, главная цель бухучета — посчитать финрез и объяснить из чего он сложился. Мы заработали или угорели? Нам вообще есть из чего дивиденды платить? А из чего складывается финрез? - Но чтобы учет был учетом, а не фантазией фаундера стартапа, нужны принципы.
- Непрерывность (мы не можем пропустить годик и сделать вид что всё ОК, остатки на конец года и на начало следующего — равны),
- объективность (все записи должны подтверждаться бумажкой),
- своевременность (его назвают принцип "начисления", если сделка заключена в январе, то и проводки в январе),
- единая "единица измерения" — деньги, причем в одной валюте. На самом деле принципов больше, но я их не помню :)
- Ага, у нас есть цели и принципы-правила. А вот теперь из принципов-правил мы приходим к инструментам. Из того, что мы считаем "финрез" мы получаем формулу
ФинРез=Наше-НеНаше, или если перенести, тоНаше=НеНаше+Финрез. А теперьНашеназовём активы, аНеНаше+Финрез— пассивы. Осталось ввести правило двойной записи, т.е. у нас проводки могут быть только такие что меняется одинаково пассив и актив, либо внутри пассива и актива "переносится". Осталось назвать "плюс" по активам "Дебетом", по пассивам "Кредитом" (и наоборот). - А дальше надо построить систему счетов и допустимых проводок, которые будут строить наш учет. Тут уже придётся продумать, как сделать такие счета, чтобы учитывать, например, оборудование, которое куплено явно не на один год так, чтобы одновременно знать сколько оно стоило, сколько оно стоит, и если считать, что затраты на это оборудование должны "отбиться" за 5 лет, то насколько эти затраты уже "отбились". Здесь, кстати, если аккуратно разбирать вопрос, то становится абсолютно понятно, что амортизация и срок службы оборудования вещи вообще говоря слабо связанные. Аналогично надо придумать схему проводок и счетов для отражения, например, товара на складе и проводок при его покупке (чтобы отразить финрез). А чтобы бухучет одной организации можно было сравнить с другим, появились стандарты учета (РСБУ, МСФО, GAAP), которые состоят как из "паттернов", так и из конкретных требований по использованию "паттернов".
Дальше. Два счета в проводке — это конечно хорошо, но почему "три счета слишком затруднит контроль правильности"? Да хоть 8, если в сумме по дебету и кредиту одинаково. Это весьма синтетическое ограничение, которое может быть полезно (например, появляется возможность оперировать показателем "обороты между счетами"), а может быть очень неудобно. И в этом же месте можно ввести название: часть проводки по одному счету по одной "стороне" (дебет или кредит) с суммой — корреспонденция или в крайнем случае "полупроводка".
Вообще есть нюанс, что принцип двойной записи, как ни странно, в бумажном виде это скорее три записи, чем две ("главная книга" и суммы в дебет и в кредит), а "двойная" скорее относится к тому, что у проводки есть 2 стороны. В компьютерном мире, конечно, записей может быть как одна, так и много.
Проводки одного документа должны находиться в одной транзакции СУБД — почему? Про одну проводку вопросов нет — она должна быть в одной транзакции. Причем в большинстве систем проводка это относительно сложная сущность которая отражается в несколько таблиц. А почему все проводки документа должны (вот так вот безаппеляционно) быть в одной транзакции СУБД? А как быть если в накладной 20 слонов, а у нас вместо пары слонов жирафы у забора дерево обгладывают или еще что-то подобное? Ситуаций в учете много и вот так железобетонно говорить вешать учетные принципы на некие "транзакции СУБД" неправильно.
Самое смешное, что всё это разжёвано и пережёвано в куче книг, статей и курсов. На книжку по основам бухучета у среднего программиста, который (для примера) разобрался, как внутри работает git или даже может написать неблокирующий стек и может вспомнить все паттерны GoF, уйдет 2-4 часа, если не начинать укуриваться деталями. За столько же времени на пальцах и с коньяком объяснит суть учета хороший замглавбух (главбух слишком усложнит, рядовой не объяснит).
Mendel Автор
31.08.2017 10:30-1Спасибо за объемный комментарий. Давайте обсудим.
Аналогия «активные — распоряжаемся, пассивные — не можем распоряжаться» не отражает сути.
В статье их несколько. Даже Ржевского я не случайно упомянул, и отдельно привел шпаргалку с тем что куда относится. На самом деле дать «правильное» определение бесполезно. Подавляющее большинство полноценных бухгалтеров (я имею ввиду главного или единственного а не «участкового») сути не понимают, а работают исключительно за счет того что у них есть регламентированный план счетов, и в нем все расписано. Помнят какие-то ассоциации, но именно самую суть не улавливают и как только отходишь от регламентированного и можешь составлять полностью свой план счетов — начинают нести полную ахинею. Недавно слышал от главбуха определение от ликвидности. Мол ликвидное активное, неликвидное пассивное.
Например смотрим на амортизацию: в РСБУ и МСФО это же пассивный счет, а «распоряжаться» мы им можем.
Как мы можем распоряжаться амортизацией?Могу копать, могу не копатьМогу амортизировать, могу не амортизировать, или амортизировать дольше? Это пассивная форма «распоряжения» сродни «могу вернуть кредит дострочно, могу не вернуть вообще, а могу попросить реструктуризацию на больший срок».
А вот каким нибудь счетом «Общепроизводственные расходы» (который активный) мы вряд ли можем распорядиться.
Общепроизводственные расходы это чертов «божественный объект» или папка «неперебранное», и вот так вот им целиком распорядиться сложно. А вот конкретными благами которые туда попали — да, можно распоряжаться. Конечно если мы сдадим секретаршу и ксерокс в аренду, то регламентрированный учет заставит нас перенести эти активы на другой счет, но да, мы можем ими распоряжаться. См. мой пример со счетом «Убытки (украли слонов)» — можно простить, «повесить» на охранника, получить страховку и т.п…
Ну не получится такие фундаментальные понятия описать коротким и емким определением чтобы человек не понявший самого принципа двойной записи смог его понять. Не получится.
Понятия активных/пассивных счетов, дебета/кредита и т.п. контринтуитивны, пока не начинаешь мыслить в терминах баланса/проводок.
И да, еще раз повторюсь — это не академическая статья, и не бай Боже не статья по регламентированному учету. Только про основы. Чтобы ПРИНЦИПЫ люди могли использовать в биллингах, ERP и т.п.
А почему пришлось вводить эту аналогию? А потому что цели и принципы бухучета выкинули.
Статья и так вышла огромной, при том что содержит лишь треть от того что я хотел, и все равно находятся те кто не понимает, и нужно еще разжевать. Вводить дискуссию на тему зачем оно нужно? Это Хабр а не Талмуд.)
И, да, упомянутые забалансовые счета, как раз один из компромиссов можду «учесть» и «не укладывается в модель». Потому что там есть например что-нибудь типа «товары на реализации», которые как бы и не наши, но если мы их потеряем, то платить придётся.
Забалансовые счета это рудимент, поскольку когда бухучет зарождался еще не было программистов, архитекторов и внятных принципов проектирования.
Сделайте два счета — пассивный «Обязательства по товарам на реализации» и активный «товары на реализации» (скорее всего субсчетом «товары на складе»). Всё. Двойная запись, баланс, единообразие архитектуры — всё есть. «Нельзя отражать на балансе то что не наше»? Почему? «Потому что оно отражено на чужом балансе». Но почему черт побери? Они мне его отдали, как оно может у него на балансе быть? Да, у него есть актив «реселлер должен нам товар или деньги», но товар у кого? Кто должен быть балансодержателем? Нет, я знаком с регламентированным учетом, но «по совести»? Но даже если и так, даже если мы не хотим раздувать валюту баланса (не вижу причин — единственный случай когда я использовал валюту так это при анализе устойчивости бизнеса и качества структуры активов при анализе потенциальных заемщиков в банке, и там я бы предпочел видеть такие заемные активы как арендованное оборудование и т.п. в балансе а не за балансом, но черт с ним, хотите за балансом — допустим) — сделайте все счета вложенными в «папочки» (на подобии счет/субсчет) и верхними папками сделайте баланс и забаланс. Всё.
главная цель бухучета — посчитать финрез и объяснить из чего он сложился. Мы заработали или угорели? Нам вообще есть из чего дивиденды платить? А из чего складывается финрез?
Что собственно и есть «общая картина финансов» :)
Я не заикаюсь о различных коэффициентах оценки активов, но даже просто если кратенько описать все виды балансовв (просто скопировав статью из википедии), то у многих читателей закипит мозг. Давайте сначала научимся получать нашу «общую картину» а потом уже будем учиться ее правильно читать.
Но чтобы учет был учетом, а не фантазией фаундера стартапа, нужны принципы
Стоп, стоп. Это статья не про принципы и бухучет, а лишь про двойную запись. Напишите статью про принципы, киньте ссылку здесь, наверняка кто-то даст вам инвайт за нее. Я еще раз повторюсь — я не ставил себе цель уложить пять лет обучения бухгалтера в одну статью.
Из того, что мы считаем «финрез» мы получаем формулу ФинРез=Наше-НеНаше, или если перенести, то Наше=НеНаше+Финрез. А теперь Наше назовём активы, а НеНаше+Финрез — пассивы.
А убытки то наше или ненаше? а финрез это что? А зачем двойная запись если можно одинарной? Ой, а амортизация это финрез или актив, ведь амортизация же наша?.. Это только кажется что так проще, потому что на самом деле у вас уже есть в голове готовая картина и понятные термины, а когда видишь это впервые — будут миллионы вопросов, вы будете разжевывать и получите тоже что у меня, только еще в пять раз больше текста потому что будете рассказывать о принципах (на которых 90% айтишников бросят читать ибо нудятина и капитанство).
А дальше надо построить систему счетов и допустимых проводок, которые будут строить наш учет. Тут уже придётся продумать, как сделать такие счета, чтобы учитывать, например, оборудование, которое куплено явно не на один год так, чтобы одновременно знать сколько оно стоило, сколько оно стоит, и если считать, что затраты на это оборудование должны «отбиться» за 5 лет, то насколько эти затраты уже «отбились». Здесь, кстати, если аккуратно разбирать вопрос, то становится абсолютно понятно, что амортизация и срок службы оборудования вещи вообще говоря слабо связанные. Аналогично надо придумать схему проводок и счетов для отражения, например, товара на складе и проводок при его покупке (чтобы отразить финрез).
Вот про это я честно говоря боюсь даже начинать писать. Напишите. Честно.
Будет интересно всем. Даже если будет сумбурно. Нормального материала по тому как разрабатывать собственный план счетов и собственный регламент — просто нет. Оно размазано по частям по миллионам книг и теорий, но даже плохенькие статьи на эту тему всегда интересны.
А чтобы бухучет одной организации можно было сравнить с другим, появились стандарты учета (РСБУ, МСФО, GAAP), которые состоят как из «паттернов», так и из конкретных требований по использованию «паттернов».
Вот не хочу я за регламентированный учет вообще говорить. Он есть. Он такой как есть. Он имеет кучу плюсов, и кучу минусов. По нему написано очень много материала. Бери, изучай, копируй, улучшай. Разве что вскользь упомянуть что сравнивать можно только сделанное по одинаковым стандартам, и для этого существует регламентный учет, но раскрывать тему — фи. Для этого есть нархоз и пять лет учебы.
Дальше. Два счета в проводке — это конечно хорошо, но почему «три счета слишком затруднит контроль правильности»? Да хоть 8, если в сумме по дебету и кредиту одинаково. Это весьма синтетическое ограничение, которое может быть полезно (например, появляется возможность оперировать показателем «обороты между счетами»), а может быть очень неудобно. И в этом же месте можно ввести название: часть проводки по одному счету по одной «стороне» (дебет или кредит) с суммой — корреспонденция или в крайнем случае «полупроводка».
Вообще есть нюанс, что принцип двойной записи, как ни странно, в бумажном виде это скорее три записи, чем две («главная книга» и суммы в дебет и в кредит), а «двойная» скорее относится к тому, что у проводки есть 2 стороны. В компьютерном мире, конечно, записей может быть как одна, так и много.
Меньше чем два нельзя ибо не будет баланса, больше не стоит поскольку усложняет архитектуру. Я не буду углубляться в то почему усложняет ибо это не по теме будет.
Проводки одного документа должны находиться в одной транзакции СУБД — почему? Про одну проводку вопросов нет — она должна быть в одной транзакции. Причем в большинстве систем проводка это относительно сложная сущность которая отражается в несколько таблиц. А почему все проводки документа должны (вот так вот безаппеляционно) быть в одной транзакции СУБД? А как быть если в накладной 20 слонов, а у нас вместо пары слонов жирафы у забора дерево обгладывают или еще что-то подобное? Ситуаций в учете много и вот так железобетонно говорить вешать учетные принципы на некие «транзакции СУБД» неправильно.
Нет, и не может быть никаких ситуаций в которых можно «провести» заведомо неверный документ (неверный с точки зрения текущего учета). Если у нас вместо 20 слонов оказывается 18 слонов и два жирафа, а жирафов у нас нет, то мы переделываем документ который вызвал проводки которые вызвали проблему, и проводим уже исправленный документ. Нельзя быть «чуточку беременной», нельзя быть «частично проведенным документом». Нельзя.
Самое смешное, что всё это разжёвано и пережёвано в куче книг, статей и курсов. На книжку по основам бухучета у среднего программиста, который (для примера) разобрался, как внутри работает git или даже может написать неблокирующий стек и может вспомнить все паттерны GoF, уйдет 2-4 часа, если не начинать укуриваться деталями. За столько же времени на пальцах и с коньяком объяснит суть учета хороший замглавбух (главбух слишком усложнит, рядовой не объяснит).
Вам шашечки или ехать? 90% программистов не пойдут тратить 4 часа своей жизни чтобы узнать нужен ли им бухучет и правильная ли это вещь.
Я видел колоссальное количество различных биллингов и прочих приложений где можно было обойтись парой таблиц в духе баланса и проводок а городили адский ад, а потом на него нагораживали еще кучу костылей, и все равно получалась каша.
Казалось бы, зачем программисту которому заказали простенький биллинг для хостинга — читать учебник по бухучету? Где бухучет а где биллинг? А мою статью прочесть за 10 минут с комментариями — вполне реально.mayorovp
31.08.2017 10:51-1Вот как раз для биллинга все эти двойные записи и проводки — лишнее.
Mendel Автор
31.08.2017 11:44Это пока вы не начинаете развивать бизнес-логику.
Как только вы хотите видеть и «кредит пока не оплатит», и прибыльность клиента, и можем ли мы дать клиенту скидку (по чем мы брали этот сервер) и т.п.
Слишком, слишком много сущностей выплывает.
redmanmale
31.08.2017 11:44+3Очевидно
что не все йогурты одинаково полезнысуществует большая разница между счетами отражающими деньги в «кассе» от того сколько мы должны денег поставщикам. Соответственно мы разделяем нашу табличку на две.Нет, не очевидно.
Один счёт — одна таблица. Потратил деньги — минус, заработал — плюс.
Счетов должно быть несколько, вот это очевидно. В вашем примере это ЯндексДеньги, пейпал, наличка,...
Mendel Автор
31.08.2017 12:09Спасибо за ваш вопрос.
Вы совершаете самую распространенную ошибку.
Вы предлагаете выкинуть часть счетов считая что они придуманы искусственно.
На самом деле все они всегда существуют, просто в неправильном учете их «держат в уме».
В уме держат сколько должен клиент. В уме держат сколько мы должны поставщику, в уме держат сколько кто из учредителей внес в проект, в уме держат на что пошли эти деньги.
Всё это держат в уме.
А потом получается хаос.
Потом это «в уме» забывается, запутывается и все эти ошибки всплывают лишь тогда, когда уже слишком поздно.
VolCh
31.08.2017 12:20+2Дал деньги в долг — это потратил? Получил долг назад — это заработал? А если не деньги дал, а клиенту товар или услугу в кредит предоставил? А обналичка ЯДа? Вроде потратил, вроде заработал, но заработал меньше чем потратил.
Varim
31.08.2017 12:37Простите, статью пробежал вскользь.
У вас есть ситуации когда на одном и том же счете, в остатках есть суммы как по дебиту так и по кредиту?
Давно не работал с бухгалтерией, вроде это активно пассивный счет называлось.
Кстати, а кроме суммы, количество у вас можно считать?
И еще, поиск по статье не находит слово «субконто».Mendel Автор
31.08.2017 12:42На активно-пассивном счете теоретически может быть либо кредитовое сальдо, либо дебетовое. На практике у нас есть такое понятие как счет и субсчет, где счет агрегирует в себе значения нескольких разных субсчетов, например счет взаимоотношения с контрагентами будет агрегировать как счета где нам должны клиенты так и счета где мы должны поставщикам (или клиентам оплатившим предоплату), так что в реальном учете такое бывает.
И именно по этой причине я против активно-пассивных счетов. В статье я такие счета не описываю, и в своих системах учета такие счета не ввожу. Но в регламентированном учете такие счета существуют.Varim
31.08.2017 12:48+1в своих системах учета такие счета не ввожу. Но в регламентированном учете такие счета существуют.
Вот в чем дело, мне казалось что нужно решать задачи бизнес требований (требований бух. учета, например).
В голове такая картина — подходит ко мне бухгалтер и говорит: «мне вот нужна такая проводка и такой активно пассивный счет», а я такой бухгалтеру — «обломиська! Я не завожу такие счета, которые вам нужны».
Мне интересно, как вы обходите требования бухгалтеров, нагибаете их что бы они прогнулись под вас? И что, никогда расхождений с законодательством не бывает?Mendel Автор
31.08.2017 13:01Активно-пассивный счет легко реализуется парой активного и пассивного с помощью автоматического перебрасывания с одного на другой. В начале комментариев более подробное обсуждение.
Плюс я не пишу (пока) конкурента 1С, и не занимаюсь регламентированным учетом.
Бухгалтеру он понадобится однозначно, а финансисту — не факт.
Ну и да, если честно то по результатам текущей оффлайновой дискуссии по этому поводу, я над своей позицией по активно-пассивному начинаю слегка сомневаться.
Rampages
31.08.2017 15:25А если по одному договору у клиента дебет, а по другому кредит? Вообще как договора сопрягаются со счетами?
p.s. может сморозил глупость т.к. не разобрался в учете…Mendel Автор
31.08.2017 19:11В таком случае зависит от того что прописано в договорах, или от того как конкретно тот кто-то самый наглый решает считать :)
Реально можно как зачитывать так и не зачитывать.
По хорошему надо делать сверку и предлагать делать зачет.
Вопрос только кажется простым. Вроде договора однородные, сроки по обоим вышли, процентов нет, валюта одна, штрафных санкций нет, чего бы и не зачесть?
Однако моментов бывает множество.
Например в системах налогообложения основанных на обороте — прямо запрещены бартеры, взаимозачеты и т.п. Только прямая денежная оплата.
Мне несколько раз приходилось гонять десятки миллионов (не рублей и не гривен) по кругу между связанными организациями поскольку чисто по требованиям гос.органов нельзя было делать взаимозачеты (большие суммы касались операций со ценными бумагами, но не суть, по требованиям фискалов тоже бывает такое). Но если контрагент не против, то делать взаимозачет хорошая практика.
mayorovp
31.08.2017 12:58Он активно-пассивные счета разбивает на связанные активный и пассивный. Так что технически ничего не мешает в таком составном счете иметь одновременно остатки и в активе, и в пассиве.
А вот для представления более логичного объекта — активно-пассивного счета с односторонним сальдо (который, между прочим, в том же биллинге встречается чаще чем все остальные типы счетов) предполагается вводить дополнительный модуль, который будет автоматически сокращать остатки.
Varim
31.08.2017 12:43-1А почему не рассматриваете активно-пассивный счет?
Мне интересно для себя, в мире бухгалтерии либо законодательстве может что то изменилось?Accounter
31.08.2017 13:11По общему правилу МСФО (и не только МСФО), дебиторская задолженность (долг нам) и кредиторская задолжность (наш долг другим) должны показываться отдельно: дебиторка в активе, кредиторка в пассиве — даже если это один и тот же контрагент (но два разных договора). Свернуть дебиторку и кредиторку между собой можно, только если в обоих договорах с данным контрагентом прямо указано, что стороны согласились не рассматривать задолженности по этим договорам раздельно.
Т.е. по умолчанию, учет задолженностей по разным договорам с одним и тем же контрагентом всегда расматриваются раздельно.
Если сворачивать — будет происходить занижение нашей реальной задолженности перед третьми лицами, которая публикуется во внешней отчетности или показывается банкам при получении кредитов.
Пример: мы должны Васе 100 рублей по кредиту, обеспеченный залогом и штрафными процентами, а Вася нам должен за товар 120 рублей. Если свернуть, то мы можем расслабиться — у нас нет долгов. Но на самом деле долг есть: мы должны Васе 100 рублей. И если мы про это забудем, то нам выставят штрафные проценты по кредититу и/или заберут залог. При этом Вася может продолжать тянуть с погашением своего долга 120 рублей нам.
Свернуть долг может принудительно только суд: мы подаем на Васю в суд на 120 рублей, а Вася выставляет встречный иск нам на 100 рублей. Суд сворачивает оба долга и выносит решение: Вася должен выплатить нам 20 рублей.mayorovp
31.08.2017 13:23Это вы рассматриваете ситуацию с разными договорами. Разные договора — разные счета, это очевидно.
Но такая ситуация может быть и в рамках одного договора. Например, при авансовых платежах. Вы же не станете утверждать что авансовый платеж нельзя "сократить" с более поздней задолженностью?
Accounter
31.08.2017 13:42Юридически можно. Но бухгалтерии все равно их не сворачивают. Если заказов десятки и сотни по договору, то при таком соврачивании потом концов не найдешь — из чего сложился итоговый долг покупателя или поставщика на дату сверки. Итог сверки между поставщиком и покупателем должен быть легко проверяемым, т.е. равен сумме их взаимных долгов по всем заказам данного договора.
mayorovp
31.08.2017 13:47И в чем же сложность "нахождения концов"?
Если "сворачивание" — отдельная операция, то да — она будет чисто визуально мешаться (потому мне и не нравится предложение автора о "наблюдателе"). Но если структура базы выстроена так, чтобы отдельное "сворачивание" просто не требовалось — то в чем сложность взять проводки по условию и посмотреть их?
Varim
31.08.2017 14:10Если свернуть, то мы можем расслабиться — у нас нет долгов. Но на самом деле долг есть: мы должны Васе 100 рублей.
Вы подразумеваете что сальдо по счету в разрезе контрагента всегда либо дебетовое либо кредитовое?
А разве нельзя сальдо по субконто не сворачивать, а так и оставить:
«счет: 33.6, субконто: ЧП Иванов, Дт: 100, Кт: 120»
вместо
«счет: 33.6, субконто: ЧП Иванов, Кт: 20»
То есть, сворачивание, это обязательное свойство счета?VolCh
31.08.2017 14:30+1Полный нарастающий итог за всю историю постоянно показывать при просмотре баланса счёта? Или каким-то специальным обязательным признаком в проводке указывать дебетуем/кредитуем мы активную или пассивную часть? Во втором случае это мало чем, по-моему, отличается от двух раздельных счетов.
Accounter
31.08.2017 15:39+1Вопрос не в сворачивании собственно. Вопрос на самом деле такой:
1) показать в отчетности актив 120 рублей и долг 100 рублей;
2) показать только актив в размере 20 рублей.
Ответ такой: правильный вариант — это №1, если это разные договоры. Или вариант №2, если это один договор (цепочка поставок и платежей по ним).Varim
31.08.2017 15:53Вроде в 1С был отчет «карточка счета» или еще какой то, и мне казалось в отчете на некоторых счетах можно было увидеть одновременно и дебетовый остаток и кредетовый, но возможно не в разрезе конкретного субконто.
Мне хотелось бы знать, нелогично ли, хотя бы у некоторых счетов, не «сворачивать» сальдо автоматически, а показывать оба остатка.
Например завести какой то флаг у счета, и назвать этот флаг "автоматически сворачивать сальдо".
А когда необходимо свернуть остатки, то тогда для этого делать специальную какую то проводку с одинаковым счетом по Дт и Кт, типа:
«счет Дт: 33.6, счет Кт: 33.6, субконто: ЧП Иванов, Сумма: 100»
где сумма 100 это min(120, 100)
Хотя, похоже что да, это скорее свойство не счета, а отчетной системы по счету.
Или флаг можно установить на комбинацию счета и субконто, например не сворачивать для комбинации счет+типСубконто1+типСубконто2 — «счет 33.6, Контрагент, договор»Mendel Автор
31.08.2017 19:15Вам не кажется что вы сейчас изобрели тот самый вариант который я озвучил в самом начале комментариев и который вы критикуете уже пол дня как?
Два раздельных счета, которые при необходимости (ваше «если есть галочка») сворачиваются автоматически.Varim
31.08.2017 19:27Понятно.
Дело в том что меня как раз интересуют всякие возможности учетных систем и для чего, в каких случаях, эти возможности применяются на практике.
Значит вы у себя задумали «возможность»-флаг «автоматически сворачивать сальдо».
Теперь мне бы еще узнать на каких счетах вы его включаете, а на каких выключаете, и зачем.
Если уже писали простите, длинный текст читаю бегло, если в нем обсуждают что то, что я уже долго не использовал.Mendel Автор
31.08.2017 19:31Очень зависит от конкретной задачи. Тут ведь уже отвечали — обычно в рамках одного счета «сворачивают», а в рамках разных — только по сверке.
Вместе с тем если это простая логика, например биллинг хостера, где есть счет клиента и его движения, то никто не заморачивается с разделением а делают активно-пассивный счет или в моем случае прописывают событие сворачивания при сохранении проводок на эти счета (в ваших терминах — стоит галочка).
Accounter
31.08.2017 13:05Если разница между активом и пассивом равна 10 рублей — значит бухгалтер ошибся один раз на 10 рублей.
А вот разница между активом и пассивом равна нулю, то значит бухгалтер ошибся два раза: первый раз на +1000000000 рублей, а потом второй раз на -1000000000 рублей :)Mendel Автор
31.08.2017 13:06Не всегда.
А если один раз ошибся на 1000, а второй раз на 990? Или ошибок было три и более?
VolCh
31.08.2017 13:41Как-то по статье вроде показалось, что она вообще о принципе двойной записи в учёте, типа подсказка для желающих биллинг или домашнюю бухгалтерию на коленке написать, не натыкаясь на камни, которые люди научились обходить если не несколько тысячилетий назад, то пятьсот лет назад точно, но по комментариям уже кажется, что она именно о регламентированном бухгалтерском учёте. Как впечатление правильнее?
Mendel Автор
31.08.2017 14:27Первое. Я не люблю регламентированный учет, и чуть ли не в каждом комментарии говорю что я его не затрагиваю. Но те для кого эта тема новая комментируют мало, в основном пишут те кто уже знаком с темой, так что в комментариях упорно скатываемся к регламентированному, как бы я от него не открещивался.
Varim
31.08.2017 14:55-2Я не люблю регламентированный учет
Следует ли добавить "и моя система не реализует его"… и тогда я задамся вопросом: «хм, а какое тогда есть моральное право у этого человека вообще учить как делать бух учет, он же похоже подлость делает новичкам учя их плохому»Varim
31.08.2017 15:39+1хотя… комментарии для того и есть что бы обсудить/поспорить
Mendel Автор
31.08.2017 19:21В том то и дело. Я ведь в самом начале написал что статья не академическая, а по основам. И везде говорю что в регламентированном учете немного не так, хоть принципы и сохраняются, но вы не можете произвольно организовывать логику, а должны пользоваться теми шаблонами что за вас придумали законодатели.
Что никак не отменяет того факта что активно-пассивные и забалансовые счета — лютый легаси, который нельзя бросить в регламентированном, но не стоит начинать в своем собственном управленческом.
Accounter
31.08.2017 13:53+2История в тему: «В одной бухгалтерии работал самый лучший бухгалтер. Все его считали самым умным. Каждое утро он открывал ящик стола и заглядывал в него. А потом закрывал ящик на ключ. И никто не знал что у него в ящике. Наконец, самый лучший бухгалтер ушел на пенсию. И вся бухгалтерия бросилась открывать его ящик чтобы посмотреть что у него там. А там была только одна надпись на дне: „Дебет — слева, кредит — справа“ :)
dmagin
31.08.2017 15:20+1Наброшу немного математики.
Если обобщать, то двойная запись — это частный случай «балансового вектора», — то есть вектора, сумма компонент которого равна нулю. Такие векторы удобны тем, что их можно складывать/вычитать — результатом снова является балансовый вектор.
Поэтому думаю, что должны существовать такие хозяйственные операции, которые удобно отражать «балансовой проводкой», а не двойной записью. В том смысле, что их принципиально нельзя свести к двойной записи.
Примером балансовой проводки на 4-х счетах может быть что-то типа (+50 Cч1, -40 Сч2, -20 Сч3, +10 Сч4).askv
31.08.2017 19:09В таких случаях в бухучёте обычно делается несколько проводок…
dmagin
31.08.2017 19:24Да, конечно, но тогда часть информации теряется. Например, о корреспонденции. Если приведенный выше вектор интерпретировать как результаты преферанса (двое выиграли 50 и 10 рублей, а двое проиграли 40 и 20), то в принципе можно сделать обычные проводки через доп. счёт (игральный стол), но тогда сложно извлечь инфу, кому именно проиграли (или выиграли) игроки.
Mendel Автор
31.08.2017 19:34А что сложного? У проводок всегда есть некий общий контейнер. Я называю его "документ". Каждая проводка ссылается на то какой документ ее породил, так что пройдя по одной проводке мы видим всю картину документа «результат преферанса».
Оффтоп: Сомневался стоит ли писать про документ, не усложнит ли… Оказалось что актуально. Уже несколько раз всплывал в этом обсуждении.dmagin
31.08.2017 19:41В нашей системе проводки объединятся в операции (в одном документе может быть несколько операций), но это не решает проблему корреспонденции, например. Как по итогам месяца посмотреть, кто у кого выигрывал в преферанс? Запрос будет сложным и неудобным.
Varim
31.08.2017 19:43В одной известной бух. системе, Операция это Документ.
В одной Операции может быть несколько Проводок.
А для чего в вашей системе несколько Операций для одного Документа?
Может у вас Операция это всего лишь одна Проводка?dmagin
31.08.2017 19:58Ну например операции "Реализация товара" и "Реализация услуг" могут выполняться в рамках одного документа. И состоять при этом из разных проводок…
Mendel Автор
31.08.2017 20:03В рамках какого документа? Чем руководствуетесь делая единый документ? Может лучше делать несколько документов, а общее для них называть «сделка» или что-то вроде?
dmagin
31.08.2017 20:14Конкретно в этой ветке мне бы не хотелось это обсуждать. Мы на эти вопросы ответили ещё 20 лет назад. Триада — "проводка, операция, документ" — универсальная модель организации учета.
Varim
31.08.2017 20:30Триада — «проводка, операция, документ» — универсальная модель организации учета
Гуглится что то не то, есть ссылка?
Mendel Автор
31.08.2017 20:42Ну если уж говорить об универсальной триаде, то это вопрос сугубо терминологический. Триада «проводка, документ, сделка» ничем собственно не отличается. Единственное что — да, по результатам этой ветки я себе выберу более нейтральные названия чтобы не было «документ» в этой цепочке.
Mendel Автор
31.08.2017 20:01А с проводками у которых есть множество счетов запрос будет простым?
Для начала мы будем вынуждены дробить такую проводку на единичные записи, поскольку нельзя сделать запись с переменным количеством полей (только давайте без 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 руб
Данные из таких проводок легко извлекаются и агрегируются.Varim
31.08.2017 20:24Немного позанудствую.
Разве так делают, а как на самом деле правильно делать проводки?
10 лет не в бухгалтерии, но вроде бы, сначала насчитывают долг, а потом по проводкам поступают «бумажные» денежки.
И вроде напрямую так не делают, а то если П1 дал деньгу В1, то получается что создался долг как будто В1 теперь должен П1, но ведь он не должен и не вернет никогда долг, проводки как то по другому принципу пишутся, через «вспомогательные» счета.Mendel Автор
31.08.2017 22:44Проводки пишутся так как записано в вашей учетной политике. Если мы говорим о регламентированном учете, то там мест для маневра не очень много, но они тоже есть. А для управленческого вы вольны строить как хотите.
Что касается последовательности проводок, то тут особой проблемы нет, ведь они у нас идут пачкой в одной операции/документе, и единой транзакцией.
Собственно поэтому я и говорю что все проводки одного документа лежат в одной транзакции, чтобы не было вот таких вот смущающих вас моментов «между».
А так то вообще задача у нас тут сугубо теоретическая ибо мне сложно понять что это за учет преферанса такой мы строим, а вы еще и регламентированный учет пришить хотите).
dmagin
01.09.2017 09:28Это, конечно, возможный вариант, но здесь вам пришлось сделать дополнительное допущение о принципе распределения долга. И выше правильно заметили, что участники могут и не придти к согласию об именно таком распределении долга. А если участников много, то замучаетесь распределять суммы и считать погрешности.
Обычно все же такое делают через доп. счет. Все проигравшие корреспондируют с ним с одной стороны, а выигравшие — с другой. Но там другое неудобство.
Я не уверен, что балансовые проводки нужны, — и лишь размышляю об этом.
Если в одной проводке допустить корреспонденцию нескольких счетов одновременно, то тогда при запросах о корреспонденции счетов следует, видимо, уточнять в какой стороне группировать счета — по дебету или кредиту.
Если, например, по дебету, то корреспонденция счетов в примере должна выглядеть примерно так:
В1 получил 50 руб. от П1 и П2
В2 получил 10 руб. от П1 и П2
А если по кредиту, то:
П1 отдал 40 руб. В1 и В2
П2 отдал 20 руб. В1 и В2
Тут нет никаких допущений о распределении сумм.
askv
31.08.2017 19:36Бухучёт и не ставит своей целью сохранение этой информации. Для этого ещё есть управленческий учёт.
dmagin
31.08.2017 19:43Да ладно ). Нормальная цель хорошего учета. Просто обычно извращаются различными способами, пытаясь ответить на подобные вопросы..
Mendel Автор
31.08.2017 20:05Хм… я возможно не сказал это прямо, но я настаиваю, что в основе управленческого учета должен тоже лежать свой баланс и свой специфический «управленческий» план счетов. Конечно это все обвешивается кучей доп.полей, кучей субконто, разными ценами (баланс, закупка, продажа) и кучей всего, но в основе — та же двойная запись.
Mendel Автор
31.08.2017 19:28Можно. Но не нужно.
Двойную запись проще контролировать чем множественную. Проще заносить в базу (иначе выходит EAV, что плохо).
Вместе с тем если уж совсем строго то вектор у нас N-мерный, где N равно количеству счетов в нашем балансе (всех, как активных так и пассивных, а не только тех по которым мы делаем операцию). А вектор соответствующий проводке это такой вектор у которого все измерения равны нулю кроме двух, обозначенных в проводке.
При этом аналогом вашей «балансовой проводки» в моих терминах является "документ" с которым связаны одна или несколько проводок. Их сумма (у которой остальные измерения равны нулю) и будет таким множественным вектором.dmagin
31.08.2017 19:53По поводу n-мерных векторов. Если задать матрицу расстояний между счетами, то оказывается, что проводка может быть описана двояким образом — контравариантным (обычным) и ковариантным (термины из тензорной алгебры). Обе проводки будут балансовыми и описывать один и тот же вектор, но когда у обычной проводки ненулевыми являются только две компоненты (двойная запись), то у аналогичной ей ковариантной звенят все компоненты.
Mendel Автор
31.08.2017 20:07Вот за что я люблю тензорную алгебру… а собственно ни за что не люблю))).
Но в качестве разминки для ума можно подумать об этом. Опишите плиз пример обеих записей применительно к счетам и проводкам, думаю многим будет интересно это увидеть.dmagin
01.09.2017 09:40Да я сам сильно удивился, обнаружив связь бухгалтерии и тензоров ). В результате и задумался о «балансовых проводках».
Но как просто описать в двух словах — пока не знаю. Возможно, как-нибудь в отдельной статье опишу.
mayorovp
31.08.2017 20:44В ортонормированном базисе ковариантные координаты совпадают с контрвариантными :-)
dmagin
01.09.2017 09:33Круто, что есть люди, которые об этом знают ). А можете догадаться, при каком условии бухгалтерские счета являются «ортонормированными»? То есть контравариантные проводки совпадают с ковариантными.
mayorovp
01.09.2017 09:43Зависит от того, какой смысл вкладывается в скалярное произведение двух счетов.
Лично я считаю, что смысла в таком произведении — нет, а потому для разных счетов там должен быть ноль, а для одинаковых — квадрат баланса. Значит, базис у нас ортонормированный.
Впрочем, если есть желание всех запутать — можно определить скалярное произведение как-нибудь по-другому. Только мне почему-то кажется, что бухгалтера такое не оценят.
dmagin
01.09.2017 10:13Ну, если говорить конкретно про «ортонормированный базис», то все проще ).
В том плане, что тут можно пока и без скалярного произведения обойтись.
Бух. счета — это вершины графа (если определять систему координат через связи между вершинами), или вершины симплекса (если определять ее через расстояния между вершинами). Так вот, если все расстояния (или связи) между вершинами одинаковы, то такой набор вершин (счетов) и соответствует «ортонормированному базису». В котором контравариантные и ковариантные проводки совпадают ).
А скалярное произведение везде одинаково определяется — через билинейную форму произведения векторов на метрический тензор.
mayorovp
Если уж мы программисты — надо упрощать модель, а не молиться на ее сложность. Достаточно сменить знак у всех пассивных счетов, и правила проводки упростятся до простого "дебит — всегда увеличивает, кредит — всегда уменьшает".
Mendel Автор
Я об этом написал в конце под заголовком «еще немного нормализуем».
Вообще я когда начинал писать статью, то думал опустить стандартное описание дебета и кредита, но решил оставить для лучшего понимания бухгалтеров.
mayorovp
А, вижу. Тогда у меня есть еще вопросы.
Рассмотрим ситуацию, когда некоторому контрагенту был выплачен аванс, ставший долгом контрагента — активом. Далее по договору контрагентом были оказаны какие-то услуги, в результате чего уже мы оказались ему должны — пассив.
Как такое отражать? Заводить два счета — или лучше вернуть тип счета "активно-пассивный" и разрешить его балансу "скакать" в обе стороны от нуля?
Mendel Автор
Я считаю что забалансовые счета и активно-пассивные счета это плохая архитектура, и вот почему:
Бизнеслогику активно-пассивных счетов мы легко можем реализовать шаблоном Наблюдатель, подписанным на оба счета, и создающим служебный документ с проводкой осуществляющей взаимозачет.
При этом если у нас будет активно-пассивный счет, то мы:
1) вносим лишнюю сущность
2) усложняем логику, в том числе логику контроля, логику отображения и т.п. Значительно усложняем, фактически в два раза усложняем
3) у нас исчезает возможность бизнес-логики при которой возможно что одновременно и мы должны контрагенту и он нам, например когда система налогообложения требует избегать взаимозачетов а только прямого расчета или сложные расчеты связанных компаний, когда фактические долги например в разных валютах и мы хотим согласовать курс, который может отличатся от балансового. Вариантов много где нужно отдельно иметь такие счета. Причем может оказаться что мы хотим такую логику ввести уже постфактум, когда уже несколько лет работали по простой. Такое изменение с активно-пассивными будет неудобно.
4) движения по счетам смешивается, мы не можем вести отдельный учет по оборотам. С двумя счетами у нас есть два дебетовых оборота и два кредитовых, а с одним — только по одному, а значит и информации меньше.
В общем не стоит смешивать сущности, не стоит. Не SOLIDно.
С забалансовыми сложнее, там больше случаев может быть, но по возможности я бы от них тоже отказывался. Если мы сами строим учет, у нас нет регламентированного плана счетов и т.п., то лучше без этих рудиментов.
mayorovp
А разве такой "наблюдатель" — не лишняя сущность?
Mendel Автор
Мой бухгалтер только что задала мне тот-же вопрос, только другими словами).
Нет, не лишняя, а «отдельная».
Если не выделять ее в отдельную сущность, то она никуда не девается, просто размазывается по множеству других сущностей.
Где отображать наш счет? В правой части или в левой?
С раздельными счетами просто, а тут нужно писать логику.
Дополнительный тип счета отражаемый в базе, в логике проверки целостности и т.п.
SergeyUstinov
Честно, очень смешные аргументы. Особенно «усложняем логику, в том числе логику контроля, логику отображения и т.п. Значительно усложняем, фактически в два раза усложняем» :)))
Возможно, вы сами до конца не понимаете предназначение именно фин счетов (синтетический учет).
Mendel Автор
Ок, вам смешно. Отлично. Смех это прекрасно. Не жадничайте. Аргументируйте. Я тоже хочу поржать вместе с Вами.