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

[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

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

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

[mazzy]

Цитата:

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

и нет инвойсов.

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

Цитата:

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

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

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

Цитата:

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

Разберитесь с терминологией и сущностями, нарисуйте квадратики и вам сразу станет ясно.

Но хозяин - барин.

[AXcons]

Цитата:

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

дык, отпилите эту проверку.

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

Зачем отпилить проверку? Правильная проверка.
Проблема в том, что общей кнопки отмены нет, а не в том, что наличие инвойса проверяет. Скриншот вы из 2009й приводили или из 12й? Где кнопка то сама? Диалог был только на скриншоте.

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

[AXcons]

Цитата:

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

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

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

Цитата:

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

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

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

[EVGL]

Цитата:

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

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

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