Proformarechnungen - Eigene Maske, Handling und Sinn

[roman.karuschka@…]

Proformarechnungen sind in LX-Office bislang als spezielle Druckmaske enthalten, die aus Auftraegen sowohl als auch Rechnungen erzeugt werden koennen.
das ist zwar ein guter Ansatz, aber damit fuehren die PFRs immer noch ein Nischendasein wie einstmals die Lieferscheine, die der Realitaet bei einigen Kunden nicht ganz gerecht wird.

Proformarechnungen sind einerseits fuer Zollzwecke in's Nicht-EU-Ausland relevant, dort werden sie der Ware beigelegt und entsprechend besteuert (oder auch nicht, falls "0")

Andererseits haben sich proformarechnungen aber in der Vergangenheit auch immer staerker bei kleinen (und einigen mittelstaendischen) Firmen durchgesetzt, die faktisch auf einen Auftrag hin eine Profomarechnung an den Kunden schreiben, sich damit bereits die Zahlung einfordern noch bevor die Ware gefertigt oder geliefert wurde.
Einer der Sinne dahinter ist oftmals der, dass je nach steuerlicher Konstellation die USt/MWSt ebenfalls bereits ausgewiesen und erhoben wird, aber bis zur Warenlieferung de facto nicht an's zustaendige FA abgefuehrt wird.
Und selbst da, wo dies bereits geschieht, sprich die 19% an den Fiskus gehen, werden andere Steueranteile bis zur Lieferung auf keinen Fall faellig.

Soviel zum Sinn der Proformas, Diskussion erbeten ;-)

Eine Anregung fuer LX waere es nun, Proformarechnungen als einen eigenen Menuepunkt einzufuehren, in weiten Teilen waeren Sie Funktionsdoubletten von vollwertigen Rechnungen, sprich, und das ist eines der grossen Defizite zu den bsiherigen Loesungen, es kann bereits ein Zahlungseingang verbucht werden, allerdings meinem Vorschlag nach auf ein Sonderkonto oder bereits mit vorbereiteten Eintraegen fuer die richtige Kontenbuchung. Denn der Tag kommt ja irgendwann, an dem sie zu richtigen Rechnungen gewandelt werden (Workflow) und sofern der Geldeingang bereits laengst erfolgte diesen auch direkt ausweisen sollten.
Ausserdem muessten diese PFRs auch Grundlage fuer Zahlungsfristen und Mahnlaeufe werden, denn kundenseitig sind sie fast vollstaendig wie "vollwertige" Rechnungen zu behandeln.

Sorry fuer den langen Text, ist ein nicht gerade unkomplexes Thema.
Ich versuche hierzu die Tage mal einen Steuerberater nach den Details zu loechern.

(In reply to comment #0)

Proformarechnungen sind in LX-Office bislang als spezielle Druckmaske
enthalten, die aus Auftraegen sowohl als auch Rechnungen erzeugt werden
koennen.
das ist zwar ein guter Ansatz, aber damit fuehren die PFRs immer noch ein
Nischendasein wie einstmals die Lieferscheine, die der Realitaet bei einigen
Kunden nicht ganz gerecht wird.

Proformarechnungen sind einerseits fuer Zollzwecke in's Nicht-EU-Ausland
relevant, dort werden sie der Ware beigelegt und entsprechend besteuert (oder
auch nicht, falls "0")

Andererseits haben sich proformarechnungen aber in der Vergangenheit auch immer
staerker bei kleinen (und einigen mittelstaendischen) Firmen durchgesetzt, die
faktisch auf einen Auftrag hin eine Profomarechnung an den Kunden schreiben,
sich damit bereits die Zahlung einfordern noch bevor die Ware gefertigt oder
geliefert wurde.

Hier müsste eigentlich eine normal Anzahlungsrechnung geschrieben werden;
dann kann man entsprechende Zwischenrechnungen schreiben und zu guter Letzt die Abschlussrechnung, in der alle vorangegangenen Rechnungen UND Zahlungen sowie die entsprechenden Steuerbeträge ausgewiesen werden müssen.

In diesem Fall werden nur die Steueranteile zum Abführen fällig, die auch tatsächlich erlöst wurden.

Einer der Sinne dahinter ist oftmals der, dass je nach steuerlicher
Konstellation die USt/MWSt ebenfalls bereits ausgewiesen und erhoben wird, aber
bis zur Warenlieferung de facto nicht an's zustaendige FA abgefuehrt wird.
Und selbst da, wo dies bereits geschieht, sprich die 19% an den Fiskus gehen,
werden andere Steueranteile bis zur Lieferung auf keinen Fall faellig.

Soviel zum Sinn der Proformas, Diskussion erbeten ;-)

