Willkommen im kivitendo Forum! Hier erweitern und teilen AnwenderInnen und EntwicklerInnen ihr Wissen.

Teste kivitendo!

kivitendo Demo

kivitendo Demo mit Schweizer Kontenplan und neuem Layout

Unterstützt kivitendo mit der Basis-Subskription!

0 Punkte

Hallo,

nachdem ich nach lange zurück liegenden und gescheiterten Versuchen von Lx-Office 2.6.0 zu kivitendo umzusteigen noch eine Weile mit dem alten System gearbeitet hatte, habe ich nach dem neu Aufsetzen des Arbeitsrechners mit Ubuntu 22.04 LTS die Gelegenheit genutzt, um einen neuen Anlauf zu nehmen.

Die Installation war soweit erfolgreich. Da ich damals schon mal gescheitert bin, die alte Datenbank einzuspielen, hatte ich alles erst einmal mit einer frischen Datenbank ausprobiert.

Aktuelle Version: 3.7.0 / postgres 14
Alte Version: lx-office 2.60 / postgres 9.3

Um den Umstieg auf die Postgresql 14 zu erleichtern, wurden dem superuser, als auch den Benutzern die Passworte in postgres, wie auch kivitendo vergeben.

Erst nach der Installation und dem Anlegen von Benutzer und Mandant und einem erst Probieren, habe ich die Datenbank aus einer Sicherung ( alle-datenbanken.dump) eingespielt.

Nach dem Benutzer Login sollte die Datenbank aktualisiert werden. Also erst die Datenbank mit user und PAsswort eingetragen, nach "weiter" den superuser mit passwort eingetragen.

Dann kam diese rot unterlegte Fehlermeldung:

The database update/creation did not succeed. The file sql/Pg-upgrade2/warehouse3.sql containing the following query failed:
UPDATE parts SET onhand = COALESCE((SELECT SUM(qty) FROM inventory WHERE inventory.parts_id = parts.id), 0)
The error message was: ERROR: record "new" has no field "bin_id"
CONTEXT: SQL expression "NEW.bin_id IS NULL AND NEW.warehouse_id IS NULL"
PL/pgSQL function check_bin_belongs_to_wh() line 2 at IF
All changes in that file have been reverted.:

Und ab da ging es nicht weiter. Ich habe noch einiges anderes probiert. Auch erst die Datenbank anzulegen und danach die Daten einzufügen, aber das ist bereits im Ansatz gescheitert.

Auch habe ich versucht per

pg_dump -U -h > exported_data.sql

die Daten zu sichern und in eine bestehende Datenbank einzuspielen. Zumindest wurden die Tabellen angelegt, nur Kivitendo gibt die Daten nicht aus. Es ist, als ob keinerlei Daten existieren.

Vermutlich weil in lx-office es ja nur den Benutzer gibt und in Kivitendo der Mandant noch "zwischen geschaltet" ist und hier irgendwo der Link fehlt.

Wie auch immer: Kennt jemand eine Möglichkeit die Daten irgendwie in Kivitendo einzupflegen. Gibt es eine Möglichkeit, den Fehler "händisch" zu beheben?

Die Fehlermeldung verstehe ich auch nicht wirklich.

von (390 Punkte)

4 Antworten

+1 Punkt

Hallo
das sieht eher nach einem schwerwiegenden Problem mit der Datenbank aus.

  • Ist das Datenbankbackup komplett sind dort die Daten drinne. .sql ist
    eine Textdatei und kann mit einem Editor geöffnet werden. Letzte Zeile sollte sowas wie --Database backup completed haben
  • Sind Daten zu sehen wenn Du dich über die SQL Konsole einloggst?

Ansonsten sollte es gehen ein Update von 2.6 auf 3.8 habe ich letztes Jahr erst gemacht.

Beste Grüße
Werner kivitendodienstleister

Unterstütze kivitendo mit einer Basis-Subcription

von (16.4k Punkte)

Danke schon mal für die Antwort.

Die letzten Zeilen der export_data.sql sind :

REVOKE ALL ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON SCHEMA public FROM postgres;
GRANT ALL ON SCHEMA public TO postgres;
GRANT ALL ON SCHEMA public TO PUBLIC;--

-- PostgreSQL database dump complete

