Kunden- und Lieferantenverwaltung – Vollständige API-Referenz

Fach-API für den Geschäftspartnerstamm: Kunde, Lieferant, Kunde und Lieferant, Interessent, Adressen, Bankverbindungen und Ansprechpartner. Basis ist https://core-backend.reybex.com/api (Staging: https://io-staging-partner.reybex.com/api). Authentifizierung wie im API: --header "authorization: Basic $TOKEN".

Verkaufsbelege stehen unter Auftragsverwaltung, Einkaufsbelege unter Einkauf-Verwaltung. Währung, Steuer, Zahlungsbedingung und Einheiten unter Prüftabellen-Verwaltung.

Aktivitäten, Chancen und der Konnektor stehen unter CRM.

Der normale Schreibweg ist POST /api/customer/. Der Body ist der Partner selbst, ohne Umschlag.

1. Grundlagen

Kunde und Lieferant sind derselbe Datensatz Customer. Die Kontaktart contactType.type entscheidet die Rolle.

GET /api/customer/convertToCustomer/{id} und GET /api/customer/convertProspectToCustomer/{id} setzen einen Interessenten auf die Kunden-Kontaktart. Ein Lieferant (type 2) wird dabei abgelehnt.

1.1 Speichern

POST /api/customer/ legt an, wenn keine id im Body steht, und ändert, wenn id gesetzt ist.

Ohne customerNo vergibt der Nummernkreis der Kontaktart die Nummer. Fehlt danach auch datevDebitorNo, wird die DATEV-Nummer aus demselben Kreis gesetzt.

Response

json

{
  "id": 30001,
  "translatedName": "Nordlicht GmbH",
  "customerNo": "KD-1000"
}

Zwei Sonderwege desselben Endpunkts:

Flag	Wirkung
`isAddressMatchingUsed`	Sucht einen bestehenden Kunden über `address` (Nummer, Name, PLZ, USt-Id, E-Mail) und legt nur an, wenn keiner passt. Antwort nur `{ "id" }`
`isSaveByCashRegister`	Legt einen Kassenkunden mit Name und Adresse an. Die Kontaktart kommt aus der Kasse

1.2 Suchschlüssel

Am Partner eine bekannte id oder einen Suchschlüssel senden.

Ziel	Suchschlüssel
Partner selbst, in anderen Aufrufen	`customerNo`
Kontaktart	`type`, sonst `name`
Land, Währung, Sprache, Steuer, Zahlungsbedingung, Kundengruppe, Versandart	`code`, sonst `type`, sonst `name`

Bank und Ansprechpartner lesen den Partner per customer.id. Ein Suchschlüssel reicht dort nicht.

1.3 Antwort- und Fehlerformat

Lesen kapselt den Datensatz:

json

{
  "data": {
    "id": 30001,
    "customerNo": "KD-1000",
    "name": "Nordlicht GmbH"
  },
  "meta": {
    "domain": "Customer",
    "total": 1
  }
}

meta kann requiredFields, readOnlyFields, hiddenFields und invisibleFields enthalten. Die Feldrechte folgen der Kontaktart: prospect, vendor oder customer.

Situation	HTTP	Körper
Partner nicht gefunden	oft 404	`{ "error": "…" }`
Unterlieferungstoleranz außerhalb 0 bis 100	500	`message.lowerDeliveryTolerance.invalid.value.error`
Überlieferungstoleranz unter 0	500	`message.upperDeliveryTolerance.invalid.value.error`
Lieferant soll Kunde werden	Fachlicher Fehler	`customer.not.found.error`
Fehlende Anmeldung	401	—

2. Kontaktart

ContactType.type:

`type`	Bedeutung	Verwendung
`0`	Interessent	Noch kein Kunde. Umwandlung über `convertToCustomer`
`1`	Kunde	Auftrag `customer.customerNo`
`2`	Lieferant	Bestellung `vendor.customerNo`
`3`	Kunde und Lieferant	Beide Belegwelten, dieselbe Nummer
`4`	Partner	Verhalten wie Kunde bei der Adresssuche
`5`	Handelsvertreter	Vertreterstamm
`6`	Adresse	Adressdatensatz ohne eigene Rolle

countryType an der Kontaktart: 0 Inland, 1 EU, 2 Third party. Die Kontaktart kann einen Nummernkreis numberRange und einen DATEV-Kreis datevNumberRange tragen.

Lesen: GET /api/domains/contactType?take=100.

3. Wichtige Felder

3.1 Partner

