Supplier Forecast Sharing: Versioned Time Buckets and Response Gaps

Issue one forecast version and retain one current response per bucket

Give the supplier one identifiable forecast version, split it into dated quantity buckets, mark which buckets require a response, and store each time-stamped supplier response beside the buyer forecast. Identify one response as current for the exact version and bucket while preserving earlier responses. When the item, unit, calendar, version or quantity does not align, create an owned exception rather than overwriting either side.

Oracle and SAP use commit in their product workflows. When that term appears here, it means only the supplier response quantity recorded in that planning workflow for a defined item and period. It is not a purchase order, capacity reservation, order acceptance, binding promise or conclusion about either party's legal rights. Use supplier response quantity in the portable record.

The minimum cycle is:

1. approve an internal forecast version for sharing;
2. issue the exact version with item, unit and bucket definitions;
3. capture receipt and a supplier response for each response-required bucket;
4. calculate quantity and timing gaps only after the keys reconcile;
5. assign gaps and missing evidence to an owner and due date;
6. resolve the planning decision before its next gate; and
7. preserve the cycle when a new version is issued.

This creates a shared planning record before purchase orders are due. It cannot prove that material, labour, equipment, production-line time, inspection or transport has been secured.

Define forecast, response and order before the first exchange

Use separate records for three different things:

• Buyer forecast: a dated estimate or scenario used to communicate possible future demand.
• Supplier response quantity: the quantity the supplier returned for the same forecast version, item, unit, location and time bucket, with its timestamp, reason and evidence state. It is a planning record, not proof of available capacity or future delivery.
• Purchase order: the buyer's controlled order document released through its own approval and acknowledgement process.

Do not let the spreadsheet layout erase those boundaries. A column labelled confirmed can be misread as an order or guaranteed supply. Prefer supplier response quantity, then define exactly what that status means in your operating process.

Oracle's current Supply Collaboration overview illustrates a product workflow in which suppliers review and respond to order forecasts, planners compare published forecasts and commits, and exceptions can identify forecast changes or a response below forecast. This supports a forecast-response-exception loop; it does not give every business the same legal meaning, deadline or escalation rule.

Begin with an internal forecast that has an owner and a controlled basis. The demand-forecasting guide for imported SKUs explains that upstream job. Supplier collaboration should not become a back door for sales, procurement or the factory to replace the approved demand baseline without a recorded version change.

Build the minimum forecast-sharing record

The following portable schema is OPL analysis. It can run in a controlled spreadsheet, supplier portal export or planning system.

Use one unit of measure for the comparison. If the buyer forecasts cartons and the supplier responds in units, store the approved conversion and original values. Do not let a formula produce a plausible but false gap from mismatched packs.

Keep notes attached to the item and bucket they explain. Oracle's current forecast and commit editing documentation includes notes in a plan/supplier/site/item context and supports day or week aggregation in downloads. That is a useful product example, not a universal file format.

Define horizon labels by required action and change control

The near and distant future do not need the same supplier response. Mark each bucket with one of two operational instructions:

• Response-required: return a quantity, reason and evidence state by the organisation-set due date.
• Visibility-only: use the quantity as planning context; no bucket-level response is requested in this cycle.

An organisation may add more zones, but each label must state what action is expected and what happens when the buyer changes it. Avoid calling a near-term bucket frozen unless the process defines who may revise it, how the change is approved and whether a fresh supplier response is required. Frozen is an internal change-control label here; it does not by itself make the quantity enforceable or reserve capacity. Likewise, open must not be read as unlimited flexibility, automatic supplier acceptance or permission to overwrite history.

Current SAP Business Network forecast documentation illustrates daily, weekly, monthly, quarterly and yearly time-series views and a configurable forecast-commit lock horizon that restricts editing inside that product. Use bucket size that matches the planning decision and available evidence. Do not copy a software default, treat a system edit lock as a commercial promise, or generalise another company's horizon.

For example, an importer might request weekly responses near an upcoming order decision while sharing monthly visibility further out. That is a process choice to document, not an industry standard. A distant visibility quantity can still help a supplier flag an obvious material or seasonal constraint without being treated as an order.

Preserve versions instead of overwriting the conversation

Every issued forecast needs a version ID and issue timestamp. When a quantity changes, preserve:

• prior forecast quantity;
• new forecast quantity;
• changed bucket;
• change reason and approving owner;
• issue date of the new version;
• prior supplier response;
• whether a new response is required; and
• link between superseded and current exchanges.

Oracle's current documentation states that, in its workflow, a forecast change creates a new version and clears commit values for changed buckets. Its export process can include current and previous forecast and commit measures. A spreadsheet does not need to mimic that software behaviour, but it should preserve the same decision distinction: a response to version 3 cannot silently answer a changed quantity in version 4.

Compare current with previous only after the supplier, site, item, unit, location, calendar and bucket keys match. Record the buyer-forecast change and supplier-response change as separate measures. A zero forecast change with a lower response is different from a buyer forecast increase followed by an unchanged old response.

Do not replace the old forecast and retain the old response on the same row. That creates a false match. Mark the prior row superseded, create the new version and request a fresh supplier response where your process requires one.

If an urgent change occurs inside a near-term zone, show it prominently and identify the buyer decision owner. The supplier's inability to match a late change is evidence for planning; it is not automatically proof of fault.

Use response states that show what happens next

States should communicate what is waiting on whom:

Avoid agreed, guaranteed, locked or confirmed capacity unless qualified evidence and the relevant commercial process support the exact statement. Within this article, a response can be received and reconciled without being converted into a contract or capacity reservation.