Zumindest sind Tabellen und Sequenzen zu sehen, wenn ich mi \dt ; \dT in der Datenbank abfrage.

Im pgAdmin kann ich in den Statisken sehen, dass die aus dem "alle-datenbanken.dump" eingespielte 39,86 MB groß ist und die mit dem Inhalt der .sql Datei "gefüllte" 21,63 MB groß ist.

Also müssen zumindest erkleckliche Daten vorhanden sein.

Nebenbei habe ich ein reines Ein-Mann-Geschäft. Die Datenmenge beträgt also nur ein Bruchteil anderer Betriebe.

Auf einem anderen System läuft die alte 2.6.0 Version immer noch. Solange das Neue nicht läuft, bleibt es dabei. Probleme mit de rDatenbank habe ich dort allerdings nicht.

Neuer Tag und neuer Versuch:

Was ich noch nicht gemacht hatte ist, einen einzelnen -dump der Datenbank zu machen und den einzuspielen. Das habe ich mit hilfe eines anderen Befehls und der .sql datei gemacht.

Jetzt also mit einem.dump das Gleiche:

Die Datenbank gelöscht und in kivitendo neu erstellt, also so, dass auch lgeich Tabellen angelegt werden und den .dump eingespielt: Es pasiert das Gleiche, wie vorher mit der sql. Datei:

Die Daten kommen zwar an - ob alle, kann ich nicht sehen - werden aber in kivitendo nicht angezeigt. Lediglich meine Kundengruppen waren zu sehen, der Rest nicht.

Die Datenbank gelöscht und versucht im Ganzen einzuspielen, was mangels der Datenbank und dem nicht zugewiesenen Benutzer scheiterte.

Also Datenbank in postgres angelegt und wieder eingespielt.

Beim Aufrufen des Mandanten will kivitendo dann wieder die Datenbank aktualisieren - was es in den Fällen, in denen ich die Datenbank in Kivitendo erstellt habe, nicht gemacht wurde. Die Option gab es auch nicht.

Und dann kam wieder die gleiche Fehlermeldung wie oben.

Während des restores kam allerdings auch eine ganze Reihe Meldungen:

pg_restore: warning: restoring tables WITH OIDS is not supported anymore

Diese kam über 50 mal. Und zuletzt:

g_restore: while PROCESSING TOC: pg_restore: from TOC entry 8; 2615
2200 SCHEMA public postgres pg_restore: error: could not execute
query: ERROR: schema "public" already exists Command was: CREATE
SCHEMA public;

pg_restore: warning: errors ignored on restore: 1

Diese OID scheinen ein Problem darzustellen. Dazu muss gesagt werden, dass meine Datenbank schon seit 2010 existiert.

Aber andere Frage: Wenn Du schon von 2.6.0 auf 3.8.0 gemacht hast, wie bist du da vorgegangen beim Einspielten der alten Datenbank? Gab es ein ähnliches Problem?

+1 Punkt

Hallo,

stimmen die Nutzer(Eigentümer | Kodierung | Zeichentyp) von alter und die Einstellungen der neuen kivitendo Installation überein?

Liste der Datenbanken mal überprüfen.

sudo -u postgres psql -l 

War zumindest bei mir das Hauptproblem bei einer Datenübernahme.

VG
Gerd

von (2.0k Punkte)

Hallo und Danke für die Antwort,

Diese Dinge passen aber. Das ist also nicht das Problem.

Gerade die "Kleinigkeiten" werden schon mal vergessen, das kenne ich auch.

+1 Punkt

Hallo,

Erst nach der Installation und dem Anlegen von Benutzer und Mandant und einem erst Probieren, habe ich die
Datenbank aus einer Sicherung ( alle-datenbanken.dump) eingespielt.

Hast du die Sicherung einfach in die bestehende 3.7.0 drüber gebügelt ?

  • probier mal nur die Mandanten Tabelle zu sichern ( nicht die kivitendo_auth )

  • in 3.7.0 nach deinem ersten Probieren die kivitendo_auth belassen

  1. die Mandanten Datenbank löschen (falls angelegt)
  2. die Mandanten Datenbank neu anlegen
  3. die Daten aus der Sicherung in die Mandantentabelle zurück lesen
  4. in kivitendo einloggen und die Datenbank mit einem Nutzer verbinden
  5. als Nutzer einloggen

VG
Gerd