Feld	Bedeutung
`name`, `name2`	Name und Zusatz
`customerNo`	Nummer. Suchschlüssel in Auftrag und Bestellung
`contactType`	Rolle, siehe Kontaktart
`code`	Zusatzcode
`street`, `street2`, `zipcode`, `city`, `province`, `country`	Hauptadresse auf dem Partner
`poBox`, `poZipcode`	Postfach
`phone`, `mobile`, `fax`, `email`, `web`	Kontakt
`language`	Sprache der Belege
`currency`	Währung. Wird auf neue Belege übernommen
`vatKey`	Steuer
`ustdid`	USt-Id. Wird beim Speichern bereinigt
`taxNumber`, `taxDepartment`	Steuernummer und Finanzamt
`paymcond`, `paymentType`	Zahlungsbedingung und Zahlart
`customerGroup`	Kundengruppe, steuert Preise
`salesPricelist`	Preisliste
`discountType`, `discountType2`, `discountType3`	Kopfrabatte, die ein neuer Verkaufsbeleg übernimmt
`itemDiscountType`	Positionsrabatt, die Rabattart muss Positionsrabatt sein
`shipping`, `freight`, `packaging`	Versand, Fracht, Verpackung
`salesDepartment`, `purDepartment`	Verkaufs- und Einkaufsabteilung
`profitCenter`	Profitcenter
`salesPerson`, `keyAccountManager`	Innen- und Key-Account
`creditLimit`	Kreditlimit
`isLocked`	Gesperrt
`blockedDelivery`	Liefersperre. Ein gesperrter Kunde liefert in der Belegkette keinen Lieferschein
`partlyDelivery`	Teillieferung erlaubt, Standard `true`
`isGrossPrice`	Neue Belege starten mit Bruttopreis
`minOrder`	Mindestbestellwert
`lowerDeliveryTolerance`, `upperDeliveryTolerance`	Lieferfenster in Prozent. Unterlieferung 0 bis 100
`isDeliveryToleranceIgnored`	Toleranzen ignorieren
`collectiveInvoice`	Sammelrechnung
`orderTransmissionType`	`0` keine. `1` E-Mail mit Lieferschein, `2` E-Mail mit Lieferschein und Etiketten, `3` EDI
`ourCustomerNumber`	Eigene Nummer beim Kunden oder Lieferanten
`gln`, `gs1`	Globale Lokationsnummer
`isEinvoiceTaxpayer`	E-Rechnungspflicht
`eInvoiceType`	`0` PDF, `1` XRechnung, `2` ZUGFeRD, `3` ZUGFeRD Markant
`eInvoiceEmail`, `eInvoiceId`	E-Rechnungs-Mail und Kennung
`isDunning`	Mahnung aktiv, Standard `true`
`datevDebitorNo`	DATEV-Debitor
`account`, `purAccount`	FiBu-Konto Verkauf und Einkauf
`abcCategory`	ABC-Klasse
`barcode`	Suche über `customerByBarcode`
`creditProcessType`	Gutschriftsverfahren. `0` keines, `1` Wareneingang, `2` Warenausgang
`isDelete`	Logisch gelöscht
`isTemplate`	Vorlage, erscheint nicht in den normalen Listen

3.2 Adresse

CustomerAddress.type: 0 sonstige, 1 Lieferung, 2 Rechnung, 3 Post.

Feld	Bedeutung
`customer`	Partner
`type`	Adressart
`isDefault`	Standardadresse dieser Art
`addressline1`, `addressline2`	Adresszeilen, oft der Empfängername
`street1`, `street2`, `zipStreet`, `city`, `province`, `country`	Straße
`isPobox`, `poboxStreet`, `zipPobox`	Postfach
`language`, `vatKey`, `ustdid`	Abweichende Sprache und Steuer
`gln`, `iln`	Lokationsnummern
`phone`, `email`	Kontakt der Adresse
`validFrom`, `validUntil`	Gültigkeit
`position`	Reihenfolge
`hasNeutralDeliveryNote`	Neutraler Lieferschein
`isDelete`	Logisch gelöscht

Die Hauptadresse auf dem Partner (street, zipcode, city) ist nicht dieselbe Tabelle wie CustomerAddress. Belege kopieren beim Anlegen die Adresse des Partners und seiner Adressdatensätze.

3.3 Bank

Feld	Bedeutung
`customer`	Partner, per `id`
`name`	Bankname
`iban`, `bic`	IBAN und BIC. Ungültige Werte: `validator.customerBank.iban` oder `validator.customerBank.bic`
`accountNumber`, `blz`	Konto und BLZ, wenn keine IBAN gesetzt ist
`country`	Land der Bank
`isMain`	Hauptbank, Standard `true`
`toPrint`	Auf Belegen drucken
`mandateReference`	SEPA-Mandat
`customerName`	Kontoinhaber
`isDelete`	Logisch gelöscht

