СисойFinSoft Как показала моя практика, торможения там возникают только при расчете себестоимости в открытом периоде.

Подскажите, в Вашей системе Вы храните таблицу проводок прошлых периодов?
Или каждый раз при построении отчета за несколько периодов проводки генерятся заново? (тут сразу возникают большие потенциальные проблемы с изменяемостью алгоритмов ПО и схем формирования проводок. Кстати, на курсах в 1С именно этот фактор приводят в пользу "денормализации" системы учета: даже если алгоритм раньше был "неправильным", а нынче стал "правильным", финансовые транзакции в закрытых периодах изменяться не должны).

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

СисойFinSoftВ торговом контуре стандарт - учет по FIFO. В производственном - по средней.
Понял. Ваша система действительно весьма неплохо будет отрабатывать при сравнительно небольшой "плотности" документов движения по одной и той же номенклатуре и/или при регулярном закрытии периода. Для торговли самое то.
Остался открытым вопрос о построении отчетов по движениям нескольких периодов (с остатками понятно).
Когда формируются отчеты по нескольким периодам, система выполняет декомпозицию. Иными словами, формируется список периодов, границами которых являются документы остатков. Далее для каждого периода определяется возможность использовать сводные итоги. Если такая возможность есть, то из базы данных берутся готовые значения, если нет, то происходит расчет по документам. В конце итоги расчетов за все периоды объединяются в итоговую выборку.

iscrafmFinSoftНапример, мы выставляем остатки на 01.03.2009, корректировки документов до этой даты запрещаются. Все расчеты по документам делаются от ближайших остатков.куда выставляете остатки? Похоже действительно как чуть выше замечали Коллеги, существует непонимание того, что такое Проведение, оно же Учет, оно же Posting, оно же...
Еще про бух.проводки спрашивали чуть выше. Расскажите плз куда они выставляются.
Сэр слишком самокритичен :-) У нас система УУ, бухгалтерский модуль был сделан в экспериментальных рамках. Реально клиенты ведут учет в 1С-Бухгалтерия. В том экспериментальном модуле была реализована схема, аналогичная схеме работы с итогами в других разрезах. В документе остатков создавалась таблица остатков по каждому бухгалтерскому счету (учет только синтетический). В сводных итогах между фиксациями остатков создавалась таблица оборотов по каждой корреспонденции. Трансляция документов в проводки собиралась в одну процедуру, которая вызывалась в нужном режиме. Если требовалось, например, получить анализ счета, то делалась оптимизация - анализировались настройки и обрабатывались только необходимые типы документов и итоги аналитических разрезов.

СисойFinSoftМежду двумя фиксациями остатков создаются записи о сводных итогах в нагруженных разрезах.

... И получаем регистры 1С (оборотные как минимум). Можно спорить о нюансах, но принципиально это то же самое.
Таким образом, концептуальное отличие от модели 1С состоит в том, что в текущем открытом периоде предлагаемая ИС не формирует дополнительные записи ("проводки") в БД, а строит их "на лету", ориентируясь на статусы документов.
Идея нормальная.
Уточню. В закрытых периодах проводок в понимании 1С тоже нет, есть сводные итоги в нагруженных разрезах. Например, есть итоговая себестоимость в разрезе отгрузочных накладных, но нет проводок по каждой строке накладной. Принцип такой. Анализируется, какие отчеты требуют больших вычислительных ресурсов и в каких разрезах они потребляют информацию. В таких разрезах сохраняем сводные итоги. Те отчеты, которые не требуют обработки большого количества информации (например, карточка товара или оборотка по взаиморасчетам), всегда считаются по документам. В этом случае скорость отклика обеспечивается оптимизацией структуры базы данных.

iscrafmFinSoftУ нас система УУ, бухгалтерский модуль был сделан в экспериментальных рамках.
В документе остатков создавалась таблица остатков по каждому бухгалтерскому счету (учет только синтетический).
В сводных итогах между фиксациями остатков создавалась таблица оборотов по каждой корреспонденции.
Трансляция документов в проводки собиралась в одну процедуру, которая вызывалась в нужном режиме. Если требовалось, например, получить анализ счета, то делалась оптимизация - анализировались настройки и обрабатывались только необходимые типы документов и итоги аналитических разрезов.
Вы оказывается вообще бух.учет только в экперементальных рамках проходили. А что здесь обсуждается? Трансляция документов в проводки, в нужном режиме...
Опыт разработки по системам бухучета у меня 16 лет. Сказанное относится к конкретной прикладной системе. Если у Вас есть конструктивные вопросы, спрашивайте.

iscrafm FinSoftАнализируется, какие отчеты требуют больших вычислительных ресурсов и в каких разрезах они потребляют информацию. В таких разрезах сохраняем сводные итоги. Те отчеты, которые не требуют обработки большого количества информации (например, карточка товара или оборотка по взаиморасчетам), всегда считаются по документам. В этом случае скорость отклика обеспечивается оптимизацией структуры базы данных.
анализатор куда встроен? Сегодня этот срез не нагружен, а завтра - нагружен. Процедура сохранения итогов меняется оперативно?
Анализатор статический, в каких разрезах сохранять сводную информацию, решает разработчик на этапе проектирования. У нас софт поставляется под ключ и поддерживается централизовано. Пользователи не имеют возможности самостоятельно дорабатывать бизнес-логику.

