Protocole d'échange avec l'API
- 1 Document IGFact
- 2 Client
- 3 Société facturante
- 4 Contenu d’un document
- 4.1 Imputation comptable
- 4.2 Code TVA
- 4.3 Produits
- 5 Devise
- 6 Journal comptable
- 7 Document externe
- 8 Identification des données minimales requises
- 9 Critère d’identification commun
- 10 Vérification des accès
- 11 Format des communications
- 12 Evolution des documents
- 13 Interface de test
Document IGFact
Dans IGFact, tout document client est composé de différents éléments obligatoires.
Client
Adresse de livraison (optionnelle)
Société facturante
Contenu d’une document
Code TVA
Imputation comptable
Produits
Devise
Journal comptable
Nous allons aborder les différents éléments plus en détail afin de comprendre la logique qui les régit.
Pour rappel, les différents modèles sont disponibles sur la documentation de notre web service :
Client
Le client est la personne à qui est adressé le document. Dans le cas d’une facture, c’est donc la société qui sera facturée et qui devra imputer cela dans sa comptabilité.
Le client est identifié de manière unique par une référence qui sera reprise au niveau de la facture. ( Cette clé est le CustomerCode de l’entité Customer)
Un client peut être associé à une devise, un pays et un code TVA.
Adresse de livraison
Le client peut être lié à une adresse de livraison (une seule au niveau de IGFact) qui est dès lors utilisée au niveau du document.
L’adresse de livraison est lié au client sur base du CustomerCode de l’entité DeliveryLocation
Société facturante
La société facturante est l’entité de facturation dans laquelle le document est émi. Dans la plupart des cas il s’agit du magasin dans lequel la vente est effectuée. IGFact permet de gérer plusieurs magasins avec des comptabilités indépendantes.
La société comporte une série de valeurs comptables par défaut, telle que des imputations comptables, un code TVA pour les ventes nationales ou pour les ventes en europe et hors europe.
Ces valeurs sont utilisées par défaut lorsque d’autres valeurs ne sont pas disponibles.
La société facturante est identifié par un numéro unique via la clé BillCompanyNumber de l’entité BillCompany:
Contenu d’un document
Le document peut contenir différents types de lignes, qui auront ou non un impact au niveau comptable.
Pour qu’une ligne de commande soit comptabilisée elle doit au moins contenir les éléments suivants :
Une quantité
Un prix unitaire
Un imputation comptable
Un code de TVA
La référence d’un produit (optionnel) ou un code spécifique au type de ligne (#HS# pour un article hors stock à usage unique par exemple)
Dans les autres cas, il s’agira de lignes à vocation informative telles que des textes ( code #TX#).
Le contenu d’un document est lié à son entête sur base de 3 éléments de la table CustomerDocumentDetail :
La société facturante (BillCompanyNumber)
L’année du document (DocumentDate)
Le numéro du document (DocumentNumber)
Imputation comptable
Une imputation comptable est nécessaire car elle permet ensuite au niveau comptable de définir le compte dans lequel sera comptabilisé le montant. L’imputation est appliquée à chaque ligne car chaque élément peut être typé au niveau comptable.
Par exemple, les produits de peinture, les articles, la main d’œuvre, …
Cette information est indispensable.
Les imputations comptables sont donc identifiées par un compte chiffre (en général de 6 chiffres mais certaines sociétés détaillent davantage leur plan comptable).
Ce code unique est repris dans le BookingCode de la table Booking
Code TVA
Le code TVA permet de connaître le taux de TVA à appliquer sur la ligne, mais également, pour la plupart des logiciels comptables, l’implication au niveau de la déclaration TVA.
Un même taux de TVA peut donc être utilisé par différent code :
Les codes TVA sont donc identifiés par un code unique et non par leur taux.
Ce code est reprise dans le champ VatCode de l’entité Vat
Produits
Les produits sont les éléments vendus par la société.
Le produit peut faire l’objet d’un taux de TVA spécifique ou d’une imputation comptable propre qui sera utilisée lors de la facturation.
Les produits sont identifiés par une référence unique (ProductCode) propre à la société facturante (BillCompanyNumber) de la table Product
Devise
La devise permet au programme de connaitre le taux de conversion et le nombre de décimale à traiter en fonction de la monnaie.
La devise est identifiée par le CurrencyCode de la table Currency
Journal comptable
Le journal comptable est une information propre au logiciel comptable qui est lié à IGFact.
Il s’agit d’un journal auquel le document comptable sera lié.
Au niveau de IGFact, ce journal déterminera aussi la numérotation attribuée au document généré.
Celui-ci est actuellement géré directement au niveau de IGFact (et non au niveau de l’API).
Document externe
Identification des données minimales requises
Afin de comprendre comment intégrer les données externes, il est nécessaire pour nous de comprendre comment remplir les prérequis expliqués.
Comment identifier au niveau de votre modèle les éléments suivants :
(Table liée, via quel id, … )
L’entête du document:
Le client
Son adresse de livraison (si disponible)
La société facturante
La devise
Le contenu du document :
Le ou les produit(s) lié(s)
D’autres types de contenu
Le code TVA utilisé
L’imputation comptable
Il est bien entendu possible, si le système ne gère pas de données comptables, que vous n’ayez pas certaines informations mais il est alors important pour nous de comprendre les critères qui vous aide à déterminer les données utilisées.
Dans le cas par exemple d’un document ou seul le pourcentage de TVA serait disponible, comment celui-ci est-il déterminé?
Et ce afin d’éviter au maximum de devoir imposer des valeurs lors de la récupération des données. Il est bien entendu que notre client commun sera peut être mis à profit à ce niveau pour définir certaines valeurs fixes à utiliser si celles-ci sont indisponibles.
Critère d’identification commun
Il est important de définir ensemble sur base de quel critère pouvons identifier nos éléments commun de manière unique et ce afin d’éviter les doublons et incohérences au maximum.
Dans le cas d’un client par exemple, faut il utiliser le numéro de TVA, un email, … afin d’éviter de multiplier les doublons, le cas échéant, cette donnée devrait devenir obligatoire des deux côtés.
Dans le cas des produits, devons nous utiliser une référence commune propre à IGFact ou au WebShop si la gestion se fait à ce niveau, …
Vérification des accès
Notre clé d’API (ou autre moyen d’accès) nous permet-elle bien d’accéder aux différents éléments liés afin de récupérer les données nécessaire à la création d’un élément qui nous serait inconnu au niveau de la commande.
Par exemple, si le client ajoute la devise $ au niveau du webshop, avons nous accès à cette table afin d’en retirer les données via l’id et les données disponibles nous permettent-elles de remplir les données expliquées au niveau de IGFact.
Format des communications
Nous devons également comprendre comment nous seront notifiés des nouveaux éléments :
Le format utilisé (XML, JSON, … )
La méthode (POST, PUT, .. )
Le format du contenu
Le contenu (un id, plusieurs id, l’objet complet, une liste d’objet, … )
Comment identifier l’entité qui a émis la notification
Exemple sur l’url de test
Evolution des documents
Est-il possible à l’utilisateur du webshop de modifier sa commande une fois qu’elle est générée ( annuler une commande, … ) ?
Quels sont les différents états d’un document?
Interface de test
Comment pouvons nous générer des commandes et des notifications afin de tester l’intégration ?