Durations

Lead time and duration are separate from pricing in Phasio. Even though duration is calculated inside the same equation as price, treat it as a distinct concept with its own logic, not as a side effect of pricing.

This page covers what is available today. Scheduling and resource-layer improvements, such as live per-station duration and calendars with public holidays, are on the roadmap and will be documented when they ship.

The two duration systems (and why only one matters)

Phasio has two places where a duration can be defined:

Model your entire workflow duration inside the process and post-process equations. Leave operation-level durations only as a fallback for methods that do not have a duration-aware equation yet.

• The process equation models the combined duration of all operations that make up a routing or method, such as Backlog -> Manufacturing -> Post-Manufacturing -> QC -> Prepare for Shipment.
• Each post-process equation models the operations for that post-process, such as machining, polishing, or dyeing.
• Together, the process and selected post-process equations represent the entire method's duration.

workflow.duration: the one link between the two systems

workflow.duration gives you the sum of hours across all operations involved, calculated from the static per-operation settings. Its useful role today is as a comparison: check whether your calculated dynamic duration is smaller or larger than workflow.duration, then react accordingly. For example, take the larger value as a safety floor.

This is the only link between operation-level settings and your equation. How you use the comparison is up to you.

See workflow.duration as a safety floor under Code examples.

How the dispatch date is calculated

For each requisition:

dispatch date = process duration + sum of selected post-process durations + lead time buffer

For an order with multiple requisitions, Phasio uses the requisition with the longest total duration.

Example: a quote becomes an order on August 15 with two days of process duration, one day of post-process duration, and one day of buffer. Its estimated dispatch date is August 19.

The buffer is a separate layer based on the lead time option the customer selects. Your duration calculation does not need to know about it unless you are implementing date-aware custom logic such as the advanced weekend example below.

See Do not double-apply the buffer under Code examples.

Weekends and non-working days (use with caution)

You can adjust a duration inside the process equation so an estimated Saturday or Sunday dispatch date rolls forward to Monday. Treat this as an advanced implementation:

• It runs only inside the process equation. A post-process duration is added afterward and can move the dispatch date back onto a weekend.
• The example uses the time at which the equation is evaluated. The estimate can therefore change when the quote is recalculated.
• The example covers weekends only. It does not include public holidays.

See Weekend rollover under Code examples.

Patterns for more advanced duration logic

These are starting points if you want to go beyond a simple static duration:

• Material-specific extra lead time. If a material must be ordered and is not kept in stock, add the extra days as a material variable and reference it in the equation.
• Machine-count aware duration for powder bed or batch processes. Calculate available builds against the machines you want to make available to the equation, not your total machine count. Some machines may be reserved, down for maintenance, or otherwise unavailable.
• Machine-speed aware duration for FDM and similar processes. Different materials print at meaningfully different speeds. Combine 2D or 3D nesting with the count of available machines and handling durations to estimate larger production runs.
• Customer-specific agreed lead time. Some customers have a negotiated fixed lead time regardless of what the equation would otherwise calculate. Handle this in one of two ways:
• One-off duration inside the shared equation. If only the duration or a few values differ, check customer?.organisationId in your normal equation and branch only the duration.
• A separate equation for that customer. If pricing, materials, workflow, and duration differ, duplicate the process equation for that customer from Customers -> [Customer] -> Pricing, or Manufacturing -> Process -> ... -> Duplicate -> Duplicate to a specific organization.

Code examples

Seven copy-paste patterns for the scenarios above.

workflow.duration as a safety floor

Problem: Your dynamic duration calculation should not undercut what the static operation setup implies.

Note: This is relevant only on Factory Floor. workflow.duration is not meaningful on other tiers.

// Use workflow.duration (static, from Settings -> Processes -> Operations)
// as a safety floor under your calculated dynamic duration.
const calculatedHours = variable('printTime', round(printTimeHours, 2))

// workflow.duration is the sum of the operation hours for this routing.
const floorHours = workflow.duration

// Never let the dynamic calculation undercut what the static setup implies.
const durationHours = Math.max(calculatedHours, floorHours)

done(unitPrice, durationHours)

Replace printTimeHours with the value your equation calculates. This is the main reason to read workflow.duration; avoid building unrelated logic around it.

Do not double-apply the buffer

Problem: It is tempting to add the lead time buffer inside your equation. Phasio already adds it automatically.

// The customer's selected lead time buffer is added automatically afterward
// when Phasio calculates the dispatch date.
const durationHours = processDurationHours

done(unitPrice, durationHours)

