Production Calendar Calculations: Working Days, Parallel Stages and Date Checks

A production day is not a fixed amount of time

A planner divides 1,200 garments by a daily output of 600 and writes “two days.” The arithmetic is correct. The finish date may still be wrong. One of those days could have only a morning shift, while the next day is closed.

A garment production calendar calculation must join three things: the work required, the hours available and the order in which stages can run. A date formula handles only part of that job. It cannot decide whether a finishing team can use the first sewing batch or must wait for the whole order.

The worked case below follows an order through sewing, handover and finishing. It uses actual dates but invented factory conditions. The working week, closure, rates and batch sizes are teaching assumptions. They are not legal working-hour rules, public-holiday claims or standard garment output rates.

The aim is a finish time that another planner can trace. That means showing why work crosses a lunch break, waits overnight or moves around a closed day. A coloured bar without those details can hide more than it explains.

Define the event before calculating its date

“Production complete” needs a precise meaning. It might mean the last garment leaves sewing, the last finishing batch is accepted or the order is packed for collection. Those events can fall on different days.

For this case, sewing completion means that all 1,200 garments have reached the stated sewing output point. Finishing completion means that all four batches have completed the defined finishing work. A separate handover step includes the agreed checks and movement between those stages.

Packing, final shipment inspection and transport are outside the numerical case. Their time must be added before using the result as a dispatch promise. The rates assume acceptable output under the stated conditions, with no unplanned repair loop.

Readiness is also an event. The material, people, machines and approved instructions must be usable when the first task starts. ApparelDiary's guide to measuring supplier lead time until stock is usable explains why a receipt date alone may not establish that point.

The GAO Schedule Assessment Guide, in its section on calendars, connects working times to resource and activity availability. It also warns against assigning every task to a default calendar. The source concerns projects; the same scheduling issue appears when factory stages work different hours.

Convert the quantity into work at each stage

Assume sewing can produce 100 accepted garments per working hour. The finishing resource can complete 150 garments per working hour. Both rates apply to this order and the resources assigned to it.

Sewing run time = 1,200 garments ÷ 100 garments per hour = 12 hours.

Finishing run time = 1,200 garments ÷ 150 garments per hour = 8 hours.

These are hours of work on separate resources. Adding them gives 20 processing hours across the two stages. It does not yet give the elapsed time from the first sewing start to the last finishing completion.

The example assumes setup is complete before the first operation starts. If setup remains, it needs its own place in the calendar. The team must also state whether a rate already includes normal losses. Applying another efficiency factor to an accepted-output rate could count the same loss twice.

A rate from a different style is not automatically valid. Material, methods, skills and equipment may change what the line can sustain. Use the relevant estimate and keep its basis beside the calculation. A precise timestamp cannot make a weak rate estimate reliable.

Give each resource its own usable hours

The order starts on Monday, 2 November 2026, at 09:00. Normal working slots in this example are 09:00–12:00 and 13:00–16:00, giving six hours per day. Saturday and Sunday are closed.

Sewing has planned training on Tuesday afternoon, so only its morning is available. Wednesday, 4 November, is an invented site closure for all three resources. Handover and finishing work the full normal Tuesday because they use different staff.

The resources have no other bookings during these slots. That assumption matters: a working day is not proof that a particular machine is free.

Microsoft's calendar guidance distinguishes regular working times from dated exceptions. It allows separate periods and hours, not just a single daily total. A factory spreadsheet should preserve that distinction too. Tuesday's training is a sewing exception, not a reason to close the entire site in every calculation.

Walk sewing through the calendar

On Monday, sewing works for six hours and makes 600 garments. Its first 300-piece batch is complete at 12:00. Lunch interrupts the calendar, so the next batch runs from 13:00 to 16:00.

Tuesday offers only three sewing hours. Another 300 garments are complete at 12:00, bringing the total to 900. The remaining 300 cannot be assigned to the afternoon because that capacity is already reserved for training.

Wednesday contributes no work. Sewing resumes on Thursday at 09:00 and finishes the last 300 garments at 12:00. The total remains twelve run hours: six on Monday, three on Tuesday and three on Thursday.

From Monday at 09:00 to Thursday at 12:00, 75 clock hours pass within the stated local-time basis. Only twelve are sewing run hours. Neither number replaces the other. One describes processing effort on the line; the other describes elapsed time across breaks, nights and the closure.

The original “two days” estimate assumed two complete six-hour workdays. Tuesday did not meet that assumption. The error came from applying a daily capacity to a day with fewer usable hours, not from dividing the quantity incorrectly.

Use whole-day spreadsheet functions for whole-day questions

Excel provides two useful functions with different jobs. WORKDAY.INTL moves forward or backward by working dates. NETWORKDAYS.INTL counts eligible dates between two endpoints.

For a simple date-only example, use a named range called Holidays containing the actual date value for 4 November 2026. The weekend mask 0000011 marks Saturday and Sunday as nonworking. Its seven positions run from Monday to Sunday; a one means closed.

