Priority ERP

Vendor: Priority Software · Mid-Market

Priority ERP (by Priority Software, Israel) is a mid-market ERP suite covering financials, sales/order management, procurement, inventory & logistics, manufacturing, project management, service management, and HR/payroll. The application is database-centric, running on Oracle or Microsoft SQL Server, and exposes its data through ODBC (the officially documented data-access path), a JSON REST API with OIDC/OAuth2, webhooks, and a Web SDK. Entities are PRIORITY 'forms' backed by real database tables; subforms are reached via ODBC as parent_sep_subform. Coverage here is partial: only entities substantiated by the public developer portal are asserted; the rest are flagged for in-app confirmation (see script header).

Accounts Payable (AP)

Vendor invoices, payments, settlements

Activities

Receive Supplier Invoice - A supplier invoice is received; DOCUMENTS_P records it as a supplier-invoice document type keyed by PDOLNO/PDOCNO.
Enter Supplier Invoice - The invoice is keyed against SUPPLIERS (SUPPLIER key) with amount, date and currency.
Approve Supplier Invoice - The invoice is approved for posting (control step against the vendor master SUPPLIERS).
Post Creditor Invoice to Ledger - The approved invoice posts to the AP ledger; debits/credits flow to TRANS against ACCOUNTS.
Run Payment Proposal - Due supplier invoices are selected for payment by a payment proposal run.
Execute Supplier Payment - Payment is made to SUPPLIERS; DOCUMENTS_P carries the payment document, the cash/bank account posts via TRANS.
Clear Supplier Invoice - The supplier invoice is cleared against its payment; AP closure posts to TRANS/ACCOUNTS.
Post AP to General Ledger - Posted AP transactions are transferred to the General Ledger (TRANS to ACCOUNTS).

Case attributes

Amount (number) - DOCUMENTS_P.TOTAL - the invoice/payment amount.
Document Number (string) - DOCUMENTS_P.PDOCNO - the supplier invoice/payment document number.
Supplier (string) - SUPPLIERS.SUPPLIER - the vendor key on the invoice and payment.
Supplier Name (string) - SUPPLIERS.SUPNAME - the vendor display name.
Currency (string) - SUPPLIERS.CURRENCY / invoice currency.
Invoice Date (date) - DOCUMENTS_P.CURDATE - the supplier invoice date.

Process-mining benefits (historical)

Invoice-to-approval lag [Efficiency]: Measure the time from Receive Supplier Invoice to Approve Supplier Invoice by SUPPLIERS.SUPPLIER to surface approval bottlenecks.
Duplicate supplier invoices [Cash]: Detect the same DOCUMENTS_P.PDOCNO/L supplier invoice entered twice before Post Creditor Invoice to Ledger to stop double payment.
Unapproved-invoice backlog [Cost]: Count supplier invoices stuck before Approve Supplier Invoice close to a due date, risking late-payment cost.
Days payable outstanding [Cash]: Measure Receive Supplier Invoice to Execute Supplier Payment duration per SUPPLIERS to see who is being paid early vs late.
Unmatched payments [Compliance]: Track Execute Supplier Payment rows never reaching Clear Supplier Invoice, leaving open AP and on-account balances.
AP-to-GL posting lag [Efficiency]: Measure the gap from Clear Supplier Invoice to Post AP to General Ledger so period-close books on time.

Process-mining benefits (action)

Due-soon payment worklist [Cash]: Show AP every supplier invoice past Run Payment Proposal but not yet Execute Supplier Payment, ordered by due date.
Duplicate-invoice blocker [Cash]: Block Post Creditor Invoice to Ledger when a matching DOCUMENTS_P.PDOCNO + SUPPLIERS.SUPPLIER invoice already exists and alert the clerk.
Early-payment discount alert [Cash]: Surface supplier invoices with early-payment terms queued for Run Payment Proposal before the discount window closes.
Auto-clear matching trigger [Efficiency]: On Execute Supplier Payment, auto-match to the supplier invoice and run Clear Supplier Invoice without manual posting.
Pending-approval queue [Service]: Show the controller every supplier invoice waiting on Approve Supplier Invoice each morning to keep payments moving.
Period-close checklist [Compliance]: Block period close when unposted AP (TRANS/ACCOUNTS) remains and publish the ready-to-close signal.

