Setting up a workspace for accounting work

Workspaces created from the Accounting with 1C template arrive organised this way. Any other workspace can adopt it, and should if it is doing recurring bookkeeping — this page is the whole of it.

Nothing here touches the scripts. Installing those is the 1C starter kit; how to post a statement is importing a bank statement. This page is about how the workspace remembers.

The problem this solves

The complaint that produces it is always the same: "I already told you this."

An accountant explains that a company is a VAT payer and VAT goes on every operation. Next month, the assistant asks again. It asks again because the answer was said in a chat, and a chat is not a place a future session can read. The fix is not a better memory — it is writing the rule into a file.

Layout

knowledge/          rules that hold across every client
clients/<client>/   one folder per company, incl. its own knowledge.md
statements/         bank statements + their employee-list files
synced_data/1c/     one import report per statement
scripts/1c/         the integration (see the starter kit)
log.md              what changed and why, in order

Create what is missing. Do not move existing files around to match this — if a workspace already keeps statements somewhere else, that is the convention, and this page is not a reason to break links the user relies on.

Write down what the user teaches you

The moment the user states a rule, correction or preference, write it down before continuing the task — not at the end of the job. Where it goes depends on how far the rule travels:

That split is not tidiness. One company's accounting policy reaching another company's database produces wrong books, and it is the single most expensive mistake available here. A rule that is true of one organisation stays in that organisation's folder.

Write rules, not transcripts:

ТОО Ромашка is a VAT payer on the general regime — book VAT on sales and purchases. Confirmed by the user 2026-07-31.

is usable next month. "User said something about VAT" is not.

Read before you act. At the start of any job, read knowledge/ and that client's knowledge.md. When a recorded rule contradicts a generic regulation, the recorded rule wins — it was confirmed by the person who owns the books. When it contradicts what the user just told you, ask which is current, then update the file.

Staying current

New help topics get published and kits get new versions without anything in the workspace changing, and nothing notifies you. A fresh session also remembers nothing, so "read the docs again" is not a plan — you cannot tell a new topic from one you already read.

Keep knowledge/help-docs.md as the record of what you last saw:

# Help docs and kits — last seen

## Help topics
| slug | lastUpdated |
| --- | --- |
| 1c-bank-statement-import | 2026-07-31 |

## Kits
| kit | version |
| --- | --- |
| 1c-core | 1.1.0 |

Check at the start of the first job of a month — the monthly close is the natural point — and whenever a task doesn't match anything you already know:

1. Fetch https://plank.md/en/help/topics. It lists every topic with its title, summary and lastUpdated.
2. Diff against knowledge/help-docs.md. Read anything new, and anything whose lastUpdated moved, where it touches 1C, ЭСФ, or how you work here.
3. Fetch https://plank.md/help/kits/index.json and compare each version. If a kit moved, see the starter kit.
4. Update knowledge/help-docs.md, and note in log.md what actually changed.

Stay quiet when nothing changed. This is a few seconds at the start of a job, not a task of its own. Tell the user only when you found something that affects their work.

Adopting this in a workspace that already has 1C work

Most workspaces doing this work already have months of history and a pile of per-client scripts. Adopting this layout is additive — nothing below deletes or rewrites anything.

1. Create knowledge/ and clients/ if they are missing, plus a knowledge.md in each client folder that already exists.

2. Harvest what is already known. Read log.md, the existing per-client folders, and your own recent reports, and write the rules you find into the right file. Anything you had to ask about twice belongs here.

3. Leave hand-written scripts alone. A workspace full of import_<client>_statement.py files is not a mess to clean up — those scripts encode real decisions. Instead, write down in clients/<client>/knowledge.md what each one does differently and why, so the next session doesn't have to re-derive it from the code.

4. Check the kit against the starter kit — a workspace set up before 2026-07 will have an older copy, or none. Compare before replacing, and keep this workspace's mapping.json and credentials.

5. Add a short section to AGENTS.md pointing here, so the next session starts from this page instead of rediscovering it:

   ## How this space is organised
   
   Accounting work. Before any job, read `knowledge/` and the relevant
   `clients/<client>/knowledge.md`, and record anything new the user tells
   you there. The full conventions are at
   https://plank.md/help/1c-workspace-setup — fetch it rather than
   reconstructing it from memory.
   

6. Tell the user what you changed, in two or three lines. This one is worth reporting, unlike the routine monthly check.