Управление перевозками (Черновик): различия между версиями

Материал из JD Edwards E1
Перейти к навигации Перейти к поиску
 
(не показано 80 промежуточных версий 9 участников)
Строка 2: Строка 2:
 
== Консолидация заказов в Отправке ==
 
== Консолидация заказов в Отправке ==
 
Критерий, по которому EnterpriseOne Transportation объединяет строки заказа в отгрузки, был проблемой для многих клиентов и консультантов. Этот документ определяет критерии для двух путей консолидации.  
 
Критерий, по которому EnterpriseOne Transportation объединяет строки заказа в отгрузки, был проблемой для многих клиентов и консультантов. Этот документ определяет критерии для двух путей консолидации.  
−
; Режим объединения в отправку/Shipment Consolidation Mode
+
; Режим консолидации отправок/Shipment Consolidation Mode
 
* Multiple Order Consolidation
 
* Multiple Order Consolidation
 
* Single Order Consolidation
 
* Single Order Consolidation
Строка 8: Строка 8:
 
* No Consolidation
 
* No Consolidation
  
 +
При вводе заказа каждая строка проходит через логику консолидации, чтобы попытаться добавить ее к той же отгрузке, что и предыдущая строка заказа, независимо от установки флага консолидации отгрузки в константах транспортировки (F49002). Флаг консолидации отгрузок только контролирует, пытается ли система добавить строки к отгрузкам, уже существующим в базе данных. В то время как Обещанная дата отгрузки/promised ship date влияет на расчет дат, изменение дат в заказе приведет к различным результатам. В этом документе обсуждается, как отгрузки консолидируются на основе постоянных настроек, ввода/переопределения дат заказа и последствий изменения различных дат после ввода заказа.
  
−
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.
+
До версии 8.9 во время ввода заказа каждая строка заказа проходила логику консолидации, чтобы попытаться добавить к той же отгрузке, что и предыдущая строка заказа (Путь 1), независимо от установки флага консолидации отгрузки в константах транспортировки (F49002). Флаг консолидации отгрузки только контролирует, пытается ли система добавить строки к отгрузкам, уже существующим в базе данных (Путь 2).  
  
−
При вводе заказа каждая строка проходит через логику консолидации, чтобы попытаться добавить ее к той же отгрузке, что и предыдущая строка заказа, независимо от установки флага консолидации отгрузки в константах транспортировки (F49002). Флаг консолидации отгрузок только контролирует, пытается ли система добавить строки к отгрузкам, уже существующим в базе данных. В то время как обещанная дата отгрузки/promised ship date влияет на расчет дат, изменение дат в заказе приведет к различным результатам. В этом документе обсуждается, как отгрузки консолидируются на основе постоянных настроек, ввода/переопределения дат заказа и последствий изменения различных дат после ввода заказа.
+
Начиная с версии 8.9 и вплоть до текущих выпусков, настройка консолидации отгрузки всегда будет определять, будет ли консолидирована строка заказа на основе пути 1 или 2 следующим образом:
 +
* Без консолидации/No Consolidation: строка заказа не будет обработана по Пути 1 и по  Пути 2.
 +
* Консолидация транзакций/Transactional: строка заказа будет обработана по Пути 1. (эквивалент "ВЫКЛ" в Xe)
 +
* Консолидация одного заказа/Single Order: строка заказа будет обработана по Пути 1 и по Пути 2. Однако Путь 2 используется в рамках Ключа заказа.
 +
* Консолидация нескольких заказов/Multiple Order: строка заказа будет обработана по обоим путям 1 и 2. (эквивалент "ВКЛ" в Xe)
  
−
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).
+
==== Путь 1: Консолидации на уровне транзакций (отгрузка обрабатывается в кэше) ====
  
