Dropships in Business Central - so close and yet so far

Back in August Kristen Hosman, a Microsoft MVP wrote up a blog entry around drop shipping in Business Central. It was a pretty thorough walkthrough of one scenario, but at the time I let drop that I had "opinions."

I know Kristen only had so much room so didn't cover requisition worksheets for generating purchase orders either - which is the functionality I prefer - but obviously more complex to explain.

I'm going to cover what I have so far added as a PTE to help support my own distribution business to make drop shipping work for us. At some future point, hopefully I can come back and add images - but right now I'd need to spend time to redact commercial data and the kids are calling.

I strongly believe that 80% of the issues I have are cross-industry and cross-business requirements that have just not been implemented by the Business Central team. The first version of this article was a disorganised list. It has now been updated to be clearer that most of this work should be implemented by a Microsoft product team and not partners who should be focused on industry specific and company specific processes.

Cross-industry requirements

• Sales lines inherit shipping agent and service levels from drop ship vendors or warehouse locations rather than the preference of the customer. It cannot only be ourselves who have drop ship suppliers (and in fact our own warehouse locations) that determine what agents are used (a configuration option).

• If a drop shipment from a purchase order directly there is no way to specify package tracking. After logging an issue in GitHub the #msdyn365bc helpfully fixed an event that allowed me to use the shipping number field to populate package tracking number in the sales shipment.

• There is no straightforward way to enter text against a sales line that is automatically carried through to a drop shipment purchase order. This means we had to do lots of extra work to ensure any special instructions are seen by the supplier.

• More contextually aware factboxes that help answer questions that would normally require 3 or more levels of navigation to find that break concentration or make the application frustrating. For example, when entering a Purchase Invoice on the line level makes visible a factbox if it was a drop shipment and shows the related sales order number and date shipped and provides a direct link to the sales document to help spot any pricing issues early.

• There really should be a simple configuration that supports drop ship and special orders being automatically created if there is just a single potential vendor for that item. Even requisition worksheets are a pain and just an extra task to remember. I'm sure there is a way to code this, but should we really need to. Even an action that is called directly from the sales order to generate these would be preferable.

• For some reason, the team decided that shipment date = delivery date = receipt date on purchase order, regardless of the shipping agent and service level. This is obviously never true, but seems to be the answer, because the alternative was too hard to be addressed. Updated dates on drop-ship lines does not update the corresponding order - which clearly in real-life must be the case.

• By default, when you choose Order -> Special Order or Drop Shipment on a line in a Sales Order or Purchase Order it is opened in Read Only mode. This is quite bizarre since very often the user does need the ability to edit and charge prior to performing an action. This forces you to manually search for the related order.

• No intelligence, just intransigence when it comes to editing a sales order or purchase order line that has a related drop ship or special shipment. Rather than allowing you to adjust a quantity (and automatically update on the related line) you flat out can't. Instead, you need to delete the line, adjust the original and recreate. You need to have the same unit of measure, even though the system knows what the conversion is and should allow flexibility on this.

• Lot Tracking that turns on/off by drop shipment vendor and not just at the item level. This allows flexibility to say that some items we buy into our warehouse are tracked at a lot level, but when drop shipped we don't care as the lot tracking is handled by the supplier (as long as we keep what the related references were for the drop shipment).

Platform capabilities

• A micro-service that can returns ranked proximity matrix between addresses to help solve questions related to location selection, shipping agent selection and I'd imagine multiple other questions.

• Ability to programmatically decorate a header field with whether it is an inherited field from a card (specify related card field) or a line field with whether it has been inherited from a header field or another card field. This would allow UX to provide much better visual guidance as to whether a value has been overwritten and what data is coming from where.

• There should be a specific field type called indicator that can be associated with a line or a specific field (in which case the grid displays it inline). We currently use on sales order lines in dedicated list pages and subforms to help determine if dropship has been ordered and for many other things using a hack of a field with emoji and drill-down events.

Industry specific

• We extensively use freight inclusive pricing in Australia's B2B food supply-chain. Our issue is that as we ship pallets, the type of nation-wide flat pricing available for some parcels don't work for us. In fact, our suppliers also provide freight inclusive pricing based on the destination city (99% of orders are to major metro business customers). So, we added vendor pricing rule modifiers where we add/subtract pricing based on the location goods are going to. These are used for generating our own customer price lists, but also modify the purchase cost when using purchase order or requisition worksheet methods.

• In addition to inheriting shipping agent from a drop ship vendor we specifically needed a way to specify for each delivery zone what shipping service is used to calculate the use of different agent services which different expected durations.

• We have customised our solution to track Chep/Loscam pallet accounts, whether customers require certificates of analysis and to provide any order specific instructions to suppliers related to drop shipment orders. Thanks to ForNav these are super simple to add into drop shipment purchase orders.

• We have added Min/Max style durations on shipping agent service levels for us to do an Amazon Style delivery date range indication. These are currency provided in a fact box for whoever is entering an order - to remind them what notes potentially should be added.

• If a customer requires a certificate of analysis, but the item is not lot tracked, then we show an indicator that allows them to add a attachment at the line level (standard functionality) and will include that attachment in the shipment advice email that goes to customer (along with any certificate from lot tracked shipments).

• Intelligence use of blanket orders. Often, we use Blanket Orders in a drop-ship scenario. In this situation there is no automatic way to ensure the corresponding blanket purchase order is used when generating the purchase order lines.

How does it compare to other platforms?

I'm lucky to enough to have experience with SAP B1, NetSuite, Odoo and Acumatica and each has their own strengths and weaknesses. Here is where they are better worse.

• SAP B1 allows you to designate a specific location as a drop shipment location and whether that location is lot tracked. Removing that being just at item level creates more flexibility in how items are managed in a supply chain.

• NetSuite and SAP B1 prompt creation of the related drop ship purchase orders directly from the sales order. Meaning that purchase orders are never forgotten, and allow update of pricing after the event.

• NetSuite intelligently creates a sales shipment record (that is editable) from a drop shipment purchase order - which allows entry of tracking details and is more intuitive to an end-user, rather than saying a purchase order is received. This is a limitation of #msdyn365bc due the fact that a sales shipment created by posting routines and isn't really an editable document that users can work with.