Skip to content
العربية

Document Terms in Service Center

Two workshops running the same Nama installation can behave completely differently. One closes a job order and a stock issue comes out of it; the other closes an identical job order and nothing leaves the store. One car receipt brings the chassis into stock; the next branch's car receipt is a piece of paper. Nobody wrote any code to make that happen — the difference lives entirely in the document term (توجيه المستند).

Every Service Center document you save carries two things at the top of the screen: a book, which decides how it is numbered, and a term, which decides how it behaves. The book is bookkeeping hygiene. The term is the configuration — and, alongside the module configuration screen, it is where most Service Center behaviour is decided.

Required licence

srvcenter for the workshop documents. The car documents also need srvcenter-subitems, the policy documents srvcenter-insurance-and-installments, the rental documents srvcenter-rental-assets, and the courier documents srvcenter-mobile-delivery.

What a term actually decides

A term is a saved rulebook for one document type. You can have as many as you like — a term per branch, a term per workflow, a term for the cash counter and another for the credit counter — and you choose which one applies each time you raise a document.

Across Service Center, the settings on a term fall into four families. Learn these four and every term screen in the module becomes readable, whichever document it belongs to.

Accounts. Most terms carry one or more pairs of accounting sides — a debit and a credit — which say where the document's money lands in the ledger. Al-Sahra Motors' job-order closing term, for instance, names the pair that receives the customer share of a finished repair.

Generation settings. Several documents do their real work by creating a second document: a job order closing creates the stock issue for the consumed parts; a car receipt creates the stock receipt that brings the chassis into the showroom store. The term names the book and term of the document to be generated. This is the single most consequential block in the module, and the one this documentation warns about most.

Stamping settings. Service Center terms are unusually chatty with master files. A workshop term can move the vehicle's status when the document commits, and fire a notification when it does. A car term can stamp a dozen back-references onto the car record — which invoice sold it, which traffic letter was issued, which salesperson handled it.

Behaviour switches. The rest are plain rules: refuse the gate pass until the customer invoice is paid, refuse the closing until every part has been issued, copy the job order's planned parts onto the issue, split a quantity of six into six separate car records.

Which documents share which term

A term is written against a family of documents, not always against one. Where two documents share a family, one term record serves both — and a setting you make for one silently applies to the other, which is worth knowing before you tune anything.

Term familyDocuments that use it
Common workshop documentsService Request, Job Estimation, Estimation Update, Add Task To Job Order, Pending Operation, Resume Operation, Product Inspection Document
Job OrderJob Order
Job Order ClosingJob Order Closing
Gate PassGate Pass
Job Order ExecutionJob Order Execution (the menu reads Production Review)
External RepairExternal Repair
Spare Parts IssueSpare Parts Issue
Spare Parts Issue RequestSpare Parts Issue Request
Spare Parts ReturnSpare Parts Return
Car sales documentsSales Quotation Request, Sales Quotation, Sales Approval, Sales Order, Sales Order Cancel, Allocation, Allocation Cancel, Pro-forma Sales Invoice, Final Delivery, Final Delivery Cancel, Traffic Letter Request, Traffic Letter Request Cancel, Traffic Letter, Traffic Letter Cancel
Car receipt documentsCar Receipt, Car Receipt Cancel
Car Sales InvoiceCar Sales Invoice
Car Sales ReturnCar Sales Return
Car Purchase OrderCar Purchase Order
Car Pro-forma Purchase InvoiceCar Pro-forma Purchase Invoice
Car Purchase InvoiceCar Purchase Invoice
Car Purchase ReturnCar Purchase Return
Sub Item Assembly DocumentSub Item Assembly Document — the only document in the module that needs the supplychain-assembly licence on top of srvcenter-subitems
Insurance Policy OrderInsurance Policy Order, Insurance Policy Renewal
Insurance Policy ReceiptInsurance Policy Receipt
Insurance Purchase InvoiceInsurance Purchase Invoice
RentalRental Request, Rental Invoice
Reservation CancelReservation Cancel
Delivery DocumentDelivery Document
Batch Delivery DocumentBatch Delivery Document
Invoice Receipt DocumentInvoice Receipt Document

