Fixed Kanbans in Dynamics 365 SCM with Warehouse Management

Fixed Kanbans in Dynamics 365 SCM with Warehouse Management

In a warehouse-managed environment, supplying production resources with small quantities of material is a common requirement. One possible solution is a Kanban flow, where the operator uses one container while the second container is replenished by the warehouse team. Once the first container is empty, it is returned to the replenishment cycle, ensuring that material is available at the resource without requiring the operator to create a warehouse request manually.

In Dynamics 365 Supply Chain Management, this process can be implemented using fixed Kanban rules in combination with Warehouse Management (WHS). The destination is defined by the activity in the production flow, whereas the source location in the main warehouse can be controlled by WHS location directives.

Configuration: Fixed Kanban Replenishment with WHS

Navigate to Production control > Setup > Lean production flow > Value streams and create a value stream for the material supply process. The value stream provides the organisational context for the production flow and its activities. After that create a generic logistic Production flow model.
Create the production flow with 1 transfer activity: Lean production flow > Production flows, associated with the value stream. Add a Version.
Under the Activities button, use Create new plan activity, where in the wizard you create the transfer activity: Activity type = Transfer. The work cells are irrelevant; mark both Update on hand on receipt and Update on hand on pick.
Choose the same “From” and “To” locations, namely the location of the resource: the activity represents the destination of the material flow. The actual source location can be determined separately by the WHS location directive.
Enter something into the time, finish creating the activity, but then enter the Details mode and enable Auto complete by put line! This setting allows the transfer activity to be completed automatically with the last put step on the mobile device in the warehouse.
Activate the flow version.
Create the fixed Kanban rule: navigate to Product information management > Lean manufacturing > Kanban rules and create a rule of type Withdrawal.
The same screw will be at more locations, potentially in containers of different sizes. Every Item-Location combination requires an own Kanban rule with a specific quantity.
Set Replenishment strategy = Fixed. Select the transfer activity created in the previous steps as the First plan activity. This automatically populates the Receipt location of the resource. Set Register as empty = Manual.
Specify the product and the Default quantity. This quantity defines how much material is requested when an empty container triggers replenishment i.e. the size of the box.
Set the Fixed kanban quantity = 2 for the two-container replenishment cycle, or 1 if the replenishment is fast enough for a one-container system.
At the bottom of the screen, you may pre-create the Kanban cards with the button + Add. Each becomes a unique barcode and a unique – and different from the barcode card number – Kanban number.
Configure warehouse work classes and the work template: under Warehouse management > Setup > Work, create the work classes required for Kanban picking and putting, then a work template for the Kanban picking work order type with the following sequence:
Under Warehouse management > Setup > Location directives, configure a directive for the Kanban picking work type. Use the directive query and actions to determine the source location from which the material is picked. This is where the actual warehouse source is controlled, independently of the destination defined in the production flow.
No separate put-away location directive nor a Kanban put away work template is required for this scenario because the destination is given by the transfer activity.
Under Warehouse management > Setup > Waves > Wave templates, configure the template used to process Kanban replenishment demand. Enable automatic wave creation and automatic release of work. Configure the remaining wave settings according to the intended processing flow.
Test the process: scan a Kanban card on the Transfer Kanban board (Production control > Kanban > Kanban board for transfer jobs) to make it empty.
The system creates the replenishment demand and processes the corresponding wave to generate warehouse work. The warehouse worker executes the picking and put operations, replenishing the container with the fixed quantity defined in the Kanban rule.
After the put operation, the material is available at the resource location, and Auto complete by put line allows the transfer activity to be completed through that process: the Kanban resets and becomes Completed automatically, awaiting the new cycle.

The fixed Kanban card cycle

To summarise:

An empty container triggers replenishment: when a container is empty, the operator scans its Kanban card on the transfer-job Kanban board in empty-container mode. This triggers the replenishment process for that card.
The system creates the replenishment demand: the Kanban is activated, and a Kanban wave is generated. Wave processing creates the warehouse work required to pick the fixed quantity and deliver it to the destination associated with the production-flow activity.
The warehouse replenishes the container: the warehouse worker executes the picking and put operations. The source location is determined by the WHS location directive, while the destination is defined by the production-flow activity. The quantity to be replenished comes from the fixed Kanban rule.
The replenished container returns to the resource: once the warehouse work is completed, the container is available for use at the resource. The other container can continue to supply material while this replenishment takes place.
The cycle repeats: when the next container becomes empty, its Kanban card triggers another replenishment cycle. The circulating cards allow the process to repeat without creating a new Kanban rule for each replenishment.

Fixed Kanban or Min/Max replenishment?

