РАУЗ под микроскопом

Расширенная Аналитика Учета Затрат, появилась в УПП (1.2.15) в далеком апреле 2008 года. Тогда подсистема имела существенные ограничения и сомнительные неоднозначные преимущества. Вот первая рыжая презентации подсистемы из тех лет (в самом конце еще одна)

Некоторые подходы РАУЗ настолько сильно ломали консервативные взгляды тогдашних внедренцев и программистов, что не многие решались на его использование.
Использование РАУЗ для многих было эквивалентно "хождению по потолку". И даже сейчас я встречаю предприятия которые опасаются РАУЗ. Сегодня я постараюсь развеять все эти опасения, и  раскрыть потенциал РАУЗ, я не буду "гнать пургу" про линейные уравнения, совмещенный учет и прочие настройки, а просто расскажу как РАУЗ устроен "изнутри".

Итак поехали.

В традиционном режиме мы обладаем кучей регистров:

• Партии товаров на складах
• Незавершенное производство, Затраты, Брак в производстве;
• Затраты на выпуск продукции;
• Партии товаров переданные;
• Партии материалов в эксплуатации;
• Выпуск продукции 

И все еще это в 4 срезах (УУ, БУ, НУ и Международный) Итого 8*4 = 32. 

Сердце

И вот вместо этих 32 регистров, в РАУЗ мы получаем всего 3 регистра (3 основных таблицы в СУБД, да простят создателей РАУЗ все Эксперты по технологическим вопросам ), эти регистры и являются сердцем РАУЗ. Движения в этих регистрах схожы с проводками по НУ, где основополагающим является принцип двойной записи, но который в тоже время не всегда объязателен.

Однако как вы наверно догадались соединить 32  регистра в 3 не так то просто поскольку такой регистр должен будет иметь как минимум 29 измерений (Эксперты еще не "отошли" от 3 таблиц :) )

Поэтому в ущерб нормализации базы данных было придумано такое понятие как "Ключи аналитики". Ключи аналитики группируют измерения по направлениям, и отвечают на следующие вопросы:

1. Аналитика вида учета  - "Где учитывается?"
2. Аналитика учета затрат - "Что учитывается?"
3. Аналитика учета партий - "Откуда это?"
4. Аналитика распределения затрат - "Для чего все это?" :)

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

Но прежде чем продолжить, вспомните есть ли в традиционном режиме то место, назовем его ядро, где сосредоточена вся логика затрат или МПЗ?
Возможно вы назовете с десяток общих модулей и скажете что вот это оно "ядро".

В РАУЗ ядро всей логики представляет из себя всего 2 объекта (или даже по одному для УУ и БУ) 

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

Сейчас я подробно расскажу про эти макеты. Для начала приведу пример одного из макетов.

В строках мы видим правила по которым формируются любые движения,  а в колонках знакомые уже нам Ключи аналитики, Ресурсы и дополнительные параметры влияющие на движения

Итак с чего же все начинается.

1. При проведении документа формируются произвольное количество таблиц значений, в большинстве случаев оно равно количеству ТЧ, но может и отличаться.
2. Структура сформированных таблиц сохраняется в ДополнительныеСвойства(.СтруктураТабличныхЧастей) объекта и передается на сервер совместно с операцией (Хочется отметить что вся логика РАУЗ выполняется на сервере в привелегированных модулях)
3. Для каждой таблицы документа определяется правило формирования
4. Выполняются движения в соответствии с правилами формирования

Имя правила формирования состоит из следующих частей:

ПоступлениеТоваровУслуг. Поступление.ТаблицаПоТоварам.Получатель

1. Имя документа;
2. Вид операции документа;
3. Имя таблицы;
4. Направление движения 

Поиск правила осуществляется только по первым 3 составляющим, направлений движений для каждой таблицы может быть сразу 2 [вспоминаем про основополагающий принцип двойной записи]:

1. Получатель (Приход, Дебит)
2. Источник (Расход, Кредит)

Если не одного правила не найдено то движения по Расширенной аналитике затрат не формируется.

Теперь более подробно остановимся на колонках:

Важно: Значение во всех колонках являются вычисляемые то есть можно использовать ?(,,) и функции общих модулей. В контексте вычисления доступны 2 переменные:

1. СтрокаДокумента
2. СтруктураШапкиДокумента

• ВыполнятьДвижение -<Булево> Определяет  нужно ли выполнять движения в регистр накопления УчетЗатрат. Если значение Ложь, будут сформированы только проводки. Необходимым условием для формирования проводок является:
• Отражение в БУ [и НУ]
• Наличие 2 правил для таблицы (ДТ - Получатель и КТ - Источник);
• Заполненность счетов учета колонки: (СчетУчета, СчетУчетаНУ) опять таки для БУ важно иметь заполненный счет в обоих направлениях для НУ хотя бы одно;
• Различие в коррекспондеции;
• ИспользоватьАналитикуВидаУчета -<Булево>. Определяет возможность использования Аналитики учета прочих затрат. Значение Ложь имеет смысл только когда не выполняются движения в РН.Учет затрат (ВыполнятьДвижение  = Ложь).
• РассчитыватьСуммы -<Булево> определяет необходимо ли рассчитывать суммы в соответствии с накопленной АналитикойВидаУчета и установленными параметрами учетной политикой . Если значение Ложь то должны быть заполнены колонки ресурсов:

• Стоимость;
• СтоимостьНУ;
• ПостояннаяРазница
• УсловиеОтбораСтрок - <Булево> определяет для каких строк будут формироваться движение, по строке  либо движения формируются либо нет

Остальные колонки представляют из себя значение ключей аналитики, или ресурсов в большинстве случаев имя ключа аналитики соответствует Видам Субконто, но если имя необходимого субконто отсутствует необходимо использовать колонки Субконто1,2,3; СубконтоНУ1,2,3

Умение читать и редактировать ядро РАУЗ, развеет все ваши сомнения в использовании РАУЗ и превратит редактирование логики движений в увлекательный процесс.

Тут можно статью и заканчивать, но хочется оставить рекомендации по редактированию этого макета:

1. Не редактируйте существующие правила, просто добавляйте  новую область с таким же именем правила, но выше существующей;
2. Задавайте для каждой добавленной строки свое имя области
3. Объединяйте макеты индивидуальной настройкой при обновлении

и.......  используйте РАУЗ, типовой режим больше не будет развивается все "вкусности" только в РАУЗ.