Synchronisation des documents

Ce qui a changé de ce côté de l’espace de travail, du plus ancien au plus récent. Un événement nomme un document, jamais son contenu : lisez le document avec l’opération correspondante, pour toujours obtenir sa version actuelle. Renvoyez nextCursor comme after lors de votre prochain appel ; tant que hasMore vaut true, rappelez immédiatement. Les événements sont conservés 30 jours et livrés au moins une fois, si bien qu’un même changement peut arriver deux fois ; les 5 dernières secondes attendent l’appel suivant. Un appelant fournisseur reçoit purchase_order.issued, changed, canceled et rejected, invoice.received, approved, rejected, paid, payment_withdrawn, remittance_sent et credit_applied, invoice.updated (un acheteur a mis la facture en attente de vérification, ou l’a libérée : lisez GetInvoiceStatus), ainsi que credit_note.accepted et rejected. Un appelant acheteur reçoit invoice.received et credit_note.received (un fournisseur a envoyé une facture ou un avoir) ; invoice.updated (une facture a été validée, par une personne ou automatiquement, ou refusée, ou son fournisseur a confirmé les coordonnées bancaires ou l’a signalée) ; invoice.payment (un paiement a été enregistré ou retiré, un avoir a soldé la facture, ou un paiement via Pleaxy a abouti ou échoué : lisez GetInvoiceRemittance) ; purchase_order.updated (une commande a été validée, refusée ou annulée) ; et purchase_order.confirmed et purchase_order.shipped (lisez GetPurchaseOrderFulfillment). Il ne reçoit que les types de documents que son rôle achats peut consulter.

Un bon de commande émis, sous forme de document que votre système intègre. format=cxml (par défaut) est un OrderRequest cXML : type new, update à partir de la version 2, delete une fois annulé. format=ubl est un Order UBL 2.1, ou un OrderCancellation une fois annulé. Les deux parties sont désignées par leur ID d’espace de travail. C’est la copie du fournisseur, quel que soit le demandeur. Un fournisseur dont des acheteurs partagent un id de BC ajoute ?buyer=<buyer Workspace ID>.

Une facture en Invoice UBL 2.1 (type 380, ou 383 pour une note de débit), à comptabiliser dans l’ERP de l’acheteur ou à archiver par le fournisseur : ses lignes, remises et frais au niveau du document, taxes et retenues, acomptes, instructions de paiement du fournisseur, et le bon de commande et le contrat qu’elle facture. Les totaux concordent avec le montant de la facture. C’est la vue du fournisseur, quel que soit le demandeur : ni rapprochement, ni constats, ni validations.

Où en est une facture, pour le système qui l’a envoyée ou celui qui la paie, sous forme d’un statut avec les codes qu’utilisent les systèmes de facturation électronique. L’équivalent en cXML ou UBL est GetInvoiceStatusDocument. C’est la vue du fournisseur, quel que soit le demandeur.

GetInvoiceStatus sous forme de document. format=cxml (par défaut) est un StatusUpdateRequest cXML avec un InvoiceStatus ; format=ubl est un ApplicationResponse UBL 2.1 avec les codes de la Peppol Invoice Response et, en cas de rejet, son motif.

Le signal de paiement d’une facture, pour le lettrage du fournisseur : comment et quand l’acheteur a payé, la référence, ce qui a été retenu et ce qui est parvenu au fournisseur, et les avis de règlement envoyés par l’acheteur (notes et justificatifs de paiement ; GetRemittanceFile en télécharge un). Pleaxy enregistre ce que déclare l’acheteur et ne déplace aucun fonds. Jamais qui, chez l’acheteur, l’a enregistré. L’équivalent en cXML ou UBL est GetInvoiceRemittanceDocument.

GetInvoiceRemittance sous forme de document. format=cxml (par défaut) est un PaymentRemittanceRequest cXML ; format=ubl est un RemittanceAdvice UBL 2.1.

Enregistre les paiements déjà effectués hors de Pleaxy par votre ERP ou votre flux bancaire - virements, chèques, ACH, carte - pour que chaque fournisseur reçoive son avis de paiement, son avis de règlement et son événement de synchronisation sans que personne ne le ressaisisse. Aucun fonds n’est déplacé. Chaque paiement suit les règles de RecordPayment et reçoit sa propre réponse ; en répéter un est sans risque (already_recorded). Une facture validée par une clé API reste refusée. note devient une note de règlement pour le fournisseur ; seul une personne peut joindre un justificatif de paiement.

Clé API acheteur avec le scope payments:record uniquement, générée avec un procurementRole autorisé à modifier les factures (administrateur ou finance). Une personne connectée utilise RecordPayment.