Data tables

SUPPLIERS - Supplier master (from product literature, NOT substantiated by the cited developer-portal pages - confirm in-app)

Accounts Receivable (AR)

Customer invoices, receipts, collections

Activities

Generate Customer Invoice - An AINVOICES row is created; IVNUM is the invoice number, CUST references CUSTOMERS.CUSTNAME.
Attach Signed Invoice - A digitally-signed invoice file is attached in EXTFILES (EXTFILENUM/EXTFILENAME), per /api/doc_examples.
Post Invoice to AR - The AINVOICES invoice is posted to the AR ledger; debits/credits flow to TRANS against ACCOUNTS.
Send Invoice to Customer - The invoice is issued to the customer; DOCUMENTS_P may carry the customer invoice document type.
Enter Customer Payment - A customer payment is recorded; DOCUMENTS_P holds the receipt document, linked to the customer via CUST.
Apply Cash to Invoice - The payment is matched against the AINVOICES.IVNUM invoice it settles.
Clear Invoice - The invoice is cleared against its payment; the AR closure posts to TRANS/ACCOUNTS.
Post AR to General Ledger - Posted AR transactions are transferred to the General Ledger (TRANS to ACCOUNTS), closing the AR loop.

Case attributes

Amount (number) - AINVOICES.TOTAL - the invoice total in the invoice currency.
Document Number (string) - DOCUMENTS_P.PDOCNO - the receipt/invoice document number.
Invoice Number (string) - AINVOICES.IVNUM - the posted customer invoice number.
Customer (string) - CUSTOMERS.CUSTNAME - the customer key on the invoice and receipt.
Currency (string) - AINVOICES.CURRENCY - the invoice currency.
Invoice Date (date) - AINVOICES.IVDATE - the invoice posting date.

Process-mining benefits (historical)

Invoice ageing by customer [Cash]: Measure the time from Post Invoice to AR to Clear Invoice per CUSTOMERS.CUSTNAME to find the slow-paying accounts stretching receivables.
Dispute and credit-note loops [Compliance]: Count re-issuances and credit notes around Clear Invoice that signal disputes or AR posting errors in the invoice-to-cash chain.
Missing signed-invoice attach [Compliance]: Find AINVOICES rows whose EXTFILES attachment never landed, so the signed copy was never sent to the customer.
Unapplied cash [Cash]: Quantify payments recorded via Enter Customer Payment that never reached Apply Cash to Invoice, leaving open invoices and on-account balances.
AR-to-GL posting lag [Efficiency]: Track the delay from Clear Invoice to Post AR to General Ledger so period-close books on time.
Invoice cycle time [Efficiency]: Measure end-to-end Generate Customer Invoice to Clear Invoice cycle time per rep to surface bottlenecks in billing.

Process-mining benefits (action)

Aged-receivables worklist [Cash]: Show finance the ageing of unpaid AINVOICES by customer each day so collections chase the right accounts first.
Missing-attachment alert [Compliance]: Flag every posted AINVOICES row with no EXTFILES attachment so the signed copy is sent before the dunning cycle starts.
Auto-cash matching trigger [Efficiency]: On Enter Customer Payment, auto-match the receipt to the AINVOICES.IVNUM invoice and run Apply Cash to Invoice without manual posting.
On-account cash queue [Service]: Surface payments that could not be auto-applied so an AR clerk reviews and clears them the same day.
Dunning trigger by ageing bucket [Service]: Auto-send a dunning DOCUMENTS_P letter to CUSTOMERS whose AINVOICES cross an ageing threshold each morning.
Period-close checklist [Compliance]: Block Close Period when unposted AR (TRANS/ACCOUNTS) remains, then publish the ready-to-close signal to the controller.

Data tables

AINVOICES - Archive of sales invoices; IVNUM is the invoice number (confirmed in /api/doc_examples)
CUSTOMERS - Customer master; key field CUSTNAME (confirmed: example "CUSTNAME":"T000032")
EXTFILES - External file attachments (digitally signed invoices, etc.) - portal examples attach under AINVOICES

General Ledger (GL)

Journal entries, chart of accounts, financials

Activities

