1. По результатам беседы по телефону:
Разберём что мы имеем сейчас:
источник данных: ZPKS_KO_STOK
ФМ: Z_KO_STOK Разработчик: - Валецкий Т.А.
Данные получаются из:
 ZFM_STOCK_AND_TURNS_GET - Программист: Зенченко П.В.
Эта программа не возвращает номера документов, т.е. уже агрегирует данные.
 Результат работы этой программы передаётся в модуль
ZFM_STOCK_FOR_MANAGER, где к результату добавляются дополнительные
поля.
В программе уже заложена обработка сторнированныхдокументов - они не выводятся в
результат.
Требуется - дополнить возможностью выводить данные за определённый период времени
(по дате создания документа), плюс в определённом случае брать сторнированные
документы, а в каком-то не брать.
Я исходил из предположения, что при условии правильного запроса к базе и правильной
организации индексов выбрать данные за период в 1 час быстрее, чем выбирать их за
вообще все периоды.
Данные из источника ZPKS_KO_STOK загружаются в ODS ZPKS_D04 “04. Складской
запас”.
Дальше возникли вопросы:
Возможно ли сделатьотчёты«на дату» без номерадокумента и как?
Условно, раньше хранилась следующая информация:
Ключевые
поля
Неключевые
поля
Показатели
Эта информация была на самый последний момент времени, т.к. перезагружалась каждый
день. Это достигалось тем, что брались только самые последние движения материалов без
истории. Номера документа не было.
Чтобы была историчность, необходимо хранить дату историчности. Относительно неё
нужно и формировать отчёт на дату. Сейчас дата историчности - это дата проводки. То
есть, мы подтягиваем в BW не состояние на дату, а изменение этого состояния и дату
изменения. Не важно, что само изменение завели в систему гораздо позже, чем оно
должно было произойти в бух.учёте. Как только оно дойдёт до BW, отчёт на дату, в том
числе на прошлую дату, будет эти изменения показывать.
Для сторнированных документов необходимо заменять дату проводки на дату
проводки сторнировавшего его документа. То есть фактически проводка с минусом в
ОДС или в кубе должна произойти на дату сторнирования.

2. Рассмотрим, как исходные данные будут попадать в отчёт в разных случаях. Если часть
данных (несколько документов) была, например, перемещена на другой склад,
переоценена и т.п., то данные в ОДС будут следующие:
Дата проводки
(по убыванию)
Ключевые поля Неключевые поля Показатели
31.12.2011
взамен
сторнированного
Могут быть
изменены по
сравнению с
исходными
Могут быть
изменены по
сравнению с
исходными
Могут быть изменены по
сравнению с исходными
31.12.2011
(сторнировано) Неизменны
С инвертированным
знаком
01.12.2011 Исходные
Для понимания механизма сторно возьмём более конкретный вариант с детализацией до
номера документа:
Документ: Поле
историчности
(по убыванию)
Ключевые
поля
Неключевые
поля
показатели
№2 (взамен
документа № 1)
31.12.2011
(создан)
Могут быть
изменены по
сравнению с
исходными
Могут быть
изменены по
сравнению с
исходными
Могут быть
изменены по
сравнению с
исходными
сторнированный
документ №1
31.12.2011
(сторнирован)
(искусственная
замена)
Т.к. запись из MKPF/MSEG
одна и та-же, то неизменны, за
исключением 0RECORDMODE
С
инвертированным
знаком
№1 01.12.2011
(создан)
Исходные
Т.к. начальные и сторнированные записи совпадают по признакам, то В ОДС
возникает проблема дублирования записей. Необходимо будет добавить
0RECRDMODE для различения исходных документов и операций сторно.
Если отчёт запускается «на дату»:
01.01.2012: документ 1 обнулится и не попадёт в отчёт. Документ 2 попадёт.
31.12.2011: документ 1 обнулится и не попадёт в отчёт. Документ 2 попадёт.
30.12.2011: документ 1 попадёт в отчёт. Документ 2 и сторно документа 1 – не попадёт.
Возьмём случай, когда документ был сторнирован той-же датой, что и создан:
Документ: Поле
историчности
Ключевые
поля
Неключевые
поля
показатели
№2 (взамен
документа № 1)
31.12.2011
(создан)
Могут быть
изменены
Могут быть
изменены
Могут быть
изменены
сторнированный
документ №1
31.12.2011
(сторнирован)
Т.к. запись из MKPF/MSEG
одна и та-же, то неизменны
С
инвертированным
знаком
№1 31.12.2011
(создан)
Исходные
В этом случае не нужно брать в ZFM_STOCK_AND_TURNS_GET документ №1, т.к. он
был сторнирован в том-же кванте времени, в котором был создан.

