When a review step opens, the record lands on the responsible person's task list. At the same time a due date is written. That date is calculated from the day count defined for the step. Duration is not a separate since-the-step-began counter; it is one due date. Before the task opens the date stays empty; the opening moment is posted to the record. The reviewer reads one date. The opening moment lands on step history. The checklist is written into the period agenda. The reference number does not change.
Day counts come from company settings. HSE defaults may be kept separate for technical decision, author revision, and manager revision. On a suggestion process, days are written from the procedure. There is no fixed universal duration; the system administrator changes the number. HR updates the setting when the procedure changes; dates on older open tasks are not rewritten automatically. The procedure text is tied to the settings screen. The dashboard total shows open and closed counts. On the first record the due date forms when the task opens.
Reminders follow the due date. The overdue badge looks at the same date. The duration label on the record file is the same. The three indicators do not run different rules. The portal inbox carries the reminder; an email body is not the decision archive. A web-based screen removes the signature-sheet chain. Notices look at the same source as the task list. The three indicators share one rule. Role decides the visible task row. The day count is not shortened while open load is high.
The task list separates pending and overdue work. A lengthening queue shows the step owner's load or a tight day count. A manager reads the list first, then discusses settings or delegation. A row without permission does not sit on the list. The module filter separates suggestion, kaizen, and HSE queues. Role does not open the wrong list. A manager writes delegation into the task note. Step history carries a time stamp. A person without permission cannot export overdue rows.
Reviewer checks are not shortened by time pressure. If benefit type, measure, or place line is missing, revision is written. Rationale stays required on an overdue task. Approval or rejection without rationale is not accepted. If an attachment exists it is read from the attachment area; a chat screenshot is not the source. A missing field is named in the reason. Time pressure does not cancel rationale. The branch filter keeps period comparison. Decision time is read beside the due date.
Common mistakes enter the period agenda. Treating the due date as a counter since the step began. Expecting the next date to extend automatically when the previous step is late; on each opening, duration is written from that step's days. Turning delay into a close without rationale. Keeping duration on a shared spreadsheet instead of the list. These mistakes are shown in training with a sample file. The training note shows mistakes with a sample file. An attachment binds to the record. The branch filter keeps period comparison.
On leave or role change, the open task moves to the new person. Older notes and past decisions are not deleted. The due date stays with the task for the new owner; duration is not rewritten from zero. A manager updates the date when needed. A delegation note leaves a trail on step history. In weeks with known leave, delegation is written in advance. Older decision rows are kept. A decision without rationale is not accepted.
When revision returns to the author, a new due date forms on the author step. The author completes the text and resubmits. In revision the text is corrected on the same file. The reviewer queue still carries an overdue badge if the author exceeds the time. Author training ties field guidance to this loop. Author overrun and reviewer delay are separated on the chain report. The chain report separates the two overruns. The menu hides a closed screen.
A rejection or approval decision closes the task. On a closed step the duration label ties to the decision time. Rejection without rationale is not accepted; even if time has run out, a reason is written. Being overdue does not justify a close without rationale. The decision sits on the portal file. The decision is not archived in an email body. The unit name is written in company language.
In a multi-step process each step carries its own due date. Delay on a previous step does not automatically extend the next step's date. On each opening, duration is written from that step's days. The chain report is read from step-by-step durations. Economic or implementation steps also carry their own day counts. The dashboard shows delay by step. Each step carries its own days. When a new step opens a new due date is written.
In the workflow wizard, decision exits are defined. The duration setting does not change how a decision moves to the next step. Duration tracks; routing is a schema rule. The two are not mixed. Responsible role is not left empty in the wizard; otherwise the task does not land. Approval goes to the next step, rejection to close, revision to the author. An exit is not left empty. The second check is that badge and file label show the same day.
Quality tracks average close time from the record table. Delay on a single record is seen from that file's step history. The period summary shows overdue task count on the unit row. A silent unit is zero records; it is read apart from the overdue row. The period meeting discusses overdue load first, then unit spread. A silent unit is read apart from overdue. Close time is tracked from the unit row.
HR aligns day counts with the procedure at setup. If separate HSE defaults are written, they are explained in training. Suggestion and kaizen may share the same schema; near miss as an HSE type may carry a separate duration. If a module is closed, that module's duration screen is hidden. When the day count changes, only newly opened tasks take the new value. The duration screen for a closed module is hidden. A branch manager sees only the local queue.
Company then branch selection also affects the task list filter. In a holding structure the wrong company drops the record into the wrong queue. A record with an empty branch breaks period comparison. Central quality lists all branch delays when permission allows; a branch manager sees the local queue. A row without permission does not enter export. The branch filter protects the queue. The chain row separates step-by-step durations.
Reward points do not stand in for the duration rule. If a rule exists, points post to the balance on approval. When a catalog request opens, points are held; they finalize on fulfillment and refund on refusal. An overdue review does not write points early; the step closes first. A notice does not write points. The balance does not go negative. Points do not stand in for the duration rule. The branch filter keeps period comparison.
An audit answers who decided what and when from step history. Due time and decision time sit side by side. An overdue column on a shared spreadsheet does not replace the source. Excel export carries the on-screen filter; a person without permission cannot export. Sample chain rows are added to the audit pack. An auditor reads the time stamp. An attachment binds to the record.
The demo portal may show a sample overdue badge; live production data is not in the sample. At go-live, day counts are written from the company procedure. Demo rows do not move into the period overdue report. At setup, unit, role, and step schema are completed first. Price and calendar are clarified on the contact form. The demo is not a live overdue report. A decision without rationale is not accepted.
Before changing the day count, the system administrator looks at open-task count. Shortening duration while open load is high inflates the queue. Delegation and owner spread are discussed first. Then the day count is posted into the procedure. Quality continues to track average close from the unit row. The training note announces the new day count to units. The menu hides a closed screen.
Author-revision overrun carries a badge apart from reviewer delay. The two badges on the same file belong to different steps. The chain report separates them row by row. The period summary shows both kinds by unit. An auditor compares due time with decision time. The unit name is written in company language.
In short: review duration is the due date written when the task opens. Reminder, badge, and file label look at the same day. Being overdue does not open a decision without rationale; list and report read the same date. In the chain each step carries its own days.