inv_89_and_om_89_architecture_changes

PeopleSoft Proprietary and Confidential Fulfillment Architecture Changes 1

PeopleSoft Inventory 8.9 and PeopleSoft Order Management 8.9 Architecture Changes This section provides an overview and describes:

• Fulfillment changes.

• Architecture changes.

• Dates and date time changes.

• Schedule and line numbers.

• Order Management specific changes.

• Archiving.

Understanding 8.9 Fulfillment Changes These are the steps for the release 8.9 fulfillment process:

Inventory fulfillment process

PeopleSoft Inventory 8.9 and Order Management 8.9 Architecture Fulfillment Changes June 2005

2 Fulfillment Architecture Changes PeopleSoft Proprietary and Confidential

The system uses one table, IN_DEMAND, throughout the order fulfillment process. Orders change state as they move through the fulfillment process. Once complete, an order can be archived.

The following table describes how different processing worked in release 8.8 and how it works in release 8.9 now:

Feature or Attribute PeopleSoft 8.8 PeopleSoft 8.9 Impact

Order entry New orders appear as demand lines in DEMAND_INF_INV.

New orders appear as unfulfilled demand lines in IN_DEMAND.

One table used throughout order fulfillment process. Orders change state as they move through the fulfillment process. Once complete, an order can be archived.

Non-stock shipments Order Management will insert non-stocked shipments directly into SHIP_INF_INV.

Drop shipment lines are stored in IN_DEMAND.

One table used throughout order fulfillment process. Once complete, order can be archived.

Reserving Once the demand line has been reserved or ATP promised, the system moves the demand line to DEMAND_INV and deletes it from DEMAND_INF_INV.

Reserve lines stored in IN_DEMAND.


Picking Once the demand line has been picking confirmed, the system moves the demand line to SHIP_INF_INV and deletes it from DEMAND_INV.

Picking lines are stored in IN_DEMAND.


Cancelled lines Any cancelled demand line gets moved to SHIP_INF_INV.

Cancelled lines are stored in IN_DEMAND with the state of canceled.


June 2005 PeopleSoft Inventory 8.9 and Order Management 8.9 Architecture Fulfillment Changes


Understanding Architecture Changes With release 8.9, we have changed the underlying fulfillment architecture for PeopleSoft Inventory, and how it receives demand lines from PeopleSoft Order Management.

Comparing Table Structures Instead of physically moving data between tables as the order proceeds through the fulfillment process, a single set of tables will be used the entire life of the order. Once the order has been completely processed (for example, invoiced and costed, and so forth), you can archive the order.

Table Data 8.8 Table Name 8.9 Table Name

The primary order fulfillment table.

DEMAND_INF_INV (prior to reservations)

DEMAND_INV (between reservations and picking confirmations)

SHIP_INF_INV (after picking confirmations)

IN_DEMAND

This table will be used to control the lock of the demand line.

N/A IN_DEMAND_LOCK

The contact information for the demand line. Prior to shipping, this table acts as an address override. That is, a row will only exist if a demand line address override has occurred. Once the order has been shipped, a row will exist with the historical address.

DEMAND_INF INV,

DEMAND_INV

SHIP_INF_INV

IN_DEMAND_ADDR

The comments for the demand line. A row will exist per comment type, only if a comment has been entered for the demand line or proforma invoice.

DEMAND_INF_INV

DEMAND_INV

SHIP_CMNT_INV

IN_DEMAND_CMNT

The billing information for the demand line.

The will include lines that have been processed by the OM Billing Interface process (OM_BILL) and the Inventory InterUnit Bill Load process (RUN_INS6300).

SHIP_INF_INV IN_DEMAND_BI

Contains a unique single New IN_DEMAND_HASH



Table Data 8.8 Table Name 8.9 Table Name key identifier representing all the keys for one demand line. Used for drop ship sales orders and pegged demand lines (new for 8.9).

Understanding IN_DEMAND The DEMAND_INV record is the foundation of the IN_DEMAND table. We have accounted for fields that exist on DEMAND_INF_INV and SHIP_INF_INV but not DEMAND_INV. We have moved some fields from these three tables to IN_DEMAND_ADDR, IN_DEMAND_LOCK, IN_DEMAND_CMNT, and IN_DEMAND_BI. Some fields were replaced or modified to accommodate new functionality.

