> For the complete documentation index, see [llms.txt](https://one-loop.gitbook.io/help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://one-loop.gitbook.io/help/marketplace-apps/lexware-office/workflow-actions/rechnung-erstellen.md). # Rechnung erstellen Die Action **Create Invoice** erstellt eine finalisierte Rechnung in Lexware Office, speichert das offizielle PDF im aktuellen Kontakt und liefert die geprüften Belegdaten an den Workflow zurück. > **Teststatus:** Implementiert, aber noch nicht als allgemein verfügbar bestätigt. Zuerst nur mit kontrollierten Testvorgängen verwenden. ## Kundentyp und Kontaktzuordnung Das Pflichtfeld **Lexware customer type** bestimmt, ob das Dokument einer Firma oder einer Privatperson zugeordnet wird. Die Integration prüft zuerst eine bestehende, passende Zuordnung; danach eine exakte E-Mail- oder Stammdatenübereinstimmung und legt erst dann einen neuen Lexware-Kontakt an. Ein Wechsel von Privatperson zu Firma wandelt keinen bestehenden Kontakt um. Die vollständige Entscheidungskette, Pflichtdaten, Rückgabevariablen und Fehlerfälle findest du unter Firmen- und Privatkunden zuordnen. ## Wann diese Action passt * Nach einer erfolgreichen Zahlung * Mit Produkten, die im CRM gepflegt sind * Mit eigenen Werten aus Formularen, Terminen, Webhooks oder vorherigen Workflow-Schritten Die Action versendet keine E-Mail. Wenn du ein Dokument weitergeben möchtest, verwende danach die Ausgabe `invoiceFileUrl`. ## Sichtbares Feld: Positionsquelle | Auswahl | Technischer Wert | Wann verwenden? | Was die Integration prüft | | --------------------- | ---------------- | ------------------------------------------------ | -------------------------------------------------------------------------- | | **Paid transaction** | `transaction` | Rechnung direkt nach einer erfolgreichen Zahlung | Transaktion, Bestellung, Positionen, Steuer, Versand, Kontakt und Standort | | **CRM products** | `products` | Positionen sind als Produkte im CRM angelegt | Produkt-Preis-Auswahl, EUR-Währung und Produktsteuer | | **Map my own fields** | `manual` | Positionen kommen aus Workflow-Variablen | Deine Positions- und Steuerfelder | Bei **Paid transaction** wird im Ergebnis `sourceMode=purchase` zurückgegeben. Das ist die interne Normalisierung und kein Fehler. ## Allgemeine Felder | Feld / Referenz | Pflicht | Format und Standard | Bedeutung | | -------------------------------------------- | ------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Title / `title` | Nein | Text bis 25 Zeichen | Überschreibt den Dokumenttitel für diese Rechnung. Leer verwendet den Lexware-Standard. | | Introduction / `introduction` | Nein | Text bis 2.000 Zeichen | Text vor den Positionen. | | Remark / `remark` | Nein | Text bis 2.000 Zeichen | Text nach den Positionen. | | Payment term in days / `paymentTermDuration` | Nein | Ganze Zahl von `0` bis `3650` | Zahlungsziel in Tagen. `0` bedeutet sofort fällig; leer verwendet den Standard. | | Lexware customer type / `customerEntityType` | Ja | `auto`, `company`, `person` | `auto` erkennt den Typ aus dem Kontakt. `company` verlangt einen Firmennamen. `person` verwendet eine Personenidentität. | Der Kundentyp legt die Kontaktstruktur fest, nicht die Steuerart. Ein bestehender Kontakt wird nicht still von Privatperson zu Unternehmen oder umgekehrt umgewandelt. ## Felder bei „Paid transaction“ | Feld / Referenz | Pflicht | So verwendest du es | | -------------------------------- | ------- | ----------------------------------------------------------------------------------------- | | Transaction ID / `transactionId` | Ja | Im Variablen-Picker die Transaktions-ID des vorausgehenden Zahlungsereignisses auswählen. | In diesem Modus sind manuelle Steuerüberschreibungen nicht erlaubt. Die Integration akzeptiert nur erfolgreiche EUR-Zahlungen für den aktuellen Kontakt und Standort. Versand wird bei Bedarf mit passenden Steueranteilen als Position ergänzt. Jeder Betrag muss centgenau zum Zahlungsvorgang passen. ## Felder bei „CRM products“ Es stehen zehn Positionsplätze zur Verfügung. Leere optionale Plätze werden ignoriert. | Feldmuster | Pflicht | Format und Standard | Bedeutung | | ------------------- | ------------- | ------------------------- | -------------------------------------------------------------- | | `productNSelection` | Position 1 ja | Auswahl „Product & Price“ | Ein Produkt mit genau einem zugehörigen EUR-Betrag auswählen. | | `productNQuantity` | Nein | Positive Zahl, leer = `1` | Menge des Produkts; `2,5` und `2.5` werden als 2,5 verstanden. | Die Integration verwendet nur EUR-Beträge. Die Steuer kommt aus der Produktkonfiguration; sie kann in diesem Modus nicht manuell überschrieben werden. ## Felder bei „Map my own fields“ ### Steuerfelder | Feld / Referenz | Pflicht | Zulässige Werte | Bedeutung | | --------------------------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Tax Type / `taxType` | Ja | `net`, `gross`, `vatfree`, `intraCommunitySupply`, `constructionService13b`, `externalService13b`, `thirdPartyCountryService`, `thirdPartyCountryDelivery` | Legt fest, ob Positionsbeträge netto oder brutto sind bzw. welcher unterstützte Sonderfall gilt. | | Tax Subtype / `taxSubType` | Nein | leer, `distanceSales`, `electronicServices` | Ergänzt die passende Steuerart. | | Tax Note / `taxTypeNote` | Nein | Freitext | Steuerlicher Hinweis. | | Customer VAT ID / `customerVatId` | Je nach Steuerart | USt-IdNr. als Text | Nur verwenden, wenn der gewählte Steuerfall sie verlangt. | ### Positionsfelder Für jede Position `N` von 1 bis 10 stehen diese Felder bereit: | Feldmuster | Pflicht | Format und Standard | Bedeutung | | ------------------ | -------------------------------------- | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | `itemNName` | Position 1 ja; weitere nur bei Nutzung | Text | Bezeichnung. Eine Position ohne Namen wird ignoriert. | | `itemNDescription` | Nein | Text | Zusätzliche Beschreibung. | | `itemNQuantity` | Bei genutzter Position ja | Positive Zahl, leer = `1` | Menge ohne Einheit. | | `itemNUnit` | Nein | Leer = `Stück` | Erlaubt: `Stück`, `Stunde`, `Tag`, `Monat`, `Pauschale`, `Kilometer`, `Kilogramm`, `Meter`, `m²`, `Lizenz`, `Paket`, `Leistung`. | | `itemNUnitPrice` | Bei genutzter Position ja | EUR-Zahl ohne Zeichen, z. B. `150.00` | Betrag je Einheit; bei `net` netto, bei `gross` brutto. Negative Beträge sind nicht erlaubt. | | `itemNTaxRate` | Bei genutzter Position ja | Zahl ohne Prozentzeichen, z. B. `19`, `7`, `0` | Steuersatz der Position. | | `itemNDiscount` | Nein | Prozent ohne Zeichen, leer = `0` | Positionsrabatt, z. B. `10` für zehn Prozent. | ## Payload-Beispiel Du schreibst diesen JSON-Block nicht selbst. Er zeigt, welche Werte nach deiner Feldzuordnung ankommen. ```json { "data": { "sourceMode": "manual", "customerEntityType": "company", "title": "Rechnung", "paymentTermDuration": "14", "taxType": "net", "item1Name": "Beratung August", "item1Quantity": "2", "item1Unit": "Stunde", "item1UnitPrice": "150.00", "item1TaxRate": "19", "item1Discount": "0" }, "extras": { "locationId": "location_example_123", "contactId": "contact_example_123", "executionId": "execution_example_123" }, "meta": { "key": "one_loop_lexware_create_invoice" } } ``` Das Ergebnis dieses Beispiels ist netto 300,00 EUR, Steuer 57,00 EUR und brutto 357,00 EUR. ## Alle Ausgabevariablen | Variable | Bedeutung im Workflow | | ------------------------------------------------------ | -------------------------------------------------------------------------------- | | `success` | `true` nur bei vollständig erfolgreicher Erstellung und PDF-Ablage. | | `status` | Ergebnisstatus; bei Erfolg `success`. | | `errorCode` | Maschinenlesbarer Fehlercode; bei Erfolg leer. | | `errorMessage` | Verständliche Fehlermeldung; bei Erfolg leer. | | `retryable` | Kennzeichnet einen möglichen vorübergehenden Fehler. | | `warnings` | Liste zusätzlicher Hinweise. | | `sourceMode` | `purchase`, `product` oder `manual`. | | `sourceReferenceType` | Art der Quelle, etwa `transaction`, `product`, `execution` oder `request`. | | `sourceReferenceId` | Kennung der verwendeten Quelle. | | `lexwareContactId` | Kennung des verwendeten Lexware-Kontakts. | | `customerMatchMethod` | Wie der Kontakt gefunden wurde: Zuordnung, E-Mail, Stammdaten oder neu erstellt. | | `customerCreated` | `true`, wenn ein neuer Lexware-Kontakt erstellt wurde. | | `customerUpdated` | `true`, wenn Kontaktdaten ergänzt wurden. | | `invoiceId` | Lexware-Kennung der Rechnung. | | `invoiceNumber` | Sichtbare Rechnungsnummer. | | `invoiceStatus` | Status der Rechnung, etwa `open`. | | `voucherDate` | Belegdatum im ISO-Format. | | `currency` | Währung, aktuell `EUR`. | | `netAmount`, `taxAmount`, `grossAmount` | Final zurückgelesene Netto-, Steuer- und Bruttosumme. | | `officialDocumentMimeType`, `officialDocumentFileName` | Typ und Name des offiziellen Dokuments. | | `invoiceDocumentId` | Kennung der PDF-Kopie am Kontakt; nicht die Lexware-Rechnungs-ID. | | `invoiceFileUrl` | URL der PDF-Kopie für den nächsten Workflow-Schritt. | | `invoiceFileName`, `invoiceMimeType` | Dateiname und MIME-Typ dieser PDF-Kopie. | | `contactDocumentStatus` | Bei vollständigem Erfolg `uploaded`. | | `lexwareViewUrl` | Interner Link zu Lexware Office, nicht als öffentlicher Link verwenden. | ## Praxisbeispiel Nach der Action folgt eine interne Nachricht oder ein Dokument-Schritt. Wähle im Variablen-Picker dieser Rechnungs-Action: ``` Rechnungsnummer: invoiceNumber PDF: invoiceFileUrl Bruttobetrag: grossAmount ``` Vor dem Weitergeben prüfen: `success=true` und `contactDocumentStatus=uploaded`. ## Häufige Fragen: Documents & Contracts mit Direct Payment ### Warum kann ein Käufer zwei Rechnungen oder E-Mails sehen? {% hint style="warning" %} **Bekannte Plattformbeschränkung** Bei **Documents & Contracts** mit aktivierter Option **Direct Payment** erzeugt die Plattform technisch zwingend eine eigene Rechnung als Zahlungsobjekt. In der aktuell beobachteten Oberfläche lässt sich **Send Invoice** bei aktivem **Direct Payment** nicht unabhängig deaktivieren. Dadurch kann die Plattform zusätzlich automatisch eine eigene Rechnungs-E-Mail an den Käufer senden. Die ONE LOOP App erstellt nach erfolgreicher Zahlung zusätzlich die fachliche und offizielle Rechnung in Lexware Office. Der Käufer kann dadurch zwei Rechnungsdarstellungen oder zwei Rechnungsnachrichten sehen: eine von der Plattform und eine von Lexware Office. Das ist **keine zweite Belastung und keine zweite Zahlung**, kann aber buchhalterisch und in der Kommunikation missverständlich sein. Das Abschalten des Invoice-Moduls in der Standortkonfiguration verhindert diesen internen Documents-&-Contracts-Invoice-Prozess derzeit nicht zuverlässig. ONE LOOP kann die von der Plattform erzeugte Rechnung oder E-Mail mit dieser Marketplace-App nicht unterdrücken. Der Scope `invoices.readonly` ist ausschließlich lesend: Er erzeugt oder versendet keine Rechnung, sondern wird bei diesem Quelltyp nur benötigt, um die bereits erzeugten Positions- und Steuerdaten sicher für Lexware Office auszulesen. Wenn auf keinen Fall eine plattformseitige Rechnung oder E-Mail entstehen darf, nutze Documents & Contracts nur für Unterschrift oder Annahme, deaktiviere **Direct Payment** und sende anschließend im Workflow einen separaten Payment Link. Nach erfolgreicher Zahlung führst du die Lexware-Action aus. Alternativ kannst du **Direct Payment** verwenden und akzeptierst die zusätzliche plattformseitige Rechnung/E-Mail als aktuelle Plattformbeschränkung. {% endhint %} ### Was soll ich wählen? * Wähle den Payment-Link-Ablauf, wenn keine plattformseitige Rechnung und keine zusätzliche plattformseitige Rechnungs-E-Mail entstehen darf. * Wähle **Direct Payment** nur, wenn die zusätzliche plattformseitige Rechnung/E-Mail als aktuelle Plattformbeschränkung für diesen Verkauf akzeptiert werden kann. Mehr zum grundsätzlichen Verhalten von Direct Payment und Invoice-Versand findest du in der [offiziellen Plattformreferenz](https://help.gohighlevel.com/support/solutions/articles/155000004063-automatically-generate-invoices-from-signed-documents-contracts).