StoresToStors_tafr

Overview

 

A merchandizing system publishes the Stores message family to describe the attributes of a Store. Store Inventory Management system needs location information for all Stores referenced in Item, POs, ASN, and/or Stock Order messages.

 

Each published Store has a location type attribute and an array of addresses. Each address has a primary address indication detailing whether this address is the primary address for the store. There may be only one primary address for a store. The store type of physical (denoted with a value of "p") need to be passed on as other store types are not of interest to SIM.

 

Store addresses input to SIM use the Stores message family. Hence, the primary functionality of the StoresToStoresPhys Tafr is to filter Stores messages regarding non-Physical stores and to publish Stores messages for all SIM instances.

 

Functional Requirements

Message type: If input message type is not one of the following. “storecre”, “storemod”, “storedel”, “storedtlmod”  the message will be dropped.

 

Input message routing information: The routing information for an input

WH message must contain the following routing info records

 A “location type” routing info record detailing the type of the location referred in the payload. A value of “p” implies this record is for a physical location and needs to be transformed into a StorePhys message. Any other value will result in the message being dropped

 

Output message routing information: The following routing information records must be present in output messages as per the specifications below:

A “location type” routing info record (<name> tag value of “loc_type”) will have a <value> tag value the same as input “location type” routing info record. Currently, all messages must have an output location type of “p”, since all input messages with other values will be filtered.

 

RibMessage envelope header fields: output 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 is not present, 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 messages’ <publishTime> fields must be set to a date/time equal to or after the input publishTime.

 

Message payload XML schema declaration: 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 must be “StoreDesc.xsd” for output “storecre”, “storemod”, and “storedtlmod” message types.

 

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

 

No primary Address indication: Any input Store payloads

a) Contains an address record but not a “primary address indication” of value “y” or “Y”

 

b) Reference an external partner type will result in an error. The TAFR MDB framework will handle the error.

 

 

Note: This implies that RMS will publish “storemod” messages with a primary address record, even if the modification is only with one of the “header” fields (such as description or currency_code)

 

whcre, whmod and whdtlmod payload processing: The input payload class type for storecre, storemod and storedtlmod payloads will be com.oracle.retail.integration.base.bo.storedesc.v1.StoreDesc class. The output payload class will be com.oracle.retail.integration.base.bo.storedesc.v1.StoreDesc class.

 

StoreDesc records contain one or more AddrDesc records. The first AddrDesc input record containing a “primary_addr_ind” with a value of “Y” or “y” will be mapped to an output (Stores family) AddrDesc record. Only a single output AddrDesc record will be output. All other input AddrDesc elements will be ignored.

 

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

 

Input AddrDesc field

Output AddrDesc field

Required for

Comment

Add1

address1

 

 

Add2

address2

 

 

City

city

 

 

state

state

 

 

country_id

country_id

 

 

Post

zip

 

 

contact_name

contact_person

 

 

contact_fax

dest_fax

 

 

contact_phone

phone_nbr

 

 

primary_addr_ind

 

 

Used to determine if this record is to be output. No field in the output record is mapped to the input field. Only the first input record with a value of “y” or “Y” for this field is output.

 

 

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.