Can't call method "accno" on an undefined value at /var/www/kivitendo-erp/bin/mozilla/is.pl line 1198.

Question

Hallo Zusammen,

aus welchen Gründen auch immer bekomme ich nun diese Fehlermeldung,
wenn ich eine neue Rechnung erstellen möchte.

Ggf hängt das Problem auch mit einer Migrtion auf Postgres 16 zusammen.

Ich dachte eigentlich, die Anwendung nach der Umstellung ausreichend getestet zu haben.

Gruß
Christian

Answer 1

Du hast ca. Release 3.9

Ist dieses DB-Skript erfolgreich durchgelaufen?

defaults_set_ARAP

Bzw. hier müsste eine ID in deiner DB kommen:

select ar_chart_id from defaults;

Comments

Hallo jan,

(1) danke für die schnelle Antwort.
(2) Die SQL Abfrage liefert für die kikitendo-DB eine null!
Klingt vermutlich nach der Ursache meines Problem.

(3) Du hast nach dem DB-Skript gefragt, das gelaufen sein soll. Handelt es sich
dabei um das Skript, dass nach der Anmeldung started, um eine DB zu aktualisieren,
das trifft zu.

Gruß
Christian

---

Exakt.

Das Skript ist zwingend erforderlich, damit alles wieder passt:

sql/Pg-upgrade2/defaults_set_ARAP.sql

Postgres hat eine Schicht "schema_info", daran macht kivi dann fest, ob das Skript schon ausgeführt wurde oder nicht.

select * from schema_info ;

Da müsste dann der Tag des Upgrade-Skripts inkl. Zeitstempel mitprotokolliert sein.

Falls das da ist, gibt es in der Tat vielleicht eine Postgres 16 Herausforderung für das seit 2 Jahrzehnten bewährte Verfahren.
Falls das nicht da ist, ist irgendetwas eher lokal bei Dir schief gelaufen.

---

Nochmals vielen Dank,

leider kann ich das sql weder unter dem ausgecheckten Version-Tag release-3.9.0 noch unter dem master unter dem genannten Pfad auf github finden.

Gruß
Christian

---

Ahh, dann hilft ein Upgrade auf die 3.9.1

https://github.com/kivitendo/kivitendo-erp/blob/master/sql/Pg-upgrade2/defaults_set_ARAP.sql

Upps, die Version gibt es noch gar nicht.

Dann zieh das Skript aus dem aktuellen github:

git fetch
git cherry-pick ea08b7dfc0c536290cce845cf41adcfeb8a2ac2f

---

Hallo Jan,

das Problem besteht weiterhin. In einem anderen Testaufbau hatte ich:
- einen abgesicherten alten Bestand in die DB geladen
- das von Dir genannte und verlinkte Script ausgeführt
- den Anwendungsserver neu gestartet
- und dann versucht eine neue Rechnung zu erstellen.

mit der folgende Fehlermeldung als Ergebnis:

Fehler!

Can't call method "accno" on an undefined value at /var/www/kivitendo-erp/bin/mozilla/is.pl line 1198.

Kurz ein paar Worte zu der Umgebung. Als Host und DB Server agiert immer eine möglichst ein aktueller Fedora-Server.
Das Kivitendo steckt in einem rootless Container und greift auf die Host-DB zu. Auf einem Rechner arbeitet dann ein Container, mit jeweils 4 Mandanten, die zeitversetzt mit bis zu einem Monat dann eine Kopie vom aktuellen Mandaten bekommt.
Dann gibt es noch eine Kopie, die als Fallback oder Kinderstube für neue Versionen herhalten soll.

Ich habe etwas getestet und folgendes herausfinden können:
- Alle Mandanten auf den beiden Knoten weisen denselben Fehler auf
- ein Aufspielen eines alten DB-Dump hilft gar nicht
- Ebenso erfolglos ist das Bauen eine neuen Containers auf der Basis einer aktuellen F40 Version
- Da die beien Container (auf den beiden Servern) nicht aktualsiert wurden, dürfte der Fehler außerhalb zu suchen sein
- Auf dem Container-Host habe ich einige rpm-Pakete ausgetauscht, obendrein wurde Postgres von 16.3-7 auf eine
ältere 11 abgesenkt, leider aich ohne Erfolg.

