So erfassen Sie einen Verkauf

Was Sie anlegen, wenn Sie einen Verkauf erfassen

Ein Verkauf in Skyline Nexus ist eine Zeile in der Transaktionstabelle mit dem Typ sell, dazu eine Reihe von Verkaufspositionen und null oder mehr Zahlungsdatensätze. Diese drei Dinge sind bewusst getrennt. Die Rechnung ist der Anspruch gegenüber dem Kunden. Die Positionen sind das, was das Regal verlassen hat. Die Zahlungen sind das Geld, das eingegangen ist. Die meisten Missverständnisse rund um Verkäufe in einem ERP entstehen, weil man diese drei als ein einziges Ereignis behandelt – an der Ladenkasse geschehen sie ja meist in derselben Sekunde.

Buchhalterisch sind es keine identischen Ereignisse. Die Rechnung erzeugt Umsatz und eine Forderung. Die Positionen mindern den Bestand und erzeugen Wareneinsatz. Die Zahlung gleicht die Forderung aus und bewegt Geld. Wer auf Ziel verkauft, erhält die Zahlung Wochen später, und dazwischen steht die Forderung in der Bilanz. Wer eine Anzahlung nimmt, erhält das Geld, bevor die Rechnung existiert. Das System bildet all das ab, weil all das in echten Unternehmen vorkommt.

Die praktische Frage beim Erfassen eines Verkaufs ist also nicht nur, welche Schaltflächen Sie drücken. Sie lautet: Welche dieser drei Dinge lege ich gerade an, und welche lege ich bewusst noch nicht an? Die Antwort bestimmt fast ausschließlich ein einziges Feld im Formular, das Statusfeld, das weiter unten behandelt wird.

Drei Türen zum selben Beleg

Das linke Menü hat ein Dropdown mit der Bezeichnung „Verkauf“. Darunter finden Sie mehrere Einträge, die alle dieselbe Art von Beleg schreiben und sich nur darin unterscheiden, wie viel des Formulars sie zeigen und wie schnell sie auszufüllen sind.

Die fertigen Belege stehen unter „Alle Verkäufe“ (/sells), unabhängig davon, durch welche Tür Sie gekommen sind. Entwürfe und Angebote haben eigene Listen, „Entwürfe auflisten“ (/sells/drafts) und „Angebote auflisten“ (/sells/quotations), weil sie noch keine echten Rechnungen sind und die Verkaufsliste nicht überladen sollen. Kassenbons erscheinen zusätzlich gesondert unter „POS-Liste“ (/pos).

Ein Implementierungsdetail ist wissenswert, weil es manches Verhalten erklärt: Das Formular „Verkauf hinzufügen“ sendet an denselben Controller wie der POS-Bildschirm. Es sind zwei Oberflächen über einer einzigen Speicherroutine. Deshalb sind Steuerregeln, Bestandsregeln und Hauptbuchbuchung identisch, egal von welchem Bildschirm aus Sie begonnen haben – und deshalb sollten Sie nicht erwarten, dass ein POS-Bon und eine Rechnung aus „Verkauf hinzufügen“ buchhalterisch unterschiedlich behandelt werden.

• „POS“ (/pos/create) ist der touch-optimierte Kassenbildschirm. Ein Kunde, ein Produktraster, ein Zahlungsbereich, in wenigen Sekunden erledigt. Die richtige Tür für Einzelhandel, Gastronomie und jeden Verkauf über den Tresen.
• „Verkauf hinzufügen“ (/sells/create) ist das vollständige Rechnungsformular. Jedes Feld ist sichtbar: Rechnungsschema, Währung, Zahlungsbedingung, Versand, benutzerdefinierte Felder, mehrere Zahlungszeilen. Die richtige Tür für eine B2B-Rechnung, einen Verkauf mit Lieferung oder alles mit Zahlungsziel.
• „Direktverkauf“ (/sells/direct/create) ist eine verkürzte Fassung von „Verkauf hinzufügen“ für einfache Rechnungen.
• „Entwurf hinzufügen“ (/sells/create?status=draft) und „Angebot hinzufügen“ (/sells/create?status=quotation) sind wieder dasselbe Formular, geöffnet mit vorbelegtem Status, damit Sie nicht versehentlich abschließen.
• „Kundenauftrag hinzufügen“ (/sells/create?sale_type=sales_order) erfasst eine Kundenbestellung, die später fakturiert wird. Der Eintrag erscheint nur, wenn Kundenaufträge in den POS-Einstellungen aktiviert sind.

