Принципы построения систем



Posted by Рустем Мухаметшин on February 25, 1999 at 10:11:08:

    Вместо вступления
    Первоначально я хотел написать нечто более проработанное и структурированное. Но время шло, руки не доходят. Поэтому представляю на суд общественности то что удалось собрать и систематизировать. Готов ответить подробнее на вопросы если таковые будут. Хотелось бы так же попросить воздерживаться от реплик типа: х-м, да это ж запросто, надо было так и так :))). Потому как то что изложено прошло длительную обкатку и зарекомендовало себя как жизнеспособное. При этом готов выслушать продуманную критику, как по исполнению так и по положениям закладываемым в основу. Вобщем, бейте, только не очень сильно :)))

    Что мне не нравится в большинстве систем
    В первую очередь примитивный подход к расчетам по НДС. Наверное для не мудреного предприятия с одним видом деятельности (а чаще просто торговли) этого достаточно. Что же обычно характерно
    - Слабая поддержка или полное отсутсвие поддержки автоматических расчетов по книге покупок и продаж. Соответсвенно, полная отделленность их построения от учетных данных (проплат).
    - Учет НДС по номенклатурным позициям по принципу от процента.
    Ну если по первому пункту можно найти какието продвижения, то по второму пункту просто поголовное приверженство принципу процента. Загляните в инструкции по НДС. Конечно там декларируются основные ставки 10% и 20%. Но в то же время там говорится что ни вкоем случае, никогда нельзя выделять НДС по этим расчетным ставкам - сколько Вам выделил поставщик столько и берите. Сюда следует добавить возникающие проблемы при расчете НДС по товарам с акцизами, ГСМ, по продажам за наличный расчет (с налогом с продаж). Т.е. сама природа НДС заложенная в инструкции говорит о том что его надо учитывать по принципу от суммы.

    Как и что я делаю
    Следовало оговориться в самом начале, что оценка чего либо невозможна без выдвижения критериев оценки. А в данном случае многое зависит от технического задания (ТЗ). Поскольку проблемы учета можно решать различными способами, то то что закладывается в ТЗ в конечном итоге и определяет результат и его качества. Поэтому сравнивать проекты по разным ТЗ мне кажеться неправомерным. В данном случае я изложу свое видение ТЗ для бухгалтерской системы и его реализцию. Это ТЗ имеет некоторые частные черты присущие моему клиенту, а именно Нефтебазе
    - Учет сумм налогов по принципу от суммы
    - Автоматические расчеты по НДС на основе аналитических данных. Построение книг покупок и продаж на основе введенных документов отгрузки и разнесенных платежей всех форм (безнал, нал, векселя, взаимозачеты, ...) При этом если нет возможности подокументального распределения сумм оплат, то это должно делаться автоматически по методу ФИФО
    - Возможность поддержки расчетов по разнообразным видам деятельности
    - Автоматический расчет сумм налогов при отгрузке по тому методу который присущ данному товару и данному виду деятельности без вмешательства оператора (к примеру ГСМ при реализации по комерческой продаже и по товарному кредиту отражается в учете совершенно по разному, однако метод реализации товара один и тот же, более того документы оказываются одинаковыми - нонсенс, да? Такой уж у нас товарный кредит :). Важно что суммы расчитываемых налогов зависят от метода расчета товарной позиции и вида деятельности и учатываются системой автоматически.
    - Партионный учет на склдах оптовых поставок и метод по фактическим средним на материальных складах
    - Учет транспотрных расходов
    - Учет расчетов с клиентами в разрезах видов деятельности. Соответсвенно учет реализации по клиентам в разрезах видов деятельности. Т.е. средства платежа и отгрузки товаров по разным видам деятельности не приведут к факту оплаченной реализации или оплаченной поставки со всеми вытекающими последствиями.

    Как это реализовано
    Для реализации аналитичяеского учета используются ЭП и факты. Остатки хранятся в ЭП, изменения прописываются в факты. К примеру, по складскому учету остатков запоминаются в ЭП
(Склад, Партия,Товар)=(количество, сумма, сумма НДС, сумма НГСМ)
    по расчетам с поставщиками по фактам прихода запоминается факты с полями
Поставщик, с/ф, склад, товар, количество, сумма, сумма НДС, сумма НГСМ, код накладных расходов(транспортных), сумма, ндс, нгсм, вид деятельности, штамп     с учетом прототипа получим 15 полей. Я как-то раньше не задумавался об ограничении в 16 полей. Кстати о нем так же нет ни слова в документации :))
    При отгрузке факт содержит как стоимости продажные так и себестоимости
    Вообщем, специально для Владимира Секретева - Полей получается много, не считаю их избыточными, хранить их в extrd я не хочу ибо в этом случае я выбрал бы предпочел другую программу - 1С Предприятие 7.5
    Если кому интересно могу подробнее расказать о чем нибудь :))

    Что мне нехватает
    - Агрегатных типов данных. Было бы здорово вместо четырех ЭП по остатку товара прописать все на ОДИН индекс!!! Экономия памяти, да и структуризация данных повышается. Как Вам например такая запись
[set41-01,'ТНБ076',{10,20,4,5}]
A =[get41-01,'ТНБ076']
Q   =A.1
S   =A.2
ND=A.3
NG=A.4
    - Вероятно стоит отказываться от полной безтиповости данных.
    - Общего модуля для Ф/к или хотябы операторов #include или uses кому как больше нравиться
    - Отделения справочника от плана счетов. Возможности организации аналитики на встроенном уровне. Возможность модификации прототипа ta
    - Было еще что-то, как вспомню напишу :)



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