|
Guide d'utilisation en ligne |
|
|
Guide d'utilisation en ligne |
Voici la liste des champs disponibles et une brève explication du contenu.
Les valeurs sont toujours formatées de ma même façon en fonction de leur type respectif :
La structure générale du schéma est basé sur une blockchain. Chaque bloc dispose d'une en-tête qui comprend un certain nombre d'informations et fourni notamment une clé de hash renforcée par une preuve de travail déterminée par un niveau de difficulté.
Ensuite viennent les données de la gestion capturées au moment de l'enregistrement du nouveau bloc. Enfin, il y a les données de la source de la transaction qui a été enregistrée dans le journal.
Lors de l'enregistrement d'un nouveau bloc dans la blockchain, la clé de hash du bloc précédent est calculée sur l'ensemble des données du bloc précédent et non pas sur son en-tête seule. Il faut donc détenir l'intégralité des données du bloc précédent pour valider le suivant. La clé de hash du bloc précédent n'est pas ajoutée dans l'en-tête au moment de l'écriture dans la chaîne. Il est obtenu par calcul du bloc précédent.
Le processus est donc le suivant:
On remplace ici T par le caractère de tabulation (code : 9). Le premier bloc de la chaîne utilise toujours la clé de hash suivante pour commencer : “e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855”. Notez également que les clés de hash sont toujours utilisées sous la forme de chaîne de caractères représentant la clé exprimée en hexadécimal.
Vous trouverez ci-dessous les détails de chaque champ (numéroté) pour chaque section.
Ces données concernent uniquement l'en-tête du bloc.
Il s'agit de la clé de hash du bloc. Cette clé doit respecter le niveau de difficulté du bloc. Ce niveau est défini par bcDifficulty. On commence généralement avec une difficulté minimum de 16. Cette difficulté peut varier mais jamais descendre en dessous de 16. Plus cette difficulté est élevée et plus il faut de de bits à zéro de au début de la clé pour satisfaire à la contrainte. Ainsi, si la difficulté est 16, la clé doit toujours commencer par 4 zéros en hexadécimal pour “0000” (16 bits à zéro).
Pour trouver la première clé qui correspond à cette caractéristique, il n'existe qu'un seul moyen : les tester toutes exhaustivement l'une après l'autre. Pour cela, on incrément bcNonce à chaque essai.
Il s'agit du numéro de révision du format de l'en-tête du bloc.
Niveau de difficulté pour trouver la clé de hash du bloc. Par défaut, sa valeur est 16.
Nombre exprimé sous la forme d'une chaîne de caractère décimaux. Représente le nombre d'essais nécessaire avant d'obtenir la preuve de travail (une clé de hash qui correspond à al difficulté). En moyenne, avec une difficulté de 16, il faut en moyenne plus de 60000 essais avant de trouver une clé qui correspond au critères.
Numéro de série du bloc dans la chaîne. On en saute jamais de numéro.
Numéro de révision de la section de données : 0.
Numéro de série unique du document dans la base de données. Ne correspond pas nécessairement au numéro du document dans le facturier.
Référence unique du document dans le facturier. Correspond au mode de numérotation sans jamais sauter de numéro.
Référence du document tel qu'il est imprimé sur le document. Peut contenir des informations complémentaire comme la date ou l'année de l'exercice.
Compteur de paiements (encaissements) enregistrés depuis le début.
Les grands totaux perpétuels sont calculés en ajoutant la valeur absolue du montant donné. Il peut donc s'agir de grands nombres au bout d'un certain temps d'utilisation puisqu'ils ne diminuent jamais.
Grand total perpétuel hors TVA : grand total précédent + valeur absolue du grand total HTVA du document.
Grand total perpétuel TVA : grand total précédent + valeur absolue du grand total TVA du document.
Grand total perpétuel hors TVA comprise : grand total précédent + valeur absolue du grand total TVAC du document.
Grand total perpétuel des champs fiscaux : grand total précédent + valeur absolue du grand total des champs fiscaux du document.
Grand total perpétuel des grands totaux : grand total précédent + valeur absolue du grand total du document.
Grand total perpétuel du total reçu : grand total précédent + valeur absolue du grand total reçu du document.
Lors de l'inscription de la nouvelle transaction, l'état de l'exercice est calculé. Vous trouverez donc l'année de l'exercice, le nombre de document (factures et notes de crédit) de l'exercice à ce moment, ainsi que le chiffres.
Il s'agit du nombre de transactions enregistrées depuis le début de l'exercice avec les totaux pour chaque ventilation. Un champ avec le montant restant à recevoir est aussi ajouté.
Le logiciel peut gérer jusque 4 modes TVA normaux différents, les auto-liquidations intracommunautaire et cocontractant ainsi que l'exonération. Il gère aussi le cas échéant les TVA étrangère dans le cas de services distant ou de télédistribution.
Dans le cas des modes normaux, vous avez les totaux hors TVA et TVA. Dans le cas des auto-liquidations, seulement le montant hors TVA. Pour ce qui est des TVA étrangères (MOSS en Belgique), vous ne disposez que des totaux hors TVA et TVA au vu du nombre de champs qu'il faudrait pour ventiler chaque taux par pays.
Référez-vous à la capture annuelle. Cette section est bâtie sur le même principe mais par mois de l'exercice. Notez cependant que le numéro du mois commence à partir du début de l'exercice. Il en s'agit pas du numéro du mois dans le calendrier.
Cette section ne tient compte que de l'année calendaire et non de l'exercice.
Année calendrier.
Nombre de paiements (encaissements) enregistrés au cours de la période.
Total en espèce.
Total en Chèques.
Total en virements.
Total en cartes.
Total par d'autres moyens (y compris apurement factures - notes de crédit).
Total.
Comme la capture précédente, mais seulement pour le mois calendaire et non de l'exercice.
Comme la capture précédente, mais seulement pour le jour calendaire et non de l'exercice.
Chaque transaction source est horodatée par un service indépendant de l'ordinateur de l'utilisateur. La signature obtenue est un cachet serveur crypté avec une clé RSA 512 bits.
Cachet serveur crypté sur 512 bits. Pour vérifier ce cachet, il faut calculer la clé de hash SHA-256 du contenu intégral de la source, ajouter le timestamp, le texte “Europe/Bruxelles” et l'ip séparés par des caractères d'espace (code : 32). Si le hash obtenu correspond à celui du secureTS décrypté à l'aide de la clé du certificat public, la signature est valide.
Horodatage indépendant de l'heure de l'horloge de l'ordinateur de l'utilisateur. L'heure est toujours fixée par rapport à l'heure locale à Bruxelles en Europe.
Zone de l'heure local : Bruxelles en Europe.
Adresse IP de l'ordinateur qui a fait la demande de cachet serveur.
Il s'agit de divers informations complémentaires pour identifier l'utilisateur à l'origine de la transaction source.
Numéro de révision du format : 0.
GUID de la base de données BeDesk.
Nom de la base de données.
GUID de la session de l'utilisateur BeDesk accédant à la base de données.
Nom de l'utilisateur défini par le système d'exploitation sous cette forme : [user]@[host]([système d'exploiation]).
Numéro de build du logiciel BeDesk Express utilisé.
Numéro de révision du format de la source : 0;
Clé de hash de la révision précédente du document ou clé de hash initiale (la même que pour la blockchain). Cette clé sera prise en compte pour le calcul de hash du prochain prevSecureSrc. Il s'agit d'une chaîne de hashes qui commence avec la première révision du document et qui doit être continue jusqu'à ça dernier révision.
Il s'agit d'un numéro unique qui permet d'identifier le document au niveau de la base de données. Ce numéro n'est pas le numéro de série du document dans le facturier.
Numéro de révision du document. On ne saute jamais de numéro et ceux-ci doivent apparaître dans l'ordre chronologique dans la chaîne.
Action réalisée :
Il y a au moins 3 actions par document. Celles-ci apparaissent dans l'ordre chronologique et de manière cohérente.
Exercice auquel appartient le document.
Mois de l'exercice auquel appartient le document. Attention, il ne s'agit pas du mois calendrier, mais du numéro du mois dans l'exercice.
Date figurant sur le document. Le fait de changer la date du document peut le faire changer d'exercice. Il est assez facile de voir si ce changement, s'il a lieu, est légitime et cohérent.
Grand total hors TVA du document.
Grand total TVA du document.
Grand total TVA comprise du document.
Grand total des éléments fiscaux spécifiques du document.
Grand total tout compris.
Total hors TVA ventilé pour la TVA normal 1.
Total TVA ventilé pour la TVA normal 1.
Total hors TVA ventilé pour la TVA normal 2.
Total TVA ventilé pour la TVA normal 2.
Total hors TVA ventilé pour la TVA normal 3.
Total TVA ventilé pour la TVA normal 3.
Total hors TVA ventilé pour la TVA normal 4.
Total TVA ventilé pour la TVA normal 4.
Total hors TVA ventilé pour l'auto-liquidation intracommunautaire.
Total hors TVA ventilé pour l'auto-liquidation cocontractant.
Total hors TVA ventilé pour l'exonération.
Total hors TVA ventilé pour la TVA étrangère.
Total TVA ventilé pour la TVA étrangère.
Nombre total de paiements (encaissements) enregistrés pour ce document.
Total en espèce.
Total par chèques.
Total par virements.
Total par cartes.
Total des autres moyens (y compris apurement factures - notes de crédit).
Total des paiements reçus ou apurés.
Lorsque l'action est “PAIEMENT”, on a ici les détails du paiement en question. On commence ici avec le numéro d'identification du paiement dans la base de données. Il ne s'agit pas du numéro d'ordre du paiement. Ce numéro d'ordre est fourni sur la même ligne dans le champ paIndexCnt.
Date de paiement.
Montant en espèce.
Montant du chèque.
Montant du virement.
Montant par carte.
Montants autres.
Montant total.
Commentaire ou justificatif.
Information relatives au client. Ici l'identifiant de la fiche du client dans la base de données.
Numéro de TVA du client.
Dénomination du client (raison sociale).
Adresse du client.
Code-postal.
Localité.
Pays.
Différence du grand total hors TVA du document par rapport à sa révision précédente.
Idem pour la TVA.
Idem pour le montant TVA comprise.
Idem pour les éléments de fiscalité spécifiques.
Idem pour le grand total.
Différence par rapport aux paiements (encaissements) en espèce.
Idem pour le total par chèques.
Idem pour les virements.
Idem par cartes.
Idem pour les moyens autres (y compris apurement).
Idem pour l'ensemble des paiements, encaissements et apurements.
Dans certains cas le logiciel demande à l'utilisateur de justifier ou de fournir la raison d'une modification ou d'une action particulière. La raison ou l'explication justificative se trouve ici. BeDesk Express ne limite pas le champ d'action de l'utilisateur tant que d'une manière ou d'une autre celle-ci peut s'avérer légitime.
Vous trouverez ici le document d'origine complet représenté sous la forme d'un document JSON facile à lire et reconstitué.