Den Bildschirm „Verkauf hinzufügen“ ausfüllen

Die erste Karte ist „Verkaufsdetails“. „Standort auswählen“ ist ein Pflichtfeld und keine Kosmetik: Es entscheidet, aus welchem Bestand der Verkauf abgebucht wird, welcher Rechnungsnummernkreis verwendet wird, welche Zahlungskonten angeboten werden und – wenn Sie E-Rechnungen übermitteln – ob der Verkauf überhaupt übermittelt wird, denn E-Invoicing wird je Standort aktiviert. „Rechnungsschema“ steuert die Nummer, die die Rechnung erhält. „Verkaufsdatum“ ist das Buchungsdatum des Belegs und steht standardmäßig auf jetzt. „Rechnungswährung“ und „Wechselkurs zu SAR“ erscheinen nur, wenn Fremdwährungsverkäufe konfiguriert sind.

„Rechnungsnummer“ ist bewusst schwer erreichbar. Das Feld wird nur für Benutzer angezeigt, die die Berechtigung zum Bearbeiten von Rechnungsnummern besitzen, und nur solange der Beleg ein Entwurf ist, mit dem Hilfetext „Zum automatischen Generieren leer lassen“. Das ist das richtige Design. Eine Rechnungsnummer, die ein Kassierer überschreiben kann, ist kein Nummernkreis, und ein lückenhafter Nummernkreis ist das Erste, was einem Betriebsprüfer auffällt.

Die Karte „Kunde“ nimmt den Kontakt und die „Zahlungsbedingung“ auf, eingegeben als Zahl plus Einheit „Monate“ oder „Tage“. Ein eigenes Fälligkeitsfeld gibt es auf diesem Bildschirm nicht: Das Fälligkeitsdatum wird aus der Zahlungsbedingung abgeleitet, und wenn Sie das Feld leer lassen, gilt die Standard-Zahlungsbedingung des Kunden. Deshalb lohnen sich die fünf Minuten, Zahlungsbedingungen im Kundenstamm statt auf jeder Rechnung zu hinterlegen.

Der Status entscheidet fast alles

Das Feld „Status“ in „Verkauf hinzufügen“ bietet „Finale“, „Entwurf“, „Angebot“ und „Proforma“. Es ist das folgenreichste Feld des Formulars, denn nahezu jedes nachgelagerte Verhalten hängt davon ab.

Es gibt eine bewusste Ausnahme von der Entwurfsregel, und Sie sollten sie kennen, bevor sie Sie überrascht. Eine Unternehmenseinstellung in den POS-Einstellungen mit der Bezeichnung „Bestand für Rechnungsentwürfe abziehen“ bewirkt, dass reine Entwürfe den Bestand bereits beim Speichern mindern und in den Umsatz-, Gewinn-, Wareneinsatz- und Cashflow-Berichten genau wie ein abgeschlossener Barverkauf zählen. Sie ist standardmäßig ausgeschaltet, und der Hilfetext im Produkt sagt das deutlich. Schalten Sie sie nur ein, wenn Sie Entwürfe tatsächlich als Kommissionierbelege nutzen, und seien Sie sich bewusst, dass Entwürfe damit finanziell real werden.

Die praktische Regel: Wenn die Ware weg ist und der Kunde Ihnen etwas schuldet, lautet der Status „Finale“. Alles andere erfasst eine Absicht, keinen Geschäftsvorfall. Nutzen Sie „Entwurf“ nicht, um einem befürchteten Fehler auszuweichen – ein Entwurf, der nie abgeschlossen wird, ist ein Verkauf, der nirgends auftaucht.

