Update Production Schedule Settings

Beta
PUT/v1/operations/production-schedule-settings

This endpoint is idempotent. Learn more

Replaces the planning assumptions production schedules are solved against.

Settings are replaced wholesale rather than patched, because they are read as one coherent set: a horizon that no longer matches the frozen window, or a capacity headroom that no longer matches the shift pattern, would produce a plan nobody intended. Send the full set on every call — a value the request leaves out is never carried over from what was stored.

The set is validated together, so a frozen window longer than the horizon, a minimum changeover above the maximum, or an active cadence with no valid schedule expression is rejected as a whole.

Existing schedule versions are unaffected — each one records the assumptions it was solved under, so changing settings changes future plans only.

Permissions requiredValues:production_schedules:update
The role behind your API key or agent must grant every one of these permissions.
constraint_department_idoptional stringnullable

ID of the department that sets the pace of the factory, and the one campaigns are planned onto.

Every machine in the department is planned, and the work of downstream departments is derived from what those machines are scheduled to run. Sending null, or leaving the field out of a request that otherwise replaces the settings, both leave the account with no constraint department — and generation is refused until one is chosen again. Send null to clear.

planning_horizon_weeksinteger

How many weeks a generated plan covers.

frozen_weeksinteger

How many leading weeks of the horizon become a commitment when a version is published.

Cannot be longer than the planning horizon. Once a version is published, changing a campaign inside the frozen window requires a reason and is recorded against the plan.

week_start_dayinteger

Day a planning week starts, where 0 is Sunday.

demand_window_monthsinteger

Months of production history the solver measures run rates, changeover behavior and lead times from.

forecast_history_monthsinteger

Months of order history the demand baseline is drawn from.

forecast_monthsinteger

Months the forecast projects forward.

Only applies to the seasonal_ema basis. A projection of anything other than twelve months is scaled to an annual rate, so the plan always reasons about a year of demand.

demand_basisstringenumValues:trailing_12seasonal_ema

How the demand a plan is solved against is derived from history.

  • trailing_12: the last twelve complete months of orders, spread evenly across the coming year.
  • seasonal_ema: a seasonally adjusted, exponentially smoothed projection that weights recent months more heavily. Falls back to the trailing baseline for an item with no history.

Demand overrides are applied on top of whichever baseline is chosen.

forecast_znumber

Z-score used for the confidence interval around the seasonal demand forecast.

The plan is solved against the central forecast, so this widens or narrows that interval without changing what gets scheduled.

changeover_avg_minutesnumber

Typical changeover duration.

Changeover time is modelled as rising with the number of new inputs a product introduces, between the minimum and maximum below. The slope is calibrated from production history so the model reproduces this average across the transitions actually observed; set it to the changeover time the floor typically reports rather than to a worst case.

changeover_min_minutesnumber

Shortest plausible changeover, and the floor of the changeover model.

Cannot exceed the maximum.

changeover_max_minutesnumber

Longest plausible changeover, and the ceiling of the changeover model.

changeover_labor_ratenumber

Hourly labor rate charged to a changeover.

This should be a dedicated technician rate rather than an allocated production rate, because one person works a single machine through a changeover. The constraint department's own labor rate takes precedence when it has one, leaving this as the fallback.

holding_rate_pctnumber

Annual cost of holding stock, as a share of item value.

Weighed against the cost of a changeover when campaigns are sized: a higher rate favors shorter, more frequent runs.

service_level_znumber

Z-score for service level safety stock targets.

finish_lead_time_weeksnumber

Weeks between coming off the constraint and being sellable.

default_constraint_lead_time_weeksnumber

Weeks of lead time to assume at the constraint for an item with no measured history.

An item's own lead time, measured from production history, is used instead whenever one can be observed.

max_weeks_supplynumber

Ceiling on how far ahead any item is built.

An item is only rebuilt once its projected stock falls below the lower of its reorder point and this many weeks of demand, so a slow mover whose statistical reorder point covers months of demand is not topped up ahead of items that are actually short.

max_flow_depthinteger

How many steps down the production flow a constraint item is traced to the finished goods it becomes.

Demand, stock and lot conventions are pooled onto the constraint item from every finished good the trace reaches, so anything further down the flow than this contributes nothing to the plan. The limit is also what stops a routing that loops back on itself from being traced forever.

shifts_per_dayinteger

Shifts worked per day.

hours_per_shiftnumber

Hours in a shift.

work_days_per_weekinteger

Days worked per week.

weeks_per_yearinteger

Weeks worked per year.

capacity_headroom_pctnumber

