Technisches Problem mit dem DATEV Export (Download-Archiv leer)

Question

Liebe Anwender und Entwickler,

ich habe vermutlich ein Konfig-Problem mit meinem Kivitendo. Wenn ich versuche ein
Datev-Export via Finanzbuchhaltung->Datevexportassistent initiiere, dann wird in dem
Verzeichnis die folgende Datei erp-users/datev-export-1581864824-719274-384/EXTF_DATEV_kivitendo_translit2019-12-01-2019-12-31.csv erstellt.

Auf der Folgeseite steht dann 'CSV-Export erfolgreich` und man drückt dann erwartungsvoll
Download, mit dem Ergebnis, dass man ein etwas kaputtes zip-Arch.

Nachfolgende Untersuchungen auf UNIX Ebene liefern ein seltsames Ergebnis:

$ file kivitendo-datev-export-20200216.zip
kivitendo-datev-export-20200216.zip: data

ok, eine zip-Datei mit entsprechender Signatur. Aber

$ unzip -t kivitendo-datev-export-20200216.zip
Archive:  kivitendo-datev-export-20200216.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
  unzip:  cannot find zipfile directory in one of kivitendo-datev-export-20200216.zip or
  kivitendo-datev-export-20200216.zip.zip, and cannot find kivitendo-datev-export-20200216.zip.ZIP, period.

Ok, die Datei scheint kaputt zu sein. Der Inhalt der 84-Bytes großen zip-Datei:

