powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура таблицы бухгалтерских проводок не дает покоя !!!!
18 сообщений из 43, страница 2 из 2
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #32361281
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По плоскости учета:
Если выплнить:
select Stuff, sum(Active),Sum(Passive),Sum(debet),Sum(Credit) from kernel.Account group by Stuff

то всегда sum(Active)=Sum(Passive) и Sum(debet)=Sum(Credit)
грубо говоря в этой модели можно вести балны 4 000 000 000 предприятий.

А что касается какие счета открывать для договора и как - мне не ясно...
Я должен сначала понять что за договор

Если вот это: таблица, то
>Doc_id int, - ID документа
>Agr_id int, - ИД договора <- убей не пойму что делает тут это поле
>TDate datetime, - дата проводки
>DACC varchar(10), дебетный счет
>KACC varchar(10), - кредитный счет
>TCurr varchar(3), - валюта
>TSum money, - сумма
>TSumRUB money - сумма в базовой валюте


по мне так нужно несколько таблиц
1) Собственно договор
2) Клиент по договору->(Таблицы схемы CRM)
3) Свойства/сущности догвора (параметры которые буишь учитывать) ->(1:N)->kernel.Accounts
4) Справочник типов операций с договором
5) Таблица операций ->(1:1)-> kernel.Document->(1:N)->kernel.Trn

в общем все очень просто....
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #32361717
Dennis_L
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Насчет stuff теперь более менее понятно, это для разделения всего что есть б базе на разные фирмы так скажем или филиалы там ...

>Agr_id int, - ИД договора <- убей не пойму что делает тут это поле

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

Например проводки :

Код: plaintext
1.
2.
3.
4.
5.
Tran_id, Doc_id, Agr_id, TDate,        DACC, KACC, TCurr, TSum, TSumRUB
 1              4       10       10 . 12 . 2003    2350     1360    USD    100        3000 
 2              4       10       10 . 12 . 2003    6450     1360    USD    200        6000 
 3              4       15       12 . 12 . 2003    1360     4560    EUR     50        170 
 4              5       16       11 . 12 . 2003    2350     1360    EUR    100        3400    


И потом надо получить остатки на счете 1360 разбитые по договорам тоесть по Agr_id (GROUP BY Agr_id). Кроме этого надо получать остатки на всех счетах для одного договора или просто просмотреть все проводки связанные с одним договором (WHERE Agr_id=X). Также часто надо делать группировки по другим параметрам догвора тоесть вначале JOIN c таблицей Agrs а потом GROUP BY Agrs.Type или что то в этом роде.
Для одного документа теоретически могут быть сделаны проводки которые относяться к разным договорам ...
В этом случае я считаю что Agr_id хранит аналитику счета 1360 или 2350 например.

Теперь мне надо сделать это в более общем случае когда есть не только договоры но и другие аналитики ... вот вобщемто и вся проблема. Кроме этого в преведущей схеме проводка содержала только одну аналитику для обоих счетов потому если аналитики у счетов разные то надо делать две проводки используя промежуточный счет.
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #32361857
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вопрос:
А может быть проводка между договорами?
Или..перефразируем - документ(проводка) относящаяся к нескольким договорам?
>Agr_id int, - ИД договора <- убей не пойму что делает тут это поле

Вообще, в бухгалтери есть только 4 вида отчетов:
1) оборотная ведомость (баланс)/Частный случай - сальдовая ведомость
2) журнал движения остатков
3) выписка по счету
4) журнал проводок
Все остальные отчеты - производные от этих четырех...

Собственно договор - это совокупность нескольких аналитических счетов.
И получить все операции/проводки - довольно элементарно....
...
Рейтинг: 0 / 0
Период между сообщениями больше года.
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33056734
valmond
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Уважаемый gardenman.
Времени прошло много с того момента, когда Вы описывали структуру БД для двойной записи.

Не внесла ли жизнь корректировок в эту структуру? Может есть чего добавить?


И еще хотел попросить, если это не комм. тайна, то может Вы можете показать как у Вас план счетов был устроен?

Заранее спаибо.
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33056900
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Все то, что здесь было написано - довольно оптимально, но как вы знаете предела совершенства нет. И в этой схеме многие вещи можно улучшить.
Этими вещами я уже не занимаюсь несколько лет. Могу разве что выслать работающий прототип (черновик) подобной системы сделанный для DB2.
Опять же в той же самой DB2 появилась с тех пор куча усовершенствований, а в этой схеме их нет.

Что касается плана счетов - это отдельная история. и мне как-то влом описывать как и что должно работать. Я за это не возьмусь. Эт слишком долго и бесплатно. так что - фантазируйте сами.
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33057145
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dennis_LПро то что в каждочасти базы может быть куча таблиц это понятно но в итоге все равно там есть таблица основных объектос с уникальным ID. И я пытаюсь решить как лучше этот самый ID связывать с бугалтерией тоесть с таблицей проводок ...особо много тут исовать и писать ненадо если придумать стандартную схему по которой связывать .... тоже самое что в этих несколькх таблицах можно описывать любые проводки в форме двойной записи ....

