Opérations financières

Sous-workflows · limites déléguées

Le graphe de lot ne sait pas rapprocher une facture. Il éclate les factures du matin et appelle un second graphe une fois par facture — ce à quoi ressemble la décomposition ici : les règles de rapprochement sont un petit graphe qu’un analyste financier peut ouvrir, exécuter face à une seule facture, et modifier, sans toucher à la mécanique qui l’entoure.

Puis l’argent s’arrête. Au-dessus de la limite déléguée, l’exécution se gare sur une approbation ; le fichier de paiement est écrit après la libération, jamais à côté, si bien qu’un lot rejeté ne laisse rien derrière lui.

Comment les graphes fonctionnent

1. Une exécution enfant par facture

   Le parent suspendu dans la base de données plutôt que de retenir des threads.

2. Un rapprochement à trois voies

   Avec ses tolérances indiquées en haut du nœud.

3. Un jalon d’approbation au-dessus de la limite déléguée

   Avec le rejet câblé comme un résultat normal.

4. Un dossier de clôture

   Il dépose un véritable .xlsx dans le stockage d’objets du projet.

Sur le canevas

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

Il est livré avec le produit

Ce projet est livré avec DjiniousWorkflow. Une commande l’initialise, une autre exécute chaque graphe qu’il contient, et les captures ici proviennent de ces exécutions.

Là où un graphe s’appuie sur une fixture plutôt que sur un système en direct, il lit la fixture là où votre déploiement lirait une base de données — remplacez le nœud en tête et le reste du graphe ne change pas. Le travail du moteur — l’éclatement, le rassemblement, l’approbation, la publication — est celui du produit lui-même.