• „Finale“ ist eine echte Rechnung. Sie mindert den Bestand, nimmt Zahlungen an, kann ins Hauptbuch gebucht werden und wird, wo E-Invoicing aktiv ist, an die Steuerbehörde übermittelt.
• „Entwurf“ ist ein Zwischenstand. Er wird nicht ins Hauptbuch gebucht und nimmt keine Zahlung an: Die Speicherroutine weigert sich, Zahlungsdatensätze für einen Verkauf mit dem Status Entwurf, Angebot oder Proforma zu schreiben. Standardmäßig berührt er auch den Bestand nicht.
• „Angebot“ ist eine Offerte. Nichts bewegt sich. Kein Bestand, kein Hauptbuch, keine Zahlung.
• „Proforma“ ist ein Vorab-Rechnungsbeleg. Wie ein Angebot bewegt er nichts.

Wie die Steuer auf einen Verkauf berechnet wird

Steuer kann auf zwei Ebenen in einen Verkauf eingehen, und der Unterschied ist wichtig. Die Positionssteuer ist ein Steuersatz, der an einer einzelnen Produktzeile hängt. Die Auftragssteuer ist ein einziger Satz für den gesamten Beleg, gewählt im Feld „Auftragssteuer“ unterhalb des Produktrasters. Die meisten Unternehmen nutzen das eine oder das andere. Beides auf demselben Beleg zu verwenden, bringt Anwender anderswo in Schwierigkeiten, und Skyline Nexus ist darauf ausgelegt, genau diesen Fehler zu verhindern.

Die Auftragssteuer wird auf eine Bemessungsgrundlage erhoben, die Positionen mit eigener Positionssteuer ausschließt. Eine Position, deren Satz dem Belegsatz entspricht, trägt nichts zur Bemessungsgrundlage der Belegsteuer bei. Einfach gesagt: Das System berechnet keine Umsatzsteuer auf Umsatzsteuer, und es besteuert eine Position, die bereits zum Belegsatz besteuert ist, nicht doppelt. Das ist eine Rechenregel in der Routine für die Rechnungssumme, keine Einstellung, an deren Häkchen Sie denken müssten.

Ob ein Preis brutto oder netto angegeben ist, ist eine Eigenschaft des Produkts, nicht der Rechnung. Im Produktformular gibt es das Feld „Verkaufspreissteuerart“ mit den Optionen „Inklusive“ und „Exklusiv“. Die Position speichert anschließend beide Werte, den Stückpreis vor Steuer und den Stückpreis inklusive Steuer, sodass die Rechnung beide anzeigen kann, ohne neu zu rechnen. Die Steuerauswahl je Zeile im Verkaufsformular erscheint nur, wenn die Inline-Steuer für das Unternehmen eingeschaltet ist; ist sie aus, kommt die Steuer aus dem Produkt und aus dem Feld „Auftragssteuer“.

Die Rundung ist eine Unternehmenseinstellung und keine Entscheidung je Rechnung. Standardmäßig wird mit voller Genauigkeit summiert und die Rechnung einmal am Ende gerundet, statt jede Position zu runden und die gerundeten Werte zu addieren. Die beiden Methoden unterscheiden sich auf einer langen Rechnung um ein paar Einheiten der kleinsten Währungseinheit – für den Kunden unerheblich, für eine Umsatzsteuer-Voranmeldung, die mit dem Hauptbuch übereinstimmen muss, sehr erheblich.

Die Zahlung ist ein eigener Datensatz, getrennt von der Rechnung

Die Karte „Zahlung hinzufügen“ unten im Formular ist optional. Jede Zahlungszeile fragt nach „Betrag“, „Bezahlt am“, „Bezahlverfahren“ und „Zahlungskonto“, dazu optional „Zahlungshinweis“. Mit „Zahlungszeile hinzufügen“ teilen Sie eine Rechnung auf mehrere Zahlungsarten auf – genau das Richtige, wenn ein Kunde teils bar und teils mit Karte zahlt. Unter den Zeilen stehen „Total bezahlbar“, „Gesamtbezahlung“, „Rückgeld“ und „Saldo“.

Handelt es sich um einen Zielverkauf, setzen Sie das Häkchen bei „Verkauf auf Ziel — voller Betrag fällig“. Das setzt den Zahlungsbetrag auf null, blendet die Zahlungszeilen aus und weist die Speicherroutine an, überhaupt keine Zahlungsdatensätze anzulegen. Die Rechnung wird ausgestellt, die Forderung bleibt bestehen, und das Geld wird später eingezogen. So wird ein Zielverkauf korrekt erfasst; eine Zahlungszeile mit dem Wert null ist es nicht.

