Hello.
Welcome to the second of two tutorials that describe how to configure ZEDI so that it can exchange transactions with your CargoWise system.
The topics covered are:
1. Configuring ZEDI to exchange transactions with CargoWise
2. Using metadata extracts to make life easier when handling CargoWise transactions
This tutorial deals with the second one. If you’ve not watched the first one yet then please do so now. The material in this tutorial will then make more sense.
Previously, we’d configured ZEDI so that it could receive transactions from CargoWise. When this happens, the files from CargoWise are added to the list of transactions as “UniversalInterchange” files from the partner you created to represent CargoWise as a whole.
The problem with this is that a UniversalInterchange file can convey a variety of different transaction types, such as WarehouseOrder, ForwardingConsol, AccountingInvoice and so on.
It would be far better if ZEDI could show them as WarehouseOrder, ForwardingConsol etc. rather than UniversalInterchange.
Similarly, the UniversalInterchange files will contain information destined for a variety of different recipients, so it would be preferable for ZEDI to assign them to the corresponding trading partner rather than the generic “CargoWise” partner.
In this way, instead of seeing something like this on the transactions screen, we would see this.
Doing this makes working with the list of transactions much easier, and it also simplifies the mappings and actions you would use to process the transactions.
Unless this was done, we’d need to have one mapping designed to process “UniversalInterchange” files from “CargoWise”. That mapping would then need to contain lots of complex logic to handle the various combinations of data type and recipient it might encounter, making that mapping difficult to manage and maintain.
By changing the document type and trading partner to appropriate values, we’re able to use individual mappings designed to handle very specific combinations of partner and document type. These are far easier to develop and look after.
The ZEDI action that allows you to set this up is “Metadata extract”. This action is commonly used to extract items of interesting information from the transactions, such as invoice numbers, shipment numbers etc., but it can also be used to change basic information about the transaction, such as the document type and partner.
The mapping used by the metadata extract would be coded to produce a file like this:
A <Metadata> section is also used in this example to capture useful items of information from the transaction but, more significantly, an <Update> section is used to change the partner ID and document type of the transaction to the appropriate values.
If we look at a UniversalInterchange file from CargoWise, the start of it might look like this:
The recipient is identified in this tag, and the document type is found in this tag.
So, our stylesheet can easily map the document type to the <Update> section in its output, which allows ZEDI to change the transaction from UniversalInterchange to a more appropriate document type.
The partner ID is slightly trickier, but not much. We need to map a numeric partner ID to the <PartnerID> tag in the <Update> section, but what we have in the <RecipientID> tag is a nine-character code.
So, we need to translate the recipient ID into a numeric partner ID.
Fortunately there’s an easy way of doing this using a ZEDI function called GetPartnerByIdentity().
This function accepts an identity string as a parameter, and attempts to find a trading partner that has it in their list of identities. It will return a snippet of XML that will contain a list of the partners that have that identity.
For the sake of this description, we’re going to say that the recipient is ACE Vegetables. Within CargoWise they’re known as “ACEMANPRD” and within ZEDI they’re setup as partner ID 37.
In the identities section of the partner definition, we can add “ACEMANPRD” as an identity for this partner.
The metadata extract stylesheet can now use the GetPartnerByIdentity() function to determine the partner ID. The code looks like this:
The recipient ID from CargoWise is passed to the GetPartnerByIdentity() function and the XML it returns is stored in the variable $Partner.
The <Update> section is coded to only output the PartnerID if at least one match was found, and then the partner ID tag is populated using this expression.
Using a metadata extract to pre-process CargoWise files in this way makes the development of your stylesheets far easier. It also makes the information on the transactions page far more meaningful, which in turn makes it easier to find the transactions you’re interested in.