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

[Lucky13]

Процесс примерно такой: клиент заказывает товары и в систему поступает заказ. Далее нужные товары перемещаются в распределительный центр (прием товара на центральный склад не рассматриваем), а потом в пункт выдачи.

Каждому товару в заказе присваивается уникальный штрихкод для отслеживания, так как не всегда отгружаются все строки заказа одновременно и статусы отправляются клиенту по каждому товару отдельно.

Вопрос, как такой процесс лучше реализовать в аксапте? Имеется в виду стандартный функционал, напрограммировать понятное дело можно. Версия значения не имеет. В идеале хотелось бы понять какие отличия есть в разных версиях системы, так как во времена 3.0 интернет продажи не были так развиты как сейчас. Возможно в функционале новых версий есть что-то более подходящее, чего не было в старых

[vmoskalenko]

Цитата:

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

Процесс примерно такой: клиент заказывает товары и в систему поступает заказ.

Sales Order

Цитата:

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

Далее нужные товары перемещаются в распределительный центр (прием товара на центральный склад не рассматриваем), а потом в пункт выдачи.

Зря что не рассматриваем. Но к сожалению, у меня тут есть пробелы в знаниях.
Но я знаю, что тут можно создать автоматически Purchase Orders у разных поставщиков и/или Transfer Orders для пополнения основного склада отгрузки.

Цитата:

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

Каждому товару в заказе присваивается уникальный штрихкод для отслеживания, так как не всегда отгружаются все строки заказа одновременно и статусы отправляются клиенту по каждому товару отдельно.

Используется Packing Slip - это по факту ТТН (Товарно-Транспортная Накладная).

Invoice (Расходная Накладная) надо генерировать не с того что указано в Sales Order, а с одного или нескольких Packing Slip.

Кстати, статус Sales Order, который на заголовке, - это по факту минимальный статус среди всех строк Sales Order. Так что можо (и нужно) отслеживать статус заказа по строкам.

Сам заказ может быть полностью скомплектованным или частично. Полностью отправленным или частично. И т.п.

Включая разные случаи, когда имеется один Sales Order, штук 5 складов, 7 разных отправок (Packing Slip) и 4 разных Invoices - потому что разные склады и/или Юр. Лица.

Кстати, Адрес доставки может быть разным для строк одного заказа. Это - в стандартной Аксапте. Иногда это мешает.

А вот про оплату всего этого - рекомендую задуматься чуть позже, когда разберётесь с Sales Order.

Цитата:

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

Вопрос, как такой процесс лучше реализовать в аксапте? Имеется в виду стандартный функционал, напрограммировать понятное дело можно. Версия значения не имеет. В идеале хотелось бы понять какие отличия есть в разных версиях системы, так как во времена 3.0 интернет продажи не были так развиты как сейчас. Возможно в функционале новых версий есть что-то более подходящее, чего не было в старых

В 3.0 не было Transfer Order - он появился в 4.0
Всё остальное - стандартный функционал.

[Lucky13]

Цитата:

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

Кстати, статус Sales Order, который на заголовке, - это по факту минимальный статус среди всех строк Sales Order. Так что можо (и нужно) отслеживать статус заказа по строкам.

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

А как показать где товар по этой строке находится?
Например:
Строка 1: Заказ открыт
Строка 2: Отгружено с центрального склада
Строка 3: Принято в распределительном центре
Строка 4: Отгружено из распределительного центра
Строка 5: Принято в пункте выдачи
Строка 6: Выдано клиенту

В общем случае складов может быть больше и когда между ними делается TransferOrder, как это отразится на статусе строк SalesOrder?

Как я понимаю, если в SalesOrder указывается склад, с которого товар будет отгружен клиенту, то все просто. Пусть даже в строках будут разные склады, делается несколько PackingSlip/Invoice и товар отгружен. А здесь нужно товар зарезервировать на центральном складе, потом переместить в нужный пункт выдачи, а потом отгрузить клиенту. И по каждой строке показать эту цепочку перемещений. Мне кажется, статус SalesOrder, даже построчный такого не покажет. Хотя могу ошибаться, давно с аксаптой не работал

[sukhanchik]

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

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

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

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

[Vals]

Цитата:

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

Вопрос, как такой процесс лучше реализовать в аксапте? Имеется в виду стандартный функционал, напрограммировать понятное дело можно. Версия значения не имеет. В идеале хотелось бы понять какие отличия есть в разных версиях системы, так как во времена 3.0 интернет продажи не были так развиты как сейчас. Возможно в функционале новых версий есть что-то более подходящее, чего не было в старых

