|
13.10.2021, 15:11 | #1 |
северный Будда
|
Цитата:
Сообщение от sukhanchik
В качестве примера - можно рассмотреть аналитику Владелец, которая изначально предназначалась для комиссионной торговли (аналитика связана со справочником клиентов / поставщиков) в России, но уже в D365FO перекочевала в международный функционал.
Но идеологически правильнее проставлять "бронь" номером заказа на продажу или номером лота (=строки заказа на продажу). Этого пока в системе нет, поэтому тут делается доработка по добавлению новой складской аналитики (аналитики отслеживания), которая заполняется в заказе на продажу (точнее в складских проводках при заказе на продажу) по кнопке "забронировать".
__________________
С уважением, Вячеслав Последний раз редактировалось pitersky; 13.10.2021 в 15:25. |
|
|
За это сообщение автора поблагодарили: Vals (20), S.Kuskov (2). |
13.10.2021, 21:54 | #2 |
Administrator
|
Цитата:
Во-первых, нужно сразу исключить "Контроль серийных номеров", чтобы можно было один серийный номер установить нескольким штукам (т.е. чтобы был 1 серийный номер у 4 штук товара) Во-вторых, идеологически предполагается, что серийный номер рождается либо на этапе покупки, либо на этапе производства, но никак не на этапе продажи. Типичный пример - это IMEI-номер телефона / ID процессора / VIN номер автомобиля, т.е. некий уникальный идентификатор, который присваивается производителем и может быть использован любой компанией для целей учета и обращению к производителю. Понятно, что технически прикрутить можно всё, но если ставить вопрос о приближении к стандарту - то серийный номер на идеологическом уровне не является аналитикой "бронирования". Хотя тут возможно задействовать группы нумерации - это правда. В-третьих, для целей анализа данных, если это возможно - удобно в значении аналитики содержать не бессмысленную номерную серию, а некоторый идентификатор, который содержит осмысленную информацию - в данном случае - номер заказа или лота. Такие вещи не всегда возможны, но в данном случае - поскольку аналитика техническая - то это возможно. В-четвёртых, даже если будет использована какая-нибудь из уже существующих аналитик - то Вам всё равно придётся допрограммировать её поведение. В этом случае гораздо удобнее завести свою аналитику и уже с ней работать. Особенно в контексте будущего в D365FO, где стандартный код уже не поменяешь. Ну и заодно защититься от неожиданностей в стандартном функционале, которые могут использовать существующую аналитику (в т.ч. серийный номер) При этом, если заводить аналитику бронирования - то под нее придется заводить (естественно) отдельный справочник. И вот в этом справочнике можно хранить дополнительную информацию о чём-либо (детали исходного документа, автора брони и т.д.), плюс иметь административные кнопки типа "Удалить бронь" для снятия брони со всей цепочки (популярность такой кнопки сопоставима с популярностью отмены разноски, когда ее делают для службы техподдержки). По поводу цепочек перемещения - то в процессе наложения брони - обычно сразу возникает вопрос - по какому правилу накладывать бронь. Если в случае поиска товара на складе - нам относительно неважно из какой ячейки будет взят товар или же в случае наличия сроков годности - неважно какой товар будет взят при одинаковом сроке годности, то в случае брони наиболее остро встает вопрос - "откуда везти?". Ну т.е. когда клиент делает заказ на получение в Омске - то важно учитывать, что из Воронежа он будет ехать несколько дней (при этом нужно будет учесть сроки годности, если они есть). А поставка из соседнего Новосибирска может и будет быстрее, но напрямую поставок нет - поэтому маршрут идет через Москву, а там и сроки годности подожмут. Если же на это еще наложится юридическое разделение по юрлицам - то будет ещё веселее. Про заграницу (таможню) я вообще молчу ))
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 13.10.2021 в 22:06. |
|
14.10.2021, 12:25 | #3 |
Аманд
|
Цитата:
Сообщение от sukhanchik
Не совсем.
Во-первых, нужно сразу исключить "Контроль серийных номеров", чтобы можно было один серийный номер установить нескольким штукам (т.е. чтобы был 1 серийный номер у 4 штук товара) Во-вторых, идеологически предполагается, что серийный номер рождается либо на этапе покупки, либо на этапе производства, но никак не на этапе продажи. Типичный пример - это IMEI-номер телефона / ID процессора / VIN номер автомобиля, т.е. некий уникальный идентификатор, который присваивается производителем и может быть использован любой компанией для целей учета и обращению к производителю. Понятно, что технически прикрутить можно всё, но если ставить вопрос о приближении к стандарту - то серийный номер на идеологическом уровне не является аналитикой "бронирования". Хотя тут возможно задействовать группы нумерации - это правда. В-третьих, для целей анализа данных, если это возможно - удобно в значении аналитики содержать не бессмысленную номерную серию, а некоторый идентификатор, который содержит осмысленную информацию - в данном случае - номер заказа или лота. Такие вещи не всегда возможны, но в данном случае - поскольку аналитика техническая - то это возможно. В-четвёртых, даже если будет использована какая-нибудь из уже существующих аналитик - то Вам всё равно придётся допрограммировать её поведение. В этом случае гораздо удобнее завести свою аналитику и уже с ней работать. Особенно в контексте будущего в D365FO, где стандартный код уже не поменяешь. Ну и заодно защититься от неожиданностей в стандартном функционале, которые могут использовать существующую аналитику (в т.ч. серийный номер) При этом, если заводить аналитику бронирования - то под нее придется заводить (естественно) отдельный справочник. И вот в этом справочнике можно хранить дополнительную информацию о чём-либо (детали исходного документа, автора брони и т.д.), плюс иметь административные кнопки типа "Удалить бронь" для снятия брони со всей цепочки (популярность такой кнопки сопоставима с популярностью отмены разноски, когда ее делают для службы техподдержки). По поводу цепочек перемещения - то в процессе наложения брони - обычно сразу возникает вопрос - по какому правилу накладывать бронь. Если в случае поиска товара на складе - нам относительно неважно из какой ячейки будет взят товар или же в случае наличия сроков годности - неважно какой товар будет взят при одинаковом сроке годности, то в случае брони наиболее остро встает вопрос - "откуда везти?". Ну т.е. когда клиент делает заказ на получение в Омске - то важно учитывать, что из Воронежа он будет ехать несколько дней (при этом нужно будет учесть сроки годности, если они есть). А поставка из соседнего Новосибирска может и будет быстрее, но напрямую поставок нет - поэтому маршрут идет через Москву, а там и сроки годности подожмут. Если же на это еще наложится юридическое разделение по юрлицам - то будет ещё веселее. Про заграницу (таможню) я вообще молчу )) На серийнике уникальность не надо убирать - каждая штука - один номер |
|
|
За это сообщение автора поблагодарили: sukhanchik (8). |