AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 12.10.2021, 13:03   #1  
Lucky13 is offline
Lucky13
Участник
1C
 
681 / 161 (7) ++++++
Регистрация: 21.10.2004
Адрес: Воронеж
Автоматизация работы маркетплейса
Процесс примерно такой: клиент заказывает товары и в систему поступает заказ. Далее нужные товары перемещаются в распределительный центр (прием товара на центральный склад не рассматриваем), а потом в пункт выдачи.

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

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

Последний раз редактировалось Lucky13; 12.10.2021 в 13:21.
Старый 12.10.2021, 16:21   #2  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
129 / 308 (11) ++++++
Регистрация: 25.01.2007
Адрес: Kyiv
Цитата:
Сообщение от 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
Всё остальное - стандартный функционал.
Старый 13.10.2021, 11:19   #3  
Lucky13 is offline
Lucky13
Участник
1C
 
681 / 161 (7) ++++++
Регистрация: 21.10.2004
Адрес: Воронеж
Цитата:
Сообщение от vmoskalenko Посмотреть сообщение
Кстати, статус Sales Order, который на заголовке, - это по факту минимальный статус среди всех строк Sales Order. Так что можо (и нужно) отслеживать статус заказа по строкам.
Насколько я помню, статус в строках - это такой же статус, что и в заголовке.

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

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

Как я понимаю, если в SalesOrder указывается склад, с которого товар будет отгружен клиенту, то все просто. Пусть даже в строках будут разные склады, делается несколько PackingSlip/Invoice и товар отгружен. А здесь нужно товар зарезервировать на центральном складе, потом переместить в нужный пункт выдачи, а потом отгрузить клиенту. И по каждой строке показать эту цепочку перемещений. Мне кажется, статус SalesOrder, даже построчный такого не покажет. Хотя могу ошибаться, давно с аксаптой не работал
Старый 13.10.2021, 12:07   #4  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,971 / 2969 (104) +++++++++
Регистрация: 13.06.2004
Адрес: Москва
Тут только главное не путать понятие "резервирование" в понятиях бизнеса (когда нужно по сути "забронировать" товар, а потом его перемещать) и понятие "резервирование" в понятиях системы (когда нужно по сути найти товар).
Процедура же "брони" решается путем проставления некоторой складской аналитики у товара, который потом уже "путешествует" до его отгрузки клиенту.

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

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

Правил цепочек перемещения пока тоже нет. Но тут очень сложно пока представить как эту задачу можно было бы решить на уровне MS. Потому что правила могут зависеть от склада / сайта / ячейки / подразделения (юрлица) / клиента / адреса доставки и т.д. Какого-то общего правила нет - поэтому задача решается в частном случае с учетом особенностей каждой организации
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: Lucky13 (5).
Старый 13.10.2021, 13:24   #5  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,754 / 500 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Цитата:
Сообщение от Lucky13 Посмотреть сообщение
Вопрос, как такой процесс лучше реализовать в аксапте? Имеется в виду стандартный функционал, напрограммировать понятное дело можно. Версия значения не имеет. В идеале хотелось бы понять какие отличия есть в разных версиях системы, так как во времена 3.0 интернет продажи не были так развиты как сейчас. Возможно в функционале новых версий есть что-то более подходящее, чего не было в старых
Какая у вас версия системы?
За это сообщение автора поблагодарили: vmoskalenko (6).
Старый 13.10.2021, 14:54   #6  
Lucky13 is offline
Lucky13
Участник
1C
 
681 / 161 (7) ++++++
Регистрация: 21.10.2004
Адрес: Воронеж
Цитата:
Сообщение от Vals Посмотреть сообщение
Какая у вас версия системы?
Не хотелось бы привязываться к какой-то конкретной версии, потому что цель понять, какие средства есть в системе для реализации данного процесса, а не реализовать его в имеющейся системе. В идеале хотелось бы понять, что полезного, применительно к данному процессу, есть, например в DAX 2012, чего, например, не было в 3.0.

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

Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Правил цепочек перемещения пока тоже нет
Спасибо за интересную мысль, про это пока даже не думал, надо будет изучить этот вопрос
Старый 13.10.2021, 15:11   #7  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,456 / 381 (15) ++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
В качестве примера - можно рассмотреть аналитику Владелец, которая изначально предназначалась для комиссионной торговли (аналитика связана со справочником клиентов / поставщиков) в России, но уже в D365FO перекочевала в международный функционал.

Но идеологически правильнее проставлять "бронь" номером заказа на продажу или номером лота (=строки заказа на продажу). Этого пока в системе нет, поэтому тут делается доработка по добавлению новой складской аналитики (аналитики отслеживания), которая заполняется в заказе на продажу (точнее в складских проводках при заказе на продажу) по кнопке "забронировать".
Что мешает использовать для сквозного трекинга аналитику "Серийный номер"? Она вроде как именно для того и придумана, чтобы отследить всю цепочку отдельно взятой поставки партнамбера
__________________
С уважением,
Вячеслав

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

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

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

