Aller au contenu principal

Interface du système de fichiers

DEVELOPMENT
  • Mise à jour

Cet article décrit comment utiliser l’interface de fichiers du service fiscal.

Prérequis

  • FiskalClient à partir de la version 1.2.11
  • FiscalClient en tant que service (les implémentations nuget ne sont pas prises en charge)

Pays pris en charge

Actuellement, seuls les pays énumérés ci-dessous sont pris en charge via l’interface de fichiers :

  • Autriche
  • Danemark (à partir de la version 1.3)

Informations complémentaires

L’interface de fichiers ne prend en charge qu’une partie très restreinte des fonctionnalités du client fiscal permettant de transmettre les données nécessaires à la fiscalisation. Si des commandes plus spécifiques sont souhaitées, le service peut toujours être intégré à des outils tels que CURL via l’interface REST. Toutefois, cela n’est pas abordé dans cet article.

Activation

L’interface du système de fichiers peut être activée comme suit :

  • En définissant le chemin d’accès au répertoire de surveillance dans le fichier appsettings.json.
  • Créer un répertoire sous C:\ProgramData\RetailForce\Fiscal web service et le nommer « fileSystemInterface ».

Attention : pour activer le système, le service doit être redémarré après ces paramétrages.

appsettings.json

"AppSettings": {
  ...,
  "FileSystemInterfacePath": "c:/temp/filesysteminterface",
  ...
}

Les entrées situées avant et après ne sont pas incluses dans l’exemple. « c:\temp\filesysteminterface » correspond au chemin d’accès surveillé.

Remarque : le dossier surveillé doit être un dossier local. Les lecteurs réseau ne sont pas pris en charge, car les systèmes de surveillance des fichiers ne fonctionnent souvent pas de manière fiable dans ce cas.

Fonctionnement

L’interface de fichiers du service fiscal surveille un répertoire à la recherche de nouveaux fichiers présentant une structure de nom spécifique. Dès qu’un nouveau fichier respectant ces conventions de nommage est créé dans ce répertoire, il est traité.

Remarque : pour les fichiers volumineux, il est conseillé de commencer par enregistrer le fichier dans le répertoire en tant que fichier temporaire, puis de le renommer avec le nom correct à l’aide de la commande RENAME.

Procédure

La procédure est la suivante :

  1. Le fichier est transféré dans le répertoire et détecté (*.request)
  2. Le fichier est alors traité
  3. Un fichier *.response ou *.error est enregistré dans le répertoire « response » (sous-répertoire du répertoire d’importation) avec le même nom de fichier avant l’extension.

Exemple

  1. Le fichier 20220308135010236.document.request est transféré
  2. Le fichier est en cours de traitement
  3. Le fichier response/20220308135010236.document.response est enregistré. 

ou, en cas d’erreur

  1. 20220308135010236.document.request est transféré
  2. Le fichier est en cours de traitement
  3. Le fichier « response/20220308135010236.document.error » est enregistré. 

Responsabilités

Les fichiers de requête traités sont déplacés vers le sous-répertoire « processed » par l’interface de gestion des fichiers.

L’interface de fichiers ne supprime jamais aucun fichier. Il est toutefois recommandé d’archiver les fichiers les plus anciens (reconnaissables à leur date) après un certain laps de temps.

Garantie de l’ordre correct

L'ordre de traitement est garanti par un nom de fichier unique et triable.

Structure du nom de fichier

AAAAMMJJHHNNSSZZZ.{type}.request

AAAA = Année (2022), plage de valeurs : 2022-3000

MM = mois (03 pour mars), plage de valeurs : 01-12

DD = Jour (02 pour le 2 du mois), plage de valeurs : 01-31

HH = Heure au format 24 heures, plage de valeurs : 00-23

NN = Minutes (04 pour 4 minutes), plage de valeurs : 00-59

SS = Secondes (05 pour 5 secondes), plage de valeurs : 00-59

ZZZ = Millisecondes (010 pour 10 millisecondes), plage de valeurs : 000 à 999

Type

{type} indique le type de la requête ; les valeurs possibles sont les suivantes :

  • Document – pour transmettre un reçu
  • validateDocument – pour valider un reçu
  • command – pour exécuter une commande

Documentation sur les types et les modèles

