Aller directement à la fin des métadonnées
Aller au début des métadonnées

Vous regardez une version antérieure (v. /wiki/spaces/IGFFR/pages/1477017626/Protocole+d+change+avec+l+API) de cette page.

afficher les différences View Version History

« Afficher la version précédente Vous regardez la version actuelle de cette page. (v. 2) afficher la version suivante »

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’oeuvre, … 

Cette information est indispensable.

Les imputations comptables sont donc identifié par un compte chiffre (en général de 6 chiffres mais certaines sociétés détaille 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é 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é 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 produits 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 ?

  • Aucune étiquette