Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 Ретроактивное исправление сумм заказов  [new]
BI_Start
Member

Откуда:
Сообщений: 14
Уважаемые спецы, я биайщик-самоучка, хочется узнать как профи подходят к такой задаче.

Дано (описываю очень упрощённо):

Каждого 1-го числа бухи берут из BI состояние всех заказов и отправляют в board.
Назовём общую сумму заказов на 01/01/18 - X.
С этого момента состояние заказов на эту дату менять нельзя.
1-го следующего месяца (01/02/18) в board отправляют картину заказов зашедших в январе (Y) + картину закрытых (по факту оплаты) в январе заказов (Z) + состояние заказов на 01/02/18 (W)
В итоге board 01/02/18 хотят увидеть следующую картину: X+Y-Z=W

01/01/18 в учётной был заказ на сумму А.
02/01/18 продавец изменил сумму заказа на А/2.
Если ничего не трогать, 01/02/18 в board увидят картину: X+Y-Z > (W-А/2)

Мы сейчас решаем это так:
В учётной сделали форму где можно открывать фиктивные заказы (они идут только в этот отчёт в BI).
Бухи открывают фиктивный заказ на сумму А/2 на 31/12/17
Таким образом выравнивают отосланный 01/01/18 в board Х.
+
Открывают фиктивный заказ на сумму -А/2 на 02/01/18.
Теперь картина такова: (X-А/2+А/2)+(Y-А/2)-Z = (W-А/2)
Сейчас начальство хочет чтобы при изменении сумм в заказах фиктивные заказы открывались учётной автоматически (это сопряжено ещё с рядом вопросов, но речь не о них).

Может, у кого есть более изящное решение?

P.S. Извините за сумбурность описания, описал как смог.
Мне кажется, подобные задачи - классика BI.
13 мар 18, 11:48    [21252334]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
soulsurfer
Member

Откуда:
Сообщений: 324
Заказы и сумма заказа у вас - это факт или измерение?
Если измерение, то делаете SCD2 c valid_from и valid_to. Если факт, то добавляете effective_date в факт, и во всех отчетах впиливаете фильтр на effective_date < <контрольная дата>.
13 мар 18, 12:36    [21252457]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
BI_Start
Member

Откуда:
Сообщений: 14
soulsurfer,

Факт.
А если заказ полностью отменили?
Или ретроактивно закрыли?
Или ретроактивно открыли (с датой за прошлый месяц)?
13 мар 18, 13:36    [21252617]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
vikkiv
Member

Откуда: London
Сообщений: 1577
BI_Start,

IMHO - не соглашусь что к BI, учётные системы это тема/задача скорее для ветки автоматизации процессов ERP (а отчётная часть реализуется просто, по типу операции Δ {изменение} или оригинал).

у тебя временной ряд с отсечкой горизонта времени по первому параметру вида Х0+Y1-Z1=X1 (лишняя переменная W только путает) или Х(n-1)+Y(n)-Z(n)=X(n) или Х(n)+Y(n+1)-Z(n+1)=X(n+1)

Х0 - открытые прошлый период
Y1 - новые новый период
Z1 - закрытые в новый период (из обоих периодов, т.е. из X0 и Y1)
Х1 : Х0+Y1-Z1=X1 (т.е. нетто открытые заказы)

изменение/обновление открытого (хотя если все заказы переносятся на новый период то будет немного по другому - зависит от реализации) заказа X(n-1) или Y(n) на Δ (т.е. если сумма изменилась, по выполнению условия Δ<>0 или Δ<>null если такое состояние возможно)
A) если заказ из прошлого периода Х(n-1) то: дублируется Δ с другим знаком
B) если заказ (новый) из текущего периода Y(n) то:
1) +Δ операции на Х(n-1) , хотя правильнее выражаться судя по твоему описанию +Δ на Х(n-2)
2) -Δ операции на Х(n-1)

