IMS. ← All docs

IMS — Subsystems

The system consists of several subsystems, each responsible for its own
area of work. All subsystems are connected through documents and
reference tables — data entered in one subsystem is automatically
available in the rest.

Documents

The central subsystem. Everything that happens in the company involving
goods and money is recorded as a document. A document has a header
(number, date, counterparty, warehouse) and lines (item, quantity,
price).

Document types are defined by the operations reference table. Each
operation has a direction — receiving, expenditure, cash, order — and its
own name. There can be several kinds of receiving alone: "Receiving from
Supplier," "Receiving Return," "Receiving Free of Charge." The system
distinguishes them and lets you build a report for each kind separately.

What you can do:
- Create documents of any type
- Add, edit, and delete lines
- Process a document — this is the moment changes are reflected in stock
- Roll back processing — to fix a mistake
- Print invoices and bills
- View a document's change history
- Attach serial numbers to items
- Reserve an item for a specific customer

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

When creating a document, the user picks an operation from the reference
table. The operation determines which fields need to be filled in: for
receiving — supplier and warehouse, for expenditure — warehouse and
customer, for a cash operation — bank account.

If the operations reference table has auto-numbering configured, the
system assigns the document number itself and increments the counter for
the next one.

Customer orders

When a customer orders from us, an order is created. An order by itself
doesn't move goods or money. It's a checkpoint: this much was ordered,
this much was shipped, this much remains.

An order groups several documents under one number. For example: a
customer ordered 100 units, we shipped 60 on one invoice and 40 on
another — both documents are linked to the same order, and the system
shows that the order has been fulfilled in full.

What you can do:
- See the list of active orders
- Track each order's fulfillment status
- Open the linked documents (receipts, shipments)
- Create new documents from an order

Supplier orders (Projects)

The mirror situation — when we order from a supplier. The supplier-order
form is one of the most developed in the system.

Order lines — exactly what's being ordered: item, quantity, price,
unit of measure. Variants of the order can be saved for comparison — for
example, one variant with cheap components, another with high-quality
ones — and any of them can be loaded back.

Linked documents — which receipts have already been recorded against
this order. You can see what's arrived and what's still in transit.

Components — automatic breakdown of the order by BOM. If 10 products
are ordered and each consists of 4 parts, the system shows that 40 parts
are needed. For each component you can see:
- how much is required by the order
- how much is in stock
- how much is already ordered from suppliers
- how much is reserved

This lets you pinpoint exactly what needs to be bought.

Component matrix — a summary report: rows are components, columns are
orders. The intersection shows how much is needed. The bottom row totals
each component. Indispensable when several orders sharing common parts
are in progress at once.

What you can do:
- Create and edit order lines
- Automatically expand the BOM into components
- Refresh stock and reservation data
- Manually add or remove components
- Save and load order variants
- Print the supplier order
- Process the order

Reports

89 reports (as of 2026-07-31, the count keeps growing), covering every
aspect of the work. Before building, each report asks for parameters —
period, warehouse, counterparty, operation — and is built fresh from
current data.

Stock reports:
- Stock on hand — current and as of any past date
- Turnover — item movement over a period (receiving, expenditure,
balance)
- Item card — full history of a single item: every operation, every
document
- Inventory count — a blind-count sheet for physically reconciling a
warehouse (no system quantity shown)
- Transfer register — per warehouse, "sent"/"received" split for a
period, with document and line-level detail

Document reports:
- Document registers — a list of documents for a period by operation type
- Invoices — a document's printed form
- Bills — for issuing to a customer

Financial reports:
- Bank operations — money movement across accounts
- Revenue — income over a period
- Balances owed — who owes us / who we owe
- Customer turnover — how much each customer bought over a period

Order reports:
- Order turnover — order fulfillment over a period
- Component matrix — a summary table of part requirements

Other:
- Employees and personnel
- Discounts and price lists
- Corrections

A report as of a past date is a special capability. The system takes
current balances and mathematically rolls back every operation after the
requested date. Real data is never touched. This lets you see the state
of stock at any point in the past.

Point of Sale

