Comcash Verfahrensdokumentation

Werbung
Technische Verfahrensdokumentation zur
Kassensoftware COMCASH ab Version 3.2b
1
2
Technische Verfahrensdokumentation zur Kassensoftware
COMCASH ab Version 3.2b (Seiten 1-6)
(ab Version 3.3 build 2236 können dem Finanzamt die prüfungsrelevanten Daten mit position.dat,
kassenstorno.dat und belege.dat über eine GDPdU-Schnittstelle bereitgestellt werden: unter
Büro/Umsätze/Kassenbuch erscheint nach Doppelklicken auf die Überschrift „Kassenbuch“, unten am
Bildschirm neben dem Button „Konten“ ein neuer Button „Finanz“. Dort muss der Prüfungszeitraum
eingegeben und auf den Button „Export“ geklickt werden, womit die folgenden drei Dateien in das
voreingestellte Verzeichnis für die tägliche Datensicherung gespeichert werden:
„Saloname_von_bis_belege.csv“, „Saloname_von_bis_kassenbons.csv“ und
„Saloname_von_bis_stornoprotokoll.csv“)
1.) Kassenbons
Alle Kassiervorgänge werden in den beiden Dateien bon.dat und position.dat
gespeichert.
Für jeden Kassenbon wird ein Datensatz in der bon.dat erzeugt.
Alle in den Kassenbons enthaltenen Kassenbonpositionen (Artikel oder Dienstleistungen) werden jeweils mit einem Datensatz in der position.dat gespeichert.
bon.dat:
Die bon.dat beinhaltet eine interne Nummer mit verfahrensbedingten Lücken
und eine fortlaufende Kassenbonnummer ohne Lücken.
Wenn ein Kunde in die Kasse geholt wird, wird ein neuer Datensatz in der bon.dat
angelegt. Die interne Nummer wird automatisch auf den um eins erhöhten Wert des
letzten Datensatzes der betreffenden Filiale gesetzt. Die Kassenbonnummer wird
zunächst auf den negativen Wert derselben internen Nummer gesetzt. Das Feld
„kassiert“ wird auf „0“ (false) gesetzt.
Wird ein Kassenbon abkassiert, wird die Kassenbonnummer auf den um eins
erhöhten Wert der letzten Kassenbonnummer gesetzt. Das Feld „kassiert“ wird auf
„1“ (true) gesetzt.
Die letzte interne Nummer unterscheidet sich von der letzten
Kassenbonnummer, weil Kunden, die zunächst in die Kasse geholt wurden und
damit bereits ein Kassenbon mit einer internen Nummer erzeugt wurde, noch vor
dem Kassiervorgang wieder storniert werden, wenn es sich z.B. um einen falschen
Kunden handelte oder der betreffende Kunde zwar erwartet wurde, dann aber nicht
zur Bedienung/Behandlung erschienen ist. Infolge dessen ist die letzte interne
Nummer typischer Weise höher als die letzte Kassenbonnummer.
Darüber hinaus werden weitere interne Nummern erzeugt und in der Bon.dat
gespeichert, wenn Angebote geschrieben werden, oder wenn unter Verwendung
des Zusatzmoduls Lagerhaltung/Bestellwesen der Verbrauch von Kabinettware
verbucht wird.
Auch die Reihenfolge der internen Nummern und der Kassenbonnummern kann
sich unterscheiden, weil beliebig viele Kunden in die Kasse geholt werden können,
diese dann aber in anderer Reihenfolge abkassiert werden.
3
Zahlungsarten:
Ist das Feld „Zahlungsart“ auf „Kabinett“ gesetzt, handelt es sich um eine
Kabinettwarenbuchung. Bei den Abschlüssen wird dieser Datensatz nicht
berücksichtigt.
Ist das Feld „Zahlungsart“ auf „Angebot“ gesetzt, handelt es sich um ein Angebot.
Auch dieser Datensatz wird bei den Abschlüssen nicht berücksichtigt.
position.dat:
Jeder Datensatz stellt einen Eintrag = Kassenbonposition auf dem Kassenbon dar.
Das Feld „Preis“ multipliziert mit dem Feld „Anzahl“ x Prozent /100 ergibt den Preis
für diese Kassenbonposition. Das Feld „Art“ bestimmt den Inhalt der jeweiligen
Kassenbonposition.
Art:
0 = Artikelverkauf
1 = Dienstleistung
2 = Einzahlung Kundenkonto
4 = Gutschein-Kauf
16 = Paket-Verkauf (Dienstleistung/en + Artikel)
17 = Dienstleistungspaket-Verkauf
24 = Artikelpaket-Verkauf
32 = Bezahlung einer Rechnung
64 = Bezahlung einer Sammelrechnung
128 = Bonus
Pakete:
Pakete bestehen aus einem Datensatz mit der Paketbezeichnung und mehreren
Datensätzen mit den eigentlichen Dienstleistungen bzw. Artikeln. Zur Berechnung
der Abschlüsse werden ausschließlich die enthaltenen Dienstleistungen und Artikel
herangezogen.
Beträge aus den Datensätzen mit der Art 16,17,24 sind deshalb nur informativ und
werden nicht für Abschlüsse und das Kassenbuch verwendet.
2.) Nachträgliche Stornierung und Änderung von Kassenbons
Stornierung einer Kassenbon-Position nach dem Kassieren ( „echter Storno“):
In diesem Fall wird in der position.dat das Feld „Markiert“ auf „1“ (true) gesetzt und
es wird ein neuer Datensatz mit dem gleichen Inhalt und negativer Anzahl angelegt.
Auch bei diesem Datensatz wird das Feld „Markiert“ auf „1“ (true) gesetzt.
4
Änderungen einer Kassenbon-Position nach dem Kassieren:
In diesem Fall wird in der position.dat das Feld „Markiert“ auf „1“ (true) gesetzt und
eine Gegenbuchung erzeugt, indem ein neuer Datensatz mit dem gleichen Inhalt und
negativer Anzahl angelegt wird. Auch bei diesem Datensatz wird das Feld „Markiert“
auf „1“ (true) gesetzt.
Zusätzlich wird direkt hinter der Gegenbuchung ein neuer Datensatz mit den neuen
Werten in die Datenbank eingefügt.
Stornierung eines Kassenbons nach dem Kassieren („echter Storno“):
In der bon.dat wird das Feld „Markiert“ auf „1“ (true) gesetzt.
In der position.dat wird bei allen Positionen des Kassenbons das Feld „Markiert“ auf
„1“ (true) gesetzt. Es wird für jede Position ein neuer Datensatz mit dem gleichen
Inhalt und der negativen Anzahl angelegt. Auch bei diesem Datensatz wird das Feld
markiert auf „1“ (true) gesetzt.
Jede Änderung/Stornierung nach einem abgeschlossenen Kassiervorgang
wird in der kassenstorno.dat protokolliert.
Im Gegensatz dazu ist die Datenbank storno.dat seit Version 3.2-b (erschienen
im Mai 2005) nicht mehr maßgebend. Diese dient dem Geschäftsinhaber nur noch
als Tätigkeitsprotokoll für den geschäftsinternen Gebrauch und soll bei Bedarf über
die Aktivitäten der Mitarbeiter in COMCASH informieren. Nach Überprüfung vom
Geschäftsinhaber kann sie gelöscht oder mangels Bedarf auch grundsätzlich
deaktiviert werden. Seit Version 3.3 Build 2236 vom 01.07.2011 wurde die
storno.dat deshalb umbenannt in journal.dat.
3.) Belege
Belege sind Geld-Transaktionen, die das Kassenbuch verändern, aber nicht durch
einen Verkauf (bon.dat und position.dat) beschrieben werden können. Jeder Beleg
wird als ein Datensatz in der belege.dat gespeichert.
Es gibt zwei Möglichkeiten, wie Belege erzeugt werden:
Die eine ist das manuelle Erstellen eines Beleges. Der Benutzer des Programmes
kann mit der Eingabemaske „Betrag verbuchen“ mit der Eingabe des Betrages, der
Auswahl des Kontos (in der Eingabemaske „Beschreibung“ benannt), der Eingabe
eines Zusatztextes und des Datums einen Beleg in das System einfügen. Ein
typischer Beleg ist „Kasse an Bank“-100 Euro....22.05.2011.
Die zweite Möglichkeit, wie Belege erzeugt werden können, ist die automatische
Verbuchung. So wird bei sofortigen, aber unbaren Zahlarten (Scheck, Kreditkarte,
Terminalzahlung) automatisch ein Beleg zur Gegenbuchung angelegt. Wenn der
Beleg im Zusammenhang mit einem Kassenbon angelegt wird, wird im Feld
„Bonnummer“ der Datenbank belege.dat die „Interne Nummer“ des Datensatzes aus
der bon.dat gespeichert.
5
Der Belege-Datensatz hat, wie so ziemlich alle anderen Datensätze in COMCASH,
auch eine Filiale- Kennung, die bei Einzelsalons immer auf „1“ steht und eine interne
fortlaufende Nummer. Das Besondere an der fortlaufenden Nummer ist, dass diese
in Zweier-Schritten hochgezählt wird.
In einer Filiale und einem Salon ohne Filialverwaltung werden nur gerade Zahlen
verwendet; in der Verwaltung dagegen nur ungerade Zahlen. Auf diese Weise
können in der Verwaltung und in der Filiale zeitgleich Belege angelegt werden.
Mit der Version 3.3 wurde noch das Feld „Index“ eingeführt. Dies wird verwendet, um
Splittbuchungen zu erlauben. Der Index wird beim ersten Buchungssatz des Belegs
auf „1“ gesetzt. Bei jedem weiteren Buchungssatz desselben Beleges wird der Index
um 1 erhöht.
Nachträgliche Stornierung/ Änderung von Belegen:
Nachträgliches Löschen (Stornierung) eines Beleges:
Das Feld „Markiert“ wird auf „1“ (true) gesetzt. Es wird ein neuer Datensatz mit dem
gleichen Inhalt und demselben Betrag, allerdings negativ angelegt. Auch bei diesem
Datensatz wird das Feld „Markiert“ auf „1“ (true) gesetzt. Das Feld „Beleg“
bzw.“Belegindex“ wird auf „-1“ gesetzt.
Nachträgliche Änderung eines Beleges:
Das Feld „Markiert“ wird auf „1“ (true) gesetzt. Es wird ein neuer Datensatz mit dem
gleichen Inhalt und demselben Betrag, allerdings negativ angelegt. Auch bei diesem
Datensatz wird das Feld „Markiert“ auf „1“ (true) gesetzt. Das Feld „Beleg“
bzw.“Belegindex“ wird auf „-1“ gesetzt.
Anschließend wird ein neuer Datensatz mit den neuen Werten in die Datenbank
eingefügt.
Jede nachträgliche Änderung/Stornierung eines bestehenden Beleges wird mit
Datum, Uhrzeit und mit der automatisch von COMCASH abgefragten
Begründung in der Kassenstorno.dat gespeichert.
4.) kassenstorno.dat
Jede nachträgliche Stornierung und Änderung von Kassenbons und Belegen werden
zusätzlich zu den Gegenbuchungen in den jeweiligen Datenbanken stets in der
kassenstorno.dat protokolliert.
Die kassenstorno.dat hat eine interne fortlaufende Nummer.
Für jede Aktion wird ein Datensatz in die Datenbank eingefügt. In der Spalte „Stelle“
wird die Art der Aktion vermerkt. Eintrittsdatum und Austrittsdatum werden auf das
Datum der Aktion gesetzt. Die Eintrittszeit und die Austrittszeit werden auf den
Zeitpunkt der Aktion gesetzt. Eintritt und Austritt haben immer den gleichen Wert.
Im Unterschied zur storno.dat/journal.dat ist es nicht möglich, die kassenstorno.dat
in COMCASH auszuschalten oder zu löschen, da sie die gesetzlich erforderlichen
Aufzeichnungen zur Erfüllung der Grundsätze ordnungsgemäßer Buchführung
(GOB) über nachträgliche, so genannte, "echte Stornos" beinhaltet; und zwar
6
inklusive der erforderlichen Begründungen, die in solchen Fällen beim Entstehen
automatisch von COMCASH abgefragt werden.
Aktionen
14: Stornierung eines kompletten Kassenbons
18: Stornierung einer Kassenbonposition
30: Stornierung eines Beleges
32: Änderung des Preises einer einzelnen Kassenbonposition
42: Änderung des Betrags eines Beleges
14: Stornierung eines kompletten Kassenbons
Personalnummer: Wenn die Passwortabfrage für diese Funktion aktiviert ist, wird die
Personalnummer auf die Personalnummer des stornierenden Personals gesetzt.
Ansonsten wird die Personalnummer auf den Wert der gewählten Stammbedienung
des Kassenbons/Kunden gesetzt.
Zusatzdouble1: Gesamtbetrag des Kassenbons
Zusatzdouble2: “0”, ohne Bedeutung
Rest_Long: Bonnummer
Rest_Int: “0”, ohne Bedeutung
Name: Name des Personals
Notiz: beim Stornieren eingegebene Begründung
18: Stornierung einer Kassenbonposition
Personalnummer: Wenn die Passwortabfrage für diese Funktion aktiviert ist, wird die
Personalnummer auf die Personalnummer des stornierenden Personals gesetzt.
Ansonsten wird die Personalnummer auf den Wert der gewählten Stammbedienung
des Kassenbons/Kunden gesetzt.
Zusatzdouble1: Betrag der Kassenbonposition
Zusatzdouble2: “0”, ohne Bedeutung
Rest_Long: Bonnummer
Rest_Int: “0”, ohne Bedeutung
Name: Name des Personals
Notiz: beim Stornieren eingegebene Begründung
30: Stornierung eines Beleges
Personalnummer: Wenn die Passwortabfrage für diese Funktion aktiviert ist, wird die
Personalnummer auf die Personalnummer des ändernden Personals gesetzt.
Ansonsten wird der Wert auf „0“ gesetzt.
Zusatzdouble1: Betrag des gelöschten Beleges
Zusatzdouble2: “0”, ohne Bedeutung
7
Rest_Long: interne Belegnummer
Rest_Int: “0”, ohne Bedeutung
Name: Name des Personals
Notiz: beim Stornieren eingegebene Begründung
32: Änderung des Preises einer Kassenbonposition
Personalnummer: Stammbedienung des Kassenbons/Kunden.
Zusatzdouble1: Alter Betrag der Kassenbonposition
Zusatzdouble2: Neuer Betrag der Kassenbonposition
Rest_Long: Kassenbonnummer
Rest_Int: “0”, ohne Bedeutung
Name: Name des Personals
Notiz: beim Ändern eingegebene Begründung
42: Änderung des Betrages eines Beleges
Personalnummer: Wenn die Passwortabfrage für diese Funktion aktiviert ist, wird die
Personalnummer auf die Personalnummer des ändernden Personals gesetzt.
Ansonsten wird der Wert auf „0“ gesetzt.
Zusatzdouble1: alter Betrag, der geändert wurde
Zusatzdouble2: “0”, ohne Bedeutung
Rest_Long: interne Belegnummer des alten Beleges
Rest_Int: “0”, ohne Bedeutung
Name: Name des Personals
Notiz: beim Ändern eingegebene Begründung
5.) Sonstiges
COMCASH hat keinen „Trainingsspeicher“ o.ä., sodass Kassiervorgänge zu
evtl. Übungs- und Testzwecken mit der entsprechenden Begründung
„Training“, „Schulung“ oder „Test“ einzeln storniert werden müssen.
Ggf. könnte alternativ dazu auch vor dem Training eine Datensicherung gemacht
werden, die nach Abschluss der Übung wieder zurückgespielt wird.
Die Erstellung von „Proforma-Rechnungen“ ist mit COMCASH nicht
vorgesehen, eine solche Funktion gibt es nicht.
Abgesehen vom Passwortschutz existiert keine Funktion zum Unterdrücken
von Daten- und Speicherinhalten.
Stand 01.09.2011
COMHAIR GmbH, Heinenkamp 4, 38444 Wolfsburg, Tel. 05308/406-0, Fax 05308/406-300
[email protected], www.comhair.de
8
Herunterladen