Configuration Assistant
Lanham Demand Planning keeps its own copy of the settings it plans from. A procurement unit carries the lead time, the order minimum, the replenishment source and the division for one item at one location, and none of that is read from the item card at planning time — it is held on the procurement unit itself. That is what makes planning fast, and it is also what makes a large catalogue tedious to set up and easy to let drift.
The features on this page are the answer to that. Some derive Lanham configuration from the Business Central master data it should agree with, and keep the two in step as the master data moves. Others are one-off or scheduled maintenance jobs that correct settings in bulk rather than one record at a time.
Nothing here runs unless you turn it on or choose to run it. Each one imposes a rule about how your configuration should look, and a rule is only worth having where it genuinely matches how your business is organised. Where it does not, leave the feature off and set the field by hand — that remains entirely supported.
Division Codes from Item Categories
A division code on a procurement unit groups items for the people who buy them. At many sites it is set by hand, one procurement unit at a time, and drifts as new items arrive.
Where your item categories already line up with your divisions, this feature makes the item category the single place the division is decided. You map division codes onto item categories once, and every procurement unit takes its division from the category its item belongs to — when it is created, when its item moves category, and when the mapping itself changes.
This is not appropriate everywhere. It assumes that knowing an item's category is enough to know its division, and that nobody has a legitimate reason to set a division that disagrees with the category. If your divisions cut across categories — if the same category is bought by two different divisions depending on the location, say — do not turn this on. While it is on, the mapping wins, and a division set by hand against it is refused rather than quietly overwritten.
Turning it on
Set Default Division from Item Category in Inventory Management Setup. Nothing changes until you do, and turning it off returns the field to ordinary manual editing without undoing anything already set.
Mapping divisions onto categories
The Division Code field on the Item Categories page is where the mapping lives. A category with no division of its own does not mean no division — it inherits whatever its parent resolves to. So a division set on a parent covers everything beneath it, and only the exceptions need a value of their own.
That is usually the whole mapping in a handful of entries. Taking a supermarket's category structure as an example:
| Item Category | Parent | Division Code set here | Resolves to |
|---|---|---|---|
| FRESH | FRESH | FRESH | |
| BAKERY | FRESH | FRESH | |
| DAIRY | FRESH | FRESH | |
| DELI | FRESH | FRESH | |
| FRUIT-VEG | FRESH | FRESH | |
| MEAT | FRESH | FRESH | |
| SEAFOOD | FRESH | FRESH | |
| AMBIENT | GROCERY | GROCERY | |
| BAKING | AMBIENT | GROCERY | |
| BEVERAGES | AMBIENT | DRINKS | DRINKS |
| CANNED | AMBIENT | GROCERY | |
| CEREALS | AMBIENT | GROCERY | |
| CONFECTIONERY | AMBIENT | GROCERY | |
| PASTA-RICE | AMBIENT | GROCERY | |
| SNACKS | AMBIENT | GROCERY | |
| HOUSEHOLD | NONFOOD | NONFOOD | |
| CLEANING | HOUSEHOLD | NONFOOD | |
| PETCARE | HOUSEHOLD | NONFOOD | |
| TOILETRIES | HOUSEHOLD | NONFOOD |
Nineteen categories, four entries. Add a new chilled category under FRESH tomorrow and it is already mapped.
The chain is followed upwards until a division is found, however deep it goes. Only when the whole chain — the category, its parent, its parent's parent, all the way up — carries nothing at all does the item resolve to no division.
When the division is applied
| What happens | What the app does |
|---|---|
| A procurement unit is created, by Lanham or by any of this app's features | The division is stamped on as the record is written. There is no second update to wait for. |
| An item is moved to a different item category | That item's procurement units are brought into line straight away. |
| A category's Division Code is changed | Every procurement unit the change reaches is updated. You are told how many that is and asked to confirm before it happens. |
| A category's Parent Category is changed | The same, because moving a category changes what it inherits. |
| You want to apply the mapping to what is already there | Run Update Division Codes from Item Categories (see below). |
Clearing a category's own division code is a change like any other: the category goes back to inheriting from its parent, and that inherited value cascades. Categories that set a division of their own are left alone by a parent's change — BEVERAGES keeps DRINKS no matter what happens to AMBIENT.
A chain that resolves to nothing never clears a division that is already set. Blank is an absence of instruction, not an instruction to wipe.
The field is protected while this is on
If an item's category resolves to a division, that is the division its procurement units carry, and the field cannot be set to anything else. On the Procurement Unit Card it is shown but not editable; anywhere else the change is refused with a message naming the item category responsible.
This is deliberate. A division set by hand against the mapping would survive only until the next time the item, the category or the procurement unit was touched, and a setting that silently reverts is worse than one you cannot change. Where an item's category chain resolves to nothing, the field stays freely editable as it always was.
Applying the mapping to existing procurement units
Update Division Codes from Item Categories brings a population that predates the mapping into line. Filter it by location, item, variant or current division code, and it gives every procurement unit in the filter the division its category resolves to, reporting how many it read and how many it changed. A unit whose chain resolves to nothing is left as it is.
It is safe to run repeatedly — a second run immediately after a first changes nothing — and it can be left to the job queue if you would rather it ran than be remembered.
Delete Empty Vendor Buying Calendars
A vendor buying calendar that no procurement unit sits behind produces nothing. It still appears in the list, still has to be scrolled past, and still looks like a buying relationship somebody is maintaining. They accumulate wherever items are discontinued, locations stop stocking a range, or a vendor is replaced.
This rule removes them. A calendar counts as empty when its Procurement Units count is zero, and Lanham deletes the suggested order that belongs to it at the same time.
A calendar is matched to its procurement units on vendor, location and division together. A calendar carrying a division its procurement units do not carry therefore counts zero, and is treated as empty. If your divisions are not maintained consistently, correct that first — Division Codes from Item Categories is one way — and confirm the Procurement Units count reads what you expect before switching this on.
Nothing that is still in use can be lost to it. Lanham refuses to delete a buying calendar that has procurement units behind it, whatever asks, so the rule can only ever remove what is genuinely empty.
Turning it on
Set Delete Empty Vendor Buying Calendars in Inventory Management Setup, then schedule the run — see below. The setting alone does nothing; it is the scheduled run that acts on it.
Scheduling the configuration rules
The rules on this page that run on a schedule rather than as you work are run together, by one job queue entry, under the command CONFIGMGT. Everything this app adds in this area will run from that same command, so once the entry exists you do not need a new one each time a rule is added — you switch the rule on in Inventory Management Setup and the existing entry picks it up.
A job queue entry for the configuration rules alone
This is the one to create if you want the configuration housekeeping to run on its own schedule, separate from Lanham's overnight process.
| Field | Value |
|---|---|
| Object Type to Run | Codeunit |
| Object ID to Run | ConfigMgtDispatch_HDP_TSL |
| Job Queue Category Code | The same category code the Lanham overnight job uses |
| Recurring Job | Yes, on the days you want it to run |
Daily is more than enough. The rules are cheap when there is nothing to do and cope with running late, so there is no sequence to get right beyond the category code.
Entries that share a category code run one after another rather than at the same time. Giving this entry the category code Lanham's overnight job uses keeps it from running while procurement units are being created or rebuilt — which is exactly the moment the counts it reads would be mid-change.
Or add it to the Lanham overnight run
If you would rather it ran as part of the night rather than on its own schedule, add CONFIGMGT to the Parameter String of the existing Lanham job queue entry instead of creating a new one. Put it last, so the rules see the configuration as the night leaves it:
/DAILY/SUGORD/CONFIGMGT/
Do one or the other, not both.
What the run records
Every run writes a line to Lanham's Processing Log, naming each rule that did something and how much it did. A run where no rule is switched on says so rather than passing silently, so an entry that was scheduled and then forgotten about is visible rather than invisible.
Update Procurement Units from Items
Synchronises procurement unit settings from the item and stockkeeping unit records they were built from: the replenishment source type and code, the purchase unit of measure, frozen lead time days and their expiry date, order minimum and order multiple, average lead time, and safety stock days.
Each is a separate option on the request page, so you can correct one setting across the catalogue without disturbing the rest. Values can be taken from the stockkeeping unit where one exists rather than the item, and the run can be narrowed to a production item group. Order minimums and multiples are rounded to the unit of measure as they are set.
With Update Safety Stock Days selected, the report copies Safety Days (Lanham) from the item, or the SKU when Use SKU Values is selected, into the procurement unit's Safety Stock Days. This field is for Lanham only; Safety Lead Time is not used.
Update Procurement Units
Fills in a missing replenishment source. It finds procurement units whose replenishment source type is Vendor but whose source code is blank, and works out who the vendor is from purchase history — the most recent open purchase order for that item and location, falling back to the most recent posted receipt. Give it a start date to bound how far back it looks.
Useful after a migration, or wherever units were created before the buying relationship was established.
Create/Update Vendor Buying Calendars
Creates or updates Vendor Buying Calendar entries from procurement units in bulk, with an option to set a Frozen Review Cycle Days value across every matching record.
Periodic Setup Helper
Moves the Production Plan Locked Through date on location cards forward automatically, using a location filter and a date formula applied to the work date.
The point of it is the job queue. Schedule it on the day you want the lock to move — Fridays with a 2W formula, say — and the date maintains itself instead of relying on somebody remembering. Run it by hand and it does the same thing once.
Initial Item Ledger Entry Update
Backfills historical usage ledger entry date information for locations where advanced forecasting is enabled. Run once during initial setup, so that prior-year usage history is reflected correctly in the figures the forecast is built from.
Vendor Buying Calendar Hotfix
A background event subscriber that prevents null datetime errors when Vendor Buying Calendar records are modified, by ensuring Order Create Date and Order Creation End are always populated. There is nothing to configure — it corrects the values as the record is written.