вторник, 19 июля 2011 г.

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

Расширенная Аналитика Учета Затрат, появилась в УПП (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. Объединяйте макеты индивидуальной настройкой при обновлении
и.......  используйте РАУЗ, типовой режим больше не будет развивается все "вкусности" только в РАУЗ.