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

[sukhanchik]

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

[skycap]

Цитата:

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

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

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

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

[TasmanianDevil]

Цитата:

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

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

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

Цитата:

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

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

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

[skycap]

Цитата:

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

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

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

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

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

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

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

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

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

[skycap]

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

[EVGL]

Цитата:

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

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

Так точно.

Цитата:

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

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

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

[S.Kuskov]

Цитата:

Сообщение от 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 поплывет).

[skycap]

Цитата:

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

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

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