von (2.0k Punkte)

Genau das hatte ich gemacht: "Drüber gebügelt". Und die anderen Versuche hatte ich ja beschrieben.

Okay:

Aber jetzt habe ich ein Verständnis-Problem: Lx-Offive kannte ja kein Mandanten, nur den Benutzer.

Die Tabelle oder die Datenbank? Letztere ist ja sozusagen die Datenbank, die meinen gesamten Datenstamm enthält.

Im Prinzip habe ich da ja nur:

Template1 als Vorlage
die lxoffice_auth, bzw die kivitendo_auth
die eigentliche Datenbank des Benutzers in lxoffice, bzw. des Mandanten in Kivitendo.

versuch mal die Datenbank des Benutzers in lxoffice zu sichern und in die neue anzulegende Datenbanktabelle des Mandanten in Kivitendo einzuspielen.

zu Punkt 2
Datenbank nicht im kivitendo anlegen sondern direkt mit postgres

postgres@host:~$ createdb --encoding=UTF8 --owner=kivitendo -U postgres "neuer datenbankname"

zu Punkt 3 - Daten einlesen

postgres@host:~$ psql -U postgres "neue datenbank" < "gesicherte lx-office.sql" 

danach Punkt 4 ( und 5)

Die neue Tabelle in kivitendo mittels Neuer Mandat -- Mandantenname eingeben -- Datenbank zuordnen
( Datenbankbenutzer und -passwort beachten) --> Datenbankverbindung testen --> Benutzer für Mandantenzugriff zuordnen.

Sorry, aber ich stehe immer noch ein wenig "auf dem Schlauch".

Meinst Du:

Datenbank des Mandanten löschen? Habe ich!

Neue Datenbank anlegen - in Kivitendo? Habe ich! Die hat jetzt auch 138 Tabellen.

Soll ich jetzt wirklich die Sicherung in die Mandanten-Tabelle einspielen, das wäre wahrscheinlich die "employee", oder?

Oder soll ich schlicht in die jetzt angelegte Datenbank für den Mandanten, die aber noch nicht mit dem Selben verknüpft ist, die Sicherung einspielen?

Hallo
kivitendo bzw lx-office war schon fast immer Mandantenfähig nur die hat sich deutlich verbessert mit Version 3.0 (Bin aber aber nicht ganz 100% sicher)
Du müsstest eine lx_auth datenbank haben
und eine oder mehere Mandantendatenbanken

   -> sudo -
   -> su - posgres
   -> psql
    postgres=# \l

Müsste dir alle datenbanken zeigen Bei mir sieht es so aus
postgres=# \l

                                      List of databases
           Name        |   Owner   | Encoding |   Collate   |    Ctype    |   Access privileges   
    -------------------+-----------+----------+-------------+-------------+-----------------------
     demo_nov23        | kivitendo | UTF8     | de_DE.UTF-8 | de_DE.UTF-8 | 
     demo_okt23        | kivitendo | UTF8     | de_DE.UTF-8 | de_DE.UTF-8 | 
     demo_sep_23       | kivitendo | UTF8     | de_DE.UTF-8 | de_DE.UTF-8 | 
     demo_skr03        | kivitendo | UTF8     | de_DE.UTF-8 | de_DE.UTF-8 | 
     kivitendo_auth    | kivitendo | UTF8     | de_DE.UTF-8 | de_DE.UTF-8 | 
     template0         | postgres  | UTF8     | de_DE.UTF-8 | de_DE.UTF-8 | =c/postgres          +
                       |           |          |             |             | postgres=CTc/postgres
     template1         | postgres  | UTF8     | de_DE.UTF-8 | de_DE.UTF-8 | =c/postgres          +
                       |           |          |             |             | postgres=CTc/postgres
     testing           | postgres  | UTF8     | de_DE.UTF-8 | de_DE.UTF-8 | 
     viso              | kivitendo | UTF8     | de_DE.UTF-8 | de_DE.UTF-8 | 

(25 rows)

Wie sieht das bei Dir aus?
Beste Grüße
Werner kivitendodienstleister

Unterstütze kivitendo mit einer Basis-Subcription

Bei mir sieht das so aus:

      Name            |   Owner   | Encoding |   Collate          |    Ctype    |   Access privileges   