Data no longer moves between DEMAND_INF_INV, DEMAND_INV, and SHIP_INF_INV based on the processes that have occurred. All data stays persistent in IN_DEMAND.

Understanding IN_DEMAND Field Changes

Fields moving to IN_DEMAND from SHIP_INF_INV

Field

PICK_CONFIRM_DTTM

INTERUNIT_INSERT

QTY_PICK_BASE

QTY_SHIPPED

QTY_SHIP_BASE

QTY_SHIPPED_CONV

LAST_QTY_SHIP

LAST_QTY_SHIP_BASE

SHIPPED_MESSAGE

QTY_VERIFY_MSG

COSTED_FLAG

UNIT_MEASURE_SHIP

UNIT_MEASURE_VOL

UNIT_MEASURE_WT

SHIP_UOM_CONV_FLAG



Field

STORAGE_AREA

STOR_LEVEL_1

STOR_LEVEL_2

STOR_LEVEL_3

STOR_LEVEL_4

EDI_DT_TIME

BACKORDER_CREATED

BUSINESS_UNIT_PO

RTV_ID

RTV_LN_NBR

RTV_DISTRIB_NUM

PRICE_PO

SHIP_SHORT_WF_DONE

CURRENCY_CD_DEST

TAX_CD_VAT

TRANSFER_COST_DEST

VAT_TXN_TYPE_CD

VAT_APPLICABILITY

IST_DISTRIB_STATUS

PUB_PROCESS_INST

FORM_DISTRIB_STAT

SHIP_PROCESS_TYP

OM_FLG

PSSH_NONOWN_FLAG

DEPLETE_INV_FLG

DEPLETED_DATE

BUSINESS_UNIT_BI

RECV_SHIP_SEQ_NBR

POST_SHIP_INSTANCE

IN_DEMAND Changed Fields

Old Field Name New Field Name

CANCEL_DATE CANCEL_DTTM




DEPLETE_DATE DEPLETE_DTTM

ORIG_SCHED_DATE

ORIG_SCHED_TIME

ORIG_SCHED_DTTM

PICK_DATE PICK_DTTM

PROCESS_INSTANCE

PROCESS_STATUS

PSSH_RUN_STATUS

Replaced by IN_DEMAND_LOCK table

RESERVED_DATE RESERVED_DTTM

RESERVED_FLAG RESERVE_STATUS

SCHED_DATE SCHED_TIME

SCHED_DTTM

SCHED_LINE_NO SCHED_LINE_NBR

SHIP_DATE

SHIP_TIME

SHIP_DTTM

SHIP_EARLY_DATE

SHIP_EARLY_TIME

SHIP_EARLY_DTTM

SHIP_LATE_DATE

SHIP_LATE_TIME

SHIP_LATE_DTTM

CANCEL_FLAG

SHIPPED_FLAG

PSSH_COMPLETE

IN_FULFILL_STATE

CUSTOMER_PO Derived from ORD_SCHEDULE.CUSTOMER_PO in Order Management.

Moved to IN_DEMAND_ADDR

Field

ADDRESS_SBR

COUNTRY_CODE using BUS_PHONE_SBR

EXTENSION using BUS_PHONE_SBR

PHONE using BUS_PHONE_SBR

CUST_CONTACT



Moved to IN_DEMAND_CMNT

Field

DESCR254

Moved to IN_DEMAND_BI

Field

INTFC_ID

INTFC_LINE_NUM

INVOICE

LINE_SEQ_NUM

BILLING_STATUS

Added to IN_DEMAND

Field Name

ADDR_OVRD_LEVEL

IN_FULFILL_STATE

IN_PRIOR_STATE

OPTIONAL_SHIP

QTY_CODE

QTY_PER

QTY_PROMISED_BASE

QTY_PICK_OVR_BASE

LAST_PROCESS_INST

VMI_DESTIN_SHIPTO

PRIORITY_SHIP_FROM

IN_LINE_BO_RULE

IN_LINE_RESV_RULE

IN_LN_RESV_BO_RULE

IN_ORDER_RESV_RULE

