IMS — Operating Concept

Every program written for real use, especially for record-keeping, rests
on some underlying idea. Everything else follows from it.

The idea behind this program is currency of data — that the system
always reflects the real, current state of things.

Which means:

1. When a user opens the system, they should see a picture as close as
   possible to the real state of the business.

2. Any company communicates with the world through documents — it sends
   something or reports something. That's what its activity consists of.
   Of all the documents a company might use, we only deal with the ones
   that change the quantity of goods/components, their location, or money
   (only the part tied to goods/components). Technical or process
   documentation, for instance, is out of scope.

3. From the "Document" concept it follows that a document in the system
   must appear before the real-world operation. If changes are
   recorded from the document only after the real operation has happened,
   the data will sooner or later drift from reality — the person doing
   the work no longer has any incentive to process the document
   accurately.

4. In small companies, operations happening inside the company are
   usually not tracked (not processed) — accounting doesn't need it for
   reporting. In our system, it's mandatory. Any change in the position
   or state of goods/components must be recorded as a document.

5. We assume that any person will make the right decision if they're
   working from correct data. If the data doesn't match reality, the
   decision will be wrong.

6. No record-keeping system makes life easier. It demands effort and
   constant discipline. It creates a lot of friction at the start. But it
   always leads to order and stronger control — which enables more
   accurate decisions.

7. The system works only through reference tables. Operators don't type
   free text, they only pick values from reference tables. This
   minimizes mistakes.

8. This approach lets an untrained person start working almost
   immediately. They see a document and enter it into the system — only
   by picking from reference tables. It's hard to get wrong.

Of course, real life is far richer and less predictable than any
record-keeping system. But keeping our overarching goal in mind — making
the system's state as current as possible — we allow any information in
the system to be corrected, through special documents that themselves
become part of the reporting trail (who corrected it, when, where, what
changed to what). Correctness is verified by people.

So:
- Every action is a document.
- The document comes before the action.
- Only system-generated documents circulate within the company.
- Verbal orders or notes must not be used.

What this actually is

IMS is an operational-control system. Not accounting, not an ERP, not a
warehouse program in the usual sense. IMS keeps data current — it records
what happens to goods and money: who, when, how much, from where, to
where. Everything else — reports, stock levels, balances owed — follows
from the recorded operations rather than being independent data of its
own.

The main principle: currency of data matters more than convenience

The system doesn't block business activity, but it does demand order. If a
document isn't recorded, the system loses its currency — and at that
point it's useless. Therefore:

• Releasing goods without a document is not allowed — not because the
  system forbids it as such, but because the data would stop matching
  reality.
• Selling something that isn't in stock is not allowed. You can't
  write off what doesn't exist.
• Manufacturing from components that aren't in stock is allowed. The
  shortage is recorded but doesn't block the output. The exact behavior
  is left to each deployment's requirements.
• A document with a zero price is not processed. A zero price
  devalues every calculation and report downstream. This is a hard rule.

Why the document must come before the action: experience shows that if
you ship goods first and record the document afterward, the document
either never gets recorded at all, or gets recorded with errors. The
person doing the work no longer cares — the goods are already gone, so
there's no incentive to get the paperwork right. Hence: document in the
system first, physical operation against the document second.

The document — the unit of work

Everything in the system happens through documents. A document is a fact:
"On June 15th, 100 units of item Z arrived at warehouse Y from supplier X
at a price of 10."

Why a document, and not individual operations: because in reality,
events come in groups. A supplier doesn't deliver one part, they deliver
an invoice with 50 line items. A sale isn't one item, it's a receipt with
several lines. A document ties together all the lines of a single event:
one date, one supplier, one warehouse.

Document lifecycle

1. Creation — the header is entered (number, date, supplier,
   warehouse)
2. Filling in — lines are added (item, quantity, price)
3. Processing — "Processing" is clicked. At this moment the system
   updates stock levels
4. Done — the document is processed, changes are reflected in stock