Es scheint -wie Sie vermutet haben-, ggf mit der PostgresDB und der Version 16 zu tun.

Lasen Sie ich wissen, falla ich auf irgendeine Weise (Test?) helfen könnte. (Testen von Änderungen).

Gruß
Christian

---

Hallo Jan,

die Fakturierung funktioniert auch mit dem SQL-Sript nicht. Bis auf weiteres muss ich händisch die
Rechnung generieren und hoffe mit einer Gutschrift dann die Zahlung einfließen zu lassen.

Um eine Klärung bzw eine Anbindung an Postgres 16 wäre mir sehr gelegen. Gerne probiere ich auf einem
Testsytem dann auch mögliche Korrekturvorschläge ein und lasse Dir das Ergebnis zukommne.

Gruß
Christian

---

Hi Christian,
kurzfristig kann ich da nicht helfen.
Meine erste Vermutung wäre auch eher, dass irgendwo etwas anderes klemmt und das die Postgres 16 Idee eher eine falsche Fährte ist. Aber wenn ich wetten würde, wäre das so eine 60:40 Vermutung.

Vielleicht beauftragst du Werner, dass er sich einmal per Fernwartung bei Dir aufschaltet.

Postgres 16 können wir uns mit Projekt-Ressourcen dann für die 3.9.1 anschauen, dass wäre so in 2 Monaten realistisch der Fall.

Gruß

---

Hallo Jan,

ok (fasst) kein Problem. Da mit der Postgres16 war so eine Idee von mir, da alles andere
in Stein gemeisselt ist (weil im Container).
Ich könnte man versuchsweise auf die 380 zurückmigrieren und dann versuchen eine Rechnung
zu erstellen, natürlich auf meiner Testumgebung.

Gruß
Christian

---

Hallo Jan,
Hallo Werner,

möglicherweise hängt mein Problem mit einer Änderung von Werner zusammen, die er vor 10 Monaten unter dem Arbeitstitel FIX: 'Buchen auf' in EK/VK Rechnungen richtig vorbelegen eingeführt hat.

enter link description here
Anstelle eines lapidaren split sehe ich nun einen Datenbank-Zugriff, der in meiner migrierten Umgebung wohl auf die Bretter geht, weil der FindBy kein Objekt liefert, aus dem ein accno ermittelt werden kann.

---

Hallo Jan,
Hallo Werner,

ich habe einmal in der Datei is.pl die Zeile 1197 wieder auskommentiert und die darauffolgenden Zeile einkommentiert, und schon funktioniert die Anwendung wieder!

So schaut es aus:

($form->{AR})        = split /--/, $form->{AR}; 
# $form->{AR}      = SL::DB::Manager::Chart->find_by( id => $form->{AR_chart_id} )->accno;

Wäre das Java Code, würde ich mir die Frage stellen, ob man sicher sein kann, dass die
DB Abfrage tatsächlich ein Ergebnis liefert. Ich bin kein Perl Experte aber hier wurde wohl eine
NULL-Ref dereferenziert.

1. Man könnte hier ggf einen if-Test auf null hinterlegen und dann als Fallback die alte Variante aufrufen und falls ein Objekt gefunden wird, die Korrektur vom Wener dann greifen lassen.
2. Die andere Frage ist, warum hat die Anwendung aus der DB kein Obkelt geliefert. Jan's Hinweis auf ein Script, das ggf noch aufzurufen war an sich nicht falsch. In der Default Tabelle war nach dem Einspielen eine id=17 hinterlegt und die Zeit in der Chart-Tabelle gefühlt auch in meiner DB auf den richtigen Zeileneintrag

is:17 accno:1200 description:Forderung ..

Soweit alles in Butter, als mögliche Erklärung käme mir noch in den Sinn, dass dem Finder ein fehlerhafter oder nicht initialisierter Wet zugewiesen wurde. Wenn ich helfen kann, dann meldet Euch bitte. Meine Mail--Adresse habt Ihr ja!

Gruß
Christian