ERP Layer · End-to-End Processes
The end-to-end process lives in one database: modules do not need to “integrate with themselves”
The KASKAD ERP layer runs end-to-end processes on top of the modules: a request becomes a commercial proposal, goes through routed approval, turns into a deal, ships from the warehouse, and lands in a report. One login, one database, shared reference data and permissions - modules never exchange file exports because they work with the same data.
End-to-End Chain
Six steps from request to report - with no data re-entry
Each step of the chain runs in its own module, but on shared reference data, currencies, and permissions. No files travel between departments: every step sees the result of the previous one immediately.
step 1
Request
A lead or request is captured in CRM. The counterparty comes from the shared directory: the warehouse and documents already see it.
step 2
Proposal
The commercial proposal is calculated by an exact-arithmetic engine - no rounding errors down to the last cent. Currency and VAT come from the organization profile.
step 3
Routed approval
The proposal follows a route like any document: sequential, parallel, or mixed - one of three types.
step 4
Deal
An approved proposal becomes a deal in the pipeline. Managers and executives see its status without exports or reconciliation.
step 5
Warehouse shipment
Shipment deducts stock in real time; every movement leaves a row in the warehouse journal. Cost of goods is tracked by valuation layers (FIFO).
step 6
Report
Stock and movement reports are built on the same data the chain ran on. Every step remains in the audit log.
Shared Reference Data
A counterparty is entered once - and visible in CRM, the warehouse, and documents
Counterparties, products, organizations
One directory for all modules. No re-entry and no duplicate reconciliation: the counterparty card in a deal, a shipment, and a document is the same record.
Shared currencies and VAT
The organization’s base currency (Uzbek som by default) and VAT are set in the organization profile. Proposals, deals, and shipments follow the same rules.
Shared permissions and audit
Four system roles plus a builder for custom ones: operations are granted by name from the “role × entity × operation” catalog. The audit log is shared across all modules.
Integrations and Open Interfaces
Integrations are built on the same events the system itself runs on
Inside the platform, modules already communicate through events. External systems follow the same rule: explicit events and an agreed exchange contract instead of opaque file exports.
Inside - an event bus
- Services communicate over NATS. A deal in CRM, a stock movement, a route step - events on a shared bus, not scheduled exports.
- The same events are available to your integrations. An external system subscribes to what already happens in KASKAD - no separate “integration layer” is invented.
- Integrations stay visible to oversight. Significant actions remain in the audit log - including those performed through an integration scenario.
Outside - an agreed contract
- Exchange with external systems - core banking, HR, accounting - follows a contract agreed within the implementation project: data scope, direction, schedule.
- The contract is part of the project documentation. Exchange formats and schedules are fixed in writing at the implementation stage, not sorted out over email after go-live.
- Everything stays in your perimeter. Services, database, files, and the bus run on the customer’s servers. Internet access is needed only for channels (Telegram/SMS), and they can be disabled.
We will walk the end-to-end chain on a live demo stand
Tell us about your process - from request to shipment. We will run it in a demo and prepare a commercial proposal. The demo takes 40 minutes.