Weil Vergleiche mit NULL immer FALSE liefern!!
Nun bin ich zum 2.Mal beim Füllen der Zahlungsschnittstelle in den gleichen Fehler gelaufen.
Wie will man einem Geschäftsführer erklären, das auf einmal Lieferanten-Rechnungen mit
der Bemerkung '(Zahlung u. Vorbehalt)' gezahlt werden, wenn doch an der Schnittstelle Lieferanten-Rechnung => Zahlungsbuch => SEPA-Lauf gar Nichts geändert wurde?
Dabei bin ich nur auf die wahnsinnige Idee verfallen, nach AvERP-Best-Practice eine Kundenspezifische Änderung an ganz anderer Stelle im SQL-Code über die SYNERPY_KUNR zu kapseln. Vielleicht wird die Änderung ja dadurch Update-Sicher???
Die geniale IF-Anweisung IF (SYNERPY_KUNR NOT IN(' schlägt ja fehl,
wenn SYNERPY_KUNR IS NULL.
Man denke bloß nicht, das mit Löschen der SYNERPY_KUNR im Firmenstamm der ursprüngliche Zustand widerhergestellt werden könnte. Denn nach einmaliger Änderung wird jetzt wohl statt NULL ein Leerstring für die SYNERPY_KUNR geliefert und man ist gezwungen einen Wert einzugegen und im Quellcode der Procedure so langsam eine Liste aller Kunden aufzubauen, die diese geniale Zahlung unter Vorbehalt nicht leisten wollen... oder einfach auszukommentieren!!!
Ganz vorsichtig Suche in den Metadaten zeigt, das das Konstrukt IF (SYNERPY_KUNR NOT IN('
wirklich nur in P_BLRC_NACH_BZAHL auftaucht
Code:
P_BLRC_NACH_BZAHL
...
IF (SYNERPY_KUNR NOT IN('AM03')) THEN
BEGIN
EXECUTE PROCEDURE P_SMREPORTLABEL(NULL,'ZAHLUNG_UNTER_VORBEHALT',
'(Zahlung u. Vorbehalt)')
RETURNING_VALUES(:ZAHLUNG);
VERWENDUNG = VERWENDUNG || ' ' || CAST(:ZAHLUNG AS VARCHAR(85));
END
