Djinious
Finance operationsOperatività d’impresa

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.

DjiniousWorkflow
Un’esecuzione di DjiniousWorkflow sospesa su un’approvazione umana, con il batch in revisione nel pannello laterale e i controlli Approva e Rifiuta.

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

DjiniousWorkflow
Il canvas di DjiniousWorkflow che mostra un grafo di intake fatture a ventitré nodi, con un fan-out in una chiamata a sub-workflow, una raccolta, una ramificazione in eccezioni e debiti, e un gate di approvazione prima che il file di pagamento venga scritto.
Il grafo di intake fatture per intero. Ognuna di quelle chiamate figlie è una propria esecuzione, sospesa nel database anziché tenuta aperta in un worker.

Come funzionano i grafi

  1. Un’esecuzione figlia per fattura

    Il genitore sospeso nel database anziché tenere occupati dei thread.

  2. Un abbinamento a tre vie

    Con le sue tolleranze indicate in cima al nodo.

  3. Un gate di approvazione sopra il limite delegato

    Con il rifiuto cablato come esito normale.

  4. 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.