iscrafmпока выявлено одно "отличие" от 1С: в регистры пишется только в момент закрытия периода, до этого момента - считается по записям документов.
Вопрос изменения структуры документов, появления новых документов и влияние этого на отчеты и расчетные процедуры остается открытым.
Разница в уровнях деталировки информации и базовой схеме расчета. В 1С практически все считается по записям в регистрах, у нас - по документам. Сводные итоги в закрытых периодах - это вспомогательный инструмент для увеличения производительности. Если их нет, то программа работать не перестанет, расчет будет произведен по документам.
Что конкретно про новые документы Вас интересует?

СисойFinSoftУточню. В закрытых периодах проводок в понимании 1С тоже нет, есть сводные итоги в нагруженных разрезах. Например, есть итоговая себестоимость в разрезе отгрузочных накладных, но нет проводок по каждой строке накладной.

В 1С 8 генерить проводки по каждой строке накладной вовсе необязательно. Информация агрегируется с точностью до счета/набора субконто (аналитик). А если торговый модуль (1С:Управление торговлей, УУ в УПП), то до комбинации измерений регистра. Никакой принципиальной разницы с Вашим подходом нет.
К сожалению, в 1С8 я заглядывал только на уровне готовой системы. Надеюсь восполнить этот пробел, так как, судя по 1С 7.7, в этих системах гораздо больше интересных идей, чем в других программах, которые мне приходилось видеть.
Поясните, пожалуйста, как в 1С8 формируется регистр партий товаров, если проводки не генерятся по каждой строке накладной.

iscrafmFinSoft
Что конкретно про новые документы Вас интересует?
то что спросил. Изменяются отчетные формы и процедуры при появлении новых документов?
Надо рассматривать два уровня процедур. Первый уровень формирует базовую выборку в оперативной памяти, которая затем используется в процедурах второго уровня, например, отчетах. Если говорить про первый уровень, то ответ - да, изменения требуются. Если говорить про второй уровень, то зависит от контекста, могут требоваться, могут и не требоваться. Я не думаю, что "проводные" системы будут требовать принципиально меньших изменений. Отмечу еще, что процедуры первого уровня у нас накрыты системой автотестирования. Ее смысл заключается в формировании различных базовых выборок и перекрестных проверок контрольных цифр.

iscrafm"проводные" системы построены по принципу, который схематично показан на рис. ниже. Т.е. отчеты формируются по таблицам фиксированной структуры. При добавлении в систему новых источников данных таблицы "регистров" не изменяются, запросы которые на них нацелены тоже. Новый источник данных добавляется вместе с процедурой учета (постинга, проведения) информации из него, т.е. с процедурой отражения данных этого источника в учете. Вы рассказываете о схеме, в которой физические регистры (или как их там) заменены на виртуальные выборки. Т.е. добавление нового источника данных требует перестройки этой самой выборки.
Основные проблемы с таким подходом происходят в системах, которые "живут во времени", т.е. их структура не является чем-то статическим.
Я думаю, что тут просто заход с другой стороны. Вы регистрируете новый источник данных и прописываете, как он отражается в физических регистрах. При работе по документам обработка нового документа прописывается в процедурах базовых выборок. Иными словами, Вы описываете отражение документа, я описываю построение выборки. Объем кода приблизительно одинаковый, только у Вас регистры "размазаны" по документам, у меня документы "размазаны" по выборкам.

СисойFinSoftПоясните, пожалуйста, как в 1С8 формируется регистр партий товаров, если проводки не генерятся по каждой строке накладной.

Вся загвоздка в том, что понимать под "партией". В 1С под финансовой "партией" понимают одинаковую номенклатуру, пришедшую по конкретному поступлению (даже если в документе несколько строк с разной ценой). Необходим более детальный учет - включай у позиции номенклатуры использование серий, характеристик. Некоторые документы формируют расходные движения построчно (реквизит регистра НомерСтрокиСписанныхТоваров), но в целом задача этого не требует.
Обычно в накладных редко бывает один и тот-же товар в разных строках. То есть все равно получаем соответствие строка накладной - запись в регистр партий. Кстати, я не знал, что в 1С8 один и тот-же товар по разным ценам в одном приходе образует одну партию. Я придерживаюсь строгого соответствия строкам документов. Даже если один и тот-же товар будет дважды в одной накладной по одной цене, в карточке товара это отразится двумя строками.

iscrafmFinSoft,

все же один из главных вопросов... если с течением времени правила интерпретации документа изменяются?
Построение всего "на лету" конечно возможно, здесь , например, так делалось. Но назначение системы немного другое, историю учета хранить не требовалось. А если требуется? Делать процедуры которые до определенного момента интерпретируют информацию по одним правилам, с определенного момента по другим и т.д. Думаю о легкости сопровождения приходится забывать понемногу.
К счастью, такое бывает нечасто. Но и в "проводной" системе я бы побоялся просто заменить модуль проведения документа, не сохранив историю генерации проводок. Тут облегчить жизнь можно, только если держать скелет системы на уровне статических для конкретного вида бизнеса понятиях.