Codes personnalisés vs codes par défaut : les codes comptables peuvent être personnalisés par les clients Smeetz afin de correspondre à leur propre plan comptable. Toutefois, le système fournit des codes par défaut si le client ne souhaite pas en configurer de spécifiques.

Note spéciale concernant les codes de vente : pour les transactions de vente (code comptable 3200), le code précis utilisé dépend du champ « code comptable » défini au niveau des prix des produits dans le back-office Smeetz. Cela permet aux organisateurs d’affecter différents comptes de revenus selon les catégories ou types de produits.

Actifs (1000–1999) : Éléments que l’organisation possède ou qui lui sont dus. Lorsqu’ils sont débités, les actifs augmentent ; lorsqu’ils sont crédités, les actifs diminuent.

Passifs (2000–2999) : Éléments que l’organisation doit. Lorsqu’ils sont crédités, les passifs augmentent ; lorsqu’ils sont débités, les passifs diminuent.

Revenus (3000–3999) : Produits générés. Lorsqu’ils sont crédités, les revenus augmentent ; lorsqu’ils sont débités (cas rare), les revenus diminuent.

Charges (4000–4999) : Coûts engagés. Lorsqu’elles sont débitées, les charges augmentent ; lorsqu’elles sont créditées (cas rare), les charges diminuent.

Date de visite (date de l’événement ou de la prestation) – utilisée pour une comptabilité d’engagement (accrual accounting).
Remarque : la date réellement prise en compte est le maximum entre la date de visite et la date de synchronisation. En effet, il est possible dans Smeetz d’effectuer une vente pour un billet dont la date de visite est déjà passée. Dans ce cas, la reconnaissance du chiffre d’affaires se fera à la date de synchronisation afin d’éviter toute comptabilisation rétroactive.

Date de synchronisation (date à laquelle la transaction est enregistrée dans le système) – utilisée pour une comptabilité de caisse (cash-basis accounting).
Remarque : cette précision est importante car Smeetz permet l’utilisation du POS hors ligne. Les ventes peuvent donc être réalisées sans connexion, mais elles ne sont enregistrées dans le système qu’au moment de la synchronisation en ligne. Par exemple, une vente effectuée hors ligne il y a deux jours mais synchronisée aujourd’hui aura une date de synchronisation correspondant à aujourd’hui, ce qui évite également toute rétroactivité.

Vente initiale : Enregistre le montant total dû par le client (Comptes clients / Créances clients) et l'obligation de fournir les services (Produits constatés d'avance / Revenus différés).

Reconnaissance des revenus : Lorsque les services sont fournis (selon la configuration de la date comptable choisie par le client), l'argent est transféré des Produits constatés d'avance vers le Chiffre d'affaires réel.

Reconnaissance des taxes : Sépare et suit de manière appropriée les montants de la taxe de vente pour les rapports fiscaux.

Remises (Discounts) : Lorsque des remises sont appliquées, elles réduisent à la fois les Créances clients et les Produits constatés d'avance. Les remises sont générées séparément car il est possible de les appliquer à un moment différent de la vente initiale.

Reconnaissance des remises : Lorsque les services sont fournis (selon la configuration de la date comptable choisie par le client), le montant de base de la remise est transféré du Chiffre d'affaires vers les Produits constatés d'avance.

Reconnaissance fiscale des remises : Sépare et suit de manière appropriée la part de taxe correspondant à la remise pour les rapports fiscaux.

Annulations : Lorsque des ventes sont annulées, les écritures de vente initiales sont contrepassées (annulées).

Annulations de remises : Lorsque des remises sont annulées, les écritures de remise initiales sont contrepassées.

Réception du paiement : Enregistre l'argent reçu de la part des prestataires de services de paiement et réduit le montant dû par les clients (Créances clients).

Remboursements : Contrepasse le processus de paiement lorsque les clients demandent un remboursement.

Représente l'argent détenu par le prestataire de services de paiement tiers (Adyen) pour le compte de l'organisateur.

Agit comme un compte d'attente ou de compensation (clearing) pour les fonds reçus des clients avant qu'ils ne soient transférés vers le compte bancaire de l'organisateur.

Il s'agit du seul compte de paiement où les fonds transitent par Smeetz avant d'atteindre l'organisateur.

Tous les versements (payouts) vers le compte bancaire de l'organisateur proviennent de ce compte.

Représente les espèces (devises physiques) et autres paiements directs reçus des clients sans l'intermédiaire du processeur de paiement Smeetz, qu'il s'agisse de méthodes de paiement hors ligne ou via des processeurs de paiement externes.

Chaque méthode de paiement configurée par l'organisateur aura son propre compte dédié et son code personnalisé.

Ces paiements parviennent directement à l'organisateur sans que Smeetz n'intervienne dans le flux de la transaction.

Ce type de compte est exclusivement réservé aux clients ayant configuré des points de vente (locations) physiques.

