Handbuch · Arbeiten mit TIM · Howtos · TIM für ÖSHZ

Der Befriedigungs-Algorithmus

Beim Registrieren jedes Buchungsdokuments werden die Auswirkungen der neuen Buchungen auf bestehende Buchungen ermittelt. Das ist der so genannte Befriedigungsalgorithmus.

Die Befriedigungstabelle

In der Befriedigungstabelle wird definiert, welche Journale welche anderen Journale «befriedigen» können.

Beispiel : Eine Bestellung (BST) wird durch eine Eingangsrechnung (REG) befriedigt. So lange die REG nicht gebucht ist, gilt die BST als «offen» bzw. «unbefriedigt». BST wartet auf REG. Eine REG ihrerseits verlangt ebenfalls nach einer Folgebuchung, und zwar nach einem Mandat bzw. einer Zahlungsanweisung (ANW). REG wartet auf ANW. Und die ANW wartet darauf, dass sie durch eine Tresoreriebuchung (Bank oder Kasse) bezahlt wird. Dies geschieht entweder direkt in Bar, oder per Zahlungsauftrag (ZAU) über die Bank. Der ZAU befriedigt die ANW, wartet dann seinerseits darauf, durch den Kontoauszug befriedigt zu werden.

BST wartet auf REG, REG wartet auf ANW, ... das ist es, was in der Befriedigungstabelle steht:

Gr1  │ Gr2  │ Attribute
───── ────── ──────────
BST  │ REG  │
REG  │ ANW  │
ANW  │ ZAU  │
ZAU  │ TRE  │
ANW  │ TRE  │

Gr1 : «wer wird befriedigt?»
Gr2 : «wer befriedigt?»
Attribute : «unter welchen Bedinungen»

(In Wirklichkeit stehen in der Tabelle mehr Einträge, weil manche Fälle detailliert pro Journal angegeben werden müssen, und außerdem kommt noch eine ähnliche Serie für Einnahmen hinzu.)

Befriedigungsattribute

Die «Attribute» in der Befriedigungstabelle kommen hinzu, um gewisse Einschränkungen oder Bedingungen zu definieren. In etwa «Okay... eine ANW wird durch einen ZAU befriedigt... aber nicht durch gleich welchen!»

M : Backmatch muss übereinstimmen
M bedeutet : nicht nur der Match, sondern auch der Backmatch muss übereinstimmen.
Beispiel : wir haben eine große Bestellung, für die nach und nach Rechnungen rein kommen, die dann jeweils bezahlt werden. Alle Buchungen haben den gleichen Match (den der Bestellung).
```
Jnl+Dok          Betrag  Backmatch
─────────────── ───────  ─────────
  BST 1         600,-
    REG 1        12,-    BST 1
      ANW 1      12,-    REG 1
        ZAU 1    12,-    ANW 1
    REG 2        42,-    BST 1
      ANW 2      42,-    REG 2
          CCB 1  12,-    ZAU 1
```
Wenn für «ANW-wartet-auf-CCB» das Attribut M nicht gesetzt wäre, dann würde der CCB 1 die erstbeste Buchung mit gleichem Match befriedigen, und das wäre im vorliegenden Fall die ANW 2. (Der Befriedigungsalgorithmus sucht immer rückwärts). Er muss aber ZAU 1 befriedigen, die nicht nur den gleichen Match, sondern auch den gleichen Backmatch hat.
Attribut M sollte für alle Einträge der Befriedigungstabelle gesetzt sein, deren IdGrj2 ZAU oder TRE ist.
S : Selbstbefriedigt
S bedeutet, dass die befriedigende Buchung dadurch, dass sie befriedigt, ihrerseits selber befriedigt wird.
Beispiel : Zahlungen sind selbstbefriedigt. Wenn eine Zahlung rausgeht, die eine andere Buchung befriedigt (z.B. eine ANW oder einen ZAU), dann ist die Zahlung als solche befriedigt. Aber wenn die Zahlung niemanden befriedigen konnte, dann ist sie ihrerseits unzufrieden und muss (z.B. durch einen nachträglichen Ausgabebeleg) befriedigt werden.
P : Permanent (bleibt offen)
U : befriedigten Betrag wieder ent-zentralisieren
N : befriedigten Betrag nicht zentralisieren
X : Backmatch entfriedigen

Journalattribute

JNLATTR_U : Überbefriedigung bei Übernahme verweigern. Ich habe eine Anweisung von 1000 BEF. Mache mit [F5] eine Übernahme in einem ZAU und ändere dann den Betrag von 1000 auf 1005 BEF. Das sollte verboten sein, indem das JNLATTR_U gesetzt wird. Weniger als 1000,- zu befriedigen ist freilich weiterhin erlaubt. Diese Kontrolle ist natürlich auch dann zu unterlassen, wenn es sich um eine nicht mit [F5] übernommene Buchung handelt. Dieses Attribut ist unabhängig vom JNLATTR_A, weil z.B. auch denkbar im Journal ANW, in dem keine automatischen Folgedokumente kommen. Bisher wird hier eine Überbefriedigung einfach ohne weitere Konsequenzen toleriert. JNLATTR_U hieße hier, dass jede Anweisung verweigert wird, die sich auf eine Rechnung bezieht (sprich: deren BackMatch nicht leer ist), und die den Rechnungsbetrag übersteigt. Andererseits ist eine Überbefriedigung sehr wohl erlaubt bei Journalen, die dieses Attribut nicht haben. Z.B. eine REG, die höher als die Bestellung ausfällt. Dies ist eine Änderung in ImpImlScan(). Es ist besser, das im Befriedigungsalgorithmus zu testen als bei der Eingabe. Weil sonst kommt z.B. jemand auf die Idee, eine Buchung in zwei Schritten zu überbefriedigen.