Re: Организация многоуровневого и валютного учета



Posted by Васеленко Сергей, Фирма КАРДИНАЛ (62.118.134.244) on September 10, 2001 at 04:04:30:

In Reply to: Re: Организация многоуровневого и валютного учета posted by Анатолий Анимица on September 09, 2001 at 09:06:37:

Спасибо, Толя, за отклик.

Пришлось снова обосновать себе правильность сделанного выбора.

: Сережа Васеленко пишет:

: Хочу поделиться опытом реализации многоуровневого аналитического учета.
: Данная тема уже неоднократно затрагивалась но, чувствуется, является насущной и сейчас.

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


: Учет разделяется на синтетический и аналитический.

: Не разделяется. Аналитический учет должен быть естественным продолжением
: синтетического. Иной подход чреват потерей изоморфности (адекватности)
: учета. И окажется, что сальдо счета 10 в час "Ч" миллион рублей,
: а на складах этого добра на 2 миллиона.

"Аналитический учет должен быть естественным продолжением синтетического".

1. Т.е. грань существует. И у нас она четко проводится.
2. Естественно продолжение должно быть "естественным".

"И окажется, что сальдо счета 10 в час "Ч" миллион рублей, а на складах этого добра на 2 миллиона."

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


: Синтетический учет опирается на синтетический план счетов, далее просто план счетов.
: Аналитический учет опирается на план счетов и аналитические справочники - организаций,
: сотрудников и т.д.

: Очень опасный подход. Каждый об'ект учета, входящий в бухгалтерскую
: систему, надежно представляется только собственным сальдо (в смысле ФБП и
: в традиционном бухгалтерском смысле). В случае с аналитическим справочником
: тоже можно потерять соответствие между остатком счета по заданному
: сотруднику и его сальдо в плане счетов. Кроме того, соотношение
: задолженностей или их перевод из одного счета в другой, например, из 71 в
: 73, в общем случае, вещь контрактная и нуждается в соответствующем
: распоряжении, приказе, договоре и бухгалтерской проводке, отражающей это
: изменение качества долга. Иное - просто малореальная идеализация предприятия.


: Один аналитический справочник можно использовать для расшифровки данных к нескольким
: синтетическим счетам.
: Например, сотрудники могут иметь сальдо по 70,71,73 счетам, организации - по счетам
: 60,61,62,63,64,76.

: Опасная конструкция. Лучше назначить любому контрагенту "ведущий" субсчет,
: например, 60. А его отношения с предприятием как покупателя отражать
: на отдельном субсчете 62, который можно снабдить ссылкой на этот 60,
: или, как сделано в 2001R, отгрузку покупателю, "сидящему" в счете 60,
: отражать через две проводки на трансферагентный счет 62т60 (отгрузка
: поставщику).

По-моему, последний абзац полностью вступает в противоречие с предыдущим:

"Кроме того, соотношение задолженностей или их перевод из одного счета в другой, например,
из 71 в 73, в общем случае, вещь контрактная и нуждается в соответствующем распоряжении,
приказе, договоре и бухгалтерской проводке, отражающей это изменение качества долга.
Иное - просто малореальная идеализация предприятия."

По-прежнему считаю, что один сотрудник или организация МОГУТ иметь сальдо на разных счетах одновременно.
И то, что система позволяет выдать сальдо по всем этим счетам без каких-либо затрат (см. SYS7.RPT) это большое достоинство реализованного ядра.

Насчет "опасности" конструкций.

Также как проводка ФБП отвечает за формирование EA,OD,OK,OP, также и единственная процедура ENTRY_FACT отвечает за формирование этих данных.

И если есть в ней ошибки, то только она одна и изменяется без переделки остального.

Опасным является, конечно, возможность несоответствия аналитического счета, подставляемого в проводку, предопределенному в плане счетов.
Но опять же это проверяется и выдается соответсвующее предупреждение.


: Учет должен быть многовалютным.

: Или не должен. В 2001R учет становится многовалютным автоматически.
: Как только субсчет участвует в какой-нибудь валютной операции.
: Причем любой субсчет, кроме налично-денежного, может содержать
: любое количество остатков в любых валютах. Кассовые счета блокируют
: попытку ввести операцию в чуждой для данной кассы валюте (принцип
: моновалютности налично-денежных счетов).

Точнее сказать: "Система должна быть многовалютной".
И если, речь идет о реализации ядра для систем, то это требование является обязательным.


: cтандартный факт ta заменен на полноформатный факт Entry и поддерживаются процедуры (через call):

: Еще одно опасное решение. Гораздо проще и надежнее оставить ta-факт,
: дополнив его различными аналитическими фактами для разных
: учетных операций (склад, валюта и т.д.).

Это какое-то нагнетание обстановки и предложение менее надежного механизма.

Во-первых, за 4 года работы предложенного ядра (организация плана счетов, процедуры проводок, системные формы) только 3 раза были серъезные ошибки - несхождение оборотов и остатков. Которые были сразу устранены заменой одной процедуры ENTRY_FACT во всех файлах-коэффициентах.

Во-вторых, для полноценной проводки необходимы данные:


Дебет (Синт.счет,Ан.счет,Док-т,Сумма в валюте) Кредит (Синт.счет,Ан.счет,Док-т,Сумма в валюте) Сумма в валюте учета

И гораздо надежнее, если эти данные сидят в одном факте, чем в четырех фактах ta и "различных аналитических фактах для разных
учетных операций".

Естественно, реализация собственных механизмов взамен встроенных требует аккуратности и осторожности.
Но как было показано в предыдущей статье, встроенных механизмов сейчас уже недостаточно и их просто НЕОБХОДИМО заменить.

Так что выбор разработчиков состоит только в том, на что заменить и как реализовать.

В этом я и готов помочь бесплатным предложением готового ядра.

С уважением, Васеленко Сергей.



Пpишедшие ответы: