LX Connect herunterladen

Neue Funktionen in der Schreib-Schnittstelle.

• Lieferanten anlegen: POST /api/Lieferant legt einen Lieferanten mit Bestellanschrift an und auf Wunsch in einem Aufruf auch Lieferanschrift, Bankverbindung, Freifelder und Kontaktpersonen. Die Antwort (201) enthält die Kennung des Lieferanten; eine transaktionId schützt vor doppelter Anlage. Scheitert nach der Anlage einer der weiteren Schritte, bleibt der Lieferant bestehen, und die Antwort 422 nennt seine Kennung und die bereits erledigten Schritte. Gelesen wird wie bisher über OData (Lieferanten, LieferantKontaktpersonen, Kontaktpersonen).
• Lieferanten pflegen: PUT /api/Lieferant/{id} ändert Matchcode, Lieferantennummer, Zahlungsart, Einzugsermächtigung und das Kennzeichen „inaktiv”; PUT …/bestellanschrift, PUT …/bankverbindung und PUT …/freifelder ändern die jeweiligen Angaben. POST …/lieferanschrift legt eine Lieferanschrift an, PUT …/lieferanschrift ändert sie und legt sie an, falls noch keine besteht. POST …/kontaktpersonen und PUT …/kontaktpersonen/{kontaktpersonId} legen Kontaktpersonen an bzw. ändern sie. Alle Änderungen betreffen nur die mitgeschickten Felder.
• Kreditorenkonto bei der Lieferantenanlage: POST /api/Lieferant legt standardmäßig ein Kreditorenkonto mit an (kreditorkontoAnlegen, Standard true). Ohne Angabe eines Kontos erhält es die Lieferantennummer als Kontonummer — bei lieferantenNr: AUTO die nächste Nummer des Lieferanten-Nummernkreises. Über kreditorenkonto lässt sich stattdessen ein vorhandenes Konto zuordnen oder ein Konto mit eigener Nummer anlegen. Existiert das Konto zur Lieferantennummer bereits, wird die Anlage abgelehnt. Das Konto lässt sich nur bei der Anlage festlegen; eine spätere Änderung der Lieferantennummer lässt es unverändert.
• Bestellanschrift heißt beim Lesen Rechnungsanschrift: Die Anschrift, die beim Schreiben bestellanschrift heißt, steht in OData in den Feldern Lieferanten.Rechnungsanschrift… — es sind dieselben Daten.
• Inaktiv gilt für den ganzen Lieferanten: Das Kennzeichen inaktiv wird an den Stammdaten gesetzt (POST und PUT /api/Lieferant), nicht an einer Anschrift, und stellt den gesamten Lieferanten inaktiv.
• Kennung der Kontaktperson: In …/kontaktpersonen/{kontaktpersonId} gehört der Wert KontaktpersonId aus LieferantKontaktpersonen — nicht deren Id, die die Zuordnung selbst bezeichnet.
• Tags an Kunden und Lieferanten: PUT /api/Kunde/{id}/tags/{tagId} bzw. PUT /api/Lieferant/{id}/tags/{tagId} ordnet einen Tag zu, DELETE auf derselben Adresse entfernt ihn wieder. Beide Aufrufe kommen ohne Rumpf aus, antworten mit 204 und sind wiederholbar: Ein bereits zugeordneter Tag wird nicht doppelt zugeordnet, das Entfernen eines nicht zugeordneten Tags ist kein Fehler. Existiert der Kunde, der Lieferant oder der Tag nicht, antwortet die Schnittstelle mit 400. Die vorhandenen Tags und ihre Zuordnungen sind wie bisher über OData lesbar (Tags, TagZuordnungen). Neue Tags legt POST /api/Tag an (s. u.).
• Lagerbuchungen: POST /api/Artikel/{id}/lagerbuchungen bucht einen manuellen Zugang oder Abgang eines Lagerartikels in einem Lager; das Vorzeichen der menge gibt die Richtung an (positiv = Zugang, negativ = Abgang). Die Antwort (201) nennt den neuen Bestand. Die beschreibung (höchstens 80 Zeichen) erscheint in Lexware als „Manueller Zugang: ” bzw. „Manueller Abgang: ”. Eine transaktionId schützt vor doppelter Buchung.
• Lagerbuchungen mit Chargen und Seriennummern: POST …/lagerbuchungen/chargennummern bucht Zugänge auf neue oder bestehende Chargen oder Abgänge von Chargen, POST …/lagerbuchungen/seriennummern Zugänge neuer oder Abgänge bestehender Seriennummern. Ein Aufruf enthält entweder zugaenge oder abgaenge und wird ganz oder gar nicht gebucht. Die Antwort nennt den neuen Bestand und die Liste aller Chargen bzw. Seriennummern des Artikels in diesem Lager mit ihrer Kennung; neue Nummern findet man darin über ihren Namen. Gelesen werden Buchungen, Bestände und Nummern über OData (Lagerbuchungen, Lagerbestaende, SerienChargenNummern, LagerbuchungSerienChargenNummern).
• Tags an Artikeln: PUT /api/Artikel/{id}/tags/{tagId} ordnet einen Tag zu, DELETE entfernt ihn — wie bei Kunden und Lieferanten ohne Rumpf, mit 204 und wiederholbar.
• Warengruppen anlegen: POST /api/Warengruppe legt eine Warengruppe mit Bezeichnung, Kurzbezeichnung und optional übergeordneter Warengruppe an. Ohne Angabe von konten erhält sie die Standardkonten der Firma. Gelesen wird über OData (Warengruppen).
• Webshop-Produktgruppen anlegen: POST /api/Produktgruppe legt eine Produktgruppe für den Webshop an (keine Warengruppe). Ihre Kennung aus der Antwort ist als produktgruppeId der Webshop-Daten eines Artikels verwendbar.
• Lohnleistungen anlegen und ändern: POST /api/Lohnleistung legt eine Lohnleistung an; mit lohnleistungNr: AUTO (Standard) vergibt LX Connect die nächste freie Nummer, die Antwort nennt Kennung und Nummer. PUT /api/Lohnleistung/{id} ändert nur die mitgeschickten Felder. Die beschreibung darf höchstens 5000 Zeichen lang sein; ein Zeilenumbruch zählt dabei als zwei Zeichen, gespeichert und gelesen wird er als CRLF. Gelesen werden Lohnleistungen über OData (Lohnleistungen).
• Nebenleistungen anlegen und ändern: POST /api/Nebenleistung legt eine Nebenleistung (etwa Porto, Fracht oder Verpackung) mit Bezeichnung, Kurzbezeichnung und Preis an; die Antwort (201) nennt ihre Kennung, eine transaktionId schützt vor doppelter Anlage. Pflicht sind Bezeichnung (höchstens 100 Zeichen, in der Firma eindeutig ohne Unterscheidung von Groß- und Kleinschreibung) und Kurzbezeichnung (höchstens 20 Zeichen); ohne Preis gilt 0. Ohne Angabe von konten erhält sie die Standardkonten der Firma. PUT /api/Nebenleistung/{id} ändert nur die mitgeschickten Felder (Bezeichnung, Kurzbezeichnung, Preis); die Konten lassen sich nach der Anlage nicht mehr ändern. Die Kennung ist als nebenleistungId einer Belegposition vom Typ Nebenleistung verwendbar. Löschen lässt sich eine Nebenleistung nicht. Gelesen wird über OData (Nebenleistungen); nach einer Änderung über die Schnittstelle sind dort ErstelltAm und ErstelltVon leer und GeaendertVon steht auf 0.
• Projekte anlegen: POST /api/Projekt legt ein Projekt an; mit projektNr: AUTO (Standard) vergibt LX Connect die nächste freie Projektnummer, die Antwort (201) nennt Kennung und Nummer. Pflicht ist die Bezeichnung; die Projektnummer vergibt LX Connect mit AUTO (Standard) oder sie wird selbst angegeben. Kunde, Kundenkonditionen, Zahlungsbedingung, Lieferart, Preisgruppe, Kostenstelle, Kostenträger, Rabatt, Kreditrahmen und Projektlaufzeit lassen sich mitgeben; die Laufzeit nimmt reine Kalendertage, ohne Angabe setzt Lexware den Anlagezeitpunkt. Eine unbekannte oder stillgelegte Angabe wird mit 400 und dem betroffenen Feld abgelehnt; eine transaktionId schützt vor doppelter Anlage. Gelesen wird über OData (Projekte), an Belegen verweist Belege.ProjektId auf das Projekt. Ändern oder Löschen lässt sich ein Projekt über die Schnittstelle nicht.
• Preisaktionen anlegen und ändern: POST /api/Preisaktion legt eine zeitlich befristete Preisaktion mit Aktionspreisen (und bis zu drei Staffelpreisen) je Artikel an; die Antwort (201) nennt ihre Kennung, eine transaktionId schützt vor doppelter Anlage. Pflicht sind Bezeichnung, Kurzbezeichnung und die Laufzeit (datumVon, datumBis als reine Kalendertage bis höchstens 31.12.2039, beide Tage eingeschlossen). Ein Artikel darf nicht zugleich in einer anderen Preisaktion mit überschneidender Laufzeit stehen — die Ablehnung (400) nennt die betroffene Position. PUT /api/Preisaktion/{id} ändert nur die mitgeschickten Kopfangaben (Bezeichnung, Kurzbezeichnung, Beschreibung, Laufzeit, Sperre, Druck der Beschreibung auf Aufträgen); eine verschobene Laufzeit wird ebenfalls auf Überschneidungen geprüft. Die Preise lassen sich nach der Anlage nicht mehr ändern, Kunden lassen sich über die Schnittstelle nicht zuordnen; ohne Zuordnung gilt die Aktion für alle Kunden. Löschen lässt sich eine Preisaktion nicht; eine gesperrte Preisaktion wirkt nicht auf Preise, auch wenn sie erst nachträglich gesperrt wird. Gelesen wird über OData (Preisaktionen, die Preise über Sonderpreise).
• Tags anlegen und ändern: POST /api/Tag legt ein Tag an (optional mit Farbe aus TagFarben), PUT /api/Tag/{id} benennt es um oder ändert die Farbe; gelesen wird über OData (Tags). Die Antwort (201) nennt die Kennung, die sich direkt für die Zuordnung an Kunden, Lieferanten, Artikel und Belege verwenden lässt; eine transaktionId schützt vor doppelter Anlage. Die Bezeichnung ist Pflicht, höchstens 50 Zeichen lang (führende und folgende Leerzeichen werden entfernt) und in der Firma eindeutig ohne Unterscheidung von Groß- und Kleinschreibung und Umlauten („ü” gilt wie „u”, „ß” wie „ss”). Ohne Farbe ist TagFarbeId leer und Farbe zeigt die Standardfarbe. PUT ändert nur die mitgeschickten Felder; eine Farbe lässt sich nicht entfernen, und jede Änderung setzt GeaendertAm neu. Löschen bietet Lexware nicht an.
• Tags an Belegen zuordnen und entfernen: PUT /api/Beleg/{id}/tags/{tagId} ordnet einem Beleg einen Tag zu, DELETE /api/Beleg/{id}/tags/{tagId} entfernt ihn; je Aufruf ein Tag, Antwort 204 ohne Inhalt. Ein unbekannter Tag wird mit 400 und dem Feld TagId abgelehnt, ein unbekannter Beleg mit 400. Doppeltes Zuordnen und Entfernen ohne Zuordnung bleiben ohne Wirkung. Auch an obsoleten Belegen möglich. Gelesen wird über OData (TagZuordnungen, Filter BelegId).
• Noch nicht lesbar: Webshop-Produktgruppen sind über OData nicht abrufbar; ihre Kennung steht nur in der Antwort der Anlage. An Belegpositionen steht die Kennung einer Lohn- oder Nebenleistung noch nicht als eigenes Feld. Bei Projekten steht der Verweis auf die Lieferart nur als LieferartNr in Projekte (derselbe Wert wie Lieferarten.Id), ein Feld LieferartId fehlt noch. Bei Preisaktionen das Kennzeichen beschreibungAufAuftragDrucken.