Ohne IBAN und ohne Kontonummer plus BLZ: message.iban.empty.error.

3.4 Ansprechpartner

CustomerEmployee verbindet den Partner mit einer ContactPerson.

Feld	Bedeutung
`customer`	Partner, per `id`
`contactPerson.firstname`, `surname`	Vor- und Nachname
`contactPerson.email`, `phone`, `mobile`	Kontakt der Person
`contactPerson.salutation`	Anrede, Suchschlüssel `name`
`isMainContact`	Hauptkontakt
`isSales`	Kontakt für Verkaufsbelege
`isPurchase`	Kontakt für Einkaufsbelege
`isFinance`	Kontakt für Finanzbelege
`isDunning`	Mahnempfänger
`sentInvoice`	Rechnungsempfänger
`department`, `position`	Abteilung und Funktion am Partner
`email`, `phone`	Abweichende Daten an der Zuordnung
`isDroppedOut`	Ausgeschieden
`isDelete`	Logisch gelöscht

4. Lesen

4.1 Ein Partner

GET /api/customer/{id}

bash

curl --header "authorization: Basic $TOKEN" \
  "https://core-backend.reybex.com/api/customer/30001"

Unbekannte Id: Ressource nicht gefunden.

Mehrere Partner: POST /api/customer/list mit { "ids": [30001, 31001] }.

Suche über die Domain-API, der Suchschlüssel ist customerNo:

GET /api/domains/customer?customerNo=eq(KD-1000)&take=1

4.2 Liste und Lieferanten

GET /api/customer/ ist die Partnerliste.

GET /api/customer/light ist die kompakte Liste.

GET /api/customer/listVendors listet nur Kontaktart Lieferant (type 2).

Mehrere Rollen: POST /api/customer/customersByContactType

json

{ "contactTypes": [1, 3] }

Response

json

{
  "data": [
    { "id": 30001, "translatedName": "KD-1000 - Nordlicht GmbH" }
  ]
}

1 sind Kunden, 3 sind Kunden und Lieferanten. Für Bestellungen 2 und 3 abfragen.

Barcode: GET /api/customer/customerByBarcode?barcode=4711. Antwort id, translatedName, barcode. Unbekannt: nicht gefunden.

4.3 Dublette vor dem Anlegen

POST /api/customer/nameDuplicate

json

{
  "name": "Nordlicht",
  "contactTypeId": 11
}

11 ist die Id der Kontaktart Kunde. Die Antwort ist { "duplicates": [ … ] } mit höchstens fünf Treffern. Jeder Treffer hat id, customerNo, name, translatedName und warrningMessage. Der letzte Schlüssel heißt in der Antwort warrningMessage.

5. Kunde anlegen

Zuerst Kontaktart, Land, Währung, Sprache, Steuer und Zahlungsbedingung lesen.

5.1 Inlandskunde

POST /api/customer/

json

{
  "name": "Nordlicht GmbH",
  "customerNo": "KD-1000",
  "contactType": { "type": 1 },
  "street": "Torstraße 1",
  "zipcode": "10115",
  "city": "Berlin",
  "country": { "code": "DE" },
  "language": { "code": "de" },
  "currency": { "code": "EUR" },
  "vatKey": { "code": "19" },
  "paymcond": { "code": "14" },
  "email": "einkauf@nordlicht.example",
  "phone": "+4930123456",
  "ustdid": "DE123456789",
  "customerGroup": { "code": "HANDEL" },
  "partlyDelivery": true,
  "blockedDelivery": false,
  "isGrossPrice": false,
  "creditLimit": 5000
}

Response

json

{
  "id": 30001,
  "translatedName": "Nordlicht GmbH",
  "customerNo": "KD-1000"
}

Ohne customerNo kommt die Nummer aus dem Nummernkreis der Kontaktart. Dieselbe Nummer verwendet später der Auftrag:

json

{ "customer": { "customerNo": "KD-1000" } }

5.2 EU-Kunde mit E-Rechnung

json

{
  "name": "Atelier Lyon",
  "customerNo": "KD-2000",
  "contactType": { "type": 1 },
  "street": "12 Rue de la République",
  "zipcode": "69002",
  "city": "Lyon",
  "country": { "code": "FR" },
  "language": { "code": "fr" },
  "currency": { "code": "EUR" },
  "vatKey": { "code": "0" },
  "ustdid": "FR12345678901",
  "paymcond": { "code": "30" },
  "email": "achat@atelier-lyon.example",
  "isEinvoiceTaxpayer": true,
  "eInvoiceType": 1,
  "eInvoiceEmail": "facture@atelier-lyon.example"
}

