Forum Discussion
Bob
Première note
Première noteDemande d'évolution API ledger_entries
Dans le cadre de notre intégration avec Pennylane, nous avons choisi d'utiliser le champ *piece_number* pour identifier les écritures liées à une même commande. Cette méthode fonctionne bien pour une recherche dans le Grand Livre.
Cependant, pour utiliser l'API afin d'identifier ces écritures et procéder au lettrage, l'endpoint *ledger_entries* ne permet pas de filtrer sur le champ *piece_number*. Rechercher ces écritures via les autres filtres disponibles (journal_id et date) nous oblige à effectuer des requêtes larges, car les encaissements et les facturations peuvent être espacés de plusieurs mois. Nous devons ensuite filtrer manuellement le champ *piece_number* sur une collection de plusieurs milliers d'écritures, ce qui atteint régulièrement la limite de débit de l'API et consomme beaucoup de ressources.
Serait-il possible d'obtenir prochainement ce filtre, somme toute très simple, puisqu'il se situe au niveau 0 du JSON de la réponse ?
Bonjour Bob
À date, non : l’endpoint GET ledger_entries ne permet pas de filtrer sur le champ piece_number. Les filtres autorisés côté API sont limités à journal_id, date, created_at, updated_at Donc votre constat est cohérent : vous êtes obligés de requêter “large” puis de filtrer vous-mêmes sur piece_number.
Si vous créez / mettez à jour les écritures via l’API, le contournement le plus robuste est de stocker côté intégration la correspondance entre votre identifiant (ex. piece_number) et les IDs des écritures retournés par l’API lors du POST/PUT (puis vous n’avez plus besoin de “rechercher” par piece_number)
Je vous invite à ajouter cette recommandation dans la “Liste d’idées” du Forum. Cette liste vous permet de faire des suggestions aux équipes Pennylane, qui seront priorisées en fonction des votes des autres utilisateurs. Vous avez donc également la possibilité d’y voter pour les fonctionnalités suggérées par d’autres utilisateurs
3 Réponses
- Angélique_
Pennylaneur
Bonjour Bob
À date, non : l’endpoint GET ledger_entries ne permet pas de filtrer sur le champ piece_number. Les filtres autorisés côté API sont limités à journal_id, date, created_at, updated_at Donc votre constat est cohérent : vous êtes obligés de requêter “large” puis de filtrer vous-mêmes sur piece_number.
Si vous créez / mettez à jour les écritures via l’API, le contournement le plus robuste est de stocker côté intégration la correspondance entre votre identifiant (ex. piece_number) et les IDs des écritures retournés par l’API lors du POST/PUT (puis vous n’avez plus besoin de “rechercher” par piece_number)
Je vous invite à ajouter cette recommandation dans la “Liste d’idées” du Forum. Cette liste vous permet de faire des suggestions aux équipes Pennylane, qui seront priorisées en fonction des votes des autres utilisateurs. Vous avez donc également la possibilité d’y voter pour les fonctionnalités suggérées par d’autres utilisateurs
BobMerci pour votre retour Angélique.
Nous envoyons nos écritures par fichier plat et c'était la seule façon que nous avions trouvé pour "grouper" nos écritures et effectuer le lettrage automatique (sur le numéro de pièce qui est une option de la plateforme). Nous ne récupérons pas les id des lignes d'écriture créée par cette méthode.
Sinon, ajouter un index DB sur votre colonne `piece_number` soulagerait le serveur au passage en plus de rendre les requêtes bien plus rapide pour le lettrage.
Cordialement.
- Angélique_
Bonjour Bob
Dans Pennylane, le regroupement des lignes en “écriture” à l’import se fait via une référence de pièce : autrement dit, si vous voulez que plusieurs lignes appartiennent à la même pièce, elles doivent partager le même Numéro de pièce / PieceRef. C’est aussi un levier utilisé pour faciliter le lettrage automatique, notamment “par numéro de pièce” depuis la balance.
Si, en plus, vous voulez importer les justificatifs en même temps que les écritures, c’est également basé sur cette même logique : vous mettez une colonne PieceRef dans le fichier d’import et les fichiers (PDF/PNG) dans le ZIP doivent avoir un nom strictement identique à la valeur de PieceRef
Si l’objectif est de “retrouver” les lignes côté outil source, l’approche la plus robuste est de porter une référence métier stable dans le fichier importé (ex. Numéro de pièce/PieceRef, et éventuellement une référence externe dans un libellé).
Si vous voulez absolument conserver une référence (ex. n° de facture) via l’import d’écritures, un contournement évoqué en interne est de la mettre dans le libellé de ligne pour la retrouver ensuite plus facilement.
Si ces informations n'aident pas suffisamment, Je vous invite à ajouter cette recommandation dans la “Liste d’idées” du Forum. Cette liste vous permet de faire des suggestions aux équipes Pennylane, qui seront priorisées en fonction des votes des autres utilisateurs. Vous avez donc également la possibilité d’y voter pour les fonctionnalités suggérées par d’autres utilisateurs
