Planning

This page covers the planning capabilities that help planners work with inventory and demand at a finer level of detail than the standard weekly forecast shape allows, especially for items that need short-term, higher-resolution planning such as fresh food.

1. Inventory Building — plan a temporary build of inventory ahead of a season, a shutdown or a campaign, and protect it from everyday demand until you choose to release it.
2. Inventory at Risk — find lot-tracked inventory that is about to become unusable, and stop planning counting it as inventory you can sell.
3. Derived Daily Forecast — take a weekly demand forecast and spread it across the trading week so short-term planning can work from a daily shape without reforecasting every day.

Inventory Building

Sometimes you need to build inventory ahead of time — cover for a shutdown, a pre-season build, inventory for a campaign — and the thing that makes it hard is not planning the build. It is stopping everyday demand from eating it before the day you actually need it.

Inventory Building lets a planner plan that build period by period, hold it back from ordinary demand until the moment it should be released, and give it back on a schedule they control.

Prerequisite

Inventory Building requires the Lanham Demand Planning app, the two virtual locations described under Setting up inventory building, and an active subscription for this app. Opening the batch list without an active subscription raises a notification, and releasing a batch raises an error.

How it works

The build is carried by a matched pair of transfer orders between your real location and a virtual Inventory Building Location:

Order	From	To	Carries
Outbound	Your real location	Inventory Building Location	Everything you build. Its lines are demand at the real location, which is what makes the planning engine build.
Inbound	Inventory Building Location	Your real location	Everything you consume. Its lines are supply at the real location, cancelling an equal part of the outbound demand.

The net of the two at any point is the quantity still being held back. Build 5,000 in each of three periods and consume 2,000 in the fourth, and 13,000 of demand is still standing that nothing else can touch.

This works for items with no forecast

Nothing about this reads or writes a forecast, a forecast adjustment or a demand forecast entry. The build is expressed as transfer demand, so it behaves identically for an item with a full statistical forecast and for an item that has never had one. It also means the size of a build is never limited by how much forecast there happens to be to consume against.

The generated orders never ship

The transfer orders exist only to hold inventory back. They are created at status Open and are never released and never posted, and three things keep it that way:

1. Release is refused outright. A transfer order carrying an inventory building batch name cannot be released. The error says why, and tells you that the way to remove the order is to unrelease its batch. Release is the gate warehouse receipts, warehouse shipments and posting all sit behind, so refusing it refuses all of them.
2. Neither virtual location carries posting setup, so even an order that somehow got past the first barrier has nowhere to post to.
3. Every inbound line is written with Planning Flexibility = None, so the Business Central planning worksheet does not propose to reschedule or cancel the generated supply. Without it, planners would see action messages they had to learn to ignore.

Setting up inventory building

1. Create two locations. Neither is a real place and neither should have posting setup:

   Location	Requirement
   Inventory Building Location	Must exist, must hold no posting setup, and must not carry Lanham procurement units.
   Virtual In-Transit Location	Must have Use As In-Transit ticked. This one is shared with Inventory at Risk — nothing is ever posted through it, so one serves both.

2. Name both on the Inventory Control tab of Advanced Forecasting Setup, in the Inventory Building Location and Virtual In-Transit Location fields.

3. Schedule the expiry process as a job queue entry (see Expiry).

Transfer routes are created for you

A transfer order cannot take lines unless its header carries an in-transit code, which means a transfer route has to exist. Rather than asking you to set up a route by hand for every location that might ever be built at, the app creates any route it needs — in both directions, using the in-transit location from setup — and only where no route already exists. An existing route is never modified.

Creating a batch

A batch is the planning, control and release unit. Search for Inventory Building Batches and create one:

Field	What it is for
Batch Name	The name planners know the batch by, for example FY27Build. It is the primary key, and it is written to External Document No. on the generated transfer orders.
Description	Why this build is being made.
Start Date, End Date	The date range the batch plans for. These decide which forecast periods the matrix has columns for, and the build is fully consumed by the end date.
Purchaser Code	The buyer responsible. Held on the batch rather than per line, because a batch is one plan with one owner even where several planners put lines into it.
Default Consumption Method	The consumption method new lines start with. It is copied onto the line when the line is created, so changing it later leaves lines already planned alone.

Several planners can maintain their own lines in the same open batch.

Planning the build

The batch page carries the batch above and a matrix of lines below — one row per item, variant and location, with a column per forecast period. Everything is edited in place; there is no separate line page to open.

Column	Notes
Location Code, Item No.	The first two columns, both mandatory. The location must be a real location, not the inventory building one.
Variant Code	Hidden by default. Show it if you plan by variant.
Consumption Method	How this line gives back whatever balance you do not consume by hand.
Active	Whether the line is included when the batch is released.
Total Build	The sum of everything the line builds. Drill down to see the periods behind it.
Total Consumption	The sum of everything the line gives back. Drill down to see the periods behind it.
Balance	The position at the end of the whole batch range, not just the periods on screen.