Why processing is a separate step, not automatic: because a document
can take hours or days to fill in. While you're entering 50 lines, stock
shouldn't twitch after every single one. Processing is the moment you say:
"this is it, the document is ready, apply it."

Before processing, a document can be changed freely. After processing —
only through a rollback.

Operation types

The type defines what happened — the direction of goods or money movement:

• Receiving (+) — goods arrived into stock
• Expenditure (−) — goods left stock
• Cash/Bank — money movement
• Order — an intent (not yet goods, not yet money)
• Manufacture — a product was assembled from components (minus parts,
  plus product)
• Correction — a price change with no goods movement

Each type (receiving, expenditure, etc.) is only a direction. Within one
type there can be any number of distinct named operations. For example:
"Receiving from Supplier," "Receiving Against Debt Repayment," "Receiving
Return." Any name you'll later want a report broken down by.

Why it's set up this way: because any business operation is one of
two things — a movement of goods or a movement of money. The type defines
the direction: goods arrived (+) or left (−). The operation name defines
the reason.

Two prices on every line

Every document line carries two prices:
- the price BEFORE the operation
- the price AFTER the operation

The actual meaning depends on the operation type. For receiving: the price
AFTER is the supplier's price, the price BEFORE is the cost including
extra charges. For expenditure: the price AFTER is the warehouse (cost)
price, the price BEFORE is the sale price.

Why two prices: because buying something for 100 and getting it into
stock at 100 are two different things. Shipping cost 20, customs cost 10 —
the real unit cost is higher. Calculate distributes extra charges across
all lines proportionally to their value.

Stock — a dynamic reflection of reality

Stock is current as of "now," but can show its state as of any date in the
past. The balance is the result of all processed documents — it isn't
stored on its own, it's computed.

Why: because manually maintaining stock balances is a source of
errors. If a balance is stored separately from the operations, it can
drift out of sync. In our system, a balance can never be "corrupted" — it
always follows from the documents. If a balance is wrong, that means some
document is wrong, and that document needs to be found and fixed.

Lot-based (batch) tracking

Every receipt creates a separate lot. If an item arrives twice at
different prices, that's two lots. On a sale, goods are written off from a
specific lot.

Why by lot: because the incoming price differs each time. A lot
carries its own history: where from, when, at what price, from which
supplier.

Rollback — the only way to fix a processed document

A processed document cannot be edited. To fix it, you roll it back: the
system undoes all the stock changes, and the document returns to "not
processed" state.

Why not just edit it directly: because a processed document has
already changed stock balances. A rollback guarantees consistency: the old
changes are undone first, then the new ones are applied.

A bulk rollback lets you "roll back" the whole warehouse to a specific
date — undoing every document after that date in reverse chronological
order.

Products — recipes (BOM)

A product is an item made up of other items. A TV made of parts. Borscht
made of ingredients. A stool made of boards and nails.

During manufacture the system automatically creates a plus for the
finished product and a minus for each component per the recipe. A
shortage of components doesn't block the process — the system records
what's available and what's missing.

Orders — an intent, not an operation

An order doesn't move goods or money. It's a checkpoint: this much was
ordered, this much was received, this much remains to be received.

An order can have several variants, for choosing the best composition for
a budget. A component breakdown matrix shows: what's needed, how much is
in stock, how much to order, what it costs.

Reservation — a promise, not a fact

Goods are physically in stock, but marked as "promised to a specific
customer." The system shows how much is really available for others.

Why not write it off immediately: a promise isn't a fact. The
customer might change their mind.

Reports — computed, not stored

A report is recomputed from scratch, from the operations, every time it's
run. If an error in a January document is found and fixed in March, a
March report covering January will show the corrected data.

A report as of a past date — the system takes the current balances and
rolls back every operation after the requested date, in a temporary copy.
The real data is never touched.

User-defined queries

Large companies with regional dealers want reports broken down by
arbitrary groups. A user creates a named filter: "Region 1" = dealers A,
B, C. The filter can be plugged into any report. Dealers can move between
regions — you only need to change the group's membership.

Summary: why it's built this way