CreatePeriodicInvoices.pm

[n.simon@…]

Soweit das im Gespräch mit Sven geklärt werden konnte, sammelt «Create­Periodic­Invoices.pm» alle wiederkehrenden Rechnungen der vorangegangenen Periode, heute und morgen, um diese dann mit den vorgegebenen, zurückliegenden(!) Rechnungsdatum zu erzeugen.

Aus buchhalterischer Sicht ist das bei IST-Versteuerung kritisch, denn damit werden Rechnungen für eine Periode erstellt, die zum Monatsende steuerrechtlich bereits erledigt wurde. Auch können ggf. vom Kunden (vorschüssig, weil mit Zahlungsziel vereinbart) geleistete Zahlungen keiner Rechnung zugeordnet werden - die gibt es ja erst nächsten Monat. Das sind dann die von Buchhaltern so heiß geliebten „ungeklärten Fälle”.

Vom Ansatz her müsste sich der Job vom Rechnungsdatum verabschieden und ein Auge auf gewünschte Zahlungsziele haben ("Fälligkeitsdatum"). So soll z.B. eine Rechnung immer "zum 15." gezahlt werden (= Fälligkeit), müsste demnach x Tage vorher geschrieben werden. Dann müsste der Job allerdings grundlegend anders arbeiten, damit z.B. Fälligkeiten zum jeweils 1. bis ca. 6. eines Monats bereits im Vormonat behandelt werden, sonst hat der Rechnungsempfänger keine Chance auf fristgerechtes bezahlen.

Allerdings will man natürlich bei IST-Versteuerung keine Rechnungen vor sich herschieben, die erst in x-Wochen zur Zahlung fällig werden.

Perfekt wäre daher ein Job, der jeden Tag prüft, welche periodischen Zahlungen in 14 Tagen (willkürlich gewählt, einstellbar?) fällig werden und diese dann heute erzeugen. Dann ist Wertstellung, Zahlungsziel, etc. alles so, wie es sein würde, wenn die Rechnung von Hand erzeugt wird. Dabei müssen evtl. auch Rechnungen eingesammelt werden, die auf ein Wochenende oder einen Feiertag gefallen sind. [Daher die 14 Tage, dann bleibt im Zweifelsfall noch eine angemessene Zahlfrist übrig).

In diesem Kontext wäre ggf. zu prüfen, ob eine wiederkehrende Rechnung einen festen Zähler ("Urrechnungs-Nummer") und eine fortlaufende Nummer haben sollte/müsste, damit der Kunde den Zahlbeleg "zuordnungsfähig" als Dauerauftrag ausstellen kann.

Das "vor sich herschieben" gilt natürlich für die SOLL-Versteuerung. Weil da wird ist das ja steuerlich relevant.

Ich verstehe das Problem nicht ganz (vermutlich sollten wir einfach kurz darüber reden). Meiner Meinung nach sollte das auch jetzt schon "gut genug" durch Konfiguration lösbar sein.

• Der Job wird so oder so einmal am Tag angestoßen.
• Jeder als wiederkehrende Rechnung konfigurierte Auftrag hat ein Periodendatum, zu dessen Beginn die Rechnung erzeugt wird. Damit keine Rechnung verloren geht, falls mal der Jobserver einen Tag nicht laufen sollte, werden auch für zurück liegende Termine Rechnungen erzeugt (das ist nicht verhandelbar). Da sich aber gemerkt wird, wann die Rechnung das letzte Mal erzeugt wurde, werden auch keine Rechnungen doppelt erzeugt.
• Normalerweise (z.B. Internetzugang, Zeitungsabo) werden Rechnungen auch wirklich erst zum Beginn der Periode gestellt, und ab dann zählt die Zahlungsfrist.
• Will man wirklich so etwas wie "zahlbar bis zum 15.", warum dann nicht trotzdem Rechnung am 1. stellen und "Zahlbar bis zum 15. des Monats" wortwörtlich draufschreiben? Dass die Anzahl Werktage, die man dann Zeit hat, leicht variieren kann (um bis zu einen Tag), wird doch hoffentlich irrelevant sein.

Replying to m.bunkus@…:

• Der Job wird so oder so einmal am Tag angestoßen.

Wird der nicht nur einmal im Monat gestartet?

sub create_job {
  $_[0]->create_standard_job('0 3 1 * *'); # first day of month at 3:00 am
}

Replying to s.schoeling@…:

Wird der nicht nur einmal im Monat gestartet?

Hmm, stimmt. Sollte meiner Meinung nach aber auch täglich laufen können, ohne dass unschöne Nebenwirkungen entstehen.