Create Journal Voucher - A new TRANS transaction header is opened (TRANSNO) for manual journal entry.
Enter Journal Lines - Debit/credit lines are entered into TRANS against ACCOUNT keys (ACCOUNTS.ACCOUNT); each line carries DEBIT/CREDIT/CURDATE/REF.
Authorize Journal - The journal is reviewed and authorised for posting (control step before it hits the ledger).
Post to General Ledger - The TRANS transaction is posted; ACCOUNTS balances are updated from the debit/credit lines.
Reconcile GL Control Accounts - Control accounts in ACCOUNTS are reconciled against their sub-ledgers to prove they tie.
Close Accounting Period - The accounting period is closed on ACCOUNTS/TRANS, preventing further postings to the closed period.

Case attributes

Credit Amount (number) - TRANS.CREDIT - the credit posted on the line.
Debit Amount (number) - TRANS.DEBIT - the debit posted on the line.
Account (string) - TRANS.ACCOUNT / ACCOUNTS.ACCOUNT - the G/L account key on each journal line.
Transaction Number (string) - TRANS.TRANSNO - the journal transaction number.
Reference (string) - TRANS.REF - the free-text reference on the journal line.
Posting Date (date) - TRANS.CURDATE - the posting date of the transaction.

Process-mining benefits (historical)

Journal backlog by preparer [Efficiency]: Measure journals stuck between Create Journal Voucher and Authorize Journal per preparer to find the bottleneck before the books close.
Out-of-balance journals [Compliance]: Detect TRANS transactions whose DEBIT and CREDIT totals do not match before Post to General Ledger so the ledger is never corrupted.
Manual-journal concentration [Cost]: Find ACCOUNTS.ACCOUNT keys that attract disproportionate manual Create Journal Voucher activity - candidates for automation or controls.
Reconciliation breaks [Compliance]: Track how often Reconcile GL Control Accounts surfaces a break between a control ACCOUNTS.ACCOUNT and its sub-ledger.
Post-to-close lag [Efficiency]: Measure the gap from Post to General Ledger to Close Accounting Period; long lags delay financial reporting.
Reworked journals [Cost]: Count TRANS transactions re-opened or re-posted after authorisation - a sign of weak review or wrong coding.

Process-mining benefits (action)

Pending-authorisation queue [Service]: Show the controller every journal waiting on Authorize Journal each morning so the books move that day.
Imbalance blocker [Compliance]: Block Post to General Ledger on any TRANS whose debit/credit totals differ, and alert the preparer immediately.
High-value-journal alert [Cost]: Flag any single Create Journal Voucher whose absolute DEBIT/CREDIT crosses a threshold for second-line review before posting.
Period-close checklist [Compliance]: Block Close Accounting Period when unposted or unreconciled TRANS/ACCOUNTS rows remain, then publish the ready-to-close signal.
Recurring-entry trigger [Efficiency]: Auto-suggest a Create Journal Voucher for known recurring ACCOUNTS postings due in the current period.
Late-posting monitor [Compliance]: Alert the controller when TRANS.CURDATE falls in a prior closed period so back-postings are reviewed not buried.

Data tables

ACCOUNTS - Chart of accounts master (standard Priority module form - NOT portal-confirmed; verify in-app)
TRANS - Posted accounting transactions / journal lines (standard Priority GL module form - NOT portal-confirmed; verify in-app)

Inventory Management (INV)

Stock movements, transfers, adjustments, valuation

Activities

Connect Part to Warehouse - A part (LOGPART.PARTNAME) is connected to a warehouse master record so stock can be held.
Create Planned Inventory Transaction - A planned inbound or outbound inventory movement is created for a PARTNAME part.
Confirm Receipt Line - An inbound line is received against LOGPART (goods in from purchase or production).
Confirm Putaway - Received stock is put away to its warehouse location against LOGPART.
Pick Inventory - Stock is picked against demand (order lines move stock out of LOGPART).
Confirm Shipment - Picked stock is shipped; a DOCUMENTS_P shipment row records the outbound movement.
Execute Inventory Transfer - Stock is moved between warehouses; LOGPART balances adjust in both locations.
Process Cycle Count - A cycle count is performed against LOGPART and discrepancies post as adjustments.

Case attributes