Type a positive quantity into a period to build, and a negative quantity to consume what you have built. Zero clears the period.

Period columns come from your configured Lanham forecast periods, limited to the batch date range. Twenty-six periods are on screen at a time — half a year of weekly periods — with Previous Set and Next Set to move through the rest of a range up to 52 periods long. Change either batch date and the columns rebuild immediately.

Balance is how you check your work before releasing

Because Balance is the position across the entire range rather than the visible columns, a line that closes properly reads zero there even when the closing periods are on a later column set. If Balance is zero, the line is finished.

Net and Accumulated views

The View toggle changes what the same cells mean:

View	Shows	Editable
Net	The movements you entered — and, once the batch is released, the generated consumption as read-only negatives.	Yes, while the batch is Open.
Accumulated	The running balance at the end of each period.	No.

View	P1	P2	P3	P4	P5	P6	P7	P8
Net	5,000	5,000	5,000	−2,000	−2,000	−3,667	−3,667	−3,666
Accumulated	5,000	10,000	15,000	13,000	11,000	7,333	3,666	0

The planner entered three build periods and two consumption periods. P6 to P8 are the automatic consumption of the 11,000 balance they did not consume by hand.

The accumulated balance can never be driven negative — inventory cannot be consumed before it is built.

Consumption methods

Every line has to end the batch range at a balance of zero, so that what was built becomes ordinary inventory once the window has passed. The Consumption Method on the line says how it gets there with whatever balance you have not consumed by hand:

Method	What happens at release
Manual	Nothing is generated. A line that still holds a balance stops the release, naming the item, location and shortfall.
Equal per Remaining Periods	The balance is spread evenly across the periods from the one after your last entry to the end of the batch range.
Period After Last Build	The whole balance is placed in the first period after your last entry.

Where your own entries already bring the balance to zero, nothing is generated whatever the method says.

Nothing is calculated while the batch is Open

The distribution runs at release and nowhere else. While a batch is open, the matrix shows only the movements you typed.

That is deliberate. If the balance were distributed as you typed, one entry would fill every remaining cell on the row and you could no longer tell your own plan from the system's. A released batch does show the generated consumption, because by then it is what the transfer orders carry.

Releasing a batch

Choose Release. The batch is validated, the consumption worked out, the transfer routes created where they are missing, and the orders generated — one outbound and one inbound per real location on the batch. The batch and its lines then lock for editing.

Releasing is refused when:

Check	Rule
Subscription	The app must be licensed.
Batch dates	Start and end date are required, and at least one configured forecast period must fall between them.
Setup	Both virtual locations must be set and must exist, and the in-transit location must have Use As In-Transit ticked.
Line	Item and location are required. The location must not be the inventory building location.
Duplicates	One line per item, variant and location within a batch.
Total Build	Must be greater than zero on an active line.
Balance	Must never be negative in any period.
Manual lines	A Manual line must already have a balance of zero.

Use Transfer Orders on the batch to see what a release produced, or the line-level Transfer Lines action to see what one line produced.

Unreleasing a batch

Choose Unrelease. Both of the batch's transfer orders are deleted in full and the batch reopens for editing. Nothing has been posted, so there is nothing to unwind, and no other batch is affected.

Expiry

A scheduled process closes batches whose range has passed. For each released batch whose current open period starts after its end date, both transfer orders are removed and the batch status is set to Completed.

Schedule it as an ordinary job queue entry on codeunit InvtBuildMgt_HDP_TSL. Daily is enough; the process copes with running late, and simply closes whatever is now past its end date.

Why both orders always go together

Neither order means anything without the other. The outbound order's demand is artificial — it represents inventory the business wants held back, not inventory anybody will ship — and the inbound order exists solely to cancel it again.

Leave the outbound order behind and you leave demand nobody will ever meet, and the planning engine goes on building against it. Leave the inbound order behind and you leave supply that will never arrive, and the planning engine stops building things it genuinely needs. So the two are created together and removed together, at release, at unrelease and at expiry alike.

Removing them at expiry is safe rather than disruptive: consumption has already brought the balance to zero within the batch range, so the two orders are equal in total and deleting the pair changes the net position by nothing. What you built is by then ordinary inventory, and the ordinary forecast and real demand consume it as they would any other — which was the point of building it.

Correcting a period that has already passed

Periods that have already finished stay editable, but entering into one asks you to confirm first. The case it exists for is a build that was planned for a period now past and never actually made — you have to be able to say so, rather than being told the period is closed.

Batch statuses

Status	Meaning
Open	Lines and quantities can be maintained. No transfer orders exist.
Released	Locked for editing. The transfer orders exist and are carrying the build.
Completed	The batch range has passed. The transfer orders have been removed and the batch is closed.

