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

Материал из JD Edwards E1
Перейти к навигации Перейти к поиску

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

Критерий, по которому 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: Консолидации на уровне транзакций (отгрузка обрабатывается в кэше)

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

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

  • строго совпадать с соответствующими полями в текущей отгрузке в кэше:
    • NMCU - Origin Shipment Depot
    • 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

Путь 2: Критерии консолидации на уровне одного/нескольких заказов (Shipment Header (F4215) table)

The second process compares the new or updated line to the shipments available for consolidation in the database only after attempting to consolidate to any shipments available in cache.

The following conditions must be TRUE to attempt to consolidate:

  • Order Key must be equal (Single Order Consolidation only)
  • Shipment Status < Protected Shipment Status
  • (Note: The Shipment Status is the Approved Shipment Status setup in the Transportation Constants (P49002) program)
  • Number of Routing Steps = 1
  • Actual Shipment Date = Zero or Null Date
  • Load Number = 0
  • Item Compatibility
  • Existing Shipment Number <> Consolidated Shipment Number (Consolidation during removal of shipment detail from a shipment)

The following entered fields must be equal to the corresponding field of the shipment in the database (F4215/F4941):

  • Origin Shipment Depot
  • Origin Address Book Number
  • Bulk/Packed Flag
  • Ship To Address Book Number
  • Sold To Address Book Number
  • Source of Order
  • Promised Ship Time
  • Promised Delivery Time
  • Requested Delivery Time

The values entered (or brought in by preferences) in the following fields must be equal to the corresponding field of the shipment in the database (F4215/F4941) -OR- either the entered field or the corresponding field of the shipment in the database (F4215/F4941) must be blank:

  • Rate Schedule
  • MOT
  • Carrier
  • Freight Handling Code

If a carrier is brought in by preferences on the order line, it must be equal to the corresponding field of the shipment in the database (F4215/F4941) -OR- the order line's carrier(s) must be blank:

  • Carrier1
  • Carrier2
  • Carrier3

Даты

Для ЗНЗ / 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 запишется в Поставку.
Ссылка
  • E1: 49: Promised Shipment and Delivery Date Calculation (Doc ID 625513.1)
Источник — http://wiki.sgsproject.nichost.ru/index.php?title=Управление_перевозками_(Черновик)&oldid=3457