====== Exportation des données de l'audit ======
:!: GoBD : Principes pour la tenue et la conservation régulière des livres, enregistrements et documents sous forme électronique ainsi que pour l'accès aux données
Sur **Chiffres d'affaires/Exportation des données de l'audit** vous accédez à l'exportation des données de l'audit. Les fichiers ainsi édités sont enregistrés au format CVS et peuvent être lus par l'administration fiscale. Veuillez faire attention au domaine comptable dans lequel vous vous trouvez. Si vous souhaitez sortir les données d'un domaine de comptes de caisse, comme par exemple UMSATZ, veuillez changer le domaine de comptes correspondant avant l'exportation GoBD.
Pour savoir comment changer de domaine comptable, cliquez ici. [[http://doku.pccaddie.com/doku.php?id=de:umsaetze:kontenbereichwaehlen:kontenbereichwaehlen|Kontenbereich sélectionner]]
Si vous avez besoin de données d'exportation provenant d'un domaine d'archives, veuillez passer au préalable dans le domaine d'archives correspondant.
Si vous sélectionnez le point de menu **Exportation des données de l'audit** la fenêtre suivante s'ouvre **Exportation des données de l'audit**:
{{de:umsaetze:gobd:datenexport.png?500|}}
Vous pouvez maintenant effectuer les réglages souhaités :
{{de:umsaetze:gobd:datenexport_nummeriert.png?500|}}
Au point (1), vous définissez la période à exporter.
Point (2) Vous avez ici la possibilité de choisir entre deux exportations PDF de factures.
* **Factures envoyées par e-mail**. Seules les factures effectivement envoyées par e-mail sont exportées.
ou
* **Toutes les factures**: Toutes les factures écrites pendant la période définie ci-dessus sont exportées sous forme de fichier PDF.
{{de:umsaetze:gobd:datenexport_rechnungen.png?500|}}
Au point (3), vous définissez un répertoire de sortie où les fichiers CVS doivent être exportés.
{{de:umsaetze:gobd:datenexport_nummeriert.png?500|}}
Si vous souhaitez crypter les fichiers à l'ouverture avec un mot de passe, saisissez un mot de passe correspondant au point (4). Celui-ci sera éventuellement nécessaire plus tard lors de l'ouverture des fichiers d'exportation.
Cliquez ensuite sur **Exportation** Point (5)
Pcc vous demande encore une fois si l'exportation fiscale doit être lancée pour la plage de comptes sélectionnée.
{{de:umsaetze:gobd:datenexport_starten.png|}}
Confirmez avec **Exporter**
Une fois l'exportation terminée, vous obtenez encore quelques informations sur l'exportation fiscale. Il s'agit de la plage de comptes éditée, de la période, de la date et de l'heure de l'exportation, du nom de l'ordinateur, de l'utilisateur Windows, de l'utilisateur Pcc et du répertoire d'édition.
{{de:umsaetze:gobd:datenexport_zusammenfassung.png?500|}}
Confirmez avec **OK**. Ensuite, l'explorateur de fichiers (Windows Explorer) s'ouvre avec le lien sélectionné (1) et un dossier ZIP (2). Dans le nom du dossier ZIP, vous pouvez déjà reconnaître la plage de comptes et la période exportées. Vous pouvez ouvrir le dossier ZIP en double-cliquant dessus.
{{de:umsaetze:umsaetze:gobd_explorer.png|}}
Dans ce dossier ZIP se trouve un autre sous-dossier qui porte le nom du domaine de comptes. Vous pouvez également ouvrir ce dossier par un double-clic. Il contient alors les fichiers CVS que vous pouvez ouvrir avec votre programme de tableur standard.
{{de:umsaetze:umsaetze:gobd_umsatz_neu.png|}}
Les fichiers d'exportation se présentent alors comme suit :
{{de:umsaetze:umsaetze:gobd_dateien.png?600|}}
Si vous avez attribué un mot de passe et que vous souhaitez ouvrir l'un des fichiers mentionnés ci-dessus, vous recevez le message suivant. Vous devez alors saisir le mot de passe que vous avez entré auparavant dans Pcc et cliquer sur **OK** confirmer.
{{de:umsaetze:umsaetze:gobd_pw.png|}}
===== Fichiers d'exportation =====
La liste ci-dessous indique le contenu de chaque fichier :
==== ARTICLE.CSV ====
Articles utilisés dans la période définie de la plage de comptes exportée
^ Nom du champ ^ Description ^
| CODE | ID unique |
| NOM | Nom |
| WAGR | ID du groupe de marchandises |
| NETTO | Prix net |
| BRUT | Prix brut |
| TVA | Taux d'imposition en pourcentage |
| COFI | Numéro de la comptabilité financière |
==== ARTICLE_GROUP.CSV ====
Groupes de marchandises utilisés dans la période définie du domaine comptable exporté
^ Nom du champ ^ Description ^
| CODE | ID unique |
| NOM | Nom |
| AREACODE | ID de la zone de réservation |
| AREANAME | Nom du domaine de réservation |
| FIBU | Numéro FiBu |
==== BOOKINGS.CSV ====
Toutes les écritures de la plage de comptes sélectionnée sont listées.
:!: Les champs importants pour les analyses économiques sont marqués en gras.
:!: Veuillez filtrer les lignes avec TYPE DE COMPTE "a" et "p" pour l'addition via BRUT DE COMPTE, car elles ne sont pas pertinentes pour le chiffre d'affaires. Le total de toutes les écritures devrait normalement être égal à 0, car les écritures de vente et les écritures de paiement s'annulent en termes de montant. Vous obtenez donc le chiffre d'affaires en filtrant encore les lignes avec le TYPE DE CONTENU "Z". Si vous filtrez uniquement sur le TYPE DE CONTENU "Z", vous obtenez les paiements.
{{tablelayout?rowsHeaderSource=Auto}}
^ Nom du champ ^ Description ^
| **KONTMITGCO** | Numéro de client Champ CODE de CUSTOMER.CSV (MITGCODE de GOLFMITG.DBF) |
| **KONTBEITCO** | Numéro d'article interne Champ CODE de ARTICLES.CSV (BEITCODE de GOLFBEIT.DBF) |
| KONTBEITSU | Quatre premiers caractères du numéro d'article public |
| **KONTBEITNA** | Texte de l'écriture ; prix :..... = Changements de prix |
| CONTEKNET | Prix d'achat de l'article comptabilisé (rarement utilisé) (net) |
| KONTVKORG | Prix de vente original en cas de rabais (brut) |
| **KONTBRUTTO** | Prix brut pour la ligne de poste, TVA incluse (prix total pour tous les articles ensemble - seules les lignes pour lesquelles un montant est indiqué ici sont pertinentes du point de vue comptable - si le montant est 0 ici, les enregistrements sont exportés pour information, par souci d'exhaustivité) |
| **CONTNETTO** | Prix net pour la ligne de poste sans TVA. |
| **KONTMWST** | Taux d'imposition en %. |
| KONTZAHLT | Montant payé - utilisé uniquement dans des cas spéciaux |
| CONTWAEHR | Devise pour les paiements en monnaie étrangère |
| **DATE DU CONTENU** | Date d'enregistrement |
| **HEURE CONTINUE** | Heure de réservation |
| **STATUT DU CONTENU** | Statut de l'entrée |
| | 0 = Mentions sans valeur comptable propre (en-tête de facture, etc.) |
| | 3 = Écritures normales |
| | 4 = Réservation avec prix variable (article "Divers", etc.) |
| | 5 = Écriture avec texte variable |
| | 7 = Ecritures par carte (rechargement sur cartes prépayées) |
| **CONTTYPE** | Type de réservation |
| | = Normal |
| | a = Soldes initiaux résultant d'un transfert de soldes de l'année précédente (non pertinent pour le chiffre d'affaires de l'année en cours) |
| | B = Écriture
|
| | R = En-tête de la facture |
| | Z = Paiement |
| | D = Supprimé (Deleted) |
| | p = Changements de prix (en cas de changement de prix d'articles avec stock, l'ancienne valeur à l'ancien prix est décomptabilisée dans CONTBRUTTO à des fins de documentation et la nouvelle valeur est à nouveau comptabilisée au nouveau prix - c'est pourquoi les enregistrements avec CONTTTYP=p doivent être ignorés dans les analyses des ventes) |
| | A = Adaptation du nombre d'articles |
| | U = Transfert |
| | K = Caisse |
| | k = Livre de caisse |
| | V = Écriture de valeur principale (Value) en cas de répartition sur plusieurs composants, pour lesquels le montant reste ici dans l'écriture principale et les écritures secondaires avec statut "w" ne sont utilisées que pour les mouvements de marchandises. |
| | W = Ecriture de mouvement de marchandises (si un article est réparti entre plusieurs, cette écriture ne doit pas être prise en compte dans le solde). |
| | x = Contrepartie correspondante si la valeur est répartie entre les composants, afin que les montants effectifs ne soient pas doublés. |
| | y = Enregistrement de liaison si un composant a encore des sous-composants |
| | v = Écritures de filiales correspondantes avec valeurs imputées au composant |
| | w = écritures filles de mouvements de stock, si le prix de vente n'est pas réparti entre les composants, mais que seul le comptage intéresse (dans ce cas, CONTBRUTTO et CONTNETTO sont donc également vides) |
| | e = Modification du prix d'achat - enregistrements par paires, décomptabilisation à l'ancien prix, réimputation au nouveau prix. Ces enregistrements permettent de noter les ajustements de prix dans le stock de marchandises - il ne s'agit pas de transactions réelles en caisse. |
| | f = Écriture de transfert entre les membres de la famille (doivent s'annuler mutuellement) |
| | q = Transfert de comptes PO - Détail de la quittance : il s'agit de lignes d'écriture qui permettent de documenter, lors de la compensation d'un compte PO par paiement ou par compensation avec d'autres avoirs, quels documents PO ont été touchés lors de l'opération. Ces enregistrements eux-mêmes ne doivent pas être saisis en valeur (CONTBRUTTO est 0), car les opérations sous-jacentes ont déjà été comptabilisées avec effet sur le produit à un autre endroit dans les documents sortants. |
| | t = TVA. Réservation de conversion pour la vente hors domicile |
| **KONTBEZ** | Statut |
| | 0 = Non comptabilisé |
| | 1 = En cours de facturation |
| | 2 = Recouvré |
| | 4 = Partiellement payé |
| | 5 = Payé |
| TOTAL DES COMPTES | //Actuellement non utilisé// |
| NOMBRE DE COMPTES | Nombre d'articles - pour les écritures de contre-passation avec montant négatif - pour les enregistrements de paiement, le montant du paiement dans la monnaie de départ |
| FACTEUR DE COMPTE | Facteur d'unité (pour les cas spéciaux où, par rapport au stock de marchandises, le facteur de vente, par exemple 1 verre, ne conduit qu'à la sortie de 0,2 litre - utilisé uniquement dans des cas exceptionnels et probablement pas pertinent pour la détermination de la valeur. Avec un offset de 100000, utilisé en outre pour décompter les crédits de points dans les systèmes d'abonnement). |
| CONTMAHND | Date de rappel |
| KONTMAHN | Niveau de rappel |
| **KONTRGNR** | Numéro de facture/document (les enregistrements sans numéro de document ne sont pas des opérations de caisse, mais des écritures internes à des fins de documentation. Les numéros de pièce sont attribués au début d'une opération de paiement afin de disposer d'une référence univoque, également en ce qui concerne les appareils de paiement EC. C'est pourquoi, lors de l'interruption des opérations de paiement, par exemple par l'interruption du paiement sur l'appareil EC, il peut y avoir des numéros de pièces réservés mais non utilisés, qui sont documentés en conséquence dans KONTBEITNA). |
| **KONTRGDAT** | Date de la facture |
| KONTBEZDAT | Date de paiement |
| KONTFIBU | Statut de mise à jour dans la comptabilité financière (pour l'interface comptable) |
| KONTAREA | Zone de caisse (en cas de grande installation avec plusieurs zones de caisse) |
| KONTSTAREA | Zone de statistiques (pour les évaluations par type de client, rarement utilisée) |
| KONTXINFO | Informations étendues pour les cas spéciaux |
| KONTSTORNO | //Actuellement non utilisé// |
| CONTRABAT | Taux de remise en %. |
| COMPTE UTILISATEUR | Identification d'utilisateur cryptée |
| NIVEAU DE COMPTE | Niveau de prix |
| KONTDTAPP | //Actuellement non utilisé// |
| KONTDTBOOK | //Actuellement non utilisé// |
| KONTPOS | Sous-position de l'élément de stock |
| KONTFISCAL | Fiscalisation dans le cadre de DSFinV-K : information sur la transaction |
| KONTFISGRP | DSFinV-K : Groupe de fiscalisation (société) |
| KONTFISBON | DSFinV-K : Numéro d'identification de fiscalisation |
| KONTFISTYP | DSFinV-K : Type d'opération |
| KONTFISFLG | DSFinV-K : Drapeaux de fiscalisation |
| KONTTABLE | //Actuellement non utilisé// - Champ de numéro de table avec numéro de parcours, le cas échéant |
| KONTREVINF | Informations sur l'annulation |
| KONTCHKSUM | Somme de contrôle des lignes habituellement non utilisée |
| KONTINDX01 | Lien interne |
| KONTINDX02 | Lien interne |
| KONTINDX03 | Lien interne |
==== CASH_PROTOCOL.CSV ====
Des informations détaillées sur les écritures de caisse sont éditées. Similaire au journal de caisse [[http://doku.pccaddie.com/doku.php?id=de:umsaetze:kassenprotokoll:kassenprotokoll|Kassenprotokoll]]
Le protocole de caisse a été introduit au début de l'année 2016.
Il s'est activé automatiquement chez le client dès que la mise à jour nécessaire a été installée.
:!: Les écritures antérieures à l'activation ne sont pas protocolées rétroactivement et ne sont donc pas éditées.
^ Nom du champ ^ Description ^
| KAPOVER | Protocole de caisse Version |
| KAPODATE | Date |
| KAPOTIME | Heure |
| KAPOTYPE | Type d'entrée |
| | B = Enregistrement |
| | S = Annulation |
| | C = Clôture journalière |
| | I = Information |
| KAPONR | Numéro de document |
| KAPONRREF | Document de référence |
| KAPOINFO | Information |
| KAPOTOT | Montant total |
| KAPOTOTCNT | Compteur total |
| KAPOVNP | Taux normal Pourcentage |
| KAPOVNN | Taux normal net |
| KAPOVNB | Taux normal brut |
| KAPOVR1P | Taux réduit 1 pour cent |
| KAPOVR1N | Taux réduit 1 Net |
| KAPOVR1B | Taux réduit 1 Brut |
| KAPOVR2P | Taux réduit 2 pour cent |
| KAPOVR2N | Taux réduit 2 Net |
| KAPOVR2B | Taux réduit 2 Brut |
| KAPOVSP | Taux spécial Pourcentage |
| KAPOVSN | Taux spécial net |
| KAPOVSB | Taux spécial brut |
| KAPOV0P | Hors taxe pourcentage (= 0) |
| KAPOV0N | Hors taxe Net |
| KAPOV0B | Hors taxe Brut |
| KAPOVNTOT | Total de la TVA |
| KAPOATT | Annexe |
| KAPOKONT | Plage de comptes / identifiant du mandant |
| KAPOCRRNCY | Monnaie |
| KAPOKASSNR | Numéro de caisse |
| KAPOUSER | Opérateur de caisse |
| KAPOPCNAME | Nom de l'ordinateur |
| KAPOPCUSER | Connexion ordinateur |
| KAPOCKSREC | Numéro d'enregistrement |
==== CASHBOOK.CSV ====
Écritures du livre de caisse
^ Nom du champ ^ Description ^
| KABUBELEG | Numéro de pièce - pour les clôtures journalières qui sont enregistrées dans le livre de caisse, on utilise ici le numéro de clôture journalière précédé de "TA". |
| KABUDATUM | Date de l'écriture. |
| KABUBELDAT | Le cas échéant, date de pièce justificative différente. |
| KABUZEIT | Heure de l'enregistrement |
| KABUTEXT | Texte du document |
| KABUDEKRCO | Lien avec MITGCODE dans le tableau des clients (numéro de débiteur ou de créancier) |
| KABUBEITCO | Lien avec BEITCODE dans le tableau des articles (article de compte) |
| KABUZARTCO | Lien avec BEITCODE dans le tableau des articles (compte de contrepartie ou type de paiement) |
| KABUZARTNA | Désignation du compte de contrepartie ou du type de paiement |
| KABUBRUTTO | Montant comptable brut |
| KABUNETTO | Montant comptable hors TVA. |
| KABUMWST | Taux de TVA |
| KABUSALDO | Solde du compte après la comptabilisation |
| KABUSALDOG | Solde du compte de contrepartie après l'écriture |
| KABUSTATUS | Statut de l'écriture |
| | K = de la caisse un encaissement ou un décaissement préenregistré |
| | U = depuis le back office une écriture préenregistrée |
| | V = Comptabilisé |
| | Remarque : pour les pièces du livre de caisse comptabilisées, deux enregistrements sont créés dans GOLFKONT.DBF (Bookings), respectivement le compte et le compte de contrepartie. |
| KABUNUTZER | Identification de l'utilisateur du collaborateur |
| KABUDSTAT | Statut d'annulation |
| KABUDUSER | Identification de l'utilisateur annulation |
| KABUDDATE | Date de l'annulation |
| KABUDTIME | Heure de l'annulation |
| KABUDWAY | Identification du chemin d'annulation |
| KABUAREA | Numéro de caisse de la saisie |
==== CHANGE_PROTOCOL.CSV ====
Toutes les modifications sont consignées dans ce fichier.
* modifications d'articles
* Modifications utilisateur (nouveau, modifier, supprimer)
* Confirmer le solde de caisse
* Désactiver le livre de caisse conforme à GoDB
* Clôture journalière
* Annuler plusieurs factures
* Annuler une facture
* Modification du numéro de facture
^ Nom du champ ^ Description ^
| DATE | Date |
| TIME | Heure |
| TYPE | Type d'entrée |
| | CHG = Configuration |
| | CASH = Écriture de caisse |
| KONT | Domaine comptable / Identification du mandant |
| USER | Utilisateur de la caisse |
| LINK | Lien vers d'autres informations (numéro de document, tableau d'articles, utilisateur, etc.) |
| INFO | Autres informations détaillées sur la documentation |
==== CUSTOMER.CSV ====
Clients utilisés dans la période définie de la plage de comptes exportée
^ Nom du champ ^ Description ^
| CODE | ID du membre |
| SUCH | Code de recherche |
==== INFO.TXT ====
Informations sur l'exportation fiscale
* Plage de comptes éditée
* Période des écritures / factures
* date et heure de l'exportation
* Nom de l'ordinateur
* Utilisateur Windows
* Utilisateur PC CADDIE
* Chemin des données vers le répertoire principal de PC CADDIE
=====Réponses pratiques sur les documents individuels=====
====1. les articles hors domicile avec 19% de TVA====
**Boisson de la tournée consommée sur place - TVA néanmoins à 7**
L'article "Boisson ronde" a été créé en tant qu'"article hors domicile" avec une TVA de 7%. Cela est tout d'abord correct du point de vue du contenu, car il s'agit généralement de petites bouteilles PET que le golfeur emporte sur le parcours et qu'il ne boit pas dans un restaurant. (c'est en tout cas ce que je sais de la pratique, je ne peux rien dire sur le fond du cas concret).
Je suppose que dans ce cas, cette bouteille devait tout de même être ouverte au restaurant et que le caissier a utilisé cet article sans le savoir et a augmenté le prix à 3,80 pour une consommation sur place. Le texte complémentaire "Sur place" a en tout cas été saisi manuellement pour justifier l'augmentation de prix.
Sauf qu'avec de telles modifications manuelles, il n'y a bien sûr aucun lien technique avec la TVA. - il s'agit de texte pur, la caisse ne peut pas juger de la composante fiscale dans un tel cas et l'employé n'en avait probablement pas non plus conscience.
{{de:umsaetze:gobd:betr1.png|}}
====2. enregistrements dans BOOKINGS sans KONTRGNR====
Notamment les encaissements et les recharges de cartes de bons.
► En principe, les positions de document avec un KONTRGNR vide peuvent être omises lors de l'analyse. Dans ce cas, il s'agit d'écritures de documentation pour les cartes de crédit qui sont en principe utilisées dans tous les domaines (donc aussi dans le golf, par exemple pour l'achat de balles de practice). Nous n'avons pas vérifié comment cela se passe chez les clients.
Quoi qu'il en soit, il est tout à fait possible que la caisse du restaurant utilise des crédits de cette carte qui ont été comptabilisés à la caisse du terrain de golf. Il s'agit en fin de compte de processus qui, à mon avis, sans connaître l'organisation concrète chez le client, entraîneraient une compensation entre le restaurateur et l'établissement de golf. En fin de compte, nous ne pouvons que proposer toutes les possibilités pour représenter correctement ces opérations.
En ce qui concerne les deux écritures sans numéro de justificatif auxquelles vous faites allusion, il s'agit de simples transferts d'une personne à une autre - par exemple lorsque la carte de crédit de l'homme sert à payer la facture de sa partenaire. Ces écritures ne sont en fin de compte qu'informatives à des fins de documentation, mais ne font finalement pas partie du ticket de caisse, pour lequel il s'agit uniquement de payer par exemple des repas avec le crédit de la carte, c'est pourquoi ces transferts n'ont pas de numéro de document. (Ils s'annulent de toute façon par rapport au montant en COMPTANT).
{{de:umsaetze:gobd:betr2.png|}}
====3. transfert familial ====
KONTRGNR 2019009971 : 22 enregistrements, dont 2 avec KONTTYP f
► En principe, les enregistrements avec le TYPE DE CONTENU "f" sont des transferts familiaux. Ceux-ci permettent généralement de documenter, par exemple, le transfert du repas de la fille au père lorsque ce dernier règle la facture pour les enfants - d'où la désignation.
Ici, l'entrée concrète est grisée - techniquement, il s'agit de deux enregistrements, le montant est décomptabilisé pour un client et comptabilisé pour l'autre - l'opération s'annule et ne joue finalement aucun rôle du point de vue du chiffre d'affaires de la caisse :
{{de:umsaetze:gobd:betr31.png|}}
Dans le cas présent, un justificatif d'un montant total de 135,30 EUR a été réglé par carte de crédit pour un montant de 30,00 EUR, les 105,30 EUR restants ont été payés en espèces - jusqu'ici, il s'agit d'une opération relativement normale.
Probablement en raison d'un malentendu lors du service, un "transfert familial" au sens figuré s'est produit par inadvertance : Le chiffre d'affaires qui avait été comptabilisé à l'origine sur le compte standard "clientèle occasionnelle" sans client concret, a été transféré lors du processus de paiement sur un client nommé "bon, bon" - donc manifestement un compte de compensation.
{{de:umsaetze:gobd:betr4.png|}}
====4) Positions de ticket de caisse sans numéro de position====
KONTRGNR 2019011082 : 214 enregistrements dans le fichier Bookings - dont 212 ont le type d'enregistrement (KONTTYP) "q".
► Dans ce cas, il s'agit du paiement d'une dette dans le compte client au moyen d'une carte de crédit. Il se trouve que dans la caisse, il y a la possibilité d'enregistrer des documents dans un compte "sur facture". Ces écritures apparaissent alors dans les comptes de caisse de cette manière - ici dans l'exemple du document 2019001207 :
{{de:umsaetze:gobd:betr52.png|}}
Pour ces clients, un compte PO est ensuite géré, dans lequel ces reports sont regroupés et à partir duquel certains clients génèrent des notes de débit ou des décomptes mensuels. Dans ce cas concret, la fonction de paiement de la dette à partir du compte PO a été utilisée dans la caisse - tous les documents sont alors rassemblés avec leurs détails et le solde total à payer est calculé - dans ce cas, 35,57 euros :
{{de:umsaetze:gobd:betr61.png|}}
Dans ce cas, l'encaissement du crédit du bon entraîne finalement un crédit sur le compte PO, qui y compense la créance, et tout est réglé. Les différents enregistrements avec l'identifiant "*" suivi de "PER", "INV" ou "DET" (pour personne, facture et détail) servent uniquement à la documentation interne des positions qui ont été touchées par cette opération. De plus, ces enregistrements sont marqués par CONTTYPE "q". Les enregistrements de la demande proprement dite sont bien entendu déjà disponibles ailleurs (vous devriez également les trouver aux endroits correspondants dans l'exportation).
Comme ces enregistrements ne servent qu'à la documentation, les champs KONTBRUTTO et KONTNETTO sont ici aussi à 0. Globalement, la caisse est programmée de telle sorte que KONTBRUTTO doit contenir la valeur vraiment décisive.
{{de:umsaetze:gobd:betr7.png|}}
====5. positions de ticket de caisse uniquement, 2 enregistrements de données : où se trouvent l'en-tête du ticket de caisse et le paiement ?====
KONTRGNR 2019018907 - Commandes et paiements à des dates différentes
► Dans notre solution de caisse, il était possible de laisser en place dans la caisse des commandes existantes qui, comme vous le voyez ici dans l'exemple, avaient déjà été tapées ("commandées") en octobre. Elles étaient alors déjà comptabilisées de manière fixe et ne pouvaient plus être supprimées (le cas échéant, elles ne pouvaient être annulées que par une écriture de contrepartie documentée). Cela a simplifié les paiements habituels dans le domaine des clubs, par exemple à la fin du mois, etc.
{{de:umsaetze:gobd:betr81.png|}}
Dans ce cas, la période est en outre assez extrême : Le client n'a finalement payé ses deux positions de bon d'octobre 2019 qu'en mai 2020.
Comme l'exportation a été limitée aux opérations de l'année 2019, les écritures de commande sont certes présentes dans votre exportation, mais l'en-tête du document, la position de commande de mai 2020 et le paiement du montant total font partie de l'exportation pour l'année 2020.
====6. traitement des bons d'achat====
KONTRGNR 2019007581 Traitement des bons d'achat
► Dans ce cas, il s'agit à nouveau, comme au point 4, de la compensation d'une dette dans le compte client au moyen d'une carte de crédit. Un document est alors créé avec les positions de commande, qui sont compensées par un transfert dans le compte PO. Du point de vue de la caisse, cela se présente alors comme suit :
{{de:umsaetze:gobd:betr10.png|}}
Dans le compte PO (ici du restaurant), les écritures apparaissent alors sous cette forme :
{{de:umsaetze:gobd:betr11.png|}}
En fin de compte, seuls les totaux des documents y sont rassemblés et gérés comme un compte client.
Pour le document en question 2019007581, le solde client de 106,78 a été payé en utilisant le crédit de la carte de crédit. C'est pourquoi le prélèvement de crédit de la carte de crédit est à nouveau comptabilisé sur ce compte PO, afin que celui-ci soit finalement équilibré. Il n'y a pas plus de détails dans ce document - le lien avec les prestations payées par le biais du compte OP est ainsi devenu très indirect. Dans certains cas, il n'est possible de le vérifier qu'en consultant les comptes dans le logiciel.
On ne peut pas voir ici dans les opérations où la carte de bon a été chargée, il existe pour cela des évaluations dans le logiciel pour chaque carte de crédit - selon la constellation chez le client, il est concevable que le chargement soit effectué dans l'entreprise de golf indépendamment de la restauration et qu'une utilisation de ce crédit dans le restaurant conduise à une facturation entre l'entreprise d'installation et l'entreprise de restauration. (voir aussi le point 2.)
====7. 3 enregistrements, 100,00 bon vente (avec annulation) et (néanmoins) paiement 100,00====
KONTRGNR 2019016690
► Il s'agit ici de trois opérations qui ont eu lieu immédiatement l'une après l'autre. Comme Monsieur Axel Heck fait partie de notre équipe, je suppose que la fonction de bon d'achat devait être testée ou démontrée ici.
1er document 2019016687 13:12 : vente d'un bon d'achat de 100,00 euros et paiement de celui-ci en espèces.
{{de:umsaetze:gobd:betr12.png|}}
2. 13h27, ce justificatif a été annulé, c'est pourquoi un justificatif d'annulation 2019016690 a été créé, qui annule avec un signe inversé l'opération de vente proprement dite. Le bon d'achat est donc à nouveau dans la caisse en tant que produit commandé.
3. la vente du bon a été annulée dans la caisse et comptabilisée en contrepartie. Il s'agit donc maintenant d'un document 0, qui a été décomptabilisé à 13:33 avec le numéro de document 2019016691. Le document 0 a été décompté à 13:33.
En fin de compte, toutes les écritures dans ce contexte s'annulent mutuellement et ne font que documenter une opération de vente d'un bon qui a été à nouveau entièrement annulée.