A batch can be renamed only while it is open — once released, its transfer orders carry the old name. Renaming an open batch carries its lines and quantities with it.

Audit

The batch records its release version, who released it and when, and when its transfer orders were last generated or removed. Those four fields sit under Show more on the General tab. The generated transfer orders are themselves a durable record of what each release produced.

Inventory Building permissions

Permission set	Covers
Inventory building (InvtBuild_HDP_TSL)	The batches, lines and period quantities, plus the transfer headers, transfer lines and transfer routes the release process creates and deletes.

Assign it to the planners who maintain batches, and to the account the expiry job queue entry runs under. An account that can only read transfer orders cannot release a batch.

Inventory at Risk

Lot-tracked inventory with a shelf life does not fail all at once. A lot moves quietly towards its expiry date, or is put on hold, or fails an inspection — and until somebody notices, planning is still counting it as inventory it can sell.

Inventory at Risk finds that inventory every night, shows it on one review page, and — where you let it — raises transfer demand that takes the quantity out of what planning treats as available, so the replacement gets planned before the shortfall arrives.

Prerequisite

Inventory at Risk requires the two virtual locations described under Setting up inventory at risk, and an active subscription for this app. Opening the review page without an active subscription raises a notification, and applying a line raises an error.

What it looks at

Lot-tracked inventory. The position comes from the open, positive item ledger entries of each lot, summed by item, lot and location — which is also the grain of a review line, and the expiry date shown on the line is the one those entries carry. Variants are not part of the grain: a lot is assessed and transferred whole. Reservations are not deducted: a reserved lot is still a lot that is going to expire.

Inventory sitting at no location at all, and inventory already at the at-risk location, are both left out. Neither could be transferred anywhere.

Rules

A rule decides what counts as at risk and what to suggest doing about it. Search for Inventory at Risk Rules. There is no card page: seeing the rules side by side is what makes their order readable.

Field	What it is for
Code	The rule's name.
Description	What the rule is for, in your own words.
Priority	The order rules are tried in. Lower numbers are tried first; rules sharing a priority are tried in code order.
Item Filter	Which items — and, through the item's Location Filter, which locations — the rule covers. Drill down to build it; see Choosing items and locations. Left blank, the rule is considered for every lot-tracked item at every location.
Days Until Expiry	How little shelf life a lot has to be down to before the rule identifies it. Zero switches the threshold off.
Lot Information Filter	A filter on Lot No. Information. Drill down to build it; see Filtering on lot information.
Suggested Write-off %	What share of the available lot quantity you expect to lose. The suggested at-risk quantity is the available quantity times this.
Suggestion Validity	A date formula, for example 7D. How long a suggestion this rule makes stands before it is reconsidered from scratch — see When a suggestion ends.
Auto-Implement	Apply the lines this rule finds automatically, without waiting for anybody.
Active	Include the rule in the nightly run.
Current Lines	How many of the review lines standing now this rule identified. Drill down to them.

A rule must identify inventory by the expiry threshold, the lot information filter, or both — a rule with neither cannot be activated. Where it carries both, a lot has to satisfy both, which is what lets you write "expiring within 30 days and failed inspection" as one rule. A rule also needs a Suggestion Validity; without one every suggestion it made would expire the day after it was made.

Both checks run at the head of every assessment as well as when Active is ticked, so a rule edited somewhere other than the page still fails loudly rather than quietly identifying nothing.

Rule precedence

Rules are tried in Priority order, lowest number first, with Code breaking a tie. The first rule that identifies an item, lot and location owns it and later rules leave it alone — rules are never combined, so a line always carries exactly one rule's write-off percentage and one rule's validity period.

Scope is whatever the rule's Item Filter says, so rules are free to overlap. That is what priority is for.

Order the rules deliberately

Because the first match wins, priority is how you say "inspection failures first, then the general 30-day check". Give the narrow rules the low numbers and leave any catch-all rule last: anything the narrow rules do not claim falls through to it.

A rule identifies inventory, it does not shut other rules out. Writing a rule for one item no longer stops a general rule being asked about that item — if you want an item exempt from a general rule, exclude it in that rule's item filter.

Choosing items and locations

Drill down on a rule's Item Filter to build a filter against Item. No., Item Category Code, Inventory Posting Group, the three Lanham Summary Codes and Location Filter are offered to start with, and you can add any other field on the item — including fields other extensions have added.

The item's Location Filter is what narrows the rule to particular locations: the rule then only looks at at-risk inventory held there. Leave it out and the rule covers every location.

Clearing every filter in the dialog leaves the rule with no item filter at all, which puts it back to covering every lot-tracked item.

Filtering on lot information

