AX 2012 R3 Типизация брака (новая аналитика отслеживания)

[skycap]

Коллеги, добрый день.

Стоит задача вести учет категорий брака (мятая упаковка, дырка в кармане, сломана ручка и пр.).
При этом сейчас в системе уже ведется учет состояния товара - годный, брак, которое определяется аналитикой отслеживания "Статус запасов".

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

Сразу возникают вопросы.

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

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

[EVGL]

https://community.dynamics.com/365/f...namics-ax-2012

[skycap]

Цитата:

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

https://community.dynamics.com/365/f...namics-ax-2012

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

[S.Kuskov]

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

[skycap]

Цитата:

Сообщение от S.Kuskov

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

Спасибо.
Предполагается, что тип брака для товаров со статусом запасов "Брак" должен быть заполнен. Каким образом это обеспечить при условии необязательности этой аналитики - это другой вопрос.
Для товаров со статусом запасов "Годный" тип брака соответственно необязателен.

Стоит отметить, что новая аналитика "Тип брака" в строках заказа на продажу будет явно указана, но только для строк со статусом запасов "Брак" - стоит цель собрать товар с конкретным типом брака.

Мы работаем с модулем WHS, поэтому для описанного случая предполагается, что иерархия резервирования будет настроена следующим образом:

- Сайт
- Склад
- Статус запасов
- Владелец (у нас есть владелец товаров)
- Тип брака
- Местоположение
- Номерной знак

По логике вещей вроде бы все нормально.
1. Кейс заказа на продажу с годным товаром.
- Сайт, Склад, Владелец = заполнены
- Статус запасов = Годный
- Тип брака - пусто

Резервирование заказа выполняется по Сайт, Склад, Владелец, Статус запасов.

2. Кейс заказа на продажу с браком
- Сайт, Склад, Владелец = заполнены
- Статус запасов = Брак
- Тип брака = Мятая коробка

Резервирование выполняется по Сайт, Склад, Владелец, Статус запасов, Тип брака.

Вроде бы все хорошо должно быть.

[sukhanchik]

Дилетантский вопрос. А почему нельзя предлагаемую аналитику Тип брака не вводить, а вместо нее использовать стандартную аналитику Статус запасов?
В справочнике статусов запасов есть галка - блокировать движения или нет. Если эта аналитика у Вас всегда будет находиться в значении Брак, то возникает вопрос - какой в ней смысл? (за исключением желания просмотра остатков суммарно по всем типам брака).
Ну т.е. прорабатывался ли вопрос о том, что в роли справочника типов брака использовать справочник статусов запасов?

[skycap]

Цитата:

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

Дилетантский вопрос. А почему нельзя предлагаемую аналитику Тип брака не вводить, а вместо нее использовать стандартную аналитику Статус запасов?
В справочнике статусов запасов есть галка - блокировать движения или нет. Если эта аналитика у Вас всегда будет находиться в значении Брак, то возникает вопрос - какой в ней смысл? (за исключением желания просмотра остатков суммарно по всем типам брака).
Ну т.е. прорабатывался ли вопрос о том, что в роли справочника типов брака использовать справочник статусов запасов?

Да, такую реализацию обсуждали, но отбросили по ряду причин:

1. Главная причина - статус запасов у нас интегрирован с некой сущностью "годный", "брак" с другой КИС (про типы брака она ничего не знает и не будет знать). Поэтому расширение статуса запасов на типы брака в принципе невозможно. Плюс есть ряд внутренних процессов, которые не позволяют это сделать.
2. И да, нужно иметь остатки по типам брака внутри статуса запасов Брак.

[skycap]

Цитата:

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

Если эта аналитика у Вас всегда будет находиться в значении Брак, то возникает вопрос - какой в ней смысл?

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

[TasmanianDevil]

Цитата:

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

статус запасов у нас интегрирован с некой сущностью "годный", "брак" с другой КИС (про типы брака она ничего не знает и не будет знать).

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

Цитата:

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

И да, нужно иметь остатки по типам брака внутри статуса запасов Брак.

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

[skycap]

Цитата:

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

На этом классификаторе - новую складскую аналитику с обязательностью заполнения и контролем выбора только "листа".

Идея как раз в том, чтобы не заполнять новую аналитику для годного товара. Учитывая что % брака несоизмеримо мал по сравнению со стоком, тянуть эту аналитику для годного товара не хочется совсем (да и лишние комбинации складских аналитик плодить не хочется).

