indique le pays correspondant.

Si les propriétés « fiscalCountryProperties » sont interrogées via la requête GET /api/v1/information/client/{clientId}/countryProperties, le pays attribué au client concerné est précisé.

Indique si la certification d’un composant de fiscalisation est requise dans un pays, ou ce qui doit être certifié.

« mandatory » - La certification du système en amont (par exemple, la caisse enregistreuse) est obligatoire. Dans ce cas, la caisse enregistreuse doit faire l’objet d’un processus de certification ou d’homologation.

« miniPOS » : la certification est obligatoire, mais elle est assurée par un composant déjà certifié pouvant être intégré au RetailForce Middleware.

« notNecessary » : aucune certification du système en amont n’est requise.

« true » - Dans le pays concerné, les données doivent être transmises ligne par ligne, par exemple vers une imprimante fiscale.

• Non pris en charge pour le moment

« false » – Interface par document (pas d’impression ligne par ligne).

• La mise en œuvre entre le système amont et le service de fiscalisation s’appuie sur des points de terminaison API standard.

Spécifie le type de fiscalisation.

« fiscalPrinter » - La fiscalisation s’effectue à l’aide d’une imprimante fiscale certifiée ou d’un système de caisse enregistreuse fiscale certifié.

• Cela implique qu’en plus du système RetailForce, une imprimante fiscale est requise ; celle-ci devra éventuellement être acquise auprès d’un fournisseur local.

« online » - La fiscalisation s’effectue via les systèmes en ligne des autorités fiscales locales.

• Aucun équipement matériel supplémentaire n’est requis.

« signature » : la fiscalisation s’effectue par la signature des données de ticket à l’aide d’un certificat numérique stocké dans le service de fiscalisation.

• Dans certains pays, il peut être nécessaire d’obtenir un certificat numérique qualifié délivré par une autorité de certification (CA).

« signatureWithOnline » : fiscalisation par génération de signatures et transmission des données en ligne vers les autorités fiscales.

• Combinaison des deux types susmentionnés.

Précise quel environnement est pris en charge :

« local » - installation locale du middleware fiscal (localement sur le système de point de vente, sur le serveur du magasin, etc.)

• Des appels API peuvent être effectués vers le service de fiscalisation installé localement :
  • http://localhost:7678/ dans le cas d’une implémentation REST, ou
  • appel de méthode dans le cas d’une implémentation NuGet.

« cloud » : le middleware fiscal est disponible sous forme de service cloud hébergé à l’adresse https://fiscalisation.RetailForce.cloud/.

• Des appels API peuvent être effectués vers le service de fiscalisation dans le Cloud.

Spécifie les systèmes d’exploitation/plateformes pris en charge.

« Linux »

• via un conteneur Docker (implémentation REST)

« windows »

• via un service Windows (implémentation REST), ou
• via une implémentation NuGet

« iOS »

• via l'implémentation nuget

« android »

• via l'implémentation NuGet, ou
• Service Android (implémentation REST)

Précise quelles exigences légales sont prises en charge ainsi que leurs versions.

Par exemple, pour la Grèce : « myDATA v1.x.x ».

Types de documents devant faire l’objet d’une « fiscalisation » dans le pays concerné. Par exemple, ils doivent être traités par le matériel prescrit, signés, etc.

Les « documentTypes » répertoriés sous « fiscalDocumentTypes » sont automatiquement traités (par exemple, signés) dans le pays concerné par le service de fiscalisation, conformément à la législation en vigueur en matière de fiscalisation.

Ces types de documents DOIVENT être transmis au service de fiscalisation du pays concerné, à condition que le système amont (« caisse enregistreuse ») les prenne en charge.

Liste des types de documents pris en charge dans chaque pays.

Outre les « fiscalDocumentTypes », les types de documents répertoriés sous « supportedDocumentTypes » PEUVENT être transmis au service de fiscalisation.

Ces types de documents sont qualifiés de « non fiscaux », c’est-à-dire qu’ils ne sont pas « fiscalisés » (par exemple, signés).

Liste des types de documents non pris en charge dans le pays concerné.

Les « documentTypes » répertoriés sous « notSupportedDocumentTypes » ne peuvent pas être transmis au service de fiscalisation dans le pays concerné.

Cette limitation peut résulter d’une contrainte technique ou de réglementations/lois spécifiques au pays.

Si un « notSupportedDocumentType » est transmis au service de fiscalisation, celui-ci renvoie un message d’erreur (« documentType non pris en charge ! »).

Le système amont doit donc bloquer l’envoi de ces types de documents dans le pays concerné.

Liste des modes de paiement pris en charge (acceptés) dans le pays concerné.

Ces modes de paiement peuvent être utilisés dans le pays concerné.