Drill down on a rule's Lot Information Filter to build a filter against Lot No. Information. Item No., Lot No., Blocked and Expired Inventory are offered to start with. It is built with a filter page rather than typed, because the fields worth filtering on often belong to other extensions — a site running quality management filters on its inspection status, and no fixed field list could have known about it.

A lot with no Lot No. Information record never matches a rule that carries a filter. That is deliberate: a filter on inspection status is a statement about lots somebody has inspected, and a lot nobody has recorded anything against has not been.

Clearing every filter in the dialog removes it again, leaving the expiry threshold as the only thing the rule looks at.

Choose Lot No. Information on a rule to see the lots it covers, with both its filters applied — the quickest way to check a filter says what you meant.

Setting up inventory at risk

1. Create the At-Risk Location. It is not a real place: it must hold no posting setup and must not carry Lanham procurement units. It must also be a different location from the Inventory Building Location — both hold inventory back, for different reasons, and one location carrying both would leave nobody able to tell which.

2. On the Inventory Control tab of Advanced Forecasting Setup, set:

   Field	What it is for
   Virtual In-Transit Location	The in-transit location the generated transfer routes use. This is the same one inventory building uses — nothing is ever posted through it, so one serves both. Must have Use As In-Transit ticked.
   At-Risk Location	The location created in step 1.
   At-Risk Shipment-Date Offset (Days)	How far out the generated demand is dated. One day is the usual setting; it puts the demand just far enough out that today's picking is not disturbed by it.

3. Write your rules.

4. Schedule the assessment as a job queue entry — see Nightly processing.

Transfer routes are created as they are needed, exactly as they are for inventory building.

Nightly processing

Schedule codeunit InvtRiskMgt_HDP_TSL as an ordinary recurring job queue entry. Advanced Forecasting Setup warns you if the locations are set up but nothing is scheduled to run the assessment, and creates that entry for you — on hold, recurring daily, retrying 10 times at 60-second intervals — for you to sequence and release.

Each run:

1. Deletes the transfer orders the previous run generated.
2. Reads the current lot position from the item ledger.
3. Decides what happens to each suggestion already standing — kept and remeasured, or removed.
4. Suggests afresh for any at-risk inventory nothing is standing for.
5. Applies every line flagged to apply whose rule has Auto-Implement.
6. Regenerates the transfer demand from every line that ends the run applied.

Every step is written to the Lanham Processing Log, so what last night did is readable from the same place as the rest of overnight processing.

You can run it on demand from the review page with Suggest Lines, which does exactly what the scheduled entry does. Run that way it shows a progress dialog naming the step it is on and the item it is working through, and finishes with a summary of what it found and created.

Nothing accumulates

The generated demand is always exactly the sum of what the applied review lines say. That is what lets a run delete every order it owns at the start of the night and rebuild them at the end without reconciling anything — and it is why an interrupted run, or a transfer line somebody edited by hand, is corrected by the next run rather than compounded.

What the run keeps, and what it recalculates

A line is a suggestion with a life. While it is inside its validity window the nightly run does not reassess it — the rule that owns it, its percentage, your adjustment and whether it is applied are all left exactly as they are. Re-deriving them every night would move the ground under a planner who has not finished thinking.

What the run does do to a surviving line is keep its measurements honest, because the inventory underneath it moves:

Left alone	Kept up to date
The rule, and the auto-implement and validity it brought	Available quantity, expiration date, days until expiry
The expected write-off percentage	The suggested quantity, recalculated from that percentage
The Apply flag, and an adjusted quantity	An unadjusted at-risk quantity, which follows the percentage down
Applied status and application method	An adjusted at-risk quantity, capped at what is still on hand

An applied line whose quantity or expiry date has moved goes back to Not Applied, and its share of the demand goes with it. The figures behind that demand no longer hold, and you are the one who decides what replaces it.

When a suggestion ends

Three things end a line. In every case it is removed, and the inventory behind it becomes ordinary at-risk inventory again, free to be suggested afresh in the same run:

Ending	What happened
Expired	Its Valid Until date has passed. The answer has gone stale and the inventory deserves a fresh look.
Inventory gone	The lot is no longer on hand at that location. There is nothing left to decide about.
Reason gone	Its own rule no longer identifies the lot — the inspection passed, the hold came off, the rule was deactivated or deleted.

Expiry starts the question again, not the answer

When a line expires it is genuinely gone. If the inventory is still at risk it comes straight back as a new suggestion, with a fresh window, its quantity re-seeded from the rule and its status back to Not Applied — which also means the Apply flag and any adjustment you made do not survive the expiry, and an applied line loses its demand until it is applied again. That is the point of the validity period: you are being asked afresh rather than looking at a decision from months ago. Where a rule carries Auto-Implement the re-suggested line is applied again in the same run, so the demand never actually lapses.

