ݺߣ

ݺߣShare a Scribd company logo

По результатам беседы по телефону

•Download as DOCX, PDF•
•
Andrew Dorfman
Andrew Dorfman
1 of 5
Download to read offline
По результатам беседы по телефону: Разберём что мы имеем сейчас: источник данных: 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, отчёт на дату, в том числе на прошлую дату, будет эти изменения показывать. Для сторнированных документов необходимо заменять дату проводки на дату проводки сторнировавшего его документа. То есть фактически проводка с минусом в ОДС или в кубе должна произойти на дату сторнирования.
Рассмотрим, как исходные данные будут попадать в отчёт в разных случаях. Если часть данных (несколько документов) была, например, перемещена на другой склад, переоценена и т.п., то данные в ОДС будут следующие: Дата проводки (по убыванию) Ключевые поля Неключевые поля Показатели 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, т.к. он был сторнирован в том-же кванте времени, в котором был создан.
Теперь посмотрим, можно ли не пользоваться номерами документов для дельты. «Отсечение» номеров документов и, возможно, агрегация по оставшимся аналитикам происходит ещё в ZFM_STOCK_AND_TURNS_GET. Рассмотрим как происходит это «отсечение»:
В таблицах 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 Отчёт можно запускать на любую дату – будет историчность. Данные в ОДС после второго запуска дельты:
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 дату проводки,тиражироватьисточник данных,изменитьцепочку.Предлагаюсделатьсначалатестовыйисточники тестовуюОДС.

More Related Content

По результатам беседы по телефону

  • 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 дату проводки,тиражироватьисточник данных,изменитьцепочку.Предлагаюсделатьсначалатестовыйисточники тестовуюОДС.