Какая у вас версия системы?

[Lucky13]

Цитата:

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

Какая у вас версия системы?

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

Цитата:

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

Процедура же "брони" решается путем проставления некоторой складской аналитики у товара, который потом уже "путешествует" до его отгрузки клиенту

Спасибо, аналитика - хорошая идея. Да, ее придется добавлять, но если ничего другого нет, то вполне подойдет

Цитата:

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

Правил цепочек перемещения пока тоже нет

Спасибо за интересную мысль, про это пока даже не думал, надо будет изучить этот вопрос

[pitersky]

Цитата:

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

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

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

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

[sukhanchik]

Цитата:

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

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

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

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

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

[S.Kuskov]

Если предположить что в системе ведётся учёт каждой единицы товара в разрезе серийных номеров. То можно строки заказа клиента заводить в разрезе реальных серийных номеров, тем самым обеспечивая связь заказа с остатками, без физического резервирования. Нужно только подумать как запретить ввод двух строк с одинаковым серийным номером.

[Lucky13]

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

Как кстати с этим в аксапте? В стандартном функционале это, как я понимаю, не учитывается, придется выкручиваться, через серийный номер, например.

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

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

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

[sukhanchik]

Цитата:

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

Если предположить что в системе ведётся учёт каждой единицы товара в разрезе серийных номеров. То можно строки заказа клиента заводить в разрезе реальных серийных номеров, тем самым обеспечивая связь заказа с остатками, без физического резервирования. Нужно только подумать как запретить ввод двух строк с одинаковым серийным номером.

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

Сроки годности актуальны в пищевой / химической (в т.ч. медицинской) отрасли. Для условной одежды нет сроков годности. Для условных макарон нет сроков годности. Молоко с большим, но истекающим сроком годности можно не брать у поставщика. А вот если продавать "живые" продукты - типа свежей сметаны, сыров или лекарственные препараты, у которых очень маленький срок годности (3-5 суток) - то сроки годности очень даже актуальны.
Поэтому тут сильно зависит от специализации маркетплейса

[Lucky13]

Цитата:

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

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

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

Цитата:

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

Сроки годности актуальны в пищевой / химической (в т.ч. медицинской) отрасли. Для условной одежды нет сроков годности. Для условных макарон нет сроков годности. Молоко с большим, но истекающим сроком годности можно не брать у поставщика. А вот если продавать "живые" продукты - типа свежей сметаны, сыров или лекарственные препараты, у которых очень маленький срок годности (3-5 суток) - то сроки годности очень даже актуальны.
Поэтому тут сильно зависит от специализации маркетплейса

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

[Vals]

Цитата:

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

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

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

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

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

[Vals]

Цитата:

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

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

Посмотрите ролики, здесь как раз по нескольким версиям системы
https://www.youtube.com/user/AMANDorg/playlists

[S.Kuskov]

Цитата:

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

Серийный номер относится к закупке/производству, а здесь нужна аналитика продажи.

Да, вы правы. Подумалось, что в общем случае заказанного товара может ещё и не быть на складе. Его ещё нужно будет заказывать у своих поставщиков. И с каким серийным номером он поступит на склад будет известно позже.

Действительно логично использовать отдельную складскую аналитику связанную с назначением остатков, а не с их происхождением.

[sukhanchik]

Цитата:

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

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

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

[Vals]

Ссылки почитать про функциональность которая может быть использована:
https://docs.microsoft.com/ru-ru/dyn...ement-overview

https://docs.microsoft.com/ru-ru/dyn...-cross-docking

https://docs.microsoft.com/ru-ru/dyn...l-setup-retail

https://docs.microsoft.com/ru-ru/dyn...aster-planning

https://docs.microsoft.com/ru-ru/dyn...-on-commission

docs.microsoft.com/ru-ru/dynamicsax-2012/appuser-itpro/download-sales-orders-from-an-online-store

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

[Lucky13]

А никто случайно не знает, как складской учет устроен в SAP R/3? Там тоже что-то похожее на складскую аналитику, как в аксапте или там как-то иначе устроено? Просто в последнее время поймал себя на мысли, что при проектировании подход аксапты очень удобен: выбираются необходимые аналитики (складские и финансовые), если надо, добавляются новые и на этой основе уже строится модель учета. Поэтому возник вопрос - это общий подход для западных систем учета или в только аксапте придумали такой механизм?