Eine Anregung fuer LX waere es nun, Proformarechnungen als einen eigenen
Menuepunkt einzufuehren, in weiten Teilen waeren Sie Funktionsdoubletten von
vollwertigen Rechnungen, sprich, und das ist eines der grossen Defizite zu den
bsiherigen Loesungen, es kann bereits ein Zahlungseingang verbucht werden,
allerdings meinem Vorschlag nach auf ein Sonderkonto oder bereits mit
vorbereiteten Eintraegen fuer die richtige Kontenbuchung. Denn der Tag kommt ja
irgendwann, an dem sie zu richtigen Rechnungen gewandelt werden (Workflow) und
sofern der Geldeingang bereits laengst erfolgte diesen auch direkt ausweisen
sollten.
Ausserdem muessten diese PFRs auch Grundlage fuer Zahlungsfristen und
Mahnlaeufe werden, denn kundenseitig sind sie fast vollstaendig wie
"vollwertige" Rechnungen zu behandeln.

Das könnte man sich mit Anzahlungs-/Zwischenrechnung/Schlussrechnung? völlig sparen. Denn dann wird die Kundenzahlung genauso verbucht, wie normale Rechnungen auch. Und damit ist es auch erheblich unkomplexer :-)

Sorry fuer den langen Text, ist ein nicht gerade unkomplexes Thema.
Ich versuche hierzu die Tage mal einen Steuerberater nach den Details zu
loechern.

Löchern ist immer gut; aber wenn man es wirklich korrekt machen will, muss man Geld in die Hand nehmen und sich diese Funktion (Schlussrechnung) programmieren lassen. DENN: je nachdem, wie die Teil- bzw. Anzahlungsrechnung geschrieben wurde, die Schlussrechnung muss ALLE Artikel, sei es Ware oder Dienstleistungen, sowie alle Seriennummern enthalten. Das führt zu dem absurden Problem, daß, habe ich zwischenzeitlich etwas separat aus einem gesamten Auftrag, für den ich Anzahlung oder Teilzahlung bekommen habe, berechnet, ich diese(n) Artikel erneut berechnen muss (in der Schlussrechnung) Um das abzufangen, ist Programmierarbeit nötig, Kostenpunkt so um die 1600 EUR zzgl. Mwst.

Wenn's einfacher geht, immer, aber ich denke, da ist das Steuerrecht "im Weg".

Das könnte man sich mit Anzahlungs-/Zwischenrechnung/Schlussrechnung? völlig
sparen. Denn dann wird die Kundenzahlung genauso verbucht, wie normale
Rechnungen auch. Und damit ist es auch erheblich unkomplexer :-)

Genau da ergibt sich aber der Punkt, denn im Grunde muessten Zahlungen aus PF-Rechnungen auf einem Zwischenkonto geparkt werden, sowohl die Netto- als auch die Steueranteile.

Wenn man es so realisiert, wird es evtl einfacher.
Fehlt nur ein Weg das dann nahtlos in eine "Endrechnung" zu ueberfuehren.

... DENN: je nachdem, wie die Teil- bzw. Anzahlungsrechnung geschrieben
wurde, die Schlussrechnung muss ALLE Artikel, sei es Ware oder
Dienstleistungen, sowie alle Seriennummern enthalten. Das führt zu dem absurden
Problem, daß, habe ich zwischenzeitlich etwas separat aus einem gesamten
Auftrag, für den ich Anzahlung oder Teilzahlung bekommen habe, berechnet,...

Das fuehrt dann wieder zu einem prinzipiellen anderen Problem..Auftraege, Lieferscheine und Rechnungen elegant zu splitten und wieder zusammenzufuehren naemlich. Das wird im Moment in den meisten ERPs vermutlich manuell gemacht.