eInvoiceType 1 ist XRechnung. 0 ist PDF, 2 ZUGFeRD, 3 ZUGFeRD Markant.

5.3 Interessent und Umwandlung

json

{
  "name": "Musterladen",
  "contactType": { "type": 0 },
  "city": "Hamburg",
  "country": { "code": "DE" },
  "email": "info@musterladen.example"
}

Angenommen die Antwort liefert id 30050. Umwandlung zum Kunden:

GET /api/customer/convertToCustomer/30050

Response: { "id": 30050, "customerNo": "KD-1050", "name": "Musterladen" }

Die Nummer kann sich ändern, weil der Nummernkreis der Kunden-Kontaktart greift.

Ein Lieferant wird nicht umgewandelt (customer.not.found.error). Fehlt eine Kunden-Kontaktart: customerType.not.found.error. GET /api/customer/convertProspectToCustomer/{id} ruft dieselbe Umwandlung auf.

6. Lieferant anlegen

6.1 Reiner Lieferant

json

{
  "name": "Mühle Ost GmbH",
  "customerNo": "L-1000",
  "contactType": { "type": 2 },
  "street": "Hafenweg 4",
  "zipcode": "20457",
  "city": "Hamburg",
  "country": { "code": "DE" },
  "language": { "code": "de" },
  "currency": { "code": "EUR" },
  "vatKey": { "code": "7" },
  "paymcond": { "code": "30" },
  "email": "bestellung@muehle-ost.example",
  "purDepartment": { "name": "Einkauf" },
  "lowerDeliveryTolerance": 5,
  "upperDeliveryTolerance": 10
}

Response: { "id": 31001, "translatedName": "Mühle Ost GmbH", "customerNo": "L-1000" }

Die Bestellung referenziert denselben Satz:

json

{ "vendor": { "customerNo": "L-1000" } }

Unterlieferung über 100 oder unter 0 bricht ab. Überlieferung unter 0 ebenfalls.

6.2 Kunde und Lieferant

Ein Partner, der kauft und liefert. type 3. Eine Nummer für Auftrag und Bestellung.

json

{
  "name": "Hof Berg",
  "customerNo": "KL-3000",
  "contactType": { "type": 3 },
  "street": "Dorfstraße 8",
  "zipcode": "83229",
  "city": "Aschau",
  "country": { "code": "DE" },
  "currency": { "code": "EUR" },
  "language": { "code": "de" },
  "vatKey": { "code": "7" },
  "paymcond": { "code": "14" },
  "email": "buero@hof-berg.example"
}

Auftrag: { "customer": { "customerNo": "KL-3000" } }. Bestellung: { "vendor": { "customerNo": "KL-3000" } }.

6.3 Lieferant mit Einkaufstoleranz und eigener Nummer

ourCustomerNumber ist die Nummer, unter der der Mandant beim Lieferanten geführt wird.

json

{
  "id": 31001,
  "ourCustomerNumber": "47110815",
  "creditProcessType": 1
}

creditProcessType 1 ist das Gutschriftsverfahren Wareneingang, 2 Warenausgang.

Dieselbe Nummer für viele Partner: POST /api/customer/saveOurCustomerNumber

json

{
  "customers": [
    { "customerNo": "L-1000", "ourCustomerNumber": "47110815" },
    { "customerNo": "L-2000", "ourCustomerNumber": "47110816" }
  ]
}

Antwort { "success": true }. Eine unbekannte customerNo wird übersprungen, nicht als Fehler gemeldet.

7. Adressen

POST /api/customerAddress/ speichert die Adresse und antwortet { "id": 32001 }. Löschen: DELETE /api/customerAddress/ mit { "id": 32001 }. Das Löschen setzt isDelete.

30001 ist Kunde KD-1000.

7.1 Lieferadresse

json

{
  "customer": { "customerNo": "KD-1000" },
  "type": 1,
  "isDefault": true,
  "addressline1": "Lager Nord",
  "street1": "Torstraße 1",
  "zipStreet": "10115",
  "city": "Berlin",
  "country": { "code": "DE" },
  "language": { "code": "de" },
  "phone": "+4930123456",
  "gln": "4012345000001",
  "position": 10
}

7.2 Rechnungsadresse

json

{
  "customer": { "customerNo": "KD-1000" },
  "type": 2,
  "isDefault": true,
  "addressline1": "Nordlicht GmbH Buchhaltung",
  "street1": "Friedrichstraße 50",
  "zipStreet": "10117",
  "city": "Berlin",
  "country": { "code": "DE" },
  "email": "rechnung@nordlicht.example",
  "ustdid": "DE123456789",
  "vatKey": { "code": "19" }
}

