This chapter covers the following topics:
The following list represents the steps that you must perform in Oracle e-Commerce Gateway to enable Inbound Planning, Shipping, and Production Sequence Schedules:
Step 5: Validate Interface Data File Map for Each Trading Partner
Step 6: Validate Interface Data File Business Rules by the EDI Translator
For details of all required setup procedures, refer to Overview of Oracle Release Management Setup Steps.
It might be necessary to define additional code conversions for UOM (unit of measure), a category used in multiple Oracle e-Commerce Gateway transactions.
Existing UOM code conversions should be evaluated to ensure that you have defined all internal and external values to be used on inbound demand transactions. Additional values might be required, both generic and trading partner-specific.
Any new internal value must also be set up within Oracle Inventory, for example UOM conversions.
For details of all of the required define procedures, refer to Step 14: Define e-Commerce Gateway Code Conversion Values.
RLM_SHP_DEL_CODE specifies the days for routine shipments and deliveries. The seed data for Oracle e-Commerce Gateway Code Conversion includes both ANSI X12 (ele. 678) and EDIFACT (code 2015) Shipment Delivery Pattern Codes.
You can define additional generic or Trading Partne- specific Shipment Delivery Pattern Codes. This code conversion enables you to define customer specific internal Shipment Delivery Pattern Codes using the Release Management Maintain Ship/Delivery Pattern Codes form. They are then mapped to external EDI values using customer keys in Oracle e-Commerce Gateway as needed.
It might be necessary to define trading partner specific values of Oracle Release Management Data Elements requiring code conversion that are used for inbound demand.
For example, one customer might consider a purpose code of Change to mean a Replacement of a subset of items on a previous schedule; another customer might consider a purpose code of Change to mean a Net Change of all data on a previous schedule. To ensure that the Demand Processor will handle the data from the first situation correctly, a trading partner-specific code conversion for RLM_TRX_PURP must be defined to link the external purpose code of Change to the internal purpose code of Replacement.
The following RLM code conversions are defined for inbound demand, and are used for SPSI, SSSI, and PSQI transactions. New internal values cannot be added, but new generic and trading partner-specific external values can be cross-referenced to existing internal values:
RLM_SCHED_TYPE
RLM_DTL_TYPE
RLM_ DTL_SUBTYP
RLM_DATE_TYPE
RLM_QTY_TYPE
RLM_TRX_PURPOSE
RLM_SHP_DEL_CODE
Examine each trading partner's EDI implementation manuals for applicable inbound demand transactions to determine if the seeded values will handle the trading partner's EDI demand properly in the Demand Processor.
For example, Modern Truck uses the EDIFACT DELJIT message for two different schedule types; they assign element 1001 of the BGM segment with a value of 241 for Shipping Schedules and 242 for Sequenced Production Schedules. If Modern Truck is one of your trading partners, additional code conversions for RLM_ SCHEDULE_TYPE could be set up as follows:
| Internal | External 1 | External 2 | EDI Standard |
|---|---|---|---|
| Sequenced | DELJIT | 242 | EDIFACT |
| Shipping | DELJIT | 241 | EDIFACT |
However, if another trading partner uses 242 with DELJIT to indicate a Kanban Shipping Schedule, you should set up these code conversions using trading partner keys. If not, define trading partner-specific external values for applicable internal values using the Define Code Conversions form.
Once data file directories, trading partner information, code conversions, and optional customizations of interface data file formats have been performed, use Oracle Applications Standard Request Submission to run extract programs for outbound transactions and import programs for inbound transactions.
Enable Inbound Planning (SPSI), Shipping (SSSI) and Production Sequence Schedules (PSQI) for each applicable trading partner. Specify which EDI Standard is used for the transaction.
For details of all required define procedures, refer to Step 16: Optionally Define Additional e-Commerce Gateway Column Rules.
If you are utilizing the Release Management Trading Partner Layer, it might be necessary to define additional Oracle e-Commerce Gateway Column Rules and corresponding Actions for specific trading partner requirements regarding Inbound Planning, Shipping, and Production Sequence Schedules. Each trading partner implementation manual should be evaluated for gaps between the standard processing and trading partner requirements. See: Oracle e-Commerce Gateway User's Guide.
You can adjust the layout of the interface data file or the mapping of data elements in Oracle e-Commerce Gateway to meet the needs of your trading partners for Inbound Planning and Shipping Schedules. See: Oracle e-Commerce Gateway User's Guide for details.
Validate that the EDI Translator is implementing the following rules for populating the interface data file for Inbound Planning, Shipping, and Production Sequence Schedules:
Note: Some of the rules below are specific to Production Sequence Schedules. Ensure that these rules are implemented for the appropriate Inbound EDI schedules.
All mapping from the EDI transaction to the interface data file is done according to the Master Spreadsheet.
In the Test Indicator attribute of the Common Control Record (0010), a test transaction is identified as T and production by P.
For Planning Schedule/Material Release, constant value SPSI must be placed in the Document ID attribute of the Common Control Record (0010).
For Shipping Schedules, constant value SSSI must be placed in the Document ID attribute of the Common Control Record (0010).
For Production Sequence Schedules, constant value PSQI must be placed in the Document ID attribute of the Common Control Record (0010).
The standard-specific EDI transaction name identifier must be placed in the Schedule Source 1000 record. For example,
X12 - “830”, “862” or “866”
ODETTE - “DELINS”
EDIFACT - “DELJIT” or “DELFOR”
The Note/Special Instruction segment is a floating segment that might occur anywhere in the transaction, but its placement in the interface data file will depend on the value of the qualifier and whether it applies to the schedule as a whole or to the scheduled item. If this segment is GEN, DEL, or PUR, then it should be loaded into record 1010. If this segment is LIN, then it should be loaded into record 2140.
Note: For Production Sequence Schedules, if the Note/Special Instruction segment is LIN, then it should be loaded into record 4030.
The date format is CCYYMMDD HHMMSS, which is 15 characters. Note the blank between the date and time. If time is irrelevant to the data field, it must be all zeros or blank.
For Planning and Shipping Schedules, the Quantity Qualifier from the EDI transaction beginning segment (BFR05, BSS11) must be assigned by the EDI Translator application to each demand detail from the FST segment (past due, firm, or forecast requirements) in record 4000, but not with authorizations, shipment/receipt, or other information.
For Production Sequence Schedules, the Quantity Qualifier from the EDI transaction beginning segment (BSS11) must be associated by the EDI Translator application with each requirement detail within the DTM segment loop, in the interface data file at 2000 or 4000 level unless specifically overridden by a value in QTY01 element.
The Purchase Order Number, if specified in a segment in the header level, for example the EDI transaction beginning segment (BFR11, BSS10), must be associated by the EDI Translator application with each schedule item detail that does not have a different Purchase Order Number specified in the detail level 2000 record.
If the JIT segment is used in a Shipping Schedule to indicate multiple requirement quantities/times in a period, each JIT segment must have its own 5000 level record. On the 5000 record, you must populate the Shipment Time and the Quantity, but leave the Ship-To Destination Code, and UOM blank.
For example, a firm demand quantity of 1000 to be delivered on 01-Nov-2004 with order number 1234 has five timed deliveries for that day. This would be indicated in the 862 as:
FST*1000*C*D*110104**002*ON*1234
JIT*100*0700
JIT*150*1000
JIT*200*1200
JIT*250*1400
JIT*300*1700
One 4000 record would be written to the interface data file, with the date, order number, firm demand status, and bucket (day) from the FST segment.
Five 5000 records would be written to the interface data file, with the appropriate time and quantity from the JIT segment. The quantity of all five 5000 records would total 1000.
In the RLM Demand Lines Interface, five item detail rows would be written, containing all 4000 record information combined with the 5000 record. The time from the 5000 record would be concatenated to the date from the 4000 record, yielding a date/time in Oracle standard date format. The quantity of all five item detail rows would total 1000.
If the SDQ segment is used in a Shipping Schedule to indicate multiple destinations for a single FST requirement, each pair of identification code and quantity elements (for example, SDQ03/SDQ04 or SDQ05/SDQ06) must have its own 5000 level record. On the 5000 record, populate the Ship-To Destination Code, the Quantity, and UOM, but leave the Shipment Time blank.
For example, a firm demand quantity of 1000 to be delivered on 01-Nov-2004 with order number 1234 is to be specifically split among three different destinations: 200 to 002BDY, 300 to 002ASY, and 500 to 002DAT. This would be indicated in the 862 as:
FST*1000*C*D*110104**002*ON*1234
SDQ*EA*92*002BDY*200*002ASY*300*002DAT*500
One 4000 record would be written to the interface data file, with the date, order number, firm demand status, and bucket (day) from the FST segment.
Three 5000 records would be written to the interface data file, each with the appropriate ship-to code and quantity from the SDQ segment. The quantity of all three 4000 records would total 1000.
In the RLM Demand Lines Interface, three item detail rows would be written, containing all 4000 record information combined with the 5000 record. The ship-to code from the 5000 record would replace and override the default ship-to information, including any specified default ship-to address fields. The quantity of all three item detail rows would total 1000.
For Production Sequence Schedules, each 3000 or 4000 record (LIN or SLN) must be assigned a unique transaction sequence number by the EDI Translator software, representing its actual sequence in the EDI transaction.
For Production Sequence Schedules, if the DTM/LIN/SLN/PID loop is being utilized, all Subline Product Descriptions must be concatenated into a single occurrence of Notes Record 4030.
For Production Sequence Schedules, if the DTM/LIN/SLN/PID loop is being utilized, all Subline Item Measurements must be concatenated into a single occurrence of Record 4050.