Fehler #406
geschlossen
abzurechnender (Netto-)Betrag bei Aufträgen rechnet falsch wenn Rechnungs-Gutschriften vorhanden sind
Von Jan Büren vor mehr als 5 Jahren hinzugefügt.
Vor mehr als 5 Jahren aktualisiert.
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)
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};
+ }
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.)
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
- Status wurde von Neu zu Gelöst geändert
Und hier #da1c0a79edca80d der Fix für den ursprünglichen Fall.
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