How to set up two-bin ‘Purchase Kanban’ system in D365 for Supply Chain

Software version: D365 and all AX 2012 versions

Before the mothership AX2012 was enriched with the Lean module, we had the lean module from the eBECS company that contained Purchase Kanban functionality.

The Purchase Kanban card would circulate between my company and the supplier and when a Kanban gets “completed,” which is the moment my supplier delivered my Kanban quantity, the system would create a received Purchase Order instantly. This could only work if the Supplier could actually receive electronic Kanban cards and treat them as Purchase Orders. In eBECS “Lean manufacturing III” you could use “lean alerting” where the supplier received an email and a purchase schedule so there was some unique functionality for purchasing.

When the AX2012 Lean module was announced in 2011 in Redmond, WA, we heard that there was no Purchasing Kanban. We had manufacturing and withdrawal Kanbans only. This was a surprise. How could Purchasing Kanban be left out? But then we were told not to worry because we did not need special Kanbans for Purchasing. We were told to just use a withdrawal Kanban to trigger the creation of a regular PO.

I remembered this statement for 10 years and recently it became necessary to actually try this out, because a customer was asking for it! How do we set this up? To create a PO, we would need MRP with auto-firming. That part I knew, but for the rest, I had no idea.

I started with a withdrawal Kanban between two locations in the same warehouse, trying to avoid the introduction of a virtual warehouse. That did not work. We need a second warehouse from which we withdraw the Kanban quantity, “pulling” it to our normal warehouse where we consume it.

Kanban Purchase Setup details for D365

Kanban is about visual replenishment. I agreed with Microsoft during that presentation in 2011 that a pull signal to a supplier is really a Purchase Order. I don’t need to email the supplier a Kanban card.

Let’s think through the following situation. In my main warehouse, that is of course “nettable” for MRP, I do my transactions. I consume my purchased Kanban items in Production Orders like every other part number. At some point I want a replenishment, but that replenishment is not coming from MRP, but from a user who looks at an empty bin and scans the Kanban card number to trigger a replenishment, in this case a PO. How to make that work? I should NOT use MRP, but I need MRP to create my planned PO and auto-firm it. Hold on, the secret will be revealed soon. The key is Item coverage by warehouse.

1. The purchased item is set up as a normal standard cost item and the minimum order quantity = Kanban bin quantity

No other cost types are allowed.

MRP needs to be told to order the exact quantity that is in the Kanban bin.

2. Create a virtual warehouse called “Kanban” or similar.

Do NOT put a vendor ID in the vendor field. This will cause big problems when creating the lean production flow as the system thinks we are going to do subcontracting.

3. The item coverage will have two lines. One line for the main warehouse where we override the coverage group with the “Manual” coverage group, and one a “Requirement” coverage for a virtual Kanban warehouse where a special coverage group contains automatic firming. The vendor is entered on this second line.

I need to switch off MRP for the main warehouse. I want my POs to arrive in the virtual Kanban warehouse (with only one location). The planned POs should be auto-firmed.

4. I have to create two work cells where one supplies the other. Then I mention these two in my production flow.

No work will ever be done in these work cells. It is a little strange you have to do this, because all these work cells are good for is to define the two warehouses between which our withdrawal Kanban is operating. But it is designed this way. The withdrawal Kanban is using a “production flow,” but there is no production. The production flow contains one transfer activity.

5. Now I can create a Fixed withdrawal Kanban rule for my purchased item for two circulating Kanbans. Don’t forget to create the Kanban-jobs that go with the cards.

For those not totally familiar with the inner workings of the Kanbans in D365/AX2012, the Kanban card number is fixed and will keep circulating. That is the number you see and the number you scan.

The Kanban job is a one-time number used for accounting purposes that is temporarily connected to the Kanban card number.

When I scan “empty,” the Kanban card drops its Kanban job and gets a new Kanban job number. Because we just do transfers, there is no financial accounting going on, but the mechanism of a temporary marriage between card number and job number remains in place.