Gedankenspiel..
Jetzt daher mal eine Entwurfsfrage fuer vermutlich fruehestens Version 3.0: wie waere es, wenn man eine Art "objektorientierte ERP" einfuehren wuerde? Ein Vorgang, der Artikel und/oder Dienstleistungen erhaelt, die sich in Angeboten, Rechnungen, Lieferscheinen etc rund um den Vorgang der quasi "im Zentrum" sitzt wiederspiegeln und anheften?
So koennte man am ehesten und saubersten einzelne Teile aus dem Topf in der Mitte mit einzelnen Dokumenten aussen verknuepfen ohne die Uebersicht zu verlieren. Modular erweiterbar um beliebige Dokumente waere das auch besser als die meisten ERPs.
Und bevor der Einwurf kommt, ja, ich weiss, das kostet Einiges (sic!) an Mannstunden und damit auch Geld ;-)
Es handelt sich erstmal nur um einen abstrakten Designgedanken, ob den jemand aufgreifen moechte bleibt demjenigen ja ueberlassen.

(In reply to comment #2)

Das könnte man sich mit Anzahlungs-/Zwischenrechnung/Schlussrechnung? völlig
sparen. Denn dann wird die Kundenzahlung genauso verbucht, wie normale
Rechnungen auch. Und damit ist es auch erheblich unkomplexer :-)

Genau da ergibt sich aber der Punkt, denn im Grunde muessten Zahlungen aus
PF-Rechnungen auf einem Zwischenkonto geparkt werden, sowohl die Netto- als
auch die Steueranteile.

Warum?

Wenn man es so realisiert, wird es evtl einfacher.
Fehlt nur ein Weg das dann nahtlos in eine "Endrechnung" zu ueberfuehren.

Stimmt. Wenn ich also anklicke: "Schlussrechnung" könnte mir LX Office alle geschriebenen Rechnungen des Kunden (vielleicht eingeschränkt nach einem Zeitbereich oder Vorgangsbezeichnung oder oder, wenn das gewünscht wird) anzeigen. Dann wähle ich per Checkbox die Rechnungen aus, die auf dieser Abschlussrechnung genannt werden sollen und LX zieht sich die entsprechenden Daten aus der Datenbank, sind ja vorhanden.

Und könnte dann nur noch den Restbetrag als fälligen Betrag in der Buchhaltung auswerfen, denn die anderen sind ja (hoffentlich) bereits bezahlt.

... DENN: je nachdem, wie die Teil- bzw. Anzahlungsrechnung geschrieben
wurde, die Schlussrechnung muss ALLE Artikel, sei es Ware oder
Dienstleistungen, sowie alle Seriennummern enthalten. Das führt zu dem absurden
Problem, daß, habe ich zwischenzeitlich etwas separat aus einem gesamten
Auftrag, für den ich Anzahlung oder Teilzahlung bekommen habe, berechnet,...

Das fuehrt dann wieder zu einem prinzipiellen anderen Problem..Auftraege,
Lieferscheine und Rechnungen elegant zu splitten und wieder zusammenzufuehren
naemlich. Das wird im Moment in den meisten ERPs vermutlich manuell gemacht.

Eben.

Alternativ kann ich die bereits gelieferten und berechneten Artikel ja über einen Dienstleistungsartikel eintragen und damit eine Lagerbuchung verhindern.
Aber bei richtig großen Projekten habe ich ein ganz anderes Problem. Es dauert ewig, 50 Artikel zu erfassen :-( Redrawzeiten sind unmenschlich.

Gedankenspiel..
Jetzt daher mal eine Entwurfsfrage fuer vermutlich fruehestens Version 3.0: wie
waere es, wenn man eine Art "objektorientierte ERP" einfuehren wuerde? Ein
Vorgang, der Artikel und/oder Dienstleistungen erhaelt, die sich in Angeboten,
Rechnungen, Lieferscheinen etc rund um den Vorgang der quasi "im Zentrum" sitzt
wiederspiegeln und anheften?
So koennte man am ehesten und saubersten einzelne Teile aus dem Topf in der
Mitte mit einzelnen Dokumenten aussen verknuepfen ohne die Uebersicht zu
verlieren. Modular erweiterbar um beliebige Dokumente waere das auch besser als
die meisten ERPs.
Und bevor der Einwurf kommt, ja, ich weiss, das kostet Einiges (sic!) an
Mannstunden und damit auch Geld ;-)

