Import von Zahlungseingängen

Das Fenster dient dazu, Zahlungseingänge zu Rechnungen aus einer anderen Anwendung in die Rechnungsausgangstabelle von Beton.NET zu importieren. Als Voraussetzung hierfür muss eine Datei mit den Importformat-Definitionen im Programmverzeichnis des Beton.NET-Servers vorhanden sein und es muss in der Definitionsdatei ein Format enthalten sein, dass zum Format Ihrer Importdaten passt. Diese Import-Definitionen werden in der Regel durch den Software-Entwickler erstellt.

Hinter der Combo-Box zur Formatauswahl befindet sich ein Schalter zum Bearbeiten der Formatdefinitionen. Diese Aktion erfordert besondere Kenntnisse und ist in erster Linie für die Entwickler gedacht.

Das Programm liest die einzelnen Datensätze ein, analysiert deren Inhalt anhand der Importdefinitionen und veranlasst bei positivem Ergebnis die weitere Verarbeitung / Protokollierung. Unzutreffende Datensätzen werden in bestimmten Fällen überlesen, in anderen Fällen auf der Ergebnisliste dargestellt. Im einzelnen wird folgendermaßen verfahren:
  • Mit "positivem Ergebnis" in vorstehendem Sinn ist der Befehl RETURN TRUE gemeint. (siehe weiter unten unter "Gestaltung der ImportZahl.def-Datei"). Das braucht nicht zwingend genau einem Datensatz der Einlesedatei zu entsprechen. Datensätze können durch die Importdefinitionen ausgeschlossen werden oder benachbarte Datensätze können zusammengefasst werden. Zur Verarbeitung wird ein Datentripel bereitgestellt, bestehend aus der Rechnungsnummer, dem Zahlungsbetrag und dem Datum. Zusätzlich ist auch noch der Bruttobetrag der Rechnung möglich.
  • Wenn die Rechnungsnummer zu keiner in der Datenbank vorhandenen Ausgangsrechnung gehört, dann wird die betroffene Verarbeitungsaktion ohne Maßnahme übergangen. Andere Aktionen, nämlich solche, zu denen eine Rechnung existiert, werden mindestens auf dem Protokoll ausgewiesen, bei zulässigen Veränderungen werden auch Daten in der Datenbank angepasst.
  • Das übergebene Datum wird als Teilzahlungsdatum gespeichert; ein eventuell schon vorhandenes Datum wird dabei überschrieben.
  • Wenn der zu zahlende Sollbetrag erreicht ist, wird das Häkchen bezahlt gesetzt und das übergebene Datum als bezahlt-Datum gespeichert. Auch dabei wird ein eventuell schon vorhandenes Datum überschrieben.
  • Für das Erreichen des zu zahlenden Betrages gelten folgende Bedingungen.
    • Entweder muss der Sollbetrag (zu einem beliebigen Datum) durch den Zahlungsbetrag erreicht oder überschritten sein.
    • Oder der skontierte Betrag muss innerhalb der Skontofrist durch den Zahlungsbetrag erreicht oder überschritten sein.
    • Wenn in den importierten Daten das Feld BRUTTO enthalten ist, dann wird für den vorgenannten Vergleich dieses Feld statt des Sollbetrages verwendet; der Sollbetrag selbst wird aber nicht verändert.
    • Durch Vorgeben einer Toleranz für Skonto-Überziehung (in Tagen) können Sie die ursprünglich gewährte Skonto-Frist für die vorgenannte Prüfung verlängern.
  • Die Funktionsweise hängt auch von Einstellungen ab, die weiter unten unter "Gestaltung der ImportZahl.def-Datei" erläutert sind.
Bei dem Format mit Datenbankzugriff (derzeit nur Arriba) können Sie rückliegende Tage vorgeben. Die hier eingestellte Zahl ist als Inhalt eines Ersatzausdruckes bei dem Datenbankbefehl des Importformates verwendbar. Dort könnte zum Beispiel die Bedingung "belegdatum>=SYSDATE-@TAGE" definiert sein.