----------------+-----------+----------+-------------+-------------+-----------------------
buch | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 |
buch2 | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 |
buch3 | kivitendo | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 |
buch4 | lxoffice | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 |
geschaeftsbuch | lxoffice | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 |
kivitendo_auth | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 |
lxerp_auth | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 |
postgres | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 |
template0 | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 | =c/postgres +

            |               |          |             |                                                            | postgres=CTc/postgres

template1 | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 | postgres=CTc/postgres+

            |               |          |             |                                                            | =c/postgres

Zur Erklärung:

lxerp_auth ist die alte Authentifizierungs-DB aus lx-office und hat für kivitendo keine Bedeutung. Die DB geschaeftsbuch ist die DB, um die es geht.

Die anderen, die "buch" heißen, sind lediglich "Hilfsdatenbanken", die ich angelegt hatte, um sie Mandanten zuzuweisen und haben ebenfalls keine Bedeutung.

Was mir noch aufgefallen ist: Dem Benutzer habe ich in kivitendo den gleichen Namen, wie in lx-office gegeben, aber dem Mandanten einen aderen.

Das sind jetzt die Datenbanken auf dem neuem Server?

Ja!

Hallo,
Was liefert den

   -> sudo -
   -> su - posgres
   -> psql
    postgres=# \du

Das hier:

                               List of roles

Role name | Attributes | Member of
-----------+------------------------------------------------------------+-----------
kivitendo | Create DB | {}
lxoffice | Create DB | {}
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

Das sieht auch so aus, wie sein soll, meine ich.

Was ich heute noch versucht hatte:

Dem Mandanten den selben Namen gegeben, wie dem Benutzer. Nur um das auch auszuschließen.

Jeweils die Datenbank wieder gelöscht und:

Datenbank in Kivitendo angelegt -> kivitendo geschlossen -> in die Datenbank aus dem dump die daten eingespielt -> in Kivitendo dem Mandanten die Datenbank zugeordnet - Benutzer / Mandant eingeloggt.

Keine Datenbankaktualisierung! Die kommt einfach nicht. Und keine Daten abrufbar, bis auf einige Einstellungen.

Das Selbe habe ich noch mal mit einer Einspielung aus der .sql Datei versucht.

Dann: Datenbank per postgres angelegt, .sql eingespielt und mit Mandanten in Kivitendo aufgerufen -> Datenbankaktualisierung -> Fehlermeldung.

Es ist offensichtlich, dass, wenn Kivitendo bereits Tabellen in der Datenbank anlegt, nur ein Teil der Daten überhaupt eingespielt werden. Jedenfalls erhalte ich jede Menge Fehlermeldungen in dem Fall.

Das Einspielen in eine leere Datenbank dagegen scheint gut zu funktionieren, ob aus dem dump oder aus .sql. Nur dann hakt es mit der Datenbankaktualisierung.

Hallo,

Dann: Datenbank per postgres angelegt, .sql eingespielt und mit Mandanten in Kivitendo aufgerufen ->
Datenbankaktualisierung -> Fehlermeldung.

Kannst du in den Fehlermeldungen etwas erkennen was da schief geht ?

Bei mir waren es z.B.: eigene angelegte Steuersätze die eine Aktualisierung fehl schlagen ließen.

Eventuell könnten es auch Einheiten sein. (mal geraten)

Diese in der .sql gelöscht und es ging.

Schau auch mal in der .sql was in der Variablen "Owner: ...." steht.
Gegebenenfalls ist dieses passend zu ersetzen.

VG Gerd

Den Fehler hatte ich ja schon weiter oben gepostet:

The database update/creation did not succeed. The file sql/Pg-upgrade2/warehouse3.sql containing the following query failed:
UPDATE parts SET onhand = COALESCE((SELECT SUM(qty) FROM inventory WHERE inventory.parts_id = parts.id), 0)
The error message was: ERROR: record "new" has no field "bin_id"
CONTEXT: SQL expression "NEW.bin_id IS NULL AND NEW.warehouse_id IS NULL"
PL/pgSQL function check_bin_belongs_to_wh() line 2 at IF
All changes in that file have been reverted.:

Und in der .sql dürfte das der passende Abschnitt sein:

-- Name: check_bin_belongs_to_wh(); Type: FUNCTION; Schema: public; Owner: lxoffice

