Auftragssumme zu niederig bei Bestellung mit Guthaben

[ongnamo]

Hallo,

es gibt zwar bereits einige Threads zum Thema Guthaben und Ausweis auf der Rechnung, aber ich den folgenden Aspekt nicht gefunden. Ein Beispiel:

Shopbestellung mit Warenwert 100 EUR, Vorkasse
Kunde löst 80 EUR Gutschein ein

In der autom. Bestellbestätigung steht dann:
Positionsliste mit den Einzelwerten
-Guthaben 80 EUR
Gesamtsumme: 20 EUR

Das ist auch schon nicht korrekt: Die Gesamtsumme sind 100 EUR und der zu zahlende Betrag 20 EUR.

Doch schlimmer ist die falsche Behandlung in der WAWI. Dort wird der Auftrag nach Import so ausgewiesen:

Betrag: 20 EUR
bezahlt: N/20 EUR
offen: 20 EUR

Das ist schlichtweg falsch. Es müsste dort stehen:

Betrag: 100 EUR
bezahlt: N/80 EUR
offen: 20 EUR

Und außerdem müsste das eingelöste Guthaben als Zahlung unter "Zahlung" ausgewiesen werden.

Laut JTL wird das Guthaben ja wie eine Zahlung behandelt und auf der Rechnung von der Rechnungssumme abgezogen. Das ist soweit nicht zu beanstanden, aber warum tut man dann beim Auftrag implizit so, als ob die Zahlung eine Bestell-Position sein? Und dann wird sie noch nicht einmal in der Positionsliste gezeigt. Wenn man nur den WaWi-Auftrag anschaut, ohne dass man die Shop-Bestellung kennt, dann wundert man sich, dass der Gesamtwert des Auftrag 20 EUR ist, obwohl die Summe der Auftragsposition 100 EUR. Kapier ich nicht. Gibt es dafür schon Lösungen?

Gruß
Thomas

 

[MichaelH]

AW: Auftragssumme zu niederig bei Bestellung mit Guthaben

Ja und nein, das Guthaben im Sinne einer Zahlung muss ja schon irgendwo existieren bzw. gebucht sein, wenn nun das Guthaben erneut als Zahlung in die WAWI fließen würde, dann würdest du z.B. 2 x die Zahlung "versteuern".
Andererseits, fehlt hier nun die Aufschlüsselung der Zahlung in ggf. unterschiedliche UST-%-Sätze, denn ein Guthaben ist zuerst mal ohne UST, also nur eine Zahlung.

Je nach dem ob man IST oder SOLL versteuert, muss man das Ganze unterschiedlich behandeln und auch je nach dem woher das Guthaben kommt.

Wenn ein Kunde z.B. einen Gutschein kauft und bezahlt, dann ist dieser ohne UST.
Der Gutschein wird dann als Guthaben in ein anderes Kundenkonto übertragen.
So - und nun ?

Alles recht komplex und daher vermeide ich selber das soweit wie irgendmöglich ...

-> Ich denke derzeit musst du das Ganze separat zusätzlich verwalten und entsprechend korrigieren.

 

[ongnamo]

AW: Auftragssumme zu niederig bei Bestellung mit Guthaben

Ja und nein, das Guthaben im Sinne einer Zahlung muss ja schon irgendwo existieren bzw. gebucht sein, wenn nun das Guthaben erneut als Zahlung in die WAWI fließen würde, dann würdest du z.B. 2 x die Zahlung "versteuern".

Nicht wirklich: Das Guthaben ist - in diesem Fall - aus einer Rücksendung entstanden. Also habe ich eine Rechnungskorrektur gebucht und damit steuerlich alles glatt gestellt. Das Geld aus der Rechnungskorrektur hat der Kunden quasi bei mir geparkt. Die erneute Bestellung, die nun tlw. mit dem Guthaben bezahlt wurde, ist daher voll zu versteuern. (Zahlungen werden übrigens nicht versteuert, nur Rechnungsbeträge ^^)

In diesem Sinne es die Einlösung des Guthabens eine Zahlung (aus Guthaben) und keine Bestellposition. Doch genau das tun der Shop und die WaWi, allerdings inkonsequent: Einerseits weisen sie die Zahlung nicht unter der Bestellpositionen aus (korrekt), andererseits tun sie bei der Ermittlung des Gesamt-Bestell-Betrages so, also ob die Zahlung eben doch eine Bestellposition wäre (nicht korrekt). Das ist strange.

Schön und konsequent wäre es dann, wenn die Guthabenzahlung unter "Zahlung" ausgewiesen würde, so dass das dann in meinem o.g. Beispiel stünde:

80 EUR Guthabenzahlung
20 EUR Vorkasse

DAS wäre transparent.

Ob IST- oder SOLL-Versteuerung ist für diesen Aspekt m.E. nebensächlich.

"-> Ich denke derzeit musst du das Ganze separat zusätzlich verwalten und entsprechend korrigieren."
Vermutlich. Schade, dass eine solche Basis-Funktion nicht richtig behandelt wird. Ich werde wohl den Auftrag stornieren und erneut in der Wawi erfassen müssen.

 

