Аналитика по отмененным заказам

[AXcons]

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

Был заказ клиента. Его скомплектовали на складе. Проводка Скомплектовано.
Потом клиент позвонил отказался. Не буду, говорит. Ок, товар раскомплектовали, проводка раскомплектовалась, удалилась. Но нужна статистика таких заказов для отчетности. Где сохранить эти сведения? Сколько было собрано, а потом разобрано по какому заказу.

Более сложные условия.
Представим, что это екоммерс, интернет-торговля.
Вводные данные те же - собрали, клиент позвонил, отказался. Здесь процесс сложнее, потому что заказы забирает транспортная компания, и склад может получить информацию об отмене поздно, и заказ уже будет отгружен в ТК, нов системе об этом данных пока не будет, потому что отгрузка закрывается не сразу. То есть автоматом с проводками ничего делать нельзя. Поэтому вопрос - какая система статусов должна быть у заказа в этом процессе - клиент позвонил - мы просим склад раскомплектовать заказ - заказ раскомплектован - или товар отгружен.
Тут самый главный вопрос предоплаченных заказов - чтобы деньги не вернуть за заказ, ушедший на доставку.
Поэтому следующий вопрос - есть заявки на возврат денег. Как убедиться, что заказ фактически отменен перед тем, как делать платеж. Убедиться автоматически, понятно. Варианты - не давать создавать заявки пока не ясен статус заказа? Платежи делают в 1С, не очень хочется там допиливать поиск заказ в Аксапте, к тому же бухгалтер легко это обойдет, не введя номер заказа.

[mazzy]

Цитата:

Сообщение от AXcons

Аналитическая задачка для консультантов.
...
Где сохранить эти сведения?

Сохранять? Что значит "сохранять" в контексте консультантов?
Или все-таки речь о доработке?

Цитата:

Сообщение от AXcons

Потом клиент позвонил отказался. Не буду, говорит. Ок, товар раскомплектовали, проводка раскомплектовалась, удалилась.

Что значит "удалилась"? Что именно удалилось? Почему само удалилась?

Если клиент отказался, то почему действие останавливается на раскомплектовани?
Ведь есть же функция "Отменить заказ". Эта функция меняет статус заказа. По заказам со статусам Отменено и надо делать отчетность по отмененным заказам. Разве не?

Или что-то другое подразумевалось?
В общем, можно еще раз сформулировать задачу? и четко указать - допустима доработка или только стандартный функционал

[AXcons]

Цитата:

Сообщение от mazzy

Сохранять? Что значит "сохранять" в контексте консультантов?
Или все-таки речь о доработке?


Что значит "удалилась"? Что именно удалилось? Почему само удалилась?

Если клиент отказался, то почему действие останавливается на раскомплектовани?
Ведь есть же функция "Отменить заказ". Эта функция меняет статус заказа. По заказам со статусам Отменено и надо делать отчетность по отмененным заказам. Разве не?

Или что-то другое подразумевалось?
В общем, можно еще раз сформулировать задачу? и четко указать - допустима доработка или только стандартный функционал

Доработки, конечно.
Сохранять в смысле нам нужны данные в системе, чтобы потом по ним строить отчетность.
Почему проводка удалилась? Количество "К поставке" обнулилось, и проводка удалилась. А как иначе?
Заказ понятно будет в статусе Отменено, но для аналитики нужны цифры - количества, артикулы - сколько отменилось (именно на этом этапе) в штуках, в деньгах. А по изначальному количеству это считать нельзя, потому что это другая цифра. У вас могли заказать три позиции, по одной из них нет резерва, вторую не нашли на складе, третью собрали, но клиент отказался. Вот эта третья позиция должна попасть в категорию "Клиент отказался", которую не нашли на складе в категорию "Не нашли на складе" и т.д. То есть нужна нормальная развернутая статистика процесса.

[mazzy]

Цитата:

Сообщение от AXcons

Почему проводка удалилась? Количество "К поставке" обнулилось, и проводка удалилась. А как иначе?

Вы говорите о складской проводке?

складские проводки не удаляются обычно.
Аксапта может расщепить, суммировать, сменить статус складских движений с одинаковым лотом.