7.3 Adresse an einen Beleg schreiben

POST /api/customer/saveAddress schreibt die Adresse auf einen vorhandenen Verkaufs- oder Einkaufsbeleg. Genau eines von salesHeadId und purHeadId muss gesetzt sein. customerNo ordnet die Adresse dem Partner zu. addressType 0 ist die Kunden- oder Hauptadresse, 1 die Empfänger- oder Lieferadresse, 2 die Rechnungsadresse. country, language und vatKey werden hier per id gelesen.

json

{
  "salesHeadId": 510100,
  "customerNo": "KD-1000",
  "addressType": 1,
  "createAddressInCustomer": true,
  "addressline1": "Lager Nord",
  "street1": "Torstraße 1",
  "zipStreet": "10115",
  "city": "Berlin",
  "country": { "id": 1 },
  "isDefault": false
}

Response: { "addressId": 32011 }

createAddressInCustomer false legt die Adresse nur an den Beleg und verwirft sie am Partner wieder. Fehlen beide Beleg-Ids: nicht gefunden.

Eigene Adressen eines Partners: GET /api/customerAddress/?customerId=30001. GET /api/customer/addresses/{id} liefert dagegen die Adressen von Konditionskunde, Zentralkunde und Hauptkontakt. Eine einzelne Adresse: GET /api/customer/getAddress/{adressId}. Die Lieferantenadresse: GET /api/customer/getVendorAddress/{adressId}. Die Tabellenliste: GET /api/customerAddress/table.

8. Bank

POST /api/customerBank/ verlangt customer.id. 30001 ist KD-1000, 31001 ist L-1000.

8.1 Hauptbank des Kunden

json

{
  "customer": { "id": 30001 },
  "name": "Berliner Bank",
  "iban": "DE89370400440532013000",
  "bic": "COBADEFFXXX",
  "country": { "code": "DE" },
  "isMain": true,
  "toPrint": true,
  "mandateReference": "MANDAT-KD-1000",
  "customerName": "Nordlicht GmbH"
}

Response: { "id": 33001 }

8.2 Bank des Lieferanten

json

{
  "customer": { "id": 31001 },
  "name": "Hamburger Bank",
  "iban": "DE12500105170648489890",
  "bic": "INGDDEFFXXX",
  "country": { "code": "DE" },
  "isMain": true,
  "customerName": "Mühle Ost GmbH"
}

Fehlt die IBAN und es gibt weder accountNumber noch blz, bricht das Speichern ab. Eine zweite Bank mit isMain false:

json

{
  "customer": { "id": 31001 },
  "name": "Zweitkonto",
  "iban": "DE02120300000000202051",
  "bic": "BYLADEM1001",
  "isMain": false
}

IBAN eines Lieferanten anlegen, falls sie noch fehlt: POST /api/customerBank/checkVendorIban

json

{
  "id": 31001,
  "iban": "DE12500105170648489890"
}

id ist die Lieferanten-Id. Existiert die IBAN schon, passiert nichts. Sonst entsteht eine Bank mit dem Namen PUR04-Automatic und isMain false. Antwort { "isSuccess": true }.

Löschen: DELETE /api/customerBank/ mit { "banks": [33001] }. Antwort { "success": "success" }.

9. Ansprechpartner

POST /api/customerEmployee/ verlangt customer.id. Die Person steht unter contactPerson.

9.1 Verkaufskontakt

json

{
  "customer": { "id": 30001 },
  "isMainContact": true,
  "isSales": true,
  "sentInvoice": true,
  "department": "Einkauf",
  "email": "einkauf@nordlicht.example",
  "phone": "+4930123457",
  "contactPerson": {
    "firstname": "Lena",
    "surname": "Berg",
    "email": "einkauf@nordlicht.example",
    "phone": "+4930123457",
    "salutation": { "name": "Frau" },
    "language": { "code": "de" }
  }
}

Response: { "id": 34001, "sentInvoice": true, "name": "…", "email": "einkauf@nordlicht.example" }

sentInvoice true übernimmt eine gültige E-Mail der Person in eInvoiceEmail des Partners. Die Person erscheint im Mail-Dialog eines Auftrags, wenn eine E-Mail hinterlegt ist.

9.2 Einkaufskontakt beim Lieferanten

json

{
  "customer": { "id": 31001 },
  "isPurchase": true,
  "isMainContact": true,
  "department": "Vertrieb",
  "contactPerson": {
    "firstname": "Omar",
    "surname": "Kruse",
    "email": "vertrieb@muehle-ost.example",
    "salutation": { "name": "Herr" }
  }
}