ну и логику чтобы бухи по привычке больше не лезли исправлять т.к. система это теперь делает сама - ограничить редактирование или создать дополнительное подтверждение с уведомлением. Т.е. фактически в зависимости от текущей даты - разделить права на ручное редактирование и системное.

ещё раз - лучше подними тему в ERP
13 мар 18, 14:02    [21252723]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30486
Блог
BI_Start,

если брать только ХД, то дельтами сделайте:
10 руб, 2018-01-01 (дата изменения)
+1 руб, 2018-01-02
-5 руб, 2018-01-03

"дату изменения" можно заменить на некий идентификатор изменения,
таблица идентификаторов изменения может содержать дату, пользователя и т.д.
13 мар 18, 14:13    [21252757]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30486
Блог
если же меняются измерения, а не меры, то можно сторнировать заказ и открывать новый
13 мар 18, 14:13    [21252759]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
vikkiv
Member

Откуда: London
Сообщений: 1577
точнее наверное всё не так, для изменений новых текущих заказов - фиктивность не нужна т.к. отчёта за период ещё нет, т.е. корректировать нечего.
для изменений прошлых заказов но ещё открытых - фиктивность нужна, вешаем корректирующий тригер создающий 2 фиктивных +/- записи на нужную Δ : один +Δ ассоциируемый с Y(n) и -Δ ассоциируемый с X(n-1)

другое дело как это должно повлиять на все предшествующие периоды если продолжить цепь (что будет предоставление не верной информации т.к. заказ уменьшился/увеличился сейчас, а не тогда, хотя зависит от интерпретации и целей), каждый период переписывать? (в этом случае перенос всех заказов в новый период как псевдо-новые будет более целесообразен)
13 мар 18, 14:27    [21252792]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
BI_Start
Member

Откуда:
Сообщений: 14
vikkiv,

Спасибо.
Мне не кажется, что это тема для ветки ERP. ERP всё это не надо. У них с учётом всё нормально и прозрачно.
Обсуждаемые здесь методы хоть технически разрабатываются в ERP, но по сути это костыли для BI only.

По терминологии согласен - принимаю терминологию Х(n-1)+Y(n)-Z(n)=X(n).
Только здесь важно оговорить что на момент (n) отчёт Х(n-1) уже месяц как в борде, и там сверяют именно с ним.
То есть они хотят получить от бухов Y(n), Z(n), X(n), а потом уж сами подставить Х(n-1) полученный месяц назад и чтоб равенство сошлось.

Поэтому:
A) если заказ из прошлого периода Х(n-1) то:
1) +Δ на Х(n-2) (чтоб к первому числу Х(n-1) заказ уже был).
2) -Δ операции на Х(n)
B) если заказ (новый) из текущего периода Y(n) то:
Вообще ничего делать не надо, все изменения в периоде между Х(n-1) и Х(n) сами скорректируются в отчёте Х(n).

Соответственно бухам вручную лезть никуда не надо - тригер при изменении сумм за прошлые месяцы сам заполнит +Δ/-Δ в нужной таблице.
Беда только что юзеры могут изменять количество/цену по несколько раз в минуту и не хочется на каждый их чих очередную +Δ/-Δ писать в таблицу.
Но это уж правда больше из области ERP проблема.

В общем, вижу что предлагаете решение схожее с нашим, и это радует.
Спасибо!
13 мар 18, 15:45    [21253043]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
BI_Start
Member

Откуда:
Сообщений: 14
Критик
BI_Start,

если брать только ХД, то дельтами сделайте:
10 руб, 2018-01-01 (дата изменения)
+1 руб, 2018-01-02
-5 руб, 2018-01-03

"дату изменения" можно заменить на некий идентификатор изменения,
таблица идентификаторов изменения может содержать дату, пользователя и т.д.