Suppose a separate task needs three whole working dates, with Monday counted as its first day. This formula returns Thursday, 5 November:

=WORKDAY.INTL(DATE(2026,11,2)-1,3,"0000011",Holidays)

Subtracting one date from the start lets Monday become the first counted working date. Without that adjustment, moving three workdays after Monday gives Friday, 6 November: Tuesday, Thursday and Friday are the three dates counted.

The matching inclusive count is:

=NETWORKDAYS.INTL(DATE(2026,11,2),DATE(2026,11,5),"0000011",Holidays)

It returns three: Monday, Tuesday and Thursday. An eligible start date and end date can both count. A same-day check on that Monday returns one, which is useful when checking how a sheet treats its endpoints.

These examples use a positive whole-day duration. Zero-duration milestones need their own rule. Also, WORKDAY.INTL truncates its day offset to an integer; entering 2.5 does not create a half-shift finish time.

Use real date values rather than ambiguous text such as 03/11/2026. Displaying a month name makes review easier. Spreadsheet language settings may change function names or separators, so test the formula in the actual file before making it part of a shared planning sheet.

Do not turn every eligible date into a full shift

The date-only count above sees three working dates. Multiplying that count by six gives eighteen hours. Sewing actually has only fifteen available hours across those dates: six on Monday, three on Tuesday and six on Thursday.

That three-hour difference is large enough to change a finish time. Adding Tuesday to the holiday list would not solve it. That would remove the valid morning as well as the unavailable afternoon.

For partial shifts, calculate with time slots. Start at the first valid slot, use as much of it as the task needs and carry any balance into the next valid slot. Stop when the remaining work reaches zero.

The sewing walk-through follows that method. A more detailed sheet can keep one row per date and shift, with available minutes, assigned work and a remaining balance. Hours and minutes should use a clear unit throughout. A value of 1.5 hours means ninety minutes, not one hour and fifty minutes.

Keep open hours separate from hours already promised to other work. A row showing six open hours and two hours reserved for another order offers only four unbooked hours. Do not hide that reservation by lowering the whole week's output rate. Its position may matter: two booked hours in the morning can delay the first batch even when the day's total capacity appears sufficient.

The record should also say what must be available together. If a task requires a machine and its qualified operator, separate free periods do not combine into usable time. The plan needs a slot when both are available. Confirm the calendar for any other required support before treating the slot as firm.

Allow overlap only when an actual batch can move

Sewing and finishing do not have to wait for the whole order in this case. The approved route permits four separate batches of 300 garments. Each batch keeps its identity through the handover and finishing stages.

The handover needs thirty working minutes per batch. Its dedicated resource carries out the agreed checks and movement. Finishing then needs two working hours per batch, since 300 divided by 150 equals two.

The case assumes each batch passes those checks and is released as planned. Thirty minutes is an invented duration for this example, not a prescribed inspection method. If a batch is held, its release time changes and the finishing plan must change with it.

IFS's operation-overlap documentation describes how a later operation can begin before the earlier one has finished the whole quantity. It also accounts for the last transferred batch and different operation rates. The hand calculation here uses explicit batches and resource bookings; it does not claim to reproduce every rule in that software.

Overlap means that different resources work at the same time. It does not allow finishing to process garments that sewing has not yet made or that the handover has not released.

Follow the four batches through finishing

The first sewing batch is complete at noon on Monday. Handover cannot start during the stated lunch break. It runs from 13:00 to 13:30, then finishing runs from 13:30 to 15:30.

The second batch leaves sewing at 16:00 on Monday. That is the end of the working slot, not the start of another half-hour of capacity. Handover waits until Tuesday at 09:00 and finishes at 09:30. Finishing completes the batch at 11:30.

Tuesday's third batch is ready from sewing at noon. Handover starts at 13:00 and finishes at 13:30. Finishing then runs until 15:30. Sewing's afternoon training does not block this work because the resources are separate.

The final batch follows the same afternoon pattern on Thursday.

All dates refer to the week beginning 2 November 2026. Each resource handles one batch at a time. No row assumes two finishing batches can use the same capacity at once.

The order completes finishing on Thursday at 15:30, or 78.5 clock hours after sewing began. The sewing work is still twelve hours, finishing is still eight hours and handover is still two hours in total. The shorter elapsed route comes from overlap and the use of separate resources.

Compare that result with holding the whole lot

Now retain the same quantities, rates, calendars and four handovers, but prevent every handover until all sewing is complete. This gives a fair comparison with a whole-lot release rule.

All four batches become available for handover on Thursday at noon. The first handover runs from 13:00 to 13:30, and the first finishing batch completes at 15:30. The handler can prepare the other batches while finishing works because those are separate resources.

The second finishing batch uses the final half-hour on Thursday. Its remaining ninety minutes run on Friday from 09:00 to 10:30. Batch three finishes at 13:30 on Friday, after crossing the lunch break. Batch four finishes at 15:30.

