Управление перевозками (Черновик)

Консолидация заказов в Отправке

Критерий, по которому EnterpriseOne Transportation объединяет строки заказа в отгрузки, был проблемой для многих клиентов и консультантов. Этот документ определяет критерии для двух путей консолидации.

Режим объединения в отправку/Shipment Consolidation Mode

• Multiple Order Consolidation
• Single Order Consolidation
• Transactional Consolidation
• No Consolidation

During order entry every order line goes through consolidation logic to attempt to be added to the same shipment as a previous order line, regardless of the setting of the shipment consolidation flag in the Transportation Constants (F49002). The shipment consolidation flag only controls whether or not the system attempts to add lines to shipments already existing in the database. While promised ship date drives the calculation of dates, changing the dates on an order will produce varying results. This document will discuss how shipments are consolidated based on constant settings, order dates entry/override, and the effects of changing various dates after order entry.

При вводе заказа каждая строка проходит через логику консолидации, чтобы попытаться добавить ее к той же отгрузке, что и предыдущая строка заказа, независимо от установки флага консолидации отгрузки в константах транспортировки (F49002). Флаг консолидации отгрузок только контролирует, пытается ли система добавить строки к отгрузкам, уже существующим в базе данных. В то время как обещанная дата отгрузки/promised ship date влияет на расчет дат, изменение дат в заказе приведет к различным результатам. В этом документе обсуждается, как отгрузки консолидируются на основе постоянных настроек, ввода/переопределения дат заказа и последствий изменения различных дат после ввода заказа.

Prior to 8.9, during order entry every order line went through consolidation logic to attempt to be added to the same shipment as a previous order line (Path 1), regardless of the setting of the shipment consolidation flag in the Transportation Constants (F49002). The shipment consolidation flag only controls whether or not the system attempts to add lines to shipments already existing in the database (Path 2).

До версии 8.9 во время ввода заказа каждая строка заказа проходила логику консолидации, чтобы попытаться добавить к той же отгрузке, что и предыдущая строка заказа (Путь 1), независимо от установки флага консолидации отгрузки в константах транспортировки (F49002). Флаг консолидации отгрузки только контролирует, пытается ли система добавить строки к отгрузкам, уже существующим в базе данных (Путь 2).

Начиная с версии 8.9 и вплоть до текущих выпусков, настройка консолидации отгрузки всегда будет определять, будет ли консолидирована строка заказа на основе пути 1 или 2 следующим образом:

Без консолидации/No Consolidation

строка заказа не будет обработана по Пути 1 и по Пути 2.

Консолидация транзакций/Transactional

строка заказа будет обработана по Пути 1. (эквивалент "ВЫКЛ" в Xe)

Консолидация одного заказа/Single Order

строка заказа будет обработана по путям 1 и 2, однако Путь 2 используется на уровне ключа заказа.

Консолидация нескольких заказов/Multiple Order

строка заказа будет обработана по обоим путям 1 и 2. (эквивалент "ВКЛ" в Xe)

Путь 1: Консолидации на уровне транзакций (отгрузка обрабатывается в кэше)

The first consolidation process compares the new or updated order line to the shipment available in the cache. The cache record is only available after the first order line has been entered, updated, or split. This process is done, in Xe, regardless of the consolidation flag setting and in 8.9 for all consolidation settings except No Consolidation.

Во-первых процесс консолидации сравнивает новую или обновленную строку заказа с отгрузкой, доступной в кэше. Запись об отгрузке в кэше создается и доступна только после ввода, обновления или разделения первой строки заказа. Этот процесс выполняется в версии Xe, независимо от установки флага консолидации, а в версии 8.9+ для всех настроек консолидации, кроме «Нет консолидации».

Следующие введенные поля строки должны:

• строго совпадать с соответствующими полями в текущей отгрузке в кэше:
  • NMCU - Origin Shipment Depot NMCU
  • ORGN - Origin Address Book Number
  • SHAN - Ship To Address Book Number
  • AN8 - Sold To Address Book Number
  • SRCO - Source of Order
  • PMDT - Promised Shipment Time
  • RSDT - Promised Delivery Time
  • DRQT - Requested Delivery Time