Fehlerbehebungen.

• Erster Start nach einem Update: Wurde die Anwendung gestartet, während der Dienst nach einem Update noch hochfuhr, blieb sie dauerhaft bei „Verbindung wiederhergestellt — App wird geladen …” stehen und ließ sich nur durch einen Neustart der Anwendung laden. Sie lädt jetzt selbständig, sobald der Dienst bereit ist. Solange der Dienst noch hochfährt, wartet die Anwendung bis zu zwei Minuten und zeigt dabei den jeweiligen Startschritt an, statt nach 30 Sekunden eine Fehlermeldung anzuzeigen.
• Dienststart nach der Installation: Auf manchen Rechnern beendete sich der Dienst LX Connect direkt nach der Installation mit der Meldung „Keine installierte Lexware-Version gefunden”, obwohl der Installer die Lexware erkannt und LX Connect installiert hatte. Der Dienst erkennt die installierte Lexware jetzt auf demselben Weg wie der Installer.
• Neuere Lexware-Versionen: Die Übernahme der Lexware-Daten verlangte bisher genau die Lexware-Version, gegen die LX Connect gebaut ist, und hätte mit einer neueren Lexware beim ersten Zugriff abgebrochen. Sie verlangt jetzt — wie der Start des Dienstes — mindestens Lexware 26.70.
• Zeitstempel im Lesemodell: Zeitstempel (z. B. ErstelltAm/GeaendertAm, Zahlungsdatum, Projektlaufzeit) werden jetzt als exakter Zeitpunkt in UTC (Z) ausgegeben; bisher war die Uhrzeit um 1–2 Stunden verschoben und reine Tagesangaben erschienen als Vortag. Filter auf diese Felder ($filter) vergleichen ebenfalls den exakten Zeitpunkt, gleich in welcher Zeitzone das Literal angegeben ist. Zeitstempel enden jetzt auf Z; eigene Korrekturen des bisherigen Versatzes sind zu entfernen. Ausnahme: Ergebnisse von $apply/groupby liefern Zeitstempel ebenfalls in UTC, aber noch ohne Z. Wer einen gelesenen Zeitstempel als Datum an die Schreib-Schnittstelle zurückgibt, rechnet ihn vorher in Ortszeit um und gibt den Kalendertag in Ortszeit an — wer nur das Datum abschneidet, schreibt bei z. B. 2026-11-01T23:00:00Z den 1. statt den 2. November.