RESERVE_STATUS

RELEASE_INSTANCE

IN_ZERO_PICK

PEG_STATUS



Field Name

SUP_PEG_STATUS

CLAIM_ID

DP_KIT_PARENT_QTY

DP_KIT_PARENT_UOM

VMI_ORDER_LINK

LINE_FIELD_C1_A

LINE_FIELD_C1_B

LINE_FIELD_C1_C

LINE_FIELD_C1_D

LINE_FIELD_C2

LINE_FIELD_C4

LINE_FIELD_C6

LINE_FIELD_C8

LINE_FIELD_C10_A

LINE_FIELD_C10_B

LINE_FIELD_C10_C

LINE_FIELD_C10_D

LINE_FIELD_C30_A

LINE_FIELD_C30_B

LINE_FIELD_C30_C

LINE_FIELD_C30_D

LINE_FIELD_DTTM_A

LINE_FIELD_DTTM_B

LINE_FIELD_DTTM_C

LINE_FIELD_DTTM_D

LINE_FIELD_N11_A

LINE_FIELD_N11_B

LINE_FIELD_N11_C

LINE_FIELD_N11_D

LINE_FIELD_N15_A

LINE_FIELD_N15_B



Field Name

LINE_FIELD_N15_C

LINE_FIELD_N15_D

IN_PROCESS_DATE (Will be NULL after the order has been depleted. Will default to the current date at demand line creation time.)

OMB_PROCESS_DATE (Will be NULL except for depleted demand lines pending processing by the OM and Inventory Billing processes)

CNTCT_SEQ_SHIP (used for sales orders to get the correct contact information)

Understanding States

We’ve added two state fields to IN_DEMAND, to track an order’s progress through the fulfillment process. IN_FULFILL_STATE tracks an active order’s progress through the fulfillment process. The system uses IN_PRIOR_STATE when a demand line is canceled to note the last state the order reached.

This table represents the values in IN_FULFILL_STATE:

State Description Release 8.8 Equivalent

10 Pending New for 8.9. Used for pending sales orders, non-inventoried items to be billed, invalid demand lines, and Asset Lifecycle Management work orders. All Inventory programs will ignore this state.

20 Unfulfilled Records on DEMAND_INF_INV where CANCEL_FLAG = N

30 Releasable Records on DEMAND_INV where PICK_BATCH_ID = 0 and PICKLIST_PRINTED = N and CANCEL_FLAG = N

40 Released Records on DEMAND_INV where (PICK_BATCH_ID <> 0 or PICKLIST_PRINTED = Y) and CANCEL_FLAG = ‘N’

50 Picking confirmed Records on SHIP_INF_INV where SHIPPED_FLAG = N and PSSH_COMPLETE = N and CANCEL_FLAG = N

60 Shipped Records on SHIP_INF_INV where SHIPPED_FLAG = Y and PSSH_COMPLETE = N and CANCEL_FLAG = N



State Description Release 8.8 Equivalent

70 Depleted Records on SHIP_INF_INV where SHIPPED_FLAG = Y and PSSH_COMPLETE = Y and CANCEL_FLAG = N

90 Canceled Records where CANCEL_FLAG = Y In general, most new demand lines will be created in an unfulfilled state. Here are some exceptions:

• Sales orders in a pending status have demand lines created in a pending state.

• Asset Lifecycle Management work orders have demand lines created in a pending state.

• Invalid demand lines are created in a pending state.

• Sales order demand lines that are on hold are not allowed to move to an unfulfilled demand state.

• Drop ship demand lines that have not been marked for billing.

Non-soft reserved/non-ATP demand lines will be created in either an unfulfilled state or releasable state depending on the non-soft reserved state option on the fulfillment business unit setup.

Understanding IN_DEMAND_ADDR This table stores the contact information for the demand line. Prior to shipping, this table acts as an address override. That is, a row only exists if a demand line address override has occurred. Once the order has been shipped, a row will exist with the historical address.

This is the structure of IN_DEMAND_ADDR:

Field Name

BUSINESS_UNIT

DEMAND_SOURCE

SOURCE_BUS_UNIT

ORDER_NO

ORDER_INT_LINE_NO

SCHED_LINE_NBR

