Skip to content

Dates Across Applications

Date fields appear in all applications under Side Widgets › Dates. Each record owns its own date values: they support planning, audit trails, supplier communication, compliance checks, and reporting. Understanding how those dates relate or do not relate to each other helps avoid surprises when a milestone moves, a deadline passes, or teams work from different screens.

Quick Check: Before You Start
  • Treat each application’s Dates widget as the source of truth for that record unless a documented automation copies values for you.
  • After changing a major milestone (for example In Store or ETD), decide whether linked records (style, shipment, colourways) need a manual review.
  • Review Site Settings for order documents, supplier edit rights, and colourway automation that expose or hide specific dates.

Separate dates per application

In general, editing dates on one record does not rewrite dates on another module’s record, even when the records are linked (for example an order and its style, or an order and a shipment). Teams align timelines through workflow and communication; the platform keeps separate fields so production orders, development styles, shipments, costings, and compliance items can each reflect their own context.

Read-only system dates (Created, Updated, and Completed where applicable) record when something happened in the system. They are not substitutes for milestone planning fields and usually should not be “fixed” by users—if they look wrong, the underlying save or status change is what needs investigation.

Style and Order

Style › Side Widgets › Dates holds development and delivery targets for the style library. Order › Side Widgets › Dates holds commitments for that production order. Those sets of fields are independent: an order may run earlier or later than the style card, or serve a different customer window.

Order › Style Details can synchronise selected style attributes into the order via style data synchronisation; that mechanism does not synchronise Dates side widgets. If style milestones change, update the order’s Dates if the production plan should follow.

When Site Settings › Order › General Settings › Colourway In Store Date is enabled, new colourways on an order can receive the order’s In Store date automatically at creation time. That is a one-time copy for new lines, not ongoing bi-directional sync between style and order.

Logistics and Fulfilment

Shipping › Dates tracks the shipment record’s departure, arrival, and delivery milestones. Those values sit on the shipment; they are not automatically kept identical to Order › Dates. When freight plans change, update both places if reports and partners should stay aligned.

On orders, editing ETD may offer to automatically update ETA and In Store when the order’s Origin has offset rules configured in Site Settings › Shipping › Origin. That automation applies within the order record only.

Compliance, Licensing, and Contracts

Compliance › Dates often includes Valid From and Valid To. Those define the certification window for that compliance record. When Valid To has passed, the compliance may be treated as expired for operational purposes even if the row still exists; renew or replace the record according to your process.

Site Settings › Order › General Settings › Component Compliance compares Order Created Date (and optional customer rules tied to ETD) against supplier/factory compliance validity. A compliance date change can therefore affect whether new or updated orders meet sharing and document rules, without changing any date on the order’s Dates widget.

License › Dates and licence fields on styles or orders support contractual timelines; they do not automatically push milestone dates into orders or styles.

Planner and Sales Order

Planner › Dates uses Valid From / Valid To for the planning record’s active window. That window is separate from style or order milestone fields unless your team copies dates manually.

Sales Order › Dates reflects the customer sales lifecycle. It does not replace Order › Dates for factory production timelines.

Costing, Component, Claim

Costing › Dates exposes lifecycle timestamps for the costing sheet (Created, Updated, Completed). They support audit and review of the cost build; they are not the same as order milestone dates on a linked order.

Component › Dates is limited to Created and Updated on the component master record. Material readiness deadlines usually appear on orders, styles, or critical path—not by editing component system timestamps.

Claim › Dates combines system timestamps with user deadlines such as Due. Claims may relate to an order operationally, but Due does not automatically track order ETD or In Store unless your process aligns them.

When dates change, pass, or conflict

Situation Typical implication
A milestone date is moved forward or back on one record Other applications’ widgets stay unchanged until someone updates them or an documented automation runs (for example ETD offsets on the order).
A deadline date has passed Filters, dashboards, and SLA-style reports may show the item as overdue; compliance Valid To may exclude the record from validation.
Order › In Store is wrong or in the past The platform may block past In Store values where restricted; an incorrect In Store can also interact with automatic completion after 180 days. Correct the date at source rather than only toggling status.
Completed status is set Completed date fields on order, claim, shipment, costing, or compliance typically update immediately and are system-managed.

Supplier visibility and editing

Application Reference

Troubleshooting

Why do Style dates and Order dates show different values?

They are separate fields on separate records. Style dates reflect product development targets; order dates reflect that order’s commitments. Align them manually when they should match. Order › Style Details synchronisation does not copy Dates widgets.

Steps to resolve:

  1. Decide which module should lead the planning change (usually the order once it is live).
  2. Update Order › Side Widgets › Dates to match the agreed plan.
  3. Optionally update Style › Side Widgets › Dates so the library reflects the same targets for future orders.
I fixed In Store but the order keeps going back to Completed. Why?

Orders can be marked Completed automatically 180 days after In Store. If In Store was wrong, the automation may still apply until the date is corrected and status is managed as described on Order › Dates.

Steps to resolve:

  1. Correct In Store on Order › Dates.
  2. Set status appropriately for your workflow (see Order › Status).
  3. If behaviour persists, confirm no other user is resetting status.
Does changing Compliance Valid To affect existing orders?

Component Compliance validation depends on whether compliance is valid for the order created date (and related rules). Narrowing Valid To can cause new sharing or document actions to fail until compliance is renewed or the supplier combination is valid again. It does not automatically clear dates on Order › Dates.

Shipment ETD does not match Order ETD. Is that a bug?

Not necessarily. Shipping › Dates and Order › Dates are independent. Update both when they should read the same for reporting.