Quantity (number) - ORDERITEMS.QUANT - the moved quantity on the order line (column name in-app-confirmed).
Part Number (string) - LOGPART.PARTNAME - the part number.
Warehouse (string) - LOGPART.WAREHOUSE - the warehouse location (in-app-confirmed).
Transaction Type (string) - Inbound / outbound / transfer / count - the kind of inventory movement.
Movement Date (date) - DOCUMENTS_P.CURDATE - the date of the inbound or outbound movement.

Process-mining benefits (historical)

Putaway latency [Cost]: Measure Confirm Receipt Line to Confirm Putaway duration by part to slow inbound handling.
Pick-to-ship turnaround [Service]: Track Pick Inventory to Confirm Shipment time per warehouse to find sites that miss the ship promise.
Stock-out frequency [Service]: Count Pick Inventory attempts that fail because LOGPART has no stock for PARTNAME, breaking order fulfilment.
Cycle-count accuracy [Compliance]: Measure the discrepancy rate surfaced by Process Cycle Count against LOGPART balances.
Dead stock [Cost]: Find LOGPART parts with no Confirm Shipment movement in the analysis window - candidates for write-down.
Transfer lead time [Efficiency]: Measure Execute Inventory Transfer duration between warehouses to find the slow movers that starve demand sites.

Process-mining benefits (action)

Low-stock pick alert [Service]: Flag Pick Inventory for a PARTNAME whose LOGPART balance is at or below the safety threshold so a transfer or purchase is triggered.
Receiving backlog worklist [Cost]: Show Goods-In every part waiting on Confirm Putaway past the SLA each shift.
Cycle-count schedule [Compliance]: Push the next Process Cycle Count by parts whose LOGPART balance has not been counted within the cycle window.
Transfer trigger on demand [Efficiency]: Auto-suggest an Execute Inventory Transfer when a demand site's LOGPART balance falls below safety stock and a source site has surplus.
Dead-stock review queue [Cost]: Surfaces LOGPART parts with no Confirm Shipment movement for review or write-down each period.
Discrepancy follow-up [Compliance]: Route every Process Cycle Count discrepancy to an investigator before the adjustment posts to LOGPART.

Data tables

LOGPART - Part logistics/master form (the surfaced form). PARTNAME is the part number (confirmed in /api/form_examples). The portal shows PART as the underlying SDK table; there is no separate PARTS form, and CHUNIT is a procedure (not a column), so neither is modeled.

Order-to-Cash (O2C)

Full sales cycle from quote through payment receipt

Activities

Create Sales Order - A sales order header is opened in the ORDERS form; ORDNAME carries the order number (portal filter ORDNAME - SO19001473).
Add Order Lines - Order lines entered as the ORDERITEMS subform of ORDERS; via ODBC reached as ORDERS_sep_ORDERITEMS, keyed by PARTNAME.
Approve Sales Order - ORDERS row released for fulfilment; status field STATDES advances on approval (DOCTODOLIST carries the to-do entry).
Allocate Inventory - Parts required by the lines are allocated against LOGPART (PARTNAME stock); basis for the warehouse pick list.
Confirm Picking - Warehouse confirms the pick; DOCTODOLIST.STATDES reflects the picked status for the order line.
Confirm Shipment - Goods shipped; a DOCUMENTS_P row (PDOCNO) records the shipment/delivery document (confirmed on /webhooks).
Post Invoice - An AINVOICES row is posted; IVNUM is the invoice number. DOCUMENTS_P carries the customer invoice document type.
Receive Customer Payment - Customer payment recorded; DOCUMENTS_P holds the receipt document, reconciled against the invoice via PDOCNO/CUST.
Clear Invoice - Invoice is cleared against the payment; the matching posts to TRANS/ACCOUNTS (G/L), closing the order-to-cash loop.

Case attributes

Document Number (string) - DOCUMENTS_P.PDOCNO - the unified document number for shipments/invoices/receipts.
Invoice Number (string) - AINVOICES.IVNUM - the posted invoice number, present once invoiced.
Order Number (string) - ORDERS.ORDNAME - the sales order number carried on every order header.
Customer (string) - CUSTOMERS.CUSTNAME - the customer key on the order and invoice.
Order Status (string) - ORDERS.STATDES / DOCTODOLIST status description - where the order sits in fulfilment.
Order Date (date) - ORDERS.CURDATE - the date the sales order was entered.

