Projekt

Allgemein

Profil

Fehler #406

abzurechnender (Netto-)Betrag bei Aufträgen rechnet falsch wenn Rechnungs-Gutschriften vorhanden sind

Von Jan Büren vor etwa 5 Jahren hinzugefügt. Vor etwa 5 Jahren aktualisiert.

Status:
Gelöst
Priorität:
Normal
Zugewiesen an:
-
Zielversion:
-
Beginn:
11.11.2019
Abgabedatum:
% erledigt:

0%

Geschätzter Aufwand:

Beschreibung

Stornos sind i.O., da sich diese aufheben.

Gutschriften sollten eigentlich den Betrag nicht "falsch" ändern, sondern bei Storno / Gutschriften ist ja im Vorgang sowieso etwas nicht nach Plan gelaufen -
Von daher würde ich beide Fälle bei der Berechnung ausklammern:

      SELECT from_id, ar.amount, ar.netamount FROM (
        SELECT from_id, to_id
        FROM record_links
        WHERE from_table = 'oe' AND to_table = 'ar'
        UNION
        SELECT rl1.from_id, rl2.to_id
        FROM record_links rl1
        LEFT JOIN record_links rl2 ON (rl1.to_table = rl2.from_table AND rl1.to_id = rl2.from_id)
        WHERE rl1.from_table = 'oe' AND rl2.to_table = 'ar'
       ) rl
       LEFT JOIN ar ON ar.id = rl.to_id
+      WHERE (ar.amount > 0 OR ar.storno)

Historie

#1

Von Jan Büren vor etwa 5 Jahren aktualisiert

Alternativ darf die Berechnung bei negativen Werten nicht mehr vom Gesamt-Betrag abgezogen werden:

+    if ($ref->{billed_amount} < 0) {
+      $ref->{remaining_amount} = $ref->{billed_amount};
+      $ref->{remaining_netamount} = $ref->{billed_netamount};
+    } else {
      $ref->{remaining_amount} = $ref->{amount} - $ref->{billed_amount};
      $ref->{remaining_netamount} = $ref->{netamount} - $ref->{billed_netamount};
+    }
#2

Von Jan Büren vor etwa 5 Jahren aktualisiert

Hmm.
Das Problem ist zusätzlich noch, dass die Query 2 Ebenen tief greift, aber nicht 3.

Also
Auftrag -> Rechnung -> Gutschrift (i.O.)
Auftrag -> Lieferschein -> Rechnung -> Gutschrift (n.i.O.)

#3

Von Jan Büren vor etwa 5 Jahren aktualisiert

Für diesen Fall:
Auftrag -> Lieferschein -> Rechnung -> Gutschrift (n.i.O.)

Hab ich noch einen weiteren UNION im SQL gemacht, jetzt prüft das Statement noch eine Ebene tiefer.
Alles was im linearen Workflow nach unten verkettet wird in der Gegenrichtung wieder als neuer Workflow betrachte, von daher sollte es keine weitere Zirkulation geben.

Commit #1d4f669171e4d432403b8fa8bea8d88634880b43

#4

Von Jan Büren vor etwa 5 Jahren aktualisiert

  • Status wurde von Neu zu Gelöst geändert

Und hier #da1c0a79edca80d der Fix für den ursprünglichen Fall.

#5

Von Jan Büren vor etwa 5 Jahren aktualisiert

Bei wiederkehrenden Rechnungen funktioniert die Abfrage auch nicht.
Vielleicht sollte man das filtern.

Ansonsten hab ich einen Fall im Datenbestand, der dann weitere Tupel in Richtung email_journal zieht, falls es hier eine ar.id gibt ....

Viel besser fände ich, einfach RecordLinks->get_links aufzurufen, dann muss man die Logik nicht in OE.pm nachbauen.
Negativ-Fall (wir laufen mit joins weiter bis zum E-Mail-Journal):

    1621 |    1109 | ar              |  1231 | ar       | email_journal |  1178

S.a. #99382a645d0cf

Auch abrufbar als: Atom PDF