Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
По плоскости учета: Если выплнить: 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 в общем все очень просто.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2003, 17:57 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
Насчет stuff теперь более менее понятно, это для разделения всего что есть б базе на разные фирмы так скажем или филиалы там ... >Agr_id int, - ИД договора <- убей не пойму что делает тут это поле Это поле показывает что данная конкрентная проводка относиться к конкретному договору. Например проводки : Код: plaintext 1. 2. 3. 4. 5. И потом надо получить остатки на счете 1360 разбитые по договорам тоесть по Agr_id (GROUP BY Agr_id). Кроме этого надо получать остатки на всех счетах для одного договора или просто просмотреть все проводки связанные с одним договором (WHERE Agr_id=X). Также часто надо делать группировки по другим параметрам догвора тоесть вначале JOIN c таблицей Agrs а потом GROUP BY Agrs.Type или что то в этом роде. Для одного документа теоретически могут быть сделаны проводки которые относяться к разным договорам ... В этом случае я считаю что Agr_id хранит аналитику счета 1360 или 2350 например. Теперь мне надо сделать это в более общем случае когда есть не только договоры но и другие аналитики ... вот вобщемто и вся проблема. Кроме этого в преведущей схеме проводка содержала только одну аналитику для обоих счетов потому если аналитики у счетов разные то надо делать две проводки используя промежуточный счет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2003, 10:54 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
Вопрос: А может быть проводка между договорами? Или..перефразируем - документ(проводка) относящаяся к нескольким договорам? >Agr_id int, - ИД договора <- убей не пойму что делает тут это поле Вообще, в бухгалтери есть только 4 вида отчетов: 1) оборотная ведомость (баланс)/Частный случай - сальдовая ведомость 2) журнал движения остатков 3) выписка по счету 4) журнал проводок Все остальные отчеты - производные от этих четырех... Собственно договор - это совокупность нескольких аналитических счетов. И получить все операции/проводки - довольно элементарно.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2003, 12:00 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
Уважаемый gardenman. Времени прошло много с того момента, когда Вы описывали структуру БД для двойной записи. Не внесла ли жизнь корректировок в эту структуру? Может есть чего добавить? И еще хотел попросить, если это не комм. тайна, то может Вы можете показать как у Вас план счетов был устроен? Заранее спаибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2005, 10:26 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
Все то, что здесь было написано - довольно оптимально, но как вы знаете предела совершенства нет. И в этой схеме многие вещи можно улучшить. Этими вещами я уже не занимаюсь несколько лет. Могу разве что выслать работающий прототип (черновик) подобной системы сделанный для DB2. Опять же в той же самой DB2 появилась с тех пор куча усовершенствований, а в этой схеме их нет. Что касается плана счетов - это отдельная история. и мне как-то влом описывать как и что должно работать. Я за это не возьмусь. Эт слишком долго и бесплатно. так что - фантазируйте сами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2005, 11:20 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
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 я бы рассмотрел статический вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2005, 12:35 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
gardenmanМогу разве что выслать работающий прототип (черновик) подобной системы сделанный для DB2. Что касается плана счетов - это отдельная история. и мне как-то влом описывать как и что должно работать. Я за это не возьмусь. В работающем прототипе план счетов же присутствует? Если Вам не сложно, то пришлите прототип. И без комментариев это будет, я думаю, ценно. (прошу только базу в виде скриптов т.к. DB2 нет) valmond##gmail.com Заранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2005, 12:38 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
в прототипе плана счетов нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2005, 12:40 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
gardenmanв прототипе плана счетов нет. Жалко конечно, но буду признателен и за то, что есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2005, 12:45 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
ModelR В проводке указывается аналитический разрез дебет, аналитический разрез кредит. Аналитический разрез - это комбинация значений аналитических признаков типа Разрез1=(товар А на складе Б). Разрез естественно участвует в разных проводках. Вопрос, как хранить разрез. Две тактики: Статическое назначение колонок. Данная колонка разреза может относиться только к одному типу объекта, справочнику (5-я колонка - товар, используется счетами С1 и С4), тогда можно пользоваться FK, запросы проще, но изменение структуры аналитики - это изменение не только словаря системы но и структуры таблицы. Динамическое назначение колонок. (5-я колонка - товар для счета С1, но договор для счета С2). Динамический вариант реализован например во ФЛАГМАНе. Конечно, тексты запросов также динамические и достаточно длинные, но система универсальна. Если вы делаете систему для конкретного заказчика и разрезов в пределах 15 я бы рассмотрел статический вариант. Полагаю, красивым решением будет создать для каждого типа хозяйственных операций свою таблицу, со своей структурой, которая наилучшим образом соответсвует содержанию данного типа операций. А наделать всякоразных аналитических представлений, это не проблема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2005, 18:10 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
mcureenab Полагаю, красивым решением будет создать для каждого типа хозяйственных операций свою таблицу, со своей структурой, которая наилучшим образом соответсвует содержанию данного типа операций. А наделать всякоразных аналитических представлений, это не проблема. Новый тип хозоперации - ежедневная рутина, и менять в таком темпе структуру таблиц продакшн системы ... Боюсь, бухгалтера и ДБА не оценят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2005, 00:39 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
Для разных хозопераций надо делать таблицы первичных бухгалтерских документов - на каждый тип свою. А таблица проводок должна быть все же универсальной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2005, 10:38 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
Тоже иногда думаю про про водку . В моем случае все обстоит полегче в силу универсальной структуры справочника объектов учета. Теперь примеряю связь проводки со ссылками на объекты учета и запетлял вот такую декларацию: Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2005, 13:26 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
Programmer_Ortodox и подумалось мне, что вполне это может быть востребовано, т.е. когда на одной стороне проводки, скажем, "Дебет", исользуется одна ссылка на объект, или, выражаясь в терминах 1С, "Субконто", а на другой стороне проводки, таких ссылок многие тысячи. Разумеется в обычных хоз.операциях это не нужно Различное количество аналитик это очень часто используется именно "в обычных хоз.операциях" Например корреспонденция между 50-ым кассой, вообще без аналитики и 76-расчетами с дебиторами/кредиторами с аналитикой Лицо, Тип услуги, Документ основания и пр. Хранение субконто в качестве массива имеет свои минусы, например сложность с выдачей остатков в разрезе определенной аналитики, например получить остатки по 76 счету в разрезе Лиц в виде SUM, CLIENT_ID, "Наименование клиента" 2-ое достаточно сложно организовать проверку обязательности заполнения значения субконто, в зависимости от того на какой счет идет проводка. А проверка должна быть обязательно иначе невозможно будет получить данные в разрезе аналитики. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2005, 17:15 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
Estets Programmer_Ortodox и подумалось мне, что вполне это может быть востребовано, т.е. когда на одной стороне проводки, скажем, "Дебет", исользуется одна ссылка на объект, или, выражаясь в терминах 1С, "Субконто", а на другой стороне проводки, таких ссылок многие тысячи. Разумеется в обычных хоз.операциях это не нужно Различное количество аналитик это очень часто используется именно "в обычных хоз.операциях" Например корреспонденция между 50-ым кассой, вообще без аналитики и 76-расчетами с дебиторами/кредиторами с аналитикой Лицо, Тип услуги, Документ основания и пр. Хранение субконто в качестве массива имеет свои минусы, например сложность с выдачей остатков в разрезе определенной аналитики, например получить остатки по 76 счету в разрезе Лиц в виде SUM, CLIENT_ID, "Наименование клиента" 2-ое достаточно сложно организовать проверку обязательности заполнения значения субконто, в зависимости от того на какой счет идет проводка. А проверка должна быть обязательно иначе невозможно будет получить данные в разрезе аналитики. Различное, в данном случае, это единицы, тысячи, миллионы. Это вынуждает радикально пересмотреть структуру таблицы проводок. Ведь не будете же вы резервировать в проводке миллионы субконто? PS Мне все таки кажется, что подобные сингулярности в учете(в самом широком его понимании) могут иметь массу вкусностей! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2005, 09:29 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
Картинку приложил для иллюстрации собсно объекта обсуждения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2005, 09:31 |
|
||
|
Структура таблицы бухгалтерских проводок не дает покоя !!!!
|
|||
|---|---|---|---|
|
#18+
Переменное число аналитик у счета и переменное число объетов проводке - разные вещи. Автор по-моему про второе : в одной проводке и сахар на склад 1 и пиво на склад 2. Обсуждалось... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2005, 10:40 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33056734&tid=1545644]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
78ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
2ms |
| others: | 270ms |
| total: | 451ms |

| 0 / 0 |