6. My Kanbans can start functioning.

I always need to do TWO scans: scan empty for my Kanban card # 1, then scan “complete” for my Kanban card # 2. Both scans are based on visual observation of the empty bin # 1 and the arriving full bin # 2.

7. I really need MRP to run continuously, as is going to be possible with the “planning optimization.” But the process will work with the traditional nightly MRP.

Having a traditional MRP run every night is not stopping the show, but of course we have a delay in the creation of the PO.

Process steps for the full Kanban cycle of a “Purchase Kanban”

1. Scan empty

This will decouple the Kanban card from the current Kanban job number and assign it a new Kanban job number.

2. New Kanban job created

This Kanban job actually creates the demand in the Net requirement screen for the Kanban warehouse.

3. New demand on the Kanban warehouse.

You will see the Kanban job number for the Kanban warehouse in Net Requirement screen. The regular warehouse will show a supply quantity with reference “Kanban.” That is the same job number you saw under the Kanban warehouse where it represents the demand.

4. MRP run

MRP will see the demand on the Kanban warehouse and respond with a planned PO for the minimum quantity we have setup in the Order defaults. This should be the Kanban bin size.

5. Planned Purchase order

The planned purchase order has the Kanban warehouse as the destination warehouse.

6. Purchase order

Automatic firming creates the Purchase order, with the Kanban warehouse as the destination warehouse. The location will also be filled in (which is unusual for a regular purchase order but there is nothing against it when items have fixed locations).

7. The purchase order is received

Inventory will sit in that one location of our virtual Kanban warehouse. But not for long. The inventory will be physically brought over immediately to the point of consumption in the main warehouse.

8. Complete withdrawal Kanban

The point of consumption personnel will see a full Kanban bin arrive with the accompanying Kanban card. In the system this card is still “empty”. They will scan this card number immediately and say “Complete”. The inventory is now moved from the Kanban warehouse to the location of consumption defined in the Kanban rule. The Kanban card now shows as “Full” or “Complete”.  Consumption can now begin (typically the consumption consists of issues to production orders).

REPEAT. GO TO STEP 1

In conclusion, let’s look at the typical picture of the Kanban transfer board screen and the Net requirement screen.

Here we see a typical snapshot of the situation of our 2-bin withdrawal Kanban. Card 34 is full and is currently being consumed.

Card 33 is empty and is causing a Demand signal in the Kanban warehouse as we speak.

As opposed to the Kanban process board, the Kanban transfer board does not show Kanban job numbers in the grid. Let’s fix that.

Now we see that the empty Kanban has Kanban job number 43. That is the number we should see in Net requirements.

And that is indeed what we see in the Net requirements screen for both warehouses. The transfer Kanban dependent demand, “Kanban line,” wants to pull 30 from our Kanban warehouse.

For the main warehouse we see this:

This is the future supply that our transfer (withdrawal) Kanban is delivering to the main warehouse.

Conclusion

This solution works perfectly when combined with a Supplier portal (or Supplier workspace) we have a robust solution that many customers can use. The buyer just needs to monitor the supplier response on the sent Purchase Orders.

It is very likely that many of the part numbers that are on a two-bin Kanban replenishment are floor stock items. That means we cannot use a solution where floor stock items are service items. This solution will not work for service items. This is not because Kanban rules would not accept service items. They do. But MRP is going to ignore service items. This solution is a great example of the “hybrid” solutions that the Lean module seems to encourage. No need for a separate “Purchase Kanban.” Use a Kanban trigger to create regular POs.

What about production?

Not surprisingly this same setup can be used to created normal production orders through a Kanban trigger. The coverage group would contain automatic firming and would probably go to status “Release” right away to make the order show up on the dispatch list (Edit job list) or on the Job Card terminal.

Have any questions on setting up a Kanban Purchase in D365 for Supply Chain? Please contact us at any time!