For this process, the fixed Kanban rule provides a direct connection between the production resource, the container and the replenishment quantity. The empty Kanban card is the trigger, and the Kanban rule determines the quantity to be replenished. The WHS module then generates and lets execute the warehouse work, including the determination of the source location. The machine operator is in control.

Min/Max replenishment addresses a slighty different requirement. It is a warehouse replenishment mechanism based on inventory thresholds by location (!), whereas the fixed Kanban process is driven by the consumption and replenishment cycle of a defined container. The Dynamics 365 system periodically controls the min/max levels and hopefully reacts on time, but only as well, as good the quantities in the BOM are, and as timely the workers record material consumption.

Production and Manufacturing blog series

Integrate APS with Dynamics 365 for SCM

APS means “Advanced Planning and Scheduling”. APS systems are used to optimize production processes by planning and scheduling manufacturing orders, taking into account factors like resource availability, machine capacity, and production deadlines. As a “better, smarter MRP”, APS helps companies improve efficiency, reduce lead times, and respond quickly to changes in sales or production orders.

In the German market, the 2 widely used programs are FELIOS from Inform-Software and HYDRA by MPDV. To be precise, their APS system is called FEDRA, with the HYDRA being a sister Manufacturing Execution System (MES). I had an occasion to integrate both with Dynamics 365 for SCM. By the way, a MES integration is something else and it already exists in Dynamics 365: Integrate with third-party manufacturing execution systems – Supply Chain Management | Dynamics 365 | Microsoft Learn.

High-level concept of the APS interface

An integrated APS uses data from the operations system, such as Dynamics 365 for SCM, including open sales, purchase, and production orders, current stock levels, and master data (BOMs, routes, resources, products and materials). All the data may be extracted from D365 with the standard or slightly modified entities.

The APS then generates an optimized production plan, often suggesting new raw material purchases and production orders, acting as a full-scale master planning system. However, we may neglect the planned order proposals and only import the updated production routes to align the ERP system with the APS. The process reduces to 5 steps:

After the nightly D365 MRP run, the above data is exported as .TXT files, representing the day’s snapshot.
APS loads these files, refreshes its database, and performs a planning run.
Operators may adjust the plan in APS the day after.
The final plan, with updated order and route dates, is exported as a set of inbound .TXT files.
The production route file is used to update production route operations in D365 via a custom entity, since the standard one may only write to Created production orders.

The production route entity at step “5” is teased in another blog: “Import a D365 FO entity with a virtual KEY field“. The entity should skip rescheduling if the operation dates in the file match those in Dynamics 365 and only touch route operation/jobs in the following statuses: Scheduled, Released, Started.

Key step: adopt the APS route schedule

Once the route is updated with the start, end dates and times (the FELIOS system only knows the date), the “jobs” and other internal structures in Dynamics 365 must be aligned with the updated operation times. The necessary actions triggered by each line = route operation in the APS file are:

Unlock the production order if it’s locked.
Re-schedule jobs associated with the route operation, using the dates and times imprinted upon the ProdRoute record. This will update capacity reservations according to the new dates. As a positive side effect, this will adjust the start and end dates of the production order if the operation is the first or last in the route. It will also update raw material demand dates and times on related BOM lines in the production order.
Lock the production order, protecting the scheduled route operation from further changes.

The below code snippet performs these key actions:

				
					    public void reschedule2jobs()
    {        
        ProdTable       prodTable = prodRoute.prodTable();
        ProdRouteJob    prodRouteJob;

        // 1. Unlock the order if locked
        if (prodTable.ProdLocked)
        {
            Args args = new Args(this);
            args.record(prodTable);
            ProdMultiLockForReschedule::construct(args).run();
        }

        // 2. Prepare a planning parameters set
        ProdParmScheduling  parm;
        parm.initParmDefault();
        parm.initFromProdParametersDim(prodTable.prodParametersDim());
        parm.CapLimited         = NoYes::No; // The APS system knows the capacity, resource, mat. availability better
        parm.MatLimited         = NoYes::No;
        parm.WrkCtrIdSched      = prodRoute.WrkCtrIdCost;

        // 3. Schedule the setup job, if any
        prodRouteJob = ProdRouteJob::findJobType(prodRoute.ProdId, prodRoute.OprNum, prodRoute.OprPriority, RouteJobType::Setup);
        if (prodRouteJob)
        {
            parm.initFromProdRouteJob(prodRouteJob);
            parm.SchedDirection = ProdSchedDirection::ForwardFromSchedDate;
            parm.SchedDate = prodRoute.FromDate;
            parm.SchedTime = prodRoute.FromTime;
            ProdUpdScheduling_Job::newParmBuffer(parm).run();
        }

        // 4. Schedule the process job
        prodRouteJob = ProdRouteJob::findJobType(prodRoute.ProdId, prodRoute.OprNum, prodRoute.OprPriority, RouteJobType::Process);
        if (prodRouteJob)
        {
            parm.initFromProdRouteJob(prodRouteJob);
            parm.SchedDirection = ProdSchedDirection::BackwardFromSchedDate;
            parm.SchedDate = prodRoute.ToDate;
            parm.SchedTime = prodRoute.ToTime;
            ProdUpdScheduling_Job::newParmBuffer(parm).run();
        }

        // 5. Lock the production order against any manual re-scheduling
        prodTable.reread();
        Args args = new Args(this);
        args.record(prodTable);
        ProdMultiLockForReschedule::construct(args).run();
    }