Twenty-six families for eighty-odd documents — which means most of your configuration effort goes into a handful of screens. The two that repay attention first are the Job Order term and the Car sales term, because between them they cover the whole of both halves of the business.

Nine documents have no term at all

Some documents in this module have nothing to configure. Their document book still shows a توجيه tab, but there is no term class behind it, so there is no rulebook to write and nothing you can tune per book:

  • Attendance
  • Odometer Reading Log
  • Product Task Opening
  • Customer Insurance Policy
  • Insurance Policy Delivery
  • Insurance Policy Cancellation
  • Insurance Policy Period Adjustment
  • Insurance Policy Value Adjustment
  • Instalment Quotation

Five of those nine are insurance-policy documents, so more than half of the insurance sub-module's documents behave one way and one way only. If you have been hunting for the switch that makes a policy delivery post something, stop hunting — there is no switch, and the document posts nothing.

The rule that governs the other two pages

Here is the habit to build, because it is what separates a working configuration from a plausible-looking one:

An account block on a term screen does not prove the document posts

Several Service Center term screens are assembled from a shared layout that carries the full accounting block — debit, credit, cash, taxes, eight discount accounts — regardless of whether the document behind it ever produces a journal entry. Filling those fields on a document that does not post produces no error, no warning, and no entry. You simply never see the money.

The two worst offenders are named on the car, insurance and rental terms page: the four traffic letter documents, and the Car Pro-forma Purchase Invoice. Treat every account block as unproven until you have committed one document and looked for the entry.

The pro-forma deserves a second sentence, because it is not merely inert:

The Car Pro-forma Purchase Invoice can acquire entries out of band

Committing a Car Pro-forma Purchase Invoice posts nothing, no matter what is on its term. But the generic More → Regenerate Accounting Effects action on that same document does reach the ledger and does create entries from those accounts. A document that has never posted can suddenly sprout a journal entry because somebody used a menu item. Document the pro-forma internally as a non-financial document and leave its account fields empty.

Generation: the switch that lies, and the two that double

The generation block is where terms cause real damage, and always in the same two ways.

"Generate Document" does not always stop generation

On the Car Receipt, the Car Final Delivery, the Spare Parts Issue and the Spare Parts Return, the Generate Document(s) / إنشاء مستندات تلقائيا tick box is not consulted. Whatever you set, these documents look only at the Generation Book and Generation Term. Unticking the box and leaving the book filled still produces the stock document.

To stop generation on those four documents you must clear the generation book and the generation term. Nothing else works.

The same applies to Manual Generation on the car receipt and the final delivery, and to the whole generation block on the Spare Parts Issue Request, which generates nothing under any setting.

And then the two symmetric traps. They are the reason this page exists at all, because a document term is the only place a reader can act on them.

Stock in — the car can be received twice

Both the Car Receipt and the Car Purchase Invoice are able to generate a Stock Receipt for the same chassis, and neither can see the other's stock document. Configure both and the car arrives in stock twice, at double cost, with no error at all.

The safe rule: fill the generation Book and Term on exactly one of the two terms. Al-Sahra Motors generates on the purchase invoice (SIPI-2026-021 produced stock receipt STR-2026-0552) and leaves the car receipt's generation book and term empty, so car receipt SIR-2026-0088 records the physical arrival, the accessory checklist and the parking slots and moves nothing. Remember that unticking Generate Document on the receipt is not enough — blank the book and the term.

Treat the two documents as alternatives, never as a sequence.

Stock out — the car can be issued twice

The mirror image. Both the Car Sales Invoice and the Car Final Delivery are able to generate a Stock Issue for the same chassis, and again neither sees the other's document. Configure both and the car leaves stock twice, its cost is relieved twice, and on-hand goes negative — silently, or with a shortage error that names a stock document nobody created by hand.

Same rule: fill the generation Book and Term on exactly one of the two terms. Al-Sahra issues from the sales invoice (SISI-2026-0498 produced stock issue STI-2026-1201) and leaves the final delivery's generation book and term empty, so SIFD-2026-0357 is purely the hand-over record. And again: unticking Generate Document on the final delivery does nothing — blank the book and the term.

Where to go next