Wenn sich jemand findet, der das bezahlt, könnte das schon passieren, aber ich denke, da gibt es im Augenblick erst mal drängendere Probleme.

Es handelt sich erstmal nur um einen abstrakten Designgedanken, ob den jemand
aufgreifen moechte bleibt demjenigen ja ueberlassen.

Eh klar.

...

Genau da ergibt sich aber der Punkt, denn im Grunde muessten Zahlungen aus
PF-Rechnungen auf einem Zwischenkonto geparkt werden, sowohl die Netto- als
auch die Steueranteile.

Warum?

Weil Waren und Dienstleistungen in zumindest einer gaengigen Variante der profomrarechnungen hierzulande bereits bezahlt werden muessen vom Kunden, aber erst bei Warenlieferung versteuert werden muessen (ganz oder in Teilen).
Daher darf erstmal nicht auf die "normalen" Konten gebucht werden, weil von dort ja die Auswertungen fuer die aktuellen UStVAs etc kommen.

Stimmt. Wenn ich also anklicke: "Schlussrechnung" ...

Und könnte dann nur noch den Restbetrag als fälligen Betrag in der Buchhaltung
auswerfen, denn die anderen sind ja (hoffentlich) bereits bezahlt.

Ein Kunde von uns verwendet PFR so, dass Lieferungen, die erst in 2 jahren stattfinden bereits jetzt bezahlt werden muessen, sprich sie werden komplett als bezahlt markiert, und die "bezahlt"-Eintraege die zu einer solchen PFR-Maske gehoeren wuerden muessten in die Rechnungsmaske der "Endrechnung" dupliziert werden, wobei dafuer dann nur zwischen internen Konten umgebucht wuerde.

Alternativ kann ich die bereits gelieferten und berechneten Artikel ja über
einen Dienstleistungsartikel eintragen und damit eine Lagerbuchung verhindern.

Hmm, machbar, aber ist das nicht sehr fehleranfaellig sobald mehrere Koeche an dem Brei kochen?

Aber bei richtig großen Projekten habe ich ein ganz anderes Problem. Es dauert
ewig, 50 Artikel zu erfassen :-( Redrawzeiten sind unmenschlich.

Da faellt mir eigentlich nur AJAX ein, in die CRM haellt das ja schon Einzug, das Frontend der ERP wird auch sicherlich irgendwann dran sein, dann geht das etwas einfacher.
Priznipiell waere ein kleines CSV-Export- und Importformat fuer Rechnungen, Lieferscheine, Auftraege etc ansonsten eine Programmierloesung die es fuer den Moment einfacher machen koennte alle notwendigen Artikellisten fuer eine zu erstellende Rechnung schnell zu verknuepfen.
Rechnungsmaske laden, CSV ueber Dialog einspielen, alle Artikel drin, nur noch Kunden- und Lieferdaten anpassen. Soweit die Theorie. Natuerlich auch eine Loesung die jemand entweder selber in Angriff nehmen oder bezahlen muesste, der Aufwand koennte aber glatt verschmerzbar sein im Hinsicht auf benoetigte Stunden.

Gedankenspiel..

Wenn sich jemand findet, der das bezahlt, könnte das schon passieren, aber ich
denke, da gibt es im Augenblick erst mal drängendere Probleme.

Das ist klar, aber von Zeit zu Zeit koennte es helfen, wenn sich mal alle Entwickler und Zubringer an einen Tisch (oder in ein Forum) setzen und eben solche abstrakten Designs besprechen, denn ansonsten wird u.U. in eine Richtung weiterprogrammiert, die spaeter Aenderungen schwerer macht bzw wo man mit zwei zusaetzlichen Zeilen Code direkt etwas haette vorbereiten koennen, dass sonst spaeter komplett neu angegangen werden muss.

Gerade hier auf der Dev-Liste passiert ja nicht soviel im Bezug auf grundsaetzliche Systemfragen, es werden uebermaessig Einzelbaustellen angegangen.

Geoffrey, ich weise den mal auf dich zu da wir bei diesem Thema im Moment ja alle dran sind.