The whole-lot rule therefore gives Friday at 15:30, compared with Thursday at 15:30 under batch release. That is 24 clock hours later in this example. It does not mean 24 labour hours were saved. Both versions still contain the same planned work.

Nor does it prove that a smaller batch is always better. More transfers can add handling and record work. Some processes have valid minimum loads or release rules. A proposed batch size must fit the physical route, quality controls and available people.

Distinguish parallel work from shared capacity

Two activities can overlap only if their dependencies and resources allow it. A handover may be logically ready but still wait for the only inspector, trolley or receiving space. A calendar that shows the day as open does not resolve that queue.

Microsoft's explanation of scheduling calendars separates project, task and resource calendars. It also notes that manually scheduled dates do not automatically follow every calendar change. This is a useful check when a displayed bar seems unchanged after an exception is entered.

For a manual factory plan, the next start is constrained by three events: the batch is released, the required resource is free and its next working slot is open. The latest of those conditions controls the start.

Independent preparation can follow a different rule. Two separate preparations that start together do not always add to the total waiting time. The next stage waits for whichever required preparation finishes last. If both tasks need the same person, however, treating them as parallel would overstate capacity.

Quality work can be another shared limit. ApparelDiary's guide to rework loops and inspection capacity explains why repair and repeat checks should not disappear inside an output target. Add those routes when they apply; do not conceal them by stretching a generic daily allowance.

Test a booking that changes the final batch

Suppose finishing has another confirmed job on Thursday from 13:30 to 14:00. All other case conditions remain unchanged. The last batch still completes handover at 13:30, but finishing cannot start it until 14:00. Two hours of work then take it to 16:00.

The half-hour booking has moved the whole order's finish by half an hour. An average daily capacity could miss this because the total finishing workload remains only eight hours. The conflict sits at the last batch's required slot, so spare capacity earlier in the week cannot serve those garments before they exist.

This is why the final transfer needs a separate check. Even a fast finishing stage must wait for the last sewing batch, its release and the next valid resource slot. Starting the first batch early does not remove those final dependencies.

Work back from a deadline using the same rules

A deadline check should use the same calendars and task boundaries as the forward plan. Subtracting a number of calendar days from a dispatch date can skip the very constraints that shaped the finish.

Suppose the fictional order must leave at 16:00 on Thursday. A finishing result of 15:30 leaves only thirty clock minutes. If a separate packing and release task needs forty-five working minutes, the current plan misses that requirement. There is a fifteen-minute shortfall even before any other unplanned delay.

The team must change a real condition: finish earlier, provide a valid separate work arrangement or agree a different deadline. Writing the dispatch date into the finish column does not create the missing time.

When planning backward, ask when the final required batch must be available for each task. Then check forward again from the actual start. If the two walks disagree, inspect the endpoints, breaks, release rules and resource bookings before changing the rates.

Use margin deliberately. A gap left for uncertainty should be visible and owned. Quietly adding spare days to every stage can hide where the real risk lies, while leaving no margin at all may turn a fragile forecast into an apparent promise.

Check the calendar before sharing the date

A useful review follows one batch from start to finish and then checks the totals. It should explain every pause and every period of overlap. In this case, the second batch is a good test: its Monday 16:00 sewing finish must not create an impossible Monday 16:30 handover.

Test a task that ends exactly at a break, one that starts on a closed date and one that spans a partial shift. Check an order that crosses the weekly closure as well. These small cases expose errors that a normal full-day example can miss.

Keep the calendar version with the plan. A new closure, a cancelled training session or a changed shift alters available time. Record actual completed quantities first, then recalculate the remaining work from its real status. Do not restart the full order duration after part of it has already finished.

At Tuesday noon in the base case, sewing has completed 900 garments and has 300 left. That balance needs three more run hours at the assumed rate. If the closure remains, those hours fall on Thursday morning. If Wednesday genuinely becomes available for all required resources, the remaining route can move forward. The changed calendar needs confirmation; deleting a closed-date entry is not evidence that people and equipment will be present.

Preserve the earlier result beside the new forecast so that a reviewer can see what changed. Use one stated local-time basis for the calculations. When work passes between sites in different time zones, convert the handover timestamps explicitly and retain each site's own working calendar. A date displayed without its time basis can make a transfer look possible when the receiving shift has already ended.

Finally, confirm the result with the people who own the resources. They should recognise their working slots, reservations and release conditions. A production calendar is useful when its dates can be explained in terms of work that the factory can actually perform.

References

• GAO: Schedule Assessment Guide, calendars and resource availability in Best Practice 4.

• Microsoft: WORKDAY.INTL syntax, weekend masks and whole-day offsets.

• Microsoft: NETWORKDAYS.INTL syntax and working-date counts.

• Microsoft: setting regular working days, hours and calendar exceptions.

• Microsoft: how project, task and resource calendars affect schedules.

• IFS Cloud 26R1: operation overlap and the last transferred batch.