Pour plus d’informations sur le modèle de document et les réponses correspondantes, veuillez vous reporter à la documentation sur le modèle d’objet et à la documentation Swagger du client Fiscal (http://localhost:7678/swagger/index.html).

Le retour d’erreur est identique pour tous les types : l’exception levée est renvoyée dans le fichier de retour (*.error).

Type « document » - transmission des reçus

Dans ce cas, le contenu du fichier est un document au format RetailForce (Document).

Le format du document peut être consulté dans la documentation relative au modèle d’objet ou dans la documentation Swagger du service fiscal (http://localhost:7678/swagger/index.html).

Réponse

La réponse fiscalResponse du pays concerné est transmise dans le fichier de retour.

Type « validateDocument » – validation d’un ticket de caisse

Le contenu du fichier est, comme pour le type « document », un document au format RetailForce.

Réponse

Le fichier de retour contient une liste éventuelle des erreurs (et des avertissements) issues de la validation.

Type « createClient » – création d’un FiscalClient

Le contenu du fichier correspond ici à un FiscalClient au format JSON (voir la documentation).

Réponse

« OK » lorsque la requête a été traitée avec succès.

Type « createClientByCloud » — création d’un FiscalClient à partir de données issues du Cloud

Le contenu du fichier est un document JSON présentant la structure suivante :

{
  "CompanyIdentification": 
  {
    "Type": 0, 
    "Identification": "UID"
  },
  "StoreNumber": "001",
  "TerminalNumber": "01",
  "ApiKey": "{ApiKey}",
  "ApiSecret": "{ApiSecret}"
}

Renvoie

L’uniqueClientId du client créé.

Type « restoreClientByCloud » : restauration d’un FiscalClient à partir des données du Cloud

Le contenu du fichier est un document JSON présentant la structure suivante :

{
  "CompanyIdentification": 
  {
    "Type": 0, 
    "Identification": "UID"
  },
  "StoreNumber": "001",
  "TerminalNumber": "01",
  "ApiKey": "{ApiKey}",
  "ApiSecret": "{ApiSecret}"
}

Résultat

L'uniqueClientId du client restauré.

Type « getClientId » - Recherche d’un client et récupération de son ID

Disponible à partir de la version 1.2.12

Le contenu du fichier est un document JSON présentant la structure suivante :

{
  "CompanyIdentification": 
  {
    "Type": 0, 
    "Identification": "UID"
  },
  "StoreNumber": "001",
  "TerminalNumber": "01"
}

Résultat

L'uniqueClientId du client créé.

Tapez « InitializeClient » - Initialisation du FiscalClient

Le contenu du fichier est un document JSON présentant la structure suivante :

{
  "UniqueClientId": "9607625f-1147-43a4-bf05-49319acbd9f6",
  "BookDate": "2022-03-10T08:52:33.3556282Z",
   "User": 
   {
     "Id": "1",
     "Caption": "Test",
     "LastName": "Test",
     "FirstName": "Test",
     "DateOfEntry": "2022-03-10T08:52:33.3556282Z"
  }
}

Les données fournies sont des données de test et doivent être remplacées par les données correctes.

Retour

Soit vide, soit un objet fiscalResponse correspondant au pays concerné.

Type « CloudConnect » - initialisation de la connexion au cloud

Le contenu du fichier est un document JSON présentant la structure suivante :

{
  "UniqueClientId": "9607625f-1147-43a4-bf05-49319acbd9f6",
  "ApiKey": "{ApiKey}",
  "ApiSecret": "{ApiSecret}",
  "PersistDays": {days} // optional, days until credentials are stored 
}
Attention : les identifiants sont stockés de manière chiffrée sur le disque. La persistance des identifiants constitue un risque potentiel pour la sécurité.

Renvoie

« OK » lorsque la requête a été traitée avec succès.

Type « AuditLog » - transmission d’une entrée du journal d’audit

Le contenu du fichier est un objet JSON présentant la structure suivante :

{
  "RecordDateTime": "2022-03-11T15:17:57.9859527",
  "UniqueClientId": "9607625f-1147-43a4-bf05-49319acbd9f6",
  "LogEntryType": 200,
  "Message": "OpenDrawer",
  "DocumentGuid": null,
  "User": null
}

Renvoie

Soit vide, soit un objet « fiscalResponse » du pays concerné (si cela est requis dans ce pays).

Type « digitalReceipt » – Transmission d’un reçu numérique

Ce type de fichier peut être utilisé pour transmettre un reçu numérique. 

Le contenu du fichier est un objet JSON présentant la structure suivante :

{
"UniqueClientId": "d5ecc344-e37a-40c6-bed4-a6b1e60e68c8",
"ReceiptMetaData": {
"DocumentType": 0,
"CustomDocumentType": null,
"DocumentGuid": "2394fef4-2339-459a-817e-e4cd86ce23f6",
"DocumentNumber": "1",
"DocumentId": "CS_01_01_1",
"BookDate": "2021-11-17T06:45:03.8203317",
"Amount": 141.0,
"Partner": null,
"Users": null,
"ProcessId": null,
"CancelledDocumentGuid": null,
"ItemIdArray": [
"1231",
"SW4471"
],
"ItemCodeArray": null
},
"PdfDataBase64": "JVBERi0xLjcKJeLjz9MKMSAwIG9iaiAKPDwKL0NvbG9yU3Bh..."
}

La propriété « ReceiptMetaData » correspond à l’objet ReceiptMetaData qui doit également être transmis lors d’un appel via l’interface REST. 

Dans l’exemple, le stream de données PDF a été abrégé par « ... ».

Résultat

Dans le fichier de retour, un lien au format QrCode (sous forme de chaîne de caractères) est renvoyé afin d’être affiché au client.

Configuration

L’interface du système de fichiers peut être activée dans la configuration client en attribuant une valeur au champ « FiscalClient.FileSystemInterfacePath ». Si ce champ est vide (valeur par défaut), l’interface de fichiers n’est pas active.

Cet article a été traduit automatiquement.

Articles associés

Commentaires

0 commentaire

Vous devez vous connecter pour laisser un commentaire.

Réalisé par Zendesk