• Значения, введенные (или полученные через предпочтения) в следующие поля, должны быть равны значению соответствующего поля текущей отгрузки в кэше -ИЛИ- либо введенное поле, либо соответствующее поле отгрузки в кэше должно быть пустым (?оба или хоть одно из них):
  • MOT - Method of Delivery
  • CARS - Carrier
  • CAR1 - Carrier1
  • CAR2 - Carrier2
  • CAR3 - Carrier3
  • ILEL - Carrier Preference Include/Exclude flag
  • BPFG - Bulk/Packed Flag
  • FRTH - Freight Handling Code
  • FRSC - Rate Schedule
  • DLLV - Line Level Delivery
  • RSLT - Route Selection Type
  • BFSD - Freight Summary
  • DSTN - Distance
  • UMD1 - Distance UOM
  • Currency Code
• Следующие введенные даты должны быть равны дате соответствующей даты для текущей отгрузки в кэше. -ИЛИ- либо введенная дата, либо соответствующая дата для отгрузки в кеше должны быть пустыми:
  • PPDJ - Promised Shipment Date
  • RSDJ - Promised Delivery Date
  • DRQJ - Requested Delivery Date

Даты

Для ЗНЗ / Other Inbound

Три даты определяют Поставку:

• Требуемая дата доставки/Requested Delivery Date (DRQJ) на наш склад
• Обещанная дата доставки/Promised Delivery Date (RSDJ) на наш склад
• Обещанная дата отгрузки/Promised Shipment Date (PPDJ) со склада поставщика

Пользователь может ввести в ЗНЗ вручную Requested Date или Promised Delivery Date. Если не ввести, Requested Date = Текущая дата, Promised Delivery Date = 0. ?Из ЗНЗ Promised Delivery Date всегда приходит равны 0.

Для расчета дат система пытается выполнить обратное планирование/Back scheduling, если не получается, по прямое планирование/forward scheduling. Система обновит данные в Маршрутизированной поставке, а затем в ЗНЗ.

• Если пользователь не указал Promised Delivery Date, то система выполняет обратное планирование/Back scheduling на основе Requested Date (DRQJ).
  • расчет Promised Delivery Date (RSDJ)
    1. RSDJ(C1) = DRQJ
    2. RSDJ = RSDJ(C1) - Days (WC B/P, CAR) >= TD
  • расчет Promised Shipment Date (PPDJ)
    1. PPDJ(C1) = RSDJ - Transit Days (route)
    2. PPDJ(C2) = PPDJ(C1) - Days (WC SUP, CAR) >= TD
    3. PPDJ(C3) = PPDJ(C2) - Lead Days (route)
    4. PPDJ = PPDJ(C3) - Days (WC SUP) > TD
  • после применения маршрута, RSDJ запишется Поставку и ЗНЗ, PPDJ запишется в Поставку. Если расчет не прошел проверку, то данный Маршрут не будет отображён.

• Если пользователь указал Promised Delivery Date (RSDJ), и это первый этап маршрута, то система выполняет обратное планирование/Back scheduling на основе Promised Delivery Date (RSDJ(M)).
  • расчет Promised Delivery Date (RSDJ)
    1. RSDJ(C1) = (RSDJ(M)
    2. RSDJ = RSDJ(C1) - Days (WC B/P, CAR) >= TD
  • расчет Promised Shipment Date (PPDJ)
    1. PPDJ(C1) = RSDJ - Transit Days (route)
    2. PPDJ(C2) = PPDJ(C1) - Days (WC SUP, CAR) >= TD
    3. PPDJ(C3) = PPDJ(C2) - Lead Days (route)
    4. PPDJ = PPDJ(C3) - Days (WC SUP) > TD
  • после применения маршрута, RSDJ запишется Поставку и ЗНЗ, PPDJ запишется в Поставку. Если расчет не прошел проверку, то данный Маршрут не будет отображён.

• Если пользователь не указал Promised Delivery Date (RSDJ) и Requested Date (DRQJ) в Поставке, то система пытается выполнить прямое планирование/forward scheduling на основе Today's Date(TD)
  • расчет Promised Shipment Date (PPDJ)
    1. PPDJ(C1) = TD + Lead Days (route)
    2. PPDJ = PPDJ(C1) + Days (WC SUP, CAR)
  • расчет Promised Delivery Date (RSDJ)
    1. RSDJ(C1) = PPDJ + Transit Days (route)
    2. RSDJ = RSDJ(C1) + Days (WC B/P, CAR)
  • после применения маршрута, RSDJ запишется Поставку и ЗНЗ, PPDJ запишется в Поставку.