Hi, I'm Abak — I'm responsible for the development of ERP.Knopka. I'll tell you not about marketing, but about the engineering decisions I am genuinely proud of. A financial product is first of all trust in the number: if the number lies, nothing else matters.
decision No. 1: revenue is cash, not “one number”
The most common bug in financial systems is storing revenue in a single field. Then it's unclear: did the money come in, or was an order just created? From the very start we separated cash (what actually came in), turnover (the value of services by category) and receivables (turnover minus cash), which is calculated automatically.
It sounds like a small thing, but this is where the honesty of the whole product grows from. Cash flow is built only from cash. Royalties are calculated from the money actually received at the cash register in the month — after discounts and net of refunds: you can't charge a percentage on money that doesn't exist yet. A prepayment and a balance payment are two different events, and each lands on its own day. That is why the ERP shows revenue and cash by day, and location profit for the month. When I checked the calculation at a real location in Shchyolkovo, everything matched to the ruble.
Why cash and turnover are different numbers and what an owner should do about it is covered in the article turnover is not cash: how not to mix up cash, turnover and receivables.
decision No. 2: one location doesn't see another
ERP.Knopka is designed for dozens of a network's locations in one system — and none of them should see another's money. The isolation does not rest on “a filter in the code that is easy to forget”, but on the database level: on row access policies in Postgres. Every query goes through the check “which locations do you have access to”. We run the automated tests “location A can't see location B's data” on every migration.
In the audit before connecting the first locations I caught a hole in how an employee is linked to an account — and closed it before live partners arrived. Financial security is not a feature, it's hygiene.
Which locations a person can access is set by roles by location in ID.Knopka: one employee can have different roles at different locations.
decision No. 3: pay for what a person actually did
A technician is paid not “on average”, but from their output by the location's rates: per service or per category. The output comes from the CRM — from order items where the performer is recorded. Nobody enters it by hand, and there are no timesheets of “sat for eight hours”. Fair and transparent.
Every location has its own rates. The main one is the rate per service; the fallback is the rate per category, if there is no rate for the specific service. A rate is either a percentage or a fixed amount per item, and the technician's percentage is calculated from the amount after or before the discount — as the partner decides. Work for which no rate is set is highlighted, so it doesn't get lost in the calculation.
Then the location manager marks the payment — in full or in parts, with the advance repaid — and can export the calculation to Excel. The ERP itself does not transfer money: it calculates who is owed how much. In detail, with an example, in the article how to calculate technician pay by location rates.
decision No. 4: the phone is a workplace
A partner looks at finances not at a desk, but in passing — on the floor, on the move. That's why the mobile version is not a “squeezed desktop”. A floating bottom bar that collapses into a half circle at the edge of the screen with one tap; a menu that slides up from the bottom and can be dragged with a finger. I verified this on a real iPhone, not in a shrunken browser window — because there is a gulf between them.
decision No. 5: the product as part of an ecosystem
ERP.Knopka lives together with the CRM, LMS and ID. The services are on different stacks, but trust each other through signed events and single sign-on: ID.Knopka gives an employee one account for all products. From the CRM, the ERP receives orders, payments, refunds and technician output. An order is paid in the CRM → the money appears in the ERP cash → royalties and pay are calculated on their own. We write the contract between the services explicitly, in one place, so nobody has to “fill in the gaps”.
How the products share data and when to take them together was explained by Herman in the article CRM, ERP and LMS: when to take them separately and when together.
where the ERP is now and what's next
ERP.Knopka is live at the first locations of the SneakNFresh network; the other locations are being connected in waves. Besides cash, location profit and technician pay, it has a shift schedule and a supplies inventory: an item gets a minimum stock level, and when the stock crosses it, the location manager or partner gets a “running low” push notification — once, not every hour.
The single employee account already exists — it's ID.Knopka. In progress are the cost of services based on usage norms and a history of rates. But the main principle will not change: the number can be trusted. That is the whole job.
frequently asked questions
how does cash differ from turnover?
Cash is money that has actually come in. Turnover is the value of the services provided, by category. The difference between them is receivables, and ERP.Knopka calculates it on its own.
what are royalties calculated from?
From the money actually received at the cash register in the month — after discounts and net of refunds. ERP.Knopka does not charge a percentage on money that doesn't exist yet.
where does the ERP get a technician's output from?
From the CRM — from order items where the performer is recorded. Nobody enters output by hand, and pay is calculated by the location's rates.
can one location see another's data?
No. Location isolation rests on the database level, every query checks which locations a person has access to, and automated tests for this run on every migration.
does the ERP transfer money to technicians?
No. The ERP calculates who is owed how much, and the location manager marks the payment — in full or in parts — and can export the calculation to Excel.