$ cat kivitendo-datev-export-20200216.zip && echo
P�{PPa6EXTF_DATEV_kivitendo_translit2020-01-01-2020-01-31.csv

schaut für mein Gefühl nach einem kaputten Stream aus, als wäre der Header des Archivs generiert worden zu sein, während die Archivierung und der damit erwartete Dateistrom aufgrund eines Fehlers nicht zustande kam und abgebrochen ist.

Gleichzeitig wurde in dem Verzeichnis /var/www/kivitendo-erp/users/datev-export-1581866955-33583-392
die Datei -rw-r--r--. 1 apache apache 1377 Feb 16 15:29 EXTF_DATEV_kivitendo_translit2020-01-01-2020-01-31.csv mit den entsprechenden Zugriffsrechten eingespielt.

Die Installation erfolgte nach Beschreibung auf einem Fefora-Linux (F31). Das zip Kommando ist verfügbar.
in der kivitento Umgebung fand sich aber keine zip-Datei. Vermutlich wird die von der Anwendung im Speicher erstellt.

Answer 1

Falls du die CRM benutzt führe mal ein git pull durch.

Was sagt denn die Fehlerkonsole des Browsers und des Webservers?
Welche ERP-Version benutzt du?

Comments

Hallo

es tut mir Leid, dass ich mich jetzt erst melde, ich bin noch mit anderen Dingen beschäftigt.
ich nutze die Version 3.5.4

Im Browser selber gibt es keinen Fehler, dieser liefert nur ein kaputtes Archiv. Das Problem ist im Anwendungsserver. Ich melde mich noch einmal später!

---

Hallo Ciatronical

ich bin seit heute von dem Release release-3.5.4 auf die release-3.5.5 umgestiegen.
Das Problem besteht weiterhin und in den Log-Dateien finde ich keinen Fehler!

Das Kivitendo läuft in einem podman-Container (verbesserter Ansatz zu docker). Der
Container ähnelt dabei einer Fedora F31 Installation (sogar ein systemd läuft darin).
Der Build der Umgebung und der Check von Kivitendo läuft ohne Probleme durch
und die Anwendung funktioniert auch ganz gut.

Das zu packende Verzeichnis auf dem Server findet sich auf unter dem /var/www/kivitendo-erp/users
Verzeichnis und ein zip Program existiert auf dem System (zip is hashed (/usr/bin/zip)).
Könnte es sein, dass das cgi-Gateway das zip nicht findet oder dass unter perl oder php eine Implementierung
des zip Kommandos erwartet wird, aber unter Fedora nicht installiert wurde?

---

Nein, kivitendo und das DATEV-Modul nutzen folgendes Perl-Modul zur Zip-Generierung:

use Archive::Zip qw(:ERROR_CODES :CONSTANTS);

Ich würde eher in eine andere Richtung überlegen, ggf. ist se_linux aktiviert und erlaubt für dieses Verzeichnis nur das Anlegen aber nicht das Erweitern der Datei?

Dann das offensichtlichere erstmal ausschließen, gibt es überhaupt Buchungsdatum im Export-Zeitraum?

Mit etwas Perl kannst Du die Stelle im Code einmal debuggen

bin/mozilla/datev.pl

sub download 
(...)

  open(IN, $tmp_name) || die("open $tmp_name");
  $::locale->with_raw_io(\*STDOUT, sub {
    print("Content-Type: application/zip\n");
    print("Content-Disposition: attachment; filename=\"${zip_name}\"\n\n");
    while (<IN>) {
      print($_);
    }
  });
  close(IN);

  unlink($tmp_name);
(..)

Das wäre ein simples Debug-Statement (error log apache2)

print(STDERR "hier bin ich" . $tmp_name);

---

Hallo Herr Büren,

herzlichen Dank für die zügigee Antwort.

1. in einem Container gibt es kein selinux. Dieses Verfahren greift nur außen am Container und den Volumes, die betroffenen Volumes sind aber explizit freigeschaltet. Auf dem spool-users konnte ja auch das Verzeichnis angelegt werden. Ggf gibt es aber ein Problem bei der Anlage der remoären zip-Datei.
   Stimmt es, dass diese zip unter dme /tmp Verzeichnis angelegt wird ?

2. Stimmt, und das passende rpm zu Archive::Zip wurde ich installiert.

3. Ein XLS export des Buchungsjournals funktioniert ohne Probleme, es muss mit dem zip zusammenhängen.

4. Ich melde mich noch

5. Vielen Dank!

---

Hi groovyman,
ich hab das Problem jetzt auch mit Ubuntu 20 LTS
Die Rechte für das globale /tmp Verzeichnis haben sich hier verändert.

Ergänz mal in bin/mozilla/datev.pl ungefähr Zeile 175:

-  $zip->writeToFileNamed($tmp_name);
+  if ($zip->writeToFileNamed($tmp_name) != AZ_OK) { die "Could not write Zip file, reason: $!" };

Das wirft dann in kivi eine Fehlermeldung, dass die Datei nicht erstellt werden kann.

Nutzt Deine Distribution Perl 5.30 oder höher?

Vgl.:

perl -v

This is perl 5, version 30, subversion 0 (v5.30.0)

Dann ist dies die wahrscheinlich Ursache:

https://github.com/perl/perl5/issues/16721

Fix sollte diese Woche im master sein.

LG

---

Hallo Herr Büren,

auf meinem Fedora F31 wird die perl-Version:

perl -v
This is perl 5, version 30, subversion 1 (v5.30.1) built for x86_64-linux-thread-multi
(with 62 registered patches, see perl -V for more detail)

ausgeliefert. Herzlichen Dank für die Info!

Gruß
Christian

---

Liebe Entwickler.

Da hätte ich noch einen kleiner Nachschlag meinerseits. Gibt es in perl oder php kein Pendant zu der clib Funktion tmpfile? Es sollte dem rufenden Prozeß ja Schnuppe sein, wie die Datei heißt. Diese muss nur auf Anfrage angelegt werden. Genau das garantiert ja tmpfile!

Gruß
Christian

---

Hi,
ja, in der Richtung hatten wir auch erst gesucht, ich bin der Meinung dass das Perl-Modul mit dieser Perl-Version und ggf. Kernel-Version eher buggy ist.

Das Generieren der tmpfiles und auch des Archivs ist hier das Problem.
Es scheint eher so zu sein, dass die Quelldateien für das ZIP-Archiv nicht gelesen werden können, obwohl die Dateireichte in Ordnung sind.

Du könntest zum Debuggen der Fehlermeldung mal diese Zeile in datev.pl tauschen:

-  $zip->writeToFileNamed($tmp_name);
+  if ($zip->writeToFileNamed($tmp_name) != AZ_OK) { die "Could not write Zip 

Ansonsten ist hier mein Workaround für die datev.pl:

- use Archive::Zip qw(:ERROR_CODES :CONSTANTS);
+ use IO::Compress::Zip qw(zip $ZipError);

sub download ...


+    zip \@filenames => $zip_name
+        or die "zip failed: $ZipError\n";
 
   chdir($cwd);
 
-  open(IN, $tmp_name) || die("open $tmp_name");
+  open(IN, $path . $zip_name) || die("open $path");
   $::locale->with_raw_io(\*STDOUT, sub {

---

'Wirft Dein GoBD-Export auch Fehler?
Der befindet sich im selben Menü ...

---

Hallo Herr Büren,

ich werde mich am WE um das Thema kümmern, da bei meinem Kunden
derzeit der Pabst im Kettenhemd tanzt.
Ich melde mich über das Wochenende und bitte um Vertändnis.

Gruß
Christian

---

Hi,
ja, kein Problem.
Ein Bugfix ist fertig, aber noch nicht im Standard.

---

Hi,
im aktuellen master auf github ist der Bugfix hierfür drin.

Gruß

---

Hallo Herr Büren,

Ihre Änderung aus dem Master habe ich soeben in meinem Container übernommen
und sogleich funktionierte der Download.

Herzlichsten Dank für Ihre Mühe!
Christian Groove