Ces points de vente permettent la gestion des espèces (transferts de fonds et corrections de caisse pour les excédents/manquants) sur des emplacements distincts. Les points de vente peuvent être liés à des terminaux POS physiques (par exemple, un ensemble de terminaux liés au même emplacement) ou à tout autre lieu défini par l'organisateur (par exemple : Banque, Coffre-fort, etc.).

Chaque point de vente possède son propre compte (ex: « Caisse - Emplacement 1 », « Caisse - Emplacement 2 »).

Cela permet le suivi des paiements en espèces, des transferts entre emplacements et des corrections de caisse spécifiques à chaque lieu (excédents/manquants).

Chaque emplacement disposera d'un code de compte personnalisé unique défini par l'organisateur.

Si une transaction n'est pas liée à un emplacement défini, elle apparaîtra simplement sous le nom de compte « Cash » (par exemple, pour les paiements en espèces effectués hors terminal POS).

Frais de réservation : Frais de plateforme facturés pour l'utilisation de notre système de réservation. Ils sont générés à la date de synchronisation de la vente, quel que soit l'état du paiement.

Frais de paiement : Frais de traitement des paiements, facturés à des moments différents selon que le client dispose ou non d'une configuration IC++ :

Taxe IDIV : Taxe spécifique sur les frais applicable aux clients de Lausanne. Elle est prélevée sous forme de pourcentage des ventes nettes (qu'elles soient payées ou non) et elle est générée lors de la création du relevé de réservation (booking statement).

Taxe sur les frais : TVA appliquée aux frais de réservation et de paiement.

Émission de bons d'achat : Lorsque des cartes-cadeaux ou des bons d'achat sont vendus (qu'ils soient payés ou non), cela enregistre l'obligation (passif) de fournir des services futurs.

Transferts de fonds : Déplacer de l'argent entre différents comptes de caisse (expliqués dans la section « Comptes de caisse »).

Corrections de caisse (Gain) : Ajustements pour les excédents comptables (lorsque l'argent physique est supérieur au montant attendu).

Corrections de caisse (Perte) : Ajustements pour les manquants comptables (lorsque l'argent physique est inférieur au montant attendu).

Déductions de frais : Déduction des frais accumulés sur le versement (payout).

Transferts bancaires : Transferts bancaires depuis le compte Smeetz Pay Acquiring (moins les frais) vers les comptes bancaires de l'organisateur.

Date de synchronisation (DATETIME) : La date et l'heure auxquelles l'événement commercial a été finalisé et synchronisé dans notre base de données. Cela représente le moment où la transaction a été enregistrée dans notre système.

Date de création (DATETIME) : L'horodatage du moment où l'enregistrement original de la transaction a été créé pour la première fois dans le système source.

Date de modification (DATETIME) : L'horodatage du moment où l'enregistrement de la transaction a été modifié ou mis à jour pour la dernière fois.

Date comptable (DATETIME) : La date à laquelle la transaction doit être reconnue à des fins de reporting financier. Cette date peut différer de la date de synchronisation selon les règles comptables (expliquées dans la section « Logique de la date comptable » ci-dessus).

ID de l'écriture comptable (STRING) : Un identifiant unique pour chaque écriture au journal, composé de l'ID de la transaction et de l'identifiant du type d'écriture (ex : « 12345S », « 12345F »..). Cela garantit que chaque écriture comptable peut être identifiée de manière unique et tracée jusqu'à sa source.

Événement (STRING) : La catégorie d'événement commercial de haut niveau (ex : « Ventes », « Paiement », « Frais », « Bon d'achat », « Transfert d'espèces », « Versement »). Cela permet un regroupement simplifié pour le reporting.

Code du compte de débit (STRING) : Le code numérique identifiant le compte à débiter (ex : « 1050 », « 2030 », « 3200 »).

Nom du compte de débit (STRING) : Le nom descriptif du compte à débiter (ex : « Créances clients », « Produits constatés d'avance », « Chiffre d'affaires »).

Code du compte de crédit (STRING) : Le code identifiant le compte à créditer.

Nom du compte de crédit (STRING) : Le nom descriptif du compte à créditer.

Valeur débit (NUMERIC) : Le montant à enregistrer en tant que débit. Il s'agit toujours d'un nombre positif représentant l'augmentation du compte de débit.

Valeur crédit (NUMERIC) : Le montant à enregistrer en tant que crédit. Il s'agit toujours d'un nombre positif représentant l'augmentation du compte de crédit. Cette valeur doit toujours être égale à la valeur débit pour que les écritures soient équilibrées.

Référence de la commande (STRING) : La référence de commande destinée au client pour la traçabilité par commande. Affiche « N/A » pour les transactions de frais et de versements (payouts) qui n'ont pas de commandes associées.

ID du relevé de réservation (STRING) : L'identifiant interne du relevé de réservation (Booking Statement ID) utilisé pour lier les transactions à des relevés de réservation spécifiques.