Auftrag stornieren ... korrekte buchhalterische Abwicklung (auch in Bezug auf JTL2DATEV)

[wawi-dl]

Hallo,

muss doch nochmals in die Runde fragen, da es hier wieder verschiedene Meinungen gibt.

Ein Kunde gibt einen Auftrag auf und bezahlt.
Bevor der Versand erfolgt ist, soll der Auftrag nun doch storniert werden.

Wie sollte man nun den Fall korrekt abwickeln, damit auch Buchhaltung etc. alles sauber hat?

1.) Auftrag stornieren und Betrag erstatten
-> Problem hierbei, es gibt Geldbewegungen ohne Zuordnung zu einer Rechnung!

2.) Auftrag ohne Versand abschließen, Rechnung + Stornorechnung erstellen und Betrag erstatten
-> Aufwendig, auch beim Verbuchen / Versand muss man aufpassen, Fehlerquelle groß!


Wir hatten schon immer Variante 1 bevorzugt, kennen dies auch so von Lieferanten.
Da wir aber eine Schnittstelle zu DATEV einrichten wollen, JTL2DATV dazu verwenden wollen, gibt es hier wohl Probleme, da die Zahlungen nicht zugeordnet werden können.

Danke

 

[Jens31]

Hallo,

2.) Auftrag ohne Versand abschließen, Rechnung + Stornorechnung erstellen und Betrag erstatten
-> Aufwendig, auch beim Verbuchen / Versand muss man aufpassen, Fehlerquelle groß!

Ich bin für Variante 2, da transparenter und in JTL immer nachvollziehbar aber unsere Steuerberater hat uns zu Variante 2 gedrängt

Warum JTL2DATEV und nicht Nexus von Dekodi?

LG

 

[wawi-dl]

Du meinst du wolltest Variante 1, musst aber Variante 2?
Naja, Variante 2 finde ich persönlich "blöd", weil der Kunde dann eine Rechnung und Stornorechnung erhält, für "nichts".

Wieso Nexus und nicht JTL2Datev?

 

[Simone_die_Echte]

Ich würde es mal von der Betriebsstruktur abhängig machen, welche Variante genutzt wird.

Betrieb mit unterschiedlichen Mitarbeitern in Büro und Buchhaltung -> Variante 2

Betrieb mit einem Mitarbeiter für beide Tätigkeitsfelder-> Variante 1
Dann wird die Zahlung / Erstattung direkt mit einem entsprechenden Vermerk auf 1590 gebucht
und es entsteht weniger Arbeitsaufwand

 

[wawi-dl]

@Simone
So ähnlich sehe ich es auch, danke.

Heißt, du setzt Zahlung "Gutschrift", die dann auf 1590 Durchlaufende Posten gebucht wird?
Wo hinterlegst du dann das Konto 1590? Direkt in der Zahlungsart unter SKR-Konto?

Nutzt du JTL2DATEV zufällig? Klappt damit das Handling?

 

[Simone_die_Echte]

Ich bin nun davon ausgegangen, dass die Rechnung noch nicht erstellt wurde (der Ware noch nicht versendet) und der Auftrag einfach storniert werden soll.
Dann erstelle ich weder Rechnung noch Gutschrift sondern buche den Zahlungsein- und ausgang direkt in der Fibu auf 1590. Die Wawi und der Nexus werden
in diesem Fall gar nicht tangiert.
Anders sieht es natürlich aus, wenn die Rechnung schon erstellt wurde.

 

[deliman]

Wir nehmen dann Variante 1 und legen einfach den Auftrag mit Vermerk "Storno" mit in den Ordner für den Steuerberater. In JTL2DATEV UO vermerken wir die Auftragsnummer und den Rest macht die Buchhalterin im Steuerbüro. Dafür will sie ja dann wenigstens eine Info in Form der AB mit dem Stornovermerk, damit sie weis, dass das ein Durchläufer ist.

Wenn der Versand schon erfolgt ist, wird auch eine Rechnung und dann eine Rechnungskorrektur erstellt. Anders ist das in diesem Fall nicht händelbar.

 

[wawi-dl]

Ja neeeeee

Wir sind IST-Versteurer, somit ist jeder Zahlungsein- / ausgang zu belegen.
Daher stornierten wir seither den Auftrag, setzen aber eine 2. negative Zahlung als Gutschrift.
Beide sind in Summe 0, was sich dann auch nirgends auswirkt.

ABER, wie bereits erwähnt kann JTL2DATEV wohl diese Zahlungen nicht verbuchen, da es keine Zuordnung gibt.
Wir wollen nicht Variante 2 gehen, nur damit JTL2DATEV alles verarbeiten kann
Ich kann mir nur vorstellen, dass ich die Zahlungsarten "Gutschrift" auf Konto 1590 laufen lassen, dann fehlt mir aber noch die Zuordnung für Zahlungseingang?!

 

[Jan-S]

Man kann doch auch mit JTL2Datev Zahlungen exportieren und verbuchen oder übersehe ich etwas?

 

[Jens31]

Hallo,

Ich meinte, wir nutzen Variante 1 obwohl ich für Variante 2 bin.

Simone_die_Echte hat vollkommen recht, bei mehr als 3 Mitarbeiter im Service und 2 Mitarbeiter in der Buchhaltung, endet es im Chaos. Uns hat die Variante 1 viele Probleme bereitet, ist ja nicht das Problem vom Steuerberater :- )

Wenn du mal wirklich Probleme hast, dann merkst du warum nicht doch Dekodi.

Herr Kaumeier von Dekodi versteht sein Handwerk, kann dir seine Seminare wärmstens empfehlen.

LG

 

[wawi-dl]

Da bin ich voll bei euch, darum ja auch Variante 1 bei uns, weil es überschaubar ist.
Wir wollen daher ungern die Arbeitsweise für ein System "verbiegen", wenn es auch anders geht.

Aktuell testen wir nur JTL2DATEV, Kontakt hatte ich bereits mit Dekodi, hatten uns auch so abgesprochen, dass ich zunächst mal JTL2DATEV anschaue.
Mir ist leider noch immer die transaktionsabhänge Abrechnung ein Dorn im Auge.
Betrachtet man beide Systeme, zahlt man für Nexus erstmal insgesammt mehr, was man aber letztendlich dann durch StB ersparrt jeweils, können wir so nicht sagen.

Grundsätzlich gefällt mir Nexus besser ...

 

[Jens31]

Guten Morgen,

um den überblick über Stornos zu behalten, kann man denen einen Rückhaltegrunde geben.

- Storno in Bearbeitung
-Storno Überweisung angewiesen
-Storno Abgeschlossen
- usw.

Für Teilstornos such ich noch nach eine Lösung, da die nicht zurückgehalten werden dürfen.

LG

 

[wawi-dl]

Rückhaltegrund?
Wie willst du diesen kommunizieren?

 

[Jens31]

Hallo,

Bei wem kommunizieren?
Es gibt Workflows oder Arbeitsanweisungen die befolgt werden müssen.
Kunde ruft an, was ist mit meiner Überweisung, ich hatte storniert? jetzt braucht der Service nur bei Stornos zu schauen, um zu sehen, wie weit die Bearbeitung ist. Buchhaltung bekommt per Workflow eine Info zum überweisen und fertig.

Mit Stornierung und Gutschrift hätte man es viel leichter und transparentere, da nur die Gutschriften abgearbeitet werden müssen.





Lg

 

[wawi-dl]

Jetzt, ohne diese Info macht es eben keinen Sinn

Das passiert uns automatisch bereits per Workflow, dass Email mit Info bzgl. Stornierung rausgeht.