CREATE FUNCTION public.check_bin_belongs_to_wh() RETURNS trigger

LANGUAGE plpgsql
AS $$BEGIN
    IF NEW.bin_id IS NULL AND NEW.warehouse_id IS NULL THEN
      RETURN NEW;
    END IF;
    IF NEW.bin_id IN (SELECT id FROM bin WHERE warehouse_id = NEW.warehouse_id) THEN
      RETURN NEW;
    ELSE
      RAISE EXCEPTION 'bin (id=%) does not belong to warehouse (id=%).', NEW.bin_id, NEW.warehouse_id;
      RETURN NULL;
    END IF;
  END;$$;

ALTER FUNCTION public.check_bin_belongs_to_wh() OWNER TO lxoffice;

Mal sehen, was ich damit mache.....

Hallo,

die Owner:... der eingelesenen *.sql sollten schon mit dem Eigentümer der Datenbanktabelle im neuen Kivitendo übereinstimmen. Zugriffsrechte müssen stimmen sonst kein korrekter Zugriff auf die Datenbank.

Ich würde ja einfach mal in der *.sql alle Ownereinträge "lxoffice" durch kivitendo ersetzen.

VG Gerd

Also das wird es nicht sein, da ich neben dem superuser ohnehin noch die User kivitendo, wie auch lxoffice angelegt hatte und die entsprechende Datenbank auch lxoffice zugeordnet hatte.

Und es geht sehr holperig weiter:

Zunächst habe ich in der sql.-sicherung den obigen Teil, der offensichtlich Probleme macht, auskommentiert. Danach wieder in eine leere Datenbank eingespielt und die Datenbankaktualisierung gemacht.

Dieser Fehler trat dann nicht mehr auf, aber ein paar ungewöhnliche Dinge:

Einmal wurde aufgefordert, dass doppelt vergebene Artikelnummern geändert werden. Kein Problem soweit, aber das System mag es offenbar nicht, wenn nicht alle monierten Artikel in einem geändert werden. In dem Fall geht es zurück und aller Artikel dürfen noch einmal geändert werden. Nach ein paar Anläufen ist auch dies Hürde genommen.

Der nächste Schritt war eine Zuweisung von Artikel zu einer Kategorie und einem Lagerplatz. Auch das ging nach zwei Anläufen.

Dafür gibt es jetzt wieder eine ziemlich dicke Fehlermeldung:
Nachdem:

Führe konjunkturpaket_2020.sql aus: Anpassung der Steuersätze für 16%/5% für Deutsche DATEV-Kontenrahmen SKR03 und SKR04

Erscheint dieses:

The database update/creation did not succeed. The file sql/Pg-upgrade2/konjunkturpaket_2020.sql containing the following query failed:

Und listet das gesamte script auf.

Am Ende steht dann dieser Fehlerbericht:

The error message was: ERROR: duplicate key value violates unique constraint "taxkeys_chartid_startdate"
DETAIL: Key (chart_id, startdate)=(6, 01.07.2020) already exists.
CONTEXT: SQL statement "insert into taxkeys (chart_id, tax_id, taxkey_id, pos_ustva, startdate )

             values (_chart_id,
                     (select id from tax where taxkey = current_taxkey.taxkey and rate = _new_rate::numeric),
                     current_taxkey.taxkey, -- 2, 3, 8, 9
                     current_taxkey.pos_ustva, '2020-07-01')"

PL/pgSQL function inline_code_block line 180 at SQL statement
All changes in that file have been reverted.:

Ich habe es mir noch nicht richtig angesehen und weiß noch nicht, wo der Haken ist. Aber ich kann mir vorstellen, dass das schon anderen vorgekommen ist.

Hallo zusammen,

ein kivitendo-Dienstleister könnte Euch helfen, ansonsten habe ich vor vier Jahren diesen Hinweis in die UPGRADE-Datei hinzugefügt:

https://github.com/kivitendo/kivitendo-erp/commit/ecefbf9abb0a7638241e51b1902b2f830850ce56

Des Weiteren:

Das Deaktivieren der Constraints zur Überwachung von verwaisten Lagerplätzen würde ich auch nicht empfehlen, bei den meisten DB-Änderungen haben sich die Entwickler etwas dabei gedacht. Ich würde eher prüfen, warum die Constraints fehlschlägt und dann gezielt die verwaisten Lagerplätze entfernen.

