Pelico's Algorithms

Who is this for ?

What you will learn

Most numbers in Pelico are calculated, not stored. A coverage status, a suggested date, a projected stock level: each one is the result of a calculation on your plan.

This matters when a number surprises you. The question is not "is this a bug ?" It is "which calculation produced this, and what did it use ?" That question always has an answer.

💡One engine, not several. Pegging, stock projection and suggested actions all run on a single shared model of your plan. That is why they cannot disagree with each other: an order cannot be blocked in one view and feasible in another.

Pelico uses five algorithms.

The five algorithms are not separate. Each one feeds the next.

💡 This explains something you have probably seen. You change one purchase order date, and half your screen updates. You did not change one number. You changed an input to pegging. Pegging then re-ran the projection, which re-ran coverage, which re-ran the suggested dates.

What it does. Pegging links supply to demand. It connects each producing event to the consuming event that it serves.

Why it matters. It gives you the full chain above and below any event. This is how you trace a blocked work order back to its cause, and forward to the customer orders it puts at risk.

By default, Pelico allocates supply chronologically: first in, first out. Your environment can add allocation constraints or priority rules on top of this default.

💡This is worth knowing if you work in MRO. Moving a gate commitment date earlier can send a scarce part to a different service order. That works because priority rules sit above the FIFO default.

Events that provide material

Events that consume material

Work Orders, Service Orders and Stock Transfer Orders appear in both lists. They consume material and produce material.
​
​

Pegging links work in both directions and in any number.

When a need is met from stock on hand, there may be no upstream event attached to that quantity. Pelico tracks stock allocation separately.
​
​

Pegging links are dynamic. Pelico rebuilds them when:

Reading a pegging delay. A positive delay means the material arrives after the date it is needed. A delay of zero or less means it arrives on time or early.

💡Colour legend on the Pegging Availability Dates view. Green means the requirement is covered. Yellow means it is conditionally covered. Red means it is delayed or blocked. Grey means no relevant event is present in the period.

Coverage is not calculated against the date material arrives. It is calculated against the date material becomes usable. Pelico calls this the Availability Date, and it is the reference point behind every projection and every coverage status.

On the consuming side, each component of a work order has its own Consumption Date, the date that component is needed. Customer orders and sales forecasts remove stock at their Shipment Date.

💡 Processing Delay is the gap between a part arriving and being usable: internal transport, inspection, admin. It defaults to zero, so most of the time the Availability Date and the Delivery Date fall on the same day. When they differ, this is why.

You may see the same event carrying three different dates. They answer different questions.

What it does. Pelico takes your current stock for a part, then replays every event that touches that part in date order. Each event adds stock or removes stock. The result is a stock level for every future date.

Why it matters. You see a shortage before it happens. A part that runs out in week 7 is a problem you can still solve in week 3.

Pelico keeps two versions of the projection. Knowing which one you are reading matters.

Both start from the same stock on hand. Both process the same external supply: purchase orders, purchase order line schedules, incoming transfers, forecasts. Both apply the same consumption.

They differ on one point only: what they do with the output of a production order whose own components are short.

Which one to use. Use the Realistic Plan for real planning and for finding shortages. Use the optimistic version as a best case, to check whether the plan would work if the blocks were cleared.

💡Read the gap between them. A difference between the two lines is your warning about internal supply at risk. If Stock level stays positive but Conditional projection goes negative, that part is only covered if someone clears an upstream block. The gap tells you where to push.

⚠️ One behaviour looks strange at first. A blocked work order still uses its available components in the projection, but it does not produce its output. This is on purpose. The components are committed to that order. The output is not credible until the block is cleared.

💡One name, two labels. Realistic Plan is the official customer-facing term and the one used across this documentation. You will also see Conditional projection as the label inside the interface. Both describe the same projection. An older term, standard projected stock, is retired and should not appear in new material.

What it does. Coverage turns a part's stock trajectory into a status for each order. Pelico compares the Availability Dates of the supply pegged to an order against the dates that order needs its components. It checks every component, then gives the order the worst status among them. One missing component blocks the whole order.

In short:

💡 The practical difference between yellow, orange and red is what you should do about it. Yellow: chase the supply, the plan works if people follow it. Orange: the date is already lost, so escalate and replan rather than wait. Red: no on-time delivery from your current plan will fix it, so you need new supply or you need to reduce the need.

People confuse these often. They measure different things.

The two are independent. An order can be late but fully covered. It can be blocked but not yet late. It can be both.

⚠️A plant with many late orders and good coverage has a scheduling problem, not a material problem. The fix is different. If you confuse the two, your team chases suppliers when the real issue is releasing work on time.

What it does. When an order cannot start as planned, this algorithm finds the next date when it could. That is the date when the parts it needs will be in stock, based on their projected stock.

Why it matters. It turns a shortage into a date. Instead of "this order is blocked", you get "this order can start on the 14th". You can plan around a date, and you can tell your customer.

⚠️Two names, one number. The algorithm is called Next Enablement Date. Its result appears in the product as the Suggested Start Date column in the Work Order Book. If you compare the algorithm documentation with the interface, these are the same thing.

Your production capacity. There is no work centre capacity in this calculation. Capacity is handled by separate scheduling logic.

⚠️ This is the most important thing to know about the suggested date. It tells you when material and upstream work allow a start. It does not tell you whether you have the capacity to start. If the shop floor says the date is impossible, that is not a contradiction. Pelico was never asked that question.

⚠️ A suggested date does not guarantee a covered order. The calculation assumes that every sub-assembly involved is produced in an optimised way. Your real plan for those sub-assemblies may be different. If you move an order to its suggested date and it stays blocked, this is why.

What it does. Pelico compares your real production needs against your planned supplier deliveries. It then suggests moving a purchase order earlier (pull-in), later (push-out), or dropping it altogether (cancel) when no need remains in the horizon.

Why it matters. You gain twice. Pushing out a delivery you do not need yet lowers your stock and frees capacity at your supplier. Pulling in a delivery you need sooner closes a shortage without raising your overall stock.

Where you see it. These appear as directional arrow indicators: an arrow pointing left to pull in, right to push out, a cancel icon, and a check icon when the delivery is already on time. You will find them mainly in the Supply Purchase Order Book, on the supply events themselves.

⚠️These are not the lightbulb suggestions. The 💡 lightbulb is a separate feature carrying Stock Improvement Opportunities, which are ways to cover a need from stock you already own. Pull-in, push-out and cancel are about rescheduling supply events you have already ordered. Two different questions, two different indicators.

Suggestions come in two parallel sets, answering different horizons.

Because the two layers run in parallel, a single event can carry up to three suggestions at once. That is expected, not a duplicate.

💡Suggestions never point to a date in the past. If a pull-in would require a delivery that should already have happened, Pelico does not suggest it.

Separately from rescheduling supply, Pelico looks for ways to cover a need from stock that already exists somewhere in your organization. These are grouped under the 💡 lightbulb icon in the Line of Balance and on the Missing Parts page.

Selecting the lightbulb opens a tooltip listing every opportunity found, each with its own sub-icon and quantity.

💡All six live behind the same lightbulb. They do not each get their own icon on the row. Open the tooltip and read the sub-icons: rotables show a recycle symbol, stock transfers an exchange-box symbol, each with its quantity.

The one exception is Rotables, which can also appear as a standalone tag on its own, outside the lightbulb.

Use this table in reverse. Find what you are looking at, and see what calculated it.