То есть Вы предлагаете блокировать историческую отчётность и уже не изменять её ретроактивно, вести как бы параллельный учёт в ХД и ERP?
Мы тоже рассматривали этот вариант. Но, имхо, это сложнее чем то что предлагает vikkiv.
Это вместо пары костылей к существующему учёту держать 2 параллельных учёта.

Но спасибо, всегда интересно рассмотреть альтернативный путь.
13 мар 18, 16:46    [21253261]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 1886
BI_Start,

не знаю причем здесь BI, но обычно если вводится понятие "закрытый период" в основной учетной системе, то его исправление (если оно допустимо) ведется в той же учетной системе, новыми (корректирующими) проводками/правками/заказами

соответственно в BI настраивается два варианта - видеть текущий итог (как сумму "закрытого периода" +правки) , так и видеть итог без введенных правок
13 мар 18, 17:25    [21253392]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
George Nordic
Member

Откуда: Moscow
Сообщений: 1041
BI_Start, просто коллеги уже сталкивались и пытаются вас предупредить, что если сами бухгалтера что-то накосячат или в системе что-то пойдет не так (пропадет или изменится какой-то инвойс), то прилетит, и очень серьезно, тому кто подобный проект реализовывал.

2 учета вести - тоже не вариант, они очень сильно разъедутся со временем, намучаетесь поддерживать.

Так что лучше как-то в ERP это все как-то вести, как уже ведется.

А можно поподробнее в чем прикладная задача состоит - сопоставление авансов / отложенные платежи /учет курсовых разниц?
Похоже на проектную деятельность с большой дебеторкой по срокам...

С Уважением,
Георгий
13 мар 18, 18:29    [21253556]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
BI_Start
Member

Откуда:
Сообщений: 14
StarikNavy,

В нашей учетной системе понятие "закрытый период" есть по отношению к финансовым /складским проводкам.
С заказами - нет такого. Нет здесь транзакций.

Описанная мной задача - требования борда по BI отчётности о заказах.
Мы, собственно, и имитируем "сумму "закрытого периода" +правки", только поскольку период в ERP на деле не закрыт, то эту "закрытость" тоже приходится подпирать костылём правок.
Финдир хотел как раз реально закрывать, но в BI. Это вроде попахивает двойным учётом.
13 мар 18, 22:48    [21253941]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
BI_Start
Member

Откуда:
Сообщений: 14
George Nordic,

Да, Вы близки к истине. У нас количество заказов измеряется в десятках/сотнях, а суммы довольно крупные, много проектальных заказов .
Инвойс какой вряд ли пропадёт, их мало, и бухи на каждый с лупой смотрят.

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

Ну да, лепим костыли в ERP, от двойного отчёта вроде отбились.

BI-то у нас кстати на Клике. Не написал сразу потому что:
а. Хотел абстрагироваться от специфики инструмента, а пообсуждать именно стратегию.
б. Зная предвзято-пренебрежительное отношение многих здешних спецов к Клику, не хотел завязнуть в холивар на эту тему.
13 мар 18, 23:08    [21253973]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
BI_Start
Member

Откуда:
Сообщений: 14
опечатка.
BI_Start
от двойного отчёта учёта вроде отбились
13 мар 18, 23:16    [21253987]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3466
тот самый случай когда автоматизировать бардак может быть и не стоит.
Попробуй разобраться и вывести на чистую воду учёт.
14 мар 18, 08:57    [21254264]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30486
Блог
Ivan Durak,

по-вашему это дела BIщика?
14 мар 18, 09:55    [21254411]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3466
Критик
Ivan Durak,

по-вашему это дела BIщика?

хорошего, да. На то он и БИЗНЕС интелидженс, чтобы быть близко к бизнесу и помогать ему принимать решения. А не тупо автоматизировать бардак.
14 мар 18, 10:18    [21254465]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
George Nordic
Member