INV_ITEM_ID

DEMAND_LINE_NO

CUST_CONTACT

ADDRESS_SBR



Field Name

BUS_PHONE_SBR

EMAILID

Address Overrides

In Order Management, you can override the address at either the header, line, or schedule levels. This information does not get written to IN_DEMAND_ADDR until either shipping time, or if you have specifically overridden the address on the demand line. To track this, there’s a field ADDR_OVRD_LEVEL on IN_DEMAND_ADDR that controls the override level.

The ADDR_OVRD_LEVEL possible values are:

• H – Sales order header override (visibility to address comes from ORD_ADDR until shipping time)

• L – Sales order line override (visibility to address comes from ORD_ADDR until shipping time)

• S – Sales order schedule override (visibility to address comes from ORD_ADDR until shipping time)

• D – Demand line override (address is stored on IN_DEMAND_ADDR)

Understanding IN_DEMAND_BI This table stores the billing information for the demand line. Because you can have multiple pricing schedules in 8.9, there may now be multiple invoice lines per one demand line. When a demand line is created, the system will not enter a row into IN_DEMAND_BI.

When the OM Billing Interface process (OM_BILL) and the Inventory InterUnit Bill Load process (RUN_INS6300) send interface records to PeopleSoft Billing, the system creates one row in IN_DEMAND_BI per interface record created.

When PeopleSoft Billing processes each interface record, the system updates the invoice and invoice line number on IN_DEMAND_BI.

All programs inquiring on the billing status of a demand line will first need to check the existence of a row on IN_DEMAND_BI. If a row exists, the actual status can be determined by field BILLING_STATUS.

This is the structure of IN_DEMAND_BI:

Field Name

BUSINESS_UNIT

DEMAND_SOURCE

SOURCE_BUS_UNIT

ORDER_NO

ORDER_INT_LINE_NO

SCHED_LINE_NBR



Field Name

INV_ITEM_ID

DEMAND_LINE_NO

INTFC_ID

INTFC_LINE_NUM

BUSINESS_UNIT_BI

INVOICE

LINE_SEQ_NUM

BILLING_STATUS

CONFIG_CODE

Understanding IN_DEMAND_CMNT This table stores the comments for the demand line. The system creates a line per comment type only if a comment has been entered for the demand line or proforma invoice.

A row will exist in this table only if a line comment or proforma comment has been entered for the demand line.

This table replaces DESCR254 on DEMAND_INF_INV and DEMAND_INV and replaces table SHIP_CMNT_INV.

This is the structure of IN_DEMAND_CMNT:

Field Name

BUSINESS_UNIT

DEMAND_SOURCE

SOURCE_BUS_UNIT

ORDER_NO

ORDER_INT_LINE_NO

SCHED_LINE_NBR

INV_ITEM_ID

DEMAND_LINE_NO

INV_COMMENT_TYPE

DESCR254



Understanding IN_DEMAND_LOCK This table is used to lock the demand line for batch processing. The system only creates IN_DEMAND_LOCK records when the table is locked.

To lock a demand line, the system inserts a row into this table. To remove a lock, the row will be deleted. Prior to removing the lock, the field LAST_PROCESS_INST on IN_DEMAND is updated with the process instance from this table for historical use.

The fulfillment background processes will check the existence of a row in this table before continuing processing.

PRCSNAME should be a unique name given to the process performing the soft lock. For batch jobs, it should be the name of the process definition.

This the structure of IN_DEMAND_LOCK:

Field Name

BUSINESS_UNIT

DEMAND_SOURCE

SOURCE_BUS_UNIT

ORDER_NO

ORDER_INT_LINE_NO

SCHED_LINE_NBR

INV_ITEM_ID

DEMAND_LINE_NO

PROCESS_INSTANCE

PRCSNAME

Understanding IN_DEMAND_HASH IN_DEMAND_HASH stores a single unique value representing each demand line’s complete key. It is used for the new pegging functionality included in release 8.9.

See Using Order Management with Pegging.

Field Name

HASH_KEY

BUSINESS_UNIT

DEMAND_SOURCE

ORDER_NO

ORDER_INT_LINE_NO

SCHED_LINE_NBR

INV_ITEM_ID