Der Zahlungsstatus des Belegs wird abgeleitet, nicht eingetippt. Er lautet bezahlt, wenn die eingegangene Summe mindestens der Rechnungssumme entspricht, teilweise, wenn etwas, aber nicht alles eingegangen ist, und fällig, wenn nichts eingegangen ist. Diese Ableitung läuft bei jedem Hinzufügen, Bearbeiten oder Löschen einer Zahlung erneut. Deshalb sollten Sie spätere Zahlungen über „Zahlung hinzufügen“ in der Verkaufsliste (/payments/add_payment/{id}) erfassen und nicht durch Bearbeiten der Rechnung. Die Rechnung zu bearbeiten, damit die Zahlen passen, ist der falsche Reflex; mehr dazu im Leitfaden zum Stornieren und Korrigieren von Transaktionen.

Was der Verkauf mit dem Bestand macht

Wird ein Verkauf als „Finale“ gespeichert, mindert jede Position die verfügbare Menge der betreffenden Produktvariante an diesem Geschäftsstandort. Produkte ohne Bestandsführung werden übersprungen: Die Abbuchungsroutine tut nichts bei einem Produkt, dessen Lagerverwaltung ausgeschaltet ist. So verkaufen Sie Dienstleistungen und Arbeitszeit über denselben Bildschirm, ohne negative Bestände zu erzeugen.

Anschließend läuft ein zweiter Schritt, den man selten sieht, aber kennen sollte. Jede verkaufte Menge wird den konkreten Einkaufspositionen zugeordnet, aus denen sie stammt, und diese Zuordnung wird gespeichert. Diese Verknüpfung macht den Wareneinsatz real statt geschätzt: Das System weiß, welcher Einkauf zu welchen Kosten welchen Verkauf beliefert hat. Sie setzt außerdem Chargen- und Verfallsregeln durch und ermöglicht es der Software, einen Überverkauf abzulehnen, wo Überverkäufe nicht erlaubt sind.

Da diese Zuordnung im Moment des Verkaufs entsteht, wird ein Verkauf, der Wochen später gegen inzwischen bewegten Bestand erfasst wird, anders zugeordnet, als es damals der Fall gewesen wäre. Das ist kein Fehler, sondern Arithmetik – und das stärkste praktische Argument dafür, Verkäufe am Tag ihres Geschehens zu erfassen.

Was ins Hauptbuch gebucht wird

Ein abgeschlossener Verkauf löst ein internes Ereignis aus, auf das das Buchhaltungsmodul reagiert. Ist alles konfiguriert, schreibt dieser Listener einen Buchungssatz. Er belastet das Sammelkonto Forderungen aus Lieferungen und Leistungen mit der vollen Rechnungssumme, schreibt den Nettobetrag den Umsatzerlösen gut und die Steuer der Umsatzsteuer. Die Erlöse werden nach Produktkategorie aufgeteilt, wo Kategorien eigene Erlöskonten haben – ein Unternehmen, das Waren und Dienstleistungen verkauft, sieht beide so ohne manuelle Auswertung getrennt in der Gewinn- und Verlustrechnung.

Drei Bedingungen müssen alle erfüllt sein, sonst wird nichts gebucht, und es lohnt sich, alle drei zu prüfen, bevor man das Hauptbuch für defekt hält. Erstens muss der Verkauf den Status „Finale“ haben. Entwürfe, Angebote und Proforma-Belege werden absichtlich übersprungen. Zweitens muss das Unternehmen „Verkäufe automatisch buchen“ in den Buchhaltungseinstellungen unter /accounting/settings eingeschaltet haben. Drittens müssen die Konten zugeordnet sein: ein Forderungskonto, ein Erlöskonto und ein Umsatzsteuerkonto, konfiguriert unter /accounting/settings/mapping. Eine fehlende Zuordnung beschädigt nichts, sie verweigert lediglich die Buchung.