−
До версии 8.9 во время ввода заказа каждая строка заказа проходила логику консолидации, чтобы попытаться добавить к той же отгрузке, что и предыдущая строка заказа (Путь 1), независимо от установки флага консолидации отгрузки в константах транспортировки (F49002). Флаг консолидации отгрузки только контролирует, пытается ли система добавить строки к отгрузкам, уже существующим в базе данных (Путь 2).  
+
Первый процесс консолидации сравнивает созданную/обновленную (кроме самой первой) строку заказа с существующей отгрузкой, доступной в кэше. Запись об отгрузке в кэше создается и доступна только после ввода, обновления или разделения первой строки заказа.
 +
Этот процесс выполняется в версии 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
 +
 
 +
; Условия  консолидации для дат в закупках
 +
 
 +
Purchase Order Level:
 +
* Если дата Requested Delivery Date = Пусто, то система укажет текущую дату;
 +
* Promised Delivery Date система всегда передает в TMS значение 0.
 +
 
 +
Строка заказа будет объединена с существующей отгрузкой только в том случае, если произошло хотя бы одно из следующих событий:
 +
# Обещанная дата отгрузки/Promised Shipment Date (PPDJ)
 +
#: Обещанная дата отгрузки в ЗНЗ не была введена или уже в прошлом;
 +
#: -ИЛИ-
 +
#: Обещанная дата отгрузки в ЗНЗ равна Обещанной дате отгрузки в Отправке, с которой консолидируется строка ЗНЗ;
 +
#: -ИЛИ-
 +
#: Обещанная дата отгрузки в Отправке, с которой консолидируется строка ЗНЗ, уже прошла.
 +
# Планируемая дата доставки / Promised Delivery Date (RSDJ)
 +
#: Планируемая дата доставки в ЗНЗ не была введена или уже в прошлом;
 +
#: -ИЛИ-
 +
#: Планируемая дата доставки в ЗНЗ равна Планируемая дата доставки в Отправке, с которой консолидируется строка ЗНЗ;
 +
#: -ИЛИ-
 +
#: Планируемая дата доставки в Отправке, с которой консолидируется строка ЗНЗ, уже прошла.
 +
# Требуемая дата доставки / Requested Delivery Date (DRQJ)
 +
#: Требуемая дата доставки в ЗНЗ равна Требуемой дате доставки в Отправке, с которой консолидируется строка ЗНЗ.
  
−
Начиная с версии 8.9 и вплоть до текущих выпусков, настройка консолидации отгрузки всегда будет определять, будет ли консолидирована строка заказа на основе пути 1 или 2 следующим образом:
+
==== Путь 2: Критерии консолидации на уровне одного/нескольких заказов (Shipment Header (F4215) table)====
−
; Без консолидации/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.
+
Следующие условия должны быть выполнены для попытки консолидации:
 +
* Ключевые поля заказа должны быть одинаковыми (только для консолидации одного заказа)
 +
* Статус отправки < Защищенный статус отправки
 +