Field Name

DEMAND_LINE_NO

Dates Versus Date/Times Because of user requests for more accurate reporting, we’ve converted the date fields tracking fulfillment activities into date/time fields. These include:


CANCEL_DATE CANCEL_DTTM

DEPLETE_DATE DEPLETE_DTTM

PICK_DATE PICK_DTTM

RESERVED_DATE RESERVED_DTTM We have also collapsed individual date and time fields into date/time fields:


ORIG_SCHED_DATE

ORIG_SCHED_TIME

ORIG_SCHED_DTTM

SCHED_DATE SCHED_TIME

SCHED_DTTM

SHIP_DATE

SHIP_TIME

SHIP_DTTM

SHIP_EARLY_DATE

SHIP_EARLY_TIME

SHIP_EARLY_DTTM

SHIP_LATE_DATE

SHIP_LATE_TIME

SHIP_LATE_DTTM

Schedule Line Number During the redesign of the inventory data model, we aligned the sales order keys with the fulfillment keys on IN_DEMAND. This required one change, the replacement of SCHED_LINE_NO with SCHED_LINE_NBR. All the fulfillment tables now use SCHED_LINE_NBR. With that said, SCHED_LINE_NBR in release 8.8 was a (5,0) field and SCHED_LINE_NO was a (4,2) field. Therefore, to facilitate the conversion, SCHED_LINE_NBR was changed to be (6,0) for 8.9.



In 8,8, the demand lines coming from purchasing used the 2 decimal places on SCHED_LINE_NO for their numbering scheme. As a result, in 8.9, all demand lines with demand source type PO and PR are having their schedule numbers converted to be:

SCHED_LINE_NBR = SCHED_LINE_NO * 100.

For all other demand source types, SCHED_LINE_NO in release 8.8 will equal SCHED_LINE_NBR in release 8.9.



Understanding How Fulfillment Changes Affect Order Management Because of the fulfillment changes to PeopleSoft Inventory, we have changed the way PeopleSoft Order Management stores data for sales order transactions.

Converting Orders Because we have merged the Inventory fulfillment tables, the following orders are immediately visible in IN_DEMAND:

• Pending orders

• Non-stock items

• Drop shipments

• Kits non-stock

• Configured kits with non-stock components

• Orders on hold

See Also

Understanding IN_DEMAND

Using Pegging with Order Management With release 8.9, the drop ship relationship between the purchase requisition/ purchase order and the sales order has been moved to the pegging tables. The requisition and purchase order keys were moved from ORD_SCHEDULE to the following pegging tables:

Key Table

sales order IN_DEMAND_HASH

requisition REQ_HASH

purchase order PO_HASH

Sales order/requisition or PO relationship IN_PEGGING



This is illustrated in the diagram below:

Sales order pegging process for drop ship relationships

See Also

Understanding IN_DEMAND_HASH



Understanding Archiving With release 8.9, PeopleSoft Inventory provides archiving with Data Archiving Manager. This PeopleTools utility archives depleted data to new archive tables.

We’ve created four archive objects:

• IN_ARCH_DEMAND

• IN_ARCH_ISSUE

• IN_ARCH_SHIP

• IN_ARCH_MSR

These archive objects establish the archiving/history record relationship and the parent/child tables relationship.

For all IN_DEMAND tables and children, we have history tables.

Archive Name Table Name

IN_DMD_HIST IN_DEMAND

IN_DMD_ADR_HIST IN_DEMAND_ADDR

IN_DMD_CMNT_HIST IN_DEMAND_CMNT

IN_DMD_BI_HIST IN_DEMAND_BI

IN_DMD_LOT_HIST LOT_ALLOC_INV

IN_DMD_PHY_HIST DEMAND_PHYS_INV

IN_EST_SHP_HIST EST_SHIP_INV

IN_ISS_HDR_HIST ISSUE_HDR_INV

IN_MSR_HDR_HIST MSR_HDR_INV

IN_SHP_HDR_HIST SHIP_HDR_INV

IN_SHP_MSC_HIST SHIP_FRT_MISC

IN_SHP_SER_HIST SHIP_SERIAL_INV

inv_89_and_om_89_architecture_changes

Documents