9.3 Mahnkontakt

json

{
  "customer": { "id": 30001 },
  "isFinance": true,
  "isDunning": true,
  "contactPerson": {
    "firstname": "Ida",
    "surname": "Sommer",
    "email": "mahnung@nordlicht.example"
  }
}

Liste der Personen eines Partners: GET /api/customerEmployee/customerEmployeeListForCustomer/{id}.

Löschen ist logisch: DELETE /api/customerEmployee/ mit { "id": 34001 }.

10. Ändern, sperren, kopieren, prüfen

10.1 Kreditlimit und Liefersperre

json

{
  "id": 30001,
  "creditLimit": 8000,
  "blockedDelivery": true,
  "isLocked": false
}

blockedDelivery true verhindert den Lieferschein in der Verkaufskette. isLocked sperrt den Partner.

10.2 USt-Id prüfen

POST /api/customer/checkUstdId

json

{
  "id": 30001,
  "UstId_2": "DE123456789",
  "Firmenname": "Nordlicht GmbH",
  "Ort": "Berlin",
  "PLZ": "10115",
  "Strasse": "Torstraße 1"
}

id ist der Partner. Die Prüfung schreibt ustdidLastCheckDate und ustdidLastCheckResult. Die Antwort enthält code, customerId und customerName. Details zum letzten Stand: GET /api/customer/ustIdDetails.

10.3 Kopieren

POST /api/customer/copy

json

{
  "customerId": 30001,
  "customerName": "Nordlicht Filiale Süd",
  "customerNo": "KD-1001",
  "customerAddress": true
}

customerAddress true kopiert die Adressen. purPrice true kopiert die Einkaufspreise des Lieferanten. Ohne customerNo vergibt der Nummernkreis eine neue Nummer. Antwort { "id": 30002 }.

10.4 Löschen

DELETE /api/customer/30001

Response: { "id": 30001 }

Das Löschen ist logisch (isDelete). Gelöschte Partner fehlen in customersByContactType und in der Namensprüfung.

11. Weitere Beispiele

11.1 Kasse

POST /api/customer/ mit isSaveByCashRegister. Die Kontaktart kommt aus der Kasse cashRegisterId. Die Kasse selbst steht unter Kassenverwaltung.

json

{
  "isSaveByCashRegister": true,
  "cashRegisterId": 9001,
  "name": "Laufkunde",
  "street": "Markt 2",
  "zipcode": "10115",
  "city": "Berlin",
  "countryId": 1,
  "email": "laufkunde@example",
  "phone": "+491511234567",
  "barcode": "4711"
}

Response: id, name, translatedName, customerNo.

11.2 Adressabgleich statt Neuanlage

isAddressMatchingUsed sucht zuerst. Der Suchblock heißt address. Treffer über customerNo gelten nur für Kontaktart 1 und 3. Ohne Treffer wird angelegt. Antwort nur die id.

json

{
  "isAddressMatchingUsed": true,
  "address": {
    "customerNo": "KD-1000",
    "name": "Nordlicht GmbH",
    "zipCode": "10115",
    "city": "Berlin",
    "street": "Torstraße 1",
    "email": "einkauf@nordlicht.example",
    "ustdid": "DE123456789"
  }
}

11.3 Handelsvertreter

json

{
  "name": "Vertrieb Süd",
  "customerNo": "VT-10",
  "contactType": { "type": 5 },
  "email": "sued@vertrieb.example",
  "country": { "code": "DE" },
  "currency": { "code": "EUR" }
}

11.4 Vom Interessenten zum Auftrag

Interessent anlegen, Abschnitt Interessent.
GET /api/customer/convertToCustomer/{id}.
Liefer- und Rechnungsadresse speichern.
Ansprechpartner mit isSales anlegen.
Auftrag mit { "customer": { "customerNo": "…" } }, siehe Auftragsverwaltung.

11.5 Vom Lieferanten zur Bestellung

Lieferant type 2 anlegen.
Bank mit customer.id speichern.
Ansprechpartner mit isPurchase anlegen.
Bestellung mit { "vendor": { "customerNo": "L-1000" } }, siehe Einkauf-Verwaltung.

12. Endpoint-Katalog

12.1 Partner