Честно про плоскости учета так и немогу въехать еще подумаю .... я это все делал до этого гораздо более упращенно вроде :

Doc_id int, - ID документа
Agr_id int, - ИД договора
TDate datetime, - дата проводки
DACC varchar(10), дебетный счет
KACC varchar(10), - кредитный счет
TCurr varchar(3), - валюта
TSum money, - сумма
TSumRUB money - сумма в базовой валюте

вот и все .... в принципе примерно этой же схемы я бы и хотел придерживаться и все вопросы связаны с полям и Agr_id (и возможно Doc_id)
варианты : 1. Analyt1_id, Analyt2_id ...
2. DAnalyt1_id, DAnalyt2_id ... KAnalyt1_id, KAnalyt2_id ...
3. Таблица TransAnalyt (Trans_id, Analyt_id, AnalytType ...)
4. возможно еще что то ...

продрузамеваеться что будет таблица где будут все возможные аналитические счета : Analytics (Analyt_id, Type, Descr, Sys_id ...)
и нуда будет помещатся все что может быть аналитиками для счета вроде

1 'A' 'AB16726', 100 - договор номер AB16726 с Agr_id=100 в таблице Agrs
2 'A' 'AV83274', 234 - договор номер AV83274 с Agr_id=234 в таблице Agrs
3 'S' 'Mazda 6', 100 - основное средство Mazda 6 с Asset_id=234 в таблице Assets
4 'U' 'Иванов', 4 - Работник Иванов с Employee_id=4 в таблице Employees

и т.д.

Есть вариант не делать такую общую таблицу а указвать тип объекта и его ID напрямую в проводке вместо Analyt_id - > Type , Sys_id - используя то что везде P.k. это int или smallint

Какие будут мнения насчет приведенных схем ?
В проводке указывается аналитический разрез дебет, аналитический разрез кредит. Аналитический разрез - это комбинация значений аналитических признаков типа Разрез1=(товар А на складе Б). Разрез естественно участвует в разных проводках. Вопрос, как хранить разрез. Две тактики:
Статическое назначение колонок. Данная колонка разреза может относиться только к одному типу объекта, справочнику (5-я колонка - товар, используется счетами С1 и С4), тогда можно пользоваться FK, запросы проще, но изменение структуры аналитики - это изменение не только словаря системы но и структуры таблицы.
Динамическое назначение колонок. (5-я колонка - товар для счета С1, но договор для счета С2). Динамический вариант реализован например во ФЛАГМАНе. Конечно, тексты запросов также динамические и достаточно длинные, но система универсальна.
Если вы делаете систему для конкретного заказчика и разрезов в пределах 15 я бы рассмотрел статический вариант.
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33057152
valmond
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
gardenmanМогу разве что выслать работающий прототип (черновик) подобной системы сделанный для DB2.

Что касается плана счетов - это отдельная история. и мне как-то влом описывать как и что должно работать. Я за это не возьмусь.

В работающем прототипе план счетов же присутствует?
Если Вам не сложно, то пришлите прототип. И без комментариев это будет, я думаю, ценно. (прошу только базу в виде скриптов т.к. DB2 нет)

valmond##gmail.com

Заранее спасибо.
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33057160
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в прототипе плана счетов нет.
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33057174
valmond
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
gardenmanв прототипе плана счетов нет.

Жалко конечно, но буду признателен и за то, что есть.
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33284589
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelR
В проводке указывается аналитический разрез дебет, аналитический разрез кредит. Аналитический разрез - это комбинация значений аналитических признаков типа Разрез1=(товар А на складе Б). Разрез естественно участвует в разных проводках. Вопрос, как хранить разрез. Две тактики:
Статическое назначение колонок. Данная колонка разреза может относиться только к одному типу объекта, справочнику (5-я колонка - товар, используется счетами С1 и С4), тогда можно пользоваться FK, запросы проще, но изменение структуры аналитики - это изменение не только словаря системы но и структуры таблицы.
Динамическое назначение колонок. (5-я колонка - товар для счета С1, но договор для счета С2). Динамический вариант реализован например во ФЛАГМАНе. Конечно, тексты запросов также динамические и достаточно длинные, но система универсальна.
Если вы делаете систему для конкретного заказчика и разрезов в пределах 15 я бы рассмотрел статический вариант.

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

А наделать всякоразных аналитических представлений, это не проблема.
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33284869
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mcureenab
Полагаю, красивым решением будет создать для каждого типа хозяйственных операций свою таблицу, со своей структурой, которая наилучшим образом соответсвует содержанию данного типа операций.

