Trading ERP for AL Rukan Al Hassan

Guru ERP configured for trading: sales, procurement, HRM, accounts and VAT. Same codebase as the Riyadh plant, two industries.

Client
AL Rukan Al Hassan Co
Location
Saudi Arabia
Project type
Trading ERP
Status
In production
Result
One platform serving two operations that have almost nothing in common.

The client

AL Rukan Al Hassan Co is a trading business in Saudi Arabia. A trading operation and a manufacturing plant look nothing alike from the outside: one converts material, the other moves it. Underneath they want the same thing, which is one number for what is where, what it cost and what is owed on it.

The challenge

A trading operation needed the same operational control a factory system gives a plant.

The constraintVAT had to be correct from the first invoice, not bolted on later.

Objectives

  • Give a trading operation the operational control a factory system gives a plant.
  • Get VAT right on the first invoice rather than in a reconciliation afterwards.
  • Stay on the same codebase as the Riyadh deployment, so neither becomes a fork.

Built on Guru ERP, a platform we own and operate rather than resell.

What we built

Guru ERP configured for trading: sales, procurement, HRM, accounts and VAT. Procurement and HR are the same modules the plant uses; sales and tax are where the two deployments diverge.

Tax is configuration, not a patch. A regime handled in code is a regime that has to be re-engineered every time a rate moves, and rates move.

The Guru ERP dashboard in the public demo, showing the week’s sales, transaction count and average basket over a daily revenue chart, with revenue by category beside it
Guru ERP, the platform this engagement runs on. Screenshots on this site come from our public demo tenant on generated data, never from a client's live system.

What it does, in production.

  1. Sales

    Quotation through to invoice, with tax resolved per line rather than applied to a total.

  2. Procurement

    The same requisition-to-receipt path the Riyadh plant runs, against a trading item master.

  3. Accounts

    Ledger entries generated by the operational events that caused them, not keyed in behind them.

  4. VAT

    Handled as configuration, so a rate or rule change is a setting rather than a release.

  5. HRM

    One employee master shared with the rest of the system.

  6. Operational reporting

    Stock, margin and receivables from the same data the invoices came from.

The shape of the system.

One codebase, two tenants, two configurations. The interesting part of that sentence is what the two deployments share: procurement and HR are the same modules in both columns, and the lists diverge either side of them.

The integration map, the data model and the deployment topology are covered in technical review under NDA rather than on a public page. The shape of the system is described here; the detail is a conversation, not a download.

How it was delivered.

The Riyadh deployment came first, which meant this one started from a system that had already survived a production floor. What it did not start from was an assumption that a trading company works like a plant.

Configuration was mapped against the operation before anything was switched on, and the tax rules were the first thing validated rather than the last.

Engineering challenges

Keeping one codebase honest

The cheapest way to serve a second industry is to fork. It is also the decision that costs three years of maintenance. Everything that differs between the plant and the trading operation lives in configuration, so both deployments take the same fixes.

Tax as data, not as code

VAT rules that live in the codebase turn a regulatory change into an engineering project. Modelled as configuration, the same change is a setting an accountant can be shown before it goes live.

What changed.

  • One platform serving two operations that have almost nothing in common.
  • The system is in production and we are still the ones supporting it.

No figure is published for this engagement. The claim that carries weight here is structural and checkable: the same build runs in two industries, and neither deployment is a fork of the other.

TechnologyWeb application, browser delivered · Configuration driven tax and localisation · Shared item and employee master · Role based access control

You do not need to arrive with a perfect technical specification.

Start with the problem. Tell us what is slowing the business down, what you want to build, or where the current system is failing. We will tell you the shortest path forward, including when that path is not us.

Start your build