Remark: the highlighted line is used to change the work centre in the route operation. The APS system sends a new resource number, it is written directly into the route operation into the cost resource column. From there, the programme relays the changed resource number to the D365 planning core to reserve the capacity of the new work centre and de-reserve the capacity of the old.

Production and Manufacturing blog series

D365 Petty cash review

Today I take a chance to review a development of my younger self: the Petty cash add-on to the Bank and cash module. In central Europe, this “Petty cash” (de: Kasse, fr: caisse) often looks like the box shown above. Inside of it there is… well… some cash. I designed, programmed this add-on and even localized it for Ukraine back in 2002 mostly on my own in something that can be called a study. It has been there in the D365FO application core all these years, and in version 10.0.39 they finally released it worldwide.

Configuration

To activate this add-on, enable Petty cash in the Feature management first. There is also a license key (what used to be called a configuration key) Country/Regional specific feature / Multiple countries/regions / General ledger – extensions for Eastern European countries / Petty cash, it is normally activated by default. Ultimately, you must activate it in Cash and bank management parameters with a slider Enable petty cash.

The setup is well described here: (1) Petty Cash Accounting – Microsoft Dynamics 365 Finance | LinkedIn. In essence, you have to create a symbolic cash account, in a Cash posting profile attach a general ledger account to it (there is usually a 1:1 relationship), then select both in Cash and bank management parameters:

Then there is a balance check. In Eastern Europe the amount of cash you accumulate may not exceed a certain threshold. In Western Europe I know no such regulations but just common sense; some companies even used to stash money 5 years ago to escape the negative bank interest. In contrary, there is a EU-wide limit for cash transactions of 10 kEUR. This can be set as an Operations limit.

In addition, you must specify at least 2 number sequences for the cash slips (bons): reimbursement and disbursement. Finally, configure a GL Journal name of the Cash type. You are good to go.

Operation

Navigate to Cash and bank management > Petty cash > Slip journal, create a new journal header, and under Lines you may start registering cash operations.

For a sale, choose the cash account in debit and a revenue account in credit. Do not forget the VAT. Once you perform Documents approval / Approve of the line, it draws the next Cash reimbursement slip “Order number”. At this step, it is supposed to print this slip at once, but in Eastern Europe there are legal requirements to its form and content, while in Western Europe there are no such requirements and… no printout. 😊Actually we are talking about a “rudimentary invoice” (de: Kleinbetragsrechnung less than €400, fr: facture simplifiée < €150) with some goods/service description, an anonymous recipient and a VAT included. However, in this case a free text invoice is advised, or you may produce it outright at a retail POS, while field servicemen should use their CE mobile terminals.

Post the journal, and it is going to integrate the cash transactions into the GL.

To pay someone out in cash, the cash account is in credit and the expense account is in debit; again, do not forget the VAT. Use Documents approval / Approve first. Interestingly, the cash balance check (see Inquiries / Cash balance) is performed at the same time, and the balance is built of both posted and unposted slips. Again, it issues a new “Order” number for a Cash disbursement slip, and in an Eastern European country it is going to print it. Here it does not make much sense, since a handyman must issue his own slip / bon to testify that he/she has been paid in full, then we take this receipt and preserve it. One case when we need a printout of our own may be a cash advance to an employee.

Conclusion

Even though this add-on remains a monument to my abilities in software design 😉 I am coming to a conclusion that it is pretty useless in Western Europe. The same level of comfort may be achieved with a separate bank account or a simple GL account (see Balance control accounts). In 20 years D365 for Finance has moved upmarket, and with the minimum of 20 licenses it is hard to imagine a company whose main source of liquidity may be cash sales. The module may find some usage in construction industry to pay temporary workers, though.

Dynamics 365 for SCM