Choose each rule's period accordingly. A short one (7D) re-asks often and suits a rule worth acting on quickly; a long one (3M) leaves decisions standing and suits standing housekeeping. Because it lives on the rule, an urgent rule and a background one can keep different rhythms. It is read when the suggestion is made and stamped onto the line, so changing a rule affects the suggestions it makes from then on and leaves the windows already given alone.

The review page

Search for Inventory at Risk, or open it from the Demand Planner Role Centre. One line per item, lot and location:

Column	Notes
Expiration Date, Days Until Expiry	The expiry carried by the lot's open entries at that location. Shown in red once the lot has expired.
Available Quantity	On hand for that lot at that location, as at the last calculation.
Rule Code	The one rule that identified the inventory.
Expected Write-off %, Suggested Quantity	What the rule suggests. The percentage is editable — changing it recalculates the suggested and at-risk quantities.
At-Risk Quantity	What will actually become demand. Editable, and never more than the available quantity.
Auto-Implement	Whether the rule behind the line applies it without waiting for anybody.
Status, Application Method	Whether demand exists for the line, and whether it was raised automatically or by hand.
Valid Until	The last date this suggestion stands before it is reconsidered from scratch.
Apply	Your decision that this line is to raise demand.

Adjusted, Applied By, Applied At and Last Calculated At are there too, hidden until you show them.

Filter and sort it like any list — by item, category, location, expiry date, rule or status.

Applying lines

Flagging a line and committing to it are two separate steps, so deciding what ought to be held back does not create anything by itself.

1. Select the lines and choose Apply, or tick Apply on the line. Nothing is created yet. Lines whose rule carries Auto-Implement arrive already flagged.
2. Select the flagged lines and choose Create Demand. The transfer demand is created or updated, the lines are marked Applied with an application method of Manual, and the action is written to the Processing Log with your user name.

Lines in the selection that cannot have demand created — already applied, no at-risk quantity, or not flagged to apply — are counted and left alone rather than stopping the rest. Where nothing in the selection can be used, you are told so and nothing happens.

Change an applied line's At-Risk Quantity or its Expected Write-off %, or untick Apply, and the line drops back to Not Applied and its share of the demand is removed straight away. Choose Create Demand again to put the revised figure in place.

Leaving a line alone

A line you simply do not flag raises no transfer demand. Such a line:

• stays on the review page;
• is counted by the Inventory at Risk to Apply cue as still awaiting a decision;
• is still reassessed by every nightly run.

That is also how you undo: untick Apply on an applied line and its demand goes with it.

The generated orders never ship

One transfer order per source location, from the real location to the at-risk location, with one line per item carrying the whole of that item's at-risk quantity across every lot. The lots are not named on the line and no reservation is made against them — the demand exists to take the quantity out of what planning treats as available, and tying it to particular lots would stop the warehouse shipping those lots for anything else.

The orders are created at status Open and are never released and never posted:

1. Release is refused outright. A transfer order generated by inventory at risk cannot be released, which is also what keeps it deletable by the next run.
2. Neither virtual location carries posting setup.
3. Every line is written with Planning Flexibility = None, so the planning worksheet does not propose to reschedule or cancel demand nobody is ever going to act on.

Generated Transfer Orders on the review page shows them.

Planning cues

The Demand Planner Role Centre carries a Planning cue group:

Tile	Counts
Current Inventory Builds	Inventory building batches whose date range covers the work date — started, and not yet finished.
Inventory at Risk to Apply	Review lines still waiting for a decision: Not Applied, and not flagged to apply.
Inventory at Risk Applied	Review lines that have become transfer demand.

Choosing a tile opens exactly the lines it counted.

Logging

System actions — deletions, the line rebuild, automatic application, the orders created — and manual applications alike are written to the Lanham Processing Log. Ordinary record changes are covered by the standard Business Central Change Log. There is no separate at-risk history to maintain: the review page always shows the present position, and the Processing Log shows how it got there.

Inventory at Risk permissions

Inventory at Risk is covered by the app's own permission sets rather than one of its own:

Permission set	Covers
Basic (Basic_HDP_TSL)	Reading the rules and the review lines.
User (User_HDP_TSL)	Working the review page: changing lines, applying them, and running the assessment.
Admin (Admin_HDP_TSL)	Everything above, plus maintaining the rules.

Give User to the planners who work the review page, and to the account the nightly job queue entry runs under. The item, lot and ledger data the assessment reads, and the transfer headers, lines and routes it creates and deletes, come with the assessment codeunit itself.

Derived Daily Forecast

Why derive a daily forecast

A forecast period is usually a week or a month, and a demand forecast entry dated at the start of one tells Business Central planning that the whole period's demand exists on that day. Over a long horizon that is fine — nobody expects a forecast to know which Tuesday. Over the next fortnight it is not: a week's demand landing on Monday pulls supply in earlier than it is needed, and a planner working the planning worksheet sees a shape that does not match how the item actually sells.