Process-mining benefits (historical)

Quotation-to-order lag [Efficiency]: Orders often wait between quotation and Convert Quotation to Order; quantify the lag per rep to surface stalled deals before revenue slips.
Approval bottleneck [Efficiency]: Pin which approver or credit rule holds up Approve Sales Order longest so release-to-fulfilment is unblocked.
Picking turnaround [Cost]: Track Confirm Picking latency per warehouse and shift to find the sites that stretch the order-to-ship promise.
Shipment on-time conformance [Service]: Compare Confirm Shipment timing against the customer promise date; DOCUMENTS_P shipment rows are the system of record.
Days sales outstanding [Cash]: Measure the gap from Post Invoice to Receive Customer Payment per customer to find the slow payers stretching cash.
Invoice-to-cash rework [Compliance]: Count credit notes and re-issuances around Clear Invoice that signal disputes or posting errors in the order-to-cash chain.

Process-mining benefits (action)

Live credit-hold worklist [Service]: Surface every ORDERS row blocked at Approve Sales Order each morning so credit holds get released the same day.
Open-order release alert [Efficiency]: Alert the warehouse when Allocate Inventory has run but Confirm Picking has not within the SLA window.
Pick backlog worklist [Cost]: Give pickers a prioritised list of lines waiting on Confirm Picking, ordered by customer promise date.
Shipment exception monitor [Service]: Flag Confirm Shipment rows missing their DOCUMENTS_P payload or attached EXTFILES so exceptions are caught before the customer notices.
Aged-receivables dashboard [Cash]: Show finance the ageing of unpaid AINVOICES by customer each day so collections chase the right accounts first.
Auto-clear matching trigger [Efficiency]: On Receive Customer Payment, auto-match to the invoice and run Clear Invoice so the order closes without manual posting.

Data tables

CUSTOMERS - Customer master; key field CUSTNAME (confirmed: example "CUSTNAME":"T000032")
ORDERITEMS - Sales order lines subform. Via ODBC it is reached as ORDERS_sep_ORDERITEMS (NOT a standalone table). Confirmed on /odbc. Line fields (quantity/price) are NOT portal-confirmed.
ORDERS - Sales orders header; order number column ORDNAME (confirmed: filter ORDNAME - SO19001473)
DOCTODOLIST - Document/order status to-do list (confirmed in /api/doc_examples). Columns are NOT portal-confirmed; the webhook example uses OWNERLOGIN, so none are asserted here.
DOCUMENTS_P - Priority document form over the DOCUMENTS base table (type-condition form per the SDK conditions page); PDOCNO confirmed in the /webhooks shipment flow. Document-type/module semantics are NOT established by the portal - confirm in-app. Linked to O2C for the shipment evidence only.
EXTFILES - External file attachments (digitally signed invoices, etc.) - portal examples attach under AINVOICES

Procure-to-Pay (P2P)

Full procurement cycle from requisition through invoice payment

Activities

Raise Purchase Requisition - A purchase requirement is raised for a PARTNAME part against a SUPPLIERS vendor.
Create Purchase Order - A purchase order is created in the ORDERS form (purchase type), keyed by ORDNAME against SUPPLIERS.
Approve Purchase Order - The purchase order is approved for sending to the supplier.
Receive Goods - Goods are received; a DOCUMENTS_P Goods Receiving Voucher (PDOCNO) records the receipt (confirmed by the SDK conditions page).
Put Away Received Goods - Received parts are put away against LOGPART stock (PARTNAME).
Match Invoice to Goods Receipt - The supplier invoice is matched to the received quantity on the DOCUMENTS_P GRV and the ORDERS lines (3-way match).
Authorize Supplier Invoice - The matched supplier invoice is authorised for payment.
Execute Supplier Payment - Payment is made to SUPPLIERS; DOCUMENTS_P carries the payment document.
Clear Supplier Invoice - The supplier invoice is cleared against payment, closing the procure-to-pay loop.

Case attributes