Le système en amont ne doit proposer à l’utilisateur de la caisse enregistreuse que les modes de paiement pris en charge dans le pays concerné.

Liste des modes de paiement qui ne sont pas pris en charge (ou non autorisés) dans le pays concerné.

Le système en amont doit masquer les modes de paiement non pris en charge dans le pays concerné.

Liste des modes de paiement (PaymentTypes) pour lesquels le paiement d’un montant supérieur à la somme due n’est pas autorisé dans le pays concerné.

Exemples :

Montant total du ticket de caisse = 38,50 EUR

• Le client règle 50 EUR par carte de débit, car il souhaite recevoir la monnaie en espèces.
• Le client paie 50 EUR en espèces et reçoit 11,50 EUR de rendu de monnaie.

Ces transactions ne sont pas autorisées dans certains pays (c’est-à-dire qu’elles ne peuvent pas être transmises au système de fiscalisation).

Cela signifie que les montants de paiement (« payment.amount ») doivent toujours correspondre au total brut des articles (« GrossValue » de toutes les « positions ») et qu’aucun montant de paiement négatif ne peut être transféré.

Liste des types de cas d’affaires pris en charge dans chaque pays.

Ces cas d’affaires peuvent être utilisés dans le pays concerné, contrairement aux « notSupportedBusinessTransactionTypes ».

Liste des types de cas d’affaires qui ne sont pas pris en charge (ou qui ne sont pas autorisés) dans le pays concerné.

Ces cas d’utilisation ne peuvent pas être utilisés dans le pays concerné et doivent être filtrés par le système source afin de ne pas être transmis au service de fiscalisation.

Informations détaillées sur les taux de TVA pris en charge dans chaque pays.

Ce tableau contient les informations suivantes :

• Taux de TVA : « VatPercent » / « VatPercent2 »
• Identifiant interne utilisé pour associer le taux de TVA correspondant : « VatIdentification »
• Désignation du taux de TVA : « caption » / « caption_EN »
• Historique des taux de VAT avec les détails de validité (« ValidFrom » - « ValidTo »)

« non obligatoire » – L’affichage du client n’est pas requis (pas d’obligation).

« obligatoire (no-RF) » – L’affichage client est obligatoire, mais n’est pas supervisé par le RetailForce Middleware ; la conformité est vérifiée automatiquement par le système de fiscalisation concerné (par exemple, par l’imprimante fiscale).

« obligatoire (RF) » – L’affichage au client est obligatoire et est contrôlé via le RetailForce Middleware.

• L'affichage client est contrôlé via l'API : POST /api/v1/transactions/display/{clientId}

« non autorisé » - L’utilisation d’un écran client est interdite dans ce pays.

Indique si les périphériques d’entrée doivent être enregistrés dans le pays concerné (« true » / « false »).

Les dispositifs de saisie ne constituent pas des systèmes d’enregistrement autonomes. Pour plus d’informations, consultez : Architectures des systèmes d’enregistrement électroniques (EAS)

« true » : dans le pays concerné, il existe une obligation de tenir un journal technique (journal d’audit) (inclus dans ce cas dans la licence RF).

• Dans ce cas, les entrées d’événements techniques doivent être transmises au service de fiscalisation via
  • POST /api/v1/transactions/AuditLog , ou
  • POST /api/v1/transactions/storeDocument (« documentType » : « [1002] = AuditLog »)

« false » : il n’existe aucune obligation de tenir un journal technique (non inclus dans la licence).

• Les événements techniques PEUVENT être enregistrés, mais ce n’est pas obligatoire.

« true » – dans le pays concerné, la réimpression d’un document doit obligatoirement être enregistrée.

• Appel de l’une des commandes suivantes :
  • PUT /api/v1/transactions/reprintDocument/ {clientId}/{DocumentGuid}, ou

  • PUT /api/v1/transactions/reprintDocument

    obligatoire.

« false » : la réimpression d’un document ne doit pas obligatoirement être enregistrée.

« terminal » – Un document ne peut être réimprimé que sur la même caisse que celle sur laquelle le document original a été émis.

« store » – Les réimpressions d’un document ne peuvent être effectuées qu’au sein de la même succursale/du même magasin où le document original a été émis.

• La fonctionnalité de réimpression inter-succursales doit être implémentée par le système en amont.

« all » - La réimpression d’un document peut être effectuée sur une autre caisse ainsi que dans une autre succursale ou un autre magasin de la même entreprise.

• La fonction de réimpression entre plusieurs succursales doit être mise en œuvre par le système en amont.

« true » - Une clôture journalière (rapport Z) doit être générée une fois par jour.

• clôture quotidienne
  • POST /api/v1/transactions/storeDocument
  • « documentType » : « [99] = EndOfDay »

