When shipping goods, there are many requirements that needs to be fulfilled. You have the ability to have correct addresses, customer requirements, freight forwarder requirements and legal requirements. To solve this we have many different “systems” in Dynamics AX 2012 (and earlier versions) to solve each of these requirements. Some of these systems are:
- Sales Shipping Stats – Print the std. AX delivery label, and get volumetric information on the packingslip/invocie.
- Bill of Lading – A document used with the freight forwarder to keep track of where to deliver the goods.
- Packing material – A system to keep track of fees related to packing material
- Ship carrier integration – A system for integrating to shipping software, like UPS Worldship og Clipper ship. Can also be used in „test mode“ if you don’t have such a shipping software.
I have gone as deep as possible into the subject to understand, and my judgment is “The data model for storing and maintaining package information in Dynamics AX 2012 is a mess!” In reality we have more than 4 different systems for maintaining package information. In reality this means we could have 4 versions of the truth. And to cover all eventualities and requirements of a advanced distribution company we need to make sure that we update all the necessary information in all 4 different systems. If Microsoft is reading this post, my suggestion for the next release is to combine these systems into one.
But it can take several years before our customers could benefit from such a change. So this blog post is about how we can make this work with what we have. First I will go deep on each of these 4 “systems”.
Sales shipping stats
The first “system” is the Shipping Specification. These are fields you register when you do packing slips.
Here you can also select to print out the standard AX delivery label.
The design is not very impressive and it clearly needs some customizations to make this acceptable for any customer of freight forwarder. But I guess that the idea from Microsoft is that shipment labels is not printed from Dynamics AX, but from a shipping software.
There also exists an inquiry form, where you can reprint the standard Dynamics AX 2012 delivery labels. I have found this menuitem available in the main manu under sales –> inqueries –> distribution –> Shipments. (Quite confusing since this is a terminology used for WMSShipments)
After the packingslip is posted, the user cannot change the data here.
The information of this is stored in a table called SalesShippingStat.
The “filling” of this information is manually done before doing a packing slip update, but it gets “marked” with Packingslip ID in the following code.
We see from this code, that the Sales Shipping Stat system does not have any uniqueness on the data or cartons. This code just related to get the summary of weight and cartons on the packingslip. Also see that the SalesParameters.useShippingStatOnPackingslip must be enabled for it to work.
Bill of Lading
The bill of lading is a receipt for goods that the carrier agrees to transport and to deliver to a designated person. It shows the list of goods delivered for transportation. In case of loss, damage, or delay, the bill of lading is the basis for filing freight claims. The bill of lading includes information about:
- The customer order.
- The carrier.
- The origin and destination of the shipment.
- The number of units in the shipment.
- Freight charge terms.
- Special instructions.
The bill of lading system is originating from the shipping module, and do not share any information with the SalesShippingStat system. It makes it possible to create a formletter like this :
The bill of lading can be both automatically and manually created,
The Bill of lading system is much more comprehensive than the sales shipping stat system, because it is possible to have some kind of unique ness.
The tables and fields used in this system is the following:
As seen here, the tables are missing the WMSPickPalletId or any SSCC-capable fields.
The tables refers to the following :
The automatic creation of BOL’s are done in the WMSShipment.ship method:
What I would expect from the BOL, is that the uniqueness of each package/pallet would be more clear. In a consolidated picking scenario we do have the WMSPickPalletID, that could provide this uniqueness, but this information is never passed into the bill of lading tables.
There is therefore no way to pass information like SSCC etc, or to use the BOL system as a basis for ASN/EDI processes. It is all about creating the Bill-Of-Lading document.
The third way of dealing with packing material is the Packing material tables
The packing material is primarily for calculating a packing material fee. The table is normally filled in when a sales invoice is posted.
The tables look like this:
The packing material system therefore seems to only have one single function. To keep track of packing material fees, and not for logistical purposes.
Shipping carrier integration tables.
The shipping carrier interface feature allows Microsoft Dynamics AX customers to integrate with shipping software. The shipping software packages can pull information from Microsoft Dynamics AX, process packages, and then move their information into Microsoft Dynamics AX, eliminating manual entry and improving tracking visibility.
In the Shipping Carrier Interface for Dynamics AX 2009, Microsoft described this feature as this in the following whitepaper.
It is intended that the packing is handled in an external shipping, and then later transferred to Dynamics AX. This is described as a process that happens between packing slip and invoicing.
It is possible to manually fill in the information, by placing the carrier integration in “test-mode”. When posting the packing slip update, then the following screen will appear:
If we look deeper into the implementation of this ship carrier system, we see that it is interesting, because it does contain much what is needed. I would say that it is the best “survival candidate” of the 4 different systems.
What happens, when the packingslip is posted is the following:
PS! Check out the calculation of the ShipCarrierCODPackage.codAmount. It does not cover discounts!
The fields in the requester table contains the following:
It is a bit sad, that it does not transfer any information about already created pick pallets into the ShipCarrierShippingRequest. In a consolidated picking scenario often these pick pallets have already been created, and it would simply the process of that was available for the shipping software.
It is in the process made so that the shipping software will return data into a staging table, that contains the following fields.
What is interesting here, is that the PackageId field, that is actually extended from WMSPickPalletId. So this means that pallet ID can be returned back. What is missing is information about width, height, length and volume. But Microsoft have placed this information in the table ShipCarrierCODPackage:
But this volumetric information is never filled in by standard AX. The table is only created from AX if there is a COD(Cash On Delivery).
A solution suggestion
There are some facts. We have AX 2012 and AX 2014 is not here yet. Our customers hate large footprint customizations, because they make upgrades more difficult. And there is already many dependencies in AX 2012 that we need to take care of. So what do I do for my customers ? I cheat the system.
- When picking all picking transactions will be marked with a pick pallet ID.
- When Packing I have a new table, that is quite large and „flat“, but contains almost all I need to fiels for my labels, freight charges, weight, volumetric information ++++
- After packing is done per shipment, then I will generate information’s into all the 4 systems from the „New architecture“ system, and prevent the standard AX to generate this information.
This gives me much more control, and also the ability to have uniqueness on all outbound cargos, tracking +++. And my footprint is ZERO in standard AX, and compatible with my PDA and label printing system (BTI)