Skip to content
MiletusDigital Solutions Engineering
Diagnostic
PRODUCT / THALES ERP

The same ERP in the cloud and on your own servers.

Thales ERP is an ERP that behaves identically in the cloud and on-premises, complies with Turkish e-document regulation and allows customisation that survives upgrades. Finance and accounts, inventory and purchasing, sales and CRM, production and MRP work on the same record, in one core.

Request a short diagnostic

Product sheet

Code
P-THALES
Owner
Miletus Digital
Deployment
Cloud · on-premises (Linux)
Modules
Finance and accounts · Inventory and purchasing · Sales and CRM · Production and MRP
Phase
M4
Updated
11 October 2026

Three claims, three mechanisms.

  1. 01 / 03

    Day-one deployment parity.

    The cloud install and the install on your own servers run from the same release artefact, with the same API and the same database migration chain. There is no environment-specific code branch, so moving where it runs changes no behaviour, screen or report.

  2. 02 / 03

    Provider-independent e-document compliance.

    e-Invoice, e-Archive and e-Waybill sit in a compliance layer kept apart from the sales, inventory and finance schema; a private integrator and a direct GİB connection both attach only to that layer. Changing provider touches neither the data schema nor the workflow.

  3. 03 / 03

    Customisation that survives upgrades.

    Customisation is written to five defined rungs, not to the core code: configuration, typed field, versioned API and event, workflow, signed extension. Forking the core and writing to the database directly are closed, so moving to a new version does not erase it.

Four modules, one record.

Each module carries one role's daily work; the record doesn't change hands between modules, it stays in one place.

  • M-01Jobs · 4

    Finance and accounts

    • Chart of accounts, immutable journal and reversals
    • Customer and supplier accounts, collections and payments
    • e-Invoice, e-Archive and e-Waybill flow
    • Cash and bank accounts, fiscal period close
    Role profileAccounting / finance
  • M-02Jobs · 4

    Inventory and purchasing

    • Warehouses, lot and serial traceability
    • Stock movements, reservations and counts
    • Purchase orders, goods receipt and invoice matching
    • Label printing and barcodes
    Role profileWarehouse / inventory
  • M-03Jobs · 4

    Sales and CRM

    • Quotes, orders and shipments
    • Lot links on shipments
    • Customer records, addresses and tax IDs
    • Orders linked to invoicing and collection
    Role profileSales
  • M-04Jobs · 4

    Production and MRP

    • Bills of materials and routings
    • Work orders and shop-floor terminal
    • Material shortages and requirements plan (MRP)
    • Capacity load view
    Role profileProduction planning / shop floor

Screen tour.

Screens are shown with synthetic data. Until the real screenshots are added, each frame holds a schematic of that screen.

Journal voucher draftSample · Synthetic
Journal voucher draft — Sample · Synthetic
Goods receipt recordSample · Synthetic
Goods receipt record — Sample · Synthetic
Sales ordersSample · Synthetic
Sales orders — Sample · Synthetic
Work orders and material shortagesSample · Synthetic
Work orders and material shortages — Sample · Synthetic

What it is built with.

The short list for the technical buyer: what it is built from, and why it holds up through upgrades.

Architecture/api/v1 · OpenAPI
  1. 01Go backend
  2. 02React + Vite front end
  3. 03PostgreSQL
  4. 04Modular monolith
  5. 05/api/v1 · OpenAPI contract
  6. 06RBAC + segregation of duties
  7. 07Append-only audit trail
  8. 08Transactional outbox
  9. 09PostgreSQL row-level security (RLS)
  10. 10Podman / systemd, rootless
Same work, two ways

By measurement, not instinct

By instinct
By measurement
Rewriting the ERP whenever the integrator changes.
e-Documents live in their own compliance layer; changing integrator needs no schema migration.
Patching customisation into the core and redoing it at every upgrade.
Customisation lives on defined rungs, not in the core; the upgrade carries it.
Cloud and on-site installs drifting apart over time.
Both run from the same release artefact; the only difference is where they run.

Works together with.

Thales keeps the operational record; two Miletus ADS products carry the marketing side. All three are parts of the same data line.

Chain · one data lineDIGITAL + ADS
  1. 01ADS
    Ad
    Miletus Panel
  2. 02ADS
    Conversation / lead
    Miletus CRM
  3. 03DIGITAL
    Order / stock / invoice
    Thales ERP
  4. 04ADS
    Measurement / decision
    Miletus Panel

A product carries each step from ad to measurement; the data between the steps is the same.

What do people ask about Thales ERP?

Cloud or on-premises?

Either. Thales runs from the same release artefact, with the same API and the same database migration chain, in the cloud and on your own servers; there is no environment-specific code branch. An on-premises install runs rootless on Podman and systemd and does not have to connect to our cloud servers; the choice changes where it runs, not the product.

What happens to our current accounting software?

Thales does not carry over past transactions from the old software; the switch happens from a start date. A new company opens with a ready chart-of-accounts template, account records are set up and the opening balances at that date are entered. Past periods stay in your current software; we settle the start date together in the diagnostic.

What if our e-invoice integrator changes?

e-Invoice, e-Archive and e-Waybill sit in a separate compliance layer; a private integrator and a direct GİB connection both attach only to that layer. When the provider changes, the connection settings change; the data schema and the workflow stay as they are.

How is customisation done?

On five rungs, starting with the lightest: configuration, typed field, versioned API and event, workflow, signed extension. Forking the core and writing to the database directly are closed, so customisation stays in place when you move to a new version. The runtime for signed extensions belongs to a later phase.

Who holds our data?

You do. On-premises, the data stays on your own servers, and sending telemetry out is not required either. In the cloud your data is kept in your own tenant: every request is bounded on the server by tenant context and PostgreSQL row-level security. Permission, financial-record and document changes are written, in the same transaction, to an append-only audit trail; if the trail cannot be written, the change is not made.

Which companies is it for?

SMEs in manufacturing, trade and distribution, or services and projects; all three run on the same core. When accounting, warehouse, sales and production have to work on the same record, Thales holds that shared record; a short diagnostic settles together whether it fits.

Start here

Bring one job you can't measure

The first conversation is a diagnosis, not a sale — and it's free. After a fixed-frame call you get one written page: where to start, and what not to do.

Emailinfo@miletusdigital.com

We reply within two business days.

Diagnostic call

Describe the job you can't measure in one line; in a free, fixed-frame conversation we'll pin down where to start.

Request a short diagnostic →info@miletusdigital.com