Loading

Posting Actions and Guards

Posting actions are what happens when a document moves: the ledger journal when an invoice posts, the stock issue when a delivery ships, the budget commitment when an order is issued. Guards are posting actions that run before a move and can refuse it. Together they turn a status change into real bookkeeping, and they are where several features are switched on per document type.

Where to find it

Architect Panel → ERP - Setup:

  • Document Posting Actions — every posting action and guard; filter by document type
  • Document Types — the Posting row action opens one type's posting actions
  • Documents — the console: Types & health checks each one resolves, and Re-post re-fires one

What a row holds

  • Document Type.
  • Trigger: when it runs (see below).
  • Engine: which part of the ERP does the work, such as doc, ledger, stock, budget, match, sales, price, apprmx (approval matrix), edi or punch (PunchOut).
  • Action: what that engine does, such as post, issue, reserve, check or send_order.
  • Config: settings for the action, written as a short JSON object.
  • Order: the order rows with the same trigger run in.

Triggers

  • A posting trigger name, such as post, commit, confirm or reverse: runs when a transition whose Posting Trigger has that name is made.
  • pre:status: a guard, run before the document enters that status. If it refuses, the move does not happen.
  • pre:convert:type and pre:create: guards before converting into a type, or creating a document.
  • converted:type: after a conversion, usually moving the source on (a requisition to Ordered).
  • entered:status: after the document enters a status, such as handing quantities back on Cancelled, or withdrawing open approvals at a dead end.

Posting is part of the move. If any action fails, the move is refused and nothing changes: "Not moved to '...' - posting failed, so nothing was changed: ..." followed by the engine's reason.

Shipped guards worth knowing

  • Credit check on confirming a sales order (customer on stop, credit limit).
  • Budget check on issuing a purchase order.
  • Priced lines on submitting a requisition: a line with a quantity and no price is refused. Remove the row to switch this off.
  • Required slots on posting a credit note: the reason must be filled in.
  • Duplicate on submitting or approving a supplier invoice; set its Config to {"require_reference":1} to make the supplier's invoice number mandatory as well.
  • Match on approving a supplier invoice, when a match policy applies.
  • Link state guards that stop a delivery or receipt being reversed once billed, and stop an order being marked Fully received before its receipts cover it.

Features you switch on here

  • PunchOut order transmission: add a row on the Purchase Order type with Trigger commit, Engine punch and Action send_order to queue issued orders back to PunchOut suppliers (see PunchOut Procurement).
  • EDI purchase orders: the shipped row that sends an 850 or ORDERS when an order is issued is switched off in its Config; most installations instead tick Send purchase orders automatically on each EDI partner (see EDI & Trading Partners).

Checking and re-posting

  1. After any change, open the Documents console's Types & health tab. Each posting row shows Resolves to and Available; an unavailable engine would fail every posting.
  2. To re-run a posting action for one document, open it on the Documents tab and use Re-post. Actions that hand quantities back are refused unless the document is actually at the status they belong to, so Re-post cannot release a live document's quantities.

What goes wrong

  • "Not moved ... posting failed": read the reason; it is usually a missing account, rate or setting in the engine named.
  • A move is refused by a guard nobody expected: find the pre: row for that status on the type and read its Config.
  • Engine not available: the engine named is not installed on this system, or the code is misspelt.

Worked example

A company wants PunchOut orders sent automatically. The architect opens Document Types, uses Posting on Purchase Order and adds a row: Trigger commit, Engine punch, Action send_order, Order 50. Types & health shows the row resolves. The next order issued to a PunchOut supplier is queued for the PunchOut Order Transmission task.

Recommendations

  • Add rows rather than editing shipped ones, and note why.
  • Prefer guards for controls: a guard refuses before anything changes.
  • Check Types & health after every change.
  • Use Re-post sparingly and only after fixing the cause.