Subcontracting with Warehouse management – Part 1

Subcontracting with Warehouse management – Part 1

Introduction

A typical real-world scenario for subcontracting in discrete manufacturing looks like this: the local production needs a part at one of the steps which is procured from a 3rd party. This supplier aka subcontractor is provided with some materials for free (“free issue materials”) to perform the work. The free issue materials remain in our local balance. They come back as a semi-finished product with a value-added service on top.

In standard D365FO, a sub-contracted operation is designated with a certain type in the route, and the bill of materials entails a service item representing the value added by the subcontractor. As the production order is getting estimated or converted from a planned production order in the MRP, a purchase order is opened with the supplier for the service item. The receipt of the service item in procurement (with a Delivery note i.e. Packing list or with an Invoice) may report the operation on the route as finished, consume materials associated with this operation, and absorb the sub-contracting cost into the value of the finished product.

The simulation by Microsoft https://docs.microsoft.com/en-us/dynamics365/supply-chain/production-control/subcontracting resembles this story, but it misses one key element: the receipt of the semi-finished product at the inbound location with the mobile scanning device (Warehouse management). Let’s get one thing straight: this just doesn’t work in Dynamics 365 for SCM for the following reason:

Assume, we need a perforated plate for the proverbial Contoso speaker from the Dynamics 365 demo database. We inform the supplier about the need for the perforation with a purchase order, send them the steel plate with a transfer order, receive the perforated plate back, put it on stock and use it in one or many production orders of our own.

Physically we treat the semi-finished product “Perforated plate” as a normal purchase order inbound delivery, but the purchase order is raised only for the service ‘inside’: “Perforation”. In theory, one may even capture a stocked service on a mobile scanner, but it cannot pass the license plate (pallet) number to the subcontracting production order, which is open for a different product number.

Two possible solutions– non-standard and standard – are presented below. None of them is fully satisfactory, though. As Germans figuratively put it, it is “die Wahl zwischen Pest und Cholera”, a choice between the devil and the deep blue sea.

above *) „Knight at the Crossroads“, 1882, by a Russian romantic and early art nouveau painter Viktor Vasnetsov

Prerequisites setup

For this study, we need a new route operation (“Perforation”), and a new Route group (Production control > Setup > Routes > Route groups). The route group Sub will be somewhat special:

The added value is absorbed with the service item, therefore the estimation and costing of the subcontractor’s time it turned off; you will probably create a separate hour cost category with the price of zero.
The Automatic route consumption Quantity is set to Yes to trigger the automatic reporting as finished (RaF) of the semi-finished production upon the PO receipt. Typically, you do not plan the subcontractor’s capacity and consider them a “black box” with a quantity-independent lead time, but for the automatic route consumption and MRP you MUST activate the Process job. The lead time may be entered either in the default order properties of the SFG released product, or in the subcontracting route as a constant Transport time.

Another part of the puzzle for the automatic RaF is the Automatic report as finished flag in the Production control > Setup > Production control parameters:

If you capture production time and yield at Job card terminals with Manufacturing execution, then the ME route/job journals will neglect this flag, and the automatic RaF will only be triggered on manual route journals and subcontracting purchase order posting.
This was about the automatic reporting as finished; the automatic consumption of materials and routes (i.e. quantity reporting + RaF) is triggered by the 2 parameters on the Automatic update tab:

The supplier (en-us: vendor) needs an external warehouse of the Vendor type and a resource of the Vendor type. The subcontractor’s warehouse (here: EUS-104) must belong to the same site as the main warehouse (here: 5). This is because the materials in the semi-finished product BOM are tagged with the subcontractor warehouse in order to trigger a replenishment (“refill”) by an outbound transfer order. Yet the sub-production order may be pointing to our own warehouse (here: 51) to directly post the receipt of the SFG at the local site, if the inbound fransfer EUS-104 -> 51 is organized by the supplier. Such a ‘mix’ of warehouses in one BOM is only possible within the same site in D365FO.

In 99% of the cases, the external warehouse does not Use warehouse management processes, i.e. it is not an ‘advanced’ one, because there is no one from our organization to capture the inbound license plates. Instead, it requires a default receipt and issue location (here: IN_OUT).