Derived daily forecast is the answer where an item needs finer planning, such as fresh food, short-life products or other inventory with a trading pattern that changes day to day. It reads a weekly demand forecast and writes a second one that carries the same quantities spread across days, keeping the weekly view for longer-range planning but letting the planner work from a daily shape in the near term.

Weekly demand forecast  →  Derived daily forecast  →  Planning worksheet

The source forecast is never changed. It is only ever read.

What it derives from

Any Business Central demand forecast can be used. Most often that is the one written by Demand Forecast Publish, which carries the Lanham net forecast — including external forecast alignment — into Business Central. It works equally well on a demand forecast maintained by hand or loaded by another process.

Source entries do not have to be dated on a week boundary, and there can be more than one in a week. Each is added to the forecast week its date falls in, and the week's total is what gets spread. A source whose periods are monthly rather than weekly will still derive, but it will put a whole month's demand into whichever week the month starts in — derive from a weekly source.

How the forecast week is worked out

Week Start Day on the derived forecast sets the boundary. A week runs from that day to the day before the next one, and the week containing the work date is the current week.

Derivation covers the current forecast week in full, from its week start day: the days already gone carry their actual posted sales, and new allocation begins on the work date. It runs forward as far as Derivation Horizon — but it always finishes on a week boundary. A horizon of 6W from a Wednesday lands mid-week, so the week the horizon falls in is covered in full rather than left as a part week. A part week of derived demand would read to planning as a quiet week rather than as a week nobody has derived yet.

Entries outside that range are left alone. History before the current week stays as it was when planning last ran against it, and anything beyond the horizon written by an earlier run is not this run's to remove.

The current week

The current week is nearly always already partly spent, so the whole week's forecast is no longer the right number to spread forward. Derivation restates the week as what has actually sold plus what is still to come.

1. Take the week's forecast quantity.
2. For each day from the start of the week through the day before the work date, add up posted item ledger sales for the same item, variant and location. Quantities are signed, so a sale and a return on the same day net off against each other.
3. Write each of those days at its own net actual. A day that sold nothing gets no entry.
4. Deduct the week's posted sales from the week's forecast, floored at zero.
5. Spread what is left across the work date to the end of the week.
6. Settle those days against the sales quantity already behind them.

The elapsed days and the allocated days therefore add back to the weekly source quantity, unless sales have already overrun it. The week is not shrunk by what has already sold — it is restated as actual-so-far plus forecast-to-come, so the derived forecast still reconciles to the weekly one it came from.

Those elapsed days do not add demand to planning. Business Central's own forecast consumption reads posted item ledger sales for the same period and takes them off the forecast, so a day carrying its actual sales is cancelled by the very entries it was built from. They are there so the week reconciles, not to drive supply.

Set Exclude Forecast Before on the planning worksheet

Planning does not ignore forecast dated before its starting date — it looks back to the last forecast entry on or before it. Setting Exclude Forecast Before to the work date when you calculate the plan keeps the elapsed days out of the calculation entirely.

A run made on the first day of the week has no elapsed day to read, and spreads the whole week forward.

The whole current week is rebuilt each run

Because the elapsed days belong to the derivation, every run deletes and rewrites them along with the rest of the week.

Open sales orders are neither deducted nor copied. They set a floor instead — see Sales quantity below.

Sales quantity

Business Central nets a demand forecast against real demand only inside one forecast period, and a daily forecast makes every day its own period. A day carrying a 50-unit order against a 25-unit forecast share has its 25 fully consumed and still plans the order's 50 on top, so the week ends up planning more than the forecast said. Derivation heads that off by looking at what is already sold.

Sales quantity for a day is:

net posted sales + outstanding sales orders − outstanding return orders

Rule
Sales orders sit on their Shipment Date	That is where planning buckets the demand.
In the current week, anything shipping on or before the work date — including a blank shipment date — lands on the work date	The work date is where the rest of the week starts, and an order that has not shipped has not gone away.
Overdue Order Lookback caps how far back that reaches	Leave it blank and every unshipped order counts, however old. Set 4W and only the last four weeks of overdue orders are picked up — useful where old orders linger on the book rather than being cancelled. A line with no shipment date counts as the oldest there is, so a lookback leaves it out.
A future week takes each day on its own	Nothing carries between weeks.
Drop shipments, blanket orders and orders released from a blanket order are not counted	They are supplied direct or planned on their own account, so counting them here would cover the same demand twice.

Leave Overdue Order Lookback blank if you can

The recommended practice is to leave it empty and keep the sales order book honest instead — a true backlog, with shipment dates that reflect when the order will actually go. Then every unshipped order is covered and nothing is quietly dropped from the plan.

An order that is not going to be shipped must be cancelled or deleted, not left on the book. While it sits there it is demand as far as Business Central is concerned: planning covers it, and so does this process. No forecast setting can fix an order book that says the business owes customers goods it has no intention of sending.