Open exceptions for gaps, missing evidence and changed assumptions

Calculate a quantity gap only after the keys match:

Response gap = supplier response quantity - buyer forecast quantity

A negative result shows the returned quantity is below the forecast for that bucket; zero means the quantities match; a positive result means the response is above the forecast. None of those values proves capacity, future delivery, supplier fault or a shortage. A blank response is missing data, not zero. The buyer forecast may have changed late, the unit or calendar may be wrong, the response may be partial, or the supplier may be waiting on materials, tooling, information or an internal decision.

Open a forecast-cycle exception when:

• a response-required bucket has no response by the organisation's defined due date;
• the response quantity or timing differs from the buyer forecast;
• the supplier and buyer use different item, unit, location or calendar keys;
• the buyer changes a bucket after the supplier responded;
• the response depends on missing evidence or an unresolved assumption;
• a supplier note identifies a possible material, process or scheduling constraint; or
• the response is attached to the wrong forecast version.

Give the exception a neutral trigger, owner, next action, due date, next decision gate and closure test. A useful reason code describes the evidence needed—such as material availability under review or unit conversion unresolved—without assigning blame.

If the response raises a real physical-capacity question, request the relevant line, shift, tooling, labour, material or allocation evidence through a qualified capacity-review process. Do not treat the forecast calendar as that audit.

Run a repeatable issue-response-review cycle

The cadence must reflect the SKU's decision horizon, forecast volatility, supplier planning cycle and next purchasing gate. There is no universal weekly or monthly rule.

Buyer issues a controlled forecast version

Before issue, the buyer should:

1. identify the approved source forecast and owner;
2. map buyer and supplier item codes and units;
3. select bucket sizes and label response-required versus visibility-only periods;
4. record prior-version changes;
5. state the response fields and organisation-owned due date; and
6. send the exact version through the controlled channel.

Receipt evidence can show that the file or portal record reached the intended workflow. It does not prove that every bucket is understood or accepted.

Supplier returns bucket-level quantities and reasons

Ask the supplier to return the original keys plus response quantity, timestamp, reason and evidence state. If one month contains a constraint in only one week, the chosen bucket size may be too coarse for the next decision. Refine the current issue without rewriting the historical exchange.

A blank cell is ambiguous. It might mean zero, unchanged, not reviewed, not applicable or missing. Require an explicit state rather than interpreting silence as a matching response.

Buyer reconciles gaps before the next decision gate

Compare buyer and supplier values bucket by bucket, then ask:

• Is the item, location, unit and version correct?
• Is the gap a quantity difference, a timing difference or both?
• What evidence supports the supplier's response?
• Did the buyer change demand after the prior response?
• Which decision—forecast, allocation, sourcing, order timing or capacity review—owns the next action?
• What evidence will close this forecast-cycle exception?

Review the production lead-time plan when bucket timing depends on evidenced manufacturing stages rather than a single unsupported finish date. If the internal demand basis changed, route it through the forecast accuracy and bias review as appropriate.

Worked example: three buckets need three different states

This example is hypothetical and does not represent an OPL customer, supplier or a recommended response horizon.

An importer issues forecast DF-240-R04 for SKU AU-K18, measured in individual units. The first three weekly buckets require responses; the fourth is visibility-only.

The 150-unit gap is 750 - 900 = -150 units. It does not prove a future shortage or supplier breach. The owner first reconciles the item, unit, week, calendar and version, then obtains the evidence behind material allocation noted. Depending on the result, the next action may belong to the demand forecast, product allocation, sourcing plan, capacity verification or future PO timing.

Suppose the buyer increases the 12 October forecast to 1,050 units in version R05. Preserve the R04 forecast and 750-unit response, mark that exchange superseded, and request an R05 response. Do not display the old 750 beside the new 1,050 as if the supplier had reviewed the change.

Move from forecast collaboration to a controlled PO

Forecast collaboration ends when the business is ready to make an order decision. Do not convert a forecast row into an assumed order.

Use the purchase-order release and supplier acknowledgement process to establish the approved item, specification, quantity, price, dates, revision and required response. The released PO—not the forecast calendar—becomes the controlled order baseline.

After release, quantity, price, date, revision or acknowledgement issues belong in the open purchase-order exception board. Keep the original forecast exchange linked as planning history, but do not let it replace the PO or its authorised amendments.

If the purchase order differs from the latest supplier forecast response, make the difference explicit before release. A planning response can inform the decision; it cannot approve the order on behalf of either party.

Launch with one supplier and one SKU family

Start with a bounded pilot:

1. choose one supplier and a manageable SKU family;
2. define forecast, response, PO and capacity-evidence terminology;
3. map buyer and supplier item codes, units and calendars;
4. select response-required and visibility-only buckets from your own decision horizon;
5. issue one approved forecast version;
6. require explicit response states and bucket-level quantities;
7. reconcile gaps and assign neutral exceptions;
8. preserve superseded versions; and
9. move actual order decisions through the controlled PO process.

The outcome is not a promise of supply. It is a decision-quality record: the buyer knows exactly what demand signal was shared, the supplier's latest response is attributable to the same version and bucket, and every material gap has an owner before the next purchasing gate.

Sources

• Oracle Supply Chain Collaboration 26B: Overview of Supply Collaboration
• Oracle Supply Planning 26A: Export Collaboration Order Forecasts
• Oracle Supply Chain Collaboration 26B: Edit Order Forecasts and Commits
• SAP Business Network: Forecast Template for Upload/Download, version 2605