Methode	Pfad	Bedeutung
`GET`	`/api/customer/{id}`	Ein Partner oder die Liste
`POST`	`/api/customer/list`	Mehrere Ids
`POST`	`/api/customer/`	Anlegen und ändern
`DELETE`	`/api/customer/{id}`	Logisch löschen
`GET`	`/api/customer/light`	Kompakte Liste
`GET`	`/api/customer/listVendors`	Nur Lieferanten
`POST`	`/api/customer/customersByContactType`	Filter `contactTypes`
`GET`	`/api/customer/customerByBarcode`	Query `barcode`
`POST`	`/api/customer/nameDuplicate`	Namensprüfung
`GET`	`/api/customer/convertToCustomer/{id}`	Interessent wird Kunde
`GET`	`/api/customer/convertProspectToCustomer/{id}`	Dieselbe Umwandlung
`POST`	`/api/customer/copy`	Kopie
`POST`	`/api/customer/saveOurCustomerNumber`	Eigene Nummern setzen
`POST`	`/api/customer/checkUstdId`	USt-Id prüfen
`GET`	`/api/customer/ustIdDetails`	Letztes Prüfergebnis
`POST`	`/api/customer/saveAddress`	Adresse an einen Beleg
`GET`	`/api/customer/addresses/{id}`	Adressen von Zentral- und Konditionskunde
`GET`	`/api/customer/getAddress/{id}`	Eine Adresse
`GET`	`/api/customer/getAddressData/{id}`	Adressdaten
`GET`	`/api/customer/getVendorAddress/{id}`	Lieferantenadresse
`POST`	`/api/customer/updateAllCustomerAddressPositions`	Adressreihenfolge neu setzen
`GET`	`/api/customer/transactions/{id}`	Belege des Partners
`GET`	`/api/customer/getCustomerAttributeText/{id}`	Attributtext
`GET`	`/api/customer/generatePinCode`	PIN erzeugen
`POST`	`/api/customer/customerRating`	Bewertung, Antwort `{ "success": true }`
`GET`	`/api/customer/location`	Koordinaten nachziehen, Antwort `{ "success": true }`
`GET` / `POST`	`/api/customer/customerInfo`	Partner im Umkreis von `latitude`, `longitude`, optional `delta` in Metern
`POST`	`/api/customer/sendCustomerLoginData`	Portal-Zugangsdaten senden
`POST`	`/api/customer/registerPortalCustomer`	Portalkunde registrieren
`GET`	`/api/customer/customersByUser`	Partner des angemeldeten Benutzers
`GET`	`/api/customer/getCustomersFromPartner`	Partner eines Partners
`GET`	`/api/customer/validityForB2bSyncButton`	Ob der B2B-Abgleich angeboten wird

Diese vier Aufrufe stehen unter CRM: GET /api/customer/exportCrmActions, POST /api/customer/getImportVcfFile, POST /api/customer/getDataForVcfFileExport, POST /api/customer/crmSaveForConnector.

12.2 Adresse, Bank, Person

Methode	Pfad	Bedeutung
`GET`	`/api/customerAddress/{id}`	Eine Adresse
`GET`	`/api/customerAddress/table`	Adressliste
`POST`	`/api/customerAddress/`	Adresse speichern
`DELETE`	`/api/customerAddress/`	Adresse löschen, Body `id`
`GET`	`/api/customerBank/{id}`	Eine Bank
`POST`	`/api/customerBank/`	Bank speichern, `customer.id` Pflicht
`POST`	`/api/customerBank/checkVendorIban`	IBAN beim Lieferanten anlegen, falls fehlend
`DELETE`	`/api/customerBank/`	Banken löschen, Body `banks`
`GET`	`/api/domains/customerBank`	Bankdaten über Generic Domain lesen
`POST`	`/api/domains/customerBank`	Bankdaten über Generic Domain speichern
`DELETE`	`/api/domains/customerBank`	Bankdaten über Generic Domain löschen
`GET`	`/api/customerEmployee/{id}`	Eine Zuordnung
`GET`	`/api/customerEmployee/customerEmployeeListForCustomer/{id}`	Personen des Partners
`POST`	`/api/customerEmployee/`	Person zuordnen
`DELETE`	`/api/customerEmployee/`	Zuordnung löschen, Body `id`
`GET`	`/api/domains/customerEmployee`	Ansprechpartner-Zuordnungen über Generic Domain lesen
`POST`	`/api/domains/customerAddress`	Liefer- und Rechnungsadressen über Generic Domain speichern
`POST`	`/api/domains/customerSalesPerson`	Vertriebszuordnung über Generic Domain speichern
`GET`	`/api/domains/crmAction`	CRM-Aktivitäten zum Partner lesen
`GET` / `POST` / `DELETE`	`/api/customerSalesPerson/`	Vertriebszuordnung
`GET` / `POST` / `DELETE`	`/api/customerSalesText/`	Verkaufstexte des Partners
`GET` / `POST` / `DELETE`	`/api/customerSalesReport/`	Verkaufsberichte des Partners

