CustOrder_tafr

Overview

A customer order entry system creates customer orders and publishes CustOrder message family messages. These messages must be forwarded to the warehouse in the form of a StockOrder message. The CustOrderToStockOrderFromRib TAFR converts the message from the CustOrder format to a StockOrder determines which warehouse specific topic to publish the message to.

Other subscribers may also subscribe to the CustOrder message, but these subscribers will operate independently of the CustOrderToStockOrderFromRib TAFR and is out of scope for these requirements.

Functional Requirements

The routing information for a message is must contain the following routing info records

a) a “direct ship indication” routing info record determined by the name field of “direct_ship_ind”. A “value” field value of “Y” implies this is a direct shipment from a third party supplier to the end customer.

b) a “gift certificate indication” (name field of “gift_cert_ind”). A “value” field value of “Y” implies this is a gift certificate fulfilled by a third party supplier.

c) if neither the direct ship indication nor the gift certificate indication has a value of “Y”, then a routing info record with the name of “physical_warehouse_id” must be present. The value field of this record must be a valid warehouse location ID. This field is used to determine the warehouse specific topic to publish the stock order message to.

d) if neither the direct ship indication nor the gift certificate indication has a value of “Y”, then a routing info record with a name field of “facility_type” should be present. If it is not present, then the default facility type from the RIB configuration is used. This value, along with c) above, references a unique entry in the RIB configuration that is used to determine the output topic for stock order messages.

Published output messages for the warehouse will be sent to a warehouse specific JMS destination. The following output message routing info records will be added if not present on the input message:

a. facility_type – the facility type. The value used will come from the default facility type found in the configuration.

If the routing info records contain a direct shipment indication with a value of “Y” or a gift certificate with a value of “Y”, then the message will be published without changes to the supplier topic associated with the TAFR. This message will not be forwarded to a warehouse specific topic. The name of this topic will assume to come from the TAFR MDB deployment configuration.

Outbound messages will have the same values as the input messages for the RIB message envelope tags of : <ribmessageID>, <customFlag>, <customData>, <id>. If one of these input fields are not present, then the output message will also not contain this tag. Nested tags within these fields will also be copied. An input message may contain a null or missing <publishTime>, while the output message may contain a set publishTime. All output message <publishTime> fields must be set to a date/time equal to or after the input publishTime.

The <messageData> or “payload” string will contain a namespace xml schema declaration detailing the URL of a XML schema definition (XSD) file. The directory specification in this URL will reside in the configuration, thus allowing the customer to configure his/her own value. The name of the XSD file specified will be “SODesc.xsd” for output messages of the type “socre” and “SORef.xsd” for output message of the type “sodel”.

Input message fields assumed to be numeric will cause the TAFR to fail if a non-numeric value is found.

Capitalization differences of the input message <type> value will be ignored. Input messages having a <type> value of “cocre” will be mapped to an output type of “socre”. The output payload class type for this set of messages will be the com.retek.payload.SODesc class. The input payload class will be the com.retek.payload.CODesc class. This class contains a COHdrDesc object used for all of the SODesc element values.

The table below details the conversion between the COHdrDesc fields and the SODesc fields. Any CODesc field not contained in the table will be ignored. Note that some fields are input as strings and are mapped to numbers. In these cases, the input is assumed to be a numeric string.

