Datumsfehleingaben bei Rechnungen unterbinden

[roman.karuschka@…]

So ziemlich jede DB die ich kenne enthaelt "Zukunftsrechnungen", d.h. Rechnungen, bei deren Datumseingabe unbemerkt Fehler geschehen sind. Besonders populaer werden solche Sachen bei Eingangsrechnungen um die Jahreswende.

Beispiel: Rechnung der Telekom geht am 23.12.2011 im Buero ein, wird weil Betrieb ueber Feiertage geschlossen erst am 05.01.2012 bearbeitet

Beispiel: Mitarbeiter traegt das Ding ein und verpasst ihm, da er wie ueblich nur Tag und Monat aendert das Datum "23.12.2012".

Feature-Request daher: Buchungsdaten auf Plausibilitaet pruefen, alle was mehr als einer Woche in der Zukunft liegt bzw mehr als 11 Monate in der Vergangenheit sollte eine extra-Nachfrage ausfwerfen die den User auf den mutmasslichen Fehler hinweist.

Im Vergleich: Kanzlei ReWe? und eine Reihe anderer Programme verfuegen ueber eine solche Warnung schon oder lehnen Zukunftsbuchungen komplett ab

Hi,
das Problem ist eigentlich nerviger als es auf den ersten Blick aussieht.
Wenn das Rechnungsdatum falsch ist, ist dies erstmal technisch leicht zu korrigieren, Finanzbuchhalterisch aber unmöglich falls es erst nach Jahresabschluss auffällt.

Ich sehe drei Lösungsansätze:

1.) DB Function für die Felder (Intervall kann beim Mandanten anlegen bestimmt werden oder nicht)
​http://stackoverflow.com/questions/10256502/postgresql-function-for-checking-date-ranges

2.) Funktion in Perl check_valid_date die entsprechend eines defaults ein Mandanten-Intervall bestimmt

3.) Javascript Oberflächen Prüfung
Diese ist ja schon bei Verkaufsrechnung ewig drin und funktioniert ewig schon nicht wirklich.
Wäre also nett die zu fixen und für Kreditoren / Debitoren und im Dialog dann zu haben.

Als weitere einfach Sofort-Massnahme könnte man die SelfTests? erweitern, genau für solche Präventiv-Massnahmen ist die ja vorgesehen.

Erstmal soweit als Idee an dieser Stelle.

Hmm.

Eigentlich doch mittlerweile einfach und sauber umzusetzen.

An den fünf Stellen wo der DATEV-Check durchgeführt wird (post_transaction in GL, AP und AR, die anderen beiden hab ich gerade vergessen), kann davor noch eine Funktion transdate_check aufgerufen werden. Die kann man jetzt auch simpel copy und paste mässig konfigurierbar machen und einen Wert für den Intervall-Zeitraum einbauen.

Ok, ich würde die Funktion mit DateTime? einfach im Kern so bauen:

my $transdate_as_datetime = DateTime?->from_lxoffice($::form->{transdate});
my $today = DateTime?->today;
my $days = int($today->subtract_datetime_absolute($transdate_as_datetime)->delta_seconds / (24*60*60));

Dann würde es einen Minimalwert nach hinten geben und einen Maximalwert in die Zukunft. Der Minimalwert ist ja auch schon durch den geschlossenen Zeitraum definiert.

Hmmm.

Die andere Programmstelle in Perl wäre dann die Stelle wo closedto (also geschlossene Periode oder nicht geschlossene Periode) überprüft wird.
Spontan habe ich hier drei offene Fragen, müssten Zeitzonen noch bedacht werden?
Soll das bei datev_check im Backend eingebaut werden mit Minimal- und Maximalwert oder lieber eine Ebene mehr Aufwand betreiben und ggf. bei / mit closedto erledigen?

Mir gefällt spontan bei datev_check mit Minimal und Maximalwerten am Sinnvollsten, dass kann dann auch in die Mandanten-Oberflächen Konfiguration.

So, übers Wochenende find ich eine Erweiterung an derselben Programmstelle wo Form->date_closed aufgerufen wird sinnvoller.
Dieses Check wird in ap.gl, ar.gl und gl.pl ausgeführt.
In ir und is ist die Funktion anders:

$form->{locked} = ($form->datetonum($form->{invdate}, \%myconfig)

<= $form->datetonum($form->{closedto}, \%myconfig));

Also das könnte man auch mal an dieser Stelle gleichziehen.

Die Berechnung wäre dann eher in psql, sowas wie:

SELECT 1 from defaults where ? - current_date > max_future_intervall

Intervall einstellbar unter Bücherkontrolle

Erledigt.

f552f878c85828a
a11d7a85a9b73798acb3a1