Ну в общем накрылась мои идея медным тазом, которая заключалась в том, чтобы заполнять либо не заполнять новую аналитику, в зависимости от статуса запасов. Что было выполнено:

1. Настроена группа аналитик отслеживания с включенной аналитикой "Тип брака", установил галки "Активный", "Пропуск для приходов", "Пропуск для расходов", "Физические запасы".

2. Под эту группу аналитик отслеживания настроена иерархия резервирования:
- Сайт
- Склад
- Статус запасов
- Тип брака (тип брака выше местоположения поскольку требуется резервирование по этой аналитике)
- Местоположение
- Номерной знак

2. При попытке назначить номенклатуре эту иерархию резервирования получаем ошибку:
"Параметры иерархии резервирований не соответствуют параметрам групп аналитик, назначенных данной номенклатуре. Параметры, которые разрешают выдачу и поступление без указания места, должны быть перенесены в низ иерархии резервирований.".
Т.е. нельзя ставить пропуски для прихода\расхода, если аналитика в иерархии выше местоположения.

Но и спустить вниз я ее не могу, поскольку в этом случае понятно, что не получится указать ее явно в строках заказа на продажу (а это обязательное условие):
"В строке заказа указаны аналитики уровня местонахождения и более низких уровней. Дальнейшее использование обработки управления складом для этой строки невозможно."

Замкнутый круг.

[EVGL]

Нет никакого замкнутого круга. Если активизировать Партии, то система умеет проставлять его в заказах автоматически. Вместо того, чтобы не заполнять аналитику, Вы передаете системе задачу его заполнения по умолчанию (это если "выше местоположения" в иерархии).

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

P.S. При переходе придется подрихтовать класс WHSChangeItemHierarchyService, который не допускает изменения иерархии резервирования, если есть проводки в статусе Ordered.

[skycap]

EVGL, простите, но я честно не понимаю, чем мне в данном случае поможет Метод обработки партии. По сути, если я правильно понял, Вы предлагаете вместо новой аналитики отслеживания использовать "Номер партии" (поправьте, пжл, если не так) и концептуально ничего не меняется - я также вынужден буду заполнять эту партию для годного товара, поскольку она будет выше местоположения.
Хочу отметить, что мы не пытаемся решить задачу контроля качества в рамках этого вопроса (не блокируем резервирование, отгрузку брака).

[EVGL]

Цитата:

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

Вы предлагаете вместо новой аналитики отслеживания использовать "Номер партии"

Так точно.

Цитата:

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

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

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

[EVGL]

P.S. Минус в отчетности. Придется эту отдельную колонку вытягивать из партии.

[S.Kuskov]

Цитата:

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

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

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

[skycap]

Спасибо, идея понятна. Будем думать дальше.

[skycap]

Цитата:

Сообщение от S.Kuskov

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

// License Plate is allowed to be blank since it is controlled by location setup, preventing a mix of inventory with/without blank License Plate dimension
if ((inventDimGroupFieldSetup.isAllowBlankIssueEnabled()
    || inventDimGroupFieldSetup.isAllowBlankReceiptEnabled())
    && le.current() != fieldNum(InventDim, LicensePlateId))
{
     ret = checkFailed("@WAX4876");
     break;
}

Судя по комментарию, мы опасаемся смешивания пустых и непустых значений аналитики. Для LP эту проверку реализовали на профиле ячейки, поэтому здесь смело ее добавили в качестве исключения.

В общем интересно и страшно одновременно. Нужно правда тестировать, смотреть что получится с остатками (есть подозрение что WHSInventReserve поплывет).

[Vals]

а почему вы управление качеством не задействуете?
https://docs.microsoft.com/ru-ru/dyn...rance-overview
Просто, понятно и логично

Брак положили в изолятор, выключили его из сводника, продаёте с этого склада брака.
Вообще конечно странная работа у российского манагерства с браком:
- Брак
- Брак, но не совсем
- Брак, но берут


Правило одно: брак никуда не должен уходить! Или в утиль или переделать до качества.

[skycap]

Возврат поставщику

[skycap]

Цитата:

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

а почему вы управление качеством не задействуете?
https://docs.microsoft.com/ru-ru/dyn...rance-overview
Просто, понятно и логично.

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