Accounting checklist page (Workspace > Checklist)

Scope: accounting closing only (month-end and year-end). Not a general task or to-do tool: it lives under the accounting permissions, its categories are accounting closing areas, and later links go to accounting modules.

Status: plan only, nothing built. Source: “Mcom Groups, Summary of Check List.xlsx”.

1. The page is the spreadsheet’s table

Same layout, same columns, same grouping, now editable and logged:

No	Category	Description	Existing Standard Deadline	Performed Date

• Rows are grouped under lettered section headers exactly as in the file (“A General Closing”, “B Cash & Bank” … “S Finalisation & Approval”). Headers collapse.
• No, Category, Description, Standard Deadline are the template: read-only for staff, editable by a checklist manager.
• Performed Date is the working cell: pick a date to record it as performed; clear it to undo. “N/A” (the file uses it on Inventory rows) is a real choice with a reason, not typed text.
• Added to the table, kept quiet at the right edge so the sheet still reads the same: Performed by (filled automatically with who set the date), Remarks, and a small history icon per row.
• Above the table: company and period selector, search, section filter, “not done yet” filter, a progress line (e.g. 52 of 84), and Export to Excel in the original layout.

1a. Customizable: the list is not the same for every company or year

The 84 rows are a starting point (the Mcom default), not a fixed list. Different companies and years need different rows, so:

• Per-company template. Each company starts from the group default and can keep its own copy: add, remove, reorder and reword rows, add its own sections, change a row’s deadline text. The group default is edited by a group-level manager; a company’s copy by that company’s manager.
• Per-run tweaks. When a run starts (or while it is open) a manager can add a one-off row, hide a row that does not apply (with a reason, shown as N/A), or change that row’s deadline for this run only.
• Applies-when switch per company for conditional rows (“where applicable”: Inventory, payroll project allocation), so a company without stock never sees section H.
• Own deadline wording. Standard Deadline is editable text per row (and later a rule), so each company’s calendar can differ.
• Every customization is logged like any other edit (who, what, old and new, reason), and a past run keeps the rows it started with.

Accounting-only means the category list is a controlled set of closing areas (General Closing, Cash & Bank, Receivables, Payables, Accruals, Fixed Assets, MFRS 16, Inventory, Borrowings, Intercompany, Tax, Payroll, Provisions, Cut-off, Subsequent Events, Financial Statements, Management Review, Audit, Finalisation) that a manager can extend, not free-form tasks.

1b. Edit it like the spreadsheet (easy for accounting users)

Three things are editable, matching the picture you marked:

1. Column names and columns. The five columns (No, Category, Description, Standard Deadline, Performed Date) are the default set. A manager can rename any column header (“Standard Deadline” to “Due”), hide one, reorder them, and add their own columns, each with a type: text, date, number, pick-list (e.g. Status: Pending / Done), person, tick box, or file. Examples a company might add: Prepared by, Reviewed by, Working paper ref, Amount, Remarks.
2. Sections (yellow: “A General Closing”). Add a section, rename it, change its letter, reorder by drag, delete an empty one (a section with rows is hidden or merged, never lost).
3. Rows (red box). Edit any cell in place by clicking it. Add a row at the end of a section or insert above or below any row (“+” on hover); duplicate, drag to reorder, delete (soft: it stays in history). Numbers renumber automatically, so the duplicate “58” in the file cannot happen again.

Ease of use rules: click a cell to edit, Enter saves and moves down, Tab moves right, paste a block of rows straight from Excel, undo for the last edit, and a “+ Add row” button always visible at the end of each section. Staff who only tick Performed Date never see the editing controls; an “Edit layout” switch shows them to managers only.

Scalable data shape: the page is driven by data, not fixed fields.

• checklist_column (per template): key, label, type, options, position, visible, built_in (the five defaults cannot be deleted, only renamed or hidden, so exports and the Performed Date logic keep working).
• checklist_section (per template): code, title, position.
• checklist_item cells: built-in values in real columns (number, description, performed date); custom columns in a jsonb cells map keyed by column key. A new column is a row in checklist_column, never a migration.
• Every layout or cell edit writes a checklist_event (kinds added: column_added, column_renamed, column_removed, section_added, section_renamed, row_added, row_edited, row_removed, row_moved) with old and new value.

2. Data

Table	Holds
checklist_template (group default, or company-owned copy via org_id), checklist_template_item	The 84 rows: section letter and name, number, category, description, deadline_text (original wording), position. Versioned: an edit makes a new version.
checklist_run	One template version for one company and one period (e.g. FY ending 30 Jun 2026).
checklist_run_item	One row per template row, copied at run start (rows can also be added, hidden or reworded for this run: origin = template / added, hidden, deadline_text override): performed_on (date or null), performed_by, not_applicable + reason, remarks.
checklist_event	Append-only history, section 3.

Scalability: a new company or year is a new run, so the group’s companies each keep their own filled table. The template can be edited (new version) without touching past runs. A different checklist (monthly close) is another template with the same page. Sections and rows are data, so adding “T” needs no code.

Deadlines stay as the original text in this first version, shown exactly as in the file. Optional later step: turn the text into a computed due date (rules such as “day N”, “weeks A to B”, “before audit”) so overdue rows can be flagged; kept out of phase 1 because the wording is free text.

Import: the 84 rows load once from the xlsx. Known issue to fix on import: item number 58 appears twice (Provisions/Impairment and Cut-off), so numbers are assigned by position.

3. Activity log (who changed what)

Every edit writes one checklist_event in the same transaction as the change:

run_id, run_item_id, actor_member_id, occurred_at, kind, old_value, new_value, reason.

Kinds: performed_set, performed_cleared, performed_changed, marked_na, unmarked_na, remarks_changed, template_item_edited, run_started, run_locked. Past-date or back-dated edits require a reason.

Shown in two places: the history icon on a row (that row’s changes) and an Activity tab for the run (all changes; filter by person, section, date; export to CSV). Each event also writes a line to the existing activity feed, and performed-date changes also write the existing tamper-proof audit log because the sheet is an internal-control record.

4. Access

checklist.view, checklist.work (set Performed Date), checklist.manage (edit the template, start and lock runs). A locked run accepts no more edits.

5. Phases

1. Template, run, the table page, Performed Date and N/A, Excel import and export.
2. Event history, row history icon, Activity tab, feed and audit lines.
3. Optional: assignee per row, reminders, computed due dates and overdue flags, group roll-up of progress.

6. Questions

• Should custom columns be per company, or one set for the whole group?

• Customize per company (own copy of the list), per run only, or both as planned in 1a?

• Several companies in the group, each with its own run?

• Is a second person’s review wanted on each row, or is the Performed Date alone the sign-off?

• Monthly close: same list, or a separate one?