HelperStable

Get payment allocations

Charge les affectations du paiement ou du document à partir d’un objet plateforme déjà présent dans le processus.

paiement ou document commercial

Get payment allocations

Relation métier

affectations de paiement

Vue d’ensemble

get_payment_allocations suit une relation canonique Ormuz au lieu de demander au designer de transporter ou reconstruire des identifiants techniques entre objets.

Exemple

Le processus possède un paiement ou document commercial et doit travailler sur ses affectations de paiement. Le node résout la relation à partir de l’objet source et retourne des objets plateforme directement utilisables.

Paramètres 3

resourceRequisPayment

Objet paiement ou document commercial dont le node doit résoudre les relations. Le type doit être payment, psp_payment, supplier_payment, invoice, supplier_invoice, order ou purchase_order ; les avoirs sont reconnus automatiquement.

statusOptionnelenum

Filtre optionnel sur le statut métier des ressources retournées.

limitOptionnelinteger

Nombre maximal de ressources retournées dans cette lecture. Utilisez has_more pour savoir si d’autres résultats existent.

Sorties 3

payment_allocationsPayment allocation[]

Affectations de paiement actuellement reliés à la source selon les filtres configurés.

countinteger

Nombre de affectations de paiement présents dans cette sortie.

has_moreboolean

Indique si d’autres affectations de paiement existent au-delà de la page retournée.

Comportement

Les résultats sont triés du plus récent au plus ancien, avec un ordre stable à date identique. La limite vaut 20 par défaut, au maximum 100. Une affectation couvrant plusieurs documents est renvoyée entière, avec toutes ses lignes, une seule fois.

Valider la source

Le node exige un paiement ou document commercial adressable avec un ID. Les sources supportées sont payment, psp_payment, supplier_payment, invoice, supplier_invoice, order ou purchase_order ; les avoirs sont reconnus automatiquement.

Résoudre la relation

Ormuz recherche les affectations de paiement liés selon la relation métier et les filtres configurés.

Exposer les résultats

Les affectations de paiement deviennent disponibles pour les bindings en aval, avec has_more lorsque la lecture est volontairement bornée.

Limites et responsabilités

Le node ne crée ni ne modifie les ressources reliées ; il lit une relation existante.
Une collection vide est un résultat valide lorsque la relation ne contient actuellement aucun objet.
La lecture est bornée par limit ; si has_more vaut true, cette sortie ne représente pas l’historique exhaustif.