но удалить Аксапта может только складскую проводку в статусе заказано.
по крайней мере стандартная аксапта.

как раз отмена строки заказа и приводит к тому, что Аксапта меняет статус складских движений на Заказано и удаляет складские движения. пока не отменили строку заказа, складские движения удаляться не должны.

==================
а вообще говоря, разукомплектовывать можно и без отмены. просто по внутренним складским причинам. или возник более срочный заказ.

другими словами, разукомплектовывание != отмена.

[AXcons]

Цитата:

Сообщение от mazzy

Вы говорите о складской проводке?

...
как раз отмена строки заказа и приводит к тому, что Аксапта меняет статус складских движений на Заказано и удаляет складские движения. пока не отменили строку заказа, складские движения удаляться не должны.

Ну я об этом и говорю, этим механизмом и удаляется.
Просто как раз в стандартной аксапте нет кнопки Оменить заказ, он отменяется сам, когда у него осталось ноль к поставке. Но сейчас речь не об этом, суть задачи в другом.

[AXcons]

Цитата:

Сообщение от mazzy

==================
а вообще говоря, разукомплектовывать можно и без отмены. просто по внутренним складским причинам. или возник более срочный заказ.

другими словами, разукомплектовывание != отмена.

1. У нас так не бывает
2. Поэтому и нельзя ориентироваться только на статус заказа, а нужны цифры - сколько именно отменено по просьбе клиента.

[mnt_dx]

Цитата:

Сообщение от AXcons

1. У нас так не бывает
2. Поэтому и нельзя ориентироваться только на статус заказа, а нужны цифры - сколько именно отменено по просьбе клиента.

Тут как считать
a) клиент отказался от того, что ему нашли на складе и берём эту цифру
или
b) от всего заказа целиком - считаем весь заказ потерей, даже если чего-то у нас не было

[Logger]

Цитата:

Сообщение от AXcons

Был заказ клиента. Его скомплектовали на складе. Проводка Скомплектовано.
Потом клиент позвонил отказался. Не буду, говорит. Ок, товар раскомплектовали, проводка раскомплектовалась, удалилась. Но нужна статистика таких заказов для отчетности. Где сохранить эти сведения? Сколько было собрано, а потом разобрано по какому заказу.

InventSumLogTTS ?

[mazzy]

Цитата:

Сообщение от Logger

InventSumLogTTS ?

сводное планирование использует эти записи для планирования и удаляет после расчета плана.

и еще: в этой таблице записи не появляются, если выключен лицензионный ключ на сводное планирование.

[AXcons]

Цитата:

Сообщение от Logger

InventSumLogTTS ?

Это такая здоровая табличка? Мы, кажется, ее чистили как-то чтобы места не занимала. А что там храниться? Никогда как-то не пользовались.

Сводное планирование мы не используем.

[EVGL]

В стандартной AX2012 R3 есть кнопка "Отменить заказ". К сожалению, она работает только по заказам, которые разукомплектованы, и удаляет их с потрохами (привет Mazzy). С отгруженными, однако, кнопке на работает.

Отсутствие статуса оплачено или какой-либо связи оплаты с заказом - это вечная, мучительная, заноза в DAX. Чтобы тут обойтись без программирования - это только через убеждение спонсора проекта, что в систему заложена великая концепция, и ей надо слепо следовать.

По существу задачи: имеем на текущем проекте сходный букет проблем и решаем классически: в закупках аналогичная задача отслеживания истории изменения заказов решается через принудительное формирование подтверждений. Почему бы и здесь не пойти тем же путем? В конце сравниваем то, что фактически отгружено (т.е. сумму по складским проводкам) с количеством в подтверждении.

[Vadik]

Цитата:

Сообщение от EVGL

Отсутствие статуса оплачено или какой-либо связи оплаты с заказом - это вечная, мучительная, заноза в DAX. Чтобы тут обойтись без программирования - это только через убеждение спонсора проекта, что в систему заложена великая концепция, и ей надо слепо следовать