*: (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
 +
* ТМЦ должны быть совместимы
 +
* Существующий Shipment Number <> Консолидированный Shipment Number (Процесс консолидация при удалении строк из отправки)
  
−
Во-первых процесс консолидации сравнивает новую или обновленную строку заказа с отгрузкой, доступной в кэше. Запись об отгрузке в кэше создается и доступна только после ввода, обновления или разделения первой строки заказа.
+
Следующие введённые поля должны совпадать с соответствующими полями отправки в таблицах (F4215/F4941)
−
Этот процесс выполняется в версии Xe, независимо от установки флага консолидации, а в версии 8.9+ для всех настроек консолидации, кроме «Нет консолидации».
+
* NMCU - Origin Shipment Depot
 +
* ORGN - Origin Address Book Number
 +
* BPFG - Bulk/Packed Flag
 +
* 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
  
−
Следующие введенные поля строки должны:
+
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:
−
* строго совпадать с соответствующими полями в текущей отгрузке в кэше:
+
* MOT - Method of Delivery
−
** NMCU - Origin Shipment Depot NMCU
+
* CARS - Carrier
−
** ORGN - Origin Address Book Number
+
* FRTH - Freight Handling Code
−
** SHAN - Ship To Address Book Number
+
* FRSC - Rate Schedule
−
** AN8 - Sold To Address Book Number
 
−
** SRCO - Source of Order
 
−
** PMDT - Promised Shipment Time
 
−
** RSDT - Promised Delivery Time
 
−
** DRQT - Requested Delivery Time
 
  
−
* Значения, введенные (или полученные через предпочтения) в следующие поля, должны быть равны значению соответствующего поля текущей отгрузки в кэше -ИЛИ- либо введенное поле, либо соответствующее поле отгрузки в кэше должно быть пустым (?оба или хоть одно из них):  
+
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-  
−
** MOT - Method of Delivery
+
the order line's carrier(s) must be blank:
−
** CARS - Carrier
+
* CAR1 - Carrier1
−
** CAR1 - Carrier1
+
* CAR2 - Carrier2
−
** CAR2 - Carrier2
+
* CAR3 - Carrier3
−
** 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 ===
 
=== Для ЗНЗ / Other Inbound ===
 +
Даты ЗНЗ:
 +
* Request date (DRQJ) - Дата запланированного прибытия ТМЦ  или запланированного выполнения действия.
 +
* Scheduled Pick date (PDDJ) - The promised shipment date for either a sales order or purchase order. Эта дата представляет собой день, когда товар может быть отгружен со склада.
 +
* Original Promised Delivery (OPDJ) - Первоначальная обещанная дата доставки для ЗНЗ.
 +
* Actual Ship Date (ADDJ) - The date on which the shipment to the customer is confirmed as shipped. During shipment confirmation, the system updates the Sales Order Detail table (F4211) with this date.
 +
* Promised Shipment (PPDJ) -The promised shipment date for a sales order. This date represents the day that the item can be shipped from the warehouse.
 +
 +
 +
 +
 
Три даты определяют Поставку:
 
Три даты определяют Поставку:
 
* Требуемая дата доставки/Requested Delivery Date (DRQJ) на наш склад
 
* Требуемая дата доставки/Requested Delivery Date (DRQJ) на наш склад
Строка 73: Строка 135:
  
 
Для расчета дат система пытается выполнить обратное планирование/Back scheduling, если не получается, по прямое планирование/forward scheduling. Система обновит данные в Маршрутизированной поставке, а затем в ЗНЗ.
 
Для расчета дат система пытается выполнить обратное планирование/Back scheduling, если не получается, по прямое планирование/forward scheduling. Система обновит данные в Маршрутизированной поставке, а затем в ЗНЗ.
 +
 
* Если пользователь не указал Promised Delivery Date, то система выполняет обратное планирование/Back scheduling на основе Requested Date (DRQJ).
 
* Если пользователь не указал Promised Delivery Date, то система выполняет обратное планирование/Back scheduling на основе Requested Date (DRQJ).
−
** Promised Delivery Date (RSDJ)
+
** расчет Promised Delivery Date (RSDJ)
 
**# RSDJ(C1) = DRQJ
 
**# RSDJ(C1) = DRQJ
−
**# RSDJ = RSDJ(C1) - Days (WC B/P, CAR) >= TD
+
**# RSDJ = RSDJ(C1) - Days (WorkCalendar B/P, CAR) >= TD
−
** Promised Shipment Date (PPDJ)
+
** расчет Promised Shipment Date (PPDJ)
 
**# PPDJ(C1) = RSDJ - Transit Days (route)
 
**# PPDJ(C1) = RSDJ - Transit Days (route)
 
**# PPDJ(C2) = PPDJ(C1) - Days (WC SUP, CAR) >= TD
 
**# PPDJ(C2) = PPDJ(C1) - Days (WC SUP, CAR) >= TD
 
**# PPDJ(C3) = PPDJ(C2) - Lead Days (route)
 
**# PPDJ(C3) = PPDJ(C2) - Lead Days (route)
 
**# PPDJ = PPDJ(C3) - Days (WC SUP) > TD
 
**# PPDJ = PPDJ(C3) - Days (WC SUP) > TD
−
** RSDJ запишется в Поставку и ЗНЗ, PPDJ запишется в Поставку.  
+
** после применения маршрута, RSDJ запишется Поставку и ЗНЗ, PPDJ запишется в Поставку. Если расчет не прошел проверку, то данный Маршрут не будет отображён.
  
−
* Если пользователь указал Promised Delivery Date (RSDJ), то система выполняет обратное планирование/Back scheduling на основе Promised Delivery Date (RSDJ(M)).
+
* Если пользователь указал Promised Delivery Date (RSDJ), и это первый этап маршрута, то система выполняет обратное планирование/Back scheduling на основе Promised Delivery Date (RSDJ(M)).
−
** Promised Delivery Date (RSDJ)
+
** расчет Promised Delivery Date (RSDJ)
 
**# RSDJ(C1) = (RSDJ(M)
 
**# RSDJ(C1) = (RSDJ(M)
 
**# RSDJ = RSDJ(C1) - Days (WC B/P, CAR) >= TD
 
**# RSDJ = RSDJ(C1) - Days (WC B/P, CAR) >= TD
−
** Promised Shipment Date (PPDJ)
+
** расчет Promised Shipment Date (PPDJ)
 
**# PPDJ(C1) = RSDJ - Transit Days (route)
 
**# PPDJ(C1) = RSDJ - Transit Days (route)
 
**# PPDJ(C2) = PPDJ(C1) - Days (WC SUP, CAR) >= TD
 
**# PPDJ(C2) = PPDJ(C1) - Days (WC SUP, CAR) >= TD
 
**# PPDJ(C3) = PPDJ(C2) - Lead Days (route)
 
**# PPDJ(C3) = PPDJ(C2) - Lead Days (route)
 
**# PPDJ = PPDJ(C3) - Days (WC SUP) > TD
 
**# PPDJ = PPDJ(C3) - Days (WC SUP) > TD
−
** RSDJ запишется в Поставку и ЗНЗ, PPDJ запишется в Поставку.  
+
** после применения маршрута, RSDJ запишется Поставку и ЗНЗ, PPDJ запишется в Поставку. Если расчет не прошел проверку, то данный Маршрут не будет отображён.
  
−
* Если пользователь указал Promised Delivery Date (RSDJ), и система, выполняя обратное планирование/Back scheduling на основе Promised Delivery Date (RSDJ(M)), вызвала ошибку при расчете, то система пытается выполнить прямое планирование/forward scheduling на основе Today's Date(TD)
+
* Если пользователь не указал Promised Delivery Date (RSDJ) и Requested Date (DRQJ) в Поставке, то система пытается выполнить прямое планирование/forward scheduling на основе Today's Date(TD)
−
** Promised Shipment Date (PPDJ)
+
** расчет Promised Shipment Date (PPDJ)
 
**# PPDJ(C1) = TD + Lead Days (route)
 
**# PPDJ(C1) = TD + Lead Days (route)
 
**# PPDJ = PPDJ(C1) + Days (WC SUP, CAR)
 
**# PPDJ = PPDJ(C1) + Days (WC SUP, CAR)
−
** Promised Delivery Date (RSDJ)
+
** расчет Promised Delivery Date (RSDJ)
 
**# RSDJ(C1) = PPDJ + Transit Days (route)
 
**# RSDJ(C1) = PPDJ + Transit Days (route)
 
**# RSDJ = RSDJ(C1) + Days (WC B/P, CAR)
 
**# RSDJ = RSDJ(C1) + Days (WC B/P, CAR)
−
** RSDJ запишется в Поставку и ЗНЗ, PPDJ запишется в Поставку.
+
** после применения маршрута, RSDJ запишется Поставку и ЗНЗ, PPDJ запишется в Поставку.
 +
 
 +
== Freight Update ==
 +
какой-то текст:
 +
*Understanding the Freight Update Process
 +
*Updating Freight Charges
 +
*Matching Freight Invoices
 +
*Reviewing Freight Update
 +
*Adjusting the Freight Audit History
 +
*https://docs.oracle.com/cd/E16936_01/e1apps812pbr0/eng/psbooks/1atm/chapter.htm?File=1atm/htm/1atm16.htm
 +
 +
=== Updating Freight Charges===
 +
какой-то текст
 +
 
 +
==== Распределение затрат на ТМЦ для Inbound Transactions ====
 +
 
 +
The system allocates freight costs on a percentage of the total weight or volume of a shipment.
 +
{| class="wikitable"
 +
! Item !! Quantity / Weight !! Percent of Total Weight !! Amount by Item
 +
|-
 +
| Item A || 100 / 50 || 25 || 3.13 (25 percent of 12.50)
 +
|-
 +
| Item B || 50 / 60 || 30 || 3.75 (30 percent of 12.50)
 +
|-
 +
| Item C || 10 / 90 || 45 || 5.62 (45 percent of 12.50)
 +
|-
 +
| Total || 200 || N/A || 12.50
 +
|}
 +
 
 +
As illustrated, the freight is allocated by the total weight by item. Then, each piece is allocated its corresponding proportion of the freight cost. Each piece from the table would be allocated these freight costs:
 +
*Item A: 3.13 ÷ 100 pieces = .0313
 +
*Item B: 3.74 ÷ 50 pieces = .075
 +
*Item C: 5.62 ÷ 10 pieces = .562
 +
 
 +
=== Проводки и счета Freight Update ===
 +
 
 +
Каждый Shipment имеет параметр Источник (Source of Order):
 +
 
 +
:: {| class="wikitable"
 +
! style="width: 50px" | Код !! style="width: 250px" | Источник !! style="width: 250px" | Направление поставки
 +
|-
 +
| I || Other / Inbound || Inbound
 +
|-
 +
| O || Other / Outbound || Outbound
 +
|-
 +
| P || Purchase Order || Inbound
 +
|-
 +
| R || Purchasing - Customer Return || Outbound
 +
|-
 +
| S || Sales || Outbound
 +
|-
 +
| T || Sales - Customer Return || Inbound
 +
|}
 +
 
 +
Каждый Shipment имеет параметр Freight Handling Code значения из UDC (42/FR). Для кодов Freight Handling Code используется Special Handling Code.
 +
 
 +
:: {| class="wikitable"
 +
! style="width: 50px" | Код !! style="width: 250px" | Источник
 +
|-
 +
| Пусто || Prepaid
 +
|-
 +
| 1 || Collect
 +
|-
 +
| 2 || Prepaid, not billable
 +
|-
 +
| 9 || Bypass routing and rating
 +
|}
 +
 
 +
Сочетание Source of Order и Freight Handling Code (точнее его SPHD) определяет условия обработки маршрута (Routing), а значит и тарификации (Rating). Каждый Маршрут (Route) содержит указания на Тарифный план (Rate Schedule) для каждого направления: Outbound Freight Rate Schedule и Inbound Freight Rate Schedule. Тарифный план включает в себя различные Тарифы (Rates). Каждый Тариф имеет возможность указать код Charge Codes для Payable и Billable.
 +
 
 +
Каждый Charge Codes содержит параметры:
 +
* G/L Offset. Класс ГК для работы АИ Freight Update.
 +
* Freight Allocations. Распределять затраты на тариф по номенклатурам в поставке Freight Update.
 +
* Taxable (Y/N). Налогообложение.
 +
 
 +
:: {| class="wikitable"
 +
! || SPHD = blank </br> (Prepaid) || SPHD = 1 </br> (Collect) || SPHD = 2 </br> (Prepaid, not billable) || SPHD = 9 </br> (Bypass routing/rating)
 +
|-
 +
| Outbound Shipment </br> (SRCO = S, R, O) || Routing = Y </br> > Billable = Y </br> > Payable = Y || Routing = [1] </br> > Billable = N </br> > Payable = N || Routing = Y </br> > Billable = N </br> > Payable = Y || Routing = [2] </br> > Billable = N </br> > Payable = N
 +
|-
 +
| Inbound  Shipment </br> (SRCO = T, P, I) || Routing = N || Routing = Y </br> > Billable = [3] </br> > Payable = Y || Routing = N || Routing = [2] </br> > Billable = N </br> > Payable = N
 +
|}
 +
 
 +
::: [1] Outbound collect shipments will be automatically routed unless there is both an override carrier and override mode of transport entered.
 +
::: [2] Перевозчик (CARS) и Режим транспортировки (MOT) должны быть введены в заказ или автоматически заполнены через transportation preference profile для использования кода freight handling = BRR.
 +
::: [3] Только credit order-based inbound collect shipments (SRCO = T) может использовать billable freight charges.
 +
 
 +
; Billable Charge Codes
 +
: Компания выставляет счет, контрагент выполняет оплату.
 +
: При FU система создает записи в F4981 и в F4211, с определенным заранее типом строки (есть свой G/L Offset), который после SU может сгенерировать Инвойс. Какой сработает G/L Offset (Charge Codes или Line Types) при SU надо проверять. При SU АИ: 4230 – Revenue; 4233- Allocated Revenue.
 +
; Payable Charge Codes
 +
: Контрагент выставляет счет, компания выполняет оплату.
 +
:* AutoPay вкл. (P4906) создает записи в F4981 (FT) и в F0411 (??). Система сразу создает ваучер при Freight Update:
 +
:*: Кт PC* (G/L Offset: Carrier, MOT)
 +
:*: Дт 4920 (G/L Offset: Charge Code)
 +
:* AutoPay выкл. (P4906): 
 +
:*# Сначала при Freight Update создает записи в F4981 (FT) и в F0911 (FT).
 +
:*#: Кт 4921 (G/L Offset: Charge Code)
 +
:*#: Дт 4920 (G/L Offset: Charge Code).
 +
:*# Затем необходимо выполнить создание и подбор ваучера Freight Voucher Match.
 +
:*#: Кт PC* (G/L Offset: Carrier, MOT)
 +
:*#: Дт 4921 (G/L Offset: Charge Code)
 +
; Freight Allocations (только для Inbound  Shipment)
 +
: Если Freight Allocations On, то при Freight Update система создаст F4111 (IB) и в F0911 (IB) c распределенной суммой затрат по ТМЦ в поставке (либо в грузе, либо еще как-то).
 +
:: Кт 4136 (GL Class: Item Location)
 +
:: Дт 4134 (GL Class: Item Location)
 +
 
 +
== Ссылки ==
 +
* [https://support.oracle.com/epmos/faces/DocumentDisplay?id=625513.1 E1: 49: Promised Shipment and Delivery Date Calculation]
 +
* [https://support.oracle.com/epmos/faces/DocumentDisplay?id=625512.1 E1: 49: Shipment Consolidation]

Текущая версия на 13:54, 26 сентября 2024

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

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

Режим консолидации отправок/Shipment Consolidation Mode
  • Multiple Order Consolidation
  • Single Order Consolidation
  • Transactional Consolidation
  • No Consolidation

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

До версии 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
Условия консолидации для дат в закупках

Purchase Order Level:

  • Если дата Requested Delivery Date = Пусто, то система укажет текущую дату;
  • Promised Delivery Date система всегда передает в TMS значение 0.

Строка заказа будет объединена с существующей отгрузкой только в том случае, если произошло хотя бы одно из следующих событий:

  1. Обещанная дата отгрузки/Promised Shipment Date (PPDJ)
    Обещанная дата отгрузки в ЗНЗ не была введена или уже в прошлом;
    -ИЛИ-
    Обещанная дата отгрузки в ЗНЗ равна Обещанной дате отгрузки в Отправке, с которой консолидируется строка ЗНЗ;
    -ИЛИ-
    Обещанная дата отгрузки в Отправке, с которой консолидируется строка ЗНЗ, уже прошла.
  2. Планируемая дата доставки / Promised Delivery Date (RSDJ)
    Планируемая дата доставки в ЗНЗ не была введена или уже в прошлом;
    -ИЛИ-
    Планируемая дата доставки в ЗНЗ равна Планируемая дата доставки в Отправке, с которой консолидируется строка ЗНЗ;
    -ИЛИ-
    Планируемая дата доставки в Отправке, с которой консолидируется строка ЗНЗ, уже прошла.
  3. Требуемая дата доставки / Requested Delivery Date (DRQJ)
    Требуемая дата доставки в ЗНЗ равна Требуемой дате доставки в Отправке, с которой консолидируется строка ЗНЗ.

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

Второй процесс сравнивает новую или обновленную строку с Отправками, доступными для консолидации в таблице, только после попытки консолидации с любыми Отправками, доступными в кэше.

Следующие условия должны быть выполнены для попытки консолидации:

  • Ключевые поля заказа должны быть одинаковыми (только для консолидации одного заказа)
  • Статус отправки < Защищенный статус отправки
    (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
  • ТМЦ должны быть совместимы
  • Существующий Shipment Number <> Консолидированный Shipment Number (Процесс консолидация при удалении строк из отправки)

Следующие введённые поля должны совпадать с соответствующими полями отправки в таблицах (F4215/F4941)

  • NMCU - Origin Shipment Depot
  • ORGN - Origin Address Book Number
  • BPFG - Bulk/Packed Flag
  • 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

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:

  • MOT - Method of Delivery
  • CARS - Carrier
  • FRTH - Freight Handling Code
  • FRSC - Rate Schedule

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:

  • CAR1 - Carrier1
  • CAR2 - Carrier2
  • CAR3 - Carrier3

Даты

Для ЗНЗ / Other Inbound

Даты ЗНЗ:

  • Request date (DRQJ) - Дата запланированного прибытия ТМЦ или запланированного выполнения действия.
  • Scheduled Pick date (PDDJ) - The promised shipment date for either a sales order or purchase order. Эта дата представляет собой день, когда товар может быть отгружен со склада.
  • Original Promised Delivery (OPDJ) - Первоначальная обещанная дата доставки для ЗНЗ.
  • Actual Ship Date (ADDJ) - The date on which the shipment to the customer is confirmed as shipped. During shipment confirmation, the system updates the Sales Order Detail table (F4211) with this date.
  • Promised Shipment (PPDJ) -The promised shipment date for a sales order. This date represents the day that the item can be shipped from the warehouse.



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

  • Требуемая дата доставки/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 (WorkCalendar 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 запишется в Поставку.

Freight Update

какой-то текст:

Updating Freight Charges

какой-то текст

Распределение затрат на ТМЦ для Inbound Transactions

The system allocates freight costs on a percentage of the total weight or volume of a shipment.

Item Quantity / Weight Percent of Total Weight Amount by Item
Item A 100 / 50 25 3.13 (25 percent of 12.50)
Item B 50 / 60 30 3.75 (30 percent of 12.50)
Item C 10 / 90 45 5.62 (45 percent of 12.50)
Total 200 N/A 12.50

As illustrated, the freight is allocated by the total weight by item. Then, each piece is allocated its corresponding proportion of the freight cost. Each piece from the table would be allocated these freight costs:

  • Item A: 3.13 ÷ 100 pieces = .0313
  • Item B: 3.74 ÷ 50 pieces = .075
  • Item C: 5.62 ÷ 10 pieces = .562

Проводки и счета Freight Update

Каждый Shipment имеет параметр Источник (Source of Order):

Код Источник Направление поставки
I Other / Inbound Inbound
O Other / Outbound Outbound
P Purchase Order Inbound
R Purchasing - Customer Return Outbound
S Sales Outbound
T Sales - Customer Return Inbound

Каждый Shipment имеет параметр Freight Handling Code значения из UDC (42/FR). Для кодов Freight Handling Code используется Special Handling Code.

Код Источник
Пусто Prepaid
1 Collect
2 Prepaid, not billable
9 Bypass routing and rating

Сочетание Source of Order и Freight Handling Code (точнее его SPHD) определяет условия обработки маршрута (Routing), а значит и тарификации (Rating). Каждый Маршрут (Route) содержит указания на Тарифный план (Rate Schedule) для каждого направления: Outbound Freight Rate Schedule и Inbound Freight Rate Schedule. Тарифный план включает в себя различные Тарифы (Rates). Каждый Тариф имеет возможность указать код Charge Codes для Payable и Billable.

Каждый Charge Codes содержит параметры:

  • G/L Offset. Класс ГК для работы АИ Freight Update.
  • Freight Allocations. Распределять затраты на тариф по номенклатурам в поставке Freight Update.
  • Taxable (Y/N). Налогообложение.
SPHD = blank
(Prepaid)		 SPHD = 1
(Collect)		 SPHD = 2
(Prepaid, not billable)		 SPHD = 9
(Bypass routing/rating)
Outbound Shipment
(SRCO = S, R, O)		 Routing = Y
> Billable = Y
> Payable = Y		 Routing = [1]
> Billable = N
> Payable = N		 Routing = Y
> Billable = N
> Payable = Y		 Routing = [2]
> Billable = N
> Payable = N
Inbound Shipment
(SRCO = T, P, I)		 Routing = N Routing = Y
> Billable = [3]
> Payable = Y		 Routing = N Routing = [2]
> Billable = N
> Payable = N
[1] Outbound collect shipments will be automatically routed unless there is both an override carrier and override mode of transport entered.
[2] Перевозчик (CARS) и Режим транспортировки (MOT) должны быть введены в заказ или автоматически заполнены через transportation preference profile для использования кода freight handling = BRR.
[3] Только credit order-based inbound collect shipments (SRCO = T) может использовать billable freight charges.
Billable Charge Codes
Компания выставляет счет, контрагент выполняет оплату.
При FU система создает записи в F4981 и в F4211, с определенным заранее типом строки (есть свой G/L Offset), который после SU может сгенерировать Инвойс. Какой сработает G/L Offset (Charge Codes или Line Types) при SU надо проверять. При SU АИ: 4230 – Revenue; 4233- Allocated Revenue.
Payable Charge Codes
Контрагент выставляет счет, компания выполняет оплату.
  • AutoPay вкл. (P4906) создает записи в F4981 (FT) и в F0411 (??). Система сразу создает ваучер при Freight Update:
    Кт PC* (G/L Offset: Carrier, MOT)
    Дт 4920 (G/L Offset: Charge Code)
  • AutoPay выкл. (P4906):
    1. Сначала при Freight Update создает записи в F4981 (FT) и в F0911 (FT).
      Кт 4921 (G/L Offset: Charge Code)
      Дт 4920 (G/L Offset: Charge Code).
    2. Затем необходимо выполнить создание и подбор ваучера Freight Voucher Match.
      Кт PC* (G/L Offset: Carrier, MOT)
      Дт 4921 (G/L Offset: Charge Code)
Freight Allocations (только для Inbound Shipment)
Если Freight Allocations On, то при Freight Update система создаст F4111 (IB) и в F0911 (IB) c распределенной суммой затрат по ТМЦ в поставке (либо в грузе, либо еще как-то).
Кт 4136 (GL Class: Item Location)
Дт 4134 (GL Class: Item Location)

Ссылки

Источник — http://wiki.sgsproject.nichost.ru/index.php?title=Управление_перевозками_(Черновик)&oldid=108728