Djinious
Finance operationsEnterprise operations

Finance operations

Invoices matched one child run each, exceptions explained rather than listed, and nothing above the delegated limit released without a signature.

DjiniousWorkflow
A DjiniousWorkflow run suspended on a human approval, with the batch under review in the rail and Approve and Reject controls.

Sub-workflows · delegated limits

The batch graph does not know how to match an invoice. It fans the morning’s invoices out and calls a second graph once per invoice — which is what decomposition looks like here: the matching rules are one small graph a finance analyst can open, run against a single invoice, and change, without touching the machinery around it.

Then the money stops. Above the delegated limit the run parks on an approval; the payment file is written after the release, never beside it, so a rejected batch leaves nothing behind.

The invoice intake graph

DjiniousWorkflow
The DjiniousWorkflow canvas showing a twenty-three node invoice intake graph, with a fan-out into a sub-workflow call, a gather, branching into exceptions and payables, and an approval gate before the payment file is written.
The invoice intake graph in full. Each of those child calls is its own run, suspended in the database rather than held open in a worker.

How the graphs run

  1. One child run per invoice

    The parent suspended in the database rather than holding threads.

  2. A three-way match

    With its tolerances stated at the top of the node.

  3. An approval gate above the delegated limit

    With rejection wired as a normal outcome.

  4. A close pack

    It files an actual .xlsx in the project’s object store.

On the canvas

flow:callWorkflow · flow:approve · files:toXlsx · artifacts:put

It ships with the product

This project ships with DjiniousWorkflow. One command seeds it, another runs every graph in it, and the captures here came out of those runs.

Where a graph leans on a fixture rather than a live system, it reads the fixture where your deployment would read a database — swap the node at the top and the rest of the graph does not change. The engine work — the fan-out, the gather, the approval, the publish — is the product’s own.