Identify CSOS purchase orders

Use the Identify CSOS purchase orders page to configure how Axway CSOS identifies and handles EDI X12 850 documents or XML purchase order documents.

• Order identification tab – If you send or receive signed orders, you must identify CSOS documents on this tab.
• Order sources tab – Whether you should use the Order sources tab depends on your situation. For instance, if you receive CSOS orders via certain message protocols — AS1, AS2, Secure file, Secure e‑mail, ebXML — a content MIME type of application/x-csos-signed-order is included in inbound message headers. This triggers Activator to validate and unpack the inbound messages as CSOS documents, and using the Order sources tab is unnecessary. On the other hand, if you send CSOS orders, you can use the Order sources tab to specify a particular integration exchange for picking up documents identified on the Order identification tab.
• Related documents tab – This tab enables you to identify documents in the backup directory and database records that need to be retained for as long as CSOS orders. The DEA requires a minimum retention of two years for CSOS orders and related documents. You can also use this tab to link EDI 855 PO acknowledgements to 850 POs. See Link EDI 855 PO Acknowledgement to 850 PO.
• CSOS duplicate orders tab – This tab enables you to specify whether to accept or reject duplicate CSOS orders.

Order identification tab

If you send or receive CSOS orders, you must configure EDI X12 850 documents or XML purchase order documents as valid CSOS documents.

To configure EDI document identification for CSOS

1. Choose one of the following methods:

• To specify that only 850s that meet certain conditions are handled as CSOS documents, click Add an EDI document identifier. For each XPath field, enter the appropriate XPath segment or click the ellipse (...) button to use the wizard to select the XPath segment from your sample 850 file.

1. Example for Identity XPath:
   /envelope/functionalgroup/transactionset[@code='855']/table/loop[@code='N1']/segment[@code='N1' and element[@code='98' and value='ST']]/element[@code='67']/value
   Example for DEA Number XPath:
   /envelope/functionalgroup/transactionset[@code='855']/table/loop[@code='N1']/segment[@code='N1' and element[@code='98' and value='ST']]/element[@code='67']/value
   Example for Order Number XPath:
   /envelope/functionalgroup/transactionset[@code="855"]/table/segment[@code="REF"]/element[@code="127"]/value

• To specify that all 850s are handled as CSOS documents, click Accept all EDI 850s as CSOS purchase orders. For the DEA Number and Order Number fields, enter the appropriate XPath segment or click the ellipse (...) button to use the wizard to select the XPath segment from your sample 850 file.

2. Under Document type, select the CSOS 850 you previously added to the central list of document types.
   If this does not appear in the list, follow the instructions in one of the following:
   
   • CSOS configuration for sending
   • CSOS configuration for receiving
3. Click Save.
4. Click Test and follow the instructions in the wizard to select your sample 850 file. Use the test results to determine if the XPath segments you configured are correct.

To configure XML document identification for CSOS

1. Click Add an XML document identifier. For each XPath field, enter the appropriate XPath segment or click the ellipse (...) button to use the wizard to select the XPath segment from your sample XML file.
2. Under Document type, select the CSOS Purchase Order you previously added to the central list of document types.
   If this does not appear in the list, follow the instructions in one of the following:
   
   • CSOS configuration for sending
   • CSOS configuration for receiving
3. Click Test and follow the instructions in the wizard to select your sample XML file. Use the test results to determine if the XPath segments you configured are correct.
4. Click Save.

Order sources tab

The Order sources tab enables you to set filtering conditions in addition to those on the Order identification tab.

Whether you should use the Order sources tab depends on your situation. For instance, if you receive CSOS orders via certain message protocols — AS1, AS2, Secure file, Secure e‑mail, ebXML — a content MIME type of application/x-csos-signed-order is included in inbound message headers. This triggers Activator to validate and unpack the inbound messages as CSOS documents, and using the Order sources tab is unnecessary. On the other hand, if you send CSOS orders, you can use the Order sources tab to specify a particular application pickup for picking up documents identified on the Order identification tab. For instance, you may want to specify one application pickup for CSOS EDI 850 documents if your company also sends non-CSOS EDI 850 documents.

To add an order source:

