14.02.2017, 17:29 | #1 |
Участник
|
Аналитика по отмененным заказам
Аналитическая задачка для консультантов. Проверим заодно, есть ли вы тут...
Топик из разряда чисто поговорить, потому что решение я найду, но люблю обсуждать свои мысли, а сейчас не с кем, все заняты. Так что, если кому скучно - велкам. Был заказ клиента. Его скомплектовали на складе. Проводка Скомплектовано. Потом клиент позвонил отказался. Не буду, говорит. Ок, товар раскомплектовали, проводка раскомплектовалась, удалилась. Но нужна статистика таких заказов для отчетности. Где сохранить эти сведения? Сколько было собрано, а потом разобрано по какому заказу. Более сложные условия. Представим, что это екоммерс, интернет-торговля. Вводные данные те же - собрали, клиент позвонил, отказался. Здесь процесс сложнее, потому что заказы забирает транспортная компания, и склад может получить информацию об отмене поздно, и заказ уже будет отгружен в ТК, нов системе об этом данных пока не будет, потому что отгрузка закрывается не сразу. То есть автоматом с проводками ничего делать нельзя. Поэтому вопрос - какая система статусов должна быть у заказа в этом процессе - клиент позвонил - мы просим склад раскомплектовать заказ - заказ раскомплектован - или товар отгружен. Тут самый главный вопрос предоплаченных заказов - чтобы деньги не вернуть за заказ, ушедший на доставку. Поэтому следующий вопрос - есть заявки на возврат денег. Как убедиться, что заказ фактически отменен перед тем, как делать платеж. Убедиться автоматически, понятно. Варианты - не давать создавать заявки пока не ясен статус заказа? Платежи делают в 1С, не очень хочется там допиливать поиск заказ в Аксапте, к тому же бухгалтер легко это обойдет, не введя номер заказа. |
|
14.02.2017, 17:54 | #2 |
Участник
|
Цитата:
Или все-таки речь о доработке? Цитата:
Если клиент отказался, то почему действие останавливается на раскомплектовани? Ведь есть же функция "Отменить заказ". Эта функция меняет статус заказа. По заказам со статусам Отменено и надо делать отчетность по отмененным заказам. Разве не? Или что-то другое подразумевалось? В общем, можно еще раз сформулировать задачу? и четко указать - допустима доработка или только стандартный функционал |
|
14.02.2017, 18:00 | #3 |
Участник
|
Цитата:
Сообщение от AXcons
Был заказ клиента. Его скомплектовали на складе. Проводка Скомплектовано.
Потом клиент позвонил отказался. Не буду, говорит. Ок, товар раскомплектовали, проводка раскомплектовалась, удалилась. Но нужна статистика таких заказов для отчетности. Где сохранить эти сведения? Сколько было собрано, а потом разобрано по какому заказу. |
|
14.02.2017, 18:01 | #4 |
Участник
|
|
|
14.02.2017, 18:02 | #5 |
Участник
|
Цитата:
Сообщение от mazzy
Сохранять? Что значит "сохранять" в контексте консультантов?
Или все-таки речь о доработке? Что значит "удалилась"? Что именно удалилось? Почему само удалилась? Если клиент отказался, то почему действие останавливается на раскомплектовани? Ведь есть же функция "Отменить заказ". Эта функция меняет статус заказа. По заказам со статусам Отменено и надо делать отчетность по отмененным заказам. Разве не? Или что-то другое подразумевалось? В общем, можно еще раз сформулировать задачу? и четко указать - допустима доработка или только стандартный функционал Сохранять в смысле нам нужны данные в системе, чтобы потом по ним строить отчетность. Почему проводка удалилась? Количество "К поставке" обнулилось, и проводка удалилась. А как иначе? Заказ понятно будет в статусе Отменено, но для аналитики нужны цифры - количества, артикулы - сколько отменилось (именно на этом этапе) в штуках, в деньгах. А по изначальному количеству это считать нельзя, потому что это другая цифра. У вас могли заказать три позиции, по одной из них нет резерва, вторую не нашли на складе, третью собрали, но клиент отказался. Вот эта третья позиция должна попасть в категорию "Клиент отказался", которую не нашли на складе в категорию "Не нашли на складе" и т.д. То есть нужна нормальная развернутая статистика процесса. |
|
14.02.2017, 18:05 | #6 |
Участник
|
|
|
14.02.2017, 18:15 | #7 |
Участник
|
Цитата:
складские проводки не удаляются обычно. Аксапта может расщепить, суммировать, сменить статус складских движений с одинаковым лотом. но удалить Аксапта может только складскую проводку в статусе заказано. по крайней мере стандартная аксапта. как раз отмена строки заказа и приводит к тому, что Аксапта меняет статус складских движений на Заказано и удаляет складские движения. пока не отменили строку заказа, складские движения удаляться не должны. ================== а вообще говоря, разукомплектовывать можно и без отмены. просто по внутренним складским причинам. или возник более срочный заказ. другими словами, разукомплектовывание != отмена. |
|
14.02.2017, 18:33 | #8 |
Участник
|
Цитата:
Просто как раз в стандартной аксапте нет кнопки Оменить заказ, он отменяется сам, когда у него осталось ноль к поставке. Но сейчас речь не об этом, суть задачи в другом. |
|
14.02.2017, 18:35 | #9 |
Участник
|
Цитата:
2. Поэтому и нельзя ориентироваться только на статус заказа, а нужны цифры - сколько именно отменено по просьбе клиента. |
|
14.02.2017, 19:04 | #10 |
Участник
|
Цитата:
a) клиент отказался от того, что ему нашли на складе и берём эту цифру или b) от всего заказа целиком - считаем весь заказ потерей, даже если чего-то у нас не было |
|
14.02.2017, 19:08 | #11 |
Участник
|
Цитата:
Потерей считается то, что мы могли продать, но не продали. А именно столько, сколько склад собрал, но не отгрузил. Обсуждается вопрос именно технической реализации. |
|
14.02.2017, 20:45 | #12 |
Участник
|
Шукайте, бабоньки, шукайте. Должон быть...
Цитата:
мы могли продать != сколько склад собрал. хотя бы потому, что заказ можно отменить раньше, чем создать документ на комплектацию. хотя бы потому, что склад может собирать не только под заказ на продажу. есть еще производственный заказ, заказ на перемещение и другие документы... Разберитесь с терминологией и сущностями, нарисуйте квадратики и вам сразу станет ясно. Но хозяин - барин. |
|
|
За это сообщение автора поблагодарили: EVGL (0). |
15.02.2017, 00:09 | #13 |
Banned
|
В стандартной AX2012 R3 есть кнопка "Отменить заказ". К сожалению, она работает только по заказам, которые разукомплектованы, и удаляет их с потрохами (привет Mazzy). С отгруженными, однако, кнопке на работает.
Отсутствие статуса оплачено или какой-либо связи оплаты с заказом - это вечная, мучительная, заноза в DAX. Чтобы тут обойтись без программирования - это только через убеждение спонсора проекта, что в систему заложена великая концепция, и ей надо слепо следовать. По существу задачи: имеем на текущем проекте сходный букет проблем и решаем классически: в закупках аналогичная задача отслеживания истории изменения заказов решается через принудительное формирование подтверждений. Почему бы и здесь не пойти тем же путем? В конце сравниваем то, что фактически отгружено (т.е. сумму по складским проводкам) с количеством в подтверждении. |
|
15.02.2017, 02:17 | #14 |
Модератор
|
Вероятно это потому что оплачивается на заказ, а накладная (накладные) по заказу. А если поменять постановку со "статуса оплаты по заказу" на "статус оплаты по инвойсу", то оказывается что программировать в общем-то и нечего - см. remainAmountXXX методы на CustInvoiceJour
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
15.02.2017, 06:58 | #15 |
Участник
|
привет, EVGL.
1. кнопка 2. отмененный заказ в базе существует в базе со всеми потрохами, но без складских движений. |
|
15.02.2017, 07:20 | #16 |
Участник
|
я, скорее всего, сегодня не смогу принять участие в обсуждении.
конечная мысль такая: в аксапте существует два механизма для комплектации по заказу: 1. pick из строчки заказа - не оставляет документ, меняет только складские проводки 2. picking list registration - оставляет документ так вот, если хочется оставить след и получать отчетность по отмененным комплектациям, то нужно пользоваться только вторым способом и НЕ нужно использовать первый (закрыть полностью. например, правами) отмененный picking list вполне остается в системе для отмененного заказа. но я еще раз повторю: мы могли продать != сколько склад собрал. |
|
15.02.2017, 09:46 | #17 |
Участник
|
Цитата:
Если уже есть заявка на возврат - пересчитывать при изменении количества мб массовые расстрелы? Последний раз редактировалось potential; 15.02.2017 в 09:52. |
|
15.02.2017, 09:51 | #18 |
Участник
|
1) Можно сделать доработку: добавить в строку заказа поле "Максимально было скомплектовано". На метод update() в таблице InventTrans добавить код, который при переходе проводки по заказу в статус "Скомплектовано" сравнивает суммарное количество скомплектованных по строке заказа проводок с уже сохраненным количеством в поле "Максимально было скомплектовано" в строке заказа. И если новая проводка увеличивает это количество, то обновлять его.
Если у вас часто раскомплектовывают, а потом заново скомплектовывают, а вам надо знать сумарно скомплектованное количество, то всегда увеличивать значение поля "Максимально было скомплектовано" при переходе складской проводки в статус "Скомплектовано" из более низкого статуса. 2) Если у вас используются Маршруты комплектации, про которые говорил Маззи, то можно просто считать сумму по количеству из всех маршрутов, в том числе в статусе "Отменено". Там в поле WMSOrderTrans.Qty хранится скомплектованное количество. Но! В этом поле хранится заданное к комплектации количество, а по факту могли скомплектовать меньше. |
|
15.02.2017, 10:47 | #19 |
Модератор
|
Цитата:
Цитата:
но я еще раз повторю:
мы могли продать != сколько склад собрал
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
15.02.2017, 11:06 | #20 |
Участник
|
|
|