Share of machine time a plan may fill.

Shifts, hours and work days give a machine's raw weekly hours; this trims them to what may actually be planned. The remainder absorbs changeovers, which are not scheduled as explicit blocks, so a value of 1 produces a plan that leaves no time to set anything up.

default_lot_unitsnumber

Units in a default production lot.

The last resort in the lot-size chain: a lot set on the item, on its product line, or on the finished goods an intermediate item becomes all take precedence.

default_customer_lead_time_daysinteger

Calendar days between an order being issued and it being due to ship.

The last resort in the ship-by chain: a lead time set on the customer, on its parent account, or on the customer's account group takes precedence. Zero commits the account to same-day shipping on every order that falls through to it, so this update replaces the whole settings object and omitting the field is not the same as leaving it alone.

ship_calendar_idoptional stringnullable

The operating calendar naming the days this account's plant tenders freight, and the one naming the days a customer's dock accepts it.

These are the account-wide fallbacks: an address or a customer with its own calendar overrides them, and an account with neither set falls back to a Monday-to-Friday week with no closures. Send null to clear.

receive_calendar_idoptional stringnullable

Send null to clear.

default_fulfillment_policystringenumValues:make_to_stockmake_to_order

How a SKU is produced when neither it nor its product line says.

  • make_to_stock: built to the forecast, holding a safety stock against its variability.
  • make_to_order: built only against orders already on the book, holding no buffer.
cadence_statusstringenumValues:activeinactive

Whether schedules are generated automatically on a recurring cadence.

While active, each due tick queues a new schedule version.

generation_cronoptional stringnullable

Standard cron expression driving the generation cadence.

Must be present and parse as a standard cron expression whenever the cadence is active, otherwise the whole update is rejected. Send null to clear.

generation_timezonestring

Timezone the cadence is interpreted in.

Decides when "every Wednesday at 6am" actually happens. A timezone the platform does not recognize falls back to UTC.

auto_publish_statusstringenumValues:activeinactive

Whether a version produced by the cadence is published automatically.

While active, a cadence run publishes as soon as it solves, committing its frozen weeks without anyone reviewing the plan. Otherwise the run leaves a draft for a planner to publish by hand. Versions generated on request are never published automatically.

objectstringenumValues:production_schedule_settings

Resource type identifier.

constraint_departmententitynullable

The department that sets the pace of the factory, and the one campaigns are planned onto.

Every machine in the department is planned, and the work of downstream departments is derived from what those machines are scheduled to run. A machine that must sit out is taken out through its own resource setting rather than by leaving it unselected. Generation is refused until a constraint department is chosen.

idstring

Unique identifier for the entity.

objectstringenumValues:entity

Resource type identifier.

typestringenumValues:accountactorentity

The resource kind that this entity references, as an object-type value (e.g. user, account).

Unlike object — which is always entity — this names the underlying resource the id points to.

namestringnullable

