BusyMan%%% :-)))) Я имел в виду ТОЛЬКО проводки и хозяйственные операции (обезличенно)... Вспомните в начале топика кто-то заикался о том, что без аналитики можно тоже обойтись путем построения соответствующим образом самого плана счетов!!! Меня интересует какая есть альтернатива такому подходу...

Я тоже в некотором роде на распутье. Правда я уже все (пока) сделал (для себя лично). Итак суть вопроса в следующем:

У нас есть оперативные документы (строки). Там есть некоторое кол-во "стандартых" кодов (полей) аналитики (субконто). И мы понимаем что нам потребуются "продвинутые" отчеты.

Мы понимаем, что можем идти двумя путями:

1. Делать отчеты путем выборок по уже имеющимся кодам аналитики с возможной надстройкой на ними (через спец_НСИ).
2. Создавать алгоритмы которые создают в БД дополн_инфо = Проводки.

Уместы оба варианта которые не следут противопоставлять. С первым все понятно, рассмотрим второй.

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

Один и тот же Документ, в разное время, в разных целях - может "породить" разные наборы Проводок. Здесь нужно принципиальное решение. Которое по сути зависит от Главной Идеи.

Примерно так - Документ может породить дерево проводок. В зависимости от внешних условий - в разное время - исполняется (проводится) часть Дерева Проводок. Например - при приходе товара - делается проводка на управл_план счетов - так как это нужно разным Аналитикам. Потом, документ может быть ПЕРЕПРОВЕДЕН или "ДОПРОВЕДЕН" и при этом будут созданы Дополнительные Проводки (например бухгалтерские (в конце месяца)).

Здесь задача сводится к реализации на уровне интерфейса - когда мы решаем для себя Главный Вопрос = Сколько Может быть Типовых (хозяйственных) операций Учета. Что это - один "слой_измерение_код аналитики" (одна поляна в БД журнал документов) - или это скажем жестко прописаное некое кол-во полей в журнале документов, где одновременно можно хранить сразу несколько Кодов Хоз_операций?

Где Хоз_операция - это "нечто" что под своим кодом объединяет НСИ - группа настройки проводок.

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

Я не привязываюсь к конкретным методикам построения управленческого учета как то ...статьи...ресурсы...центры затрат... и рассуждаю в общем случае.

А вот если мне надо будет сделать например, анализ оборачиваемости или узнать , например зависимость торговой наценки от <список_параметров> я создам в системе новые Проводки. И там все увижу.

BusyMan UK0IAI У нас есть оперативные документы (строки). Там есть некоторое кол-во "стандартых" кодов (полей) аналитики (субконто). И мы понимаем что нам потребуются "продвинутые" отчеты.

Мы понимаем, что можем идти двумя путями:

1. Делать отчеты путем выборок по уже имеющимся кодам аналитики с возможной надстройкой на ними (через спец_НСИ).
2. Создавать алгоритмы которые создают в БД дополн_инфо = Проводки

....

Здесь задача сводится к реализации на уровне интерфейса - когда мы решаем для себя Главный Вопрос = Сколько Может быть Типовых (хозяйственных) операций Учета. Что это - один "слой_измерение_код аналитики" (одна поляна в БД журнал документов) - или это скажем жестко прописаное некое кол-во полей в журнале документов, где одновременно можно хранить сразу несколько Кодов Хоз_операций?


А можно поподробнее с примерчиком...
Вот какие например субконто у вас там используются? И как они потом обрабатываются и что их наличие позволяет узнать?

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

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

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

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

Тут есть засада - в разное время базы распределения бывают разные. Поэтому все есть Динамическое, с введением истории и все такое.
- есть орг_структура, где важным является Должность. Она (орг_струк)также Динамическая, когда в разное время разные сотрудники занимают разные Должности а разные Должности входят в разные Центры Отвественности...

Короче, при любом "чихе" надо точно указать период и восстановить все динамическую НСИ на время "чиха".

ДЛЯ УСКОРЕНИЯ ОТЧЕТОВ (важно) в строку проводки попадает целый комплект атрибутов, както ...Должность, Сотрудник, Центр Отвествености, Код Базы распределения.... Т.е. именно те индификаторы , по комбинации которых можно точно узнать ...типа..."кто это был (на момент проводки) и где он сидел". И если мы "вдруг" хотим выдать "Фамилию" то мы именно по этому комплекту, лезем в динамический НСИ и узнаем ...кто там числился на тот момент времени.

Тормоз производительности возникает ТОЛЬКО на ретроспективных отчетах, когда мы вынуждены восставливать Орг_структуры из динамических НСИ для каждого промежуточного отчетного периода. Однако есть алгоритмы ускорения.

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

Точнее не начальник - а некая Должность. персоны могут тусоваться туда сюда, а Должности остаются.

При повышенных требованиях секьюоити - еще возникают дополниельные слои - типа по Группам (товаров) или группам_клиентов или ...что там еще.

Как вариант ускорения быстрдействия в целом - еть техничекое решение, когда если Юзер вошел в систему, то на него "навешивается" пакет строк, содержащих некие дежурные списки. актуальные на время сеанса работы (не сесии!!). Например - список "доступных клиентов". Тогда, при выводе отчетов - это не надо каждый раз "вычислять".

