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

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

Каждого 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.

soulsurfer,

Факт.
А если заказ полностью отменили?
Или ретроактивно закрыли?
Или ретроактивно открыли (с датой за прошлый месяц)?

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 проблема.

В общем, вижу что предлагаете решение схожее с нашим, и это радует.
Спасибо!

КритикBI_Start,

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

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

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

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

StarikNavy,

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

Описанная мной задача - требования борда по BI отчётности о заказах.
Мы, собственно, и имитируем "сумму "закрытого периода" +правки", только поскольку период в ERP на деле не закрыт, то эту "закрытость" тоже приходится подпирать костылём правок.
Финдир хотел как раз реально закрывать, но в BI. Это вроде попахивает двойным учётом.

George Nordic,

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

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

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

BI-то у нас кстати на Клике. Не написал сразу потому что:
а. Хотел абстрагироваться от специфики инструмента, а пообсуждать именно стратегию.
б. Зная предвзято-пренебрежительное отношение многих здешних спецов к Клику, не хотел завязнуть в холивар на эту тему.

опечатка.
BI_Start от двойного отчёта учёта вроде отбились

Ivan Durakтот самый случай когда автоматизировать бардак может быть и не стоит.
Попробуй разобраться и вывести на чистую воду учёт.
А в чём, по Вашему, здесь бардак?
Что здесь "выводить на чистую воду"?

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

Но вот есть специфическое пожелание борда получать ежемесячный отчёт в таком формате.

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

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

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

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

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

Вот надо борду чтоб срез за прошлый месяц сходился со срезом за этот.
Вот раньше бухи сидели в конце каждого месяца по 3 дня с екселями.
А теперь вносят корректирующие заказы в учётной и уже сидят сильно меньше.
А сейчас финдир хочет полной автоматизации и "прозрачности".
Хочу, говорит, шоб как в банковской распечатке: зашло/ушло.

Ivan DurakавторВот надо борду чтоб срез за прошлый месяц сходился со срезом за этот.
надо просто понять что показывает этот борд??
заказы актуальные на "тогда" ??
заказы подтвержденные?
заказы не отмененные?
Легко.
Борд он Board of Directors. Он не показывает, он смотрит. Актуальные подтвержденные не отмененные заказы на "тогда".

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

Ivan Durak,

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

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

Но мне не кажется что просто добавить поле например "дата_изменения_цены" достаточно.
Надо ещё отдельно сохранить старую цену. А также таких изменений может быть много, и более ранняя дата не сохранится.
То есть для этого надо заводить отдельную таблицу с записью на каждое изменение.
И такая таблица у нас конечно же есть - лог изменений называется.
Но выцарапывать записи из лога изменений для фильтров в отчётах - уже не столь тривиальная задача.
Имхо, проще создать фиктивную запись на каждое изменение в учётной. Тогда для BI всём прозрачно.

Ivan Durak,

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

Ivan Durak,

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

Во-вторых, борд сидит очень высоко, и не вникает в детали и изменения конкретных заказов.
Его интересует общий KPI.
Для контроля мелочей есть сторонний аудит который приходит раз в год и неделю копается в учётной системе вместе с бухами.