UPS World Ship XML Import from Dynamics GP

Problem

The Sales Order Fulfilment (SOP) software I wrote for Microsoft Dynamics GP, deals with multiple Dynamics GP companies. You can choose the company and fulfil any available pick lists for sales orders or invoices from that company. The software implements a least cost parcel routing engine. If it decides to route to UPS or TNT carriers we wish the software to ensure that that carrier invoices the correct originating company, avoiding the necessity for intercompany transactions in the accounting system to apportion costs.

The parcel details are sent to the UPS World Ship software as XML files, generated from an XSLT against the order tables SOP10100 and SOP10200 and several custom tables for pick lists and despatch records.

History

The XML Import has been something we have used for many years, since World Ship 5.0, I think we are on 11 now. However when we enquired about having multiple shipper billing accounts it was not possible without a separate instance of world ship for each carrier account. It was something that was mooted as a feature of the next version.

Last Week

Time has moved on and UPS upgraded us recently to the current version of World Ship, so I revisited the problem.

I investigated the Openshipments.xdr schema file for the new version of World Ship to see what had changed. I found a new element definition as shown below for the shipper UpsAccountNumber, i.e. the place the cost for the shipment should be invoiced to.

<ElementType name = "Shipper" content = "eltOnly" order = "seq" model = "closed">
<element type = "UpsAccountNumber" minOccurs = "0" maxOccurs = "1"/>
</ElementType>

I then changed our XSLT to add a node in our outputted XML, and a parameter to pass into the XSLT so that I may pass the UPS account number to the XSLT.

<Shipper>
<UpsAccountNumber><xsl:value-of select="normalize-space($AccountNo)"/></UpsAccountNumber>
</Shipper>  

After ensuring the accounts were set up and activated in the Shipper Setup of World Ship, we tried it out, thankfully it just worked, the consignment was generated against the company for who the order had been fulfilled.

TNT

We also use the auto import utility with TNT Express Shipper. In this case it is a fixed length text file import, but I applied a similar upgrade for TNT with our technical representative a couple of weeks ago. This results in the account number getting passed and mapped in the TNT software so that again the correct company gets the invoice.

TNT Errors

Another advantage of the new TNT software is that it passes back the consignment number and any errors that have occurred during the import, so it does a full handshake – like UPS have done for a long time. This makes my life easier as I don’t have a job running anymore to pluck the consignment numbers from the TNT SQL database in order to populate the Dynamics GP tracking number tables in Dynamics. As it happens I’ve started using our own consignment numbers now so GP is the source of the consignment number, but having access to errors allows us to correct address records in Dynamics GP that consistently throw exceptions in Express Manager. These exceptions are usually things like town in wrong field or a post code update making a post code invalid that was entered in the past in GP. Mismatches can occur between the versions of post code PAF file on GP and on TNT.

Conclusion

My fulfilment software now passes the account numbers for the carriers through depending on the owner company of the order in GP. This account number is used by TNT or UPS to assign that consignment to the correct company for invoicing, that in turn makes the accounts department happy as the billing gets easier.

Next…

It was also mentioned by TNT that they can now provide electronic invoices, UPS have done for years but this means it is now worth importing the actual cost of carriage back into GP so we can get a better analysis of margin for individual orders.

Dynamics GP Warehouse Despatch Fulfilment .NET

Some years ago I wrote a lovely bit of software to that allowed us to gain much more control over the way that orders are handled by the warehouse at despatch.

Once an order is sent to the "Warehouse" Batch a custom windows service prints off a pick list for that order or sends the order to a "Pending Stock" batch if it is awaiting allocation of more goods due to pending purchase orders or stock shortages. The order is checked for weight and manual handling warnings are printed on the pick if any item requires special handling as does notice get applied should there be hazodous chemicals or problems with air frieghting the item. The picklist is then added to a despatch screen as awaiting picking and fulfilment.

The operative takes the pick list from the printer and goes off to pick the order (version II was always  intended to feed the virtual picklist to PDA's that the staff would carry, not got that one done yet!). Once they have the pick complete, the items are weighed and they then scan the barcode on the picklist at the despatch terminal. The terminal asks the user for the weight of the consignment cartons/boxes and the dimentions if they are exceptional or for export. The wizard then asks for the picker, checker and despatcher names for that pick. Finally it caculates the best carrier for the consignment depending on the weight, if the order has none stock items (thus would be delay if item was to be lost in normal post), if the value of the consignment is over a threshold, the time of day (to catch the next carrier arriving), dimentions are checked for those supported by different carriers, including if the consignment is on a pallet. The soup is stirred and a service and carrier selected to get the items to the customer by the time they requested.

A despatch note is printed by the despatch terminal and tracking numbers are obtained from the carrier systems, and labels printed off for the parcels, and xml sent to the carrier machines so they know all about what they have to deliver.

It automates much more such as preventing duplicate despatches, taking notice of process holds and customer credit issues, charging Credit cards if they were applied to the order, its great!

However I've another company implemenation to do over the next couple of weeks, we are putting Dynamics GP into a computer periferal company that we aquired. Although they have very similar requirements to those already existing they also add in the complexity of a trade counter operation. This means the software now needs to support sales staff at the counter fulfilling orders, producing invoices etc. Cool - I like a challenge. Thus I've cracked open the solution file and started having a look at how it all works again as a refresher to see what needs adapting for the next implementation. Now I've realised that times have moved on with GP and .NET. We now have the WCF and the WPF to help me out together with better webservices in GP. All this application is direct to table, which was the only way to go when it was written, econnect was an arm and a leg and laden with bugs. Now it is a mature affordable soution - thanks MS!

Thus I start thinking about where to go as I also have to think about multiple binning that was never used in the old implementation. This is where you have stock held in multiple locations in the warehouses and set priority for where the stock should be drawn from. Useful if you wish to keep bulk stock up a height and draw it down to accessable locations further down the racks. This lead me to a blog of interest  http://scruffylookingcatherder.com/archive/2008/01/03/custom-dynamics-warehousing.aspx where Jacob sounds he is in a similar suituation to my own using similar technology sets to solve the problems. Jacob also has some interesting posts on development to read.

Now I just need to get my skates on and work out how to get my application working for next week....