Вероятно это потому что оплачивается на заказ, а накладная (накладные) по заказу. А если поменять постановку со "статуса оплаты по заказу" на "статус оплаты по инвойсу", то оказывается что программировать в общем-то и нечего - см. remainAmountXXX методы на CustInvoiceJour

[AXcons]

Цитата:

Сообщение от Vadik

Вероятно это потому что оплачивается на заказ, а накладная (накладные) по заказу. А если поменять постановку со "статуса оплаты по заказу" на "статус оплаты по инвойсу", то оказывается что программировать в общем-то и нечего - см. remainAmountXXX методы на CustInvoiceJour

Проблема то с предоплатой, не с постоплатой. Инвойса еще нет.

[EVGL]

Цитата:

Сообщение от Vadik

Вероятно это потому что оплачивается на заказ, а накладная (накладные) по заказу. А если поменять постановку со "статуса оплаты по заказу" на "статус оплаты по инвойсу", то оказывается что программировать в общем-то и нечего - см. remainAmountXXX методы на CustInvoiceJour

Это все понятно, но:
1) В практике все больше MTO и ETO бизнесов (индустрия 4.0, так сказать), так что смена постановки не отражает сути процесса.
2) И в consumer, как правило, 1 заказ = 1 оплата = 1 счет
3) То, что я не договорил, но AXcons справедливо упомянула: в отличии от закупок, в заказах все еще нет штатного средства работы с предоплатами помимо знаменитой чешской фичи.
4) AR и Sales - два разных отдела.

[mazzy]

Цитата:

Сообщение от EVGL

нет штатного средства работы с предоплатами помимо знаменитой чешской фичи.

не надо!

только не это, шеф. только не это!
https://www.youtube.com/watch?v=cywTOdr1_po

[mazzy]

Цитата:

Сообщение от EVGL

(привет Mazzy).

привет, EVGL.

1. кнопка
2. отмененный заказ в базе существует в базе со всеми потрохами, но без складских движений.

[AXcons]

Цитата:

Сообщение от mazzy

привет, EVGL.

1. кнопка
.

У нас 2009я. Там вроде в жизни такой кнопки не было.

[mazzy]

Цитата:

Сообщение от AXcons

У нас 2009я. Там вроде в жизни такой кнопки не было.

если девочка назовет свое имя...
или версию своей аксапты...

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

деталей я уже не помню.
но достаточно поискать по перекрестным ссылкам как используется значение enum.

[AXcons]

Цитата:

Сообщение от mazzy

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

Так я об этом и говорю - заказ переходит в статус Отменен, только когда ни по одной строке не осталось количества "К поставке", и нет инвойсов.
И это большая проблема. Мы приделали, конечно, кнопки какие нужно. Но в стандарте такой кнопки отродясь не было, о чем я и говорю.

[AXcons]

Цитата:

Сообщение от EVGL

Отсутствие статуса оплачено или какой-либо связи оплаты с заказом - это вечная, мучительная, заноза в DAX. Чтобы тут обойтись без программирования - это только через убеждение спонсора проекта, что в систему заложена великая концепция, и ей надо слепо следовать.

Мы доработали сопоставления, у нас платежи можно загружать в разрезе номеров заказов, и они будут автоматически сопоставлены. Правда, в интерфейс заказа это не выводили.

Цитата:

Сообщение от EVGL

По существу задачи: имеем на текущем проекте сходный букет проблем и решаем классически: в закупках аналогичная задача отслеживания истории изменения заказов решается через принудительное формирование подтверждений. Почему бы и здесь не пойти тем же путем? В конце сравниваем то, что фактически отгружено (т.е. сумму по складским проводкам) с количеством в подтверждении.

Ок, подтверждение (ну или документ с фактом комплектации) мы сохраним допустим, а как понять, что по нему не было отгрузки? То есть все равно в момент раскомплектации нужно найти этот документ и там что-то проставить. Или имеется в виду, что мы ставим фильтр по отмененным заказам, и в них просто берем значения из этого подтверждения сколько было скомплектовано перед отменой? То же самое можно в строке заказа хранить наверное. Вопрос только сразу встает с докомплектацией, когда частями комплектовалось.