Integrate APS with Dynamics 365 for SCM

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:

  1. After the nightly D365 MRP run, the above data is exported as .TXT files, representing the day’s snapshot.
  2. APS loads these files, refreshes its database, and performs a planning run.
  3. Operators may adjust the plan in APS the day after.
  4. The final plan, with updated order and route dates, is exported as a set of inbound .TXT files.
  5. 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:
 
  1. Unlock the production order if it’s locked.
  2. 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.
  3. 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.

D365 Petty cash review

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:

D365 Petty Cash Setup

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.

Cash Slip Journal

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 slipOrder 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.

Dissecting the Warehouse Management app layout

Dissecting the Warehouse Management app layout

The layout of the Dynamics 365 Warehouse Management app is managed by both the App code and the D365 SCM core to ensure a productive workflow. The app receives a state from the Dynamics 365 SCM core encapsulated in a “container,” comprising a list of controls to be presented on the current screen. These hints include the DisplayArea  assignment (the display area where controls that are awaiting input or confirmation are found, see Inspect details of active Warehouse Management mobile app sessions – Supply Chain Management | Dynamics 365 | Microsoft Learn) and the InstructionControl reference for item ID, quantity, location confirmations.

Typically, controls without default values are positioned in the Primary Input Area, awaiting user input through scanning or manual entry. In the above example, the next empty control is LP (license plate) i.e. the licence plate to pick the goods from. These controls which require a user input are presented one after another following the order of controls in the “container” or the explicit Display Priority, if provided by the programmer of the warehouse menu item UI. This is perceived by the user as a series of screens; internally, it remains the same screen.

To determine the DisplayArea, the D365 core employs heuristics. Controls with default values slide down to the Info and Secondary Input Area, except for confirmation fields like Confirm Location, which appear in the Primary Input Area despite seemingly having a default value. The initial value is still empty, but the InstructionControl let the warehouse app present a hint from a different field and display it in italic (here: BULK-010).

Upon assigning values to all controls, the screen is considered complete, triggering the button in the Primary Action Area.

Control placement on the Warehouse Management app screen can be influenced through the WHSMobileAppServiceDecoratorRule class family. For instance, a control with a non-empty default value can still be prompted in the primary input area, as demonstrated in the below code snippet:

				
					[SubscribesTo(classStr(WHSMobileAppServiceDecoratorRuleDefaultDisplayArea), staticDelegateStr(WHSMobileAppServiceDecoratorRuleDefaultDisplayArea, isTextInPrimaryInputAreaDelegate))]
public static void WHSMobileAppServiceDecorator_isTextInPrimaryInputAreaDelegate(boolean _enabled, Map _controlMap, str _data, WHSMenuItemName _menuItemName, EventHandlerResult _result)
{
   if (_enabled && _controlMap.lookup(#XMLControlName) == #MyControl)
   {
      _result.result(true);
   }
}
				
			
It is important to remove (to be exact, not to rebuild after the last user interaction) such a control from the screen once it receives its input, otherwise it will be prompted repeatedly in an infinite loop. The second example showcases a custom control with an InstructionControl reference for requesting confirmations while presenting a hint in italic:
				
					[ExtensionOf(classStr(WHSMobileAppServiceDecoratorRuleInstruction))]
final class WHSMobileAppServiceDecoratorRuleInstruction_Extension
{
    #WHSRF
    protected WHSMobileAppControlName getInstructionControlName(WHSMobileAppControlName _controlName)
    {
        WHSMobileAppControlName confirmationControl = _controlName;
        WHSMobileAppControlName masterControl;
        masterControl = next getInstructionControlName(confirmationControl);
        if (confirmationControl == #MyControl)
        {
            masterControl = #MyMasterControl;
        }
        return masterControl;
    }
}