Comments 266
Если уж мы программисты — надо упрощать модель, а не молиться на ее сложность. Достаточно сменить знак у всех пассивных счетов, и правила проводки упростятся до простого "дебит — всегда увеличивает, кредит — всегда уменьшает".
Я об этом написал в конце под заголовком «еще немного нормализуем».
Вообще я когда начинал писать статью, то думал опустить стандартное описание дебета и кредита, но решил оставить для лучшего понимания бухгалтеров.
Вообще я когда начинал писать статью, то думал опустить стандартное описание дебета и кредита, но решил оставить для лучшего понимания бухгалтеров.
А, вижу. Тогда у меня есть еще вопросы.
Рассмотрим ситуацию, когда некоторому контрагенту был выплачен аванс, ставший долгом контрагента — активом. Далее по договору контрагентом были оказаны какие-то услуги, в результате чего уже мы оказались ему должны — пассив.
Как такое отражать? Заводить два счета — или лучше вернуть тип счета "активно-пассивный" и разрешить его балансу "скакать" в обе стороны от нуля?
Я считаю что забалансовые счета и активно-пассивные счета это плохая архитектура, и вот почему:
Бизнеслогику активно-пассивных счетов мы легко можем реализовать шаблоном Наблюдатель, подписанным на оба счета, и создающим служебный документ с проводкой осуществляющей взаимозачет.
При этом если у нас будет активно-пассивный счет, то мы:
1) вносим лишнюю сущность
2) усложняем логику, в том числе логику контроля, логику отображения и т.п. Значительно усложняем, фактически в два раза усложняем
3) у нас исчезает возможность бизнес-логики при которой возможно что одновременно и мы должны контрагенту и он нам, например когда система налогообложения требует избегать взаимозачетов а только прямого расчета или сложные расчеты связанных компаний, когда фактические долги например в разных валютах и мы хотим согласовать курс, который может отличатся от балансового. Вариантов много где нужно отдельно иметь такие счета. Причем может оказаться что мы хотим такую логику ввести уже постфактум, когда уже несколько лет работали по простой. Такое изменение с активно-пассивными будет неудобно.
4) движения по счетам смешивается, мы не можем вести отдельный учет по оборотам. С двумя счетами у нас есть два дебетовых оборота и два кредитовых, а с одним — только по одному, а значит и информации меньше.
В общем не стоит смешивать сущности, не стоит. Не SOLIDно.
С забалансовыми сложнее, там больше случаев может быть, но по возможности я бы от них тоже отказывался. Если мы сами строим учет, у нас нет регламентированного плана счетов и т.п., то лучше без этих рудиментов.
Бизнеслогику активно-пассивных счетов мы легко можем реализовать шаблоном Наблюдатель, подписанным на оба счета, и создающим служебный документ с проводкой осуществляющей взаимозачет.
При этом если у нас будет активно-пассивный счет, то мы:
1) вносим лишнюю сущность
2) усложняем логику, в том числе логику контроля, логику отображения и т.п. Значительно усложняем, фактически в два раза усложняем
3) у нас исчезает возможность бизнес-логики при которой возможно что одновременно и мы должны контрагенту и он нам, например когда система налогообложения требует избегать взаимозачетов а только прямого расчета или сложные расчеты связанных компаний, когда фактические долги например в разных валютах и мы хотим согласовать курс, который может отличатся от балансового. Вариантов много где нужно отдельно иметь такие счета. Причем может оказаться что мы хотим такую логику ввести уже постфактум, когда уже несколько лет работали по простой. Такое изменение с активно-пассивными будет неудобно.
4) движения по счетам смешивается, мы не можем вести отдельный учет по оборотам. С двумя счетами у нас есть два дебетовых оборота и два кредитовых, а с одним — только по одному, а значит и информации меньше.
В общем не стоит смешивать сущности, не стоит. Не SOLIDно.
С забалансовыми сложнее, там больше случаев может быть, но по возможности я бы от них тоже отказывался. Если мы сами строим учет, у нас нет регламентированного плана счетов и т.п., то лучше без этих рудиментов.
А разве такой "наблюдатель" — не лишняя сущность?
Мой бухгалтер только что задала мне тот-же вопрос, только другими словами).
Нет, не лишняя, а «отдельная».
Если не выделять ее в отдельную сущность, то она никуда не девается, просто размазывается по множеству других сущностей.
Где отображать наш счет? В правой части или в левой?
С раздельными счетами просто, а тут нужно писать логику.
Дополнительный тип счета отражаемый в базе, в логике проверки целостности и т.п.
Нет, не лишняя, а «отдельная».
Если не выделять ее в отдельную сущность, то она никуда не девается, просто размазывается по множеству других сущностей.
Где отображать наш счет? В правой части или в левой?
С раздельными счетами просто, а тут нужно писать логику.
Дополнительный тип счета отражаемый в базе, в логике проверки целостности и т.п.
Честно, очень смешные аргументы. Особенно «усложняем логику, в том числе логику контроля, логику отображения и т.п. Значительно усложняем, фактически в два раза усложняем» :)))
Возможно, вы сами до конца не понимаете предназначение именно фин счетов (синтетический учет).
Возможно, вы сами до конца не понимаете предназначение именно фин счетов (синтетический учет).
А давайте еще упростим. Дебет всегда увеличивает дебет. Кредит всегда увеличивает кредит.
А давайте… почитаем статью?
дебет увеличивает дебет, а кредит увеличивает кредит… гениально.
А кредит соответственно уменьшает дебет, а дебет соответственно уменьшает кредит?
где-то я это уже видел… постойте… а ну да, положительные и отрицательные числа.
Это я уже молчу что вы над терминологией надругались как над портовой девкой.
У нас тут спор между западной и советской школами, отчасти терминологический — на сотню страниц разросся, а вы тут «есть устоявшаяся терминология в несколько веков, но мне так удобнее, так что привыкайте»… Ну а про такие мелочи как проверка целостности базы и т.п. я вообще молчу… почитайте статью, почитайте, коль перешли сюда.
дебет увеличивает дебет, а кредит увеличивает кредит… гениально.
А кредит соответственно уменьшает дебет, а дебет соответственно уменьшает кредит?
где-то я это уже видел… постойте… а ну да, положительные и отрицательные числа.
Это я уже молчу что вы над терминологией надругались как над портовой девкой.
У нас тут спор между западной и советской школами, отчасти терминологический — на сотню страниц разросся, а вы тут «есть устоявшаяся терминология в несколько веков, но мне так удобнее, так что привыкайте»… Ну а про такие мелочи как проверка целостности базы и т.п. я вообще молчу… почитайте статью, почитайте, коль перешли сюда.
Довольно быстро разобрался с этим когда начал записывать расходы в GnuCash
Тоже использую GnuCash. Довольно топорный и примитивный, с дизайном из начала 2000-х, но блин, ничего больше нет. Жаль что ничего более современного и симпатичного на эту тему нет, чтобы не грузился 20-30 с (при том что на С написан), не требовал бы кучи ручных настроек (биржи, тикеры акций, валюты нужно руками подключать) и не использовал бы perl для синхронизации с внешними сервисами (курс валют, цена акций, и т.д.)
Перешел несколько лет с GnuCash на YNAB и очень рад. Он просто работает, никаких зависимостей и в комплекте с программой идёт идеология работы, помогающая тебе организовать свои финансы.
Более 10 лет пользуюсь AceMoney. Первая программа, которую без сожаления купил.
А GnuCash оттолкнул как раз «бухгалтерским» подходом при занесении записей.
А GnuCash оттолкнул как раз «бухгалтерским» подходом при занесении записей.
Ну как это нет. Есть:
Money Manager Ex (http://www.moneymanagerex.org) — бесплатная, открытая, в т.ч. есть клиенты для мобильных платформ. Сначала пользовался им, но в какой-то момент меня перестала устраивать не достаточная глубина анализа (нет возможности создавать разветвленную аналитику).
AbilityCash (https://dervish.ru/) — бесплатная, закрытая. Разрабатывается с начала 2000-х, поэтому интерфейс немного не свеж. По части глубины анализа существенно превосходит предыдущую, но нужно разобраться и настроить под себя.
1С: Деньги (http://v8.1c.ru/money/) — не бесплатная (но дешевая), «полуоткрытая» (поставляется только в базовом варианте, версии проф не бывает, поэтому править конфу нельзя, но внешние отчеты — пожалуйста). Есть какой-то мобильный клиент. Настраиваемая как душе угодно аналитика, хорошие отчеты (если знаете СКД, отчеты можно гнуть для себя как хочешь).
Для домашней бухгалтерии самое то.
Money Manager Ex (http://www.moneymanagerex.org) — бесплатная, открытая, в т.ч. есть клиенты для мобильных платформ. Сначала пользовался им, но в какой-то момент меня перестала устраивать не достаточная глубина анализа (нет возможности создавать разветвленную аналитику).
AbilityCash (https://dervish.ru/) — бесплатная, закрытая. Разрабатывается с начала 2000-х, поэтому интерфейс немного не свеж. По части глубины анализа существенно превосходит предыдущую, но нужно разобраться и настроить под себя.
1С: Деньги (http://v8.1c.ru/money/) — не бесплатная (но дешевая), «полуоткрытая» (поставляется только в базовом варианте, версии проф не бывает, поэтому править конфу нельзя, но внешние отчеты — пожалуйста). Есть какой-то мобильный клиент. Настраиваемая как душе угодно аналитика, хорошие отчеты (если знаете СКД, отчеты можно гнуть для себя как хочешь).
Для домашней бухгалтерии самое то.
Ну не знаю, эта вся бухгалтерия слишком домашняя, тупо записывать траты. Я такими пользовался, рано или поздно начинается рассинхрон, где-то что-то не сходится. Вот в случае с двойной записей, все четко, к тому же хочется гибкости, чтобы одной транзакцией записать что-то типа: купил что-то со своей карточки, с комиссией за конвертацию, всю суму нужно разделить на 2-3 человека. Ничто кроме Gnucash из того что пробовал, не позволить такое записать, нужно будет вбивать несколько транзакций. Или одной транзакцией записать доход, где чистый доход идет на счет а налоги в траты. Чтобы capital gain по-нормальному считало, а не только FIFO в лучшем случае. Да и вообще приятно из коробки работать с вот этой структурой (assets, liabilities, income, expanses) пропагандируемой от Киосаки до более фундаментальных специалистов.
Раз уж подняли эту тему, много лет всё пытался завести учёт финансов семьи, но с рядом требований (думаю, многим семейным будет полезно):
1) непосредственный учёт, причём для двоих (муж-жена), доходы-расходы обоих
2) персональные счета, которые никак не светятся у второго участника, это может быть как что-то сберегательное, так и рабочее (выдали на закупку чего-либо), и с фиксацией, кто, когда, на что выдал и когда вернуть/отчитаться
2а) сбережения в наличке и их движение
3) поддержка обязательных платежей (ЖК, ипотека), с возможностью корректировки сумм и предупреждением что «скоро пора»
4) кредитки. Ставка, беспроцентный период каждой покупки, обязательные платежи к дате,…
Желательно онлайн, но можно и стационарно. Можно платную.
Крайне желательна поддержка банков или хотя бы их смс, автоматом вносить инфу в базу, для смс это получается нужен андроид клиент. Есть что-то такое?
1) непосредственный учёт, причём для двоих (муж-жена), доходы-расходы обоих
2) персональные счета, которые никак не светятся у второго участника, это может быть как что-то сберегательное, так и рабочее (выдали на закупку чего-либо), и с фиксацией, кто, когда, на что выдал и когда вернуть/отчитаться
2а) сбережения в наличке и их движение
3) поддержка обязательных платежей (ЖК, ипотека), с возможностью корректировки сумм и предупреждением что «скоро пора»
4) кредитки. Ставка, беспроцентный период каждой покупки, обязательные платежи к дате,…
Желательно онлайн, но можно и стационарно. Можно платную.
Крайне желательна поддержка банков или хотя бы их смс, автоматом вносить инфу в базу, для смс это получается нужен андроид клиент. Есть что-то такое?
Дзен мани? zenmoney.ru
1 — не вижу как сделать несколько логинов с общими счетами
2 — отсутствует
4 — отсутствует (счет, названный кредиткой, это не 4)
Для одиночки или фрилансера без ипотек и кредиток может и норм.
2 — отсутствует
4 — отсутствует (счет, названный кредиткой, это не 4)
Для одиночки или фрилансера без ипотек и кредиток может и норм.
1. support.zenmoney.ru/topics/9-semejnyij-byudzhet-dlya-vsej-semi
2. Там же, плюс «Долги», плюс «Проекты»
4. support.zenmoney.ru/topics/5-nastrojka-kreditnyih-kart-i-kreditov
btw, не имею к ним отношения, просто нравится продукт :)
2. Там же, плюс «Долги», плюс «Проекты»
4. support.zenmoney.ru/topics/5-nastrojka-kreditnyih-kart-i-kreditov
btw, не имею к ним отношения, просто нравится продукт :)
То есть ряд операций можно только через приложение, часть только через веб… Очень непроработан этот момент.
4 — для кредиток нет отслеживания платежей, например у сбера «до 50 дней» идут на каждый из платежей, и нужно отслеживать каждую транзакцию. Условно, при общем долге 100к — с процентами может быть только 10к, а через 2 дня их станет 60к, потому что через 2 дня у них «дата Х» и спишет процент за 50к.
Также, в поддержке банков есть всякий левак, но нет ни альфы, ни сбера.
В веб для кредиток нет такого ВАЖНОГО поля как процентная ставка.
И 100р в месяц это как-то дохрена (да, видел и другие тарифы)
4 — для кредиток нет отслеживания платежей, например у сбера «до 50 дней» идут на каждый из платежей, и нужно отслеживать каждую транзакцию. Условно, при общем долге 100к — с процентами может быть только 10к, а через 2 дня их станет 60к, потому что через 2 дня у них «дата Х» и спишет процент за 50к.
Также, в поддержке банков есть всякий левак, но нет ни альфы, ни сбера.
В веб для кредиток нет такого ВАЖНОГО поля как процентная ставка.
И 100р в месяц это как-то дохрена (да, видел и другие тарифы)
Я пользуюсь Sanuel Family. Платная. Есть клиент десктопный, есть мобильный.
Позволяет работать с несколькими пользователями, со своим набором счетов у каждого. Можно создать бюджет, можно расписать платежи по датам, которые будут отображаться на главной странице и позволят о них не забыть. Есть много отчётов, при помощи которых анализируются доходы, расходы, динамика их изменений (легко посмотреть на сколько выросли расходы на бензин за год-два, например).
Есть калькулятор стоимости кредитов, можно просчитать выгоду от досрочного погашения. Есть возможность создать финансовую цель (накопить на машину за год, например), и отслеживать прогресс в её достижении (с подсказками, сколько надо в этом месяце на неё отложить, чтобы достичь к запланированному сроку). И ещё масса другого функционала.
Пользуюсь ей уже много лет, весьма доволен. Счета в разных банках и разных валютах, кредиты, кредитные карты (правда эта часть не всегда корректно работает в плане расчётов ежемесячных минимальных платежей, но тут могут быть виноваты мои руки), всё под контролем.
Позволяет работать с несколькими пользователями, со своим набором счетов у каждого. Можно создать бюджет, можно расписать платежи по датам, которые будут отображаться на главной странице и позволят о них не забыть. Есть много отчётов, при помощи которых анализируются доходы, расходы, динамика их изменений (легко посмотреть на сколько выросли расходы на бензин за год-два, например).
Есть калькулятор стоимости кредитов, можно просчитать выгоду от досрочного погашения. Есть возможность создать финансовую цель (накопить на машину за год, например), и отслеживать прогресс в её достижении (с подсказками, сколько надо в этом месяце на неё отложить, чтобы достичь к запланированному сроку). И ещё масса другого функционала.
Пользуюсь ей уже много лет, весьма доволен. Счета в разных банках и разных валютах, кредиты, кредитные карты (правда эта часть не всегда корректно работает в плане расчётов ежемесячных минимальных платежей, но тут могут быть виноваты мои руки), всё под контролем.
А как учитывается уплата всяких налогов?
Меня всегда удивляло, когда так называемая "двойная запись" преподносится как преимущество. Везде говорят, что для минимизации ошибок нужно избегать дублирования информации, а здесь наоборот, даже поощряется. Как у кого-то после этого язык поворачивается назвать систему удобной или понятной — ума не приложу. Причем, я ещё понимаю, если бы записи для разных счетов вносились разными системами или транзакциями — тогда имеет смысл проверять друг друга (хотя тоже сложный вопрос, на чьей стороне правда). Но когда это делает одна и та же система, за одно действие — верх театра абсурда. А потом начинаются проблемы, что что-то там не сходится, наверное при записи ошиблись — в одном месте записали 10, а в другом --100. Сами создали проблему, сами героически решаем. А было бы это одно поле а не 2, такого бы не случилось. Поправьте меня, если я ошибаюсь.
Если бы поле было одно, то не ошибались бы никогда на 100 вместо 10?
Очевидно, расхождения бы были бы невозможны. Пока у меня складывается впечатление, что сначала пишут разные числа, а потом пишут другие разные числа, чтобы избавиться от расхождений и жалуются, что приходится писать вот эту вторую пару. А о том, что и первую можно не писать и избавить себя от дальнейшей работы почему никто не упоминает, словно все поголовно владеют каким то тайным знанием, зачем это нужно.
«Тайное знание» подробно описано в статье. Мне даже кажется очень подробно.
Плюс я планирую во второй части в основном его повторять (вернее расписать подробнее несколько относительно реальных примеров применения данного подхода). Плюс ниже я еще раз повторил.
Вот честно — я уверен что несмотря на то что я звучу как попугай, я считаю что действительно оно сложно понимается и стоит несколько раз повторить, а потом еще раз повторить, но у меня твердая уверенность что вы или не читали статью вообще, или пробежали по заголовкам и даже не попытались в нее вникнуть.
Я очень хочу слышать вопросы, но вопросы конкретные и осмысленные а не какие-то абстрактные высказывания ходящие по кругу. ПРОЧТИТЕ СТАТЬЮ.
Специально для вас я приведу абзац который я выкинул из окончательной версии статьи (был в середине):
Плюс я планирую во второй части в основном его повторять (вернее расписать подробнее несколько относительно реальных примеров применения данного подхода). Плюс ниже я еще раз повторил.
Вот честно — я уверен что несмотря на то что я звучу как попугай, я считаю что действительно оно сложно понимается и стоит несколько раз повторить, а потом еще раз повторить, но у меня твердая уверенность что вы или не читали статью вообще, или пробежали по заголовкам и даже не попытались в нее вникнуть.
Я очень хочу слышать вопросы, но вопросы конкретные и осмысленные а не какие-то абстрактные высказывания ходящие по кругу. ПРОЧТИТЕ СТАТЬЮ.
Специально для вас я приведу абзац который я выкинул из окончательной версии статьи (был в середине):
Советую взять листик в клеточку или ексель/гугл-таблицу, нарисовать таблицу «баланса», таблицу для проводок и расписать все проводки для всех примеров которые я приводил в тексте. Какой счет дебетуется, какой кредитуется, на какую сумму и т.п. Дополнительно было бы неплохо попробовать построить цепочку проводок которые могли привести из нулевого баланса (в начале проекта на всех счетах у нас ноль) нашего Слономаркета к балансу приведенному в начале статьи.
Я очень хочу слышать вопросы, но вопросы конкретные и осмысленные а не какие-то абстрактные высказывания ходящие по кругу.Да с «абстрактными высказываниями» тоже нормально.
У нас есть абстрактное высказывание:
Везде говорят, что для минимизации ошибок нужно избегать дублирования информации, а здесь наоборот, даже поощряется.Примем его на веру и напишем пару следствий:
1. Бекапы — это категорически неправильно. Нельзя их делать. А бэкапы бэкапов в другом — это вообще смерть.
2. Системы логирования — это вообще катастрофа. Их быть не должно. Ни в коем случае. Вся имеющаяся в них информация поступила туда из основной системы и, разумеется, там уже есть — а копии нам не нужни никогда и нигде.
Ну и другие подобные же выводы можно сделать. Нравится? Применимо на практике?
Правда заключается в том, что у людей, высказывающих подобные вещи просто каша в голове и они не то, что бухгалтерии не понимают — они в принципе и программирования-то не понимают и того как IT-системы (а бухгалтерия — это «родоначальная» IT-система, ради них и предки компьютеров, собственно, выпускались).
Все современные файловые системы и базы данных, блин, к «двойной записи» пришли — все данные пишутся в лог и на диск/базу. И «подведение баланса» у них тоже есть — это когда вы завершаете транзакцию. Почему бухгалтерия «подводит баланс» раз в месяц, а базы данных сотни раз в секунду — вопрос интересный, но базовых принципов не меняющий.
Вы правда не видите никаких изъянов в своих рассуждениях? Подумайте еще раз.
Подумали?
Бекап — это по определению неактуальные данные. Когда у вас противоречие в бекапе и оригинальных данных, то при накате бекапа у вас нет вопросов, как его разрешать. Используются значения из бекапа. Накат исходных изменений в бекап (т.е. создание нового бекапа) тоже не предполагает, что вы вдруг начнете сомневаться, обновлять или не обновлять?
Лог — вообще ни к селу ни к городу. Вы сами то поняли, что сказали?
Вся имеющаяся в них информация поступила туда из основной системы и, разумеется, там уже есть — а копии нам не нужни никогда и нигде.
Строчка в логе 01.01.2017 00:00 Access denied где именно хранится в основной системе? Для определености можете считать, что система — это компьютер, в который была совершена попытка логина.
Кеш — тоже вторичные данные. Если данные в кеше противоречат основным данным, вы инвалидируете кеш.
Логгирование в базах данных и в файловых системах не пишет одинаковые данные в лог и основное хранилище. В этом нет смысла. Там то данные как раз разные и естественно, никому в голову не приходит это называть двойной, тройной или какой еще записью. Кроме того, лог не работает для восстановления данных — если данные повреждены, то они утеряны. Он лишь позволяет сказать, были они записаны или нет и вернуться к одному из состояний в хранилище. А не состояний в хранилище или логе
А из названия термина "двойная запись", я, как всякий здравомыслящий человек, подразумеваю, что это не просто так и действительно пишутся одинаковые данные в 2 разных места. Точнее, предполагается, что они будут одинаковыми, а что на самом деле получится, непонятно. И таки между завершением транзакции и "подведением баланса" в бухгалтерии чудовищная разница. В первом случае снаружи никто не видит несогласованного состояния. А во втором несогласованность уже есть, непонятно, сколько народу ее увидело и тут она мучительно ищется и устраняется, причем еще почему-то автоматически это не делается.
Вообщем, я понимаю, что очень хотелось блеснуть остротой ума, только каша чуть на пол не выплеснулась. Впредь будьте аккуратнее.
А из названия термина «двойная запись», я, как всякий здравомыслящий человек, подразумеваю, что это не просто так и действительно пишутся одинаковые данные в 2 разных места.
Вы ошибаетесь. Здравомыслящий человек не подразумевает, а читает статью в которой несколько раз написано что данные РАЗНЫЕ.
Хм… А здесь вы с пеной у рта утверждаете, что одинаковые.
В данном случае дублирование информации используется для выявления ошибок. А требование к отсутствию дублирования это немного о другом. Дело в том, что считать ошибкой.
Допустим, возьмём классический реляционный подход. Состояние базы данных корректно, если оно внутренне непротиворечиво. То есть, ошибка, и внутреннее противоречие, здесь, по сути, синонимы. Но это так только с точки зрения математики. Если добавить к рассмотрению связь с реальным миром, то отсутствие противоречий не гарантирует нам корректность данных. Любое внутренне противоречие является ошибкой, но не любая ошибка выражается во внутреннем противоречии.
Рассмотрим простейший пример. Допустим, у нас есть одна таблица с контактными данными людей. И в ней указано, что телефон Васи — 555-77-77. Там же есть поле, в котором указаны адреса, и там записано, что Вася живет в доме номер 1 по улице Ленина, в 77-й квартире. Теперь представим, что у нас есть вторая таблица, в которой указаны номера телефонов, закрепленных за адресами. И там есть запись, указывающая что в той самой 77-й квартире, в доме номер 1 по улице Ленина, подключен совсем другой телефон — 777-55-55.
Очевидно, что в записях ошибка. Но это нам мало чего даёт, ведь мы не знаем какая из записей верна. Мы теперь не можем сказать, то ли Вася живет по другому адресу, то ли у него другой номер телефона. Но если бы у нас не было таблицы, в которой телефонные номера связаны с адресами, разве это гарантировало бы нам корректность телефонного номера, или адреса Васи? Конечно же нет. Тот кто записал эту информацию, мог указать что угодно. Никакого Васи вообще может не существовать. И квартиры такой в том доме может не быть.
Зато, наличие дубликата позволило нам выявить тот факт, что ошибка в принципе существует. В случае с описанной БД, нам это мало что даёт. Но когда все ходы записаны, а в случае с бухгалтерией это именно так, это даёт нам повод перепроверить операции, и выяснить, откуда взялась ошибка. Баланс работает как контрольная сумма. А история операций, как информация для восстановления.
Если в нашу БД из примера добавить данные о том, кто вносил каждое изменение, а так же хранить все предыдущие записи, то мы могли бы, выявив ошибку, найти того, кто её внёс, и каким было последнее непротиворечивое состояние. В таких системах дублирование помогает искать и устранять ошибки, от которых невозможно формально защититься, например ошибочный пользовательский ввод.
Допустим, возьмём классический реляционный подход. Состояние базы данных корректно, если оно внутренне непротиворечиво. То есть, ошибка, и внутреннее противоречие, здесь, по сути, синонимы. Но это так только с точки зрения математики. Если добавить к рассмотрению связь с реальным миром, то отсутствие противоречий не гарантирует нам корректность данных. Любое внутренне противоречие является ошибкой, но не любая ошибка выражается во внутреннем противоречии.
Рассмотрим простейший пример. Допустим, у нас есть одна таблица с контактными данными людей. И в ней указано, что телефон Васи — 555-77-77. Там же есть поле, в котором указаны адреса, и там записано, что Вася живет в доме номер 1 по улице Ленина, в 77-й квартире. Теперь представим, что у нас есть вторая таблица, в которой указаны номера телефонов, закрепленных за адресами. И там есть запись, указывающая что в той самой 77-й квартире, в доме номер 1 по улице Ленина, подключен совсем другой телефон — 777-55-55.
Очевидно, что в записях ошибка. Но это нам мало чего даёт, ведь мы не знаем какая из записей верна. Мы теперь не можем сказать, то ли Вася живет по другому адресу, то ли у него другой номер телефона. Но если бы у нас не было таблицы, в которой телефонные номера связаны с адресами, разве это гарантировало бы нам корректность телефонного номера, или адреса Васи? Конечно же нет. Тот кто записал эту информацию, мог указать что угодно. Никакого Васи вообще может не существовать. И квартиры такой в том доме может не быть.
Зато, наличие дубликата позволило нам выявить тот факт, что ошибка в принципе существует. В случае с описанной БД, нам это мало что даёт. Но когда все ходы записаны, а в случае с бухгалтерией это именно так, это даёт нам повод перепроверить операции, и выяснить, откуда взялась ошибка. Баланс работает как контрольная сумма. А история операций, как информация для восстановления.
Если в нашу БД из примера добавить данные о том, кто вносил каждое изменение, а так же хранить все предыдущие записи, то мы могли бы, выявив ошибку, найти того, кто её внёс, и каким было последнее непротиворечивое состояние. В таких системах дублирование помогает искать и устранять ошибки, от которых невозможно формально защититься, например ошибочный пользовательский ввод.
Спасибо за комментарий. Отчасти Вы правы. Но в контексте фин.учета это не совсем верно. Двойная запись не удваивает информацию. Двойная запись лишь требует ПОЛНОТУ информации. Она немного ограничивает нас в том какую информацию мы можем игнорировать, но по факту у нас здесь нет такого чтобы одна и та же информация повторялась дважды.
В программировании, и в особенности в проектировании структур данных есть два процесса: нормализация и денормализация БД.
На первый взгляд это взаимно противоположные действия, но немного не так.
Нормализация это процесс уменьшения избыточности, с целью уменьшения количества логических ошибок, упрощения и т.п.
Денормализация это процесс целенаправленного внесения избыточности для решения каких-то конкретных задач — увеличение надежности, улучшение производительности и т.п.
Ключевой момент который упускают те кто считают эти процессы противоположными — денормализацию можно проводить ТОЛЬКО ПОСЛЕ ТОГО КАК была проведена нормализация. Эти процессы не противоположны, а взаимно-дополняющие. Случайно денормализованная структура несет в себе хаос. Специально денормализованная — гармонию :)
В программировании, и в особенности в проектировании структур данных есть два процесса: нормализация и денормализация БД.
На первый взгляд это взаимно противоположные действия, но немного не так.
Нормализация это процесс уменьшения избыточности, с целью уменьшения количества логических ошибок, упрощения и т.п.
Денормализация это процесс целенаправленного внесения избыточности для решения каких-то конкретных задач — увеличение надежности, улучшение производительности и т.п.
Ключевой момент который упускают те кто считают эти процессы противоположными — денормализацию можно проводить ТОЛЬКО ПОСЛЕ ТОГО КАК была проведена нормализация. Эти процессы не противоположны, а взаимно-дополняющие. Случайно денормализованная структура несет в себе хаос. Специально денормализованная — гармонию :)
Очевидно, что в записях ошибка. Но это нам мало чего даёт, ведь мы не знаем какая из записей верна.
Вот-вот, о чем я и говорю. Так называемая "двойная запись" делает 2 записи, из которых непонятно, какая из них верна, если там ошибутся и в одно место запишут одно, а в другое — другое.
Возможно, это просто некорректная терминология, тянущаяся из дремучего бумажного легаси, и на самом деле операция делает одно изменение + 2 изменения в кешах (суммы на задействованных счетах). Но тогда я не понимаю, зачем ее (терминологию) применять, да еще и с каким-то придыханием рассказывать всем вокруг, какое же это благо — "двойная запись". Если это не более, чем обновление кеша — то что в этом особенного?
Кроме того, раз сумма счета всего лишь кеш при совершении операций, то при наличии расхождений исправление элементарно — нужно лишь инвалидировать кеш и посчитать его заново. Это автоматическая операция, но судя по количеству мемов про рвущих волосы бухгалтеров в последний день месяца из-за не сходящихся балансов, что-то тут не то.
А было бы это одно поле а не 2, такого бы не случилось.
Нет, такое бы все равно случилось. Просто оно не было бы замечено — и это куда хуже.
Ну заметите вы расхождение и на что его исправлять? Можете посчитать правильным число 100, а на самом деле правильное было 10. И в чем выгода, если опять результат неправильный будет?
С вашим подходом лучше от бухгалтерии держаться по-дальше. Числа-то не из головы придумываются вообще-то.
Какая разница, откуда числа приходят? Вот у вас есть факт: 2 разных числа, когда должны быть одинаковые. Что вы будите с этим делать? Если у вас нет никаких сторонних источников данных (типа товара на складе), как вы поймете, чему верить?
У вас не может быть РАЗНЫХ чисел.
Они по определению одинаковые.
Разные числа не разрешит записать программа или злой главбух.
Двойная запись это не про копию информации а про закон сохранения.
Если бы третий закон Ньютона назвали бы «закон двух сил», то вы бы тоже предполагали что они должны быть одинаковые, но кто-то по ошибке может сделать их разными а потом не понятно будет какой вариант правильный?
Они по определению одинаковые.
Разные числа не разрешит записать программа или злой главбух.
Двойная запись это не про копию информации а про закон сохранения.
Если бы третий закон Ньютона назвали бы «закон двух сил», то вы бы тоже предполагали что они должны быть одинаковые, но кто-то по ошибке может сделать их разными а потом не понятно будет какой вариант правильный?
А куда, собственно, они делись, сторонние источники-то?
Вообще вопрос не такой уж глупый как кажется.
На самом деле 99% возможных ошибок будут обнаружены прямо в момент их совершения. Вы просто не сможете записать неправильно. Получите сообщение об ошибке или еще как, но вам не нужно будет выискивать в чем именно ошибка поскольку как правильно заметил mayorovp на момент внесения данных в систему учета у вас перед глазами будет само событие которое вы описываете. Проданный товар, купленные запчасти, зарплатная ведомость или счет на оплату налогов. Не суть, но само событие предметной области будет на виду, а значит угадывать какой ответ правильный будет не нужно.
Однако даже если ошибка пройдет дальше, то ее будет проще локализовать и исправить поскольку у нас будет несколько фактических показателей которые не сходятся. Например у нас на складе излишки сигарет с ментолом и нехватка денег в кассе. Значит мы можем предположить что мы забыли оформить какую-то закупку сигарет. Начинаем поднимать закупки. Документы, поставщиков, все операции связанные с ментоловыми сигаретами и оказывается что мы ошиблись, с ментоловыми сигаретами все в порядке, а потерялась накладная на вишневые сигареты. Просто товаровед посчитала что в кассовой зоне пересортица и перебросила часть ментоловых сигарет на счет вишневых поскольку вишневых по факту продавалось больше чем было в базе. (Реальный случай).
В одиночной записи мы бы не смогли так просто отследить эту связь, ведь у нас не было бы проводки которая затрагивала бы и ментоловые и вишневые сигареты.
Случай с пересортицей был сложным. А вот случай когда реально потерялась накладная именно на ментоловые, и мы сразу подняли все движения по ментоловым и увидели что был заказ на такую сумму, что не пляшут и деньги и сигареты и стали звонить поставщику и т.п. — более частый. Без двойной записи пришлось бы перебирать все операции в поисках проблемной.
ПС: вообще поиск нестыковок в большом сложном балансе, когда все очевидные вещи уже исправлены автоматически за счет двойной записи, а ошибка не одна, а множество мелких — очень сложное занятие сродни искусству.
На самом деле 99% возможных ошибок будут обнаружены прямо в момент их совершения. Вы просто не сможете записать неправильно. Получите сообщение об ошибке или еще как, но вам не нужно будет выискивать в чем именно ошибка поскольку как правильно заметил mayorovp на момент внесения данных в систему учета у вас перед глазами будет само событие которое вы описываете. Проданный товар, купленные запчасти, зарплатная ведомость или счет на оплату налогов. Не суть, но само событие предметной области будет на виду, а значит угадывать какой ответ правильный будет не нужно.
Однако даже если ошибка пройдет дальше, то ее будет проще локализовать и исправить поскольку у нас будет несколько фактических показателей которые не сходятся. Например у нас на складе излишки сигарет с ментолом и нехватка денег в кассе. Значит мы можем предположить что мы забыли оформить какую-то закупку сигарет. Начинаем поднимать закупки. Документы, поставщиков, все операции связанные с ментоловыми сигаретами и оказывается что мы ошиблись, с ментоловыми сигаретами все в порядке, а потерялась накладная на вишневые сигареты. Просто товаровед посчитала что в кассовой зоне пересортица и перебросила часть ментоловых сигарет на счет вишневых поскольку вишневых по факту продавалось больше чем было в базе. (Реальный случай).
В одиночной записи мы бы не смогли так просто отследить эту связь, ведь у нас не было бы проводки которая затрагивала бы и ментоловые и вишневые сигареты.
Случай с пересортицей был сложным. А вот случай когда реально потерялась накладная именно на ментоловые, и мы сразу подняли все движения по ментоловым и увидели что был заказ на такую сумму, что не пляшут и деньги и сигареты и стали звонить поставщику и т.п. — более частый. Без двойной записи пришлось бы перебирать все операции в поисках проблемной.
ПС: вообще поиск нестыковок в большом сложном балансе, когда все очевидные вещи уже исправлены автоматически за счет двойной записи, а ошибка не одна, а множество мелких — очень сложное занятие сродни искусству.
Ошибаетесь.
Я понимаю что статья длинная и легко потерять нить или прочитать через строчку, так что остановлюсь на том моменте еще раз.
Минимальная операция в двойной записи это проводка.
У проводке грубо говоря есть три поля — два поля указывают номера счетов где отражаются изменения, третье поле это сумма изменения.
Эти счета РАЗНЫЕ, а сумма одна. Поэтому сделать так чтобы в одном месте 10 а в другом 100 — не получится. В бумажном виде такое изредка случалось, но с появлением в бухгалтерии компьютеров — полностью исчезло.
Давайте рассмотрим случай который я наблюдал пару дней назад.
Две девушки открыли стартап.
Они делают бижутерию ручной работы.
Одна из них закупала материалы. Делала несколько закупок в разных местах. Плюс у нее были некоторые материалы закупленные еще до того как они стали работать вместе, и они договорились что она вносит эти материалы в общак, и берет за них оговоренную стоимость из кассы. Девочки пользуются простым, тупым учетом — у них есть несколько табличек примерно аналогичных счетам баланса (материалы, деньги в кассе, товар на складе и т.п.) изменения в которых они ведут одиночными записями. Когда девочка записывала эти операции в кассу она по ошибке указала стоимость принесенного ей товара не как расход из кассы (выплату ей стоимости товара) а как доход. А поскольку она делала другие закупки, покупала из своих денег а потом забирала из кассы разницу, то ошибка не была замечена сразу, она взяла денег за вычетом двойной стоимости принесенных ею материалов.
Ошибка всплыла только потому что ее партнерша перечитывала все записи внимательно и дотошно и увидела что тут явно ошибка.
Если бы у них использовалась двойная запись, то ей нужно было бы записать не только факт ухода или прихода денег, но и вторую запись за что эти деньги пришли или на что были потрачены. В данном случае должны были бы увеличится суммы в таблице «материалы на складе». В принципе в автоматическом варианте тут ошибки не могло бы быть просто потому что раз материалы актив, и он увеличился а второй записью идет касса которая тоже актив, то она может только уменьшится. Но если даже опустить эту проверку и записать вручную в таблицу неверную запись — мы нарушим баланс. Активные счета сразу перестанут совпадать с пассивными, ведь у нас одной операцией увеличилось сразу два активных счета.
Ну и еще раз — двойная запись не записывает одну операцию дважды. Она просто записывает связанные вещи как единую запись. Примерный аналог, чтобы понять в чем она двойная — банковские счета (на самом деле там все так же — активы, пассивы, дебет и кредит, но это уже в следующих частях). Если мы переводим деньги с одного счета на другой счет в том же банке, то при одиночной записи мы сделаем две записи — одной записью мы уменьшим счет источника, второй записью увеличим счет получателя. При двойной записи мы просто запишем — взять столько-то денег с такого-то счета и положить на такой-то. Одной, ДВОЙНОЙ записью. Согласитесь что так ошибиться сложнее.
Я понимаю что статья длинная и легко потерять нить или прочитать через строчку, так что остановлюсь на том моменте еще раз.
Минимальная операция в двойной записи это проводка.
У проводке грубо говоря есть три поля — два поля указывают номера счетов где отражаются изменения, третье поле это сумма изменения.
Эти счета РАЗНЫЕ, а сумма одна. Поэтому сделать так чтобы в одном месте 10 а в другом 100 — не получится. В бумажном виде такое изредка случалось, но с появлением в бухгалтерии компьютеров — полностью исчезло.
Давайте рассмотрим случай который я наблюдал пару дней назад.
Две девушки открыли стартап.
Они делают бижутерию ручной работы.
Одна из них закупала материалы. Делала несколько закупок в разных местах. Плюс у нее были некоторые материалы закупленные еще до того как они стали работать вместе, и они договорились что она вносит эти материалы в общак, и берет за них оговоренную стоимость из кассы. Девочки пользуются простым, тупым учетом — у них есть несколько табличек примерно аналогичных счетам баланса (материалы, деньги в кассе, товар на складе и т.п.) изменения в которых они ведут одиночными записями. Когда девочка записывала эти операции в кассу она по ошибке указала стоимость принесенного ей товара не как расход из кассы (выплату ей стоимости товара) а как доход. А поскольку она делала другие закупки, покупала из своих денег а потом забирала из кассы разницу, то ошибка не была замечена сразу, она взяла денег за вычетом двойной стоимости принесенных ею материалов.
Ошибка всплыла только потому что ее партнерша перечитывала все записи внимательно и дотошно и увидела что тут явно ошибка.
Если бы у них использовалась двойная запись, то ей нужно было бы записать не только факт ухода или прихода денег, но и вторую запись за что эти деньги пришли или на что были потрачены. В данном случае должны были бы увеличится суммы в таблице «материалы на складе». В принципе в автоматическом варианте тут ошибки не могло бы быть просто потому что раз материалы актив, и он увеличился а второй записью идет касса которая тоже актив, то она может только уменьшится. Но если даже опустить эту проверку и записать вручную в таблицу неверную запись — мы нарушим баланс. Активные счета сразу перестанут совпадать с пассивными, ведь у нас одной операцией увеличилось сразу два активных счета.
Ну и еще раз — двойная запись не записывает одну операцию дважды. Она просто записывает связанные вещи как единую запись. Примерный аналог, чтобы понять в чем она двойная — банковские счета (на самом деле там все так же — активы, пассивы, дебет и кредит, но это уже в следующих частях). Если мы переводим деньги с одного счета на другой счет в том же банке, то при одиночной записи мы сделаем две записи — одной записью мы уменьшим счет источника, второй записью увеличим счет получателя. При двойной записи мы просто запишем — взять столько-то денег с такого-то счета и положить на такой-то. Одной, ДВОЙНОЙ записью. Согласитесь что так ошибиться сложнее.
Пока я вижу, что вы описываете ситуацию, что реальные суммы есть только в одном объекте — в проводке. То, что на счету — это кеширование, счета вообще бы могли ничего не хранить и считать свой баланс каждый раз при доступе к нему, последовательно применяя все проводки. Я не понимаю, почему такой кеш надо как-то по-особому называть, да еще и таким сбивающем с толку названием.
Если мы переводим деньги с одного счета на другой счет в том же банке, то при одиночной записи мы сделаем две записи — одной записью мы уменьшим счет источника, второй записью увеличим счет получателя. При двойной записи мы просто запишем — взять столько-то денег с такого-то счета и положить на такой-то. Одной, ДВОЙНОЙ записью. Согласитесь что так ошибиться сложнее.
Не знаю, кто придумал всю эту терминологию с одиночными/двойными записями, но она ужасна. А если это легаси, тянущееся с бумажных времен, то непонятно, почему его давно не переименовали во что-то более интуитивно понятное.
Пока я вижу, что вы описываете ситуацию, что реальные суммы есть только в одном объекте — в проводке. То, что на счету — это кеширование, счета вообще бы могли ничего не хранить и считать свой баланс каждый раз при доступе к нему, последовательно применяя все проводки. Я не понимаю, почему такой кеш надо как-то по-особому называть, да еще и таким сбивающем с толку названием.
Я вам больше скажу. У вас нет никакого кошелька, и нет никаких банковских счетов, нет кредитных и дебетовых карточек, нет счетов в вебмани. Ничего этого нет. Это просто кеш. А на самом деле существуют только транзакции которые касаются данных сущностей. Непонятно зачем столько всего придумали когда реальные деньги есть только в операциях. Вот вам подарили первый кошелек в десять лет? Вот с тех пор все приходы и расходы посчитайте, и будете знать сколько денег в кошельке…
Да, это будет единственно гарантированно ТОЧНЫЙ способ узнать, сколько там денег. Кстати, в криптовалютах вроде такой способ сейчас и применяется — в самом деле, не можете же вы доверять тому, что сказал Вася о содержимом своего кошелька.
Такой, да не такой. Там как раз обычно промежуточные значения материализуются в промежуточных транзакциях, так что если у вас блокчейн доверенный (раньше проверили), то все дерево просматривать необязательно — хватит последнего места где встречается нужный выход. Ну и другие костыли, чтобы не слишком терять производительность. Но такой подход там не от хорошей жизни. Как минимум там заранее неизвестен список всех «счетов». Ну и другие особенности.
Я же не настаиванию на неиспользовании кеша. Разумеется, он нужен. Однако нужно понимать, что это всего лишь кеш, его можно в любой момент забыть и посчитать заново. Да, это может быть накладно, но ведь нас в первую очередь интересует корректность, а во вторую производительность.
Материализация транзакции — это кеш. Использовать его или нет — дело желания. Конечно, в повседневности его используют, но это не обязательно.
Как минимум там заранее неизвестен список всех «счетов»
Не понял, как это влияет. У нас первичны операции, т.е. проводки. Вы и в "обычном" случае их список заранее не знаете.
На самом деле, на уровне БД создаётся одна запись в таблице транзакций: с полями: дата, сумма, счётДт, счётКт, описание. Для того чтобы получить баланс того или иного счёта нам надо просто отобрать все транзакции, где этот счёт фигурирует в Кт или Дт. Из проверок только проверить, что оба счёта указаны, ну и ряд бизнес-проверок (чтобы проводка имела смысл, чтобы не выпрыгивала из временного периода итд)
Такая подход позволяет вам в любой момент времени изменить как сумму, дату транзакции, так и сами счета между которыми осуществялется эта транзакция, без боязни, что вы нарушите целостность итогового баланса (т.е. что сальдо активных счетов всегда будет равно сальдо Пассивов)
Такая подход позволяет вам в любой момент времени изменить как сумму, дату транзакции, так и сами счета между которыми осуществялется эта транзакция, без боязни, что вы нарушите целостность итогового баланса (т.е. что сальдо активных счетов всегда будет равно сальдо Пассивов)
Есть такой подход.
Но у него есть несколько недостатков.
Главный минус вашего подхода это «можно изменить не опасаясь нарушить». Это ошибка.
Изменяя что-то задним числом вы рискуете нарушить целостность проводок которые были после того, ведь ваше изменение могло повлиять на условия при которых последующие проводки не имели бы смысла. Так что нет, это не преимущество а недостаток. Лучше отменять все что было после измененной записи и осуществлять изменения заново.
Это называется «отмена проведения документа» и «перепроведение документа» в терминах 1С, да и в других системах вроде тоже.
Так что «изменять задним числом» я вам не советую даже рассматривать.
А вот с тем чтобы складывать все проводки это да, идея верная.
Но у нее есть один жЫрный минус который делает ее в чистом виде не рабочей:
Такие операции слишком накладны. Вместо одного SELECT который вернет нам множество интересующих нас счетов отбирая нужные данные по условию используя индекс мы будем выполнять множество групповых операций проходя по всей базе.
В больших объемах это не просто накладно а неподъемно по производительности.
Вместе с тем если мы отказываемся от «изменить задним числом», а мы от него и так отказались, то можно к проводке добавить еще два поля — значение дебетуемого счета после проводки и значение кредитуемого счета после проводки.
В таком виде мы можем сразу получать состояние счетов на разную дату (сортировка по дате и условие что меньше или равно искомой дате), избавляемся от дополнительной таблицы, легко считаем обороты по счету, изменения за период и т.п.
Но у него есть несколько недостатков.
Главный минус вашего подхода это «можно изменить не опасаясь нарушить». Это ошибка.
Изменяя что-то задним числом вы рискуете нарушить целостность проводок которые были после того, ведь ваше изменение могло повлиять на условия при которых последующие проводки не имели бы смысла. Так что нет, это не преимущество а недостаток. Лучше отменять все что было после измененной записи и осуществлять изменения заново.
Это называется «отмена проведения документа» и «перепроведение документа» в терминах 1С, да и в других системах вроде тоже.
Так что «изменять задним числом» я вам не советую даже рассматривать.
А вот с тем чтобы складывать все проводки это да, идея верная.
Но у нее есть один жЫрный минус который делает ее в чистом виде не рабочей:
Такие операции слишком накладны. Вместо одного SELECT который вернет нам множество интересующих нас счетов отбирая нужные данные по условию используя индекс мы будем выполнять множество групповых операций проходя по всей базе.
В больших объемах это не просто накладно а неподъемно по производительности.
Вместе с тем если мы отказываемся от «изменить задним числом», а мы от него и так отказались, то можно к проводке добавить еще два поля — значение дебетуемого счета после проводки и значение кредитуемого счета после проводки.
В таком виде мы можем сразу получать состояние счетов на разную дату (сортировка по дате и условие что меньше или равно искомой дате), избавляемся от дополнительной таблицы, легко считаем обороты по счету, изменения за период и т.п.
Изменяя что-то задним числом вы рискуете нарушить целостность проводок которые были после того, ведь ваше изменение могло повлиять на условия при которых последующие проводки не имели бы смысла
Я говорил про нарушение целостности итогового баланса. Вопрос же права пользователя вносить сумятицу в его собственную бухгалтерию это скорее вопрос дизайна системы.
Такие операции слишком накладны
Не буду спорить. Всё зависит от масштаба и процесса. Мы используем двойной учёт для управленческих операций и у нас вопрос внесения изменений в большей степени актуален, чем вопрос производительности.
Я не против внесения изменений задним числом. Иногда конечно лучше сторно, но если это не регламентированный учет и легитимность правок решена на другом уровне абстракции, то пусть себе правят. Я о другом. Не стоит давать пользователю возможность отстрелить себе ногу. Максимум тестов которые могут быть, должны быть. Соответственно я против того чтобы были правки «по тихому», не трогая последующие транзакции.
В очень простой логике это может сработать, но по мере роста объем логики для проверки таких вот изменений чтобы они не вызвали лавину проблем вам придется писать код который будет проходить все транзакции (не только проводки но и документы их вызвавшие) которые были после исправленной, и проверять что они будут нормально проходить в условиях изменений. А в таком случае смысл «тихой» правки исчезает. Вы все равно проходите всех «потомков».
В очень простой логике это может сработать, но по мере роста объем логики для проверки таких вот изменений чтобы они не вызвали лавину проблем вам придется писать код который будет проходить все транзакции (не только проводки но и документы их вызвавшие) которые были после исправленной, и проверять что они будут нормально проходить в условиях изменений. А в таком случае смысл «тихой» правки исчезает. Вы все равно проходите всех «потомков».
Смысл "тихой" правки — в возможности длительных исправлений. Скажем, отдел неделю расследует что натворили предшественники и исправляет ошибки — так что, все это держать в памяти?
Случается-то всякое, вряд ли разумно запрещать исправлять найденную ошибку только из-за того что это исправление выявляет еще три. Скажем, в базе записано что продали 600 слонов — а тут выяснилось, что этих слонов у нас на складе никогда не было. Что лучше: запретить вносить в базу поправку об отсутствии слонов на складе пока не выяснится чего же на самом деле продали — или внести информацию об отсутствии слонов, сохранить — и подсветить красным продажу того, чего не существовало?
Да, со скрипом соглашусь, что такой подход имеет право на жизнь.
Со скрипом потому что я бы предпочел при проведении правки об отсутствии слонов откатил бы все документы которые не проводятся в новых условиях (накладные на продажу слонов), а оперативную задачу «работаем хоть как-то» закрывал бы внеочередной инвентаризацией и продажей по состоянию из инвентаризации. Но Ваш подход да, имеет свои плюсы в этом случае.
Минус тут вполне существенный — вы не видите реальной картины. Что реально у вас не пляшет, ведь вслед за отменой проведения продаж у нас начнут не плясать деньги и т.п., и по результатам вполне может оказаться что на самом деле те слоны все-таки были, но получены были на день раньше или еще каким образом.
Разбор работы «папиредныков» лучше начинать с инвентаризации. И уже когда есть инвентаризация, то тебе не важно что было раньше. От инвентаризации до инвентаризации склад зависит только от правильности текущего учета (не только склад конечно). А значит проводить частичное исправление которое тянет за собой кучу красного нет смысла.
Но в целом — ок, согласен, возможен случай когда мы живем с красным.
Но все равно предвычисления счетов лучше делать. Отвечу ниже об этом.
Со скрипом потому что я бы предпочел при проведении правки об отсутствии слонов откатил бы все документы которые не проводятся в новых условиях (накладные на продажу слонов), а оперативную задачу «работаем хоть как-то» закрывал бы внеочередной инвентаризацией и продажей по состоянию из инвентаризации. Но Ваш подход да, имеет свои плюсы в этом случае.
Минус тут вполне существенный — вы не видите реальной картины. Что реально у вас не пляшет, ведь вслед за отменой проведения продаж у нас начнут не плясать деньги и т.п., и по результатам вполне может оказаться что на самом деле те слоны все-таки были, но получены были на день раньше или еще каким образом.
Разбор работы «папиредныков» лучше начинать с инвентаризации. И уже когда есть инвентаризация, то тебе не важно что было раньше. От инвентаризации до инвентаризации склад зависит только от правильности текущего учета (не только склад конечно). А значит проводить частичное исправление которое тянет за собой кучу красного нет смысла.
Но в целом — ок, согласен, возможен случай когда мы живем с красным.
Но все равно предвычисления счетов лучше делать. Отвечу ниже об этом.
Дополнительные поля с балансом — это лишние трудности по их поддержке в актуальном состоянии. Лучше уж вот так:
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-2 апдейтами в тех редких случаях когда надо править логику.
Я соглашусь вынести состояния счетов из проводок в отдельную таблицу, со ссылкой на проводку которая к этому состоянию привела, но городить вот такое — я против, да.
Я не уверен насколько адекватны по скорости будут индексы у вьювов с агрегирующими функциями. И не хочу этого узнавать.
Все это делается 1-2 апдейтами в тех редких случаях когда надо править логику.
Я соглашусь вынести состояния счетов из проводок в отдельную таблицу, со ссылкой на проводку которая к этому состоянию привела, но городить вот такое — я против, да.
Если мы делаем изменение старых проводок, то у нас есть сумма на которую было изменение.Да, сумма есть, и ее нужно записать во все 10 000 последующих проводок.
Если нужно поправить 10 проводок, то 10 раз перезапишется «пол базы»?
А в чем проблема? Ну перезапишем десять раз «полбазы» и что? Тут предлагают при каждом просмотре считать всю сумму всех проводок, а вы боитесь разово, при редком изменении сделать один запрос? ОДИН, не пачку. Ну десять изменений, десять запросов. В любом случае нагрузка ниже на порядки.
1) чтение не запись, тем более для SSD
2) mayorovp предлагает индексированное представление. Об этом говорит with schemabinding и unique clustered index.
Индексированное представление автоматически перевычисляется при изменении исходных данных.
3) не нравится Индексированное view, можно использовать тригеры БД или просто считать итоги в логике и писать в таблицу итогов. (но я не уверен что не потерял какую то вашу суть, почему вы именно так сделали)
2) mayorovp предлагает индексированное представление. Об этом говорит with schemabinding и unique clustered index.
Индексированное представление автоматически перевычисляется при изменении исходных данных.
3) не нравится Индексированное view, можно использовать тригеры БД или просто считать итоги в логике и писать в таблицу итогов. (но я не уверен что не потерял какую то вашу суть, почему вы именно так сделали)
1) чтение совсем не запись, поскольку в реальных кейсах выполняется не в разы, а на порядки чаще. Счет идет реально на порядки, так что некоторое удорожание за счет более дорогой записи — ничтожно. В особенности если учесть тот факт что запись затрагивающая значительное колво строк — исчезающе редкое явление связанное с ошибками учета. Штатная запись затрагивает лишь текущие единицы строк
2) Я понимаю что у mayorovp речь идет об индексированных данных. Однако я не знаю как конкретно такие сложные индексы поведут себя в различных СУБД. И знать не хочу. Зато я знаю что простое обновление руками будет дешевым и простым. Подумайте еще раз. В идеальном случае, если СУБД идеально решит вторую фундаментальную проблему программирования (инвалидация кеша) — мы получим ровно тоже количество операций записи что и в моем варианте. Вам надо будет обновить все индексы связанные с этим конкретным счетом, и только их. Что я делаю вручную, напрямую указав это в запросе. Вместе с тем далеко не факт что СУБД сможет понять этот факт и не начнет пересчитывать индекс при каждом изменении а не только при тех которые нужны.
3) Да, я храню предвычисленные значения на каждый момент времени в отдельной таблице итогов и обновляю ее в логике. Да, я не люблю нагружать логикой базу, и по возможности избегаю вьювов и тригеров там где этого можно избежать без существенных потерь в производительности или архитектурных сложностей. Но дело не в этом. Нить данной дискуссии началась на том что кто-то здесь предложил отказаться от таблицы счетов вообще и хранить всю информацию только в проводках, а значения счетов вычислять каждый раз суммируя. Я предложил вариант который тоже будет с одной таблицей, но без чрезмерных вычислений — добавление результирующих значений прямо в таблицу проводки. mayorovp на это предложил вместо денормализации сделать вьюв…
2) Я понимаю что у mayorovp речь идет об индексированных данных. Однако я не знаю как конкретно такие сложные индексы поведут себя в различных СУБД. И знать не хочу. Зато я знаю что простое обновление руками будет дешевым и простым. Подумайте еще раз. В идеальном случае, если СУБД идеально решит вторую фундаментальную проблему программирования (инвалидация кеша) — мы получим ровно тоже количество операций записи что и в моем варианте. Вам надо будет обновить все индексы связанные с этим конкретным счетом, и только их. Что я делаю вручную, напрямую указав это в запросе. Вместе с тем далеко не факт что СУБД сможет понять этот факт и не начнет пересчитывать индекс при каждом изменении а не только при тех которые нужны.
3) Да, я храню предвычисленные значения на каждый момент времени в отдельной таблице итогов и обновляю ее в логике. Да, я не люблю нагружать логикой базу, и по возможности избегаю вьювов и тригеров там где этого можно избежать без существенных потерь в производительности или архитектурных сложностей. Но дело не в этом. Нить данной дискуссии началась на том что кто-то здесь предложил отказаться от таблицы счетов вообще и хранить всю информацию только в проводках, а значения счетов вычислять каждый раз суммируя. Я предложил вариант который тоже будет с одной таблицей, но без чрезмерных вычислений — добавление результирующих значений прямо в таблицу проводки. mayorovp на это предложил вместо денормализации сделать вьюв…
вторую фундаментальную проблему программирования (инвалидация кеша)Подскажите, какие первая и третья фундаментальные проблемы программирования? А четвертая и пятая есть? Я не троллю.
Вместе с тем далеко не факт что СУБД сможет понять этот факт и не начнет пересчитывать индекс при каждом изменении а не только при тех которые нужны.
Тем не менее, это факт. MS SQL (а я писал используя его синтаксис) просто не позволит вам создать такой индекс который не cможет потом эффективно поддерживать при обновлениях.
А Мускул? А SQLite3? А…
Ну это же не серьезно. Ну вот честно.
Есть готовое решение в одну строку, которое использует минимальный синтаксис и заведется даже на СУБД на файлах, при этом имеет идеальную эффективность.
Вы предлагаете заменить это решение на другое. Новое решение работает только на некоторых СУБД. Оно занимает экран кода. При этом ПРЕДПОЛОЖИТЕЛЬНО может достигать почти такую же эффективность как у первого решения. Плюсы? Плюс только один — «потому что могу!».
И да ваш вариант даже чисто теоретически не сможет быть равным по скорости с моим. Как внутри работает индекс? Ведь любая СУБД работает с файлами, в которых существуют таблицы, а индексы это просто особая форма таблицы (да, деревья тоже выглядят как таблица). Фактически добавляя индекс мы создаем некую служебную таблицу которая обновляется по определенным правилам. Чтобы понять что его нужно обновлять СУБД вешает некий триггер (не совсем, но суть похожая) на те таблицы что участвуют в индексе. При изменении тех таблиц запускается наш триггер который проверяет должен ли текущий запрос повлиять на данные которые отражены в индексе, потом определяет какие именно поля он должен затронуть, и изменяет индекс (если нужно). Другого варианта особо то и нет. В вашем случае если даже допустить что СУБД сможет построить идеальное условие и идеально определить какие записи в этой служебной таблице индекса (полный аналог моей кстати), то все равно она будет выполнять этот анализ при КАЖДОМ изменяющем запросе. Это абсолютно принебрежимый оверхед, но он есть, да.
Ну это же не серьезно. Ну вот честно.
Есть готовое решение в одну строку, которое использует минимальный синтаксис и заведется даже на СУБД на файлах, при этом имеет идеальную эффективность.
Вы предлагаете заменить это решение на другое. Новое решение работает только на некоторых СУБД. Оно занимает экран кода. При этом ПРЕДПОЛОЖИТЕЛЬНО может достигать почти такую же эффективность как у первого решения. Плюсы? Плюс только один — «потому что могу!».
И да ваш вариант даже чисто теоретически не сможет быть равным по скорости с моим. Как внутри работает индекс? Ведь любая СУБД работает с файлами, в которых существуют таблицы, а индексы это просто особая форма таблицы (да, деревья тоже выглядят как таблица). Фактически добавляя индекс мы создаем некую служебную таблицу которая обновляется по определенным правилам. Чтобы понять что его нужно обновлять СУБД вешает некий триггер (не совсем, но суть похожая) на те таблицы что участвуют в индексе. При изменении тех таблиц запускается наш триггер который проверяет должен ли текущий запрос повлиять на данные которые отражены в индексе, потом определяет какие именно поля он должен затронуть, и изменяет индекс (если нужно). Другого варианта особо то и нет. В вашем случае если даже допустить что СУБД сможет построить идеальное условие и идеально определить какие записи в этой служебной таблице индекса (полный аналог моей кстати), то все равно она будет выполнять этот анализ при КАЖДОМ изменяющем запросе. Это абсолютно принебрежимый оверхед, но он есть, да.
Интересно, вы на каком языке пишите, со сборкой мусора? У вас между запросами от UI приложение умирает, или есть какое то «статическое» поле, которое содержит данные между запросами?
У вас случайно нет тяжелых структур в памяти которые приходится создавать/обновлять при каждом запросе?
Как вы поддерживаете иерархию итогов по счетам/субсчетам и по каталогу товаров с группами?
У вас случайно нет тяжелых структур в памяти которые приходится создавать/обновлять при каждом запросе?
Как вы поддерживаете иерархию итогов по счетам/субсчетам и по каталогу товаров с группами?
А как все эти вопросы влияют на обсуждаемую тему и тем более на основную тему данной статьи?)
Я ведь не затрагиваю вопрос того что вьюв mayorovp не особо красив, равно как и не спрашиваю цвет ваших глаз :)
Единичный апдейт вызываемый раз в день а то и раз в пару месяцев будет много проще и быстрее чем вьюв на полстраницы вызываемый постоянно по тысяче раз за один отчет. Всё.
Я ведь не затрагиваю вопрос того что вьюв mayorovp не особо красив, равно как и не спрашиваю цвет ваших глаз :)
Единичный апдейт вызываемый раз в день а то и раз в пару месяцев будет много проще и быстрее чем вьюв на полстраницы вызываемый постоянно по тысяче раз за один отчет. Всё.
А теперь сравните затраты на чтение данных из базы.
Сравнить с чем? У меня они на несколько порядков меньше чем у вас.
Не верю.
Вспоминая основную задачу, ради которой все и затевалось — понимание общей картины финансов, предлагаю подумать как будет выполняться запрос "получить текущий баланс по каждому счету".
В моем случае это будет merge join трех индексов. Если счета не все, а только часть — то будет два уточняющих nested loops join с выбором конкретного элемента из индексов.
А у вас что получится?
Вы хотите прям живую структуру и живые запросы?
Причем универсальную структуру, под основной типовой набор?
Ну ок, давайте набросаем. Единственное что — предвидя что мы скатимся на бенчмарк, причем 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) Проверка того, что все проводки были «законными» на любой момент времени (на случай изменения задним числом — того самого «тихого» варианта, ну или возможных технических сбоев)
Вроде ничего не забыл? Подходит такое ТЗ? Есть пожелания, дополнения?
Причем универсальную структуру, под основной типовой набор?
Ну ок, давайте набросаем. Единственное что — предвидя что мы скатимся на бенчмарк, причем 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) Проверка того, что все проводки были «законными» на любой момент времени (на случай изменения задним числом — того самого «тихого» варианта, ну или возможных технических сбоев)
Вроде ничего не забыл? Подходит такое ТЗ? Есть пожелания, дополнения?
UPD: Вспомнилось, добавить еще:
2.6) Если задача не решается одним лишь запросом, то написать код обвязки на псевдокоде или одном из языков программирования
3.2.9) Список всех проводок по конкретному счету за период
3.2.10) Список всех значений конкретного счета за период (в виде таймштамп- значение)
2.6) Если задача не решается одним лишь запросом, то написать код обвязки на псевдокоде или одном из языков программирования
3.2.9) Список всех проводок по конкретному счету за период
3.2.10) Список всех значений конкретного счета за период (в виде таймштамп- значение)
Так что «изменять задним числом» я вам не советую даже рассматривать.На самом деле тут есть важный момент, который вы подразумеваете, который нигде не упомянули явно, но который принципиально важен.
Дело в том, что есть бухгалтерия и «бухгалтерия за 10000 рублёв раз в неделю». Последнее — это особый жанр, собственно к бухгалтерии имеющий мало отношения. Это, грубо говоря, когда вы получаете раз в неделю кучку проводок (но не все!) и задание — «изобразить что-нибудь для налоговой».
Вот тут и изменение сумм задним числом и перенос дат транзакций (чтобы счета «посредине» не становились отрицательными) и многое другое — невероятно востребовано и полезно.
Но к тому, что обычные люди, не «мелкие предприниматели на карман» понимают под словом «бухгалтерия» это имеет мало отношения.
А потом через полгода всплывает накладная на полмиллиона на которую ты налоговую накладную в базу не занес. Ага. Видели.
Приходящий бухгалтер хорош когда на предприятии есть кто-то, кто и без бухгалтера следит за фин.дисциплиной. Или внятная управленческая система учета которая делает это автоматически. А иначе — хаос.
Но я говорю о другом.
Исправления задним числом нужны, без них никуда. Сторно это мучение.
Но плохо как раз делать исправления не проверив что оно не покалечило другие операции.
Приходящий бухгалтер хорош когда на предприятии есть кто-то, кто и без бухгалтера следит за фин.дисциплиной. Или внятная управленческая система учета которая делает это автоматически. А иначе — хаос.
Но я говорю о другом.
Исправления задним числом нужны, без них никуда. Сторно это мучение.
Но плохо как раз делать исправления не проверив что оно не покалечило другие операции.
Везде говорят, что для минимизации ошибок нужно избегать дублирования информации,
В этом месте всем передает привет CRC, ECC, и прочие способы избыточно кодировать информацию, что бы было легко обнаруживать ошибки, корректировать и так далее.
Избыточное кодирование — это все-таки не просто дублирование. Помимо собственно дополнительных данных важное значение имеет алгоритм, примешивающий их к исходным данным. Вот, недавно на хабре была прекрасная статья о кодах Рида-Соломона. Представте, на примере из этой статьи, что для вектора из 3-й чисел мы хотим найти 3 избыточных значение. Казалось бы, чего проще — просто продублировать исходные? Но что будет, если в получившемся векторе [A, B, C, A, B, C] мы потеряем оба элемента A? Мы ведь можем потерять как минимум любые 2 элемента. Их будет не восстановить. А алгоритм Рида-Соломона такой ситуации не допускает.
Так что сравнивать дублирование и избыточное кодирование некорректно. Первое плохо. Второе хорошо.
Вы забыли народную мудрость — если несешь чушь, то главное не расплескать.
Извините за грубость, но это уже просто троллинг какой-то. Я наверное уже двадцатый раз повторяю — В ДВОЙНОЙ ЗАПИСИ НЕТ НИКАКОЙ ИЗБЫТОЧНОЙ ИНФОРМАЦИИ.
Двойная запись требует писать всю информацию. Один раз, но всю.
В супермаркете нам всем дают фискальный чек.
В фискальном чеке есть информация о продавце (том кто получил деньги) и о сумме которую он от нас получил. Это одинарная запись, в ней есть информация куда пришли деньги, и сколько этих денег.
Также в нем написано допустим «молоко — 1 штука, 5 рублей» и «хлеб — 2 штуки, 10 рублей». Это тоже одинарная запись, вернее две одинарные записи — со счета «склад Рога и Копыта, молоко на складе» ушли 5 рублей, а куда неизвестно, и «со счета хлеб на складе Рога и Копыта» ушло 10 рублей, а куда неизвестно.
Вы приходите домой и записываете себе в тетрадку — потратил в магазине 15 рублей. Это одинарная запись, ибо известно откуда ушли деньги (кошелек), и сколько их, но неизвестно кому они ушли. Также вы записываете «купил молоко за 5 рублей». Это одинарная запись — увеличение счета «молоко в холодильнике» на 5 рублей. Ну и третья одинарная запись «хлеб в хлебнице» — плюс десять рублей.
Тут у нас записывается по одну счету денег, и по одному счету товаров.
По сути мы получили шесть одиночных записей. Но сопоставить их между собой сложно Они не связаны воедино. И когда их будет тысяча, и потом мы увидим ошибку, то отследить ее происхождение будет невозможно.
А теперь представьте себе не чек, а накладную. Стандартную, какими обмениваются юрлица. В накладной есть продавец и покупатель, ну и хлеб с молоком и их цены.
Тут уже прямая связь — хлеб из магазина перекочевал в хлебницу, а молоко из магазина перекочевало в холодильник. Ну и до кучи платежку добавим, где есть номер счета плательщика и номер счета получателя. И если вдруг у нас не хватит хлеба в холодильнике то мы сразу подумаем — либо мы не записали операцию когда он у нас был потрачен, либо что-то не то с операцией когда он у нас поступил, и сразу окажется что мы забыли его на кассе.
Информации во втором случае больше не стало, информации столько-же, но в первом случае это шесть одиночных записей, а во втором — три двойных. И сразу проще найти ошибки.
Извините за грубость, но это уже просто троллинг какой-то. Я наверное уже двадцатый раз повторяю — В ДВОЙНОЙ ЗАПИСИ НЕТ НИКАКОЙ ИЗБЫТОЧНОЙ ИНФОРМАЦИИ.
Двойная запись требует писать всю информацию. Один раз, но всю.
В супермаркете нам всем дают фискальный чек.
В фискальном чеке есть информация о продавце (том кто получил деньги) и о сумме которую он от нас получил. Это одинарная запись, в ней есть информация куда пришли деньги, и сколько этих денег.
Также в нем написано допустим «молоко — 1 штука, 5 рублей» и «хлеб — 2 штуки, 10 рублей». Это тоже одинарная запись, вернее две одинарные записи — со счета «склад Рога и Копыта, молоко на складе» ушли 5 рублей, а куда неизвестно, и «со счета хлеб на складе Рога и Копыта» ушло 10 рублей, а куда неизвестно.
Вы приходите домой и записываете себе в тетрадку — потратил в магазине 15 рублей. Это одинарная запись, ибо известно откуда ушли деньги (кошелек), и сколько их, но неизвестно кому они ушли. Также вы записываете «купил молоко за 5 рублей». Это одинарная запись — увеличение счета «молоко в холодильнике» на 5 рублей. Ну и третья одинарная запись «хлеб в хлебнице» — плюс десять рублей.
Тут у нас записывается по одну счету денег, и по одному счету товаров.
По сути мы получили шесть одиночных записей. Но сопоставить их между собой сложно Они не связаны воедино. И когда их будет тысяча, и потом мы увидим ошибку, то отследить ее происхождение будет невозможно.
А теперь представьте себе не чек, а накладную. Стандартную, какими обмениваются юрлица. В накладной есть продавец и покупатель, ну и хлеб с молоком и их цены.
Тут уже прямая связь — хлеб из магазина перекочевал в хлебницу, а молоко из магазина перекочевало в холодильник. Ну и до кучи платежку добавим, где есть номер счета плательщика и номер счета получателя. И если вдруг у нас не хватит хлеба в холодильнике то мы сразу подумаем — либо мы не записали операцию когда он у нас был потрачен, либо что-то не то с операцией когда он у нас поступил, и сразу окажется что мы забыли его на кассе.
Информации во втором случае больше не стало, информации столько-же, но в первом случае это шесть одиночных записей, а во втором — три двойных. И сразу проще найти ошибки.
Я не понимаю, зачем вам в вашем примере знать что-о о счетах продавца (оставим в стороне вопрос, вообще позволит ли продавец вам знать эту информацию)? Какая разница, молоко со склада пришло, с молокозавода или напрямую из-под коровы? Что то вы усложняете. У нас есть 2 операции:
- +молоко в холодильнике, эквивалент 5 рублей — -5 рублей в магазине "Рога и копыта"
- +хлеб в холодильнике, эквивалент 10 рублей — -10 рублей в магазине "Рога и копыта"
При желании можете у этих двух операций хранить ссылку на чек, что вам дали в магазине, таким образом они будут объединены. В чем тут запутаться, я не пойму. А вот в вашем описании действительно черт ногу сломит.
Кстати, не очень понятно, зачем продукты в деньгах учитывать и что будет, если завтра я продам молоко, но по 10 рублей...
Это не две операции, а две пары связанных операций по разным счетам учёта на равные по модулю, но противоположные по сумме. Запутаться можно если перепутать суммы или знаки. Чтобы этого не было и делается двойная запись (и для холодильника, и для кошелька) с обязательным условием равентства по модулю со сверкой итогового баланса и желательной сквозной ссылкой на чек или на вторую запись, для упрощения поиска ошибки, когда она обнаружится.
Нет, это именно 2 операции. Под операцией а подразумеваю перенос денег с одного места (счета, если вам так понятнее) в другое, возможно, с трансформацией (деньги -> молоко, деньги -> хлеб).
- Перепутать знаки
- Перепутать модули
- Забыть сделать вторую операцию
Многовато что-то случаев, когда можно что-то сделать не так против железобетонной одной операции, с одной суммой и одним знаком (определяющем, куда идут деньги (причем именно сами деньги, а не их эквивалент в виде молока или хлеба) — к нам или от нас), где просто нечего путать. Можно лишь ввести неправильные данные, ну так от этого никакая система не застрахована, она не может понять, какие данные правильные, а какие нет. Если вы ей говорите, что купили по 100 рублей, хотя стоило 10 — у вас в любом случае будут отражены 100 рублей, а не правильные 10.
Я смотрю то, что вы написали: "+молоко в холодильнике, эквивалент 5 рублей — -5 рублей в магазине "Рога и копыта"":
два счёта, (холодильник и кошелек), по одной операции на каждый с равным модулем и противоположным знаком — типичная двойная запись. Суть двойной записи в том, что каждая операция проходит по двум счетам одновременно с одной суммой.
Избыточное кодирование — это все-таки не просто дублирование.
RAID 1 — просо дублирование.
Дублирование, по сути — простейший вариант избыточного кодирования.
Не понимаю, что вы хотите сказать. Да, RAID 1 — просто дублирование, поэтому его надежность меньше, чем у методов с избыточным кодированием. Тут на хабре недавно была статья, где говорилось об этом, и в частности для RAID делался парадоксальный вывод, что надежность хранения данных тем меньше, чем больше дисков.
хочу сказать, что ваш начальный тезис — ошибочен.
1. непонятно что такое «везде»
2. вот я привел несколько примеров, когда наоборот — избыточная информация позволяет не только выявлять ошибки (CRC) но и корректировать их (ECC и прочие), или даже просто примитивное дублирование (RAID 1) повышает надежность хранения информации — то есть, в случае возникновения ошибок на этом уровне, это не приводит к ошибкам далее — используют ту копию, которая осталась целой.
На статью с парадоксальным выводом хотелось бы ссылку.
Что же касательно двойной записи в бухгалтерии, то судя по вашим комментариям к этой статье, вы не разобрались, и даже желания разобраться не видно.
Везде говорят, что для минимизации ошибок нужно избегать дублирования информации,
1. непонятно что такое «везде»
2. вот я привел несколько примеров, когда наоборот — избыточная информация позволяет не только выявлять ошибки (CRC) но и корректировать их (ECC и прочие), или даже просто примитивное дублирование (RAID 1) повышает надежность хранения информации — то есть, в случае возникновения ошибок на этом уровне, это не приводит к ошибкам далее — используют ту копию, которая осталась целой.
На статью с парадоксальным выводом хотелось бы ссылку.
Что же касательно двойной записи в бухгалтерии, то судя по вашим комментариям к этой статье, вы не разобрались, и даже желания разобраться не видно.
Двойная запись — это термин из времён бумажной бухгалтерии, когда агрегацию по счетам (само слово «счёт» намекает, что это агрегат каких-то первичных данных) из единой «базы» в виде «амбарной книги» делать было весьма затруднительно, а значит нельзя было контролировать остатки по счетам, особенно в момент проведения операции. Придумали «материализованные вьюхи» в виде карточек счетов с текущим балансом, на которые ссылаются записи в «амбарной книги». Но поскольку в проводке участвует два счёта (откуда-то взяли и куда-то положили), то балансы счетов нужно менять одновременно в двух карточках. Отсюда и «двойная запись». Сейчас это актуально при, например, использовании реальных материализованных представлений, когда СУБД изменяет две записи вьюхи при добавлении проводки в таблицу.
> Везде говорят, что для минимизации ошибок нужно избегать дублирования информации
Правильно говорят. Только двойная запись — это не дублирование информации.
Бухгалтерия отражает движение материальных ценностей, выраженных в денежных единицах. Любое движение имеет две точки — начало и конец, ушли и пришли, источник и назначение. В обывательской логике привычно думать, что бывают операции, которые имеют одну точку — но это неверно. Точек всегда две и только две. И даже обыватель всегда фиксирует обе точки, только одну из них «держит в уме», и делает вид, что её не существует.
Правильно говорят. Только двойная запись — это не дублирование информации.
Бухгалтерия отражает движение материальных ценностей, выраженных в денежных единицах. Любое движение имеет две точки — начало и конец, ушли и пришли, источник и назначение. В обывательской логике привычно думать, что бывают операции, которые имеют одну точку — но это неверно. Точек всегда две и только две. И даже обыватель всегда фиксирует обе точки, только одну из них «держит в уме», и делает вид, что её не существует.
Статья читается тяжеловато, в ней излишне упрощено всё что можно и нельзя и вместе с упрощением выкинут смысл бухучета. Эти же упрощения приводят к явно неправильным аналогиям.
Примерно так:
- Аналогия "активные — распоряжаемся, пассивные — не можем распоряжаться" не отражает сути. Например смотрим на амортизацию: в РСБУ и МСФО это же пассивный счет, а "распоряжаться" мы им можем. А вот каким нибудь счетом "Общепроизводственные расходы" (который активный) мы вряд ли можем распорядиться.
- А почему пришлось вводить эту аналогию? А потому что цели и принципы бухучета выкинули. Зачем мы вообще считаем эти "счета" и "проводки"? Чтобы бухгалетру было чем заняться? "Понимать общую картину финансов" это и звучит неопределённо и, если уж честно, то бухучет часто скрывает ключевые показатели "общей картины". И, да, упомянутые забалансовые счета, как раз один из компромиссов можду "учесть" и "не укладывается в модель". Потому что там есть например что-нибудь типа "товары на реализации", которые как бы и не наши, но если мы их потеряем, то платить придётся.
В современном мире у бухучета дофига смысловой нагрузки, конечно, это и "стандартный язык" и учет всякой ереси и фискальные учеты, но, насколько я понимаю, главная цель бухучета — посчитать финрез и объяснить из чего он сложился. Мы заработали или угорели? Нам вообще есть из чего дивиденды платить? А из чего складывается финрез? - Но чтобы учет был учетом, а не фантазией фаундера стартапа, нужны принципы.
- Непрерывность (мы не можем пропустить годик и сделать вид что всё ОК, остатки на конец года и на начало следующего — равны),
- объективность (все записи должны подтверждаться бумажкой),
- своевременность (его назвают принцип "начисления", если сделка заключена в январе, то и проводки в январе),
- единая "единица измерения" — деньги, причем в одной валюте. На самом деле принципов больше, но я их не помню :)
- Ага, у нас есть цели и принципы-правила. А вот теперь из принципов-правил мы приходим к инструментам. Из того, что мы считаем "финрез" мы получаем формулу
ФинРез=Наше-НеНаше, или если перенести, тоНаше=НеНаше+Финрез. А теперьНашеназовём активы, аНеНаше+Финрез— пассивы. Осталось ввести правило двойной записи, т.е. у нас проводки могут быть только такие что меняется одинаково пассив и актив, либо внутри пассива и актива "переносится". Осталось назвать "плюс" по активам "Дебетом", по пассивам "Кредитом" (и наоборот). - А дальше надо построить систему счетов и допустимых проводок, которые будут строить наш учет. Тут уже придётся продумать, как сделать такие счета, чтобы учитывать, например, оборудование, которое куплено явно не на один год так, чтобы одновременно знать сколько оно стоило, сколько оно стоит, и если считать, что затраты на это оборудование должны "отбиться" за 5 лет, то насколько эти затраты уже "отбились". Здесь, кстати, если аккуратно разбирать вопрос, то становится абсолютно понятно, что амортизация и срок службы оборудования вещи вообще говоря слабо связанные. Аналогично надо придумать схему проводок и счетов для отражения, например, товара на складе и проводок при его покупке (чтобы отразить финрез). А чтобы бухучет одной организации можно было сравнить с другим, появились стандарты учета (РСБУ, МСФО, GAAP), которые состоят как из "паттернов", так и из конкретных требований по использованию "паттернов".
Дальше. Два счета в проводке — это конечно хорошо, но почему "три счета слишком затруднит контроль правильности"? Да хоть 8, если в сумме по дебету и кредиту одинаково. Это весьма синтетическое ограничение, которое может быть полезно (например, появляется возможность оперировать показателем "обороты между счетами"), а может быть очень неудобно. И в этом же месте можно ввести название: часть проводки по одному счету по одной "стороне" (дебет или кредит) с суммой — корреспонденция или в крайнем случае "полупроводка".
Вообще есть нюанс, что принцип двойной записи, как ни странно, в бумажном виде это скорее три записи, чем две ("главная книга" и суммы в дебет и в кредит), а "двойная" скорее относится к тому, что у проводки есть 2 стороны. В компьютерном мире, конечно, записей может быть как одна, так и много.
Проводки одного документа должны находиться в одной транзакции СУБД — почему? Про одну проводку вопросов нет — она должна быть в одной транзакции. Причем в большинстве систем проводка это относительно сложная сущность которая отражается в несколько таблиц. А почему все проводки документа должны (вот так вот безаппеляционно) быть в одной транзакции СУБД? А как быть если в накладной 20 слонов, а у нас вместо пары слонов жирафы у забора дерево обгладывают или еще что-то подобное? Ситуаций в учете много и вот так железобетонно говорить вешать учетные принципы на некие "транзакции СУБД" неправильно.
Самое смешное, что всё это разжёвано и пережёвано в куче книг, статей и курсов. На книжку по основам бухучета у среднего программиста, который (для примера) разобрался, как внутри работает git или даже может написать неблокирующий стек и может вспомнить все паттерны GoF, уйдет 2-4 часа, если не начинать укуриваться деталями. За столько же времени на пальцах и с коньяком объяснит суть учета хороший замглавбух (главбух слишком усложнит, рядовой не объяснит).
Спасибо за объемный комментарий. Давайте обсудим.
В статье их несколько. Даже Ржевского я не случайно упомянул, и отдельно привел шпаргалку с тем что куда относится. На самом деле дать «правильное» определение бесполезно. Подавляющее большинство полноценных бухгалтеров (я имею ввиду главного или единственного а не «участкового») сути не понимают, а работают исключительно за счет того что у них есть регламентированный план счетов, и в нем все расписано. Помнят какие-то ассоциации, но именно самую суть не улавливают и как только отходишь от регламентированного и можешь составлять полностью свой план счетов — начинают нести полную ахинею. Недавно слышал от главбуха определение от ликвидности. Мол ликвидное активное, неликвидное пассивное.
Как мы можем распоряжаться амортизацией?Могу копать, могу не копать Могу амортизировать, могу не амортизировать, или амортизировать дольше? Это пассивная форма «распоряжения» сродни «могу вернуть кредит дострочно, могу не вернуть вообще, а могу попросить реструктуризацию на больший срок».
Общепроизводственные расходы это чертов «божественный объект» или папка «неперебранное», и вот так вот им целиком распорядиться сложно. А вот конкретными благами которые туда попали — да, можно распоряжаться. Конечно если мы сдадим секретаршу и ксерокс в аренду, то регламентрированный учет заставит нас перенести эти активы на другой счет, но да, мы можем ими распоряжаться. См. мой пример со счетом «Убытки (украли слонов)» — можно простить, «повесить» на охранника, получить страховку и т.п…
Ну не получится такие фундаментальные понятия описать коротким и емким определением чтобы человек не понявший самого принципа двойной записи смог его понять. Не получится.
Понятия активных/пассивных счетов, дебета/кредита и т.п. контринтуитивны, пока не начинаешь мыслить в терминах баланса/проводок.
И да, еще раз повторюсь — это не академическая статья, и не бай Боже не статья по регламентированному учету. Только про основы. Чтобы ПРИНЦИПЫ люди могли использовать в биллингах, ERP и т.п.
Статья и так вышла огромной, при том что содержит лишь треть от того что я хотел, и все равно находятся те кто не понимает, и нужно еще разжевать. Вводить дискуссию на тему зачем оно нужно? Это Хабр а не Талмуд.)
Забалансовые счета это рудимент, поскольку когда бухучет зарождался еще не было программистов, архитекторов и внятных принципов проектирования.
Сделайте два счета — пассивный «Обязательства по товарам на реализации» и активный «товары на реализации» (скорее всего субсчетом «товары на складе»). Всё. Двойная запись, баланс, единообразие архитектуры — всё есть. «Нельзя отражать на балансе то что не наше»? Почему? «Потому что оно отражено на чужом балансе». Но почему черт побери? Они мне его отдали, как оно может у него на балансе быть? Да, у него есть актив «реселлер должен нам товар или деньги», но товар у кого? Кто должен быть балансодержателем? Нет, я знаком с регламентированным учетом, но «по совести»? Но даже если и так, даже если мы не хотим раздувать валюту баланса (не вижу причин — единственный случай когда я использовал валюту так это при анализе устойчивости бизнеса и качества структуры активов при анализе потенциальных заемщиков в банке, и там я бы предпочел видеть такие заемные активы как арендованное оборудование и т.п. в балансе а не за балансом, но черт с ним, хотите за балансом — допустим) — сделайте все счета вложенными в «папочки» (на подобии счет/субсчет) и верхними папками сделайте баланс и забаланс. Всё.
Что собственно и есть «общая картина финансов» :)
Я не заикаюсь о различных коэффициентах оценки активов, но даже просто если кратенько описать все виды балансовв (просто скопировав статью из википедии), то у многих читателей закипит мозг. Давайте сначала научимся получать нашу «общую картину» а потом уже будем учиться ее правильно читать.
Стоп, стоп. Это статья не про принципы и бухучет, а лишь про двойную запись. Напишите статью про принципы, киньте ссылку здесь, наверняка кто-то даст вам инвайт за нее. Я еще раз повторюсь — я не ставил себе цель уложить пять лет обучения бухгалтера в одну статью.
А убытки то наше или ненаше? а финрез это что? А зачем двойная запись если можно одинарной? Ой, а амортизация это финрез или актив, ведь амортизация же наша?.. Это только кажется что так проще, потому что на самом деле у вас уже есть в голове готовая картина и понятные термины, а когда видишь это впервые — будут миллионы вопросов, вы будете разжевывать и получите тоже что у меня, только еще в пять раз больше текста потому что будете рассказывать о принципах (на которых 90% айтишников бросят читать ибо нудятина и капитанство).
Вот про это я честно говоря боюсь даже начинать писать. Напишите. Честно.
Будет интересно всем. Даже если будет сумбурно. Нормального материала по тому как разрабатывать собственный план счетов и собственный регламент — просто нет. Оно размазано по частям по миллионам книг и теорий, но даже плохенькие статьи на эту тему всегда интересны.
Вот не хочу я за регламентированный учет вообще говорить. Он есть. Он такой как есть. Он имеет кучу плюсов, и кучу минусов. По нему написано очень много материала. Бери, изучай, копируй, улучшай. Разве что вскользь упомянуть что сравнивать можно только сделанное по одинаковым стандартам, и для этого существует регламентный учет, но раскрывать тему — фи. Для этого есть нархоз и пять лет учебы.
Меньше чем два нельзя ибо не будет баланса, больше не стоит поскольку усложняет архитектуру. Я не буду углубляться в то почему усложняет ибо это не по теме будет.
Нет, и не может быть никаких ситуаций в которых можно «провести» заведомо неверный документ (неверный с точки зрения текущего учета). Если у нас вместо 20 слонов оказывается 18 слонов и два жирафа, а жирафов у нас нет, то мы переделываем документ который вызвал проводки которые вызвали проблему, и проводим уже исправленный документ. Нельзя быть «чуточку беременной», нельзя быть «частично проведенным документом». Нельзя.
Вам шашечки или ехать? 90% программистов не пойдут тратить 4 часа своей жизни чтобы узнать нужен ли им бухучет и правильная ли это вещь.
Я видел колоссальное количество различных биллингов и прочих приложений где можно было обойтись парой таблиц в духе баланса и проводок а городили адский ад, а потом на него нагораживали еще кучу костылей, и все равно получалась каша.
Казалось бы, зачем программисту которому заказали простенький биллинг для хостинга — читать учебник по бухучету? Где бухучет а где биллинг? А мою статью прочесть за 10 минут с комментариями — вполне реально.
Аналогия «активные — распоряжаемся, пассивные — не можем распоряжаться» не отражает сути.
В статье их несколько. Даже Ржевского я не случайно упомянул, и отдельно привел шпаргалку с тем что куда относится. На самом деле дать «правильное» определение бесполезно. Подавляющее большинство полноценных бухгалтеров (я имею ввиду главного или единственного а не «участкового») сути не понимают, а работают исключительно за счет того что у них есть регламентированный план счетов, и в нем все расписано. Помнят какие-то ассоциации, но именно самую суть не улавливают и как только отходишь от регламентированного и можешь составлять полностью свой план счетов — начинают нести полную ахинею. Недавно слышал от главбуха определение от ликвидности. Мол ликвидное активное, неликвидное пассивное.
Например смотрим на амортизацию: в РСБУ и МСФО это же пассивный счет, а «распоряжаться» мы им можем.
Как мы можем распоряжаться амортизацией?
А вот каким нибудь счетом «Общепроизводственные расходы» (который активный) мы вряд ли можем распорядиться.
Общепроизводственные расходы это чертов «божественный объект» или папка «неперебранное», и вот так вот им целиком распорядиться сложно. А вот конкретными благами которые туда попали — да, можно распоряжаться. Конечно если мы сдадим секретаршу и ксерокс в аренду, то регламентрированный учет заставит нас перенести эти активы на другой счет, но да, мы можем ими распоряжаться. См. мой пример со счетом «Убытки (украли слонов)» — можно простить, «повесить» на охранника, получить страховку и т.п…
Ну не получится такие фундаментальные понятия описать коротким и емким определением чтобы человек не понявший самого принципа двойной записи смог его понять. Не получится.
Понятия активных/пассивных счетов, дебета/кредита и т.п. контринтуитивны, пока не начинаешь мыслить в терминах баланса/проводок.
И да, еще раз повторюсь — это не академическая статья, и не бай Боже не статья по регламентированному учету. Только про основы. Чтобы ПРИНЦИПЫ люди могли использовать в биллингах, ERP и т.п.
А почему пришлось вводить эту аналогию? А потому что цели и принципы бухучета выкинули.
Статья и так вышла огромной, при том что содержит лишь треть от того что я хотел, и все равно находятся те кто не понимает, и нужно еще разжевать. Вводить дискуссию на тему зачем оно нужно? Это Хабр а не Талмуд.)
И, да, упомянутые забалансовые счета, как раз один из компромиссов можду «учесть» и «не укладывается в модель». Потому что там есть например что-нибудь типа «товары на реализации», которые как бы и не наши, но если мы их потеряем, то платить придётся.
Забалансовые счета это рудимент, поскольку когда бухучет зарождался еще не было программистов, архитекторов и внятных принципов проектирования.
Сделайте два счета — пассивный «Обязательства по товарам на реализации» и активный «товары на реализации» (скорее всего субсчетом «товары на складе»). Всё. Двойная запись, баланс, единообразие архитектуры — всё есть. «Нельзя отражать на балансе то что не наше»? Почему? «Потому что оно отражено на чужом балансе». Но почему черт побери? Они мне его отдали, как оно может у него на балансе быть? Да, у него есть актив «реселлер должен нам товар или деньги», но товар у кого? Кто должен быть балансодержателем? Нет, я знаком с регламентированным учетом, но «по совести»? Но даже если и так, даже если мы не хотим раздувать валюту баланса (не вижу причин — единственный случай когда я использовал валюту так это при анализе устойчивости бизнеса и качества структуры активов при анализе потенциальных заемщиков в банке, и там я бы предпочел видеть такие заемные активы как арендованное оборудование и т.п. в балансе а не за балансом, но черт с ним, хотите за балансом — допустим) — сделайте все счета вложенными в «папочки» (на подобии счет/субсчет) и верхними папками сделайте баланс и забаланс. Всё.
главная цель бухучета — посчитать финрез и объяснить из чего он сложился. Мы заработали или угорели? Нам вообще есть из чего дивиденды платить? А из чего складывается финрез?
Что собственно и есть «общая картина финансов» :)
Я не заикаюсь о различных коэффициентах оценки активов, но даже просто если кратенько описать все виды балансовв (просто скопировав статью из википедии), то у многих читателей закипит мозг. Давайте сначала научимся получать нашу «общую картину» а потом уже будем учиться ее правильно читать.
Но чтобы учет был учетом, а не фантазией фаундера стартапа, нужны принципы
Стоп, стоп. Это статья не про принципы и бухучет, а лишь про двойную запись. Напишите статью про принципы, киньте ссылку здесь, наверняка кто-то даст вам инвайт за нее. Я еще раз повторюсь — я не ставил себе цель уложить пять лет обучения бухгалтера в одну статью.
Из того, что мы считаем «финрез» мы получаем формулу ФинРез=Наше-НеНаше, или если перенести, то Наше=НеНаше+Финрез. А теперь Наше назовём активы, а НеНаше+Финрез — пассивы.
А убытки то наше или ненаше? а финрез это что? А зачем двойная запись если можно одинарной? Ой, а амортизация это финрез или актив, ведь амортизация же наша?.. Это только кажется что так проще, потому что на самом деле у вас уже есть в голове готовая картина и понятные термины, а когда видишь это впервые — будут миллионы вопросов, вы будете разжевывать и получите тоже что у меня, только еще в пять раз больше текста потому что будете рассказывать о принципах (на которых 90% айтишников бросят читать ибо нудятина и капитанство).
А дальше надо построить систему счетов и допустимых проводок, которые будут строить наш учет. Тут уже придётся продумать, как сделать такие счета, чтобы учитывать, например, оборудование, которое куплено явно не на один год так, чтобы одновременно знать сколько оно стоило, сколько оно стоит, и если считать, что затраты на это оборудование должны «отбиться» за 5 лет, то насколько эти затраты уже «отбились». Здесь, кстати, если аккуратно разбирать вопрос, то становится абсолютно понятно, что амортизация и срок службы оборудования вещи вообще говоря слабо связанные. Аналогично надо придумать схему проводок и счетов для отражения, например, товара на складе и проводок при его покупке (чтобы отразить финрез).
Вот про это я честно говоря боюсь даже начинать писать. Напишите. Честно.
Будет интересно всем. Даже если будет сумбурно. Нормального материала по тому как разрабатывать собственный план счетов и собственный регламент — просто нет. Оно размазано по частям по миллионам книг и теорий, но даже плохенькие статьи на эту тему всегда интересны.
А чтобы бухучет одной организации можно было сравнить с другим, появились стандарты учета (РСБУ, МСФО, GAAP), которые состоят как из «паттернов», так и из конкретных требований по использованию «паттернов».
Вот не хочу я за регламентированный учет вообще говорить. Он есть. Он такой как есть. Он имеет кучу плюсов, и кучу минусов. По нему написано очень много материала. Бери, изучай, копируй, улучшай. Разве что вскользь упомянуть что сравнивать можно только сделанное по одинаковым стандартам, и для этого существует регламентный учет, но раскрывать тему — фи. Для этого есть нархоз и пять лет учебы.
Дальше. Два счета в проводке — это конечно хорошо, но почему «три счета слишком затруднит контроль правильности»? Да хоть 8, если в сумме по дебету и кредиту одинаково. Это весьма синтетическое ограничение, которое может быть полезно (например, появляется возможность оперировать показателем «обороты между счетами»), а может быть очень неудобно. И в этом же месте можно ввести название: часть проводки по одному счету по одной «стороне» (дебет или кредит) с суммой — корреспонденция или в крайнем случае «полупроводка».
Вообще есть нюанс, что принцип двойной записи, как ни странно, в бумажном виде это скорее три записи, чем две («главная книга» и суммы в дебет и в кредит), а «двойная» скорее относится к тому, что у проводки есть 2 стороны. В компьютерном мире, конечно, записей может быть как одна, так и много.
Меньше чем два нельзя ибо не будет баланса, больше не стоит поскольку усложняет архитектуру. Я не буду углубляться в то почему усложняет ибо это не по теме будет.
Проводки одного документа должны находиться в одной транзакции СУБД — почему? Про одну проводку вопросов нет — она должна быть в одной транзакции. Причем в большинстве систем проводка это относительно сложная сущность которая отражается в несколько таблиц. А почему все проводки документа должны (вот так вот безаппеляционно) быть в одной транзакции СУБД? А как быть если в накладной 20 слонов, а у нас вместо пары слонов жирафы у забора дерево обгладывают или еще что-то подобное? Ситуаций в учете много и вот так железобетонно говорить вешать учетные принципы на некие «транзакции СУБД» неправильно.
Нет, и не может быть никаких ситуаций в которых можно «провести» заведомо неверный документ (неверный с точки зрения текущего учета). Если у нас вместо 20 слонов оказывается 18 слонов и два жирафа, а жирафов у нас нет, то мы переделываем документ который вызвал проводки которые вызвали проблему, и проводим уже исправленный документ. Нельзя быть «чуточку беременной», нельзя быть «частично проведенным документом». Нельзя.
Самое смешное, что всё это разжёвано и пережёвано в куче книг, статей и курсов. На книжку по основам бухучета у среднего программиста, который (для примера) разобрался, как внутри работает git или даже может написать неблокирующий стек и может вспомнить все паттерны GoF, уйдет 2-4 часа, если не начинать укуриваться деталями. За столько же времени на пальцах и с коньяком объяснит суть учета хороший замглавбух (главбух слишком усложнит, рядовой не объяснит).
Вам шашечки или ехать? 90% программистов не пойдут тратить 4 часа своей жизни чтобы узнать нужен ли им бухучет и правильная ли это вещь.
Я видел колоссальное количество различных биллингов и прочих приложений где можно было обойтись парой таблиц в духе баланса и проводок а городили адский ад, а потом на него нагораживали еще кучу костылей, и все равно получалась каша.
Казалось бы, зачем программисту которому заказали простенький биллинг для хостинга — читать учебник по бухучету? Где бухучет а где биллинг? А мою статью прочесть за 10 минут с комментариями — вполне реально.
Вот как раз для биллинга все эти двойные записи и проводки — лишнее.
Это пока вы не начинаете развивать бизнес-логику.
Как только вы хотите видеть и «кредит пока не оплатит», и прибыльность клиента, и можем ли мы дать клиенту скидку (по чем мы брали этот сервер) и т.п.
Слишком, слишком много сущностей выплывает.
Как только вы хотите видеть и «кредит пока не оплатит», и прибыльность клиента, и можем ли мы дать клиенту скидку (по чем мы брали этот сервер) и т.п.
Слишком, слишком много сущностей выплывает.
Как только вы хотите видеть и «кредит пока не оплатит»
Если у нас учёт с персонализацией по клиентам — тогда надо создавать автоматически индивидуальный план счетов для каждого клиента (типа кредит там, на роутер, типы счетов по видам услуг и т. д и т. п.).
Но далее — в не очень крупной организации потребуется анализировать, как минимум, внутриорганизационные движения денег между подразделениями, и, в итоге, потребуется ERP-система.
Поэтому, по видимому, ERP-системы и являются эволюционным развитием классической бухгалтерии.
И, даже в "простых" случаях лучше попробовать внедрить на вырост ADempiere, чем баловаться самописами.
Очевидночто не все йогурты одинаково полезнысуществует большая разница между счетами отражающими деньги в «кассе» от того сколько мы должны денег поставщикам. Соответственно мы разделяем нашу табличку на две.
Нет, не очевидно.
Один счёт — одна таблица. Потратил деньги — минус, заработал — плюс.
Счетов должно быть несколько, вот это очевидно. В вашем примере это ЯндексДеньги, пейпал, наличка,...
Спасибо за ваш вопрос.
Вы совершаете самую распространенную ошибку.
Вы предлагаете выкинуть часть счетов считая что они придуманы искусственно.
На самом деле все они всегда существуют, просто в неправильном учете их «держат в уме».
В уме держат сколько должен клиент. В уме держат сколько мы должны поставщику, в уме держат сколько кто из учредителей внес в проект, в уме держат на что пошли эти деньги.
Всё это держат в уме.
А потом получается хаос.
Потом это «в уме» забывается, запутывается и все эти ошибки всплывают лишь тогда, когда уже слишком поздно.
Вы совершаете самую распространенную ошибку.
Вы предлагаете выкинуть часть счетов считая что они придуманы искусственно.
На самом деле все они всегда существуют, просто в неправильном учете их «держат в уме».
В уме держат сколько должен клиент. В уме держат сколько мы должны поставщику, в уме держат сколько кто из учредителей внес в проект, в уме держат на что пошли эти деньги.
Всё это держат в уме.
А потом получается хаос.
Потом это «в уме» забывается, запутывается и все эти ошибки всплывают лишь тогда, когда уже слишком поздно.
Дал деньги в долг — это потратил? Получил долг назад — это заработал? А если не деньги дал, а клиенту товар или услугу в кредит предоставил? А обналичка ЯДа? Вроде потратил, вроде заработал, но заработал меньше чем потратил.
Простите, статью пробежал вскользь.
У вас есть ситуации когда на одном и том же счете, в остатках есть суммы как по дебиту так и по кредиту?
Давно не работал с бухгалтерией, вроде это активно пассивный счет называлось.
Кстати, а кроме суммы, количество у вас можно считать?
И еще, поиск по статье не находит слово «субконто».
У вас есть ситуации когда на одном и том же счете, в остатках есть суммы как по дебиту так и по кредиту?
Давно не работал с бухгалтерией, вроде это активно пассивный счет называлось.
Кстати, а кроме суммы, количество у вас можно считать?
И еще, поиск по статье не находит слово «субконто».
На активно-пассивном счете теоретически может быть либо кредитовое сальдо, либо дебетовое. На практике у нас есть такое понятие как счет и субсчет, где счет агрегирует в себе значения нескольких разных субсчетов, например счет взаимоотношения с контрагентами будет агрегировать как счета где нам должны клиенты так и счета где мы должны поставщикам (или клиентам оплатившим предоплату), так что в реальном учете такое бывает.
И именно по этой причине я против активно-пассивных счетов. В статье я такие счета не описываю, и в своих системах учета такие счета не ввожу. Но в регламентированном учете такие счета существуют.
И именно по этой причине я против активно-пассивных счетов. В статье я такие счета не описываю, и в своих системах учета такие счета не ввожу. Но в регламентированном учете такие счета существуют.
в своих системах учета такие счета не ввожу. Но в регламентированном учете такие счета существуют.Вот в чем дело, мне казалось что нужно решать задачи бизнес требований (требований бух. учета, например).
В голове такая картина — подходит ко мне бухгалтер и говорит: «мне вот нужна такая проводка и такой активно пассивный счет», а я такой бухгалтеру — «обломиська! Я не завожу такие счета, которые вам нужны».
Мне интересно, как вы обходите требования бухгалтеров, нагибаете их что бы они прогнулись под вас? И что, никогда расхождений с законодательством не бывает?
Активно-пассивный счет легко реализуется парой активного и пассивного с помощью автоматического перебрасывания с одного на другой. В начале комментариев более подробное обсуждение.
Плюс я не пишу (пока) конкурента 1С, и не занимаюсь регламентированным учетом.
Бухгалтеру он понадобится однозначно, а финансисту — не факт.
Ну и да, если честно то по результатам текущей оффлайновой дискуссии по этому поводу, я над своей позицией по активно-пассивному начинаю слегка сомневаться.
Плюс я не пишу (пока) конкурента 1С, и не занимаюсь регламентированным учетом.
Бухгалтеру он понадобится однозначно, а финансисту — не факт.
Ну и да, если честно то по результатам текущей оффлайновой дискуссии по этому поводу, я над своей позицией по активно-пассивному начинаю слегка сомневаться.
А если по одному договору у клиента дебет, а по другому кредит? Вообще как договора сопрягаются со счетами?
p.s. может сморозил глупость т.к. не разобрался в учете…
p.s. может сморозил глупость т.к. не разобрался в учете…
В таком случае зависит от того что прописано в договорах, или от того как конкретно тот кто-то самый наглый решает считать :)
Реально можно как зачитывать так и не зачитывать.
По хорошему надо делать сверку и предлагать делать зачет.
Вопрос только кажется простым. Вроде договора однородные, сроки по обоим вышли, процентов нет, валюта одна, штрафных санкций нет, чего бы и не зачесть?
Однако моментов бывает множество.
Например в системах налогообложения основанных на обороте — прямо запрещены бартеры, взаимозачеты и т.п. Только прямая денежная оплата.
Мне несколько раз приходилось гонять десятки миллионов (не рублей и не гривен) по кругу между связанными организациями поскольку чисто по требованиям гос.органов нельзя было делать взаимозачеты (большие суммы касались операций со ценными бумагами, но не суть, по требованиям фискалов тоже бывает такое). Но если контрагент не против, то делать взаимозачет хорошая практика.
Реально можно как зачитывать так и не зачитывать.
По хорошему надо делать сверку и предлагать делать зачет.
Вопрос только кажется простым. Вроде договора однородные, сроки по обоим вышли, процентов нет, валюта одна, штрафных санкций нет, чего бы и не зачесть?
Однако моментов бывает множество.
Например в системах налогообложения основанных на обороте — прямо запрещены бартеры, взаимозачеты и т.п. Только прямая денежная оплата.
Мне несколько раз приходилось гонять десятки миллионов (не рублей и не гривен) по кругу между связанными организациями поскольку чисто по требованиям гос.органов нельзя было делать взаимозачеты (большие суммы касались операций со ценными бумагами, но не суть, по требованиям фискалов тоже бывает такое). Но если контрагент не против, то делать взаимозачет хорошая практика.
Он активно-пассивные счета разбивает на связанные активный и пассивный. Так что технически ничего не мешает в таком составном счете иметь одновременно остатки и в активе, и в пассиве.
А вот для представления более логичного объекта — активно-пассивного счета с односторонним сальдо (который, между прочим, в том же биллинге встречается чаще чем все остальные типы счетов) предполагается вводить дополнительный модуль, который будет автоматически сокращать остатки.
А почему не рассматриваете активно-пассивный счет?
Мне интересно для себя, в мире бухгалтерии либо законодательстве может что то изменилось?
Мне интересно для себя, в мире бухгалтерии либо законодательстве может что то изменилось?
По общему правилу МСФО (и не только МСФО), дебиторская задолженность (долг нам) и кредиторская задолжность (наш долг другим) должны показываться отдельно: дебиторка в активе, кредиторка в пассиве — даже если это один и тот же контрагент (но два разных договора). Свернуть дебиторку и кредиторку между собой можно, только если в обоих договорах с данным контрагентом прямо указано, что стороны согласились не рассматривать задолженности по этим договорам раздельно.
Т.е. по умолчанию, учет задолженностей по разным договорам с одним и тем же контрагентом всегда расматриваются раздельно.
Если сворачивать — будет происходить занижение нашей реальной задолженности перед третьми лицами, которая публикуется во внешней отчетности или показывается банкам при получении кредитов.
Пример: мы должны Васе 100 рублей по кредиту, обеспеченный залогом и штрафными процентами, а Вася нам должен за товар 120 рублей. Если свернуть, то мы можем расслабиться — у нас нет долгов. Но на самом деле долг есть: мы должны Васе 100 рублей. И если мы про это забудем, то нам выставят штрафные проценты по кредититу и/или заберут залог. При этом Вася может продолжать тянуть с погашением своего долга 120 рублей нам.
Свернуть долг может принудительно только суд: мы подаем на Васю в суд на 120 рублей, а Вася выставляет встречный иск нам на 100 рублей. Суд сворачивает оба долга и выносит решение: Вася должен выплатить нам 20 рублей.
Т.е. по умолчанию, учет задолженностей по разным договорам с одним и тем же контрагентом всегда расматриваются раздельно.
Если сворачивать — будет происходить занижение нашей реальной задолженности перед третьми лицами, которая публикуется во внешней отчетности или показывается банкам при получении кредитов.
Пример: мы должны Васе 100 рублей по кредиту, обеспеченный залогом и штрафными процентами, а Вася нам должен за товар 120 рублей. Если свернуть, то мы можем расслабиться — у нас нет долгов. Но на самом деле долг есть: мы должны Васе 100 рублей. И если мы про это забудем, то нам выставят штрафные проценты по кредититу и/или заберут залог. При этом Вася может продолжать тянуть с погашением своего долга 120 рублей нам.
Свернуть долг может принудительно только суд: мы подаем на Васю в суд на 120 рублей, а Вася выставляет встречный иск нам на 100 рублей. Суд сворачивает оба долга и выносит решение: Вася должен выплатить нам 20 рублей.
Это вы рассматриваете ситуацию с разными договорами. Разные договора — разные счета, это очевидно.
Но такая ситуация может быть и в рамках одного договора. Например, при авансовых платежах. Вы же не станете утверждать что авансовый платеж нельзя "сократить" с более поздней задолженностью?
Юридически можно. Но бухгалтерии все равно их не сворачивают. Если заказов десятки и сотни по договору, то при таком соврачивании потом концов не найдешь — из чего сложился итоговый долг покупателя или поставщика на дату сверки. Итог сверки между поставщиком и покупателем должен быть легко проверяемым, т.е. равен сумме их взаимных долгов по всем заказам данного договора.
И в чем же сложность "нахождения концов"?
Если "сворачивание" — отдельная операция, то да — она будет чисто визуально мешаться (потому мне и не нравится предложение автора о "наблюдателе"). Но если структура базы выстроена так, чтобы отдельное "сворачивание" просто не требовалось — то в чем сложность взять проводки по условию и посмотреть их?
Если свернуть, то мы можем расслабиться — у нас нет долгов. Но на самом деле долг есть: мы должны Васе 100 рублей.Вы подразумеваете что сальдо по счету в разрезе контрагента всегда либо дебетовое либо кредитовое?
А разве нельзя сальдо по субконто не сворачивать, а так и оставить:
«счет: 33.6, субконто: ЧП Иванов, Дт: 100, Кт: 120»
вместо
«счет: 33.6, субконто: ЧП Иванов, Кт: 20»
То есть, сворачивание, это обязательное свойство счета?
Полный нарастающий итог за всю историю постоянно показывать при просмотре баланса счёта? Или каким-то специальным обязательным признаком в проводке указывать дебетуем/кредитуем мы активную или пассивную часть? Во втором случае это мало чем, по-моему, отличается от двух раздельных счетов.
Вопрос не в сворачивании собственно. Вопрос на самом деле такой:
1) показать в отчетности актив 120 рублей и долг 100 рублей;
2) показать только актив в размере 20 рублей.
Ответ такой: правильный вариант — это №1, если это разные договоры. Или вариант №2, если это один договор (цепочка поставок и платежей по ним).
1) показать в отчетности актив 120 рублей и долг 100 рублей;
2) показать только актив в размере 20 рублей.
Ответ такой: правильный вариант — это №1, если это разные договоры. Или вариант №2, если это один договор (цепочка поставок и платежей по ним).
Вроде в 1С был отчет «карточка счета» или еще какой то, и мне казалось в отчете на некоторых счетах можно было увидеть одновременно и дебетовый остаток и кредетовый, но возможно не в разрезе конкретного субконто.
Мне хотелось бы знать, нелогично ли, хотя бы у некоторых счетов, не «сворачивать» сальдо автоматически, а показывать оба остатка.
Например завести какой то флаг у счета, и назвать этот флаг "автоматически сворачивать сальдо".
А когда необходимо свернуть остатки, то тогда для этого делать специальную какую то проводку с одинаковым счетом по Дт и Кт, типа:
«счет Дт: 33.6, счет Кт: 33.6, субконто: ЧП Иванов, Сумма: 100»
где сумма 100 это min(120, 100)
Хотя, похоже что да, это скорее свойство не счета, а отчетной системы по счету.
Или флаг можно установить на комбинацию счета и субконто, например не сворачивать для комбинации счет+типСубконто1+типСубконто2 — «счет 33.6, Контрагент, договор»
Мне хотелось бы знать, нелогично ли, хотя бы у некоторых счетов, не «сворачивать» сальдо автоматически, а показывать оба остатка.
Например завести какой то флаг у счета, и назвать этот флаг "автоматически сворачивать сальдо".
А когда необходимо свернуть остатки, то тогда для этого делать специальную какую то проводку с одинаковым счетом по Дт и Кт, типа:
«счет Дт: 33.6, счет Кт: 33.6, субконто: ЧП Иванов, Сумма: 100»
где сумма 100 это min(120, 100)
Хотя, похоже что да, это скорее свойство не счета, а отчетной системы по счету.
Или флаг можно установить на комбинацию счета и субконто, например не сворачивать для комбинации счет+типСубконто1+типСубконто2 — «счет 33.6, Контрагент, договор»
Вам не кажется что вы сейчас изобрели тот самый вариант который я озвучил в самом начале комментариев и который вы критикуете уже пол дня как?
Два раздельных счета, которые при необходимости (ваше «если есть галочка») сворачиваются автоматически.
Два раздельных счета, которые при необходимости (ваше «если есть галочка») сворачиваются автоматически.
Понятно.
Дело в том что меня как раз интересуют всякие возможности учетных систем и для чего, в каких случаях, эти возможности применяются на практике.
Значит вы у себя задумали «возможность»-флаг «автоматически сворачивать сальдо».
Теперь мне бы еще узнать на каких счетах вы его включаете, а на каких выключаете, и зачем.
Если уже писали простите, длинный текст читаю бегло, если в нем обсуждают что то, что я уже долго не использовал.
Дело в том что меня как раз интересуют всякие возможности учетных систем и для чего, в каких случаях, эти возможности применяются на практике.
Значит вы у себя задумали «возможность»-флаг «автоматически сворачивать сальдо».
Теперь мне бы еще узнать на каких счетах вы его включаете, а на каких выключаете, и зачем.
Если уже писали простите, длинный текст читаю бегло, если в нем обсуждают что то, что я уже долго не использовал.
Очень зависит от конкретной задачи. Тут ведь уже отвечали — обычно в рамках одного счета «сворачивают», а в рамках разных — только по сверке.
Вместе с тем если это простая логика, например биллинг хостера, где есть счет клиента и его движения, то никто не заморачивается с разделением а делают активно-пассивный счет или в моем случае прописывают событие сворачивания при сохранении проводок на эти счета (в ваших терминах — стоит галочка).
Вместе с тем если это простая логика, например биллинг хостера, где есть счет клиента и его движения, то никто не заморачивается с разделением а делают активно-пассивный счет или в моем случае прописывают событие сворачивания при сохранении проводок на эти счета (в ваших терминах — стоит галочка).
Если разница между активом и пассивом равна 10 рублей — значит бухгалтер ошибся один раз на 10 рублей.
А вот разница между активом и пассивом равна нулю, то значит бухгалтер ошибся два раза: первый раз на +1000000000 рублей, а потом второй раз на -1000000000 рублей :)
А вот разница между активом и пассивом равна нулю, то значит бухгалтер ошибся два раза: первый раз на +1000000000 рублей, а потом второй раз на -1000000000 рублей :)
Как-то по статье вроде показалось, что она вообще о принципе двойной записи в учёте, типа подсказка для желающих биллинг или домашнюю бухгалтерию на коленке написать, не натыкаясь на камни, которые люди научились обходить если не несколько тысячилетий назад, то пятьсот лет назад точно, но по комментариям уже кажется, что она именно о регламентированном бухгалтерском учёте. Как впечатление правильнее?
Первое. Я не люблю регламентированный учет, и чуть ли не в каждом комментарии говорю что я его не затрагиваю. Но те для кого эта тема новая комментируют мало, в основном пишут те кто уже знаком с темой, так что в комментариях упорно скатываемся к регламентированному, как бы я от него не открещивался.
Я не люблю регламентированный учетСледует ли добавить "и моя система не реализует его"… и тогда я задамся вопросом: «хм, а какое тогда есть моральное право у этого человека вообще учить как делать бух учет, он же похоже подлость делает новичкам учя их плохому»
хотя… комментарии для того и есть что бы обсудить/поспорить
В том то и дело. Я ведь в самом начале написал что статья не академическая, а по основам. И везде говорю что в регламентированном учете немного не так, хоть принципы и сохраняются, но вы не можете произвольно организовывать логику, а должны пользоваться теми шаблонами что за вас придумали законодатели.
Что никак не отменяет того факта что активно-пассивные и забалансовые счета — лютый легаси, который нельзя бросить в регламентированном, но не стоит начинать в своем собственном управленческом.
Что никак не отменяет того факта что активно-пассивные и забалансовые счета — лютый легаси, который нельзя бросить в регламентированном, но не стоит начинать в своем собственном управленческом.
История в тему: «В одной бухгалтерии работал самый лучший бухгалтер. Все его считали самым умным. Каждое утро он открывал ящик стола и заглядывал в него. А потом закрывал ящик на ключ. И никто не знал что у него в ящике. Наконец, самый лучший бухгалтер ушел на пенсию. И вся бухгалтерия бросилась открывать его ящик чтобы посмотреть что у него там. А там была только одна надпись на дне: „Дебет — слева, кредит — справа“ :)
>Так мы подошли ко второму фундаментальному понятию — проводка.
Какая проводка? Электрики что ли? это «бухгалтерская запись»
Какая проводка? Электрики что ли? это «бухгалтерская запись»
есть такое слово «крыжить»
*удаки, которые минусуют поди вики пончитались ))
"бухгалтерская запись" — 85тыс
"бухгалтерская проводка" — 146тыс
Ну и расшифровка терминов в словарях:
Запись
Проводка
Но даже если бы вы каким-то чудесным образом были правы — минусы вы бы получили чисто за форму подачи вашего мнения.
Большинство комментариев от ридонли которые я тут одобрил — противоречили моей позиции, но в основном к ним шла аргументация…
"бухгалтерская проводка" — 146тыс
Ну и расшифровка терминов в словарях:
Запись
Проводка
Но даже если бы вы каким-то чудесным образом были правы — минусы вы бы получили чисто за форму подачи вашего мнения.
Большинство комментариев от ридонли которые я тут одобрил — противоречили моей позиции, но в основном к ним шла аргументация…
Не следуйте принципу «толпа леммингов не может ошибкаться», посмотрите англоязычную литературу (accounting record, accounting transaction)
Это исключительно терминологический вопрос. Мы обсуждаем русскоязычный термин, на русскоязычном ресурсе и во всех странах где русский язык имеет существенное хождение — преобладает советская терминология.
Вы ведь не станете называть леммингами тех кто предпочитает понятие астронавт понятию космонавт? При этом термины при их семантической близости имеют определенные различия.
В данном случае между советской и западной школой есть такое же существенное различие — колво участвующих в операции счетов. Так что различие терминологии это как раз благо а не зло.
Да и вместе с этим. Черт с ним, называйте как хотите. В вашей позиции возмущает не это, а то что вы критикуете академически принятую позицию, поддерживаемую большинством, при этом позиция эта относится исключительно к терминологии.
Вы ведь не станете называть леммингами тех кто предпочитает понятие астронавт понятию космонавт? При этом термины при их семантической близости имеют определенные различия.
В данном случае между советской и западной школой есть такое же существенное различие — колво участвующих в операции счетов. Так что различие терминологии это как раз благо а не зло.
Да и вместе с этим. Черт с ним, называйте как хотите. В вашей позиции возмущает не это, а то что вы критикуете академически принятую позицию, поддерживаемую большинством, при этом позиция эта относится исключительно к терминологии.
Наброшу немного математики.
Если обобщать, то двойная запись — это частный случай «балансового вектора», — то есть вектора, сумма компонент которого равна нулю. Такие векторы удобны тем, что их можно складывать/вычитать — результатом снова является балансовый вектор.
Поэтому думаю, что должны существовать такие хозяйственные операции, которые удобно отражать «балансовой проводкой», а не двойной записью. В том смысле, что их принципиально нельзя свести к двойной записи.
Примером балансовой проводки на 4-х счетах может быть что-то типа (+50 Cч1, -40 Сч2, -20 Сч3, +10 Сч4).
Если обобщать, то двойная запись — это частный случай «балансового вектора», — то есть вектора, сумма компонент которого равна нулю. Такие векторы удобны тем, что их можно складывать/вычитать — результатом снова является балансовый вектор.
Поэтому думаю, что должны существовать такие хозяйственные операции, которые удобно отражать «балансовой проводкой», а не двойной записью. В том смысле, что их принципиально нельзя свести к двойной записи.
Примером балансовой проводки на 4-х счетах может быть что-то типа (+50 Cч1, -40 Сч2, -20 Сч3, +10 Сч4).
В таких случаях в бухучёте обычно делается несколько проводок…
Да, конечно, но тогда часть информации теряется. Например, о корреспонденции. Если приведенный выше вектор интерпретировать как результаты преферанса (двое выиграли 50 и 10 рублей, а двое проиграли 40 и 20), то в принципе можно сделать обычные проводки через доп. счёт (игральный стол), но тогда сложно извлечь инфу, кому именно проиграли (или выиграли) игроки.
А что сложного? У проводок всегда есть некий общий контейнер. Я называю его "документ". Каждая проводка ссылается на то какой документ ее породил, так что пройдя по одной проводке мы видим всю картину документа «результат преферанса».
Оффтоп: Сомневался стоит ли писать про документ, не усложнит ли… Оказалось что актуально. Уже несколько раз всплывал в этом обсуждении.
Оффтоп: Сомневался стоит ли писать про документ, не усложнит ли… Оказалось что актуально. Уже несколько раз всплывал в этом обсуждении.
В нашей системе проводки объединятся в операции (в одном документе может быть несколько операций), но это не решает проблему корреспонденции, например. Как по итогам месяца посмотреть, кто у кого выигрывал в преферанс? Запрос будет сложным и неудобным.
В одной известной бух. системе, Операция это Документ.
В одной Операции может быть несколько Проводок.
А для чего в вашей системе несколько Операций для одного Документа?
Может у вас Операция это всего лишь одна Проводка?
В одной Операции может быть несколько Проводок.
А для чего в вашей системе несколько Операций для одного Документа?
Может у вас Операция это всего лишь одна Проводка?
Ну например операции "Реализация товара" и "Реализация услуг" могут выполняться в рамках одного документа. И состоять при этом из разных проводок…
В рамках какого документа? Чем руководствуетесь делая единый документ? Может лучше делать несколько документов, а общее для них называть «сделка» или что-то вроде?
Конкретно в этой ветке мне бы не хотелось это обсуждать. Мы на эти вопросы ответили ещё 20 лет назад. Триада — "проводка, операция, документ" — универсальная модель организации учета.
Триада — «проводка, операция, документ» — универсальная модель организации учетаГуглится что то не то, есть ссылка?
Ну если уж говорить об универсальной триаде, то это вопрос сугубо терминологический. Триада «проводка, документ, сделка» ничем собственно не отличается. Единственное что — да, по результатам этой ветки я себе выберу более нейтральные названия чтобы не было «документ» в этой цепочке.
А с проводками у которых есть множество счетов запрос будет простым?
Для начала мы будем вынуждены дробить такую проводку на единичные записи, поскольку нельзя сделать запись с переменным количеством полей (только давайте без NoSQL, она здесь только внесет еще больше сложностей ибо до N-ной части проводки будет сложно добраться).
Потом из этих осколков проводки нам нужно будет как-то собрать общую картину. Ну ок, собрали. Но что мы увидим? По факту то все выигравшие выиграли у всех проигравших. Так что если мы хотим не просто узнать кто у кого, а получить это в денежном выражении (а мы хотим, иначе нечего было начинать), то нам придется как-то эти суммы делить.
Для примера возьмем ваш случай с двумя победителями и двумя проигравшими.
Распишем это так:
В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 руб
Данные из таких проводок легко извлекаются и агрегируются.
Для начала мы будем вынуждены дробить такую проводку на единичные записи, поскольку нельзя сделать запись с переменным количеством полей (только давайте без 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 руб
Данные из таких проводок легко извлекаются и агрегируются.
Немного позанудствую.
Разве так делают, а как на самом деле правильно делать проводки?
10 лет не в бухгалтерии, но вроде бы, сначала насчитывают долг, а потом по проводкам поступают «бумажные» денежки.
И вроде напрямую так не делают, а то если П1 дал деньгу В1, то получается что создался долг как будто В1 теперь должен П1, но ведь он не должен и не вернет никогда долг, проводки как то по другому принципу пишутся, через «вспомогательные» счета.
Разве так делают, а как на самом деле правильно делать проводки?
10 лет не в бухгалтерии, но вроде бы, сначала насчитывают долг, а потом по проводкам поступают «бумажные» денежки.
И вроде напрямую так не делают, а то если П1 дал деньгу В1, то получается что создался долг как будто В1 теперь должен П1, но ведь он не должен и не вернет никогда долг, проводки как то по другому принципу пишутся, через «вспомогательные» счета.
Проводки пишутся так как записано в вашей учетной политике. Если мы говорим о регламентированном учете, то там мест для маневра не очень много, но они тоже есть. А для управленческого вы вольны строить как хотите.
Что касается последовательности проводок, то тут особой проблемы нет, ведь они у нас идут пачкой в одной операции/документе, и единой транзакцией.
Собственно поэтому я и говорю что все проводки одного документа лежат в одной транзакции, чтобы не было вот таких вот смущающих вас моментов «между».
А так то вообще задача у нас тут сугубо теоретическая ибо мне сложно понять что это за учет преферанса такой мы строим, а вы еще и регламентированный учет пришить хотите).
Что касается последовательности проводок, то тут особой проблемы нет, ведь они у нас идут пачкой в одной операции/документе, и единой транзакцией.
Собственно поэтому я и говорю что все проводки одного документа лежат в одной транзакции, чтобы не было вот таких вот смущающих вас моментов «между».
А так то вообще задача у нас тут сугубо теоретическая ибо мне сложно понять что это за учет преферанса такой мы строим, а вы еще и регламентированный учет пришить хотите).
Это, конечно, возможный вариант, но здесь вам пришлось сделать дополнительное допущение о принципе распределения долга. И выше правильно заметили, что участники могут и не придти к согласию об именно таком распределении долга. А если участников много, то замучаетесь распределять суммы и считать погрешности.
Обычно все же такое делают через доп. счет. Все проигравшие корреспондируют с ним с одной стороны, а выигравшие — с другой. Но там другое неудобство.
Я не уверен, что балансовые проводки нужны, — и лишь размышляю об этом.
Если в одной проводке допустить корреспонденцию нескольких счетов одновременно, то тогда при запросах о корреспонденции счетов следует, видимо, уточнять в какой стороне группировать счета — по дебету или кредиту.
Если, например, по дебету, то корреспонденция счетов в примере должна выглядеть примерно так:
В1 получил 50 руб. от П1 и П2
В2 получил 10 руб. от П1 и П2
А если по кредиту, то:
П1 отдал 40 руб. В1 и В2
П2 отдал 20 руб. В1 и В2
Тут нет никаких допущений о распределении сумм.
Обычно все же такое делают через доп. счет. Все проигравшие корреспондируют с ним с одной стороны, а выигравшие — с другой. Но там другое неудобство.
Я не уверен, что балансовые проводки нужны, — и лишь размышляю об этом.
Если в одной проводке допустить корреспонденцию нескольких счетов одновременно, то тогда при запросах о корреспонденции счетов следует, видимо, уточнять в какой стороне группировать счета — по дебету или кредиту.
Если, например, по дебету, то корреспонденция счетов в примере должна выглядеть примерно так:
В1 получил 50 руб. от П1 и П2
В2 получил 10 руб. от П1 и П2
А если по кредиту, то:
П1 отдал 40 руб. В1 и В2
П2 отдал 20 руб. В1 и В2
Тут нет никаких допущений о распределении сумм.
Вы хотите изобрести «лямбда-счета»?) Ведь по сути в множественной проводке есть некий общий счет этой проводки просто он не занимает адресное пространство на подобии лямбда-функций/классов.
У вас либо есть общий счет, тогда его можно указать явно, либо его нет, тогда есть логика распределения долгов (как вариант — та что я привел, пропорциональная). Третьего не дано.
Я сделал предположение о распределении долгов поскольку вы захотели узнать «кто кому», а значит логично что еще и «сколько».
А так то «операции» или у меня «документы» это как раз такие «метапроводки» которые имеют много входов-векторов и остаются балансовыми векторами.
При этом их обслуживание остается простым.
У вас либо есть общий счет, тогда его можно указать явно, либо его нет, тогда есть логика распределения долгов (как вариант — та что я привел, пропорциональная). Третьего не дано.
Я сделал предположение о распределении долгов поскольку вы захотели узнать «кто кому», а значит логично что еще и «сколько».
А так то «операции» или у меня «документы» это как раз такие «метапроводки» которые имеют много входов-векторов и остаются балансовыми векторами.
При этом их обслуживание остается простым.
Бухучёт и не ставит своей целью сохранение этой информации. Для этого ещё есть управленческий учёт.
Да ладно ). Нормальная цель хорошего учета. Просто обычно извращаются различными способами, пытаясь ответить на подобные вопросы..
Хм… я возможно не сказал это прямо, но я настаиваю, что в основе управленческого учета должен тоже лежать свой баланс и свой специфический «управленческий» план счетов. Конечно это все обвешивается кучей доп.полей, кучей субконто, разными ценами (баланс, закупка, продажа) и кучей всего, но в основе — та же двойная запись.
Можно. Но не нужно.
Двойную запись проще контролировать чем множественную. Проще заносить в базу (иначе выходит EAV, что плохо).
Вместе с тем если уж совсем строго то вектор у нас N-мерный, где N равно количеству счетов в нашем балансе (всех, как активных так и пассивных, а не только тех по которым мы делаем операцию). А вектор соответствующий проводке это такой вектор у которого все измерения равны нулю кроме двух, обозначенных в проводке.
При этом аналогом вашей «балансовой проводки» в моих терминах является "документ" с которым связаны одна или несколько проводок. Их сумма (у которой остальные измерения равны нулю) и будет таким множественным вектором.
Двойную запись проще контролировать чем множественную. Проще заносить в базу (иначе выходит EAV, что плохо).
Вместе с тем если уж совсем строго то вектор у нас N-мерный, где N равно количеству счетов в нашем балансе (всех, как активных так и пассивных, а не только тех по которым мы делаем операцию). А вектор соответствующий проводке это такой вектор у которого все измерения равны нулю кроме двух, обозначенных в проводке.
При этом аналогом вашей «балансовой проводки» в моих терминах является "документ" с которым связаны одна или несколько проводок. Их сумма (у которой остальные измерения равны нулю) и будет таким множественным вектором.
По поводу n-мерных векторов. Если задать матрицу расстояний между счетами, то оказывается, что проводка может быть описана двояким образом — контравариантным (обычным) и ковариантным (термины из тензорной алгебры). Обе проводки будут балансовыми и описывать один и тот же вектор, но когда у обычной проводки ненулевыми являются только две компоненты (двойная запись), то у аналогичной ей ковариантной звенят все компоненты.
Вот за что я люблю тензорную алгебру… а собственно ни за что не люблю))).
Но в качестве разминки для ума можно подумать об этом. Опишите плиз пример обеих записей применительно к счетам и проводкам, думаю многим будет интересно это увидеть.
Но в качестве разминки для ума можно подумать об этом. Опишите плиз пример обеих записей применительно к счетам и проводкам, думаю многим будет интересно это увидеть.
В ортонормированном базисе ковариантные координаты совпадают с контрвариантными :-)
Круто, что есть люди, которые об этом знают ). А можете догадаться, при каком условии бухгалтерские счета являются «ортонормированными»? То есть контравариантные проводки совпадают с ковариантными.
Зависит от того, какой смысл вкладывается в скалярное произведение двух счетов.
Лично я считаю, что смысла в таком произведении — нет, а потому для разных счетов там должен быть ноль, а для одинаковых — квадрат баланса. Значит, базис у нас ортонормированный.
Впрочем, если есть желание всех запутать — можно определить скалярное произведение как-нибудь по-другому. Только мне почему-то кажется, что бухгалтера такое не оценят.
Ну, если говорить конкретно про «ортонормированный базис», то все проще ).
В том плане, что тут можно пока и без скалярного произведения обойтись.
Бух. счета — это вершины графа (если определять систему координат через связи между вершинами), или вершины симплекса (если определять ее через расстояния между вершинами). Так вот, если все расстояния (или связи) между вершинами одинаковы, то такой набор вершин (счетов) и соответствует «ортонормированному базису». В котором контравариантные и ковариантные проводки совпадают ).
А скалярное произведение везде одинаково определяется — через билинейную форму произведения векторов на метрический тензор.
В том плане, что тут можно пока и без скалярного произведения обойтись.
Бух. счета — это вершины графа (если определять систему координат через связи между вершинами), или вершины симплекса (если определять ее через расстояния между вершинами). Так вот, если все расстояния (или связи) между вершинами одинаковы, то такой набор вершин (счетов) и соответствует «ортонормированному базису». В котором контравариантные и ковариантные проводки совпадают ).
А скалярное произведение везде одинаково определяется — через билинейную форму произведения векторов на метрический тензор.
Метрический тензор — это и есть скалярные произведения базисных векторов. Я о нем и говорил, только другими словами.
Да, конечно. Просто для набора бух. счетов сложно определить именно скалярные произведения между ними — никакой бух не ответит на такой вопрос ). А вот связи (или расстояния) между счетами — оценить можно. Поскольку логично предположить, что корреспондирующие счета расположены ближе друг к другу (связаны), чем некорреспондирующие.
Далее зная дистанционную матрицу (или матрицу смежности), можно построить метрический тензор. Даже два — ковариантный и контравариантный. Тогда скалярные произведения сами определятся.
Далее зная дистанционную матрицу (или матрицу смежности), можно построить метрический тензор. Даже два — ковариантный и контравариантный. Тогда скалярные произведения сами определятся.
Вот это обсужденице тут у вас!
Вопрос остались открытые? Или со всем разобрались?
С тем, что Активный и Пассивный счёт — это не то же самое, что счёт из Актива и из Пассива?
Что Актив — это то, чем компания владеет, а Пассив — источники этого владения? Вместо «владеет», видел, в обсуждении использовалось слово «распоряжается».
Что активно-пассивные счета иногда удобны, но в общем-то не практикуются в других бухгалтерских школах?
Вопрос остались открытые? Или со всем разобрались?
С тем, что Активный и Пассивный счёт — это не то же самое, что счёт из Актива и из Пассива?
Что Актив — это то, чем компания владеет, а Пассив — источники этого владения? Вместо «владеет», видел, в обсуждении использовалось слово «распоряжается».
Что активно-пассивные счета иногда удобны, но в общем-то не практикуются в других бухгалтерских школах?
с балансом понятно дебет=кредит, пассив=актив.
а как быть например с чистой прибылью. Мы ведь не продаем слонов по той же цене по какой купили.
а как быть например с чистой прибылью. Мы ведь не продаем слонов по той же цене по какой купили.
Mendel, один совет — посмотрите, как реализован модуль главной книги в любой из нормальных ERP систем (не 1С) — навик, аксапта, оебс, сап…
И подумайте, почему именно так.
То, как вы описываете проводки — не очень корректно и неудобно в реализации.
Достаточно часто надо делать проводки с тремя, четырьмя и более фин счетами.
Например, вы перебрасываете 1000 евро с еврового счета на долларовый и приходит 1100 долларов. Попробуйте записать это проводками, и поймете, почему удобны проводки с тремя и более фин счетами.
Ну и остальные ваши измышления, например записывать в каждой проводке текущее сальдо по счету :)))
Технически, вроде бы да, можно. Но — зачем? Вы про материализованные (индексированные) представления слышали?
Просто если человек, не разбирающийся в бух учете, начнет изучать тему по этой статье — ему будет сложно потом разбираться с реальными задачами в этой области.
И подумайте, почему именно так.
То, как вы описываете проводки — не очень корректно и неудобно в реализации.
Достаточно часто надо делать проводки с тремя, четырьмя и более фин счетами.
Например, вы перебрасываете 1000 евро с еврового счета на долларовый и приходит 1100 долларов. Попробуйте записать это проводками, и поймете, почему удобны проводки с тремя и более фин счетами.
Ну и остальные ваши измышления, например записывать в каждой проводке текущее сальдо по счету :)))
Технически, вроде бы да, можно. Но — зачем? Вы про материализованные (индексированные) представления слышали?
Просто если человек, не разбирающийся в бух учете, начнет изучать тему по этой статье — ему будет сложно потом разбираться с реальными задачами в этой области.
Материализованные вьюхи это синтаксический сахар у которого СУБД делает тоже самое что и я, но не зная бизнес-логики. Объясню почему я против вьювов вообще на низком уровне — дальше будет несколько уровней абстракции, сложные отчеты, и там тоже будет вьювы.
Синтаксически не проблема, но все равно все это разворачивается в обычные запросы, так что лучше уж сразу построить структуру без излишеств. Ну и конечно зависимость от сложных СУБД тоже существенный минус. Если говорить о моих задачах, то невозможность сделать все это в sqlite а то и на простых json-файлах — недостаток фатальный, ну да ладно, не мною единым, но все равно я сторонник минимальной логики в СУБД, а в основном держать ее в коде. Логика должна быть простой. Усложнить мы ее всегда успеем.
А в реальных условиях, да еще и в хайлоаде… Я понимаю что вы как и mayorovp sql-фанаты, но это плохой дизайн.
Далее — по поводу текущего сальдо в проводке: это был «олимпиадный» ответ на предложение вообще не иметь таблицу счетов, а каждый раз суммировать проводки. В реальности так можно, но сложно. В простейшем случая я за таблицу вида таймштамп-счет-значение (ну и ИД конечно, в качестве неявного времени использовать его а не таймштамп).
По сути это тот-же материализованный вьюв который вы толкаете. Только без тройного жоина эмулирующего юнион, и существующий в явном виде, а значит дающий больше гибкости в обслуживании и более прозрачный с точки зрения кода.
Что касается многосчетовых проводок… Я пока не увидел ни единого примера где они имели бы хоть какое-то химерное преимущество перед операцией/документом (т.е. пачкой нормальных проводок). Ваш пример с обменом валют мне не понятен, поскольку вы складываете теплое и мягкое, а любой баланс ведется в единой валюте. А тут у нас максимум комиссия появляется, ну или курсовые разницы можно, если курс использующийся для «балансовой стоимости» у нас слишком отличается от реального.
Раскройте свою мысль по обмену валют который вы описали.
ПС: и да, повторюсь еще раз — множественная проводка легко делается пачкой проводок. Максимум можно ввести специфическое поведение для некоторых счетов, чтобы они проверяли что входящее и исходящее сальдо по нему ПОСЛЕ ВСЕЙ ОПЕРАЦИИ/ДОКУМЕНТА всегда нулевое. Т.е. как я их назвал «лямбда-счета». В балансе такие можно не указывать ибо они всегда нулевые. Пример такого счета выше — игровой стол.
Синтаксически не проблема, но все равно все это разворачивается в обычные запросы, так что лучше уж сразу построить структуру без излишеств. Ну и конечно зависимость от сложных СУБД тоже существенный минус. Если говорить о моих задачах, то невозможность сделать все это в sqlite а то и на простых json-файлах — недостаток фатальный, ну да ладно, не мною единым, но все равно я сторонник минимальной логики в СУБД, а в основном держать ее в коде. Логика должна быть простой. Усложнить мы ее всегда успеем.
А в реальных условиях, да еще и в хайлоаде… Я понимаю что вы как и mayorovp sql-фанаты, но это плохой дизайн.
Далее — по поводу текущего сальдо в проводке: это был «олимпиадный» ответ на предложение вообще не иметь таблицу счетов, а каждый раз суммировать проводки. В реальности так можно, но сложно. В простейшем случая я за таблицу вида таймштамп-счет-значение (ну и ИД конечно, в качестве неявного времени использовать его а не таймштамп).
По сути это тот-же материализованный вьюв который вы толкаете. Только без тройного жоина эмулирующего юнион, и существующий в явном виде, а значит дающий больше гибкости в обслуживании и более прозрачный с точки зрения кода.
Что касается многосчетовых проводок… Я пока не увидел ни единого примера где они имели бы хоть какое-то химерное преимущество перед операцией/документом (т.е. пачкой нормальных проводок). Ваш пример с обменом валют мне не понятен, поскольку вы складываете теплое и мягкое, а любой баланс ведется в единой валюте. А тут у нас максимум комиссия появляется, ну или курсовые разницы можно, если курс использующийся для «балансовой стоимости» у нас слишком отличается от реального.
Раскройте свою мысль по обмену валют который вы описали.
ПС: и да, повторюсь еще раз — множественная проводка легко делается пачкой проводок. Максимум можно ввести специфическое поведение для некоторых счетов, чтобы они проверяли что входящее и исходящее сальдо по нему ПОСЛЕ ВСЕЙ ОПЕРАЦИИ/ДОКУМЕНТА всегда нулевое. Т.е. как я их назвал «лямбда-счета». В балансе такие можно не указывать ибо они всегда нулевые. Пример такого счета выше — игровой стол.
Плохой дизайн и усложнение логики…
Странно слышать от вас такие обвинения. :)))
Давайте я еще раз объясню, как именно хранится информация о фин проводках в нормальных ERP системах. Если отбросить все накопившиеся «какашки мамонтов», то в основной таблице фин проводок есть такие поля:
— номер записи — целое (автоинкремент)
— номер транзакции (проводки) — целое
— дата учета
— код набора аналитик — целое (фин счет — одна из аналитик, когда номер именно фин счета выделяют в отдельное поле, то это скорее унаследованный код, хотя для некоторых ситуаций и полезно)
— признак реверсивности (красное сторно) — булево
— сумма операции в функциональной валюте — decimal
Также есть два ограничения:
1. Дата учета должна быть одной и той же для всех записей с одинаковым номером транзакции (проводки).
2. Сумма поля «сумма операции в функциональной валюте» (на английском понятнее — там это sum and amount — разные слова))) всех записей с одним и тем же номером транзакции (проводки) должна быть равна нулю.
Номер записи обычно идет без пропусков, это облегчает аудит, но само по себе отсутствие пропусков не обязательно, как и само поле «номер записи» :))) Но с этим полем работать намного удобнее.
И это ВСЁ, что нужно собственно для учета. Заметьте, вообще нет никаких дебетов / кредитов, деления счетов на активные / пассивные или на балансовые счета / счета прибылей и убытков. Очень простая логика, которую легко реализовать.
Разумеется, в реальных системах обычно есть дополнительные поля:
— справочная информация (номер и дата документа, описание проводки и т.п.)
— техническая информация (из какого модуля «пришла» проводка а также ключи, помогающие связать между собой записи в главной книге и прочих модулях)
— поля, упрощающие ряд расчетов (денормализация). например, сумма дебита и сумма кредита — их можно вычислить по другим полям — при «признак реверсивности» = ложь если поле сумма больше нуля то дебет, если меньше нуля то кредит; при «признак реверсивности» = истина если поле сумма больше нуля то кредит, если меньше нуля то дебет, но для многих задач удобнее хранить в явном виде.
А теперь сравните с теми ограничениями, которые надо реализовать в вашем варианте дизайна. :)))
Например, подробнее разберем мой пример с переброской денег с еврового счета на долларовый (конвертация денег в другую валюту).
Предположим, что функциональная валюта у нас — евро. Для учета мы используем курсы центробанка, а банк для конвертации — спотовый курс. И эти курсы, как правило, разные.
Как я уже сказал, банк конвертировал 1000 евро в 1100 долларов. А курс центробанка для 1100 долларов — 1005 евро.
То есть итог на фин счетах должен выглядеть следующим образом:
— Банк счет (евро): -1000 (-1000 евро)
— Банк счет (доллар): +1005 (+1100 долларов)
— Реализованная прибыль от курсовых разниц: -5
Если мы допускаем в системе сложные проводки, то можем прямо в таком виде и записать проводку в главную книгу и успокоиться.
А вот если нам надо разбить операции «попарно» — все сильно усложняется.
Например, мы учитываем операцию следующим образом:
Проводка 1
— Банк счет (евро): -1000 (-1000 евро)
— Банк счет (доллар): +1000 (+1100 долларов)
Проводка 2
— Банк счет (доллар): +5 (+0 долларов)
— Реализованная прибыль от курсовых разниц: -5
Итоговый результат тот же самый, но у нас вылазит сразу ДВЕ проблемы.
Проблема 1.
Мы в первой проводке учитываем сумму в валюте (доллары) не по курсу на дату выполнения операции. Это, в свою очередь, приводит к целому букету проблем, начиная от того, что сложнее выполнять банальные проверки корректности пересчета сумм из валюты операции в функциональную валюту и заканчивая СУЩЕСТВЕННЫМ усложнением логики различных расчетов. Ведь мы не можем для расчета суммы в функциональной валюте везде вызывать одну простую процедуру, которая просто находит курс на дату учета операции и умножает сумму в валюте операции на этот курс.
Проблема 2.
Нарушаются базовые принципы фин учета. Фин проводки являются ОЧЕНЬ близкими аналогами ACID транзакций баз данных (собственно говоря, при начале разработки баз данных фин учет был одной из основных сфер применения). То есть, каждая фин проводка должна преобразовывать фин учет из одного корректного состояния в другое корректное состояние. А теперь представим, что по какой-то причине мы зафиксировали в базе только одну из этих проводок. В таком случае мы получим некорректные данные в отчетности. То есть нам надо вводить дополнительную группировку проводок в «транзакции», что в свою очередь усложняет систему.
И самое главное, что подобное деление на простые проводки не дает никакого реального выигрыша. Многие теоретики любят рассуждать о ценности отчетов на основе корреспонденции счетов, но на практике необходимость в этой информации возникает КРАЙНЕ редко.
Вернее не совсем так. Необходимость в данных о «корреспонденции» проводок возникает регулярно, но корреспонденция в том виде, в каком она обычно реализована, не дает нужной детализации. А реализовать её на нужном уровне весьма сложно. Например, у сапа есть очень полезная функциональность — Document Splitting, которая и делает нужные «связки» (об этой функциональности можно почитать здесь и, например, здесь). Но это, мягко говоря, «немножко сложнее» той корреспонденции, которая есть в той же 1С. :)
Странно слышать от вас такие обвинения. :)))
Давайте я еще раз объясню, как именно хранится информация о фин проводках в нормальных ERP системах. Если отбросить все накопившиеся «какашки мамонтов», то в основной таблице фин проводок есть такие поля:
— номер записи — целое (автоинкремент)
— номер транзакции (проводки) — целое
— дата учета
— код набора аналитик — целое (фин счет — одна из аналитик, когда номер именно фин счета выделяют в отдельное поле, то это скорее унаследованный код, хотя для некоторых ситуаций и полезно)
— признак реверсивности (красное сторно) — булево
— сумма операции в функциональной валюте — decimal
Также есть два ограничения:
1. Дата учета должна быть одной и той же для всех записей с одинаковым номером транзакции (проводки).
2. Сумма поля «сумма операции в функциональной валюте» (на английском понятнее — там это sum and amount — разные слова))) всех записей с одним и тем же номером транзакции (проводки) должна быть равна нулю.
Номер записи обычно идет без пропусков, это облегчает аудит, но само по себе отсутствие пропусков не обязательно, как и само поле «номер записи» :))) Но с этим полем работать намного удобнее.
И это ВСЁ, что нужно собственно для учета. Заметьте, вообще нет никаких дебетов / кредитов, деления счетов на активные / пассивные или на балансовые счета / счета прибылей и убытков. Очень простая логика, которую легко реализовать.
Разумеется, в реальных системах обычно есть дополнительные поля:
— справочная информация (номер и дата документа, описание проводки и т.п.)
— техническая информация (из какого модуля «пришла» проводка а также ключи, помогающие связать между собой записи в главной книге и прочих модулях)
— поля, упрощающие ряд расчетов (денормализация). например, сумма дебита и сумма кредита — их можно вычислить по другим полям — при «признак реверсивности» = ложь если поле сумма больше нуля то дебет, если меньше нуля то кредит; при «признак реверсивности» = истина если поле сумма больше нуля то кредит, если меньше нуля то дебет, но для многих задач удобнее хранить в явном виде.
А теперь сравните с теми ограничениями, которые надо реализовать в вашем варианте дизайна. :)))
Например, подробнее разберем мой пример с переброской денег с еврового счета на долларовый (конвертация денег в другую валюту).
Предположим, что функциональная валюта у нас — евро. Для учета мы используем курсы центробанка, а банк для конвертации — спотовый курс. И эти курсы, как правило, разные.
Как я уже сказал, банк конвертировал 1000 евро в 1100 долларов. А курс центробанка для 1100 долларов — 1005 евро.
То есть итог на фин счетах должен выглядеть следующим образом:
— Банк счет (евро): -1000 (-1000 евро)
— Банк счет (доллар): +1005 (+1100 долларов)
— Реализованная прибыль от курсовых разниц: -5
Если мы допускаем в системе сложные проводки, то можем прямо в таком виде и записать проводку в главную книгу и успокоиться.
А вот если нам надо разбить операции «попарно» — все сильно усложняется.
Например, мы учитываем операцию следующим образом:
Проводка 1
— Банк счет (евро): -1000 (-1000 евро)
— Банк счет (доллар): +1000 (+1100 долларов)
Проводка 2
— Банк счет (доллар): +5 (+0 долларов)
— Реализованная прибыль от курсовых разниц: -5
Итоговый результат тот же самый, но у нас вылазит сразу ДВЕ проблемы.
Проблема 1.
Мы в первой проводке учитываем сумму в валюте (доллары) не по курсу на дату выполнения операции. Это, в свою очередь, приводит к целому букету проблем, начиная от того, что сложнее выполнять банальные проверки корректности пересчета сумм из валюты операции в функциональную валюту и заканчивая СУЩЕСТВЕННЫМ усложнением логики различных расчетов. Ведь мы не можем для расчета суммы в функциональной валюте везде вызывать одну простую процедуру, которая просто находит курс на дату учета операции и умножает сумму в валюте операции на этот курс.
Проблема 2.
Нарушаются базовые принципы фин учета. Фин проводки являются ОЧЕНЬ близкими аналогами ACID транзакций баз данных (собственно говоря, при начале разработки баз данных фин учет был одной из основных сфер применения). То есть, каждая фин проводка должна преобразовывать фин учет из одного корректного состояния в другое корректное состояние. А теперь представим, что по какой-то причине мы зафиксировали в базе только одну из этих проводок. В таком случае мы получим некорректные данные в отчетности. То есть нам надо вводить дополнительную группировку проводок в «транзакции», что в свою очередь усложняет систему.
И самое главное, что подобное деление на простые проводки не дает никакого реального выигрыша. Многие теоретики любят рассуждать о ценности отчетов на основе корреспонденции счетов, но на практике необходимость в этой информации возникает КРАЙНЕ редко.
Вернее не совсем так. Необходимость в данных о «корреспонденции» проводок возникает регулярно, но корреспонденция в том виде, в каком она обычно реализована, не дает нужной детализации. А реализовать её на нужном уровне весьма сложно. Например, у сапа есть очень полезная функциональность — Document Splitting, которая и делает нужные «связки» (об этой функциональности можно почитать здесь и, например, здесь). Но это, мягко говоря, «немножко сложнее» той корреспонденции, которая есть в той же 1С. :)
Плохой дизайн и усложнение логики…
Странно слышать от вас такие обвинения. :)))
Ой! Я кажется обидел целого архитектора, простите великодушно.
Давайте я еще раз объясню, как именно хранится информация о фин проводках в нормальных ERP системах.
А зачем объяснять? Если у нас не фиксированное количество корр.счетов в операции то у вас только один вариант — EAV.
Заметьте, вообще нет никаких дебетов / кредитов, деления счетов на активные / пассивные или на балансовые счета / счета прибылей и убытков. Очень простая логика, которую легко реализовать.
Заметил, да. Теперь по пунктам.
У вас нет дебета и кредита, а значит нет дебетового и кредитового оборота. Соответственно тут три варианта — либо вы теряете огромный пласт аналитики, либо вы его теряете здесь а потом городите множественные надстройки чтобы потом вытащить ту же информацию, либо, что более верооятно — дебет и кредит у вас есть, это отрицательные и положительные суммы у ваших кусочков проводок (знак и определяет дебет или кредит) и потом в аналитике вы используете этот факт, но не называете это общепринятыми названиями. Не прописывать сущности явно, и тем более не называть их — один из признаков архитектуры с душком. Но суть не в этом — главное что они у вас есть. Деление счетов на активные и пассивные это более высокий уровень абстракции. Возьмите в нормальном учете с двойной записью все счета и сделайте их активно-пассивными, и будет учет без разделения. Если на счете плюс, значит он активный и выводим в активных, если минус то пассивный и выводим в пассивных.
Разделение на активные и пассивные это уже часть логики а не структуры. Это определенный механизм валидации, это дополнительный признак для агрегации и для анализа и т.п. А чисто физически, на уровне абстракции «проводка» их как таковых и нет. Так что с активными и пассивными счетами ровно тот же случай — либо они у вас есть, но вы их так не называете, и они выглядят таким образом на более высоком уровне абстракции, либо их у вас нет, и вы теряете большой пласт аналитики и функционала.
Балансовые и забалансовые я трогать не буду, это артефакт книжного учета, я сам тут против них высказывался.
А теперь сравните с теми ограничениями, которые надо реализовать в вашем варианте дизайна. :)))
Сравнил. У меня ровно в два раза меньше, причем все явно, нет размазанной логики.
Предположим, что функциональная валюта у нас — евро. Для учета мы используем курсы центробанка, а банк для конвертации — спотовый курс. И эти курсы, как правило, разные.
Как я уже сказал, банк конвертировал 1000 евро в 1100 долларов. А курс центробанка для 1100 долларов — 1005 евро.
Спасибо за ваш пример. Вы убедили меня в том, что идея с «лямбда-счетами» была глупая, и я зря повелся на идеи вашего коллеги из партии сложных проводок. Все счета должны быть явными. А значит у нас получается так:
В вашем варианте учета у нас три записи в базе:
— Банк счет (евро): -1000 (-1000 евро)
— Банк счет (доллар): +1005 (+1100 долларов)
— Реализованная прибыль от курсовых разниц: -5
эдакие три «кварковые» проводки в которых есть только один счет и сумма, но опущен второй счет.
Теперь тоже самое в нормальном учете:
Три проводки:
Дт: Транзитный-счет-обмен-валют, Кт: Банк-счет-евро, 1000евро
Дт: Транзитный-счет-обмен-валют, Кт: Прибыль-курсовые-разницы, 5евро
Дт: Банк-счет-доллар, Кт: Транзитный-счет-обмен-валют, 1005евро
Да, у нашего транзитника сальдо будет всегда нулевое, но мы сразу имеем возможность считать по нему дебетовый (ну или кредитовый, тут одинаково) оборот за период, и видеть суммы которые мы меняли. Без сложных манипуляций, без лишней информации в других документах и т.п. Всё из баланса. (У вас нельзя, ибо оба банковских счета дебетуются и кредитуются не только обменными операциями, но и торговыми и т.п.).
Колво записей тоже одинаково. Колво информации в записях по факту выйдет меньше ибо таким образом мы потом сильно экономим как раз на дополнительных полях и всяких лишних связях, лишних таблицах и т.п.
Мы в первой проводке учитываем сумму в валюте (доллары) не по курсу на дату выполнения операции.
Ничего не понял. Не по какому курсу? Учитесь формулировать мысли однозначно, вы же «архитектор» :) Соответственно и весь дальнейший тред про курсы не понятен. Думаю что вы тут притянули какой-то неверный вариант учета, но объяснитесь, может и вправду будет интересный вопрос.
Нарушаются базовые принципы фин учета. Фин проводки являются ОЧЕНЬ близкими аналогами ACID транзакций баз данных (собственно говоря, при начале разработки баз данных фин учет был одной из основных сфер применения). То есть, каждая фин проводка должна преобразовывать фин учет из одного корректного состояния в другое корректное состояние. А теперь представим, что по какой-то причине мы зафиксировали в базе только одну из этих проводок. В таком случае мы получим некорректные данные в отчетности. То есть нам надо вводить дополнительную группировку проводок в «транзакции», что в свою очередь усложняет систему.
Чушь. Представьте себе что вы каким-то образом сохранили только одну вашу «кварковую» проводку (часть проводки где один счет). Представили? Нет? А зачем мне тогда представлять в моей системе то, что вы не хотите представлять в вашей?
См. статью — все проводки одного документа должны проводиться в одной транзакции.
Да, я по итогу споров в комментариях склоняюсь к тому чтобы назвать «документ» словом операция, так будет проще, но суть не меняется. Проводка атомарна по своей сути, она представляет из себя одну запись, ее не раздробить. А операция атомарна средствами СУБД.
И самое главное, что подобное деление на простые проводки не дает никакого реального выигрыша. Многие теоретики любят рассуждать о ценности отчетов на основе корреспонденции счетов, но на практике необходимость в этой информации возникает КРАЙНЕ редко.
Вернее не совсем так. Необходимость в данных о «корреспонденции» проводок возникает регулярно, но корреспонденция в том виде, в каком она обычно реализована, не дает нужной детализации. А реализовать её на нужном уровне весьма сложно.
Вот это уже ближе к теме. Действительно, крайне мало людей способны грамотно продумать архитектуру, в том числе и правильно построить корреспонденцию. Поэтому регулярно городят лишние надстройки, без которых можно обойтись если хорошо понимать суть процессов, но проще ведь велосипед изобрести.
Ну и да, классическая структура баланса подразумевает что у нас только одна, заранее зафиксированная иерархия счетов, одна валюта и т.п. Вместе с тем компьютерная реализация дает много большую гибкость. Собственно ее то я и хочу реализовать. Отчасти ради этих обсуждений и затевалась статья).
АПД: Забыл написать. Ваш вариант из двух двойных проводок отражает типичную ошибку. Попытку неоправданно уменьшить количество сущностей любой ценой. Чисто интуитивно кажется что чем меньше информации мы можем использовать для одного и того же факта, тем лучше, но важнее не выкинуть часть информации. Собственно двойная запись это исключительно про то, что записывать нужно все, а не только то что кажется важным (это не значит что нужна максимальная детализация, агрегацию никто не отменял).
«Кварковые» проводки — крутой термин, надо будет запомнить. :)))
По поводу создания отдельного «транзитного» фин счета, сальдо по которому всегда равно нулю (просто для того, чтобы смотреть, какие суммы меняли)… Спорить не буду — если очень хочется создавать кучу транзитных счетов с сомнительными целями, то почему бы и нет? :)))
Про велосипеды очень хорошо сказано. Я именно поэтому и советую посмотреть, как это всё уже реализовано. И сап для новой главной книги, и микрософт для 2013 навика реализовали фактически одну и ту же модель хранения данных об аналитических разрезах фин проводок. Поэтому высока вероятность, что именно такая модель близка к оптимальной (у оебса эта же модель была изначально, и, подозреваю, именно с оебса идею и скопировали).
Почитайте о том, как это в навике сделали и почему именно так сделали. А потом начинайте изобретать свои велосипеды.
По поводу создания отдельного «транзитного» фин счета, сальдо по которому всегда равно нулю (просто для того, чтобы смотреть, какие суммы меняли)… Спорить не буду — если очень хочется создавать кучу транзитных счетов с сомнительными целями, то почему бы и нет? :)))
Действительно, крайне мало людей способны грамотно продумать архитектуру, в том числе и правильно построить корреспонденцию. Поэтому регулярно городят лишние надстройки, без которых можно обойтись если хорошо понимать суть процессов, но проще ведь велосипед изобрести.
Ну и да, классическая структура баланса подразумевает что у нас только одна, заранее зафиксированная иерархия счетов, одна валюта и т.п. Вместе с тем компьютерная реализация дает много большую гибкость. Собственно ее то я и хочу реализовать. Отчасти ради этих обсуждений и затевалась статья).
Про велосипеды очень хорошо сказано. Я именно поэтому и советую посмотреть, как это всё уже реализовано. И сап для новой главной книги, и микрософт для 2013 навика реализовали фактически одну и ту же модель хранения данных об аналитических разрезах фин проводок. Поэтому высока вероятность, что именно такая модель близка к оптимальной (у оебса эта же модель была изначально, и, подозреваю, именно с оебса идею и скопировали).
Почитайте о том, как это в навике сделали и почему именно так сделали. А потом начинайте изобретать свои велосипеды.
Чушь. Представьте себе что вы каким-то образом сохранили только одну вашу «кварковую» проводку (часть проводки где один счет). Представили? Нет? А зачем мне тогда представлять в моей системе то, что вы не хотите представлять в вашей?
См. статью — все проводки одного документа должны проводиться в одной транзакции.
Потому что в среде финансистов / разработчиков учетного софта минимальной (атомарной) операцией принято считать как раз проводку. Именно проводка обязательно должна учитываться в одной транзакции, а не «все проводки одного документа должны проводиться в одной транзакции». Это — вопрос знания профессиональной терминологии.
Кстати, в большинстве систем проводки одного документа мало того, что учитываются не в одной транзакции, так они еще могут учитываться разными датами :))) Типичный пример — себестоимость продаж по инвойсу.
В том то и дело, что «ядро» фин учета должно корректно работать с самыми разными документами, которые генерируются в разных модулях, написанных разными программистами. Ну и, например, есть еще проводки, учитываемые из журналов.
То, что вы собираетесь вводить дополнительное понятие «операция» (транзакция), которая объединяет в себе несколько проводок, которые должны учитываться одновременно и представляют из себя одно целое — как раз и показывает, что проводка, состоящая только из одного дебета и одного кредита — неудобна.
Намного проще сразу сказать, что проводка = транзакция, которая состоит из некоторого множества строк главной книги, которые всегда учитываются как одно целое (в одной транзакции БД). И не надо придумывать дополнительных сущностей.
Это — вопрос знания профессиональной терминологии.
Проводка это двойная запись. Терминологию надо знать, да. Про терминологию я тут уже отвечал.
А то что вы сторонник неакадемической терминологии, то это не плохо и не хорошо, просто не стоит обвинять тех кто придерживается терминологии которой пользуются большинство в незнании терминологии.
Намного проще сразу сказать, что проводка = транзакция, которая состоит из некоторого множества строк главной книги, которые всегда учитываются как одно целое (в одной транзакции БД). И не надо придумывать дополнительных сущностей.
Придумывать сущности никому не нужно. Есть проводка. Всё. Она придумана не вчера, и нет никаких причин ее урезать. Есть только одна причина урезать проводку до одного счета, и обзывать пачку проводок словом проводка — неумение строить корреспонденцию правильно.
Почему это я сторонник неакадемической терминологии? Например, академический термин «кварковые проводки» мне очень нравится… :)))
Я рад, что вы умеете строить корреспонденции счетов. Когда реализуете свой блок фин учёта с аналитическими измерениями и корреспонденцией, напишите ещё одну статью. Всем будет интересно. :)))
Я рад, что вы умеете строить корреспонденции счетов. Когда реализуете свой блок фин учёта с аналитическими измерениями и корреспонденцией, напишите ещё одну статью. Всем будет интересно. :)))
Есть только одна причина урезать проводку до одного счета, и обзывать пачку проводок словом проводка — неумение строить корреспонденцию правильно.Что значит «правильно»? Весь мир шагает не в ногу, одна Россия в ногу?
По историческим причинам в России (начиная с 1С, но не только) принято считать что проводка должна затрагивать ровно два счёта. Но если вы почитаете то же понятие на других языках, то обнаружите, что там требуются как минимум два счёта, а не ровно два.
И действительно — если я купил билет в подземку за 5 евро, то с какого фига у меня будет две транзакции, та ещё и такие, в которых ни в одном месте 5 евро не будут упомянуты?
Причина для этого ровно одна: так было удобнее работать «на бумаге», без компьютеров, а когда компьютеры появились — никто не задумался над тем, что этот атавизм, в общем, можно и отбросить.
KISS. Проще на бумаге значит проще в принципе.
Двойная запись это по сути третий закон Ньютона в мире финансов.
Ну давайте перефразируем третий закон под множество сил и их векторную сумму. Будет правильно, но запутанно. Для множественных ФИНАНСОВЫХ ТРАНЗАКЦИЙ есть «операция».
Весь спор, если отбросить терминологическую составляющую — ведется о том сколько счетов делать у минимальной операции — я говорю два, вы говорите — один.
При этом любую операцию можно деградировать до «множественной проводки» как минимум введя транзитный счет. При этом мы получим ту же функцию что и у «множественной проводки», только с дополнительной аналитикой вокруг нашего транзитника.
Аналогично с активно-пассивным счетом. Два счета — активный и пассивный с автоматическим перебросом прекрасно выполняют его функцию.
При этом раздельные активные и пассивные счета дают возможность бесшовной замены логики, а заменить один активно-пассивный счет на два сложнее. Аналогично операции из проводок проще переделывать, без переделки учета по другим счетам (задним числом это не всегда просто).
плюс возможностей больше. Ошибок меньше.
Двойная запись это по сути третий закон Ньютона в мире финансов.
Ну давайте перефразируем третий закон под множество сил и их векторную сумму. Будет правильно, но запутанно. Для множественных ФИНАНСОВЫХ ТРАНЗАКЦИЙ есть «операция».
Весь спор, если отбросить терминологическую составляющую — ведется о том сколько счетов делать у минимальной операции — я говорю два, вы говорите — один.
При этом любую операцию можно деградировать до «множественной проводки» как минимум введя транзитный счет. При этом мы получим ту же функцию что и у «множественной проводки», только с дополнительной аналитикой вокруг нашего транзитника.
Аналогично с активно-пассивным счетом. Два счета — активный и пассивный с автоматическим перебросом прекрасно выполняют его функцию.
При этом раздельные активные и пассивные счета дают возможность бесшовной замены логики, а заменить один активно-пассивный счет на два сложнее. Аналогично операции из проводок проще переделывать, без переделки учета по другим счетам (задним числом это не всегда просто).
плюс возможностей больше. Ошибок меньше.
Весь спор, если отбросить терминологическую составляющую — ведется о том сколько счетов делать у минимальной операции — я говорю два, вы говорите — один.Такого спора — нет. Есть спор о том могут ли больше, чем два счёта участвовать.
В 1С (и вообще в России) принято дробить операции так, чтобы счетов было ровно два. За границей (и даже в ERP в России) — принято проводить операции «как они есть».
KISS. Проще на бумаге значит проще в принципе.Совершенно необязательно. Компьютер производить миллиарды сложений/умножений в секунду, человек — хорошо если одно. Соотвественно заставить компиьютер выполнять лишний миллион-другой операций ради того, чтобы человек сделал на одно сложение меньше — хорошее дело никак не противоречащее KISS.
Такого спора — нет. Есть спор о том могут ли больше, чем два счёта участвовать.
У меня есть операции. В них может любое количество счетов участвовать.
При этом двойная проводка это одна запись в базу, множественная — столько записей сколько счетов участвует.
У меня все проводки в операции идут одной транзакцией, у вас все записи составляющие проводку («кварковые» проводки) идут в одной транзакции.
Если не нужно, или лень выстраивать корреспонденцию по какой-то операции тонко, то можно грубо добавить транзитный счет, и получить ровно тот функционал что у множественной проводки.
Итого различий три:
1) множественная проводка лишает дополнительной гибкости. Для меня это важно. Это и транзитники, дающие простую дополнительную аналитику вообще без лишнего кода, и дополнительный контроль целостности (да хоть бы и теми же транзитниками, и да, это как выше сказали «один потерял, другой поломал», да, транзакция атомарна и все такое, но оно так ровно до тех пор пока не услышишь в трубке «ААААА, Мендель, у меня тут винт накрылся, полбазы нет, бекапы старые, но есть большая часть журналов синхронизации за этот период, спасай!»). Вам не надо, ну да Бог с вами. Допустим это не существенное различие, раз оно вам не надо.
2) В двойной проводке появляются транзитники, которые «замусоривают» адресное пространство плана счетов (при условии что вам они не нужны). Данное различие абсолютно незначительно, ибо если уж сильно хочется избавиться от дополнительной аналитики — сделайте один транзитник для любых операций. Т.е. совсем один на всю систему учета. Бонусом получите дополнительный контроль целостности — как только он ненулевой, так значит целостность нарушена.
3) Третье различие как раз терминологическое. Называть проводкой единичную запись в базу (у вас она без названия, я в вашем случае называю ее «кварковой проводкой», т.е. субатомной, у меня это проводка), или совокупность таких проводок (кварковых проводок), или совокупность называть операцией. Вот и вся терминология.
Совершенно необязательно. Компьютер производить миллиарды сложений/умножений в секунду, человек — хорошо если одно. Соотвественно заставить компиьютер выполнять лишний миллион-другой операций ради того, чтобы человек сделал на одно сложение меньше — хорошее дело никак не противоречащее KISS.
Вычислительная сложность вообще побоку.
Важна лишь сложность анализа структуры, проектирования, анализа данных, сложность создания дополнительных запросов информации (которая определяет может ли это сделать сам пользователь или ему придется звать программиста) и т.п.
О! Очередная статья про двойную бухгалтерию. Как раз то, что надо. Может, вы мне, наконец, объясните, что такое это ваша двойная запись. Конкретнее, вопрос у меня такой: в двойной записи сумма активов равна сумме пассивов. Но достигается это равенство за счёт такого простого хака: за счёт того, что мы подбираем одну из строчек пассива под названием «нераспределённая прибыль» таким образом, чтобы сумма активов была равна сумме пассивов. Вот и всё. Ну а раз так, то какой тогда в этом смысл?
Может быть смысл был лишь в те времена, когда расчёты велись на бумаге, и это помогало не ошибиться?
И скажите, вся эта двойная запись нужна лишь в ситуации, когда бизнес существует как бы отдельно от учредителей, т. е. когда понятие «долг бизнеса учредителю» имеет смысл? Или в ситуации учёта личных финансов тоже имеет смысл?
Вот смотрите: давайте-ка я немного изменю вашу систему. Во-первых, строчку «нераспределённая прибыль» я выкину. Это просто хак такой, чтобы сумма активов была равна сумме пассивов. Я его уберу. Что касается строчки «долг учредителю», то я напомню, что он нужен лишь в ситуации с бизнесом, в обычной же житейской ситуации типа учёта личных финансов он не нужен. Поэтому его я тоже уберу, мне, обывателю, так понятнее, допустим, я веду учёт личных финансов. Так вот, остальные пассивы переношу с графу «активы», взяв со знаком минус. Получаю просто одну графу. Только активы. Всё. И при внесении изменений просто вношу любые изменения, ни о каких балансах не забочусь. Понятное дело, соблюдая здравый смысл. А здравый смысл заключается вот в чём: сумму всех активов можно изменять, но лишь в ситуациях, когда это действительно исходит из логики ситуации. То есть украли слонов — окей, убираем их из активов. И больше ничего не меняем. Потому что кража — это ситуация, при которой активы действительно уменьшаются. Нашли сто рублей на улице — опять-таки, заносим в активы и ничего больше не меняем. А вот если мы купили слонов, ясное дело, нужно деньги из активов убрать, а самих слонов добавить.
А теперь вопрос: чем ваша система лучше моей, изменённой? Мне кажется, ничем. Ваша система отличается от моей лишь наличием магической строчки «нераспределённая прибыль», в которую заносится всё, что по-другому учесть не получается.
И сразу скажу: статью я уже прочитал. Я всё понял. Да, я понял, что при двойной записи вероятность ошибок уменьшается. Но уменьшается лишь при условии, что все расчёты ведутся на бумажке, столбиком. А если у вас некая компьютерная система, и там сама система гарантирует сразу сходимость баланса, то чем в такой ситуации ваша система лучше моей? Да ничем. Они вообще ничем не отличаются. Просто в вашей системе есть ещё строчка-хак «нераспределённая прибыль», а в остальном нет разницы вообще никакой.
— habrahabr.ru/post/336656/#comment_10391116
После прочтения этого абзаца у меня закралось сильное подозрение, что, возможно, в нём-то как раз и содержатся ответы на все мои вопросы, а заодно и ответы на вопросы многих комментаторов. Надо только подробнее расписать и наступит счастье. Итак, Mendel, спрашиваю в лоб: распишите, пожалуйста, максимально подробно ситуацию описанную в этом абзаце, можно даже в виде отдельной статьи. Вот этот ваш «реальный случай». Итак, во-первых, как такое возможно, что существует некая компьютерная система, которая (пускай даже лишь в одном проценте случаев) допускает, что в неё возможно изначально внести информацию так, что баланс (сразу после внесения этой информации) будет не сходится? Ну как в вашем примере, что-то внесли, сходится перестало, начали разбираться и т. д. Вот разберите пожалуйста максимально подробно, как такое может произойти, что баланс не сойдётся, и как потом эта самая магическая двойная бухгалтерия поможет решить все проблемы.
И вообще, я так и не понял: так как всё-таки обычно устроена работа с компьютерной бухгалтерской системой? В неё вносят инфу и сразу при внесении система гарантирует, что баланс сходится? Если так, то почему тогда бухгалтера раз в месяц чего-то там пытаются свести?
Может быть смысл был лишь в те времена, когда расчёты велись на бумаге, и это помогало не ошибиться?
И скажите, вся эта двойная запись нужна лишь в ситуации, когда бизнес существует как бы отдельно от учредителей, т. е. когда понятие «долг бизнеса учредителю» имеет смысл? Или в ситуации учёта личных финансов тоже имеет смысл?
Вот смотрите: давайте-ка я немного изменю вашу систему. Во-первых, строчку «нераспределённая прибыль» я выкину. Это просто хак такой, чтобы сумма активов была равна сумме пассивов. Я его уберу. Что касается строчки «долг учредителю», то я напомню, что он нужен лишь в ситуации с бизнесом, в обычной же житейской ситуации типа учёта личных финансов он не нужен. Поэтому его я тоже уберу, мне, обывателю, так понятнее, допустим, я веду учёт личных финансов. Так вот, остальные пассивы переношу с графу «активы», взяв со знаком минус. Получаю просто одну графу. Только активы. Всё. И при внесении изменений просто вношу любые изменения, ни о каких балансах не забочусь. Понятное дело, соблюдая здравый смысл. А здравый смысл заключается вот в чём: сумму всех активов можно изменять, но лишь в ситуациях, когда это действительно исходит из логики ситуации. То есть украли слонов — окей, убираем их из активов. И больше ничего не меняем. Потому что кража — это ситуация, при которой активы действительно уменьшаются. Нашли сто рублей на улице — опять-таки, заносим в активы и ничего больше не меняем. А вот если мы купили слонов, ясное дело, нужно деньги из активов убрать, а самих слонов добавить.
А теперь вопрос: чем ваша система лучше моей, изменённой? Мне кажется, ничем. Ваша система отличается от моей лишь наличием магической строчки «нераспределённая прибыль», в которую заносится всё, что по-другому учесть не получается.
И сразу скажу: статью я уже прочитал. Я всё понял. Да, я понял, что при двойной записи вероятность ошибок уменьшается. Но уменьшается лишь при условии, что все расчёты ведутся на бумажке, столбиком. А если у вас некая компьютерная система, и там сама система гарантирует сразу сходимость баланса, то чем в такой ситуации ваша система лучше моей? Да ничем. Они вообще ничем не отличаются. Просто в вашей системе есть ещё строчка-хак «нераспределённая прибыль», а в остальном нет разницы вообще никакой.
На самом деле 99% возможных ошибок будут обнаружены прямо в момент их совершения. Вы просто не сможете записать неправильно. Получите сообщение об ошибке или еще как, но вам не нужно будет выискивать в чем именно ошибка поскольку как правильно заметил mayorovp на момент внесения данных в систему учета у вас перед глазами будет само событие которое вы описываете. Проданный товар, купленные запчасти, зарплатная ведомость или счет на оплату налогов. Не суть, но само событие предметной области будет на виду, а значит угадывать какой ответ правильный будет не нужно.
Однако даже если ошибка пройдет дальше, то ее будет проще локализовать и исправить поскольку у нас будет несколько фактических показателей которые не сходятся. Например у нас на складе излишки сигарет с ментолом и нехватка денег в кассе. Значит мы можем предположить что мы забыли оформить какую-то закупку сигарет. Начинаем поднимать закупки. Документы, поставщиков, все операции связанные с ментоловыми сигаретами и оказывается что мы ошиблись, с ментоловыми сигаретами все в порядке, а потерялась накладная на вишневые сигареты. Просто товаровед посчитала что в кассовой зоне пересортица и перебросила часть ментоловых сигарет на счет вишневых поскольку вишневых по факту продавалось больше чем было в базе. (Реальный случай).
— habrahabr.ru/post/336656/#comment_10391116
После прочтения этого абзаца у меня закралось сильное подозрение, что, возможно, в нём-то как раз и содержатся ответы на все мои вопросы, а заодно и ответы на вопросы многих комментаторов. Надо только подробнее расписать и наступит счастье. Итак, Mendel, спрашиваю в лоб: распишите, пожалуйста, максимально подробно ситуацию описанную в этом абзаце, можно даже в виде отдельной статьи. Вот этот ваш «реальный случай». Итак, во-первых, как такое возможно, что существует некая компьютерная система, которая (пускай даже лишь в одном проценте случаев) допускает, что в неё возможно изначально внести информацию так, что баланс (сразу после внесения этой информации) будет не сходится? Ну как в вашем примере, что-то внесли, сходится перестало, начали разбираться и т. д. Вот разберите пожалуйста максимально подробно, как такое может произойти, что баланс не сойдётся, и как потом эта самая магическая двойная бухгалтерия поможет решить все проблемы.
И вообще, я так и не понял: так как всё-таки обычно устроена работа с компьютерной бухгалтерской системой? В неё вносят инфу и сразу при внесении система гарантирует, что баланс сходится? Если так, то почему тогда бухгалтера раз в месяц чего-то там пытаются свести?
И скажите, вся эта двойная запись нужна лишь в ситуации, когда бизнес существует как бы отдельно от учредителей, т. е. когда понятие «долг бизнеса учредителю» имеет смысл? Или в ситуации учёта личных финансов тоже имеет смысл?Она нужна всегда, когда у вас есть разные «виды» денег.
То есть если вы живёте в пещере, налогов у вас нет, с ОпСоСами и ISP не общаетесь, за коммуналку и детский сад не платите, поездки на море не планируете — то, скорее всего, все эти премудрости вам и не нужны. Но тогда не очень понятно что вы делаете на Хабре.
Если же вы нормальный человек, покупаете проездной не на одну поездку, а, скажем, на 20, планируете ремонт и платите налоги — то у вас автоматически возникают разнообразные «активы» и пассивы. И сложить их в одну кучу вы никак не сможете — если у вас куча денег на счету сотового телефона, но за Internet вы не заплатили — то его отключат. А электричество, может, сходу и не отключат — но вам начислят штраф.
Просто в вашей системе есть ещё строчка-хак «нераспределённая прибыль», а в остальном нет разницы вообще никакой.Строчка-хак??? Это, условно говоря, деньги лежащие у вас в кошельке. Если вам неважно сколько у вас там денег — то отдайте их мне и не будет у вас проблем с бухгалтерией. Никаких. Ибо вы будете заняты другими проблемами…
В неё вносят инфу и сразу при внесении система гарантирует, что баланс сходится?Система гарантирует то, что она, собственно, может гарантировать: что пассивы и активы совпадают. Остальное — дело бухгалтера.
Если так, то почему тогда бухгалтера раз в месяц чего-то там пытаются свести?Бухгалтерия показывает некоторое «видение мира»: сколько денег должны вы, сколько денег должны вам. Причём в современном мире таких, проверяемых «снаружи» счетов даже у частного лица могут быть десятки (даже если вы с банками не связываетесь и кредиты не берёте). А дальше — вы смотрите в выписку со счёта и выясняется, что согласно бухгалтерии — у МГТСа на вашем счету должно быть денег вагон, а вам звонят и говорят, что вас завтра отключат за неуплату. Вы поднимаете документы, выясняете, что два раза провели один и тот же платёж, один раз — как оплату сотовой связи, второй — как наземной. Исправляете — но после исправления оказывается что в один из дней у вас в кассе остались деньги сверх лимита и вам нужно что-то с этим срочно делать (если реально нарушения не было — то нужно найти-таки вторую платёжку и понять куда, если не на оплату наземной связи, ушли деньги). И так далее.
В случае с частным лицом всё, конечно, проще (за то, что вы будете под матрасом хранить миллион вам никто штраф не выпишет), но прицип тот же.
Mendel, khim, я веду личную бухгалтерию. При помощи самописной программы. Если говорить совсем упрощённо, там у меня нет пассивов, есть только активы (нал, счёт в сбербанке и т. д.). Причём активы могут иметь и отрицательную стоимость, долг кому-то — это актив с отрицательной стоимостью. Сумма активов у меня не равна нулю, она может увеличиваться и уменьшаться, никаких магических строчек "нераспределённая прибыль" и "долг учредителю" у меня нет. У меня есть проводки, они, упрощённо говоря, бывают двух видов: те, которые не меняют сумму активов (скажем, перенос денег из налички на сбербанк, и это делается одной проводкой в моей системе), и те, что меняют (украли у меня что-то, я нашёл на улице 100 рублей, ну или мне выплатили зарплату, ну или потратил на что-то). Когда я даю кому-то денег в долг, это не меняет сумму активов, я одновременно уменьшаю наличку и добавляю актив под названием "долг кому-то". Аналогично с ситуацией, когда мне возвращают долг, когда я беру денег в долг и т. д. (опять-таки, это совершается одной проводкой).
В моей системе лежит список всех проводок (а также инфу о том, сколько денег было в некоторый фиксированный начальный момент в прошлом). Все проводки указаны со временем совершения, а также со словесным описанием. На основании этой инфы система может мне говорить, сколько у меня было активов (и каких) в любой момент времени в прошлом (а также сегодня), а также сколько я потратил и заработал за любой промежуток времени, и на что именно. Меня всё устраивает, никакой другой функциональности мне больше не надо.
В системе используются следующие принципы:
- Все операции, которые (исходя из из сути) не должны менять сумму активов, должны вноситься в систему так, чтобы они не меняли сумму активов. Это относится к переносам денег со счёта на счёт, к одалживанию денег и т. д. Но операции, которые по сути могут менять сумму активов, вносятся так, что они её меняют
- Нужно вносить вообще все операции, иначе толку в системе нет
- Должен быть учёт вообще всех активов, иначе, опять-таки, толку нет
- Сумма активов в момент времени X плюс доход за период X — Y минус расход за период X — Y должен быть равен сумме активов в момент времени Y. Этот принцип гарантируется моей системой, внести инфу в него так, чтобы он не соблюдался, невозможно
Мне нужно лишь генерировать отчёты из моей системы (об активах в конкретный момент и о доходах и расходах за любой промежуток), ничего другого мне не надо. Мне не нужно, чтобы система предупреждала меня о том, что, скажем, на каком-то из счетов заканчиваются деньги, чтобы она предупреждала о том, что нужно кому-то вернуть долг, заплатить за телефон и т. д. Также, мне не нужна стратегия. Поясню. Допустим, есть бизнесмен, у него есть несколько отделов. И ему нужно понять, какой из отделов приносит прибыль, а какой — нет. Так вот, такого мне не надо. За любой период я хочу видеть, на что ушли деньги. Но "на что ушли деньги" я понимаю лишь в обычном, бытовом смысле (т. е. я хочу чтобы система просто выдала мне словесные описания проводок, которые я сам же в неё ввёл), а не в стратегическом.
Собственно, вопрос: верно ли, что в моей системе уже используется двойная запись, просто я об этом не знаю? Если нет, то что по сути изменится от добавления двойной записи, и как это мне поможет? Как мне кажется, добавление двойной записи сведётся лишь к тому, что отрицательные активы станут именоваться пассивами, и добавится ещё один пассив под названием "нераспределённая прибыль", который всегда будет подбираться так, чтобы сумма активов была равна сумме пассивов. Ну а смысл тогда?
Собственно, вопрос: верно ли, что в моей системе уже используется двойная запись, просто я об этом не знаю?Зависит от более конкретного ответа на вопрос о том как именно система гарантирует последний принцип: «Сумма активов в момент времени X плюс доход за период X — Y минус расход за период X — Y должен быть равен сумме активов в момент времени Y.»
Если наиболее естественным способом (вы в операции помечаете, что что-то «принесло вам доход и, соответственно, имеет право изменить сумму активов»), то вы, фактически, используете стандартный бухгалтерский подход — просто с другими названиями.
Если наиболее естественным способом (вы в операции помечаете, что что-то «принесло вам доход и, соответственно, имеет право изменить сумму активов»), то вы, фактически, используете стандартный бухгалтерский подход — просто с другими названиями
Именно так я и делаю
Тогда ваши данные и «стандартные» бухгалтерские вполне эквивалентны… с точки зрения программиста. Одно можно легко пересчитать в другое.
К сожалению «стандартный», «сферический» бухгалтер этого понять неспособен — и будет обьяснять вам, камлать на свои проводки и удивляться как вы вообще что-то можете из вашей формы понять.
Главбух получающий 150-200К в месяц и разбирающийся не только в форме, но и в содержании — другое дело. Скорее всего пожмёт плечами и скажет, что не понимает — зачем вам свой велосипед, но если в налоговую отчётность сдавать не нужно, то, в общем — какая разница?
К сожалению «стандартный», «сферический» бухгалтер этого понять неспособен — и будет обьяснять вам, камлать на свои проводки и удивляться как вы вообще что-то можете из вашей формы понять.
Главбух получающий 150-200К в месяц и разбирающийся не только в форме, но и в содержании — другое дело. Скорее всего пожмёт плечами и скажет, что не понимает — зачем вам свой велосипед, но если в налоговую отчётность сдавать не нужно, то, в общем — какая разница?
У меня есть проводки, они, упрощённо говоря, бывают двух видов: те, которые не меняют сумму активов (скажем, перенос денег из налички на сбербанк, и это делается одной проводкой в моей системе), и те, что меняют (украли у меня что-то, я нашёл на улице 100 рублей, ну или мне выплатили зарплату, ну или потратил на что-то).
Вы решили что некоторые факты в свою систему вы вносить не хотите. Они существуют, просто вы их не хотите вносить. Например «убытки от кражи» это актив. Плохой актив. Сложно его использовать, но иногда можно. Вы решаете — черт с ним, не нужен он мне. И не записываете. Вам подарили деньги. Это пассив. Незначительный, но пассив. Пусть не надо отдавать, но хоть чаще здороваться с человеком надо. Но вы не записываете его. Не потому что он не существует, а потому что не хотите. Не интересен он вам.
Цена за это — два вида проводок и различие между активами и пассивами.
Так неправильно. Будете записывать всё — будет и код проще, и информации больше. И проверить себя проще. Ну и да, у вас не «активы которые бывают отрицательные» а активы и пассивы. На самом деле это разделение чисто для контроля. Если вы решаете что все (или почти все, я не настаиваю на том чтобы не было активно-пассивных, хотя так проще) могут быть либо положительными либо отрицательными, то так сложнее ошибиться, но это незначительно по сравнению с двойственностью.
Сумма активов в момент времени X плюс доход за период X — Y минус расход за период X — Y должен быть равен сумме активов в момент времени Y. Этот принцип гарантируется моей системой, внести инфу в него так, чтобы он не соблюдался, невозможно
Превратите вот это вот в нормальные счета, и будет у вас кошерная система учета.
Вы правильно говорите что вносить надо всё. Внесите прибыли и убытки. Внесите на соответствующие счета. Что еще у вас одиночными операциями вносится дополните, и всё сразу упростится примерно вдвое.
В регламентированном (официальном бухучете) тоже есть такие операции в которых одиночная запись, но они делаются с особыми «забалансовыми» счетами, и это сильно все запутывает. Вместо того чтобы добавить некоторые и так существующие вещи их убирают. (например то что мы взяли в аренду — отражают на забалансовом счете, но по хорошему стоило бы отразить арендованную машину в активах, а обязательство ее вернуть — в пассивах, и все было бы кошер, на двойных проводках).
Вам подарили деньги. Это пассив. Незначительный, но пассив. Пусть не надо отдавать, но хоть чаще здороваться с человеком надо
Чтоа? А кто-то вообще записывает такие вещи в бухгалтерию как пассив?! А если я всё же деньги на улице нашёл, то что?
и всё сразу упростится примерно вдвое
Ничего не упростится. Наоборот, у меня кроме совершенно реальных активов возникнет куча виртуальных. Кражи станут активами, найденные деньги на улице — пассивами и т. д. и т. п. Будет куча виртуальных активов и пассивов, и понять, какие из них настоящие, будет сложно. Отмечать как-то что ли? Т. е. ввести сущность "настоящий актив" и "ненастоящий", так что ли? У меня же всё просто — активы всегда настоящие. А причины, откуда эти активы возникли — это у меня история. Она и хранится, там, где ей и положено — в истории, в логе, и там её можно, если что, посмотреть.
Если я сделаю по-вашему, то история у меня всё равно останется (ну мне же нужна история всех проводок, так ведь?) Зачем тогда мне нужно заносить, мол, что мне подарили деньги в пассивы, если в истории это есть всё равно?
Mendel, а вы, случаем, в Enron не работали? :)))
Сразу вспоминается креативная бухгалтерия, описанная Баффетом…
Вы не пробовали в гугле поискать «критерии признания активов МСФО»? :)))
Например «убытки от кражи» это актив. Плохой актив.
Сразу вспоминается креативная бухгалтерия, описанная Баффетом…
Вы не пробовали в гугле поискать «критерии признания активов МСФО»? :)))
Сергей, а как МСФО помогут объяснить почему убытки это активный счет?)
Можно конечно зайти со стороны «изобретем полуторные проводки» как нам тут объясняли что «виртуальные» счета не нужны и не нужен баланс, а потом внесем «виртуальные» счета туда, где они смогут сохранять баланс, но это довольно искусственное описание, и ИМХО не дает ПОНИМАНИЯ того что такое активные и пассивные счета и почему именно так. Люди просто зазубривают какой счет должен быть с какой стороны и всё. Да, я упрощаю. Но ИМХО лучше пусть читатели поймут, чем будут зубрить DEADCLIC.
Можно конечно зайти со стороны «изобретем полуторные проводки» как нам тут объясняли что «виртуальные» счета не нужны и не нужен баланс, а потом внесем «виртуальные» счета туда, где они смогут сохранять баланс, но это довольно искусственное описание, и ИМХО не дает ПОНИМАНИЯ того что такое активные и пассивные счета и почему именно так. Люди просто зазубривают какой счет должен быть с какой стороны и всё. Да, я упрощаю. Но ИМХО лучше пусть читатели поймут, чем будут зубрить DEADCLIC.
Активы <> активный счет. Например, накопленная амортизация это классический пример пассивного счета, который расположен в активах баланса.
Еще раз советую почитать книжки про учет и отчетность. Если нет желания читать стандарты и комментарии к ним четверки — почитайте того же Баффета.
Зазубривают только те, кто не понимает базовых понятий в области учета и отчетности. И, если уж на то пошло, прибыль / убытки — это пассив баланса.
Погуглите еще термин «карго культ». Именно этим вы сейчас страдаете. Назначение фин учета — получение фин отчетности. Всё. Фин счета, двойная запись, проводки и т.п. — не более чем средство получения отчетности. И без понимания того, какой именно должна быть отчетность, не будет понимания, каким должен быть учет.
А у вас, судя по фразам
Еще раз советую почитать книжки про учет и отчетность. Если нет желания читать стандарты и комментарии к ним четверки — почитайте того же Баффета.
Зазубривают только те, кто не понимает базовых понятий в области учета и отчетности. И, если уж на то пошло, прибыль / убытки — это пассив баланса.
Погуглите еще термин «карго культ». Именно этим вы сейчас страдаете. Назначение фин учета — получение фин отчетности. Всё. Фин счета, двойная запись, проводки и т.п. — не более чем средство получения отчетности. И без понимания того, какой именно должна быть отчетность, не будет понимания, каким должен быть учет.
А у вас, судя по фразам
Например «убытки от кражи» это актив.просто напросто нет понимания того, что такое фин отчетность, зачем она нужна и, соответственно, какой она должна быть.
А давайте просто сделаем статью из названий книжек которые надо почитать?
В трех частях конечно, в одну ведь не влезет. Ну и четвертой частью выпустим список терминов. Не глоссарий, глоссарий не влезет, только список.
Это статья о двойной записи и только о ней. И даже она в одну статью не влезла.
Активы конечно же не синоним активного счета, но вот это вот, то что вы пишите… в чистом виде «зазубривание без понимания». Что такое накопленная амортизация? Это же чистый хак, не более. По сути это фонд амортизации, на который мы накидываем амортизацию, чисто чтобы не делать переоценку балансовой стоимости, но для удобства, чтобы видеть реальную картину (а именно стоимость основных) мы пишем его в активах. Простой хак, чтобы и информативно было, и не слишком гемморно учет вести. Никакого отношения к основам он не имеет.
что честно? Вот прям оба счета пассив?
или может у нас активно-пассивный счет который в отчете хочется вывести только один раз, поэтому засунем в ту сторону
Может быть опять никакого отношения к самой математической сущности двойной записи и баланса вопрос не имеет, а чистая косметика, но один архитектор-ERP зазубрил без понимания?)
Повторяюсь еще раз. Зазубривать DEADCLIC — стратегия для юзеров. «Архитекторам» нужно понимание. Напишите свою статью про двойную запись, а мы поржем. Или про финотчетность и то как ее читать. Ржать не будем, думаю в уже готовых чужих планах счетов и т.п. написанных другими людьми вам будет что-то рассказать что мне будет интересно почитать. Но с пониманием основ и с архитектурой у вас беда, да.
В трех частях конечно, в одну ведь не влезет. Ну и четвертой частью выпустим список терминов. Не глоссарий, глоссарий не влезет, только список.
Это статья о двойной записи и только о ней. И даже она в одну статью не влезла.
Активы <> активный счет. Например, накопленная амортизация это классический пример пассивного счета, который расположен в активах баланса.
Активы конечно же не синоним активного счета, но вот это вот, то что вы пишите… в чистом виде «зазубривание без понимания». Что такое накопленная амортизация? Это же чистый хак, не более. По сути это фонд амортизации, на который мы накидываем амортизацию, чисто чтобы не делать переоценку балансовой стоимости, но для удобства, чтобы видеть реальную картину (а именно стоимость основных) мы пишем его в активах. Простой хак, чтобы и информативно было, и не слишком гемморно учет вести. Никакого отношения к основам он не имеет.
если уж на то пошло, прибыль / убытки — это пассив баланса
что честно? Вот прям оба счета пассив?
или может у нас активно-пассивный счет который в отчете хочется вывести только один раз, поэтому засунем в ту сторону
бланка отчетабаланса где он бывает чаще?
Может быть опять никакого отношения к самой математической сущности двойной записи и баланса вопрос не имеет, а чистая косметика, но один архитектор-ERP зазубрил без понимания?)
Повторяюсь еще раз. Зазубривать DEADCLIC — стратегия для юзеров. «Архитекторам» нужно понимание. Напишите свою статью про двойную запись, а мы поржем. Или про финотчетность и то как ее читать. Ржать не будем, думаю в уже готовых чужих планах счетов и т.п. написанных другими людьми вам будет что-то рассказать что мне будет интересно почитать. Но с пониманием основ и с архитектурой у вас беда, да.
Что такое накопленная амортизация? Это же чистый хак, не более. По сути это фонд амортизации, на который мы накидываем амортизацию, чисто чтобы не делать переоценку балансовой стоимости, но для удобства, чтобы видеть реальную картину (а именно стоимость основных) мы пишем его в активах.
А можно поподробнее? Что такое (в вашей интерпретации) фонд амортизации, амортизация, стоимость основных, переоценка балансовой стоимости… Хочется обогатиться новыми «академическими» терминами.
Вот прям оба счета пассив?
или может у нас активно-пассивный счет который в отчете хочется вывести только один раз, поэтому засунем в ту сторону
:)))
Таки да. Вот прям оба счета — пассив, раздел капитал.
Даже если мы вместо одного активно — пассивного счета «прибыль / убытки» сделаем два счета — оба эти счета будут в пассиве баланса.
Я об этом и говорю — пока не понимаешь экономического смысла разных статей отчетности, все рассуждения об учете, двойной записи и т.п. — не более чем карго культ.
RTFM
что то картинка не прикрепилась с первого раза:
drive.google.com/file/d/0B68s1C8n6aJCM2JPVTEwTDBlNUtYWHBHUmQxcHZZZm9qRTBF/view?usp=sharing
drive.google.com/file/d/0B68s1C8n6aJCM2JPVTEwTDBlNUtYWHBHUmQxcHZZZm9qRTBF/view?usp=sharing
Хорошая фотка. Поржал, спасибо.
С нетерпением жду вашу статью.
С нетерпением жду вашу статью.
А зачем её писать? :)))
Если человек умеет и любит читать — он и так сможет почитать книжки по учету и отчетности, по крайней мере несколько ссылок я оставил.
А всем остальным и картинки хватит — многа букаф все равно не осилят. :)))
Я рад, что картинка вас рассмешила. А то вы столько анекдотов написали, а мне и ответить нечем. Придумать что-то из серии «убыток от кражи — актив» не так то легко… :)))
Если человек умеет и любит читать — он и так сможет почитать книжки по учету и отчетности, по крайней мере несколько ссылок я оставил.
А всем остальным и картинки хватит — многа букаф все равно не осилят. :)))
Я рад, что картинка вас рассмешила. А то вы столько анекдотов написали, а мне и ответить нечем. Придумать что-то из серии «убыток от кражи — актив» не так то легко… :)))
А всем остальным и картинки хватит — многа букаф все равно не осилят. :)))
Карминского? Ниасилят. Там на 20 страниц смысла — еще двести воды.
Книжки по SQL? Ниасилят. ибо вообще не в тему.
International GAAP? Я вот прям вижу как человек которому нужно автоматизировать финансы фирмочки с десятком «батискафов» или оффшорного ресселинг-хостера с полсотней серверов, или маленький интернет-магазин на пару сотен продаж в месяц (не важно будет это программист или владелец бизнеса) — берет в библиотеке англоязычный трехтомник с рекомендациями по организации учета в рамках МСФО… вот прям так и вижу, ага.
Хунгендберг? Не встречал, не знаю. Но судя по остальной подборке подозреваю что тоже не в тему будет.
International GAAP? Я вот прям вижу как человек которому нужно автоматизировать финансы фирмочки с десятком «батискафов» или оффшорного ресселинг-хостера с полсотней серверов, или маленький интернет-магазин на пару сотен продаж в месяц (не важно будет это программист или владелец бизнеса) — берет в библиотеке англоязычный трехтомник с рекомендациями по организации учета в рамках МСФО… вот прям так и вижу, ага.
Так я об этом чуть выше и написал:
А всем остальным и картинки хватит — многа букаф все равно не осилят.
Только вы немного не так расставили акценты. Если профессионалу, далекому от учета, надо «автоматизировать финансы фирмочки с десятком «батискафов» или оффшорного ресселинг-хостера с полсотней серверов, или маленький интернет-магазин на пару сотен продаж в месяц» — то он:
1. возьмет учетный софт, который написали люди, которые разбираются в учете.
или
2. прочитает, к примеру, «Концептуальные основы финансовой
отчетности» на русском языке (регистрация на том ресурсе бесплатная), почитает еще некоторые стандарты (если читать для небольших фирм — там чуть больше 200 страниц — не очень много) — и реализует сам модуль фин учета.
А вот если это будет человек «с пониженным уровнем профессионализма», он…
Не буду детализировать, но «кварковые проводки» и «убытки от кражи — актив» очень хорошо вписываются именно в этот вариант.
Еще раз повторю свой совет, который я дал в первом комментарии: Разберитесь для начала, что такое фин отчетность, для чего она нужна, из чего состоит и какие к ней существуют требования. У вас большие пробелы в базовых знаниях в области учета и отчетности.
Еще раз повторю свой совет, который я дал в первом комментарии: Разберитесь для начала, что такое фин отчетность, для чего она нужна, из чего состоит и какие к ней существуют требования. У вас большие пробелы в базовых знаниях в области учета и отчетности.
А ты прости меня кто такой, чтобы МНЕ советы давать?)
ТеоретеГ блин.
Я работал аналитиком в банке. Не много. Но отзывы остались хорошие. Я работал директором фин.учреждения. Приватное фин.учреждение, но наша дочка имела пару лицензий. Фонда, связанные операции, вексели шмексели… Я был директором небольшой оптовой фирмы с месячным оборотом в 8 миллионов баксов.
Ну и и.о. главбуха (сам себе директор и бухгалтер) на микроскопической фирме с чуть меньше сотни операций в месяц. НДС, безНДС одновременно.
Я прекрасно понимаю что бухгалтерия это не мое. Я прекрасно знаю в каких местах я хромаю, и насколько сильно я хромаю.
Но блин ты то кто такой чтобы давать мне ТАКИЕ советы?
«Архитектор»? А еще ты знаешь SQL и много других страшных слов?
Считаешь что я плохо пишу — напиши лучше.
Считаешь что я в чем-то ошибаюсь — напиши в чем, напиши как правильно, обоснуй. Нет ведь. Весь диалог строится по принципу:
-Вы пишите чушь!
-Почему чушь?
-Потому что вы ничего не понимаете!
-Ну вот так, вот так и вот так, а что не правильно?
-Должно быть вот так!
-Почему?
-Потому что я много книжек читал. Про SQL и не только! Вот какой я крутой!
Я видел столько наколеночных учетов, что тебе и не снилось. Чего они только не пишут в своих тетрадках… А программисты в своих биллингах да складах городят такооооое что safinaskar со своей полуторной записью вообще душка и лапочка. И десятки коллег после кухонных разговоров со мной о двойной записи в разы сокращали своих монстров. Так что даже упрощенная статья да, нужна и полезна. Но нет блин, «архитектор» всех научит, всем расскажет что они тупые и «ниасилят».
ПС: сорвался на эмоции да. Простите. Еще и тему в очередной раз апнул. Но просто достали эти «пиявки»:
А ты прости меня кто такой, чтобы МНЕ советы давать?
Я — специалист, который знает, почему прибыль / убытки находятся в капитале (пассиве) баланса.
А ты — человек, который взялся писать статью об учете, при этом утверждая, что
«убытки от кражи» это актив
Более того, когда указали на ошибки и дали ссылки на книги и стандарты, вместо того, чтобы их прочитать и повысить свой уровень знаний, начал переходить на личности, и доказывать, что все вокруг в гуано, а один ты — д’Артанья́н.
Для того, чтобы осилить — нужно желание учиться.
«Конечно, необходимо признать и существование того, что старожилы называют ламерством, то есть навязчивое желание малообразованных неофитов навязать свою точку зрения на проблему, с которой тот недавно познакомился «на лету». »
— Олег Татарников, 1997г., Компьютерра.
«Есть 2 типа людей: чайники и ламеры.
Из первых вырастают гуру, а вторые так и остаются ламерами.»
— Анонимус.
Ламер (от пиндосск. lame — хромой, калечный; от исп. lamér — лизать, (реже) ягненок, что тоже как бы намекает; в переводе с недословного жаргона — унылый, или также — «криворукий» (комп. сленг)) — человек, абсолютно некомпетентный в той или иной сфере, обычно в компьютерной, но твёрдо уверенный в обратном и не предпринимающий абсолютно никаких попыток что-нибудь узнать.
Она нужна всегда, когда у вас есть разные «виды» денег.
Я и не говорил, что разные мои счета (кошелёк в кармане, счёт в сбербанке и т. д.) нужно смешать в одно. Это разные активы, это я понимаю.
Строчка-хак??? Это, условно говоря, деньги лежащие у вас в кошельке
Судя по статье, деньги в кошельке — это актив, а нераспределённая прибыль — это пассив. Так что это разные вещи.
Вы поднимаете документы, выясняете, что два раза провели один и тот же платёж, один раз — как оплату сотовой связи, второй — как наземной. Исправляете — но после исправления оказывается что в один из дней у вас в кассе остались деньги сверх лимита и вам нужно что-то с этим срочно делать (если реально нарушения не было — то нужно найти-таки вторую платёжку и понять куда, если не на оплату наземной связи, ушли деньги). И так далее.
Всё это я смогу сделать и в своей (реально существующей, я её не выдумал щас на ходу) системе, которую я описал в комменте https://habrahabr.ru/post/336656/#comment_10395424 (или, может, вы скажете, что я уже использую там двойную запись?). Если не согласны, то объясните подробно, почему по-вашему в моей системе мне совершить такой манёвр будет сложно, а в системе с двойной записью — легко (если вам это удастся, то это будет очень здорово, возможно, тут как раз собака и зарыта)
Судя по статье, деньги в кошельке — это актив, а нераспределённая прибыль — это пассив. Так что это разные вещи.,Нераспределённая прибыль — это оценка тех деньг, которые вы ещё не решили куда потратить и которые просто лежат у вас в кошельке. То есть если у вас в кошельке физически 10000, но из них 9000 уже отложены на покупку молока, то «не распределённая прибыль» будет 1000.
Судя по описанию вы, в вашей системе, всё равно делаете что-то подобное, только называете по другому.
?!?!?!?? Ээээ, вот, допустим, я использую бухгалтерию так, как описано в статье. У меня было 10 000 рэ, и все они были нераспределённой прибылью. Потом в какой-то момент я решил 9000 из них отложить на молоко, ничего никуда физически не перемещая. Как будут выглядеть активы и пассивы до принятия такого решения и как будет выглядеть проводка, соответствующая самому решению?!
У меня в моей системе нет понятия «деньги, отложенные на что-то». Есть реальные, физически существующие счета
У меня в моей системе нет понятия «деньги, отложенные на что-то». Есть реальные, физически существующие счета
Как будут выглядеть активы и пассивы до принятия такого решения и как будет выглядеть проводка, соответствующая самому решению?!В статье был пример:
Начисленные и не выплаченные дивиденды: 500рубСоответственно «нераспределённая прибыль» должна будет перетечь в другой счёт. Какие именно при этом породятся проводки — сходу не скажу. Есть ощущение что сначала вам придётся перегнать прибыль в резервы, а уже потом, оттуда — на, собственно «запланированное, но не купленное, молоко».
Но если вы частное лицо — то тут таких жёстких ограничений нет.
Вы поднимаете документы, выясняете, что два раза провели один и тот же платёж, один раз — как оплату сотовой связи, второй — как наземной. Исправляете — но после исправления оказывается что в один из дней у вас в кассе остались деньги сверх лимита и вам нужно что-то с этим срочно делать (если реально нарушения не было — то нужно найти-таки вторую платёжку и понять куда, если не на оплату наземной связи, ушли деньги). И так далее.
Объясните подробнее, что вы пытаетесь тут сказать.
- Каким образом платеж можно провести дважды (насколько я понимаю из цитаты)? Система этого что, не может заметить и не позволить это сделать? Как вообще идентифицируются платежи — кортеж (сумма, источник, назначение) или как-то иначе?
- Что значит исправили? В чем оно заключалось? Должно было быть одинаковых 2 платежа за наземную связь? Два за сотовую? Или 2 разных, один за наземную, другой за сотовую? Опять-таки, что значит разные?
- Откуда появились деньги в кассе? Вы же вроде как исправлением должны были их уменьшить?
- Что значит деньги сверх лимита? Чем это плохо? Кто ставит этот лимит и какое имеет на это право?
Каким образом платеж можно провести дважды (насколько я понимаю из цитаты)?Просто взять и два раза внести данные в систему. Как вы от этого защититесь? Можно отказаться принимать полные дубликаты, но тогда банальная ситуация когда у вас автомат не принимает платежи больше, скажем, 5000 рублей, а вы хотите заплатить 10000 (и потому платили дважды) вдруг станет незаконной.
Как вообще идентифицируются платежи — кортеж (сумма, источник, назначение) или как-то иначе?Сумма, источник, назначение — это минимум. Обычно там ещё много разной другой информации. Которая для подсчётов не нужна, но крайне полезна когда вы пытаетесь сопоставить данные бухгалтерии с реальным миром.
Что значит исправили? В чем оно заключалось?Подняли документы, привели данные в программе в соответствие с действительностью. Во многих случаях достаточно просто посмотреть на «метаморформацию», чтобы понять что платежи в МГТС никак не могут проходить по статье «закупка расходных материалов».
Откуда появились деньги в кассе? Вы же вроде как исправлением должны были их уменьшить?Не понял вопроса. Если вы убрали платёж, то счёт, с которого этот платёж совершался — автоматически стал содержать больше денег, однако.
Что значит деньги сверх лимита? Чем это плохо? Кто ставит этот лимит и какое имеет на это право?Государство. Это частное лицо может положить миллион «под подушку». А предприятие, если ему кто-то заплатит миллион наличными, должно будет по окончании операционного дня этот миллион сдать (ну не совсем миллион… всё что сверх лимита) в банк. Есть также ограничения на то, сколько вы можете потратить на рекламу, транспорт и прочая, прочая, прочая. За нарушение — обычно штраф, но могут и счёт блокировать, если их будет много.
Объяснить очень легко. :)))
Двойная запись выполняет те же функции, что и ограничения целостности данных (Constraints) в базах данных ну или бекапы для сисадминов. До тех пор, пока учет (работа с БД, работа сервера) ведется без ошибок (сбоев), без двойной записи (Constraints, бекапов) можно обойтись. Но, как говорится, все люди делятся на тех, кто не делает бекапов, и на тех, кто уже делает. :)))
Двойная запись выполняет те же функции, что и ограничения целостности данных (Constraints) в базах данных ну или бекапы для сисадминов. До тех пор, пока учет (работа с БД, работа сервера) ведется без ошибок (сбоев), без двойной записи (Constraints, бекапов) можно обойтись. Но, как говорится, все люди делятся на тех, кто не делает бекапов, и на тех, кто уже делает. :)))
Mendel, хотелось бы ответ именно от вас
Ого! Ну наконец-то еще хоть кто-то пытается разобраться во всем этом навозе, без ввода всяких туманных понятий и с учетом современных реалий.
Конкретнее, вопрос у меня такой: в двойной записи сумма активов равна сумме пассивов. Но достигается это равенство за счёт такого простого хака: за счёт того, что мы подбираем одну из строчек пассива под названием «нераспределённая прибыль» таким образом, чтобы сумма активов была равна сумме пассивов. Вот и всё. Ну а раз так, то какой тогда в этом смысл?
Спасибо за ваш вопрос. Видно что вы пытаетесь вникнуть, и еще — подтверждаете что вторая статья таки да, должна быть полностью из примеров.
Ошибка ваша в слове «подбирается».
Она не подбирается, она самая что ни на есть реальная. Что есть то и записываем.
Давайте представим себе без всяких балансов и записей простую ситуацию.
Вы купили слонов за 100рублей, продали за 150рублей.
100рублей это ваши расходы, 150рублей это ваши доходы, 50 рублей это ваша прибыль.
Типичная ошибка при понимании двойной записи — считать что в ней есть избыточность.
Нет, избыточности в ней нет, просто она записывает ВСЁ что есть на самом деле.
Запишите эту операцию в баланс, и прибыль перестанет казаться виртуальным хаком.
И скажите, вся эта двойная запись нужна лишь в ситуации, когда бизнес существует как бы отдельно от учредителей, т. е. когда понятие «долг бизнеса учредителю» имеет смысл? Или в ситуации учёта личных финансов тоже имеет смысл?
Любой счет, включая капитал, имеет смысл вводить тогда когда он имеет смысл.
Весь баланс это краткое отражение истории операций. В начале любого бизнеса у нас учредители дают бизнесу какие-то активы. До этого у нас на балансе все по нулям, а после этого в активах появляются активы, в пассивных счетах — капитал, или «долг учредителю».
В личных финансах это может быть «наследство от родителей»… или ничего не будет. Не суть. Активные счета — то что есть, пассивные — откуда оно взялось. Если что-то взялось, то есть и откуда… Ну как-то так.
И еще, я не уверен что это именно то что вы спрашиваете, но не смешивайте личные финансы и финансы бизнеса. Меня 14 лет назад девочки (красивые блин) из ЕБРР очень сношали за неуместную агрегацию счетов и направлений бизнесов.
Я тогда работал в банке аналитиком. Оценивали заемщиков «по реальным данным», т.е. по черной бухгалтерии. Которая у каждого разная и всегда-всегда ужасная.
Разумеется многие у кого было несколько направлений бизнеса (ну а так оно почти всегда) — вели их учет вперемешку. И когда я все это приводил в человеческий вид, пригодный для анализа, то соответственно был соблазн повторять структуру учета клиента, и тоже смешивать. Но за это ругались очень сильно, и вот почему: когда учет смешанный, то часто мы не видим что у одного из направлений убытки, которые покрываются доходами другого. Это может быть признаком проблемы о которой заемщик еще не знает, или что было лично на моей практике — клиент знает о проблеме, но врет о целях кредита. Говорит что на развитие удачного направления, а сам хочет потратить на санацию проблемного направления. Соответственно смешивание личных денег и денег личного бизнеса лишает нас возможности видеть отдельно картину по бизнесу, и отдельно по личным финансам, и принимать решения по ним отдельно.
Это просто хак такой, чтобы сумма активов была равна сумме пассивов. Я его уберу.
Не хак. Ничто не хак. Отличие правильного учета от неправильного не в том, что правильный добавляет то чего нет, а в том, что неправильный убирает то что есть на самом деле… Ну а дальше у вас не хватает части счетов и все расползается. Обсуждать нечего.
Еще раз, если вы все еще не верите мне, что в реальности всегда есть ДВА счета а не один — в нашем мире один из фундаментальных законов это закон сохранения. Если что-то появилось, то оно появилось откуда-то. И там стало меньше. Если что-то исчезло, то где-то что-то появилось. Всегда. Если вор украл слонов, то у нас в обмен на это появился долг вора перед нами. Другое дело что не всегда мы сможем им воспользоваться. У меня когда был парк грузовых машин — два раза машины вскрывали. Один раз менты по горячим следам раскрыли и вор рассчитался включая ущерб. О том что поймали вторых я узнал через пять лет, когда искал в реестре информацию по своей фирме. Оказывается суд им даже присудил ущерб который они должны мне (ага, меньше половины факта), но денег у них нифига не было. Можно было конечно их их з/п в колонии что-то высчитывать, но я об этом узнал поздно, да и гемороя больше. Но факт остается фактом — этот убыток сел у меня в актив, и я мог им распорядится. Теоретически. Первый раз смог. Но пока не нашли, два дня я думал что все, не смогу. А в активе он висел. Убыток да, висел в активе.
Итак, Mendel, спрашиваю в лоб: распишите, пожалуйста, максимально подробно ситуацию описанную в этом абзаце, можно даже в виде отдельной статьи. Вот этот ваш «реальный случай».
Распишу. Отдельной статьей. Примеры учета распишу. Но не этот случай, тут еще больше запутаемся.
И вообще, я так и не понял: так как всё-таки обычно устроена работа с компьютерной бухгалтерской системой? В неё вносят инфу и сразу при внесении система гарантирует, что баланс сходится? Если так, то почему тогда бухгалтера раз в месяц чего-то там пытаются свести?
Немного не так. Не сходится то что в базе с те что в реальности. В базе баланс сходится. Активы равны пассивам, все ок. Но в базе написано что у нас 5 яблок, а на самом деле 10. И в базе написано что в кассе 100 рублей, а на самом деле 200рублей.
Ищем, и понимаем что что-то забыли записать, или записали не туда. Вот с этим и бегают каждый месяц.
Наследство от родителей тоже в пассивы? Зачем? Его же не надо будет возвращать, оно уже моё. Пассивы — это долги, разве нет?
В моей реально существующей системе, описанной здесь: https://habrahabr.ru/post/336656/#comment_10395424 есть два вида отчётов (условно): список операций (история) за любой промежуток времени, и список активов в любой момент времени (в том числе "сейчас"). Так вот, если, допустим, я получу наследство от родителей, то, разумеется, я внесу это как проводку с указанием источника средств "наследство от родителей", и она будет видна в истории. Но вот в списке активов (у меня только активы, мои долги кому-то отображаются как активы со знаком минус) строчки "наследство от родителей" не будет, потому что никому я это наследство уже не должен. В активах отображаются лишь физические счета, мои долги кому-то (со знаком минус) и долги кого-то мне (со знаком плюс).
В общем, не понимаю, зачем вносить наследство в пассивы. Если понадобится узнать, откуда взялись деньги, надо будет смотреть в истории. А в пассивах только реальные долги кому-то должны быть.
Может быть, вы скажете, что получение зп или даже "нашёл на улице 100 рэ" тоже нужно вносить в пассив, чтобы там была огромная куча мелких записей, по одной за каждый возможный источник дохода. А то мало ли, блин, вдруг мне захочется потом найдённую сторублёвую бумажку положить обратно на то же место на улице.
когда учет смешанный, то часто мы не видим что у одного из направлений убытки, которые покрываются доходами другого
Про это я уже сказал в упомянутом комменте:
Также, мне не нужна стратегия. Поясню. Допустим, есть бизнесмен, у него есть несколько отделов. И ему нужно понять, какой из отделов приносит прибыль, а какой — нет. Так вот, такого мне не надо
Или, может быть, вы скажете, что двойная запись как раз для того и нужна, чтобы видеть прибыльность разных направлений? Тогда так и скажите
Если вор украл слонов, то у нас в обмен на это появился долг вора перед нами
А если стихийное бедствие, и ничего не застраховано? А если деньги на улице нашли? Если действовать по вашей схеме, то в нашем балансе в графе "активе" будет куча убытков, которые уже никто никогда не вернёт, а в графе "пассивы" куча как бы долгов, которые на самом деле никому возвращать не надо, типа этого наследства от родителей. И будет тогда человек, у которого ничего нет, но у которого по бухгалтерии получается активов на миллион долларов, и пассивов столько же
Я попробовал вам ответить и понял, что вы действительно живёте «почти в лесу».
Действительно, в какой другой стране можно сказать
Или
А вот это уже — во-многом потому, что Россиийское законодательство так просто устроено. Но это только для «физиков» оно так просто устроено. У Юрлиц же есть куча ограничений. Вы не можете заплатить, скажем, за рекламу, 1000000 рублей просто потому что они у вас есть — вам нужно будет посмотреть на разные параметры, которые в вашей системе считаются только на основании принципа:
А причина всё та же: на «расходы на рекламу» налог ниже, чем на «чистую прибыль», и государство следит за тем, чтобы вся «чистая прибыль» не растворилась в подобного рода сомнительных платежах…
А в вашей схеме — он, неожиданно, окажется кристально чист и пуст.
В России, кстати, ситуация похожая, но противоположная: если вы, наоборот, купите этот дом, а потом его уничтожит ураган — то вы окажетесь без ничего… но право на налоговый-то вычет в следующем году никуда не денется!
У меня просто есть ощущение, что вы тщательно избегаете случаев для которых нужна бухгалтерия, а где это не получается (как с тем же вычетом за покупку недвижимости) — рассчитываете всё вне вашей бухгалтерии… но тогда зачем она вам вообще нужна???
Действительно, в какой другой стране можно сказать
Но вот в списке активов (у меня только активы, мои долги кому-то отображаются как активы со знаком минус) строчки «наследство от родителей» не будет, потому что никому я это наследство уже не должен.и быть при этом правым? В большинстве стран вы должны будете заплатить налог — и, как правило, не в момент получения наследства, а в следующем году.
Или
Может быть, вы скажете, что получение зп или даже «нашёл на улице 100 рэ» тоже нужно вносить в пассив, чтобы там была огромная куча мелких записей, по одной за каждый возможный источник дохода. А то мало ли, блин, вдруг мне захочется потом найдённую сторублёвую бумажку положить обратно на то же место на улице.Ведь в России — это тоже правда: налоговая ставка (в отличие, опять-таки, от большинства других стран) не зависит от источника получения дохода (за редкими исключениями) — и от того на что вы потратили деньги не зависит тоже…
Или, может быть, вы скажете, что двойная запись как раз для того и нужна, чтобы видеть прибыльность разных направлений?Как мы уже выяснили двойная запись у вас, на самом деле, есть. Чего у вас нет — так это разделения активов и пассивов по разным видам счетов.
А вот это уже — во-многом потому, что Россиийское законодательство так просто устроено. Но это только для «физиков» оно так просто устроено. У Юрлиц же есть куча ограничений. Вы не можете заплатить, скажем, за рекламу, 1000000 рублей просто потому что они у вас есть — вам нужно будет посмотреть на разные параметры, которые в вашей системе считаются только на основании принципа:
Если понадобится узнать, откуда взялись деньги, надо будет смотреть в истории.и только после этого вы сможете сказать — можно это делать или нет.
А причина всё та же: на «расходы на рекламу» налог ниже, чем на «чистую прибыль», и государство следит за тем, чтобы вся «чистая прибыль» не растворилась в подобного рода сомнительных платежах…
И будет тогда человек, у которого ничего нет, но у которого по бухгалтерии получается активов на миллион долларов, и пассивов столько жеТак в этом же всё и дело! Если этот человек получил в наследство дом за миллион долларов, а на следующий день его смыло морской волной, то у него, понятно, ничего не останется… кроме обязательства уплатить за этот дом налоги!
А в вашей схеме — он, неожиданно, окажется кристально чист и пуст.
В России, кстати, ситуация похожая, но противоположная: если вы, наоборот, купите этот дом, а потом его уничтожит ураган — то вы окажетесь без ничего… но право на налоговый-то вычет в следующем году никуда не денется!
У меня просто есть ощущение, что вы тщательно избегаете случаев для которых нужна бухгалтерия, а где это не получается (как с тем же вычетом за покупку недвижимости) — рассчитываете всё вне вашей бухгалтерии… но тогда зачем она вам вообще нужна???
Я брал гипотетическую ситуацию, когда никаких налогов нет. А даже если предположить налоги, то тогда в момент получения наследства и прочего долг (государству) получается лишь на сумму налога, а не на всю сумму наследства
А даже если предположить налоги, то тогда в момент получения наследства и прочего долг (государству) получается лишь на сумму налога, а не на всю сумму наследства.Однако для того, чтобы рассчитать сумму налога вам придётся учесть не только это наследство, но также и другие доходы, так как они меняют ставку и облагаемую базу! А как вы это сделаете, если свалили всё в кучу?
У меня же есть лог операций. И в своей системе я могу узнать доход и расход за любой период
У меня же есть лог операций.Ну да. Но с тем же успехом вы могли их в тетрадочку записать.
И в своей системе я могу узнать доход и расход за любой период.Прекрасно. Как это вам поможет заполнить графу «сумма, потраченная на лечение в 2016 году»? За это, кстати, даже «в лесу» под названием Россия можно вычет получить.
У меня же есть лог операций
У меня есть не лог операций отдельно от бухгалтерии, а лог операций, являющийся неотъемлемой частью бухгалтерии. Который гарантированно (это гарантируется самой системой) действительно является логом всех изменений активов.
Как это вам поможет заполнить графу «сумма, потраченная на лечение в 2016 году»?
Операциям в логе я могу проставить теги. И по тегам смотреть. Кстати говоря, (я не говорил об этом) именно так я на самом деле и делаю. У меня у операций есть теги, а теги эти образуют иерархическую систему. А потому за любой период я могу смотреть структуру доходов и расходов.
А вы, видимо, предлагаете считать сумму, потраченную на лечение, активом, да? Это нелогично, т. к. этот актив мне никто налом не даст, это уже потраченные деньги, их нет, они в истории, они в прошлом.
И, кстати, если считать их активом, то как тогда узнать сумму, потраченную на лечение именно в 2016-м году? Без логов, а только на основании списка активов и пассивов? Никак. Потому что актив "сумма, потраченная на лечение" будет включать все траты начиная с начала ведения бухгалтерии. А узнать сумму, потраченную на лечение за определённый период, без логов вы всё равно не сможете. А зачем тогда держать эти деньги, потраченные на лечение, в активах?
Операциям в логе я могу проставить теги. И по тегам смотреть. Кстати говоря, (я не говорил об этом) именно так я на самом деле и делаю. У меня у операций есть теги, а теги эти образуют иерархическую систему. А потому за любой период я могу смотреть структуру доходов и расходов.Ну то есть план счетов вы тоже изобрели. Это хорошо.
А вы, видимо, предлагаете считать сумму, потраченную на лечение, активом, да? Это нелогично, т. к. этот актив мне никто налом не даст, это уже потраченные деньги, их нет, они в истории, они в прошлом.Нет, я не предлагаю их занести в актив. Мне просто было непонятно как вы, фактически, c одним счётом, получаете хоть что-то полезное от вашей системы.
Потому что актив «сумма, потраченная на лечение» будет включать все траты начиная с начала ведения бухгалтерии.Но также будет подвёдён баланс за месяц и год — а уже из них будут видны все нужные нам числа.
А узнать сумму, потраченную на лечение за определённый период, без логов вы всё равно не сможете.Смогу, конечно. Движение денег по соответствующему счёту за год — это и будет ответом.
Можете рассматривать план счетов, как «систему тегов специально заточенную под существующее законодательство», если хотите.
Фактически ваша система представляет собой кустарную поделку, которая достаточно грубо имитирует стандартный бухгалтерский учёт за исключением пары косметических моментов.
А дальше возникает вопрос: а нафига, собственно? Зачем что-то делать «на коленке», а потом, когда нужно, пересчитывать под требования закона — если можно сразу сделать всё «по правилам»?
Нет, я не предлагаю их занести в актив
А куда тогда? В лог? Так и у меня они в логе
Мне просто было непонятно как вы, фактически, c одним счётом, получаете хоть что-то полезное от вашей системы
У меня по одному счёту на физический кошелёк, счёт в сбербанке, и т. д., на каждый долг кому-то и долг мне. Если убрать долги и считать, что кошелёк и счёт в сбере — это одно, то, да, у меня один счёт. Но у меня всё равно всё ок. Потому что у меня вся история есть. И я могу посмотреть, сколько у меня было денег в любой момент, сколько доходов и расходов за любой период, и структуру этих доходов и расходов. И больше мне ничего не надо, и я не понимаю, зачем кому-то может быть нужно что-то ещё.
Но также будет подвёдён баланс за месяц и год
Что это такое?
Движение денег по соответствующему счёту за год — это и будет ответом.
Это я и называю логом. Я словом лог понимаю не то, что в программировании называют логом (я выразился, наверное, неправильно). (Заодно Mendel пингану, может он тоже моё "лог" неправильно понял.) Я логом называю не /var/log/messages.log какой-нибудь там. Я называю им, собственно, главную и неотъемлемую часть моей системы — собственно, список операций. Консистентность которого система гарантирует.
Далее, по какому "соответствующему"? По физическому кошельку? Нераспределённой прибыли? Или по специальному счёту "расходы на лечение"? Тогда что это за счёт такой? По идее актив, но ведь вы сами только что сказали, что это не актив
Да ну. Надоело.
Ваша архитектура это как ТТУК — вроде и оно, но не оно. И спорить тут смысла нет никакого, будете до крови отстаивать свою позицию. Вы просто решили что у вас самая лучшая архитектура и на любой аргумент придумываете кучу возражений. Скучно.
Учет доходов и расходов у вас есть? Учет изменения «активов», да? И ведется он отдельно от основной системы так? Т.е. когда у вас одиночная проводка, то одновременно вы еще и записываете что произошло изменение суммы баланса, чтобы видеть доходы/расходы и общую целостность. Я правильно вас понял?)
Ваша архитектура это как ТТУК — вроде и оно, но не оно. И спорить тут смысла нет никакого, будете до крови отстаивать свою позицию. Вы просто решили что у вас самая лучшая архитектура и на любой аргумент придумываете кучу возражений. Скучно.
Учет доходов и расходов у вас есть? Учет изменения «активов», да? И ведется он отдельно от основной системы так? Т.е. когда у вас одиночная проводка, то одновременно вы еще и записываете что произошло изменение суммы баланса, чтобы видеть доходы/расходы и общую целостность. Я правильно вас понял?)
Mendel, раз вы задаёте вопросы, значит, вам всё-таки интересно. Поэтому отвечу подробно. За одно khim пингану.
Итак, на самом деле никакой БД у меня нет вообще. Есть (условно) один текстовый файл, который содержит в себе список активов в совершенно конкретный фиксированный момент времени в прошлом (2016-01-21 23:59:59 UTC), а также список событий, т. е. операций, проводок, совершённых начиная с того момента (как меняющих сумму активов, так и не меняющих). Файл этот я пополняю самостоятельно, в текстовом редакторе. Файл написан на придуманном мной языке. Поддерживаются комменты (комменты — это именно комменты, они игнорируются полностью).
Если угодно, считайте, что этот файл эквивалентен БД с двумя таблицами: ACCOUNTS_IN_THE_BEGINNING и EVENTS.
Есть программа (C++, bison), которая умеет этот файл читать и выдавать на его основе следующую инфу: список активов в любой времени X, доходы и расходы на промежутке X — Y, и список активов в конце этого промежутка, т. е. Y.
К событиям, которые переносят деньги с одного счёта на другой, никаких описаний не прикрепляется. А вот к доходам и расходам, т. е., собственно, операциям, которые меняют суммарные активы, прикрепляется так называемый "путь". Путь — это своего рода тег, объясняющий откуда взялись деньги или куда они ушли. Пути образуют иерархическую структуру. Когда моя программа показывает доходы и расходы на некий промежуток времени, она показывает дерево этих самых путей.
Итак, пример входного файла (с фейковыми данными):
# Комменты начинаются с решётки. Они полностью игнорируются
history_begin
2016-01-21 23:59:59;
currencies
RUB; # Программа поддерживает работу с несколькими валютами
USD;
rates_init
RUB; # Здесь указываются курсы валют в начальный момент. Потом они могут меняться
1 USD = 60 RUB;
accounts # Счета в начальный момент, забейте на "/a"
"Visa" 1000 RUB "/a";
"Yandex Money" 1000 RUB "/a";
boxes # box - это своего рода счёт, на котором деньги могут изменяться сами по себе, ну, например, счёт в банке с процентами
events # Собственно, события
# Перенос со счёта на счёт
2016-01-22 01:00:00 account_transfer "Visa" 500 RUB "Yandex Money";
# Траты
2016-01-23 01:00:00 account_change "Visa" -100 RUB "/life/food";
2016-01-24 01:00:00 account_change "Visa" -200 RUB "/life/food";
2016-01-25 01:00:00 account_change "Yandex Money" -100 RUB "/life/taxi";
# Заработок
2016-01-26 01:00:00 account_change "Visa" 2000 RUB "/life/job";Если теперь запустить программу на этом входе так:
/dr/projects/accounting/program/accounting '2016-01-24 00:00:00' '2016-01-27 00:00:00' RUB /tmp/oo /tmp/ooo < ~/tmp/a.accто она выдаст мой баланс в указанных двух временных точках и все доходы и расходы за этот промежуток:
---- 2016-01-24 00:00:00.000000
"Visa" 400.00 RUB = 400.00 RUB
"Yandex Money" 1,500.00 RUB = 1,500.00 RUB
---- 1,900.00 RUB
/life/food -200.00 RUB
/life/job 2,000.00 RUB
/life/taxi -100.00 RUB
/life@ 1,700.00 RUB
@ 1,700.00 RUB
---- 2016-01-27 00:00:00.000000
"Visa" 2,200.00 RUB = 2,200.00 RUB
"Yandex Money" 1,400.00 RUB = 1,400.00 RUB
---- 3,600.00 RUBУчет доходов и расходов у вас есть?
Да.
Учет изменения «активов», да?
Да. Учёт доходов и расходов — это и есть учёт изменения активов. Каждый доход или расход является одноврменно изменением активов.
И ведется он отдельно от основной системы так?
Нет.
Т.е. когда у вас одиночная проводка, то одновременно вы еще и записываете что произошло изменение суммы баланса, чтобы видеть доходы/расходы и общую целостность.
Я просто записываю эту одиночную проводку. И больше ничего не делаю. А программа знает, что раз эта проводка есть, значит, активы изменились. Т. е. по отдельности расход и изменение активов я не записываю.
P. S. Ещё у меня деньги хранятся в double'ах. :)
Я просто записываю эту одиночную проводку. И больше ничего не делаю. А программа знает, что раз эта проводка есть, значит, активы изменились. Т. е. по отдельности расход и изменение активов я не записываю.
т.е. по факту у вас есть два специальных счета — расходы и доходы (ну или как я понимаю вашу извращенную логику это таки один счет, активно-пассивный), и особый вид проводки для него. Т.е. если проводка имеет один счет, то вторым подразумевается счет «изменение активов».
Все остальное даже комментировать не буду.
Наследство от родителей тоже в пассивы? Зачем? Его же не надо будет возвращать, оно уже моё. Пассивы — это долги, разве нет?
Пассивы это не столько «долги» сколько «происхождение денег». В активах лежат сами деньги, в пассивах — написано откуда они. Это из нераспределенной прибыли, это из наследства, это «отложено на дивиденды» и т.п. Пассив который не нужно отдавать — все равно пассив. Актив который нельзя использовать — все равно актив.
В общем, не понимаю, зачем вносить наследство в пассивы. Если понадобится узнать, откуда взялись деньги, надо будет смотреть в истории. А в пассивах только реальные долги кому-то должны быть.
Простой пример. Представьте себе что вы ошиблись при внесении суммы… ну не наследства, а скажем подарок на ДР. Вам подарили тысячу рублей, а вы записали сто.
Потом прошел месяц, и в кошельке лишние 900рублей.
Что за бабки? Неправильно записали деньги за ДР? Одолжили у кого-то и забыли записать? Сосед на прошлой неделе просил купить ему какую-то хрень, раз вы едете на базар, но ее не оказалось… не помню что это было, но вроде я ему денег вернул тогда… или забыл? Черт, что это за деньги то такие?
А была бы графа «подарки», то увидели бы, что что-то подозрительно маленькая сумма.
В вагоне проводок за месяц выискивать сложно, а в десятке счетов — проще.
В данном случае это мелочь, но все равно помогает.
А если говорить о наследстве, то тут есть опасность побольше.
«Деньги есть, деньги не вопрос». Двадцать лет назад, когда я только начинал заниматься бизнесом, то у меня с партнером был небольшой магазинчик. И с каждой неделей у нас в кассе было все больше денег. И каждую неделю мы продавали все больше компьютеров, и зарабатывали все больше денег. Ну и брали себе «дивиденды» конечно все больше. Оставляли в кассе сколько нужно на ближайшее время… Через два года мы таки посчитали все подробно и оказалось что дивиденды у нас росли быстрее чем прибыль. Но деньги в кассе были. Просто рост оборотов увеличивал рост денег которые мы должны были отдать поставщикам с отсрочкой платежа, а поскольку был постоянный рост, то проедание в долг заметили только через два года. Считали только что есть, не сильно отслеживая происхождение.
Потом еще посчитали все подробно, и разделились. Еще даже было что делить. Но это в основном были нематериальные активы. Деньги были выедены в минус.
Так вот. Наследство. Наследство это куча бабла. Без отражения того откуда оно взялось. Сразу появляется желание больше тратить. Машину получше. А она больше топлива ест, дороже ремонт. И вроде все хорошо. Деньги есть. Но расходы то уже возросли. Мы ведь «чистую прибыль» не считаем, нам она ни к чему. Разницу между доходами и расходами не считаем. Смотрим только что у нас есть. А деньги есть. Все хорошо. Уменьшаются правда, но есть…
Может быть, вы скажете, что получение зп или даже «нашёл на улице 100 рэ» тоже нужно вносить в пассив, чтобы там была огромная куча мелких записей, по одной за каждый возможный источник дохода. А то мало ли, блин, вдруг мне захочется потом найдённую сторублёвую бумажку положить обратно на то же место на улице.
Не надо писать разные, надо писать все движения, а не дробить до атомов. Просто сделать счета «прочие доходы» и «прочие расходы» и все.
Или, может быть, вы скажете, что двойная запись как раз для того и нужна, чтобы видеть прибыльность разных направлений? Тогда так и скажите
Двойная запись нужна чтобы видеть всё, а не только часть. А что именно видеть — не суть.
А если стихийное бедствие, и ничего не застраховано? А если деньги на улице нашли? Если действовать по вашей схеме, то в нашем балансе в графе «активе» будет куча убытков, которые уже никто никогда не вернёт, а в графе «пассивы» куча как бы долгов, которые на самом деле никому возвращать не надо, типа этого наследства от родителей. И будет тогда человек, у которого ничего нет, но у которого по бухгалтерии получается активов на миллион долларов, и пассивов столько же
Убытки можно покрыть, например уменьшив какой-то пассив.
Допустим у вас в кошельке лежала тысяча рублей. Она была у вас записана в активе «кошелек, 1000». У вас ее украли. Вы делаете проводку «из кошелька в убытки». При этом вы откладывали «на черный день». Держали их на карточке. Допустим 10000. И у вас было записано «10000 на карточке» (актив) и «10000 — отложено на черный день» — это пассив. Теперь вы сняли тысячу с карточки. Теперь на карточке девять, в кошельке тысяча, убытки тысяча, отложено десять. Но раз вы уже взяли из отложенных тысячу в кошелек, и будете тратить, то отложенное уменьшаем.
При этом «отложено на черный день» это не дубль карточки, а именно отражение того что за деньги. Ибо вы можете себе решить что десять тысяч у вас на черный день, при этом пять из них лежат на карточке, четыре дома, и одна в кошельке. Когда понадобятся, тогда и возьмете там где будет. Но «свободных» у вас только тысяча, как и записано в «нераспределеная прибыль».
Так что при нормальном учете миллионов не будет, они будут взаимно уменьшаться.
Ну и вообще, в целом… не знаю как тут правильнее было бы смотреть на личные финансы, но в бизнесе смотрят не на активы а на капитал и другие параметры, ибо не все активы одинаково хороши, и не все пассивы плохи. Я тут разделение на активы и пассивы ввел, не трогая другое чтобы математику объяснить, а тонкости учета уже потом.
В вагоне проводок за месяц выискивать сложно, а в десятке счетов — проще.
Разницы нет. Не убедительно. Просто получить список проводок, затрагивающих этот счёт (в данном случае физический кошелёк) и среди них искать. Эти проводки ещё при создании можно разметить как-то, мол, на что ушло, и потом по этим тегам легко искать. Вы скАжете, мол, это и есть пассивы. Я скажу, что это не пассивы, это история, лог. Сущность должна быть там, где её место.
Двадцать лет назад, когда я только начинал заниматься бизнесом, то у меня с партнером был небольшой магазинчик
В моей системе такого казуса тоже произойти не могло бы. В моей системе всегда можно посмотреть список активов (а долг кому-то — это отрицательный актив). Вы бы тогда в моей системе периодически смотрели бы список активов и видели бы, что сумма активов почему-то отрицательна, и что среди активов есть очень большой по модулю отрицательный актив — долг поставщикам. И поняли бы, что что-то не то. А логи всех передвижений пишутся, в них тоже можно всё посмотреть
Наследство это куча бабла. Без отражения того откуда оно взялось. Сразу появляется желание больше тратить. Машину получше
Дык у меня ведутся логи. Можно посмотреть доходы и расходы за любой промежуток. И активы в любой точке. Так что я могу увидеть, что сейчас активов меньше, чем было недавно, значит, я много трачу. Ну или, что то же самое, что за последний месяц расходы больше доходов.
Разницу между доходами и расходами не считаем
Считаем! Моя система позволяет её считать. За любой промежуток времени
«10000 — отложено на черный день» — это пассив
Стоп. До сих пор вы говорили, что пассив — это источник денег. Причина их появления. А теперь вдруг "отложено на то-то" — это пассив. Как так? Вот допустим, у меня был полный ноль. Я получил наследство 1000 р. Стало: активы: кошелёк 1000 р., пассивы: наследство 1000 р. Окей, теперь допустим, я хочу отложить эти 1000 р. на чёрный день. Как это сделать? Переложить из пассива наследство в пассив чёрный день? Но тогда инфа о том, что деньги возникли из наследства, потеряется. А разве не для этого вы ведёте такой строгий учёт? Чтобы не терять инфу о том, откуда что возникло?
Теперь такой вопрос. Допустим, у нас есть бизнес, мы ведём его бухгалтерию. У бизнеса есть два направления (ну допустим, одно — это продавать слонов, другое — компьютеры). У нас будет одна строчка "нераспределённая прибыль" или две? Прибыль от продажи компьютеров и прибыль от продажи слонов?
Считаем! Моя система позволяет её считать. За любой промежуток времени
Ой, всё.
Стоп. До сих пор вы говорили, что пассив — это источник денег. Причина их появления. А теперь вдруг «отложено на то-то» — это пассив. Как так? Вот допустим, у меня был полный ноль. Я получил наследство 1000 р. Стало: активы: кошелёк 1000 р., пассивы: наследство 1000 р. Окей, теперь допустим, я хочу отложить эти 1000 р. на чёрный день. Как это сделать? Переложить из пассива наследство в пассив чёрный день? Но тогда инфа о том, что деньги возникли из наследства, потеряется. А разве не для этого вы ведёте такой строгий учёт? Чтобы не терять инфу о том, откуда что возникло?
Пассивы нужны чтобы знать что это за активы. Почему они у нас, зачем они у нас и т.п. Это может быть откуда, это может быть «на что отложено» и т.п… Вот открываете вы кошелек, а там в два раза больше денег чем обычно. Вы к жене с вопросом. Жена говорит — это деньги на поездку на море, по дороге в булочную — забеги в тургаенство и купи билеты. Или говорит «а это я в лотерею выиграла». Или скажет «это прибыль от проданных помидор с дачи». Что бы она не сказала — она назовет статью пассива.
Ответьте на мой вопрос. Вот есть 1000 р., которые «наследство». И я хочу их теперь отложить на море. Как это сделать? Просто перетащить из пассива «наследство» в пассив «на море», так? Я пытаюсь понять. Но тогда потеряется информация о том, что это, вообще-то, наследство. А раз мы так запросто стираем эту информацию, зачем тогда было изначально это информацию хранить?
И опять-таки, что такое всё же пассив? Источник денег или куда я собираюсь их потратить? Ведь одни и те же деньги могут запросто иметь некий источник, и при этом иметь некую цель. Как в моём примере. Это и наследство, и деньги на море
И опять-таки, что такое всё же пассив? Источник денег или куда я собираюсь их потратить? Ведь одни и те же деньги могут запросто иметь некий источник, и при этом иметь некую цель. Как в моём примере. Это и наследство, и деньги на море
Теперь такой вопрос. Допустим, у нас есть бизнес, мы ведём его бухгалтерию. У бизнеса есть два направления (ну допустим, одно — это продавать слонов, другое — компьютеры). У нас будет одна строчка «нераспределённая прибыль» или две? Прибыль от продажи компьютеров и прибыль от продажи слонов?
Это уже к тому как вы учет построите. Да, по хорошему надо дробить. Причем не только прибыли и убытки а вообще всё. Я делаю раздельные бюджеты (балансы), и когда в одном направлении активов много, а в других есть в них потребность, то делаю «межбюджетный трансфер». Ну точнее есть «общак», а есть бюджеты направлений, и я забираю у доноров, и отдаю рецепиентам. В следующий период может быть наоборот.
Я, кажется, понимаю, в чём у нас непонимание. Вы хотите в пассивах хранить инфу о том, откуда взялись те или иные деньги. Я считаю, что это функция истории. Т. е. функция другой таблицы в БД. Есть БД с активами и, возможно, пассивами. А есть БД с историей проводок. И я до сих пор так считаю, это логично, блин. Активы и пассивы — это сколько у меня есть сейчас, сколько должен я и сколько должны мне. А не вся история того, откуда эти деньги взялись, как они увеличивались и уменьшались. Если как-нибудь там на примерах в следующей статье сумеете объяснить, как хранение истории в самих активах и пассивах может помочь, будет здорово. Я вижу здесь неправильное использование сущностей
Есть ещё один момент, по которому, как мне кажется, мы не согласны. Я считаю, что бухгалтерия должна отражать только то, что реально существует. То есть не должно быть ситуации, при которой вы подумали, приняли некое решение, и на основании одного только этого своего решения (а не реального события) внесли некое изменение в пассивы и активы.
Пример. Было 1000 р. Лично ваших. "Нераспределённая прибыль". Но тут вы решили, что надо отложить их на море. И "отложили", перенеся в пассив "отложено на море". В реальном мире ничего не произошло. И из кошелька вы их никуда не дели. А баланс изменился.
Другой пример. У вас два направления бизнеса. А физический счёт один. Потом вы решили сделать этот ваш "межбюджетный трансфер". Подумали, приняли решение. И сделали. Не изменив ничего в физическом мире, а лишь внеся своё решение в бухгалтерию.
Или пример из основного текста вашей статьи. Есть учредитель, у него есть бизнес. У него дела идут хорошо, "нераспределённая прибыль" растёт. Учредитель решает, раз она такая большая, увеличить "долг учредителю". За счёт "нераспределённой прибыли". Опять-таки, эта проводка есть лишь результат решения учредителя, никакого реального события не было.
Я ещё понимаю пример с кражей. Скажем, произошла кража, повисла в активе "кража". Потом долго думали, решили списать на охранника. И пересли в актив "долг охранника". Тут хотя бы понятно, что произошло: был относительно реальный актив, по которому был шанс получить его от воров. Но потом шанс исчез, и решили этот актив сконвертировать. Но что касается трёх примеров выше, у меня никакого оправдания им нет.
Вот этого всего быть не должно. Бухгалтерия должна отражать только физическую реальность и больше ничего ничего. Сущностей должно быть меньше. Бритва Оккама. KISS. Так логичнее, проще, лучше.
Все эти виртуальные перемещения не подтверждаются никакими реальными документами, проверить потом их потом, подняв документы, невозможно.
Поэтому я и предлагаю всевозможные виртуальные строчки типа "наследство", "долг учредителю", "нераспределённая прибыль" и так далее и тому подобное, убрать на фиг. Потому что они все виртуальные. И собственник бизнеса по желанию левой пятки может переносить между ними деньги туда-сюда, и за этими перемещениями не будет стоять никаких реальных действий. Захотел учредитель простить "долг учредителя" бизнесу — взял и простил. И т. д.
Бухгалтерия должна быть такой, чтобы бухгалтер, основываясь лишь на фактической информации, мог составить её единственным образом. В вашей же модели получается, что её можно (при одних и тех же реальных событиях) составить разными способами, но все они правильные. WTF?
Ещё момент: когда будете писать следующие статьи, напишите, как хранится история в реальных компьютерных бухгалтерских системах. В идеале приведите приведите упрощённую схему БД бухгалтерской системы, чтоб была какая-то инфа, от которой можно дальше плясать. Видимо, в реальных БД история всё же хранится, просто вы пока не объяснили, каким именно способом, отсюда и непонимание
Вот этого всего быть не должно. Бухгалтерия должна отражать только физическую реальность и больше ничего ничего.
С чего это вы так решили?
Для чего нужен баланс? Чтобы видеть общую картину финансов.
Ок. А для чего нам нужна эта общая картина? Повесить на стенку?
Или принимать решения? Решения как распоряжаться, решения как достигать тех или иных финансовых целей (шубу жене купить). Чтобы знать что мы их уже достигли и т.п.
А для этого нужно не только видеть что у нас в кошельке и что мы должны, но и текущую картину планирования. Мы можем ее менять, но видеть ее мы должны.
Например мы купили 100 слонов, за 100 рублей. Такое количество слонов нам удобно для нашего объема продаж и т.п. Ассортимент есть, запасы есть и т.п.
Потом мы продали 50 слонов за 100 рублей.
Итого у нас 50 слонов и 100 рублей.
Можем ли мы взять эти 100 рублей и на что-то потратить?
Можем, если очень надо, но по хорошему 50 рублей нам будут нужны для пополнения склада. Так что мы так и запишем «пассивный счет, фонд пополнения склада — 50 рублей». Ну и з/п через неделю выплачивать, так что еще 20 рублей стоило бы отложить на з/п. Так и запишем «фонд оплаты труда — 20 рублей». Ну и оставшиеся 30 рублей мы оставим себе на всякие возрастающие расходы, в распоряжении фирмы. Называть никак не будем, а просто на эту сумму увеличим капитал (долг перед учредителем).
При этом сами деньги есть, мы можем ими воспользоваться. Или не воспользоваться.
Например у нас подвернулась возможность купить жирафов со скидкой, и мы думаем — купить или не купить. Деньги есть, но стоит ли? Не окажется ли что потом они будут нужны в другом месте? В вашем варианте у вас просто есть 100 рублей и все. И думай гадай, можно их тратить или нет. А по хорошему видно, что 50 на слонов отложены, 20 на з/п, а 30 вполне свободны, их уже отдали как раз на такие вот нужды. И если цена хорошая, и товар ходовой, а зарплата скоро, то наверное можно взять рублей на 50. А слонов пока взять не на 50, а на 30. Выгода в жирафах будет больше, немного можно будет и с ограниченным ассортиментом поработать.
Ну или наоборот — взять из з/п ибо расчет не скоро, а слоны раскупаются быстро, и в крайнем случае всегда из оборота на зарплату найдем…
Конечно все планы и всю картину в баланс не засунуть, но общую картинку увидеть можно.
Я считаю, что бухгалтерия должна отражать только то, что реально существует. То есть не должно быть ситуации, при которой вы подумали, приняли некое решение, и на основании одного только этого своего решения (а не реального события) внесли некое изменение в пассивы и активы.
Решение — это тоже реальное событие.
Зашел за «текстом под звёздочкой» в заголовке, но не нашел его.
Что я сделал не так?
Что я сделал не так?
Всегда хотел спросить такую вещь. Вот начали мы вести учёт. У нас всё по нулям (мы ж только начали). И вот мы нашли 100 рублей. Как такое проводить?
Я спрашиваю таким образом именно потому, что «нашли 100 рублей» равносильно «украли 100 рублей», но с разными знаками. Вот только для задачи «нашли 100 рублей» можно задать те самые нулевые начальные условия.
Я спрашиваю таким образом именно потому, что «нашли 100 рублей» равносильно «украли 100 рублей», но с разными знаками. Вот только для задачи «нашли 100 рублей» можно задать те самые нулевые начальные условия.
Дт: Деньги в кошельке, Кт: Случайные доходы, 100руб
Кт: Случайные доходы, 100руб.
Ведь на самом деле, особого смысла в этом счету, как бы и нет. Это и не актив, и не пассив. Наличие такого счёта — побочный эффект двойной записи.
Ведь на самом деле, особого смысла в этом счету, как бы и нет. Это и не актив, и не пассив. Наличие такого счёта — побочный эффект двойной записи.
И да, и нет.
Нельзя назвать подобные счета просто артефактом двойной записи.
Это скорее «плод» системы учета. Не только двойной записи, но и дальнейшей работы.
Причем используются они не только и не столько для «слива» тех операций к которым сложно придумать какой-то счет, сколько как инструмент учета и планирования.
Ну вот отразили мы этот «случайный доход», висит он у нас на этом счете. Дальше что?
Дальше мы решаем что эти деньги пойдут на пьянку. Или решаем что потратим на рекламу. Но допустим на пьянку.
И сразу, как только решили:
Дт: «случайный доход», Кт: «пятничная попойка», 100руб
Ну а в пятницу уже
Дт: «пятничная пьянка», Кт: «кошелек», 100руб (ну или больше, если там было еще отложено).
Нельзя назвать подобные счета просто артефактом двойной записи.
Это скорее «плод» системы учета. Не только двойной записи, но и дальнейшей работы.
Причем используются они не только и не столько для «слива» тех операций к которым сложно придумать какой-то счет, сколько как инструмент учета и планирования.
Ну вот отразили мы этот «случайный доход», висит он у нас на этом счете. Дальше что?
Дальше мы решаем что эти деньги пойдут на пьянку. Или решаем что потратим на рекламу. Но допустим на пьянку.
И сразу, как только решили:
Дт: «случайный доход», Кт: «пятничная попойка», 100руб
Ну а в пятницу уже
Дт: «пятничная пьянка», Кт: «кошелек», 100руб (ну или больше, если там было еще отложено).
В целом пассив, как и украли — всегда может появиться владелец и потребовать назад.
Извините, если кто-то выше написал то же самое, а я не заметил.
Исторически у нас в СССР сложилось две практики бухучета — б/у предприятий и банковский б/у. На предприятиях обычной практикой было в течениемесяца квартала оформлять документы — ордера, авансы, накладные, приходы и расходы и т.д. согласно бюджета, но без отражения по счетам. То есть операции делались, а проводки не фиксировались. Рассчитывалась, к примеру, зарплата, заказывались деньги в банке — зарплата выплачивалась, ведомость по выплате клалась в ящик. И каждый конец квартала был аврал по оформлению квартального отчета. Из всех ящиков вытаскивались все накопившиеся бумажки, считались и записывались в Главную книгу, причем (в зависимости от бухгалтера, конечно) каждый раз главный бухгалтер переживал, сойдется у него баланс или не сойдется. Сколько из-за этого инфарктов было…
У банков же была классическая двойная запись — каждая операция отражалась по двум счетам одновременно и в тот же день. Фактически банки работали только утром, а во второй половине дооформляли документы и по каждому из них делали проводки.
Причина в столь разительной разнице в подходах проста — банки сдавали баланс в ЦБ каждый день, а предприятия в налоговую — ежеквартально.
Так вот, когда началась автоматизация бухгалтерии и банков, то одним программистам ставили задачи бухгалтера предприятий, а другим — банковские. Поэтому одни программисты реализововали документы с «полупроводками», т.е. с отражением по одному счету, а другие запрещали вводить документ, если в нем не было проводки (или нескольких) с двумя счетами и одной и той же суммой по обоим из них.
Та же история с активными и пассивными счетами. У некоторых бухгалтеров не было особого понимания, что одни являются естественным продолжением других. Главная книга (в смысле натурально КНИГА) их содержала в разных разделах. Поэтому при автоматизации бухгалтера ставили задачу «хочу видеть АКТИВ отдельно от ПАССИВА». Кто из программистов не повелся, тот молодец. Но многие сделали эти счета отдельными (некоторые даже вели их в разных таблицах) и положительными. Что из этого получилось — описано в статье.
Об остатках на счетах. Выше есть абсолютно верный комментарий, что остаток должен соответствовать счету на конец дня. Точка. Что происходит с ним в течение дня — вообще говоря, не проблема бухучета. Например, расчетный счет (пассивный) с овердрафтом в банке может в течение уходить в минус и возвращаться. Главное, чтобы на конец дня его остаток был кредитовый или ноль. За это в банках отвечает специальная процедура урегулирования овердрафта, причем эта процедура необязательно автоматическая, урегулирование может делать человек, вручную переводя деньги с/на ссудного счета.
И опогоде проводках. Изначально — да, проводки содержали два счета и одну сумму. Когда банки стали заниматься инвалютой, то оказалось, что конверсионные проводки плохо укладываются в этот шаблон — суммы в валюте счета по дебету и по кредиту не совпадали. Так как на тот момент нельзя было изменить структуру проводки, то ввели конверсионные счета. Для простой операции вместо одной проводки стало три (с учетом курсовой разницы), иногда четыре. Потом автоматизация улучшилась, и в одну проводку стало можно запихать не одну сумму, а точнее, две и более сумм в разных валютах финансовых инструментах. И не два счета, а 1:M или М:1. Главное, что должно было соблюдаться — равенство сумм в рублях РФ по дебету и кредиту. Ну и соответствие правилам бухучета, конечно, к примеру не стоило запихивать в одну проводку балансовые и внебалансовые счета.
Так вот, о чем же это я хотел сказать… А! На самом деле неважно, создаете ли вы полупроводки или полноценные проводки в момент осуществления операции, или вообще не отражаете операцию по счетам — главное, чтобы на конец дня у вас был полноценный правильный бухучет. По этой причине, а также для улучшения производительности «главную книгу» иногда делают в банках отдельной системой, а правила создания проводок выносят на промежуточный слой, который анализирует операцию и создает нужные проводки, пусть даже с временным лагом.
И бородатый анекдот в тему:
Исторически у нас в СССР сложилось две практики бухучета — б/у предприятий и банковский б/у. На предприятиях обычной практикой было в течение
У банков же была классическая двойная запись — каждая операция отражалась по двум счетам одновременно и в тот же день. Фактически банки работали только утром, а во второй половине дооформляли документы и по каждому из них делали проводки.
Причина в столь разительной разнице в подходах проста — банки сдавали баланс в ЦБ каждый день, а предприятия в налоговую — ежеквартально.
Так вот, когда началась автоматизация бухгалтерии и банков, то одним программистам ставили задачи бухгалтера предприятий, а другим — банковские. Поэтому одни программисты реализововали документы с «полупроводками», т.е. с отражением по одному счету, а другие запрещали вводить документ, если в нем не было проводки (или нескольких) с двумя счетами и одной и той же суммой по обоим из них.
Та же история с активными и пассивными счетами. У некоторых бухгалтеров не было особого понимания, что одни являются естественным продолжением других. Главная книга (в смысле натурально КНИГА) их содержала в разных разделах. Поэтому при автоматизации бухгалтера ставили задачу «хочу видеть АКТИВ отдельно от ПАССИВА». Кто из программистов не повелся, тот молодец. Но многие сделали эти счета отдельными (некоторые даже вели их в разных таблицах) и положительными. Что из этого получилось — описано в статье.
Об остатках на счетах. Выше есть абсолютно верный комментарий, что остаток должен соответствовать счету на конец дня. Точка. Что происходит с ним в течение дня — вообще говоря, не проблема бухучета. Например, расчетный счет (пассивный) с овердрафтом в банке может в течение уходить в минус и возвращаться. Главное, чтобы на конец дня его остаток был кредитовый или ноль. За это в банках отвечает специальная процедура урегулирования овердрафта, причем эта процедура необязательно автоматическая, урегулирование может делать человек, вручную переводя деньги с/на ссудного счета.
И о
Так вот, о чем же это я хотел сказать… А! На самом деле неважно, создаете ли вы полупроводки или полноценные проводки в момент осуществления операции, или вообще не отражаете операцию по счетам — главное, чтобы на конец дня у вас был полноценный правильный бухучет. По этой причине, а также для улучшения производительности «главную книгу» иногда делают в банках отдельной системой, а правила создания проводок выносят на промежуточный слой, который анализирует операцию и создает нужные проводки, пусть даже с временным лагом.
И бородатый анекдот в тему:
Устроился молодой бухгалтер на работу в одну контору. Хороший оказался специалист. Быстро начал в гору идти. Только вот у него странность одна была. Каждое утро он садился на свое рабочее место, отпирал ключиком тумбочку, выдвигал верхний ящик, заглядывал в него, снова запирал и приступал к работе. Шли годы. Он стал главным бухгалтером этого предприятия. Но каждое утро он заглядывал перед работой в тумбочку. Коллеги недоумевали, но в тумбочку заглянуть не решались, да и закрыта она была всегда. И вот, его проводили на пенсию. На следующее утро коллеги ринулись к его рабочему столу, взломали верхний ящик и увидели, что на его дне лежит бумажка, на которой написано крупными буквами:
"ДЕБЕТ — слева, КРЕДИТ — справа".
Спасибо за интересный экскурс в историю, но один момент вызывает у меня несогласие:
Есть еще третья категория б/у. Бюджетники. Эти звери по моему вообще проводки не разносят никогда. Работал в органе гос.власти. Был в куче разных комиссий, от инвентаризации до ликвидации. Этим зверям я бы оружие не дал. Годами бегают за автографами. То потеряли что-то, то вдруг всплыл акт передачи или накладная которую они три года назад забыли провести и теперь нужно переделать инвентаризации пары отделов за эти три года… При этом понимания законодательной базы нулевое — как в казначействе сказали так и делаем. Про основы бухучета, двойной записи и т.п. я молчу. Зазубренные шаблоны и всё. Внятное понимание процессов во всей структуре умерло с уходом на пенсию старого главбуха… Вот не надо им давать возможности «главное чтобы в конце дня сошлось». Не стоит.
Не подумайте, я не первыйдень замужем год в бизнесе. Я ничего не имею против приходящего бухгалтера разносящего пачку первички раз в неделю или даже раз в месяц (спасибо новым нормам по налоговым накладным). Но даже если наш приходящий бухгалтер будет с мозгами — пусть лучше целостность проверяется подокументарно. Так проще заметить ошибки, ведь если что-то «временно» пошло красным, то значит мы что-то не отразили, например не отразили что предприятие «одолжило» денег у работника или учредителя (под отчет дали меньше чем надо было или еще как). Или кто-то что-то прячет, и плохо спрятал. И не факт что прячет от налоговой, может и от учредителя прячет.
Ведь в реальной жизни красным ничего не бывает. Ведь фактически описанный вами овердрафт внутри дня это отдельный счет с кредитом, который работает только в рамках дня. Просто мы скрываем часть проводок, для простоты. Я даже наверное по итогу обсуждений смягчу свое отношение к активно-пассивным. А-п можно использовать, если в голове есть четкая картина того, что «на самом деле» это искусственная конструкция из двух счетов, и а-п у нас только для упрощения. Я также не против того чтобы целостность базанса и активного/пассивного счетов проверялась не после проводки а после всей транзакции/операции, хотя и предпочитаю чтобы это делалось за счет двойных «советских» проводок, и транзитных счетов операции, а не полупроводками. Но вот Но вот делать валидацию «в конце дня/недели/месяца» я против. Вполне можно проводить документы задним числом, только так, чтобы их последовательность выдавала валидные движения по счетам. Не пляшет — разложи в другом порядке, чтобы плясало. Иначе может статься что тасовать их придется в такой ситуации когда исправить что-то будет сложно (говорю как человек которому приходилось неоднократно бывать в кабинетах и УБЕП и налоговой полиции и всегда «сухим из воды»).
Об остатках на счетах. Выше есть абсолютно верный комментарий, что остаток должен соответствовать счету на конец дня. Точка. Что происходит с ним в течение дня — вообще говоря, не проблема бухучета. Например, расчетный счет (пассивный) с овердрафтом в банке может в течение уходить в минус и возвращаться. Главное, чтобы на конец дня его остаток был кредитовый или ноль. За это в банках отвечает специальная процедура урегулирования овердрафта, причем эта процедура необязательно автоматическая, урегулирование может делать человек, вручную переводя деньги с/на ссудного счета.
Есть еще третья категория б/у. Бюджетники. Эти звери по моему вообще проводки не разносят никогда. Работал в органе гос.власти. Был в куче разных комиссий, от инвентаризации до ликвидации. Этим зверям я бы оружие не дал. Годами бегают за автографами. То потеряли что-то, то вдруг всплыл акт передачи или накладная которую они три года назад забыли провести и теперь нужно переделать инвентаризации пары отделов за эти три года… При этом понимания законодательной базы нулевое — как в казначействе сказали так и делаем. Про основы бухучета, двойной записи и т.п. я молчу. Зазубренные шаблоны и всё. Внятное понимание процессов во всей структуре умерло с уходом на пенсию старого главбуха… Вот не надо им давать возможности «главное чтобы в конце дня сошлось». Не стоит.
Не подумайте, я не первый
Ведь в реальной жизни красным ничего не бывает. Ведь фактически описанный вами овердрафт внутри дня это отдельный счет с кредитом, который работает только в рамках дня. Просто мы скрываем часть проводок, для простоты. Я даже наверное по итогу обсуждений смягчу свое отношение к активно-пассивным. А-п можно использовать, если в голове есть четкая картина того, что «на самом деле» это искусственная конструкция из двух счетов, и а-п у нас только для упрощения. Я также не против того чтобы целостность базанса и активного/пассивного счетов проверялась не после проводки а после всей транзакции/операции, хотя и предпочитаю чтобы это делалось за счет двойных «советских» проводок, и транзитных счетов операции, а не полупроводками. Но вот Но вот делать валидацию «в конце дня/недели/месяца» я против. Вполне можно проводить документы задним числом, только так, чтобы их последовательность выдавала валидные движения по счетам. Не пляшет — разложи в другом порядке, чтобы плясало. Иначе может статься что тасовать их придется в такой ситуации когда исправить что-то будет сложно (говорю как человек которому приходилось неоднократно бывать в кабинетах и УБЕП и налоговой полиции и всегда «сухим из воды»).
Есть еще третья категория б/у. Бюджетники. Эти звери по моему вообще проводки не разносят никогда.
У меня пока обошлось, не встречался.
Ведь в реальной жизни красным ничего не бывает. Ведь фактически описанный вами овердрафт внутри дня это отдельный счет с кредитом, который работает только в рамках дня.
Я не очень понял про отдельный счет с кредитом. Когда оформляется овердрафт по расчетному счету, то ссудный счет к нему либо открывается сразу, либо при первой выдаче (погашения красного сальдо на расчетном счете). Или вы про что?
Просто мы скрываем часть проводок, для простоты.
Нет, мы их реально не делаем, потому что для них нет никаких оснований в течение дня. Представьте два предприятия, которые в течение дня должны рассчитаться друг с другом. У обоих по 10р. на счету, а взаимные долги по 100р. Если бы не было овердрафта, то они не могли бы рассчитаться никак, пока у одного из них не появятся средства извне.
С овердрафтом они рассчитаются, но на конец дня у них будет опять положительный остаток и выдачи кредита не происходит, новые проводки не появляются. Вот если один не заплатит, то у второго будет красное сальдо, недостача на счете — вот тогда появится проводка по выдаче кредита, которая обнулит остаток.
Нет, мы их реально не делаем, потому что для них нет никаких оснований в течение дня. Представьте два предприятия, которые в течение дня должны рассчитаться друг с другом. У обоих по 10р. на счету, а взаимные долги по 100р. Если бы не было овердрафта, то они не могли бы рассчитаться никак, пока у одного из них не появятся средства извне.
А что может помешать им просто взаимно простить друг другу 100 рублей долга, одним документом? Для этого не требуется офердрафт ни в бухгалтериях, ни в банке.
Или есть какие-то законодательные нормы, запрещающие такие соглашения между контрагентами?
А что может помешать им просто взаимно простить друг другу 100 рублей долга, одним документом? Для этого не требуется офердрафт ни в бухгалтериях, ни в банке.Ага. Давайте простую техническую процедуру заменим кучей бюрократии с привлечением инвесторов, учредителей, проведением головования и прочего. Отличное решение, чё.
Конечно если речь идёт о малых предприлятиях, где подобной бюрократии нет — то так будет проще, но в общем случае — нет.
Черт с ней с бюрократией, иногда это вообще не проблема. Но частенько клиринг в принципе невозможно избежать.
Реальный случай из жизни.
У меня был юрик. Приватная фин.установа.
У юрика дочка — фин.учреждение с лицензией.
Ну как дочка. У моего юрика было 99.99% акций, а остальное у нашего юриста, чтобы обойти требование о запрете на два юрика одного вида с одинаковым составом учредителей.
У дочки как водится минимальный уставной капитал довольно большой, а лиц.требования — 100% выплаченный уставной.
В результате я покупаю у одного нашего партнера акции одного завода по договорной цене за вексель.
Акции завода отдаю на комиссию торговцу. Торговец от своего имени продает их моей дочке.
В результате на этом этапе имеем:
Я должен дочке лям (уставной фонд).
Дочка должна торговцу лям (за поставленные акции).
Торговец должен мне лям (за мои акции).
Ну и мой долг по векселю, но он к делу не относится.
Если мы вот это вот закроем сверками и письмами, то нас потом возлюбят все. И нац.комиссия по ценным бумагам, и налоговая и кто угодно. Аффилированные операции и т.п. А клиринг или овердрафт закрывают все красиво и без вопросов.
У каждой стороны по две платежки с разными юриками, а дальше уже или ишак или падишах.
Реальный случай из жизни.
У меня был юрик. Приватная фин.установа.
У юрика дочка — фин.учреждение с лицензией.
Ну как дочка. У моего юрика было 99.99% акций, а остальное у нашего юриста, чтобы обойти требование о запрете на два юрика одного вида с одинаковым составом учредителей.
У дочки как водится минимальный уставной капитал довольно большой, а лиц.требования — 100% выплаченный уставной.
В результате я покупаю у одного нашего партнера акции одного завода по договорной цене за вексель.
Акции завода отдаю на комиссию торговцу. Торговец от своего имени продает их моей дочке.
В результате на этом этапе имеем:
Я должен дочке лям (уставной фонд).
Дочка должна торговцу лям (за поставленные акции).
Торговец должен мне лям (за мои акции).
Ну и мой долг по векселю, но он к делу не относится.
Если мы вот это вот закроем сверками и письмами, то нас потом возлюбят все. И нац.комиссия по ценным бумагам, и налоговая и кто угодно. Аффилированные операции и т.п. А клиринг или овердрафт закрывают все красиво и без вопросов.
У каждой стороны по две платежки с разными юриками, а дальше уже или ишак или падишах.
В нашем случае первым умер ишак...
В нашем случае первым умер ишак (нацкомиссия признала акции завода переоцененными), но было это после двух лет нормальной работы, мы сходим образом донаполнили устав и работали дальше. Ну а потом умер падишах — обанкротился наш западный партнер на котором была завязана вся деятельность. Причем перед этим нам крупно повезло. Буквально за месяц до краха — наемный директор дочки провел фактически рейдерский захват, опорочив нашу команду в глазах партнера. Разруливать не стали, мои партнеры психанули, мол «да как он мог в это все поверить, ну и пошел он». Ну и я соответственно написал банально дарственную на свою долю (100%) на этого хмыря. В результате у горе-рейдера разумеется не было «запаса плавучести», и он никак не смог разрулить свой кризис, и закончилось для него все банкротством обеих компаний и дисквалификацией от нац.комиссии (т.е. не быть ему больше директором фин.учреждения, да собственно с полученной от нас репутацией его и рядовым сотрудником мало кто возьмет). И да, от его банкротства никто из клиентов не пострадал.
вообще если еще более глобально, то операции в балансе должны отражать реальность, а не псевдореальность. В реальности произошел взаимозачет, как его не называй. В псевдореалности — залезание в долг, отдача, вторая отдача, закрытие долга. Про это вообще весь современный мировой бухучет (не в РФ).
Честно говоря, я не в курсе, как сейчас по законодательству.
Исходя из общих рассуждений — это теоретически возможно, но при условии отсутствия других обязательств у предприятий, особенно перед бюджетом, судом и т.п.
Во время кризиса неплатежей в 90-х взаиморасчеты делались все равно через банки — предприятия приносили реестры своих должников, те — своих и так далее. Если цепочка замыкалась, то расчеты по всем счетам проводились одним днем.
Исходя из общих рассуждений — это теоретически возможно, но при условии отсутствия других обязательств у предприятий, особенно перед бюджетом, судом и т.п.
Во время кризиса неплатежей в 90-х взаиморасчеты делались все равно через банки — предприятия приносили реестры своих должников, те — своих и так далее. Если цепочка замыкалась, то расчеты по всем счетам проводились одним днем.
Сейчас посмотрел документацию GnuCash. Так вот, как мне показалось, там такая же система, как и у меня. Т. е. там есть assets и есть liabilities, но они не соответствуют активам и пассивам в вашем понимании, это реальное имущество и реальные долги, и они совсем не обязательно друг другу равны. Если произошёл доход, то assets увеличивается и income (доход) тоже увеличивается. liabilities не трогаются. Всё, как у меня. Что на это скажете? В GnuCash дураки сидят?
Я не знаю как в ГнуКеш, и тем более как там «под капотом». И не собираюсь изучать. На все ваши вопросы ответили уже сто раз, что я что другие. Единственное что тут еще можно сделать
это написать статью с практическими примерами, но у меня все еще не хватает времени. Да и на них вы скажете, что мол ладно, но это только для бизнеса подходит.
это написать статью с практическими примерами, но у меня все еще не хватает времени. Да и на них вы скажете, что мол ладно, но это только для бизнеса подходит.
Свежая статья на гиктаймс по теме "бухгалтерия для программистов". Попросили дать ссылку.
Скажу сразу, автор описал все довольно поверхностно, и местами откровенно ошибочно, но ошибки такие которыми грешат многие «рядовые» бухгалтера. В отличии от моей статьи там намного больше терминов, а для более углубленного изучения можно уже сами термины гуглить.
В общем поскольку мое продолжение неизвестно когда будет (прошу простить, но дедлайн у меня явно до конца года затянется), то тем кому интересна классическая терминология — рекомендую.
Скажу сразу, автор описал все довольно поверхностно, и местами откровенно ошибочно, но ошибки такие которыми грешат многие «рядовые» бухгалтера. В отличии от моей статьи там намного больше терминов, а для более углубленного изучения можно уже сами термины гуглить.
В общем поскольку мое продолжение неизвестно когда будет (прошу простить, но дедлайн у меня явно до конца года затянется), то тем кому интересна классическая терминология — рекомендую.
Sign up to leave a comment.
Двойная бюстгалтерия* глазами программиста