Последний раз редактировалось sukhanchik; 13.10.2021 в 22:06.
Старый 13.10.2021, 22:50   #9  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,363 / 1694 (63) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Если предположить что в системе ведётся учёт каждой единицы товара в разрезе серийных номеров. То можно строки заказа клиента заводить в разрезе реальных серийных номеров, тем самым обеспечивая связь заказа с остатками, без физического резервирования. Нужно только подумать как запретить ввод двух строк с одинаковым серийным номером.
Старый 14.10.2021, 09:30   #10  
Lucky13 is offline
Lucky13
Участник
1C
 
681 / 161 (7) ++++++
Регистрация: 21.10.2004
Адрес: Воронеж
Согласен с sukhanchik, что серийный номер относится к закупке/производству, а здесь нужна аналитика продажи. Вести учет каждой единицы отдельно, по-моему, накладно, но с другой стороны маркировка охватывает все больше и больше групп товаров и ходят слухи, что в будущем всё будет маркироваться.

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

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

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

Получается расширяемая складская аналитика в аксапте - это, в данном случае, большой плюс, но не в каждой системе так можно. Либо второй вариант, оперировать сериями, но тогда затрагивается процесс еще и закупки
Старый 14.10.2021, 10:15   #11  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,971 / 2969 (104) +++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Если предположить что в системе ведётся учёт каждой единицы товара в разрезе серийных номеров. То можно строки заказа клиента заводить в разрезе реальных серийных номеров, тем самым обеспечивая связь заказа с остатками, без физического резервирования. Нужно только подумать как запретить ввод двух строк с одинаковым серийным номером.
В "можно строки заказа клиента заводить в разрезе реальных серийных номеров" и основная проблема. Потому что в маркетплейсе предполагается, что заказ на продажу по сути создает клиент (да и в иных организациях любят отталкиваться от формулировки клиента). Собственно, автоматизация и заключается в том, чтобы перенести рутинный технический труд с человека на компьютер.
А запрет ввода двух одинаковых строк решается тем, что эта аналитика заполняется программно. И эта доработка и входит в мою фразу "всё равно придётся допрограммировать её поведение"

Сроки годности актуальны в пищевой / химической (в т.ч. медицинской) отрасли. Для условной одежды нет сроков годности. Для условных макарон нет сроков годности. Молоко с большим, но истекающим сроком годности можно не брать у поставщика. А вот если продавать "живые" продукты - типа свежей сметаны, сыров или лекарственные препараты, у которых очень маленький срок годности (3-5 суток) - то сроки годности очень даже актуальны.
Поэтому тут сильно зависит от специализации маркетплейса
__________________
Возможно сделать все. Вопрос времени
Старый 14.10.2021, 11:18   #12  
Lucky13 is offline
Lucky13
Участник
1C
 
681 / 161 (7) ++++++
Регистрация: 21.10.2004
Адрес: Воронеж
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
В "можно строки заказа клиента заводить в разрезе реальных серийных номеров" и основная проблема. Потому что в маркетплейсе предполагается, что заказ на продажу по сути создает клиент (да и в иных организациях любят отталкиваться от формулировки клиента). Собственно, автоматизация и заключается в том, чтобы перенести рутинный технический труд с человека на компьютер.
А запрет ввода двух одинаковых строк решается тем, что эта аналитика заполняется программно. И эта доработка и входит в мою фразу "всё равно придётся допрограммировать её поведение"
Особый случай, когда группа товаров подлежит обязательной маркировке (обувь, фото-видео техника, фармацевтика, возможно сейчас уже список шире). Тогда каждый экземпляр учитывается отдельно, и возможно в таком случае удобнее действовать как-то иначе

Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Сроки годности актуальны в пищевой / химической (в т.ч. медицинской) отрасли. Для условной одежды нет сроков годности. Для условных макарон нет сроков годности. Молоко с большим, но истекающим сроком годности можно не брать у поставщика. А вот если продавать "живые" продукты - типа свежей сметаны, сыров или лекарственные препараты, у которых очень маленький срок годности (3-5 суток) - то сроки годности очень даже актуальны.
Поэтому тут сильно зависит от специализации маркетплейса
Я имел в виду, что "живые продукты", а также, например, лекарственные препараты с небольшим сроком годности, обычно исключены из ассортимента маркетплейсов. Они ими просто не торгуют и это оговаривается при заключении договора с поставщиками. По крайне мере ни разу не встречал маркетплейса, где продавались бы скоропортящиеся продукты
За это сообщение автора поблагодарили: sukhanchik (4).
Старый 14.10.2021, 12:25   #13  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,754 / 500 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Не совсем.
Во-первых, нужно сразу исключить "Контроль серийных номеров", чтобы можно было один серийный номер установить нескольким штукам (т.е. чтобы был 1 серийный номер у 4 штук товара)
Во-вторых, идеологически предполагается, что серийный номер рождается либо на этапе покупки, либо на этапе производства, но никак не на этапе продажи. Типичный пример - это IMEI-номер телефона / ID процессора / VIN номер автомобиля, т.е. некий уникальный идентификатор, который присваивается производителем и может быть использован любой компанией для целей учета и обращению к производителю. Понятно, что технически прикрутить можно всё, но если ставить вопрос о приближении к стандарту - то серийный номер на идеологическом уровне не является аналитикой "бронирования". Хотя тут возможно задействовать группы нумерации - это правда.
В-третьих, для целей анализа данных, если это возможно - удобно в значении аналитики содержать не бессмысленную номерную серию, а некоторый идентификатор, который содержит осмысленную информацию - в данном случае - номер заказа или лота. Такие вещи не всегда возможны, но в данном случае - поскольку аналитика техническая - то это возможно.
В-четвёртых, даже если будет использована какая-нибудь из уже существующих аналитик - то Вам всё равно придётся допрограммировать её поведение. В этом случае гораздо удобнее завести свою аналитику и уже с ней работать. Особенно в контексте будущего в D365FO, где стандартный код уже не поменяешь. Ну и заодно защититься от неожиданностей в стандартном функционале, которые могут использовать существующую аналитику (в т.ч. серийный номер)

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