Es hat gedauert, aber die Datenbankaktualisierung ist endlich durch!

Bis dahin war es aber noch einmal sehr holprig und ich kann mir vorstellen, dass die Arbeit noch längst nicht getan ist. Aber ich kann das System benutzen und es scheinen auch alle Daten da zu sein.

Was kam nach meinem letzten Post?

In der Tat hatte ich 2020 in lx-office natürlich die Steuer geändert, was sich nun mit dem release natürlich beißt.

Ich habe den Tip von @jbueren befolgt und habe die sql scripts der sql/Pg-upgrade2/konjunkturpaket_2020* sozusagen auf "ignore" gesetzt.

ed -i 's/ignore: 0/ignore: 1/g' sql/Pg-upgrade2/konjunkturpaket_2020*

Natürlich mit meinen vollständigen Pfaden und mit "sudo" vorangesetzt, also mit root-Rechten.

Es sind insgesamt fünf, nicht drei, da für jeden Kontenrahmen je noch einmal ein Korrektur-script hinzu kam.

Das hatte alerdings wieder Fehlermeldungen zur Folge: Zuerst wurden fehlende Abhängigkeiten von je dem release_3_5_6.sql und release_3_5_6_1.sql bemängelt.

Zuerst hatte ich auch diese mit -- ignore: 1 versehen. Dann aber traten wieder andere Abhängikeitsfehler auf den Plan und zwar jedes Mal aufs neue. Es werden so einige sein.

Also habe ich -- ignore: 1 wieder gelöscht und statt dessen, die Abhängigkeit zu den konjunkturpaket_2020. - scripten auskommentiert. In beiden releases. Damit dürfen m.E. alle anderen scripte gerne eine "Verbindung" zu den release-scripten haben, nur ab da, geht es nicht weiter.

Das ging gut, bis zuletzt doch noch eine andere Abhängikeit moniert wurde. Diesmal das script sql/release_3_5_7.sql

-- @tag: release_3_5_7
-- @description: Leeres Script, das alle Upgradescripte bis zum Release 3.5.7 voraussetzt, um ein fest definiertes Schema zu definieren.
'-- @depends: release_3_5_6_1 record_links_dunning_post_delete_trigger customer_vendor_routing_id dunning_original_invoice_printed tax_point2 custom_variables_add_edit_position defaults_req_delivery_date add_transfer_doc_interval defaults_delivery_orders_check_stocked cvars_remove_duplicate_entries time_recordings_articles record_template_payment_id defaults_customer_vendor_ustid_taxnummer_unique shop_4 defaults_posting_records_default_false add_gl_imported file_storage_project customer_vendor_add_postal_invoice file_storage_dunning_documents time_recordings_remove_type orderitems_optional time_recordings_add_order defaults_transfer_settings'

Auch hier habe ich die Abhängikeit auskommentiert.

Der Übersicht halber mache ich so etwas am liebsten direkt in den scripten mit einem Editor und mit Root-Rechten ( sudo nautilus).

Nun lief die Aktualisierung zu Ende.

Bevor ich diesen Faden als gelöst markiere will ich noch einiges ausprobieren.

Es kann natürlich sein, dass bei dem einen oder anderen der Helfer hier die Alarmglocken schrillen!!! Weil ich zwar meiner Meinung nach relativ logisch vorgegangen bin, was nun alles andere als richtig sein muß.

Wenn dem so ist, lasst es mich gerne wissen.

Ach ja: Vielen Dank schon mal für jeden Beitrag hier. Weiter geholfen hat wirklich alles.

0 Punkte

Diese Frage habe ich neu gestellt:

https://forum.kivitendo.de/6200/rechnungen-in-kivitendo-können-nicht-gebucht-werden

Und sie ist auch bereits gelöst.

von (390 Punkte)
Bearbeitet von

Ähnliche Fragen

0 Punkte
0 Antworten
Gefragt 7, Jan 2016 von kbroszat (260 Punkte)
0 Punkte
2 Antworten
0 Punkte
3 Antworten
Gefragt 24, Jul 2012 von Anonym
0 Punkte
1 Antwort
Gefragt 15, Mai 2019 von kbroszat (260 Punkte)
0 Punkte
1 Antwort
Gefragt 12, Mär 2014 von Anonym
...