Откуда: Moscow
Сообщений: 1041
Критик
по-вашему это дела BIщика?
Конечно: "ты такой умный, вот и придумай что-нибудь". А, серьезно, BI-щик - это действительно эксперт, который не просто понимает, в какой системе что лежит, но и для чего К тому же, понимает задачи ключевых сотрудников и ЛПР. Так что абсолютно не удивлен такой задаче. Еще и спросят как оценить эффективность использования собственных и привлеченных ДС и как их отличить в системе

BI_Start, попробуйте поговорить в таком ключе: что именно хочет видеть борд? Судя по задаче, это количество оплаченных заказов за предыдущий период + кол-во открытых, но неоплаченных заказов на конец периода.

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

Удачи!
С Уважением,
Георгий
14 мар 18, 10:22    [21254478]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
BI_Start
Member

Откуда:
Сообщений: 14
Ivan Durak
тот самый случай когда автоматизировать бардак может быть и не стоит.
Попробуй разобраться и вывести на чистую воду учёт.

А в чём, по Вашему, здесь бардак?
Что здесь "выводить на чистую воду"?

Стандартные ситуации: клиент отменил заказ/перенёс на месяц вперёд/получил скидку/бухи не утвердили из-за облиго/etc....
В учётной это нормально, никакого бардака.
Я уж не говорю о стандартнейшей ситуации с изменением курсовых разниц, которая просто не является темой данного поста.

Но вот есть специфическое пожелание борда получать ежемесячный отчёт в таком формате.
14 мар 18, 11:50    [21254869]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
BI_Start
Member

Откуда:
Сообщений: 14
George Nordic
Критик
по-вашему это дела BIщика?
Конечно: "ты такой умный, вот и придумай что-нибудь". А, серьезно, BI-щик - это действительно эксперт, который не просто понимает, в какой системе что лежит, но и для чего К тому же, понимает задачи ключевых сотрудников и ЛПР. Так что абсолютно не удивлен такой задаче. Еще и спросят как оценить эффективность использования собственных и привлеченных ДС и как их отличить в системе

BI_Start, попробуйте поговорить в таком ключе: что именно хочет видеть борд? Судя по задаче, это количество оплаченных заказов за предыдущий период + кол-во открытых, но неоплаченных заказов на конец периода.

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

Удачи!
С Уважением,
Георгий

Да, в общем, довольно ясно что борд хочет получить.
И, конечно, есть море флагов в учётной, определяющих что идёт в отчёт (по клиентам, по счетам, BU, по заказам и т.д.).
Это всё давно заформализировано и работает уже несколько лет.
И в идеале им конечно показывают "как есть".

Но вот что делать если...клиент отменил заказ/перенёс на месяц вперёд/получил скидку/бухи не утвердили из-за облиго/etc....

Вот надо борду чтоб срез за прошлый месяц сходился со срезом за этот.
Вот раньше бухи сидели в конце каждого месяца по 3 дня с екселями.
А теперь вносят корректирующие заказы в учётной и уже сидят сильно меньше.
А сейчас финдир хочет полной автоматизации и "прозрачности".
Хочу, говорит, шоб как в банковской распечатке: зашло/ушло.
14 мар 18, 12:06    [21254936]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3466
автор
Вот надо борду чтоб срез за прошлый месяц сходился со срезом за этот.

надо просто понять что показывает этот борд??
заказы актуальные на "тогда" ??
заказы подтвержденные?
заказы не отмененные?
15 мар 18, 17:30    [21259655]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
BI_Start
Member

Откуда:
Сообщений: 14
Ivan Durak
автор
Вот надо борду чтоб срез за прошлый месяц сходился со срезом за этот.

надо просто понять что показывает этот борд??
заказы актуальные на "тогда" ??
заказы подтвержденные?
заказы не отмененные?

Легко.
Борд он Board of Directors. Он не показывает, он смотрит. Актуальные подтвержденные не отмененные заказы на "тогда".

Как это решает описанную мной проблему?
15 мар 18, 18:22    [21259765]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3466
BI_Start
Ivan Durak
пропущено...