The lookback is there for order books that carry orders nobody intends to ship. It stops those inflating the work date, but it does so by ignoring real demand, so treat it as a workaround while the book is put right rather than a setting to live with.

The week is then settled:

1. Each day gets its base share of the week, exactly as if nothing were known about sales.
2. A day whose sales quantity is above its share takes the sales quantity instead — known demand beats a forecast of it — and the excess comes off the rest of the week, which is re-shared by the original pattern. Re-sharing can push another day over its own reduced share, so it repeats until nothing moves.
3. If the week's sales quantity passes the week's forecast, every day simply takes its sales quantity and the week runs above the forecast. At that point the orders are the better number.

So the forecast is the ceiling on the week unless orders have already gone past it. That holds even when posted sales have used the week's forecast up: the days still to come carry what is on order for them, because an order is known demand and gets covered either way.

Reading the entries

Each allocated day is written as two entries rather than one net figure, so you can see the forecast and the correction separately. The matrix shows their total; drill down to see the parts.

Day	Entries	Day total
Wed	33 — Source 1,035, equally shared at 33.33333%. +17 — Raised by 17 to sales quantity 50.	50
Thu	33 — Source 1,035, equally shared at 33.33333%. −8 — Reduced by 8 to hold the week to the forecast. Sales quantity 0.	25
Fri	34 — Source 1,035, equally shared at 33.33333%. −9 — Reduced by 9 to hold the week to the forecast. Sales quantity 0.	25

The adjustments add up to zero whenever the forecast is holding the week, which makes it easy to check at a glance. Where sales quantity has overrun the forecast they add up to the overrun instead, and each day reads Set to sales quantity N, which the week's forecast no longer covers.

Sales quantity is a snapshot taken when the forecast was derived. By the time you read it back the orders will usually have moved on — the description records what it was at the time, not what it is now.

Daily patterns

Daily Forecast Setup holds the Monday-to-Sunday shape of a week, as seven percentages that add up to 100 when Enabled. Disabled patterns are ignored. Reach it from the Item Card, the Stockkeeping Unit Card, the Planning Worksheet, or from Demand Forecasts.

A pattern is keyed by item, variant and location, and a blank variant or location is a wildcard. The most specific match wins:

Looked for	Covers
Item + variant + location	That stockkeeping unit only.
Item + location	Every variant at that location.
Item + variant	That variant everywhere.
Item alone	The whole item.

So one row per item is usually enough, with an extra row only where a particular location or variant trades differently.

Where a pattern is defined it decides the allocation outright, including any share it puts on a Saturday or Sunday. A weekend share is taken as deliberate, and the location calendar does not override it. In the current week the shares of the days still to come are re-proportioned between themselves, so a week that is half gone still allocates all of what is left.

The base entry on each day records where its share came from:

The day	Reads
Driven by a pattern	Source 1,035, 20% configured, 22.22222% effective. In a part week the effective percentage is the configured share divided by the shares of the days still to come; in a future week the two are the same.
Split equally, with no pattern	Source 1,035, equally shared at 16.66667%.
A current week with posted sales already deducted	The same, with the deduction named: Source 1,035 less 50 sales, 20% configured, 22.22222% effective.
An elapsed day of the current week	Actual Sales

Any adjustment against sales quantity is written as a second entry — see Reading the entries.

Build from Sales History maintains the table, and does both jobs from one request page. Filter the items however you like, add a location filter and a date range, and tick what you want done:

Option
Create Missing Patterns	Adds a pattern for every item, variant and location combination that sold in the range and does not have one yet.
Regenerate Existing Patterns	Rebuilds the patterns in scope from the weekday shape of sales in the range. One with no sales in the range is left exactly as it was, rather than zeroed on the strength of a quiet six months.
Item filters	The item table's own filters — number, category, and the rest.
Location Filter	Which locations to work on. Blank covers every one.
From Date / To Date	The history to read. Ending on yesterday keeps a part-posted day out of the shape.
Include Variant Detail	On, and each variant that sold gets its own pattern. Off, and one pattern per item and location covers every variant. It only affects patterns being created.

Both switches start ticked, which is the usual run: bring in whatever is new and refresh the rest. A combination that already has a pattern is never created over the top of, so the report is safe to re-run.

New patterns arrive disabled

They are created with Enabled off, so nothing starts steering a forecast before somebody has looked at it. Review the shape, then turn it on.

Where there is no pattern

Most items never need one. With no pattern, the week is split equally across the working days in the location's base calendar — the location's own calendar where it has one, the company's otherwise. Where neither is set every day counts as a working day, because a site that keeps no calendar is saying it has no closed days rather than that it never opens.

Three things can leave nothing to spread across:

