Показать сообщение отдельно
Старый 13.10.2021, 21:54   #8  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от pitersky Посмотреть сообщение
Что мешает использовать для сквозного трекинга аналитику "Серийный номер"? Она вроде как именно для того и придумана, чтобы отследить всю цепочку отдельно взятой поставки партнамбера
Не совсем.
Во-первых, нужно сразу исключить "Контроль серийных номеров", чтобы можно было один серийный номер установить нескольким штукам (т.е. чтобы был 1 серийный номер у 4 штук товара)
Во-вторых, идеологически предполагается, что серийный номер рождается либо на этапе покупки, либо на этапе производства, но никак не на этапе продажи. Типичный пример - это IMEI-номер телефона / ID процессора / VIN номер автомобиля, т.е. некий уникальный идентификатор, который присваивается производителем и может быть использован любой компанией для целей учета и обращению к производителю. Понятно, что технически прикрутить можно всё, но если ставить вопрос о приближении к стандарту - то серийный номер на идеологическом уровне не является аналитикой "бронирования". Хотя тут возможно задействовать группы нумерации - это правда.
В-третьих, для целей анализа данных, если это возможно - удобно в значении аналитики содержать не бессмысленную номерную серию, а некоторый идентификатор, который содержит осмысленную информацию - в данном случае - номер заказа или лота. Такие вещи не всегда возможны, но в данном случае - поскольку аналитика техническая - то это возможно.
В-четвёртых, даже если будет использована какая-нибудь из уже существующих аналитик - то Вам всё равно придётся допрограммировать её поведение. В этом случае гораздо удобнее завести свою аналитику и уже с ней работать. Особенно в контексте будущего в D365FO, где стандартный код уже не поменяешь. Ну и заодно защититься от неожиданностей в стандартном функционале, которые могут использовать существующую аналитику (в т.ч. серийный номер)

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

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

Последний раз редактировалось sukhanchik; 13.10.2021 в 22:06.