надо просто понять что показывает этот борд??
заказы актуальные на "тогда" ??
заказы подтвержденные?
заказы не отмененные?

Легко.
Борд он Board of Directors. Он не показывает, он смотрит. Актуальные подтвержденные не отмененные заказы на "тогда".

Как это решает описанную мной проблему?

какую бизнес-задачу он решает вы так и не описали.
А проблемы его физически реализовать нет никакой - scd3 подход. Много колонок в факте типа "дата заказа, дата отмены, дата заказа для борда, дата отмены для борда, дата ещехрензнаетдлякакогоотчетаноменяпопросилииядобавил". и собирайте себе хоть по 15 разным паралельным учетам.
Для такой херни сложнее ничего делать не стоит.
19 мар 18, 10:23    [21266853]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
BI_Start
Member

Откуда:
Сообщений: 14
Ivan Durak,

Бизнес-задачу я здесь описал, и не раз.
Возможно, у нас путаница в терминологии, тогда опишите пример бизнес-задач в рамках данного поста.

Насчёт полей с различными датами - в теории это оптимальный способ, мне он нравится больше создания "фиктивных" заказов.
В целом мы так и делаем, у нас много различных полей с датами, и отчёты фильтруются по ним.

Но мне не кажется что просто добавить поле например "дата_изменения_цены" достаточно.
Надо ещё отдельно сохранить старую цену. А также таких изменений может быть много, и более ранняя дата не сохранится.
То есть для этого надо заводить отдельную таблицу с записью на каждое изменение.
И такая таблица у нас конечно же есть - лог изменений называется.
Но выцарапывать записи из лога изменений для фильтров в отчётах - уже не столь тривиальная задача.
Имхо, проще создать фиктивную запись на каждое изменение в учётной. Тогда для BI всём прозрачно.
19 мар 18, 18:09    [21269262]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3466
BI_Start
Борд он Board of Directors. Он не показывает, он смотрит. Актуальные подтвержденные не отмененные заказы на "тогда".

зачем он это делает? Какую пользу несет для него эта информация?
19 мар 18, 18:24    [21269325]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
BI_Start
Member

Откуда:
Сообщений: 14
Ivan Durak,

Вы спрашиваете зачем Board контролирует поступающие заказы и факты их поставки/оплаты и соответствие этих фактов годовым/квартальным/месячным таргетам?
И Вы считаете что от ответа на этот вопрос зависит решение данной проблемы?
19 мар 18, 22:30    [21269794]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3466
BI_Start
Ivan Durak,

Вы спрашиваете зачем Board контролирует поступающие заказы и факты их поставки/оплаты и соответствие этих фактов годовым/квартальным/месячным таргетам?
И Вы считаете что от ответа на этот вопрос зависит решение данной проблемы?

Я уверен, что в таком виде он не может контролировать целиком поступающие заказы. Т.к. не видит какие из них были изменены!!
20 мар 18, 10:47    [21270556]     Ответить | Цитировать Сообщить модератору
 Re: Ретроактивное исправление сумм заказов  [new]
BI_Start
Member

Откуда:
Сообщений: 14
Ivan Durak,

Во-первых, прекрасно может.
В "фиктивных" заказах которые открывают в учётной, и которые видны в BI, есть все данные - и на уровне текстовых ремарок, и на уровне флагов- отмена, изменение цены, изменение кол-ва, скидка и т.д.
А вот если б сделали как Вы предлагаете, точно не смог бы проконтролировать не только конкретные изменения, но и общие суммы не сошлись бы помесячно (я уже объяснил почему).

Во-вторых, борд сидит очень высоко, и не вникает в детали и изменения конкретных заказов.
Его интересует общий KPI.
Для контроля мелочей есть сторонний аудит который приходит раз в год и неделю копается в учётной системе вместе с бухами.
20 мар 18, 12:49    [21271084]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / OLAP и DWH Ответить