Document Number (string) - DOCUMENTS_P.PDOCNO - the goods receipt / invoice / payment document.
Part (string) - ORDERITEMS.PARTNAME / LOGPART.PARTNAME - the purchased part.
Purchase Order (string) - ORDERS.ORDNAME - the purchase order number.
Supplier (string) - SUPPLIERS.SUPPLIER - the vendor key on the order and invoice.
Order Status (string) - ORDERS.STATDES - the purchase order status.
Receipt Date (date) - DOCUMENTS_P.CURDATE - the goods receipt date.

Process-mining benefits (historical)

Requisition-to-PO lag [Efficiency]: Measure the time from Raise Purchase Requisition to Create Purchase Order to find slow buyers delaying supply.
PO approval bottleneck [Efficiency]: Track which approver holds Approve Purchase Order longest by SUPPLIERS so release is unblocked.
Goods-receipt vs PO variance [Cost]: Compare Receive Goods quantities on DOCUMENTS_P against the ORDERS lines to find short or over deliveries.
3-way match failures [Compliance]: Count supplier invoices that fail Match Invoice to Goods Receipt - PO, GRV, and invoice disagree - before payment.
Supplier lead-time variability [Service]: Measure Create Purchase Order to Receive Goods duration per SUPPLIERS to flag unreliable vendors.
Unmatched payments [Cash]: Track Execute Supplier Payment rows never reaching Clear Supplier Invoice, leaving open AP and duplicate-payment risk.

Process-mining benefits (action)

Open-PO receiving alert [Service]: Flag purchase orders where Approve Purchase Order has run but Receive Goods is overdue against the promised date.
3-way-match dashboard [Compliance]: Show AP every supplier invoice pending Match Invoice to Goods Receipt with its GRV and PO links each morning.
Duplicate-PO blocker [Cost]: Block Create Purchase Order when an open ORDERS to the same SUPPLIERS for the same PARTNAME already exists.
Due-soon payment worklist [Cash]: Surface authorised supplier invoices queued for Execute Supplier Payment ordered by due date.
GRV-not-invoiced monitor [Cost]: Flag Receive Goods rows with DOCUMENTS_P GRV but no matched supplier invoice within the term, to chase credits or invoices.
Auto-clear on payment [Efficiency]: On Execute Supplier Payment, auto-match and run Clear Supplier Invoice so the order closes without manual posting.

Data tables

SUPPLIERS - Supplier master (from product literature, NOT substantiated by the cited developer-portal pages - confirm in-app)

Project Management (PM)

Project definition, WBS elements, networks, costs

Activities

Create Project - A project is created in the PROJECTS form (PROJECT key, PROJECTNAME/PROJECTDES) per the Project Management module.
Define Project Tasks - The project's tasks/WBS are defined against PROJECTS to structure the work and cost roll-up.
Record Project Transaction - Costs (materials, time, expenses) are recorded against PROJECTS for a task, accumulating project cost.
Invoice Project - Billable project transactions are invoiced to the customer (revenue against PROJECTS); DOCUMENTS_P may carry the billing document.
Post Project to General Ledger - Project cost and revenue are posted to the General Ledger (TRANS to ACCOUNTS), recognising the project result.
Close Project - The project is closed in PROJECTS once billing and posting are complete.

Case attributes

Amount (number) - The transaction/billing amount recorded against the project.
Project (string) - PROJECTS.PROJECT - the project key.
Project Name (string) - PROJECTS.PROJECTNAME - the project display name.
Task (string) - The project task/WBS element.
Project Date (date) - PROJECTS.CURDATE - the project/start date.

Process-mining benefits (historical)

Cost-to-budget by project [Cost]: Compare accumulated Record Project Transaction against the planned budget per PROJECTS.PROJECT to find overrun projects early.
Unbilled services [Cash]: Track Record Project Transaction rows that never reach Invoice Project, leaving revenue unbilled and cash delayed.
Project cycle time [Efficiency]: Measure Create Project to Close Project duration by project type to find admin drag at the tail.
Margin erosion [Cash]: Compare Invoice Project revenue to Record Project Transaction cost per PROJECTS to surface projects losing margin.
Unposted project results [Compliance]: Detect Invoice Project rows never reaching Post Project to General Ledger so period results are incomplete.
Task completion lag [Efficiency]: Measure Define Project Tasks to Record Project Transaction gap to find projects slow to start work.