COHdrDesc field	SODesc field	Required for	Comment
amount1	amount1	Neither	COHdrDesc uses string, SODesc is number. Implementation assumes input is string of a decimal number
amount2	amount2	Neither	Same as amount1
amount3	amount3	Neither	Same as amount1
amount4	amount4	Neither	Same as amount1
amount5	amount5	Neither	Same as amount1
amount6	amount6	Neither	Same as amount1
base_code	priority	Both	base_code is string, priority is number. Implementation assumes an integer number string
bill_address4	bill_address4	Neither
bill_address5	bill_address5	Neither
bill_to_address_line_2	bill_address2	COHdrDesc only
bill_to_address_line_3	bill_address3	COHdrDesc only
bill_to_city	bill_city	COHdrDesc only
bill_to_country_code	bill_country_id	COHdrDesc only
bill_to_full_name	bill_address_desc	COHdrDesc only
bill_to_postal_code	bill_zip	COHdrDesc only
bill_to_state_province	bill_state	COHdrDesc only
bill_to_street_address	bill_address1	COHdrDesc only
break_by_distro	break_by_distro	COHdrDesc only
calculated_shipping_amount	shipping_total	COHdrDesc only	shipping_total is a number, implementation assumes calculated_shipping_amount is a decimal string
carrier_code	carrier_code	Both
carrier_service_type_code	carrier_service_code	COHdrDesc only
chute_type	chute_type	Neither
cartonization _flag	cartonization	COHdrDesc only
consumer_direct_flag	consumer_direct	COHdrDesc only
document_type	document_type	Both
event_code	event_code	Neither
event_description	event_description	Neither
message	message	Neither
order_line_cost	order_line_costs	COHdrDesc only
order_number	parent_customer_order	COHdrDesc only
order_total	total	COHdrDesc only	Total is a number, order_total is a string.
order_type	order_type	Both
physical_warehouse_id	dc_destid	Both
pick_complete	pick_complete	COHdrDesc only
pick_not_after_date	pick_not_after_date	Both
pick_not_before_date	pick_not_before_date	Both
po_nbr	po_nbr	Neither
promotions_total	promotion_total	COHdrDesc only	promotion_total is number, promotions_total is string.
rollback_allocation	rollback_allocation	COHdrDesc only
route	route	COHdrDesc only
ship_address4	ship_address4	Neither
ship_address5	ship_address5	Neither
ship_to_city	ship_city	COHdrDesc only
ship_request_id	distro_nbr	Both	distro_nbr is a long, ship_request_id is a string. The implementation will assume ship_request_id is an integer in string form.
ship_to_address_line_3	ship_address3	Neither
ship_to_address_line_2	ship_address2	Neither
ship_to_country_code	ship_country_id	COHdrDesc only
ship_to_fullname	ship_address_desc	COHdrDesc only
ship_to_postal_code	ship_zip	COHdrDesc only
ship_to_state_province	ship_state	COHdrDesc only
ship_to_street_address	ship_address1	COHdrDesc only
taxable_total	tax_total	COHdrDesc only	tax_total is number, implementation assumes taxable_total is a decimal numeric string.

CODesc records also contain one or more CODtlDesc records which are mapped to SODtlDesc records contained within an SODesc. The table below maps source CODtlDesc fields to output SODtlDesc fields. These fields are only copied when the input CODtlDesc record contains an item_status element with a case-insensitive value of “L”. All other CODtlDesc records are filtered and not copied.

Note that some fields are input as strings and are mapped to numbers. In these cases, the input is assumed to be a numeric string.

Any CODtlDesc field not included in the table below will be ignored.

CODtlDesc field	SODtlDesc field	Required for	Comment
amount1	amount1	Neither	CODtlDesc uses string, SODtlDesc is number. Implementation assumes input is string of a decimal number
amount2	amount2	Neither	Same as amount1
amount3	amount3	Neither	Same as amount1
amount4	amount4	Neither	Same as amount1
amount5	amount5	Neither	Same as amount1
amount6	amount6	Neither	Same as amount1
gift_services_line_amt	gift_cost	CODtlDesc Only	gift_cost is a decimal number
item_number	item_id	Both
item_status	item_status	Both
order_line_nbr	order_line_nbr	CODtlDesc Only	order_line_nbr is a 3-digit integer number for SODtlDesc and is a String for order_line_nbr in CODtlDesc
prom_line_amt	promotion	CODtlDesc Only	promotion is an Long (integer) number, prom_line_amt is a string
rdm_dest_id	dest_id	Both
requested_quantity	requested_unit_qty	Both	requested_unit_qty is a decimal number, requested_quantity is a string
sh_additional_line_amt	shipping	CODtlDesc Only	Shipping is a decimal number, sh_additional_line_amt is a string
tax_line_amt	tax	CODtlDesc Only	Tax is a decimal number, tax_line_amt is a string.
total_line_merch_amt	sub_total	CODtlDesc Only	sub_total is a decimal number, total_line_merch_amt is a string.
unit_selling_price	retail_price	CODtlDesc Only	retail_price is a decimal number, unit_selling_price is a string.
unit_tax_percent	tax_percent	CODtlDesc Only	TAX_PERCENT is a decimal number, unit_tax_percent is a string.

Capitalization differences of the input message <type> value will be ignored. Input messages having a <type> value of “codel” will be mapped to an output type of “sodel”. The output payload class type for this set of messages will be the com.retek.payload.SORef class. The input payload class will be the com.retek.payload.CORef class. The table below details the conversion between the CORef fields and the SORef fields. Any CORef field not contained in the table will be ignored.

CORef field	SORef field	Required for	Comment
ship_request_id	distro_nbr	Both
	document_type	SORef Only	Set to a hard-coded value of “C”
rdm_dest_id	dc_dest_id	SORef Only	Implementation will assume that RdmDestId is always set.

The SORef element may contain an array of SODtlRef elements. Certain fields of the CORef input payload will be mapped to a single SODtlRef element added to the SORef payload element. These fields are detailed in the table below

CORef field	SODtlRef field	Required for	Comment
item_number	item_id	Both
	dest_id	SODtlRef Only	Set to a hard-coded value of “-1”

Disclaimer: This document is a general data mapping and reference guide for data coming in and out of Oracle Retail application systems via RIB messages; it is not meant to give detailed information about every possible data scenario.