Набираем в поисковике "Фундаментальная информатика и информационные технологии". Заходим на первую ссылку: https://mai.ru/education/fpmf/about_fiit/ Читаем, что там.
Ну, в простом случае можно сразу выполнить группировку без джойна и получить нужный датасет: GROUP_BY parent_id, acc_sub_id А что, если нужен отчет с несколькими уровнями группировок больше двух?
Пользователь сам решает какой счет использовать и с каким уровнем вложенности работать.
В проводках нельзя использовать счет, у которого есть потомки. Обязательно нужно указывать самый крайний счет. В вашей юрисдикции существует такое правило?
в данном случае генератор отчетов самостоятельно вычислит итоговые суммы по складам, субсчетам и счетам, а также итоговую сумму в целом по отчету. В вашем случае как выглядит запрос получения подобного датасета, если мы имеем несколько порядков субсчетов?
Да, в проводке хранится только самьій "низкий" уровень счета.
В проводках всегда должен указываться самый крайний субсчет, т.е. самого "низкого" порядка. Если в нашем случае мы для субсчета укажем NOT NULL,
acc_sub_id smallint NOT NULL,
то будет невозможно создать проводку без указания самого крайнего субсчета. СУБД сама будет нас защищать от создания ошибочной проводки, будет поднимать исключение. Для разных счетов может быть разное количество порядков, поэтому придется создавать отдельные журналы или книги. В вашем случае как выполняется защита от создания подобных неправильных проводок? Нужно всегда помнить, является ли счет крайним или нет?
Надо построить ЦОД в Беринговом проливе, холодное течение из Ледовитого океана будет охлаждать процессоры и давать электричество для ЦОДа. На Байкале начнут расти бананы. Здорово я придумал?
Мне кажется что разделение проводок по разным таблицам-журналам это неправильный подход.
Разные журналы могут иметь свой набор полей, который нужен только им.
Вы привязываетесь к номерам журналов и конкретному плану счетов. Они имеют свойство меняться. Я не знаком с этими номерами в РФ, но мне кажется номер журнала можно хранить в проводке. И изменение страны для которой происходит учет не должно влиять на структуру таблиц.
Да, конечно, я об этом думаю. Пока рассмотрел частный случай, для России.
Таблицу счетов можно сделать древовидной, а в таблице операций хранить только один счет, самого низкого уровня. И обороты по главному счету получать при помощи объединения с таблицей проводок.
Мне знакома такая терминология: синтетические счета - счета первого порядка, субсчета - счета второго порядка, субсчета могут быть разделены на свои собственные субсчета - счета третьего порядка и следующие порядков. Главный счет, я так понимаю - синтетический счет, а счета самого низкого уровня - это субсчета самого глубокого порядка? Правильно понимаю?
А с производительностью как в этом случае? Для получения регистров обычная группировка с агрегацией, мне кажется, быстрее будет работать.
дублирование всех полей на счет, субсчет, склад для дебета и кредита себе идея.
Я планирую рассмотреть использование вспомогательных журналов и/или книг для записи проводок. Для каждого счета можно сделать свой журнал со своим набором полей, которые нужны только для этого счета. Возможно, в этом случае дублирование уйдет.
С другой стороны, удобно обортную ведомость получать.
Прошу прощения, немного не в тему ответил. Сейчас, пока собирается информация какие поля нужны и какая структура данных нужна, наверное, преждевременно декларировать внешние ключи и т.д. Когда все более менее определится, то можно будет все и определить. Возможно, уже при создании моделей на SQLAlchemy.
Идентификатор операции - для того, чтобы связать все проводки имеющие отношение к одной операции. В данном случае, в синтетическом учете будет одна проводка, а в аналитическом учете три проводки получается: материал разложился на 2 субсчета и 2 склада. Кроме того, планируется рассмотреть использование вспомогательных журналов и книг.
А можно пример из реальной практики? Какие счета и субсчета использовались? Много ли найдется организаций, которым пришлось это выполнить? Можно же просто написать скрипт, который все это исправит.
По всем вопросам - я пока провожу исследования, изучаю эту область. На некоторые вопросы ответы в прошлой статье. Рассмотрение аналитического учета только началось.
Непонятно, что из этого материальные таблицы, а что представления и запросы.
Вообще, я планирую использовать ORM. Нужна поддержка миграций и кастомизации моделей. С ORM-ом это вроде делается проще.
Как-то не отражено соответствие и субсчетов, а если субсчета у субсчетов?
Счет в одном поле, субсчет в другом поле. Субсчета других порядков можно выполнить аналогично, в отдельных полях.
Как обеспечить ссылочную целостность аналитического учета, если "10" это склады и материалы, а "60" это поставщики?
Набираем в поисковике "Фундаментальная информатика и информационные технологии". Заходим на первую ссылку: https://mai.ru/education/fpmf/about_fiit/
Читаем, что там.
Хы-хы-хы.
Ну, в простом случае можно сразу выполнить группировку без джойна и получить нужный датасет:
GROUP_BY parent_id, acc_sub_id
А что, если нужен отчет с несколькими уровнями группировок больше двух?
Не совсем понял эту мысль. Можно подробнее?
Я опираюсь на такие определения: https://en.wikipedia.org/wiki/General_ledger и https://en.wikipedia.org/wiki/Ledger
Добавил реализацию со вспомогательными книгами:
https://github.com/nomhoi/empire-erp/blob/master/research/day4/README.md#step-2-%D0%B2%D1%81%D0%BF%D0%BE%D0%BC%D0%BE%D0%B3%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5-%D0%BA%D0%BD%D0%B8%D0%B3%D0%B8
Понятно. Про промежуточные итоги я написал выше, это выполняется генераторами. А join не увеличивает время выполнения запросов?
В проводках нельзя использовать счет, у которого есть потомки. Обязательно нужно указывать самый крайний счет. В вашей юрисдикции существует такое правило?
У вас есть такие отчеты, в которых выполняется агрегация по группам?
Например, в этом отчете выполняется группировка по полю Cust ID.
И здесь мы видим суммы для каждой такой группы.
Таких групп в одном отчете может быть несколько. В вашем случае как это можно выполнить? Т.е. как можно подготовить датасет для такого отчета?
Для многих генераторов отчетов, если нужно получить отчет с агрегацией по группам, нужно подавать датасет примерно в таком виде:
в данном случае генератор отчетов самостоятельно вычислит итоговые суммы по складам, субсчетам и счетам, а также итоговую сумму в целом по отчету.
В вашем случае как выглядит запрос получения подобного датасета, если мы имеем несколько порядков субсчетов?
В проводках всегда должен указываться самый крайний субсчет, т.е. самого "низкого" порядка.
Если в нашем случае мы для субсчета укажем NOT NULL,
то будет невозможно создать проводку без указания самого крайнего субсчета. СУБД сама будет нас защищать от создания ошибочной проводки, будет поднимать исключение.
Для разных счетов может быть разное количество порядков, поэтому придется создавать отдельные журналы или книги.
В вашем случае как выполняется защита от создания подобных неправильных проводок? Нужно всегда помнить, является ли счет крайним или нет?
А что сразу Chrome? Lynx не покатит, не?
Надо построить ЦОД в Беринговом проливе, холодное течение из Ледовитого океана будет охлаждать процессоры и давать электричество для ЦОДа. На Байкале начнут расти бананы. Здорово я придумал?
Спасибо, я посмотрю.
Разные журналы могут иметь свой набор полей, который нужен только им.
Да, конечно, я об этом думаю. Пока рассмотрел частный случай, для России.
Мне знакома такая терминология: синтетические счета - счета первого порядка, субсчета - счета второго порядка, субсчета могут быть разделены на свои собственные субсчета - счета третьего порядка и следующие порядков. Главный счет, я так понимаю - синтетический счет, а счета самого низкого уровня - это субсчета самого глубокого порядка? Правильно понимаю?
А с производительностью как в этом случае? Для получения регистров обычная группировка с агрегацией, мне кажется, быстрее будет работать.
Как-нибудь, дело дойдет, нарисую uml диаграммы.
Со вспомогательными журналами получается так:
https://github.com/nomhoi/empire-erp/tree/master/research/day4
Я планирую рассмотреть использование вспомогательных журналов и/или книг для записи проводок. Для каждого счета можно сделать свой журнал со своим набором полей, которые нужны только для этого счета. Возможно, в этом случае дублирование уйдет.
С другой стороны, удобно обортную ведомость получать.
Прошу прощения, немного не в тему ответил. Сейчас, пока собирается информация какие поля нужны и какая структура данных нужна, наверное, преждевременно декларировать внешние ключи и т.д. Когда все более менее определится, то можно будет все и определить. Возможно, уже при создании моделей на SQLAlchemy.
Идентификатор операции - для того, чтобы связать все проводки имеющие отношение к одной операции. В данном случае, в синтетическом учете будет одна проводка, а в аналитическом учете три проводки получается: материал разложился на 2 субсчета и 2 склада. Кроме того, планируется рассмотреть использование вспомогательных журналов и книг.
А можно пример из реальной практики? Какие счета и субсчета использовались?
Много ли найдется организаций, которым пришлось это выполнить? Можно же просто написать скрипт, который все это исправит.
Добавил ссылку на содержание цикла статей.
Добавляем поле для материалов.
По всем вопросам - я пока провожу исследования, изучаю эту область. На некоторые вопросы ответы в прошлой статье. Рассмотрение аналитического учета только началось.
Вообще, я планирую использовать ORM. Нужна поддержка миграций и кастомизации моделей. С ORM-ом это вроде делается проще.
Счет в одном поле, субсчет в другом поле. Субсчета других порядков можно выполнить аналогично, в отдельных полях.
Можно добавить поле - идентификатор операции.