Process-mining benefits (action)

Overrun-project worklist [Cost]: Show PM every project whose Record Project Transaction has crossed its budget threshold before more cost is committed.
Unbilled-revenue alert [Cash]: Surface billable Record Project Transaction rows not yet Invoice Project so they are billed this period.
Close-pending sweep [Compliance]: List projects with Invoice Project and Post Project to General Ledger done but not Close Project each period.
Period-close checklist [Compliance]: Block Close Period when unposted Post Project to General Ledger rows remain against any PROJECTS.
Margin dashboard [Cash]: Show finance the live margin (Invoice Project revenue minus Record Project Transaction cost) per project so eroders are visible.
Stalled-start monitor [Service]: Flag projects past Define Project Tasks with no Record Project Transaction within the start SLA so they are chased.

Data tables

PROJECTS - Project master (from product literature, NOT confirmed by the developer portal - treat as in-app-unconfirmed)

Production/Manufacturing (PROD)

Production orders, BOM, routing, shop floor execution

Activities

Define Work Pattern - A work pattern is defined (WORKPAT / WORKPATNAME / WORKPATDES) describing the shift pattern for work centers (confirmed on /odbc).
Assign Pattern to Work Center - The work pattern is applied to a work center (WORKC / WORKCNAME / WORKCDES) to set its operating schedule (confirmed on /odbc).
Create Production Order - A production order is created for a part (LOGPART.PARTNAME) to be made on a work center.
Release Production Order - The production order is released to the shop floor for execution.
Stage Materials - The input parts (LOGPART.PARTNAME) are staged at the work center for the order.
Report Operation Completed - An operation on the WORKC work center is reported complete for the production order.
Report Production Receipt - Finished goods are received back into LOGPART stock (PARTNAME) from the completed production order.
Close Production Order - The production order is closed once the finished quantity is received and operations are complete.

Case attributes

Part (string) - LOGPART.PARTNAME - the part being produced or consumed.
Production Order (string) - The production order reference.
Work Pattern (string) - WORKPAT.WORKPAT - the shift pattern applied to the work center.
Work Center (string) - WORKC.WORKC - the work center key executing the operation.
Operation Status (string) - Where the production order sits in execution.

Process-mining benefits (historical)

Work-center utilization [Cost]: Measure how much of the WORKC schedule (set by Assign Pattern to Work Center) is spent on Report Operation Completed vs idle, to right-size capacity.
Schedule vs actual variance [Service]: Compare planned Report Operation Completed timing on WORKC against actual to find the work centers that slip schedules.
Material staging delays [Cost]: Track Stage Materials lag before Report Operation Completed to find parts (LOGPART.PARTNAME) that starve production.
Throughput per work center [Efficiency]: Count Report Production Receipt quantity per WORKC over time to rank and rebalance the shop floor.
Order close lag [Compliance]: Measure Report Production Receipt to Close Production Order time to find unfinished admin that delays order closure.
Rework on operations [Cost]: Count operations reopened after Report Operation Completed - a sign of quality issues on a WORKC.

Process-mining benefits (action)

Late-order worklist [Service]: Show production control every production order past its Report Operation Completed due date, by WORKC, each shift.
Material-shortage alert [Cost]: Flag Stage Materials that cannot find the LOGPART.PARTNAME input so procurement is triggered before the work center idles.
Work-center capacity dashboard [Efficiency]: Show each WORKC's booked vs available hours under its Assign Pattern to Work Center schedule so overload is visible.
Auto-receipt trigger [Efficiency]: On the last Report Operation Completed, auto-run Report Production Receipt so finished goods hit LOGPART without manual delay.
Idle-work-center monitor [Cost]: Surface WORKC with no Report Operation Completed within its shift window for immediate load reassignment.
Close-order sweep [Compliance]: List production orders with Report Production Receipt done but not Close Production Order so they are closed the same day.

Data tables

WORKC - Work centers (confirmed on /odbc: WORKC, WORKCNAME, WORKCDES)
WORKPAT - Work patterns applied to work centers (confirmed on /odbc: WORKPAT, WORKPATNAME, WORKPATDES)

Explore this interactively in the mindzie Knowledge Base.