3. Теперь посмотрим, можно ли не пользоваться номерами документов для дельты.
«Отсечение» номеров документов и, возможно, агрегация по оставшимся аналитикам
происходит ещё в ZFM_STOCK_AND_TURNS_GET. Рассмотрим как происходит это
«отсечение»:

4. В таблицах MKPF+MSEG хранится:
CPUDT Документ: BUDAT –
дата
проводки
Ключевые
поля BW
Неключевые
поля BW
Суммы, объём
01.01.2012,
(создан)
№А2 21.12.2011, B 200
01.01.2012
(сторниров
ан)
№А1 21.12.2011
A
-200
31.12.2011,
(создан)
№Б2 24.12.2011, A 150
31.12.2011
(сторниров
ан)
№Б1 24.12.2011
A
-100
06.12.2011
(создан)
№А1 01.12.2011 A 200
04.12.2011
(создан)
№Б1 03.12.2011 A 100
показано самое подробное поле-номер документа, поле CPUDT изменения документа +
только те поля, которые мы выбираем в BW. Скобками показаныдва запуска дельты.
В первом запуске экстрактор должен выбрать документы:
CPUDT Документ: BUDAT –
дата
проводки
Ключевые
поля BW
Неключевые
поля BW
Суммы, объём
31.12.2011,
(создан)
№Б2 24.12.2011, A 150
31.12.2011
(сторниров
ан)
№Б1 24.12.2011
A
-100
06.12.2011
(создан)
№А1 01.12.2011 A 200
04.12.2011
(создан)
№Б1 03.12.2011 A 100
После отсечения номера документа и без учёта даты создания экстрактор возвратит и в
ODS будут следующие данные:
BUDAT –
дата
проводки
Ключевые
поля BW
Неключевые
поля BW
Суммы, объём
24.12.2011, A 150
24.12.2011
A
-100
01.12.2011 A 200
03.12.2011 A 100
Отчёт можно запускать на любую дату – будет историчность.
Данные в ОДС после второго запуска дельты:

5. BUDAT –
дата
проводки
Ключевые
поля BW
Неключевые
поля BW
Суммы, объём
21.12.2011, B 200
21.12.2011
A
-200
24.12.2011, A 150
24.12.2011 A -100
01.12.2011 A 200
03.12.2011 A 100
Историчностьтоже соблюдается,напримерна 21 число:
21.12.2011, B 200
21.12.2011
A
-200
01.12.2011 A 200
03.12.2011 A 100
B 200
A 100
В данном случае А и B – любые комбинацииключевых инеключевых полей,укоторых,например,
отличаетсятолькономерсклада.
Нужно ли будет переделыватьвсе отчёты?
Там где нужно оставить существующую логику «только на текущий момент» - менять не
нужно, т.к. в инфопровайдере будет хранится та-же информация, что и раньше, плюс
взаимоуничтожающиеся сторнированные документы:
Раньше:
Ключевые
поля
Неключевые
поля
показатели
A B 5
После изменений:
Ключевые
поля
Неключевые
поля
показатели
A B 5
=
-3
3
Итогоиз измененийв BW - нужно будетдобавить в ODS дату проводки,тиражироватьисточник
данных,изменитьцепочку.Предлагаюсделатьсначалатестовыйисточники тестовуюОДС.