Vom Ergebnis des Imports können Sie sich im Protokoll überzeugen. Die vorgenommenen Änderungen sehen Sie außerdem im Fenster Rechnungsausgang.

Hinweise zur Gestaltung der ImportZahl.def-Datei

Es wird eine einheitliche Syntax zum Importieren von Lieferscheinen, Stammdaten und Zahlungseingängen verwendet. Außer den Sachverhalten, die im Fenster Bearbeiten der Formatdefinitionen beschrieben oder dort ersichtlich sind, gilt noch folgendes:

Es werden die folgenden vier Datenfelder der Tabelle RAUSGANG verwendet: RNUMMER, TZAHLUNG, TZDATUM und BRUTTO. Beim Auftreten von RETURN FALSE wird die Verarbeitung des Eingabe-Datensatzes ohne Verarbeitung abgebrochen. RETURN TRUE bewirkt die Verarbeitung des Datensatzes. Falls kein RETURN vorkommt, wird am Ende der Definitionen verarbeitet.

In den Folgezeilen nach der Format-Kennung können bestimmte Einstellungen stehen, die mit einem Stern (*) eingeleitet werden. Um die jeweilige Einstellung außer Kraft zu setzen, kann man die betreffende Zeile löschen oder den Stern durch ein Apostroph (Kommentarzeichen) ersetzen. Folgende Einstellungen sind möglich:
  • *KUMULIEREN: Der übergebene Betrag wird zum bisher eventuell schon in der Datenbank vorhandenen Teilzahlungsbetrag addiert = kumuliert. Achtung: In diesem Fall darf jede Importdatei nur ein einziges Mal importiert werden. - Der Gegensatz hierzu ist das Ersetzen des Betrags in der Datenbank durch den Betrag der Importdatei. Dann muss die Importdatei auch bei Teilzahlungen den insgesamt gezahlten Betrag enthalten. Der Betrag wird auch dann ersetzt, wenn der neue Betrag niedriger als derjenige in der Datenbank ist.
  • *RECH_ZUSAMM: Wenn Teilzahlungsbeträge zu einundderselben Rechnung an verschiedenen Stellen in der Datei stehen, dann funktioniert das Kumulieren ohne Besonderheiten. Beim Ersetzen würde aber ein Problem auftreten, indem der zweite Teilbetrag den ersten Teilbetrag überschreiben würde. Durch diese Einstellung wird das Problem verhindert, indem der Programmcode nach dem Einlesen der Importdatei und vor deren Verarbeitung die Datensätze mit gleicher Rechnungsnummer zusammenfasst, indem die Teilbeträge kumuliert werden und das jeweils größte Datum verwendet wird. - Ohne diese Einstellung wird jedes Ergebnistripel einzeln, unabhängig von anderen verarbeitet.
  • *STRENG: Durch diese strenge Prüfungen gegen Überzahlung wird kein Zahlungseingang (auch kein negativer) akzeptiert, wenn die Rechnung bereits das Bezahlt-Häkchen hat. Und es wird keine Bezahlung über den Bruttobetrag der Rechnung hinaus akzeptiert. Bei Verletzung dieser Bedingung wird der Datenbank-Datensatz nicht verändert; der Protokoll-Eintrag wird als "überzahlt" gekennzeichnet.
  • *SKONTO_IGN: Das in der Datenbank vorhandene erlaubte Skonto wird ignoriert. Diese Einstellung kann in zwei Situationen nützlich sein: Erstens, falls sich aus der Importdatei nicht erkennen lässt, ob es sich bei den Beträgen um reale Zahlungen/Teilzahlungen oder um in Anspruch genommene Skontobeträge handelt. Und zweitens, wenn die Importdatei auch solche Positionen enthält, die vom Benutzer - auch über das erlaubte Skonto hinaus - bereits als Minderung akzeptiert worden sind.
Während der Bearbeitung der Formatdefinitionen werden die Einstellungszeilen durch Zufügen der Vorsätze "' (zur Formatbearbeitung deaktiviert) " temporär unwirksam gemacht, weil sie nicht der allgemeingültigen Import-Syntax entsprechen. Beim Speichern des Formates werden diese Vorsätze wieder entfernt.
Bamberg