The cash-register module for retail sales. A fast interface for the
cashier: find the item, add it to the receipt, complete the sale.

What you can do:
- Fast item search by name or SKU
- Add an item to the receipt with a quantity
- Automatic total calculation
- Apply discounts from price lists — the system automatically picks the
right discount for the customer and item
- Complete the sale — a sale document is created
- Print the receipt

Discount price lists let you set different prices for different customers
or customer groups. On sale, the system finds the applicable price list
itself.

History

View the history of changes. Who changed what and when — by document and
by item.

What you can do:
- View the history of a specific item — every operation with it:
receipts, expenditures, which documents, from which suppliers
- View the system event log

Tools

Utility functions for managing data and configuring the system.

Reservation — mark stock as "promised" to a specific customer or
order. The item stays physically in place, but the system shows how much
is really available for others.

Placement — indicate exactly where on the warehouse the item sits:
rack, shelf, cell. Helps find items quickly when shipping.

Serial numbers — attach a unique number to a unit of stock. On
receiving, enter the number; on expenditure, pick from the ones on hand.

Specifications (BOM) — describe what a product is made of. A product
is a list of components with quantities. Used in manufacturing and when
breaking down orders into components.

Expense distribution — spread shipping, customs, and other extra
charges across receiving lines proportionally to their value. After
distribution, the item's stock price reflects the real acquisition cost.

Extra sums — services, taxes, and totals added to a document on top of
the goods value.

Stock viewer — current balances for any warehouse, with search.

Ad-hoc queries — for power users: build a custom query against the
data with arbitrary conditions and groupings.

Event log — a system log: which operations were performed, by whom,
and when.

Access management — assign user permissions: who can see which
sections, work with which warehouses.

Employees — the company personnel reference.

Rollback — undo document processing. A single document can be rolled
back, or every document after a given date.

Report manager — configure report templates: which reports are
available, which operation type they're tied to.

Reference tables

Master data — everything documents and reports refer to. Work in the
system starts with filling in reference tables.

Main reference tables:
- Items — everything the company receives and issues: parts,
materials, products, services
- Partners — suppliers and customers. One company can be both
- Warehouses — physical storage locations
- Operations — document kinds: "Receiving from Supplier," "Retail
Sale," "Transfer," etc.
- Bank accounts — for cash operations
- Units of measure — pieces, kilograms, meters, packs
- Contracts — linking documents to counterparty contracts
- Payment methods — cash, bank transfer, card, etc.
- Specifications — a product's recipe (what it's made of)
- Price lists — discount and special prices for customers

The system has over 50 reference tables in total (registry — the sysfl
table, 52 records). All of them work the same way: search, view, add,
edit. Deleted records don't disappear, they're marked inactive — so as
not to break references from old documents.

Security and login

Login. The user enters a username/password. The password is stored in
the database as a bcrypt hash (not plain text) — comparison is done via
password_verify, not a direct string match. On a successful login, the
server creates a session — a random token is actually written to the
database (sessions table: token → who logged in → expiry, 12 hours), not
just handed to the client on trust.

Every request to the server. The app automatically attaches the
current session's token to every action — this is done in a single,
central place, not repeated per form, so every section of the app gets
this the same way.

Server-side check. Before performing any action (creating a document,
deleting, running a report — anything), the server checks: is there a
valid token, does such a session exist, has it expired. No valid session
— the action isn't performed at all. The exception is login itself and
token verification (otherwise there'd be nothing to log in with).

Login is mandatory. Previously, in a test mode, the app opened the
menu right away, without login. That's been removed — without login
there's no session, without a session the server refuses the very first
action, so login has become not just the first screen but effectively a
required condition for using the app.

What isn't checked yet. The server currently only checks "is the user
logged in at all," not "can this particular user perform this particular
action." Role-based permissions are currently only enforced in the UI
(hiding unavailable buttons) — the server doesn't re-verify them. This is
the next step in the system's development, not yet done.

How the subsystems connect

Everything converges on documents and reference tables:

Data is entered once and used everywhere. There's no duplication — there's
a single source of truth.