[MichaelH]

AW: Auftragssumme zu niederig bei Bestellung mit Guthaben

"Zahlungen werden übrigens nicht versteuert, nur Rechnungsbeträge"
- JEIN, ist eben IST (Zahlungen) oder SOLL (Rechnungen), habe ich ja erwähnt, kommt als auf die Firma/FIBU an wie diese geführt wird.


"Ob IST- oder SOLL-Versteuerung ist für diesen Aspekt m.E. nebensächlich. "
- Nein, absolut nicht, das ist extrem wichtig, weil bei IST die Zahlungen die erfasst sind eine wichtige Rolle spielen und nicht die Belege (Rechnung/Gutschrift).
- Und auch bei SOLL wenn du die Zahlungen über die WAWI verwaltest ist das nicht unwichtig.


Ich "umschiffe" dein Problem, in dem das Guthaben bei der Rechnung/Gutschrift stehen bleibt und dann mit der neuen Bestellung entsprechend in der WAWI manuell umgebucht wird.
Somit stimmen dann IST als auch SOLL-Variante.
Der Kunde hat als Dokument ja seine Gutschrift.
Bei der Gutschrift wird angeführt: Gutschrift bei der Zahlung in Abzug bringen.


"Also habe ich eine Rechnungskorrektur gebucht und damit steuerlich alles glatt gestellt."
Aber in der WAWI auch ?
Hier müsstest du dann korrekterweise das Guthaben als Minus-Zahlung erfassen und stattdessen den Betrag als Guthaben in den Shop laden.
Dann würde die WAWI zwar stimmen, aber der Export bei IST-Variante nicht (mehr).

-> Es gibt verschiedene Möglichkeiten wie man das organisatorisch und in der WAWI handhaben kann ...
-> Hin wie her, die WAWI bietet diese Variante die du gerne hättest definitiv nicht.

 

[ongnamo]

AW: Auftragssumme zu niederig bei Bestellung mit Guthaben

Also ob Ist- oder Sollversteuerung ist für diesen Post schon irrelevant, weil es primär um die falsche Darstellung der Auftragssumme geht. Da spielt die nachgelagerte Versteuerung zunächst mal keine Rolle.

Auch wenn der Post jetzt etwas abdriftet in Richtung des generellen Problems "Guthabenbehandlung in JTL", habe ich Fragen zu deinem Ansatz:
"in dem das Guthaben bei der Rechnung/Gutschrift stehen bleibt"

Ich hatte bislang bei dem Auftrag / Rechnung im Falle einer Rechnungskorrektur den Gutschriftsbetrag negativ erfasst. Ist Dein Vorschlag, dass genau diese "Zahlung", die eher eine Verrechnung ist, nicht zu erfassen ist und damit der Auftrag als überzahlt in der Liste steht?


"Aber in der WAWI auch ?
Hier müsstest du dann korrekterweise das Guthaben als Minus-Zahlung erfassen und stattdessen den Betrag als Guthaben in den Shop laden.
Dann würde die WAWI zwar stimmen, aber der Export bei IST-Variante nicht (mehr)."

Genau das habe ich gemacht:
a) Gutschriftsbetrag als Minus-Zahlung erfasst mit Kein Export angehakt
b) Als Guthaben im Shop bereitgestellt
c) Export stimmt, da sowohl Zahlbetrag der Rechnung als auch Betrag der Gutschrift (über separaten Gutschriftsexport) exportiert werden (bin IST Versteuerer).

Damit ist in der WAWI alles glatt, beim STB/FA auch und der Kunde hat sein Guthaben im Shop. So weit, so gut, doch nun haben wir das Problem mit der Auftragssumme, weshalb ich den Post geöffnet habe.

Insgesamt ist das alles ein Gemurkse und ich hoffe, dass sich JTL diese Themas doch irgendwann mal annimmt. Es wäre alles einfacher, wenn man dem Kundenkonto ein Guthaben zuordnen könnte, dass bei eingehenden Bestellung in Abzug gebracht wird, sofern das noch nicht im Shop passiert ist.

 

[MichaelH]

AW: Auftragssumme zu niederig bei Bestellung mit Guthaben

Du machst das wie "SOLL, aber da du "IST" versteuerst ist dein Ablauf falsch, weil die 80 Euro über die Gutschrift "verschwunden" sind, tatsächlich aber immer noch auf deinem Konto existieren.
Du müsstest also Differenzen haben bei der Abstimmung deiner Bankkonten mit der FIBU ...

Mein Ablauf korrigiert die Zahlung und die UST, dann wenn die Lieferung auch tatsächlich erbracht wurde und wird. Für mich nicht unwesentlich da ich verschiedene UST-Sätze habe und ich nicht weiß was der Kunde kaufen "wird" mit seinem Guthaben.

 

[ongnamo]

AW: Auftragssumme zu niederig bei Bestellung mit Guthaben

Verstanden.

Aber eine Lösung zu dem Thread-Thema hast Du nicht zufällig auch? Achja, Du vermeidest es, überhaupt dem Kunden eim Shop ein Guthaben zu geben ^^ Ist vermutlich beim aktuellen Stand der Software das Beste.