Purchase & Invoice Approval Workflow

Ihr Nutzen

Funktionen im Detail

The module dtx_approval blocks purchase.order.button_confirm() and account.move.action_post() (only in_invoice/in_refund) until all required approvals are in place. Amounts are aggregated per Analytic Account via analytic_distribution. For each branch the highest matching min_amount tier is determined and all stages within that tier are processed sequentially by sequence. Approvers are resolved per stage as a pool (any/all). A mail.activity is scheduled on the document itself for every open entry.

1. Roles and Permissions

Assign via Settings → Users → Groups: DTX Approval.

2. Configuring Approval Stages

Menu: Accounting → Configuration → Approval Stages

A stage is global per company and has the following fields:

• Name — Display name
• Sequence — Processing order (lower = earlier)
• Document Type — purchase, vendor_bill or both
• Minimum Amount — Threshold on branch level. Only the highest matching min_amount tier is used — lower tiers are discarded entirely.
• Approver Type:
  • Fixed Users — explicit user list in Approver Users
  • Fixed Group — all active users of a res.groups
  • Analytic Responsible — project manager plus the Approval Responsibles and all active members of Approval Groups configured on the analytic account; without an AA it falls back to the requester's HR manager
  • Requester's Manager — always resolves to the requester's HR manager
• Approver Mode:
  • any — the first approver closes the stage (natural substitution)
  • all — every approver must approve
• Activity Deadline (Days) — sets mail.activity.date_deadline; overdue activities appear in Odoo's standard overdue view.
• Active — a stage can be deactivated at any time.

Simple Example

In this simple example there is only one stage — every order (from 0 €) is approved by the analytic responsible.

Hierarchical Approval within a Price Tier

For amounts above a certain threshold, multiple approval levels can be processed sequentially. To achieve this, create several stages with the same min_amount. The sequence determines the order — the lowest sequence starts first; the next level is activated only after the previous one is completed.

Example: Three-level approval from 5,000 €

Flow for an order of 8,000 €:

1. Level 1 — Technical Review (Seq 10): The analytic responsible receives an activity immediately. Mode any → one approver is sufficient.
2. Level 2 — Controlling (Seq 20): Only after level 1 is completed do all members of the controlling group receive an activity. Mode all → every member must approve (in parallel, order within the level does not matter).
3. Level 3 — Management (Seq 30): Only after level 2 is completed does management receive an activity. Mode any → one member is sufficient.

Combining Multiple Price Tiers

You can define different hierarchies for different amounts. Since only the highest matching min_amount applies, separate tiers are formed:

• Amount < 5,000 €: Only "Project Manager" (min_amount = 0) applies — single-level approval.
• Amount ≥ 5,000 €: Only the three stages with min_amount = 5,000 apply — three-level hierarchical approval. The stage with min_amount = 0 is discarded.

3. Maintaining Analytic Accounts

Menu: Accounting → Configuration → Analytic Accounting → Analytic Accounts

The form contains two fields under Approval:

• Approval Responsibles — individual users who can approve documents for this analytic account.
• Approval Groups — user groups whose active members are automatically included as approvers.

Both serve as a fallback (or supplement) when the stage type is Analytic Responsible and are merged with any project managers linked to the analytic account into a single approver pool.

4. Workflow: Purchase Order / Vendor Bill

4.1 Requesting Approval

1. Create a purchase order or vendor bill in Draft, assign analytic_distribution to the lines.
2. Click Request Approval in the header.
3. The module:
   • aggregates the amount per analytic account (price_subtotal * distribution_pct / 100),
   • creates a Branch for each AA,
   • creates a Fallback Branch (analytic_account_id = False) for lines without distribution,
   • determines the highest matching min_amount tier per branch and activates all stages within it,
   • schedules mail.activity entries on the document for the first stage immediately.

The status field dtx_approval_state in the header shows pending.

4.2 Granting Approval

Assigned approvers see the activity on the document (purchase order or bill) in their My Activities view and in the chatter. The actions Approve / Refuse are available on the Approval Request form.

• Approve closes the activity, sets the entry to approved and posts a message in the chatter.
• With mode any, all remaining entries for the stage are automatically closed with the note "Auto-closed: another approver already approved this stage."
• After a stage is completed, activities for the next stage are scheduled automatically.

4.3 Refusal

4.4 Confirmation / Posting

• Purchase Order: button_confirm() is blocked until the associated request has status approved — otherwise a UserError is raised.
• Vendor Bill: action_post() is gated only for in_invoice and in_refund; customer invoices (out_invoice) are not affected.
• Only then is the original behaviour executed.

4.5 Subsequent Changes to the Document

After confirm/post, changes are no longer monitored — the request is preserved unchanged as a historical audit record.

5. Dashboards and Views

• Accounting → Approvals → Approval Requests: filtered by default to state pending. The filter "Waiting on me" shows only requests where the current user is listed as an approver in an open stage.
• Kanban view (default):
  • Requests are grouped by state with colour-coded borders (grey = draft, blue = pending, green = approved, red = refused).
  • Each card shows the document reference, requester, amount and date.
  • Approve and Refuse buttons are available directly on each card for quick action.
  • Columns follow the fixed order: Draft → Pending → Approved → Refused.
• List view: Available as an alternative view for a compact tabular overview of all requests.
• Request form view:
  • Header with statusbar draft → pending → approved/refused
  • Notebook Branches with totals per analytic account
  • Branch dialog lists entries per stage (approver, state, comment, approved-on)
  • Chatter at the bottom for the audit trail

6. Frequently Asked Questions

A user is both requester and approver — what happens?

Self-approval is blocked by _assert_can_act() (UserError). Exception: members of the group DTX Approval / Administrator.

What if no stage matches a document?

The request is immediately set to approved and confirmation can proceed without further steps.

Why is the "Request Approval" button not shown?

• For purchase.order: state must be draft or sent and no active request may exist.
• For account.move: the entry must be in_invoice/in_refund and still in draft.
• Additionally, at least one active stage for the matching document_type must exist, otherwise _dtx_needs_approval() returns False and the gate mechanism is disabled.

I need to substitute for an approver immediately.

Use the pool mechanism: set the stage type to fixed_group or fixed_users, add multiple users, mode any — the first approval is sufficient.

How can I manually cancel a request?

As a DTX Approval / Administrator, click Cancel on the request form. Activities are deleted and the request is set to refused.

7. Menu Overview

Accounting
+-- Approvals
|   +-- Approval Requests          (User + Admin)
+-- Configuration
    +-- Approval Stages            (Admin)

Analytic account form (Analytic Accounting): additional section Approval with fields Approval Responsibles and Approval Groups.

Interesse geweckt?

Lassen Sie sich unverbindlich beraten – wir zeigen Ihnen, wie dieses Modul in Ihre Prozesse passt.