По поводу цепочек перемещения - то в процессе наложения брони - обычно сразу возникает вопрос - по какому правилу накладывать бронь. Если в случае поиска товара на складе - нам относительно неважно из какой ячейки будет взят товар или же в случае наличия сроков годности - неважно какой товар будет взят при одинаковом сроке годности, то в случае брони наиболее остро встает вопрос - "откуда везти?". Ну т.е. когда клиент делает заказ на получение в Омске - то важно учитывать, что из Воронежа он будет ехать несколько дней (при этом нужно будет учесть сроки годности, если они есть). А поставка из соседнего Новосибирска может и будет быстрее, но напрямую поставок нет - поэтому маршрут идет через Москву, а там и сроки годности подожмут. Если же на это еще наложится юридическое разделение по юрлицам - то будет ещё веселее. Про заграницу (таможню) я вообще молчу ))
Что-то ты прям всё усложнил Такая модель работает на AX2009: Номер партии генерим в заказе на продажу и дальше поехали его тянуть через склад, резервы, сводник и производство. Всё красиво, аж скулы сводит
На серийнике уникальность не надо убирать - каждая штука - один номер
За это сообщение автора поблагодарили: sukhanchik (8).
Старый 14.10.2021, 12:33   #14  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,754 / 500 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Цитата:
Сообщение от Lucky13 Посмотреть сообщение
Не хотелось бы привязываться к какой-то конкретной версии, потому что цель понять, какие средства есть в системе для реализации данного процесса, а не реализовать его в имеющейся системе. В идеале хотелось бы понять, что полезного, применительно к данному процессу, есть, например в DAX 2012, чего, например, не было в 3.0.
Посмотрите ролики, здесь как раз по нескольким версиям системы
https://www.youtube.com/user/AMANDorg/playlists
Старый 14.10.2021, 13:17   #15  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,363 / 1694 (63) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от Lucky13 Посмотреть сообщение
Серийный номер относится к закупке/производству, а здесь нужна аналитика продажи.
Да, вы правы. Подумалось, что в общем случае заказанного товара может ещё и не быть на складе. Его ещё нужно будет заказывать у своих поставщиков. И с каким серийным номером он поступит на склад будет известно позже.

Действительно логично использовать отдельную складскую аналитику связанную с назначением остатков, а не с их происхождением.
Старый 14.10.2021, 13:35   #16  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,971 / 2969 (104) +++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от Lucky13 Посмотреть сообщение
Я имел в виду, что "живые продукты", а также, например, лекарственные препараты с небольшим сроком годности, обычно исключены из ассортимента маркетплейсов. Они ими просто не торгуют и это оговаривается при заключении договора с поставщиками. По крайне мере ни разу не встречал маркетплейса, где продавались бы скоропортящиеся продукты
Согласен. Я рассуждал шире - для любой продажи под заказ - необязательно через общедоступный массовый маркетплейс
__________________
Возможно сделать все. Вопрос времени
Старый 14.10.2021, 16:18   #17  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,754 / 500 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Ссылки почитать про функциональность которая может быть использована:
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 (5).
Старый 14.10.2021, 17:01   #18  
Lucky13 is offline
Lucky13
Участник
1C
 
681 / 161 (7) ++++++
Регистрация: 21.10.2004
Адрес: Воронеж
А никто случайно не знает, как складской учет устроен в SAP R/3? Там тоже что-то похожее на складскую аналитику, как в аксапте или там как-то иначе устроено? Просто в последнее время поймал себя на мысли, что при проектировании подход аксапты очень удобен: выбираются необходимые аналитики (складские и финансовые), если надо, добавляются новые и на этой основе уже строится модель учета. Поэтому возник вопрос - это общий подход для западных систем учета или в только аксапте придумали такой механизм?
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
ax2009, 2012. У кого есть опыт работы с paging в Query? Стоит ли этим заморачиваться? mazzy DAX: Программирование 12 12.11.2015 09:03
Изменение графика работы в середине месяца wyro4ka DAX: Функционал 10 01.11.2012 15:32
Журнал работы пользователей (логи)? Anais DAX: Администрирование 7 26.08.2009 09:15
Использование профилировщика и толкование результатов его работы belugin DAX: Программирование 3 22.11.2005 16:56
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 00:50.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.