Business rules and validation field guide

Validation is the part of OSERP that explains what may happen, when it may happen, and what evidence is required. A rule should be deterministic, scoped, testable, and visible to the user. A green status means the configured checks passed for that moment; posting revalidates because data may change while a document waits for approval.

Rule definition fields

Open Administration → Rules → New.

Field	Example	Purpose and impact
Rule code	SALES-CREDIT-001	Stable policy key
Module/entity	Sales Order	Record scope
Event	Confirm	Evaluation point
Company scope	company_uae	Isolation
Effective from/to	2026-01-01 / blank	Version boundary
Condition	Exposure + order > limit	Decision logic
Severity	Error / warning	Block or inform
Message code	CREDIT_HOLD	Searchable user reason
Owner	Credit manager	Exception responsibility
Override role	CFO	Controlled bypass
Tolerance	AED 100	Materiality boundary
Evidence	Credit approval	Proof requirement
Status	Active	Future execution

A version is immutable after execution. Change creates a new rule version with author, reason, approval, and effective date. Historic evaluations show the version used.

Evaluation timing

Rules may run on draft save, submit, approve, post, import, receipt, allocation, payment release, or close. Early checks improve guidance; final checks protect accounting and stock. A draft may allow incomplete fields, while posting requires company, period, account, tax, and source.

Document status should show last validation time, rule version, passed checks, warnings, errors, and data snapshot or hash. A user should know whether a warning is informational or blocks the next action.

Precedence and conflict

Rules can be global, company, branch, warehouse, item, partner, contract, or transaction-specific. Precedence must be explicit. For example, a customer contract price may override a general price list, while statutory tax overrides a customer discount.

When two rules conflict, show selected rule, ignored rule, effective dates, and reason. Do not depend on file order or undocumented database sequence.

Tolerances and precision

Tolerance fields define quantity percentage, price amount, tax difference, currency rounding, date window, credit exposure, or count variance. State whether comparison uses transaction currency, functional currency, or base quantity.

An AP price variance of USD 1.20 per carton may be within a 1% tolerance, while a tax variance may require exact match. Rounding is not a permission to exceed a control; record residual and rule.

Error and warning messages

Messages should identify rule code, field, actual value, expected condition, action, owner, and request/correlation ID. Example: CREDIT_HOLD: exposure AED 260,000 exceeds limit AED 250,000; credit manager approval required. Avoid vague “validation failed.”

Localise wording without changing code or policy. API responses expose machine-readable code and field path; UI shows clear explanation.

Overrides and approvals

Override fields include rule, original result, new decision, reason, evidence, actor, role, timestamp, expiry, and approver. A warning may be overridden by permitted role; an error should require an explicit approved exception or remain blocked.

Overrides are not edits to master data. A salesperson cannot increase a credit limit by overriding an order; a warehouse clerk cannot release quarantine by overriding a quality result. Segregate maker and approver.

Common rule patterns

Credit: customer active, exposure, overdue, guarantee, and order value. Inventory: item active, warehouse, owner, batch/serial, quality, expiry, shelf life, and available quantity. Tax: company, date, jurisdiction, item, partner, certificate, and code. Accounting: period, account, dimensions, currency, source, balance, and permission. Workflow: approver, amount, version, evidence, and segregation.

Imports and idempotency

Import rules validate schema, required fields, external ID, tenant/company scope, dates, currency, decimals, duplicate source, and referential integrity. Invalid rows return field path, code, message, and row key. Partial success policy must be explicit; a batch should not appear complete when rows failed.

Create and action requests use idempotency keys. A retry returns original result or a clear conflict. Replayed webhook or import must not duplicate document, stock, payment, or journal effects.

Rule telemetry and monitoring

Monitor evaluation count, pass rate, failure rate, override rate, age, owner, module, company, and version. A sudden drop in tax validation or rise in manual overrides is a control signal. Keep rule changes and deployment reference in configuration audit.

API behavior

Validation endpoints return status, rule code, field path, severity, actual, expected, evidence requirement, and correlation ID. Posting endpoints repeat critical checks server-side.

{"valid":false,"results":[{"code":"CREDIT_HOLD","severity":"ERROR",
 "field":"customerId","actual":"exposure=260000","expected":"<=250000",
 "action":"Obtain credit-manager approval","correlationId":"corr_0041"}]}

Test evidence

Each rule needs positive, negative, boundary, permission, effective-date, currency, company-isolation, retry, and reversal tests. Record fixture IDs, rule version, input, expected result, actual result, actor, timestamp, and downstream journal/stock effect.

Practice: test a credit limit at, below, and above threshold; AP price and quantity tolerance; expired tax certificate; quarantine batch; closed period; self-approval; duplicate POST; webhook replay; and currency rounding. Explain every field, rule precedence, message, override, evidence, API response, and audit event.

Related: Workflow and Approval field guide, Tax field guide, Inventory field guide, Audit and Compliance field guide, and API cookbook.