А наделать всякоразных аналитических представлений, это не проблема.
Новый тип хозоперации - ежедневная рутина, и менять в таком темпе структуру таблиц продакшн системы ... Боюсь, бухгалтера и ДБА не оценят.
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33292491
strizh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для разных хозопераций надо делать таблицы первичных бухгалтерских документов - на каждый тип свою. А таблица проводок должна быть все же универсальной.
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33293091
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тоже иногда думаю про про водку . В моем случае все обстоит полегче в силу универсальной структуры справочника объектов учета.
Теперь примеряю связь проводки со ссылками на объекты учета и запетлял вот такую декларацию:
Код: plaintext
1.
2.
3.
4.
.............
OBJ_D BIGINT [ 1 : 1000000000 ] NOT NULL,
OBJ_D BIGINT [ 1 : 1000000000 ] NOT NULL,
.............
и подумалось мне, что вполне это может быть востребовано, т.е. когда на одной стороне проводки, скажем, "Дебет", исользуется одна ссылка на объект, или, выражаясь в терминах 1С, "Субконто", а на другой стороне проводки, таких ссылок многие тысячи. Разумеется в обычных хоз.операциях это не нужно, но я могу захотеть родить некую исследовательскую операцию (на небалансовых счетах), с целью получения многомерного анализа своих данных и, сохраню результат в этом компактном виде, т.е. в виде такой асимметричной проводки. Приведенные декларации относятся к Interbase и компилируются без проблем и, насколько мне известно, пространство под массив выделяется только по факту его использования, т.е. здесь обозначены допустимые граница. Таким образом мы имеем: Произвольное количество субконто в проводке; каждое субконто может иметь произвольный уровень иерархии объектов; каждая проводка может(если нужно) иметь индивидуальную конфигурацию. Проводка получается компактной. Собираюсь еще поставить ссылку(наверное тоже нужен массив), котор. будет указывать на скрипт, которым она сгенерирована и котор. лежит в базе (используется FastScript). Хотелось бы услышать критические замечания в плане методологии учета произвольных фактов или может ссылки в те "места" , где это более уместно обсудить
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33296595
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Programmer_Ortodox
и подумалось мне, что вполне это может быть востребовано, т.е. когда на одной стороне проводки, скажем, "Дебет", исользуется одна ссылка на объект, или, выражаясь в терминах 1С, "Субконто", а на другой стороне проводки, таких ссылок многие тысячи. Разумеется в обычных хоз.операциях это не нужно
Различное количество аналитик это очень часто используется именно "в обычных хоз.операциях" Например корреспонденция между 50-ым кассой, вообще без аналитики и 76-расчетами с дебиторами/кредиторами с аналитикой Лицо, Тип услуги, Документ основания и пр.

Хранение субконто в качестве массива имеет свои минусы, например сложность с выдачей остатков в разрезе определенной аналитики, например получить остатки по 76 счету в разрезе Лиц в виде
SUM, CLIENT_ID, "Наименование клиента"

2-ое достаточно сложно организовать проверку обязательности заполнения значения субконто, в зависимости от того на какой счет идет проводка. А проверка должна быть обязательно иначе невозможно будет получить данные в разрезе аналитики.
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33297519
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Estets Programmer_Ortodox
и подумалось мне, что вполне это может быть востребовано, т.е. когда на одной стороне проводки, скажем, "Дебет", исользуется одна ссылка на объект, или, выражаясь в терминах 1С, "Субконто", а на другой стороне проводки, таких ссылок многие тысячи. Разумеется в обычных хоз.операциях это не нужно
Различное количество аналитик это очень часто используется именно "в обычных хоз.операциях" Например корреспонденция между 50-ым кассой, вообще без аналитики и 76-расчетами с дебиторами/кредиторами с аналитикой Лицо, Тип услуги, Документ основания и пр.

Хранение субконто в качестве массива имеет свои минусы, например сложность с выдачей остатков в разрезе определенной аналитики, например получить остатки по 76 счету в разрезе Лиц в виде
SUM, CLIENT_ID, "Наименование клиента"

2-ое достаточно сложно организовать проверку обязательности заполнения значения субконто, в зависимости от того на какой счет идет проводка. А проверка должна быть обязательно иначе невозможно будет получить данные в разрезе аналитики.
Различное, в данном случае, это единицы, тысячи, миллионы. Это вынуждает радикально пересмотреть структуру таблицы проводок. Ведь не будете же вы резервировать в проводке миллионы субконто?
PS
Мне все таки кажется, что подобные сингулярности в учете(в самом широком его понимании) могут иметь массу вкусностей!
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33297524
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Картинку приложил для иллюстрации собсно объекта обсуждения.
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33297755
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Переменное число аналитик у счета и переменное число объетов проводке - разные вещи. Автор по-моему про второе : в одной проводке и сахар на склад 1 и пиво на склад 2.
Обсуждалось...
...
Рейтинг: 0 / 0
Структура таблицы бухгалтерских проводок не дает покоя !!!!
    #33298008
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Естественно, о проводке и речь, как о некотором факте
...
Рейтинг: 0 / 0
18 сообщений из 43, страница 2 из 2
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура таблицы бухгалтерских проводок не дает покоя !!!!
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]