Cet article décrit la correspondance entre le modèle d’objet de document (DOM) de RetailForce et le modèle iEKA lituanien.
Correspondance des documentTypes
En Lituanie, on distingue principalement les types de documents suivants (appelés « type de document ») :
- FiscalReceipt – transactions de vente
- nonFiscalReceipt – documents à des fins diverses
- FiscalDay – rapport de clôture quotidien
Au sein de la catégorie « nonFiscalReceipt », il existe d’autres types permettant d’opérer des distinctions plus précises.
Tous ces types (FiscalReceipt, NonFiscalReceipt, FiscalDay) doivent être transmis au système iEKA et sont donc considérés comme des « documents fiscaux » selon la définition de RetailForce, c’est-à-dire des documents devant être fiscalisés. La seule différence réside dans le fait que les NonFiscalReceipt, contrairement aux FiscalReceipt et aux documents FiscalDay, ne sont pas signés à l’aide d’un module de sécurité.
| Lituanie | RetailForce documentType | ||||
| Type | Type | Description | N° | Description | Remarques |
| fiscalReceipt | reçu | Justificatif de caisse – vente de biens/services | 0 | Reçu | - |
| fiscalReceipt | reçu | Reçu nul | 1 000 | Reçu nul | - |
| nonFiscalReceipt | Document de retour non fiscal | Justificatif de caisse destiné à l’enregistrement des retours, des échanges et des remboursements | 0 | Reçu |
Il s’agit du même type de document qu’un ticket de caisse standard. Correspondance : SI
|
| nonFiscalReceipt | document d'annulation non fiscal | Interruption d’une transaction avant son achèvement, transaction incomplète | 0 | Un reçu | est généré lorsque le point de terminaison POST /api/v1/transactions/cancelDocument est appelé. |
| - | - | - | 1 | Facture | Non pris en charge pour le moment |
| - | - | - | 2 | Bon de livraison | Non implémenté à ce stade |
| nonFiscalReceipt | Document de collecte non fiscal |
Opération de paiement, retrait d'argent de la caisse | 10 | PayOut | Les opérations de paiement doivent être transmises avec des valeurs NÉGATIVES (GrossValue, Amount, etc.) |
| nonFiscalReceipt | Document financier non fiscal |
Opérations spécifiques liées aux pharmacies | 10 | PayOut | Non pris en charge pour le moment |
| nonFiscalReceipt | Document de collecte non fiscal | Opérations de dépôt, par exemple dépôt de monnaie | 11 | PayIn | Les opérations de PayIn doivent être transmises avec des valeurs POSITIVES (GrossValue, Amount, etc.) |
| nonFiscalReceipt | nonFiscalFinancialDocument | Opérations spécifiques liées aux pharmacies | 11 | PayIn | Non pris en charge pour le moment |
| - | - | - | 12 | ProformaInvoice | Non implémenté à ce stade |
| - | - | - | 13 | Commande client | Non implémenté à ce stade |
| nonFiscalReceipt | preOrderDocument | - | 14 | PreliminaryReceipt | - |
| - | - | - | 15 | Reçu de paiement | Non implémenté à ce stade |
| - | - | - | 80 | LongTermOrder | Type de document pris en charge |
| nonFiscalReceipt | document de collecte non fiscal | Opérations de dépôt, par exemple dépôt de monnaie | 90 | OpeningBalance | est considéré comme un PayIn |
| nonFiscalReceipt | document non fiscal | « Rapport (X) » – rapport intermédiaire | 98 | CashCheck | Un CashCheck peut être généré via le point de terminaison GET /api/v1/closing/{clientId}/endofdayDocument. Toutefois, avant toute opération storeDocument, les champs documentType et documentCaption doivent être modifiés en conséquence |
| fiscalDay | fiscalDay | « Rapport (Z) » - rapport de clôture quotidien | 99 | EndOfDay | Un document « EndOfDay » peut être généré via le point de terminaison GET /api/v1/closing/{clientId}/endofdayDocument, puis enregistré via storeDocument. |
| - | - | - | 100 | Inventaire | Non pris en charge pour le moment |
| nonFiscalReceipt | Document financier non fiscal | Structure « Autres opérations d’encaissement » (collectionType : 3 – achat) | 101 | Achat | Fonctionnalité actuellement non implémentée |
| - | - | - | 1001 | Impression du reçu | Fonctionnalité actuellement non implémentée |
| - | - | - | 1100 | DiversNonFiscal | Non implémenté à ce stade |
Mappage des PaymentTypes
Le tableau suivant présente les modes de paiement décrits dans la documentation technique du système lituanien iEKA et leur correspondance avec RetailForce DOM.
| <paymenttype> iEKA Lituanie</paymenttype> | « PaymentType » RetailForce | Remarques | |
| 1 - Espèces | Espèces | 0 | Paiement en espèces |
| 2 - Paiement par carte de débit/crédit | EcCard | 1 | Paiement par carte de débit |
| 2 – Paiement par carte de débit/crédit | CreditCard | 2 | Paiement par carte de crédit |
| 3 – Autre carte de paiement (par exemple, carte de fidélité) | Fidélité | 13 | |
| 4 – Bons d’achat | MultiPurposeVoucher | 4 | Les bons à usage unique (3) ne sont actuellement pas pris en charge en tant que PaymentType, mais doivent être transférés dans l’élément « positions ». |
| 5 - Mandat postal | BankAccount | 11 | Paiement par virement bancaire |
| 6 - Remboursé par le budget de la Caisse d’assurance maladie obligatoire | non pris en charge | ||
| 7 – Remboursé par le budget de l’État | non pris en charge | ||
| 8 - Cryptomonnaie | Crypto | 9 | |
| 9 – Autre | non pris en charge | ||
| Structure « Autres opérations de collecte d’espèces » (collectionType 1 – dépôt) | Dépôt | 6 | Non pris en charge en Lituanie en tant que mode de paiement spécifique, mais en tant qu’opération de collecte d’espèces |
| 10 – Arrondi | ne constitue pas un mode de paiement distinct dans RetailForce, mais est représenté par l’élément « rounding » (DocumentPosition.rounding). | ||
| NoCash | 7 | Non pris en charge pour le moment | |
| Aucun | 8 | Non pris en charge pour le moment | |
| Applications pour téléphones mobiles | 10 | Non pris en charge pour le moment | |
| Fiche client | 12 | Non pris en charge pour le moment | |
| Chèque | 14 | Non implémenté à ce stade | |
| CreditNote | 15 | Non pris en charge pour le moment | |
Mappage des BusinessTransactionTypes
Les BusinessTransactionTypes de RetailForce sont essentiellement mis en correspondance avec ce que l’on appelle des « opérations » en Lituanie.
| Lituanie | RetailForce | |
| Opération | N° | BusinessTransactionType |
| Opération de vente | 0 | Chiffre d’affaires |
| Ajouts de remises | 1 | Remise |
| Opération de versement (collectionType 1 – dépôt) | 2 | Dépôt de vides |
|
PaymentType 4 – bons PayOutType 4 – bons |
3 | Bon à usage unique |
|
PaymentType 4 – bons PayOutType 4 – bons |
4 | MultiPurposeVoucher |
|
Non enregistré Dans la législation lituanienne, les pourboires ne sont pas considérés comme des transactions commerciales dans le secteur du commerce de détail et de l’hôtellerie-restauration. Ils sont traités comme des revenus personnels. |
5 | Pourboire |
| Non enregistré. | 6 | Pourboire d’entreprise |
| Opération PayIn (type de recette 1 – dépôt) | 7 | Dépôt |
| Autres opérations d’encaissement en espèces (sens d’encaissement OUT) | 10 | Paiement |
| Autres opérations de collecte d'espèces (sens de collecte IN) | 11 | PayIn |
| Autres opérations de collecte d’espèces (direction de collecte IN ou OUT) | 90 | MoneyTransfer |
| Non implémenté à ce stade | 91 | Différence de caisse |
| Non pris en charge | 92 | |
| Non pris en charge | 93 | |
collectionTypes
Les autres opérations de paiement sont représentées par les « collectionTypes ».
| Lituanie | RetailForce | |
| collectionType | N° | Correspondance |
| Dépôt | 1 |
PaymentType : [6] = Dépôt BusinessTransactionType : [7] = Dépôt |
| Autre | 2 | non mappé |
| Achat | 3 | Non pris en charge pour le moment |
| Remboursement | 4 |
SI :
|
Le système RetailForce enregistre les échanges avec le système iEKA. Ces fichiers de débogage sont stockés dans le répertoire C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.
Pour plus de détails, consultez l’article « Communication iEKA ».
Cet article a été traduit automatiquement.
Commentaires
0 commentaire
Vous devez vous connecter pour laisser un commentaire.