Monday, January 25, 2021

#827 OIC February 21 New Features - B2B Trading Partner Management







Here we are talking about the concept of a host and her remote trading partners. This brings organization to B2B document exchange, essentially defining who can exchange what documents with me and whether the trading partner's role is that of sender or receiver. This is all covered by a B2B agreement. 

B2B documents contain specific fields for sender and receiver ids. The first line of the EDI X12 850 PO doc includes this information - ISA stands for Interchange Control Header.




OIC B2B now supports enforcement of Trading Partners/Agreements; let's look at how this is implemented.


Trading Partner Creation in OIC


Let's begin with ourselves, identified as the Host - 

Here I click on Host Profile and enter an identifier - this will be used in B2B document exchanges; such documents will contain fields that identify the sender and receiver of the B2B document. 









The Identifiers define the host company in B2B transactions, based on standard fields. Here I choose to use the EDI Interchange ID field and set it to the value 1234













Now to the trading partners, the folks with whom I do business. In my example I will be using the EDI X12 850 document; this is a standard Purchase Order. In this case I will be receiving such an X12 850 document from my Trading Partner.

Firstly, I define the Trading Partner


















Now I can add more details on the various tabs - 
1. Contact Email address
2. I also add the unique identifier - in this case, 4567 





















Now to the Agreements tab - this allows me to specify the documents to be exchanged between the Trading Partner and the Host.








As you can see, we can have inbound and outbound traffic e.g. I could send GuinnessBrewery a Purchase Order for kegs of Guinness or the brewery orders Hare of The Dog T-Shirts from me. Let's go for the latter and define the relevant agreement.






Now what would such an X12 850 PO look like for the above use case?

Here are the first couple of lines - 




 

Again check out the first line above - ISA - note the two values - 4567 and 1234, our two unique identifiers. These identify the sender and receiver, for this document exchange.

Now that we have the Trading Partner setup completed, let's look at how OIC supports us in processing such documents.

Creating a B2B Trading Partner enable Integration in OIC

The use case is simple - read the PO 850 document, validate that it applies to a Trading Partner Agreement. Translate the PO 850 EDI format to OIC's lingua franca - XML. Use the resulting data as input to creating a Customer and Sales Order in Netsuite. 

The OIC FTP Adapter has been augmented with new B2B Trading Partner Management functionality.

In this example, I will download my B2B X12 850 doc from my ftp server.

Here is the initial payload I will use - note the first line values










This file is in the following directory of my ftp server - 











Here is my integration flow  - I use the ftp adapter to download the file and then invoke the OIC B2B action to translate the X12 850 doc format to xml.














Here is the configuration of downloadB2B - again, this is using the ftp adapter.























TranslateIncomingPO is configured as follows - 




 



The above screenshot shows the Activity Stream

We see here that Trading Partner Agreement enforcement happens at the translate phase.

The error is succinct - no trading partner identified by 111111T.

Let's try again with the following document - Note the first line with the correct senders and receivers. 



Now the Activity Stream looks good from a technical perspective. But now to another new feature of the OIC February 21 release - B2B Message Tracking -

This is a new menu option - 








Note the 2 tabs - Business Messages and Wire Messages

I begin with the Wire message - essentially the technical message.  








The Business Message - this is the X12 850 message with all its validations etc.
Looks like we have an issue here -



Before going into that - let's review the tabs - 





Clicking on the Functional Acknowledgement Link brings me to the FA message - 


For those not au fait with the FA definition, you can check it out online -


Now back to that Business Error - 


It is complaining about element FOB05 -

So what is this? Again, google to the rescue -


I have only 4 FOB elements in my 850 document.
I add an FOB05 value of CPT and retest -















I now get the error that FOB06 is missing - 
FOB06 is a location qualifier - I add WH - which, incidentally, stands for Warehouse.





I re-test and see the following - 


Now we have success from a technical and business perspective.
Naturally, in the real world, I would not be making such amendments to business documents on the fly.


So let's recap on what we've done so far 


OIC FTP adapter configured for B2B trading partner usage -

This results in the following - the creation of the B2B Wire message


 
The next step is to use the B2B Action from OIC - to translate from X12 format to OIC.
Again, I sue the B2B Trading partner option here. This will check that the documents adhere to a B2B agreement i.e. the sender is allowed to send this document type to the receiver. The Sender/Receiver info is in the first line of the X12 850 doc - 


 
4567 identifies my Trading Partner - GuinnessBrewery
1234 - identifies the Host - i.e. my organization

We also saw the strict validation done by the TranslateIncomingPO action.
This action does the following - 
1. Sends the Functional Acknowledgement
2. Validates the incoming doc
3. Translates into XML format

Here is the response from that action -


btw. the strict validation of the incoming B2B doc can be deactivated here - 


The Translate output includes references to the Business and Wire Messages.

Now I need to create another integration that will take the b2b message as the basis for Customer and Sales Order creation in Netsuite.

The input for this integration will be the output from the Translate action.  


I save this locally.




I create a new app-driven integration with a REST trigger and use the above xsd as the request.





I drop the B2B Action again and configure for FETCH -









Now I drop the Netsuite connection and configure for creating a Customer -





Now to the mapping - Map to FetchB2BDoc -



Finally the Map - CreateCustomer - 



Note the EDI 850 document representation on the left -

I just map the customer name from the N1 segment -







I map the Netsuite Internal Id to the response -


Now all I need to do is update the previous integration to call this one.
This I do and test - 



Excellent stuff!

Conclusion 

So a final recap - How did I implement the processing of the EDI X12 850 Purchase Order?
The B2B metadata setup was rather simple - create the Host and Trading Partner(s) and their unique identifiers. Then I created the agreement between GuinnessBrewery and the Host. The agreement stated which b2b documents are being exchanged and in which direction - inbound / outbound.

The First Integration downloads the B2B doc from my sFTP Server - 


 

It then uses the B2B action to Translate the PO -


 
The first integration then calls the 2nd integration to FETCH the B2B message in XML format -




Finally, transform the data for the target system, in my case, Netsuite.

Think of the first integration as a pre-processor, that validates the Trading Partner Management aspect as well as the semantics of the message.

The second integration processes the B2B doc - fetching it in XML format and sending it downstream. 


































 



No comments:

Post a Comment