TemplarВ свете бурного обсуждения я не понял, чем бухгалтерский учет отличается от финансового...
ИМХО, в западной системе это одно и то же. У нас по причине "оптимизации налогов" отдельно встает налоговый учет - тот же бухгалтерский, но с другими целями.
Управленческий, опять же имхо, имеет 2 важных отличия
1. Направлен в будущие периоды
2. Фиксируется как в денежных, так и в натуральных показателях

Пожалуй одно из принциапиальных отличий бух_учета от управлеческого состои в том, в бух_учет ведется на основе балансовых уравнений.
Было + Приход - Расход = Стало.
Эти балансы одно из гениальних изобретений человечества. И требует высокой точномти документооборота.

А в Управленческом учете - это не принципильно. Там можно контролировать токо Приход и Расход. И/или (важно) План и Факт. В бух_учете термин План вообще то не имеет особого смысла (за исключением неких нормативов к списанию затрат).

Как то я ставил себе некую цель, когд мой Упр.учет должен был автоматически работать в 4-х измерениях. План, Факт, План-на-Факт, Прогноз.

Где План-на-Факт есть процедуры пересчета утверденных Планов в сопоставимые с Фактом (объемами продаж по факту на пример) - например,плановыми расходами на фактический объем продаж.

А Прогноз например, реализуется черех продвинутую модель (производства) ...MRP-модель, где на основании расширенных наборов данных, как то:

Нормы расхода ресурсов на един продукции с учетом (разное)....,
Технология изготовления (маршрут)
Детальный план Продаж (загрузки производства)
Детальные планы прочие (ремонты, замены...)
Точные сведения о Постоянных расходах и Переменных, Прямых и Косвенных.

Создаются алгоритмы, которые в состоянии смоделировать (смета, бюджет) производства при разных вариантах его загрузки.

Все выше сказанное автоматически относится к любым видам хозяйствования и торговли.

Для реализации этих задач мне как раз и потребовался управленческий учет, когда например при учете накладных расходов, были разработаны специальные планы счетов - на которох (экономисты!!) делали свои Приходы и Расходы. Путем специальной интерпритации рядовых "бухгалтерских" документов.

BusyMan UK0IAIда еще - управленчий учет начинается с ....описания ..мощной модели ..оранизационной структуры.. Которая является неотъемлимой частью общей секьюрити. Когда например Начальник, автоматом видит данные своих подчиненных. Сверху вниз.

Точнее не начальник - а некая Должность. персоны могут тусоваться туда сюда, а Должности остаются.

При повышенных требованиях секьюоити - еще возникают дополниельные слои - типа по Группам (товаров) или группам_клиентов или ...что там еще.

Как вариант ускорения быстрдействия в целом - еть техничекое решение, когда если Юзер вошел в систему, то на него "навешивается" пакет строк, содержащих некие дежурные списки. актуальные на время сеанса работы (не сесии!!). Например - список "доступных клиентов". Тогда, при выводе отчетов - это не надо каждый раз "вычислять".

О! Это как раз очень актуально... Я даже и не думал что аналитику еще и для таких целей привлекают :))... Как же интересно это выглядит когда аналитикой задается круг данных, с которым может работать пользователь (группы товаров, поставщиков и т.п.).

Особенно интересует как решать проблему особенности подчинения и перекрестного подчинения .

Это чтож... Если строить такую систему в РСУБД, то у каждой проводки будет целый длинный перечень значений по аналитикам? Т.е. БД сильно раздувается значит?

Ключевое слово ЛИНК. ССЫЛКА. ПРоводка может хранить всего лишь ССЫЛКУ на массив строк в НСИ. Нет необходимости делать "много проводок".
Но надо сразу , в архитектуре, определиться со степенью "параллелизма".

Когда, мне например, для табельного учета - удалось очень удачо!! догадаться - ЧТО ЕСЛИ штатное меняется всегда - то для ...быстродействия системы... НАДО В КАЖДОЙ СТРОКЕ ТАБЕЛЯ одновременно хранить сразу ТРИ кода аналитики (три поля) - Код_подразделения, Код_Должности, Код_сотрудника.

А хотя казалось бы, что можно хранить только инфо типа таб_номер или Id сотрудника. + некие ограничения (...Id_должности всегда уникален и все типа Кладовщики все имеют разные Id_должности...понятно о чем речь?).

А для упр_учета - Учет Фактических Накладных расходов с учетом Баз Распределения (которые есть динамические), то надо сначала сохранить "шапку" (где ссылка на код базы распределения) и тут же сразу и СТРОКИ (доп_проводки) где по сути произвен Расчет ...как юзеры общими принтерами....затраты несут...).

Итак - управленчией учет часто порождает избыточную инфо в БД.


Особенно интересует как решать проблему особенности подчинения и перекрестного подчинения .

Вообще не вопрос. Создается справочник орг_структуры (дерево), где есть доп_классификация строк. Тип строки. Тип учетной записи в дереве орг_структуры. Которая может принимать, например такие занчения как:
а потом строите дерево. И делаете такой "фишка".
На строку или Узел в дереве.

Потом вы эти Ссылки ставите скажем в подчинение (по дереву...ниже) к любому элементу дерева, например к любой Должности. И тем самым Сразу описываете ГОРИЗОНТАЛЬНЫЕ (ПЕРЕКРЕСТНЫЕ) связи подчинения.

И в КАЖДОМ СЕЛЕКТЕ, в Условии WHERE прописываете под_запросы...типа дай мне сначала все строки некого узла дерева, а потот вытащи еще и все ссылки (строки на которые ведут ссылки).