Dynamics GP Drop Shipping Sales invoices before purchase invoice with Shipment Notification Tool (SNT)
Hey- I’m going to let you into a little secret. No one talks much about this tool and it is difficult to find information on about it, I read about it some time back and suddenly found a need to use it.
What is it?
The Shipment Notification tool can be an essential tool for Dynamics GP customers who drop ship goods to customers. Drop ship means that the supplier sends the goods directly to the customer, the goods never physically touch your premises. This is a very common situation, for companies using 3rd Party Logistics providers (3PL), those companies may never “touch” the goods they sell, instead the goods are (mostly) sent direct from the fulfilment service provider to the customer. This is more popular in eCommerce situations due to the robust and easy to use API’s provided by companies such as Fulfilment by Amazon making it a simple way to do business.
The problems many companies face when trying to implement this in the real world using Dynamics GP ERP system, is the desire to invoice your customer immediately on receiving the ship notification or delivery notification from the 3PL provider. Most companies are keen to invoice customers as soon as possible for the best cash flow outcome.
Natively GP will require the purchase invoice from the supplier to be input before the goods can be invoiced using a Sales Order Processing (SOP) sales invoice. Suppliers may consolidate invoices, it is not uncommon for a supplier to perform a monthly billing cycle, consolidating invoices over the month. As sales invoices rely on purchase invoices, this will cause a significant lag in the generation of sales invoices and subsequent impact on cash flow and unintended consequence of extending the customers’ credit terms. Not only that, if the customer returns the goods before they are even invoiced, confusion ensues.
How to get it?
Shipment Notification Tool (SNT) is a FREE tool. There are rumours on the Internet that the SNT is distributed within the Professional Services Tool Library, however after going on that wild goose chase it turns out that the Shipment Notification Tool is only available from Microsoft via a support email. A Dynamics Partner, can raise this support case, this is certainly true of GP2013R2. If it is somewhere on Partner Source (the partner version of customer source), then it is well hidden, as no one can find it. The SNT will be emailed by Microsoft as a compressed archive, shown below. Note that Encoreblog had copies of the tool on their website, but I would not trust downloading from an unverified source. Careful consideration should be taken if downloading from the internet. The danger is installing a potentially compromised GP dictionary into your ERP system, that theoretically could have spy or malware in it, potentially transmitting your companies core data, or customer data, to a hacker to sell or use for corporate espionage. Is it really worth the time it saves to take the risk? No reflection of integrity of Encoreblog here, merely trying to raise awareness of this danger in general!
Contained inside the archive, there is a SQL script to create the database objects for the companies using the SNT and a cnk file that should be placed into the application directory of GP. The cnk creates the application enhancements to support the tool in the GP client software.
The behaviour of SNT can be changed using configuration switches in the client DEX.INI file. The following is lifted from the one page of instructions (Shipment Notification.doc).
taShipmentNotificationAlwaysTransfer = true
If this switch exists in the dex.ini and is set to true, orders will always be allowed to be transferred to invoices, even if the Shipped flag in the taShipmentNotification table is not marked.
taShipmentNotificationAlwaysPost = true
If this switch exists in the dex.ini and is set to true, invoices will always be allowed to post, even if the Shipped flag is not marked and the purchase invoice has not been processed. (see posting holds section below)
taShipmentNotificationAllowVoids = true
If this switch exists in the dex.ini and is set to true, invoices will be able to be voided, even if they have Purchase Order Commitments.
When installed, a new GP window becomes available. This form allows the drop ship purchase order items to be selected and marked as shipped. This may not be required depending on the settings of the configuration switches set above. Certainly on testing, after installing this tool and setting the DEX switches it is now possible to produce sales invoice before purchase invoices, that was not possible before.
If the supplier partial ships the order, the Quantity To Invoice and Quantity to Back Order on the sales order can be manually adjusted before transferring to sales invoice. Do not attempt to use the Quantity Fulfilled as this has no meaning for an order that has no physical fulfilment. Note here that the quantity to invoice of the sales line is not tied to the quantity shipped in the shipment notification window.
It seems to be the shipped check box that unlocks the ability to invoice the document. This is annoying as with multiple shipments, after the first shipment the full quantity can be accidentally invoiced on the sales order. Indeed the presence of the POP-SOP link means the following dialog pops up preventing editing of the quantities, so with out breaking the SOP-POP commitment relationship, the whole quantity must be invoiced – argh, no good for partial shipments from suppliers.
Again there is no link or awareness of quantities on the shipping notification window from the sale order. Only awareness of the shipped check box. This means the person invoicing the sales orders must reapply the information that the person marking the purchase order as shipped entered. Duplication of effort and risk of errors in my opinion.
This may be an area that I will address with a modification on the shipping window to update the sales quantities in response to the notification quantities, but I don’t know where that leads me in regard to the commitment, do I simply un-commit the quantity shipped? More work required in this area!
Another limitation of the shipment notification window, in relation to supplier partial shipments, is the ship date can only be entered once. There is only one row in this “table” for the purchase order line, so as the various shipments are made, the same value is updated adding to it more quantity. As a new row cannot be added for each shipment notification, the detail of the dates the shipments were made is lot recordable. The more I dig into this the more I see the need for implementing a total rewrite of the Shipment Notification Tool. However I really don’t want to do that, yet we get many split despatches from suppliers.
Error This document contains one or more posting holds
When attempting to post a sales invoice in Dynamics GP, if the shipping window feature is in use and where a sales order is drop ship purchase order linked, then a dialog may appear. The following dialog box is not really a posting hold error as the text suggests. I suspect the Shipping Notification window modification is piggy backing on the posting holds function to prevent the posting of sales invoices before the purchase invoice has been posted.
The actual costs from the purchase invoice (what we have been charged by the supplier for the goods) cannot be used in the sales order once it has been posted. This error box is preventing the sales invoice being posted until the purchase invoice (with the correct costs) has been processed. This thereby ensures that the drop ship account does not become out of balance due to differences in costs between those recorded in the sales invoice and those recorded in the purchase invoice. This behaviour can be changed with the ini setting mentioned before, taShipmentNotificationAlwaysPost = true. Once this is set the above message is not longer fired and the invoice will post. However more care over the balancing of the accounts is required in this case. This may be appropriate where electronic transactions with agreed pricing is in place and all costs are known up front.
A question on Dynamics GP Community was asking about how the costs are handled. Costs for the sale will derive from the sales order line as this is the only place it can be obtained until the purchase order invoice is later received and posted.