Human-readable display name for the entity (e.g. a user's full name, a sales order number).

handlestringnullable

Secondary human-readable identifier (e.g. email address, username, redacted API key value).

planning_horizon_weeksinteger

How many weeks a generated plan covers.

frozen_weeksinteger

How many leading weeks of the horizon become a commitment when a version is published.

Nothing is frozen while a version is still a draft. Once published, changing a campaign inside the frozen window requires a reason and is recorded against the plan. Cannot be longer than the planning horizon.

week_start_dayinteger

Day a planning week starts, where 0 is Sunday.

demand_window_monthsinteger

Months of production history the solver measures run rates, changeover behavior and lead times from.

forecast_history_monthsinteger

Months of order history the demand baseline is drawn from.

forecast_monthsinteger

Months the forecast projects forward.

Only applies to the seasonal_ema basis. A projection of anything other than twelve months is scaled to an annual rate, so the plan always reasons about a year of demand.

demand_basisstringenumValues:trailing_12seasonal_ema

How the demand a plan is solved against is derived from history.

  • trailing_12: the last twelve complete months of orders, spread evenly across the coming year.
  • seasonal_ema: a seasonally adjusted, exponentially smoothed projection that weights recent months more heavily. Falls back to the trailing baseline for an item with no history.

Demand overrides are applied on top of whichever baseline is chosen.

forecast_znumber

Z-score used for the confidence interval around the seasonal demand forecast.

The plan is solved against the central forecast, so this widens or narrows that interval without changing what gets scheduled.

changeover_avg_minutesnumber

Typical changeover duration.

Changeover time is modelled as rising with the number of new inputs a product introduces, between the minimum and maximum below. The slope is calibrated from production history so the model reproduces this average across the transitions actually observed, which is why the value belongs at the changeover time the floor typically reports rather than at a worst case.

changeover_min_minutesnumber

Shortest plausible changeover, and the floor of the changeover model.

changeover_max_minutesnumber

Longest plausible changeover, and the ceiling of the changeover model.

changeover_labor_ratenumber

Hourly labor rate charged to a changeover.

This is a dedicated technician rate rather than an allocated production rate, because one person works a single machine through a changeover. Together with the typical changeover duration it prices the setup cost that decides economic campaign sizes. The constraint department's own labor rate takes precedence when it has one, leaving this as the fallback.

holding_rate_pctnumber

Annual cost of holding stock, as a share of item value.

Weighed against the cost of a changeover when campaigns are sized: a higher rate favors shorter, more frequent runs.

service_level_znumber

Z-score behind the safety stock targets.

A higher value buys more cover against demand variability at both the constraint and the finished goods stage, at the cost of carrying more stock.

finish_lead_time_weeksnumber

Weeks between coming off the constraint and being sellable.

Added to the constraint's own lead time when reorder points are set, so a plan replenishes early enough for a decision made today to become sellable stock.

default_constraint_lead_time_weeksnumber

Weeks of lead time to assume at the constraint for an item with no measured history.

An item's own lead time, measured from production history, is used instead whenever one can be observed.

max_weeks_supplynumber

Ceiling on how far ahead any item is built.

An item is only rebuilt once its projected stock falls below the lower of its reorder point and this many weeks of demand, so a slow mover whose statistical reorder point covers months of demand is not topped up ahead of items that are actually short.

max_flow_depthinteger

How many steps down the production flow a constraint item is traced to the finished goods it becomes.

Demand, stock and lot conventions are pooled onto the constraint item from every finished good the trace reaches, so anything further down the flow than this contributes nothing to the plan. The limit is also what stops a routing that loops back on itself from being traced forever.

shifts_per_dayinteger

Shifts worked per day.

hours_per_shiftnumber

Hours in a shift.

work_days_per_weekinteger

Days worked per week.

weeks_per_yearinteger

Weeks worked per year.

capacity_headroom_pctnumber

Share of machine time a plan may fill.

Shifts, hours and work days give a machine's raw weekly hours; this trims them to what may actually be planned. The remainder absorbs changeovers, which are not scheduled as explicit blocks, so a value of 1 produces a plan that leaves no time to set anything up.

default_lot_unitsnumber

Units in a default production lot.

The last resort in the lot-size chain: a lot set on the item, on its product line, or on the finished goods an intermediate item becomes all take precedence.

default_customer_lead_time_daysinteger

Calendar days between an order being issued and it being due to ship.

The last resort in the ship-by chain: a lead time set on the customer, on its parent account, or on the customer's account group takes precedence. Zero means same-day shipping.

ship_calendar_idstringnullable

The account-wide operating calendars: the days the plant tenders freight, and the days a customer's dock accepts it.

Behind the per-address and per-customer links and ahead of a plain Monday-to-Friday week. Null on both means every ship-by date is resolved against weekdays alone.

receive_calendar_idstringnullable
default_fulfillment_policystringenumValues:make_to_stockmake_to_order

How a SKU is produced when neither it nor its product line says.

  • make_to_stock: built to the forecast, holding a safety stock against its variability.
  • make_to_order: built only against orders already on the book, holding no buffer.
cadence_statusstringenumValues:activeinactive

Whether schedules are generated automatically on a recurring cadence.

While active, each due tick queues a new schedule version; a generation cron expression is required for the cadence to be saved.

generation_cronstringnullable

Standard cron expression driving the generation cadence.

generation_timezonestring

Timezone the cadence is interpreted in.

Decides when "every Wednesday at 6am" actually happens. A timezone the platform does not recognize falls back to UTC.

auto_publish_statusstringenumValues:activeinactive

Whether a version produced by the cadence is published automatically.

While active, a cadence run publishes as soon as it solves, committing its frozen weeks without anyone reviewing the plan. Otherwise the run leaves a draft for a planner to publish by hand. Versions generated on request are never published automatically.

last_generated_atstring (date-time)nullable

When the cadence last fired.

Stamped when a run is queued rather than when the plan finishes solving, and the next due time is measured from it.

settings_statusstringenumValues:storeddefault

Whether the values returned were saved on the account or are the defaults applied when nothing has been saved.

created_atstring (date-time)

Creation timestamp.

updated_atstring (date-time)

Last updated timestamp.

Responses

200

Successful response for Update Production Schedule Settings