« false » : aucune obligation de clôture journalière.

Indique le délai, à compter de l’ouverture quotidienne de la caisse, dans lequel une clôture quotidienne doit avoir lieu (par exemple, dans les 24 heures).

« -1 » – non défini.

Précisez si les ventes et les retours peuvent être enregistrés simultanément sur un ticket de caisse (Document).

« oneReceiptAllowed » : autorisé (les ventes et les retours peuvent figurer ensemble sur un même ticket).

• Ventes :
  • « positions » (type 0 ou 1) avec des valeurs positives,
• Retours :
  • « positions » (type 0 ou 1) avec des valeurs négatives et
  • « documentReference » défini.

« oneReceiptAllowedVat » : tant que le montant de la Vat reste positif, les ventes et les retours peuvent être enregistrés sur un seul et même ticket de caisse.

« multiReceipt » : les ventes et les retours doivent être enregistrés sur des tickets de caisse distincts.

• Avant la transmission des données au service de fiscalisation, le système en amont doit automatiquement séparer les ventes et les retours en transactions distinctes.

« NoReturnAllowed » : dans le pays concerné, le traitement des retours via le système de fiscalisation n’est pas possible. Dans ces pays, les retours sont souvent gérés au moyen de formulaires spéciaux ou d’outils similaires au sein du service comptable.

Où les articles achetés peuvent-ils être retournés ?

« terminal » – Les articles ne peuvent être repris qu’à la même caisse (émission de bon d’achat) où la vente initiale a été effectuée.

« store » – Les articles ne peuvent être retournés que dans la même succursale/le même magasin (lieu d’émission du ticket de caisse) où la vente initiale a été effectuée.

« all » - Les articles peuvent également être retournés dans d’autres succursales de la même entreprise.

Référence du document pour les retours

« single » - en cas de retour, la référence ne peut porter que sur UN SEUL document antérieur (document de vente des services ou des biens retournés).

• « documentReference » n’est autorisé que pour un seul document préliminaire, ou
• la référence au niveau des postes (« positionReference ») n’est autorisée que pour un seul document préliminaire.

« multiple » : en cas de retours, il est possible de faire référence à plusieurs documents antérieurs (plusieurs tickets de caisse si plusieurs services ou marchandises issus de plusieurs achats sont retournés). 

• « documentReference » vers plusieurs documents antérieurs, ou
• référence au document antérieur correspondant via « positionReference » sur chaque poste de retour.

Indique si l’élément « fiscalDocumentNumber » de la réponse « fiscalResponse » du pays concerné doit être imprimé sur les documents.

• Les numéros de document transférés depuis le système en amont sont ignorés. Le système fiscal (par exemple, l’imprimante) attribue de manière autonome le numéro de document ou l’ID correspondant.

« true » : dans le pays concerné, les majorations sur les biens ou les services sont autorisées.

• surcharges :
  • « positions.discounts » avec des valeurs NÉGATIVES

« false » – Les majorations de prix ne sont pas autorisées.

Indique si le mode formation/démonstration du terminal de point de vente est autorisé dans le pays concerné

« true » – autorisé.

• Mode de formation :
  • « IsTraining » : true

« false » – La caisse ne doit pas disposer d’un mode formation/démonstration.

« true » – La somme des articles individuels est calculée sur la base du montant net (NetValue) (par exemple, au Québec/au Canada).

« false » – La somme des articles individuels est calculée sur la base du montant brut (GrossValue) (par défaut).

« true » - Les éléments qui ont été saisis mais qui ne figurent pas par la suite dans le document doivent être transmis dans la payload (JSON).

« false » – Les lignes qui ont été saisies mais qui ne figurent pas par la suite dans le document n’ont pas besoin d’être transmises.

Spécifie le type de document de départ dans le pays concerné.

Ce paramètre n’est pertinent que si le système en amont n’utilise PAS la fonction GET /api/v1/transactions/document/{clientId}/start lors de l’initialisation et génère lui-même le document de départ correspondant.

Liste des types de versements pris en charge dans le pays concerné.

Les éléments répertoriés sous « supportedPayOutTypes » peuvent/doivent être spécifiés pour les paiements (« documentType » : « [10] = PayOut » et « BusinessTransactionType » : « [10] = PayOut »).

Indique si les taux de TVA sont calculés par le module de fiscalisation correspondant du pays.

« true » : le module de fiscalisation calcule les taux de VAT.

« false » : la caisse enregistreuse doit calculer les taux de Vat.

Précise si des décimales doivent être incluses dans le document JSON transmis au middleware fiscal lors de l'envoi des montants/totaux, et le nombre de décimales à inclure.

S'applique à toutes les spécifications de valeur dans la charge utile (« GrossValue », « NetValue », « TaxValue », « Amount », etc.)