The production resource uses this unique Input warehouse, therefore it requires an own dedicated resource group: resource <=> resource group <=> input warehouse.

Should the inbound transfer order from the supplier to our premises be managed by us, then the Output warehouse = Input warehouse = EUS-104.
The Output location is an interesting topic of its own. In reality, the output warehouse comes from the MRP planning, from the MRP demand. The MRP demand comes from the production BOM line which is deemed to consume the subcontracted SFG. Whatever the consumption warehouse is set there, it propagates the planned production order for the SFG, unless the inbound transport is managed by us (then it requires a separate replenishment setting EUS-104 -> 51).

If the same subcontractor delivers products to different warehouses of our own, then the sub-production order does not always comply with the above Warehouse setting at the resource level.
Fortunately, the developer of the method \Data Dictionary\Tables\ProdTable\Methods\defaultOutputLocation() was not sophisticated enough to check if the warehouse in the production order matches the warehouse of the last resource on the production route: the Output location is overwritten unconditionally on reporting the product as finished. It suffices if all warehouses have an output location with the same code RECV-SUB.

Finally, we need a set of released products:

Item numberNameProduct typeStor dim groupItem model groupUoMUnit seq. groupReserv. hier
D0003StandardSpeaker (FG)Item     
M0070Perforated plate (SFG)ItemWare (=WHS-managed)e.g. FIFO (stocked)EaEa PLDefault
M0070_SC*Perforation (service)ServiceWare (WHS) or SiteWH (non-WHS)e.g. FIFO (stocked)EaEa PL or noneDefault or None
M0071Steel plate (RMServiceWaree.g. FIFO (stocked)EaEa PLDefault

*Option 2 only

In standard D365 SCM (hereafter ‘Option 2’), there will be a ‘twin’ service item (here: M0070_SC) defined for every semi-finished product (M0070). As they put it, “…the service product is used to identify the arrival of the semi-finished product”.

Option 1: Subcontracting via Purchase order

1-level BOM: in this case subcontracting is managed through a ‘trading’ flow. The subcontracted semi-finished product is procured via a purchase order and received in stock as a regular inbound shipment. In other words, the subcontracted product does not originate in a production order as otherwise prescribed by the D365 best practices. The component(s) of the product are either provided for free or directly sold to the subcontractor and remain in the master product’s BOM.

In fact, the subcontracting operation “5” in the route on the diagram is not even required, everything is managed through the BOM:

According to the documentation https://docs.microsoft.com/en-us/dynamics365/unified-operations/supply-chain/production-control/manage-subcontract-work-production,
to use subcontracting of route operations for production or batch orders, the product that is used for the procurement of the service must be defined as a product of the Service type. However, an undocumented feature of D365FO allows for stocked products of the type Product (not Service!) in the Vendor-type line.

An analysis of the source code in
\Data Dictionary\Tables\ProdBOM\Methods\postVendorProdBOM
\Data Dictionary\Tables\ProdBOM\Methods\postVendorProdRoute

has shown, that an automatic consumption of the BOM or the route is not supported for Products, unless you extend the ProdBOM.verifyItemType() method. However, it is not such a bad thing: the automatic BOM consumption of a service PO receipt would have consumed the service itself, then any other material at the same route operation (Op 10). But we don’t want to consume the SFG M0070 immediately! The product has to be received, put away to the main warehouse, picked from the warehouse, brought to the step “Assembly” and then consumed.

To backflush the material M0071, it has been attached to the same operation 10 Assembly (note the external warehouse for consumption):

This is not ideal, because the material is needed at the moment of the Op 5 scheduled start. The operation 10 is scheduled later. To mitigate shortages, one should choose the transfer lead times of the free issue materials carefully.
Resource consumption = Yes means the material is picked from the location of the respective machine 5110 (here: 51/002)

Let’s create a production order for D0003 at the site “5”, estimate it and check the MRP explosion:

The estimation of the production order resulted in a purchase order for M0070. In addition, a planned transfer order has been created for the raw material from our site to their site. After the confirmation of the PO by the supplier, this transfer order must be dealt with soon, to ensure the smooth execution of their work. Potentially – depending on the MRP settings – this can be also a purchase order delivered directly to the subcontractor.

To proceed, firm the transfer order, locate the transfer order in the list Inventory management > Inbound orders > Transfer order list by looking at the target warehouse, contact the shipping carrier and organize a pick-up of the goods, then use Ship / Release to warehouse to initiate warehouse work for the reserved (!) material. Process the work at the mobile device: Outbound / Transfer pick. Check out my earlier blog how to call the mobile device emulator:

Once picked and ready to be loaded into the truck, the shipment appears in the list Warehouse management > Shipments > Shipments ready to ship. Print a packing list, confirm the shipment. The transfer order is now officially Shipped. Receive the transfer order for the whole quantity immediately, as this external warehouse is unmanaged. The plates for perforation are now at the warehouse EUS-104.

Someday, the plates come back, full of holes. They need to be received at the mobile scanner (Inbound / Purchase receive). The SSCC number typically exists and can be scanned, there can be an option to print an own label with the product ID and name. Next, the pallet is Put away to the main stock:

With a little customization, the purchase order may be updated with a delivery note by an automated batch for the whole registered quantity, yet this delivery note does not kick off any automatic action in production due to the wrong product type of M0070.
The production may be released now! Make sure the newly received subcontracted product has been reserved, then go for a Release. It creates warehouse work to pick the perforated plate and bring it to the assembly resource. At this moment, M0070 becomes reserved at the location level. Process the work at the mobile device: Production / Production pick

The perforated plate has been brought to the location 002 of the machine. From now on, the production order may be started, and a picking list for the ultimate material consumption may be posted in a vast number of ways. The material M0071 previously brought to the supplier is backflushed too:

Success!
Check out the 2nd part: Subcontracting via Production order.

Number of records in D365

Number of records in D365

In Dynamics AX2012 there used to be a development tool to quickly count the number of records in all DAX tables: Ctrl-Shift-W, then Tools / Number of records:
Number of records Ax2012

This can be an interesting figure for data migration, measurement of the transaction volume, performance evaluation etc. A similar inquiry in Dynamics 365 for Finance / SCM can be executed in a multitude of ways:

The new grid

At the moment of this publication the grid is still in a preview and slightly defunct, but you can add a grouping into any D365 list and it is going to draw the number of rows inside: right-click a column, say Group by this column and get a counter in the group header:
Count by group in the New grid
The calculation is slow as all records must be loaded from the server into the form data source first. On 10k+ records this method becomes slow to the grade of full impracticability.

Export to Excel

This method works faster than any Data management entity export: press Ctrl-Shift-M to select all records (including invisible / not loaded), then Office button / Export to excel. The success message already gives a clear indication of the total of all records exported: “We finished your export of 6265 rows. The full export took 1.6 minutes.
Export to Excel
This works a way faster, but not the fastest.

Workspace tile

On a screen of your choice, apply a query if needed, then use Options / Add to workspace, then ConfigureShow count on the tile, then check the destination workspace:
Tile counter
This works fast and even provides a drill-down capability, but not techy enough.


Get entity record count

Navigate to Common / Common / Office integration / Excel workbook designer. This little known cockpit let you make magic self-refreshing Excels you can give out to the users. The tailored Excel templates have pre-configured columns and a Microsoft Dynamics Office Add-in conditioned to the current environment. Now look for the entity of your interest and press the sleek button Get entity record count:
Get entity record count
This is a super fast, smart and satisfying method, handicapped by the fact, that not every table in the system is an entity, but it comes the closest to the good old Number of records list.

What Item requirements can’t do

What Item requirements can’t do

This is kind of a recurring question: people have illusions about the Item requirements sales order type in Dynamics 365 for Finance and SCM.

First of all, in connection with a Fixed-fee project in D365 you may only open an Item requirement sales order. In one of the D365 versions they shortly enabled the classic Sales order but then quickly closed the ‘exploit’ (“Sales Orders may not be created for project type Fixed-price“), because a “classic” delivery note (en-us: Picking list) does not produce project transactions; the sales order would forever remain in the status Delivered and would never impact the project revenue. A project Sales order is only available on T&M projects where it can be billed directly.

Project management and accounting/Item tasks/Item requirements

Item requirements form

Pros and contras

A project sales order of the Item requirement type cannot be updated with an ordinary Delivery note but the special “Project – Delivery note” only. Then it produces a cost transaction to drive the project revenue recognition. Once delivered, the line immediately becomes “Invoiced” as if the sales price was zero. The support of Warehouse management had been added some time ago, and the shipment knows exactly which type of the delivery note to trigger upon confirmation of the load. This is what can be considered ‘good’ about the sales order type.

The list of the Item requirement sales order disadvantages is much longer:

  1. One cannot confirm an Item requirement sales order, I seriously can’t comprehend the reason. Order confirmations are not supported, you cannot liaise the delivery to your customer in a structured way.
  2. The user interface differs radically from the normal sales order, which is not well received by users and business owners.
  3. One cannot activate the Direct delivery mode at the IR sales order line level. Instead, you use the classic marking and open a purchase order through the Create purchase order button. Then you have to manually update the purchase order, choosing the customer’s address from the global address book and propagating it to the lines.
  4. Subsequently, a PO delivery note cannot update the sales order unless you affirm the “Consume items for a project…” prompt on posting. This however requires a 1:1 relation between a PO and SO which is not always given if the MRP planning is used: one purchase order may cover both project and non-project demands, and won’t become a Project purchase order. In such a case, the IR sales order delivery note must be posted manually.
  5. Similarly, Intercompany order chains are not supported.
  6. In the Warehouse management module, item requirements should not be consolidated in a load with “classic” sales orders as they may not be on the same delivery note. This is a subtle, nasty trap: in standard D365, a delivery note is posted per load = truck, not per shipment = order. There is an attribute, a flavour of the load whether it’s a ‘project’ load or a ‘normal’ load. In a mix of different sales order types this flavour cannot be right of course (see \Classes\WHSSalesPackingSlipPost): either one shipment or another is going to be posted wrongly or throw an error. Post the 2 delivery notes separately from the sales order screen, neither the load nor the shipment Delivery note button is going to work.
  7. Item requirements do not support multiple funding sources, i.e. multiple billing customers or changes of the customer account in the project contract. And no, the latest feature Allow sales orders for projects with multiple funding sources does not apply to the fixed-price project, try it: “Item requirement may not be created for a project associated to a contract with multiple funding sources“.
    The validation is dumb stupid, the 100% allocation in the funding rules to one or another funding source doesn’t bring any relief. You make this mistake only once; you may still gain access to your IR sales order through the normal sales list page or the Item tasks/Sales orders button, but processing the delivery of this sales order poses a serious challenge (unless you use Warehouse management). And no, you can’t remove the 2nd funding source anymore: Catch-22. You better delete the sales order and start all over.

  8. Update 29.08.2022: The mode Allow sales orders for projects with multiple sources has been extended to fixed fee projects. In some July 2022 update (10.0.27 ?) they finalized the feature “Allow item requirements with multiple funding sources for Project Operations stocked/production-based scenarios“. Activate it, and the caption for the above parameter becomes SALES ORDERS AND ITEM REQUIREMENTS. Warning: activating the feature does not update existing sales order lines! A new field Invoice account at the item requirement lines remains empty, and it prevents you from updating the lines.

     

  9. For the migration of historical orders, there is a special entity “Project item requirements“, and it is weak. It works at the line level and creates one SO header per project, i.e. you have no control over the Sales ID. Most of the sales order header attributes – delivery reason, sales taker, sales responsible etc. – are not available.
  10. Last but not least, non-stockable services are not updated properly by the “Project – Delivery note” and such a line remains in the Delivered status forever, the sales order as a whole will never be “Invoiced”.
    Update 28.07.2021: the issue 9 will go away if you activate the feature Enable creation of item requirement for non-stocked items: “Enabling this and turning on the ‘Create item requirement’ parameter will create an item requirement when creating a PO with non-stocked items.”

What can we do?

Not much:

  • Live with it.
  • Complain about it, but Microsoft has been aware for a long time.
  • Re-enable “classic”project sales orders on Fixed fee projects and programmatically enforce the “Item requirement-style” delivery note on those sales orders. This is not an easy development, but feasible in D365.