Approval Workflow and Alert Designer

The problem: your approval rules are more complicated than the approval window allows

SAP Business One ships with approval procedures, and for simple cases they work. You pick a document, set a condition on a field like total or discount, name an approver, and the document waits. Where it runs out of road is the point at which almost every growing company arrives:

• Approval must depend on something the standard condition list does not expose — a project code in a UDF, a cost centre on the line, a Business Partner credit status, a budget balance for the period.
• Approval must escalate through levels by value: the department head to \$5,000, the finance director to \$25,000, the managing director above that — with the right level chosen automatically rather than by whoever remembers the policy.
• Approval must route by organisation, not by document — the requester's department decides who signs, and the same Purchase Order goes to a different approver depending on who raised it.
• Approvers are travelling and will not open the SAP client for two days, so a \$400 Purchase Order holds up a production line.
• Nobody chases anything, so requests sit in the queue until a supplier calls.

The result is a policy that exists on paper and is enforced by memory and email. Purchase Orders get raised after the goods arrive. Credit limits get overridden by whoever is nearest the keyboard. And at audit time nobody can produce a clean record of who approved what, when, and on what basis.

What ECOSIRE builds

We build a rule-driven approval and alert engine that runs inside your SAP Business One company database and complements — rather than fights — the native approval mechanism.

A rule builder your finance team can actually operate

Rules are defined in a maintained interface, not in code, and stored as User-Defined Objects over User-Defined Tables so they are secured, backed up and transported like any other SAP data. A rule combines:

• Document scope — Purchase Request, Purchase Order, A/P Invoice, Sales Order, A/R Credit Memo, Sales Quotation, Journal Entry, Goods Issue, Business Partner master or item master changes.
• Conditions — header or line values, gross or net total, discount percentage, gross-profit percentage, Business Partner group or credit status, item group, warehouse, cost centre, project, or any UDF you already use. Conditions combine with AND/OR and value ranges.
• Approver resolution — a named user, a role, the requester's department manager resolved from your employee master, or a dynamic lookup based on the document's own data.
• Level logic — sequential levels with value thresholds, parallel approvers with any-one or all-must-approve semantics, and automatic skip when the same person appears twice in a chain.

Approve from email or phone, not only from the SAP client

Every pending request generates a notification containing the document detail the approver needs to decide — supplier, amount, lines, requester, budget position — with approve and reject actions that work from an email client or a mobile browser. The action posts back through the Service Layer as a genuine approval decision recorded against the document, not as a note somebody has to re-key into SAP later. Rejections require a reason, and the reason is stored with the decision.

Escalation and delegation that runs itself

A request that sits unanswered past its threshold escalates to the next level or to a named deputy, with a reminder cadence you set per rule. Approvers can register planned absence with a delegate and a date range, so nothing stalls behind an out-of-office. Every escalation and delegation is logged.

Alerts beyond approvals

The same rule engine drives notification-only alerts, which is where most of the day-to-day value lands: a Sales Order raised for a Business Partner over its credit limit, an item dropping below minimum stock in a specific Warehouse, an A/P Invoice whose price differs from the Purchase Order beyond tolerance, a Sales Quotation approaching expiry, a Journal Entry posted to a restricted account, a Business Partner bank detail changed. Alerts go to SAP's internal messaging, to email, or both, on event or on schedule.

An audit trail that answers the question

Every decision writes an immutable record: document, rule, level, approver, delegate if any, decision, reason, timestamp, and the values the rule evaluated at the moment it fired. Reporting is available in-application and as Crystal Reports layouts, so the approval history of a document can be printed and filed with it.

Technical fit

Built for SAP Business One 10.0 on Microsoft SQL Server and SAP HANA, on-premise or cloud-hosted. Document interception and posting use the Service Layer, with the DI API used server-side where a document operation requires it. Where your existing native approval procedures already cover a case correctly, we leave them alone — the engine is designed to sit beside them, and part of the scoping work is deciding which rules stay native and which move.

Who this is for

SAP Business One sites where spend authority is genuinely tiered, where the approver depends on more than the document total, or where approvers are frequently away from the SAP client. Typically companies past the point where the owner signs everything: multi-department manufacturers and distributors, project-based businesses tracking cost centres, and any organisation whose auditors have asked for documented segregation of duties.

If your approval policy is one approver and one threshold, native SAP approval procedures already do that and we will tell you so rather than sell you a rule engine you do not need.

How delivery works

1. Scoping call. We document your actual approval matrix — every document type, threshold, approver, exception and escalation path — plus the alerts you want, your SAP version, database platform and hosting, and your email infrastructure. 2. Fixed quote. A written scope with a fixed price and delivery date. Nothing is built until you approve it. 3. Build. Rules are developed against your document types, your UDFs and your organisational structure, not a generic template. 4. Install in test. Installed into your test company database, where your real approvers run their real documents through the chain and you tune thresholds before anything binds live transactions. 5. Install in production. After sign-off, installed into the production company database, with the rule set enabled progressively — usually purchasing first — so the business is never blocked by an untested rule. 6. Support window. A defect-fix support period from go-live, extendable afterwards.

Typical lead time is one working week from approved quote, driven by how many document types and how many distinct rule paths are in the matrix. This is a build-to-order add-on: there is no ready-made package to download and no trial, because the value is in rules fitted to your authority matrix, and that matrix does not exist until we have written it down together.