Neue Funktionen in der Schreib-Schnittstelle.

• Buchungen übergeben: Der neue Endpunkt POST /api/Buchung übergibt Buchungen an die Lexware Buchhaltung. Die Verarbeitung ist asynchron: Lexware legt die Buchung zunächst in einer Warteschlange ab, in Stapel oder Journal erscheint sie erst, wenn der Import in Lexware buchhaltung manuell angestoßen wurde (Menüleiste Ansicht → Import Buchungsdaten). Beim Aufruf prüft Lexware nur Feldlängen sowie Kostenstelle und Kostenträger.
• Debitorenkonto bei der Kundenanlage: POST /api/Kunde legt standardmäßig ein Debitorenkonto mit an (debitorkontoAnlegen, Standard true). Ohne Angabe eines Kontos erhält es die Kundennummer als Kontonummer — bei kundenNr: AUTO die nächste Nummer des Kunden-Nummernkreises. Über debitorenkonto lässt sich stattdessen ein vorhandenes Konto zuordnen oder ein Konto mit eigener Nummer anlegen. Existiert das Konto zur Kundennummer bereits, wird die Anlage abgelehnt. Die Zuordnung ist nur bei der Anlage möglich und nachträglich über die Schnittstelle nicht änderbar.
• Geänderte Antworten beim Anlegen: Alle Anlage-Antworten der Schreib-Schnittstelle (201) kommen ohne Location-Header. Er verwies bisher auf Adressen, die es nicht gibt. Die Kennung des angelegten Datensatzes steht unverändert im Antwortrumpf; gelesen wird weiterhin über OData.

Erste öffentliche Version von LX Connect.

LX Connect stellt die Daten einer lokalen Lexware-Installation als eigene Datenbank und über eine OData- und REST-Schnittstelle bereit. Voraussetzung ist Lexware ab Version 26.70 mit PostgreSQL-Datenbank.

Bis zum 1. Januar 2027 ist LX Connect in vollem Umfang kostenlos nutzbar. Am Datenmodell und an den Schnittstellen sind bis dahin noch Änderungen möglich.