Finance operations
Fatture abbinate ciascuna a un’esecuzione figlia, eccezioni spiegate anziché elencate, e nulla al di sopra del limite delegato rilasciato senza una firma.

Sub-workflow · limiti delegati
Il grafo batch non sa come abbinare una fattura. Distribuisce a ventaglio le fatture del mattino e chiama un secondo grafo una volta per fattura — è così che appare qui la scomposizione: le regole di abbinamento sono un piccolo grafo che un analista finanziario può aprire, eseguire su una singola fattura, e modificare, senza toccare il macchinario intorno.
Poi il denaro si ferma. Sopra il limite delegato l’esecuzione si parcheggia su un’approvazione; il file di pagamento viene scritto dopo il rilascio, mai accanto a esso, così un batch rifiutato non lascia nulla dietro di sé.
Il grafo di intake delle fatture

Come funzionano i grafi
Un’esecuzione figlia per fattura
Il genitore sospeso nel database anziché tenere occupati dei thread.
Un abbinamento a tre vie
Con le sue tolleranze indicate in cima al nodo.
Un gate di approvazione sopra il limite delegato
Con il rifiuto cablato come esito normale.
Un pacchetto di chiusura
Archivia un vero file .xlsx nell’object store del progetto.
Sul canvas
flow:callWorkflow · flow:approve · files:toXlsx · artifacts:put
Viene distribuito con il prodotto
Questo progetto viene distribuito con DjiniousWorkflow. Un comando lo popola, un altro esegue ogni grafo al suo interno, e le schermate qui provengono da quelle esecuzioni.
Dove un grafo si appoggia a un fixture anziché a un sistema live, legge il fixture nel punto in cui il tuo deployment leggerebbe un database — sostituisci il nodo in cima e il resto del grafo non cambia. Il lavoro del motore — il fan-out, la raccolta, l’approvazione, la pubblicazione — è quello proprio del prodotto.
Continua a esplorare



