Erstellung eines Auftrags funktioniert nach Update 3.6 auf 3.9 nicht

Question

Hallo,

wir haben das System, aktuell in einer parallelen TestInstallation, bis auf 3.9 aktualisiert und bereits wie hier besprochen einiges korrigiert. Jetzt haben wir ein anderes Problem aufgedeckt. Sobald ich im Menu "Verkauf -> Angebot erfassen" klicke, bekomme ich den Fehler:

do_transaction() failed - DBD::Pg::st execute failed: FEHLER:  Spalte »quotation« existiert nicht
LINE 2:                         WHERE (quotation = '1') AND customer...
                                   ^ at /var/www/kivitendo-prod/SL/DBUtils.pm line 150.

Beim Update hat das System von keinen Fehlern mitgeteilt und in der 3.6 hat die Funktion normal gearbeitet. Ich habe die alte Datenbank angeschaut -- da sieht man die Spalte oe.quotation, in der aktualisierten DB aber nicht mehr. Und wie auf dem Link oben erwähnt, ist das richtig so, weil der Update-Skript oe.quotation löschen soll. Wieso möchte das Skript doch auf die Tabelle zugreifen?

rreimche@Neuer-Server:/var/www/kivitendo-prod$ cat VERSION
3.9.0

BG
Roman

Answer 1

Hallo Roman,
Ich kann den Fehler nicht nachstellen, daher erstmal

• Apache neustarten
• Browsercache löschen

Beste Grüße
Werner kivitendodienstleister

Unterstütze kivitendo mit einer Basis-Subcription

Comments

Hallo Werner,

danke für die Infos. Die 2 Empfehlungen haben leider nichts geändert. Aber das soll an Skriptdateien liegen, denke ich.

Ich habe in einem neuen Folder die Repo geclont, release-3.9.0 ausgecheckt und probiert -- das Ergebnis war gleich.

Beste Grüße
Roman

---