13. Häufige Fehler

Situation	Ursache
`customer.not.found.error`	Id unbekannt, oder ein Lieferant soll zum Kunden werden
`customerType.not.found.error`	Keine Kunden-Kontaktart für die Umwandlung
`message.lowerDeliveryTolerance.invalid.value.error`	Toleranz unter 0 oder über 100
`message.upperDeliveryTolerance.invalid.value.error`	Überlieferung unter 0
`message.iban.empty.error`	Weder IBAN noch Konto und BLZ
`validator.customerBank.iban`	IBAN ungültig
`validator.customerBank.bic`	BIC ungültig
Bank oder Person ohne Partner	`customer.id` fehlt
`saveAddress` ohne Beleg	Weder `salesHeadId` noch `purHeadId`
Auftrag findet den Kunden nicht	`customerNo` weicht ab oder der Partner ist gelöscht
Bestellung findet den Lieferanten nicht	Kontaktart ist nicht 2 oder 3

Kunden- und Lieferantenverwaltung – Vollständige API-Referenz ​

1. Grundlagen ​

1.1 Speichern ​

1.2 Suchschlüssel ​

1.3 Antwort- und Fehlerformat ​

2. Kontaktart ​

3. Wichtige Felder ​

3.1 Partner ​

3.2 Adresse ​

3.3 Bank ​

3.4 Ansprechpartner ​

4. Lesen ​

4.1 Ein Partner ​

4.2 Liste und Lieferanten ​

4.3 Dublette vor dem Anlegen ​

5. Kunde anlegen ​

5.1 Inlandskunde ​

5.2 EU-Kunde mit E-Rechnung ​

5.3 Interessent und Umwandlung ​

6. Lieferant anlegen ​

6.1 Reiner Lieferant ​

6.2 Kunde und Lieferant ​

6.3 Lieferant mit Einkaufstoleranz und eigener Nummer ​

7. Adressen ​

7.1 Lieferadresse ​

7.2 Rechnungsadresse ​

7.3 Adresse an einen Beleg schreiben ​

8. Bank ​

8.1 Hauptbank des Kunden ​

8.2 Bank des Lieferanten ​

9. Ansprechpartner ​

9.1 Verkaufskontakt ​

9.2 Einkaufskontakt beim Lieferanten ​

9.3 Mahnkontakt ​

10. Ändern, sperren, kopieren, prüfen ​

10.1 Kreditlimit und Liefersperre ​

10.2 USt-Id prüfen ​

10.3 Kopieren ​

10.4 Löschen ​

11. Weitere Beispiele ​

11.1 Kasse ​

11.2 Adressabgleich statt Neuanlage ​

11.3 Handelsvertreter ​

11.4 Vom Interessenten zum Auftrag ​

11.5 Vom Lieferanten zur Bestellung ​

12. Endpoint-Katalog ​

12.1 Partner ​

12.2 Adresse, Bank, Person ​

13. Häufige Fehler ​

Kunden- und Lieferantenverwaltung – Vollständige API-Referenz

1. Grundlagen

1.1 Speichern

1.2 Suchschlüssel

1.3 Antwort- und Fehlerformat

2. Kontaktart

3. Wichtige Felder

3.1 Partner

3.2 Adresse

3.3 Bank

3.4 Ansprechpartner

4. Lesen

4.1 Ein Partner

4.2 Liste und Lieferanten

4.3 Dublette vor dem Anlegen

5. Kunde anlegen

5.1 Inlandskunde

5.2 EU-Kunde mit E-Rechnung

5.3 Interessent und Umwandlung

6. Lieferant anlegen

6.1 Reiner Lieferant

6.2 Kunde und Lieferant

6.3 Lieferant mit Einkaufstoleranz und eigener Nummer

7. Adressen

7.1 Lieferadresse

7.2 Rechnungsadresse

7.3 Adresse an einen Beleg schreiben

8. Bank

8.1 Hauptbank des Kunden

8.2 Bank des Lieferanten

9. Ansprechpartner

9.1 Verkaufskontakt

9.2 Einkaufskontakt beim Lieferanten

9.3 Mahnkontakt

10. Ändern, sperren, kopieren, prüfen

10.1 Kreditlimit und Liefersperre

10.2 USt-Id prüfen

10.3 Kopieren

10.4 Löschen

11. Weitere Beispiele

11.1 Kasse

11.2 Adressabgleich statt Neuanlage

11.3 Handelsvertreter

11.4 Vom Interessenten zum Auftrag

11.5 Vom Lieferanten zur Bestellung

12. Endpoint-Katalog

12.1 Partner

12.2 Adresse, Bank, Person

13. Häufige Fehler