Comments 61
Заметим, что в этом списке суммы проводок по дебету и кредиту хранятся в одном поле, сумма по дебету положительна, сумма по кредиту отрицательна.
При такой структуре становится неразличимой при поселедущем анализе сторнирующая запись по дебету от записи по кредиту и наоборот. При этом нельзя будет вычислить правильно вычислить обороты по кредиту и по дебету. Т.к. сторнирующая запись будет учитываться в не своем обороте.
В Ваше структуре есть некоторая избыточность. Достаточно таокй струткуры
Д-т К-т Сумма
1 11 100
1 11 -100
11 1 100 и т.п.
Хотя сразу скажу что проводки могут быть более сложные. Одна проводка и несколько счетов дебета. Одна проводка и несколько счетов кредита. И, возможно, одна проводка и одновременно несколько счетов дебета и кредита. Хотя последний случай наверное очень редкий. Во всяком случае 1с версии 7,7 такие проводки не допускала.
И, возможно, одна проводка и одновременно несколько счетов дебета и кредита. Хотя последний случай наверное очень редкий.
Этот случай не редкий, а невозможный, т.к. в таком случае становится неясно, какой дебет относится к какому кредиту. Иначе говоря, появляется многовариантность.
А по поводу сторно вы верно подметили.
Я, как раз, пробую выполнить насколько возможно обобщенную версию бухгалтерского учета, базовую версию. После этого для разных государств будут производные версии. Уже паттерн проектирования подобрал: State — Государство.
При такой структуре становится неразличимой при поселедущем анализе сторнирующая запись по дебету от записи по кредиту и наоборот. При этом нельзя будет вычислить правильно вычислить обороты по кредиту и по дебету. Т.к. сторнирующая запись будет учитываться в не своем обороте.
Спасибо за замечание. Я до оборотов пока не дошел. Буду разбираться с этой проблемой.
В Ваше структуре есть некоторая избыточность. Достаточно таокй струткуры
Д-т К-т Сумма
1 11 100
1 11 -100
11 1 100 и т.п.
В структуре класса Account?
Хотя сразу скажу что проводки могут быть более сложные. Одна проводка и несколько счетов дебета. Одна проводка и несколько счетов кредита.
Посмотрю этот момент.
И, возможно, одна проводка и одновременно несколько счетов дебета и кредита. Хотя последний случай наверное очень редкий. Во всяком случае 1с версии 7,7 такие проводки не допускала.
Возможна такая ситуация, например?
1 200
2 500
11 300
12 400У нас нет. В учебниках сложная проводка определяется как один ко многим. С точки зрения реализации если есть проводки типа один ко многим то будет та же структура что и многие ко многим. То есть если перейти к реляционным отношениям у вас будет строка таблицы проводка и с ней связаны несколько строк таблицы со счетами дебета и кредита и суммами.
Но это такая идеальная структура. В реальной структуре нужно предусматривать проблемы с производительностью. Чтобы не нужно для вычисления остатков было делать запросы за весь период работы системы. Эти и вопросами кстати занимались в 80е теоретики советского бухучета. Могу порекомендовать интереснейшую книгу Кузьминский Теория бухгалтерского учёта. Очень многое из того времени было забыто и выброшено. Что то вошло в такие продукты как 1с
Сложную проводку, вроде выше уже писали, можно разбить на простые. Отношение один ко многим.
Как будет выглядеть структура базы данных, это еще мы рассмотрим. На производительность обязательно будет обращать внимание.
Книгу посмотрю, спасибо.
Разбить сложную на простые это примерно как разбить слово по слогам. То есть можно но это не отменяет наличие сложных проводок.
Сложная проводка все равно в базу зайдет как несколько простых. У них будет общий идентификатор документа. Один-же документ у сложной проводки?
С моей точки зрения в структуру изначально нужно закладывать данные без условностей. Я лет 15 назад работал на заводе где ит-директор как бы назвали сейчас решил внедрять erp собственной разработки. Его идея была гениальной. Обкатать на своих erp а дальше стать миллионером на ее распространении. Короче знаний об организации производства у него не было. Хотя он считал что раз он ходит через проходную в свой отдел то он стало быть является экспертом в автоматизации производства. Через пять минут общения по поводу того как работать с его erp он зашёл в маленький тупик но тут же нашелся что нужно ввести условную деталь. Ещё через пять минут оказалось что нужно вводить условного рабочего а потом условную операцию, условный станок, условную партию, условное изделие и т.п. Собственно по этим же причинам часто буксуют и внедрения самых именитых erp. Нет надлежащей привязки к конкретной предметной области. Самая распространенная ловушка, которая описана кстати у Питеркина ещё лет 20 назад это наличие наряду с конструкторской ещё и технологической спецификации изделия, я уже не говорю непрерывном внесении изменений как в конструкторскую так и в технологическую документацию а также разрешения на отклонения от технологической и конструкторской документации. А увы без всего этого наполнения erp будет такой себе чисто воображаемой конструкцией.
Если отвечать конкретно на поставленный вопрос от можно больше вопросов получить чем ответов. Поэтому собственно каждое решение это компромис.
Я бы не ста нагружать еще слово документ лишней нагрузкой а взял бы на вооружение слово хозяйственная операция (кстати в 1с старых версий так и было. Был документ и с ним могла быть связана операция а могла и не быть связана)
Дальше возникает вопрос принципиальный нужно и хранить в базе реально двойную запись. То есть одну строку для дебета и одну строку для кредита. Многие теоретики автоматизации бухучета в 70-е годы пришли к выводу что это излишне. Поэтому достаточно хранить запись вида
№ хоз. оп. Счет дебета Счет кредита Сумма
Например (номера счетов взяты с потолка)
1 — 10 — 11 — 100
1 — 10 — 12 — 20
Это так для сложной проводки получится
1с прежних версий хранил даже так сложные проводки
1 — 10 — пусто — 120
1 — пусто — 11 — 100
1 — пусто — 12 — 20
Как вы понимаете оба не очень красивые особенно 2-й.
Первый вариант хотя бы обеспечивает сходимость сумм по дебету и кредиту т.к. сумма собвенно одна
Если хранить операции в более клссическом с точки зрения реляционных баз виде
№ Счет Это дебет? Сумма
1 — 10 — Дебет — 120
1 — 11 — Кредит — 100
1 — 12 — Кредит — 20
Тоже плохо т.к для операций с одним номером должно выполнятся равенство сумм дебета и кредита, а это никак не обеспечивается на уровне данных (в отличие от предыдущего варианта)
Чем дальше в лес тем больше компромисов.
Нужно сразу иметь в виду что вычисление остатков на счете суммированием всех значений от начала и до конца будет операцией весьма накладной. Если таких записей миллиарды. Поэтому как правило или не заморачиваются (когда это еще будет столько записей и мы уже оплату всю получим) или же делают промежуточные итоги например на начало/конец месяца. Но тут опять все становится еще более зависимым. Нужно корректно блокировать базу на чтение/запись, учитывать возможность правок "задним числом". Короче люди на этой теме диссертации защищают. А суперкрасивого решения пока нет.
Т.е. все что надо дебетовать дебетуем из suspense в котором 0 на балансе
все счета что надо кредитовать кредитуем из того-же suspense и сальдо на suspense должно быть 0
если сальдо не 0, тогда проводка не сбалансирована
При такой структуре становится неразличимой при поселедущем анализе сторнирующая запись по дебету от записи по кредиту и наоборот. При этом нельзя будет вычислить правильно вычислить обороты по кредиту и по дебету. Т.к. сторнирующая запись будет учитываться в не своем обороте.
Можно добавить поле в таблице для установки специального флага для таких записей, чтобы они не учитывались при составлении оборотной ведомости. Добавить Boolean поле будет дешевле, чем еще одно Decimal поле. Другой вариант: добавить в Account поля для оборотов для их подсчета сразу при добавлении записей на счет и при добавлении сторно правильным образом эти обороты обновлять.
Остаток на активном счету может быть только по дебету.
Остаток на пассивном счету может быть только по кредиту.
Остаток на активно-пассивном счету может быть и по дебету и по кредиту.
У вас причина и следствие поменяны местами.
Если по счету возможен только дебетовый остаток, такой счет называется активным.
И т.д.
А, по-моему, без разницы. Существуют активные счета. Активные счета обладают определенными свойствами.
Я с бухгалтерией раньше не имел дела. Вот только изучаю. Буду признателен за любые замечания и предложения.
Хорошо, я не буду спорить, почитаю ваши книги.
Если вы начинающий, рекомендую «Бухучет за 20 минут» и «Понимаете ли вы бухгалтерский учет?».
Спасибо, посмотрю. Я пока смотрел такие курсы:
http://www.finbuh1c.ru/
https://www.accountingcoach.com/
Вы уж извините, но читать лекцию на эту тему мне недосуг. Да это и долго.
Есть две такие интересные дисциплины: история бухучета и теория бухучета. Не думаю что они сильно помогают практическим бухгалтерам в их повседневной практике. Но для тех кто хочет получить представление о системе бухучета вцелом для разработки армов бухгалтера я бы очень рекомендовал.
А активно-пассивный? :)
Активно-пассивные счета возникают для отражений операций товар деньги товар. Они характеризуются разницей во времени предоплата и постоплата а также результатом прибыли или убытки. От этого и возникает вот эта двойственность. По своему смыслу эти счета очень близки к пассивным. О.кю на них не учитывается активы а источники. Например поставщик поставил нам материалы и мы отразили в активах эти материалы и тот факт что источником финансирования этих материалов является наша задолженность перед поставщиком. Или противоположный случай мы сделали предоплату маткриало и списали деньги с активов. И возникает уже долг поставщика перед нами. Поэтому остаток может быть как на дебета так и на кредите.
Например, пришел товар от поставщика: одновременно увеличился активный 41 счет (пришло что-то материальное) и так же увеличился 62 счет — мы стали «должны» поставщику денег за товар. Заплатим деньги с «материального» 51 счета и наш «долг» закроется.
Когда только начинаешь изучать бух. учет бывает очень полезно спрашивать себя «можно ли это потрогать?». Если можно — счет точно активный, ставим его в Дт или Кт в зависимости от того, плюс это или минус. Ну а корр. счету остается незанятое место в проводке
активы — это то, что можно «потрогать руками», пассивы — это обязательство (очень упрощенно: долги)… очень полезно спрашивать себя «можно ли это потрогать?». Если можно — счет точно активный
Это правило помогает не всегда. Мне не помогло, например, понять счёт «Уставный капитал». Собрались учредители, внесли уставный капитал. Он формирует денежное имущество фирмы, на эти средства фирма теперь может что-нибудь закупить. Однако, в плане счетов этот счёт является пассивным. Я так и не понял, почему. Ведь, казалось бы, в результате этих взносов никаких долговых обязательств не сформировалось; материальных ценностей во владении фирмы прибыло. Почему пассивный?
Это типа долговых обязательств перед учредителями.
Другая ситуация: если акционеры решат реинвестировать прибыль, то ту часть, которую они реинвестируют, в пассивах переведут со счета нераспределенной прибыли на счет «прибыль от прошлых финансовых периодов». Этот счет эквивалентен уставному капиталу и обозначает задолженность компании перед учредителями.
Таким образом активные счета это «что у нас есть», а пассивные «кому мы это должны (себе или внешним кредиторам)». Особенно важно помнить что в активных счетах могут быть и совсем нематериальные вещи. Например, если вы оказываете услугу, то на самом деле в первую очередь возникает долг перед покупателем (пропущенный этап в объяснении выше) и только потом, после оплаты, этот долг превращается в сумму на счету в банке. То есть между оказанием услуги и оплатой существует актив «долговые обязательства».
Например, если вы оказываете услугу, то на самом деле в первую очередь возникает долг перед покупателем (пропущенный этап в объяснении выше) и только потом, после оплаты, этот долг превращается в сумму на счету в банке.
Вроде долг перед покупателем образуется в том случае, если покупатель оплатил, а услуга еще не оказана. После оказания услуги долг исчезает.
Если была указана услуга до оплаты, до долг у покупателя до оплаты услуги.
- Принес деньги — положили их в банк на 51 — в корреспонденции остался УК как «обязательство» перед учредителем за эти деньги
- Принес компьютер — положили его в Основные средства (на самом деле нет). В корреспонденции опять УК, который явно оказывается пассивом.
В общем, надо к проводке все сводить, тогда становится понятнее
Если слово обязательства заменить на слово источники то все будет понятнее
Ничего не поменяно и не перепутано. Тип счёта и, соответственно, область допустимых значений для остатка на нём определяются же не по факту, а по плану. Или у вас возможна ситуация, когда два года некоторый счёт был активным, а на третий год знак остатка сменился и счёт стал активно-пассивным?
Задача стоит исследовать все свойства бух-учета. Без понимания этих вещей получается не обойтись.
Я не совсем понял цель проекта. Специально зашел на Гит, еще на какой то сайт. Это разработка 1С на Python? Цель проекта, образовательная? Это как изучать андроид накидывая блоки, только в бухгалтерский учет? Или на выходе должен быть полноценный Framework? Тогда без указания, что такое операция, и что такое проводки внутри операции, только еще больше запутывают.
Для себя определил так.
Вначале статьи все уже написано.
Я в статье написал, что даты, описания и прочая информация пока опускается для упрощения задачи. Важно было вначале понять, как формируются счета и баланс без лишней писанины.
Нет, пока по условиям задачи на начало периода остатков нет.
Скажем, это должны быть остатки по разным клиентам?
Можно посмотреть алгоритм с использованием SQL в новой статье: https://habr.com/ru/post/568192/. Можно сначала внести остатки на начало периода, смотрите 2 шаг.
Но я первым делом вижу отсутствие аналитики.
Т.е. получается, что для взаиморасчетов — для каждого клиента надо заводить свой субсчет?
А для материалов на складах — для каждого склада и каждого вида материалов на этом складе — тоже свой субсчет?
Тогда, в частности, будет либо очень сложно найти полный остаток данного материала по всем складам, либо все остатки материалов по данному складу.
Сейчас разбираюсь с аналитическим учетом, будет в следующей статье. Пока только с синтетическими счетами: https://habr.com/ru/post/568192/
Empire ERP. Занимательная бухгалтерия: главная книга, счета, баланс