root@Produktiv-Server:/var/www/kivitendo-prod# grep -rnw "quotation ="
grep: .git/objects/pack/pack-1da1cfaeabf19ee2715687d78e8f2c9c6cf1cdd8.pack: Übereinstimmungen in Binärdatei
sql/Pg-upgrade2/order_type.sql:17:  WHERE customer_id IS NOT NULL and (quotation = FALSE or quotation is null) and intake = FALSE;
sql/Pg-upgrade2/order_type.sql:19:  WHERE vendor_id   IS NOT NULL and (quotation = FALSE or quotation is null) and intake = FALSE;
sql/Pg-upgrade2/order_type.sql:22:  WHERE customer_id IS NOT NULL and quotation = TRUE and intake = FALSE;
sql/Pg-upgrade2/order_type.sql:24:  WHERE vendor_id   IS NOT NULL and quotation = TRUE and intake = FALSE;
sql/Pg-upgrade2/order_type.sql:27:  WHERE customer_id IS NOT NULL and (quotation = FALSE or quotation is null) and intake = TRUE;
sql/Pg-upgrade2/order_type.sql:29:  WHERE vendor_id   IS NOT NULL and quotation = TRUE and intake = TRUE;
SL/Form.pm:2701:    $where = "quotation = '0'";
SL/Form.pm:2705:    $where = "quotation = '1'";
SL/Controller/ImageUpload.pm:20:  sales_order     => [ "SL::DB::Order", [ sales => 1, quotation => 0 ] ],
SL/Controller/ImageUpload.pm:21:  sales_quotation => [ "SL::DB::Order", [ sales => 1, quotation => 1 ] ],
SL/Controller/ImageUpload.pm:22:  purchase_order  => [ "SL::DB::Order", [ sales => 0, quotation => 1 ] ],
SL/OE.pm:888:  my $quotation = $form->{type} =~ /_order$/ ? 'f' : 't';
SL/OE.pm:896:         delivered = ?, proforma = ?, quotation = ?, department_id = ?, language_id = ?,
SL/Presenter.pm:156:  my $quotation = SL::DB::Manager::Order->get_first(

Ich sehe die folgende Stelle im Code auf nah zu SL/Form.pm:2701:

if ($self->{type} =~ /delivery_order/) {
  $arap  = 'delivery_orders';
  delete $column_map{"cu.currency"};

} elsif ($self->{type} =~ /_order/) {
  $arap  = 'oe';
  $where = "quotation = '0'";

} elsif ($self->{type} =~ /_quotation/) {
  $arap  = 'oe';
  $where = "quotation = '1'";

} elsif ($table eq 'customer') {
  $arap  = 'ar';

} else {
  $arap  = 'ap';

}

$where           = "($where) AND" if ($where);
my $query        = qq|SELECT MAX(id) FROM $arap
                    WHERE $where ${table}_id > 0|;

Scheint so zu sein, dass im Falle vom Angebot das System oe.quotation in WHERE verwenden soll, das ist in 3.9.0. Wobei mir fehlt hier " AND customer" aus dem Fehlertext.

---

Hallo Roman,
ändere folgendes in der Mandantenkonfiguration:

System -> Mandantenkonfiguration -> Features -> Experimentelle Features: Auftragscontroller: Ja

Der Auftragscontroller ist mittlerweile nicht mehr experimentell, sondern stabiler als der bisherige Controller, da der zumindestens bei unseren Kunden kaum in Benutzung ist und beim nächsten Release mal rausfliegen müsste ...

Gruß

Jan

---

Hallo Jan,

vielen Dank für die Hilfe, aber der Vorschlag hat leider den folgenden Fehler ausgelöst und neuer Auftagscontroller wurde nicht aktiviert:

Can't locate object method "invoice_prevent_browser_back" via package "SL::DB::Default" at /usr/share/perl5/Rose/DB/Object.pm line 1657.

Rose::DB::Object::AUTOLOAD(SL::DB::Default=HASH(0x559e49b42ce8), 0) called at /var/www/kivitendo-prod/SL/DB/Object.pm line 95
SL::DB::Object::_assign_attributes(SL::DB::Default=HASH(0x559e49b42ce8), "bin_id_ignore_onhand", undef, "workflow_po_ap_chart_id", "", "order_warn_no_deliverydate", 1, "signature", ...) called at /var/www/kivitendo-prod/SL/DB/Object.pm line 71
SL::DB::Object::assign_attributes(SL::DB::Default=HASH(0x559e49b42ce8), "vendornumber", 276, "parts_show_image", 1, "fxloss_accno_id", 15, "allow_sales_invoice_from_sales_order", ...) called at /var/www/kivitendo-prod/SL/Controller/ClientConfig.pm line 58
SL::Controller::ClientConfig::action_save(SL::Controller::ClientConfig=HASH(0x559e496f5a80)) called at /var/www/kivitendo-prod/SL/Controller/Base.pm line 278
SL::Controller::Base::_run_action(SL::Controller::ClientConfig=HASH(0x559e496f5a80), "save") called at /var/www/kivitendo-prod/SL/Dispatcher.pm line 222
SL::Dispatcher::_run_controller("ClientConfig", "save") called at /var/www/kivitendo-prod/SL/Dispatcher.pm line 315
eval {...} called at /var/www/kivitendo-prod/SL/Dispatcher.pm line 322
SL::Dispatcher::handle_request(SL::Dispatcher=HASH(0x559e3fff3670)) called at /var/www/kivitendo-prod/dispatcher.pl line 16

Das ist wahrscheinlich nicht relevant, aber installation_check.pl zeigt alles grün. Ich wäre für weitere Empfehlung dankbar.

Grüße
Roman

---

Hi Roman,
da hab ich jetzt keine Idee mehr dazu.

Webserver durchgestartet? Sind alle DB-Upgrade-Skript in dem Mandanten eingespielt?

Ansonsten bitte bspw. Werner um Support per Fernwartung.

Gruß

---

Kurze Info meinerseits.
Haben eben selbst von 3.6.x auf 3.9 upgedated und auch den oben geannten SQL Fehler gehabt.
Nach aktivieren des neuen Auftragscontrollers schaut es aber nun gut aus.