Situation	What happens
Nothing left in the current week because a pattern only sells on days already gone	The remainder goes on the work date. The pattern still says the week has demand, and the work date is the first day left to put it on.
Nothing left in the current week because the calendar is closed for the rest of it — a Saturday run against a weekday-only calendar	Nothing is allocated. A closed site is not forecast to sell. Anything already on order for those days is still covered.
A whole week with no working day in the location calendar	The whole week goes on the first day of the week, and a warning is written to the Lanham process log. The run finishes as Completed with Warnings.

Rounding

Daily quantities are whole units, for the same reason the publish run rounds up: Business Central plans in whole units far more often than a forecast is expressed in them. The week's quantity is rounded up first, then spread, and each day takes the difference between the running total rounded to that point and what has already been given out. That keeps small quantities spread across the week instead of piling onto one day, and the days always add back to the week exactly.

Everything the run writes is a whole unit — the elapsed-day actuals and the sales quantity a day is settled at, as well as the shares — so the arithmetic stays whole and the week reconciles exactly.

Setting up a derived forecast

1. Create a demand forecast name for this process alone.

   The derived demand forecast is rewritten in full

   Every run deletes and rebuilds everything under that name inside the derivation range. Anything else writing to the same name will be destroyed. Do not point this at a demand forecast anybody maintains by hand.

   A forecast that is already the target of Publish to Demand Forecast, or of Lanham's Save Stat. Forecast to Base BC Demand Forecast, is refused outright — the two would fight over the same entries.

2. On Demand Forecasts, set Derive From Forecast to the weekly forecast to read. It cannot be the derived forecast itself, and it cannot be another derived forecast — derive from the weekly figure both of them read.

3. Set Derivation Horizon, for example 6W. Long enough to cover the short-term planning window, and no longer: past that, a weekly forecast is the better shape to plan from.

4. Leave Overdue Order Lookback blank, and keep the order book clean instead. Only set it where old unshipped orders linger and nobody is going to tidy them — see the note under Sales quantity.

5. Set Week Start Day to the day your trading week starts on.

6. Set up any Daily Forecast Setup patterns you need. Items without one are spread across the location calendar's working days, which is the right answer for most of them.

7. Turn Derivation Enabled on. The setup is checked as you do, so a missing source, horizon or week start day is refused here rather than discovered on the first nightly run.

8. Point the planning worksheet at the derived forecast for short-term planning. The weekly one stays available for everything beyond the horizon.

Running it

Run Forecast Derivation on Demand Forecasts rebuilds the selected forecast and reports what it did. Three fields on the same page record the outcome:

Field	Shows
Last Derivation Run	When it last ran.
Last Derivation Status	Success, Completed with Warnings, Failed, or In Progress while a run is under way.
Last Derivation Error	The run summary, a count of the warnings, or the error that stopped it.

A run that fails leaves nothing behind. The whole rebuild is one transaction, so a failure rolls the forecast back to what it was rather than leaving half a forecast that looks finished. The status still records the attempt.

Running it twice over unchanged data produces exactly the same entries and never duplicates them.

Publishing its source through Demand Forecast Publish also runs derivation automatically, provided Derivation Enabled is on. Publication commits first, then each enabled direct dependant runs and commits separately. A failed target retains its previous forecast entries and records its failure; the source publication and successful sibling derivations stay committed.

Scheduling the derivation run

Schedule Forecast Derivation on Demand Forecasts creates the job queue entry and opens its card. It is created On Hold, recurring on all seven days, retrying up to 10 times with a 60-second wait between attempts — and it takes the job queue category code from your publish entry where one exists.

Field	Value
Object Type to Run	Codeunit
Object ID to Run	DerForcDispatch_HDP_TSL
Job Queue Category Code	The same category code the publish entry uses

It derives every demand forecast that has derivation enabled, each as its own transaction, so one misconfigured forecast does not stop the rest.

Order matters. Schedule it after whatever maintains the source forecast — the publish run, where that is the source. Sharing the job queue category code serialises them; sequence them by scheduled start time within it. Running out of order is not corrupting: it derives from a source one cycle stale, and the next run puts it right.

Because the shape of the week moves with the work date, with posted sales and open orders read afresh every time, this is a run to schedule daily rather than weekly.

Keep this independent schedule where forecasts must refresh between publications or their sources are maintained by another process. Automatic derivation after publishing refreshes only the enabled direct dependants of the forecast just published.

Limitations

• Derive from a weekly source. A monthly source derives without complaint but puts the month's demand into the week the month starts in.
• Sales quantity is a snapshot. Orders that arrive, change or ship after a run are not reflected until the next one, which is the main reason to run it daily.
• Small quantities spread thinly. A weekly forecast of three units across seven days produces three days with one unit each, not seven days with a fraction.
• Blanket order demand is not covered here. Business Central plans it in its own right, on top of the forecast.