Автоматизация работы маркетплейса

[sukhanchik]

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

В качестве примера - можно рассмотреть аналитику Владелец, которая изначально предназначалась для комиссионной торговли (аналитика связана со справочником клиентов / поставщиков) в России, но уже в D365FO перекочевала в международный функционал.

Но идеологически правильнее проставлять "бронь" номером заказа на продажу или номером лота (=строки заказа на продажу). Этого пока в системе нет, поэтому тут делается доработка по добавлению новой складской аналитики (аналитики отслеживания), которая заполняется в заказе на продажу (точнее в складских проводках при заказе на продажу) по кнопке "забронировать".

Правил цепочек перемещения пока тоже нет. Но тут очень сложно пока представить как эту задачу можно было бы решить на уровне MS. Потому что правила могут зависеть от склада / сайта / ячейки / подразделения (юрлица) / клиента / адреса доставки и т.д. Какого-то общего правила нет - поэтому задача решается в частном случае с учетом особенностей каждой организации

[pitersky]

Цитата:

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

В качестве примера - можно рассмотреть аналитику Владелец, которая изначально предназначалась для комиссионной торговли (аналитика связана со справочником клиентов / поставщиков) в России, но уже в D365FO перекочевала в международный функционал.

Но идеологически правильнее проставлять "бронь" номером заказа на продажу или номером лота (=строки заказа на продажу). Этого пока в системе нет, поэтому тут делается доработка по добавлению новой складской аналитики (аналитики отслеживания), которая заполняется в заказе на продажу (точнее в складских проводках при заказе на продажу) по кнопке "забронировать".

Что мешает использовать для сквозного трекинга аналитику "Серийный номер"? Она вроде как именно для того и придумана, чтобы отследить всю цепочку отдельно взятой поставки партнамбера

[sukhanchik]

Цитата:

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

Что мешает использовать для сквозного трекинга аналитику "Серийный номер"? Она вроде как именно для того и придумана, чтобы отследить всю цепочку отдельно взятой поставки партнамбера

Не совсем.
Во-первых, нужно сразу исключить "Контроль серийных номеров", чтобы можно было один серийный номер установить нескольким штукам (т.е. чтобы был 1 серийный номер у 4 штук товара)
Во-вторых, идеологически предполагается, что серийный номер рождается либо на этапе покупки, либо на этапе производства, но никак не на этапе продажи. Типичный пример - это IMEI-номер телефона / ID процессора / VIN номер автомобиля, т.е. некий уникальный идентификатор, который присваивается производителем и может быть использован любой компанией для целей учета и обращению к производителю. Понятно, что технически прикрутить можно всё, но если ставить вопрос о приближении к стандарту - то серийный номер на идеологическом уровне не является аналитикой "бронирования". Хотя тут возможно задействовать группы нумерации - это правда.
В-третьих, для целей анализа данных, если это возможно - удобно в значении аналитики содержать не бессмысленную номерную серию, а некоторый идентификатор, который содержит осмысленную информацию - в данном случае - номер заказа или лота. Такие вещи не всегда возможны, но в данном случае - поскольку аналитика техническая - то это возможно.
В-четвёртых, даже если будет использована какая-нибудь из уже существующих аналитик - то Вам всё равно придётся допрограммировать её поведение. В этом случае гораздо удобнее завести свою аналитику и уже с ней работать. Особенно в контексте будущего в D365FO, где стандартный код уже не поменяешь. Ну и заодно защититься от неожиданностей в стандартном функционале, которые могут использовать существующую аналитику (в т.ч. серийный номер)

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

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

[Vals]

Цитата:

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

Не совсем.
Во-первых, нужно сразу исключить "Контроль серийных номеров", чтобы можно было один серийный номер установить нескольким штукам (т.е. чтобы был 1 серийный номер у 4 штук товара)
Во-вторых, идеологически предполагается, что серийный номер рождается либо на этапе покупки, либо на этапе производства, но никак не на этапе продажи. Типичный пример - это IMEI-номер телефона / ID процессора / VIN номер автомобиля, т.е. некий уникальный идентификатор, который присваивается производителем и может быть использован любой компанией для целей учета и обращению к производителю. Понятно, что технически прикрутить можно всё, но если ставить вопрос о приближении к стандарту - то серийный номер на идеологическом уровне не является аналитикой "бронирования". Хотя тут возможно задействовать группы нумерации - это правда.
В-третьих, для целей анализа данных, если это возможно - удобно в значении аналитики содержать не бессмысленную номерную серию, а некоторый идентификатор, который содержит осмысленную информацию - в данном случае - номер заказа или лота. Такие вещи не всегда возможны, но в данном случае - поскольку аналитика техническая - то это возможно.
В-четвёртых, даже если будет использована какая-нибудь из уже существующих аналитик - то Вам всё равно придётся допрограммировать её поведение. В этом случае гораздо удобнее завести свою аналитику и уже с ней работать. Особенно в контексте будущего в D365FO, где стандартный код уже не поменяешь. Ну и заодно защититься от неожиданностей в стандартном функционале, которые могут использовать существующую аналитику (в т.ч. серийный номер)

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

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

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