1. Click Add an order source at the bottom of the page. The page displays an available default source of any exchange from any party to any party.
2. This default choice means:
   
   • If sending orders – All purchase order documents defined on the Order identification tab are picked up from any application pickup and queued for signing.
   • If receiving orders – All purchase orders defined on the Order identification tab and received from any partner are unpacked, validated against the root certificate for the user’s signature and DEA registration number, and routed to an application delivery.
2. To configure more specific conditions, click on the Purchase order picked up, sent from, or sent to field on the CSOS Orders sources tab. This opens a wizard that lets you choose application deliveries (inbound or outbound transports) and parties (communities or partners). The following table shows example configurations.

Purchase orders picked up from	sent from	sent to
file system integration	Your community	Partner A
file system integration	Your community	Any partner
Trading transport for receiving messages from partners	Partner A	Your community
Trading transport for receiving messages from partners	Any partner	Your community

3. Once you have made your selections, click Save.
   You can specify multiple sources, but take care not to set up overlapping conditions. Once added, you can change or delete a source by using the appropriate buttons. When sending orders, purchase orders are plucked from the normal processing routine of Activator and queued for signing. Once signed, the messages are placed back in Activator flow. For example, if you choose file system application pickup as the message source and any party as the sender and receiver, all properly formatted purchase orders defined on the Order identification tab are queued for signing. All other EDI documents and document types (XML and binary) are ignored. Once signed, the orders are placed back in Activator flow for packaging and sending to partners.

Related documents tab

By default, Activator is configured to retain documents identified as CSOS orders for two years. This tab lets you identify documents such as invoices and shipment notices that must be retained along with the related CSOS orders. One use for this tab is to associate 855 purchase order acknowledgements. See Link EDI 855 PO Acknowledgement to 850 PO for more information.

This tab is similar to the Order identification tab. An important difference is that when you click Add an EDI document identifier, you can type an EDI document type number in the Identity XPath/Document number field rather than specify an XPath. This tells Activator that all EDI documents of that type are CSOS related.

When identifying related documents, specifying XPaths for a DEA Number and Order Number are optional. But doing so helps to link CSOS orders and related documents in Message Tracker.

The age of messages and database records to purge normally is set on a global purge configuration page in the user interface. CSOS orders and related documents have a minimum expiration of two years, regardless whether the global purge age is less than two years. If the global purge age is set to more than two years, CSOS orders and related documents are retained for the longer period.

For information about global purge configuration, see Data storage, backups, and purging.

CSOS duplicate orders tab

CSOS duplicate checking is done for CSOS purchase orders your community receives from partners. Duplicate checking is not done for orders picked up from application pickup unless the community that picks up the order is the named receiver (a rare case).

If your community only sends signed orders but does not receive any, duplicate checking is not applicable and you can ignore this tab.

The target documents are the EDI or XML documents defined on the Order identification tab.

By default, the radio button for rejecting duplicate purchase orders is selected on the CSOS duplicate orders tab. When selected, Activator checks whether an order duplicates a previously received order in the following ways:

• Duplicate order number
• Duplicate DEA registration number
• Duplicate sender name
• Duplicate receiver name

If all of these values are the same as those in a previously received order, the document is given a failed status. You can search for failed documents in Message Tracker.

If you also have configured Activator to check for duplicate EDI documents, checking for duplicate CSOS orders is performed in addition to the duplicate EDI checking.

Aside from choosing whether a community can allow or reject duplicates, you can set up exceptions to the selected behavior on a per-partner basis. Whether you choose to reject or allow duplicate orders, the choice applies to all orders received for the community, unless you define partner-specific exceptions.

Note that the CSOS duplicate order tabs can be found on two pages in the user interface. One location is the identify CSOS purchase orders page at CSOS > Configure CSOS. The other is the message validation rules page, which is opened by clicking Message validation on the navigation graphic at the top of a community summary page. To configure CSOS duplicate checking, you only need to use one of these pages.

To add a partner-specific exception to the selected behavior, click Add an exception for a partner. A wizard displays to help you locate and select the partner or partners you want to add. You can add multiple partners to the exception list at one time using the wizard. Activator applies the opposite of the selected behavior to any partners that display in the exception list.