requisition.leadTime?.buffer returns the buffer in hours, but you only need to read it for custom date-aware logic such as the weekend-rollover pattern below. Never add it directly to your returned duration.

Weekend rollover (use with caution)

Problem: You want an estimated Saturday or Sunday dispatch date to roll onto the following Monday.

// Illustrative only. This covers weekends but not public holidays or time
// added after the process equation, such as a post-process duration.
const processDurationHours = 48
const bufferHours = requisition.leadTime?.buffer ?? 0

// Phasio also calculates estimated dispatch from the current evaluation time.
const calculatedAt = new Date()
const dispatchDate = new Date(
  calculatedAt.getTime() + (processDurationHours + bufferHours) * 60 * 60 * 1000
)

const dayOfWeek = dispatchDate.getUTCDay() // 0 = Sunday, 6 = Saturday
if (dayOfWeek === 6) dispatchDate.setUTCDate(dispatchDate.getUTCDate() + 2)
if (dayOfWeek === 0) dispatchDate.setUTCDate(dispatchDate.getUTCDate() + 1)

const adjustedTotalHours =
  (dispatchDate.getTime() - calculatedAt.getTime()) / (60 * 60 * 1000)

// Return only the process portion. Phasio adds bufferHours automatically.
const adjustedProcessHours = adjustedTotalHours - bufferHours

done(unitPrice, adjustedProcessHours)

If a customer adds a post-process with its own duration, that duration is added on top of adjustedProcessHours and can move the estimated date back onto a weekend. This pattern only adjusts the process equation.

Material-specific extra lead time

Problem: A material must be ordered and is not kept in stock.

// Material variable to create before saving:
//   extraLeadDays, for example 3 for ordered material and 0 for stocked material
const baseProcessHours = variable('printTime', round(printTimeHours, 2))
const extraLeadDays = specification.material.variables['extraLeadDays'] ?? 0

const durationHours = baseProcessHours + extraLeadDays * 24

done(unitPrice, durationHours)

Set extraLeadDays to 0 for materials you stock and to the expected procurement time for materials you order.

Machine-count aware batch duration

Problem: Powder bed and batch processes need to account for the machines realistically available, not the total fleet size.

const { quantity } = requisition

// Reserve capacity for rush orders, maintenance, or other customers.
const TOTAL_MACHINES = 10
const availableMachines = Math.max(
  1,
  Math.min(variable('Available machines', 6), TOTAL_MACHINES)
)

// partsPerBuild comes from your 2D or 3D packing calculation.
const buildsNeeded = Math.ceil(quantity / partsPerBuild)
const buildHoursEach = 18

// N machines run each round in parallel; rounds run in sequence.
const durationHours = Math.ceil(buildsNeeded / availableMachines) * buildHoursEach

done(unitPrice, durationHours)

Use the calculatePartsPerBuild helper from the pricing Cookbook's "Parts per build chamber" snippet to calculate partsPerBuild for your chamber.

FDM volumetric-flow duration

Problem: A flat per-material duration does not reflect that some materials print much slower than others.

// Material variable to create before saving:
//   volumetricFlowMm3s, for example 15 for PLA or 9 for ASA
const { material, volume } = specification
const volumetricFlow = material.variables['volumetricFlowMm3s']

const printTimeHours = variable(
  'printTime',
  round(volume / volumetricFlow / 3600, 2)
)

done(unitPrice, printTimeHours)

Slower-flowing materials such as ASA, PC, and nylon blends get a lower volumetricFlowMm3s, which increases the calculated duration without a separate per-material duration table.

Customer-specific agreed duration

Problem: A customer has a negotiated fixed duration while the rest of the shared equation remains unchanged.

const calculatedHours = variable('printTime', round(printTimeHours, 2))
const AGREED_CUSTOMER_ID = 1234
const AGREED_DURATION_HOURS = 5 * 24

const durationHours = customer?.organisationId === AGREED_CUSTOMER_ID
  ? AGREED_DURATION_HOURS
  : calculatedHours

done(unitPrice, durationHours)

Replace the example customer ID and duration with the agreed values. If more than a few values differ for that customer, use a separate customer-specific equation instead of adding many branches.

Using AI to build your duration logic

You do not need to explain every Phasio detail to an AI. Give it these boundaries and it can draft a reasonable duration calculation:

• The equation is TypeScript.
• An equation duration overrides static operation durations.
• The lead time buffer is applied automatically and must not be added again.
• workflow.duration is available on Factory Floor for comparison against the calculated value.
• Volumetric flow, available machine count, and material-specific add-ons are common ways to make duration more realistic.

Glossary