Eine vierte Hürde erwischt viele am Monatsende: Die Geschäftsperiode, in die das Verkaufsdatum fällt, muss offen sein. Ist die Periode abgeschlossen oder gesperrt, wird die Buchung abgelehnt, statt stillschweigend in einen geschlossenen Monat zurückdatiert zu werden. Das ist das richtige Verhalten und der ganze Sinn eines Periodenabschlusses, bedeutet aber, dass ein Verkauf mit Datum in einem gesperrten Monat erst ins Hauptbuch gelangt, wenn die Periode wieder geöffnet oder das Datum korrigiert wird.

E-Invoicing, wo es gilt

In Saudi-Arabien erzeugt und übermittelt das E-Invoicing-Modul die Rechnung automatisch, sobald ein Verkauf als „Finale“ gespeichert wird. Es wird je Geschäftsstandort aktiviert und nicht für das ganze Unternehmen, sodass ein Unternehmen einen Standort bereits im E-Invoicing-Verfahren betreiben kann, während ein anderer noch nicht angemeldet ist. Die Konfiguration befindet sich unter /zatca/configuration.

Die Übermittlung ist idempotent: Das System speichert, was bereits übermittelt wurde, und übermittelt dieselbe Rechnung nicht zweimal. Schlägt eine Übermittlung fehl, bleibt der Verkauf trotzdem gespeichert. Das ist eine bewusste Entscheidung, denn einen Verkauf zu verlieren, weil der Endpunkt einer Steuerbehörde nicht erreichbar war, wäre weit schlimmer, als ihn ein paar Minuten später zu übermitteln. Eine fehlgeschlagene Übermittlung kann aus dem Verkauf selbst erneut gesendet werden.

Ist eine Rechnung übermittelt, ist sie für die Bearbeitung gesperrt. Die Meldung des Systems ist eindeutig: Die Rechnung wurde bereits übermittelt und kann nicht mehr bearbeitet werden; zur Korrektur müssen Sie eine Gutschrift oder eine Belastungsanzeige ausstellen. Das ist keine Schikane der Software. Eine übermittelte Rechnung ist ein Dokument, das nun bei der Steuerbehörde liegt, und der einzige rechtmäßige Weg, es zu ändern, ist ein weiteres Dokument.

Nach dem Speichern

Der Verkauf erscheint unter „Alle Verkäufe“ mit Rechnungsnummer, Kunde, Summe, Zahlungsstatus und gegebenenfalls seinem E-Invoicing-Status. Über das Zeilenmenü können Sie ihn ansehen, drucken, eine Zahlung hinzufügen, seine Zahlungen anzeigen oder eine Rückgabe dazu beginnen. Die Detailansicht unter /sells/show/{id} zeigt Positionen, Steueraufschlüsselung und Zahlungshistorie an einem Ort – der Bildschirm, den Sie öffnen, wenn jemand fragt, was mit einer bestimmten Rechnung passiert ist.

Der Saldo des Kunden wird nach dem Verkauf neu berechnet, sodass die Forderung sofort im Kundenkonto und in der Altersstruktur der Forderungen sichtbar ist. Ist die Hauptbuchbuchung aktiviert und konfiguriert, erscheinen dieselben Zahlen über das Buchhaltungsmodul auch in der Summen- und Saldenliste und in der Bilanz. Stimmen beide nicht überein, liegt die Ursache meist an einer der drei oben genannten Buchungshürden und nicht an einem Rechenfehler.

Eine kurze Checkliste

• Stimmt der Standort? Er entscheidet über Bestand, Nummernkreis, Zahlungskonten und E-Invoicing.
• Ist der Status „Finale“? Alles andere ist noch kein Verkauf.
• Ist das Verkaufsdatum der Tag, an dem der Verkauf tatsächlich stattfand, und nicht der Tag, an dem Sie ihn eintippen?
• Hat der Kunde nicht bezahlt: Ist „Verkauf auf Ziel — voller Betrag fällig“ angehakt statt einer Zahlungszeile mit null?
• Bei einem Zielverkauf: Ist die Zahlungsbedingung gesetzt, damit die Rechnung korrekt altert?
• Sehen die Steuerbeträge in der Summenleiste vor dem Speichern richtig aus – nicht erst danach?