WGAПоявилась тут задача по бухгалтерскому учету.Как раз именно в бухгалтерском учете всё уже давным-давно придумано. Ведь понятие "бухгалтерской проводки" сводится к отражению хозяйственной операции на "бухгалтерских счетах", которые и являются, по своей сути, агрегатами. ОСВ - это всего лишь отчет, который выводит содержимое подобного агрегата в тех или иных аналитических разрезах.

Некоторые разработчики пытаются избежать хранения в базе отдельных сущностей вроде "бухгалтерских счетов" и "проводок" по ним, формируя, в частности, ОСВ непосредственно по массивам первичных документов в процессе формирования ОСВ как отчета. Однако, по-моему, это не совсем удачный подход по множеству причин.

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

Именно по этой причине первоисточники в виде электронных документов хранят в одних сущностях (журналах документов), а проводки, которые они вызывают, в других - в бухгалтерских счетах и бухгалтерских регистрах. Это удобно еще и потому, что неподготовленные по различным причинам документы огут оставаться "непроведенными", либо "проведенными частично" (например, когда по приходу ТМЦ предоставлена накладная ТОРГ-12, но не предоставлена корректно оформленная счет-фактура). Проводки также могут возникать не на основе формализованного документа с заранее расписанной схемой проводок, но и на основе "бухгалтерской справки", в которой могут быть совершенно любая заранее непредсказуемая совокупность проводок.

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

Бухгалтерский счет - и есть, по сути, нечто подобное OLAP-кубу. Аналитические разрезы бухгалтерского счета определяют перечень его измерений, учетные периоды - одно из измерений, другие определяются видом счета (для счетов взаиморасчетов это могут быть контрагенты и договоры, для счетов учета ТМЦ - перечень складов и номенклатура и т.д.). А суммы в различных валютах, натуральные показатели (количество) образуют его меры.

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

Классическая система имеет отдельные таблицы "документов" и "бухгалтерских счетов". "Проводки" - это формирование записей в таблицах "бухгалтерских счетов" на основе данных таблиц "документов". OLAP-кубы можно построить на таблицах счетов, исходя из фактических возможностей и требований к оперативности получаемых агрегатов.

P.S. А вообще-то это вопрос по тематике немного другого форума - разработка информационных систем. Модератор: Могу перенести туда тему, если создатель темы не возражает

WGAНадеюсь разум победит )Тут нужно не надеяться, я претворять "разум" в жизнь. :)

WGAВопрос оптимизации сложных отчетов - не самое главное. Лично я понимаю, что просуммировать, скажем, по 10 проводкам, с правильными индексами может быть не намного дороже, чем достать одну строку из предварительно подготовленной таблицыСмотря что в этой таблице находится. Если электронные формы первичных документов, тогда это не очень удачная идея. Подобные идеи приходят на ум тем, кто не видит суть системы бухгалтерских счетов и проводок.

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

Во-вторых, я не вижу смысла городить кучу различных отчетов для просмотра данных о задолженностях контрагентов, о движении товарно-материальных ценностей, о начисленной амортизации по основным средствам и нематериальным активам, о начисленной и выплаченной зарплате сотрудников и десятках других видов отчетов. Достаточно разработать один универсальный отчет, который может работать с любыми бухгалтерскими счетами, разворачивая и сворачивая на них информацию до нужной степени детализации, выводя итоги/подытоги, остатки, обороты, вспомогательную информацию из аналитических справочников (субконто) и т.д. Такой отчет никак не будет зависеть от количества видов документов, которые где-либо каким-либо образом формируют проводки. И его не придется модифицировать каждый раз, когда будут добавляться новые виды документов или изменяться схемы проводок.

Классическая учетная система 1С предлагает некие стандартные схемы проводок, шаблоны которых, в зависимости от вида документа и параметров, указанных в документах, автоматически меняться. Но они не предлагаются как схема проводок "зашитая насмерть" для того или иного случая. В каких-то специфических ситуациях пользователь всегда имеет возможность отредактировать те проводки, которые система предложила "по умолчанию" - и это правильно. ИНФИН предоставляет возможность воспользоваться предварительно настроенными совокупностями проводок с помощью "автоматических операций" или "стандартных операций", но также позволяет сделать "просто проводки" - совершенно любые и по любому поводу, если предварительно настроенные схемы в данной конкретной ситуации чем-то не устраивают пользователя. И это тоже правильно.

Есть вещи, которые в 1С меня раздражают после того как я поработал с ИНФИНом - это как раз отсутствие унифицированного подхода к отчетам и интерфейсам, который имеется в ИНФИНе. В ИНФИНе, если ты просматриваешь что-либо табице-подобное, у тебя всегда есть возможность единообразных механизмов фильтрации, поиска, сортировки, вывода суммирующих итогов. В 1С же в одних случаях нужно использовать одни методы, в других другие. Флаги "проведено" или "помечено на удаление" недоступны для фильтрации записей в некоторых компонентах интерфейса, в которых доступны другие поля. В одних табличных представлениях есть возможность увидеть суммовые итоги, в других нету. Не понятно, почему, например, отфильтровавший в перечне платежек некую их совокупность по наличию некой фразы в назначении платежа не может сразу же получить их итоговую сумму, а должен хвататься за калькулятор или, совершая груду промежуточных действий, выгружать данные в электронные таблицы, чтобы там просуммировать полученные записи, или городить новый вид отчета где-то в другом месте программы, когда вот уже оно это место, где нужные записи уже отфильтрованы, осталось только где-нибудь увидеть поле "ИТОГО"...

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

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