{
"info": {
"name": "Pixi SOAP API",
"description": "Inoffizielle Collection aller SOAP-Calls von Pixi. Vor dem ersten Request die Variablen `username` und `password` (Basic Auth) setzen. Dokumentation: https://pixi-api-docs.de/de",
"schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
},
"auth": {
"type": "basic",
"basic": [
{
"key": "username",
"value": "{{username}}",
"type": "string"
},
{
"key": "password",
"value": "{{password}}",
"type": "string"
}
]
},
"variable": [
{
"key": "baseUrl",
"value": "https://apigateway.descartes.com/tms/pixi/",
"type": "string"
},
{
"key": "username",
"value": "",
"type": "string"
},
{
"key": "password",
"value": "",
"type": "string"
}
],
"item": [
{
"name": "Customers",
"item": [
{
"name": "pixiAddCustomerComment",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n K-100234\n Customer requested delivery only after 2 pm.\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt das Kommentarfeld `CHisNote` eines über die externe Kundennummer ermittelten Kunden und liefert 1 bei Erfolg bzw. 0, wenn kein Kunde gefunden wurde.\n\nSchreibt einen Kommentar in die Spalte `CHisNote` eines Kundendatensatzes.\n\n1. Die Prozedur prüft, ob in `Customers` ein Kunde mit `CustomerNrExternal` = `CustomerNrExternal` existiert.\n2. Wird `ShopID` übergeben, werden nur Kunden mit `CustomerOf` = `ShopID` berücksichtigt. Ohne `ShopID` (`NULL`) erfolgt keine Prüfung des Shops.\n3. Existiert kein passender Kunde, liefert der Aufruf eine Zeile mit `ReturnMessage` = `0`. Es wird nichts geändert.\n4. Andernfalls wird `CHisNote` **aller** passenden Kunden auf `Comment` gesetzt und der Aufruf liefert eine Zeile mit `ReturnMessage` = `1`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustomerNrExternal` | varchar(250) | Ja | Externe Kundennummer (`Customers.CustomerNrExternal`) des zu aktualisierenden Kunden. |\n| `Comment` | ntext | Ja | Kommentartext. Er ersetzt den aktuellen Inhalt von `CHisNote`. |\n| `ShopID` | varchar(3) | Nein | Optionale Shop-ID (`Customers.CustomerOf`). Wenn gesetzt, werden nur Kunden dieses Shops berücksichtigt. Bei `NULL` werden Kunden aller Shops berücksichtigt. |\n\n- Entgegen dem Namen und dem Kopfkommentar (\"manuelles Buchungsereignis anlegen\") wird kein neuer Eintrag angelegt. Der bestehende Inhalt von `CHisNote` wird **überschrieben**. Ein vorhandener Kommentar geht verloren, sofern er nicht in `Comment` mitgegeben wird.\n- Wird `ShopID` weggelassen und existiert dieselbe externe Kundennummer in mehreren Shops, wird der Kommentar bei all diesen Kunden geschrieben.\n- Die Existenzprüfung liest mit `NOLOCK`. Prüfung und Update laufen nicht in einer expliziten Transaktion.\n- Existiert der Kunde und wird `Comment` weggelassen, wird `CHisNote` auf `NULL` gesetzt, da `Comment` keinen Standardwert hat.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAddCustomerComment"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n K-100234\n Customer requested delivery only after 2 pm.\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt das Kommentarfeld `CHisNote` eines über die externe Kundennummer ermittelten Kunden und liefert 1 bei Erfolg bzw. 0, wenn kein Kunde gefunden wurde.\n\nSchreibt einen Kommentar in die Spalte `CHisNote` eines Kundendatensatzes.\n\n1. Die Prozedur prüft, ob in `Customers` ein Kunde mit `CustomerNrExternal` = `CustomerNrExternal` existiert.\n2. Wird `ShopID` übergeben, werden nur Kunden mit `CustomerOf` = `ShopID` berücksichtigt. Ohne `ShopID` (`NULL`) erfolgt keine Prüfung des Shops.\n3. Existiert kein passender Kunde, liefert der Aufruf eine Zeile mit `ReturnMessage` = `0`. Es wird nichts geändert.\n4. Andernfalls wird `CHisNote` **aller** passenden Kunden auf `Comment` gesetzt und der Aufruf liefert eine Zeile mit `ReturnMessage` = `1`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustomerNrExternal` | varchar(250) | Ja | Externe Kundennummer (`Customers.CustomerNrExternal`) des zu aktualisierenden Kunden. |\n| `Comment` | ntext | Ja | Kommentartext. Er ersetzt den aktuellen Inhalt von `CHisNote`. |\n| `ShopID` | varchar(3) | Nein | Optionale Shop-ID (`Customers.CustomerOf`). Wenn gesetzt, werden nur Kunden dieses Shops berücksichtigt. Bei `NULL` werden Kunden aller Shops berücksichtigt. |\n\n- Entgegen dem Namen und dem Kopfkommentar (\"manuelles Buchungsereignis anlegen\") wird kein neuer Eintrag angelegt. Der bestehende Inhalt von `CHisNote` wird **überschrieben**. Ein vorhandener Kommentar geht verloren, sofern er nicht in `Comment` mitgegeben wird.\n- Wird `ShopID` weggelassen und existiert dieselbe externe Kundennummer in mehreren Shops, wird der Kommentar bei all diesen Kunden geschrieben.\n- Die Existenzprüfung liest mit `NOLOCK`. Prüfung und Update laufen nicht in einer expliziten Transaktion.\n- Existiert der Kunde und wird `Comment` weggelassen, wird `CHisNote` auf `NULL` gesetzt, da `Comment` keinen Standardwert hat.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAddCustomerComment"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n \n"
}
]
},
{
"name": "pixiAddressesDisplayDuplicates",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Paare möglicherweise doppelter Kundenadressen aus der Dublettenprüfung mit Adress-, Auftrags-, Rechnungs- und Kundendaten beider Seiten.\n\nLiest die Ergebnisse einer vorher ausgeführten Dublettenprüfung aus `Addresses_Duplicates`. Jeder Datensatz dort verknüpft zwei Adressen (`AddrRef1`/`AddrRef2`) und zwei Kunden (`CustRef1`/`CustRef2`) mit einer Übereinstimmungsstufe und einem Übereinstimmungstext.\n\nFür jedes Paar liefert der Aufruf:\n- Übereinstimmungsstufe und -text,\n- Name, Firma (`CareOf`), Straße, Hausnummer, Ort, PLZ und Land beider Adressen,\n- Anzahl der Rechnungen und Datum der letzten Rechnung (`LastDelivery1`/`2`) je Kunde,\n- externe Kundennummer und DATEV-Kontonummer beider Kunden,\n- Auftragsnummer und Auftragsstatus der Aufträge, die die jeweilige Adresse verwenden,\n- `NrOfRecords`, die Gesamtzahl der nicht verwendeten Dublettendatensätze.\n\nFilter:\n- Es werden nur Datensätze mit `CustRef1` größer als `StartCustRef` geliefert. `NULL` wird als `0` behandelt.\n- Mit `ShowUsed` = `0` werden nur Datensätze geliefert, deren `UsedFlag` `0` oder `NULL` ist. Mit `ShowUsed` = `1` werden alle Datensätze geliefert, auch bereits bearbeitete.\n- `RowCount` begrenzt die Anzahl der gelieferten Zeilen über `SET ROWCOUNT`.\n\nDie Zeilen sind aufsteigend nach `CustRef1` sortiert. Zum Blättern wird der höchste gelieferte `CustRef1` als `StartCustRef` des nächsten Aufrufs übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartCustRef` | int | Nein | Es werden nur Datensätze mit `CustRef1` größer als dieser Wert geliefert. Dient zum Blättern. `NULL` wird als `0` behandelt. |\n| `ShowUsed` | bit | Nein | Legt fest, ob bereits als verwendet markierte Dublettendatensätze enthalten sind. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen (über `SET ROWCOUNT`). `0` bedeutet keine Begrenzung. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- Die Adressen werden per Inner Join mit `OrderHeader` verknüpft. Ein Paar wird nur geliefert, wenn beide Adressen von mindestens einem Auftrag verwendet werden. Ein Paar erzeugt eine Zeile je Kombination aus Aufträgen der Adresse 1 und Aufträgen der Adresse 2. Die Zeilen sind daher nicht eindeutig je Dublettendatensatz.\n- Da ein `CustRef1` mehrere Zeilen erzeugen kann, kann eine durch `RowCount` begrenzte Seite mitten in einem `CustRef1` enden. Wird mit diesem `CustRef1` als `StartCustRef` fortgesetzt, werden dessen restliche Zeilen übersprungen.\n- `RowCount` = `0` hebt die Begrenzung auf (`SET ROWCOUNT 0`).\n- `NrOfRecords` ist in jeder Zeile gleich. Gezählt werden alle nicht verwendeten Datensätze, deren beide Kunden existieren. `StartCustRef`, `ShowUsed` und die Verknüpfung mit Aufträgen werden dabei nicht berücksichtigt, daher kann der Wert von der Anzahl tatsächlich abrufbarer Zeilen abweichen.\n- `CustKeyMatchedTo` ist `NULL`, wenn `ShowUsed` = `0` ist. Andernfalls entspricht der Wert immer dem Schlüssel von Kunde 1 (`CustRef1`), da Kunde 1 per Inner Join verknüpft ist.\n- Der Aufruf zeigt nur Daten an. Er führt keine Kunden zusammen und setzt kein `UsedFlag`. Wie `Addresses_Duplicates` befüllt wird, ist aus diesem Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAddressesDisplayDuplicates"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Paare möglicherweise doppelter Kundenadressen aus der Dublettenprüfung mit Adress-, Auftrags-, Rechnungs- und Kundendaten beider Seiten.\n\nLiest die Ergebnisse einer vorher ausgeführten Dublettenprüfung aus `Addresses_Duplicates`. Jeder Datensatz dort verknüpft zwei Adressen (`AddrRef1`/`AddrRef2`) und zwei Kunden (`CustRef1`/`CustRef2`) mit einer Übereinstimmungsstufe und einem Übereinstimmungstext.\n\nFür jedes Paar liefert der Aufruf:\n- Übereinstimmungsstufe und -text,\n- Name, Firma (`CareOf`), Straße, Hausnummer, Ort, PLZ und Land beider Adressen,\n- Anzahl der Rechnungen und Datum der letzten Rechnung (`LastDelivery1`/`2`) je Kunde,\n- externe Kundennummer und DATEV-Kontonummer beider Kunden,\n- Auftragsnummer und Auftragsstatus der Aufträge, die die jeweilige Adresse verwenden,\n- `NrOfRecords`, die Gesamtzahl der nicht verwendeten Dublettendatensätze.\n\nFilter:\n- Es werden nur Datensätze mit `CustRef1` größer als `StartCustRef` geliefert. `NULL` wird als `0` behandelt.\n- Mit `ShowUsed` = `0` werden nur Datensätze geliefert, deren `UsedFlag` `0` oder `NULL` ist. Mit `ShowUsed` = `1` werden alle Datensätze geliefert, auch bereits bearbeitete.\n- `RowCount` begrenzt die Anzahl der gelieferten Zeilen über `SET ROWCOUNT`.\n\nDie Zeilen sind aufsteigend nach `CustRef1` sortiert. Zum Blättern wird der höchste gelieferte `CustRef1` als `StartCustRef` des nächsten Aufrufs übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartCustRef` | int | Nein | Es werden nur Datensätze mit `CustRef1` größer als dieser Wert geliefert. Dient zum Blättern. `NULL` wird als `0` behandelt. |\n| `ShowUsed` | bit | Nein | Legt fest, ob bereits als verwendet markierte Dublettendatensätze enthalten sind. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen (über `SET ROWCOUNT`). `0` bedeutet keine Begrenzung. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- Die Adressen werden per Inner Join mit `OrderHeader` verknüpft. Ein Paar wird nur geliefert, wenn beide Adressen von mindestens einem Auftrag verwendet werden. Ein Paar erzeugt eine Zeile je Kombination aus Aufträgen der Adresse 1 und Aufträgen der Adresse 2. Die Zeilen sind daher nicht eindeutig je Dublettendatensatz.\n- Da ein `CustRef1` mehrere Zeilen erzeugen kann, kann eine durch `RowCount` begrenzte Seite mitten in einem `CustRef1` enden. Wird mit diesem `CustRef1` als `StartCustRef` fortgesetzt, werden dessen restliche Zeilen übersprungen.\n- `RowCount` = `0` hebt die Begrenzung auf (`SET ROWCOUNT 0`).\n- `NrOfRecords` ist in jeder Zeile gleich. Gezählt werden alle nicht verwendeten Datensätze, deren beide Kunden existieren. `StartCustRef`, `ShowUsed` und die Verknüpfung mit Aufträgen werden dabei nicht berücksichtigt, daher kann der Wert von der Anzahl tatsächlich abrufbarer Zeilen abweichen.\n- `CustKeyMatchedTo` ist `NULL`, wenn `ShowUsed` = `0` ist. Andernfalls entspricht der Wert immer dem Schlüssel von Kunde 1 (`CustRef1`), da Kunde 1 per Inner Join verknüpft ist.\n- Der Aufruf zeigt nur Daten an. Er führt keine Kunden zusammen und setzt kein `UsedFlag`. Wie `Addresses_Duplicates` befüllt wird, ist aus diesem Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAddressesDisplayDuplicates"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n Name, Street, ZIP\n 1024\n 5511\n Anna\n Müller\n \n Hauptstraße\n 12\n Berlin\n 10115\n DE\n 2048\n 8830\n Anna\n Mueller\n \n Hauptstr.\n 12\n Berlin\n 10115\n DE\n 3\n 1\n 2024-03-11T10:15:00\n 2024-05-02T08:40:00\n SHOP-1024\n SHOP-2048\n 57\n 300112\n AU\n 300987\n AU\n 10024\n 10048\n \n"
}
]
},
{
"name": "pixiAddressesDisplayDuplicatesMarkUsed",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10452\n 10987\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Markiert ein gespeichertes Paar möglicher Kundendubletten als verwendet, indem `UsedFlag` = 1 in der Dublettenliste gesetzt wird.\n\nMarkiert einen Eintrag der Adress-Dublettenliste (`Addresses_Duplicates`) als verwendet.\n\n1. Es wird geprüft, ob mindestens eine Zeile mit `CustRef1` = `@CustRef1` und `CustRef2` = `@CustRef2` existiert.\n2. Existiert keine solche Zeile, wird eine Statuszeile mit `ReturnCode` = `ERROR` geliefert und nichts geändert.\n3. Andernfalls wird `UsedFlag` bei **allen** Zeilen dieses Paares auf `1` gesetzt und eine Statuszeile mit `ReturnCode` = `OK` geliefert.\n\nDas Paar wird exakt in der übergebenen Reihenfolge gesucht: `CustRef1`/`CustRef2` werden nicht vertauscht, ein als (B, A) gespeichertes Paar wird bei Aufruf mit (A, B) also nicht gefunden.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustRef1` | int | Ja | Referenz des ersten Kunden des Dublettenpaares, verglichen mit `Addresses_Duplicates.CustRef1`. |\n| `CustRef2` | int | Ja | Referenz des zweiten Kunden des Dublettenpaares, verglichen mit `Addresses_Duplicates.CustRef2`. |\n\n- Die Existenzprüfung liest mit `NOLOCK`; Prüfung und Update laufen nicht in einer Transaktion.\n- Der Fehlertext \"At least one customers not existing\" ist irreführend: Er erscheint, wenn das Dublettenpaar nicht in `Addresses_Duplicates` vorhanden ist, nicht nach einer Prüfung der Kundentabelle.\n- Ein erneuter Aufruf für ein bereits markiertes Paar liefert wieder `OK` (idempotent).\n- Der Statustext steht immer in der Spalte `ErrorMessage`, auch bei Erfolg.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAddressesDisplayDuplicatesMarkUsed"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10452\n 10987\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Markiert ein gespeichertes Paar möglicher Kundendubletten als verwendet, indem `UsedFlag` = 1 in der Dublettenliste gesetzt wird.\n\nMarkiert einen Eintrag der Adress-Dublettenliste (`Addresses_Duplicates`) als verwendet.\n\n1. Es wird geprüft, ob mindestens eine Zeile mit `CustRef1` = `@CustRef1` und `CustRef2` = `@CustRef2` existiert.\n2. Existiert keine solche Zeile, wird eine Statuszeile mit `ReturnCode` = `ERROR` geliefert und nichts geändert.\n3. Andernfalls wird `UsedFlag` bei **allen** Zeilen dieses Paares auf `1` gesetzt und eine Statuszeile mit `ReturnCode` = `OK` geliefert.\n\nDas Paar wird exakt in der übergebenen Reihenfolge gesucht: `CustRef1`/`CustRef2` werden nicht vertauscht, ein als (B, A) gespeichertes Paar wird bei Aufruf mit (A, B) also nicht gefunden.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustRef1` | int | Ja | Referenz des ersten Kunden des Dublettenpaares, verglichen mit `Addresses_Duplicates.CustRef1`. |\n| `CustRef2` | int | Ja | Referenz des zweiten Kunden des Dublettenpaares, verglichen mit `Addresses_Duplicates.CustRef2`. |\n\n- Die Existenzprüfung liest mit `NOLOCK`; Prüfung und Update laufen nicht in einer Transaktion.\n- Der Fehlertext \"At least one customers not existing\" ist irreführend: Er erscheint, wenn das Dublettenpaar nicht in `Addresses_Duplicates` vorhanden ist, nicht nach einer Prüfung der Kundentabelle.\n- Ein erneuter Aufruf für ein bereits markiertes Paar liefert wieder `OK` (idempotent).\n- Der Statustext steht immer in der Spalte `ErrorMessage`, auch bei Erfolg.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAddressesDisplayDuplicatesMarkUsed"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n Record marked as used\n \n"
}
]
},
{
"name": "pixiAddressesFindDuplicates",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ermittelt wahrscheinliche Kundendubletten per unscharfem Adressabgleich in Blöcken von 2500 Adressen und speichert bewertete Kundenpaare in Addresses_Duplicates.\n\nBatch-Job, der Kundendubletten durch Vergleich der Adressen erkennt. Es wird keine Ergebnismenge geliefert. Die Ergebnisse werden in die Tabelle `Addresses_Duplicates` geschrieben.\n\n**Zeitfenster**\n\nDie Prozedur arbeitet nur zwischen 21:00 und 06:59 Uhr Serverzeit. Liegt die aktuelle Stunde zwischen 7 und 20, wird eine Meldung ausgegeben und die Prozedur ohne weitere Aktion beendet. Einzige Ausnahme ist eine Session mit `CONTEXT_INFO` = `0x00999`, die für Unit-Tests verwendet wird.\n\n**Ablauf**\n\n1. Legt die Hilfstabellen `tmp.Addresses_Process` und `tmp.Addresses_Simple` an, falls sie noch nicht existieren.\n2. Bei `ReCreateAll` = 1 werden `Addresses_Duplicates`, `tmp.Addresses_Simple` und `tmp.Addresses_Process` per `TRUNCATE` geleert. Alle bisherigen Treffer werden gelöscht.\n3. Wählt bis zu 2500 Kunden-Hauptadressen (`Customers.AddrRef`) als Kandidaten aus, neueste Adressnummer zuerst. Ein Kandidat muss alle folgenden Bedingungen erfüllen:\n - Er ist noch nicht in `tmp.Addresses_Simple` enthalten.\n - Seine Nummer liegt über der höchsten oder unter der niedrigsten bereits verarbeiteten Nummer.\n - Der Kunde hat keinen Auftrag mit einem Auftragskopf-Attribut vom Typ 3 (archivierte Aufträge).\n4. Entfernt Titel aus den Namen: `Frau`, `Herr`, `Prof.`, `Dipl.`, `Ing.`, `Mag.`, `med.`, `Dr.`. Ist der Nachname leer, wird das Feld `Name` am ersten Leerzeichen in Vor- und Nachname aufgeteilt.\n5. Speichert eine vereinfachte Kopie jeder Adresse in `tmp.Addresses_Simple`:\n - die ersten 3 Zeichen von `SOUNDEX` für Straße, Ort, Nachname, Vorname und CareOf (Firma);\n - die Quersumme der PLZ (`fCrossSum`);\n - Adress-, Kunden- und Shop-ID.\n6. Markiert bis zu 2500 dieser Adressen in `tmp.Addresses_Process` als verarbeitet, neueste zuerst.\n7. Vergleicht die neu verarbeiteten Adressen mit allen vereinfachten Adressen. Ein Paar gilt als Treffer, wenn alle folgenden Bedingungen erfüllt sind:\n - anderer Kunde;\n - gleicher Shop;\n - gleicher Soundex-Code für Ort, Straße und CareOf;\n - gleiche PLZ-Quersumme;\n - gleiche Soundex-Codes für Vor- und Nachname, auch bei vertauschtem Vor- und Nachnamen.\n\n Ein Kunde wird übersprungen, wenn er bereits als `CustRef1` oder `CustRef2` in `Addresses_Duplicates` vorkommt.\n8. Vergibt für jedes Paar eine Punktzahl (`MatchLevel`). Sie ergibt sich als Summe dieser Teile:\n - Name: 40 vollständig, 30 vertauscht, 20 Soundex-Treffer, 10 schwacher Treffer oder abweichender Vorname;\n - Straße: 20 vollständig, 10 teilweise, 5 schwach;\n - Ort: 20 vollständig, 10 teilweise, 5 schwach;\n - PLZ: 20 vollständig, 10 gleiche Quersumme;\n - Firma (CareOf): 0 vollständig, -10 teilweise, -15 schwach.\n\n `MatchText` enthält die nicht vollständigen Treffer-Kennzeichen, z. B. `STREET_PARTIAL_MATCH;`, gekürzt auf 100 Zeichen.\n9. Fügt jedes neue Paar einmal ein. `CustRef1`/`AddrRef1` ist der neu verarbeitete Kunde, `CustRef2`/`AddrRef2` der gefundene Kunde. Bereits vorhandene Paare werden in beiden Richtungen übersprungen.\n10. Enthält `tmp.Addresses_Simple` noch Adressen, die nicht in `tmp.Addresses_Process` stehen, stellt die Prozedur `EXEC pipiAddressesFindDuplicates` in `ExecQueries` ein. So wird der Lauf im nächsten Block fortgesetzt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ReCreateAll` | bit | Nein | Bei 1 werden alle vorhandenen Dublettentreffer und die Fortschrittstabellen gelöscht, und der Abgleich beginnt von vorn. Dies wirkt nur innerhalb des nächtlichen Zeitfensters. |\n\n- **Keine Ergebnismenge:** Der Aufruf liefert keine Zeilen. Informative Ausgaben erfolgen nur per `PRINT`, z. B. `RUN BEFORE 07:00 or AFTER 20:00` tagsüber. Diese Meldungen erscheinen je nach Client als `SqlMessage`. Ein Aufruf tagsüber wirkt daher erfolgreich, bewirkt aber nichts.\n- **ReCreateAll tagsüber:** Das Leeren bei `ReCreateAll` = 1 erfolgt erst nach der Zeitprüfung. Tagsüber hat der Parameter keine Wirkung.\n- **Fortsetzung:** Der Folgelauf wird in `ExecQueries` eingestellt. Wie und wann diese Warteschlange ausgeführt wird, ist nicht Teil dieses Codes. Ein Kommentar nennt \"1 Minute\" sowie Läufe bis 7 Uhr. Die Blockgröße beträgt 2500 Adressen, obwohl ein Kommentar 100 erwähnt.\n- **Permanente Hilfstabellen:** Die Prozedur legt die permanenten Tabellen `tmp.Addresses_Simple` und `tmp.Addresses_Process` an und befüllt sie, um den Fortschritt zwischen den Läufen festzuhalten.\n- **Keine Transaktion:** Alle Lesezugriffe verwenden `NOLOCK`, eine explizite Transaktion gibt es nicht.\n- **Im Code erkennbare Fallstricke:**\n - Die Teilprüfung für Straße und Ort vergleicht eine Adresse mit sich selbst. Stimmen Straße oder Ort nicht exakt überein, ergibt sich daher immer `STREET_PARTIAL_MATCH;` bzw. `CITY_PARTIAL_MATCH;`. Die `_LOW`-Varianten treten nie auf.\n - Die Paare werden je Summe der beiden Kunden-IDs (`s.CustRef + c.CustRef`) nummeriert. Verschiedene Paare mit gleicher ID-Summe können daher entfallen, weil nur das erste übernommen wird.\n - Stimmen die Namen nur vertauscht per Soundex überein, aber nicht exakt vertauscht, bleibt die Namenskategorie leer. `MatchLevel` und `MatchText` werden dann NULL.\n- **Laufzeit:** Der Abgleich ist rechenintensiv. Ein Code-Kommentar warnt davor, die Blockgröße zu erhöhen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAddressesFindDuplicates"
},
"response": []
},
{
"name": "pixiCAGetCustomerEvents",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Kundenkonto-Ereignisse (Buchungen, inklusive gelöschter) eines Kunden zusammen mit den Kontostatistiken wie Saldo und vorgeschlagener Erstattung.\n\nListet das Kundenkonto eines Kunden auf.\n\n**Kunde bestimmen**\n- Entweder `CustRef` (interner Kundenschlüssel) übergeben **oder**\n- `ShopID` und `CustNrExt` (externe Kundennummer im Shop) gemeinsam übergeben. Die Prozedur ermittelt dann `CustKey` aus `Customers` über `CustomerOf` = `ShopID` und `CustomerNrExternal` = `CustNrExt`.\n- Ist `CustRef` leer oder 0 und fehlt `ShopID` oder `CustNrExt`, wird ein Fehler ausgelöst.\n- Ist `CustRef` angegeben, werden `ShopID` und `CustNrExt` ignoriert.\n\n**Ereignisse**\nAlle Kontoereignisse des Kunden werden ohne Filter gesammelt (Übersetzungen in Sprache 1):\n- aktive Buchungen aus `CustomerAccount` (`IsDeleted` = 0),\n- gelöschte Buchungen aus `CustomerAccountLog` mit Historienvermerk `DELETE` (`IsDeleted` = 1).\n\n`Number` enthält je nach Bezug des Ereignisses die Rechnungsnummer, den Bankzeilentext, die Kontonummer der Lastschrift oder die Referenz der manuellen Buchung. `OpenTOMatch` ist `Amount` abzüglich des ausgeglichenen Betrags.\n\n**Statistik**\nDie Kontostatistik (Saldo, offene Aufträge, vorgeschlagene Erstattung, Ausgleichs-Kennzeichen, Kontowährung) wird pro Kunde berechnet und an jede Ereigniszeile angehängt.\n\n**Ergebnis**\nEine Zeile pro Ereignis mit jeweils denselben Statistikspalten. Hat der Kunde keine Ereignisse, wird eine einzelne Zeile geliefert, in der nur die Statistikspalten gefüllt sind (Ereignisspalten einschließlich `CustRef` sind NULL).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustRef` | int | Nein | Interner Kundenschlüssel (`CustKey`). Wenn angegeben (nicht 0), hat er Vorrang vor `ShopID`/`CustNrExt`. |\n| `CustNrExt` | varchar(60) | Nein | Externe Kundennummer (`CustomerNrExternal`). Wird nur zusammen mit `ShopID` verwendet, wenn `CustRef` fehlt. |\n| `ShopID` | varchar(3) | Nein | Shop, zu dem der Kunde gehört (`CustomerOf`). Wird nur zusammen mit `CustNrExt` verwendet, wenn `CustRef` fehlt. |\n\n- Nur lesend; alle permanenten Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können erscheinen.\n- Das abschließende `SELECT` hat kein `ORDER BY`; die Hilfsprozedur liefert die Ereignisse aufsteigend nach `EventDate`, die Reihenfolge der zurückgegebenen Zeilen ist aber nicht garantiert.\n- Passen `ShopID`/`CustNrExt` zu keinem Kunden, wird kein Kundenschlüssel gefunden; das Ergebnis hängt dann von der Prozedur `Pixi_CA_GetCustomerAccountSummary` (nicht beigefügt) ab und ist in der Regel leer.\n- Die temporäre Statistiktabelle hat einen eindeutigen Index auf `CustRef`. Liefert die Zusammenfassung mehr als eine Zeile pro Kunde (z. B. mehrere Währungen), schlägt das Einfügen mit einem Duplicate-Key-Fehler fehl.\n- Die Spalte `DoNotRefund` ist das Kennzeichen des einzelnen Ereignisses, nicht die Summe aus der Statistik.\n- Die Währungsumrechnung der Statistik hängt von der Einstellung `MultiCurrencyEnabled` ab; `AccountCurrencyCode` kann Auftrags- oder Basiswährung sein.\n- Die Spaltennamen `IsAcountMatched` und `SuggestedRefound` sind genau so geschrieben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCAGetCustomerEvents"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Kundenkonto-Ereignisse (Buchungen, inklusive gelöschter) eines Kunden zusammen mit den Kontostatistiken wie Saldo und vorgeschlagener Erstattung.\n\nListet das Kundenkonto eines Kunden auf.\n\n**Kunde bestimmen**\n- Entweder `CustRef` (interner Kundenschlüssel) übergeben **oder**\n- `ShopID` und `CustNrExt` (externe Kundennummer im Shop) gemeinsam übergeben. Die Prozedur ermittelt dann `CustKey` aus `Customers` über `CustomerOf` = `ShopID` und `CustomerNrExternal` = `CustNrExt`.\n- Ist `CustRef` leer oder 0 und fehlt `ShopID` oder `CustNrExt`, wird ein Fehler ausgelöst.\n- Ist `CustRef` angegeben, werden `ShopID` und `CustNrExt` ignoriert.\n\n**Ereignisse**\nAlle Kontoereignisse des Kunden werden ohne Filter gesammelt (Übersetzungen in Sprache 1):\n- aktive Buchungen aus `CustomerAccount` (`IsDeleted` = 0),\n- gelöschte Buchungen aus `CustomerAccountLog` mit Historienvermerk `DELETE` (`IsDeleted` = 1).\n\n`Number` enthält je nach Bezug des Ereignisses die Rechnungsnummer, den Bankzeilentext, die Kontonummer der Lastschrift oder die Referenz der manuellen Buchung. `OpenTOMatch` ist `Amount` abzüglich des ausgeglichenen Betrags.\n\n**Statistik**\nDie Kontostatistik (Saldo, offene Aufträge, vorgeschlagene Erstattung, Ausgleichs-Kennzeichen, Kontowährung) wird pro Kunde berechnet und an jede Ereigniszeile angehängt.\n\n**Ergebnis**\nEine Zeile pro Ereignis mit jeweils denselben Statistikspalten. Hat der Kunde keine Ereignisse, wird eine einzelne Zeile geliefert, in der nur die Statistikspalten gefüllt sind (Ereignisspalten einschließlich `CustRef` sind NULL).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustRef` | int | Nein | Interner Kundenschlüssel (`CustKey`). Wenn angegeben (nicht 0), hat er Vorrang vor `ShopID`/`CustNrExt`. |\n| `CustNrExt` | varchar(60) | Nein | Externe Kundennummer (`CustomerNrExternal`). Wird nur zusammen mit `ShopID` verwendet, wenn `CustRef` fehlt. |\n| `ShopID` | varchar(3) | Nein | Shop, zu dem der Kunde gehört (`CustomerOf`). Wird nur zusammen mit `CustNrExt` verwendet, wenn `CustRef` fehlt. |\n\n- Nur lesend; alle permanenten Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können erscheinen.\n- Das abschließende `SELECT` hat kein `ORDER BY`; die Hilfsprozedur liefert die Ereignisse aufsteigend nach `EventDate`, die Reihenfolge der zurückgegebenen Zeilen ist aber nicht garantiert.\n- Passen `ShopID`/`CustNrExt` zu keinem Kunden, wird kein Kundenschlüssel gefunden; das Ergebnis hängt dann von der Prozedur `Pixi_CA_GetCustomerAccountSummary` (nicht beigefügt) ab und ist in der Regel leer.\n- Die temporäre Statistiktabelle hat einen eindeutigen Index auf `CustRef`. Liefert die Zusammenfassung mehr als eine Zeile pro Kunde (z. B. mehrere Währungen), schlägt das Einfügen mit einem Duplicate-Key-Fehler fehl.\n- Die Spalte `DoNotRefund` ist das Kennzeichen des einzelnen Ereignisses, nicht die Summe aus der Statistik.\n- Die Währungsumrechnung der Statistik hängt von der Einstellung `MultiCurrencyEnabled` ab; `AccountCurrencyCode` kann Auftrags- oder Basiswährung sein.\n- Die Spaltennamen `IsAcountMatched` und `SuggestedRefound` sind genau so geschrieben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCAGetCustomerEvents"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n 2024-03-04T10:15:00\n INV\n RE-2024-00871\n Order 55120\n -119.0000\n 0.0000\n false\n EUR\n true\n 0.0000\n 0.0000\n 0.0000\n false\n EUR\n \n \n 10452\n 2024-03-06T08:02:00\n BNK\n Payment 55120\n K-200381 Order 55120\n 119.0000\n 0.0000\n false\n EUR\n true\n 0.0000\n 0.0000\n 0.0000\n false\n EUR\n \n"
}
]
},
{
"name": "pixiCustomerInfoSet",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Rechnungszahlungsziel und Mahneinstellungen eines Kunden, identifiziert über CustKey oder externe Kundennummer/E-Mail plus Shop.\n\nÄndert die Zahlungs- und Mahneinstellungen genau eines Kundendatensatzes in `Customers`.\n\n**Identifikation des Kunden**\n\n- Entweder `CustKey` übergeben **oder** `ShopId` zusammen mit `CustomerNrExternal` und/oder `CustomerEmail`.\n- `CustomerNrExternal`, `CustomerEmail` und `ReminderAction` werden getrimmt; leere Zeichenketten gelten als nicht angegeben.\n- Gesucht werden Kunden, bei denen (`CustomerNrExternal` übereinstimmt **oder** `CeMail` mit `CustomerEmail` übereinstimmt) und `CustomerOf` = `ShopId` ist, **oder** bei denen `CustKey` übereinstimmt.\n- Wird kein Kunde oder mehr als ein Kunde gefunden, schlägt der Aufruf fehl.\n\n**Prüfungen**\n\n- `ReminderAction` muss einer der Werte `NONE`, `PRINT`, `MAIL`, `PRINT&MAIL` oder `0` sein.\n- `InvoiceDueDays`, `DaysForFirstReminder`, `DaysForNextReminder`, `ReminderDueDays` und `ReminderCost` dürfen nicht negativ sein.\n\n**Übernahme der Werte**\n\n- Ein weggelassener Parameter (NULL) behält den aktuell gespeicherten Wert des Kunden.\n- Der Wert `0` (bzw. `'0'` bei `ReminderAction`) löscht die Einstellung, d. h. sie wird als NULL gespeichert (Option deaktiviert).\n- Jeder andere Wert überschreibt den gespeicherten Wert.\n\nZusätzlich werden `UpdateDate` auf das aktuelle Datum/Uhrzeit und `UpdateEmp` auf `API-CustomerInfoSet` gesetzt.\n\nDer Aufruf liefert immer eine Statuszeile mit `Status` (`OK` oder `ERROR`) und `StatusMessage`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Nein | Interner Pixi-Kundenschlüssel. Identifiziert den Kunden allein; alternativ `ShopId` mit `CustomerNrExternal`/`CustomerEmail` verwenden. |\n| `CustomerNrExternal` | varchar(60) | Nein | Externe (Shop-)Kundennummer, abgeglichen mit `CustomerNrExternal` der Kunden von `ShopId`. Wird getrimmt; leer gilt als nicht angegeben. |\n| `CustomerEmail` | varchar(256) | Nein | E-Mail-Adresse des Kunden, abgeglichen mit `CeMail` der Kunden von `ShopId`. Wird getrimmt; leer gilt als nicht angegeben. |\n| `ShopId` | varchar(3) | Nein | Shop, zu dem der Kunde gehört (`CustomerOf`). Erforderlich, wenn der Kunde über `CustomerNrExternal` oder `CustomerEmail` identifiziert wird. |\n| `InvoiceDueDays` | smallint | Nein | Zahlungsziel von Rechnungen in Tagen. NULL behält den aktuellen Wert, 0 löscht ihn, negative Werte werden abgelehnt. |\n| `ReminderAction` | varchar(20) | Nein | Art des Mahnversands an den Kunden. NULL oder leer behält den aktuellen Wert. |\n| `DaysForFirstReminder` | smallint | Nein | Tage bis zur ersten Mahnung. NULL behält den aktuellen Wert, 0 löscht ihn, negative Werte werden abgelehnt. |\n| `DaysForNextReminder` | smallint | Nein | Tage bis zur nächsten Mahnung. NULL behält den aktuellen Wert, 0 löscht ihn, negative Werte werden abgelehnt. |\n| `ReminderDueDays` | smallint | Nein | Zahlungsfrist auf Mahnungen in Tagen. NULL behält den aktuellen Wert, 0 löscht ihn, negative Werte werden abgelehnt. |\n| `ReminderCost` | money | Nein | Mahngebühr pro Mahnung. NULL behält den aktuellen Wert, 0 löscht ihn (als NULL gespeichert), negative Werte werden abgelehnt. |\n\n- Alle Prüffehler werden innerhalb eines `TRY`-Blocks ausgelöst und abgefangen; sie werden als Statuszeile mit `Status` = `ERROR` zurückgegeben, nicht als `SqlMessage`. Gemeldet wird nur die erste fehlgeschlagene Prüfung.\n- Der Rückgabewert der Prozedur ist `0` bei Erfolg und `1` bei Fehler; SOAP-Clients sollten die Spalte `Status` auswerten.\n- Die Kandidatensuche liest `Customers` mit `NOLOCK`. Suche und Update laufen nicht in einer expliziten Transaktion.\n- Stolperfalle: Die Suchbedingungen sind mit `OR` verknüpft. Wird `CustKey` zusammen mit `ShopId` und `CustomerNrExternal`/`CustomerEmail` übergeben oder verweisen `CustomerNrExternal` und `CustomerEmail` auf verschiedene Kunden, können mehrere Datensätze gefunden werden und der Aufruf scheitert mit \"More than one customer found\". Für ein eindeutiges Ergebnis nur ein Identifikationsmerkmal übergeben.\n- `ShopId` wird im Gegensatz zu den anderen Identifikationsmerkmalen nicht getrimmt.\n- Bei `ReminderAction` unterscheiden sich `NONE` und `0`: `NONE` speichert den Wert `NONE`, `0` speichert NULL. Ob die Werteprüfung Groß-/Kleinschreibung beachtet, hängt von der Datenbank-Collation ab.\n- Ein `ReminderCost` von `0` wird als NULL gespeichert; Mahnkosten von genau null lassen sich daher nicht explizit hinterlegen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCustomerInfoSet"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Rechnungszahlungsziel und Mahneinstellungen eines Kunden, identifiziert über CustKey oder externe Kundennummer/E-Mail plus Shop.\n\nÄndert die Zahlungs- und Mahneinstellungen genau eines Kundendatensatzes in `Customers`.\n\n**Identifikation des Kunden**\n\n- Entweder `CustKey` übergeben **oder** `ShopId` zusammen mit `CustomerNrExternal` und/oder `CustomerEmail`.\n- `CustomerNrExternal`, `CustomerEmail` und `ReminderAction` werden getrimmt; leere Zeichenketten gelten als nicht angegeben.\n- Gesucht werden Kunden, bei denen (`CustomerNrExternal` übereinstimmt **oder** `CeMail` mit `CustomerEmail` übereinstimmt) und `CustomerOf` = `ShopId` ist, **oder** bei denen `CustKey` übereinstimmt.\n- Wird kein Kunde oder mehr als ein Kunde gefunden, schlägt der Aufruf fehl.\n\n**Prüfungen**\n\n- `ReminderAction` muss einer der Werte `NONE`, `PRINT`, `MAIL`, `PRINT&MAIL` oder `0` sein.\n- `InvoiceDueDays`, `DaysForFirstReminder`, `DaysForNextReminder`, `ReminderDueDays` und `ReminderCost` dürfen nicht negativ sein.\n\n**Übernahme der Werte**\n\n- Ein weggelassener Parameter (NULL) behält den aktuell gespeicherten Wert des Kunden.\n- Der Wert `0` (bzw. `'0'` bei `ReminderAction`) löscht die Einstellung, d. h. sie wird als NULL gespeichert (Option deaktiviert).\n- Jeder andere Wert überschreibt den gespeicherten Wert.\n\nZusätzlich werden `UpdateDate` auf das aktuelle Datum/Uhrzeit und `UpdateEmp` auf `API-CustomerInfoSet` gesetzt.\n\nDer Aufruf liefert immer eine Statuszeile mit `Status` (`OK` oder `ERROR`) und `StatusMessage`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Nein | Interner Pixi-Kundenschlüssel. Identifiziert den Kunden allein; alternativ `ShopId` mit `CustomerNrExternal`/`CustomerEmail` verwenden. |\n| `CustomerNrExternal` | varchar(60) | Nein | Externe (Shop-)Kundennummer, abgeglichen mit `CustomerNrExternal` der Kunden von `ShopId`. Wird getrimmt; leer gilt als nicht angegeben. |\n| `CustomerEmail` | varchar(256) | Nein | E-Mail-Adresse des Kunden, abgeglichen mit `CeMail` der Kunden von `ShopId`. Wird getrimmt; leer gilt als nicht angegeben. |\n| `ShopId` | varchar(3) | Nein | Shop, zu dem der Kunde gehört (`CustomerOf`). Erforderlich, wenn der Kunde über `CustomerNrExternal` oder `CustomerEmail` identifiziert wird. |\n| `InvoiceDueDays` | smallint | Nein | Zahlungsziel von Rechnungen in Tagen. NULL behält den aktuellen Wert, 0 löscht ihn, negative Werte werden abgelehnt. |\n| `ReminderAction` | varchar(20) | Nein | Art des Mahnversands an den Kunden. NULL oder leer behält den aktuellen Wert. |\n| `DaysForFirstReminder` | smallint | Nein | Tage bis zur ersten Mahnung. NULL behält den aktuellen Wert, 0 löscht ihn, negative Werte werden abgelehnt. |\n| `DaysForNextReminder` | smallint | Nein | Tage bis zur nächsten Mahnung. NULL behält den aktuellen Wert, 0 löscht ihn, negative Werte werden abgelehnt. |\n| `ReminderDueDays` | smallint | Nein | Zahlungsfrist auf Mahnungen in Tagen. NULL behält den aktuellen Wert, 0 löscht ihn, negative Werte werden abgelehnt. |\n| `ReminderCost` | money | Nein | Mahngebühr pro Mahnung. NULL behält den aktuellen Wert, 0 löscht ihn (als NULL gespeichert), negative Werte werden abgelehnt. |\n\n- Alle Prüffehler werden innerhalb eines `TRY`-Blocks ausgelöst und abgefangen; sie werden als Statuszeile mit `Status` = `ERROR` zurückgegeben, nicht als `SqlMessage`. Gemeldet wird nur die erste fehlgeschlagene Prüfung.\n- Der Rückgabewert der Prozedur ist `0` bei Erfolg und `1` bei Fehler; SOAP-Clients sollten die Spalte `Status` auswerten.\n- Die Kandidatensuche liest `Customers` mit `NOLOCK`. Suche und Update laufen nicht in einer expliziten Transaktion.\n- Stolperfalle: Die Suchbedingungen sind mit `OR` verknüpft. Wird `CustKey` zusammen mit `ShopId` und `CustomerNrExternal`/`CustomerEmail` übergeben oder verweisen `CustomerNrExternal` und `CustomerEmail` auf verschiedene Kunden, können mehrere Datensätze gefunden werden und der Aufruf scheitert mit \"More than one customer found\". Für ein eindeutiges Ergebnis nur ein Identifikationsmerkmal übergeben.\n- `ShopId` wird im Gegensatz zu den anderen Identifikationsmerkmalen nicht getrimmt.\n- Bei `ReminderAction` unterscheiden sich `NONE` und `0`: `NONE` speichert den Wert `NONE`, `0` speichert NULL. Ob die Werteprüfung Groß-/Kleinschreibung beachtet, hängt von der Datenbank-Collation ab.\n- Ein `ReminderCost` von `0` wird als NULL gespeichert; Mahnkosten von genau null lassen sich daher nicht explizit hinterlegen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCustomerInfoSet"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n Record successfully updated\n \n"
}
]
},
{
"name": "pixiCustomerKeyByEmail",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n max.mustermann@example.com\n SHP\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Kundenschlüssel (`CustKey`) des Kunden eines Shops, dessen primäre oder sekundäre E-Mail-Adresse der angegebenen Adresse entspricht.\n\nSucht einen Kunden anhand der E-Mail-Adresse innerhalb eines Shops und liefert dessen internen Schlüssel als einzelnen Integer-Wert.\n\n- Ein Kunde passt, wenn `@eMail` entweder dem Feld `eMail` oder dem Feld `eMail2` entspricht und der Kunde zum Shop `@ShopId` gehört (`CustomerOf`).\n- Es können nur Kunden zurückgegeben werden, die mindestens einen Adressdatensatz besitzen (`Addresses.AdrCustRef = CustKey`), da die Suche einen Inner Join auf die Adressen verwendet.\n- Mit `@AllowAmbiguous = 0` (Standard) wird nur dann ein Schlüssel geliefert, wenn **genau ein** Kunde im Shop diese E-Mail-Adresse hat. Teilen sich mehrere Kunden die Adresse, ist das Ergebnis `NULL`.\n- Mit `@AllowAmbiguous = 1` entfällt die Eindeutigkeitsprüfung, und der Schlüssel eines der passenden Kunden wird geliefert.\n- Passt kein Kunde, ist das Ergebnis `NULL`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `eMail` | varchar(60) | Ja | Gesuchte E-Mail-Adresse; wird mit den Feldern `eMail` und `eMail2` des Kunden verglichen. |\n| `ShopId` | char(3) | Ja | Shop-ID, zu der der Kunde gehören muss (`CustomerOf`). |\n| `AllowAmbiguous` | bit | Nein | Steuert, ob ein Schlüssel geliefert wird, wenn sich mehrere Kunden des Shops die E-Mail-Adresse teilen. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, es können also nicht festgeschriebene Daten gelesen werden.\n- Bei `@AllowAmbiguous = 1` und mehreren Treffern erfolgt die Auswahl per `TOP 1` ohne `ORDER BY`; welcher Kunde geliefert wird, ist nicht deterministisch.\n- Die Eindeutigkeitszählung berücksichtigt nur die Tabelle `Customers`, nicht den Join auf die Adressen. Ein einzelner passender Kunde ohne Adresse ergibt daher `NULL`.\n- `NULL` wird sowohl für „nicht gefunden“ als auch für „mehrdeutig“ geliefert; beide Fälle sind am Ergebnis allein nicht unterscheidbar. Ein erneuter Aufruf mit `AllowAmbiguous = 1` zeigt, ob überhaupt Treffer existieren.\n- Ob der Vergleich Groß-/Kleinschreibung beachtet, hängt von der Datenbank-Collation ab; die E-Mail-Adresse wird weder getrimmt noch normalisiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCustomerKeyByEmail"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n max.mustermann@example.com\n SHP\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Kundenschlüssel (`CustKey`) des Kunden eines Shops, dessen primäre oder sekundäre E-Mail-Adresse der angegebenen Adresse entspricht.\n\nSucht einen Kunden anhand der E-Mail-Adresse innerhalb eines Shops und liefert dessen internen Schlüssel als einzelnen Integer-Wert.\n\n- Ein Kunde passt, wenn `@eMail` entweder dem Feld `eMail` oder dem Feld `eMail2` entspricht und der Kunde zum Shop `@ShopId` gehört (`CustomerOf`).\n- Es können nur Kunden zurückgegeben werden, die mindestens einen Adressdatensatz besitzen (`Addresses.AdrCustRef = CustKey`), da die Suche einen Inner Join auf die Adressen verwendet.\n- Mit `@AllowAmbiguous = 0` (Standard) wird nur dann ein Schlüssel geliefert, wenn **genau ein** Kunde im Shop diese E-Mail-Adresse hat. Teilen sich mehrere Kunden die Adresse, ist das Ergebnis `NULL`.\n- Mit `@AllowAmbiguous = 1` entfällt die Eindeutigkeitsprüfung, und der Schlüssel eines der passenden Kunden wird geliefert.\n- Passt kein Kunde, ist das Ergebnis `NULL`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `eMail` | varchar(60) | Ja | Gesuchte E-Mail-Adresse; wird mit den Feldern `eMail` und `eMail2` des Kunden verglichen. |\n| `ShopId` | char(3) | Ja | Shop-ID, zu der der Kunde gehören muss (`CustomerOf`). |\n| `AllowAmbiguous` | bit | Nein | Steuert, ob ein Schlüssel geliefert wird, wenn sich mehrere Kunden des Shops die E-Mail-Adresse teilen. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, es können also nicht festgeschriebene Daten gelesen werden.\n- Bei `@AllowAmbiguous = 1` und mehreren Treffern erfolgt die Auswahl per `TOP 1` ohne `ORDER BY`; welcher Kunde geliefert wird, ist nicht deterministisch.\n- Die Eindeutigkeitszählung berücksichtigt nur die Tabelle `Customers`, nicht den Join auf die Adressen. Ein einzelner passender Kunde ohne Adresse ergibt daher `NULL`.\n- `NULL` wird sowohl für „nicht gefunden“ als auch für „mehrdeutig“ geliefert; beide Fälle sind am Ergebnis allein nicht unterscheidbar. Ein erneuter Aufruf mit `AllowAmbiguous = 1` zeigt, ob überhaupt Treffer existieren.\n- Ob der Vergleich Groß-/Kleinschreibung beachtet, hängt von der Datenbank-Collation ab; die E-Mail-Adresse wird weder getrimmt noch normalisiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCustomerKeyByEmail"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n \n"
}
]
},
{
"name": "pixiCustomerKeyByNumber",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n WEB-100245\n SHP\n 0\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den internen Kundenschlüssel (CustKey) zu einer externen Kundennummer innerhalb eines Shops.\n\nSucht einen Kunden in der Tabelle `Customers` anhand der externen Kundennummer (`CustomerNrExternal`) und des Shops, dem der Kunde zugeordnet ist (`CustomerOf` = `ShopId`).\n\n- Bei `AllowAmbiguous` = 1 wird der Schlüssel eines passenden Kunden geliefert, auch wenn mehrere Kunden im Shop dieselbe externe Nummer haben.\n- Bei `AllowAmbiguous` = 0 wird nur dann ein Schlüssel geliefert, wenn genau ein Kunde passt. Bei mehreren Treffern ist die Ergebnismenge leer.\n- Gibt es keinen Treffer, ist die Ergebnismenge leer.\n\nEs wird höchstens eine Zeile zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustomerNrExternal` | varchar(60) | Ja | Externe Kundennummer, z. B. die Kundennummer im Onlineshop. |\n| `ShopId` | char(3) | Ja | Shop-ID, der der Kunde zugeordnet ist. Der Wert wird mit `Customers.CustomerOf` verglichen. |\n| `AllowAmbiguous` | bit | Ja | Steuert, ob bei mehreren passenden Kunden ein Schlüssel geliefert wird. |\n\n- Alle Parameter sind Pflicht; keiner hat einen Standardwert.\n- Die Abfrage nutzt `TOP 1` ohne `ORDER BY`. Bei `AllowAmbiguous` = 1 und mehreren Treffern ist nicht festgelegt, welcher `CustKey` geliefert wird.\n- Gelesen wird mit `NOLOCK`, daher können nicht festgeschriebene Daten sichtbar sein.\n- Eine leere Ergebnismenge bedeutet entweder keinen Treffer oder, bei `AllowAmbiguous` = 0, einen mehrdeutigen Treffer. Der Aufrufer kann die beiden Fälle nicht unterscheiden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCustomerKeyByNumber"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n WEB-100245\n SHP\n 0\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den internen Kundenschlüssel (CustKey) zu einer externen Kundennummer innerhalb eines Shops.\n\nSucht einen Kunden in der Tabelle `Customers` anhand der externen Kundennummer (`CustomerNrExternal`) und des Shops, dem der Kunde zugeordnet ist (`CustomerOf` = `ShopId`).\n\n- Bei `AllowAmbiguous` = 1 wird der Schlüssel eines passenden Kunden geliefert, auch wenn mehrere Kunden im Shop dieselbe externe Nummer haben.\n- Bei `AllowAmbiguous` = 0 wird nur dann ein Schlüssel geliefert, wenn genau ein Kunde passt. Bei mehreren Treffern ist die Ergebnismenge leer.\n- Gibt es keinen Treffer, ist die Ergebnismenge leer.\n\nEs wird höchstens eine Zeile zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustomerNrExternal` | varchar(60) | Ja | Externe Kundennummer, z. B. die Kundennummer im Onlineshop. |\n| `ShopId` | char(3) | Ja | Shop-ID, der der Kunde zugeordnet ist. Der Wert wird mit `Customers.CustomerOf` verglichen. |\n| `AllowAmbiguous` | bit | Ja | Steuert, ob bei mehreren passenden Kunden ein Schlüssel geliefert wird. |\n\n- Alle Parameter sind Pflicht; keiner hat einen Standardwert.\n- Die Abfrage nutzt `TOP 1` ohne `ORDER BY`. Bei `AllowAmbiguous` = 1 und mehreren Treffern ist nicht festgelegt, welcher `CustKey` geliefert wird.\n- Gelesen wird mit `NOLOCK`, daher können nicht festgeschriebene Daten sichtbar sein.\n- Eine leere Ergebnismenge bedeutet entweder keinen Treffer oder, bei `AllowAmbiguous` = 0, einen mehrdeutigen Treffer. Der Aufrufer kann die beiden Fälle nicht unterscheiden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCustomerKeyByNumber"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 48213\n \n"
}
]
},
{
"name": "pixiCustomerSearch",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Sucht Kunden anhand externer Kundennummer, E-Mail, Name, Adresse, Ort, PLZ, Land, Shop, Auftrags- oder Rechnungsnummer.\n\nWrapper um die interne Prozedur `Pixi_CustomerSearch`. Der Aufruf normalisiert zuerst die Suchparameter und gibt sie dann weiter. Das Ergebnis liefert die interne Prozedur.\n\nNormalisierung:\n- Leere Zeichenketten und `NULL` werden durch den Platzhalter `%` ersetzt. Bei `Name` und `Address` lautet der Ersatz `%%`.\n- `CustNrExternal`: Wird ein Wert ungleich `%` übergeben, wird ein `%` angehängt. Damit entsteht eine Präfixsuche, z. B. wird `K100` zu `K100%`.\n- `OrderNr`: `0` (und `NULL`) gilt als kein Filter (`NULL`).\n\nZuordnung der Parameter zu `Pixi_CustomerSearch`:\n- `CustNrExternal` wird als `@CustID` übergeben, `@CustomerNrExternal` als `NULL`.\n- `RowCount`, `eMail`, `Name`, `Address`, `City`, `Zip`, `Country`, `ShopID`, `OrderNr`, `OrderNrExternal` und `InvoiceNr` werden nach der Normalisierung durchgereicht.\n- Die übrigen Filter der internen Prozedur sind fest auf `NULL` gesetzt: `CardNr`, `BoxNr`, `ItemName`, `ItemEAN`, `Status` und `ShipCode`. `SerialNr` ist fest auf `%` gesetzt.\n\n`RowCount` (Standard 1500) wird an die interne Prozedur übergeben und begrenzt vermutlich die Anzahl der gelieferten Zeilen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `RowCount` | integer | Nein | Maximale Anzahl Zeilen. Wird an `Pixi_CustomerSearch` übergeben. |\n| `CustNrExternal` | varchar(255) | Nein | Externe Kundennummer. Ein `%` wird angehängt, dadurch entsteht eine Präfixsuche. Wird als `@CustID` übergeben. |\n| `eMail` | varchar(255) | Nein | E-Mail-Filter (Platzhaltermuster). Leerer Wert bedeutet kein Filter. |\n| `Name` | varchar(255) | Nein | Filter auf den Kundennamen (Platzhaltermuster). Leerer Wert wird durch `%%` ersetzt. |\n| `Address` | varchar(255) | Nein | Filter auf Adresse/Straße (Platzhaltermuster). Leerer Wert wird durch `%%` ersetzt. |\n| `City` | varchar(255) | Nein | Filter auf den Ort (Platzhaltermuster). |\n| `Zip` | varchar(255) | Nein | Filter auf die PLZ (Platzhaltermuster). |\n| `Country` | varchar(255) | Nein | Filter auf das Land (Platzhaltermuster). |\n| `ShopID` | varchar(3) | Nein | Shop-Kürzel. Wird unverändert übergeben; Standard ist eine leere Zeichenkette. |\n| `OrderNr` | integer | Nein | Pixi-Auftragsnummer. `NULL` oder `0` bedeutet kein Filter. |\n| `OrderNrExternal` | varchar(255) | Nein | Filter auf die externe (Shop-)Auftragsnummer (Platzhaltermuster). |\n| `InvoiceNr` | varchar(255) | Nein | Filter auf die Rechnungsnummer (Platzhaltermuster). |\n\n- Die Definition von `Pixi_CustomerSearch` liegt nicht vor. Spalten des Ergebnisses, genaue Suchlogik und Sortierung lassen sich aus diesem Code nicht ableiten. Die `%`-Standardwerte deuten auf `LIKE`-Mustervergleiche hin, dies ist jedoch nicht bestätigt.\n- Da der Code `OrderNr` mit einer leeren Zeichenkette vergleicht, wird der Wert `0` als `NULL` (kein Filter) behandelt.\n- Der Kopfkommentar (\"Template for getting items…\") stammt aus einer Vorlage und beschreibt diesen Aufruf nicht.\n- Der Aufruf selbst schreibt keine Daten. Ob die interne Prozedur Nebeneffekte hat, ist unbekannt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCustomerSearch"
},
"response": []
},
{
"name": "pixiCustomersOpenCases",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10452\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Sperrkennzeichen, offene Aufträge, unbezahlte Rechnungen, Rechnungsschuld und offenen Auftragswert eines Kunden samt Währungscode der Beträge.\n\nLiefert eine einzelne Zeile mit den offenen Vorgängen des Kunden mit dem angegebenen `CustKey`.\n\nDas Verhalten hängt von der Einstellung `MultiCurrencyEnabled` ab.\n\n**Mehrwährung deaktiviert** (Einstellung ungleich `1`):\n- `Locked` ist `1`, wenn das Kennzeichen `SLocked` des Kunden einen anderen Wert als `N` hat, sonst `0`.\n- `OpenOrders` ist die Anzahl unterschiedlicher Auftragsnummern mit mindestens einer Auftragsposition des Kunden (`Orderlines.CustRef`), deren Status kein Endstatus laut `OrderStates` (`FinalState = 'Y'`) ist.\n- `OpenOrderAmount` ist die Summe von `OrderLineAmount` dieser nicht abgeschlossenen Positionen. Die Beträge werden wie gespeichert summiert, ohne Währungsumrechnung.\n- `UnpaidInvoices` ist die Anzahl der Rechnungen des Kunden, bei denen der bezahlte Betrag nicht dem Rechnungsbetrag entspricht. Ein fehlender bezahlter Betrag zählt als `0`.\n- `DebtByInvoices` ist die Summe von `total - PayedSum` über alle Rechnungen des Kunden.\n- `BaseCurrency` ist der Code der Datenbankwährung. Er stammt aus der Einstellung `HomeCurrency` und muss eine Hauptwährung in `pixi.Currency` sein.\n\n**Mehrwährung aktiviert** (Einstellung gleich `1`):\n- Die Anzahlen werden auf dieselbe Weise ermittelt.\n- Jeder Positionsbetrag wird durch den Wechselkurs seines Auftragskopfs (`OrderHeader.ExchRateId`) geteilt.\n- Jede Rechnungsschuld wird durch den Wechselkurs der Rechnung (`Invoices.ExchRateId`) geteilt.\n- Die Ergebnisse sind damit Beträge in Basiswährung.\n- `BaseCurrency` ist der Code der Basiswährung des Shops, dem der Kunde zugeordnet ist (`Shops.BaseCurrencyId`).\n\nExistiert kein Kunde mit dem angegebenen `CustKey`, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Ja | Schlüssel des Kunden (`Customers.CustKey`). |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; die Werte können nicht festgeschriebene Daten enthalten.\n- Ohne Mehrwährung werden Auftrags- und Rechnungsbeträge in unterschiedlichen Währungen unumgerechnet addiert. `BaseCurrency` nennt dann nur den Code der Datenbankwährung; es ist nicht die tatsächliche Währung der Summe.\n- Bei aktivierter Mehrwährung fallen folgende Datensätze aus Beträgen und Anzahlen heraus: Positionen, deren Auftragskopf keinen passenden Wechselkurs hat, und Rechnungen ohne passenden Wechselkurs. Es wird keine Zeile geliefert, wenn der Shop des Kunden oder dessen Basiswährung nicht gefunden wird.\n- Rechnungen mit `NULL` als bezahltem Betrag werden in `UnpaidInvoices` gezählt. Ihre Schuld fehlt aber in `DebtByInvoices`, weil `SUM` das Ergebnis `total - NULL` ignoriert.\n- Überzahlte Rechnungen gelten ebenfalls als unbezahlt und verringern `DebtByInvoices`.\n- `DebtByInvoices` ist `0`, wenn der Kunde keine Rechnungen hat.\n- Der Einstellungswert wird in `BIT` umgewandelt. Ein nicht numerischer Wert außer `true`/`false` führt zu einem Konvertierungsfehler.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCustomersOpenCases"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10452\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Sperrkennzeichen, offene Aufträge, unbezahlte Rechnungen, Rechnungsschuld und offenen Auftragswert eines Kunden samt Währungscode der Beträge.\n\nLiefert eine einzelne Zeile mit den offenen Vorgängen des Kunden mit dem angegebenen `CustKey`.\n\nDas Verhalten hängt von der Einstellung `MultiCurrencyEnabled` ab.\n\n**Mehrwährung deaktiviert** (Einstellung ungleich `1`):\n- `Locked` ist `1`, wenn das Kennzeichen `SLocked` des Kunden einen anderen Wert als `N` hat, sonst `0`.\n- `OpenOrders` ist die Anzahl unterschiedlicher Auftragsnummern mit mindestens einer Auftragsposition des Kunden (`Orderlines.CustRef`), deren Status kein Endstatus laut `OrderStates` (`FinalState = 'Y'`) ist.\n- `OpenOrderAmount` ist die Summe von `OrderLineAmount` dieser nicht abgeschlossenen Positionen. Die Beträge werden wie gespeichert summiert, ohne Währungsumrechnung.\n- `UnpaidInvoices` ist die Anzahl der Rechnungen des Kunden, bei denen der bezahlte Betrag nicht dem Rechnungsbetrag entspricht. Ein fehlender bezahlter Betrag zählt als `0`.\n- `DebtByInvoices` ist die Summe von `total - PayedSum` über alle Rechnungen des Kunden.\n- `BaseCurrency` ist der Code der Datenbankwährung. Er stammt aus der Einstellung `HomeCurrency` und muss eine Hauptwährung in `pixi.Currency` sein.\n\n**Mehrwährung aktiviert** (Einstellung gleich `1`):\n- Die Anzahlen werden auf dieselbe Weise ermittelt.\n- Jeder Positionsbetrag wird durch den Wechselkurs seines Auftragskopfs (`OrderHeader.ExchRateId`) geteilt.\n- Jede Rechnungsschuld wird durch den Wechselkurs der Rechnung (`Invoices.ExchRateId`) geteilt.\n- Die Ergebnisse sind damit Beträge in Basiswährung.\n- `BaseCurrency` ist der Code der Basiswährung des Shops, dem der Kunde zugeordnet ist (`Shops.BaseCurrencyId`).\n\nExistiert kein Kunde mit dem angegebenen `CustKey`, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Ja | Schlüssel des Kunden (`Customers.CustKey`). |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; die Werte können nicht festgeschriebene Daten enthalten.\n- Ohne Mehrwährung werden Auftrags- und Rechnungsbeträge in unterschiedlichen Währungen unumgerechnet addiert. `BaseCurrency` nennt dann nur den Code der Datenbankwährung; es ist nicht die tatsächliche Währung der Summe.\n- Bei aktivierter Mehrwährung fallen folgende Datensätze aus Beträgen und Anzahlen heraus: Positionen, deren Auftragskopf keinen passenden Wechselkurs hat, und Rechnungen ohne passenden Wechselkurs. Es wird keine Zeile geliefert, wenn der Shop des Kunden oder dessen Basiswährung nicht gefunden wird.\n- Rechnungen mit `NULL` als bezahltem Betrag werden in `UnpaidInvoices` gezählt. Ihre Schuld fehlt aber in `DebtByInvoices`, weil `SUM` das Ergebnis `total - NULL` ignoriert.\n- Überzahlte Rechnungen gelten ebenfalls als unbezahlt und verringern `DebtByInvoices`.\n- `DebtByInvoices` ist `0`, wenn der Kunde keine Rechnungen hat.\n- Der Einstellungswert wird in `BIT` umgewandelt. Ein nicht numerischer Wert außer `true`/`false` führt zu einem Konvertierungsfehler.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCustomersOpenCases"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 0\n 2\n 1\n 149.9000\n 312.5000\n EUR\n \n"
}
]
},
{
"name": "pixiEmillControlCustomers",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kunden, deren Anzahl an Aufträgen mit Auftragspositionen im Status ANG oder kürzlichem AUS eine Mindestanzahl erreicht, optional je Shop.\n\nListet Kunden mit mehreren passenden Aufträgen auf, etwa um doppelte oder auffällige Bestellungen desselben Kunden zu erkennen.\n\nAblauf:\n\n1. Ein leerer `ShopID` wird als `NULL` behandelt. Dann gilt kein Shop-Filter.\n2. Ein Auftrag zählt, wenn mindestens eine seiner Positionen in `Orderlines` eine der folgenden Bedingungen erfüllt:\n - Status `ANG`, unabhängig vom Datum, oder\n - Status `AUS` und `OrderDate` liegt weniger als `DayRange` Tage zurück, gemessen als Differenz in Kalendertagen zu heute.\n3. Die passenden Aufträge aus `OrderHeader` werden über `CustRef` = `CustKey` mit `Customers` verknüpft.\n4. Ist `ShopID` gesetzt, werden nur Kunden berücksichtigt, deren `CustomerOf` dem `ShopID` entspricht.\n5. Die Ergebnisse werden je Kunde (`CustRef`) gruppiert. Zurückgegeben werden nur Kunden mit mindestens `MinOrderCount` passenden Aufträgen.\n\nJede Zeile enthält Name, E-Mail-Adresse, Anzahl der passenden Aufträge und Shop des Kunden. Eine feste Sortierung gibt es nicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DayRange` | int | Nein | Anzahl der Tage ab heute rückwärts, in denen das Auftragsdatum liegen muss. Gilt nur für Auftragspositionen im Status `AUS`. |\n| `MinOrderCount` | int | Nein | Mindestanzahl passender Aufträge, die ein Kunde haben muss, um zurückgegeben zu werden. |\n| `ShopID` | varchar(3) | Nein | Shop des Kunden (`CustomerOf`). Bei `NULL` oder Leerstring werden Kunden aller Shops geliefert. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen. Das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Wegen der SQL-Operatorrangfolge (`AND` vor `OR`) gilt die Einschränkung über `DayRange` nur für Positionen im Status `AUS`. Aufträge mit Positionen im Status `ANG` werden unabhängig von ihrem Alter gezählt.\n- Aus dem Code geht nicht hervor, zu welcher Tabelle die unqualifizierte Spalte `OrderDate` gehört. Hat `Orderlines` keine solche Spalte, wird das Auftragsdatum aus `OrderHeader` verwendet.\n- Der Shop-Filter bezieht sich auf den Shop des Kunden (`CustomerOf`), nicht auf den Shop des Auftrags.\n- `Name`, `eMail` und `ShopID` werden je Kundengruppe per `MAX()` ermittelt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEmillControlCustomers"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kunden, deren Anzahl an Aufträgen mit Auftragspositionen im Status ANG oder kürzlichem AUS eine Mindestanzahl erreicht, optional je Shop.\n\nListet Kunden mit mehreren passenden Aufträgen auf, etwa um doppelte oder auffällige Bestellungen desselben Kunden zu erkennen.\n\nAblauf:\n\n1. Ein leerer `ShopID` wird als `NULL` behandelt. Dann gilt kein Shop-Filter.\n2. Ein Auftrag zählt, wenn mindestens eine seiner Positionen in `Orderlines` eine der folgenden Bedingungen erfüllt:\n - Status `ANG`, unabhängig vom Datum, oder\n - Status `AUS` und `OrderDate` liegt weniger als `DayRange` Tage zurück, gemessen als Differenz in Kalendertagen zu heute.\n3. Die passenden Aufträge aus `OrderHeader` werden über `CustRef` = `CustKey` mit `Customers` verknüpft.\n4. Ist `ShopID` gesetzt, werden nur Kunden berücksichtigt, deren `CustomerOf` dem `ShopID` entspricht.\n5. Die Ergebnisse werden je Kunde (`CustRef`) gruppiert. Zurückgegeben werden nur Kunden mit mindestens `MinOrderCount` passenden Aufträgen.\n\nJede Zeile enthält Name, E-Mail-Adresse, Anzahl der passenden Aufträge und Shop des Kunden. Eine feste Sortierung gibt es nicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DayRange` | int | Nein | Anzahl der Tage ab heute rückwärts, in denen das Auftragsdatum liegen muss. Gilt nur für Auftragspositionen im Status `AUS`. |\n| `MinOrderCount` | int | Nein | Mindestanzahl passender Aufträge, die ein Kunde haben muss, um zurückgegeben zu werden. |\n| `ShopID` | varchar(3) | Nein | Shop des Kunden (`CustomerOf`). Bei `NULL` oder Leerstring werden Kunden aller Shops geliefert. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen. Das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Wegen der SQL-Operatorrangfolge (`AND` vor `OR`) gilt die Einschränkung über `DayRange` nur für Positionen im Status `AUS`. Aufträge mit Positionen im Status `ANG` werden unabhängig von ihrem Alter gezählt.\n- Aus dem Code geht nicht hervor, zu welcher Tabelle die unqualifizierte Spalte `OrderDate` gehört. Hat `Orderlines` keine solche Spalte, wird das Auftragsdatum aus `OrderHeader` verwendet.\n- Der Shop-Filter bezieht sich auf den Shop des Kunden (`CustomerOf`), nicht auf den Shop des Auftrags.\n- `Name`, `eMail` und `ShopID` werden je Kundengruppe per `MAX()` ermittelt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEmillControlCustomers"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Max Mustermann\n max.mustermann@example.de\n 3\n SH1\n \n \n Erika Musterfrau\n erika@example.com\n 2\n SH1\n \n"
}
]
},
{
"name": "pixiEmillGetCustomers",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kunden mit E-Mail-Adresse und Namen, optional gefiltert nach Bestell- oder Versanddatum, Artikel, Zahlungs- und Versandstatus oder Shop, mit schlüsselbasiertem Paging.\n\nLiefert eine Liste von Kunden (Schlüssel, E-Mail, Vorname, Nachname, Shop) für den Einsatz in E-Mail-Marketing-Werkzeugen. Die Prozedur erzeugt eine dynamische Abfrage auf `Customers`, verknüpft mit `Addresses` (Inner Join über die Adressreferenz des Kunden). Alle Filter sind optional und werden mit UND kombiniert:\n\n- `orderdate`: nur Kunden mit mindestens einer Auftragsposition, deren Bestelldatum auf denselben Kalendertag fällt (Jahr, Monat und Tag werden verglichen, die Uhrzeit wird ignoriert).\n- `ShipDate`: nur Kunden mit mindestens einer Auftragsposition, die an diesem Kalendertag versendet wurde.\n- `EanUpc`: nur Kunden, die einen Artikel mit dieser EAN/UPC bestellt haben.\n- `ArticleNr`: nur Kunden, die einen Artikel bestellt haben, dessen **Lieferanten-Artikelnummer** (`ItemNrSuppl`) übereinstimmt.\n- `paid`: `1` = Kunden mit mindestens einer Rechnung, deren bezahlter Betrag der Gesamtsumme entspricht; `0` = Kunden mit mindestens einer Rechnung, deren bezahlter Betrag von der Gesamtsumme abweicht.\n- `Shipped`: `1` = Kunden mit mindestens einer versendeten Auftragsposition; `0` = Kunden mit mindestens einer Auftragsposition ohne Versanddatum.\n- `ShopID`: nur Kunden dieses Shops (`CustomerOf`). Ein leerer String wird als kein Filter behandelt.\n\nDas Ergebnis ist aufsteigend nach Kundenschlüssel sortiert und auf `Top` Zeilen begrenzt. Für Paging wird der höchste `custkey` der vorherigen Seite als `resumeKey` übergeben; dann werden nur Kunden mit größerem Schlüssel geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `orderdate` | datetime | Nein | Nur Kunden mit einer Auftragsposition, die an diesem Kalendertag bestellt wurde. Die Uhrzeit wird ignoriert. |\n| `ShipDate` | datetime | Nein | Nur Kunden mit einer Auftragsposition, die an diesem Kalendertag versendet wurde. Die Uhrzeit wird ignoriert. |\n| `EanUpc` | varchar(13) | Nein | Nur Kunden, die einen Artikel mit dieser EAN/UPC bestellt haben. |\n| `ArticleNr` | varchar(50) | Nein | Nur Kunden, die einen Artikel mit dieser Lieferanten-Artikelnummer (`ItemNrSuppl`) bestellt haben. |\n| `paid` | bit | Nein | Filter auf den Zahlungsstatus der Rechnungen. `NULL` = kein Filter. |\n| `Shipped` | bit | Nein | Filter auf den Versandstatus der Auftragspositionen. `NULL` = kein Filter. |\n| `resumeKey` | int | Nein | Paging-Schlüssel: nur Kunden mit einem Kundenschlüssel größer als dieser Wert werden geliefert. Den letzten `custkey` der vorherigen Seite übergeben. |\n| `Top` | int | Nein | Maximale Anzahl gelieferter Zeilen (über `SET ROWCOUNT`; `0` = keine Begrenzung). |\n| `ShopID` | varchar(3) | Nein | Nur Kunden dieses Shops (`CustomerOf`). Ein leerer String wird als `NULL` (kein Filter) behandelt. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`; `Top` = `0` liefert alle passenden Zeilen.\n- Kunden ohne passenden Adressdatensatz werden wegen des Inner Join nicht geliefert.\n- Die Filter `paid` und `Shipped` prüfen auf *mindestens eine* passende Rechnung bzw. Auftragsposition, nicht auf alle. `paid = 1` liefert daher auch Kunden, die zusätzlich unbezahlte Rechnungen haben.\n- Die Datumsfilter wenden `DATEPART` auf die Spalte an, Indizes auf Bestell- oder Versanddatum können dadurch nicht genutzt werden; bei großen Datenbanken können diese Filter langsam sein.\n- `ArticleNr` wird mit der Lieferanten-Artikelnummer (`ItemNrSuppl`) verglichen, nicht mit der internen Artikelnummer.\n- Die Anweisung wird an `sp_executesql` unter dem Parameternamen `@statment` statt des dokumentierten `@stmt` übergeben; der Aufruf verlässt sich auf die positionsbezogene Verarbeitung dieses Parameters.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEmillGetCustomers"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kunden mit E-Mail-Adresse und Namen, optional gefiltert nach Bestell- oder Versanddatum, Artikel, Zahlungs- und Versandstatus oder Shop, mit schlüsselbasiertem Paging.\n\nLiefert eine Liste von Kunden (Schlüssel, E-Mail, Vorname, Nachname, Shop) für den Einsatz in E-Mail-Marketing-Werkzeugen. Die Prozedur erzeugt eine dynamische Abfrage auf `Customers`, verknüpft mit `Addresses` (Inner Join über die Adressreferenz des Kunden). Alle Filter sind optional und werden mit UND kombiniert:\n\n- `orderdate`: nur Kunden mit mindestens einer Auftragsposition, deren Bestelldatum auf denselben Kalendertag fällt (Jahr, Monat und Tag werden verglichen, die Uhrzeit wird ignoriert).\n- `ShipDate`: nur Kunden mit mindestens einer Auftragsposition, die an diesem Kalendertag versendet wurde.\n- `EanUpc`: nur Kunden, die einen Artikel mit dieser EAN/UPC bestellt haben.\n- `ArticleNr`: nur Kunden, die einen Artikel bestellt haben, dessen **Lieferanten-Artikelnummer** (`ItemNrSuppl`) übereinstimmt.\n- `paid`: `1` = Kunden mit mindestens einer Rechnung, deren bezahlter Betrag der Gesamtsumme entspricht; `0` = Kunden mit mindestens einer Rechnung, deren bezahlter Betrag von der Gesamtsumme abweicht.\n- `Shipped`: `1` = Kunden mit mindestens einer versendeten Auftragsposition; `0` = Kunden mit mindestens einer Auftragsposition ohne Versanddatum.\n- `ShopID`: nur Kunden dieses Shops (`CustomerOf`). Ein leerer String wird als kein Filter behandelt.\n\nDas Ergebnis ist aufsteigend nach Kundenschlüssel sortiert und auf `Top` Zeilen begrenzt. Für Paging wird der höchste `custkey` der vorherigen Seite als `resumeKey` übergeben; dann werden nur Kunden mit größerem Schlüssel geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `orderdate` | datetime | Nein | Nur Kunden mit einer Auftragsposition, die an diesem Kalendertag bestellt wurde. Die Uhrzeit wird ignoriert. |\n| `ShipDate` | datetime | Nein | Nur Kunden mit einer Auftragsposition, die an diesem Kalendertag versendet wurde. Die Uhrzeit wird ignoriert. |\n| `EanUpc` | varchar(13) | Nein | Nur Kunden, die einen Artikel mit dieser EAN/UPC bestellt haben. |\n| `ArticleNr` | varchar(50) | Nein | Nur Kunden, die einen Artikel mit dieser Lieferanten-Artikelnummer (`ItemNrSuppl`) bestellt haben. |\n| `paid` | bit | Nein | Filter auf den Zahlungsstatus der Rechnungen. `NULL` = kein Filter. |\n| `Shipped` | bit | Nein | Filter auf den Versandstatus der Auftragspositionen. `NULL` = kein Filter. |\n| `resumeKey` | int | Nein | Paging-Schlüssel: nur Kunden mit einem Kundenschlüssel größer als dieser Wert werden geliefert. Den letzten `custkey` der vorherigen Seite übergeben. |\n| `Top` | int | Nein | Maximale Anzahl gelieferter Zeilen (über `SET ROWCOUNT`; `0` = keine Begrenzung). |\n| `ShopID` | varchar(3) | Nein | Nur Kunden dieses Shops (`CustomerOf`). Ein leerer String wird als `NULL` (kein Filter) behandelt. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`; `Top` = `0` liefert alle passenden Zeilen.\n- Kunden ohne passenden Adressdatensatz werden wegen des Inner Join nicht geliefert.\n- Die Filter `paid` und `Shipped` prüfen auf *mindestens eine* passende Rechnung bzw. Auftragsposition, nicht auf alle. `paid = 1` liefert daher auch Kunden, die zusätzlich unbezahlte Rechnungen haben.\n- Die Datumsfilter wenden `DATEPART` auf die Spalte an, Indizes auf Bestell- oder Versanddatum können dadurch nicht genutzt werden; bei großen Datenbanken können diese Filter langsam sein.\n- `ArticleNr` wird mit der Lieferanten-Artikelnummer (`ItemNrSuppl`) verglichen, nicht mit der internen Artikelnummer.\n- Die Anweisung wird an `sp_executesql` unter dem Parameternamen `@statment` statt des dokumentierten `@stmt` übergeben; der Aufruf verlässt sich auf die positionsbezogene Verarbeitung dieses Parameters.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEmillGetCustomers"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10251\n anna.schmidt@example.de\n Anna\n Schmidt\n SH1\n \n \n 10254\n m.weber@example.com\n Markus\n Weber\n SH1\n \n"
}
]
},
{
"name": "pixiEmillGetCustomers2",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine Liste von Kunden mit Rechnungsadresse und letzten Auftragsdaten, gefiltert nach Artikel-, Auftrags-, Zahlungs- und Kundenmerkmalen.\n\nLiefert eine Zeile pro Kunde, der mindestens eine Auftragsposition besitzt, die allen angegebenen Filtern entspricht. Der Kunde wird mit seiner Adresse (`AddrRef`), den Auftragspositionen, dem Artikel, der Artikelkategorie (`tontrArten` über `configType`) und optional mit Rechnung, Lieferant und zusätzlichen Artikeldaten verknüpft. Alle Filter werden mit UND kombiniert. Ein Filter, dessen Parameter `NULL` ist, wird nicht angewendet.\n\n**Shop**\n- `ShopID`: nur Kunden, deren `CustomerOf` diesem Wert entspricht. Ein Leerstring gilt als `NULL`.\n\n**Artikelfilter** (auf die Auftragspositionen angewendet)\n- `ArticleName` mit `ArticleNameCmp`: `0` = exakte Übereinstimmung mit dem Artikelnamen der Auftragsposition, `1` = Name enthält den Wert.\n- `ArticleNr` mit `ArticleNrCmp`: vergleicht mit Lieferanten-Artikelnummer, EAN/UPC oder interner Artikelnummer. `0` = exakt, `1` = enthält.\n- `ArtCategory`: Schlüssel der Artikelkategorie (`tontrArtKey`).\n- `ArtSupplier`: Lieferantennummer der Auftragsposition (`SupplInfo`) oder Lieferantenname.\n\n**Auftragsfilter**\n- `orderStatus`: Status der Auftragsposition, z. B. `AUS` oder `RET`.\n- `ShipDateFrom`/`ShipDateTo`: Versanddatum der Auftragsposition zwischen beiden Werten. Der Filter greift nur, wenn **beide** gesetzt sind.\n- `ShipDateDays` mit `ShipDateDaysCmp`: Anzahl Tage zwischen Versanddatum und jetzt. `0` = mehr als, `1` = genau, `2` = weniger als `ShipDateDays` Tage.\n- `PaymentType`: Zahlungsart der mit der Auftragsposition verknüpften Rechnung.\n\n**Kundenfilter**\n- `CustTurnover` mit `CustTurnoverCmp`: Summe aller Rechnungsbeträge des Kunden. `0` = Umsatz größer als der Wert, `1` = gleich, `2` = kleiner.\n- `CustReturn`: `0` = ignorieren, `1` = nur Kunden mit mindestens einer Auftragsposition im Status `RET`, `-1` = nur Kunden ohne solche Positionen.\n- `CustBlocked`: `0` = nur nicht gesperrte Kunden, `1` = gesperrte und nicht gesperrte Kunden.\n- `CustOpenOrders`: `0` = ignorieren, `1` = nur Kunden mit mindestens einem Auftrag, dessen Gesamtstatus `OPEN` ist.\n\nDie Spalten `OrderDate`, `ShipDate` und `Status` sind die Maximalwerte über die passenden Auftragspositionen des Kunden. Das Ergebnis ist nach `CustKey` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ArticleName` | varchar(100) | Nein | Artikelname der Auftragsposition als Filter; Vergleich gemäß `ArticleNameCmp`. |\n| `ArticleNameCmp` | int | Nein | Vergleichsmodus für `ArticleName`. `NULL` wird als `0` behandelt. |\n| `ArticleNr` | varchar(50) | Nein | Artikelnummer als Filter; Vergleich mit Lieferanten-Artikelnummer, EAN/UPC und interner Artikelnummer gemäß `ArticleNrCmp`. |\n| `ArticleNrCmp` | int | Nein | Vergleichsmodus für `ArticleNr`. `NULL` wird als `0` behandelt. |\n| `ArtCategory` | int | Nein | Schlüssel der Artikelkategorie (`tontrArtKey` in `tontrArten`). |\n| `ArtSupplier` | varchar(50) | Nein | Lieferantennummer der Auftragsposition oder Lieferantenname. |\n| `orderStatus` | varchar(3) | Nein | Status der Auftragsposition, z. B. `AUS` oder `RET`. |\n| `ShipDateFrom` | datetime | Nein | Beginn des Versanddatumsbereichs. Wirkt nur zusammen mit `ShipDateTo`. |\n| `ShipDateTo` | datetime | Nein | Ende des Versanddatumsbereichs (inklusive). Wirkt nur zusammen mit `ShipDateFrom`. |\n| `ShipDateDays` | int | Nein | Anzahl Tage seit dem Versanddatum der Auftragsposition; Vergleich gemäß `ShipDateDaysCmp`. |\n| `ShipDateDaysCmp` | int | Nein | Vergleichsmodus für `ShipDateDays`. `NULL` wird als `1` behandelt. |\n| `PaymentType` | varchar(30) | Nein | Zahlungsart der mit der Auftragsposition verknüpften Rechnung. |\n| `CustTurnover` | int | Nein | Umsatzschwelle, verglichen mit der Summe aller Rechnungsbeträge des Kunden gemäß `CustTurnoverCmp`. |\n| `CustTurnoverCmp` | int | Nein | Vergleichsmodus für `CustTurnover`. `NULL` wird als `1` behandelt. |\n| `CustReturn` | int | Nein | Filter auf Retouren des Kunden. `NULL` wird als `0` behandelt. |\n| `CustBlocked` | int | Nein | Steuert, ob gesperrte Kunden enthalten sind. `NULL` wird als `0` behandelt. |\n| `CustOpenOrders` | int | Nein | Filter auf offene Aufträge des Kunden. `NULL` wird als `0` behandelt. |\n| `resumeKey` | int | Nein | Wird von der Prozedur nicht verwendet. |\n| `ShopID` | varchar(3) | Nein | Shop, dem der Kunde zugeordnet ist (`CustomerOf`). Leerstring oder `NULL` bedeutet alle Shops. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können daher erscheinen.\n- `resumeKey` ist deklariert, wird aber nicht verwendet; es gibt kein Paging.\n- `Status` ist der alphabetisch höchste Status der passenden Auftragspositionen, nicht zwingend der Status des neuesten Auftrags. `OrderDate` und `ShipDate` werden unabhängig voneinander ermittelt.\n- Vergleichsparameter mit anderen als den dokumentierten Werten (z. B. `ArticleNameCmp = 2` bei gesetztem `ArticleName` oder `CustBlocked = 2`) führen dazu, dass der Filter nichts trifft und das Ergebnis leer ist.\n- `CustTurnover` schließt Kunden ohne Rechnung aus, da deren Umsatzsumme `NULL` ist.\n- Bei gesetztem `PaymentType` werden nur Auftragspositionen berücksichtigt, die mit einer Rechnung desselben Kunden verknüpft sind.\n- Auftragspositionen, deren `configType` keinen Eintrag in `tontrArten` hat, werden nie berücksichtigt.\n- `CustOpenOrders = 1` ruft die Skalarfunktion `fPixi_GetWholeOrderState` pro Auftrag des Kunden auf, was bei Kunden mit vielen Aufträgen langsam sein kann.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEmillGetCustomers2"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine Liste von Kunden mit Rechnungsadresse und letzten Auftragsdaten, gefiltert nach Artikel-, Auftrags-, Zahlungs- und Kundenmerkmalen.\n\nLiefert eine Zeile pro Kunde, der mindestens eine Auftragsposition besitzt, die allen angegebenen Filtern entspricht. Der Kunde wird mit seiner Adresse (`AddrRef`), den Auftragspositionen, dem Artikel, der Artikelkategorie (`tontrArten` über `configType`) und optional mit Rechnung, Lieferant und zusätzlichen Artikeldaten verknüpft. Alle Filter werden mit UND kombiniert. Ein Filter, dessen Parameter `NULL` ist, wird nicht angewendet.\n\n**Shop**\n- `ShopID`: nur Kunden, deren `CustomerOf` diesem Wert entspricht. Ein Leerstring gilt als `NULL`.\n\n**Artikelfilter** (auf die Auftragspositionen angewendet)\n- `ArticleName` mit `ArticleNameCmp`: `0` = exakte Übereinstimmung mit dem Artikelnamen der Auftragsposition, `1` = Name enthält den Wert.\n- `ArticleNr` mit `ArticleNrCmp`: vergleicht mit Lieferanten-Artikelnummer, EAN/UPC oder interner Artikelnummer. `0` = exakt, `1` = enthält.\n- `ArtCategory`: Schlüssel der Artikelkategorie (`tontrArtKey`).\n- `ArtSupplier`: Lieferantennummer der Auftragsposition (`SupplInfo`) oder Lieferantenname.\n\n**Auftragsfilter**\n- `orderStatus`: Status der Auftragsposition, z. B. `AUS` oder `RET`.\n- `ShipDateFrom`/`ShipDateTo`: Versanddatum der Auftragsposition zwischen beiden Werten. Der Filter greift nur, wenn **beide** gesetzt sind.\n- `ShipDateDays` mit `ShipDateDaysCmp`: Anzahl Tage zwischen Versanddatum und jetzt. `0` = mehr als, `1` = genau, `2` = weniger als `ShipDateDays` Tage.\n- `PaymentType`: Zahlungsart der mit der Auftragsposition verknüpften Rechnung.\n\n**Kundenfilter**\n- `CustTurnover` mit `CustTurnoverCmp`: Summe aller Rechnungsbeträge des Kunden. `0` = Umsatz größer als der Wert, `1` = gleich, `2` = kleiner.\n- `CustReturn`: `0` = ignorieren, `1` = nur Kunden mit mindestens einer Auftragsposition im Status `RET`, `-1` = nur Kunden ohne solche Positionen.\n- `CustBlocked`: `0` = nur nicht gesperrte Kunden, `1` = gesperrte und nicht gesperrte Kunden.\n- `CustOpenOrders`: `0` = ignorieren, `1` = nur Kunden mit mindestens einem Auftrag, dessen Gesamtstatus `OPEN` ist.\n\nDie Spalten `OrderDate`, `ShipDate` und `Status` sind die Maximalwerte über die passenden Auftragspositionen des Kunden. Das Ergebnis ist nach `CustKey` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ArticleName` | varchar(100) | Nein | Artikelname der Auftragsposition als Filter; Vergleich gemäß `ArticleNameCmp`. |\n| `ArticleNameCmp` | int | Nein | Vergleichsmodus für `ArticleName`. `NULL` wird als `0` behandelt. |\n| `ArticleNr` | varchar(50) | Nein | Artikelnummer als Filter; Vergleich mit Lieferanten-Artikelnummer, EAN/UPC und interner Artikelnummer gemäß `ArticleNrCmp`. |\n| `ArticleNrCmp` | int | Nein | Vergleichsmodus für `ArticleNr`. `NULL` wird als `0` behandelt. |\n| `ArtCategory` | int | Nein | Schlüssel der Artikelkategorie (`tontrArtKey` in `tontrArten`). |\n| `ArtSupplier` | varchar(50) | Nein | Lieferantennummer der Auftragsposition oder Lieferantenname. |\n| `orderStatus` | varchar(3) | Nein | Status der Auftragsposition, z. B. `AUS` oder `RET`. |\n| `ShipDateFrom` | datetime | Nein | Beginn des Versanddatumsbereichs. Wirkt nur zusammen mit `ShipDateTo`. |\n| `ShipDateTo` | datetime | Nein | Ende des Versanddatumsbereichs (inklusive). Wirkt nur zusammen mit `ShipDateFrom`. |\n| `ShipDateDays` | int | Nein | Anzahl Tage seit dem Versanddatum der Auftragsposition; Vergleich gemäß `ShipDateDaysCmp`. |\n| `ShipDateDaysCmp` | int | Nein | Vergleichsmodus für `ShipDateDays`. `NULL` wird als `1` behandelt. |\n| `PaymentType` | varchar(30) | Nein | Zahlungsart der mit der Auftragsposition verknüpften Rechnung. |\n| `CustTurnover` | int | Nein | Umsatzschwelle, verglichen mit der Summe aller Rechnungsbeträge des Kunden gemäß `CustTurnoverCmp`. |\n| `CustTurnoverCmp` | int | Nein | Vergleichsmodus für `CustTurnover`. `NULL` wird als `1` behandelt. |\n| `CustReturn` | int | Nein | Filter auf Retouren des Kunden. `NULL` wird als `0` behandelt. |\n| `CustBlocked` | int | Nein | Steuert, ob gesperrte Kunden enthalten sind. `NULL` wird als `0` behandelt. |\n| `CustOpenOrders` | int | Nein | Filter auf offene Aufträge des Kunden. `NULL` wird als `0` behandelt. |\n| `resumeKey` | int | Nein | Wird von der Prozedur nicht verwendet. |\n| `ShopID` | varchar(3) | Nein | Shop, dem der Kunde zugeordnet ist (`CustomerOf`). Leerstring oder `NULL` bedeutet alle Shops. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können daher erscheinen.\n- `resumeKey` ist deklariert, wird aber nicht verwendet; es gibt kein Paging.\n- `Status` ist der alphabetisch höchste Status der passenden Auftragspositionen, nicht zwingend der Status des neuesten Auftrags. `OrderDate` und `ShipDate` werden unabhängig voneinander ermittelt.\n- Vergleichsparameter mit anderen als den dokumentierten Werten (z. B. `ArticleNameCmp = 2` bei gesetztem `ArticleName` oder `CustBlocked = 2`) führen dazu, dass der Filter nichts trifft und das Ergebnis leer ist.\n- `CustTurnover` schließt Kunden ohne Rechnung aus, da deren Umsatzsumme `NULL` ist.\n- Bei gesetztem `PaymentType` werden nur Auftragspositionen berücksichtigt, die mit einer Rechnung desselben Kunden verknüpft sind.\n- Auftragspositionen, deren `configType` keinen Eintrag in `tontrArten` hat, werden nie berücksichtigt.\n- `CustOpenOrders = 1` ruft die Skalarfunktion `fPixi_GetWholeOrderState` pro Auftrag des Kunden auf, was bei Kunden mit vielen Aufträgen langsam sein kann.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEmillGetCustomers2"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n K-000815\n anna.mueller@example.de\n Anna\n Müller\n Hauptstraße 12\n 80331\n München\n Bayern\n 2024-02-10T14:23:00\n 2024-02-12T09:05:00\n AUS\n SHP\n \n"
}
]
},
{
"name": "pixiGetAddress",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104527\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert einen einzelnen Adressdatensatz anhand des Adressschlüssels inklusive Länderangaben, Bankdaten und Zahlungsart.\n\nLiest eine Adresse anhand ihres Primärschlüssels `AddrKey` aus der Adresstabelle von Pixi.\n\n- Gefiltert wird über `AddrKey = @AddrKey`. Es wird höchstens eine Zeile geliefert.\n- Das Land der Adresse (`Country`) wird über den Ländercode mit der Ländertabelle verknüpft. Ländername sowie ISO-2- und ISO-3-Code werden ergänzt. Existiert kein passendes Land, bleiben diese Spalten leer.\n- Neben den Kontaktdaten (Name, Firma, Straße, PLZ, Ort, Telefon, Fax, E-Mail) enthält das Ergebnis die externe Kundennummer, den verknüpften Kundenschlüssel (`CustKey`), die USt-IdNr., das Geburtsdatum, eine Notiz, Bankdaten (Kontonummer, Kontoinhaber, BLZ, Bankname, BIC, IBAN) und die an der Adresse hinterlegte Zahlungsart.\n- Mehrere Spalten werden in der Ausgabe umbenannt, z. B. `Anrede` zu `Title`, `CareOf` zu `Company`, `AdrCustRef` zu `CustKey` und `UsStId` zu `VatID`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AddrKey` | int | Ja | Primärschlüssel der zu liefernden Adresse. |\n\n- Beide Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein.\n- Existiert keine Adresse mit dem angegebenen Schlüssel, ist die Ergebnismenge leer; eine Fehlermeldung wird nicht geliefert.\n- Das Ergebnis enthält Bankdaten (IBAN, BIC, Kontonummer). Diese sind gemäß Datenschutzanforderungen zu behandeln.\n- Die Datentypen der Spalten sind in der Prozedur nicht ersichtlich; die hier angegebenen Typen sind durch den Code nicht belegt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetAddress"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104527\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert einen einzelnen Adressdatensatz anhand des Adressschlüssels inklusive Länderangaben, Bankdaten und Zahlungsart.\n\nLiest eine Adresse anhand ihres Primärschlüssels `AddrKey` aus der Adresstabelle von Pixi.\n\n- Gefiltert wird über `AddrKey = @AddrKey`. Es wird höchstens eine Zeile geliefert.\n- Das Land der Adresse (`Country`) wird über den Ländercode mit der Ländertabelle verknüpft. Ländername sowie ISO-2- und ISO-3-Code werden ergänzt. Existiert kein passendes Land, bleiben diese Spalten leer.\n- Neben den Kontaktdaten (Name, Firma, Straße, PLZ, Ort, Telefon, Fax, E-Mail) enthält das Ergebnis die externe Kundennummer, den verknüpften Kundenschlüssel (`CustKey`), die USt-IdNr., das Geburtsdatum, eine Notiz, Bankdaten (Kontonummer, Kontoinhaber, BLZ, Bankname, BIC, IBAN) und die an der Adresse hinterlegte Zahlungsart.\n- Mehrere Spalten werden in der Ausgabe umbenannt, z. B. `Anrede` zu `Title`, `CareOf` zu `Company`, `AdrCustRef` zu `CustKey` und `UsStId` zu `VatID`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AddrKey` | int | Ja | Primärschlüssel der zu liefernden Adresse. |\n\n- Beide Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein.\n- Existiert keine Adresse mit dem angegebenen Schlüssel, ist die Ergebnismenge leer; eine Fehlermeldung wird nicht geliefert.\n- Das Ergebnis enthält Bankdaten (IBAN, BIC, Kontonummer). Diese sind gemäß Datenschutzanforderungen zu behandeln.\n- Die Datentypen der Spalten sind in der Prozedur nicht ersichtlich; die hier angegebenen Typen sind durch den Code nicht belegt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetAddress"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 104527\n 1\n K-20931\n Frau\n Anna Müller\n Anna\n Müller\n Müller GmbH\n Hauptstraße 12\n Hauptstraße\n 12\n München\n 80331\n D\n +49 89 123456\n \n anna.mueller@example.de\n 2023-05-14T10:22:31\n \n 55210\n DE123456789\n Deutschland\n DE\n DEU\n \n Anna Müller\n \n Musterbank\n MUSTDEMMXXX\n DE89370400440532013000\n RECHNUNG\n 1985-03-02T00:00:00\n \n"
}
]
},
{
"name": "pixiGetAddressesByEmail",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n max.mustermann@example.com\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Adressen, deren E-Mail-Adresse dem angegebenen Wert entspricht, optional eingeschränkt auf einen Shop.\n\nDurchsucht die Adresstabelle nach Datensätzen, deren `eMail` dem Parameter `Email` entspricht.\n\n- Ist `ShopId` `NULL` oder leer, werden Adressen aller Shops geliefert.\n- Andernfalls werden nur Adressen geliefert, deren Shop (`AddrShopID`) gleich `ShopId` ist.\n\nZu jeder Adresse werden die Adressdaten, die externe Kundennummer, der verknüpfte Kundenschlüssel (`CustKey`) sowie Ländername und ISO-Codes aus der Ländertabelle geliefert. Die Länderdaten werden per Left Outer Join ergänzt, sodass Adressen mit unbekanntem Ländercode trotzdem mit leeren Länderspalten erscheinen.\n\nEine Sortierreihenfolge ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Email` | varchar(60) | Ja | Zu suchende E-Mail-Adresse (exakter Vergleich mit der E-Mail der Adresse). |\n| `ShopId` | char(3) | Nein | Optionale Shop-ID. Wenn gesetzt, werden nur Adressen dieses Shops geliefert; `NULL` oder leer liefert Adressen aller Shops. |\n\n- Liest mit `NOLOCK`; nicht festgeschriebene Daten können geliefert werden.\n- Der E-Mail-Vergleich ist ein exakter Gleichheitsvergleich; ob Groß-/Kleinschreibung beachtet wird, hängt von der Collation der Datenbank ab. Platzhalter werden nicht unterstützt.\n- Mehrere Zeilen pro E-Mail-Adresse sind üblich, z. B. für verschiedene Kunden oder Adresstypen (Rechnungs- und Lieferadressen).\n- Gibt es keinen Treffer, wird eine leere Ergebnismenge geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetAddressesByEmail"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n max.mustermann@example.com\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Adressen, deren E-Mail-Adresse dem angegebenen Wert entspricht, optional eingeschränkt auf einen Shop.\n\nDurchsucht die Adresstabelle nach Datensätzen, deren `eMail` dem Parameter `Email` entspricht.\n\n- Ist `ShopId` `NULL` oder leer, werden Adressen aller Shops geliefert.\n- Andernfalls werden nur Adressen geliefert, deren Shop (`AddrShopID`) gleich `ShopId` ist.\n\nZu jeder Adresse werden die Adressdaten, die externe Kundennummer, der verknüpfte Kundenschlüssel (`CustKey`) sowie Ländername und ISO-Codes aus der Ländertabelle geliefert. Die Länderdaten werden per Left Outer Join ergänzt, sodass Adressen mit unbekanntem Ländercode trotzdem mit leeren Länderspalten erscheinen.\n\nEine Sortierreihenfolge ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Email` | varchar(60) | Ja | Zu suchende E-Mail-Adresse (exakter Vergleich mit der E-Mail der Adresse). |\n| `ShopId` | char(3) | Nein | Optionale Shop-ID. Wenn gesetzt, werden nur Adressen dieses Shops geliefert; `NULL` oder leer liefert Adressen aller Shops. |\n\n- Liest mit `NOLOCK`; nicht festgeschriebene Daten können geliefert werden.\n- Der E-Mail-Vergleich ist ein exakter Gleichheitsvergleich; ob Groß-/Kleinschreibung beachtet wird, hängt von der Collation der Datenbank ab. Platzhalter werden nicht unterstützt.\n- Mehrere Zeilen pro E-Mail-Adresse sind üblich, z. B. für verschiedene Kunden oder Adresstypen (Rechnungs- und Lieferadressen).\n- Gibt es keinen Treffer, wird eine leere Ergebnismenge geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetAddressesByEmail"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 48213\n R\n 100245\n Herr\n Max Mustermann\n Max\n Mustermann\n \n Musterstraße 12\n Musterstraße\n 12\n München\n 80331\n D\n 089 123456\n \n max.mustermann@example.com\n 2023-05-14T10:22:31\n \n 15032\n Deutschland\n DE\n DEU\n \n"
}
]
},
{
"name": "pixiGetCAEventsAndReminders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n SHP\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kundenkonto-Ereignisse (Rechnungen, Ausgleiche/Zahlungen, Mahnungen und virtuelle Vollzahlungs-Ereignisse) eines Shops in einem Zeitraum inkl. Saldo und Mahnstufen.\n\nSammelt alle Kundenkonto-Ereignisse der Kunden des Shops `ShopId` in einem Zeitraum und liefert sie als gemeinsame Ereignisliste. Mahnungsversand und vollständige Bezahlung von Rechnungen werden als zusätzliche Ereignisse behandelt.\n\n**Zeitraum**\n- Ist `StartDate` NULL, beginnt der Zeitraum am Ersten des aktuellen Monats. Andernfalls beginnt er um 00:00 Uhr von `StartDate`.\n- Ist `EndDate` NULL, endet der Zeitraum am Ende des heutigen Tages. Andernfalls endet er um 23:59:59.997 von `EndDate`.\n\n**Erfasste Ereignisarten**\n1. **Rechnungsereignisse**: Einträge in `CustomerAccount` mit `EventID = 'INV'`, deren `EventDate` im Zeitraum liegt. `EventKey` = `CAE_`.\n2. **Mahnungsereignisse**: Mahnungen (`Reminders` verknüpft mit `ReminderLines`), deren `ReminderSentDate` im Zeitraum liegt. Sie werden mit `EventID = 'REM'` geliefert. Der Betrag ist der negative Wert aus Mahnsumme minus Mahnkosten, `ReminderLevel` stammt aus der Mahnposition. `EventKey` = `REM_`.\n3. **Ausgleichsereignisse**: Datensätze in `CustomerAccountMatch`, die im Zeitraum angelegt wurden und einen Rechnungseintrag (`EventID = 'INV'`) mit einem anderen Kundenkontoeintrag verknüpfen. Beide Verknüpfungsrichtungen werden berücksichtigt. Die Zeile trägt `EventID` und `EventDate` des Gegeneintrags (z. B. einer Zahlung). Der Betrag ist der absolute Ausgleichsbetrag, `EventUpdateDate` das Anlagedatum des Ausgleichs. `EventKey` = `CAM_`.\n4. **Virtuelle Vollzahlungsereignisse**: Für eine Rechnung eines gelieferten Kunden, deren Ausgleiche bis `EndDate` genau die Rechnungssumme ergeben, wird ein virtuelles Ereignis mit `EventID = 'REM'` und Betrag 0 erzeugt. Sein Datum ist das letzte Ausgleichsdatum plus 1 ms. Der Kunde muss zusätzlich mindestens ein Ausgleichsereignis im Zeitraum haben, und das Ereignis entfällt, wenn sein Datum vor dem Zeitraumbeginn liegt. `EventKey` = `FPY_`.\n\n**Kundenfilter**\n- Es werden nur Kunden geliefert, deren `CustomerOf` gleich `ShopId` ist.\n- Bei `CustomerNumberIsNumeric = 1` werden nur Kunden geliefert, deren `CustomerNrExternal` ausschließlich aus Ziffern besteht. Bei `0` (Standard oder NULL) werden alle Kunden des Shops geliefert.\n\n**Mahnstufen**\n- Für jede Rechnung ohne virtuelles Vollzahlungsereignis wird der höchste `HighestReminderLevel` aller Mahnungen ermittelt, die die Rechnung enthalten (Rechnungsdatum vor `EndDate`).\n- Dieser Wert wird in `ReminderLevel` aller Nicht-`REM`-Ereignisse der Rechnung geschrieben.\n- `CustomerReminderLevel` ist das Maximum dieser Stufen über alle offenen Rechnungen des Kunden. Es wird bei allen Ereignissen des Kunden gesetzt.\n\n**Beträge und Währungen**\n- `Balance_ShopCurr` ist die Summe aller Kundenkontobeträge mit `EventDate` vor `EndDate`.\n- Ist die Einstellung `MultiCurrencyEnabled` gleich 1, werden diese Beträge mit dem Wechselkurs des aktuellen Tages umgerechnet.\n- `Amount_ShopCurr` ist der auf dieselbe Weise umgerechnete Ereignisbetrag. Ein fehlender Kurs zählt als 1.\n\n**Ausgabe**\n- Jede Ereigniszeile enthält die externe Kundennummer, die Rechnungsnummer und die externe Auftragsnummer.\n- Geliefert werden nur Ereignisse, die einer Rechnung in `Invoices` zugeordnet werden können.\n- Das Ergebnis ist `DISTINCT` und nach `EventUpdateDate`, dann `EventDate` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | Nein | Beginn des Zeitraums (Uhrzeit wird ignoriert, es gilt 00:00 Uhr). NULL bedeutet der Erste des aktuellen Monats. |\n| `EndDate` | datetime | Nein | Ende des Zeitraums (es gilt das Ende des angegebenen Tages). NULL bedeutet das Ende des heutigen Tages. |\n| `ShopId` | varchar(3) | Ja | Shop, dessen Kunden geliefert werden (Vergleich mit `Customers.CustomerOf`). Darf nicht leer sein. |\n| `CustomerNumberIsNumeric` | bit | Nein | Beschränkt das Ergebnis auf Kunden mit rein numerischer externer Kundennummer. NULL wird als 0 behandelt. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Wechselkurse werden immer zum **aktuellen Datum** (`ExchDate` = heute) gelesen, nicht zum Ereignisdatum. Bei `MultiCurrencyEnabled = 1` und fehlendem Tageskurs fallen Einträge in Fremdwährung aus `Balance_ShopCurr` heraus (Division durch NULL). `Amount_ShopCurr` verwendet in diesem Fall den Kurs 1.\n- Die Einstellung `DoNOTChargeShipCostOnSecondDelivery` wird gelesen, aber nicht verwendet.\n- Eine Rechnung mit Positionen aus mehreren externen Aufträgen erzeugt je `OrderNrExternal` eine Zeile.\n- Mahnungszeilen entstehen durch doppelte Verknüpfung der Mahnpositionen. Eine Mahnung mit mehreren Positionen kann daher mehrere Zeilen mit unterschiedlichen Kombinationen aus `InvoiceNr` und `ReminderLevel` liefern.\n- Virtuelle `FPY_`-Ereignisse entstehen je Kundenkontoeintrag der Rechnung, daher sind mehrere `FPY_`-Zeilen pro Rechnung möglich.\n- Eine unbekannte `ShopId` liefert ein leeres Ergebnis, keinen Fehler.\n- Temporäre Tabellen werden am Ende über `util.TempTableDrop` (nicht beigefügt) gelöscht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCAEventsAndReminders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n SHP\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kundenkonto-Ereignisse (Rechnungen, Ausgleiche/Zahlungen, Mahnungen und virtuelle Vollzahlungs-Ereignisse) eines Shops in einem Zeitraum inkl. Saldo und Mahnstufen.\n\nSammelt alle Kundenkonto-Ereignisse der Kunden des Shops `ShopId` in einem Zeitraum und liefert sie als gemeinsame Ereignisliste. Mahnungsversand und vollständige Bezahlung von Rechnungen werden als zusätzliche Ereignisse behandelt.\n\n**Zeitraum**\n- Ist `StartDate` NULL, beginnt der Zeitraum am Ersten des aktuellen Monats. Andernfalls beginnt er um 00:00 Uhr von `StartDate`.\n- Ist `EndDate` NULL, endet der Zeitraum am Ende des heutigen Tages. Andernfalls endet er um 23:59:59.997 von `EndDate`.\n\n**Erfasste Ereignisarten**\n1. **Rechnungsereignisse**: Einträge in `CustomerAccount` mit `EventID = 'INV'`, deren `EventDate` im Zeitraum liegt. `EventKey` = `CAE_`.\n2. **Mahnungsereignisse**: Mahnungen (`Reminders` verknüpft mit `ReminderLines`), deren `ReminderSentDate` im Zeitraum liegt. Sie werden mit `EventID = 'REM'` geliefert. Der Betrag ist der negative Wert aus Mahnsumme minus Mahnkosten, `ReminderLevel` stammt aus der Mahnposition. `EventKey` = `REM_`.\n3. **Ausgleichsereignisse**: Datensätze in `CustomerAccountMatch`, die im Zeitraum angelegt wurden und einen Rechnungseintrag (`EventID = 'INV'`) mit einem anderen Kundenkontoeintrag verknüpfen. Beide Verknüpfungsrichtungen werden berücksichtigt. Die Zeile trägt `EventID` und `EventDate` des Gegeneintrags (z. B. einer Zahlung). Der Betrag ist der absolute Ausgleichsbetrag, `EventUpdateDate` das Anlagedatum des Ausgleichs. `EventKey` = `CAM_`.\n4. **Virtuelle Vollzahlungsereignisse**: Für eine Rechnung eines gelieferten Kunden, deren Ausgleiche bis `EndDate` genau die Rechnungssumme ergeben, wird ein virtuelles Ereignis mit `EventID = 'REM'` und Betrag 0 erzeugt. Sein Datum ist das letzte Ausgleichsdatum plus 1 ms. Der Kunde muss zusätzlich mindestens ein Ausgleichsereignis im Zeitraum haben, und das Ereignis entfällt, wenn sein Datum vor dem Zeitraumbeginn liegt. `EventKey` = `FPY_`.\n\n**Kundenfilter**\n- Es werden nur Kunden geliefert, deren `CustomerOf` gleich `ShopId` ist.\n- Bei `CustomerNumberIsNumeric = 1` werden nur Kunden geliefert, deren `CustomerNrExternal` ausschließlich aus Ziffern besteht. Bei `0` (Standard oder NULL) werden alle Kunden des Shops geliefert.\n\n**Mahnstufen**\n- Für jede Rechnung ohne virtuelles Vollzahlungsereignis wird der höchste `HighestReminderLevel` aller Mahnungen ermittelt, die die Rechnung enthalten (Rechnungsdatum vor `EndDate`).\n- Dieser Wert wird in `ReminderLevel` aller Nicht-`REM`-Ereignisse der Rechnung geschrieben.\n- `CustomerReminderLevel` ist das Maximum dieser Stufen über alle offenen Rechnungen des Kunden. Es wird bei allen Ereignissen des Kunden gesetzt.\n\n**Beträge und Währungen**\n- `Balance_ShopCurr` ist die Summe aller Kundenkontobeträge mit `EventDate` vor `EndDate`.\n- Ist die Einstellung `MultiCurrencyEnabled` gleich 1, werden diese Beträge mit dem Wechselkurs des aktuellen Tages umgerechnet.\n- `Amount_ShopCurr` ist der auf dieselbe Weise umgerechnete Ereignisbetrag. Ein fehlender Kurs zählt als 1.\n\n**Ausgabe**\n- Jede Ereigniszeile enthält die externe Kundennummer, die Rechnungsnummer und die externe Auftragsnummer.\n- Geliefert werden nur Ereignisse, die einer Rechnung in `Invoices` zugeordnet werden können.\n- Das Ergebnis ist `DISTINCT` und nach `EventUpdateDate`, dann `EventDate` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | Nein | Beginn des Zeitraums (Uhrzeit wird ignoriert, es gilt 00:00 Uhr). NULL bedeutet der Erste des aktuellen Monats. |\n| `EndDate` | datetime | Nein | Ende des Zeitraums (es gilt das Ende des angegebenen Tages). NULL bedeutet das Ende des heutigen Tages. |\n| `ShopId` | varchar(3) | Ja | Shop, dessen Kunden geliefert werden (Vergleich mit `Customers.CustomerOf`). Darf nicht leer sein. |\n| `CustomerNumberIsNumeric` | bit | Nein | Beschränkt das Ergebnis auf Kunden mit rein numerischer externer Kundennummer. NULL wird als 0 behandelt. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Wechselkurse werden immer zum **aktuellen Datum** (`ExchDate` = heute) gelesen, nicht zum Ereignisdatum. Bei `MultiCurrencyEnabled = 1` und fehlendem Tageskurs fallen Einträge in Fremdwährung aus `Balance_ShopCurr` heraus (Division durch NULL). `Amount_ShopCurr` verwendet in diesem Fall den Kurs 1.\n- Die Einstellung `DoNOTChargeShipCostOnSecondDelivery` wird gelesen, aber nicht verwendet.\n- Eine Rechnung mit Positionen aus mehreren externen Aufträgen erzeugt je `OrderNrExternal` eine Zeile.\n- Mahnungszeilen entstehen durch doppelte Verknüpfung der Mahnpositionen. Eine Mahnung mit mehreren Positionen kann daher mehrere Zeilen mit unterschiedlichen Kombinationen aus `InvoiceNr` und `ReminderLevel` liefern.\n- Virtuelle `FPY_`-Ereignisse entstehen je Kundenkontoeintrag der Rechnung, daher sind mehrere `FPY_`-Zeilen pro Rechnung möglich.\n- Eine unbekannte `ShopId` liefert ein leeres Ergebnis, keinen Fehler.\n- Temporäre Tabellen werden am Ende über `util.TempTableDrop` (nicht beigefügt) gelöscht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCAEventsAndReminders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 100234\n RE2024-00451\n WEB-77812\n INV\n 119.0000\n EUR\n 2024-03-04T10:15:00\n 119.0000\n EUR\n 119.0000\n 1\n 1\n CAE_558812\n 2024-03-04T10:15:00\n \n \n 100234\n RE2024-00451\n WEB-77812\n REM\n -119.0000\n EUR\n 2024-03-20T08:00:00\n -119.0000\n EUR\n 119.0000\n 1\n 1\n REM_3311\n 2024-03-20T08:00:00\n \n"
}
]
},
{
"name": "pixiGetChangedCustomers",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T00:00:00\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kunden, die seit einem Zeitpunkt angelegt oder geändert wurden, optional bis zu einem Enddatum, sortiert nach Änderungsdatum und begrenzt auf eine maximale Zeilenzahl.\n\nLiest die Kundentabelle und liefert alle Kunden, deren Änderungsdatum im angefragten Zeitraum liegt. Der Aufruf dient typischerweise der inkrementellen (Delta-)Synchronisation von Kunden in ein externes System.\n\n- Das **Änderungsdatum** eines Kunden ist sein `UpdateDate` bzw. sein `CreateDate`, falls der Kunde nie geändert wurde. Dieser Wert wird auch in der Spalte `UpdateDate` zurückgegeben.\n- Ist `To` nicht angegeben oder leer, werden alle Kunden mit Änderungsdatum `>= Since` geliefert.\n- Ist `To` gesetzt, werden Kunden mit Änderungsdatum zwischen `Since` und `To` (jeweils inklusive) geliefert.\n- Das Ergebnis ist aufsteigend nach Änderungsdatum sortiert (älteste Änderung zuerst).\n- Es werden höchstens `Rowcount` Zeilen geliefert (Standard `1000`).\n\nJe Kunde werden Kundenschlüssel, die Schlüssel der Rechnungs- und Lieferadresse, ein Liefersperre-Kennzeichen, der Wert `CustomerOf`, E-Mail-Adresse und Name geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Ja | Beginn des Zeitraums (inklusive). Geliefert werden Kunden, deren Änderungsdatum (`UpdateDate`, sonst `CreateDate`) gleich oder später ist. |\n| `To` | datetime | Nein | Optionales Ende des Zeitraums (inklusive). Fehlt der Wert oder ist er leer, gibt es keine Obergrenze. |\n| `Rowcount` | int | Nein | Maximale Anzahl gelieferter Zeilen. `0` bedeutet keine Begrenzung. |\n\n- Die Tabelle wird `WITH (NOLOCK)` gelesen; nicht festgeschriebene Änderungen können daher geliefert werden.\n- Die Begrenzung erfolgt über `SET ROWCOUNT`. Mit `Rowcount` = `0` entfällt die Begrenzung, und alle passenden Zeilen werden geliefert.\n- Die Prüfung auf ein leeres `To` vergleicht mit `''`, was SQL Server in `1900-01-01 00:00:00` umwandelt. Genau dieses Datum als `To` wird daher wie ein fehlendes Enddatum behandelt.\n- Vorgehen beim Blättern: das höchste gelieferte `UpdateDate` als nächstes `Since` verwenden. Da der Filter `>=` lautet, werden die letzten Datensätze erneut geliefert; nach `CustKey` deduplizieren. Es gibt kein zweites Sortierkriterium – haben mehr als `Rowcount` Kunden dasselbe Änderungsdatum, kommt die Schleife nicht weiter; in diesem Fall `Rowcount` erhöhen.\n- `ShipLock` ist `1`, wenn das Kundenfeld `SLocked` den Wert `Y` hat, sonst `0`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedCustomers"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T00:00:00\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kunden, die seit einem Zeitpunkt angelegt oder geändert wurden, optional bis zu einem Enddatum, sortiert nach Änderungsdatum und begrenzt auf eine maximale Zeilenzahl.\n\nLiest die Kundentabelle und liefert alle Kunden, deren Änderungsdatum im angefragten Zeitraum liegt. Der Aufruf dient typischerweise der inkrementellen (Delta-)Synchronisation von Kunden in ein externes System.\n\n- Das **Änderungsdatum** eines Kunden ist sein `UpdateDate` bzw. sein `CreateDate`, falls der Kunde nie geändert wurde. Dieser Wert wird auch in der Spalte `UpdateDate` zurückgegeben.\n- Ist `To` nicht angegeben oder leer, werden alle Kunden mit Änderungsdatum `>= Since` geliefert.\n- Ist `To` gesetzt, werden Kunden mit Änderungsdatum zwischen `Since` und `To` (jeweils inklusive) geliefert.\n- Das Ergebnis ist aufsteigend nach Änderungsdatum sortiert (älteste Änderung zuerst).\n- Es werden höchstens `Rowcount` Zeilen geliefert (Standard `1000`).\n\nJe Kunde werden Kundenschlüssel, die Schlüssel der Rechnungs- und Lieferadresse, ein Liefersperre-Kennzeichen, der Wert `CustomerOf`, E-Mail-Adresse und Name geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Ja | Beginn des Zeitraums (inklusive). Geliefert werden Kunden, deren Änderungsdatum (`UpdateDate`, sonst `CreateDate`) gleich oder später ist. |\n| `To` | datetime | Nein | Optionales Ende des Zeitraums (inklusive). Fehlt der Wert oder ist er leer, gibt es keine Obergrenze. |\n| `Rowcount` | int | Nein | Maximale Anzahl gelieferter Zeilen. `0` bedeutet keine Begrenzung. |\n\n- Die Tabelle wird `WITH (NOLOCK)` gelesen; nicht festgeschriebene Änderungen können daher geliefert werden.\n- Die Begrenzung erfolgt über `SET ROWCOUNT`. Mit `Rowcount` = `0` entfällt die Begrenzung, und alle passenden Zeilen werden geliefert.\n- Die Prüfung auf ein leeres `To` vergleicht mit `''`, was SQL Server in `1900-01-01 00:00:00` umwandelt. Genau dieses Datum als `To` wird daher wie ein fehlendes Enddatum behandelt.\n- Vorgehen beim Blättern: das höchste gelieferte `UpdateDate` als nächstes `Since` verwenden. Da der Filter `>=` lautet, werden die letzten Datensätze erneut geliefert; nach `CustKey` deduplizieren. Es gibt kein zweites Sortierkriterium – haben mehr als `Rowcount` Kunden dasselbe Änderungsdatum, kommt die Schleife nicht weiter; in diesem Fall `Rowcount` erhöhen.\n- `ShipLock` ist `1`, wenn das Kundenfeld `SLocked` den Wert `Y` hat, sonst `0`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedCustomers"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n 23011\n 23012\n false\n SHOP1\n anna.mueller@example.de\n Anna Müller\n 2024-05-02T09:14:33.217\n \n \n 10988\n 24170\n 24170\n true\n SHOP1\n info@beispiel-gmbh.de\n Beispiel GmbH\n 2024-05-02T11:40:05.003\n \n"
}
]
},
{
"name": "pixiGetComments",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Kommentare eines Kunden (aus der Kundenhistorie) und/oder eines Auftrags, neueste zuerst, mit Offset-basiertem Paging.\n\nSammelt Kommentare zu einem Kunden, einem Auftrag oder beiden und liefert sie in einer gemeinsamen Liste.\n\n1. Sind `CustomerNrExternal` und `OrderNr` beide `NULL` oder leer, wird eine einzelne Fehlerzeile (`ReturnCode` = `ERROR`) geliefert; sonst passiert nichts.\n2. Ist `CustomerNrExternal` nicht `NULL`, werden alle Einträge der Kundenhistorie mit einem Notiztext ungleich `NULL` für den Kunden mit dieser externen Kundennummer als Typ `CustomerComment` gesammelt. Sie werden nach Änderungsdatum der Historie absteigend (neueste zuerst) nummeriert.\n3. Ist `OrderNr` nicht `NULL`, werden alle Auftragskommentare dieser Auftragsnummer als Typ `OrderComment` angehängt (innerhalb dieser Gruppe ohne definierte Reihenfolge).\n4. Jede gesammelte Zeile erhält eine laufende Nummer `Offset` ab 0 in der Reihenfolge der Sammlung (zuerst Kundenkommentare, dann Auftragskommentare).\n5. Geliefert werden höchstens `RowCount` Zeilen, deren `Offset` größer oder gleich `@Offset` ist, sortiert nach `Date` absteigend.\n\nBeide Filter sind kombinierbar; die Kommentare werden dann in einer Ergebnismenge zusammengeführt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustomerNrExternal` | varchar(255) | Nein | Externe Kundennummer. Wenn gesetzt, werden die Historienkommentare des Kunden geliefert. |\n| `OrderNr` | varchar(50) | Nein | Auftragsnummer. Wenn gesetzt, werden die Kommentare dieses Auftrags geliefert. |\n| `Offset` | int | Nein | Nullbasierte laufende Nummer, ab der Zeilen geliefert werden (Paging). |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen; 0 bedeutet keine Begrenzung. |\n\n- Die Nummerierung `Offset` folgt der Sammelreihenfolge (Kundenkommentare nach Datum absteigend, danach Auftragskommentare in undefinierter Reihenfolge), die Ausgabe ist jedoch nach `Date` absteigend sortiert. Bei Angabe beider Filter entspricht das Paging über `@Offset` daher nicht zwingend der angezeigten Datumsreihenfolge.\n- `SET ROWCOUNT` begrenzt die Ausgabe; `RowCount` = 0 liefert alle Zeilen.\n- Die Leer-Prüfung lehnt den Aufruf nur ab, wenn beide Werte leer sind. Ein Leerstring (nicht `NULL`) in einem Parameter führt den jeweiligen Zweig trotzdem aus, z. B. sucht `CustomerNrExternal` = '' nach Kunden mit leerer externer Nummer.\n- `Offset` ist ein `smallint`; mehr als 32.767 gesammelte Kommentare würden einen Überlauffehler verursachen.\n- Es werden keine `NOLOCK`-Hinweise verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetComments"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Kommentare eines Kunden (aus der Kundenhistorie) und/oder eines Auftrags, neueste zuerst, mit Offset-basiertem Paging.\n\nSammelt Kommentare zu einem Kunden, einem Auftrag oder beiden und liefert sie in einer gemeinsamen Liste.\n\n1. Sind `CustomerNrExternal` und `OrderNr` beide `NULL` oder leer, wird eine einzelne Fehlerzeile (`ReturnCode` = `ERROR`) geliefert; sonst passiert nichts.\n2. Ist `CustomerNrExternal` nicht `NULL`, werden alle Einträge der Kundenhistorie mit einem Notiztext ungleich `NULL` für den Kunden mit dieser externen Kundennummer als Typ `CustomerComment` gesammelt. Sie werden nach Änderungsdatum der Historie absteigend (neueste zuerst) nummeriert.\n3. Ist `OrderNr` nicht `NULL`, werden alle Auftragskommentare dieser Auftragsnummer als Typ `OrderComment` angehängt (innerhalb dieser Gruppe ohne definierte Reihenfolge).\n4. Jede gesammelte Zeile erhält eine laufende Nummer `Offset` ab 0 in der Reihenfolge der Sammlung (zuerst Kundenkommentare, dann Auftragskommentare).\n5. Geliefert werden höchstens `RowCount` Zeilen, deren `Offset` größer oder gleich `@Offset` ist, sortiert nach `Date` absteigend.\n\nBeide Filter sind kombinierbar; die Kommentare werden dann in einer Ergebnismenge zusammengeführt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustomerNrExternal` | varchar(255) | Nein | Externe Kundennummer. Wenn gesetzt, werden die Historienkommentare des Kunden geliefert. |\n| `OrderNr` | varchar(50) | Nein | Auftragsnummer. Wenn gesetzt, werden die Kommentare dieses Auftrags geliefert. |\n| `Offset` | int | Nein | Nullbasierte laufende Nummer, ab der Zeilen geliefert werden (Paging). |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen; 0 bedeutet keine Begrenzung. |\n\n- Die Nummerierung `Offset` folgt der Sammelreihenfolge (Kundenkommentare nach Datum absteigend, danach Auftragskommentare in undefinierter Reihenfolge), die Ausgabe ist jedoch nach `Date` absteigend sortiert. Bei Angabe beider Filter entspricht das Paging über `@Offset` daher nicht zwingend der angezeigten Datumsreihenfolge.\n- `SET ROWCOUNT` begrenzt die Ausgabe; `RowCount` = 0 liefert alle Zeilen.\n- Die Leer-Prüfung lehnt den Aufruf nur ab, wenn beide Werte leer sind. Ein Leerstring (nicht `NULL`) in einem Parameter führt den jeweiligen Zweig trotzdem aus, z. B. sucht `CustomerNrExternal` = '' nach Kunden mit leerer externer Nummer.\n- `Offset` ist ein `smallint`; mehr als 32.767 gesammelte Kommentare würden einen Überlauffehler verursachen.\n- Es werden keine `NOLOCK`-Hinweise verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetComments"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 0\n CustomerComment\n 2024-03-12T10:15:00\n MM\n Kunde wünscht Lieferung nur vormittags.\n \n \n 1\n CustomerComment\n 2023-11-02T14:40:00\n AS\n Rechnungsadresse geändert.\n \n"
}
]
},
{
"name": "pixiGetCRMCustomerData",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kunden mit ihren Hauptadressdaten seitenweise nach CustKey sortiert, gedacht für den Abgleich mit CRM-Systemen.\n\nLiefert Kundendatensätze zusammen mit der beim Kunden hinterlegten Adresse (`AddrRef`).\n\n- Es werden nur Kunden mit `CustKey` größer als `CustKeyStart` geliefert.\n- Ist `CustomerOf` leer oder NULL, werden Kunden aller Shops geliefert, andernfalls nur Kunden mit passendem `CustomerOf`.\n- Es werden höchstens `Rows` Zeilen geliefert, aufsteigend nach `CustKey` sortiert.\n\n**Paging:** Mit `CustKeyStart = 0` beginnen und beim nächsten Aufruf den höchsten `CustKey` der vorherigen Seite als `CustKeyStart` übergeben. Werden weniger als `Rows` Zeilen geliefert, ist das Ende erreicht.\n\nEine leere `VATID` wird als NULL geliefert. `Locked` ist `Y`, wenn der Kunde für den Verkauf (`SLocked`) oder die Lieferung (`DLocked`) gesperrt ist, sonst `N`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKeyStart` | int | Nein | Es werden nur Kunden mit einem `CustKey` größer als dieser Wert geliefert. Für Paging den letzten `CustKey` der vorherigen Seite übergeben. |\n| `Rows` | int | Nein | Maximale Anzahl gelieferter Zeilen (Seitengröße). |\n| `CustomerOf` | varchar(3) | Nein | Shop-Kürzel, dem der Kunde zugeordnet ist. Leer oder NULL liefert Kunden aller Shops. |\n\n- Die Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können sichtbar sein, und bei gleichzeitigen Schreibvorgängen können Zeilen fehlen oder doppelt erscheinen.\n- Die Adresse wird per LEFT JOIN angebunden; Kunden ohne passende Adresse werden mit NULL in den Adressspalten geliefert.\n- Trotz des Kopfkommentars zu \"sicheren XML-Werten\" werden die Werte außer `VATID` und `Locked` nicht umgewandelt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCRMCustomerData"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kunden mit ihren Hauptadressdaten seitenweise nach CustKey sortiert, gedacht für den Abgleich mit CRM-Systemen.\n\nLiefert Kundendatensätze zusammen mit der beim Kunden hinterlegten Adresse (`AddrRef`).\n\n- Es werden nur Kunden mit `CustKey` größer als `CustKeyStart` geliefert.\n- Ist `CustomerOf` leer oder NULL, werden Kunden aller Shops geliefert, andernfalls nur Kunden mit passendem `CustomerOf`.\n- Es werden höchstens `Rows` Zeilen geliefert, aufsteigend nach `CustKey` sortiert.\n\n**Paging:** Mit `CustKeyStart = 0` beginnen und beim nächsten Aufruf den höchsten `CustKey` der vorherigen Seite als `CustKeyStart` übergeben. Werden weniger als `Rows` Zeilen geliefert, ist das Ende erreicht.\n\nEine leere `VATID` wird als NULL geliefert. `Locked` ist `Y`, wenn der Kunde für den Verkauf (`SLocked`) oder die Lieferung (`DLocked`) gesperrt ist, sonst `N`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKeyStart` | int | Nein | Es werden nur Kunden mit einem `CustKey` größer als dieser Wert geliefert. Für Paging den letzten `CustKey` der vorherigen Seite übergeben. |\n| `Rows` | int | Nein | Maximale Anzahl gelieferter Zeilen (Seitengröße). |\n| `CustomerOf` | varchar(3) | Nein | Shop-Kürzel, dem der Kunde zugeordnet ist. Leer oder NULL liefert Kunden aller Shops. |\n\n- Die Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können sichtbar sein, und bei gleichzeitigen Schreibvorgängen können Zeilen fehlen oder doppelt erscheinen.\n- Die Adresse wird per LEFT JOIN angebunden; Kunden ohne passende Adresse werden mit NULL in den Adressspalten geliefert.\n- Trotz des Kopfkommentars zu \"sicheren XML-Werten\" werden die Werte außer `VATID` und `Locked` nicht umgewandelt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCRMCustomerData"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1001\n K-50231\n SHP\n Herr\n Max Mustermann\n \n Max\n Mustermann\n Hauptstraße\n 12\n Hauptstraße 12\n 80331\n München\n BY\n DE\n max@example.com\n +49 89 123456\n \n N\n 1980-05-17T00:00:00\n \n \n"
}
]
},
{
"name": "pixiGetCRMCustomers",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert CRM-Kennzahlen je Kunde (Bestellabstände, Auftragsanzahlen, Nettoumsätze und Retourenbeträge je Zeitraum), berechnet aus Rechnungen und Aufträgen.\n\nBerechnet je Kunde eine Zeile mit Kundenlebenszyklus-Kennzahlen auf Basis von Rechnungen und Aufträgen.\n\n**Rechnungen**\n- Als Basis werden nur Rechnungen mit `Total > 0` verwendet. Gefiltert wird nach `InvDate` zwischen `CalculationStart` und `CalculationEnd` (jede Grenze nur, wenn gesetzt), nach dem Rechnungsshop `InvShopID` = `CustomerOf` (falls nicht leer) und nach `CustRef` (falls nicht 0/NULL).\n- Beträge sind **Nettobeträge** (`Total_Net` bzw. `Total_Net - Total_ShipCost_Net` für die Werte ohne Versandkosten).\n- Retourenbeträge je Rechnung ergeben sich als 0 minus Summe der Nettobeträge aller Rechnungen, die über `RefToInvoiceKey` auf diese Rechnung verweisen (Gutschriften). Diese verweisenden Rechnungen werden nicht nach Datum oder Shop gefiltert.\n- Ist die Einstellung `MultiCurrencyEnabled` gleich `1`, werden alle Beträge durch den Wechselkurs der Rechnung (`ExchRateId`) geteilt und `BaseCurrency` enthält den Code der Basiswährung dieses Wechselkurses. Andernfalls werden die Beträge in der ursprünglichen Rechnungswährung geliefert und `BaseCurrency` ist NULL.\n\n**Aufträge**\n- Aufträge werden nach `UpdateDate` zwischen `CalculationStart` und `CalculationEnd`, nach `CustomerOf` des Kunden und nach `CustRef` gefiltert. Sie werden je Auftragsnummer gruppiert; als Auftragsdatum gilt das späteste `CreateDate` des Auftrags.\n- Daraus werden je Kunde das Datum des ersten, zweiten (nächsthöhere Auftragsnummer) und letzten Auftrags ermittelt.\n\n**Ergebnis**\n- Je Kunde: Tage seit dem ersten/letzten Auftrag sowie zwischen erstem/zweitem und erstem/letztem Auftrag (bezogen auf das aktuelle Datum), Auftragsanzahlen der letzten 90/365/730 Tage und gesamt, Beträge der ersten, zweiten und letzten Rechnung (Spalten `FirstOrder…`, `SecondOrder…`, `LastOrder…`), Beträge im ersten und zweiten Jahr nach der ersten Rechnung, in den 365 Tagen vor der letzten Rechnung, in den beiden 365-Tage-Fenstern vor `CalculationEnd` (bzw. jetzt) sowie Gesamtsummen.\n- Es werden nur Kunden mit mindestens einer passenden Rechnung geliefert.\n- Paging: höchstens `Rows` Zeilen mit `CustKey > Offset`, sortiert nach `CustKey` aufsteigend. `Offset` ist ein Kundenschlüssel, keine Zeilenanzahl: für die nächste Seite den letzten `CustKey` der vorherigen Seite übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustomerOf` | varchar(3) | Nein | Shop-ID. Filtert Rechnungen nach `InvShopID` und Aufträge nach `CustomerOf` des Kunden. NULL oder leer = alle Shops. |\n| `CalculationStart` | datetime | Nein | Untergrenze für Rechnungsdatum (`InvDate`) und Änderungsdatum des Auftrags (`UpdateDate`). NULL = keine Untergrenze. |\n| `CalculationEnd` | datetime | Nein | Obergrenze für Rechnungsdatum und Änderungsdatum des Auftrags. Zugleich Bezugsdatum der `…FromNow…`-Spalten; bei NULL dient das aktuelle Datum als Bezug und es gibt keine Obergrenze. |\n| `CustRef` | int | Nein | Kundenschlüssel, um die Berechnung auf einen Kunden zu beschränken. NULL oder 0 = alle Kunden. |\n| `Rows` | int | Nein | Maximale Anzahl gelieferter Zeilen (Seitengröße). |\n| `Offset` | int | Nein | Es werden nur Kunden mit `CustKey` größer als dieser Wert geliefert. Für die nächste Seite den letzten `CustKey` der vorherigen Seite übergeben. |\n\n- Nur lesend; alle permanenten Tabellen außer `Customers` werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten enthalten sein.\n- Die Spalten `FirstOrderTotal`, `SecondOrderTotal`, `LastOrderTotal` usw. stammen aus der ersten, zweiten und letzten **Rechnung** (nach `InvoiceKey`), nicht aus Aufträgen.\n- Tagesstatistiken und die Auftragsanzahlen für 90/365/730 Tage beziehen sich immer auf `GETDATE()`, die `…FromNow…`-Beträge dagegen auf `CalculationEnd` (bzw. das aktuelle Datum, falls nicht gesetzt).\n- Zeitfenstergrenzen sind teilweise exklusiv: `SecondYear…` berücksichtigt z. B. nur Daten strikt nach erster Rechnung + 365 Tage und strikt vor + 730 Tage; Rechnungen genau auf der Grenze zählen in keinem der beiden Jahre.\n- Der Shopfilter verwendet für Beträge `InvShopID` der Rechnung, für Aufträge aber `CustomerOf` des Kunden; Datumsfilter nutzen bei Rechnungen `InvDate`, bei Aufträgen `UpdateDate`.\n- Bei aktivierter Mehrwährungsfähigkeit werden Rechnungen ohne passenden Wechselkurs übersprungen. Ein Kunde mit Rechnungen in verschiedenen Basiswährungen erscheint je Basiswährung einmal; die Zeitraumsummen (`FirstYear…`, `LastYear…` usw.) werden dabei nicht nach Währung getrennt.\n- `DaysSince…`-Spalten sind NULL, wenn kein Auftrag des Kunden den Filtern entspricht.\n- Die Berechnung erfolgt über mehrere temporäre Tabellen und korrelierte Unterabfragen; eine Einschränkung des Datumsbereichs oder von `CustRef` verbessert die Laufzeit bei großen Datenbanken.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCRMCustomers"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert CRM-Kennzahlen je Kunde (Bestellabstände, Auftragsanzahlen, Nettoumsätze und Retourenbeträge je Zeitraum), berechnet aus Rechnungen und Aufträgen.\n\nBerechnet je Kunde eine Zeile mit Kundenlebenszyklus-Kennzahlen auf Basis von Rechnungen und Aufträgen.\n\n**Rechnungen**\n- Als Basis werden nur Rechnungen mit `Total > 0` verwendet. Gefiltert wird nach `InvDate` zwischen `CalculationStart` und `CalculationEnd` (jede Grenze nur, wenn gesetzt), nach dem Rechnungsshop `InvShopID` = `CustomerOf` (falls nicht leer) und nach `CustRef` (falls nicht 0/NULL).\n- Beträge sind **Nettobeträge** (`Total_Net` bzw. `Total_Net - Total_ShipCost_Net` für die Werte ohne Versandkosten).\n- Retourenbeträge je Rechnung ergeben sich als 0 minus Summe der Nettobeträge aller Rechnungen, die über `RefToInvoiceKey` auf diese Rechnung verweisen (Gutschriften). Diese verweisenden Rechnungen werden nicht nach Datum oder Shop gefiltert.\n- Ist die Einstellung `MultiCurrencyEnabled` gleich `1`, werden alle Beträge durch den Wechselkurs der Rechnung (`ExchRateId`) geteilt und `BaseCurrency` enthält den Code der Basiswährung dieses Wechselkurses. Andernfalls werden die Beträge in der ursprünglichen Rechnungswährung geliefert und `BaseCurrency` ist NULL.\n\n**Aufträge**\n- Aufträge werden nach `UpdateDate` zwischen `CalculationStart` und `CalculationEnd`, nach `CustomerOf` des Kunden und nach `CustRef` gefiltert. Sie werden je Auftragsnummer gruppiert; als Auftragsdatum gilt das späteste `CreateDate` des Auftrags.\n- Daraus werden je Kunde das Datum des ersten, zweiten (nächsthöhere Auftragsnummer) und letzten Auftrags ermittelt.\n\n**Ergebnis**\n- Je Kunde: Tage seit dem ersten/letzten Auftrag sowie zwischen erstem/zweitem und erstem/letztem Auftrag (bezogen auf das aktuelle Datum), Auftragsanzahlen der letzten 90/365/730 Tage und gesamt, Beträge der ersten, zweiten und letzten Rechnung (Spalten `FirstOrder…`, `SecondOrder…`, `LastOrder…`), Beträge im ersten und zweiten Jahr nach der ersten Rechnung, in den 365 Tagen vor der letzten Rechnung, in den beiden 365-Tage-Fenstern vor `CalculationEnd` (bzw. jetzt) sowie Gesamtsummen.\n- Es werden nur Kunden mit mindestens einer passenden Rechnung geliefert.\n- Paging: höchstens `Rows` Zeilen mit `CustKey > Offset`, sortiert nach `CustKey` aufsteigend. `Offset` ist ein Kundenschlüssel, keine Zeilenanzahl: für die nächste Seite den letzten `CustKey` der vorherigen Seite übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustomerOf` | varchar(3) | Nein | Shop-ID. Filtert Rechnungen nach `InvShopID` und Aufträge nach `CustomerOf` des Kunden. NULL oder leer = alle Shops. |\n| `CalculationStart` | datetime | Nein | Untergrenze für Rechnungsdatum (`InvDate`) und Änderungsdatum des Auftrags (`UpdateDate`). NULL = keine Untergrenze. |\n| `CalculationEnd` | datetime | Nein | Obergrenze für Rechnungsdatum und Änderungsdatum des Auftrags. Zugleich Bezugsdatum der `…FromNow…`-Spalten; bei NULL dient das aktuelle Datum als Bezug und es gibt keine Obergrenze. |\n| `CustRef` | int | Nein | Kundenschlüssel, um die Berechnung auf einen Kunden zu beschränken. NULL oder 0 = alle Kunden. |\n| `Rows` | int | Nein | Maximale Anzahl gelieferter Zeilen (Seitengröße). |\n| `Offset` | int | Nein | Es werden nur Kunden mit `CustKey` größer als dieser Wert geliefert. Für die nächste Seite den letzten `CustKey` der vorherigen Seite übergeben. |\n\n- Nur lesend; alle permanenten Tabellen außer `Customers` werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten enthalten sein.\n- Die Spalten `FirstOrderTotal`, `SecondOrderTotal`, `LastOrderTotal` usw. stammen aus der ersten, zweiten und letzten **Rechnung** (nach `InvoiceKey`), nicht aus Aufträgen.\n- Tagesstatistiken und die Auftragsanzahlen für 90/365/730 Tage beziehen sich immer auf `GETDATE()`, die `…FromNow…`-Beträge dagegen auf `CalculationEnd` (bzw. das aktuelle Datum, falls nicht gesetzt).\n- Zeitfenstergrenzen sind teilweise exklusiv: `SecondYear…` berücksichtigt z. B. nur Daten strikt nach erster Rechnung + 365 Tage und strikt vor + 730 Tage; Rechnungen genau auf der Grenze zählen in keinem der beiden Jahre.\n- Der Shopfilter verwendet für Beträge `InvShopID` der Rechnung, für Aufträge aber `CustomerOf` des Kunden; Datumsfilter nutzen bei Rechnungen `InvDate`, bei Aufträgen `UpdateDate`.\n- Bei aktivierter Mehrwährungsfähigkeit werden Rechnungen ohne passenden Wechselkurs übersprungen. Ein Kunde mit Rechnungen in verschiedenen Basiswährungen erscheint je Basiswährung einmal; die Zeitraumsummen (`FirstYear…`, `LastYear…` usw.) werden dabei nicht nach Währung getrennt.\n- `DaysSince…`-Spalten sind NULL, wenn kein Auftrag des Kunden den Filtern entspricht.\n- Die Berechnung erfolgt über mehrere temporäre Tabellen und korrelierte Unterabfragen; eine Einschränkung des Datumsbereichs oder von `CustRef` verbessert die Laufzeit bei großen Datenbanken.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCRMCustomers"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10234\n 812\n 45\n 63\n 767\n 1\n 3\n 5\n 6\n 84.033613445\n 79.8319\n 0.000000000\n 0.0000\n 42.008403361\n 37.8067\n 42.008403361\n 37.8067\n 125.210084034\n 121.0084\n 0.000000000\n 0.0000\n 210.084033613\n 197.4790\n 42.008403361\n 37.8067\n 125.210084034\n 121.0084\n 0.000000000\n 0.0000\n 250.420168068\n 242.0168\n 0.000000000\n 0.0000\n 85.210084034\n 81.0084\n 0.000000000\n 0.0000\n 250.420168068\n 242.0168\n 0.000000000\n 0.0000\n 545.714285715\n 520.5042\n 42.008403361\n 37.8067\n EUR\n \n"
}
]
},
{
"name": "pixiGetCRMSales",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den kumulierten Netto-Umsatz je Kunde aus Rechnungen abzüglich referenzierender Gutschriften, optional gefiltert nach Shops und Rechnungsdatum, mit Keyset-Paging.\n\nBerechnet eine Umsatzkennzahl je Kunde (`CustKey`) aus den Rechnungen und liefert eine Zeile je Kunde und Basiswährung.\n\n**Ablauf**\n\n1. Ein leerer Wert in `CustomerOf` wird wie `NULL` behandelt. Ist er gesetzt, wird er als XML ausgewertet (`/SHOPS/SHOP`, Wert `SHOPID`, als Element oder Attribut). Es werden nur Shop-IDs berücksichtigt, die in `Shops` existieren.\n2. Rechnungen werden ausgewählt, wenn:\n - der Bruttobetrag `Total` größer als 0 ist (Gutschriften mit negativem Betrag zählen nicht als eigene Rechnung),\n - das Rechnungsdatum `InvDate` im Bereich `CalculationStart` … `CalculationEnd` liegt (beide Grenzen inklusive und optional),\n - bei gesetztem `CustomerOf` der Shop des Kunden (`CustomerOf`) zu den übergebenen Shops gehört.\n3. Je Rechnung werden der Nettobetrag (`Total_Net`) und der Nettobetrag ohne Versandkosten (`Total_Net - Total_ShipCost_Net`) herangezogen. Die Nettobeträge aller Rechnungen, die über `RefToInvoiceKey` auf diese Rechnung verweisen (in der Regel Gutschriften), werden zu diesen Werten addiert.\n4. **Währungsbehandlung** abhängig von der Einstellung `MultiCurrencyEnabled`:\n - nicht `1`: Beträge bleiben in der Originalwährung der Rechnung, `BaseCurrency` ist `NULL`;\n - `1`: jeder Betrag wird durch den Wechselkurs der Rechnung (`pixi.ExchRate`) geteilt, `BaseCurrency` enthält den Code der Basiswährung dieses Kurses.\n5. Die Ergebnisse werden nach `CustKey` und `BaseCurrency` gruppiert.\n\n**Paging**\n\nDas Paging arbeitet mit Schlüsseln: Es werden nur Kunden mit `CustKey` größer als `Offset` geliefert, aufsteigend nach `CustKey` sortiert und auf `Rows` Zeilen begrenzt. Für die nächste Seite wird der zuletzt gelieferte `CustKey` als `Offset` übergeben. `Offset` ist keine Zeilenanzahl.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustomerOf` | varchar(max) | Nein | XML-Liste von pixi*-Shops (`/SHOPS/SHOP/SHOPID`). Es werden nur Kunden dieser Shops ausgewertet. `NULL` oder leer: alle Kunden. |\n| `CalculationStart` | datetime | Nein | Frühestes Rechnungsdatum (inklusive). `NULL`: keine Untergrenze. |\n| `CalculationEnd` | datetime | Nein | Spätestes Rechnungsdatum (inklusive). `NULL`: keine Obergrenze. |\n| `Rows` | int | Nein | Maximale Anzahl gelieferter Zeilen. |\n| `Offset` | int | Nein | Es werden nur Kunden mit `CustKey` größer als dieser Wert geliefert. Den letzten `CustKey` der vorherigen Seite übergeben. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Ist `CustomerOf` gesetzt, aber keine der Shop-IDs existiert in `Shops`, werden keine Zeilen geliefert. Ungültiges XML führt zu einem Fehler von `sp_xml_preparedocument`.\n- Ohne Mehrwährung (`MultiCurrencyEnabled` ungleich `1`) werden Beträge verschiedener Rechnungswährungen ohne Umrechnung addiert.\n- Mit Mehrwährung werden Rechnungen ohne Wechselkurs (`ExchRateId` nicht in `pixi.ExchRate` vorhanden) ausgeschlossen; referenzierende Gutschriften ohne Wechselkurs fließen nicht in die Summen ein. Umgerechnete Beträge werden mit 9 Nachkommastellen gespeichert.\n- Mit Mehrwährung kann ein Kunde in mehreren Zeilen erscheinen (eine je Basiswährung). Da `Rows` Zeilen und nicht Kunden begrenzt, kann eine Seite mitten in den Zeilen eines Kunden enden; wird dieser `CustKey` als nächster `Offset` verwendet, entfallen die restlichen Zeilen dieses Kunden.\n- Der Datumsfilter gilt nur für die Hauptrechnung; referenzierende Gutschriften werden unabhängig von ihrem Datum einbezogen.\n- Ein Kennzeichen für Komplettretouren wird intern berechnet, aber nicht ausgegeben.\n- Die Datenbankwährung wird über `pixi.GetDatabaseCurrency()` gelesen, die Werte werden im Ergebnis jedoch nicht verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCRMSales"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den kumulierten Netto-Umsatz je Kunde aus Rechnungen abzüglich referenzierender Gutschriften, optional gefiltert nach Shops und Rechnungsdatum, mit Keyset-Paging.\n\nBerechnet eine Umsatzkennzahl je Kunde (`CustKey`) aus den Rechnungen und liefert eine Zeile je Kunde und Basiswährung.\n\n**Ablauf**\n\n1. Ein leerer Wert in `CustomerOf` wird wie `NULL` behandelt. Ist er gesetzt, wird er als XML ausgewertet (`/SHOPS/SHOP`, Wert `SHOPID`, als Element oder Attribut). Es werden nur Shop-IDs berücksichtigt, die in `Shops` existieren.\n2. Rechnungen werden ausgewählt, wenn:\n - der Bruttobetrag `Total` größer als 0 ist (Gutschriften mit negativem Betrag zählen nicht als eigene Rechnung),\n - das Rechnungsdatum `InvDate` im Bereich `CalculationStart` … `CalculationEnd` liegt (beide Grenzen inklusive und optional),\n - bei gesetztem `CustomerOf` der Shop des Kunden (`CustomerOf`) zu den übergebenen Shops gehört.\n3. Je Rechnung werden der Nettobetrag (`Total_Net`) und der Nettobetrag ohne Versandkosten (`Total_Net - Total_ShipCost_Net`) herangezogen. Die Nettobeträge aller Rechnungen, die über `RefToInvoiceKey` auf diese Rechnung verweisen (in der Regel Gutschriften), werden zu diesen Werten addiert.\n4. **Währungsbehandlung** abhängig von der Einstellung `MultiCurrencyEnabled`:\n - nicht `1`: Beträge bleiben in der Originalwährung der Rechnung, `BaseCurrency` ist `NULL`;\n - `1`: jeder Betrag wird durch den Wechselkurs der Rechnung (`pixi.ExchRate`) geteilt, `BaseCurrency` enthält den Code der Basiswährung dieses Kurses.\n5. Die Ergebnisse werden nach `CustKey` und `BaseCurrency` gruppiert.\n\n**Paging**\n\nDas Paging arbeitet mit Schlüsseln: Es werden nur Kunden mit `CustKey` größer als `Offset` geliefert, aufsteigend nach `CustKey` sortiert und auf `Rows` Zeilen begrenzt. Für die nächste Seite wird der zuletzt gelieferte `CustKey` als `Offset` übergeben. `Offset` ist keine Zeilenanzahl.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustomerOf` | varchar(max) | Nein | XML-Liste von pixi*-Shops (`/SHOPS/SHOP/SHOPID`). Es werden nur Kunden dieser Shops ausgewertet. `NULL` oder leer: alle Kunden. |\n| `CalculationStart` | datetime | Nein | Frühestes Rechnungsdatum (inklusive). `NULL`: keine Untergrenze. |\n| `CalculationEnd` | datetime | Nein | Spätestes Rechnungsdatum (inklusive). `NULL`: keine Obergrenze. |\n| `Rows` | int | Nein | Maximale Anzahl gelieferter Zeilen. |\n| `Offset` | int | Nein | Es werden nur Kunden mit `CustKey` größer als dieser Wert geliefert. Den letzten `CustKey` der vorherigen Seite übergeben. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Ist `CustomerOf` gesetzt, aber keine der Shop-IDs existiert in `Shops`, werden keine Zeilen geliefert. Ungültiges XML führt zu einem Fehler von `sp_xml_preparedocument`.\n- Ohne Mehrwährung (`MultiCurrencyEnabled` ungleich `1`) werden Beträge verschiedener Rechnungswährungen ohne Umrechnung addiert.\n- Mit Mehrwährung werden Rechnungen ohne Wechselkurs (`ExchRateId` nicht in `pixi.ExchRate` vorhanden) ausgeschlossen; referenzierende Gutschriften ohne Wechselkurs fließen nicht in die Summen ein. Umgerechnete Beträge werden mit 9 Nachkommastellen gespeichert.\n- Mit Mehrwährung kann ein Kunde in mehreren Zeilen erscheinen (eine je Basiswährung). Da `Rows` Zeilen und nicht Kunden begrenzt, kann eine Seite mitten in den Zeilen eines Kunden enden; wird dieser `CustKey` als nächster `Offset` verwendet, entfallen die restlichen Zeilen dieses Kunden.\n- Der Datumsfilter gilt nur für die Hauptrechnung; referenzierende Gutschriften werden unabhängig von ihrem Datum einbezogen.\n- Ein Kennzeichen für Komplettretouren wird intern berechnet, aber nicht ausgegeben.\n- Die Datenbankwährung wird über `pixi.GetDatabaseCurrency()` gelesen, die Werte werden im Ergebnis jedoch nicht verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCRMSales"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1001\n 1523.450000000\n 1488.4500\n EUR\n \n \n 1002\n 89.900000000\n 84.9000\n EUR\n \n"
}
]
},
{
"name": "pixiGetCustomerAccountBalance",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10045\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Kundenkontosaldo (Summe aller Kontobuchungen bis zu einem optionalen Stichtag) eines Kunden, ermittelt über den internen Schlüssel oder die externe Kundennummer.\n\nBerechnet den Saldo des Kundenkontos (`CustomerAccount`) für einen oder mehrere Kunden.\n\n**Kundensuche**\n- `CustKey` wird mit der externen Kundennummer (`CustomerNrExternal`) und, sofern der Wert in eine Ganzzahl umgewandelt werden kann, mit dem internen Kundenschlüssel (`CustKey`) verglichen. Ein Kunde wird gefunden, wenn **einer** der beiden Vergleiche zutrifft.\n- Ist `ShopId` angegeben (nicht leer), werden nur Kunden berücksichtigt, deren `CustomerOf` diesem Shop entspricht.\n\n**Stichtag**\n- Ist `DateTo` angegeben, wird der Wert auf das Tagesende (23:59:59.997) erweitert. Summiert werden nur Kontobuchungen mit `EventDate` bis zu diesem Zeitpunkt oder ohne `EventDate`.\n- Ohne `DateTo` werden alle Buchungen summiert.\n\n**Währungsbehandlung**\n- Die Einstellung `MultiCurrencyEnabled` wird zur Laufzeit gelesen.\n- Bei `1` wird jeder Buchungsbetrag durch den Wechselkurs der Buchung (`ExchRateId`) geteilt und das Ergebnis nach der Basiswährung dieses Wechselkurses (`BaseCurrency`) gruppiert.\n- Andernfalls werden die Beträge unverändert summiert und `BaseCurrency` ist die Datenbank-(Haus-)Währung aus der Einstellung `HomeCurrency`.\n\n**Ergebnis**\nEine Zeile je gefundenem Kunden (im Mehrwährungsmodus je Basiswährung) mit dem Saldo `CAbalance` (als `money`) und dem Datum der letzten einbezogenen Kontobuchung `LastEventDate`. Kunden ohne Kontobuchungen werden mit Saldo `0` und `LastEventDate` = NULL geliefert. Wird kein Kunde gefunden, wird keine Zeile geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | varchar(200) | Ja | Kundenkennung: entweder die externe Kundennummer (`CustomerNrExternal`) oder der interne Kundenschlüssel (`CustKey`, sofern numerisch). |\n| `DateTo` | datetime | Nein | Optionaler Stichtag. Nur Kontobuchungen bis zum Ende dieses Tages werden einbezogen. NULL bedeutet alle Buchungen. |\n| `ShopId` | varchar(3) | Nein | Optionaler Shop-Filter auf `CustomerOf` des Kunden. NULL oder leer bedeutet alle Shops. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; der Saldo kann nicht festgeschriebene Daten enthalten.\n- Da `CustKey` sowohl mit der externen Nummer als auch mit dem internen Schlüssel verglichen wird, können mehrere Kunden geliefert werden (z. B. ein Kunde mit internem Schlüssel `123` und ein anderer mit externer Nummer `123`). `ShopId` verwenden oder `CustomerId` im Ergebnis prüfen.\n- Stolperfalle bei `DateTo`: Der Datumsfilter wirkt nach dem Outer Join. Ein Kunde, dessen Kontobuchungen alle **nach** `DateTo` liegen, wird gar nicht geliefert (keine Zeile statt einer Zeile mit Saldo 0).\n- Mehrwährungsmodus: Buchungen ohne Wechselkurs ergeben bei der Division NULL und fließen nicht in die Summe ein; sie bilden zudem eine eigene Gruppe mit `BaseCurrency` = NULL. Buchungen mit unterschiedlichen Basiswährungen ergeben getrennte Zeilen für denselben Kunden.\n- Eine leere `ShopId` wird wie NULL behandelt (kein Shop-Filter).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCustomerAccountBalance"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10045\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Kundenkontosaldo (Summe aller Kontobuchungen bis zu einem optionalen Stichtag) eines Kunden, ermittelt über den internen Schlüssel oder die externe Kundennummer.\n\nBerechnet den Saldo des Kundenkontos (`CustomerAccount`) für einen oder mehrere Kunden.\n\n**Kundensuche**\n- `CustKey` wird mit der externen Kundennummer (`CustomerNrExternal`) und, sofern der Wert in eine Ganzzahl umgewandelt werden kann, mit dem internen Kundenschlüssel (`CustKey`) verglichen. Ein Kunde wird gefunden, wenn **einer** der beiden Vergleiche zutrifft.\n- Ist `ShopId` angegeben (nicht leer), werden nur Kunden berücksichtigt, deren `CustomerOf` diesem Shop entspricht.\n\n**Stichtag**\n- Ist `DateTo` angegeben, wird der Wert auf das Tagesende (23:59:59.997) erweitert. Summiert werden nur Kontobuchungen mit `EventDate` bis zu diesem Zeitpunkt oder ohne `EventDate`.\n- Ohne `DateTo` werden alle Buchungen summiert.\n\n**Währungsbehandlung**\n- Die Einstellung `MultiCurrencyEnabled` wird zur Laufzeit gelesen.\n- Bei `1` wird jeder Buchungsbetrag durch den Wechselkurs der Buchung (`ExchRateId`) geteilt und das Ergebnis nach der Basiswährung dieses Wechselkurses (`BaseCurrency`) gruppiert.\n- Andernfalls werden die Beträge unverändert summiert und `BaseCurrency` ist die Datenbank-(Haus-)Währung aus der Einstellung `HomeCurrency`.\n\n**Ergebnis**\nEine Zeile je gefundenem Kunden (im Mehrwährungsmodus je Basiswährung) mit dem Saldo `CAbalance` (als `money`) und dem Datum der letzten einbezogenen Kontobuchung `LastEventDate`. Kunden ohne Kontobuchungen werden mit Saldo `0` und `LastEventDate` = NULL geliefert. Wird kein Kunde gefunden, wird keine Zeile geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | varchar(200) | Ja | Kundenkennung: entweder die externe Kundennummer (`CustomerNrExternal`) oder der interne Kundenschlüssel (`CustKey`, sofern numerisch). |\n| `DateTo` | datetime | Nein | Optionaler Stichtag. Nur Kontobuchungen bis zum Ende dieses Tages werden einbezogen. NULL bedeutet alle Buchungen. |\n| `ShopId` | varchar(3) | Nein | Optionaler Shop-Filter auf `CustomerOf` des Kunden. NULL oder leer bedeutet alle Shops. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; der Saldo kann nicht festgeschriebene Daten enthalten.\n- Da `CustKey` sowohl mit der externen Nummer als auch mit dem internen Schlüssel verglichen wird, können mehrere Kunden geliefert werden (z. B. ein Kunde mit internem Schlüssel `123` und ein anderer mit externer Nummer `123`). `ShopId` verwenden oder `CustomerId` im Ergebnis prüfen.\n- Stolperfalle bei `DateTo`: Der Datumsfilter wirkt nach dem Outer Join. Ein Kunde, dessen Kontobuchungen alle **nach** `DateTo` liegen, wird gar nicht geliefert (keine Zeile statt einer Zeile mit Saldo 0).\n- Mehrwährungsmodus: Buchungen ohne Wechselkurs ergeben bei der Division NULL und fließen nicht in die Summe ein; sie bilden zudem eine eigene Gruppe mit `BaseCurrency` = NULL. Buchungen mit unterschiedlichen Basiswährungen ergeben getrennte Zeilen für denselben Kunden.\n- Eine leere `ShopId` wird wie NULL behandelt (kein Shop-Filter).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCustomerAccountBalance"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10045\n K-778812\n SH1\n -125.5000\n EUR\n 2024-03-28T14:12:05\n \n"
}
]
},
{
"name": "pixiGetCustomerEvents",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Kundenkontobuchungen (Rechnungen, Zahlungen, Lastschriften, manuelle Buchungen), gefiltert nach Kunde, Ereignistyp und Zeitraum.\n\nLiest Einträge aus dem Kundenkonto (`CustomerAccount`) und ergänzt sie um Anzeige- und Statusinformationen.\n\n**Filter** (alle optional, UND-verknüpft; ein weggelassener oder `NULL`-Parameter filtert nicht):\n- `CustKey`: nur Einträge, deren `CustRef` diesem Kundenschlüssel entspricht.\n- `EventID`: nur Einträge dieses Ereignistyps.\n- `DateFrom` / `DateTo`: nur Einträge mit `EventDate` im Zeitraum (beide Grenzen inklusive).\n\nOhne Parameter werden alle Kundenkontoeinträge geliefert.\n\n**Ergänzungen je Eintrag:**\n- `EventName`: Bezeichnung des Ereignistyps aus `CustomerAccountEvents`, übersetzt über die Übersetzungstabelle (Sprach-ID 2, Rückfall auf den unübersetzten Text). Bei Einträgen mit Bezug auf eine Lastschrift (`DTAUSref` gesetzt) wird der übersetzte Lastschriftstatus in eckigen Klammern angehängt, z. B. `Lastschrift [Exportiert]`.\n- `Number`: lesbare Referenz je nach verknüpftem Objekt, in dieser Reihenfolge geprüft: Rechnungsnummer (`InvoiceRef`), Bankzeilentext `BankText01` (`BanklineRef`), Kontonummer der Lastschrift (`DTAUSref`), Referenz der manuellen Buchung (`ManualBookingRef`), sonst eine leere Zeichenkette.\n- `OpenTOMatch`: `Amount` abzüglich des bereits ausgeglichenen Betrags (NULL zählt als 0).\n- `AllowToDelete`: 1, wenn der Eintrag gelöscht werden darf, sonst 0. Löschbar ist ein Eintrag nur, wenn er mit keinem anderen Eintrag ausgeglichen ist und entweder Ereignistyp und Lastschriftstatus das Löschen erlauben oder er zu einer Rechnung gehört, die nicht bezahlt ist, nicht per Kreditkarte bezahlt wurde (`CCPPaymentDone` ungleich `Y`), keine Mahnzeilen hat und deren Positionen alle im Status `EIN` oder alle im Status `RET` sind (oder keine Positionen hat).\n- `CCPTranLogKey`: ein Kreditkarten-Transaktionsprotokolleintrag desselben Kunden, dessen Rechnungsnummer der Rechnungsnummer oder der Bezugsrechnungsnummer der verknüpften Rechnung entspricht.\n- `OrderCurrency`: Währungscode (`CodeA`) des Eintrags.\n- `IsDeleted`: immer 0.\n\nDas Ergebnis hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Nein | Kundenschlüssel (`CustRef`). Nur Einträge dieses Kunden werden geliefert. NULL = alle Kunden. |\n| `EventID` | varchar(3) | Nein | Ereignistyp-ID aus `CustomerAccountEvents`. NULL = alle Ereignistypen. |\n| `DateFrom` | datetime | Nein | Untergrenze für `EventDate` (inklusive). NULL = keine Untergrenze. |\n| `DateTo` | datetime | Nein | Obergrenze für `EventDate` (inklusive). NULL = keine Obergrenze. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten erscheinen.\n- Die Einstellung `CaEnabled` ändert die Prüfung auf \"bezahlt\" für `AllowToDelete`: Ist sie `0` oder nicht vorhanden, wird `Invoices.Payed` verwendet, sonst das jüngste Anlagedatum in `CustomerAccountMatch` für den Eintrag.\n- Die Löschregel ist eine Inline-Kopie von `fPixi_CA_canIdeleteEvent`, jedoch ohne die zusätzliche Prüfung des Scan-Out-Datums der Rechnung (`ScanOutDate`). Ergebnisse können daher von der Funktion abweichen.\n- Einträge, deren `CurrencyId` keinen Datensatz in `pixi.Currency` hat, werden nicht geliefert (Inner Join).\n- Hat der Ereignistyp keinen Datensatz in `CustomerAccountEvents`, sind `EventName` und `AllowToDelete` NULL.\n- `DateTo` wird mit `<=` verglichen; ein reines Datum wie `2024-03-31` bedeutet Mitternacht, spätere Einträge dieses Tages fehlen.\n- Verweisen mehrere gelieferte Einträge auf dieselbe Lastschrift (`DTAUSref`), kann das Anlegen eines eindeutigen Index auf einer internen temporären Tabelle mit einem SQL-Fehler scheitern; ein Filter auf den Kunden vermeidet dies in der Regel.\n- Die View `PV_CustomerAccountMatchGroup` basiert auf `PV_CustomerAccountBond`, deren Definition nicht vorliegt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCustomerEvents"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Kundenkontobuchungen (Rechnungen, Zahlungen, Lastschriften, manuelle Buchungen), gefiltert nach Kunde, Ereignistyp und Zeitraum.\n\nLiest Einträge aus dem Kundenkonto (`CustomerAccount`) und ergänzt sie um Anzeige- und Statusinformationen.\n\n**Filter** (alle optional, UND-verknüpft; ein weggelassener oder `NULL`-Parameter filtert nicht):\n- `CustKey`: nur Einträge, deren `CustRef` diesem Kundenschlüssel entspricht.\n- `EventID`: nur Einträge dieses Ereignistyps.\n- `DateFrom` / `DateTo`: nur Einträge mit `EventDate` im Zeitraum (beide Grenzen inklusive).\n\nOhne Parameter werden alle Kundenkontoeinträge geliefert.\n\n**Ergänzungen je Eintrag:**\n- `EventName`: Bezeichnung des Ereignistyps aus `CustomerAccountEvents`, übersetzt über die Übersetzungstabelle (Sprach-ID 2, Rückfall auf den unübersetzten Text). Bei Einträgen mit Bezug auf eine Lastschrift (`DTAUSref` gesetzt) wird der übersetzte Lastschriftstatus in eckigen Klammern angehängt, z. B. `Lastschrift [Exportiert]`.\n- `Number`: lesbare Referenz je nach verknüpftem Objekt, in dieser Reihenfolge geprüft: Rechnungsnummer (`InvoiceRef`), Bankzeilentext `BankText01` (`BanklineRef`), Kontonummer der Lastschrift (`DTAUSref`), Referenz der manuellen Buchung (`ManualBookingRef`), sonst eine leere Zeichenkette.\n- `OpenTOMatch`: `Amount` abzüglich des bereits ausgeglichenen Betrags (NULL zählt als 0).\n- `AllowToDelete`: 1, wenn der Eintrag gelöscht werden darf, sonst 0. Löschbar ist ein Eintrag nur, wenn er mit keinem anderen Eintrag ausgeglichen ist und entweder Ereignistyp und Lastschriftstatus das Löschen erlauben oder er zu einer Rechnung gehört, die nicht bezahlt ist, nicht per Kreditkarte bezahlt wurde (`CCPPaymentDone` ungleich `Y`), keine Mahnzeilen hat und deren Positionen alle im Status `EIN` oder alle im Status `RET` sind (oder keine Positionen hat).\n- `CCPTranLogKey`: ein Kreditkarten-Transaktionsprotokolleintrag desselben Kunden, dessen Rechnungsnummer der Rechnungsnummer oder der Bezugsrechnungsnummer der verknüpften Rechnung entspricht.\n- `OrderCurrency`: Währungscode (`CodeA`) des Eintrags.\n- `IsDeleted`: immer 0.\n\nDas Ergebnis hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Nein | Kundenschlüssel (`CustRef`). Nur Einträge dieses Kunden werden geliefert. NULL = alle Kunden. |\n| `EventID` | varchar(3) | Nein | Ereignistyp-ID aus `CustomerAccountEvents`. NULL = alle Ereignistypen. |\n| `DateFrom` | datetime | Nein | Untergrenze für `EventDate` (inklusive). NULL = keine Untergrenze. |\n| `DateTo` | datetime | Nein | Obergrenze für `EventDate` (inklusive). NULL = keine Obergrenze. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten erscheinen.\n- Die Einstellung `CaEnabled` ändert die Prüfung auf \"bezahlt\" für `AllowToDelete`: Ist sie `0` oder nicht vorhanden, wird `Invoices.Payed` verwendet, sonst das jüngste Anlagedatum in `CustomerAccountMatch` für den Eintrag.\n- Die Löschregel ist eine Inline-Kopie von `fPixi_CA_canIdeleteEvent`, jedoch ohne die zusätzliche Prüfung des Scan-Out-Datums der Rechnung (`ScanOutDate`). Ergebnisse können daher von der Funktion abweichen.\n- Einträge, deren `CurrencyId` keinen Datensatz in `pixi.Currency` hat, werden nicht geliefert (Inner Join).\n- Hat der Ereignistyp keinen Datensatz in `CustomerAccountEvents`, sind `EventName` und `AllowToDelete` NULL.\n- `DateTo` wird mit `<=` verglichen; ein reines Datum wie `2024-03-31` bedeutet Mitternacht, spätere Einträge dieses Tages fehlen.\n- Verweisen mehrere gelieferte Einträge auf dieselbe Lastschrift (`DTAUSref`), kann das Anlegen eines eindeutigen Index auf einer internen temporären Tabelle mit einem SQL-Fehler scheitern; ein Filter auf den Kunden vermeidet dies in der Regel.\n- Die View `PV_CustomerAccountMatchGroup` basiert auf `PV_CustomerAccountBond`, deren Definition nicht vorliegt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCustomerEvents"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 88231\n 10452\n 2024-02-14T10:22:00\n INV\n Rechnung\n RE2024-004711\n Auftrag 500123\n -59.90\n -59.90\n false\n 45871\n 0\n false\n EUR\n \n \n 88240\n 10452\n 2024-02-16T08:05:00\n BNK\n Zahlungseingang\n RE2024-004711 Mustermann\n \n 59.90\n 0.00\n false\n 3321\n 0\n false\n EUR\n \n"
}
]
},
{
"name": "pixiGetCustomerInfo",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Basisinformationen zu einem Kunden: Name, Kommentar, DATEV-Konto, Sperrkennzeichen, Anzahl Rechnungen je Mahnstufe und externe Kundennummer.\n\nSucht den Kunden mit dem internen Schlüssel `CustKey` und verknüpft ihn mit seiner Hauptadresse (`Customers.AddrRef` → `Addresses.AddrKey`).\n\nGeliefert wird eine Zeile mit:\n- dem Namen aus dem Adressdatensatz,\n- der Kundenhistorien-Notiz (`CHisNote`) als `Comment`,\n- der DATEV-Kontonummer als Text,\n- dem Sperrkennzeichen (`N`, falls nicht gesetzt),\n- der Anzahl der Rechnungen des Kunden in Mahnstufe 1, 2 und 3,\n- der externen Kundennummer.\n\nExistiert kein Kunde mit diesem Schlüssel oder fehlt der zugehörige Adressdatensatz, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Ja | Interner Schlüssel des Kunden (`Customers.CustKey`). |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, die Werte können daher nicht festgeschriebene Daten enthalten.\n- Rechnungen mit Mahnstufen über 3 werden nicht gezählt.\n- Die DATEV-Kontonummer wird in `varchar(10)` umgewandelt.\n- Laut einem Kommentar im Code soll die Spaltenliste später erweitert werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCustomerInfo"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Basisinformationen zu einem Kunden: Name, Kommentar, DATEV-Konto, Sperrkennzeichen, Anzahl Rechnungen je Mahnstufe und externe Kundennummer.\n\nSucht den Kunden mit dem internen Schlüssel `CustKey` und verknüpft ihn mit seiner Hauptadresse (`Customers.AddrRef` → `Addresses.AddrKey`).\n\nGeliefert wird eine Zeile mit:\n- dem Namen aus dem Adressdatensatz,\n- der Kundenhistorien-Notiz (`CHisNote`) als `Comment`,\n- der DATEV-Kontonummer als Text,\n- dem Sperrkennzeichen (`N`, falls nicht gesetzt),\n- der Anzahl der Rechnungen des Kunden in Mahnstufe 1, 2 und 3,\n- der externen Kundennummer.\n\nExistiert kein Kunde mit diesem Schlüssel oder fehlt der zugehörige Adressdatensatz, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Ja | Interner Schlüssel des Kunden (`Customers.CustKey`). |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, die Werte können daher nicht festgeschriebene Daten enthalten.\n- Rechnungen mit Mahnstufen über 3 werden nicht gezählt.\n- Die DATEV-Kontonummer wird in `varchar(10)` umgewandelt.\n- Laut einem Kommentar im Code soll die Spaltenliste später erweitert werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCustomerInfo"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Mustermann GmbH\n Pays by invoice only\n 10234\n N\n 2\n 1\n 0\n SHOP-4711\n \n"
}
]
},
{
"name": "pixiGetCustomerList",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert bis zu 10.000 Kunden mit Aufträgen ab einem Kundenschlüssel, mit Auftrags-, Umsatz-, Retouren- und Mahnstatistik sowie Daten der Hauptadresse.\n\nErstellt eine Kundenliste mit Kennzahlen, ausgehend von den Aufträgen in `OrderHeader`.\n\n1. `StartCustKey` (NULL wird als `0` behandelt) legt den ersten Kunden fest. Es werden die ersten **10.000** unterschiedlichen `CustRef`-Werte aus `OrderHeader` mit `CustRef >= StartCustKey` in aufsteigender Reihenfolge ermittelt und ihre Aufträge gezählt (`OrderCount`). Kunden ohne Auftrag werden nie geliefert.\n2. Für jeden dieser Kunden wird berechnet:\n - `DaysSinceLastOrder` / `DaysSinceFirstOrder`: Tage zwischen heute und dem spätesten `OrderDate` in `Orderlines` des Auftrags mit der höchsten bzw. niedrigsten Auftragsnummer des Kunden.\n - Aus `Invoices`: `Turnover_all` (Summe der Rechnungen mit positivem Betrag), `Turnover_avgPerOrder` (Durchschnitt der positiven Rechnungsbeträge), `ReturnCount` (Anzahl der Rechnungen mit negativem Betrag), `ReturnValue` (Summe der negativen Beträge) und `ReminderLevel` (höchste Mahnstufe).\n - Aus `Invlines`: `ItemCount_all`, die Summe aller positiven `ItemQty`-Werte.\n3. Die Währungsbehandlung hängt von der Einstellung `MultiCurrencyEnabled` ab:\n - nicht `1`: Beträge werden in der Originalwährung der Rechnung summiert, `BaseCurrency` ist NULL.\n - `1`: jeder Rechnungsbetrag wird durch den Wechselkurs der Rechnung (`pixi.ExchRate`) geteilt, `BaseCurrency` enthält den ISO-Code der Basiswährung.\n4. Das Ergebnis wird mit `Customers` und der Hauptadresse des Kunden (`Customers.AddrRef` → `Addresses`) verknüpft und aufsteigend nach `CustKey` sortiert.\n\n**Paging:** Für den nächsten Block erneut mit `StartCustKey` = zuletzt gelieferter `CustKey` + 1 aufrufen (der Filter ist inklusiv).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartCustKey` | int | Nein | Kleinster einzuschließender Kundenschlüssel (`CustKey`, inklusiv). NULL oder weggelassen beginnt bei 0. Für Paging den zuletzt gelieferten `CustKey` + 1 übergeben. |\n\n- Alle permanenten Tabellen werden mit `NOLOCK` gelesen; die Werte können nicht festgeschriebene Daten enthalten.\n- Ohne Mehrwährung können `Turnover_all`, `Turnover_avgPerOrder` und `ReturnValue` verschiedene Währungen vermischen, wenn ein Kunde Rechnungen in mehreren Währungen hat.\n- Mit aktivierter Mehrwährung werden Rechnungen ohne passenden Wechselkurs-Datensatz ignoriert. Verweisen die Rechnungen eines Kunden auf mehr als eine Basiswährung, schlägt der eindeutige Index auf der temporären Rechnungstabelle fehl und der Aufruf endet mit einem SQL-Fehler.\n- `Turnover_avgPerOrder` ist der Durchschnitt je positiver Rechnung, nicht je Auftrag.\n- Die Tage seit erstem/letztem Auftrag beruhen auf der niedrigsten/höchsten Auftragsnummer, nicht auf dem frühesten/spätesten Auftragsdatum; sie sind NULL, wenn dieser Auftrag keine Positionen hat.\n- Der Block von 10.000 wird aus `OrderHeader` vor der Verknüpfung mit `Customers`/`Addresses` gebildet; dort fehlende Kunden entfallen, sodass ein Block weniger als 10.000 Zeilen enthalten kann, obwohl weitere Kunden folgen. Paging fortsetzen, bis ein leeres Ergebnis zurückkommt.\n- Die Adresse ist die Hauptadresse (`AddrRef`), nicht die Lieferadresse.\n- Die Aggregation über alle Aufträge und Rechnungen kann bei großen Datenbanken aufwendig sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCustomerList"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert bis zu 10.000 Kunden mit Aufträgen ab einem Kundenschlüssel, mit Auftrags-, Umsatz-, Retouren- und Mahnstatistik sowie Daten der Hauptadresse.\n\nErstellt eine Kundenliste mit Kennzahlen, ausgehend von den Aufträgen in `OrderHeader`.\n\n1. `StartCustKey` (NULL wird als `0` behandelt) legt den ersten Kunden fest. Es werden die ersten **10.000** unterschiedlichen `CustRef`-Werte aus `OrderHeader` mit `CustRef >= StartCustKey` in aufsteigender Reihenfolge ermittelt und ihre Aufträge gezählt (`OrderCount`). Kunden ohne Auftrag werden nie geliefert.\n2. Für jeden dieser Kunden wird berechnet:\n - `DaysSinceLastOrder` / `DaysSinceFirstOrder`: Tage zwischen heute und dem spätesten `OrderDate` in `Orderlines` des Auftrags mit der höchsten bzw. niedrigsten Auftragsnummer des Kunden.\n - Aus `Invoices`: `Turnover_all` (Summe der Rechnungen mit positivem Betrag), `Turnover_avgPerOrder` (Durchschnitt der positiven Rechnungsbeträge), `ReturnCount` (Anzahl der Rechnungen mit negativem Betrag), `ReturnValue` (Summe der negativen Beträge) und `ReminderLevel` (höchste Mahnstufe).\n - Aus `Invlines`: `ItemCount_all`, die Summe aller positiven `ItemQty`-Werte.\n3. Die Währungsbehandlung hängt von der Einstellung `MultiCurrencyEnabled` ab:\n - nicht `1`: Beträge werden in der Originalwährung der Rechnung summiert, `BaseCurrency` ist NULL.\n - `1`: jeder Rechnungsbetrag wird durch den Wechselkurs der Rechnung (`pixi.ExchRate`) geteilt, `BaseCurrency` enthält den ISO-Code der Basiswährung.\n4. Das Ergebnis wird mit `Customers` und der Hauptadresse des Kunden (`Customers.AddrRef` → `Addresses`) verknüpft und aufsteigend nach `CustKey` sortiert.\n\n**Paging:** Für den nächsten Block erneut mit `StartCustKey` = zuletzt gelieferter `CustKey` + 1 aufrufen (der Filter ist inklusiv).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartCustKey` | int | Nein | Kleinster einzuschließender Kundenschlüssel (`CustKey`, inklusiv). NULL oder weggelassen beginnt bei 0. Für Paging den zuletzt gelieferten `CustKey` + 1 übergeben. |\n\n- Alle permanenten Tabellen werden mit `NOLOCK` gelesen; die Werte können nicht festgeschriebene Daten enthalten.\n- Ohne Mehrwährung können `Turnover_all`, `Turnover_avgPerOrder` und `ReturnValue` verschiedene Währungen vermischen, wenn ein Kunde Rechnungen in mehreren Währungen hat.\n- Mit aktivierter Mehrwährung werden Rechnungen ohne passenden Wechselkurs-Datensatz ignoriert. Verweisen die Rechnungen eines Kunden auf mehr als eine Basiswährung, schlägt der eindeutige Index auf der temporären Rechnungstabelle fehl und der Aufruf endet mit einem SQL-Fehler.\n- `Turnover_avgPerOrder` ist der Durchschnitt je positiver Rechnung, nicht je Auftrag.\n- Die Tage seit erstem/letztem Auftrag beruhen auf der niedrigsten/höchsten Auftragsnummer, nicht auf dem frühesten/spätesten Auftragsdatum; sie sind NULL, wenn dieser Auftrag keine Positionen hat.\n- Der Block von 10.000 wird aus `OrderHeader` vor der Verknüpfung mit `Customers`/`Addresses` gebildet; dort fehlende Kunden entfallen, sodass ein Block weniger als 10.000 Zeilen enthalten kann, obwohl weitere Kunden folgen. Paging fortsetzen, bis ein leeres Ergebnis zurückkommt.\n- Die Adresse ist die Hauptadresse (`AddrRef`), nicht die Lieferadresse.\n- Die Aggregation über alle Aufträge und Rechnungen kann bei großen Datenbanken aufwendig sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCustomerList"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10001\n SHOP-4711\n 5\n 489.7000\n 12\n 97.9400\n 1\n -39.9000\n 0\n 14\n 412\n WEB\n max.mustermann@example.com\n Herr\n Max\n Mustermann\n Max Mustermann\n \n Hauptstraße 1\n 80331\n DE\n 0\n EUR\n \n"
}
]
},
{
"name": "pixiGetCustomerOrderAccount",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10234\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Stammdaten, Adressen, Aufträge, Auftragspositionen, Bundle-Positionen, Rechnungen, Rechnungspositionen sowie Kundenkonto-Übersicht und -Buchungen eines Kunden.\n\nStellt alle Daten für die Kundenkonto-Ansicht eines Kunden (`CustKey`) zusammen und gibt sie in neun Ergebnismengen zurück.\n\n**Auswahl der Aufträge**\n\nDie Aufträge stammen aus `Orderlines` mit `CustRef = @CustKey`. Die Prozedur wendet einen optionalen Filter auf `Orderlines.OrderDate` an:\n\n- `OrderDateFrom` und `OrderDateTo` gesetzt: `OrderDate >= OrderDateFrom` und `OrderDate < OrderDateTo`. Die Obergrenze ist exklusiv.\n- Nur `OrderDateFrom` gesetzt: `OrderDate >= OrderDateFrom`.\n- Sonst: kein Datumsfilter. Das gilt auch, wenn nur `OrderDateTo` gesetzt ist (siehe Hinweise).\n\nEin Auftrag wird aufgenommen, wenn mindestens eine seiner Positionen passt. Danach werden alle Positionen eines ausgewählten Auftrags geliefert.\n\nDie Rechnungen sind alle eindeutigen `InvRef`-Werte der Positionen der ausgewählten Aufträge.\n\n**Ergebnismengen**\n\n1. Kundenstammdaten aus `Customers`.\n2. Alle Adressen des Kunden (`AdrCustRef = @CustKey`), inklusive Bank- und Kreditkartendaten sowie ISO-Ländercodes aus `Countries`.\n3. Auftragsköpfe der ausgewählten Aufträge mit Währungscode.\n4. Auftragspositionen der ausgewählten Aufträge, sortiert nach `OrderNr`. Enthält Lieferanten-Artikelnummer, voraussichtliche Lieferung und ein berechnetes `ResQty`.\n5. Bundle-Positionen (`BundleOrderlines`) der ausgewählten Aufträge, sortiert nach `OrderNr`.\n6. Rechnungen zu den ausgewählten Aufträgen.\n7. Rechnungspositionen dieser Rechnungen, sortiert nach `InvoiceRef`.\n8. Finanzielle Übersicht des Kundenkontos. Sie wird von `Pixi_CA_GetCustomerAccountSummary` berechnet und nicht nach Datum gefiltert.\n9. Alle Kundenkonto-Buchungen (`CustomerAccount`) des Kunden, sortiert nach `CustomerAccountKey`. Sie werden nicht nach Datum gefiltert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Ja | Interner Kundenschlüssel (`Customers.CustKey`). |\n| `OrderDateFrom` | datetime | Nein | Untergrenze (inklusiv) für das Datum der Auftragsposition. NULL bedeutet keine Untergrenze. |\n| `OrderDateTo` | datetime | Nein | Obergrenze (exklusiv) für das Datum der Auftragsposition. Wird nur zusammen mit `OrderDateFrom` verwendet; allein übergeben wird es ignoriert. |\n\n- **Fehler im Datumsfilter:** Der dritte Zweig wiederholt die Bedingung des zweiten (`OrderDateFrom IS NOT NULL AND OrderDateTo IS NULL`). Wird nur `OrderDateTo` übergeben, wird es ignoriert und alle Aufträge des Kunden werden geliefert. Für eine reine Obergrenze zusätzlich ein sehr frühes `OrderDateFrom` übergeben.\n- **Keine Sperren:** Alle Lesezugriffe verwenden `NOLOCK`, nicht festgeschriebene Daten können erscheinen.\n- **Währungs-Joins:** Auftragsköpfe, Auftragspositionen, Bundle-Positionen, Rechnungen, Rechnungspositionen und Kontobuchungen werden per Inner Join mit `pixi.Currency` verknüpft. Datensätze ohne passende Währung fehlen im Ergebnis.\n- **`ResQty` in Ergebnismenge 4:**\n - Der Code rangiert die aktiven Reservierungen desselben Artikels nach `ResDate` und `ResOrderlineRef`, über alle Kunden und Lagerorte. Aktiv heißt: Auftragsstatus in `OrderStates` mit `FinalState = 'N'`, ohne `EIN`, `FUT` und `FUS`.\n - `ResQty` ist der Lagerortbestand (`ItemLocationSpecific.LocationQuantity`) abzüglich der Anzahl früherer Reservierungen.\n - Positionen ohne aktive Reservierung erhalten den vollen Lagerortbestand.\n- **Immer NULL:** `SOrderlineRef` ist immer NULL.\n- **Doppelte Spalten:** Spalten mit Endung `_OrderCurr` wiederholen die Basisspalte. Der Code markiert sie zur Entfernung.\n- **Wiederholte Werte:** `ShipCost` in den Ergebnismengen 4 und 5 ist der Wert aus dem Auftragskopf und wird auf jeder Position wiederholt.\n- **Sensible Daten:** Ergebnismenge 2 liefert Kreditkartennummer, CVC und Bankdaten. Die Antwort ist entsprechend zu schützen.\n- **Ergebnismenge 8:**\n - Sie hängt von `Pixi_CA_GetCustomerAccountSummary` ab, das die Einstellungen `DoNOTChargeShipCostOnSecondDelivery`, `MultiCurrencyEnabled` und `HomeCurrency` liest.\n - Sie kann leer sein, wenn Shop des Kunden oder Einstellung `HomeCurrency` nicht aufgelöst werden können.\n - Bei mehreren Währungen und aktivierter Mehrwährung wird mit dem Wechselkurs des aktuellen Tages umgerechnet.\n- **Unbekannter Kunde:** Bei unbekanntem `CustKey` sind die Ergebnismengen leer. Es wird kein Fehler ausgelöst.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCustomerOrderAccount"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10234\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Stammdaten, Adressen, Aufträge, Auftragspositionen, Bundle-Positionen, Rechnungen, Rechnungspositionen sowie Kundenkonto-Übersicht und -Buchungen eines Kunden.\n\nStellt alle Daten für die Kundenkonto-Ansicht eines Kunden (`CustKey`) zusammen und gibt sie in neun Ergebnismengen zurück.\n\n**Auswahl der Aufträge**\n\nDie Aufträge stammen aus `Orderlines` mit `CustRef = @CustKey`. Die Prozedur wendet einen optionalen Filter auf `Orderlines.OrderDate` an:\n\n- `OrderDateFrom` und `OrderDateTo` gesetzt: `OrderDate >= OrderDateFrom` und `OrderDate < OrderDateTo`. Die Obergrenze ist exklusiv.\n- Nur `OrderDateFrom` gesetzt: `OrderDate >= OrderDateFrom`.\n- Sonst: kein Datumsfilter. Das gilt auch, wenn nur `OrderDateTo` gesetzt ist (siehe Hinweise).\n\nEin Auftrag wird aufgenommen, wenn mindestens eine seiner Positionen passt. Danach werden alle Positionen eines ausgewählten Auftrags geliefert.\n\nDie Rechnungen sind alle eindeutigen `InvRef`-Werte der Positionen der ausgewählten Aufträge.\n\n**Ergebnismengen**\n\n1. Kundenstammdaten aus `Customers`.\n2. Alle Adressen des Kunden (`AdrCustRef = @CustKey`), inklusive Bank- und Kreditkartendaten sowie ISO-Ländercodes aus `Countries`.\n3. Auftragsköpfe der ausgewählten Aufträge mit Währungscode.\n4. Auftragspositionen der ausgewählten Aufträge, sortiert nach `OrderNr`. Enthält Lieferanten-Artikelnummer, voraussichtliche Lieferung und ein berechnetes `ResQty`.\n5. Bundle-Positionen (`BundleOrderlines`) der ausgewählten Aufträge, sortiert nach `OrderNr`.\n6. Rechnungen zu den ausgewählten Aufträgen.\n7. Rechnungspositionen dieser Rechnungen, sortiert nach `InvoiceRef`.\n8. Finanzielle Übersicht des Kundenkontos. Sie wird von `Pixi_CA_GetCustomerAccountSummary` berechnet und nicht nach Datum gefiltert.\n9. Alle Kundenkonto-Buchungen (`CustomerAccount`) des Kunden, sortiert nach `CustomerAccountKey`. Sie werden nicht nach Datum gefiltert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Ja | Interner Kundenschlüssel (`Customers.CustKey`). |\n| `OrderDateFrom` | datetime | Nein | Untergrenze (inklusiv) für das Datum der Auftragsposition. NULL bedeutet keine Untergrenze. |\n| `OrderDateTo` | datetime | Nein | Obergrenze (exklusiv) für das Datum der Auftragsposition. Wird nur zusammen mit `OrderDateFrom` verwendet; allein übergeben wird es ignoriert. |\n\n- **Fehler im Datumsfilter:** Der dritte Zweig wiederholt die Bedingung des zweiten (`OrderDateFrom IS NOT NULL AND OrderDateTo IS NULL`). Wird nur `OrderDateTo` übergeben, wird es ignoriert und alle Aufträge des Kunden werden geliefert. Für eine reine Obergrenze zusätzlich ein sehr frühes `OrderDateFrom` übergeben.\n- **Keine Sperren:** Alle Lesezugriffe verwenden `NOLOCK`, nicht festgeschriebene Daten können erscheinen.\n- **Währungs-Joins:** Auftragsköpfe, Auftragspositionen, Bundle-Positionen, Rechnungen, Rechnungspositionen und Kontobuchungen werden per Inner Join mit `pixi.Currency` verknüpft. Datensätze ohne passende Währung fehlen im Ergebnis.\n- **`ResQty` in Ergebnismenge 4:**\n - Der Code rangiert die aktiven Reservierungen desselben Artikels nach `ResDate` und `ResOrderlineRef`, über alle Kunden und Lagerorte. Aktiv heißt: Auftragsstatus in `OrderStates` mit `FinalState = 'N'`, ohne `EIN`, `FUT` und `FUS`.\n - `ResQty` ist der Lagerortbestand (`ItemLocationSpecific.LocationQuantity`) abzüglich der Anzahl früherer Reservierungen.\n - Positionen ohne aktive Reservierung erhalten den vollen Lagerortbestand.\n- **Immer NULL:** `SOrderlineRef` ist immer NULL.\n- **Doppelte Spalten:** Spalten mit Endung `_OrderCurr` wiederholen die Basisspalte. Der Code markiert sie zur Entfernung.\n- **Wiederholte Werte:** `ShipCost` in den Ergebnismengen 4 und 5 ist der Wert aus dem Auftragskopf und wird auf jeder Position wiederholt.\n- **Sensible Daten:** Ergebnismenge 2 liefert Kreditkartennummer, CVC und Bankdaten. Die Antwort ist entsprechend zu schützen.\n- **Ergebnismenge 8:**\n - Sie hängt von `Pixi_CA_GetCustomerAccountSummary` ab, das die Einstellungen `DoNOTChargeShipCostOnSecondDelivery`, `MultiCurrencyEnabled` und `HomeCurrency` liest.\n - Sie kann leer sein, wenn Shop des Kunden oder Einstellung `HomeCurrency` nicht aufgelöst werden können.\n - Bei mehreren Währungen und aktivierter Mehrwährung wird mit dem Wechselkurs des aktuellen Tages umgerechnet.\n- **Unbekannter Kunde:** Bei unbekanntem `CustKey` sind die Ergebnismengen leer. Es wird kein Fehler ausgelöst.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCustomerOrderAccount"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n K-100234\n SHOP1\n max.mustermann@example.com\n N\n 55871\n \n"
}
]
},
{
"name": "pixiGetCustomersToRefund",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kunden mit positivem Rückerstattungsvorschlag aus dem Kundenkonto inklusive Saldo, offenen Aufträgen und Abgleichstatus, optional gefiltert nach Shop und Betrag.\n\nErmittelt, welche Kunden eine Rückerstattung aus ihrem Kundenkonto (`CustomerAccount`) erhalten sollten.\n\n1. Ein leerer `ShopId` wird als `NULL` behandelt. `NULL` für `AmountFrom` / `AmountTo` wird durch `0` / `1000000` ersetzt.\n2. Als Kandidaten werden alle Kunden gewählt, deren Kundenkontobuchungen in Summe positiv sind.\n3. Für diese Kandidaten berechnet die interne Prozedur `Pixi_CA_GetSummaryList` je Kunde:\n - `FinancialBalance`: Summe aller Kundenkontobeträge.\n - `OpenOrders`: Wert der Auftragspositionen in offenem Status (`OrderStates.CA_IsOpenOrder = 1`), die noch nicht in einer Rechnung stehen, abzüglich nicht eingelöster Gutscheine und zuzüglich Versandkosten. Berücksichtigt werden nur Aufträge, deren Zahlungsart `CA_SubstractFromopenOrdersWhenRefund = 0` hat; negative Werte je Währung werden auf 0 gesetzt.\n - `SuggestedRefund`: erstattungsfähiger Kontobetrag (Buchungen ohne `DoNotRefund` sowie der abgeglichene Teil von Buchungen mit `DoNotRefund`) abzüglich `OpenOrders`.\n - `OpenToMatch`: noch nicht abgeglichener Betrag.\n - `IsMatched`: Abgleichkennzeichen, abgeleitet aus den offenen Abgleichsummen je Währung.\n - `CurrencyId`: Währung der Werte.\n4. Zurückgegeben werden nur Kunden mit `SuggestedRefund > 0` und `SuggestedRefund` zwischen `AmountFrom` und `AmountTo` (inklusive). Ist `ShopId` angegeben, nur Kunden dieses Shops (`Customers.CustomerOf`); ist `IsAccountMatched` angegeben, nur Kunden mit passendem `IsMatched`-Wert.\n\nEine Sortierung ist nicht definiert; Paging gibt es nicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShopId` | varchar(3) | Nein | Shop der Kunden (`Customers.CustomerOf`). `NULL` oder leer liefert Kunden aller Shops. |\n| `AmountFrom` | money | Nein | Mindestbetrag des Rückerstattungsvorschlags (inklusive). `NULL` wird als 0 behandelt. |\n| `AmountTo` | money | Nein | Höchstbetrag des Rückerstattungsvorschlags (inklusive). `NULL` wird als 1000000 behandelt. |\n| `IsAccountMatched` | bit | Nein | Filter auf das Abgleichkennzeichen `IsMatched`. `NULL` liefert beide. |\n\n- Nur lesend; alle Tabellen werden mit `NOLOCK` gelesen, Werte können daher nicht festgeschriebene Daten enthalten.\n- Das Verhalten hängt von den Einstellungen `DoNOTChargeShipCostOnSecondDelivery` (ob Versandkosten bei bereits teilweise berechneten Aufträgen zu den offenen Aufträgen addiert werden), `MultiCurrencyEnabled` und `HomeCurrency` ab.\n- Bei `MultiCurrencyEnabled = 1` und Buchungen bzw. offenen Aufträgen eines Kunden in mehreren Währungen werden die Beträge mit dem Wechselkurs des aktuellen Tages (`pixi.ExchRate`) in die Basiswährung des Shops umgerechnet. Fehlt ein Kurs für heute, fallen die Beträge dieser Währung aus den Summen heraus. Ohne Mehrwährung ist `CurrencyId` die Hauswährung.\n- Die Berechnung läuft über alle Kunden mit positivem Kontosaldo, bevor die Filter greifen; der Aufruf kann daher bei großen Datenbanken auch mit einschränkendem `ShopId` aufwendig sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCustomersToRefund"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kunden mit positivem Rückerstattungsvorschlag aus dem Kundenkonto inklusive Saldo, offenen Aufträgen und Abgleichstatus, optional gefiltert nach Shop und Betrag.\n\nErmittelt, welche Kunden eine Rückerstattung aus ihrem Kundenkonto (`CustomerAccount`) erhalten sollten.\n\n1. Ein leerer `ShopId` wird als `NULL` behandelt. `NULL` für `AmountFrom` / `AmountTo` wird durch `0` / `1000000` ersetzt.\n2. Als Kandidaten werden alle Kunden gewählt, deren Kundenkontobuchungen in Summe positiv sind.\n3. Für diese Kandidaten berechnet die interne Prozedur `Pixi_CA_GetSummaryList` je Kunde:\n - `FinancialBalance`: Summe aller Kundenkontobeträge.\n - `OpenOrders`: Wert der Auftragspositionen in offenem Status (`OrderStates.CA_IsOpenOrder = 1`), die noch nicht in einer Rechnung stehen, abzüglich nicht eingelöster Gutscheine und zuzüglich Versandkosten. Berücksichtigt werden nur Aufträge, deren Zahlungsart `CA_SubstractFromopenOrdersWhenRefund = 0` hat; negative Werte je Währung werden auf 0 gesetzt.\n - `SuggestedRefund`: erstattungsfähiger Kontobetrag (Buchungen ohne `DoNotRefund` sowie der abgeglichene Teil von Buchungen mit `DoNotRefund`) abzüglich `OpenOrders`.\n - `OpenToMatch`: noch nicht abgeglichener Betrag.\n - `IsMatched`: Abgleichkennzeichen, abgeleitet aus den offenen Abgleichsummen je Währung.\n - `CurrencyId`: Währung der Werte.\n4. Zurückgegeben werden nur Kunden mit `SuggestedRefund > 0` und `SuggestedRefund` zwischen `AmountFrom` und `AmountTo` (inklusive). Ist `ShopId` angegeben, nur Kunden dieses Shops (`Customers.CustomerOf`); ist `IsAccountMatched` angegeben, nur Kunden mit passendem `IsMatched`-Wert.\n\nEine Sortierung ist nicht definiert; Paging gibt es nicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShopId` | varchar(3) | Nein | Shop der Kunden (`Customers.CustomerOf`). `NULL` oder leer liefert Kunden aller Shops. |\n| `AmountFrom` | money | Nein | Mindestbetrag des Rückerstattungsvorschlags (inklusive). `NULL` wird als 0 behandelt. |\n| `AmountTo` | money | Nein | Höchstbetrag des Rückerstattungsvorschlags (inklusive). `NULL` wird als 1000000 behandelt. |\n| `IsAccountMatched` | bit | Nein | Filter auf das Abgleichkennzeichen `IsMatched`. `NULL` liefert beide. |\n\n- Nur lesend; alle Tabellen werden mit `NOLOCK` gelesen, Werte können daher nicht festgeschriebene Daten enthalten.\n- Das Verhalten hängt von den Einstellungen `DoNOTChargeShipCostOnSecondDelivery` (ob Versandkosten bei bereits teilweise berechneten Aufträgen zu den offenen Aufträgen addiert werden), `MultiCurrencyEnabled` und `HomeCurrency` ab.\n- Bei `MultiCurrencyEnabled = 1` und Buchungen bzw. offenen Aufträgen eines Kunden in mehreren Währungen werden die Beträge mit dem Wechselkurs des aktuellen Tages (`pixi.ExchRate`) in die Basiswährung des Shops umgerechnet. Fehlt ein Kurs für heute, fallen die Beträge dieser Währung aus den Summen heraus. Ohne Mehrwährung ist `CurrencyId` die Hauswährung.\n- Die Berechnung läuft über alle Kunden mit positivem Kontosaldo, bevor die Filter greifen; der Aufruf kann daher bei großen Datenbanken auch mit einschränkendem `ShopId` aufwendig sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCustomersToRefund"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n SHP\n true\n 49.9000\n 49.9000\n 0.0000\n 49.9000\n 1\n \n \n 10988\n SHP\n false\n 15.0000\n 40.0000\n 25.0000\n 40.0000\n 1\n \n"
}
]
},
{
"name": "pixiGetDatevExportAddresses",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-01-01T00:00:00\n 2024-02-01T00:00:00\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kunden- (und optional Lieferanten-)Adressdaten für die DATEV-Exportdatei, gefiltert nach Zeitraum, Shop, Land, E-Mail, DATEV-Konto und Kostenstelle.\n\nStellt die Adressstammdaten (Debitoren und optional Kreditoren) für einen DATEV-Export bereit.\n\n1. Zuerst wird die Einstellung `BookExportDatevActive` geprüft. Ist sie nicht `1`, wird nur eine Fehlerzeile (`Status` = `ERROR`) zurückgegeben.\n2. Andernfalls werden alle Kunden ermittelt, die im Zeitraum `@DateFrom` (einschließlich) bis `@DateTo` (ausschließlich) mindestens eine Rechnung mit `InvDate` oder mindestens eine Auftragsposition mit `OrderDate` haben. Die Datumswerte werden exakt wie übergeben verwendet, inklusive Uhrzeit.\n3. Für diese Kunden wird die Hauptadresse zusammen mit Shop- und Länderdaten geliefert. Optionale Filter (jeweils ignoriert bei `NULL`):\n - `ShopId`: Shop der Adresse\n - `CostCenter`: Kostenstelle des Shops (Leerstring gilt als `NULL`)\n - `Country`: Pixi-Ländercode der Adresse\n - `Email`: exakte E-Mail-Adresse\n - `DatevUserAccount`: DATEV-Kontonummer des Kunden\n4. Ist die Einstellung `BookExportDatevKreditorenActive` gleich `1`, werden zusätzlich alle Lieferanten mit nicht leerer Kundennummer (`CustNr`) als Kreditoren angehängt. Für Lieferanten gelten nur die Filter `Country`, `Email` und `DatevUserAccount`; Zeitraum, Shop und Kostenstelle werden nicht berücksichtigt.\n5. Aus allen Werten werden doppelte Anführungszeichen entfernt und Semikolons durch Leerzeichen ersetzt, sodass die Werte direkt in eine semikolongetrennte Datei geschrieben werden können.\n\nDas Ergebnis ist nach `CustomerNr` (als Text) sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Ja | Beginn des Zeitraums (einschließlich) für Rechnungs- und Auftragsdatum zur Auswahl der Kunden. |\n| `DateTo` | datetime | Ja | Ende des Zeitraums (ausschließlich) für Rechnungs- und Auftragsdatum. |\n| `ShopId` | varchar(3) | Nein | Optionale Shop-ID; nur Kunden, deren Adresse zu diesem Shop gehört. Gilt nicht für Lieferanten. |\n| `Country` | varchar(3) | Nein | Optionaler Pixi-Ländercode der Adresse (Kundenadresse bzw. Lieferantenland). |\n| `Email` | varchar(60) | Nein | Optionale exakte E-Mail-Adresse der Kundenadresse bzw. des Lieferanten. |\n| `DatevUserAccount` | varchar(10) | Nein | Optionale DATEV-Kontonummer: DATEV-Kontonummer des Kunden bzw. Kundennummer beim Lieferanten (erste 10 Zeichen). |\n| `CostCenter` | varchar(8) | Nein | Optionale Kostenstelle des Shops; ein Leerstring gilt als kein Filter. Gilt nicht für Lieferanten. |\n\n- Nur lesend; alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- `@DateTo` ist exklusiv, und es erfolgt keine Anpassung auf Tagesbeginn/-ende. Für einen vollständigen Tag ist der Folgetag 00:00 als `@DateTo` zu übergeben.\n- Einstellungen, die das Ergebnis beeinflussen (fehlende Einstellung gilt als `0`):\n - `BookExportDatevActive`: muss `1` sein, sonst wird nur die Fehlerzeile geliefert.\n - `BookExportDatevKreditorenActive`: hängt Lieferanten als Kreditoren an.\n - `BookUseISOCntCode`: `ZipOld` erhält den ISO3-Ländercode statt des Pixi-Ländercodes als Präfix (bei Lieferanten wird der ISO3-Code zusätzlich vor den Pixi-Code gesetzt).\n - `RemoveNonASCII`: entfernt Nicht-ASCII-Zeichen aus `City`.\n- Kunden, deren Adressland nicht in der Ländertabelle steht oder deren Adress-Shop nicht existiert, werden nicht geliefert (Inner Joins).\n- Die interne Prozedur kann ein Shop-Kürzel mit mehr als 3 Zeichen auflösen, dieser Call deklariert `ShopId` jedoch als `varchar(3)`, daher ist nur die 3-stellige Shop-ID verwendbar.\n- `Company` enthält das vollständige c/o-Feld der Adresse, `Name2` dasselbe Feld auf 40 Zeichen gekürzt. `ShortCode` ist immer leer, `Empty1` immer ein Leerstring.\n- Lieferantenzeilen ohne passenden Ländereintrag erhalten als Vorgabe `Country` = `D`, `CountryISO3` = `DEU`, `CountryISO2` = `DE` und `CountryKFZ` = `D`; sobald nach `Country` gefiltert wird, fallen solche Zeilen jedoch heraus.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetDatevExportAddresses"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-01-01T00:00:00\n 2024-02-01T00:00:00\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kunden- (und optional Lieferanten-)Adressdaten für die DATEV-Exportdatei, gefiltert nach Zeitraum, Shop, Land, E-Mail, DATEV-Konto und Kostenstelle.\n\nStellt die Adressstammdaten (Debitoren und optional Kreditoren) für einen DATEV-Export bereit.\n\n1. Zuerst wird die Einstellung `BookExportDatevActive` geprüft. Ist sie nicht `1`, wird nur eine Fehlerzeile (`Status` = `ERROR`) zurückgegeben.\n2. Andernfalls werden alle Kunden ermittelt, die im Zeitraum `@DateFrom` (einschließlich) bis `@DateTo` (ausschließlich) mindestens eine Rechnung mit `InvDate` oder mindestens eine Auftragsposition mit `OrderDate` haben. Die Datumswerte werden exakt wie übergeben verwendet, inklusive Uhrzeit.\n3. Für diese Kunden wird die Hauptadresse zusammen mit Shop- und Länderdaten geliefert. Optionale Filter (jeweils ignoriert bei `NULL`):\n - `ShopId`: Shop der Adresse\n - `CostCenter`: Kostenstelle des Shops (Leerstring gilt als `NULL`)\n - `Country`: Pixi-Ländercode der Adresse\n - `Email`: exakte E-Mail-Adresse\n - `DatevUserAccount`: DATEV-Kontonummer des Kunden\n4. Ist die Einstellung `BookExportDatevKreditorenActive` gleich `1`, werden zusätzlich alle Lieferanten mit nicht leerer Kundennummer (`CustNr`) als Kreditoren angehängt. Für Lieferanten gelten nur die Filter `Country`, `Email` und `DatevUserAccount`; Zeitraum, Shop und Kostenstelle werden nicht berücksichtigt.\n5. Aus allen Werten werden doppelte Anführungszeichen entfernt und Semikolons durch Leerzeichen ersetzt, sodass die Werte direkt in eine semikolongetrennte Datei geschrieben werden können.\n\nDas Ergebnis ist nach `CustomerNr` (als Text) sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Ja | Beginn des Zeitraums (einschließlich) für Rechnungs- und Auftragsdatum zur Auswahl der Kunden. |\n| `DateTo` | datetime | Ja | Ende des Zeitraums (ausschließlich) für Rechnungs- und Auftragsdatum. |\n| `ShopId` | varchar(3) | Nein | Optionale Shop-ID; nur Kunden, deren Adresse zu diesem Shop gehört. Gilt nicht für Lieferanten. |\n| `Country` | varchar(3) | Nein | Optionaler Pixi-Ländercode der Adresse (Kundenadresse bzw. Lieferantenland). |\n| `Email` | varchar(60) | Nein | Optionale exakte E-Mail-Adresse der Kundenadresse bzw. des Lieferanten. |\n| `DatevUserAccount` | varchar(10) | Nein | Optionale DATEV-Kontonummer: DATEV-Kontonummer des Kunden bzw. Kundennummer beim Lieferanten (erste 10 Zeichen). |\n| `CostCenter` | varchar(8) | Nein | Optionale Kostenstelle des Shops; ein Leerstring gilt als kein Filter. Gilt nicht für Lieferanten. |\n\n- Nur lesend; alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- `@DateTo` ist exklusiv, und es erfolgt keine Anpassung auf Tagesbeginn/-ende. Für einen vollständigen Tag ist der Folgetag 00:00 als `@DateTo` zu übergeben.\n- Einstellungen, die das Ergebnis beeinflussen (fehlende Einstellung gilt als `0`):\n - `BookExportDatevActive`: muss `1` sein, sonst wird nur die Fehlerzeile geliefert.\n - `BookExportDatevKreditorenActive`: hängt Lieferanten als Kreditoren an.\n - `BookUseISOCntCode`: `ZipOld` erhält den ISO3-Ländercode statt des Pixi-Ländercodes als Präfix (bei Lieferanten wird der ISO3-Code zusätzlich vor den Pixi-Code gesetzt).\n - `RemoveNonASCII`: entfernt Nicht-ASCII-Zeichen aus `City`.\n- Kunden, deren Adressland nicht in der Ländertabelle steht oder deren Adress-Shop nicht existiert, werden nicht geliefert (Inner Joins).\n- Die interne Prozedur kann ein Shop-Kürzel mit mehr als 3 Zeichen auflösen, dieser Call deklariert `ShopId` jedoch als `varchar(3)`, daher ist nur die 3-stellige Shop-ID verwendbar.\n- `Company` enthält das vollständige c/o-Feld der Adresse, `Name2` dasselbe Feld auf 40 Zeichen gekürzt. `ShortCode` ist immer leer, `Empty1` immer ein Leerstring.\n- Lieferantenzeilen ohne passenden Ländereintrag erhalten als Vorgabe `Country` = `D`, `CountryISO3` = `DEU`, `CountryISO2` = `DE` und `CountryKFZ` = `D`; sobald nach `Country` gefiltert wird, fallen solche Zeilen jedoch heraus.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetDatevExportAddresses"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10001\n Max Mustermann\n \n \n Max\n Mustermann\n \n Musterstr. 1\n \n D-12345\n 12345\n D\n DEU\n DE\n D\n Berlin\n 030 123456\n \n max.mustermann@example.com\n 1000\n \n"
}
]
},
{
"name": "pixiMergeCustomers",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10452\n 10987\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Führt einen doppelten Kunden mit einem anderen Kunden zusammen, indem alle zugehörigen Datensätze auf den Zielkunden umgehängt und der Quellkunde gelöscht wird.\n\nHängt alle Daten des Kunden `CustRefFrom` auf den Kunden `CustRefTo` um und löscht anschließend `CustRefFrom`.\n\n**Prüfungen.** Die Prüfungen laufen in dieser Reihenfolge. Die erste fehlgeschlagene Prüfung beendet den Aufruf mit `ReturnCode` = `ERROR`:\n1. `CustRefTo` und `CustRefFrom` müssen verschieden sein.\n2. Das Paar muss in `Addresses_Duplicates` eingetragen sein. Beide Richtungen zählen (`CustRef1`/`CustRef2`).\n3. Beide Kunden müssen in `Customers` existieren.\n4. Keiner der Kunden darf einen Auftrag mit einem `OrderHeaderAttribute` vom Typ `3` haben (archivierte Aufträge).\n5. Die Basiswährungen (`Shops.BaseCurrencyId`) der Shops beider Kunden (`Customers.CustomerOf`) müssen gleich sein.\n\n**Zusammenführung.** In einer Transaktion wird die Kundenreferenz in diesen Tabellen von `CustRefFrom` auf `CustRefTo` geändert:\n- Aufträge und Auftragspositionen: `OrderHeader`, `Orderlines`, `BundleOrderlines`, `OrderHistory`\n- Rechnungen und Mahnungen: `Invoices`, `Invlines`, `InvoicesDeleted`, `InvlinesDeleted`, `Reminders`\n- Schnittstellentabellen: `C_Int_OrderHeader`, `C_Int_Orderlines`, `C_Int_Addresses`\n- Adressen und Historie: `Addresses`, `AddressesHist`, `CustomersHist`\n- Kundenkonto: `CustomerAccount`, `CustomerAccountLog`, `CustomerAccountManualBookings`, `CustomerAccountManualBookingsLog`\n- Zahlungen und Lastschriften: `CCPTranLog`, `DTAUS`, `DTAUSLog`\n- Sonstiges: `Voucher`, `eMaillogs`, `AM_Mail`, `AM_MailHist`, `Boxes`, `pixi.Offer`, `lastsdetail`\n\nIn `Addresses` und `C_Int_Addresses` wird zusätzlich `CustomerNrExternal` auf die externe Kundennummer des Zielkunden gesetzt.\n\nDanach werden die Dubletteneinträge von `CustRefFrom` aus `Addresses_Duplicates` entfernt und der Quellkunde aus `Customers` gelöscht.\n\n**Abschluss.** Dieser Schritt läuft immer, auch nach einer fehlgeschlagenen Prüfung oder einem Fehler. Zeilen mit `CustRefFrom` werden aus `Addresses_Duplicates` und `tmp.Addresses_Simple` gelöscht, und ein Ereignis wird protokolliert. Es wird eine Statuszeile mit `ReturnCode` und `ErrorMessage` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustRefTo` | int | Ja | Kundenschlüssel (`Customers.CustKey`) des Zielkunden, der bestehen bleibt und alle Daten erhält. |\n| `CustRefFrom` | int | Ja | Kundenschlüssel (`Customers.CustKey`) des Quellkunden, dessen Daten umgehängt werden und der anschließend gelöscht wird. |\n\n- **Stolperfalle:** Die abschließende Bereinigung läuft immer. Alle Einträge von `CustRefFrom` in `Addresses_Duplicates` und `tmp.Addresses_Simple` werden auch bei fehlgeschlagener Prüfung gelöscht. Sind beide Parameter gleich, werden damit die Dubletteneinträge dieses Kunden entfernt.\n- Ist eine äußere Transaktion offen, wird ein Savepoint gesetzt und nicht committet. Andernfalls wird eine eigene Transaktion geöffnet und committet. Bei einem Fehler wird zurückgerollt, der Fehler über `log.EventInsert` und `log.InsertError` protokolliert und `Unexpected error: \"…\"` geliefert, wobei der Fehlertext auf 80 Zeichen gekürzt ist.\n- Die abschließende Bereinigung und Protokollierung laufen nach dem Commit der Zusammenführung, bzw. innerhalb der Transaktion des Aufrufers, falls eine offen ist.\n- `XACT_ABORT` ist aktiv.\n- Während der Zusammenführung wird `CONTEXT_INFO` auf verschiedene Werte gesetzt, um Trigger auf `OrderHeader`, `Addresses`, `CCPTranLog`, `Invoices`, `Invlines`, `Orderlines` und `CustomerAccount` zu umgehen. Die Trigger sind nicht beigefügt, daher ist die übersprungene Logik unbekannt.\n- Nach der Zusammenführung versucht der Code, die Kundenkontosummen per Dummy-Update auf `CustomerAccount` neu zu berechnen. Das Update filtert auf `CustRefFrom`, dessen Zeilen bereits umgehängt sind, und betrifft daher vermutlich keine Zeile.\n- Hat einer der beiden Kunden keinen passenden Shop, ist die Währung `NULL` und die Währungsprüfung verhindert die Zusammenführung nicht.\n- Die Prüfungen lesen mit `NOLOCK`. Die umzuhängenden Zeilen werden mit `UPDLOCK` gesammelt.\n- Die Tabellen, in die die Protokollierungsprozeduren `log.EventInsert` und `log.InsertError` schreiben, sind nicht erkennbar, da ihre Definitionen nicht beigefügt sind.\n- Der Aufruf ist nicht umkehrbar: Der Quellkunde wird gelöscht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiMergeCustomers"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10452\n 10987\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Führt einen doppelten Kunden mit einem anderen Kunden zusammen, indem alle zugehörigen Datensätze auf den Zielkunden umgehängt und der Quellkunde gelöscht wird.\n\nHängt alle Daten des Kunden `CustRefFrom` auf den Kunden `CustRefTo` um und löscht anschließend `CustRefFrom`.\n\n**Prüfungen.** Die Prüfungen laufen in dieser Reihenfolge. Die erste fehlgeschlagene Prüfung beendet den Aufruf mit `ReturnCode` = `ERROR`:\n1. `CustRefTo` und `CustRefFrom` müssen verschieden sein.\n2. Das Paar muss in `Addresses_Duplicates` eingetragen sein. Beide Richtungen zählen (`CustRef1`/`CustRef2`).\n3. Beide Kunden müssen in `Customers` existieren.\n4. Keiner der Kunden darf einen Auftrag mit einem `OrderHeaderAttribute` vom Typ `3` haben (archivierte Aufträge).\n5. Die Basiswährungen (`Shops.BaseCurrencyId`) der Shops beider Kunden (`Customers.CustomerOf`) müssen gleich sein.\n\n**Zusammenführung.** In einer Transaktion wird die Kundenreferenz in diesen Tabellen von `CustRefFrom` auf `CustRefTo` geändert:\n- Aufträge und Auftragspositionen: `OrderHeader`, `Orderlines`, `BundleOrderlines`, `OrderHistory`\n- Rechnungen und Mahnungen: `Invoices`, `Invlines`, `InvoicesDeleted`, `InvlinesDeleted`, `Reminders`\n- Schnittstellentabellen: `C_Int_OrderHeader`, `C_Int_Orderlines`, `C_Int_Addresses`\n- Adressen und Historie: `Addresses`, `AddressesHist`, `CustomersHist`\n- Kundenkonto: `CustomerAccount`, `CustomerAccountLog`, `CustomerAccountManualBookings`, `CustomerAccountManualBookingsLog`\n- Zahlungen und Lastschriften: `CCPTranLog`, `DTAUS`, `DTAUSLog`\n- Sonstiges: `Voucher`, `eMaillogs`, `AM_Mail`, `AM_MailHist`, `Boxes`, `pixi.Offer`, `lastsdetail`\n\nIn `Addresses` und `C_Int_Addresses` wird zusätzlich `CustomerNrExternal` auf die externe Kundennummer des Zielkunden gesetzt.\n\nDanach werden die Dubletteneinträge von `CustRefFrom` aus `Addresses_Duplicates` entfernt und der Quellkunde aus `Customers` gelöscht.\n\n**Abschluss.** Dieser Schritt läuft immer, auch nach einer fehlgeschlagenen Prüfung oder einem Fehler. Zeilen mit `CustRefFrom` werden aus `Addresses_Duplicates` und `tmp.Addresses_Simple` gelöscht, und ein Ereignis wird protokolliert. Es wird eine Statuszeile mit `ReturnCode` und `ErrorMessage` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustRefTo` | int | Ja | Kundenschlüssel (`Customers.CustKey`) des Zielkunden, der bestehen bleibt und alle Daten erhält. |\n| `CustRefFrom` | int | Ja | Kundenschlüssel (`Customers.CustKey`) des Quellkunden, dessen Daten umgehängt werden und der anschließend gelöscht wird. |\n\n- **Stolperfalle:** Die abschließende Bereinigung läuft immer. Alle Einträge von `CustRefFrom` in `Addresses_Duplicates` und `tmp.Addresses_Simple` werden auch bei fehlgeschlagener Prüfung gelöscht. Sind beide Parameter gleich, werden damit die Dubletteneinträge dieses Kunden entfernt.\n- Ist eine äußere Transaktion offen, wird ein Savepoint gesetzt und nicht committet. Andernfalls wird eine eigene Transaktion geöffnet und committet. Bei einem Fehler wird zurückgerollt, der Fehler über `log.EventInsert` und `log.InsertError` protokolliert und `Unexpected error: \"…\"` geliefert, wobei der Fehlertext auf 80 Zeichen gekürzt ist.\n- Die abschließende Bereinigung und Protokollierung laufen nach dem Commit der Zusammenführung, bzw. innerhalb der Transaktion des Aufrufers, falls eine offen ist.\n- `XACT_ABORT` ist aktiv.\n- Während der Zusammenführung wird `CONTEXT_INFO` auf verschiedene Werte gesetzt, um Trigger auf `OrderHeader`, `Addresses`, `CCPTranLog`, `Invoices`, `Invlines`, `Orderlines` und `CustomerAccount` zu umgehen. Die Trigger sind nicht beigefügt, daher ist die übersprungene Logik unbekannt.\n- Nach der Zusammenführung versucht der Code, die Kundenkontosummen per Dummy-Update auf `CustomerAccount` neu zu berechnen. Das Update filtert auf `CustRefFrom`, dessen Zeilen bereits umgehängt sind, und betrifft daher vermutlich keine Zeile.\n- Hat einer der beiden Kunden keinen passenden Shop, ist die Währung `NULL` und die Währungsprüfung verhindert die Zusammenführung nicht.\n- Die Prüfungen lesen mit `NOLOCK`. Die umzuhängenden Zeilen werden mit `UPDLOCK` gesammelt.\n- Die Tabellen, in die die Protokollierungsprozeduren `log.EventInsert` und `log.InsertError` schreiben, sind nicht erkennbar, da ihre Definitionen nicht beigefügt sind.\n- Der Aufruf ist nicht umkehrbar: Der Quellkunde wird gelöscht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiMergeCustomers"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n Both customers successfully merged\n \n"
}
]
},
{
"name": "pixiReadAddresses",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Adressdatensätze aus der Tabelle Addresses, entweder eine einzelne Adresse per Schlüssel oder eine nach Anlage- und/oder Änderungsdatum gefilterte Liste mit schlüsselbasiertem Paging.\n\nLiest Adressen (Kunden- und sonstige Adressdatensätze) aus der Tabelle `Addresses`. Alle Zweige liefern dieselben 66 Spalten.\n\n**Vorbereitung**\n- Ist `RowCount` auf einen Wert ungleich 0 gesetzt, wird die Anzahl der gelieferten Zeilen auf diesen Wert begrenzt (`SET ROWCOUNT`).\n- Wird `AddrKey` nicht übergeben, gilt der Wert `0`.\n\n**Filtermodus** – die erste zutreffende Regel gilt:\n1. `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` gesetzt: Liefert Adressen mit `AddrKey` > `AddrKey`, bei denen (`CreateDate` >= Von **oder** `UpdateDate` >= Von) und (`CreateDate` < Bis **oder** `UpdateDate` < Bis) gilt. Jede Grenze ist optional.\n2. `CreateDateFrom` oder `CreateDateTo` gesetzt: Liefert Adressen mit `AddrKey` > `AddrKey` und `CreateDate` im Bereich `[Von, Bis)`.\n3. `UpdateDateFrom` oder `UpdateDateTo` gesetzt: Liefert Adressen mit `AddrKey` > `AddrKey` und `UpdateDate` im Bereich `[Von, Bis)`.\n4. `RowCount` übergeben (beliebiger Wert, auch `0`): Liefert alle Adressen mit `AddrKey` > `AddrKey`.\n5. Sonst: Liefert die einzelne Adresse, deren `AddrKey` dem übergebenen Wert entspricht.\n\nIn den Modi 1–4 wird nach `AddrKey` aufsteigend sortiert, und `AddrKey` wirkt als exklusive Untergrenze. Damit ist Paging möglich: Den zuletzt erhaltenen `AddrKey` beim nächsten Aufruf zusammen mit `RowCount` als `AddrKey` übergeben.\n\nDie unteren Datumsgrenzen sind inklusiv, die oberen exklusiv.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AddrKey` | int | Nein | Adressschlüssel. Ohne Datumsfilter und `RowCount` wird genau diese Adresse gewählt, sonst dient er als exklusive Untergrenze für das Paging. NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Inklusive Untergrenze für `CreateDate`. Wird nur verwendet, wenn kein kombinierter Datumsfilter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Exklusive Obergrenze für `CreateDate`. Wird nur verwendet, wenn kein kombinierter Datumsfilter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Inklusive Untergrenze für `UpdateDate`. Wird nur verwendet, wenn weder kombinierter noch Anlagedatumsfilter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Exklusive Obergrenze für `UpdateDate`. Wird nur verwendet, wenn weder kombinierter noch Anlagedatumsfilter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Inklusive Untergrenze. Trifft zu, wenn `CreateDate` oder `UpdateDate` gleich oder später ist. Hat höchste Priorität. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Exklusive Obergrenze. Trifft zu, wenn `CreateDate` oder `UpdateDate` davor liegt. Hat höchste Priorität. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. 0 oder NULL bedeutet keine Begrenzung. Wird der Parameter (auch mit 0) ohne Datumsfilter übergeben, werden alle Adressen mit Schlüssel größer als `AddrKey` geliefert. |\n\n- Die Tabelle wird `WITH (NOLOCK)` gelesen. Nicht festgeschriebene Änderungen können geliefert werden, und bei gleichzeitigen Änderungen können Zeilen fehlen oder doppelt erscheinen.\n- Die Datumsfiltergruppen werden nicht kombiniert: Es gilt nur die Gruppe mit der höchsten Priorität (kombiniertes Datum > Anlagedatum > Änderungsdatum), die übrigen werden ignoriert.\n- Im kombinierten Modus werden Von- und Bis-Bedingung unabhängig geprüft. Eine Adresse, die vor der Bis-Grenze angelegt und nach der Von-Grenze geändert wurde, wird beispielsweise geliefert, auch wenn keines der Daten im Zeitfenster liegt. Zeilen mit `UpdateDate` NULL können nur über `CreateDate` passen.\n- Wird `AddrKey` zusammen mit einem Datumsfilter oder `RowCount` übergeben, ist er **kein** exakter Treffer, sondern eine exklusive Untergrenze.\n- `RowCount = 0` führt in Modus 4 ohne Zeilenbegrenzung und liefert daher **alle** Adressen oberhalb von `AddrKey`.\n- Ein Aufruf ohne Parameter sucht die Adresse mit `AddrKey = 0` und liefert in der Regel keine Zeile.\n- Das Ergebnis enthält sensible Zahlungsdaten wie Kartennummer, Kartenprüfnummer (`CCCVC`), IBAN und Bankverbindung. Zugriff und Protokollierung sollten entsprechend eingeschränkt werden.\n- Die Spaltentypen von `Addresses` sind im Code nicht ersichtlich. Die Bedeutungen der Spalten in dieser Dokumentation sind aus den Spaltennamen abgeleitet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadAddresses"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Adressdatensätze aus der Tabelle Addresses, entweder eine einzelne Adresse per Schlüssel oder eine nach Anlage- und/oder Änderungsdatum gefilterte Liste mit schlüsselbasiertem Paging.\n\nLiest Adressen (Kunden- und sonstige Adressdatensätze) aus der Tabelle `Addresses`. Alle Zweige liefern dieselben 66 Spalten.\n\n**Vorbereitung**\n- Ist `RowCount` auf einen Wert ungleich 0 gesetzt, wird die Anzahl der gelieferten Zeilen auf diesen Wert begrenzt (`SET ROWCOUNT`).\n- Wird `AddrKey` nicht übergeben, gilt der Wert `0`.\n\n**Filtermodus** – die erste zutreffende Regel gilt:\n1. `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` gesetzt: Liefert Adressen mit `AddrKey` > `AddrKey`, bei denen (`CreateDate` >= Von **oder** `UpdateDate` >= Von) und (`CreateDate` < Bis **oder** `UpdateDate` < Bis) gilt. Jede Grenze ist optional.\n2. `CreateDateFrom` oder `CreateDateTo` gesetzt: Liefert Adressen mit `AddrKey` > `AddrKey` und `CreateDate` im Bereich `[Von, Bis)`.\n3. `UpdateDateFrom` oder `UpdateDateTo` gesetzt: Liefert Adressen mit `AddrKey` > `AddrKey` und `UpdateDate` im Bereich `[Von, Bis)`.\n4. `RowCount` übergeben (beliebiger Wert, auch `0`): Liefert alle Adressen mit `AddrKey` > `AddrKey`.\n5. Sonst: Liefert die einzelne Adresse, deren `AddrKey` dem übergebenen Wert entspricht.\n\nIn den Modi 1–4 wird nach `AddrKey` aufsteigend sortiert, und `AddrKey` wirkt als exklusive Untergrenze. Damit ist Paging möglich: Den zuletzt erhaltenen `AddrKey` beim nächsten Aufruf zusammen mit `RowCount` als `AddrKey` übergeben.\n\nDie unteren Datumsgrenzen sind inklusiv, die oberen exklusiv.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AddrKey` | int | Nein | Adressschlüssel. Ohne Datumsfilter und `RowCount` wird genau diese Adresse gewählt, sonst dient er als exklusive Untergrenze für das Paging. NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Inklusive Untergrenze für `CreateDate`. Wird nur verwendet, wenn kein kombinierter Datumsfilter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Exklusive Obergrenze für `CreateDate`. Wird nur verwendet, wenn kein kombinierter Datumsfilter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Inklusive Untergrenze für `UpdateDate`. Wird nur verwendet, wenn weder kombinierter noch Anlagedatumsfilter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Exklusive Obergrenze für `UpdateDate`. Wird nur verwendet, wenn weder kombinierter noch Anlagedatumsfilter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Inklusive Untergrenze. Trifft zu, wenn `CreateDate` oder `UpdateDate` gleich oder später ist. Hat höchste Priorität. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Exklusive Obergrenze. Trifft zu, wenn `CreateDate` oder `UpdateDate` davor liegt. Hat höchste Priorität. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. 0 oder NULL bedeutet keine Begrenzung. Wird der Parameter (auch mit 0) ohne Datumsfilter übergeben, werden alle Adressen mit Schlüssel größer als `AddrKey` geliefert. |\n\n- Die Tabelle wird `WITH (NOLOCK)` gelesen. Nicht festgeschriebene Änderungen können geliefert werden, und bei gleichzeitigen Änderungen können Zeilen fehlen oder doppelt erscheinen.\n- Die Datumsfiltergruppen werden nicht kombiniert: Es gilt nur die Gruppe mit der höchsten Priorität (kombiniertes Datum > Anlagedatum > Änderungsdatum), die übrigen werden ignoriert.\n- Im kombinierten Modus werden Von- und Bis-Bedingung unabhängig geprüft. Eine Adresse, die vor der Bis-Grenze angelegt und nach der Von-Grenze geändert wurde, wird beispielsweise geliefert, auch wenn keines der Daten im Zeitfenster liegt. Zeilen mit `UpdateDate` NULL können nur über `CreateDate` passen.\n- Wird `AddrKey` zusammen mit einem Datumsfilter oder `RowCount` übergeben, ist er **kein** exakter Treffer, sondern eine exklusive Untergrenze.\n- `RowCount = 0` führt in Modus 4 ohne Zeilenbegrenzung und liefert daher **alle** Adressen oberhalb von `AddrKey`.\n- Ein Aufruf ohne Parameter sucht die Adresse mit `AddrKey = 0` und liefert in der Regel keine Zeile.\n- Das Ergebnis enthält sensible Zahlungsdaten wie Kartennummer, Kartenprüfnummer (`CCCVC`), IBAN und Bankverbindung. Zugriff und Protokollierung sollten entsprechend eingeschränkt werden.\n- Die Spaltentypen von `Addresses` sind im Code nicht ersichtlich. Die Bedeutungen der Spalten in dieser Dokumentation sind aus den Spaltennamen abgeleitet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadAddresses"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10251\n K10251\n C\n SHOP-4711\n SHOP1\n Herr\n Max Mustermann\n Max\n Mustermann\n Hauptstraße\n 12\n Berlin\n 10115\n DE\n max@example.com\n 2024-03-01T09:15:00\n API\n 2024-03-01T10:02:00\n API\n 1\n \n \n 10252\n K10252\n C\n SHOP1\n Frau\n Erika Musterfrau\n Erika\n Musterfrau\n Ringweg\n 3a\n Hamburg\n 20095\n DE\n erika@example.com\n 2024-03-01T11:40:00\n API\n 1\n \n"
}
]
},
{
"name": "pixiReadCustomerAccountMatch",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Ausgleichsdatensätze des Kundenkontos (Paare ausgeglichener Kundenkontobuchungen), gefiltert nach Datum, Kunde oder Kontobuchung, mit Keyset-Paging.\n\nLiest Datensätze aus der Tabelle `CustomerAccountMatch`. Jeder Datensatz verknüpft zwei Kundenkontobuchungen (`CAref1`, `CAref2`) mit dem ausgeglichenen Betrag `AbsoluteMatchAmount`.\n\n**Paging:** `CustomerAccountMatchKey` dient als Cursor. Es werden nur Datensätze mit einem Schlüssel **größer als** dem übergebenen Wert geliefert (NULL wird als `0` behandelt). Es werden höchstens `RowCount` Zeilen geliefert (NULL wird als `1000` behandelt), aufsteigend sortiert nach `CustomerAccountMatchKey`. Für die nächste Seite wird der höchste Schlüssel der vorherigen Seite übergeben.\n\n**Datumsfilter:** Es wird nur eine Gruppe von Datumsfiltern angewendet. Die Gruppen werden in dieser Reihenfolge geprüft:\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: Ein Datensatz erfüllt die Untergrenze, wenn `CreateDate` **oder** `UpdateDate` >= dem Von-Wert ist, und die Obergrenze, wenn `CreateDate` **oder** `UpdateDate` < dem Bis-Wert ist.\n2. `CreateDateFrom` / `CreateDateTo`: Filter auf `CreateDate` (Von inklusive, Bis exklusive).\n3. `UpdateDateFrom` / `UpdateDateTo`: Filter auf `UpdateDate` (Von inklusive, Bis exklusive).\n\nIst in einer höherrangigen Gruppe mindestens ein Wert gesetzt, werden die Datumsparameter der nachrangigen Gruppen ignoriert. Ohne Datumsparameter werden nur der Schlüssel und die übrigen Filter angewendet.\n\n**Weitere Filter (immer angewendet):**\n- `CustRef`: Der Kunde der ersten oder der zweiten verknüpften Kundenkontobuchung muss übereinstimmen.\n- `CustomerAccountKey`: `CAref1` oder `CAref2` muss dem übergebenen Wert entsprechen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustomerAccountMatchKey` | int | Nein | Paging-Cursor: Es werden nur Datensätze mit einem Schlüssel größer als dieser Wert geliefert. NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `CreateDate`. Wird ignoriert, wenn ein kombinierter Anlage-/Änderungsdatumsparameter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusive) für `CreateDate`. Wird ignoriert, wenn ein kombinierter Anlage-/Änderungsdatumsparameter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `UpdateDate`. Wird nur verwendet, wenn weder kombinierte noch Anlagedatumsparameter gesetzt sind. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusive) für `UpdateDate`. Wird nur verwendet, wenn weder kombinierte noch Anlagedatumsparameter gesetzt sind. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusive): Ein Datensatz passt, wenn `CreateDate` oder `UpdateDate` an oder nach diesem Wert liegt. Hat Vorrang vor allen anderen Datumsparametern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (exklusive): Ein Datensatz passt, wenn `CreateDate` oder `UpdateDate` vor diesem Wert liegt. Hat Vorrang vor allen anderen Datumsparametern. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. NULL wird als 1000 behandelt. |\n| `CustRef` | int | Nein | Kundenreferenz: Liefert nur Ausgleiche, bei denen eine der beiden verknüpften Kundenkontobuchungen zu diesem Kunden gehört. |\n| `CustomerAccountKey` | int | Nein | Schlüssel der Kundenkontobuchung: Liefert nur Ausgleiche, bei denen `CAref1` oder `CAref2` diesem Wert entspricht. |\n\n- `CustomerAccountMatchKey` ist **keine** exakte Suche: Da NULL-Werte von `CustomerAccountMatchKey` und `RowCount` zu Beginn durch Standardwerte ersetzt werden, verwendet der Code immer den Bereichszweig (`Schlüssel > Wert`). Der Zweig für einen exakten Schlüsseltreffer und der Zweig für ein leeres Ergebnis werden nie erreicht. Um einen einzelnen Datensatz mit Schlüssel `n` zu lesen, wird `n - 1` und `RowCount = 1` übergeben.\n- Der kombinierte Anlage-/Änderungsdatumsfilter verknüpft seine Bedingungen mit OR; Unter- und Obergrenze können also durch unterschiedliche Datumsspalten erfüllt werden. Das Ergebnis kann daher weiter gefasst sein als ein exaktes Zeitfenster.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; es können nicht festgeschriebene Daten geliefert werden.\n- `RowCount = 0` liefert keine Zeilen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadCustomerAccountMatch"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Ausgleichsdatensätze des Kundenkontos (Paare ausgeglichener Kundenkontobuchungen), gefiltert nach Datum, Kunde oder Kontobuchung, mit Keyset-Paging.\n\nLiest Datensätze aus der Tabelle `CustomerAccountMatch`. Jeder Datensatz verknüpft zwei Kundenkontobuchungen (`CAref1`, `CAref2`) mit dem ausgeglichenen Betrag `AbsoluteMatchAmount`.\n\n**Paging:** `CustomerAccountMatchKey` dient als Cursor. Es werden nur Datensätze mit einem Schlüssel **größer als** dem übergebenen Wert geliefert (NULL wird als `0` behandelt). Es werden höchstens `RowCount` Zeilen geliefert (NULL wird als `1000` behandelt), aufsteigend sortiert nach `CustomerAccountMatchKey`. Für die nächste Seite wird der höchste Schlüssel der vorherigen Seite übergeben.\n\n**Datumsfilter:** Es wird nur eine Gruppe von Datumsfiltern angewendet. Die Gruppen werden in dieser Reihenfolge geprüft:\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: Ein Datensatz erfüllt die Untergrenze, wenn `CreateDate` **oder** `UpdateDate` >= dem Von-Wert ist, und die Obergrenze, wenn `CreateDate` **oder** `UpdateDate` < dem Bis-Wert ist.\n2. `CreateDateFrom` / `CreateDateTo`: Filter auf `CreateDate` (Von inklusive, Bis exklusive).\n3. `UpdateDateFrom` / `UpdateDateTo`: Filter auf `UpdateDate` (Von inklusive, Bis exklusive).\n\nIst in einer höherrangigen Gruppe mindestens ein Wert gesetzt, werden die Datumsparameter der nachrangigen Gruppen ignoriert. Ohne Datumsparameter werden nur der Schlüssel und die übrigen Filter angewendet.\n\n**Weitere Filter (immer angewendet):**\n- `CustRef`: Der Kunde der ersten oder der zweiten verknüpften Kundenkontobuchung muss übereinstimmen.\n- `CustomerAccountKey`: `CAref1` oder `CAref2` muss dem übergebenen Wert entsprechen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustomerAccountMatchKey` | int | Nein | Paging-Cursor: Es werden nur Datensätze mit einem Schlüssel größer als dieser Wert geliefert. NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `CreateDate`. Wird ignoriert, wenn ein kombinierter Anlage-/Änderungsdatumsparameter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusive) für `CreateDate`. Wird ignoriert, wenn ein kombinierter Anlage-/Änderungsdatumsparameter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `UpdateDate`. Wird nur verwendet, wenn weder kombinierte noch Anlagedatumsparameter gesetzt sind. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusive) für `UpdateDate`. Wird nur verwendet, wenn weder kombinierte noch Anlagedatumsparameter gesetzt sind. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusive): Ein Datensatz passt, wenn `CreateDate` oder `UpdateDate` an oder nach diesem Wert liegt. Hat Vorrang vor allen anderen Datumsparametern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (exklusive): Ein Datensatz passt, wenn `CreateDate` oder `UpdateDate` vor diesem Wert liegt. Hat Vorrang vor allen anderen Datumsparametern. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. NULL wird als 1000 behandelt. |\n| `CustRef` | int | Nein | Kundenreferenz: Liefert nur Ausgleiche, bei denen eine der beiden verknüpften Kundenkontobuchungen zu diesem Kunden gehört. |\n| `CustomerAccountKey` | int | Nein | Schlüssel der Kundenkontobuchung: Liefert nur Ausgleiche, bei denen `CAref1` oder `CAref2` diesem Wert entspricht. |\n\n- `CustomerAccountMatchKey` ist **keine** exakte Suche: Da NULL-Werte von `CustomerAccountMatchKey` und `RowCount` zu Beginn durch Standardwerte ersetzt werden, verwendet der Code immer den Bereichszweig (`Schlüssel > Wert`). Der Zweig für einen exakten Schlüsseltreffer und der Zweig für ein leeres Ergebnis werden nie erreicht. Um einen einzelnen Datensatz mit Schlüssel `n` zu lesen, wird `n - 1` und `RowCount = 1` übergeben.\n- Der kombinierte Anlage-/Änderungsdatumsfilter verknüpft seine Bedingungen mit OR; Unter- und Obergrenze können also durch unterschiedliche Datumsspalten erfüllt werden. Das Ergebnis kann daher weiter gefasst sein als ein exaktes Zeitfenster.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; es können nicht festgeschriebene Daten geliefert werden.\n- `RowCount = 0` liefert keine Zeilen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadCustomerAccountMatch"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1201\n 55812\n 55890\n 119.0000\n PIXI\n 2024-01-15T10:22:31\n PIXI\n 2024-01-15T10:22:31\n \n \n 1202\n 55901\n 55934\n 49.9000\n MM\n 2024-01-16T08:05:12\n MM\n 2024-01-17T14:40:03\n \n"
}
]
},
{
"name": "pixiReadCustomers",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kundenstammsätze aus der Tabelle `Customers`, entweder einen Kunden per Schlüssel oder eine nach Anlage-/Änderungsdatum gefilterte Seite.\n\nLiest Kundenstammdaten aus `Customers`. Alle Zweige liefern dieselbe Spaltenliste. Die Parameter wählen genau einen Zweig, geprüft in dieser Reihenfolge:\n\n1. **Anlage- *oder* Änderungsdatum**: Ist `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` gesetzt, werden Kunden mit `CustKey > @CustKey` geliefert, deren `CreateDate` **oder** `UpdateDate` `>= From` ist und deren `CreateDate` **oder** `UpdateDate` `< To` ist. Eine Grenze mit Wert NULL wird ignoriert.\n2. **Anlagedatum**: Andernfalls, wenn `CreateDateFrom` oder `CreateDateTo` gesetzt ist, werden Kunden mit `CustKey > @CustKey` sowie `CreateDate >= From` und `CreateDate < To` geliefert.\n3. **Änderungsdatum**: Andernfalls, wenn `UpdateDateFrom` oder `UpdateDateTo` gesetzt ist, werden Kunden mit `CustKey > @CustKey` sowie `UpdateDate >= From` und `UpdateDate < To` geliefert.\n4. **Schlüsselbereich**: Andernfalls, wenn `RowCount` übergeben wird (beliebiger Wert, auch `0`), werden alle Kunden mit `CustKey > @CustKey` geliefert.\n5. **Einzelner Kunde**: Andernfalls wird der Kunde mit `CustKey = @CustKey` geliefert.\n\nWird `CustKey` nicht übergeben, wird es auf `0` gesetzt. In den Datums- und Schlüsselbereichszweigen bedeutet das \"von Anfang an\". Im Zweig für einen einzelnen Kunden wird dann Schlüssel `0` gesucht, was normalerweise keine Zeile liefert.\n\nDie unteren Datumsgrenzen sind inklusiv, die oberen exklusiv. Die Zweige 1–4 sind aufsteigend nach `CustKey` sortiert. Ist `RowCount` ungleich 0, wird die Zeilenzahl per `SET ROWCOUNT` begrenzt.\n\n**Paging:** Den letzten `CustKey` der vorherigen Seite als `CustKey` zusammen mit `RowCount` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Nein | Kundenschlüssel. Exakte Suche im Zweig für einen einzelnen Kunden. Exklusive Untergrenze (`CustKey > Wert`) in den Datums- und Schlüsselbereichszweigen. NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Inklusive Untergrenze für `CreateDate`. Wird nur verwendet, wenn kein `CreateAndUpdateDate*`-Parameter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Exklusive Obergrenze für `CreateDate`. Wird nur verwendet, wenn kein `CreateAndUpdateDate*`-Parameter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Inklusive Untergrenze für `UpdateDate`. Wird nur verwendet, wenn weder `CreateAndUpdateDate*`- noch `CreateDate*`-Parameter gesetzt sind. |\n| `UpdateDateTo` | datetime | Nein | Exklusive Obergrenze für `UpdateDate`. Wird nur verwendet, wenn weder `CreateAndUpdateDate*`- noch `CreateDate*`-Parameter gesetzt sind. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Inklusive Untergrenze. Ein Kunde passt, wenn `CreateDate` oder `UpdateDate` an oder nach diesem Wert liegt. Hat Vorrang vor allen anderen Datumsparametern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Exklusive Obergrenze. Ein Kunde passt, wenn `CreateDate` oder `UpdateDate` vor diesem Wert liegt. Hat Vorrang vor allen anderen Datumsparametern. |\n| `RowCount` | int | Nein | Maximale Zeilenzahl (per `SET ROWCOUNT`). 0 oder NULL bedeutet keine Begrenzung. Jeder Wert ungleich NULL wählt ohne Datumsfilter den Schlüsselbereichszweig (`CustKey > @CustKey`). |\n\n- In den Datumszweigen ist `CustKey` eine **exklusive Untergrenze** und keine exakte Suche. Ein Kundenschlüssel zusammen mit einem Datumsfilter liefert die Kunden *nach* diesem Schlüssel.\n- Es wird nur eine Datumsfiltergruppe verwendet. `CreateAndUpdateDate*` hat Vorrang vor `CreateDate*`, dieses vor `UpdateDate*`. Werden mehrere Gruppen übergeben, werden die übrigen ignoriert.\n- Im kombinierten Filter ist auch die Obergrenze eine ODER-Bedingung. Ein Kunde, der vor `CreateAndUpdateDateTo` angelegt wurde, passt auch dann, wenn er danach geändert wurde, und umgekehrt.\n- `RowCount = 0` wählt den Schlüsselbereichszweig, begrenzt die Zeilen aber nicht. Es werden also alle Kunden nach `CustKey` geliefert.\n- Die Tabelle wird `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- Das Ergebnis enthält sensible Daten wie `Password`, Kreditkartenfelder (`CardNr`, `CardExp`) und Bankdaten (`Account`, `BLZ`). Diese sind entsprechend zu behandeln.\n- Der letzte Zweig \"keine Daten\" (`WHERE 1 = 0`) ist nicht erreichbar, da `CustKey` nach dem Ersetzen des Standardwerts nie NULL ist.\n- Die Datentypen der Spalten sind in der Prozedur nicht sichtbar. Sie stammen aus der Tabelle `Customers`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadCustomers"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kundenstammsätze aus der Tabelle `Customers`, entweder einen Kunden per Schlüssel oder eine nach Anlage-/Änderungsdatum gefilterte Seite.\n\nLiest Kundenstammdaten aus `Customers`. Alle Zweige liefern dieselbe Spaltenliste. Die Parameter wählen genau einen Zweig, geprüft in dieser Reihenfolge:\n\n1. **Anlage- *oder* Änderungsdatum**: Ist `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` gesetzt, werden Kunden mit `CustKey > @CustKey` geliefert, deren `CreateDate` **oder** `UpdateDate` `>= From` ist und deren `CreateDate` **oder** `UpdateDate` `< To` ist. Eine Grenze mit Wert NULL wird ignoriert.\n2. **Anlagedatum**: Andernfalls, wenn `CreateDateFrom` oder `CreateDateTo` gesetzt ist, werden Kunden mit `CustKey > @CustKey` sowie `CreateDate >= From` und `CreateDate < To` geliefert.\n3. **Änderungsdatum**: Andernfalls, wenn `UpdateDateFrom` oder `UpdateDateTo` gesetzt ist, werden Kunden mit `CustKey > @CustKey` sowie `UpdateDate >= From` und `UpdateDate < To` geliefert.\n4. **Schlüsselbereich**: Andernfalls, wenn `RowCount` übergeben wird (beliebiger Wert, auch `0`), werden alle Kunden mit `CustKey > @CustKey` geliefert.\n5. **Einzelner Kunde**: Andernfalls wird der Kunde mit `CustKey = @CustKey` geliefert.\n\nWird `CustKey` nicht übergeben, wird es auf `0` gesetzt. In den Datums- und Schlüsselbereichszweigen bedeutet das \"von Anfang an\". Im Zweig für einen einzelnen Kunden wird dann Schlüssel `0` gesucht, was normalerweise keine Zeile liefert.\n\nDie unteren Datumsgrenzen sind inklusiv, die oberen exklusiv. Die Zweige 1–4 sind aufsteigend nach `CustKey` sortiert. Ist `RowCount` ungleich 0, wird die Zeilenzahl per `SET ROWCOUNT` begrenzt.\n\n**Paging:** Den letzten `CustKey` der vorherigen Seite als `CustKey` zusammen mit `RowCount` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Nein | Kundenschlüssel. Exakte Suche im Zweig für einen einzelnen Kunden. Exklusive Untergrenze (`CustKey > Wert`) in den Datums- und Schlüsselbereichszweigen. NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Inklusive Untergrenze für `CreateDate`. Wird nur verwendet, wenn kein `CreateAndUpdateDate*`-Parameter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Exklusive Obergrenze für `CreateDate`. Wird nur verwendet, wenn kein `CreateAndUpdateDate*`-Parameter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Inklusive Untergrenze für `UpdateDate`. Wird nur verwendet, wenn weder `CreateAndUpdateDate*`- noch `CreateDate*`-Parameter gesetzt sind. |\n| `UpdateDateTo` | datetime | Nein | Exklusive Obergrenze für `UpdateDate`. Wird nur verwendet, wenn weder `CreateAndUpdateDate*`- noch `CreateDate*`-Parameter gesetzt sind. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Inklusive Untergrenze. Ein Kunde passt, wenn `CreateDate` oder `UpdateDate` an oder nach diesem Wert liegt. Hat Vorrang vor allen anderen Datumsparametern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Exklusive Obergrenze. Ein Kunde passt, wenn `CreateDate` oder `UpdateDate` vor diesem Wert liegt. Hat Vorrang vor allen anderen Datumsparametern. |\n| `RowCount` | int | Nein | Maximale Zeilenzahl (per `SET ROWCOUNT`). 0 oder NULL bedeutet keine Begrenzung. Jeder Wert ungleich NULL wählt ohne Datumsfilter den Schlüsselbereichszweig (`CustKey > @CustKey`). |\n\n- In den Datumszweigen ist `CustKey` eine **exklusive Untergrenze** und keine exakte Suche. Ein Kundenschlüssel zusammen mit einem Datumsfilter liefert die Kunden *nach* diesem Schlüssel.\n- Es wird nur eine Datumsfiltergruppe verwendet. `CreateAndUpdateDate*` hat Vorrang vor `CreateDate*`, dieses vor `UpdateDate*`. Werden mehrere Gruppen übergeben, werden die übrigen ignoriert.\n- Im kombinierten Filter ist auch die Obergrenze eine ODER-Bedingung. Ein Kunde, der vor `CreateAndUpdateDateTo` angelegt wurde, passt auch dann, wenn er danach geändert wurde, und umgekehrt.\n- `RowCount = 0` wählt den Schlüsselbereichszweig, begrenzt die Zeilen aber nicht. Es werden also alle Kunden nach `CustKey` geliefert.\n- Die Tabelle wird `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- Das Ergebnis enthält sensible Daten wie `Password`, Kreditkartenfelder (`CardNr`, `CardExp`) und Bankdaten (`Account`, `BLZ`). Diese sind entsprechend zu behandeln.\n- Der letzte Zweig \"keine Daten\" (`WHERE 1 = 0`) ist nicht erreichbar, da `CustKey` nach dem Ersetzen des Standardwerts nie NULL ist.\n- Die Datentypen der Spalten sind in der Prozedur nicht sichtbar. Sie stammen aus der Tabelle `Customers`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadCustomers"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10235\n max.mustermann\n Max Mustermann\n Hauptstraße\n 12\n 80331\n München\n DE\n max@example.com\n SHOP-4711\n 2024-03-01T10:15:00\n 2024-03-01T12:00:00\n \n"
}
]
},
{
"name": "pixiRepairCustomerData",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungs- und Lieferadressen sowie Shop-Notizen der in einem Zeitraum angelegten Aufträge als Vorschau für die Bereinigung ungültiger Zeichen.\n\nLaut Kopfkommentar dient die Prozedur dazu, *ungültige Zeichen für die API-Ausgabe zu reparieren*. Der aktuelle Code ändert jedoch keine Daten. Er selektiert nur die betroffenen Datensätze.\n\nAblauf:\n\n1. Ohne `FromDate` wird der Beginn des aktuellen Tages (00:00:00) verwendet. Ohne `ToDate` wird das Ende des aktuellen Tages (23:59:59.997) verwendet.\n2. Aus `OrderHeader` werden alle Aufträge ermittelt, deren `CreateDate` zwischen `FromDate` und `ToDate` liegt (jeweils einschließlich) und die sowohl eine Rechnungsadresse (`AddrRef <> 0`) als auch eine Lieferadresse (`ShipAdrRef <> 0`) besitzen.\n3. Die Rechnungs- und Lieferadressschlüssel dieser Aufträge werden gesammelt.\n4. Anschließend wird eine Transaktion geöffnet:\n - Bei `CommitResult = 1` wird die leere Transaktion bestätigt. Es wird keine Ergebnismenge geliefert.\n - Andernfalls (0 oder NULL) werden zwei Ergebnismengen geliefert, danach wird die Transaktion zurückgerollt:\n - die Namens-, Adress- und Telefonfelder aller gesammelten Adressen aus `Addresses`. Jede Adresse erscheint nur einmal.\n - `OrderNr` und `Shop_Note` aller gesammelten Aufträge.\n\nDie Sortierung beider Ergebnismengen ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Nein | Beginn des Zeitraums für das Anlagedatum der Aufträge (einschließlich). Bei NULL wird der Beginn des aktuellen Tages verwendet. |\n| `ToDate` | datetime | Nein | Ende des Zeitraums für das Anlagedatum der Aufträge (einschließlich). Bei NULL wird das Ende des aktuellen Tages (23:59:59.997) verwendet. |\n| `CommitResult` | bit | Nein | Steuert, ob die Transaktion bestätigt wird oder die betroffenen Daten als Vorschau geliefert werden. |\n\n- Trotz des Namens führt die Prozedur keine Änderungen durch. Die Transaktion enthält keine Datenänderungen. `CommitResult = 1` bewirkt daher nur, dass keine Ausgabe erfolgt. Die eigentliche Reparaturlogik wurde offenbar entfernt.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`. Daher können auch nicht festgeschriebene Daten geliefert werden.\n- Aufträge ohne Rechnungs- oder Lieferadresse (Referenz 0) werden vollständig ignoriert.\n- Große Zeiträume können zu umfangreichen Ergebnismengen führen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiRepairCustomerData"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungs- und Lieferadressen sowie Shop-Notizen der in einem Zeitraum angelegten Aufträge als Vorschau für die Bereinigung ungültiger Zeichen.\n\nLaut Kopfkommentar dient die Prozedur dazu, *ungültige Zeichen für die API-Ausgabe zu reparieren*. Der aktuelle Code ändert jedoch keine Daten. Er selektiert nur die betroffenen Datensätze.\n\nAblauf:\n\n1. Ohne `FromDate` wird der Beginn des aktuellen Tages (00:00:00) verwendet. Ohne `ToDate` wird das Ende des aktuellen Tages (23:59:59.997) verwendet.\n2. Aus `OrderHeader` werden alle Aufträge ermittelt, deren `CreateDate` zwischen `FromDate` und `ToDate` liegt (jeweils einschließlich) und die sowohl eine Rechnungsadresse (`AddrRef <> 0`) als auch eine Lieferadresse (`ShipAdrRef <> 0`) besitzen.\n3. Die Rechnungs- und Lieferadressschlüssel dieser Aufträge werden gesammelt.\n4. Anschließend wird eine Transaktion geöffnet:\n - Bei `CommitResult = 1` wird die leere Transaktion bestätigt. Es wird keine Ergebnismenge geliefert.\n - Andernfalls (0 oder NULL) werden zwei Ergebnismengen geliefert, danach wird die Transaktion zurückgerollt:\n - die Namens-, Adress- und Telefonfelder aller gesammelten Adressen aus `Addresses`. Jede Adresse erscheint nur einmal.\n - `OrderNr` und `Shop_Note` aller gesammelten Aufträge.\n\nDie Sortierung beider Ergebnismengen ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Nein | Beginn des Zeitraums für das Anlagedatum der Aufträge (einschließlich). Bei NULL wird der Beginn des aktuellen Tages verwendet. |\n| `ToDate` | datetime | Nein | Ende des Zeitraums für das Anlagedatum der Aufträge (einschließlich). Bei NULL wird das Ende des aktuellen Tages (23:59:59.997) verwendet. |\n| `CommitResult` | bit | Nein | Steuert, ob die Transaktion bestätigt wird oder die betroffenen Daten als Vorschau geliefert werden. |\n\n- Trotz des Namens führt die Prozedur keine Änderungen durch. Die Transaktion enthält keine Datenänderungen. `CommitResult = 1` bewirkt daher nur, dass keine Ausgabe erfolgt. Die eigentliche Reparaturlogik wurde offenbar entfernt.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`. Daher können auch nicht festgeschriebene Daten geliefert werden.\n- Aufträge ohne Rechnungs- oder Lieferadresse (Referenz 0) werden vollständig ignoriert.\n- Große Zeiträume können zu umfangreichen Ergebnismengen führen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiRepairCustomerData"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Herr\n \n Max Mustermann\n \n Max\n Mustermann\n Hauptstraße\n 12\n Berlin\n \n DE\n 030 123456\n \n \n"
}
]
},
{
"name": "pixiSatisfiedCustomers",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert fakturierte Kunden (oder die Rechnungspositionen eines Kunden) in einem Liefer- und Bestellzeitraum, z. B. für Zufriedenheitsumfragen oder Bewertungsanfragen.\n\nWählt Rechnungspositionen zusammen mit den zugehörigen Auftragspositionen und der Rechnungsadresse aus. Das Ergebnis eignet sich, um Kunden zu kontaktieren, die kürzlich Ware erhalten haben.\n\n**Zeitraum**: Die Tagesparameter beziehen sich auf das aktuelle Serverdatum (`GETDATE()`):\n- `MaxDaysSinceDelivery`: Rechnungsdatum (`InvDate`) muss am oder nach dem Tagesbeginn vor *N* Tagen liegen.\n- `MinDaysSinceDelivery`: Rechnungsdatum muss am oder vor dem Tagesende vor *N* Tagen liegen.\n- `MaxDaysSinceOrder` / `MinDaysSinceOrder`: entsprechend für das Bestelldatum der Auftragsposition.\n- `NULL` deaktiviert die jeweilige Grenze.\n\n**Weitere Filter**:\n- Rechnungen, auf die eine andere Rechnung (`RefToInvoiceKey`, z. B. Gutschrift) mit Rechnungsdatum ab dem `MaxDaysSinceDelivery`-Datum verweist, werden ausgeschlossen.\n- Positionen, deren Auftragsposition den Status `MIN` und ein Bestelldatum ab dem `MaxDaysSinceDelivery`-Datum hat, werden ausgeschlossen.\n- `ExcludePartialDeliveries = 1`: Aufträge (über `OrderNr`), die noch Auftragspositionen im Status `ANG` oder `EIN` haben, werden ausgeschlossen.\n- `NoOrderSince = 1`: Kunden mit einer Auftragsposition, deren Bestelldatum am oder nach dem `MinDaysSinceDelivery`-Datum liegt, werden ausgeschlossen.\n- Nur Positionen mit `ItemQty >= 0`.\n\n**Zwei Modi**:\n- `CustomerNrExternal` ist `NULL`: eine Zeile pro externer Kundennummer (`GROUP BY Addresses.CustomerNrExternal`), sortiert nach Kundennummer. `ItemQty` ist die **Anzahl** der passenden Rechnungspositionen.\n- `CustomerNrExternal` ist gesetzt: nur Positionen dieses Kunden, eine Zeile pro Rechnungsposition (`GROUP BY Invlinekey`), ohne explizite Sortierung. `ItemQty` ist die Menge der Position.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `MaxDaysSinceDelivery` | int | Nein | Ältestes Rechnungsdatum in Tagen vor heute; Rechnungsdatum muss am oder nach dem Beginn dieses Tages liegen. NULL = keine Untergrenze. |\n| `MinDaysSinceDelivery` | int | Nein | Jüngstes Rechnungsdatum in Tagen vor heute; Rechnungsdatum muss am oder vor dem Ende dieses Tages liegen. Wird auch von NoOrderSince verwendet. NULL = keine Obergrenze. |\n| `MaxDaysSinceOrder` | int | Nein | Ältestes Bestelldatum in Tagen vor heute (Tagesbeginn). NULL = keine Untergrenze. |\n| `MinDaysSinceOrder` | int | Nein | Jüngstes Bestelldatum in Tagen vor heute (Tagesende). NULL = keine Obergrenze. |\n| `CustomerNrExternal` | varchar(60) | Nein | Externe Kundennummer der Rechnungsadresse. Wenn gesetzt, eine Zeile pro Rechnungsposition dieses Kunden; bei NULL eine Zeile pro Kunde. |\n| `ExcludePartialDeliveries` | bit | Nein | Schließt Aufträge aus, die noch Auftragspositionen im Status ANG oder EIN haben. |\n| `NoOrderSince` | bit | Nein | Schließt Kunden aus, die am oder nach dem MinDaysSinceDelivery-Datum bestellt haben. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Im Kundenmodus wird jede Spalte unabhängig mit `MAX`/`MIN` aggregiert, daher können `InvoiceNr`, `ItemText`, `ItemPrice`, `ItemNrShop` usw. aus unterschiedlichen Rechnungen oder Positionen desselben Kunden stammen.\n- Adressen ohne externe Kundennummer werden im Kundenmodus zu einer `NULL`-Zeile zusammengefasst.\n- Der Gutschriftsfilter und der Filter auf Status `MIN` greifen nur, wenn `MaxDaysSinceDelivery` gesetzt ist; bei `NULL` trifft der Vergleich nie zu und nichts wird ausgeschlossen.\n- `NoOrderSince = 1` wirkt nur, wenn `MinDaysSinceDelivery` gesetzt ist, da gegen dieses Datum verglichen wird.\n- Die Tabelle zu `ItemQty`, `ItemText`, `ItemPrice`, `orderdate` und `Status` ist im Code nicht qualifiziert; vermutlich Rechnungs- bzw. Auftragspositionen.\n- Die Bedeutung der Auftragspositionsstatus `MIN`, `ANG` und `EIN` ist im Code nicht definiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSatisfiedCustomers"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert fakturierte Kunden (oder die Rechnungspositionen eines Kunden) in einem Liefer- und Bestellzeitraum, z. B. für Zufriedenheitsumfragen oder Bewertungsanfragen.\n\nWählt Rechnungspositionen zusammen mit den zugehörigen Auftragspositionen und der Rechnungsadresse aus. Das Ergebnis eignet sich, um Kunden zu kontaktieren, die kürzlich Ware erhalten haben.\n\n**Zeitraum**: Die Tagesparameter beziehen sich auf das aktuelle Serverdatum (`GETDATE()`):\n- `MaxDaysSinceDelivery`: Rechnungsdatum (`InvDate`) muss am oder nach dem Tagesbeginn vor *N* Tagen liegen.\n- `MinDaysSinceDelivery`: Rechnungsdatum muss am oder vor dem Tagesende vor *N* Tagen liegen.\n- `MaxDaysSinceOrder` / `MinDaysSinceOrder`: entsprechend für das Bestelldatum der Auftragsposition.\n- `NULL` deaktiviert die jeweilige Grenze.\n\n**Weitere Filter**:\n- Rechnungen, auf die eine andere Rechnung (`RefToInvoiceKey`, z. B. Gutschrift) mit Rechnungsdatum ab dem `MaxDaysSinceDelivery`-Datum verweist, werden ausgeschlossen.\n- Positionen, deren Auftragsposition den Status `MIN` und ein Bestelldatum ab dem `MaxDaysSinceDelivery`-Datum hat, werden ausgeschlossen.\n- `ExcludePartialDeliveries = 1`: Aufträge (über `OrderNr`), die noch Auftragspositionen im Status `ANG` oder `EIN` haben, werden ausgeschlossen.\n- `NoOrderSince = 1`: Kunden mit einer Auftragsposition, deren Bestelldatum am oder nach dem `MinDaysSinceDelivery`-Datum liegt, werden ausgeschlossen.\n- Nur Positionen mit `ItemQty >= 0`.\n\n**Zwei Modi**:\n- `CustomerNrExternal` ist `NULL`: eine Zeile pro externer Kundennummer (`GROUP BY Addresses.CustomerNrExternal`), sortiert nach Kundennummer. `ItemQty` ist die **Anzahl** der passenden Rechnungspositionen.\n- `CustomerNrExternal` ist gesetzt: nur Positionen dieses Kunden, eine Zeile pro Rechnungsposition (`GROUP BY Invlinekey`), ohne explizite Sortierung. `ItemQty` ist die Menge der Position.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `MaxDaysSinceDelivery` | int | Nein | Ältestes Rechnungsdatum in Tagen vor heute; Rechnungsdatum muss am oder nach dem Beginn dieses Tages liegen. NULL = keine Untergrenze. |\n| `MinDaysSinceDelivery` | int | Nein | Jüngstes Rechnungsdatum in Tagen vor heute; Rechnungsdatum muss am oder vor dem Ende dieses Tages liegen. Wird auch von NoOrderSince verwendet. NULL = keine Obergrenze. |\n| `MaxDaysSinceOrder` | int | Nein | Ältestes Bestelldatum in Tagen vor heute (Tagesbeginn). NULL = keine Untergrenze. |\n| `MinDaysSinceOrder` | int | Nein | Jüngstes Bestelldatum in Tagen vor heute (Tagesende). NULL = keine Obergrenze. |\n| `CustomerNrExternal` | varchar(60) | Nein | Externe Kundennummer der Rechnungsadresse. Wenn gesetzt, eine Zeile pro Rechnungsposition dieses Kunden; bei NULL eine Zeile pro Kunde. |\n| `ExcludePartialDeliveries` | bit | Nein | Schließt Aufträge aus, die noch Auftragspositionen im Status ANG oder EIN haben. |\n| `NoOrderSince` | bit | Nein | Schließt Kunden aus, die am oder nach dem MinDaysSinceDelivery-Datum bestellt haben. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Im Kundenmodus wird jede Spalte unabhängig mit `MAX`/`MIN` aggregiert, daher können `InvoiceNr`, `ItemText`, `ItemPrice`, `ItemNrShop` usw. aus unterschiedlichen Rechnungen oder Positionen desselben Kunden stammen.\n- Adressen ohne externe Kundennummer werden im Kundenmodus zu einer `NULL`-Zeile zusammengefasst.\n- Der Gutschriftsfilter und der Filter auf Status `MIN` greifen nur, wenn `MaxDaysSinceDelivery` gesetzt ist; bei `NULL` trifft der Vergleich nie zu und nichts wird ausgeschlossen.\n- `NoOrderSince = 1` wirkt nur, wenn `MinDaysSinceDelivery` gesetzt ist, da gegen dieses Datum verglichen wird.\n- Die Tabelle zu `ItemQty`, `ItemText`, `ItemPrice`, `orderdate` und `Status` ist im Code nicht qualifiziert; vermutlich Rechnungs- bzw. Auftragspositionen.\n- Die Bedeutung der Auftragspositionsstatus `MIN`, `ANG` und `EIN` ist im Code nicht definiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSatisfiedCustomers"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n RE2024-10452\n 88213\n K100234\n SHOP1\n Frau\n Anna Müller\n anna.mueller@example.de\n 2024-05-03T14:22:10\n 2024-04-29T09:15:00\n Trekkingschuh Alpin\n 2\n TS-ALP-42\n 89.9000\n \n"
}
]
},
{
"name": "pixiSetCustomerDiscount",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt den Rabatt in Prozent (`Rabat`) eines Kunden, der über E-Mail-Adresse und/oder externe Kundennummer ermittelt wird.\n\nAktualisiert das Feld `Rabat` genau eines Kunden in `Customers` und liefert eine Statuszeile.\n\n**Prüfungen**\n- `Discount` ist Pflicht und muss zwischen 0 und 100 liegen (einschließlich).\n- Leere Zeichenketten in `CustMail` und `CustNr` werden als `NULL` behandelt. Mindestens einer der beiden Parameter muss angegeben werden.\n\n**Kundensuche**\n\nGezählt werden Kunden mit `CeMail = CustMail`, Kunden mit `CustomerNrExternal = CustNr` sowie Kunden, auf die beides zutrifft. Ohne `CustNr` verlangt die letzte Prüfung nur eine passende E-Mail-Adresse und eine nicht leere (nicht NULL) Kundennummer. Die Auswahl erfolgt so:\n1. Hat genau ein Kunde die E-Mail-Adresse, wird dieser Kunde verwendet. `CustNr` wird dann ignoriert.\n2. Hat kein Kunde die E-Mail-Adresse, aber genau ein Kunde die Kundennummer, wird dieser verwendet.\n3. Haben mehrere Kunden die E-Mail-Adresse und passt genau einer davon zur Kundennummer, wird dieser verwendet.\n4. Andernfalls wird eine Fehlerzeile geliefert, entweder *More then one customer found…* oder *No customer found…*.\n\n**Aktualisierung und Ergebnis**\n\nFür den gefundenen Kunden wird `Rabat` auf `Discount` gesetzt. Anschließend wird eine Zeile mit `Status` = `Success` geliefert. Die Meldung enthält den neuen Rabatt, die E-Mail-Adresse und die externe Kundennummer des Kunden. Alle Fehler, auch Prüfungsfehler, werden als einzelne Zeile mit `Status` = `Error` und dem Fehlertext in `Message` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustMail` | varchar(256) | Nein | E-Mail-Adresse des Kunden (`CeMail`). Eine leere Zeichenkette gilt als NULL. Dieser Parameter oder `CustNr` muss angegeben werden. |\n| `CustNr` | varchar(60) | Nein | Externe Kundennummer (`CustomerNrExternal`). Eine leere Zeichenkette gilt als NULL. Wird verwendet, wenn kein Kunde die E-Mail-Adresse hat, oder um zwischen mehreren Kunden mit derselben E-Mail-Adresse zu unterscheiden. |\n| `Discount` | numeric(6, 2) | Nein | Rabatt in Prozent, der in `Rabat` gespeichert wird. Faktisch Pflicht: Der Wert muss angegeben werden und zwischen 0 und 100 liegen. |\n\n- Fehler kommen nie als `SqlMessage` zurück. Sie werden abgefangen und als Zeile mit `Status` = `Error` geliefert; daher immer die Spalte `Status` prüfen.\n- Stolperfalle: Passt die E-Mail-Adresse zu genau einem Kunden, wird dieser Kunde aktualisiert, auch wenn die angegebene `CustNr` zu einem anderen oder zu keinem Kunden gehört.\n- Die Erfolgsmeldung wird per Zeichenkettenverkettung erzeugt. Ist `CeMail` oder `CustomerNrExternal` des Kunden `NULL`, ist `Message` voraussichtlich `NULL` (übliches SQL-Server-Verhalten bei `CONCAT_NULL_YIELDS_NULL`), obwohl die Aktualisierung erfolgt ist.\n- Die Suchabfragen verwenden `NOLOCK`, das Update verwendet `ROWLOCK`. Eine explizite Transaktion gibt es nicht.\n- E-Mail-Adresse und Kundennummer werden mit `=` verglichen. Ob dabei Groß-/Kleinschreibung zählt, hängt von der Datenbank-Collation ab.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetCustomerDiscount"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt den Rabatt in Prozent (`Rabat`) eines Kunden, der über E-Mail-Adresse und/oder externe Kundennummer ermittelt wird.\n\nAktualisiert das Feld `Rabat` genau eines Kunden in `Customers` und liefert eine Statuszeile.\n\n**Prüfungen**\n- `Discount` ist Pflicht und muss zwischen 0 und 100 liegen (einschließlich).\n- Leere Zeichenketten in `CustMail` und `CustNr` werden als `NULL` behandelt. Mindestens einer der beiden Parameter muss angegeben werden.\n\n**Kundensuche**\n\nGezählt werden Kunden mit `CeMail = CustMail`, Kunden mit `CustomerNrExternal = CustNr` sowie Kunden, auf die beides zutrifft. Ohne `CustNr` verlangt die letzte Prüfung nur eine passende E-Mail-Adresse und eine nicht leere (nicht NULL) Kundennummer. Die Auswahl erfolgt so:\n1. Hat genau ein Kunde die E-Mail-Adresse, wird dieser Kunde verwendet. `CustNr` wird dann ignoriert.\n2. Hat kein Kunde die E-Mail-Adresse, aber genau ein Kunde die Kundennummer, wird dieser verwendet.\n3. Haben mehrere Kunden die E-Mail-Adresse und passt genau einer davon zur Kundennummer, wird dieser verwendet.\n4. Andernfalls wird eine Fehlerzeile geliefert, entweder *More then one customer found…* oder *No customer found…*.\n\n**Aktualisierung und Ergebnis**\n\nFür den gefundenen Kunden wird `Rabat` auf `Discount` gesetzt. Anschließend wird eine Zeile mit `Status` = `Success` geliefert. Die Meldung enthält den neuen Rabatt, die E-Mail-Adresse und die externe Kundennummer des Kunden. Alle Fehler, auch Prüfungsfehler, werden als einzelne Zeile mit `Status` = `Error` und dem Fehlertext in `Message` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustMail` | varchar(256) | Nein | E-Mail-Adresse des Kunden (`CeMail`). Eine leere Zeichenkette gilt als NULL. Dieser Parameter oder `CustNr` muss angegeben werden. |\n| `CustNr` | varchar(60) | Nein | Externe Kundennummer (`CustomerNrExternal`). Eine leere Zeichenkette gilt als NULL. Wird verwendet, wenn kein Kunde die E-Mail-Adresse hat, oder um zwischen mehreren Kunden mit derselben E-Mail-Adresse zu unterscheiden. |\n| `Discount` | numeric(6, 2) | Nein | Rabatt in Prozent, der in `Rabat` gespeichert wird. Faktisch Pflicht: Der Wert muss angegeben werden und zwischen 0 und 100 liegen. |\n\n- Fehler kommen nie als `SqlMessage` zurück. Sie werden abgefangen und als Zeile mit `Status` = `Error` geliefert; daher immer die Spalte `Status` prüfen.\n- Stolperfalle: Passt die E-Mail-Adresse zu genau einem Kunden, wird dieser Kunde aktualisiert, auch wenn die angegebene `CustNr` zu einem anderen oder zu keinem Kunden gehört.\n- Die Erfolgsmeldung wird per Zeichenkettenverkettung erzeugt. Ist `CeMail` oder `CustomerNrExternal` des Kunden `NULL`, ist `Message` voraussichtlich `NULL` (übliches SQL-Server-Verhalten bei `CONCAT_NULL_YIELDS_NULL`), obwohl die Aktualisierung erfolgt ist.\n- Die Suchabfragen verwenden `NOLOCK`, das Update verwendet `ROWLOCK`. Eine explizite Transaktion gibt es nicht.\n- E-Mail-Adresse und Kundennummer werden mit `=` verglichen. Ob dabei Groß-/Kleinschreibung zählt, hängt von der Datenbank-Collation ab.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetCustomerDiscount"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n Discount of 7.50% was set for customer: (e-mail: \"max.mustermann@example.com\" customer number: \"K100234\")\n \n"
}
]
},
{
"name": "pixiSetShippingLock",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder entfernt die Liefersperre (`SLocked`) eines Kunden, identifiziert über `CustKey` oder über externe Kundennummer und Shop.\n\nSetzt das Liefersperre-Kennzeichen eines Kundendatensatzes in `Customers`.\n\n1. `UserName` wird getrimmt. Ist der Wert leer oder nicht angegeben, wird `API` verwendet. Der Wert wird in `Customers.UpdateEmp` geschrieben.\n2. `Locked` wird in den gespeicherten Wert umgesetzt: `1` wird zu `Y`. Jeder andere Wert, auch `0` und `NULL`, wird zu `N`.\n3. Ist `CustomerNrExternal` nicht leer, ermittelt die Prozedur den `CustKey` des Kunden, dessen `CustomerNrExternal` übereinstimmt und dessen `CustomerOf` gleich `ShopID` ist. Passen mehrere Kunden, wird nur einer davon verwendet (`TOP 1`, ohne definierte Reihenfolge).\n4. Beim Kunden mit dem ermittelten `CustKey` werden `SLocked` und `UpdateEmp` aktualisiert.\n5. Zurückgegeben wird eine Zeile mit der Spalte `Result`: `0`, wenn genau ein Kunde aktualisiert wurde, sonst `1`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Nein | Interner Schlüssel des Kunden. Wird verwendet, wenn `CustomerNrExternal` leer ist oder darüber kein passender Kunde gefunden wird. |\n| `Locked` | bit | Nein | `1` setzt die Liefersperre (`SLocked` = `Y`). Jeder andere Wert hebt sie auf (`SLocked` = `N`). |\n| `CustomerNrExternal` | varchar(250) | Nein | Externe Kundennummer, z. B. aus dem Shop. Ist sie gesetzt, wird der Kunde über diese Nummer zusammen mit `ShopID` gesucht. |\n| `ShopID` | varchar(3) | Nein | Shop-Kürzel, das mit `Customers.CustomerOf` verglichen wird. Für die Suche über `CustomerNrExternal` erforderlich. |\n| `UserName` | varchar(50) | Nein | Benutzername, der in `UpdateEmp` geschrieben wird. Ist er leer oder nicht angegeben, wird `API` verwendet. |\n\n- Ist `CustomerNrExternal` angegeben, passt aber kein Kunde, behält die Variable den übergebenen `CustKey`. In diesem Fall wird der Kunde mit diesem `CustKey` aktualisiert, oder es wird nichts aktualisiert, wenn `CustKey` `NULL` ist.\n- `ShopID` wird mit `=` verglichen. Ist `ShopID` `NULL`, während `CustomerNrExternal` gesetzt ist, findet die Suche nie einen Treffer.\n- Wird weder `CustKey` noch eine passende externe Nummer übergeben, wird keine Zeile aktualisiert und `Result` = `1` zurückgegeben.\n- Die Suche verwendet `UPDLOCK`. Es gibt keine explizite Transaktion, daher gilt die Sperre nur für die Dauer dieser Anweisung.\n- Es werden keine Fehlermeldungen erzeugt. Erfolg oder Misserfolg zeigt nur der Wert `Result` an.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetShippingLock"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder entfernt die Liefersperre (`SLocked`) eines Kunden, identifiziert über `CustKey` oder über externe Kundennummer und Shop.\n\nSetzt das Liefersperre-Kennzeichen eines Kundendatensatzes in `Customers`.\n\n1. `UserName` wird getrimmt. Ist der Wert leer oder nicht angegeben, wird `API` verwendet. Der Wert wird in `Customers.UpdateEmp` geschrieben.\n2. `Locked` wird in den gespeicherten Wert umgesetzt: `1` wird zu `Y`. Jeder andere Wert, auch `0` und `NULL`, wird zu `N`.\n3. Ist `CustomerNrExternal` nicht leer, ermittelt die Prozedur den `CustKey` des Kunden, dessen `CustomerNrExternal` übereinstimmt und dessen `CustomerOf` gleich `ShopID` ist. Passen mehrere Kunden, wird nur einer davon verwendet (`TOP 1`, ohne definierte Reihenfolge).\n4. Beim Kunden mit dem ermittelten `CustKey` werden `SLocked` und `UpdateEmp` aktualisiert.\n5. Zurückgegeben wird eine Zeile mit der Spalte `Result`: `0`, wenn genau ein Kunde aktualisiert wurde, sonst `1`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Nein | Interner Schlüssel des Kunden. Wird verwendet, wenn `CustomerNrExternal` leer ist oder darüber kein passender Kunde gefunden wird. |\n| `Locked` | bit | Nein | `1` setzt die Liefersperre (`SLocked` = `Y`). Jeder andere Wert hebt sie auf (`SLocked` = `N`). |\n| `CustomerNrExternal` | varchar(250) | Nein | Externe Kundennummer, z. B. aus dem Shop. Ist sie gesetzt, wird der Kunde über diese Nummer zusammen mit `ShopID` gesucht. |\n| `ShopID` | varchar(3) | Nein | Shop-Kürzel, das mit `Customers.CustomerOf` verglichen wird. Für die Suche über `CustomerNrExternal` erforderlich. |\n| `UserName` | varchar(50) | Nein | Benutzername, der in `UpdateEmp` geschrieben wird. Ist er leer oder nicht angegeben, wird `API` verwendet. |\n\n- Ist `CustomerNrExternal` angegeben, passt aber kein Kunde, behält die Variable den übergebenen `CustKey`. In diesem Fall wird der Kunde mit diesem `CustKey` aktualisiert, oder es wird nichts aktualisiert, wenn `CustKey` `NULL` ist.\n- `ShopID` wird mit `=` verglichen. Ist `ShopID` `NULL`, während `CustomerNrExternal` gesetzt ist, findet die Suche nie einen Treffer.\n- Wird weder `CustKey` noch eine passende externe Nummer übergeben, wird keine Zeile aktualisiert und `Result` = `1` zurückgegeben.\n- Die Suche verwendet `UPDLOCK`. Es gibt keine explizite Transaktion, daher gilt die Sperre nur für die Dauer dieser Anweisung.\n- Es werden keine Fehlermeldungen erzeugt. Erfolg oder Misserfolg zeigt nur der Wert `Result` an.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetShippingLock"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 0\n \n"
}
]
},
{
"name": "pixiShowSpecialCommentCustomers",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kunden mit Kundenhistorien-Notiz (CHisNote) zusammen mit ihren Rechnungen, optional gefiltert nach einer Rechnungsnummer.\n\nLiest Kundenkonto-Einträge (`CustomerAccount`) und verknüpft sie mit Kunde, Rechnung und Rechnungswährung. Jede Ergebniszeile entspricht einem Kundenkonto-Eintrag.\n\nDer Aufruf arbeitet in zwei Modi:\n\n- **`InvoiceNr` angegeben**: liefert die Einträge, deren Rechnung genau diese Rechnungsnummer hat. Die Kundennotiz `CHisNote` wird in diesem Modus **nicht** geprüft, daher werden auch Kunden ohne Notiz geliefert. Es gibt keine Sortierung.\n- **`InvoiceNr` leer oder weggelassen**: liefert alle Einträge, deren Kunde eine nicht leere `CHisNote` hat und deren Rechnung eine nicht leere Rechnungsnummer besitzt. Die Zeilen sind nach Rechnungsdatum absteigend sortiert (`InvDate DESC`), die neuesten zuerst.\n\nDie Anzahl der gelieferten Zeilen wird über `Rows` begrenzt (Standard 300). Ein leerer String für `InvoiceNr` wird wie `NULL` behandelt, ein `NULL`-Wert für `Rows` durch 300 ersetzt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Rows` | int | Nein | Maximale Anzahl der gelieferten Zeilen (über `SET ROWCOUNT`). `NULL` wird durch 300 ersetzt; `0` bedeutet keine Begrenzung. |\n| `InvoiceNr` | varchar(64) | Nein | Gesuchte Rechnungsnummer. Wenn gesetzt, werden nur Einträge zu dieser Rechnung geliefert und die Kundennotiz wird nicht geprüft. Ein leerer String wird wie `NULL` behandelt (Listenmodus). |\n\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`. Wird `Rows` = `0` übergeben, entfällt die Begrenzung und es werden **alle** passenden Zeilen geliefert, was bei großen Datenbanken langsam sein kann.\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; nicht festgeschriebene Daten können erscheinen.\n- Obwohl `LEFT JOIN`s verwendet werden, wirken diese durch die `WHERE`-Bedingungen auf die Rechnung (und im Listenmodus auf den Kunden) wie Inner Joins: Einträge ohne Rechnung werden nie geliefert.\n- `CHisNote != ''` schließt Kunden aus, deren Notiz `NULL` ist.\n- Hat ein Kundenkonto mehrere Einträge zur selben Rechnung, erscheint diese Rechnung mehrfach.\n- `Addresses` wird verknüpft, aber keine Spalte daraus geliefert.\n- Laut Kopfkommentar wurde der Aufruf für ein bestimmtes Kundenprojekt (Ticket PC-95) erstellt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiShowSpecialCommentCustomers"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kunden mit Kundenhistorien-Notiz (CHisNote) zusammen mit ihren Rechnungen, optional gefiltert nach einer Rechnungsnummer.\n\nLiest Kundenkonto-Einträge (`CustomerAccount`) und verknüpft sie mit Kunde, Rechnung und Rechnungswährung. Jede Ergebniszeile entspricht einem Kundenkonto-Eintrag.\n\nDer Aufruf arbeitet in zwei Modi:\n\n- **`InvoiceNr` angegeben**: liefert die Einträge, deren Rechnung genau diese Rechnungsnummer hat. Die Kundennotiz `CHisNote` wird in diesem Modus **nicht** geprüft, daher werden auch Kunden ohne Notiz geliefert. Es gibt keine Sortierung.\n- **`InvoiceNr` leer oder weggelassen**: liefert alle Einträge, deren Kunde eine nicht leere `CHisNote` hat und deren Rechnung eine nicht leere Rechnungsnummer besitzt. Die Zeilen sind nach Rechnungsdatum absteigend sortiert (`InvDate DESC`), die neuesten zuerst.\n\nDie Anzahl der gelieferten Zeilen wird über `Rows` begrenzt (Standard 300). Ein leerer String für `InvoiceNr` wird wie `NULL` behandelt, ein `NULL`-Wert für `Rows` durch 300 ersetzt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Rows` | int | Nein | Maximale Anzahl der gelieferten Zeilen (über `SET ROWCOUNT`). `NULL` wird durch 300 ersetzt; `0` bedeutet keine Begrenzung. |\n| `InvoiceNr` | varchar(64) | Nein | Gesuchte Rechnungsnummer. Wenn gesetzt, werden nur Einträge zu dieser Rechnung geliefert und die Kundennotiz wird nicht geprüft. Ein leerer String wird wie `NULL` behandelt (Listenmodus). |\n\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`. Wird `Rows` = `0` übergeben, entfällt die Begrenzung und es werden **alle** passenden Zeilen geliefert, was bei großen Datenbanken langsam sein kann.\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; nicht festgeschriebene Daten können erscheinen.\n- Obwohl `LEFT JOIN`s verwendet werden, wirken diese durch die `WHERE`-Bedingungen auf die Rechnung (und im Listenmodus auf den Kunden) wie Inner Joins: Einträge ohne Rechnung werden nie geliefert.\n- `CHisNote != ''` schließt Kunden aus, deren Notiz `NULL` ist.\n- Hat ein Kundenkonto mehrere Einträge zur selben Rechnung, erscheint diese Rechnung mehrfach.\n- `Addresses` wird verknüpft, aber keine Spalte daraus geliefert.\n- Laut Kopfkommentar wurde der Aufruf für ein bestimmtes Kundenprojekt (Ticket PC-95) erstellt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiShowSpecialCommentCustomers"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Müller GmbH\n z. Hd. Frau Schmidt\n 80331\n München\n Nur Vorkasse\n RE2024-004711\n 249.90\n 2024-05-14T10:23:00\n 10234\n EUR\n \n"
}
]
},
{
"name": "pixiUpdateCustomer",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 12345\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert E-Mail, Name und Postanschrift eines bestehenden Kunden und seiner verknüpften Adresse und sichert die bisherige Adresse in der Adresshistorie.\n\nAktualisiert einen über `CustKey` identifizierten Kunden zusammen mit der über `Customers.AddrRef` verknüpften Adresse.\n\n1. Alle Textparameter werden getrimmt. Leere Zeichenketten werden als `NULL` behandelt.\n2. Der Kunde wird über `CustKey` gesucht und mit seiner Adresse verknüpft. Der Kunde muss eine verknüpfte Adresse haben.\n - Kein Treffer: Status `404`.\n - Mehr als ein Treffer: Status `409`.\n3. Wird genau ein Kunde gefunden, laufen die folgenden Schritte in einer Transaktion:\n - Die aktuelle Adresse wird in die Adresshistorie kopiert. `HUpdateEmp` wird auf `API` und `HNoteHist` auf `Duplicate Check App` gesetzt.\n - Die E-Mail des Kunden (`Customers.CeMail`) wird auf `eMail` gesetzt. Das geschieht **immer**, auch wenn `eMail` `NULL` ist.\n - Die Adresse wird aktualisiert. Nur Parameter ungleich `NULL` ändern den gespeicherten Wert:\n - `FirstName`, `LastName`, `Street`, `HouseNr`, `City`, `ZIP` und `eMail` werden einzeln aktualisiert.\n - `Name` wird aus Vorname + Leerzeichen + Nachname neu gebildet.\n - `Address` wird aus Straße + Leerzeichen + Hausnummer neu gebildet.\n - Der Aufruf liefert Status `200`.\n4. Bei einem SQL-Fehler wird die Transaktion zurückgerollt. Der Aufruf liefert dann Status `500` mit dem SQL-Fehlertext.\n\nDer Aufruf liefert immer genau eine Statuszeile mit `StatusCode` und `ErrorMsg`. `ErrorMsg` enthält auch die Erfolgsmeldung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Ja | Schlüssel des zu aktualisierenden Kunden. |\n| `Street` | varchar(255) | Nein | Neue Straße. Wird getrimmt; leer oder `NULL` behält die gespeicherte Straße. Wird auch zum Neubilden von `Address` verwendet. |\n| `HouseNr` | varchar(10) | Nein | Neue Hausnummer. Wird getrimmt; leer oder `NULL` behält den gespeicherten Wert. Wird auch zum Neubilden von `Address` verwendet. |\n| `City` | varchar(60) | Nein | Neuer Ort. Wird getrimmt; leer oder `NULL` behält den gespeicherten Ort. |\n| `Zip` | varchar(10) | Nein | Neue Postleitzahl. Wird getrimmt; leer oder `NULL` behält den gespeicherten Wert. |\n| `eMail` | varchar(256) | Nein | Neue E-Mail-Adresse. Wird getrimmt. Wird immer in `Customers.CeMail` geschrieben, `NULL` oder leer leert den Wert dort. In `Addresses.eMail` nur, wenn nicht `NULL`. |\n| `FirstName` | varchar(60) | Nein | Neuer Vorname. Wird getrimmt; leer oder `NULL` behält den gespeicherten Wert. Wird auch zum Neubilden von `Name` verwendet. |\n| `LastName` | varchar(60) | Nein | Neuer Nachname. Wird getrimmt; leer oder `NULL` behält den gespeicherten Wert. Wird auch zum Neubilden von `Name` verwendet. |\n\n- **Stolperfalle – Kunden-E-Mail wird geleert:** `Customers.CeMail` wird ohne `NULL`-Prüfung mit `eMail` überschrieben. Wird `eMail` weggelassen oder leer übergeben, wird die E-Mail des Kunden geleert. Nur die Adress-E-Mail (`Addresses.eMail`) behält ihren alten Wert. Soll die E-Mail unverändert bleiben, muss immer die aktuelle E-Mail übergeben werden.\n- **Stolperfalle – neu gebildete Felder:** `Name` und `Address` werden immer aus Vor-/Nachname bzw. Straße/Hausnummer neu gebildet. Dabei werden die Parameter verwendet, oder die gespeicherten Spaltenwerte, wenn ein Parameter `NULL` ist. Ist einer der beiden Teile sowohl im Parameter als auch in der gespeicherten Spalte `NULL`, ergibt sich in der Regel `NULL` (Standardverhalten von `CONCAT_NULL_YIELDS_NULL`). Manuell gepflegte Werte in `Name` oder `Address` werden überschrieben.\n- **Nicht in der Historie:** Der Historieneintrag speichert nur die klassischen Adressfelder (z. B. `Name`, `Address`, `City`, `ZIP`). `FirstName`, `LastName`, `Street`, `HouseNr` und `eMail` werden dort nicht gesichert.\n- **Context-Info:** Während der Adressaktualisierung wird `CONTEXT_INFO` der Sitzung auf `0x33999` gesetzt und danach auf `0x00000` zurückgesetzt. Der Zweck ist im Code nicht ersichtlich; vermutlich wird der Wert von Triggern auf `Addresses` ausgewertet.\n- **Sperren:** Die Suche liest mit `NOLOCK`. Die Updates verwenden `ROWLOCK` innerhalb der benannten Transaktion `UpdateCustomer`.\n- **Fehlerbehandlung:** Der CATCH-Block führt immer `ROLLBACK TRANSACTION` aus. Tritt ein Fehler auf, bevor die Transaktion gestartet wurde, kann dieser Rollback einen zusätzlichen SQL-Fehler auslösen. Dieser kommt als `SqlMessage` neben der Statuszeile `500` zurück.\n- **Aufräumen:** Die temporäre Tabelle wird über `util.TempTableDrop` gelöscht. Die Definition dieses Objekts liegt nicht vor.\n- **NULL-Schlüssel:** Ist `CustKey` `NULL`, wird Status `404` geliefert und `ErrorMsg` ist `NULL`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateCustomer"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 12345\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert E-Mail, Name und Postanschrift eines bestehenden Kunden und seiner verknüpften Adresse und sichert die bisherige Adresse in der Adresshistorie.\n\nAktualisiert einen über `CustKey` identifizierten Kunden zusammen mit der über `Customers.AddrRef` verknüpften Adresse.\n\n1. Alle Textparameter werden getrimmt. Leere Zeichenketten werden als `NULL` behandelt.\n2. Der Kunde wird über `CustKey` gesucht und mit seiner Adresse verknüpft. Der Kunde muss eine verknüpfte Adresse haben.\n - Kein Treffer: Status `404`.\n - Mehr als ein Treffer: Status `409`.\n3. Wird genau ein Kunde gefunden, laufen die folgenden Schritte in einer Transaktion:\n - Die aktuelle Adresse wird in die Adresshistorie kopiert. `HUpdateEmp` wird auf `API` und `HNoteHist` auf `Duplicate Check App` gesetzt.\n - Die E-Mail des Kunden (`Customers.CeMail`) wird auf `eMail` gesetzt. Das geschieht **immer**, auch wenn `eMail` `NULL` ist.\n - Die Adresse wird aktualisiert. Nur Parameter ungleich `NULL` ändern den gespeicherten Wert:\n - `FirstName`, `LastName`, `Street`, `HouseNr`, `City`, `ZIP` und `eMail` werden einzeln aktualisiert.\n - `Name` wird aus Vorname + Leerzeichen + Nachname neu gebildet.\n - `Address` wird aus Straße + Leerzeichen + Hausnummer neu gebildet.\n - Der Aufruf liefert Status `200`.\n4. Bei einem SQL-Fehler wird die Transaktion zurückgerollt. Der Aufruf liefert dann Status `500` mit dem SQL-Fehlertext.\n\nDer Aufruf liefert immer genau eine Statuszeile mit `StatusCode` und `ErrorMsg`. `ErrorMsg` enthält auch die Erfolgsmeldung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Ja | Schlüssel des zu aktualisierenden Kunden. |\n| `Street` | varchar(255) | Nein | Neue Straße. Wird getrimmt; leer oder `NULL` behält die gespeicherte Straße. Wird auch zum Neubilden von `Address` verwendet. |\n| `HouseNr` | varchar(10) | Nein | Neue Hausnummer. Wird getrimmt; leer oder `NULL` behält den gespeicherten Wert. Wird auch zum Neubilden von `Address` verwendet. |\n| `City` | varchar(60) | Nein | Neuer Ort. Wird getrimmt; leer oder `NULL` behält den gespeicherten Ort. |\n| `Zip` | varchar(10) | Nein | Neue Postleitzahl. Wird getrimmt; leer oder `NULL` behält den gespeicherten Wert. |\n| `eMail` | varchar(256) | Nein | Neue E-Mail-Adresse. Wird getrimmt. Wird immer in `Customers.CeMail` geschrieben, `NULL` oder leer leert den Wert dort. In `Addresses.eMail` nur, wenn nicht `NULL`. |\n| `FirstName` | varchar(60) | Nein | Neuer Vorname. Wird getrimmt; leer oder `NULL` behält den gespeicherten Wert. Wird auch zum Neubilden von `Name` verwendet. |\n| `LastName` | varchar(60) | Nein | Neuer Nachname. Wird getrimmt; leer oder `NULL` behält den gespeicherten Wert. Wird auch zum Neubilden von `Name` verwendet. |\n\n- **Stolperfalle – Kunden-E-Mail wird geleert:** `Customers.CeMail` wird ohne `NULL`-Prüfung mit `eMail` überschrieben. Wird `eMail` weggelassen oder leer übergeben, wird die E-Mail des Kunden geleert. Nur die Adress-E-Mail (`Addresses.eMail`) behält ihren alten Wert. Soll die E-Mail unverändert bleiben, muss immer die aktuelle E-Mail übergeben werden.\n- **Stolperfalle – neu gebildete Felder:** `Name` und `Address` werden immer aus Vor-/Nachname bzw. Straße/Hausnummer neu gebildet. Dabei werden die Parameter verwendet, oder die gespeicherten Spaltenwerte, wenn ein Parameter `NULL` ist. Ist einer der beiden Teile sowohl im Parameter als auch in der gespeicherten Spalte `NULL`, ergibt sich in der Regel `NULL` (Standardverhalten von `CONCAT_NULL_YIELDS_NULL`). Manuell gepflegte Werte in `Name` oder `Address` werden überschrieben.\n- **Nicht in der Historie:** Der Historieneintrag speichert nur die klassischen Adressfelder (z. B. `Name`, `Address`, `City`, `ZIP`). `FirstName`, `LastName`, `Street`, `HouseNr` und `eMail` werden dort nicht gesichert.\n- **Context-Info:** Während der Adressaktualisierung wird `CONTEXT_INFO` der Sitzung auf `0x33999` gesetzt und danach auf `0x00000` zurückgesetzt. Der Zweck ist im Code nicht ersichtlich; vermutlich wird der Wert von Triggern auf `Addresses` ausgewertet.\n- **Sperren:** Die Suche liest mit `NOLOCK`. Die Updates verwenden `ROWLOCK` innerhalb der benannten Transaktion `UpdateCustomer`.\n- **Fehlerbehandlung:** Der CATCH-Block führt immer `ROLLBACK TRANSACTION` aus. Tritt ein Fehler auf, bevor die Transaktion gestartet wurde, kann dieser Rollback einen zusätzlichen SQL-Fehler auslösen. Dieser kommt als `SqlMessage` neben der Statuszeile `500` zurück.\n- **Aufräumen:** Die temporäre Tabelle wird über `util.TempTableDrop` gelöscht. Die Definition dieses Objekts liegt nicht vor.\n- **NULL-Schlüssel:** Ist `CustKey` `NULL`, wird Status `404` geliefert und `ErrorMsg` ist `NULL`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateCustomer"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 200\n Customer with CustKey: 12345 was updated.\n \n"
}
]
},
{
"name": "pixiWebLogin",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n max.mustermann@example.com\n 80331\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Kundenschlüssel (`CustKey`) eines Kunden, dessen Rechnungs- oder Lieferadresse zur angegebenen E-Mail/Kundennummer und PLZ passt.\n\nEinfache Web-Login-Prüfung: ermittelt einen Kunden anhand einer E-Mail-Adresse (oder externen Kundennummer) in Kombination mit einer PLZ und liefert dessen `CustKey`.\n\nAblauf des Abgleichs:\n\n- `Email` und `ZIP` müssen jeweils mindestens 4 Zeichen lang sein (`LEN`), andernfalls wird kein Kunde gefunden.\n- Die **Rechnungsadresse** (`Customers.AddrRef`) und die **Lieferadresse** (`Customers.ShipRef`) des Kunden werden getrennt geprüft. Ein Kunde passt, wenn *eine* der beiden Adressen beide Bedingungen erfüllt:\n - `Email` passt zum Adressfeld `CustomerNrExternal` **oder** `eMail`.\n - `ZIP` passt zum Adressfeld `ZIP`.\n- Jeder Vergleich ist ein Teilstring-Abgleich in beide Richtungen: Die Eingabe enthält den gespeicherten Wert oder der gespeicherte Wert enthält die Eingabe (`LIKE '%…%'` in beide Richtungen).\n- Der erste passende Kunde (`TOP 1`) wird zurückgegeben. Es gibt kein `ORDER BY`; bei mehreren Treffern ist der gelieferte Kunde daher nicht deterministisch.\n\nWird kein Kunde gefunden, liefert die Funktion `NULL`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Email` | varchar(60) | Ja | E-Mail-Adresse oder externe Kundennummer (`CustomerNrExternal`) des Kunden. Muss mindestens 4 Zeichen lang sein. |\n| `ZIP` | varchar(10) | Ja | PLZ der Rechnungs- oder Lieferadresse des Kunden. Muss mindestens 4 Zeichen lang sein. |\n\n- **Keine sichere Authentifizierung.** Es gibt kein Passwort; die Kenntnis von E-Mail (oder Kundennummer) und PLZ genügt. Nur als einfache Identifikation verwenden.\n- **Falle bei leeren gespeicherten Werten:** Durch den umgekehrten Abgleich (Eingabe `LIKE '%' + gespeicherter Wert + '%'`) passt eine Adresse, deren `eMail`, `CustomerNrExternal` oder `ZIP` ein Leerstring ist, auf *jede* ausreichend lange Eingabe. Gespeicherte `NULL`-Werte passen nicht.\n- Der Teilstring-Abgleich ist unscharf: z. B. passt `ZIP` `1234` auch auf eine gespeicherte `12345`. Platzhalterzeichen in der Eingabe (`%`, `_`, `[`) werden von `LIKE` ausgewertet.\n- `LEN` ignoriert nachgestellte Leerzeichen; diese zählen nicht zur Mindestlänge von 4.\n- Die Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können geliefert werden.\n- Der Abgleich mit führendem Platzhalter kann keine Indizes nutzen und ist bei großen Kundentabellen ggf. langsam.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiWebLogin"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n max.mustermann@example.com\n 80331\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Kundenschlüssel (`CustKey`) eines Kunden, dessen Rechnungs- oder Lieferadresse zur angegebenen E-Mail/Kundennummer und PLZ passt.\n\nEinfache Web-Login-Prüfung: ermittelt einen Kunden anhand einer E-Mail-Adresse (oder externen Kundennummer) in Kombination mit einer PLZ und liefert dessen `CustKey`.\n\nAblauf des Abgleichs:\n\n- `Email` und `ZIP` müssen jeweils mindestens 4 Zeichen lang sein (`LEN`), andernfalls wird kein Kunde gefunden.\n- Die **Rechnungsadresse** (`Customers.AddrRef`) und die **Lieferadresse** (`Customers.ShipRef`) des Kunden werden getrennt geprüft. Ein Kunde passt, wenn *eine* der beiden Adressen beide Bedingungen erfüllt:\n - `Email` passt zum Adressfeld `CustomerNrExternal` **oder** `eMail`.\n - `ZIP` passt zum Adressfeld `ZIP`.\n- Jeder Vergleich ist ein Teilstring-Abgleich in beide Richtungen: Die Eingabe enthält den gespeicherten Wert oder der gespeicherte Wert enthält die Eingabe (`LIKE '%…%'` in beide Richtungen).\n- Der erste passende Kunde (`TOP 1`) wird zurückgegeben. Es gibt kein `ORDER BY`; bei mehreren Treffern ist der gelieferte Kunde daher nicht deterministisch.\n\nWird kein Kunde gefunden, liefert die Funktion `NULL`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Email` | varchar(60) | Ja | E-Mail-Adresse oder externe Kundennummer (`CustomerNrExternal`) des Kunden. Muss mindestens 4 Zeichen lang sein. |\n| `ZIP` | varchar(10) | Ja | PLZ der Rechnungs- oder Lieferadresse des Kunden. Muss mindestens 4 Zeichen lang sein. |\n\n- **Keine sichere Authentifizierung.** Es gibt kein Passwort; die Kenntnis von E-Mail (oder Kundennummer) und PLZ genügt. Nur als einfache Identifikation verwenden.\n- **Falle bei leeren gespeicherten Werten:** Durch den umgekehrten Abgleich (Eingabe `LIKE '%' + gespeicherter Wert + '%'`) passt eine Adresse, deren `eMail`, `CustomerNrExternal` oder `ZIP` ein Leerstring ist, auf *jede* ausreichend lange Eingabe. Gespeicherte `NULL`-Werte passen nicht.\n- Der Teilstring-Abgleich ist unscharf: z. B. passt `ZIP` `1234` auch auf eine gespeicherte `12345`. Platzhalterzeichen in der Eingabe (`%`, `_`, `[`) werden von `LIKE` ausgewertet.\n- `LEN` ignoriert nachgestellte Leerzeichen; diese zählen nicht zur Mindestlänge von 4.\n- Die Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können geliefert werden.\n- Der Abgleich mit führendem Platzhalter kann keine Indizes nutzen und ist bei großen Kundentabellen ggf. langsam.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiWebLogin"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4711\n \n"
}
]
}
]
},
{
"name": "Customs",
"item": [
{
"name": "pixiGetItemCustomsInfo",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Zolldaten (Zolltarifnummer, Ursprungsland, Gewicht, Maße) eines Artikels, ermittelt über ItemKey, interne Artikelnummer oder EAN/UPC.\n\nLiefert die zollrelevanten Stammdaten eines einzelnen Artikels aus den Artikelstammdaten.\n\n1. Wird keiner der Parameter `ItemKey`, `ItemNrInt` und `EanUpc` übergeben, wird eine Statuszeile zurückgegeben. Alle Datenspalten sind `NULL`, `ResultCode` ist `501`, und der Aufruf endet.\n2. Ist `ItemKey` `NULL` oder `0`, wird der Artikelschlüssel über `ItemNrInt` (interne Artikelnummer) ermittelt.\n3. Wurde danach noch kein Artikelschlüssel gefunden, erfolgt die Suche über `EanUpc`.\n4. Der Artikel mit dem ermittelten Schlüssel wird zurückgegeben. Das Ursprungsland `CustomsCountryOfOrigin` wird mit der Ländertabelle verknüpft, um zusätzlich den ISO2-Code zu liefern. Bei Erfolg ist `ResultCode` `200` und `ResultMessage` `OK`.\n\nVorrang der Kennungen: zuerst `ItemKey`, dann `ItemNrInt`, dann `EanUpc`. Existiert kein passender Artikel, ist die Ergebnismenge leer; eine Fehlerzeile wird nicht geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. Hat Vorrang vor den anderen Kennungen. `NULL` oder `0` bedeutet, dass der Artikel über `ItemNrInt` bzw. `EanUpc` gesucht wird. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer. Wird nur verwendet, wenn `ItemKey` nicht übergeben wird. |\n| `EanUpc` | varchar(50) | Nein | EAN/UPC des Artikels. Wird nur verwendet, wenn über `ItemKey` bzw. `ItemNrInt` kein Artikel gefunden wurde. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; es können daher nicht festgeschriebene Daten geliefert werden.\n- Wird ein von 0 verschiedener, aber nicht existierender `ItemKey` übergeben, werden `ItemNrInt` und `EanUpc` **nicht** ersatzweise verwendet. Das Ergebnis ist dann einfach leer.\n- Die Suche über `ItemNrInt` bzw. `EanUpc` verwendet `TOP 1` ohne `ORDER BY`. Teilen sich mehrere Artikel dieselbe EAN, ist nicht festgelegt, welcher Artikel geliefert wird.\n- Wird nur `ItemKey = 0` übergeben, ist die Parameterprüfung bestanden, die Ergebnismenge bleibt aber leer.\n- Der Spaltenname `Heigth` ist im Quellcode falsch geschrieben und muss genau so ausgelesen werden.\n- `CustomsCountryOfOriginISO2` ist `NULL`, wenn der Ländercode nicht in der Ländertabelle gefunden wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemCustomsInfo"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Zolldaten (Zolltarifnummer, Ursprungsland, Gewicht, Maße) eines Artikels, ermittelt über ItemKey, interne Artikelnummer oder EAN/UPC.\n\nLiefert die zollrelevanten Stammdaten eines einzelnen Artikels aus den Artikelstammdaten.\n\n1. Wird keiner der Parameter `ItemKey`, `ItemNrInt` und `EanUpc` übergeben, wird eine Statuszeile zurückgegeben. Alle Datenspalten sind `NULL`, `ResultCode` ist `501`, und der Aufruf endet.\n2. Ist `ItemKey` `NULL` oder `0`, wird der Artikelschlüssel über `ItemNrInt` (interne Artikelnummer) ermittelt.\n3. Wurde danach noch kein Artikelschlüssel gefunden, erfolgt die Suche über `EanUpc`.\n4. Der Artikel mit dem ermittelten Schlüssel wird zurückgegeben. Das Ursprungsland `CustomsCountryOfOrigin` wird mit der Ländertabelle verknüpft, um zusätzlich den ISO2-Code zu liefern. Bei Erfolg ist `ResultCode` `200` und `ResultMessage` `OK`.\n\nVorrang der Kennungen: zuerst `ItemKey`, dann `ItemNrInt`, dann `EanUpc`. Existiert kein passender Artikel, ist die Ergebnismenge leer; eine Fehlerzeile wird nicht geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. Hat Vorrang vor den anderen Kennungen. `NULL` oder `0` bedeutet, dass der Artikel über `ItemNrInt` bzw. `EanUpc` gesucht wird. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer. Wird nur verwendet, wenn `ItemKey` nicht übergeben wird. |\n| `EanUpc` | varchar(50) | Nein | EAN/UPC des Artikels. Wird nur verwendet, wenn über `ItemKey` bzw. `ItemNrInt` kein Artikel gefunden wurde. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; es können daher nicht festgeschriebene Daten geliefert werden.\n- Wird ein von 0 verschiedener, aber nicht existierender `ItemKey` übergeben, werden `ItemNrInt` und `EanUpc` **nicht** ersatzweise verwendet. Das Ergebnis ist dann einfach leer.\n- Die Suche über `ItemNrInt` bzw. `EanUpc` verwendet `TOP 1` ohne `ORDER BY`. Teilen sich mehrere Artikel dieselbe EAN, ist nicht festgelegt, welcher Artikel geliefert wird.\n- Wird nur `ItemKey = 0` übergeben, ist die Parameterprüfung bestanden, die Ergebnismenge bleibt aber leer.\n- Der Spaltenname `Heigth` ist im Quellcode falsch geschrieben und muss genau so ausgelesen werden.\n- `CustomsCountryOfOriginISO2` ist `NULL`, wenn der Ländercode nicht in der Ländertabelle gefunden wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemCustomsInfo"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4711\n 85176200\n CN\n CN\n 0.350\n 5.00\n 15.00\n 20.00\n Network router\n 00\n 200\n OK\n \n"
}
]
},
{
"name": "pixiReportItemsWithMissingCustomsInfo",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, die noch nicht mit dem System-Tag `AtlasData` markiert sind, inklusive Stammdaten und Zollfeldern, seitenweise nach `ItemKey`.\n\nListet Artikel auf, deren Zollinformationen noch nicht als vollständig markiert sind.\n\n1. Die ID des System-Tags `AtlasData` (Tag-Typ `1`, `IsSystemTag = 1`) wird aus `Tag` ermittelt.\n2. Es werden alle Artikel gewählt, denen dieser Tag in `TagMatch` **nicht** zugeordnet ist.\n3. Nur Artikel mit `ItemKey` größer als `ItemKeyStart` werden geliefert.\n4. Das Ergebnis ist aufsteigend nach `ItemKey` sortiert und auf `Rowcount` Zeilen begrenzt.\n\nJe Artikel werden Stammdaten (Name, Lieferant, Nummern, EAN, Verkaufspreis, MwSt-Stufe, Gewicht und Abmessungen), alle zugeordneten Artikel-Tags als durch `|` getrennte Zeichenkette, die ABC-Klassifizierung sowie die aktuellen Zollfelder (Zolltarifnummer, Ursprungsland mit ISO2-Code, Zolltariftext, vorheriges Verfahren) geliefert.\n\n**Paging:** Den höchsten `ItemKey` der vorherigen Seite als `ItemKeyStart` übergeben, um die nächste Seite zu erhalten. Mit `0` beginnen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Rowcount` | int | Nein | Maximale Anzahl gelieferter Zeilen (Seitengröße). `0` bedeutet keine Begrenzung. |\n| `ItemKeyStart` | int | Nein | Nur Artikel mit `ItemKey` größer als dieser Wert werden geliefert. Für Paging den letzten `ItemKey` der vorherigen Seite übergeben. |\n\n- \"Fehlende Zollinformationen\" ist ausschließlich über das Fehlen des Tags `AtlasData` definiert. Die Zollspalten gelieferter Artikel können bereits gefüllt sein; Artikel mit leeren Zollfeldern, die den Tag tragen, werden nicht geliefert.\n- Existiert der System-Tag `AtlasData` nicht, ist die Tag-ID `NULL`, die `NOT EXISTS`-Prüfung greift nie und es werden **alle** Artikel (oberhalb von `ItemKeyStart`) geliefert.\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`; `Rowcount = 0` hebt die Begrenzung auf.\n- Inaktive Artikel sind enthalten; siehe Spalte `Enabled`.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, nicht festgeschriebene Daten können erscheinen.\n- `ItemTAGs` und `ABC` werden je Zeile über Skalarfunktionen berechnet, was bei großen Seiten langsam sein kann.\n- Die Spalte `Heigth` ist so geschrieben wie in der Datenbank.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportItemsWithMissingCustomsInfo"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, die noch nicht mit dem System-Tag `AtlasData` markiert sind, inklusive Stammdaten und Zollfeldern, seitenweise nach `ItemKey`.\n\nListet Artikel auf, deren Zollinformationen noch nicht als vollständig markiert sind.\n\n1. Die ID des System-Tags `AtlasData` (Tag-Typ `1`, `IsSystemTag = 1`) wird aus `Tag` ermittelt.\n2. Es werden alle Artikel gewählt, denen dieser Tag in `TagMatch` **nicht** zugeordnet ist.\n3. Nur Artikel mit `ItemKey` größer als `ItemKeyStart` werden geliefert.\n4. Das Ergebnis ist aufsteigend nach `ItemKey` sortiert und auf `Rowcount` Zeilen begrenzt.\n\nJe Artikel werden Stammdaten (Name, Lieferant, Nummern, EAN, Verkaufspreis, MwSt-Stufe, Gewicht und Abmessungen), alle zugeordneten Artikel-Tags als durch `|` getrennte Zeichenkette, die ABC-Klassifizierung sowie die aktuellen Zollfelder (Zolltarifnummer, Ursprungsland mit ISO2-Code, Zolltariftext, vorheriges Verfahren) geliefert.\n\n**Paging:** Den höchsten `ItemKey` der vorherigen Seite als `ItemKeyStart` übergeben, um die nächste Seite zu erhalten. Mit `0` beginnen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Rowcount` | int | Nein | Maximale Anzahl gelieferter Zeilen (Seitengröße). `0` bedeutet keine Begrenzung. |\n| `ItemKeyStart` | int | Nein | Nur Artikel mit `ItemKey` größer als dieser Wert werden geliefert. Für Paging den letzten `ItemKey` der vorherigen Seite übergeben. |\n\n- \"Fehlende Zollinformationen\" ist ausschließlich über das Fehlen des Tags `AtlasData` definiert. Die Zollspalten gelieferter Artikel können bereits gefüllt sein; Artikel mit leeren Zollfeldern, die den Tag tragen, werden nicht geliefert.\n- Existiert der System-Tag `AtlasData` nicht, ist die Tag-ID `NULL`, die `NOT EXISTS`-Prüfung greift nie und es werden **alle** Artikel (oberhalb von `ItemKeyStart`) geliefert.\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`; `Rowcount = 0` hebt die Begrenzung auf.\n- Inaktive Artikel sind enthalten; siehe Spalte `Enabled`.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, nicht festgeschriebene Daten können erscheinen.\n- `ItemTAGs` und `ABC` werden je Zeile über Skalarfunktionen berechnet, was bei großen Seiten langsam sein kann.\n- Die Spalte `Heigth` ist so geschrieben wie in der Datenbank.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportItemsWithMissingCustomsInfo"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1042\n Steel Water Bottle 750ml\n 17\n WB-750-BLK\n 4006381333931\n SUP-88213\n 19.9900\n MwSt_High\n 1\n A|Outdoor\n 0.35\n 26\n 7\n 7\n A\n 73239300\n CN\n CN\n Haushaltsartikel aus nichtrostendem Stahl\n \n \n"
}
]
},
{
"name": "pixiSetItemCustomsInfo",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 12345\n ShopSync\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert die Zolldaten (Zolltarifnummer, Ursprungsland, Zolltariftext, Vorverfahren) sowie Gewicht und Abmessungen eines Artikels.\n\nAktualisiert die zollrelevanten Felder und die Abmessungen eines Artikels, der über `ItemKey` bestimmt wird.\n\n1. Wird `CustomsCountryOfOriginISO2` übergeben und ist der Wert nicht leer, wird der zweistellige ISO-Code in der Ländertabelle gesucht. Der dort gefundene Pixi-Ländercode (`CntCode`) ersetzt den Wert von `CustomsCountryOfOrigin`.\n2. Der Artikel wird aktualisiert. Nur Parameter, die nicht `NULL` sind, überschreiben den gespeicherten Wert. Ein weggelassener oder als `NULL` übergebener Parameter behält den aktuellen Wert.\n3. Die Aktualisierung erfolgt nur, wenn mindestens ein übergebener Wert vom gespeicherten Wert abweicht oder ein gespeicherter Wert `NULL` ist und ein Wert übergeben wird.\n4. Bei einer Aktualisierung wird `UpdateEmp` auf ` (API)` und `UpdateDate` auf das aktuelle Datum mit Uhrzeit gesetzt.\n\nDer Aufruf liefert eine Statuszeile:\n- `200` / `OK`: Der Artikel wurde geändert.\n- `200` / `Accepted - no changes needed`: Der Artikel existiert, alle übergebenen Werte entsprechen aber bereits den gespeicherten Werten.\n- `401` / `Not found`: Es existiert kein Artikel mit diesem `ItemKey`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Ja | Interner Schlüssel des zu aktualisierenden Artikels. |\n| `UserName` | varchar(50) | Ja | Name des Benutzers oder Systems, das die Änderung vornimmt. Der Wert wird mit dem Zusatz ` (API)` in `UpdateEmp` gespeichert. |\n| `CustomsTariffNumber` | varchar(50) | Nein | Zolltarifnummer (HS-Code). `NULL` behält den aktuellen Wert. |\n| `CustomsCountryOfOrigin` | varchar(3) | Nein | Pixi-Ländercode des Ursprungslands. Der Wert wird überschrieben, wenn `CustomsCountryOfOriginISO2` einem Land zugeordnet werden kann. `NULL` behält den aktuellen Wert. |\n| `CustomsCountryOfOriginISO2` | varchar(2) | Nein | ISO-3166-1-Alpha-2-Code des Ursprungslands. Ist der Wert nicht leer, wird er in den Pixi-Ländercode umgesetzt und hat Vorrang vor `CustomsCountryOfOrigin`. |\n| `Weight` | numeric | Nein | Gewicht des Artikels. Nachkommastellen gehen verloren, da der Parameter `numeric(18,0)` ist. `NULL` behält den aktuellen Wert. |\n| `Heigth` | numeric | Nein | Höhe des Artikels (Schreibweise `Heigth`). Nachkommastellen gehen verloren. `NULL` behält den aktuellen Wert. |\n| `Width` | numeric | Nein | Breite des Artikels. Nachkommastellen gehen verloren. `NULL` behält den aktuellen Wert. |\n| `Length` | numeric | Nein | Länge des Artikels. Nachkommastellen gehen verloren. `NULL` behält den aktuellen Wert. |\n| `CustomsTariffText` | varchar(max) | Nein | Warenbeschreibung für Zollzwecke. `NULL` behält den aktuellen Wert. |\n| `CustomsPreviousProcess` | varchar(10) | Nein | Code des zollrechtlichen Vorverfahrens. `NULL` behält den aktuellen Wert. |\n\n- `Weight`, `Heigth`, `Width` und `Length` sind als einfaches `NUMERIC` deklariert. Ohne Angabe von Genauigkeit und Nachkommastellen entspricht das `numeric(18,0)`, daher werden Nachkommastellen vor dem Speichern weggerundet. Es sollten ganze Zahlen in der Einheit übergeben werden, die Pixi für diese Felder verwendet.\n- Der Parameter für die Höhe heißt `Heigth`, ebenso wie die Spalte.\n- Ein Feld kann mit diesem Aufruf nicht auf `NULL` zurückgesetzt werden, da `NULL` \"aktuellen Wert beibehalten\" bedeutet. Ein Leerstring wird dagegen als Leerstring gespeichert.\n- Findet sich zu `CustomsCountryOfOriginISO2` kein Land, weist die Suche nichts zu. Dann wird der in `CustomsCountryOfOrigin` übergebene Wert verwendet. Ist auch dieser `NULL`, bleibt der gespeicherte Wert erhalten. Ein Fehler wird nicht gemeldet.\n- Für einen nicht vorhandenen Artikel liefert der Code `401`, nicht `404`.\n- Die Aktualisierung verwendet `ROWLOCK`. Die Ländersuche und die Existenzprüfung lesen mit `NOLOCK`.\n- Ändert sich nichts, bleiben `UpdateEmp` und `UpdateDate` unverändert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemCustomsInfo"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 12345\n ShopSync\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert die Zolldaten (Zolltarifnummer, Ursprungsland, Zolltariftext, Vorverfahren) sowie Gewicht und Abmessungen eines Artikels.\n\nAktualisiert die zollrelevanten Felder und die Abmessungen eines Artikels, der über `ItemKey` bestimmt wird.\n\n1. Wird `CustomsCountryOfOriginISO2` übergeben und ist der Wert nicht leer, wird der zweistellige ISO-Code in der Ländertabelle gesucht. Der dort gefundene Pixi-Ländercode (`CntCode`) ersetzt den Wert von `CustomsCountryOfOrigin`.\n2. Der Artikel wird aktualisiert. Nur Parameter, die nicht `NULL` sind, überschreiben den gespeicherten Wert. Ein weggelassener oder als `NULL` übergebener Parameter behält den aktuellen Wert.\n3. Die Aktualisierung erfolgt nur, wenn mindestens ein übergebener Wert vom gespeicherten Wert abweicht oder ein gespeicherter Wert `NULL` ist und ein Wert übergeben wird.\n4. Bei einer Aktualisierung wird `UpdateEmp` auf ` (API)` und `UpdateDate` auf das aktuelle Datum mit Uhrzeit gesetzt.\n\nDer Aufruf liefert eine Statuszeile:\n- `200` / `OK`: Der Artikel wurde geändert.\n- `200` / `Accepted - no changes needed`: Der Artikel existiert, alle übergebenen Werte entsprechen aber bereits den gespeicherten Werten.\n- `401` / `Not found`: Es existiert kein Artikel mit diesem `ItemKey`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Ja | Interner Schlüssel des zu aktualisierenden Artikels. |\n| `UserName` | varchar(50) | Ja | Name des Benutzers oder Systems, das die Änderung vornimmt. Der Wert wird mit dem Zusatz ` (API)` in `UpdateEmp` gespeichert. |\n| `CustomsTariffNumber` | varchar(50) | Nein | Zolltarifnummer (HS-Code). `NULL` behält den aktuellen Wert. |\n| `CustomsCountryOfOrigin` | varchar(3) | Nein | Pixi-Ländercode des Ursprungslands. Der Wert wird überschrieben, wenn `CustomsCountryOfOriginISO2` einem Land zugeordnet werden kann. `NULL` behält den aktuellen Wert. |\n| `CustomsCountryOfOriginISO2` | varchar(2) | Nein | ISO-3166-1-Alpha-2-Code des Ursprungslands. Ist der Wert nicht leer, wird er in den Pixi-Ländercode umgesetzt und hat Vorrang vor `CustomsCountryOfOrigin`. |\n| `Weight` | numeric | Nein | Gewicht des Artikels. Nachkommastellen gehen verloren, da der Parameter `numeric(18,0)` ist. `NULL` behält den aktuellen Wert. |\n| `Heigth` | numeric | Nein | Höhe des Artikels (Schreibweise `Heigth`). Nachkommastellen gehen verloren. `NULL` behält den aktuellen Wert. |\n| `Width` | numeric | Nein | Breite des Artikels. Nachkommastellen gehen verloren. `NULL` behält den aktuellen Wert. |\n| `Length` | numeric | Nein | Länge des Artikels. Nachkommastellen gehen verloren. `NULL` behält den aktuellen Wert. |\n| `CustomsTariffText` | varchar(max) | Nein | Warenbeschreibung für Zollzwecke. `NULL` behält den aktuellen Wert. |\n| `CustomsPreviousProcess` | varchar(10) | Nein | Code des zollrechtlichen Vorverfahrens. `NULL` behält den aktuellen Wert. |\n\n- `Weight`, `Heigth`, `Width` und `Length` sind als einfaches `NUMERIC` deklariert. Ohne Angabe von Genauigkeit und Nachkommastellen entspricht das `numeric(18,0)`, daher werden Nachkommastellen vor dem Speichern weggerundet. Es sollten ganze Zahlen in der Einheit übergeben werden, die Pixi für diese Felder verwendet.\n- Der Parameter für die Höhe heißt `Heigth`, ebenso wie die Spalte.\n- Ein Feld kann mit diesem Aufruf nicht auf `NULL` zurückgesetzt werden, da `NULL` \"aktuellen Wert beibehalten\" bedeutet. Ein Leerstring wird dagegen als Leerstring gespeichert.\n- Findet sich zu `CustomsCountryOfOriginISO2` kein Land, weist die Suche nichts zu. Dann wird der in `CustomsCountryOfOrigin` übergebene Wert verwendet. Ist auch dieser `NULL`, bleibt der gespeicherte Wert erhalten. Ein Fehler wird nicht gemeldet.\n- Für einen nicht vorhandenen Artikel liefert der Code `401`, nicht `404`.\n- Die Aktualisierung verwendet `ROWLOCK`. Die Ländersuche und die Existenzprüfung lesen mit `NOLOCK`.\n- Ändert sich nichts, bleiben `UpdateEmp` und `UpdateDate` unverändert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemCustomsInfo"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 200\n OK\n \n"
}
]
}
]
},
{
"name": "Direct-Fulfillment",
"item": [
{
"name": "pixiDFCreateInvoices",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt Direct-Fulfillment-Rechnungen (DF) für bereite Auftragspositionen an, optional eingeschränkt auf und ergänzt um Versanddienstleister und Tracking-Daten aus XML.\n\nDer Aufruf legt Rechnungen für Direct-Fulfillment-Aufträge an. Die eigentliche Verarbeitung übernimmt die interne Prozedur `Pixi_CreateFulfillmentIncoices`, die mit `CreateEmp = 'API'` läuft.\n\n**Ablauf**\n\n1. Ein exklusiver Application-Lock `pipiDFCreateInvoices` wird mit 5 Sekunden Timeout angefordert, damit parallele Läufe nacheinander ausgeführt werden.\n2. Ist `OrderlinesXML` gesetzt (ein Leerstring gilt als NULL), werden die Elemente `/Orderlines/Orderline` mit den Unterelementen `OrderlineKey`, `ShipVendor`, `ShipmentTrackingId` und `ReturnTrackingId` gelesen.\n3. Bei `ShowDetailedMessages = 1` wird die Eingabe zuerst geprüft:\n - Das XML muss vorhanden sein und mindestens ein `Orderline` enthalten.\n - Der Versanddienstleister-Code (aus der ersten Zeile je Auftrag) darf höchstens 3 Zeichen lang sein.\n - Alle Sendungs-Tracking-IDs eines Auftrags, mit `;` verbunden, dürfen höchstens 512 Zeichen lang sein. Dieselbe Grenze gilt für die Retouren-Tracking-IDs.\n - Jeder `OrderlineKey` muss in `Orderlines` existieren.\n \n Schlägt eine Prüfung fehl, werden alle Fehlerzeilen zurückgegeben und keine Rechnung angelegt.\n4. Die Rechnungen werden angelegt. Das Verhalten hängt von den Einstellungen `EnableFulfilmentTypeOne` und `EnableFulfilmentTypeTwo` ab:\n - **Typ eins:** Auftragspositionen aus dem XML mit Status `FUT` werden zuerst auf `FUS` gesetzt. Danach wird je Auftrag mit `FUS`-Positionen eine Rechnung erzeugt. Mit XML werden nur die übergebenen Positionen verwendet, ohne XML alle `FUS`-Positionen.\n - **Typ zwei:** Kandidaten sind Aufträge, deren Positionen alle `FUS` oder in einem Endstatus sind und die mindestens eine `FUS`-Position ohne Rechnung haben. Das XML schränkt die Kandidaten-Aufträge nicht ein. Es bestimmt nur, welche `FUS`-Positionen in die Rechnung übernommen werden. Positionen mit Status `MIN` werden immer übernommen.\n5. Jeder Auftrag wird in einer eigenen Transaktion verarbeitet:\n - Die Rechnung wird angelegt, mit `Fulfillment = 1` gekennzeichnet und mit Rechnungspositionen versehen.\n - Der Versanddienstleister aus dem XML ersetzt den des Auftrags.\n - Tracking-IDs aus dem XML werden an der Rechnung gespeichert. Mehrere IDs können mit `;` getrennt werden, und jede eindeutige ID wird ein eigenes Rechnungspaket.\n - Die Auftragspositionen werden auf `AUS` mit `InvRef` und `ShipDate` gesetzt.\n - Eine Rechnungsnummer wird vergeben, eine Buchung im Kundenkonto angelegt und die Rechnung ausgescannt.\n - Ein Event `InvoiceCreated` wird veröffentlicht.\n6. Bei `ShowDetailedMessages = 1` wird eine Statustabelle zurückgegeben:\n - eine `OK`-Zeile mit den Rechnungsnummern, die mit den übergebenen Positionen verknüpft sind;\n - eine `ERROR`-Zeile mit Aufträgen, deren übergebene Positionen keine Rechnungsposition haben;\n - eine `ERROR`-Zeile, wenn beides nicht zutrifft.\n\nBei `ShowDetailedMessages = 0` wird keine Ergebnismenge geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlinesXML` | varchar(max) | Nein | XML mit den abzurechnenden Auftragspositionen sowie optionalem Versanddienstleister und Tracking-Daten. Erwarteter Pfad: `/Orderlines/Orderline`, mit den Elementen `OrderlineKey`, `ShipVendor` (max. 3 Zeichen), `ShipmentTrackingId` und `ReturnTrackingId`. Mehrere Tracking-IDs können mit `;` getrennt werden. Bei NULL oder Leerstring werden alle berechtigten Positionen verarbeitet. Bei `ShowDetailedMessages = 1` ist das XML Pflicht. |\n| `ShowDetailedMessages` | bit | Nein | Steuert die Eingabeprüfung und die Status-Ergebnismenge. NULL wird als 0 behandelt. |\n\n- **Fehler werden verschluckt.** Der gesamte Ablauf läuft in `TRY/CATCH`. Der `CATCH`-Block gibt nur den Application-Lock frei, SQL-Fehler erreichen den Aufrufer also nie. Bei `ShowDetailedMessages = 0` erhält der Aufrufer gar keine Rückmeldung.\n- **Lock-Ergebnis wird nicht geprüft.** Der Rückgabewert von `sp_getapplock` wird nicht ausgewertet. Kann der Lock nicht innerhalb von 5 Sekunden erlangt werden, läuft die Verarbeitung trotzdem weiter.\n- **Lock wird bei Validierungsfehlern nicht freigegeben.** Bei den vorzeitigen Rücksprüngen nach einem Validierungsfehler wird der Lock nicht explizit freigegeben. Er bleibt bis zum Ende der Session bestehen.\n- **Kürzungsrisiko.** `ErrorMessage` ist `varchar(512)`, und die Liste der Rechnungsnummern liegt in einer `varchar(512)`-Variablen. Lange Listen von Auftrags- oder Rechnungsnummern können gekürzt werden oder einen Kürzungsfehler auslösen, der dann stillschweigend abgefangen wird.\n- **Validierung ist optional.** Sie läuft nur bei `ShowDetailedMessages = 1`. Ohne sie liest die interne Prozedur `ShipVendor` als `varchar(3)` und die Tracking-IDs als `varchar(512)`, längere Werte können also abgeschnitten werden.\n- **Bedeutung der `OK`-Zeile.** Sie nennt alle Rechnungen, die mit den übergebenen Positionen verknüpft sind, also unter Umständen auch früher erzeugte. Der Code-Kommentar nennt einen Lieferanten ohne `CanDoDirectFulfillment` oder einen Positionsstatus ungleich `FUT` als typische Ursachen für eine fehlende Rechnung.\n- **Einstellungen.**\n - Ist weder `EnableFulfilmentTypeOne` noch `EnableFulfilmentTypeTwo` gleich `1`, werden keine Rechnungen erzeugt.\n - Bei `DoNotSendAUSmailOnFulfillment` = `1`/`Y` werden die Positionen zusätzlich mit `CustomerEMailed = 'Y'` markiert.\n- **Rechnungsnummern.** Eine vorhandene externe Rechnungsnummer an den Auftragspositionen (`InvoiceNrExternal`) wird bei der Anlage der Rechnung verwendet. Danach ruft die interne Prozedur `Pixi_GetNextInvNr` auf und schreibt deren Ergebnis in `InvoiceNr`. Ob dabei die externe Nummer erhalten bleibt, ist nicht ersichtlich, da diese Prozedur nicht beigefügt ist.\n- **Rollback je Auftrag.** Eine Rechnung ohne Positionen wird zurückgerollt und gelöscht, ebenso ein Auftrag, bei dem Fehler aufgetreten sind. Andere Aufträge sind davon nicht betroffen.\n- **Weitere Nebeneffekte.** Mehrere verschachtelte Prozeduren sind nicht beigefügt: `GOS_Qi_InvoiceNOD`, `Pixi_CA_AddPixiInvoice`, `GOSScanOutInvoice`, `Pixi_PollCreateRecords`, `Pixi_MQ_EventPublish` und `Pixi_AddDataForSEPAExportToInvoice`. Ihre Nebeneffekte sind hier nicht dokumentiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFCreateInvoices"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt Direct-Fulfillment-Rechnungen (DF) für bereite Auftragspositionen an, optional eingeschränkt auf und ergänzt um Versanddienstleister und Tracking-Daten aus XML.\n\nDer Aufruf legt Rechnungen für Direct-Fulfillment-Aufträge an. Die eigentliche Verarbeitung übernimmt die interne Prozedur `Pixi_CreateFulfillmentIncoices`, die mit `CreateEmp = 'API'` läuft.\n\n**Ablauf**\n\n1. Ein exklusiver Application-Lock `pipiDFCreateInvoices` wird mit 5 Sekunden Timeout angefordert, damit parallele Läufe nacheinander ausgeführt werden.\n2. Ist `OrderlinesXML` gesetzt (ein Leerstring gilt als NULL), werden die Elemente `/Orderlines/Orderline` mit den Unterelementen `OrderlineKey`, `ShipVendor`, `ShipmentTrackingId` und `ReturnTrackingId` gelesen.\n3. Bei `ShowDetailedMessages = 1` wird die Eingabe zuerst geprüft:\n - Das XML muss vorhanden sein und mindestens ein `Orderline` enthalten.\n - Der Versanddienstleister-Code (aus der ersten Zeile je Auftrag) darf höchstens 3 Zeichen lang sein.\n - Alle Sendungs-Tracking-IDs eines Auftrags, mit `;` verbunden, dürfen höchstens 512 Zeichen lang sein. Dieselbe Grenze gilt für die Retouren-Tracking-IDs.\n - Jeder `OrderlineKey` muss in `Orderlines` existieren.\n \n Schlägt eine Prüfung fehl, werden alle Fehlerzeilen zurückgegeben und keine Rechnung angelegt.\n4. Die Rechnungen werden angelegt. Das Verhalten hängt von den Einstellungen `EnableFulfilmentTypeOne` und `EnableFulfilmentTypeTwo` ab:\n - **Typ eins:** Auftragspositionen aus dem XML mit Status `FUT` werden zuerst auf `FUS` gesetzt. Danach wird je Auftrag mit `FUS`-Positionen eine Rechnung erzeugt. Mit XML werden nur die übergebenen Positionen verwendet, ohne XML alle `FUS`-Positionen.\n - **Typ zwei:** Kandidaten sind Aufträge, deren Positionen alle `FUS` oder in einem Endstatus sind und die mindestens eine `FUS`-Position ohne Rechnung haben. Das XML schränkt die Kandidaten-Aufträge nicht ein. Es bestimmt nur, welche `FUS`-Positionen in die Rechnung übernommen werden. Positionen mit Status `MIN` werden immer übernommen.\n5. Jeder Auftrag wird in einer eigenen Transaktion verarbeitet:\n - Die Rechnung wird angelegt, mit `Fulfillment = 1` gekennzeichnet und mit Rechnungspositionen versehen.\n - Der Versanddienstleister aus dem XML ersetzt den des Auftrags.\n - Tracking-IDs aus dem XML werden an der Rechnung gespeichert. Mehrere IDs können mit `;` getrennt werden, und jede eindeutige ID wird ein eigenes Rechnungspaket.\n - Die Auftragspositionen werden auf `AUS` mit `InvRef` und `ShipDate` gesetzt.\n - Eine Rechnungsnummer wird vergeben, eine Buchung im Kundenkonto angelegt und die Rechnung ausgescannt.\n - Ein Event `InvoiceCreated` wird veröffentlicht.\n6. Bei `ShowDetailedMessages = 1` wird eine Statustabelle zurückgegeben:\n - eine `OK`-Zeile mit den Rechnungsnummern, die mit den übergebenen Positionen verknüpft sind;\n - eine `ERROR`-Zeile mit Aufträgen, deren übergebene Positionen keine Rechnungsposition haben;\n - eine `ERROR`-Zeile, wenn beides nicht zutrifft.\n\nBei `ShowDetailedMessages = 0` wird keine Ergebnismenge geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlinesXML` | varchar(max) | Nein | XML mit den abzurechnenden Auftragspositionen sowie optionalem Versanddienstleister und Tracking-Daten. Erwarteter Pfad: `/Orderlines/Orderline`, mit den Elementen `OrderlineKey`, `ShipVendor` (max. 3 Zeichen), `ShipmentTrackingId` und `ReturnTrackingId`. Mehrere Tracking-IDs können mit `;` getrennt werden. Bei NULL oder Leerstring werden alle berechtigten Positionen verarbeitet. Bei `ShowDetailedMessages = 1` ist das XML Pflicht. |\n| `ShowDetailedMessages` | bit | Nein | Steuert die Eingabeprüfung und die Status-Ergebnismenge. NULL wird als 0 behandelt. |\n\n- **Fehler werden verschluckt.** Der gesamte Ablauf läuft in `TRY/CATCH`. Der `CATCH`-Block gibt nur den Application-Lock frei, SQL-Fehler erreichen den Aufrufer also nie. Bei `ShowDetailedMessages = 0` erhält der Aufrufer gar keine Rückmeldung.\n- **Lock-Ergebnis wird nicht geprüft.** Der Rückgabewert von `sp_getapplock` wird nicht ausgewertet. Kann der Lock nicht innerhalb von 5 Sekunden erlangt werden, läuft die Verarbeitung trotzdem weiter.\n- **Lock wird bei Validierungsfehlern nicht freigegeben.** Bei den vorzeitigen Rücksprüngen nach einem Validierungsfehler wird der Lock nicht explizit freigegeben. Er bleibt bis zum Ende der Session bestehen.\n- **Kürzungsrisiko.** `ErrorMessage` ist `varchar(512)`, und die Liste der Rechnungsnummern liegt in einer `varchar(512)`-Variablen. Lange Listen von Auftrags- oder Rechnungsnummern können gekürzt werden oder einen Kürzungsfehler auslösen, der dann stillschweigend abgefangen wird.\n- **Validierung ist optional.** Sie läuft nur bei `ShowDetailedMessages = 1`. Ohne sie liest die interne Prozedur `ShipVendor` als `varchar(3)` und die Tracking-IDs als `varchar(512)`, längere Werte können also abgeschnitten werden.\n- **Bedeutung der `OK`-Zeile.** Sie nennt alle Rechnungen, die mit den übergebenen Positionen verknüpft sind, also unter Umständen auch früher erzeugte. Der Code-Kommentar nennt einen Lieferanten ohne `CanDoDirectFulfillment` oder einen Positionsstatus ungleich `FUT` als typische Ursachen für eine fehlende Rechnung.\n- **Einstellungen.**\n - Ist weder `EnableFulfilmentTypeOne` noch `EnableFulfilmentTypeTwo` gleich `1`, werden keine Rechnungen erzeugt.\n - Bei `DoNotSendAUSmailOnFulfillment` = `1`/`Y` werden die Positionen zusätzlich mit `CustomerEMailed = 'Y'` markiert.\n- **Rechnungsnummern.** Eine vorhandene externe Rechnungsnummer an den Auftragspositionen (`InvoiceNrExternal`) wird bei der Anlage der Rechnung verwendet. Danach ruft die interne Prozedur `Pixi_GetNextInvNr` auf und schreibt deren Ergebnis in `InvoiceNr`. Ob dabei die externe Nummer erhalten bleibt, ist nicht ersichtlich, da diese Prozedur nicht beigefügt ist.\n- **Rollback je Auftrag.** Eine Rechnung ohne Positionen wird zurückgerollt und gelöscht, ebenso ein Auftrag, bei dem Fehler aufgetreten sind. Andere Aufträge sind davon nicht betroffen.\n- **Weitere Nebeneffekte.** Mehrere verschachtelte Prozeduren sind nicht beigefügt: `GOS_Qi_InvoiceNOD`, `Pixi_CA_AddPixiInvoice`, `GOSScanOutInvoice`, `Pixi_PollCreateRecords`, `Pixi_MQ_EventPublish` und `Pixi_AddDataForSEPAExportToInvoice`. Ihre Nebeneffekte sind hier nicht dokumentiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFCreateInvoices"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n Direct fulfilment Invoice(s) created with invoice number(s): RE100234; RE100235\n \n"
}
]
},
{
"name": "pixiDFGetChanges",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die neuesten, noch nicht gemeldeten Fulfillment-Statusänderungen von `FUT`-Auftragspositionen für einen Direct-Fulfillment-Lieferanten inklusive Adress-, Artikel- und Auftragsdaten.\n\nAPI-Aufruf für Direct-Fulfillment-Lieferanten (DF), der die noch zu verarbeitenden Änderungen an Auftragspositionen abruft.\n\n**Authentifizierung**\n\n- Der Lieferant wird in `Suppliers` über `SupplNr` gesucht. `Secret` muss der `CustNr` des Lieferanten entsprechen. Der Lieferant darf nicht deaktiviert sein und muss `CanDoDirectFulfillment = 1` haben.\n- Wird kein Lieferant gefunden und ist die Einstellung `DFAPIAllowFullAccessWithoutSecret` gleich `0` (oder nicht vorhanden), wird eine einzelne Zeile mit `Error = 403` geliefert.\n- Wird kein Lieferant gefunden und ist die Einstellung ungleich `0`, läuft der Aufruf **ohne Lieferantenfilter** weiter und liefert die Änderungen aller Lieferanten.\n\n**Auswahl**\n\nJe Auftragsposition wird nur der neueste `OrderHistory`-Eintrag (höchster `OrderHistKey`) berücksichtigt, und nur wenn alle folgenden Bedingungen gelten:\n\n- die Auftragsposition hat den Status `FUT`;\n- der Historienstatus ist ein Status in `OrderStates` mit `FulfilmentStatus = 'Y'`;\n- `SupplInfo` der Position entspricht dem authentifizierten Lieferanten (falls einer gefunden wurde);\n- Lieferadresse (`ASlocked`) und Kunde (`SLocked`) sind nicht gesperrt, außer bei `LockedCustomers = 1`;\n- `OrderNrExternal` entspricht `OrderNRExternal`, sofern dieser Parameter angegeben ist;\n- der Auftragskopf wurde vor mehr als 5 Minuten angelegt.\n\nZusätzlich muss der Historieneintrag `ClientNotified = 'N'` haben. Positionen, deren Status in `ExcludeStatuses` enthalten ist, werden übersprungen.\n\n**Ausgabe**\n\n- Kommt eine Auftragsposition mehrfach im Ergebnis vor, wird statt der Daten eine einzelne Meldungszeile geliefert und der Aufruf beendet.\n- Andernfalls werden alle Zeilen nach `StatusChangeDate` sortiert geliefert. In Datenbanken, deren Name mit `pixi_PSP` beginnt, wird nach `ordernr` und dann `StatusChangeDate` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer des Direct-Fulfillment-Lieferanten. Dient der Authentifizierung und filtert die Auftragspositionen über `SupplInfo`. |\n| `Secret` | varchar(20) | Nein | Secret des Lieferanten. Muss der `CustNr` des Lieferanten in `Suppliers` entsprechen. |\n| `OrderNRExternal` | varchar(50) | Nein | Optionale externe Auftragsnummer. Beschränkt das Ergebnis auf Änderungen dieses Auftrags; leer oder NULL bedeutet alle Aufträge. |\n| `ExcludeStatuses` | varchar(200) | Nein | Auszuschließende Positionsstatus, als Teilstring geprüft (z. B. `STO,AUS`). In `pixi_PSP`-Datenbanken ist die Vorgabe bei leerem Wert `STO`. |\n| `LockedCustomers` | bit | Nein | Gibt an, ob Positionen mit gesperrter Lieferadresse oder gesperrtem Kunden enthalten sind. |\n\n- Der Aufruf ist rein lesend. Er setzt `ClientNotified` **nicht**, daher werden dieselben Änderungen erneut geliefert, bis ein anderer Prozess sie als gemeldet markiert. Dieser Prozess ist nicht Teil dieses Codes.\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- `ExcludeStatuses` wird per `CHARINDEX` (Teilstring-Suche) geprüft, daher ist jedes Trennzeichen möglich, z. B. `STO,AUS`. Die innere Auswahl liefert ohnehin nur `FUT`-Positionen, daher wirkt der Parameter nur, wenn er `FUT` enthält; dann werden alle Zeilen unterdrückt.\n- Ist `ExcludeStatuses` leer und beginnt der Datenbankname mit `pixi_PSP`, wird `STO` als Vorgabe verwendet.\n- Sind `SupplNr`/`Secret` falsch und ist `DFAPIAllowFullAccessWithoutSecret` ungleich `0`, werden die Daten **aller** Lieferanten geliefert.\n- Aufträge, die vor weniger als 5 Minuten angelegt wurden, werden zurückgehalten.\n- Die temporäre Tabelle wird über `util.TempTableDrop` verwaltet. Dieses Objekt liegt nicht vor.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFGetChanges"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die neuesten, noch nicht gemeldeten Fulfillment-Statusänderungen von `FUT`-Auftragspositionen für einen Direct-Fulfillment-Lieferanten inklusive Adress-, Artikel- und Auftragsdaten.\n\nAPI-Aufruf für Direct-Fulfillment-Lieferanten (DF), der die noch zu verarbeitenden Änderungen an Auftragspositionen abruft.\n\n**Authentifizierung**\n\n- Der Lieferant wird in `Suppliers` über `SupplNr` gesucht. `Secret` muss der `CustNr` des Lieferanten entsprechen. Der Lieferant darf nicht deaktiviert sein und muss `CanDoDirectFulfillment = 1` haben.\n- Wird kein Lieferant gefunden und ist die Einstellung `DFAPIAllowFullAccessWithoutSecret` gleich `0` (oder nicht vorhanden), wird eine einzelne Zeile mit `Error = 403` geliefert.\n- Wird kein Lieferant gefunden und ist die Einstellung ungleich `0`, läuft der Aufruf **ohne Lieferantenfilter** weiter und liefert die Änderungen aller Lieferanten.\n\n**Auswahl**\n\nJe Auftragsposition wird nur der neueste `OrderHistory`-Eintrag (höchster `OrderHistKey`) berücksichtigt, und nur wenn alle folgenden Bedingungen gelten:\n\n- die Auftragsposition hat den Status `FUT`;\n- der Historienstatus ist ein Status in `OrderStates` mit `FulfilmentStatus = 'Y'`;\n- `SupplInfo` der Position entspricht dem authentifizierten Lieferanten (falls einer gefunden wurde);\n- Lieferadresse (`ASlocked`) und Kunde (`SLocked`) sind nicht gesperrt, außer bei `LockedCustomers = 1`;\n- `OrderNrExternal` entspricht `OrderNRExternal`, sofern dieser Parameter angegeben ist;\n- der Auftragskopf wurde vor mehr als 5 Minuten angelegt.\n\nZusätzlich muss der Historieneintrag `ClientNotified = 'N'` haben. Positionen, deren Status in `ExcludeStatuses` enthalten ist, werden übersprungen.\n\n**Ausgabe**\n\n- Kommt eine Auftragsposition mehrfach im Ergebnis vor, wird statt der Daten eine einzelne Meldungszeile geliefert und der Aufruf beendet.\n- Andernfalls werden alle Zeilen nach `StatusChangeDate` sortiert geliefert. In Datenbanken, deren Name mit `pixi_PSP` beginnt, wird nach `ordernr` und dann `StatusChangeDate` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer des Direct-Fulfillment-Lieferanten. Dient der Authentifizierung und filtert die Auftragspositionen über `SupplInfo`. |\n| `Secret` | varchar(20) | Nein | Secret des Lieferanten. Muss der `CustNr` des Lieferanten in `Suppliers` entsprechen. |\n| `OrderNRExternal` | varchar(50) | Nein | Optionale externe Auftragsnummer. Beschränkt das Ergebnis auf Änderungen dieses Auftrags; leer oder NULL bedeutet alle Aufträge. |\n| `ExcludeStatuses` | varchar(200) | Nein | Auszuschließende Positionsstatus, als Teilstring geprüft (z. B. `STO,AUS`). In `pixi_PSP`-Datenbanken ist die Vorgabe bei leerem Wert `STO`. |\n| `LockedCustomers` | bit | Nein | Gibt an, ob Positionen mit gesperrter Lieferadresse oder gesperrtem Kunden enthalten sind. |\n\n- Der Aufruf ist rein lesend. Er setzt `ClientNotified` **nicht**, daher werden dieselben Änderungen erneut geliefert, bis ein anderer Prozess sie als gemeldet markiert. Dieser Prozess ist nicht Teil dieses Codes.\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- `ExcludeStatuses` wird per `CHARINDEX` (Teilstring-Suche) geprüft, daher ist jedes Trennzeichen möglich, z. B. `STO,AUS`. Die innere Auswahl liefert ohnehin nur `FUT`-Positionen, daher wirkt der Parameter nur, wenn er `FUT` enthält; dann werden alle Zeilen unterdrückt.\n- Ist `ExcludeStatuses` leer und beginnt der Datenbankname mit `pixi_PSP`, wird `STO` als Vorgabe verwendet.\n- Sind `SupplNr`/`Secret` falsch und ist `DFAPIAllowFullAccessWithoutSecret` ungleich `0`, werden die Daten **aller** Lieferanten geliefert.\n- Aufträge, die vor weniger als 5 Minuten angelegt wurden, werden zurückgehalten.\n- Die temporäre Tabelle wird über `util.TempTableDrop` verwaltet. Dieses Objekt liegt nicht vor.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFGetChanges"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Frau\n \n Anna\n Muster\n Hauptstraße\n 80331\n 12\n München\n DE\n anna.muster@example.com\n 089123456\n \n N\n \n 2024-05-14T00:00:00\n DHL\n Kaffeemaschine X200\n 4012345678901\n X200-BLK\n SKU-4711\n 1\n 129.90\n FUT\n 884512\n 553210\n 2024-05-13T10:15:22\n 2024-05-13T09:58:01\n SHOP-2024-004711\n WEB\n \n L001\n PP\n 0.00\n 4.90\n \n DF\n 120345\n N\n N\n EUR\n \n"
}
]
},
{
"name": "pixiDFGetChangesConfirmation",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n L001\n K12345\n 584213\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Bestätigt eine verarbeitete Auftragshistorien-Änderung für einen Direct-Fulfillment-Lieferanten, setzt das ClientNotified-Flag und optional das Tracking-Versanddatum einer Rechnung.\n\nQuittiert einen Eintrag der Auftragshistorie aus der Direct-Fulfillment-API. Ein Lieferant ruft dies auf, nachdem er eine Änderung verarbeitet hat, damit die Änderung als übermittelt markiert wird.\n\n1. **Authentifizierung:** Der Lieferant wird in `Suppliers` über `SupplNr` gesucht, mit `CustNr` = `Secret`, nicht deaktiviert (`Disabled` <> 1) und für Direct Fulfillment freigeschaltet (`CanDoDirectFulfillment` = 1).\n - Wird kein Lieferant gefunden und hat die Einstellung `DFAPIAllowFullAccessWithoutSecret` den Wert `0`, liefert der Aufruf den Status `403`. Fehlt die Einstellung, gilt ebenfalls `0`.\n - Bei jedem anderen Wert der Einstellung entfällt die Secret-Prüfung.\n2. **Suche:** Existiert der `OrderHistKey` nicht in `OrderHistory`, liefert der Aufruf den Status `404`.\n3. **Aktualisierung:** Andernfalls wird die interne Prozedur `GOSUpdateOHClientNotifiedXML` ausgeführt:\n - Der Historieneintrag erhält `ClientNotified` = `Y` (nur wenn `OrderHistKey` <> 0).\n - Ist `InvoiceKey` <> 0, wird `Invoices.TrackingIDSent` der Rechnung auf das aktuelle Datum mit Uhrzeit gesetzt.\n - Bei Erfolg ist der Status `200`. Tritt ein Fehler auf, ist der Status `500` mit der SQL-Fehlermeldung.\n\nDer Aufruf liefert immer genau eine Zeile mit `Status` und `ErrorMsg`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Ja | Lieferantennummer des Direct-Fulfillment-Lieferanten. |\n| `Secret` | varchar(20) | Ja | Secret des Lieferanten. Es wird mit dem Feld `CustNr` des Lieferanten verglichen. |\n| `OrderHistKey` | int | Ja | Schlüssel des zu bestätigenden Eintrags der Auftragshistorie. Der Eintrag erhält `ClientNotified` = `Y`. |\n| `InvoiceKey` | int | Nein | Optionaler Rechnungsschlüssel. Ist er ungleich 0, wird `TrackingIDSent` dieser Rechnung auf das aktuelle Datum mit Uhrzeit gesetzt. |\n\n- Der Code prüft nicht, ob `OrderHistKey` oder `InvoiceKey` zum authentifizierten Lieferanten gehört. Jeder vorhandene Historieneintrag kann bestätigt werden.\n- `InvoiceKey` wird nicht validiert. Existiert die Rechnung nicht, wird keine Zeile geändert, der Status ist trotzdem `200`.\n- Die beiden Updates laufen nicht in einer expliziten Transaktion. Schlägt das Rechnungs-Update fehl, kann das `ClientNotified`-Flag bereits gesetzt sein, obwohl der Aufruf `500` liefert.\n- Lieferantensuche und Existenzprüfung verwenden `NOLOCK`.\n- Ist `OrderHistKey` `NULL`, wird die `404`-Meldung durch die Zeichenverkettung `NULL`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFGetChangesConfirmation"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n L001\n K12345\n 584213\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Bestätigt eine verarbeitete Auftragshistorien-Änderung für einen Direct-Fulfillment-Lieferanten, setzt das ClientNotified-Flag und optional das Tracking-Versanddatum einer Rechnung.\n\nQuittiert einen Eintrag der Auftragshistorie aus der Direct-Fulfillment-API. Ein Lieferant ruft dies auf, nachdem er eine Änderung verarbeitet hat, damit die Änderung als übermittelt markiert wird.\n\n1. **Authentifizierung:** Der Lieferant wird in `Suppliers` über `SupplNr` gesucht, mit `CustNr` = `Secret`, nicht deaktiviert (`Disabled` <> 1) und für Direct Fulfillment freigeschaltet (`CanDoDirectFulfillment` = 1).\n - Wird kein Lieferant gefunden und hat die Einstellung `DFAPIAllowFullAccessWithoutSecret` den Wert `0`, liefert der Aufruf den Status `403`. Fehlt die Einstellung, gilt ebenfalls `0`.\n - Bei jedem anderen Wert der Einstellung entfällt die Secret-Prüfung.\n2. **Suche:** Existiert der `OrderHistKey` nicht in `OrderHistory`, liefert der Aufruf den Status `404`.\n3. **Aktualisierung:** Andernfalls wird die interne Prozedur `GOSUpdateOHClientNotifiedXML` ausgeführt:\n - Der Historieneintrag erhält `ClientNotified` = `Y` (nur wenn `OrderHistKey` <> 0).\n - Ist `InvoiceKey` <> 0, wird `Invoices.TrackingIDSent` der Rechnung auf das aktuelle Datum mit Uhrzeit gesetzt.\n - Bei Erfolg ist der Status `200`. Tritt ein Fehler auf, ist der Status `500` mit der SQL-Fehlermeldung.\n\nDer Aufruf liefert immer genau eine Zeile mit `Status` und `ErrorMsg`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Ja | Lieferantennummer des Direct-Fulfillment-Lieferanten. |\n| `Secret` | varchar(20) | Ja | Secret des Lieferanten. Es wird mit dem Feld `CustNr` des Lieferanten verglichen. |\n| `OrderHistKey` | int | Ja | Schlüssel des zu bestätigenden Eintrags der Auftragshistorie. Der Eintrag erhält `ClientNotified` = `Y`. |\n| `InvoiceKey` | int | Nein | Optionaler Rechnungsschlüssel. Ist er ungleich 0, wird `TrackingIDSent` dieser Rechnung auf das aktuelle Datum mit Uhrzeit gesetzt. |\n\n- Der Code prüft nicht, ob `OrderHistKey` oder `InvoiceKey` zum authentifizierten Lieferanten gehört. Jeder vorhandene Historieneintrag kann bestätigt werden.\n- `InvoiceKey` wird nicht validiert. Existiert die Rechnung nicht, wird keine Zeile geändert, der Status ist trotzdem `200`.\n- Die beiden Updates laufen nicht in einer expliziten Transaktion. Schlägt das Rechnungs-Update fehl, kann das `ClientNotified`-Flag bereits gesetzt sein, obwohl der Aufruf `500` liefert.\n- Lieferantensuche und Existenzprüfung verwenden `NOLOCK`.\n- Ist `OrderHistKey` `NULL`, wird die `404`-Meldung durch die Zeichenverkettung `NULL`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFGetChangesConfirmation"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 200\n ClientNotified flag successfully set for OrderHistKey(584213).\n \n"
}
]
},
{
"name": "pixiDFGetOrderlines",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die offenen Direct-Fulfillment-Auftragspositionen (Status FUT) eines Auftrags für einen Direct-Fulfillment-Lieferanten, authentifiziert über Lieferantennummer und Secret.\n\nWird von Direct-Fulfillment-Lieferanten (Streckengeschäft) verwendet, um die zu versendenden Positionen eines Auftrags abzurufen.\n\n**Authentifizierung**\n\n- Leere Zeichenketten in `SupplNr` und `Secret` werden als `NULL` behandelt.\n- Gesucht wird ein Lieferant in `Suppliers`, dessen `SupplNr` gleich `SupplNr` und dessen `CustNr` gleich `Secret` ist. Der Lieferant darf nicht deaktiviert sein und muss `CanDoDirectFulfillment = 1` haben.\n- Wird kein solcher Lieferant gefunden und ist die Einstellung `DFAPIAllowFullAccessWithoutSecret` gleich `0` (oder nicht vorhanden), wird nur eine Zeile mit `Error = '403'` geliefert.\n- Ist die Einstellung ungleich `0`, entfällt die Prüfung, und der Aufruf funktioniert ohne gültiges Secret.\n\n**Gelieferte Auftragspositionen**\n\nNur Positionen, die alle folgenden Bedingungen erfüllen:\n\n- Die Position gehört zum Auftrag `OrderNR`.\n- Die Position hat den Status `FUT`; verwendet wird der neueste `OrderHistory`-Eintrag mit Status `FUT` (`OrderHistKey`, `StatusChangeDate`, `ClientNotified`).\n- Der Status `FUT` ist in `OrderStates` als Fulfilment-Status gekennzeichnet (`FulfilmentStatus = 'Y'`).\n- Ohne `AllOrderlines = 1` werden nur noch nicht bestätigte Positionen (`ClientNotified = 'N'`) geliefert.\n- Ist `SupplNr` angegeben, werden nur Positionen mit `SupplInfo = SupplNr` geliefert, und dieser Lieferant muss Direct Fulfillment unterstützen. Ist `SupplNr` leer (nur bei deaktivierter Secret-Prüfung möglich), werden Positionen aller Lieferanten geliefert.\n- Die Lieferadresse darf nicht gesperrt sein (`ASlocked`), der Kunde ebenfalls nicht (`SLocked`).\n- Auftragskopf, Rechnungsadresse, Kunde und Währung müssen vorhanden sein (Inner Joins).\n\n**Artikeldaten**\n\n`EANUPC`, `ItemNrSuppl` und `ItemNrInt` stammen aus dem lieferantenspezifischen `AddItems`-Datensatz (Lieferant = `SupplInfo` der Position, zuletzt aktualisierter Datensatz); fehlt ein Wert dort, wird der Wert aus `Items` verwendet.\n\nDoppelte Zeilen werden entfernt (`DISTINCT`). Eine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNR` | int | Ja | Nummer des Auftrags, dessen Direct-Fulfillment-Positionen geliefert werden. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer des Direct-Fulfillment-Lieferanten. Dient der Authentifizierung und beschränkt die Positionen auf diesen Lieferanten. Leere Zeichenkette wird als NULL behandelt. |\n| `Secret` | varchar(20) | Nein | Secret des Lieferanten; muss dem Feld `CustNr` des Lieferanten entsprechen. Leere Zeichenkette wird als NULL behandelt. |\n| `AllOrderlines` | bit | Nein | Legt fest, ob bereits bestätigte Positionen enthalten sind. |\n\n- Der Fehler wird als normale Ergebniszeile (`Error`, `ErrorMsg`) geliefert, nicht als SQL-Fehler. Die Antwort sollte auf die Spalte `Error` geprüft werden.\n- `Secret` wird mit dem Feld `CustNr` des Lieferanten verglichen (die Kundennummer, unter der der Shop beim Lieferanten geführt wird).\n- Ist `DFAPIAllowFullAccessWithoutSecret` aktiviert und bleibt `SupplNr` leer, werden die Positionen **aller** Lieferanten des Auftrags geliefert. Im Produktivbetrieb sollte diese Einstellung auf `0` bleiben.\n- Der Aufruf ändert keine Daten; Positionen werden nicht als bestätigt markiert. `OrderlineConfirmed` entspricht `ClientNotified` des neuesten `FUT`-Historieneintrags.\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können geliefert werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFGetOrderlines"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die offenen Direct-Fulfillment-Auftragspositionen (Status FUT) eines Auftrags für einen Direct-Fulfillment-Lieferanten, authentifiziert über Lieferantennummer und Secret.\n\nWird von Direct-Fulfillment-Lieferanten (Streckengeschäft) verwendet, um die zu versendenden Positionen eines Auftrags abzurufen.\n\n**Authentifizierung**\n\n- Leere Zeichenketten in `SupplNr` und `Secret` werden als `NULL` behandelt.\n- Gesucht wird ein Lieferant in `Suppliers`, dessen `SupplNr` gleich `SupplNr` und dessen `CustNr` gleich `Secret` ist. Der Lieferant darf nicht deaktiviert sein und muss `CanDoDirectFulfillment = 1` haben.\n- Wird kein solcher Lieferant gefunden und ist die Einstellung `DFAPIAllowFullAccessWithoutSecret` gleich `0` (oder nicht vorhanden), wird nur eine Zeile mit `Error = '403'` geliefert.\n- Ist die Einstellung ungleich `0`, entfällt die Prüfung, und der Aufruf funktioniert ohne gültiges Secret.\n\n**Gelieferte Auftragspositionen**\n\nNur Positionen, die alle folgenden Bedingungen erfüllen:\n\n- Die Position gehört zum Auftrag `OrderNR`.\n- Die Position hat den Status `FUT`; verwendet wird der neueste `OrderHistory`-Eintrag mit Status `FUT` (`OrderHistKey`, `StatusChangeDate`, `ClientNotified`).\n- Der Status `FUT` ist in `OrderStates` als Fulfilment-Status gekennzeichnet (`FulfilmentStatus = 'Y'`).\n- Ohne `AllOrderlines = 1` werden nur noch nicht bestätigte Positionen (`ClientNotified = 'N'`) geliefert.\n- Ist `SupplNr` angegeben, werden nur Positionen mit `SupplInfo = SupplNr` geliefert, und dieser Lieferant muss Direct Fulfillment unterstützen. Ist `SupplNr` leer (nur bei deaktivierter Secret-Prüfung möglich), werden Positionen aller Lieferanten geliefert.\n- Die Lieferadresse darf nicht gesperrt sein (`ASlocked`), der Kunde ebenfalls nicht (`SLocked`).\n- Auftragskopf, Rechnungsadresse, Kunde und Währung müssen vorhanden sein (Inner Joins).\n\n**Artikeldaten**\n\n`EANUPC`, `ItemNrSuppl` und `ItemNrInt` stammen aus dem lieferantenspezifischen `AddItems`-Datensatz (Lieferant = `SupplInfo` der Position, zuletzt aktualisierter Datensatz); fehlt ein Wert dort, wird der Wert aus `Items` verwendet.\n\nDoppelte Zeilen werden entfernt (`DISTINCT`). Eine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNR` | int | Ja | Nummer des Auftrags, dessen Direct-Fulfillment-Positionen geliefert werden. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer des Direct-Fulfillment-Lieferanten. Dient der Authentifizierung und beschränkt die Positionen auf diesen Lieferanten. Leere Zeichenkette wird als NULL behandelt. |\n| `Secret` | varchar(20) | Nein | Secret des Lieferanten; muss dem Feld `CustNr` des Lieferanten entsprechen. Leere Zeichenkette wird als NULL behandelt. |\n| `AllOrderlines` | bit | Nein | Legt fest, ob bereits bestätigte Positionen enthalten sind. |\n\n- Der Fehler wird als normale Ergebniszeile (`Error`, `ErrorMsg`) geliefert, nicht als SQL-Fehler. Die Antwort sollte auf die Spalte `Error` geprüft werden.\n- `Secret` wird mit dem Feld `CustNr` des Lieferanten verglichen (die Kundennummer, unter der der Shop beim Lieferanten geführt wird).\n- Ist `DFAPIAllowFullAccessWithoutSecret` aktiviert und bleibt `SupplNr` leer, werden die Positionen **aller** Lieferanten des Auftrags geliefert. Im Produktivbetrieb sollte diese Einstellung auf `0` bleiben.\n- Der Aufruf ändert keine Daten; Positionen werden nicht als bestätigt markiert. `OrderlineConfirmed` entspricht `ClientNotified` des neuesten `FUT`-Historieneintrags.\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können geliefert werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFGetOrderlines"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 558812\n 104523\n Gartenstuhl Teak natur\n 4006381333931\n GS-TEAK-01\n SHOP-77812\n 2\n 89.90\n FUT\n 9912034\n 2024-05-14T09:32:11\n 2024-05-14T08:15:00\n WEB-2024-55123\n \n DF01\n \n DF\n 33417\n N\n EUR\n 0\n 100245\n \n"
}
]
},
{
"name": "pixiDFGetOrderlines_new",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Direct-Fulfillment-Auftragspositionen (Status FUT) eines Auftrags für einen berechtigten Streckenlieferanten inklusive Artikel-, Historien- und Währungsdaten.\n\nSchnittstellenaufruf für Direct-Fulfillment-Lieferanten (Streckengeschäft), um die zu erfüllenden Positionen eines einzelnen Auftrags abzurufen.\n\n**Berechtigung**\n\n1. Leere Strings in `SupplNr` und `Secret` werden als `NULL` behandelt.\n2. In `Suppliers` wird ein Lieferant gesucht, dessen `SupplNr` gleich `SupplNr` und dessen `CustNr` gleich `Secret` ist, der nicht deaktiviert ist und `CanDoDirectFulfillment = 1` hat.\n3. Wird kein solcher Lieferant gefunden und ist die Einstellung `DFAPIAllowFullAccessWithoutSecret` gleich `0` (oder nicht vorhanden), wird ausschließlich eine Fehlerzeile mit `Error = 403` geliefert.\n4. Andernfalls werden die Auftragspositionen geliefert.\n\n**Auswahl der Positionen**\n\n- Nur Positionen des Auftrags `OrderNR` mit Positionsstatus `FUT`.\n- Jede Position wird mit ihrem neuesten `OrderHistory`-Eintrag mit Status `FUT` verknüpft; dieser Status muss in `OrderStates` ein Fulfillment-Status sein (`FulfilmentStatus = 'Y'`).\n- Standardmäßig werden nur noch nicht bestätigte Positionen geliefert (`ClientNotified = 'N'`); mit `AllOrderlines = 1` auch bereits bestätigte.\n- Ist `SupplNr` angegeben, werden nur Positionen geliefert, deren `SupplInfo` gleich `SupplNr` ist und deren Lieferant ein Direct-Fulfillment-Lieferant ist. Ist `SupplNr` leer (nur möglich, wenn Vollzugriff ohne Secret erlaubt ist), werden Positionen aller Lieferanten geliefert.\n- Positionen werden ausgeschlossen, wenn die Lieferadresse gesperrt ist (`ASLocked = 'Y'`) oder der Kunde gesperrt ist (`SLocked = 'Y'`).\n- Positionen ohne passende Rechnungsadresse, Kunde, Auftragskopf oder Währung werden nicht geliefert (Inner Joins).\n\n**Artikeldaten**\n\nDer Artikel wird aus `Items` gelesen; der lieferantenspezifische Zusatzartikel-Datensatz in `AddItems` (passend zum Lieferanten der Position, neuester nach `UpdateDate`) liefert `ItemNrSuppl` vorrangig, während `EANUPC` zuerst vom Artikel und nur ersatzweise aus `AddItems` stammt.\n\nDas Ergebnis ist `DISTINCT` und hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNR` | int | Ja | Pixi-Auftragsnummer, deren Positionen geliefert werden. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer des Direct-Fulfillment-Lieferanten. Dient der Berechtigung und schränkt die Positionen auf diesen Lieferanten ein. Leerer String wird als NULL behandelt. |\n| `Secret` | varchar(20) | Nein | Secret des Lieferanten; muss mit der beim Lieferanten hinterlegten `CustNr` übereinstimmen. Leerer String wird als NULL behandelt. |\n| `AllOrderlines` | bit | Nein | Steuert, ob bereits bestätigte Positionen enthalten sind. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können geliefert werden.\n- Das `Secret` wird mit dem Feld `CustNr` des Lieferanten verglichen (die Kundennummer von Pixi beim Lieferanten).\n- Ist die Einstellung `DFAPIAllowFullAccessWithoutSecret` ungleich `0`, ist die Secret-Prüfung faktisch abgeschaltet: Jeder Aufrufer erhält Daten, bei leerer `SupplNr` sogar die Positionen aller Lieferanten des Auftrags.\n- Der Aufruf ist rein lesend: `ClientNotified` wird nicht gesetzt. Das Bestätigen von Positionen erfordert einen separaten Aufruf; die Spalte `OrderlineConfirmed` zeigt nur den aktuellen Wert.\n- Die Fehlerzeile hat andere Spalten (`Error`, `ErrorMsg`) als die Datenzeilen; Clients müssen prüfen, welche Spalten vorhanden sind.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFGetOrderlines_new"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Direct-Fulfillment-Auftragspositionen (Status FUT) eines Auftrags für einen berechtigten Streckenlieferanten inklusive Artikel-, Historien- und Währungsdaten.\n\nSchnittstellenaufruf für Direct-Fulfillment-Lieferanten (Streckengeschäft), um die zu erfüllenden Positionen eines einzelnen Auftrags abzurufen.\n\n**Berechtigung**\n\n1. Leere Strings in `SupplNr` und `Secret` werden als `NULL` behandelt.\n2. In `Suppliers` wird ein Lieferant gesucht, dessen `SupplNr` gleich `SupplNr` und dessen `CustNr` gleich `Secret` ist, der nicht deaktiviert ist und `CanDoDirectFulfillment = 1` hat.\n3. Wird kein solcher Lieferant gefunden und ist die Einstellung `DFAPIAllowFullAccessWithoutSecret` gleich `0` (oder nicht vorhanden), wird ausschließlich eine Fehlerzeile mit `Error = 403` geliefert.\n4. Andernfalls werden die Auftragspositionen geliefert.\n\n**Auswahl der Positionen**\n\n- Nur Positionen des Auftrags `OrderNR` mit Positionsstatus `FUT`.\n- Jede Position wird mit ihrem neuesten `OrderHistory`-Eintrag mit Status `FUT` verknüpft; dieser Status muss in `OrderStates` ein Fulfillment-Status sein (`FulfilmentStatus = 'Y'`).\n- Standardmäßig werden nur noch nicht bestätigte Positionen geliefert (`ClientNotified = 'N'`); mit `AllOrderlines = 1` auch bereits bestätigte.\n- Ist `SupplNr` angegeben, werden nur Positionen geliefert, deren `SupplInfo` gleich `SupplNr` ist und deren Lieferant ein Direct-Fulfillment-Lieferant ist. Ist `SupplNr` leer (nur möglich, wenn Vollzugriff ohne Secret erlaubt ist), werden Positionen aller Lieferanten geliefert.\n- Positionen werden ausgeschlossen, wenn die Lieferadresse gesperrt ist (`ASLocked = 'Y'`) oder der Kunde gesperrt ist (`SLocked = 'Y'`).\n- Positionen ohne passende Rechnungsadresse, Kunde, Auftragskopf oder Währung werden nicht geliefert (Inner Joins).\n\n**Artikeldaten**\n\nDer Artikel wird aus `Items` gelesen; der lieferantenspezifische Zusatzartikel-Datensatz in `AddItems` (passend zum Lieferanten der Position, neuester nach `UpdateDate`) liefert `ItemNrSuppl` vorrangig, während `EANUPC` zuerst vom Artikel und nur ersatzweise aus `AddItems` stammt.\n\nDas Ergebnis ist `DISTINCT` und hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNR` | int | Ja | Pixi-Auftragsnummer, deren Positionen geliefert werden. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer des Direct-Fulfillment-Lieferanten. Dient der Berechtigung und schränkt die Positionen auf diesen Lieferanten ein. Leerer String wird als NULL behandelt. |\n| `Secret` | varchar(20) | Nein | Secret des Lieferanten; muss mit der beim Lieferanten hinterlegten `CustNr` übereinstimmen. Leerer String wird als NULL behandelt. |\n| `AllOrderlines` | bit | Nein | Steuert, ob bereits bestätigte Positionen enthalten sind. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können geliefert werden.\n- Das `Secret` wird mit dem Feld `CustNr` des Lieferanten verglichen (die Kundennummer von Pixi beim Lieferanten).\n- Ist die Einstellung `DFAPIAllowFullAccessWithoutSecret` ungleich `0`, ist die Secret-Prüfung faktisch abgeschaltet: Jeder Aufrufer erhält Daten, bei leerer `SupplNr` sogar die Positionen aller Lieferanten des Auftrags.\n- Der Aufruf ist rein lesend: `ClientNotified` wird nicht gesetzt. Das Bestätigen von Positionen erfordert einen separaten Aufruf; die Spalte `OrderlineConfirmed` zeigt nur den aktuellen Wert.\n- Die Fehlerzeile hat andere Spalten (`Error`, `ErrorMsg`) als die Datenzeilen; Clients müssen prüfen, welche Spalten vorhanden sind.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFGetOrderlines_new"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 587341\n 104523\n Gartenstuhl Teak natur\n 4012345678901\n GS-TK-100\n SHOP-55821\n 2\n 89.90\n FUT\n 2210457\n 2024-05-14T09:12:33\n 2024-05-13T18:47:02\n 400017722\n \n DF01\n \n 1\n 33012\n N\n EUR\n \n GS100\n \n"
}
]
},
{
"name": "pixiDFGetOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Auftragsköpfe mit Lieferadressdaten der Aufträge, die offene Direct-Fulfillment-Auftragspositionen (Status FUT) für einen Lieferanten enthalten.\n\nTeil der Direct-Fulfillment-API (DF): Ein Lieferant ruft die Aufträge ab, die er direkt an den Kunden versenden soll.\n\n**Authentifizierung**\n\n- Die Einstellung `DFAPIAllowFullAccessWithoutSecret` wird gelesen. Ist sie nicht `1`, wird der Lieferant über `SupplNr` zusammen mit `Secret` identifiziert; `Secret` muss der `CustNr` des Lieferanten (Kundennummer beim Lieferanten) entsprechen.\n- Der Lieferant muss existieren, darf nicht deaktiviert sein und muss `CanDoDirectFulfillment = 1` haben.\n- Kann der Lieferant nicht identifiziert werden und ist die Einstellung nicht `1`, wird eine einzelne Fehlerzeile mit `Error = 403` zurückgegeben.\n- Ist die Einstellung `1`, wird das Secret nicht geprüft. Eine angegebene `SupplNr` muss trotzdem einem aktiven DF-Lieferanten entsprechen, sonst wird eine Fehlerzeile geliefert. Wird `SupplNr` weggelassen (oder `0`), werden die Aufträge **aller** Lieferanten geliefert.\n\n**Auftragsauswahl**\n\nEin Auftrag wird geliefert, wenn er mindestens eine Auftragsposition hat, die\n\n- den Status `FUT` hat,\n- dem Lieferanten zugeordnet ist (`SupplInfo`), außer wenn kein Lieferant gesetzt ist (Vollzugriff), und\n- `ClientNotified = 'N'` hat (noch nicht übertragen), außer bei `AllOrders = 1`.\n\nAufträge mit gesperrter Lieferadresse oder gesperrtem Kunden werden ausgeschlossen. Nur Aufträge mit vorhandenem Kunden, Rechnungsadresse, Lieferadresse, Land und Währung werden geliefert (Inner Joins).\n\nDas Ergebnis enthält eine Zeile pro Auftrag, sortiert nach `OrderNr`. `AddrShopID` und `APayment` stammen aus der Rechnungsadresse, alle anderen Adressfelder aus der Lieferadresse.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer des Direct-Fulfillment-Lieferanten. Erforderlich, außer die Einstellung `DFAPIAllowFullAccessWithoutSecret` ist `1`; dann liefert das Weglassen die Aufträge aller Lieferanten. |\n| `Secret` | varchar(20) | Nein | Secret des Lieferanten; muss der `CustNr` des Lieferanten entsprechen. Wird ignoriert, wenn `DFAPIAllowFullAccessWithoutSecret` `1` ist. |\n| `AllOrders` | bit | Nein | Steuert, ob bereits übermittelte Auftragspositionen berücksichtigt werden. NULL wird als 0 behandelt. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Der Aufruf markiert die Aufträge nicht als übertragen; `ClientNotified` wird hier nicht geändert. Ohne `AllOrders = 1` werden dieselben Aufträge erneut geliefert, bis ein anderer Prozess die Auftragspositionen aktualisiert.\n- Bei einem Authentifizierungsfehler wird nur die Fehlerzeile geliefert (Rückgabewert 1), keine Auftragsdaten.\n- Ist `DFAPIAllowFullAccessWithoutSecret = 1` und wird keine `SupplNr` angegeben, werden die Aufträge aller Lieferanten offengelegt; diese Einstellung sollte mit Bedacht eingesetzt werden.\n- Die Auftragshistorie wird in der Positionsprüfung verknüpft, der Historienfilter ist jedoch auskommentiert und hat keinen Einfluss auf das Ergebnis.\n- Eine temporäre Tabelle wird über `util.TempTableDrop` angelegt bzw. gelöscht (Definition nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFGetOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Auftragsköpfe mit Lieferadressdaten der Aufträge, die offene Direct-Fulfillment-Auftragspositionen (Status FUT) für einen Lieferanten enthalten.\n\nTeil der Direct-Fulfillment-API (DF): Ein Lieferant ruft die Aufträge ab, die er direkt an den Kunden versenden soll.\n\n**Authentifizierung**\n\n- Die Einstellung `DFAPIAllowFullAccessWithoutSecret` wird gelesen. Ist sie nicht `1`, wird der Lieferant über `SupplNr` zusammen mit `Secret` identifiziert; `Secret` muss der `CustNr` des Lieferanten (Kundennummer beim Lieferanten) entsprechen.\n- Der Lieferant muss existieren, darf nicht deaktiviert sein und muss `CanDoDirectFulfillment = 1` haben.\n- Kann der Lieferant nicht identifiziert werden und ist die Einstellung nicht `1`, wird eine einzelne Fehlerzeile mit `Error = 403` zurückgegeben.\n- Ist die Einstellung `1`, wird das Secret nicht geprüft. Eine angegebene `SupplNr` muss trotzdem einem aktiven DF-Lieferanten entsprechen, sonst wird eine Fehlerzeile geliefert. Wird `SupplNr` weggelassen (oder `0`), werden die Aufträge **aller** Lieferanten geliefert.\n\n**Auftragsauswahl**\n\nEin Auftrag wird geliefert, wenn er mindestens eine Auftragsposition hat, die\n\n- den Status `FUT` hat,\n- dem Lieferanten zugeordnet ist (`SupplInfo`), außer wenn kein Lieferant gesetzt ist (Vollzugriff), und\n- `ClientNotified = 'N'` hat (noch nicht übertragen), außer bei `AllOrders = 1`.\n\nAufträge mit gesperrter Lieferadresse oder gesperrtem Kunden werden ausgeschlossen. Nur Aufträge mit vorhandenem Kunden, Rechnungsadresse, Lieferadresse, Land und Währung werden geliefert (Inner Joins).\n\nDas Ergebnis enthält eine Zeile pro Auftrag, sortiert nach `OrderNr`. `AddrShopID` und `APayment` stammen aus der Rechnungsadresse, alle anderen Adressfelder aus der Lieferadresse.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer des Direct-Fulfillment-Lieferanten. Erforderlich, außer die Einstellung `DFAPIAllowFullAccessWithoutSecret` ist `1`; dann liefert das Weglassen die Aufträge aller Lieferanten. |\n| `Secret` | varchar(20) | Nein | Secret des Lieferanten; muss der `CustNr` des Lieferanten entsprechen. Wird ignoriert, wenn `DFAPIAllowFullAccessWithoutSecret` `1` ist. |\n| `AllOrders` | bit | Nein | Steuert, ob bereits übermittelte Auftragspositionen berücksichtigt werden. NULL wird als 0 behandelt. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Der Aufruf markiert die Aufträge nicht als übertragen; `ClientNotified` wird hier nicht geändert. Ohne `AllOrders = 1` werden dieselben Aufträge erneut geliefert, bis ein anderer Prozess die Auftragspositionen aktualisiert.\n- Bei einem Authentifizierungsfehler wird nur die Fehlerzeile geliefert (Rückgabewert 1), keine Auftragsdaten.\n- Ist `DFAPIAllowFullAccessWithoutSecret = 1` und wird keine `SupplNr` angegeben, werden die Aufträge aller Lieferanten offengelegt; diese Einstellung sollte mit Bedacht eingesetzt werden.\n- Die Auftragshistorie wird in der Positionsprüfung verknüpft, der Historienfilter ist jedoch auskommentiert und hat keinen Einfluss auf das Ergebnis.\n- Eine temporäre Tabelle wird über `util.TempTableDrop` angelegt bzw. gelöscht (Definition nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFGetOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 100234\n Herr\n Max\n Mustermann\n Hauptstraße\n 80331\n 12\n München\n D\n max@example.com\n 089123456\n 2024-05-14T00:00:00\n DHL\n SH1\n RE\n N\n 0.00\n DE\n DEU\n 4.90\n 0\n 0\n 0\n EUR\n Webshop\n \n"
}
]
},
{
"name": "pixiDFSetStatus",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 784512FUS22024-05-14T10:30:0000340434161094042557RE-2024-0815B2024-172025-12-31SN-000123]]>\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt den Direct-Fulfillment-Status von Auftragspositionen anhand einer XML-Liste von OrderHistory-Schlüsseln und legt optional anschließend DF-Rechnungen an.\n\nWird von Direct-Fulfillment-Lieferanten genutzt, um den Bearbeitungsstand von Auftragspositionen (versendet, storniert, nicht lieferbar) zusammen mit Versanddatum, Tracking-ID, externer Rechnungsnummer, Charge, MHD und Seriennummer zurückzumelden.\n\n**Ablauf**\n\n1. **Authentifizierung:** Es wird ein Lieferant in `Suppliers` mit `SupplNr` = `@SupplNr`, `CustNr` = `@Secret`, nicht deaktiviert und `CanDoDirectFulfillment = 1` gesucht. Wird keiner gefunden und ist die Einstellung `DFAPIAllowFullAccessWithoutSecret` `0` oder nicht vorhanden, bricht der Aufruf mit der Meldung `403 Not Authorized…` ab und liefert keine Zeilen.\n2. **XML-Auswertung:** Alle Elemente `/SETDFSTATUS/ITEM` (elementbasiert) werden in eine Arbeitstabelle gelesen. Fehlende `ERROR`/`ERRORMSG` werden mit `200`/leer belegt.\n3. **Duplikatprüfung:** Kommt derselbe `ORDERHISTORYKEY` mehrfach mit demselben `STATUS` vor, wird `500 Duplicate Orderhistorykey and Status.` ausgelöst und nichts geändert.\n4. **Verarbeitung je Eintrag** (in einer Transaktion): Die Auftragsposition wird über `OrderHistory.OrderHistKey` → `OrderLineRef` ermittelt, danach wird die interne Prozedur `Pixi_UpdateOrderlineDFStatusByOrderlineKey` ausgeführt. Diese:\n - lehnt den Eintrag ab, wenn die Auftragsposition nicht existiert, bereits im Status `FUS` oder in einem Endstatus ist, wenn `QTY` < 1 oder größer als die Positionsmenge ist, oder wenn Charge/MHD für Artikel mit den entsprechenden System-Tags fehlen (nur bei aktiver Einstellung `DFRequiredDataForSystemTags`);\n - teilt die Auftragsposition, wenn `QTY` kleiner als die aktuelle Menge ist (die gemeldete Menge bleibt auf der ursprünglichen Position, der Rest geht auf eine neue Position im alten Status);\n - setzt den Status: `STO` → `STO`, `NLB` → `NLB`, jeder andere Wert → `FUS` bei DF-Typ 1, 3 oder leer, sonst `BES` (dann wird eine Reservierung für den Auftrag angelegt);\n - aktualisiert die Auftragsposition mit Status, Versanddatum, Tracking-ID, externer Rechnungsnummer, Charge, MHD und Seriennummer (`UpdateEmp` = `DF API`).\n5. Der Ergebnistext je Eintrag wird in `ERRORMSG` geschrieben; `ERROR` wird `500`, wenn der Text `error` enthält, sonst `200`. Jeder Eintrag wird zusätzlich in `LogTable` protokolliert.\n6. Alle Einträge werden als eine Ergebnismenge zurückgegeben und die Transaktion wird festgeschrieben.\n7. Ist `@CreateInvoices` = `Y`, wird anschließend `pipiDFCreateInvoices` ohne Parameter ausgeführt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | Ja | XML-Dokument mit einem `ITEM` je Statusmeldung unter dem Wurzelelement `SETDFSTATUS`. Elemente: `ORDERHISTORYKEY`, `STATUS` (`STO` = Storno, `NLB` = nicht lieferbar, andere Werte = bearbeitet/versendet), `QTY`, `SHIPDATE`, `TRACKINGID`, `INVOICENREXTERNAL`, `BATCHNUMBER`, `BESTBEFOREDATE`, `SERIALNUMBER`; `ERROR`/`ERRORMSG` werden gelesen, aber durch das Ergebnis überschrieben. |\n| `CreateInvoices` | varchar(1) | Nein | Bei `Y` wird nach erfolgreichem Lauf `pipiDFCreateInvoices` ausgeführt. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer des Direct-Fulfillment-Lieferanten, dient der Authentifizierung. |\n| `Secret` | varchar(20) | Nein | Geheimwert des Lieferanten; wird mit `Suppliers.CustNr` verglichen. Kann nur entfallen, wenn die Einstellung `DFAPIAllowFullAccessWithoutSecret` aktiv ist. |\n\n- **Teilverarbeitung:** Fehler bei einzelnen Einträgen machen die übrigen Einträge nicht rückgängig. Der interne Fehlerzähler wird nie erhöht, die Transaktion wird also immer festgeschrieben; `ERROR` muss je Zeile geprüft werden.\n- `@SupplNr`/`@Secret` dienen nur der Authentifizierung. Der Code prüft **nicht**, ob die Auftragspositionen zu diesem Lieferanten gehören.\n- Die 403-Meldung wird mit Schweregrad 0 ausgelöst, also als Informationsmeldung und nicht als SQL-Fehler. Clients müssen sie explizit auswerten, wenn keine Zeilen zurückkommen.\n- `STATUS` wird mit bis zu 13 Zeichen gelesen, aber als `varchar(3)` verarbeitet; längere Werte werden abgeschnitten, und die Ergebniszeile wird dann eventuell nicht aktualisiert (bleibt bei `ERROR` `200`).\n- Versanddatum, Tracking-ID und externe Rechnungsnummer werden immer überschrieben; fehlende Elemente setzen diese Felder auf NULL. Charge, MHD und Seriennummer behalten bei leerem Wert ihren bisherigen Inhalt.\n- `BESTBEFOREDATE` wird implizit in ein Datum umgewandelt; ungültige Werte führen zu einer Ausnahme.\n- Bei einer Ausnahme wird die Transaktion zurückgerollt, der Fehler über `log.InsertError` protokolliert und keine Ergebnismenge geliefert. Fehler, die in der internen Prozedur abgefangen werden, erscheinen ggf. nicht in `ERROR`.\n- Treffen mehrere Fehlerbedingungen auf einen Eintrag zu, wird nur die zuletzt gesetzte Meldung geliefert.\n- `@CreateInvoices = 'Y'` führt `pipiDFCreateInvoices` für **alle** zur Rechnungsstellung bereiten DF-Auftragspositionen aus, nicht nur für die dieses Aufrufs; dies geschieht nach dem Commit und liefert keine Zeilen. Die eigentliche Rechnungserstellung (`Pixi_CreateFulfillmentIncoices`) liegt nicht vor.\n- Lesezugriffe verwenden `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFSetStatus"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 784512FUS22024-05-14T10:30:0000340434161094042557RE-2024-0815B2024-172025-12-31SN-000123]]>\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt den Direct-Fulfillment-Status von Auftragspositionen anhand einer XML-Liste von OrderHistory-Schlüsseln und legt optional anschließend DF-Rechnungen an.\n\nWird von Direct-Fulfillment-Lieferanten genutzt, um den Bearbeitungsstand von Auftragspositionen (versendet, storniert, nicht lieferbar) zusammen mit Versanddatum, Tracking-ID, externer Rechnungsnummer, Charge, MHD und Seriennummer zurückzumelden.\n\n**Ablauf**\n\n1. **Authentifizierung:** Es wird ein Lieferant in `Suppliers` mit `SupplNr` = `@SupplNr`, `CustNr` = `@Secret`, nicht deaktiviert und `CanDoDirectFulfillment = 1` gesucht. Wird keiner gefunden und ist die Einstellung `DFAPIAllowFullAccessWithoutSecret` `0` oder nicht vorhanden, bricht der Aufruf mit der Meldung `403 Not Authorized…` ab und liefert keine Zeilen.\n2. **XML-Auswertung:** Alle Elemente `/SETDFSTATUS/ITEM` (elementbasiert) werden in eine Arbeitstabelle gelesen. Fehlende `ERROR`/`ERRORMSG` werden mit `200`/leer belegt.\n3. **Duplikatprüfung:** Kommt derselbe `ORDERHISTORYKEY` mehrfach mit demselben `STATUS` vor, wird `500 Duplicate Orderhistorykey and Status.` ausgelöst und nichts geändert.\n4. **Verarbeitung je Eintrag** (in einer Transaktion): Die Auftragsposition wird über `OrderHistory.OrderHistKey` → `OrderLineRef` ermittelt, danach wird die interne Prozedur `Pixi_UpdateOrderlineDFStatusByOrderlineKey` ausgeführt. Diese:\n - lehnt den Eintrag ab, wenn die Auftragsposition nicht existiert, bereits im Status `FUS` oder in einem Endstatus ist, wenn `QTY` < 1 oder größer als die Positionsmenge ist, oder wenn Charge/MHD für Artikel mit den entsprechenden System-Tags fehlen (nur bei aktiver Einstellung `DFRequiredDataForSystemTags`);\n - teilt die Auftragsposition, wenn `QTY` kleiner als die aktuelle Menge ist (die gemeldete Menge bleibt auf der ursprünglichen Position, der Rest geht auf eine neue Position im alten Status);\n - setzt den Status: `STO` → `STO`, `NLB` → `NLB`, jeder andere Wert → `FUS` bei DF-Typ 1, 3 oder leer, sonst `BES` (dann wird eine Reservierung für den Auftrag angelegt);\n - aktualisiert die Auftragsposition mit Status, Versanddatum, Tracking-ID, externer Rechnungsnummer, Charge, MHD und Seriennummer (`UpdateEmp` = `DF API`).\n5. Der Ergebnistext je Eintrag wird in `ERRORMSG` geschrieben; `ERROR` wird `500`, wenn der Text `error` enthält, sonst `200`. Jeder Eintrag wird zusätzlich in `LogTable` protokolliert.\n6. Alle Einträge werden als eine Ergebnismenge zurückgegeben und die Transaktion wird festgeschrieben.\n7. Ist `@CreateInvoices` = `Y`, wird anschließend `pipiDFCreateInvoices` ohne Parameter ausgeführt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | Ja | XML-Dokument mit einem `ITEM` je Statusmeldung unter dem Wurzelelement `SETDFSTATUS`. Elemente: `ORDERHISTORYKEY`, `STATUS` (`STO` = Storno, `NLB` = nicht lieferbar, andere Werte = bearbeitet/versendet), `QTY`, `SHIPDATE`, `TRACKINGID`, `INVOICENREXTERNAL`, `BATCHNUMBER`, `BESTBEFOREDATE`, `SERIALNUMBER`; `ERROR`/`ERRORMSG` werden gelesen, aber durch das Ergebnis überschrieben. |\n| `CreateInvoices` | varchar(1) | Nein | Bei `Y` wird nach erfolgreichem Lauf `pipiDFCreateInvoices` ausgeführt. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer des Direct-Fulfillment-Lieferanten, dient der Authentifizierung. |\n| `Secret` | varchar(20) | Nein | Geheimwert des Lieferanten; wird mit `Suppliers.CustNr` verglichen. Kann nur entfallen, wenn die Einstellung `DFAPIAllowFullAccessWithoutSecret` aktiv ist. |\n\n- **Teilverarbeitung:** Fehler bei einzelnen Einträgen machen die übrigen Einträge nicht rückgängig. Der interne Fehlerzähler wird nie erhöht, die Transaktion wird also immer festgeschrieben; `ERROR` muss je Zeile geprüft werden.\n- `@SupplNr`/`@Secret` dienen nur der Authentifizierung. Der Code prüft **nicht**, ob die Auftragspositionen zu diesem Lieferanten gehören.\n- Die 403-Meldung wird mit Schweregrad 0 ausgelöst, also als Informationsmeldung und nicht als SQL-Fehler. Clients müssen sie explizit auswerten, wenn keine Zeilen zurückkommen.\n- `STATUS` wird mit bis zu 13 Zeichen gelesen, aber als `varchar(3)` verarbeitet; längere Werte werden abgeschnitten, und die Ergebniszeile wird dann eventuell nicht aktualisiert (bleibt bei `ERROR` `200`).\n- Versanddatum, Tracking-ID und externe Rechnungsnummer werden immer überschrieben; fehlende Elemente setzen diese Felder auf NULL. Charge, MHD und Seriennummer behalten bei leerem Wert ihren bisherigen Inhalt.\n- `BESTBEFOREDATE` wird implizit in ein Datum umgewandelt; ungültige Werte führen zu einer Ausnahme.\n- Bei einer Ausnahme wird die Transaktion zurückgerollt, der Fehler über `log.InsertError` protokolliert und keine Ergebnismenge geliefert. Fehler, die in der internen Prozedur abgefangen werden, erscheinen ggf. nicht in `ERROR`.\n- Treffen mehrere Fehlerbedingungen auf einen Eintrag zu, wird nur die zuletzt gesetzte Meldung geliefert.\n- `@CreateInvoices = 'Y'` führt `pipiDFCreateInvoices` für **alle** zur Rechnungsstellung bereiten DF-Auftragspositionen aus, nicht nur für die dieses Aufrufs; dies geschieht nach dem Commit und liefert keine Zeilen. Die eigentliche Rechnungserstellung (`Pixi_CreateFulfillmentIncoices`) liegt nicht vor.\n- Lesezugriffe verwenden `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFSetStatus"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 784512\n FUS\n 2\n 2024-05-14T10:30:00\n 00340434161094042557\n RE-2024-0815\n B2024-17\n 2025-12-31\n SN-000123\n 200\n \n \n \n 784513\n STO\n 500\n ERROR: Orderline was already processed.\n \n"
}
]
},
{
"name": "pixiDFSetSupplierNotifiedFlag",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder entfernt das Benachrichtigt-Kennzeichen (`ClientNotified`) am letzten `FUT`-Historieneintrag der Auftragspositionen eines Auftrags oder einer einzelnen Position.\n\nKennzeichnet Auftragspositionen im Direct-Fulfillment-Prozess (Streckengeschäft) als an den Lieferanten gemeldet bzw. nicht gemeldet.\n\n1. Kandidaten werden aus `Orderlines` ermittelt, bei denen `OrderlineKey = @OrderlineKey` **oder** `OrderNr = @OrderNr` gilt. Positionen mit Status `HAL` werden ausgeschlossen.\n2. Für jeden Kandidaten wird geprüft, ob er bearbeitbar ist: Eine Position ist nur bearbeitbar, wenn sie **keinen** Eintrag in `OrderHistory` mit einem Status außerhalb von `HAL`, `ANG`, `BES`, `FUT`, `NEW` besitzt. Positionen mit einem anderen Historienstatus werden übersprungen.\n3. Für jede bearbeitbare Position wird der `OrderHistory`-Eintrag mit dem höchsten `OrderHistKey` unter ihren Einträgen mit Status `FUT` aktualisiert: `ClientNotified` wird auf `Y` gesetzt, wenn `@IsNotified = 1`, sonst auf `N`.\n\nPositionen ohne `FUT`-Historieneintrag bleiben unverändert. Der Aufruf liefert keine Ergebnismenge und keine Statuszeile.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Schlüssel einer einzelnen zu verarbeitenden Auftragsposition. Mit `OrderNr` per ODER verknüpft. |\n| `OrderNr` | int | Nein | Auftragsnummer; alle Positionen dieses Auftrags (außer Status `HAL`) werden verarbeitet. Mit `OrderlineKey` per ODER verknüpft. |\n| `IsNotified` | bit | Nein | Zu setzender Wert des Benachrichtigt-Kennzeichens. |\n\n- Die beiden Filterparameter werden mit `OR` verknüpft: Werden beide übergeben, werden Positionen verarbeitet, die entweder zum Positionsschlüssel oder zur Auftragsnummer passen. Wird keiner übergeben, wird nichts aktualisiert.\n- Die Prüfung `IF @IsNotified = NULL` ist bei Standardeinstellung von `ANSI_NULLS` nie wahr. Wird `IsNotified` explizit als NULL übergeben, greift daher **nicht** der Wert 1; das Kennzeichen wird auf `N` gesetzt. Für den Standardwert 1 den Parameter weglassen.\n- Trotz des Aufrufnamens wird die Spalte `OrderHistory.ClientNotified` geschrieben.\n- Es gibt keine Rückmeldung über die Anzahl aktualisierter Zeilen (`SET NOCOUNT ON`, keine Ergebnismenge); ob eine Position als nicht bearbeitbar übersprungen wurde, ist für den Aufrufer nicht erkennbar.\n- Die Kandidatenermittlung liest mit `NOLOCK`; das Update verwendet `ROWLOCK`. Keine explizite Transaktion.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFSetSupplierNotifiedFlag"
},
"response": []
},
{
"name": "pixiDFUpdateOrderlineStatus",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n L001\n K4711\n FUS\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt den Direct-Fulfillment-Status einer Auftragsposition für einen authentifizierten Lieferanten, optional mit Versanddatum, Tracking-ID, Rechnungsnummer, Teilmenge und Chargendaten.\n\nAPI-Aufruf, mit dem Direct-Fulfillment-Lieferanten den Bearbeitungsstand einer Auftragsposition an Pixi zurückmelden.\n\n**1. Authentifizierung**\n- Der Lieferant wird in `Suppliers` über `SupplNr` gesucht; `Secret` muss der `CustNr` des Lieferanten entsprechen, der Lieferant darf nicht deaktiviert sein und muss `CanDoDirectFulfillment = 1` haben.\n- Wird kein Lieferant gefunden und ist die Einstellung `DFAPIAllowFullAccessWithoutSecret` gleich `0` (oder nicht vorhanden), wird eine Zeile mit `Error = '403'` geliefert und nichts geändert.\n- Ist diese Einstellung ungleich `0`, läuft der Aufruf auch mit falschem Secret weiter.\n\n**2. Ermitteln der Auftragsposition**\n- Ist `OrderlineRef` kleiner als 1 (Standard), wird der Positionsschlüssel über `OrderHistoryKey` aus `OrderHistory` gelesen.\n- Leere Zeichenketten in `BatchNumber`, `BestBeforeDate` und `SerialNumber` werden als NULL behandelt.\n\n**3. Prüfungen** (in der internen Prozedur `Pixi_UpdateOrderlineDFStatusByOrderlineKey`). Die Aktualisierung wird abgelehnt, wenn:\n- die Auftragsposition nicht existiert;\n- die Einstellung `DFRequiredDataForSystemTags` aktiv ist und der Artikel das System-Tag für Chargennummer (Tag `-6`) und/oder Mindesthaltbarkeitsdatum (Tag `-7`) trägt, der entsprechende Wert aber fehlt;\n- `Qty` kleiner als 1 oder größer als die aktuelle Positionsmenge ist;\n- die Position bereits den Status `FUS` oder einen in `OrderStates` als final markierten Status hat.\n\n**4. Aktualisierung**\n- Ist `Qty` kleiner als die aktuelle Menge, wird die Position zuerst geteilt: Die ursprüngliche Position behält `Qty`, eine neue Position mit der Restmenge wird mit dem alten Status angelegt.\n- Der neue Status ergibt sich aus `Status`: `STO` und `NLB` werden unverändert übernommen; jeder andere Wert führt bei DF-Typ 1, 3 oder ohne DF-Typ zu `FUS`, sonst zu `BES`.\n- Die Position erhält den neuen Status, `DFShipDate`, `DFShipmentTrackingID` (aus `DFTrackingID`), `InvoiceNrExternal`, Chargennummer, Mindesthaltbarkeitsdatum, Seriennummer, `UpdateDate` und `UpdateEmp = 'DF API'`.\n- Ist der resultierende Status `BES`, wird eine Reservierung für den gesamten Auftrag angelegt.\n\n**5. Antwort**\nEine Zeile mit `Error` (`200` oder `500`) und `ErrorMsg`. `500` wird geliefert, wenn die Meldung das Wort `error` enthält. Bei Erfolg ist `ErrorMsg` leer oder enthält die Info zur Teilung. Jeder Aufruf nach erfolgreicher Authentifizierung schreibt eine Zeile in `LogTable`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Ja | Lieferantennummer des Direct-Fulfillment-Lieferanten. |\n| `Secret` | varchar(20) | Ja | Secret des Lieferanten; muss der beim Lieferanten hinterlegten `CustNr` entsprechen. |\n| `Status` | varchar(3) | Ja | Gewünschter Status. `STO` und `NLB` werden unverändert gesetzt; jeder andere Wert setzt `FUS` (DF-Typ 1, 3 oder keiner) bzw. `BES` (andere DF-Typen). |\n| `OrderHistoryKey` | int | Nein | Schlüssel des `OrderHistory`-Eintrags; dient zur Ermittlung der Position, wenn `OrderlineRef` nicht angegeben ist. |\n| `DFShipDate` | datetime | Nein | Vom Lieferanten gemeldetes Versanddatum; wird in `DFShipDate` gespeichert (bei Weglassen mit NULL überschrieben). |\n| `DFTrackingID` | varchar(100) | Nein | Sendungsverfolgungsnummer; wird in `DFShipmentTrackingID` gespeichert (bei Weglassen mit NULL überschrieben). |\n| `Qty` | int | Nein | Bearbeitete Menge. Muss zwischen 1 und der aktuellen Positionsmenge liegen; ein kleinerer Wert teilt die Position. NULL behält die volle Menge. |\n| `InvoiceNrExternal` | varchar(20) | Nein | Rechnungsnummer des Lieferanten; wird in `InvoiceNrExternal` gespeichert (bei Weglassen mit NULL überschrieben). |\n| `OrderlineRef` | int | Nein | Schlüssel der Auftragsposition (`OrderlineKey`). Ist er kleiner als 1, wird er über `OrderHistoryKey` ermittelt. |\n| `BatchNumber` | varchar(50) | Nein | Chargennummer. Pflicht, wenn der Artikel das Chargen-System-Tag trägt und `DFRequiredDataForSystemTags` aktiv ist; bei Weglassen bleibt der bisherige Wert erhalten. |\n| `BestBeforeDate` | datetime | Nein | Mindesthaltbarkeitsdatum. Pflicht, wenn der Artikel das MHD-System-Tag trägt und `DFRequiredDataForSystemTags` aktiv ist; bei Weglassen bleibt der bisherige Wert erhalten. |\n| `SerialNumber` | varchar(50) | Nein | Seriennummer; wird in `SerialNr` gespeichert. Bei Weglassen bleibt der bisherige Wert erhalten. |\n\n- Der Aufruf prüft **nicht**, ob die Auftragsposition zum authentifizierten Lieferanten gehört; jeder Positionsschlüssel kann angesprochen werden.\n- `DFShipDate`, `DFTrackingID` und `InvoiceNrExternal` werden immer geschrieben; fehlen sie, werden vorhandene Werte mit NULL überschrieben. `BatchNumber`, `BestBeforeDate` und `SerialNumber` behalten ihre bisherigen Werte, wenn sie nicht übergeben werden.\n- Prüfmeldungen überschreiben sich gegenseitig; gemeldet wird nur die zuletzt fehlgeschlagene Prüfung.\n- Die Fehlererkennung basiert auf `CHARINDEX('error', ErrorMsg)`; für die großgeschriebenen `ERROR:`-Meldungen funktioniert das nur bei einer nicht case-sensitiven Datenbank-Collation.\n- Laufzeitfehler während der Aktualisierung werden abgefangen, zurückgerollt und über `log.InsertError` protokolliert, ändern aber `ErrorMsg` nicht; die Antwort kann daher `200` mit leerer oder INFO-Meldung sein, obwohl nichts gespeichert wurde. Im Zweifel die Position anschließend prüfen.\n- Die Prüfung auf eine fehlgeschlagene Reservierung (`ERROR: Error Creating Reservation`) liest `@@ERROR` nach einer `SET`-Anweisung und greift daher praktisch nie.\n- Die Verarbeitung läuft in einer eigenen Transaktion bzw. einem Savepoint innerhalb einer bestehenden Transaktion. Lesezugriffe verwenden `NOLOCK`.\n- Das Verhalten von `GOSBreakOrderline`, `Pixi_Res_CreateReservationForOrder`, `dbo.SettingGet` und `log.InsertError` ist hier nicht sichtbar; diese können weitere Tabellen schreiben.\n- Ein Mindesthaltbarkeitsdatum `1900-01-01` wird wegen des Vergleichs mit `''` wie ein leerer Wert behandelt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFUpdateOrderlineStatus"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n L001\n K4711\n FUS\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt den Direct-Fulfillment-Status einer Auftragsposition für einen authentifizierten Lieferanten, optional mit Versanddatum, Tracking-ID, Rechnungsnummer, Teilmenge und Chargendaten.\n\nAPI-Aufruf, mit dem Direct-Fulfillment-Lieferanten den Bearbeitungsstand einer Auftragsposition an Pixi zurückmelden.\n\n**1. Authentifizierung**\n- Der Lieferant wird in `Suppliers` über `SupplNr` gesucht; `Secret` muss der `CustNr` des Lieferanten entsprechen, der Lieferant darf nicht deaktiviert sein und muss `CanDoDirectFulfillment = 1` haben.\n- Wird kein Lieferant gefunden und ist die Einstellung `DFAPIAllowFullAccessWithoutSecret` gleich `0` (oder nicht vorhanden), wird eine Zeile mit `Error = '403'` geliefert und nichts geändert.\n- Ist diese Einstellung ungleich `0`, läuft der Aufruf auch mit falschem Secret weiter.\n\n**2. Ermitteln der Auftragsposition**\n- Ist `OrderlineRef` kleiner als 1 (Standard), wird der Positionsschlüssel über `OrderHistoryKey` aus `OrderHistory` gelesen.\n- Leere Zeichenketten in `BatchNumber`, `BestBeforeDate` und `SerialNumber` werden als NULL behandelt.\n\n**3. Prüfungen** (in der internen Prozedur `Pixi_UpdateOrderlineDFStatusByOrderlineKey`). Die Aktualisierung wird abgelehnt, wenn:\n- die Auftragsposition nicht existiert;\n- die Einstellung `DFRequiredDataForSystemTags` aktiv ist und der Artikel das System-Tag für Chargennummer (Tag `-6`) und/oder Mindesthaltbarkeitsdatum (Tag `-7`) trägt, der entsprechende Wert aber fehlt;\n- `Qty` kleiner als 1 oder größer als die aktuelle Positionsmenge ist;\n- die Position bereits den Status `FUS` oder einen in `OrderStates` als final markierten Status hat.\n\n**4. Aktualisierung**\n- Ist `Qty` kleiner als die aktuelle Menge, wird die Position zuerst geteilt: Die ursprüngliche Position behält `Qty`, eine neue Position mit der Restmenge wird mit dem alten Status angelegt.\n- Der neue Status ergibt sich aus `Status`: `STO` und `NLB` werden unverändert übernommen; jeder andere Wert führt bei DF-Typ 1, 3 oder ohne DF-Typ zu `FUS`, sonst zu `BES`.\n- Die Position erhält den neuen Status, `DFShipDate`, `DFShipmentTrackingID` (aus `DFTrackingID`), `InvoiceNrExternal`, Chargennummer, Mindesthaltbarkeitsdatum, Seriennummer, `UpdateDate` und `UpdateEmp = 'DF API'`.\n- Ist der resultierende Status `BES`, wird eine Reservierung für den gesamten Auftrag angelegt.\n\n**5. Antwort**\nEine Zeile mit `Error` (`200` oder `500`) und `ErrorMsg`. `500` wird geliefert, wenn die Meldung das Wort `error` enthält. Bei Erfolg ist `ErrorMsg` leer oder enthält die Info zur Teilung. Jeder Aufruf nach erfolgreicher Authentifizierung schreibt eine Zeile in `LogTable`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Ja | Lieferantennummer des Direct-Fulfillment-Lieferanten. |\n| `Secret` | varchar(20) | Ja | Secret des Lieferanten; muss der beim Lieferanten hinterlegten `CustNr` entsprechen. |\n| `Status` | varchar(3) | Ja | Gewünschter Status. `STO` und `NLB` werden unverändert gesetzt; jeder andere Wert setzt `FUS` (DF-Typ 1, 3 oder keiner) bzw. `BES` (andere DF-Typen). |\n| `OrderHistoryKey` | int | Nein | Schlüssel des `OrderHistory`-Eintrags; dient zur Ermittlung der Position, wenn `OrderlineRef` nicht angegeben ist. |\n| `DFShipDate` | datetime | Nein | Vom Lieferanten gemeldetes Versanddatum; wird in `DFShipDate` gespeichert (bei Weglassen mit NULL überschrieben). |\n| `DFTrackingID` | varchar(100) | Nein | Sendungsverfolgungsnummer; wird in `DFShipmentTrackingID` gespeichert (bei Weglassen mit NULL überschrieben). |\n| `Qty` | int | Nein | Bearbeitete Menge. Muss zwischen 1 und der aktuellen Positionsmenge liegen; ein kleinerer Wert teilt die Position. NULL behält die volle Menge. |\n| `InvoiceNrExternal` | varchar(20) | Nein | Rechnungsnummer des Lieferanten; wird in `InvoiceNrExternal` gespeichert (bei Weglassen mit NULL überschrieben). |\n| `OrderlineRef` | int | Nein | Schlüssel der Auftragsposition (`OrderlineKey`). Ist er kleiner als 1, wird er über `OrderHistoryKey` ermittelt. |\n| `BatchNumber` | varchar(50) | Nein | Chargennummer. Pflicht, wenn der Artikel das Chargen-System-Tag trägt und `DFRequiredDataForSystemTags` aktiv ist; bei Weglassen bleibt der bisherige Wert erhalten. |\n| `BestBeforeDate` | datetime | Nein | Mindesthaltbarkeitsdatum. Pflicht, wenn der Artikel das MHD-System-Tag trägt und `DFRequiredDataForSystemTags` aktiv ist; bei Weglassen bleibt der bisherige Wert erhalten. |\n| `SerialNumber` | varchar(50) | Nein | Seriennummer; wird in `SerialNr` gespeichert. Bei Weglassen bleibt der bisherige Wert erhalten. |\n\n- Der Aufruf prüft **nicht**, ob die Auftragsposition zum authentifizierten Lieferanten gehört; jeder Positionsschlüssel kann angesprochen werden.\n- `DFShipDate`, `DFTrackingID` und `InvoiceNrExternal` werden immer geschrieben; fehlen sie, werden vorhandene Werte mit NULL überschrieben. `BatchNumber`, `BestBeforeDate` und `SerialNumber` behalten ihre bisherigen Werte, wenn sie nicht übergeben werden.\n- Prüfmeldungen überschreiben sich gegenseitig; gemeldet wird nur die zuletzt fehlgeschlagene Prüfung.\n- Die Fehlererkennung basiert auf `CHARINDEX('error', ErrorMsg)`; für die großgeschriebenen `ERROR:`-Meldungen funktioniert das nur bei einer nicht case-sensitiven Datenbank-Collation.\n- Laufzeitfehler während der Aktualisierung werden abgefangen, zurückgerollt und über `log.InsertError` protokolliert, ändern aber `ErrorMsg` nicht; die Antwort kann daher `200` mit leerer oder INFO-Meldung sein, obwohl nichts gespeichert wurde. Im Zweifel die Position anschließend prüfen.\n- Die Prüfung auf eine fehlgeschlagene Reservierung (`ERROR: Error Creating Reservation`) liest `@@ERROR` nach einer `SET`-Anweisung und greift daher praktisch nie.\n- Die Verarbeitung läuft in einer eigenen Transaktion bzw. einem Savepoint innerhalb einer bestehenden Transaktion. Lesezugriffe verwenden `NOLOCK`.\n- Das Verhalten von `GOSBreakOrderline`, `Pixi_Res_CreateReservationForOrder`, `dbo.SettingGet` und `log.InsertError` ist hier nicht sichtbar; diese können weitere Tabellen schreiben.\n- Ein Mindesthaltbarkeitsdatum `1900-01-01` wird wegen des Vergleichs mit `''` wie ein leerer Wert behandelt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDFUpdateOrderlineStatus"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 200\n INFO: Split Orderline - Updated Qty: 2, New Orderline Qty:1\n \n"
}
]
},
{
"name": "pixiSetFulfillmentOptions",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt den Direct-Fulfillment-Typ (DF_type) einer Auftragsposition oder aller Positionen eines Auftrags und setzt bearbeitbare Positionen auf Status ANG zurück.\n\nWeist Auftragspositionen einen Direct-Fulfillment-Typ zu und liefert das Ergebnis je Position zurück.\n\n1. Ist `DF_Type` gleich `0`, wird der Wert als `NULL` behandelt, d. h. der Fulfillment-Typ wird entfernt.\n2. Die zu verarbeitenden Auftragspositionen werden gesammelt:\n - `OrderlineKey` > 0: diese einzelne Position wird aufgenommen (ohne Prüfung von Status oder Existenz).\n - `OrderNr` > 0: alle Positionen dieses Auftrags, deren `Status` nicht `HAL` (angehalten) ist, werden aufgenommen.\n - Beide Parameter können kombiniert werden; ist keiner > 0, wird nichts verarbeitet und eine leere Ergebnismenge geliefert.\n3. Jede gesammelte Position wird auf Bearbeitbarkeit geprüft. Eine Position ist **nicht bearbeitbar** (`IsEditable` = 0), wenn\n - die Auftragshistorie (`OrderHistory`) einen Eintrag mit einem Status außerhalb von `HAL`, `ANG`, `BES`, `FUT`, `NEW` enthält oder einen `FUT`-Eintrag mit `ClientNotified` = `Y`, oder\n - sie auf einer Pickliste (`PLitem`/`PLHeader`) steht, deren Ablaufdatum `PLHexpiryDate` in der Zukunft liegt.\n Andernfalls ist sie bearbeitbar (`IsEditable` = 1).\n4. Für alle bearbeitbaren Positionen wird `DF_type` auf den übergebenen Wert und `Status` auf `ANG` gesetzt.\n5. Je gesammelter Position wird eine Zeile mit aktueller Auftragsnummer, Positionsschlüssel, Status, DF-Typ und Bearbeitbarkeitskennzeichen geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Schlüssel einer einzelnen zu aktualisierenden Auftragsposition. Wird bei NULL oder <= 0 ignoriert. |\n| `OrderNr` | int | Nein | Auftragsnummer; alle nicht angehaltenen (`HAL`) Positionen dieses Auftrags werden verarbeitet. Wird bei NULL oder <= 0 ignoriert. |\n| `DF_Type` | int | Nein | Direct-Fulfillment-Typ, der an den Positionen gesetzt wird. `0` oder NULL entfernt den Typ (setzt `DF_type` auf NULL). |\n\n- Die Aktualisierung läuft in einer eigenen Transaktion bzw. als Savepoint, wenn der Aufrufer bereits eine Transaktion geöffnet hat.\n- Der Status jeder bearbeitbaren Position wird unabhängig vom bisherigen Status auf `ANG` gesetzt. Eine direkt über `OrderlineKey` übergebene Position wird nicht auf `HAL` gefiltert, sodass eine angehaltene Position auf diesem Weg auf `ANG` gesetzt werden kann.\n- Wird dieselbe Position über `OrderlineKey` übergeben und gehört sie zu `OrderNr`, erscheint sie zweimal im Ergebnis.\n- Existiert `OrderlineKey` nicht, wird eine Zeile mit `NULL` in allen Positionsspalten und `IsEditable` = 1 geliefert.\n- Lesezugriffe auf `Orderlines`, `OrderHistory`, `PLitem` und `PLHeader` erfolgen mit `NOLOCK`; auch die Ergebnismenge wird mit `NOLOCK` gelesen.\n- Im Fehlerfall wird die Transaktion zurückgerollt, der Fehler über `log.InsertError` protokolliert (Definition nicht beigefügt) und statt der Ergebniszeilen eine Fehlerzeile geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetFulfillmentOptions"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt den Direct-Fulfillment-Typ (DF_type) einer Auftragsposition oder aller Positionen eines Auftrags und setzt bearbeitbare Positionen auf Status ANG zurück.\n\nWeist Auftragspositionen einen Direct-Fulfillment-Typ zu und liefert das Ergebnis je Position zurück.\n\n1. Ist `DF_Type` gleich `0`, wird der Wert als `NULL` behandelt, d. h. der Fulfillment-Typ wird entfernt.\n2. Die zu verarbeitenden Auftragspositionen werden gesammelt:\n - `OrderlineKey` > 0: diese einzelne Position wird aufgenommen (ohne Prüfung von Status oder Existenz).\n - `OrderNr` > 0: alle Positionen dieses Auftrags, deren `Status` nicht `HAL` (angehalten) ist, werden aufgenommen.\n - Beide Parameter können kombiniert werden; ist keiner > 0, wird nichts verarbeitet und eine leere Ergebnismenge geliefert.\n3. Jede gesammelte Position wird auf Bearbeitbarkeit geprüft. Eine Position ist **nicht bearbeitbar** (`IsEditable` = 0), wenn\n - die Auftragshistorie (`OrderHistory`) einen Eintrag mit einem Status außerhalb von `HAL`, `ANG`, `BES`, `FUT`, `NEW` enthält oder einen `FUT`-Eintrag mit `ClientNotified` = `Y`, oder\n - sie auf einer Pickliste (`PLitem`/`PLHeader`) steht, deren Ablaufdatum `PLHexpiryDate` in der Zukunft liegt.\n Andernfalls ist sie bearbeitbar (`IsEditable` = 1).\n4. Für alle bearbeitbaren Positionen wird `DF_type` auf den übergebenen Wert und `Status` auf `ANG` gesetzt.\n5. Je gesammelter Position wird eine Zeile mit aktueller Auftragsnummer, Positionsschlüssel, Status, DF-Typ und Bearbeitbarkeitskennzeichen geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Schlüssel einer einzelnen zu aktualisierenden Auftragsposition. Wird bei NULL oder <= 0 ignoriert. |\n| `OrderNr` | int | Nein | Auftragsnummer; alle nicht angehaltenen (`HAL`) Positionen dieses Auftrags werden verarbeitet. Wird bei NULL oder <= 0 ignoriert. |\n| `DF_Type` | int | Nein | Direct-Fulfillment-Typ, der an den Positionen gesetzt wird. `0` oder NULL entfernt den Typ (setzt `DF_type` auf NULL). |\n\n- Die Aktualisierung läuft in einer eigenen Transaktion bzw. als Savepoint, wenn der Aufrufer bereits eine Transaktion geöffnet hat.\n- Der Status jeder bearbeitbaren Position wird unabhängig vom bisherigen Status auf `ANG` gesetzt. Eine direkt über `OrderlineKey` übergebene Position wird nicht auf `HAL` gefiltert, sodass eine angehaltene Position auf diesem Weg auf `ANG` gesetzt werden kann.\n- Wird dieselbe Position über `OrderlineKey` übergeben und gehört sie zu `OrderNr`, erscheint sie zweimal im Ergebnis.\n- Existiert `OrderlineKey` nicht, wird eine Zeile mit `NULL` in allen Positionsspalten und `IsEditable` = 1 geliefert.\n- Lesezugriffe auf `Orderlines`, `OrderHistory`, `PLitem` und `PLHeader` erfolgen mit `NOLOCK`; auch die Ergebnismenge wird mit `NOLOCK` gelesen.\n- Im Fehlerfall wird die Transaktion zurückgerollt, der Fehler über `log.InsertError` protokolliert (Definition nicht beigefügt) und statt der Ergebniszeilen eine Fehlerzeile geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetFulfillmentOptions"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 98765\n 123456\n ANG\n 1\n true\n \n \n 98765\n 123457\n AUS\n false\n \n"
}
]
}
]
},
{
"name": "General",
"item": [
{
"name": "pixiAdminGetCUL",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die an lizenzpflichtigen Pixi-Clients angemeldeten Benutzer zu einem Snapshot-Zeitpunkt oder zum letzten Snapshot, wenn kein Datum übergeben wird.\n\nListet die aktuell angemeldeten Benutzer (CUL) aus der Snapshot-Tabelle `UsersLoggedIn` auf.\n\n1. Wird `Date` nicht übergeben, wird der jüngste Snapshot-Zeitpunkt (`MAX(Tag)`) aller Sitzungen mit Sitzungstyp 1 oder 2 verwendet.\n2. Berücksichtigt werden nur Zeilen, deren `Tag` **exakt** diesem Datum entspricht, und nur Sitzungen vom Typ 1 oder 2.\n3. Nur lizenzpflichtige Anwendungen werden einbezogen. Eine Anwendung zählt, wenn sie in `ExeClientVersion` mit `LicenceNeeded = 1` eingetragen ist und entweder:\n - die Einstellung `pixiLicencesManager` den Wert `1` hat und die Sitzungstyp-Referenz des Clients `1` ist (Desktop), oder\n - die Einstellung `pixiLicencesManagerWeb` den Wert `1` hat und die Sitzungstyp-Referenz des Clients `2` ist (Web).\n Fehlende Einstellungen gelten als `0`.\n4. Master-Benutzer werden ausgeschlossen: Zeilen, deren `UserName` als `ComputerName` in `MasterUsers` vorkommt, sowie Zeilen mit `UserNameUsingPixi` = `master`.\n5. Bekannte Programme erhalten einen sortierbaren Anzeigenamen (z. B. wird `PPOS2.exe` zu `1_POS`, `supplorders_a.exe` zu `2_SupplOrders` bis `ControlCenter.exe` zu `9_ControlCenter`). Andere Anwendungsnamen bleiben unverändert.\n\nDas Ergebnis ist nach `UserName`, `UserNameUsingPixi` und dem umbenannten `AppName` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Date` | datetime | Nein | Snapshot-Zeitpunkt (`Tag` in `UsersLoggedIn`), der ausgewertet wird. Muss exakt übereinstimmen. Ohne Angabe wird der letzte Snapshot der Sitzungstypen 1 und 2 verwendet. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Sind beide Lizenzmanager-Einstellungen `0` oder nicht vorhanden, qualifiziert sich keine Anwendung und das Ergebnis ist immer leer.\n- `Date` muss exakt einem Snapshot-`Tag` entsprechen (inklusive Uhrzeit); ein Datum ohne die genaue Uhrzeit des Snapshots liefert keine Zeilen. Die Übergabe von `1900-01-01` wirkt wie das Weglassen des Datums, da der Code `ISNULL(@Date, '')` mit einer leeren Zeichenkette vergleicht.\n- `AppName_clean` entfernt einfach die ersten zwei Zeichen von `AppName`. Bei umbenannten Anwendungen fällt damit das numerische Präfix weg (`1_POS` → `POS`); bei nicht zugeordneten Anwendungen werden die ersten zwei Zeichen des ursprünglichen Programmnamens abgeschnitten.\n- Vollständige Zuordnung: `PPOS2.exe` → `1_POS`, `supplorders_a.exe` → `2_SupplOrders`, `paymentsclient_a.exe` → `3_Payments`, `shippingclient_a.exe` → `4_Shipping`, `CustomerClient_A.exe` → `5_CustomerService`, `ReportClientA.exe` → `6_Reports`, `binclient_a.exe` → `7_Bin`, `InvoicesClient_A.exe` → `8_Invoices`, `ControlCenter.exe` → `9_ControlCenter`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAdminGetCUL"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die an lizenzpflichtigen Pixi-Clients angemeldeten Benutzer zu einem Snapshot-Zeitpunkt oder zum letzten Snapshot, wenn kein Datum übergeben wird.\n\nListet die aktuell angemeldeten Benutzer (CUL) aus der Snapshot-Tabelle `UsersLoggedIn` auf.\n\n1. Wird `Date` nicht übergeben, wird der jüngste Snapshot-Zeitpunkt (`MAX(Tag)`) aller Sitzungen mit Sitzungstyp 1 oder 2 verwendet.\n2. Berücksichtigt werden nur Zeilen, deren `Tag` **exakt** diesem Datum entspricht, und nur Sitzungen vom Typ 1 oder 2.\n3. Nur lizenzpflichtige Anwendungen werden einbezogen. Eine Anwendung zählt, wenn sie in `ExeClientVersion` mit `LicenceNeeded = 1` eingetragen ist und entweder:\n - die Einstellung `pixiLicencesManager` den Wert `1` hat und die Sitzungstyp-Referenz des Clients `1` ist (Desktop), oder\n - die Einstellung `pixiLicencesManagerWeb` den Wert `1` hat und die Sitzungstyp-Referenz des Clients `2` ist (Web).\n Fehlende Einstellungen gelten als `0`.\n4. Master-Benutzer werden ausgeschlossen: Zeilen, deren `UserName` als `ComputerName` in `MasterUsers` vorkommt, sowie Zeilen mit `UserNameUsingPixi` = `master`.\n5. Bekannte Programme erhalten einen sortierbaren Anzeigenamen (z. B. wird `PPOS2.exe` zu `1_POS`, `supplorders_a.exe` zu `2_SupplOrders` bis `ControlCenter.exe` zu `9_ControlCenter`). Andere Anwendungsnamen bleiben unverändert.\n\nDas Ergebnis ist nach `UserName`, `UserNameUsingPixi` und dem umbenannten `AppName` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Date` | datetime | Nein | Snapshot-Zeitpunkt (`Tag` in `UsersLoggedIn`), der ausgewertet wird. Muss exakt übereinstimmen. Ohne Angabe wird der letzte Snapshot der Sitzungstypen 1 und 2 verwendet. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Sind beide Lizenzmanager-Einstellungen `0` oder nicht vorhanden, qualifiziert sich keine Anwendung und das Ergebnis ist immer leer.\n- `Date` muss exakt einem Snapshot-`Tag` entsprechen (inklusive Uhrzeit); ein Datum ohne die genaue Uhrzeit des Snapshots liefert keine Zeilen. Die Übergabe von `1900-01-01` wirkt wie das Weglassen des Datums, da der Code `ISNULL(@Date, '')` mit einer leeren Zeichenkette vergleicht.\n- `AppName_clean` entfernt einfach die ersten zwei Zeichen von `AppName`. Bei umbenannten Anwendungen fällt damit das numerische Präfix weg (`1_POS` → `POS`); bei nicht zugeordneten Anwendungen werden die ersten zwei Zeichen des ursprünglichen Programmnamens abgeschnitten.\n- Vollständige Zuordnung: `PPOS2.exe` → `1_POS`, `supplorders_a.exe` → `2_SupplOrders`, `paymentsclient_a.exe` → `3_Payments`, `shippingclient_a.exe` → `4_Shipping`, `CustomerClient_A.exe` → `5_CustomerService`, `ReportClientA.exe` → `6_Reports`, `binclient_a.exe` → `7_Bin`, `InvoicesClient_A.exe` → `8_Invoices`, `ControlCenter.exe` → `9_ControlCenter`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAdminGetCUL"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 2024-05-14T10:15:00\n mmueller\n WS-LAGER01\n 58\n Bin\n 7_Bin\n 24.5.1.0\n \n \n 2024-05-14T10:15:00\n skraus\n WS-OFFICE03\n 71\n SupplOrders\n 2_SupplOrders\n 24.5.1.0\n \n"
}
]
},
{
"name": "pixiCheckPixiUserLogin",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n shopapi\n S3cret!2024\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Prüft Benutzername und Passwort eines Pixi-Benutzers, optional einen Berechtigungscode, und liefert, ob die Anmeldung gültig ist, samt E-Mail und echtem Namen.\n\nPrüft die Anmeldedaten eines Pixi-Benutzers (Tabelle `UCS_USERS`).\n\n1. Das Passwort wird mit `dbo.PixiEncrypt` verschlüsselt. Das gespeicherte Passwort `USER_PWD` wird mit diesem verschlüsselten Wert verglichen.\n2. Der Benutzer wird über `UserName` gesucht. Ist `USER_PWD` beim Benutzer `NULL`, greift die Passwortprüfung *Version 2*: Die Prozedur ruft `pixi.UserPassword_ValidateV2` mit Benutzername und Klartext-Passwort auf. Meldet diese Prozedur Erfolg, gilt die Passwortprüfung als bestanden.\n3. `ValidUser` ist nur dann `1`, wenn ein Benutzer mit dem angegebenen `UserName` existiert und alle folgenden Bedingungen erfüllt sind:\n - Das Passwort stimmt, entweder über den klassischen Vergleich oder über die V2-Prüfung.\n - Ist `CheckPermission` gesetzt, besitzt der Benutzer eine Rolle (`USER_HAS_ROLES` → `USER_ROLES` → `ROLE_HAS_PERMISSIONS`) mit einer Berechtigung, deren `Permission_Code` gleich `CheckPermission` ist. Ein Leerstring bedeutet keine Berechtigungsprüfung.\n - Das Konto ist nicht abgelaufen: `User_expire` ist nicht `1`, oder es ist `1` und `Expiration_date` liegt nach dem aktuellen Zeitpunkt.\n - `User_active = 1`.\n Andernfalls ist `ValidUser` gleich `0`.\n4. Bei gültiger Anmeldung werden die Ausgabeparameter `UserEmail` und `UserRealName` aus `User_Email` und `REAL_NAME` befüllt. `NULL`-Werte werden zu Leerstrings.\n5. Ist `SuppressDataset` nicht `1`, liefert die Prozedur eine Zeile mit `ValidUser`, `UserName`, `UserEmail` und `UserRealName`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `UserName` | varchar(1024) | Ja | Pixi-Benutzername (`UCS_USERS.USER_NAME`). |\n| `Password` | varchar(1024) | Ja | Passwort des Benutzers im Klartext. |\n| `CheckPermission` | varchar(5) | Nein | Optionaler Berechtigungscode (`User_Permissions.Permission_Code`), den der Benutzer über eine seiner Rollen besitzen muss. `NULL` oder ein Leerstring überspringt die Berechtigungsprüfung. |\n| `ValidUser` | bit | Nein | Ausgabe: `1`, wenn die Anmeldung gültig ist, sonst `0`. |\n| `SuppressDataset` | bit | Nein | Bei `1` wird keine Ergebnismenge geliefert, nur die Ausgabeparameter werden gesetzt. `NULL` gilt als `0`. |\n| `UserEmail` | varchar(100) | Nein | Ausgabe: E-Mail-Adresse des Benutzers, nur bei gültiger Anmeldung gesetzt. Leerstring, wenn keine hinterlegt ist. |\n| `UserRealName` | varchar(40) | Nein | Ausgabe: echter Name des Benutzers, nur bei gültiger Anmeldung gesetzt. Leerstring, wenn keiner hinterlegt ist. |\n\n- Die zurückgegebene Zeile enthält `UserEmail` und `UserRealName`, sobald der Benutzername existiert, **auch wenn `ValidUser` 0 ist**, etwa bei falschem Passwort. Existiert der Benutzer nicht, sind beide Spalten `NULL`. Die Ausgabeparameter `UserEmail`/`UserRealName` werden dagegen nur bei gültiger Anmeldung gesetzt.\n- `dbo.PixiEncrypt` ist lediglich eine einfache XOR-Verschleierung und kein kryptografischer Hash. Das Passwort sollte nur über die verschlüsselte Verbindung übertragen werden.\n- `pixi.UserPassword_ValidateV2` liegt nicht vor. Die genaue Logik und mögliche Seiteneffekte, etwa Protokollierung oder Sperrung, sind unbekannt.\n- Ist `User_expire` `NULL`, ergibt die Ablaufbedingung nicht wahr. Solche Benutzer werden daher abgewiesen.\n- Der Vergleich des Benutzernamens hängt von der Datenbank-Collation ab. Die erste Suche für die V2-Prüfung verwendet `COLLATE DATABASE_DEFAULT`, die Gültigkeitsprüfung nicht.\n- Alle Lesezugriffe der Gültigkeitsprüfung erfolgen mit `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCheckPixiUserLogin"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n shopapi\n S3cret!2024\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Prüft Benutzername und Passwort eines Pixi-Benutzers, optional einen Berechtigungscode, und liefert, ob die Anmeldung gültig ist, samt E-Mail und echtem Namen.\n\nPrüft die Anmeldedaten eines Pixi-Benutzers (Tabelle `UCS_USERS`).\n\n1. Das Passwort wird mit `dbo.PixiEncrypt` verschlüsselt. Das gespeicherte Passwort `USER_PWD` wird mit diesem verschlüsselten Wert verglichen.\n2. Der Benutzer wird über `UserName` gesucht. Ist `USER_PWD` beim Benutzer `NULL`, greift die Passwortprüfung *Version 2*: Die Prozedur ruft `pixi.UserPassword_ValidateV2` mit Benutzername und Klartext-Passwort auf. Meldet diese Prozedur Erfolg, gilt die Passwortprüfung als bestanden.\n3. `ValidUser` ist nur dann `1`, wenn ein Benutzer mit dem angegebenen `UserName` existiert und alle folgenden Bedingungen erfüllt sind:\n - Das Passwort stimmt, entweder über den klassischen Vergleich oder über die V2-Prüfung.\n - Ist `CheckPermission` gesetzt, besitzt der Benutzer eine Rolle (`USER_HAS_ROLES` → `USER_ROLES` → `ROLE_HAS_PERMISSIONS`) mit einer Berechtigung, deren `Permission_Code` gleich `CheckPermission` ist. Ein Leerstring bedeutet keine Berechtigungsprüfung.\n - Das Konto ist nicht abgelaufen: `User_expire` ist nicht `1`, oder es ist `1` und `Expiration_date` liegt nach dem aktuellen Zeitpunkt.\n - `User_active = 1`.\n Andernfalls ist `ValidUser` gleich `0`.\n4. Bei gültiger Anmeldung werden die Ausgabeparameter `UserEmail` und `UserRealName` aus `User_Email` und `REAL_NAME` befüllt. `NULL`-Werte werden zu Leerstrings.\n5. Ist `SuppressDataset` nicht `1`, liefert die Prozedur eine Zeile mit `ValidUser`, `UserName`, `UserEmail` und `UserRealName`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `UserName` | varchar(1024) | Ja | Pixi-Benutzername (`UCS_USERS.USER_NAME`). |\n| `Password` | varchar(1024) | Ja | Passwort des Benutzers im Klartext. |\n| `CheckPermission` | varchar(5) | Nein | Optionaler Berechtigungscode (`User_Permissions.Permission_Code`), den der Benutzer über eine seiner Rollen besitzen muss. `NULL` oder ein Leerstring überspringt die Berechtigungsprüfung. |\n| `ValidUser` | bit | Nein | Ausgabe: `1`, wenn die Anmeldung gültig ist, sonst `0`. |\n| `SuppressDataset` | bit | Nein | Bei `1` wird keine Ergebnismenge geliefert, nur die Ausgabeparameter werden gesetzt. `NULL` gilt als `0`. |\n| `UserEmail` | varchar(100) | Nein | Ausgabe: E-Mail-Adresse des Benutzers, nur bei gültiger Anmeldung gesetzt. Leerstring, wenn keine hinterlegt ist. |\n| `UserRealName` | varchar(40) | Nein | Ausgabe: echter Name des Benutzers, nur bei gültiger Anmeldung gesetzt. Leerstring, wenn keiner hinterlegt ist. |\n\n- Die zurückgegebene Zeile enthält `UserEmail` und `UserRealName`, sobald der Benutzername existiert, **auch wenn `ValidUser` 0 ist**, etwa bei falschem Passwort. Existiert der Benutzer nicht, sind beide Spalten `NULL`. Die Ausgabeparameter `UserEmail`/`UserRealName` werden dagegen nur bei gültiger Anmeldung gesetzt.\n- `dbo.PixiEncrypt` ist lediglich eine einfache XOR-Verschleierung und kein kryptografischer Hash. Das Passwort sollte nur über die verschlüsselte Verbindung übertragen werden.\n- `pixi.UserPassword_ValidateV2` liegt nicht vor. Die genaue Logik und mögliche Seiteneffekte, etwa Protokollierung oder Sperrung, sind unbekannt.\n- Ist `User_expire` `NULL`, ergibt die Ablaufbedingung nicht wahr. Solche Benutzer werden daher abgewiesen.\n- Der Vergleich des Benutzernamens hängt von der Datenbank-Collation ab. Die erste Suche für die V2-Prüfung verwendet `COLLATE DATABASE_DEFAULT`, die Gültigkeitsprüfung nicht.\n- Alle Lesezugriffe der Gültigkeitsprüfung erfolgen mit `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCheckPixiUserLogin"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n true\n shopapi\n shopapi@example.com\n Shop Schnittstelle\n \n"
}
]
},
{
"name": "pixiGetClientVersion",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die aktuelle Version und die minimal erlaubte Version einer oder aller Pixi-Client-Anwendungen.\n\nLiest die Versionsinformationen der Pixi-Client-Anwendungen aus der Tabelle `ExeClientVersion`.\n\n- Wird `Client` weggelassen, als `NULL` oder als Leerstring übergeben, wird für jeden in der Tabelle hinterlegten Client eine Zeile geliefert.\n- Wird `Client` angegeben, wird nur die Zeile geliefert, deren `ClientName` dem übergebenen Wert entspricht. Existiert kein Client mit diesem Namen, ist die Ergebnismenge leer.\n\nEine Sortierung wird nicht vorgenommen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Client` | varchar(64) | Nein | Name der Client-Anwendung. Leerstring oder `NULL` liefert alle Clients. |\n\nDie Tabelle wird mit `NOLOCK` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein. Der Vergleich auf `ClientName` folgt der Sortierung (Collation) der Datenbank (in der Regel ohne Beachtung der Groß-/Kleinschreibung). Die Spaltentypen sind aus dem Code nicht ersichtlich; vermutlich handelt es sich um Versionszeichenketten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetClientVersion"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die aktuelle Version und die minimal erlaubte Version einer oder aller Pixi-Client-Anwendungen.\n\nLiest die Versionsinformationen der Pixi-Client-Anwendungen aus der Tabelle `ExeClientVersion`.\n\n- Wird `Client` weggelassen, als `NULL` oder als Leerstring übergeben, wird für jeden in der Tabelle hinterlegten Client eine Zeile geliefert.\n- Wird `Client` angegeben, wird nur die Zeile geliefert, deren `ClientName` dem übergebenen Wert entspricht. Existiert kein Client mit diesem Namen, ist die Ergebnismenge leer.\n\nEine Sortierung wird nicht vorgenommen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Client` | varchar(64) | Nein | Name der Client-Anwendung. Leerstring oder `NULL` liefert alle Clients. |\n\nDie Tabelle wird mit `NOLOCK` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein. Der Vergleich auf `ClientName` folgt der Sortierung (Collation) der Datenbank (in der Regel ohne Beachtung der Groß-/Kleinschreibung). Die Spaltentypen sind aus dem Code nicht ersichtlich; vermutlich handelt es sich um Versionszeichenketten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetClientVersion"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n PixiClient\n 24.10.1\n 24.04.0\n \n"
}
]
},
{
"name": "pixiGetCountries",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert ein Land oder alle Länder aus den Länderstammdaten von Pixi, optional nur Länder, die in Adressen verwendet werden.\n\nLiest die Länderstammdaten aus der Tabelle `Countries`.\n\n- Ist `CntCode` gesetzt, wird nur das Land mit diesem Code geliefert.\n- Ist `CntCode` leer oder `NULL`, werden alle Länder geliefert. Ein Leerstring wird wie `NULL` behandelt.\n- Ist `OnlyActive` = `1` und kein `CntCode` angegeben, beschränkt sich die Liste auf Länder, deren Code in der Spalte `Country` mindestens eines Datensatzes in `Addresses` vorkommt.\n- Ist `OnlyActive` = `1` und ein `CntCode` angegeben, wird das Land geliefert, unabhängig davon, ob es in einer Adresse verwendet wird.\n\nDie Sortierung erfolgt nach `CntName`. Jede Zeile enthält den internen Ländercode, den Namen, die Standard-Versandkosten, das Datumsformat, den Sprachcode, die ISO-2- und ISO-3-Codes, MwSt.-Einstellungen und das EU-Kennzeichen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CntCode` | varchar(3) | Nein | Interner Pixi-Ländercode des gewünschten Landes. Bei Leerstring oder `NULL` werden alle Länder geliefert. |\n| `OnlyActive` | bit | Nein | Bei `1` und ohne `CntCode` werden nur Länder geliefert, die in mindestens einer Adresse verwendet werden. |\n\n- „Aktiv“ bei `OnlyActive` bezieht sich nicht auf ein Aktiv-Kennzeichen der Länderdaten. Gemeint ist nur, dass das Land in mindestens einer Adresse in `Addresses` verwendet wird.\n- Die ISO-3-Spalte wird mit dem Alias `CntCodeIsO3` (kleines `s`) geliefert. XML-Elementnamen unterscheiden Groß- und Kleinschreibung, daher muss der Client genau diesen Namen lesen.\n- Beide Tabellen werden mit `NOLOCK` gelesen. Das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Die Spaltentypen sind im Code nicht ersichtlich. Die SQL-Typen sind daher als `unknown` angegeben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCountries"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert ein Land oder alle Länder aus den Länderstammdaten von Pixi, optional nur Länder, die in Adressen verwendet werden.\n\nLiest die Länderstammdaten aus der Tabelle `Countries`.\n\n- Ist `CntCode` gesetzt, wird nur das Land mit diesem Code geliefert.\n- Ist `CntCode` leer oder `NULL`, werden alle Länder geliefert. Ein Leerstring wird wie `NULL` behandelt.\n- Ist `OnlyActive` = `1` und kein `CntCode` angegeben, beschränkt sich die Liste auf Länder, deren Code in der Spalte `Country` mindestens eines Datensatzes in `Addresses` vorkommt.\n- Ist `OnlyActive` = `1` und ein `CntCode` angegeben, wird das Land geliefert, unabhängig davon, ob es in einer Adresse verwendet wird.\n\nDie Sortierung erfolgt nach `CntName`. Jede Zeile enthält den internen Ländercode, den Namen, die Standard-Versandkosten, das Datumsformat, den Sprachcode, die ISO-2- und ISO-3-Codes, MwSt.-Einstellungen und das EU-Kennzeichen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CntCode` | varchar(3) | Nein | Interner Pixi-Ländercode des gewünschten Landes. Bei Leerstring oder `NULL` werden alle Länder geliefert. |\n| `OnlyActive` | bit | Nein | Bei `1` und ohne `CntCode` werden nur Länder geliefert, die in mindestens einer Adresse verwendet werden. |\n\n- „Aktiv“ bei `OnlyActive` bezieht sich nicht auf ein Aktiv-Kennzeichen der Länderdaten. Gemeint ist nur, dass das Land in mindestens einer Adresse in `Addresses` verwendet wird.\n- Die ISO-3-Spalte wird mit dem Alias `CntCodeIsO3` (kleines `s`) geliefert. XML-Elementnamen unterscheiden Groß- und Kleinschreibung, daher muss der Client genau diesen Namen lesen.\n- Beide Tabellen werden mit `NOLOCK` gelesen. Das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Die Spaltentypen sind im Code nicht ersichtlich. Die SQL-Typen sind daher als `unknown` angegeben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCountries"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n A\n Österreich\n 9.90\n dd.mm.yyyy\n DE\n 1\n AT\n AUT\n 1\n Austria\n 35000.00\n 1\n \n \n D\n Deutschland\n 4.90\n dd.mm.yyyy\n DE\n 1\n DE\n DEU\n 1\n Germany\n 0.00\n 1\n \n"
}
]
},
{
"name": "pixiGetCurrency",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Hauptwährungen aus der Pixi-Währungstabelle, optional gefiltert nach ISO-Code oder Währungs-ID.\n\nLiest die Währungstabelle `pixi.Currency` und liefert nur Einträge, die als Hauptwährung gekennzeichnet sind (`ParentCurrency = 1`).\n\n- Ohne Parameter werden alle Hauptwährungen geliefert.\n- `CurrencyCode` filtert nach dem alphabetischen ISO-Code (`CodeA`), z. B. `EUR`.\n- `CurrencyId` filtert nach der internen Währungs-ID.\n- Beide Filter lassen sich kombinieren; eine Zeile muss dann beide erfüllen.\n- `NULL`-Werte werden wie die Standardwerte (Leerstring bzw. `0`) behandelt, der Filter entfällt also.\n\nInaktive Währungen werden ebenfalls geliefert; die Spalte `Active` zeigt den Status. Eine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CurrencyCode` | varchar(3) | Nein | Alphabetischer ISO-Währungscode (`CodeA`) als Filter. Leerstring oder NULL liefert alle Hauptwährungen. |\n| `CurrencyId` | smallint | Nein | Interne Währungs-ID als Filter. `0` oder NULL deaktiviert diesen Filter. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen, nicht festgeschriebene Änderungen können daher sichtbar sein.\n- Währungen, die keine Hauptwährung sind (`ParentCurrency` ungleich 1), werden nie geliefert, auch wenn ihr Code oder ihre ID explizit übergeben wird; das Ergebnis ist dann leer.\n- Die Reihenfolge der Zeilen ist nicht garantiert, da die Abfrage kein `ORDER BY` enthält.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCurrency"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Hauptwährungen aus der Pixi-Währungstabelle, optional gefiltert nach ISO-Code oder Währungs-ID.\n\nLiest die Währungstabelle `pixi.Currency` und liefert nur Einträge, die als Hauptwährung gekennzeichnet sind (`ParentCurrency = 1`).\n\n- Ohne Parameter werden alle Hauptwährungen geliefert.\n- `CurrencyCode` filtert nach dem alphabetischen ISO-Code (`CodeA`), z. B. `EUR`.\n- `CurrencyId` filtert nach der internen Währungs-ID.\n- Beide Filter lassen sich kombinieren; eine Zeile muss dann beide erfüllen.\n- `NULL`-Werte werden wie die Standardwerte (Leerstring bzw. `0`) behandelt, der Filter entfällt also.\n\nInaktive Währungen werden ebenfalls geliefert; die Spalte `Active` zeigt den Status. Eine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CurrencyCode` | varchar(3) | Nein | Alphabetischer ISO-Währungscode (`CodeA`) als Filter. Leerstring oder NULL liefert alle Hauptwährungen. |\n| `CurrencyId` | smallint | Nein | Interne Währungs-ID als Filter. `0` oder NULL deaktiviert diesen Filter. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen, nicht festgeschriebene Änderungen können daher sichtbar sein.\n- Währungen, die keine Hauptwährung sind (`ParentCurrency` ungleich 1), werden nie geliefert, auch wenn ihr Code oder ihre ID explizit übergeben wird; das Ergebnis ist dann leer.\n- Die Reihenfolge der Zeilen ist nicht garantiert, da die Abfrage kein `ORDER BY` enthält.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCurrency"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 2\n EUR\n 978\n 1\n 1031\n \n \n 3\n CHF\n 756\n 1\n 2055\n \n"
}
]
},
{
"name": "pixiGetCurrentPixiVersion",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Version der aktuellen Pixi-Datenbank, den Revisionsnamen, den Konsistenzstatus zur Master-Datenbank sowie Endpunkt-Informationen.\n\nDer Aufruf hat keine Parameter. Er leitet direkt an die interne Prozedur `Pixi_GetCurrentPixiVersion` weiter und liefert eine Zeile.\n\nAblauf:\n\n1. Die Versionsinformationen werden über `Pixi_GetCurrentVersion` gelesen. Dies liefert die Version aus dem lokalen Änderungsprotokoll (`DB_Change_Log`) und aus der Master-Datenbank.\n2. Die Endpunktdaten des Mandanten werden über `util.Master_EndpointGet` aus der Master-Datenbank gelesen. Dazu gehören Standard-Einstiegs-URI, Client-ID und interner Versionsname.\n3. Die Spalte `InformationQualityDescription` wird gesetzt:\n - `200 OK`: Die Master-Datenbank war erreichbar, und ihre Version stimmt mit dem lokalen Änderungsprotokoll überein.\n - `401 ...`: Die Master-Datenbank war erreichbar, ihre Version weicht aber vom lokalen `DB_Change_Log` ab.\n - `301 ...`: Auf die Master-Datenbank konnte nicht zugegriffen werden. Die Angaben stammen nur aus dem lokalen Änderungsprotokoll.\n4. An `DefaultEntryPointUri` wird ein abschließender Schrägstrich angehängt, falls er fehlt.\n\nVersionsauswahl:\n\n- `Version` und `RevisionName` verwenden die Werte aus dem lokalen Änderungsprotokoll.\n- Sind diese `NULL`, werden ersatzweise die Master-Werte verwendet.\n\nDie Zeile enthält außerdem:\n\n- den Datenbanknamen\n- die Einstellung `DesktopLoginEnabled` (Standard `1`, falls nicht gesetzt)\n\n- Die Objekte `Pixi_GetCurrentVersion`, `util.Master_EndpointGet` und `dbo.SettingGet` sind nicht beigefügt. Welche Tabellen sie lesen und wann der Master-Endpunkt einen anderen Status als 200 liefert, ist aus dem Code nicht ersichtlich.\n- Liefert `Pixi_GetCurrentVersion` keine Zeile, ist das Ergebnis leer.\n- Ist die Version aus dem lokalen Änderungsprotokoll `NULL`, ergibt der Vergleich mit der Master-Version nicht wahr. Der Status bleibt dann `200 OK`, obwohl nichts verglichen wurde.\n- Ist die Master-Datenbank nicht erreichbar, können `Version_Master`, `DefaultEntryPointUri` und `ClientId` `NULL` sein. Ein `NULL`-Wert in `DefaultEntryPointUri` bleibt `NULL`; es wird kein Schrägstrich angehängt.\n- Die Informationsqualität wird als Textspalte geliefert, nicht als SQL-Fehler. Die führende Zahl (200, 301, 401) kann ausgewertet werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCurrentPixiVersion"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Version der aktuellen Pixi-Datenbank, den Revisionsnamen, den Konsistenzstatus zur Master-Datenbank sowie Endpunkt-Informationen.\n\nDer Aufruf hat keine Parameter. Er leitet direkt an die interne Prozedur `Pixi_GetCurrentPixiVersion` weiter und liefert eine Zeile.\n\nAblauf:\n\n1. Die Versionsinformationen werden über `Pixi_GetCurrentVersion` gelesen. Dies liefert die Version aus dem lokalen Änderungsprotokoll (`DB_Change_Log`) und aus der Master-Datenbank.\n2. Die Endpunktdaten des Mandanten werden über `util.Master_EndpointGet` aus der Master-Datenbank gelesen. Dazu gehören Standard-Einstiegs-URI, Client-ID und interner Versionsname.\n3. Die Spalte `InformationQualityDescription` wird gesetzt:\n - `200 OK`: Die Master-Datenbank war erreichbar, und ihre Version stimmt mit dem lokalen Änderungsprotokoll überein.\n - `401 ...`: Die Master-Datenbank war erreichbar, ihre Version weicht aber vom lokalen `DB_Change_Log` ab.\n - `301 ...`: Auf die Master-Datenbank konnte nicht zugegriffen werden. Die Angaben stammen nur aus dem lokalen Änderungsprotokoll.\n4. An `DefaultEntryPointUri` wird ein abschließender Schrägstrich angehängt, falls er fehlt.\n\nVersionsauswahl:\n\n- `Version` und `RevisionName` verwenden die Werte aus dem lokalen Änderungsprotokoll.\n- Sind diese `NULL`, werden ersatzweise die Master-Werte verwendet.\n\nDie Zeile enthält außerdem:\n\n- den Datenbanknamen\n- die Einstellung `DesktopLoginEnabled` (Standard `1`, falls nicht gesetzt)\n\n- Die Objekte `Pixi_GetCurrentVersion`, `util.Master_EndpointGet` und `dbo.SettingGet` sind nicht beigefügt. Welche Tabellen sie lesen und wann der Master-Endpunkt einen anderen Status als 200 liefert, ist aus dem Code nicht ersichtlich.\n- Liefert `Pixi_GetCurrentVersion` keine Zeile, ist das Ergebnis leer.\n- Ist die Version aus dem lokalen Änderungsprotokoll `NULL`, ergibt der Vergleich mit der Master-Version nicht wahr. Der Status bleibt dann `200 OK`, obwohl nichts verglichen wurde.\n- Ist die Master-Datenbank nicht erreichbar, können `Version_Master`, `DefaultEntryPointUri` und `ClientId` `NULL` sein. Ein `NULL`-Wert in `DefaultEntryPointUri` bleibt `NULL`; es wird kein Schrägstrich angehängt.\n- Die Informationsqualität wird als Textspalte geliefert, nicht als SQL-Fehler. Die führende Zahl (200, 301, 401) kann ausgewertet werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCurrentPixiVersion"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 24.10.1\n Release 24.10 Build 1\n 200 OK\n 24.10.1\n 24.10.1\n PIXI_SHOP01\n 1\n https://shop01.pixi.example.com/\n SHOP01\n \n"
}
]
},
{
"name": "pixiGetPixiVersion",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Einträge des Datenbank-Änderungsprotokolls mit Revisionsnummer, höchste Revision zuerst, zur Ermittlung der installierten Pixi-Version.\n\nLiest das Datenbank-Änderungsprotokoll (`DB_change_log`) und liefert alle Einträge, deren `revision` nicht `NULL` ist.\n\n- Der Aufruf hat keine Parameter.\n- Die Zeilen werden absteigend nach `revision` sortiert. Die Sortierung erfolgt numerisch je Segment: Die Revisionszeichenkette wird an `.` aufgeteilt und jedes Segment wird links mit Nullen auf 7 Stellen aufgefüllt, sodass `6.10.2` vor `6.9.15` steht.\n- Die erste Zeile enthält somit die höchste Revision und kann als aktuelle Pixi-Version verwendet werden.\n\n- Die Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Einträge können daher sichtbar sein.\n- Es werden alle passenden Zeilen ohne Paging geliefert; das Ergebnis kann umfangreich sein. Wird nur die aktuelle Version benötigt, genügt die erste Zeile.\n- Segmente mit mehr als 7 Zeichen werden nicht aufgefüllt und können die Sortierung verfälschen. Nicht-numerische Segmente werden als Text sortiert.\n- Die Spaltentypen sind aus dem Code nicht ersichtlich, da die Definition von `DB_change_log` nicht beiliegt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPixiVersion"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Einträge des Datenbank-Änderungsprotokolls mit Revisionsnummer, höchste Revision zuerst, zur Ermittlung der installierten Pixi-Version.\n\nLiest das Datenbank-Änderungsprotokoll (`DB_change_log`) und liefert alle Einträge, deren `revision` nicht `NULL` ist.\n\n- Der Aufruf hat keine Parameter.\n- Die Zeilen werden absteigend nach `revision` sortiert. Die Sortierung erfolgt numerisch je Segment: Die Revisionszeichenkette wird an `.` aufgeteilt und jedes Segment wird links mit Nullen auf 7 Stellen aufgefüllt, sodass `6.10.2` vor `6.9.15` steht.\n- Die erste Zeile enthält somit die höchste Revision und kann als aktuelle Pixi-Version verwendet werden.\n\n- Die Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Einträge können daher sichtbar sein.\n- Es werden alle passenden Zeilen ohne Paging geliefert; das Ergebnis kann umfangreich sein. Wird nur die aktuelle Version benötigt, genügt die erste Zeile.\n- Segmente mit mehr als 7 Zeichen werden nicht aufgefüllt und können die Sortierung verfälschen. Nicht-numerische Segmente werden als Text sortiert.\n- Die Spaltentypen sind aus dem Code nicht ersichtlich, da die Definition von `DB_change_log` nicht beiliegt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPixiVersion"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n pipiGetItemInfo\n 23.11.2\n update_23.11.2.sql\n dbo\n 2023-11-14T09:12:45.000+01:00\n \n \n pipiReadOrder\n 23.11.1\n update_23.11.1.sql\n dbo\n 2023-11-02T08:30:10.000+01:00\n \n"
}
]
},
{
"name": "pixiGetServerTime",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert das aktuelle lokale Datum und die Uhrzeit des Pixi-Datenbankservers sowie die aktuelle UTC-Zeit.\n\nLiefert genau eine Zeile mit zwei Spalten:\n\n- `ServerTime`: aktuelles lokales Datum und Uhrzeit des SQL Servers (`CURRENT_TIMESTAMP`).\n- `ServerTimeUTC`: aktuelles Datum und Uhrzeit in UTC (`GETUTCDATE()`).\n\nDer Aufruf hat keine Parameter und greift auf keine Tabellen zu.\n\n- Hilfreich, um den Zeitzonenversatz des Pixi-Servers zu ermitteln, z. B. bevor Datumsfilter wie \"geändert seit\" an andere Aufrufe übergeben werden, die mit serverlokalen Zeitstempeln vergleichen.\n- Beide Werte sind vom Typ `datetime` mit einer Genauigkeit von etwa 3 Millisekunden.\n- `ServerTime` richtet sich nach der Zeitzoneneinstellung des Betriebssystems des Datenbankservers.\n- Eignet sich auch als einfache Prüfung von Verbindung und Authentifizierung.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetServerTime"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert das aktuelle lokale Datum und die Uhrzeit des Pixi-Datenbankservers sowie die aktuelle UTC-Zeit.\n\nLiefert genau eine Zeile mit zwei Spalten:\n\n- `ServerTime`: aktuelles lokales Datum und Uhrzeit des SQL Servers (`CURRENT_TIMESTAMP`).\n- `ServerTimeUTC`: aktuelles Datum und Uhrzeit in UTC (`GETUTCDATE()`).\n\nDer Aufruf hat keine Parameter und greift auf keine Tabellen zu.\n\n- Hilfreich, um den Zeitzonenversatz des Pixi-Servers zu ermitteln, z. B. bevor Datumsfilter wie \"geändert seit\" an andere Aufrufe übergeben werden, die mit serverlokalen Zeitstempeln vergleichen.\n- Beide Werte sind vom Typ `datetime` mit einer Genauigkeit von etwa 3 Millisekunden.\n- `ServerTime` richtet sich nach der Zeitzoneneinstellung des Betriebssystems des Datenbankservers.\n- Eignet sich auch als einfache Prüfung von Verbindung und Authentifizierung.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetServerTime"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 2024-05-14T14:32:07.123+02:00\n 2024-05-14T12:32:07.123+02:00\n \n"
}
]
},
{
"name": "pixiGetSettings",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Wert einer einzelnen Pixi-Einstellung oder ohne Namensangabe eine Übersicht ausgewählter Einstellungen, Lizenzzähler und Stammdatenanzahlen.\n\nLiest Systemeinstellungen aus der Tabelle `Settings`. Leere Zeichenketten in den Parametern werden als `NULL` behandelt.\n\nDer Aufruf kennt drei Modi:\n\n- **`SettingName` = `LocID`**: liefert eine Zeile mit `SettingName` = `LocID` und einem `SettingValue`, der alle Lager-IDs aus `Location` jeweils gefolgt von `; ` auflistet (z. B. `001; 002; `).\n- **Beliebiger anderer `SettingName`**: liefert eine Zeile mit dem angefragten Namen und dessen Wert aus `Settings` (erster Treffer). Existiert die Einstellung nicht oder ist ihr Wert `NULL`, ist `SettingValue` gleich `'0'`.\n- **Kein `SettingName`** (weggelassen oder leer): liefert eine Übersicht mit mehreren Zeilen:\n - die Einstellungen `EnablePrintingRules`, `BookExportDatevActive`, `FulfillmentBuyingOption`, `pixiLicences`, `ReservePrepaymentOrders`, `ScanInWithPiccoLink`, `EnablePersonalizedItems`, `SerialNumberValidityCheckEnabled`, `PixiMail_CreationEnabled`, `PixiMail_SendingEnabled`, `C_ItemImportEnabled`, `C_OrderImportEnabled`, `ReturnsEnabled`, `EnableDbCCP`, `Add_0_to_12_char_BarCode`, `default_quantity`, `APIUpdateItemBinCodes`, `NumberOfPiccoTerminals` (nur sofern in `Settings` vorhanden),\n - `Mobile_Licenses`: Anzahl aktiver Benutzersitzungen mit Sitzungstyp 4 oder 5,\n - `Suppliers`, `Shops`, `Locations`: Anzahl der Datensätze in den jeweiligen Tabellen,\n - `ShipVendors`: alle Versanddienstleister-Namen, jeweils gefolgt von `, `,\n - `LocID`: alle Lager-IDs, jeweils gefolgt von `; `,\n - `PIM`: `'1'`, wenn eine Einstellung `ShopUrl` auf `pim.pixi.eu` oder `pim-beta.pixi.eu` verweist, sonst `'0'`. Ist die Einstellung `C_OrderImportEnabled` gleich `1`, werden zusätzlich die Kanaleinstellungen (`C_ChannelSettings`) geprüft.\n\nDie Übersichtszeilen werden per `UNION` zusammengeführt; doppelte Zeilen entfallen, eine Sortierreihenfolge ist nicht garantiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SettingName` | varchar(50) | Nein | Name der zu lesenden Einstellung. `LocID` liefert die Liste aller Lager-IDs. Leer oder weggelassen liefert die Übersicht ausgewählter Einstellungen und Zähler. |\n| `ShopID` | varchar(3) | Nein | Shop-ID. Wird an die Einstellungsabfrage übergeben, hat derzeit aber keine Wirkung. |\n| `LocID` | varchar(3) | Nein | Lager-ID. Wird an die Einstellungsabfrage übergeben, hat derzeit aber keine Wirkung. |\n\n- `ShopID` und `LocID` werden an die interne Funktion zum Lesen der Einstellung übergeben, dort aber ignoriert. Shop- oder lagerspezifische Werte werden daher **nicht** geliefert; das Ergebnis ist immer der globale Wert aus `Settings`.\n- Eine fehlende Einstellung ist nicht von einer Einstellung mit dem Wert `'0'` zu unterscheiden.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; Werte können nicht festgeschriebene Änderungen enthalten.\n- Die Listen für `LocID` und `ShipVendors` werden mit `FOR XML PATH` erzeugt: Sie enden mit einem Trennzeichen, Sonderzeichen wie `&` können XML-maskiert erscheinen, und bei leerer Tabelle ist der Wert `NULL`.\n- Im Übersichtsmodus wird `C_OrderImportEnabled` mit der Zahl `1` verglichen; ein nicht numerischer Wert dieser Einstellung würde einen Konvertierungsfehler verursachen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetSettings"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Wert einer einzelnen Pixi-Einstellung oder ohne Namensangabe eine Übersicht ausgewählter Einstellungen, Lizenzzähler und Stammdatenanzahlen.\n\nLiest Systemeinstellungen aus der Tabelle `Settings`. Leere Zeichenketten in den Parametern werden als `NULL` behandelt.\n\nDer Aufruf kennt drei Modi:\n\n- **`SettingName` = `LocID`**: liefert eine Zeile mit `SettingName` = `LocID` und einem `SettingValue`, der alle Lager-IDs aus `Location` jeweils gefolgt von `; ` auflistet (z. B. `001; 002; `).\n- **Beliebiger anderer `SettingName`**: liefert eine Zeile mit dem angefragten Namen und dessen Wert aus `Settings` (erster Treffer). Existiert die Einstellung nicht oder ist ihr Wert `NULL`, ist `SettingValue` gleich `'0'`.\n- **Kein `SettingName`** (weggelassen oder leer): liefert eine Übersicht mit mehreren Zeilen:\n - die Einstellungen `EnablePrintingRules`, `BookExportDatevActive`, `FulfillmentBuyingOption`, `pixiLicences`, `ReservePrepaymentOrders`, `ScanInWithPiccoLink`, `EnablePersonalizedItems`, `SerialNumberValidityCheckEnabled`, `PixiMail_CreationEnabled`, `PixiMail_SendingEnabled`, `C_ItemImportEnabled`, `C_OrderImportEnabled`, `ReturnsEnabled`, `EnableDbCCP`, `Add_0_to_12_char_BarCode`, `default_quantity`, `APIUpdateItemBinCodes`, `NumberOfPiccoTerminals` (nur sofern in `Settings` vorhanden),\n - `Mobile_Licenses`: Anzahl aktiver Benutzersitzungen mit Sitzungstyp 4 oder 5,\n - `Suppliers`, `Shops`, `Locations`: Anzahl der Datensätze in den jeweiligen Tabellen,\n - `ShipVendors`: alle Versanddienstleister-Namen, jeweils gefolgt von `, `,\n - `LocID`: alle Lager-IDs, jeweils gefolgt von `; `,\n - `PIM`: `'1'`, wenn eine Einstellung `ShopUrl` auf `pim.pixi.eu` oder `pim-beta.pixi.eu` verweist, sonst `'0'`. Ist die Einstellung `C_OrderImportEnabled` gleich `1`, werden zusätzlich die Kanaleinstellungen (`C_ChannelSettings`) geprüft.\n\nDie Übersichtszeilen werden per `UNION` zusammengeführt; doppelte Zeilen entfallen, eine Sortierreihenfolge ist nicht garantiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SettingName` | varchar(50) | Nein | Name der zu lesenden Einstellung. `LocID` liefert die Liste aller Lager-IDs. Leer oder weggelassen liefert die Übersicht ausgewählter Einstellungen und Zähler. |\n| `ShopID` | varchar(3) | Nein | Shop-ID. Wird an die Einstellungsabfrage übergeben, hat derzeit aber keine Wirkung. |\n| `LocID` | varchar(3) | Nein | Lager-ID. Wird an die Einstellungsabfrage übergeben, hat derzeit aber keine Wirkung. |\n\n- `ShopID` und `LocID` werden an die interne Funktion zum Lesen der Einstellung übergeben, dort aber ignoriert. Shop- oder lagerspezifische Werte werden daher **nicht** geliefert; das Ergebnis ist immer der globale Wert aus `Settings`.\n- Eine fehlende Einstellung ist nicht von einer Einstellung mit dem Wert `'0'` zu unterscheiden.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; Werte können nicht festgeschriebene Änderungen enthalten.\n- Die Listen für `LocID` und `ShipVendors` werden mit `FOR XML PATH` erzeugt: Sie enden mit einem Trennzeichen, Sonderzeichen wie `&` können XML-maskiert erscheinen, und bei leerer Tabelle ist der Wert `NULL`.\n- Im Übersichtsmodus wird `C_OrderImportEnabled` mit der Zahl `1` verglichen; ein nicht numerischer Wert dieser Einstellung würde einen Konvertierungsfehler verursachen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetSettings"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n LocID\n 001; 002; \n \n"
}
]
},
{
"name": "pixiGetShops",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Stammdaten aller Shops oder eines einzelnen Shops inklusive Adresse, Kontakt, Bankdaten aus den Fußzeilen und Kostenstelle.\n\nLiest die Shop-Stammdaten aus der Tabelle `shops`.\n\n- Wird `ShopID` übergeben, wird nur der Shop mit dieser ID geliefert.\n- Fehlt `ShopID`, ist sie `NULL` oder ein Leerstring, werden alle Shops geliefert.\n\nEine Sortierung ist nicht festgelegt. Die Zeilen kommen also in der Reihenfolge, die die Datenbank liefert. Einige Spalten werden im Ergebnis umbenannt: `SI_WebAddr` wird zu `ShopURL`, `SI_Address` zu `ShopCompany`, und die Fußzeilen `SI_FootLine1` bis `SI_FootLine4` werden als `BIC`, `IBAN`, `KontoBLZ` und `BankName` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | Nein | ID des zu liefernden Shops. Ist sie leer oder `NULL`, werden alle Shops geliefert. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen, daher können auch nicht festgeschriebene Daten im Ergebnis erscheinen.\n- Die bankbezogenen Spaltennamen (`BIC`, `IBAN`, `KontoBLZ`, `BankName`) sind nur Aliase für die allgemeinen Fußzeilen `SI_FootLine1` bis `SI_FootLine4`. Sie enthalten das, was in diesen Fußzeilen gepflegt ist, was nicht zwingend Bankdaten sein müssen.\n- Eine unbekannte `ShopID` löst keinen Fehler aus; die Ergebnismenge ist dann einfach leer.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetShops"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Stammdaten aller Shops oder eines einzelnen Shops inklusive Adresse, Kontakt, Bankdaten aus den Fußzeilen und Kostenstelle.\n\nLiest die Shop-Stammdaten aus der Tabelle `shops`.\n\n- Wird `ShopID` übergeben, wird nur der Shop mit dieser ID geliefert.\n- Fehlt `ShopID`, ist sie `NULL` oder ein Leerstring, werden alle Shops geliefert.\n\nEine Sortierung ist nicht festgelegt. Die Zeilen kommen also in der Reihenfolge, die die Datenbank liefert. Einige Spalten werden im Ergebnis umbenannt: `SI_WebAddr` wird zu `ShopURL`, `SI_Address` zu `ShopCompany`, und die Fußzeilen `SI_FootLine1` bis `SI_FootLine4` werden als `BIC`, `IBAN`, `KontoBLZ` und `BankName` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | Nein | ID des zu liefernden Shops. Ist sie leer oder `NULL`, werden alle Shops geliefert. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen, daher können auch nicht festgeschriebene Daten im Ergebnis erscheinen.\n- Die bankbezogenen Spaltennamen (`BIC`, `IBAN`, `KontoBLZ`, `BankName`) sind nur Aliase für die allgemeinen Fußzeilen `SI_FootLine1` bis `SI_FootLine4`. Sie enthalten das, was in diesen Fußzeilen gepflegt ist, was nicht zwingend Bankdaten sein müssen.\n- Eine unbekannte `ShopID` löst keinen Fehler aus; die Ergebnismenge ist dann einfach leer.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetShops"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n ABC\n Example Shop\n https://www.example-shop.de\n Hauptstraße 1\n München\n BY\n 80331\n DE\n Max Mustermann\n +49 89 123456\n +49 89 123457\n Example GmbH\n info@example-shop.de\n +49 89 123456\n +49 89 123457\n BIC: DEUTDEMMXXX\n IBAN: DE89370400440532013000\n Konto 532013000 BLZ 37040044\n Deutsche Bank\n 100\n \n"
}
]
},
{
"name": "pixiGetUserPermissions",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Pixi-Benutzer mit Namen und einer durch Semikolon getrennten Liste der Berechtigungscodes aus ihren Rollen.\n\nLiefert die Berechtigungscodes eines Pixi-Benutzers oder aller Benutzer.\n\n- Ist `UserName` angegeben, wird nur dieser Benutzer geliefert. Bei leerem Wert oder `NULL` werden alle Benutzer geliefert.\n- Der interne Benutzer `master` wird immer ausgeschlossen.\n- Berücksichtigt werden nur Benutzer, denen mindestens eine Rolle zugeordnet ist. Benutzer ohne Rolle werden überhaupt nicht geliefert.\n- Die Berechtigungscodes ergeben sich aus den Rollen des Benutzers über die Zuordnung von Rollen zu Berechtigungen. Jeder Code erscheint pro Benutzer nur einmal, auch wenn ihn mehrere Rollen gewähren.\n\nPro Benutzer wird eine Zeile geliefert. `PermissionCode` enthält alle Codes dieses Benutzers, verbunden mit `;`.\n\nWird kein passender Benutzer gefunden, wird stattdessen eine Statuszeile mit `Status` = `Error` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `UserName` | varchar(50) | Nein | Anmeldename des Benutzers. Leer oder `NULL` liefert alle Benutzer außer `master`. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- Jeder Berechtigungscode wird vor dem Verbinden in `varchar(10)` umgewandelt. Längere Codes werden abgeschnitten.\n- Gewähren die Rollen eines Benutzers keine Berechtigungen, ist `PermissionCode` `NULL`.\n- Weder die Zeilen noch die Codes innerhalb von `PermissionCode` haben eine garantierte Reihenfolge.\n- Die Liste wird mit `FOR XML PATH` erzeugt. Zeichen wie `&`, `<` oder `>` würden daher XML-maskiert erscheinen.\n- Werden alle Benutzer abgefragt und keiner gefunden, nennt die Fehlermeldung einen leeren Benutzernamen (`''`).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetUserPermissions"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Pixi-Benutzer mit Namen und einer durch Semikolon getrennten Liste der Berechtigungscodes aus ihren Rollen.\n\nLiefert die Berechtigungscodes eines Pixi-Benutzers oder aller Benutzer.\n\n- Ist `UserName` angegeben, wird nur dieser Benutzer geliefert. Bei leerem Wert oder `NULL` werden alle Benutzer geliefert.\n- Der interne Benutzer `master` wird immer ausgeschlossen.\n- Berücksichtigt werden nur Benutzer, denen mindestens eine Rolle zugeordnet ist. Benutzer ohne Rolle werden überhaupt nicht geliefert.\n- Die Berechtigungscodes ergeben sich aus den Rollen des Benutzers über die Zuordnung von Rollen zu Berechtigungen. Jeder Code erscheint pro Benutzer nur einmal, auch wenn ihn mehrere Rollen gewähren.\n\nPro Benutzer wird eine Zeile geliefert. `PermissionCode` enthält alle Codes dieses Benutzers, verbunden mit `;`.\n\nWird kein passender Benutzer gefunden, wird stattdessen eine Statuszeile mit `Status` = `Error` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `UserName` | varchar(50) | Nein | Anmeldename des Benutzers. Leer oder `NULL` liefert alle Benutzer außer `master`. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- Jeder Berechtigungscode wird vor dem Verbinden in `varchar(10)` umgewandelt. Längere Codes werden abgeschnitten.\n- Gewähren die Rollen eines Benutzers keine Berechtigungen, ist `PermissionCode` `NULL`.\n- Weder die Zeilen noch die Codes innerhalb von `PermissionCode` haben eine garantierte Reihenfolge.\n- Die Liste wird mit `FOR XML PATH` erzeugt. Zeichen wie `&`, `<` oder `>` würden daher XML-maskiert erscheinen.\n- Werden alle Benutzer abgefragt und keiner gefunden, nennt die Fehlermeldung einen leeren Benutzernamen (`''`).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetUserPermissions"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n jdoe\n John\n Doe\n 101;102;205\n \n"
}
]
},
{
"name": "pixiGetUsersFromLastLogin",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Pixi-Benutzer aus dem letzten Anmelde-Snapshot von `UsersLoggedIn` mit Vorname, Nachname und E-Mail-Adresse.\n\nDer Aufruf hat keine Parameter.\n\n1. Ermittelt wird der höchste Wert von `Tag` in `UsersLoggedIn` unter den Einträgen mit `UserActiveSessionTypeId = 1`. Dieser Wert kennzeichnet den zuletzt erfassten Snapshot der angemeldeten Benutzer.\n2. Geliefert werden alle Einträge aus `UsersLoggedIn` mit diesem `Tag` und `UserActiveSessionTypeId` 1 oder 2.\n3. Jeder Eintrag wird mit `Users` verknüpft. Dabei muss der Teil von `UsersLoggedIn.UserName` vor dem ersten Leerzeichen dem Wert `Users.UserName` entsprechen.\n4. Die Zeilen werden über alle Ausgabespalten gruppiert. Mehrfache Sitzungseinträge desselben Anmeldenamens erscheinen daher nur einmal.\n\nDas Ergebnis hat keine festgelegte Sortierung.\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`. Das Ergebnis kann daher nicht festgeschriebene oder inkonsistente Daten enthalten.\n- Einträge, deren `UserName` in `UsersLoggedIn` kein Leerzeichen enthält, werden nie geliefert. In diesem Fall liefert `PATINDEX` den Wert 0, der extrahierte Name ist leer und die Verknüpfung mit `Users` findet keinen Treffer.\n- Laut Kopfkommentar liefert die Prozedur \"die Anzahl aktiver Verbindungen und angemeldeter Benutzer\". Der Code liefert jedoch eine Liste von Benutzern und keine Anzahl.\n- Die Bedeutung der Werte 1 und 2 von `UserActiveSessionTypeId` ist im Code nicht festgelegt. Wie und wann `UsersLoggedIn` befüllt wird, ist hier ebenfalls nicht ersichtlich.\n- Gibt es keinen Eintrag mit `UserActiveSessionTypeId = 1`, ist das Ergebnis leer.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetUsersFromLastLogin"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Pixi-Benutzer aus dem letzten Anmelde-Snapshot von `UsersLoggedIn` mit Vorname, Nachname und E-Mail-Adresse.\n\nDer Aufruf hat keine Parameter.\n\n1. Ermittelt wird der höchste Wert von `Tag` in `UsersLoggedIn` unter den Einträgen mit `UserActiveSessionTypeId = 1`. Dieser Wert kennzeichnet den zuletzt erfassten Snapshot der angemeldeten Benutzer.\n2. Geliefert werden alle Einträge aus `UsersLoggedIn` mit diesem `Tag` und `UserActiveSessionTypeId` 1 oder 2.\n3. Jeder Eintrag wird mit `Users` verknüpft. Dabei muss der Teil von `UsersLoggedIn.UserName` vor dem ersten Leerzeichen dem Wert `Users.UserName` entsprechen.\n4. Die Zeilen werden über alle Ausgabespalten gruppiert. Mehrfache Sitzungseinträge desselben Anmeldenamens erscheinen daher nur einmal.\n\nDas Ergebnis hat keine festgelegte Sortierung.\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`. Das Ergebnis kann daher nicht festgeschriebene oder inkonsistente Daten enthalten.\n- Einträge, deren `UserName` in `UsersLoggedIn` kein Leerzeichen enthält, werden nie geliefert. In diesem Fall liefert `PATINDEX` den Wert 0, der extrahierte Name ist leer und die Verknüpfung mit `Users` findet keinen Treffer.\n- Laut Kopfkommentar liefert die Prozedur \"die Anzahl aktiver Verbindungen und angemeldeter Benutzer\". Der Code liefert jedoch eine Liste von Benutzern und keine Anzahl.\n- Die Bedeutung der Werte 1 und 2 von `UserActiveSessionTypeId` ist im Code nicht festgelegt. Wie und wann `UsersLoggedIn` befüllt wird, ist hier ebenfalls nicht ersichtlich.\n- Gibt es keinen Eintrag mit `UserActiveSessionTypeId = 1`, ist das Ergebnis leer.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetUsersFromLastLogin"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n mmueller PIXI-WS01\n Martin\n Müller\n m.mueller@example.com\n 48213\n \n \n skrause PIXI-WS07\n Sabine\n Krause\n s.krause@example.com\n 48213\n \n"
}
]
},
{
"name": "pixiGetVATByCountries",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die vollen und ermäßigten Mehrwertsteuersätze je Land, die zu einem Zeitpunkt gültig sind, gefiltert nach ISO-Ländercode und/oder MwSt-Kennzeichen.\n\nErmittelt Mehrwertsteuersätze aus den MwSt-Stammdaten (`VATs`), verknüpft mit den Länderstammdaten (`Countries`) über `VATs.Country = Countries.CntCode`.\n\n**Parameterbehandlung**\n- Leere Zeichenketten in `CntCodeISO2`, `CntCodeISO3` und `ChargeVAT` werden als nicht angegeben (`NULL`) behandelt.\n- Ein `Datetime` vor dem `01.01.1990` wird durch das aktuelle Datum mit Uhrzeit ersetzt.\n\n**Prüfung**\nStatt Daten wird eine Fehlerzeile geliefert, wenn `Datetime` fehlt oder keiner der Parameter `CntCodeISO2`, `CntCodeISO3` und `ChargeVAT` angegeben ist. Erforderlich sind also ein Datum und mindestens ein weiterer Filter.\n\n**Filter**\n- `CntCodeISO2`: nur Länder mit diesem ISO-3166-Alpha-2-Code.\n- `CntCodeISO3`: nur Länder mit diesem ISO-3166-Alpha-3-Code.\n- `ChargeVAT`: nur MwSt-Datensätze mit diesem `ChargeVAT`-Wert.\n- `Datetime`: nur MwSt-Datensätze, deren Gültigkeitszeitraum das Datum enthält (`DateStart` <= `Datetime` <= `DateEnd`, beide Grenzen inklusive).\n\nAlle angegebenen Filter werden mit UND verknüpft. Eine explizite Sortierung gibt es nicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CntCodeISO2` | char(2) | Nein | ISO-3166-Alpha-2-Ländercode als Filter. Leere Zeichenkette bedeutet kein Filter. |\n| `CntCodeISO3` | char(3) | Nein | ISO-3166-Alpha-3-Ländercode als Filter. Leere Zeichenkette bedeutet kein Filter. |\n| `ChargeVAT` | char(1) | Nein | Wert der Spalte `ChargeVAT` des MwSt-Datensatzes als Filter. Leere Zeichenkette bedeutet kein Filter. |\n| `Datetime` | datetime | Nein | Zeitpunkt, zu dem die MwSt-Sätze gültig sein müssen. Faktisch Pflicht: ohne Angabe wird eine Fehlerzeile geliefert. Werte vor dem 01.01.1990 werden durch das aktuelle Datum mit Uhrzeit ersetzt. |\n\n- Beide Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können sichtbar sein.\n- MwSt-Datensätze mit `NULL` in `DateStart` oder `DateEnd` werden nie gefunden, da der Datumsvergleich bei `NULL` nicht wahr ist.\n- Ein sehr altes Datum (vor 1990) liefert stillschweigend die aktuell gültigen Sätze statt historischer Werte.\n- `DateEnd` wird inklusive Uhrzeit verglichen; ist `DateEnd` als Mitternacht gespeichert, passt ein späterer Zeitpunkt am selben Tag nicht mehr.\n- Die Bedeutung der `ChargeVAT`-Werte ist in dieser Prozedur nicht festgelegt, sondern ergibt sich aus dem Inhalt der Tabelle `VATs`.\n- Wird nur ein Ländercode angegeben, können mehrere Zeilen je Land geliefert werden, z. B. eine je `ChargeVAT`-Wert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetVATByCountries"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die vollen und ermäßigten Mehrwertsteuersätze je Land, die zu einem Zeitpunkt gültig sind, gefiltert nach ISO-Ländercode und/oder MwSt-Kennzeichen.\n\nErmittelt Mehrwertsteuersätze aus den MwSt-Stammdaten (`VATs`), verknüpft mit den Länderstammdaten (`Countries`) über `VATs.Country = Countries.CntCode`.\n\n**Parameterbehandlung**\n- Leere Zeichenketten in `CntCodeISO2`, `CntCodeISO3` und `ChargeVAT` werden als nicht angegeben (`NULL`) behandelt.\n- Ein `Datetime` vor dem `01.01.1990` wird durch das aktuelle Datum mit Uhrzeit ersetzt.\n\n**Prüfung**\nStatt Daten wird eine Fehlerzeile geliefert, wenn `Datetime` fehlt oder keiner der Parameter `CntCodeISO2`, `CntCodeISO3` und `ChargeVAT` angegeben ist. Erforderlich sind also ein Datum und mindestens ein weiterer Filter.\n\n**Filter**\n- `CntCodeISO2`: nur Länder mit diesem ISO-3166-Alpha-2-Code.\n- `CntCodeISO3`: nur Länder mit diesem ISO-3166-Alpha-3-Code.\n- `ChargeVAT`: nur MwSt-Datensätze mit diesem `ChargeVAT`-Wert.\n- `Datetime`: nur MwSt-Datensätze, deren Gültigkeitszeitraum das Datum enthält (`DateStart` <= `Datetime` <= `DateEnd`, beide Grenzen inklusive).\n\nAlle angegebenen Filter werden mit UND verknüpft. Eine explizite Sortierung gibt es nicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CntCodeISO2` | char(2) | Nein | ISO-3166-Alpha-2-Ländercode als Filter. Leere Zeichenkette bedeutet kein Filter. |\n| `CntCodeISO3` | char(3) | Nein | ISO-3166-Alpha-3-Ländercode als Filter. Leere Zeichenkette bedeutet kein Filter. |\n| `ChargeVAT` | char(1) | Nein | Wert der Spalte `ChargeVAT` des MwSt-Datensatzes als Filter. Leere Zeichenkette bedeutet kein Filter. |\n| `Datetime` | datetime | Nein | Zeitpunkt, zu dem die MwSt-Sätze gültig sein müssen. Faktisch Pflicht: ohne Angabe wird eine Fehlerzeile geliefert. Werte vor dem 01.01.1990 werden durch das aktuelle Datum mit Uhrzeit ersetzt. |\n\n- Beide Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können sichtbar sein.\n- MwSt-Datensätze mit `NULL` in `DateStart` oder `DateEnd` werden nie gefunden, da der Datumsvergleich bei `NULL` nicht wahr ist.\n- Ein sehr altes Datum (vor 1990) liefert stillschweigend die aktuell gültigen Sätze statt historischer Werte.\n- `DateEnd` wird inklusive Uhrzeit verglichen; ist `DateEnd` als Mitternacht gespeichert, passt ein späterer Zeitpunkt am selben Tag nicht mehr.\n- Die Bedeutung der `ChargeVAT`-Werte ist in dieser Prozedur nicht festgelegt, sondern ergibt sich aus dem Inhalt der Tabelle `VATs`.\n- Wird nur ein Ländercode angegeben, können mehrere Zeilen je Land geliefert werden, z. B. eine je `ChargeVAT`-Wert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetVATByCountries"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Deutschland\n DE\n DEU\n Y\n 19.00\n 7.00\n \n"
}
]
},
{
"name": "pixiGetVATRatesHistory",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Einträge der Änderungshistorie der Mehrwertsteuersätze aus der Tabelle VATsHist.\n\nLiefert alle Zeilen der Historientabelle der Mehrwertsteuersätze `VATsHist` ohne Filter.\n\nJede Zeile enthält die Texte einer Änderung (`HText`, `LText`), eine Bemerkung sowie Datum und Mitarbeiter der Änderung.\n\nDer Aufruf hat keine Parameter. Eine Sortierung ist nicht definiert, die Reihenfolge der Zeilen ist daher nicht garantiert.\n\n- Die Tabelle wird mit `NOLOCK` gelesen, nicht festgeschriebene Änderungen können daher erscheinen.\n- Die genaue Bedeutung von `HText` und `LText` geht aus dem Code nicht hervor. Den Spaltennamen nach handelt es sich vermutlich um einen Kopftext und einen Langtext der Änderung; dies lässt sich aus dem Code nicht bestätigen.\n- Das Ergebnis wird weder begrenzt noch seitenweise ausgegeben. Es werden alle Historieneinträge geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetVATRatesHistory"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Einträge der Änderungshistorie der Mehrwertsteuersätze aus der Tabelle VATsHist.\n\nLiefert alle Zeilen der Historientabelle der Mehrwertsteuersätze `VATsHist` ohne Filter.\n\nJede Zeile enthält die Texte einer Änderung (`HText`, `LText`), eine Bemerkung sowie Datum und Mitarbeiter der Änderung.\n\nDer Aufruf hat keine Parameter. Eine Sortierung ist nicht definiert, die Reihenfolge der Zeilen ist daher nicht garantiert.\n\n- Die Tabelle wird mit `NOLOCK` gelesen, nicht festgeschriebene Änderungen können daher erscheinen.\n- Die genaue Bedeutung von `HText` und `LText` geht aus dem Code nicht hervor. Den Spaltennamen nach handelt es sich vermutlich um einen Kopftext und einen Langtext der Änderung; dies lässt sich aus dem Code nicht bestätigen.\n- Das Ergebnis wird weder begrenzt noch seitenweise ausgegeben. Es werden alle Historieneinträge geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetVATRatesHistory"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n VAT rate 1\n Rate changed from 16.00 to 19.00\n Annual adjustment\n 2021-01-01T00:05:12.000+01:00\n MP\n \n"
}
]
},
{
"name": "pixiGetVersions",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die aktuelle und die minimal zulässige Programmversion der Pixi-Client-Anwendungen, optional für einen Client-Namen.\n\nLiest die Versionsinformationen der Client-Programme aus der Tabelle `ExeClientVersion`.\n\n- Wird `ClientName` weggelassen oder `NULL` übergeben, werden alle Zeilen der Tabelle geliefert.\n- Wird `ClientName` angegeben, werden nur die Zeilen geliefert, deren `ClientName` exakt dem Wert entspricht.\n\nJede Zeile enthält den Client-Namen, die neueste verfügbare Version und die minimal zulässige Version, die ein Client haben muss. Eine Sortierung wird nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ClientName` | varchar(50) | Nein | Name der Client-Anwendung als Filter (exakte Übereinstimmung). `NULL` liefert alle Clients. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen, nicht festgeschriebene Änderungen können sichtbar sein.\n- Das Ergebnis hat kein `ORDER BY`; die Reihenfolge der Zeilen ist nicht garantiert.\n- Ein unbekannter `ClientName` liefert eine leere Ergebnismenge, keinen Fehler.\n- Die Datentypen der Spalten sind im Code nicht ersichtlich; sie stammen aus der Tabelle `ExeClientVersion`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetVersions"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die aktuelle und die minimal zulässige Programmversion der Pixi-Client-Anwendungen, optional für einen Client-Namen.\n\nLiest die Versionsinformationen der Client-Programme aus der Tabelle `ExeClientVersion`.\n\n- Wird `ClientName` weggelassen oder `NULL` übergeben, werden alle Zeilen der Tabelle geliefert.\n- Wird `ClientName` angegeben, werden nur die Zeilen geliefert, deren `ClientName` exakt dem Wert entspricht.\n\nJede Zeile enthält den Client-Namen, die neueste verfügbare Version und die minimal zulässige Version, die ein Client haben muss. Eine Sortierung wird nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ClientName` | varchar(50) | Nein | Name der Client-Anwendung als Filter (exakte Übereinstimmung). `NULL` liefert alle Clients. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen, nicht festgeschriebene Änderungen können sichtbar sein.\n- Das Ergebnis hat kein `ORDER BY`; die Reihenfolge der Zeilen ist nicht garantiert.\n- Ein unbekannter `ClientName` liefert eine leere Ergebnismenge, keinen Fehler.\n- Die Datentypen der Spalten sind im Code nicht ersichtlich; sie stammen aus der Tabelle `ExeClientVersion`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetVersions"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n PixiClient\n 24.3.1.0\n 23.11.0.0\n \n"
}
]
},
{
"name": "pixiImportAddXML",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt ein Auftrags- oder Artikel-Import-XML im Pixi-XML-Log (`C_XMLLog`) mit Status `XIM` an und liefert den Schlüssel des neuen Log-Eintrags.\n\nÜbergibt ein Import-Dokument an den neuen Import-Mechanismus von Pixi, indem es in das XML-Log geschrieben wird.\n\n1. Ist `ParameterXML` nicht leer, ersetzt sein Inhalt `XML`. Ein leerer `OperationType` oder ein leeres `XML` wird als `NULL` behandelt.\n2. `OperationType` wird ohne Beachtung der Groß-/Kleinschreibung ausgewertet:\n - `order` ergibt den Operationstyp `OrderImport`\n - `item` ergibt den Operationstyp `ItemImport`\n - jeder andere Wert, auch `NULL`, wird abgelehnt.\n Der Schlüssel des Operationstyps wird aus `C_OperationTypes` gelesen.\n3. `ChannelRef` wird in `C_Channels` gesucht.\n4. Danach wird in dieser Reihenfolge geprüft: Kanal ist `NULL`, Operationstyp unbekannt, XML fehlt. Die erste fehlgeschlagene Prüfung liefert eine Zeile mit `ErrorNr` = 500 und `ErrorMsg`.\n5. Sind alle Prüfungen erfolgreich, wird das XML in `C_XMLLog` geschrieben, mit `Source` = `API`, `Status` = `XIM`, Benutzer `API`, dem ermittelten Operationstyp und dem Kanal. Der Text wird bereinigt und in den Datentyp XML konvertiert. Schlägt die Konvertierung fehl, werden der Rohtext sowie Fehlernummer und Fehlermeldung der Konvertierung gespeichert. Der Aufruf meldet das nicht als Fehler.\n6. Zurückgegeben wird der Schlüssel des neuen Log-Eintrags. Der Aufruf importiert den Auftrag oder Artikel nicht selbst. Das geschieht später in der Import-Verarbeitung, die nicht Teil dieses Aufrufs ist.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ChannelRef` | int | Nein | Schlüssel des Kanals (`C_Channels.ChannelKey`), zu dem der Import gehört. Nur ein explizites `NULL` wird abgelehnt; unbekannte Schlüssel werden unverändert gespeichert. |\n| `OperationType` | varchar(20) | Nein | Art des Imports, ohne Beachtung der Groß-/Kleinschreibung. Jeder Wert außer `ORDER` oder `ITEM` führt zu einem Fehler. |\n| `XML` | varchar(max) | Nein | Das Import-Dokument als Text, z. B. ein Auftrag oder ein BMEcat-Artikeldokument. Es wird ignoriert, wenn `ParameterXML` gefüllt ist. Ist es leer oder fehlt es, liefert der Aufruf einen Fehler. |\n| `ParameterXML` | varchar(max) | Nein | Alternative zu `XML`. Ist der Wert nicht leer, ersetzt er den Inhalt von `XML`. |\n\n- **Zwei Ergebnismengen bei Erfolg:** Die interne Prozedur `Pixi_C_InsertXML` liefert den neuen Schlüssel bereits als `XMLLogKey` (`SqlRowSet1`). Anschließend liefert der Aufruf denselben Wert noch einmal als `XMLKey` (`SqlRowSet2`). Im Fehlerfall wird nur eine Zeile (`ErrorNr`/`ErrorMsg`) in `SqlRowSet1` geliefert.\n- **Schwache Kanalprüfung:** Existiert `ChannelRef` nicht in `C_Channels`, behält die Variable den übergebenen Wert. Der Fehler `Channel not defined` tritt daher nur auf, wenn `ChannelRef` explizit `NULL` ist. Ein nicht vorhandener Kanal, auch der Standardwert `0`, wird ohne Fehler gespeichert.\n- Wird `order` oder `item` übergeben, fehlt aber der passende Eintrag (`OrderImport`/`ItemImport`) in `C_OperationTypes`, bleibt der Operationstyp `NULL`. Der Eintrag wird dann ohne Operationstyp gespeichert statt abgelehnt.\n- **Ungültiges XML wird nicht abgelehnt.** Eine fehlgeschlagene XML-Konvertierung wird nur in den Log-Spalten `XmlResponseCastErrorNr`/`XmlResponseCastErrorMessage` festgehalten. Das XML sollte vor dem Senden geprüft werden.\n- Das XML wird durch `fPixi_CleanupXmlText` bereinigt. Die Definition dieser Funktion liegt nicht vor.\n- Es wird keine explizite Transaktion verwendet. Die Abfragen auf `C_OperationTypes` und `C_Channels` nutzen `NOLOCK`.\n- Das XML-Dokument muss im SOAP-Element maskiert (oder als CDATA) übergeben werden, da der Parameter ein `varchar(max)`-String ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiImportAddXML"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt ein Auftrags- oder Artikel-Import-XML im Pixi-XML-Log (`C_XMLLog`) mit Status `XIM` an und liefert den Schlüssel des neuen Log-Eintrags.\n\nÜbergibt ein Import-Dokument an den neuen Import-Mechanismus von Pixi, indem es in das XML-Log geschrieben wird.\n\n1. Ist `ParameterXML` nicht leer, ersetzt sein Inhalt `XML`. Ein leerer `OperationType` oder ein leeres `XML` wird als `NULL` behandelt.\n2. `OperationType` wird ohne Beachtung der Groß-/Kleinschreibung ausgewertet:\n - `order` ergibt den Operationstyp `OrderImport`\n - `item` ergibt den Operationstyp `ItemImport`\n - jeder andere Wert, auch `NULL`, wird abgelehnt.\n Der Schlüssel des Operationstyps wird aus `C_OperationTypes` gelesen.\n3. `ChannelRef` wird in `C_Channels` gesucht.\n4. Danach wird in dieser Reihenfolge geprüft: Kanal ist `NULL`, Operationstyp unbekannt, XML fehlt. Die erste fehlgeschlagene Prüfung liefert eine Zeile mit `ErrorNr` = 500 und `ErrorMsg`.\n5. Sind alle Prüfungen erfolgreich, wird das XML in `C_XMLLog` geschrieben, mit `Source` = `API`, `Status` = `XIM`, Benutzer `API`, dem ermittelten Operationstyp und dem Kanal. Der Text wird bereinigt und in den Datentyp XML konvertiert. Schlägt die Konvertierung fehl, werden der Rohtext sowie Fehlernummer und Fehlermeldung der Konvertierung gespeichert. Der Aufruf meldet das nicht als Fehler.\n6. Zurückgegeben wird der Schlüssel des neuen Log-Eintrags. Der Aufruf importiert den Auftrag oder Artikel nicht selbst. Das geschieht später in der Import-Verarbeitung, die nicht Teil dieses Aufrufs ist.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ChannelRef` | int | Nein | Schlüssel des Kanals (`C_Channels.ChannelKey`), zu dem der Import gehört. Nur ein explizites `NULL` wird abgelehnt; unbekannte Schlüssel werden unverändert gespeichert. |\n| `OperationType` | varchar(20) | Nein | Art des Imports, ohne Beachtung der Groß-/Kleinschreibung. Jeder Wert außer `ORDER` oder `ITEM` führt zu einem Fehler. |\n| `XML` | varchar(max) | Nein | Das Import-Dokument als Text, z. B. ein Auftrag oder ein BMEcat-Artikeldokument. Es wird ignoriert, wenn `ParameterXML` gefüllt ist. Ist es leer oder fehlt es, liefert der Aufruf einen Fehler. |\n| `ParameterXML` | varchar(max) | Nein | Alternative zu `XML`. Ist der Wert nicht leer, ersetzt er den Inhalt von `XML`. |\n\n- **Zwei Ergebnismengen bei Erfolg:** Die interne Prozedur `Pixi_C_InsertXML` liefert den neuen Schlüssel bereits als `XMLLogKey` (`SqlRowSet1`). Anschließend liefert der Aufruf denselben Wert noch einmal als `XMLKey` (`SqlRowSet2`). Im Fehlerfall wird nur eine Zeile (`ErrorNr`/`ErrorMsg`) in `SqlRowSet1` geliefert.\n- **Schwache Kanalprüfung:** Existiert `ChannelRef` nicht in `C_Channels`, behält die Variable den übergebenen Wert. Der Fehler `Channel not defined` tritt daher nur auf, wenn `ChannelRef` explizit `NULL` ist. Ein nicht vorhandener Kanal, auch der Standardwert `0`, wird ohne Fehler gespeichert.\n- Wird `order` oder `item` übergeben, fehlt aber der passende Eintrag (`OrderImport`/`ItemImport`) in `C_OperationTypes`, bleibt der Operationstyp `NULL`. Der Eintrag wird dann ohne Operationstyp gespeichert statt abgelehnt.\n- **Ungültiges XML wird nicht abgelehnt.** Eine fehlgeschlagene XML-Konvertierung wird nur in den Log-Spalten `XmlResponseCastErrorNr`/`XmlResponseCastErrorMessage` festgehalten. Das XML sollte vor dem Senden geprüft werden.\n- Das XML wird durch `fPixi_CleanupXmlText` bereinigt. Die Definition dieser Funktion liegt nicht vor.\n- Es wird keine explizite Transaktion verwendet. Die Abfragen auf `C_OperationTypes` und `C_Channels` nutzen `NOLOCK`.\n- Das XML-Dokument muss im SOAP-Element maskiert (oder als CDATA) übergeben werden, da der Parameter ein `varchar(max)`-String ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiImportAddXML"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 58231\n \n"
}
]
},
{
"name": "pixiImportFindXML",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n order\n 100004711\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den neuesten XML-Importlog-Eintrag zu einem Auftrag (über ORDER_ID) oder einem Artikel (über SUPPLIER_AID).\n\nDurchsucht das XML-Importlog `C_XMLLog` nach dem neuesten Eintrag, der eine angegebene ID enthält, und liefert ihn mit Request-, Response- und Statusinformationen.\n\n1. Ist `Id` leer oder `NULL`, wird eine Statuszeile mit `StatusCode` 400 zurückgegeben; weitere Schritte erfolgen nicht.\n2. `Type` wird ohne Beachtung der Groß-/Kleinschreibung ausgewertet:\n - `order`: Ermittelt den Operationstyp `OrderImport` aus `C_OperationTypes` und sucht Logeinträge, deren `XmlResponseXml` ein Element `ORDER_ID` (in beliebiger Tiefe) mit dem Wert von `Id` enthält.\n - `item`: Ermittelt den Operationstyp `ItemImport` und sucht nach einem Element `SUPPLIER_AID` (in beliebiger Tiefe) mit dem Wert von `Id`.\n - Jeder andere Wert liefert eine Statuszeile mit `StatusCode` 400.\n3. Zusätzliche Filter für beide Typen:\n - Ist `Channel` angegeben, werden nur Einträge mit dieser `ChannelRef` berücksichtigt; bei `NULL` werden alle Kanäle durchsucht.\n - Einträge mit `Status` = `XNI` werden ausgeschlossen.\n4. Das Ergebnis wird absteigend nach `XMLLogKey` sortiert, und nur die erste Zeile (der neueste passende Logeintrag) wird geliefert. Gibt es keinen Treffer, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Type` | varchar(10) | Ja | Art des Imports, in dem gesucht wird (ohne Beachtung der Groß-/Kleinschreibung). |\n| `Id` | varchar(50) | Ja | Gesuchter Wert: die Auftrags-ID (`ORDER_ID`) bei `order` bzw. die Lieferantenartikelnummer (`SUPPLIER_AID`) bei `item`. Darf nicht leer sein. |\n| `Channel` | int | Nein | Optionaler Kanalschlüssel (`ChannelRef`) zur Einschränkung der Suche; `NULL` durchsucht alle Kanäle. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; nicht festgeschriebene Logeinträge können daher geliefert werden.\n- Der ID-Vergleich ist ein exakter Zeichenkettenvergleich mit dem Elementwert in `XmlResponseXml` per XPath-`exist()` mit Nachfahrensuche (`//`). Dies wird für jede in Frage kommende Logzeile ausgewertet und kann bei großen Logtabellen langsam sein; die Angabe von `Channel` schränkt die Suche ein.\n- Die Prüfung von `Id` erfolgt vor der Prüfung von `Type`; bei leerer `Id` wird daher immer die ID-Fehlermeldung geliefert, auch wenn `Type` ungültig ist.\n- Existiert der Operationstyp `OrderImport` bzw. `ItemImport` nicht in `C_OperationTypes`, werden keine Zeilen geliefert.\n- Die Bedeutung des Statuswerts `XNI` ist im Code nicht definiert.\n- `Response` ist die XML-Spalte `XmlResponseXml`, konvertiert nach `varchar(max)`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiImportFindXML"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n order\n 100004711\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den neuesten XML-Importlog-Eintrag zu einem Auftrag (über ORDER_ID) oder einem Artikel (über SUPPLIER_AID).\n\nDurchsucht das XML-Importlog `C_XMLLog` nach dem neuesten Eintrag, der eine angegebene ID enthält, und liefert ihn mit Request-, Response- und Statusinformationen.\n\n1. Ist `Id` leer oder `NULL`, wird eine Statuszeile mit `StatusCode` 400 zurückgegeben; weitere Schritte erfolgen nicht.\n2. `Type` wird ohne Beachtung der Groß-/Kleinschreibung ausgewertet:\n - `order`: Ermittelt den Operationstyp `OrderImport` aus `C_OperationTypes` und sucht Logeinträge, deren `XmlResponseXml` ein Element `ORDER_ID` (in beliebiger Tiefe) mit dem Wert von `Id` enthält.\n - `item`: Ermittelt den Operationstyp `ItemImport` und sucht nach einem Element `SUPPLIER_AID` (in beliebiger Tiefe) mit dem Wert von `Id`.\n - Jeder andere Wert liefert eine Statuszeile mit `StatusCode` 400.\n3. Zusätzliche Filter für beide Typen:\n - Ist `Channel` angegeben, werden nur Einträge mit dieser `ChannelRef` berücksichtigt; bei `NULL` werden alle Kanäle durchsucht.\n - Einträge mit `Status` = `XNI` werden ausgeschlossen.\n4. Das Ergebnis wird absteigend nach `XMLLogKey` sortiert, und nur die erste Zeile (der neueste passende Logeintrag) wird geliefert. Gibt es keinen Treffer, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Type` | varchar(10) | Ja | Art des Imports, in dem gesucht wird (ohne Beachtung der Groß-/Kleinschreibung). |\n| `Id` | varchar(50) | Ja | Gesuchter Wert: die Auftrags-ID (`ORDER_ID`) bei `order` bzw. die Lieferantenartikelnummer (`SUPPLIER_AID`) bei `item`. Darf nicht leer sein. |\n| `Channel` | int | Nein | Optionaler Kanalschlüssel (`ChannelRef`) zur Einschränkung der Suche; `NULL` durchsucht alle Kanäle. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; nicht festgeschriebene Logeinträge können daher geliefert werden.\n- Der ID-Vergleich ist ein exakter Zeichenkettenvergleich mit dem Elementwert in `XmlResponseXml` per XPath-`exist()` mit Nachfahrensuche (`//`). Dies wird für jede in Frage kommende Logzeile ausgewertet und kann bei großen Logtabellen langsam sein; die Angabe von `Channel` schränkt die Suche ein.\n- Die Prüfung von `Id` erfolgt vor der Prüfung von `Type`; bei leerer `Id` wird daher immer die ID-Fehlermeldung geliefert, auch wenn `Type` ungültig ist.\n- Existiert der Operationstyp `OrderImport` bzw. `ItemImport` nicht in `C_OperationTypes`, werden keine Zeilen geliefert.\n- Die Bedeutung des Statuswerts `XNI` ist im Code nicht definiert.\n- `Response` ist die XML-Spalte `XmlResponseXml`, konvertiert nach `varchar(max)`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiImportFindXML"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 58231\n <ORDER>...</ORDER>\n <ORDER><ORDER_HEADER><ORDER_INFO><ORDER_ID>100004711</ORDER_ID></ORDER_INFO></ORDER_HEADER></ORDER>\n OK\n 2024-03-12T10:15:22\n 2024-03-12T10:15:25\n \n 0\n \n \n"
}
]
},
{
"name": "pixiImportGetChannels",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle in Pixi angelegten Channels mit Schlüssel, Name und Name des Channel-Typs.\n\nLiefert eine Zeile je Channel aus `C_Channels`. Der Aufruf hat keine Parameter und wendet keinen Filter an.\n\nJe Channel werden zurückgegeben:\n\n- der Channel-Schlüssel (`ChannelKey`)\n- der Channel-Name (`ChannelName`)\n- der Name des Channel-Typs (`ChannelType`). Dieser Wert wird über `ChannelTypeRef` des Channels in `C_ChannelTypes` nachgeschlagen.\n\nDer Code legt keine Sortierung fest, die Reihenfolge der Zeilen ist daher nicht garantiert.\n\n- Beide Tabellen werden mit `NOLOCK` gelesen. Nicht festgeschriebene Änderungen können daher im Ergebnis erscheinen.\n- `ChannelType` ist `NULL`, wenn zum `ChannelTypeRef` des Channels kein Channel-Typ existiert.\n- Die Datentypen der Spalten sind im Code nicht ersichtlich, da die Tabellendefinitionen nicht beigefügt sind.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiImportGetChannels"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle in Pixi angelegten Channels mit Schlüssel, Name und Name des Channel-Typs.\n\nLiefert eine Zeile je Channel aus `C_Channels`. Der Aufruf hat keine Parameter und wendet keinen Filter an.\n\nJe Channel werden zurückgegeben:\n\n- der Channel-Schlüssel (`ChannelKey`)\n- der Channel-Name (`ChannelName`)\n- der Name des Channel-Typs (`ChannelType`). Dieser Wert wird über `ChannelTypeRef` des Channels in `C_ChannelTypes` nachgeschlagen.\n\nDer Code legt keine Sortierung fest, die Reihenfolge der Zeilen ist daher nicht garantiert.\n\n- Beide Tabellen werden mit `NOLOCK` gelesen. Nicht festgeschriebene Änderungen können daher im Ergebnis erscheinen.\n- `ChannelType` ist `NULL`, wenn zum `ChannelTypeRef` des Channels kein Channel-Typ existiert.\n- Die Datentypen der Spalten sind im Code nicht ersichtlich, da die Tabellendefinitionen nicht beigefügt sind.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiImportGetChannels"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n Webshop DE\n Shop\n \n \n 2\n Amazon DE\n Marketplace\n \n"
}
]
},
{
"name": "pixiImportGetChannelSettings",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Name, Kanaltyp und alle Einstellungen eines einzelnen Import-Kanals.\n\nLiest den über `ChannelKey` angegebenen Kanal aus der Kanaltabelle und liefert eine Zeile pro Einstellung dieses Kanals.\n\n- Der Name des Kanaltyps wird über die Typreferenz des Kanals ergänzt (Left Join, daher leer, wenn der Typ fehlt).\n- Die Einstellungen werden per Left Join verknüpft. Ein Kanal ohne Einstellungen liefert daher trotzdem **eine Zeile** mit leerem `SettingName` und `SettingValue`.\n- Existiert kein Kanal mit dem angegebenen Schlüssel, werden keine Zeilen geliefert.\n\nEine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ChannelKey` | int | Nein | Schlüssel des Kanals, dessen Einstellungen geliefert werden. |\n\nAlle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein. Der Standardwert `0` für `ChannelKey` trifft in der Regel keinen Kanal; der Schlüssel sollte immer explizit übergeben werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiImportGetChannelSettings"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Name, Kanaltyp und alle Einstellungen eines einzelnen Import-Kanals.\n\nLiest den über `ChannelKey` angegebenen Kanal aus der Kanaltabelle und liefert eine Zeile pro Einstellung dieses Kanals.\n\n- Der Name des Kanaltyps wird über die Typreferenz des Kanals ergänzt (Left Join, daher leer, wenn der Typ fehlt).\n- Die Einstellungen werden per Left Join verknüpft. Ein Kanal ohne Einstellungen liefert daher trotzdem **eine Zeile** mit leerem `SettingName` und `SettingValue`.\n- Existiert kein Kanal mit dem angegebenen Schlüssel, werden keine Zeilen geliefert.\n\nEine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ChannelKey` | int | Nein | Schlüssel des Kanals, dessen Einstellungen geliefert werden. |\n\nAlle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein. Der Standardwert `0` für `ChannelKey` trifft in der Regel keinen Kanal; der Schlüssel sollte immer explizit übergeben werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiImportGetChannelSettings"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Shop DE\n Shopware\n ApiUrl\n https://shop.example.de/api\n \n \n Shop DE\n Shopware\n ImportInterval\n 15\n \n"
}
]
},
{
"name": "pixiImportGetXML",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Eintrag des XML-Importprotokolls (`C_XMLLog`) mit Request, Response, Status und Fehlerinformationen zu einem Protokollschlüssel.\n\nLiest einen oder mehrere Datensätze aus der XML-Importprotokolltabelle `C_XMLLog`.\n\n- Eine Zeile wird geliefert, wenn `XMLLogKey` gleich `@XMLLogKey` **oder** `@LogKeyXML` ist.\n- Beide Parameter haben dieselbe Wirkung. `@LogKeyXML` ist ein alternativer Name für denselben Schlüssel. Werden beide mit unterschiedlichen Werten übergeben, können bis zu zwei Protokolleinträge geliefert werden.\n- Das Ergebnis enthält den Roh-Request und die Roh-Response, deren in XML umgewandelte Fassungen, den Verarbeitungsstatus, den Operationstyp, den Kanal, die Anzahl der Verarbeitungsversuche, Fehlertexte sowie Anlage- und Änderungsinformationen.\n\nEine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `XMLLogKey` | int | Nein | Schlüssel des XML-Protokolleintrags (`C_XMLLog.XMLLogKey`), der geliefert werden soll. |\n| `LogKeyXML` | int | Nein | Alternativer Parameter für den Protokollschlüssel. Er wird mit `XMLLogKey` per ODER verknüpft. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen. Einträge, die gerade verarbeitet werden, können in nicht festgeschriebenem Zustand geliefert werden.\n- Beide Parameter haben den Standardwert `0`. Wird keiner übergeben, passt nur ein Protokolleintrag mit Schlüssel `0`, der in der Regel nicht existiert. Das Ergebnis ist dann leer.\n- Die Definition von `C_XMLLog` liegt nicht vor. Die Datentypen der Spalten sind daher teilweise unbekannt. `XmlRequestXml`/`XmlResponseXml` und die `...CastError...`-Spalten enthalten vermutlich das Ergebnis der Umwandlung des Rohtexts in XML sowie einen eventuellen Umwandlungsfehler.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiImportGetXML"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Eintrag des XML-Importprotokolls (`C_XMLLog`) mit Request, Response, Status und Fehlerinformationen zu einem Protokollschlüssel.\n\nLiest einen oder mehrere Datensätze aus der XML-Importprotokolltabelle `C_XMLLog`.\n\n- Eine Zeile wird geliefert, wenn `XMLLogKey` gleich `@XMLLogKey` **oder** `@LogKeyXML` ist.\n- Beide Parameter haben dieselbe Wirkung. `@LogKeyXML` ist ein alternativer Name für denselben Schlüssel. Werden beide mit unterschiedlichen Werten übergeben, können bis zu zwei Protokolleinträge geliefert werden.\n- Das Ergebnis enthält den Roh-Request und die Roh-Response, deren in XML umgewandelte Fassungen, den Verarbeitungsstatus, den Operationstyp, den Kanal, die Anzahl der Verarbeitungsversuche, Fehlertexte sowie Anlage- und Änderungsinformationen.\n\nEine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `XMLLogKey` | int | Nein | Schlüssel des XML-Protokolleintrags (`C_XMLLog.XMLLogKey`), der geliefert werden soll. |\n| `LogKeyXML` | int | Nein | Alternativer Parameter für den Protokollschlüssel. Er wird mit `XMLLogKey` per ODER verknüpft. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen. Einträge, die gerade verarbeitet werden, können in nicht festgeschriebenem Zustand geliefert werden.\n- Beide Parameter haben den Standardwert `0`. Wird keiner übergeben, passt nur ein Protokolleintrag mit Schlüssel `0`, der in der Regel nicht existiert. Das Ergebnis ist dann leer.\n- Die Definition von `C_XMLLog` liegt nicht vor. Die Datentypen der Spalten sind daher teilweise unbekannt. `XmlRequestXml`/`XmlResponseXml` und die `...CastError...`-Spalten enthalten vermutlich das Ergebnis der Umwandlung des Rohtexts in XML sowie einen eventuellen Umwandlungsfehler.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiImportGetXML"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 123456\n Shop\n <Order>...</Order>\n <Result>OK</Result>\n OK\n 1\n API\n 2024-03-15T10:22:31\n API\n 2024-03-15T10:22:33\n 2\n 1\n \n 0\n 0\n \n"
}
]
},
{
"name": "pixiImportProcessXML",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Verarbeitet ein importiertes Artikel- oder Auftrags-XML aus C_XMLLog sofort (Parsen, Prüfen, Übernahme in Haupttabellen), ohne auf den SQL-Agent-Importjob zu warten.\n\nStößt die Verarbeitung eines importierten XML, identifiziert über `XMLLogKey`, sofort an.\n\n1. **Prüfung**: Das XML muss in `C_XMLLog` existieren, sein Operationstyp (`C_OperationTypes.OperationType`) muss `ItemImport` oder `OrderImport` sein und sein `Status` einer der Werte `COC`, `ERR`, `NEI`, `XER`, `XIM` oder `XPA`. Andernfalls wird eine Statuszeile mit `ReturnCode` = `ERROR API` geliefert.\n2. **Artikel-XML** (`ItemImport`):\n - Ist der Application Lock `PixiItemImport` bereits belegt (der Artikelimport-Agent-Job läuft), wird für dieses XML nur der Parse-Schritt `Pixi_C_ParseAndCheckXMLsFromItemImport` ausgeführt; der Aufruf endet mit einer `ERROR API`-Zeile, dass das XML bereits in Verarbeitung ist und geparst wurde.\n - Andernfalls setzt der Aufruf den Lock selbst, führt Parsen/Prüfen und anschließend `Pixi_C_ApplyItemsToMainTables` für dieses XML aus und gibt den Lock wieder frei.\n3. **Auftrags-XML** (`OrderImport`): gleiche Logik mit Lock `PixiOrderImport`, Parse-Schritt `Pixi_C_ParseAndCheckXMLsFromOrderImport` und Übernahme-Schritt `Pixi_C_ApplyOrdersToMainTables`.\n4. Zum Schluss wird eine Statuszeile mit `ReturnCode` = `OK` geliefert.\n\nAlle aufgerufenen Prozeduren laufen mit dem Benutzernamen `API`.\n\nDa die aufgerufenen Prozeduren eigene Zeilen zurückgeben, erhält der Aufrufer mehrere Ergebnismengen: die `Success`-Zeile des Parse-Schritts, ggf. Zeilen des Übernahme-Schritts und zuletzt die Statuszeile `ReturnCode`/`ErrorMessage`. Für das Ergebnis ist immer die **letzte** Ergebnismenge auszuwerten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `XMLLogKey` | int | Ja | Schlüssel des importierten XML in `C_XMLLog`, das (erneut) verarbeitet werden soll. Muss ein Artikel- oder Auftragsimport-XML im Status `COC`, `ERR`, `NEI`, `XER`, `XIM` oder `XPA` sein. |\n\n- **Fehler beim Parsen/Übernehmen werden verschluckt**: Parse- und Übernahme-Schritt laufen in einem inneren `TRY/CATCH`, der nur den Application Lock freigibt. Schlägt einer fehl, liefert der Aufruf trotzdem `ReturnCode` = `OK`. Das tatsächliche Ergebnis ist anschließend über `C_XMLLog.Status`/`Error` zu prüfen.\n- Die Info-Meldung `XML with XMLLogKey {XMLLogKey} has been processed.` wird mit Schweregrad 1 ausgelöst und kann als `SqlMessage` erscheinen; sie ist kein Fehler.\n- Im Fall „bereits in Verarbeitung“ **wurde** das XML geparst, obwohl `ReturnCode` = `ERROR API` ist.\n- Die Application Locks `PixiItemImport` / `PixiOrderImport` (Owner Session) werden mit den SQL-Agent-Importjobs geteilt; solange der Aufruf den Lock hält, kann der Agent-Job nicht parallel verarbeiten.\n- Die aufgerufenen Prozeduren berücksichtigen die Einstellungen `C_ItemImportEnabled`, `C_ItemImport_ParseAndCheckData_Enabled`, `C_OrderImportEnabled`, `C_OrderImport_ParseAndCheckData_Enabled`, `C_OrderImport_ApplyToMainTables_Enabled` sowie Einstellungen je Kanaltyp. Sind diese deaktiviert, tun die Schritte nichts, der Aufruf liefert aber trotzdem `OK`.\n- Die Parse-Schritte parsen nur XMLs des Kanaltyps `URL` mit leerer Spalte `Error`. XMLs der Kanaltypen `PlentyREST` oder `ShipRush` werden nur auf Status `XIM` (mit `AttemptsToProcess` = 0) zurückgesetzt, damit der Integration Service sie erneut parst.\n- Die Parse-Schritte führen auch globale Arbeiten aus (z. B. `pixi_C_UpdateXMLsAsParsed`, Wechselkursimport bei Aufträgen), der Auftrags-Übernahme-Schritt ruft `Pixi_AmazonOrdersMarkOrders` auf.\n- Die Einstellung `C_ParseAndImportDataIntervalMinutes` wird gelesen, aber nicht verwendet.\n- `Pixi_C_ApplyItemsToMainTables` liegt nicht vor; dessen genaues Verhalten und zurückgegebene Zeilen sind unbekannt.\n- Existenz- und Statusprüfungen verwenden `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiImportProcessXML"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Verarbeitet ein importiertes Artikel- oder Auftrags-XML aus C_XMLLog sofort (Parsen, Prüfen, Übernahme in Haupttabellen), ohne auf den SQL-Agent-Importjob zu warten.\n\nStößt die Verarbeitung eines importierten XML, identifiziert über `XMLLogKey`, sofort an.\n\n1. **Prüfung**: Das XML muss in `C_XMLLog` existieren, sein Operationstyp (`C_OperationTypes.OperationType`) muss `ItemImport` oder `OrderImport` sein und sein `Status` einer der Werte `COC`, `ERR`, `NEI`, `XER`, `XIM` oder `XPA`. Andernfalls wird eine Statuszeile mit `ReturnCode` = `ERROR API` geliefert.\n2. **Artikel-XML** (`ItemImport`):\n - Ist der Application Lock `PixiItemImport` bereits belegt (der Artikelimport-Agent-Job läuft), wird für dieses XML nur der Parse-Schritt `Pixi_C_ParseAndCheckXMLsFromItemImport` ausgeführt; der Aufruf endet mit einer `ERROR API`-Zeile, dass das XML bereits in Verarbeitung ist und geparst wurde.\n - Andernfalls setzt der Aufruf den Lock selbst, führt Parsen/Prüfen und anschließend `Pixi_C_ApplyItemsToMainTables` für dieses XML aus und gibt den Lock wieder frei.\n3. **Auftrags-XML** (`OrderImport`): gleiche Logik mit Lock `PixiOrderImport`, Parse-Schritt `Pixi_C_ParseAndCheckXMLsFromOrderImport` und Übernahme-Schritt `Pixi_C_ApplyOrdersToMainTables`.\n4. Zum Schluss wird eine Statuszeile mit `ReturnCode` = `OK` geliefert.\n\nAlle aufgerufenen Prozeduren laufen mit dem Benutzernamen `API`.\n\nDa die aufgerufenen Prozeduren eigene Zeilen zurückgeben, erhält der Aufrufer mehrere Ergebnismengen: die `Success`-Zeile des Parse-Schritts, ggf. Zeilen des Übernahme-Schritts und zuletzt die Statuszeile `ReturnCode`/`ErrorMessage`. Für das Ergebnis ist immer die **letzte** Ergebnismenge auszuwerten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `XMLLogKey` | int | Ja | Schlüssel des importierten XML in `C_XMLLog`, das (erneut) verarbeitet werden soll. Muss ein Artikel- oder Auftragsimport-XML im Status `COC`, `ERR`, `NEI`, `XER`, `XIM` oder `XPA` sein. |\n\n- **Fehler beim Parsen/Übernehmen werden verschluckt**: Parse- und Übernahme-Schritt laufen in einem inneren `TRY/CATCH`, der nur den Application Lock freigibt. Schlägt einer fehl, liefert der Aufruf trotzdem `ReturnCode` = `OK`. Das tatsächliche Ergebnis ist anschließend über `C_XMLLog.Status`/`Error` zu prüfen.\n- Die Info-Meldung `XML with XMLLogKey {XMLLogKey} has been processed.` wird mit Schweregrad 1 ausgelöst und kann als `SqlMessage` erscheinen; sie ist kein Fehler.\n- Im Fall „bereits in Verarbeitung“ **wurde** das XML geparst, obwohl `ReturnCode` = `ERROR API` ist.\n- Die Application Locks `PixiItemImport` / `PixiOrderImport` (Owner Session) werden mit den SQL-Agent-Importjobs geteilt; solange der Aufruf den Lock hält, kann der Agent-Job nicht parallel verarbeiten.\n- Die aufgerufenen Prozeduren berücksichtigen die Einstellungen `C_ItemImportEnabled`, `C_ItemImport_ParseAndCheckData_Enabled`, `C_OrderImportEnabled`, `C_OrderImport_ParseAndCheckData_Enabled`, `C_OrderImport_ApplyToMainTables_Enabled` sowie Einstellungen je Kanaltyp. Sind diese deaktiviert, tun die Schritte nichts, der Aufruf liefert aber trotzdem `OK`.\n- Die Parse-Schritte parsen nur XMLs des Kanaltyps `URL` mit leerer Spalte `Error`. XMLs der Kanaltypen `PlentyREST` oder `ShipRush` werden nur auf Status `XIM` (mit `AttemptsToProcess` = 0) zurückgesetzt, damit der Integration Service sie erneut parst.\n- Die Parse-Schritte führen auch globale Arbeiten aus (z. B. `pixi_C_UpdateXMLsAsParsed`, Wechselkursimport bei Aufträgen), der Auftrags-Übernahme-Schritt ruft `Pixi_AmazonOrdersMarkOrders` auf.\n- Die Einstellung `C_ParseAndImportDataIntervalMinutes` wird gelesen, aber nicht verwendet.\n- `Pixi_C_ApplyItemsToMainTables` liegt nicht vor; dessen genaues Verhalten und zurückgegebene Zeilen sind unbekannt.\n- Existenz- und Statusprüfungen verwenden `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiImportProcessXML"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n \n"
}
]
},
{
"name": "pixiInfoSettingsHist",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Änderungshistorie der Pixi-Einstellungen in einem Datumsbereich, neueste Änderungen zuerst, optional auf eine Anzahl Zeilen begrenzt.\n\nLiest das Änderungsprotokoll der Einstellungen aus der Tabelle `SettingsHist` und liefert eine Zeile je protokollierter Änderung.\n\n- Das wirksame Änderungsdatum eines Eintrags ist `UpdateDate` bzw. `CreateDate`, falls `UpdateDate` leer ist. Dieselbe Logik gilt für den Mitarbeiter: `UpdateEmp`, sonst `CreateEmp`.\n- Es werden nur Einträge geliefert, deren wirksames Änderungsdatum zwischen `FromDate` und `ToDate` liegt (jeweils einschließlich).\n- Wird `FromDate` weggelassen, ist `NULL` oder liegt das Jahr vor 1990, wird `1970-01-01` verwendet, d. h. es gibt keine untere Grenze.\n- Wird `ToDate` weggelassen, ist `NULL` oder liegt das Jahr vor 1990, wird das aktuelle Datum mit Uhrzeit verwendet.\n- Die Sortierung erfolgt absteigend nach dem wirksamen Änderungsdatum (neueste zuerst).\n- Ist `Rows` größer als 0, werden nur so viele Zeilen geliefert (per `SET ROWCOUNT`). Bei `0` (Standard) werden alle passenden Zeilen geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Nein | Beginn des Datumsbereichs (einschließlich) für das wirksame Änderungsdatum. `NULL` oder ein Jahr vor 1990 bedeutet keine untere Grenze (`1970-01-01`). |\n| `ToDate` | datetime | Nein | Ende des Datumsbereichs (einschließlich) für das wirksame Änderungsdatum. `NULL` oder ein Jahr vor 1990 bedeutet das aktuelle Datum mit Uhrzeit. |\n| `Rows` | int | Nein | Maximale Anzahl zurückgegebener Zeilen. `0` oder kleiner liefert alle passenden Zeilen. |\n\n- Die Tabelle wird `WITH(NOLOCK)` gelesen, daher können nicht festgeschriebene Änderungen erscheinen.\n- `ToDate` wird inklusive Uhrzeit verglichen. Ein Wert wie `2024-03-31` (Mitternacht) schließt spätere Änderungen dieses Tages aus; für den ganzen Tag `2024-03-31T23:59:59` oder den Folgetag übergeben.\n- Der Filter auf einen `ISNULL`-Ausdruck verhindert die Indexnutzung auf den Datumsspalten; bei großen Historientabellen empfehlen sich enge Datumsbereiche oder eine Begrenzung über `Rows`.\n- Die genauen Datentypen der Spalten von `SettingsHist` sind im Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiInfoSettingsHist"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Änderungshistorie der Pixi-Einstellungen in einem Datumsbereich, neueste Änderungen zuerst, optional auf eine Anzahl Zeilen begrenzt.\n\nLiest das Änderungsprotokoll der Einstellungen aus der Tabelle `SettingsHist` und liefert eine Zeile je protokollierter Änderung.\n\n- Das wirksame Änderungsdatum eines Eintrags ist `UpdateDate` bzw. `CreateDate`, falls `UpdateDate` leer ist. Dieselbe Logik gilt für den Mitarbeiter: `UpdateEmp`, sonst `CreateEmp`.\n- Es werden nur Einträge geliefert, deren wirksames Änderungsdatum zwischen `FromDate` und `ToDate` liegt (jeweils einschließlich).\n- Wird `FromDate` weggelassen, ist `NULL` oder liegt das Jahr vor 1990, wird `1970-01-01` verwendet, d. h. es gibt keine untere Grenze.\n- Wird `ToDate` weggelassen, ist `NULL` oder liegt das Jahr vor 1990, wird das aktuelle Datum mit Uhrzeit verwendet.\n- Die Sortierung erfolgt absteigend nach dem wirksamen Änderungsdatum (neueste zuerst).\n- Ist `Rows` größer als 0, werden nur so viele Zeilen geliefert (per `SET ROWCOUNT`). Bei `0` (Standard) werden alle passenden Zeilen geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Nein | Beginn des Datumsbereichs (einschließlich) für das wirksame Änderungsdatum. `NULL` oder ein Jahr vor 1990 bedeutet keine untere Grenze (`1970-01-01`). |\n| `ToDate` | datetime | Nein | Ende des Datumsbereichs (einschließlich) für das wirksame Änderungsdatum. `NULL` oder ein Jahr vor 1990 bedeutet das aktuelle Datum mit Uhrzeit. |\n| `Rows` | int | Nein | Maximale Anzahl zurückgegebener Zeilen. `0` oder kleiner liefert alle passenden Zeilen. |\n\n- Die Tabelle wird `WITH(NOLOCK)` gelesen, daher können nicht festgeschriebene Änderungen erscheinen.\n- `ToDate` wird inklusive Uhrzeit verglichen. Ein Wert wie `2024-03-31` (Mitternacht) schließt spätere Änderungen dieses Tages aus; für den ganzen Tag `2024-03-31T23:59:59` oder den Folgetag übergeben.\n- Der Filter auf einen `ISNULL`-Ausdruck verhindert die Indexnutzung auf den Datumsspalten; bei großen Historientabellen empfehlen sich enge Datumsbereiche oder eine Begrenzung über `Rows`.\n- Die genauen Datentypen der Spalten von `SettingsHist` sind im Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiInfoSettingsHist"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n DefaultShippingMethod\n DHL\n UPS\n 2024-03-15T10:42:00\n MM\n Changed via settings dialog\n \n \n InvoiceCopies\n 1\n 2\n 2024-02-01T08:15:30\n AB\n \n \n"
}
]
},
{
"name": "pixiMetadata",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n pixiGetItemInfo\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Eingabeparameter eines Pixi-API-Calls mit Namen, Datentyp und maximaler Länge.\n\nErmittelt die Eingabeparameter eines API-Calls aus der SQL-Server-Katalogsicht `INFORMATION_SCHEMA.PARAMETERS` der aktuellen Datenbank.\n\n1. Jedes Vorkommen von `pixi` in `procedure` wird durch `pipi` ersetzt. Es können daher sowohl der SOAP-Name (`pixiItemSearch`) als auch der SQL-Name (`pipiItemSearch`) übergeben werden.\n2. Beginnt der so entstandene Name nicht mit `pipi`, wird eine Statuszeile mit `ErrNr` = `403` und `ErrMessage` = `No such API call` zurückgegeben.\n3. Anschließend wird in jedem Fall die Parameterliste des Objekts geliefert:\n - nur Objekte der aktuellen Datenbank (`SPECIFIC_CATALOG = DB_NAME()`),\n - nur Parameter mit `PARAMETER_MODE = 'IN'`,\n - das führende `@` wird aus dem Parameternamen entfernt,\n - sortiert nach der deklarierten Parameterposition.\n\nExistiert der Call nicht, ist die Parameterergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `procedure` | varchar(50) | Ja | Name des API-Calls, dessen Parameter abgefragt werden. Entweder der SOAP-Name (`pixi…`) oder der SQL-Name (`pipi…`). |\n\n- Nach der Fehlerzeile wird die Prozedur **nicht** beendet. In diesem Fall werden zwei Ergebnismengen geliefert: die Fehlerzeile in `SqlRowSet1` und die (meist leere) Parameterliste in `SqlRowSet2`. Ohne Fehler ist die Parameterliste `SqlRowSet1`.\n- Da die Ausführung fortgesetzt wird, werden die Parameter eines Objekts ohne `pipi`-Präfix trotzdem geliefert, sofern ein Objekt mit diesem Namen existiert.\n- `REPLACE` ersetzt jedes Vorkommen von `pixi` im Namen, nicht nur das Präfix. Ob Ersetzung und Präfixprüfung Groß-/Kleinschreibung beachten, hängt von der Sortierung (Collation) der Datenbank ab.\n- `OUTPUT`-Parameter (Modus `INOUT`) und der Rückgabewert skalarer Funktionen werden nicht aufgeführt. Standardwerte und Pflichtangaben werden nicht geliefert.\n- `CHARACTER_MAXIMUM_LENGTH` ist `NULL` bei Nicht-Zeichentypen und `-1` bei `(max)`-Typen.\n- Die Sichtbarkeit in `INFORMATION_SCHEMA` hängt von den Berechtigungen des Datenbankbenutzers ab.\n- Die Katalogsicht wird mit `NOLOCK` gelesen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiMetadata"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n pixiGetItemInfo\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Eingabeparameter eines Pixi-API-Calls mit Namen, Datentyp und maximaler Länge.\n\nErmittelt die Eingabeparameter eines API-Calls aus der SQL-Server-Katalogsicht `INFORMATION_SCHEMA.PARAMETERS` der aktuellen Datenbank.\n\n1. Jedes Vorkommen von `pixi` in `procedure` wird durch `pipi` ersetzt. Es können daher sowohl der SOAP-Name (`pixiItemSearch`) als auch der SQL-Name (`pipiItemSearch`) übergeben werden.\n2. Beginnt der so entstandene Name nicht mit `pipi`, wird eine Statuszeile mit `ErrNr` = `403` und `ErrMessage` = `No such API call` zurückgegeben.\n3. Anschließend wird in jedem Fall die Parameterliste des Objekts geliefert:\n - nur Objekte der aktuellen Datenbank (`SPECIFIC_CATALOG = DB_NAME()`),\n - nur Parameter mit `PARAMETER_MODE = 'IN'`,\n - das führende `@` wird aus dem Parameternamen entfernt,\n - sortiert nach der deklarierten Parameterposition.\n\nExistiert der Call nicht, ist die Parameterergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `procedure` | varchar(50) | Ja | Name des API-Calls, dessen Parameter abgefragt werden. Entweder der SOAP-Name (`pixi…`) oder der SQL-Name (`pipi…`). |\n\n- Nach der Fehlerzeile wird die Prozedur **nicht** beendet. In diesem Fall werden zwei Ergebnismengen geliefert: die Fehlerzeile in `SqlRowSet1` und die (meist leere) Parameterliste in `SqlRowSet2`. Ohne Fehler ist die Parameterliste `SqlRowSet1`.\n- Da die Ausführung fortgesetzt wird, werden die Parameter eines Objekts ohne `pipi`-Präfix trotzdem geliefert, sofern ein Objekt mit diesem Namen existiert.\n- `REPLACE` ersetzt jedes Vorkommen von `pixi` im Namen, nicht nur das Präfix. Ob Ersetzung und Präfixprüfung Groß-/Kleinschreibung beachten, hängt von der Sortierung (Collation) der Datenbank ab.\n- `OUTPUT`-Parameter (Modus `INOUT`) und der Rückgabewert skalarer Funktionen werden nicht aufgeführt. Standardwerte und Pflichtangaben werden nicht geliefert.\n- `CHARACTER_MAXIMUM_LENGTH` ist `NULL` bei Nicht-Zeichentypen und `-1` bei `(max)`-Typen.\n- Die Sichtbarkeit in `INFORMATION_SCHEMA` hängt von den Berechtigungen des Datenbankbenutzers ab.\n- Die Katalogsicht wird mit `NOLOCK` gelesen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiMetadata"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n pipiMetadata\n procedure\n varchar\n 50\n \n"
}
]
},
{
"name": "pixiReadCodeTableValues",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Codetabellenwerte aus pixi.CodeTableValue mit übersetzter Beschreibung, entweder einen einzelnen Wert per Id oder eine Seite von Werten nach einer Id.\n\nLiest Einträge der Codetabelle `pixi.CodeTableValue` zusammen mit ihrem Beschreibungstext aus `dbo.Translation`.\n\n1. Wird `Id` nicht übergeben, wird der Wert auf `0` gesetzt.\n2. Es werden die Übersetzungen mit `DBObjectName = 'CodeTableValue'` und `LanguageID = @LanguageId` geladen. Die Zuordnung erfolgt über die `Id` des Werts.\n3. Danach arbeitet der Aufruf in einem von zwei Modi:\n - **Paging-Modus** (`RowCount` gesetzt): liefert höchstens `RowCount` Werte mit `Id > @Id`, sortiert nach `Id` aufsteigend. Für die nächste Seite wird die letzte `Id` der vorherigen Seite als `Id` übergeben. Für den Start wird `Id` = `0` übergeben oder weggelassen.\n - **Einzelmodus** (`RowCount` nicht gesetzt): liefert den Wert mit `Id = @Id`.\n\nDie Verknüpfung mit den Übersetzungen ist ein Inner Join. Werte ohne Übersetzung in der angeforderten Sprache werden nicht geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Id` | int | Nein | Ohne `RowCount`: die `Id` des zu liefernden Codetabellenwerts. Mit `RowCount`: es werden Werte mit einer größeren `Id` geliefert (Paging). `NULL` wird als `0` behandelt. |\n| `RowCount` | int | Nein | Maximale Anzahl Zeilen pro Seite. Ist der Wert gesetzt, arbeitet der Aufruf im Paging-Modus (`Id > @Id`, sortiert nach `Id`). Bei `NULL` wird ein einzelner Wert per `Id` geliefert. |\n| `LanguageId` | int | Nein | Sprache des Beschreibungstexts (`LanguageID` in `dbo.Translation`). Es werden nur Werte mit einer Übersetzung in dieser Sprache geliefert. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können auch nicht festgeschriebene Daten erscheinen.\n- Werden `Id` und `RowCount` beide weggelassen, wird der Wert mit `Id = 0` gesucht. Das Ergebnis ist in der Regel leer. Zum Lesen aller Werte wird `RowCount` übergeben.\n- Der Code enthält einen dritten Zweig, der eine leere Ergebnismenge liefert. Dieser Zweig wird nie ausgeführt, da `Id` bei `NULL` immer auf `0` gesetzt wird.\n- Ein negativer `RowCount` führt zu einem SQL-Fehler bei `TOP`.\n- `LanguageId` ist standardmäßig `1`. Für welche Sprache diese ID steht, hängt vom Inhalt von `dbo.Translation` ab.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadCodeTableValues"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Codetabellenwerte aus pixi.CodeTableValue mit übersetzter Beschreibung, entweder einen einzelnen Wert per Id oder eine Seite von Werten nach einer Id.\n\nLiest Einträge der Codetabelle `pixi.CodeTableValue` zusammen mit ihrem Beschreibungstext aus `dbo.Translation`.\n\n1. Wird `Id` nicht übergeben, wird der Wert auf `0` gesetzt.\n2. Es werden die Übersetzungen mit `DBObjectName = 'CodeTableValue'` und `LanguageID = @LanguageId` geladen. Die Zuordnung erfolgt über die `Id` des Werts.\n3. Danach arbeitet der Aufruf in einem von zwei Modi:\n - **Paging-Modus** (`RowCount` gesetzt): liefert höchstens `RowCount` Werte mit `Id > @Id`, sortiert nach `Id` aufsteigend. Für die nächste Seite wird die letzte `Id` der vorherigen Seite als `Id` übergeben. Für den Start wird `Id` = `0` übergeben oder weggelassen.\n - **Einzelmodus** (`RowCount` nicht gesetzt): liefert den Wert mit `Id = @Id`.\n\nDie Verknüpfung mit den Übersetzungen ist ein Inner Join. Werte ohne Übersetzung in der angeforderten Sprache werden nicht geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Id` | int | Nein | Ohne `RowCount`: die `Id` des zu liefernden Codetabellenwerts. Mit `RowCount`: es werden Werte mit einer größeren `Id` geliefert (Paging). `NULL` wird als `0` behandelt. |\n| `RowCount` | int | Nein | Maximale Anzahl Zeilen pro Seite. Ist der Wert gesetzt, arbeitet der Aufruf im Paging-Modus (`Id > @Id`, sortiert nach `Id`). Bei `NULL` wird ein einzelner Wert per `Id` geliefert. |\n| `LanguageId` | int | Nein | Sprache des Beschreibungstexts (`LanguageID` in `dbo.Translation`). Es werden nur Werte mit einer Übersetzung in dieser Sprache geliefert. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können auch nicht festgeschriebene Daten erscheinen.\n- Werden `Id` und `RowCount` beide weggelassen, wird der Wert mit `Id = 0` gesucht. Das Ergebnis ist in der Regel leer. Zum Lesen aller Werte wird `RowCount` übergeben.\n- Der Code enthält einen dritten Zweig, der eine leere Ergebnismenge liefert. Dieser Zweig wird nie ausgeführt, da `Id` bei `NULL` immer auf `0` gesetzt wird.\n- Ein negativer `RowCount` führt zu einem SQL-Fehler bei `TOP`.\n- `LanguageId` ist standardmäßig `1`. Für welche Sprache diese ID steht, hängt vom Inhalt von `dbo.Translation` ab.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadCodeTableValues"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 1\n STD\n Standard\n true\n true\n 1\n true\n \n \n 2\n 1\n EXP\n Express\n true\n false\n 2\n false\n \n"
}
]
},
{
"name": "pixiReadTranslations",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Einträge der Pixi-Übersetzungstabelle seitenweise, sortiert nach `TranslationKey`, beginnend nach einem angegebenen Schlüssel.\n\nLiest Übersetzungseinträge (sprachabhängige Texte) aus der Tabelle `Translation` per Keyset-Paging.\n\n- Wird `TranslationKey` weggelassen oder als `NULL` übergeben, wird der Wert auf `0` gesetzt. Das Lesen beginnt dann am Anfang der Tabelle.\n- Wird `RowCount` weggelassen oder als `NULL` übergeben, wird der Wert auf `1000` gesetzt.\n- Geliefert werden höchstens `RowCount` Zeilen, deren `TranslationKey` **größer** als der übergebene `TranslationKey` ist, aufsteigend sortiert nach `TranslationKey`.\n\nUm alle Übersetzungen zu lesen, wird mit `TranslationKey = 0` begonnen (oder der Parameter weggelassen). Danach wird die Abfrage jeweils mit dem höchsten `TranslationKey` der vorherigen Seite wiederholt, bis weniger als `RowCount` Zeilen zurückkommen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TranslationKey` | int | Nein | Paging-Cursor. Es werden nur Einträge mit einem `TranslationKey` größer als dieser Wert geliefert. `NULL` wird als `0` behandelt. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. `NULL` wird als `1000` behandelt. |\n\n- Da beide Parameter bei `NULL` durch Standardwerte ersetzt werden, wird immer nur der Paging-Zweig ausgeführt. Der Code enthält zusätzlich Zweige für eine exakte Suche nach `TranslationKey` und für ein leeres Ergebnis. Diese Zweige sind jedoch nicht erreichbar.\n- Die Übergabe eines bestimmten `TranslationKey` liefert **nicht** diesen Eintrag, sondern die Einträge danach.\n- Die Tabelle wird `WITH (NOLOCK)` gelesen. Nicht festgeschriebene Änderungen können daher sichtbar sein.\n- `RowCount = 0` liefert keine Zeilen. Ein negativer `RowCount` führt zu einem SQL-Server-Fehler aus der `TOP`-Klausel.\n- Die Spaltentypen sind im Code nicht erkennbar, da die Definition der Tabelle `Translation` nicht vorliegt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadTranslations"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Einträge der Pixi-Übersetzungstabelle seitenweise, sortiert nach `TranslationKey`, beginnend nach einem angegebenen Schlüssel.\n\nLiest Übersetzungseinträge (sprachabhängige Texte) aus der Tabelle `Translation` per Keyset-Paging.\n\n- Wird `TranslationKey` weggelassen oder als `NULL` übergeben, wird der Wert auf `0` gesetzt. Das Lesen beginnt dann am Anfang der Tabelle.\n- Wird `RowCount` weggelassen oder als `NULL` übergeben, wird der Wert auf `1000` gesetzt.\n- Geliefert werden höchstens `RowCount` Zeilen, deren `TranslationKey` **größer** als der übergebene `TranslationKey` ist, aufsteigend sortiert nach `TranslationKey`.\n\nUm alle Übersetzungen zu lesen, wird mit `TranslationKey = 0` begonnen (oder der Parameter weggelassen). Danach wird die Abfrage jeweils mit dem höchsten `TranslationKey` der vorherigen Seite wiederholt, bis weniger als `RowCount` Zeilen zurückkommen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TranslationKey` | int | Nein | Paging-Cursor. Es werden nur Einträge mit einem `TranslationKey` größer als dieser Wert geliefert. `NULL` wird als `0` behandelt. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. `NULL` wird als `1000` behandelt. |\n\n- Da beide Parameter bei `NULL` durch Standardwerte ersetzt werden, wird immer nur der Paging-Zweig ausgeführt. Der Code enthält zusätzlich Zweige für eine exakte Suche nach `TranslationKey` und für ein leeres Ergebnis. Diese Zweige sind jedoch nicht erreichbar.\n- Die Übergabe eines bestimmten `TranslationKey` liefert **nicht** diesen Eintrag, sondern die Einträge danach.\n- Die Tabelle wird `WITH (NOLOCK)` gelesen. Nicht festgeschriebene Änderungen können daher sichtbar sein.\n- `RowCount = 0` liefert keine Zeilen. Ein negativer `RowCount` führt zu einem SQL-Server-Fehler aus der `TOP`-Klausel.\n- Die Spaltentypen sind im Code nicht erkennbar, da die Definition der Tabelle `Translation` nicht vorliegt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadTranslations"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n EN\n ORDER_STATUS_OPEN\n Open\n pixi\n OrderStatus\n \n \n 2\n DE\n ORDER_STATUS_OPEN\n Offen\n pixi\n OrderStatus\n \n"
}
]
},
{
"name": "pixiSysUTRefreshViewsAndProcedures",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert die Metadaten aller nicht schemagebundenen Views und markiert alle Stored Procedures der Pixi-Datenbank zur Neukompilierung.\n\nWartungsaufruf ohne Parameter. Die Datenbankobjekte werden in zwei Durchläufen bearbeitet:\n\n1. **Views:** Alle Views (`type = 'V'`) in allen Schemas, die **nicht** schemagebunden sind (`IsSchemaBound = 0`), werden einzeln an `sp_refreshview` übergeben. Dadurch werden ihre gespeicherten Metadaten aktualisiert, z. B. nach Änderungen an Spalten der zugrunde liegenden Tabellen.\n2. **Stored Procedures:** Alle Stored Procedures (`type = 'P'`) in allen Schemas werden einzeln an `sp_recompile` übergeben. Ihre zwischengespeicherten Ausführungspläne werden bei der nächsten Ausführung neu kompiliert.\n\nDie Objekte werden als `schema.name` angesprochen.\n\nWerden beide Durchläufe abgeschlossen, wird eine Zeile mit `Code = '200'` und `Text = 'OK'` geliefert. Schlägt ein Schritt fehl, bricht die Verarbeitung an dieser Stelle ab und es wird eine Zeile mit `Code = '500'` und der SQL-Fehlermeldung in `Text` geliefert.\n\n- Es gibt keine Transaktion. Bereits aktualisierte Views bleiben bei einem Fehler aktualisiert. Tritt ein Fehler im View-Durchlauf auf, wird keine Procedure neu kompiliert.\n- Eine einzelne fehlerhafte View bricht den gesamten Lauf ab. Das kann eine View sein, die auf eine gelöschte Tabelle oder Spalte verweist. Der Fehler wird als Zeile mit `500` geliefert.\n- Die Cursor werden im Fehlerfall weder geschlossen noch freigegeben. Handelt es sich um globale Cursor (Datenbank-Standard), bleiben sie für die Verbindung offen. Ein späterer Aufruf über dieselbe Verbindung kann dann fehlschlagen, weil bereits ein Cursor `cursor_views` oder `cursor_procs` existiert.\n- `sp_refreshview` und `sp_recompile` benötigen `ALTER`-Berechtigung auf jedes Objekt. Sie setzen außerdem Schemasperren. Bei großen Datenbanken kann der Aufruf lange dauern und andere Sitzungen kurzzeitig blockieren.\n- Schemagebundene Views werden übersprungen. Funktionen und Trigger werden nicht bearbeitet.\n- Die Neukompilierung aller Procedures erzeugt bei deren nächster Ausführung zusätzliche Kompilierlast.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSysUTRefreshViewsAndProcedures"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert die Metadaten aller nicht schemagebundenen Views und markiert alle Stored Procedures der Pixi-Datenbank zur Neukompilierung.\n\nWartungsaufruf ohne Parameter. Die Datenbankobjekte werden in zwei Durchläufen bearbeitet:\n\n1. **Views:** Alle Views (`type = 'V'`) in allen Schemas, die **nicht** schemagebunden sind (`IsSchemaBound = 0`), werden einzeln an `sp_refreshview` übergeben. Dadurch werden ihre gespeicherten Metadaten aktualisiert, z. B. nach Änderungen an Spalten der zugrunde liegenden Tabellen.\n2. **Stored Procedures:** Alle Stored Procedures (`type = 'P'`) in allen Schemas werden einzeln an `sp_recompile` übergeben. Ihre zwischengespeicherten Ausführungspläne werden bei der nächsten Ausführung neu kompiliert.\n\nDie Objekte werden als `schema.name` angesprochen.\n\nWerden beide Durchläufe abgeschlossen, wird eine Zeile mit `Code = '200'` und `Text = 'OK'` geliefert. Schlägt ein Schritt fehl, bricht die Verarbeitung an dieser Stelle ab und es wird eine Zeile mit `Code = '500'` und der SQL-Fehlermeldung in `Text` geliefert.\n\n- Es gibt keine Transaktion. Bereits aktualisierte Views bleiben bei einem Fehler aktualisiert. Tritt ein Fehler im View-Durchlauf auf, wird keine Procedure neu kompiliert.\n- Eine einzelne fehlerhafte View bricht den gesamten Lauf ab. Das kann eine View sein, die auf eine gelöschte Tabelle oder Spalte verweist. Der Fehler wird als Zeile mit `500` geliefert.\n- Die Cursor werden im Fehlerfall weder geschlossen noch freigegeben. Handelt es sich um globale Cursor (Datenbank-Standard), bleiben sie für die Verbindung offen. Ein späterer Aufruf über dieselbe Verbindung kann dann fehlschlagen, weil bereits ein Cursor `cursor_views` oder `cursor_procs` existiert.\n- `sp_refreshview` und `sp_recompile` benötigen `ALTER`-Berechtigung auf jedes Objekt. Sie setzen außerdem Schemasperren. Bei großen Datenbanken kann der Aufruf lange dauern und andere Sitzungen kurzzeitig blockieren.\n- Schemagebundene Views werden übersprungen. Funktionen und Trigger werden nicht bearbeitet.\n- Die Neukompilierung aller Procedures erzeugt bei deren nächster Ausführung zusätzliche Kompilierlast.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSysUTRefreshViewsAndProcedures"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 200\n OK\n \n"
}
]
},
{
"name": "pixiTagCreate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen neuen Tag eines angegebenen Tag-Typs (für Artikel oder Aufträge) an, sofern noch kein Tag mit gleichem Typ und Namen existiert.\n\nLegt einen Tag-Datensatz in Pixi an. Tags dienen zur Kennzeichnung von Artikeln oder Aufträgen. Der Aufruf liefert eine Statuszeile mit `Status` und `Message`.\n\nAblauf:\n\n1. **Prüfung.** `TypeID` muss auf einen vorhandenen Tag-Typ verweisen, und `Name` darf nicht leer sein. Schlägt die Prüfung fehl, wird kein Tag angelegt und `Status` ist `Error`. Die Prüfungen erfolgen in dieser Reihenfolge:\n - `TypeID` und `Name` fehlen beide\n - `TypeID` fehlt\n - kein Tag-Typ mit dieser `TypeID` vorhanden\n - `Name` leer\n2. **Dublettenprüfung.** Es wird gezählt, wie viele Tags mit gleicher `TypeID` und gleichem `Name` bereits existieren. Ist mindestens einer vorhanden, wird nichts eingefügt und `Status` ist `Information`.\n3. **Anlage.** Andernfalls wird ein neuer Tag angelegt mit:\n - dem angegebenen Typ und Namen\n - `Description`; `NULL` wird als Leerstring gespeichert\n - `IsSystemTag` = 0\n\n `Status` ist dann `Success`.\n\nDie ID des neuen Tags wird **nicht** zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TypeID` | int | Nein | ID des Tag-Typs (`TagType.Id`). Faktisch Pflicht; muss auf einen vorhandenen Tag-Typ verweisen. |\n| `Name` | varchar(50) | Nein | Name des neuen Tags. Faktisch Pflicht; darf nicht leer sein. Zusammen mit `TypeID` muss er eindeutig sein, sonst wird kein Tag angelegt. |\n| `Description` | varchar(4000) | Nein | Optionale Beschreibung des Tags. `NULL` wird als Leerstring gespeichert. |\n\n- **Transaktionen:** Der Aufruf läuft in einer eigenen Transaktion. Wird er innerhalb einer bestehenden Transaktion aufgerufen, wird stattdessen ein Savepoint verwendet. `XACT_ABORT` ist aktiv.\n- **Fehlerbehandlung:** Bei einem unerwarteten Fehler wird die Transaktion zurückgerollt und der Fehler über `log.InsertError` protokolliert (Definition nicht beigefügt). Es wird trotzdem eine Statuszeile mit `Status` = `Error` geliefert; ein SQL-Fehler wird nicht ausgelöst.\n- **Dubletten:** Die Prüfungen auf Tag-Typ und Dubletten lesen mit `NOLOCK`. Gleichzeitige Aufrufe mit gleichem Typ und Namen können daher beide einen Tag anlegen, sofern kein Unique-Constraint auf `Tag` dies verhindert; ein solcher Constraint ist im Code nicht ersichtlich.\n- **Namensvergleich:** Ob Namen unter Beachtung der Groß-/Kleinschreibung verglichen werden, hängt von der Datenbank-Collation ab.\n- **Meldungstext:** In der Meldung 'already exists' wird der Name auf 20 Zeichen gekürzt.\n- **Tag-ID:** Die ID des neuen Tags wird nicht zurückgegeben und muss separat ermittelt werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagCreate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen neuen Tag eines angegebenen Tag-Typs (für Artikel oder Aufträge) an, sofern noch kein Tag mit gleichem Typ und Namen existiert.\n\nLegt einen Tag-Datensatz in Pixi an. Tags dienen zur Kennzeichnung von Artikeln oder Aufträgen. Der Aufruf liefert eine Statuszeile mit `Status` und `Message`.\n\nAblauf:\n\n1. **Prüfung.** `TypeID` muss auf einen vorhandenen Tag-Typ verweisen, und `Name` darf nicht leer sein. Schlägt die Prüfung fehl, wird kein Tag angelegt und `Status` ist `Error`. Die Prüfungen erfolgen in dieser Reihenfolge:\n - `TypeID` und `Name` fehlen beide\n - `TypeID` fehlt\n - kein Tag-Typ mit dieser `TypeID` vorhanden\n - `Name` leer\n2. **Dublettenprüfung.** Es wird gezählt, wie viele Tags mit gleicher `TypeID` und gleichem `Name` bereits existieren. Ist mindestens einer vorhanden, wird nichts eingefügt und `Status` ist `Information`.\n3. **Anlage.** Andernfalls wird ein neuer Tag angelegt mit:\n - dem angegebenen Typ und Namen\n - `Description`; `NULL` wird als Leerstring gespeichert\n - `IsSystemTag` = 0\n\n `Status` ist dann `Success`.\n\nDie ID des neuen Tags wird **nicht** zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TypeID` | int | Nein | ID des Tag-Typs (`TagType.Id`). Faktisch Pflicht; muss auf einen vorhandenen Tag-Typ verweisen. |\n| `Name` | varchar(50) | Nein | Name des neuen Tags. Faktisch Pflicht; darf nicht leer sein. Zusammen mit `TypeID` muss er eindeutig sein, sonst wird kein Tag angelegt. |\n| `Description` | varchar(4000) | Nein | Optionale Beschreibung des Tags. `NULL` wird als Leerstring gespeichert. |\n\n- **Transaktionen:** Der Aufruf läuft in einer eigenen Transaktion. Wird er innerhalb einer bestehenden Transaktion aufgerufen, wird stattdessen ein Savepoint verwendet. `XACT_ABORT` ist aktiv.\n- **Fehlerbehandlung:** Bei einem unerwarteten Fehler wird die Transaktion zurückgerollt und der Fehler über `log.InsertError` protokolliert (Definition nicht beigefügt). Es wird trotzdem eine Statuszeile mit `Status` = `Error` geliefert; ein SQL-Fehler wird nicht ausgelöst.\n- **Dubletten:** Die Prüfungen auf Tag-Typ und Dubletten lesen mit `NOLOCK`. Gleichzeitige Aufrufe mit gleichem Typ und Namen können daher beide einen Tag anlegen, sofern kein Unique-Constraint auf `Tag` dies verhindert; ein solcher Constraint ist im Code nicht ersichtlich.\n- **Namensvergleich:** Ob Namen unter Beachtung der Groß-/Kleinschreibung verglichen werden, hängt von der Datenbank-Collation ab.\n- **Meldungstext:** In der Meldung 'already exists' wird der Name auf 20 Zeichen gekürzt.\n- **Tag-ID:** Die ID des neuen Tags wird nicht zurückgegeben und muss separat ermittelt werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagCreate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n New tag was successfully created\n \n"
}
]
},
{
"name": "pixiTagDelete",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht einen Tag, der über seine ID oder über Typ und Name bestimmt wird, und entfernt alle Zuordnungen zu Artikeln oder Aufträgen.\n\nLöscht einen Tag aus `Tag` zusammen mit allen Zuordnungen in `TagMatch`. Tags dienen zur Kennzeichnung von Objekten wie Artikeln oder Aufträgen.\n\nDer Tag kann auf zwei Arten bestimmt werden:\n\n- über `TagId` oder\n- über die Kombination aus `TypeId` und `Name`. Beide Werte sind gemeinsam erforderlich.\n\nDie Parameter werden in dieser Reihenfolge geprüft:\n\n1. Fehlen alle drei Parameter oder wird nur einer von `TypeId` und `Name` übergeben, liefert der Aufruf einen Fehler wegen fehlender Pflichtparameter.\n2. Wird `TagId` übergeben, existiert aber kein Tag mit dieser ID, lautet die Meldung *Tag does not exist*.\n3. Wird `TagId` nicht übergeben und passt kein Tag zu `TypeId` und `Name`, lautet die Meldung ebenfalls *Tag does not exist*.\n4. Ist der gefundene Tag ein System-Tag (`IsSystemTag` = 1), kann er nicht gelöscht werden.\n5. Werden `TagId` sowie `TypeId`/`Name` übergeben und verweisen sie auf zwei verschiedene Tags, liefert der Aufruf einen Fehler.\n\nSind alle Prüfungen bestanden, werden zuerst alle `TagMatch`-Zeilen des Tags gelöscht. Dadurch wird der Tag von allen zugeordneten Objekten entfernt. Danach wird der Tag selbst gelöscht. Der Aufruf liefert immer genau eine Zeile mit `Status` und `Message`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagId` | int | Nein | ID des zu löschenden Tags. Alternative zur Kombination aus `TypeId` und `Name`. |\n| `TypeId` | int | Nein | Typ des Tags (`Tag.TypeId`). Muss zusammen mit `Name` übergeben werden, wenn der Tag über den Namen bestimmt wird. |\n| `Name` | varchar(50) | Nein | Name des Tags (`Tag.Name`). Muss zusammen mit `TypeId` übergeben werden. |\n\n- Der Aufruf läuft in einer eigenen Transaktion. Ist bereits eine Transaktion offen, wird stattdessen ein Savepoint verwendet. Bei einem unerwarteten Fehler werden die Änderungen zurückgerollt und der Fehler über `log.InsertError` protokolliert. Zurückgegeben wird dann `Status` = `Error` mit den ersten 80 Zeichen der SQL-Fehlermeldung.\n- Fehler werden nie als `SqlMessage` ausgelöst. Die Spalte `Status` ist daher immer auszuwerten.\n- Stolperfalle: Wird `TagId` zusammen mit einem Paar aus `TypeId`/`Name` übergeben, zu dem kein Tag existiert, greift die Konfliktprüfung nicht. In diesem Fall wird der Tag mit `TagId` gelöscht.\n- Wird `TagId` zusammen mit nur `TypeId` oder nur `Name` übergeben, erscheint der Fehler wegen fehlender Pflichtparameter, obwohl `TagId` allein genügen würde.\n- Die Prüfungen lesen `Tag` mit `NOLOCK`. Die Löschvorgänge verwenden `ROWLOCK`.\n- Die Bedeutung der `TypeId`-Werte (z. B. Artikel- oder Auftrags-Tags) ist in diesem Code nicht festgelegt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagDelete"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht einen Tag, der über seine ID oder über Typ und Name bestimmt wird, und entfernt alle Zuordnungen zu Artikeln oder Aufträgen.\n\nLöscht einen Tag aus `Tag` zusammen mit allen Zuordnungen in `TagMatch`. Tags dienen zur Kennzeichnung von Objekten wie Artikeln oder Aufträgen.\n\nDer Tag kann auf zwei Arten bestimmt werden:\n\n- über `TagId` oder\n- über die Kombination aus `TypeId` und `Name`. Beide Werte sind gemeinsam erforderlich.\n\nDie Parameter werden in dieser Reihenfolge geprüft:\n\n1. Fehlen alle drei Parameter oder wird nur einer von `TypeId` und `Name` übergeben, liefert der Aufruf einen Fehler wegen fehlender Pflichtparameter.\n2. Wird `TagId` übergeben, existiert aber kein Tag mit dieser ID, lautet die Meldung *Tag does not exist*.\n3. Wird `TagId` nicht übergeben und passt kein Tag zu `TypeId` und `Name`, lautet die Meldung ebenfalls *Tag does not exist*.\n4. Ist der gefundene Tag ein System-Tag (`IsSystemTag` = 1), kann er nicht gelöscht werden.\n5. Werden `TagId` sowie `TypeId`/`Name` übergeben und verweisen sie auf zwei verschiedene Tags, liefert der Aufruf einen Fehler.\n\nSind alle Prüfungen bestanden, werden zuerst alle `TagMatch`-Zeilen des Tags gelöscht. Dadurch wird der Tag von allen zugeordneten Objekten entfernt. Danach wird der Tag selbst gelöscht. Der Aufruf liefert immer genau eine Zeile mit `Status` und `Message`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagId` | int | Nein | ID des zu löschenden Tags. Alternative zur Kombination aus `TypeId` und `Name`. |\n| `TypeId` | int | Nein | Typ des Tags (`Tag.TypeId`). Muss zusammen mit `Name` übergeben werden, wenn der Tag über den Namen bestimmt wird. |\n| `Name` | varchar(50) | Nein | Name des Tags (`Tag.Name`). Muss zusammen mit `TypeId` übergeben werden. |\n\n- Der Aufruf läuft in einer eigenen Transaktion. Ist bereits eine Transaktion offen, wird stattdessen ein Savepoint verwendet. Bei einem unerwarteten Fehler werden die Änderungen zurückgerollt und der Fehler über `log.InsertError` protokolliert. Zurückgegeben wird dann `Status` = `Error` mit den ersten 80 Zeichen der SQL-Fehlermeldung.\n- Fehler werden nie als `SqlMessage` ausgelöst. Die Spalte `Status` ist daher immer auszuwerten.\n- Stolperfalle: Wird `TagId` zusammen mit einem Paar aus `TypeId`/`Name` übergeben, zu dem kein Tag existiert, greift die Konfliktprüfung nicht. In diesem Fall wird der Tag mit `TagId` gelöscht.\n- Wird `TagId` zusammen mit nur `TypeId` oder nur `Name` übergeben, erscheint der Fehler wegen fehlender Pflichtparameter, obwohl `TagId` allein genügen würde.\n- Die Prüfungen lesen `Tag` mit `NOLOCK`. Die Löschvorgänge verwenden `ROWLOCK`.\n- Die Bedeutung der `TypeId`-Werte (z. B. Artikel- oder Auftrags-Tags) ist in diesem Code nicht festgelegt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagDelete"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n Tag was successfully deleted. Tag was also removed from assigned objects\n \n"
}
]
},
{
"name": "pixiTagGet",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Tag-Definitionen, die in einem Zeitraum angelegt wurden, optional gefiltert nach Tag-Typ, inklusive Name des Tag-Typs.\n\nLiefert die in Pixi definierten Tags (Tabelle `Tag`) zusammen mit ihrem Tag-Typ (`TagType`).\n\n- `DateFrom` / `DateTo` filtern auf das Anlagedatum des Tags (`RecordCreatedOn`, an beiden Grenzen inklusive). Ohne `DateFrom` wird das Anlagedatum des ältesten Tags verwendet, ohne `DateTo` das aktuelle Datum mit Uhrzeit.\n- `TypeId` schränkt das Ergebnis auf einen Tag-Typ ein. Ohne Angabe werden Tags aller Typen geliefert.\n- `RowCount` begrenzt die Anzahl der Zeilen (Standard 1000, auch bei Übergabe von `NULL`).\n\nEs werden nur Tags geliefert, deren `TypeId` in `TagType` vorhanden ist (Inner Join). Sortiert wird aufsteigend nach `TagId`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. `NULL` wird als 1000 behandelt. |\n| `DateFrom` | smalldatetime | Nein | Beginn des Zeitraums für das Anlagedatum (inklusive). Bei `NULL` wird das Anlagedatum des ältesten Tags verwendet. |\n| `DateTo` | smalldatetime | Nein | Ende des Zeitraums für das Anlagedatum (inklusive). Bei `NULL` wird das aktuelle Datum mit Uhrzeit verwendet. |\n| `TypeId` | int | Nein | ID des Tag-Typs (`TagType.Id`), nach dem gefiltert wird. `NULL` liefert Tags aller Typen. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Die Datumsparameter sind `smalldatetime` (Minutengenauigkeit); Sekunden werden gerundet.\n- Es gibt keinen Offset-Parameter. Für große Datenmengen den Zeitraum eingrenzen oder `RowCount` erhöhen.\n- Geliefert werden nur die Tag-Definitionen, nicht die Zuordnungen von Tags zu Objekten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagGet"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Tag-Definitionen, die in einem Zeitraum angelegt wurden, optional gefiltert nach Tag-Typ, inklusive Name des Tag-Typs.\n\nLiefert die in Pixi definierten Tags (Tabelle `Tag`) zusammen mit ihrem Tag-Typ (`TagType`).\n\n- `DateFrom` / `DateTo` filtern auf das Anlagedatum des Tags (`RecordCreatedOn`, an beiden Grenzen inklusive). Ohne `DateFrom` wird das Anlagedatum des ältesten Tags verwendet, ohne `DateTo` das aktuelle Datum mit Uhrzeit.\n- `TypeId` schränkt das Ergebnis auf einen Tag-Typ ein. Ohne Angabe werden Tags aller Typen geliefert.\n- `RowCount` begrenzt die Anzahl der Zeilen (Standard 1000, auch bei Übergabe von `NULL`).\n\nEs werden nur Tags geliefert, deren `TypeId` in `TagType` vorhanden ist (Inner Join). Sortiert wird aufsteigend nach `TagId`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. `NULL` wird als 1000 behandelt. |\n| `DateFrom` | smalldatetime | Nein | Beginn des Zeitraums für das Anlagedatum (inklusive). Bei `NULL` wird das Anlagedatum des ältesten Tags verwendet. |\n| `DateTo` | smalldatetime | Nein | Ende des Zeitraums für das Anlagedatum (inklusive). Bei `NULL` wird das aktuelle Datum mit Uhrzeit verwendet. |\n| `TypeId` | int | Nein | ID des Tag-Typs (`TagType.Id`), nach dem gefiltert wird. `NULL` liefert Tags aller Typen. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Die Datumsparameter sind `smalldatetime` (Minutengenauigkeit); Sekunden werden gerundet.\n- Es gibt keinen Offset-Parameter. Für große Datenmengen den Zeitraum eingrenzen oder `RowCount` erhöhen.\n- Geliefert werden nur die Tag-Definitionen, nicht die Zuordnungen von Tags zu Objekten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagGet"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n Express\n Express shipping requested\n false\n 2024-03-12T09:15:00\n 1\n Order\n \n \n 2\n Fragile\n Handle with care\n true\n 2024-03-14T11:40:00\n 2\n Item\n \n"
}
]
},
{
"name": "pixiTagMatchAdd",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 12\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Weist ein vorhandenes Tag je nach Tag-Typ einem Artikel oder einem Auftrag zu und liefert eine Statuszeile.\n\nLegt eine Tag-Zuordnung (eine Zeile in `TagMatch`) für das in `TagId` angegebene Tag an.\n\nAblauf:\n\n1. Der Typ des Tags wird aus `Tag` gelesen. Der Typ bestimmt, welchem Objekt das Tag zugeordnet werden kann:\n - `TypeId` = 1: Artikel-Tag, `ItemId` ist Pflicht und muss als `ItemKey` in `items` existieren.\n - `TypeId` = 2: Auftrags-Tag, `OrderNr` ist Pflicht und muss als `OrderNr` in `OrderHeader` existieren. Die Auftragsnummer wird in den internen `OrderHeaderKey` übersetzt.\n2. Es wird geprüft, ob das Tag dem angegebenen Artikel bzw. Auftrag bereits zugeordnet ist.\n3. Die Prüfungen erfolgen in dieser Reihenfolge, die erste fehlgeschlagene bestimmt das Ergebnis: fehlende `TagId`, unbekanntes Tag, fehlende `ItemId`/`OrderNr` für den Tag-Typ, unbekannter Artikel/Auftrag, bereits vorhandene Zuordnung.\n4. Sind alle Prüfungen erfolgreich, wird die Zuordnung angelegt. Bei einem Artikel-Tag wird nur der Artikel gespeichert, bei einem Auftrags-Tag nur der Auftragskopf-Schlüssel; der jeweils andere Parameter wird ignoriert.\n\nDer Aufruf liefert immer genau eine Zeile mit `Status` (`Success`, `Warning` oder `Error`) und `Message`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagId` | int | Ja | ID des zuzuordnenden Tags (`Tag.Id`). Sein Typ bestimmt, ob `ItemId` oder `OrderNr` verwendet wird. |\n| `OrderNr` | int | Nein | Auftragsnummer (`OrderHeader.OrderNr`), der das Tag zugeordnet wird. Pflicht für Auftrags-Tags (`TypeId` = 2), bei Artikel-Tags ignoriert. |\n| `ItemId` | int | Nein | Interner Artikelschlüssel (`items.ItemKey`), dem das Tag zugeordnet wird. Pflicht für Artikel-Tags (`TypeId` = 1), bei Auftrags-Tags ignoriert. |\n\n- Die Verarbeitung läuft in einer eigenen Transaktion bzw. in einem Savepoint, wenn der Aufrufer bereits eine Transaktion geöffnet hat. Bei einem unerwarteten Fehler werden die Änderungen zurückgerollt, der Fehler über `log.InsertError` protokolliert und statt einer `SqlMessage` eine Statuszeile mit `Unexpected error: \"…\"` (erste 80 Zeichen der SQL-Fehlermeldung) geliefert.\n- Die Abfragen verwenden `NOLOCK`; die Dublettenprüfung kann daher nicht festgeschriebene Daten lesen, und zwei parallele Aufrufe könnten beide die Prüfung bestehen.\n- Die Dublettenprüfung vergleicht das Tag mit dem Auftrag **oder** dem Artikel. Werden `OrderNr` und `ItemId` gemeinsam übergeben, führt eine vorhandene Zuordnung zu einem der beiden zur `Warning`, auch wenn sie nicht zum Tag-Typ passt.\n- Bei Tags, deren `TypeId` weder 1 noch 2 ist, findet keine Artikel-/Auftragsprüfung statt, und es wird eine `TagMatch`-Zeile mit leerem `ItemId` und `OrderHeaderId` angelegt.\n- `OrderNr` ist die sichtbare Auftragsnummer, nicht der interne `OrderHeaderKey`; `ItemId` ist der interne `ItemKey`.\n- Der Kopfkommentar der Prozedur („Get tags for objects“) passt nicht zum Verhalten; die Prozedur schreibt Daten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagMatchAdd"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 12\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Weist ein vorhandenes Tag je nach Tag-Typ einem Artikel oder einem Auftrag zu und liefert eine Statuszeile.\n\nLegt eine Tag-Zuordnung (eine Zeile in `TagMatch`) für das in `TagId` angegebene Tag an.\n\nAblauf:\n\n1. Der Typ des Tags wird aus `Tag` gelesen. Der Typ bestimmt, welchem Objekt das Tag zugeordnet werden kann:\n - `TypeId` = 1: Artikel-Tag, `ItemId` ist Pflicht und muss als `ItemKey` in `items` existieren.\n - `TypeId` = 2: Auftrags-Tag, `OrderNr` ist Pflicht und muss als `OrderNr` in `OrderHeader` existieren. Die Auftragsnummer wird in den internen `OrderHeaderKey` übersetzt.\n2. Es wird geprüft, ob das Tag dem angegebenen Artikel bzw. Auftrag bereits zugeordnet ist.\n3. Die Prüfungen erfolgen in dieser Reihenfolge, die erste fehlgeschlagene bestimmt das Ergebnis: fehlende `TagId`, unbekanntes Tag, fehlende `ItemId`/`OrderNr` für den Tag-Typ, unbekannter Artikel/Auftrag, bereits vorhandene Zuordnung.\n4. Sind alle Prüfungen erfolgreich, wird die Zuordnung angelegt. Bei einem Artikel-Tag wird nur der Artikel gespeichert, bei einem Auftrags-Tag nur der Auftragskopf-Schlüssel; der jeweils andere Parameter wird ignoriert.\n\nDer Aufruf liefert immer genau eine Zeile mit `Status` (`Success`, `Warning` oder `Error`) und `Message`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagId` | int | Ja | ID des zuzuordnenden Tags (`Tag.Id`). Sein Typ bestimmt, ob `ItemId` oder `OrderNr` verwendet wird. |\n| `OrderNr` | int | Nein | Auftragsnummer (`OrderHeader.OrderNr`), der das Tag zugeordnet wird. Pflicht für Auftrags-Tags (`TypeId` = 2), bei Artikel-Tags ignoriert. |\n| `ItemId` | int | Nein | Interner Artikelschlüssel (`items.ItemKey`), dem das Tag zugeordnet wird. Pflicht für Artikel-Tags (`TypeId` = 1), bei Auftrags-Tags ignoriert. |\n\n- Die Verarbeitung läuft in einer eigenen Transaktion bzw. in einem Savepoint, wenn der Aufrufer bereits eine Transaktion geöffnet hat. Bei einem unerwarteten Fehler werden die Änderungen zurückgerollt, der Fehler über `log.InsertError` protokolliert und statt einer `SqlMessage` eine Statuszeile mit `Unexpected error: \"…\"` (erste 80 Zeichen der SQL-Fehlermeldung) geliefert.\n- Die Abfragen verwenden `NOLOCK`; die Dublettenprüfung kann daher nicht festgeschriebene Daten lesen, und zwei parallele Aufrufe könnten beide die Prüfung bestehen.\n- Die Dublettenprüfung vergleicht das Tag mit dem Auftrag **oder** dem Artikel. Werden `OrderNr` und `ItemId` gemeinsam übergeben, führt eine vorhandene Zuordnung zu einem der beiden zur `Warning`, auch wenn sie nicht zum Tag-Typ passt.\n- Bei Tags, deren `TypeId` weder 1 noch 2 ist, findet keine Artikel-/Auftragsprüfung statt, und es wird eine `TagMatch`-Zeile mit leerem `ItemId` und `OrderHeaderId` angelegt.\n- `OrderNr` ist die sichtbare Auftragsnummer, nicht der interne `OrderHeaderKey`; `ItemId` ist der interne `ItemKey`.\n- Der Kopfkommentar der Prozedur („Get tags for objects“) passt nicht zum Verhalten; die Prozedur schreibt Daten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagMatchAdd"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n Tag was successfully assigned\n \n"
}
]
},
{
"name": "pixiTagUpdate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Benennt einen benutzerdefinierten Tag um und aktualisiert optional dessen Beschreibung; liefert eine Status/Message-Zeile.\n\nAktualisiert einen vorhandenen Datensatz in der Tabelle `Tag`, also einen Tag, der Artikeln oder Aufträgen zugeordnet werden kann.\n\nAblauf:\n\n1. `IsSystemTag` und `TypeId` des Tags mit der übergebenen `TagId` werden gelesen.\n2. Es wird geprüft, ob bereits ein anderer Tag mit demselben `Name` und derselben `TypeId` existiert. Tags anderer Typen dürfen denselben Namen tragen.\n3. Die Eingaben werden in dieser Reihenfolge geprüft; die Prüfung endet beim ersten Fehler:\n - `TagId` darf nicht leer sein.\n - `Name` darf weder NULL noch eine leere Zeichenkette sein.\n - Der Tag darf kein System-Tag sein (`IsSystemTag = 1`).\n - Der Tag muss existieren.\n - Kein anderer Tag desselben Typs darf den neuen Namen bereits verwenden.\n4. Sind alle Prüfungen erfolgreich, wird der Tag aktualisiert:\n - `Name` wird auf `Name` gesetzt.\n - `Description` wird auf `Description` gesetzt. Ist `Description` NULL oder fehlt der Parameter, bleibt die bisherige Beschreibung erhalten.\n - `RecordModifiedOn` wird auf den aktuellen Zeitpunkt gesetzt.\n - `RecordModifiedByUserId` wird auf den Benutzer `API` gesetzt, ersatzweise auf `pixiAdministration`, falls kein Benutzer `API` existiert.\n - `RowVersion` wird um 1 erhöht.\n\nDer Aufruf liefert immer genau eine Zeile mit `Status` (`Success` oder `Error`) und `Message`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagId` | int | Nein | ID des zu ändernden Tags. Faktisch Pflicht: Ist der Wert leer, wird eine Fehlerzeile zurückgegeben. |\n| `Name` | varchar(50) | Nein | Neuer Name des Tags. Faktisch Pflicht; der Name muss unter den Tags desselben Typs eindeutig sein. |\n| `Description` | varchar(4000) | Nein | Neue Beschreibung des Tags. Bei NULL bleibt die bisherige Beschreibung erhalten. |\n\n- Validierungsfehler werden nicht als SQL-Fehler ausgelöst. Sie werden als Zeile mit `Status = 'Error'` zurückgegeben; daher die Spalte `Status` auswerten.\n- Die Aktualisierung läuft in einer eigenen Transaktion. Ist bereits eine Transaktion offen, wird stattdessen ein Savepoint gesetzt. Bei einem unerwarteten Fehler wird zurückgerollt und der Fehler über `log.InsertError` protokolliert. Dieses Objekt ist nicht beigefügt; was es schreibt, ist hier nicht dokumentiert.\n- Die Abfragen nach dem vorhandenen Tag und nach doppelten Namen verwenden `NOLOCK`. Das Update selbst verwendet `ROWLOCK`.\n- `Name` wird nicht getrimmt. Ein Name, der nur aus Leerzeichen besteht, besteht die Leer-Prüfung, da SQL Server nachfolgende Leerzeichen beim Zeichenkettenvergleich ignoriert.\n- Eine leere Zeichenkette als `Description` leert die Beschreibung. NULL oder ein fehlender Parameter behält die bisherige Beschreibung.\n- Bei unerwarteten Fehlern wird der ursprüngliche SQL-Fehlertext auf 80 Zeichen gekürzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagUpdate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Benennt einen benutzerdefinierten Tag um und aktualisiert optional dessen Beschreibung; liefert eine Status/Message-Zeile.\n\nAktualisiert einen vorhandenen Datensatz in der Tabelle `Tag`, also einen Tag, der Artikeln oder Aufträgen zugeordnet werden kann.\n\nAblauf:\n\n1. `IsSystemTag` und `TypeId` des Tags mit der übergebenen `TagId` werden gelesen.\n2. Es wird geprüft, ob bereits ein anderer Tag mit demselben `Name` und derselben `TypeId` existiert. Tags anderer Typen dürfen denselben Namen tragen.\n3. Die Eingaben werden in dieser Reihenfolge geprüft; die Prüfung endet beim ersten Fehler:\n - `TagId` darf nicht leer sein.\n - `Name` darf weder NULL noch eine leere Zeichenkette sein.\n - Der Tag darf kein System-Tag sein (`IsSystemTag = 1`).\n - Der Tag muss existieren.\n - Kein anderer Tag desselben Typs darf den neuen Namen bereits verwenden.\n4. Sind alle Prüfungen erfolgreich, wird der Tag aktualisiert:\n - `Name` wird auf `Name` gesetzt.\n - `Description` wird auf `Description` gesetzt. Ist `Description` NULL oder fehlt der Parameter, bleibt die bisherige Beschreibung erhalten.\n - `RecordModifiedOn` wird auf den aktuellen Zeitpunkt gesetzt.\n - `RecordModifiedByUserId` wird auf den Benutzer `API` gesetzt, ersatzweise auf `pixiAdministration`, falls kein Benutzer `API` existiert.\n - `RowVersion` wird um 1 erhöht.\n\nDer Aufruf liefert immer genau eine Zeile mit `Status` (`Success` oder `Error`) und `Message`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagId` | int | Nein | ID des zu ändernden Tags. Faktisch Pflicht: Ist der Wert leer, wird eine Fehlerzeile zurückgegeben. |\n| `Name` | varchar(50) | Nein | Neuer Name des Tags. Faktisch Pflicht; der Name muss unter den Tags desselben Typs eindeutig sein. |\n| `Description` | varchar(4000) | Nein | Neue Beschreibung des Tags. Bei NULL bleibt die bisherige Beschreibung erhalten. |\n\n- Validierungsfehler werden nicht als SQL-Fehler ausgelöst. Sie werden als Zeile mit `Status = 'Error'` zurückgegeben; daher die Spalte `Status` auswerten.\n- Die Aktualisierung läuft in einer eigenen Transaktion. Ist bereits eine Transaktion offen, wird stattdessen ein Savepoint gesetzt. Bei einem unerwarteten Fehler wird zurückgerollt und der Fehler über `log.InsertError` protokolliert. Dieses Objekt ist nicht beigefügt; was es schreibt, ist hier nicht dokumentiert.\n- Die Abfragen nach dem vorhandenen Tag und nach doppelten Namen verwenden `NOLOCK`. Das Update selbst verwendet `ROWLOCK`.\n- `Name` wird nicht getrimmt. Ein Name, der nur aus Leerzeichen besteht, besteht die Leer-Prüfung, da SQL Server nachfolgende Leerzeichen beim Zeichenkettenvergleich ignoriert.\n- Eine leere Zeichenkette als `Description` leert die Beschreibung. NULL oder ein fehlender Parameter behält die bisherige Beschreibung.\n- Bei unerwarteten Fehlern wird der ursprüngliche SQL-Fehlertext auf 80 Zeichen gekürzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagUpdate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n Tag was successfully changed\n \n"
}
]
}
]
},
{
"name": "Invoices",
"item": [
{
"name": "pixiCreateDirectInv",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n 100245\n ,1234,1235,\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine Direktrechnung für einen Auftrag an, entweder für alle offenen Auftragspositionen oder für eine kommagetrennte Liste von Positionsschlüsseln.\n\nDer Aufruf ist ein schlanker Wrapper um die interne Prozedur `Pixi_CreateDirectInvInvoices`. Übergeben werden `LocID`, `CreateEmp`, `OrderNr` und `OrderlineRefs`; alle anderen Werte sind fest: keine Prüfung \"alle Artikel auf Lager\", keine Lagerplatz-Einschränkung, kein 1SS-Modus (One-Step-Shipping), Ergebniszeile aktiv, eigene Transaktion, Erstellungsmodus `Manual`, Sprache 1.\n\n**Vorprüfungen (keine Ergebnismenge, keine Rechnung):**\n- Hat der Auftrag keine Position in einem der offenen Status `RAS`, `OPA`, `NAO`, `ANG`, `BES`, `BOR`, `NAS`, `OPH`, `NAD`, endet der Aufruf ohne Meldung.\n- Ist `OrderlineRefs` leer und liegt eine Position des Auftrags auf einer aktiven (nicht abgelaufenen) Pickliste, endet der Aufruf ohne Meldung.\n\n**Auswahl der Positionen:**\n- `OrderlineRefs` wird an Kommas getrennt; nur numerische Schlüssel > 0 werden verwendet. Bei leerem Wert werden alle Positionen des Auftrags verwendet.\n- Berechnet werden nur Positionen von `OrderNr` in den oben genannten offenen Status sowie `MIN`, und nur, wenn sie noch nicht auf einer Rechnungsposition stehen.\n- Der Kunde darf nicht gesperrt sein (`SLocked`) und die Lieferadresse nicht gesperrt (`ASlocked`); sonst wird nichts angelegt.\n\n**Rechnungserstellung:**\n1. Abhängig von der Einstellung `DoNotReleaseStockOnDirectInvoiceScanOut` (Wert `0`) wird intern eine Pickliste für die gewählten Positionen erzeugt (Teillieferung und Teilmengen erlaubt) und mit dem Kommentar `DirectInvStockRelease` markiert.\n2. In einer Transaktion wird der Rechnungskopf angelegt (MwSt-Typ `I`, oder `N`, wenn die Rechnungsadresse eine USt-IdNr. hat oder der Kunde `TaxOnInvoice = 'N'` hat), Wechselkurs und Retouren-Tracking-ID werden ermittelt und SEPA-Daten ergänzt.\n3. Rechnungspositionen werden aus den Auftragspositionen übernommen (Menge, Preis, Rabatt, MwSt, Versandkosten, Währung, Seriennummer).\n4. Die Rechnung erhält die nächste Rechnungsnummer des Shops und ein Paket-Bruttogewicht (Einstellung `DefaultShippingWeight` oder aus Artikelgewichten berechnet, wenn `CalculateWeightFromItems = 1`).\n5. Berechnete offene Positionen erhalten Status `EIN` und die Rechnungsreferenz; `MIN`-Positionen erhalten nur die Rechnungsreferenz.\n6. Bei `Invoice_CancelPartialDelivery = 1` werden verbleibende `ANG`/`HAL`/`BOR`-Positionen von Aufträgen mit erzwungener Teillieferung und Stornierung auf `STO` gesetzt.\n7. Verlangt der Versanddienstleister (`DoScanOutOnInvoiceCreate`) oder die Zahlungsart (`AutoScanOutInvoice`) es, wird eine Kiste angelegt und ausgescannt sowie ein Job zur Bestandsfreigabe eingereiht.\n8. Das Ereignis `InvoiceCreated` wird veröffentlicht.\n\nAm Ende wird eine Statuszeile zurückgegeben (siehe Ergebnismengen).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | Nein | Standort-ID für die interne Pickliste sowie Kisten- und Ausscan-Verarbeitung. |\n| `CreateEmp` | varchar(50) | Nein | Benutzername, der als Ersteller der Rechnung und als Bearbeiter der Auftragspositionen gespeichert wird. |\n| `OrderNr` | int | Ja | Nummer des zu berechnenden Auftrags. |\n| `OrderlineRefs` | varchar(2000) | Ja | Kommagetrennte Positionsschlüssel, die berechnet werden sollen, z. B. `,1234,1235,`. Leerstring bedeutet alle zulässigen Positionen des Auftrags. Schlüssel, die nicht zum Auftrag gehören, werden ignoriert. |\n\n- `OrderlineRefs` hat keinen Standardwert und muss übergeben werden; ein Leerstring (oder NULL) bedeutet \"alle zulässigen Positionen\". Das dokumentierte Format ist `,1234,1235,`.\n- **Stille Abbrüche:** In den beiden Vorprüfungsfällen wird gar keine Zeile zurückgegeben. Ist Kunde oder Lieferadresse gesperrt, meldet die Abschlusszeile `Success = 1`, aber `InvoiceKey = 0` und `CreatedInv = 0`; daher `CreatedInv`/`InvoiceKey` prüfen, nicht nur `Success`.\n- Bei einem Fehler in der Rechnungstransaktion wird alles zurückgerollt, die interne Pickliste gelöscht, der Fehler protokolliert (`LOG.InsertError`), eine Zeile mit vier Spalten geliefert und der Fehler über `sp_Exception_ReRaise` (nicht beigefügt) erneut ausgelöst, sodass der Client zusätzlich eine `SqlMessage` erhält.\n- Ein Fehler beim Erzeugen der internen Pickliste wird nicht erneut ausgelöst, sondern in `ErrorMessage` der Abschlusszeile mit `Success = 0` gemeldet.\n- `LocID` wird für Picklisten- und Kistenverarbeitung verwendet; der Rechnungsstandort stammt aus den Auftragspositionen.\n- Das Verhalten hängt von den Einstellungen `DoNotReleaseStockOnDirectInvoiceScanOut`, `DefaultShippingWeight`, `CalculateWeightFromItems`, `PutThisStatusesOnInvoice`, `Invoice_CancelPartialDelivery` und `1SS_ForceAutoScanOut` ab.\n- Nebeneffekte: MQ-Ereignis `InvoiceCreated`, ein eingereihter Eintrag `Pixi_ReleaseStockFrominvoicePicklist` in `ExecQueries` beim Ausscannen, Laufzeitprotokoll über `LOG.EventDurationInsert`. Viele Lesezugriffe verwenden `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateDirectInv"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n 100245\n ,1234,1235,\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine Direktrechnung für einen Auftrag an, entweder für alle offenen Auftragspositionen oder für eine kommagetrennte Liste von Positionsschlüsseln.\n\nDer Aufruf ist ein schlanker Wrapper um die interne Prozedur `Pixi_CreateDirectInvInvoices`. Übergeben werden `LocID`, `CreateEmp`, `OrderNr` und `OrderlineRefs`; alle anderen Werte sind fest: keine Prüfung \"alle Artikel auf Lager\", keine Lagerplatz-Einschränkung, kein 1SS-Modus (One-Step-Shipping), Ergebniszeile aktiv, eigene Transaktion, Erstellungsmodus `Manual`, Sprache 1.\n\n**Vorprüfungen (keine Ergebnismenge, keine Rechnung):**\n- Hat der Auftrag keine Position in einem der offenen Status `RAS`, `OPA`, `NAO`, `ANG`, `BES`, `BOR`, `NAS`, `OPH`, `NAD`, endet der Aufruf ohne Meldung.\n- Ist `OrderlineRefs` leer und liegt eine Position des Auftrags auf einer aktiven (nicht abgelaufenen) Pickliste, endet der Aufruf ohne Meldung.\n\n**Auswahl der Positionen:**\n- `OrderlineRefs` wird an Kommas getrennt; nur numerische Schlüssel > 0 werden verwendet. Bei leerem Wert werden alle Positionen des Auftrags verwendet.\n- Berechnet werden nur Positionen von `OrderNr` in den oben genannten offenen Status sowie `MIN`, und nur, wenn sie noch nicht auf einer Rechnungsposition stehen.\n- Der Kunde darf nicht gesperrt sein (`SLocked`) und die Lieferadresse nicht gesperrt (`ASlocked`); sonst wird nichts angelegt.\n\n**Rechnungserstellung:**\n1. Abhängig von der Einstellung `DoNotReleaseStockOnDirectInvoiceScanOut` (Wert `0`) wird intern eine Pickliste für die gewählten Positionen erzeugt (Teillieferung und Teilmengen erlaubt) und mit dem Kommentar `DirectInvStockRelease` markiert.\n2. In einer Transaktion wird der Rechnungskopf angelegt (MwSt-Typ `I`, oder `N`, wenn die Rechnungsadresse eine USt-IdNr. hat oder der Kunde `TaxOnInvoice = 'N'` hat), Wechselkurs und Retouren-Tracking-ID werden ermittelt und SEPA-Daten ergänzt.\n3. Rechnungspositionen werden aus den Auftragspositionen übernommen (Menge, Preis, Rabatt, MwSt, Versandkosten, Währung, Seriennummer).\n4. Die Rechnung erhält die nächste Rechnungsnummer des Shops und ein Paket-Bruttogewicht (Einstellung `DefaultShippingWeight` oder aus Artikelgewichten berechnet, wenn `CalculateWeightFromItems = 1`).\n5. Berechnete offene Positionen erhalten Status `EIN` und die Rechnungsreferenz; `MIN`-Positionen erhalten nur die Rechnungsreferenz.\n6. Bei `Invoice_CancelPartialDelivery = 1` werden verbleibende `ANG`/`HAL`/`BOR`-Positionen von Aufträgen mit erzwungener Teillieferung und Stornierung auf `STO` gesetzt.\n7. Verlangt der Versanddienstleister (`DoScanOutOnInvoiceCreate`) oder die Zahlungsart (`AutoScanOutInvoice`) es, wird eine Kiste angelegt und ausgescannt sowie ein Job zur Bestandsfreigabe eingereiht.\n8. Das Ereignis `InvoiceCreated` wird veröffentlicht.\n\nAm Ende wird eine Statuszeile zurückgegeben (siehe Ergebnismengen).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | Nein | Standort-ID für die interne Pickliste sowie Kisten- und Ausscan-Verarbeitung. |\n| `CreateEmp` | varchar(50) | Nein | Benutzername, der als Ersteller der Rechnung und als Bearbeiter der Auftragspositionen gespeichert wird. |\n| `OrderNr` | int | Ja | Nummer des zu berechnenden Auftrags. |\n| `OrderlineRefs` | varchar(2000) | Ja | Kommagetrennte Positionsschlüssel, die berechnet werden sollen, z. B. `,1234,1235,`. Leerstring bedeutet alle zulässigen Positionen des Auftrags. Schlüssel, die nicht zum Auftrag gehören, werden ignoriert. |\n\n- `OrderlineRefs` hat keinen Standardwert und muss übergeben werden; ein Leerstring (oder NULL) bedeutet \"alle zulässigen Positionen\". Das dokumentierte Format ist `,1234,1235,`.\n- **Stille Abbrüche:** In den beiden Vorprüfungsfällen wird gar keine Zeile zurückgegeben. Ist Kunde oder Lieferadresse gesperrt, meldet die Abschlusszeile `Success = 1`, aber `InvoiceKey = 0` und `CreatedInv = 0`; daher `CreatedInv`/`InvoiceKey` prüfen, nicht nur `Success`.\n- Bei einem Fehler in der Rechnungstransaktion wird alles zurückgerollt, die interne Pickliste gelöscht, der Fehler protokolliert (`LOG.InsertError`), eine Zeile mit vier Spalten geliefert und der Fehler über `sp_Exception_ReRaise` (nicht beigefügt) erneut ausgelöst, sodass der Client zusätzlich eine `SqlMessage` erhält.\n- Ein Fehler beim Erzeugen der internen Pickliste wird nicht erneut ausgelöst, sondern in `ErrorMessage` der Abschlusszeile mit `Success = 0` gemeldet.\n- `LocID` wird für Picklisten- und Kistenverarbeitung verwendet; der Rechnungsstandort stammt aus den Auftragspositionen.\n- Das Verhalten hängt von den Einstellungen `DoNotReleaseStockOnDirectInvoiceScanOut`, `DefaultShippingWeight`, `CalculateWeightFromItems`, `PutThisStatusesOnInvoice`, `Invoice_CancelPartialDelivery` und `1SS_ForceAutoScanOut` ab.\n- Nebeneffekte: MQ-Ereignis `InvoiceCreated`, ein eingereihter Eintrag `Pixi_ReleaseStockFrominvoicePicklist` in `ExecQueries` beim Ausscannen, Laufzeitprotokoll über `LOG.EventDurationInsert`. Viele Lesezugriffe verwenden `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateDirectInv"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 48213\n 0\n 48213\n 51007\n \n"
}
]
},
{
"name": "pixiCreateDirectInvoice",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 93867\n ,280671,280672,\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine Direktrechnung für einen Auftrag an, für ausgewählte oder alle offenen Auftragspositionen, und liefert das Ergebnis als Statuszeile.\n\nWrapper um die interne Prozedur `Pixi_CreateDirectInvInvoices`. Es werden immer `CreationMode = 'Direct'` und Sprache 1 verwendet. Die Optionen der internen Prozedur für 1SS, Lagerplatz und Mindesthaltbarkeit werden nicht genutzt.\n\n**Ablauf**\n\n1. **Prüfung auf offene Positionen.** Hat der Auftrag keine Auftragsposition in einem der Status `RAS`, `OPA`, `NAO`, `ANG`, `BES`, `BOR`, `NAS`, `OPH`, `NAD` (z. B. nur `MIN`-Positionen), endet der Aufruf ohne Ergebnismenge.\n2. **Positionsauswahl.** `OrderlineRefs` wird an Kommas in Positionsschlüssel zerlegt. Ein leerer Wert oder NULL bedeutet *alle zulässigen Positionen des Auftrags*.\n3. **Prüfung auf aktive Pickliste.** Ist `OrderlineRefs` leer und liegt eine Position des Auftrags auf einer aktiven Pickliste (`PLitem.Expired = 0`), endet der Aufruf ohne Ergebnismenge.\n4. **Prüfung von Kunde und Adressen.** Kunde, Rechnungsadresse, Lieferadresse, Versanddienstleister und Währung werden aus `OrderHeader` gelesen. Ist der Kunde (`SLocked`) oder die Lieferadresse (`ASlocked`) gesperrt, wird keine Rechnung erstellt.\n5. **Pickliste zur Bestandsfreigabe.** Ist die Einstellung `DoNotReleaseStockOnDirectInvoiceScanOut` gleich `'0'` oder `AllInvoiceItemsInStock = 'Y'`, wird eine Pickliste für die ausgewählten Positionen erstellt (Teilaufträge und Teilmengen erlaubt).\n - Bei `AllInvoiceItemsInStock = 'Y'` wird die Pickliste gelöscht und keine Rechnung erstellt, wenn sie leer ist oder die gepickte Menge von der Summe der bestellten Mengen abweicht.\n - Ist die Einstellung `'1'`, wird die Pickliste nach der Prüfung wieder gelöscht.\n6. **Rechnungserstellung (in einer Transaktion).**\n - Der Rechnungskopf wird angelegt. Die MwSt-Art ist `N`, wenn die Rechnungsadresse eine USt-IdNr. (`UsStID`) hat oder der Kunde `TaxOnInvoice = 'N'` hat, sonst `I`.\n - Wechselkurs, Retouren-Tracking-ID und SEPA-Daten werden ermittelt.\n - Rechnungspositionen werden für die ausgewählten, noch nicht berechneten Positionen in den obigen Status sowie `MIN` eingefügt.\n - Die nächste Rechnungsnummer des Shops wird vergeben. Das Paketgewicht ist die Einstellung `DefaultShippingWeight`, bei `CalculateWeightFromItems = 1` die Summe der Artikelgewichte, begrenzt auf 999999.999.\n7. **Aktualisierung der Auftragspositionen.** Berechnete Nicht-`MIN`-Positionen erhalten `InvRef` und Status `EIN`. `MIN`-Positionen erhalten nur `InvRef`.\n8. **Stornierung verbleibender Positionen.** Bei Einstellung `Invoice_CancelPartialDelivery = '1'` werden verbleibende `ANG`/`HAL`/`BOR`-Positionen von Aufträgen mit `ForceToPickListIfNotFULL = 1` und `OHCancelAfterForcedShipOut = 1` auf `STO` gesetzt.\n9. **Automatischer Scan-Out.** Verlangt dies der Versanddienstleister (`DoScanOutOnInvoiceCreate`) oder die Zahlungsart (`AutoScanOutInvoice`):\n - eine Kiste wird angelegt und ausgescannt;\n - ein Job zur Bestandsfreigabe wird in `ExecQueries` eingereiht;\n - bei Einstellung `1SS_ForceAutoScanOut = 1` wird die Kiste gelöscht und `ScanOutDone` wird 1.\n10. **Event.** Das MQ-Event `InvoiceCreated` wird veröffentlicht und die Transaktion bestätigt.\n\nAbschließend wird eine Statuszeile mit `Success`, `InvoiceKey`, `CreatedInv` und `InvoicePackageId` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Auftragsnummer (`OrderHeader.OrderNr`), für die die Rechnung erstellt wird. |\n| `OrderlineRefs` | varchar(2000) | Ja | Kommagetrennte Positionsschlüssel (`OrderlineKey`), von Kommas eingeschlossen, z. B. `,1234,1235,`. Leerer String oder NULL berechnet alle zulässigen Positionen des Auftrags. |\n| `AllInvoiceItemsInStock` | varchar(1) | Nein | Bei `Y` wird die Rechnung nur erstellt, wenn alle ausgewählten Positionen vollständig aus dem Bestand gepickt werden können. NULL wird wie `N` behandelt. |\n| `LocID` | varchar(3) | Nein | Standort-ID für Picklistenerstellung, Kistenanlage und Scan-Out. |\n| `CreateEmp` | varchar(50) | Nein | Benutzername, der als Ersteller der Rechnung, der Rechnungspositionen und der Positionsänderungen gespeichert wird. |\n\n- **In einigen Fällen keine Ergebnismenge.** Der Aufruf liefert gar keine Ergebnismenge, wenn der Auftrag keine offenen (Nicht-`MIN`-)Positionen hat, wenn `OrderlineRefs` leer ist und ein Teil des Auftrags auf einer aktiven Pickliste liegt, oder wenn bei `AllInvoiceItemsInStock = 'Y'` die gepickte Menge nicht passt. Clients müssen ein fehlendes `SqlRowSet1` behandeln.\n- **`Success = 1` garantiert keine Rechnung.** In diesen Fällen bleiben `InvoiceKey`/`CreatedInv` 0:\n - Kunde oder Lieferadresse ist gesperrt;\n - es wurden keine zulässigen Positionen gefunden;\n - die Pickliste war bei `AllInvoiceItemsInStock = 'Y'` leer.\n `CreatedInv > 0` sollte immer geprüft werden.\n- **Fehler werden doppelt gemeldet.** Tritt bei der Rechnungserstellung ein Fehler auf:\n - die Transaktion wird zurückgerollt und der Fehler über `LOG.InsertError` protokolliert;\n - die Pickliste wird gelöscht;\n - eine Zeile mit `Success = 0` wird geliefert;\n - anschließend wird der Fehler erneut ausgelöst (`sp_Exception_ReRaise`), sodass zusätzlich eine `SqlMessage` zurückkommt.\n- **Format von `OrderlineRefs`.** Der Wert muss kommagetrennt sein, z. B. `,1234,1235,`. Nur numerische Elemente größer 0 werden verwendet.\n- **`LocID`.** Wird nur für Picklistenerstellung und Scan-Out verwendet. Der Rechnungsstandort stammt aus den Auftragspositionen (`LocationID`).\n- **Seiteneffekte:**\n - Picklisten werden ggf. angelegt und gelöscht;\n - beim automatischen Scan-Out wird ein Job `Pixi_ReleaseStockFrominvoicePicklist` in `ExecQueries` eingereiht;\n - das MQ-Event `InvoiceCreated` wird veröffentlicht;\n - `Pixi_CA_AddPixiInvoice` wird ausgeführt;\n - eine Laufzeitprotokollierung erfolgt über `LOG.EventDurationInsert`.\n- **Nicht beigefügt.** Das Verhalten der aufgerufenen Prozeduren (z. B. `Pixi_CreatePickList`, `GOS_Qi_InvoiceNOD`, `Pixi_ScanOutBox`) ist nicht beigefügt; sie können weitere Fehler auslösen.\n- **Sperren.** Die meisten Lesezugriffe verwenden `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateDirectInvoice"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 93867\n ,280671,280672,\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine Direktrechnung für einen Auftrag an, für ausgewählte oder alle offenen Auftragspositionen, und liefert das Ergebnis als Statuszeile.\n\nWrapper um die interne Prozedur `Pixi_CreateDirectInvInvoices`. Es werden immer `CreationMode = 'Direct'` und Sprache 1 verwendet. Die Optionen der internen Prozedur für 1SS, Lagerplatz und Mindesthaltbarkeit werden nicht genutzt.\n\n**Ablauf**\n\n1. **Prüfung auf offene Positionen.** Hat der Auftrag keine Auftragsposition in einem der Status `RAS`, `OPA`, `NAO`, `ANG`, `BES`, `BOR`, `NAS`, `OPH`, `NAD` (z. B. nur `MIN`-Positionen), endet der Aufruf ohne Ergebnismenge.\n2. **Positionsauswahl.** `OrderlineRefs` wird an Kommas in Positionsschlüssel zerlegt. Ein leerer Wert oder NULL bedeutet *alle zulässigen Positionen des Auftrags*.\n3. **Prüfung auf aktive Pickliste.** Ist `OrderlineRefs` leer und liegt eine Position des Auftrags auf einer aktiven Pickliste (`PLitem.Expired = 0`), endet der Aufruf ohne Ergebnismenge.\n4. **Prüfung von Kunde und Adressen.** Kunde, Rechnungsadresse, Lieferadresse, Versanddienstleister und Währung werden aus `OrderHeader` gelesen. Ist der Kunde (`SLocked`) oder die Lieferadresse (`ASlocked`) gesperrt, wird keine Rechnung erstellt.\n5. **Pickliste zur Bestandsfreigabe.** Ist die Einstellung `DoNotReleaseStockOnDirectInvoiceScanOut` gleich `'0'` oder `AllInvoiceItemsInStock = 'Y'`, wird eine Pickliste für die ausgewählten Positionen erstellt (Teilaufträge und Teilmengen erlaubt).\n - Bei `AllInvoiceItemsInStock = 'Y'` wird die Pickliste gelöscht und keine Rechnung erstellt, wenn sie leer ist oder die gepickte Menge von der Summe der bestellten Mengen abweicht.\n - Ist die Einstellung `'1'`, wird die Pickliste nach der Prüfung wieder gelöscht.\n6. **Rechnungserstellung (in einer Transaktion).**\n - Der Rechnungskopf wird angelegt. Die MwSt-Art ist `N`, wenn die Rechnungsadresse eine USt-IdNr. (`UsStID`) hat oder der Kunde `TaxOnInvoice = 'N'` hat, sonst `I`.\n - Wechselkurs, Retouren-Tracking-ID und SEPA-Daten werden ermittelt.\n - Rechnungspositionen werden für die ausgewählten, noch nicht berechneten Positionen in den obigen Status sowie `MIN` eingefügt.\n - Die nächste Rechnungsnummer des Shops wird vergeben. Das Paketgewicht ist die Einstellung `DefaultShippingWeight`, bei `CalculateWeightFromItems = 1` die Summe der Artikelgewichte, begrenzt auf 999999.999.\n7. **Aktualisierung der Auftragspositionen.** Berechnete Nicht-`MIN`-Positionen erhalten `InvRef` und Status `EIN`. `MIN`-Positionen erhalten nur `InvRef`.\n8. **Stornierung verbleibender Positionen.** Bei Einstellung `Invoice_CancelPartialDelivery = '1'` werden verbleibende `ANG`/`HAL`/`BOR`-Positionen von Aufträgen mit `ForceToPickListIfNotFULL = 1` und `OHCancelAfterForcedShipOut = 1` auf `STO` gesetzt.\n9. **Automatischer Scan-Out.** Verlangt dies der Versanddienstleister (`DoScanOutOnInvoiceCreate`) oder die Zahlungsart (`AutoScanOutInvoice`):\n - eine Kiste wird angelegt und ausgescannt;\n - ein Job zur Bestandsfreigabe wird in `ExecQueries` eingereiht;\n - bei Einstellung `1SS_ForceAutoScanOut = 1` wird die Kiste gelöscht und `ScanOutDone` wird 1.\n10. **Event.** Das MQ-Event `InvoiceCreated` wird veröffentlicht und die Transaktion bestätigt.\n\nAbschließend wird eine Statuszeile mit `Success`, `InvoiceKey`, `CreatedInv` und `InvoicePackageId` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Auftragsnummer (`OrderHeader.OrderNr`), für die die Rechnung erstellt wird. |\n| `OrderlineRefs` | varchar(2000) | Ja | Kommagetrennte Positionsschlüssel (`OrderlineKey`), von Kommas eingeschlossen, z. B. `,1234,1235,`. Leerer String oder NULL berechnet alle zulässigen Positionen des Auftrags. |\n| `AllInvoiceItemsInStock` | varchar(1) | Nein | Bei `Y` wird die Rechnung nur erstellt, wenn alle ausgewählten Positionen vollständig aus dem Bestand gepickt werden können. NULL wird wie `N` behandelt. |\n| `LocID` | varchar(3) | Nein | Standort-ID für Picklistenerstellung, Kistenanlage und Scan-Out. |\n| `CreateEmp` | varchar(50) | Nein | Benutzername, der als Ersteller der Rechnung, der Rechnungspositionen und der Positionsänderungen gespeichert wird. |\n\n- **In einigen Fällen keine Ergebnismenge.** Der Aufruf liefert gar keine Ergebnismenge, wenn der Auftrag keine offenen (Nicht-`MIN`-)Positionen hat, wenn `OrderlineRefs` leer ist und ein Teil des Auftrags auf einer aktiven Pickliste liegt, oder wenn bei `AllInvoiceItemsInStock = 'Y'` die gepickte Menge nicht passt. Clients müssen ein fehlendes `SqlRowSet1` behandeln.\n- **`Success = 1` garantiert keine Rechnung.** In diesen Fällen bleiben `InvoiceKey`/`CreatedInv` 0:\n - Kunde oder Lieferadresse ist gesperrt;\n - es wurden keine zulässigen Positionen gefunden;\n - die Pickliste war bei `AllInvoiceItemsInStock = 'Y'` leer.\n `CreatedInv > 0` sollte immer geprüft werden.\n- **Fehler werden doppelt gemeldet.** Tritt bei der Rechnungserstellung ein Fehler auf:\n - die Transaktion wird zurückgerollt und der Fehler über `LOG.InsertError` protokolliert;\n - die Pickliste wird gelöscht;\n - eine Zeile mit `Success = 0` wird geliefert;\n - anschließend wird der Fehler erneut ausgelöst (`sp_Exception_ReRaise`), sodass zusätzlich eine `SqlMessage` zurückkommt.\n- **Format von `OrderlineRefs`.** Der Wert muss kommagetrennt sein, z. B. `,1234,1235,`. Nur numerische Elemente größer 0 werden verwendet.\n- **`LocID`.** Wird nur für Picklistenerstellung und Scan-Out verwendet. Der Rechnungsstandort stammt aus den Auftragspositionen (`LocationID`).\n- **Seiteneffekte:**\n - Picklisten werden ggf. angelegt und gelöscht;\n - beim automatischen Scan-Out wird ein Job `Pixi_ReleaseStockFrominvoicePicklist` in `ExecQueries` eingereiht;\n - das MQ-Event `InvoiceCreated` wird veröffentlicht;\n - `Pixi_CA_AddPixiInvoice` wird ausgeführt;\n - eine Laufzeitprotokollierung erfolgt über `LOG.EventDurationInsert`.\n- **Nicht beigefügt.** Das Verhalten der aufgerufenen Prozeduren (z. B. `Pixi_CreatePickList`, `GOS_Qi_InvoiceNOD`, `Pixi_ScanOutBox`) ist nicht beigefügt; sie können weitere Fehler auslösen.\n- **Sperren.** Die meisten Lesezugriffe verwenden `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateDirectInvoice"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 512345\n false\n 512345\n 498761\n \n"
}
]
},
{
"name": "pixiCreateInvoice",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 1042\n 001\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine Rechnung für eine gepackte Kiste (BoxNr an einem Lager) an und liefert die neue Rechnungs-ID und Rechnungsnummer mit einer Statuszeile.\n\nLegt die Rechnung für den Inhalt einer Kiste an und liefert immer genau eine Statuszeile.\n\n1. Ist `BoxNr` oder `LocId` `NULL`, wird eine Fehlerzeile geliefert. Ein leerer `UserName` wird durch `API` ersetzt.\n2. Die Kiste wird mit der internen Prozedur `GOS_BoxesRange` (Bereich `BoxNr`..`BoxNr` am Lager `LocId`) auf Fakturierbarkeit geprüft. Die Kiste ist fakturierbar, wenn alle folgenden Bedingungen gelten:\n - sie ist noch nicht als versendet markiert (`WaitForSend` <> `Y`) oder sie ist physisch voll und enthält Positionen ohne Rechnungspositionen;\n - der Kunde hat keine Versandsperre (`SLocked` nicht `Y`/`1`);\n - keine Lieferadresse der Auftragspositionen in der Kiste hat eine Versandsperre (`ASlocked`);\n - die Kistennummer ist nicht die eigene Kistennummer des Lagers (`LocBoxNumber`);\n - haben Auftragspositionen der Kiste ein Bestätigungsdatum (`ConfDate`), liegt mindestens eines davon auf dem heutigen Tag.\n3. Ist die Kiste nicht fakturierbar, wird der Grund ermittelt und als Fehlerzeile geliefert: Kiste an diesem Lager nicht gefunden, Kiste leer, Rechnung existiert bereits, Versandsperre auf einer Auftragsadresse, Versandsperre beim Kunden; sonst ein allgemeines \"Invoice creation failed.\" (deckt auch die Regeln zu `ConfDate` und Lager-Kistennummer ab).\n4. Ist die Kiste fakturierbar, legt die interne Prozedur `Pixi_CreateInv` die Rechnung mit Erstellungsmodus `API` und Sprach-ID `1` an. Dabei wird:\n - die Kiste als versendet markiert (`WaitForSend = 'Y'`) und gegen Doppelfakturierung gesperrt;\n - der Rechnungskopf (`Invoices`) und je Kistenposition eine Rechnungsposition (`Invlines`) angelegt; zusätzlich noch nicht fakturierte Auftragspositionen desselben Auftrags mit Status `MIN` oder einem Status aus der Einstellung `PutThisStatusesOnInvoice`;\n - `Orderlines.InvRef` gesetzt, die endgültige Rechnungsnummer je Shop vergeben, Bruttogewicht, Retouren-Tracking-ID und ein `InvoicePackage`-Datensatz gespeichert;\n - optional die Kiste ausgescannt, offene Teillieferungen storniert, die Rechnung auf das Kundenkonto gebucht und das Ereignis `InvoiceCreated` veröffentlicht.\n Existiert für die Kiste bereits eine Entwurfsrechnung (`InvoiceStatusId = 0`), wird stattdessen dieser Entwurf finalisiert (Erstellungsmodus `MobileShipOut`).\n5. Ergebnis: bei Erfolg eine Zeile mit `InvoiceId`, `InvoiceNr` und `Status = 'SUCCESS'`; bei Fehler sind `InvoiceId`/`InvoiceNr` `NULL` und `Status`/`Message` enthalten den Fehler.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BoxNr` | int | Ja | Nummer der gepackten Kiste, die fakturiert werden soll. |\n| `LocId` | varchar(3) | Ja | Lager-ID, zu der die Kiste gehört. |\n| `UserName` | varchar(50) | Nein | Benutzername, der als Ersteller der Rechnung und ihrer Positionen gespeichert wird. Leer oder NULL wird durch `API` ersetzt. |\n\n- Die Rechnungserstellung läuft in einer eigenen Transaktion (bzw. einem Savepoint, falls der Aufrufer bereits eine Transaktion hat). Bei Deadlock (1205) oder doppeltem Schlüssel (2601) wird bis zu 5-mal wiederholt; Wiederholungen und Fehler werden in `LogTable` und im Fehlerprotokoll erfasst.\n- Die Vorprüfungen verwenden `NOLOCK`; der eigentliche Schutz vor Doppelrechnungen ist das `UPDLOCK` auf die Kiste in `Pixi_CreateInv`.\n- Der Statuswert unterscheidet sich in der Schreibweise: Fehler der Vorprüfung liefern `Error`, Fehler aus der Rechnungserstellung `ERROR` (aus dem internen Ergebnis übernommen).\n- Fallstrick: Einige interne Fehler (z. B. \"ERROR CREATING INVOICE Invoice Total empty\", Fremdschlüsselfehler wie Aufträge verschiedener Kunden in einer Kiste) werden in `Pixi_CreateInv` abgefangen, ohne dessen Fehlermeldung zu setzen. Dann liefert dieser Aufruf `Status = 'SUCCESS'` mit `InvoiceId`/`InvoiceNr` = `NULL`. Daher immer prüfen, dass `InvoiceId` nicht `NULL` ist.\n- Das Verhalten hängt von zur Laufzeit gelesenen Einstellungen ab: `PutThisStatusesOnInvoice`, `Enforce_CheckKuhlung` (Versandkostenanpassung für Kühlartikel), `DefaultShippingWeight`, `CalculateWeightFromItems`, `Invoice_CancelPartialDelivery` (offene Positionen mit Status `ANG`, `HAL`, `BOR` werden auf `STO` gesetzt).\n- Das Ausscannen erfolgt automatisch, wenn der Versanddienstleister (`DoScanOutOnInvoiceCreate`) oder die Zahlungsart (`AutoScanOutInvoice`) dies vorsieht.\n- Der Pfad zur Finalisierung von Entwürfen (`Pixi_CreateInvoiceFromDraft`) liegt nicht vor; dessen genaues Verhalten und Meldungen sind hier nicht dokumentiert.\n- Die Fehlermeldung für fehlende Parameter nennt den Benutzernamen, geprüft werden aber nur `BoxNr` und `LocId`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateInvoice"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 1042\n 001\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine Rechnung für eine gepackte Kiste (BoxNr an einem Lager) an und liefert die neue Rechnungs-ID und Rechnungsnummer mit einer Statuszeile.\n\nLegt die Rechnung für den Inhalt einer Kiste an und liefert immer genau eine Statuszeile.\n\n1. Ist `BoxNr` oder `LocId` `NULL`, wird eine Fehlerzeile geliefert. Ein leerer `UserName` wird durch `API` ersetzt.\n2. Die Kiste wird mit der internen Prozedur `GOS_BoxesRange` (Bereich `BoxNr`..`BoxNr` am Lager `LocId`) auf Fakturierbarkeit geprüft. Die Kiste ist fakturierbar, wenn alle folgenden Bedingungen gelten:\n - sie ist noch nicht als versendet markiert (`WaitForSend` <> `Y`) oder sie ist physisch voll und enthält Positionen ohne Rechnungspositionen;\n - der Kunde hat keine Versandsperre (`SLocked` nicht `Y`/`1`);\n - keine Lieferadresse der Auftragspositionen in der Kiste hat eine Versandsperre (`ASlocked`);\n - die Kistennummer ist nicht die eigene Kistennummer des Lagers (`LocBoxNumber`);\n - haben Auftragspositionen der Kiste ein Bestätigungsdatum (`ConfDate`), liegt mindestens eines davon auf dem heutigen Tag.\n3. Ist die Kiste nicht fakturierbar, wird der Grund ermittelt und als Fehlerzeile geliefert: Kiste an diesem Lager nicht gefunden, Kiste leer, Rechnung existiert bereits, Versandsperre auf einer Auftragsadresse, Versandsperre beim Kunden; sonst ein allgemeines \"Invoice creation failed.\" (deckt auch die Regeln zu `ConfDate` und Lager-Kistennummer ab).\n4. Ist die Kiste fakturierbar, legt die interne Prozedur `Pixi_CreateInv` die Rechnung mit Erstellungsmodus `API` und Sprach-ID `1` an. Dabei wird:\n - die Kiste als versendet markiert (`WaitForSend = 'Y'`) und gegen Doppelfakturierung gesperrt;\n - der Rechnungskopf (`Invoices`) und je Kistenposition eine Rechnungsposition (`Invlines`) angelegt; zusätzlich noch nicht fakturierte Auftragspositionen desselben Auftrags mit Status `MIN` oder einem Status aus der Einstellung `PutThisStatusesOnInvoice`;\n - `Orderlines.InvRef` gesetzt, die endgültige Rechnungsnummer je Shop vergeben, Bruttogewicht, Retouren-Tracking-ID und ein `InvoicePackage`-Datensatz gespeichert;\n - optional die Kiste ausgescannt, offene Teillieferungen storniert, die Rechnung auf das Kundenkonto gebucht und das Ereignis `InvoiceCreated` veröffentlicht.\n Existiert für die Kiste bereits eine Entwurfsrechnung (`InvoiceStatusId = 0`), wird stattdessen dieser Entwurf finalisiert (Erstellungsmodus `MobileShipOut`).\n5. Ergebnis: bei Erfolg eine Zeile mit `InvoiceId`, `InvoiceNr` und `Status = 'SUCCESS'`; bei Fehler sind `InvoiceId`/`InvoiceNr` `NULL` und `Status`/`Message` enthalten den Fehler.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BoxNr` | int | Ja | Nummer der gepackten Kiste, die fakturiert werden soll. |\n| `LocId` | varchar(3) | Ja | Lager-ID, zu der die Kiste gehört. |\n| `UserName` | varchar(50) | Nein | Benutzername, der als Ersteller der Rechnung und ihrer Positionen gespeichert wird. Leer oder NULL wird durch `API` ersetzt. |\n\n- Die Rechnungserstellung läuft in einer eigenen Transaktion (bzw. einem Savepoint, falls der Aufrufer bereits eine Transaktion hat). Bei Deadlock (1205) oder doppeltem Schlüssel (2601) wird bis zu 5-mal wiederholt; Wiederholungen und Fehler werden in `LogTable` und im Fehlerprotokoll erfasst.\n- Die Vorprüfungen verwenden `NOLOCK`; der eigentliche Schutz vor Doppelrechnungen ist das `UPDLOCK` auf die Kiste in `Pixi_CreateInv`.\n- Der Statuswert unterscheidet sich in der Schreibweise: Fehler der Vorprüfung liefern `Error`, Fehler aus der Rechnungserstellung `ERROR` (aus dem internen Ergebnis übernommen).\n- Fallstrick: Einige interne Fehler (z. B. \"ERROR CREATING INVOICE Invoice Total empty\", Fremdschlüsselfehler wie Aufträge verschiedener Kunden in einer Kiste) werden in `Pixi_CreateInv` abgefangen, ohne dessen Fehlermeldung zu setzen. Dann liefert dieser Aufruf `Status = 'SUCCESS'` mit `InvoiceId`/`InvoiceNr` = `NULL`. Daher immer prüfen, dass `InvoiceId` nicht `NULL` ist.\n- Das Verhalten hängt von zur Laufzeit gelesenen Einstellungen ab: `PutThisStatusesOnInvoice`, `Enforce_CheckKuhlung` (Versandkostenanpassung für Kühlartikel), `DefaultShippingWeight`, `CalculateWeightFromItems`, `Invoice_CancelPartialDelivery` (offene Positionen mit Status `ANG`, `HAL`, `BOR` werden auf `STO` gesetzt).\n- Das Ausscannen erfolgt automatisch, wenn der Versanddienstleister (`DoScanOutOnInvoiceCreate`) oder die Zahlungsart (`AutoScanOutInvoice`) dies vorsieht.\n- Der Pfad zur Finalisierung von Entwürfen (`Pixi_CreateInvoiceFromDraft`) liegt nicht vor; dessen genaues Verhalten und Meldungen sind hier nicht dokumentiert.\n- Die Fehlermeldung für fehlende Parameter nennt den Benutzernamen, geprüft werden aber nur `BoxNr` und `LocId`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateInvoice"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 184532\n RE2024104871\n SUCCESS\n \n \n"
}
]
},
{
"name": "pixiCreatePOSInvoice",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt aus einem XML-Dokument eine neue POS-Rechnung an oder ergänzt eine offene um Positionen und bucht die verkauften Artikel aus dem Bestand aus.\n\nLegt eine Kassenrechnung (POS-Rechnung) für eine Kasse an. Alle Daten werden in einem XML-Dokument im Parameter `XML` übergeben.\n\n**Einlesen**\n- Kopfdaten aus `POSINVOICE/HEADER`: `REGISTERID` (Pflicht), `POSHEADERKEY` (optional, eine bestehende Rechnung, die ergänzt wird), `COMMENT`, `CUSTOMERNREXTERNAL` (optional) und `GENERALBIN` (optionaler allgemeiner POS-Lagerplatz).\n- Positionen aus `POSINVOICE/LINES/LINE`: `ITEMNRINT`, `QUANTITY`, `PRICE`, `DISCOUNTPERCENT` (Standard 0) und `BIN` (bevorzugter Lagerplatz, Standard leer). `COMMAND` wird gelesen, aber nicht verwendet.\n\n**Ermittlungen**\n- Der Kunde wird über `Customers.CustomerNrExternal` gesucht; sein Adressschlüssel wird an der Rechnung gespeichert.\n- Die offene POS-Session (`EndTime` ist NULL) der Kasse mit der neuesten `StartTime` liefert Lager, Session-ID und Benutzernamen.\n- Der Artikel jeder Position wird über `ItemNrInt` gesucht; dessen EAN/UPC wird übernommen.\n\n**Prüfungen** (in dieser Reihenfolge; der erste Fehler beendet den Aufruf mit einer `ERROR`-Zeile)\n1. `REGISTERID` ist vorhanden.\n2. Bei Angabe von `POSHEADERKEY` existiert die Rechnung in `POSheader2` und ihr Status ist weder `CLO` noch `STO`.\n3. Für die Kasse existiert eine offene POS-Session.\n4. Alle Artikel existieren.\n5. Bei Angabe von `CUSTOMERNREXTERNAL` existiert der Kunde.\n6. Keine Menge ist negativ.\n7. `DISCOUNTPERCENT` liegt zwischen 0 und 100.\n\n**Ausführung** (in einer Transaktion)\n- Ohne `POSHEADERKEY` wird über die interne Prozedur `Pixi_POSNewInvoice` ein neuer Rechnungskopf angelegt (Belegart `INV`). Diese Prozedur schreibt zusätzlich ein Session-Ereignis und veröffentlicht das MQ-Ereignis `POSInoviceCreated`.\n- Der Kopf wird aktualisiert: Kundenadresse, `InvoiceComment`, Änderungsbenutzer und Änderungsdatum.\n- Für jede Position:\n - Eine `POSitem2`-Zeile mit Menge, Preis, Rabatt und EAN/UPC wird angelegt.\n - Entnahme-Lagerplätze werden vorgeschlagen, mit `BIN` als Prioritäts-Lagerplatz und `GENERALBIN` als allgemeinem Lagerplatz, in aufsteigender Reihenfolge.\n - Die Vorschläge werden in `POSItemBinSelection` gespeichert.\n - Der Bestand wird von den Lagerplätzen ausgebucht (Aktionstyp 4, Lagerbewegungsreferenzen `SMORef` 15 / `SMTRef` 12).\n - Schlägt die Buchung einer Position fehl, wird der gesamte Aufruf zurückgerollt.\n- Bei Erfolg wird eine Zeile mit `ReturnCode` = `OK` und dem Rechnungsschlüssel in `Message` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | Nein | XML-Dokument mit dem Wurzelelement `POSINVOICE`. Es enthält ein `HEADER`-Element (`REGISTERID`, `POSHEADERKEY`, `COMMENT`, `CUSTOMERNREXTERNAL`, `GENERALBIN`) und `LINES/LINE`-Elemente (`ITEMNRINT`, `QUANTITY`, `PRICE`, `DISCOUNTPERCENT`, `BIN`, `COMMAND`). Werte können als Kindelemente oder als Attribute angegeben werden. Obwohl der SQL-Standardwert NULL ist, funktioniert der Aufruf ohne diesen Parameter nicht. |\n\n- **Spaltenname unterscheidet sich in der Schreibweise:** Die Erfolgszeile hat die Spalte `Message`, die Fehlerzeile die Spalte `MESSAGE`. XML-Elementnamen unterscheiden Groß- und Kleinschreibung, daher muss ein Client beide auslesen.\n- **XML-Parsing außerhalb der Fehlerbehandlung:** `sp_xml_preparedocument` läuft außerhalb des `TRY`-Blocks. Ein NULL-Wert oder ungültiges `XML` kommt daher als `SqlMessage` zurück und nicht als `ERROR`-Zeile. Das XML-Dokument-Handle wird nie mit `sp_xml_removedocument` freigegeben.\n- **Datentypfehler:** Nicht konvertierbare Werte im XML (z. B. nicht numerische `QUANTITY` oder `PRICE`) führen zu einer `ERROR`-Zeile mit der SQL-Server-Meldung.\n- **Überschriebene Kopffelder:** Wird eine bestehende Rechnung ergänzt, werden die Positionen angehängt; vorhandene Positionen bleiben unverändert. `PHCusAddrKey` und `InvoiceComment` werden immer überschrieben, mit NULL, wenn `CUSTOMERNREXTERNAL` oder `COMMENT` fehlt.\n- **Neue Rechnung bei Schlüssel 0:** Ein leerer oder `0`-Wert in `POSHEADERKEY` wird als „neu anlegen“ behandelt.\n- **Irreführende Artikel-Fehlermeldung:** Die Meldung 'Item not found' enthält die Artikelnummer einer beliebigen Position, nicht unbedingt die des fehlenden Artikels. Fehlt dort `ITEMNRINT`, ist die Meldung leer. Die Meldung wird auf 150 Zeichen gekürzt.\n- **Ungeprüfte Positionswerte:** Eine NULL-Menge und ein NULL-Preis werden nicht abgewiesen; eine Menge von 0 wird akzeptiert. `PRICE` wird wie übergeben gespeichert und nicht aus den Artikelstammdaten übernommen.\n- **Chargen und MHD:** Die Bestandsbuchung übergibt keine Charge und kein Mindesthaltbarkeitsdatum, daher kommt nur Lagerplatzbestand ohne Charge und ohne MHD in Frage. Chargen- oder MHD-geführte Artikel scheitern daher voraussichtlich mit einer Bestandsmeldung.\n- **Lagerplatzlogik nicht beigefügt:** Die eigentliche Lagerplatzwahl erfolgt in `Pixi_POS_GetTakeOutBins` und `Pixi_POSSuggestBinTakeOut`. Der Bestand wird in `Pixi_InvBinTakeOut` ausgebucht. Diese Objekte sind nicht beigefügt, daher lassen sich die genaue Lagerplatzreihenfolge und die Entnahmemeldungen hier nicht dokumentieren.\n- **Nebeneffekte der aufgerufenen Prozeduren:** `POSSession_event` und `POSBinTrack` werden geschrieben, das MQ-Ereignis `POSInoviceCreated` wird veröffentlicht, und Entnahmefehler werden in `LogTable` protokolliert.\n- **Transaktion:** Alle Änderungen laufen in einer Transaktion und werden bei jedem Fehler zurückgerollt. Lesezugriffe verwenden `NOLOCK`, die Kopfaktualisierung `ROWLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreatePOSInvoice"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt aus einem XML-Dokument eine neue POS-Rechnung an oder ergänzt eine offene um Positionen und bucht die verkauften Artikel aus dem Bestand aus.\n\nLegt eine Kassenrechnung (POS-Rechnung) für eine Kasse an. Alle Daten werden in einem XML-Dokument im Parameter `XML` übergeben.\n\n**Einlesen**\n- Kopfdaten aus `POSINVOICE/HEADER`: `REGISTERID` (Pflicht), `POSHEADERKEY` (optional, eine bestehende Rechnung, die ergänzt wird), `COMMENT`, `CUSTOMERNREXTERNAL` (optional) und `GENERALBIN` (optionaler allgemeiner POS-Lagerplatz).\n- Positionen aus `POSINVOICE/LINES/LINE`: `ITEMNRINT`, `QUANTITY`, `PRICE`, `DISCOUNTPERCENT` (Standard 0) und `BIN` (bevorzugter Lagerplatz, Standard leer). `COMMAND` wird gelesen, aber nicht verwendet.\n\n**Ermittlungen**\n- Der Kunde wird über `Customers.CustomerNrExternal` gesucht; sein Adressschlüssel wird an der Rechnung gespeichert.\n- Die offene POS-Session (`EndTime` ist NULL) der Kasse mit der neuesten `StartTime` liefert Lager, Session-ID und Benutzernamen.\n- Der Artikel jeder Position wird über `ItemNrInt` gesucht; dessen EAN/UPC wird übernommen.\n\n**Prüfungen** (in dieser Reihenfolge; der erste Fehler beendet den Aufruf mit einer `ERROR`-Zeile)\n1. `REGISTERID` ist vorhanden.\n2. Bei Angabe von `POSHEADERKEY` existiert die Rechnung in `POSheader2` und ihr Status ist weder `CLO` noch `STO`.\n3. Für die Kasse existiert eine offene POS-Session.\n4. Alle Artikel existieren.\n5. Bei Angabe von `CUSTOMERNREXTERNAL` existiert der Kunde.\n6. Keine Menge ist negativ.\n7. `DISCOUNTPERCENT` liegt zwischen 0 und 100.\n\n**Ausführung** (in einer Transaktion)\n- Ohne `POSHEADERKEY` wird über die interne Prozedur `Pixi_POSNewInvoice` ein neuer Rechnungskopf angelegt (Belegart `INV`). Diese Prozedur schreibt zusätzlich ein Session-Ereignis und veröffentlicht das MQ-Ereignis `POSInoviceCreated`.\n- Der Kopf wird aktualisiert: Kundenadresse, `InvoiceComment`, Änderungsbenutzer und Änderungsdatum.\n- Für jede Position:\n - Eine `POSitem2`-Zeile mit Menge, Preis, Rabatt und EAN/UPC wird angelegt.\n - Entnahme-Lagerplätze werden vorgeschlagen, mit `BIN` als Prioritäts-Lagerplatz und `GENERALBIN` als allgemeinem Lagerplatz, in aufsteigender Reihenfolge.\n - Die Vorschläge werden in `POSItemBinSelection` gespeichert.\n - Der Bestand wird von den Lagerplätzen ausgebucht (Aktionstyp 4, Lagerbewegungsreferenzen `SMORef` 15 / `SMTRef` 12).\n - Schlägt die Buchung einer Position fehl, wird der gesamte Aufruf zurückgerollt.\n- Bei Erfolg wird eine Zeile mit `ReturnCode` = `OK` und dem Rechnungsschlüssel in `Message` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | Nein | XML-Dokument mit dem Wurzelelement `POSINVOICE`. Es enthält ein `HEADER`-Element (`REGISTERID`, `POSHEADERKEY`, `COMMENT`, `CUSTOMERNREXTERNAL`, `GENERALBIN`) und `LINES/LINE`-Elemente (`ITEMNRINT`, `QUANTITY`, `PRICE`, `DISCOUNTPERCENT`, `BIN`, `COMMAND`). Werte können als Kindelemente oder als Attribute angegeben werden. Obwohl der SQL-Standardwert NULL ist, funktioniert der Aufruf ohne diesen Parameter nicht. |\n\n- **Spaltenname unterscheidet sich in der Schreibweise:** Die Erfolgszeile hat die Spalte `Message`, die Fehlerzeile die Spalte `MESSAGE`. XML-Elementnamen unterscheiden Groß- und Kleinschreibung, daher muss ein Client beide auslesen.\n- **XML-Parsing außerhalb der Fehlerbehandlung:** `sp_xml_preparedocument` läuft außerhalb des `TRY`-Blocks. Ein NULL-Wert oder ungültiges `XML` kommt daher als `SqlMessage` zurück und nicht als `ERROR`-Zeile. Das XML-Dokument-Handle wird nie mit `sp_xml_removedocument` freigegeben.\n- **Datentypfehler:** Nicht konvertierbare Werte im XML (z. B. nicht numerische `QUANTITY` oder `PRICE`) führen zu einer `ERROR`-Zeile mit der SQL-Server-Meldung.\n- **Überschriebene Kopffelder:** Wird eine bestehende Rechnung ergänzt, werden die Positionen angehängt; vorhandene Positionen bleiben unverändert. `PHCusAddrKey` und `InvoiceComment` werden immer überschrieben, mit NULL, wenn `CUSTOMERNREXTERNAL` oder `COMMENT` fehlt.\n- **Neue Rechnung bei Schlüssel 0:** Ein leerer oder `0`-Wert in `POSHEADERKEY` wird als „neu anlegen“ behandelt.\n- **Irreführende Artikel-Fehlermeldung:** Die Meldung 'Item not found' enthält die Artikelnummer einer beliebigen Position, nicht unbedingt die des fehlenden Artikels. Fehlt dort `ITEMNRINT`, ist die Meldung leer. Die Meldung wird auf 150 Zeichen gekürzt.\n- **Ungeprüfte Positionswerte:** Eine NULL-Menge und ein NULL-Preis werden nicht abgewiesen; eine Menge von 0 wird akzeptiert. `PRICE` wird wie übergeben gespeichert und nicht aus den Artikelstammdaten übernommen.\n- **Chargen und MHD:** Die Bestandsbuchung übergibt keine Charge und kein Mindesthaltbarkeitsdatum, daher kommt nur Lagerplatzbestand ohne Charge und ohne MHD in Frage. Chargen- oder MHD-geführte Artikel scheitern daher voraussichtlich mit einer Bestandsmeldung.\n- **Lagerplatzlogik nicht beigefügt:** Die eigentliche Lagerplatzwahl erfolgt in `Pixi_POS_GetTakeOutBins` und `Pixi_POSSuggestBinTakeOut`. Der Bestand wird in `Pixi_InvBinTakeOut` ausgebucht. Diese Objekte sind nicht beigefügt, daher lassen sich die genaue Lagerplatzreihenfolge und die Entnahmemeldungen hier nicht dokumentieren.\n- **Nebeneffekte der aufgerufenen Prozeduren:** `POSSession_event` und `POSBinTrack` werden geschrieben, das MQ-Ereignis `POSInoviceCreated` wird veröffentlicht, und Entnahmefehler werden in `LogTable` protokolliert.\n- **Transaktion:** Alle Änderungen laufen in einer Transaktion und werden bei jedem Fehler zurückgerollt. Lesezugriffe verwenden `NOLOCK`, die Kopfaktualisierung `ROWLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreatePOSInvoice"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n 10452\n \n"
}
]
},
{
"name": "pixiDatevExportPosInvoices",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T00:00:00\n 2024-05-31T00:00:00\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert POS-Verkäufe und POS-Zahlungen eines Zeitraums als DATEV-Buchungszeilen (Erlöse je Steuersatz und Zahlungen) für den Export in die Buchhaltung.\n\nWrapper für die interne Prozedur `Pixi_DatevExportPOSInvoices`. Sie erzeugt DATEV-Buchungszeilen aus Kassenbelegen (`POSheader2`/`POSitem2`) und POS-Zahlungen (`POSPayment`).\n\n**Zeitraum**: `DateFrom` wird auf den Tagesbeginn und `DateTo` auf das Tagesende gesetzt. Verglichen wird jeweils mit dem Belegdatum `PHdate`.\n\n**Erlöszeilen (`Source` = `INV`)**\n- Eine Zeile je Kassenbeleg und Steuersatz, Vorzeichen, Artikel-Buchungskonto und weiteren Gruppierungsmerkmalen. Die Positionsbeträge sind `PIQty * PIEndPrice`. Ein Kopfrabatt (Betrag oder Prozent) wird anteilig auf die Positionen verteilt.\n- `MwstSatz` ist der Steuersatz des Artikels (1 = voll, 2 = ermäßigt, 3 = null). Bei Adressen mit `AddrNoChargeVAT` wird er auf 3 gesetzt.\n- `BookKeepingAccount` hängt vom Steuersatz ab und stammt aus den Einstellungen `AccountNumberPOSInvoice`, `AccountNumberPOSInvoiceVatLow` und `AccountNumberPOSInvoiceVatZero`.\n- `VatCode` und `BookKeepingAccount` können danach durch `DatevVatCodeOverrideHigh/Low` und `DatevAccountOverrideHigh/Low` aus der Tabelle `VATs` übersteuert werden. Ein zum Belegdatum gültiger länderspezifischer Eintrag hat Vorrang vor einem allgemeinen. Konten, die als Wert von Einstellungen mit Namen wie `book%accounteucompanies%` vorkommen, werden nicht übersteuert.\n- Gruppen mit Summe 0 entfallen.\n\n**Zahlungszeilen (`Source` = `PAY`)**\n- Eine Zeile je POS-Zahlungsbetrag, ausgenommen die Zahlungsarten `B` und `-`. Der Betrag ist `POSPayment.Amount`.\n- `BookKeepingAccount` ist das `BookkeepingAccountPos` der Zahlungsart, ersatzweise die Einstellung `AccountNumberPOSPayment`.\n- `Gegenkonto` stammt aus dem Shop (`Shops.Gegenkonto`) des Kunden (`Customers.CustomerOf`), der über die Rechnung mit gleicher Nummer verknüpft ist.\n\n**Filter** (jeweils ohne Wirkung bei `NULL`):\n- `ShopId`: Shop der Adresse. Bei `INV`-Zeilen ist das die Kundenadresse des Kassenbelegs, bei `PAY`-Zeilen die Adresse der Rechnung mit gleicher Nummer.\n- `Country`: Land der Kundenadresse des Kassenbelegs.\n- `InvoiceNr`: Belegnummer (`PHdocNr`).\n- `OrderNrExternal`: externe Auftragsnummer der Auftragsposition (`INV`) bzw. des Auftragskopfs (`PAY`).\n- `BookKeepingAccount`: wirkt als Alles-oder-nichts-Schalter, nicht als Zeilenfilter. `INV`-Zeilen erscheinen nur, wenn der Wert einer der drei POS-Erlöskonto-Einstellungen entspricht. `PAY`-Zeilen erscheinen nur, wenn er `AccountNumberPOSPayment` entspricht.\n\n**Ausgabe**\n- Mit `ShowOnlySums` = 0 werden alle Zeilen geliefert. Enthalten sind nur Zeilen, deren Land in `Countries` existiert.\n- `Price` und `PriceInCents` sind Absolutwerte; die Richtung steht in `Sign`.\n- `CustomerNr` wird ersatzweise mit der Einstellung `DefaultCustomerAccountNumber` gefüllt.\n- Sortierung: `InvoiceNr`, `Source`, `InvText`, `Price`.\n\nMit `ShowOnlySums` = 1 wird nur eine Platzhalterzeile mit `ReportName` = `DATEVExportInvoices` geliefert. Alle Summenspalten dieser Zeile sind `NULL`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Ja | Beginn des Zeitraums (Belegdatum). Die Uhrzeit wird auf den Tagesbeginn gesetzt. |\n| `DateTo` | datetime | Ja | Ende des Zeitraums (Belegdatum). Wird auf das Tagesende erweitert. |\n| `ShopId` | varchar(3) | Nein | Optionaler Filter auf den Shop der Kundenadresse. Verkäufe ohne Adresse entfallen, wenn gesetzt. |\n| `ShowOnlySums` | bit | Nein | Wählt den Ausgabemodus: Buchungszeilen oder Platzhalter-Summenzeile. |\n| `Country` | varchar(3) | Nein | Optionaler Filter auf den Pixi-Ländercode der Kundenadresse des Kassenbelegs. |\n| `InvoiceNr` | varchar(20) | Nein | Optionaler Filter auf die Kassenbelegnummer (`PHdocNr`). |\n| `OrderNrExternal` | varchar(50) | Nein | Optionaler Filter auf die externe Auftragsnummer des Kassenverkaufs. |\n| `BookKeepingAccount` | varchar(255) | Nein | Optionaler Kontoschalter. `INV`-Zeilen erscheinen nur, wenn der Wert einer POS-Erlöskonto-Einstellung entspricht. `PAY`-Zeilen erscheinen nur, wenn er `AccountNumberPOSPayment` entspricht. |\n\n- Nur lesend. Alle Tabellen werden mit `NOLOCK` gelesen, außer `POSheader2` und `Addresses` im Zahlungsteil. Nicht festgeschriebene Daten können daher erscheinen.\n- Zahlreiche Einstellungen verändern die Ausgabe:\n - `BookExportDatevPro`: Vorzeichen `s`/`h` statt `+`/`-`.\n - `BookExportDatevHomeCountry`: Heimatland, Standard `D`.\n - `BookExportDatevUseOrderNrExternal`: kommagetrennte Liste von Zahlungsarten, bei denen `InvoiceNr` die externe Auftragsnummer statt der Belegnummer enthält.\n - `BookExportBookAccountAsKostenStelle`: schreibt das Artikel-Buchungskonto in `Empty2`.\n - `ExportPaymentTypeAsKostenStelle2`: `Empty3` erhält die Zahlungsart (1). Bei 2 erhält es `NULL` für `INV`-Zeilen und das Shop-`Gegenkonto` für `PAY`-Zeilen.\n - Steuerschlüssel-Einstellungen `BookEu*VatCode`, `BookGer*VatCode` und `BookNonEuVatCode`.\n- Die Steuerschlüssel-Einstellungen werden nach `int` konvertiert. Ein nicht numerischer Wert führt zu einem Konvertierungsfehler.\n- `Country` fällt auf das Land des Kassenstandorts (`Location.LocCountry`) zurück. `VatCode` und `AccountNrItems` werden dagegen nur aus dem Land der Kundenadresse ermittelt und können bei anonymen Kassenverkäufen `NULL` sein.\n- Zahlungszeilen werden mit den Kassenpositionen verknüpft. Eine Zahlung kann daher in mehrere Zeilen aufgeteilt werden, wenn die Artikel unterschiedliche Steuerschlüssel oder Artikelkonten haben.\n- Die Währung ist immer die Hauswährung der Datenbank (`pixi.GetDatabaseCurrency`).\n- `OrderNrExternal` wird auf 12 Zeichen und `InvText` auf 60 Zeichen gekürzt.\n- Der Modus `ShowOnlySums` liefert derzeit keine echten Summen, nur `NULL`-Werte.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDatevExportPosInvoices"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T00:00:00\n 2024-05-31T00:00:00\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert POS-Verkäufe und POS-Zahlungen eines Zeitraums als DATEV-Buchungszeilen (Erlöse je Steuersatz und Zahlungen) für den Export in die Buchhaltung.\n\nWrapper für die interne Prozedur `Pixi_DatevExportPOSInvoices`. Sie erzeugt DATEV-Buchungszeilen aus Kassenbelegen (`POSheader2`/`POSitem2`) und POS-Zahlungen (`POSPayment`).\n\n**Zeitraum**: `DateFrom` wird auf den Tagesbeginn und `DateTo` auf das Tagesende gesetzt. Verglichen wird jeweils mit dem Belegdatum `PHdate`.\n\n**Erlöszeilen (`Source` = `INV`)**\n- Eine Zeile je Kassenbeleg und Steuersatz, Vorzeichen, Artikel-Buchungskonto und weiteren Gruppierungsmerkmalen. Die Positionsbeträge sind `PIQty * PIEndPrice`. Ein Kopfrabatt (Betrag oder Prozent) wird anteilig auf die Positionen verteilt.\n- `MwstSatz` ist der Steuersatz des Artikels (1 = voll, 2 = ermäßigt, 3 = null). Bei Adressen mit `AddrNoChargeVAT` wird er auf 3 gesetzt.\n- `BookKeepingAccount` hängt vom Steuersatz ab und stammt aus den Einstellungen `AccountNumberPOSInvoice`, `AccountNumberPOSInvoiceVatLow` und `AccountNumberPOSInvoiceVatZero`.\n- `VatCode` und `BookKeepingAccount` können danach durch `DatevVatCodeOverrideHigh/Low` und `DatevAccountOverrideHigh/Low` aus der Tabelle `VATs` übersteuert werden. Ein zum Belegdatum gültiger länderspezifischer Eintrag hat Vorrang vor einem allgemeinen. Konten, die als Wert von Einstellungen mit Namen wie `book%accounteucompanies%` vorkommen, werden nicht übersteuert.\n- Gruppen mit Summe 0 entfallen.\n\n**Zahlungszeilen (`Source` = `PAY`)**\n- Eine Zeile je POS-Zahlungsbetrag, ausgenommen die Zahlungsarten `B` und `-`. Der Betrag ist `POSPayment.Amount`.\n- `BookKeepingAccount` ist das `BookkeepingAccountPos` der Zahlungsart, ersatzweise die Einstellung `AccountNumberPOSPayment`.\n- `Gegenkonto` stammt aus dem Shop (`Shops.Gegenkonto`) des Kunden (`Customers.CustomerOf`), der über die Rechnung mit gleicher Nummer verknüpft ist.\n\n**Filter** (jeweils ohne Wirkung bei `NULL`):\n- `ShopId`: Shop der Adresse. Bei `INV`-Zeilen ist das die Kundenadresse des Kassenbelegs, bei `PAY`-Zeilen die Adresse der Rechnung mit gleicher Nummer.\n- `Country`: Land der Kundenadresse des Kassenbelegs.\n- `InvoiceNr`: Belegnummer (`PHdocNr`).\n- `OrderNrExternal`: externe Auftragsnummer der Auftragsposition (`INV`) bzw. des Auftragskopfs (`PAY`).\n- `BookKeepingAccount`: wirkt als Alles-oder-nichts-Schalter, nicht als Zeilenfilter. `INV`-Zeilen erscheinen nur, wenn der Wert einer der drei POS-Erlöskonto-Einstellungen entspricht. `PAY`-Zeilen erscheinen nur, wenn er `AccountNumberPOSPayment` entspricht.\n\n**Ausgabe**\n- Mit `ShowOnlySums` = 0 werden alle Zeilen geliefert. Enthalten sind nur Zeilen, deren Land in `Countries` existiert.\n- `Price` und `PriceInCents` sind Absolutwerte; die Richtung steht in `Sign`.\n- `CustomerNr` wird ersatzweise mit der Einstellung `DefaultCustomerAccountNumber` gefüllt.\n- Sortierung: `InvoiceNr`, `Source`, `InvText`, `Price`.\n\nMit `ShowOnlySums` = 1 wird nur eine Platzhalterzeile mit `ReportName` = `DATEVExportInvoices` geliefert. Alle Summenspalten dieser Zeile sind `NULL`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Ja | Beginn des Zeitraums (Belegdatum). Die Uhrzeit wird auf den Tagesbeginn gesetzt. |\n| `DateTo` | datetime | Ja | Ende des Zeitraums (Belegdatum). Wird auf das Tagesende erweitert. |\n| `ShopId` | varchar(3) | Nein | Optionaler Filter auf den Shop der Kundenadresse. Verkäufe ohne Adresse entfallen, wenn gesetzt. |\n| `ShowOnlySums` | bit | Nein | Wählt den Ausgabemodus: Buchungszeilen oder Platzhalter-Summenzeile. |\n| `Country` | varchar(3) | Nein | Optionaler Filter auf den Pixi-Ländercode der Kundenadresse des Kassenbelegs. |\n| `InvoiceNr` | varchar(20) | Nein | Optionaler Filter auf die Kassenbelegnummer (`PHdocNr`). |\n| `OrderNrExternal` | varchar(50) | Nein | Optionaler Filter auf die externe Auftragsnummer des Kassenverkaufs. |\n| `BookKeepingAccount` | varchar(255) | Nein | Optionaler Kontoschalter. `INV`-Zeilen erscheinen nur, wenn der Wert einer POS-Erlöskonto-Einstellung entspricht. `PAY`-Zeilen erscheinen nur, wenn er `AccountNumberPOSPayment` entspricht. |\n\n- Nur lesend. Alle Tabellen werden mit `NOLOCK` gelesen, außer `POSheader2` und `Addresses` im Zahlungsteil. Nicht festgeschriebene Daten können daher erscheinen.\n- Zahlreiche Einstellungen verändern die Ausgabe:\n - `BookExportDatevPro`: Vorzeichen `s`/`h` statt `+`/`-`.\n - `BookExportDatevHomeCountry`: Heimatland, Standard `D`.\n - `BookExportDatevUseOrderNrExternal`: kommagetrennte Liste von Zahlungsarten, bei denen `InvoiceNr` die externe Auftragsnummer statt der Belegnummer enthält.\n - `BookExportBookAccountAsKostenStelle`: schreibt das Artikel-Buchungskonto in `Empty2`.\n - `ExportPaymentTypeAsKostenStelle2`: `Empty3` erhält die Zahlungsart (1). Bei 2 erhält es `NULL` für `INV`-Zeilen und das Shop-`Gegenkonto` für `PAY`-Zeilen.\n - Steuerschlüssel-Einstellungen `BookEu*VatCode`, `BookGer*VatCode` und `BookNonEuVatCode`.\n- Die Steuerschlüssel-Einstellungen werden nach `int` konvertiert. Ein nicht numerischer Wert führt zu einem Konvertierungsfehler.\n- `Country` fällt auf das Land des Kassenstandorts (`Location.LocCountry`) zurück. `VatCode` und `AccountNrItems` werden dagegen nur aus dem Land der Kundenadresse ermittelt und können bei anonymen Kassenverkäufen `NULL` sein.\n- Zahlungszeilen werden mit den Kassenpositionen verknüpft. Eine Zahlung kann daher in mehrere Zeilen aufgeteilt werden, wenn die Artikel unterschiedliche Steuerschlüssel oder Artikelkonten haben.\n- Die Währung ist immer die Hauswährung der Datenbank (`pixi.GetDatabaseCurrency`).\n- `OrderNrExternal` wird auf 12 Zeichen und `InvText` auf 60 Zeichen gekürzt.\n- Der Modus `ShowOnlySums` liefert derzeit keine echten Summen, nur `NULL`-Werte.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDatevExportPosInvoices"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n INV\n EUR\n 2024-05-03T14:22:00\n D\n 1\n -\n 49.90\n 4990\n 3\n 8400\n 8400\n K2024000123\n \n 2024-05-03T14:22:00\n 10000\n \n \n \n \n Max Mustermann\n Max\n Mustermann\n 1\n DE\n \n \n PAY\n EUR\n 2024-05-03T14:22:00\n D\n -\n 49.90\n 4990\n 3\n 1000\n 8400\n K2024000123\n \n 2024-05-03T14:22:00\n 10000\n \n \n \n \n Max Mustermann\n Max\n Mustermann\n 1360\n 1\n DE\n \n"
}
]
},
{
"name": "pixiDeleteInvoicePackage",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 4711\n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht ein Versandpaket samt Paketpositionen einer Rechnung und aktualisiert Tracking-IDs und Paketanzahl der Rechnung.\n\nEntfernt einen Paketdatensatz (`pixi.InvoicePackage`), der zu einer Rechnung gehört, z. B. nach dem Stornieren eines Versandlabels.\n\nDer Aufruf führt diese Prüfungen nacheinander aus und liefert in jedem Fall genau eine Zeile mit der Spalte `Response`:\n\n1. Das Paket `PackageId` muss existieren. Andernfalls: `400 Bad Request - Package ID does not exist.`\n2. Das Paket muss zur Rechnung `InvoiceKey` gehören. Andernfalls: `400 Bad Request - Invoice ID does not match the package.`\n3. Die Rechnung muss mehr als ein Paket haben. Das letzte verbleibende Paket einer Rechnung kann nicht gelöscht werden: `400 Bad Request - This is the last package for invoice and delete is not allowed.`\n\nSind alle Prüfungen erfolgreich:\n\n- werden alle Paketpositionen (`pixi.InvoicePackageLines`) des Pakets gelöscht,\n- wird das Paket selbst gelöscht,\n- wird in `Invoices` die Tracking-ID des Pakets inklusive folgendem `;` aus `ShipmentTrackingID` entfernt und `Packages` auf die Anzahl der verbleibenden Pakete der Rechnung gesetzt,\n- wird `200 OK` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PackageId` | int | Ja | ID des zu löschenden Pakets (`pixi.InvoicePackage.Id`). |\n| `InvoiceKey` | int | Ja | Schlüssel der Rechnung, zu der das Paket gehört. Muss mit `InvoiceId` des Pakets übereinstimmen. |\n\n- Alle Änderungen laufen in einer Transaktion (bzw. einem Savepoint, falls der Aufrufer bereits eine Transaktion geöffnet hat). Bei einem SQL-Fehler werden die Änderungen zurückgerollt, der Fehler über `log.InsertError` protokolliert und `500 Internal Server Error` als normale Zeile zurückgegeben, nicht als `SqlMessage`.\n- Die Existenz- und Anzahlprüfungen lesen `pixi.InvoicePackage` mit `NOLOCK`; parallele Änderungen werden ggf. nicht berücksichtigt.\n- Die Tracking-ID wird nur dann aus `ShipmentTrackingID` entfernt, wenn ihr ein `;` folgt. Eine Tracking-ID am Ende der Liste ohne abschließendes Semikolon bleibt im Feld stehen. `REPLACE` entfernt jedes Vorkommen des Musters.\n- Hat das Paket keine `TrackingID` (NULL), liefert der `REPLACE`-Ausdruck NULL, wodurch `ShipmentTrackingID` der Rechnung auf NULL gesetzt wird.\n- Die `ReturnTrackingId` des Pakets wird gelesen, aber nicht aus der Rechnung entfernt.\n- Wird für `InvoiceKey` NULL übergeben, folgt immer die Antwort \"does not match\".\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDeleteInvoicePackage"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 4711\n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht ein Versandpaket samt Paketpositionen einer Rechnung und aktualisiert Tracking-IDs und Paketanzahl der Rechnung.\n\nEntfernt einen Paketdatensatz (`pixi.InvoicePackage`), der zu einer Rechnung gehört, z. B. nach dem Stornieren eines Versandlabels.\n\nDer Aufruf führt diese Prüfungen nacheinander aus und liefert in jedem Fall genau eine Zeile mit der Spalte `Response`:\n\n1. Das Paket `PackageId` muss existieren. Andernfalls: `400 Bad Request - Package ID does not exist.`\n2. Das Paket muss zur Rechnung `InvoiceKey` gehören. Andernfalls: `400 Bad Request - Invoice ID does not match the package.`\n3. Die Rechnung muss mehr als ein Paket haben. Das letzte verbleibende Paket einer Rechnung kann nicht gelöscht werden: `400 Bad Request - This is the last package for invoice and delete is not allowed.`\n\nSind alle Prüfungen erfolgreich:\n\n- werden alle Paketpositionen (`pixi.InvoicePackageLines`) des Pakets gelöscht,\n- wird das Paket selbst gelöscht,\n- wird in `Invoices` die Tracking-ID des Pakets inklusive folgendem `;` aus `ShipmentTrackingID` entfernt und `Packages` auf die Anzahl der verbleibenden Pakete der Rechnung gesetzt,\n- wird `200 OK` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PackageId` | int | Ja | ID des zu löschenden Pakets (`pixi.InvoicePackage.Id`). |\n| `InvoiceKey` | int | Ja | Schlüssel der Rechnung, zu der das Paket gehört. Muss mit `InvoiceId` des Pakets übereinstimmen. |\n\n- Alle Änderungen laufen in einer Transaktion (bzw. einem Savepoint, falls der Aufrufer bereits eine Transaktion geöffnet hat). Bei einem SQL-Fehler werden die Änderungen zurückgerollt, der Fehler über `log.InsertError` protokolliert und `500 Internal Server Error` als normale Zeile zurückgegeben, nicht als `SqlMessage`.\n- Die Existenz- und Anzahlprüfungen lesen `pixi.InvoicePackage` mit `NOLOCK`; parallele Änderungen werden ggf. nicht berücksichtigt.\n- Die Tracking-ID wird nur dann aus `ShipmentTrackingID` entfernt, wenn ihr ein `;` folgt. Eine Tracking-ID am Ende der Liste ohne abschließendes Semikolon bleibt im Feld stehen. `REPLACE` entfernt jedes Vorkommen des Musters.\n- Hat das Paket keine `TrackingID` (NULL), liefert der `REPLACE`-Ausdruck NULL, wodurch `ShipmentTrackingID` der Rechnung auf NULL gesetzt wird.\n- Die `ReturnTrackingId` des Pakets wird gelesen, aber nicht aus der Rechnung entfernt.\n- Wird für `InvoiceKey` NULL übergeben, folgt immer die Antwort \"does not match\".\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDeleteInvoicePackage"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 200 OK\n \n"
}
]
},
{
"name": "pixiEmillInvoicesList",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Rechnungen eines Datumsbereichs, optional auf einen Shop beschränkt, mit Kundendaten und zugehörigem Auftrag für die eMill-Anbindung.\n\nListet Rechnungen für die eMill-Anbindung auf.\n\n- `ShopID`: Ist der Wert leer oder fehlt er, werden Rechnungen aller Shops geliefert; andernfalls nur Rechnungen, deren `InvShopID` gleich `ShopID` ist.\n- `DateFrom`: Fehlt der Wert oder liegt er vor dem 01.01.1990, wird der Beginn des aktuellen Tages (00:00:00) verwendet.\n- `DateTo`: Fehlt der Wert oder liegt er vor dem 01.01.1990, wird das Ende des aktuellen Tages (23:59:59.997) verwendet.\n- Eine Rechnung wird geliefert, wenn ihr `InvDate` zwischen `DateFrom` und `DateTo` liegt (jeweils einschließlich).\n\nZu jeder Rechnung werden ergänzt:\n\n- Kundendaten (externe Kundennummer, Anrede, Namen, E-Mail) des in der Rechnung referenzierten Kunden; diese Spalten sind leer, wenn kein Kunde gefunden wird;\n- Auftragsdaten (`OrderNr`, `OrderNrExternal`, `OrdShopID`, `OrderDate`) der Auftragsposition mit dem höchsten Schlüssel unter den Rechnungspositionen der Rechnung.\n\nDas Ergebnis hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | Nein | Shop-ID zur Filterung der Rechnungen (`InvShopID`). Leer oder nicht angegeben liefert Rechnungen aller Shops. |\n| `DateFrom` | datetime | Nein | Beginn des Rechnungsdatumsbereichs (einschließlich). Fehlend oder vor dem 01.01.1990: Beginn des aktuellen Tages. |\n| `DateTo` | datetime | Nein | Ende des Rechnungsdatumsbereichs (einschließlich). Fehlend oder vor dem 01.01.1990: Ende des aktuellen Tages (23:59:59.997). |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; nicht festgeschriebene Daten können erscheinen.\n- Rechnungen ohne Rechnungspositionen oder deren höchste referenzierte Auftragsposition nicht existiert, werden **nicht** geliefert (Inner Join auf die Auftragsposition).\n- Wird nur ein Datum übergeben, wird das andere auf heute gesetzt: Nur ein `DateTo` in der Vergangenheit ergibt `DateFrom` = heute und damit ein leeres Ergebnis.\n- `DateTo` ohne Uhrzeit bedeutet Mitternacht, spätere Rechnungen dieses Tages werden ausgeschlossen; das Tagesende sollte explizit übergeben werden.\n- Pro Rechnung wird nur ein Auftrag ausgegeben, auch wenn die Rechnung Positionen mehrerer Aufträge enthält.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEmillInvoicesList"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Rechnungen eines Datumsbereichs, optional auf einen Shop beschränkt, mit Kundendaten und zugehörigem Auftrag für die eMill-Anbindung.\n\nListet Rechnungen für die eMill-Anbindung auf.\n\n- `ShopID`: Ist der Wert leer oder fehlt er, werden Rechnungen aller Shops geliefert; andernfalls nur Rechnungen, deren `InvShopID` gleich `ShopID` ist.\n- `DateFrom`: Fehlt der Wert oder liegt er vor dem 01.01.1990, wird der Beginn des aktuellen Tages (00:00:00) verwendet.\n- `DateTo`: Fehlt der Wert oder liegt er vor dem 01.01.1990, wird das Ende des aktuellen Tages (23:59:59.997) verwendet.\n- Eine Rechnung wird geliefert, wenn ihr `InvDate` zwischen `DateFrom` und `DateTo` liegt (jeweils einschließlich).\n\nZu jeder Rechnung werden ergänzt:\n\n- Kundendaten (externe Kundennummer, Anrede, Namen, E-Mail) des in der Rechnung referenzierten Kunden; diese Spalten sind leer, wenn kein Kunde gefunden wird;\n- Auftragsdaten (`OrderNr`, `OrderNrExternal`, `OrdShopID`, `OrderDate`) der Auftragsposition mit dem höchsten Schlüssel unter den Rechnungspositionen der Rechnung.\n\nDas Ergebnis hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | Nein | Shop-ID zur Filterung der Rechnungen (`InvShopID`). Leer oder nicht angegeben liefert Rechnungen aller Shops. |\n| `DateFrom` | datetime | Nein | Beginn des Rechnungsdatumsbereichs (einschließlich). Fehlend oder vor dem 01.01.1990: Beginn des aktuellen Tages. |\n| `DateTo` | datetime | Nein | Ende des Rechnungsdatumsbereichs (einschließlich). Fehlend oder vor dem 01.01.1990: Ende des aktuellen Tages (23:59:59.997). |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; nicht festgeschriebene Daten können erscheinen.\n- Rechnungen ohne Rechnungspositionen oder deren höchste referenzierte Auftragsposition nicht existiert, werden **nicht** geliefert (Inner Join auf die Auftragsposition).\n- Wird nur ein Datum übergeben, wird das andere auf heute gesetzt: Nur ein `DateTo` in der Vergangenheit ergibt `DateFrom` = heute und damit ein leeres Ergebnis.\n- `DateTo` ohne Uhrzeit bedeutet Mitternacht, spätere Rechnungen dieses Tages werden ausgeschlossen; das Tagesende sollte explizit übergeben werden.\n- Pro Rechnung wird nur ein Auftrag ausgegeben, auch wenn die Rechnung Positionen mehrerer Aufträge enthält.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEmillInvoicesList"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n RE240512\n 48213\n K10023\n Frau\n Anna Müller\n \n anna.mueller@example.com\n 2024-05-14T10:22:31\n 153344\n 100004711\n SH1\n 2024-05-12T18:05:00\n \n"
}
]
},
{
"name": "pixiGetCountriesInvoice",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die eindeutige Liste der Länder (Code und Name), die in den Rechnungsadressen aller Rechnungen vorkommen.\n\nErmittelt das Land der Adresse, die mit jeder Rechnung verknüpft ist, und liefert jedes Land einmal mit Code und Namen.\n\n- Jede Rechnung aus `Invoices` wird über `AddrRef` = `AddrKey` mit ihrer Adresse in `Addresses` verknüpft. Rechnungen ohne passende Adresse entfallen.\n- Der Länderwert der Adresse wird in der Tabelle `countries` über `CntCode` nachgeschlagen.\n- Das Ergebnis wird dedupliziert (`DISTINCT`) und aufsteigend nach `CntName` sortiert.\n\nDer Aufruf hat keine Parameter und berücksichtigt immer alle Rechnungen der Datenbank.\n\n- Die Suche in `countries` erfolgt per `LEFT JOIN`. Enthält eine Adresse einen Länderwert, der in `countries` nicht existiert (oder leer/NULL ist), wird eine Zeile mit `CntCode` und `CntName` jeweils NULL geliefert. Durch die aufsteigende Sortierung nach `CntName` steht diese Zeile an erster Stelle.\n- Der nicht gefundene Länderwert selbst wird nicht zurückgegeben, nur die NULL-Spalten.\n- `Invoices` und `Addresses` werden mit `NOLOCK` gelesen (Dirty Reads möglich); `countries` wird ohne Sperrhinweis gelesen.\n- Die Abfrage durchläuft alle Rechnungen; bei großen Datenbanken kann der Aufruf entsprechend dauern.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCountriesInvoice"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die eindeutige Liste der Länder (Code und Name), die in den Rechnungsadressen aller Rechnungen vorkommen.\n\nErmittelt das Land der Adresse, die mit jeder Rechnung verknüpft ist, und liefert jedes Land einmal mit Code und Namen.\n\n- Jede Rechnung aus `Invoices` wird über `AddrRef` = `AddrKey` mit ihrer Adresse in `Addresses` verknüpft. Rechnungen ohne passende Adresse entfallen.\n- Der Länderwert der Adresse wird in der Tabelle `countries` über `CntCode` nachgeschlagen.\n- Das Ergebnis wird dedupliziert (`DISTINCT`) und aufsteigend nach `CntName` sortiert.\n\nDer Aufruf hat keine Parameter und berücksichtigt immer alle Rechnungen der Datenbank.\n\n- Die Suche in `countries` erfolgt per `LEFT JOIN`. Enthält eine Adresse einen Länderwert, der in `countries` nicht existiert (oder leer/NULL ist), wird eine Zeile mit `CntCode` und `CntName` jeweils NULL geliefert. Durch die aufsteigende Sortierung nach `CntName` steht diese Zeile an erster Stelle.\n- Der nicht gefundene Länderwert selbst wird nicht zurückgegeben, nur die NULL-Spalten.\n- `Invoices` und `Addresses` werden mit `NOLOCK` gelesen (Dirty Reads möglich); `countries` wird ohne Sperrhinweis gelesen.\n- Die Abfrage durchläuft alle Rechnungen; bei großen Datenbanken kann der Aufruf entsprechend dauern.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCountriesInvoice"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n AT\n Austria\n \n \n DE\n Germany\n \n"
}
]
},
{
"name": "pixiGetDatevExportInvoices",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-01-01T00:00:00\n 2024-01-31T23:59:59\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die DATEV-Exportdaten für Rechnungen in einem Zeitraum, optional gefiltert nach Shop, Land, Rechnungsnummer, externer Auftragsnummer, Sachkonto und Kostenstelle.\n\nStellt die DATEV-Exportdatei \"Rechnungen\" über die API bereit.\n\n1. Der Aufruf liest die Einstellung `BookExportDatevActive` (in Pixi als \"DATEV API Calls\" bezeichnet).\n2. Ist die Einstellung `1`, werden alle Parameter unverändert an die interne Prozedur `Pixi_DatevExportInvoices` übergeben, und deren Ergebnis wird zurückgegeben. Zusätzlich wird `@SetStartAndEndOfDay = 0` übergeben.\n3. Ist die Einstellung nicht `1`, wird kein Export ausgeführt. Stattdessen wird eine Statuszeile mit `Status` = `ERROR` und einer Meldung geliefert, dass die Einstellung nicht aktiviert ist.\n\nParameter:\n- `DateFrom` und `DateTo` sind Pflicht und legen den Zeitraum des Exports fest.\n- Alle weiteren Parameter sind optionale Filter. Ein weggelassener Filter (`NULL`) schränkt das jeweilige Kriterium nicht ein. Dies setzt voraus, dass die interne Prozedur `NULL` so behandelt.\n- `ShowOnlySums` fordert eine summierte Ausgabe statt Einzelzeilen an.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Ja | Beginn des Exportzeitraums. |\n| `DateTo` | datetime | Ja | Ende des Exportzeitraums. Der Wert wird vermutlich exakt wie übergeben verwendet, daher die Uhrzeit mit angeben. |\n| `ShopId` | varchar(3) | Nein | Optionaler Filter nach Shop-ID. |\n| `ShowOnlySums` | bit | Nein | Bei `1` werden vom Export nur Summen statt Einzelzeilen angefordert. |\n| `Country` | varchar(3) | Nein | Optionaler Filter nach Ländercode. |\n| `InvoiceNr` | varchar(20) | Nein | Optionaler Filter nach Rechnungsnummer. |\n| `OrderNrExternal` | varchar(50) | Nein | Optionaler Filter nach externer Auftragsnummer (Shop-Auftragsnummer). |\n| `BookKeepingAccount` | varchar(255) | Nein | Optionaler Filter nach Buchhaltungskonto (Sachkonto). |\n| `CostCenter` | varchar(8) | Nein | Optionaler Filter nach Kostenstelle. |\n\n- Die eigentliche Exportlogik, die Filtersemantik und die Spalten der Export-Ergebnismenge stehen in `Pixi_DatevExportInvoices`. Deren Definition liegt nicht vor, daher können die Spalten und mögliche Nebeneffekte des Exports hier nicht dokumentiert werden.\n- Da `@SetStartAndEndOfDay = 0` übergeben wird, werden `DateFrom` und `DateTo` vermutlich exakt wie übergeben verwendet und nicht auf 00:00 / 23:59:59 erweitert. Um ganze Tage abzudecken, sollten Uhrzeiten explizit angegeben werden, z. B. `2024-01-31T23:59:59`.\n- Die Einstellung wird über `fpixi_GetSetting` gelesen. Existiert die Einstellung nicht, liefert diese Funktion `0`, und der Aufruf gibt die Fehlerzeile zurück. Ein nicht nach `BIT` konvertierbarer Einstellungswert führt zu einem Konvertierungsfehler.\n- Die Einstellung wird mit `NOLOCK` aus `Settings` gelesen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetDatevExportInvoices"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-01-01T00:00:00\n 2024-01-31T23:59:59\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die DATEV-Exportdaten für Rechnungen in einem Zeitraum, optional gefiltert nach Shop, Land, Rechnungsnummer, externer Auftragsnummer, Sachkonto und Kostenstelle.\n\nStellt die DATEV-Exportdatei \"Rechnungen\" über die API bereit.\n\n1. Der Aufruf liest die Einstellung `BookExportDatevActive` (in Pixi als \"DATEV API Calls\" bezeichnet).\n2. Ist die Einstellung `1`, werden alle Parameter unverändert an die interne Prozedur `Pixi_DatevExportInvoices` übergeben, und deren Ergebnis wird zurückgegeben. Zusätzlich wird `@SetStartAndEndOfDay = 0` übergeben.\n3. Ist die Einstellung nicht `1`, wird kein Export ausgeführt. Stattdessen wird eine Statuszeile mit `Status` = `ERROR` und einer Meldung geliefert, dass die Einstellung nicht aktiviert ist.\n\nParameter:\n- `DateFrom` und `DateTo` sind Pflicht und legen den Zeitraum des Exports fest.\n- Alle weiteren Parameter sind optionale Filter. Ein weggelassener Filter (`NULL`) schränkt das jeweilige Kriterium nicht ein. Dies setzt voraus, dass die interne Prozedur `NULL` so behandelt.\n- `ShowOnlySums` fordert eine summierte Ausgabe statt Einzelzeilen an.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Ja | Beginn des Exportzeitraums. |\n| `DateTo` | datetime | Ja | Ende des Exportzeitraums. Der Wert wird vermutlich exakt wie übergeben verwendet, daher die Uhrzeit mit angeben. |\n| `ShopId` | varchar(3) | Nein | Optionaler Filter nach Shop-ID. |\n| `ShowOnlySums` | bit | Nein | Bei `1` werden vom Export nur Summen statt Einzelzeilen angefordert. |\n| `Country` | varchar(3) | Nein | Optionaler Filter nach Ländercode. |\n| `InvoiceNr` | varchar(20) | Nein | Optionaler Filter nach Rechnungsnummer. |\n| `OrderNrExternal` | varchar(50) | Nein | Optionaler Filter nach externer Auftragsnummer (Shop-Auftragsnummer). |\n| `BookKeepingAccount` | varchar(255) | Nein | Optionaler Filter nach Buchhaltungskonto (Sachkonto). |\n| `CostCenter` | varchar(8) | Nein | Optionaler Filter nach Kostenstelle. |\n\n- Die eigentliche Exportlogik, die Filtersemantik und die Spalten der Export-Ergebnismenge stehen in `Pixi_DatevExportInvoices`. Deren Definition liegt nicht vor, daher können die Spalten und mögliche Nebeneffekte des Exports hier nicht dokumentiert werden.\n- Da `@SetStartAndEndOfDay = 0` übergeben wird, werden `DateFrom` und `DateTo` vermutlich exakt wie übergeben verwendet und nicht auf 00:00 / 23:59:59 erweitert. Um ganze Tage abzudecken, sollten Uhrzeiten explizit angegeben werden, z. B. `2024-01-31T23:59:59`.\n- Die Einstellung wird über `fpixi_GetSetting` gelesen. Existiert die Einstellung nicht, liefert diese Funktion `0`, und der Aufruf gibt die Fehlerzeile zurück. Ein nicht nach `BIT` konvertierbarer Einstellungswert führt zu einem Konvertierungsfehler.\n- Die Einstellung wird mit `NOLOCK` aus `Settings` gelesen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetDatevExportInvoices"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n ERROR\n Setting \"DATEV API Calls\" (BookExportDatevActive) is not enabled.\n \n"
}
]
},
{
"name": "pixiGetInkassoBookings",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-01-01T00:00:00\n 2024-01-31T23:59:59\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die im Zeitraum an das Inkasso übergebenen Rechnungen mit Kundenadresse und Beträgen; nur in den Datenbanken pixi_GCH unterstützt.\n\nDieser Aufruf ist kundenspezifisch und funktioniert nur, wenn die Pixi-Datenbank `pixi_GCH` oder `pixi_GCH_test` heißt. In allen anderen Datenbanken wird eine Statuszeile mit `Status` = `Info` und dem Hinweis geliefert, dass der Aufruf nicht mehr unterstützt wird.\n\nIn den unterstützten Datenbanken wird die interne Prozedur `Pixi_CA_GetInkassoBookings` ausgeführt und deren Zeilen werden zurückgegeben:\n\n1. Die Buchungs-Event-ID für manuelle Inkasso-Buchungen wird aus der Einstellung `CA_Inkasso_ManualBookingID` gelesen (Standard `INU`).\n2. Alle Kundenkonto-Buchungen (`CustomerAccount`) mit dieser Event-ID und einem `EventDate` zwischen `FromDate` und `ToDate` (jeweils einschließlich) werden ermittelt.\n3. Über `CustomerAccountMatch` werden die zugeordneten Buchungen in beide Richtungen gesucht und die Rechnungen bestimmt, auf die diese Buchungen verweisen.\n4. Pro Rechnung wird eine Zeile mit Kunde (`Customers`) und Kundenadresse (`Addresses`) geliefert, aufsteigend sortiert nach Rechnungsdatum (`InvDate`).\n\nDas Zeilenformat ist ein festes Exportformat für ein Inkassobüro:\n- Feste Werte: `KundenNr` = `975503`, `RecordCode` = `0`, `CompanyType` = `99`, `Land` = `001`, `Adresszusatz` und `Rechnungsgrund` leer.\n- `Sprachcode` ist `D`, wenn die Adresse zum Shop `GCH` gehört, sonst `F`.\n- `Geschlecht` ist `m` bei Anrede `Herr`, `w` bei `Frau`, sonst `f`.\n- Datumswerte (`Geburtsdatum`, `Rechnungsdatum`) haben das Format `dd.mm.yyyy`.\n- Beträge (`BetragCHF`, `Mahnkosten`, `BetragCHFtotal`) werden als Text mit Punkt als Dezimaltrennzeichen geliefert. `BetragCHF` ist der Betrag der zugeordneten Inkasso-Buchung, `BetragCHFtotal` der Rechnungsbetrag, `Mahnkosten` die Mahngebühren (0, wenn keine vorhanden).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Ja | Beginn des Zeitraums (einschließlich) für das `EventDate` der Inkasso-Buchungen. |\n| `ToDate` | datetime | Ja | Ende des Zeitraums (einschließlich) für das `EventDate` der Inkasso-Buchungen. Für den ganzen letzten Tag die Uhrzeit angeben, z. B. 23:59:59. |\n\n- Außerhalb der Datenbanken `pixi_GCH` / `pixi_GCH_test` ist der Aufruf faktisch stillgelegt: Es wird immer die `Info`-Zeile geliefert, ohne Daten abzufragen.\n- Vor dem Export wird die Hilfsprozedur `util.TableDrop` für die Alt-Tabelle `tmp.pipiGetInkassoBookings_Output` aufgerufen; die Daten selbst werden in einer temporären Tabelle gesammelt, die am Ende gelöscht wird. Die Hilfsprozeduren liegen nicht vor.\n- Die Event-ID hängt von der Einstellung `CA_Inkasso_ManualBookingID` ab, die zur Laufzeit über `dbo.SettingGet` gelesen wird.\n- Die Kundenkonto-Tabellen werden `WITH (NOLOCK)` gelesen; nicht festgeschriebene Buchungen können daher enthalten sein.\n- `EventDate BETWEEN FromDate AND ToDate` wird auf `datetime` verglichen: Ein `ToDate` ohne Uhrzeit (Mitternacht) schließt spätere Buchungen dieses Tages aus.\n- `Geburtsjahr` ist `0`, wenn kein Geburtsdatum hinterlegt ist; `Geburtsdatum` ist dann leer.\n- `BetragCHF` kann leer (NULL) sein, wenn kein passender Inkasso-Buchungsbetrag gefunden wird. Die Betragsermittlung verwendet skalare Unterabfragen; hat eine Rechnung mehrere Kundenkonto-Einträge, kann SQL Server den Fehler 'Unterabfrage hat mehr als einen Wert zurückgegeben' auslösen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInkassoBookings"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-01-01T00:00:00\n 2024-01-31T23:59:59\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die im Zeitraum an das Inkasso übergebenen Rechnungen mit Kundenadresse und Beträgen; nur in den Datenbanken pixi_GCH unterstützt.\n\nDieser Aufruf ist kundenspezifisch und funktioniert nur, wenn die Pixi-Datenbank `pixi_GCH` oder `pixi_GCH_test` heißt. In allen anderen Datenbanken wird eine Statuszeile mit `Status` = `Info` und dem Hinweis geliefert, dass der Aufruf nicht mehr unterstützt wird.\n\nIn den unterstützten Datenbanken wird die interne Prozedur `Pixi_CA_GetInkassoBookings` ausgeführt und deren Zeilen werden zurückgegeben:\n\n1. Die Buchungs-Event-ID für manuelle Inkasso-Buchungen wird aus der Einstellung `CA_Inkasso_ManualBookingID` gelesen (Standard `INU`).\n2. Alle Kundenkonto-Buchungen (`CustomerAccount`) mit dieser Event-ID und einem `EventDate` zwischen `FromDate` und `ToDate` (jeweils einschließlich) werden ermittelt.\n3. Über `CustomerAccountMatch` werden die zugeordneten Buchungen in beide Richtungen gesucht und die Rechnungen bestimmt, auf die diese Buchungen verweisen.\n4. Pro Rechnung wird eine Zeile mit Kunde (`Customers`) und Kundenadresse (`Addresses`) geliefert, aufsteigend sortiert nach Rechnungsdatum (`InvDate`).\n\nDas Zeilenformat ist ein festes Exportformat für ein Inkassobüro:\n- Feste Werte: `KundenNr` = `975503`, `RecordCode` = `0`, `CompanyType` = `99`, `Land` = `001`, `Adresszusatz` und `Rechnungsgrund` leer.\n- `Sprachcode` ist `D`, wenn die Adresse zum Shop `GCH` gehört, sonst `F`.\n- `Geschlecht` ist `m` bei Anrede `Herr`, `w` bei `Frau`, sonst `f`.\n- Datumswerte (`Geburtsdatum`, `Rechnungsdatum`) haben das Format `dd.mm.yyyy`.\n- Beträge (`BetragCHF`, `Mahnkosten`, `BetragCHFtotal`) werden als Text mit Punkt als Dezimaltrennzeichen geliefert. `BetragCHF` ist der Betrag der zugeordneten Inkasso-Buchung, `BetragCHFtotal` der Rechnungsbetrag, `Mahnkosten` die Mahngebühren (0, wenn keine vorhanden).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Ja | Beginn des Zeitraums (einschließlich) für das `EventDate` der Inkasso-Buchungen. |\n| `ToDate` | datetime | Ja | Ende des Zeitraums (einschließlich) für das `EventDate` der Inkasso-Buchungen. Für den ganzen letzten Tag die Uhrzeit angeben, z. B. 23:59:59. |\n\n- Außerhalb der Datenbanken `pixi_GCH` / `pixi_GCH_test` ist der Aufruf faktisch stillgelegt: Es wird immer die `Info`-Zeile geliefert, ohne Daten abzufragen.\n- Vor dem Export wird die Hilfsprozedur `util.TableDrop` für die Alt-Tabelle `tmp.pipiGetInkassoBookings_Output` aufgerufen; die Daten selbst werden in einer temporären Tabelle gesammelt, die am Ende gelöscht wird. Die Hilfsprozeduren liegen nicht vor.\n- Die Event-ID hängt von der Einstellung `CA_Inkasso_ManualBookingID` ab, die zur Laufzeit über `dbo.SettingGet` gelesen wird.\n- Die Kundenkonto-Tabellen werden `WITH (NOLOCK)` gelesen; nicht festgeschriebene Buchungen können daher enthalten sein.\n- `EventDate BETWEEN FromDate AND ToDate` wird auf `datetime` verglichen: Ein `ToDate` ohne Uhrzeit (Mitternacht) schließt spätere Buchungen dieses Tages aus.\n- `Geburtsjahr` ist `0`, wenn kein Geburtsdatum hinterlegt ist; `Geburtsdatum` ist dann leer.\n- `BetragCHF` kann leer (NULL) sein, wenn kein passender Inkasso-Buchungsbetrag gefunden wird. Die Betragsermittlung verwendet skalare Unterabfragen; hat eine Rechnung mehrere Kundenkonto-Einträge, kann SQL Server den Fehler 'Unterabfrage hat mehr als einen Wert zurückgegeben' auslösen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInkassoBookings"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 975503\n 0\n K-104522\n Muster\n Hans\n 99\n \n Bahnhofstrasse\n 12\n 8001\n Zürich\n 001\n D\n m\n 14.03.1978\n 1978\n 044 123 45 67\n \n hans.muster@example.ch\n 079 123 45 67\n 05.10.2023\n RE2023104411\n 149.90\n \n 20.00\n 149.90\n \n"
}
]
},
{
"name": "pixiGetInvoice",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungsköpfe mit Summen, MwSt., Zahlungsstatus, Bankdaten und verknüpften Auftragsnummern, gefiltert nach Rechnungsnummer, Shop, Datum, Auftrag oder Zahlstatus, mit schlüsselbasiertem Paging.\n\nWählt Rechnungen aus `Invoices` (verknüpft mit `Customers`) aus und liefert je Rechnung eine Zeile mit Beträgen, Zahlungs- und Versanddaten.\n\n**Normalisierung der Parameter**\n- Leere Zeichenketten in `InvoiceNr`, `ShopID`, `PaymentType`, `OrderNRExternal` sowie `OrderNR = 0` gelten als *kein Filter*.\n- `RowCount` NULL oder 0 wird zu 1000.\n- Datumsparameter vor dem 01.01.1990 werden ignoriert.\n\n**Filter** (mit UND verknüpft, nur wenn gesetzt)\n- `StartKey` > 0: nur Rechnungen mit `InvoiceKey` größer als `StartKey`.\n- `InvoiceNr`: exakte Rechnungsnummer.\n- `InvDateFrom`/`InvDateTo`: Rechnungsdatum, `ShipDateFrom`/`ShipDateTo`: Scan-Out-(Versand-)Datum, `UpdateDateFrom`/`UpdateDateTo`: letzte Änderung. Alle Datumsvergleiche sind **exklusiv** (`>` und `<`).\n- `ShopID`: Shop des Kunden (`Customers.CustomerOF`).\n- `PaymentType`: Zahlungsart-Code der Rechnung.\n- `OrderNR` / `OrderNRExternal`: Die Rechnung muss mindestens eine Rechnungsposition zu einer Auftragsposition mit dieser Auftragsnummer bzw. externen Auftragsnummer enthalten.\n- `OnlyUnpaidInvoices` = 1: Bezahlter Betrag weicht von der gerundeten Summe ab, und es existiert kein offener Kundenkontoeintrag (ohne Bankzeile, DTAUS oder manuelle Buchung) mit `DoNotRefund`.\n\n**Paging**\nEs werden die ersten `RowCount` passenden Rechnungen nach `InvoiceKey` ausgewählt. Für die nächste Seite wird der höchste `InvoiceKey` des vorigen Ergebnisses als `StartKey` übergeben.\n\n**Ergebnis**\n- `OrderNr`/`OrderNrExternal` sind die höchsten Auftragsnummern der über die Rechnungspositionen verknüpften Aufträge (bei gesetztem Auftragsfilter nur passende Auftragspositionen).\n- `CcpPayID` wird nur bei `AddCCPPayID` = 1 gefüllt und enthält eine kommagetrennte Liste der Payment-IDs der verknüpften Aufträge.\n- `PaymentDate` ist das jüngste Datum aus dem Kundenkonto-Ausgleich.\n- `Paid` ist 1, wenn der bezahlte Betrag der auf 2 Stellen gerundeten Summe entspricht.\n- `Discount_Invoice` ist bei `B2C`-Rechnungen die Brutto-, sonst die Netto-Gutscheinsumme.\n- `VATHigh`/`VATLow`/`VATSum` enthalten auch die MwSt. auf Versand- und Rücksendekosten.\n\nSortierung nach `InvoiceDate`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Nein | Exakte Rechnungsnummer. Leer = kein Filter. |\n| `ShopID` | varchar(3) | Nein | Shop-ID des Kunden (`Customers.CustomerOF`). Leer = alle Shops. |\n| `PaymentType` | char(1) | Nein | Zahlungsart-Code der Rechnung (`Invoices.Payment`). Leer = alle. |\n| `OrderNR` | int | Nein | Nur Rechnungen mit Positionen dieser Auftragsnummer. 0 = kein Filter. |\n| `OrderNRExternal` | varchar(50) | Nein | Nur Rechnungen mit Positionen dieser externen (Shop-)Auftragsnummer. Leer = kein Filter. |\n| `InvDateFrom` | datetime | Nein | Rechnungsdatum strikt nach diesem Wert. Werte vor 01.01.1990 werden ignoriert. |\n| `InvDateTo` | datetime | Nein | Rechnungsdatum strikt vor diesem Wert. Werte vor 01.01.1990 werden ignoriert. |\n| `UpdateDateFrom` | datetime | Nein | Letzte Änderung der Rechnung strikt nach diesem Wert. Werte vor 01.01.1990 werden ignoriert. |\n| `UpdateDateTo` | datetime | Nein | Letzte Änderung der Rechnung strikt vor diesem Wert. Werte vor 01.01.1990 werden ignoriert. |\n| `RowCount` | int | Nein | Maximale Anzahl ausgewählter Rechnungen (Seitengröße). NULL oder 0 = 1000. |\n| `AddCCPPayID` | bit | Nein | Bei 1 wird die Spalte `CcpPayID` mit den kommagetrennten Payment-IDs der verknüpften Aufträge gefüllt. |\n| `OnlyUnpaidInvoices` | bit | Nein | Bei 1 nur Rechnungen, deren bezahlter Betrag von der gerundeten Summe abweicht und die keinen offenen Kundenkontoeintrag mit `DoNotRefund` haben. |\n| `StartKey` | int | Nein | Paging-Schlüssel: nur Rechnungen mit `InvoiceKey` größer als dieser Wert. 0 = von Anfang an; negative Werte liefern nichts. |\n| `ShipDateFrom` | datetime | Nein | Scan-Out-(Versand-)Datum strikt nach diesem Wert. Werte vor 01.01.1990 werden ignoriert. |\n| `ShipDateTo` | datetime | Nein | Scan-Out-(Versand-)Datum strikt vor diesem Wert. Werte vor 01.01.1990 werden ignoriert. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; nicht festgeschriebene Daten können erscheinen.\n- Die Hauptselektion wird als dynamisches SQL (`sp_executesql`) mit Parametern ausgeführt.\n- `TotalRows` ist die Zeilenzahl des Selektionsschritts, der durch `RowCount` begrenzt ist; es ist **nicht** die Gesamtzahl der passenden Rechnungen.\n- Ein negativer `StartKey` liefert keine Zeilen.\n- Datumsfilter sind exklusiv: `InvDateTo = 2024-03-31` schließt Rechnungen ab genau diesem Zeitpunkt aus.\n- Die Abschlussabfrage verwendet Inner Joins auf `CustomerAccount`, `Payments`, `Addresses`, `pixi.Currency` und `pixi.ExchRate`. Rechnungen ohne passenden Datensatz dort werden nicht geliefert (aber in `TotalRows` gezählt). Eine Rechnung mit mehreren Kundenkontoeinträgen oder verknüpften Aufträgen mit unterschiedlichen `ccpPayID`-Werten kann mehrfach erscheinen.\n- Temporäre Tabellen haben eindeutige Indizes auf dem Rechnungsschlüssel; bei mehreren Kundenkontoeinträgen oder mehrdeutigen Auftragsdaten kann der Aufruf mit einem Duplicate-Key-Fehler von SQL Server abbrechen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoice"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungsköpfe mit Summen, MwSt., Zahlungsstatus, Bankdaten und verknüpften Auftragsnummern, gefiltert nach Rechnungsnummer, Shop, Datum, Auftrag oder Zahlstatus, mit schlüsselbasiertem Paging.\n\nWählt Rechnungen aus `Invoices` (verknüpft mit `Customers`) aus und liefert je Rechnung eine Zeile mit Beträgen, Zahlungs- und Versanddaten.\n\n**Normalisierung der Parameter**\n- Leere Zeichenketten in `InvoiceNr`, `ShopID`, `PaymentType`, `OrderNRExternal` sowie `OrderNR = 0` gelten als *kein Filter*.\n- `RowCount` NULL oder 0 wird zu 1000.\n- Datumsparameter vor dem 01.01.1990 werden ignoriert.\n\n**Filter** (mit UND verknüpft, nur wenn gesetzt)\n- `StartKey` > 0: nur Rechnungen mit `InvoiceKey` größer als `StartKey`.\n- `InvoiceNr`: exakte Rechnungsnummer.\n- `InvDateFrom`/`InvDateTo`: Rechnungsdatum, `ShipDateFrom`/`ShipDateTo`: Scan-Out-(Versand-)Datum, `UpdateDateFrom`/`UpdateDateTo`: letzte Änderung. Alle Datumsvergleiche sind **exklusiv** (`>` und `<`).\n- `ShopID`: Shop des Kunden (`Customers.CustomerOF`).\n- `PaymentType`: Zahlungsart-Code der Rechnung.\n- `OrderNR` / `OrderNRExternal`: Die Rechnung muss mindestens eine Rechnungsposition zu einer Auftragsposition mit dieser Auftragsnummer bzw. externen Auftragsnummer enthalten.\n- `OnlyUnpaidInvoices` = 1: Bezahlter Betrag weicht von der gerundeten Summe ab, und es existiert kein offener Kundenkontoeintrag (ohne Bankzeile, DTAUS oder manuelle Buchung) mit `DoNotRefund`.\n\n**Paging**\nEs werden die ersten `RowCount` passenden Rechnungen nach `InvoiceKey` ausgewählt. Für die nächste Seite wird der höchste `InvoiceKey` des vorigen Ergebnisses als `StartKey` übergeben.\n\n**Ergebnis**\n- `OrderNr`/`OrderNrExternal` sind die höchsten Auftragsnummern der über die Rechnungspositionen verknüpften Aufträge (bei gesetztem Auftragsfilter nur passende Auftragspositionen).\n- `CcpPayID` wird nur bei `AddCCPPayID` = 1 gefüllt und enthält eine kommagetrennte Liste der Payment-IDs der verknüpften Aufträge.\n- `PaymentDate` ist das jüngste Datum aus dem Kundenkonto-Ausgleich.\n- `Paid` ist 1, wenn der bezahlte Betrag der auf 2 Stellen gerundeten Summe entspricht.\n- `Discount_Invoice` ist bei `B2C`-Rechnungen die Brutto-, sonst die Netto-Gutscheinsumme.\n- `VATHigh`/`VATLow`/`VATSum` enthalten auch die MwSt. auf Versand- und Rücksendekosten.\n\nSortierung nach `InvoiceDate`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Nein | Exakte Rechnungsnummer. Leer = kein Filter. |\n| `ShopID` | varchar(3) | Nein | Shop-ID des Kunden (`Customers.CustomerOF`). Leer = alle Shops. |\n| `PaymentType` | char(1) | Nein | Zahlungsart-Code der Rechnung (`Invoices.Payment`). Leer = alle. |\n| `OrderNR` | int | Nein | Nur Rechnungen mit Positionen dieser Auftragsnummer. 0 = kein Filter. |\n| `OrderNRExternal` | varchar(50) | Nein | Nur Rechnungen mit Positionen dieser externen (Shop-)Auftragsnummer. Leer = kein Filter. |\n| `InvDateFrom` | datetime | Nein | Rechnungsdatum strikt nach diesem Wert. Werte vor 01.01.1990 werden ignoriert. |\n| `InvDateTo` | datetime | Nein | Rechnungsdatum strikt vor diesem Wert. Werte vor 01.01.1990 werden ignoriert. |\n| `UpdateDateFrom` | datetime | Nein | Letzte Änderung der Rechnung strikt nach diesem Wert. Werte vor 01.01.1990 werden ignoriert. |\n| `UpdateDateTo` | datetime | Nein | Letzte Änderung der Rechnung strikt vor diesem Wert. Werte vor 01.01.1990 werden ignoriert. |\n| `RowCount` | int | Nein | Maximale Anzahl ausgewählter Rechnungen (Seitengröße). NULL oder 0 = 1000. |\n| `AddCCPPayID` | bit | Nein | Bei 1 wird die Spalte `CcpPayID` mit den kommagetrennten Payment-IDs der verknüpften Aufträge gefüllt. |\n| `OnlyUnpaidInvoices` | bit | Nein | Bei 1 nur Rechnungen, deren bezahlter Betrag von der gerundeten Summe abweicht und die keinen offenen Kundenkontoeintrag mit `DoNotRefund` haben. |\n| `StartKey` | int | Nein | Paging-Schlüssel: nur Rechnungen mit `InvoiceKey` größer als dieser Wert. 0 = von Anfang an; negative Werte liefern nichts. |\n| `ShipDateFrom` | datetime | Nein | Scan-Out-(Versand-)Datum strikt nach diesem Wert. Werte vor 01.01.1990 werden ignoriert. |\n| `ShipDateTo` | datetime | Nein | Scan-Out-(Versand-)Datum strikt vor diesem Wert. Werte vor 01.01.1990 werden ignoriert. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; nicht festgeschriebene Daten können erscheinen.\n- Die Hauptselektion wird als dynamisches SQL (`sp_executesql`) mit Parametern ausgeführt.\n- `TotalRows` ist die Zeilenzahl des Selektionsschritts, der durch `RowCount` begrenzt ist; es ist **nicht** die Gesamtzahl der passenden Rechnungen.\n- Ein negativer `StartKey` liefert keine Zeilen.\n- Datumsfilter sind exklusiv: `InvDateTo = 2024-03-31` schließt Rechnungen ab genau diesem Zeitpunkt aus.\n- Die Abschlussabfrage verwendet Inner Joins auf `CustomerAccount`, `Payments`, `Addresses`, `pixi.Currency` und `pixi.ExchRate`. Rechnungen ohne passenden Datensatz dort werden nicht geliefert (aber in `TotalRows` gezählt). Eine Rechnung mit mehreren Kundenkontoeinträgen oder verknüpften Aufträgen mit unterschiedlichen `ccpPayID`-Werten kann mehrfach erscheinen.\n- Temporäre Tabellen haben eindeutige Indizes auf dem Rechnungsschlüssel; bei mehreren Kundenkontoeinträgen oder mehrdeutigen Auftragsdaten kann der Aufruf mit einem Duplicate-Key-Fehler von SQL Server abbrechen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoice"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 2\n RE2024001234\n 2024-03-05T10:15:00\n SHP\n 55120\n 55121\n 30211\n 119.00\n 19.00\n 19.00\n 0.00\n 100.00\n 4.95\n 4.16\n 0.00\n 0.00\n V\n Vorkasse\n 2024-03-06T09:00:00\n true\n 119.00\n 119.00\n 00340434161234567890\n 2024-03-05T14:30:00\n 0\n 100523\n WEB-2024-55871\n DHL\n EUR\n EUR\n 119.00\n 884512\n 0.00\n PIXI\n 1.000000\n \n"
}
]
},
{
"name": "pixiGetInvoiceLines",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100123\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Positionen einer Rechnung mit Artikel-, Auftragspositions-, Preis-, MwSt.-, Chargen- und Streckendaten, optional inklusive Versandkosten-, Gutschein- und manueller Rechnungszeilen.\n\nLiefert die Rechnungspositionen der Rechnung, deren Nummer exakt `InvoiceNr` entspricht. Die Daten stammen aus der Reporting-View `PV_Invlines`, die echte Rechnungspositionen mit künstlichen Zeilen für Beträge auf Rechnungsebene kombiniert. Jede Zeile wird um Daten der Auftragsposition (`BatchNumber`, `BestBeforeDate`, `TaxRate` als `VATPercent`) und des Artikels (`PicLinkLarge`) ergänzt.\n\n**Sonderzeilen** (gesteuert über `IncludeSpecialInvLines`):\n\n- `-2`: Versandkosten der Rechnung (`ArtName` = `ZZZ Versandkosten`), nur wenn die Versandkosten ungleich 0 sind.\n- `-1`: Gutscheine (`ArtName` = `ZZZ Gutscheine`), Preis als negative Gutscheinsumme.\n- `-3`: manuelle Rechnung ohne Rechnungspositionen (`ArtName` = `ZZZ Manuelle Rechnung ohne Artikel`), Betrag = Rechnungssumme abzüglich Versandkosten.\n\nMit `IncludeSpecialInvLines` = 0 (Standard) werden diese Zeilen ausgeschlossen, mit 1 werden sie mitgeliefert. Bei Sonderzeilen enthält `OrderLineKey` den Sonderwert (-1, -2, -3), `ItemQty` ist 1 und die meisten Artikel-/Auftragsfelder (`InvoiceLineKey`, `ArtNr`, `OrderNr`, `BoxNr`, …) sind `NULL`.\n\n`ItemPriceNoVAT` ist der Nettopreis, gerundet auf die Anzahl Nachkommastellen aus der Einstellung `PrintInvLineMoneyPrecision` (2, wenn die Einstellung fehlt oder 0 ist). Eine Sortierung findet nicht statt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(50) | Ja | Nummer der Rechnung, deren Positionen geliefert werden (exakter Vergleich mit der Rechnungsnummer). |\n| `IncludeSpecialInvLines` | bit | Nein | Legt fest, ob künstliche Zeilen für Versandkosten, Gutscheine und manuelle Rechnungen mitgeliefert werden. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, es können also nicht festgeschriebene Daten geliefert werden.\n- Der Filter auf Sonderzeilen vergleicht den Artikelschlüssel mit `NOT IN (-1, -2, -3)`. Echte Rechnungspositionen ohne Auftragsposition oder deren Auftragsposition keinen Artikel hat, haben den Artikelschlüssel `NULL` und werden bei `IncludeSpecialInvLines` = 0 **ebenfalls ausgeschlossen**. Mit dem Wert 1 werden sicher alle Zeilen der Rechnung geliefert.\n- `SerialNr` greift auf die Seriennummer einer anderen Rechnungsposition derselben Auftragsposition zurück, wenn die Zeile selbst keine hat.\n- Die Einstellung `PrintInvLineMoneyPrecision` wird zur Laufzeit aus `Settings` gelesen; shop- oder lagerspezifische Werte werden nicht berücksichtigt.\n- Die Reihenfolge der Zeilen ist undefiniert; bei Bedarf clientseitig sortieren.\n- Eine unbekannte Rechnungsnummer liefert eine leere Ergebnismenge, keinen Fehler.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoiceLines"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100123\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Positionen einer Rechnung mit Artikel-, Auftragspositions-, Preis-, MwSt.-, Chargen- und Streckendaten, optional inklusive Versandkosten-, Gutschein- und manueller Rechnungszeilen.\n\nLiefert die Rechnungspositionen der Rechnung, deren Nummer exakt `InvoiceNr` entspricht. Die Daten stammen aus der Reporting-View `PV_Invlines`, die echte Rechnungspositionen mit künstlichen Zeilen für Beträge auf Rechnungsebene kombiniert. Jede Zeile wird um Daten der Auftragsposition (`BatchNumber`, `BestBeforeDate`, `TaxRate` als `VATPercent`) und des Artikels (`PicLinkLarge`) ergänzt.\n\n**Sonderzeilen** (gesteuert über `IncludeSpecialInvLines`):\n\n- `-2`: Versandkosten der Rechnung (`ArtName` = `ZZZ Versandkosten`), nur wenn die Versandkosten ungleich 0 sind.\n- `-1`: Gutscheine (`ArtName` = `ZZZ Gutscheine`), Preis als negative Gutscheinsumme.\n- `-3`: manuelle Rechnung ohne Rechnungspositionen (`ArtName` = `ZZZ Manuelle Rechnung ohne Artikel`), Betrag = Rechnungssumme abzüglich Versandkosten.\n\nMit `IncludeSpecialInvLines` = 0 (Standard) werden diese Zeilen ausgeschlossen, mit 1 werden sie mitgeliefert. Bei Sonderzeilen enthält `OrderLineKey` den Sonderwert (-1, -2, -3), `ItemQty` ist 1 und die meisten Artikel-/Auftragsfelder (`InvoiceLineKey`, `ArtNr`, `OrderNr`, `BoxNr`, …) sind `NULL`.\n\n`ItemPriceNoVAT` ist der Nettopreis, gerundet auf die Anzahl Nachkommastellen aus der Einstellung `PrintInvLineMoneyPrecision` (2, wenn die Einstellung fehlt oder 0 ist). Eine Sortierung findet nicht statt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(50) | Ja | Nummer der Rechnung, deren Positionen geliefert werden (exakter Vergleich mit der Rechnungsnummer). |\n| `IncludeSpecialInvLines` | bit | Nein | Legt fest, ob künstliche Zeilen für Versandkosten, Gutscheine und manuelle Rechnungen mitgeliefert werden. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, es können also nicht festgeschriebene Daten geliefert werden.\n- Der Filter auf Sonderzeilen vergleicht den Artikelschlüssel mit `NOT IN (-1, -2, -3)`. Echte Rechnungspositionen ohne Auftragsposition oder deren Auftragsposition keinen Artikel hat, haben den Artikelschlüssel `NULL` und werden bei `IncludeSpecialInvLines` = 0 **ebenfalls ausgeschlossen**. Mit dem Wert 1 werden sicher alle Zeilen der Rechnung geliefert.\n- `SerialNr` greift auf die Seriennummer einer anderen Rechnungsposition derselben Auftragsposition zurück, wenn die Zeile selbst keine hat.\n- Die Einstellung `PrintInvLineMoneyPrecision` wird zur Laufzeit aus `Settings` gelesen; shop- oder lagerspezifische Werte werden nicht berücksichtigt.\n- Die Reihenfolge der Zeilen ist undefiniert; bei Bedarf clientseitig sortieren.\n- Eine unbekannte Rechnungsnummer liefert eine leere Ergebnismenge, keinen Fehler.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoiceLines"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 554321\n 100123\n 887766\n A-1001\n T-Shirt blau M\n 2\n 19.9900\n A-1001\n 4012345678901\n 50077\n SHOP-98765\n 16.8000\n 19.00\n 3.1900\n \n \n 100123\n -2\n ZZZ Versandkosten\n \n \n 1\n 4.9500\n 4.1600\n 0.7900\n \n"
}
]
},
{
"name": "pixiGetInvoiceLinesExtended",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungsköpfe zusammen mit ihren Rechnungspositionen in einer flachen Ergebnismenge, gefiltert nach Rechnung, Shop, Auftrag, Kunde, Zahlungsart und Datum.\n\nFasst Rechnungskopf- und Rechnungspositionsdaten in einem Aufruf zusammen. Jede Ergebniszeile ist eine Rechnungsposition; alle Kopf-, Rechnungsadress- und Zahlungsfelder werden auf jeder Position derselben Rechnung wiederholt.\n\n**Normalisierung der Parameter**\n- Leere Zeichenketten werden bei allen Text- und Datumsfiltern als `NULL` behandelt; `OrderNR = 0` gilt als `NULL`.\n- `RowCount` ist standardmäßig 1000; `NULL`, 0 oder negative Werte werden ebenfalls durch 1000 ersetzt.\n\n**Schritt 1 – Kandidaten-Rechnungen** (dynamisches SQL über `sp_executesql`)\nBis zu `RowCount * 3` Rechnungen werden aus `Invoices` (verknüpft mit `Customers`, Left Join auf `InvLines`) nach Rechnungsdatum sortiert ausgewählt. Nur gesetzte Filter werden ergänzt:\n- `InvoiceNr`: exakte Rechnungsnummer.\n- `ShopID`: `Customers.CustomerOf`.\n- `PaymentType`: `Invoices.Payment`.\n- `InvDateFrom` / `InvDateTo`: Rechnungsdatum echt größer / echt kleiner als der Wert.\n- `UpdateDateFrom` / `UpdateDateTo`: echt größer / kleiner als der Wert, auf `InvLines.UpdateDate` (Standard) oder auf `Invoices.UpdateDate`, wenn `ConsiderInvoiceUpdates = 1`. Datensätze mit `UpdateDate` `NULL` werden nie gefunden.\n- `OrderNR`: die Rechnung hat mindestens eine Position, die mit einer Auftragsposition dieses Auftrags verknüpft ist.\n- `OrderNRExternal`: wird über `OrderHeader.OrderNrExternal` in eine interne Auftragsnummer aufgelöst und dann wie `OrderNR` gefiltert.\n- `OnlyUnpaidInvoices = 1`: bezahlter Betrag weicht vom Gesamtbetrag ab, und es existiert kein offener `CustomerAccount`-Eintrag zur Rechnung mit `DoNotRefund = 1` (ohne Bankzeilen-, DTAUS- oder manuelle Buchungsreferenz).\n- `CustomerNrExternal`: `Customers.CustomerNrExternal`.\n\n**Schritt 2 – Köpfe und Positionen**\n- Die ersten `RowCount` Kandidaten (sortiert nach Rechnungsdatum und Rechnungsschlüssel) werden als Köpfe geladen. Nur Rechnungen mit passender Währung, einem in `Payments` vorhandenen Zahlungscode und einer Rechnungsadresse in `Addresses` bleiben erhalten.\n- Positionen werden aus der View `PV_Invlines` gelesen, die auch Pseudo-Positionen enthält: `ItemKey = -2` Versandkosten, `-1` Gutscheine, `-3` manuelle Rechnungen ohne Positionen. Lieferantenpreis und Lieferantennummer stammen aus `SupplierPrice_History`, sofern vorhanden.\n- Bei `AddCCPPayID = 1` werden die `ccpPayID`-Werte aller Aufträge der Rechnung kommagetrennt in `CcpPayID` zusammengefasst.\n\n**Schritt 3 – abschließender Filter und Ausgabe**\n- Pseudo-Positionen (`ItemKey` -1, -2, -3) werden nur bei `IncludeSpecialInvLines = 1` geliefert.\n- `Status` filtert auf den Auftragspositionsstatus der Position (`AUS`, falls kein Status vorhanden).\n- `IsReplacementOnly = 1` liefert nur Positionen, deren Auftragsposition den Status `MIN` hat oder einen `OrderHistory`-Eintrag mit Status `MIN` besitzt (Ersatzlieferungen).\n- Es werden höchstens `RowCount` Zeilen (Positionen) geliefert, sortiert nach Rechnungsdatum und Rechnungsschlüssel.\n- `UpdateDate` in der Ausgabe ist standardmäßig das Änderungs-/Anlagedatum der Position (Fallback auf das Datum der Rechnung), bei `ConsiderInvoiceUpdates = 1` das Änderungs-/Anlagedatum der Rechnung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Nein | Exakte Rechnungsnummer. Leere Zeichenkette bedeutet kein Filter. |\n| `ShopID` | varchar(3) | Nein | Shop-ID des Kunden (`Customers.CustomerOf`). |\n| `PaymentType` | char(1) | Nein | Zahlungscode der Rechnung (`Invoices.Payment`). |\n| `OrderNR` | int | Nein | Interne Auftragsnummer; liefert Rechnungen mit mindestens einer Position dieses Auftrags. 0 bedeutet kein Filter. |\n| `OrderNRExternal` | varchar(50) | Nein | Externe Auftragsnummer; wird über `OrderHeader` in die interne Auftragsnummer aufgelöst. |\n| `InvDateFrom` | datetime | Nein | Liefert Rechnungen mit Rechnungsdatum echt nach diesem Wert. |\n| `InvDateTo` | datetime | Nein | Liefert Rechnungen mit Rechnungsdatum echt vor diesem Wert. |\n| `UpdateDateFrom` | datetime | Nein | Änderungsdatum echt nach diesem Wert, auf Rechnungspositionen oder auf der Rechnung je nach `ConsiderInvoiceUpdates`. |\n| `UpdateDateTo` | datetime | Nein | Änderungsdatum echt vor diesem Wert, auf Rechnungspositionen oder auf der Rechnung je nach `ConsiderInvoiceUpdates`. |\n| `RowCount` | int | Nein | Maximale Anzahl Rechnungen und gelieferter Zeilen. `NULL`, 0 oder negative Werte werden durch 1000 ersetzt. |\n| `AddCCPPayID` | bit | Nein | Bei 1 wird `CcpPayID` mit den kommagetrennten Zahlungsanbieter-IDs der Aufträge der Rechnung gefüllt. |\n| `OnlyUnpaidInvoices` | bit | Nein | Bei 1 nur Rechnungen, deren bezahlter Betrag vom Gesamtbetrag abweicht und die keinen offenen Kundenkontoeintrag mit `DoNotRefund` haben. |\n| `IncludeSpecialInvLines` | bit | Nein | Bei 1 werden auch Pseudo-Positionen für Versandkosten (`ItemKey` -2), Gutscheine (-1) und manuelle Rechnungen ohne Positionen (-3) geliefert. |\n| `Status` | varchar(3) | Nein | Auftragspositionsstatus der Position; Positionen ohne Status gelten als `AUS`. |\n| `CustomerNrExternal` | varchar(60) | Nein | Externe Kundennummer (`Customers.CustomerNrExternal`). |\n| `IsReplacementOnly` | bit | Nein | Bei 1 nur Positionen, deren Auftragsposition den Status `MIN` hat oder hatte (Ersatzlieferung). |\n| `ConsiderInvoiceUpdates` | bit | Nein | Legt fest, welches Änderungsdatum die Änderungsdatumsfilter und die Ausgabespalte `UpdateDate` verwenden. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; nicht festgeschriebene Daten können erscheinen.\n- `RowCount` begrenzt Rechnungen **und** die finalen Positionszeilen. Da das abschließende `TOP` Positionen zählt, können Positionen der letzten Rechnung abgeschnitten werden. Für vollständige Rechnungen per `InvoiceNr` abfragen oder einen deutlich höheren `RowCount` wählen.\n- Datumsgrenzen sind exklusiv (`>` und `<`), nicht inklusiv.\n- Mit dem Standard `ConsiderInvoiceUpdates = 0` wirken die Änderungsdatumsfilter auf Rechnungspositionen; Rechnungen ohne Positionen (z. B. manuelle Rechnungen) werden dabei nie gefunden.\n- Kann `OrderNRExternal` in `OrderHeader` nicht aufgelöst werden, ist das Ergebnis leer. Teilen sich mehrere Aufträge die externe Nummer, wird nur einer davon verwendet.\n- Positionen mit `ItemKey` `NULL` (Rechnungspositionen ohne Auftragsposition oder Artikel) fallen durch die Prüfung `NOT IN (-1,-2,-3)` heraus, sofern nicht `IncludeSpecialInvLines = 1`.\n- Bei `IsReplacementOnly = 1` werden Pseudo-Positionen nie geliefert, da sie keine Auftragsposition haben.\n- `CcpPayID` wird auf 50 Zeichen gekürzt.\n- `Currency` ist immer die Konstante `EUR`; die tatsächliche Auftragswährung steht in `OrderCurrency`.\n- `OrderDate` liefert `1900-01-01`, wenn die Position keinen Auftrag hat (leere Zeichenkette als Datum). `EANUPC` ist `0` bei Positionen ohne Artikel.\n- `OrderNr` erscheint in jeder Zeile zweimal.\n- `Paid` ist nur 1, wenn der bezahlte Betrag exakt dem Rechnungsbetrag entspricht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoiceLinesExtended"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungsköpfe zusammen mit ihren Rechnungspositionen in einer flachen Ergebnismenge, gefiltert nach Rechnung, Shop, Auftrag, Kunde, Zahlungsart und Datum.\n\nFasst Rechnungskopf- und Rechnungspositionsdaten in einem Aufruf zusammen. Jede Ergebniszeile ist eine Rechnungsposition; alle Kopf-, Rechnungsadress- und Zahlungsfelder werden auf jeder Position derselben Rechnung wiederholt.\n\n**Normalisierung der Parameter**\n- Leere Zeichenketten werden bei allen Text- und Datumsfiltern als `NULL` behandelt; `OrderNR = 0` gilt als `NULL`.\n- `RowCount` ist standardmäßig 1000; `NULL`, 0 oder negative Werte werden ebenfalls durch 1000 ersetzt.\n\n**Schritt 1 – Kandidaten-Rechnungen** (dynamisches SQL über `sp_executesql`)\nBis zu `RowCount * 3` Rechnungen werden aus `Invoices` (verknüpft mit `Customers`, Left Join auf `InvLines`) nach Rechnungsdatum sortiert ausgewählt. Nur gesetzte Filter werden ergänzt:\n- `InvoiceNr`: exakte Rechnungsnummer.\n- `ShopID`: `Customers.CustomerOf`.\n- `PaymentType`: `Invoices.Payment`.\n- `InvDateFrom` / `InvDateTo`: Rechnungsdatum echt größer / echt kleiner als der Wert.\n- `UpdateDateFrom` / `UpdateDateTo`: echt größer / kleiner als der Wert, auf `InvLines.UpdateDate` (Standard) oder auf `Invoices.UpdateDate`, wenn `ConsiderInvoiceUpdates = 1`. Datensätze mit `UpdateDate` `NULL` werden nie gefunden.\n- `OrderNR`: die Rechnung hat mindestens eine Position, die mit einer Auftragsposition dieses Auftrags verknüpft ist.\n- `OrderNRExternal`: wird über `OrderHeader.OrderNrExternal` in eine interne Auftragsnummer aufgelöst und dann wie `OrderNR` gefiltert.\n- `OnlyUnpaidInvoices = 1`: bezahlter Betrag weicht vom Gesamtbetrag ab, und es existiert kein offener `CustomerAccount`-Eintrag zur Rechnung mit `DoNotRefund = 1` (ohne Bankzeilen-, DTAUS- oder manuelle Buchungsreferenz).\n- `CustomerNrExternal`: `Customers.CustomerNrExternal`.\n\n**Schritt 2 – Köpfe und Positionen**\n- Die ersten `RowCount` Kandidaten (sortiert nach Rechnungsdatum und Rechnungsschlüssel) werden als Köpfe geladen. Nur Rechnungen mit passender Währung, einem in `Payments` vorhandenen Zahlungscode und einer Rechnungsadresse in `Addresses` bleiben erhalten.\n- Positionen werden aus der View `PV_Invlines` gelesen, die auch Pseudo-Positionen enthält: `ItemKey = -2` Versandkosten, `-1` Gutscheine, `-3` manuelle Rechnungen ohne Positionen. Lieferantenpreis und Lieferantennummer stammen aus `SupplierPrice_History`, sofern vorhanden.\n- Bei `AddCCPPayID = 1` werden die `ccpPayID`-Werte aller Aufträge der Rechnung kommagetrennt in `CcpPayID` zusammengefasst.\n\n**Schritt 3 – abschließender Filter und Ausgabe**\n- Pseudo-Positionen (`ItemKey` -1, -2, -3) werden nur bei `IncludeSpecialInvLines = 1` geliefert.\n- `Status` filtert auf den Auftragspositionsstatus der Position (`AUS`, falls kein Status vorhanden).\n- `IsReplacementOnly = 1` liefert nur Positionen, deren Auftragsposition den Status `MIN` hat oder einen `OrderHistory`-Eintrag mit Status `MIN` besitzt (Ersatzlieferungen).\n- Es werden höchstens `RowCount` Zeilen (Positionen) geliefert, sortiert nach Rechnungsdatum und Rechnungsschlüssel.\n- `UpdateDate` in der Ausgabe ist standardmäßig das Änderungs-/Anlagedatum der Position (Fallback auf das Datum der Rechnung), bei `ConsiderInvoiceUpdates = 1` das Änderungs-/Anlagedatum der Rechnung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Nein | Exakte Rechnungsnummer. Leere Zeichenkette bedeutet kein Filter. |\n| `ShopID` | varchar(3) | Nein | Shop-ID des Kunden (`Customers.CustomerOf`). |\n| `PaymentType` | char(1) | Nein | Zahlungscode der Rechnung (`Invoices.Payment`). |\n| `OrderNR` | int | Nein | Interne Auftragsnummer; liefert Rechnungen mit mindestens einer Position dieses Auftrags. 0 bedeutet kein Filter. |\n| `OrderNRExternal` | varchar(50) | Nein | Externe Auftragsnummer; wird über `OrderHeader` in die interne Auftragsnummer aufgelöst. |\n| `InvDateFrom` | datetime | Nein | Liefert Rechnungen mit Rechnungsdatum echt nach diesem Wert. |\n| `InvDateTo` | datetime | Nein | Liefert Rechnungen mit Rechnungsdatum echt vor diesem Wert. |\n| `UpdateDateFrom` | datetime | Nein | Änderungsdatum echt nach diesem Wert, auf Rechnungspositionen oder auf der Rechnung je nach `ConsiderInvoiceUpdates`. |\n| `UpdateDateTo` | datetime | Nein | Änderungsdatum echt vor diesem Wert, auf Rechnungspositionen oder auf der Rechnung je nach `ConsiderInvoiceUpdates`. |\n| `RowCount` | int | Nein | Maximale Anzahl Rechnungen und gelieferter Zeilen. `NULL`, 0 oder negative Werte werden durch 1000 ersetzt. |\n| `AddCCPPayID` | bit | Nein | Bei 1 wird `CcpPayID` mit den kommagetrennten Zahlungsanbieter-IDs der Aufträge der Rechnung gefüllt. |\n| `OnlyUnpaidInvoices` | bit | Nein | Bei 1 nur Rechnungen, deren bezahlter Betrag vom Gesamtbetrag abweicht und die keinen offenen Kundenkontoeintrag mit `DoNotRefund` haben. |\n| `IncludeSpecialInvLines` | bit | Nein | Bei 1 werden auch Pseudo-Positionen für Versandkosten (`ItemKey` -2), Gutscheine (-1) und manuelle Rechnungen ohne Positionen (-3) geliefert. |\n| `Status` | varchar(3) | Nein | Auftragspositionsstatus der Position; Positionen ohne Status gelten als `AUS`. |\n| `CustomerNrExternal` | varchar(60) | Nein | Externe Kundennummer (`Customers.CustomerNrExternal`). |\n| `IsReplacementOnly` | bit | Nein | Bei 1 nur Positionen, deren Auftragsposition den Status `MIN` hat oder hatte (Ersatzlieferung). |\n| `ConsiderInvoiceUpdates` | bit | Nein | Legt fest, welches Änderungsdatum die Änderungsdatumsfilter und die Ausgabespalte `UpdateDate` verwenden. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; nicht festgeschriebene Daten können erscheinen.\n- `RowCount` begrenzt Rechnungen **und** die finalen Positionszeilen. Da das abschließende `TOP` Positionen zählt, können Positionen der letzten Rechnung abgeschnitten werden. Für vollständige Rechnungen per `InvoiceNr` abfragen oder einen deutlich höheren `RowCount` wählen.\n- Datumsgrenzen sind exklusiv (`>` und `<`), nicht inklusiv.\n- Mit dem Standard `ConsiderInvoiceUpdates = 0` wirken die Änderungsdatumsfilter auf Rechnungspositionen; Rechnungen ohne Positionen (z. B. manuelle Rechnungen) werden dabei nie gefunden.\n- Kann `OrderNRExternal` in `OrderHeader` nicht aufgelöst werden, ist das Ergebnis leer. Teilen sich mehrere Aufträge die externe Nummer, wird nur einer davon verwendet.\n- Positionen mit `ItemKey` `NULL` (Rechnungspositionen ohne Auftragsposition oder Artikel) fallen durch die Prüfung `NOT IN (-1,-2,-3)` heraus, sofern nicht `IncludeSpecialInvLines = 1`.\n- Bei `IsReplacementOnly = 1` werden Pseudo-Positionen nie geliefert, da sie keine Auftragsposition haben.\n- `CcpPayID` wird auf 50 Zeichen gekürzt.\n- `Currency` ist immer die Konstante `EUR`; die tatsächliche Auftragswährung steht in `OrderCurrency`.\n- `OrderDate` liefert `1900-01-01`, wenn die Position keinen Auftrag hat (leere Zeichenkette als Datum). `EANUPC` ist `0` bei Positionen ohne Artikel.\n- `OrderNr` erscheint in jeder Zeile zweimal.\n- `Paid` ist nur 1, wenn der bezahlte Betrag exakt dem Rechnungsbetrag entspricht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoiceLinesExtended"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n RE2024001234\n 2024-01-10T14:22:00\n SHP\n 4711\n 119.00\n 19.00\n R\n Rechnung\n false\n 2024-01-10T14:22:00\n 123456\n WEB-100045\n \n EUR\n EUR\n 98765\n Muster\n Berlin\n DE\n 555001\n 4006381333931\n Kugelschreiber blau\n 2\n 59.50\n 50.0000\n AUS\n I\n 880011\n \n"
}
]
},
{
"name": "pixiGetInvoiceLinesPrinted",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE2024-001234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Positionen einer Rechnung druckfertig aufbereitet, gruppiert pro Auftragsposition, mit optionaler Bundle-Zusammenfassung und Ersatzzeile für Rechnungen ohne Positionen.\n\nDer Aufruf übergibt `InvoiceNr` an die interne Prozedur `GOS_PrintInvLine` und liefert deren einziges Resultset.\n\n**Ablauf:**\n\n1. Die Rechnung wird über `InvoiceNr` in `Invoices` (verknüpft mit `pixi.Currency`) gesucht. Gelesen werden Schlüssel, Pickliste (`PLHref`), Gutschriftsbezug (`RefToInvoiceKey`) und `DiscountTotal`.\n2. Alle Rechnungspositionen (`Invlines`) der Rechnung werden mit Auftragspositionen, Artikeln, Ursprungsland und dem Artikelcode vom Typ 3 (`InternalItemNumber`) verknüpft. Gruppiert wird nach der übergeordneten Auftragsposition (`OriginalOrderlineRef` bzw. die Position selbst, wenn sie nicht geteilt wurde) sowie nach Preis, MwSt., Rabatt, Seriennummer, Charge, MHD und weiteren Attributen. Mengen und Beträge werden je Gruppe summiert.\n3. Pro Position werden der erste Lagerplatzname und die Anzahl der Picklistenpositionen aus der Pickliste der Rechnung ermittelt (`BinName`, `QtyFromBin`).\n4. **Bundles:** Ist die Einstellung `CombineBundles` = 1 und die Rechnung keine Gutschrift (`RefToInvoiceKey` ist NULL), werden alle Komponentenpositionen eines Bundles zu einer Zeile mit den Daten der Bundle-Auftragsposition (`BundleOrderlines`) und des Bundle-Artikels zusammengefasst. Die Bundle-Anzahl ergibt sich aus Komponentenmenge geteilt durch Menge pro Bundle aus `BundleItemsHistDetail` (oder der Menge der Bundle-Auftragsposition, falls keine Historie existiert). Andernfalls wird jede Komponentenposition einzeln geliefert.\n5. Ergibt sich keine Position (Rechnung ohne Positionen), wird eine Ersatzzeile aus dem Rechnungskopf erzeugt: Text aus `TextIfNoInvlines`, `OrderQty` = 1, Preis = Rechnungssumme minus Versandkosten, MwSt.-Kennzeichen und Steuersatz abgeleitet aus den Bemessungsgrundlagen hoch/niedrig. In dieser Zeile enthält `OrderNr` den Rechnungsschlüssel und `OrderNrExternal` die Rechnungsnummer.\n6. Sortiert wird nach `ArtName`. Jede Zeile enthält zusätzlich den Rechnungsrabatt als `InvoiceTotalDiscount`.\n\nDie Einstellung `UseInitialOrderDate` steuert `OrderDate`: 0 liefert das späteste Bestelldatum der gruppierten Auftragspositionen, 1 das früheste.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(50) | Ja | Rechnungsnummer (`Invoices.InvoiceNr`) der Rechnung, deren Positionen geliefert werden. Nur die ersten 25 Zeichen werden verwendet. |\n\n- Der Parameter ist als `varchar(50)` deklariert, die interne Prozedur akzeptiert jedoch nur `varchar(25)`; längere Rechnungsnummern werden stillschweigend abgeschnitten.\n- Existiert die Rechnungsnummer nicht (oder hat die Rechnung keine passende Währung in `pixi.Currency`), ist das Resultset leer; ein Fehler wird nicht gemeldet.\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Die Einstellungen `CombineBundles` und `UseInitialOrderDate` werden zur Laufzeit über `fpixi_GetSetting` gelesen; `ItemTagList` wird von `fpixi_GetItemTAGsNamesAsString` erzeugt. Beide Funktionen liegen nicht vor.\n- Spalten wie `itemprice_ordercurr`, `ItemAmount_OrderCurr`, `USDamount` und `EURamount` sind Altlasten (Kommentare markieren sie zur Entfernung); sie enthalten dieselben Werte wie die Spalten in Rechnungswährung.\n- `ItemAmount` enthält die Betragsdifferenzen der Positionen (`InvLineAmountDiff`), `ItemAmountNoVAT_OrderCurr` dagegen nur die Summe der Nettobeträge.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoiceLinesPrinted"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE2024-001234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Positionen einer Rechnung druckfertig aufbereitet, gruppiert pro Auftragsposition, mit optionaler Bundle-Zusammenfassung und Ersatzzeile für Rechnungen ohne Positionen.\n\nDer Aufruf übergibt `InvoiceNr` an die interne Prozedur `GOS_PrintInvLine` und liefert deren einziges Resultset.\n\n**Ablauf:**\n\n1. Die Rechnung wird über `InvoiceNr` in `Invoices` (verknüpft mit `pixi.Currency`) gesucht. Gelesen werden Schlüssel, Pickliste (`PLHref`), Gutschriftsbezug (`RefToInvoiceKey`) und `DiscountTotal`.\n2. Alle Rechnungspositionen (`Invlines`) der Rechnung werden mit Auftragspositionen, Artikeln, Ursprungsland und dem Artikelcode vom Typ 3 (`InternalItemNumber`) verknüpft. Gruppiert wird nach der übergeordneten Auftragsposition (`OriginalOrderlineRef` bzw. die Position selbst, wenn sie nicht geteilt wurde) sowie nach Preis, MwSt., Rabatt, Seriennummer, Charge, MHD und weiteren Attributen. Mengen und Beträge werden je Gruppe summiert.\n3. Pro Position werden der erste Lagerplatzname und die Anzahl der Picklistenpositionen aus der Pickliste der Rechnung ermittelt (`BinName`, `QtyFromBin`).\n4. **Bundles:** Ist die Einstellung `CombineBundles` = 1 und die Rechnung keine Gutschrift (`RefToInvoiceKey` ist NULL), werden alle Komponentenpositionen eines Bundles zu einer Zeile mit den Daten der Bundle-Auftragsposition (`BundleOrderlines`) und des Bundle-Artikels zusammengefasst. Die Bundle-Anzahl ergibt sich aus Komponentenmenge geteilt durch Menge pro Bundle aus `BundleItemsHistDetail` (oder der Menge der Bundle-Auftragsposition, falls keine Historie existiert). Andernfalls wird jede Komponentenposition einzeln geliefert.\n5. Ergibt sich keine Position (Rechnung ohne Positionen), wird eine Ersatzzeile aus dem Rechnungskopf erzeugt: Text aus `TextIfNoInvlines`, `OrderQty` = 1, Preis = Rechnungssumme minus Versandkosten, MwSt.-Kennzeichen und Steuersatz abgeleitet aus den Bemessungsgrundlagen hoch/niedrig. In dieser Zeile enthält `OrderNr` den Rechnungsschlüssel und `OrderNrExternal` die Rechnungsnummer.\n6. Sortiert wird nach `ArtName`. Jede Zeile enthält zusätzlich den Rechnungsrabatt als `InvoiceTotalDiscount`.\n\nDie Einstellung `UseInitialOrderDate` steuert `OrderDate`: 0 liefert das späteste Bestelldatum der gruppierten Auftragspositionen, 1 das früheste.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(50) | Ja | Rechnungsnummer (`Invoices.InvoiceNr`) der Rechnung, deren Positionen geliefert werden. Nur die ersten 25 Zeichen werden verwendet. |\n\n- Der Parameter ist als `varchar(50)` deklariert, die interne Prozedur akzeptiert jedoch nur `varchar(25)`; längere Rechnungsnummern werden stillschweigend abgeschnitten.\n- Existiert die Rechnungsnummer nicht (oder hat die Rechnung keine passende Währung in `pixi.Currency`), ist das Resultset leer; ein Fehler wird nicht gemeldet.\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Die Einstellungen `CombineBundles` und `UseInitialOrderDate` werden zur Laufzeit über `fpixi_GetSetting` gelesen; `ItemTagList` wird von `fpixi_GetItemTAGsNamesAsString` erzeugt. Beide Funktionen liegen nicht vor.\n- Spalten wie `itemprice_ordercurr`, `ItemAmount_OrderCurr`, `USDamount` und `EURamount` sind Altlasten (Kommentare markieren sie zur Entfernung); sie enthalten dieselben Werte wie die Spalten in Rechnungswährung.\n- `ItemAmount` enthält die Betragsdifferenzen der Positionen (`InvLineAmountDiff`), `ItemAmountNoVAT_OrderCurr` dagegen nur die Summe der Nettobeträge.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoiceLinesPrinted"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 558812\n 904417\n 4711-BL\n 2024-03-04T10:15:00\n T-Shirt Basic blau L\n EUR\n T-Shirt Basic blau L\n T-Shirt Basic\n 2\n 2\n 0\n 0\n 19.9900\n 0.0000\n H\n 4711-BL\n 39.9800\n 33.6000\n 310245\n SHOP-100234\n AUS\n A-01-03\n 2\n 1\n \n 0\n 0.0000\n 19.000\n \n"
}
]
},
{
"name": "pixiGetInvoicePackageLines",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Paketpositionen von Rechnungspaketen zu einer Rechnung (per ID oder Nummer) oder zu einem einzelnen Paket mit Artikelnummer, Rechnungsposition und Menge.\n\nLiefert die Positionen von Rechnungspaketen (`pixi.InvoicePackageLines`). Jede Position verknüpft ein Paket mit einer Rechnungsposition und einer Menge.\n\n**Eingabe und Prüfung**\n\n- Mindestens einer der Parameter `InvoiceNumber`, `InvoiceId` oder `PackageId` muss angegeben sein. Eine leere `InvoiceNumber` gilt als nicht angegeben.\n- `InvoiceNumber` wird in einen Rechnungsschlüssel aufgelöst. Sind `InvoiceId` und `InvoiceNumber` beide angegeben, müssen sie auf dieselbe Rechnung verweisen.\n- Ist `PackageId` angegeben, muss das Paket Paketpositionen haben. Ist zusätzlich eine Rechnung angegeben, muss das Paket zu dieser Rechnung gehören.\n- Ist eine Rechnung angegeben, muss mindestens ein Paket dieser Rechnung Paketpositionen haben.\n- Schlägt eine Prüfung fehl, wird eine Zeile `Status`/`Message` mit `Status` = `Error` zurückgegeben. Danach folgt keine weitere Ergebnismenge.\n\n**Auswahl**\n\n- **Nur Rechnung angegeben:** Alle Pakete der Rechnung werden verwendet.\n- **`PackageId` angegeben, mit oder ohne Rechnung:** Nur dieses Paket wird verwendet.\n- Rechnungen werden verworfen, wenn sie keine Rechnungspositionen haben oder wenn eine verknüpfte Rechnungsposition keinen Bezug zu einer Auftragsposition (`OrderLineRef`) hat.\n- Die Paketpositionen werden mit den Rechnungspositionen der ausgewählten Rechnungen abgeglichen. Es werden nur Positionen geliefert, deren Artikel eine interne Artikelnummer hat (`pixi.ItemCode`, Codetyp 2).\n- `InvoiceNr` hat in allen Zeilen denselben Wert. Es ist die Nummer der ausgewählten Rechnung.\n\nDie Ergebnismenge hat keine explizite Sortierung. Passt keine Position, wird eine Statuszeile mit `Info` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNumber` | varchar(20) | Nein | Rechnungsnummer (`InvoiceNr`). Ein Leerstring wird als NULL behandelt. Ist zusätzlich `InvoiceId` angegeben, müssen beide auf dieselbe Rechnung verweisen. |\n| `InvoiceId` | int | Nein | Rechnungsschlüssel (`InvoiceKey`) der Rechnung, deren Paketpositionen geliefert werden. |\n| `PackageId` | int | Nein | ID eines Rechnungspakets. Ist sie angegeben, werden nur die Positionen dieses Pakets geliefert. Ist zusätzlich eine Rechnung angegeben, muss das Paket zu ihr gehören. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`. Daten, die gleichzeitig geschrieben werden, können unbestätigt erscheinen.\n- Laut einem Code-Kommentar werden diese Pakete vom Delphi-ShipOut-Prozess angelegt.\n- Stolperfalle: Die Rechnung wird komplett verworfen, wenn eine ihrer verknüpften Rechnungspositionen keinen `OrderLineRef` hat. Dann liefert der Aufruf die `Info`-Zeile und keine Positionen, auch wenn die Rechnung Paketpositionen hat.\n- Positionen, deren Artikel keine interne Artikelnummer hat (Codetyp 2 in `pixi.ItemCode`), erscheinen nicht. Hat ein Artikel mehrere Codes vom Typ 2, werden seine Positionen mehrfach geliefert.\n- Fehler- und Infozeilen kommen in der normalen Ergebnismenge mit den Spalten `Status` und `Message` zurück. Es wird kein SQL-Fehler ausgelöst. Der Rückgabewert ist 1 bei Fehlern, sonst 0.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoicePackageLines"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Paketpositionen von Rechnungspaketen zu einer Rechnung (per ID oder Nummer) oder zu einem einzelnen Paket mit Artikelnummer, Rechnungsposition und Menge.\n\nLiefert die Positionen von Rechnungspaketen (`pixi.InvoicePackageLines`). Jede Position verknüpft ein Paket mit einer Rechnungsposition und einer Menge.\n\n**Eingabe und Prüfung**\n\n- Mindestens einer der Parameter `InvoiceNumber`, `InvoiceId` oder `PackageId` muss angegeben sein. Eine leere `InvoiceNumber` gilt als nicht angegeben.\n- `InvoiceNumber` wird in einen Rechnungsschlüssel aufgelöst. Sind `InvoiceId` und `InvoiceNumber` beide angegeben, müssen sie auf dieselbe Rechnung verweisen.\n- Ist `PackageId` angegeben, muss das Paket Paketpositionen haben. Ist zusätzlich eine Rechnung angegeben, muss das Paket zu dieser Rechnung gehören.\n- Ist eine Rechnung angegeben, muss mindestens ein Paket dieser Rechnung Paketpositionen haben.\n- Schlägt eine Prüfung fehl, wird eine Zeile `Status`/`Message` mit `Status` = `Error` zurückgegeben. Danach folgt keine weitere Ergebnismenge.\n\n**Auswahl**\n\n- **Nur Rechnung angegeben:** Alle Pakete der Rechnung werden verwendet.\n- **`PackageId` angegeben, mit oder ohne Rechnung:** Nur dieses Paket wird verwendet.\n- Rechnungen werden verworfen, wenn sie keine Rechnungspositionen haben oder wenn eine verknüpfte Rechnungsposition keinen Bezug zu einer Auftragsposition (`OrderLineRef`) hat.\n- Die Paketpositionen werden mit den Rechnungspositionen der ausgewählten Rechnungen abgeglichen. Es werden nur Positionen geliefert, deren Artikel eine interne Artikelnummer hat (`pixi.ItemCode`, Codetyp 2).\n- `InvoiceNr` hat in allen Zeilen denselben Wert. Es ist die Nummer der ausgewählten Rechnung.\n\nDie Ergebnismenge hat keine explizite Sortierung. Passt keine Position, wird eine Statuszeile mit `Info` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNumber` | varchar(20) | Nein | Rechnungsnummer (`InvoiceNr`). Ein Leerstring wird als NULL behandelt. Ist zusätzlich `InvoiceId` angegeben, müssen beide auf dieselbe Rechnung verweisen. |\n| `InvoiceId` | int | Nein | Rechnungsschlüssel (`InvoiceKey`) der Rechnung, deren Paketpositionen geliefert werden. |\n| `PackageId` | int | Nein | ID eines Rechnungspakets. Ist sie angegeben, werden nur die Positionen dieses Pakets geliefert. Ist zusätzlich eine Rechnung angegeben, muss das Paket zu ihr gehören. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`. Daten, die gleichzeitig geschrieben werden, können unbestätigt erscheinen.\n- Laut einem Code-Kommentar werden diese Pakete vom Delphi-ShipOut-Prozess angelegt.\n- Stolperfalle: Die Rechnung wird komplett verworfen, wenn eine ihrer verknüpften Rechnungspositionen keinen `OrderLineRef` hat. Dann liefert der Aufruf die `Info`-Zeile und keine Positionen, auch wenn die Rechnung Paketpositionen hat.\n- Positionen, deren Artikel keine interne Artikelnummer hat (Codetyp 2 in `pixi.ItemCode`), erscheinen nicht. Hat ein Artikel mehrere Codes vom Typ 2, werden seine Positionen mehrfach geliefert.\n- Fehler- und Infozeilen kommen in der normalen Ergebnismenge mit den Spalten `Status` und `Message` zurück. Es wird kein SQL-Fehler ausgelöst. Der Rückgabewert ist 1 bei Fehlern, sonst 0.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoicePackageLines"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n 58231\n RE2024001234\n 3315\n ART-100245\n 912877\n 2\n \n \n 10452\n 58231\n RE2024001234\n 4120\n ART-200871\n 912878\n 1\n \n"
}
]
},
{
"name": "pixiGetInvoicePublicLink",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert einen öffentlichen Download-Link mit Ablaufdatum für das gespeicherte Dokument einer Rechnung, ermittelt über Rechnungs-ID und/oder Rechnungsnummer.\n\nErmittelt eine Rechnung und liefert einen öffentlichen Download-Link für das zugehörige gespeicherte Dokument.\n\n1. `InvoiceNr` wird getrimmt. Ein leerer Wert gilt als nicht angegeben.\n2. Mindestens einer der Parameter `InvoiceId` oder `InvoiceNr` muss angegeben sein, sonst wird eine Fehlerzeile geliefert.\n3. **Beide angegeben:** Die Rechnung muss sowohl `InvoiceKey = InvoiceId` als auch `InvoiceNr` erfüllen.\n - Passt keine Rechnung zu beiden Werten, existiert aber eine Rechnung mit der ID oder mit der Nummer, wird der Fehler `InvoiceId and InvoiceNr do not match.` geliefert.\n - Existiert keine von beiden, wird `Invoice Not Found.` geliefert.\n4. **Nur ein Wert angegeben:** Die Rechnung wird über diesen Wert gesucht. Wird keine gefunden, wird `Invoice Not Found.` geliefert.\n5. Ist der Rechnung kein Dokument zugeordnet (`DocumentStorageId` leer), wird `Document Not Found.` geliefert.\n6. Link und Ablaufdatum werden von der internen Prozedur `pixi.DocumentPublicLink_Get` erzeugt. Meldet diese einen Status ungleich 0, wird `Failed to generate invoice download link.` geliefert.\n7. Bei Erfolg wird eine Zeile mit Rechnungs-ID, ermittelter Rechnungsnummer, Download-Link und Ablaufdatum des Links geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceId` | int | Nein | Interner Rechnungsschlüssel (`InvoiceKey`). Optional, wenn `InvoiceNr` angegeben ist. Sind beide angegeben, müssen sie zur selben Rechnung gehören. |\n| `InvoiceNr` | varchar(20) | Nein | Rechnungsnummer. Wird getrimmt; ein leerer Wert gilt als nicht angegeben. Optional, wenn `InvoiceId` angegeben ist. |\n\n- Der Link wird von `pixi.DocumentPublicLink_Get` erzeugt. Deren Definition liegt nicht vor, daher ist aus diesem Code nicht ersichtlich:\n - das Format des Links,\n - die Gültigkeitsdauer,\n - ob Link-Datensätze in der Datenbank gespeichert werden.\n- Fehler werden als normale Zeile mit `Status` = `Error` und `Message` geliefert, nicht als SQL-Fehler ausgelöst. Der Rückgabewert der Prozedur ist 1 bei Fehler und 0 bei Erfolg.\n- Rechnungen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können sichtbar sein.\n- Die Suche verwendet `TOP (1)` ohne `ORDER BY`. Teilen sich mehrere Rechnungen dieselbe `InvoiceNr`, ist die gelieferte Rechnung bei Suche nur über die Nummer zufällig. Für ein eindeutiges Ergebnis `InvoiceId` angeben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoicePublicLink"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert einen öffentlichen Download-Link mit Ablaufdatum für das gespeicherte Dokument einer Rechnung, ermittelt über Rechnungs-ID und/oder Rechnungsnummer.\n\nErmittelt eine Rechnung und liefert einen öffentlichen Download-Link für das zugehörige gespeicherte Dokument.\n\n1. `InvoiceNr` wird getrimmt. Ein leerer Wert gilt als nicht angegeben.\n2. Mindestens einer der Parameter `InvoiceId` oder `InvoiceNr` muss angegeben sein, sonst wird eine Fehlerzeile geliefert.\n3. **Beide angegeben:** Die Rechnung muss sowohl `InvoiceKey = InvoiceId` als auch `InvoiceNr` erfüllen.\n - Passt keine Rechnung zu beiden Werten, existiert aber eine Rechnung mit der ID oder mit der Nummer, wird der Fehler `InvoiceId and InvoiceNr do not match.` geliefert.\n - Existiert keine von beiden, wird `Invoice Not Found.` geliefert.\n4. **Nur ein Wert angegeben:** Die Rechnung wird über diesen Wert gesucht. Wird keine gefunden, wird `Invoice Not Found.` geliefert.\n5. Ist der Rechnung kein Dokument zugeordnet (`DocumentStorageId` leer), wird `Document Not Found.` geliefert.\n6. Link und Ablaufdatum werden von der internen Prozedur `pixi.DocumentPublicLink_Get` erzeugt. Meldet diese einen Status ungleich 0, wird `Failed to generate invoice download link.` geliefert.\n7. Bei Erfolg wird eine Zeile mit Rechnungs-ID, ermittelter Rechnungsnummer, Download-Link und Ablaufdatum des Links geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceId` | int | Nein | Interner Rechnungsschlüssel (`InvoiceKey`). Optional, wenn `InvoiceNr` angegeben ist. Sind beide angegeben, müssen sie zur selben Rechnung gehören. |\n| `InvoiceNr` | varchar(20) | Nein | Rechnungsnummer. Wird getrimmt; ein leerer Wert gilt als nicht angegeben. Optional, wenn `InvoiceId` angegeben ist. |\n\n- Der Link wird von `pixi.DocumentPublicLink_Get` erzeugt. Deren Definition liegt nicht vor, daher ist aus diesem Code nicht ersichtlich:\n - das Format des Links,\n - die Gültigkeitsdauer,\n - ob Link-Datensätze in der Datenbank gespeichert werden.\n- Fehler werden als normale Zeile mit `Status` = `Error` und `Message` geliefert, nicht als SQL-Fehler ausgelöst. Der Rückgabewert der Prozedur ist 1 bei Fehler und 0 bei Erfolg.\n- Rechnungen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können sichtbar sein.\n- Die Suche verwendet `TOP (1)` ohne `ORDER BY`. Teilen sich mehrere Rechnungen dieselbe `InvoiceNr`, ist die gelieferte Rechnung bei Suche nur über die Nummer zufällig. Für ein eindeutiges Ergebnis `InvoiceId` angeben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoicePublicLink"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 104523\n RE2024-001234\n https://documents.example.com/public/3f2a9c1e-7b4d-4e8a-9f10-2c6d5e8b1a77\n 2024-06-15T14:30:00\n \n"
}
]
},
{
"name": "pixiGetInvoicesByOrderNr",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Rechnungen, die Positionen des angegebenen Auftrags enthalten, mit Zahlungs-, Bank-/Kreditkarten-, Versand- und Währungsdaten.\n\nErmittelt alle Rechnungen, die über ihre Rechnungspositionen mit dem Auftrag `OrderNr` verknüpft sind: Die Auftragspositionen des Auftrags werden mit den Rechnungspositionen (`OrderLineRef`) verbunden, und jede referenzierte Rechnung wird einmal geliefert.\n\nJe Rechnung werden geliefert:\n\n- **Rechnungsdaten**: Nummer, Datum, IDs von Zahlungs- und Lieferadresse, Gesamtbetrag.\n- **Zahlungsdaten**:\n - der Zahlungsartcode und dessen Text aus den Zahlungsarten. Fehlt ein Text, wird der Code selbst als Text geliefert.\n - Zahlungsdatum und bezahlte Summe.\n - ein berechnetes Kennzeichen `Paid`.\n- **Bank- und Kreditkartendaten** der Zahlungsadresse (`AddrRef`).\n- **Versanddaten**: Tracking-ID, Scan-Out-Datum als Versanddatum und die Mahnstufe.\n- **Auftragsdaten**: `OrderNr` sowie `OrderNrExternal` ohne führende und nachgestellte Leerzeichen.\n- **Währung**: der ISO-Code (`CodeA`) der Rechnungswährung.\n\n`Paid` ist `1`, wenn `PayedSum` (NULL als 0 gewertet) gleich `total` ist, sonst `0`.\n\nDas Ergebnis hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Pixi-Auftragsnummer, deren Rechnungen geliefert werden. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- Rechnungen werden nur geliefert, wenn die Zahlungsadresse in `Addresses` und die Währung in `Currency` existieren. Beides sind Inner Joins.\n- `Paid` ist auch bei überzahlten Rechnungen `0`, da auf Gleichheit geprüft wird und nicht auf 'bezahlte Summe ≥ Gesamtbetrag'.\n- Ist `total` NULL, ist `Paid` gleich `1`.\n- Tragen die Auftragspositionen unterschiedliche `OrderNrExternal`-Werte, wird für alle Rechnungen der Maximalwert geliefert.\n- Das Ergebnis enthält sensible Zahlungsdaten (Kontonummer, Kreditkartennummer); die Ausgabe ist entsprechend zu behandeln.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoicesByOrderNr"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Rechnungen, die Positionen des angegebenen Auftrags enthalten, mit Zahlungs-, Bank-/Kreditkarten-, Versand- und Währungsdaten.\n\nErmittelt alle Rechnungen, die über ihre Rechnungspositionen mit dem Auftrag `OrderNr` verknüpft sind: Die Auftragspositionen des Auftrags werden mit den Rechnungspositionen (`OrderLineRef`) verbunden, und jede referenzierte Rechnung wird einmal geliefert.\n\nJe Rechnung werden geliefert:\n\n- **Rechnungsdaten**: Nummer, Datum, IDs von Zahlungs- und Lieferadresse, Gesamtbetrag.\n- **Zahlungsdaten**:\n - der Zahlungsartcode und dessen Text aus den Zahlungsarten. Fehlt ein Text, wird der Code selbst als Text geliefert.\n - Zahlungsdatum und bezahlte Summe.\n - ein berechnetes Kennzeichen `Paid`.\n- **Bank- und Kreditkartendaten** der Zahlungsadresse (`AddrRef`).\n- **Versanddaten**: Tracking-ID, Scan-Out-Datum als Versanddatum und die Mahnstufe.\n- **Auftragsdaten**: `OrderNr` sowie `OrderNrExternal` ohne führende und nachgestellte Leerzeichen.\n- **Währung**: der ISO-Code (`CodeA`) der Rechnungswährung.\n\n`Paid` ist `1`, wenn `PayedSum` (NULL als 0 gewertet) gleich `total` ist, sonst `0`.\n\nDas Ergebnis hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Pixi-Auftragsnummer, deren Rechnungen geliefert werden. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- Rechnungen werden nur geliefert, wenn die Zahlungsadresse in `Addresses` und die Währung in `Currency` existieren. Beides sind Inner Joins.\n- `Paid` ist auch bei überzahlten Rechnungen `0`, da auf Gleichheit geprüft wird und nicht auf 'bezahlte Summe ≥ Gesamtbetrag'.\n- Ist `total` NULL, ist `Paid` gleich `1`.\n- Tragen die Auftragspositionen unterschiedliche `OrderNrExternal`-Werte, wird für alle Rechnungen der Maximalwert geliefert.\n- Das Ergebnis enthält sensible Zahlungsdaten (Kontonummer, Kreditkartennummer); die Ausgabe ist entsprechend zu behandeln.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoicesByOrderNr"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n R2024001234\n 2024-03-15T10:22:00\n 45821\n 45822\n 129.90\n PP\n PayPal\n 2024-03-15T10:25:00\n true\n 129.90\n 129.90\n \n \n \n \n \n \n \n \n 00340434161094042557\n 2024-03-15T16:40:00\n 0\n 123456\n SHOP-100045\n EUR\n \n"
}
]
},
{
"name": "pixiGetInvoicesForCustomer",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Rechnungen eines Kunden, identifiziert über Kundenschlüssel oder externe Kundennummer, optional gefiltert auf eine einzelne Rechnungsnummer.\n\nListet Rechnungen eines Kunden mit Zahlungs-, Bank- bzw. Karten-, Versand- und Auftragsinformationen auf.\n\n**Identifikation des Kunden**\n\n`NULL`-Werte werden zunächst durch `0` (bei `CustKey`) bzw. einen Leerstring ersetzt. Danach muss genau ein Merkmal gesetzt sein:\n\n- `CustKey` <> 0 und `CustomerNrExternal` leer: Die Rechnungen dieses Kundenschlüssels werden geliefert.\n- `CustKey` = 0 und `CustomerNrExternal` gesetzt: Alle Kunden in `Customers` mit dieser `CustomerNrExternal` werden verwendet. Teilen sich mehrere Kunden die Nummer, werden die Rechnungen aller dieser Kunden geliefert.\n- Beide gesetzt oder beide leer: Es wird kein Kunde ausgewählt und die Ergebnismenge ist leer.\n\n**Rechnungsfilter**\n\n- Ist `InvoiceNr` leer oder `NULL`, werden alle Rechnungen des Kunden geliefert.\n- Andernfalls wird nur die Rechnung mit genau dieser `InvoiceNr` geliefert.\n\n**Gelieferte Daten je Rechnung**\n\n- Rechnungsdaten aus `Invoices`: Nummer, Datum, IDs der Rechnungs- und Lieferadresse, Gesamtbetrag, Zahlungscode, Zahlungsdatum, bezahlter Betrag, Tracking-ID, Versanddatum und Mahnstufe.\n- `PaymentText` stammt aus `Payments`. Wird der Code dort nicht gefunden, wird der Zahlungscode selbst geliefert.\n- `Paid` ist `1`, wenn der bezahlte Betrag (ein fehlender Betrag zählt als 0) dem Gesamtbetrag entspricht, sonst `0`.\n- Karten- und Bankdaten (`Cc…`, `Account`, `Blz`, `BankName`, `AccountName`) stammen aus der Rechnungsadresse in `Addresses`.\n- `OrderNr` und `OrderNrExternal` sind die höchsten Werte unter den Auftragspositionen, die mit den Rechnungspositionen verknüpft sind. Sie sind `NULL`, wenn die Rechnung keine verknüpften Auftragspositionen hat.\n- `OrderCurrencyCode` ist der Währungscode aus `pixi.Currency`.\n\nDer Code legt keine Sortierung fest.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Nein | Interner Kundenschlüssel. Entweder dieses Merkmal oder `CustomerNrExternal` verwenden. 0 oder `NULL` bedeutet nicht gesetzt. |\n| `CustomerNrExternal` | varchar(60) | Nein | Externe Kundennummer, z. B. die Kundennummer des Shops. Wird nur verwendet, wenn `CustKey` 0 ist. Leer oder `NULL` bedeutet nicht gesetzt. |\n| `InvoiceNr` | varchar(20) | Nein | Optionale Rechnungsnummer. Ist sie gesetzt, wird nur diese Rechnung geliefert. Leer oder `NULL` liefert alle Rechnungen des Kunden. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten im Ergebnis erscheinen.\n- `pixi.Currency` wird per Inner Join verknüpft. Rechnungen, deren `CurrencyId` keine passende Währung hat, werden nicht geliefert.\n- Werden `CustKey` und `CustomerNrExternal` gleichzeitig übergeben, liefert der Aufruf keine Zeilen und keinen Fehler. Nur eines der beiden Merkmale übergeben.\n- Ist der Rechnungsbetrag `NULL`, trifft der Vergleich für `Paid` nicht zu und die Spalte liefert `1`.\n- Das Ergebnis enthält sensible Zahlungsdaten: Kartennummer, Karteninhaber, Ablaufdatum der Karte und Bankverbindung.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoicesForCustomer"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Rechnungen eines Kunden, identifiziert über Kundenschlüssel oder externe Kundennummer, optional gefiltert auf eine einzelne Rechnungsnummer.\n\nListet Rechnungen eines Kunden mit Zahlungs-, Bank- bzw. Karten-, Versand- und Auftragsinformationen auf.\n\n**Identifikation des Kunden**\n\n`NULL`-Werte werden zunächst durch `0` (bei `CustKey`) bzw. einen Leerstring ersetzt. Danach muss genau ein Merkmal gesetzt sein:\n\n- `CustKey` <> 0 und `CustomerNrExternal` leer: Die Rechnungen dieses Kundenschlüssels werden geliefert.\n- `CustKey` = 0 und `CustomerNrExternal` gesetzt: Alle Kunden in `Customers` mit dieser `CustomerNrExternal` werden verwendet. Teilen sich mehrere Kunden die Nummer, werden die Rechnungen aller dieser Kunden geliefert.\n- Beide gesetzt oder beide leer: Es wird kein Kunde ausgewählt und die Ergebnismenge ist leer.\n\n**Rechnungsfilter**\n\n- Ist `InvoiceNr` leer oder `NULL`, werden alle Rechnungen des Kunden geliefert.\n- Andernfalls wird nur die Rechnung mit genau dieser `InvoiceNr` geliefert.\n\n**Gelieferte Daten je Rechnung**\n\n- Rechnungsdaten aus `Invoices`: Nummer, Datum, IDs der Rechnungs- und Lieferadresse, Gesamtbetrag, Zahlungscode, Zahlungsdatum, bezahlter Betrag, Tracking-ID, Versanddatum und Mahnstufe.\n- `PaymentText` stammt aus `Payments`. Wird der Code dort nicht gefunden, wird der Zahlungscode selbst geliefert.\n- `Paid` ist `1`, wenn der bezahlte Betrag (ein fehlender Betrag zählt als 0) dem Gesamtbetrag entspricht, sonst `0`.\n- Karten- und Bankdaten (`Cc…`, `Account`, `Blz`, `BankName`, `AccountName`) stammen aus der Rechnungsadresse in `Addresses`.\n- `OrderNr` und `OrderNrExternal` sind die höchsten Werte unter den Auftragspositionen, die mit den Rechnungspositionen verknüpft sind. Sie sind `NULL`, wenn die Rechnung keine verknüpften Auftragspositionen hat.\n- `OrderCurrencyCode` ist der Währungscode aus `pixi.Currency`.\n\nDer Code legt keine Sortierung fest.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Nein | Interner Kundenschlüssel. Entweder dieses Merkmal oder `CustomerNrExternal` verwenden. 0 oder `NULL` bedeutet nicht gesetzt. |\n| `CustomerNrExternal` | varchar(60) | Nein | Externe Kundennummer, z. B. die Kundennummer des Shops. Wird nur verwendet, wenn `CustKey` 0 ist. Leer oder `NULL` bedeutet nicht gesetzt. |\n| `InvoiceNr` | varchar(20) | Nein | Optionale Rechnungsnummer. Ist sie gesetzt, wird nur diese Rechnung geliefert. Leer oder `NULL` liefert alle Rechnungen des Kunden. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten im Ergebnis erscheinen.\n- `pixi.Currency` wird per Inner Join verknüpft. Rechnungen, deren `CurrencyId` keine passende Währung hat, werden nicht geliefert.\n- Werden `CustKey` und `CustomerNrExternal` gleichzeitig übergeben, liefert der Aufruf keine Zeilen und keinen Fehler. Nur eines der beiden Merkmale übergeben.\n- Ist der Rechnungsbetrag `NULL`, trifft der Vergleich für `Paid` nicht zu und die Spalte liefert `1`.\n- Das Ergebnis enthält sensible Zahlungsdaten: Kartennummer, Karteninhaber, Ablaufdatum der Karte und Bankverbindung.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoicesForCustomer"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n RE2024001234\n 2024-03-12T10:15:00\n 88231\n 88232\n 129.90\n VK\n Vorkasse\n 2024-03-14T00:00:00\n true\n 129.90\n 129.90\n 00340434161234567890\n 2024-03-15T08:42:00\n 0\n 502311\n SHOP-77812\n EUR\n \n"
}
]
},
{
"name": "pixiGetInvoiceShippingInformation",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE2024001234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert versandrelevante Informationen zu einer Rechnung: Zahlungsart, Versender, Beträge, Lieferadresse mit Länderdaten, Auftragsdaten und Paketgewichte.\n\nSucht die Rechnung mit der übergebenen `InvoiceNr` und liefert eine Zeile mit den Daten, die ein Versand- oder Etikettentool typischerweise benötigt.\n\nDie Zeile setzt sich wie folgt zusammen:\n- **Rechnung**: Nummer, Datum, Shop, Zahlungsartcode, Versendercode, Gesamtbetrag und Versandkosten aus `Invoices`.\n- **Währung**: Währungscode (`CodeA`) der Rechnungswährung. Die Verknüpfung ist ein Inner Join; eine Rechnung ohne passenden Währungsdatensatz liefert keine Zeile.\n- **Zahlungsart und Versender**: Text der Zahlungsart und Name des Versenders (optional, ggf. leer).\n- **Lieferadresse**: die Adresse aus der Lieferadressreferenz der Rechnung (`ShipAdrRef`) mit Namensbestandteilen, Straße, Hausnummer, Ort, PLZ, Postfach, Telefon, E-Mail und USt-IdNr.\n- **Land**: Ländername, EasyLog-Ländername sowie ISO2-/ISO3-Code des Adresslandes.\n- **Auftrag**: Der zugehörige Auftrag wird über die Rechnungspositionen ermittelt: Die erste gefundene Rechnungsposition verweist auf eine Auftragsposition, deren Auftrag verwendet wird. Daraus werden Adressbemerkungen, DHL-Verfahren/-Produkt/-Extras, Geschenknachricht, Versanddatum, Shop-Notiz, Auftragsnummer und externe Auftragsnummer geliefert.\n- **Gewichte**: Netto- und Bruttopaketgewicht, auf 3 Nachkommastellen gerundet.\n\nExistiert keine Rechnung mit dieser Nummer, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(50) | Ja | Nummer der Rechnung (`Invoices.InvoiceNr`), zu der die Versandinformationen geliefert werden. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; es können nicht festgeschriebene Daten geliefert werden.\n- Der Auftrag wird über `TOP 1`-Unterabfragen ohne `ORDER BY` ermittelt. Enthält eine Rechnung Positionen aus mehreren Aufträgen, wird nur einer davon verwendet, und welcher, ist nicht deterministisch.\n- `Total_OrderCurr` entspricht immer `Total` und `ShipCost_OrderCurr` immer `ShipCost`; Kommentare im Code markieren diese Spalten zur Entfernung, daher sollte man sich nicht auf sie verlassen.\n- `PackageNetWeight` und `PackageGrossWeight` werden ohne Tabellenalias referenziert; aus dem Code ist nicht ersichtlich, ob sie aus `Invoices` oder `OrderHeader` stammen.\n- Es werden keine Fehlerzeilen geliefert; eine unbekannte Rechnungsnummer ergibt einfach keine Zeilen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoiceShippingInformation"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE2024001234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert versandrelevante Informationen zu einer Rechnung: Zahlungsart, Versender, Beträge, Lieferadresse mit Länderdaten, Auftragsdaten und Paketgewichte.\n\nSucht die Rechnung mit der übergebenen `InvoiceNr` und liefert eine Zeile mit den Daten, die ein Versand- oder Etikettentool typischerweise benötigt.\n\nDie Zeile setzt sich wie folgt zusammen:\n- **Rechnung**: Nummer, Datum, Shop, Zahlungsartcode, Versendercode, Gesamtbetrag und Versandkosten aus `Invoices`.\n- **Währung**: Währungscode (`CodeA`) der Rechnungswährung. Die Verknüpfung ist ein Inner Join; eine Rechnung ohne passenden Währungsdatensatz liefert keine Zeile.\n- **Zahlungsart und Versender**: Text der Zahlungsart und Name des Versenders (optional, ggf. leer).\n- **Lieferadresse**: die Adresse aus der Lieferadressreferenz der Rechnung (`ShipAdrRef`) mit Namensbestandteilen, Straße, Hausnummer, Ort, PLZ, Postfach, Telefon, E-Mail und USt-IdNr.\n- **Land**: Ländername, EasyLog-Ländername sowie ISO2-/ISO3-Code des Adresslandes.\n- **Auftrag**: Der zugehörige Auftrag wird über die Rechnungspositionen ermittelt: Die erste gefundene Rechnungsposition verweist auf eine Auftragsposition, deren Auftrag verwendet wird. Daraus werden Adressbemerkungen, DHL-Verfahren/-Produkt/-Extras, Geschenknachricht, Versanddatum, Shop-Notiz, Auftragsnummer und externe Auftragsnummer geliefert.\n- **Gewichte**: Netto- und Bruttopaketgewicht, auf 3 Nachkommastellen gerundet.\n\nExistiert keine Rechnung mit dieser Nummer, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(50) | Ja | Nummer der Rechnung (`Invoices.InvoiceNr`), zu der die Versandinformationen geliefert werden. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; es können nicht festgeschriebene Daten geliefert werden.\n- Der Auftrag wird über `TOP 1`-Unterabfragen ohne `ORDER BY` ermittelt. Enthält eine Rechnung Positionen aus mehreren Aufträgen, wird nur einer davon verwendet, und welcher, ist nicht deterministisch.\n- `Total_OrderCurr` entspricht immer `Total` und `ShipCost_OrderCurr` immer `ShipCost`; Kommentare im Code markieren diese Spalten zur Entfernung, daher sollte man sich nicht auf sie verlassen.\n- `PackageNetWeight` und `PackageGrossWeight` werden ohne Tabellenalias referenziert; aus dem Code ist nicht ersichtlich, ob sie aus `Invoices` oder `OrderHeader` stammen.\n- Es werden keine Fehlerzeilen geliefert; eine unbekannte Rechnungsnummer ergibt einfach keine Zeilen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoiceShippingInformation"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n RE2024001234\n 2024-03-15T10:22:00\n SHOP1\n VK\n Vorkasse\n DHL\n DHL Paket\n 59.90\n EUR\n 59.90\n 4.90\n 4.90\n Frau\n Anna Schmidt\n Anna\n Schmidt\n Hauptstraße\n 12\n München\n 80331\n D\n Deutschland\n DEUTSCHLAND\n DE\n DEU\n anna.schmidt@example.com\n 456789\n 100012345\n 1.250\n 1.480\n \n"
}
]
},
{
"name": "pixiGetInvoiceShippingReport",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Rechnungen eines Zeitraums mit DATEV-Kontonummer des Kunden und Lieferadresse, optional gefiltert nach Shop.\n\nListet Rechnungen zusammen mit der DATEV-Kontonummer des Kunden und der Lieferadresse der Rechnung auf. Laut Kopfkommentar wurde der Aufruf für einen bestimmten Kunden (\"Customer LLL\") erstellt.\n\nAblauf:\n\n1. Eine leere `ShopID` wird wie `NULL` behandelt und bedeutet damit alle Shops.\n2. Ohne `DateFrom` wird der Tagesbeginn (00:00:00) vor 30 Tagen verwendet.\n3. Ohne `DateTo` wird das Ende des aktuellen Tages (23:59:59.997) verwendet.\n4. Die Rechnungen stammen aus der Sicht bzw. Tabelle `PV_Rechnungen`. Zurückgegeben werden nur Rechnungen mit `Rechnungsdatum >= DateFrom` und `Rechnungsdatum < DateTo`. Die Obergrenze ist **exklusiv**.\n5. Jede Rechnung wird über die Rechnungsnummer mit `Invoices` verknüpft. Von dort werden der Kunde (`Customers`, für die DATEV-Kontonummer) und die Lieferadresse (`Addresses` über `ShipAdrRef`) gelesen. Der Ländername stammt aus `Countries`.\n6. Ist `ShopID` gesetzt, werden nur Rechnungen mit passender `InvShopID` geliefert.\n\nDas Ergebnis hat keine definierte Sortierung und kein Paging.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | Nein | Shop-ID als Filter (`InvShopID` der Rechnung). `NULL` oder leer liefert Rechnungen aller Shops. |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (inklusive), verglichen mit dem Rechnungsdatum. Bei `NULL` wird der Tagesbeginn vor 30 Tagen verwendet. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (exklusiv), verglichen mit dem Rechnungsdatum. Bei `NULL` wird das Ende des aktuellen Tages (23:59:59.997) verwendet. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen. Das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- `DateTo` wird mit `<` verglichen. Bei einem reinen Datum wie `2024-03-31T00:00:00` sind Rechnungen dieses Tages **nicht** enthalten. Um sie einzuschließen, den Folgetag oder eine Uhrzeit am Tagesende übergeben.\n- Die Verknüpfungen sind `LEFT JOIN`s. Ohne Shop-Filter werden auch Rechnungen ohne passenden Eintrag in `Invoices`, `Customers`, `Addresses` oder `Countries` geliefert, mit `NULL` in den fehlenden Spalten. Mit Shop-Filter fallen Rechnungen ohne passende `Invoices`-Zeile weg.\n- `Firma` wird aus dem Feld `CareOf` der Adresse befüllt.\n- `PV_Rechnungen` liegt nicht vor. Ob es sich um eine Sicht handelt und wie sie die Rechnungen auswählt, ist aus dem Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoiceShippingReport"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Rechnungen eines Zeitraums mit DATEV-Kontonummer des Kunden und Lieferadresse, optional gefiltert nach Shop.\n\nListet Rechnungen zusammen mit der DATEV-Kontonummer des Kunden und der Lieferadresse der Rechnung auf. Laut Kopfkommentar wurde der Aufruf für einen bestimmten Kunden (\"Customer LLL\") erstellt.\n\nAblauf:\n\n1. Eine leere `ShopID` wird wie `NULL` behandelt und bedeutet damit alle Shops.\n2. Ohne `DateFrom` wird der Tagesbeginn (00:00:00) vor 30 Tagen verwendet.\n3. Ohne `DateTo` wird das Ende des aktuellen Tages (23:59:59.997) verwendet.\n4. Die Rechnungen stammen aus der Sicht bzw. Tabelle `PV_Rechnungen`. Zurückgegeben werden nur Rechnungen mit `Rechnungsdatum >= DateFrom` und `Rechnungsdatum < DateTo`. Die Obergrenze ist **exklusiv**.\n5. Jede Rechnung wird über die Rechnungsnummer mit `Invoices` verknüpft. Von dort werden der Kunde (`Customers`, für die DATEV-Kontonummer) und die Lieferadresse (`Addresses` über `ShipAdrRef`) gelesen. Der Ländername stammt aus `Countries`.\n6. Ist `ShopID` gesetzt, werden nur Rechnungen mit passender `InvShopID` geliefert.\n\nDas Ergebnis hat keine definierte Sortierung und kein Paging.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | Nein | Shop-ID als Filter (`InvShopID` der Rechnung). `NULL` oder leer liefert Rechnungen aller Shops. |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (inklusive), verglichen mit dem Rechnungsdatum. Bei `NULL` wird der Tagesbeginn vor 30 Tagen verwendet. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (exklusiv), verglichen mit dem Rechnungsdatum. Bei `NULL` wird das Ende des aktuellen Tages (23:59:59.997) verwendet. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen. Das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- `DateTo` wird mit `<` verglichen. Bei einem reinen Datum wie `2024-03-31T00:00:00` sind Rechnungen dieses Tages **nicht** enthalten. Um sie einzuschließen, den Folgetag oder eine Uhrzeit am Tagesende übergeben.\n- Die Verknüpfungen sind `LEFT JOIN`s. Ohne Shop-Filter werden auch Rechnungen ohne passenden Eintrag in `Invoices`, `Customers`, `Addresses` oder `Countries` geliefert, mit `NULL` in den fehlenden Spalten. Mit Shop-Filter fallen Rechnungen ohne passende `Invoices`-Zeile weg.\n- `Firma` wird aus dem Feld `CareOf` der Adresse befüllt.\n- `PV_Rechnungen` liegt nicht vor. Ob es sich um eine Sicht handelt und wie sie die Rechnungen auswählt, ist aus dem Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoiceShippingReport"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10045\n RE2024001234\n Anna\n Müller\n Müller GmbH\n Hauptstraße 12\n 80331\n München\n Deutschland\n anna.mueller@example.com\n \n"
}
]
},
{
"name": "pixiGetInvoicesUnpaid",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle unbezahlten Rechnungen oder mit `PaidInvoices` = 1 alle bezahlten Rechnungen mit Zahlungs-, Bank-, Adress- und Währungsdaten, sortiert nach Rechnungsdatum.\n\nLiest Rechnungen aus `Invoices` zusammen mit dem Kunden, der Zahlungsart, der Rechnungsadresse, deren Land und der Rechnungswährung.\n\nDer Parameter `PaidInvoices` wählt einen von zwei Modi:\n\n- `0` (Standard): **unbezahlte Rechnungen**. Eine Rechnung wird geliefert, wenn die bezahlte Summe (`PayedSum`, NULL zählt als 0) nicht exakt dem auf 2 Nachkommastellen gerundeten Rechnungsbetrag entspricht **und** in `CustomerAccount` kein Eintrag für diesen Kunden und diese Rechnung mit `DoNotRefund = 1` ohne Bankzeilen-, DTAUS- oder manuelle Buchungsreferenz existiert.\n- `1`: **bezahlte Rechnungen**. Eine Rechnung wird geliefert, wenn die bezahlte Summe um weniger als 0,01 vom gerundeten Rechnungsbetrag abweicht **oder** ein solcher `DoNotRefund`-Eintrag in `CustomerAccount` existiert.\n\nEs werden nur Rechnungen geliefert, zu denen Währung, Kunde, Zahlungsart (`Payments.Code` = Zahlungscode der Rechnung) und Rechnungsadresse existieren (Inner Joins). Das Land ist optional.\n\nDie Sortierung erfolgt aufsteigend nach Rechnungsdatum. Es gibt kein Paging; alle passenden Rechnungen werden geliefert.\n\nSpaltenlogik:\n- `Paid` ist nur 1, wenn die bezahlte Summe exakt dem gerundeten Rechnungsbetrag entspricht, sonst 0.\n- `PaymentDate` ist das Zahlungsdatum der Rechnung, wenn `Paid` = 1, sonst NULL.\n- `PaymentText` ist der Text der Zahlungsart, ersatzweise der Zahlungscode.\n- `Currency` und `OrderCurrency` enthalten beide den Währungscode der Rechnung; `total`, `TotalToPay` und `TotalToPay_OrderCurr` enthalten alle den Rechnungsbetrag.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PaidInvoices` | bit | Nein | Wählt den Modus: 0 liefert unbezahlte Rechnungen, 1 liefert bezahlte Rechnungen. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Im Modus `1` verwendet der Filter eine Toleranz von 0,01, `Paid` und `PaymentDate` jedoch einen exakten Vergleich. Rechnungen mit minimaler Differenz oder Rechnungen, die nur wegen eines `DoNotRefund`-Eintrags geliefert werden, erscheinen daher mit `Paid` = 0 und `PaymentDate` = NULL.\n- Wird NULL für `PaidInvoices` übergeben, werden keine Zeilen geliefert.\n- Rechnungen, deren Zahlungscode keinen Eintrag in `Payments` hat oder deren Kunde, Adresse oder Währung fehlt, werden ohne Hinweis ausgeschlossen.\n- Das Ergebnis enthält sensible Zahlungsdaten (Kreditkartennummer, -inhaber und -ablauf, Bankkonto, BLZ).\n- Ohne Paging kann das Ergebnis bei vielen Rechnungen sehr groß werden.\n- Laut Code-Kommentar ist die Währungslogik (`Currency` = Rechnungswährung) vorläufig, bis Mehrwährung vollständig unterstützt wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoicesUnpaid"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle unbezahlten Rechnungen oder mit `PaidInvoices` = 1 alle bezahlten Rechnungen mit Zahlungs-, Bank-, Adress- und Währungsdaten, sortiert nach Rechnungsdatum.\n\nLiest Rechnungen aus `Invoices` zusammen mit dem Kunden, der Zahlungsart, der Rechnungsadresse, deren Land und der Rechnungswährung.\n\nDer Parameter `PaidInvoices` wählt einen von zwei Modi:\n\n- `0` (Standard): **unbezahlte Rechnungen**. Eine Rechnung wird geliefert, wenn die bezahlte Summe (`PayedSum`, NULL zählt als 0) nicht exakt dem auf 2 Nachkommastellen gerundeten Rechnungsbetrag entspricht **und** in `CustomerAccount` kein Eintrag für diesen Kunden und diese Rechnung mit `DoNotRefund = 1` ohne Bankzeilen-, DTAUS- oder manuelle Buchungsreferenz existiert.\n- `1`: **bezahlte Rechnungen**. Eine Rechnung wird geliefert, wenn die bezahlte Summe um weniger als 0,01 vom gerundeten Rechnungsbetrag abweicht **oder** ein solcher `DoNotRefund`-Eintrag in `CustomerAccount` existiert.\n\nEs werden nur Rechnungen geliefert, zu denen Währung, Kunde, Zahlungsart (`Payments.Code` = Zahlungscode der Rechnung) und Rechnungsadresse existieren (Inner Joins). Das Land ist optional.\n\nDie Sortierung erfolgt aufsteigend nach Rechnungsdatum. Es gibt kein Paging; alle passenden Rechnungen werden geliefert.\n\nSpaltenlogik:\n- `Paid` ist nur 1, wenn die bezahlte Summe exakt dem gerundeten Rechnungsbetrag entspricht, sonst 0.\n- `PaymentDate` ist das Zahlungsdatum der Rechnung, wenn `Paid` = 1, sonst NULL.\n- `PaymentText` ist der Text der Zahlungsart, ersatzweise der Zahlungscode.\n- `Currency` und `OrderCurrency` enthalten beide den Währungscode der Rechnung; `total`, `TotalToPay` und `TotalToPay_OrderCurr` enthalten alle den Rechnungsbetrag.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PaidInvoices` | bit | Nein | Wählt den Modus: 0 liefert unbezahlte Rechnungen, 1 liefert bezahlte Rechnungen. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Im Modus `1` verwendet der Filter eine Toleranz von 0,01, `Paid` und `PaymentDate` jedoch einen exakten Vergleich. Rechnungen mit minimaler Differenz oder Rechnungen, die nur wegen eines `DoNotRefund`-Eintrags geliefert werden, erscheinen daher mit `Paid` = 0 und `PaymentDate` = NULL.\n- Wird NULL für `PaidInvoices` übergeben, werden keine Zeilen geliefert.\n- Rechnungen, deren Zahlungscode keinen Eintrag in `Payments` hat oder deren Kunde, Adresse oder Währung fehlt, werden ohne Hinweis ausgeschlossen.\n- Das Ergebnis enthält sensible Zahlungsdaten (Kreditkartennummer, -inhaber und -ablauf, Bankkonto, BLZ).\n- Ohne Paging kann das Ergebnis bei vielen Rechnungen sehr groß werden.\n- Laut Code-Kommentar ist die Währungslogik (`Currency` = Rechnungswährung) vorläufig, bis Mehrwährung vollständig unterstützt wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoicesUnpaid"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n RE100234\n 2024-03-04T10:15:00\n SHOP1\n 55012\n 55013\n 20871\n 89.90\n RE\n Rechnung\n false\n 89.90\n 0.00\n 00340434161234567890\n 2024-03-04T15:42:00\n 2024-03-04T15:42:00\n 0\n DHL\n EUR\n EUR\n 89.90\n 100234\n K-4711\n 80331\n München\n DEU\n Max Mustermann\n Max\n Mustermann\n Marienplatz\n 1\n 2024-03-18T00:00:00\n 10871\n \n"
}
]
},
{
"name": "pixiGetPaidInvoices",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T00:00:00\n 2024-05-31T23:59:59\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungen, die über Ausgleiche im Kundenkonto vollständig bezahlt sind und deren Zahlung im angegebenen Zeitraum gebucht wurde.\n\nErmittelt Rechnungen, die im Kundenkonto (`CustomerAccount`) ausgeglichen wurden, und liefert eine Zeile je Rechnungsbuchung.\n\nAblauf:\n\n1. Es werden alle Kundenkontobuchungen mit `EventDate` zwischen `@From` und `@To` (inklusive, `BETWEEN`) und `Amount > 0` ermittelt. Das sind in der Regel die Zahlungsbuchungen.\n2. Über `CustomerAccountMatch` werden alle Kundenkontobuchungen gesucht, die mit diesen Buchungen ausgeglichen wurden, in beide Richtungen (`CARef1` ↔ `CARef2`).\n3. Berücksichtigt werden nur ausgeglichene Buchungen mit Bezug zu einer Rechnung (`InvoiceRef IS NOT NULL`).\n4. Berücksichtigt werden nur vollständig ausgeglichene Buchungen: Die Summe von `AbsoluteMatchAmount` über alle Ausgleiche der Buchung plus der eigene `Amount` der Buchung muss genau `0` ergeben.\n\nFür jede verbleibende Buchung werden geliefert:\n\n- Rechnungsschlüssel und Rechnungsnummer aus `Invoices`,\n- `DatePaid`: das späteste `EventDate` aller mit der Rechnungsbuchung ausgeglichenen Kundenkontobuchungen (nicht auf den Zeitraum beschränkt),\n- `ShopID`: der Shop des Kunden (`Customers.CustomerOf`),\n- `OrderNRExternal`: die höchste externe Auftragsnummer der über `Invlines` mit der Rechnung verknüpften Auftragspositionen,\n- `PaymentType`: die Zahlungsart der Rechnung.\n\nEine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `From` | datetime | Ja | Beginn des Zeitraums (inklusive) für das Buchungsdatum (`EventDate`) der Zahlungsbuchungen. |\n| `To` | datetime | Ja | Ende des Zeitraums (inklusive) für das Buchungsdatum (`EventDate`) der Zahlungsbuchungen. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- `BETWEEN` schließt beide Grenzen ein. Wird `@To` als Datum ohne Uhrzeit (Mitternacht) übergeben, fehlen spätere Zahlungen dieses Tages.\n- Die Prüfung auf vollständigen Ausgleich vergleicht exakt mit `0`; Rundungsdifferenzen in den Ausgleichen schließen eine Rechnung aus.\n- Hat eine Rechnung mehrere Kundenkontobuchungen, die jeweils die Bedingungen erfüllen, kann die Rechnung mehrfach erscheinen.\n- `DatePaid` ist das späteste Datum aller ausgeglichenen Buchungen und kann außerhalb von `@From`/`@To` liegen.\n- In der Ausgleichsprüfung sind die Spalten `Amount` und `CustomerAccountKey` nicht qualifiziert; der Code verlässt sich darauf, dass sie auf die äußere `CustomerAccount`-Buchung verweisen.\n- Der Kopfkommentar der Prozedur (\"Checks pixi* user credentials\") passt nicht zur Funktion und ist offenbar ein Kopierrest.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPaidInvoices"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T00:00:00\n 2024-05-31T23:59:59\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungen, die über Ausgleiche im Kundenkonto vollständig bezahlt sind und deren Zahlung im angegebenen Zeitraum gebucht wurde.\n\nErmittelt Rechnungen, die im Kundenkonto (`CustomerAccount`) ausgeglichen wurden, und liefert eine Zeile je Rechnungsbuchung.\n\nAblauf:\n\n1. Es werden alle Kundenkontobuchungen mit `EventDate` zwischen `@From` und `@To` (inklusive, `BETWEEN`) und `Amount > 0` ermittelt. Das sind in der Regel die Zahlungsbuchungen.\n2. Über `CustomerAccountMatch` werden alle Kundenkontobuchungen gesucht, die mit diesen Buchungen ausgeglichen wurden, in beide Richtungen (`CARef1` ↔ `CARef2`).\n3. Berücksichtigt werden nur ausgeglichene Buchungen mit Bezug zu einer Rechnung (`InvoiceRef IS NOT NULL`).\n4. Berücksichtigt werden nur vollständig ausgeglichene Buchungen: Die Summe von `AbsoluteMatchAmount` über alle Ausgleiche der Buchung plus der eigene `Amount` der Buchung muss genau `0` ergeben.\n\nFür jede verbleibende Buchung werden geliefert:\n\n- Rechnungsschlüssel und Rechnungsnummer aus `Invoices`,\n- `DatePaid`: das späteste `EventDate` aller mit der Rechnungsbuchung ausgeglichenen Kundenkontobuchungen (nicht auf den Zeitraum beschränkt),\n- `ShopID`: der Shop des Kunden (`Customers.CustomerOf`),\n- `OrderNRExternal`: die höchste externe Auftragsnummer der über `Invlines` mit der Rechnung verknüpften Auftragspositionen,\n- `PaymentType`: die Zahlungsart der Rechnung.\n\nEine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `From` | datetime | Ja | Beginn des Zeitraums (inklusive) für das Buchungsdatum (`EventDate`) der Zahlungsbuchungen. |\n| `To` | datetime | Ja | Ende des Zeitraums (inklusive) für das Buchungsdatum (`EventDate`) der Zahlungsbuchungen. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- `BETWEEN` schließt beide Grenzen ein. Wird `@To` als Datum ohne Uhrzeit (Mitternacht) übergeben, fehlen spätere Zahlungen dieses Tages.\n- Die Prüfung auf vollständigen Ausgleich vergleicht exakt mit `0`; Rundungsdifferenzen in den Ausgleichen schließen eine Rechnung aus.\n- Hat eine Rechnung mehrere Kundenkontobuchungen, die jeweils die Bedingungen erfüllen, kann die Rechnung mehrfach erscheinen.\n- `DatePaid` ist das späteste Datum aller ausgeglichenen Buchungen und kann außerhalb von `@From`/`@To` liegen.\n- In der Ausgleichsprüfung sind die Spalten `Amount` und `CustomerAccountKey` nicht qualifiziert; der Code verlässt sich darauf, dass sie auf die äußere `CustomerAccount`-Buchung verweisen.\n- Der Kopfkommentar der Prozedur (\"Checks pixi* user credentials\") passt nicht zur Funktion und ist offenbar ein Kopierrest.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPaidInvoices"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 48213\n 2024100512\n 2024-05-14T10:32:00\n ABC\n 100045678\n VORKASSE\n \n \n 48250\n 2024100549\n 2024-05-20T08:15:00\n ABC\n 100045702\n RECHNUNG\n \n"
}
]
},
{
"name": "pixiGetPosInvoiceLines",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n POS-100023\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Positionen einer POS-Rechnung (Kassenbeleg) mit Artikelnummer, EAN, Bezeichnung, Menge, Preisen und Rabatt zu einer Belegnummer.\n\nLiefert alle Positionen des POS-Belegs, dessen Belegnummer (`POSheader2.PHdocNr`) mit `InvoiceNr` übereinstimmt.\n\n1. Zuerst wird die gemeinsame API-Hülle `Pixi_ApiEnvelope` ausgeführt. Sie prüft die Aufrufhäufigkeit dieser Funktion und protokolliert den Zeitpunkt des Aufrufs.\n2. Liefert die Hülle den Ergebniscode `200`, werden die POS-Positionen (`POSitem2`) des passenden POS-Kopfs (`POSheader2`) gelesen. Jede Position wird per Inner Join mit ihrem Artikel (`items`) verknüpft.\n3. Jede Zeile enthält die interne Artikelnummer, die EAN, die Artikelbezeichnung, die Menge, Belegdatum und Belegnummer sowie die Preisfelder der Position. Ein fehlender Rabatt wird als `0.0` geliefert.\n\nDie Belegnummer wird exakt verglichen. Der Code legt keine Sortierung fest, die Reihenfolge der Positionen ist daher nicht garantiert. Gibt es keinen passenden POS-Beleg, wird eine leere Ergebnismenge geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Ja | Belegnummer der POS-Rechnung (`POSheader2.PHdocNr`). Exakter Vergleich. |\n| `ResultCode` | char(3) | Nein | Ergebniscode der API-Hülle: `200` bei Erfolg, `502` bei Überschreitung der Aufrufhäufigkeit. |\n| `ResultText` | varchar(1024) | Nein | Ergebnistext der API-Hülle, z. B. `OK` oder die Meldung zur Aufrufbegrenzung. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`. Es können nicht festgeschriebene Daten geliefert werden.\n- Positionen, deren Artikel in `items` nicht mehr existiert, werden nicht geliefert, da der Artikel per Inner Join verknüpft wird.\n- `ItemPrice_Netto` wird als `PIendPrice - PIvatInPrice` berechnet, also als Positionsendpreis abzüglich der darin enthaltenen MwSt.\n- `ItemPrice_Brutto` stammt direkt aus `PIprice`. Aus dem Code geht nicht hervor, ob es sich um einen Einzel- oder Positionspreis handelt.\n- `Pixi_ApiEnvelope` schreibt den Aufrufzeitpunkt in `API_STATISTICS`. Ist in `API_CONTROL` ein Mindestabstand konfiguriert und liegt der letzte Aufruf zu kurz zurück, liefert die Hülle statt der Rechnungspositionen eine Zeile mit `ResultCode`/`ResultText` und dem Code `502`.\n- Die Ausgabeparameter `ResultCode` und `ResultText` enthalten das Ergebnis der Hülle (`200`/`OK` bei Erfolg).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPosInvoiceLines"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n POS-100023\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Positionen einer POS-Rechnung (Kassenbeleg) mit Artikelnummer, EAN, Bezeichnung, Menge, Preisen und Rabatt zu einer Belegnummer.\n\nLiefert alle Positionen des POS-Belegs, dessen Belegnummer (`POSheader2.PHdocNr`) mit `InvoiceNr` übereinstimmt.\n\n1. Zuerst wird die gemeinsame API-Hülle `Pixi_ApiEnvelope` ausgeführt. Sie prüft die Aufrufhäufigkeit dieser Funktion und protokolliert den Zeitpunkt des Aufrufs.\n2. Liefert die Hülle den Ergebniscode `200`, werden die POS-Positionen (`POSitem2`) des passenden POS-Kopfs (`POSheader2`) gelesen. Jede Position wird per Inner Join mit ihrem Artikel (`items`) verknüpft.\n3. Jede Zeile enthält die interne Artikelnummer, die EAN, die Artikelbezeichnung, die Menge, Belegdatum und Belegnummer sowie die Preisfelder der Position. Ein fehlender Rabatt wird als `0.0` geliefert.\n\nDie Belegnummer wird exakt verglichen. Der Code legt keine Sortierung fest, die Reihenfolge der Positionen ist daher nicht garantiert. Gibt es keinen passenden POS-Beleg, wird eine leere Ergebnismenge geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Ja | Belegnummer der POS-Rechnung (`POSheader2.PHdocNr`). Exakter Vergleich. |\n| `ResultCode` | char(3) | Nein | Ergebniscode der API-Hülle: `200` bei Erfolg, `502` bei Überschreitung der Aufrufhäufigkeit. |\n| `ResultText` | varchar(1024) | Nein | Ergebnistext der API-Hülle, z. B. `OK` oder die Meldung zur Aufrufbegrenzung. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`. Es können nicht festgeschriebene Daten geliefert werden.\n- Positionen, deren Artikel in `items` nicht mehr existiert, werden nicht geliefert, da der Artikel per Inner Join verknüpft wird.\n- `ItemPrice_Netto` wird als `PIendPrice - PIvatInPrice` berechnet, also als Positionsendpreis abzüglich der darin enthaltenen MwSt.\n- `ItemPrice_Brutto` stammt direkt aus `PIprice`. Aus dem Code geht nicht hervor, ob es sich um einen Einzel- oder Positionspreis handelt.\n- `Pixi_ApiEnvelope` schreibt den Aufrufzeitpunkt in `API_STATISTICS`. Ist in `API_CONTROL` ein Mindestabstand konfiguriert und liegt der letzte Aufruf zu kurz zurück, liefert die Hülle statt der Rechnungspositionen eine Zeile mit `ResultCode`/`ResultText` und dem Code `502`.\n- Die Ausgabeparameter `ResultCode` und `ResultText` enthalten das Ergebnis der Hülle (`200`/`OK` bei Erfolg).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPosInvoiceLines"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 100245\n 4006381333931\n Kugelschreiber blau\n 2\n 2024-03-15T14:32:00\n POS-100023\n 2.38\n 4.00\n 0.0\n 4.76\n \n"
}
]
},
{
"name": "pixiGetReminders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 1\n R\n SHP\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert unbezahlte Rechnungen einer Zahlungsart, die für die angegebene Mahnstufe fällig sind, inklusive Adress- und Shopdaten.\n\nListet offene Rechnungen auf, die für die nächste Zahlungserinnerung bzw. Mahnung in Frage kommen. Der Aufruf delegiert an die interne Prozedur `pixi_GetReminders`.\n\nEine Rechnung wird geliefert, wenn alle folgenden Bedingungen erfüllt sind:\n\n- `Invoices.Payed` ist NULL (nicht bezahlt).\n- `Invoices.Payment` entspricht `@PaymentType`.\n- `Invoices.total` ist größer als 0.\n- Zwischen `Invoices.ScanOutDate` und dem aktuellen Serverdatum liegen mehr Tage als der Schwellenwert.\n- Die aktuelle Mahnstufe der Rechnung entspricht der Stufe vor `@ReminderLevel`:\n - Stufe `1`: `ReminderLevel` ist NULL oder 0,\n - Stufe `2`: `ReminderLevel` = 1,\n - Stufe `3`: `ReminderLevel` = 2,\n - Stufe größer als 3: `ReminderLevel` = `@ReminderLevel` - 1.\n- Die über `Invoices.AddrRef` referenzierte Adresse gehört zum Shop `@ShopID`, oder `@ShopID` ist NULL (alle Shops).\n\nDer Tages-Schwellenwert wird so ermittelt:\n\n- Stufen 1 bis 3: `@ReminderDays`, falls angegeben, sonst die Einstellung `ReminderLevel1_Days` (sofern nicht 0), sonst 15 (Stufe 1), 30 (Stufe 2) bzw. 45 (Stufe 3).\n- Stufen über 3: `@ReminderDays`, falls angegeben, sonst 45. Die Einstellung wird nicht verwendet.\n\nJede Zeile enthält Rechnungsdaten, die Rechnungsadresse sowie Shopname und Kunden-E-Mail des Shops. Eine Sortierung ist nicht definiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ReminderLevel` | int | Ja | Vorzubereitende Mahnstufe. Wählt Rechnungen, deren aktuelle Mahnstufe eine Stufe darunter liegt. |\n| `PaymentType` | char(1) | Ja | Zahlungsart-Kürzel; nur Rechnungen mit `Invoices.Payment` gleich diesem Wert werden geliefert. |\n| `ShopID` | char(3) | Ja | Shop-ID der Rechnungsadresse. NULL liefert Rechnungen aller Shops. |\n| `ReminderDays` | int | Nein | Mindestanzahl Tage seit `ScanOutDate` (strikt größer). Bei NULL wird die Einstellung bzw. der Standardwert der Stufe verwendet. |\n\n- Nur lesend: Der Aufruf erhöht die Mahnstufe der gelieferten Rechnungen **nicht**. Die Mahnstufe muss auf anderem Weg aktualisiert werden, sonst werden dieselben Rechnungen erneut geliefert.\n- Fallstrick: Auch die Stufen 2 und 3 lesen die Einstellung `ReminderLevel1_Days` (keine stufenspezifische Einstellung). Ist diese gesetzt, ersetzt sie die Standardwerte 30 und 45 dieser Stufen, sodass ohne `@ReminderDays` alle drei Stufen denselben Schwellenwert verwenden.\n- Die Einstellung wird über die Funktion `fpixi_GetSetting` gelesen, deren Definition nicht vorliegt.\n- Ist `@ReminderLevel` NULL oder kleiner als 1, wird keine Ergebnismenge zurückgegeben.\n- Das Alter wird ab `ScanOutDate` (Ausscan-/Versanddatum) gemessen, nicht ab `InvDate`. Rechnungen ohne `ScanOutDate` werden nie geliefert.\n- Rechnungen ohne passende Adresse oder Shop werden wegen Inner Joins ausgeschlossen.\n- `@ShopID` hat keinen Standardwert und muss übergeben werden; NULL liefert alle Shops.\n- Alle Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können erscheinen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetReminders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 1\n R\n SHP\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert unbezahlte Rechnungen einer Zahlungsart, die für die angegebene Mahnstufe fällig sind, inklusive Adress- und Shopdaten.\n\nListet offene Rechnungen auf, die für die nächste Zahlungserinnerung bzw. Mahnung in Frage kommen. Der Aufruf delegiert an die interne Prozedur `pixi_GetReminders`.\n\nEine Rechnung wird geliefert, wenn alle folgenden Bedingungen erfüllt sind:\n\n- `Invoices.Payed` ist NULL (nicht bezahlt).\n- `Invoices.Payment` entspricht `@PaymentType`.\n- `Invoices.total` ist größer als 0.\n- Zwischen `Invoices.ScanOutDate` und dem aktuellen Serverdatum liegen mehr Tage als der Schwellenwert.\n- Die aktuelle Mahnstufe der Rechnung entspricht der Stufe vor `@ReminderLevel`:\n - Stufe `1`: `ReminderLevel` ist NULL oder 0,\n - Stufe `2`: `ReminderLevel` = 1,\n - Stufe `3`: `ReminderLevel` = 2,\n - Stufe größer als 3: `ReminderLevel` = `@ReminderLevel` - 1.\n- Die über `Invoices.AddrRef` referenzierte Adresse gehört zum Shop `@ShopID`, oder `@ShopID` ist NULL (alle Shops).\n\nDer Tages-Schwellenwert wird so ermittelt:\n\n- Stufen 1 bis 3: `@ReminderDays`, falls angegeben, sonst die Einstellung `ReminderLevel1_Days` (sofern nicht 0), sonst 15 (Stufe 1), 30 (Stufe 2) bzw. 45 (Stufe 3).\n- Stufen über 3: `@ReminderDays`, falls angegeben, sonst 45. Die Einstellung wird nicht verwendet.\n\nJede Zeile enthält Rechnungsdaten, die Rechnungsadresse sowie Shopname und Kunden-E-Mail des Shops. Eine Sortierung ist nicht definiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ReminderLevel` | int | Ja | Vorzubereitende Mahnstufe. Wählt Rechnungen, deren aktuelle Mahnstufe eine Stufe darunter liegt. |\n| `PaymentType` | char(1) | Ja | Zahlungsart-Kürzel; nur Rechnungen mit `Invoices.Payment` gleich diesem Wert werden geliefert. |\n| `ShopID` | char(3) | Ja | Shop-ID der Rechnungsadresse. NULL liefert Rechnungen aller Shops. |\n| `ReminderDays` | int | Nein | Mindestanzahl Tage seit `ScanOutDate` (strikt größer). Bei NULL wird die Einstellung bzw. der Standardwert der Stufe verwendet. |\n\n- Nur lesend: Der Aufruf erhöht die Mahnstufe der gelieferten Rechnungen **nicht**. Die Mahnstufe muss auf anderem Weg aktualisiert werden, sonst werden dieselben Rechnungen erneut geliefert.\n- Fallstrick: Auch die Stufen 2 und 3 lesen die Einstellung `ReminderLevel1_Days` (keine stufenspezifische Einstellung). Ist diese gesetzt, ersetzt sie die Standardwerte 30 und 45 dieser Stufen, sodass ohne `@ReminderDays` alle drei Stufen denselben Schwellenwert verwenden.\n- Die Einstellung wird über die Funktion `fpixi_GetSetting` gelesen, deren Definition nicht vorliegt.\n- Ist `@ReminderLevel` NULL oder kleiner als 1, wird keine Ergebnismenge zurückgegeben.\n- Das Alter wird ab `ScanOutDate` (Ausscan-/Versanddatum) gemessen, nicht ab `InvDate`. Rechnungen ohne `ScanOutDate` werden nie geliefert.\n- Rechnungen ohne passende Adresse oder Shop werden wegen Inner Joins ausgeschlossen.\n- `@ShopID` hat keinen Standardwert und muss übergeben werden; NULL liefert alle Shops.\n- Alle Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können erscheinen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetReminders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 100234\n 2024-03-01T10:15:00\n 89.90\n R\n 00340434161094042557\n Max Mustermann\n \n \n Hauptstraße\n 12\n München\n BY\n 80331\n DE\n +49 89 123456\n max@example.com\n Example Shop\n service@example-shop.de\n \n"
}
]
},
{
"name": "pixiGetRemindersCA",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungen mit Mahnhistorie, Mahnkosten, offenem Betrag, Kundenkontostatus und Rechnungsadresse, optional gefiltert nach Mahnstufe, Shop, Zahlungsart und Datum.\n\nLiefert eine Zeile je Rechnung, die den Filtern entspricht, ergänzt um Mahndaten, Kennzahlen des Kundenkontos (CA) und die Rechnungsadresse.\n\n**Normalisierung der Parameter**\n- `ReminderLevel` = 0, `ShopID` = '' und `PaymentType` = '' werden als NULL (kein Filter) behandelt.\n- `ReminderDays` = 0 wird als NULL behandelt. Ist `ReminderDays` > 0, werden `InvoiceFrom` und `InvoiceTo` **überschrieben** mit dem Zeitraum von jetzt minus `ReminderDays` Tagen bis jetzt.\n- Ist `InvoiceFrom` gesetzt und `InvoiceTo` leer, wird `InvoiceTo` auf das aktuelle Datum mit Uhrzeit gesetzt.\n\n**Filter** (alle mit UND verknüpft)\n- `ReminderLevel`: nur Rechnungen mit mindestens einer Mahnposition genau dieser Mahnstufe. Bei NULL sind **alle** Rechnungen Kandidaten, auch Rechnungen ohne Mahnung.\n- `InvoiceFrom`/`InvoiceTo`: Rechnungsdatum zwischen beiden Werten (inklusive). Wird nur angewendet, wenn `InvoiceFrom` gesetzt ist.\n- `PaymentType`: Zahlungsart der Rechnung entspricht dem Wert.\n- `ShopID`: der Kunde gehört zu diesem Shop (`CustomerOf`).\n- `OnlyUnmatched` = 1: nur Rechnungen, deren bezahlter Betrag vom Rechnungsbetrag abweicht.\n- `OnlyWhenCAUnbalanced`: siehe Hinweise – der wirksame Wert wird aus `OnlyUnmatched` übernommen; wenn aktiv, nur Rechnungen von Kunden, deren Kundenkontosaldo ungleich 0 ist.\n\nEs werden nur Rechnungen geliefert, deren Kunde existiert, einem vorhandenen Shop zugeordnet ist und deren Rechnungsadresse existiert.\n\n**Gelieferte Daten**\n- Rechnungsdaten: Schlüssel, Rechnungsnummer, Kunden- und Adressschlüssel, Shop, höchste Auftragsnummer und die externe Auftragsnummer dieses Auftrags, Datum und Rechnungsbetrag.\n- Mahndaten: höchste Mahnstufe, frühestes Mahndatum je Stufe 1–6 (`ReminderDate1` … `ReminderDate6`), Kosten der letzten Mahnung (höchster Mahnungsschlüssel) und Summe der Kosten aller Mahnungen der Rechnung.\n- `OpenInvoiceAmount` = Rechnungsbetrag minus bezahlter Betrag.\n- Kundenkonto: `CAMatched` (1, wenn alle positiven oder alle negativen Kontobuchungen vollständig ausgeglichen sind, sonst 0) und `CAFinancialBalance` (Saldo des Kundenkontos; bei mehreren Währungen mit dem heutigen Wechselkurs umgerechnet, falls Mehrwährung aktiviert ist).\n- Kunden- und Adressdaten (externe Kundennummer, Firma, Name, Straße, PLZ, Ort, Land, Telefon, Fax, E-Mail).\n\nDie Zeilen sind nach Kundenschlüssel sortiert; innerhalb eines Kunden gibt es keine weitere Sortierung und kein Paging.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ReminderLevel` | int | Nein | Nur Rechnungen mit mindestens einer Mahnposition dieser Mahnstufe. NULL oder 0: kein Filter (auch Rechnungen ohne Mahnung). |\n| `PaymentType` | char(1) | Nein | Zahlungsart-Kürzel der Rechnung. NULL oder leer: kein Filter. |\n| `ShopID` | char(3) | Nein | Shop, zu dem der Kunde gehört (`CustomerOf`). NULL oder leer: alle Shops. |\n| `ReminderDays` | int | Nein | Wenn > 0, wird das Rechnungsdatum auf die letzten N Tage bis jetzt beschränkt; `InvoiceFrom`/`InvoiceTo` werden überschrieben. 0: nicht verwendet. |\n| `InvoiceFrom` | datetime | Nein | Beginn des Rechnungsdatumsbereichs (inklusive). NULL: kein Datumsfilter. |\n| `InvoiceTo` | datetime | Nein | Ende des Rechnungsdatumsbereichs (inklusive). Standard ist jetzt, wenn `InvoiceFrom` gesetzt ist. Ohne `InvoiceFrom` ohne Wirkung. |\n| `OnlyUnmatched` | bit | Nein | 1: nur Rechnungen, deren bezahlter Betrag vom Rechnungsbetrag abweicht. Aktiviert zusätzlich den Filter auf den Kundenkontosaldo (siehe Hinweise). |\n| `OnlyWhenCAUnbalanced` | bit | Nein | Gedacht, um nur Kunden mit Kundenkontosaldo <> 0 zu liefern. Der übergebene Wert wird ignoriert; der Code verwendet stattdessen den Wert von `OnlyUnmatched`. |\n\n- **Fallstrick:** Der Code setzt `OnlyWhenCAUnbalanced` auf den Wert von `OnlyUnmatched`. Der für `OnlyWhenCAUnbalanced` übergebene Wert wird daher ignoriert; `OnlyUnmatched` = 1 aktiviert sowohl den Filter auf den bezahlten Betrag als auch den Filter auf den Kundenkontosaldo.\n- Ohne `ReminderLevel` ist der Aufruf nicht auf gemahnte oder offene Rechnungen beschränkt. Ohne weitere Filter werden alle Rechnungen der Datenbank geliefert, was sehr langsam sein kann. Zur Eingrenzung `OnlyUnmatched`, einen Datumsbereich oder `ReminderLevel` verwenden.\n- `ReminderDays` > 0 hat Vorrang vor explizit übergebenen Werten für `InvoiceFrom`/`InvoiceTo`. `InvoiceTo` allein (ohne `InvoiceFrom`) hat keine Wirkung.\n- `CAMatched` wird in einer temporären `money`-Spalte zwischengespeichert und daher als Dezimalwert (1.00 / 0.00) statt als Boolean geliefert.\n- Die Kundenkonto-Kennzahlen werden über `fPixi_CA_IsMatched` und `fPixi_CA_FinancialBalance` für alle Kunden berechnet. Die Währungsumrechnung hängt von der Einstellung `MultiCurrencyEnabled` und dem heutigen Wechselkurs ab; existiert für heute kein Kurs, wird der umgerechnete Betrag NULL.\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Nur die Mahnstufen 1 bis 6 haben eine eigene Datumsspalte.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetRemindersCA"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungen mit Mahnhistorie, Mahnkosten, offenem Betrag, Kundenkontostatus und Rechnungsadresse, optional gefiltert nach Mahnstufe, Shop, Zahlungsart und Datum.\n\nLiefert eine Zeile je Rechnung, die den Filtern entspricht, ergänzt um Mahndaten, Kennzahlen des Kundenkontos (CA) und die Rechnungsadresse.\n\n**Normalisierung der Parameter**\n- `ReminderLevel` = 0, `ShopID` = '' und `PaymentType` = '' werden als NULL (kein Filter) behandelt.\n- `ReminderDays` = 0 wird als NULL behandelt. Ist `ReminderDays` > 0, werden `InvoiceFrom` und `InvoiceTo` **überschrieben** mit dem Zeitraum von jetzt minus `ReminderDays` Tagen bis jetzt.\n- Ist `InvoiceFrom` gesetzt und `InvoiceTo` leer, wird `InvoiceTo` auf das aktuelle Datum mit Uhrzeit gesetzt.\n\n**Filter** (alle mit UND verknüpft)\n- `ReminderLevel`: nur Rechnungen mit mindestens einer Mahnposition genau dieser Mahnstufe. Bei NULL sind **alle** Rechnungen Kandidaten, auch Rechnungen ohne Mahnung.\n- `InvoiceFrom`/`InvoiceTo`: Rechnungsdatum zwischen beiden Werten (inklusive). Wird nur angewendet, wenn `InvoiceFrom` gesetzt ist.\n- `PaymentType`: Zahlungsart der Rechnung entspricht dem Wert.\n- `ShopID`: der Kunde gehört zu diesem Shop (`CustomerOf`).\n- `OnlyUnmatched` = 1: nur Rechnungen, deren bezahlter Betrag vom Rechnungsbetrag abweicht.\n- `OnlyWhenCAUnbalanced`: siehe Hinweise – der wirksame Wert wird aus `OnlyUnmatched` übernommen; wenn aktiv, nur Rechnungen von Kunden, deren Kundenkontosaldo ungleich 0 ist.\n\nEs werden nur Rechnungen geliefert, deren Kunde existiert, einem vorhandenen Shop zugeordnet ist und deren Rechnungsadresse existiert.\n\n**Gelieferte Daten**\n- Rechnungsdaten: Schlüssel, Rechnungsnummer, Kunden- und Adressschlüssel, Shop, höchste Auftragsnummer und die externe Auftragsnummer dieses Auftrags, Datum und Rechnungsbetrag.\n- Mahndaten: höchste Mahnstufe, frühestes Mahndatum je Stufe 1–6 (`ReminderDate1` … `ReminderDate6`), Kosten der letzten Mahnung (höchster Mahnungsschlüssel) und Summe der Kosten aller Mahnungen der Rechnung.\n- `OpenInvoiceAmount` = Rechnungsbetrag minus bezahlter Betrag.\n- Kundenkonto: `CAMatched` (1, wenn alle positiven oder alle negativen Kontobuchungen vollständig ausgeglichen sind, sonst 0) und `CAFinancialBalance` (Saldo des Kundenkontos; bei mehreren Währungen mit dem heutigen Wechselkurs umgerechnet, falls Mehrwährung aktiviert ist).\n- Kunden- und Adressdaten (externe Kundennummer, Firma, Name, Straße, PLZ, Ort, Land, Telefon, Fax, E-Mail).\n\nDie Zeilen sind nach Kundenschlüssel sortiert; innerhalb eines Kunden gibt es keine weitere Sortierung und kein Paging.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ReminderLevel` | int | Nein | Nur Rechnungen mit mindestens einer Mahnposition dieser Mahnstufe. NULL oder 0: kein Filter (auch Rechnungen ohne Mahnung). |\n| `PaymentType` | char(1) | Nein | Zahlungsart-Kürzel der Rechnung. NULL oder leer: kein Filter. |\n| `ShopID` | char(3) | Nein | Shop, zu dem der Kunde gehört (`CustomerOf`). NULL oder leer: alle Shops. |\n| `ReminderDays` | int | Nein | Wenn > 0, wird das Rechnungsdatum auf die letzten N Tage bis jetzt beschränkt; `InvoiceFrom`/`InvoiceTo` werden überschrieben. 0: nicht verwendet. |\n| `InvoiceFrom` | datetime | Nein | Beginn des Rechnungsdatumsbereichs (inklusive). NULL: kein Datumsfilter. |\n| `InvoiceTo` | datetime | Nein | Ende des Rechnungsdatumsbereichs (inklusive). Standard ist jetzt, wenn `InvoiceFrom` gesetzt ist. Ohne `InvoiceFrom` ohne Wirkung. |\n| `OnlyUnmatched` | bit | Nein | 1: nur Rechnungen, deren bezahlter Betrag vom Rechnungsbetrag abweicht. Aktiviert zusätzlich den Filter auf den Kundenkontosaldo (siehe Hinweise). |\n| `OnlyWhenCAUnbalanced` | bit | Nein | Gedacht, um nur Kunden mit Kundenkontosaldo <> 0 zu liefern. Der übergebene Wert wird ignoriert; der Code verwendet stattdessen den Wert von `OnlyUnmatched`. |\n\n- **Fallstrick:** Der Code setzt `OnlyWhenCAUnbalanced` auf den Wert von `OnlyUnmatched`. Der für `OnlyWhenCAUnbalanced` übergebene Wert wird daher ignoriert; `OnlyUnmatched` = 1 aktiviert sowohl den Filter auf den bezahlten Betrag als auch den Filter auf den Kundenkontosaldo.\n- Ohne `ReminderLevel` ist der Aufruf nicht auf gemahnte oder offene Rechnungen beschränkt. Ohne weitere Filter werden alle Rechnungen der Datenbank geliefert, was sehr langsam sein kann. Zur Eingrenzung `OnlyUnmatched`, einen Datumsbereich oder `ReminderLevel` verwenden.\n- `ReminderDays` > 0 hat Vorrang vor explizit übergebenen Werten für `InvoiceFrom`/`InvoiceTo`. `InvoiceTo` allein (ohne `InvoiceFrom`) hat keine Wirkung.\n- `CAMatched` wird in einer temporären `money`-Spalte zwischengespeichert und daher als Dezimalwert (1.00 / 0.00) statt als Boolean geliefert.\n- Die Kundenkonto-Kennzahlen werden über `fPixi_CA_IsMatched` und `fPixi_CA_FinancialBalance` für alle Kunden berechnet. Die Währungsumrechnung hängt von der Einstellung `MultiCurrencyEnabled` und dem heutigen Wechselkurs ab; existiert für heute kein Kurs, wird der umgerechnete Betrag NULL.\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Nur die Mahnstufen 1 bis 6 haben eine eigene Datumsspalte.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetRemindersCA"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 48211\n 2024010532\n 10233\n 55120\n SHP\n 300512\n WEB-100245\n 2024-02-03T10:15:00\n 149.9000\n 2\n 2024-02-20T08:00:00\n 2024-03-05T08:00:00\n 5.0000\n 7.5000\n 149.9000\n 0.0000\n -149.9000\n K-4711\n Anna\n Muster\n Anna Muster\n Hauptstraße\n 12\n 80331\n München\n DE\n anna.muster@example.com\n \n"
}
]
},
{
"name": "pixiGetUpdatedInvoices",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Rechnungen, die nach einem Zeitpunkt angelegt oder geändert wurden (einschließlich Änderungen an Rechnungspositionen), optional mit Paging und Zahlungsartfilter.\n\nDer Aufruf dient der Delta-Synchronisation von Rechnungen.\n\n1. Wird `Since` nicht übergeben, gilt der Beginn des aktuellen Tages (00:00 Uhr). Ein leerer `PaymentType` wird wie `NULL` behandelt.\n2. Kandidaten werden aus drei Quellen gesammelt, jeweils beschränkt auf einen `InvoiceKey` größer als `OffSet`:\n - Rechnungen, deren `CreateDate` nach `Since` liegt,\n - Rechnungen, deren `UpdateDate` nach `Since` liegt,\n - Rechnungspositionen (`Invlines`), deren `UpdateDate` nach `Since` liegt; Kandidat ist die zugehörige Rechnung.\n3. Die Kandidaten werden je Rechnung gruppiert. `UpdateDate` im Ergebnis ist der späteste der zutreffenden Zeitstempel.\n4. Ist `PaymentType` gesetzt, bleiben nur Rechnungen mit dieser Zahlungsart.\n5. Die Liste wird aufsteigend nach `InvoiceKey` sortiert und auf `Rows` Rechnungen begrenzt (`0` = keine Begrenzung).\n6. Für jede verbleibende Rechnung liefert der Aufruf Schlüssel, Rechnungsnummer, Änderungsdatum, Shop (`CustomerOf` des Kunden) sowie Zahlungsartcode und -text, sortiert nach `InvoiceKey`.\n\n**Paging:** den höchsten `InvoiceKey` der vorherigen Seite als `OffSet` mit demselben `Since` übergeben, um die nächste Seite abzurufen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Nein | Es werden nur Rechnungen geliefert, die nach diesem Zeitpunkt angelegt oder geändert wurden (inklusive Positionen). `NULL` bedeutet Beginn des aktuellen Tages. |\n| `Rows` | int | Nein | Maximale Anzahl Rechnungen pro Aufruf (Seitengröße). `0` liefert alle passenden Rechnungen. |\n| `PaymentType` | varchar(1) | Nein | Optionaler Zahlungsartcode (`Invoices.Payment`). Es werden nur Rechnungen mit dieser Zahlungsart geliefert. `NULL` oder leer bedeutet alle Zahlungsarten. |\n| `OffSet` | int | Nein | Paging-Offset: es werden nur Rechnungen mit einem `InvoiceKey` größer als dieser Wert berücksichtigt. Den höchsten `InvoiceKey` der vorherigen Seite übergeben. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; nicht festgeschriebene Änderungen können sichtbar sein.\n- Der Vergleich mit `Since` ist strikt (`>`); genau zum Zeitpunkt `Since` geänderte Datensätze werden nicht geliefert.\n- `UpdateDate` berücksichtigt nur Zeitstempel nach `Since` und ist damit die späteste Änderung im angefragten Zeitraum.\n- Die Begrenzung `Rows` (über `SET ROWCOUNT`) greift vor den Joins auf `Customers` und `Payments`. Rechnungen ohne passenden Kunden oder Zahlungsartcode fallen danach heraus, sodass eine Seite weniger als `Rows` Zeilen enthalten kann, obwohl weitere Daten existieren. Paging daher mit dem höchsten gelieferten `InvoiceKey` fortsetzen, bis keine Zeilen mehr kommen.\n- Nur die abschließende Abfrage ist in eine Fehlerbehandlung eingebettet; bei einem unerwarteten Fehler wird eine Statuszeile geliefert und die Prozedur gibt `3` zurück, sonst `0`.\n- Temporäre Tabellen werden mit `util.TempTableDrop` aufgeräumt (Definition nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetUpdatedInvoices"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Rechnungen, die nach einem Zeitpunkt angelegt oder geändert wurden (einschließlich Änderungen an Rechnungspositionen), optional mit Paging und Zahlungsartfilter.\n\nDer Aufruf dient der Delta-Synchronisation von Rechnungen.\n\n1. Wird `Since` nicht übergeben, gilt der Beginn des aktuellen Tages (00:00 Uhr). Ein leerer `PaymentType` wird wie `NULL` behandelt.\n2. Kandidaten werden aus drei Quellen gesammelt, jeweils beschränkt auf einen `InvoiceKey` größer als `OffSet`:\n - Rechnungen, deren `CreateDate` nach `Since` liegt,\n - Rechnungen, deren `UpdateDate` nach `Since` liegt,\n - Rechnungspositionen (`Invlines`), deren `UpdateDate` nach `Since` liegt; Kandidat ist die zugehörige Rechnung.\n3. Die Kandidaten werden je Rechnung gruppiert. `UpdateDate` im Ergebnis ist der späteste der zutreffenden Zeitstempel.\n4. Ist `PaymentType` gesetzt, bleiben nur Rechnungen mit dieser Zahlungsart.\n5. Die Liste wird aufsteigend nach `InvoiceKey` sortiert und auf `Rows` Rechnungen begrenzt (`0` = keine Begrenzung).\n6. Für jede verbleibende Rechnung liefert der Aufruf Schlüssel, Rechnungsnummer, Änderungsdatum, Shop (`CustomerOf` des Kunden) sowie Zahlungsartcode und -text, sortiert nach `InvoiceKey`.\n\n**Paging:** den höchsten `InvoiceKey` der vorherigen Seite als `OffSet` mit demselben `Since` übergeben, um die nächste Seite abzurufen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Nein | Es werden nur Rechnungen geliefert, die nach diesem Zeitpunkt angelegt oder geändert wurden (inklusive Positionen). `NULL` bedeutet Beginn des aktuellen Tages. |\n| `Rows` | int | Nein | Maximale Anzahl Rechnungen pro Aufruf (Seitengröße). `0` liefert alle passenden Rechnungen. |\n| `PaymentType` | varchar(1) | Nein | Optionaler Zahlungsartcode (`Invoices.Payment`). Es werden nur Rechnungen mit dieser Zahlungsart geliefert. `NULL` oder leer bedeutet alle Zahlungsarten. |\n| `OffSet` | int | Nein | Paging-Offset: es werden nur Rechnungen mit einem `InvoiceKey` größer als dieser Wert berücksichtigt. Den höchsten `InvoiceKey` der vorherigen Seite übergeben. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; nicht festgeschriebene Änderungen können sichtbar sein.\n- Der Vergleich mit `Since` ist strikt (`>`); genau zum Zeitpunkt `Since` geänderte Datensätze werden nicht geliefert.\n- `UpdateDate` berücksichtigt nur Zeitstempel nach `Since` und ist damit die späteste Änderung im angefragten Zeitraum.\n- Die Begrenzung `Rows` (über `SET ROWCOUNT`) greift vor den Joins auf `Customers` und `Payments`. Rechnungen ohne passenden Kunden oder Zahlungsartcode fallen danach heraus, sodass eine Seite weniger als `Rows` Zeilen enthalten kann, obwohl weitere Daten existieren. Paging daher mit dem höchsten gelieferten `InvoiceKey` fortsetzen, bis keine Zeilen mehr kommen.\n- Nur die abschließende Abfrage ist in eine Fehlerbehandlung eingebettet; bei einem unerwarteten Fehler wird eine Statuszeile geliefert und die Prozedur gibt `3` zurück, sonst `0`.\n- Temporäre Tabellen werden mit `util.TempTableDrop` aufgeräumt (Definition nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetUpdatedInvoices"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n RE2024-010452\n 2024-05-02T09:14:33\n SHOP1\n V\n Vorkasse\n \n \n 10457\n RE2024-010457\n 2024-05-02T11:02:10\n SHOP1\n R\n Rechnung\n \n"
}
]
},
{
"name": "pixiInvoiceSetInfo",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder ersetzt die Notiz (`Note`) einer einzelnen Rechnung, die über Rechnungsnummer oder Rechnungsschlüssel bestimmt wird.\n\nAktualisiert das Feld `Note` genau einer Rechnung in der Tabelle `Invoices`.\n\n1. Die Rechnung wird über die Bedingung `InvoiceNr = @InvoiceNr OR InvoiceKey = @InvoiceKey` gesucht.\n2. Trifft die Bedingung auf keine oder auf mehr als eine Rechnung zu, liefert der Aufruf eine Statuszeile mit `ErrorNr` = `404` und ändert nichts. Das ist der Fall, wenn:\n - weder `InvoiceNr` noch `InvoiceKey` übergeben wird,\n - die angegebene Nummer bzw. der Schlüssel nicht existiert,\n - `InvoiceNr` und `InvoiceKey` auf zwei verschiedene Rechnungen verweisen.\n3. Trifft die Bedingung auf genau eine Rechnung zu, wird deren `Note` mit `@Note` überschrieben und eine Statuszeile mit `ErrorNr` = `200` und leerer `ErrorMessage` geliefert.\n4. Schlägt das Update fehl, wird eine Statuszeile mit `ErrorNr` = `500` geliefert.\n\nDie Angabe beider Parameter ist zulässig, sofern sie auf dieselbe Rechnung verweisen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Nein | Rechnungsnummer der zu ändernden Rechnung. Diese oder `InvoiceKey` muss genau eine Rechnung bestimmen. |\n| `InvoiceKey` | int | Nein | Interner Schlüssel der zu ändernden Rechnung. Alternative zu `InvoiceNr`; werden beide angegeben, müssen sie auf dieselbe Rechnung verweisen. |\n| `Note` | varchar(255) | Nein | Neuer Notiztext der Rechnung. Ersetzt die vorhandene Notiz; `NULL` (oder Weglassen des Parameters) löscht sie. |\n\n- Die vorhandene Notiz wird **ersetzt**, nicht ergänzt. Wird `Note` weggelassen, gilt der Standardwert `NULL` und die Notiz der Rechnung wird gelöscht.\n- Die Existenzprüfung liest `Invoices` mit `NOLOCK`; Prüfung und Update laufen nicht in einer Transaktion.\n- Die Statuszeile `500` enthält nicht den ursprünglichen SQL-Fehlertext.\n- `ErrorNr` wird als Zeichenkette (`'200'`, `'404'`, `'500'`) geliefert, nicht als Zahl.\n- `@Note` ist als `varchar(255)` deklariert; längere Texte können abgeschnitten werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiInvoiceSetInfo"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder ersetzt die Notiz (`Note`) einer einzelnen Rechnung, die über Rechnungsnummer oder Rechnungsschlüssel bestimmt wird.\n\nAktualisiert das Feld `Note` genau einer Rechnung in der Tabelle `Invoices`.\n\n1. Die Rechnung wird über die Bedingung `InvoiceNr = @InvoiceNr OR InvoiceKey = @InvoiceKey` gesucht.\n2. Trifft die Bedingung auf keine oder auf mehr als eine Rechnung zu, liefert der Aufruf eine Statuszeile mit `ErrorNr` = `404` und ändert nichts. Das ist der Fall, wenn:\n - weder `InvoiceNr` noch `InvoiceKey` übergeben wird,\n - die angegebene Nummer bzw. der Schlüssel nicht existiert,\n - `InvoiceNr` und `InvoiceKey` auf zwei verschiedene Rechnungen verweisen.\n3. Trifft die Bedingung auf genau eine Rechnung zu, wird deren `Note` mit `@Note` überschrieben und eine Statuszeile mit `ErrorNr` = `200` und leerer `ErrorMessage` geliefert.\n4. Schlägt das Update fehl, wird eine Statuszeile mit `ErrorNr` = `500` geliefert.\n\nDie Angabe beider Parameter ist zulässig, sofern sie auf dieselbe Rechnung verweisen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Nein | Rechnungsnummer der zu ändernden Rechnung. Diese oder `InvoiceKey` muss genau eine Rechnung bestimmen. |\n| `InvoiceKey` | int | Nein | Interner Schlüssel der zu ändernden Rechnung. Alternative zu `InvoiceNr`; werden beide angegeben, müssen sie auf dieselbe Rechnung verweisen. |\n| `Note` | varchar(255) | Nein | Neuer Notiztext der Rechnung. Ersetzt die vorhandene Notiz; `NULL` (oder Weglassen des Parameters) löscht sie. |\n\n- Die vorhandene Notiz wird **ersetzt**, nicht ergänzt. Wird `Note` weggelassen, gilt der Standardwert `NULL` und die Notiz der Rechnung wird gelöscht.\n- Die Existenzprüfung liest `Invoices` mit `NOLOCK`; Prüfung und Update laufen nicht in einer Transaktion.\n- Die Statuszeile `500` enthält nicht den ursprünglichen SQL-Fehlertext.\n- `ErrorNr` wird als Zeichenkette (`'200'`, `'404'`, `'500'`) geliefert, nicht als Zahl.\n- `@Note` ist als `varchar(255)` deklariert; längere Texte können abgeschnitten werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiInvoiceSetInfo"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 200\n \n \n"
}
]
},
{
"name": "pixiInvoiceSetTrackingID",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE1004711\n 00340434161094042557;00340434161094042564\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder ergänzt Sendungsverfolgungsnummern (Tracking-IDs) einer Rechnung und ihrer Pakete, optional mit Überschreiben und Zurücksetzen des Kundenbenachrichtigungs-Flags.\n\nOrdnet einer Rechnung (`Invoices.ShipmentTrackingID`) und ihren Paketen (`pixi.InvoicePackage`) eine oder mehrere Tracking-IDs zu.\n\n1. **Rechnungssuche**: `InvoiceNR` wird mit `Invoices.InvoiceNr` abgeglichen. Enthält die Nummer `-`, werden die Suffixe nach dem letzten `-` schrittweise entfernt und auch alle gekürzten Varianten geprüft (z. B. `RE1000-2-1` → `RE1000-2` → `RE1000`). Verwendet werden nur tatsächlich vorhandene Rechnungsnummern.\n2. **Trennzeichen**: Ist `Separator` weder `;` noch leer, wird jedes Vorkommen in `TrackingID` durch `;` ersetzt. Intern dient immer `;` als Trennzeichen.\n3. Wird keine Rechnung gefunden, wird die Zeile `InvoiceNR is not existing` geliefert und nichts geändert.\n4. Wird die Rechnung gefunden, wird zuerst die Zeile `InvoiceNR found and Updated` geliefert. Danach:\n - **`Overwrite` = 1**: `Invoices.ShipmentTrackingID` wird geleert. Alle Pakete der Rechnung ohne Paketpositionen werden von `InvoicePolling` gelöst (`InvoicePackageId` = NULL). Pakete ohne Paketpositionen werden gelöscht, mit Ausnahme des Pakets mit der kleinsten Id.\n - Die interne Prozedur `Pixi_SetTrackingId` wird ausgeführt. Sie zerlegt die Tracking-IDs, ignoriert bereits an der Rechnung gespeicherte IDs und verteilt die neuen IDs auf Pakete:\n - Hat kein Paket Paketpositionen aus einer Packstation, erhält ein einzelnes vorhandenes Paket mit leerer Tracking-ID die erste neue ID. Alle weiteren neuen IDs werden als neue Pakete angelegt; existiert kein solches Paket, gilt das für alle neuen IDs. `ShipmentTrackingID` der Rechnung wird anschließend aus allen eindeutigen Paket-Tracking-IDs neu gebildet, sortiert und mit `;` getrennt.\n - Gibt es Pakete mit Paketpositionen und genau ein Paket, erhält dieses Paket die letzte neue ID. Bei mehreren Paketen bleiben die Pakete unverändert. `ShipmentTrackingID` wird zur Vereinigung aus vorhandenen und neuen IDs.\n - `Invoices.Packages` wird auf die Anzahl der Pakete gesetzt, `UpdateDate` und `UpdateEmp` (`TrackingID Import`) werden aktualisiert. Ein Ereignis `InvoiceChanged` wird veröffentlicht.\n - **`ResetClientNotifiedFlag` = 1**: Für alle Auftragspositionen der Rechnung erhält der jeweils jüngste `OrderHistory`-Eintrag mit Status `AUS` den Wert `ClientNotified = 'N'`. Der Versand wird damit samt Tracking-ID erneut an Kunde bzw. Shop gemeldet.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNR` | varchar(20) | Ja | Rechnungsnummer. Durch `-` abgetrennte Suffixe werden schrittweise entfernt, falls die vollständige Nummer nicht existiert. |\n| `TrackingID` | varchar(8000) | Ja | Eine oder mehrere Tracking-IDs, getrennt durch `Separator`. Jede ID wird auf 512 Zeichen gekürzt. |\n| `Overwrite` | bit | Nein | Bei 1 wird das Tracking-Feld der Rechnung geleert, und Pakete ohne Paketpositionen (außer dem ersten) werden gelöscht, bevor die neuen IDs gesetzt werden. |\n| `ResetClientNotifiedFlag` | bit | Nein | Bei 1 wird der jüngste `AUS`-Eintrag der Auftragshistorie jeder Auftragsposition der Rechnung auf `ClientNotified = 'N'` gesetzt, damit der Versand erneut exportiert wird. |\n| `Separator` | varchar(1) | Nein | Trennzeichen in `TrackingID`. Es wird intern in `;` umgewandelt; ein leerer Wert bedeutet `;`. |\n\n- Die Prozedur läuft in einer eigenen Transaktion bzw. in einem Savepoint, wenn bereits eine Transaktion offen ist.\n- **Fehler werden verschluckt**: Sie werden abgefangen, die Transaktion wird zurückgerollt und der Fehler über `log.InsertError` protokolliert. An den Aufrufer wird kein Fehler gemeldet. Da die Meldung `InvoiceNR found and Updated` *vor* den Änderungen selektiert wird, kann sie auch dann geliefert werden, wenn alle Änderungen zurückgerollt wurden.\n- Auflösung der Rechnungsnummer: Passen mehrere Varianten (z. B. `RE1000-1` und `RE1000`), wird durch die sortierte Variablenzuweisung typischerweise die kürzeste passende Nummer verwendet. Zur Vermeidung von Mehrdeutigkeiten sollte die exakte Rechnungsnummer übergeben werden.\n- `Overwrite` setzt die Tracking-ID des verbleibenden Pakets (kleinste Id) nicht zurück. Hat dieses Paket bereits eine Tracking-ID, werden die neuen IDs als zusätzliche Pakete angelegt. Die alte ID erscheint erneut in `ShipmentTrackingID`, da dieses Feld aus allen Paketen neu gebildet wird.\n- `Overwrite` löst `InvoicePolling`-Zeilen auch vom verbleibenden Paket, sofern dieses keine Paketpositionen hat.\n- Pakete mit Paketpositionen werden nie gelöscht. Gibt es mehrere solcher Pakete, werden die Paket-Tracking-IDs gar nicht geändert; nur das Feld an der Rechnung wird ergänzt. Die interne Prozedur weist selbst darauf hin, dass Tracking-IDs besser pro Paket gesetzt werden sollten.\n- Tracking-IDs werden jeweils auf 512 Zeichen gekürzt. Die Zerlegung erfolgt über `dbo.fPixi_GetCommaSplit`, die Benutzerermittlung über `inf.UserGetByName` und die Ereignisveröffentlichung über `dbo.Pixi_MQ_EventPublish`. Deren Definitionen liegen nicht vor.\n- Lesezugriffe verwenden `NOLOCK`, Updates `ROWLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiInvoiceSetTrackingID"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE1004711\n 00340434161094042557;00340434161094042564\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder ergänzt Sendungsverfolgungsnummern (Tracking-IDs) einer Rechnung und ihrer Pakete, optional mit Überschreiben und Zurücksetzen des Kundenbenachrichtigungs-Flags.\n\nOrdnet einer Rechnung (`Invoices.ShipmentTrackingID`) und ihren Paketen (`pixi.InvoicePackage`) eine oder mehrere Tracking-IDs zu.\n\n1. **Rechnungssuche**: `InvoiceNR` wird mit `Invoices.InvoiceNr` abgeglichen. Enthält die Nummer `-`, werden die Suffixe nach dem letzten `-` schrittweise entfernt und auch alle gekürzten Varianten geprüft (z. B. `RE1000-2-1` → `RE1000-2` → `RE1000`). Verwendet werden nur tatsächlich vorhandene Rechnungsnummern.\n2. **Trennzeichen**: Ist `Separator` weder `;` noch leer, wird jedes Vorkommen in `TrackingID` durch `;` ersetzt. Intern dient immer `;` als Trennzeichen.\n3. Wird keine Rechnung gefunden, wird die Zeile `InvoiceNR is not existing` geliefert und nichts geändert.\n4. Wird die Rechnung gefunden, wird zuerst die Zeile `InvoiceNR found and Updated` geliefert. Danach:\n - **`Overwrite` = 1**: `Invoices.ShipmentTrackingID` wird geleert. Alle Pakete der Rechnung ohne Paketpositionen werden von `InvoicePolling` gelöst (`InvoicePackageId` = NULL). Pakete ohne Paketpositionen werden gelöscht, mit Ausnahme des Pakets mit der kleinsten Id.\n - Die interne Prozedur `Pixi_SetTrackingId` wird ausgeführt. Sie zerlegt die Tracking-IDs, ignoriert bereits an der Rechnung gespeicherte IDs und verteilt die neuen IDs auf Pakete:\n - Hat kein Paket Paketpositionen aus einer Packstation, erhält ein einzelnes vorhandenes Paket mit leerer Tracking-ID die erste neue ID. Alle weiteren neuen IDs werden als neue Pakete angelegt; existiert kein solches Paket, gilt das für alle neuen IDs. `ShipmentTrackingID` der Rechnung wird anschließend aus allen eindeutigen Paket-Tracking-IDs neu gebildet, sortiert und mit `;` getrennt.\n - Gibt es Pakete mit Paketpositionen und genau ein Paket, erhält dieses Paket die letzte neue ID. Bei mehreren Paketen bleiben die Pakete unverändert. `ShipmentTrackingID` wird zur Vereinigung aus vorhandenen und neuen IDs.\n - `Invoices.Packages` wird auf die Anzahl der Pakete gesetzt, `UpdateDate` und `UpdateEmp` (`TrackingID Import`) werden aktualisiert. Ein Ereignis `InvoiceChanged` wird veröffentlicht.\n - **`ResetClientNotifiedFlag` = 1**: Für alle Auftragspositionen der Rechnung erhält der jeweils jüngste `OrderHistory`-Eintrag mit Status `AUS` den Wert `ClientNotified = 'N'`. Der Versand wird damit samt Tracking-ID erneut an Kunde bzw. Shop gemeldet.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNR` | varchar(20) | Ja | Rechnungsnummer. Durch `-` abgetrennte Suffixe werden schrittweise entfernt, falls die vollständige Nummer nicht existiert. |\n| `TrackingID` | varchar(8000) | Ja | Eine oder mehrere Tracking-IDs, getrennt durch `Separator`. Jede ID wird auf 512 Zeichen gekürzt. |\n| `Overwrite` | bit | Nein | Bei 1 wird das Tracking-Feld der Rechnung geleert, und Pakete ohne Paketpositionen (außer dem ersten) werden gelöscht, bevor die neuen IDs gesetzt werden. |\n| `ResetClientNotifiedFlag` | bit | Nein | Bei 1 wird der jüngste `AUS`-Eintrag der Auftragshistorie jeder Auftragsposition der Rechnung auf `ClientNotified = 'N'` gesetzt, damit der Versand erneut exportiert wird. |\n| `Separator` | varchar(1) | Nein | Trennzeichen in `TrackingID`. Es wird intern in `;` umgewandelt; ein leerer Wert bedeutet `;`. |\n\n- Die Prozedur läuft in einer eigenen Transaktion bzw. in einem Savepoint, wenn bereits eine Transaktion offen ist.\n- **Fehler werden verschluckt**: Sie werden abgefangen, die Transaktion wird zurückgerollt und der Fehler über `log.InsertError` protokolliert. An den Aufrufer wird kein Fehler gemeldet. Da die Meldung `InvoiceNR found and Updated` *vor* den Änderungen selektiert wird, kann sie auch dann geliefert werden, wenn alle Änderungen zurückgerollt wurden.\n- Auflösung der Rechnungsnummer: Passen mehrere Varianten (z. B. `RE1000-1` und `RE1000`), wird durch die sortierte Variablenzuweisung typischerweise die kürzeste passende Nummer verwendet. Zur Vermeidung von Mehrdeutigkeiten sollte die exakte Rechnungsnummer übergeben werden.\n- `Overwrite` setzt die Tracking-ID des verbleibenden Pakets (kleinste Id) nicht zurück. Hat dieses Paket bereits eine Tracking-ID, werden die neuen IDs als zusätzliche Pakete angelegt. Die alte ID erscheint erneut in `ShipmentTrackingID`, da dieses Feld aus allen Paketen neu gebildet wird.\n- `Overwrite` löst `InvoicePolling`-Zeilen auch vom verbleibenden Paket, sofern dieses keine Paketpositionen hat.\n- Pakete mit Paketpositionen werden nie gelöscht. Gibt es mehrere solcher Pakete, werden die Paket-Tracking-IDs gar nicht geändert; nur das Feld an der Rechnung wird ergänzt. Die interne Prozedur weist selbst darauf hin, dass Tracking-IDs besser pro Paket gesetzt werden sollten.\n- Tracking-IDs werden jeweils auf 512 Zeichen gekürzt. Die Zerlegung erfolgt über `dbo.fPixi_GetCommaSplit`, die Benutzerermittlung über `inf.UserGetByName` und die Ereignisveröffentlichung über `dbo.Pixi_MQ_EventPublish`. Deren Definitionen liegen nicht vor.\n- Lesezugriffe verwenden `NOLOCK`, Updates `ROWLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiInvoiceSetTrackingID"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n InvoiceNR found and Updated\n \n"
}
]
},
{
"name": "pixiManualCreditCreate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine manuelle Gutschrift (negative Rechnung) zu einer bestehenden Rechnung mit einem Betrag und einem Steuersatz an.\n\nLegt eine Gutschrift an, die auf eine bestehende Rechnung verweist. Die Gutschrift hat keine Artikelpositionen; sie besteht aus einem Betrag und einem Steuersatz.\n\n1. **Prüfungen**\n - `Amount` muss größer als 0 sein.\n - `VATRate` muss `H`, `L` oder `N` sein.\n - Mindestens `InvoiceKey` oder `InvoiceNr` muss angegeben werden. Ist nur `InvoiceNr` angegeben, wird der Schlüssel in `Invoices` ermittelt. Die Rechnung muss existieren. Sind beide angegeben, müssen sie zur selben Rechnung gehören.\n2. **Rechnungsdaten**: Auftragstyp, Rechnungslager, Kunde, Rechnungs- und Lieferadresse sowie Währung werden aus der ursprünglichen Rechnung übernommen. Das Land stammt aus der Rechnungsadresse.\n3. **Positionstext**: Ist `PositionText` leer, wird ein Standardtext erzeugt. Bei `LanguageId` = 1 lautet er `Manual Credit: Created From: {InvoiceNr}`, sonst `Manuell Gutschrift: Erstellt von: {InvoiceNr}`. `LanguageId` ist standardmäßig 2.\n4. **Steuerberechnung**: Die Steuersätze für Land und Auftragstyp werden über `Pixi_CA_GetVATList` gelesen. Verwendet wird die Zeile mit dem angeforderten `VATRate`.\n - Bei Auftragstyp `B2B` gilt `Amount` als **Nettobetrag**: netto = −`Amount`, brutto = −`Amount` × (1 + MwSt.), auf 2 Stellen gerundet.\n - Bei allen anderen Auftragstypen gilt `Amount` als **Bruttobetrag**: brutto = −`Amount`, netto = −`Amount` / (1 + MwSt.), auf 2 Stellen gerundet.\n5. **Limitprüfung**: Der absolute Bruttobetrag der neuen Gutschrift wird zur absoluten Summe der Beträge aller Rechnungen addiert, die bereits auf die ursprüngliche Rechnung verweisen (`RefToInvoiceKey`). Ist das Ergebnis größer als der Rechnungsbetrag der ursprünglichen Rechnung, wird der Aufruf abgelehnt.\n6. **Anlage**: `Pixi_CA_InsertManualInvoice` legt die Gutschrift an. Dabei wird Folgendes ausgeführt:\n - die nächste Rechnungsnummer wird vergeben;\n - der Datensatz wird in `Invoices` eingefügt, wobei `RefToInvoiceKey`/`RefToInvoiceNr` auf die ursprüngliche Rechnung verweisen;\n - SEPA-Daten und ein `InvoicePackage`-Datensatz werden ergänzt;\n - die Gutschrift wird auf das Kundenkonto gebucht;\n - das MQ-Event `InvoiceCreated` wird veröffentlicht.\n\nDer Aufruf liefert eine Statuszeile mit `Status` und `Message`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceKey` | int | Nein | Schlüssel der ursprünglichen Rechnung. Dieser Wert oder `InvoiceNr` ist erforderlich; bei Angabe beider müssen sie übereinstimmen. |\n| `InvoiceNr` | varchar(20) | Nein | Nummer der ursprünglichen Rechnung. Dient zur Ermittlung des Schlüssels, wenn `InvoiceKey` fehlt. |\n| `PositionText` | varchar(120) | Nein | Text der Gutschrift, gespeichert als Rechnungstext ohne Positionen. Ist er leer, wird ein Standardtext mit der ursprünglichen Rechnungsnummer verwendet. |\n| `LanguageId` | tinyint | Nein | Sprache für den Standard-Positionstext. `NULL` wird als 2 behandelt. Der Wert wird auch an die innere Prozedur übergeben. |\n| `VATRate` | varchar(1) | Nein | Steuersatzklasse des Gutschriftbetrags. |\n| `Amount` | money | Nein | Positiver Gutschriftbetrag. Bei Auftragstyp `B2B` ist er netto, bei allen anderen Auftragstypen brutto. Er wird negativ gespeichert. |\n| `UserName` | varchar(50) | Nein | Benutzername, der als Ersteller der Gutschrift gespeichert wird. |\n\n- Der Aufruf läuft in einer eigenen Transaktion. Ist bereits eine Transaktion offen, wird stattdessen ein Savepoint verwendet. Prüffehler führen zum Rollback mit Rückgabewert 2. Unerwartete Fehler werden über `log.InsertError` protokolliert und liefern Rückgabewert 3. Erfolg liefert 0. Rückgabewerte sind nicht Teil der SOAP-Zeilen.\n- **`Amount` und `VATRate` sollten immer übergeben werden.** Ein `NULL`-Wert löst die Prüfungen nicht aus, da Vergleiche mit `NULL` nicht wahr sind. Die berechneten Beträge bleiben dann `NULL`, und auch die Limitprüfung greift nicht.\n- Dasselbe gilt, wenn die Steuerliste keine Zeile für den angeforderten `VATRate` enthält, z. B. `L` für ein Land ohne ermäßigten Satz. Die Beträge bleiben `NULL`.\n- `Pixi_CA_GetVATList` kann für denselben `VATRate` sowohl den aktuellen als auch einen vor 12 Monaten gültigen Satz liefern. Welche Zeile dann für die Berechnung verwendet wird, ist im Code nicht festgelegt.\n- Die Limitprüfung addiert den Absolutwert der **Summe** bestehender verweisender Rechnungen, nicht die Summe der Absolutwerte.\n- Die Rechnungsabfragen verwenden `NOLOCK`. Gleichzeitige Gutschriften zur selben Rechnung werden daher nicht sicher daran gehindert, den Rechnungsbetrag zu überschreiten.\n- `Pixi_CA_InsertManualInvoice` fängt eigene Fehler ab, protokolliert sie und gibt sie nicht weiter. Bei einem Fehler dort kann trotzdem die `OK`-Zeile geliefert werden. Darauf kann eine `Error`-Zeile folgen, wenn der abschließende Commit fehlschlägt, weil die Transaktion bereits zurückgerollt wurde.\n- Der Text des allgemeinen Fehlers (`...getting the report values...`) ist irreführend; er betrifft jeden unerwarteten Fehler dieses Aufrufs.\n- Die inneren Prozeduren `Pixi_GetNextInvNr`, `Pixi_CA_AddPixiInvoice`, `Pixi_AddDataForSEPAExportToInvoice` und `Pixi_MQ_EventPublish` liegen nicht vor. Ihre genauen Auswirkungen, etwa Kundenkontobuchungen und das MQ-Event, sind hier nicht dokumentiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiManualCreditCreate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine manuelle Gutschrift (negative Rechnung) zu einer bestehenden Rechnung mit einem Betrag und einem Steuersatz an.\n\nLegt eine Gutschrift an, die auf eine bestehende Rechnung verweist. Die Gutschrift hat keine Artikelpositionen; sie besteht aus einem Betrag und einem Steuersatz.\n\n1. **Prüfungen**\n - `Amount` muss größer als 0 sein.\n - `VATRate` muss `H`, `L` oder `N` sein.\n - Mindestens `InvoiceKey` oder `InvoiceNr` muss angegeben werden. Ist nur `InvoiceNr` angegeben, wird der Schlüssel in `Invoices` ermittelt. Die Rechnung muss existieren. Sind beide angegeben, müssen sie zur selben Rechnung gehören.\n2. **Rechnungsdaten**: Auftragstyp, Rechnungslager, Kunde, Rechnungs- und Lieferadresse sowie Währung werden aus der ursprünglichen Rechnung übernommen. Das Land stammt aus der Rechnungsadresse.\n3. **Positionstext**: Ist `PositionText` leer, wird ein Standardtext erzeugt. Bei `LanguageId` = 1 lautet er `Manual Credit: Created From: {InvoiceNr}`, sonst `Manuell Gutschrift: Erstellt von: {InvoiceNr}`. `LanguageId` ist standardmäßig 2.\n4. **Steuerberechnung**: Die Steuersätze für Land und Auftragstyp werden über `Pixi_CA_GetVATList` gelesen. Verwendet wird die Zeile mit dem angeforderten `VATRate`.\n - Bei Auftragstyp `B2B` gilt `Amount` als **Nettobetrag**: netto = −`Amount`, brutto = −`Amount` × (1 + MwSt.), auf 2 Stellen gerundet.\n - Bei allen anderen Auftragstypen gilt `Amount` als **Bruttobetrag**: brutto = −`Amount`, netto = −`Amount` / (1 + MwSt.), auf 2 Stellen gerundet.\n5. **Limitprüfung**: Der absolute Bruttobetrag der neuen Gutschrift wird zur absoluten Summe der Beträge aller Rechnungen addiert, die bereits auf die ursprüngliche Rechnung verweisen (`RefToInvoiceKey`). Ist das Ergebnis größer als der Rechnungsbetrag der ursprünglichen Rechnung, wird der Aufruf abgelehnt.\n6. **Anlage**: `Pixi_CA_InsertManualInvoice` legt die Gutschrift an. Dabei wird Folgendes ausgeführt:\n - die nächste Rechnungsnummer wird vergeben;\n - der Datensatz wird in `Invoices` eingefügt, wobei `RefToInvoiceKey`/`RefToInvoiceNr` auf die ursprüngliche Rechnung verweisen;\n - SEPA-Daten und ein `InvoicePackage`-Datensatz werden ergänzt;\n - die Gutschrift wird auf das Kundenkonto gebucht;\n - das MQ-Event `InvoiceCreated` wird veröffentlicht.\n\nDer Aufruf liefert eine Statuszeile mit `Status` und `Message`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceKey` | int | Nein | Schlüssel der ursprünglichen Rechnung. Dieser Wert oder `InvoiceNr` ist erforderlich; bei Angabe beider müssen sie übereinstimmen. |\n| `InvoiceNr` | varchar(20) | Nein | Nummer der ursprünglichen Rechnung. Dient zur Ermittlung des Schlüssels, wenn `InvoiceKey` fehlt. |\n| `PositionText` | varchar(120) | Nein | Text der Gutschrift, gespeichert als Rechnungstext ohne Positionen. Ist er leer, wird ein Standardtext mit der ursprünglichen Rechnungsnummer verwendet. |\n| `LanguageId` | tinyint | Nein | Sprache für den Standard-Positionstext. `NULL` wird als 2 behandelt. Der Wert wird auch an die innere Prozedur übergeben. |\n| `VATRate` | varchar(1) | Nein | Steuersatzklasse des Gutschriftbetrags. |\n| `Amount` | money | Nein | Positiver Gutschriftbetrag. Bei Auftragstyp `B2B` ist er netto, bei allen anderen Auftragstypen brutto. Er wird negativ gespeichert. |\n| `UserName` | varchar(50) | Nein | Benutzername, der als Ersteller der Gutschrift gespeichert wird. |\n\n- Der Aufruf läuft in einer eigenen Transaktion. Ist bereits eine Transaktion offen, wird stattdessen ein Savepoint verwendet. Prüffehler führen zum Rollback mit Rückgabewert 2. Unerwartete Fehler werden über `log.InsertError` protokolliert und liefern Rückgabewert 3. Erfolg liefert 0. Rückgabewerte sind nicht Teil der SOAP-Zeilen.\n- **`Amount` und `VATRate` sollten immer übergeben werden.** Ein `NULL`-Wert löst die Prüfungen nicht aus, da Vergleiche mit `NULL` nicht wahr sind. Die berechneten Beträge bleiben dann `NULL`, und auch die Limitprüfung greift nicht.\n- Dasselbe gilt, wenn die Steuerliste keine Zeile für den angeforderten `VATRate` enthält, z. B. `L` für ein Land ohne ermäßigten Satz. Die Beträge bleiben `NULL`.\n- `Pixi_CA_GetVATList` kann für denselben `VATRate` sowohl den aktuellen als auch einen vor 12 Monaten gültigen Satz liefern. Welche Zeile dann für die Berechnung verwendet wird, ist im Code nicht festgelegt.\n- Die Limitprüfung addiert den Absolutwert der **Summe** bestehender verweisender Rechnungen, nicht die Summe der Absolutwerte.\n- Die Rechnungsabfragen verwenden `NOLOCK`. Gleichzeitige Gutschriften zur selben Rechnung werden daher nicht sicher daran gehindert, den Rechnungsbetrag zu überschreiten.\n- `Pixi_CA_InsertManualInvoice` fängt eigene Fehler ab, protokolliert sie und gibt sie nicht weiter. Bei einem Fehler dort kann trotzdem die `OK`-Zeile geliefert werden. Darauf kann eine `Error`-Zeile folgen, wenn der abschließende Commit fehlschlägt, weil die Transaktion bereits zurückgerollt wurde.\n- Der Text des allgemeinen Fehlers (`...getting the report values...`) ist irreführend; er betrifft jeden unerwarteten Fehler dieses Aufrufs.\n- Die inneren Prozeduren `Pixi_GetNextInvNr`, `Pixi_CA_AddPixiInvoice`, `Pixi_AddDataForSEPAExportToInvoice` und `Pixi_MQ_EventPublish` liegen nicht vor. Ihre genauen Auswirkungen, etwa Kundenkontobuchungen und das MQ-Event, sind hier nicht dokumentiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiManualCreditCreate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n Credit created\n \n"
}
]
},
{
"name": "pixiReadInvlines",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungspositionen, entweder eine einzelne Position per Schlüssel oder eine nach Anlage- und/oder Änderungsdatum gefilterte Liste mit schlüsselbasiertem Paging.\n\nLiest Rechnungspositionen aus `Invlines`. Jede Position wird mit ihrer Rechnung (`Invoices`) und der Rechnungswährung (`pixi.Currency`) verknüpft. Es wird nur ein Filtermodus verwendet. Die Prozedur prüft die Modi in dieser Reihenfolge:\n\n1. **Anlage- oder Änderungsdatum**: `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` ist gesetzt. Eine Position passt, wenn `CreateDate` **oder** `UpdateDate` `>=` dem Von-Wert ist und `CreateDate` **oder** `UpdateDate` `<` dem Bis-Wert ist.\n2. **Anlagedatum**: `CreateDateFrom` oder `CreateDateTo` ist gesetzt. Gefiltert wird auf `CreateDate` (Von inklusive, Bis exklusive).\n3. **Änderungsdatum**: `UpdateDateFrom` oder `UpdateDateTo` ist gesetzt. Gefiltert wird auf `UpdateDate` (Von inklusive, Bis exklusive).\n4. **Schlüsselbereich**: `RowCount` wird übergeben (beliebiger Wert ungleich NULL). Liefert alle Positionen mit `InvLineKey` größer als `InvlineKey`.\n5. **Einzelner Schlüssel**: Keiner der obigen Fälle trifft zu. Liefert die Position, deren `InvLineKey` gleich `InvlineKey` ist.\n\nIn den Modi 1–4 werden nur Positionen mit `InvLineKey` > `InvlineKey` geliefert, aufsteigend sortiert nach `InvLineKey`. `InvlineKey` ist standardmäßig `0`, daher kommen standardmäßig alle Schlüssel in Frage.\n\nEin `RowCount` ungleich 0 begrenzt die Anzahl der Zeilen (`SET ROWCOUNT`). Damit ist Paging möglich: Der zuletzt erhaltene `InvLineKey` wird im nächsten Aufruf als `InvlineKey` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvlineKey` | int | Nein | Schlüssel der Rechnungsposition. NULL wird als `0` behandelt. Im Einzelschlüssel-Modus wird die Position mit genau diesem Schlüssel geliefert. In allen anderen Modi werden nur Positionen mit größerem Schlüssel geliefert (Paging-Cursor). |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `CreateDate`. Wird ignoriert, wenn ein `CreateAndUpdateDate*`-Parameter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusive) für `CreateDate`. Wird ignoriert, wenn ein `CreateAndUpdateDate*`-Parameter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `UpdateDate`. Wird nur verwendet, wenn kein `CreateAndUpdateDate*`- oder `CreateDate*`-Parameter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusive) für `UpdateDate`. Wird nur verwendet, wenn kein `CreateAndUpdateDate*`- oder `CreateDate*`-Parameter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusive): passt, wenn `CreateDate` oder `UpdateDate` an oder nach diesem Wert liegt. Hat die höchste Priorität unter den Datumsfiltern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (exklusive): passt, wenn `CreateDate` oder `UpdateDate` vor diesem Wert liegt. |\n| `RowCount` | int | Nein | Maximale Anzahl zu liefernder Zeilen. `0` oder NULL bedeutet keine Begrenzung. Jeder Wert ungleich NULL (auch `0`) ohne Datumsfilter schaltet in den Schlüsselbereich-Modus. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`. Es können nicht festgeschriebene Daten geliefert werden.\n- Positionen werden nur geliefert, wenn ihre Rechnung existiert und die `CurrencyId` der Rechnung auf eine Währung verweist (Inner Joins).\n- Ein Aufruf ohne Parameter liefert keine Zeilen: `InvlineKey` wird zu `0`, und der Einzelschlüssel-Modus sucht nach Schlüssel `0`.\n- Die Übergabe von `RowCount` = `0` schaltet in den Schlüsselbereich-Modus ohne Zeilenbegrenzung. Damit werden **alle** Rechnungspositionen oberhalb von `InvlineKey` geliefert.\n- Die Datumsfilter-Modi schließen sich gegenseitig aus. Ist zum Beispiel `CreateAndUpdateDate*` gesetzt, werden die Parameter `CreateDate*` und `UpdateDate*` ignoriert.\n- Im kombinierten Datumsmodus werden Von und Bis unabhängig voneinander gegen eines der beiden Datumsfelder geprüft. Eine Position kann daher auch passen, wenn keines der beiden Datumsfelder im Bereich liegt.\n- `ItemPrice_OrderCurr` und `ShipCost_OrderCurr` sind Kopien von `ItemPrice` und `ShipCost`. Kommentare im Code markieren sie zur Entfernung, neue Integrationen sollten sich daher nicht auf sie stützen.\n- Der letzte Ausweichzweig im Code (leeres Ergebnis) wird nie erreicht, da `InvlineKey` an dieser Stelle nie NULL ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadInvlines"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungspositionen, entweder eine einzelne Position per Schlüssel oder eine nach Anlage- und/oder Änderungsdatum gefilterte Liste mit schlüsselbasiertem Paging.\n\nLiest Rechnungspositionen aus `Invlines`. Jede Position wird mit ihrer Rechnung (`Invoices`) und der Rechnungswährung (`pixi.Currency`) verknüpft. Es wird nur ein Filtermodus verwendet. Die Prozedur prüft die Modi in dieser Reihenfolge:\n\n1. **Anlage- oder Änderungsdatum**: `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` ist gesetzt. Eine Position passt, wenn `CreateDate` **oder** `UpdateDate` `>=` dem Von-Wert ist und `CreateDate` **oder** `UpdateDate` `<` dem Bis-Wert ist.\n2. **Anlagedatum**: `CreateDateFrom` oder `CreateDateTo` ist gesetzt. Gefiltert wird auf `CreateDate` (Von inklusive, Bis exklusive).\n3. **Änderungsdatum**: `UpdateDateFrom` oder `UpdateDateTo` ist gesetzt. Gefiltert wird auf `UpdateDate` (Von inklusive, Bis exklusive).\n4. **Schlüsselbereich**: `RowCount` wird übergeben (beliebiger Wert ungleich NULL). Liefert alle Positionen mit `InvLineKey` größer als `InvlineKey`.\n5. **Einzelner Schlüssel**: Keiner der obigen Fälle trifft zu. Liefert die Position, deren `InvLineKey` gleich `InvlineKey` ist.\n\nIn den Modi 1–4 werden nur Positionen mit `InvLineKey` > `InvlineKey` geliefert, aufsteigend sortiert nach `InvLineKey`. `InvlineKey` ist standardmäßig `0`, daher kommen standardmäßig alle Schlüssel in Frage.\n\nEin `RowCount` ungleich 0 begrenzt die Anzahl der Zeilen (`SET ROWCOUNT`). Damit ist Paging möglich: Der zuletzt erhaltene `InvLineKey` wird im nächsten Aufruf als `InvlineKey` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvlineKey` | int | Nein | Schlüssel der Rechnungsposition. NULL wird als `0` behandelt. Im Einzelschlüssel-Modus wird die Position mit genau diesem Schlüssel geliefert. In allen anderen Modi werden nur Positionen mit größerem Schlüssel geliefert (Paging-Cursor). |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `CreateDate`. Wird ignoriert, wenn ein `CreateAndUpdateDate*`-Parameter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusive) für `CreateDate`. Wird ignoriert, wenn ein `CreateAndUpdateDate*`-Parameter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `UpdateDate`. Wird nur verwendet, wenn kein `CreateAndUpdateDate*`- oder `CreateDate*`-Parameter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusive) für `UpdateDate`. Wird nur verwendet, wenn kein `CreateAndUpdateDate*`- oder `CreateDate*`-Parameter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusive): passt, wenn `CreateDate` oder `UpdateDate` an oder nach diesem Wert liegt. Hat die höchste Priorität unter den Datumsfiltern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (exklusive): passt, wenn `CreateDate` oder `UpdateDate` vor diesem Wert liegt. |\n| `RowCount` | int | Nein | Maximale Anzahl zu liefernder Zeilen. `0` oder NULL bedeutet keine Begrenzung. Jeder Wert ungleich NULL (auch `0`) ohne Datumsfilter schaltet in den Schlüsselbereich-Modus. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`. Es können nicht festgeschriebene Daten geliefert werden.\n- Positionen werden nur geliefert, wenn ihre Rechnung existiert und die `CurrencyId` der Rechnung auf eine Währung verweist (Inner Joins).\n- Ein Aufruf ohne Parameter liefert keine Zeilen: `InvlineKey` wird zu `0`, und der Einzelschlüssel-Modus sucht nach Schlüssel `0`.\n- Die Übergabe von `RowCount` = `0` schaltet in den Schlüsselbereich-Modus ohne Zeilenbegrenzung. Damit werden **alle** Rechnungspositionen oberhalb von `InvlineKey` geliefert.\n- Die Datumsfilter-Modi schließen sich gegenseitig aus. Ist zum Beispiel `CreateAndUpdateDate*` gesetzt, werden die Parameter `CreateDate*` und `UpdateDate*` ignoriert.\n- Im kombinierten Datumsmodus werden Von und Bis unabhängig voneinander gegen eines der beiden Datumsfelder geprüft. Eine Position kann daher auch passen, wenn keines der beiden Datumsfelder im Bereich liegt.\n- `ItemPrice_OrderCurr` und `ShipCost_OrderCurr` sind Kopien von `ItemPrice` und `ShipCost`. Kommentare im Code markieren sie zur Entfernung, neue Integrationen sollten sich daher nicht auf sie stützen.\n- Der letzte Ausweichzweig im Code (leeres Ergebnis) wird nie erreicht, da `InvlineKey` an dieser Stelle nie NULL ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadInvlines"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10234\n 5120\n 88412\n 3307\n 4410\n ART-1001\n 2\n 2\n T-Shirt blau, Gr. M\n 19.99\n 0\n 19\n 2024-01-15T10:22:05\n API\n 2024-01-15T10:22:05\n API\n 19.99\n 4.90\n 0\n EUR\n 4.90\n 1201\n N\n \n 19.99\n 0\n 0\n \n"
}
]
},
{
"name": "pixiReadInvoices",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungsköpfe aus Pixi, gefiltert nach Rechnungsschlüssel oder -nummer, Erstell- und/oder Änderungsdatum oder als nach Schlüssel sortierte Seite.\n\nLiest Rechnungsköpfe aus `Invoices`. Der Währungscode stammt aus `pixi.Currency`, die Mahndaten aus der Mahnung mit der höchsten Stufe pro Rechnung in `Reminders`. Alle Modi liefern dieselben Spalten, sortiert nach `InvoiceKey` aufsteigend.\n\nIst `RowCount` auf einen Wert ungleich 0 gesetzt, wird die Anzahl der gelieferten Zeilen darauf begrenzt. Ein fehlender `InvoiceKey` wird als `0` behandelt.\n\nVerwendet wird der erste zutreffende Modus:\n\n1. **Erstell- oder Änderungsdatum**: `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` ist gesetzt. Liefert Rechnungen mit `InvoiceKey` > `InvoiceKey`, deren `CreateDate` **oder** `UpdateDate` zwischen beiden Werten liegt. Beide Grenzen sind inklusive (`BETWEEN`).\n2. **Erstelldatum**: `CreateDateFrom` oder `CreateDateTo` ist gesetzt. Liefert Rechnungen mit `InvoiceKey` > `InvoiceKey` und `CreateDate` >= Von und < Bis. Jede Grenze kann entfallen.\n3. **Änderungsdatum**: `UpdateDateFrom` oder `UpdateDateTo` ist gesetzt. Gleiche Logik auf `UpdateDate`.\n4. **Schlüsselbereich / Paging**: `RowCount` wird übergeben. Liefert Rechnungen mit `InvoiceKey` größer als der übergebene `InvoiceKey`. Für das Paging wird der zuletzt erhaltene Schlüssel als nächster `InvoiceKey` übergeben.\n5. **Einzelne Rechnung**: Andernfalls werden die Rechnungen mit `InvoiceKey` = `InvoiceKey` **oder** `InvoiceNr` = `InvoiceNr` geliefert.\n\nIn den Modi 1–3 gilt zusätzlich die Schlüsselbedingung. Datumsfilter lassen sich daher mit `InvoiceKey` und `RowCount` für Keyset-Paging kombinieren. `InvoiceNr` wird nur in Modus 5 ausgewertet.\n\nDie Spalte `ReminderLevel` liefert die höchste `HighestReminderLevel` aus `Reminders` zur Rechnung, `ReminderCosts` die Kosten dieser Mahnung. Gibt es keine solche Mahnung, werden die Werte aus der Rechnung selbst verwendet. `VoucherSum_OrderCurr` ist bei `OrderType` `B2C` die Brutto-Gutscheinsumme, sonst die Netto-Gutscheinsumme.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceKey` | int | Nein | Rechnungsschlüssel. In Modus 5 wird diese Rechnung gewählt. In allen anderen Modi werden nur Rechnungen mit größerem Schlüssel geliefert (Paging-Start). NULL wird als 0 behandelt. |\n| `InvoiceNr` | varchar(20) | Nein | Zu suchende Rechnungsnummer. Wird nur in Modus 5 ausgewertet, also ohne Datumsfilter und ohne `RowCount`. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `CreateDate`. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `CreateDate`. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `UpdateDate`. Wird nur ohne Erstelldatumsfilter ausgewertet. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `UpdateDate`. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für Rechnungen, die im Zeitraum erstellt oder geändert wurden. Hat Vorrang vor allen anderen Filtern. Zusammen mit `CreateAndUpdateDateTo` übergeben. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (inklusive) für Rechnungen, die im Zeitraum erstellt oder geändert wurden. |\n| `RowCount` | int | Nein | Maximale Anzahl Zeilen (0 oder NULL = keine Begrenzung). Wird der Wert übergeben, aktiviert er ohne Datumsfilter zusätzlich den Schlüsselbereichsmodus. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, es können also nicht festgeschriebene Daten geliefert werden.\n- Rechnungen ohne passenden Datensatz in `pixi.Currency` (Inner Join über `CurrencyId`) werden nie geliefert.\n- Falle in Modus 1: Wird nur einer der Werte `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo` übergeben, ist die ODER-Bedingung immer erfüllt. Dann werden alle Rechnungen oberhalb von `InvoiceKey` geliefert. Daher immer beide Grenzen übergeben.\n- Falle in Modus 4: `InvoiceKey` zusammen mit `RowCount` liefert die Rechnungen **nach** diesem Schlüssel, nicht die Rechnung selbst. `InvoiceNr` wird ignoriert, sobald `RowCount` oder ein Datumsfilter übergeben wird.\n- `RowCount` = 0 wählt ebenfalls Modus 4, jedoch ohne Zeilenbegrenzung. Dadurch können alle Rechnungen geliefert werden.\n- Ohne Parameter sucht Modus 5 nach `InvoiceKey` = 0 und liefert normalerweise ein leeres Ergebnis. Der letzte Fallback-Zweig (`WHERE 1 = 0`) wird nie erreicht.\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`.\n- Die Spalten `Total_OrderCurr`, `Total_ShipCost_OrderCurr`, `VATBaseHigh_OrderCurr`, `VATBaseLow_OrderCurr`, `VATHigh_OrderCurr`, `VATLow_OrderCurr`, `VATBaseHigh_ShipCost_OrderCurr` und `VATBaseLow_ShipCost_OrderCurr` sind nur Kopien anderer Spalten. Kommentare im Code markieren sie zur Entfernung, daher sollten sie nicht verwendet werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadInvoices"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungsköpfe aus Pixi, gefiltert nach Rechnungsschlüssel oder -nummer, Erstell- und/oder Änderungsdatum oder als nach Schlüssel sortierte Seite.\n\nLiest Rechnungsköpfe aus `Invoices`. Der Währungscode stammt aus `pixi.Currency`, die Mahndaten aus der Mahnung mit der höchsten Stufe pro Rechnung in `Reminders`. Alle Modi liefern dieselben Spalten, sortiert nach `InvoiceKey` aufsteigend.\n\nIst `RowCount` auf einen Wert ungleich 0 gesetzt, wird die Anzahl der gelieferten Zeilen darauf begrenzt. Ein fehlender `InvoiceKey` wird als `0` behandelt.\n\nVerwendet wird der erste zutreffende Modus:\n\n1. **Erstell- oder Änderungsdatum**: `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` ist gesetzt. Liefert Rechnungen mit `InvoiceKey` > `InvoiceKey`, deren `CreateDate` **oder** `UpdateDate` zwischen beiden Werten liegt. Beide Grenzen sind inklusive (`BETWEEN`).\n2. **Erstelldatum**: `CreateDateFrom` oder `CreateDateTo` ist gesetzt. Liefert Rechnungen mit `InvoiceKey` > `InvoiceKey` und `CreateDate` >= Von und < Bis. Jede Grenze kann entfallen.\n3. **Änderungsdatum**: `UpdateDateFrom` oder `UpdateDateTo` ist gesetzt. Gleiche Logik auf `UpdateDate`.\n4. **Schlüsselbereich / Paging**: `RowCount` wird übergeben. Liefert Rechnungen mit `InvoiceKey` größer als der übergebene `InvoiceKey`. Für das Paging wird der zuletzt erhaltene Schlüssel als nächster `InvoiceKey` übergeben.\n5. **Einzelne Rechnung**: Andernfalls werden die Rechnungen mit `InvoiceKey` = `InvoiceKey` **oder** `InvoiceNr` = `InvoiceNr` geliefert.\n\nIn den Modi 1–3 gilt zusätzlich die Schlüsselbedingung. Datumsfilter lassen sich daher mit `InvoiceKey` und `RowCount` für Keyset-Paging kombinieren. `InvoiceNr` wird nur in Modus 5 ausgewertet.\n\nDie Spalte `ReminderLevel` liefert die höchste `HighestReminderLevel` aus `Reminders` zur Rechnung, `ReminderCosts` die Kosten dieser Mahnung. Gibt es keine solche Mahnung, werden die Werte aus der Rechnung selbst verwendet. `VoucherSum_OrderCurr` ist bei `OrderType` `B2C` die Brutto-Gutscheinsumme, sonst die Netto-Gutscheinsumme.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceKey` | int | Nein | Rechnungsschlüssel. In Modus 5 wird diese Rechnung gewählt. In allen anderen Modi werden nur Rechnungen mit größerem Schlüssel geliefert (Paging-Start). NULL wird als 0 behandelt. |\n| `InvoiceNr` | varchar(20) | Nein | Zu suchende Rechnungsnummer. Wird nur in Modus 5 ausgewertet, also ohne Datumsfilter und ohne `RowCount`. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `CreateDate`. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `CreateDate`. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `UpdateDate`. Wird nur ohne Erstelldatumsfilter ausgewertet. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `UpdateDate`. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für Rechnungen, die im Zeitraum erstellt oder geändert wurden. Hat Vorrang vor allen anderen Filtern. Zusammen mit `CreateAndUpdateDateTo` übergeben. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (inklusive) für Rechnungen, die im Zeitraum erstellt oder geändert wurden. |\n| `RowCount` | int | Nein | Maximale Anzahl Zeilen (0 oder NULL = keine Begrenzung). Wird der Wert übergeben, aktiviert er ohne Datumsfilter zusätzlich den Schlüsselbereichsmodus. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, es können also nicht festgeschriebene Daten geliefert werden.\n- Rechnungen ohne passenden Datensatz in `pixi.Currency` (Inner Join über `CurrencyId`) werden nie geliefert.\n- Falle in Modus 1: Wird nur einer der Werte `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo` übergeben, ist die ODER-Bedingung immer erfüllt. Dann werden alle Rechnungen oberhalb von `InvoiceKey` geliefert. Daher immer beide Grenzen übergeben.\n- Falle in Modus 4: `InvoiceKey` zusammen mit `RowCount` liefert die Rechnungen **nach** diesem Schlüssel, nicht die Rechnung selbst. `InvoiceNr` wird ignoriert, sobald `RowCount` oder ein Datumsfilter übergeben wird.\n- `RowCount` = 0 wählt ebenfalls Modus 4, jedoch ohne Zeilenbegrenzung. Dadurch können alle Rechnungen geliefert werden.\n- Ohne Parameter sucht Modus 5 nach `InvoiceKey` = 0 und liefert normalerweise ein leeres Ergebnis. Der letzte Fallback-Zweig (`WHERE 1 = 0`) wird nie erreicht.\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`.\n- Die Spalten `Total_OrderCurr`, `Total_ShipCost_OrderCurr`, `VATBaseHigh_OrderCurr`, `VATBaseLow_OrderCurr`, `VATHigh_OrderCurr`, `VATLow_OrderCurr`, `VATBaseHigh_ShipCost_OrderCurr` und `VATBaseLow_ShipCost_OrderCurr` sind nur Kopien anderer Spalten. Kommentare im Code markieren sie zur Entfernung, daher sollten sie nicht verwendet werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadInvoices"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10501\n RE2024-001235\n 2024-05-02T10:15:00\n 4711\n 119.00\n 100.00\n 19.00\n 19.00\n EUR\n 2024-05-02T10:15:00\n 2024-05-03T08:00:00\n 0\n SHOP1\n \n"
}
]
},
{
"name": "pixiReadPOSHeader",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kopfdaten von POS-Belegen (Kassenbelegen) aus POSheader2, entweder einen einzelnen Beleg per Schlüssel oder eine nach Anlage-/Änderungsdatum gefilterte Liste mit Paging über den Schlüssel.\n\nLiest Kopfdatensätze von POS-Belegen aus der Tabelle `POSheader2`. Alle Zweige liefern dieselben Spalten. Wird `POSHeaderKey` nicht übergeben, gilt der Wert `0`.\n\nIst `RowCount` ungleich `0`, wird die Anzahl der gelieferten Zeilen per `SET ROWCOUNT` begrenzt.\n\nDie Parameter werden in dieser Reihenfolge ausgewertet; es wird nur der erste passende Zweig ausgeführt:\n\n1. **Anlage- oder Änderungsdatum** – wenn `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` gesetzt ist: Belege mit `POSheaderKey > POSHeaderKey`, bei denen `PHcreateDate` oder `PHupdateDate` `>= CreateAndUpdateDateFrom` ist und `PHcreateDate` oder `PHupdateDate` `< CreateAndUpdateDateTo` ist.\n2. **Anlagedatum** – wenn `CreateDateFrom` oder `CreateDateTo` gesetzt ist: Belege mit `POSheaderKey > POSHeaderKey` und `PHcreateDate` im Bereich `[CreateDateFrom, CreateDateTo)`.\n3. **Änderungsdatum** – wenn `UpdateDateFrom` oder `UpdateDateTo` gesetzt ist: Belege mit `POSheaderKey > POSHeaderKey` und `PHupdateDate` im Bereich `[UpdateDateFrom, UpdateDateTo)`.\n4. **Schlüsselbereich** – wenn `RowCount` übergeben wird (nicht NULL): Belege mit `POSheaderKey > POSHeaderKey`.\n5. **Einzelner Beleg** – sonst: der Beleg mit `POSheaderKey = POSHeaderKey`.\n\nDie Zweige 1–4 sind nach `POSheaderKey` aufsteigend sortiert. Für Paging wird der zuletzt erhaltene `POSheaderKey` im nächsten Aufruf als `POSHeaderKey` zusammen mit `RowCount` übergeben.\n\nUntere Datumsgrenzen sind inklusiv, obere exklusiv. Fehlt eine Grenze, ist diese Seite offen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `POSHeaderKey` | int | Nein | Schlüssel des POS-Belegkopfs. Exakter Treffer im Einzelmodus; exklusive Untergrenze (`>`) für Paging in den Datums- und Schlüsselbereichsmodi. NULL wird als `0` behandelt. |\n| `CreateDateFrom` | datetime | Nein | Inklusive Untergrenze für `PHcreateDate`. |\n| `CreateDateTo` | datetime | Nein | Exklusive Obergrenze für `PHcreateDate`. |\n| `UpdateDateFrom` | datetime | Nein | Inklusive Untergrenze für `PHupdateDate`. Wird ignoriert, wenn ein Anlagedatums- oder kombinierter Filter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Exklusive Obergrenze für `PHupdateDate`. Wird ignoriert, wenn ein Anlagedatums- oder kombinierter Filter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Inklusive Untergrenze, geprüft gegen `PHcreateDate` oder `PHupdateDate`. Hat Vorrang vor allen anderen Datumsfiltern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Exklusive Obergrenze, geprüft gegen `PHcreateDate` oder `PHupdateDate`. |\n| `RowCount` | int | Nein | Maximale Anzahl Zeilen (per `SET ROWCOUNT`); `0` oder NULL bedeutet keine Begrenzung. Wird der Parameter ohne Datumsfilter übergeben, wird in den Schlüsselbereichsmodus (`POSheaderKey > POSHeaderKey`) gewechselt. |\n\n- Die Tabelle wird `WITH (NOLOCK)` gelesen; nicht festgeschriebene Daten können geliefert werden.\n- In den Datumszweigen ist `POSHeaderKey` eine Untergrenze (`>`), kein exakter Treffer. Wird ein bestimmter Schlüssel zusammen mit einem Datumsfilter übergeben, wird dieser Beleg selbst nicht geliefert.\n- Beim kombinierten Anlage-/Änderungsfilter werden beide Grenzen unabhängig geprüft: Eine Zeile passt, wenn eines der beiden Daten `>=` der Untergrenze und eines der beiden Daten `<` der Obergrenze ist – nicht zwingend dasselbe Datum.\n- Ein Aufruf ohne Parameter liefert keine Zeilen (gesucht wird `POSheaderKey = 0`).\n- Wird `RowCount = 0` ausdrücklich übergeben, greift der Schlüsselbereichs-Zweig ohne Zeilenbegrenzung, d. h. alle Belege mit einem Schlüssel größer `POSHeaderKey` werden geliefert.\n- Die Datentypen der Spalten sind im Code nicht sichtbar; sie stammen aus der Tabelle `POSheader2`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadPOSHeader"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kopfdaten von POS-Belegen (Kassenbelegen) aus POSheader2, entweder einen einzelnen Beleg per Schlüssel oder eine nach Anlage-/Änderungsdatum gefilterte Liste mit Paging über den Schlüssel.\n\nLiest Kopfdatensätze von POS-Belegen aus der Tabelle `POSheader2`. Alle Zweige liefern dieselben Spalten. Wird `POSHeaderKey` nicht übergeben, gilt der Wert `0`.\n\nIst `RowCount` ungleich `0`, wird die Anzahl der gelieferten Zeilen per `SET ROWCOUNT` begrenzt.\n\nDie Parameter werden in dieser Reihenfolge ausgewertet; es wird nur der erste passende Zweig ausgeführt:\n\n1. **Anlage- oder Änderungsdatum** – wenn `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` gesetzt ist: Belege mit `POSheaderKey > POSHeaderKey`, bei denen `PHcreateDate` oder `PHupdateDate` `>= CreateAndUpdateDateFrom` ist und `PHcreateDate` oder `PHupdateDate` `< CreateAndUpdateDateTo` ist.\n2. **Anlagedatum** – wenn `CreateDateFrom` oder `CreateDateTo` gesetzt ist: Belege mit `POSheaderKey > POSHeaderKey` und `PHcreateDate` im Bereich `[CreateDateFrom, CreateDateTo)`.\n3. **Änderungsdatum** – wenn `UpdateDateFrom` oder `UpdateDateTo` gesetzt ist: Belege mit `POSheaderKey > POSHeaderKey` und `PHupdateDate` im Bereich `[UpdateDateFrom, UpdateDateTo)`.\n4. **Schlüsselbereich** – wenn `RowCount` übergeben wird (nicht NULL): Belege mit `POSheaderKey > POSHeaderKey`.\n5. **Einzelner Beleg** – sonst: der Beleg mit `POSheaderKey = POSHeaderKey`.\n\nDie Zweige 1–4 sind nach `POSheaderKey` aufsteigend sortiert. Für Paging wird der zuletzt erhaltene `POSheaderKey` im nächsten Aufruf als `POSHeaderKey` zusammen mit `RowCount` übergeben.\n\nUntere Datumsgrenzen sind inklusiv, obere exklusiv. Fehlt eine Grenze, ist diese Seite offen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `POSHeaderKey` | int | Nein | Schlüssel des POS-Belegkopfs. Exakter Treffer im Einzelmodus; exklusive Untergrenze (`>`) für Paging in den Datums- und Schlüsselbereichsmodi. NULL wird als `0` behandelt. |\n| `CreateDateFrom` | datetime | Nein | Inklusive Untergrenze für `PHcreateDate`. |\n| `CreateDateTo` | datetime | Nein | Exklusive Obergrenze für `PHcreateDate`. |\n| `UpdateDateFrom` | datetime | Nein | Inklusive Untergrenze für `PHupdateDate`. Wird ignoriert, wenn ein Anlagedatums- oder kombinierter Filter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Exklusive Obergrenze für `PHupdateDate`. Wird ignoriert, wenn ein Anlagedatums- oder kombinierter Filter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Inklusive Untergrenze, geprüft gegen `PHcreateDate` oder `PHupdateDate`. Hat Vorrang vor allen anderen Datumsfiltern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Exklusive Obergrenze, geprüft gegen `PHcreateDate` oder `PHupdateDate`. |\n| `RowCount` | int | Nein | Maximale Anzahl Zeilen (per `SET ROWCOUNT`); `0` oder NULL bedeutet keine Begrenzung. Wird der Parameter ohne Datumsfilter übergeben, wird in den Schlüsselbereichsmodus (`POSheaderKey > POSHeaderKey`) gewechselt. |\n\n- Die Tabelle wird `WITH (NOLOCK)` gelesen; nicht festgeschriebene Daten können geliefert werden.\n- In den Datumszweigen ist `POSHeaderKey` eine Untergrenze (`>`), kein exakter Treffer. Wird ein bestimmter Schlüssel zusammen mit einem Datumsfilter übergeben, wird dieser Beleg selbst nicht geliefert.\n- Beim kombinierten Anlage-/Änderungsfilter werden beide Grenzen unabhängig geprüft: Eine Zeile passt, wenn eines der beiden Daten `>=` der Untergrenze und eines der beiden Daten `<` der Obergrenze ist – nicht zwingend dasselbe Datum.\n- Ein Aufruf ohne Parameter liefert keine Zeilen (gesucht wird `POSheaderKey = 0`).\n- Wird `RowCount = 0` ausdrücklich übergeben, greift der Schlüsselbereichs-Zweig ohne Zeilenbegrenzung, d. h. alle Belege mit einem Schlüssel größer `POSHeaderKey` werden geliefert.\n- Die Datentypen der Spalten sind im Code nicht sichtbar; sie stammen aus der Tabelle `POSheader2`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadPOSHeader"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10453\n MK\n 2024-03-15T10:24:11\n MK\n 2024-03-15T10:25:02\n 2024-03-15T10:24:11\n K-2024-001873\n R\n BAR\n 1\n C\n Max Mustermann\n 80331\n München\n DE\n 59.90\n 59.90\n 001\n 9.56\n KASSE1\n 50.34\n 0\n 0.00\n 0.00\n 9.56\n \n"
}
]
},
{
"name": "pixiReportInvlines",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n 2024-03-01T00:00:00\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungspositionen in einem Datumsbereich, optional gefiltert nach Shop, Zahlungsart, Lieferant, Kategorie, EAN und interner Artikelnummer.\n\nLiest Rechnungspositionen aus der View `PV_Invlines` und ergänzt den Währungscode des Auftrags über die Tabellen für Wechselkurse (`pixi.ExchRate`) und Währungen (`pixi.Currency`).\n\nAblauf:\n\n1. Die Anzahl der gelieferten Zeilen wird auf `Rowcount` begrenzt (Standard 1000).\n2. `DateFrom` wird auf den Tagesbeginn (00:00:00) gesetzt.\n3. Ist `DateTo` leer oder `NULL`, gilt das aktuelle Datum mit Uhrzeit. Andernfalls wird `DateTo` auf das Tagesende (23:59:59.997) gesetzt.\n4. Leere Zeichenketten in den optionalen Filterparametern werden wie `NULL` behandelt; der Filter entfällt dann.\n5. Geliefert werden nur Rechnungspositionen, deren Rechnungsdatum zwischen `DateFrom` und `DateTo` liegt. Die folgenden optionalen Filter werden mit UND verknüpft:\n - `ShopID`: `ShopID LIKE @ShopID`\n - `PaymentType`: exakter Vergleich mit `PaymentType`\n - `SupplNr`: Für den Artikel muss in `AddItems` ein Eintrag mit diesem Lieferanten existieren. Jeder dem Artikel zugeordnete Lieferant zählt, nicht nur der Lieferant der Rechnungsposition.\n - `Category`: Der Kategorietext wird in `TontrArten.TontrText` gesucht. Die zugehörige `TontrArt` wird per `LIKE` mit dem `configtype` der Position verglichen.\n - `EAN`: `EANUPC LIKE @EAN`\n - `ItemNrInt`: `ItemNrInt LIKE @ItemNrInt`\n\nDer Code enthält kein `ORDER BY`; die Reihenfolge der Zeilen ist daher nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Rowcount` | int | Nein | Maximale Anzahl gelieferter Zeilen; 0 bedeutet keine Begrenzung. |\n| `DateFrom` | datetime | Ja | Beginn des Rechnungsdatumsbereichs. Die Uhrzeit wird auf den Tagesbeginn gesetzt. |\n| `DateTo` | datetime | Nein | Ende des Rechnungsdatumsbereichs, wird auf das Tagesende gesetzt. Ist der Wert leer, gilt das aktuelle Datum mit Uhrzeit. |\n| `ShopID` | varchar(3) | Nein | Filter auf die Shop-ID, Vergleich per LIKE. Leer bedeutet alle Shops. |\n| `PaymentType` | char(1) | Nein | Filter auf die Zahlungsart der Rechnung (exakter Vergleich). Leer bedeutet alle Zahlungsarten. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Liefert nur Positionen von Artikeln, denen dieser Lieferant in `AddItems` zugeordnet ist. |\n| `Category` | varchar(50) | Nein | Kategorietext wie in `TontrArten.TontrText` hinterlegt. Er wird in den Kategoriecode übersetzt und mit dem `configtype` der Position verglichen. |\n| `EAN` | varchar(13) | Nein | Filter auf die EAN/UPC des Artikels, Vergleich per LIKE. |\n| `ItemNrInt` | varchar(50) | Nein | Filter auf die interne Artikelnummer, Vergleich per LIKE. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen. Nicht festgeschriebene Daten können im Ergebnis erscheinen.\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`. `Rowcount` = 0 hebt die Begrenzung auf.\n- `ShopID`, `EAN` und `ItemNrInt` werden per `LIKE` verglichen; Platzhalter wie `%` und `_` sind möglich.\n- Wird der Text von `Category` in `TontrArten` nicht gefunden, werden keine Zeilen geliefert. Kommt der Text mehrfach vor, liefert die Unterabfrage mehrere Werte und SQL Server meldet einen Fehler.\n- Ohne `DateTo` endet der Zeitraum zum aktuellen Zeitpunkt, nicht am Ende des aktuellen Tages.\n- Rechnungspositionen ohne passenden Wechselkurs oder ohne passende Währung werden durch die Inner Joins ausgeschlossen.\n- `InvDate` wird als Zeichenkette im Format `yyyy-mm-dd hh:mi:ss` geliefert.\n- Der Kopfkommentar der Prozedur ist ein allgemeiner Vorlagentext und beschreibt diesen Aufruf nicht.\n- `PV_Invlines` ist eine View, deren Definition nicht beigefügt ist. Die Datentypen der meisten Spalten lassen sich daher nicht ableiten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportInvlines"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n 2024-03-01T00:00:00\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungspositionen in einem Datumsbereich, optional gefiltert nach Shop, Zahlungsart, Lieferant, Kategorie, EAN und interner Artikelnummer.\n\nLiest Rechnungspositionen aus der View `PV_Invlines` und ergänzt den Währungscode des Auftrags über die Tabellen für Wechselkurse (`pixi.ExchRate`) und Währungen (`pixi.Currency`).\n\nAblauf:\n\n1. Die Anzahl der gelieferten Zeilen wird auf `Rowcount` begrenzt (Standard 1000).\n2. `DateFrom` wird auf den Tagesbeginn (00:00:00) gesetzt.\n3. Ist `DateTo` leer oder `NULL`, gilt das aktuelle Datum mit Uhrzeit. Andernfalls wird `DateTo` auf das Tagesende (23:59:59.997) gesetzt.\n4. Leere Zeichenketten in den optionalen Filterparametern werden wie `NULL` behandelt; der Filter entfällt dann.\n5. Geliefert werden nur Rechnungspositionen, deren Rechnungsdatum zwischen `DateFrom` und `DateTo` liegt. Die folgenden optionalen Filter werden mit UND verknüpft:\n - `ShopID`: `ShopID LIKE @ShopID`\n - `PaymentType`: exakter Vergleich mit `PaymentType`\n - `SupplNr`: Für den Artikel muss in `AddItems` ein Eintrag mit diesem Lieferanten existieren. Jeder dem Artikel zugeordnete Lieferant zählt, nicht nur der Lieferant der Rechnungsposition.\n - `Category`: Der Kategorietext wird in `TontrArten.TontrText` gesucht. Die zugehörige `TontrArt` wird per `LIKE` mit dem `configtype` der Position verglichen.\n - `EAN`: `EANUPC LIKE @EAN`\n - `ItemNrInt`: `ItemNrInt LIKE @ItemNrInt`\n\nDer Code enthält kein `ORDER BY`; die Reihenfolge der Zeilen ist daher nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Rowcount` | int | Nein | Maximale Anzahl gelieferter Zeilen; 0 bedeutet keine Begrenzung. |\n| `DateFrom` | datetime | Ja | Beginn des Rechnungsdatumsbereichs. Die Uhrzeit wird auf den Tagesbeginn gesetzt. |\n| `DateTo` | datetime | Nein | Ende des Rechnungsdatumsbereichs, wird auf das Tagesende gesetzt. Ist der Wert leer, gilt das aktuelle Datum mit Uhrzeit. |\n| `ShopID` | varchar(3) | Nein | Filter auf die Shop-ID, Vergleich per LIKE. Leer bedeutet alle Shops. |\n| `PaymentType` | char(1) | Nein | Filter auf die Zahlungsart der Rechnung (exakter Vergleich). Leer bedeutet alle Zahlungsarten. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Liefert nur Positionen von Artikeln, denen dieser Lieferant in `AddItems` zugeordnet ist. |\n| `Category` | varchar(50) | Nein | Kategorietext wie in `TontrArten.TontrText` hinterlegt. Er wird in den Kategoriecode übersetzt und mit dem `configtype` der Position verglichen. |\n| `EAN` | varchar(13) | Nein | Filter auf die EAN/UPC des Artikels, Vergleich per LIKE. |\n| `ItemNrInt` | varchar(50) | Nein | Filter auf die interne Artikelnummer, Vergleich per LIKE. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen. Nicht festgeschriebene Daten können im Ergebnis erscheinen.\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`. `Rowcount` = 0 hebt die Begrenzung auf.\n- `ShopID`, `EAN` und `ItemNrInt` werden per `LIKE` verglichen; Platzhalter wie `%` und `_` sind möglich.\n- Wird der Text von `Category` in `TontrArten` nicht gefunden, werden keine Zeilen geliefert. Kommt der Text mehrfach vor, liefert die Unterabfrage mehrere Werte und SQL Server meldet einen Fehler.\n- Ohne `DateTo` endet der Zeitraum zum aktuellen Zeitpunkt, nicht am Ende des aktuellen Tages.\n- Rechnungspositionen ohne passenden Wechselkurs oder ohne passende Währung werden durch die Inner Joins ausgeschlossen.\n- `InvDate` wird als Zeichenkette im Format `yyyy-mm-dd hh:mi:ss` geliefert.\n- Der Kopfkommentar der Prozedur ist ein allgemeiner Vorlagentext und beschreibt diesen Aufruf nicht.\n- `PV_Invlines` ist eine View, deren Definition nicht beigefügt ist. Die Datentypen der meisten Spalten lassen sich daher nicht ableiten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportInvlines"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10045\n 88231\n R2024-001234\n 2024-03-05 14:22:10\n R\n 554120\n ABC\n L001\n Muster GmbH\n USB-Kabel 2m\n 4006381333931\n ART-10045\n MU-778\n Zubehör\n 2\n 2.50\n 9.99\n 8.39\n 19.00\n EUR\n \n"
}
]
},
{
"name": "pixiSendEmailForInvoice",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n ZEB000003\n Your invoice ZEB000003\n Thank you for your order. Please find your invoice attached.\n master\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt für eine Rechnung eine Pixi-Automail vom Typ `API_Invoice_eMail` aus der passenden Mailvorlage an und stellt sie in den Postausgang oder die Entwürfe.\n\nErzeugt über das Pixi-Automail-Modul (AM) eine E-Mail zu einer Rechnung und stellt sie zum Versand bereit. Verwendet wird der Mailtyp `API_Invoice_eMail`.\n\nAblauf:\n\n1. Ein leerer Wert für `InvoiceNr` gilt als nicht angegeben. Fehlende Werte für `Subject` und `Message` werden zu Leerstrings.\n2. `Subject`, `Message` und `InvoiceNr` werden in einer temporären Tabelle abgelegt (`Api_Subject`, `Api_Message`, `InvoiceNr`). Die SQL-Abfrage des Mailtyps kann beim Aufbau der Mail darauf zugreifen.\n3. Der Mailtyp `API_Invoice_eMail` wird in `AM_Type` gesucht und muss aktiviert sein.\n4. Die Rechnung wird aus `Invoices` gelesen und mit ihrer Rechnungsadresse in `Addresses` verknüpft. Daraus ergeben sich Kunde, Shop-ID, Land, Versanddienstleister und Zahlungsart.\n5. Über `fPixi_AM_GetTemplate` wird eine Mailvorlage dieses Typs gewählt. Gesucht wird eine aktive Vorlage, die zu Shop, Land, Zahlungsart und Versanddienstleister passt. Passt keine Vorlage zu allen vier Kriterien, wird schrittweise auf Vorlagen mit weniger Übereinstimmungen und zuletzt auf eine allgemeine Vorlage zurückgegriffen.\n6. `pixi_AM_CreateMailForCSD` erzeugt die Mail: Empfänger, Betreff, Text und Textart.\n7. `Pixi_AM_SendManual` speichert die Mail mit Status `CREATED` in `AM_Mail`. Gegebenenfalls wird das Rechnungsdokument als Anhang hinterlegt.\n8. Der Schlüssel des neuen Mail-Datensatzes wird in der Spalte `AM_TypeKey` zurückgegeben.\n\nSchlägt eine Prüfung fehl, liefert der Aufruf eine Zeile mit `ReturnCode` = `ERROR` und einer `ErrorMsg` und bricht ab.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Ja | Nummer der Rechnung, zu der die Mail erzeugt wird (`Invoices.InvoiceNr`). Ein leerer Wert wird abgelehnt. |\n| `Subject` | varchar(255) | Ja | Betrefftext. Er wird der Abfrage des Mailtyps als `Api_Subject` bereitgestellt. Der endgültige Betreff stammt aus der Vorlage. NULL wird als Leerstring behandelt. |\n| `Message` | varchar(1024) | Ja | Freier Nachrichtentext. Er wird der Abfrage des Mailtyps als `Api_Message` bereitgestellt. NULL wird als Leerstring behandelt. |\n| `UserName` | varchar(50) | Ja | Benutzer, der als Ersteller und letzter Bearbeiter des Mail-Datensatzes gespeichert wird. Werte über 20 Zeichen werden abgeschnitten. |\n\n- Der Aufruf versendet die Mail nicht direkt. Er legt einen Datensatz in `AM_Mail` an, und zwar in Ordner 1 (Postausgang) oder in Ordner 0 (Entwürfe), wenn die Einstellung `PixiMail_ForceManualMode` = `1` ist oder der Mailtyp im manuellen Modus steht. Zusätzlich wird das MQ-Ereignis `MailCreated` veröffentlicht.\n- **Testmodus:** Ist die Einstellung `PixiMail_ForceTestMode` = `1` oder der Testmodus des Mailtyps aktiv, wird der Empfänger durch die Adresse aus der Einstellung `PixiMail_Test_eMail` ersetzt.\n- **Betreff und Nachricht:** Der übergebene `Subject` wird durch den von der Vorlage erzeugten Betreff überschrieben. `Subject` und `Message` erscheinen nur dann in der Mail, wenn die SQL-Abfrage des Mailtyps oder die Vorlage `Api_Subject` / `Api_Message` verwendet. Diese Abfrage ist in `AM_Type.AM_TypeSQLproc` hinterlegt und läuft als dynamisches SQL. Ihr genaues Verhalten ist aus dem Code nicht ersichtlich.\n- Schlägt die dynamische Abfrage fehl, wird der Fehler nur im AM-Log protokolliert und der Aufruf liefert `eMail was not created!`.\n- Liefert die Abfrage keine Zeilen, entsteht eine leere Platzhalter-Mailzeile. Diese wird unter Umständen mit leerem Empfänger gespeichert.\n- **Mailtyp muss auch als Ordner-1-Typ existieren:** `Pixi_AM_SendManual` erwartet den Typ mit `AM_TypeFolder` = 1. Andernfalls wird `Email Type is disabled` ausgelöst. Der Aufrufer erhält dann eine `SqlMessage` und eine Zeile mit `AM_TypeKey` = 0.\n- **Irreführender Spaltenname:** `AM_TypeKey` enthält den Schlüssel der neuen Mail (Identity von `AM_Mail`), nicht den Typschlüssel.\n- **Rechnungsanhang:** Das Rechnungsdokument wird nur dann über `AM_MailAttachment` angehängt, wenn der Mailtyp Anhänge erlaubt, die Vorlage `AttachInvoiceDocument` = 1 hat und ein Anhangspfad ermittelt wird.\n- `AM_MailInvoiceNr` wird im Mail-Datensatz als NULL gespeichert.\n- `UserName` wird an einen Parameter vom Typ `varchar(20)` übergeben; längere Werte werden abgeschnitten.\n- Lesezugriffe erfolgen mit `NOLOCK`. Es wird keine explizite Transaktion verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSendEmailForInvoice"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n ZEB000003\n Your invoice ZEB000003\n Thank you for your order. Please find your invoice attached.\n master\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt für eine Rechnung eine Pixi-Automail vom Typ `API_Invoice_eMail` aus der passenden Mailvorlage an und stellt sie in den Postausgang oder die Entwürfe.\n\nErzeugt über das Pixi-Automail-Modul (AM) eine E-Mail zu einer Rechnung und stellt sie zum Versand bereit. Verwendet wird der Mailtyp `API_Invoice_eMail`.\n\nAblauf:\n\n1. Ein leerer Wert für `InvoiceNr` gilt als nicht angegeben. Fehlende Werte für `Subject` und `Message` werden zu Leerstrings.\n2. `Subject`, `Message` und `InvoiceNr` werden in einer temporären Tabelle abgelegt (`Api_Subject`, `Api_Message`, `InvoiceNr`). Die SQL-Abfrage des Mailtyps kann beim Aufbau der Mail darauf zugreifen.\n3. Der Mailtyp `API_Invoice_eMail` wird in `AM_Type` gesucht und muss aktiviert sein.\n4. Die Rechnung wird aus `Invoices` gelesen und mit ihrer Rechnungsadresse in `Addresses` verknüpft. Daraus ergeben sich Kunde, Shop-ID, Land, Versanddienstleister und Zahlungsart.\n5. Über `fPixi_AM_GetTemplate` wird eine Mailvorlage dieses Typs gewählt. Gesucht wird eine aktive Vorlage, die zu Shop, Land, Zahlungsart und Versanddienstleister passt. Passt keine Vorlage zu allen vier Kriterien, wird schrittweise auf Vorlagen mit weniger Übereinstimmungen und zuletzt auf eine allgemeine Vorlage zurückgegriffen.\n6. `pixi_AM_CreateMailForCSD` erzeugt die Mail: Empfänger, Betreff, Text und Textart.\n7. `Pixi_AM_SendManual` speichert die Mail mit Status `CREATED` in `AM_Mail`. Gegebenenfalls wird das Rechnungsdokument als Anhang hinterlegt.\n8. Der Schlüssel des neuen Mail-Datensatzes wird in der Spalte `AM_TypeKey` zurückgegeben.\n\nSchlägt eine Prüfung fehl, liefert der Aufruf eine Zeile mit `ReturnCode` = `ERROR` und einer `ErrorMsg` und bricht ab.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Ja | Nummer der Rechnung, zu der die Mail erzeugt wird (`Invoices.InvoiceNr`). Ein leerer Wert wird abgelehnt. |\n| `Subject` | varchar(255) | Ja | Betrefftext. Er wird der Abfrage des Mailtyps als `Api_Subject` bereitgestellt. Der endgültige Betreff stammt aus der Vorlage. NULL wird als Leerstring behandelt. |\n| `Message` | varchar(1024) | Ja | Freier Nachrichtentext. Er wird der Abfrage des Mailtyps als `Api_Message` bereitgestellt. NULL wird als Leerstring behandelt. |\n| `UserName` | varchar(50) | Ja | Benutzer, der als Ersteller und letzter Bearbeiter des Mail-Datensatzes gespeichert wird. Werte über 20 Zeichen werden abgeschnitten. |\n\n- Der Aufruf versendet die Mail nicht direkt. Er legt einen Datensatz in `AM_Mail` an, und zwar in Ordner 1 (Postausgang) oder in Ordner 0 (Entwürfe), wenn die Einstellung `PixiMail_ForceManualMode` = `1` ist oder der Mailtyp im manuellen Modus steht. Zusätzlich wird das MQ-Ereignis `MailCreated` veröffentlicht.\n- **Testmodus:** Ist die Einstellung `PixiMail_ForceTestMode` = `1` oder der Testmodus des Mailtyps aktiv, wird der Empfänger durch die Adresse aus der Einstellung `PixiMail_Test_eMail` ersetzt.\n- **Betreff und Nachricht:** Der übergebene `Subject` wird durch den von der Vorlage erzeugten Betreff überschrieben. `Subject` und `Message` erscheinen nur dann in der Mail, wenn die SQL-Abfrage des Mailtyps oder die Vorlage `Api_Subject` / `Api_Message` verwendet. Diese Abfrage ist in `AM_Type.AM_TypeSQLproc` hinterlegt und läuft als dynamisches SQL. Ihr genaues Verhalten ist aus dem Code nicht ersichtlich.\n- Schlägt die dynamische Abfrage fehl, wird der Fehler nur im AM-Log protokolliert und der Aufruf liefert `eMail was not created!`.\n- Liefert die Abfrage keine Zeilen, entsteht eine leere Platzhalter-Mailzeile. Diese wird unter Umständen mit leerem Empfänger gespeichert.\n- **Mailtyp muss auch als Ordner-1-Typ existieren:** `Pixi_AM_SendManual` erwartet den Typ mit `AM_TypeFolder` = 1. Andernfalls wird `Email Type is disabled` ausgelöst. Der Aufrufer erhält dann eine `SqlMessage` und eine Zeile mit `AM_TypeKey` = 0.\n- **Irreführender Spaltenname:** `AM_TypeKey` enthält den Schlüssel der neuen Mail (Identity von `AM_Mail`), nicht den Typschlüssel.\n- **Rechnungsanhang:** Das Rechnungsdokument wird nur dann über `AM_MailAttachment` angehängt, wenn der Mailtyp Anhänge erlaubt, die Vorlage `AttachInvoiceDocument` = 1 hat und ein Anhangspfad ermittelt wird.\n- `AM_MailInvoiceNr` wird im Mail-Datensatz als NULL gespeichert.\n- `UserName` wird an einen Parameter vom Typ `varchar(20)` übergeben; längere Werte werden abgeschnitten.\n- Lesezugriffe erfolgen mit `NOLOCK`. Es wird keine explizite Transaktion verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSendEmailForInvoice"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 158342\n \n"
}
]
},
{
"name": "pixiSetInvoicePaid",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE2024001234\n 1\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt eine Rechnung auf bezahlt, indem eine manuelle Buchung im Kundenkonto angelegt und mit dem offenen Rechnungsbetrag ausgeglichen wird.\n\nWrapper um die interne Prozedur `pixi_SetInvoicePaid`. Die Rückgabe ist eine Statuszeile mit `Status` und `Message`.\n\nAblauf der internen Prozedur:\n\n1. Die Rechnung wird über `InvoiceNR` in `Invoices` gesucht. Gelesen werden Kunde, Gesamtbetrag, bezahlte Summe, Währung und Wechselkurs.\n2. Über `Pixi_CA_GetCustomerAccountforInvoice` wird der Kundenkonto-Eintrag der Rechnung ermittelt. Der Buchungsbetrag ist der negierte Wert von `OpenToMatch` dieses Eintrags.\n3. Die Eingaben werden in dieser Reihenfolge geprüft:\n - `paid` muss `1` sein. Das Zurücksetzen auf unbezahlt wird nicht unterstützt.\n - Die Rechnung muss existieren.\n - Die Rechnung darf nicht bereits vollständig bezahlt sein (`total` = `PayedSum`).\n - `eventID` muss angegeben sein.\n - Das Ereignis muss in `CustomerAccountEvents` mit `IsManual = 1` und `OriginalAmountMultiply = 1` existieren, also ein manuelles, positives Ereignis sein.\n - `PaidDate` (Standard: aktuelles Datum mit Uhrzeit) darf nicht in der Zukunft liegen.\n4. Mit `Pixi_CA_InsertManualBookingEvent` wird eine manuelle Buchung angelegt:\n - Die Buchung verwendet Währung und Wechselkurs der Rechnung.\n - Als Benutzername wird `API` eingetragen.\n - Die Buchung wird mit dem Kundenkonto-Eintrag der Rechnung ausgeglichen.\n\nBei Erfolg liefert der Aufruf `Status = Success`. Erreicht ein Fehler den Wrapper, liefert er `Status = Error` mit dem Fehlertext.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNR` | varchar(20) | Ja | Nummer der Rechnung, die auf bezahlt gesetzt werden soll (`Invoices.InvoiceNr`). |\n| `paid` | bit | Ja | Muss `1` sein. Der Wert `0` (auf unbezahlt setzen) wird mit einem Fehler abgewiesen. |\n| `PaidDate` | datetime | Nein | Buchungsdatum. Bei NULL werden das aktuelle Datum und die aktuelle Uhrzeit verwendet. Darf nicht in der Zukunft liegen. |\n| `eventID` | varchar(3) | Nein | ID des Kundenkonto-Ereignisses für die Buchung (`CustomerAccountEvents.EventID`). Trotz Standardwert ist der Parameter Pflicht. Das Ereignis muss manuell (`IsManual = 1`) und positiv (`OriginalAmountMultiply = 1`) sein. |\n| `PaidSum` | money | Nein | Bezahlter Betrag. Er wird weitergereicht, aber nicht für die Buchung verwendet; gebucht wird immer der volle offene Betrag. |\n\n- `PaidSum` wirkt sich nicht auf den gebuchten Betrag aus. Ein Wert von `0` wird durch NULL ersetzt, sonst wird der Parameter nicht verwendet. Gebucht wird immer der volle offene Betrag (`OpenToMatch`) des Kundenkonto-Eintrags der Rechnung.\n- Die interne Prozedur läuft in einer eigenen Transaktion oder, bei bereits offener Transaktion, in einem Savepoint. `XACT_ABORT` ist aktiv, bei Fehlern wird zurückgerollt.\n- Im CATCH-Block ruft die interne Prozedur `log.InsertError` mit Parameter `1` auf. Dieses Objekt liegt nicht vor. Ob es den Fehler erneut auslöst, ist daher unbekannt. Nur in diesem Fall liefert der Wrapper die `Error`-Zeile; andernfalls könnte ein fehlgeschlagener Aufruf dennoch `Success` melden.\n- Die Ermittlung des Kundenkonto-Eintrags erfolgt vor den Prüfungen. Bei einer nicht existierenden Rechnung wird sie mit NULL-Schlüsseln aufgerufen.\n- `Invoices` und `CustomerAccountEvents` werden mit `NOLOCK` gelesen.\n- Welche Tabellen `Pixi_CA_InsertManualBookingEvent` schreibt, ist aus dem vorliegenden Code nicht ersichtlich.\n- Die Prüfung auf 'bereits bezahlt' vergleicht `total` und `PayedSum` auf exakte Gleichheit. Eine teilbezahlte Rechnung wird mit dem verbleibenden offenen Betrag gebucht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetInvoicePaid"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE2024001234\n 1\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt eine Rechnung auf bezahlt, indem eine manuelle Buchung im Kundenkonto angelegt und mit dem offenen Rechnungsbetrag ausgeglichen wird.\n\nWrapper um die interne Prozedur `pixi_SetInvoicePaid`. Die Rückgabe ist eine Statuszeile mit `Status` und `Message`.\n\nAblauf der internen Prozedur:\n\n1. Die Rechnung wird über `InvoiceNR` in `Invoices` gesucht. Gelesen werden Kunde, Gesamtbetrag, bezahlte Summe, Währung und Wechselkurs.\n2. Über `Pixi_CA_GetCustomerAccountforInvoice` wird der Kundenkonto-Eintrag der Rechnung ermittelt. Der Buchungsbetrag ist der negierte Wert von `OpenToMatch` dieses Eintrags.\n3. Die Eingaben werden in dieser Reihenfolge geprüft:\n - `paid` muss `1` sein. Das Zurücksetzen auf unbezahlt wird nicht unterstützt.\n - Die Rechnung muss existieren.\n - Die Rechnung darf nicht bereits vollständig bezahlt sein (`total` = `PayedSum`).\n - `eventID` muss angegeben sein.\n - Das Ereignis muss in `CustomerAccountEvents` mit `IsManual = 1` und `OriginalAmountMultiply = 1` existieren, also ein manuelles, positives Ereignis sein.\n - `PaidDate` (Standard: aktuelles Datum mit Uhrzeit) darf nicht in der Zukunft liegen.\n4. Mit `Pixi_CA_InsertManualBookingEvent` wird eine manuelle Buchung angelegt:\n - Die Buchung verwendet Währung und Wechselkurs der Rechnung.\n - Als Benutzername wird `API` eingetragen.\n - Die Buchung wird mit dem Kundenkonto-Eintrag der Rechnung ausgeglichen.\n\nBei Erfolg liefert der Aufruf `Status = Success`. Erreicht ein Fehler den Wrapper, liefert er `Status = Error` mit dem Fehlertext.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNR` | varchar(20) | Ja | Nummer der Rechnung, die auf bezahlt gesetzt werden soll (`Invoices.InvoiceNr`). |\n| `paid` | bit | Ja | Muss `1` sein. Der Wert `0` (auf unbezahlt setzen) wird mit einem Fehler abgewiesen. |\n| `PaidDate` | datetime | Nein | Buchungsdatum. Bei NULL werden das aktuelle Datum und die aktuelle Uhrzeit verwendet. Darf nicht in der Zukunft liegen. |\n| `eventID` | varchar(3) | Nein | ID des Kundenkonto-Ereignisses für die Buchung (`CustomerAccountEvents.EventID`). Trotz Standardwert ist der Parameter Pflicht. Das Ereignis muss manuell (`IsManual = 1`) und positiv (`OriginalAmountMultiply = 1`) sein. |\n| `PaidSum` | money | Nein | Bezahlter Betrag. Er wird weitergereicht, aber nicht für die Buchung verwendet; gebucht wird immer der volle offene Betrag. |\n\n- `PaidSum` wirkt sich nicht auf den gebuchten Betrag aus. Ein Wert von `0` wird durch NULL ersetzt, sonst wird der Parameter nicht verwendet. Gebucht wird immer der volle offene Betrag (`OpenToMatch`) des Kundenkonto-Eintrags der Rechnung.\n- Die interne Prozedur läuft in einer eigenen Transaktion oder, bei bereits offener Transaktion, in einem Savepoint. `XACT_ABORT` ist aktiv, bei Fehlern wird zurückgerollt.\n- Im CATCH-Block ruft die interne Prozedur `log.InsertError` mit Parameter `1` auf. Dieses Objekt liegt nicht vor. Ob es den Fehler erneut auslöst, ist daher unbekannt. Nur in diesem Fall liefert der Wrapper die `Error`-Zeile; andernfalls könnte ein fehlgeschlagener Aufruf dennoch `Success` melden.\n- Die Ermittlung des Kundenkonto-Eintrags erfolgt vor den Prüfungen. Bei einer nicht existierenden Rechnung wird sie mit NULL-Schlüsseln aufgerufen.\n- `Invoices` und `CustomerAccountEvents` werden mit `NOLOCK` gelesen.\n- Welche Tabellen `Pixi_CA_InsertManualBookingEvent` schreibt, ist aus dem vorliegenden Code nicht ersichtlich.\n- Die Prüfung auf 'bereits bezahlt' vergleicht `total` und `PayedSum` auf exakte Gleichheit. Eine teilbezahlte Rechnung wird mit dem verbleibenden offenen Betrag gebucht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetInvoicePaid"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n Successfully created CA manual booking event for InvoiceNr RE2024001234\n \n"
}
]
},
{
"name": "pixiSetInvoiceShippingInformation",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Paketanzahl, Netto- und Bruttopaketgewicht sowie Versanddienstleister einer vorhandenen Rechnung und liefert die gespeicherten Werte.\n\nSetzt Versandinformationen an einer einzelnen Rechnung in der Tabelle `Invoices`, identifiziert über `InvoiceNr`.\n\n1. Zuerst wird geprüft, ob eine Rechnung mit der angegebenen `InvoiceNr` existiert. Falls nicht, wird eine Statuszeile mit `Status` = `400` geliefert und nichts geändert.\n2. Die aktuellen Werte von `PackageNetWeight`, `PackageGrossWeight`, `Packages` und `ShipVendor` werden gelesen.\n3. Die Rechnung wird aktualisiert. Jedes Feld wird nur überschrieben, wenn der zugehörige Parameter nicht `NULL` ist. Weggelassene oder mit `NULL` übergebene Parameter behalten den bisherigen Wert. Damit sind Teilaktualisierungen möglich, z. B. nur die Paketanzahl.\n4. Wurde mindestens eine Zeile aktualisiert, wird `Status` = `200` mit den gespeicherten Werten der Rechnung geliefert. Andernfalls wird `Status` = `500` mit den aktuellen Werten geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Nein | Nummer der zu aktualisierenden Rechnung. Praktisch erforderlich: Ohne passende Rechnung liefert der Aufruf Status `400`. |\n| `PackageNetWeight` | float | Nein | Neues Nettogewicht der Pakete. `NULL` behält den bisherigen Wert bei. |\n| `PackageGrossWeight` | float | Nein | Neues Bruttogewicht der Pakete. `NULL` behält den bisherigen Wert bei. |\n| `Packages` | int | Nein | Neue Paketanzahl. `NULL` behält den bisherigen Wert bei. |\n| `ShipVendor` | varchar(3) | Nein | Neues Kürzel des Versanddienstleisters mit bis zu 3 Zeichen. Der Wert wird nicht validiert. `NULL` behält den bisherigen Wert bei. |\n\n- Ein Feld kann mit diesem Aufruf nicht auf `NULL` zurückgesetzt werden, da `NULL`-Parameter \"bisherigen Wert beibehalten\" bedeuten.\n- `ShipVendor` wird nicht validiert. Jeder Wert mit bis zu 3 Zeichen wird unverändert geschrieben.\n- Gewichte werden nicht auf Plausibilität geprüft, z. B. ein Bruttogewicht kleiner als das Nettogewicht oder negative Werte.\n- Die Existenzprüfung und das Lesen der alten Werte erfolgen mit `NOLOCK`. Eine explizite Transaktion wird nicht verwendet.\n- Der `500`-Zweig tritt praktisch nur auf, wenn die Rechnung zwischen Prüfung und Update gelöscht wird. Die Ergebniszeile enthält dann in der Regel keine Daten.\n- Haben mehrere Zeilen dieselbe `InvoiceNr`, werden alle aktualisiert und alle geliefert.\n- Die Spaltentypen im Ergebnis sind aus den im Code deklarierten Variablen abgeleitet. Die Tabellendefinition von `Invoices` liegt nicht vor.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetInvoiceShippingInformation"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Paketanzahl, Netto- und Bruttopaketgewicht sowie Versanddienstleister einer vorhandenen Rechnung und liefert die gespeicherten Werte.\n\nSetzt Versandinformationen an einer einzelnen Rechnung in der Tabelle `Invoices`, identifiziert über `InvoiceNr`.\n\n1. Zuerst wird geprüft, ob eine Rechnung mit der angegebenen `InvoiceNr` existiert. Falls nicht, wird eine Statuszeile mit `Status` = `400` geliefert und nichts geändert.\n2. Die aktuellen Werte von `PackageNetWeight`, `PackageGrossWeight`, `Packages` und `ShipVendor` werden gelesen.\n3. Die Rechnung wird aktualisiert. Jedes Feld wird nur überschrieben, wenn der zugehörige Parameter nicht `NULL` ist. Weggelassene oder mit `NULL` übergebene Parameter behalten den bisherigen Wert. Damit sind Teilaktualisierungen möglich, z. B. nur die Paketanzahl.\n4. Wurde mindestens eine Zeile aktualisiert, wird `Status` = `200` mit den gespeicherten Werten der Rechnung geliefert. Andernfalls wird `Status` = `500` mit den aktuellen Werten geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Nein | Nummer der zu aktualisierenden Rechnung. Praktisch erforderlich: Ohne passende Rechnung liefert der Aufruf Status `400`. |\n| `PackageNetWeight` | float | Nein | Neues Nettogewicht der Pakete. `NULL` behält den bisherigen Wert bei. |\n| `PackageGrossWeight` | float | Nein | Neues Bruttogewicht der Pakete. `NULL` behält den bisherigen Wert bei. |\n| `Packages` | int | Nein | Neue Paketanzahl. `NULL` behält den bisherigen Wert bei. |\n| `ShipVendor` | varchar(3) | Nein | Neues Kürzel des Versanddienstleisters mit bis zu 3 Zeichen. Der Wert wird nicht validiert. `NULL` behält den bisherigen Wert bei. |\n\n- Ein Feld kann mit diesem Aufruf nicht auf `NULL` zurückgesetzt werden, da `NULL`-Parameter \"bisherigen Wert beibehalten\" bedeuten.\n- `ShipVendor` wird nicht validiert. Jeder Wert mit bis zu 3 Zeichen wird unverändert geschrieben.\n- Gewichte werden nicht auf Plausibilität geprüft, z. B. ein Bruttogewicht kleiner als das Nettogewicht oder negative Werte.\n- Die Existenzprüfung und das Lesen der alten Werte erfolgen mit `NOLOCK`. Eine explizite Transaktion wird nicht verwendet.\n- Der `500`-Zweig tritt praktisch nur auf, wenn die Rechnung zwischen Prüfung und Update gelöscht wird. Die Ergebniszeile enthält dann in der Regel keine Daten.\n- Haben mehrere Zeilen dieselbe `InvoiceNr`, werden alle aktualisiert und alle geliefert.\n- Die Spaltentypen im Ergebnis sind aus den im Code deklarierten Variablen abgeleitet. Die Tabellendefinition von `Invoices` liegt nicht vor.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetInvoiceShippingInformation"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 200\n Data updated in pixi*\n RE2024001234\n 2\n 2.35\n 2.8\n DHL\n \n"
}
]
},
{
"name": "pixiSetReminderLevel",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2\n RE2024001234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt die Mahnstufe einer Rechnung, die über ihre Rechnungsnummer ermittelt wird.\n\nErmittelt die Rechnung über `InvoiceNR` (`Invoices.InvoiceNr`) und übergibt deren Schlüssel an die interne Prozedur `Pixi_CA_R_SetLevel`. Als Benutzername wird `API` verwendet.\n\nDiese Prozedur arbeitet wie folgt:\n\n- **Stufe größer 0:** Es werden die Mahnungen (`Reminders`) gesucht, die eine Mahnposition (`ReminderLines`) zu dieser Rechnung enthalten und deren `HighestReminderLevel` gleich `ReminderLevel` ist.\n - **Wenn eine passende Mahnung existiert:**\n - Die Rechnung erhält die neue `ReminderLevel`.\n - `UpdateEmp` wird auf `API` gesetzt.\n - `UpdateDate` wird auf das **Datum dieser Mahnung** gesetzt, nicht auf die aktuelle Zeit.\n - Alle Mahnpositionen der Rechnung werden dieser Mahnung zugeordnet (`ReminderRef`).\n - **Wenn keine passende Mahnung existiert:** Nur die Rechnung wird aktualisiert, `UpdateDate` erhält die aktuelle Zeit.\n- **Stufe 0 oder `NULL`:** Die `ReminderLevel` der Rechnung wird auf `NULL` zurückgesetzt. `UpdateEmp` = `API` und `UpdateDate` = jetzt.\n\nDer Aufruf liefert keine Ergebnismenge.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ReminderLevel` | int | Ja | Neue Mahnstufe der Rechnung. 0 oder NULL setzt die Mahnstufe auf NULL zurück. |\n| `InvoiceNR` | varchar(20) | Ja | Rechnungsnummer (`Invoices.InvoiceNr`) der zu ändernden Rechnung. |\n\n- **Keine Rückmeldung:** Es gibt weder eine Statuszeile noch eine Fehlerbehandlung. Existiert die Rechnungsnummer nicht, wird nichts geändert, und der Aufruf endet trotzdem ohne Meldung.\n- **Mehrdeutige Rechnungsnummern:** Der Rechnungsschlüssel wird per skalarer Unterabfrage gelesen. Teilen sich mehrere Rechnungen dieselbe `InvoiceNr`, löst SQL Server Fehler 512 aus (\"Subquery returned more than 1 value\").\n- **Sperren:** Die Abfragen auf `Invoices`, `Reminders` und `ReminderLines` verwenden `NOLOCK`.\n- **Transaktionen:** Die Änderungen laufen ohne explizite Transaktion.\n- **Keine Prüfung:** `ReminderLevel` wird nicht gegen einen Wertebereich geprüft; jeder ganzzahlige Wert wird geschrieben.\n- **Mehrere passende Mahnungen:** Die Mahnung wird per Variablenzuweisung mit `ORDER BY ReminderDate` ermittelt. In der Praxis ergibt das meist die jüngste, SQL Server garantiert aber nicht, welche Zeile verwendet wird.\n- **Umhängen der Positionen:** Wird eine passende Mahnung gefunden, werden alle Mahnpositionen der Rechnung dieser Mahnung zugeordnet, auch Positionen, die zu anderen Mahnungen gehörten.\n- **Stufe 0:** Die Prüfung, die 0 als \"keine Stufe\" behandeln soll, greift nie (`NULLIF(@ReminderLevel, 0) = 0` ist nie wahr). Bei 0 sucht der Code daher trotzdem nach Mahnungen mit `HighestReminderLevel = 0`. Die Mahnstufe der Rechnung wird in jedem Fall `NULL`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetReminderLevel"
},
"response": []
},
{
"name": "pixiUpdateInvoicePackageTrackingIds",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt Sendungs- und Retouren-Tracking-IDs einer Rechnung und, falls eindeutig bestimmbar, des zugehörigen Rechnungspakets und publiziert ein `InvoiceChanged`-Event.\n\nAktualisiert Tracking-Informationen einer Rechnung (`Invoices`) und ihres Pakets (`pixi.InvoicePackage`). Als Ergebnis wird immer eine Statuszeile mit `Status` und `Message` geliefert.\n\n**Prüfungen**\n- Mindestens einer der Werte `PackageId` oder `InvoiceNr` und mindestens einer der Werte `TrackingId` oder `ReturnTrackingId` muss gefüllt sein. Andernfalls wird Status `400` geliefert. Eine `PackageId` von `0` gilt als leer.\n- Bei `TrackingId` und `ReturnTrackingId` wird je ein führendes und ein abschließendes `;` entfernt.\n\n**Ermittlung von Rechnung und Paket**\n- Mit `InvoiceNr` wird die Rechnung über die Rechnungsnummer gelesen. Alle Pakete mit `Id = PackageId` oder zur Rechnung gehörend werden geladen.\n- Nur mit `PackageId` wird das Paket geladen und die zugehörige Rechnung gelesen.\n- Wird nur `InvoiceNr` übergeben, hat die Rechnung mehrere Pakete und ist `Overwrite = 1`, wird Status `400` geliefert (`PackageId` ist erforderlich).\n- Wird kein Paket gefunden, wird Status `400` geliefert. Das gilt auch, wenn die Rechnung nicht existiert oder kein Paket hat. Gleiches gilt, wenn `PackageId` und `InvoiceNr` beide übergeben werden, das Paket aber nicht zur Rechnung gehört.\n- Überschreitet die Länge aus gespeichertem und neuem Wert 512 Zeichen, wird Status `411` geliefert. Geprüft wird dies für `ShipmentTrackingID` und für `retTrackIDhist`.\n\n**Welche Datensätze aktualisiert werden**\n- Die Rechnung wird immer aktualisiert.\n- Das Paket wird in drei Fällen zusätzlich aktualisiert:\n - `PackageId` und `InvoiceNr` passen zusammen.\n - Nur `InvoiceNr` wird übergeben und die Rechnung hat genau ein Paket.\n - Nur `PackageId` wird übergeben.\n- Wird nur `InvoiceNr` übergeben, hat die Rechnung mehrere Pakete und ist `Overwrite = 0`, wird nur die Rechnung aktualisiert.\n\n**Sendungs-Tracking (`TrackingId`)**\n- `Overwrite = 0`: `TrackingId` wird mit `;` getrennt an `Invoices.ShipmentTrackingID` angehängt. Das geschieht nur, wenn der bestehende Wert sie noch nicht enthält (Teilstring-Vergleich).\n- `Overwrite = 1`: `ShipmentTrackingID` wird neu gebildet aus den Tracking-IDs aller anderen Pakete der Rechnung, jeweils gefolgt von `;`, plus `TrackingId`. Ist `TrackingId` bereits in dieser Liste enthalten, wird `ShipmentTrackingID` auf `TrackingId` allein gesetzt.\n- Das Paket erhält nur das letzte `;`-getrennte Segment von `TrackingId` als `TrackingID`.\n\n**Retouren-Tracking (`ReturnTrackingId`)**\n- `Overwrite` hat auf das Retouren-Tracking keinen Einfluss.\n- Ist `ReturnTrackingId` noch nicht in `Invoices.retTrackID` enthalten:\n - `retTrackID` wird auf das letzte `;`-getrennte Segment gesetzt.\n - Der vollständige Wert wird mit abschließendem `;` an `retTrackIDhist` angehängt.\n- Das Paket erhält das letzte Segment als `ReturnTrackingId`.\n\n**Weitere Schritte**\n- Die Rechnung erhält `UpdateDate = GETDATE()` und `UpdateEmp = '(Return) TrackingID API Update'`.\n- Das Paket erhält `RecordModifiedOn` und `RecordModifiedByUserId`, die ID des Benutzers `API`.\n- Mit `ResetClientNotifiedFlag = 1` wird `ClientNotified` auf `N` gesetzt, und zwar beim jeweils letzten `AUS`-Eintrag (ausgeliefert) in `OrderHistory` jeder Auftragsposition der Rechnung. Dadurch wird die Sendung erneut exportiert bzw. gemeldet.\n- Zum Schluss wird das MQ-Event `InvoiceChanged` mit dem Rechnungsschlüssel und dem Parameter `SetTrackingId` publiziert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PackageId` | int | Nein | ID des Rechnungspakets (`pixi.InvoicePackage.Id`). Pflicht, wenn `InvoiceNr` fehlt. Ebenfalls Pflicht, wenn die Rechnung mehrere Pakete hat und `Overwrite = 1` ist. `0` gilt als leer. |\n| `InvoiceNr` | varchar(20) | Nein | Rechnungsnummer (`Invoices.InvoiceNr`). Pflicht, wenn `PackageId` fehlt. Werden beide übergeben, muss das Paket zu dieser Rechnung gehören. |\n| `TrackingId` | varchar(512) | Nein | Sendungs-Tracking-ID, optional mehrere IDs mit `;` getrennt. Der Wert geht in `Invoices.ShipmentTrackingID` ein. Das Paket erhält das letzte Segment. Dieser Wert oder `ReturnTrackingId` muss gefüllt sein. |\n| `ReturnTrackingId` | varchar(512) | Nein | Retouren-Tracking-ID, optional mehrere IDs mit `;` getrennt. Das letzte Segment wird in `Invoices.retTrackID` und im Paket gespeichert. Der vollständige Wert wird an `retTrackIDhist` angehängt. |\n| `Overwrite` | bit | Nein | Steuert, wie `TrackingId` in die Rechnung geschrieben wird. Auf die Retouren-Tracking-ID hat er keinen Einfluss. |\n| `ResetClientNotifiedFlag` | bit | Nein | Bei `1` wird `ClientNotified = 'N'` bei den letzten `AUS`-Einträgen der Auftragshistorie der Auftragspositionen der Rechnung gesetzt, damit die Sendung erneut exportiert bzw. gemeldet wird. |\n\n- **Transaktion:** Alle Änderungen laufen in einer Transaktion. Besteht beim Aufrufer bereits eine offene Transaktion, wird ein Savepoint verwendet. Validierungsfehler (`400`/`411`) ändern nichts; die Transaktion wird trotzdem committet und die Statuszeile geliefert.\n- **Unerwartete SQL-Fehler:** Die Transaktion wird zurückgerollt und der Fehler über `log.InsertError` protokolliert. In diesem Fall wird keine Statuszeile geliefert.\n- **Status als Zeichenkette:** `Status` ist eine Zeichenkette (`200`, `400`, `411`), kein HTTP-Status. Der SOAP-Aufruf selbst ist erfolgreich.\n- **Duplikatprüfung:** Die Prüfung, ob eine Tracking-ID bereits vorhanden ist, erfolgt per `LIKE '%…%'` als Teilstring-Vergleich. Eine neue ID, die Teil einer längeren bestehenden ID ist oder `%` / `_` enthält, kann fälschlich als vorhanden gelten und wird dann nicht angehängt.\n- **Meldungen:** Sie nennen `InvoiceKey`, der Parameter heißt jedoch `PackageId`.\n- **NOLOCK:** Rechnungen und Pakete werden mit `NOLOCK` gelesen.\n- **Trigger:** Während des Rechnungs-Updates wird `CONTEXT_INFO` auf `0x11111` gesetzt, vermutlich damit Trigger dieses Update erkennen. Deren Verhalten ist hier nicht sichtbar.\n- **Unbekannter API-Benutzer:** Existiert kein Benutzer `API` in `UCS_USERS`, wird `RecordModifiedByUserId` auf `NULL` gesetzt.\n- **MQ-Event:** `InvoiceChanged` wird nur gesendet, wenn die Einstellung `pixiMQ_Enabled` aktiv ist und das Event in `EventConfiguration` konfiguriert und aktiviert ist. Zustellfehler landen in `EventQueue` und führen nicht zu einem Fehler dieses Aufrufs.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateInvoicePackageTrackingIds"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt Sendungs- und Retouren-Tracking-IDs einer Rechnung und, falls eindeutig bestimmbar, des zugehörigen Rechnungspakets und publiziert ein `InvoiceChanged`-Event.\n\nAktualisiert Tracking-Informationen einer Rechnung (`Invoices`) und ihres Pakets (`pixi.InvoicePackage`). Als Ergebnis wird immer eine Statuszeile mit `Status` und `Message` geliefert.\n\n**Prüfungen**\n- Mindestens einer der Werte `PackageId` oder `InvoiceNr` und mindestens einer der Werte `TrackingId` oder `ReturnTrackingId` muss gefüllt sein. Andernfalls wird Status `400` geliefert. Eine `PackageId` von `0` gilt als leer.\n- Bei `TrackingId` und `ReturnTrackingId` wird je ein führendes und ein abschließendes `;` entfernt.\n\n**Ermittlung von Rechnung und Paket**\n- Mit `InvoiceNr` wird die Rechnung über die Rechnungsnummer gelesen. Alle Pakete mit `Id = PackageId` oder zur Rechnung gehörend werden geladen.\n- Nur mit `PackageId` wird das Paket geladen und die zugehörige Rechnung gelesen.\n- Wird nur `InvoiceNr` übergeben, hat die Rechnung mehrere Pakete und ist `Overwrite = 1`, wird Status `400` geliefert (`PackageId` ist erforderlich).\n- Wird kein Paket gefunden, wird Status `400` geliefert. Das gilt auch, wenn die Rechnung nicht existiert oder kein Paket hat. Gleiches gilt, wenn `PackageId` und `InvoiceNr` beide übergeben werden, das Paket aber nicht zur Rechnung gehört.\n- Überschreitet die Länge aus gespeichertem und neuem Wert 512 Zeichen, wird Status `411` geliefert. Geprüft wird dies für `ShipmentTrackingID` und für `retTrackIDhist`.\n\n**Welche Datensätze aktualisiert werden**\n- Die Rechnung wird immer aktualisiert.\n- Das Paket wird in drei Fällen zusätzlich aktualisiert:\n - `PackageId` und `InvoiceNr` passen zusammen.\n - Nur `InvoiceNr` wird übergeben und die Rechnung hat genau ein Paket.\n - Nur `PackageId` wird übergeben.\n- Wird nur `InvoiceNr` übergeben, hat die Rechnung mehrere Pakete und ist `Overwrite = 0`, wird nur die Rechnung aktualisiert.\n\n**Sendungs-Tracking (`TrackingId`)**\n- `Overwrite = 0`: `TrackingId` wird mit `;` getrennt an `Invoices.ShipmentTrackingID` angehängt. Das geschieht nur, wenn der bestehende Wert sie noch nicht enthält (Teilstring-Vergleich).\n- `Overwrite = 1`: `ShipmentTrackingID` wird neu gebildet aus den Tracking-IDs aller anderen Pakete der Rechnung, jeweils gefolgt von `;`, plus `TrackingId`. Ist `TrackingId` bereits in dieser Liste enthalten, wird `ShipmentTrackingID` auf `TrackingId` allein gesetzt.\n- Das Paket erhält nur das letzte `;`-getrennte Segment von `TrackingId` als `TrackingID`.\n\n**Retouren-Tracking (`ReturnTrackingId`)**\n- `Overwrite` hat auf das Retouren-Tracking keinen Einfluss.\n- Ist `ReturnTrackingId` noch nicht in `Invoices.retTrackID` enthalten:\n - `retTrackID` wird auf das letzte `;`-getrennte Segment gesetzt.\n - Der vollständige Wert wird mit abschließendem `;` an `retTrackIDhist` angehängt.\n- Das Paket erhält das letzte Segment als `ReturnTrackingId`.\n\n**Weitere Schritte**\n- Die Rechnung erhält `UpdateDate = GETDATE()` und `UpdateEmp = '(Return) TrackingID API Update'`.\n- Das Paket erhält `RecordModifiedOn` und `RecordModifiedByUserId`, die ID des Benutzers `API`.\n- Mit `ResetClientNotifiedFlag = 1` wird `ClientNotified` auf `N` gesetzt, und zwar beim jeweils letzten `AUS`-Eintrag (ausgeliefert) in `OrderHistory` jeder Auftragsposition der Rechnung. Dadurch wird die Sendung erneut exportiert bzw. gemeldet.\n- Zum Schluss wird das MQ-Event `InvoiceChanged` mit dem Rechnungsschlüssel und dem Parameter `SetTrackingId` publiziert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PackageId` | int | Nein | ID des Rechnungspakets (`pixi.InvoicePackage.Id`). Pflicht, wenn `InvoiceNr` fehlt. Ebenfalls Pflicht, wenn die Rechnung mehrere Pakete hat und `Overwrite = 1` ist. `0` gilt als leer. |\n| `InvoiceNr` | varchar(20) | Nein | Rechnungsnummer (`Invoices.InvoiceNr`). Pflicht, wenn `PackageId` fehlt. Werden beide übergeben, muss das Paket zu dieser Rechnung gehören. |\n| `TrackingId` | varchar(512) | Nein | Sendungs-Tracking-ID, optional mehrere IDs mit `;` getrennt. Der Wert geht in `Invoices.ShipmentTrackingID` ein. Das Paket erhält das letzte Segment. Dieser Wert oder `ReturnTrackingId` muss gefüllt sein. |\n| `ReturnTrackingId` | varchar(512) | Nein | Retouren-Tracking-ID, optional mehrere IDs mit `;` getrennt. Das letzte Segment wird in `Invoices.retTrackID` und im Paket gespeichert. Der vollständige Wert wird an `retTrackIDhist` angehängt. |\n| `Overwrite` | bit | Nein | Steuert, wie `TrackingId` in die Rechnung geschrieben wird. Auf die Retouren-Tracking-ID hat er keinen Einfluss. |\n| `ResetClientNotifiedFlag` | bit | Nein | Bei `1` wird `ClientNotified = 'N'` bei den letzten `AUS`-Einträgen der Auftragshistorie der Auftragspositionen der Rechnung gesetzt, damit die Sendung erneut exportiert bzw. gemeldet wird. |\n\n- **Transaktion:** Alle Änderungen laufen in einer Transaktion. Besteht beim Aufrufer bereits eine offene Transaktion, wird ein Savepoint verwendet. Validierungsfehler (`400`/`411`) ändern nichts; die Transaktion wird trotzdem committet und die Statuszeile geliefert.\n- **Unerwartete SQL-Fehler:** Die Transaktion wird zurückgerollt und der Fehler über `log.InsertError` protokolliert. In diesem Fall wird keine Statuszeile geliefert.\n- **Status als Zeichenkette:** `Status` ist eine Zeichenkette (`200`, `400`, `411`), kein HTTP-Status. Der SOAP-Aufruf selbst ist erfolgreich.\n- **Duplikatprüfung:** Die Prüfung, ob eine Tracking-ID bereits vorhanden ist, erfolgt per `LIKE '%…%'` als Teilstring-Vergleich. Eine neue ID, die Teil einer längeren bestehenden ID ist oder `%` / `_` enthält, kann fälschlich als vorhanden gelten und wird dann nicht angehängt.\n- **Meldungen:** Sie nennen `InvoiceKey`, der Parameter heißt jedoch `PackageId`.\n- **NOLOCK:** Rechnungen und Pakete werden mit `NOLOCK` gelesen.\n- **Trigger:** Während des Rechnungs-Updates wird `CONTEXT_INFO` auf `0x11111` gesetzt, vermutlich damit Trigger dieses Update erkennen. Deren Verhalten ist hier nicht sichtbar.\n- **Unbekannter API-Benutzer:** Existiert kein Benutzer `API` in `UCS_USERS`, wird `RecordModifiedByUserId` auf `NULL` gesetzt.\n- **MQ-Event:** `InvoiceChanged` wird nur gesendet, wenn die Einstellung `pixiMQ_Enabled` aktiv ist und das Event in `EventConfiguration` konfiguriert und aktiviert ist. Zustellfehler landen in `EventQueue` und führen nicht zu einem Fehler dieses Aufrufs.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateInvoicePackageTrackingIds"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 200\n TrackingId & ReturnTrackingId was updated successfully\n \n"
}
]
}
]
},
{
"name": "Items",
"item": [
{
"name": "pixiCanConvertBundle",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Prüft, ob ein Artikel in ein Bundle bzw. aus einem Bundle umgewandelt werden kann, und liefert seine Stammdaten mit dem Kennzeichen `CanConvert`.\n\nErmittelt einen Artikel und prüft, ob er bereits verwendet wird, was eine Umwandlung (Änderung des Bundle-Status) verhindert.\n\n**Ermittlung des Artikels** (leere Zeichenketten werden als `NULL` behandelt):\n1. Wird `ItemKey` übergeben, werden `ItemNrInt` und `EAN` ignoriert.\n2. Andernfalls wird bei Angabe von `ItemNrInt` der Artikel über die Artikelcodes (Codetyp 2 = interne Artikelnummer) gesucht; `EAN` wird dann ignoriert.\n3. Andernfalls wird bei Angabe von `EAN` der Artikel über die Artikelcodes (Codetyp 1 = EAN) gesucht.\n\nPassen mehrere Artikel zu einem Code, wird der erste gefundene Treffer verwendet.\n\n**Prüfung:** `CanConvert` ist `0`, wenn der Artikel in mindestens einem der folgenden Bereiche referenziert wird, sonst `1`:\n- Auftragspositionen (`Orderlines`)\n- Bundle-Auftragspositionen (`BundleOrderlines`)\n- Lagerplatzbestände (`InvBinItem`)\n\n**Ergebnis:** eine Zeile mit Artikelschlüssel, interner Artikelnummer, EAN, Bundle-Kennzeichen und dem Kennzeichen `CanConvert`. Wird kein Artikel gefunden, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. Hat Vorrang vor `ItemNrInt` und `EAN`. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer, Suche über die Artikelcodes (Codetyp 2). Wird nur verwendet, wenn `ItemKey` leer ist; hat Vorrang vor `EAN`. |\n| `EAN` | varchar(13) | Nein | EAN des Artikels, Suche über die Artikelcodes (Codetyp 1). Wird nur verwendet, wenn weder `ItemKey` noch `ItemNrInt` übergeben wird. |\n\n- Der Aufruf prüft nur; es wird nichts umgewandelt.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Wurde der Artikel über `EAN` gefunden, liefert die Spalte `EAN` die übergebene EAN (ggf. eine Zusatz-EAN) statt der Haupt-EAN `EANUPC` des Artikels.\n- Eine unbekannte `ItemNrInt` führt nicht zu einer Suche über `EAN`; das Ergebnis ist dann leer.\n- Es gibt keine Fehlerzeile: Ein leeres Ergebnis bedeutet, dass der Artikel nicht gefunden wurde.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCanConvertBundle"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Prüft, ob ein Artikel in ein Bundle bzw. aus einem Bundle umgewandelt werden kann, und liefert seine Stammdaten mit dem Kennzeichen `CanConvert`.\n\nErmittelt einen Artikel und prüft, ob er bereits verwendet wird, was eine Umwandlung (Änderung des Bundle-Status) verhindert.\n\n**Ermittlung des Artikels** (leere Zeichenketten werden als `NULL` behandelt):\n1. Wird `ItemKey` übergeben, werden `ItemNrInt` und `EAN` ignoriert.\n2. Andernfalls wird bei Angabe von `ItemNrInt` der Artikel über die Artikelcodes (Codetyp 2 = interne Artikelnummer) gesucht; `EAN` wird dann ignoriert.\n3. Andernfalls wird bei Angabe von `EAN` der Artikel über die Artikelcodes (Codetyp 1 = EAN) gesucht.\n\nPassen mehrere Artikel zu einem Code, wird der erste gefundene Treffer verwendet.\n\n**Prüfung:** `CanConvert` ist `0`, wenn der Artikel in mindestens einem der folgenden Bereiche referenziert wird, sonst `1`:\n- Auftragspositionen (`Orderlines`)\n- Bundle-Auftragspositionen (`BundleOrderlines`)\n- Lagerplatzbestände (`InvBinItem`)\n\n**Ergebnis:** eine Zeile mit Artikelschlüssel, interner Artikelnummer, EAN, Bundle-Kennzeichen und dem Kennzeichen `CanConvert`. Wird kein Artikel gefunden, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. Hat Vorrang vor `ItemNrInt` und `EAN`. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer, Suche über die Artikelcodes (Codetyp 2). Wird nur verwendet, wenn `ItemKey` leer ist; hat Vorrang vor `EAN`. |\n| `EAN` | varchar(13) | Nein | EAN des Artikels, Suche über die Artikelcodes (Codetyp 1). Wird nur verwendet, wenn weder `ItemKey` noch `ItemNrInt` übergeben wird. |\n\n- Der Aufruf prüft nur; es wird nichts umgewandelt.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Wurde der Artikel über `EAN` gefunden, liefert die Spalte `EAN` die übergebene EAN (ggf. eine Zusatz-EAN) statt der Haupt-EAN `EANUPC` des Artikels.\n- Eine unbekannte `ItemNrInt` führt nicht zu einer Suche über `EAN`; das Ergebnis ist dann leer.\n- Es gibt keine Fehlerzeile: Ein leeres Ergebnis bedeutet, dass der Artikel nicht gefunden wurde.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCanConvertBundle"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4711\n ART-10023\n 4006381333931\n false\n true\n \n"
}
]
},
{
"name": "pixiCreateItemSupplier",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n L001\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine neue Lieferantenzuordnung (AddItems-Datensatz) für einen bestehenden Artikel an, optional mit eigener EAN und als bevorzugter Lieferant.\n\nOrdnet einem Artikel einen Lieferanten zu, indem ein Datensatz in `AddItems` eingefügt wird. Der Aufruf liefert genau eine Statuszeile (`Status`, `Message`).\n\nAblauf:\n\n1. **Lieferantenprüfung**: `SupplNr` ist Pflicht; ein Leerstring gilt als nicht angegeben. Der Lieferant muss in `Suppliers` existieren.\n2. **Artikelidentifikation**: Der Artikel wird über `pixi.ItemCode` ermittelt, und zwar anhand von `ItemKey`, `EAN` (Barcode, Codetyp 1) und/oder `ItemNrInt` (Shop-Artikelnummer, Codetyp 2). Mindestens ein Wert ist erforderlich. Werden mehrere Werte angegeben, müssen alle auf denselben Artikel zeigen. Jeder angegebene Wert muss gefunden werden.\n3. **Prüfung NewEAN**: Wird `NewEAN` angegeben, darf dieser Code bei keinem anderen Artikel unter einem scanbaren Codetyp existieren.\n4. **EAN des neuen Datensatzes**: Gespeichert wird `NewEAN`. Fehlt dieser Wert, wird `EAN` verwendet. Fehlen beide, wird die `EANUPC` des Artikels aus `items` übernommen. Aus dem Artikel übernommen werden außerdem `ItemNrInt` (falls nicht angegeben), `IntLinkNR1`, `IntLinkNR` und der Verkaufspreis `Price`.\n5. **Dublettenprüfung**: Existiert für den Artikel in `pixi.ItemCode` bereits ein Barcode-Eintrag mit dieser EAN für diesen Lieferanten, bricht der Aufruf mit einem Fehler ab.\n6. **Bevorzugter Lieferant**: Bei `PreferredSupplier` = 1 wird zuerst der bisherige bevorzugte Lieferantendatensatz des Artikels (ein Datensatz, `TOP (1)`) auf `PreferredSupplier` = 0 gesetzt.\n7. **Einfügen**: Ein neuer `AddItems`-Datensatz wird angelegt. Er erhält `SupplPrice`, `ItemNrSuppl`, `SupplDeliveryTime` (= `ItemDeliveryTime`), `MinOrderQty`, `OrderOnlyPackageUnits` (= `OnlyPU`), `Active` (= `IsActive`) und `PreferredSupplier`. `AutoPrice` wird auf 0 gesetzt, `CreateDate` auf den aktuellen Zeitpunkt.\n\nBei Erfolg lautet der Status `New record inserted`. Die Meldung enthält den gespeicherten Lieferantenpreis, die Lieferantenartikelnummer und die EAN.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Artikelschlüssel zur Identifikation des Artikels. 0 gilt als nicht angegeben. |\n| `ItemNrInt` | varchar(50) | Nein | Shop-Artikelnummer zur Identifikation des Artikels (Codetyp 2). Fehlt sie, wird die `ItemNrInt` des Artikels im neuen Datensatz gespeichert. |\n| `EAN` | varchar(13) | Nein | Barcode zur Identifikation des Artikels (Codetyp 1). Er wird auch als EAN des neuen Datensatzes verwendet, wenn `NewEAN` leer ist. |\n| `NewEAN` | varchar(13) | Nein | EAN, die im neuen Lieferantendatensatz gespeichert wird. Sie darf nicht als scanbarer Code bei einem anderen Artikel existieren. |\n| `SupplNr` | varchar(4) | Ja | Lieferantennummer (Pflicht); muss in `Suppliers` existieren. |\n| `SupplPrice` | money | Nein | Einkaufspreis beim Lieferanten; NULL wird zu 0. |\n| `ItemNrSuppl` | varchar(50) | Nein | Artikelnummer des Lieferanten; ein Leerstring wird als NULL gespeichert. |\n| `PreferredSupplier` | bit | Nein | Markiert den neuen Datensatz als bevorzugten Lieferanten; der bisherige bevorzugte Datensatz wird zuvor zurückgesetzt. |\n| `MinOrderQty` | int | Nein | Mindestbestellmenge; NULL wird zu 0. |\n| `OnlyPU` | bit | Nein | Nur in Verpackungseinheiten bestellen (gespeichert in `OrderOnlyPackageUnits`). |\n| `ItemDeliveryTime` | int | Nein | Lieferzeit des Lieferanten (gespeichert in `SupplDeliveryTime`). |\n| `IsActive` | bit | Nein | Gibt an, ob der Lieferantendatensatz aktiv ist; NULL wird zu 1. |\n\n- Alle Fehler werden als normale Zeile mit `Status` = `Error` zurückgegeben; es wird kein `RAISERROR` verwendet.\n- Das Zurücksetzen des alten bevorzugten Lieferanten und das Einfügen laufen in einer Transaktion. Läuft bereits eine Transaktion, wird stattdessen ein Savepoint gesetzt.\n- Bei einer Ausnahme wird die Transaktion zurückgerollt und der Fehler über `log.InsertError` protokolliert. Der SQL-Fehlertext wird anschließend in `Message` geliefert.\n- Die Abfragen verwenden `NOLOCK`; nicht festgeschriebene Daten können gelesen werden.\n- Die Dublettenprüfung liest `pixi.ItemCode`, nicht `AddItems`. Ob `pixi.ItemCode` mit `AddItems` synchron gehalten wird (z. B. per Trigger), ist aus diesem Code nicht ersichtlich.\n- Lässt sich keine EAN ermitteln (kein `NewEAN`, kein `EAN`, Artikel ohne `EANUPC`), greift die Dublettenprüfung nie. Der Datensatz wird dann ohne EAN angelegt.\n- `NewEAN` setzt nur die EAN des neuen Lieferantendatensatzes. Die Haupt-EAN des Artikels in `items` bleibt unverändert.\n- `ItemNrInt` wird nicht von Leerstring auf NULL normalisiert. Ein leer übergebenes `ItemNrInt` zusammen mit einem anderen Identifikator führt zu einer leeren `ItemNrInt` im neuen Datensatz.\n- `ItemDeliveryTime` wird bei explizit übergebenem NULL nicht durch 0 ersetzt.\n- Es wird nur ein bisher bevorzugter Datensatz (`TOP (1)`) zurückgesetzt. Weitere als bevorzugt markierte Datensätze bleiben unverändert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateItemSupplier"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n L001\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine neue Lieferantenzuordnung (AddItems-Datensatz) für einen bestehenden Artikel an, optional mit eigener EAN und als bevorzugter Lieferant.\n\nOrdnet einem Artikel einen Lieferanten zu, indem ein Datensatz in `AddItems` eingefügt wird. Der Aufruf liefert genau eine Statuszeile (`Status`, `Message`).\n\nAblauf:\n\n1. **Lieferantenprüfung**: `SupplNr` ist Pflicht; ein Leerstring gilt als nicht angegeben. Der Lieferant muss in `Suppliers` existieren.\n2. **Artikelidentifikation**: Der Artikel wird über `pixi.ItemCode` ermittelt, und zwar anhand von `ItemKey`, `EAN` (Barcode, Codetyp 1) und/oder `ItemNrInt` (Shop-Artikelnummer, Codetyp 2). Mindestens ein Wert ist erforderlich. Werden mehrere Werte angegeben, müssen alle auf denselben Artikel zeigen. Jeder angegebene Wert muss gefunden werden.\n3. **Prüfung NewEAN**: Wird `NewEAN` angegeben, darf dieser Code bei keinem anderen Artikel unter einem scanbaren Codetyp existieren.\n4. **EAN des neuen Datensatzes**: Gespeichert wird `NewEAN`. Fehlt dieser Wert, wird `EAN` verwendet. Fehlen beide, wird die `EANUPC` des Artikels aus `items` übernommen. Aus dem Artikel übernommen werden außerdem `ItemNrInt` (falls nicht angegeben), `IntLinkNR1`, `IntLinkNR` und der Verkaufspreis `Price`.\n5. **Dublettenprüfung**: Existiert für den Artikel in `pixi.ItemCode` bereits ein Barcode-Eintrag mit dieser EAN für diesen Lieferanten, bricht der Aufruf mit einem Fehler ab.\n6. **Bevorzugter Lieferant**: Bei `PreferredSupplier` = 1 wird zuerst der bisherige bevorzugte Lieferantendatensatz des Artikels (ein Datensatz, `TOP (1)`) auf `PreferredSupplier` = 0 gesetzt.\n7. **Einfügen**: Ein neuer `AddItems`-Datensatz wird angelegt. Er erhält `SupplPrice`, `ItemNrSuppl`, `SupplDeliveryTime` (= `ItemDeliveryTime`), `MinOrderQty`, `OrderOnlyPackageUnits` (= `OnlyPU`), `Active` (= `IsActive`) und `PreferredSupplier`. `AutoPrice` wird auf 0 gesetzt, `CreateDate` auf den aktuellen Zeitpunkt.\n\nBei Erfolg lautet der Status `New record inserted`. Die Meldung enthält den gespeicherten Lieferantenpreis, die Lieferantenartikelnummer und die EAN.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Artikelschlüssel zur Identifikation des Artikels. 0 gilt als nicht angegeben. |\n| `ItemNrInt` | varchar(50) | Nein | Shop-Artikelnummer zur Identifikation des Artikels (Codetyp 2). Fehlt sie, wird die `ItemNrInt` des Artikels im neuen Datensatz gespeichert. |\n| `EAN` | varchar(13) | Nein | Barcode zur Identifikation des Artikels (Codetyp 1). Er wird auch als EAN des neuen Datensatzes verwendet, wenn `NewEAN` leer ist. |\n| `NewEAN` | varchar(13) | Nein | EAN, die im neuen Lieferantendatensatz gespeichert wird. Sie darf nicht als scanbarer Code bei einem anderen Artikel existieren. |\n| `SupplNr` | varchar(4) | Ja | Lieferantennummer (Pflicht); muss in `Suppliers` existieren. |\n| `SupplPrice` | money | Nein | Einkaufspreis beim Lieferanten; NULL wird zu 0. |\n| `ItemNrSuppl` | varchar(50) | Nein | Artikelnummer des Lieferanten; ein Leerstring wird als NULL gespeichert. |\n| `PreferredSupplier` | bit | Nein | Markiert den neuen Datensatz als bevorzugten Lieferanten; der bisherige bevorzugte Datensatz wird zuvor zurückgesetzt. |\n| `MinOrderQty` | int | Nein | Mindestbestellmenge; NULL wird zu 0. |\n| `OnlyPU` | bit | Nein | Nur in Verpackungseinheiten bestellen (gespeichert in `OrderOnlyPackageUnits`). |\n| `ItemDeliveryTime` | int | Nein | Lieferzeit des Lieferanten (gespeichert in `SupplDeliveryTime`). |\n| `IsActive` | bit | Nein | Gibt an, ob der Lieferantendatensatz aktiv ist; NULL wird zu 1. |\n\n- Alle Fehler werden als normale Zeile mit `Status` = `Error` zurückgegeben; es wird kein `RAISERROR` verwendet.\n- Das Zurücksetzen des alten bevorzugten Lieferanten und das Einfügen laufen in einer Transaktion. Läuft bereits eine Transaktion, wird stattdessen ein Savepoint gesetzt.\n- Bei einer Ausnahme wird die Transaktion zurückgerollt und der Fehler über `log.InsertError` protokolliert. Der SQL-Fehlertext wird anschließend in `Message` geliefert.\n- Die Abfragen verwenden `NOLOCK`; nicht festgeschriebene Daten können gelesen werden.\n- Die Dublettenprüfung liest `pixi.ItemCode`, nicht `AddItems`. Ob `pixi.ItemCode` mit `AddItems` synchron gehalten wird (z. B. per Trigger), ist aus diesem Code nicht ersichtlich.\n- Lässt sich keine EAN ermitteln (kein `NewEAN`, kein `EAN`, Artikel ohne `EANUPC`), greift die Dublettenprüfung nie. Der Datensatz wird dann ohne EAN angelegt.\n- `NewEAN` setzt nur die EAN des neuen Lieferantendatensatzes. Die Haupt-EAN des Artikels in `items` bleibt unverändert.\n- `ItemNrInt` wird nicht von Leerstring auf NULL normalisiert. Ein leer übergebenes `ItemNrInt` zusammen mit einem anderen Identifikator führt zu einer leeren `ItemNrInt` im neuen Datensatz.\n- `ItemDeliveryTime` wird bei explizit übergebenem NULL nicht durch 0 ersetzt.\n- Es wird nur ein bisher bevorzugter Datensatz (`TOP (1)`) zurückgesetzt. Weitere als bevorzugt markierte Datensätze bleiben unverändert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateItemSupplier"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n New record inserted\n SupplPrice:12.50, ItemNrSuppl:SUP-4711, EAN:4006381333931\n \n"
}
]
},
{
"name": "pixiDeleteItemSupplier",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n ABC\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht die Lieferantenzuordnung (AddItems-Datensatz) eines Artikels für einen Lieferanten, sofern keine offenen Lieferantenbestellungen bestehen.\n\nEntfernt genau einen Artikel-Lieferanten-Datensatz aus `AddItems`.\n\n1. `ItemKey` = `0` wird als `NULL` behandelt, eine leere `ItemNrInt` als `NULL`.\n2. **Kandidaten-Artikel** sind alle Zeilen in `Items`, bei denen `ItemNrInt` = `@ItemNrInt` **oder** `ItemKey` = `@ItemKey` **oder** `EANUPC` = `@EAN` gilt. Die Kriterien sind mit ODER verknüpft, daher können mehrere Artikel Kandidaten werden.\n3. In `AddItems` werden die Datensätze dieser Kandidaten-Artikel zum Lieferanten `@SupplNr` gesucht. Ist `@EAN` angegeben, muss zusätzlich `EanUpc` des `AddItems`-Datensatzes übereinstimmen.\n4. Wird kein Datensatz gefunden, kommt der Fehler *No records found with provided parameters.* zurück. Bei mehr als einem Datensatz kommt der Fehler *Item could not be uniquely identified.* zurück. In beiden Fällen wird nichts geändert.\n5. Ist einer der Kandidaten-Artikel in einer Lieferantenbestellung dieses Lieferanten enthalten, deren Status als offen gekennzeichnet ist (`IsAllOpen` = 1, z. B. NEW, BES, CON), wird ein Fehler geliefert und nichts gelöscht.\n6. Andernfalls wird der `AddItems`-Datensatz in einer Transaktion gelöscht (bzw. mit Savepoint, wenn der Aufrufer bereits eine offene Transaktion hat).\n7. Wurde `@EAN` angegeben, entspricht der Haupt-Barcode `Items.EanUpc` dem Wert `@EAN` und trägt kein `AddItems`-Datensatz der Kandidaten-Artikel diese EAN mehr, wird `Items.EanUpc` durch den `EanUpc` eines der verbleibenden `AddItems`-Datensätze des Artikels ersetzt. Datensätze anderer Lieferanten als `MGS` werden bevorzugt.\n8. Es wird eine einzelne Statuszeile mit `STATUS` und `MESSAGE` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. `0` gilt als nicht gesetzt. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer. Ein leerer String gilt als nicht gesetzt. |\n| `SupplNr` | varchar(4) | Ja | Lieferantennummer des Lieferanten, dessen Zuordnung gelöscht wird. |\n| `EAN` | varchar(13) | Nein | EAN/UPC-Barcode. Dient zur Suche des Artikels über `Items.EANUPC` und schränkt, wenn gesetzt, den `AddItems`-Datensatz zusätzlich auf diese EAN ein. Löst außerdem das Ersetzen des Haupt-Barcodes aus, wenn dieser nicht mehr verwendet wird. |\n\n- Alle Abfragen verwenden `NOLOCK`, daher können die Eindeutigkeits- und Bestellprüfungen auch nicht festgeschriebene Daten sehen.\n- Da die Artikelkriterien mit ODER verknüpft sind, erweitert die Angabe mehrerer Kennungen, die auf verschiedene Artikel zeigen, die Kandidatenmenge. Die Prüfung auf offene Lieferantenbestellungen und die Barcode-Aktualisierung gelten für **alle** Kandidaten-Artikel, nicht nur für den Artikel, dessen `AddItems`-Datensatz gelöscht wurde.\n- Bleibt beim Ersetzen des Barcodes kein `AddItems`-Datensatz für einen Artikel übrig, wird `Items.EanUpc` auf `NULL` gesetzt.\n- Ein leerer String für `EAN` wird nicht in `NULL` umgewandelt, sondern als Filterwert verwendet.\n- Die Erfolgsmeldung enthält `ItemNrInt` nur, wenn dieser Wert übergeben wurde; bei Aufruf nur mit `ItemKey` oder `EAN` bleibt dieser Teil leer.\n- Die Erfolgszeile wird erzeugt, bevor die temporären Tabellen über `util.TempTableDrop` (nicht beigefügt) gelöscht werden und bevor der Commit erfolgt. Tritt dabei ein Fehler auf, kann zusätzlich eine Fehlerzeile folgen.\n- Fehler im Lösch-/Update-Block werden abgefangen, die Transaktion (bzw. der Savepoint) wird zurückgerollt und statt eines SQL-Fehlers eine `Error`-Zeile geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDeleteItemSupplier"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n ABC\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht die Lieferantenzuordnung (AddItems-Datensatz) eines Artikels für einen Lieferanten, sofern keine offenen Lieferantenbestellungen bestehen.\n\nEntfernt genau einen Artikel-Lieferanten-Datensatz aus `AddItems`.\n\n1. `ItemKey` = `0` wird als `NULL` behandelt, eine leere `ItemNrInt` als `NULL`.\n2. **Kandidaten-Artikel** sind alle Zeilen in `Items`, bei denen `ItemNrInt` = `@ItemNrInt` **oder** `ItemKey` = `@ItemKey` **oder** `EANUPC` = `@EAN` gilt. Die Kriterien sind mit ODER verknüpft, daher können mehrere Artikel Kandidaten werden.\n3. In `AddItems` werden die Datensätze dieser Kandidaten-Artikel zum Lieferanten `@SupplNr` gesucht. Ist `@EAN` angegeben, muss zusätzlich `EanUpc` des `AddItems`-Datensatzes übereinstimmen.\n4. Wird kein Datensatz gefunden, kommt der Fehler *No records found with provided parameters.* zurück. Bei mehr als einem Datensatz kommt der Fehler *Item could not be uniquely identified.* zurück. In beiden Fällen wird nichts geändert.\n5. Ist einer der Kandidaten-Artikel in einer Lieferantenbestellung dieses Lieferanten enthalten, deren Status als offen gekennzeichnet ist (`IsAllOpen` = 1, z. B. NEW, BES, CON), wird ein Fehler geliefert und nichts gelöscht.\n6. Andernfalls wird der `AddItems`-Datensatz in einer Transaktion gelöscht (bzw. mit Savepoint, wenn der Aufrufer bereits eine offene Transaktion hat).\n7. Wurde `@EAN` angegeben, entspricht der Haupt-Barcode `Items.EanUpc` dem Wert `@EAN` und trägt kein `AddItems`-Datensatz der Kandidaten-Artikel diese EAN mehr, wird `Items.EanUpc` durch den `EanUpc` eines der verbleibenden `AddItems`-Datensätze des Artikels ersetzt. Datensätze anderer Lieferanten als `MGS` werden bevorzugt.\n8. Es wird eine einzelne Statuszeile mit `STATUS` und `MESSAGE` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. `0` gilt als nicht gesetzt. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer. Ein leerer String gilt als nicht gesetzt. |\n| `SupplNr` | varchar(4) | Ja | Lieferantennummer des Lieferanten, dessen Zuordnung gelöscht wird. |\n| `EAN` | varchar(13) | Nein | EAN/UPC-Barcode. Dient zur Suche des Artikels über `Items.EANUPC` und schränkt, wenn gesetzt, den `AddItems`-Datensatz zusätzlich auf diese EAN ein. Löst außerdem das Ersetzen des Haupt-Barcodes aus, wenn dieser nicht mehr verwendet wird. |\n\n- Alle Abfragen verwenden `NOLOCK`, daher können die Eindeutigkeits- und Bestellprüfungen auch nicht festgeschriebene Daten sehen.\n- Da die Artikelkriterien mit ODER verknüpft sind, erweitert die Angabe mehrerer Kennungen, die auf verschiedene Artikel zeigen, die Kandidatenmenge. Die Prüfung auf offene Lieferantenbestellungen und die Barcode-Aktualisierung gelten für **alle** Kandidaten-Artikel, nicht nur für den Artikel, dessen `AddItems`-Datensatz gelöscht wurde.\n- Bleibt beim Ersetzen des Barcodes kein `AddItems`-Datensatz für einen Artikel übrig, wird `Items.EanUpc` auf `NULL` gesetzt.\n- Ein leerer String für `EAN` wird nicht in `NULL` umgewandelt, sondern als Filterwert verwendet.\n- Die Erfolgsmeldung enthält `ItemNrInt` nur, wenn dieser Wert übergeben wurde; bei Aufruf nur mit `ItemKey` oder `EAN` bleibt dieser Teil leer.\n- Die Erfolgszeile wird erzeugt, bevor die temporären Tabellen über `util.TempTableDrop` (nicht beigefügt) gelöscht werden und bevor der Commit erfolgt. Tritt dabei ein Fehler auf, kann zusätzlich eine Fehlerzeile folgen.\n- Fehler im Lösch-/Update-Block werden abgefangen, die Transaktion (bzw. der Savepoint) wird zurückgerollt und statt eines SQL-Fehlers eine `Error`-Zeile geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDeleteItemSupplier"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n Item with ItemNrInt: ART-10045 and SupplNr: ABC was deleted.\n \n"
}
]
},
{
"name": "pixiDispoGetItems",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert einen Block von Artikeln mit bevorzugtem Lieferanten, Preisen, Bestand und lagerortspezifischen Dispositionsdaten für den Export in die Logcontrol-Dispo-Software.\n\nExportiert Artikelstammdaten für die Dispositionssoftware von Logcontrol. Der Aufruf arbeitet blockweise.\n\n1. **Kandidatenauswahl:** Aus `items` werden die ersten `ItemCount` Artikel mit `ItemKey` größer als `ItemKeyStart` (aufsteigend nach `ItemKey`) samt Standardlieferant gelesen.\n2. **Bevorzugter Lieferant:** Existiert ein `AddItems`-Datensatz mit `PreferredSupplier = 1`, ersetzt dessen Lieferant den Standardlieferanten des Artikels.\n3. **Zusatzdaten je Artikel:**\n - Artikel-Tags (Tags mit `TypeId = 1`) als kommagetrennte Liste,\n - das früheste `OrderDate` aller Auftragspositionen des Artikels,\n - die Summe der Lagerplatzmengen (`BinItemQTY`) über alle Lagerplätze in Lagerorten, die kein Sonderlager sind (`SpecialStock <> 1`).\n4. **Ergebnis:** eine Zeile je Artikel **und Lagerort** aus `ItemLocationSpecific`. Es werden nur Zeilen geliefert, bei denen\n - der Lieferant in `Suppliers` existiert,\n - ein `AddItems`-Datensatz für Artikel und diesen Lieferanten vorhanden ist,\n - der Lagerort kein Sonderlager ist,\n - und, falls `LocationIds` angegeben ist, die `LocID` in der kommagetrennten Liste enthalten ist.\n\nDie Sortierung erfolgt aufsteigend nach `ItemKey`. Dezimalwerte (`SupplPrice`, `Price`) werden als Text mit Komma als Dezimaltrennzeichen geliefert, Datumswerte im Format `tt.mm.jjjj`. Einfache und doppelte Anführungszeichen werden aus dem Artikelnamen entfernt.\n\n**Paging:** Für den nächsten Block `ItemKeyStart` auf den höchsten `ItemKey` des vorherigen Blocks setzen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKeyStart` | int | Nein | Es werden nur Artikel mit einem `ItemKey` größer als dieser Wert berücksichtigt. `0` für den ersten Block, danach der höchste gelieferte `ItemKey`. |\n| `LocationIds` | varchar(max) | Nein | Optionale kommagetrennte Liste von Lagerort-IDs (`LocID`). Es werden nur Zeilen dieser Lagerorte geliefert. `NULL` oder leer liefert alle Lagerorte ohne Sonderlager. |\n| `ItemCount` | int | Nein | Maximale Anzahl der je Aufruf aus `items` gelesenen Kandidatenartikel (Blockgröße). |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- `ItemCount` begrenzt die Anzahl der **Kandidatenartikel**, nicht die Anzahl der Ergebniszeilen. Durch die Zeilen je Lagerort können es mehr Zeilen sein; durch die Inner Joins (Lieferant, `AddItems`, `ItemLocationSpecific`, Lagerort ohne Sonderlager, Lagerortfilter) können es weniger oder gar keine sein, obwohl weitere Artikel existieren. Ein leeres Ergebnis bedeutet daher nicht zwingend das Ende der Artikelliste; `ItemKeyStart` sollte über den Blockbereich weitergesetzt werden, statt abzubrechen.\n- `Quantity` wird über die Auftragspositionsdaten verknüpft: Für Artikel ohne Auftragsposition ist `Quantity` immer `0`, auch wenn Bestand vorhanden ist.\n- `Quantity` ist die Summe über alle Lagerorte ohne Sonderlager, nicht die Menge des Lagerorts in `LocationId` (dafür `LocationQuantity`).\n- `Tags` beginnt mit einem führenden Leerzeichen (nur das erste Komma wird entfernt); Sonderzeichen wie `&` werden durch die Verkettung XML-maskiert.\n- Ein leerer oder nur aus Leerzeichen bestehender Wert für `LocationIds` wird wie `NULL` behandelt (kein Lagerortfilter). Listeneinträge werden getrimmt und als `varchar(10)` verglichen.\n- `VATLevel`: `L` bei `MwStSatz = 2`, `0` bei `MwStSatz = 3`, sonst `H`. `Typ` ist immer `0100`.\n- Temporäre Tabellen werden über `util.TempTableDrop` gelöscht (nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDispoGetItems"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert einen Block von Artikeln mit bevorzugtem Lieferanten, Preisen, Bestand und lagerortspezifischen Dispositionsdaten für den Export in die Logcontrol-Dispo-Software.\n\nExportiert Artikelstammdaten für die Dispositionssoftware von Logcontrol. Der Aufruf arbeitet blockweise.\n\n1. **Kandidatenauswahl:** Aus `items` werden die ersten `ItemCount` Artikel mit `ItemKey` größer als `ItemKeyStart` (aufsteigend nach `ItemKey`) samt Standardlieferant gelesen.\n2. **Bevorzugter Lieferant:** Existiert ein `AddItems`-Datensatz mit `PreferredSupplier = 1`, ersetzt dessen Lieferant den Standardlieferanten des Artikels.\n3. **Zusatzdaten je Artikel:**\n - Artikel-Tags (Tags mit `TypeId = 1`) als kommagetrennte Liste,\n - das früheste `OrderDate` aller Auftragspositionen des Artikels,\n - die Summe der Lagerplatzmengen (`BinItemQTY`) über alle Lagerplätze in Lagerorten, die kein Sonderlager sind (`SpecialStock <> 1`).\n4. **Ergebnis:** eine Zeile je Artikel **und Lagerort** aus `ItemLocationSpecific`. Es werden nur Zeilen geliefert, bei denen\n - der Lieferant in `Suppliers` existiert,\n - ein `AddItems`-Datensatz für Artikel und diesen Lieferanten vorhanden ist,\n - der Lagerort kein Sonderlager ist,\n - und, falls `LocationIds` angegeben ist, die `LocID` in der kommagetrennten Liste enthalten ist.\n\nDie Sortierung erfolgt aufsteigend nach `ItemKey`. Dezimalwerte (`SupplPrice`, `Price`) werden als Text mit Komma als Dezimaltrennzeichen geliefert, Datumswerte im Format `tt.mm.jjjj`. Einfache und doppelte Anführungszeichen werden aus dem Artikelnamen entfernt.\n\n**Paging:** Für den nächsten Block `ItemKeyStart` auf den höchsten `ItemKey` des vorherigen Blocks setzen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKeyStart` | int | Nein | Es werden nur Artikel mit einem `ItemKey` größer als dieser Wert berücksichtigt. `0` für den ersten Block, danach der höchste gelieferte `ItemKey`. |\n| `LocationIds` | varchar(max) | Nein | Optionale kommagetrennte Liste von Lagerort-IDs (`LocID`). Es werden nur Zeilen dieser Lagerorte geliefert. `NULL` oder leer liefert alle Lagerorte ohne Sonderlager. |\n| `ItemCount` | int | Nein | Maximale Anzahl der je Aufruf aus `items` gelesenen Kandidatenartikel (Blockgröße). |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- `ItemCount` begrenzt die Anzahl der **Kandidatenartikel**, nicht die Anzahl der Ergebniszeilen. Durch die Zeilen je Lagerort können es mehr Zeilen sein; durch die Inner Joins (Lieferant, `AddItems`, `ItemLocationSpecific`, Lagerort ohne Sonderlager, Lagerortfilter) können es weniger oder gar keine sein, obwohl weitere Artikel existieren. Ein leeres Ergebnis bedeutet daher nicht zwingend das Ende der Artikelliste; `ItemKeyStart` sollte über den Blockbereich weitergesetzt werden, statt abzubrechen.\n- `Quantity` wird über die Auftragspositionsdaten verknüpft: Für Artikel ohne Auftragsposition ist `Quantity` immer `0`, auch wenn Bestand vorhanden ist.\n- `Quantity` ist die Summe über alle Lagerorte ohne Sonderlager, nicht die Menge des Lagerorts in `LocationId` (dafür `LocationQuantity`).\n- `Tags` beginnt mit einem führenden Leerzeichen (nur das erste Komma wird entfernt); Sonderzeichen wie `&` werden durch die Verkettung XML-maskiert.\n- Ein leerer oder nur aus Leerzeichen bestehender Wert für `LocationIds` wird wie `NULL` behandelt (kein Lagerortfilter). Listeneinträge werden getrimmt und als `varchar(10)` verglichen.\n- `VATLevel`: `L` bei `MwStSatz = 2`, `0` bei `MwStSatz = 3`, sonst `H`. `Typ` ist immer `0100`.\n- Temporäre Tabellen werden über `util.TempTableDrop` gelöscht (nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDispoGetItems"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1024\n 4,2500\n Kaffeebecher Keramik 300 ml\n 6\n 20\n 12\n L001\n -\n KB-300\n MUG-300-W\n 148\n 14.05.2024\n 0100\n Keramik Großhandel GmbH\n 03.02.2021\n 11.02.2021\n Küche, Geschenk\n 5\n 1\n 9,9500\n H\n 0\n 001\n 148\n 200\n 30\n \n"
}
]
},
{
"name": "pixiEmillGetItemCategories",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Artikelkategorien mit Kennung und Bezeichnung, sortiert nach Bezeichnung.\n\nLiefert die vollständige Liste der Artikelkategorien aus der Tabelle `TontrArten`.\n\n- Der Aufruf hat keine Parameter und wendet keinen Filter an.\n- Jede Zeile enthält die Kategoriekennung (`ArtCategory`) und deren Bezeichnung (`ArtCategoryDescription`).\n- Die Zeilen sind alphabetisch nach Bezeichnung sortiert.\n\nDer Aufruf gehört zur eMill-Anbindung (Tag `Tech_eMill`).\n\nDie Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können daher sichtbar sein. Die Datentypen der Spalten sind im Code nicht ersichtlich und daher als `unknown` angegeben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEmillGetItemCategories"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Artikelkategorien mit Kennung und Bezeichnung, sortiert nach Bezeichnung.\n\nLiefert die vollständige Liste der Artikelkategorien aus der Tabelle `TontrArten`.\n\n- Der Aufruf hat keine Parameter und wendet keinen Filter an.\n- Jede Zeile enthält die Kategoriekennung (`ArtCategory`) und deren Bezeichnung (`ArtCategoryDescription`).\n- Die Zeilen sind alphabetisch nach Bezeichnung sortiert.\n\nDer Aufruf gehört zur eMill-Anbindung (Tag `Tech_eMill`).\n\nDie Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können daher sichtbar sein. Die Datentypen der Spalten sind im Code nicht ersichtlich und daher als `unknown` angegeben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEmillGetItemCategories"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n BU\n Bücher\n \n \n EL\n Elektronik\n \n"
}
]
},
{
"name": "pixiGetCategories",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Artikelkategorien (Tabelle TontrArten), optional gefiltert nach Schlüssel, Kurzbezeichnung oder Text.\n\nLiest die Kategorie-Stammdaten aus `TontrArten` und liefert Schlüssel, Kurzbezeichnung und Bezeichnung jeder Kategorie.\n\nLeere Werte werden zuerst normalisiert: `TontrArtKey` = `0` sowie leere Zeichenketten für `TontrShort` oder `TontrText` werden als `NULL` behandelt.\n\nEs wird immer nur **ein** Filter angewendet, in folgender Rangfolge:\n\n1. Ist `TontrArtKey` gesetzt, wird nur die Kategorie mit diesem Schlüssel geliefert.\n2. Andernfalls, wenn `TontrShort` gesetzt ist, werden Kategorien mit exakt passender Kurzbezeichnung geliefert.\n3. Andernfalls, wenn `TontrText` gesetzt ist, werden Kategorien mit exakt passendem Text geliefert.\n4. Ist kein Parameter gesetzt, werden alle Kategorien geliefert.\n\nDas Ergebnis ist stets aufsteigend nach `TontrText` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TontrArtKey` | int | Nein | Schlüssel der Kategorie. `0` wird als `NULL` behandelt. Hat die höchste Filterpriorität. |\n| `TontrShort` | varchar(50) | Nein | Kurzbezeichnung der Kategorie (exakter Vergleich). Leere Zeichenkette wird als `NULL` behandelt. Wird nur verwendet, wenn `TontrArtKey` nicht gesetzt ist. |\n| `TontrText` | varchar(50) | Nein | Bezeichnung der Kategorie (exakter Vergleich). Leere Zeichenkette wird als `NULL` behandelt. Wird nur verwendet, wenn weder `TontrArtKey` noch `TontrShort` gesetzt ist. |\n\n- Filter werden nicht kombiniert: Werden mehrere Parameter übergeben, gilt nur der mit der höchsten Priorität (`TontrArtKey` > `TontrShort` > `TontrText`); die übrigen werden ignoriert.\n- Der Vergleich ist exakt (`=`), ohne Platzhalter oder Teilsuche.\n- Die Tabelle wird mit `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein.\n- Gibt es keinen Treffer, wird eine leere Ergebnismenge geliefert; eine Fehlerzeile gibt es nicht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCategories"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Artikelkategorien (Tabelle TontrArten), optional gefiltert nach Schlüssel, Kurzbezeichnung oder Text.\n\nLiest die Kategorie-Stammdaten aus `TontrArten` und liefert Schlüssel, Kurzbezeichnung und Bezeichnung jeder Kategorie.\n\nLeere Werte werden zuerst normalisiert: `TontrArtKey` = `0` sowie leere Zeichenketten für `TontrShort` oder `TontrText` werden als `NULL` behandelt.\n\nEs wird immer nur **ein** Filter angewendet, in folgender Rangfolge:\n\n1. Ist `TontrArtKey` gesetzt, wird nur die Kategorie mit diesem Schlüssel geliefert.\n2. Andernfalls, wenn `TontrShort` gesetzt ist, werden Kategorien mit exakt passender Kurzbezeichnung geliefert.\n3. Andernfalls, wenn `TontrText` gesetzt ist, werden Kategorien mit exakt passendem Text geliefert.\n4. Ist kein Parameter gesetzt, werden alle Kategorien geliefert.\n\nDas Ergebnis ist stets aufsteigend nach `TontrText` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TontrArtKey` | int | Nein | Schlüssel der Kategorie. `0` wird als `NULL` behandelt. Hat die höchste Filterpriorität. |\n| `TontrShort` | varchar(50) | Nein | Kurzbezeichnung der Kategorie (exakter Vergleich). Leere Zeichenkette wird als `NULL` behandelt. Wird nur verwendet, wenn `TontrArtKey` nicht gesetzt ist. |\n| `TontrText` | varchar(50) | Nein | Bezeichnung der Kategorie (exakter Vergleich). Leere Zeichenkette wird als `NULL` behandelt. Wird nur verwendet, wenn weder `TontrArtKey` noch `TontrShort` gesetzt ist. |\n\n- Filter werden nicht kombiniert: Werden mehrere Parameter übergeben, gilt nur der mit der höchsten Priorität (`TontrArtKey` > `TontrShort` > `TontrText`); die übrigen werden ignoriert.\n- Der Vergleich ist exakt (`=`), ohne Platzhalter oder Teilsuche.\n- Die Tabelle wird mit `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein.\n- Gibt es keinen Treffer, wird eine leere Ergebnismenge geliefert; eine Fehlerzeile gibt es nicht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCategories"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 3\n BOOK\n Books\n \n \n 5\n CD\n Music CDs\n \n"
}
]
},
{
"name": "pixiGetEanByItemNr",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10001234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den EAN/UPC-Code eines Artikels anhand seiner internen Artikelnummer.\n\nSkalarfunktion, die in `Items` den Artikel sucht, dessen `ItemNrInt` dem Parameter `ItemNrInt` entspricht, und dessen `EANUPC`-Wert zurückgibt.\n\n- Wird kein Artikel gefunden, ist das Ergebnis `NULL`.\n- Ist `EANUPC` beim Artikel leer oder `NULL`, wird dieser Wert unverändert zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | Ja | Interne Artikelnummer (`ItemNrInt`) des Artikels, dessen EAN abgefragt wird. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können zurückgegeben werden.\n- Der Rückgabetyp ist `varchar(13)`; längere Werte in `EANUPC` würden auf 13 Zeichen gekürzt.\n- Gäbe es mehrere Zeilen mit derselben `ItemNrInt`, würde der Wert einer davon ohne definierte Reihenfolge zurückgegeben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetEanByItemNr"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10001234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den EAN/UPC-Code eines Artikels anhand seiner internen Artikelnummer.\n\nSkalarfunktion, die in `Items` den Artikel sucht, dessen `ItemNrInt` dem Parameter `ItemNrInt` entspricht, und dessen `EANUPC`-Wert zurückgibt.\n\n- Wird kein Artikel gefunden, ist das Ergebnis `NULL`.\n- Ist `EANUPC` beim Artikel leer oder `NULL`, wird dieser Wert unverändert zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | Ja | Interne Artikelnummer (`ItemNrInt`) des Artikels, dessen EAN abgefragt wird. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können zurückgegeben werden.\n- Der Rückgabetyp ist `varchar(13)`; längere Werte in `EANUPC` würden auf 13 Zeichen gekürzt.\n- Gäbe es mehrere Zeilen mit derselben `ItemNrInt`, würde der Wert einer davon ohne definierte Reihenfolge zurückgegeben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetEanByItemNr"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4012345678901\n \n"
}
]
},
{
"name": "pixiGetEKPriceHistory",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Historie der Einkaufs- (EK) und Verkaufspreise aus der Artikelhistorie, optional gefiltert nach Artikelnummer und Zeitraum, mit Paging.\n\nLiest Preis-Historiensätze aus `ItemsHist` und liefert sie seitenweise.\n\n**Filter**\n- `ItemNrInternal`: wenn nicht leer, werden nur Historiensätze geliefert, deren interne Artikelnummer (`ItemNrInt`) diesem Wert entspricht. Leer oder `NULL` liefert alle Artikel.\n- `FromDate` / `ToDate`: Filter auf `UpdateDate` (an beiden Enden inklusive).\n - beide gesetzt: `UpdateDate` zwischen `FromDate` und `ToDate`\n - nur `FromDate`: `UpdateDate` >= `FromDate`\n - nur `ToDate`: `UpdateDate` <= `ToDate`\n - keiner: kein Datumsfilter\n\n**Sortierung und Paging**\n- Die Zeilen werden mit `RowNumber` (ab 1) nummeriert, sortiert nach `UpdateDate`, dann Artikelschlüssel, dann Einkaufspreis, jeweils aufsteigend (älteste Änderung zuerst).\n- Geliefert werden nur Zeilen mit `RowNumber` zwischen `StartRow` und `StartRow + RowCount` (beide inklusive), sortiert nach `RowNumber`.\n- `RowCount = 0` wird als 100 behandelt.\n\nZu jedem Historiensatz wird die aktuelle Lieferantennummer (`SupplNr`) aus dem Artikelstamm `Items` ergänzt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemNrInternal` | varchar(250) | Nein | Interne Artikelnummer als Filter (`ItemNrInt`). Leer oder `NULL` liefert die Historie aller Artikel. |\n| `FromDate` | datetime | Nein | Untergrenze (inklusive) für `UpdateDate`. Leer, `NULL` oder `1900-01-01` bedeutet keine Untergrenze. |\n| `ToDate` | datetime | Nein | Obergrenze (inklusive, mit Uhrzeit) für `UpdateDate`. Leer, `NULL` oder `1900-01-01` bedeutet keine Obergrenze. |\n| `RowCount` | int | Nein | Seitengröße bzw. Offset. Geliefert werden die Zeilen von `StartRow` bis `StartRow + RowCount`. `0` wird als 100 behandelt. |\n| `StartRow` | int | Nein | Erste `RowNumber` der Seite (inklusive). Die Nummerierung beginnt bei 1. |\n\n- **Überlappung beim Paging:** Der Seitenbereich ist an beiden Enden inklusive. Mit `StartRow = 0` und `RowCount = 100` werden die Zeilen 1–100 geliefert, mit `StartRow = 100` die Zeilen 100–200 (101 Zeilen). Aufeinanderfolgende Seiten teilen sich daher eine Zeile, sofern `StartRow` nicht um `RowCount + 1` erhöht wird.\n- Ein Kommentar im Code nennt einen Standard von 1000 Zeilen, tatsächlich verwendet der Code 100, wenn `RowCount` 0 ist.\n- Der Leerstring-Standard der Datumsparameter wird zu `1900-01-01` konvertiert; genau dieses Datum wird als „kein Filter“ behandelt.\n- `ToDate` wird inklusive Uhrzeit verglichen. Ein Datum ohne Uhrzeit (z. B. `2024-06-30T00:00:00`) schließt spätere Änderungen desselben Tages aus.\n- Historiensätze mit `NULL` in `UpdateDate` oder `ItemNrInt` werden nie geliefert, da die Filterbedingungen immer ausgewertet werden.\n- `SupplNr` ist der aktuell in `Items` hinterlegte Lieferant, nicht der Lieferant zum Zeitpunkt der Änderung; er ist `NULL`, wenn der Artikel nicht mehr existiert.\n- Es werden keine `NOLOCK`-Hinweise verwendet. Ohne Artikelfilter läuft die Nummerierung über die gesamte Historientabelle, was bei großen Datenmengen langsam sein kann.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetEKPriceHistory"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Historie der Einkaufs- (EK) und Verkaufspreise aus der Artikelhistorie, optional gefiltert nach Artikelnummer und Zeitraum, mit Paging.\n\nLiest Preis-Historiensätze aus `ItemsHist` und liefert sie seitenweise.\n\n**Filter**\n- `ItemNrInternal`: wenn nicht leer, werden nur Historiensätze geliefert, deren interne Artikelnummer (`ItemNrInt`) diesem Wert entspricht. Leer oder `NULL` liefert alle Artikel.\n- `FromDate` / `ToDate`: Filter auf `UpdateDate` (an beiden Enden inklusive).\n - beide gesetzt: `UpdateDate` zwischen `FromDate` und `ToDate`\n - nur `FromDate`: `UpdateDate` >= `FromDate`\n - nur `ToDate`: `UpdateDate` <= `ToDate`\n - keiner: kein Datumsfilter\n\n**Sortierung und Paging**\n- Die Zeilen werden mit `RowNumber` (ab 1) nummeriert, sortiert nach `UpdateDate`, dann Artikelschlüssel, dann Einkaufspreis, jeweils aufsteigend (älteste Änderung zuerst).\n- Geliefert werden nur Zeilen mit `RowNumber` zwischen `StartRow` und `StartRow + RowCount` (beide inklusive), sortiert nach `RowNumber`.\n- `RowCount = 0` wird als 100 behandelt.\n\nZu jedem Historiensatz wird die aktuelle Lieferantennummer (`SupplNr`) aus dem Artikelstamm `Items` ergänzt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemNrInternal` | varchar(250) | Nein | Interne Artikelnummer als Filter (`ItemNrInt`). Leer oder `NULL` liefert die Historie aller Artikel. |\n| `FromDate` | datetime | Nein | Untergrenze (inklusive) für `UpdateDate`. Leer, `NULL` oder `1900-01-01` bedeutet keine Untergrenze. |\n| `ToDate` | datetime | Nein | Obergrenze (inklusive, mit Uhrzeit) für `UpdateDate`. Leer, `NULL` oder `1900-01-01` bedeutet keine Obergrenze. |\n| `RowCount` | int | Nein | Seitengröße bzw. Offset. Geliefert werden die Zeilen von `StartRow` bis `StartRow + RowCount`. `0` wird als 100 behandelt. |\n| `StartRow` | int | Nein | Erste `RowNumber` der Seite (inklusive). Die Nummerierung beginnt bei 1. |\n\n- **Überlappung beim Paging:** Der Seitenbereich ist an beiden Enden inklusive. Mit `StartRow = 0` und `RowCount = 100` werden die Zeilen 1–100 geliefert, mit `StartRow = 100` die Zeilen 100–200 (101 Zeilen). Aufeinanderfolgende Seiten teilen sich daher eine Zeile, sofern `StartRow` nicht um `RowCount + 1` erhöht wird.\n- Ein Kommentar im Code nennt einen Standard von 1000 Zeilen, tatsächlich verwendet der Code 100, wenn `RowCount` 0 ist.\n- Der Leerstring-Standard der Datumsparameter wird zu `1900-01-01` konvertiert; genau dieses Datum wird als „kein Filter“ behandelt.\n- `ToDate` wird inklusive Uhrzeit verglichen. Ein Datum ohne Uhrzeit (z. B. `2024-06-30T00:00:00`) schließt spätere Änderungen desselben Tages aus.\n- Historiensätze mit `NULL` in `UpdateDate` oder `ItemNrInt` werden nie geliefert, da die Filterbedingungen immer ausgewertet werden.\n- `SupplNr` ist der aktuell in `Items` hinterlegte Lieferant, nicht der Lieferant zum Zeitpunkt der Änderung; er ist `NULL`, wenn der Artikel nicht mehr existiert.\n- Es werden keine `NOLOCK`-Hinweise verwendet. Ohne Artikelfilter läuft die Nummerierung über die gesamte Historientabelle, was bei großen Datenmengen langsam sein kann.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetEKPriceHistory"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 1523\n 70012\n SUP-88213\n 4711-BLK\n 4006381333931\n 19.9900\n 8.4500\n 2024-02-14T09:31:22\n \n \n 2\n 1523\n 70012\n SUP-88213\n 4711-BLK\n 4006381333931\n 21.9900\n 9.1000\n 2024-05-03T14:05:10\n \n"
}
]
},
{
"name": "pixiGetItemBundleDefinition",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Bestandteile und Mengen eines Bundle-Artikels, identifiziert über Artikelschlüssel, interne Artikelnummer, EAN/UPC oder Lieferantenartikelnummer.\n\nErmittelt die in `BundleItems` hinterlegte Bundle-Definition eines Bundle-Artikels und liefert je Bestandteil eine Zeile. Die Stammdaten der Bestandteile stammen aus `Items`.\n\nEs wird nur ein Identifikator verwendet. Die Prüfung erfolgt in dieser Rangfolge:\n\n1. `ItemKey`, wenn größer als 0.\n2. `ItemNrInt`, wenn nicht leer. Verwendet wird der erste Artikel mit dieser internen Artikelnummer (`TOP 1` ohne Sortierung).\n3. `EANUPC`, wenn nicht leer. Verwendet wird der erste Artikel mit dieser EAN/UPC (`TOP 1` ohne Sortierung).\n4. `ItemNrSuppl`, wenn nicht leer. Verwendet werden **alle** Artikel mit dieser Lieferantenartikelnummer. Die Bestandteile aller passenden Bundles erscheinen gemeinsam in einem Ergebnis.\n\nSobald ein Parameter mit höherer Priorität gesetzt ist, werden die übrigen ignoriert.\n\nIn diesen Fällen liefert der Aufruf keine Zeilen:\n\n- kein Identifikator angegeben\n- der Identifikator passt zu keinem Artikel\n- der Artikel ist kein Bundle\n\nDie Ergebnismenge hat in allen Fällen dieselben Spalten. Eine Sortierung findet nicht statt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Bundle-Artikels. Hat die höchste Priorität, wenn größer als 0. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer des Bundle-Artikels. Wird nur verwendet, wenn `ItemKey` nicht gesetzt ist. |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC des Bundle-Artikels. Wird nur verwendet, wenn `ItemKey` und `ItemNrInt` nicht gesetzt sind. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferantenartikelnummer des Bundle-Artikels. Wird nur verwendet, wenn kein anderer Identifikator gesetzt ist. Alle Artikel mit dieser Nummer werden berücksichtigt. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Teilen sich mehrere Artikel dieselbe `ItemNrInt` oder `EANUPC`, ist nicht festgelegt, welcher Artikel verwendet wird.\n- Bei Suche über `ItemNrSuppl` lassen sich die Bestandteile verschiedener Bundles nicht unterscheiden, da das Ergebnis keine Spalte für den übergeordneten Bundle-Artikel enthält.\n- Die Artikeldaten der Bestandteile werden per `LEFT JOIN` ermittelt. Existiert ein Bestandteil nicht mehr in `Items`, bleiben dessen Artikelspalten leer (NULL), während `BundleItemKey` und `Qty` gefüllt sind.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemBundleDefinition"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Bestandteile und Mengen eines Bundle-Artikels, identifiziert über Artikelschlüssel, interne Artikelnummer, EAN/UPC oder Lieferantenartikelnummer.\n\nErmittelt die in `BundleItems` hinterlegte Bundle-Definition eines Bundle-Artikels und liefert je Bestandteil eine Zeile. Die Stammdaten der Bestandteile stammen aus `Items`.\n\nEs wird nur ein Identifikator verwendet. Die Prüfung erfolgt in dieser Rangfolge:\n\n1. `ItemKey`, wenn größer als 0.\n2. `ItemNrInt`, wenn nicht leer. Verwendet wird der erste Artikel mit dieser internen Artikelnummer (`TOP 1` ohne Sortierung).\n3. `EANUPC`, wenn nicht leer. Verwendet wird der erste Artikel mit dieser EAN/UPC (`TOP 1` ohne Sortierung).\n4. `ItemNrSuppl`, wenn nicht leer. Verwendet werden **alle** Artikel mit dieser Lieferantenartikelnummer. Die Bestandteile aller passenden Bundles erscheinen gemeinsam in einem Ergebnis.\n\nSobald ein Parameter mit höherer Priorität gesetzt ist, werden die übrigen ignoriert.\n\nIn diesen Fällen liefert der Aufruf keine Zeilen:\n\n- kein Identifikator angegeben\n- der Identifikator passt zu keinem Artikel\n- der Artikel ist kein Bundle\n\nDie Ergebnismenge hat in allen Fällen dieselben Spalten. Eine Sortierung findet nicht statt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Bundle-Artikels. Hat die höchste Priorität, wenn größer als 0. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer des Bundle-Artikels. Wird nur verwendet, wenn `ItemKey` nicht gesetzt ist. |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC des Bundle-Artikels. Wird nur verwendet, wenn `ItemKey` und `ItemNrInt` nicht gesetzt sind. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferantenartikelnummer des Bundle-Artikels. Wird nur verwendet, wenn kein anderer Identifikator gesetzt ist. Alle Artikel mit dieser Nummer werden berücksichtigt. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Teilen sich mehrere Artikel dieselbe `ItemNrInt` oder `EANUPC`, ist nicht festgelegt, welcher Artikel verwendet wird.\n- Bei Suche über `ItemNrSuppl` lassen sich die Bestandteile verschiedener Bundles nicht unterscheiden, da das Ergebnis keine Spalte für den übergeordneten Bundle-Artikel enthält.\n- Die Artikeldaten der Bestandteile werden per `LEFT JOIN` ermittelt. Existiert ein Bestandteil nicht mehr in `Items`, bleiben dessen Artikelspalten leer (NULL), während `BundleItemKey` und `Qty` gefüllt sind.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemBundleDefinition"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1201\n 2\n ART-1201\n SUP-1201\n 4006381333948\n Kugelschreiber blau\n 1.99\n \n \n 1305\n 1\n ART-1305\n SUP-1305\n 4006381333955\n Notizblock A5\n 3.49\n \n"
}
]
},
{
"name": "pixiGetItemInfo",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Stammdaten, Bestand, Lieferanten-, MwSt.-, Tag- und Zollinformationen zu einem oder mehreren Artikeln, gesucht über Artikelschlüssel, EAN, Artikelnummern oder eine XML-Liste.\n\nSucht Artikel und liefert pro gefundenem Artikel eine Zeile mit dessen Stammdaten.\n\n**Normalisierung der Eingaben**\n- `ItemKey` = 0 und leere Zeichenketten werden als `NULL` behandelt.\n- Ist keiner der Parameter `ItemKey`, `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `ItemXML` oder `InternalItemNumber` gesetzt, wird statt Artikeldaten eine einzelne Fehlerzeile geliefert. `LocID` allein reicht nicht aus.\n\n**Suchkriterien**\n\nDie Einzelparameter und jeder Eintrag `/ITEMS/ITEM` aus `ItemXML` bilden eine Liste von Suchkriterien. Jedes Kriterium wird gegen `pixi.ItemCode` geprüft:\n- `ItemKey` / `ITEMKEY`: Artikel-ID\n- `EANUPC` / `EAN`: Codetyp 1 (EAN)\n- `ItemNrInt` / `ITEMNRINT`: Codetyp 2 (interne Artikelnummer)\n- `InternalItemNumber` / `INTERNALITEMNUMBER`: Codetyp 3\n- `ItemNrSuppl` / `ITEMNRSUPPL`: Codetyp 4 (Lieferanten-Artikelnummer)\n\nAlle Treffer werden mit **ODER**-Logik (Vereinigungsmenge) kombiniert: Ein Artikel wird geliefert, wenn er zu einem der angegebenen Werte passt. Doppelte Treffer werden entfernt.\n\n**Ausgabewerte**\n- `LocID` wählt lagerspezifische Werte aus `ItemLocationSpecific`: `MinStockQty`, `Quantity`, `SafetyStock`, `TargetStock`. Ohne Lager (oder ohne lagerspezifischen Datensatz) werden die globalen Artikelwerte verwendet, `SafetyStock`/`TargetStock` sind dann 0.\n- `ConsiderFavouriteSupplier` = 1 verwendet den aktiven bevorzugten Lieferanten (`AddItems.PreferredSupplier` = 1, Lieferant nicht deaktiviert) für `SupplPrice`, `SupplNr`, `ItemNrSuppl`, `EANUPC` und `MinOrderQty`. Mit dem Standardwert 0 werden die Werte des Artikels und der `AddItems`-Datensatz des Hauptlieferanten verwendet.\n- `VATLevel` ergibt sich aus dem MwSt.-Satz: 2 = `MwSt_Low`, 3 = `MwSt_Null`, alle anderen Werte = `MwSt_High`.\n- `ItemTAGs` enthält alle Tags des Artikels, getrennt durch `|`. `ABC` enthält nur die System-Tags `A`, `B` oder `C`.\n\nDie Zeilen werden ohne definierte Sortierung geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Gesuchter Artikelschlüssel (Artikel-ID). 0 gilt als nicht gesetzt. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer (Codetyp 2 in `pixi.ItemCode`). |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC-Code (Codetyp 1 in `pixi.ItemCode`). |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer (Codetyp 4 in `pixi.ItemCode`). |\n| `LocID` | varchar(3) | Nein | Lager-ID für lagerspezifische Werte (`MinStockQty`, `Quantity`, `SafetyStock`, `TargetStock`). Wirkt nicht als Suchkriterium. |\n| `ItemXML` | varchar(max) | Nein | XML-Liste der gesuchten Artikel: ein `ITEM`-Element pro Kriteriensatz unterhalb von `ITEMS`, mit optionalen Unterelementen `ITEMKEY`, `ITEMNRSUPPL`, `ITEMNRINT`, `EAN`, `INTERNALITEMNUMBER`. |\n| `InternalItemNumber` | varchar(50) | Nein | Zusätzliche interne Artikelnummer (Codetyp 3 in `pixi.ItemCode`). |\n| `ConsiderFavouriteSupplier` | bit | Nein | Bei 1 werden die Lieferantenwerte vom aktiven bevorzugten Lieferanten übernommen. Laut Code-Kommentar \"nicht mehr verwendet\", wird aber weiterhin ausgewertet. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Laut Code-Kommentar wird `ConsiderFavouriteSupplier` \"nicht mehr verwendet\", der Code wertet den Parameter aber weiterhin aus: Bei 1 werden die Werte des bevorzugten Lieferanten verwendet, und `MinOrderQty` ist 0, wenn kein aktiver bevorzugter Lieferant existiert.\n- Auch die Suche über `ItemKey` läuft über `pixi.ItemCode`. Ein Artikel ohne Eintrag in `pixi.ItemCode` wird trotz gültigem Schlüssel nicht gefunden.\n- Mehrere Parameter erweitern das Ergebnis (ODER), sie schränken es nicht ein.\n- In `ItemXML` heißt das EAN-Element `EAN`, nicht `EANUPC`. Tabulatoren werden aus `ITEMKEY` entfernt. Ein nicht numerischer `ITEMKEY` oder fehlerhaftes XML führt zu einem SQL-Fehler.\n- `EANUPC` ist auf 13 Zeichen begrenzt.\n- Durch die Outer Joins (z. B. mehrere Codetyp-3-Einträge oder mehrere aktive bevorzugte Lieferanten) kann ein Artikel mehrfach im Ergebnis erscheinen.\n- Es werden keine Daten geändert; nur temporäre Tabellen werden verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemInfo"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Stammdaten, Bestand, Lieferanten-, MwSt.-, Tag- und Zollinformationen zu einem oder mehreren Artikeln, gesucht über Artikelschlüssel, EAN, Artikelnummern oder eine XML-Liste.\n\nSucht Artikel und liefert pro gefundenem Artikel eine Zeile mit dessen Stammdaten.\n\n**Normalisierung der Eingaben**\n- `ItemKey` = 0 und leere Zeichenketten werden als `NULL` behandelt.\n- Ist keiner der Parameter `ItemKey`, `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `ItemXML` oder `InternalItemNumber` gesetzt, wird statt Artikeldaten eine einzelne Fehlerzeile geliefert. `LocID` allein reicht nicht aus.\n\n**Suchkriterien**\n\nDie Einzelparameter und jeder Eintrag `/ITEMS/ITEM` aus `ItemXML` bilden eine Liste von Suchkriterien. Jedes Kriterium wird gegen `pixi.ItemCode` geprüft:\n- `ItemKey` / `ITEMKEY`: Artikel-ID\n- `EANUPC` / `EAN`: Codetyp 1 (EAN)\n- `ItemNrInt` / `ITEMNRINT`: Codetyp 2 (interne Artikelnummer)\n- `InternalItemNumber` / `INTERNALITEMNUMBER`: Codetyp 3\n- `ItemNrSuppl` / `ITEMNRSUPPL`: Codetyp 4 (Lieferanten-Artikelnummer)\n\nAlle Treffer werden mit **ODER**-Logik (Vereinigungsmenge) kombiniert: Ein Artikel wird geliefert, wenn er zu einem der angegebenen Werte passt. Doppelte Treffer werden entfernt.\n\n**Ausgabewerte**\n- `LocID` wählt lagerspezifische Werte aus `ItemLocationSpecific`: `MinStockQty`, `Quantity`, `SafetyStock`, `TargetStock`. Ohne Lager (oder ohne lagerspezifischen Datensatz) werden die globalen Artikelwerte verwendet, `SafetyStock`/`TargetStock` sind dann 0.\n- `ConsiderFavouriteSupplier` = 1 verwendet den aktiven bevorzugten Lieferanten (`AddItems.PreferredSupplier` = 1, Lieferant nicht deaktiviert) für `SupplPrice`, `SupplNr`, `ItemNrSuppl`, `EANUPC` und `MinOrderQty`. Mit dem Standardwert 0 werden die Werte des Artikels und der `AddItems`-Datensatz des Hauptlieferanten verwendet.\n- `VATLevel` ergibt sich aus dem MwSt.-Satz: 2 = `MwSt_Low`, 3 = `MwSt_Null`, alle anderen Werte = `MwSt_High`.\n- `ItemTAGs` enthält alle Tags des Artikels, getrennt durch `|`. `ABC` enthält nur die System-Tags `A`, `B` oder `C`.\n\nDie Zeilen werden ohne definierte Sortierung geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Gesuchter Artikelschlüssel (Artikel-ID). 0 gilt als nicht gesetzt. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer (Codetyp 2 in `pixi.ItemCode`). |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC-Code (Codetyp 1 in `pixi.ItemCode`). |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer (Codetyp 4 in `pixi.ItemCode`). |\n| `LocID` | varchar(3) | Nein | Lager-ID für lagerspezifische Werte (`MinStockQty`, `Quantity`, `SafetyStock`, `TargetStock`). Wirkt nicht als Suchkriterium. |\n| `ItemXML` | varchar(max) | Nein | XML-Liste der gesuchten Artikel: ein `ITEM`-Element pro Kriteriensatz unterhalb von `ITEMS`, mit optionalen Unterelementen `ITEMKEY`, `ITEMNRSUPPL`, `ITEMNRINT`, `EAN`, `INTERNALITEMNUMBER`. |\n| `InternalItemNumber` | varchar(50) | Nein | Zusätzliche interne Artikelnummer (Codetyp 3 in `pixi.ItemCode`). |\n| `ConsiderFavouriteSupplier` | bit | Nein | Bei 1 werden die Lieferantenwerte vom aktiven bevorzugten Lieferanten übernommen. Laut Code-Kommentar \"nicht mehr verwendet\", wird aber weiterhin ausgewertet. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Laut Code-Kommentar wird `ConsiderFavouriteSupplier` \"nicht mehr verwendet\", der Code wertet den Parameter aber weiterhin aus: Bei 1 werden die Werte des bevorzugten Lieferanten verwendet, und `MinOrderQty` ist 0, wenn kein aktiver bevorzugter Lieferant existiert.\n- Auch die Suche über `ItemKey` läuft über `pixi.ItemCode`. Ein Artikel ohne Eintrag in `pixi.ItemCode` wird trotz gültigem Schlüssel nicht gefunden.\n- Mehrere Parameter erweitern das Ergebnis (ODER), sie schränken es nicht ein.\n- In `ItemXML` heißt das EAN-Element `EAN`, nicht `EANUPC`. Tabulatoren werden aus `ITEMKEY` entfernt. Ein nicht numerischer `ITEMKEY` oder fehlerhaftes XML führt zu einem SQL-Fehler.\n- `EANUPC` ist auf 13 Zeichen begrenzt.\n- Durch die Outer Joins (z. B. mehrere Codetyp-3-Einträge oder mehrere aktive bevorzugte Lieferanten) kann ein Artikel mehrfach im Ergebnis erscheinen.\n- Es werden keine Daten geändert; nur temporäre Tabellen werden verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemInfo"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1234\n 4.2000\n USB-C Cable 1m\n 1\n 10\n 20\n 50\n L001\n Accessories\n ART-10001\n SUP-778-B\n 148\n 9.9900\n MwSt_High\n true\n A|Bestseller\n 4006381333931\n A\n 2\n https://shop.example.com/img/1234_l.jpg\n https://shop.example.com/img/1234_s.jpg\n INT-5501\n 10\n 200\n USB-C to USB-C cable, 1 m, black\n 4.5000\n 0.05\n 2\n 10\n 15\n 85444290\n CN\n Electric conductors\n CableCorp\n \n"
}
]
},
{
"name": "pixiGetItemInfo2",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Stammdaten, Preise, Bestand, Tags und Lieferanteninformationen zu einem oder mehreren Artikeln, gesucht über ItemKey, EAN, Artikelnummern oder eine XML-Liste.\n\nSucht Artikel und liefert je gefundenem Artikel eine Zeile mit Stammdaten, Preisen, Bestand und Tags.\n\n**Normalisierung der Eingaben**\n- `ItemKey` = 0 sowie leere Zeichenketten in `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `ItemXML` und `InternalItemNumber` gelten als nicht angegeben. Ein leerer `LocID` wird als NULL behandelt.\n- Ist keiner der Parameter `ItemKey`, `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `ItemXML` oder `InternalItemNumber` angegeben, wird eine einzelne Fehlerzeile (`Error`, `ErrorMsg`) geliefert. `LocID` allein reicht nicht aus.\n\n**Artikelsuche**\n- Die Einzelparameter und jedes `/ITEMS/ITEM`-Element aus `ItemXML` bilden eine Liste von Suchkriterien. Aus `ITEMKEY` im XML werden Leerzeichen entfernt.\n- Die Artikel werden in der Tabelle der Artikelcodes gesucht, alle Treffer werden zusammengeführt (logisches ODER, ohne Duplikate):\n - `ItemKey` entspricht der Artikel-ID,\n - `EANUPC` / `EAN` entspricht einem Code vom Typ 1 (EAN),\n - `ItemNrInt` entspricht einem Code vom Typ 2,\n - `InternalItemNumber` entspricht einem Code vom Typ 3,\n - `ItemNrSuppl` entspricht einem Code vom Typ 4.\n\n**Ausgabe**\n- Eine Zeile je gefundenem Artikel, sortiert nach `ItemKey`.\n- Ist `LocID` angegeben, stammen `MinStockQty`, `Quantity`, `SafetyStock` und `TargetStock` aus den lagerspezifischen Artikeldaten dieses Lagers; andernfalls (oder wenn keine solchen Daten vorhanden sind) stammen `MinStockQty` und `Quantity` aus dem Artikelstamm, `SafetyStock`/`TargetStock` sind 0.\n- Mit `ConsiderFavouriteSupplier` = 1 werden Preis, Lieferantennummer, Lieferanten-Artikelnummer, EAN und Mindestbestellmenge aus dem aktiven Vorzugslieferanten-Eintrag (Lieferant nicht deaktiviert) übernommen, ersatzweise aus dem Artikelstamm. Mit 0 (Standard) stammen `MinOrderQty` und `EANUPC` aus dem Lieferanteneintrag des Hauptlieferanten des Artikels, ersatzweise aus dem Artikelstamm.\n- `VATLevel` übersetzt den MwSt-Satz-Code 1/2/3 in `MwSt_High`/`MwSt_Low`/`MwSt_Null`.\n- `ItemTAGs` enthält alle Tags des Artikels getrennt durch `|`; `ABC` enthält den System-Tag `A`, `B` oder `C` des Artikels.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel. 0 gilt als nicht angegeben. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer (Artikelcode-Typ 2). Leere Zeichenkette gilt als nicht angegeben. |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC des Artikels (Artikelcode-Typ 1). Leere Zeichenkette gilt als nicht angegeben. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer (Artikelcode-Typ 4). Leere Zeichenkette gilt als nicht angegeben. |\n| `LocID` | varchar(3) | Nein | Lager-ID. Wenn angegeben, werden Bestand, Mindestbestand, Sicherheitsbestand und Zielbestand aus den lagerspezifischen Artikeldaten gelesen. Kein Suchkriterium. |\n| `ItemXML` | varchar(max) | Nein | XML-Liste der zu suchenden Artikel. Jedes `/ITEMS/ITEM`-Element kann `ITEMKEY`, `ITEMNRSUPPL`, `ITEMNRINT`, `EAN` und `INTERNALITEMNUMBER` enthalten. Wird mit den Einzelparametern kombiniert. |\n| `InternalItemNumber` | varchar(50) | Nein | Interne Artikelnummer (Artikelcode-Typ 3). Leere Zeichenkette gilt als nicht angegeben. |\n| `ConsiderFavouriteSupplier` | bit | Nein | Bei 1 werden Lieferantenpreis, Lieferantennummer, Lieferanten-Artikelnummer, EAN und Mindestbestellmenge aus dem aktiven Vorzugslieferanten übernommen. Als nicht mehr verwendet kommentiert, wird vom Code aber weiterhin ausgewertet. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, es können daher nicht festgeschriebene Daten geliefert werden.\n- Die Suche läuft vollständig über die Tabelle der Artikelcodes: Ein Artikel wird über `ItemKey` nur gefunden, wenn mindestens ein Artikelcode-Eintrag vorhanden ist.\n- Obwohl `ConsiderFavouriteSupplier` als \"Not used anymore\" kommentiert ist, wertet der Code den Parameter weiterhin aus. Mit Wert 1 und ohne aktiven Vorzugslieferanten ist `MinOrderQty` 0.\n- Durch die Verknüpfungen in der Ausgabe können mehrere Zeilen je Artikel entstehen, z. B. bei mehreren internen Artikelnummern (Codetyp 3), mehreren Lieferanteneinträgen zum Hauptlieferanten, mehreren Vorzugslieferanten oder mehreren der System-Tags `A`/`B`/`C`.\n- `ITEMKEY`-Werte im XML werden nach `int` konvertiert; ein nicht numerischer Wert führt zu einem SQL-Konvertierungsfehler. Ungültiges XML führt ebenfalls zu einem SQL-Fehler.\n- `ItemTAGs` wird aus der Tag-Zuordnungstabelle `TagMatch` gelesen, `ABC` dagegen aus `ItemTagMatching`; `ItemTAGs` ist NULL, wenn der Artikel keine Tags hat.\n- `VATLevel` ist NULL für MwSt-Satz-Codes außer 1, 2 und 3.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemInfo2"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Stammdaten, Preise, Bestand, Tags und Lieferanteninformationen zu einem oder mehreren Artikeln, gesucht über ItemKey, EAN, Artikelnummern oder eine XML-Liste.\n\nSucht Artikel und liefert je gefundenem Artikel eine Zeile mit Stammdaten, Preisen, Bestand und Tags.\n\n**Normalisierung der Eingaben**\n- `ItemKey` = 0 sowie leere Zeichenketten in `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `ItemXML` und `InternalItemNumber` gelten als nicht angegeben. Ein leerer `LocID` wird als NULL behandelt.\n- Ist keiner der Parameter `ItemKey`, `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `ItemXML` oder `InternalItemNumber` angegeben, wird eine einzelne Fehlerzeile (`Error`, `ErrorMsg`) geliefert. `LocID` allein reicht nicht aus.\n\n**Artikelsuche**\n- Die Einzelparameter und jedes `/ITEMS/ITEM`-Element aus `ItemXML` bilden eine Liste von Suchkriterien. Aus `ITEMKEY` im XML werden Leerzeichen entfernt.\n- Die Artikel werden in der Tabelle der Artikelcodes gesucht, alle Treffer werden zusammengeführt (logisches ODER, ohne Duplikate):\n - `ItemKey` entspricht der Artikel-ID,\n - `EANUPC` / `EAN` entspricht einem Code vom Typ 1 (EAN),\n - `ItemNrInt` entspricht einem Code vom Typ 2,\n - `InternalItemNumber` entspricht einem Code vom Typ 3,\n - `ItemNrSuppl` entspricht einem Code vom Typ 4.\n\n**Ausgabe**\n- Eine Zeile je gefundenem Artikel, sortiert nach `ItemKey`.\n- Ist `LocID` angegeben, stammen `MinStockQty`, `Quantity`, `SafetyStock` und `TargetStock` aus den lagerspezifischen Artikeldaten dieses Lagers; andernfalls (oder wenn keine solchen Daten vorhanden sind) stammen `MinStockQty` und `Quantity` aus dem Artikelstamm, `SafetyStock`/`TargetStock` sind 0.\n- Mit `ConsiderFavouriteSupplier` = 1 werden Preis, Lieferantennummer, Lieferanten-Artikelnummer, EAN und Mindestbestellmenge aus dem aktiven Vorzugslieferanten-Eintrag (Lieferant nicht deaktiviert) übernommen, ersatzweise aus dem Artikelstamm. Mit 0 (Standard) stammen `MinOrderQty` und `EANUPC` aus dem Lieferanteneintrag des Hauptlieferanten des Artikels, ersatzweise aus dem Artikelstamm.\n- `VATLevel` übersetzt den MwSt-Satz-Code 1/2/3 in `MwSt_High`/`MwSt_Low`/`MwSt_Null`.\n- `ItemTAGs` enthält alle Tags des Artikels getrennt durch `|`; `ABC` enthält den System-Tag `A`, `B` oder `C` des Artikels.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel. 0 gilt als nicht angegeben. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer (Artikelcode-Typ 2). Leere Zeichenkette gilt als nicht angegeben. |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC des Artikels (Artikelcode-Typ 1). Leere Zeichenkette gilt als nicht angegeben. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer (Artikelcode-Typ 4). Leere Zeichenkette gilt als nicht angegeben. |\n| `LocID` | varchar(3) | Nein | Lager-ID. Wenn angegeben, werden Bestand, Mindestbestand, Sicherheitsbestand und Zielbestand aus den lagerspezifischen Artikeldaten gelesen. Kein Suchkriterium. |\n| `ItemXML` | varchar(max) | Nein | XML-Liste der zu suchenden Artikel. Jedes `/ITEMS/ITEM`-Element kann `ITEMKEY`, `ITEMNRSUPPL`, `ITEMNRINT`, `EAN` und `INTERNALITEMNUMBER` enthalten. Wird mit den Einzelparametern kombiniert. |\n| `InternalItemNumber` | varchar(50) | Nein | Interne Artikelnummer (Artikelcode-Typ 3). Leere Zeichenkette gilt als nicht angegeben. |\n| `ConsiderFavouriteSupplier` | bit | Nein | Bei 1 werden Lieferantenpreis, Lieferantennummer, Lieferanten-Artikelnummer, EAN und Mindestbestellmenge aus dem aktiven Vorzugslieferanten übernommen. Als nicht mehr verwendet kommentiert, wird vom Code aber weiterhin ausgewertet. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, es können daher nicht festgeschriebene Daten geliefert werden.\n- Die Suche läuft vollständig über die Tabelle der Artikelcodes: Ein Artikel wird über `ItemKey` nur gefunden, wenn mindestens ein Artikelcode-Eintrag vorhanden ist.\n- Obwohl `ConsiderFavouriteSupplier` als \"Not used anymore\" kommentiert ist, wertet der Code den Parameter weiterhin aus. Mit Wert 1 und ohne aktiven Vorzugslieferanten ist `MinOrderQty` 0.\n- Durch die Verknüpfungen in der Ausgabe können mehrere Zeilen je Artikel entstehen, z. B. bei mehreren internen Artikelnummern (Codetyp 3), mehreren Lieferanteneinträgen zum Hauptlieferanten, mehreren Vorzugslieferanten oder mehreren der System-Tags `A`/`B`/`C`.\n- `ITEMKEY`-Werte im XML werden nach `int` konvertiert; ein nicht numerischer Wert führt zu einem SQL-Konvertierungsfehler. Ungültiges XML führt ebenfalls zu einem SQL-Fehler.\n- `ItemTAGs` wird aus der Tag-Zuordnungstabelle `TagMatch` gelesen, `ABC` dagegen aus `ItemTagMatching`; `ItemTAGs` ist NULL, wenn der Artikel keine Tags hat.\n- `VATLevel` ist NULL für MwSt-Satz-Codes außer 1, 2 und 3.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemInfo2"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4711\n 12.5000\n Trekking Backpack 40L\n 1\n 1\n 5\n 10\n L001\n Standard\n ART-10045\n SUP-998877\n 42\n 49.9900\n MwSt_High\n 1\n A|Outdoor|Sale\n 4006381333931\n A\n 2-3 days\n https://shop.example.com/img/4711_l.jpg\n https://shop.example.com/img/4711_s.jpg\n INT-00045\n 0\n 0\n Lightweight trekking backpack with rain cover.\n \n"
}
]
},
{
"name": "pixiGetItemInfoPickList",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikelstammdaten für einen oder mehrere Artikel an einem Lager sowie offene Picklistenpositionen, gepackte Kartonmengen und einen kombinierten Statuscode.\n\nSucht einen oder mehrere Artikel und liefert deren Stammdaten zusammen mit Informationen zu Picklisten und Kartons, in denen sie aktuell vorkommen.\n\n**Prüfung**\n- Sind `ItemKey`, `EANUPC`, `ItemNrSuppl`, `ItemNrInt` und `ItemXML` alle leer, liefert der Aufruf eine Zeile mit `Status` = `0` und einer Meldung, gefolgt von der abschließenden Statuszeile `0000`. `LocID` allein genügt nicht. `ItemKey` = `0` gilt ebenfalls als leer.\n\n**Artikelsuche**\n- Ein einzelner Artikel wird über `COALESCE(EANUPC, ItemNrInt, ItemNrSuppl)` in den scanbaren Artikelcodes ermittelt (`pixi.ItemCode` mit einem Codetyp, bei dem `Scannable` = 1 ist). Verwendet wird der erste Treffer. Ist `ItemKey` übergeben, hat er Vorrang vor der Code-Suche.\n- Zusätzlich kann `ItemXML` mehrere Artikel enthalten (`/ITEMS/ITEM` mit den Kindelementen `ITEMNRINT`, `ITEMNRSUPPL`, `ITEMKEY`, `EAN`). Jeder Eintrag findet Artikel, deren interne Nummer, EAN, Artikelschlüssel **oder** Lieferantenartikelnummer einem der Werte entspricht. Diese Artikel werden zum Einzelartikel aus den Parametern hinzugefügt.\n\n**Ergebnismengen bei Erfolg** (in dieser Reihenfolge)\n1. Artikeldaten aus `items`, verknüpft mit den lagerspezifischen Werten aus `ItemLocationSpecific` für `LocID` (Bestand, Mindestbestand, Mindestbestellmenge), Kategoriename, MwSt-Stufe, Tags, ABC-Klasse, voraussichtliche Lieferzeit und Bildlinks.\n2. Picklistenpositionen: je Artikel und Pickliste die Anzahl nicht abgelaufener Picklistenpositionen, deren Auftragsposition nicht im Status `AUS`, `NLB`, `RET`, `STO` oder `EIN` ist. Bei gesetztem `LocID` nach dem Lager der Auftragsposition gefiltert.\n3. Kartonpositionen: je Artikel, Karton und verwendeter Picklistennummer die summierte Menge in Kartons für Auftragspositionen im Status `EIN`. Bei gesetztem `LocID` nach dem Lager der Auftragsposition gefiltert.\n4. Eine Statuszeile mit vierstelligem Code: Zugriff / Artikel gefunden / auf Pickliste / im Karton. Mögliche Werte sind `0000` (kein Parameter), `1000` (keine Artikeldaten gefunden), `1100`, `1101`, `1110` und `1111`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel. Hat Vorrang vor der Code-Suche. `0` wird als leer behandelt. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer; wird für die Suche über scanbare Codes verwendet, wenn `EANUPC` NULL ist. |\n| `EANUPC` | varchar(13) | Nein | EAN-/UPC-Code; wird als erster Wert für die Suche über scanbare Codes verwendet. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferantenartikelnummer; wird für die Code-Suche verwendet, wenn `EANUPC` und `ItemNrInt` NULL sind. |\n| `LocID` | varchar(3) | Nein | Lager-ID. Erforderlich für die Ergebnismenge mit Artikeldaten (lagerspezifische Werte); filtert bei Angabe Picklisten- und Kartondaten nach dem Lager der Auftragsposition. |\n| `ItemXML` | varchar(max) | Nein | Optionale Liste weiterer Artikel als XML (`/ITEMS/ITEM`, elementbasiert). Jeder Eintrag kann `ITEMNRINT`, `ITEMNRSUPPL`, `ITEMKEY` und `EAN` enthalten; jeder passende Wert wählt den Artikel aus. |\n\n- Die Ergebnismenge mit Artikeldaten verwendet einen INNER JOIN auf `ItemLocationSpecific` mit `LocID = @LocID`. Wird `LocID` nicht übergeben (NULL), werden **keine Artikelzeilen** geliefert und der Status lautet `1000`, obwohl die Picklisten- und Kartonergebnisse weiterhin für alle Lager gefüllt werden.\n- Die Suche verwendet `COALESCE`; ein Leerstring in `EANUPC` (statt den Parameter wegzulassen) verhindert daher die Suche über `ItemNrInt` oder `ItemNrSuppl`.\n- Der XML-Abgleich verwendet ODER-Bedingungen; ein `ITEM`-Eintrag kann mehrere verschiedene Artikel treffen.\n- Wird derselbe Artikel mehrfach angegeben (z. B. über Parameter und XML), können die Picklisten- und Kartonergebnisse doppelte Zeilen enthalten; die Artikeldaten nicht.\n- `Sum_PickListItem`, `Sum_BoxItem`, `PickListNr` und `BoxNr` sind in `ISNULL(..., '')` gekapselt; bei numerischen Spalten wird ein leerer Wert zu `0`.\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden. Die Picklisten- und Kartonaggregate werden vor der Filterung für alle Artikel berechnet, was bei großen Datenbanken langsam sein kann.\n- Ungültiges XML in `ItemXML` führt zu einem SQL-Fehler aus `sp_xml_preparedocument`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemInfoPickList"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikelstammdaten für einen oder mehrere Artikel an einem Lager sowie offene Picklistenpositionen, gepackte Kartonmengen und einen kombinierten Statuscode.\n\nSucht einen oder mehrere Artikel und liefert deren Stammdaten zusammen mit Informationen zu Picklisten und Kartons, in denen sie aktuell vorkommen.\n\n**Prüfung**\n- Sind `ItemKey`, `EANUPC`, `ItemNrSuppl`, `ItemNrInt` und `ItemXML` alle leer, liefert der Aufruf eine Zeile mit `Status` = `0` und einer Meldung, gefolgt von der abschließenden Statuszeile `0000`. `LocID` allein genügt nicht. `ItemKey` = `0` gilt ebenfalls als leer.\n\n**Artikelsuche**\n- Ein einzelner Artikel wird über `COALESCE(EANUPC, ItemNrInt, ItemNrSuppl)` in den scanbaren Artikelcodes ermittelt (`pixi.ItemCode` mit einem Codetyp, bei dem `Scannable` = 1 ist). Verwendet wird der erste Treffer. Ist `ItemKey` übergeben, hat er Vorrang vor der Code-Suche.\n- Zusätzlich kann `ItemXML` mehrere Artikel enthalten (`/ITEMS/ITEM` mit den Kindelementen `ITEMNRINT`, `ITEMNRSUPPL`, `ITEMKEY`, `EAN`). Jeder Eintrag findet Artikel, deren interne Nummer, EAN, Artikelschlüssel **oder** Lieferantenartikelnummer einem der Werte entspricht. Diese Artikel werden zum Einzelartikel aus den Parametern hinzugefügt.\n\n**Ergebnismengen bei Erfolg** (in dieser Reihenfolge)\n1. Artikeldaten aus `items`, verknüpft mit den lagerspezifischen Werten aus `ItemLocationSpecific` für `LocID` (Bestand, Mindestbestand, Mindestbestellmenge), Kategoriename, MwSt-Stufe, Tags, ABC-Klasse, voraussichtliche Lieferzeit und Bildlinks.\n2. Picklistenpositionen: je Artikel und Pickliste die Anzahl nicht abgelaufener Picklistenpositionen, deren Auftragsposition nicht im Status `AUS`, `NLB`, `RET`, `STO` oder `EIN` ist. Bei gesetztem `LocID` nach dem Lager der Auftragsposition gefiltert.\n3. Kartonpositionen: je Artikel, Karton und verwendeter Picklistennummer die summierte Menge in Kartons für Auftragspositionen im Status `EIN`. Bei gesetztem `LocID` nach dem Lager der Auftragsposition gefiltert.\n4. Eine Statuszeile mit vierstelligem Code: Zugriff / Artikel gefunden / auf Pickliste / im Karton. Mögliche Werte sind `0000` (kein Parameter), `1000` (keine Artikeldaten gefunden), `1100`, `1101`, `1110` und `1111`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel. Hat Vorrang vor der Code-Suche. `0` wird als leer behandelt. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer; wird für die Suche über scanbare Codes verwendet, wenn `EANUPC` NULL ist. |\n| `EANUPC` | varchar(13) | Nein | EAN-/UPC-Code; wird als erster Wert für die Suche über scanbare Codes verwendet. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferantenartikelnummer; wird für die Code-Suche verwendet, wenn `EANUPC` und `ItemNrInt` NULL sind. |\n| `LocID` | varchar(3) | Nein | Lager-ID. Erforderlich für die Ergebnismenge mit Artikeldaten (lagerspezifische Werte); filtert bei Angabe Picklisten- und Kartondaten nach dem Lager der Auftragsposition. |\n| `ItemXML` | varchar(max) | Nein | Optionale Liste weiterer Artikel als XML (`/ITEMS/ITEM`, elementbasiert). Jeder Eintrag kann `ITEMNRINT`, `ITEMNRSUPPL`, `ITEMKEY` und `EAN` enthalten; jeder passende Wert wählt den Artikel aus. |\n\n- Die Ergebnismenge mit Artikeldaten verwendet einen INNER JOIN auf `ItemLocationSpecific` mit `LocID = @LocID`. Wird `LocID` nicht übergeben (NULL), werden **keine Artikelzeilen** geliefert und der Status lautet `1000`, obwohl die Picklisten- und Kartonergebnisse weiterhin für alle Lager gefüllt werden.\n- Die Suche verwendet `COALESCE`; ein Leerstring in `EANUPC` (statt den Parameter wegzulassen) verhindert daher die Suche über `ItemNrInt` oder `ItemNrSuppl`.\n- Der XML-Abgleich verwendet ODER-Bedingungen; ein `ITEM`-Eintrag kann mehrere verschiedene Artikel treffen.\n- Wird derselbe Artikel mehrfach angegeben (z. B. über Parameter und XML), können die Picklisten- und Kartonergebnisse doppelte Zeilen enthalten; die Artikeldaten nicht.\n- `Sum_PickListItem`, `Sum_BoxItem`, `PickListNr` und `BoxNr` sind in `ISNULL(..., '')` gekapselt; bei numerischen Spalten wird ein leerer Wert zu `0`.\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden. Die Picklisten- und Kartonaggregate werden vor der Filterung für alle Artikel berechnet, was bei großen Datenbanken langsam sein kann.\n- Ungültiges XML in `ItemXML` führt zu einem SQL-Fehler aus `sp_xml_preparedocument`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemInfoPickList"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1234\n 4.5000\n USB-Kabel 2m\n 10\n 20\n 50\n L100\n Zubehör\n 4711\n SUP-4711\n 135\n 9.9900\n MwSt_High\n 1\n A|Kabel\n 4006381333931\n SUP-4711\n A\n 2\n https://shop.example.com/img/4711_l.jpg\n https://shop.example.com/img/4711_s.jpg\n \n"
}
]
},
{
"name": "pixiGetItemLogistics",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert aktive Artikel ohne Stücklisten mit Verpackungseinheit (VPE) und Tags für einen Fulfillment-Dienstleister, seitenweise nach Artikelschlüssel.\n\nLiefert Stammdaten von Artikeln für einen externen Fulfillment-Dienstleister.\n\n**Filter**\n- Nur Artikel mit `Enabled = 1` (aktive Artikel).\n- Nur Artikel mit `IsBundle = 0`. Stücklistenartikel selbst werden nicht geliefert.\n- Nur Artikel mit `ItemKey` größer als `StartKey`.\n\n**Paging**\n- Das Ergebnis ist aufsteigend nach `ItemKey` sortiert und auf `RowCount` Zeilen begrenzt.\n- Für die nächste Seite wird der höchste `ItemKey` der vorherigen Seite als `StartKey` übergeben. Werden weniger als `RowCount` Zeilen geliefert, sind alle Daten gelesen.\n\n**VPE (Verpackungseinheit)**\n- Ein Artikel erhält seine `OrderUnit` (bzw. 1, wenn `OrderUnit` NULL ist) als `VPE`, wenn er in mindestens einer Stückliste die einzige Komponente ist und die Menge dieser Komponente der `OrderUnit` des Artikels (als Ganzzahl) entspricht. Solche Stücklisten bilden eine Verpackungseinheit des Artikels ab.\n- Alle anderen Artikel erhalten `VPE = 1`.\n\n**Tags**\n- `Tags` enthält die Namen aller dem Artikel zugeordneten Tags, alphabetisch sortiert und durch `|` getrennt. Leerer String, wenn der Artikel keine Tags hat.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartKey` | int | Nein | Es werden nur Artikel mit einem `ItemKey` größer als dieser Wert geliefert. 0 für die erste Seite, danach der letzte `ItemKey` der vorherigen Seite. |\n| `RowCount` | int | Nein | Maximale Anzahl der Zeilen pro Aufruf. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- `OrderUnit` wird für den Vergleich mit der Stücklistenmenge nach `INT` konvertiert; Nachkommastellen werden bei dieser Prüfung abgeschnitten.\n- Der Tag-String wird je Zeile über die Skalarfunktion `fpixi_GetItemTAGsAsString` gebildet und ist auf 8000 Zeichen begrenzt; große `RowCount`-Werte können langsam sein.\n- Die genauen Datentypen von `ItemName` und `OrderUnit` sind in der Tabelle `items` definiert und im Code nicht sichtbar.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemLogistics"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert aktive Artikel ohne Stücklisten mit Verpackungseinheit (VPE) und Tags für einen Fulfillment-Dienstleister, seitenweise nach Artikelschlüssel.\n\nLiefert Stammdaten von Artikeln für einen externen Fulfillment-Dienstleister.\n\n**Filter**\n- Nur Artikel mit `Enabled = 1` (aktive Artikel).\n- Nur Artikel mit `IsBundle = 0`. Stücklistenartikel selbst werden nicht geliefert.\n- Nur Artikel mit `ItemKey` größer als `StartKey`.\n\n**Paging**\n- Das Ergebnis ist aufsteigend nach `ItemKey` sortiert und auf `RowCount` Zeilen begrenzt.\n- Für die nächste Seite wird der höchste `ItemKey` der vorherigen Seite als `StartKey` übergeben. Werden weniger als `RowCount` Zeilen geliefert, sind alle Daten gelesen.\n\n**VPE (Verpackungseinheit)**\n- Ein Artikel erhält seine `OrderUnit` (bzw. 1, wenn `OrderUnit` NULL ist) als `VPE`, wenn er in mindestens einer Stückliste die einzige Komponente ist und die Menge dieser Komponente der `OrderUnit` des Artikels (als Ganzzahl) entspricht. Solche Stücklisten bilden eine Verpackungseinheit des Artikels ab.\n- Alle anderen Artikel erhalten `VPE = 1`.\n\n**Tags**\n- `Tags` enthält die Namen aller dem Artikel zugeordneten Tags, alphabetisch sortiert und durch `|` getrennt. Leerer String, wenn der Artikel keine Tags hat.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartKey` | int | Nein | Es werden nur Artikel mit einem `ItemKey` größer als dieser Wert geliefert. 0 für die erste Seite, danach der letzte `ItemKey` der vorherigen Seite. |\n| `RowCount` | int | Nein | Maximale Anzahl der Zeilen pro Aufruf. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- `OrderUnit` wird für den Vergleich mit der Stücklistenmenge nach `INT` konvertiert; Nachkommastellen werden bei dieser Prüfung abgeschnitten.\n- Der Tag-String wird je Zeile über die Skalarfunktion `fpixi_GetItemTAGsAsString` gebildet und ist auf 8000 Zeichen begrenzt; große `RowCount`-Werte können langsam sein.\n- Die genauen Datentypen von `ItemName` und `OrderUnit` sind in der Tabelle `items` definiert und im Code nicht sichtbar.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemLogistics"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1012\n Kaffeebecher Keramik 300 ml\n 6\n Fragile|Kitchen\n \n \n 1015\n Teelöffel Edelstahl\n 1\n \n \n"
}
]
},
{
"name": "pixiGetItemLogisticsEAN",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert seitenweise die EANs aktiver Nicht-Bundle-Artikel sowie die EANs von Einzelartikel-Bundles, die als Verpackungseinheit (VPE) dienen.\n\nStellt EAN-Daten von Artikeln für einen Fulfillment-Dienstleister bereit, einschließlich der EANs von Verpackungseinheiten, die als Bundles abgebildet sind.\n\n**Paging**\n\n1. Es werden die ersten `@RowCount` Artikel mit `ItemKey` größer als `@StartKey` ausgewählt, aufsteigend sortiert nach `ItemKey`.\n2. Nur Artikel mit `Enabled = 1` und `IsBundle = 0` gelangen in die Seite.\n\n**Ergebniszeilen**\n\n- Für jeden Artikel der Seite gibt es eine Zeile mit der eigenen `EANUPC` des Artikels und `VPE = 1`.\n- Zusätzlich werden *VPE-Bundles* gesucht: Bundles mit genau einer Bundle-Position, deren Menge der `OrderUnit` des enthaltenen Artikels (als `int`) entspricht. Für jedes solche Bundle, dessen enthaltener Artikel in der aktuellen Seite liegt, wird eine Zeile geliefert mit:\n - `ItemKey` = der **enthaltene** Artikel,\n - `EANUPC` = die EAN des **Bundles**,\n - `VPE` = die `OrderUnit` des enthaltenen Artikels.\n\nBeide Teile werden per `UNION` zusammengeführt (exakte Duplikate entfallen) und nach `ItemKey` sortiert.\n\n**Alle Artikel durchlaufen**\n\nMit `StartKey = 0` beginnen und den höchsten `ItemKey` der letzten Antwort als nächsten `StartKey` übergeben. Abbrechen, wenn ein Aufruf keine Zeilen mehr liefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartKey` | int | Nein | Es werden nur Artikel mit einem `ItemKey` größer als dieser Wert geliefert. `0` für die erste Seite, danach der höchste `ItemKey` der vorherigen Antwort. |\n| `RowCount` | int | Nein | Maximale Anzahl Artikel (aktiv, kein Bundle) pro Seite. Die Anzahl der gelieferten Zeilen kann durch zusätzliche VPE-Zeilen höher sein. |\n\n- Derselbe `ItemKey` kann in mehreren Zeilen vorkommen (eigene EAN plus je eine Zeile pro VPE-Bundle). Die Zeilenanzahl kann daher `@RowCount` übersteigen; `@RowCount` begrenzt die Anzahl unterschiedlicher Artikel, nicht der Zeilen.\n- Das Bundle selbst wird nicht nach `Enabled` gefiltert; auch deaktivierte Bundles, die die VPE-Kriterien erfüllen, werden geliefert.\n- Bundles mit mehr als einer Bundle-Position oder mit einer Menge ungleich der `OrderUnit` des enthaltenen Artikels werden ignoriert.\n- Die meisten Joins lesen mit `NOLOCK` (Dirty Reads möglich); der Join für die eigene EAN des Artikels verwendet keinen Locking-Hint.\n- `EANUPC` kann leer oder `NULL` sein, wenn keine EAN gepflegt ist.\n- Der genaue Datentyp von `VPE` hängt vom Spaltentyp von `Items.OrderUnit` ab, der im Code nicht ersichtlich ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemLogisticsEAN"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert seitenweise die EANs aktiver Nicht-Bundle-Artikel sowie die EANs von Einzelartikel-Bundles, die als Verpackungseinheit (VPE) dienen.\n\nStellt EAN-Daten von Artikeln für einen Fulfillment-Dienstleister bereit, einschließlich der EANs von Verpackungseinheiten, die als Bundles abgebildet sind.\n\n**Paging**\n\n1. Es werden die ersten `@RowCount` Artikel mit `ItemKey` größer als `@StartKey` ausgewählt, aufsteigend sortiert nach `ItemKey`.\n2. Nur Artikel mit `Enabled = 1` und `IsBundle = 0` gelangen in die Seite.\n\n**Ergebniszeilen**\n\n- Für jeden Artikel der Seite gibt es eine Zeile mit der eigenen `EANUPC` des Artikels und `VPE = 1`.\n- Zusätzlich werden *VPE-Bundles* gesucht: Bundles mit genau einer Bundle-Position, deren Menge der `OrderUnit` des enthaltenen Artikels (als `int`) entspricht. Für jedes solche Bundle, dessen enthaltener Artikel in der aktuellen Seite liegt, wird eine Zeile geliefert mit:\n - `ItemKey` = der **enthaltene** Artikel,\n - `EANUPC` = die EAN des **Bundles**,\n - `VPE` = die `OrderUnit` des enthaltenen Artikels.\n\nBeide Teile werden per `UNION` zusammengeführt (exakte Duplikate entfallen) und nach `ItemKey` sortiert.\n\n**Alle Artikel durchlaufen**\n\nMit `StartKey = 0` beginnen und den höchsten `ItemKey` der letzten Antwort als nächsten `StartKey` übergeben. Abbrechen, wenn ein Aufruf keine Zeilen mehr liefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartKey` | int | Nein | Es werden nur Artikel mit einem `ItemKey` größer als dieser Wert geliefert. `0` für die erste Seite, danach der höchste `ItemKey` der vorherigen Antwort. |\n| `RowCount` | int | Nein | Maximale Anzahl Artikel (aktiv, kein Bundle) pro Seite. Die Anzahl der gelieferten Zeilen kann durch zusätzliche VPE-Zeilen höher sein. |\n\n- Derselbe `ItemKey` kann in mehreren Zeilen vorkommen (eigene EAN plus je eine Zeile pro VPE-Bundle). Die Zeilenanzahl kann daher `@RowCount` übersteigen; `@RowCount` begrenzt die Anzahl unterschiedlicher Artikel, nicht der Zeilen.\n- Das Bundle selbst wird nicht nach `Enabled` gefiltert; auch deaktivierte Bundles, die die VPE-Kriterien erfüllen, werden geliefert.\n- Bundles mit mehr als einer Bundle-Position oder mit einer Menge ungleich der `OrderUnit` des enthaltenen Artikels werden ignoriert.\n- Die meisten Joins lesen mit `NOLOCK` (Dirty Reads möglich); der Join für die eigene EAN des Artikels verwendet keinen Locking-Hint.\n- `EANUPC` kann leer oder `NULL` sein, wenn keine EAN gepflegt ist.\n- Der genaue Datentyp von `VPE` hängt vom Spaltentyp von `Items.OrderUnit` ab, der im Code nicht ersichtlich ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemLogisticsEAN"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1001\n 4006381333931\n 1\n \n \n 1001\n 4006381333948\n 12\n \n"
}
]
},
{
"name": "pixiGetItemStatus",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Aktiv-/Inaktiv-Status (`Enabled`) eines Artikels, ermittelt über ItemKey oder interne Artikelnummer.\n\nErmittelt einen einzelnen Artikel und liefert dessen Aktiv-Status.\n\n1. Der Artikel wird in der Tabelle `Items` gesucht. Eine Zeile passt, wenn ihr `ItemKey` gleich `ItemKey` ist (nur wenn `ItemKey` übergeben wurde) **oder** ihr `ItemNrInt` gleich `ItemNrInt` ist. Die erste passende Zeile (`TOP 1`, ohne Sortierung) liefert den ItemKey.\n2. Anschließend werden `ItemKey`, `ItemNrInt` und `Enabled` dieses Artikels zurückgegeben.\n\nPasst keiner der Parameter zu einem Artikel oder werden beide weggelassen, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer des Artikels. Wird verwendet, wenn `ItemKey` nicht übergeben wird oder nicht passt. |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels in der Tabelle `Items`. |\n\n- Beide Parameter werden mit **ODER** verknüpft. Werden beide übergeben und verweisen auf unterschiedliche Artikel, ist nicht festgelegt, welcher Artikel geliefert wird (`TOP 1` ohne `ORDER BY`). Daher nur einen der beiden Parameter übergeben.\n- Existiert ein übergebener `ItemKey` nicht und passt auch `ItemNrInt` nicht, ist die Ergebnismenge leer; es wird kein Fehler gemeldet.\n- Existiert `ItemKey` nicht, passt aber `ItemNrInt`, wird der über `ItemNrInt` gefundene Artikel geliefert.\n- Gelesen wird mit `NOLOCK`, nicht festgeschriebene Änderungen können daher sichtbar sein.\n- Datentyp und Bedeutung der Werte von `Enabled` sind aus dem Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemStatus"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Aktiv-/Inaktiv-Status (`Enabled`) eines Artikels, ermittelt über ItemKey oder interne Artikelnummer.\n\nErmittelt einen einzelnen Artikel und liefert dessen Aktiv-Status.\n\n1. Der Artikel wird in der Tabelle `Items` gesucht. Eine Zeile passt, wenn ihr `ItemKey` gleich `ItemKey` ist (nur wenn `ItemKey` übergeben wurde) **oder** ihr `ItemNrInt` gleich `ItemNrInt` ist. Die erste passende Zeile (`TOP 1`, ohne Sortierung) liefert den ItemKey.\n2. Anschließend werden `ItemKey`, `ItemNrInt` und `Enabled` dieses Artikels zurückgegeben.\n\nPasst keiner der Parameter zu einem Artikel oder werden beide weggelassen, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer des Artikels. Wird verwendet, wenn `ItemKey` nicht übergeben wird oder nicht passt. |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels in der Tabelle `Items`. |\n\n- Beide Parameter werden mit **ODER** verknüpft. Werden beide übergeben und verweisen auf unterschiedliche Artikel, ist nicht festgelegt, welcher Artikel geliefert wird (`TOP 1` ohne `ORDER BY`). Daher nur einen der beiden Parameter übergeben.\n- Existiert ein übergebener `ItemKey` nicht und passt auch `ItemNrInt` nicht, ist die Ergebnismenge leer; es wird kein Fehler gemeldet.\n- Existiert `ItemKey` nicht, passt aber `ItemNrInt`, wird der über `ItemNrInt` gefundene Artikel geliefert.\n- Gelesen wird mit `NOLOCK`, nicht festgeschriebene Änderungen können daher sichtbar sein.\n- Datentyp und Bedeutung der Werte von `Enabled` sind aus dem Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemStatus"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4711\n ART-100234\n 1\n \n"
}
]
},
{
"name": "pixiGetItemTags",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Liste der Artikel-Tags (Tag-Typ 1), optional einschließlich System-Tags, sortiert nach Name.\n\nLiest alle Tags vom Typ `TypeId = 1` (Artikel-Tags) aus der Tabelle `Tag`.\n\n- Mit `SystemTags = 0` (Standard) werden nur benutzerdefinierte Tags geliefert (`IsSystemTag = 0`).\n- Mit `SystemTags = 1` werden zusätzlich die System-Tags geliefert.\n\nDas Ergebnis ist aufsteigend nach Tag-Name sortiert. Jede Zeile enthält Schlüssel, Name und Beschreibung des Tags.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SystemTags` | bit | Nein | Steuert, ob System-Tags im Ergebnis enthalten sind. |\n\nDie Tabelle wird mit `NOLOCK` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein. Der Kopfkommentar der Prozedur (\"Template for getting items…\") stammt aus einer Vorlage und beschreibt nicht das tatsächliche Verhalten. Jeder Wert von `SystemTags` außer `1` wirkt wie `0`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemTags"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Liste der Artikel-Tags (Tag-Typ 1), optional einschließlich System-Tags, sortiert nach Name.\n\nLiest alle Tags vom Typ `TypeId = 1` (Artikel-Tags) aus der Tabelle `Tag`.\n\n- Mit `SystemTags = 0` (Standard) werden nur benutzerdefinierte Tags geliefert (`IsSystemTag = 0`).\n- Mit `SystemTags = 1` werden zusätzlich die System-Tags geliefert.\n\nDas Ergebnis ist aufsteigend nach Tag-Name sortiert. Jede Zeile enthält Schlüssel, Name und Beschreibung des Tags.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SystemTags` | bit | Nein | Steuert, ob System-Tags im Ergebnis enthalten sind. |\n\nDie Tabelle wird mit `NOLOCK` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein. Der Kopfkommentar der Prozedur (\"Template for getting items…\") stammt aus einer Vorlage und beschreibt nicht das tatsächliche Verhalten. Jeder Wert von `SystemTags` außer `1` wirkt wie `0`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemTags"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 12\n Bestseller\n Top-selling items\n \n \n 15\n Sale\n Items on sale\n \n"
}
]
},
{
"name": "pixiGetResolvedItemDependencies",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löst eine Liste von Artikeln in die tatsächlichen Lagerartikel auf: Nicht-Bundle-Artikel bleiben erhalten, Bundles werden durch ihre Bestandteile mit multiplizierten Mengen ersetzt.\n\nNimmt eine Liste von Artikeln mit Mengen als XML entgegen und liefert die Artikel, von denen die Anfrage tatsächlich abhängt, z. B. um Bestand für einen Auftrag zu prüfen oder zu reservieren.\n\nAblauf:\n\n1. Das XML in `ItemXML` wird ab `/Items/Item` gelesen. Jedes `Item` kann den Artikel über `ItemKey`, über `ItemNrInt` oder über beide identifizieren und enthält eine Menge `Qty`.\n2. Fehlende Kennungen werden aus der Tabelle `Items` ergänzt: fehlt `ItemKey`, wird er über `ItemNrInt` ermittelt; fehlt `ItemNrInt`, wird sie über `ItemKey` ermittelt.\n3. Einträge, deren `ItemKey` nicht ermittelt werden kann (unbekannte Artikelnummer), werden ohne Meldung verworfen.\n4. Auflösung:\n - Artikel mit `IsBundle = 0` werden mit der angefragten Menge `Qty` geliefert.\n - Artikel mit `IsBundle = 1` werden selbst nicht geliefert. Stattdessen wird jeder Bestandteil aus `BundleItems` mit der Menge `Qty` × Bestandteilmenge geliefert.\n5. Das Ergebnis wird nach `ItemKey` gruppiert: Mengen desselben Artikels (mehrfach angegeben oder in mehreren Bundles enthalten) werden summiert.\n\nWird `ItemXML` nicht übergeben, wird eine leere Ergebnismenge geliefert. Eine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemXML` | varchar(max) | Nein | XML-Liste der angefragten Artikel. Wurzel `Items`, je Eintrag ein Element `Item` mit den Kindelementen `ItemKey` und/oder `ItemNrInt` sowie `Qty`. Bei NULL ist das Ergebnis leer. |\n\n- Nur lesend; alle Zugriffe auf `Items` und `BundleItems` erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Bundles werden nur eine Ebene tief aufgelöst. Ein Bestandteil, der selbst ein Bundle ist, wird unverändert geliefert und nicht weiter aufgelöst.\n- Sind `ItemKey` und `ItemNrInt` beide angegeben, wird `ItemKey` verwendet; `ItemNrInt` wird nicht dagegen geprüft.\n- Unbekannte Artikel werden ohne Fehlermeldung verworfen; bei Bedarf das Ergebnis mit der Anfrage abgleichen.\n- Fehlt `Qty` bei einem Eintrag, ist dessen Menge `NULL` und trägt nicht zur summierten `Qty` bei (die Summe ist `NULL`, wenn alle Beiträge `NULL` sind).\n- Ungültiges XML führt zu einem SQL-Fehler aus `sp_xml_preparedocument`, der als `SqlMessage` zurückkommt.\n- Der Datentyp der gelieferten `Qty` hängt vom Typ von `BundleItems.Qty` ab, der im Code nicht sichtbar ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetResolvedItemDependencies"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löst eine Liste von Artikeln in die tatsächlichen Lagerartikel auf: Nicht-Bundle-Artikel bleiben erhalten, Bundles werden durch ihre Bestandteile mit multiplizierten Mengen ersetzt.\n\nNimmt eine Liste von Artikeln mit Mengen als XML entgegen und liefert die Artikel, von denen die Anfrage tatsächlich abhängt, z. B. um Bestand für einen Auftrag zu prüfen oder zu reservieren.\n\nAblauf:\n\n1. Das XML in `ItemXML` wird ab `/Items/Item` gelesen. Jedes `Item` kann den Artikel über `ItemKey`, über `ItemNrInt` oder über beide identifizieren und enthält eine Menge `Qty`.\n2. Fehlende Kennungen werden aus der Tabelle `Items` ergänzt: fehlt `ItemKey`, wird er über `ItemNrInt` ermittelt; fehlt `ItemNrInt`, wird sie über `ItemKey` ermittelt.\n3. Einträge, deren `ItemKey` nicht ermittelt werden kann (unbekannte Artikelnummer), werden ohne Meldung verworfen.\n4. Auflösung:\n - Artikel mit `IsBundle = 0` werden mit der angefragten Menge `Qty` geliefert.\n - Artikel mit `IsBundle = 1` werden selbst nicht geliefert. Stattdessen wird jeder Bestandteil aus `BundleItems` mit der Menge `Qty` × Bestandteilmenge geliefert.\n5. Das Ergebnis wird nach `ItemKey` gruppiert: Mengen desselben Artikels (mehrfach angegeben oder in mehreren Bundles enthalten) werden summiert.\n\nWird `ItemXML` nicht übergeben, wird eine leere Ergebnismenge geliefert. Eine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemXML` | varchar(max) | Nein | XML-Liste der angefragten Artikel. Wurzel `Items`, je Eintrag ein Element `Item` mit den Kindelementen `ItemKey` und/oder `ItemNrInt` sowie `Qty`. Bei NULL ist das Ergebnis leer. |\n\n- Nur lesend; alle Zugriffe auf `Items` und `BundleItems` erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Bundles werden nur eine Ebene tief aufgelöst. Ein Bestandteil, der selbst ein Bundle ist, wird unverändert geliefert und nicht weiter aufgelöst.\n- Sind `ItemKey` und `ItemNrInt` beide angegeben, wird `ItemKey` verwendet; `ItemNrInt` wird nicht dagegen geprüft.\n- Unbekannte Artikel werden ohne Fehlermeldung verworfen; bei Bedarf das Ergebnis mit der Anfrage abgleichen.\n- Fehlt `Qty` bei einem Eintrag, ist dessen Menge `NULL` und trägt nicht zur summierten `Qty` bei (die Summe ist `NULL`, wenn alle Beiträge `NULL` sind).\n- Ungültiges XML führt zu einem SQL-Fehler aus `sp_xml_preparedocument`, der als `SqlMessage` zurückkommt.\n- Der Datentyp der gelieferten `Qty` hängt vom Typ von `BundleItems.Qty` ab, der im Code nicht sichtbar ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetResolvedItemDependencies"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1052\n ART-10052\n 3\n \n \n 1077\n ART-10077\n 2\n \n"
}
]
},
{
"name": "pixiItemGetByTags",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 12Summer15New20Discontinued]]>\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, deren zugeordnete Tags einem XML-Tagfilter mit AND-, OR- und NOT-Gruppen entsprechen; Tags werden per ID oder (Teil-)Name bestimmt.\n\nSucht Artikel anhand der ihnen zugeordneten Tags (Tabelle `TagMatch`).\n\n**1. Filter einlesen**\n\n`TagFilter` ist ein XML-Dokument mit dem Wurzelelement `TagFilter` und den Gruppen `AND`, `OR` und `NOT`. Jede Gruppe kann beliebig viele `TagId`- und `TagName`-Elemente enthalten. Namen werden getrimmt; leere Namen gelten als fehlend.\n\n**2. Tags auflösen**\n\nJeder Eintrag wird gegen Tags mit `TypeId = 1` aufgelöst:\n- `TagId` wird mit der Tag-ID verglichen.\n- `TagName` wird bei `PartialTagNameMatch = 0` exakt verglichen, bei `PartialTagNameMatch = 1` per `LIKE '%name%'`. Ein Teilname kann mehrere Tags treffen.\n\n**3. Prüfung**\n\nDer Aufruf bricht mit einer Status-Ergebnismenge ab und liefert keine Artikel, wenn:\n- ein Eintrag keinem Tag zugeordnet werden kann oder\n- dasselbe Tag mehrfach aufgelöst wird. Das gilt gruppenübergreifend, innerhalb einer Gruppe und wenn ein Tag sowohl per ID als auch per Name angegeben ist.\n\nDann wird je Filtereintrag eine Zeile geliefert:\n- Fehlerhafte Einträge erhalten `Status = ERROR`.\n- Gültige Einträge erhalten `OK` mit `Complete match on TagName`, `Partial match on TagName` oder `Complete match on TagId`.\n\n**4. Artikelauswahl**\n\nBerücksichtigt werden nur Artikel, denen in `TagMatch` mindestens ein Tag zugeordnet ist. Ein Artikel wird geliefert, wenn er **keines** der NOT-Tags hat und mindestens eine der folgenden Bedingungen gilt:\n- es wurden weder AND- noch OR-Tags angegeben (nur NOT oder leerer Filter);\n- er hat **alle** AND-Tags. Bei `StrictANDCondition = 1` darf er zusätzlich keine weiteren Tags haben; seine Tag-Menge muss also genau der AND-Menge entsprechen;\n- er hat **mindestens ein** OR-Tag.\n\nAND und OR werden mit ODER verknüpft. OR-Tags erweitern das Ergebnis also, statt es einzuschränken.\n\nDas Ergebnis enthält `ItemId`, `ItemNrInt` und `ItemName`. Die Zeilen sind eindeutig und nicht sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagFilter` | varchar(max) | Ja | XML-Filter mit Wurzel `TagFilter` und optionalen Gruppen `AND`, `OR` und `NOT`, die jeweils `TagId`- und/oder `TagName`-Elemente enthalten. |\n| `PartialTagNameMatch` | bit | Nein | Steuert, wie `TagName`-Einträge mit Tag-Namen verglichen werden. |\n| `StrictANDCondition` | bit | Nein | Steuert, wie streng die AND-Gruppe auf die Tags eines Artikels angewendet wird. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten sind möglich.\n- Die Umwandlung von `TagFilter` in XML erfolgt **vor** der Fehlerbehandlung. Ungültiges XML führt daher zu einem SQL-Fehler (`SqlMessage`) statt zu einer Statuszeile.\n- Ein nicht numerischer `TagId`-Wert verursacht einen Konvertierungsfehler innerhalb der Fehlerbehandlung. Ergebnis ist die einzelne Statuszeile `Unexpected error occured while parsing the @TagFilter parameter`.\n- Das Verhalten bei `TagFilter = NULL` ist im Code nicht explizit behandelt.\n- Im Filter sind nur Tags mit `TypeId = 1` verwendbar.\n- Die strikte AND-Prüfung berücksichtigt alle dem Artikel in `TagMatch` zugeordneten Tags, unabhängig vom Typ.\n- Nach einer Status-Ergebnismenge liefert die Prozedur den Rückgabewert 1. Statuszeilen und Artikelzeilen kommen nie im selben Aufruf vor; beide erscheinen als `SqlRowSet1`. Zur Unterscheidung auf eine Spalte `Status` prüfen.\n- Bei `PartialTagNameMatch = 1` kann ein kurzer Name mehrere Tags treffen. Er überschneidet sich dann leicht mit anderen Einträgen und löst `Tag used in another operation` aus.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiItemGetByTags"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 12Summer15New20Discontinued]]>\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, deren zugeordnete Tags einem XML-Tagfilter mit AND-, OR- und NOT-Gruppen entsprechen; Tags werden per ID oder (Teil-)Name bestimmt.\n\nSucht Artikel anhand der ihnen zugeordneten Tags (Tabelle `TagMatch`).\n\n**1. Filter einlesen**\n\n`TagFilter` ist ein XML-Dokument mit dem Wurzelelement `TagFilter` und den Gruppen `AND`, `OR` und `NOT`. Jede Gruppe kann beliebig viele `TagId`- und `TagName`-Elemente enthalten. Namen werden getrimmt; leere Namen gelten als fehlend.\n\n**2. Tags auflösen**\n\nJeder Eintrag wird gegen Tags mit `TypeId = 1` aufgelöst:\n- `TagId` wird mit der Tag-ID verglichen.\n- `TagName` wird bei `PartialTagNameMatch = 0` exakt verglichen, bei `PartialTagNameMatch = 1` per `LIKE '%name%'`. Ein Teilname kann mehrere Tags treffen.\n\n**3. Prüfung**\n\nDer Aufruf bricht mit einer Status-Ergebnismenge ab und liefert keine Artikel, wenn:\n- ein Eintrag keinem Tag zugeordnet werden kann oder\n- dasselbe Tag mehrfach aufgelöst wird. Das gilt gruppenübergreifend, innerhalb einer Gruppe und wenn ein Tag sowohl per ID als auch per Name angegeben ist.\n\nDann wird je Filtereintrag eine Zeile geliefert:\n- Fehlerhafte Einträge erhalten `Status = ERROR`.\n- Gültige Einträge erhalten `OK` mit `Complete match on TagName`, `Partial match on TagName` oder `Complete match on TagId`.\n\n**4. Artikelauswahl**\n\nBerücksichtigt werden nur Artikel, denen in `TagMatch` mindestens ein Tag zugeordnet ist. Ein Artikel wird geliefert, wenn er **keines** der NOT-Tags hat und mindestens eine der folgenden Bedingungen gilt:\n- es wurden weder AND- noch OR-Tags angegeben (nur NOT oder leerer Filter);\n- er hat **alle** AND-Tags. Bei `StrictANDCondition = 1` darf er zusätzlich keine weiteren Tags haben; seine Tag-Menge muss also genau der AND-Menge entsprechen;\n- er hat **mindestens ein** OR-Tag.\n\nAND und OR werden mit ODER verknüpft. OR-Tags erweitern das Ergebnis also, statt es einzuschränken.\n\nDas Ergebnis enthält `ItemId`, `ItemNrInt` und `ItemName`. Die Zeilen sind eindeutig und nicht sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagFilter` | varchar(max) | Ja | XML-Filter mit Wurzel `TagFilter` und optionalen Gruppen `AND`, `OR` und `NOT`, die jeweils `TagId`- und/oder `TagName`-Elemente enthalten. |\n| `PartialTagNameMatch` | bit | Nein | Steuert, wie `TagName`-Einträge mit Tag-Namen verglichen werden. |\n| `StrictANDCondition` | bit | Nein | Steuert, wie streng die AND-Gruppe auf die Tags eines Artikels angewendet wird. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten sind möglich.\n- Die Umwandlung von `TagFilter` in XML erfolgt **vor** der Fehlerbehandlung. Ungültiges XML führt daher zu einem SQL-Fehler (`SqlMessage`) statt zu einer Statuszeile.\n- Ein nicht numerischer `TagId`-Wert verursacht einen Konvertierungsfehler innerhalb der Fehlerbehandlung. Ergebnis ist die einzelne Statuszeile `Unexpected error occured while parsing the @TagFilter parameter`.\n- Das Verhalten bei `TagFilter = NULL` ist im Code nicht explizit behandelt.\n- Im Filter sind nur Tags mit `TypeId = 1` verwendbar.\n- Die strikte AND-Prüfung berücksichtigt alle dem Artikel in `TagMatch` zugeordneten Tags, unabhängig vom Typ.\n- Nach einer Status-Ergebnismenge liefert die Prozedur den Rückgabewert 1. Statuszeilen und Artikelzeilen kommen nie im selben Aufruf vor; beide erscheinen als `SqlRowSet1`. Zur Unterscheidung auf eine Spalte `Status` prüfen.\n- Bei `PartialTagNameMatch = 1` kann ein kurzer Name mehrere Tags treffen. Er überschneidet sich dann leicht mit anderen Einträgen und löst `Tag used in another operation` aus.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiItemGetByTags"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4711\n ART-10023\n Garden chair teak\n \n \n 4712\n ART-10024\n Garden table teak\n \n"
}
]
},
{
"name": "pixiItemsBySupplier",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n L001\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine seitenweise Liste der Artikel eines Lieferanten mit EAN, Artikelname und Gesamtbestand über alle Lagerplätze.\n\nLiefert alle Artikel, die mit dem Lieferanten `SupplNr` verknüpft sind.\n\n1. Die Prozedur ermittelt alle `IntLinkNr1`-Werte aus `AddItems` mit der angegebenen `SupplNr`. Anschließend werden alle Datensätze aus `Items` mit einem dieser `IntLinkNr1`-Werte gewählt.\n2. Für jeden Artikel wird `StockQty` als Summe von `BinItemQTY` aus `InvBinItem` berechnet (`BinItemRef` = `ItemKey`). Die Summe umfasst alle Lagerplätze und ist `0`, wenn für den Artikel keine Bestandsdatensätze vorhanden sind.\n3. Die Zeilen werden in einer temporären Tabelle fortlaufend nummeriert (`RowNr`, beginnend bei 1).\n4. Zurückgegeben werden nur die Zeilen mit `RowNr` zwischen `FromRow` und `FromRow + Rows - 1`.\n\nJede Zeile enthält zusätzlich Paging-Informationen:\n- `RecordsTotal`: Anzahl aller passenden Artikel.\n- `RecordsFrom`: der übergebene Wert von `FromRow`.\n- `RecordsRequested`: der übergebene Wert von `Rows`.\n\nZum seitenweisen Abruf wird `FromRow` jeweils um `Rows` erhöht, bis `FromRow` größer als `RecordsTotal` ist.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | char(4) | Ja | Lieferantennummer. Wird mit `AddItems.SupplNr` verglichen. |\n| `FromRow` | int | Nein | Nummer der ersten zurückzugebenden Zeile (beginnend bei 1). Bei `NULL` werden alle Zeilen geliefert. |\n| `Rows` | int | Nein | Maximale Anzahl zurückzugebender Zeilen. Bei `NULL` werden alle Zeilen ab `FromRow` geliefert. |\n\n- Die Nummerierung der Zeilen erfolgt ohne `ORDER BY`. Die Reihenfolge der Artikel und damit der Inhalt der einzelnen Seiten ist nicht garantiert. Sie kann sich zwischen Aufrufen unterscheiden, sodass beim Paging Artikel doppelt erscheinen oder fehlen können.\n- Ist `Rows` `NULL`, werden alle Zeilen ab `FromRow` geliefert. Ist `FromRow` `NULL`, wird unabhängig von `Rows` die vollständige Liste geliefert.\n- `RecordsFrom` und `RecordsRequested` geben die Parameterwerte unverändert zurück, auch `NULL`.\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen. Die Ergebnisse können nicht festgeschriebene Daten enthalten.\n- `StockQty` ist die Summe über alle Lagerplätze und Lager. Reservierungen und Sperrbestände werden nicht berücksichtigt.\n- Passt kein Artikel zum Lieferanten, wird eine leere Ergebnismenge geliefert. Eine Fehlerzeile gibt es nicht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiItemsBySupplier"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n L001\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine seitenweise Liste der Artikel eines Lieferanten mit EAN, Artikelname und Gesamtbestand über alle Lagerplätze.\n\nLiefert alle Artikel, die mit dem Lieferanten `SupplNr` verknüpft sind.\n\n1. Die Prozedur ermittelt alle `IntLinkNr1`-Werte aus `AddItems` mit der angegebenen `SupplNr`. Anschließend werden alle Datensätze aus `Items` mit einem dieser `IntLinkNr1`-Werte gewählt.\n2. Für jeden Artikel wird `StockQty` als Summe von `BinItemQTY` aus `InvBinItem` berechnet (`BinItemRef` = `ItemKey`). Die Summe umfasst alle Lagerplätze und ist `0`, wenn für den Artikel keine Bestandsdatensätze vorhanden sind.\n3. Die Zeilen werden in einer temporären Tabelle fortlaufend nummeriert (`RowNr`, beginnend bei 1).\n4. Zurückgegeben werden nur die Zeilen mit `RowNr` zwischen `FromRow` und `FromRow + Rows - 1`.\n\nJede Zeile enthält zusätzlich Paging-Informationen:\n- `RecordsTotal`: Anzahl aller passenden Artikel.\n- `RecordsFrom`: der übergebene Wert von `FromRow`.\n- `RecordsRequested`: der übergebene Wert von `Rows`.\n\nZum seitenweisen Abruf wird `FromRow` jeweils um `Rows` erhöht, bis `FromRow` größer als `RecordsTotal` ist.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | char(4) | Ja | Lieferantennummer. Wird mit `AddItems.SupplNr` verglichen. |\n| `FromRow` | int | Nein | Nummer der ersten zurückzugebenden Zeile (beginnend bei 1). Bei `NULL` werden alle Zeilen geliefert. |\n| `Rows` | int | Nein | Maximale Anzahl zurückzugebender Zeilen. Bei `NULL` werden alle Zeilen ab `FromRow` geliefert. |\n\n- Die Nummerierung der Zeilen erfolgt ohne `ORDER BY`. Die Reihenfolge der Artikel und damit der Inhalt der einzelnen Seiten ist nicht garantiert. Sie kann sich zwischen Aufrufen unterscheiden, sodass beim Paging Artikel doppelt erscheinen oder fehlen können.\n- Ist `Rows` `NULL`, werden alle Zeilen ab `FromRow` geliefert. Ist `FromRow` `NULL`, wird unabhängig von `Rows` die vollständige Liste geliefert.\n- `RecordsFrom` und `RecordsRequested` geben die Parameterwerte unverändert zurück, auch `NULL`.\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen. Die Ergebnisse können nicht festgeschriebene Daten enthalten.\n- `StockQty` ist die Summe über alle Lagerplätze und Lager. Reservierungen und Sperrbestände werden nicht berücksichtigt.\n- Passt kein Artikel zum Lieferanten, wird eine leere Ergebnismenge geliefert. Eine Fehlerzeile gibt es nicht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiItemsBySupplier"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 1024\n 4006381333931\n Ballpoint pen blue\n 120\n 2\n 1\n 50\n \n \n 2\n 1025\n 4006381333948\n Ballpoint pen red\n 0\n 2\n 1\n 50\n \n"
}
]
},
{
"name": "pixiItemSearch",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Sucht Artikel nach Name bzw. Artikelcode, EAN/UPC, Konfigurationstyp und Lieferant und liefert Artikelzeilen inklusive Lieferantenpreisen und offenen Lieferantenbestellmengen.\n\nWrapper um die interne Prozedur `GOSItemSearch1`. Die Parameter werden weitergereicht; Lieferantenpreise und Statistiken werden immer angefordert. Da kein Benutzername übergeben wird, sind Lieferanten- (EK-)Preise immer sichtbar.\n\nAblauf:\n\n1. Ist `SupplNr` leer, wird `ShowOnlyItemsForExactSupplier` auf `0` gesetzt.\n2. `RowCount` = `0` wird durch die Einstellung `ItemSearchLimit` ersetzt. Ist auch diese `0`, gilt `300`.\n3. Ist `EANUPC` gesetzt, werden die Artikel-IDs gesammelt, deren Code in `pixi.ItemCode` exakt übereinstimmt. Dabei zählen nur Codetypen, die als scannbar markiert sind.\n4. Ist `ItemName` gesetzt und hat der EAN-Schritt nichts gefunden, wird `ItemName` mit **allen** Artikelcodes verglichen:\n - Passt genau ein Code exakt, ist dieser Artikel das Ergebnis. Die Freitextsuche wird dann deaktiviert und Codetyp `1` verwendet.\n - Andernfalls werden alle Artikel gesammelt, deren Code mit `ItemName` beginnt. `ItemName` dient dann zusätzlich als Smart-Search-Begriff.\n5. `ConfigType` wird als Filter für den Konfigurationstyp (`TonTrArt`) weitergegeben.\n6. `SupplNr` wird als Lieferantenfilter weitergegeben. `LocID` bestimmt das Lager (Standard `001`).\n7. Es wird immer die Datenbankwährung verwendet. Ein Wechselkurs wird nicht übergeben.\n8. Pro Artikel wird die offene Menge aus Lieferantenbestellungen berechnet: bestellt minus geliefert minus nicht geliefert. Gezählt werden nur Lieferantenbestellungen mit vollständig offenem Status und Mengen für das gewählte Lager. Bei angegebener `SupplNr` zählen nur Bestellungen dieses Lieferanten.\n9. Die abschließende Abfrage liefert `SELECT DISTINCT TOP (RowCount)` Zeilen. Sie wird dynamisch aufgebaut.\n\nDie Abfrage hat kein `ORDER BY`; die ORDER-BY-Klausel ist im Code auskommentiert. Die Reihenfolge der Zeilen ist daher nicht garantiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `RowCount` | int | Nein | Maximale Anzahl Zeilen. Bei `0` gilt die Einstellung `ItemSearchLimit`; ist diese ebenfalls `0`, liegt das Limit bei 300. |\n| `ItemName` | varchar(100) | Nein | Suchbegriff. Ein exakter Einzeltreffer auf einen beliebigen Artikelcode liefert diesen Artikel. Andernfalls werden Artikel gesammelt, deren Code mit dem Begriff beginnt, und der Begriff dient zusätzlich als Smart Search über die Artikeldaten. |\n| `ConfigType` | varchar(4) | Nein | Filter auf den Konfigurationstyp, wird als `TonTrArt` weitergegeben. Leer bedeutet kein Filter. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Dient als Lieferantenfilter und beschränkt die offenen Lieferantenbestellmengen auf diesen Lieferanten. |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC-Code. Wird exakt mit Artikelcodes verglichen, deren Codetyp scannbar ist. |\n| `LocID` | varchar(3) | Nein | Lager-ID für Bestandsdaten und offene Lieferantenbestellmengen. |\n| `ShowOnlyItemsForExactSupplier` | bit | Nein | Bei `1` werden nur Artikel genau des angegebenen Lieferanten geliefert. Wird ignoriert (auf `0` gesetzt), wenn `SupplNr` leer ist. |\n\n- Ergebnisspalten, Artikelfilter (Lieferant, Konfigurationstyp, Smart Search) und Joins stammen aus der Prozedur `pixi_ItemSearchPrepareDynamicQuery`. Deren Definition liegt nicht vor, daher kann die genaue Spaltenliste hier nicht dokumentiert werden.\n- Alle Lesezugriffe verwenden `NOLOCK`; Ergebnisse können daher nicht festgeschriebene Daten enthalten.\n- Das Verhalten hängt von den Einstellungen `ItemSearchLimit`, `MultiCurrencyEnabled` und `HalOrdersActiveDays` ab. Die Alt-Einstellung `ShowSupplPriceOnlyToTheseUsers` wird gelesen, hat aber keine Wirkung, da kein Benutzername übergeben wird.\n- `ShowStatistics = 1` wird an `GOSItemSearch1` übergeben, im vorliegenden Code dieser Prozedur aber nicht verwendet.\n- Stolperfalle: Bei genau einem exakten Code-Treffer über `ItemName` setzt der Code zuerst `ItemName` auf NULL und kopiert den Wert danach nach `EANUPC`. Dadurch wird auch `EANUPC` NULL.\n- Einfache Anführungszeichen in `ItemName` und `SupplNr` werden maskiert, bevor sie in das dynamische SQL eingesetzt werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiItemSearch"
},
"response": []
},
{
"name": "pixiReadAddItems",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Zusatzartikel-Datensätze (lieferantenbezogene Artikeldaten wie EAN, Lieferanten-Artikelnummer und Preise) aus `AddItems`, gefiltert nach Schlüssel, Zeitraum und Lieferant.\n\nLiest Datensätze aus der Tabelle `AddItems`. Diese enthalten lieferantenbezogene Artikeldaten: EAN/UPC, Lieferanten-Artikelnummer, interne Artikelnummer, Preise, MwSt-Satz und das Kennzeichen für den bevorzugten Lieferanten.\n\nZuerst werden die Parameter vorbereitet:\n\n- Ist `RowCount` gesetzt und ungleich `0`, wird die Anzahl der gelieferten Zeilen auf `RowCount` begrenzt.\n- Wird `AddItemKey` nicht übergeben, wird der Wert auf `0` gesetzt.\n- Ist `SupplNr` leer oder besteht nur aus Leerzeichen, gilt der Filter als nicht gesetzt.\n\nAnschließend wird genau eine der folgenden Abfragen ausgeführt. Es gilt der erste Zweig, dessen Bedingung zutrifft:\n\n1. **Anlage- oder Änderungsdatum** (`CreateAndUpdateDateFrom` und/oder `CreateAndUpdateDateTo` gesetzt): Datensätze mit `AddItemKey` > `AddItemKey`.\n - Die Untergrenze greift, wenn `CreateDate` **oder** `UpdateDate` >= `CreateAndUpdateDateFrom` ist.\n - Die Obergrenze greift, wenn `CreateDate` **oder** `UpdateDate` < `CreateAndUpdateDateTo` ist.\n2. **Anlagedatum** (`CreateDateFrom` und/oder `CreateDateTo` gesetzt): Datensätze mit `AddItemKey` > `AddItemKey` und `CreateDate` >= Von und < Bis.\n3. **Änderungsdatum** (`UpdateDateFrom` und/oder `UpdateDateTo` gesetzt): Datensätze mit `AddItemKey` > `AddItemKey` und `UpdateDate` >= Von und < Bis.\n4. **Schlüsselbereich** (`RowCount` übergeben, auch als `0`): Datensätze mit `AddItemKey` > `AddItemKey`.\n5. **Einzelner Schlüssel** (sonst): der Datensatz mit `AddItemKey` = `AddItemKey`.\n\nIn allen Zweigen schränkt der optionale Filter `SupplNr` das Ergebnis auf einen Lieferanten ein. Die Zweige 1 bis 4 sind aufsteigend nach `AddItemKey` sortiert. Damit ist Paging möglich: den zuletzt erhaltenen `AddItemKey` zusammen mit `RowCount` übergeben, um die nächste Seite zu erhalten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AddItemKey` | int | Nein | Schlüssel des Zusatzartikels. Ohne Datumsfilter und ohne `RowCount` wird genau der Datensatz mit diesem Schlüssel geliefert. Andernfalls werden nur Datensätze mit größerem Schlüssel geliefert (Startpunkt für Paging). `NULL` wird als `0` behandelt. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusiv) für `CreateDate`. Wird nur verwendet, wenn kein kombiniertes Anlage-/Änderungsdatum gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `CreateDate`. Wird nur verwendet, wenn kein kombiniertes Anlage-/Änderungsdatum gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusiv) für `UpdateDate`. Wird nur verwendet, wenn weder ein kombiniertes Datum noch ein Anlagedatum gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `UpdateDate`. Wird nur verwendet, wenn weder ein kombiniertes Datum noch ein Anlagedatum gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusiv). Trifft zu, wenn `CreateDate` oder `UpdateDate` an oder nach diesem Wert liegt. Hat Vorrang vor allen anderen Datumsparametern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (exklusiv). Trifft zu, wenn `CreateDate` oder `UpdateDate` vor diesem Wert liegt. Hat Vorrang vor allen anderen Datumsparametern. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen (über `SET ROWCOUNT`). Wird der Parameter ohne Datumsfilter übergeben, läuft die Schlüsselbereichs-Abfrage (`AddItemKey` > übergebener Schlüssel). `0` bedeutet keine Begrenzung. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Wenn gesetzt, werden nur Datensätze dieses Lieferanten geliefert. Leere oder nur aus Leerzeichen bestehende Werte werden ignoriert. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein.\n- Ohne Parameter wird `AddItemKey` auf `0` gesetzt und der Einzelschlüssel-Zweig ausgeführt. Dieser liefert in der Regel keine Zeilen.\n- Bei `RowCount` = `0` wird der Schlüsselbereichs-Zweig ohne Zeilenbegrenzung ausgeführt. Dann werden **alle** passenden Datensätze geliefert, was bei großen Tabellen langsam sein kann.\n- Die Grenzen des kombinierten Anlage-/Änderungsfilters werden jeweils gegen eine der beiden Datumsspalten geprüft. Ein Datensatz kann daher auch dann zutreffen, wenn keines der beiden Daten im Zeitraum liegt, etwa wenn `CreateDate` vor und `UpdateDate` nach dem Zeitraum liegt.\n- Bei `SupplNr` werden nur leere Werte normalisiert. Führende Leerzeichen werden nicht entfernt und können dazu führen, dass kein Datensatz gefunden wird.\n- Die Datumsfilter haben folgende Rangfolge: kombiniert Anlage/Änderung, Anlage, Änderung. Datumsparameter mit niedrigerem Rang werden ignoriert, wenn ein Parameter mit höherem Rang gesetzt ist.\n- Alle Obergrenzen sind exklusiv (`<`).\n- Der Kopfkommentar spricht von Lieferantendaten, die Prozedur liefert jedoch Zusatzartikel-Datensätze.\n- Die Spaltentypen sind im Code nicht sichtbar. Als `unknown` markierte Typen sind aus den Spaltennamen abgeleitet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadAddItems"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Zusatzartikel-Datensätze (lieferantenbezogene Artikeldaten wie EAN, Lieferanten-Artikelnummer und Preise) aus `AddItems`, gefiltert nach Schlüssel, Zeitraum und Lieferant.\n\nLiest Datensätze aus der Tabelle `AddItems`. Diese enthalten lieferantenbezogene Artikeldaten: EAN/UPC, Lieferanten-Artikelnummer, interne Artikelnummer, Preise, MwSt-Satz und das Kennzeichen für den bevorzugten Lieferanten.\n\nZuerst werden die Parameter vorbereitet:\n\n- Ist `RowCount` gesetzt und ungleich `0`, wird die Anzahl der gelieferten Zeilen auf `RowCount` begrenzt.\n- Wird `AddItemKey` nicht übergeben, wird der Wert auf `0` gesetzt.\n- Ist `SupplNr` leer oder besteht nur aus Leerzeichen, gilt der Filter als nicht gesetzt.\n\nAnschließend wird genau eine der folgenden Abfragen ausgeführt. Es gilt der erste Zweig, dessen Bedingung zutrifft:\n\n1. **Anlage- oder Änderungsdatum** (`CreateAndUpdateDateFrom` und/oder `CreateAndUpdateDateTo` gesetzt): Datensätze mit `AddItemKey` > `AddItemKey`.\n - Die Untergrenze greift, wenn `CreateDate` **oder** `UpdateDate` >= `CreateAndUpdateDateFrom` ist.\n - Die Obergrenze greift, wenn `CreateDate` **oder** `UpdateDate` < `CreateAndUpdateDateTo` ist.\n2. **Anlagedatum** (`CreateDateFrom` und/oder `CreateDateTo` gesetzt): Datensätze mit `AddItemKey` > `AddItemKey` und `CreateDate` >= Von und < Bis.\n3. **Änderungsdatum** (`UpdateDateFrom` und/oder `UpdateDateTo` gesetzt): Datensätze mit `AddItemKey` > `AddItemKey` und `UpdateDate` >= Von und < Bis.\n4. **Schlüsselbereich** (`RowCount` übergeben, auch als `0`): Datensätze mit `AddItemKey` > `AddItemKey`.\n5. **Einzelner Schlüssel** (sonst): der Datensatz mit `AddItemKey` = `AddItemKey`.\n\nIn allen Zweigen schränkt der optionale Filter `SupplNr` das Ergebnis auf einen Lieferanten ein. Die Zweige 1 bis 4 sind aufsteigend nach `AddItemKey` sortiert. Damit ist Paging möglich: den zuletzt erhaltenen `AddItemKey` zusammen mit `RowCount` übergeben, um die nächste Seite zu erhalten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AddItemKey` | int | Nein | Schlüssel des Zusatzartikels. Ohne Datumsfilter und ohne `RowCount` wird genau der Datensatz mit diesem Schlüssel geliefert. Andernfalls werden nur Datensätze mit größerem Schlüssel geliefert (Startpunkt für Paging). `NULL` wird als `0` behandelt. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusiv) für `CreateDate`. Wird nur verwendet, wenn kein kombiniertes Anlage-/Änderungsdatum gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `CreateDate`. Wird nur verwendet, wenn kein kombiniertes Anlage-/Änderungsdatum gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusiv) für `UpdateDate`. Wird nur verwendet, wenn weder ein kombiniertes Datum noch ein Anlagedatum gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `UpdateDate`. Wird nur verwendet, wenn weder ein kombiniertes Datum noch ein Anlagedatum gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusiv). Trifft zu, wenn `CreateDate` oder `UpdateDate` an oder nach diesem Wert liegt. Hat Vorrang vor allen anderen Datumsparametern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (exklusiv). Trifft zu, wenn `CreateDate` oder `UpdateDate` vor diesem Wert liegt. Hat Vorrang vor allen anderen Datumsparametern. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen (über `SET ROWCOUNT`). Wird der Parameter ohne Datumsfilter übergeben, läuft die Schlüsselbereichs-Abfrage (`AddItemKey` > übergebener Schlüssel). `0` bedeutet keine Begrenzung. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Wenn gesetzt, werden nur Datensätze dieses Lieferanten geliefert. Leere oder nur aus Leerzeichen bestehende Werte werden ignoriert. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein.\n- Ohne Parameter wird `AddItemKey` auf `0` gesetzt und der Einzelschlüssel-Zweig ausgeführt. Dieser liefert in der Regel keine Zeilen.\n- Bei `RowCount` = `0` wird der Schlüsselbereichs-Zweig ohne Zeilenbegrenzung ausgeführt. Dann werden **alle** passenden Datensätze geliefert, was bei großen Tabellen langsam sein kann.\n- Die Grenzen des kombinierten Anlage-/Änderungsfilters werden jeweils gegen eine der beiden Datumsspalten geprüft. Ein Datensatz kann daher auch dann zutreffen, wenn keines der beiden Daten im Zeitraum liegt, etwa wenn `CreateDate` vor und `UpdateDate` nach dem Zeitraum liegt.\n- Bei `SupplNr` werden nur leere Werte normalisiert. Führende Leerzeichen werden nicht entfernt und können dazu führen, dass kein Datensatz gefunden wird.\n- Die Datumsfilter haben folgende Rangfolge: kombiniert Anlage/Änderung, Anlage, Änderung. Datumsparameter mit niedrigerem Rang werden ignoriert, wenn ein Parameter mit höherem Rang gesetzt ist.\n- Alle Obergrenzen sind exklusiv (`<`).\n- Der Kopfkommentar spricht von Lieferantendaten, die Prozedur liefert jedoch Zusatzartikel-Datensätze.\n- Die Spaltentypen sind im Code nicht sichtbar. Als `unknown` markierte Typen sind aus den Spaltennamen abgeleitet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadAddItems"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1201\n 4006381333931\n \n SUP-77812\n 100245\n \n LI01\n 19.99\n 8.50\n EUR\n 19.00\n N\n 2024-03-01T09:15:00\n 2024-03-05T14:20:00\n 5531\n 2024-03-05T14:20:00\n SKU-100245\n Y\n Y\n \n"
}
]
},
{
"name": "pixiReadBundleItems",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Bundle-Artikel-Datensätze (Bundle-Komponenten) aus BundleItems, gefiltert nach Schlüssel, Anlage- und/oder Änderungsdatum, optional mit schlüsselbasiertem Paging.\n\nLiest Datensätze aus der Tabelle `BundleItems`. Jeder Datensatz verknüpft einen Artikel (`ItemRef`) mit einem enthaltenen Bundle-Artikel (`BundleItemRef`) und einer Menge (`Qty`).\n\nIst `RowCount` auf einen Wert ungleich 0 gesetzt, wird die Anzahl der zurückgegebenen Zeilen auf diesen Wert begrenzt. Wird `BundleItemKey` nicht übergeben, gilt der Wert `0`.\n\nDie Filterparameter werden in fester Reihenfolge geprüft. Verwendet wird nur die **erste** zutreffende Filtergruppe:\n\n1. **Kombinierter Datumsfilter**: `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` ist gesetzt. Die Untergrenze ist erfüllt, wenn `CreateDate` **oder** `UpdateDate` am oder nach `CreateAndUpdateDateFrom` liegt. Die Obergrenze ist erfüllt, wenn `CreateDate` **oder** `UpdateDate` vor `CreateAndUpdateDateTo` liegt. Geliefert werden nur Zeilen mit `BundleItemKey` > `BundleItemKey`.\n2. **Anlagedatumsfilter**: `CreateDateFrom` oder `CreateDateTo` ist gesetzt. Gefiltert wird mit `CreateDate` >= von und `CreateDate` < bis, zusätzlich gilt `BundleItemKey` > `BundleItemKey`.\n3. **Änderungsdatumsfilter**: `UpdateDateFrom` oder `UpdateDateTo` ist gesetzt. Gefiltert wird mit `UpdateDate` >= von und `UpdateDate` < bis, zusätzlich gilt `BundleItemKey` > `BundleItemKey`.\n4. **Schlüsselbereich / Paging**: Kein Datumsfilter ist gesetzt, aber `RowCount` wird übergeben. Geliefert werden alle Zeilen mit `BundleItemKey` > `BundleItemKey`.\n5. **Einzelner Datensatz**: Weder ein Datumsfilter noch `RowCount` wird übergeben. Geliefert wird die Zeile mit genau `BundleItemKey` = `BundleItemKey`.\n\nDie Untergrenzen schließen den angegebenen Wert ein, die Obergrenzen schließen ihn aus. Die Zweige 1 bis 4 sind aufsteigend nach `BundleItemKey` sortiert.\n\nFür Paging wird `RowCount` übergeben und `BundleItemKey` auf den letzten `BundleItemKey` der vorherigen Seite gesetzt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BundleItemKey` | int | Nein | Bei Datumsfiltern oder `RowCount`: Es werden nur Zeilen mit einem größeren Schlüssel geliefert (Paging-Start). Andernfalls: der exakte Schlüssel des zu lesenden Datensatzes. NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `CreateDate`. Wird nur verwendet, wenn kein kombinierter Datumsfilter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `CreateDate`. Wird nur verwendet, wenn kein kombinierter Datumsfilter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `UpdateDate`. Wird nur verwendet, wenn weder ein kombinierter Filter noch ein Anlagedatumsfilter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `UpdateDate`. Wird nur verwendet, wenn weder ein kombinierter Filter noch ein Anlagedatumsfilter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusive), die `CreateDate` oder `UpdateDate` erreichen muss. Hat Vorrang vor allen anderen Datumsfiltern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (exklusiv): `CreateDate` oder `UpdateDate` muss vor diesem Wert liegen. Hat Vorrang vor allen anderen Datumsfiltern. |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen (0 oder NULL = keine Begrenzung). Ist der Wert gesetzt und kein Datumsfilter angegeben, liefert der Aufruf Zeilen mit einem Schlüssel größer als `BundleItemKey` statt eines einzelnen Datensatzes. |\n\n- Alle Lesezugriffe verwenden `WITH (NOLOCK)`. Die Ergebnisse können nicht festgeschriebene Daten enthalten.\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`.\n- Wird `RowCount` = `0` übergeben, greift trotzdem Zweig 4 (Schlüsselbereich), da der Wert nicht NULL ist. In diesem Fall gilt keine Zeilenbegrenzung, und es werden alle Zeilen oberhalb des Schlüssels geliefert.\n- Ein Aufruf ohne Parameter liefert die Zeile mit `BundleItemKey` = 0. Das ergibt in der Regel ein leeres Ergebnis.\n- Der abschließende Zweig „keine Daten“ im Code ist nie erreichbar, da `BundleItemKey` an dieser Stelle nie NULL ist.\n- Die genaue Bedeutung von `ItemRef` und `BundleItemRef` ist im Code nicht festgelegt. Vermutlich ist `ItemRef` der Bundle-Artikel (übergeordneter Artikel) und `BundleItemRef` der enthaltene Komponenten-Artikel.\n- Die Datentypen der Spalten `ItemRef`, `BundleItemRef` und `Qty` sind im Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadBundleItems"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Bundle-Artikel-Datensätze (Bundle-Komponenten) aus BundleItems, gefiltert nach Schlüssel, Anlage- und/oder Änderungsdatum, optional mit schlüsselbasiertem Paging.\n\nLiest Datensätze aus der Tabelle `BundleItems`. Jeder Datensatz verknüpft einen Artikel (`ItemRef`) mit einem enthaltenen Bundle-Artikel (`BundleItemRef`) und einer Menge (`Qty`).\n\nIst `RowCount` auf einen Wert ungleich 0 gesetzt, wird die Anzahl der zurückgegebenen Zeilen auf diesen Wert begrenzt. Wird `BundleItemKey` nicht übergeben, gilt der Wert `0`.\n\nDie Filterparameter werden in fester Reihenfolge geprüft. Verwendet wird nur die **erste** zutreffende Filtergruppe:\n\n1. **Kombinierter Datumsfilter**: `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` ist gesetzt. Die Untergrenze ist erfüllt, wenn `CreateDate` **oder** `UpdateDate` am oder nach `CreateAndUpdateDateFrom` liegt. Die Obergrenze ist erfüllt, wenn `CreateDate` **oder** `UpdateDate` vor `CreateAndUpdateDateTo` liegt. Geliefert werden nur Zeilen mit `BundleItemKey` > `BundleItemKey`.\n2. **Anlagedatumsfilter**: `CreateDateFrom` oder `CreateDateTo` ist gesetzt. Gefiltert wird mit `CreateDate` >= von und `CreateDate` < bis, zusätzlich gilt `BundleItemKey` > `BundleItemKey`.\n3. **Änderungsdatumsfilter**: `UpdateDateFrom` oder `UpdateDateTo` ist gesetzt. Gefiltert wird mit `UpdateDate` >= von und `UpdateDate` < bis, zusätzlich gilt `BundleItemKey` > `BundleItemKey`.\n4. **Schlüsselbereich / Paging**: Kein Datumsfilter ist gesetzt, aber `RowCount` wird übergeben. Geliefert werden alle Zeilen mit `BundleItemKey` > `BundleItemKey`.\n5. **Einzelner Datensatz**: Weder ein Datumsfilter noch `RowCount` wird übergeben. Geliefert wird die Zeile mit genau `BundleItemKey` = `BundleItemKey`.\n\nDie Untergrenzen schließen den angegebenen Wert ein, die Obergrenzen schließen ihn aus. Die Zweige 1 bis 4 sind aufsteigend nach `BundleItemKey` sortiert.\n\nFür Paging wird `RowCount` übergeben und `BundleItemKey` auf den letzten `BundleItemKey` der vorherigen Seite gesetzt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BundleItemKey` | int | Nein | Bei Datumsfiltern oder `RowCount`: Es werden nur Zeilen mit einem größeren Schlüssel geliefert (Paging-Start). Andernfalls: der exakte Schlüssel des zu lesenden Datensatzes. NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `CreateDate`. Wird nur verwendet, wenn kein kombinierter Datumsfilter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `CreateDate`. Wird nur verwendet, wenn kein kombinierter Datumsfilter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `UpdateDate`. Wird nur verwendet, wenn weder ein kombinierter Filter noch ein Anlagedatumsfilter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `UpdateDate`. Wird nur verwendet, wenn weder ein kombinierter Filter noch ein Anlagedatumsfilter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusive), die `CreateDate` oder `UpdateDate` erreichen muss. Hat Vorrang vor allen anderen Datumsfiltern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (exklusiv): `CreateDate` oder `UpdateDate` muss vor diesem Wert liegen. Hat Vorrang vor allen anderen Datumsfiltern. |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen (0 oder NULL = keine Begrenzung). Ist der Wert gesetzt und kein Datumsfilter angegeben, liefert der Aufruf Zeilen mit einem Schlüssel größer als `BundleItemKey` statt eines einzelnen Datensatzes. |\n\n- Alle Lesezugriffe verwenden `WITH (NOLOCK)`. Die Ergebnisse können nicht festgeschriebene Daten enthalten.\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`.\n- Wird `RowCount` = `0` übergeben, greift trotzdem Zweig 4 (Schlüsselbereich), da der Wert nicht NULL ist. In diesem Fall gilt keine Zeilenbegrenzung, und es werden alle Zeilen oberhalb des Schlüssels geliefert.\n- Ein Aufruf ohne Parameter liefert die Zeile mit `BundleItemKey` = 0. Das ergibt in der Regel ein leeres Ergebnis.\n- Der abschließende Zweig „keine Daten“ im Code ist nie erreichbar, da `BundleItemKey` an dieser Stelle nie NULL ist.\n- Die genaue Bedeutung von `ItemRef` und `BundleItemRef` ist im Code nicht festgelegt. Vermutlich ist `ItemRef` der Bundle-Artikel (übergeordneter Artikel) und `BundleItemRef` der enthaltene Komponenten-Artikel.\n- Die Datentypen der Spalten `ItemRef`, `BundleItemRef` und `Qty` sind im Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadBundleItems"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 101\n 5012\n 4870\n 2\n 2024-01-15T10:22:31\n 2024-01-20T08:05:12\n \n \n 102\n 5012\n 4871\n 1\n 2024-01-15T10:22:31\n 2024-01-15T10:22:31\n \n"
}
]
},
{
"name": "pixiReadItems",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikelstammdaten für einen einzelnen Artikel, einen Schlüsselbereich oder im Zeitfenster angelegte/geänderte Artikel, sortiert nach ItemKey.\n\nLiest Artikel aus `items` und ergänzt sie um den Export-Lieferzeitwert, den Lieferantennamen und den Text der Konfigurationsart. Alle Modi liefern dieselben Spalten.\n\nZuerst wird, falls `RowCount` ungleich 0 ist, die Anzahl der zurückgegebenen Zeilen auf diesen Wert begrenzt. Ein fehlender `ItemKey` wird als `0` behandelt.\n\nEs gilt der erste zutreffende Modus:\n\n1. **Angelegt oder geändert** (`CreateAndUpdateDateFrom` und/oder `CreateAndUpdateDateTo` gesetzt): Artikel mit `ItemKey > ItemKey`, bei denen `CreateDate` **oder** `UpdateDate` `>=` dem Von-Wert ist und `CreateDate` **oder** `UpdateDate` `<` dem Bis-Wert ist. Sortiert nach `ItemKey` aufsteigend.\n2. **Angelegt** (`CreateDateFrom` und/oder `CreateDateTo` gesetzt): Artikel mit `ItemKey > ItemKey` und `CreateDate` in `[von, bis)`. Sortiert nach `ItemKey`.\n3. **Geändert** (`UpdateDateFrom` und/oder `UpdateDateTo` gesetzt): Artikel mit `ItemKey > ItemKey` und `UpdateDate` in `[von, bis)`. Sortiert nach `ItemKey`.\n4. **Schlüsselbereich** (`RowCount` nicht NULL): alle Artikel mit `ItemKey > ItemKey`, sortiert nach `ItemKey`.\n5. **Einzelartikel** (sonst): der Artikel, dessen `ItemKey` dem Parameter entspricht.\n\nIn den Modi 1–4 ist `ItemKey` eine exklusive Untergrenze. Damit ist Keyset-Paging möglich: den letzten `ItemKey` der vorherigen Seite zusammen mit `RowCount` übergeben.\n\nBei den Datumsprüfungen gelten nur die angegebenen Grenzen. Die Bis-Werte sind exklusiv.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel. Im Einzelartikelmodus der exakte Schlüssel. In Bereichs- und Datumsmodi eine exklusive Untergrenze (`ItemKey > Wert`). NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Liefert Artikel mit `CreateDate >=` diesem Wert (inklusiv). |\n| `CreateDateTo` | datetime | Nein | Liefert Artikel mit `CreateDate <` diesem Wert (exklusiv). |\n| `UpdateDateFrom` | datetime | Nein | Liefert Artikel mit `UpdateDate >=` diesem Wert. Wird ignoriert, wenn ein Anlagedatum oder kombiniertes Datum angegeben ist. |\n| `UpdateDateTo` | datetime | Nein | Liefert Artikel mit `UpdateDate <` diesem Wert (exklusiv). Wird ignoriert, wenn ein Anlagedatum oder kombiniertes Datum angegeben ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Liefert Artikel, deren `CreateDate` oder `UpdateDate` `>=` diesem Wert ist. Hat Vorrang vor allen anderen Datumsparametern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Liefert Artikel, deren `CreateDate` oder `UpdateDate` `<` diesem Wert ist (exklusiv). Hat Vorrang vor allen anderen Datumsparametern. |\n| `RowCount` | int | Nein | Maximale Zeilenanzahl (Seitengröße). Werte ungleich 0 begrenzen das Ergebnis. Jeder Wert ungleich NULL ohne Datumsfilter wählt den Schlüsselbereichsmodus. `0` bedeutet keine Begrenzung. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen. Ergebnisse können nicht festgeschriebene oder inkonsistente Daten enthalten.\n- Ein Aufruf ohne Parameter landet in Modus 5 mit `ItemKey = 0`. Das liefert normalerweise ein leeres Ergebnis. Der letzte `ELSE`-Zweig im Code, der eine leere Ergebnismenge liefert, wird nie erreicht.\n- `RowCount = 0` wählt Modus 4 (ohne Datumsfilter) ohne Zeilenbegrenzung. Es werden alle Artikel mit `ItemKey > ItemKey` geliefert, was sehr viele sein können.\n- `RowCount` wirkt über `SET ROWCOUNT` und begrenzt daher auch Modus 5. Dieser Modus liefert ohnehin höchstens eine Zeile.\n- Im kombinierten Modus werden Von- und Bis-Grenze unabhängig gegen `CreateDate` oder `UpdateDate` geprüft. Beispielsweise erfüllt ein Artikel, der vor dem Von-Datum angelegt, aber danach geändert wurde, die Von-Bedingung.\n- Datumsparameter verschiedener Modi werden nicht kombiniert. Sind kombinierte Datumswerte gesetzt, werden die getrennten Anlage-/Änderungsdaten ignoriert, und Anlagedaten haben Vorrang vor Änderungsdaten.\n- Existieren für einen Artikel mehrere Zeilen in `Item_EstimatedDelivery`, wird der Artikel mehrfach geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadItems"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikelstammdaten für einen einzelnen Artikel, einen Schlüsselbereich oder im Zeitfenster angelegte/geänderte Artikel, sortiert nach ItemKey.\n\nLiest Artikel aus `items` und ergänzt sie um den Export-Lieferzeitwert, den Lieferantennamen und den Text der Konfigurationsart. Alle Modi liefern dieselben Spalten.\n\nZuerst wird, falls `RowCount` ungleich 0 ist, die Anzahl der zurückgegebenen Zeilen auf diesen Wert begrenzt. Ein fehlender `ItemKey` wird als `0` behandelt.\n\nEs gilt der erste zutreffende Modus:\n\n1. **Angelegt oder geändert** (`CreateAndUpdateDateFrom` und/oder `CreateAndUpdateDateTo` gesetzt): Artikel mit `ItemKey > ItemKey`, bei denen `CreateDate` **oder** `UpdateDate` `>=` dem Von-Wert ist und `CreateDate` **oder** `UpdateDate` `<` dem Bis-Wert ist. Sortiert nach `ItemKey` aufsteigend.\n2. **Angelegt** (`CreateDateFrom` und/oder `CreateDateTo` gesetzt): Artikel mit `ItemKey > ItemKey` und `CreateDate` in `[von, bis)`. Sortiert nach `ItemKey`.\n3. **Geändert** (`UpdateDateFrom` und/oder `UpdateDateTo` gesetzt): Artikel mit `ItemKey > ItemKey` und `UpdateDate` in `[von, bis)`. Sortiert nach `ItemKey`.\n4. **Schlüsselbereich** (`RowCount` nicht NULL): alle Artikel mit `ItemKey > ItemKey`, sortiert nach `ItemKey`.\n5. **Einzelartikel** (sonst): der Artikel, dessen `ItemKey` dem Parameter entspricht.\n\nIn den Modi 1–4 ist `ItemKey` eine exklusive Untergrenze. Damit ist Keyset-Paging möglich: den letzten `ItemKey` der vorherigen Seite zusammen mit `RowCount` übergeben.\n\nBei den Datumsprüfungen gelten nur die angegebenen Grenzen. Die Bis-Werte sind exklusiv.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel. Im Einzelartikelmodus der exakte Schlüssel. In Bereichs- und Datumsmodi eine exklusive Untergrenze (`ItemKey > Wert`). NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Liefert Artikel mit `CreateDate >=` diesem Wert (inklusiv). |\n| `CreateDateTo` | datetime | Nein | Liefert Artikel mit `CreateDate <` diesem Wert (exklusiv). |\n| `UpdateDateFrom` | datetime | Nein | Liefert Artikel mit `UpdateDate >=` diesem Wert. Wird ignoriert, wenn ein Anlagedatum oder kombiniertes Datum angegeben ist. |\n| `UpdateDateTo` | datetime | Nein | Liefert Artikel mit `UpdateDate <` diesem Wert (exklusiv). Wird ignoriert, wenn ein Anlagedatum oder kombiniertes Datum angegeben ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Liefert Artikel, deren `CreateDate` oder `UpdateDate` `>=` diesem Wert ist. Hat Vorrang vor allen anderen Datumsparametern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Liefert Artikel, deren `CreateDate` oder `UpdateDate` `<` diesem Wert ist (exklusiv). Hat Vorrang vor allen anderen Datumsparametern. |\n| `RowCount` | int | Nein | Maximale Zeilenanzahl (Seitengröße). Werte ungleich 0 begrenzen das Ergebnis. Jeder Wert ungleich NULL ohne Datumsfilter wählt den Schlüsselbereichsmodus. `0` bedeutet keine Begrenzung. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen. Ergebnisse können nicht festgeschriebene oder inkonsistente Daten enthalten.\n- Ein Aufruf ohne Parameter landet in Modus 5 mit `ItemKey = 0`. Das liefert normalerweise ein leeres Ergebnis. Der letzte `ELSE`-Zweig im Code, der eine leere Ergebnismenge liefert, wird nie erreicht.\n- `RowCount = 0` wählt Modus 4 (ohne Datumsfilter) ohne Zeilenbegrenzung. Es werden alle Artikel mit `ItemKey > ItemKey` geliefert, was sehr viele sein können.\n- `RowCount` wirkt über `SET ROWCOUNT` und begrenzt daher auch Modus 5. Dieser Modus liefert ohnehin höchstens eine Zeile.\n- Im kombinierten Modus werden Von- und Bis-Grenze unabhängig gegen `CreateDate` oder `UpdateDate` geprüft. Beispielsweise erfüllt ein Artikel, der vor dem Von-Datum angelegt, aber danach geändert wurde, die Von-Bedingung.\n- Datumsparameter verschiedener Modi werden nicht kombiniert. Sind kombinierte Datumswerte gesetzt, werden die getrennten Anlage-/Änderungsdaten ignoriert, und Anlagedaten haben Vorrang vor Änderungsdaten.\n- Existieren für einen Artikel mehrere Zeilen in `Item_EstimatedDelivery`, wird der Artikel mehrfach geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadItems"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 12346\n 4006381333931\n STB-100\n A-100234\n SUP01\n Ballpoint pen blue\n STD\n 2.49\n 0.95\n 19\n 0.02\n 2024-01-15T10:22:00\n 2024-03-01T08:10:00\n 120\n 1\n 0\n Office Supplies GmbH\n Standard\n Stabilo\n \n"
}
]
},
{
"name": "pixiReadItemTagMatching",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Zuordnungen von Artikel-Tags zu Artikeln seitenweise mit Keyset-Paging über die Zuordnungs-ID.\n\nLiest Tag-Zuordnungen aus `TagMatch` und liefert nur solche, deren Tag in `Tag` den Wert `TypeId = 1` hat. Laut Code-Kommentar sind das Artikel-Tags.\n\n- Es werden nur Zuordnungen mit einer ID größer als `@Start` geliefert.\n- Es werden höchstens `@RowCount` Zeilen geliefert.\n- Die Sortierung erfolgt aufsteigend nach der Zuordnungs-ID (`ItemMatchKey`).\n\n**Paging:** `@Start` ist kein Zeilen-Offset, sondern der zuletzt erhaltene `ItemMatchKey`. Zum Lesen aller Zuordnungen mit `Start = 0` beginnen. Danach erneut aufrufen und `Start` auf den höchsten `ItemMatchKey` der vorherigen Seite setzen. Aufhören, sobald weniger als `RowCount` Zeilen zurückkommen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Start` | int | Nein | Es werden nur Zuordnungen mit einer ID (`ItemMatchKey`) größer als dieser Wert geliefert. Für die nächste Seite den letzten `ItemMatchKey` der vorherigen Seite übergeben. |\n| `RowCount` | int | Nein | Maximale Anzahl der gelieferten Zeilen. |\n\n- Beide Tabellen werden mit `NOLOCK` gelesen. Nicht festgeschriebene Änderungen können daher sichtbar sein, und bei gleichzeitigen Schreibvorgängen können Zeilen fehlen oder doppelt erscheinen.\n- Die Bedeutung von `TypeId = 1` (Artikel-Tags) stammt aus dem Kommentar der Prozedur; andere Tag-Typen werden ignoriert.\n- Der Aufruf liefert nur IDs. Tag-Namen und Artikeldetails müssen über andere Aufrufe gelesen werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadItemTagMatching"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Zuordnungen von Artikel-Tags zu Artikeln seitenweise mit Keyset-Paging über die Zuordnungs-ID.\n\nLiest Tag-Zuordnungen aus `TagMatch` und liefert nur solche, deren Tag in `Tag` den Wert `TypeId = 1` hat. Laut Code-Kommentar sind das Artikel-Tags.\n\n- Es werden nur Zuordnungen mit einer ID größer als `@Start` geliefert.\n- Es werden höchstens `@RowCount` Zeilen geliefert.\n- Die Sortierung erfolgt aufsteigend nach der Zuordnungs-ID (`ItemMatchKey`).\n\n**Paging:** `@Start` ist kein Zeilen-Offset, sondern der zuletzt erhaltene `ItemMatchKey`. Zum Lesen aller Zuordnungen mit `Start = 0` beginnen. Danach erneut aufrufen und `Start` auf den höchsten `ItemMatchKey` der vorherigen Seite setzen. Aufhören, sobald weniger als `RowCount` Zeilen zurückkommen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Start` | int | Nein | Es werden nur Zuordnungen mit einer ID (`ItemMatchKey`) größer als dieser Wert geliefert. Für die nächste Seite den letzten `ItemMatchKey` der vorherigen Seite übergeben. |\n| `RowCount` | int | Nein | Maximale Anzahl der gelieferten Zeilen. |\n\n- Beide Tabellen werden mit `NOLOCK` gelesen. Nicht festgeschriebene Änderungen können daher sichtbar sein, und bei gleichzeitigen Schreibvorgängen können Zeilen fehlen oder doppelt erscheinen.\n- Die Bedeutung von `TypeId = 1` (Artikel-Tags) stammt aus dem Kommentar der Prozedur; andere Tag-Typen werden ignoriert.\n- Der Aufruf liefert nur IDs. Tag-Namen und Artikeldetails müssen über andere Aufrufe gelesen werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadItemTagMatching"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 101\n 5\n 23817\n \n \n 102\n 7\n 23817\n \n"
}
]
},
{
"name": "pixiReadItemTags",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die in Pixi definierten Artikel-Tags sortiert nach Tag-Schlüssel, mit Paging über Startschlüssel und Zeilenanzahl.\n\nLiest Tags vom Typ Artikel (`TypeId = 1`) aus der Tag-Tabelle.\n\n- Es werden nur Tags geliefert, deren Schlüssel größer als `Start` ist.\n- Das Ergebnis ist aufsteigend nach `TagKey` sortiert und auf `RowCount` Zeilen begrenzt.\n- Ist `RowCount` `NULL` oder kleiner als 1, werden 1000 Zeilen geliefert.\n\n**Paging:** Für die nächste Seite wird der höchste `TagKey` der vorherigen Seite als `Start` übergeben. Dies wird wiederholt, bis weniger als `RowCount` Zeilen zurückkommen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Start` | int | Nein | Es werden nur Tags mit einem Schlüssel größer als dieser Wert geliefert. Für Paging den letzten `TagKey` der vorherigen Seite verwenden. |\n| `RowCount` | int | Nein | Maximale Anzahl zu liefernder Zeilen. `NULL` oder Werte kleiner als 1 werden durch 1000 ersetzt. |\n\nDie Tabelle wird mit `NOLOCK` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein. Tags anderer Typen (andere `TypeId`-Werte) werden nicht geliefert. Der Aufruf listet nur Tag-Definitionen; welche Artikel ein Tag tragen, wird nicht geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadItemTags"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die in Pixi definierten Artikel-Tags sortiert nach Tag-Schlüssel, mit Paging über Startschlüssel und Zeilenanzahl.\n\nLiest Tags vom Typ Artikel (`TypeId = 1`) aus der Tag-Tabelle.\n\n- Es werden nur Tags geliefert, deren Schlüssel größer als `Start` ist.\n- Das Ergebnis ist aufsteigend nach `TagKey` sortiert und auf `RowCount` Zeilen begrenzt.\n- Ist `RowCount` `NULL` oder kleiner als 1, werden 1000 Zeilen geliefert.\n\n**Paging:** Für die nächste Seite wird der höchste `TagKey` der vorherigen Seite als `Start` übergeben. Dies wird wiederholt, bis weniger als `RowCount` Zeilen zurückkommen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Start` | int | Nein | Es werden nur Tags mit einem Schlüssel größer als dieser Wert geliefert. Für Paging den letzten `TagKey` der vorherigen Seite verwenden. |\n| `RowCount` | int | Nein | Maximale Anzahl zu liefernder Zeilen. `NULL` oder Werte kleiner als 1 werden durch 1000 ersetzt. |\n\nDie Tabelle wird mit `NOLOCK` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein. Tags anderer Typen (andere `TypeId`-Werte) werden nicht geliefert. Der Aufruf listet nur Tag-Definitionen; welche Artikel ein Tag tragen, wird nicht geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadItemTags"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 3\n Bestseller\n Top selling items\n false\n \n \n 7\n Fragile\n Handle with care\n false\n \n"
}
]
},
{
"name": "pixiSetItemBuyingInfo",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt Mindestbestand, Mindestbestellmenge, Zielbestand und Sicherheitsbestand eines Artikels global oder für ein bestimmtes Lager.\n\nAktualisiert die einkaufsrelevanten Mengen eines Artikels.\n\n**Normalisierung der Eingaben**\n- `ItemKey` = `0` und Leerstrings in allen übrigen Parametern werden als `NULL` behandelt, also als \"nicht angegeben\".\n- Ein negativer `TargetStock` wird durch `0` ersetzt.\n\n**Ermittlung des Artikels**\n\nDer Artikel wird in `items` über `ItemKey`, `ItemNrInt` **oder** `EANUPC` gesucht. Die Bedingungen sind mit ODER verknüpft; jeder Datensatz, der zu einem der Identifikatoren passt, wird verwendet. Wird kein Artikel gefunden, bleibt der übergebene `ItemKey` unverändert.\n\n**Artikelebene (`items`)**\n\nDieser Schritt wird nur ausgeführt, wenn kein `Location` angegeben ist und mindestens `MinStockQty` oder `MinOrderQty` gesetzt ist. Er aktualisiert `MinStockQty` und `MinOrderQty` des Artikels. Ein nicht angegebener Wert behält seinen bisherigen Inhalt.\n\n**Lagerebene (`ItemLocationSpecific`)**\n\nDieser Schritt wird ausgeführt, wenn mindestens eine der vier Mengen gesetzt ist. Er aktualisiert `MinStockQty`, `MinOrderQty`, `TargetStock` und `SafetyStock` der lagerspezifischen Datensätze des Artikels:\n- Ist `Location` angegeben, wird nur der Datensatz mit dieser `LocID` aktualisiert.\n- Ist `Location` nicht angegeben, werden **alle** Lagerdatensätze des Artikels aktualisiert.\n\nNicht angegebene Werte bleiben unverändert.\n\n`TargetStock` und `SafetyStock` existieren nur auf Lagerebene.\n\nDie Prozedur liefert keine Ergebnismenge.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. `0` gilt als nicht angegeben. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer als alternativer Identifikator. Ein Leerstring gilt als nicht angegeben. |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC des Artikels als alternativer Identifikator. Ein Leerstring gilt als nicht angegeben. |\n| `Location` | varchar(3) | Nein | Lager-ID (`LocID`). Ist sie gesetzt, wird nur der lagerspezifische Datensatz dieses Lagers aktualisiert; die Werte auf Artikelebene bleiben unverändert. Ist sie leer, werden die Artikelebene und alle Lagerdatensätze aktualisiert. |\n| `MinStockQty` | varchar(10) | Nein | Neuer Mindestbestand als ganzzahliger String. Leer bedeutet: der Wert wird nicht geändert. |\n| `MinOrderQty` | varchar(10) | Nein | Neue Mindestbestellmenge als ganzzahliger String. Leer bedeutet: der Wert wird nicht geändert. |\n| `TargetStock` | varchar(10) | Nein | Neuer Zielbestand, nur auf Lagerebene, als ganzzahliger String. Negative Werte werden auf `0` gesetzt. Leer bedeutet: der Wert wird nicht geändert. |\n| `SafetyStock` | varchar(10) | Nein | Neuer Sicherheitsbestand, nur auf Lagerebene, als ganzzahliger String. Leer bedeutet: der Wert wird nicht geändert. |\n\n- **Transaktionen:** Die Prozedur läuft in einer eigenen Transaktion oder in einem Savepoint, falls bereits eine Transaktion offen ist.\n- **Fehler werden nicht zurückgemeldet:** Alle Fehler werden abgefangen und an `log.InsertError` übergeben. Beispiele sind eine nicht numerische Menge, deren Umwandlung nach `int` scheitert, oder ein Wert mit mehr als 10 Zeichen. Dieses Objekt liegt nicht vor; ob dabei etwas an den Aufrufer zurückgegeben wird, ist unbekannt. Ein erfolgreicher und ein fehlgeschlagener Aufruf können daher gleich aussehen.\n- **Mehrdeutige Identifikatoren:** Passen mehrere Artikel zur ODER-Bedingung, etwa wenn die Identifikatoren zu verschiedenen Artikeln gehören, wird einer davon willkürlich gewählt. Es sollte nur ein Identifikator oder konsistente Identifikatoren übergeben werden.\n- **Artikel nicht gefunden:** Wird kein Artikel gefunden, wird nichts aktualisiert und keine Meldung geliefert.\n- **Keine Bereichsprüfung:** Nur `TargetStock` wird auf `0` begrenzt. Negative Werte für `MinStockQty`, `MinOrderQty` und `SafetyStock` werden unverändert gespeichert.\n- **Sperren:** Lesezugriffe verwenden `NOLOCK`, Updates verwenden `ROWLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemBuyingInfo"
},
"response": []
},
{
"name": "pixiSetItemBuyingInfoXML",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Einkaufsdaten wie Mindestbestand, Mindestbestellmenge, Bestelleinheit, Soll- und Sicherheitsbestand für mehrere Artikel aus einem XML-Dokument.\n\nLiest pro Artikel ein `Item`-Element aus `/BuyingInfo/Item` (elementbasiert) und schreibt die übergebenen Werte in die Artikelstammdaten, die lagerspezifischen Artikeldaten und die Lieferanten-Artikeldaten.\n\n**Ermittlung des Artikels**\n\nEin Artikel kann über `ItemKey`, `ItemNrInt` oder `EAN` identifiziert werden. Die Suche erfolgt in dieser Reihenfolge: über `ItemKey`, dann über `ItemNrInt`, dann über `EAN`. Jeder Treffer überschreibt die Kennungen mit denen des gefundenen Artikels, ein späterer Treffer hat also Vorrang. Einträge, zu denen kein Artikel gefunden wird, werden ohne Meldung übergangen.\n\n**Bereinigung der Werte**\n\n- Leere Textfelder (`ItemNrInt`, `EAN`, `Location`, `SupplierCode`) sowie ein leerer oder mit `0` belegter `ItemKey` gelten als nicht übergeben.\n- Mengenfelder (`MinStockQty`, `MinOrderQty`, `OrderUnit`, `VPE`, `TargetStock`, `SafetyStock`) werden nur verwendet, wenn sie numerisch sind; andernfalls werden sie ignoriert.\n- `OrderUnit` und `VPE` werden zusammengeführt: Ist `OrderUnit` angegeben, wird dieser Wert für beide verwendet, sonst `VPE` für beide.\n- Ein negativer `TargetStock` wird auf `0` gesetzt.\n- Nicht übergebene Felder (NULL) bleiben unverändert.\n\n**Was aktualisiert wird**\n\n- `MinStockQty`: im Artikelstamm (`items`) nur, wenn keine `Location` angegeben ist; in `ItemLocationSpecific` für alle Lager des Artikels, wenn keine `Location` angegeben ist, sonst nur für dieses Lager.\n- `MinOrderQty`: gleiche Regel wie `MinStockQty`; zusätzlich beim Lieferanten-Artikel (`AddItems`) für den in `SupplierCode` angegebenen Lieferanten (unabhängig von `Location`).\n- `OrderUnit` / `VPE`: nur im Artikelstamm und nur, wenn keine `Location` angegeben ist.\n- `TargetStock` und `SafetyStock`: nur in `ItemLocationSpecific`, für alle Lager oder nur für die angegebene `Location`.\n\n**Ergebnis**\n\nLiefert pro gefundenem Artikel eine Zeile mit den ermittelten Kennungen und den übernommenen Werten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BuyingXML` | varchar(max) | Nein | XML-Dokument mit einem `Item`-Element pro Artikel unterhalb des Wurzelelements `BuyingInfo`. Jeder Artikel wird über `ItemKey`, `ItemNrInt` oder `EAN` identifiziert; die übrigen Elemente enthalten die zu setzenden Werte. `Location` (max. 3 Zeichen) beschränkt lagerspezifische Änderungen auf ein Lager, `SupplierCode` (max. 4 Zeichen) wählt den Lieferanten-Artikel für `MinOrderQty`. |\n\n- Alle Änderungen laufen in einer Transaktion (bzw. einem Savepoint, wenn der Aufrufer bereits eine Transaktion geöffnet hat). Bei einem Fehler werden die Änderungen zurückgerollt und der Fehler über `log.InsertError` protokolliert; dieses Objekt liegt nicht vor, daher ist offen, ob der Fehler an den Aufrufer weitergegeben wird. In diesem Fall wird keine Ergebnismenge geliefert.\n- `ISNUMERIC` akzeptiert auch Werte wie `1.5` oder `1e3`. Solche Werte bestehen die Prüfung, scheitern aber bei der Umwandlung nach `int` und brechen den gesamten Aufruf mit Rollback ab. Nur ganze Zahlen übergeben.\n- Die Artikelsuche verwendet `NOLOCK`. Teilen sich mehrere Artikel dieselbe EAN, kann die EAN-Suche einen beliebigen davon wählen und einen Treffer über `ItemKey` oder `ItemNrInt` überschreiben.\n- Werte können nicht geleert werden: Ein leeres Element bedeutet \"nicht ändern\". Zum Zurücksetzen einer Menge `0` übergeben.\n- `Location` wird in der Ergebnismenge nicht zurückgegeben, und die Zeile zeigt nicht, ob ein Lager- oder Lieferantendatensatz tatsächlich existierte.\n- Der Kopfkommentar (\"Set Tags for Items\") entspricht nicht der tatsächlichen Funktion der Prozedur.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemBuyingInfoXML"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Einkaufsdaten wie Mindestbestand, Mindestbestellmenge, Bestelleinheit, Soll- und Sicherheitsbestand für mehrere Artikel aus einem XML-Dokument.\n\nLiest pro Artikel ein `Item`-Element aus `/BuyingInfo/Item` (elementbasiert) und schreibt die übergebenen Werte in die Artikelstammdaten, die lagerspezifischen Artikeldaten und die Lieferanten-Artikeldaten.\n\n**Ermittlung des Artikels**\n\nEin Artikel kann über `ItemKey`, `ItemNrInt` oder `EAN` identifiziert werden. Die Suche erfolgt in dieser Reihenfolge: über `ItemKey`, dann über `ItemNrInt`, dann über `EAN`. Jeder Treffer überschreibt die Kennungen mit denen des gefundenen Artikels, ein späterer Treffer hat also Vorrang. Einträge, zu denen kein Artikel gefunden wird, werden ohne Meldung übergangen.\n\n**Bereinigung der Werte**\n\n- Leere Textfelder (`ItemNrInt`, `EAN`, `Location`, `SupplierCode`) sowie ein leerer oder mit `0` belegter `ItemKey` gelten als nicht übergeben.\n- Mengenfelder (`MinStockQty`, `MinOrderQty`, `OrderUnit`, `VPE`, `TargetStock`, `SafetyStock`) werden nur verwendet, wenn sie numerisch sind; andernfalls werden sie ignoriert.\n- `OrderUnit` und `VPE` werden zusammengeführt: Ist `OrderUnit` angegeben, wird dieser Wert für beide verwendet, sonst `VPE` für beide.\n- Ein negativer `TargetStock` wird auf `0` gesetzt.\n- Nicht übergebene Felder (NULL) bleiben unverändert.\n\n**Was aktualisiert wird**\n\n- `MinStockQty`: im Artikelstamm (`items`) nur, wenn keine `Location` angegeben ist; in `ItemLocationSpecific` für alle Lager des Artikels, wenn keine `Location` angegeben ist, sonst nur für dieses Lager.\n- `MinOrderQty`: gleiche Regel wie `MinStockQty`; zusätzlich beim Lieferanten-Artikel (`AddItems`) für den in `SupplierCode` angegebenen Lieferanten (unabhängig von `Location`).\n- `OrderUnit` / `VPE`: nur im Artikelstamm und nur, wenn keine `Location` angegeben ist.\n- `TargetStock` und `SafetyStock`: nur in `ItemLocationSpecific`, für alle Lager oder nur für die angegebene `Location`.\n\n**Ergebnis**\n\nLiefert pro gefundenem Artikel eine Zeile mit den ermittelten Kennungen und den übernommenen Werten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BuyingXML` | varchar(max) | Nein | XML-Dokument mit einem `Item`-Element pro Artikel unterhalb des Wurzelelements `BuyingInfo`. Jeder Artikel wird über `ItemKey`, `ItemNrInt` oder `EAN` identifiziert; die übrigen Elemente enthalten die zu setzenden Werte. `Location` (max. 3 Zeichen) beschränkt lagerspezifische Änderungen auf ein Lager, `SupplierCode` (max. 4 Zeichen) wählt den Lieferanten-Artikel für `MinOrderQty`. |\n\n- Alle Änderungen laufen in einer Transaktion (bzw. einem Savepoint, wenn der Aufrufer bereits eine Transaktion geöffnet hat). Bei einem Fehler werden die Änderungen zurückgerollt und der Fehler über `log.InsertError` protokolliert; dieses Objekt liegt nicht vor, daher ist offen, ob der Fehler an den Aufrufer weitergegeben wird. In diesem Fall wird keine Ergebnismenge geliefert.\n- `ISNUMERIC` akzeptiert auch Werte wie `1.5` oder `1e3`. Solche Werte bestehen die Prüfung, scheitern aber bei der Umwandlung nach `int` und brechen den gesamten Aufruf mit Rollback ab. Nur ganze Zahlen übergeben.\n- Die Artikelsuche verwendet `NOLOCK`. Teilen sich mehrere Artikel dieselbe EAN, kann die EAN-Suche einen beliebigen davon wählen und einen Treffer über `ItemKey` oder `ItemNrInt` überschreiben.\n- Werte können nicht geleert werden: Ein leeres Element bedeutet \"nicht ändern\". Zum Zurücksetzen einer Menge `0` übergeben.\n- `Location` wird in der Ergebnismenge nicht zurückgegeben, und die Zeile zeigt nicht, ob ein Lager- oder Lieferantendatensatz tatsächlich existierte.\n- Der Kopfkommentar (\"Set Tags for Items\") entspricht nicht der tatsächlichen Funktion der Prozedur.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemBuyingInfoXML"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10045\n A-10045\n 4006381333931\n 20\n 50\n L001\n 100\n 15\n 10\n \n \n 10046\n A-10046\n 4006381333948\n 5\n 30\n 3\n 6\n \n"
}
]
},
{
"name": "pixiSetItemCategory",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n Textilien\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Weist einem Artikel, identifiziert über Artikel-Key oder interne Artikelnummer, eine Kategorie aus der Tabelle TontrArten zu.\n\nSetzt die Kategorie eines einzelnen Artikels.\n\n1. **Artikel ermitteln:** Ist `ItemKEy` angegeben, wird dieser direkt verwendet. Ist er `NULL`, wird der Artikel über `ItemNRInt` (interne Artikelnummer) in `items` gesucht. Bei mehreren Treffern wird ein beliebiger verwendet (`TOP (1)` ohne Sortierung).\n2. Kann kein Artikel-Key ermittelt werden, wird eine Zeile mit `Error` = `Item not found.` geliefert; es erfolgt keine Änderung.\n3. **Kategorie suchen:** Die Kategorie wird in `TontrArten` über ihren Text gesucht (`TontrText` = `Category`). Gelesen werden `TontrArt` (Konfigurationstyp) und `TontrArtKey` (Kategorie-ID) des ersten Treffers.\n4. Wird keine Kategorie gefunden oder hat der gefundene Datensatz kein `TontrArt`, wird eine Zeile mit `Error` = `Category is not existing.` geliefert; es erfolgt keine Änderung.\n5. Andernfalls werden die Spalten `ConfigType` und `CategoryId` des Artikels aktualisiert und eine Zeile mit `Error` = `OK` geliefert.\n\nDer Aufruf liefert immer genau eine Zeile mit der Spalte `Error`, die den Statustext enthält.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKEy` | int | Nein | Interner Key des Artikels (`items.ItemKey`). Hat Vorrang vor `ItemNRInt`. |\n| `ItemNRInt` | varchar(50) | Nein | Interne Artikelnummer (`items.ItemNrInt`). Wird nur verwendet, wenn `ItemKEy` `NULL` ist. |\n| `Category` | varchar(50) | Ja | Text der Kategorie, wie in `TontrArten.TontrText` hinterlegt. |\n\n- Wird `ItemKEy` übergeben, wird dessen Existenz **nicht** geprüft. Bei einem nicht vorhandenen Key ändert das Update keine Zeile, der Aufruf liefert trotzdem `OK`.\n- Werden `ItemKEy` und `ItemNRInt` gemeinsam übergeben, wird `ItemNRInt` ignoriert.\n- Die Kategorie wird über ihren Anzeigetext gesucht, nicht über den Key. Haben mehrere Kategorien denselben Text, wird eine beliebige verwendet.\n- Die Lesezugriffe verwenden `NOLOCK` (Dirty Reads möglich); das Update verwendet `ROWLOCK`. Es wird keine explizite Transaktion verwendet.\n- Die Statusspalte heißt auch im Erfolgsfall (`OK`) `Error`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemCategory"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n Textilien\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Weist einem Artikel, identifiziert über Artikel-Key oder interne Artikelnummer, eine Kategorie aus der Tabelle TontrArten zu.\n\nSetzt die Kategorie eines einzelnen Artikels.\n\n1. **Artikel ermitteln:** Ist `ItemKEy` angegeben, wird dieser direkt verwendet. Ist er `NULL`, wird der Artikel über `ItemNRInt` (interne Artikelnummer) in `items` gesucht. Bei mehreren Treffern wird ein beliebiger verwendet (`TOP (1)` ohne Sortierung).\n2. Kann kein Artikel-Key ermittelt werden, wird eine Zeile mit `Error` = `Item not found.` geliefert; es erfolgt keine Änderung.\n3. **Kategorie suchen:** Die Kategorie wird in `TontrArten` über ihren Text gesucht (`TontrText` = `Category`). Gelesen werden `TontrArt` (Konfigurationstyp) und `TontrArtKey` (Kategorie-ID) des ersten Treffers.\n4. Wird keine Kategorie gefunden oder hat der gefundene Datensatz kein `TontrArt`, wird eine Zeile mit `Error` = `Category is not existing.` geliefert; es erfolgt keine Änderung.\n5. Andernfalls werden die Spalten `ConfigType` und `CategoryId` des Artikels aktualisiert und eine Zeile mit `Error` = `OK` geliefert.\n\nDer Aufruf liefert immer genau eine Zeile mit der Spalte `Error`, die den Statustext enthält.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKEy` | int | Nein | Interner Key des Artikels (`items.ItemKey`). Hat Vorrang vor `ItemNRInt`. |\n| `ItemNRInt` | varchar(50) | Nein | Interne Artikelnummer (`items.ItemNrInt`). Wird nur verwendet, wenn `ItemKEy` `NULL` ist. |\n| `Category` | varchar(50) | Ja | Text der Kategorie, wie in `TontrArten.TontrText` hinterlegt. |\n\n- Wird `ItemKEy` übergeben, wird dessen Existenz **nicht** geprüft. Bei einem nicht vorhandenen Key ändert das Update keine Zeile, der Aufruf liefert trotzdem `OK`.\n- Werden `ItemKEy` und `ItemNRInt` gemeinsam übergeben, wird `ItemNRInt` ignoriert.\n- Die Kategorie wird über ihren Anzeigetext gesucht, nicht über den Key. Haben mehrere Kategorien denselben Text, wird eine beliebige verwendet.\n- Die Lesezugriffe verwenden `NOLOCK` (Dirty Reads möglich); das Update verwendet `ROWLOCK`. Es wird keine explizite Transaktion verwendet.\n- Die Statusspalte heißt auch im Erfolgsfall (`OK`) `Error`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemCategory"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n \n"
}
]
},
{
"name": "pixiSetItemEan",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n 4012345678901\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt einen neuen EAN/UPC-Code für genau einen Artikel, der über Artikelschlüssel, interne Artikelnummer, Lieferantenartikelnummer oder aktuelle EAN ermittelt wird.\n\nErsetzt den EAN/UPC-Code eines einzelnen Artikels.\n\n1. Mindestens ein Identifikator muss übergeben werden: `ItemKey`, `ItemNrInt`, `OldEan` oder `ItemNrSuppl`. Andernfalls lautet das Ergebnis `401 No item ID provided`.\n2. Die Prozedur zählt die Artikel, auf die **irgendeiner** der übergebenen Identifikatoren passt. Die Identifikatoren werden mit `OR` verknüpft, nicht mit `AND`.\n - Kein Treffer: `402 Item not found`.\n - Mehr als ein Treffer: `403 More than one item is found`. Das gilt auch, wenn mehrere Identifikatoren übergeben werden, die auf unterschiedliche Artikel zeigen.\n3. Bei genau einem Treffer wird die Einstellung `BMECatImport_Update_EANUPC` geprüft. Ist sie `0` oder nicht vorhanden, wird nichts geändert und das Ergebnis lautet `405 ...`.\n4. Andernfalls wird in einer Transaktion `EANUPC` auf `NewEan` gesetzt:\n - in `Items` für den Artikel,\n - in `AddItems` für alle Datensätze, deren `ItemRef` auf den Artikel verweist.\n\n Bei Erfolg lautet das Ergebnis `200 Item updated`. Bei einem SQL-Fehler wird die Transaktion zurückgerollt und das Ergebnis lautet `404 Unexpected error: ...`.\n\nDer Ergebnistext wird immer in den Ausgabeparameter `ResultMessage` geschrieben. Zusätzlich wird er als einzeilige Ergebnismenge zurückgegeben, sofern `SupressDataset` nicht 1 ist.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels (`Items.ItemKey`). Optionaler Identifikator. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer (`Items.ItemNrInt`). Optionaler Identifikator. |\n| `OldEan` | varchar(13) | Nein | Aktuelle EAN/UPC des Artikels (`Items.EANUPC`). Optionaler Identifikator. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferantenartikelnummer (`Items.ItemNrSuppl`). Optionaler Identifikator. |\n| `NewEan` | varchar(13) | Ja | Neuer EAN/UPC-Code, der in `Items` und `AddItems` gespeichert wird. |\n| `SupressDataset` | bit | Nein | Steuert, ob das Ergebnis zusätzlich als Ergebnismenge zurückgegeben wird. `NULL` wird als 0 behandelt. |\n| `ResultMessage` | varchar(256) | Nein | Ausgabe: Statuscode gefolgt von einem Meldungstext, z. B. `200 Item updated`. |\n\n- Fehler werden nicht ausgelöst. Sie werden als Text zurückgegeben, dessen erste drei Zeichen ein Statuscode sind (`200`, `401`–`405`). Aufrufer sollten dieses Präfix auswerten.\n- Die Einstellung `BMECatImport_Update_EANUPC` wird über `fpixi_GetSetting` gelesen. Eine fehlende Einstellung gilt als `0`; die Einstellung muss also mit einem Wert ungleich `0` vorhanden sein.\n- `NewEan` wird nicht geprüft:\n - keine Prüfziffer- oder Formatprüfung,\n - keine Eindeutigkeitsprüfung gegenüber anderen Artikeln,\n - `NULL` wird nicht abgewiesen und würde die EAN leeren.\n- Da `ItemKey` mit `''` verglichen wird, gilt ein `ItemKey` von `0` als \"nicht übergeben\".\n- Die Artikelsuche erfolgt mit `NOLOCK`.\n- Der Text einer `404`-Meldung wird auf 256 Zeichen gekürzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemEan"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n 4012345678901\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt einen neuen EAN/UPC-Code für genau einen Artikel, der über Artikelschlüssel, interne Artikelnummer, Lieferantenartikelnummer oder aktuelle EAN ermittelt wird.\n\nErsetzt den EAN/UPC-Code eines einzelnen Artikels.\n\n1. Mindestens ein Identifikator muss übergeben werden: `ItemKey`, `ItemNrInt`, `OldEan` oder `ItemNrSuppl`. Andernfalls lautet das Ergebnis `401 No item ID provided`.\n2. Die Prozedur zählt die Artikel, auf die **irgendeiner** der übergebenen Identifikatoren passt. Die Identifikatoren werden mit `OR` verknüpft, nicht mit `AND`.\n - Kein Treffer: `402 Item not found`.\n - Mehr als ein Treffer: `403 More than one item is found`. Das gilt auch, wenn mehrere Identifikatoren übergeben werden, die auf unterschiedliche Artikel zeigen.\n3. Bei genau einem Treffer wird die Einstellung `BMECatImport_Update_EANUPC` geprüft. Ist sie `0` oder nicht vorhanden, wird nichts geändert und das Ergebnis lautet `405 ...`.\n4. Andernfalls wird in einer Transaktion `EANUPC` auf `NewEan` gesetzt:\n - in `Items` für den Artikel,\n - in `AddItems` für alle Datensätze, deren `ItemRef` auf den Artikel verweist.\n\n Bei Erfolg lautet das Ergebnis `200 Item updated`. Bei einem SQL-Fehler wird die Transaktion zurückgerollt und das Ergebnis lautet `404 Unexpected error: ...`.\n\nDer Ergebnistext wird immer in den Ausgabeparameter `ResultMessage` geschrieben. Zusätzlich wird er als einzeilige Ergebnismenge zurückgegeben, sofern `SupressDataset` nicht 1 ist.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels (`Items.ItemKey`). Optionaler Identifikator. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer (`Items.ItemNrInt`). Optionaler Identifikator. |\n| `OldEan` | varchar(13) | Nein | Aktuelle EAN/UPC des Artikels (`Items.EANUPC`). Optionaler Identifikator. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferantenartikelnummer (`Items.ItemNrSuppl`). Optionaler Identifikator. |\n| `NewEan` | varchar(13) | Ja | Neuer EAN/UPC-Code, der in `Items` und `AddItems` gespeichert wird. |\n| `SupressDataset` | bit | Nein | Steuert, ob das Ergebnis zusätzlich als Ergebnismenge zurückgegeben wird. `NULL` wird als 0 behandelt. |\n| `ResultMessage` | varchar(256) | Nein | Ausgabe: Statuscode gefolgt von einem Meldungstext, z. B. `200 Item updated`. |\n\n- Fehler werden nicht ausgelöst. Sie werden als Text zurückgegeben, dessen erste drei Zeichen ein Statuscode sind (`200`, `401`–`405`). Aufrufer sollten dieses Präfix auswerten.\n- Die Einstellung `BMECatImport_Update_EANUPC` wird über `fpixi_GetSetting` gelesen. Eine fehlende Einstellung gilt als `0`; die Einstellung muss also mit einem Wert ungleich `0` vorhanden sein.\n- `NewEan` wird nicht geprüft:\n - keine Prüfziffer- oder Formatprüfung,\n - keine Eindeutigkeitsprüfung gegenüber anderen Artikeln,\n - `NULL` wird nicht abgewiesen und würde die EAN leeren.\n- Da `ItemKey` mit `''` verglichen wird, gilt ein `ItemKey` von `0` als \"nicht übergeben\".\n- Die Artikelsuche erfolgt mit `NOLOCK`.\n- Der Text einer `404`-Meldung wird auf 256 Zeichen gekürzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemEan"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 200 Item updated\n \n"
}
]
},
{
"name": "pixiSetItemInfo",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Stammdaten eines oder mehrerer Artikel (Name, Beschreibung, Kategorie, Preis, MwSt-Stufe, Maße, Zolldaten, Hersteller, interne Artikelnummer).\n\nÄndert Artikelstammdaten in `items` und die interne Artikelnummer in `ItemCode`. Zwei Eingabewege sind möglich, einzeln oder kombiniert:\n\n- `ItemKey` + `ItemDescription`: setzt die Beschreibung eines einzelnen Artikels. Eine fehlende oder leere `ItemDescription` entfernt die Beschreibung.\n- `ItemInfoXML`: beliebig viele `Item`-Elemente unterhalb von `/ItemInfo` (elementbasiert). Jeder Eintrag bestimmt den Artikel über `ItemKey`; fehlt `ItemKey` oder ist er `0`, wird der Artikel über `ItemNrInt` (Artikelcode vom Typ 2) gesucht.\n\n**Ablauf**\n\n1. Leere Elemente gelten als nicht angegeben.\n2. Einträge, deren `Enabled` keine Ganzzahl oder deren `PriceVK` nicht numerisch ist, werden verworfen und mit einer Statuszeile gemeldet.\n3. Feldzuordnung (nicht angegebene Felder behalten ihren aktuellen Wert, außer `ItemDescription`):\n - `ItemName` → `ItemName`, `PicLinkSmall`/`PicLinkLarge`, `CustomsTariffNumber`, `CustomsCountryOfOrigin`, `CustomsTariffText` → gleichnamige Spalten, `Manufacturer` → `Artist`.\n - `ItemDescription` → `ItemDescription`, wird immer geschrieben; `NULL`, wenn der Eintrag keine enthält.\n - `Enabled` → Bit (`0` = deaktiviert, jede andere Zahl = aktiviert).\n - `PriceVK` → `Price` (money, Dezimalpunkt).\n - `VATLevel`: `HIGH`, `LOW`, `ZERO` → `MwStSatz` 1, 2, 3; andere Werte werden ignoriert.\n - `Weight` → Ganzzahl `decimal(10,0)`; `Heigth`, `Width`, `Length` → Ganzzahlen `decimal(4,0)`; nicht konvertierbare Werte werden ignoriert.\n - `Category`: wird über den Text in `TontrArten` gesucht. Unbekannte Kategorien werden mit dem nächsten freien Hexadezimal-Code angelegt. Der Artikel erhält `CategoryId` und `ConfigType` dieser Kategorie.\n - `InternalItemNumber`: Artikelcode vom Typ 3 in `ItemCode`; wird angelegt, wenn der Artikel keinen hat, sonst bei Abweichung geändert.\n4. Ein Artikel wird nur aktualisiert, wenn er in `items` existiert und der Eintrag mindestens ein Feld außer `ItemDescription`/`InternalItemNumber` enthält oder es sich um den Artikel aus dem Parameter `ItemKey` handelt.\n5. Kommt derselbe Artikel in mehreren Einträgen mit unterschiedlichen Daten vor, wird er gar nicht aktualisiert.\n6. Aktualisierte Artikel erhalten `UpdateDate` = aktuelle Zeit und `UpdateEmp` = `API user SetItemInfo`.\n\n**Ergebnis**\n\nWenn mindestens ein Artikel für die Aktualisierung in Frage kam und kein SQL-Fehler auftrat, wird pro Eintrag eine Zeile mit `Status` = `Updated` oder dem Grund für das Überspringen geliefert. Andernfalls wird eine einzelne Zeile mit `Status` (`404` oder `500`) und `ErrorMsg` geliefert. Die Zeilen sind nicht sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Schlüssel eines einzelnen Artikels, dessen Beschreibung aus `ItemDescription` gesetzt wird. `0` gilt als nicht angegeben. Dieser Artikel wird auch ohne weitere Felder aktualisiert. |\n| `ItemDescription` | varchar(4000) | Nein | Neue Beschreibung für den Artikel aus `ItemKey`. Wird nur zusammen mit `ItemKey` verwendet. Leer oder fehlend entfernt die Beschreibung. |\n| `ItemInfoXML` | varchar(max) | Nein | XML-Dokument mit einem `Item`-Element pro Artikel unterhalb von `/ItemInfo`. Kindelemente: `ItemKey`, `ItemNrInt`, `ItemName`, `ItemDescription`, `InternalItemNumber`, `Category`, `Enabled`, `PriceVK`, `PicLinkSmall`, `PicLinkLarge`, `VATLevel`, `Weight`, `Heigth`, `Width`, `Length`, `CustomsTariffNumber`, `CustomsCountryOfOrigin`, `CustomsTariffText`, `Manufacturer`. Leere Elemente werden ignoriert. |\n\n- **Beschreibung wird überschrieben:** Jeder aktualisierte Artikel erhält `ItemDescription` aus seinem Eintrag. Ein XML-Eintrag ohne `ItemDescription` löscht daher die vorhandene Beschreibung. Soll sie erhalten bleiben, muss sie immer mitgesendet werden.\n- Wird derselbe Artikel über den Parameter `ItemKey` und im XML übergeben, entstehen in der Regel zwei unterschiedliche Einträge; der Artikel wird dann ohne Änderung als `Duplicated entries found in input parameters` gemeldet.\n- Ein Eintrag, der nur `InternalItemNumber` (und/oder `ItemDescription`) enthält, wird nicht verarbeitet und als `No item/s found or have no data for update` gemeldet, außer es handelt sich um den Artikel aus dem Parameter `ItemKey`.\n- Neue Kategorien in `TontrArten` werden vor und unabhängig von der Artikelaktualisierung angelegt, auch wenn der Artikel nicht existiert, der Eintrag doppelt ist oder die Aktualisierung später fehlschlägt.\n- Es gibt keine explizite Transaktion: Die Änderungen an `ItemCode` und das Update von `items` sind getrennte Anweisungen in einem `TRY`-Block. Schlägt eine spätere Anweisung fehl, bleiben frühere Änderungen bestehen und der Aufruf liefert `500` statt der Zeilen pro Artikel.\n- Während des Updates von `items` wird `CONTEXT_INFO` auf `0x11199` gesetzt, um die Artikel-Trigger zu unterdrücken; danach wird der vorherige Wert wiederhergestellt.\n- Das Element für die Höhe heißt im XML `Heigth`.\n- `Weight` und die Maße werden auf Ganzzahlen gerundet; Maße über 9999 werden ignoriert.\n- Fehlerhaftes XML oder ein Konvertierungsproblem vor dem `TRY`-Block führt zu einem SQL-Fehler (`SqlMessage`) statt einer Statuszeile. Der Code prüft nicht explizit, ob `ItemInfoXML` leer ist.\n- Kommt kein Eintrag für ein Update in Frage, wird nur `404` geliefert, auch wenn Einträge wegen nicht numerischem `Enabled`/`PriceVK` verworfen wurden.\n- Lesezugriffe auf `items`, `ItemCode`, `TontrArten` und `Numbers` erfolgen mit `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemInfo"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Stammdaten eines oder mehrerer Artikel (Name, Beschreibung, Kategorie, Preis, MwSt-Stufe, Maße, Zolldaten, Hersteller, interne Artikelnummer).\n\nÄndert Artikelstammdaten in `items` und die interne Artikelnummer in `ItemCode`. Zwei Eingabewege sind möglich, einzeln oder kombiniert:\n\n- `ItemKey` + `ItemDescription`: setzt die Beschreibung eines einzelnen Artikels. Eine fehlende oder leere `ItemDescription` entfernt die Beschreibung.\n- `ItemInfoXML`: beliebig viele `Item`-Elemente unterhalb von `/ItemInfo` (elementbasiert). Jeder Eintrag bestimmt den Artikel über `ItemKey`; fehlt `ItemKey` oder ist er `0`, wird der Artikel über `ItemNrInt` (Artikelcode vom Typ 2) gesucht.\n\n**Ablauf**\n\n1. Leere Elemente gelten als nicht angegeben.\n2. Einträge, deren `Enabled` keine Ganzzahl oder deren `PriceVK` nicht numerisch ist, werden verworfen und mit einer Statuszeile gemeldet.\n3. Feldzuordnung (nicht angegebene Felder behalten ihren aktuellen Wert, außer `ItemDescription`):\n - `ItemName` → `ItemName`, `PicLinkSmall`/`PicLinkLarge`, `CustomsTariffNumber`, `CustomsCountryOfOrigin`, `CustomsTariffText` → gleichnamige Spalten, `Manufacturer` → `Artist`.\n - `ItemDescription` → `ItemDescription`, wird immer geschrieben; `NULL`, wenn der Eintrag keine enthält.\n - `Enabled` → Bit (`0` = deaktiviert, jede andere Zahl = aktiviert).\n - `PriceVK` → `Price` (money, Dezimalpunkt).\n - `VATLevel`: `HIGH`, `LOW`, `ZERO` → `MwStSatz` 1, 2, 3; andere Werte werden ignoriert.\n - `Weight` → Ganzzahl `decimal(10,0)`; `Heigth`, `Width`, `Length` → Ganzzahlen `decimal(4,0)`; nicht konvertierbare Werte werden ignoriert.\n - `Category`: wird über den Text in `TontrArten` gesucht. Unbekannte Kategorien werden mit dem nächsten freien Hexadezimal-Code angelegt. Der Artikel erhält `CategoryId` und `ConfigType` dieser Kategorie.\n - `InternalItemNumber`: Artikelcode vom Typ 3 in `ItemCode`; wird angelegt, wenn der Artikel keinen hat, sonst bei Abweichung geändert.\n4. Ein Artikel wird nur aktualisiert, wenn er in `items` existiert und der Eintrag mindestens ein Feld außer `ItemDescription`/`InternalItemNumber` enthält oder es sich um den Artikel aus dem Parameter `ItemKey` handelt.\n5. Kommt derselbe Artikel in mehreren Einträgen mit unterschiedlichen Daten vor, wird er gar nicht aktualisiert.\n6. Aktualisierte Artikel erhalten `UpdateDate` = aktuelle Zeit und `UpdateEmp` = `API user SetItemInfo`.\n\n**Ergebnis**\n\nWenn mindestens ein Artikel für die Aktualisierung in Frage kam und kein SQL-Fehler auftrat, wird pro Eintrag eine Zeile mit `Status` = `Updated` oder dem Grund für das Überspringen geliefert. Andernfalls wird eine einzelne Zeile mit `Status` (`404` oder `500`) und `ErrorMsg` geliefert. Die Zeilen sind nicht sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Schlüssel eines einzelnen Artikels, dessen Beschreibung aus `ItemDescription` gesetzt wird. `0` gilt als nicht angegeben. Dieser Artikel wird auch ohne weitere Felder aktualisiert. |\n| `ItemDescription` | varchar(4000) | Nein | Neue Beschreibung für den Artikel aus `ItemKey`. Wird nur zusammen mit `ItemKey` verwendet. Leer oder fehlend entfernt die Beschreibung. |\n| `ItemInfoXML` | varchar(max) | Nein | XML-Dokument mit einem `Item`-Element pro Artikel unterhalb von `/ItemInfo`. Kindelemente: `ItemKey`, `ItemNrInt`, `ItemName`, `ItemDescription`, `InternalItemNumber`, `Category`, `Enabled`, `PriceVK`, `PicLinkSmall`, `PicLinkLarge`, `VATLevel`, `Weight`, `Heigth`, `Width`, `Length`, `CustomsTariffNumber`, `CustomsCountryOfOrigin`, `CustomsTariffText`, `Manufacturer`. Leere Elemente werden ignoriert. |\n\n- **Beschreibung wird überschrieben:** Jeder aktualisierte Artikel erhält `ItemDescription` aus seinem Eintrag. Ein XML-Eintrag ohne `ItemDescription` löscht daher die vorhandene Beschreibung. Soll sie erhalten bleiben, muss sie immer mitgesendet werden.\n- Wird derselbe Artikel über den Parameter `ItemKey` und im XML übergeben, entstehen in der Regel zwei unterschiedliche Einträge; der Artikel wird dann ohne Änderung als `Duplicated entries found in input parameters` gemeldet.\n- Ein Eintrag, der nur `InternalItemNumber` (und/oder `ItemDescription`) enthält, wird nicht verarbeitet und als `No item/s found or have no data for update` gemeldet, außer es handelt sich um den Artikel aus dem Parameter `ItemKey`.\n- Neue Kategorien in `TontrArten` werden vor und unabhängig von der Artikelaktualisierung angelegt, auch wenn der Artikel nicht existiert, der Eintrag doppelt ist oder die Aktualisierung später fehlschlägt.\n- Es gibt keine explizite Transaktion: Die Änderungen an `ItemCode` und das Update von `items` sind getrennte Anweisungen in einem `TRY`-Block. Schlägt eine spätere Anweisung fehl, bleiben frühere Änderungen bestehen und der Aufruf liefert `500` statt der Zeilen pro Artikel.\n- Während des Updates von `items` wird `CONTEXT_INFO` auf `0x11199` gesetzt, um die Artikel-Trigger zu unterdrücken; danach wird der vorherige Wert wiederhergestellt.\n- Das Element für die Höhe heißt im XML `Heigth`.\n- `Weight` und die Maße werden auf Ganzzahlen gerundet; Maße über 9999 werden ignoriert.\n- Fehlerhaftes XML oder ein Konvertierungsproblem vor dem `TRY`-Block führt zu einem SQL-Fehler (`SqlMessage`) statt einer Statuszeile. Der Code prüft nicht explizit, ob `ItemInfoXML` leer ist.\n- Kommt kein Eintrag für ein Update in Frage, wird nur `404` geliefert, auch wenn Einträge wegen nicht numerischem `Enabled`/`PriceVK` verworfen wurden.\n- Lesezugriffe auf `items`, `ItemCode`, `TontrArten` und `Numbers` erfolgen mit `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemInfo"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 12345\n Updated\n \n \n No item/s found or have no data for update\n ART-9999\n \n"
}
]
},
{
"name": "pixiSetItemStatus",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktiviert oder deaktiviert einen Artikel oder dessen Lieferantenzuordnung und stellt den Artikel für den Shop-Export in die Warteschlange.\n\nSetzt den Status eines Artikels.\n\n1. **Artikel ermitteln.** Der Artikel wird in `Items` über `ItemKey` (nur wenn `ItemKey` übergeben wird) **oder** über `ItemNrInt` gesucht. Wird kein Artikel gefunden, wird Status `404` geliefert. Werden mehrere Artikel gefunden, wird Status `409` geliefert. Das kann auch passieren, wenn `ItemKey` und `ItemNrInt` gemeinsam übergeben werden und auf verschiedene Artikel verweisen.\n2. **Status setzen.**\n - Ohne `SupplierID` (oder mit Leerstring): Das Flag `Enabled` des Artikels in `Items` wird auf den Wert von `Enabled` gesetzt.\n - Mit `SupplierID`: Der Lieferantendatensatz des Artikels in `AddItems` (über den Artikel und `SupplNr` = `SupplierID`) wird gesucht. Bei keinem oder mehreren Treffern wird Status `404` bzw. `409` geliefert. Bei genau einem Treffer wird dessen Flag `Active` auf `Enabled` gesetzt. Das Flag `Enabled` des Artikels selbst bleibt in diesem Fall **unverändert**.\n - Schlägt das Update fehl, wird Status `500` mit der SQL-Fehlermeldung geliefert.\n3. **Bei Erfolg** wird der Artikel zur Neuberechnung und zum erzwungenen Export in den Shop in die Warteschlange gestellt. Danach wird der Artikel geliefert, mit `ItemKey`, `ItemNrInt`, `Enabled`, der übergebenen `SupplNr` und, falls ein Lieferant übergeben wurde, dem Flag `Active` des Lieferantendatensatzes.\n\nIm Fehlerfall wird stattdessen eine einzelne Zeile mit `Status` und `ErrorMsg` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer. Dient zur Suche des Artikels, wenn `ItemKey` nicht übergeben wird (oder zusätzlich dazu). |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. Alternative zu `ItemNrInt`. |\n| `Enabled` | bit | Nein | Neuer Status. Er wird in `Items.Enabled` geschrieben, bzw. in `AddItems.Active`, wenn `SupplierID` übergeben wird. |\n| `SupplierID` | varchar(4) | Nein | Lieferantennummer (`SupplNr`). Wenn gesetzt, wird nur der Lieferantendatensatz des Artikels in `AddItems` aktiviert bzw. deaktiviert. Ein Leerstring wird als NULL behandelt. |\n\n- **Leere Fehlermeldung:** Wird `ItemKey` nicht übergeben und der Artikel nicht gefunden, ergibt die `404`-Meldung NULL. Grund ist, dass die Meldung `ItemKey` ohne NULL-Behandlung verkettet, sodass `ErrorMsg` leer sein kann. Maßgeblich ist `Status`.\n- **Leeres Ergebnis trotz Erfolg:** Das Erfolgsergebnis verknüpft `Items` mit `AddItems`. Ein Artikel ohne Lieferantendatensatz (`AddItems`) liefert daher keine Zeile, obwohl das Update erfolgreich war.\n- **Nebeneffekt bei Erfolg:** `Pixi_ExportItemChangesToShop` fügt den Artikel mit `ForceToExport = 1` in `pixi.ItemRecalculateStockQueue` ein. Im Fehlerfall wird kein Export eingereiht.\n- **Transaktionen und Sperren:** Es wird keine explizite Transaktion verwendet. Lesezugriffe nutzen `NOLOCK`, Updates `ROWLOCK`.\n- **Temporäre Tabellen:** Sie werden über `util.TempTableDrop` gelöscht, dessen Definition nicht beiliegt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemStatus"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktiviert oder deaktiviert einen Artikel oder dessen Lieferantenzuordnung und stellt den Artikel für den Shop-Export in die Warteschlange.\n\nSetzt den Status eines Artikels.\n\n1. **Artikel ermitteln.** Der Artikel wird in `Items` über `ItemKey` (nur wenn `ItemKey` übergeben wird) **oder** über `ItemNrInt` gesucht. Wird kein Artikel gefunden, wird Status `404` geliefert. Werden mehrere Artikel gefunden, wird Status `409` geliefert. Das kann auch passieren, wenn `ItemKey` und `ItemNrInt` gemeinsam übergeben werden und auf verschiedene Artikel verweisen.\n2. **Status setzen.**\n - Ohne `SupplierID` (oder mit Leerstring): Das Flag `Enabled` des Artikels in `Items` wird auf den Wert von `Enabled` gesetzt.\n - Mit `SupplierID`: Der Lieferantendatensatz des Artikels in `AddItems` (über den Artikel und `SupplNr` = `SupplierID`) wird gesucht. Bei keinem oder mehreren Treffern wird Status `404` bzw. `409` geliefert. Bei genau einem Treffer wird dessen Flag `Active` auf `Enabled` gesetzt. Das Flag `Enabled` des Artikels selbst bleibt in diesem Fall **unverändert**.\n - Schlägt das Update fehl, wird Status `500` mit der SQL-Fehlermeldung geliefert.\n3. **Bei Erfolg** wird der Artikel zur Neuberechnung und zum erzwungenen Export in den Shop in die Warteschlange gestellt. Danach wird der Artikel geliefert, mit `ItemKey`, `ItemNrInt`, `Enabled`, der übergebenen `SupplNr` und, falls ein Lieferant übergeben wurde, dem Flag `Active` des Lieferantendatensatzes.\n\nIm Fehlerfall wird stattdessen eine einzelne Zeile mit `Status` und `ErrorMsg` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer. Dient zur Suche des Artikels, wenn `ItemKey` nicht übergeben wird (oder zusätzlich dazu). |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. Alternative zu `ItemNrInt`. |\n| `Enabled` | bit | Nein | Neuer Status. Er wird in `Items.Enabled` geschrieben, bzw. in `AddItems.Active`, wenn `SupplierID` übergeben wird. |\n| `SupplierID` | varchar(4) | Nein | Lieferantennummer (`SupplNr`). Wenn gesetzt, wird nur der Lieferantendatensatz des Artikels in `AddItems` aktiviert bzw. deaktiviert. Ein Leerstring wird als NULL behandelt. |\n\n- **Leere Fehlermeldung:** Wird `ItemKey` nicht übergeben und der Artikel nicht gefunden, ergibt die `404`-Meldung NULL. Grund ist, dass die Meldung `ItemKey` ohne NULL-Behandlung verkettet, sodass `ErrorMsg` leer sein kann. Maßgeblich ist `Status`.\n- **Leeres Ergebnis trotz Erfolg:** Das Erfolgsergebnis verknüpft `Items` mit `AddItems`. Ein Artikel ohne Lieferantendatensatz (`AddItems`) liefert daher keine Zeile, obwohl das Update erfolgreich war.\n- **Nebeneffekt bei Erfolg:** `Pixi_ExportItemChangesToShop` fügt den Artikel mit `ForceToExport = 1` in `pixi.ItemRecalculateStockQueue` ein. Im Fehlerfall wird kein Export eingereiht.\n- **Transaktionen und Sperren:** Es wird keine explizite Transaktion verwendet. Lesezugriffe nutzen `NOLOCK`, Updates `ROWLOCK`.\n- **Temporäre Tabellen:** Sie werden über `util.TempTableDrop` gelöscht, dessen Definition nicht beiliegt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemStatus"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4711\n A-10045\n 1\n LIE1\n 0\n \n"
}
]
},
{
"name": "pixiSetItemSupplier",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n L001\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt die Lieferantenzuordnung (AddItems-Zeile) eines Artikels an oder aktualisiert sie, inklusive Lieferantenpreis, Lieferanten-Artikelnummer, EAN und Bestelleinstellungen.\n\nPflegt die Lieferantendaten eines Artikels in `AddItems` für den in `SupplNr` angegebenen Lieferanten.\n\n**Prüfungen**\n1. `ItemKey = 0` sowie leere Zeichenketten in `EAN`, `ItemNrSuppl` und `ItemNrInt` werden als NULL behandelt.\n2. Werden `ItemKey` und `ItemNrInt` gemeinsam übergeben, müssen beide in `items` zum selben Artikel gehören.\n3. Der Lieferant `SupplNr` muss in `Suppliers` existieren.\n4. Mindestens einer der Parameter `ItemKey`, `EAN`, `ItemNrSuppl` oder `ItemNrInt` muss angegeben sein.\n\n**Ermittlung des Artikels**\nDer Artikel wird in den vorhandenen `AddItems`-Zeilen gesucht (verknüpft mit `items`). Eine Zeile passt, wenn eine dieser Bedingungen zutrifft:\n- `ItemRef = ItemKey`\n- `EANUPC = EAN`\n- `ItemNrInt = ItemNrInt`\n- `ItemNrSuppl = ItemNrSuppl` **und** `SupplNr = SupplNr`\n\nEs muss genau ein Artikel gefunden werden, sonst wird eine Fehlerzeile geliefert.\n- Bei `AddEAN = 0` ist es ein Fehler, wenn für den Lieferanten mehr als eine passende `AddItems`-Zeile existiert.\n- Bei `AddEAN = 1` wird eine Warnung geliefert, wenn bereits eine Zeile mit derselben `EAN` und demselben Lieferanten existiert.\n\n**Schreiben**\n- Bei `PreferredSupplier = 1` wird zuerst `PreferredSupplier` auf allen `AddItems`-Zeilen des Artikels auf 0 gesetzt, damit nur eine Zeile bevorzugt bleibt.\n- Bei `AddEAN = 0` und vorhandener passender `AddItems`-Zeile des Lieferanten wird die älteste Zeile (kleinstes `UpdateDate`) aktualisiert. Nicht übergebene Parameter behalten die bisherigen Werte. Für Preis, Lieferanten-Artikelnummer und EAN dienen die Werte des Artikelstamms als Rückfall. Rückgabe: `Record updated`.\n- Andernfalls (noch keine Zeile für diesen Lieferanten oder `AddEAN = 1`) wird eine neue `AddItems`-Zeile angelegt. Die Werte stammen aus den Parametern, mit Rückfall auf den Artikelstamm (`EANUPC`, `ItemNrSuppl`, `SupplPrice`). `ItemNrInt`, `IntLinkNR1`, `IntLinkNR` und `Price` werden vom Artikel übernommen, `AutoPrice` wird auf 0 gesetzt. Rückgabe: `New record inserted`.\n\nDer Aufruf liefert immer genau eine Statuszeile mit `Status` und `Message`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels (`items.ItemKey`). 0 wird als NULL behandelt. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer. Wird zusätzlich `ItemKey` übergeben, müssen beide zum selben Artikel gehören. Leere Zeichenkette wird als NULL behandelt. |\n| `SupplNr` | varchar(4) | Ja | Lieferantennummer. Sie muss in `Suppliers` existieren und bestimmt, welche `AddItems`-Zeile aktualisiert oder angelegt wird. |\n| `SupplPrice` | money | Nein | Einkaufspreis beim Lieferanten. Ohne Angabe bleibt der bisherige Wert erhalten; bei neuer Zeile wird der Wert aus dem Artikelstamm verwendet. |\n| `EAN` | varchar(13) | Nein | EAN/UPC. Dient zur Suche des Artikels und wird in `AddItems.EANUPC` gespeichert. Leere Zeichenkette wird als NULL behandelt. |\n| `ItemNrSuppl` | varchar(50) | Nein | Artikelnummer des Lieferanten. Dient nur zusammen mit `SupplNr` zur Suche und wird in `AddItems.ItemNrSuppl` gespeichert. Leere Zeichenkette wird als NULL behandelt. |\n| `AddEAN` | bit | Nein | Bei 1 wird immer eine neue `AddItems`-Zeile angelegt (z. B. für eine zusätzliche EAN), statt eine vorhandene zu aktualisieren. |\n| `PreferredSupplier` | smallint | Nein | Kennzeichen für den bevorzugten Lieferanten. Bei 1 werden alle anderen `AddItems`-Zeilen des Artikels auf 0 gesetzt. Ohne Angabe bleibt der Wert beim Update erhalten; eine neue Zeile erhält 0. |\n| `MinOrderQty` | int | Nein | Mindestbestellmenge beim Lieferanten. Ohne Angabe bleibt der bisherige Wert erhalten; eine neue Zeile erhält NULL. |\n| `OnlyPU` | bit | Nein | Nur in Verpackungseinheiten bestellen (`OrderOnlyPackageUnits`). Ohne Angabe bleibt der bisherige Wert erhalten; eine neue Zeile erhält 0. |\n| `ItemDeliveryTime` | int | Nein | Lieferzeit des Lieferanten (`SupplDeliveryTime`). Ohne Angabe bleibt der bisherige Wert erhalten; eine neue Zeile erhält NULL. |\n\n- **Der Artikel muss bereits mindestens eine `AddItems`-Zeile besitzen.** Die Suche läuft nur über `AddItems`. Ein Artikel ohne Lieferantenzeile liefert daher `No items found with given parameters.`, auch wenn `ItemKey` gültig ist.\n- Bei `AddEAN = 1` mit einer neuen EAN lässt sich der Artikel nur über einen vorhandenen Wert finden. Daher `ItemKey` oder `ItemNrInt` übergeben, da die neue EAN in `AddItems` noch nicht existiert.\n- Die Suchbedingungen sind mit OR verknüpft. Werden mehrere Kennungen übergeben, die auf verschiedene Artikel zeigen, folgt `More then one item was identified ...`.\n- Beim Anlegen einer neuen Zeile werden `MinOrderQty` und `SupplDeliveryTime` nur aus den Parametern übernommen (NULL, wenn nicht angegeben). `OrderOnlyPackageUnits` und `PreferredSupplier` sind standardmäßig 0.\n- In der Erfolgsmeldung werden NULL-Werte nicht behandelt. Ist `ItemNrSuppl` oder `EANUPC` im Ergebnis NULL, ist `Message` NULL.\n- Die Schreibzugriffe laufen in einer Transaktion. Bei bereits offener Transaktion des Aufrufers wird stattdessen ein Savepoint gesetzt. Im Fehlerfall werden die Änderungen zurückgerollt, der Fehler wird über `log.InsertError` protokolliert (Definition nicht beigefügt) und eine `Error`-Zeile mit dem SQL-Fehlertext geliefert.\n- Lesezugriffe verwenden `NOLOCK`, Updates `ROWLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemSupplier"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n L001\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt die Lieferantenzuordnung (AddItems-Zeile) eines Artikels an oder aktualisiert sie, inklusive Lieferantenpreis, Lieferanten-Artikelnummer, EAN und Bestelleinstellungen.\n\nPflegt die Lieferantendaten eines Artikels in `AddItems` für den in `SupplNr` angegebenen Lieferanten.\n\n**Prüfungen**\n1. `ItemKey = 0` sowie leere Zeichenketten in `EAN`, `ItemNrSuppl` und `ItemNrInt` werden als NULL behandelt.\n2. Werden `ItemKey` und `ItemNrInt` gemeinsam übergeben, müssen beide in `items` zum selben Artikel gehören.\n3. Der Lieferant `SupplNr` muss in `Suppliers` existieren.\n4. Mindestens einer der Parameter `ItemKey`, `EAN`, `ItemNrSuppl` oder `ItemNrInt` muss angegeben sein.\n\n**Ermittlung des Artikels**\nDer Artikel wird in den vorhandenen `AddItems`-Zeilen gesucht (verknüpft mit `items`). Eine Zeile passt, wenn eine dieser Bedingungen zutrifft:\n- `ItemRef = ItemKey`\n- `EANUPC = EAN`\n- `ItemNrInt = ItemNrInt`\n- `ItemNrSuppl = ItemNrSuppl` **und** `SupplNr = SupplNr`\n\nEs muss genau ein Artikel gefunden werden, sonst wird eine Fehlerzeile geliefert.\n- Bei `AddEAN = 0` ist es ein Fehler, wenn für den Lieferanten mehr als eine passende `AddItems`-Zeile existiert.\n- Bei `AddEAN = 1` wird eine Warnung geliefert, wenn bereits eine Zeile mit derselben `EAN` und demselben Lieferanten existiert.\n\n**Schreiben**\n- Bei `PreferredSupplier = 1` wird zuerst `PreferredSupplier` auf allen `AddItems`-Zeilen des Artikels auf 0 gesetzt, damit nur eine Zeile bevorzugt bleibt.\n- Bei `AddEAN = 0` und vorhandener passender `AddItems`-Zeile des Lieferanten wird die älteste Zeile (kleinstes `UpdateDate`) aktualisiert. Nicht übergebene Parameter behalten die bisherigen Werte. Für Preis, Lieferanten-Artikelnummer und EAN dienen die Werte des Artikelstamms als Rückfall. Rückgabe: `Record updated`.\n- Andernfalls (noch keine Zeile für diesen Lieferanten oder `AddEAN = 1`) wird eine neue `AddItems`-Zeile angelegt. Die Werte stammen aus den Parametern, mit Rückfall auf den Artikelstamm (`EANUPC`, `ItemNrSuppl`, `SupplPrice`). `ItemNrInt`, `IntLinkNR1`, `IntLinkNR` und `Price` werden vom Artikel übernommen, `AutoPrice` wird auf 0 gesetzt. Rückgabe: `New record inserted`.\n\nDer Aufruf liefert immer genau eine Statuszeile mit `Status` und `Message`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels (`items.ItemKey`). 0 wird als NULL behandelt. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer. Wird zusätzlich `ItemKey` übergeben, müssen beide zum selben Artikel gehören. Leere Zeichenkette wird als NULL behandelt. |\n| `SupplNr` | varchar(4) | Ja | Lieferantennummer. Sie muss in `Suppliers` existieren und bestimmt, welche `AddItems`-Zeile aktualisiert oder angelegt wird. |\n| `SupplPrice` | money | Nein | Einkaufspreis beim Lieferanten. Ohne Angabe bleibt der bisherige Wert erhalten; bei neuer Zeile wird der Wert aus dem Artikelstamm verwendet. |\n| `EAN` | varchar(13) | Nein | EAN/UPC. Dient zur Suche des Artikels und wird in `AddItems.EANUPC` gespeichert. Leere Zeichenkette wird als NULL behandelt. |\n| `ItemNrSuppl` | varchar(50) | Nein | Artikelnummer des Lieferanten. Dient nur zusammen mit `SupplNr` zur Suche und wird in `AddItems.ItemNrSuppl` gespeichert. Leere Zeichenkette wird als NULL behandelt. |\n| `AddEAN` | bit | Nein | Bei 1 wird immer eine neue `AddItems`-Zeile angelegt (z. B. für eine zusätzliche EAN), statt eine vorhandene zu aktualisieren. |\n| `PreferredSupplier` | smallint | Nein | Kennzeichen für den bevorzugten Lieferanten. Bei 1 werden alle anderen `AddItems`-Zeilen des Artikels auf 0 gesetzt. Ohne Angabe bleibt der Wert beim Update erhalten; eine neue Zeile erhält 0. |\n| `MinOrderQty` | int | Nein | Mindestbestellmenge beim Lieferanten. Ohne Angabe bleibt der bisherige Wert erhalten; eine neue Zeile erhält NULL. |\n| `OnlyPU` | bit | Nein | Nur in Verpackungseinheiten bestellen (`OrderOnlyPackageUnits`). Ohne Angabe bleibt der bisherige Wert erhalten; eine neue Zeile erhält 0. |\n| `ItemDeliveryTime` | int | Nein | Lieferzeit des Lieferanten (`SupplDeliveryTime`). Ohne Angabe bleibt der bisherige Wert erhalten; eine neue Zeile erhält NULL. |\n\n- **Der Artikel muss bereits mindestens eine `AddItems`-Zeile besitzen.** Die Suche läuft nur über `AddItems`. Ein Artikel ohne Lieferantenzeile liefert daher `No items found with given parameters.`, auch wenn `ItemKey` gültig ist.\n- Bei `AddEAN = 1` mit einer neuen EAN lässt sich der Artikel nur über einen vorhandenen Wert finden. Daher `ItemKey` oder `ItemNrInt` übergeben, da die neue EAN in `AddItems` noch nicht existiert.\n- Die Suchbedingungen sind mit OR verknüpft. Werden mehrere Kennungen übergeben, die auf verschiedene Artikel zeigen, folgt `More then one item was identified ...`.\n- Beim Anlegen einer neuen Zeile werden `MinOrderQty` und `SupplDeliveryTime` nur aus den Parametern übernommen (NULL, wenn nicht angegeben). `OrderOnlyPackageUnits` und `PreferredSupplier` sind standardmäßig 0.\n- In der Erfolgsmeldung werden NULL-Werte nicht behandelt. Ist `ItemNrSuppl` oder `EANUPC` im Ergebnis NULL, ist `Message` NULL.\n- Die Schreibzugriffe laufen in einer Transaktion. Bei bereits offener Transaktion des Aufrufers wird stattdessen ein Savepoint gesetzt. Im Fehlerfall werden die Änderungen zurückgerollt, der Fehler wird über `log.InsertError` protokolliert (Definition nicht beigefügt) und eine `Error`-Zeile mit dem SQL-Fehlertext geliefert.\n- Lesezugriffe verwenden `NOLOCK`, Updates `ROWLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemSupplier"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Record updated\n SupplPrice:12.50 ItemNrSuppl:LF-4711 EANUPC:4006381333931\n \n"
}
]
},
{
"name": "pixiSetItemTags",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Gleicht die Tags mit Präfix der im XML übergebenen Artikel ab: legt fehlende Tags an, ergänzt neue Zuordnungen und entfernt nicht mehr aufgeführte Zuordnungen mit Präfix.\n\nSetzt die Tags eines oder mehrerer Artikel aus dem XML-Dokument in `TagsXML`. Der Aufruf arbeitet als **Ersetzen je Artikel** für alle Tags, deren Name mit `TagPrefix` beginnt.\n\nAblauf:\n\n1. Jedes Element `/ItemTags/Item/TagList/Tag` ergibt eine Zeile. Der Tag-Name wird als `TagPrefix` + `Name` gebildet (ein leerer `Name` ergibt keinen Namen). Leere Werte für `ItemNrInt`, `EANUPC` sowie `ItemKey` = 0 gelten als nicht angegeben.\n2. Der Artikel wird in drei Durchläufen gegen `Items` aufgelöst: zuerst über `ItemKey`, dann über `ItemNrInt`, dann über `EANUPC`. Ein späterer Treffer überschreibt einen früheren; zeigen mehrere Kennungen auf unterschiedliche Artikel, gewinnt der EAN-Treffer. Zeilen, deren Artikel nicht gefunden wird, werden ohne Meldung verworfen.\n3. Noch nicht vorhandene Tags (Typ 1, kein System-Tag) werden über den Namen in `Tag` angelegt. Kommt derselbe Name mit unterschiedlichen Beschreibungen vor, wird die alphabetisch größte Beschreibung verwendet; eine fehlende Beschreibung wird als Leerstring gespeichert. Beschreibungen bestehender Tags werden nicht geändert.\n4. Für jeden im XML enthaltenen Artikel werden alle bestehenden Zuordnungen in `TagMatch` zu Tags vom Typ 1, deren Name `TagPrefix%` entspricht und die für diesen Artikel nicht aufgeführt sind, gelöscht. Tags ohne Präfix bleiben unverändert. Ein Artikel, der nur mit leerem Tag-Namen übergeben wird, verliert dadurch alle Tags mit Präfix.\n5. Aufgeführte, noch nicht vorhandene Zuordnungen werden in `TagMatch` eingefügt.\n\nDas Ergebnis listet die neu eingefügten Zuordnungen mit `Action` = `ADDED`. Artikel, die mit leerem Tag-Namen übergeben wurden, erscheinen zusätzlich einmal mit `Action` = `DELETED` und leerem `TagKey`/`TagName`. Die einzelnen entfernten Zuordnungen werden **nicht** zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | Nein | XML-Dokument mit den Artikeln und ihrer Tag-Liste. Jedes `Item` identifiziert den Artikel über `ItemKey`, `ItemNrInt` und/oder `EANUPC` und enthält eine `TagList` mit `Tag`-Elementen (`Name`, `Description`). Ein leerer `Name` bewirkt, dass alle Tags mit Präfix des Artikels entfernt werden. |\n| `TagPrefix` | varchar(20) | Nein | Präfix, das jedem Tag-Namen aus dem XML vorangestellt wird. Nur Zuordnungen zu Tags, deren Name mit diesem Präfix beginnt, werden abgeglichen (entfernt, wenn nicht aufgeführt). Das Leerzeichen am Ende des Standardwerts beachten. |\n\n- Keine explizite Transaktion: Anlage von Tags, Löschungen und Einfügungen sind getrennte Anweisungen; ein Fehler dazwischen kann einen Teilzustand hinterlassen.\n- Lesezugriffe auf `Items` und `Tag` erfolgen mit `NOLOCK`.\n- `TagPrefix` wird in einem `LIKE`-Muster verwendet; `%` oder `_` im Präfix wirken als Platzhalter und können die Menge der zu entfernenden Tags erweitern. Ein leeres Präfix macht **alle** Tags vom Typ 1 der übergebenen Artikel zu Löschkandidaten. Ein Präfix `NULL` ergibt keine Tag-Namen, sodass weder hinzugefügt noch entfernt wird.\n- Das XML-Element `Name` wird als `varchar(50)`, `Description` als `varchar(500)`, `EANUPC` als `varchar(13)` gelesen; längere Werte werden abgeschnitten. Ob Präfix + Name in `Tag.Name` passt, hängt von der nicht sichtbaren Tabellendefinition ab.\n- Das Dokument-Handle aus `sp_xml_preparedocument` wird nie mit `sp_xml_removedocument` freigegeben; es bleibt bis zum Ende der Verbindung belegt.\n- Es werden keine Fehlerzeilen geliefert; unbekannte Artikel werden stillschweigend ignoriert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemTags"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Gleicht die Tags mit Präfix der im XML übergebenen Artikel ab: legt fehlende Tags an, ergänzt neue Zuordnungen und entfernt nicht mehr aufgeführte Zuordnungen mit Präfix.\n\nSetzt die Tags eines oder mehrerer Artikel aus dem XML-Dokument in `TagsXML`. Der Aufruf arbeitet als **Ersetzen je Artikel** für alle Tags, deren Name mit `TagPrefix` beginnt.\n\nAblauf:\n\n1. Jedes Element `/ItemTags/Item/TagList/Tag` ergibt eine Zeile. Der Tag-Name wird als `TagPrefix` + `Name` gebildet (ein leerer `Name` ergibt keinen Namen). Leere Werte für `ItemNrInt`, `EANUPC` sowie `ItemKey` = 0 gelten als nicht angegeben.\n2. Der Artikel wird in drei Durchläufen gegen `Items` aufgelöst: zuerst über `ItemKey`, dann über `ItemNrInt`, dann über `EANUPC`. Ein späterer Treffer überschreibt einen früheren; zeigen mehrere Kennungen auf unterschiedliche Artikel, gewinnt der EAN-Treffer. Zeilen, deren Artikel nicht gefunden wird, werden ohne Meldung verworfen.\n3. Noch nicht vorhandene Tags (Typ 1, kein System-Tag) werden über den Namen in `Tag` angelegt. Kommt derselbe Name mit unterschiedlichen Beschreibungen vor, wird die alphabetisch größte Beschreibung verwendet; eine fehlende Beschreibung wird als Leerstring gespeichert. Beschreibungen bestehender Tags werden nicht geändert.\n4. Für jeden im XML enthaltenen Artikel werden alle bestehenden Zuordnungen in `TagMatch` zu Tags vom Typ 1, deren Name `TagPrefix%` entspricht und die für diesen Artikel nicht aufgeführt sind, gelöscht. Tags ohne Präfix bleiben unverändert. Ein Artikel, der nur mit leerem Tag-Namen übergeben wird, verliert dadurch alle Tags mit Präfix.\n5. Aufgeführte, noch nicht vorhandene Zuordnungen werden in `TagMatch` eingefügt.\n\nDas Ergebnis listet die neu eingefügten Zuordnungen mit `Action` = `ADDED`. Artikel, die mit leerem Tag-Namen übergeben wurden, erscheinen zusätzlich einmal mit `Action` = `DELETED` und leerem `TagKey`/`TagName`. Die einzelnen entfernten Zuordnungen werden **nicht** zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | Nein | XML-Dokument mit den Artikeln und ihrer Tag-Liste. Jedes `Item` identifiziert den Artikel über `ItemKey`, `ItemNrInt` und/oder `EANUPC` und enthält eine `TagList` mit `Tag`-Elementen (`Name`, `Description`). Ein leerer `Name` bewirkt, dass alle Tags mit Präfix des Artikels entfernt werden. |\n| `TagPrefix` | varchar(20) | Nein | Präfix, das jedem Tag-Namen aus dem XML vorangestellt wird. Nur Zuordnungen zu Tags, deren Name mit diesem Präfix beginnt, werden abgeglichen (entfernt, wenn nicht aufgeführt). Das Leerzeichen am Ende des Standardwerts beachten. |\n\n- Keine explizite Transaktion: Anlage von Tags, Löschungen und Einfügungen sind getrennte Anweisungen; ein Fehler dazwischen kann einen Teilzustand hinterlassen.\n- Lesezugriffe auf `Items` und `Tag` erfolgen mit `NOLOCK`.\n- `TagPrefix` wird in einem `LIKE`-Muster verwendet; `%` oder `_` im Präfix wirken als Platzhalter und können die Menge der zu entfernenden Tags erweitern. Ein leeres Präfix macht **alle** Tags vom Typ 1 der übergebenen Artikel zu Löschkandidaten. Ein Präfix `NULL` ergibt keine Tag-Namen, sodass weder hinzugefügt noch entfernt wird.\n- Das XML-Element `Name` wird als `varchar(50)`, `Description` als `varchar(500)`, `EANUPC` als `varchar(13)` gelesen; längere Werte werden abgeschnitten. Ob Präfix + Name in `Tag.Name` passt, hängt von der nicht sichtbaren Tabellendefinition ab.\n- Das Dokument-Handle aus `sp_xml_preparedocument` wird nie mit `sp_xml_removedocument` freigegeben; es bleibt bis zum Ende der Verbindung belegt.\n- Es werden keine Fehlerzeilen geliefert; unbekannte Artikel werden stillschweigend ignoriert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetItemTags"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 17\n API Sale\n 1234\n ADDED\n \n \n 18\n API New\n 1234\n ADDED\n \n"
}
]
},
{
"name": "pixiTagMatchAddForItems",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ordnet Artikeln per XML ein oder mehrere Artikel-Tags zu und liefert je angeforderter Tag-/Artikel-Zuordnung eine Statuszeile.\n\nLegt Einträge in `TagMatch` an, die Tags vom Typ 1 (Artikel-Tags) mit Artikeln verknüpfen.\n\n**Verarbeitung der Eingabe**\n\n- `TagsXML` wird mit `OPENXML` über den Pfad `/Tags/Item/TagList/Tag` (elementzentriert) gelesen. Jedes `Tag`-Element ist eine angeforderte Zuordnung.\n- `TagId` wird aus dem `Tag`-Element gelesen, `ItemId` und `ItemNrInt` aus dem übergeordneten `Item`-Element. Die Werte `0` und Leerstring gelten als nicht angegeben.\n- Der Artikel wird so ermittelt: Ist `ItemId` angegeben, wird dieser Wert verwendet. Andernfalls wird `ItemNrInt` in `pixi.ItemCode` (`Code` mit `CodeTypeId = 2`) gesucht, um den Artikelschlüssel zu bestimmen.\n\n**Prüfung, in dieser Reihenfolge**\n\n1. Anforderungen, deren Artikelschlüssel nicht in `items` existiert oder deren Tag nicht in `Tag` mit `TypeId = 1` existiert, erhalten einen Status:\n - `TagId` fehlt, oder `TagId` ist angegeben, aber weder `ItemId` noch `ItemNrInt`: `Error` / *Mandatory parameter is missing*.\n - `ItemNrInt` nicht gefunden, `ItemId` unbekannt oder Tag unbekannt bzw. kein Artikel-Tag: `Error` / *One of the provided values is not valid*.\n2. Verbleibende Anforderungen, deren Tag-/Artikel-Paar bereits in `TagMatch` existiert (für ein Tag vom Typ 1): `Warning` / *Tag is already assigned to that item*.\n3. Alle übrigen Anforderungen: `Success` / *Tag was successfully assigned to item*. Diese Paare werden in `TagMatch` eingefügt (Duplikate innerhalb des XML nur einmal).\n\n**Ergebnis**\n\nEine Zeile je angeforderter Zuordnung, sortiert nach der Position des `Tag`-Elements im XML, mit Tag-ID, ermittelter Artikel-ID, übergebener Artikelnummer sowie `Status`/`Message`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | Nein | XML-Dokument mit den Artikeln und den zuzuordnenden Tags. Jedes `Item` enthält `ItemId` und/oder `ItemNrInt` sowie eine `TagList` mit einem oder mehreren `Tag`-Elementen mit `TagId`. |\n\n- Die Prozedur läuft in einer eigenen Transaktion oder setzt einen Savepoint, wenn der Aufrufer bereits eine Transaktion geöffnet hat.\n- Zugriffe auf `items`, `Tag`, `TagMatch` und `pixi.ItemCode` erfolgen mit `NOLOCK`; parallele Aufrufe können daher dasselbe Paar doppelt einfügen oder nicht festgeschriebene Daten sehen.\n- Bei einem unerwarteten Fehler wird die Transaktion zurückgerollt und der Fehler über `log.InsertError` (nicht beigefügt) protokolliert. Der CATCH-Block setzt intern eine \"Unexpected error\"-Meldung, gibt sie aber **nicht** als Zeile zurück; der Aufrufer erhält in diesem Fall kein Resultset. Ob `log.InsertError` den Fehler erneut auslöst, ist im Code nicht ersichtlich.\n- `ItemId` hat Vorrang vor `ItemNrInt`; sind beide angegeben, wird `ItemNrInt` nur zurückgegeben.\n- Passt eine `ItemNrInt` auf mehrere Einträge in `pixi.ItemCode`, kann eine Anforderung mehrere Ergebniszeilen erzeugen.\n- Tags mit einem `TypeId` ungleich 1 werden als ungültig abgewiesen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagMatchAddForItems"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ordnet Artikeln per XML ein oder mehrere Artikel-Tags zu und liefert je angeforderter Tag-/Artikel-Zuordnung eine Statuszeile.\n\nLegt Einträge in `TagMatch` an, die Tags vom Typ 1 (Artikel-Tags) mit Artikeln verknüpfen.\n\n**Verarbeitung der Eingabe**\n\n- `TagsXML` wird mit `OPENXML` über den Pfad `/Tags/Item/TagList/Tag` (elementzentriert) gelesen. Jedes `Tag`-Element ist eine angeforderte Zuordnung.\n- `TagId` wird aus dem `Tag`-Element gelesen, `ItemId` und `ItemNrInt` aus dem übergeordneten `Item`-Element. Die Werte `0` und Leerstring gelten als nicht angegeben.\n- Der Artikel wird so ermittelt: Ist `ItemId` angegeben, wird dieser Wert verwendet. Andernfalls wird `ItemNrInt` in `pixi.ItemCode` (`Code` mit `CodeTypeId = 2`) gesucht, um den Artikelschlüssel zu bestimmen.\n\n**Prüfung, in dieser Reihenfolge**\n\n1. Anforderungen, deren Artikelschlüssel nicht in `items` existiert oder deren Tag nicht in `Tag` mit `TypeId = 1` existiert, erhalten einen Status:\n - `TagId` fehlt, oder `TagId` ist angegeben, aber weder `ItemId` noch `ItemNrInt`: `Error` / *Mandatory parameter is missing*.\n - `ItemNrInt` nicht gefunden, `ItemId` unbekannt oder Tag unbekannt bzw. kein Artikel-Tag: `Error` / *One of the provided values is not valid*.\n2. Verbleibende Anforderungen, deren Tag-/Artikel-Paar bereits in `TagMatch` existiert (für ein Tag vom Typ 1): `Warning` / *Tag is already assigned to that item*.\n3. Alle übrigen Anforderungen: `Success` / *Tag was successfully assigned to item*. Diese Paare werden in `TagMatch` eingefügt (Duplikate innerhalb des XML nur einmal).\n\n**Ergebnis**\n\nEine Zeile je angeforderter Zuordnung, sortiert nach der Position des `Tag`-Elements im XML, mit Tag-ID, ermittelter Artikel-ID, übergebener Artikelnummer sowie `Status`/`Message`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | Nein | XML-Dokument mit den Artikeln und den zuzuordnenden Tags. Jedes `Item` enthält `ItemId` und/oder `ItemNrInt` sowie eine `TagList` mit einem oder mehreren `Tag`-Elementen mit `TagId`. |\n\n- Die Prozedur läuft in einer eigenen Transaktion oder setzt einen Savepoint, wenn der Aufrufer bereits eine Transaktion geöffnet hat.\n- Zugriffe auf `items`, `Tag`, `TagMatch` und `pixi.ItemCode` erfolgen mit `NOLOCK`; parallele Aufrufe können daher dasselbe Paar doppelt einfügen oder nicht festgeschriebene Daten sehen.\n- Bei einem unerwarteten Fehler wird die Transaktion zurückgerollt und der Fehler über `log.InsertError` (nicht beigefügt) protokolliert. Der CATCH-Block setzt intern eine \"Unexpected error\"-Meldung, gibt sie aber **nicht** als Zeile zurück; der Aufrufer erhält in diesem Fall kein Resultset. Ob `log.InsertError` den Fehler erneut auslöst, ist im Code nicht ersichtlich.\n- `ItemId` hat Vorrang vor `ItemNrInt`; sind beide angegeben, wird `ItemNrInt` nur zurückgegeben.\n- Passt eine `ItemNrInt` auf mehrere Einträge in `pixi.ItemCode`, kann eine Anforderung mehrere Ergebniszeilen erzeugen.\n- Tags mit einem `TypeId` ungleich 1 werden als ungültig abgewiesen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagMatchAddForItems"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 5\n 1234\n Success\n Tag was successfully assigned to item\n \n \n 7\n 1234\n Warning\n Tag is already assigned to that item\n \n"
}
]
},
{
"name": "pixiTagMatchDeleteForItems",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Entfernt Tag-Zuordnungen (TagMatch) von Artikeln für eine als XML übergebene Liste von Tag/Artikel-Paaren und liefert je Paar eine Statuszeile.\n\nLöscht Zuordnungen von Artikel-Tags zu Artikeln als Massenoperation.\n\n**Eingabe**\n\n`TagsXML` enthält je Artikel ein `Item`-Element mit einer `TagList` aus `Tag`-Elementen. Jedes `Tag`-Element ist eine Anfrage (Tag/Artikel-Paar). Der Artikel wird entweder über `ItemId` (Artikelschlüssel) oder über `ItemNrInt` (interne Artikelnummer, Suche in `ItemCode` mit Codetyp `2`) identifiziert. Ist `ItemId` angegeben, hat diese Vorrang vor `ItemNrInt`. Die Werte `0` für `TagId`/`ItemId` sowie eine leere `ItemNrInt` gelten als nicht angegeben.\n\n**Prüfung je Paar**\n\n- `TagId` fehlt oder weder `ItemId` noch `ItemNrInt` angegeben → `Error` / *Mandatory parameter is missing*.\n- `ItemNrInt` angegeben, aber nicht gefunden, `ItemId` nicht in `items` vorhanden oder `TagId` kein existierender Tag vom Typ `1` (Artikel-Tag) → `Error` / *One of the provided values is not valid*.\n- Tag und Artikel gültig und Zuordnung in `TagMatch` vorhanden → Zuordnung wird gelöscht, `Success` / *Tag was successfully removed from item*.\n- Tag und Artikel gültig, aber keine Zuordnung vorhanden → `Warning` / *Tag is not assigned to that item*.\n\n**Ausgabe**\n\nEine Ergebnismenge mit einer Zeile je verarbeitetem `Tag`-Element (sortiert nach der Position im XML) mit `TagId`, der ermittelten `ItemId`, der übergebenen `ItemNrInt`, `Status` und `Message`. Ungültige Paare verhindern nicht die Verarbeitung der übrigen Paare.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | Nein | XML-Dokument mit den Artikeln und den zu entfernenden Tags. Pfad `/Tags/Item/TagList/Tag`, elementbasiert: `Item` enthält `ItemId` oder `ItemNrInt`, jedes `Tag` enthält `TagId`. |\n\n- Der gesamte Aufruf läuft in einer Transaktion (`XACT_ABORT ON`); innerhalb einer bestehenden Transaktion wird stattdessen ein Savepoint gesetzt.\n- Bei einem unerwarteten SQL-Fehler wird die Transaktion zurückgerollt und der Fehler über `log.InsertError` protokolliert. Die Prozedur liefert in diesem Fall **keine** Ergebnismenge; eine leere Antwort ist daher als Fehler zu werten.\n- Ist `TagsXML` nicht angegeben (`NULL`) oder enthält es keine `Tag`-Elemente, wird nichts gelöscht und es werden keine Zeilen (bzw. keine Ergebnismenge) geliefert.\n- Sind `ItemId` und `ItemNrInt` beide angegeben, wird nur `ItemId` verwendet; die Übereinstimmung beider Werte wird nicht geprüft.\n- Passt eine `ItemNrInt` in `ItemCode` zu mehreren Artikeln, kann ein Paar mehrere Ergebniszeilen erzeugen.\n- Lesezugriffe verwenden `NOLOCK`, das Löschen `ROWLOCK`.\n- Es werden nur Tags mit `TypeId = 1` (Artikel-Tags) berücksichtigt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagMatchDeleteForItems"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Entfernt Tag-Zuordnungen (TagMatch) von Artikeln für eine als XML übergebene Liste von Tag/Artikel-Paaren und liefert je Paar eine Statuszeile.\n\nLöscht Zuordnungen von Artikel-Tags zu Artikeln als Massenoperation.\n\n**Eingabe**\n\n`TagsXML` enthält je Artikel ein `Item`-Element mit einer `TagList` aus `Tag`-Elementen. Jedes `Tag`-Element ist eine Anfrage (Tag/Artikel-Paar). Der Artikel wird entweder über `ItemId` (Artikelschlüssel) oder über `ItemNrInt` (interne Artikelnummer, Suche in `ItemCode` mit Codetyp `2`) identifiziert. Ist `ItemId` angegeben, hat diese Vorrang vor `ItemNrInt`. Die Werte `0` für `TagId`/`ItemId` sowie eine leere `ItemNrInt` gelten als nicht angegeben.\n\n**Prüfung je Paar**\n\n- `TagId` fehlt oder weder `ItemId` noch `ItemNrInt` angegeben → `Error` / *Mandatory parameter is missing*.\n- `ItemNrInt` angegeben, aber nicht gefunden, `ItemId` nicht in `items` vorhanden oder `TagId` kein existierender Tag vom Typ `1` (Artikel-Tag) → `Error` / *One of the provided values is not valid*.\n- Tag und Artikel gültig und Zuordnung in `TagMatch` vorhanden → Zuordnung wird gelöscht, `Success` / *Tag was successfully removed from item*.\n- Tag und Artikel gültig, aber keine Zuordnung vorhanden → `Warning` / *Tag is not assigned to that item*.\n\n**Ausgabe**\n\nEine Ergebnismenge mit einer Zeile je verarbeitetem `Tag`-Element (sortiert nach der Position im XML) mit `TagId`, der ermittelten `ItemId`, der übergebenen `ItemNrInt`, `Status` und `Message`. Ungültige Paare verhindern nicht die Verarbeitung der übrigen Paare.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | Nein | XML-Dokument mit den Artikeln und den zu entfernenden Tags. Pfad `/Tags/Item/TagList/Tag`, elementbasiert: `Item` enthält `ItemId` oder `ItemNrInt`, jedes `Tag` enthält `TagId`. |\n\n- Der gesamte Aufruf läuft in einer Transaktion (`XACT_ABORT ON`); innerhalb einer bestehenden Transaktion wird stattdessen ein Savepoint gesetzt.\n- Bei einem unerwarteten SQL-Fehler wird die Transaktion zurückgerollt und der Fehler über `log.InsertError` protokolliert. Die Prozedur liefert in diesem Fall **keine** Ergebnismenge; eine leere Antwort ist daher als Fehler zu werten.\n- Ist `TagsXML` nicht angegeben (`NULL`) oder enthält es keine `Tag`-Elemente, wird nichts gelöscht und es werden keine Zeilen (bzw. keine Ergebnismenge) geliefert.\n- Sind `ItemId` und `ItemNrInt` beide angegeben, wird nur `ItemId` verwendet; die Übereinstimmung beider Werte wird nicht geprüft.\n- Passt eine `ItemNrInt` in `ItemCode` zu mehreren Artikeln, kann ein Paar mehrere Ergebniszeilen erzeugen.\n- Lesezugriffe verwenden `NOLOCK`, das Löschen `ROWLOCK`.\n- Es werden nur Tags mit `TypeId = 1` (Artikel-Tags) berücksichtigt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagMatchDeleteForItems"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 5\n 1234\n Success\n Tag was successfully removed from item\n \n \n 7\n 1234\n Warning\n Tag is not assigned to that item\n \n"
}
]
}
]
},
{
"name": "KPIs",
"item": [
{
"name": "pixiReportShippedOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Dashboard-Zählwerte versendeter Rechnungen für den Stichtag, den Vortag, den laufenden Monat bis zum Enddatum und den Vormonat.\n\nZählt Versendungen für ein Dashboard. Eine Versendung ist ein Datensatz in `Invoices` mit einem `ScanOutDate`. Gezählt werden nur Rechnungen mit mindestens einer Auftragsposition (`Orderlines.InvRef`). Jede Rechnung zählt einmal; die Werte sind also Rechnungsanzahlen, keine Auftragsanzahlen.\n\nWirkung der Parameter:\n- `EndDate` ist standardmäßig das aktuelle Datum mit Uhrzeit (`GETDATE()`). Es ist der Bezugszeitpunkt für alle Zeiträume.\n- `StartDate` ist standardmäßig der erste Tag des Vormonats von `EndDate`. Es wird nur für den Wert des Stichtags verwendet, und nur wenn es auf demselben Kalendertag wie `EndDate` liegt. Ist `StartDate` später als `EndDate`, wird es auf `EndDate` gesetzt.\n- `ShopID` beschränkt die Zählung auf Rechnungen mit mindestens einer Auftragsposition mit `OrdShopID` = `ShopID`. Ein leerer Wert oder `NULL` bedeutet alle Shops.\n\nZuerst werden alle passenden Rechnungen gesammelt, deren `ScanOutDate` zwischen dem Beginn des Vormonats und dem Ende des Tages von `EndDate` liegt. Danach wird eine Zeile mit vier Zählwerten geliefert (alle Bereiche schließen beide Grenzen ein):\n- `ShipoutOnGivenDay`: ab `StartDate` (am selben Tag) oder sonst ab Mitternacht des Tages von `EndDate`, bis `EndDate`.\n- `ShipoutOnPreviousDay`: der ganze Kalendertag vor `EndDate`.\n- `ShipoutInGivenMonth`: vom 1. des Monats von `EndDate`, 00:00 Uhr, bis `EndDate`.\n- `ShipoutInPreviousMonth`: der ganze vorherige Kalendermonat.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | Nein | Startzeitpunkt für die Zählung am Stichtag. Wird nur verwendet, wenn er auf demselben Kalendertag wie `EndDate` liegt. Standard: erster Tag des Vormonats von `EndDate`; die Zählung beginnt dann um Mitternacht des Tages von `EndDate`. |\n| `EndDate` | datetime | Nein | Bezugszeitpunkt. Alle Zeiträume werden davon abgeleitet; die Zählwerte für Stichtag und Monat reichen bis zu diesem Zeitpunkt. Standard: aktuelles Datum mit Uhrzeit. |\n| `ShopID` | varchar(3) | Nein | Shop-Filter. Gezählt werden nur Rechnungen mit mindestens einer Auftragsposition dieses Shops (`OrdShopID`). Leer oder `NULL` bedeutet alle Shops. |\n\n- Alle vier Zählwerte werden in `varchar(10)`-Variablen gespeichert und daher als Zeichenketten geliefert, nicht als Ganzzahlen.\n- Die Zählung reicht bis `EndDate` selbst, nicht bis zum Ende dieses Tages. Wird `EndDate` ohne Uhrzeit (Mitternacht) übergeben, zählt `ShipoutOnGivenDay` nur Rechnungen, die genau um Mitternacht gescannt wurden, und `ShipoutInGivenMonth` lässt den ganzen Tag von `EndDate` aus. Daher eine Uhrzeit wie 23:59:59 übergeben oder `EndDate` weglassen, damit die aktuelle Uhrzeit gilt.\n- Mit `StartDate` lässt sich kein Zeitraum über mehrere Tage abfragen. Liegt es auf einem anderen Tag als `EndDate`, wird es ignoriert, und die Zählung für den Stichtag beginnt um Mitternacht des Tages von `EndDate`.\n- Die Lesezugriffe verwenden `NOLOCK`; die Zählwerte können daher nicht festgeschriebene Daten enthalten.\n- Tritt ein Fehler auf, wird die Meldung nur per `PRINT` ausgegeben, und die Prozedur endet mit Rückgabewert -1 ohne Ergebnismenge.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportShippedOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Dashboard-Zählwerte versendeter Rechnungen für den Stichtag, den Vortag, den laufenden Monat bis zum Enddatum und den Vormonat.\n\nZählt Versendungen für ein Dashboard. Eine Versendung ist ein Datensatz in `Invoices` mit einem `ScanOutDate`. Gezählt werden nur Rechnungen mit mindestens einer Auftragsposition (`Orderlines.InvRef`). Jede Rechnung zählt einmal; die Werte sind also Rechnungsanzahlen, keine Auftragsanzahlen.\n\nWirkung der Parameter:\n- `EndDate` ist standardmäßig das aktuelle Datum mit Uhrzeit (`GETDATE()`). Es ist der Bezugszeitpunkt für alle Zeiträume.\n- `StartDate` ist standardmäßig der erste Tag des Vormonats von `EndDate`. Es wird nur für den Wert des Stichtags verwendet, und nur wenn es auf demselben Kalendertag wie `EndDate` liegt. Ist `StartDate` später als `EndDate`, wird es auf `EndDate` gesetzt.\n- `ShopID` beschränkt die Zählung auf Rechnungen mit mindestens einer Auftragsposition mit `OrdShopID` = `ShopID`. Ein leerer Wert oder `NULL` bedeutet alle Shops.\n\nZuerst werden alle passenden Rechnungen gesammelt, deren `ScanOutDate` zwischen dem Beginn des Vormonats und dem Ende des Tages von `EndDate` liegt. Danach wird eine Zeile mit vier Zählwerten geliefert (alle Bereiche schließen beide Grenzen ein):\n- `ShipoutOnGivenDay`: ab `StartDate` (am selben Tag) oder sonst ab Mitternacht des Tages von `EndDate`, bis `EndDate`.\n- `ShipoutOnPreviousDay`: der ganze Kalendertag vor `EndDate`.\n- `ShipoutInGivenMonth`: vom 1. des Monats von `EndDate`, 00:00 Uhr, bis `EndDate`.\n- `ShipoutInPreviousMonth`: der ganze vorherige Kalendermonat.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | Nein | Startzeitpunkt für die Zählung am Stichtag. Wird nur verwendet, wenn er auf demselben Kalendertag wie `EndDate` liegt. Standard: erster Tag des Vormonats von `EndDate`; die Zählung beginnt dann um Mitternacht des Tages von `EndDate`. |\n| `EndDate` | datetime | Nein | Bezugszeitpunkt. Alle Zeiträume werden davon abgeleitet; die Zählwerte für Stichtag und Monat reichen bis zu diesem Zeitpunkt. Standard: aktuelles Datum mit Uhrzeit. |\n| `ShopID` | varchar(3) | Nein | Shop-Filter. Gezählt werden nur Rechnungen mit mindestens einer Auftragsposition dieses Shops (`OrdShopID`). Leer oder `NULL` bedeutet alle Shops. |\n\n- Alle vier Zählwerte werden in `varchar(10)`-Variablen gespeichert und daher als Zeichenketten geliefert, nicht als Ganzzahlen.\n- Die Zählung reicht bis `EndDate` selbst, nicht bis zum Ende dieses Tages. Wird `EndDate` ohne Uhrzeit (Mitternacht) übergeben, zählt `ShipoutOnGivenDay` nur Rechnungen, die genau um Mitternacht gescannt wurden, und `ShipoutInGivenMonth` lässt den ganzen Tag von `EndDate` aus. Daher eine Uhrzeit wie 23:59:59 übergeben oder `EndDate` weglassen, damit die aktuelle Uhrzeit gilt.\n- Mit `StartDate` lässt sich kein Zeitraum über mehrere Tage abfragen. Liegt es auf einem anderen Tag als `EndDate`, wird es ignoriert, und die Zählung für den Stichtag beginnt um Mitternacht des Tages von `EndDate`.\n- Die Lesezugriffe verwenden `NOLOCK`; die Zählwerte können daher nicht festgeschriebene Daten enthalten.\n- Tritt ein Fehler auf, wird die Meldung nur per `PRINT` ausgegeben, und die Prozedur endet mit Rückgabewert -1 ohne Ergebnismenge.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportShippedOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 142\n 318\n 4127\n 8954\n \n"
}
]
},
{
"name": "pixiReportShippingEfficiency",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die durchschnittliche Durchlaufzeit von Aufträgen in Tagen und den Anteil der innerhalb von 24 Stunden versendeten Aufträge der letzten N Tage.\n\nBerechnet zwei Versandeffizienz-Kennzahlen für das CEO-Dashboard. Die Werte werden als eine Zeile und zusätzlich über die beiden `OUTPUT`-Parameter zurückgegeben.\n\n1. **Betrachtungszeitraum**: Der Zeitraum beginnt um Mitternacht des Tages, der `@SamplingPeriod` Tage vor heute liegt, und endet zum aktuellen Zeitpunkt. Ist `@SamplingPeriod` `NULL`, werden 7 Tage verwendet.\n2. **Berücksichtigte Aufträge**: Ein Auftrag gilt als versendet, wenn er mindestens eine Auftragsposition mit Status `AUS` und einem `ShipDate` im Zeitraum hat und keine seiner Positionen einen anderen Status als `AUS` hat. Teilweise versendete Aufträge und Aufträge mit Positionen in einem anderen Status werden ignoriert.\n3. **Durchlaufzeit je Auftrag**: Für die im Zeitraum versendeten Positionen werden die `ANG`- und `AUS`-Einträge aus der Auftragshistorie gelesen. Die Durchlaufzeit eines Auftrags ist die Differenz in Stunden (`DATEDIFF(hh, …)`) zwischen dem frühesten `ANG`-Statuswechsel und dem spätesten `AUS`-Statuswechsel.\n4. **Kennzahlen**:\n - `AVGThroughputTimeInDays`: Summe der in Tage umgerechneten Durchlaufzeiten je Auftrag (`hoursPassed / 24`), geteilt durch die Anzahl versendeter Aufträge. Das Ergebnis wird auf 2 Nachkommastellen gerundet.\n - `PercThroughputTimeIn24h`: Anzahl der Aufträge mit einer Durchlaufzeit von höchstens 24 Stunden, geteilt durch die Anzahl versendeter Aufträge und multipliziert mit 100. Das Ergebnis wird auf 2 Nachkommastellen gerundet.\n5. Werden keine versendeten Aufträge gefunden, sind beide Werte `0`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SamplingPeriod` | int | Nein | Anzahl der Tage ab heute rückwärts, über die die Kennzahlen berechnet werden. Der Zeitraum beginnt um Mitternacht dieses Tages. `NULL` wird als 7 behandelt. |\n| `AVGThroughputTimeInDays` | float | Nein | Ausgabe: durchschnittliche Durchlaufzeit in Tagen (volle Tage je Auftrag), auf 2 Nachkommastellen gerundet. Ein übergebener Wert wird ignoriert. |\n| `PercThroughputTimeIn24h` | float | Nein | Ausgabe: prozentualer Anteil der versendeten Aufträge mit einer Durchlaufzeit von höchstens 24 Stunden, auf 2 Nachkommastellen gerundet. Ein übergebener Wert wird ignoriert. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, die Werte können daher nicht festgeschriebene Daten enthalten.\n- `hoursPassed` ist ein Integer, daher ist `hoursPassed / 24` eine Ganzzahldivision. Jeder Auftrag geht nur mit vollen Tagen in den Durchschnitt ein, Tagesbruchteile werden abgeschnitten. Ein Auftrag mit 30 Stunden zählt als 1 Tag, ein Auftrag mit 20 Stunden als 0 Tage.\n- `DATEDIFF(hh, …)` zählt überschrittene Stundengrenzen. Es misst nicht die exakt verstrichene Zeit.\n- Der Divisor ist die Anzahl aller vollständig versendeten Aufträge. Dazu zählen auch Aufträge ohne `ANG`/`AUS`-Einträge in der Historie. Solche Aufträge haben keine Durchlaufzeit oder eine Durchlaufzeit `NULL`. Sie senken beide Kennzahlen.\n- Sonderfall: Gibt es versendete Aufträge, aber keiner hat passende Historieneinträge, ist die Summe `NULL`. `AVGThroughputTimeInDays` wird dann als `NULL` und `PercThroughputTimeIn24h` als `0` geliefert.\n- Für den frühesten `ANG`- und den spätesten `AUS`-Zeitpunkt werden nur Positionen mit `ShipDate` im Zeitraum herangezogen.\n- Bei großer Auftragshistorie kann der Aufruf aufwendig sein, da `orderhistory` nach allen `ANG`/`AUS`-Einträgen durchsucht wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportShippingEfficiency"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die durchschnittliche Durchlaufzeit von Aufträgen in Tagen und den Anteil der innerhalb von 24 Stunden versendeten Aufträge der letzten N Tage.\n\nBerechnet zwei Versandeffizienz-Kennzahlen für das CEO-Dashboard. Die Werte werden als eine Zeile und zusätzlich über die beiden `OUTPUT`-Parameter zurückgegeben.\n\n1. **Betrachtungszeitraum**: Der Zeitraum beginnt um Mitternacht des Tages, der `@SamplingPeriod` Tage vor heute liegt, und endet zum aktuellen Zeitpunkt. Ist `@SamplingPeriod` `NULL`, werden 7 Tage verwendet.\n2. **Berücksichtigte Aufträge**: Ein Auftrag gilt als versendet, wenn er mindestens eine Auftragsposition mit Status `AUS` und einem `ShipDate` im Zeitraum hat und keine seiner Positionen einen anderen Status als `AUS` hat. Teilweise versendete Aufträge und Aufträge mit Positionen in einem anderen Status werden ignoriert.\n3. **Durchlaufzeit je Auftrag**: Für die im Zeitraum versendeten Positionen werden die `ANG`- und `AUS`-Einträge aus der Auftragshistorie gelesen. Die Durchlaufzeit eines Auftrags ist die Differenz in Stunden (`DATEDIFF(hh, …)`) zwischen dem frühesten `ANG`-Statuswechsel und dem spätesten `AUS`-Statuswechsel.\n4. **Kennzahlen**:\n - `AVGThroughputTimeInDays`: Summe der in Tage umgerechneten Durchlaufzeiten je Auftrag (`hoursPassed / 24`), geteilt durch die Anzahl versendeter Aufträge. Das Ergebnis wird auf 2 Nachkommastellen gerundet.\n - `PercThroughputTimeIn24h`: Anzahl der Aufträge mit einer Durchlaufzeit von höchstens 24 Stunden, geteilt durch die Anzahl versendeter Aufträge und multipliziert mit 100. Das Ergebnis wird auf 2 Nachkommastellen gerundet.\n5. Werden keine versendeten Aufträge gefunden, sind beide Werte `0`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SamplingPeriod` | int | Nein | Anzahl der Tage ab heute rückwärts, über die die Kennzahlen berechnet werden. Der Zeitraum beginnt um Mitternacht dieses Tages. `NULL` wird als 7 behandelt. |\n| `AVGThroughputTimeInDays` | float | Nein | Ausgabe: durchschnittliche Durchlaufzeit in Tagen (volle Tage je Auftrag), auf 2 Nachkommastellen gerundet. Ein übergebener Wert wird ignoriert. |\n| `PercThroughputTimeIn24h` | float | Nein | Ausgabe: prozentualer Anteil der versendeten Aufträge mit einer Durchlaufzeit von höchstens 24 Stunden, auf 2 Nachkommastellen gerundet. Ein übergebener Wert wird ignoriert. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, die Werte können daher nicht festgeschriebene Daten enthalten.\n- `hoursPassed` ist ein Integer, daher ist `hoursPassed / 24` eine Ganzzahldivision. Jeder Auftrag geht nur mit vollen Tagen in den Durchschnitt ein, Tagesbruchteile werden abgeschnitten. Ein Auftrag mit 30 Stunden zählt als 1 Tag, ein Auftrag mit 20 Stunden als 0 Tage.\n- `DATEDIFF(hh, …)` zählt überschrittene Stundengrenzen. Es misst nicht die exakt verstrichene Zeit.\n- Der Divisor ist die Anzahl aller vollständig versendeten Aufträge. Dazu zählen auch Aufträge ohne `ANG`/`AUS`-Einträge in der Historie. Solche Aufträge haben keine Durchlaufzeit oder eine Durchlaufzeit `NULL`. Sie senken beide Kennzahlen.\n- Sonderfall: Gibt es versendete Aufträge, aber keiner hat passende Historieneinträge, ist die Summe `NULL`. `AVGThroughputTimeInDays` wird dann als `NULL` und `PercThroughputTimeIn24h` als `0` geliefert.\n- Für den frühesten `ANG`- und den spätesten `AUS`-Zeitpunkt werden nur Positionen mit `ShipDate` im Zeitraum herangezogen.\n- Bei großer Auftragshistorie kann der Aufruf aufwendig sein, da `orderhistory` nach allen `ANG`/`AUS`-Einträgen durchsucht wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportShippingEfficiency"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1.37\n 62.5\n \n"
}
]
}
]
},
{
"name": "Orderlines",
"item": [
{
"name": "pixiAddOrderLine",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104532\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine neue Auftragsposition für einen Artikel in einem bestehenden Auftrag an, berechnet Preise und Rabatte und liefert die neue Positions-ID oder Validierungsfehler.\n\nLegt eine Auftragsposition (Zeile in `Orderlines`) im Auftrag `PixiOrderNr` an.\n\n**1. Normalisierung**\n- `ItemKey` = 0 gilt als NULL, `ItemNrInt` = '' gilt als NULL.\n- Ein leeres `Date` wird zum aktuellen Zeitpunkt.\n- Ein leerer `Status` wird zu `NEW`.\n- Ein NULL-Wert bei `UsePaymentStatus` wird zu 0, ein NULL-Wert bei `LocationID` wird zu `001`.\n\n**2. Prüfungen**\nAlle fehlgeschlagenen Prüfungen werden gesammelt, jede erzeugt eine Fehlerzeile:\n- `UsePaymentStatus` = 1 zusammen mit einem `Status` ungleich `NEW` wird abgelehnt.\n- `Status` muss einer der Werte `NEW`, `ANG`, `HAL`, `FUT`, `STO`, `NLB` sein.\n- Ist `ItemNrInt` angegeben, wird der Artikel über `ItemNrInt` gesucht. Der gefundene Schlüssel ersetzt `ItemKey`. Wird kein Artikel gefunden, entsteht ein Fehler.\n- Ist bis dahin kein Fehler aufgetreten, muss der Artikel einen Eintrag in `pixi.ItemCode` haben.\n- Ein `Discount` (Gutscheinbetrag) ungleich 0 erfordert eine `VoucherID`.\n- Enthält der Auftrag bereits eine Position mit Gutschein, wird eine abweichende `VoucherID` abgelehnt. Pro Auftrag ist nur ein Gutschein erlaubt.\n\nSchlägt eine Prüfung fehl, werden die Fehlerzeilen zurückgegeben und es wird nichts geschrieben.\n\n**3. Status aus der Zahlungsart**\nBei `UsePaymentStatus` = 1 wird der Positionsstatus aus `Payments.IniOrderStatus` der Zahlungsart der Rechnungsadresse des Auftrags übernommen.\n\n**4. Dürfen Positionen ergänzt werden?**\n`pipiCanAddOrderlines` prüft, ob der Auftrag noch neue Positionen annimmt:\n- Bei den Zahlungsarten `K`/`C` müssen alle vorhandenen Positionen in `NEW`, `ANG`, `HAL`, `MIN`, `OPH`, `BES`, `STO` oder `NLB` stehen.\n- Bei anderen Zahlungsarten darf keine Position in `EIN` oder `AUS` stehen.\n\nNur bei Ergebnis 1 wird die Position angelegt.\n\n**5. Kopfdaten**\n- Kunde, Adressen, Auftragstyp, Währung und die bestehenden Kopfwerte werden aus dem Auftrag gelesen.\n- `OrderNrExternal` stammt aus dem Auftragskopf. Fehlt dort ein Wert, wird der Parameter verwendet. Fehlt auch dieser, wird eine Zeitstempel-Zeichenkette erzeugt.\n- `Employee` wird als ` (API)` gespeichert, ohne Angabe als `API`.\n\n**6. Währung**\nIst die Einstellung `MultiCurrencyEnabled` aus oder hat der Auftrag keinen Wechselkurs, wird die Datenbankwährung mit Kurs 1 verwendet. Andernfalls:\n- Die tagesaktuellen Kurse werden aus `pixi.ExchRate` gelesen.\n- Für die Datenbankwährung wird deren Kursquelle verwendet.\n- Für die Basiswährung des Wechselkurs-Eintrags des Auftrags dient die `ExchRateSourceID` des Shops als Quelle.\n\n**7. Preise**\n- `FullPrice` (brutto) und das Netto-Gegenstück stammen aus dem Parameter, sofern er ungleich 0 ist.\n- Andernfalls wird der Artikelpreis verwendet: zuerst der Preis in Auftragswährung, dann der Basiswährungspreis × Kurs, dann der Datenbankwährungspreis × Kurs, sonst 0.\n- Bei `B2B`-Aufträgen gilt der Parameter `FullPrice` als Nettopreis, und der Bruttopreis wird immer aus den Artikelpreisen ermittelt.\n- `ItemName` überschreibt die Artikelbezeichnung.\n\n**8. Positionsrabatt**\n- Ist `FullPriceDiscountValue` angegeben, wird dieser Wert verwendet.\n- Sonst wird `DiscountPercent` % vom Bruttopreis (`B2C`) bzw. vom Nettopreis (andere Auftragstypen) verwendet.\n- Sonst wird der volle Preis minus `DiscountedPrice` verwendet.\n- Sonst ist der Rabatt 0.\n\nDerselbe Rabattwert wird vom Brutto- und vom Nettopreis abgezogen und ergibt `Price` und `Price_Net`.\n\n**9. Kopfwerte des Auftrags**\n- `ShipCost`, `Discount`, `AddressRemarks`, `Verfahren`, `Product` und `Extras` werden aus den Parametern übernommen, wenn sie nicht leer bzw. ungleich 0 sind. Andernfalls bleiben die bestehenden Kopfwerte erhalten.\n- Ein bereits vorhandener Gutschein des Auftrags hat immer Vorrang vor `VoucherID`.\n\n**10. Anlage**\nDie Position wird über `Pixi_InsertOrderline` mit diesen festen Werten angelegt:\n- Quelle `I`\n- Positionstyp `ORD`\n- 15 Wartetage\n- `LocationID` als Lager und als letztes Bestelllager\n\nAnschließend wird eine Zeile mit `CanAdd` = 1 und der neuen `OrderlineId` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PixiOrderNr` | int | Ja | Pixi-Auftragsnummer des bestehenden Auftrags. |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel. 0 gilt als NULL. Wird durch den über `ItemNrInt` gefundenen Schlüssel ersetzt, falls dieser Parameter angegeben ist. |\n| `ItemNrInt` | varchar(50) | Nein | Shop-Artikelnummer zur Suche des Artikels. Eine leere Zeichenkette gilt als NULL. |\n| `Quantity` | int | Nein | Menge der Auftragsposition. |\n| `ShipCost` | money | Nein | Versandkosten der Position. Bei 0 werden die Versandkosten des Auftragskopfs verwendet. |\n| `LocationID` | varchar(3) | Nein | Lager-ID der Position. NULL wird zu `001`. |\n| `GiftMessage` | varchar(8000) | Nein | Geschenknachricht. Wird in den Auftragskopf geschrieben und überschreibt den vorhandenen Wert, auch mit der leeren Zeichenkette als Standardwert. |\n| `DiscountPercent` | numeric(6, 2) | Nein | Positionsrabatt in Prozent des vollen Preises (brutto bei B2C, sonst netto). Wird nur verwendet, wenn `FullPriceDiscountValue` NULL ist. |\n| `VoucherID` | varchar(50) | Nein | Gutscheincode. Pflicht, wenn `Discount` ungleich 0 ist. Ein bereits im Auftrag vorhandener Gutschein hat Vorrang; ein abweichender Code wird abgelehnt. |\n| `Discount` | money | Nein | Gutscheinbetrag für den Auftragskopf. Bei NULL oder 0 bleibt der vorhandene Kopfwert erhalten. Ist der resultierende Wert > 0, wird ein Gutscheindatensatz angelegt, falls noch keiner existiert. |\n| `AddressRemarks` | varchar(255) | Nein | Adressbemerkung für den Auftragskopf. Bei leerem Wert bleibt der vorhandene Wert erhalten. |\n| `Verfahren` | varchar(50) | Nein | Wert für das Kopffeld `Verfahren`. Bei leerem Wert bleibt der vorhandene Wert erhalten. |\n| `Product` | varchar(50) | Nein | Wert für das Kopffeld `Product`. Bei leerem Wert bleibt der vorhandene Wert erhalten. |\n| `Extras` | varchar(50) | Nein | Wert für das Kopffeld `Extras`. Bei leerem Wert bleibt der vorhandene Wert erhalten. |\n| `Employee` | varchar(50) | Nein | Anlegender Mitarbeiter. Wird mit dem Zusatz ` (API)` gespeichert; bei NULL wird `API` gespeichert. |\n| `Date` | datetime | Nein | Anlagedatum der Position (`CreateDate`/`UpdateDate`). Bei leerem Wert wird der aktuelle Zeitpunkt verwendet. `OrderDate` der Position ist immer der aktuelle Zeitpunkt. |\n| `Status` | varchar(3) | Nein | Status der neuen Position. Bei leerem Wert wird `NEW` verwendet. |\n| `UsePaymentStatus` | bit | Nein | Bei 1 wird der Positionsstatus aus dem initialen Auftragsstatus der Zahlungsart des Auftrags übernommen. Nicht kombinierbar mit einem `Status` ungleich `NEW`. |\n| `ItemNrExternal` | varchar(50) | Nein | Externe Artikelnummer, die in der Position gespeichert wird. |\n| `FullPrice` | money | Nein | Voller Bruttopreis vor Rabatt. Bei B2B-Aufträgen wird der Wert als Nettopreis verwendet. Bei NULL oder 0 wird der Artikelpreis verwendet. |\n| `FullPriceDiscountValue` | money | Nein | Absoluter Rabatt je Einheit. Hat Vorrang vor `DiscountPercent` und `DiscountedPrice`. |\n| `DiscountedPrice` | money | Nein | Preis nach Rabatt. Der Rabatt ergibt sich aus vollem Preis minus diesem Wert; wird nur verwendet, wenn kein anderer Rabattparameter angegeben ist. |\n| `ItemName` | varchar(120) | Nein | Artikelbezeichnung der Position. Bei NULL wird die Bezeichnung aus dem Artikelstamm verwendet. |\n| `ItemSpecialNote` | varchar(8000) | Nein | Sonderhinweis zur Position (`oItemSpecialNote`). |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer. Wird nur verwendet, wenn der Auftragskopf keine hat; sonst gilt der Kopfwert. Ohne beides wird eine Zeitstempel-Zeichenkette erzeugt. |\n| `DF_Type` | varchar(1) | Nein | Direct-Fulfillment-Typ, wird in `DF_type` der Position gespeichert. |\n| `SerialNumber` | varchar(50) | Nein | Seriennummer, wird in `SerialNr` der Position gespeichert. |\n\n- **Kein Ergebnis, wenn keine Positionen ergänzt werden dürfen:** Liefert `pipiCanAddOrderlines` 0 oder NULL, gibt der Aufruf überhaupt keine Zeilen zurück. Das ist der Fall, wenn der Auftrag nicht existiert oder eine Position bereits in einem sperrenden Status steht. Eine leere Antwort ist daher als „nicht angelegt“ zu werten.\n- **Doppelte Fehlerzeile:** Die Prüfung `UsePaymentStatus` = 1 mit `Status` ≠ `NEW` läuft zweimal, der Fehler erscheint daher doppelt im Ergebnis.\n- **Status wird nicht erneut geprüft:** Ein aus der Zahlungsart übernommener Status (`UsePaymentStatus` = 1) wird nicht gegen die erlaubte Liste geprüft.\n- **Artikelpreis erforderlich:** Der Artikel benötigt eine Preiszeile in der Datenbankwährung (Inner Join auf `pixi.ItemPrice`). Andernfalls werden Artikeldaten und Preise nicht gefüllt, und die Position kann ohne EAN oder Preis entstehen.\n- **Auftragskopf wird überschrieben:** `Pixi_InsertOrderline` aktualisiert die Kopffelder `GiftMessage`, `ShipInstruct`, `Discount`, `Address_Remarks`, `Verfahren`, `Product`, `Extras`, `Shipdate` und die Steuersätze.\n - `GiftMessage` hat den Standardwert '' und überschreibt damit eine vorhandene Geschenknachricht.\n - `ShipInstruct` wird auf '' und `Shipdate` auf NULL gesetzt.\n- **Gutscheinanlage:** Ist der resultierende `Discount` > 0 und existiert noch kein `Voucher`-Eintrag mit dieser ID, wird ein Gutschein mit Shop `GRM` und der Auftragswährung angelegt. Das Ablaufdatum wird mit `DATEADD(y, 1, …)` berechnet; der Datumsteil `y` steht für den Tag des Jahres, das Datum liegt also einen Tag nach dem Bestelldatum.\n- **Protokollierung:** Weicht `OrderNrExternal` vom Kopfwert ab, wird ein Eintrag in `LogTable` geschrieben.\n- **Transaktion:** Die Anlage erfolgt in einer Transaktion innerhalb von `Pixi_InsertOrderline`.\n- **Positions-ID:** Die neue ID wird aus einer temporären Tabelle gelesen, die ein `INSTEAD OF`-Trigger auf `Orderlines` füllt. Der Trigger liegt nicht vor. Wird keine ID geliefert, ist `OrderlineId` NULL, obwohl `CanAdd` = 1 ist.\n- **Lesezugriffe:** Alle Lesezugriffe verwenden `NOLOCK`.\n- **Wechselkurse:** Kurse werden nur für das aktuelle Datum gesucht. Fehlt ein Kurs für heute, werden umgerechnete Preise NULL.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAddOrderLine"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104532\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine neue Auftragsposition für einen Artikel in einem bestehenden Auftrag an, berechnet Preise und Rabatte und liefert die neue Positions-ID oder Validierungsfehler.\n\nLegt eine Auftragsposition (Zeile in `Orderlines`) im Auftrag `PixiOrderNr` an.\n\n**1. Normalisierung**\n- `ItemKey` = 0 gilt als NULL, `ItemNrInt` = '' gilt als NULL.\n- Ein leeres `Date` wird zum aktuellen Zeitpunkt.\n- Ein leerer `Status` wird zu `NEW`.\n- Ein NULL-Wert bei `UsePaymentStatus` wird zu 0, ein NULL-Wert bei `LocationID` wird zu `001`.\n\n**2. Prüfungen**\nAlle fehlgeschlagenen Prüfungen werden gesammelt, jede erzeugt eine Fehlerzeile:\n- `UsePaymentStatus` = 1 zusammen mit einem `Status` ungleich `NEW` wird abgelehnt.\n- `Status` muss einer der Werte `NEW`, `ANG`, `HAL`, `FUT`, `STO`, `NLB` sein.\n- Ist `ItemNrInt` angegeben, wird der Artikel über `ItemNrInt` gesucht. Der gefundene Schlüssel ersetzt `ItemKey`. Wird kein Artikel gefunden, entsteht ein Fehler.\n- Ist bis dahin kein Fehler aufgetreten, muss der Artikel einen Eintrag in `pixi.ItemCode` haben.\n- Ein `Discount` (Gutscheinbetrag) ungleich 0 erfordert eine `VoucherID`.\n- Enthält der Auftrag bereits eine Position mit Gutschein, wird eine abweichende `VoucherID` abgelehnt. Pro Auftrag ist nur ein Gutschein erlaubt.\n\nSchlägt eine Prüfung fehl, werden die Fehlerzeilen zurückgegeben und es wird nichts geschrieben.\n\n**3. Status aus der Zahlungsart**\nBei `UsePaymentStatus` = 1 wird der Positionsstatus aus `Payments.IniOrderStatus` der Zahlungsart der Rechnungsadresse des Auftrags übernommen.\n\n**4. Dürfen Positionen ergänzt werden?**\n`pipiCanAddOrderlines` prüft, ob der Auftrag noch neue Positionen annimmt:\n- Bei den Zahlungsarten `K`/`C` müssen alle vorhandenen Positionen in `NEW`, `ANG`, `HAL`, `MIN`, `OPH`, `BES`, `STO` oder `NLB` stehen.\n- Bei anderen Zahlungsarten darf keine Position in `EIN` oder `AUS` stehen.\n\nNur bei Ergebnis 1 wird die Position angelegt.\n\n**5. Kopfdaten**\n- Kunde, Adressen, Auftragstyp, Währung und die bestehenden Kopfwerte werden aus dem Auftrag gelesen.\n- `OrderNrExternal` stammt aus dem Auftragskopf. Fehlt dort ein Wert, wird der Parameter verwendet. Fehlt auch dieser, wird eine Zeitstempel-Zeichenkette erzeugt.\n- `Employee` wird als ` (API)` gespeichert, ohne Angabe als `API`.\n\n**6. Währung**\nIst die Einstellung `MultiCurrencyEnabled` aus oder hat der Auftrag keinen Wechselkurs, wird die Datenbankwährung mit Kurs 1 verwendet. Andernfalls:\n- Die tagesaktuellen Kurse werden aus `pixi.ExchRate` gelesen.\n- Für die Datenbankwährung wird deren Kursquelle verwendet.\n- Für die Basiswährung des Wechselkurs-Eintrags des Auftrags dient die `ExchRateSourceID` des Shops als Quelle.\n\n**7. Preise**\n- `FullPrice` (brutto) und das Netto-Gegenstück stammen aus dem Parameter, sofern er ungleich 0 ist.\n- Andernfalls wird der Artikelpreis verwendet: zuerst der Preis in Auftragswährung, dann der Basiswährungspreis × Kurs, dann der Datenbankwährungspreis × Kurs, sonst 0.\n- Bei `B2B`-Aufträgen gilt der Parameter `FullPrice` als Nettopreis, und der Bruttopreis wird immer aus den Artikelpreisen ermittelt.\n- `ItemName` überschreibt die Artikelbezeichnung.\n\n**8. Positionsrabatt**\n- Ist `FullPriceDiscountValue` angegeben, wird dieser Wert verwendet.\n- Sonst wird `DiscountPercent` % vom Bruttopreis (`B2C`) bzw. vom Nettopreis (andere Auftragstypen) verwendet.\n- Sonst wird der volle Preis minus `DiscountedPrice` verwendet.\n- Sonst ist der Rabatt 0.\n\nDerselbe Rabattwert wird vom Brutto- und vom Nettopreis abgezogen und ergibt `Price` und `Price_Net`.\n\n**9. Kopfwerte des Auftrags**\n- `ShipCost`, `Discount`, `AddressRemarks`, `Verfahren`, `Product` und `Extras` werden aus den Parametern übernommen, wenn sie nicht leer bzw. ungleich 0 sind. Andernfalls bleiben die bestehenden Kopfwerte erhalten.\n- Ein bereits vorhandener Gutschein des Auftrags hat immer Vorrang vor `VoucherID`.\n\n**10. Anlage**\nDie Position wird über `Pixi_InsertOrderline` mit diesen festen Werten angelegt:\n- Quelle `I`\n- Positionstyp `ORD`\n- 15 Wartetage\n- `LocationID` als Lager und als letztes Bestelllager\n\nAnschließend wird eine Zeile mit `CanAdd` = 1 und der neuen `OrderlineId` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PixiOrderNr` | int | Ja | Pixi-Auftragsnummer des bestehenden Auftrags. |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel. 0 gilt als NULL. Wird durch den über `ItemNrInt` gefundenen Schlüssel ersetzt, falls dieser Parameter angegeben ist. |\n| `ItemNrInt` | varchar(50) | Nein | Shop-Artikelnummer zur Suche des Artikels. Eine leere Zeichenkette gilt als NULL. |\n| `Quantity` | int | Nein | Menge der Auftragsposition. |\n| `ShipCost` | money | Nein | Versandkosten der Position. Bei 0 werden die Versandkosten des Auftragskopfs verwendet. |\n| `LocationID` | varchar(3) | Nein | Lager-ID der Position. NULL wird zu `001`. |\n| `GiftMessage` | varchar(8000) | Nein | Geschenknachricht. Wird in den Auftragskopf geschrieben und überschreibt den vorhandenen Wert, auch mit der leeren Zeichenkette als Standardwert. |\n| `DiscountPercent` | numeric(6, 2) | Nein | Positionsrabatt in Prozent des vollen Preises (brutto bei B2C, sonst netto). Wird nur verwendet, wenn `FullPriceDiscountValue` NULL ist. |\n| `VoucherID` | varchar(50) | Nein | Gutscheincode. Pflicht, wenn `Discount` ungleich 0 ist. Ein bereits im Auftrag vorhandener Gutschein hat Vorrang; ein abweichender Code wird abgelehnt. |\n| `Discount` | money | Nein | Gutscheinbetrag für den Auftragskopf. Bei NULL oder 0 bleibt der vorhandene Kopfwert erhalten. Ist der resultierende Wert > 0, wird ein Gutscheindatensatz angelegt, falls noch keiner existiert. |\n| `AddressRemarks` | varchar(255) | Nein | Adressbemerkung für den Auftragskopf. Bei leerem Wert bleibt der vorhandene Wert erhalten. |\n| `Verfahren` | varchar(50) | Nein | Wert für das Kopffeld `Verfahren`. Bei leerem Wert bleibt der vorhandene Wert erhalten. |\n| `Product` | varchar(50) | Nein | Wert für das Kopffeld `Product`. Bei leerem Wert bleibt der vorhandene Wert erhalten. |\n| `Extras` | varchar(50) | Nein | Wert für das Kopffeld `Extras`. Bei leerem Wert bleibt der vorhandene Wert erhalten. |\n| `Employee` | varchar(50) | Nein | Anlegender Mitarbeiter. Wird mit dem Zusatz ` (API)` gespeichert; bei NULL wird `API` gespeichert. |\n| `Date` | datetime | Nein | Anlagedatum der Position (`CreateDate`/`UpdateDate`). Bei leerem Wert wird der aktuelle Zeitpunkt verwendet. `OrderDate` der Position ist immer der aktuelle Zeitpunkt. |\n| `Status` | varchar(3) | Nein | Status der neuen Position. Bei leerem Wert wird `NEW` verwendet. |\n| `UsePaymentStatus` | bit | Nein | Bei 1 wird der Positionsstatus aus dem initialen Auftragsstatus der Zahlungsart des Auftrags übernommen. Nicht kombinierbar mit einem `Status` ungleich `NEW`. |\n| `ItemNrExternal` | varchar(50) | Nein | Externe Artikelnummer, die in der Position gespeichert wird. |\n| `FullPrice` | money | Nein | Voller Bruttopreis vor Rabatt. Bei B2B-Aufträgen wird der Wert als Nettopreis verwendet. Bei NULL oder 0 wird der Artikelpreis verwendet. |\n| `FullPriceDiscountValue` | money | Nein | Absoluter Rabatt je Einheit. Hat Vorrang vor `DiscountPercent` und `DiscountedPrice`. |\n| `DiscountedPrice` | money | Nein | Preis nach Rabatt. Der Rabatt ergibt sich aus vollem Preis minus diesem Wert; wird nur verwendet, wenn kein anderer Rabattparameter angegeben ist. |\n| `ItemName` | varchar(120) | Nein | Artikelbezeichnung der Position. Bei NULL wird die Bezeichnung aus dem Artikelstamm verwendet. |\n| `ItemSpecialNote` | varchar(8000) | Nein | Sonderhinweis zur Position (`oItemSpecialNote`). |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer. Wird nur verwendet, wenn der Auftragskopf keine hat; sonst gilt der Kopfwert. Ohne beides wird eine Zeitstempel-Zeichenkette erzeugt. |\n| `DF_Type` | varchar(1) | Nein | Direct-Fulfillment-Typ, wird in `DF_type` der Position gespeichert. |\n| `SerialNumber` | varchar(50) | Nein | Seriennummer, wird in `SerialNr` der Position gespeichert. |\n\n- **Kein Ergebnis, wenn keine Positionen ergänzt werden dürfen:** Liefert `pipiCanAddOrderlines` 0 oder NULL, gibt der Aufruf überhaupt keine Zeilen zurück. Das ist der Fall, wenn der Auftrag nicht existiert oder eine Position bereits in einem sperrenden Status steht. Eine leere Antwort ist daher als „nicht angelegt“ zu werten.\n- **Doppelte Fehlerzeile:** Die Prüfung `UsePaymentStatus` = 1 mit `Status` ≠ `NEW` läuft zweimal, der Fehler erscheint daher doppelt im Ergebnis.\n- **Status wird nicht erneut geprüft:** Ein aus der Zahlungsart übernommener Status (`UsePaymentStatus` = 1) wird nicht gegen die erlaubte Liste geprüft.\n- **Artikelpreis erforderlich:** Der Artikel benötigt eine Preiszeile in der Datenbankwährung (Inner Join auf `pixi.ItemPrice`). Andernfalls werden Artikeldaten und Preise nicht gefüllt, und die Position kann ohne EAN oder Preis entstehen.\n- **Auftragskopf wird überschrieben:** `Pixi_InsertOrderline` aktualisiert die Kopffelder `GiftMessage`, `ShipInstruct`, `Discount`, `Address_Remarks`, `Verfahren`, `Product`, `Extras`, `Shipdate` und die Steuersätze.\n - `GiftMessage` hat den Standardwert '' und überschreibt damit eine vorhandene Geschenknachricht.\n - `ShipInstruct` wird auf '' und `Shipdate` auf NULL gesetzt.\n- **Gutscheinanlage:** Ist der resultierende `Discount` > 0 und existiert noch kein `Voucher`-Eintrag mit dieser ID, wird ein Gutschein mit Shop `GRM` und der Auftragswährung angelegt. Das Ablaufdatum wird mit `DATEADD(y, 1, …)` berechnet; der Datumsteil `y` steht für den Tag des Jahres, das Datum liegt also einen Tag nach dem Bestelldatum.\n- **Protokollierung:** Weicht `OrderNrExternal` vom Kopfwert ab, wird ein Eintrag in `LogTable` geschrieben.\n- **Transaktion:** Die Anlage erfolgt in einer Transaktion innerhalb von `Pixi_InsertOrderline`.\n- **Positions-ID:** Die neue ID wird aus einer temporären Tabelle gelesen, die ein `INSTEAD OF`-Trigger auf `Orderlines` füllt. Der Trigger liegt nicht vor. Wird keine ID geliefert, ist `OrderlineId` NULL, obwohl `CanAdd` = 1 ist.\n- **Lesezugriffe:** Alle Lesezugriffe verwenden `NOLOCK`.\n- **Wechselkurse:** Kurse werden nur für das aktuelle Datum gesucht. Fehlt ein Kurs für heute, werden umgerechnete Preise NULL.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAddOrderLine"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n true\n 104532\n \n 887321\n WEB-2024-000123\n \n"
}
]
},
{
"name": "pixiBreakOrderline",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n 2\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Teilt eine Auftragsposition in zwei Positionen auf, indem eine angegebene Menge in eine neue Auftragsposition übertragen wird, optional mit neuem Status.\n\nTeilt eine bestehende Auftragsposition, die über `OrderlineKey` angegeben wird, in zwei Auftragspositionen auf. Der Aufruf ist ein schlanker Wrapper um die interne Prozedur `GOSBreakOrderline`. Alle Parameter werden unverändert durchgereicht.\n\nAblauf:\n\n1. `GOSBreakOrderline` wird mit `OrderlineKey`, `NewQty`, `NewStatus`, `InvlineRef`, `UserName` und `BinRef` ausgeführt. Die internen Parameter `TermID`, `LargeOrderToBreak` und `PLHKey` behalten ihre Standardwerte.\n2. `GOSBreakOrderline` startet eine Transaktion oder setzt einen Savepoint, falls bereits eine Transaktion offen ist. Anschließend wird eine exklusive Anwendungssperre mit dem Namen `Orderline_` und 5 Sekunden Timeout angefordert. Danach erfolgt die eigentliche Aufteilung über `GOSBreakOrderline_Base`.\n3. Die innere Prozedur liefert eine Zeile mit `Success` und `NewOrderlineKey`. Der Wrapper speichert diese Zeile intern und gibt sie **nicht** an den Aufrufer weiter.\n4. Ist der gespeicherte Wert `Success` ungleich `1`, löst der Aufruf einen Fehler mit Schweregrad 11 aus.\n\nBei Erfolg liefert der Aufruf keine Ergebnismenge. Der Schlüssel der neu angelegten Auftragsposition wird nicht zurückgegeben. Er muss anschließend ermittelt werden, zum Beispiel durch erneutes Lesen der Auftragspositionen des Auftrags.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | integer | Ja | Schlüssel der Auftragsposition, die aufgeteilt werden soll. Wird auch für den Namen der Anwendungssperre `Orderline_` verwendet. |\n| `NewQty` | integer | Ja | Menge für die Aufteilung. Wird an `GOSBreakOrderline_Base` übergeben; die genaue Bedeutung wird dort festgelegt. |\n| `NewStatus` | varchar(3) | Nein | Optionaler Positionsstatus für die abgeteilte Position. Ein leerer String bedeutet, dass kein Status explizit vorgegeben wird. Die gültigen Werte werden in der inneren Prozedur geprüft. |\n| `InvlineRef` | int | Nein | Optionale Referenz auf eine Rechnungsposition, wird an die Aufteilungslogik durchgereicht. `0` bedeutet keine Referenz. |\n| `UserName` | varchar(50) | Nein | Name des Benutzers, der die Aufteilung ausführt, wird an die Aufteilungslogik durchgereicht. |\n| `BinRef` | int | Nein | Optionale Referenz auf einen Lagerplatz, wird an die Aufteilungslogik durchgereicht. |\n\n- Die eigentliche Aufteilungslogik liegt in `GOSBreakOrderline_Base`, das nicht beigefügt ist. Folgende Punkte lassen sich aus dem vorliegenden Code nicht ableiten: die genaue Bedeutung von `NewQty` (Menge der neuen oder der verbleibenden Position), die gültigen Werte von `NewStatus`, die Wirkung von `InvlineRef` und `BinRef` sowie die geänderten Tabellen.\n- `GOSBreakOrderline` verwendet pro Auftragsposition eine exklusive Anwendungssperre (`sp_getapplock`, 5 Sekunden Timeout). Gleichzeitige Aufteilungen derselben Position werden dadurch serialisiert. Kann die Sperre nicht erlangt werden, wird intern der Fehler `Could not obtain the lock` ausgelöst.\n- Fehler innerhalb von `GOSBreakOrderline` werden abgefangen. Die Transaktion wird zurückgerollt und der Fehler über `log.InsertError` protokolliert. Ob der ursprüngliche Fehler danach beim Aufrufer ankommt, hängt von `log.InsertError` ab, das nicht beigefügt ist.\n- Das Ergebnis der inneren Prozedur wird per `INSERT ... EXEC` übernommen. Ein `ROLLBACK` innerhalb eines `INSERT ... EXEC` kann selbst einen SQL-Server-Fehler verursachen. Fehler können daher mit einer anderen Meldung als erwartet auftreten.\n- Stolperfalle: Liefert die innere Prozedur keine Zeile, ergibt die Prüfung auf `Success` NULL. In diesem Fall wird kein Fehler ausgelöst, obwohl möglicherweise nichts aufgeteilt wurde.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiBreakOrderline"
},
"response": []
},
{
"name": "pixiCanAddOrderlines",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Prüft, ob einem Auftrag noch neue Auftragspositionen hinzugefügt werden dürfen, abhängig von Zahlungsart und Status der vorhandenen Positionen.\n\nErmittelt für den Auftrag `PixiOrderNr`, ob weitere Auftragspositionen hinzugefügt werden können. Das Ergebnis wird in den Output-Parameter `CanAdd` geschrieben, optional als Statuszeile zurückgegeben und zusätzlich als Rückgabewert der Prozedur verwendet.\n\nDer Auftragskopf (`OrderHeader`) wird mit seiner Adresse (`Addresses`, über `AddrRef`) verknüpft. Die Entscheidung hängt von der Zahlungsart-Spalte `APayment` ab:\n\n- **Zahlungsart ungleich `K` oder `C`**: `CanAdd = 1`, wenn der Auftrag **keine** Auftragspositionen mit Status `EIN` oder `AUS` hat. Sonst `0`.\n- **Zahlungsart `K` oder `C`**: `CanAdd = 1` nur, wenn **alle** Auftragspositionen einen der Status `NEW`, `ANG`, `HAL`, `MIN`, `OPH`, `BES`, `STO`, `NLB` haben. Sobald eine Position einen anderen Status hat, ist das Ergebnis `0`.\n- Ein Auftrag ohne Auftragspositionen liefert daher immer `1`, sofern eine Zahlungsart gesetzt ist.\n- Ist `APayment` `NULL`, trifft keine Bedingung zu und das Ergebnis ist `0`.\n\nBei `SupressOutput = 0` (Standard) wird eine Zeile mit `CanAdd`, `OrderNr` und `ErrorMessage` (immer `NULL`) zurückgegeben. Bei `SupressOutput = 1` wird keine Ergebnismenge geliefert; das Ergebnis steht dann nur im Output-Parameter und im Rückgabewert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PixiOrderNr` | int | Ja | Pixi-Auftragsnummer (`OrderHeader.OrderNr`) des zu prüfenden Auftrags. |\n| `CanAdd` | bit | Nein | Ausgabe: `1`, wenn Auftragspositionen hinzugefügt werden können, sonst `0`. Behält den übergebenen Wert, wenn der Auftrag nicht gefunden wird. |\n| `SupressOutput` | bit | Nein | Steuert, ob die Ergebniszeile zurückgegeben wird. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; das Ergebnis kann daher nicht festgeschriebene Änderungen widerspiegeln.\n- Existiert der Auftrag nicht (oder gibt es keinen passenden Adressdatensatz), wird kein Wert zugewiesen: `CanAdd` behält den übergebenen Wert (in der Regel `NULL`), und die zurückgegebene Zeile zeigt diesen Wert. Eine Fehlermeldung wird nicht erzeugt; `ErrorMessage` ist immer `NULL`. Ein `NULL` in `CanAdd` ist als „Auftrag nicht gefunden“ zu werten.\n- `CanAdd` ist als `OUTPUT` ohne Standardwert deklariert und muss daher im Request mitgesendet werden (z. B. leer oder `0`).\n- Die Spalte `APayment` wird ohne Tabellenalias referenziert und aus `OrderHeader` oder `Addresses` aufgelöst. Die Bedeutung der Zahlungsarten `K` und `C` ist im Code nicht festgelegt.\n- Auftragspositionen mit Status `NULL` werden bei der Prüfung für die Zahlungsarten `K`/`C` nicht berücksichtigt.\n- Die Prozedur ändert keine Daten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCanAddOrderlines"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Prüft, ob einem Auftrag noch neue Auftragspositionen hinzugefügt werden dürfen, abhängig von Zahlungsart und Status der vorhandenen Positionen.\n\nErmittelt für den Auftrag `PixiOrderNr`, ob weitere Auftragspositionen hinzugefügt werden können. Das Ergebnis wird in den Output-Parameter `CanAdd` geschrieben, optional als Statuszeile zurückgegeben und zusätzlich als Rückgabewert der Prozedur verwendet.\n\nDer Auftragskopf (`OrderHeader`) wird mit seiner Adresse (`Addresses`, über `AddrRef`) verknüpft. Die Entscheidung hängt von der Zahlungsart-Spalte `APayment` ab:\n\n- **Zahlungsart ungleich `K` oder `C`**: `CanAdd = 1`, wenn der Auftrag **keine** Auftragspositionen mit Status `EIN` oder `AUS` hat. Sonst `0`.\n- **Zahlungsart `K` oder `C`**: `CanAdd = 1` nur, wenn **alle** Auftragspositionen einen der Status `NEW`, `ANG`, `HAL`, `MIN`, `OPH`, `BES`, `STO`, `NLB` haben. Sobald eine Position einen anderen Status hat, ist das Ergebnis `0`.\n- Ein Auftrag ohne Auftragspositionen liefert daher immer `1`, sofern eine Zahlungsart gesetzt ist.\n- Ist `APayment` `NULL`, trifft keine Bedingung zu und das Ergebnis ist `0`.\n\nBei `SupressOutput = 0` (Standard) wird eine Zeile mit `CanAdd`, `OrderNr` und `ErrorMessage` (immer `NULL`) zurückgegeben. Bei `SupressOutput = 1` wird keine Ergebnismenge geliefert; das Ergebnis steht dann nur im Output-Parameter und im Rückgabewert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PixiOrderNr` | int | Ja | Pixi-Auftragsnummer (`OrderHeader.OrderNr`) des zu prüfenden Auftrags. |\n| `CanAdd` | bit | Nein | Ausgabe: `1`, wenn Auftragspositionen hinzugefügt werden können, sonst `0`. Behält den übergebenen Wert, wenn der Auftrag nicht gefunden wird. |\n| `SupressOutput` | bit | Nein | Steuert, ob die Ergebniszeile zurückgegeben wird. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; das Ergebnis kann daher nicht festgeschriebene Änderungen widerspiegeln.\n- Existiert der Auftrag nicht (oder gibt es keinen passenden Adressdatensatz), wird kein Wert zugewiesen: `CanAdd` behält den übergebenen Wert (in der Regel `NULL`), und die zurückgegebene Zeile zeigt diesen Wert. Eine Fehlermeldung wird nicht erzeugt; `ErrorMessage` ist immer `NULL`. Ein `NULL` in `CanAdd` ist als „Auftrag nicht gefunden“ zu werten.\n- `CanAdd` ist als `OUTPUT` ohne Standardwert deklariert und muss daher im Request mitgesendet werden (z. B. leer oder `0`).\n- Die Spalte `APayment` wird ohne Tabellenalias referenziert und aus `OrderHeader` oder `Addresses` aufgelöst. Die Bedeutung der Zahlungsarten `K` und `C` ist im Code nicht festgelegt.\n- Auftragspositionen mit Status `NULL` werden bei der Prüfung für die Zahlungsarten `K`/`C` nicht berücksichtigt.\n- Die Prozedur ändert keine Daten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCanAddOrderlines"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 104523\n \n"
}
]
},
{
"name": "pixiCanCancelOrderline",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Prüft, ob eine Auftragsposition noch storniert werden kann, und liefert 1 (ja) oder 0 (nein).\n\nSkalarfunktion, die eine einzelne Auftragsposition anhand von `OrderlineKey` prüft.\n\nDie Auftragsposition wird über ihren `Status` mit `OrderStates` verknüpft. Die Funktion liefert nur dann `1`, wenn **alle** folgenden Bedingungen erfüllt sind:\n\n- der Status der Auftragsposition ist kein Endstatus (`OrderStates.FinalState` ist `N` oder NULL),\n- der Status der Auftragsposition ist nicht `EIN`,\n- die Auftragsposition ist nicht in `BoxItems` referenziert (nicht in eine Kiste gepackt),\n- die Auftragsposition ist nicht in `InvLines` referenziert (nicht berechnet).\n\nIst eine dieser Bedingungen nicht erfüllt, liefert die Funktion `0`.\n\nDie Funktion prüft nur und ändert keine Daten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Ja | Schlüssel der zu prüfenden Auftragsposition (`Orderlines.OrderlineKey`). |\n\n- Das Ergebnis ist `NULL`, wenn keine Auftragsposition mit dem angegebenen Schlüssel existiert oder ihr `Status` keinen passenden Eintrag in `OrderStates` hat (Inner Join).\n- Alle Tabellen werden mit `NOLOCK` gelesen; das Ergebnis kann daher nicht festgeschriebene Daten widerspiegeln.\n- Die Prüfungen gegen `BoxItems` und `InvLines` verwenden `NOT IN`. Enthält `BoxItems.OrderLineRef` oder `InvLines.OrderlineRef` NULL-Werte, wird die Bedingung nie wahr und die Funktion liefert für jede Auftragsposition `0`.\n- Die Funktion storniert nichts, sondern zeigt nur an, ob eine Stornierung zulässig ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCanCancelOrderline"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Prüft, ob eine Auftragsposition noch storniert werden kann, und liefert 1 (ja) oder 0 (nein).\n\nSkalarfunktion, die eine einzelne Auftragsposition anhand von `OrderlineKey` prüft.\n\nDie Auftragsposition wird über ihren `Status` mit `OrderStates` verknüpft. Die Funktion liefert nur dann `1`, wenn **alle** folgenden Bedingungen erfüllt sind:\n\n- der Status der Auftragsposition ist kein Endstatus (`OrderStates.FinalState` ist `N` oder NULL),\n- der Status der Auftragsposition ist nicht `EIN`,\n- die Auftragsposition ist nicht in `BoxItems` referenziert (nicht in eine Kiste gepackt),\n- die Auftragsposition ist nicht in `InvLines` referenziert (nicht berechnet).\n\nIst eine dieser Bedingungen nicht erfüllt, liefert die Funktion `0`.\n\nDie Funktion prüft nur und ändert keine Daten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Ja | Schlüssel der zu prüfenden Auftragsposition (`Orderlines.OrderlineKey`). |\n\n- Das Ergebnis ist `NULL`, wenn keine Auftragsposition mit dem angegebenen Schlüssel existiert oder ihr `Status` keinen passenden Eintrag in `OrderStates` hat (Inner Join).\n- Alle Tabellen werden mit `NOLOCK` gelesen; das Ergebnis kann daher nicht festgeschriebene Daten widerspiegeln.\n- Die Prüfungen gegen `BoxItems` und `InvLines` verwenden `NOT IN`. Enthält `BoxItems.OrderLineRef` oder `InvLines.OrderlineRef` NULL-Werte, wird die Bedingung nie wahr und die Funktion liefert für jede Auftragsposition `0`.\n- Die Funktion storniert nichts, sondern zeigt nur an, ob eine Stornierung zulässig ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCanCancelOrderline"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n \n"
}
]
},
{
"name": "pixiCanCancelOrderline2",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Status einer Auftragsposition und ein Kennzeichen, ob die Auftragsposition noch storniert werden kann.\n\nPrüft, ob eine einzelne Auftragsposition storniert werden kann, und liefert dazu eine Zeile.\n\nDie in `OrderlineKey` angegebene Auftragsposition wird aus `Orderlines` gelesen und über den Statuscode mit `OrderStates` verknüpft. Die Zeile enthält den Schlüssel der Auftragsposition, den Statuscode, den Statustext und das Kennzeichen `CanCancel`.\n\n`CanCancel` ist nur dann `1`, wenn alle folgenden Bedingungen erfüllt sind:\n\n- der Status ist kein Endstatus (`FinalState` des Status ist `N` oder leer),\n- der Status ist nicht `EIN`,\n- die Auftragsposition wird in `BoxItems` nicht referenziert (es gibt keinen Box-Eintrag zu ihr),\n- die Auftragsposition wird in `InvLines` nicht referenziert (sie ist noch nicht berechnet).\n\nIn allen anderen Fällen ist `CanCancel` gleich `0`.\n\nDer Aufruf führt nur eine Prüfung durch. Es wird nichts storniert und es werden keine Daten geändert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Ja | Schlüssel der zu prüfenden Auftragsposition (`Orderlines.OrderlineKey`). |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen. Das Ergebnis kann nicht festgeschriebene Änderungen enthalten; daher empfiehlt sich eine erneute Prüfung unmittelbar vor der Stornierung.\n- Die Ergebnismenge ist leer, wenn die Auftragsposition nicht existiert oder ihr Statuscode keinen Eintrag in `OrderStates` hat (Inner Join).\n- Die Prüfungen gegen `BoxItems` und `InvLines` verwenden `NOT IN`-Unterabfragen. Enthält eine dieser Tabellen eine Zeile mit leerer (`NULL`) Referenz auf die Auftragsposition, ist die Bedingung nie erfüllt und `CanCancel` ist für jede Auftragsposition `0`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCanCancelOrderline2"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Status einer Auftragsposition und ein Kennzeichen, ob die Auftragsposition noch storniert werden kann.\n\nPrüft, ob eine einzelne Auftragsposition storniert werden kann, und liefert dazu eine Zeile.\n\nDie in `OrderlineKey` angegebene Auftragsposition wird aus `Orderlines` gelesen und über den Statuscode mit `OrderStates` verknüpft. Die Zeile enthält den Schlüssel der Auftragsposition, den Statuscode, den Statustext und das Kennzeichen `CanCancel`.\n\n`CanCancel` ist nur dann `1`, wenn alle folgenden Bedingungen erfüllt sind:\n\n- der Status ist kein Endstatus (`FinalState` des Status ist `N` oder leer),\n- der Status ist nicht `EIN`,\n- die Auftragsposition wird in `BoxItems` nicht referenziert (es gibt keinen Box-Eintrag zu ihr),\n- die Auftragsposition wird in `InvLines` nicht referenziert (sie ist noch nicht berechnet).\n\nIn allen anderen Fällen ist `CanCancel` gleich `0`.\n\nDer Aufruf führt nur eine Prüfung durch. Es wird nichts storniert und es werden keine Daten geändert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Ja | Schlüssel der zu prüfenden Auftragsposition (`Orderlines.OrderlineKey`). |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen. Das Ergebnis kann nicht festgeschriebene Änderungen enthalten; daher empfiehlt sich eine erneute Prüfung unmittelbar vor der Stornierung.\n- Die Ergebnismenge ist leer, wenn die Auftragsposition nicht existiert oder ihr Statuscode keinen Eintrag in `OrderStates` hat (Inner Join).\n- Die Prüfungen gegen `BoxItems` und `InvLines` verwenden `NOT IN`-Unterabfragen. Enthält eine dieser Tabellen eine Zeile mit leerer (`NULL`) Referenz auf die Auftragsposition, ist die Bedingung nie erfüllt und `CanCancel` ist für jede Auftragsposition `0`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCanCancelOrderline2"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 123456\n AUF\n Auftrag angelegt\n 1\n \n"
}
]
},
{
"name": "pixiCancelOrder",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Storniert alle offenen Auftragspositionen eines Auftrags, indem ihr Status auf `STO` (storniert) oder `NLB` (nicht lieferbar) gesetzt wird.\n\nSetzt den Status der Auftragspositionen des Auftrags `OrderNr` auf den Wert von `Status`.\n\n1. Ist `Status` leer oder `NULL`, wird `STO` verwendet.\n2. Nur `STO` und `NLB` sind zulässig. Bei jedem anderen Wert wird eine Zeile mit `ErrorMessage` geliefert und nichts geändert.\n3. Ausgewählt werden die Auftragspositionen des Auftrags, die alle folgenden Bedingungen erfüllen:\n - der aktuelle Status der Position ist kein Endstatus (`OrderStates.FinalState = 'Y'`);\n - keine Auftragsposition des Auftrags ist in `BoxItems` referenziert;\n - keine Auftragsposition des Auftrags ist in `InvLines` referenziert.\n4. Die ausgewählten Positionen erhalten den neuen `Status`. `UpdateDate` wird auf die aktuelle Zeit und `UpdateEmp` auf `API` gesetzt.\n5. Wurde mindestens eine Position geändert, wird eine Zeile mit `SuccessfulMessage` geliefert. Wurde keine Position geändert, liefert der Aufruf keine Ergebnismenge; der Rückgabewert der Prozedur ist dann `1` (bei Erfolg `0`).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Nummer des Auftrags, dessen Auftragspositionen storniert werden (`Orderlines.OrderNr`). |\n| `Status` | varchar(3) | Nein | Neuer Status für die Auftragspositionen. Leer oder `NULL` wird als `STO` behandelt. |\n\n- **Auftragsweite Prüfung:** Die Kommentare im Code deuten eine Prüfung pro Position an. Die Unterabfragen auf `BoxItems` und `InvLines` sind jedoch nur über die Auftragsnummer korreliert. Ist **irgendeine** Position des Auftrags bereits in einer Kiste oder auf einer Rechnung, wird **keine** Position storniert, nicht nur diese eine Position.\n- Positionen in einem Endstatus werden übersprungen. Ein erneuter Aufruf für einen bereits stornierten Auftrag liefert daher in der Regel keine Zeilen.\n- Wurde nichts geändert, wird keine Meldung geliefert (z. B. unbekannter Auftrag, alle Positionen im Endstatus, Positionen bereits in Kisten oder auf Rechnungen). Eine fehlende Zeile `SuccessfulMessage` ist als „nicht storniert“ zu werten.\n- Die Auswahl liest mit `NOLOCK`; das Update verwendet `ROWLOCK`. Es gibt keine explizite Transaktion.\n- Geändert wird nur der Status der Auftragspositionen. Auftragskopf und Reservierungen werden von dieser Prozedur nicht direkt angepasst.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCancelOrder"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Storniert alle offenen Auftragspositionen eines Auftrags, indem ihr Status auf `STO` (storniert) oder `NLB` (nicht lieferbar) gesetzt wird.\n\nSetzt den Status der Auftragspositionen des Auftrags `OrderNr` auf den Wert von `Status`.\n\n1. Ist `Status` leer oder `NULL`, wird `STO` verwendet.\n2. Nur `STO` und `NLB` sind zulässig. Bei jedem anderen Wert wird eine Zeile mit `ErrorMessage` geliefert und nichts geändert.\n3. Ausgewählt werden die Auftragspositionen des Auftrags, die alle folgenden Bedingungen erfüllen:\n - der aktuelle Status der Position ist kein Endstatus (`OrderStates.FinalState = 'Y'`);\n - keine Auftragsposition des Auftrags ist in `BoxItems` referenziert;\n - keine Auftragsposition des Auftrags ist in `InvLines` referenziert.\n4. Die ausgewählten Positionen erhalten den neuen `Status`. `UpdateDate` wird auf die aktuelle Zeit und `UpdateEmp` auf `API` gesetzt.\n5. Wurde mindestens eine Position geändert, wird eine Zeile mit `SuccessfulMessage` geliefert. Wurde keine Position geändert, liefert der Aufruf keine Ergebnismenge; der Rückgabewert der Prozedur ist dann `1` (bei Erfolg `0`).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Nummer des Auftrags, dessen Auftragspositionen storniert werden (`Orderlines.OrderNr`). |\n| `Status` | varchar(3) | Nein | Neuer Status für die Auftragspositionen. Leer oder `NULL` wird als `STO` behandelt. |\n\n- **Auftragsweite Prüfung:** Die Kommentare im Code deuten eine Prüfung pro Position an. Die Unterabfragen auf `BoxItems` und `InvLines` sind jedoch nur über die Auftragsnummer korreliert. Ist **irgendeine** Position des Auftrags bereits in einer Kiste oder auf einer Rechnung, wird **keine** Position storniert, nicht nur diese eine Position.\n- Positionen in einem Endstatus werden übersprungen. Ein erneuter Aufruf für einen bereits stornierten Auftrag liefert daher in der Regel keine Zeilen.\n- Wurde nichts geändert, wird keine Meldung geliefert (z. B. unbekannter Auftrag, alle Positionen im Endstatus, Positionen bereits in Kisten oder auf Rechnungen). Eine fehlende Zeile `SuccessfulMessage` ist als „nicht storniert“ zu werten.\n- Die Auswahl liest mit `NOLOCK`; das Update verwendet `ROWLOCK`. Es gibt keine explizite Transaktion.\n- Geändert wird nur der Status der Auftragspositionen. Auftragskopf und Reservierungen werden von dieser Prozedur nicht direkt angepasst.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCancelOrder"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Order was successfully canceled\n \n"
}
]
},
{
"name": "pixiCancelOrderline",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Storniert eine einzelne Auftragsposition oder eine ganze Bundle-Position oder setzt sie auf nicht lieferbar (`STO`/`NLB`), sofern sie nicht final, verpackt oder berechnet ist.\n\nSetzt den Status einer Auftragsposition oder einer Bundle-Position samt aller zugehörigen Auftragspositionen auf `STO` (storniert) oder `NLB` (nicht lieferbar).\n\n1. `Status` ist standardmäßig `STO`; ein leerer Wert oder NULL wird ebenfalls als `STO` behandelt.\n2. Der Wert `0` für `OrderlineKey` oder `BundleOrderlineKey` gilt als nicht übergeben. Fehlen beide Schlüssel, wird eine Fehlerzeile geliefert.\n3. Wird nur `OrderlineKey` übergeben und gehört diese Auftragsposition zu einer vorhandenen Bundle-Position (`BundleOrderlineRef`), wechselt der Aufruf auf diese Bundle-Position. Verarbeitet wird dann das **gesamte Bundle**, nicht nur die einzelne Position.\n4. Ist ein Bundle-Schlüssel bekannt (übergeben oder ermittelt), wird `OrderlineKey` ignoriert. Verarbeitet werden alle Auftragspositionen mit diesem `BundleOrderlineRef`.\n5. Aktualisiert werden nur Auftragspositionen, die alle folgenden Bedingungen erfüllen:\n - ihr aktueller Status ist kein Endstatus in `OrderStates` (`FinalState = 'Y'`)\n - sie liegen in keiner Box (`boxitems`)\n - sie stehen auf keiner Rechnungsposition (`Invlines`)\n7. Die ausgewählten Auftragspositionen erhalten den neuen `Status`, `UpdateEmp = 'API'` und das aktuelle Datum als `UpdateDate`. Die zugehörigen Bundle-Positionen werden ebenso aktualisiert.\n8. Bei Erfolg wird eine Zeile mit `SuccessfulMessage` geliefert. Der Text hängt davon ab, ob eine einzelne Auftragsposition oder ein Bundle storniert wurde.\n\nIst `Status` weder `STO` noch `NLB` oder erfüllt keine Auftragsposition die Bedingungen, wird eine Zeile mit `ErrorMessage` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Schlüssel der zu stornierenden Auftragsposition. `0` gilt als nicht übergeben. Gehört die Position zu einem Bundle, wird das gesamte Bundle verarbeitet. |\n| `Status` | varchar(3) | Nein | Neuer Status für die Auftragspositionen. Leer oder NULL bedeutet `STO`. |\n| `BundleOrderlineKey` | int | Nein | Schlüssel der Bundle-Position, deren Auftragspositionen storniert werden. Ist er gesetzt, wird `OrderlineKey` ignoriert. `0` gilt als nicht übergeben. |\n\n- Die Meldung `ONLY Status STO or NLB Allowed` wird auch geliefert, wenn der Status gültig ist, aber keine Auftragsposition die Bedingungen erfüllt. Das ist der Fall, wenn der Schlüssel nicht existiert oder alle Positionen final, verpackt oder berechnet sind. Der Text ist in diesem Fall irreführend.\n- Bei Bundles werden nur die passenden Auftragspositionen aktualisiert. Die Bundle-Position selbst erhält den neuen Status trotzdem, sobald mindestens eine ihrer Positionen passt. Verpackte, berechnete oder finale Positionen behalten ihren bisherigen Status.\n- Erfolgs- und Fehlermeldung kommen in unterschiedlich benannten Spalten (`ErrorMessage` bzw. `SuccessfulMessage`). Clients sollten prüfen, welche Spalte vorhanden ist.\n- Die Prüfungen lesen mit `NOLOCK`. Die beiden Updates laufen ohne explizite Transaktion.\n- Der Rückgabewert der Prozedur (0/1) ist nicht Teil der Ergebniszeilen.\n- Der Statuswert wird so geschrieben, wie er übergeben wurde. Der Vergleich mit `STO`/`NLB` hängt von der Collation der Datenbank ab.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCancelOrderline"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Storniert eine einzelne Auftragsposition oder eine ganze Bundle-Position oder setzt sie auf nicht lieferbar (`STO`/`NLB`), sofern sie nicht final, verpackt oder berechnet ist.\n\nSetzt den Status einer Auftragsposition oder einer Bundle-Position samt aller zugehörigen Auftragspositionen auf `STO` (storniert) oder `NLB` (nicht lieferbar).\n\n1. `Status` ist standardmäßig `STO`; ein leerer Wert oder NULL wird ebenfalls als `STO` behandelt.\n2. Der Wert `0` für `OrderlineKey` oder `BundleOrderlineKey` gilt als nicht übergeben. Fehlen beide Schlüssel, wird eine Fehlerzeile geliefert.\n3. Wird nur `OrderlineKey` übergeben und gehört diese Auftragsposition zu einer vorhandenen Bundle-Position (`BundleOrderlineRef`), wechselt der Aufruf auf diese Bundle-Position. Verarbeitet wird dann das **gesamte Bundle**, nicht nur die einzelne Position.\n4. Ist ein Bundle-Schlüssel bekannt (übergeben oder ermittelt), wird `OrderlineKey` ignoriert. Verarbeitet werden alle Auftragspositionen mit diesem `BundleOrderlineRef`.\n5. Aktualisiert werden nur Auftragspositionen, die alle folgenden Bedingungen erfüllen:\n - ihr aktueller Status ist kein Endstatus in `OrderStates` (`FinalState = 'Y'`)\n - sie liegen in keiner Box (`boxitems`)\n - sie stehen auf keiner Rechnungsposition (`Invlines`)\n7. Die ausgewählten Auftragspositionen erhalten den neuen `Status`, `UpdateEmp = 'API'` und das aktuelle Datum als `UpdateDate`. Die zugehörigen Bundle-Positionen werden ebenso aktualisiert.\n8. Bei Erfolg wird eine Zeile mit `SuccessfulMessage` geliefert. Der Text hängt davon ab, ob eine einzelne Auftragsposition oder ein Bundle storniert wurde.\n\nIst `Status` weder `STO` noch `NLB` oder erfüllt keine Auftragsposition die Bedingungen, wird eine Zeile mit `ErrorMessage` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Schlüssel der zu stornierenden Auftragsposition. `0` gilt als nicht übergeben. Gehört die Position zu einem Bundle, wird das gesamte Bundle verarbeitet. |\n| `Status` | varchar(3) | Nein | Neuer Status für die Auftragspositionen. Leer oder NULL bedeutet `STO`. |\n| `BundleOrderlineKey` | int | Nein | Schlüssel der Bundle-Position, deren Auftragspositionen storniert werden. Ist er gesetzt, wird `OrderlineKey` ignoriert. `0` gilt als nicht übergeben. |\n\n- Die Meldung `ONLY Status STO or NLB Allowed` wird auch geliefert, wenn der Status gültig ist, aber keine Auftragsposition die Bedingungen erfüllt. Das ist der Fall, wenn der Schlüssel nicht existiert oder alle Positionen final, verpackt oder berechnet sind. Der Text ist in diesem Fall irreführend.\n- Bei Bundles werden nur die passenden Auftragspositionen aktualisiert. Die Bundle-Position selbst erhält den neuen Status trotzdem, sobald mindestens eine ihrer Positionen passt. Verpackte, berechnete oder finale Positionen behalten ihren bisherigen Status.\n- Erfolgs- und Fehlermeldung kommen in unterschiedlich benannten Spalten (`ErrorMessage` bzw. `SuccessfulMessage`). Clients sollten prüfen, welche Spalte vorhanden ist.\n- Die Prüfungen lesen mit `NOLOCK`. Die beiden Updates laufen ohne explizite Transaktion.\n- Der Rückgabewert der Prozedur (0/1) ist nicht Teil der Ergebniszeilen.\n- Der Statuswert wird so geschrieben, wie er übergeben wurde. Der Vergleich mit `STO`/`NLB` hängt von der Collation der Datenbank ab.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCancelOrderline"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Orderline was successfully canceled\n \n"
}
]
},
{
"name": "pixiCanUpdateOrderline",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Status einer Auftragsposition und ob sie noch geändert bzw. storniert werden kann.\n\nSucht die über `OrderlineKey` angegebene Auftragsposition in `Orderlines` und verknüpft ihren Statuscode mit `OrderStates`, um den Statustext zu ermitteln.\n\nDie Spalte `CanCancel` ist nur dann `1`, wenn alle folgenden Bedingungen erfüllt sind:\n\n- der Status ist kein Endstatus (`FinalState` des Status ist `N` oder nicht gesetzt),\n- der Status ist nicht `EIN`,\n- die Auftragsposition ist in keinem Packstück-Eintrag referenziert (`boxitems.OrderLineRef`), d. h. sie wurde noch nicht verpackt,\n- die Auftragsposition ist in keiner Rechnungsposition referenziert (`Invlines.OrderLineRef`), d. h. sie wurde noch nicht berechnet.\n\nAndernfalls ist `CanCancel` gleich `0`.\n\nExistiert die Auftragsposition nicht oder hat ihr Status keinen Eintrag in `OrderStates` (Inner Join), wird keine Zeile zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Ja | Schlüssel der zu prüfenden Auftragsposition (`Orderlines.OrderlineKey`). |\n\nAlle Tabellen werden mit `NOLOCK` gelesen; das Ergebnis kann daher nicht festgeschriebene Daten widerspiegeln. Der Aufruf prüft nur und ändert die Auftragsposition nicht. Ein leeres Ergebnis bedeutet, dass der Positionsschlüssel unbekannt ist (oder sein Status in `OrderStates` fehlt), nicht dass eine Stornierung unmöglich ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCanUpdateOrderline"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Status einer Auftragsposition und ob sie noch geändert bzw. storniert werden kann.\n\nSucht die über `OrderlineKey` angegebene Auftragsposition in `Orderlines` und verknüpft ihren Statuscode mit `OrderStates`, um den Statustext zu ermitteln.\n\nDie Spalte `CanCancel` ist nur dann `1`, wenn alle folgenden Bedingungen erfüllt sind:\n\n- der Status ist kein Endstatus (`FinalState` des Status ist `N` oder nicht gesetzt),\n- der Status ist nicht `EIN`,\n- die Auftragsposition ist in keinem Packstück-Eintrag referenziert (`boxitems.OrderLineRef`), d. h. sie wurde noch nicht verpackt,\n- die Auftragsposition ist in keiner Rechnungsposition referenziert (`Invlines.OrderLineRef`), d. h. sie wurde noch nicht berechnet.\n\nAndernfalls ist `CanCancel` gleich `0`.\n\nExistiert die Auftragsposition nicht oder hat ihr Status keinen Eintrag in `OrderStates` (Inner Join), wird keine Zeile zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Ja | Schlüssel der zu prüfenden Auftragsposition (`Orderlines.OrderlineKey`). |\n\nAlle Tabellen werden mit `NOLOCK` gelesen; das Ergebnis kann daher nicht festgeschriebene Daten widerspiegeln. Der Aufruf prüft nur und ändert die Auftragsposition nicht. Ein leeres Ergebnis bedeutet, dass der Positionsschlüssel unbekannt ist (oder sein Status in `OrderStates` fehlt), nicht dass eine Stornierung unmöglich ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCanUpdateOrderline"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 123456\n AUF\n Offen\n 1\n \n"
}
]
},
{
"name": "pixiDeleteOrderline",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht eine Auftragsposition (bzw. das gesamte Bundle, zu dem sie gehört) und entfernt den Auftrag, wenn keine Positionen mehr übrig sind.\n\nLöscht die über `OrderlineKey` angegebene Auftragsposition innerhalb einer Transaktion.\n\n1. **Prüfung:** Die Position muss in `Orderlines` existieren und einen der Status `HAL`, `ANG`, `STO`, `NLB` oder `FUT` haben. Andernfalls wird eine `ERROR`-Zeile geliefert und nichts geändert.\n2. **Bundle-Behandlung:** Hat die Position eine `BundleOrderlineRef`, wird das **gesamte Bundle** gelöscht, nicht nur die angegebene Position.\n3. **Status-Rücksetzung:** Die Position (bzw. alle Positionen des Bundles) desselben Auftrags ohne `BoxNr` werden auf Status `NEW` mit `UpdateEmp` = `API` gesetzt.\n4. **Löschung:** Alle betroffenen Positionen im Status `NEW` werden vom Auftrag gelöst: `OrderNr`, `CustRef`, `AddrRef`, `ShipAdrRef`, `Qty`, Preise, Rabatte und `ShipCost` werden auf 0 gesetzt, `ItemRef`, `ShipRef`, `Order_Id` und `BundleOrderlineRef` auf NULL. Der Bundle-Kopf in `BundleOrderlines` wird gelöscht, sofern er den Status `NEW` hat. Reservierungen (`Reservation`) der betroffenen Positionen werden gelöscht.\n5. **Leerer Auftrag:** Hat der Auftrag danach keine Positionen mehr, wird der Auftragskopf samt seinen Einträgen in `PL_NotReservedOrdersCheck`, `TagMatch` und `OrderHeaderAttribute` gelöscht.\n\nDer Aufruf liefert genau eine Zeile mit `ReturnCode` (`OK` oder `ERROR`) und einem Text in `ErrorMessage`. Bei Bundles nennt der Erfolgstext sowohl die angegebene Position als auch den Bundle-Schlüssel.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Ja | Schlüssel der zu löschenden Auftragsposition. Sie muss den Status `HAL`, `ANG`, `STO`, `NLB` oder `FUT` haben. Gehört sie zu einem Bundle, wird das gesamte Bundle gelöscht. |\n\n- Alle Änderungen laufen in einer Transaktion; bei einem vom Aufruf abgefangenen Fehler wird sie zurückgerollt und eine `ERROR`-Zeile geliefert.\n- Die Positionszeilen werden **nicht physisch gelöscht**. Sie werden zurückgesetzt (`OrderNr` = 0 usw.); laut Code-Kommentar entfernt ein Job sie über Nacht. Dieser Job ist nicht Teil des Aufrufs.\n- Die Statusprüfung verwendet `NOLOCK` und kann daher nicht festgeschriebene Daten lesen.\n- Trigger auf `Orderlines` und `Reservation` werden während Update/Delete über `CONTEXT_INFO` unterdrückt.\n- Nur die angegebene Position wird auf einen zulässigen Status geprüft. Bei Bundles werden alle übrigen Komponenten ohne `BoxNr` unabhängig von ihrem Status auf `NEW` gesetzt und gelöscht. Positionen mit gesetzter `BoxNr` behalten ihren Status und werden nicht gelöscht.\n- Die aufgerufenen Unterprozeduren fangen eigene Fehler ab und protokollieren sie über `log.InsertError`, ohne sie weiterzugeben. Je nach Transaktionszustand erscheint ein Fehler darin als Transaktionszähler-Fehler in der `ERROR`-Zeile, oder der Aufruf meldet `OK`, obwohl der Teilschritt auf seinen Savepoint zurückgerollt wurde.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDeleteOrderline"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht eine Auftragsposition (bzw. das gesamte Bundle, zu dem sie gehört) und entfernt den Auftrag, wenn keine Positionen mehr übrig sind.\n\nLöscht die über `OrderlineKey` angegebene Auftragsposition innerhalb einer Transaktion.\n\n1. **Prüfung:** Die Position muss in `Orderlines` existieren und einen der Status `HAL`, `ANG`, `STO`, `NLB` oder `FUT` haben. Andernfalls wird eine `ERROR`-Zeile geliefert und nichts geändert.\n2. **Bundle-Behandlung:** Hat die Position eine `BundleOrderlineRef`, wird das **gesamte Bundle** gelöscht, nicht nur die angegebene Position.\n3. **Status-Rücksetzung:** Die Position (bzw. alle Positionen des Bundles) desselben Auftrags ohne `BoxNr` werden auf Status `NEW` mit `UpdateEmp` = `API` gesetzt.\n4. **Löschung:** Alle betroffenen Positionen im Status `NEW` werden vom Auftrag gelöst: `OrderNr`, `CustRef`, `AddrRef`, `ShipAdrRef`, `Qty`, Preise, Rabatte und `ShipCost` werden auf 0 gesetzt, `ItemRef`, `ShipRef`, `Order_Id` und `BundleOrderlineRef` auf NULL. Der Bundle-Kopf in `BundleOrderlines` wird gelöscht, sofern er den Status `NEW` hat. Reservierungen (`Reservation`) der betroffenen Positionen werden gelöscht.\n5. **Leerer Auftrag:** Hat der Auftrag danach keine Positionen mehr, wird der Auftragskopf samt seinen Einträgen in `PL_NotReservedOrdersCheck`, `TagMatch` und `OrderHeaderAttribute` gelöscht.\n\nDer Aufruf liefert genau eine Zeile mit `ReturnCode` (`OK` oder `ERROR`) und einem Text in `ErrorMessage`. Bei Bundles nennt der Erfolgstext sowohl die angegebene Position als auch den Bundle-Schlüssel.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Ja | Schlüssel der zu löschenden Auftragsposition. Sie muss den Status `HAL`, `ANG`, `STO`, `NLB` oder `FUT` haben. Gehört sie zu einem Bundle, wird das gesamte Bundle gelöscht. |\n\n- Alle Änderungen laufen in einer Transaktion; bei einem vom Aufruf abgefangenen Fehler wird sie zurückgerollt und eine `ERROR`-Zeile geliefert.\n- Die Positionszeilen werden **nicht physisch gelöscht**. Sie werden zurückgesetzt (`OrderNr` = 0 usw.); laut Code-Kommentar entfernt ein Job sie über Nacht. Dieser Job ist nicht Teil des Aufrufs.\n- Die Statusprüfung verwendet `NOLOCK` und kann daher nicht festgeschriebene Daten lesen.\n- Trigger auf `Orderlines` und `Reservation` werden während Update/Delete über `CONTEXT_INFO` unterdrückt.\n- Nur die angegebene Position wird auf einen zulässigen Status geprüft. Bei Bundles werden alle übrigen Komponenten ohne `BoxNr` unabhängig von ihrem Status auf `NEW` gesetzt und gelöscht. Positionen mit gesetzter `BoxNr` behalten ihren Status und werden nicht gelöscht.\n- Die aufgerufenen Unterprozeduren fangen eigene Fehler ab und protokollieren sie über `log.InsertError`, ohne sie weiterzugeben. Je nach Transaktionszustand erscheint ein Fehler darin als Transaktionszähler-Fehler in der `ERROR`-Zeile, oder der Aufruf meldet `OK`, obwohl der Teilschritt auf seinen Savepoint zurückgerollt wurde.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDeleteOrderline"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n Orderline with OrderlineKey 123456 has been deleted successfully.\n \n"
}
]
},
{
"name": "pixiEstimatedDeliveryUpdates",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Berechnet die voraussichtlichen Liefertermine von Auftragspositionen und Artikeln für einen Auftrag, eine Shop-Bestellnummer oder einen Artikel neu und stellt geänderte Artikel zum Export ein.\n\nWrapper um die interne Prozedur `Pixi_EstimatedDeliveryUpdates`.\n\n1. `OrderNr = 0`, `ShopOrderNr = ''` und `ItemRef = 0` werden als NULL behandelt.\n2. Sind alle drei Parameter NULL, endet der Aufruf sofort ohne jede Änderung. Eine vollständige Neuberechnung aller Artikel ist über diesen Aufruf nicht möglich.\n3. Andernfalls wird die interne Prozedur mit den übergebenen Werten ausgeführt.\n\n**Auswahl der Artikel**\n\n- `OrderNr`: Artikel der Auftragspositionen dieses Auftrags (nicht gelöscht, `OrderNr <> 0`) mit Status `ANG` oder `HAL` sowie Positionen, die zu einer Bundle-Position gehören.\n- `ShopOrderNr`: ebenso, abgeglichen über `Orderlines.OrderNrExternal`.\n- `ItemRef`: der Artikel selbst. Ist er ein Bundle, werden seine Bestandteile ergänzt und das Bundle wird ebenfalls neu berechnet.\n- Direkt berechnet werden nur Artikel, die keine Bundles sind. Wird kein Artikel gefunden, endet die Prozedur ohne Änderungen.\n\n**Berechnung** (Einstellung `EstimatedDeliveryCalcUsesFIFO`)\n\n- `1` (FIFO): Bestandseinheiten in Lagern mit `ParticipateInEstDelivery = 1` und offene Mengen bestätigter Lieferantenbestellpositionen (`IsOrderedConfirmed = 1`, mit voraussichtlichem Liefertermin, in teilnehmenden Lagern) werden Stück für Stück den offenen Auftragspositionen mit Status `ANG`/`HAL` zugeordnet. Die Positionen werden nach `AutoReservationDone` absteigend, Auftragsdatum und Positionsschlüssel sortiert. Jede Auftragsposition erhält den Termin ihrer zuletzt zugeordneten Einheit und die verwendete Lieferantenbestellposition (`RealSorderlineRef`). Bestand und Termine in der Vergangenheit ergeben das heutige Datum. Der Artikel erhält den Termin der nächsten Einheit, die nach allen offenen Positionen noch frei ist, oder NULL.\n- `0` (MAX) / `2` (MIN): der späteste bzw. früheste voraussichtliche Liefertermin bestätigter Lieferantenbestellpositionen mit teilnehmendem Lieferlager. Er wird nur verwendet, wenn er nach dem heutigen Datum liegt und noch offene Menge besteht. Alle Auftragspositionen des Artikels und der Artikel selbst erhalten diesen Termin.\n- Jeder andere Wert berechnet nichts.\n\n**Bereinigung und Bundles**\n\n- Sofern nicht alle drei Parameter gefüllt sind, werden vorhandene Einträge in `Orderline_EstimatedDelivery` und `Item_EstimatedDelivery` (Artikel ohne Bundles), die nicht neu berechnet wurden, auf NULL gesetzt und damit gelöscht.\n- Bundles erhalten den spätesten Termin ihrer Bestandteile. Hat ein Bestandteil keinen Termin, erhält das Bundle keinen Termin.\n\n**Speichern**\n\n- `Item_EstimatedDelivery` und `Orderline_EstimatedDelivery` werden per MERGE aktualisiert. Ein NULL-Ergebnis löscht die Zeile, ein geänderter Wert wird mit neuem Änderungsdatum aktualisiert, ein neuer Artikel bzw. eine neue Position wird eingefügt.\n- Geänderte Bundles sowie geänderte Artikel, die bereits einen Eintrag in `InvBinItemLog` haben, werden mit `ForceToExport = 1` in `pixi.ItemRecalculateStockQueue` eingestellt.\n- Geänderte Artikel ohne Eintrag in `InvBinItemLog` erhalten eine Log-Zeile mit Menge 0 und `UpdateEmp = 'AutoEstDelExp'`, damit sie exportiert werden.\n\nDer Aufruf liefert keine Ergebnismenge.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. Die Artikel der offenen Auftragspositionen dieses Auftrags werden neu berechnet. 0 wird als NULL behandelt. |\n| `ShopOrderNr` | varchar(50) | Nein | Externe Shop-Bestellnummer, abgeglichen über `Orderlines.OrderNrExternal`. Ein leerer String wird als NULL behandelt. |\n| `ItemRef` | int | Nein | Artikelschlüssel (`ItemKey`), der neu berechnet werden soll. Bei einem Bundle werden dessen Bestandteile einbezogen. 0 wird als NULL behandelt. |\n\n- **Fallstrick:** Der Bereinigungsschritt ist nicht auf den ausgewählten Auftrag oder Artikel beschränkt. Sofern nicht `OrderNr`, `ShopOrderNr` und `ItemRef` alle gefüllt sind, wird jeder Eintrag in `Orderline_EstimatedDelivery` und `Item_EstimatedDelivery` (Artikel ohne Bundles), der in diesem Lauf nicht neu berechnet wurde, systemweit gelöscht.\n- Ist an der Auswahl kein Bundle beteiligt, werden alle Bundles im System anhand der aktuellen Ergebnisse neu berechnet.\n- Im Modus MAX/MIN erhalten alle Auftragspositionen des Artikels den Termin, unabhängig von ihrem Status. Im FIFO-Modus werden nur offene Positionen mit Status `ANG`/`HAL` berücksichtigt.\n- Der Berechnungsmodus stammt aus der Einstellung `EstimatedDeliveryCalcUsesFIFO`, die zur Laufzeit über `fpixi_GetSetting` gelesen wird. Deren Definition liegt nicht vor.\n- Die Prozedur gibt 0 zurück, wenn nichts getan wurde, sonst 1. Die SOAP-Antwort enthält diesen Rückgabewert nicht als Zeile.\n- Es gibt keine explizite Transaktion. Lesezugriffe verwenden `NOLOCK`.\n- Der FIFO-Modus zerlegt Mengen über `dbo.Numbers` in einzelne Einheiten. Bei großen Mengen kann das langsam sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEstimatedDeliveryUpdates"
},
"response": []
},
{
"name": "pixiGetChangedOrderlines",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-03-11T00:00:00\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Statusänderungen von Auftragspositionen aus der Auftragshistorie seit einem Zeitpunkt, wahlweise alle Änderungen oder nur die letzte je Position.\n\nLiest Statusänderungen von Auftragspositionen aus der Auftragshistorie und liefert sie zusammen mit Artikel- und Auftragsreferenzen.\n\n- Es werden nur Historieneinträge mit `StatusChangeDate` >= `Since` geliefert. Ist `Since` `NULL`, wird das aktuelle Datum mit Uhrzeit (`GETDATE()`) verwendet.\n- `WholeHistory` = `1` (Standard): Alle passenden Historieneinträge werden geliefert, eine Auftragsposition kann also mehrfach erscheinen.\n- `WholeHistory` = `0`: Nur der Eintrag, dessen `StatusChangeDate` dem jüngsten `StatusChangeDate` dieser Auftragsposition in der gesamten Historie entspricht, wird geliefert. Liegt die letzte Änderung einer Position vor `Since`, erscheint sie nicht.\n- Historieneinträge werden mit der Auftragsposition und dem Artikel verknüpft (Inner Joins). Einträge ohne passende Auftragsposition oder ohne Artikel werden nicht geliefert.\n- Identische Zeilen werden zusammengefasst (`DISTINCT`).\n- Die Sortierung erfolgt aufsteigend nach `StatusChangeDate`.\n- `Rows` begrenzt die Anzahl der gelieferten Zeilen; `0` (Standard) oder `NULL` bedeutet keine Begrenzung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Ja | Beginn des Zeitfensters. Nur Historieneinträge mit `StatusChangeDate` >= diesem Wert werden geliefert. `NULL` wird durch das aktuelle Datum mit Uhrzeit ersetzt. |\n| `WholeHistory` | bit | Nein | Steuert, ob alle Statusänderungen oder nur die letzte Änderung je Auftragsposition geliefert werden. |\n| `Rows` | int | Nein | Maximale Anzahl gelieferter Zeilen. `0` oder `NULL` bedeutet keine Begrenzung. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Änderungen geliefert werden (Dirty Reads).\n- Wird `NULL` für `Since` übergeben, werden faktisch nur Änderungen ab dem Aufrufzeitpunkt geliefert, was in der Regel ein leeres Ergebnis ergibt.\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`; einen Offset gibt es nicht. Für inkrementelles Abfragen wird das höchste `StatusChangeDate` des letzten Aufrufs als nächstes `Since` verwendet. Da der Filter `>=` nutzt, werden Zeilen mit genau diesem Zeitstempel erneut geliefert und müssen vom Aufrufer dedupliziert werden (z. B. über `OrderlineKey` und `StatusChangeDate`). Haben mehr Zeilen denselben Zeitstempel als `Rows` erlaubt, kann das Abfragen hängen bleiben; daher einen ausreichend großen Wert für `Rows` wählen.\n- Bei `WholeHistory` = `0` sind dennoch mehrere Zeilen je Auftragsposition möglich, wenn mehrere Historieneinträge mit unterschiedlichem Status dasselbe jüngste `StatusChangeDate` haben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedOrderlines"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-03-11T00:00:00\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Statusänderungen von Auftragspositionen aus der Auftragshistorie seit einem Zeitpunkt, wahlweise alle Änderungen oder nur die letzte je Position.\n\nLiest Statusänderungen von Auftragspositionen aus der Auftragshistorie und liefert sie zusammen mit Artikel- und Auftragsreferenzen.\n\n- Es werden nur Historieneinträge mit `StatusChangeDate` >= `Since` geliefert. Ist `Since` `NULL`, wird das aktuelle Datum mit Uhrzeit (`GETDATE()`) verwendet.\n- `WholeHistory` = `1` (Standard): Alle passenden Historieneinträge werden geliefert, eine Auftragsposition kann also mehrfach erscheinen.\n- `WholeHistory` = `0`: Nur der Eintrag, dessen `StatusChangeDate` dem jüngsten `StatusChangeDate` dieser Auftragsposition in der gesamten Historie entspricht, wird geliefert. Liegt die letzte Änderung einer Position vor `Since`, erscheint sie nicht.\n- Historieneinträge werden mit der Auftragsposition und dem Artikel verknüpft (Inner Joins). Einträge ohne passende Auftragsposition oder ohne Artikel werden nicht geliefert.\n- Identische Zeilen werden zusammengefasst (`DISTINCT`).\n- Die Sortierung erfolgt aufsteigend nach `StatusChangeDate`.\n- `Rows` begrenzt die Anzahl der gelieferten Zeilen; `0` (Standard) oder `NULL` bedeutet keine Begrenzung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Ja | Beginn des Zeitfensters. Nur Historieneinträge mit `StatusChangeDate` >= diesem Wert werden geliefert. `NULL` wird durch das aktuelle Datum mit Uhrzeit ersetzt. |\n| `WholeHistory` | bit | Nein | Steuert, ob alle Statusänderungen oder nur die letzte Änderung je Auftragsposition geliefert werden. |\n| `Rows` | int | Nein | Maximale Anzahl gelieferter Zeilen. `0` oder `NULL` bedeutet keine Begrenzung. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Änderungen geliefert werden (Dirty Reads).\n- Wird `NULL` für `Since` übergeben, werden faktisch nur Änderungen ab dem Aufrufzeitpunkt geliefert, was in der Regel ein leeres Ergebnis ergibt.\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`; einen Offset gibt es nicht. Für inkrementelles Abfragen wird das höchste `StatusChangeDate` des letzten Aufrufs als nächstes `Since` verwendet. Da der Filter `>=` nutzt, werden Zeilen mit genau diesem Zeitstempel erneut geliefert und müssen vom Aufrufer dedupliziert werden (z. B. über `OrderlineKey` und `StatusChangeDate`). Haben mehr Zeilen denselben Zeitstempel als `Rows` erlaubt, kann das Abfragen hängen bleiben; daher einen ausreichend großen Wert für `Rows` wählen.\n- Bei `WholeHistory` = `0` sind dennoch mehrere Zeilen je Auftragsposition möglich, wenn mehrere Historieneinträge mit unterschiedlichem Status dasselbe jüngste `StatusChangeDate` haben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedOrderlines"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 100234\n WEB-2024-00815\n AUS\n 2024-03-11T09:15:22.000+01:00\n SKU-4711\n WEB\n 558812\n \n \n 100877\n WEB-2024-00816\n STO\n 2024-03-11T10:02:05.000+01:00\n SKU-0815\n WEB\n 558820\n \n"
}
]
},
{
"name": "pixiGetOrderline",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Auftragspositionen gefiltert nach Schlüssel, Auftrag, Status, Shop, Zahlungsart, Datum oder Rechnung, inkl. Preisen, MwSt., Versanddaten und verfügbarem Bestand.\n\nLiefert Auftragspositionen (`Orderlines`) und Bundle-Positionen (`BundleOrderlines`), die allen angegebenen Filtern entsprechen, sortiert nach `OrderlineKey`.\n\n**Normalisierung der Eingaben**\n- `OrderlineKey` und `OrderNR` mit Wert `0` sowie leere Strings bei Text- und Datumsparametern gelten als *nicht gesetzt*.\n- `RowCount` NULL wird zu `1000`.\n- Enthält `OrderNRExternal` `DROP`, `ALTER`, `DELETE`, `TRUNCATE` oder `UPDATE`, endet die Prozedur sofort ohne Ergebnismenge.\n\n**Filter** (UND-verknüpft, nur wenn gesetzt)\n- `OrderlineKey`, `OrderNR`, `OrderNRExternal`, `Status`: exakter Vergleich mit der Auftragsposition.\n- `ShopID`: `CustomerOF` des Kunden der Position.\n- `PaymentType`: `APayment` der Adresse der Position.\n- `OrderDateFrom`/`OrderDateTo` und `UpdateDateFrom`/`UpdateDateTo`: exklusive Grenzen (`>` und `<`).\n- `InvoiceNr`: nur Positionen, die als Rechnungsposition der Rechnung mit dieser Nummer vorkommen.\n\n**Bundle-Behandlung** (`ShowOrderlines`)\n- `1`: Bundles werden nicht als normale Artikel verarbeitet; alle Auftragspositionen inkl. der Bundle-Komponenten werden geliefert.\n- `0`: Bundles werden als normale Artikel verarbeitet; Komponentenpositionen (mit Bundle-Referenz) entfallen, die Bundle-Position selbst wird aus `BundleOrderlines` geliefert.\n- nicht gesetzt: Wert aus der Einstellung `ProcessBundleItemsAsNormalItems` (Standard `0`).\n\nBundle-Positionen werden mit denselben Filtern gesucht; Datums- und Rechnungsfilter werden gegen die Komponentenpositionen geprüft, und die Filter `OrderNR`/`OrderNRExternal` treffen Bundle-Positionen nur, wenn Bundles als normale Artikel verarbeitet werden.\n\n**Zeilenlimit**: Zuerst werden bis zu `RowCount` normale Auftragspositionen (aufsteigend nach `OrderlineKey`) gesammelt, danach füllen Bundle-Positionen das restliche Kontingent. Einen Offset gibt es nicht; für Paging eignen sich `OrderlineKey`- oder Datumsfilter.\n\n**Berechnete Werte**\n- `FullPrice` = `Qty` × `Price`; `FullPriceForItem` ist der gespeicherte Gesamtpreis der Position.\n- `VATRate` und `PriceNoVAT` (auf 2 Nachkommastellen gerundet) stammen aus der ersten Rechnungsposition, sonst aus der MwSt.-Klasse des Artikels (`H`, `L`, `N`) bzw. dem Nettopreis der Position.\n- `ShipDate` ist das Scan-Out-Datum der Rechnung (bzw. der referenzierten Rechnung).\n- `AvailStockOrderLine` = Bestand des Artikels am Lager der Position abzüglich der Anzahl früherer Reservierungen desselben Artikels durch Positionen in aktiven (nicht finalen) Status außer `EIN`, `FUT`, `FUS`.\n- `ReservedCount` = das Minimum aus `Qty` und `AvailStockOrderLine`, mindestens 0.\n\nBundle-Positionen enthalten keine Versand-, Bestands- oder Lieferterminangaben (NULL).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Schlüssel einer einzelnen Auftragsposition; 0 gilt als nicht gesetzt. |\n| `OrderNR` | int | Nein | Pixi-Auftragsnummer; 0 gilt als nicht gesetzt. |\n| `OrderNRExternal` | varchar(50) | Nein | Externe (Shop-)Auftragsnummer, exakter Vergleich. Werte mit DROP, ALTER, DELETE, TRUNCATE oder UPDATE beenden den Aufruf ohne Ergebnis. |\n| `Status` | varchar(3) | Nein | Statuscode der Auftragsposition (aus `OrderStates`). |\n| `ShopID` | varchar(3) | Nein | Shop-ID; Vergleich mit `CustomerOF` des Kunden der Position. |\n| `PaymentType` | char(1) | Nein | Zahlungsart; Vergleich mit `APayment` der Adresse der Position. |\n| `OrderDateFrom` | datetime | Nein | Nur Positionen mit Auftragsdatum echt nach diesem Wert. |\n| `OrderDateTo` | datetime | Nein | Nur Positionen mit Auftragsdatum echt vor diesem Wert. |\n| `UpdateDateFrom` | datetime | Nein | Nur Positionen, die echt nach diesem Zeitpunkt geändert wurden. |\n| `UpdateDateTo` | datetime | Nein | Nur Positionen, die echt vor diesem Zeitpunkt geändert wurden. |\n| `RowCount` | int | Nein | Maximale Anzahl Kandidatenpositionen (zuerst normale, dann Bundle-Positionen). NULL bedeutet 1000. |\n| `InvoiceNr` | varchar(50) | Nein | Nur Positionen, die in der Rechnung mit dieser Nummer enthalten sind. |\n| `ShowOrderlines` | bit | Nein | Steuert die Bundle-Behandlung. NULL verwendet die Einstellung `ProcessBundleItemsAsNormalItems`. |\n\n- Nur lesend; alle Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können erscheinen.\n- Die Filterabfrage wird als dynamisches SQL aufgebaut, aber parametrisiert über `sp_executesql` ausgeführt.\n- Die Schlüsselwortprüfung auf `OrderNRExternal` endet stillschweigend (keine Zeilen, kein Fehler) – eine externe Auftragsnummer, die z. B. `UPDATE` enthält, ist nicht suchbar.\n- `RowCount` begrenzt die Kandidaten vor den abschließenden Joins. Positionen ohne Auftragskopf, Währung, Artikel, Auftragsstatus oder `ItemLocationSpecific`-Eintrag für Artikel und Lager entfallen, daher können weniger Zeilen als `RowCount` zurückkommen.\n- Bei `ShowOrderlines` = 1 (oder Einstellung `0`) ohne Filter `OrderNR`/`OrderNRExternal` können Bundle-Positionen aus `BundleOrderlines` zusätzlich zu ihren Komponenten erscheinen.\n- `ReservedCount` ist bei Bundle-Positionen NULL, da `AvailStockOrderLine` dort NULL ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderline"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Auftragspositionen gefiltert nach Schlüssel, Auftrag, Status, Shop, Zahlungsart, Datum oder Rechnung, inkl. Preisen, MwSt., Versanddaten und verfügbarem Bestand.\n\nLiefert Auftragspositionen (`Orderlines`) und Bundle-Positionen (`BundleOrderlines`), die allen angegebenen Filtern entsprechen, sortiert nach `OrderlineKey`.\n\n**Normalisierung der Eingaben**\n- `OrderlineKey` und `OrderNR` mit Wert `0` sowie leere Strings bei Text- und Datumsparametern gelten als *nicht gesetzt*.\n- `RowCount` NULL wird zu `1000`.\n- Enthält `OrderNRExternal` `DROP`, `ALTER`, `DELETE`, `TRUNCATE` oder `UPDATE`, endet die Prozedur sofort ohne Ergebnismenge.\n\n**Filter** (UND-verknüpft, nur wenn gesetzt)\n- `OrderlineKey`, `OrderNR`, `OrderNRExternal`, `Status`: exakter Vergleich mit der Auftragsposition.\n- `ShopID`: `CustomerOF` des Kunden der Position.\n- `PaymentType`: `APayment` der Adresse der Position.\n- `OrderDateFrom`/`OrderDateTo` und `UpdateDateFrom`/`UpdateDateTo`: exklusive Grenzen (`>` und `<`).\n- `InvoiceNr`: nur Positionen, die als Rechnungsposition der Rechnung mit dieser Nummer vorkommen.\n\n**Bundle-Behandlung** (`ShowOrderlines`)\n- `1`: Bundles werden nicht als normale Artikel verarbeitet; alle Auftragspositionen inkl. der Bundle-Komponenten werden geliefert.\n- `0`: Bundles werden als normale Artikel verarbeitet; Komponentenpositionen (mit Bundle-Referenz) entfallen, die Bundle-Position selbst wird aus `BundleOrderlines` geliefert.\n- nicht gesetzt: Wert aus der Einstellung `ProcessBundleItemsAsNormalItems` (Standard `0`).\n\nBundle-Positionen werden mit denselben Filtern gesucht; Datums- und Rechnungsfilter werden gegen die Komponentenpositionen geprüft, und die Filter `OrderNR`/`OrderNRExternal` treffen Bundle-Positionen nur, wenn Bundles als normale Artikel verarbeitet werden.\n\n**Zeilenlimit**: Zuerst werden bis zu `RowCount` normale Auftragspositionen (aufsteigend nach `OrderlineKey`) gesammelt, danach füllen Bundle-Positionen das restliche Kontingent. Einen Offset gibt es nicht; für Paging eignen sich `OrderlineKey`- oder Datumsfilter.\n\n**Berechnete Werte**\n- `FullPrice` = `Qty` × `Price`; `FullPriceForItem` ist der gespeicherte Gesamtpreis der Position.\n- `VATRate` und `PriceNoVAT` (auf 2 Nachkommastellen gerundet) stammen aus der ersten Rechnungsposition, sonst aus der MwSt.-Klasse des Artikels (`H`, `L`, `N`) bzw. dem Nettopreis der Position.\n- `ShipDate` ist das Scan-Out-Datum der Rechnung (bzw. der referenzierten Rechnung).\n- `AvailStockOrderLine` = Bestand des Artikels am Lager der Position abzüglich der Anzahl früherer Reservierungen desselben Artikels durch Positionen in aktiven (nicht finalen) Status außer `EIN`, `FUT`, `FUS`.\n- `ReservedCount` = das Minimum aus `Qty` und `AvailStockOrderLine`, mindestens 0.\n\nBundle-Positionen enthalten keine Versand-, Bestands- oder Lieferterminangaben (NULL).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Schlüssel einer einzelnen Auftragsposition; 0 gilt als nicht gesetzt. |\n| `OrderNR` | int | Nein | Pixi-Auftragsnummer; 0 gilt als nicht gesetzt. |\n| `OrderNRExternal` | varchar(50) | Nein | Externe (Shop-)Auftragsnummer, exakter Vergleich. Werte mit DROP, ALTER, DELETE, TRUNCATE oder UPDATE beenden den Aufruf ohne Ergebnis. |\n| `Status` | varchar(3) | Nein | Statuscode der Auftragsposition (aus `OrderStates`). |\n| `ShopID` | varchar(3) | Nein | Shop-ID; Vergleich mit `CustomerOF` des Kunden der Position. |\n| `PaymentType` | char(1) | Nein | Zahlungsart; Vergleich mit `APayment` der Adresse der Position. |\n| `OrderDateFrom` | datetime | Nein | Nur Positionen mit Auftragsdatum echt nach diesem Wert. |\n| `OrderDateTo` | datetime | Nein | Nur Positionen mit Auftragsdatum echt vor diesem Wert. |\n| `UpdateDateFrom` | datetime | Nein | Nur Positionen, die echt nach diesem Zeitpunkt geändert wurden. |\n| `UpdateDateTo` | datetime | Nein | Nur Positionen, die echt vor diesem Zeitpunkt geändert wurden. |\n| `RowCount` | int | Nein | Maximale Anzahl Kandidatenpositionen (zuerst normale, dann Bundle-Positionen). NULL bedeutet 1000. |\n| `InvoiceNr` | varchar(50) | Nein | Nur Positionen, die in der Rechnung mit dieser Nummer enthalten sind. |\n| `ShowOrderlines` | bit | Nein | Steuert die Bundle-Behandlung. NULL verwendet die Einstellung `ProcessBundleItemsAsNormalItems`. |\n\n- Nur lesend; alle Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können erscheinen.\n- Die Filterabfrage wird als dynamisches SQL aufgebaut, aber parametrisiert über `sp_executesql` ausgeführt.\n- Die Schlüsselwortprüfung auf `OrderNRExternal` endet stillschweigend (keine Zeilen, kein Fehler) – eine externe Auftragsnummer, die z. B. `UPDATE` enthält, ist nicht suchbar.\n- `RowCount` begrenzt die Kandidaten vor den abschließenden Joins. Positionen ohne Auftragskopf, Währung, Artikel, Auftragsstatus oder `ItemLocationSpecific`-Eintrag für Artikel und Lager entfallen, daher können weniger Zeilen als `RowCount` zurückkommen.\n- Bei `ShowOrderlines` = 1 (oder Einstellung `0`) ohne Filter `OrderNR`/`OrderNRExternal` können Bundle-Positionen aus `BundleOrderlines` zusätzlich zu ihren Komponenten erscheinen.\n- `ReservedCount` ist bei Bundle-Positionen NULL, da `AvailStockOrderLine` dort NULL ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderline"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 154872\n T-Shirt Basic Blau M\n 2\n 19.9900\n AUF\n Auftrag\n TS-BL-M\n 200345\n SHOP-100234\n EUR\n 2024-01-15T10:22:00\n 2024-01-15T10:25:00\n 4711\n 0.0000\n 0.00\n 39.9800\n 39.9800\n H\n 16.8000\n 100045\n 5\n 4006381333931\n 2.0\n \n"
}
]
},
{
"name": "pixiGetOrderlineExtended",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Auftragspositionen und Bundle-Positionen mit Preisen, MwSt., Lagerverfügbarkeit, Reservierung, Versand- und Picklistendaten, gefiltert nach Auftrag, Artikel, Status, Shop, Zahlart oder Datum.\n\nLiefert erweiterte Daten zu Auftragspositionen. Alle Filter sind optional und werden mit UND verknüpft. Leere Strings sowie `0` bei `OrderlineKey`/`OrderNR` gelten als \"kein Filter\".\n\n**Artikelfilter (`ItemXML`)**: Artikel können über `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL` oder `EAN` angegeben werden. Alle passenden Artikelschlüssel werden gesammelt; es werden nur Auftragspositionen dieser Artikel geliefert.\n\n**Bundle-Behandlung (`ShowOrderlines`)**:\n- `1`: Bundles werden nicht als normale Artikel behandelt, die Komponenten-Positionen von Bundles sind enthalten.\n- `0`: Bundles werden als normale Artikel behandelt, Auftragspositionen, die zu einem Bundle gehören (`BundleOrderlineRef` gesetzt), werden ausgeschlossen.\n- nicht übergeben / `NULL`: Wert aus der Einstellung `ProcessBundleItemsAsNormalItems`.\n\n**Auswahlschritte**:\n1. Bis zu `RowCount` (Standard 1000) Zeilen aus `Orderlines`, die den Filtern entsprechen, sortiert nach `OrderlineKey`.\n2. Das verbleibende Zeilenkontingent wird mit Zeilen aus `BundleOrderlines` (gruppiert je Bundle-Position) aufgefüllt. Filter auf `OrderNR` und `OrderNRExternal` greifen bei Bundle-Positionen nur, wenn Bundles als normale Artikel verarbeitet werden; Datums- und Rechnungsfilter werden auf die Komponenten-Positionen angewendet.\n\n**Schlüsselfilter**: Bei `IsStartKey = 0` liefert `OrderlineKey` genau diese Position; bei `IsStartKey = 1` alle Positionen mit `OrderlineKey >=` dem Wert, was zusammen mit `RowCount` Paging ermöglicht.\n\n**Weitere Filter**: `Status` (Positionsstatus), `ShopID` (Shop des Kunden), `PaymentType` (Zahlart der Adresse), `OrderDateFrom`/`OrderDateTo` und `UpdateDateFrom`/`UpdateDateTo` (exklusive Grenzen), `InvoiceNr` (Position ist in dieser Rechnung enthalten).\n\n**Ersatzlieferungen (`IsReplacementOnly = 1`)**: Es werden nur Auftragspositionen mit Status `MIN` oder mit einem `MIN`-Eintrag in der Auftragshistorie geliefert.\n\n**Berechnete Werte**:\n- `AvailStockOrderLine`: Lagerbestand des Artikels am Lager der Position abzüglich der Anzahl früherer Reservierungen desselben Artikels unter den ausgewählten Positionen (gezählt werden nur Positionen in nicht finalen Status außer `EIN`, `FUT`, `FUS`).\n- `ReservedCount`: der kleinere Wert aus `Qty` und `AvailStockOrderLine`, mindestens 0.\n- `VATRate`, `PriceNoVAT`, `ShipDate` stammen aus der ersten Rechnungsposition der Auftragsposition, falls vorhanden, sonst aus Auftragsposition und Artikel.\n\nDas Ergebnis ist nach `OrderlineKey` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Schlüssel der Auftragsposition. Exakter Vergleich oder Startschlüssel je nach `IsStartKey`. `0` bedeutet kein Filter. |\n| `OrderNR` | int | Nein | Pixi-Auftragsnummer. `0` bedeutet kein Filter. |\n| `OrderNRExternal` | varchar(50) | Nein | Externe Auftragsnummer (Shop). |\n| `Status` | varchar(3) | Nein | Statuscode der Auftragsposition. |\n| `ShopID` | varchar(3) | Nein | Shop-ID; filtert auf den Shop des Kunden (`CustomerOF`). |\n| `PaymentType` | char(1) | Nein | Zahlart der Auftragsadresse (`APayment`). |\n| `OrderDateFrom` | datetime | Nein | Nur Positionen mit Auftragsdatum nach diesem Wert (exklusiv). |\n| `OrderDateTo` | datetime | Nein | Nur Positionen mit Auftragsdatum vor diesem Wert (exklusiv). |\n| `UpdateDateFrom` | datetime | Nein | Nur Positionen, die nach diesem Zeitpunkt geändert wurden (exklusiv). |\n| `UpdateDateTo` | datetime | Nein | Nur Positionen, die vor diesem Zeitpunkt geändert wurden (exklusiv). |\n| `RowCount` | int | Nein | Maximale Anzahl ausgewählter Positionen (zuerst Auftragspositionen, dann Bundle-Positionen). NULL bedeutet 1000. |\n| `InvoiceNr` | varchar(50) | Nein | Nur Positionen, die in der Rechnung mit dieser Nummer enthalten sind. |\n| `ShowOrderlines` | bit | Nein | Steuert die Behandlung von Bundle-Komponenten-Positionen. |\n| `IsStartKey` | bit | Nein | Legt fest, wie `OrderlineKey` verglichen wird. |\n| `ItemXML` | varchar(max) | Nein | Optionale Artikelliste als Filter; jedes `ITEM` kann `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL` oder `EAN` enthalten. |\n| `IsReplacementOnly` | bit | Nein | Schränkt normale Auftragspositionen auf Ersatzpositionen ein. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Die Auswahl wird als dynamisches SQL aufgebaut. Das Zeilenlimit stammt aus `RowCount` (NULL wird zu 1000); der Parameter `RowCount` selbst wird sonst nicht verwendet.\n- Wird `ItemXML` übergeben, aber keiner der angegebenen Artikel gefunden, wird **kein Artikelfilter angewendet** und es werden Positionen aller Artikel geliefert.\n- Ungültiges XML in `ItemXML` führt zu einem SQL-Fehler aus `sp_xml_preparedocument`.\n- Bei Bundle-Positionen ist der Schlüsselfilter immer ein exakter Vergleich (`IsStartKey` wird dort ignoriert).\n- `IsReplacementOnly` schränkt nur normale Auftragspositionen ein; ausgewählte Bundle-Positionen werden weiterhin geliefert.\n- Normale Auftragspositionen werden nur geliefert, wenn ein `ItemLocationSpecific`-Datensatz für Artikel und `LocationID` der Position existiert und Auftragskopf sowie Währung vorhanden sind.\n- Eine Position auf mehreren Picklisten erscheint einmal je Pickliste (`PicklistNr`).\n- Bei Bundle-Positionen sind `ShipDate`, `DFShipDate`, `DFShipmentTrackingID`, `AvailStockOrderLine`, `EstimatedDelivery` und damit `ReservedCount` NULL; `OrderDate`/`UpdateDate` stammen aus einer der Komponenten-Positionen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderlineExtended"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Auftragspositionen und Bundle-Positionen mit Preisen, MwSt., Lagerverfügbarkeit, Reservierung, Versand- und Picklistendaten, gefiltert nach Auftrag, Artikel, Status, Shop, Zahlart oder Datum.\n\nLiefert erweiterte Daten zu Auftragspositionen. Alle Filter sind optional und werden mit UND verknüpft. Leere Strings sowie `0` bei `OrderlineKey`/`OrderNR` gelten als \"kein Filter\".\n\n**Artikelfilter (`ItemXML`)**: Artikel können über `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL` oder `EAN` angegeben werden. Alle passenden Artikelschlüssel werden gesammelt; es werden nur Auftragspositionen dieser Artikel geliefert.\n\n**Bundle-Behandlung (`ShowOrderlines`)**:\n- `1`: Bundles werden nicht als normale Artikel behandelt, die Komponenten-Positionen von Bundles sind enthalten.\n- `0`: Bundles werden als normale Artikel behandelt, Auftragspositionen, die zu einem Bundle gehören (`BundleOrderlineRef` gesetzt), werden ausgeschlossen.\n- nicht übergeben / `NULL`: Wert aus der Einstellung `ProcessBundleItemsAsNormalItems`.\n\n**Auswahlschritte**:\n1. Bis zu `RowCount` (Standard 1000) Zeilen aus `Orderlines`, die den Filtern entsprechen, sortiert nach `OrderlineKey`.\n2. Das verbleibende Zeilenkontingent wird mit Zeilen aus `BundleOrderlines` (gruppiert je Bundle-Position) aufgefüllt. Filter auf `OrderNR` und `OrderNRExternal` greifen bei Bundle-Positionen nur, wenn Bundles als normale Artikel verarbeitet werden; Datums- und Rechnungsfilter werden auf die Komponenten-Positionen angewendet.\n\n**Schlüsselfilter**: Bei `IsStartKey = 0` liefert `OrderlineKey` genau diese Position; bei `IsStartKey = 1` alle Positionen mit `OrderlineKey >=` dem Wert, was zusammen mit `RowCount` Paging ermöglicht.\n\n**Weitere Filter**: `Status` (Positionsstatus), `ShopID` (Shop des Kunden), `PaymentType` (Zahlart der Adresse), `OrderDateFrom`/`OrderDateTo` und `UpdateDateFrom`/`UpdateDateTo` (exklusive Grenzen), `InvoiceNr` (Position ist in dieser Rechnung enthalten).\n\n**Ersatzlieferungen (`IsReplacementOnly = 1`)**: Es werden nur Auftragspositionen mit Status `MIN` oder mit einem `MIN`-Eintrag in der Auftragshistorie geliefert.\n\n**Berechnete Werte**:\n- `AvailStockOrderLine`: Lagerbestand des Artikels am Lager der Position abzüglich der Anzahl früherer Reservierungen desselben Artikels unter den ausgewählten Positionen (gezählt werden nur Positionen in nicht finalen Status außer `EIN`, `FUT`, `FUS`).\n- `ReservedCount`: der kleinere Wert aus `Qty` und `AvailStockOrderLine`, mindestens 0.\n- `VATRate`, `PriceNoVAT`, `ShipDate` stammen aus der ersten Rechnungsposition der Auftragsposition, falls vorhanden, sonst aus Auftragsposition und Artikel.\n\nDas Ergebnis ist nach `OrderlineKey` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Schlüssel der Auftragsposition. Exakter Vergleich oder Startschlüssel je nach `IsStartKey`. `0` bedeutet kein Filter. |\n| `OrderNR` | int | Nein | Pixi-Auftragsnummer. `0` bedeutet kein Filter. |\n| `OrderNRExternal` | varchar(50) | Nein | Externe Auftragsnummer (Shop). |\n| `Status` | varchar(3) | Nein | Statuscode der Auftragsposition. |\n| `ShopID` | varchar(3) | Nein | Shop-ID; filtert auf den Shop des Kunden (`CustomerOF`). |\n| `PaymentType` | char(1) | Nein | Zahlart der Auftragsadresse (`APayment`). |\n| `OrderDateFrom` | datetime | Nein | Nur Positionen mit Auftragsdatum nach diesem Wert (exklusiv). |\n| `OrderDateTo` | datetime | Nein | Nur Positionen mit Auftragsdatum vor diesem Wert (exklusiv). |\n| `UpdateDateFrom` | datetime | Nein | Nur Positionen, die nach diesem Zeitpunkt geändert wurden (exklusiv). |\n| `UpdateDateTo` | datetime | Nein | Nur Positionen, die vor diesem Zeitpunkt geändert wurden (exklusiv). |\n| `RowCount` | int | Nein | Maximale Anzahl ausgewählter Positionen (zuerst Auftragspositionen, dann Bundle-Positionen). NULL bedeutet 1000. |\n| `InvoiceNr` | varchar(50) | Nein | Nur Positionen, die in der Rechnung mit dieser Nummer enthalten sind. |\n| `ShowOrderlines` | bit | Nein | Steuert die Behandlung von Bundle-Komponenten-Positionen. |\n| `IsStartKey` | bit | Nein | Legt fest, wie `OrderlineKey` verglichen wird. |\n| `ItemXML` | varchar(max) | Nein | Optionale Artikelliste als Filter; jedes `ITEM` kann `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL` oder `EAN` enthalten. |\n| `IsReplacementOnly` | bit | Nein | Schränkt normale Auftragspositionen auf Ersatzpositionen ein. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Die Auswahl wird als dynamisches SQL aufgebaut. Das Zeilenlimit stammt aus `RowCount` (NULL wird zu 1000); der Parameter `RowCount` selbst wird sonst nicht verwendet.\n- Wird `ItemXML` übergeben, aber keiner der angegebenen Artikel gefunden, wird **kein Artikelfilter angewendet** und es werden Positionen aller Artikel geliefert.\n- Ungültiges XML in `ItemXML` führt zu einem SQL-Fehler aus `sp_xml_preparedocument`.\n- Bei Bundle-Positionen ist der Schlüsselfilter immer ein exakter Vergleich (`IsStartKey` wird dort ignoriert).\n- `IsReplacementOnly` schränkt nur normale Auftragspositionen ein; ausgewählte Bundle-Positionen werden weiterhin geliefert.\n- Normale Auftragspositionen werden nur geliefert, wenn ein `ItemLocationSpecific`-Datensatz für Artikel und `LocationID` der Position existiert und Auftragskopf sowie Währung vorhanden sind.\n- Eine Position auf mehreren Picklisten erscheint einmal je Pickliste (`PicklistNr`).\n- Bei Bundle-Positionen sind `ShipDate`, `DFShipDate`, `DFShipmentTrackingID`, `AvailStockOrderLine`, `EstimatedDelivery` und damit `ReservedCount` NULL; `OrderDate`/`UpdateDate` stammen aus einer der Komponenten-Positionen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderlineExtended"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 123456\n T-Shirt Blue M\n 2\n 19.9900\n AUF\n Offen\n TS-BL-M\n 500123\n WEB-100045\n EUR\n 2024-01-15T10:22:00\n 2024-01-15T11:05:00\n 4711\n 0.0000\n 0.00\n 39.9800\n 39.9800\n H\n 16.8000\n ART-1001\n 14\n 4006381333931\n 2.0\n 001\n 6.3800\n 19.000\n OPEN\n 8812\n \n"
}
]
},
{
"name": "pixiGetOrderlineHistory",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Statushistorie einer einzelnen Auftragsposition in chronologischer Reihenfolge.\n\nLiest alle Einträge aus der Tabelle `orderhistory`, die zur in `OrderlineKey` angegebenen Auftragsposition gehören (Spalte `OrderLineRef`).\n\nFür jede Statusänderung werden geliefert:\n- das Datum der Änderung,\n- der gesetzte Status,\n- der Benutzer, der die Änderung vorgenommen hat,\n- ob der Kunde benachrichtigt wurde,\n- der Schlüssel des Historieneintrags.\n\nDie Zeilen sind nach `StatusChangeDate` aufsteigend sortiert, der älteste Eintrag steht zuerst. Hat die Auftragsposition keine Historieneinträge oder existiert sie nicht, wird eine leere Ergebnismenge geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Ja | Schlüssel der Auftragsposition, deren Statushistorie geliefert wird (Abgleich mit `OrderLineRef` in `orderhistory`). |\n\n- Die Tabelle wird mit `NOLOCK` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein.\n- Bei einem unbekannten Positionsschlüssel wird kein Fehler gemeldet; die Ergebnismenge ist dann leer.\n- Die Spalte `UpdateEmp` wird als `UpdateUser` und `OrderHistKey` als `OrderlineHistKey` ausgegeben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderlineHistory"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Statushistorie einer einzelnen Auftragsposition in chronologischer Reihenfolge.\n\nLiest alle Einträge aus der Tabelle `orderhistory`, die zur in `OrderlineKey` angegebenen Auftragsposition gehören (Spalte `OrderLineRef`).\n\nFür jede Statusänderung werden geliefert:\n- das Datum der Änderung,\n- der gesetzte Status,\n- der Benutzer, der die Änderung vorgenommen hat,\n- ob der Kunde benachrichtigt wurde,\n- der Schlüssel des Historieneintrags.\n\nDie Zeilen sind nach `StatusChangeDate` aufsteigend sortiert, der älteste Eintrag steht zuerst. Hat die Auftragsposition keine Historieneinträge oder existiert sie nicht, wird eine leere Ergebnismenge geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Ja | Schlüssel der Auftragsposition, deren Statushistorie geliefert wird (Abgleich mit `OrderLineRef` in `orderhistory`). |\n\n- Die Tabelle wird mit `NOLOCK` gelesen, daher können nicht festgeschriebene Änderungen sichtbar sein.\n- Bei einem unbekannten Positionsschlüssel wird kein Fehler gemeldet; die Ergebnismenge ist dann leer.\n- Die Spalte `UpdateEmp` wird als `UpdateUser` und `OrderHistKey` als `OrderlineHistKey` ausgegeben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderlineHistory"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 2024-03-11T09:15:22\n AUF\n API\n 0\n 987001\n \n \n 2024-03-12T14:02:10\n AUS\n lager01\n 1\n 987245\n \n"
}
]
},
{
"name": "pixiGetOrderlinesForOrder",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100234\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Auftragspositionen eines oder mehrerer Aufträge, optional mit zusammengefassten Stücklisten-Positionen, inklusive Bestands-, Rechnungs- und Versanddaten.\n\nErmittelt die zu lesenden Aufträge und liefert deren Auftragspositionen in einer Ergebnismenge.\n\n**Auswahl der Aufträge**\n- Der Auftrag mit `OrderNr` = `@OrderNr` wird immer berücksichtigt (sofern vorhanden).\n- Ist `@OrderXML` angegeben, wird jedes Element `/ORDERS/ORDER` (elementbasiert) mit den Unterelementen `ORDERNR` und `ORDERNREXTERNAL` gelesen. Jeder Auftrag, dessen `OrderNr` zu `ORDERNR` **oder** dessen `OrderNrExternal` zu `ORDERNREXTERNAL` passt, wird hinzugefügt.\n\n**Stücklisten-Modus**\n- `@ReturnBundle` bestimmt den Modus. Ist der Wert `NULL`, wird die Einstellung `APIBundleOrderlines` verwendet (fehlende Einstellung = `0`).\n- `0`: Jede Auftragsposition wird mit ihren eigenen Werten geliefert (`ArtName`, `Qty`, `Price`, `Status`, ...).\n- `1`: Auftragspositionen, die zu einer Stückliste gehören (`BundleOrderlineRef` gesetzt), werden zu einer Zeile pro Stückliste zusammengefasst (die Position mit der kleinsten `OrderlineKey`). Bezeichnung, Menge, Preis, externe Nummern, Datum, Artikel, Notiz, Rabatte, Betrag, Steuersatz und Nettopreis werden, soweit vorhanden, aus der Stücklisten-Position (`BundleOrderlines`) übernommen. Der Status der Stückliste wird abhängig von der Einstellung `APIBundleOneAllAUS` aus allen zugehörigen Positionen berechnet: Bei `1` wird der gemeinsame Status geliefert, wenn alle Positionen denselben Status haben, sonst der Status mit der kleinsten `OrderStateKey`; bei `0` der Status mit der größten `OrderStateKey`.\n\n**Berechnete Spalten**\n- `StatusText`: Text des Status aus `OrderStates`.\n- `OrderCurrency`: Währungscode (`CodeA`) des Auftrags.\n- `VATRate`: `H`, wenn der Steuersatz der Rechnungsposition (bzw. der Stückliste) dem `TaxRateHigh` des Auftrags entspricht, `L` bei `TaxRateLow`, sonst `N` (auch wenn keine Rechnungsposition existiert).\n- `PriceNoVAT`: Nettopreis der Rechnungsposition (bzw. der Stückliste), auf 2 Nachkommastellen gerundet.\n- `AvailStockOrderLine`: verfügbare Menge des Artikels am Lager der Position (Lagermenge abzüglich offener Reservierungen des Artikels).\n- `ReservedCount`: der kleinere Wert aus `Qty` und `AvailStockOrderLine`, jedoch nicht kleiner als 0.\n- `ShipDate`: `ScanOutDate` der zugehörigen Rechnung.\n\nDas Ergebnis hat keine explizite Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Pixi-Auftragsnummer (`OrderHeader.OrderNr`), deren Auftragspositionen geliefert werden. |\n| `OrderXML` | varchar(max) | Nein | Optionales XML mit weiteren Aufträgen, zugeordnet über `ORDERNR` oder `ORDERNREXTERNAL`. |\n| `ReturnBundle` | bit | Nein | Steuert, ob Stücklisten-Positionen zusammengefasst werden. `NULL` verwendet die Einstellung `APIBundleOrderlines`. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; nicht festgeschriebene Daten können geliefert werden.\n- `@OrderNr` hat keinen Standardwert und muss immer übergeben werden. Wird nur `@OrderXML` verwendet, kann eine nicht existierende Nummer (z. B. `0`) übergeben werden.\n- Wird derselbe Auftrag sowohl über `@OrderNr` als auch über `@OrderXML` ausgewählt, wird sein Schlüssel doppelt übernommen und seine Positionen erscheinen doppelt im Ergebnis.\n- Auftragspositionen mit mehreren Rechnungspositionen mit `ItemQty` >= 0 können mehrfach erscheinen (eine Zeile pro Rechnungsposition). Rechnungspositionen mit negativer Menge (Retouren) werden ignoriert.\n- Im Stücklisten-Modus werden nur Positionen mit `BundleOrderlineRef IS NULL` oder die erste Position einer Partition geliefert. Speichern Nicht-Stücklisten-Positionen `0` statt `NULL` in `BundleOrderlineRef`, würden sie zusammengefasst und nur eine davon geliefert; das hängt von den Daten ab und ist im Code nicht erkennbar.\n- `AvailStockOrderLine` zieht die Anzahl der Reservierungszeilen des Artikels über alle Aufträge ab (offene Status außer `EIN`, `FUT`, `FUS`), nicht pro Lager. Der Wert ist `NULL`, wenn für den Artikel kein `ItemLocationSpecific`-Eintrag für das Lager existiert; dann ist auch `ReservedCount` `NULL`.\n- `PriceNoVAT` ist für noch nicht berechnete Positionen `NULL` (sofern nicht aus einer Stücklisten-Position übernommen).\n- Ungültiges XML in `@OrderXML` führt zu einem SQL-Fehler von `sp_xml_preparedocument`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderlinesForOrder"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100234\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Auftragspositionen eines oder mehrerer Aufträge, optional mit zusammengefassten Stücklisten-Positionen, inklusive Bestands-, Rechnungs- und Versanddaten.\n\nErmittelt die zu lesenden Aufträge und liefert deren Auftragspositionen in einer Ergebnismenge.\n\n**Auswahl der Aufträge**\n- Der Auftrag mit `OrderNr` = `@OrderNr` wird immer berücksichtigt (sofern vorhanden).\n- Ist `@OrderXML` angegeben, wird jedes Element `/ORDERS/ORDER` (elementbasiert) mit den Unterelementen `ORDERNR` und `ORDERNREXTERNAL` gelesen. Jeder Auftrag, dessen `OrderNr` zu `ORDERNR` **oder** dessen `OrderNrExternal` zu `ORDERNREXTERNAL` passt, wird hinzugefügt.\n\n**Stücklisten-Modus**\n- `@ReturnBundle` bestimmt den Modus. Ist der Wert `NULL`, wird die Einstellung `APIBundleOrderlines` verwendet (fehlende Einstellung = `0`).\n- `0`: Jede Auftragsposition wird mit ihren eigenen Werten geliefert (`ArtName`, `Qty`, `Price`, `Status`, ...).\n- `1`: Auftragspositionen, die zu einer Stückliste gehören (`BundleOrderlineRef` gesetzt), werden zu einer Zeile pro Stückliste zusammengefasst (die Position mit der kleinsten `OrderlineKey`). Bezeichnung, Menge, Preis, externe Nummern, Datum, Artikel, Notiz, Rabatte, Betrag, Steuersatz und Nettopreis werden, soweit vorhanden, aus der Stücklisten-Position (`BundleOrderlines`) übernommen. Der Status der Stückliste wird abhängig von der Einstellung `APIBundleOneAllAUS` aus allen zugehörigen Positionen berechnet: Bei `1` wird der gemeinsame Status geliefert, wenn alle Positionen denselben Status haben, sonst der Status mit der kleinsten `OrderStateKey`; bei `0` der Status mit der größten `OrderStateKey`.\n\n**Berechnete Spalten**\n- `StatusText`: Text des Status aus `OrderStates`.\n- `OrderCurrency`: Währungscode (`CodeA`) des Auftrags.\n- `VATRate`: `H`, wenn der Steuersatz der Rechnungsposition (bzw. der Stückliste) dem `TaxRateHigh` des Auftrags entspricht, `L` bei `TaxRateLow`, sonst `N` (auch wenn keine Rechnungsposition existiert).\n- `PriceNoVAT`: Nettopreis der Rechnungsposition (bzw. der Stückliste), auf 2 Nachkommastellen gerundet.\n- `AvailStockOrderLine`: verfügbare Menge des Artikels am Lager der Position (Lagermenge abzüglich offener Reservierungen des Artikels).\n- `ReservedCount`: der kleinere Wert aus `Qty` und `AvailStockOrderLine`, jedoch nicht kleiner als 0.\n- `ShipDate`: `ScanOutDate` der zugehörigen Rechnung.\n\nDas Ergebnis hat keine explizite Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Pixi-Auftragsnummer (`OrderHeader.OrderNr`), deren Auftragspositionen geliefert werden. |\n| `OrderXML` | varchar(max) | Nein | Optionales XML mit weiteren Aufträgen, zugeordnet über `ORDERNR` oder `ORDERNREXTERNAL`. |\n| `ReturnBundle` | bit | Nein | Steuert, ob Stücklisten-Positionen zusammengefasst werden. `NULL` verwendet die Einstellung `APIBundleOrderlines`. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; nicht festgeschriebene Daten können geliefert werden.\n- `@OrderNr` hat keinen Standardwert und muss immer übergeben werden. Wird nur `@OrderXML` verwendet, kann eine nicht existierende Nummer (z. B. `0`) übergeben werden.\n- Wird derselbe Auftrag sowohl über `@OrderNr` als auch über `@OrderXML` ausgewählt, wird sein Schlüssel doppelt übernommen und seine Positionen erscheinen doppelt im Ergebnis.\n- Auftragspositionen mit mehreren Rechnungspositionen mit `ItemQty` >= 0 können mehrfach erscheinen (eine Zeile pro Rechnungsposition). Rechnungspositionen mit negativer Menge (Retouren) werden ignoriert.\n- Im Stücklisten-Modus werden nur Positionen mit `BundleOrderlineRef IS NULL` oder die erste Position einer Partition geliefert. Speichern Nicht-Stücklisten-Positionen `0` statt `NULL` in `BundleOrderlineRef`, würden sie zusammengefasst und nur eine davon geliefert; das hängt von den Daten ab und ist im Code nicht erkennbar.\n- `AvailStockOrderLine` zieht die Anzahl der Reservierungszeilen des Artikels über alle Aufträge ab (offene Status außer `EIN`, `FUT`, `FUS`), nicht pro Lager. Der Wert ist `NULL`, wenn für den Artikel kein `ItemLocationSpecific`-Eintrag für das Lager existiert; dann ist auch `ReservedCount` `NULL`.\n- `PriceNoVAT` ist für noch nicht berechnete Positionen `NULL` (sofern nicht aus einer Stücklisten-Position übernommen).\n- Ungültiges XML in `@OrderXML` führt zu einem SQL-Fehler von `sp_xml_preparedocument`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderlinesForOrder"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 553201\n Laufschuh Pro 42\n 1\n 89.9000\n AUS\n Ausgeliefert\n LS-PRO-42\n 100234\n SHOP-4711\n EUR\n 2024-03-12T10:15:00\n 8812\n \n 0.0000\n 0\n 89.9000\n H\n 75.55\n 14\n 100-8812\n 2024-03-13T14:02:00\n 1\n SUP-77812\n \n"
}
]
},
{
"name": "pixiGetText",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n ORDERLINE_STATUS\n AU\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Klartext zu einem Objektcode; derzeit wird nur der Status von Auftragspositionen (`ORDERLINE_STATUS`) unterstützt.\n\nSkalarfunktion, die einen Code in den zugehörigen Text übersetzt.\n\n- Ist `ObjectType` gleich `ORDERLINE_STATUS` (ohne Beachtung der Groß-/Kleinschreibung, Vergleich über `UPPER`), wird in `OrderStates` die Zeile gesucht, deren `State` dem Wert von `ObjectId` entspricht, und deren `StateText` zurückgegeben.\n- Bei jedem anderen `ObjectType` oder wenn kein passender Status existiert, liefert die Funktion `NULL`.\n\nDas Ergebnis ist ein einzelner Wert vom Typ `varchar(1024)`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ObjectType` | varchar(100) | Ja | Art des Objekts, dessen Text abgefragt wird. Vergleich ohne Beachtung der Groß-/Kleinschreibung. |\n| `ObjectId` | varchar(100) | Ja | Code des Objekts, bei `ORDERLINE_STATUS` der Statuscode (`State`) der Auftragsposition. |\n\n- Die Abfrage verwendet `NOLOCK`, daher können nicht festgeschriebene Daten gelesen werden.\n- `ObjectId` wird als `varchar(100)` übergeben und mit `State` verglichen; eine implizite Konvertierung hängt vom Spaltentyp von `State` ab, der im Code nicht sichtbar ist.\n- Treffen mehrere Zeilen zu, wird der Wert der zuletzt gelesenen Zeile zurückgegeben (Variablenzuweisung im `SELECT`).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetText"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n ORDERLINE_STATUS\n AU\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Klartext zu einem Objektcode; derzeit wird nur der Status von Auftragspositionen (`ORDERLINE_STATUS`) unterstützt.\n\nSkalarfunktion, die einen Code in den zugehörigen Text übersetzt.\n\n- Ist `ObjectType` gleich `ORDERLINE_STATUS` (ohne Beachtung der Groß-/Kleinschreibung, Vergleich über `UPPER`), wird in `OrderStates` die Zeile gesucht, deren `State` dem Wert von `ObjectId` entspricht, und deren `StateText` zurückgegeben.\n- Bei jedem anderen `ObjectType` oder wenn kein passender Status existiert, liefert die Funktion `NULL`.\n\nDas Ergebnis ist ein einzelner Wert vom Typ `varchar(1024)`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ObjectType` | varchar(100) | Ja | Art des Objekts, dessen Text abgefragt wird. Vergleich ohne Beachtung der Groß-/Kleinschreibung. |\n| `ObjectId` | varchar(100) | Ja | Code des Objekts, bei `ORDERLINE_STATUS` der Statuscode (`State`) der Auftragsposition. |\n\n- Die Abfrage verwendet `NOLOCK`, daher können nicht festgeschriebene Daten gelesen werden.\n- `ObjectId` wird als `varchar(100)` übergeben und mit `State` verglichen; eine implizite Konvertierung hängt vom Spaltentyp von `State` ab, der im Code nicht sichtbar ist.\n- Treffen mehrere Zeilen zu, wird der Wert der zuletzt gelesenen Zeile zurückgegeben (Variablenzuweisung im `SELECT`).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetText"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Ausgeliefert\n \n"
}
]
},
{
"name": "pixiReadBundleOrderlines",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Bundle-Auftragspositionen aus `BundleOrderlines`, gefiltert nach Anlage- und/oder Änderungsdatum und seitenweise nach Schlüssel.\n\nLiest Bundle-Auftragspositionen (die Kopfzeilen von Bundles in Aufträgen) aus der Tabelle `BundleOrderlines` mit schlüsselbasiertem Paging.\n\n**Auswahl der Kandidaten.** Es wird nur die erste zutreffende Filtergruppe angewendet, in dieser Reihenfolge:\n\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: Positionen, deren `CreateDate` **oder** `UpdateDate` im Zeitraum liegt.\n2. `CreateDateFrom` / `CreateDateTo`: Positionen, deren `CreateDate` im Zeitraum liegt.\n3. `UpdateDateFrom` / `UpdateDateTo`: Positionen, deren `UpdateDate` im Zeitraum liegt.\n4. Kein Datumsfilter: alle Positionen.\n\nInnerhalb einer Datumsgruppe wird ein fehlender *From*-Wert durch das aktuelle Datum minus zwei Jahre ersetzt, ein fehlender *To*-Wert durch das aktuelle Datum mit Uhrzeit. Die Zeiträume sind inklusiv (`BETWEEN`).\n\n**Paging.** In allen Fällen werden nur Positionen mit `BundleOrderlineKey` > `OrderlineKey` geliefert. `OrderlineKey` ist standardmäßig `0`. Es werden höchstens `RowCount` Positionen geliefert (Standard `1000`), aufsteigend sortiert nach `BundleOrderlineKey`. Für die nächste Seite wird der höchste `OrderlineKey` der vorherigen Seite übergeben.\n\nDas Ergebnis ist eine Ergebnismenge mit ausgewählten Spalten aus `BundleOrderlines`, aufsteigend sortiert nach `OrderlineKey`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Paging-Cursor: Es werden nur Positionen mit einem Schlüssel größer als dieser Wert geliefert. NULL wird als `0` behandelt. |\n| `CreateDateFrom` | datetime | Nein | Beginn des Anlagedatum-Zeitraums. Wird nur verwendet, wenn kein kombinierter Zeitraum angegeben ist. Ist nur das Ende gesetzt, gilt das Datum vor zwei Jahren. |\n| `CreateDateTo` | datetime | Nein | Ende des Anlagedatum-Zeitraums (inklusiv). Ist nur der Beginn gesetzt, gilt das aktuelle Datum mit Uhrzeit. |\n| `UpdateDateFrom` | datetime | Nein | Beginn des Änderungsdatum-Zeitraums. Wird nur verwendet, wenn weder ein kombinierter noch ein Anlagedatum-Zeitraum angegeben ist. Ist nur das Ende gesetzt, gilt das Datum vor zwei Jahren. |\n| `UpdateDateTo` | datetime | Nein | Ende des Änderungsdatum-Zeitraums (inklusiv). Ist nur der Beginn gesetzt, gilt das aktuelle Datum mit Uhrzeit. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Beginn eines Zeitraums, der gegen `CreateDate` oder `UpdateDate` geprüft wird. Hat Vorrang vor allen anderen Datumsfiltern. Ist nur das Ende gesetzt, gilt das Datum vor zwei Jahren. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Ende des kombinierten Anlage-/Änderungszeitraums (inklusiv). Ist nur der Beginn gesetzt, gilt das aktuelle Datum mit Uhrzeit. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Positionen pro Aufruf. NULL wird als `1000` behandelt. |\n\n- `OrderlineKey` ist **kein** Filter auf genau einen Schlüssel. Da ein NULL-Wert zu Beginn durch `0` und `RowCount` durch `1000` ersetzt wird, wird der Codezweig zum Lesen eines einzelnen Schlüssels nie erreicht. Um genau eine Position mit Schlüssel *n* zu lesen, `OrderlineKey` = *n*-1 und `RowCount` = `1` übergeben.\n- Ein NULL-Wert für `RowCount` wird als `1000` behandelt.\n- Alle Lesezugriffe verwenden `NOLOCK`; es können nicht festgeschriebene Daten geliefert sowie bei gleichzeitigen Änderungen Zeilen übersprungen oder doppelt geliefert werden.\n- Die Datums-Standardwerte beruhen auf der Serverzeit (`GETDATE()`); ohne *From*-Wert liefern die Datumsfilter keine Positionen, die älter als zwei Jahre sind.\n- Die Datentypen der Spalten sind im Code nicht sichtbar; sie stammen aus der Tabelle `BundleOrderlines`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadBundleOrderlines"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Bundle-Auftragspositionen aus `BundleOrderlines`, gefiltert nach Anlage- und/oder Änderungsdatum und seitenweise nach Schlüssel.\n\nLiest Bundle-Auftragspositionen (die Kopfzeilen von Bundles in Aufträgen) aus der Tabelle `BundleOrderlines` mit schlüsselbasiertem Paging.\n\n**Auswahl der Kandidaten.** Es wird nur die erste zutreffende Filtergruppe angewendet, in dieser Reihenfolge:\n\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: Positionen, deren `CreateDate` **oder** `UpdateDate` im Zeitraum liegt.\n2. `CreateDateFrom` / `CreateDateTo`: Positionen, deren `CreateDate` im Zeitraum liegt.\n3. `UpdateDateFrom` / `UpdateDateTo`: Positionen, deren `UpdateDate` im Zeitraum liegt.\n4. Kein Datumsfilter: alle Positionen.\n\nInnerhalb einer Datumsgruppe wird ein fehlender *From*-Wert durch das aktuelle Datum minus zwei Jahre ersetzt, ein fehlender *To*-Wert durch das aktuelle Datum mit Uhrzeit. Die Zeiträume sind inklusiv (`BETWEEN`).\n\n**Paging.** In allen Fällen werden nur Positionen mit `BundleOrderlineKey` > `OrderlineKey` geliefert. `OrderlineKey` ist standardmäßig `0`. Es werden höchstens `RowCount` Positionen geliefert (Standard `1000`), aufsteigend sortiert nach `BundleOrderlineKey`. Für die nächste Seite wird der höchste `OrderlineKey` der vorherigen Seite übergeben.\n\nDas Ergebnis ist eine Ergebnismenge mit ausgewählten Spalten aus `BundleOrderlines`, aufsteigend sortiert nach `OrderlineKey`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Paging-Cursor: Es werden nur Positionen mit einem Schlüssel größer als dieser Wert geliefert. NULL wird als `0` behandelt. |\n| `CreateDateFrom` | datetime | Nein | Beginn des Anlagedatum-Zeitraums. Wird nur verwendet, wenn kein kombinierter Zeitraum angegeben ist. Ist nur das Ende gesetzt, gilt das Datum vor zwei Jahren. |\n| `CreateDateTo` | datetime | Nein | Ende des Anlagedatum-Zeitraums (inklusiv). Ist nur der Beginn gesetzt, gilt das aktuelle Datum mit Uhrzeit. |\n| `UpdateDateFrom` | datetime | Nein | Beginn des Änderungsdatum-Zeitraums. Wird nur verwendet, wenn weder ein kombinierter noch ein Anlagedatum-Zeitraum angegeben ist. Ist nur das Ende gesetzt, gilt das Datum vor zwei Jahren. |\n| `UpdateDateTo` | datetime | Nein | Ende des Änderungsdatum-Zeitraums (inklusiv). Ist nur der Beginn gesetzt, gilt das aktuelle Datum mit Uhrzeit. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Beginn eines Zeitraums, der gegen `CreateDate` oder `UpdateDate` geprüft wird. Hat Vorrang vor allen anderen Datumsfiltern. Ist nur das Ende gesetzt, gilt das Datum vor zwei Jahren. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Ende des kombinierten Anlage-/Änderungszeitraums (inklusiv). Ist nur der Beginn gesetzt, gilt das aktuelle Datum mit Uhrzeit. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Positionen pro Aufruf. NULL wird als `1000` behandelt. |\n\n- `OrderlineKey` ist **kein** Filter auf genau einen Schlüssel. Da ein NULL-Wert zu Beginn durch `0` und `RowCount` durch `1000` ersetzt wird, wird der Codezweig zum Lesen eines einzelnen Schlüssels nie erreicht. Um genau eine Position mit Schlüssel *n* zu lesen, `OrderlineKey` = *n*-1 und `RowCount` = `1` übergeben.\n- Ein NULL-Wert für `RowCount` wird als `1000` behandelt.\n- Alle Lesezugriffe verwenden `NOLOCK`; es können nicht festgeschriebene Daten geliefert sowie bei gleichzeitigen Änderungen Zeilen übersprungen oder doppelt geliefert werden.\n- Die Datums-Standardwerte beruhen auf der Serverzeit (`GETDATE()`); ohne *From*-Wert liefern die Datumsfilter keine Positionen, die älter als zwei Jahre sind.\n- Die Datentypen der Spalten sind im Code nicht sichtbar; sie stammen aus der Tabelle `BundleOrderlines`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadBundleOrderlines"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n 200315\n 8812\n 9120\n 9121\n BUNDLE-001\n Starter Set\n 1\n 49.90\n AUF\n 2024-06-12T10:15:00\n 2024-06-12T10:15:03\n API\n 2024-06-12T11:02:44\n API\n 3301\n SHOP-100045\n 001\n SHOP1\n 41.93\n 19.00\n \n"
}
]
},
{
"name": "pixiReadOrderlines",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Auftragspositionen aus `Orderlines` nach Schlüssel, Schlüsselbereich oder Anlage-/Änderungszeitraum, inklusive Währung, Wechselkurs, Versandkosten und voraussichtlicher Lieferung.\n\nLiest Auftragspositionen in einem von mehreren Auswahlmodi. Ein fehlender `OrderlineKey` wird als `0` behandelt. Es gilt der erste zutreffende Modus:\n\n1. **Angelegt oder geändert** – wenn `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` gesetzt ist: Positionen mit `OrderlineKey` > `OrderlineKey`, deren `CreateDate` **oder** `UpdateDate` im Zeitraum liegt.\n2. **Angelegt** – sonst, wenn `CreateDateFrom` oder `CreateDateTo` gesetzt ist: Positionen mit Schlüssel > `OrderlineKey`, deren `CreateDate` im Zeitraum liegt.\n3. **Geändert** – sonst, wenn `UpdateDateFrom` oder `UpdateDateTo` gesetzt ist: Positionen mit Schlüssel > `OrderlineKey`, deren `UpdateDate` im Zeitraum liegt.\n4. **Schlüsselbereich** – sonst, wenn `RowCount` übergeben wird (jeder Wert, auch `0`): alle Positionen mit Schlüssel > `OrderlineKey`.\n5. **Einzelne Position** – andernfalls: die Position mit genau diesem `OrderlineKey`.\n\nIn den Datumsmodi wird eine fehlende Untergrenze auf 10 Jahre vor der aktuellen Serverzeit gesetzt, eine fehlende Obergrenze auf die aktuelle Serverzeit (`GETDATE()`). Die Grenzen sind inklusiv (`BETWEEN`).\n\nIst `RowCount` > 0, wird die Zeilenzahl auf `RowCount` begrenzt, beginnend mit den kleinsten Schlüsseln. Das Ergebnis ist aufsteigend nach `OrderlineKey` sortiert. Damit ist Keyset-Paging möglich: den zuletzt gelieferten `OrderlineKey` im nächsten Aufruf als `OrderlineKey` übergeben.\n\nJede Position wird mit ihrem Auftragskopf (`OrderHeader`), dem Wechselkurs und der Währung des Auftrags sowie optional mit `Orderline_EstimatedDelivery` verknüpft.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Im Einzelmodus der Schlüssel der gewünschten Position; in allen anderen Modi werden nur Positionen mit größerem Schlüssel geliefert (Paging-Start). `NULL` wird als `0` behandelt. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze für `CreateDate` (inklusiv). Standard 10 Jahre zurück, wenn nur die Obergrenze gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Obergrenze für `CreateDate` (inklusiv). Standard ist die aktuelle Serverzeit, wenn nur die Untergrenze gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze für `UpdateDate` (inklusiv). Wird nur verwendet, wenn kein Anlage- bzw. Anlage-und-Änderungs-Filter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze für `UpdateDate` (inklusiv). Standard ist die aktuelle Serverzeit. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze; geliefert werden Positionen, deren `CreateDate` oder `UpdateDate` im Zeitraum liegt. Hat Vorrang vor allen anderen Datumsfiltern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze für den kombinierten Anlage-/Änderungsfilter. Standard ist die aktuelle Serverzeit. |\n| `RowCount` | int | Nein | Maximale Zeilenzahl, wenn > 0. Wird der Parameter ohne Datumsfilter übergeben, gilt der Schlüsselbereichsmodus (alle Positionen mit Schlüssel > `OrderlineKey`). |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; nicht festgeschriebene oder inkonsistente Daten sind möglich.\n- Die Begrenzung erfolgt per `SET ROWCOUNT` und wirkt sowohl auf die Kandidatenauswahl als auch auf die Abschlussabfrage.\n- Positionen werden nur geliefert, wenn Auftragskopf, Wechselkurs (`pixi.ExchRate`) und Währung (`pixi.Currency`) existieren (Inner Joins). Eine Seite kann daher weniger als `RowCount` Zeilen enthalten, obwohl weitere Daten folgen; ab dem letzten Schlüssel weiterblättern und erst bei leerem Ergebnis aufhören.\n- Enthält `Orderline_EstimatedDelivery` mehrere Zeilen pro Position, erscheint die Position mehrfach.\n- `RowCount = 0` ohne Datumsfilter liefert **alle** Positionen oberhalb von `OrderlineKey` ohne Begrenzung.\n- Ein Aufruf ohne Parameter sucht `OrderlineKey = 0` und liefert in der Regel keine Zeilen.\n- Die Datumsfilter haben in der genannten Reihenfolge Vorrang; pro Aufruf wird nur ein Datumsmodus verwendet.\n- `Price_OrderCurr` entspricht `Price`, `ShipCost_OrderCurr` entspricht `ShipCost`, `Price_OrderCurr_Set` und `ShipCost_OrderCurr_Set` sind immer `0`, `SOrderlineRef` ist immer `NULL`. Kommentare im Code markieren die `_OrderCurr`-Spalten zur Entfernung.\n- `ShipCost` sind die Versandkosten des gesamten Auftragskopfs und werden in jeder Position des Auftrags wiederholt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadOrderlines"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Auftragspositionen aus `Orderlines` nach Schlüssel, Schlüsselbereich oder Anlage-/Änderungszeitraum, inklusive Währung, Wechselkurs, Versandkosten und voraussichtlicher Lieferung.\n\nLiest Auftragspositionen in einem von mehreren Auswahlmodi. Ein fehlender `OrderlineKey` wird als `0` behandelt. Es gilt der erste zutreffende Modus:\n\n1. **Angelegt oder geändert** – wenn `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` gesetzt ist: Positionen mit `OrderlineKey` > `OrderlineKey`, deren `CreateDate` **oder** `UpdateDate` im Zeitraum liegt.\n2. **Angelegt** – sonst, wenn `CreateDateFrom` oder `CreateDateTo` gesetzt ist: Positionen mit Schlüssel > `OrderlineKey`, deren `CreateDate` im Zeitraum liegt.\n3. **Geändert** – sonst, wenn `UpdateDateFrom` oder `UpdateDateTo` gesetzt ist: Positionen mit Schlüssel > `OrderlineKey`, deren `UpdateDate` im Zeitraum liegt.\n4. **Schlüsselbereich** – sonst, wenn `RowCount` übergeben wird (jeder Wert, auch `0`): alle Positionen mit Schlüssel > `OrderlineKey`.\n5. **Einzelne Position** – andernfalls: die Position mit genau diesem `OrderlineKey`.\n\nIn den Datumsmodi wird eine fehlende Untergrenze auf 10 Jahre vor der aktuellen Serverzeit gesetzt, eine fehlende Obergrenze auf die aktuelle Serverzeit (`GETDATE()`). Die Grenzen sind inklusiv (`BETWEEN`).\n\nIst `RowCount` > 0, wird die Zeilenzahl auf `RowCount` begrenzt, beginnend mit den kleinsten Schlüsseln. Das Ergebnis ist aufsteigend nach `OrderlineKey` sortiert. Damit ist Keyset-Paging möglich: den zuletzt gelieferten `OrderlineKey` im nächsten Aufruf als `OrderlineKey` übergeben.\n\nJede Position wird mit ihrem Auftragskopf (`OrderHeader`), dem Wechselkurs und der Währung des Auftrags sowie optional mit `Orderline_EstimatedDelivery` verknüpft.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Im Einzelmodus der Schlüssel der gewünschten Position; in allen anderen Modi werden nur Positionen mit größerem Schlüssel geliefert (Paging-Start). `NULL` wird als `0` behandelt. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze für `CreateDate` (inklusiv). Standard 10 Jahre zurück, wenn nur die Obergrenze gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Obergrenze für `CreateDate` (inklusiv). Standard ist die aktuelle Serverzeit, wenn nur die Untergrenze gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze für `UpdateDate` (inklusiv). Wird nur verwendet, wenn kein Anlage- bzw. Anlage-und-Änderungs-Filter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze für `UpdateDate` (inklusiv). Standard ist die aktuelle Serverzeit. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze; geliefert werden Positionen, deren `CreateDate` oder `UpdateDate` im Zeitraum liegt. Hat Vorrang vor allen anderen Datumsfiltern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze für den kombinierten Anlage-/Änderungsfilter. Standard ist die aktuelle Serverzeit. |\n| `RowCount` | int | Nein | Maximale Zeilenzahl, wenn > 0. Wird der Parameter ohne Datumsfilter übergeben, gilt der Schlüsselbereichsmodus (alle Positionen mit Schlüssel > `OrderlineKey`). |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; nicht festgeschriebene oder inkonsistente Daten sind möglich.\n- Die Begrenzung erfolgt per `SET ROWCOUNT` und wirkt sowohl auf die Kandidatenauswahl als auch auf die Abschlussabfrage.\n- Positionen werden nur geliefert, wenn Auftragskopf, Wechselkurs (`pixi.ExchRate`) und Währung (`pixi.Currency`) existieren (Inner Joins). Eine Seite kann daher weniger als `RowCount` Zeilen enthalten, obwohl weitere Daten folgen; ab dem letzten Schlüssel weiterblättern und erst bei leerem Ergebnis aufhören.\n- Enthält `Orderline_EstimatedDelivery` mehrere Zeilen pro Position, erscheint die Position mehrfach.\n- `RowCount = 0` ohne Datumsfilter liefert **alle** Positionen oberhalb von `OrderlineKey` ohne Begrenzung.\n- Ein Aufruf ohne Parameter sucht `OrderlineKey = 0` und liefert in der Regel keine Zeilen.\n- Die Datumsfilter haben in der genannten Reihenfolge Vorrang; pro Aufruf wird nur ein Datumsmodus verwendet.\n- `Price_OrderCurr` entspricht `Price`, `ShipCost_OrderCurr` entspricht `ShipCost`, `Price_OrderCurr_Set` und `ShipCost_OrderCurr_Set` sind immer `0`, `SOrderlineRef` ist immer `NULL`. Kommentare im Code markieren die `_OrderCurr`-Spalten zur Entfernung.\n- `ShipCost` sind die Versandkosten des gesamten Auftragskopfs und werden in jeder Position des Auftrags wiederholt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadOrderlines"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 184523\n 90211\n 4711\n AB-1001\n T-Shirt blau M\n 2\n 19.9900\n AU\n 2024-05-01T10:15:00\n EUR\n 1.0000\n 4.9000\n SHOP-100234\n 001\n 2024-05-01T10:15:03\n 2024-05-01T11:02:40\n 0\n 0\n 2024-05-03T00:00:00\n \n"
}
]
},
{
"name": "pixiReadPOSItems",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kassenbon-Positionen (POS) aus `POSitem2`, gefiltert nach Schlüssel oder nach Anlage-/Änderungsdatum des POS-Kopfs, mit optionalem schlüsselbasiertem Paging.\n\nLiest Positionen von Kassenbons (POS). Wird `POSItemKey` nicht übergeben, wird `0` verwendet. Der erste zutreffende Zweig bestimmt den Filter:\n\n1. **Anlage- oder Änderungsdatum** – wenn `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` gesetzt ist: Positionen, deren POS-Kopf (`POSheader2`) im Zeitraum angelegt *oder* geändert wurde. Die Untergrenze gilt als erfüllt, wenn `PHCreateDate` oder `PHUpdateDate` `>=` dem Von-Wert ist, die Obergrenze, wenn `PHCreateDate` oder `PHUpdateDate` `<` dem Bis-Wert ist.\n2. **Anlagedatum** – sonst, wenn `CreateDateFrom` oder `CreateDateTo` gesetzt ist: `PHCreateDate` des Kopfs `>=` Von und `<` Bis.\n3. **Änderungsdatum** – sonst, wenn `UpdateDateFrom` oder `UpdateDateTo` gesetzt ist: `PHUpdateDate` des Kopfs `>=` Von und `<` Bis.\n4. **Schlüsselbereich** – sonst, wenn `RowCount` übergeben wird: alle Positionen mit `POSitemKey` größer als `POSItemKey`.\n5. **Einzelne Position** – andernfalls: die Position mit genau `POSitemKey` = `POSItemKey`.\n\nIn den Zweigen 1–4 werden nur Positionen mit `POSitemKey` > `POSItemKey` geliefert, aufsteigend sortiert nach `POSitemKey`. Die Zweige 1–3 liefern nur Positionen mit vorhandenem POS-Kopf (Inner Join).\n\n`RowCount` begrenzt die Anzahl der gelieferten Zeilen (sofern nicht 0). Für Paging wird der zuletzt erhaltene `POSitemKey` im nächsten Aufruf als `POSItemKey` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `POSItemKey` | int | Nein | Schlüssel einer POS-Position. Exakter Treffer im Einzelpositions-Zweig; sonst werden nur Positionen mit größerem Schlüssel geliefert (Paging-Start). NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusiv) für das Anlagedatum des POS-Kopfs. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusiv) für das Anlagedatum des POS-Kopfs. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusiv) für das Änderungsdatum des POS-Kopfs. Wird ignoriert, wenn ein Anlage- oder kombinierter Filter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusiv) für das Änderungsdatum des POS-Kopfs. Wird ignoriert, wenn ein Anlage- oder kombinierter Filter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusiv), geprüft gegen Anlage- oder Änderungsdatum des Kopfs. Hat Vorrang vor allen anderen Datumsfiltern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (exklusiv), geprüft gegen Anlage- oder Änderungsdatum des Kopfs. Hat Vorrang vor allen anderen Datumsfiltern. |\n| `RowCount` | int | Nein | Maximale Anzahl Zeilen (0 oder NULL = keine Begrenzung). Wird der Wert ohne Datumsfilter übergeben, wird der Schlüsselbereichs-Zweig verwendet (`POSitemKey` > `POSItemKey`). |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; es können nicht festgeschriebene Daten geliefert werden.\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`.\n- Ein Aufruf ohne Parameter landet im Einzelpositions-Zweig mit Schlüssel `0` und liefert normalerweise ein leeres Ergebnis.\n- `RowCount` = `0` wählt trotzdem den Schlüsselbereichs-Zweig (der Wert ist nicht NULL), setzt aber keine Begrenzung; es werden alle Positionen oberhalb von `POSItemKey` geliefert.\n- Die Obergrenzen der Datumsfilter sind exklusiv (`<`). Beim kombinierten Anlage-/Änderungsfilter werden die Grenzen unabhängig geprüft; eine Zeile kann die Untergrenze über das eine und die Obergrenze über das andere Datum erfüllen.\n- Die Datumsfilter beziehen sich auf den POS-Kopf, nicht auf die Position selbst.\n- Der letzte Zweig \"no data\" im Code ist nicht erreichbar, da `POSItemKey` nach der Standardwertbehandlung nie NULL ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadPOSItems"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kassenbon-Positionen (POS) aus `POSitem2`, gefiltert nach Schlüssel oder nach Anlage-/Änderungsdatum des POS-Kopfs, mit optionalem schlüsselbasiertem Paging.\n\nLiest Positionen von Kassenbons (POS). Wird `POSItemKey` nicht übergeben, wird `0` verwendet. Der erste zutreffende Zweig bestimmt den Filter:\n\n1. **Anlage- oder Änderungsdatum** – wenn `CreateAndUpdateDateFrom` oder `CreateAndUpdateDateTo` gesetzt ist: Positionen, deren POS-Kopf (`POSheader2`) im Zeitraum angelegt *oder* geändert wurde. Die Untergrenze gilt als erfüllt, wenn `PHCreateDate` oder `PHUpdateDate` `>=` dem Von-Wert ist, die Obergrenze, wenn `PHCreateDate` oder `PHUpdateDate` `<` dem Bis-Wert ist.\n2. **Anlagedatum** – sonst, wenn `CreateDateFrom` oder `CreateDateTo` gesetzt ist: `PHCreateDate` des Kopfs `>=` Von und `<` Bis.\n3. **Änderungsdatum** – sonst, wenn `UpdateDateFrom` oder `UpdateDateTo` gesetzt ist: `PHUpdateDate` des Kopfs `>=` Von und `<` Bis.\n4. **Schlüsselbereich** – sonst, wenn `RowCount` übergeben wird: alle Positionen mit `POSitemKey` größer als `POSItemKey`.\n5. **Einzelne Position** – andernfalls: die Position mit genau `POSitemKey` = `POSItemKey`.\n\nIn den Zweigen 1–4 werden nur Positionen mit `POSitemKey` > `POSItemKey` geliefert, aufsteigend sortiert nach `POSitemKey`. Die Zweige 1–3 liefern nur Positionen mit vorhandenem POS-Kopf (Inner Join).\n\n`RowCount` begrenzt die Anzahl der gelieferten Zeilen (sofern nicht 0). Für Paging wird der zuletzt erhaltene `POSitemKey` im nächsten Aufruf als `POSItemKey` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `POSItemKey` | int | Nein | Schlüssel einer POS-Position. Exakter Treffer im Einzelpositions-Zweig; sonst werden nur Positionen mit größerem Schlüssel geliefert (Paging-Start). NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusiv) für das Anlagedatum des POS-Kopfs. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusiv) für das Anlagedatum des POS-Kopfs. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusiv) für das Änderungsdatum des POS-Kopfs. Wird ignoriert, wenn ein Anlage- oder kombinierter Filter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusiv) für das Änderungsdatum des POS-Kopfs. Wird ignoriert, wenn ein Anlage- oder kombinierter Filter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusiv), geprüft gegen Anlage- oder Änderungsdatum des Kopfs. Hat Vorrang vor allen anderen Datumsfiltern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (exklusiv), geprüft gegen Anlage- oder Änderungsdatum des Kopfs. Hat Vorrang vor allen anderen Datumsfiltern. |\n| `RowCount` | int | Nein | Maximale Anzahl Zeilen (0 oder NULL = keine Begrenzung). Wird der Wert ohne Datumsfilter übergeben, wird der Schlüsselbereichs-Zweig verwendet (`POSitemKey` > `POSItemKey`). |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; es können nicht festgeschriebene Daten geliefert werden.\n- Die Zeilenbegrenzung erfolgt über `SET ROWCOUNT`.\n- Ein Aufruf ohne Parameter landet im Einzelpositions-Zweig mit Schlüssel `0` und liefert normalerweise ein leeres Ergebnis.\n- `RowCount` = `0` wählt trotzdem den Schlüsselbereichs-Zweig (der Wert ist nicht NULL), setzt aber keine Begrenzung; es werden alle Positionen oberhalb von `POSItemKey` geliefert.\n- Die Obergrenzen der Datumsfilter sind exklusiv (`<`). Beim kombinierten Anlage-/Änderungsfilter werden die Grenzen unabhängig geprüft; eine Zeile kann die Untergrenze über das eine und die Obergrenze über das andere Datum erfüllen.\n- Die Datumsfilter beziehen sich auf den POS-Kopf, nicht auf die Position selbst.\n- Der letzte Zweig \"no data\" im Code ist nicht erreichbar, da `POSItemKey` nach der Standardwertbehandlung nie NULL ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadPOSItems"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 15231\n 4102\n 8812\n 4006381333931\n ART-10023\n 2\n 19.99\n 0\n 19.99\n 3.19\n 1\n 311\n 99821\n 1\n 14\n 4006381333931\n 19\n 39.98\n 0\n \n 0\n 552310\n \n \n"
}
]
},
{
"name": "pixiSetOrderlineLocation",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n 001\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt das Lager (LocID) einer Auftragsposition oder einer Bundle-Position samt zugehöriger Bundle-Positionen um.\n\nÄndert das Lager (`LocationID` und `LastOrdLocationID`) von Auftragspositionen. Der Aufruf übergibt an die interne Prozedur `Pixi_UpdateOrderLocation` mit dem Benutzernamen `API` und liefert eine Statuszeile.\n\n**Welche Datensätze geändert werden**\n\n- **Nur `OrderlineKey` angegeben:** Die Auftragsposition selbst wird umgesetzt. Gehört sie zu einem Bundle, werden auch alle weiteren Positionen desselben Bundles und die Bundle-Position (`BundleOrderlines`) umgesetzt.\n- **Nur `BundleOrderlineKey` angegeben:** Alle Komponentenpositionen des Bundles und die Bundle-Position selbst werden umgesetzt. Die Komponentenpositionen werden nur umgesetzt, wenn die Bundle-Position einen zulässigen Status hat.\n- **Kein Schlüssel angegeben:** Der Aufruf schlägt fehl, da kein Auftrag ermittelt werden kann.\n\nNur Positionen mit zulässigem Status werden aktualisiert. Zulässig sind alle nicht finalen Status aus `OrderStates` (`FinalState = 'N'`) außer `EIN`, `FUT` und `FUS`. Positionen mit anderem Status werden ohne Meldung übergangen; der Aufruf liefert trotzdem `OK`.\n\n**Prüfungen**\n\nDie interne Prozedur prüft Folgendes und lehnt den Aufruf ab, wenn eine Prüfung fehlschlägt:\n\n- Die Auftragsposition bzw. Bundle-Position existiert.\n- `LocationId` existiert in `Location`.\n- Mindestens eine Position des Auftrags hat den Status `NEW`, `ANG`, `HAL`, `MIN`, `BES`, `STO` oder `NLB`.\n- Keine der betroffenen Auftragspositionen liegt auf einer Pickliste (`PLitem`).\n\n**POS-/Reservierungslager**\n\nHat das Ziellager eine `ResLocID`, wird `ResOnLocDate` im Auftragskopf auf NULL gesetzt. Danach betrachtet die Prozedur andere Aufträge, die zulässige Positionen mit denselben Artikeln auf diesem Lager haben. Liegt das späteste `ResOnLocDate` dieser Aufträge vor dem frühesten Reservierungsdatum dieses Auftrags, erhalten alle Reservierungen dieses Auftrags dieses späteste `ResOnLocDate` plus eine Sekunde als neues `ResDate`.\n\n**Ergebnis**\n\nBei Erfolg liefert der Aufruf `ReturnCode = 'OK'`. Andernfalls liefert er `ReturnCode = 'ERROR'` mit der allgemeinen Meldung `Ilegal parameters`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Schlüssel der umzusetzenden Auftragsposition. Gehört sie zu einem Bundle, werden auch die übrigen Bundle-Positionen und die Bundle-Position umgesetzt. Dieser Schlüssel oder `BundleOrderlineKey` muss angegeben werden. |\n| `BundleOrderlineKey` | int | Nein | Schlüssel der Bundle-Position (`BundleOrderlines`), die mit allen Komponentenpositionen umgesetzt wird. Dieser Schlüssel oder `OrderlineKey` muss angegeben werden. |\n| `LocationId` | char(3) | Ja | Ziellager (`LocID` aus Tabelle `Location`). Muss existieren. |\n\n- Alle Fehlerursachen der internen Prozedur münden in die eine Meldung `Ilegal parameters`. Die genauen Gründe werden nur per `PRINT` ausgegeben, z. B. `ERROR: Wrong LocationID: ...` oder `... must not be on Picklist`. Ob ein SOAP-Client diese Texte erhält, ist aus dem Code nicht ersichtlich.\n- `UpdateEmp` wird auf `API` und `UpdateDate` auf die aktuelle Zeit gesetzt, und zwar bei allen aktualisierten Zeilen.\n- Die interne Prozedur läuft in einer eigenen Transaktion oder nutzt einen Savepoint, falls bereits eine Transaktion offen ist. Bei einem Laufzeitfehler erfolgt ein Rollback, der Fehler wird über `log.InsertError` protokolliert und der Aufruf liefert `ERROR`.\n- Während des Updates von `BundleOrderlines` wird `CONTEXT_INFO` vorübergehend auf `0x30000` gesetzt. Laut Code-Kommentar wird damit eine Neuberechnung der Bundles vermieden; die auswertenden Trigger liegen nicht vor.\n- Prüfungen lesen mit `NOLOCK`; Updates verwenden `ROWLOCK`.\n- Die gleichzeitige Angabe von `OrderlineKey` und `BundleOrderlineKey` ist nicht zu empfehlen:\n - Der Bundle-Schlüssel bestimmt den Auftrag.\n - Die Bundle-Position selbst wird nicht aktualisiert.\n - Dieselben Positionen können doppelt erfasst werden, sodass der eindeutige Index auf der internen Temp-Tabelle fehlschlägt und der Aufruf `ERROR` liefert.\n\n Es sollte nur einer der beiden Schlüssel übergeben werden.\n- Die Statusprüfung (`NEW`, `ANG`, `HAL`, ...) verlangt nur eine Position des gesamten Auftrags in einem solchen Status, nicht zwingend die Zielposition.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetOrderlineLocation"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n 001\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt das Lager (LocID) einer Auftragsposition oder einer Bundle-Position samt zugehöriger Bundle-Positionen um.\n\nÄndert das Lager (`LocationID` und `LastOrdLocationID`) von Auftragspositionen. Der Aufruf übergibt an die interne Prozedur `Pixi_UpdateOrderLocation` mit dem Benutzernamen `API` und liefert eine Statuszeile.\n\n**Welche Datensätze geändert werden**\n\n- **Nur `OrderlineKey` angegeben:** Die Auftragsposition selbst wird umgesetzt. Gehört sie zu einem Bundle, werden auch alle weiteren Positionen desselben Bundles und die Bundle-Position (`BundleOrderlines`) umgesetzt.\n- **Nur `BundleOrderlineKey` angegeben:** Alle Komponentenpositionen des Bundles und die Bundle-Position selbst werden umgesetzt. Die Komponentenpositionen werden nur umgesetzt, wenn die Bundle-Position einen zulässigen Status hat.\n- **Kein Schlüssel angegeben:** Der Aufruf schlägt fehl, da kein Auftrag ermittelt werden kann.\n\nNur Positionen mit zulässigem Status werden aktualisiert. Zulässig sind alle nicht finalen Status aus `OrderStates` (`FinalState = 'N'`) außer `EIN`, `FUT` und `FUS`. Positionen mit anderem Status werden ohne Meldung übergangen; der Aufruf liefert trotzdem `OK`.\n\n**Prüfungen**\n\nDie interne Prozedur prüft Folgendes und lehnt den Aufruf ab, wenn eine Prüfung fehlschlägt:\n\n- Die Auftragsposition bzw. Bundle-Position existiert.\n- `LocationId` existiert in `Location`.\n- Mindestens eine Position des Auftrags hat den Status `NEW`, `ANG`, `HAL`, `MIN`, `BES`, `STO` oder `NLB`.\n- Keine der betroffenen Auftragspositionen liegt auf einer Pickliste (`PLitem`).\n\n**POS-/Reservierungslager**\n\nHat das Ziellager eine `ResLocID`, wird `ResOnLocDate` im Auftragskopf auf NULL gesetzt. Danach betrachtet die Prozedur andere Aufträge, die zulässige Positionen mit denselben Artikeln auf diesem Lager haben. Liegt das späteste `ResOnLocDate` dieser Aufträge vor dem frühesten Reservierungsdatum dieses Auftrags, erhalten alle Reservierungen dieses Auftrags dieses späteste `ResOnLocDate` plus eine Sekunde als neues `ResDate`.\n\n**Ergebnis**\n\nBei Erfolg liefert der Aufruf `ReturnCode = 'OK'`. Andernfalls liefert er `ReturnCode = 'ERROR'` mit der allgemeinen Meldung `Ilegal parameters`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Schlüssel der umzusetzenden Auftragsposition. Gehört sie zu einem Bundle, werden auch die übrigen Bundle-Positionen und die Bundle-Position umgesetzt. Dieser Schlüssel oder `BundleOrderlineKey` muss angegeben werden. |\n| `BundleOrderlineKey` | int | Nein | Schlüssel der Bundle-Position (`BundleOrderlines`), die mit allen Komponentenpositionen umgesetzt wird. Dieser Schlüssel oder `OrderlineKey` muss angegeben werden. |\n| `LocationId` | char(3) | Ja | Ziellager (`LocID` aus Tabelle `Location`). Muss existieren. |\n\n- Alle Fehlerursachen der internen Prozedur münden in die eine Meldung `Ilegal parameters`. Die genauen Gründe werden nur per `PRINT` ausgegeben, z. B. `ERROR: Wrong LocationID: ...` oder `... must not be on Picklist`. Ob ein SOAP-Client diese Texte erhält, ist aus dem Code nicht ersichtlich.\n- `UpdateEmp` wird auf `API` und `UpdateDate` auf die aktuelle Zeit gesetzt, und zwar bei allen aktualisierten Zeilen.\n- Die interne Prozedur läuft in einer eigenen Transaktion oder nutzt einen Savepoint, falls bereits eine Transaktion offen ist. Bei einem Laufzeitfehler erfolgt ein Rollback, der Fehler wird über `log.InsertError` protokolliert und der Aufruf liefert `ERROR`.\n- Während des Updates von `BundleOrderlines` wird `CONTEXT_INFO` vorübergehend auf `0x30000` gesetzt. Laut Code-Kommentar wird damit eine Neuberechnung der Bundles vermieden; die auswertenden Trigger liegen nicht vor.\n- Prüfungen lesen mit `NOLOCK`; Updates verwenden `ROWLOCK`.\n- Die gleichzeitige Angabe von `OrderlineKey` und `BundleOrderlineKey` ist nicht zu empfehlen:\n - Der Bundle-Schlüssel bestimmt den Auftrag.\n - Die Bundle-Position selbst wird nicht aktualisiert.\n - Dieselben Positionen können doppelt erfasst werden, sodass der eindeutige Index auf der internen Temp-Tabelle fehlschlägt und der Aufruf `ERROR` liefert.\n\n Es sollte nur einer der beiden Schlüssel übergeben werden.\n- Die Statusprüfung (`NEW`, `ANG`, `HAL`, ...) verlangt nur eine Position des gesamten Auftrags in einem solchen Status, nicht zwingend die Zielposition.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetOrderlineLocation"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n \n \n"
}
]
},
{
"name": "pixiUpdateOrderline",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ändert Bezeichnung, Menge, Preise, Rabatte, Notiz, Seriennummer und DF-Typ einer Auftragsposition oder Bundle-Position, sofern die Position noch änderbar ist.\n\nÄndert eine einzelne Auftragsposition (`OrderlineKey`) oder eine Bundle-Position (`BundleOrderlineKey`) und liefert eine Zeile `result` mit `1` (ausgeführt) oder `0` (abgelehnt).\n\n**Schlüsselwahl**\n- `BundleOrderlineKey = 0` wird als `NULL` behandelt.\n- Fehlen beide Schlüssel, wird eine Informationsmeldung ausgegeben und `result = 0` geliefert.\n- Ist `BundleOrderlineKey` gesetzt, wird `OrderlineKey` ignoriert.\n\n**Prüfung der Änderbarkeit**\nDie Position, bei einem Bundle jede Komponenten-Position, muss alle folgenden Bedingungen erfüllen:\n- ihr Auftragsstatus (`OrderStates`) ist kein Endstatus (`FinalState` ist `N` oder leer),\n- ihr Status ist nicht `EIN`,\n- sie ist nicht in einer Kiste verpackt (`boxitems`),\n- sie steht auf keiner Rechnung (`Invlines`).\n\nErfüllt eine einzige Position die Prüfung nicht, wird nichts geändert und `result = 0` geliefert.\n\n**Zusammenführen mit den aktuellen Werten**\nJeder nicht übergebene Parameter (`NULL`) behält den gespeicherten Wert der Position. Bei `ArtName`, `oItemSpecialNote` und `SerialNumber` behält auch ein Leerstring den gespeicherten Wert. Bei Bundles wird die Seriennummer nicht verarbeitet. Ist der resultierende `Price` höher als `FullPrice`, wird `FullPrice` auf `Price` angehoben. Dieselbe Regel gilt für die Nettowerte.\n\n**Aktualisierung**\nAnschließend wird die interne Prozedur `Pixi_UpdateOrderline` mit dem Bearbeiter `API` ausgeführt. Sie führt Folgendes aus:\n- aktualisiert die Auftragsposition bzw. Bundle-Position mit Menge, Brutto-/Nettopreis, Bestätigungsdatum, Bezeichnung, Notiz, Seriennummer, Vollpreisen, Rabattprozent/-wert und `DF_type`;\n- setzt bei Bundles zusätzlich `DF_type` auf allen Komponenten-Positionen;\n- schreibt die aktuellen Kopfwerte (Adressbemerkung, Geschenknachricht sowie bei vorhandener Versandanweisung auch Versandanweisung, `Verfahren`, `Product`, `Extras`) zurück in `OrderHeader`;\n- gleicht den Gutschein des Auftrags ab (siehe Hinweise);\n- baut die Reservierungen des gesamten Auftrags neu auf, wenn eine seiner Positionen eine Reservierung hat.\n\nZum Schluss wird `result = 1` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Schlüssel der zu ändernden Auftragsposition. Wird ignoriert, wenn `BundleOrderlineKey` gesetzt ist. |\n| `ArtName` | varchar(120) | Nein | Neue Artikelbezeichnung der Position. `NULL` oder leer behält die aktuelle Bezeichnung. |\n| `Qty` | int | Nein | Neue Menge. `NULL` behält die aktuelle Menge. |\n| `Price` | money | Nein | Neuer Stückpreis, wird auch als Ausgangswert für den Nettopreis verwendet. `NULL` behält den aktuellen Preis. |\n| `FullPrice` | money | Nein | Neuer Vollpreis (ohne Rabatt), wird auch als Netto-Vollpreis gespeichert. Wird auf `Price` angehoben, falls niedriger. `NULL` behält den aktuellen Wert. |\n| `oItemSpecialNote` | varchar(8000) | Nein | Notiz zur Position. `NULL` oder leer behält die aktuelle Notiz. |\n| `DiscountValue` | money | Nein | Rabattbetrag der Position. `NULL` behält den aktuellen Wert. |\n| `DiscountPerc` | float | Nein | Rabattprozent der Position, gespeichert mit zwei Nachkommastellen. `NULL` behält den aktuellen Wert. |\n| `DF_Type` | varchar(1) | Nein | Direct-Fulfillment-Typ der Position (`DF_type`). Bei Bundles auch auf alle Komponenten-Positionen übertragen. `NULL` behält den aktuellen Wert. |\n| `SerialNumber` | varchar(50) | Nein | Seriennummer der Auftragsposition. `NULL` oder leer behält den aktuellen Wert. Bei Bundle-Positionen nicht verarbeitet. |\n| `BundleOrderlineKey` | int | Nein | Schlüssel der zu ändernden Bundle-Position. `0` wird als `NULL` behandelt. Hat Vorrang vor `OrderlineKey`. |\n\n- **Nicht vorhandener Schlüssel:** Existiert `OrderlineKey` bzw. `BundleOrderlineKey` nicht, findet die Prüfung keine Zeile und lehnt den Aufruf nicht ab. Es wird nichts geändert, trotzdem wird `result = 1` geliefert.\n- **Meldungen statt Fehler:** Alle `RAISERROR`-Aufrufe verwenden Schweregrad 0. Sie kommen nur als `SqlMessage` an, nicht als SQL-Fehler.\n- **Rechnungsprüfung:** Findet `Pixi_UpdateOrderline` eine Rechnungsposition, gibt es seine Meldung aus und ändert nichts. Danach wird dennoch `result = 1` geliefert.\n- **Nettopreise:** Nettopreis und Netto-Vollpreis werden mit den übergebenen Bruttowerten (`Price`, `FullPrice`) vorbelegt. Der Positionspreis wird anschließend über `dbo.fPixi_CalculatePrices` (nicht beigefügt) anhand von Steuersatz und Auftragsart umgerechnet. `FullPrice_Net` wird ohne Umrechnung gespeichert und enthält nach Übergabe von `FullPrice` denselben Wert wie `FullPrice`.\n- **Datentypen:** `DiscountPerc` wird als `numeric(6,2)` weitergegeben und daher auf zwei Nachkommastellen gerundet. `GiftMessage` wird als `varchar(1000)` weitergegeben.\n- **Werte nicht leerbar:** `ArtName`, `oItemSpecialNote` und `SerialNumber` lassen sich über diesen Aufruf nicht leeren.\n- **Gutschein-Abgleich** (anhand des Gutscheincodes der Position und `OrderHeader.Discount`):\n - Existiert der Gutschein mit abweichendem Betrag, wird sein Betrag auf den Auftragsrabatt gesetzt.\n - Ist dieser Rabatt 0, wird `VoucherID` auf allen Positionen und Bundle-Positionen des Auftrags geleert.\n - Existiert der Gutschein nicht und ist der Code nicht `NULL`, wird ein Gutschein angelegt (gültig etwa ein Jahr ab Auftragsdatum, einmalig, Shop `GRM`) und allen Positionen des Auftrags zugeordnet.\n- **Reservierungen:** Reservierungen werden über `Pixi_Res_RemoveReservationForOrder` und `Pixi_Res_CreateReservationForOrder` entfernt und neu angelegt. Diese Prozeduren sind nicht beigefügt und können weitere Ausgaben erzeugen.\n- **Transaktionen und Fehler:** Die Aktualisierung läuft in einer Transaktion bzw. einem Savepoint, falls bereits eine Transaktion offen ist. Bei einer Ausnahme wird zurückgerollt, eine Zeile mit Fehlermeldung und Fehlerzähler geliefert (unbenannte Spalten), der Fehler über `log.InsertError` protokolliert und anschließend dennoch `result = 1` geliefert.\n- **Sperren:** Die Prüfungen lesen mit `NOLOCK`; Aktualisierungen verwenden `ROWLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateOrderline"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ändert Bezeichnung, Menge, Preise, Rabatte, Notiz, Seriennummer und DF-Typ einer Auftragsposition oder Bundle-Position, sofern die Position noch änderbar ist.\n\nÄndert eine einzelne Auftragsposition (`OrderlineKey`) oder eine Bundle-Position (`BundleOrderlineKey`) und liefert eine Zeile `result` mit `1` (ausgeführt) oder `0` (abgelehnt).\n\n**Schlüsselwahl**\n- `BundleOrderlineKey = 0` wird als `NULL` behandelt.\n- Fehlen beide Schlüssel, wird eine Informationsmeldung ausgegeben und `result = 0` geliefert.\n- Ist `BundleOrderlineKey` gesetzt, wird `OrderlineKey` ignoriert.\n\n**Prüfung der Änderbarkeit**\nDie Position, bei einem Bundle jede Komponenten-Position, muss alle folgenden Bedingungen erfüllen:\n- ihr Auftragsstatus (`OrderStates`) ist kein Endstatus (`FinalState` ist `N` oder leer),\n- ihr Status ist nicht `EIN`,\n- sie ist nicht in einer Kiste verpackt (`boxitems`),\n- sie steht auf keiner Rechnung (`Invlines`).\n\nErfüllt eine einzige Position die Prüfung nicht, wird nichts geändert und `result = 0` geliefert.\n\n**Zusammenführen mit den aktuellen Werten**\nJeder nicht übergebene Parameter (`NULL`) behält den gespeicherten Wert der Position. Bei `ArtName`, `oItemSpecialNote` und `SerialNumber` behält auch ein Leerstring den gespeicherten Wert. Bei Bundles wird die Seriennummer nicht verarbeitet. Ist der resultierende `Price` höher als `FullPrice`, wird `FullPrice` auf `Price` angehoben. Dieselbe Regel gilt für die Nettowerte.\n\n**Aktualisierung**\nAnschließend wird die interne Prozedur `Pixi_UpdateOrderline` mit dem Bearbeiter `API` ausgeführt. Sie führt Folgendes aus:\n- aktualisiert die Auftragsposition bzw. Bundle-Position mit Menge, Brutto-/Nettopreis, Bestätigungsdatum, Bezeichnung, Notiz, Seriennummer, Vollpreisen, Rabattprozent/-wert und `DF_type`;\n- setzt bei Bundles zusätzlich `DF_type` auf allen Komponenten-Positionen;\n- schreibt die aktuellen Kopfwerte (Adressbemerkung, Geschenknachricht sowie bei vorhandener Versandanweisung auch Versandanweisung, `Verfahren`, `Product`, `Extras`) zurück in `OrderHeader`;\n- gleicht den Gutschein des Auftrags ab (siehe Hinweise);\n- baut die Reservierungen des gesamten Auftrags neu auf, wenn eine seiner Positionen eine Reservierung hat.\n\nZum Schluss wird `result = 1` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Nein | Schlüssel der zu ändernden Auftragsposition. Wird ignoriert, wenn `BundleOrderlineKey` gesetzt ist. |\n| `ArtName` | varchar(120) | Nein | Neue Artikelbezeichnung der Position. `NULL` oder leer behält die aktuelle Bezeichnung. |\n| `Qty` | int | Nein | Neue Menge. `NULL` behält die aktuelle Menge. |\n| `Price` | money | Nein | Neuer Stückpreis, wird auch als Ausgangswert für den Nettopreis verwendet. `NULL` behält den aktuellen Preis. |\n| `FullPrice` | money | Nein | Neuer Vollpreis (ohne Rabatt), wird auch als Netto-Vollpreis gespeichert. Wird auf `Price` angehoben, falls niedriger. `NULL` behält den aktuellen Wert. |\n| `oItemSpecialNote` | varchar(8000) | Nein | Notiz zur Position. `NULL` oder leer behält die aktuelle Notiz. |\n| `DiscountValue` | money | Nein | Rabattbetrag der Position. `NULL` behält den aktuellen Wert. |\n| `DiscountPerc` | float | Nein | Rabattprozent der Position, gespeichert mit zwei Nachkommastellen. `NULL` behält den aktuellen Wert. |\n| `DF_Type` | varchar(1) | Nein | Direct-Fulfillment-Typ der Position (`DF_type`). Bei Bundles auch auf alle Komponenten-Positionen übertragen. `NULL` behält den aktuellen Wert. |\n| `SerialNumber` | varchar(50) | Nein | Seriennummer der Auftragsposition. `NULL` oder leer behält den aktuellen Wert. Bei Bundle-Positionen nicht verarbeitet. |\n| `BundleOrderlineKey` | int | Nein | Schlüssel der zu ändernden Bundle-Position. `0` wird als `NULL` behandelt. Hat Vorrang vor `OrderlineKey`. |\n\n- **Nicht vorhandener Schlüssel:** Existiert `OrderlineKey` bzw. `BundleOrderlineKey` nicht, findet die Prüfung keine Zeile und lehnt den Aufruf nicht ab. Es wird nichts geändert, trotzdem wird `result = 1` geliefert.\n- **Meldungen statt Fehler:** Alle `RAISERROR`-Aufrufe verwenden Schweregrad 0. Sie kommen nur als `SqlMessage` an, nicht als SQL-Fehler.\n- **Rechnungsprüfung:** Findet `Pixi_UpdateOrderline` eine Rechnungsposition, gibt es seine Meldung aus und ändert nichts. Danach wird dennoch `result = 1` geliefert.\n- **Nettopreise:** Nettopreis und Netto-Vollpreis werden mit den übergebenen Bruttowerten (`Price`, `FullPrice`) vorbelegt. Der Positionspreis wird anschließend über `dbo.fPixi_CalculatePrices` (nicht beigefügt) anhand von Steuersatz und Auftragsart umgerechnet. `FullPrice_Net` wird ohne Umrechnung gespeichert und enthält nach Übergabe von `FullPrice` denselben Wert wie `FullPrice`.\n- **Datentypen:** `DiscountPerc` wird als `numeric(6,2)` weitergegeben und daher auf zwei Nachkommastellen gerundet. `GiftMessage` wird als `varchar(1000)` weitergegeben.\n- **Werte nicht leerbar:** `ArtName`, `oItemSpecialNote` und `SerialNumber` lassen sich über diesen Aufruf nicht leeren.\n- **Gutschein-Abgleich** (anhand des Gutscheincodes der Position und `OrderHeader.Discount`):\n - Existiert der Gutschein mit abweichendem Betrag, wird sein Betrag auf den Auftragsrabatt gesetzt.\n - Ist dieser Rabatt 0, wird `VoucherID` auf allen Positionen und Bundle-Positionen des Auftrags geleert.\n - Existiert der Gutschein nicht und ist der Code nicht `NULL`, wird ein Gutschein angelegt (gültig etwa ein Jahr ab Auftragsdatum, einmalig, Shop `GRM`) und allen Positionen des Auftrags zugeordnet.\n- **Reservierungen:** Reservierungen werden über `Pixi_Res_RemoveReservationForOrder` und `Pixi_Res_CreateReservationForOrder` entfernt und neu angelegt. Diese Prozeduren sind nicht beigefügt und können weitere Ausgaben erzeugen.\n- **Transaktionen und Fehler:** Die Aktualisierung läuft in einer Transaktion bzw. einem Savepoint, falls bereits eine Transaktion offen ist. Bei einer Ausnahme wird zurückgerollt, eine Zeile mit Fehlermeldung und Fehlerzähler geliefert (unbenannte Spalten), der Fehler über `log.InsertError` protokolliert und anschließend dennoch `result = 1` geliefert.\n- **Sperren:** Die Prüfungen lesen mit `NOLOCK`; Aktualisierungen verwenden `ROWLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateOrderline"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n \n"
}
]
}
]
},
{
"name": "Orders",
"item": [
{
"name": "pixiAddOrderComment",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100245\n Customer requests delivery after 2 pm.\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt die Shop-Notiz (`Shop_Note`) eines Auftrags anhand der Auftragsnummer und liefert 1 bei Erfolg oder 0, wenn der Auftrag fehlt oder maskiert ist.\n\nSchreibt einen Kommentar in das Feld für die Shop-Notiz eines Auftrags.\n\n1. Der Auftrag wird in `OrderHeader` über `OrderNr` gesucht. Existiert kein Auftrag, wird eine Zeile mit `ReturnMessage` = `0` geliefert und die Verarbeitung beendet.\n2. Es wird geprüft, ob der Auftrag bearbeitbar ist. Ein Auftrag gilt als nicht bearbeitbar (maskiert), wenn ein Auftragskopf-Attribut vom Typ `2` mit dem Wert `2` vorhanden ist. Bei einem maskierten Auftrag wird `ReturnMessage` = `0` geliefert und nichts geändert.\n3. Andernfalls wird `Shop_Note` des Auftrags auf `@Comment` gesetzt und `ReturnMessage` = `1` geliefert.\n\nTrotz des Namens wird der Kommentar **nicht angehängt**: Der bisherige Inhalt von `Shop_Note` wird vollständig ersetzt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Auftragsnummer des Auftrags, dessen Shop-Notiz gesetzt wird. |\n| `Comment` | nvarchar(max) | Ja | Text, der in `Shop_Note` geschrieben wird. Ersetzt die bisherige Notiz vollständig; `NULL` ergibt eine leere Notiz. |\n\n- Die bestehende Shop-Notiz wird überschrieben. Soll bisheriger Text erhalten bleiben, muss die aktuelle Notiz vorher gelesen und der kombinierte Text gesendet werden.\n- Ist `Comment` `NULL`, wird die Notiz auf eine leere Zeichenkette gesetzt (die Blacklist-Funktion ersetzt derzeit nur `NULL` durch `''`).\n- `ReturnMessage` = `0` unterscheidet nicht zwischen \"Auftrag nicht gefunden\" und \"Auftrag maskiert\".\n- Das Lesen des Auftrags und seiner Attribute erfolgt mit `NOLOCK`.\n- Das Update läuft in einer eigenen Transaktion bzw. in einem Savepoint, falls bereits eine Transaktion offen ist. Bei einem Fehler wird zurückgerollt und der Fehler über `log.InsertError` protokolliert (Definition nicht beigefügt); in diesem Fall liefert die Prozedur keine `ReturnMessage`-Zeile, und ob ein Fehler an den Aufrufer weitergegeben wird, hängt von `log.InsertError` ab.\n- Die Suche des Auftrags über `OrderNr` liegt außerhalb der Fehlerbehandlung; gäbe es mehrere Aufträge mit derselben `OrderNr`, würde die Unterabfrage mit einem SQL-Fehler abbrechen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAddOrderComment"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100245\n Customer requests delivery after 2 pm.\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt die Shop-Notiz (`Shop_Note`) eines Auftrags anhand der Auftragsnummer und liefert 1 bei Erfolg oder 0, wenn der Auftrag fehlt oder maskiert ist.\n\nSchreibt einen Kommentar in das Feld für die Shop-Notiz eines Auftrags.\n\n1. Der Auftrag wird in `OrderHeader` über `OrderNr` gesucht. Existiert kein Auftrag, wird eine Zeile mit `ReturnMessage` = `0` geliefert und die Verarbeitung beendet.\n2. Es wird geprüft, ob der Auftrag bearbeitbar ist. Ein Auftrag gilt als nicht bearbeitbar (maskiert), wenn ein Auftragskopf-Attribut vom Typ `2` mit dem Wert `2` vorhanden ist. Bei einem maskierten Auftrag wird `ReturnMessage` = `0` geliefert und nichts geändert.\n3. Andernfalls wird `Shop_Note` des Auftrags auf `@Comment` gesetzt und `ReturnMessage` = `1` geliefert.\n\nTrotz des Namens wird der Kommentar **nicht angehängt**: Der bisherige Inhalt von `Shop_Note` wird vollständig ersetzt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Auftragsnummer des Auftrags, dessen Shop-Notiz gesetzt wird. |\n| `Comment` | nvarchar(max) | Ja | Text, der in `Shop_Note` geschrieben wird. Ersetzt die bisherige Notiz vollständig; `NULL` ergibt eine leere Notiz. |\n\n- Die bestehende Shop-Notiz wird überschrieben. Soll bisheriger Text erhalten bleiben, muss die aktuelle Notiz vorher gelesen und der kombinierte Text gesendet werden.\n- Ist `Comment` `NULL`, wird die Notiz auf eine leere Zeichenkette gesetzt (die Blacklist-Funktion ersetzt derzeit nur `NULL` durch `''`).\n- `ReturnMessage` = `0` unterscheidet nicht zwischen \"Auftrag nicht gefunden\" und \"Auftrag maskiert\".\n- Das Lesen des Auftrags und seiner Attribute erfolgt mit `NOLOCK`.\n- Das Update läuft in einer eigenen Transaktion bzw. in einem Savepoint, falls bereits eine Transaktion offen ist. Bei einem Fehler wird zurückgerollt und der Fehler über `log.InsertError` protokolliert (Definition nicht beigefügt); in diesem Fall liefert die Prozedur keine `ReturnMessage`-Zeile, und ob ein Fehler an den Aufrufer weitergegeben wird, hängt von `log.InsertError` ab.\n- Die Suche des Auftrags über `OrderNr` liegt außerhalb der Fehlerbehandlung; gäbe es mehrere Aufträge mit derselben `OrderNr`, würde die Unterabfrage mit einem SQL-Fehler abbrechen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAddOrderComment"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n \n"
}
]
},
{
"name": "pixiCanChangeAddress",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert 1, wenn die Adresse eines Auftrags noch geändert werden darf, weil zu seinen Auftragspositionen keine Rechnungspositionen existieren, sonst 0.\n\nPrüft, ob die Adresse eines Auftrags noch geändert werden darf. Die Prüfung stützt sich ausschließlich darauf, ob der Auftrag bereits ganz oder teilweise berechnet wurde.\n\n1. Sind `OrderNr` und `OrderNrExternal` beide `NULL`, liefert die Funktion sofort `0`.\n2. Andernfalls werden die Auftragspositionen (`Orderlines`) des Auftrags ermittelt:\n - über `OrderNr`, wenn nur `OrderNr` angegeben ist, oder\n - über `OrderNrExternal`, wenn nur `OrderNrExternal` angegeben ist.\n3. Gezählt werden die Rechnungspositionen (`InvLines`), die über `OrderlineRef` auf eine dieser Auftragspositionen verweisen.\n4. Existiert mindestens eine Rechnungsposition (Auftrag zumindest teilweise berechnet), ist das Ergebnis `0`. Existiert keine, ist das Ergebnis `1`, und die Adresse darf geändert werden.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Interne Pixi-Auftragsnummer. Wird nur verwendet, wenn `OrderNrExternal` `NULL` ist. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer, z. B. die Shop-Bestellnummer. Wird nur verwendet, wenn `OrderNr` `NULL` ist. |\n\n- Nur **einen** der beiden Parameter übergeben. Sind beide angegeben, greift keine der Filterbedingungen. Es werden keine Auftragspositionen gefunden, und die Funktion liefert `1` (Änderung erlaubt), auch wenn der Auftrag berechnet ist.\n- Eine nicht existierende Auftragsnummer liefert ebenfalls `1`, da keine Rechnungspositionen gefunden werden. Eine Existenzprüfung des Auftrags findet nicht statt.\n- Beide Tabellen werden mit `NOLOCK` gelesen, das Ergebnis kann daher nicht festgeschriebene Daten widerspiegeln.\n- Geprüft werden nur Rechnungspositionen. Andere Zustände wie Versand oder Stornierung werden nicht berücksichtigt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCanChangeAddress"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert 1, wenn die Adresse eines Auftrags noch geändert werden darf, weil zu seinen Auftragspositionen keine Rechnungspositionen existieren, sonst 0.\n\nPrüft, ob die Adresse eines Auftrags noch geändert werden darf. Die Prüfung stützt sich ausschließlich darauf, ob der Auftrag bereits ganz oder teilweise berechnet wurde.\n\n1. Sind `OrderNr` und `OrderNrExternal` beide `NULL`, liefert die Funktion sofort `0`.\n2. Andernfalls werden die Auftragspositionen (`Orderlines`) des Auftrags ermittelt:\n - über `OrderNr`, wenn nur `OrderNr` angegeben ist, oder\n - über `OrderNrExternal`, wenn nur `OrderNrExternal` angegeben ist.\n3. Gezählt werden die Rechnungspositionen (`InvLines`), die über `OrderlineRef` auf eine dieser Auftragspositionen verweisen.\n4. Existiert mindestens eine Rechnungsposition (Auftrag zumindest teilweise berechnet), ist das Ergebnis `0`. Existiert keine, ist das Ergebnis `1`, und die Adresse darf geändert werden.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Interne Pixi-Auftragsnummer. Wird nur verwendet, wenn `OrderNrExternal` `NULL` ist. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer, z. B. die Shop-Bestellnummer. Wird nur verwendet, wenn `OrderNr` `NULL` ist. |\n\n- Nur **einen** der beiden Parameter übergeben. Sind beide angegeben, greift keine der Filterbedingungen. Es werden keine Auftragspositionen gefunden, und die Funktion liefert `1` (Änderung erlaubt), auch wenn der Auftrag berechnet ist.\n- Eine nicht existierende Auftragsnummer liefert ebenfalls `1`, da keine Rechnungspositionen gefunden werden. Eine Existenzprüfung des Auftrags findet nicht statt.\n- Beide Tabellen werden mit `NOLOCK` gelesen, das Ergebnis kann daher nicht festgeschriebene Daten widerspiegeln.\n- Geprüft werden nur Rechnungspositionen. Andere Zustände wie Versand oder Stornierung werden nicht berücksichtigt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCanChangeAddress"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n \n"
}
]
},
{
"name": "pixiCanMergeOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100234\n 100235\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Prüft, ob zwei Aufträge zusammengeführt werden können, und liefert ein Kennzeichen sowie einen Grundcode mit Text.\n\nPrüft, ob der Quellauftrag (`SourceOrderNr`) in den Zielauftrag (`TargetOrderNr`) zusammengeführt werden kann. Der Aufruf ändert keine Daten.\n\nDie Prüfungen laufen in dieser Reihenfolge. Die erste fehlschlagende Prüfung setzt `CanMerge = 0` und den passenden Grund. Die weiteren Prüfungen entfallen dann:\n\n1. **Beide Aufträge vorhanden**: In `OrderHeader` müssen für die beiden Auftragsnummern genau zwei Zeilen existieren. Andernfalls lautet der Grund `401`.\n2. **Gleicher Kunde**: `CustRef` beider Aufträge muss übereinstimmen. Andernfalls lautet der Grund `402`.\n3. **Status der Auftragspositionen**: Keine Auftragsposition der beiden Aufträge darf einen anderen Status als `ANG` haben. Andernfalls lautet der Grund `403`.\n4. **Zahlungsart**: `APayment` der über `AddrRef` referenzierten Adressen muss gleich sein und darf nicht `K` (Kreditkarte) sein. Andernfalls lautet der Grund `404`.\n5. **Picklisten**: Keine Auftragsposition der beiden Aufträge darf auf einer Pickliste stehen, deren `PLHexpiryDate` in der Zukunft liegt und deren `ReservedOrderNr` leer oder 0 ist. Andernfalls lautet der Grund `405`.\n6. **Währung und Auftragsart**: `CurrencyId` muss übereinstimmen, sonst lautet der Grund `406`. Danach muss `OrderType` übereinstimmen, sonst lautet der Grund `407`.\n\nSind alle Prüfungen erfolgreich, liefert der Aufruf `CanMerge = 1` und `Reason = '200 OK'`. Er liefert immer genau eine Zeile mit `CanMerge` und `Reason`. Dieselben Werte werden in die Ausgabeparameter geschrieben, und `CanMerge` ist zusätzlich der Rückgabewert der Prozedur.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TargetOrderNr` | int | Ja | Auftragsnummer des Zielauftrags, in den der Quellauftrag zusammengeführt würde. |\n| `SourceOrderNr` | int | Ja | Auftragsnummer des Quellauftrags, der in den Zielauftrag zusammengeführt würde. |\n| `CanMerge` | int | Nein | Ausgabe: 1, wenn die Aufträge zusammengeführt werden können, sonst 0. Ein übergebener Wert wird ignoriert. |\n| `Reason` | varchar(128) | Nein | Ausgabe: Grundcode mit Text, z. B. `200 OK` oder `402 Orders must belong to the same customer`. Ein übergebener Wert wird ignoriert. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, das Ergebnis kann daher auf nicht festgeschriebenen Daten beruhen. Unmittelbar vor dem eigentlichen Zusammenführen erneut prüfen.\n- Sind `TargetOrderNr` und `SourceOrderNr` gleich, wird nur eine Kopfzeile gefunden, das Ergebnis ist dann `401`.\n- Ein `NULL`-Wert in `CustRef`, `APayment`, `CurrencyId` oder `OrderType` lässt den Vergleich fehlschlagen und führt zum jeweiligen Fehlercode.\n- Aufträge ohne Auftragspositionen bestehen die Statusprüfung (`403`).\n- Wird die Adresse eines Auftrags (`AddrRef`) nicht in `Addresses` gefunden, liefert der Join keine Zeile, und die Zahlungsartprüfung (`404`) entfällt faktisch.\n- Die Spalte `ReservedOrderNr` in der Picklistenprüfung ist nicht mit einem Tabellennamen qualifiziert. Aus dem Code geht nicht hervor, ob sie zu `PLitem` oder `plheader` gehört.\n- Der Grundtext beginnt mit einem HTTP-ähnlichen numerischen Code (`200`, `401`–`407`), der sich für die programmatische Auswertung eignet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCanMergeOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100234\n 100235\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Prüft, ob zwei Aufträge zusammengeführt werden können, und liefert ein Kennzeichen sowie einen Grundcode mit Text.\n\nPrüft, ob der Quellauftrag (`SourceOrderNr`) in den Zielauftrag (`TargetOrderNr`) zusammengeführt werden kann. Der Aufruf ändert keine Daten.\n\nDie Prüfungen laufen in dieser Reihenfolge. Die erste fehlschlagende Prüfung setzt `CanMerge = 0` und den passenden Grund. Die weiteren Prüfungen entfallen dann:\n\n1. **Beide Aufträge vorhanden**: In `OrderHeader` müssen für die beiden Auftragsnummern genau zwei Zeilen existieren. Andernfalls lautet der Grund `401`.\n2. **Gleicher Kunde**: `CustRef` beider Aufträge muss übereinstimmen. Andernfalls lautet der Grund `402`.\n3. **Status der Auftragspositionen**: Keine Auftragsposition der beiden Aufträge darf einen anderen Status als `ANG` haben. Andernfalls lautet der Grund `403`.\n4. **Zahlungsart**: `APayment` der über `AddrRef` referenzierten Adressen muss gleich sein und darf nicht `K` (Kreditkarte) sein. Andernfalls lautet der Grund `404`.\n5. **Picklisten**: Keine Auftragsposition der beiden Aufträge darf auf einer Pickliste stehen, deren `PLHexpiryDate` in der Zukunft liegt und deren `ReservedOrderNr` leer oder 0 ist. Andernfalls lautet der Grund `405`.\n6. **Währung und Auftragsart**: `CurrencyId` muss übereinstimmen, sonst lautet der Grund `406`. Danach muss `OrderType` übereinstimmen, sonst lautet der Grund `407`.\n\nSind alle Prüfungen erfolgreich, liefert der Aufruf `CanMerge = 1` und `Reason = '200 OK'`. Er liefert immer genau eine Zeile mit `CanMerge` und `Reason`. Dieselben Werte werden in die Ausgabeparameter geschrieben, und `CanMerge` ist zusätzlich der Rückgabewert der Prozedur.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TargetOrderNr` | int | Ja | Auftragsnummer des Zielauftrags, in den der Quellauftrag zusammengeführt würde. |\n| `SourceOrderNr` | int | Ja | Auftragsnummer des Quellauftrags, der in den Zielauftrag zusammengeführt würde. |\n| `CanMerge` | int | Nein | Ausgabe: 1, wenn die Aufträge zusammengeführt werden können, sonst 0. Ein übergebener Wert wird ignoriert. |\n| `Reason` | varchar(128) | Nein | Ausgabe: Grundcode mit Text, z. B. `200 OK` oder `402 Orders must belong to the same customer`. Ein übergebener Wert wird ignoriert. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, das Ergebnis kann daher auf nicht festgeschriebenen Daten beruhen. Unmittelbar vor dem eigentlichen Zusammenführen erneut prüfen.\n- Sind `TargetOrderNr` und `SourceOrderNr` gleich, wird nur eine Kopfzeile gefunden, das Ergebnis ist dann `401`.\n- Ein `NULL`-Wert in `CustRef`, `APayment`, `CurrencyId` oder `OrderType` lässt den Vergleich fehlschlagen und führt zum jeweiligen Fehlercode.\n- Aufträge ohne Auftragspositionen bestehen die Statusprüfung (`403`).\n- Wird die Adresse eines Auftrags (`AddrRef`) nicht in `Addresses` gefunden, liefert der Join keine Zeile, und die Zahlungsartprüfung (`404`) entfällt faktisch.\n- Die Spalte `ReservedOrderNr` in der Picklistenprüfung ist nicht mit einem Tabellennamen qualifiziert. Aus dem Code geht nicht hervor, ob sie zu `PLitem` oder `plheader` gehört.\n- Der Grundtext beginnt mit einem HTTP-ähnlichen numerischen Code (`200`, `401`–`407`), der sich für die programmatische Auswertung eignet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCanMergeOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 0\n 403 All involved orderlines must have status ANG\n \n"
}
]
},
{
"name": "pixiChangeAddress",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n S\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ändert die Rechnungs- oder Lieferadresse eines Auftrags, solange der Auftrag noch nicht berechnet wurde.\n\nAktualisiert den Adressdatensatz, der mit einem Auftrag verknüpft ist, und liefert einen Statustext.\n\n1. Der Auftrag wird **entweder** über `OrderNr` **oder** über `OrderNrExternal` bestimmt. `OrderNr = 0` und ein leerer Wert für `OrderNrExternal` gelten als nicht gesetzt.\n2. Die Funktion `pipiCanChangeAddress` prüft, ob die Adresse geändert werden darf. Sie liefert 0, wenn kein Auftrag angegeben ist oder zu einer Auftragsposition bereits eine Rechnungsposition (`InvLines`) existiert. Andernfalls liefert sie 1.\n3. Der Adressschlüssel wird aus den Auftragspositionen (`Orderlines`) gelesen:\n - Enthält `AddrType` ein `B` (ohne Beachtung der Groß-/Kleinschreibung), wird die Rechnungsadresse (`AddrRef`) verwendet.\n - Andernfalls wird die Lieferadresse (`ShipAdrRef`) verwendet. Das gilt auch für `S`, andere Werte und einen leeren Wert.\n4. Ist die Änderung erlaubt und wurde eine Adresse gefunden, wird die Adresse aktualisiert:\n - Leere Zeichenketten gelten als „nicht übergeben“. Jeder nicht übergebene Parameter behält den aktuellen Wert der Adresse. Es werden nur die übergebenen Felder geändert.\n - `ASlocked` setzt die Versandsperre: `1` setzt `ASlocked = 'Y'`, jeder andere numerische Wert setzt `'N'`. Fehlt der Parameter, bleibt der aktuelle Wert erhalten.\n - Bei Lieferadressen (`AddrType = 'S'` in `Addresses`) wird bei einer Änderung der Sperre ein Eintrag in `pixi.AddressesShippingLockHistory` geschrieben.\n - `UpdateDate` wird auf das aktuelle Datum gesetzt, `UpdateEmp` auf `api`.\n5. Der Status wird im Ausgabeparameter `FunctionResult` und als eine Zeile mit der Spalte `Result` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. 0 wird als NULL behandelt. Entweder diesen Wert oder `OrderNrExternal` übergeben, nicht beide. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer (Shop). Eine leere Zeichenkette wird als NULL behandelt. Wird nur verwendet, wenn `OrderNr` nicht gesetzt ist. |\n| `AddrType` | char(2) | Ja | Legt fest, welche Adresse des Auftrags geändert wird. Ein Wert mit `B` wählt die Rechnungsadresse, alle anderen Werte wählen die Lieferadresse. |\n| `Anrede` | varchar(60) | Nein | Anrede. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `FirstName` | varchar(60) | Nein | Vorname. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `LastName` | varchar(60) | Nein | Nachname. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `CareOf` | varchar(60) | Nein | Adresszusatz (c/o). Fehlt der Wert, bleibt der aktuelle Wert erhalten. Anders als bei den übrigen Feldern wird eine leere Zeichenkette als leere Zeichenkette gespeichert. |\n| `Street` | varchar(100) | Nein | Straße. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `HouseNr` | varchar(12) | Nein | Hausnummer. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `City` | varchar(50) | Nein | Ort. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `State` | varchar(3) | Nein | Bundesland bzw. Region. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `ZIP` | varchar(10) | Nein | Postleitzahl. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `Country` | varchar(3) | Nein | Ländercode. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `Phone` | varchar(60) | Nein | Telefonnummer. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `Phone2` | varchar(60) | Nein | Zweite Telefonnummer. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `Fax` | varchar(60) | Nein | Faxnummer. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `Fax2` | varchar(60) | Nein | Zweite Faxnummer. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `eMail` | varchar(60) | Nein | E-Mail-Adresse. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `Account` | varchar(10) | Nein | Kontonummer (Spalte `AAccount`). Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `BLZ` | varchar(8) | Nein | Bankleitzahl (Spalte `ABLZ`). Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `BankName` | varchar(50) | Nein | Name der Bank (Spalte `ABankName`). Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `AccName` | varchar(27) | Nein | Kontoinhaber (Spalte `AAccName`). Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `BIC` | varchar(11) | Nein | BIC. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `IBAN` | varchar(35) | Nein | IBAN. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `ASlocked` | varchar(1) | Nein | Versandsperre. `1` speichert `Y`, jeder andere numerische Wert speichert `N`. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. Nicht numerische Werte führen zu einem Konvertierungsfehler. |\n| `FunctionResult` | varchar(128) | Nein | Ausgabe: Statustext, z. B. `200 OK`. Derselbe Text wird in der Spalte `Result` zurückgegeben. |\n| `CardHolderName` | varchar(60) | Nein | Name des Karteninhabers (Spalte `ACardName`). Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `Note` | varchar(8000) | Nein | Notiz zur Adresse. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `VatId` | varchar(20) | Nein | USt-IdNr. (Spalte `UsStId`). Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n\n- **Nur eine Auftragskennung übergeben.** Werden `OrderNr` und `OrderNrExternal` gleichzeitig übergeben, passt keine Auftragsposition. Das Ergebnis ist dann `402 Address not found`.\n- **Felder können nicht geleert werden.** Leere Werte werden ignoriert, der bisherige Wert bleibt erhalten. Ausnahme ist `CareOf`: Eine leere Zeichenkette wird als leere Zeichenkette gespeichert.\n- **`ASlocked` muss numerisch sein.** Der Code vergleicht den Wert mit der Zahl 1. Ein Wert wie `Y` führt daher zu einem SQL-Konvertierungsfehler, der als `SqlMessage` zurückkommt. `1` oder `0` verwenden.\n- **Sperrhistorie.** Der Historieneintrag wird nur geschrieben, wenn sich der gespeicherte Wert von `ASlocked` vom neuen Wert unterscheidet. Ist der gespeicherte Wert NULL, wird kein Eintrag geschrieben. Als Benutzer-ID der Historie dient der Benutzer `api`, ersatzweise `pixiAdministration`.\n- **Aufträge mit mehreren Positionen.** Der Adressschlüssel wird aus einer der Auftragspositionen übernommen; der Code legt nicht fest, aus welcher. Aufträge, deren Positionen auf unterschiedliche Adressen verweisen, werden nicht gesondert behandelt.\n- **Lesezugriffe und Transaktionen.** Auftragspositionen und Adressen werden mit `NOLOCK` gelesen. Es gibt keine explizite Transaktion.\n- **Statuscodes.** Die Codes 200–403 sind reine Textcodes und keine HTTP-Status. Ist weder eine Änderung erlaubt noch eine Adresse gefunden, überschreibt `402` den Wert `401`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiChangeAddress"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n S\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ändert die Rechnungs- oder Lieferadresse eines Auftrags, solange der Auftrag noch nicht berechnet wurde.\n\nAktualisiert den Adressdatensatz, der mit einem Auftrag verknüpft ist, und liefert einen Statustext.\n\n1. Der Auftrag wird **entweder** über `OrderNr` **oder** über `OrderNrExternal` bestimmt. `OrderNr = 0` und ein leerer Wert für `OrderNrExternal` gelten als nicht gesetzt.\n2. Die Funktion `pipiCanChangeAddress` prüft, ob die Adresse geändert werden darf. Sie liefert 0, wenn kein Auftrag angegeben ist oder zu einer Auftragsposition bereits eine Rechnungsposition (`InvLines`) existiert. Andernfalls liefert sie 1.\n3. Der Adressschlüssel wird aus den Auftragspositionen (`Orderlines`) gelesen:\n - Enthält `AddrType` ein `B` (ohne Beachtung der Groß-/Kleinschreibung), wird die Rechnungsadresse (`AddrRef`) verwendet.\n - Andernfalls wird die Lieferadresse (`ShipAdrRef`) verwendet. Das gilt auch für `S`, andere Werte und einen leeren Wert.\n4. Ist die Änderung erlaubt und wurde eine Adresse gefunden, wird die Adresse aktualisiert:\n - Leere Zeichenketten gelten als „nicht übergeben“. Jeder nicht übergebene Parameter behält den aktuellen Wert der Adresse. Es werden nur die übergebenen Felder geändert.\n - `ASlocked` setzt die Versandsperre: `1` setzt `ASlocked = 'Y'`, jeder andere numerische Wert setzt `'N'`. Fehlt der Parameter, bleibt der aktuelle Wert erhalten.\n - Bei Lieferadressen (`AddrType = 'S'` in `Addresses`) wird bei einer Änderung der Sperre ein Eintrag in `pixi.AddressesShippingLockHistory` geschrieben.\n - `UpdateDate` wird auf das aktuelle Datum gesetzt, `UpdateEmp` auf `api`.\n5. Der Status wird im Ausgabeparameter `FunctionResult` und als eine Zeile mit der Spalte `Result` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. 0 wird als NULL behandelt. Entweder diesen Wert oder `OrderNrExternal` übergeben, nicht beide. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer (Shop). Eine leere Zeichenkette wird als NULL behandelt. Wird nur verwendet, wenn `OrderNr` nicht gesetzt ist. |\n| `AddrType` | char(2) | Ja | Legt fest, welche Adresse des Auftrags geändert wird. Ein Wert mit `B` wählt die Rechnungsadresse, alle anderen Werte wählen die Lieferadresse. |\n| `Anrede` | varchar(60) | Nein | Anrede. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `FirstName` | varchar(60) | Nein | Vorname. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `LastName` | varchar(60) | Nein | Nachname. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `CareOf` | varchar(60) | Nein | Adresszusatz (c/o). Fehlt der Wert, bleibt der aktuelle Wert erhalten. Anders als bei den übrigen Feldern wird eine leere Zeichenkette als leere Zeichenkette gespeichert. |\n| `Street` | varchar(100) | Nein | Straße. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `HouseNr` | varchar(12) | Nein | Hausnummer. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `City` | varchar(50) | Nein | Ort. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `State` | varchar(3) | Nein | Bundesland bzw. Region. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `ZIP` | varchar(10) | Nein | Postleitzahl. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `Country` | varchar(3) | Nein | Ländercode. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `Phone` | varchar(60) | Nein | Telefonnummer. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `Phone2` | varchar(60) | Nein | Zweite Telefonnummer. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `Fax` | varchar(60) | Nein | Faxnummer. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `Fax2` | varchar(60) | Nein | Zweite Faxnummer. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `eMail` | varchar(60) | Nein | E-Mail-Adresse. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `Account` | varchar(10) | Nein | Kontonummer (Spalte `AAccount`). Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `BLZ` | varchar(8) | Nein | Bankleitzahl (Spalte `ABLZ`). Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `BankName` | varchar(50) | Nein | Name der Bank (Spalte `ABankName`). Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `AccName` | varchar(27) | Nein | Kontoinhaber (Spalte `AAccName`). Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `BIC` | varchar(11) | Nein | BIC. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `IBAN` | varchar(35) | Nein | IBAN. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `ASlocked` | varchar(1) | Nein | Versandsperre. `1` speichert `Y`, jeder andere numerische Wert speichert `N`. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. Nicht numerische Werte führen zu einem Konvertierungsfehler. |\n| `FunctionResult` | varchar(128) | Nein | Ausgabe: Statustext, z. B. `200 OK`. Derselbe Text wird in der Spalte `Result` zurückgegeben. |\n| `CardHolderName` | varchar(60) | Nein | Name des Karteninhabers (Spalte `ACardName`). Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `Note` | varchar(8000) | Nein | Notiz zur Adresse. Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n| `VatId` | varchar(20) | Nein | USt-IdNr. (Spalte `UsStId`). Bei leerem oder fehlendem Wert bleibt der aktuelle Wert erhalten. |\n\n- **Nur eine Auftragskennung übergeben.** Werden `OrderNr` und `OrderNrExternal` gleichzeitig übergeben, passt keine Auftragsposition. Das Ergebnis ist dann `402 Address not found`.\n- **Felder können nicht geleert werden.** Leere Werte werden ignoriert, der bisherige Wert bleibt erhalten. Ausnahme ist `CareOf`: Eine leere Zeichenkette wird als leere Zeichenkette gespeichert.\n- **`ASlocked` muss numerisch sein.** Der Code vergleicht den Wert mit der Zahl 1. Ein Wert wie `Y` führt daher zu einem SQL-Konvertierungsfehler, der als `SqlMessage` zurückkommt. `1` oder `0` verwenden.\n- **Sperrhistorie.** Der Historieneintrag wird nur geschrieben, wenn sich der gespeicherte Wert von `ASlocked` vom neuen Wert unterscheidet. Ist der gespeicherte Wert NULL, wird kein Eintrag geschrieben. Als Benutzer-ID der Historie dient der Benutzer `api`, ersatzweise `pixiAdministration`.\n- **Aufträge mit mehreren Positionen.** Der Adressschlüssel wird aus einer der Auftragspositionen übernommen; der Code legt nicht fest, aus welcher. Aufträge, deren Positionen auf unterschiedliche Adressen verweisen, werden nicht gesondert behandelt.\n- **Lesezugriffe und Transaktionen.** Auftragspositionen und Adressen werden mit `NOLOCK` gelesen. Es gibt keine explizite Transaktion.\n- **Statuscodes.** Die Codes 200–403 sind reine Textcodes und keine HTTP-Status. Ist weder eine Änderung erlaubt noch eine Adresse gefunden, überschreibt `402` den Wert `401`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiChangeAddress"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 200 OK\n \n"
}
]
},
{
"name": "pixiCreateOrderComment",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen Freitext-Kommentar zu einem bestehenden Auftrag an und speichert Benutzer und Erstellungszeitpunkt.\n\nLegt einen neuen Eintrag in den Auftragskommentaren für den angegebenen Auftrag an.\n\nAblauf:\n\n1. **Prüfung:** Fehlt `OrderNr` oder ist sie `0`, oder fehlt `Comment` bzw. ist er leer, liefert der Aufruf eine Fehlerzeile und bricht ab.\n2. **Auftragsprüfung:** Der Aufruf zählt die Aufträge in `OrderHeader` mit der angegebenen `OrderNr`. Existiert keiner, wird eine Fehlerzeile mit der Auftragsnummer geliefert.\n3. **Anlage:** Andernfalls wird eine Zeile in `OrderComments` eingefügt, mit Auftragsnummer, Kommentartext, dem Wert von `User` als anlegendem Mitarbeiter (`CreateEmp`) und der aktuellen Serverzeit als `CreateDate`.\n4. Anschließend wird eine einzelne Zeile mit `ReturnCode` = `SUCCESS` geliefert.\n\nJeder Aufruf legt einen neuen Kommentar an. Bestehende Kommentare werden nie geändert oder ersetzt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Interne Pixi-Auftragsnummer (`OrderHeader.OrderNr`), zu der der Kommentar angelegt wird. Muss gesetzt und ungleich `0` sein, sonst wird eine Fehlerzeile geliefert. |\n| `Comment` | varchar(max) | Nein | Text des Kommentars. Darf nicht leer sein, sonst wird eine Fehlerzeile geliefert. |\n| `User` | varchar(50) | Nein | Name oder Kürzel des Benutzers, der als Ersteller des Kommentars (`CreateEmp`) gespeichert wird. |\n\n- Der Kopfkommentar im Code besagt, dass die Prozedur Auftragskommentare *liest*; das ist falsch. Die Prozedur legt ausschließlich einen Kommentar an.\n- Die Ergebniszeile hat unterschiedliche Formen: Fehlerzeilen enthalten die Spalten `ReturnCode` und `ErrorMsg`, die Erfolgszeile nur `ReturnCode`. Clients sollten zuerst `ReturnCode` auswerten.\n- Es wird keine explizite Transaktion verwendet. Ein erneuter Aufruf legt einen doppelten Kommentar an; Wiederholungen nach Timeouts können daher zu Doppeleinträgen führen.\n- `CreateDate` wird mit `CURRENT_TIMESTAMP` gesetzt, also mit der lokalen Zeit des Datenbankservers.\n- `Comment` ist `varchar`, nicht `nvarchar`; Zeichen außerhalb der Codepage der Datenbank können verloren gehen.\n- Da SQL Server nachfolgende Leerzeichen beim Stringvergleich ignoriert, wird ein Kommentar, der nur aus Leerzeichen besteht, als leer abgewiesen.\n- Werte für `User` mit mehr als 50 Zeichen werden durch den Parametertyp abgeschnitten.\n- Der Auftrag wird ausschließlich über die interne `OrderNr` identifiziert; eine externe Auftragsnummer wird nicht unterstützt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateOrderComment"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen Freitext-Kommentar zu einem bestehenden Auftrag an und speichert Benutzer und Erstellungszeitpunkt.\n\nLegt einen neuen Eintrag in den Auftragskommentaren für den angegebenen Auftrag an.\n\nAblauf:\n\n1. **Prüfung:** Fehlt `OrderNr` oder ist sie `0`, oder fehlt `Comment` bzw. ist er leer, liefert der Aufruf eine Fehlerzeile und bricht ab.\n2. **Auftragsprüfung:** Der Aufruf zählt die Aufträge in `OrderHeader` mit der angegebenen `OrderNr`. Existiert keiner, wird eine Fehlerzeile mit der Auftragsnummer geliefert.\n3. **Anlage:** Andernfalls wird eine Zeile in `OrderComments` eingefügt, mit Auftragsnummer, Kommentartext, dem Wert von `User` als anlegendem Mitarbeiter (`CreateEmp`) und der aktuellen Serverzeit als `CreateDate`.\n4. Anschließend wird eine einzelne Zeile mit `ReturnCode` = `SUCCESS` geliefert.\n\nJeder Aufruf legt einen neuen Kommentar an. Bestehende Kommentare werden nie geändert oder ersetzt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Interne Pixi-Auftragsnummer (`OrderHeader.OrderNr`), zu der der Kommentar angelegt wird. Muss gesetzt und ungleich `0` sein, sonst wird eine Fehlerzeile geliefert. |\n| `Comment` | varchar(max) | Nein | Text des Kommentars. Darf nicht leer sein, sonst wird eine Fehlerzeile geliefert. |\n| `User` | varchar(50) | Nein | Name oder Kürzel des Benutzers, der als Ersteller des Kommentars (`CreateEmp`) gespeichert wird. |\n\n- Der Kopfkommentar im Code besagt, dass die Prozedur Auftragskommentare *liest*; das ist falsch. Die Prozedur legt ausschließlich einen Kommentar an.\n- Die Ergebniszeile hat unterschiedliche Formen: Fehlerzeilen enthalten die Spalten `ReturnCode` und `ErrorMsg`, die Erfolgszeile nur `ReturnCode`. Clients sollten zuerst `ReturnCode` auswerten.\n- Es wird keine explizite Transaktion verwendet. Ein erneuter Aufruf legt einen doppelten Kommentar an; Wiederholungen nach Timeouts können daher zu Doppeleinträgen führen.\n- `CreateDate` wird mit `CURRENT_TIMESTAMP` gesetzt, also mit der lokalen Zeit des Datenbankservers.\n- `Comment` ist `varchar`, nicht `nvarchar`; Zeichen außerhalb der Codepage der Datenbank können verloren gehen.\n- Da SQL Server nachfolgende Leerzeichen beim Stringvergleich ignoriert, wird ein Kommentar, der nur aus Leerzeichen besteht, als leer abgewiesen.\n- Werte für `User` mit mehr als 50 Zeichen werden durch den Parametertyp abgeschnitten.\n- Der Auftrag wird ausschließlich über die interne `OrderNr` identifiziert; eine externe Auftragsnummer wird nicht unterstützt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateOrderComment"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n SUCCESS\n \n"
}
]
},
{
"name": "pixiDeleteOrder",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht einen kompletten Auftrag, sofern alle Auftragspositionen den Status ANG, HAL oder STO haben und keine auf einer aktiven Pickliste steht.\n\nLöscht den über `OrderNr` angegebenen Auftrag samt abhängigen Daten und liefert eine Statuszeile.\n\n**Prüfungen** (vor jeder Änderung):\n1. Der Auftragskopf wird über `OrderNr` gesucht und mit Auftragspositionen, Bankzuordnungen, Kundenkonto-Ereignissen und Picklistenpositionen verknüpft. Wird keine Zeile gefunden, lautet das Ergebnis `404`.\n2. Hat eine Auftragsposition einen anderen Status als `ANG`, `HAL` oder `STO`, lautet das Ergebnis `409`.\n3. Steht eine Auftragsposition auf einer Pickliste, deren Ablaufdatum (`PLHexpiryDate`) in der Zukunft liegt, lautet das Ergebnis `409` mit der Picklisten-Meldung. Diese Prüfung läuft zuletzt, ihre Meldung gewinnt also, wenn beide 409-Bedingungen zutreffen.\n\nSchlägt eine Prüfung fehl, wird nichts geändert.\n\n**Löschschritte** (in einer Transaktion):\n- Für jede Auftragsposition wird ein `OrderHistory`-Eintrag mit Status `NEW` und Mitarbeiter `API` geschrieben.\n- Die Auftragspositionen werden **nicht physisch gelöscht**, sondern vom Auftrag gelöst und zurückgesetzt: `OrderNr`, `CustRef`, `AddrRef`, `ShipAdrRef` werden `0`, `Status` wird `NEW`, `UpdateEmp` wird `API`, Menge, Preise, Beträge, Rabatte, Steuer und Versandkosten werden `0`, `ItemRef`, `ShipRef`, `Order_Id`, `BundleOrderlineRef` werden NULL.\n- Referenzierte Bundle-Positionen (`BundleOrderlines`) werden gelöscht.\n- Auftragskopf-Attribute (`OrderHeaderAttribute`) werden gelöscht.\n- Reservierungen (`Reservation`) der Auftragspositionen werden gelöscht.\n- Das mit der Bankzuordnung des Auftrags verknüpfte Kundenkonto-Ereignis wird über `Pixi_CA_DeleteEvent` gelöscht (dabei können auch die zugehörige Rechnung, Bankzuordnungen, Kundenkonto-Matches, DTAUS-Datensätze oder manuelle Buchungen gelöscht werden).\n- Abschließend löscht `Pixi_DeleteEmptyOrder` Picklisten-Prüfeinträge, Tag-Zuordnungen, restliche Kopfattribute und den Auftragskopf selbst.\n\nBei Erfolg enthält die Statuszeile `200` und einen Bestätigungstext. Unerwartete SQL-Fehler werden protokolliert und als `500` mit der SQL-Fehlermeldung zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Nummer des zu löschenden Auftrags (`OrderHeader.OrderNr`). |\n\n- Die Kandidatendaten werden mit `NOLOCK` gelesen; Änderungen nutzen `ROWLOCK`. `XACT_ABORT` ist aktiv. Besteht beim Aufrufer bereits eine Transaktion, wird statt einer neuen Transaktion ein Savepoint gesetzt.\n- `CONTEXT_INFO` wird zeitweise gesetzt, um die Trigger auf `Orderlines` und `Reservation` zu umgehen; deren Triggerlogik läuft für diese Änderungen also nicht.\n- Stolperfalle: Die Prozedur legt einen eindeutigen Index auf den Positionsschlüssel der Kandidatendaten an. Kommt eine Auftragsposition in den verknüpften Daten mehrfach vor (z. B. mehrere Bankzuordnungen zum Auftrag oder die Position steht auf mehreren Picklisten, auch abgelaufenen), schlägt die Indexerstellung fehl und der Aufruf liefert `500`.\n- Es wird nur ein Kundenkonto-Ereignis gelöscht (`TOP 1` ohne Sortierung), auch wenn mehrere Bankzuordnungen existieren. Ob es gelöscht werden darf, entscheidet `fPixi_CA_canIdeleteEvent`; Rechnungen werden über `Pixi_DeleteInvoice` entfernt. Beide Objekte liegen nicht vor, ihr genaues Verhalten ist daher hier nicht dokumentiert.\n- `Pixi_CA_DeleteEvent` rollt bei einem Fehler die gesamte Transaktion zurück und wirft die Meldung erneut; sie kommt dann als Status `500` zurück.\n- Fehler in `Pixi_DeleteEmptyOrder` werden dort über `log.InsertError` protokolliert und nicht weitergereicht.\n- Auch bei 404 oder 409 wird eine leere Transaktion geöffnet und committet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDeleteOrder"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht einen kompletten Auftrag, sofern alle Auftragspositionen den Status ANG, HAL oder STO haben und keine auf einer aktiven Pickliste steht.\n\nLöscht den über `OrderNr` angegebenen Auftrag samt abhängigen Daten und liefert eine Statuszeile.\n\n**Prüfungen** (vor jeder Änderung):\n1. Der Auftragskopf wird über `OrderNr` gesucht und mit Auftragspositionen, Bankzuordnungen, Kundenkonto-Ereignissen und Picklistenpositionen verknüpft. Wird keine Zeile gefunden, lautet das Ergebnis `404`.\n2. Hat eine Auftragsposition einen anderen Status als `ANG`, `HAL` oder `STO`, lautet das Ergebnis `409`.\n3. Steht eine Auftragsposition auf einer Pickliste, deren Ablaufdatum (`PLHexpiryDate`) in der Zukunft liegt, lautet das Ergebnis `409` mit der Picklisten-Meldung. Diese Prüfung läuft zuletzt, ihre Meldung gewinnt also, wenn beide 409-Bedingungen zutreffen.\n\nSchlägt eine Prüfung fehl, wird nichts geändert.\n\n**Löschschritte** (in einer Transaktion):\n- Für jede Auftragsposition wird ein `OrderHistory`-Eintrag mit Status `NEW` und Mitarbeiter `API` geschrieben.\n- Die Auftragspositionen werden **nicht physisch gelöscht**, sondern vom Auftrag gelöst und zurückgesetzt: `OrderNr`, `CustRef`, `AddrRef`, `ShipAdrRef` werden `0`, `Status` wird `NEW`, `UpdateEmp` wird `API`, Menge, Preise, Beträge, Rabatte, Steuer und Versandkosten werden `0`, `ItemRef`, `ShipRef`, `Order_Id`, `BundleOrderlineRef` werden NULL.\n- Referenzierte Bundle-Positionen (`BundleOrderlines`) werden gelöscht.\n- Auftragskopf-Attribute (`OrderHeaderAttribute`) werden gelöscht.\n- Reservierungen (`Reservation`) der Auftragspositionen werden gelöscht.\n- Das mit der Bankzuordnung des Auftrags verknüpfte Kundenkonto-Ereignis wird über `Pixi_CA_DeleteEvent` gelöscht (dabei können auch die zugehörige Rechnung, Bankzuordnungen, Kundenkonto-Matches, DTAUS-Datensätze oder manuelle Buchungen gelöscht werden).\n- Abschließend löscht `Pixi_DeleteEmptyOrder` Picklisten-Prüfeinträge, Tag-Zuordnungen, restliche Kopfattribute und den Auftragskopf selbst.\n\nBei Erfolg enthält die Statuszeile `200` und einen Bestätigungstext. Unerwartete SQL-Fehler werden protokolliert und als `500` mit der SQL-Fehlermeldung zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Nummer des zu löschenden Auftrags (`OrderHeader.OrderNr`). |\n\n- Die Kandidatendaten werden mit `NOLOCK` gelesen; Änderungen nutzen `ROWLOCK`. `XACT_ABORT` ist aktiv. Besteht beim Aufrufer bereits eine Transaktion, wird statt einer neuen Transaktion ein Savepoint gesetzt.\n- `CONTEXT_INFO` wird zeitweise gesetzt, um die Trigger auf `Orderlines` und `Reservation` zu umgehen; deren Triggerlogik läuft für diese Änderungen also nicht.\n- Stolperfalle: Die Prozedur legt einen eindeutigen Index auf den Positionsschlüssel der Kandidatendaten an. Kommt eine Auftragsposition in den verknüpften Daten mehrfach vor (z. B. mehrere Bankzuordnungen zum Auftrag oder die Position steht auf mehreren Picklisten, auch abgelaufenen), schlägt die Indexerstellung fehl und der Aufruf liefert `500`.\n- Es wird nur ein Kundenkonto-Ereignis gelöscht (`TOP 1` ohne Sortierung), auch wenn mehrere Bankzuordnungen existieren. Ob es gelöscht werden darf, entscheidet `fPixi_CA_canIdeleteEvent`; Rechnungen werden über `Pixi_DeleteInvoice` entfernt. Beide Objekte liegen nicht vor, ihr genaues Verhalten ist daher hier nicht dokumentiert.\n- `Pixi_CA_DeleteEvent` rollt bei einem Fehler die gesamte Transaktion zurück und wirft die Meldung erneut; sie kommt dann als Status `500` zurück.\n- Fehler in `Pixi_DeleteEmptyOrder` werden dort über `log.InsertError` protokolliert und nicht weitergereicht.\n- Auch bei 404 oder 409 wird eine leere Transaktion geöffnet und committet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDeleteOrder"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 200\n Order with OrderNr: 100234 was deleted.\n \n"
}
]
},
{
"name": "pixiEmillGetOrderStates",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Liste aller Auftragsstatus mit ID und Beschreibung, sortiert nach Beschreibung.\n\nLiefert alle Einträge der Tabelle `OrderStates` (Auftragsstatus).\n\n- Keine Parameter, keine Filter: Alle definierten Auftragsstatus werden zurückgegeben.\n- Jede Zeile enthält den Statuscode (`orderStatus`) und den zugehörigen Text (`StateDesc`).\n- Die Zeilen sind alphabetisch nach dem Statustext sortiert.\n\nDas Ergebnis dient dazu, Statuscodes aus anderen Auftragsaufrufen in lesbare Beschreibungen zu übersetzen oder Auswahllisten zu befüllen.\n\n- Die Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können sichtbar sein.\n- Die Prozedur wurde ursprünglich für die eMill-Anbindung geschrieben (Tags `Tech_eMill`), ist aber eine allgemeine Nachschlageabfrage.\n- Die Sprache von `StateDesc` hängt vom Inhalt von `OrderStates` ab; der Code übersetzt nichts.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEmillGetOrderStates"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Liste aller Auftragsstatus mit ID und Beschreibung, sortiert nach Beschreibung.\n\nLiefert alle Einträge der Tabelle `OrderStates` (Auftragsstatus).\n\n- Keine Parameter, keine Filter: Alle definierten Auftragsstatus werden zurückgegeben.\n- Jede Zeile enthält den Statuscode (`orderStatus`) und den zugehörigen Text (`StateDesc`).\n- Die Zeilen sind alphabetisch nach dem Statustext sortiert.\n\nDas Ergebnis dient dazu, Statuscodes aus anderen Auftragsaufrufen in lesbare Beschreibungen zu übersetzen oder Auswahllisten zu befüllen.\n\n- Die Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können sichtbar sein.\n- Die Prozedur wurde ursprünglich für die eMill-Anbindung geschrieben (Tags `Tech_eMill`), ist aber eine allgemeine Nachschlageabfrage.\n- Die Sprache von `StateDesc` hängt vom Inhalt von `OrderStates` ab; der Code übersetzt nichts.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEmillGetOrderStates"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n AU\n Auftrag\n \n \n ST\n Storniert\n \n"
}
]
},
{
"name": "pixiGetChangedOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-14T08:00:00\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Kopfdaten aller Aufträge, die seit einem Zeitpunkt angelegt oder geändert wurden, einschließlich Änderungen an Auftragspositionen oder Adressen.\n\nDer Aufruf dient der Delta-Synchronisation von Aufträgen. Er liefert eine Zeile je geändertem Auftrag.\n\n**Zeitfenster**\n\n- Das Ende des Fensters, `DateTimeTo`, ist die Serverzeit bei der Ausführung (`GETDATE()`). Es wird in jeder Zeile zurückgegeben.\n- Liegt `DateTimeFrom` später als fünf Minuten vor der Serverzeit, wird der Wert auf *jetzt minus 5 Minuten* zurückgesetzt. Jeder Aufruf deckt damit mindestens die letzten fünf Minuten ab.\n\n**Welche Aufträge als geändert gelten**\n\nEin Auftrag wird ausgewählt, wenn mindestens einer der folgenden Zeitstempel bei oder nach `DateTimeFrom` und nicht nach `DateTimeTo` liegt:\n\n1. Auftragskopf: `UpdateDate`, oder `CreateDate`, falls der Auftrag nie geändert wurde.\n2. Eine Auftragsposition: deren `UpdateDate`, oder `CreateDate` bei nie geänderten Positionen.\n3. Rechnungsadresse (`AddrRef`) oder Lieferadresse (`ShipAdrRef`) des Auftrags: `UpdateDate`, oder `CreateDate`, falls nie geändert.\n\n**Filter Direct Fulfillment**\n\n- `ReturnOnlyDFOrders = 0` (Standard): Alle geänderten Aufträge werden geliefert.\n- `ReturnOnlyDFOrders = 1`: Nur geänderte Aufträge mit mindestens einer Auftragsposition, zu der ein `OrderHistory`-Eintrag mit Status `FUT` existiert, werden geliefert.\n\n**Gelieferte Daten**\n\n- Die Kopffelder stammen aus dem Auftragskopf, dem Kunden (`ShopID` ist `CustomerOf` des Kunden) und den Adressen. `PaymentType` ist die Zahlungsart der Rechnungsadresse. `OrderLocked` ist das Sperrkennzeichen der Lieferadresse (`N`, falls leer).\n- Je Auftrag aggregierte Positionsfelder:\n - `OrderDate`: das späteste Bestelldatum der Positionen, bei Einstellung `UseInitialOrderDate` = `1` das früheste.\n - `VoucherID`: die höchste Gutschein-ID mit dem zugehörigen `VoucherAmount`.\n - `OrderCurrency`: der Währungscode.\n - `EstimatedDelivery`: der späteste voraussichtliche Liefertermin.\n- Es werden nur Aufträge mit vorhandenem Kunden, vorhandener Rechnungsadresse und vorhandener Lieferadresse geliefert. Die Zeilen sind nicht sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateTimeFrom` | datetime | Ja | Beginn des Änderungszeitraums. Werte, die später als fünf Minuten vor der Serverzeit liegen, werden auf jetzt minus 5 Minuten zurückgesetzt. |\n| `skipGetXMLValue` | bit | Nein | Wird im Code nicht verwendet und hat keine Wirkung. |\n| `ReturnOnlyDFOrders` | bit | Nein | Beschränkt das Ergebnis auf Direct-Fulfillment-Aufträge, also Aufträge mit einer Position, zu der ein `OrderHistory`-Eintrag mit Status `FUT` existiert. |\n\n- **Polling:** Den Wert `DateTimeTo` der vorherigen Antwort als `DateTimeFrom` des nächsten Aufrufs übergeben. Wegen des Mindestfensters von fünf Minuten kann derselbe Auftrag in aufeinanderfolgenden Aufrufen erneut geliefert werden. Die Zeilen sollten daher idempotent verarbeitet werden.\n- Ist `DateTimeFrom` gleich `NULL`, trifft kein Auftrag zu und das Ergebnis ist leer.\n- **Ungenutzter Parameter:** `skipGetXMLValue` ist deklariert, wird im Code aber nicht verwendet.\n- **Dirty Reads:** Alle permanenten Tabellen werden mit `NOLOCK` gelesen. Nicht festgeschriebene Daten können erscheinen, und bei parallelen Änderungen können Zeilen fehlen oder doppelt auftreten.\n- **Einstellung:** `UseInitialOrderDate` wird aus der Tabelle `Settings` gelesen und steuert, ob `OrderDate` das früheste oder das späteste Positionsdatum ist.\n- **Fehlende Währung:** Die Positionsaggregate (`OrderDate`, `VoucherID`, `VoucherAmount`, `OrderCurrency`, `EstimatedDelivery`) sind `NULL`, wenn die Währung des Auftrags nicht in `pixi.Currency` gefunden wird oder der Auftrag keine Positionen hat.\n- **EstimatedDelivery:** Der Code vergleicht den Wert mit einem Platzhalterdatum (jetzt + 999 Tage, inklusive Uhrzeit). Dieser Vergleich trifft praktisch nie zu, daher wird der Wert unverändert geliefert.\n- **Performance:** Der Aufruf durchsucht Adressen, Auftragsköpfe und Auftragspositionen nach Datum. Sehr alte Werte für `DateTimeFrom` können große Ergebnismengen und lange Laufzeiten verursachen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-14T08:00:00\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Kopfdaten aller Aufträge, die seit einem Zeitpunkt angelegt oder geändert wurden, einschließlich Änderungen an Auftragspositionen oder Adressen.\n\nDer Aufruf dient der Delta-Synchronisation von Aufträgen. Er liefert eine Zeile je geändertem Auftrag.\n\n**Zeitfenster**\n\n- Das Ende des Fensters, `DateTimeTo`, ist die Serverzeit bei der Ausführung (`GETDATE()`). Es wird in jeder Zeile zurückgegeben.\n- Liegt `DateTimeFrom` später als fünf Minuten vor der Serverzeit, wird der Wert auf *jetzt minus 5 Minuten* zurückgesetzt. Jeder Aufruf deckt damit mindestens die letzten fünf Minuten ab.\n\n**Welche Aufträge als geändert gelten**\n\nEin Auftrag wird ausgewählt, wenn mindestens einer der folgenden Zeitstempel bei oder nach `DateTimeFrom` und nicht nach `DateTimeTo` liegt:\n\n1. Auftragskopf: `UpdateDate`, oder `CreateDate`, falls der Auftrag nie geändert wurde.\n2. Eine Auftragsposition: deren `UpdateDate`, oder `CreateDate` bei nie geänderten Positionen.\n3. Rechnungsadresse (`AddrRef`) oder Lieferadresse (`ShipAdrRef`) des Auftrags: `UpdateDate`, oder `CreateDate`, falls nie geändert.\n\n**Filter Direct Fulfillment**\n\n- `ReturnOnlyDFOrders = 0` (Standard): Alle geänderten Aufträge werden geliefert.\n- `ReturnOnlyDFOrders = 1`: Nur geänderte Aufträge mit mindestens einer Auftragsposition, zu der ein `OrderHistory`-Eintrag mit Status `FUT` existiert, werden geliefert.\n\n**Gelieferte Daten**\n\n- Die Kopffelder stammen aus dem Auftragskopf, dem Kunden (`ShopID` ist `CustomerOf` des Kunden) und den Adressen. `PaymentType` ist die Zahlungsart der Rechnungsadresse. `OrderLocked` ist das Sperrkennzeichen der Lieferadresse (`N`, falls leer).\n- Je Auftrag aggregierte Positionsfelder:\n - `OrderDate`: das späteste Bestelldatum der Positionen, bei Einstellung `UseInitialOrderDate` = `1` das früheste.\n - `VoucherID`: die höchste Gutschein-ID mit dem zugehörigen `VoucherAmount`.\n - `OrderCurrency`: der Währungscode.\n - `EstimatedDelivery`: der späteste voraussichtliche Liefertermin.\n- Es werden nur Aufträge mit vorhandenem Kunden, vorhandener Rechnungsadresse und vorhandener Lieferadresse geliefert. Die Zeilen sind nicht sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateTimeFrom` | datetime | Ja | Beginn des Änderungszeitraums. Werte, die später als fünf Minuten vor der Serverzeit liegen, werden auf jetzt minus 5 Minuten zurückgesetzt. |\n| `skipGetXMLValue` | bit | Nein | Wird im Code nicht verwendet und hat keine Wirkung. |\n| `ReturnOnlyDFOrders` | bit | Nein | Beschränkt das Ergebnis auf Direct-Fulfillment-Aufträge, also Aufträge mit einer Position, zu der ein `OrderHistory`-Eintrag mit Status `FUT` existiert. |\n\n- **Polling:** Den Wert `DateTimeTo` der vorherigen Antwort als `DateTimeFrom` des nächsten Aufrufs übergeben. Wegen des Mindestfensters von fünf Minuten kann derselbe Auftrag in aufeinanderfolgenden Aufrufen erneut geliefert werden. Die Zeilen sollten daher idempotent verarbeitet werden.\n- Ist `DateTimeFrom` gleich `NULL`, trifft kein Auftrag zu und das Ergebnis ist leer.\n- **Ungenutzter Parameter:** `skipGetXMLValue` ist deklariert, wird im Code aber nicht verwendet.\n- **Dirty Reads:** Alle permanenten Tabellen werden mit `NOLOCK` gelesen. Nicht festgeschriebene Daten können erscheinen, und bei parallelen Änderungen können Zeilen fehlen oder doppelt auftreten.\n- **Einstellung:** `UseInitialOrderDate` wird aus der Tabelle `Settings` gelesen und steuert, ob `OrderDate` das früheste oder das späteste Positionsdatum ist.\n- **Fehlende Währung:** Die Positionsaggregate (`OrderDate`, `VoucherID`, `VoucherAmount`, `OrderCurrency`, `EstimatedDelivery`) sind `NULL`, wenn die Währung des Auftrags nicht in `pixi.Currency` gefunden wird oder der Auftrag keine Positionen hat.\n- **EstimatedDelivery:** Der Code vergleicht den Wert mit einem Platzhalterdatum (jetzt + 999 Tage, inklusive Uhrzeit). Dieser Vergleich trifft praktisch nie zu, daher wird der Wert unverändert geliefert.\n- **Performance:** Der Aufruf durchsucht Adressen, Auftragsköpfe und Auftragspositionen nach Datum. Sehr alte Werte für `DateTimeFrom` können große Ergebnismengen und lange Laufzeiten verursachen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 2024-05-14T10:15:32.457\n 48211\n 100482\n 2024-05-14T09:58:10.123\n SHOP-2024-77812\n AUF\n DHL\n WEB\n 4.9500\n 90311\n 90312\n google\n V\n 55120\n max.mustermann@example.com\n K-10077\n N\n 2024-05-14T09:57:44\n EUR\n \n"
}
]
},
{
"name": "pixiGetExpiredReservations",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Aufträge eines POS-Standorts, deren Auftragspositionen älter als die Reservierungsfrist sind und keine Reservierung haben.\n\nLiefert die eindeutigen Auftragsnummern und Kundenreferenzen der Aufträge an einem POS-Standort, deren Reservierungsfrist abgelaufen ist.\n\nEine Auftragsposition wird berücksichtigt, wenn alle folgenden Bedingungen erfüllt sind:\n\n- `LocationID` der Auftragsposition entspricht `@LocationId` (dem POS-Standort).\n- Dem POS-Standort ist ein Reservierungsstandort zugeordnet (`Location.ResLocID`), und dieser Standort existiert in `Location`.\n- Der über `CustRef` referenzierte Kunde existiert in `Customers`.\n- Zur Auftragsposition existiert kein Eintrag in `Reservation` (`ResOrderlineRef`).\n- Der Status der Auftragsposition ist `ANG` oder `HAL`.\n- Seit `OrderDate` sind mehr ganze Tage vergangen als die Reservierungsfrist. Die Frist ist `ResExpDays` des Reservierungsstandorts. Ist dieser Wert NULL, gilt die globale Einstellung `ReservationExpiry`.\n- Jede Auftragsposition desselben Auftrags hat einen `ItemLocationSpecific`-Datensatz für den Reservierungsstandort. Fehlt dieser Datensatz auch nur bei einer Position, wird der gesamte Auftrag ausgeschlossen.\n\nJeder Auftrag erscheint nur einmal. Die Ausgabe ist aufsteigend nach `ordernr` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocationId` | varchar(50) | Nein | ID des POS-Standorts (`Location.LocID`), dessen Auftragspositionen geprüft werden. Ohne Wert werden keine Zeilen geliefert. |\n\n- Wird `LocationId` weggelassen (NULL), ist der Vergleich `LocationID = NULL` nie wahr und das Ergebnis immer leer. Es sollte daher immer ein Standort übergeben werden.\n- So wird die Reservierungsfrist aus der Einstellung `ReservationExpiry` ermittelt:\n - Die Einstellung wird über `fpixi_GetSetting` gelesen. Diese Funktion liefert `'0'`, wenn die Einstellung nicht existiert.\n - Eine fehlende Einstellung ergibt damit eine Frist von 0 Tagen, nicht 14. Dann qualifiziert sich jede Auftragsposition, die älter als einen Tag ist.\n - Der Ersatzwert von 14 Tagen greift nur, wenn die Einstellung mit leerem Wert existiert.\n - Ein nicht numerischer Wert der Einstellung führt zu einem Konvertierungsfehler.\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- Der Kopfkommentar der Prozedur (\"orders ready to pick up\") passt nicht zu Name und Logik. Die hier beschriebene Funktionsweise folgt dem Code.\n- Die Prozedur liest nur Daten. Sie storniert keine Aufträge und ändert keine Daten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetExpiredReservations"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Aufträge eines POS-Standorts, deren Auftragspositionen älter als die Reservierungsfrist sind und keine Reservierung haben.\n\nLiefert die eindeutigen Auftragsnummern und Kundenreferenzen der Aufträge an einem POS-Standort, deren Reservierungsfrist abgelaufen ist.\n\nEine Auftragsposition wird berücksichtigt, wenn alle folgenden Bedingungen erfüllt sind:\n\n- `LocationID` der Auftragsposition entspricht `@LocationId` (dem POS-Standort).\n- Dem POS-Standort ist ein Reservierungsstandort zugeordnet (`Location.ResLocID`), und dieser Standort existiert in `Location`.\n- Der über `CustRef` referenzierte Kunde existiert in `Customers`.\n- Zur Auftragsposition existiert kein Eintrag in `Reservation` (`ResOrderlineRef`).\n- Der Status der Auftragsposition ist `ANG` oder `HAL`.\n- Seit `OrderDate` sind mehr ganze Tage vergangen als die Reservierungsfrist. Die Frist ist `ResExpDays` des Reservierungsstandorts. Ist dieser Wert NULL, gilt die globale Einstellung `ReservationExpiry`.\n- Jede Auftragsposition desselben Auftrags hat einen `ItemLocationSpecific`-Datensatz für den Reservierungsstandort. Fehlt dieser Datensatz auch nur bei einer Position, wird der gesamte Auftrag ausgeschlossen.\n\nJeder Auftrag erscheint nur einmal. Die Ausgabe ist aufsteigend nach `ordernr` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocationId` | varchar(50) | Nein | ID des POS-Standorts (`Location.LocID`), dessen Auftragspositionen geprüft werden. Ohne Wert werden keine Zeilen geliefert. |\n\n- Wird `LocationId` weggelassen (NULL), ist der Vergleich `LocationID = NULL` nie wahr und das Ergebnis immer leer. Es sollte daher immer ein Standort übergeben werden.\n- So wird die Reservierungsfrist aus der Einstellung `ReservationExpiry` ermittelt:\n - Die Einstellung wird über `fpixi_GetSetting` gelesen. Diese Funktion liefert `'0'`, wenn die Einstellung nicht existiert.\n - Eine fehlende Einstellung ergibt damit eine Frist von 0 Tagen, nicht 14. Dann qualifiziert sich jede Auftragsposition, die älter als einen Tag ist.\n - Der Ersatzwert von 14 Tagen greift nur, wenn die Einstellung mit leerem Wert existiert.\n - Ein nicht numerischer Wert der Einstellung führt zu einem Konvertierungsfehler.\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- Der Kopfkommentar der Prozedur (\"orders ready to pick up\") passt nicht zu Name und Logik. Die hier beschriebene Funktionsweise folgt dem Code.\n- Die Prozedur liest nur Daten. Sie storniert keine Aufträge und ändert keine Daten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetExpiredReservations"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 100245\n 5821\n \n \n 100312\n 6110\n \n"
}
]
},
{
"name": "pixiGetMergableOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Aufträge, die mit einem gegebenen Auftrag zusammengeführt werden können: gleicher Kunde, Auftragstyp, Währung und Zahlungsart, alle Positionen ANG, nicht auf aktiver Pickliste.\n\nErmittelt Kandidaten für die Zusammenführung mit dem Referenzauftrag `OrderNr`.\n\n1. Der Referenzauftrag wird aus `OrderHeader` gelesen: Kunde (`CustRef`), Währung (`CurrencyId`), Auftragstyp (`OrderType`) sowie die Zahlungsart (`APayment`) der über `AddrRef` verknüpften Adresse.\n2. Andere Aufträge werden geliefert, wenn **alle** folgenden Bedingungen erfüllt sind:\n - gleicher Kunde (`CustRef`), aber andere Auftragsnummer;\n - gleicher `OrderType` und gleiche `CurrencyId`;\n - die Adresse des Kandidaten hat dieselbe Zahlungsart wie der Referenzauftrag, und diese Zahlungsart ist nicht `K` (verwendet der Referenzauftrag `K`, werden keine Aufträge geliefert);\n - keine Auftragsposition des Kandidaten befindet sich auf einer Picklistenposition, deren Pickliste noch nicht abgelaufen ist (`PLHexpiryDate` größer als jetzt) und deren `ReservedOrderNr` leer oder 0 ist;\n - alle Auftragspositionen des Kandidaten haben den Status `ANG` (Aufträge ohne Positionen sind damit ausgeschlossen).\n3. Sortiert wird nach `CreateDate` aufsteigend (ältester Auftrag zuerst).\n\nExistiert der Referenzauftrag nicht, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Interne Nummer des Referenzauftrags, zu dem zusammenführbare Aufträge gesucht werden. |\n\n- Nur lesend; alle Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten sichtbar sein.\n- Der Referenzauftrag selbst wird nicht auf Positionsstatus oder Picklistenzuordnung geprüft; gefiltert werden nur die Kandidaten.\n- Die Bedeutung der Zahlungsart `K` ist im Code nicht definiert; sie wird lediglich von der Zusammenführung ausgeschlossen.\n- Die Spalte `ReservedOrderNr` wird ohne Tabellenalias verwendet; sie gehört entweder zu `PLitem` oder `PLHeader`, was der Code nicht eindeutig macht.\n- Der Aufruf listet nur Kandidaten auf und führt keine Zusammenführung durch.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetMergableOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Aufträge, die mit einem gegebenen Auftrag zusammengeführt werden können: gleicher Kunde, Auftragstyp, Währung und Zahlungsart, alle Positionen ANG, nicht auf aktiver Pickliste.\n\nErmittelt Kandidaten für die Zusammenführung mit dem Referenzauftrag `OrderNr`.\n\n1. Der Referenzauftrag wird aus `OrderHeader` gelesen: Kunde (`CustRef`), Währung (`CurrencyId`), Auftragstyp (`OrderType`) sowie die Zahlungsart (`APayment`) der über `AddrRef` verknüpften Adresse.\n2. Andere Aufträge werden geliefert, wenn **alle** folgenden Bedingungen erfüllt sind:\n - gleicher Kunde (`CustRef`), aber andere Auftragsnummer;\n - gleicher `OrderType` und gleiche `CurrencyId`;\n - die Adresse des Kandidaten hat dieselbe Zahlungsart wie der Referenzauftrag, und diese Zahlungsart ist nicht `K` (verwendet der Referenzauftrag `K`, werden keine Aufträge geliefert);\n - keine Auftragsposition des Kandidaten befindet sich auf einer Picklistenposition, deren Pickliste noch nicht abgelaufen ist (`PLHexpiryDate` größer als jetzt) und deren `ReservedOrderNr` leer oder 0 ist;\n - alle Auftragspositionen des Kandidaten haben den Status `ANG` (Aufträge ohne Positionen sind damit ausgeschlossen).\n3. Sortiert wird nach `CreateDate` aufsteigend (ältester Auftrag zuerst).\n\nExistiert der Referenzauftrag nicht, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Interne Nummer des Referenzauftrags, zu dem zusammenführbare Aufträge gesucht werden. |\n\n- Nur lesend; alle Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten sichtbar sein.\n- Der Referenzauftrag selbst wird nicht auf Positionsstatus oder Picklistenzuordnung geprüft; gefiltert werden nur die Kandidaten.\n- Die Bedeutung der Zahlungsart `K` ist im Code nicht definiert; sie wird lediglich von der Zusammenführung ausgeschlossen.\n- Die Spalte `ReservedOrderNr` wird ohne Tabellenalias verwendet; sie gehört entweder zu `PLitem` oder `PLHeader`, was der Code nicht eindeutig macht.\n- Der Aufruf listet nur Kandidaten auf und führt keine Zusammenführung durch.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetMergableOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 104498\n 2024-03-11T09:15:22\n SHOP-100231\n \n \n 104517\n 2024-03-12T14:02:47\n SHOP-100245\n \n"
}
]
},
{
"name": "pixiGetOrder",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Details zu einem oder mehreren Aufträgen inkl. Adressen, Kunde, Auftragspositionen, Bundle-Positionen, Rechnungen und Kundenkonto als verschachteltes XML.\n\nSammelt aus den drei Eingabeparametern eine Menge von Auftragsnummern und liefert pro eindeutiger Auftragsnummer eine Zeile mit den Feldern des Auftragskopfs und mehreren verschachtelten XML-Dokumenten.\n\n**Auswahl der Aufträge** (alle Parameter sind kombinierbar; die Ergebnisse werden zusammengeführt und dedupliziert):\n- `OrderNr`: wird direkt übernommen, wenn größer als 0. Es erfolgt **keine** Prüfung gegen `OrderHeader`.\n- `OrderNrExternal`: alle Aufträge mit exakt passender `OrderNrExternal` werden übernommen.\n- `OrderNrXML`: XML-Dokument mit Wurzel `OrderNrs`; jedes Element `OrderNr` fügt diese Auftragsnummer hinzu, jedes Element `OrderNrExternal` alle Aufträge mit dieser externen Nummer.\n\nWird keine Auftragsnummer ermittelt, liefert der Aufruf **kein Resultset**.\n\n**Pro Auftrag enthält die Zeile:**\n- Felder des Auftragskopfs aus `OrderHeader` (Versanddienstleister, Geschenknachricht, Status, Summen, Referenzen, Kennzeichen, `OrderType`, `ShipCost` …).\n- `BillingAddress` und `ShippingAddress`: XML der über `AddrRef` / `ShipAdrRef` referenzierten Adresse, ergänzt um Ländernamen und Ländercodes (ISO2, ISO3, Afterbuy, Plenty).\n- `Customer`: XML des über `CustRef` referenzierten Kunden.\n- `Orderlines`: XML aller Auftragspositionen mit Währungscode (`OrderCurrency`), Artikeldaten und `PickListNr`.\n- `BundleOrderlines`: XML der Bundle-Auftragspositionen.\n- `Invoices`: XML aller Rechnungen, die mindestens eine Rechnungsposition zu einer Auftragsposition dieses Auftrags enthalten; jede Rechnung enthält ihre `InvoiceLines`.\n- `CustomerAccount`: XML der Kundenkontobuchungen des Kunden, die entweder zu einer dieser Rechnungen gehören oder ohne Rechnung über einen Bankabgleich mit dem Auftrag verknüpft sind; sortiert nach `CustomerAccountKey` aufsteigend.\n- `OnPicklist`: Picklistenstatus der Auftragspositionen (`None`, `Partial`, `All`).\n- `VoucherID`: die höchste `VoucherID` der Auftragspositionen.\n\nDie Reihenfolge der Zeilen ist nicht definiert (kein `ORDER BY`).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Interne Pixi-Auftragsnummer. Wird nur verwendet, wenn größer als 0. |\n| `OrderNrXML` | varchar(max) | Nein | XML-Liste von Auftragsnummern und/oder externen Auftragsnummern (Wurzel `OrderNrs`, Kindelemente `OrderNr` und `OrderNrExternal`). Fehlerhaftes XML wird ignoriert. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer (Shop); alle Aufträge mit genau diesem Wert werden geliefert. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; Daten können nicht festgeschrieben oder inkonsistent sein.\n- Eine nicht existierende `OrderNr` liefert trotzdem eine Zeile: `OrderNr` ist gefüllt, alle Kopffelder und XML-Spalten sind NULL.\n- Fehlerhaftes `OrderNrXML` wird stillschweigend ignoriert (leerer `CATCH`). Das XML-Dokumenthandle wird nie mit `sp_xml_removedocument` freigegeben.\n- Logik für `OnPicklist`: `None`, wenn keine Position auf einer Pickliste ist; `Partial`, wenn einige Positionen eine Pickliste haben und andere nicht; `All`, wenn alle Positionen auf einer oder mehreren Picklisten sind. Bei Aufträgen ohne Positionen ist der Wert NULL.\n- Auftrags- und Bundle-Positionen werden per Inner Join mit `Items` und `Currency` verknüpft; Positionen, deren Artikel nicht mehr existiert, fehlen im XML.\n- Das verschachtelte XML nutzt `FOR XML PATH` ohne Zeilennamen, daher ist jeder Datensatz ein Element `row`; NULL-Werte werden weggelassen.\n- Felder mit Endung `_OrderCurr` (z. B. `Price_OrderCurr`, `Total_OrderCurr`) sind Duplikate der Basisfelder und im Code zur Entfernung markiert; sie sollten nicht verwendet werden.\n- Das Abrufen vieler Aufträge auf einmal kann wegen der zahlreichen korrelierten Unterabfragen pro Auftrag aufwendig sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrder"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Details zu einem oder mehreren Aufträgen inkl. Adressen, Kunde, Auftragspositionen, Bundle-Positionen, Rechnungen und Kundenkonto als verschachteltes XML.\n\nSammelt aus den drei Eingabeparametern eine Menge von Auftragsnummern und liefert pro eindeutiger Auftragsnummer eine Zeile mit den Feldern des Auftragskopfs und mehreren verschachtelten XML-Dokumenten.\n\n**Auswahl der Aufträge** (alle Parameter sind kombinierbar; die Ergebnisse werden zusammengeführt und dedupliziert):\n- `OrderNr`: wird direkt übernommen, wenn größer als 0. Es erfolgt **keine** Prüfung gegen `OrderHeader`.\n- `OrderNrExternal`: alle Aufträge mit exakt passender `OrderNrExternal` werden übernommen.\n- `OrderNrXML`: XML-Dokument mit Wurzel `OrderNrs`; jedes Element `OrderNr` fügt diese Auftragsnummer hinzu, jedes Element `OrderNrExternal` alle Aufträge mit dieser externen Nummer.\n\nWird keine Auftragsnummer ermittelt, liefert der Aufruf **kein Resultset**.\n\n**Pro Auftrag enthält die Zeile:**\n- Felder des Auftragskopfs aus `OrderHeader` (Versanddienstleister, Geschenknachricht, Status, Summen, Referenzen, Kennzeichen, `OrderType`, `ShipCost` …).\n- `BillingAddress` und `ShippingAddress`: XML der über `AddrRef` / `ShipAdrRef` referenzierten Adresse, ergänzt um Ländernamen und Ländercodes (ISO2, ISO3, Afterbuy, Plenty).\n- `Customer`: XML des über `CustRef` referenzierten Kunden.\n- `Orderlines`: XML aller Auftragspositionen mit Währungscode (`OrderCurrency`), Artikeldaten und `PickListNr`.\n- `BundleOrderlines`: XML der Bundle-Auftragspositionen.\n- `Invoices`: XML aller Rechnungen, die mindestens eine Rechnungsposition zu einer Auftragsposition dieses Auftrags enthalten; jede Rechnung enthält ihre `InvoiceLines`.\n- `CustomerAccount`: XML der Kundenkontobuchungen des Kunden, die entweder zu einer dieser Rechnungen gehören oder ohne Rechnung über einen Bankabgleich mit dem Auftrag verknüpft sind; sortiert nach `CustomerAccountKey` aufsteigend.\n- `OnPicklist`: Picklistenstatus der Auftragspositionen (`None`, `Partial`, `All`).\n- `VoucherID`: die höchste `VoucherID` der Auftragspositionen.\n\nDie Reihenfolge der Zeilen ist nicht definiert (kein `ORDER BY`).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Interne Pixi-Auftragsnummer. Wird nur verwendet, wenn größer als 0. |\n| `OrderNrXML` | varchar(max) | Nein | XML-Liste von Auftragsnummern und/oder externen Auftragsnummern (Wurzel `OrderNrs`, Kindelemente `OrderNr` und `OrderNrExternal`). Fehlerhaftes XML wird ignoriert. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer (Shop); alle Aufträge mit genau diesem Wert werden geliefert. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; Daten können nicht festgeschrieben oder inkonsistent sein.\n- Eine nicht existierende `OrderNr` liefert trotzdem eine Zeile: `OrderNr` ist gefüllt, alle Kopffelder und XML-Spalten sind NULL.\n- Fehlerhaftes `OrderNrXML` wird stillschweigend ignoriert (leerer `CATCH`). Das XML-Dokumenthandle wird nie mit `sp_xml_removedocument` freigegeben.\n- Logik für `OnPicklist`: `None`, wenn keine Position auf einer Pickliste ist; `Partial`, wenn einige Positionen eine Pickliste haben und andere nicht; `All`, wenn alle Positionen auf einer oder mehreren Picklisten sind. Bei Aufträgen ohne Positionen ist der Wert NULL.\n- Auftrags- und Bundle-Positionen werden per Inner Join mit `Items` und `Currency` verknüpft; Positionen, deren Artikel nicht mehr existiert, fehlen im XML.\n- Das verschachtelte XML nutzt `FOR XML PATH` ohne Zeilennamen, daher ist jeder Datensatz ein Element `row`; NULL-Werte werden weggelassen.\n- Felder mit Endung `_OrderCurr` (z. B. `Price_OrderCurr`, `Total_OrderCurr`) sind Duplikate der Basisfelder und im Code zur Entfernung markiert; sie sollten nicht verwendet werden.\n- Das Abrufen vieler Aufträge auf einmal kann wegen der zahlreichen korrelierten Unterabfragen pro Auftrag aufwendig sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrder"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 100234\n \n \n 55012\n Anna\n Muster\n Hauptstr.\n 5\n München\n 80331\n D\n DE\n \n \n \n \n PP\n SHP\n \n \n DHL\n 2024-03-11T09:42:17\n SHOP-4711\n AUF\n 59.90\n \n \n 812345\n TS-100-M\n T-Shirt M\n 2\n 24.95\n AUF\n EUR\n 4711\n \n \n B2C\n None\n 4.95\n \n"
}
]
},
{
"name": "pixiGetOrderChanges",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Aufträge, die in einem Zeitraum angelegt, geändert, berechnet oder ausgescannt wurden, mit einer Zeile je erkannter Änderung.\n\nSammelt Änderungsereignisse zu Aufträgen im Zeitraum von `DateFrom` (einschließlich) bis `DateTo` (ausschließlich) und gibt sie als flache Liste zurück. Der Aufruf ist für abfragende Clients gedacht, die Aufträge in ein externes System synchronisieren.\n\nOhne `DateFrom` gilt der aktuelle Zeitpunkt minus einen Tag. Ohne `DateTo` gilt der aktuelle Zeitpunkt.\n\nJe nach `ChangeType` laufen eine oder alle dieser Prüfungen:\n\n- `CORDER`: Auftragsköpfe, deren `CreateDate` im Zeitraum liegt. `Param1` ist leer.\n- `UORDER`: Auftragsköpfe, deren `UpdateDate` im Zeitraum liegt. `Param1` ist leer.\n- `CORDERL`: Auftragspositionen, deren `CreateDate` im Zeitraum liegt. Eine Zeile je Position; `Param1` enthält den `OrderlineKey`.\n- `UORDERL`: Auftragspositionen, deren `UpdateDate` im Zeitraum liegt. Eine Zeile je Position; `Param1` enthält den `OrderlineKey`.\n- `IORDER`: Rechnungen, deren `InvDate` im Zeitraum liegt. Eine Zeile je Auftrag und Rechnung; `Param1` enthält die `InvoiceNr`.\n- `SORDER`: Rechnungen, deren `ScanOutDate` im Zeitraum liegt. Eine Zeile je Auftrag und Rechnung; `Param1` enthält die `InvoiceNr`.\n\n`ALL` (Standard) führt alle sechs Prüfungen aus.\n\nOptionale Filter:\n\n- `ShopID`: bei Kopf-Ereignissen der Shop der Auftragsadresse (`AddrShopId`). Bei Positions-Ereignissen der Shop der Auftragsposition (`OrdShopID`). Bei Rechnungs-Ereignissen der Shop der Rechnung (`InvShopID`).\n- `PaymentType`: bei Kopf- und Positions-Ereignissen die Zahlungsart der Adresse (`APayment`). Bei Rechnungs-Ereignissen die Zahlungsart der Rechnung (`Payment`).\n\nEs werden nur Zeilen mit `OrderNr` > 0 geliefert. Sortiert wird aufsteigend nach `OrderNr`, dann `ChangeType`, dann `Param1`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ChangeType` | varchar(10) | Nein | Art der zu meldenden Änderung. `ALL` liefert alle Arten. |\n| `ShopID` | varchar(3) | Nein | Optionaler Shop-Filter. Er wird je nach Änderungsart auf den Shop der Adresse, der Auftragsposition oder der Rechnung angewendet. `NULL` liefert alle Shops. |\n| `PaymentType` | char(1) | Nein | Optionaler Filter auf die Zahlungsart. Er wird auf die Zahlungsart der Adresse (`APayment`) oder der Rechnung (`Payment`) angewendet. `NULL` liefert alle Zahlungsarten. |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (einschließlich). Standard ist der aktuelle Zeitpunkt minus einen Tag. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (ausschließlich). Standard ist der aktuelle Zeitpunkt. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`. Daher können nicht festgeschriebene Änderungen erscheinen, und unter gleichzeitiger Last können Zeilen fehlen oder doppelt auftreten.\n- Der Zeitraum ist halboffen (`>= DateFrom`, `< DateTo`). Wird das vorherige `DateTo` als nächstes `DateFrom` verwendet, entsteht eine lückenlose Abfrage ohne Überschneidungen.\n- Das Ergebnis wird nicht dedupliziert. Derselbe Auftrag kann mehrfach erscheinen: mit mehreren Änderungsarten, mehreren Positionen oder mehreren Rechnungen.\n- `CORDER`/`UORDER` verknüpfen per Inner Join mit der Auftragsadresse. Auftragsköpfe ohne passende Adresse werden nicht gemeldet.\n- `Param1` ist ein `varchar` und wird daher als Text sortiert: `OrderlineKey`- und `InvoiceNr`-Werte werden alphabetisch, nicht numerisch sortiert.\n- Ein unbekannter Wert für `ChangeType` löst keinen Fehler aus; das Ergebnis ist dann leer.\n- Es werden keine Fehlerzeilen erzeugt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderChanges"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Aufträge, die in einem Zeitraum angelegt, geändert, berechnet oder ausgescannt wurden, mit einer Zeile je erkannter Änderung.\n\nSammelt Änderungsereignisse zu Aufträgen im Zeitraum von `DateFrom` (einschließlich) bis `DateTo` (ausschließlich) und gibt sie als flache Liste zurück. Der Aufruf ist für abfragende Clients gedacht, die Aufträge in ein externes System synchronisieren.\n\nOhne `DateFrom` gilt der aktuelle Zeitpunkt minus einen Tag. Ohne `DateTo` gilt der aktuelle Zeitpunkt.\n\nJe nach `ChangeType` laufen eine oder alle dieser Prüfungen:\n\n- `CORDER`: Auftragsköpfe, deren `CreateDate` im Zeitraum liegt. `Param1` ist leer.\n- `UORDER`: Auftragsköpfe, deren `UpdateDate` im Zeitraum liegt. `Param1` ist leer.\n- `CORDERL`: Auftragspositionen, deren `CreateDate` im Zeitraum liegt. Eine Zeile je Position; `Param1` enthält den `OrderlineKey`.\n- `UORDERL`: Auftragspositionen, deren `UpdateDate` im Zeitraum liegt. Eine Zeile je Position; `Param1` enthält den `OrderlineKey`.\n- `IORDER`: Rechnungen, deren `InvDate` im Zeitraum liegt. Eine Zeile je Auftrag und Rechnung; `Param1` enthält die `InvoiceNr`.\n- `SORDER`: Rechnungen, deren `ScanOutDate` im Zeitraum liegt. Eine Zeile je Auftrag und Rechnung; `Param1` enthält die `InvoiceNr`.\n\n`ALL` (Standard) führt alle sechs Prüfungen aus.\n\nOptionale Filter:\n\n- `ShopID`: bei Kopf-Ereignissen der Shop der Auftragsadresse (`AddrShopId`). Bei Positions-Ereignissen der Shop der Auftragsposition (`OrdShopID`). Bei Rechnungs-Ereignissen der Shop der Rechnung (`InvShopID`).\n- `PaymentType`: bei Kopf- und Positions-Ereignissen die Zahlungsart der Adresse (`APayment`). Bei Rechnungs-Ereignissen die Zahlungsart der Rechnung (`Payment`).\n\nEs werden nur Zeilen mit `OrderNr` > 0 geliefert. Sortiert wird aufsteigend nach `OrderNr`, dann `ChangeType`, dann `Param1`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ChangeType` | varchar(10) | Nein | Art der zu meldenden Änderung. `ALL` liefert alle Arten. |\n| `ShopID` | varchar(3) | Nein | Optionaler Shop-Filter. Er wird je nach Änderungsart auf den Shop der Adresse, der Auftragsposition oder der Rechnung angewendet. `NULL` liefert alle Shops. |\n| `PaymentType` | char(1) | Nein | Optionaler Filter auf die Zahlungsart. Er wird auf die Zahlungsart der Adresse (`APayment`) oder der Rechnung (`Payment`) angewendet. `NULL` liefert alle Zahlungsarten. |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (einschließlich). Standard ist der aktuelle Zeitpunkt minus einen Tag. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (ausschließlich). Standard ist der aktuelle Zeitpunkt. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`. Daher können nicht festgeschriebene Änderungen erscheinen, und unter gleichzeitiger Last können Zeilen fehlen oder doppelt auftreten.\n- Der Zeitraum ist halboffen (`>= DateFrom`, `< DateTo`). Wird das vorherige `DateTo` als nächstes `DateFrom` verwendet, entsteht eine lückenlose Abfrage ohne Überschneidungen.\n- Das Ergebnis wird nicht dedupliziert. Derselbe Auftrag kann mehrfach erscheinen: mit mehreren Änderungsarten, mehreren Positionen oder mehreren Rechnungen.\n- `CORDER`/`UORDER` verknüpfen per Inner Join mit der Auftragsadresse. Auftragsköpfe ohne passende Adresse werden nicht gemeldet.\n- `Param1` ist ein `varchar` und wird daher als Text sortiert: `OrderlineKey`- und `InvoiceNr`-Werte werden alphabetisch, nicht numerisch sortiert.\n- Ein unbekannter Wert für `ChangeType` löst keinen Fehler aus; das Ergebnis ist dann leer.\n- Es werden keine Fehlerzeilen erzeugt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderChanges"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 100245\n CORDER\n 2024-05-01T09:15:22\n \n \n 100245\n CORDERL\n 2024-05-01T09:15:23\n 587311\n \n"
}
]
},
{
"name": "pixiGetOrderComments",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Kommentare zu Aufträgen, die nach einem bestimmten Zeitpunkt angelegt wurden, optional gefiltert nach Pixi-Auftragsnummer oder Shop-Auftragsnummer.\n\nLiefert die zu Aufträgen gespeicherten Kommentare zusammen mit den zugehörigen Auftragsnummern.\n\n**Behandlung der Parameter**\n- `OrderNr` = `0` wird wie nicht gesetzt (`NULL`) behandelt.\n- Ein leerer Wert für `OrderNrShop` wird wie nicht gesetzt (`NULL`) behandelt.\n- `RowCount` ist auf den Bereich 1 bis 1000 begrenzt. Ein Wert, der `NULL`, kleiner als 1 oder größer als 1000 ist, wird durch `1000` ersetzt.\n- `Since` wird bei `NULL` auf `2000-01-01` gesetzt.\n\n**Filter**\n- Es werden nur Kommentare geliefert, deren `CreateDate` **echt später** als `Since` ist.\n- Ist weder `OrderNr` noch `OrderNrShop` gesetzt, werden die Kommentare aller Aufträge geliefert.\n- Ist `OrderNr` gesetzt, werden die Kommentare des Auftrags mit dieser Pixi-Auftragsnummer geliefert.\n- Ist `OrderNrShop` gesetzt, werden die Kommentare der Aufträge geliefert, deren externe (Shop-)Auftragsnummer `OrderNrExternal` übereinstimmt.\n- Sind beide gesetzt, werden sie mit **ODER** verknüpft: Kommentare beider Aufträge werden geliefert.\n\n**Sortierung und Begrenzung**\n\nDie Zeilen werden aufsteigend nach `CreateDate` sortiert, es werden höchstens `RowCount` Zeilen geliefert. Damit ist ein inkrementeller Abruf möglich: Das `CreateDate` der zuletzt erhaltenen Zeile wird beim nächsten Aufruf als `Since` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. `0` oder `NULL` bedeutet keinen Filter auf diese Nummer. |\n| `OrderNrShop` | varchar(50) | Nein | Externe (Shop-)Auftragsnummer, verglichen mit `OrderNrExternal`. Leer oder `NULL` bedeutet keinen Filter auf diese Nummer. |\n| `Since` | datetime | Nein | Es werden nur Kommentare geliefert, die echt nach diesem Zeitpunkt angelegt wurden. `NULL` wird durch `2000-01-01` ersetzt. |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen (1 bis 1000). Werte außerhalb dieses Bereichs oder `NULL` werden durch 1000 ersetzt. |\n\n- Beide Tabellen werden mit `NOLOCK` gelesen; bei parallelen Änderungen können nicht festgeschriebene Daten geliefert oder Zeilen übersehen werden.\n- Die Sortierung hat außer `CreateDate` kein weiteres Kriterium. Beim seitenweisen Abruf mit `Since` = letztes `CreateDate` werden Kommentare mit exakt demselben `CreateDate` wie die zuletzt gelieferte Zeile übersprungen, da der Filter echt größer (`>`) prüft. Endet eine Seite mitten in Zeilen mit gleichem Zeitstempel, gehen die restlichen Zeilen verloren.\n- Die maximale Seitengröße beträgt 1000 Zeilen; größere Werte für `RowCount` führen nicht zu einem Fehler, sondern werden stillschweigend auf 1000 gesetzt.\n- Es werden nur Kommentare geliefert, deren Auftrag in `OrderHeader` existiert (Inner Join).\n- Ein `Since`-Wert von `1900-01-01` (Wert eines leeren Datums) wird ebenfalls durch `2000-01-01` ersetzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderComments"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Kommentare zu Aufträgen, die nach einem bestimmten Zeitpunkt angelegt wurden, optional gefiltert nach Pixi-Auftragsnummer oder Shop-Auftragsnummer.\n\nLiefert die zu Aufträgen gespeicherten Kommentare zusammen mit den zugehörigen Auftragsnummern.\n\n**Behandlung der Parameter**\n- `OrderNr` = `0` wird wie nicht gesetzt (`NULL`) behandelt.\n- Ein leerer Wert für `OrderNrShop` wird wie nicht gesetzt (`NULL`) behandelt.\n- `RowCount` ist auf den Bereich 1 bis 1000 begrenzt. Ein Wert, der `NULL`, kleiner als 1 oder größer als 1000 ist, wird durch `1000` ersetzt.\n- `Since` wird bei `NULL` auf `2000-01-01` gesetzt.\n\n**Filter**\n- Es werden nur Kommentare geliefert, deren `CreateDate` **echt später** als `Since` ist.\n- Ist weder `OrderNr` noch `OrderNrShop` gesetzt, werden die Kommentare aller Aufträge geliefert.\n- Ist `OrderNr` gesetzt, werden die Kommentare des Auftrags mit dieser Pixi-Auftragsnummer geliefert.\n- Ist `OrderNrShop` gesetzt, werden die Kommentare der Aufträge geliefert, deren externe (Shop-)Auftragsnummer `OrderNrExternal` übereinstimmt.\n- Sind beide gesetzt, werden sie mit **ODER** verknüpft: Kommentare beider Aufträge werden geliefert.\n\n**Sortierung und Begrenzung**\n\nDie Zeilen werden aufsteigend nach `CreateDate` sortiert, es werden höchstens `RowCount` Zeilen geliefert. Damit ist ein inkrementeller Abruf möglich: Das `CreateDate` der zuletzt erhaltenen Zeile wird beim nächsten Aufruf als `Since` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. `0` oder `NULL` bedeutet keinen Filter auf diese Nummer. |\n| `OrderNrShop` | varchar(50) | Nein | Externe (Shop-)Auftragsnummer, verglichen mit `OrderNrExternal`. Leer oder `NULL` bedeutet keinen Filter auf diese Nummer. |\n| `Since` | datetime | Nein | Es werden nur Kommentare geliefert, die echt nach diesem Zeitpunkt angelegt wurden. `NULL` wird durch `2000-01-01` ersetzt. |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen (1 bis 1000). Werte außerhalb dieses Bereichs oder `NULL` werden durch 1000 ersetzt. |\n\n- Beide Tabellen werden mit `NOLOCK` gelesen; bei parallelen Änderungen können nicht festgeschriebene Daten geliefert oder Zeilen übersehen werden.\n- Die Sortierung hat außer `CreateDate` kein weiteres Kriterium. Beim seitenweisen Abruf mit `Since` = letztes `CreateDate` werden Kommentare mit exakt demselben `CreateDate` wie die zuletzt gelieferte Zeile übersprungen, da der Filter echt größer (`>`) prüft. Endet eine Seite mitten in Zeilen mit gleichem Zeitstempel, gehen die restlichen Zeilen verloren.\n- Die maximale Seitengröße beträgt 1000 Zeilen; größere Werte für `RowCount` führen nicht zu einem Fehler, sondern werden stillschweigend auf 1000 gesetzt.\n- Es werden nur Kommentare geliefert, deren Auftrag in `OrderHeader` existiert (Inner Join).\n- Ein `Since`-Wert von `1900-01-01` (Wert eines leeren Datums) wird ebenfalls durch `2000-01-01` ersetzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderComments"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Customer asked for delivery after 2 pm.\n MK\n 2024-05-02T09:15:32.000\n SHOP-100023\n 123456\n \n \n Address corrected by phone.\n AS\n 2024-05-02T11:48:07.000\n SHOP-100031\n 123470\n \n"
}
]
},
{
"name": "pixiGetOrderHeader",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Auftragsköpfe mit Kunden-, Rechnungs- und Lieferadress-, Rechnungs-, Versand-, Gutschein- und Tag-Daten, ausgewählt über Auftragsnummer, externe Auftragsnummer oder Filter.\n\nDer Aufruf wählt Auftragsköpfe in einem von drei Modi aus und liefert eine Zeile je Auftrag.\n\n**Normalisierung der Parameter**\n- `OrderNr` = 0, `CustKey` = 0 sowie leere Zeichenketten für `OrderNrExternal`, `ShopID`, `PaymentType`, `ShippingCountry` gelten als *nicht gesetzt*.\n- Datumsparameter (`FromTime`, `UntilTime`, `FromUpdateTime`), die mehr als 100 Jahre in der Vergangenheit liegen (z. B. `1900-01-01`), gelten als *nicht gesetzt*.\n- `RowCount` = NULL wird zu 1000.\n\n**Auswahlmodi** (die erste zutreffende Regel gilt)\n1. `OrderNr` gesetzt: der Auftrag mit dieser `OrderNr`. Optional eingeschränkt über `CustKey` und `ShopID` (`CustomerOf` des Kunden). Alle anderen Filter werden ignoriert.\n2. `OrderNrExternal` gesetzt: Aufträge mit dieser externen Auftragsnummer, optional eingeschränkt über `CustKey` und `ShopID`. Alle anderen Filter werden ignoriert.\n3. Einer der Parameter `FromTime`, `UntilTime`, `ShopID`, `PaymentType`, `ShippingCountry`, `CustKey`, `FromUpdateTime` gesetzt: Filtersuche, UND-verknüpft:\n - `OrderDate` > `FromTime` und `OrderDate` < `UntilTime` (jeweils exklusiv)\n - `UpdateDate` > `FromUpdateTime` (exklusiv)\n - `CustRef` = `CustKey`\n - `CustomerOf` des Kunden = `ShopID`\n - Land der Lieferadresse = `ShippingCountry`\n - Zahlungsart (`APayment`) der Rechnungsadresse = `PaymentType`\n \n Es werden höchstens `RowCount` Aufträge übernommen, älteste `CreateDate` zuerst.\n4. Kein Parameter gesetzt: Es wird ein leeres Ergebnis geliefert (Abwärtskompatibilität).\n\n**Gelieferte Daten**\n- Kopffelder des Auftrags, Kundendaten, Zahlungs-/Bankdaten der Rechnungsadresse sowie Name und Anschrift der Lieferadresse.\n- Aggregate über die Auftragspositionen: `Shipdate`/`LastShipdate` (frühestes/spätestes `ScanOutDate` der verknüpften Rechnungen), `TrackingID`, `ShipVendor`, `LastInvoiceNr` (höchste Rechnungsnummer), `VoucherID` (höchste Gutschein-ID der Positionen) mit `VoucherAmount` aus der Gutscheintabelle, `EstimatedDelivery` (spätester voraussichtlicher Liefertermin) und `TotalDiscount` (Summe aus `DiscountValue` × `Qty` für Positionen, die nicht im Status `STO` oder `NLB` sind).\n- Berücksichtigt werden nur Rechnungen, die keine Gutschriften sind (ohne Verweis auf eine andere Rechnung). Positionen im Status `MIN` werden immer berücksichtigt, andere nur bei Rechnungspositionsmenge > 0 oder ohne Rechnungsposition.\n- `Gender` wird aus der Anrede der Lieferadresse abgeleitet: 1 für `Herr`, `Hr.`, `M.`, `Monsieur`, `Mr`, `Mr.`; 2 für `Mrs`, `Mrs.`, `Ms`, `Ms.`, `Frau`, `Fr.`; sonst 0.\n- `Tags` enthält die Namen der Tags des Auftrags, nach Name sortiert und durch `|` getrennt.\n\nDie Zeilen sind nach `CreateDate` aufsteigend sortiert und auf `RowCount` begrenzt. Passt kein Auftrag, wird eine leere Ergebnismenge mit denselben Spalten geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. Wenn gesetzt (nicht 0), wird genau dieser Auftrag gesucht (Modus 1); nur `CustKey` und `ShopID` wirken als zusätzliche Einschränkung. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer (z. B. Shop-Bestellnummer). Wird verwendet, wenn `OrderNr` nicht gesetzt ist (Modus 2); nur `CustKey` und `ShopID` wirken als zusätzliche Einschränkung. |\n| `CustKey` | int | Nein | Kundenschlüssel. Schränkt das Ergebnis auf Aufträge dieses Kunden ein. 0 gilt als nicht gesetzt. |\n| `FromTime` | datetime | Nein | Nur Filtersuche: liefert Aufträge mit `OrderDate` nach diesem Wert (exklusiv). Datumswerte mehr als 100 Jahre in der Vergangenheit werden ignoriert. |\n| `UntilTime` | datetime | Nein | Nur Filtersuche: liefert Aufträge mit `OrderDate` vor diesem Wert (exklusiv). Datumswerte mehr als 100 Jahre in der Vergangenheit werden ignoriert. |\n| `ShopID` | char(3) | Nein | Shop-ID. Schränkt das Ergebnis auf Aufträge von Kunden ein, deren `CustomerOf` diesem Wert entspricht. Wirkt in allen Modi. |\n| `PaymentType` | char(1) | Nein | Nur Filtersuche: Zahlungsart-Kennzeichen der Rechnungsadresse (`APayment`). |\n| `ShippingCountry` | varchar(3) | Nein | Nur Filtersuche: Ländercode der Lieferadresse. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Aufträge. NULL wird als 1000 behandelt. |\n| `FromUpdateTime` | datetime | Nein | Nur Filtersuche: liefert Aufträge mit `UpdateDate` nach diesem Wert (exklusiv). Datumswerte mehr als 100 Jahre in der Vergangenheit werden ignoriert. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; nicht festgeschriebene Daten können geliefert werden.\n- Die Filtersuche (Modus 3) wird als dynamisches SQL aufgebaut; nur gesetzte Filter werden in die `WHERE`-Klausel übernommen.\n- Für Paging/inkrementellen Export `FromUpdateTime` oder `FromTime` zusammen mit `RowCount` verwenden. Die Auswahl ist nach `CreateDate` sortiert, nicht nach `UpdateDate`, und die Zeitfilter sind exklusiv (`>`/`<`).\n- `RowCount` = 0 liefert keine Zeilen; ein negativer Wert führt zu einem SQL-Fehler bei `TOP`.\n- Aufträge ohne passenden Währungs-, Kunden-, Rechnungsadress- oder Lieferadressdatensatz werden nicht geliefert (Inner Joins). Aufträge ohne Auftragspositionen werden mit leeren Aggregatspalten geliefert.\n- Ist eine Auftragsposition mit mehreren Rechnungspositionen verknüpft, wird ihr Rabatt in `TotalDiscount` je Rechnungsposition gezählt.\n- `OrderTotal_OrderCurr` enthält denselben Wert wie `OrderTotal`. `OrderLocked` stammt aus dem Sperrkennzeichen der Lieferadresse (`N`, falls leer). `CustomerNr` ist die DATEV-Kontonummer des Kunden.\n- Die Einstellungen `NumberOfDecimalPlacesForPrices` und `UseInitialOrderDate` werden gelesen, beeinflussen das Ergebnis aber nicht.\n- Dauert der Aufruf länger als 5 Sekunden, werden Parameter und dynamisches SQL an `LOG.EventDurationInsert` übergeben (Definition nicht beigefügt; vermutlich ein Eintrag in ein Laufzeitprotokoll).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderHeader"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Auftragsköpfe mit Kunden-, Rechnungs- und Lieferadress-, Rechnungs-, Versand-, Gutschein- und Tag-Daten, ausgewählt über Auftragsnummer, externe Auftragsnummer oder Filter.\n\nDer Aufruf wählt Auftragsköpfe in einem von drei Modi aus und liefert eine Zeile je Auftrag.\n\n**Normalisierung der Parameter**\n- `OrderNr` = 0, `CustKey` = 0 sowie leere Zeichenketten für `OrderNrExternal`, `ShopID`, `PaymentType`, `ShippingCountry` gelten als *nicht gesetzt*.\n- Datumsparameter (`FromTime`, `UntilTime`, `FromUpdateTime`), die mehr als 100 Jahre in der Vergangenheit liegen (z. B. `1900-01-01`), gelten als *nicht gesetzt*.\n- `RowCount` = NULL wird zu 1000.\n\n**Auswahlmodi** (die erste zutreffende Regel gilt)\n1. `OrderNr` gesetzt: der Auftrag mit dieser `OrderNr`. Optional eingeschränkt über `CustKey` und `ShopID` (`CustomerOf` des Kunden). Alle anderen Filter werden ignoriert.\n2. `OrderNrExternal` gesetzt: Aufträge mit dieser externen Auftragsnummer, optional eingeschränkt über `CustKey` und `ShopID`. Alle anderen Filter werden ignoriert.\n3. Einer der Parameter `FromTime`, `UntilTime`, `ShopID`, `PaymentType`, `ShippingCountry`, `CustKey`, `FromUpdateTime` gesetzt: Filtersuche, UND-verknüpft:\n - `OrderDate` > `FromTime` und `OrderDate` < `UntilTime` (jeweils exklusiv)\n - `UpdateDate` > `FromUpdateTime` (exklusiv)\n - `CustRef` = `CustKey`\n - `CustomerOf` des Kunden = `ShopID`\n - Land der Lieferadresse = `ShippingCountry`\n - Zahlungsart (`APayment`) der Rechnungsadresse = `PaymentType`\n \n Es werden höchstens `RowCount` Aufträge übernommen, älteste `CreateDate` zuerst.\n4. Kein Parameter gesetzt: Es wird ein leeres Ergebnis geliefert (Abwärtskompatibilität).\n\n**Gelieferte Daten**\n- Kopffelder des Auftrags, Kundendaten, Zahlungs-/Bankdaten der Rechnungsadresse sowie Name und Anschrift der Lieferadresse.\n- Aggregate über die Auftragspositionen: `Shipdate`/`LastShipdate` (frühestes/spätestes `ScanOutDate` der verknüpften Rechnungen), `TrackingID`, `ShipVendor`, `LastInvoiceNr` (höchste Rechnungsnummer), `VoucherID` (höchste Gutschein-ID der Positionen) mit `VoucherAmount` aus der Gutscheintabelle, `EstimatedDelivery` (spätester voraussichtlicher Liefertermin) und `TotalDiscount` (Summe aus `DiscountValue` × `Qty` für Positionen, die nicht im Status `STO` oder `NLB` sind).\n- Berücksichtigt werden nur Rechnungen, die keine Gutschriften sind (ohne Verweis auf eine andere Rechnung). Positionen im Status `MIN` werden immer berücksichtigt, andere nur bei Rechnungspositionsmenge > 0 oder ohne Rechnungsposition.\n- `Gender` wird aus der Anrede der Lieferadresse abgeleitet: 1 für `Herr`, `Hr.`, `M.`, `Monsieur`, `Mr`, `Mr.`; 2 für `Mrs`, `Mrs.`, `Ms`, `Ms.`, `Frau`, `Fr.`; sonst 0.\n- `Tags` enthält die Namen der Tags des Auftrags, nach Name sortiert und durch `|` getrennt.\n\nDie Zeilen sind nach `CreateDate` aufsteigend sortiert und auf `RowCount` begrenzt. Passt kein Auftrag, wird eine leere Ergebnismenge mit denselben Spalten geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. Wenn gesetzt (nicht 0), wird genau dieser Auftrag gesucht (Modus 1); nur `CustKey` und `ShopID` wirken als zusätzliche Einschränkung. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer (z. B. Shop-Bestellnummer). Wird verwendet, wenn `OrderNr` nicht gesetzt ist (Modus 2); nur `CustKey` und `ShopID` wirken als zusätzliche Einschränkung. |\n| `CustKey` | int | Nein | Kundenschlüssel. Schränkt das Ergebnis auf Aufträge dieses Kunden ein. 0 gilt als nicht gesetzt. |\n| `FromTime` | datetime | Nein | Nur Filtersuche: liefert Aufträge mit `OrderDate` nach diesem Wert (exklusiv). Datumswerte mehr als 100 Jahre in der Vergangenheit werden ignoriert. |\n| `UntilTime` | datetime | Nein | Nur Filtersuche: liefert Aufträge mit `OrderDate` vor diesem Wert (exklusiv). Datumswerte mehr als 100 Jahre in der Vergangenheit werden ignoriert. |\n| `ShopID` | char(3) | Nein | Shop-ID. Schränkt das Ergebnis auf Aufträge von Kunden ein, deren `CustomerOf` diesem Wert entspricht. Wirkt in allen Modi. |\n| `PaymentType` | char(1) | Nein | Nur Filtersuche: Zahlungsart-Kennzeichen der Rechnungsadresse (`APayment`). |\n| `ShippingCountry` | varchar(3) | Nein | Nur Filtersuche: Ländercode der Lieferadresse. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Aufträge. NULL wird als 1000 behandelt. |\n| `FromUpdateTime` | datetime | Nein | Nur Filtersuche: liefert Aufträge mit `UpdateDate` nach diesem Wert (exklusiv). Datumswerte mehr als 100 Jahre in der Vergangenheit werden ignoriert. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; nicht festgeschriebene Daten können geliefert werden.\n- Die Filtersuche (Modus 3) wird als dynamisches SQL aufgebaut; nur gesetzte Filter werden in die `WHERE`-Klausel übernommen.\n- Für Paging/inkrementellen Export `FromUpdateTime` oder `FromTime` zusammen mit `RowCount` verwenden. Die Auswahl ist nach `CreateDate` sortiert, nicht nach `UpdateDate`, und die Zeitfilter sind exklusiv (`>`/`<`).\n- `RowCount` = 0 liefert keine Zeilen; ein negativer Wert führt zu einem SQL-Fehler bei `TOP`.\n- Aufträge ohne passenden Währungs-, Kunden-, Rechnungsadress- oder Lieferadressdatensatz werden nicht geliefert (Inner Joins). Aufträge ohne Auftragspositionen werden mit leeren Aggregatspalten geliefert.\n- Ist eine Auftragsposition mit mehreren Rechnungspositionen verknüpft, wird ihr Rabatt in `TotalDiscount` je Rechnungsposition gezählt.\n- `OrderTotal_OrderCurr` enthält denselben Wert wie `OrderTotal`. `OrderLocked` stammt aus dem Sperrkennzeichen der Lieferadresse (`N`, falls leer). `CustomerNr` ist die DATEV-Kontonummer des Kunden.\n- Die Einstellungen `NumberOfDecimalPlacesForPrices` und `UseInitialOrderDate` werden gelesen, beeinflussen das Ergebnis aber nicht.\n- Dauert der Aufruf länger als 5 Sekunden, werden Parameter und dynamisches SQL an `LOG.EventDurationInsert` übergeben (Definition nicht beigefügt; vermutlich ein Eintrag in ein Laufzeitprotokoll).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderHeader"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 48211\n 100234\n 2024-05-14T10:22:31\n SHOP-2024-004711\n 89.9000\n 84.9000\n AUF\n 2024-05-15T14:03:12\n 2024-05-15T14:03:12\n 00340434161094015902\n DHL\n SHP\n 2024-05-14T10:20:00\n 5.0000\n 77120\n 77121\n V\n \n \n 5821\n Frau\n 2\n Müller\n Anna\n DE\n 80331\n München\n Marienplatz\n 1\n 10025821\n EUR\n 89.9000\n anna.mueller@example.com\n N\n RE240512\n 0.0000\n STD\n Express|VIP\n \n"
}
]
},
{
"name": "pixiGetOrderHeaderList",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n SHOP-100234SHOP-100235]]>\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kopfdaten für mehrere Aufträge anhand ihrer externen Auftragsnummern, inklusive Kunden-, Adress-, Zahlungs-, Versand- und Rechnungsinformationen.\n\nErwartet eine Liste externer Auftragsnummern (`OrderNrExternal`) als XML und liefert je passendem Auftrag aus `OrderHeader` eine Zeile.\n\n**Ablauf:**\n\n1. Das XML wird in Werte zerlegt. Gelesen wird jedes Kindelement des Wurzelelements, unabhängig vom Elementnamen. Doppelte Werte werden entfernt.\n2. Ist die Liste leer, gibt die Prozedur `No Data!` per PRINT aus und liefert **kein Resultset**.\n3. Zwei Einstellungen werden gelesen:\n - `UseInitialOrderDate`: bei `1` ist `OrderDate` das früheste Bestelldatum der Auftragspositionen, sonst das späteste.\n - `NumberOfDecimalPlacesForPrices`: Anzahl Nachkommastellen für die Rundung von `Qty * Price` je Position (Standard `2`, wenn die Einstellung fehlt oder `0` ist).\n4. Aufträge werden über `OrderHeader.OrderNrExternal` gefunden. Externe Nummern ohne passenden Auftrag werden ohne Hinweis übergangen.\n5. Ein Auftrag wird nur geliefert, wenn Währung, Kunde, Rechnungsadresse (`AddrRef`) und Lieferadresse (`ShipAdrRef`) vorhanden sind. Diese Verknüpfungen sind Inner Joins.\n6. Je Auftrag werden die Auftragspositionen zusammen mit ihren Rechnungspositionen, ihren Rechnungen (nur Rechnungen mit `RefToInvoiceKey IS NULL`) und ihren voraussichtlichen Lieferterminen aggregiert:\n - Versanddaten (min./max. `ScanOutDate`), Tracking-ID, Versanddienstleister, letzte Rechnungsnummer;\n - `Paid`/`PayedSum` aus den Rechnungen;\n - `OrderTotal_OrderCurr` = Summe der gerundeten Werte `Qty * Price` aller Positionen außer Status `STO` und `NLB`, plus `ShipCost`, minus `Discount`.\n7. `Gender` wird aus der Anrede (`Anrede`) der Lieferadresse abgeleitet:\n - `1` für `Herr`, `Hr.`, `M.`, `Monsieur`, `Mr`, `Mr.`\n - `2` für `Mrs`, `Mrs.`, `Ms`, `Ms.`, `Frau`, `Fr.`\n - `0` für alle anderen Werte.\n\nDie Sortierung erfolgt nach `CreateDate` aufsteigend.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNrExternalXml` | xml | Ja | XML-Liste externer Auftragsnummern. Jedes Kindelement des Wurzelelements enthält eine Nummer. Die Elementnamen werden nicht geprüft; der Code-Kommentar verwendet `…`. |\n\n- Nur lesend. Die meisten Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten erscheinen. Die Unterabfrage für `OrderLocked` auf `Addresses` läuft ohne `NOLOCK`.\n- Die Werte werden als `varchar(256)` zerlegt, aber in einer Schlüsselspalte `varchar(50)` gespeichert. Eine externe Auftragsnummer mit mehr als 50 Zeichen kann den Aufruf mit einem Abschneidefehler abbrechen.\n- Eine leere Eingabe liefert keine Fehlerzeile. Es gibt nur die PRINT-Meldung `No Data!` und keine Zeilen.\n- `EstimatedDelivery` ist nur gefüllt, wenn **jede** Auftragsposition einen voraussichtlichen Liefertermin hat. Dann wird der späteste Termin geliefert. Fehlt bei einer Position der Termin, ist die Spalte `NULL`. Intern wird für fehlende Termine ein Platzhalterdatum (jetzt + 999 Tage) verwendet und danach wieder in `NULL` umgewandelt.\n- `Paid` wird je verknüpfter Zeile berechnet. Auftragspositionen ohne Rechnung gelten ebenfalls als bezahlt, daher kann `Paid` auch bei einem gar nicht berechneten Auftrag `1` sein. `PayedSum` ist die höchste bezahlte Summe unter den Rechnungen, deren `PayedSum` dem auf 2 Stellen gerundeten Rechnungsbetrag entspricht.\n- Die Auftragspositionen werden mit Rechnungspositionen und Lieferterminen verknüpft. Hat eine Position mehrere Rechnungspositionen oder mehrere Liefertermin-Einträge, wird sie in `OrderTotal_OrderCurr` mehrfach gezählt.\n- Die Positionspreise stammen aus `Price` (nicht aus dem Preis in Auftragswährung), obwohl die Spalte `OrderTotal_OrderCurr` heißt.\n- Die Quelltabelle von `SubShopName` und `SubShopLogo` ist im Code nicht qualifiziert. Vermutlich stammen die Spalten aus `OrderHeader`.\n- Die `Gender`-Zuordnung vergleicht die Anrede exakt. Ob dabei Groß-/Kleinschreibung beachtet wird, hängt von der Datenbank-Collation ab.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderHeaderList"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n SHOP-100234SHOP-100235]]>\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kopfdaten für mehrere Aufträge anhand ihrer externen Auftragsnummern, inklusive Kunden-, Adress-, Zahlungs-, Versand- und Rechnungsinformationen.\n\nErwartet eine Liste externer Auftragsnummern (`OrderNrExternal`) als XML und liefert je passendem Auftrag aus `OrderHeader` eine Zeile.\n\n**Ablauf:**\n\n1. Das XML wird in Werte zerlegt. Gelesen wird jedes Kindelement des Wurzelelements, unabhängig vom Elementnamen. Doppelte Werte werden entfernt.\n2. Ist die Liste leer, gibt die Prozedur `No Data!` per PRINT aus und liefert **kein Resultset**.\n3. Zwei Einstellungen werden gelesen:\n - `UseInitialOrderDate`: bei `1` ist `OrderDate` das früheste Bestelldatum der Auftragspositionen, sonst das späteste.\n - `NumberOfDecimalPlacesForPrices`: Anzahl Nachkommastellen für die Rundung von `Qty * Price` je Position (Standard `2`, wenn die Einstellung fehlt oder `0` ist).\n4. Aufträge werden über `OrderHeader.OrderNrExternal` gefunden. Externe Nummern ohne passenden Auftrag werden ohne Hinweis übergangen.\n5. Ein Auftrag wird nur geliefert, wenn Währung, Kunde, Rechnungsadresse (`AddrRef`) und Lieferadresse (`ShipAdrRef`) vorhanden sind. Diese Verknüpfungen sind Inner Joins.\n6. Je Auftrag werden die Auftragspositionen zusammen mit ihren Rechnungspositionen, ihren Rechnungen (nur Rechnungen mit `RefToInvoiceKey IS NULL`) und ihren voraussichtlichen Lieferterminen aggregiert:\n - Versanddaten (min./max. `ScanOutDate`), Tracking-ID, Versanddienstleister, letzte Rechnungsnummer;\n - `Paid`/`PayedSum` aus den Rechnungen;\n - `OrderTotal_OrderCurr` = Summe der gerundeten Werte `Qty * Price` aller Positionen außer Status `STO` und `NLB`, plus `ShipCost`, minus `Discount`.\n7. `Gender` wird aus der Anrede (`Anrede`) der Lieferadresse abgeleitet:\n - `1` für `Herr`, `Hr.`, `M.`, `Monsieur`, `Mr`, `Mr.`\n - `2` für `Mrs`, `Mrs.`, `Ms`, `Ms.`, `Frau`, `Fr.`\n - `0` für alle anderen Werte.\n\nDie Sortierung erfolgt nach `CreateDate` aufsteigend.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNrExternalXml` | xml | Ja | XML-Liste externer Auftragsnummern. Jedes Kindelement des Wurzelelements enthält eine Nummer. Die Elementnamen werden nicht geprüft; der Code-Kommentar verwendet `…`. |\n\n- Nur lesend. Die meisten Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten erscheinen. Die Unterabfrage für `OrderLocked` auf `Addresses` läuft ohne `NOLOCK`.\n- Die Werte werden als `varchar(256)` zerlegt, aber in einer Schlüsselspalte `varchar(50)` gespeichert. Eine externe Auftragsnummer mit mehr als 50 Zeichen kann den Aufruf mit einem Abschneidefehler abbrechen.\n- Eine leere Eingabe liefert keine Fehlerzeile. Es gibt nur die PRINT-Meldung `No Data!` und keine Zeilen.\n- `EstimatedDelivery` ist nur gefüllt, wenn **jede** Auftragsposition einen voraussichtlichen Liefertermin hat. Dann wird der späteste Termin geliefert. Fehlt bei einer Position der Termin, ist die Spalte `NULL`. Intern wird für fehlende Termine ein Platzhalterdatum (jetzt + 999 Tage) verwendet und danach wieder in `NULL` umgewandelt.\n- `Paid` wird je verknüpfter Zeile berechnet. Auftragspositionen ohne Rechnung gelten ebenfalls als bezahlt, daher kann `Paid` auch bei einem gar nicht berechneten Auftrag `1` sein. `PayedSum` ist die höchste bezahlte Summe unter den Rechnungen, deren `PayedSum` dem auf 2 Stellen gerundeten Rechnungsbetrag entspricht.\n- Die Auftragspositionen werden mit Rechnungspositionen und Lieferterminen verknüpft. Hat eine Position mehrere Rechnungspositionen oder mehrere Liefertermin-Einträge, wird sie in `OrderTotal_OrderCurr` mehrfach gezählt.\n- Die Positionspreise stammen aus `Price` (nicht aus dem Preis in Auftragswährung), obwohl die Spalte `OrderTotal_OrderCurr` heißt.\n- Die Quelltabelle von `SubShopName` und `SubShopLogo` ist im Code nicht qualifiziert. Vermutlich stammen die Spalten aus `OrderHeader`.\n- Die `Gender`-Zuordnung vergleicht die Anrede exakt. Ob dabei Groß-/Kleinschreibung beachtet wird, hängt von der Datenbank-Collation ab.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderHeaderList"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 48211\n 100512\n 2024-03-11T09:14:22\n SHOP-100234\n 84.90\n 79.90\n AUS\n 2024-03-12T14:02:00\n 2024-03-12T14:02:00\n 00340434161234567890\n DHL\n WEB\n 2024-03-11T09:14:22\n 5.00\n 70211\n 70212\n PayPal\n 0.00\n 33120\n Frau\n 2\n Muster\n Anna\n DE\n 80331\n München\n Marienplatz 1\n 10045\n EUR\n 84.90\n true\n 84.90\n anna.muster@example.com\n C-55812\n N\n 200781\n \n"
}
]
},
{
"name": "pixiGetOrderHeadersByOrderDate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-01-01T00:00:00\n 2024-01-31T23:59:59\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Auftragsköpfe mit Zahlungs-, Versand-, Gutschein- und Tracking-Daten für alle Aufträge mit Auftragspositionen, deren Bestelldatum im angegebenen Zeitraum liegt.\n\nLiefert eine Zeile je Auftragskopf für alle Aufträge mit mindestens einer Auftragsposition, deren `Orderdate` zwischen `FromDate` und `ToDate` liegt (inklusive, `BETWEEN`).\n\n**Filter**\n- `ShopID` schränkt die Auftragspositionen auf diejenigen ein, deren `CustomerOF` dem angegebenen Shop entspricht. Ein Leerstring wird wie `NULL` behandelt, d. h. alle Shops.\n- Es werden nur Aufträge geliefert, zu denen ein Kunde, eine Rechnungsadresse (`AddrRef`) und eine Währung existieren (Inner Joins auf `Customers`, `Addresses` und `pixi.Currency`).\n\n**Aufbau des Ergebnisses**\n1. Die Basisdaten stammen aus dem Auftragskopf, dem Kunden, der Rechnungsadresse (Bank- und Kreditkartendaten, PLZ) und der Währung (`CurrencyCode`). `OrderLocked` ist das Sperrkennzeichen der Lieferadresse, `N`, falls keine gefunden wird.\n2. `PaymentType` wird aus der Zahlungsart der Rechnungsadresse gefüllt.\n3. `OrderNrExternal`, `OrderDate`, `VoucherID` und `VoucherAmount` stammen aus den Auftragspositionen (bzw. dem Gutschein), `ShipCost` aus dem Auftragskopf.\n4. `TrackingID` (Sendungs-Tracking-ID, sonst die Direct-Fulfillment-Tracking-ID) und `ShipVendor` stammen aus den Rechnungen zu den Positionen des Auftrags.\n5. `Shipdate` ist das früheste und `LastShipdate` das späteste Scan-Out-Datum aller Rechnungen zu den Positionen des Auftrags.\n\nDas Ergebnis ist nach `OrderDate` aufsteigend sortiert. Es gibt kein Paging.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Ja | Beginn des Zeitraums für das Bestelldatum der Auftragspositionen (inklusive). |\n| `ToDate` | datetime | Ja | Ende des Zeitraums für das Bestelldatum der Auftragspositionen (inklusive). |\n| `ShopID` | varchar(3) | Nein | Shop-ID zur Filterung der Auftragspositionen (`CustomerOF`). `NULL` oder Leerstring liefert Aufträge aller Shops. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- `BETWEEN` ist inklusiv: Ist `ToDate` ein Datum ohne Uhrzeit (Mitternacht), werden spätere Auftragspositionen dieses Tages nicht erfasst. Für den ganzen Tag z. B. `2024-01-31T23:59:59` übergeben.\n- Der Shop-Filter wirkt auf `CustomerOF` der Auftragspositionen, das gelieferte `ShopID` ist dagegen `CustomerOf` des Kunden.\n- Bei Aufträgen mit mehreren Positionen oder Rechnungen werden `OrderNrExternal`, `OrderDate`, `VoucherID`, `VoucherAmount`, `TrackingID` und `ShipVendor` aus einer beliebigen passenden Zeile übernommen. `OrderDate` kann daher von einer Position außerhalb des angefragten Zeitraums stammen.\n- `Shipdate`, `LastShipdate`, `TrackingID` und `ShipVendor` sind `NULL`, solange keine Rechnung existiert.\n- Das Ergebnis enthält sensible Zahlungsdaten (Kreditkartennummer, Bankverbindung) der Rechnungsadresse.\n- Kein Paging: Große Zeiträume können große Ergebnisse und lange Laufzeiten verursachen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderHeadersByOrderDate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-01-01T00:00:00\n 2024-01-31T23:59:59\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Auftragsköpfe mit Zahlungs-, Versand-, Gutschein- und Tracking-Daten für alle Aufträge mit Auftragspositionen, deren Bestelldatum im angegebenen Zeitraum liegt.\n\nLiefert eine Zeile je Auftragskopf für alle Aufträge mit mindestens einer Auftragsposition, deren `Orderdate` zwischen `FromDate` und `ToDate` liegt (inklusive, `BETWEEN`).\n\n**Filter**\n- `ShopID` schränkt die Auftragspositionen auf diejenigen ein, deren `CustomerOF` dem angegebenen Shop entspricht. Ein Leerstring wird wie `NULL` behandelt, d. h. alle Shops.\n- Es werden nur Aufträge geliefert, zu denen ein Kunde, eine Rechnungsadresse (`AddrRef`) und eine Währung existieren (Inner Joins auf `Customers`, `Addresses` und `pixi.Currency`).\n\n**Aufbau des Ergebnisses**\n1. Die Basisdaten stammen aus dem Auftragskopf, dem Kunden, der Rechnungsadresse (Bank- und Kreditkartendaten, PLZ) und der Währung (`CurrencyCode`). `OrderLocked` ist das Sperrkennzeichen der Lieferadresse, `N`, falls keine gefunden wird.\n2. `PaymentType` wird aus der Zahlungsart der Rechnungsadresse gefüllt.\n3. `OrderNrExternal`, `OrderDate`, `VoucherID` und `VoucherAmount` stammen aus den Auftragspositionen (bzw. dem Gutschein), `ShipCost` aus dem Auftragskopf.\n4. `TrackingID` (Sendungs-Tracking-ID, sonst die Direct-Fulfillment-Tracking-ID) und `ShipVendor` stammen aus den Rechnungen zu den Positionen des Auftrags.\n5. `Shipdate` ist das früheste und `LastShipdate` das späteste Scan-Out-Datum aller Rechnungen zu den Positionen des Auftrags.\n\nDas Ergebnis ist nach `OrderDate` aufsteigend sortiert. Es gibt kein Paging.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Ja | Beginn des Zeitraums für das Bestelldatum der Auftragspositionen (inklusive). |\n| `ToDate` | datetime | Ja | Ende des Zeitraums für das Bestelldatum der Auftragspositionen (inklusive). |\n| `ShopID` | varchar(3) | Nein | Shop-ID zur Filterung der Auftragspositionen (`CustomerOF`). `NULL` oder Leerstring liefert Aufträge aller Shops. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- `BETWEEN` ist inklusiv: Ist `ToDate` ein Datum ohne Uhrzeit (Mitternacht), werden spätere Auftragspositionen dieses Tages nicht erfasst. Für den ganzen Tag z. B. `2024-01-31T23:59:59` übergeben.\n- Der Shop-Filter wirkt auf `CustomerOF` der Auftragspositionen, das gelieferte `ShopID` ist dagegen `CustomerOf` des Kunden.\n- Bei Aufträgen mit mehreren Positionen oder Rechnungen werden `OrderNrExternal`, `OrderDate`, `VoucherID`, `VoucherAmount`, `TrackingID` und `ShipVendor` aus einer beliebigen passenden Zeile übernommen. `OrderDate` kann daher von einer Position außerhalb des angefragten Zeitraums stammen.\n- `Shipdate`, `LastShipdate`, `TrackingID` und `ShipVendor` sind `NULL`, solange keine Rechnung existiert.\n- Das Ergebnis enthält sensible Zahlungsdaten (Kreditkartennummer, Bankverbindung) der Rechnungsadresse.\n- Kein Paging: Große Zeiträume können große Ergebnisse und lange Laufzeiten verursachen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderHeadersByOrderDate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 48211\n 100532\n 2024-01-15T10:22:31\n WEB-778812\n 129.9000\n 124.9000\n AUS\n 2024-01-16T14:05:00\n 2024-01-16T14:05:00\n 00340434161094042557\n DHL\n SHP\n 2024-01-15T10:20:00\n 4.9900\n 77120\n 77121\n Bitte klingeln\n R\n \n 77120\n 10115\n 30455\n N\n EUR\n \n"
}
]
},
{
"name": "pixiGetOrderHeadersForCustomer",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Auftragsköpfe eines Kunden, ermittelt über Kundenschlüssel oder externe Kundennummer bzw. E-Mail, inklusive Zahlungs-, Gutschein- und Versanddaten.\n\nLiefert eine Zeile pro Auftrag (`OrderHeader`) eines Kunden, sortiert nach `OrderDate` absteigend.\n\n**Kundenauswahl**\n- Ist `CustKey` ungleich `0`, werden nur Aufträge mit `CustRef = CustKey` geliefert. `CustomerNrExternal` und `ShopID` werden in diesem Fall ignoriert.\n- Ist `CustKey` gleich `0` (Standard), werden die Aufträge aller Kunden geliefert, deren `CustomerNrExternal` **oder** E-Mail-Adresse (`CeMail`) dem Wert von `CustomerNrExternal` entspricht. Ist `ShopID` angegeben, muss der Kunde zusätzlich zu diesem Shop gehören (`CustomerOf`). Eine leere `ShopID` wird als `NULL` behandelt (kein Shop-Filter).\n\n**Weitere Filter**\n- `OrderDateFrom`: nur Aufträge mit `OrderDate` ab diesem Zeitpunkt. `NULL` oder leer bedeutet `1900-01-01`.\n- `OrderStatus`: `OPEN`, `HOLD` oder `CLOSED` filtert auf den Auftragsstatus. Jeder andere Wert (oder `NULL`) deaktiviert den Statusfilter.\n\n**Gelieferte Daten pro Auftrag**\n- Kopfdaten wie Auftragsnummer, externe Auftragsnummer, Summen, Versandkosten, Shop-Notiz, Adressbemerkungen und Währungscode (`OrderCurrencyCode` aus der Währung des Auftrags).\n- Zahlungsdaten aus der Rechnungsadresse (`AddrRef`): Zahlungsart, Kreditkarten- und Bankverbindungsfelder, PLZ.\n- `ShopID` ist der Shop, zu dem der **Kunde** gehört (`CustomerOf`).\n- `OrderLocked` ist das Sperrkennzeichen (`ASlocked`) der Lieferadresse, `N` falls nicht gesetzt.\n- `VoucherID` / `VoucherAmount`: höchste Gutschein-ID und höchster Gutscheinbetrag aus den Auftragspositionen (über Positionen referenzierte Gutscheine); `NULL`, wenn der Auftrag keinen Gutschein hat.\n- `Shipdate` / `LastShipdate`: frühestes und spätestes Scan-Out-Datum aller Rechnungen zu den Auftragspositionen.\n- `TrackingID` / `ShipVendor`: aus der Rechnung mit dem höchsten `InvoiceKey`; fehlt dort die Tracking-ID, wird die Direktversand-Tracking-ID der Auftragsposition verwendet. `NULL`, wenn der Auftrag noch nicht berechnet wurde.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Nein | Interner Kundenschlüssel. Ist der Wert ungleich `0`, werden die Aufträge über diesen Schlüssel ermittelt und `CustomerNrExternal`/`ShopID` ignoriert. |\n| `CustomerNrExternal` | varchar(60) | Nein | Externe Kundennummer oder E-Mail-Adresse des Kunden. Wird nur verwendet, wenn `CustKey` gleich `0` ist. |\n| `ShopID` | varchar(3) | Nein | Shop, zu dem der Kunde gehören muss. Wird nur verwendet, wenn `CustKey` gleich `0` ist; leer oder `NULL` bedeutet alle Shops. |\n| `OrderStatus` | varchar(10) | Nein | Optionaler Filter auf den Auftragsstatus. Andere als die aufgeführten Werte deaktivieren den Filter. |\n| `OrderDateFrom` | datetime | Nein | Nur Aufträge mit einem Auftragsdatum ab diesem Zeitpunkt. `NULL` oder leer bedeutet `1900-01-01`. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Ist `CustKey` gleich `0` und `CustomerNrExternal` leer, trifft der Filter auf Kunden mit leerer externer Kundennummer oder leerer E-Mail-Adresse zu. Daher immer entweder `CustKey` oder eine nicht leere `CustomerNrExternal` übergeben.\n- Da auch die E-Mail-Adresse verglichen wird, können mehrere Kunden (z. B. in verschiedenen Shops) zutreffen; zur Einschränkung `ShopID` verwenden.\n- Die interne temporäre Tabelle hat eindeutige Indizes auf `OrderNr` und `AddrRef`. Teilen sich zwei ausgewählte Aufträge dieselbe Rechnungsadresse oder haben mehrere `OrderNr` `NULL`, bricht der Aufruf mit einem SQL-Fehler wegen doppeltem Schlüssel ab.\n- `VoucherID` und `VoucherAmount` werden unabhängig voneinander mit `MAX` ermittelt; bei mehreren Gutscheinen pro Auftrag können die Werte von unterschiedlichen Gutscheinen stammen.\n- Hat die letzte Rechnung mehrere Positionen mit unterschiedlichen Ersatz-Tracking-IDs, ist die Auswahl nicht deterministisch und ein Auftrag kann in seltenen Fällen mehrfach erscheinen.\n- Das Ergebnis enthält sensible Zahlungsdaten (Kartennummer, Bankverbindung).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderHeadersForCustomer"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Auftragsköpfe eines Kunden, ermittelt über Kundenschlüssel oder externe Kundennummer bzw. E-Mail, inklusive Zahlungs-, Gutschein- und Versanddaten.\n\nLiefert eine Zeile pro Auftrag (`OrderHeader`) eines Kunden, sortiert nach `OrderDate` absteigend.\n\n**Kundenauswahl**\n- Ist `CustKey` ungleich `0`, werden nur Aufträge mit `CustRef = CustKey` geliefert. `CustomerNrExternal` und `ShopID` werden in diesem Fall ignoriert.\n- Ist `CustKey` gleich `0` (Standard), werden die Aufträge aller Kunden geliefert, deren `CustomerNrExternal` **oder** E-Mail-Adresse (`CeMail`) dem Wert von `CustomerNrExternal` entspricht. Ist `ShopID` angegeben, muss der Kunde zusätzlich zu diesem Shop gehören (`CustomerOf`). Eine leere `ShopID` wird als `NULL` behandelt (kein Shop-Filter).\n\n**Weitere Filter**\n- `OrderDateFrom`: nur Aufträge mit `OrderDate` ab diesem Zeitpunkt. `NULL` oder leer bedeutet `1900-01-01`.\n- `OrderStatus`: `OPEN`, `HOLD` oder `CLOSED` filtert auf den Auftragsstatus. Jeder andere Wert (oder `NULL`) deaktiviert den Statusfilter.\n\n**Gelieferte Daten pro Auftrag**\n- Kopfdaten wie Auftragsnummer, externe Auftragsnummer, Summen, Versandkosten, Shop-Notiz, Adressbemerkungen und Währungscode (`OrderCurrencyCode` aus der Währung des Auftrags).\n- Zahlungsdaten aus der Rechnungsadresse (`AddrRef`): Zahlungsart, Kreditkarten- und Bankverbindungsfelder, PLZ.\n- `ShopID` ist der Shop, zu dem der **Kunde** gehört (`CustomerOf`).\n- `OrderLocked` ist das Sperrkennzeichen (`ASlocked`) der Lieferadresse, `N` falls nicht gesetzt.\n- `VoucherID` / `VoucherAmount`: höchste Gutschein-ID und höchster Gutscheinbetrag aus den Auftragspositionen (über Positionen referenzierte Gutscheine); `NULL`, wenn der Auftrag keinen Gutschein hat.\n- `Shipdate` / `LastShipdate`: frühestes und spätestes Scan-Out-Datum aller Rechnungen zu den Auftragspositionen.\n- `TrackingID` / `ShipVendor`: aus der Rechnung mit dem höchsten `InvoiceKey`; fehlt dort die Tracking-ID, wird die Direktversand-Tracking-ID der Auftragsposition verwendet. `NULL`, wenn der Auftrag noch nicht berechnet wurde.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Nein | Interner Kundenschlüssel. Ist der Wert ungleich `0`, werden die Aufträge über diesen Schlüssel ermittelt und `CustomerNrExternal`/`ShopID` ignoriert. |\n| `CustomerNrExternal` | varchar(60) | Nein | Externe Kundennummer oder E-Mail-Adresse des Kunden. Wird nur verwendet, wenn `CustKey` gleich `0` ist. |\n| `ShopID` | varchar(3) | Nein | Shop, zu dem der Kunde gehören muss. Wird nur verwendet, wenn `CustKey` gleich `0` ist; leer oder `NULL` bedeutet alle Shops. |\n| `OrderStatus` | varchar(10) | Nein | Optionaler Filter auf den Auftragsstatus. Andere als die aufgeführten Werte deaktivieren den Filter. |\n| `OrderDateFrom` | datetime | Nein | Nur Aufträge mit einem Auftragsdatum ab diesem Zeitpunkt. `NULL` oder leer bedeutet `1900-01-01`. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Ist `CustKey` gleich `0` und `CustomerNrExternal` leer, trifft der Filter auf Kunden mit leerer externer Kundennummer oder leerer E-Mail-Adresse zu. Daher immer entweder `CustKey` oder eine nicht leere `CustomerNrExternal` übergeben.\n- Da auch die E-Mail-Adresse verglichen wird, können mehrere Kunden (z. B. in verschiedenen Shops) zutreffen; zur Einschränkung `ShopID` verwenden.\n- Die interne temporäre Tabelle hat eindeutige Indizes auf `OrderNr` und `AddrRef`. Teilen sich zwei ausgewählte Aufträge dieselbe Rechnungsadresse oder haben mehrere `OrderNr` `NULL`, bricht der Aufruf mit einem SQL-Fehler wegen doppeltem Schlüssel ab.\n- `VoucherID` und `VoucherAmount` werden unabhängig voneinander mit `MAX` ermittelt; bei mehreren Gutscheinen pro Auftrag können die Werte von unterschiedlichen Gutscheinen stammen.\n- Hat die letzte Rechnung mehrere Positionen mit unterschiedlichen Ersatz-Tracking-IDs, ist die Auswahl nicht deterministisch und ein Auftrag kann in seltenen Fällen mehrfach erscheinen.\n- Das Ergebnis enthält sensible Zahlungsdaten (Kartennummer, Bankverbindung).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderHeadersForCustomer"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 558812\n 400123\n 2024-03-11T09:14:22\n WEB-100245\n 89.9000\n 84.9000\n CLOSED\n 2024-03-12T15:02:10\n 2024-03-12T15:02:10\n 00340434161094042557\n DHL\n SH1\n 2024-03-11T09:10:00\n 5.0000\n 912345\n 912346\n \n R\n \n 912345\n 80331\n 10234\n N\n EUR\n \n"
}
]
},
{
"name": "pixiGetOrderNrByAddress",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine Auftragsnummer, deren Auftragspositionen den angegebenen Adressschlüssel als Rechnungs- oder Lieferadresse referenzieren.\n\nErmittelt eine Auftragsnummer zu einem Adressschlüssel. Laut Kommentar im Code wird der Aufruf für Desktop-Benachrichtigungen benötigt.\n\n- Durchsucht die Tabelle `Orderlines` nach Zeilen, bei denen `AddrRef` (Rechnungsadresse) **oder** `ShipAdrRef` (Lieferadresse) gleich `@AddrKey` ist.\n- Es werden nur Zeilen mit `OrderNr > 0` berücksichtigt.\n- Es wird höchstens eine Zeile (`TOP 1`) mit der Spalte `OrderNr` zurückgegeben.\n\nGibt es keine passende Auftragsposition, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AddrKey` | int | Ja | Adressschlüssel. Er wird mit der Rechnungsadressreferenz `AddrRef` und der Lieferadressreferenz `ShipAdrRef` der Auftragspositionen verglichen. |\n\n- `TOP 1` wird ohne `ORDER BY` verwendet. Referenzieren mehrere Aufträge dieselbe Adresse, ist nicht festgelegt, welche Auftragsnummer zurückgegeben wird. Das Ergebnis kann sich zwischen Aufrufen ändern.\n- Die Tabelle wird `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten sichtbar sein.\n- Die Suche erfolgt über Auftragspositionen, nicht über eine Auftragskopftabelle. Aufträge ohne Positionen werden nicht gefunden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderNrByAddress"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine Auftragsnummer, deren Auftragspositionen den angegebenen Adressschlüssel als Rechnungs- oder Lieferadresse referenzieren.\n\nErmittelt eine Auftragsnummer zu einem Adressschlüssel. Laut Kommentar im Code wird der Aufruf für Desktop-Benachrichtigungen benötigt.\n\n- Durchsucht die Tabelle `Orderlines` nach Zeilen, bei denen `AddrRef` (Rechnungsadresse) **oder** `ShipAdrRef` (Lieferadresse) gleich `@AddrKey` ist.\n- Es werden nur Zeilen mit `OrderNr > 0` berücksichtigt.\n- Es wird höchstens eine Zeile (`TOP 1`) mit der Spalte `OrderNr` zurückgegeben.\n\nGibt es keine passende Auftragsposition, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AddrKey` | int | Ja | Adressschlüssel. Er wird mit der Rechnungsadressreferenz `AddrRef` und der Lieferadressreferenz `ShipAdrRef` der Auftragspositionen verglichen. |\n\n- `TOP 1` wird ohne `ORDER BY` verwendet. Referenzieren mehrere Aufträge dieselbe Adresse, ist nicht festgelegt, welche Auftragsnummer zurückgegeben wird. Das Ergebnis kann sich zwischen Aufrufen ändern.\n- Die Tabelle wird `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten sichtbar sein.\n- Die Suche erfolgt über Auftragspositionen, nicht über eine Auftragskopftabelle. Aufträge ohne Positionen werden nicht gefunden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderNrByAddress"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 250117\n \n"
}
]
},
{
"name": "pixiGetOrderNrByOrderNrExternal",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n SHOP-100234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Pixi-Auftragsnummer (OrderNr) zu einer externen Auftragsnummer oder 0, wenn kein passender Auftrag existiert.\n\nSkalare Funktion, die eine externe Auftragsnummer (z. B. die Bestellnummer eines Onlineshops) in die interne Pixi-Auftragsnummer übersetzt.\n\n- Durchsucht die Auftragspositionen (`Orderlines`), deren `OrderNrExternal` exakt dem Parameter `OrderNrExternal` entspricht.\n- Verknüpft jede gefundene Position über `OrderNr` mit dem Auftragskopf (`OrderHeader`), sodass nur Aufträge mit vorhandenem Kopf berücksichtigt werden.\n- Passen mehrere Aufträge, wird die höchste `OrderNr` geliefert.\n- Wird nichts gefunden, ist das Ergebnis `0` statt NULL.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNrExternal` | varchar(50) | Ja | Externe Auftragsnummer, wie sie in `Orderlines.OrderNrExternal` gespeichert ist; Vergleich auf exakte Gleichheit. |\n\n- Die externe Auftragsnummer wird aus den Auftragspositionen gelesen, nicht aus dem Auftragskopf. Ein Auftrag ohne Positionen wird nicht gefunden.\n- Beide Tabellen werden `WITH(NOLOCK)` gelesen; nicht festgeschriebene Daten können sichtbar sein.\n- Wurde dieselbe externe Nummer für mehrere Aufträge verwendet, wird nur die höchste `OrderNr` geliefert; weitere Treffer werden ohne Hinweis ignoriert.\n- Bei Übergabe von NULL gibt es keinen Treffer, das Ergebnis ist `0`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderNrByOrderNrExternal"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n SHOP-100234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Pixi-Auftragsnummer (OrderNr) zu einer externen Auftragsnummer oder 0, wenn kein passender Auftrag existiert.\n\nSkalare Funktion, die eine externe Auftragsnummer (z. B. die Bestellnummer eines Onlineshops) in die interne Pixi-Auftragsnummer übersetzt.\n\n- Durchsucht die Auftragspositionen (`Orderlines`), deren `OrderNrExternal` exakt dem Parameter `OrderNrExternal` entspricht.\n- Verknüpft jede gefundene Position über `OrderNr` mit dem Auftragskopf (`OrderHeader`), sodass nur Aufträge mit vorhandenem Kopf berücksichtigt werden.\n- Passen mehrere Aufträge, wird die höchste `OrderNr` geliefert.\n- Wird nichts gefunden, ist das Ergebnis `0` statt NULL.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNrExternal` | varchar(50) | Ja | Externe Auftragsnummer, wie sie in `Orderlines.OrderNrExternal` gespeichert ist; Vergleich auf exakte Gleichheit. |\n\n- Die externe Auftragsnummer wird aus den Auftragspositionen gelesen, nicht aus dem Auftragskopf. Ein Auftrag ohne Positionen wird nicht gefunden.\n- Beide Tabellen werden `WITH(NOLOCK)` gelesen; nicht festgeschriebene Daten können sichtbar sein.\n- Wurde dieselbe externe Nummer für mehrere Aufträge verwendet, wird nur die höchste `OrderNr` geliefert; weitere Treffer werden ohne Hinweis ignoriert.\n- Bei Übergabe von NULL gibt es keinen Treffer, das Ergebnis ist `0`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderNrByOrderNrExternal"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 458921\n \n"
}
]
},
{
"name": "pixiGetOrderNrExternalByBoxNr",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100245\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Pixi-Auftragsnummern und externen Auftragsnummern aller Aufträge, deren Auftragspositionen in einer bestimmten Box enthalten sind.\n\nSucht eine Box anhand ihrer Nummer und liefert die Aufträge, deren Auftragspositionen in dieser Box enthalten sind.\n\n- Die Box wird über `BoxNr` aus der Tabelle `boxes` ermittelt.\n- Die Boxpositionen (`boxitems`) werden mit den Auftragspositionen (`Orderlines`) und diese mit dem Auftragskopf (`OrderHeader`) verknüpft.\n- Ist `LocId` angegeben, werden nur Boxen dieses Standorts (`LocationID`) berücksichtigt. Ein leerer String wird wie `NULL` behandelt, dann wird über alle Standorte gesucht.\n- Das Ergebnis ist `DISTINCT`: Jeder Auftrag erscheint nur einmal, auch wenn mehrere seiner Positionen in der Box liegen. Eine Box kann Positionen mehrerer Aufträge enthalten, daher sind mehrere Zeilen möglich.\n- Es wird keine explizite Sortierung vorgenommen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BoxNr` | int | Ja | Nummer der Box (`boxes.BoxNr`), deren Aufträge geliefert werden sollen. |\n| `LocId` | varchar(3) | Nein | Optionale Standort-ID, um die Suche nach der Box auf einen Standort einzuschränken (`boxes.LocationID`). `NULL` oder leerer String durchsucht alle Standorte. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- Existiert keine Box mit der angegebenen Nummer (oder gehört sie zu einem anderen Standort) oder enthält die Box keine Auftragspositionen, wird eine leere Ergebnismenge geliefert; es gibt keine Fehlerzeile.\n- `OrderNrExternal` wird als leerer String geliefert, wenn der Auftrag keine externe Auftragsnummer hat. Das `ISNULL` auf `OrderNr` hat wegen der Inner Joins praktisch keine Wirkung.\n- Ohne `LocId` werden Boxen mit gleicher Nummer an verschiedenen Standorten gemeinsam berücksichtigt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderNrExternalByBoxNr"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100245\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Pixi-Auftragsnummern und externen Auftragsnummern aller Aufträge, deren Auftragspositionen in einer bestimmten Box enthalten sind.\n\nSucht eine Box anhand ihrer Nummer und liefert die Aufträge, deren Auftragspositionen in dieser Box enthalten sind.\n\n- Die Box wird über `BoxNr` aus der Tabelle `boxes` ermittelt.\n- Die Boxpositionen (`boxitems`) werden mit den Auftragspositionen (`Orderlines`) und diese mit dem Auftragskopf (`OrderHeader`) verknüpft.\n- Ist `LocId` angegeben, werden nur Boxen dieses Standorts (`LocationID`) berücksichtigt. Ein leerer String wird wie `NULL` behandelt, dann wird über alle Standorte gesucht.\n- Das Ergebnis ist `DISTINCT`: Jeder Auftrag erscheint nur einmal, auch wenn mehrere seiner Positionen in der Box liegen. Eine Box kann Positionen mehrerer Aufträge enthalten, daher sind mehrere Zeilen möglich.\n- Es wird keine explizite Sortierung vorgenommen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BoxNr` | int | Ja | Nummer der Box (`boxes.BoxNr`), deren Aufträge geliefert werden sollen. |\n| `LocId` | varchar(3) | Nein | Optionale Standort-ID, um die Suche nach der Box auf einen Standort einzuschränken (`boxes.LocationID`). `NULL` oder leerer String durchsucht alle Standorte. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- Existiert keine Box mit der angegebenen Nummer (oder gehört sie zu einem anderen Standort) oder enthält die Box keine Auftragspositionen, wird eine leere Ergebnismenge geliefert; es gibt keine Fehlerzeile.\n- `OrderNrExternal` wird als leerer String geliefert, wenn der Auftrag keine externe Auftragsnummer hat. Das `ISNULL` auf `OrderNr` hat wegen der Inner Joins praktisch keine Wirkung.\n- Ohne `LocId` werden Boxen mit gleicher Nummer an verschiedenen Standorten gemeinsam berücksichtigt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderNrExternalByBoxNr"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 458712\n SHOP-2024-00981\n \n \n 458730\n SHOP-2024-01002\n \n"
}
]
},
{
"name": "pixiGetOrdersByDeliveryDate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Aufträge mit Lieferadresse, deren Lieferdatum (ShipDate) eine bestimmte Anzahl Tage in der Zukunft liegt, einem Datum entspricht oder in der Zukunft liegt.\n\nLiest Aufträge aus `OrderHeader` zusammen mit ihrer Lieferadresse (`Addresses` über `ShipAdrRef`) und liefert Auftragsnummer, Auftragsdatum, Lieferdatum, Versandart sowie die Felder der Lieferadresse.\n\nDer Datumsfilter besteht aus drei Alternativen, die mit **ODER** verknüpft sind:\n\n- `DaysToDeliveryDate`: Aufträge, deren `ShipDate` genau so viele Kalendertage nach dem heutigen Tag liegt (Tagesgrenzen über `DATEDIFF(DAY, ...)`; `0` = heute, negative Werte = vergangene Tage).\n- `DeliveryDate`: Aufträge, deren `ShipDate` **exakt** dem übergebenen Datums-/Zeitwert entspricht.\n- Werden weder `DaysToDeliveryDate` noch `DeliveryDate` übergeben, werden alle Aufträge geliefert, deren `ShipDate` nach dem aktuellen Zeitpunkt liegt.\n\nWerden beide Datumsparameter übergeben, werden Aufträge geliefert, die einem der beiden Kriterien entsprechen.\n\nZusätzliche Filter (UND-verknüpft):\n\n- `ShipVendor`: nur Aufträge mit diesem `ShipVendorCode`.\n- `ShopID`: nur Aufträge, deren Lieferadresse diese `AddrShopID` hat.\n\nEine Sortierung ist nicht definiert; die Reihenfolge der Zeilen ist beliebig. Paging gibt es nicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DaysToDeliveryDate` | int | Nein | Anzahl Kalendertage von heute bis zum Lieferdatum (`ShipDate`). `0` = heute, `1` = morgen. Mit `DeliveryDate` per ODER verknüpft. |\n| `DeliveryDate` | datetime | Nein | Exaktes Lieferdatum; wird per Gleichheit inklusive Uhrzeit mit `ShipDate` verglichen. Mit `DaysToDeliveryDate` per ODER verknüpft. |\n| `ShipVendor` | varchar(3) | Nein | Code der Versandart (`ShipVendorCode`) als Filter. `NULL` = alle Versandarten. |\n| `ShopID` | varchar(3) | Nein | Shop-ID der Lieferadresse (`AddrShopID`) als Filter. `NULL` = alle Shops. |\n\n- `DeliveryDate` wird exakt inklusive Uhrzeit mit `ShipDate` verglichen. Enthält `ShipDate` eine Uhrzeit, muss der exakte Wert übergeben oder stattdessen `DaysToDeliveryDate` verwendet werden.\n- Der Shop-Filter bezieht sich auf den Shop der Lieferadresse (`AddrShopID`), nicht auf ein Feld des Auftragskopfs.\n- Aufträge ohne passende Lieferadresse werden nicht geliefert (Inner Join).\n- Der Auftragsstatus wird nicht gefiltert; stornierte oder bereits versendete Aufträge können enthalten sein.\n- Ohne Parameter werden alle Aufträge mit Lieferdatum in der Zukunft geliefert, was eine große Ergebnismenge ergeben kann.\n- Der Kopfkommentar der Prozedur (\"Template for getting items...\") ist ein Überbleibsel und beschreibt die Prozedur nicht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrdersByDeliveryDate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Aufträge mit Lieferadresse, deren Lieferdatum (ShipDate) eine bestimmte Anzahl Tage in der Zukunft liegt, einem Datum entspricht oder in der Zukunft liegt.\n\nLiest Aufträge aus `OrderHeader` zusammen mit ihrer Lieferadresse (`Addresses` über `ShipAdrRef`) und liefert Auftragsnummer, Auftragsdatum, Lieferdatum, Versandart sowie die Felder der Lieferadresse.\n\nDer Datumsfilter besteht aus drei Alternativen, die mit **ODER** verknüpft sind:\n\n- `DaysToDeliveryDate`: Aufträge, deren `ShipDate` genau so viele Kalendertage nach dem heutigen Tag liegt (Tagesgrenzen über `DATEDIFF(DAY, ...)`; `0` = heute, negative Werte = vergangene Tage).\n- `DeliveryDate`: Aufträge, deren `ShipDate` **exakt** dem übergebenen Datums-/Zeitwert entspricht.\n- Werden weder `DaysToDeliveryDate` noch `DeliveryDate` übergeben, werden alle Aufträge geliefert, deren `ShipDate` nach dem aktuellen Zeitpunkt liegt.\n\nWerden beide Datumsparameter übergeben, werden Aufträge geliefert, die einem der beiden Kriterien entsprechen.\n\nZusätzliche Filter (UND-verknüpft):\n\n- `ShipVendor`: nur Aufträge mit diesem `ShipVendorCode`.\n- `ShopID`: nur Aufträge, deren Lieferadresse diese `AddrShopID` hat.\n\nEine Sortierung ist nicht definiert; die Reihenfolge der Zeilen ist beliebig. Paging gibt es nicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DaysToDeliveryDate` | int | Nein | Anzahl Kalendertage von heute bis zum Lieferdatum (`ShipDate`). `0` = heute, `1` = morgen. Mit `DeliveryDate` per ODER verknüpft. |\n| `DeliveryDate` | datetime | Nein | Exaktes Lieferdatum; wird per Gleichheit inklusive Uhrzeit mit `ShipDate` verglichen. Mit `DaysToDeliveryDate` per ODER verknüpft. |\n| `ShipVendor` | varchar(3) | Nein | Code der Versandart (`ShipVendorCode`) als Filter. `NULL` = alle Versandarten. |\n| `ShopID` | varchar(3) | Nein | Shop-ID der Lieferadresse (`AddrShopID`) als Filter. `NULL` = alle Shops. |\n\n- `DeliveryDate` wird exakt inklusive Uhrzeit mit `ShipDate` verglichen. Enthält `ShipDate` eine Uhrzeit, muss der exakte Wert übergeben oder stattdessen `DaysToDeliveryDate` verwendet werden.\n- Der Shop-Filter bezieht sich auf den Shop der Lieferadresse (`AddrShopID`), nicht auf ein Feld des Auftragskopfs.\n- Aufträge ohne passende Lieferadresse werden nicht geliefert (Inner Join).\n- Der Auftragsstatus wird nicht gefiltert; stornierte oder bereits versendete Aufträge können enthalten sein.\n- Ohne Parameter werden alle Aufträge mit Lieferdatum in der Zukunft geliefert, was eine große Ergebnismenge ergeben kann.\n- Der Kopfkommentar der Prozedur (\"Template for getting items...\") ist ein Überbleibsel und beschreibt die Prozedur nicht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrdersByDeliveryDate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 104523\n 2024-06-10T09:15:00\n 2024-06-14T00:00:00\n DHL\n anna.mueller@example.de\n Anna\n Müller\n Anna Müller\n \n Hauptstraße 12\n Hauptstraße\n 12\n 80331\n München\n DE\n SHP\n \n"
}
]
},
{
"name": "pixiGetOrdersReadyForPickup",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Aufträge mit reservierten Auftragspositionen, die Kunden an einem bestimmten POS-Standort abholen können, samt Kundenreferenz.\n\nListet Aufträge auf, die an einem POS-Standort zur Abholung durch den Kunden bereitstehen.\n\nEin Auftrag wird geliefert, wenn er mindestens eine Auftragsposition hat, die alle folgenden Bedingungen erfüllt:\n\n- die `LocationID` der Position entspricht `LocationId`;\n- der Standort der Position existiert in `Location` und hat einen Reservierungsstandort (`ResLocID`), der ebenfalls in `Location` existiert;\n- die `CustRef` der Position verweist auf einen vorhandenen Kunden in `Customers`;\n- für die Position existiert eine Reservierung in `Reservation` (`ResOrderlineRef` = Schlüssel der Auftragsposition);\n- der Positionsstatus ist `ANG` oder `HAL`;\n- das Auftragsdatum ist nicht älter als die Reservierungsfrist in Tagen: `ResExpDays` des Reservierungsstandorts oder, falls dieser NULL ist, der Wert der Einstellung `ReservationExpiry`.\n\nZusätzlich wird der gesamte Auftrag ausgeschlossen, wenn **irgendeine** seiner Auftragspositionen einen Artikel betrifft, für den kein `ItemLocationSpecific`-Datensatz zum Reservierungsstandort existiert. Geprüft wird nur das Vorhandensein dieses Datensatzes, nicht der Bestand.\n\nDas Ergebnis ist je Auftragsnummer und Kunde eindeutig und aufsteigend nach Auftragsnummer sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocationId` | varchar(50) | Nein | ID des POS-Standorts (`Location.LocID`), dessen Auftragspositionen geprüft werden. Muss gesetzt sein; bei NULL werden keine Zeilen geliefert. |\n\n- Wird `LocationId` weggelassen (NULL), trifft der Vergleich mit `LocationID` nie zu und das Ergebnis ist immer leer. Es sollte immer ein Standort übergeben werden.\n- Falle beim Fristwert: Auf 14 Tage wird nur zurückgegriffen, wenn die Einstellung `ReservationExpiry` einen Leerstring liefert. `fPIXI_GetSetting` liefert `'0'`, wenn die Einstellung nicht existiert; ohne Einstellung und ohne `ResExpDays` am Reservierungsstandort werden daher nur Aufträge mit heutigem Datum geliefert.\n- Die Frist wird in Kalendertagen zwischen Auftragsdatum und aktuellem Serverdatum gemessen (`DATEDIFF` in Tagen).\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können erscheinen.\n- Nur lesend; es werden keine Daten geändert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrdersReadyForPickup"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Aufträge mit reservierten Auftragspositionen, die Kunden an einem bestimmten POS-Standort abholen können, samt Kundenreferenz.\n\nListet Aufträge auf, die an einem POS-Standort zur Abholung durch den Kunden bereitstehen.\n\nEin Auftrag wird geliefert, wenn er mindestens eine Auftragsposition hat, die alle folgenden Bedingungen erfüllt:\n\n- die `LocationID` der Position entspricht `LocationId`;\n- der Standort der Position existiert in `Location` und hat einen Reservierungsstandort (`ResLocID`), der ebenfalls in `Location` existiert;\n- die `CustRef` der Position verweist auf einen vorhandenen Kunden in `Customers`;\n- für die Position existiert eine Reservierung in `Reservation` (`ResOrderlineRef` = Schlüssel der Auftragsposition);\n- der Positionsstatus ist `ANG` oder `HAL`;\n- das Auftragsdatum ist nicht älter als die Reservierungsfrist in Tagen: `ResExpDays` des Reservierungsstandorts oder, falls dieser NULL ist, der Wert der Einstellung `ReservationExpiry`.\n\nZusätzlich wird der gesamte Auftrag ausgeschlossen, wenn **irgendeine** seiner Auftragspositionen einen Artikel betrifft, für den kein `ItemLocationSpecific`-Datensatz zum Reservierungsstandort existiert. Geprüft wird nur das Vorhandensein dieses Datensatzes, nicht der Bestand.\n\nDas Ergebnis ist je Auftragsnummer und Kunde eindeutig und aufsteigend nach Auftragsnummer sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocationId` | varchar(50) | Nein | ID des POS-Standorts (`Location.LocID`), dessen Auftragspositionen geprüft werden. Muss gesetzt sein; bei NULL werden keine Zeilen geliefert. |\n\n- Wird `LocationId` weggelassen (NULL), trifft der Vergleich mit `LocationID` nie zu und das Ergebnis ist immer leer. Es sollte immer ein Standort übergeben werden.\n- Falle beim Fristwert: Auf 14 Tage wird nur zurückgegriffen, wenn die Einstellung `ReservationExpiry` einen Leerstring liefert. `fPIXI_GetSetting` liefert `'0'`, wenn die Einstellung nicht existiert; ohne Einstellung und ohne `ResExpDays` am Reservierungsstandort werden daher nur Aufträge mit heutigem Datum geliefert.\n- Die Frist wird in Kalendertagen zwischen Auftragsdatum und aktuellem Serverdatum gemessen (`DATEDIFF` in Tagen).\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können erscheinen.\n- Nur lesend; es werden keine Daten geändert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrdersReadyForPickup"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 100245\n 5821\n \n \n 100251\n 6034\n \n"
}
]
},
{
"name": "pixiGetOrderTotals",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Auftragspositionen eines Auftrags zusammen mit Auftragssummen, MwSt.- und Versandkostenbeträgen, wie sie die Rechnung ergeben würde.\n\nSucht einen Auftrag und liefert eine Zeile pro Auftragsposition; die Summen aus dem Auftragskopf werden in jeder Zeile wiederholt.\n\n**Auswahl des Auftrags**\n- Ist `OrderNr` gesetzt (nicht `0`/`NULL`), werden die Positionen dieser Pixi-Auftragsnummer verwendet. `OrderNrExternal` wird dann ignoriert.\n- Andernfalls werden bei nicht leerem `OrderNrExternal` die Positionen mit dieser externen Auftragsnummer verwendet.\n- Ist keines von beiden angegeben, wird nichts gefunden.\n- `CustKey` schränkt das Ergebnis optional auf Positionen dieses Kunden ein. `0` oder `NULL` deaktiviert den Filter.\n\n**Verknüpfungen**\n\nDie Positionen benötigen einen passenden Artikel, eine Rechnungsadresse, eine Lieferadresse, einen Kunden, den Shop des Kunden, die Zahlungsart der Rechnungsadresse, einen Auftragskopf und die Auftragswährung. Positionen, bei denen etwas davon fehlt, werden nicht geliefert.\n\n**Statusauswertung**\n- Werden keine Positionen gefunden, wird eine Zeile mit `ErrorMessage` = `No results found` geliefert.\n- Haben alle gefundenen Positionen den Status `STO` (storniert), wird eine Zeile mit `ErrorMessage` = `Only orderlines with status STO found` geliefert.\n- Andernfalls werden alle Positionen mit einem Status ungleich `STO` geliefert, mit Positionswerten (EAN, Lieferantenartikelnummer, Bezeichnung, Menge, Preis, Nettowerte, Notiz) und Kopfwerten (Auftragssumme, Rabatt, MwSt. gesamt/voll/ermäßigt inklusive MwSt. der Versandkosten, Nettosumme der Positionen, Versandkosten brutto und netto, Steuersätze, Währungscode).\n\nEs wird keine Sortierung angewendet.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. Hat Vorrang vor `OrderNrExternal`; `0` bedeutet nicht gesetzt. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe (Shop-)Auftragsnummer. Wird nur verwendet, wenn `OrderNr` `0` oder `NULL` ist; leer bedeutet nicht gesetzt. |\n| `CustKey` | int | Nein | Optionaler Kundenschlüssel; schränkt das Ergebnis auf Positionen dieses Kunden ein. `0` oder `NULL` deaktiviert den Filter. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- Kopfwerte (`OrderTotal`, `Discount`, `VATTotal`, `ShipCost` usw.) wiederholen sich in jeder Positionszeile; sie dürfen nicht über die Zeilen summiert werden.\n- `VATTotal`, `VATHigh` und `VATLow` enthalten die MwSt. auf Versandkosten, `NettoTotal` ist dagegen nur die Nettosumme der Positionen ohne Versandkosten.\n- Mehrere Beträge werden auf 2 Nachkommastellen gerundet und nach `float` konvertiert.\n- Positionen mit Status `NULL` werden weder als storniert noch als nicht storniert gezählt und nicht geliefert.\n- Die erste Ergebnismenge hat je nach Ergebnis eine andere Struktur: entweder die Positionsspalten oder eine einzelne Spalte `ErrorMessage`. Vor dem Auslesen sollte auf `ErrorMessage` geprüft werden.\n- Nur stornierte Positionen werden ausgeblendet; der Status selbst wird nicht geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderTotals"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Auftragspositionen eines Auftrags zusammen mit Auftragssummen, MwSt.- und Versandkostenbeträgen, wie sie die Rechnung ergeben würde.\n\nSucht einen Auftrag und liefert eine Zeile pro Auftragsposition; die Summen aus dem Auftragskopf werden in jeder Zeile wiederholt.\n\n**Auswahl des Auftrags**\n- Ist `OrderNr` gesetzt (nicht `0`/`NULL`), werden die Positionen dieser Pixi-Auftragsnummer verwendet. `OrderNrExternal` wird dann ignoriert.\n- Andernfalls werden bei nicht leerem `OrderNrExternal` die Positionen mit dieser externen Auftragsnummer verwendet.\n- Ist keines von beiden angegeben, wird nichts gefunden.\n- `CustKey` schränkt das Ergebnis optional auf Positionen dieses Kunden ein. `0` oder `NULL` deaktiviert den Filter.\n\n**Verknüpfungen**\n\nDie Positionen benötigen einen passenden Artikel, eine Rechnungsadresse, eine Lieferadresse, einen Kunden, den Shop des Kunden, die Zahlungsart der Rechnungsadresse, einen Auftragskopf und die Auftragswährung. Positionen, bei denen etwas davon fehlt, werden nicht geliefert.\n\n**Statusauswertung**\n- Werden keine Positionen gefunden, wird eine Zeile mit `ErrorMessage` = `No results found` geliefert.\n- Haben alle gefundenen Positionen den Status `STO` (storniert), wird eine Zeile mit `ErrorMessage` = `Only orderlines with status STO found` geliefert.\n- Andernfalls werden alle Positionen mit einem Status ungleich `STO` geliefert, mit Positionswerten (EAN, Lieferantenartikelnummer, Bezeichnung, Menge, Preis, Nettowerte, Notiz) und Kopfwerten (Auftragssumme, Rabatt, MwSt. gesamt/voll/ermäßigt inklusive MwSt. der Versandkosten, Nettosumme der Positionen, Versandkosten brutto und netto, Steuersätze, Währungscode).\n\nEs wird keine Sortierung angewendet.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. Hat Vorrang vor `OrderNrExternal`; `0` bedeutet nicht gesetzt. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe (Shop-)Auftragsnummer. Wird nur verwendet, wenn `OrderNr` `0` oder `NULL` ist; leer bedeutet nicht gesetzt. |\n| `CustKey` | int | Nein | Optionaler Kundenschlüssel; schränkt das Ergebnis auf Positionen dieses Kunden ein. `0` oder `NULL` deaktiviert den Filter. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- Kopfwerte (`OrderTotal`, `Discount`, `VATTotal`, `ShipCost` usw.) wiederholen sich in jeder Positionszeile; sie dürfen nicht über die Zeilen summiert werden.\n- `VATTotal`, `VATHigh` und `VATLow` enthalten die MwSt. auf Versandkosten, `NettoTotal` ist dagegen nur die Nettosumme der Positionen ohne Versandkosten.\n- Mehrere Beträge werden auf 2 Nachkommastellen gerundet und nach `float` konvertiert.\n- Positionen mit Status `NULL` werden weder als storniert noch als nicht storniert gezählt und nicht geliefert.\n- Die erste Ergebnismenge hat je nach Ergebnis eine andere Struktur: entweder die Positionsspalten oder eine einzelne Spalte `ErrorMessage`. Vor dem Auslesen sollte auf `ErrorMessage` geprüft werden.\n- Nur stornierte Positionen werden ausgeblendet; der Status selbst wird nicht geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetOrderTotals"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 123456\n 4006381333931\n STB-200\n Stabilo Boss Textmarker gelb\n 2\n 11.9\n 23.8\n SHOP-100045\n \n 10\n 20\n 28.75\n 0\n 4.59\n 4.59\n 0\n 20\n 4.95\n 4.16\n 19\n 7\n EUR\n \n"
}
]
},
{
"name": "pixiGetPartialDeliveryStatus",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Teillieferungs-Einstellungen eines Auftrags: Teillieferung aktiv, Stornierung nicht verfügbarer Artikel und Teillieferung für den Rest.\n\nLiest den Auftragskopf mit der angegebenen `OrderNr` und liefert dessen Teillieferungs-Kennzeichen.\n\n- `PartialDeliveryActive` stammt aus `ForceToPicklistIfNotFULL`. Ist dieser Wert NULL, wird `0` geliefert.\n- `CancelUnavailableItems` stammt aus `OHCancelAfterForcedShipOut`.\n- `PartialDeliveryForRemaining` stammt aus `OHMultiForceToPicklist`.\n\nExistiert kein Auftrag mit dieser Nummer, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Interne Auftragsnummer (`OrderHeader.OrderNr`) des zu prüfenden Auftrags. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können sichtbar sein.\n- Bei unbekannter Auftragsnummer wird keine Fehlerzeile geliefert; es ist zu prüfen, ob die Ergebnismenge eine Zeile enthält.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPartialDeliveryStatus"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Teillieferungs-Einstellungen eines Auftrags: Teillieferung aktiv, Stornierung nicht verfügbarer Artikel und Teillieferung für den Rest.\n\nLiest den Auftragskopf mit der angegebenen `OrderNr` und liefert dessen Teillieferungs-Kennzeichen.\n\n- `PartialDeliveryActive` stammt aus `ForceToPicklistIfNotFULL`. Ist dieser Wert NULL, wird `0` geliefert.\n- `CancelUnavailableItems` stammt aus `OHCancelAfterForcedShipOut`.\n- `PartialDeliveryForRemaining` stammt aus `OHMultiForceToPicklist`.\n\nExistiert kein Auftrag mit dieser Nummer, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Interne Auftragsnummer (`OrderHeader.OrderNr`) des zu prüfenden Auftrags. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können sichtbar sein.\n- Bei unbekannter Auftragsnummer wird keine Fehlerzeile geliefert; es ist zu prüfen, ob die Ergebnismenge eine Zeile enthält.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPartialDeliveryStatus"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 123456\n 1\n 0\n 1\n \n"
}
]
},
{
"name": "pixiGetShippableOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Auftragspositionen vollständig lieferbarer Aufträge oder eine Zusammenfassung dieser Aufträge.\n\nWrapper um `pipiReportGetShippableOrders`. `ShowDetails` wird in ein Bit umgewandelt und als `@ViewDetails` übergeben. Die übrigen Optionen sind fest vorgegeben: keine Teillieferungen, kein Shop-Filter, `@IncludeOrdersWithAnyShipDate = 0`, keine Ausgabe je Lager.\n\n**Berücksichtigte Aufträge**\n- Auftragspositionen mit Status `ANG` oder `EIN`, gesetzter Artikelreferenz (`ItemRef` nicht NULL) und `Qty > 0`.\n- Der Auftrag muss zu einem vorhandenen Kunden gehören.\n- Weder die Liefer- noch die Rechnungsadresse des Auftrags darf gesperrt sein (`ASlocked = 'Y'`).\n- Der Auftrag darf nicht gesperrt sein (`OhSLocked = 'Y'`).\n- Das Versanddatum muss leer oder kleiner als morgen sein. Aufträge mit Versanddatum in der Zukunft werden ausgeschlossen.\n\n**Bestandsprüfung**\n- Der Bestand wird je Position über `pixi_CalculateStockForOrderLines` berechnet, und zwar über die Lager mit `SpecialStock = 0`.\n- Es werden nur **vollständig lieferbare Aufträge** zurückgegeben. Ist eine einzige Position nicht lieferbar, entfällt der gesamte Auftrag.\n\n**Ausgabe**\n- `ShowDetails` ≠ 0 (Standard `1`): eine Zeile je Auftragsposition, sortiert nach `OrderNr` und `OrderlineRef`.\n- `ShowDetails` = 0 oder NULL: eine Summenzeile mit Anzahl der Aufträge, Auftragssumme (Summe aus `Price * Qty`), summierten Versandkosten und Anzahl Picks (Summe `Qty`).\n\n**Währung**\n- Ist die Einstellung `MultiCurrencyEnabled` aktiv, werden Preise und Versandkosten in die Datenbankwährung umgerechnet. Dafür wird der Wechselkurs desselben Datums verwendet, und der Währungscode wird in `dbCurrency` geliefert.\n- Andernfalls bleiben die Werte in Auftragswährung, und `dbCurrency` ist NULL.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShowDetails` | int | Nein | Steuert die Ausgabe. Jeder Wert ungleich 0 liefert eine Zeile je Auftragsposition; 0 oder NULL liefert eine Summenzeile. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten enthalten sein.\n- Die Bestandsberechnung in `pixi_CalculateStockForOrderLines` liegt nicht vor, daher lassen sich ihre genauen Regeln (Reservierungen, Mindestbestand) hier nicht dokumentieren. Sie wird mit `@SkipZeroStockItemsCalc = 1` aufgerufen.\n- Bei aktiver Mehrwährung teilt der Code durch 1, wenn kein passender Wechselkurs gefunden wird. Der Wert bleibt dann ohne Hinweis in Auftragswährung.\n- Im Detailmodus ist `ShipCost` der Versandkostenbetrag des gesamten Auftrags und wird in jeder Position wiederholt. Er darf nicht je Position aufsummiert werden.\n- Im Summenmodus werden die Versandkosten über eindeutige Paare aus `OrderNr` und `ShipCost` summiert.\n- Gibt es keine passenden Aufträge, liefert die Summenzeile trotzdem `Orders = 0` und `ShipCost = 0`; `OrderTotal` und `Picks` sind dann NULL.\n- Für Teillieferungen, Shop-Filter oder Ausgabe je Lager `pixiReportGetShippableOrders` direkt aufrufen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetShippableOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Auftragspositionen vollständig lieferbarer Aufträge oder eine Zusammenfassung dieser Aufträge.\n\nWrapper um `pipiReportGetShippableOrders`. `ShowDetails` wird in ein Bit umgewandelt und als `@ViewDetails` übergeben. Die übrigen Optionen sind fest vorgegeben: keine Teillieferungen, kein Shop-Filter, `@IncludeOrdersWithAnyShipDate = 0`, keine Ausgabe je Lager.\n\n**Berücksichtigte Aufträge**\n- Auftragspositionen mit Status `ANG` oder `EIN`, gesetzter Artikelreferenz (`ItemRef` nicht NULL) und `Qty > 0`.\n- Der Auftrag muss zu einem vorhandenen Kunden gehören.\n- Weder die Liefer- noch die Rechnungsadresse des Auftrags darf gesperrt sein (`ASlocked = 'Y'`).\n- Der Auftrag darf nicht gesperrt sein (`OhSLocked = 'Y'`).\n- Das Versanddatum muss leer oder kleiner als morgen sein. Aufträge mit Versanddatum in der Zukunft werden ausgeschlossen.\n\n**Bestandsprüfung**\n- Der Bestand wird je Position über `pixi_CalculateStockForOrderLines` berechnet, und zwar über die Lager mit `SpecialStock = 0`.\n- Es werden nur **vollständig lieferbare Aufträge** zurückgegeben. Ist eine einzige Position nicht lieferbar, entfällt der gesamte Auftrag.\n\n**Ausgabe**\n- `ShowDetails` ≠ 0 (Standard `1`): eine Zeile je Auftragsposition, sortiert nach `OrderNr` und `OrderlineRef`.\n- `ShowDetails` = 0 oder NULL: eine Summenzeile mit Anzahl der Aufträge, Auftragssumme (Summe aus `Price * Qty`), summierten Versandkosten und Anzahl Picks (Summe `Qty`).\n\n**Währung**\n- Ist die Einstellung `MultiCurrencyEnabled` aktiv, werden Preise und Versandkosten in die Datenbankwährung umgerechnet. Dafür wird der Wechselkurs desselben Datums verwendet, und der Währungscode wird in `dbCurrency` geliefert.\n- Andernfalls bleiben die Werte in Auftragswährung, und `dbCurrency` ist NULL.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShowDetails` | int | Nein | Steuert die Ausgabe. Jeder Wert ungleich 0 liefert eine Zeile je Auftragsposition; 0 oder NULL liefert eine Summenzeile. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten enthalten sein.\n- Die Bestandsberechnung in `pixi_CalculateStockForOrderLines` liegt nicht vor, daher lassen sich ihre genauen Regeln (Reservierungen, Mindestbestand) hier nicht dokumentieren. Sie wird mit `@SkipZeroStockItemsCalc = 1` aufgerufen.\n- Bei aktiver Mehrwährung teilt der Code durch 1, wenn kein passender Wechselkurs gefunden wird. Der Wert bleibt dann ohne Hinweis in Auftragswährung.\n- Im Detailmodus ist `ShipCost` der Versandkostenbetrag des gesamten Auftrags und wird in jeder Position wiederholt. Er darf nicht je Position aufsummiert werden.\n- Im Summenmodus werden die Versandkosten über eindeutige Paare aus `OrderNr` und `ShipCost` summiert.\n- Gibt es keine passenden Aufträge, liefert die Summenzeile trotzdem `Orders = 0` und `ShipCost = 0`; `OrderTotal` und `Picks` sind dann NULL.\n- Für Teillieferungen, Shop-Filter oder Ausgabe je Lager `pixiReportGetShippableOrders` direkt aufrufen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetShippableOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 50211\n 10234\n 2\n 1622\n ANG\n 4.9000\n 19.9900\n 1\n \n \n 50212\n 10234\n 1\n 1730\n ANG\n 4.9000\n 9.5000\n 1\n \n"
}
]
},
{
"name": "pixiGetShippedOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n 2024-01-01T00:00:00\n 2024-01-31T23:59:59\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die versendeten Aufträge (fakturiert mit Historienstatus EIN) eines Zeitraums, entweder als Detailzeilen oder als Anzahl und Summe je Währung.\n\nErmittelt alle Rechnungen eines Zeitraums, die als versendet gelten, und liefert sie entweder detailliert oder verdichtet.\n\n**Auswahl der Rechnungen**\n- Eine Rechnung wird berücksichtigt, wenn mindestens eine ihrer Rechnungspositionen (`Invlines`) auf eine Auftragsposition verweist, zu der ein `OrderHistory`-Eintrag mit Status `EIN` existiert.\n- Der Zeitraum wird per `BETWEEN @FromDate AND @ToDate` gegen `Invoices.InvDate` (Standard) bzw. gegen `Invoices.ScanOutDate` geprüft, wenn `SearchByScanOutDate = 1` ist.\n- Standardmäßig werden nur Rechnungen mit `total > 0` geliefert; mit `IncludeOrdersWithTotalZero = 1` auch Rechnungen mit `total >= 0`. Negative Summen werden nie geliefert.\n- Ist `CustomerNrExternal` gefüllt (der Wert wird getrimmt; leer bedeutet kein Filter), werden nur Rechnungen des Kunden mit dieser externen Kundennummer geliefert.\n\nZu jeder ausgewählten Rechnung werden die unterschiedlichen externen Auftragsnummern (`Orderlines.OrderNrExternal`) ihrer Positionen ermittelt.\n\n**`ShowDetails = 1` (Standard)**\nLiefert eine Zeile je Kombination aus Rechnung und externer Auftragsnummer, sortiert nach `InvDate`. Eine Rechnung über mehrere Aufträge erscheint daher mehrfach. Die Zeilen enthalten Rechnungsdaten, Lieferadresse, Währung, Versanddienstleister, Tracking-ID und den Mitarbeiter, der die Rechnung ausgescannt hat (`ScanOutEmp`: alphabetisch kleinster `UpdateEmp` der `OrderHistory`-Einträge mit Status `AUS`).\n\n**Jeder andere Wert von `ShowDetails`**\nLiefert eine Zeile je Währung mit der Anzahl der Aufträge (Kombinationen aus Rechnung und Auftragsnummer) und der Summe der Rechnungsbeträge, wobei jeder Rechnungsbetrag nur einmal gezählt wird.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShowDetails` | int | Nein | Steuert die Ausgabe: `1` liefert Detailzeilen, jeder andere Wert Anzahl und Summe je Währung. |\n| `FromDate` | varchar(25) | Ja | Beginn des Zeitraums (inklusive), verglichen mit Rechnungsdatum bzw. Ausscandatum. |\n| `ToDate` | varchar(25) | Ja | Ende des Zeitraums (inklusive). Ohne Uhrzeit bedeutet es Mitternacht dieses Tages. |\n| `CustomerNrExternal` | varchar(60) | Nein | Optionale externe Kundennummer zur Einschränkung auf einen Kunden. Leer bedeutet alle Kunden. |\n| `IncludeOrdersWithTotalZero` | bit | Nein | Bei `1` werden auch Rechnungen mit Summe null berücksichtigt, sonst nur Rechnungen mit positiver Summe. |\n| `SearchByScanOutDate` | bit | Nein | Bei `1` wird der Zeitraum auf `ScanOutDate` angewendet, sonst auf das Rechnungsdatum `InvDate`. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- `FromDate` und `ToDate` sind Zeichenketten, die für den `BETWEEN`-Vergleich implizit konvertiert werden. Ein Datum ohne Uhrzeit (z. B. `2024-01-31`) bedeutet Mitternacht, spätere Rechnungen dieses Tages fehlen dann. Daher eine Uhrzeit wie `2024-01-31 23:59:59` oder den Folgetag angeben. Ein eindeutiges Format wie ISO `yyyy-mm-ddThh:mi:ss` verwenden.\n- Im Detailmodus entfallen Rechnungen ohne passende Lieferadresse (`ShipAdrRef`) oder Währung wegen Inner Joins.\n- Im Summenmodus wird keine Zeile geliefert, wenn keine Rechnung passt (die Abfrage verwendet `GROUP BY`).\n- `ScanOutEmp` ist leer, wenn zu den Rechnungspositionen kein `OrderHistory`-Eintrag mit Status `AUS` existiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetShippedOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n 2024-01-01T00:00:00\n 2024-01-31T23:59:59\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die versendeten Aufträge (fakturiert mit Historienstatus EIN) eines Zeitraums, entweder als Detailzeilen oder als Anzahl und Summe je Währung.\n\nErmittelt alle Rechnungen eines Zeitraums, die als versendet gelten, und liefert sie entweder detailliert oder verdichtet.\n\n**Auswahl der Rechnungen**\n- Eine Rechnung wird berücksichtigt, wenn mindestens eine ihrer Rechnungspositionen (`Invlines`) auf eine Auftragsposition verweist, zu der ein `OrderHistory`-Eintrag mit Status `EIN` existiert.\n- Der Zeitraum wird per `BETWEEN @FromDate AND @ToDate` gegen `Invoices.InvDate` (Standard) bzw. gegen `Invoices.ScanOutDate` geprüft, wenn `SearchByScanOutDate = 1` ist.\n- Standardmäßig werden nur Rechnungen mit `total > 0` geliefert; mit `IncludeOrdersWithTotalZero = 1` auch Rechnungen mit `total >= 0`. Negative Summen werden nie geliefert.\n- Ist `CustomerNrExternal` gefüllt (der Wert wird getrimmt; leer bedeutet kein Filter), werden nur Rechnungen des Kunden mit dieser externen Kundennummer geliefert.\n\nZu jeder ausgewählten Rechnung werden die unterschiedlichen externen Auftragsnummern (`Orderlines.OrderNrExternal`) ihrer Positionen ermittelt.\n\n**`ShowDetails = 1` (Standard)**\nLiefert eine Zeile je Kombination aus Rechnung und externer Auftragsnummer, sortiert nach `InvDate`. Eine Rechnung über mehrere Aufträge erscheint daher mehrfach. Die Zeilen enthalten Rechnungsdaten, Lieferadresse, Währung, Versanddienstleister, Tracking-ID und den Mitarbeiter, der die Rechnung ausgescannt hat (`ScanOutEmp`: alphabetisch kleinster `UpdateEmp` der `OrderHistory`-Einträge mit Status `AUS`).\n\n**Jeder andere Wert von `ShowDetails`**\nLiefert eine Zeile je Währung mit der Anzahl der Aufträge (Kombinationen aus Rechnung und Auftragsnummer) und der Summe der Rechnungsbeträge, wobei jeder Rechnungsbetrag nur einmal gezählt wird.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShowDetails` | int | Nein | Steuert die Ausgabe: `1` liefert Detailzeilen, jeder andere Wert Anzahl und Summe je Währung. |\n| `FromDate` | varchar(25) | Ja | Beginn des Zeitraums (inklusive), verglichen mit Rechnungsdatum bzw. Ausscandatum. |\n| `ToDate` | varchar(25) | Ja | Ende des Zeitraums (inklusive). Ohne Uhrzeit bedeutet es Mitternacht dieses Tages. |\n| `CustomerNrExternal` | varchar(60) | Nein | Optionale externe Kundennummer zur Einschränkung auf einen Kunden. Leer bedeutet alle Kunden. |\n| `IncludeOrdersWithTotalZero` | bit | Nein | Bei `1` werden auch Rechnungen mit Summe null berücksichtigt, sonst nur Rechnungen mit positiver Summe. |\n| `SearchByScanOutDate` | bit | Nein | Bei `1` wird der Zeitraum auf `ScanOutDate` angewendet, sonst auf das Rechnungsdatum `InvDate`. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- `FromDate` und `ToDate` sind Zeichenketten, die für den `BETWEEN`-Vergleich implizit konvertiert werden. Ein Datum ohne Uhrzeit (z. B. `2024-01-31`) bedeutet Mitternacht, spätere Rechnungen dieses Tages fehlen dann. Daher eine Uhrzeit wie `2024-01-31 23:59:59` oder den Folgetag angeben. Ein eindeutiges Format wie ISO `yyyy-mm-ddThh:mi:ss` verwenden.\n- Im Detailmodus entfallen Rechnungen ohne passende Lieferadresse (`ShipAdrRef`) oder Währung wegen Inner Joins.\n- Im Summenmodus wird keine Zeile geliefert, wenn keine Rechnung passt (die Abfrage verwendet `GROUP BY`).\n- `ScanOutEmp` ist leer, wenn zu den Rechnungspositionen kein `OrderHistory`-Eintrag mit Status `AUS` existiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetShippedOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 240117\n 2024-01-15T10:24:00\n 2024-01-15T14:02:00\n 89.90\n 00340434161234567890\n Muster GmbH\n Hauptstraße 12\n München\n 80331\n D\n SHOP-100512\n EUR\n DHL\n K-100245\n MMUSTER\n DE\n DEU\n \n"
}
]
},
{
"name": "pixiMergeOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100245\n 100251\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Führt einen Quell-Auftrag mit einem Ziel-Auftrag zusammen, indem alle Auftragspositionen und Bundle-Positionen verschoben und Steuersätze sowie Versandkosten neu berechnet werden.\n\nÜberträgt den Inhalt des Auftrags `SourceOrderNr` in den Auftrag `TargetOrderNr`.\n\n1. Die Auftragsköpfe beider Aufträge werden gelesen (Auftragsart, Währung, Versandkosten).\n2. Bei unterschiedlicher Auftragsart oder Währung wird ein Fehler ausgelöst und abgebrochen. Das geschieht auch, wenn keiner der beiden Aufträge existiert.\n3. `pipiCanMergeOrders` wird ausgeführt. Diese Prozedur prüft die folgenden Bedingungen und liefert eine eigene Ergebniszeile (`CanMerge`, `Reason`):\n - beide Aufträge existieren\n - beide gehören zum selben Kunden\n - alle Positionen haben Status `ANG`\n - beide haben dieselbe Zahlungsart, die keine Kreditkarte `K` sein darf\n - keine Position liegt auf einer aktiven Pickliste\n - beide haben dieselbe Währung und Auftragsart\n4. Ist die Zusammenführung erlaubt, laufen die folgenden Schritte in einer Transaktion:\n - Die Versandkosten im Kopf des Ziel-Auftrags werden auf die höheren Versandkosten der beiden Aufträge gesetzt.\n - Alle vorhandenen Positionen und Bundle-Positionen des Ziel-Auftrags erhalten diese Versandkosten sowie `UpdateEmp` und `UpdateDate`.\n - Die Positionen des Quell-Auftrags werden in den Ziel-Auftrag verschoben. Sie übernehmen Rechnungs- und Lieferadresse, `Order_Id`, `OrderNrExternal` und `VoucherID` der Positionen des Ziel-Auftrags.\n - Ihr `TaxRate` wird über `fPixi_GetVATRate` neu berechnet. Grundlage sind die Auftragsart des Quell-Auftrags sowie Land und Steuerpflicht der Ziel-Lieferadresse.\n - Bei Einstellung `CalculateBundleVAT` = `0` erhalten Bundle-Komponenten den Steuersatz ihrer Bundle-Position.\n - Die Bundle-Positionen des Quell-Auftrags werden ebenso verschoben. Bei `CalculateBundleVAT` = `1` ist ihr Steuersatz der nach Nettobetrag gewichtete Durchschnitt der Komponenten, sonst der Wert aus der Steuerfunktion.\n - Bankzuordnungen (`BankMatch`) des Quell-Auftrags werden dem Ziel-Auftrag zugeordnet.\n - Der `Discount` im Kopf des Quell-Auftrags wird auf 0 gesetzt.\n5. Zurückgegeben wird `ResultMessage`:\n - `200 OK` bei Erfolg\n - der Grundcode aus `pipiCanMergeOrders` (401–407), wenn die Zusammenführung nicht erlaubt ist\n - `500 Unexpected error`, wenn die Transaktion fehlschlägt\n\n`UpdateEmp` wird auf `Employee` mit dem Zusatz ` (API)` gesetzt, ohne Mitarbeiterangabe auf `API`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TargetOrderNr` | int | Ja | Auftragsnummer des Ziel-Auftrags, der die Positionen aufnimmt. |\n| `SourceOrderNr` | int | Ja | Auftragsnummer des Quell-Auftrags, dessen Positionen in den Ziel-Auftrag verschoben werden. |\n| `Employee` | varchar(50) | Nein | Mitarbeitername, der mit dem Zusatz ` (API)` in `UpdateEmp` geschrieben wird. Bei NULL wird `API` verwendet. |\n| `ResultMessage` | varchar(128) | Nein | Ausgabe: Ergebniscode mit Text, z. B. `200 OK`, ein Grund 401–407 aus `pipiCanMergeOrders` oder `500 Unexpected error`. |\n\n- Der Aufruf liefert **zwei** Ergebnismengen. `SqlRowSet1` stammt aus `pipiCanMergeOrders` (`CanMerge`, `Reason`). `SqlRowSet2` enthält `ResultMessage`.\n- Der Kopf des Quell-Auftrags wird **nicht** gelöscht. Er bleibt ohne Positionen und mit `Discount` = 0 bestehen.\n- Beim Aktualisieren der Versandkosten in `OrderHeader` wird `CONTEXT_INFO` 0x66666 gesetzt, um den Update-Trigger zu umgehen.\n- Die aus den Ziel-Positionen übernommenen Werte (Adressen, `Order_Id`, `OrderNrExternal`, `VoucherID`) stammen aus einer beliebigen Position des Ziel-Auftrags. Hat der Ziel-Auftrag keine Positionen, werden diese Werte bei den verschobenen Positionen NULL.\n- Quell-Positionen, deren `ItemRef` keinen passenden Eintrag in `items` hat, werden nicht verschoben.\n- Auch Bundle-Positionen ohne Komponenten werden nicht verschoben.\n- Bei `CalculateBundleVAT` = `1` führt eine Nettosumme von 0 über die Komponenten eines Bundles zu einem Divisionsfehler. Die Transaktion wird dann zurückgerollt und `500 Unexpected error` geliefert.\n- Fehlerdetails werden dabei nicht zurückgegeben; jeder Fehler in der Transaktion liefert nur `500 Unexpected error`.\n- Lesezugriffe erfolgen mit `NOLOCK`.\n- `fPixi_GetDefaultCountryCode`, das in `fPixi_GetVATRate` verwendet wird, liegt nicht vor, daher ist die Ermittlung des Standardlandes hier nicht vollständig beschreibbar.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiMergeOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100245\n 100251\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Führt einen Quell-Auftrag mit einem Ziel-Auftrag zusammen, indem alle Auftragspositionen und Bundle-Positionen verschoben und Steuersätze sowie Versandkosten neu berechnet werden.\n\nÜberträgt den Inhalt des Auftrags `SourceOrderNr` in den Auftrag `TargetOrderNr`.\n\n1. Die Auftragsköpfe beider Aufträge werden gelesen (Auftragsart, Währung, Versandkosten).\n2. Bei unterschiedlicher Auftragsart oder Währung wird ein Fehler ausgelöst und abgebrochen. Das geschieht auch, wenn keiner der beiden Aufträge existiert.\n3. `pipiCanMergeOrders` wird ausgeführt. Diese Prozedur prüft die folgenden Bedingungen und liefert eine eigene Ergebniszeile (`CanMerge`, `Reason`):\n - beide Aufträge existieren\n - beide gehören zum selben Kunden\n - alle Positionen haben Status `ANG`\n - beide haben dieselbe Zahlungsart, die keine Kreditkarte `K` sein darf\n - keine Position liegt auf einer aktiven Pickliste\n - beide haben dieselbe Währung und Auftragsart\n4. Ist die Zusammenführung erlaubt, laufen die folgenden Schritte in einer Transaktion:\n - Die Versandkosten im Kopf des Ziel-Auftrags werden auf die höheren Versandkosten der beiden Aufträge gesetzt.\n - Alle vorhandenen Positionen und Bundle-Positionen des Ziel-Auftrags erhalten diese Versandkosten sowie `UpdateEmp` und `UpdateDate`.\n - Die Positionen des Quell-Auftrags werden in den Ziel-Auftrag verschoben. Sie übernehmen Rechnungs- und Lieferadresse, `Order_Id`, `OrderNrExternal` und `VoucherID` der Positionen des Ziel-Auftrags.\n - Ihr `TaxRate` wird über `fPixi_GetVATRate` neu berechnet. Grundlage sind die Auftragsart des Quell-Auftrags sowie Land und Steuerpflicht der Ziel-Lieferadresse.\n - Bei Einstellung `CalculateBundleVAT` = `0` erhalten Bundle-Komponenten den Steuersatz ihrer Bundle-Position.\n - Die Bundle-Positionen des Quell-Auftrags werden ebenso verschoben. Bei `CalculateBundleVAT` = `1` ist ihr Steuersatz der nach Nettobetrag gewichtete Durchschnitt der Komponenten, sonst der Wert aus der Steuerfunktion.\n - Bankzuordnungen (`BankMatch`) des Quell-Auftrags werden dem Ziel-Auftrag zugeordnet.\n - Der `Discount` im Kopf des Quell-Auftrags wird auf 0 gesetzt.\n5. Zurückgegeben wird `ResultMessage`:\n - `200 OK` bei Erfolg\n - der Grundcode aus `pipiCanMergeOrders` (401–407), wenn die Zusammenführung nicht erlaubt ist\n - `500 Unexpected error`, wenn die Transaktion fehlschlägt\n\n`UpdateEmp` wird auf `Employee` mit dem Zusatz ` (API)` gesetzt, ohne Mitarbeiterangabe auf `API`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TargetOrderNr` | int | Ja | Auftragsnummer des Ziel-Auftrags, der die Positionen aufnimmt. |\n| `SourceOrderNr` | int | Ja | Auftragsnummer des Quell-Auftrags, dessen Positionen in den Ziel-Auftrag verschoben werden. |\n| `Employee` | varchar(50) | Nein | Mitarbeitername, der mit dem Zusatz ` (API)` in `UpdateEmp` geschrieben wird. Bei NULL wird `API` verwendet. |\n| `ResultMessage` | varchar(128) | Nein | Ausgabe: Ergebniscode mit Text, z. B. `200 OK`, ein Grund 401–407 aus `pipiCanMergeOrders` oder `500 Unexpected error`. |\n\n- Der Aufruf liefert **zwei** Ergebnismengen. `SqlRowSet1` stammt aus `pipiCanMergeOrders` (`CanMerge`, `Reason`). `SqlRowSet2` enthält `ResultMessage`.\n- Der Kopf des Quell-Auftrags wird **nicht** gelöscht. Er bleibt ohne Positionen und mit `Discount` = 0 bestehen.\n- Beim Aktualisieren der Versandkosten in `OrderHeader` wird `CONTEXT_INFO` 0x66666 gesetzt, um den Update-Trigger zu umgehen.\n- Die aus den Ziel-Positionen übernommenen Werte (Adressen, `Order_Id`, `OrderNrExternal`, `VoucherID`) stammen aus einer beliebigen Position des Ziel-Auftrags. Hat der Ziel-Auftrag keine Positionen, werden diese Werte bei den verschobenen Positionen NULL.\n- Quell-Positionen, deren `ItemRef` keinen passenden Eintrag in `items` hat, werden nicht verschoben.\n- Auch Bundle-Positionen ohne Komponenten werden nicht verschoben.\n- Bei `CalculateBundleVAT` = `1` führt eine Nettosumme von 0 über die Komponenten eines Bundles zu einem Divisionsfehler. Die Transaktion wird dann zurückgerollt und `500 Unexpected error` geliefert.\n- Fehlerdetails werden dabei nicht zurückgegeben; jeder Fehler in der Transaktion liefert nur `500 Unexpected error`.\n- Lesezugriffe erfolgen mit `NOLOCK`.\n- `fPixi_GetDefaultCountryCode`, das in `fPixi_GetVATRate` verwendet wird, liegt nicht vor, daher ist die Ermittlung des Standardlandes hier nicht vollständig beschreibbar.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiMergeOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 200 OK\n \n"
}
]
},
{
"name": "pixiOrderGetByTags",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 12Express15Marketplace7Blocked]]>\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Aufträge eines Datumsbereichs, gefiltert nach Auftrags-Tags mit AND-, OR- und NOT-Bedingungen aus einem XML-Filter.\n\nSucht Aufträge anhand der zugeordneten Tags. Der Filter wird als XML in `TagFilter` übergeben.\n\n**Auswertung und Prüfung**\n\n- Das XML wird unter `/TagFilter/AND`, `/TagFilter/OR` und `/TagFilter/NOT` gelesen. Jeder Block kann beliebig viele `TagId`- und `TagName`-Elemente enthalten. Tag-Namen werden getrimmt, leere Namen werden ignoriert.\n- Jeder Eintrag wird gegen die Tags vom Typ `2` (Auftrags-Tags) aufgelöst:\n - über `Id`, wenn `TagId` angegeben ist;\n - über den exakten `Name` bei `PartialTagNameMatch` = 0;\n - über `Name LIKE '%…%'` bei `PartialTagNameMatch` = 1.\n- Ein Teiltreffer kann einen Eintrag auf mehrere Tags auflösen.\n- Ein Eintrag ohne passenden Tag erhält den Status `ERROR`.\n- Ein Tag, der in der aufgelösten Liste mehrfach vorkommt, erhält ebenfalls `ERROR`. Das gilt operationsübergreifend und auch innerhalb derselben Operation, z. B. bei Angabe per Id und per Name.\n- Hat ein Eintrag einen Fehler, liefert der Aufruf die vollständige Prüfliste (eine Zeile je aufgelöstem Eintrag) und keine Aufträge.\n- Ist das XML nicht lesbar (oder eine `TagId` nicht numerisch), wird eine einzelne Fehlerzeile geliefert.\n\n**Auftragssuche** (nur bei erfolgreicher Prüfung)\n\n- `DateFrom` ist standardmäßig 6 Monate vor jetzt, `DateTo` jetzt und `RowCount` 1000.\n- Der Datumsbereich wird in einen Schlüsselbereich umgerechnet. Er beginnt beim kleinsten `OrderHeaderKey` mit `OrderDate >= DateFrom` und endet beim größten `OrderHeaderKey` mit `OrderDate < DateTo`. Alle Aufträge mit einem Schlüssel in diesem Bereich werden berücksichtigt.\n- **NOT**: Der Auftrag darf keinen der NOT-Tags tragen.\n- **OR**: Der Auftrag muss mindestens einen der OR-Tags tragen.\n- **AND**: Der Auftrag muss alle AND-Tags tragen.\n- Leere Blöcke werden nicht angewendet. Enthält der Filter keine Tags (oder ist `TagFilter` leer), werden alle Aufträge des Bereichs geliefert.\n- Das Ergebnis wird auf `TOP (RowCount)` begrenzt und nach `OrderHeaderKey` aufsteigend sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagFilter` | varchar(max) | Ja | XML-Filter mit `AND`-, `OR`- und `NOT`-Blöcken unter `TagFilter`, jeweils mit `TagId`- und/oder `TagName`-Elementen. Ein leerer Wert bedeutet keinen Tag-Filter. |\n| `PartialTagNameMatch` | bit | Nein | Steuert, wie `TagName`-Einträge abgeglichen werden. |\n| `StrictANDCondition` | bit | Nein | Obsolet, wird nicht verwendet. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Aufträge. NULL wird als 1000 behandelt. |\n| `DateFrom` | datetime | Nein | Beginn des Auftragsdatumsbereichs (inklusiv). NULL bedeutet 6 Monate vor jetzt. |\n| `DateTo` | datetime | Nein | Ende des Auftragsdatumsbereichs (exklusiv). NULL bedeutet jetzt. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, es können also nicht festgeschriebene Daten geliefert werden.\n- `StrictANDCondition` ist als obsolet markiert und wird nicht verwendet.\n- Der Datumsfilter wirkt über den Schlüsselbereich, nicht direkt über `OrderDate`. Aufträge mit einem Schlüssel im Bereich, deren Datum außerhalb liegt, werden trotzdem geliefert.\n- `DateTo` ist exklusiv.\n- Gibt es zu einer Datumsgrenze keinen Auftrag, ist der Schlüsselbereich leer und es werden keine Zeilen geliefert.\n- Die AND-Prüfung vergleicht die Anzahl passender Tag-Zuordnungen mit der Anzahl der AND-Tags. Doppelte Zuordnungen desselben Tags zu einem Auftrag können das Ergebnis verfälschen.\n- Bei `PartialTagNameMatch` = 1 zählt jeder über das Namensmuster gefundene Tag als eigener Tag. Bei AND sind damit alle gefundenen Tags erforderlich.\n- Ein Code-Kommentar weist darauf hin, dass die OR-Bedingung möglicherweise nicht korrekt funktioniert.\n- Die Meldung `Tag used in another operation` wird auch gesetzt, wenn derselbe Tag innerhalb einer Operation doppelt referenziert wird.\n- Beide möglichen ersten Ergebnismengen kommen als `SqlRowSet1` an. Zur Unterscheidung von Prüfliste und Auftragsliste auf die Spalte `Status` prüfen.\n- Ein negativer `RowCount` löst einen SQL-Fehler außerhalb der Fehlerbehandlung aus.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiOrderGetByTags"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 12Express15Marketplace7Blocked]]>\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Aufträge eines Datumsbereichs, gefiltert nach Auftrags-Tags mit AND-, OR- und NOT-Bedingungen aus einem XML-Filter.\n\nSucht Aufträge anhand der zugeordneten Tags. Der Filter wird als XML in `TagFilter` übergeben.\n\n**Auswertung und Prüfung**\n\n- Das XML wird unter `/TagFilter/AND`, `/TagFilter/OR` und `/TagFilter/NOT` gelesen. Jeder Block kann beliebig viele `TagId`- und `TagName`-Elemente enthalten. Tag-Namen werden getrimmt, leere Namen werden ignoriert.\n- Jeder Eintrag wird gegen die Tags vom Typ `2` (Auftrags-Tags) aufgelöst:\n - über `Id`, wenn `TagId` angegeben ist;\n - über den exakten `Name` bei `PartialTagNameMatch` = 0;\n - über `Name LIKE '%…%'` bei `PartialTagNameMatch` = 1.\n- Ein Teiltreffer kann einen Eintrag auf mehrere Tags auflösen.\n- Ein Eintrag ohne passenden Tag erhält den Status `ERROR`.\n- Ein Tag, der in der aufgelösten Liste mehrfach vorkommt, erhält ebenfalls `ERROR`. Das gilt operationsübergreifend und auch innerhalb derselben Operation, z. B. bei Angabe per Id und per Name.\n- Hat ein Eintrag einen Fehler, liefert der Aufruf die vollständige Prüfliste (eine Zeile je aufgelöstem Eintrag) und keine Aufträge.\n- Ist das XML nicht lesbar (oder eine `TagId` nicht numerisch), wird eine einzelne Fehlerzeile geliefert.\n\n**Auftragssuche** (nur bei erfolgreicher Prüfung)\n\n- `DateFrom` ist standardmäßig 6 Monate vor jetzt, `DateTo` jetzt und `RowCount` 1000.\n- Der Datumsbereich wird in einen Schlüsselbereich umgerechnet. Er beginnt beim kleinsten `OrderHeaderKey` mit `OrderDate >= DateFrom` und endet beim größten `OrderHeaderKey` mit `OrderDate < DateTo`. Alle Aufträge mit einem Schlüssel in diesem Bereich werden berücksichtigt.\n- **NOT**: Der Auftrag darf keinen der NOT-Tags tragen.\n- **OR**: Der Auftrag muss mindestens einen der OR-Tags tragen.\n- **AND**: Der Auftrag muss alle AND-Tags tragen.\n- Leere Blöcke werden nicht angewendet. Enthält der Filter keine Tags (oder ist `TagFilter` leer), werden alle Aufträge des Bereichs geliefert.\n- Das Ergebnis wird auf `TOP (RowCount)` begrenzt und nach `OrderHeaderKey` aufsteigend sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagFilter` | varchar(max) | Ja | XML-Filter mit `AND`-, `OR`- und `NOT`-Blöcken unter `TagFilter`, jeweils mit `TagId`- und/oder `TagName`-Elementen. Ein leerer Wert bedeutet keinen Tag-Filter. |\n| `PartialTagNameMatch` | bit | Nein | Steuert, wie `TagName`-Einträge abgeglichen werden. |\n| `StrictANDCondition` | bit | Nein | Obsolet, wird nicht verwendet. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Aufträge. NULL wird als 1000 behandelt. |\n| `DateFrom` | datetime | Nein | Beginn des Auftragsdatumsbereichs (inklusiv). NULL bedeutet 6 Monate vor jetzt. |\n| `DateTo` | datetime | Nein | Ende des Auftragsdatumsbereichs (exklusiv). NULL bedeutet jetzt. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, es können also nicht festgeschriebene Daten geliefert werden.\n- `StrictANDCondition` ist als obsolet markiert und wird nicht verwendet.\n- Der Datumsfilter wirkt über den Schlüsselbereich, nicht direkt über `OrderDate`. Aufträge mit einem Schlüssel im Bereich, deren Datum außerhalb liegt, werden trotzdem geliefert.\n- `DateTo` ist exklusiv.\n- Gibt es zu einer Datumsgrenze keinen Auftrag, ist der Schlüsselbereich leer und es werden keine Zeilen geliefert.\n- Die AND-Prüfung vergleicht die Anzahl passender Tag-Zuordnungen mit der Anzahl der AND-Tags. Doppelte Zuordnungen desselben Tags zu einem Auftrag können das Ergebnis verfälschen.\n- Bei `PartialTagNameMatch` = 1 zählt jeder über das Namensmuster gefundene Tag als eigener Tag. Bei AND sind damit alle gefundenen Tags erforderlich.\n- Ein Code-Kommentar weist darauf hin, dass die OR-Bedingung möglicherweise nicht korrekt funktioniert.\n- Die Meldung `Tag used in another operation` wird auch gesetzt, wenn derselbe Tag innerhalb einer Operation doppelt referenziert wird.\n- Beide möglichen ersten Ergebnismengen kommen als `SqlRowSet1` an. Zur Unterscheidung von Prüfliste und Auftragsliste auf die Spalte `Status` prüfen.\n- Ein negativer `RowCount` löst einen SQL-Fehler außerhalb der Fehlerbehandlung aus.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiOrderGetByTags"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n AND\n 12\n 12\n Priority\n ERROR\n Tag used in another operation\n \n \n NOT\n Blocked\n ERROR\n TagId or TagName not found\n \n"
}
]
},
{
"name": "pixiOrderSetGdprPollingExportFlag",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n 1\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder entfernt das DSGVO-Polling-Exportkennzeichen (`ExportGdprDataForPolling`) eines Auftrags, der über Auftragsnummer oder externe Auftragsnummer ermittelt wird.\n\nAktualisiert die Spalte `ExportGdprDataForPolling` eines Auftrags in `OrderHeader`.\n\n1. `OrderNr` = `0` und ein leerer `OrderNrExternal` gelten als nicht übergeben.\n2. Der Auftrag wird zuerst über `OrderNr` gesucht. Wird dabei kein Auftrag gefunden, erfolgt die Suche über `OrderNrExternal`. Sind beide angegeben und passt `OrderNr`, wird `OrderNrExternal` ignoriert.\n3. Prüfungen in dieser Reihenfolge:\n - weder `OrderNr` noch `OrderNrExternal` übergeben → Fehler,\n - kein Auftrag gefunden → Fehler,\n - `ExportGdprDataForPolling` ist NULL → Fehler.\n4. Hat der Auftrag bereits den gewünschten Wert, wird nichts geändert und eine Zeile mit `Warning` geliefert.\n5. Andernfalls wird das Kennzeichen aktualisiert, `UpdateEmp` auf `User` gesetzt (Standard `API user`) und eine Zeile mit `Success` geliefert.\n\nDer Aufruf liefert immer genau eine Zeile mit `Status` und `Message`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. `0` wird als NULL behandelt. Wird vor `OrderNrExternal` geprüft. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer (z. B. Shop-Bestellnummer). Leerer String wird als NULL behandelt. Wird verwendet, wenn über `OrderNr` kein Auftrag gefunden wird. |\n| `ExportGdprDataForPolling` | bit | Ja | Neuer Wert des DSGVO-Polling-Exportkennzeichens. |\n| `User` | varchar(50) | Nein | Benutzername, der in `UpdateEmp` geschrieben wird. NULL oder leer wird zu `API user`. |\n\n- Läuft in einer eigenen Transaktion bzw. in einem Savepoint, falls bereits eine Transaktion offen ist. Mit `XACT_ABORT ON` werden unerwartete Fehler zurückgerollt und über `log.InsertError` (nicht beigefügt) protokolliert; der Fehlertext wird in `Message` auf 80 Zeichen gekürzt.\n- Suche und Existenzprüfung lesen `OrderHeader` mit `NOLOCK`; das Update verwendet `ROWLOCK`.\n- Teilen sich mehrere Aufträge dieselbe `OrderNrExternal`, wird nur einer davon (die zuerst gelesene Zeile) aktualisiert.\n- `ExportGdprDataForPolling` hat keinen Standardwert; fehlt der Parameter, lehnt SQL Server den Aufruf ab, bevor die Prozedur läuft. Nur ein explizites NULL führt zur Statuszeile \"Mandatory parameter ExportGdprDataForPolling is missing\".\n- Prüfungsfehler werden als normale Zeile mit `Status` = `Error` geliefert, nicht als SQL-Fehler.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiOrderSetGdprPollingExportFlag"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n 1\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder entfernt das DSGVO-Polling-Exportkennzeichen (`ExportGdprDataForPolling`) eines Auftrags, der über Auftragsnummer oder externe Auftragsnummer ermittelt wird.\n\nAktualisiert die Spalte `ExportGdprDataForPolling` eines Auftrags in `OrderHeader`.\n\n1. `OrderNr` = `0` und ein leerer `OrderNrExternal` gelten als nicht übergeben.\n2. Der Auftrag wird zuerst über `OrderNr` gesucht. Wird dabei kein Auftrag gefunden, erfolgt die Suche über `OrderNrExternal`. Sind beide angegeben und passt `OrderNr`, wird `OrderNrExternal` ignoriert.\n3. Prüfungen in dieser Reihenfolge:\n - weder `OrderNr` noch `OrderNrExternal` übergeben → Fehler,\n - kein Auftrag gefunden → Fehler,\n - `ExportGdprDataForPolling` ist NULL → Fehler.\n4. Hat der Auftrag bereits den gewünschten Wert, wird nichts geändert und eine Zeile mit `Warning` geliefert.\n5. Andernfalls wird das Kennzeichen aktualisiert, `UpdateEmp` auf `User` gesetzt (Standard `API user`) und eine Zeile mit `Success` geliefert.\n\nDer Aufruf liefert immer genau eine Zeile mit `Status` und `Message`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. `0` wird als NULL behandelt. Wird vor `OrderNrExternal` geprüft. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer (z. B. Shop-Bestellnummer). Leerer String wird als NULL behandelt. Wird verwendet, wenn über `OrderNr` kein Auftrag gefunden wird. |\n| `ExportGdprDataForPolling` | bit | Ja | Neuer Wert des DSGVO-Polling-Exportkennzeichens. |\n| `User` | varchar(50) | Nein | Benutzername, der in `UpdateEmp` geschrieben wird. NULL oder leer wird zu `API user`. |\n\n- Läuft in einer eigenen Transaktion bzw. in einem Savepoint, falls bereits eine Transaktion offen ist. Mit `XACT_ABORT ON` werden unerwartete Fehler zurückgerollt und über `log.InsertError` (nicht beigefügt) protokolliert; der Fehlertext wird in `Message` auf 80 Zeichen gekürzt.\n- Suche und Existenzprüfung lesen `OrderHeader` mit `NOLOCK`; das Update verwendet `ROWLOCK`.\n- Teilen sich mehrere Aufträge dieselbe `OrderNrExternal`, wird nur einer davon (die zuerst gelesene Zeile) aktualisiert.\n- `ExportGdprDataForPolling` hat keinen Standardwert; fehlt der Parameter, lehnt SQL Server den Aufruf ab, bevor die Prozedur läuft. Nur ein explizites NULL führt zur Statuszeile \"Mandatory parameter ExportGdprDataForPolling is missing\".\n- Prüfungsfehler werden als normale Zeile mit `Status` = `Error` geliefert, nicht als SQL-Fehler.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiOrderSetGdprPollingExportFlag"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n GDPR Polling Export Flag successfully updated\n \n"
}
]
},
{
"name": "pixiOrderSetInfo",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Subshop-Name, Subshop-Logo und Referrer eines Auftrags, ermittelt über Pixi-Auftragsnummer oder externe Auftragsnummer.\n\nSetzt Informationsfelder im Kopf eines bestehenden Auftrags.\n\n1. **Auftragssuche:** Die Prozedur sucht in `Orderlines` nach Zeilen, bei denen `OrderNrExternal` gleich `@OrderNrExternal` **oder** `OrderNr` gleich `@OrderNr` ist. Die `OrderNr` einer passenden Zeile wird übernommen. Gibt es keinen Treffer, behält `@OrderNr` den übergebenen Wert.\n2. **Prüfung:** Existiert zur ermittelten `OrderNr` nicht genau ein Datensatz in `OrderHeader`, wird eine Fehlerzeile mit `ErrorNr` `404` geliefert. Es wird nichts geändert.\n3. **Aktualisierung:** Andernfalls wird der Datensatz in `OrderHeader` aktualisiert:\n - `SubShopName` wird auf `@SubShopName` gesetzt,\n - `SubShopLogo` wird auf `@SubShopLogo` gesetzt,\n - `Referrer` wird auf `@Referrer` gesetzt.\n\n Ein weggelassener Parameter oder ein Parameter mit dem Wert `NULL` lässt den bestehenden Wert unverändert. Damit sind Teilaktualisierungen möglich.\n4. Schlägt die Aktualisierung fehl, wird eine Fehlerzeile mit `ErrorNr` `500` geliefert.\n\nBei Erfolg liefert der Aufruf **keine Ergebnismenge**.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. Alternative zu `OrderNrExternal`. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer, z. B. aus dem Shop. Sie wird über `Orderlines` aufgelöst. Alternative zu `OrderNr`. |\n| `SubShopName` | varchar(50) | Nein | Neuer Subshop-Name. `NULL` behält den aktuellen Wert bei. |\n| `SubShopLogo` | varchar(50) | Nein | Neue Referenz auf das Subshop-Logo. `NULL` behält den aktuellen Wert bei. |\n| `Referrer` | varchar(50) | Nein | Neuer Referrer, also die Herkunft des Auftrags. `NULL` behält den aktuellen Wert bei. |\n\n- Die Suche über `@OrderNrExternal` erfolgt über `Orderlines`, nicht über `OrderHeader`. Ein Auftrag ohne Auftragspositionen ist über die externe Nummer nicht auffindbar und liefert `404`. Die Suche nur über `@OrderNr` funktioniert in diesem Fall trotzdem, weil der übergebene Wert erhalten bleibt.\n- Werden `@OrderNr` und `@OrderNrExternal` gemeinsam übergeben und verweisen sie auf verschiedene Aufträge, erkennt der Code diesen Konflikt **nicht**, obwohl der Fehlertext das nahelegt. Die Suche übernimmt dann die `OrderNr` einer der passenden Auftragspositionen; welche Zeile verwendet wird, ist nicht festgelegt. Dieser Auftrag wird aktualisiert. Es sollte nur einer der beiden Identifikatoren übergeben werden.\n- Die Suche liest mit `NOLOCK`.\n- Ein Leerstring ist nicht `NULL`. Er überschreibt das Feld mit einem leeren Wert. Nur `NULL` oder ein weggelassener Parameter erhält den bestehenden Wert.\n- Werte mit mehr als 50 Zeichen können die Aktualisierung scheitern lassen; dann wird die Zeile `500` geliefert. Ob das eintritt, hängt von den Spaltengrößen in `OrderHeader` ab, die im Code nicht sichtbar sind.\n- Die Fehlertexte sprechen von einer „Rechnung“ (invoice), der Aufruf arbeitet jedoch mit Aufträgen.\n- Es wird keine explizite Transaktion geöffnet. Die Aktualisierung ist eine einzelne Anweisung.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiOrderSetInfo"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Subshop-Name, Subshop-Logo und Referrer eines Auftrags, ermittelt über Pixi-Auftragsnummer oder externe Auftragsnummer.\n\nSetzt Informationsfelder im Kopf eines bestehenden Auftrags.\n\n1. **Auftragssuche:** Die Prozedur sucht in `Orderlines` nach Zeilen, bei denen `OrderNrExternal` gleich `@OrderNrExternal` **oder** `OrderNr` gleich `@OrderNr` ist. Die `OrderNr` einer passenden Zeile wird übernommen. Gibt es keinen Treffer, behält `@OrderNr` den übergebenen Wert.\n2. **Prüfung:** Existiert zur ermittelten `OrderNr` nicht genau ein Datensatz in `OrderHeader`, wird eine Fehlerzeile mit `ErrorNr` `404` geliefert. Es wird nichts geändert.\n3. **Aktualisierung:** Andernfalls wird der Datensatz in `OrderHeader` aktualisiert:\n - `SubShopName` wird auf `@SubShopName` gesetzt,\n - `SubShopLogo` wird auf `@SubShopLogo` gesetzt,\n - `Referrer` wird auf `@Referrer` gesetzt.\n\n Ein weggelassener Parameter oder ein Parameter mit dem Wert `NULL` lässt den bestehenden Wert unverändert. Damit sind Teilaktualisierungen möglich.\n4. Schlägt die Aktualisierung fehl, wird eine Fehlerzeile mit `ErrorNr` `500` geliefert.\n\nBei Erfolg liefert der Aufruf **keine Ergebnismenge**.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. Alternative zu `OrderNrExternal`. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer, z. B. aus dem Shop. Sie wird über `Orderlines` aufgelöst. Alternative zu `OrderNr`. |\n| `SubShopName` | varchar(50) | Nein | Neuer Subshop-Name. `NULL` behält den aktuellen Wert bei. |\n| `SubShopLogo` | varchar(50) | Nein | Neue Referenz auf das Subshop-Logo. `NULL` behält den aktuellen Wert bei. |\n| `Referrer` | varchar(50) | Nein | Neuer Referrer, also die Herkunft des Auftrags. `NULL` behält den aktuellen Wert bei. |\n\n- Die Suche über `@OrderNrExternal` erfolgt über `Orderlines`, nicht über `OrderHeader`. Ein Auftrag ohne Auftragspositionen ist über die externe Nummer nicht auffindbar und liefert `404`. Die Suche nur über `@OrderNr` funktioniert in diesem Fall trotzdem, weil der übergebene Wert erhalten bleibt.\n- Werden `@OrderNr` und `@OrderNrExternal` gemeinsam übergeben und verweisen sie auf verschiedene Aufträge, erkennt der Code diesen Konflikt **nicht**, obwohl der Fehlertext das nahelegt. Die Suche übernimmt dann die `OrderNr` einer der passenden Auftragspositionen; welche Zeile verwendet wird, ist nicht festgelegt. Dieser Auftrag wird aktualisiert. Es sollte nur einer der beiden Identifikatoren übergeben werden.\n- Die Suche liest mit `NOLOCK`.\n- Ein Leerstring ist nicht `NULL`. Er überschreibt das Feld mit einem leeren Wert. Nur `NULL` oder ein weggelassener Parameter erhält den bestehenden Wert.\n- Werte mit mehr als 50 Zeichen können die Aktualisierung scheitern lassen; dann wird die Zeile `500` geliefert. Ob das eintritt, hängt von den Spaltengrößen in `OrderHeader` ab, die im Code nicht sichtbar sind.\n- Die Fehlertexte sprechen von einer „Rechnung“ (invoice), der Aufruf arbeitet jedoch mit Aufträgen.\n- Es wird keine explizite Transaktion geöffnet. Die Aktualisierung ist eine einzelne Anweisung.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiOrderSetInfo"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 404\n Invoice does not exist or two different invoice parameters were specified.\n \n"
}
]
},
{
"name": "pixiPicklistDelete",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht eine Pickliste samt Positionen, Pickfortschritt, Picklistenkisten und Transportbehälter-Zuordnungen.\n\nLöscht die über `PicklistNumber` (`PLHkey` in `PLHeader`) angegebene Pickliste.\n\nAblauf:\n1. Wird `PicklistNumber` nicht übergeben, wird eine Fehlerzeile geliefert.\n2. Existiert keine Pickliste mit dieser Nummer, wird eine Fehlerzeile geliefert.\n3. Die Anzahl der Einträge in `PL_ItemPickingProgress` zur Pickliste wird ermittelt. Sind Einträge vorhanden und ist `ForceDelete = 0`, bricht der Aufruf mit einer Fehlerzeile ab, da Artikel der Pickliste gerade gepickt werden.\n4. Andernfalls wird die interne Prozedur `Pixi_DeletePickList` ausgeführt. Sie löscht nacheinander die Pickfortschritt-Einträge, die Picklistenkisten (`PicklistBox`), die Transportbehälter-Zuordnungen mit Belegtyp 1 (`TransportBinMatch`), die Picklistenpositionen (`PLitem`) und zuletzt den Picklistenkopf (`PLHeader`).\n5. Es wird eine Zeile mit `Status = Success` und einer Bestätigungsmeldung geliefert.\n\nIn jedem Fall wird genau eine Zeile mit `Status` und `Message` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PicklistNumber` | int | Nein | Nummer der zu löschenden Pickliste (`PLHkey`). Technisch optional, der Aufruf liefert jedoch einen Fehler, wenn sie fehlt. |\n| `ForceDelete` | bit | Nein | Löscht die Pickliste auch dann, wenn gerade Artikel gepickt werden. |\n\n- Das Löschen erfolgt in `Pixi_DeletePickList` innerhalb einer Transaktion (bzw. eines Savepoints, falls bereits eine Transaktion offen ist). Bei einem Fehler wird zurückgerollt und über `log.InsertError` protokolliert (nicht beigefügt).\n- Stolperfalle: `Pixi_DeletePickList` fängt eigene Fehler ab und gibt sie nicht weiter. Ein Fehler beim Löschen ist für diesen Aufruf daher meist nicht sichtbar, und die `Success`-Zeile kann geliefert werden, obwohl die Pickliste nach dem Rollback noch existiert. Im Zweifel das Löschen prüfen. Die Meldung `Unexpected error. Picklist was not deleted.` erscheint nur bei Fehlern, die außerhalb der inneren Prozedur auftreten.\n- Die Prüfungen auf Existenz und Pickfortschritt verwenden `NOLOCK` und können daher nicht festgeschriebene Daten lesen.\n- `ForceDelete = 1` löscht auch Picklisten, die gerade gepickt werden; der Pickfortschritt geht dabei verloren.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiPicklistDelete"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht eine Pickliste samt Positionen, Pickfortschritt, Picklistenkisten und Transportbehälter-Zuordnungen.\n\nLöscht die über `PicklistNumber` (`PLHkey` in `PLHeader`) angegebene Pickliste.\n\nAblauf:\n1. Wird `PicklistNumber` nicht übergeben, wird eine Fehlerzeile geliefert.\n2. Existiert keine Pickliste mit dieser Nummer, wird eine Fehlerzeile geliefert.\n3. Die Anzahl der Einträge in `PL_ItemPickingProgress` zur Pickliste wird ermittelt. Sind Einträge vorhanden und ist `ForceDelete = 0`, bricht der Aufruf mit einer Fehlerzeile ab, da Artikel der Pickliste gerade gepickt werden.\n4. Andernfalls wird die interne Prozedur `Pixi_DeletePickList` ausgeführt. Sie löscht nacheinander die Pickfortschritt-Einträge, die Picklistenkisten (`PicklistBox`), die Transportbehälter-Zuordnungen mit Belegtyp 1 (`TransportBinMatch`), die Picklistenpositionen (`PLitem`) und zuletzt den Picklistenkopf (`PLHeader`).\n5. Es wird eine Zeile mit `Status = Success` und einer Bestätigungsmeldung geliefert.\n\nIn jedem Fall wird genau eine Zeile mit `Status` und `Message` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PicklistNumber` | int | Nein | Nummer der zu löschenden Pickliste (`PLHkey`). Technisch optional, der Aufruf liefert jedoch einen Fehler, wenn sie fehlt. |\n| `ForceDelete` | bit | Nein | Löscht die Pickliste auch dann, wenn gerade Artikel gepickt werden. |\n\n- Das Löschen erfolgt in `Pixi_DeletePickList` innerhalb einer Transaktion (bzw. eines Savepoints, falls bereits eine Transaktion offen ist). Bei einem Fehler wird zurückgerollt und über `log.InsertError` protokolliert (nicht beigefügt).\n- Stolperfalle: `Pixi_DeletePickList` fängt eigene Fehler ab und gibt sie nicht weiter. Ein Fehler beim Löschen ist für diesen Aufruf daher meist nicht sichtbar, und die `Success`-Zeile kann geliefert werden, obwohl die Pickliste nach dem Rollback noch existiert. Im Zweifel das Löschen prüfen. Die Meldung `Unexpected error. Picklist was not deleted.` erscheint nur bei Fehlern, die außerhalb der inneren Prozedur auftreten.\n- Die Prüfungen auf Existenz und Pickfortschritt verwenden `NOLOCK` und können daher nicht festgeschriebene Daten lesen.\n- `ForceDelete = 1` löscht auch Picklisten, die gerade gepickt werden; der Pickfortschritt geht dabei verloren.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiPicklistDelete"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n Picklist with picklist number \"10452\" was deleted.\n \n"
}
]
},
{
"name": "pixiReadOrderHeader",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Auftragsköpfe nach Schlüssel oder Auftragsnummer oder nach Anlage-/Änderungszeiträumen, mit schlüsselbasiertem Paging.\n\nLiest Datensätze aus `OrderHeader`. Die Parameter wählen einen von mehreren **sich gegenseitig ausschließenden Modi**, geprüft in dieser Reihenfolge:\n\n1. **Anlage- oder Änderungszeitraum**: `CreateAndUpdateDateFrom` und/oder `CreateAndUpdateDateTo` ist gesetzt. Liefert Aufträge, deren `CreateDate` **oder** `UpdateDate` `>=` From ist und deren `CreateDate` **oder** `UpdateDate` `<` To ist.\n2. **Anlagezeitraum**: `CreateDateFrom` und/oder `CreateDateTo` ist gesetzt. Filtert `CreateDate >= From` und `CreateDate < To`.\n3. **Änderungszeitraum**: `UpdateDateFrom` und/oder `UpdateDateTo` ist gesetzt. Filtert `UpdateDate >= From` und `UpdateDate < To`.\n4. **Paging ohne Datumsfilter**: `RowCount` ist gesetzt und kein Datumsparameter ist gesetzt. Liefert die nächsten Aufträge nach `OrderHeaderKey`.\n5. **Einzelner Auftrag**: sonst. Liefert höchstens einen Auftrag, dessen `OrderHeaderKey` dem übergebenen Schlüssel **oder** dessen `OrderNr` der übergebenen Auftragsnummer entspricht.\n\nNur der erste zutreffende Modus wird verwendet. Parameter späterer Modi werden ignoriert. So hat `OrderNr` beispielsweise keine Wirkung, wenn ein Datumsparameter oder `RowCount` gesetzt ist.\n\n**Paging**: In den Modi 1–4 ist `OrderHeaderKey` eine *exklusive* Untergrenze. Es werden nur Aufträge mit einem größeren Schlüssel als dem übergebenen Wert geliefert. Wird `OrderHeaderKey` nicht übergeben, gilt der Wert `0`. Für die nächste Seite wird der zuletzt erhaltene `OrderHeaderKey` übergeben.\n\n**Zeilenlimit**: Die Ausgabe ist auf `RowCount` Zeilen begrenzt. Ist `RowCount` `NULL` oder `0`, gilt ein Limit von 1000 Zeilen. Werte über 100000 werden auf 100000 begrenzt. Die Zeilen sind immer aufsteigend nach `OrderHeaderKey` sortiert.\n\n**Berechnete Spalten**:\n- `ShipDate` ist das späteste `ShipDate` der `Orderlines` des Auftrags.\n- `ShopNote` wird in einen CDATA-Abschnitt eingeschlossen, wenn der Text mit `<` beginnt.\n- `ExchRateId` wird nur gefüllt, wenn die Einstellung `MultiCurrencyEnabled` den Wert `1` hat.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderHeaderKey` | int | Nein | In Datums- und Paging-Modi: exklusive Untergrenze (Paging-Cursor); `NULL` gilt als `0`. Im Einzelauftragsmodus: exakter Schlüssel des gesuchten Auftrags. |\n| `OrderNr` | int | Nein | Auftragsnummer. Nur im Einzelauftragsmodus verwendet, also wenn kein Datumsparameter und kein `RowCount` gesetzt ist. |\n| `CreateDateFrom` | datetime | Nein | Inklusive Untergrenze für `CreateDate` (Anlagezeitraum-Modus). |\n| `CreateDateTo` | datetime | Nein | Exklusive Obergrenze für `CreateDate` (Anlagezeitraum-Modus). |\n| `UpdateDateFrom` | datetime | Nein | Inklusive Untergrenze für `UpdateDate`. Nur verwendet, wenn kein Anlage-oder-Änderungs- bzw. Anlagezeitraum-Parameter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Exklusive Obergrenze für `UpdateDate` (Änderungszeitraum-Modus). |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze: Ein Auftrag passt, wenn `CreateDate` oder `UpdateDate` auf oder nach diesem Wert liegt. Hat Vorrang vor allen anderen Filtern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze: Ein Auftrag passt, wenn `CreateDate` oder `UpdateDate` vor diesem Wert liegt. |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen (begrenzt auf 100000; `NULL` oder `0` bedeutet 1000). Ohne Datumsparameter aktiviert ein gesetzter Wert den Paging-Modus ab `OrderHeaderKey`. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- **Ohne Filter**: Ein Aufruf ohne Parameter liefert keine Zeilen, sofern kein Auftrag mit Schlüssel `0` existiert. Der Aufruf fällt in den Einzelauftragsmodus mit Schlüssel `0`.\n- **Einzelauftragsmodus**: Werden `OrderHeaderKey` und `OrderNr` gemeinsam übergeben, wirkt der Filter als ODER. Es wird ein beliebiger passender Auftrag geliefert, da vor `TOP 1` keine Sortierung erfolgt.\n- **Anlage-oder-Änderungsmodus**: Die ODER-Logik ist großzügig. Die To-Grenze schließt einen Auftrag nur aus, wenn sowohl `CreateDate` als auch `UpdateDate` auf oder nach To liegen. Dieser Modus sammelt alle passenden Schlüssel, bevor das Zeilenlimit greift; bei großen Zeiträumen kann das langsam sein.\n- **`RowCount = 0`**: In den Modi 2–4 führt `RowCount = 0` zu null Kandidaten, es werden also keine Zeilen geliefert. Für den Standardwert 1000 sollte stattdessen `NULL` übergeben werden. Negative Werte führen zu einem SQL-Fehler.\n- Das Zeilenlimit wird per `SET ROWCOUNT` umgesetzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadOrderHeader"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Auftragsköpfe nach Schlüssel oder Auftragsnummer oder nach Anlage-/Änderungszeiträumen, mit schlüsselbasiertem Paging.\n\nLiest Datensätze aus `OrderHeader`. Die Parameter wählen einen von mehreren **sich gegenseitig ausschließenden Modi**, geprüft in dieser Reihenfolge:\n\n1. **Anlage- oder Änderungszeitraum**: `CreateAndUpdateDateFrom` und/oder `CreateAndUpdateDateTo` ist gesetzt. Liefert Aufträge, deren `CreateDate` **oder** `UpdateDate` `>=` From ist und deren `CreateDate` **oder** `UpdateDate` `<` To ist.\n2. **Anlagezeitraum**: `CreateDateFrom` und/oder `CreateDateTo` ist gesetzt. Filtert `CreateDate >= From` und `CreateDate < To`.\n3. **Änderungszeitraum**: `UpdateDateFrom` und/oder `UpdateDateTo` ist gesetzt. Filtert `UpdateDate >= From` und `UpdateDate < To`.\n4. **Paging ohne Datumsfilter**: `RowCount` ist gesetzt und kein Datumsparameter ist gesetzt. Liefert die nächsten Aufträge nach `OrderHeaderKey`.\n5. **Einzelner Auftrag**: sonst. Liefert höchstens einen Auftrag, dessen `OrderHeaderKey` dem übergebenen Schlüssel **oder** dessen `OrderNr` der übergebenen Auftragsnummer entspricht.\n\nNur der erste zutreffende Modus wird verwendet. Parameter späterer Modi werden ignoriert. So hat `OrderNr` beispielsweise keine Wirkung, wenn ein Datumsparameter oder `RowCount` gesetzt ist.\n\n**Paging**: In den Modi 1–4 ist `OrderHeaderKey` eine *exklusive* Untergrenze. Es werden nur Aufträge mit einem größeren Schlüssel als dem übergebenen Wert geliefert. Wird `OrderHeaderKey` nicht übergeben, gilt der Wert `0`. Für die nächste Seite wird der zuletzt erhaltene `OrderHeaderKey` übergeben.\n\n**Zeilenlimit**: Die Ausgabe ist auf `RowCount` Zeilen begrenzt. Ist `RowCount` `NULL` oder `0`, gilt ein Limit von 1000 Zeilen. Werte über 100000 werden auf 100000 begrenzt. Die Zeilen sind immer aufsteigend nach `OrderHeaderKey` sortiert.\n\n**Berechnete Spalten**:\n- `ShipDate` ist das späteste `ShipDate` der `Orderlines` des Auftrags.\n- `ShopNote` wird in einen CDATA-Abschnitt eingeschlossen, wenn der Text mit `<` beginnt.\n- `ExchRateId` wird nur gefüllt, wenn die Einstellung `MultiCurrencyEnabled` den Wert `1` hat.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderHeaderKey` | int | Nein | In Datums- und Paging-Modi: exklusive Untergrenze (Paging-Cursor); `NULL` gilt als `0`. Im Einzelauftragsmodus: exakter Schlüssel des gesuchten Auftrags. |\n| `OrderNr` | int | Nein | Auftragsnummer. Nur im Einzelauftragsmodus verwendet, also wenn kein Datumsparameter und kein `RowCount` gesetzt ist. |\n| `CreateDateFrom` | datetime | Nein | Inklusive Untergrenze für `CreateDate` (Anlagezeitraum-Modus). |\n| `CreateDateTo` | datetime | Nein | Exklusive Obergrenze für `CreateDate` (Anlagezeitraum-Modus). |\n| `UpdateDateFrom` | datetime | Nein | Inklusive Untergrenze für `UpdateDate`. Nur verwendet, wenn kein Anlage-oder-Änderungs- bzw. Anlagezeitraum-Parameter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Exklusive Obergrenze für `UpdateDate` (Änderungszeitraum-Modus). |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze: Ein Auftrag passt, wenn `CreateDate` oder `UpdateDate` auf oder nach diesem Wert liegt. Hat Vorrang vor allen anderen Filtern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze: Ein Auftrag passt, wenn `CreateDate` oder `UpdateDate` vor diesem Wert liegt. |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen (begrenzt auf 100000; `NULL` oder `0` bedeutet 1000). Ohne Datumsparameter aktiviert ein gesetzter Wert den Paging-Modus ab `OrderHeaderKey`. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- **Ohne Filter**: Ein Aufruf ohne Parameter liefert keine Zeilen, sofern kein Auftrag mit Schlüssel `0` existiert. Der Aufruf fällt in den Einzelauftragsmodus mit Schlüssel `0`.\n- **Einzelauftragsmodus**: Werden `OrderHeaderKey` und `OrderNr` gemeinsam übergeben, wirkt der Filter als ODER. Es wird ein beliebiger passender Auftrag geliefert, da vor `TOP 1` keine Sortierung erfolgt.\n- **Anlage-oder-Änderungsmodus**: Die ODER-Logik ist großzügig. Die To-Grenze schließt einen Auftrag nur aus, wenn sowohl `CreateDate` als auch `UpdateDate` auf oder nach To liegen. Dieser Modus sammelt alle passenden Schlüssel, bevor das Zeilenlimit greift; bei großen Zeiträumen kann das langsam sein.\n- **`RowCount = 0`**: In den Modi 2–4 führt `RowCount = 0` zu null Kandidaten, es werden also keine Zeilen geliefert. Für den Standardwert 1000 sollte stattdessen `NULL` übergeben werden. Negative Werte führen zu einem SQL-Fehler.\n- Das Zeilenlimit wird per `SET ROWCOUNT` umgesetzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadOrderHeader"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 125431\n 200346\n DHL\n 0.00\n API\n 2024-05-01T09:15:22\n 2024-05-01T10:02:11\n 48211\n 90122\n 90123\n 2024-05-02T14:30:00\n 4.90\n SHOP-100045\n AUF\n 59.80\n 64.70\n 1\n \n"
}
]
},
{
"name": "pixiReleaseOrder",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100012345\n ABC\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Gibt einen angehaltenen Auftrag anhand externer Auftragsnummer und Shop frei, indem dessen Auftragspositionen von Status HAL auf ANG gesetzt werden.\n\nGibt einen angehaltenen Auftrag (Status `HAL`) frei, damit er wieder bearbeitet werden kann.\n\n1. Die interne Auftragsnummer (`OrderNr`) wird in `Orderlines` über `OrderNrExternal` = `@OrderNrExternal` ermittelt, verknüpft mit `Customers` über `CustomerOf` = `@ShopId`.\n2. Die interne Prozedur `GOS_ReleaseOnHold` wird mit dieser Auftragsnummer und dem Benutzer `API` aufgerufen. Sie setzt alle Auftragspositionen des Auftrags mit Status `HAL` auf `ANG`, setzt `UpdateDate` auf das aktuelle Datum und `UpdateEmp` auf `API (payments)`.\n3. Abschließend wird eine Statuszeile geliefert: die Anzahl der Auftragspositionen mit der angegebenen externen Auftragsnummer und dem Shop, die nun Status `ANG` haben. `ReturnCode` ist `OK`, wenn diese Anzahl größer 0 ist, sonst `ERROR`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNrExternal` | varchar(50) | Ja | Externe Auftragsnummer (z. B. die Bestellnummer des Shops) des freizugebenden Auftrags. |\n| `ShopId` | char(3) | Ja | Shop-ID; wird mit `CustomerOf` des Kunden des Auftrags verglichen. |\n\n- `AffectedRows` ist nicht die Anzahl der tatsächlich freigegebenen Positionen: Gezählt werden **alle** Positionen mit Status `ANG`, auch solche, die bereits vor dem Aufruf `ANG` hatten. Ein Aufruf für einen nicht angehaltenen Auftrag mit `ANG`-Positionen liefert daher ebenfalls `OK`.\n- Wird kein Auftrag gefunden, wird nichts geändert und das Ergebnis ist `ERROR` mit `AffectedRows` = 0. Dasselbe gilt, wenn der Auftrag existiert, danach aber keine Position im Status `ANG` ist (z. B. Positionen in anderen Status).\n- Teilen sich mehrere Aufträge innerhalb des Shops dieselbe externe Auftragsnummer, wird nur einer davon (die zuletzt gelesene Zeile der Suche) freigegeben, während die Zählung Positionen aller passenden Aufträge umfasst.\n- Suche und abschließende Zählung verwenden `NOLOCK`; das Ergebnis kann daher nicht festgeschriebene Daten widerspiegeln.\n- Die Aktualisierung läuft in einer Transaktion (bzw. einem Savepoint, falls bereits eine Transaktion offen ist). Bei einem Fehler wird zurückgerollt, die Fehlerdetails werden in `LogTable` protokolliert und der Fehler erneut ausgelöst.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReleaseOrder"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100012345\n ABC\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Gibt einen angehaltenen Auftrag anhand externer Auftragsnummer und Shop frei, indem dessen Auftragspositionen von Status HAL auf ANG gesetzt werden.\n\nGibt einen angehaltenen Auftrag (Status `HAL`) frei, damit er wieder bearbeitet werden kann.\n\n1. Die interne Auftragsnummer (`OrderNr`) wird in `Orderlines` über `OrderNrExternal` = `@OrderNrExternal` ermittelt, verknüpft mit `Customers` über `CustomerOf` = `@ShopId`.\n2. Die interne Prozedur `GOS_ReleaseOnHold` wird mit dieser Auftragsnummer und dem Benutzer `API` aufgerufen. Sie setzt alle Auftragspositionen des Auftrags mit Status `HAL` auf `ANG`, setzt `UpdateDate` auf das aktuelle Datum und `UpdateEmp` auf `API (payments)`.\n3. Abschließend wird eine Statuszeile geliefert: die Anzahl der Auftragspositionen mit der angegebenen externen Auftragsnummer und dem Shop, die nun Status `ANG` haben. `ReturnCode` ist `OK`, wenn diese Anzahl größer 0 ist, sonst `ERROR`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNrExternal` | varchar(50) | Ja | Externe Auftragsnummer (z. B. die Bestellnummer des Shops) des freizugebenden Auftrags. |\n| `ShopId` | char(3) | Ja | Shop-ID; wird mit `CustomerOf` des Kunden des Auftrags verglichen. |\n\n- `AffectedRows` ist nicht die Anzahl der tatsächlich freigegebenen Positionen: Gezählt werden **alle** Positionen mit Status `ANG`, auch solche, die bereits vor dem Aufruf `ANG` hatten. Ein Aufruf für einen nicht angehaltenen Auftrag mit `ANG`-Positionen liefert daher ebenfalls `OK`.\n- Wird kein Auftrag gefunden, wird nichts geändert und das Ergebnis ist `ERROR` mit `AffectedRows` = 0. Dasselbe gilt, wenn der Auftrag existiert, danach aber keine Position im Status `ANG` ist (z. B. Positionen in anderen Status).\n- Teilen sich mehrere Aufträge innerhalb des Shops dieselbe externe Auftragsnummer, wird nur einer davon (die zuletzt gelesene Zeile der Suche) freigegeben, während die Zählung Positionen aller passenden Aufträge umfasst.\n- Suche und abschließende Zählung verwenden `NOLOCK`; das Ergebnis kann daher nicht festgeschriebene Daten widerspiegeln.\n- Die Aktualisierung läuft in einer Transaktion (bzw. einem Savepoint, falls bereits eine Transaktion offen ist). Bei einem Fehler wird zurückgerollt, die Fehlerdetails werden in `LogTable` protokolliert und der Fehler erneut ausgelöst.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReleaseOrder"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n 3\n \n"
}
]
},
{
"name": "pixiReportGetShippableOrdersV2",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert offene Aufträge bzw. Auftragspositionen, die mit dem aktuellen Bestand versendet werden können, als Details oder Summen, optional je Lager.\n\nErmittelt, welche offenen Aufträge mit dem aktuellen Bestand versendet werden können, und liefert sie als Positionsdetails oder als Summen.\n\n**1. Kandidaten-Aufträge**\n- Berücksichtigt werden nur Auftragspositionen im Status `ANG` oder `EIN` (soweit in `OrderStates` vorhanden) mit `ItemRef` und `Qty > 0`. Ersatzpositionen ohne Artikel entfallen.\n- `ShopId`: nur Aufträge, deren Kunde `CustomerOf = @ShopId` hat. Ein Leerstring (Standard) bedeutet alle Shops.\n- Aufträge mit gesperrter Liefer- oder Rechnungsadresse (`ASlocked = 'Y'`) werden ausgeschlossen.\n- Aufträge mit gesperrtem Kopf (`OhSLocked = 'Y'`) werden ausgeschlossen.\n- Versanddatum: standardmäßig nur Aufträge ohne Versanddatum oder mit Versanddatum vor morgen. Mit `IncludeOrdersWithAnyShipDate = 1` wird das Versanddatum ignoriert.\n\n**2. Bestandsprüfung**\nFür jede Kandidatenposition entscheidet die interne Prozedur `pixi_CalculateStockForOrderLines`, ob sie versandfähig ist. Verwendet wird der Bestand der Lager mit `SpecialStock = 0`. Frühere Reservierungen und ältere nicht reservierte Auftragspositionen (FIFO nach Reservierungsdatum bzw. Positionsschlüssel) werden vom Bestand abgezogen. Positionen im Status `EIN` gelten immer als versandfähig. `UseFIFObyLocationV2` legt fest, ob je Lager der Position (`1`) oder über alle Lager summiert (`0`) geprüft wird. `NULL` bedeutet, dass der Wert der Einstellung `UseFIFObyLocation` gilt.\n\n**3. Filter Teillieferung**\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 0`: alle Positionen von Aufträgen, bei denen jede Kandidatenposition versandfähig ist (nur vollständige Aufträge).\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 1`: alle versandfähigen Positionen, unabhängig davon, ob der Auftrag vollständig ist.\n- `OnlyPartDelivery = 1`: nur versandfähige Positionen von Aufträgen, die auch mindestens eine nicht versandfähige Position enthalten. `IncludePartDelivery` wird ignoriert.\n\n**4. Währung**\nIst die Einstellung `MultiCurrencyEnabled` gleich `1`, werden `Price` und `ShipCost` durch den Kurs der Datenbankwährungs-Kursquelle für Währung und Kursdatum des Auftrags geteilt. Das Ergebnis liegt in Datenbankwährung vor, `dbCurrency` enthält deren Code. Wird kein passender Kurs gefunden, bleiben die Beträge unverändert. Ohne Mehrwährung werden die Beträge wie gespeichert geliefert und `dbCurrency` ist `NULL`.\n\n**5. Ausgabe** (genau eine Ergebnismenge, abhängig von `ViewDetails` und `PerLocation`)\n- `ViewDetails = 1`, `PerLocation = 0`: eine Zeile je Position, sortiert nach `OrderNr`, `OrderlineRef`.\n- `ViewDetails = 0`, `PerLocation = 0`: eine Summenzeile mit Anzahl Aufträge, Auftragswert (`Price * Qty`), Versandkosten und Picks.\n- `ViewDetails = 1`, `PerLocation = 1`: wie die Details, zusätzlich mit Spalte `LocationId`.\n- `ViewDetails = 0`, `PerLocation = 1`: eine Summenzeile je Lager.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ViewDetails` | bit | Nein | `1` liefert eine Zeile je Auftragsposition, `0` (oder `NULL`) liefert Summen. |\n| `IncludePartDelivery` | bit | Nein | Bei `OnlyPartDelivery = 0`: `1` liefert alle versandfähigen Positionen, auch von nur teilweise versendbaren Aufträgen. `0` liefert nur vollständige Aufträge. Wird bei `OnlyPartDelivery = 1` ignoriert. |\n| `OnlyPartDelivery` | bit | Nein | `1` liefert nur die versandfähigen Positionen von Aufträgen, die auch nicht versandfähige Positionen enthalten (Teillieferungen). |\n| `ShopId` | varchar(3) | Nein | Shop-Kürzel. Es werden nur Aufträge von Kunden mit `CustomerOf` gleich diesem Wert geliefert. Leer bedeutet alle Shops. |\n| `IncludeOrdersWithAnyShipDate` | bit | Nein | `0`: nur Aufträge ohne Versanddatum oder mit Versanddatum bis heute. `1`: das Versanddatum wird ignoriert. |\n| `PerLocation` | bit | Nein | `1` ergänzt `LocationId` in den Details bzw. gruppiert die Summen je Lager. Im Code als \"alte Variante\" bezeichnet. |\n| `UseFIFObyLocationV2` | bit | Nein | Steuert die Bestandsprüfung: `1` prüft den Bestand des Lagers der Position, `0` den Gesamtbestand aller Lager ohne Sonderbestand. `NULL` verwendet die Einstellung `UseFIFObyLocation`. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`. Das Ergebnis kann nicht festgeschriebene Daten enthalten und ist nur eine Momentaufnahme; es wird nichts reserviert oder geändert.\n- `NULL` für `ViewDetails`, `IncludePartDelivery`, `OnlyPartDelivery` und `PerLocation` wird als `0` behandelt. Eine leere `ShopId` gilt als \"alle Shops\". `NULL` für `IncludeOrdersWithAnyShipDate` wirkt wie `0`.\n- **Einstellungen mit Einfluss auf das Verhalten:**\n - `MultiCurrencyEnabled`: Währungsumrechnung und Spalte `dbCurrency`.\n - `HomeCurrency` und `DatabaseCurrencyExchRateSourceId`: verwendete Datenbankwährung und Kursquelle.\n - `UseFIFObyLocation`: gilt, wenn `UseFIFObyLocationV2` `NULL` ist.\n- Ob ein Auftrag \"vollständig\" ist, wird nur anhand seiner `ANG`/`EIN`-Positionen mit Artikel und positiver Menge beurteilt. Positionen in anderen Status werden ignoriert.\n- `ShipCost` sind die Versandkosten aus dem Auftragskopf und stehen auf jeder Position. In den Summen werden sie einmal je Auftrag addiert. In den Summen je Lager werden sie einmal je Auftrag und Lager addiert; ein Auftrag über mehrere Lager zählt seine Versandkosten daher in jedem dieser Lager.\n- Bei der Gesamtsumme (`ViewDetails = 0`, `PerLocation = 0`) wird immer eine Zeile geliefert. Ist nichts versandfähig, gilt `Orders` = 0 und `ShipCost` = 0, `OrderTotal`/`Picks` sind `NULL`. Die Summen je Lager liefern in diesem Fall keine Zeilen.\n- Ein Kommentar im Code bezeichnet `PerLocation` als \"alte Variante\".\n- Die interne Bestandsprozedur ruft `log.EventDurationInsert` auf (Definition nicht beigefügt), das vermutlich einen Laufzeit-Logeintrag schreibt.\n- Der Aufruf durchsucht alle offenen `ANG`/`EIN`-Positionen samt Reservierungen und kann bei großen Datenbanken aufwendig sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportGetShippableOrdersV2"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert offene Aufträge bzw. Auftragspositionen, die mit dem aktuellen Bestand versendet werden können, als Details oder Summen, optional je Lager.\n\nErmittelt, welche offenen Aufträge mit dem aktuellen Bestand versendet werden können, und liefert sie als Positionsdetails oder als Summen.\n\n**1. Kandidaten-Aufträge**\n- Berücksichtigt werden nur Auftragspositionen im Status `ANG` oder `EIN` (soweit in `OrderStates` vorhanden) mit `ItemRef` und `Qty > 0`. Ersatzpositionen ohne Artikel entfallen.\n- `ShopId`: nur Aufträge, deren Kunde `CustomerOf = @ShopId` hat. Ein Leerstring (Standard) bedeutet alle Shops.\n- Aufträge mit gesperrter Liefer- oder Rechnungsadresse (`ASlocked = 'Y'`) werden ausgeschlossen.\n- Aufträge mit gesperrtem Kopf (`OhSLocked = 'Y'`) werden ausgeschlossen.\n- Versanddatum: standardmäßig nur Aufträge ohne Versanddatum oder mit Versanddatum vor morgen. Mit `IncludeOrdersWithAnyShipDate = 1` wird das Versanddatum ignoriert.\n\n**2. Bestandsprüfung**\nFür jede Kandidatenposition entscheidet die interne Prozedur `pixi_CalculateStockForOrderLines`, ob sie versandfähig ist. Verwendet wird der Bestand der Lager mit `SpecialStock = 0`. Frühere Reservierungen und ältere nicht reservierte Auftragspositionen (FIFO nach Reservierungsdatum bzw. Positionsschlüssel) werden vom Bestand abgezogen. Positionen im Status `EIN` gelten immer als versandfähig. `UseFIFObyLocationV2` legt fest, ob je Lager der Position (`1`) oder über alle Lager summiert (`0`) geprüft wird. `NULL` bedeutet, dass der Wert der Einstellung `UseFIFObyLocation` gilt.\n\n**3. Filter Teillieferung**\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 0`: alle Positionen von Aufträgen, bei denen jede Kandidatenposition versandfähig ist (nur vollständige Aufträge).\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 1`: alle versandfähigen Positionen, unabhängig davon, ob der Auftrag vollständig ist.\n- `OnlyPartDelivery = 1`: nur versandfähige Positionen von Aufträgen, die auch mindestens eine nicht versandfähige Position enthalten. `IncludePartDelivery` wird ignoriert.\n\n**4. Währung**\nIst die Einstellung `MultiCurrencyEnabled` gleich `1`, werden `Price` und `ShipCost` durch den Kurs der Datenbankwährungs-Kursquelle für Währung und Kursdatum des Auftrags geteilt. Das Ergebnis liegt in Datenbankwährung vor, `dbCurrency` enthält deren Code. Wird kein passender Kurs gefunden, bleiben die Beträge unverändert. Ohne Mehrwährung werden die Beträge wie gespeichert geliefert und `dbCurrency` ist `NULL`.\n\n**5. Ausgabe** (genau eine Ergebnismenge, abhängig von `ViewDetails` und `PerLocation`)\n- `ViewDetails = 1`, `PerLocation = 0`: eine Zeile je Position, sortiert nach `OrderNr`, `OrderlineRef`.\n- `ViewDetails = 0`, `PerLocation = 0`: eine Summenzeile mit Anzahl Aufträge, Auftragswert (`Price * Qty`), Versandkosten und Picks.\n- `ViewDetails = 1`, `PerLocation = 1`: wie die Details, zusätzlich mit Spalte `LocationId`.\n- `ViewDetails = 0`, `PerLocation = 1`: eine Summenzeile je Lager.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ViewDetails` | bit | Nein | `1` liefert eine Zeile je Auftragsposition, `0` (oder `NULL`) liefert Summen. |\n| `IncludePartDelivery` | bit | Nein | Bei `OnlyPartDelivery = 0`: `1` liefert alle versandfähigen Positionen, auch von nur teilweise versendbaren Aufträgen. `0` liefert nur vollständige Aufträge. Wird bei `OnlyPartDelivery = 1` ignoriert. |\n| `OnlyPartDelivery` | bit | Nein | `1` liefert nur die versandfähigen Positionen von Aufträgen, die auch nicht versandfähige Positionen enthalten (Teillieferungen). |\n| `ShopId` | varchar(3) | Nein | Shop-Kürzel. Es werden nur Aufträge von Kunden mit `CustomerOf` gleich diesem Wert geliefert. Leer bedeutet alle Shops. |\n| `IncludeOrdersWithAnyShipDate` | bit | Nein | `0`: nur Aufträge ohne Versanddatum oder mit Versanddatum bis heute. `1`: das Versanddatum wird ignoriert. |\n| `PerLocation` | bit | Nein | `1` ergänzt `LocationId` in den Details bzw. gruppiert die Summen je Lager. Im Code als \"alte Variante\" bezeichnet. |\n| `UseFIFObyLocationV2` | bit | Nein | Steuert die Bestandsprüfung: `1` prüft den Bestand des Lagers der Position, `0` den Gesamtbestand aller Lager ohne Sonderbestand. `NULL` verwendet die Einstellung `UseFIFObyLocation`. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`. Das Ergebnis kann nicht festgeschriebene Daten enthalten und ist nur eine Momentaufnahme; es wird nichts reserviert oder geändert.\n- `NULL` für `ViewDetails`, `IncludePartDelivery`, `OnlyPartDelivery` und `PerLocation` wird als `0` behandelt. Eine leere `ShopId` gilt als \"alle Shops\". `NULL` für `IncludeOrdersWithAnyShipDate` wirkt wie `0`.\n- **Einstellungen mit Einfluss auf das Verhalten:**\n - `MultiCurrencyEnabled`: Währungsumrechnung und Spalte `dbCurrency`.\n - `HomeCurrency` und `DatabaseCurrencyExchRateSourceId`: verwendete Datenbankwährung und Kursquelle.\n - `UseFIFObyLocation`: gilt, wenn `UseFIFObyLocationV2` `NULL` ist.\n- Ob ein Auftrag \"vollständig\" ist, wird nur anhand seiner `ANG`/`EIN`-Positionen mit Artikel und positiver Menge beurteilt. Positionen in anderen Status werden ignoriert.\n- `ShipCost` sind die Versandkosten aus dem Auftragskopf und stehen auf jeder Position. In den Summen werden sie einmal je Auftrag addiert. In den Summen je Lager werden sie einmal je Auftrag und Lager addiert; ein Auftrag über mehrere Lager zählt seine Versandkosten daher in jedem dieser Lager.\n- Bei der Gesamtsumme (`ViewDetails = 0`, `PerLocation = 0`) wird immer eine Zeile geliefert. Ist nichts versandfähig, gilt `Orders` = 0 und `ShipCost` = 0, `OrderTotal`/`Picks` sind `NULL`. Die Summen je Lager liefern in diesem Fall keine Zeilen.\n- Ein Kommentar im Code bezeichnet `PerLocation` als \"alte Variante\".\n- Die interne Bestandsprozedur ruft `log.EventDurationInsert` auf (Definition nicht beigefügt), das vermutlich einen Laufzeit-Logeintrag schreibt.\n- Der Aufruf durchsucht alle offenen `ANG`/`EIN`-Positionen samt Reservierungen und kann bei großen Datenbanken aufwendig sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportGetShippableOrdersV2"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 42\n 3157.8000\n 209.5000\n 118\n EUR\n \n"
}
]
},
{
"name": "pixiRequestPartialDelivery",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n 1\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktiviert oder deaktiviert die Teillieferung für einen Auftrag und setzt die zugehörigen Storno- und Mehrfach-Teillieferungs-Flags, sofern der Auftrag nicht abgeschlossen oder gesperrt ist.\n\nÄndert die Teillieferungs-Einstellungen im Kopf eines Auftrags.\n\n1. Der Gesamtstatus des Auftrags wird aus seinen Auftragspositionen ermittelt:\n - `CLOSED` – alle Positionen befinden sich in einem Endstatus, oder der Auftrag hat gar keine Positionen (das gilt auch für nicht existierende Auftragsnummern).\n - `HOLD` – jede Position ist im Status `HAL`, im Status `MIN` oder in einem Endstatus.\n - `OPEN` – in allen anderen Fällen.\n2. Nur wenn der Status weder `CLOSED` noch `HOLD` ist, wird der Auftragskopf mit `OrderNr` = `@OrderNr` aktualisiert:\n - `ForceToPicklistIfNotFULL` wird auf `1` gesetzt, wenn `@PartialDeliveryActive` gleich `1` ist; bei `0` oder `NULL` wird das Feld auf `NULL` gesetzt (Teillieferung aus). Dieser Wert wird immer geschrieben.\n - `OHCancelAfterForcedShipOut` wird auf `@CancelUnavailableItems` gesetzt; fehlt der Parameter oder ist er `NULL`, bleibt der bisherige Wert erhalten.\n - `OHMultiForceToPicklist` wird auf `@PartialDeliveryForRemaining` gesetzt; fehlt der Parameter oder ist er `NULL`, bleibt der bisherige Wert erhalten.\n3. Die Anzahl der betroffenen Zeilen wird in der Spalte `RowsUpdated` zurückgegeben (`1`, wenn der Auftragskopf aktualisiert wurde).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Interne Pixi-Auftragsnummer (`OrderHeader.OrderNr`) des zu ändernden Auftrags. |\n| `PartialDeliveryActive` | bit | Ja | Schaltet die Teillieferung ein oder aus (`ForceToPicklistIfNotFULL`). `1` setzt das Flag, `0` oder `NULL` setzt es auf `NULL`. |\n| `CancelUnavailableItems` | bit | Nein | Wert für `OHCancelAfterForcedShipOut` (nicht verfügbare Artikel nach der erzwungenen Teillieferung stornieren). `NULL` behält den bisherigen Wert bei. |\n| `PartialDeliveryForRemaining` | bit | Nein | Wert für `OHMultiForceToPicklist` (weitere Teillieferungen für die Restmenge erlauben). `NULL` behält den bisherigen Wert bei. |\n\n- Ist der Auftrag abgeschlossen, gesperrt oder nicht vorhanden, wird kein Fehler gemeldet; es erfolgt lediglich keine Aktualisierung. Über `RowsUpdated` lässt sich prüfen, ob die Änderung übernommen wurde.\n- `RowsUpdated` wird nach dem bedingten Update aus `@@ROWCOUNT` gelesen. Wird das Update übersprungen, wird der Wert nicht explizit auf `0` gesetzt, sondern ergibt sich aus der Zeilenzählung von SQL Server für die vorherigen Anweisungen; zur sicheren Unterscheidung sollte der Auftragsstatus bei Bedarf separat abgefragt werden.\n- Anders als bei den beiden anderen Flags gibt es für `@PartialDeliveryActive` keine Beibehaltung des bisherigen Werts: `NULL` schaltet die Teillieferung aus.\n- Der Auftragsstatus wird mit `NOLOCK` aus den Auftragspositionen gelesen; bei gleichzeitigen Änderungen kann die Statusprüfung leicht veraltet sein.\n- Es wird keine explizite Transaktion verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiRequestPartialDelivery"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n 1\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktiviert oder deaktiviert die Teillieferung für einen Auftrag und setzt die zugehörigen Storno- und Mehrfach-Teillieferungs-Flags, sofern der Auftrag nicht abgeschlossen oder gesperrt ist.\n\nÄndert die Teillieferungs-Einstellungen im Kopf eines Auftrags.\n\n1. Der Gesamtstatus des Auftrags wird aus seinen Auftragspositionen ermittelt:\n - `CLOSED` – alle Positionen befinden sich in einem Endstatus, oder der Auftrag hat gar keine Positionen (das gilt auch für nicht existierende Auftragsnummern).\n - `HOLD` – jede Position ist im Status `HAL`, im Status `MIN` oder in einem Endstatus.\n - `OPEN` – in allen anderen Fällen.\n2. Nur wenn der Status weder `CLOSED` noch `HOLD` ist, wird der Auftragskopf mit `OrderNr` = `@OrderNr` aktualisiert:\n - `ForceToPicklistIfNotFULL` wird auf `1` gesetzt, wenn `@PartialDeliveryActive` gleich `1` ist; bei `0` oder `NULL` wird das Feld auf `NULL` gesetzt (Teillieferung aus). Dieser Wert wird immer geschrieben.\n - `OHCancelAfterForcedShipOut` wird auf `@CancelUnavailableItems` gesetzt; fehlt der Parameter oder ist er `NULL`, bleibt der bisherige Wert erhalten.\n - `OHMultiForceToPicklist` wird auf `@PartialDeliveryForRemaining` gesetzt; fehlt der Parameter oder ist er `NULL`, bleibt der bisherige Wert erhalten.\n3. Die Anzahl der betroffenen Zeilen wird in der Spalte `RowsUpdated` zurückgegeben (`1`, wenn der Auftragskopf aktualisiert wurde).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Interne Pixi-Auftragsnummer (`OrderHeader.OrderNr`) des zu ändernden Auftrags. |\n| `PartialDeliveryActive` | bit | Ja | Schaltet die Teillieferung ein oder aus (`ForceToPicklistIfNotFULL`). `1` setzt das Flag, `0` oder `NULL` setzt es auf `NULL`. |\n| `CancelUnavailableItems` | bit | Nein | Wert für `OHCancelAfterForcedShipOut` (nicht verfügbare Artikel nach der erzwungenen Teillieferung stornieren). `NULL` behält den bisherigen Wert bei. |\n| `PartialDeliveryForRemaining` | bit | Nein | Wert für `OHMultiForceToPicklist` (weitere Teillieferungen für die Restmenge erlauben). `NULL` behält den bisherigen Wert bei. |\n\n- Ist der Auftrag abgeschlossen, gesperrt oder nicht vorhanden, wird kein Fehler gemeldet; es erfolgt lediglich keine Aktualisierung. Über `RowsUpdated` lässt sich prüfen, ob die Änderung übernommen wurde.\n- `RowsUpdated` wird nach dem bedingten Update aus `@@ROWCOUNT` gelesen. Wird das Update übersprungen, wird der Wert nicht explizit auf `0` gesetzt, sondern ergibt sich aus der Zeilenzählung von SQL Server für die vorherigen Anweisungen; zur sicheren Unterscheidung sollte der Auftragsstatus bei Bedarf separat abgefragt werden.\n- Anders als bei den beiden anderen Flags gibt es für `@PartialDeliveryActive` keine Beibehaltung des bisherigen Werts: `NULL` schaltet die Teillieferung aus.\n- Der Auftragsstatus wird mit `NOLOCK` aus den Auftragspositionen gelesen; bei gleichzeitigen Änderungen kann die Statusprüfung leicht veraltet sein.\n- Es wird keine explizite Transaktion verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiRequestPartialDelivery"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n \n"
}
]
},
{
"name": "pixiSetBoxRangeForPicklist",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 4711\n 1\n 20\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder ändert den Kistenbereich (erste und letzte Kistennummer) einer Pickliste nach Prüfung von Kisten, Überschneidungen und Kistenanzahl.\n\nWeist der Pickliste `Picklist` den Kistenbereich `BoxNrFrom`–`BoxNrTo` zu.\n\nDie Eingaben werden in dieser Reihenfolge geprüft; beim ersten Fehler wird eine Zeile mit `Status` = `Error` und `Message` zurückgegeben:\n\n1. Die Pickliste muss in `PLHeader` existieren.\n2. `BoxNrFrom` muss als Kiste in `boxes` existieren.\n3. `BoxNrTo` muss als Kiste in `boxes` existieren.\n4. `BoxNrTo` darf nicht kleiner als `BoxNrFrom` sein.\n5. Ist die Einstellung `Picklist_Creation_Allow_BoxRange_OverLap` gleich `0`, darf keine Kistennummer des angeforderten Bereichs im Kistenbereich einer anderen Pickliste liegen.\n6. Die Anzahl der verschiedenen Aufträge auf der Pickliste (über Picklistenpositionen und Auftragspositionen) darf die Anzahl freier Kisten im Bereich nicht übersteigen. Eine Kiste gilt als frei, wenn `BOrderNr` `NULL` oder `0` ist.\n\nSind alle Prüfungen erfolgreich, wird:\n\n- jede bestehende Kistenzuordnung der Pickliste aus `pixi.PicklistBox` gelöscht,\n- der neue Bereich in `PLHeader.PLHfromBox` / `PLHeader.PLHtoBox` geschrieben,\n- eine Zeile mit Picklistenschlüssel, neuem Bereich und Statustext zurückgegeben. Der Text lautet *set*, wenn die Pickliste vorher keinen vollständigen Bereich hatte, sonst *changed*.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Picklist` | int | Ja | Schlüssel der Pickliste (`PLHeader.PLHkey`), deren Kistenbereich gesetzt wird. |\n| `BoxNrFrom` | int | Ja | Erste Kistennummer des Bereichs. Muss in `boxes` existieren. |\n| `BoxNrTo` | int | Ja | Letzte Kistennummer des Bereichs. Muss in `boxes` existieren und darf nicht kleiner als `BoxNrFrom` sein. |\n\n- Löschen und Aktualisieren laufen in einer Transaktion. Läuft der Aufruf bereits in einer offenen Transaktion, wird stattdessen ein Savepoint gesetzt und die äußere Transaktion nicht committet.\n- Bei einem unerwarteten SQL-Fehler wird die Transaktion (bzw. der Savepoint) zurückgerollt. Es wird eine Zeile mit `Status` = `Error` und dem SQL-Fehlertext zurückgegeben, und der Fehler wird über `log.InsertError` protokolliert (Definition nicht beigefügt).\n- Die Prüfabfragen verwenden `NOLOCK`, gleichzeitige Änderungen werden daher eventuell nicht erkannt.\n- Die Überschneidungsprüfung läuft nur, wenn der Einstellungswert `0` ist. Fehlt die Einstellung (`NULL`) oder hat sie einen anderen Wert, sind überlappende Bereiche erlaubt. Die Prüfung nutzt die Hilfstabelle `Numbers`; Kistennummern außerhalb ihres Bereichs werden nicht geprüft.\n- Kisten, die bereits einem Auftrag zugeordnet sind (`BOrderNr` gesetzt), gelten als belegt, auch wenn der Auftrag zur selben Pickliste gehört.\n- Eine frühere Prüfung, die Änderungen verhinderte, sobald Artikel der Pickliste bereits in Kisten gelegt wurden, wurde aus Gründen der Abwärtskompatibilität entfernt. Der Bereich kann daher auch danach geändert werden; bestehende Zuordnungen in `pixi.PicklistBox` werden in jedem Fall gelöscht.\n- Der Erfolgs-Statustext enthält die Schreibweise `succesfully` genau so, wie sie vom Code erzeugt wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetBoxRangeForPicklist"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 4711\n 1\n 20\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder ändert den Kistenbereich (erste und letzte Kistennummer) einer Pickliste nach Prüfung von Kisten, Überschneidungen und Kistenanzahl.\n\nWeist der Pickliste `Picklist` den Kistenbereich `BoxNrFrom`–`BoxNrTo` zu.\n\nDie Eingaben werden in dieser Reihenfolge geprüft; beim ersten Fehler wird eine Zeile mit `Status` = `Error` und `Message` zurückgegeben:\n\n1. Die Pickliste muss in `PLHeader` existieren.\n2. `BoxNrFrom` muss als Kiste in `boxes` existieren.\n3. `BoxNrTo` muss als Kiste in `boxes` existieren.\n4. `BoxNrTo` darf nicht kleiner als `BoxNrFrom` sein.\n5. Ist die Einstellung `Picklist_Creation_Allow_BoxRange_OverLap` gleich `0`, darf keine Kistennummer des angeforderten Bereichs im Kistenbereich einer anderen Pickliste liegen.\n6. Die Anzahl der verschiedenen Aufträge auf der Pickliste (über Picklistenpositionen und Auftragspositionen) darf die Anzahl freier Kisten im Bereich nicht übersteigen. Eine Kiste gilt als frei, wenn `BOrderNr` `NULL` oder `0` ist.\n\nSind alle Prüfungen erfolgreich, wird:\n\n- jede bestehende Kistenzuordnung der Pickliste aus `pixi.PicklistBox` gelöscht,\n- der neue Bereich in `PLHeader.PLHfromBox` / `PLHeader.PLHtoBox` geschrieben,\n- eine Zeile mit Picklistenschlüssel, neuem Bereich und Statustext zurückgegeben. Der Text lautet *set*, wenn die Pickliste vorher keinen vollständigen Bereich hatte, sonst *changed*.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Picklist` | int | Ja | Schlüssel der Pickliste (`PLHeader.PLHkey`), deren Kistenbereich gesetzt wird. |\n| `BoxNrFrom` | int | Ja | Erste Kistennummer des Bereichs. Muss in `boxes` existieren. |\n| `BoxNrTo` | int | Ja | Letzte Kistennummer des Bereichs. Muss in `boxes` existieren und darf nicht kleiner als `BoxNrFrom` sein. |\n\n- Löschen und Aktualisieren laufen in einer Transaktion. Läuft der Aufruf bereits in einer offenen Transaktion, wird stattdessen ein Savepoint gesetzt und die äußere Transaktion nicht committet.\n- Bei einem unerwarteten SQL-Fehler wird die Transaktion (bzw. der Savepoint) zurückgerollt. Es wird eine Zeile mit `Status` = `Error` und dem SQL-Fehlertext zurückgegeben, und der Fehler wird über `log.InsertError` protokolliert (Definition nicht beigefügt).\n- Die Prüfabfragen verwenden `NOLOCK`, gleichzeitige Änderungen werden daher eventuell nicht erkannt.\n- Die Überschneidungsprüfung läuft nur, wenn der Einstellungswert `0` ist. Fehlt die Einstellung (`NULL`) oder hat sie einen anderen Wert, sind überlappende Bereiche erlaubt. Die Prüfung nutzt die Hilfstabelle `Numbers`; Kistennummern außerhalb ihres Bereichs werden nicht geprüft.\n- Kisten, die bereits einem Auftrag zugeordnet sind (`BOrderNr` gesetzt), gelten als belegt, auch wenn der Auftrag zur selben Pickliste gehört.\n- Eine frühere Prüfung, die Änderungen verhinderte, sobald Artikel der Pickliste bereits in Kisten gelegt wurden, wurde aus Gründen der Abwärtskompatibilität entfernt. Der Bereich kann daher auch danach geändert werden; bestehende Zuordnungen in `pixi.PicklistBox` werden in jedem Fall gelöscht.\n- Der Erfolgs-Statustext enthält die Schreibweise `succesfully` genau so, wie sie vom Code erzeugt wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetBoxRangeForPicklist"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4711\n 1\n 20\n BoxRange for picklist(4711) was succesfully changed\n \n"
}
]
},
{
"name": "pixiSetOrderShippingInformation",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt Versanddienstleister sowie DHL-Produkt, -Verfahren und -Extras im Auftragskopf eines Auftrags, ermittelt über Pixi-Auftragsnummer oder externe Auftragsnummer.\n\nAktualisiert die Versandinformationen eines Auftrags in `OrderHeader`.\n\n1. Der Auftrag wird über `OrderNr = @OrderNr OR OrderNrExternal = @OrderNrExternal` gesucht. Wird kein Auftrag gefunden (auch wenn beide Parameter NULL sind), wird eine Zeile mit `Status` 400 geliefert und nichts geändert.\n2. Wird ein Auftrag gefunden, wird die Auftragszeile mit `UPDLOCK, ROWLOCK` gelesen. `OrderNr` und `OrderNrExternal` werden aus dem gespeicherten Auftrag übernommen. Jeder der Werte `ShipVendor`, `DHLProdukt`, `DHLVerfahren` und `DHLExtra`, der als NULL übergeben oder weggelassen wird, behält seinen bisherigen Wert (`ShipVendorCode`, `Product`, `Verfahren`, `Extras`).\n3. Der Auftrag wird über seine `OrderNr` aktualisiert. Die Änderung läuft in einer eigenen Transaktion oder, falls der Aufrufer bereits eine Transaktion geöffnet hat, in einem Savepoint.\n4. Die Prozedur liefert eine Statuszeile mit den aktuellen Werten des Auftrags:\n - `Status` 200 mit `Data updated in pixi`, wenn eine Zeile aktualisiert wurde.\n - `Status` 500 mit `Data could not be updated in pixi`, wenn keine Zeile aktualisiert wurde, z. B. wegen eines SQL-Fehlers.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer des zu ändernden Auftrags. Dieser Wert oder `OrderNrExternal` muss den Auftrag identifizieren. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer (z. B. aus dem Shop), über die der Auftrag gefunden wird, wenn `OrderNr` nicht angegeben ist. |\n| `ShipVendor` | varchar(3) | Nein | Versanddienstleister-Code, der in `ShipVendorCode` geschrieben wird. NULL behält den bisherigen Wert. |\n| `DHLProdukt` | varchar(50) | Nein | DHL-Produkt, das in `Product` geschrieben wird. NULL behält den bisherigen Wert. |\n| `DHLVerfahren` | varchar(50) | Nein | DHL-Verfahren, das in `Verfahren` geschrieben wird. NULL behält den bisherigen Wert. |\n| `DHLExtra` | varchar(50) | Nein | DHL-Extras, die in `Extras` geschrieben werden. NULL behält den bisherigen Wert. |\n\n- Ein Wert kann mit diesem Aufruf nicht auf NULL zurückgesetzt werden: NULL bedeutet \"bisherigen Wert behalten\". Ein Leerstring wird als solcher gespeichert.\n- Da die Suche mit `OR` arbeitet, können bei Übergabe von `OrderNr` und `OrderNrExternal` zwei verschiedene Aufträge gefunden werden, oder eine externe Nummer kann mehrere Aufträge treffen. Dann werden die Variablen aus einer der gefundenen Zeilen ohne definierte Reihenfolge belegt, und nur dieser Auftrag wird geändert. Daher nur einen Identifikator übergeben.\n- SQL-Fehler werden abgefangen, die Transaktion (bzw. der Savepoint) wird zurückgerollt und der Fehler über `log.InsertError` protokolliert (Definition nicht beigefügt). Es wird keine `SqlMessage` geliefert; der Aufrufer erhält nur `Status` 500. Ist die Transaktion nicht mehr commitfähig, wird ein vollständiges `ROLLBACK` ausgeführt, das auch eine äußere Transaktion des Aufrufers zurückrollt.\n- Die Existenzprüfung und die abschließende Statuszeile lesen `OrderHeader` mit `NOLOCK`.\n- Die Spaltentypen von `Product`, `Verfahren` und `Extras` sind im Code nicht sichtbar; zu lange Werte führen zu einem Fehler und damit zu `Status` 500.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetOrderShippingInformation"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt Versanddienstleister sowie DHL-Produkt, -Verfahren und -Extras im Auftragskopf eines Auftrags, ermittelt über Pixi-Auftragsnummer oder externe Auftragsnummer.\n\nAktualisiert die Versandinformationen eines Auftrags in `OrderHeader`.\n\n1. Der Auftrag wird über `OrderNr = @OrderNr OR OrderNrExternal = @OrderNrExternal` gesucht. Wird kein Auftrag gefunden (auch wenn beide Parameter NULL sind), wird eine Zeile mit `Status` 400 geliefert und nichts geändert.\n2. Wird ein Auftrag gefunden, wird die Auftragszeile mit `UPDLOCK, ROWLOCK` gelesen. `OrderNr` und `OrderNrExternal` werden aus dem gespeicherten Auftrag übernommen. Jeder der Werte `ShipVendor`, `DHLProdukt`, `DHLVerfahren` und `DHLExtra`, der als NULL übergeben oder weggelassen wird, behält seinen bisherigen Wert (`ShipVendorCode`, `Product`, `Verfahren`, `Extras`).\n3. Der Auftrag wird über seine `OrderNr` aktualisiert. Die Änderung läuft in einer eigenen Transaktion oder, falls der Aufrufer bereits eine Transaktion geöffnet hat, in einem Savepoint.\n4. Die Prozedur liefert eine Statuszeile mit den aktuellen Werten des Auftrags:\n - `Status` 200 mit `Data updated in pixi`, wenn eine Zeile aktualisiert wurde.\n - `Status` 500 mit `Data could not be updated in pixi`, wenn keine Zeile aktualisiert wurde, z. B. wegen eines SQL-Fehlers.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer des zu ändernden Auftrags. Dieser Wert oder `OrderNrExternal` muss den Auftrag identifizieren. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer (z. B. aus dem Shop), über die der Auftrag gefunden wird, wenn `OrderNr` nicht angegeben ist. |\n| `ShipVendor` | varchar(3) | Nein | Versanddienstleister-Code, der in `ShipVendorCode` geschrieben wird. NULL behält den bisherigen Wert. |\n| `DHLProdukt` | varchar(50) | Nein | DHL-Produkt, das in `Product` geschrieben wird. NULL behält den bisherigen Wert. |\n| `DHLVerfahren` | varchar(50) | Nein | DHL-Verfahren, das in `Verfahren` geschrieben wird. NULL behält den bisherigen Wert. |\n| `DHLExtra` | varchar(50) | Nein | DHL-Extras, die in `Extras` geschrieben werden. NULL behält den bisherigen Wert. |\n\n- Ein Wert kann mit diesem Aufruf nicht auf NULL zurückgesetzt werden: NULL bedeutet \"bisherigen Wert behalten\". Ein Leerstring wird als solcher gespeichert.\n- Da die Suche mit `OR` arbeitet, können bei Übergabe von `OrderNr` und `OrderNrExternal` zwei verschiedene Aufträge gefunden werden, oder eine externe Nummer kann mehrere Aufträge treffen. Dann werden die Variablen aus einer der gefundenen Zeilen ohne definierte Reihenfolge belegt, und nur dieser Auftrag wird geändert. Daher nur einen Identifikator übergeben.\n- SQL-Fehler werden abgefangen, die Transaktion (bzw. der Savepoint) wird zurückgerollt und der Fehler über `log.InsertError` protokolliert (Definition nicht beigefügt). Es wird keine `SqlMessage` geliefert; der Aufrufer erhält nur `Status` 500. Ist die Transaktion nicht mehr commitfähig, wird ein vollständiges `ROLLBACK` ausgeführt, das auch eine äußere Transaktion des Aufrufers zurückrollt.\n- Die Existenzprüfung und die abschließende Statuszeile lesen `OrderHeader` mit `NOLOCK`.\n- Die Spaltentypen von `Product`, `Verfahren` und `Extras` sind im Code nicht sichtbar; zu lange Werte führen zu einem Fehler und damit zu `Status` 500.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetOrderShippingInformation"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 200\n Data updated in pixi\n 123456\n SHOP-100234\n DHL\n V01PAK\n 01\n Premium\n \n"
}
]
},
{
"name": "pixiSetOrderShippingLock",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder entfernt die Versandsperre eines Auftrags über dessen Lieferadresse und schreibt einen Eintrag in die Versandsperren-Historie.\n\nSetzt die Versandsperre (`ASlocked`) an der Lieferadresse eines Auftrags.\n\n1. `Locked` = `NULL` wird als `1` behandelt; ein leerer oder `NULL`-`UserName` wird zu `API`.\n2. Die Referenz auf die Lieferadresse (`ShipAdrRef`) wird aus `OrderHeader` zum `OrderNr` gelesen. Existiert der Auftrag nicht oder ist `ShipAdrRef` `NULL`, wird eine `ERROR`-Zeile geliefert.\n3. Der referenzierte Datensatz in `Addresses` wird nur ausgewählt, wenn er `AddrType = 'S'` hat und sein aktueller `ASlocked`-Wert vom Zielwert abweicht (`Y` für Sperren, `N` für Entsperren). Wird keine solche Adresse gefunden, wird eine `INFO`-Zeile geliefert und nichts geändert.\n4. Ist `Reason` leer oder `NULL`, wird der Text `Order was locked by {UserName}` bzw. `Order was unlocked by {UserName}` verwendet.\n5. Ein Datensatz wird in `pixi.AddressesShippingLockHistory` eingefügt. Er enthält die Benutzer-ID, den Adressschlüssel, das Sperrkennzeichen und den Grund. Die Benutzer-ID wird aus `UserName` über `inf.UserGetByName` ermittelt, bei unbekanntem Namen wird der Benutzer `pixiAdministration` verwendet.\n6. Die Adresse wird aktualisiert:\n - `ASlocked` wird auf `Y`/`N` gesetzt.\n - `UpdateDate` wird auf die aktuelle Zeit gesetzt.\n - `UpdateEmp` wird auf den Benutzernamen gesetzt. Der Standardwert `API` wird als `API SetOrderShippingLock` geschrieben.\n7. Eine `OK`-Zeile wird geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Nummer des Auftrags, dessen Versandsperre geändert wird. |\n| `Locked` | bit | Nein | Zielzustand der Versandsperre. `NULL` wird als `1` behandelt. |\n| `UserName` | varchar(50) | Nein | Name des ändernden Benutzers. Leer oder `NULL` wird zu `API`. Der Name dient zur Ermittlung der Benutzer-ID für den Historieneintrag, mit Rückfall auf `pixiAdministration`. Außerdem wird er in `UpdateEmp` geschrieben, wobei `API` als `API SetOrderShippingLock` gespeichert wird. |\n| `Reason` | varchar(255) | Nein | Grund, der als `CustomerComment` in der Versandsperren-Historie gespeichert wird. Ist er leer, wird der Standardtext `Order was locked by …` / `Order was unlocked by …` verwendet. |\n\n- Die Sperre wird an dem Adressdatensatz gespeichert, auf den `ShipAdrRef` des Auftrags verweist, nicht am Auftragskopf selbst.\n- Die `INFO`-Zeile (`already set to …`) wird auch geliefert, wenn die referenzierte Adresse nicht existiert oder nicht `AddrType = 'S'` hat. In diesem Fall kann die Meldung irreführend sein.\n- `OrderHeader` wird mit `NOLOCK` gelesen; die Adresse wird mit `UPDLOCK` ausgewählt.\n- Es wird keine explizite Transaktion verwendet. Das Einfügen in die Historie und die Aktualisierung der Adresse sind getrennte Anweisungen und werden nicht gemeinsam zurückgerollt.\n- Während der Aktualisierung wird `CONTEXT_INFO` vorübergehend auf `0x33999` gesetzt und danach wiederhergestellt. Dies wird vermutlich von Triggern auf `Addresses` ausgewertet, die nicht beigefügt sind.\n- Statuszeilen verwenden immer die Spalte `ErrorMessage`, auch im `OK`-Fall.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetOrderShippingLock"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder entfernt die Versandsperre eines Auftrags über dessen Lieferadresse und schreibt einen Eintrag in die Versandsperren-Historie.\n\nSetzt die Versandsperre (`ASlocked`) an der Lieferadresse eines Auftrags.\n\n1. `Locked` = `NULL` wird als `1` behandelt; ein leerer oder `NULL`-`UserName` wird zu `API`.\n2. Die Referenz auf die Lieferadresse (`ShipAdrRef`) wird aus `OrderHeader` zum `OrderNr` gelesen. Existiert der Auftrag nicht oder ist `ShipAdrRef` `NULL`, wird eine `ERROR`-Zeile geliefert.\n3. Der referenzierte Datensatz in `Addresses` wird nur ausgewählt, wenn er `AddrType = 'S'` hat und sein aktueller `ASlocked`-Wert vom Zielwert abweicht (`Y` für Sperren, `N` für Entsperren). Wird keine solche Adresse gefunden, wird eine `INFO`-Zeile geliefert und nichts geändert.\n4. Ist `Reason` leer oder `NULL`, wird der Text `Order was locked by {UserName}` bzw. `Order was unlocked by {UserName}` verwendet.\n5. Ein Datensatz wird in `pixi.AddressesShippingLockHistory` eingefügt. Er enthält die Benutzer-ID, den Adressschlüssel, das Sperrkennzeichen und den Grund. Die Benutzer-ID wird aus `UserName` über `inf.UserGetByName` ermittelt, bei unbekanntem Namen wird der Benutzer `pixiAdministration` verwendet.\n6. Die Adresse wird aktualisiert:\n - `ASlocked` wird auf `Y`/`N` gesetzt.\n - `UpdateDate` wird auf die aktuelle Zeit gesetzt.\n - `UpdateEmp` wird auf den Benutzernamen gesetzt. Der Standardwert `API` wird als `API SetOrderShippingLock` geschrieben.\n7. Eine `OK`-Zeile wird geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Nummer des Auftrags, dessen Versandsperre geändert wird. |\n| `Locked` | bit | Nein | Zielzustand der Versandsperre. `NULL` wird als `1` behandelt. |\n| `UserName` | varchar(50) | Nein | Name des ändernden Benutzers. Leer oder `NULL` wird zu `API`. Der Name dient zur Ermittlung der Benutzer-ID für den Historieneintrag, mit Rückfall auf `pixiAdministration`. Außerdem wird er in `UpdateEmp` geschrieben, wobei `API` als `API SetOrderShippingLock` gespeichert wird. |\n| `Reason` | varchar(255) | Nein | Grund, der als `CustomerComment` in der Versandsperren-Historie gespeichert wird. Ist er leer, wird der Standardtext `Order was locked by …` / `Order was unlocked by …` verwendet. |\n\n- Die Sperre wird an dem Adressdatensatz gespeichert, auf den `ShipAdrRef` des Auftrags verweist, nicht am Auftragskopf selbst.\n- Die `INFO`-Zeile (`already set to …`) wird auch geliefert, wenn die referenzierte Adresse nicht existiert oder nicht `AddrType = 'S'` hat. In diesem Fall kann die Meldung irreführend sein.\n- `OrderHeader` wird mit `NOLOCK` gelesen; die Adresse wird mit `UPDLOCK` ausgewählt.\n- Es wird keine explizite Transaktion verwendet. Das Einfügen in die Historie und die Aktualisierung der Adresse sind getrennte Anweisungen und werden nicht gemeinsam zurückgerollt.\n- Während der Aktualisierung wird `CONTEXT_INFO` vorübergehend auf `0x33999` gesetzt und danach wiederhergestellt. Dies wird vermutlich von Triggern auf `Addresses` ausgewertet, die nicht beigefügt sind.\n- Statuszeilen verwenden immer die Spalte `ErrorMessage`, auch im `OK`-Fall.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetOrderShippingLock"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n Order with OrderNr 104523 changed. \n \n"
}
]
},
{
"name": "pixiTagMatchAddForOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ordnet Aufträgen ein oder mehrere Tags zu, die als XML übergeben werden, und liefert je Tag/Auftrag-Paar eine Statuszeile.\n\nLegt Tag-Zuordnungen (`TagMatch`-Einträge) zwischen Tags und Aufträgen an.\n\n1. Das XML in `TagsXML` wird elementbasiert entlang `/Tags/Order/TagList/Tag` ausgelesen. Jedes `Tag`-Element ergibt einen Kandidaten. Dessen `TagId` wird mit `OrderId` und `OrderNrExternal` aus dem umgebenden `Order`-Element kombiniert. Die Werte `0` und leere Zeichenketten gelten als nicht angegeben.\n2. Der Auftrag wird über `OrderHeader` ermittelt:\n - `OrderId` wird mit `OrderHeader.OrderNr` abgeglichen.\n - `OrderNrExternal` wird mit `OrderHeader.OrderNrExternal` abgeglichen.\n - Sind beide angegeben, hat die Auftragsnummer (`OrderId`) Vorrang.\n3. Jeder Kandidat wird geprüft:\n - Keine `TagId` oder weder Auftragsnummer noch externe Auftragsnummer: `Mandatory parameter is missing`.\n - Der Auftrag wird nicht gefunden, oder der Tag existiert nicht als Auftrags-Tag (`Tag.TypeId = 2`): `One of the provided values is not valid`.\n - Der Tag ist dem Auftrag bereits zugeordnet: Warnung `Tag is already assigned to that order`.\n4. Alle übrigen Kandidaten werden in `TagMatch` (`TagId`, `OrderHeaderId`) eingefügt. Doppelte Paare im XML werden nur einmal geschrieben.\n\nDer Aufruf liefert je verarbeitetem Kandidaten eine Zeile, in der Reihenfolge der `Tag`-Elemente im XML. Jede Zeile enthält Status und Meldung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | Nein | XML mit Aufträgen und den zuzuordnenden Tags. Jedes `Order`-Element bestimmt den Auftrag über `OrderId` (Pixi-Auftragsnummer) oder `OrderNrExternal`. Seine `TagList` enthält `Tag`-Elemente mit je einer `TagId`. |\n\n- Der Aufruf läuft in einer eigenen Transaktion. Wird er innerhalb einer bestehenden Transaktion aufgerufen, verwendet er stattdessen einen Savepoint.\n- Die Abfragen auf `OrderHeader`, `Tag` und `TagMatch` verwenden `NOLOCK`.\n- Bei einem unerwarteten Fehler (z. B. ungültiges XML) setzt der `CATCH`-Block die Transaktion zurück und protokolliert den Fehler über `log.InsertError`. In diesem Fall wird keine Ergebnismenge geliefert. Die interne Meldung `Unexpected error: ...` wird zwar erzeugt, aber nie ausgegeben.\n- Es werden nur Tags mit `TypeId = 2` (Auftrags-Tags) akzeptiert.\n- Passt eine `OrderNrExternal` auf mehrere Aufträge, kann ein Kandidat mehrere Ergebniszeilen erzeugen.\n- Wird `TagsXML` weggelassen (`NULL`) oder enthält es keine `Tag`-Elemente, wird nichts zugeordnet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagMatchAddForOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ordnet Aufträgen ein oder mehrere Tags zu, die als XML übergeben werden, und liefert je Tag/Auftrag-Paar eine Statuszeile.\n\nLegt Tag-Zuordnungen (`TagMatch`-Einträge) zwischen Tags und Aufträgen an.\n\n1. Das XML in `TagsXML` wird elementbasiert entlang `/Tags/Order/TagList/Tag` ausgelesen. Jedes `Tag`-Element ergibt einen Kandidaten. Dessen `TagId` wird mit `OrderId` und `OrderNrExternal` aus dem umgebenden `Order`-Element kombiniert. Die Werte `0` und leere Zeichenketten gelten als nicht angegeben.\n2. Der Auftrag wird über `OrderHeader` ermittelt:\n - `OrderId` wird mit `OrderHeader.OrderNr` abgeglichen.\n - `OrderNrExternal` wird mit `OrderHeader.OrderNrExternal` abgeglichen.\n - Sind beide angegeben, hat die Auftragsnummer (`OrderId`) Vorrang.\n3. Jeder Kandidat wird geprüft:\n - Keine `TagId` oder weder Auftragsnummer noch externe Auftragsnummer: `Mandatory parameter is missing`.\n - Der Auftrag wird nicht gefunden, oder der Tag existiert nicht als Auftrags-Tag (`Tag.TypeId = 2`): `One of the provided values is not valid`.\n - Der Tag ist dem Auftrag bereits zugeordnet: Warnung `Tag is already assigned to that order`.\n4. Alle übrigen Kandidaten werden in `TagMatch` (`TagId`, `OrderHeaderId`) eingefügt. Doppelte Paare im XML werden nur einmal geschrieben.\n\nDer Aufruf liefert je verarbeitetem Kandidaten eine Zeile, in der Reihenfolge der `Tag`-Elemente im XML. Jede Zeile enthält Status und Meldung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | Nein | XML mit Aufträgen und den zuzuordnenden Tags. Jedes `Order`-Element bestimmt den Auftrag über `OrderId` (Pixi-Auftragsnummer) oder `OrderNrExternal`. Seine `TagList` enthält `Tag`-Elemente mit je einer `TagId`. |\n\n- Der Aufruf läuft in einer eigenen Transaktion. Wird er innerhalb einer bestehenden Transaktion aufgerufen, verwendet er stattdessen einen Savepoint.\n- Die Abfragen auf `OrderHeader`, `Tag` und `TagMatch` verwenden `NOLOCK`.\n- Bei einem unerwarteten Fehler (z. B. ungültiges XML) setzt der `CATCH`-Block die Transaktion zurück und protokolliert den Fehler über `log.InsertError`. In diesem Fall wird keine Ergebnismenge geliefert. Die interne Meldung `Unexpected error: ...` wird zwar erzeugt, aber nie ausgegeben.\n- Es werden nur Tags mit `TypeId = 2` (Auftrags-Tags) akzeptiert.\n- Passt eine `OrderNrExternal` auf mehrere Aufträge, kann ein Kandidat mehrere Ergebniszeilen erzeugen.\n- Wird `TagsXML` weggelassen (`NULL`) oder enthält es keine `Tag`-Elemente, wird nichts zugeordnet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagMatchAddForOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 12\n 123456\n 98765\n Success\n Tag was successfully assigned to order\n \n \n 12\n SHOP-100045\n Error\n One of the provided values is not valid\n \n"
}
]
},
{
"name": "pixiTagMatchDeleteForOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Entfernt Tag-Zuordnungen (TagMatch) von Aufträgen für die per XML übergebenen Tag/Auftrag-Paare und liefert pro Paar eine Statuszeile.\n\nLöscht die Zuordnung von Auftrags-Tags zu Aufträgen. Die Paare werden in `TagsXML` übergeben; jedes `Tag`-Element unterhalb von `/Tags/Order/TagList` ist ein Eintrag.\n\nAblauf:\n\n1. Das XML wird elementbasiert gelesen. Für jedes `Tag` wird `TagId` aus dem `Tag`-Element, `OrderId` und `OrderNrExternal` aus dem übergeordneten `Order`-Element gelesen. Eine `TagId` oder `OrderId` von `0` sowie eine leere `OrderNrExternal` gelten als nicht angegeben.\n2. Der Auftrag wird in `OrderHeader` ermittelt: über `OrderNr` = `OrderId` und über `OrderNrExternal`. Der über `OrderId` gefundene OrderHeaderKey hat Vorrang; wird dort keiner gefunden, wird der über `OrderNrExternal` gefundene verwendet. Ist nur `OrderNrExternal` angegeben, wird als `OrderId` die `OrderNr` des gefundenen Auftrags zurückgegeben.\n3. Jeder Eintrag wird geprüft:\n - keine `TagId` oder weder `OrderId` noch `OrderNrExternal` → `Error` *Mandatory parameter is missing*\n - Auftrag nicht gefunden oder Tag nicht als Auftrags-Tag (`Tag.TypeId = 2`) vorhanden → `Error` *One of the provided values is not valid*\n4. Für gültige Einträge wird eine bestehende `TagMatch`-Zeile mit diesem Tag und Auftragskopf gesucht. Existiert sie, erhält der Eintrag `Success` *Tag was successfully removed from order* und die `TagMatch`-Zeile wird gelöscht. Existiert sie nicht, erhält der Eintrag `Warning` *Tag is not assigned to that order*.\n5. Pro Eintrag wird eine Ergebniszeile zurückgegeben, sortiert in der Reihenfolge der Einträge im XML.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | Nein | XML-Dokument mit den Aufträgen und den zu entfernenden Tags. Jedes `Order`-Element enthält `OrderId` (Pixi-`OrderNr`) und/oder `OrderNrExternal` sowie eine `TagList` mit einem oder mehreren `Tag`-Elementen mit jeweils einer `TagId`. |\n\n- Berücksichtigt werden nur Tags mit `TypeId = 2` (Auftrags-Tags).\n- Der Aufruf läuft in einer eigenen Transaktion bzw. in einem Savepoint, wenn bereits eine Transaktion offen ist.\n- Bei einem unerwarteten Fehler (z. B. ungültiges XML) wird die Transaktion zurückgerollt, der Fehler über `log.InsertError` (nicht beigefügt) protokolliert und **keine Ergebnismenge zurückgegeben**. Der Text `Unexpected error: \"…\"` wird intern gebildet, aber nicht ausgegeben.\n- Lesezugriffe auf `OrderHeader`, `Tag` und `TagMatch` erfolgen mit `NOLOCK`; das Löschen mit `ROWLOCK`.\n- Teilen sich mehrere Aufträge dieselbe `OrderNrExternal`, kann ein Eintrag mehrere Ergebniszeilen liefern und der Tag wird von allen passenden Aufträgen entfernt.\n- Wird dasselbe Tag/Auftrag-Paar doppelt übergeben, erhalten beide Einträge `Success`; die `TagMatch`-Zeile wird einmal gelöscht.\n- Der Kopfkommentar der Prozedur lautet *Create TagMatch for Order*, der Code entfernt jedoch ausschließlich Zuordnungen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagMatchDeleteForOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Entfernt Tag-Zuordnungen (TagMatch) von Aufträgen für die per XML übergebenen Tag/Auftrag-Paare und liefert pro Paar eine Statuszeile.\n\nLöscht die Zuordnung von Auftrags-Tags zu Aufträgen. Die Paare werden in `TagsXML` übergeben; jedes `Tag`-Element unterhalb von `/Tags/Order/TagList` ist ein Eintrag.\n\nAblauf:\n\n1. Das XML wird elementbasiert gelesen. Für jedes `Tag` wird `TagId` aus dem `Tag`-Element, `OrderId` und `OrderNrExternal` aus dem übergeordneten `Order`-Element gelesen. Eine `TagId` oder `OrderId` von `0` sowie eine leere `OrderNrExternal` gelten als nicht angegeben.\n2. Der Auftrag wird in `OrderHeader` ermittelt: über `OrderNr` = `OrderId` und über `OrderNrExternal`. Der über `OrderId` gefundene OrderHeaderKey hat Vorrang; wird dort keiner gefunden, wird der über `OrderNrExternal` gefundene verwendet. Ist nur `OrderNrExternal` angegeben, wird als `OrderId` die `OrderNr` des gefundenen Auftrags zurückgegeben.\n3. Jeder Eintrag wird geprüft:\n - keine `TagId` oder weder `OrderId` noch `OrderNrExternal` → `Error` *Mandatory parameter is missing*\n - Auftrag nicht gefunden oder Tag nicht als Auftrags-Tag (`Tag.TypeId = 2`) vorhanden → `Error` *One of the provided values is not valid*\n4. Für gültige Einträge wird eine bestehende `TagMatch`-Zeile mit diesem Tag und Auftragskopf gesucht. Existiert sie, erhält der Eintrag `Success` *Tag was successfully removed from order* und die `TagMatch`-Zeile wird gelöscht. Existiert sie nicht, erhält der Eintrag `Warning` *Tag is not assigned to that order*.\n5. Pro Eintrag wird eine Ergebniszeile zurückgegeben, sortiert in der Reihenfolge der Einträge im XML.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | Nein | XML-Dokument mit den Aufträgen und den zu entfernenden Tags. Jedes `Order`-Element enthält `OrderId` (Pixi-`OrderNr`) und/oder `OrderNrExternal` sowie eine `TagList` mit einem oder mehreren `Tag`-Elementen mit jeweils einer `TagId`. |\n\n- Berücksichtigt werden nur Tags mit `TypeId = 2` (Auftrags-Tags).\n- Der Aufruf läuft in einer eigenen Transaktion bzw. in einem Savepoint, wenn bereits eine Transaktion offen ist.\n- Bei einem unerwarteten Fehler (z. B. ungültiges XML) wird die Transaktion zurückgerollt, der Fehler über `log.InsertError` (nicht beigefügt) protokolliert und **keine Ergebnismenge zurückgegeben**. Der Text `Unexpected error: \"…\"` wird intern gebildet, aber nicht ausgegeben.\n- Lesezugriffe auf `OrderHeader`, `Tag` und `TagMatch` erfolgen mit `NOLOCK`; das Löschen mit `ROWLOCK`.\n- Teilen sich mehrere Aufträge dieselbe `OrderNrExternal`, kann ein Eintrag mehrere Ergebniszeilen liefern und der Tag wird von allen passenden Aufträgen entfernt.\n- Wird dasselbe Tag/Auftrag-Paar doppelt übergeben, erhalten beide Einträge `Success`; die `TagMatch`-Zeile wird einmal gelöscht.\n- Der Kopfkommentar der Prozedur lautet *Create TagMatch for Order*, der Code entfernt jedoch ausschließlich Zuordnungen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiTagMatchDeleteForOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 7\n 104512\n SHOP-2024-0815\n 98765\n Success\n Tag was successfully removed from order\n \n \n 12\n 104512\n SHOP-2024-0815\n 98765\n Warning\n Tag is not assigned to that order\n \n"
}
]
},
{
"name": "pixiUpdateOrder",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Versandkosten, Versanddatum, Shop-Notiz, Gutschein, Adressbemerkung und Zahlungsart eines bestehenden offenen Auftrags.\n\nAktualisiert ausgewählte Kopfdaten eines bestehenden Auftrags. Der Auftrag wird über `OrderNr` oder `OrderNrExternal` gefunden.\n\n**Prüfungen (jede liefert eine `Error`-Zeile und bricht ab):**\n1. Mindestens `OrderNr` oder `OrderNrExternal` muss angegeben sein.\n2. Der Auftrag wird mit `OrderNr = @OrderNr OR OrderNrExternal = @OrderNrExternal` gesucht (erster Treffer). Wird keiner gefunden, kommt ein Fehler.\n3. `VoucherID` und `VoucherAmount` müssen gemeinsam angegeben werden.\n4. Der Gutschein darf nicht bereits auf Auftragspositionen eines anderen Auftrags verwendet sein.\n5. Ist `PaymentType` angegeben, muss der Wert als `Code` in der Tabelle `Payments` existieren.\n6. Der Auftrag muss noch änderbar sein: Der aus den Auftragspositionen berechnete Gesamtstatus muss `OPEN` oder `HOLD` sein. Zusätzlich muss die Anzahl nicht finaler Positionen mit Rechnungspositionen kleiner sein als die Anzahl der Positionen, die weder final sind noch den Status `MIN` oder `FUS` haben.\n\n**Aktualisierung:**\n- Nicht übergebene Parameter behalten die aktuellen Werte des Auftrags.\n- `ShipCosts` wird bei `B2B`-Aufträgen auf die Netto-Versandkosten angewendet, bei `B2C`-Aufträgen auf die Brutto-Versandkosten.\n- `ShipDate` ersetzt das Versanddatum. Der Wert `1900-01-01` setzt es auf `NULL`.\n- `ShopNote` und `AddressRemarks` ersetzen die gespeicherten Texte.\n- Alle übrigen Kopffelder werden unverändert durchgereicht, z. B. Geschenktext, Versandanweisung, Versanddienstleister, CCP-Merchant, `ccpPayID`, Verfahren/Product/Extras und Auftragstyp.\n- Die eigentliche Aktualisierung erfolgt über die interne Prozedur `Pixi_UpdateOrder`. Sie setzt `UpdateDate` auf die aktuelle Zeit.\n- Ändern sich die Versandkosten und gilt weder Gutschein noch Rabatt, wird auch `ShipCost` der Auftragspositionen angepasst.\n- Ein angegebener Gutschein wird in `Voucher` angelegt, falls er noch nicht existiert. Andernfalls wird sein Betrag aktualisiert. Die Gutschein-ID wird danach auf alle Auftragspositionen geschrieben.\n- Ist `PaymentType` angegeben, wird der Wert in `APayment` der Adresse des Auftrags (`AddrRef`) geschrieben.\n\nBei Erfolg wird eine `Success`-Zeile geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. Entweder diese oder `OrderNrExternal` ist erforderlich. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer (Shop). Wird verwendet, wenn `OrderNr` fehlt; Leerstring gilt als nicht angegeben. |\n| `ShipCosts` | money | Nein | Neue Versandkosten (netto bei `B2B`-, brutto bei `B2C`-Aufträgen). Ohne Angabe bleibt der aktuelle Wert. |\n| `ShipDate` | datetime | Nein | Neues Versanddatum. Ohne Angabe bleibt der aktuelle Wert; `1900-01-01` löscht es. |\n| `ShopNote` | varchar(max) | Nein | Notiz des Shops zum Auftrag (Shop-Kommentar). Ohne Angabe bleibt die aktuelle Notiz. |\n| `VoucherID` | varchar(50) | Nein | Gutschein-ID. Muss zusammen mit `VoucherAmount` angegeben werden und darf nicht in einem anderen Auftrag verwendet sein. |\n| `VoucherAmount` | money | Nein | Durch den Gutschein abgedeckter Betrag. Erfordert `VoucherID`; `0` gilt als nicht angegeben. |\n| `PaymentType` | varchar(1) | Nein | Zahlungsart-Code; muss in `Payments` existieren. Wird in `APayment` der Auftragsadresse geschrieben. Leerstring gilt als nicht angegeben. |\n| `AddressRemarks` | varchar(255) | Nein | Neue Adressbemerkung des Auftrags. Ohne Angabe bleibt der aktuelle Wert. |\n\n- `VoucherAmount` wird über `NULLIF(@VoucherAmount, '')` geprüft. Da `''` bei `money` zu `0` konvertiert wird, gilt ein Betrag von `0` als *nicht angegeben*. `VoucherID` mit Betrag `0` liefert daher `VoucherID provided without VoucherAmount.`\n- Eine leere `VoucherID` gilt als nicht angegeben.\n- Sind `OrderNr` und `OrderNrExternal` angegeben und passen sie zu verschiedenen Aufträgen, wird ein beliebiger davon aktualisiert (`TOP (1)` ohne `ORDER BY`).\n- Bei der Meldung *does not exist* wird der Text per Verkettung gebildet. Ist einer der beiden Bezeichner `NULL`, ist die Spalte `Message` `NULL`.\n- `Pixi_UpdateOrder` läuft in einer eigenen Transaktion und fängt Fehler selbst ab. Sie protokolliert sie über `log.InsertError` und wirft sie nicht erneut, sodass die äußere Fehlerbehandlung sie ggf. nicht sieht. Eine `Success`-Zeile ist daher auch möglich, wenn die innere Aktualisierung zurückgerollt wurde. `log.InsertError` liegt nicht vor.\n- Die Aktualisierung der Zahlungsart in `Addresses` erfolgt nach der inneren Transaktion und außerhalb davon.\n- Hat der Auftrag keinen CCP-Merchant, kann die innere Prozedur anhand der Einstellung `DefaultCCPMerchant` einen setzen.\n- Ist `ccpPayID` bei einem offenen Auftrag `NULL`, wird ein Leerstring gespeichert.\n- `ShopNote` ist als `varchar(max)` deklariert. Zeichen außerhalb der Codepage der Datenbank gehen verloren, obwohl die Zielspalte `nvarchar` ist.\n- Lesezugriffe im Prüfteil nutzen `NOLOCK`; die innere Prozedur setzt `UPDLOCK` auf `OrderHeader` und `Orderlines`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateOrder"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Versandkosten, Versanddatum, Shop-Notiz, Gutschein, Adressbemerkung und Zahlungsart eines bestehenden offenen Auftrags.\n\nAktualisiert ausgewählte Kopfdaten eines bestehenden Auftrags. Der Auftrag wird über `OrderNr` oder `OrderNrExternal` gefunden.\n\n**Prüfungen (jede liefert eine `Error`-Zeile und bricht ab):**\n1. Mindestens `OrderNr` oder `OrderNrExternal` muss angegeben sein.\n2. Der Auftrag wird mit `OrderNr = @OrderNr OR OrderNrExternal = @OrderNrExternal` gesucht (erster Treffer). Wird keiner gefunden, kommt ein Fehler.\n3. `VoucherID` und `VoucherAmount` müssen gemeinsam angegeben werden.\n4. Der Gutschein darf nicht bereits auf Auftragspositionen eines anderen Auftrags verwendet sein.\n5. Ist `PaymentType` angegeben, muss der Wert als `Code` in der Tabelle `Payments` existieren.\n6. Der Auftrag muss noch änderbar sein: Der aus den Auftragspositionen berechnete Gesamtstatus muss `OPEN` oder `HOLD` sein. Zusätzlich muss die Anzahl nicht finaler Positionen mit Rechnungspositionen kleiner sein als die Anzahl der Positionen, die weder final sind noch den Status `MIN` oder `FUS` haben.\n\n**Aktualisierung:**\n- Nicht übergebene Parameter behalten die aktuellen Werte des Auftrags.\n- `ShipCosts` wird bei `B2B`-Aufträgen auf die Netto-Versandkosten angewendet, bei `B2C`-Aufträgen auf die Brutto-Versandkosten.\n- `ShipDate` ersetzt das Versanddatum. Der Wert `1900-01-01` setzt es auf `NULL`.\n- `ShopNote` und `AddressRemarks` ersetzen die gespeicherten Texte.\n- Alle übrigen Kopffelder werden unverändert durchgereicht, z. B. Geschenktext, Versandanweisung, Versanddienstleister, CCP-Merchant, `ccpPayID`, Verfahren/Product/Extras und Auftragstyp.\n- Die eigentliche Aktualisierung erfolgt über die interne Prozedur `Pixi_UpdateOrder`. Sie setzt `UpdateDate` auf die aktuelle Zeit.\n- Ändern sich die Versandkosten und gilt weder Gutschein noch Rabatt, wird auch `ShipCost` der Auftragspositionen angepasst.\n- Ein angegebener Gutschein wird in `Voucher` angelegt, falls er noch nicht existiert. Andernfalls wird sein Betrag aktualisiert. Die Gutschein-ID wird danach auf alle Auftragspositionen geschrieben.\n- Ist `PaymentType` angegeben, wird der Wert in `APayment` der Adresse des Auftrags (`AddrRef`) geschrieben.\n\nBei Erfolg wird eine `Success`-Zeile geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. Entweder diese oder `OrderNrExternal` ist erforderlich. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer (Shop). Wird verwendet, wenn `OrderNr` fehlt; Leerstring gilt als nicht angegeben. |\n| `ShipCosts` | money | Nein | Neue Versandkosten (netto bei `B2B`-, brutto bei `B2C`-Aufträgen). Ohne Angabe bleibt der aktuelle Wert. |\n| `ShipDate` | datetime | Nein | Neues Versanddatum. Ohne Angabe bleibt der aktuelle Wert; `1900-01-01` löscht es. |\n| `ShopNote` | varchar(max) | Nein | Notiz des Shops zum Auftrag (Shop-Kommentar). Ohne Angabe bleibt die aktuelle Notiz. |\n| `VoucherID` | varchar(50) | Nein | Gutschein-ID. Muss zusammen mit `VoucherAmount` angegeben werden und darf nicht in einem anderen Auftrag verwendet sein. |\n| `VoucherAmount` | money | Nein | Durch den Gutschein abgedeckter Betrag. Erfordert `VoucherID`; `0` gilt als nicht angegeben. |\n| `PaymentType` | varchar(1) | Nein | Zahlungsart-Code; muss in `Payments` existieren. Wird in `APayment` der Auftragsadresse geschrieben. Leerstring gilt als nicht angegeben. |\n| `AddressRemarks` | varchar(255) | Nein | Neue Adressbemerkung des Auftrags. Ohne Angabe bleibt der aktuelle Wert. |\n\n- `VoucherAmount` wird über `NULLIF(@VoucherAmount, '')` geprüft. Da `''` bei `money` zu `0` konvertiert wird, gilt ein Betrag von `0` als *nicht angegeben*. `VoucherID` mit Betrag `0` liefert daher `VoucherID provided without VoucherAmount.`\n- Eine leere `VoucherID` gilt als nicht angegeben.\n- Sind `OrderNr` und `OrderNrExternal` angegeben und passen sie zu verschiedenen Aufträgen, wird ein beliebiger davon aktualisiert (`TOP (1)` ohne `ORDER BY`).\n- Bei der Meldung *does not exist* wird der Text per Verkettung gebildet. Ist einer der beiden Bezeichner `NULL`, ist die Spalte `Message` `NULL`.\n- `Pixi_UpdateOrder` läuft in einer eigenen Transaktion und fängt Fehler selbst ab. Sie protokolliert sie über `log.InsertError` und wirft sie nicht erneut, sodass die äußere Fehlerbehandlung sie ggf. nicht sieht. Eine `Success`-Zeile ist daher auch möglich, wenn die innere Aktualisierung zurückgerollt wurde. `log.InsertError` liegt nicht vor.\n- Die Aktualisierung der Zahlungsart in `Addresses` erfolgt nach der inneren Transaktion und außerhalb davon.\n- Hat der Auftrag keinen CCP-Merchant, kann die innere Prozedur anhand der Einstellung `DefaultCCPMerchant` einen setzen.\n- Ist `ccpPayID` bei einem offenen Auftrag `NULL`, wird ein Leerstring gespeichert.\n- `ShopNote` ist als `varchar(max)` deklariert. Zeichen außerhalb der Codepage der Datenbank gehen verloren, obwohl die Zielspalte `nvarchar` ist.\n- Lesezugriffe im Prüfteil nutzen `NOLOCK`; die innere Prozedur setzt `UPDLOCK` auf `OrderHeader` und `Orderlines`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateOrder"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n Order with OrderNr: 100234 was updated.\n \n"
}
]
}
]
},
{
"name": "Payments",
"item": [
{
"name": "pixiAutoMatchPayments",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ordnet die Bankzeilen eines Bank-Headers automatisch offenen Aufträgen oder Rechnungen zu, bestätigt die Zuordnung und gibt den Auftrag bei vollständiger Zahlung frei.\n\nFührt den automatischen Zahlungsabgleich für einen Bank-Header (`BankHeaderKey`) aus und bestätigt bei einem Treffer die Zuordnung; anschließend wird versucht, den zugeordneten Auftrag freizugeben.\n\n1. Ist `BankHeaderKey` NULL, wird eine Zeile mit NULL-Werten und der Meldung `Parameter BankHeaderKey is mandatory!` geliefert; sonst passiert nichts.\n2. Der interne automatische Abgleich (`Pixi_BankAutomaticMatching`) läuft für alle Bankzeilen dieses Headers, die noch keinen Eintrag in `BankMatch` haben. Gesucht werden 100%-Treffer:\n - **Aufträge**, deren Zahlungsart einen Abgleich erlaubt (`Payments.MatchToOrders = 1`) und die mindestens eine Auftragsposition im Status `HAL` haben. Der Bankbetrag muss dem offenen Betrag (`OrderTotal - PaidByCustomer`, auf 2 Stellen gerundet) in derselben Währung entsprechen, und der Buchungstext (`BankText01`–`BankText03`) muss die externe Auftragsnummer (optional ohne Präfix), die `ccpPayID`, eine eindeutige externe Kundennummer oder eine eindeutige E-Mail-Adresse enthalten.\n - **Rechnungen**, die vollständig unbezahlt sind und deren Zahlungsart `MatchToInvoices = 1` hat. Der Bankbetrag muss der Rechnungssumme entsprechen; der Buchungstext muss Rechnungsnummer, externe Auftragsnummer, Kundennummer oder E-Mail enthalten.\n - Mehrdeutige Kandidaten werden verworfen. Gefundene Treffer werden als Vorabzuordnung (`IsPrematch = 1`) in `BankMatch` geschrieben.\n3. Wurde kein Treffer gefunden, lautet `message` `0 matched orders/invoices found.` gefolgt von einem Zeilenumbruch und dem Statistiktext des Abgleichs (Anzahl Bankzeilen, offene und zugeordnete Aufträge/Rechnungen).\n4. Andernfalls wird der `BankMatch`-Eintrag der Bankzeile dieses Headers gelesen, und alle Vorabzuordnungen dieser Bankzeile werden bestätigt (`IsPrematch` auf 0).\n5. Für den zugeordneten Auftrag werden `OrderNr` und die Differenz `ABS(OrderTotal - PaidByCustomer)` aus `OrderHeader` gelesen:\n - Differenz 0: Alle Auftragspositionen des Auftrags im Status `HAL` werden auf `ANG` gesetzt (Bearbeiter `IPN_API (payments)`); Meldung `Delta: 0; releasing order: {OrderNr}`.\n - Sonst: Meldung `Delta: {Delta}; cannot release order:{OrderNr}`; der Auftrag bleibt angehalten.\n6. Sofern nicht `SuppressOutput = 1`, wird eine Zeile mit `OrderHeaderKey`, `OrderNr`, `AmountMatched`, `BankLineKey` und `message` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BankHeaderKey` | int | Nein | Schlüssel des Bank-Headers, dessen Bankzeilen abgeglichen werden. Faktisch Pflicht; fehlt er, wird eine Fehlerzeile geliefert. |\n| `SuppressOutput` | bit | Nein | Unterdrückt die Ergebniszeile nach der Verarbeitung. NULL wird als 0 behandelt. Die Fehlerzeile bei fehlendem `BankHeaderKey` wird immer geliefert. |\n\n- **Eine Bankzeile pro Header erwartet:** Die Bankzeile wird über eine Unterabfrage auf `BankLines` mit Filter `BankHeaderRef` ermittelt. Hat der Bank-Header mehrere Bankzeilen und wurde ein Treffer gefunden, löst SQL Server Fehler 512 aus (Unterabfrage liefert mehr als einen Wert), zurückgegeben als `SqlMessage`. Zu diesem Zeitpunkt sind die Vorabzuordnungen bereits in `BankMatch` geschrieben. Der Aufruf ist für Header mit genau einer Zeile gedacht (z. B. eine Zahlungsbenachrichtigung pro Header, Bearbeiter `IPN_API`).\n- **Keine Transaktion:** Abgleich, Bestätigung und Auftragsfreigabe laufen als getrennte Schritte. Ein Fehler in einem späteren Schritt macht frühere Schritte nicht rückgängig.\n- Der `BankMatch`-Eintrag wird ohne Filter auf `IsPrematch` gelesen; existieren mehrere Einträge für die Bankzeile, wird ein beliebiger geliefert.\n- Betrifft der Treffer eine Rechnung statt eines Auftrags, sind `OrderHeaderKey` und `OrderNr` NULL, es wird kein Auftrag freigegeben und `message` ist NULL (Verkettung mit NULL).\n- Wird trotz Treffer keine `BankMatch`-Zeile gefunden (`BankLineKey` NULL), läuft die Bestätigung in ihren Massenzweig und bestätigt bis zu 100 beliebige Vorabzuordnungen aller Bankzeilen.\n- Ob `PaidByCustomer` bei der Differenzberechnung bereits aktualisiert ist, hängt von Logik ab, die im Code nicht sichtbar ist (z. B. Trigger auf `BankMatch`).\n- Das Abgleichsverhalten wird durch die Einstellungen `AutomatchBanklines_Enforce_CustomerNrExternal` (Auftrags-/Rechnungsnummer muss zusätzlich mit Kundennummer vorkommen, außer bei `0`) und `AutomatchBanklinesStrictOrderNrExternalMatchOnly` (`1` deaktiviert den Abgleich über die externe Auftragsnummer ohne Präfix) beeinflusst. Auftragsnummern ohne Präfix werden erst ab 5 Zeichen verwendet.\n- Lesezugriffe erfolgen mit `NOLOCK`; nicht festgeschriebene Daten können berücksichtigt werden.\n- Schlägt die Auftragsfreigabe fehl, wird der Fehler in `LogTable` protokolliert und erneut ausgelöst.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAutoMatchPayments"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ordnet die Bankzeilen eines Bank-Headers automatisch offenen Aufträgen oder Rechnungen zu, bestätigt die Zuordnung und gibt den Auftrag bei vollständiger Zahlung frei.\n\nFührt den automatischen Zahlungsabgleich für einen Bank-Header (`BankHeaderKey`) aus und bestätigt bei einem Treffer die Zuordnung; anschließend wird versucht, den zugeordneten Auftrag freizugeben.\n\n1. Ist `BankHeaderKey` NULL, wird eine Zeile mit NULL-Werten und der Meldung `Parameter BankHeaderKey is mandatory!` geliefert; sonst passiert nichts.\n2. Der interne automatische Abgleich (`Pixi_BankAutomaticMatching`) läuft für alle Bankzeilen dieses Headers, die noch keinen Eintrag in `BankMatch` haben. Gesucht werden 100%-Treffer:\n - **Aufträge**, deren Zahlungsart einen Abgleich erlaubt (`Payments.MatchToOrders = 1`) und die mindestens eine Auftragsposition im Status `HAL` haben. Der Bankbetrag muss dem offenen Betrag (`OrderTotal - PaidByCustomer`, auf 2 Stellen gerundet) in derselben Währung entsprechen, und der Buchungstext (`BankText01`–`BankText03`) muss die externe Auftragsnummer (optional ohne Präfix), die `ccpPayID`, eine eindeutige externe Kundennummer oder eine eindeutige E-Mail-Adresse enthalten.\n - **Rechnungen**, die vollständig unbezahlt sind und deren Zahlungsart `MatchToInvoices = 1` hat. Der Bankbetrag muss der Rechnungssumme entsprechen; der Buchungstext muss Rechnungsnummer, externe Auftragsnummer, Kundennummer oder E-Mail enthalten.\n - Mehrdeutige Kandidaten werden verworfen. Gefundene Treffer werden als Vorabzuordnung (`IsPrematch = 1`) in `BankMatch` geschrieben.\n3. Wurde kein Treffer gefunden, lautet `message` `0 matched orders/invoices found.` gefolgt von einem Zeilenumbruch und dem Statistiktext des Abgleichs (Anzahl Bankzeilen, offene und zugeordnete Aufträge/Rechnungen).\n4. Andernfalls wird der `BankMatch`-Eintrag der Bankzeile dieses Headers gelesen, und alle Vorabzuordnungen dieser Bankzeile werden bestätigt (`IsPrematch` auf 0).\n5. Für den zugeordneten Auftrag werden `OrderNr` und die Differenz `ABS(OrderTotal - PaidByCustomer)` aus `OrderHeader` gelesen:\n - Differenz 0: Alle Auftragspositionen des Auftrags im Status `HAL` werden auf `ANG` gesetzt (Bearbeiter `IPN_API (payments)`); Meldung `Delta: 0; releasing order: {OrderNr}`.\n - Sonst: Meldung `Delta: {Delta}; cannot release order:{OrderNr}`; der Auftrag bleibt angehalten.\n6. Sofern nicht `SuppressOutput = 1`, wird eine Zeile mit `OrderHeaderKey`, `OrderNr`, `AmountMatched`, `BankLineKey` und `message` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BankHeaderKey` | int | Nein | Schlüssel des Bank-Headers, dessen Bankzeilen abgeglichen werden. Faktisch Pflicht; fehlt er, wird eine Fehlerzeile geliefert. |\n| `SuppressOutput` | bit | Nein | Unterdrückt die Ergebniszeile nach der Verarbeitung. NULL wird als 0 behandelt. Die Fehlerzeile bei fehlendem `BankHeaderKey` wird immer geliefert. |\n\n- **Eine Bankzeile pro Header erwartet:** Die Bankzeile wird über eine Unterabfrage auf `BankLines` mit Filter `BankHeaderRef` ermittelt. Hat der Bank-Header mehrere Bankzeilen und wurde ein Treffer gefunden, löst SQL Server Fehler 512 aus (Unterabfrage liefert mehr als einen Wert), zurückgegeben als `SqlMessage`. Zu diesem Zeitpunkt sind die Vorabzuordnungen bereits in `BankMatch` geschrieben. Der Aufruf ist für Header mit genau einer Zeile gedacht (z. B. eine Zahlungsbenachrichtigung pro Header, Bearbeiter `IPN_API`).\n- **Keine Transaktion:** Abgleich, Bestätigung und Auftragsfreigabe laufen als getrennte Schritte. Ein Fehler in einem späteren Schritt macht frühere Schritte nicht rückgängig.\n- Der `BankMatch`-Eintrag wird ohne Filter auf `IsPrematch` gelesen; existieren mehrere Einträge für die Bankzeile, wird ein beliebiger geliefert.\n- Betrifft der Treffer eine Rechnung statt eines Auftrags, sind `OrderHeaderKey` und `OrderNr` NULL, es wird kein Auftrag freigegeben und `message` ist NULL (Verkettung mit NULL).\n- Wird trotz Treffer keine `BankMatch`-Zeile gefunden (`BankLineKey` NULL), läuft die Bestätigung in ihren Massenzweig und bestätigt bis zu 100 beliebige Vorabzuordnungen aller Bankzeilen.\n- Ob `PaidByCustomer` bei der Differenzberechnung bereits aktualisiert ist, hängt von Logik ab, die im Code nicht sichtbar ist (z. B. Trigger auf `BankMatch`).\n- Das Abgleichsverhalten wird durch die Einstellungen `AutomatchBanklines_Enforce_CustomerNrExternal` (Auftrags-/Rechnungsnummer muss zusätzlich mit Kundennummer vorkommen, außer bei `0`) und `AutomatchBanklinesStrictOrderNrExternalMatchOnly` (`1` deaktiviert den Abgleich über die externe Auftragsnummer ohne Präfix) beeinflusst. Auftragsnummern ohne Präfix werden erst ab 5 Zeichen verwendet.\n- Lesezugriffe erfolgen mit `NOLOCK`; nicht festgeschriebene Daten können berücksichtigt werden.\n- Schlägt die Auftragsfreigabe fehl, wird der Fehler in `LogTable` protokolliert und erneut ausgelöst.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAutoMatchPayments"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 215873\n 100482\n 59.9000\n 88231\n Delta: 0; releasing order: 100482\n \n"
}
]
},
{
"name": "pixiBanklineExists",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Anzahl der Bankzeilen, die zu den übergebenen Banktexten und optional zum Betrag passen.\n\nPrüft, ob Bankzeilen (`BankLines`) mit den übergebenen Werten bereits vorhanden sind, zum Beispiel vor dem Import eines Kontoauszugs.\n\n- Leere Zeichenketten in `BankText01`, `BankText02` und `BankText03` werden wie `NULL` behandelt.\n- Mindestens einer der drei Textparameter muss gefüllt sein. Sind alle drei leer oder nicht angegeben, findet keine Suche statt; die Ergebniszeile enthält `count` = 0 und in der Spalte `error` eine Meldung.\n- Andernfalls werden alle Bankzeilen gezählt, bei denen jeder **angegebene** Parameter exakt mit der gleichnamigen Spalte übereinstimmt (`=`-Vergleich, kein `LIKE`). Nicht angegebene Parameter schränken die Suche nicht ein.\n- `BankAmount` ist optional und wird exakt mit `BankAmount` verglichen.\n\nDer Aufruf liefert immer genau eine Zeile mit der Anzahl, einem Meldungstext und einem Fehlertext (oder `NULL`).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BankText01` | varchar(1024) | Nein | Erster Banktext, nach dem gesucht wird (exakter Vergleich mit `BankText01`). Eine leere Zeichenkette gilt als nicht angegeben. Mindestens einer der drei Textparameter ist erforderlich. |\n| `BankText02` | varchar(1024) | Nein | Zweiter Banktext, nach dem gesucht wird (exakter Vergleich mit `BankText02`). Eine leere Zeichenkette gilt als nicht angegeben. |\n| `BankText03` | varchar(1024) | Nein | Dritter Banktext, nach dem gesucht wird (exakter Vergleich mit `BankText03`). Eine leere Zeichenkette gilt als nicht angegeben. |\n| `BankAmount` | money | Nein | Optionaler Betrag der Bankzeile (exakter Vergleich mit `BankAmount`). Wird er nicht angegeben, wird nicht nach Betrag gefiltert. |\n\n- Fehler werden nicht als SQL-Fehler ausgelöst. Die Spalte `error` ist zu prüfen: Ist sie nicht `NULL`, waren die Parameter ungültig. In diesem Fall lautet `message` trotzdem `No bankline was found.`.\n- Stolperfalle: Ein nicht angegebener Parameter wird durch die Spalte selbst ersetzt (`ISNULL(@Param, Spalte)`). Bankzeilen, bei denen eine der Spalten `BankText01`, `BankText02`, `BankText03` oder `BankAmount` `NULL` ist, werden daher **nie** gezählt, auch wenn der betreffende Parameter nicht übergeben wurde.\n- Der Textvergleich verwendet die Sortierung der Datenbank (meist ohne Beachtung der Groß-/Kleinschreibung). Nachgestellte Leerzeichen werden beim Vergleich ignoriert, führende nicht.\n- Die Abfrage liest ohne `NOLOCK`. Es gibt keine Seiteneffekte.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiBanklineExists"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Anzahl der Bankzeilen, die zu den übergebenen Banktexten und optional zum Betrag passen.\n\nPrüft, ob Bankzeilen (`BankLines`) mit den übergebenen Werten bereits vorhanden sind, zum Beispiel vor dem Import eines Kontoauszugs.\n\n- Leere Zeichenketten in `BankText01`, `BankText02` und `BankText03` werden wie `NULL` behandelt.\n- Mindestens einer der drei Textparameter muss gefüllt sein. Sind alle drei leer oder nicht angegeben, findet keine Suche statt; die Ergebniszeile enthält `count` = 0 und in der Spalte `error` eine Meldung.\n- Andernfalls werden alle Bankzeilen gezählt, bei denen jeder **angegebene** Parameter exakt mit der gleichnamigen Spalte übereinstimmt (`=`-Vergleich, kein `LIKE`). Nicht angegebene Parameter schränken die Suche nicht ein.\n- `BankAmount` ist optional und wird exakt mit `BankAmount` verglichen.\n\nDer Aufruf liefert immer genau eine Zeile mit der Anzahl, einem Meldungstext und einem Fehlertext (oder `NULL`).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BankText01` | varchar(1024) | Nein | Erster Banktext, nach dem gesucht wird (exakter Vergleich mit `BankText01`). Eine leere Zeichenkette gilt als nicht angegeben. Mindestens einer der drei Textparameter ist erforderlich. |\n| `BankText02` | varchar(1024) | Nein | Zweiter Banktext, nach dem gesucht wird (exakter Vergleich mit `BankText02`). Eine leere Zeichenkette gilt als nicht angegeben. |\n| `BankText03` | varchar(1024) | Nein | Dritter Banktext, nach dem gesucht wird (exakter Vergleich mit `BankText03`). Eine leere Zeichenkette gilt als nicht angegeben. |\n| `BankAmount` | money | Nein | Optionaler Betrag der Bankzeile (exakter Vergleich mit `BankAmount`). Wird er nicht angegeben, wird nicht nach Betrag gefiltert. |\n\n- Fehler werden nicht als SQL-Fehler ausgelöst. Die Spalte `error` ist zu prüfen: Ist sie nicht `NULL`, waren die Parameter ungültig. In diesem Fall lautet `message` trotzdem `No bankline was found.`.\n- Stolperfalle: Ein nicht angegebener Parameter wird durch die Spalte selbst ersetzt (`ISNULL(@Param, Spalte)`). Bankzeilen, bei denen eine der Spalten `BankText01`, `BankText02`, `BankText03` oder `BankAmount` `NULL` ist, werden daher **nie** gezählt, auch wenn der betreffende Parameter nicht übergeben wurde.\n- Der Textvergleich verwendet die Sortierung der Datenbank (meist ohne Beachtung der Groß-/Kleinschreibung). Nachgestellte Leerzeichen werden beim Vergleich ignoriert, führende nicht.\n- Die Abfrage liest ohne `NOLOCK`. Es gibt keine Seiteneffekte.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiBanklineExists"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n Bankline/s exist.\n \n"
}
]
},
{
"name": "pixiCACreateManualBooking",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10234\n MPY\n 49.90\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine manuelle Buchung im Kundenkonto an und gleicht sie optional mit einem vorhandenen Kontoeintrag oder einer Rechnung ab.\n\nLegt eine manuelle Buchung (zum Beispiel eine manuelle Zahlung oder eine Korrektur) im Kundenkonto des Kunden `CustKey` an.\n\nAblauf:\n\n1. `EventDate` wird auf das aktuelle Datum mit Uhrzeit gesetzt, wenn kein Wert übergeben wird.\n2. Ist `MatchToInvoiceNr` gesetzt, wird der neueste Kundenkontoeintrag (`MAX(CustomerAccountKey)`) gesucht, der sich auf diese Rechnung bezieht. Die Rechnung muss zu `CustKey` gehören. Der gefundene Schlüssel ersetzt einen in `MatchKey` übergebenen Wert. Wird kein Eintrag gefunden, wird ein Fehler zurückgegeben.\n3. `EventID` muss in den Ereignisdefinitionen des Kundenkontos existieren und als manuell gekennzeichnet sein (`IsManual = 1`).\n4. `EventDate` darf nicht in der Zukunft liegen.\n5. Wird `CurrencyId` nicht übergeben, wird die Basiswährung des Shops verwendet, zu dem der Kunde gehört.\n6. Die Buchung wird mit dem Benutzernamen `API` angelegt. Der Wechselkurs wird automatisch anhand von Shop, Währung und `EventDate` ermittelt.\n7. Ist ein Abgleichsschlüssel bekannt (aus `MatchToInvoiceNr` oder `MatchKey`), wird der neue Eintrag mit diesem Eintrag abgeglichen. Der Abgleich erfolgt nur, wenn beide Einträge noch einen offenen Betrag haben, die Vorzeichen der beiden Einträge entgegengesetzt sind, `Amount` nicht 0 ist und der Betrag des Zieleintrags nicht 0 ist. Abgeglichen wird der kleinere der beiden offenen Beträge.\n\nDer gesamte Aufruf läuft in einer Transaktion. Zurückgegeben wird eine Zeile mit `ReturnCode` = `OK` bei Erfolg oder `ERROR` mit dem Fehlertext.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Ja | Schlüssel des Kunden, in dessen Kundenkonto gebucht wird. |\n| `EventID` | varchar(3) | Ja | ID des zu buchenden Kundenkonto-Ereignisses. Das Ereignis muss existieren und als manuell gekennzeichnet sein. |\n| `Amount` | money | Ja | Betrag der Buchung. |\n| `EventDate` | datetime | Nein | Datum und Uhrzeit der Buchung. Darf nicht in der Zukunft liegen. Bei `NULL` wird das aktuelle Datum mit Uhrzeit verwendet. |\n| `Comment` | varchar(512) | Nein | Kommentar, der als Referenz der Buchung gespeichert wird. `NULL` wird als Leerstring gespeichert. |\n| `MatchToInvoiceNr` | varchar(20) | Nein | Nummer einer Rechnung dieses Kunden. Die neue Buchung wird mit dem neuesten Kontoeintrag dieser Rechnung abgeglichen. Hat Vorrang vor `MatchKey`. |\n| `MatchKey` | int | Nein | Schlüssel des Kundenkontoeintrags (`CustomerAccountKey`), mit dem die neue Buchung abgeglichen wird. Wird ignoriert, wenn `MatchToInvoiceNr` gesetzt ist. |\n| `CurrencyId` | smallint | Nein | Währung der Buchung. Bei `NULL` wird die Basiswährung des Shops des Kunden verwendet. |\n\n- Validierungsfehler und Fehler bei der Wechselkursermittlung setzen die Transaktion zurück und liefern eine `ERROR`-Zeile.\n- Fehler beim Einfügen oder beim Abgleich innerhalb der internen Buchungsprozedur werden dort abgefangen und nicht weitergegeben. In diesem Fall kann der Aufruf trotzdem `OK` liefern, obwohl keine Buchung angelegt wurde. Bei Bedarf sollte das Kundenkonto anschließend geprüft werden.\n- Der Kundenkontoeintrag zur neuen Buchung wird über `ManualBookingRef` gelesen. Er wird vermutlich durch Logik an der Tabelle der manuellen Buchungen erzeugt, die hier nicht sichtbar ist.\n- Die Wechselkursermittlung (`pixi.GetExchRateID`) und die Abgleichsprozedur (`Pixi_CA_InsertMatch`) liegen nicht vor; ihr genaues Verhalten ist unbekannt.\n- Bei `MatchKey` wird nicht geprüft, ob der Eintrag zum Kunden gehört. `MatchToInvoiceNr` wird geprüft und ist daher vorzuziehen.\n- `CustKey` wird nicht ausdrücklich geprüft. Bei einem unbekannten Kunden bleibt `CurrencyId` `NULL`, wenn kein Wert übergeben wird.\n- Der Fehlertext für ein Datum in der Zukunft spricht von einem \"paid date\"; gemeint ist `EventDate`.\n- Abfragen verwenden `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCACreateManualBooking"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10234\n MPY\n 49.90\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine manuelle Buchung im Kundenkonto an und gleicht sie optional mit einem vorhandenen Kontoeintrag oder einer Rechnung ab.\n\nLegt eine manuelle Buchung (zum Beispiel eine manuelle Zahlung oder eine Korrektur) im Kundenkonto des Kunden `CustKey` an.\n\nAblauf:\n\n1. `EventDate` wird auf das aktuelle Datum mit Uhrzeit gesetzt, wenn kein Wert übergeben wird.\n2. Ist `MatchToInvoiceNr` gesetzt, wird der neueste Kundenkontoeintrag (`MAX(CustomerAccountKey)`) gesucht, der sich auf diese Rechnung bezieht. Die Rechnung muss zu `CustKey` gehören. Der gefundene Schlüssel ersetzt einen in `MatchKey` übergebenen Wert. Wird kein Eintrag gefunden, wird ein Fehler zurückgegeben.\n3. `EventID` muss in den Ereignisdefinitionen des Kundenkontos existieren und als manuell gekennzeichnet sein (`IsManual = 1`).\n4. `EventDate` darf nicht in der Zukunft liegen.\n5. Wird `CurrencyId` nicht übergeben, wird die Basiswährung des Shops verwendet, zu dem der Kunde gehört.\n6. Die Buchung wird mit dem Benutzernamen `API` angelegt. Der Wechselkurs wird automatisch anhand von Shop, Währung und `EventDate` ermittelt.\n7. Ist ein Abgleichsschlüssel bekannt (aus `MatchToInvoiceNr` oder `MatchKey`), wird der neue Eintrag mit diesem Eintrag abgeglichen. Der Abgleich erfolgt nur, wenn beide Einträge noch einen offenen Betrag haben, die Vorzeichen der beiden Einträge entgegengesetzt sind, `Amount` nicht 0 ist und der Betrag des Zieleintrags nicht 0 ist. Abgeglichen wird der kleinere der beiden offenen Beträge.\n\nDer gesamte Aufruf läuft in einer Transaktion. Zurückgegeben wird eine Zeile mit `ReturnCode` = `OK` bei Erfolg oder `ERROR` mit dem Fehlertext.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustKey` | int | Ja | Schlüssel des Kunden, in dessen Kundenkonto gebucht wird. |\n| `EventID` | varchar(3) | Ja | ID des zu buchenden Kundenkonto-Ereignisses. Das Ereignis muss existieren und als manuell gekennzeichnet sein. |\n| `Amount` | money | Ja | Betrag der Buchung. |\n| `EventDate` | datetime | Nein | Datum und Uhrzeit der Buchung. Darf nicht in der Zukunft liegen. Bei `NULL` wird das aktuelle Datum mit Uhrzeit verwendet. |\n| `Comment` | varchar(512) | Nein | Kommentar, der als Referenz der Buchung gespeichert wird. `NULL` wird als Leerstring gespeichert. |\n| `MatchToInvoiceNr` | varchar(20) | Nein | Nummer einer Rechnung dieses Kunden. Die neue Buchung wird mit dem neuesten Kontoeintrag dieser Rechnung abgeglichen. Hat Vorrang vor `MatchKey`. |\n| `MatchKey` | int | Nein | Schlüssel des Kundenkontoeintrags (`CustomerAccountKey`), mit dem die neue Buchung abgeglichen wird. Wird ignoriert, wenn `MatchToInvoiceNr` gesetzt ist. |\n| `CurrencyId` | smallint | Nein | Währung der Buchung. Bei `NULL` wird die Basiswährung des Shops des Kunden verwendet. |\n\n- Validierungsfehler und Fehler bei der Wechselkursermittlung setzen die Transaktion zurück und liefern eine `ERROR`-Zeile.\n- Fehler beim Einfügen oder beim Abgleich innerhalb der internen Buchungsprozedur werden dort abgefangen und nicht weitergegeben. In diesem Fall kann der Aufruf trotzdem `OK` liefern, obwohl keine Buchung angelegt wurde. Bei Bedarf sollte das Kundenkonto anschließend geprüft werden.\n- Der Kundenkontoeintrag zur neuen Buchung wird über `ManualBookingRef` gelesen. Er wird vermutlich durch Logik an der Tabelle der manuellen Buchungen erzeugt, die hier nicht sichtbar ist.\n- Die Wechselkursermittlung (`pixi.GetExchRateID`) und die Abgleichsprozedur (`Pixi_CA_InsertMatch`) liegen nicht vor; ihr genaues Verhalten ist unbekannt.\n- Bei `MatchKey` wird nicht geprüft, ob der Eintrag zum Kunden gehört. `MatchToInvoiceNr` wird geprüft und ist daher vorzuziehen.\n- `CustKey` wird nicht ausdrücklich geprüft. Bei einem unbekannten Kunden bleibt `CurrencyId` `NULL`, wenn kein Wert übergeben wird.\n- Der Fehlertext für ein Datum in der Zukunft spricht von einem \"paid date\"; gemeint ist `EventDate`.\n- Abfragen verwenden `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCACreateManualBooking"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n Event successfully added to customer account\n \n"
}
]
},
{
"name": "pixiCADeleteEvent",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht ein Kundenkonto-Ereignis (CustomerAccount-Eintrag) samt Rechnung, Bankzuordnungen und Kontozuordnungen, sofern das Löschen erlaubt ist.\n\nLöscht ein Ereignis aus dem Kundenkonto (`CustomerAccount`), identifiziert über den Schlüssel `CAref`.\n\nAblauf:\n1. Der gemeinsame API-Envelope prüft die Aufrufhäufigkeit. Ist das Limit überschritten, wird eine Zeile `ResultCode`/`ResultText` mit Code `502` geliefert, und es passiert nichts weiter.\n2. Ist `CAref` NULL, wird eine Zeile mit `ReturnCode = 'ERROR'` geliefert.\n3. Andernfalls läuft die interne Prozedur `Pixi_CA_DeleteEvent` mit dem Benutzernamen `API` in einer Transaktion:\n - Die Funktion `fPixi_CA_canIdeleteEvent` entscheidet, ob das Ereignis gelöscht werden darf. Falls nicht, wird nichts geändert und `Success = 0` geliefert.\n - Ist eine Rechnung verknüpft (`InvoiceRef`), wird diese über `Pixi_DeleteInvoice` gelöscht.\n - Bankzuordnungen (`BankMatch`) der verknüpften Bankzeile (`BanklineRef`) werden gelöscht.\n - `UpdateEmp`/`UpdateDate` werden am Ereignis und an allen `CustomerAccountMatch`-Zeilen gesetzt, in denen das Ereignis als `CAref1` oder `CAref2` vorkommt. Diese Zuordnungen werden anschließend gelöscht.\n - Die `CustomerAccount`-Zeile selbst wird gelöscht.\n - Danach versucht der Code, einen verknüpften `DTAUS`-Datensatz (nur wenn dessen Status das Löschen erlaubt) bzw. eine verknüpfte manuelle Buchung (`CustomerAccountManualBookings`) zu entfernen.\n4. Eine Zeile mit `Success` (1 = gelöscht, 0 = nicht gelöscht) und `ErrorMessage` wird geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CAref` | int | Ja | Schlüssel des zu löschenden Kundenkonto-Ereignisses (`CustomerAccount.CustomerAccountKey`). Darf nicht NULL sein. |\n| `ResultCode` | char(3) | Nein | Ausgabe: Ergebniscode des API-Envelopes, `200` bei normaler Ausführung, `502` bei Überschreitung des Aufruflimits. |\n| `ResultText` | varchar(1024) | Nein | Ausgabe: Ergebnistext des API-Envelopes, `OK` oder die Meldung zum Aufruflimit. |\n\n- Alle Änderungen laufen in einer Transaktion; bei einem Fehler wird zurückgerollt, der Fehler per `RAISERROR` (Schweregrad 16, als `SqlMessage`) erneut ausgelöst und trotzdem eine Zeile mit `Success = 0` und dem Fehlertext geliefert.\n- Die Regeln von `fPixi_CA_canIdeleteEvent` und das Verhalten von `Pixi_DeleteInvoice` liegen nicht vor; welche Ereignisse löschbar sind und ob das Löschen der Rechnung zusätzliche Ergebnismengen liefert, ist aus diesem Code nicht ersichtlich.\n- Die Ermittlung des verknüpften `DTAUS`-Datensatzes und der manuellen Buchung liest `DTAUSref`/`ManualBookingRef` aus `CustomerAccount`, **nachdem** diese Zeile bereits gelöscht wurde; die Unterabfragen finden daher praktisch nichts. Laut Code-Kommentar übernimmt ein Trigger das Löschen aus `DTAUS` und `CustomerAccountManualBookings`; dieser Trigger liegt nicht vor.\n- Ist das Löschen nicht erlaubt, erzeugt die interne Prozedur nur ein `PRINT` ('Event CANNOT Be Deleted'), das nicht als Zeile sichtbar ist; maßgeblich ist `Success = 0`.\n- Die Ausgabeparameter `ResultCode`/`ResultText` enthalten das Envelope-Ergebnis (`200`/`OK` bei normaler Ausführung).\n- Lesezugriffe mit `NOLOCK`, Schreibzugriffe mit `ROWLOCK`. Jeder Aufruf aktualisiert `API_STATISTICS`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCADeleteEvent"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht ein Kundenkonto-Ereignis (CustomerAccount-Eintrag) samt Rechnung, Bankzuordnungen und Kontozuordnungen, sofern das Löschen erlaubt ist.\n\nLöscht ein Ereignis aus dem Kundenkonto (`CustomerAccount`), identifiziert über den Schlüssel `CAref`.\n\nAblauf:\n1. Der gemeinsame API-Envelope prüft die Aufrufhäufigkeit. Ist das Limit überschritten, wird eine Zeile `ResultCode`/`ResultText` mit Code `502` geliefert, und es passiert nichts weiter.\n2. Ist `CAref` NULL, wird eine Zeile mit `ReturnCode = 'ERROR'` geliefert.\n3. Andernfalls läuft die interne Prozedur `Pixi_CA_DeleteEvent` mit dem Benutzernamen `API` in einer Transaktion:\n - Die Funktion `fPixi_CA_canIdeleteEvent` entscheidet, ob das Ereignis gelöscht werden darf. Falls nicht, wird nichts geändert und `Success = 0` geliefert.\n - Ist eine Rechnung verknüpft (`InvoiceRef`), wird diese über `Pixi_DeleteInvoice` gelöscht.\n - Bankzuordnungen (`BankMatch`) der verknüpften Bankzeile (`BanklineRef`) werden gelöscht.\n - `UpdateEmp`/`UpdateDate` werden am Ereignis und an allen `CustomerAccountMatch`-Zeilen gesetzt, in denen das Ereignis als `CAref1` oder `CAref2` vorkommt. Diese Zuordnungen werden anschließend gelöscht.\n - Die `CustomerAccount`-Zeile selbst wird gelöscht.\n - Danach versucht der Code, einen verknüpften `DTAUS`-Datensatz (nur wenn dessen Status das Löschen erlaubt) bzw. eine verknüpfte manuelle Buchung (`CustomerAccountManualBookings`) zu entfernen.\n4. Eine Zeile mit `Success` (1 = gelöscht, 0 = nicht gelöscht) und `ErrorMessage` wird geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CAref` | int | Ja | Schlüssel des zu löschenden Kundenkonto-Ereignisses (`CustomerAccount.CustomerAccountKey`). Darf nicht NULL sein. |\n| `ResultCode` | char(3) | Nein | Ausgabe: Ergebniscode des API-Envelopes, `200` bei normaler Ausführung, `502` bei Überschreitung des Aufruflimits. |\n| `ResultText` | varchar(1024) | Nein | Ausgabe: Ergebnistext des API-Envelopes, `OK` oder die Meldung zum Aufruflimit. |\n\n- Alle Änderungen laufen in einer Transaktion; bei einem Fehler wird zurückgerollt, der Fehler per `RAISERROR` (Schweregrad 16, als `SqlMessage`) erneut ausgelöst und trotzdem eine Zeile mit `Success = 0` und dem Fehlertext geliefert.\n- Die Regeln von `fPixi_CA_canIdeleteEvent` und das Verhalten von `Pixi_DeleteInvoice` liegen nicht vor; welche Ereignisse löschbar sind und ob das Löschen der Rechnung zusätzliche Ergebnismengen liefert, ist aus diesem Code nicht ersichtlich.\n- Die Ermittlung des verknüpften `DTAUS`-Datensatzes und der manuellen Buchung liest `DTAUSref`/`ManualBookingRef` aus `CustomerAccount`, **nachdem** diese Zeile bereits gelöscht wurde; die Unterabfragen finden daher praktisch nichts. Laut Code-Kommentar übernimmt ein Trigger das Löschen aus `DTAUS` und `CustomerAccountManualBookings`; dieser Trigger liegt nicht vor.\n- Ist das Löschen nicht erlaubt, erzeugt die interne Prozedur nur ein `PRINT` ('Event CANNOT Be Deleted'), das nicht als Zeile sichtbar ist; maßgeblich ist `Success = 0`.\n- Die Ausgabeparameter `ResultCode`/`ResultText` enthalten das Envelope-Ergebnis (`200`/`OK` bei normaler Ausführung).\n- Lesezugriffe mit `NOLOCK`, Schreibzugriffe mit `ROWLOCK`. Jeder Aufruf aktualisiert `API_STATISTICS`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCADeleteEvent"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n \n \n"
}
]
},
{
"name": "pixiCADeleteEventMatches",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht alle Kundenkonto-Zuordnungen (Matches) eines Kundenkonto-Eintrags (CAref) einschließlich der daraus abgeleiteten Bank-Zuordnungen.\n\nEntfernt alle Zuordnungen, an denen der angegebene Kundenkonto-Eintrag beteiligt ist.\n\n1. Zuerst läuft die gemeinsame API-Hülle. Sie prüft die Aufruffrequenz und protokolliert den Aufrufzeitpunkt. Wird das Limit überschritten, liefert der Aufruf eine Zeile `ResultCode`/`ResultText` mit Code `502` und führt sonst nichts aus.\n2. Ist `CAref` gleich `NULL`, wird eine Zeile mit `ReturnCode` = `ERROR` geliefert und nichts gelöscht.\n3. Andernfalls ermittelt die Prozedur alle Datensätze in `CustomerAccountMatch`, bei denen `CAref1` oder `CAref2` dem Wert von `CAref` entspricht. Für jeden Match-Schlüssel geschieht Folgendes:\n - `UpdateDate` wird auf den aktuellen Zeitpunkt und `UpdateEmp` auf `API` gesetzt.\n - Alle `BankMatch`-Zeilen, deren `SourceCustomerAccountMatchKey` auf diese Zuordnung verweist, werden gelöscht.\n - Die Zuordnung selbst wird gelöscht.\n\nBei Erfolg liefert der Aufruf keine Ergebnismenge. Die Ausgabeparameter `ResultCode`/`ResultText` enthalten `200`/`OK`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CAref` | int | Ja | Schlüssel des Kundenkonto-Eintrags. Alle Zuordnungen, in denen er als `CAref1` oder `CAref2` vorkommt, werden gelöscht. |\n| `ResultCode` | char(3) | Nein | Ergebniscode der API-Hülle: `200`, wenn der Aufruf ausgeführt wurde, `502`, wenn das Frequenzlimit überschritten wurde. |\n| `ResultText` | varchar(1024) | Nein | Ergebnistext der API-Hülle: `OK` oder die Meldung zum Frequenzlimit. |\n\n- Jede Zuordnung wird in einer eigenen Transaktion innerhalb von `Pixi_CA_DeleteMatch` gelöscht. Eine übergreifende Transaktion gibt es nicht. Schlägt das Löschen einer Zuordnung fehl, wird nur diese zurückgerollt und der Fehler per `RAISERROR` (Schweregrad 16) erneut ausgelöst. Bereits gelöschte Zuordnungen bleiben gelöscht. Die Schleife läuft mit den übrigen Zuordnungen weiter.\n- Die Liste der Zuordnungen wird mit `NOLOCK` gelesen. Die Löschvorgänge verwenden `ROWLOCK`.\n- Die Aktualisierung von `UpdateDate`/`UpdateEmp` unmittelbar vor dem Löschen dient vermutlich Audit- oder Trigger-Logik. Der Code zeigt dies nicht.\n- Eine Zuordnung wird gefunden, wenn `CAref` auf einer der beiden Seiten steht (`CAref1` oder `CAref2`).\n- Existiert keine Zuordnung zu `CAref`, endet der Aufruf ohne Ergebnis und ohne Fehler.\n- `ResultCode` bleibt `200`, auch wenn die Zeile `CAref cannot be NULL` geliefert wird. Die zurückgegebene Zeile sollte daher ebenfalls ausgewertet werden.\n- Das Frequenzlimit stammt aus `API_CONTROL.MIN_BREATHING_MSEC` für diesen Funktionsnamen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCADeleteEventMatches"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht alle Kundenkonto-Zuordnungen (Matches) eines Kundenkonto-Eintrags (CAref) einschließlich der daraus abgeleiteten Bank-Zuordnungen.\n\nEntfernt alle Zuordnungen, an denen der angegebene Kundenkonto-Eintrag beteiligt ist.\n\n1. Zuerst läuft die gemeinsame API-Hülle. Sie prüft die Aufruffrequenz und protokolliert den Aufrufzeitpunkt. Wird das Limit überschritten, liefert der Aufruf eine Zeile `ResultCode`/`ResultText` mit Code `502` und führt sonst nichts aus.\n2. Ist `CAref` gleich `NULL`, wird eine Zeile mit `ReturnCode` = `ERROR` geliefert und nichts gelöscht.\n3. Andernfalls ermittelt die Prozedur alle Datensätze in `CustomerAccountMatch`, bei denen `CAref1` oder `CAref2` dem Wert von `CAref` entspricht. Für jeden Match-Schlüssel geschieht Folgendes:\n - `UpdateDate` wird auf den aktuellen Zeitpunkt und `UpdateEmp` auf `API` gesetzt.\n - Alle `BankMatch`-Zeilen, deren `SourceCustomerAccountMatchKey` auf diese Zuordnung verweist, werden gelöscht.\n - Die Zuordnung selbst wird gelöscht.\n\nBei Erfolg liefert der Aufruf keine Ergebnismenge. Die Ausgabeparameter `ResultCode`/`ResultText` enthalten `200`/`OK`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CAref` | int | Ja | Schlüssel des Kundenkonto-Eintrags. Alle Zuordnungen, in denen er als `CAref1` oder `CAref2` vorkommt, werden gelöscht. |\n| `ResultCode` | char(3) | Nein | Ergebniscode der API-Hülle: `200`, wenn der Aufruf ausgeführt wurde, `502`, wenn das Frequenzlimit überschritten wurde. |\n| `ResultText` | varchar(1024) | Nein | Ergebnistext der API-Hülle: `OK` oder die Meldung zum Frequenzlimit. |\n\n- Jede Zuordnung wird in einer eigenen Transaktion innerhalb von `Pixi_CA_DeleteMatch` gelöscht. Eine übergreifende Transaktion gibt es nicht. Schlägt das Löschen einer Zuordnung fehl, wird nur diese zurückgerollt und der Fehler per `RAISERROR` (Schweregrad 16) erneut ausgelöst. Bereits gelöschte Zuordnungen bleiben gelöscht. Die Schleife läuft mit den übrigen Zuordnungen weiter.\n- Die Liste der Zuordnungen wird mit `NOLOCK` gelesen. Die Löschvorgänge verwenden `ROWLOCK`.\n- Die Aktualisierung von `UpdateDate`/`UpdateEmp` unmittelbar vor dem Löschen dient vermutlich Audit- oder Trigger-Logik. Der Code zeigt dies nicht.\n- Eine Zuordnung wird gefunden, wenn `CAref` auf einer der beiden Seiten steht (`CAref1` oder `CAref2`).\n- Existiert keine Zuordnung zu `CAref`, endet der Aufruf ohne Ergebnis und ohne Fehler.\n- `ResultCode` bleibt `200`, auch wenn die Zeile `CAref cannot be NULL` geliefert wird. Die zurückgegebene Zeile sollte daher ebenfalls ausgewertet werden.\n- Das Frequenzlimit stammt aus `API_CONTROL.MIN_BREATHING_MSEC` für diesen Funktionsnamen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCADeleteEventMatches"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 502\n (850) Frequency quote exceeded. Next call to this function can be made in ca. 850 milliseconds\n \n"
}
]
},
{
"name": "pixiCAGetEvents",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kundenkonto-Ereignisse (Buchungen), gefiltert nach Ereignistyp, Datum, Betrag, Rechnung, Zahlungsart oder Kunde, optional inklusive gelöschter Ereignisse.\n\nLiest Einträge aus dem Kundenkonto (`CustomerAccount`) zusammen mit dem Währungscode aus `pixi.Currency`.\n\nAlle Filterparameter sind optional und werden mit `AND` verknüpft. Ein Filter wirkt nur, wenn der Parameter nicht `NULL` ist:\n\n- `EventID`: exakter Vergleich auf den Ereignistyp.\n- `CreateDateFrom`/`CreateDateTo`, `UpdateDateFrom`/`UpdateDateTo`, `EventDateFrom`/`EventDateTo`: inklusive Bereiche (`>=` / `<=`) auf `CreateDate`, `UpdateDate` und `EventDate`.\n- `MinAmount`/`MaxAmount`: inklusiver Bereich auf `Amount`.\n- `MinMatchedAmount`/`MaxMatchedAmount`: inklusiver Bereich auf `Matched`.\n- `InvoiceRef`: exakter Vergleich auf die verknüpfte Rechnung.\n- `DoNotRefund`: exakter Vergleich auf das Kennzeichen.\n- `PaymentCode`: verknüpft `Invoices` über `InvoiceRef` und liefert nur Ereignisse, deren Rechnung diese Zahlungsart (`Payment`) hat.\n- `CustRef`: wird nur angewendet, wenn der Wert größer als `0` ist.\n\nBei `ShowDeleted` = `1` werden zusätzlich gelöschte Ereignisse aus der Historientabelle `CustomerAccountLog` (Zeilen mit `HistRemark` = `DELETE`) mit denselben Filtern geliefert. Diese Zeilen haben `IsDeleted` = `1`, aktive Zeilen `IsDeleted` = `0`.\n\nOhne Filter werden alle Kundenkonto-Ereignisse geliefert. Die Ergebnismenge hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `EventID` | varchar(3) | Nein | Ereignistyp, nach dem gefiltert wird (exakter Vergleich). `NULL` = alle Ereignistypen. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusive) für das Anlagedatum. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (inklusive) für das Anlagedatum. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für das Datum der letzten Änderung. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (inklusive) für das Datum der letzten Änderung. |\n| `EventDateFrom` | datetime | Nein | Untergrenze (inklusive) für das Ereignisdatum. |\n| `EventDateTo` | datetime | Nein | Obergrenze (inklusive) für das Ereignisdatum. |\n| `MinAmount` | money | Nein | Mindestwert (inklusive) von `Amount`. |\n| `MaxAmount` | money | Nein | Höchstwert (inklusive) von `Amount`. |\n| `MinMatchedAmount` | money | Nein | Mindestwert (inklusive) des zugeordneten Betrags `Matched`. |\n| `MaxMatchedAmount` | money | Nein | Höchstwert (inklusive) des zugeordneten Betrags `Matched`. |\n| `InvoiceRef` | int | Nein | Rechnungsschlüssel (`InvoiceKey`), mit dem das Ereignis verknüpft ist (exakter Vergleich). |\n| `DoNotRefund` | bit | Nein | Filter auf das Kennzeichen `DoNotRefund`. `NULL` = kein Filter. |\n| `PaymentCode` | char(1) | Nein | Zahlungsartcode der verknüpften Rechnung (`Invoices.Payment`). Es werden nur Ereignisse mit verknüpfter Rechnung dieser Zahlungsart geliefert. |\n| `CustRef` | int | Nein | Kundenschlüssel. Wird nur angewendet, wenn größer als `0`. |\n| `ShowDeleted` | bit | Nein | Legt fest, ob gelöschte Ereignisse aus `CustomerAccountLog` mitgeliefert werden. |\n\n- Die Abfrage wird als dynamisches SQL aufgebaut und mit `sp_executesql` ausgeführt; alle Werte werden als Parameter übergeben.\n- Alle Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können daher erscheinen.\n- Aktive und gelöschte Zeilen werden mit `UNION` (nicht `UNION ALL`) zusammengeführt, vollständig identische Zeilen erscheinen daher nur einmal.\n- Obwohl `Invoices` per `LEFT JOIN` verknüpft wird, schließt der Filter `PaymentCode` alle Ereignisse ohne verknüpfte Rechnung aus.\n- Ereignisse, deren `CurrencyId` keinen Eintrag in `pixi.Currency` hat, werden nicht geliefert (Inner Join).\n- Ohne Filter kann der Aufruf sehr viele Zeilen liefern; eine Einschränkung nach Kunde oder Datum wird empfohlen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCAGetEvents"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kundenkonto-Ereignisse (Buchungen), gefiltert nach Ereignistyp, Datum, Betrag, Rechnung, Zahlungsart oder Kunde, optional inklusive gelöschter Ereignisse.\n\nLiest Einträge aus dem Kundenkonto (`CustomerAccount`) zusammen mit dem Währungscode aus `pixi.Currency`.\n\nAlle Filterparameter sind optional und werden mit `AND` verknüpft. Ein Filter wirkt nur, wenn der Parameter nicht `NULL` ist:\n\n- `EventID`: exakter Vergleich auf den Ereignistyp.\n- `CreateDateFrom`/`CreateDateTo`, `UpdateDateFrom`/`UpdateDateTo`, `EventDateFrom`/`EventDateTo`: inklusive Bereiche (`>=` / `<=`) auf `CreateDate`, `UpdateDate` und `EventDate`.\n- `MinAmount`/`MaxAmount`: inklusiver Bereich auf `Amount`.\n- `MinMatchedAmount`/`MaxMatchedAmount`: inklusiver Bereich auf `Matched`.\n- `InvoiceRef`: exakter Vergleich auf die verknüpfte Rechnung.\n- `DoNotRefund`: exakter Vergleich auf das Kennzeichen.\n- `PaymentCode`: verknüpft `Invoices` über `InvoiceRef` und liefert nur Ereignisse, deren Rechnung diese Zahlungsart (`Payment`) hat.\n- `CustRef`: wird nur angewendet, wenn der Wert größer als `0` ist.\n\nBei `ShowDeleted` = `1` werden zusätzlich gelöschte Ereignisse aus der Historientabelle `CustomerAccountLog` (Zeilen mit `HistRemark` = `DELETE`) mit denselben Filtern geliefert. Diese Zeilen haben `IsDeleted` = `1`, aktive Zeilen `IsDeleted` = `0`.\n\nOhne Filter werden alle Kundenkonto-Ereignisse geliefert. Die Ergebnismenge hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `EventID` | varchar(3) | Nein | Ereignistyp, nach dem gefiltert wird (exakter Vergleich). `NULL` = alle Ereignistypen. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusive) für das Anlagedatum. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (inklusive) für das Anlagedatum. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für das Datum der letzten Änderung. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (inklusive) für das Datum der letzten Änderung. |\n| `EventDateFrom` | datetime | Nein | Untergrenze (inklusive) für das Ereignisdatum. |\n| `EventDateTo` | datetime | Nein | Obergrenze (inklusive) für das Ereignisdatum. |\n| `MinAmount` | money | Nein | Mindestwert (inklusive) von `Amount`. |\n| `MaxAmount` | money | Nein | Höchstwert (inklusive) von `Amount`. |\n| `MinMatchedAmount` | money | Nein | Mindestwert (inklusive) des zugeordneten Betrags `Matched`. |\n| `MaxMatchedAmount` | money | Nein | Höchstwert (inklusive) des zugeordneten Betrags `Matched`. |\n| `InvoiceRef` | int | Nein | Rechnungsschlüssel (`InvoiceKey`), mit dem das Ereignis verknüpft ist (exakter Vergleich). |\n| `DoNotRefund` | bit | Nein | Filter auf das Kennzeichen `DoNotRefund`. `NULL` = kein Filter. |\n| `PaymentCode` | char(1) | Nein | Zahlungsartcode der verknüpften Rechnung (`Invoices.Payment`). Es werden nur Ereignisse mit verknüpfter Rechnung dieser Zahlungsart geliefert. |\n| `CustRef` | int | Nein | Kundenschlüssel. Wird nur angewendet, wenn größer als `0`. |\n| `ShowDeleted` | bit | Nein | Legt fest, ob gelöschte Ereignisse aus `CustomerAccountLog` mitgeliefert werden. |\n\n- Die Abfrage wird als dynamisches SQL aufgebaut und mit `sp_executesql` ausgeführt; alle Werte werden als Parameter übergeben.\n- Alle Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können daher erscheinen.\n- Aktive und gelöschte Zeilen werden mit `UNION` (nicht `UNION ALL`) zusammengeführt, vollständig identische Zeilen erscheinen daher nur einmal.\n- Obwohl `Invoices` per `LEFT JOIN` verknüpft wird, schließt der Filter `PaymentCode` alle Ereignisse ohne verknüpfte Rechnung aus.\n- Ereignisse, deren `CurrencyId` keinen Eintrag in `pixi.Currency` hat, werden nicht geliefert (Inner Join).\n- Ohne Filter kann der Aufruf sehr viele Zeilen liefern; eine Einschränkung nach Kunde oder Datum wird empfohlen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCAGetEvents"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1025\n 4711\n PAY\n 2024-01-15T10:32:00\n Bank transfer 2024-0115\n 149.9000\n 149.9000\n 123456\n 0\n false\n AD\n 2024-01-15T10:32:00\n AD\n 2024-01-15T10:35:00\n \n false\n EUR\n \n"
}
]
},
{
"name": "pixiCAGetInvoiceMatch",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Debitorenkonto-Buchungen, die mit der Debitorenkonto-Buchung einer angegebenen Rechnung ausgeglichen wurden.\n\nErmittelt die Debitorenkonto-Buchung (CA-Eintrag) einer Rechnung und listet alle CA-Einträge auf, die mit ihr ausgeglichen wurden, z. B. Zahlungen oder Gutschriften, die die Rechnung begleichen.\n\n1. Mindestens einer der Parameter `InvoiceKey` oder `InvoiceNr` muss gesetzt sein (der Wert `0` bzw. ein Leerstring gilt als nicht gesetzt). Andernfalls wird ein Fehler ausgelöst.\n2. Ist `InvoiceKey` nicht gesetzt, wird der Schlüssel über `InvoiceNr` aus `Invoices` ermittelt.\n3. Der CA-Eintrag, dessen `InvoiceRef` dem Rechnungsschlüssel entspricht, wird bestimmt.\n4. Alle Ausgleichsdatensätze in `CustomerAccountMatch`, in denen dieser CA-Eintrag auf einer der beiden Seiten (`CAref1` oder `CAref2`) steht, werden gelesen, und die jeweiligen **Gegenbuchungen** werden zurückgegeben. Ein Ausgleichsdatensatz, der den Rechnungseintrag auf beiden Seiten referenziert (Selbstausgleich), liefert den Rechnungseintrag selbst.\n5. Der Währungscode stammt aus `pixi.Currency` über die Währungs-ID der Buchung.\n\nDas Ergebnis hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceKey` | int | Nein | Interner Schlüssel der Rechnung. Hat Vorrang vor `InvoiceNr`. `0` oder NULL bedeutet nicht gesetzt. |\n| `InvoiceNr` | varchar(20) | Nein | Rechnungsnummer. Wird zur Ermittlung des Rechnungsschlüssels verwendet, wenn `InvoiceKey` nicht gesetzt ist. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; es können nicht festgeschriebene Daten geliefert werden.\n- Die Spalte `InvoiceNr` gibt nur den Eingabeparameter zurück. Wird nur `InvoiceKey` übergeben, ist `InvoiceNr` im Ergebnis leer (NULL).\n- Werden beide Parameter übergeben, wird `InvoiceKey` verwendet; `InvoiceNr` wird nicht dagegen geprüft.\n- Wird keine Rechnung oder kein CA-Eintrag zur Rechnung gefunden, wird eine leere Ergebnismenge ohne Fehler geliefert.\n- Verweisen mehrere CA-Einträge auf dieselbe Rechnung, wird nur einer davon (nicht deterministisch) verwendet.\n- Der Kopfkommentar der Prozedur (\"show all CA Events and Statistics for a selected customer\") entspricht nicht dem tatsächlichen Verhalten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCAGetInvoiceMatch"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Debitorenkonto-Buchungen, die mit der Debitorenkonto-Buchung einer angegebenen Rechnung ausgeglichen wurden.\n\nErmittelt die Debitorenkonto-Buchung (CA-Eintrag) einer Rechnung und listet alle CA-Einträge auf, die mit ihr ausgeglichen wurden, z. B. Zahlungen oder Gutschriften, die die Rechnung begleichen.\n\n1. Mindestens einer der Parameter `InvoiceKey` oder `InvoiceNr` muss gesetzt sein (der Wert `0` bzw. ein Leerstring gilt als nicht gesetzt). Andernfalls wird ein Fehler ausgelöst.\n2. Ist `InvoiceKey` nicht gesetzt, wird der Schlüssel über `InvoiceNr` aus `Invoices` ermittelt.\n3. Der CA-Eintrag, dessen `InvoiceRef` dem Rechnungsschlüssel entspricht, wird bestimmt.\n4. Alle Ausgleichsdatensätze in `CustomerAccountMatch`, in denen dieser CA-Eintrag auf einer der beiden Seiten (`CAref1` oder `CAref2`) steht, werden gelesen, und die jeweiligen **Gegenbuchungen** werden zurückgegeben. Ein Ausgleichsdatensatz, der den Rechnungseintrag auf beiden Seiten referenziert (Selbstausgleich), liefert den Rechnungseintrag selbst.\n5. Der Währungscode stammt aus `pixi.Currency` über die Währungs-ID der Buchung.\n\nDas Ergebnis hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceKey` | int | Nein | Interner Schlüssel der Rechnung. Hat Vorrang vor `InvoiceNr`. `0` oder NULL bedeutet nicht gesetzt. |\n| `InvoiceNr` | varchar(20) | Nein | Rechnungsnummer. Wird zur Ermittlung des Rechnungsschlüssels verwendet, wenn `InvoiceKey` nicht gesetzt ist. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; es können nicht festgeschriebene Daten geliefert werden.\n- Die Spalte `InvoiceNr` gibt nur den Eingabeparameter zurück. Wird nur `InvoiceKey` übergeben, ist `InvoiceNr` im Ergebnis leer (NULL).\n- Werden beide Parameter übergeben, wird `InvoiceKey` verwendet; `InvoiceNr` wird nicht dagegen geprüft.\n- Wird keine Rechnung oder kein CA-Eintrag zur Rechnung gefunden, wird eine leere Ergebnismenge ohne Fehler geliefert.\n- Verweisen mehrere CA-Einträge auf dieselbe Rechnung, wird nur einer davon (nicht deterministisch) verwendet.\n- Der Kopfkommentar der Prozedur (\"show all CA Events and Statistics for a selected customer\") entspricht nicht dem tatsächlichen Verhalten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCAGetInvoiceMatch"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 104523\n RE2024-001234\n 2\n 2024-03-15T10:30:00\n Payment PayPal 7XK12345\n -119.00\n -119.00\n EUR\n 2024-03-15T10:31:12\n \n"
}
]
},
{
"name": "pixiCAInsertMatch",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 15234\n 15240\n 49.90\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine Verrechnung (Match) zwischen zwei Kundenkonto-Buchungen mit einem angegebenen Betrag an.\n\nVerknüpft zwei Kundenkonto-Buchungen, z. B. eine Zahlung und eine Rechnung, mit einem Verrechnungsbetrag.\n\n1. Zuerst läuft die allgemeine API-Hülle. Sie prüft das Aufruffrequenz-Limit für `pipiCAInsertMatch` und speichert den Zeitpunkt des Aufrufs. Ist das Limit überschritten, wird eine Zeile mit `ResultCode` `502` und `ResultText` geliefert, und es passiert nichts weiter.\n2. Ist `CAref1`, `CAref2` oder `MatchAmount` `NULL`, wird eine Statuszeile mit `ReturnCode` = `ERROR` und `ErrorMessage` geliefert. Es werden keine Daten geschrieben.\n3. Andernfalls wird ein Datensatz in `CustomerAccountMatch` angelegt:\n - `CAref1` und `CAref2` werden wie übergeben gespeichert.\n - `AbsoluteMatchAmount` erhält `MatchAmount`, auf 2 Nachkommastellen gerundet.\n - Anlage- und Änderungsbenutzer werden auf `API` gesetzt, jeweils mit aktuellem Datum und aktueller Uhrzeit.\n\nBei Erfolg liefert der Aufruf keine Ergebnismenge.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CAref1` | int | Ja | Schlüssel der ersten zu verrechnenden Kundenkonto-Buchung. |\n| `CAref2` | int | Ja | Schlüssel der zweiten zu verrechnenden Kundenkonto-Buchung. |\n| `MatchAmount` | money | Ja | Zu verrechnender Betrag. Er wird auf 2 Nachkommastellen gerundet und als `AbsoluteMatchAmount` gespeichert. |\n| `ResultCode` | char(3) | Nein | Ausgabe: Ergebniscode der API-Hülle, `200` bei zugelassenem Aufruf oder `502` bei überschrittenem Frequenz-Limit. |\n| `ResultText` | varchar(1024) | Nein | Ausgabe: Text zu `ResultCode`, entweder `OK` oder die Meldung zum Frequenz-Limit. |\n\n- Das Einfügen läuft in einer eigenen Transaktion bzw. in einem Savepoint, wenn bereits eine Transaktion offen ist.\n- SQL-Fehler beim Einfügen werden abgefangen, zurückgerollt und über `log.InsertError` protokolliert; dieses Objekt liegt nicht vor. Beispiele sind Constraint-Verletzungen bei nicht existierenden `CAref`-Werten. Der Aufrufer erhält in diesem Fall **keine Fehlerzeile**, sodass Erfolg und fehlgeschlagenes Einfügen anhand der Antwort allein nicht unterscheidbar sind.\n- Der Code prüft nicht, ob `CAref1` und `CAref2` existieren, zum selben Kunden gehören oder ob der Betrag zu den offenen Salden passt. Solche Prüfungen hängen von hier nicht sichtbaren Tabellen-Constraints ab.\n- Die ID des neuen Match-Datensatzes wird nur als interner Rückgabewert der Prozedur verwendet und nicht an den SOAP-Aufrufer geliefert.\n- `CAref1`, `CAref2` und `MatchAmount` haben keinen Standardwert. Werden sie im Request weggelassen, entsteht ein SQL-Fehler wegen des fehlenden Parameters. Die `ERROR`-Zeile erscheint nur, wenn sie explizit als `NULL` übergeben werden.\n- Der Fehlertext enthält einen Tippfehler: Er nennt `CAref1` zweimal statt `CAref1` und `CAref2`.\n- Frequenz-Limits werden in `API_CONTROL` (`MIN_BREATHING_MSEC`) konfiguriert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCAInsertMatch"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 15234\n 15240\n 49.90\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine Verrechnung (Match) zwischen zwei Kundenkonto-Buchungen mit einem angegebenen Betrag an.\n\nVerknüpft zwei Kundenkonto-Buchungen, z. B. eine Zahlung und eine Rechnung, mit einem Verrechnungsbetrag.\n\n1. Zuerst läuft die allgemeine API-Hülle. Sie prüft das Aufruffrequenz-Limit für `pipiCAInsertMatch` und speichert den Zeitpunkt des Aufrufs. Ist das Limit überschritten, wird eine Zeile mit `ResultCode` `502` und `ResultText` geliefert, und es passiert nichts weiter.\n2. Ist `CAref1`, `CAref2` oder `MatchAmount` `NULL`, wird eine Statuszeile mit `ReturnCode` = `ERROR` und `ErrorMessage` geliefert. Es werden keine Daten geschrieben.\n3. Andernfalls wird ein Datensatz in `CustomerAccountMatch` angelegt:\n - `CAref1` und `CAref2` werden wie übergeben gespeichert.\n - `AbsoluteMatchAmount` erhält `MatchAmount`, auf 2 Nachkommastellen gerundet.\n - Anlage- und Änderungsbenutzer werden auf `API` gesetzt, jeweils mit aktuellem Datum und aktueller Uhrzeit.\n\nBei Erfolg liefert der Aufruf keine Ergebnismenge.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CAref1` | int | Ja | Schlüssel der ersten zu verrechnenden Kundenkonto-Buchung. |\n| `CAref2` | int | Ja | Schlüssel der zweiten zu verrechnenden Kundenkonto-Buchung. |\n| `MatchAmount` | money | Ja | Zu verrechnender Betrag. Er wird auf 2 Nachkommastellen gerundet und als `AbsoluteMatchAmount` gespeichert. |\n| `ResultCode` | char(3) | Nein | Ausgabe: Ergebniscode der API-Hülle, `200` bei zugelassenem Aufruf oder `502` bei überschrittenem Frequenz-Limit. |\n| `ResultText` | varchar(1024) | Nein | Ausgabe: Text zu `ResultCode`, entweder `OK` oder die Meldung zum Frequenz-Limit. |\n\n- Das Einfügen läuft in einer eigenen Transaktion bzw. in einem Savepoint, wenn bereits eine Transaktion offen ist.\n- SQL-Fehler beim Einfügen werden abgefangen, zurückgerollt und über `log.InsertError` protokolliert; dieses Objekt liegt nicht vor. Beispiele sind Constraint-Verletzungen bei nicht existierenden `CAref`-Werten. Der Aufrufer erhält in diesem Fall **keine Fehlerzeile**, sodass Erfolg und fehlgeschlagenes Einfügen anhand der Antwort allein nicht unterscheidbar sind.\n- Der Code prüft nicht, ob `CAref1` und `CAref2` existieren, zum selben Kunden gehören oder ob der Betrag zu den offenen Salden passt. Solche Prüfungen hängen von hier nicht sichtbaren Tabellen-Constraints ab.\n- Die ID des neuen Match-Datensatzes wird nur als interner Rückgabewert der Prozedur verwendet und nicht an den SOAP-Aufrufer geliefert.\n- `CAref1`, `CAref2` und `MatchAmount` haben keinen Standardwert. Werden sie im Request weggelassen, entsteht ein SQL-Fehler wegen des fehlenden Parameters. Die `ERROR`-Zeile erscheint nur, wenn sie explizit als `NULL` übergeben werden.\n- Der Fehlertext enthält einen Tippfehler: Er nennt `CAref1` zweimal statt `CAref1` und `CAref2`.\n- Frequenz-Limits werden in `API_CONTROL` (`MIN_BREATHING_MSEC`) konfiguriert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCAInsertMatch"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n ERROR\n CAref1, CAref1 and MatchAmount cannot be NULL\n \n"
}
]
},
{
"name": "pixiCreateBankline",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n shop-payments-2024-03-15.csv\n 2024-03-15T00:00:00\n 149.90\n Order 100234\n Invoice RE-2024-0815\n ?\n 37040044\n 0532013000\n Max Mustermann\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen neuen Bank-Kopfsatz mit genau einer Bankzeile (Kontobewegung) an und liefert die Schlüssel beider Datensätze.\n\nImportiert eine einzelne Kontobewegung in Pixi, z. B. für den späteren Abgleich mit Aufträgen oder Rechnungen.\n\nAblauf:\n\n1. Ermittelt die Datenbankwährung (Hauswährung) über `pixi.GetDatabaseCurrency()`. Das ist die Währung, deren Code der Einstellung `HomeCurrency` entspricht und die als Basiswährung gekennzeichnet ist.\n2. Ist `SourceType` `NULL` oder leer, wird `API` verwendet.\n3. Legt einen neuen Datensatz in `BankHeader` mit `SourceType`, der aktuellen Serverzeit als `BankImportDate` und `BankFileName` an.\n4. Legt einen Datensatz in `BankLines` an, der auf den neuen Kopfsatz verweist:\n - `BankDate` = `BankDate`.\n - `BookDate` = Monat und Tag von `BankDate` als vierstellige Zeichenkette `MMDD` (z. B. `0315`).\n - `BusinessCode` ist immer `051`.\n - `BankCode` = `BLZ`, `AccountNr`, `CustomerName`, `BankText01`–`BankText03`, `ParsedBIC` = `BIC`, `ParsedIBAN` = `IBAN`, `AccountingBankAccount`.\n - `CurrencyId` = `CurrencyId` bzw. die Datenbankwährung, wenn `CurrencyId` nicht angegeben ist.\n5. Liefert eine Zeile mit dem neuen `BankHeaderKey` und `BanklineKey`.\n\nJeder Aufruf erzeugt einen eigenen Bank-Kopfsatz; weitere Zeilen können über diesen Aufruf nicht an einen bestehenden Kopfsatz angehängt werden.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BankFileName` | varchar(1024) | Ja | Name der Bankdatei bzw. Quelle der Kontobewegung; wird in `BankHeader.BankFileName` gespeichert. |\n| `BankDate` | datetime | Ja | Datum der Kontobewegung. Daraus wird auch `BookDate` (Format `MMDD`) abgeleitet. |\n| `BankAmount` | money | Ja | Betrag der Kontobewegung. |\n| `BankText01` | varchar(1024) | Ja | Erste Zeile des Verwendungszwecks bzw. Buchungstexts. |\n| `BankText02` | varchar(1024) | Ja | Zweite Zeile des Verwendungszwecks bzw. Buchungstexts. |\n| `BankText03` | varchar(1024) | Ja | Dritte Zeile des Verwendungszwecks bzw. Buchungstexts. |\n| `BLZ` | char(11) | Ja | Bankleitzahl des Auftraggebers; wird in `BankLines.BankCode` gespeichert. |\n| `AccountNr` | char(24) | Ja | Kontonummer des Auftraggebers. |\n| `CustomerName` | varchar(60) | Ja | Name des Kontoinhabers bzw. Zahlers. |\n| `BIC` | varchar(50) | Nein | BIC des Auftraggebers; wird in `BankLines.ParsedBIC` gespeichert. |\n| `IBAN` | varchar(150) | Nein | IBAN des Auftraggebers; wird in `BankLines.ParsedIBAN` gespeichert. |\n| `AccountingBankAccount` | varchar(250) | Nein | Eigenes Bankkonto (Buchhaltungskonto), zu dem die Kontobewegung gehört. |\n| `SourceType` | varchar(3) | Nein | Quelltyp, der in `BankHeader.SourceType` gespeichert wird. `NULL` oder eine leere Zeichenkette wird durch `API` ersetzt. |\n| `CurrencyId` | smallint | Nein | Id der Währung des Betrags. Bei `NULL` wird die Datenbankwährung (Hauswährung) verwendet. |\n\n- Es wird keine explizite Transaktion verwendet. Schlägt das Einfügen in `BankLines` fehl, bleibt der bereits angelegte `BankHeader`-Datensatz ohne Zeilen bestehen.\n- Es findet keine Prüfung statt: Dubletten werden nicht erkannt, IBAN/BIC werden nicht validiert, das Vorzeichen des Betrags wird unverändert übernommen.\n- `BankFileName`, `BankDate`, `BankAmount`, `BankText01`–`BankText03`, `BLZ`, `AccountNr` und `CustomerName` haben keinen Standardwert und müssen im Request enthalten sein (sie dürfen leer bzw. `NULL` sein, soweit die Tabelle dies zulässt).\n- Ist `BankDate` `NULL`, ist auch `BookDate` `NULL`.\n- Wird keine Währung zur Einstellung `HomeCurrency` gefunden und `CurrencyId` nicht übergeben, wird `CurrencyId` als `NULL` gespeichert.\n- `BLZ` und `AccountNr` sind `char`-Parameter und werden mit Leerzeichen aufgefüllt; `SourceType` ist auf 3 Zeichen begrenzt.\n- `BanklineKey` stammt aus `SCOPE_IDENTITY()` und wird daher als Dezimalwert geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateBankline"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n shop-payments-2024-03-15.csv\n 2024-03-15T00:00:00\n 149.90\n Order 100234\n Invoice RE-2024-0815\n ?\n 37040044\n 0532013000\n Max Mustermann\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen neuen Bank-Kopfsatz mit genau einer Bankzeile (Kontobewegung) an und liefert die Schlüssel beider Datensätze.\n\nImportiert eine einzelne Kontobewegung in Pixi, z. B. für den späteren Abgleich mit Aufträgen oder Rechnungen.\n\nAblauf:\n\n1. Ermittelt die Datenbankwährung (Hauswährung) über `pixi.GetDatabaseCurrency()`. Das ist die Währung, deren Code der Einstellung `HomeCurrency` entspricht und die als Basiswährung gekennzeichnet ist.\n2. Ist `SourceType` `NULL` oder leer, wird `API` verwendet.\n3. Legt einen neuen Datensatz in `BankHeader` mit `SourceType`, der aktuellen Serverzeit als `BankImportDate` und `BankFileName` an.\n4. Legt einen Datensatz in `BankLines` an, der auf den neuen Kopfsatz verweist:\n - `BankDate` = `BankDate`.\n - `BookDate` = Monat und Tag von `BankDate` als vierstellige Zeichenkette `MMDD` (z. B. `0315`).\n - `BusinessCode` ist immer `051`.\n - `BankCode` = `BLZ`, `AccountNr`, `CustomerName`, `BankText01`–`BankText03`, `ParsedBIC` = `BIC`, `ParsedIBAN` = `IBAN`, `AccountingBankAccount`.\n - `CurrencyId` = `CurrencyId` bzw. die Datenbankwährung, wenn `CurrencyId` nicht angegeben ist.\n5. Liefert eine Zeile mit dem neuen `BankHeaderKey` und `BanklineKey`.\n\nJeder Aufruf erzeugt einen eigenen Bank-Kopfsatz; weitere Zeilen können über diesen Aufruf nicht an einen bestehenden Kopfsatz angehängt werden.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BankFileName` | varchar(1024) | Ja | Name der Bankdatei bzw. Quelle der Kontobewegung; wird in `BankHeader.BankFileName` gespeichert. |\n| `BankDate` | datetime | Ja | Datum der Kontobewegung. Daraus wird auch `BookDate` (Format `MMDD`) abgeleitet. |\n| `BankAmount` | money | Ja | Betrag der Kontobewegung. |\n| `BankText01` | varchar(1024) | Ja | Erste Zeile des Verwendungszwecks bzw. Buchungstexts. |\n| `BankText02` | varchar(1024) | Ja | Zweite Zeile des Verwendungszwecks bzw. Buchungstexts. |\n| `BankText03` | varchar(1024) | Ja | Dritte Zeile des Verwendungszwecks bzw. Buchungstexts. |\n| `BLZ` | char(11) | Ja | Bankleitzahl des Auftraggebers; wird in `BankLines.BankCode` gespeichert. |\n| `AccountNr` | char(24) | Ja | Kontonummer des Auftraggebers. |\n| `CustomerName` | varchar(60) | Ja | Name des Kontoinhabers bzw. Zahlers. |\n| `BIC` | varchar(50) | Nein | BIC des Auftraggebers; wird in `BankLines.ParsedBIC` gespeichert. |\n| `IBAN` | varchar(150) | Nein | IBAN des Auftraggebers; wird in `BankLines.ParsedIBAN` gespeichert. |\n| `AccountingBankAccount` | varchar(250) | Nein | Eigenes Bankkonto (Buchhaltungskonto), zu dem die Kontobewegung gehört. |\n| `SourceType` | varchar(3) | Nein | Quelltyp, der in `BankHeader.SourceType` gespeichert wird. `NULL` oder eine leere Zeichenkette wird durch `API` ersetzt. |\n| `CurrencyId` | smallint | Nein | Id der Währung des Betrags. Bei `NULL` wird die Datenbankwährung (Hauswährung) verwendet. |\n\n- Es wird keine explizite Transaktion verwendet. Schlägt das Einfügen in `BankLines` fehl, bleibt der bereits angelegte `BankHeader`-Datensatz ohne Zeilen bestehen.\n- Es findet keine Prüfung statt: Dubletten werden nicht erkannt, IBAN/BIC werden nicht validiert, das Vorzeichen des Betrags wird unverändert übernommen.\n- `BankFileName`, `BankDate`, `BankAmount`, `BankText01`–`BankText03`, `BLZ`, `AccountNr` und `CustomerName` haben keinen Standardwert und müssen im Request enthalten sein (sie dürfen leer bzw. `NULL` sein, soweit die Tabelle dies zulässt).\n- Ist `BankDate` `NULL`, ist auch `BookDate` `NULL`.\n- Wird keine Währung zur Einstellung `HomeCurrency` gefunden und `CurrencyId` nicht übergeben, wird `CurrencyId` als `NULL` gespeichert.\n- `BLZ` und `AccountNr` sind `char`-Parameter und werden mit Leerzeichen aufgefüllt; `SourceType` ist auf 3 Zeichen begrenzt.\n- `BanklineKey` stammt aus `SCOPE_IDENTITY()` und wird daher als Dezimalwert geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateBankline"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1523\n 48211\n \n"
}
]
},
{
"name": "pixiCreateBanklineMatch",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 4711\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ordnet eine Bankzeile einem Auftrag zu, indem ein manueller Bank-Match angelegt wird, und gibt den Auftrag optional frei.\n\nLegt einen manuellen Eintrag in `BankMatch` an, der eine Bankzeile (`BanklineKey`) mit einem Auftrag verknüpft.\n\n1. Es muss entweder `OrderNr` oder `OrderNrExternal` übergeben werden, sonst wird eine Fehlerzeile geliefert.\n2. Der Auftrag wird in `OrderHeader` über `OrderNr = @OrderNr OR OrderNrExternal = @OrderNrExternal` gesucht. Der offene Betrag ist die Auftragssumme, gerundet auf die Anzahl Nachkommastellen aus der Einstellung `NumberOfDecimalPlacesForPrices` (Standard 2), abzüglich `PaidByCustomer`.\n3. Die Abweichung wird als Absolutwert aus verbleibendem Bankbetrag (`BankAmount - UsedAmount`) minus offenem Betrag berechnet. Ist `MaxMatchDelta` gesetzt und die Abweichung größer, wird nichts geschrieben und eine Fehlerzeile geliefert.\n4. Existiert bereits eine Zuordnung zwischen diesem Auftrag und dieser Bankzeile, wird eine Fehlerzeile geliefert.\n5. Andernfalls wird eine Zeile in `BankMatch` mit `ManualMatch = 1`, dem aktuellen Datum und `AmountMatched` = dem kleineren Wert aus verbleibendem Bankbetrag und offenem Betrag angelegt.\n6. Bei `AutoReleaseOrder = 1` wird die Differenz zwischen `OrderTotal` und `PaidByCustomer` des Auftrags erneut geprüft. Ist sie kleiner oder gleich `MaxMatchDelta` (bzw. 0, wenn nicht gesetzt), werden die Auftragspositionen mit Status `HAL` auf `ANG` gesetzt (Auftrag wird freigegeben). Andernfalls wird die gerade angelegte Zuordnung wieder gelöscht.\n\nDer Aufruf liefert immer genau eine Zeile mit `Status`, `Message` und den aktuellen Werten der Bankzeile.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BanklineKey` | int | Ja | Schlüssel der Bankzeile (`BankLines.BankLineKey`), die zugeordnet werden soll. |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. Entweder dieser Wert oder `OrderNrExternal` muss übergeben werden. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer (z. B. Shop-Bestellnummer). Wird verwendet, wenn `OrderNr` nicht übergeben wird. |\n| `MaxMatchDelta` | money | Nein | Maximal zulässige Abweichung zwischen verbleibendem Bankbetrag und offenem Auftragsbetrag. Bei NULL erfolgt vor der Zuordnung keine Prüfung; für die Freigabeprüfung gilt NULL als 0. |\n| `AutoReleaseOrder` | bit | Nein | Bei 1 wird der Auftrag nach der Zuordnung freigegeben, wenn die Restdifferenz innerhalb von `MaxMatchDelta` liegt; andernfalls wird die neue Zuordnung wieder entfernt. |\n\n- **Status zeigt das Ergebnis der Freigabe nicht an:** Nach dem Insert ist `Status` immer `OK` und `Message` immer leer, auch wenn die Zuordnung wieder gelöscht wurde, weil der Auftrag nicht freigegeben werden konnte. Bei Bedarf den Auftrag bzw. `BankMatch` anschließend prüfen.\n- Die Freigabeprüfung setzt voraus, dass `PaidByCustomer` nach dem Insert aktualisiert wurde. Der Code selbst aktualisiert diesen Wert nicht; vermutlich geschieht das über Logik außerhalb dieser Prozedur (z. B. einen Trigger), die hier nicht sichtbar ist. Ist `PaidByCustomer` NULL, wird der Auftrag nie freigegeben und die Zuordnung entfernt.\n- Werden `OrderNr` und `OrderNrExternal` gleichzeitig übergeben, kann der `OR`-Filter mehrere Aufträge treffen; dann wird einer davon beliebig verwendet.\n- Die Existenz der Bankzeile wird nicht geprüft. Bei nicht vorhandenem `BanklineKey` wird keine Zuordnung angelegt, `Status` ist trotzdem `OK`. Der Match-Schlüssel wird dann über `IDENT_CURRENT('BankMatch')` ermittelt, das nicht sitzungsbezogen ist; zusammen mit `AutoReleaseOrder = 1` und fehlgeschlagener Freigabeprüfung kann so eine fremde `BankMatch`-Zeile gelöscht werden. Dasselbe Risiko besteht bei parallelen Inserts.\n- Ist `UsedAmount` NULL, wird `AmountMatched` NULL (kein `ISNULL` im Insert), während die Abweichungsprüfung den Wert als 0 behandelt.\n- Lesezugriffe verwenden `NOLOCK`. Die Verarbeitung läuft in einer Transaktion, die nach der Auftragssuche in allen Zweigen committet wird.\n- Fehler bei der Freigabe (`GOS_ReleaseOnHold`) werden in `LogTable` protokolliert und erneut ausgelöst; sie erreichen den Aufrufer als `SqlMessage`.\n- Freigegebene Auftragspositionen erhalten `UpdateEmp` = `BanklineMatch - API (payments)`, gekürzt auf 20 Zeichen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateBanklineMatch"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 4711\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ordnet eine Bankzeile einem Auftrag zu, indem ein manueller Bank-Match angelegt wird, und gibt den Auftrag optional frei.\n\nLegt einen manuellen Eintrag in `BankMatch` an, der eine Bankzeile (`BanklineKey`) mit einem Auftrag verknüpft.\n\n1. Es muss entweder `OrderNr` oder `OrderNrExternal` übergeben werden, sonst wird eine Fehlerzeile geliefert.\n2. Der Auftrag wird in `OrderHeader` über `OrderNr = @OrderNr OR OrderNrExternal = @OrderNrExternal` gesucht. Der offene Betrag ist die Auftragssumme, gerundet auf die Anzahl Nachkommastellen aus der Einstellung `NumberOfDecimalPlacesForPrices` (Standard 2), abzüglich `PaidByCustomer`.\n3. Die Abweichung wird als Absolutwert aus verbleibendem Bankbetrag (`BankAmount - UsedAmount`) minus offenem Betrag berechnet. Ist `MaxMatchDelta` gesetzt und die Abweichung größer, wird nichts geschrieben und eine Fehlerzeile geliefert.\n4. Existiert bereits eine Zuordnung zwischen diesem Auftrag und dieser Bankzeile, wird eine Fehlerzeile geliefert.\n5. Andernfalls wird eine Zeile in `BankMatch` mit `ManualMatch = 1`, dem aktuellen Datum und `AmountMatched` = dem kleineren Wert aus verbleibendem Bankbetrag und offenem Betrag angelegt.\n6. Bei `AutoReleaseOrder = 1` wird die Differenz zwischen `OrderTotal` und `PaidByCustomer` des Auftrags erneut geprüft. Ist sie kleiner oder gleich `MaxMatchDelta` (bzw. 0, wenn nicht gesetzt), werden die Auftragspositionen mit Status `HAL` auf `ANG` gesetzt (Auftrag wird freigegeben). Andernfalls wird die gerade angelegte Zuordnung wieder gelöscht.\n\nDer Aufruf liefert immer genau eine Zeile mit `Status`, `Message` und den aktuellen Werten der Bankzeile.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BanklineKey` | int | Ja | Schlüssel der Bankzeile (`BankLines.BankLineKey`), die zugeordnet werden soll. |\n| `OrderNr` | int | Nein | Pixi-Auftragsnummer. Entweder dieser Wert oder `OrderNrExternal` muss übergeben werden. |\n| `OrderNrExternal` | varchar(50) | Nein | Externe Auftragsnummer (z. B. Shop-Bestellnummer). Wird verwendet, wenn `OrderNr` nicht übergeben wird. |\n| `MaxMatchDelta` | money | Nein | Maximal zulässige Abweichung zwischen verbleibendem Bankbetrag und offenem Auftragsbetrag. Bei NULL erfolgt vor der Zuordnung keine Prüfung; für die Freigabeprüfung gilt NULL als 0. |\n| `AutoReleaseOrder` | bit | Nein | Bei 1 wird der Auftrag nach der Zuordnung freigegeben, wenn die Restdifferenz innerhalb von `MaxMatchDelta` liegt; andernfalls wird die neue Zuordnung wieder entfernt. |\n\n- **Status zeigt das Ergebnis der Freigabe nicht an:** Nach dem Insert ist `Status` immer `OK` und `Message` immer leer, auch wenn die Zuordnung wieder gelöscht wurde, weil der Auftrag nicht freigegeben werden konnte. Bei Bedarf den Auftrag bzw. `BankMatch` anschließend prüfen.\n- Die Freigabeprüfung setzt voraus, dass `PaidByCustomer` nach dem Insert aktualisiert wurde. Der Code selbst aktualisiert diesen Wert nicht; vermutlich geschieht das über Logik außerhalb dieser Prozedur (z. B. einen Trigger), die hier nicht sichtbar ist. Ist `PaidByCustomer` NULL, wird der Auftrag nie freigegeben und die Zuordnung entfernt.\n- Werden `OrderNr` und `OrderNrExternal` gleichzeitig übergeben, kann der `OR`-Filter mehrere Aufträge treffen; dann wird einer davon beliebig verwendet.\n- Die Existenz der Bankzeile wird nicht geprüft. Bei nicht vorhandenem `BanklineKey` wird keine Zuordnung angelegt, `Status` ist trotzdem `OK`. Der Match-Schlüssel wird dann über `IDENT_CURRENT('BankMatch')` ermittelt, das nicht sitzungsbezogen ist; zusammen mit `AutoReleaseOrder = 1` und fehlgeschlagener Freigabeprüfung kann so eine fremde `BankMatch`-Zeile gelöscht werden. Dasselbe Risiko besteht bei parallelen Inserts.\n- Ist `UsedAmount` NULL, wird `AmountMatched` NULL (kein `ISNULL` im Insert), während die Abweichungsprüfung den Wert als 0 behandelt.\n- Lesezugriffe verwenden `NOLOCK`. Die Verarbeitung läuft in einer Transaktion, die nach der Auftragssuche in allen Zweigen committet wird.\n- Fehler bei der Freigabe (`GOS_ReleaseOnHold`) werden in `LogTable` protokolliert und erneut ausgelöst; sie erreichen den Aufrufer als `SqlMessage`.\n- Freigegebene Auftragspositionen erhalten `UpdateEmp` = `BanklineMatch - API (payments)`, gekürzt auf 20 Zeichen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateBanklineMatch"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n \n 4711\n 119.9000\n 0.0000\n \n"
}
]
},
{
"name": "pixiCreateInkassoBookings",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10\n 1\n 3\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt manuelle Kundenkonto-Buchungen für offene, gemahnte Rechnungen im Inkasso an; außerhalb bestimmter Datenbanken nicht mehr unterstützt.\n\nDer Aufruf prüft den Namen der aktuellen Datenbank.\n\n- **Datenbank `pixi_GCH` oder `pixi_GCH_test`:** Die interne Prozedur `Pixi_CA_CreateinkassoManualBookings` wird mit den drei Parametern ausgeführt. Sie legt manuelle Buchungsereignisse auf dem Kundenkonto an, damit die betroffenen Rechnungen nicht mehr offen sind. In diesem Fall wird keine Ergebnismenge zurückgegeben.\n- **Jede andere Datenbank:** Es wird nichts gebucht. Der Aufruf liefert eine einzelne Zeile mit `Status` = `Info` und einer Meldung, dass der Aufruf nicht mehr unterstützt wird.\n\nDie interne Prozedur arbeitet so:\n\n1. Sie liest die Buchungsereignis-ID aus der Einstellung `CA_Inkasso_ManualBookingID`. Ist die Einstellung leer oder `0`, wird `INU` verwendet.\n2. Sie fährt nur fort, wenn in `CustomerAccountEvents` ein Ereignis mit dieser ID existiert und `OriginalAmountMultiply = -1` hat (negatives Ereignis).\n3. Sie wählt Rechnungen mit `Total` > 0 und offenem Betrag (`Total` - `PayedSum`) > 0. Der Kunde muss laut `fPixi_CA_IsMatched` abgeglichen sein. Zusätzlich muss der Kunde mindestens eine offene Rechnung haben, die alle folgenden Bedingungen erfüllt:\n - Mahnstufe zwischen `MinimumReminderLevel` und `MaxReminderLevel`;\n - Rechnungsdatum älter als `MinimumAgeInDays` Tage.\n4. Für jede gewählte Rechnung schreibt sie einen Logeintrag in `LogTable`. Anschließend ruft sie `Pixi_CA_InsertManualBookingEvent` auf, mit dem negierten offenen Betrag, dem Text `Manual booking`, dem Benutzer `pixi* Automatic`, dem Kundenkonto-Schlüssel der Rechnung und deren Währung.\n\nGebucht werden alle offenen Rechnungen eines qualifizierten Kunden, nicht nur die Rechnungen, die die Alters- und Mahnstufenkriterien erfüllen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `MinimumAgeInDays` | int | Ja | Mindestalter einer gemahnten Rechnung in Tagen (Rechnungsdatum älter als heute minus dieser Wert), damit der Kunde berücksichtigt wird. |\n| `MinimumReminderLevel` | smallint | Ja | Niedrigste Mahnstufe (inklusive) der qualifizierenden Rechnung. NULL-Mahnstufen zählen als 0. |\n| `MaxReminderLevel` | int | Ja | Höchste Mahnstufe (inklusive) der qualifizierenden Rechnung. |\n\n- **Veraltet:** Außerhalb der Datenbanken `pixi_GCH` und `pixi_GCH_test` liefert der Aufruf nur die `Info`-Zeile und führt sonst nichts aus. Der Meldungstext enthält den Tippfehler `suported`.\n- **Keine Rückmeldung:** In den unterstützten Datenbanken wird keine Ergebnismenge geliefert. Der Erfolg lässt sich nur über `LogTable` oder das Kundenkonto prüfen.\n- **Hier nicht dokumentiert:** Die Definitionen von `Pixi_CA_InsertManualBookingEvent`, `fPixi_CA_IsMatched` und `fPixi_GetSetting` liegen nicht vor. Deren genaues Verhalten ist daher nicht dokumentiert.\n- **Dynamisches SQL, keine Transaktion:** Buchungen und Logeinträge werden als dynamisches SQL aufgebaut und ohne explizite Transaktion ausgeführt. Die Logeinträge werden vor den Buchungen geschrieben; schlägt eine Buchung fehl, können Logeinträge ohne zugehörige Buchung verbleiben.\n- **Dirty Reads:** Lesezugriffe verwenden `NOLOCK`.\n- **Kein Schutz vor Doppelbuchungen:** Wiederholte Aufrufe können weitere Buchungen erzeugen, solange Rechnungen noch als offen erscheinen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateInkassoBookings"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10\n 1\n 3\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt manuelle Kundenkonto-Buchungen für offene, gemahnte Rechnungen im Inkasso an; außerhalb bestimmter Datenbanken nicht mehr unterstützt.\n\nDer Aufruf prüft den Namen der aktuellen Datenbank.\n\n- **Datenbank `pixi_GCH` oder `pixi_GCH_test`:** Die interne Prozedur `Pixi_CA_CreateinkassoManualBookings` wird mit den drei Parametern ausgeführt. Sie legt manuelle Buchungsereignisse auf dem Kundenkonto an, damit die betroffenen Rechnungen nicht mehr offen sind. In diesem Fall wird keine Ergebnismenge zurückgegeben.\n- **Jede andere Datenbank:** Es wird nichts gebucht. Der Aufruf liefert eine einzelne Zeile mit `Status` = `Info` und einer Meldung, dass der Aufruf nicht mehr unterstützt wird.\n\nDie interne Prozedur arbeitet so:\n\n1. Sie liest die Buchungsereignis-ID aus der Einstellung `CA_Inkasso_ManualBookingID`. Ist die Einstellung leer oder `0`, wird `INU` verwendet.\n2. Sie fährt nur fort, wenn in `CustomerAccountEvents` ein Ereignis mit dieser ID existiert und `OriginalAmountMultiply = -1` hat (negatives Ereignis).\n3. Sie wählt Rechnungen mit `Total` > 0 und offenem Betrag (`Total` - `PayedSum`) > 0. Der Kunde muss laut `fPixi_CA_IsMatched` abgeglichen sein. Zusätzlich muss der Kunde mindestens eine offene Rechnung haben, die alle folgenden Bedingungen erfüllt:\n - Mahnstufe zwischen `MinimumReminderLevel` und `MaxReminderLevel`;\n - Rechnungsdatum älter als `MinimumAgeInDays` Tage.\n4. Für jede gewählte Rechnung schreibt sie einen Logeintrag in `LogTable`. Anschließend ruft sie `Pixi_CA_InsertManualBookingEvent` auf, mit dem negierten offenen Betrag, dem Text `Manual booking`, dem Benutzer `pixi* Automatic`, dem Kundenkonto-Schlüssel der Rechnung und deren Währung.\n\nGebucht werden alle offenen Rechnungen eines qualifizierten Kunden, nicht nur die Rechnungen, die die Alters- und Mahnstufenkriterien erfüllen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `MinimumAgeInDays` | int | Ja | Mindestalter einer gemahnten Rechnung in Tagen (Rechnungsdatum älter als heute minus dieser Wert), damit der Kunde berücksichtigt wird. |\n| `MinimumReminderLevel` | smallint | Ja | Niedrigste Mahnstufe (inklusive) der qualifizierenden Rechnung. NULL-Mahnstufen zählen als 0. |\n| `MaxReminderLevel` | int | Ja | Höchste Mahnstufe (inklusive) der qualifizierenden Rechnung. |\n\n- **Veraltet:** Außerhalb der Datenbanken `pixi_GCH` und `pixi_GCH_test` liefert der Aufruf nur die `Info`-Zeile und führt sonst nichts aus. Der Meldungstext enthält den Tippfehler `suported`.\n- **Keine Rückmeldung:** In den unterstützten Datenbanken wird keine Ergebnismenge geliefert. Der Erfolg lässt sich nur über `LogTable` oder das Kundenkonto prüfen.\n- **Hier nicht dokumentiert:** Die Definitionen von `Pixi_CA_InsertManualBookingEvent`, `fPixi_CA_IsMatched` und `fPixi_GetSetting` liegen nicht vor. Deren genaues Verhalten ist daher nicht dokumentiert.\n- **Dynamisches SQL, keine Transaktion:** Buchungen und Logeinträge werden als dynamisches SQL aufgebaut und ohne explizite Transaktion ausgeführt. Die Logeinträge werden vor den Buchungen geschrieben; schlägt eine Buchung fehl, können Logeinträge ohne zugehörige Buchung verbleiben.\n- **Dirty Reads:** Lesezugriffe verwenden `NOLOCK`.\n- **Kein Schutz vor Doppelbuchungen:** Wiederholte Aufrufe können weitere Buchungen erzeugen, solange Rechnungen noch als offen erscheinen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateInkassoBookings"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Info\n API Call: pixiCreateInkassoBookings is no longer suported.\n \n"
}
]
},
{
"name": "pixiDatevExportPosWires",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-03-01T00:00:00\n 2024-03-31T00:00:00\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert POS-Barzahlungen und optional Kassensitzungs-Ereignisse eines Zeitraums als Buchungszeilen für einen DATEV-Export.\n\nDer Aufruf gibt alle Parameter unverändert an die interne Prozedur `Pixi_DatevExportPOSWires` weiter und liefert deren Ergebnis. Jede Zeile ist eine Buchungszeile für einen DATEV-Export.\n\n**Zeitraum**\n\n- `DateFrom` wird auf den Tagesbeginn gesetzt.\n- `DateTo` wird auf das Tagesende gesetzt.\n- Berücksichtigt werden Datensätze, deren Datum zwischen `DateFrom` und einer Sekunde vor dem angepassten `DateTo` liegt.\n\n**Teil 1 – POS-Zahlungen** (`POSPayment`, verknüpft mit Kassenbon-Kopf und Kundenadresse)\n\n- Ist die Einstellung `ConsiderAllPosEvents` `0` (Standard), werden nur Zahlungen mit Zahlungscode `B` exportiert. Ist sie `1`, werden Zahlungen mit allen Zahlungscodes exportiert.\n- `ShopId` filtert auf den Shop der Kundenadresse (`AddrShopID`).\n- `Country` filtert auf die Spalte `Country`.\n- `AmoutFrom` / `AmoutTo` filtern auf den Absolutbetrag; beide Grenzen sind inklusiv.\n- `Sign` ist das Minuszeichen bei Zahlungscode `-` (Wechselgeld) oder negativem Betrag, sonst das Pluszeichen.\n- `CustomerNr` sind die ersten 10 Zeichen der externen Kundennummer. Ist diese leer, wird die Einstellung `DefaultCustomerAccountNumber` verwendet, sonst `0`.\n- `InvoiceNr` ist die Belegnummer des Kassenbons.\n- `WireText` ist `Change` bei Zahlungscode `-`, sonst leer.\n\n**Teil 2 – Sitzungsereignisse** (`POSSession_event`)\n\n- Nur enthalten, wenn `ConsiderAllPosEvents` `1` ist.\n- Umfasst die Ereignistypen `D` (Drawer Open), `E` (Session Stop) und `S` (Session Start) im Zeitraum.\n- `ShopId`, `Country` und die Betragsfilter gelten für diesen Teil **nicht**.\n- `Amount` ist der Absolutwert aus Einnahme minus Ausgabe. `Sign` ist Plus, wenn die Differenz ≥ 0 ist, sonst Minus.\n- `CustomerNr` ist das Standard-Kundenkonto. `InvoiceNr` ist leer.\n- `WireText` ist der Ereignisname, gefolgt von ` - ` und dem Ereigniskommentar, falls vorhanden.\n\n**Vorzeichen**\n\nIst die Einstellung `BookExportDatevPro` gesetzt (nicht `0`), lauten die Vorzeichen `s` (Soll) und `h` (Haben). Andernfalls lauten sie `+` und `-`.\n\n**Gemeinsame Spalten**\n\n- `Currency` ist immer `EUR`.\n- `BankAccountNr` ist die Einstellung `AccountNumberPOSPayment`, oder `0`, falls sie nicht gesetzt ist.\n- Die Spalten `Empty1`–`Empty6` sind leere Platzhalter für das DATEV-Dateiformat.\n\n**Sortierung**: `BankAccountNr`, dann `BankDate`, dann `Sign` absteigend.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Ja | Beginn des Zeitraums. Wird auf den Tagesbeginn gesetzt. |\n| `DateTo` | datetime | Ja | Ende des Zeitraums. Wird auf das Tagesende gesetzt, der angegebene Tag ist also enthalten. |\n| `ShopId` | varchar(3) | Nein | Optionaler Shop-Filter auf den Shop der Kundenadresse (`AddrShopID`). Gilt nur für POS-Zahlungen, nicht für Sitzungsereignisse. |\n| `Country` | varchar(3) | Nein | Optionaler Filter auf die Spalte `Country`. Gilt nur für POS-Zahlungen. |\n| `AmoutFrom` | money | Nein | Optionaler Mindest-Absolutbetrag der Zahlung (inklusiv). Gilt nur für POS-Zahlungen. Schreibweise beachten. |\n| `AmoutTo` | money | Nein | Optionaler Höchst-Absolutbetrag der Zahlung (inklusiv). Gilt nur für POS-Zahlungen. Schreibweise beachten. |\n\n- Die Parameternamen `AmoutFrom` und `AmoutTo` sind im Code falsch geschrieben (fehlendes `n`). Sie müssen genau so übergeben werden.\n- Das Verhalten hängt von den Einstellungen `BookExportDatevPro`, `AccountNumberPOSPayment`, `DefaultCustomerAccountNumber` und `ConsiderAllPosEvents` ab. Diese werden zur Laufzeit über `dbo.SettingGet` gelesen.\n- Die genauen Tagesgrenzen stammen aus `fPixi_GetDateStartOfDay` / `fPixi_GetDateEndOfDay`, die nicht beiliegen. Laut Code-Kommentar wird vom Ende eine Sekunde abgezogen, damit Zeilen mit 00:00:00 nicht doppelt exportiert werden.\n- Beide Teile werden mit `UNION` statt `UNION ALL` zusammengeführt. Vollständig identische Zeilen erscheinen daher nur einmal. Das kann zum Beispiel bei zwei gleichen Zahlungen auf demselben Bon zur selben Zeit vorkommen.\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können enthalten sein.\n- Der Filter `ShopId` trifft nur Zahlungen mit verknüpfter Kundenadresse.\n- Die Währung wird immer als `EUR` ausgegeben, unabhängig von der tatsächlichen Zahlungswährung.\n- Nur lesend; es werden keine Daten geändert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDatevExportPosWires"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-03-01T00:00:00\n 2024-03-31T00:00:00\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert POS-Barzahlungen und optional Kassensitzungs-Ereignisse eines Zeitraums als Buchungszeilen für einen DATEV-Export.\n\nDer Aufruf gibt alle Parameter unverändert an die interne Prozedur `Pixi_DatevExportPOSWires` weiter und liefert deren Ergebnis. Jede Zeile ist eine Buchungszeile für einen DATEV-Export.\n\n**Zeitraum**\n\n- `DateFrom` wird auf den Tagesbeginn gesetzt.\n- `DateTo` wird auf das Tagesende gesetzt.\n- Berücksichtigt werden Datensätze, deren Datum zwischen `DateFrom` und einer Sekunde vor dem angepassten `DateTo` liegt.\n\n**Teil 1 – POS-Zahlungen** (`POSPayment`, verknüpft mit Kassenbon-Kopf und Kundenadresse)\n\n- Ist die Einstellung `ConsiderAllPosEvents` `0` (Standard), werden nur Zahlungen mit Zahlungscode `B` exportiert. Ist sie `1`, werden Zahlungen mit allen Zahlungscodes exportiert.\n- `ShopId` filtert auf den Shop der Kundenadresse (`AddrShopID`).\n- `Country` filtert auf die Spalte `Country`.\n- `AmoutFrom` / `AmoutTo` filtern auf den Absolutbetrag; beide Grenzen sind inklusiv.\n- `Sign` ist das Minuszeichen bei Zahlungscode `-` (Wechselgeld) oder negativem Betrag, sonst das Pluszeichen.\n- `CustomerNr` sind die ersten 10 Zeichen der externen Kundennummer. Ist diese leer, wird die Einstellung `DefaultCustomerAccountNumber` verwendet, sonst `0`.\n- `InvoiceNr` ist die Belegnummer des Kassenbons.\n- `WireText` ist `Change` bei Zahlungscode `-`, sonst leer.\n\n**Teil 2 – Sitzungsereignisse** (`POSSession_event`)\n\n- Nur enthalten, wenn `ConsiderAllPosEvents` `1` ist.\n- Umfasst die Ereignistypen `D` (Drawer Open), `E` (Session Stop) und `S` (Session Start) im Zeitraum.\n- `ShopId`, `Country` und die Betragsfilter gelten für diesen Teil **nicht**.\n- `Amount` ist der Absolutwert aus Einnahme minus Ausgabe. `Sign` ist Plus, wenn die Differenz ≥ 0 ist, sonst Minus.\n- `CustomerNr` ist das Standard-Kundenkonto. `InvoiceNr` ist leer.\n- `WireText` ist der Ereignisname, gefolgt von ` - ` und dem Ereigniskommentar, falls vorhanden.\n\n**Vorzeichen**\n\nIst die Einstellung `BookExportDatevPro` gesetzt (nicht `0`), lauten die Vorzeichen `s` (Soll) und `h` (Haben). Andernfalls lauten sie `+` und `-`.\n\n**Gemeinsame Spalten**\n\n- `Currency` ist immer `EUR`.\n- `BankAccountNr` ist die Einstellung `AccountNumberPOSPayment`, oder `0`, falls sie nicht gesetzt ist.\n- Die Spalten `Empty1`–`Empty6` sind leere Platzhalter für das DATEV-Dateiformat.\n\n**Sortierung**: `BankAccountNr`, dann `BankDate`, dann `Sign` absteigend.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Ja | Beginn des Zeitraums. Wird auf den Tagesbeginn gesetzt. |\n| `DateTo` | datetime | Ja | Ende des Zeitraums. Wird auf das Tagesende gesetzt, der angegebene Tag ist also enthalten. |\n| `ShopId` | varchar(3) | Nein | Optionaler Shop-Filter auf den Shop der Kundenadresse (`AddrShopID`). Gilt nur für POS-Zahlungen, nicht für Sitzungsereignisse. |\n| `Country` | varchar(3) | Nein | Optionaler Filter auf die Spalte `Country`. Gilt nur für POS-Zahlungen. |\n| `AmoutFrom` | money | Nein | Optionaler Mindest-Absolutbetrag der Zahlung (inklusiv). Gilt nur für POS-Zahlungen. Schreibweise beachten. |\n| `AmoutTo` | money | Nein | Optionaler Höchst-Absolutbetrag der Zahlung (inklusiv). Gilt nur für POS-Zahlungen. Schreibweise beachten. |\n\n- Die Parameternamen `AmoutFrom` und `AmoutTo` sind im Code falsch geschrieben (fehlendes `n`). Sie müssen genau so übergeben werden.\n- Das Verhalten hängt von den Einstellungen `BookExportDatevPro`, `AccountNumberPOSPayment`, `DefaultCustomerAccountNumber` und `ConsiderAllPosEvents` ab. Diese werden zur Laufzeit über `dbo.SettingGet` gelesen.\n- Die genauen Tagesgrenzen stammen aus `fPixi_GetDateStartOfDay` / `fPixi_GetDateEndOfDay`, die nicht beiliegen. Laut Code-Kommentar wird vom Ende eine Sekunde abgezogen, damit Zeilen mit 00:00:00 nicht doppelt exportiert werden.\n- Beide Teile werden mit `UNION` statt `UNION ALL` zusammengeführt. Vollständig identische Zeilen erscheinen daher nur einmal. Das kann zum Beispiel bei zwei gleichen Zahlungen auf demselben Bon zur selben Zeit vorkommen.\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können enthalten sein.\n- Der Filter `ShopId` trifft nur Zahlungen mit verknüpfter Kundenadresse.\n- Die Währung wird immer als `EUR` ausgegeben, unabhängig von der tatsächlichen Zahlungswährung.\n- Nur lesend; es werden keine Daten geändert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDatevExportPosWires"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n EUR\n +\n 49.9000\n \n 10000\n POS-2024-001234\n \n 2024-03-05T14:22:10\n 1000\n \n \n \n \n \n \n \n EUR\n -\n 0.1000\n \n 10000\n POS-2024-001234\n \n 2024-03-05T14:22:10\n 1000\n \n \n \n \n Change\n \n"
}
]
},
{
"name": "pixiEmillGetPaymentTypes",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Liste aller Zahlungsarten (Code und Bezeichnung), sortiert nach Bezeichnung.\n\nLiefert alle Datensätze der Zahlungsarten-Stammdaten (`Payments`).\n\n- Keine Parameter, keine Filter: Es werden alle Zahlungsarten zurückgegeben.\n- Jede Zeile enthält den Code der Zahlungsart (`PaymentType`) und den Bezeichnungstext (`PaymentTypeDesc`).\n- Die Zeilen sind alphabetisch nach dem Bezeichnungstext sortiert.\n\nDie Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können daher sichtbar sein. Der Aufruf gehört zur `Emill`-Gruppe und dient typischerweise dazu, Codes von Zahlungsarten in lesbare Bezeichnungen zu übersetzen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEmillGetPaymentTypes"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Liste aller Zahlungsarten (Code und Bezeichnung), sortiert nach Bezeichnung.\n\nLiefert alle Datensätze der Zahlungsarten-Stammdaten (`Payments`).\n\n- Keine Parameter, keine Filter: Es werden alle Zahlungsarten zurückgegeben.\n- Jede Zeile enthält den Code der Zahlungsart (`PaymentType`) und den Bezeichnungstext (`PaymentTypeDesc`).\n- Die Zeilen sind alphabetisch nach dem Bezeichnungstext sortiert.\n\nDie Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können daher sichtbar sein. Der Aufruf gehört zur `Emill`-Gruppe und dient typischerweise dazu, Codes von Zahlungsarten in lesbare Bezeichnungen zu übersetzen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiEmillGetPaymentTypes"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n NN\n Nachnahme\n \n \n VK\n Vorkasse\n \n"
}
]
},
{
"name": "pixiGetCreditCardInfo",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100245\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die zu einem Auftrag gespeicherten Kreditkartendaten und die Autorisierungs-ID des Kreditkartenzahlungsanbieters.\n\nSucht den Auftrag mit der angegebenen `OrderNr` in `OrderHeader` und verknüpft den zugehörigen Adressdatensatz (`OrderHeader.AddrRef` = `Addresses.AddrKey`). Die Kreditkartenfelder stammen aus diesem Adressdatensatz.\n\nDie gelieferte Zeile enthält:\n- den Text der Kartenart, ermittelt aus `Creditcards.CardText` über `Addresses.ACardType`\n- Karteninhaber, Kartennummer, Ablaufdatum und CVC\n- die Autorisierungs-ID des Kreditkartenzahlungsanbieters (`OrderHeader.ccpPayID`)\n- das Kennzeichen `CCPIDUsedBefore`. Es ist `1`, wenn ein anderer Auftrag desselben Kunden (`CustRef`) mit niedrigerer Auftragsnummer bereits dieselbe `ccpPayID` hat, sonst `0`.\n\nExistiert kein Auftrag mit dieser Nummer oder hat der Auftrag keinen passenden Adressdatensatz, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Auftragsnummer (`OrderHeader.OrderNr`) des Auftrags, dessen Kreditkartendaten geliefert werden. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; es können nicht festgeschriebene Daten geliefert werden.\n- Der Aufruf liefert sensible Zahlungsdaten (vollständige Kartennummer und CVC) so, wie sie gespeichert sind. Der Zugriff auf diesen Aufruf sollte eingeschränkt werden.\n- Ist `ccpPayID` `NULL`, trifft der Vergleich mit früheren Aufträgen nie zu, und `CCPIDUsedBefore` ist `0`.\n- Die Kartenart wird über eine skalare Unterabfrage ermittelt. Enthält `Creditcards` mehrere Zeilen mit demselben `CardType`, löst SQL Server einen Fehler aus (Unterabfrage liefert mehr als einen Wert). Gibt es keine passende Zeile, ist `CreditCardType` `NULL`.\n- Die Datentypen der Spalten hängen von den Tabellendefinitionen ab, die nicht Teil des Codes sind.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCreditCardInfo"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100245\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die zu einem Auftrag gespeicherten Kreditkartendaten und die Autorisierungs-ID des Kreditkartenzahlungsanbieters.\n\nSucht den Auftrag mit der angegebenen `OrderNr` in `OrderHeader` und verknüpft den zugehörigen Adressdatensatz (`OrderHeader.AddrRef` = `Addresses.AddrKey`). Die Kreditkartenfelder stammen aus diesem Adressdatensatz.\n\nDie gelieferte Zeile enthält:\n- den Text der Kartenart, ermittelt aus `Creditcards.CardText` über `Addresses.ACardType`\n- Karteninhaber, Kartennummer, Ablaufdatum und CVC\n- die Autorisierungs-ID des Kreditkartenzahlungsanbieters (`OrderHeader.ccpPayID`)\n- das Kennzeichen `CCPIDUsedBefore`. Es ist `1`, wenn ein anderer Auftrag desselben Kunden (`CustRef`) mit niedrigerer Auftragsnummer bereits dieselbe `ccpPayID` hat, sonst `0`.\n\nExistiert kein Auftrag mit dieser Nummer oder hat der Auftrag keinen passenden Adressdatensatz, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Auftragsnummer (`OrderHeader.OrderNr`) des Auftrags, dessen Kreditkartendaten geliefert werden. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; es können nicht festgeschriebene Daten geliefert werden.\n- Der Aufruf liefert sensible Zahlungsdaten (vollständige Kartennummer und CVC) so, wie sie gespeichert sind. Der Zugriff auf diesen Aufruf sollte eingeschränkt werden.\n- Ist `ccpPayID` `NULL`, trifft der Vergleich mit früheren Aufträgen nie zu, und `CCPIDUsedBefore` ist `0`.\n- Die Kartenart wird über eine skalare Unterabfrage ermittelt. Enthält `Creditcards` mehrere Zeilen mit demselben `CardType`, löst SQL Server einen Fehler aus (Unterabfrage liefert mehr als einen Wert). Gibt es keine passende Zeile, ist `CreditCardType` `NULL`.\n- Die Datentypen der Spalten hängen von den Tabellendefinitionen ab, die nicht Teil des Codes sind.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetCreditCardInfo"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 100245\n VISA\n Max Mustermann\n 4111111111111111\n 12/27\n 123\n TX-8F3A21C9\n 0\n \n"
}
]
},
{
"name": "pixiGetDatevExportWires",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-01-01T00:00:00\n 2024-01-31T23:59:59\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die DATEV-Exportzeilen für Zahlungen (Bankbuchungen und Kundenkonto-Ereignisse) in einem Zeitraum, optional gefiltert nach Shop, Land, Bankkonto, Betragsbereich und Kostenstelle.\n\nErzeugt den Inhalt der DATEV-Exportdatei \"Payment\" (Zahlungen).\n\n1. Die Einstellung `BookExportDatevActive` wird geprüft. Ist sie nicht `1`, wird nur eine Statuszeile mit `Status` = `ERROR` geliefert.\n2. Andernfalls wird die interne Prozedur `Pixi_DatevExportWires` mit den übergebenen Parametern und `SetStartAndEndOfDay = 0` ausgeführt, d. h. `DateFrom` und `DateTo` werden **genau wie übergeben** verwendet, ohne Erweiterung auf Tagesanfang/-ende.\n\nDas Ergebnis kombiniert zwei Quellen (`UNION ALL`):\n\n**Bankbuchungen** (`BankLines`)\n- Bankbuchungen mit `BankDate` zwischen `DateFrom` und `DateTo` (inklusive). Ist die Einstellung `BookExportWiresWithBookDate` = 1, wird das Datum aus dem Buchungsdatum der Bankbuchung (MMTT plus Jahr, mit Korrektur beim Jahreswechsel) abgeleitet; dafür wird ein Fenster von zwei Wochen vor/nach dem Zeitraum gelesen.\n- Bankbuchungen aus Bankköpfen mit Quelltyp `APY` werden immer ausgeschlossen; `CCP` nur bei gesetzter Einstellung `BookExportCcpTransactions`; `UPD` und Geschäftsvorfall `020` nur bei gesetzter Einstellung `BookExportUpdTransactions`.\n- Kunde, Shop und Rechnung werden über die endgültige (kein Prematch) Bankzuordnung ermittelt: Rechnung, Auftrag, Lastschrift (`DTAUS`) oder Kundenkontoeintrag, in dieser Reihenfolge.\n- `CustomerNr` ist die `DatevAccNr` des Kunden bzw. die Einstellung `BookDefaultCustomerNr`, wenn kein Kunde gefunden wird.\n- `InvoiceNr` ist die externe Auftragsnummer, wenn die Zahlungsart in der Einstellung `BookExportDatevUseOrderNrExternal` aufgeführt ist; sonst die Rechnungsnummer (bei Lastschriften die zugeordnete Rechnung). Ersatzwert ist `BookDefaultInvoiceNr`; der Wert wird auf 12 Zeichen gekürzt.\n- `BankAccountNr` ist das Buchhaltungs-Bankkonto der Bankbuchung (bei gesetzter Einstellung `BookExportQueryAndUseAccountingBankAccount`), das PayPal-Konto `BookDefaultBankAccountNrPayPal` bei Quelltyp `PPL`/`PLL`, sonst `BookDefaultBankAccountNr`.\n- `WireText` setzt sich aus externer Auftragsnummer, Banktexten 1–3 und bei Kreditkartenzahlungen `Kreditkarte` plus Zahlungs-ID zusammen; max. 60 Zeichen, doppelte Anführungszeichen werden entfernt.\n\n**Kundenkonto-Ereignisse** (`CustomerAccount`, Ereignisse `RPP`, `RCC`, `BTC`)\n- Ereignisse mit `EventDate` >= `DateFrom` und < `DateTo`.\n- Enthalten, wenn eine manuelle Buchung verknüpft ist oder wenn die Einstellung `BookExportDatevExportAutomaticCAEvents` aktiv und der Ereignistyp als manuell markiert ist; zusätzlich lastschriftbezogene Einträge mit zugeordneter Rechnung, wenn `BookExportManualDtausToDatev` gesetzt ist.\n- `BankAccountNr` ist das Buchungskonto des Ereignistyps; `BTC` erhält das Plus-Zeichen, die übrigen das Minus-Zeichen.\n\n**Filter** (beide Teile): `ShopId` (Shop des Kunden), `CostCenter` (Kostenstelle des Shops), `Country` (Land der Rechnungs-/Auftragsadresse bzw. Kundenadresse), `AmoutFrom`/`AmoutTo` (auf den Absolutbetrag) und `BankAccountNr` (auf das ermittelte Bankkonto).\n\nDas Vorzeichen ist `s`/`h`, wenn die Einstellung `BookExportDatevPro` aktiv ist, sonst `+`/`-`. Sortierung nach `BankAccountNr`, `BankDate`, `Amount`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Ja | Beginn des Zeitraums (wird genau wie übergeben verwendet). |\n| `DateTo` | datetime | Ja | Ende des Zeitraums (wird genau wie übergeben verwendet; inklusive für Bankbuchungen, exklusive für Kundenkonto-Ereignisse). |\n| `ShopId` | varchar(3) | Nein | Optionale Shop-ID; nur Zahlungen von Kunden dieses Shops werden geliefert. |\n| `Country` | varchar(3) | Nein | Optionaler Ländercode der Rechnungs-/Auftragsadresse (Bankbuchungen) bzw. Kundenadresse (Kundenkonto-Ereignisse). |\n| `BankAccountNr` | varchar(10) | Nein | Optionales Buchungs-Bankkonto; wird mit der ermittelten Spalte `BankAccountNr` verglichen. Leerstring wird als NULL behandelt. |\n| `AmoutFrom` | money | Nein | Optionaler Mindest-Absolutbetrag. |\n| `AmoutTo` | money | Nein | Optionaler Höchst-Absolutbetrag. |\n| `CostCenter` | varchar(8) | Nein | Optionale Kostenstelle des Shops. Leerstring wird als NULL behandelt. |\n\n- Nur lesend; alle Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- Wegen `SetStartAndEndOfDay = 0` bedeutet ein `DateTo` von `2024-01-31` Mitternacht zu Beginn dieses Tages: Bankbuchungen dieses Tages nach 00:00 und Kundenkonto-Ereignisse dieses Tages sind **nicht** enthalten. Für den ganzen Tag z. B. `2024-01-31T23:59:59` übergeben.\n- Bankbuchungen verwenden eine inklusive Obergrenze (`BETWEEN`), Kundenkonto-Ereignisse eine exklusive (`<`).\n- Trotz des Kommentars \"Betragsbereich in €\" werden `AmoutFrom`/`AmoutTo` mit dem Absolutbetrag in der Währung der Bankbuchung bzw. des Ereignisses verglichen, ohne Umrechnung.\n- `ShopId` ist als `varchar(3)` deklariert; die interne Suche über das Shop-Kürzel (Werte länger als 3 Zeichen) kann über diesen Aufruf daher nicht greifen. Eine leere `ShopId` wird nicht als NULL behandelt und liefert keine Zeilen, leere Werte für `BankAccountNr` und `CostCenter` dagegen schon.\n- Kundenkonto-Ereignisse werden nur geliefert, wenn ihr Wechselkurs in der intern reduzierten Kursmenge enthalten ist (Kurse der Datenbankwährungsquelle innerhalb von ±2 Wochen für Währungen, die in den ausgewählten Bankbuchungen vorkommen).\n- Bankbuchungen ohne Bankkopf werden durch die Quelltyp-Filter ausgeschlossen.\n- Das Verhalten hängt von zahlreichen zur Laufzeit gelesenen Einstellungen ab (siehe Beschreibung); `dbo.SettingGet` und `pixi.GetDatabaseCurrency` liegen nicht vor, ihre genaue Semantik ist daher hier nicht dokumentiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetDatevExportWires"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-01-01T00:00:00\n 2024-01-31T23:59:59\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die DATEV-Exportzeilen für Zahlungen (Bankbuchungen und Kundenkonto-Ereignisse) in einem Zeitraum, optional gefiltert nach Shop, Land, Bankkonto, Betragsbereich und Kostenstelle.\n\nErzeugt den Inhalt der DATEV-Exportdatei \"Payment\" (Zahlungen).\n\n1. Die Einstellung `BookExportDatevActive` wird geprüft. Ist sie nicht `1`, wird nur eine Statuszeile mit `Status` = `ERROR` geliefert.\n2. Andernfalls wird die interne Prozedur `Pixi_DatevExportWires` mit den übergebenen Parametern und `SetStartAndEndOfDay = 0` ausgeführt, d. h. `DateFrom` und `DateTo` werden **genau wie übergeben** verwendet, ohne Erweiterung auf Tagesanfang/-ende.\n\nDas Ergebnis kombiniert zwei Quellen (`UNION ALL`):\n\n**Bankbuchungen** (`BankLines`)\n- Bankbuchungen mit `BankDate` zwischen `DateFrom` und `DateTo` (inklusive). Ist die Einstellung `BookExportWiresWithBookDate` = 1, wird das Datum aus dem Buchungsdatum der Bankbuchung (MMTT plus Jahr, mit Korrektur beim Jahreswechsel) abgeleitet; dafür wird ein Fenster von zwei Wochen vor/nach dem Zeitraum gelesen.\n- Bankbuchungen aus Bankköpfen mit Quelltyp `APY` werden immer ausgeschlossen; `CCP` nur bei gesetzter Einstellung `BookExportCcpTransactions`; `UPD` und Geschäftsvorfall `020` nur bei gesetzter Einstellung `BookExportUpdTransactions`.\n- Kunde, Shop und Rechnung werden über die endgültige (kein Prematch) Bankzuordnung ermittelt: Rechnung, Auftrag, Lastschrift (`DTAUS`) oder Kundenkontoeintrag, in dieser Reihenfolge.\n- `CustomerNr` ist die `DatevAccNr` des Kunden bzw. die Einstellung `BookDefaultCustomerNr`, wenn kein Kunde gefunden wird.\n- `InvoiceNr` ist die externe Auftragsnummer, wenn die Zahlungsart in der Einstellung `BookExportDatevUseOrderNrExternal` aufgeführt ist; sonst die Rechnungsnummer (bei Lastschriften die zugeordnete Rechnung). Ersatzwert ist `BookDefaultInvoiceNr`; der Wert wird auf 12 Zeichen gekürzt.\n- `BankAccountNr` ist das Buchhaltungs-Bankkonto der Bankbuchung (bei gesetzter Einstellung `BookExportQueryAndUseAccountingBankAccount`), das PayPal-Konto `BookDefaultBankAccountNrPayPal` bei Quelltyp `PPL`/`PLL`, sonst `BookDefaultBankAccountNr`.\n- `WireText` setzt sich aus externer Auftragsnummer, Banktexten 1–3 und bei Kreditkartenzahlungen `Kreditkarte` plus Zahlungs-ID zusammen; max. 60 Zeichen, doppelte Anführungszeichen werden entfernt.\n\n**Kundenkonto-Ereignisse** (`CustomerAccount`, Ereignisse `RPP`, `RCC`, `BTC`)\n- Ereignisse mit `EventDate` >= `DateFrom` und < `DateTo`.\n- Enthalten, wenn eine manuelle Buchung verknüpft ist oder wenn die Einstellung `BookExportDatevExportAutomaticCAEvents` aktiv und der Ereignistyp als manuell markiert ist; zusätzlich lastschriftbezogene Einträge mit zugeordneter Rechnung, wenn `BookExportManualDtausToDatev` gesetzt ist.\n- `BankAccountNr` ist das Buchungskonto des Ereignistyps; `BTC` erhält das Plus-Zeichen, die übrigen das Minus-Zeichen.\n\n**Filter** (beide Teile): `ShopId` (Shop des Kunden), `CostCenter` (Kostenstelle des Shops), `Country` (Land der Rechnungs-/Auftragsadresse bzw. Kundenadresse), `AmoutFrom`/`AmoutTo` (auf den Absolutbetrag) und `BankAccountNr` (auf das ermittelte Bankkonto).\n\nDas Vorzeichen ist `s`/`h`, wenn die Einstellung `BookExportDatevPro` aktiv ist, sonst `+`/`-`. Sortierung nach `BankAccountNr`, `BankDate`, `Amount`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Ja | Beginn des Zeitraums (wird genau wie übergeben verwendet). |\n| `DateTo` | datetime | Ja | Ende des Zeitraums (wird genau wie übergeben verwendet; inklusive für Bankbuchungen, exklusive für Kundenkonto-Ereignisse). |\n| `ShopId` | varchar(3) | Nein | Optionale Shop-ID; nur Zahlungen von Kunden dieses Shops werden geliefert. |\n| `Country` | varchar(3) | Nein | Optionaler Ländercode der Rechnungs-/Auftragsadresse (Bankbuchungen) bzw. Kundenadresse (Kundenkonto-Ereignisse). |\n| `BankAccountNr` | varchar(10) | Nein | Optionales Buchungs-Bankkonto; wird mit der ermittelten Spalte `BankAccountNr` verglichen. Leerstring wird als NULL behandelt. |\n| `AmoutFrom` | money | Nein | Optionaler Mindest-Absolutbetrag. |\n| `AmoutTo` | money | Nein | Optionaler Höchst-Absolutbetrag. |\n| `CostCenter` | varchar(8) | Nein | Optionale Kostenstelle des Shops. Leerstring wird als NULL behandelt. |\n\n- Nur lesend; alle Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- Wegen `SetStartAndEndOfDay = 0` bedeutet ein `DateTo` von `2024-01-31` Mitternacht zu Beginn dieses Tages: Bankbuchungen dieses Tages nach 00:00 und Kundenkonto-Ereignisse dieses Tages sind **nicht** enthalten. Für den ganzen Tag z. B. `2024-01-31T23:59:59` übergeben.\n- Bankbuchungen verwenden eine inklusive Obergrenze (`BETWEEN`), Kundenkonto-Ereignisse eine exklusive (`<`).\n- Trotz des Kommentars \"Betragsbereich in €\" werden `AmoutFrom`/`AmoutTo` mit dem Absolutbetrag in der Währung der Bankbuchung bzw. des Ereignisses verglichen, ohne Umrechnung.\n- `ShopId` ist als `varchar(3)` deklariert; die interne Suche über das Shop-Kürzel (Werte länger als 3 Zeichen) kann über diesen Aufruf daher nicht greifen. Eine leere `ShopId` wird nicht als NULL behandelt und liefert keine Zeilen, leere Werte für `BankAccountNr` und `CostCenter` dagegen schon.\n- Kundenkonto-Ereignisse werden nur geliefert, wenn ihr Wechselkurs in der intern reduzierten Kursmenge enthalten ist (Kurse der Datenbankwährungsquelle innerhalb von ±2 Wochen für Währungen, die in den ausgewählten Bankbuchungen vorkommen).\n- Bankbuchungen ohne Bankkopf werden durch die Quelltyp-Filter ausgeschlossen.\n- Das Verhalten hängt von zahlreichen zur Laufzeit gelesenen Einstellungen ab (siehe Beschreibung); `dbo.SettingGet` und `pixi.GetDatabaseCurrency` liegen nicht vor, ihre genaue Semantik ist daher hier nicht dokumentiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetDatevExportWires"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n EUR\n +\n 119.0000\n \n 10045\n RE2024001234\n \n 2024-01-15T00:00:00\n 1200\n \n \n \n \n WEB-50012 Zahlung Rechnung RE2024001234\n 1.000000\n 100\n WEB-50012\n \n"
}
]
},
{
"name": "pixiGetPaymentDetailsForInvoice",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE2024-001234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Kundenkontoeintrag einer Rechnung samt aller zugeordneten Kontoeinträge und deren Bankzeilen- und Bankimportdaten.\n\nErmittelt die Zahlungssituation einer einzelnen Rechnung über das Kundenkonto (`CustomerAccount`).\n\n1. Die Rechnung wird über `InvoiceNr` in `Invoices` gesucht. Anschließend wird der Kundenkontoeintrag ermittelt, dessen `InvoiceRef` auf diese Rechnung verweist (Rechnungseintrag).\n2. Alle Kundenkontoeinträge, die in `CustomerAccountMatch` mit diesem Rechnungseintrag ausgeglichen wurden, werden gesammelt. Die Zuordnung wird in beide Richtungen ausgewertet (`CARef1` und `CARef2`), sodass Zahlungen, Gutschriften oder andere verknüpfte Einträge unabhängig von der Speicherrichtung gefunden werden.\n3. Für den Rechnungseintrag und alle zugeordneten Einträge wird je eine Zeile mit den Kontodaten geliefert. Stammt ein Eintrag aus einer Bankzeile (`BanklineRef`), werden die Daten der Bankzeile (`BankLines`) und der Bankimportdatei (`BankHeader`) ergänzt; andernfalls bleiben diese Spalten leer.\n\nSortierung: Zuerst der Rechnungseintrag selbst, danach die zugeordneten Einträge aufsteigend nach `CustomerAccountKey`.\n\nExistiert keine Rechnung mit der angegebenen Nummer oder hat sie keinen Kundenkontoeintrag, wird eine leere Ergebnismenge geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Ja | Nummer der Rechnung (`Invoices.InvoiceNr`), deren Zahlungsdetails abgefragt werden. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, es können daher nicht festgeschriebene Daten geliefert werden.\n- Es werden nur direkte Zuordnungen des Rechnungseintrags geliefert; Einträge, die nur indirekt (über einen anderen zugeordneten Eintrag) verknüpft sind, fehlen.\n- Teilen sich mehrere Rechnungen dieselbe `InvoiceNr`, liefert die Unterabfrage mehrere Werte und SQL Server meldet Fehler 512 (als `SqlMessage`).\n- Verweisen mehrere Kundenkontoeinträge auf die Rechnung, wird nur einer davon (nicht deterministisch) als Rechnungseintrag verwendet.\n- Die Spaltentypen sind im Code nicht sichtbar; die hier angegebenen Typen sind aus Spaltennamen und Verwendung abgeleitet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPaymentDetailsForInvoice"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE2024-001234\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Kundenkontoeintrag einer Rechnung samt aller zugeordneten Kontoeinträge und deren Bankzeilen- und Bankimportdaten.\n\nErmittelt die Zahlungssituation einer einzelnen Rechnung über das Kundenkonto (`CustomerAccount`).\n\n1. Die Rechnung wird über `InvoiceNr` in `Invoices` gesucht. Anschließend wird der Kundenkontoeintrag ermittelt, dessen `InvoiceRef` auf diese Rechnung verweist (Rechnungseintrag).\n2. Alle Kundenkontoeinträge, die in `CustomerAccountMatch` mit diesem Rechnungseintrag ausgeglichen wurden, werden gesammelt. Die Zuordnung wird in beide Richtungen ausgewertet (`CARef1` und `CARef2`), sodass Zahlungen, Gutschriften oder andere verknüpfte Einträge unabhängig von der Speicherrichtung gefunden werden.\n3. Für den Rechnungseintrag und alle zugeordneten Einträge wird je eine Zeile mit den Kontodaten geliefert. Stammt ein Eintrag aus einer Bankzeile (`BanklineRef`), werden die Daten der Bankzeile (`BankLines`) und der Bankimportdatei (`BankHeader`) ergänzt; andernfalls bleiben diese Spalten leer.\n\nSortierung: Zuerst der Rechnungseintrag selbst, danach die zugeordneten Einträge aufsteigend nach `CustomerAccountKey`.\n\nExistiert keine Rechnung mit der angegebenen Nummer oder hat sie keinen Kundenkontoeintrag, wird eine leere Ergebnismenge geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Ja | Nummer der Rechnung (`Invoices.InvoiceNr`), deren Zahlungsdetails abgefragt werden. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, es können daher nicht festgeschriebene Daten geliefert werden.\n- Es werden nur direkte Zuordnungen des Rechnungseintrags geliefert; Einträge, die nur indirekt (über einen anderen zugeordneten Eintrag) verknüpft sind, fehlen.\n- Teilen sich mehrere Rechnungen dieselbe `InvoiceNr`, liefert die Unterabfrage mehrere Werte und SQL Server meldet Fehler 512 (als `SqlMessage`).\n- Verweisen mehrere Kundenkontoeinträge auf die Rechnung, wird nur einer davon (nicht deterministisch) als Rechnungseintrag verwendet.\n- Die Spaltentypen sind im Code nicht sichtbar; die hier angegebenen Typen sind aus Spaltennamen und Verwendung abgeleitet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPaymentDetailsForInvoice"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n 88120\n INV\n 2024-03-04T10:15:00\n RE2024-001234\n -119.00\n 1\n 50311\n 0\n \n \n 10452\n 88257\n PAY\n 2024-03-07T00:00:00\n Zahlung RE2024-001234\n 119.00\n 1\n 7731\n 0\n 2024-03-07T00:00:00\n 2024-03-07T00:00:00\n 119.00\n RE2024-001234\n EUR\n Max Mustermann\n COBADEFFXXX\n DE89370400440532013000\n CAMT\n camt053_20240307.xml\n 2024-03-08T06:00:00\n \n"
}
]
},
{
"name": "pixiGetPaymenttypes",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die in Pixi angelegten Zahlungsarten, optional gefiltert nach Code, Zahlungstext, initialem Auftragsstatus oder XML-Tag.\n\nLiest die Zahlungsarten aus der Tabelle `Payments` und liefert für jede Zahlungsart `Code`, `PaymentText`, `IniOrderStatus` und `XMLTag`.\n\n- Parameter, die als Leerstring übergeben werden, gelten als nicht gesetzt (`NULL`).\n- Ist **kein** Parameter gesetzt, werden alle Zahlungsarten geliefert.\n- Sind ein oder mehrere Parameter gesetzt, wird eine Zahlungsart geliefert, wenn sie **mindestens einem** der übergebenen Werte entspricht:\n - `Code` gleich `Code`\n - `PaymentText` gleich `PaymentText`\n - `IniOrderStatus` gleich `IniOrderStatus`\n - `XMLTag` gleich `TagXML`\n\nAlle Vergleiche sind exakte Übereinstimmungen; eine Platzhaltersuche gibt es nicht. Eine Sortierung wird nicht vorgenommen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Code` | varchar(1) | Nein | Einstelliger Code der Zahlungsart. Leer bedeutet kein Filter auf den Code. |\n| `PaymentText` | varchar(32) | Nein | Exakter Text (Bezeichnung) der Zahlungsart. Leer bedeutet kein Filter auf den Text. |\n| `IniOrderStatus` | varchar(3) | Nein | Initialer Auftragsstatus, den Aufträge mit dieser Zahlungsart erhalten. Leer bedeutet kein Filter auf den Status. |\n| `TagXML` | varchar(32) | Nein | XML-Tag der Zahlungsart, verglichen mit der Spalte `XMLTag`. Leer bedeutet kein Filter auf das Tag. |\n\n- Die Filter werden mit **ODER** verknüpft, nicht mit UND. Werden z. B. `Code` und `IniOrderStatus` übergeben, werden Zahlungsarten geliefert, die einem der beiden Werte entsprechen, nicht nur solche, die beiden entsprechen.\n- Die Tabelle wird `WITH (NOLOCK)` gelesen; nicht festgeschriebene Änderungen können sichtbar sein.\n- Der Parameter für das XML-Tag heißt `TagXML`, die zurückgegebene Spalte dagegen `XMLTag`.\n- Da SQL Server nachfolgende Leerzeichen beim Stringvergleich ignoriert, gilt auch ein Wert aus reinen Leerzeichen als nicht gesetzt.\n- Die Spaltentypen des Ergebnisses sind im Code nicht sichtbar; die angegebenen Typen entsprechen den Parametertypen, die für die Vergleiche verwendet werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPaymenttypes"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die in Pixi angelegten Zahlungsarten, optional gefiltert nach Code, Zahlungstext, initialem Auftragsstatus oder XML-Tag.\n\nLiest die Zahlungsarten aus der Tabelle `Payments` und liefert für jede Zahlungsart `Code`, `PaymentText`, `IniOrderStatus` und `XMLTag`.\n\n- Parameter, die als Leerstring übergeben werden, gelten als nicht gesetzt (`NULL`).\n- Ist **kein** Parameter gesetzt, werden alle Zahlungsarten geliefert.\n- Sind ein oder mehrere Parameter gesetzt, wird eine Zahlungsart geliefert, wenn sie **mindestens einem** der übergebenen Werte entspricht:\n - `Code` gleich `Code`\n - `PaymentText` gleich `PaymentText`\n - `IniOrderStatus` gleich `IniOrderStatus`\n - `XMLTag` gleich `TagXML`\n\nAlle Vergleiche sind exakte Übereinstimmungen; eine Platzhaltersuche gibt es nicht. Eine Sortierung wird nicht vorgenommen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Code` | varchar(1) | Nein | Einstelliger Code der Zahlungsart. Leer bedeutet kein Filter auf den Code. |\n| `PaymentText` | varchar(32) | Nein | Exakter Text (Bezeichnung) der Zahlungsart. Leer bedeutet kein Filter auf den Text. |\n| `IniOrderStatus` | varchar(3) | Nein | Initialer Auftragsstatus, den Aufträge mit dieser Zahlungsart erhalten. Leer bedeutet kein Filter auf den Status. |\n| `TagXML` | varchar(32) | Nein | XML-Tag der Zahlungsart, verglichen mit der Spalte `XMLTag`. Leer bedeutet kein Filter auf das Tag. |\n\n- Die Filter werden mit **ODER** verknüpft, nicht mit UND. Werden z. B. `Code` und `IniOrderStatus` übergeben, werden Zahlungsarten geliefert, die einem der beiden Werte entsprechen, nicht nur solche, die beiden entsprechen.\n- Die Tabelle wird `WITH (NOLOCK)` gelesen; nicht festgeschriebene Änderungen können sichtbar sein.\n- Der Parameter für das XML-Tag heißt `TagXML`, die zurückgegebene Spalte dagegen `XMLTag`.\n- Da SQL Server nachfolgende Leerzeichen beim Stringvergleich ignoriert, gilt auch ein Wert aus reinen Leerzeichen als nicht gesetzt.\n- Die Spaltentypen des Ergebnisses sind im Code nicht sichtbar; die angegebenen Typen entsprechen den Parametertypen, die für die Vergleiche verwendet werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPaymenttypes"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n V\n Vorkasse\n VK\n PREPAYMENT\n \n \n R\n Rechnung\n AU\n INVOICE\n \n"
}
]
},
{
"name": "pixiGetPendingPayments",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert zu einem Stichtag nicht vollständig zugeordnete Zahlungen auf Kundenkonten, summiert je Zahlungsart oder als Einzelposten.\n\nListet Zahlungen auf Kundenkonten (`CustomerAccount`), die zu einem Stichtag noch offen, also nicht vollständig zugeordnet, waren.\n\n**Parameterbehandlung**\n- `Date`: Bei `NULL` oder einem Wert vor dem 01.01.1990 wird das aktuelle Datum mit Uhrzeit (`GETDATE()`) verwendet.\n- `Details`: `NULL` wird als `0` behandelt.\n- `ShopID`: Ein Leerstring wird als `NULL` behandelt, also ohne Shop-Filter.\n\n**Auswahl**\n1. Für jeden Kundenkontoposten wird aus `CustomerAccountLog` der letzte Log-Eintrag mit Ereignis `PAY` ermittelt, dessen `EventDate` echt vor `Date` liegt.\n2. Der Posten wird nur berücksichtigt, wenn `Amount - Matched` dieses `PAY`-Eintrags mindestens 0,01 beträgt.\n3. `OpenAmount` ist der Betrag des Kundenkontopostens abzüglich des `Matched`-Werts des letzten Log-Eintrags beliebigen Ereignistyps vor `Date`. Gibt es keinen solchen Eintrag, wird 0 abgezogen.\n4. Die Zahlungsart stammt aus der Zahlungsart des Auftrags (Lieferadresse, `APayment`) oder der Rechnung (`Payment`), die über `BankMatch` mit der Bankzeile verknüpft ist. Wird keine Zahlungsart gefunden, wird `ZZZ unbekannt` verwendet.\n5. Ist `ShopID` gesetzt, werden nur Kunden geliefert, deren `CustomerOf` gleich `ShopID` ist.\n\n**Währung**\n- Ist die Einstellung `MultiCurrencyEnabled` nicht `1`, werden die Beträge in der Originalwährung des Postens geliefert und `dbCurrency` ist `NULL`.\n- Ist `MultiCurrencyEnabled` = `1`, werden `Amount` und `OpenAmount` durch Division mit dem Wechselkurs in die Datenbankwährung (Hauswährung) umgerechnet. `dbCurrency` enthält dann den Code der Datenbankwährung.\n\n**Ausgabe**\n- `Details = 1`: eine Zeile je Kundenkontoposten, sortiert nach `PaymentType`, `CustRef` und `CustomerAccountKey`.\n- `Details = 0` (Standard): eine Zeile je `PaymentType` und `dbCurrency` mit summiertem `OpenAmount` und dem verwendeten Stichtag, sortiert nach `PaymentType`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Date` | datetime | Nein | Stichtag. Berücksichtigt werden nur Log-Einträge echt vor diesem Zeitpunkt. `NULL` oder Werte vor dem 01.01.1990 werden durch das aktuelle Datum mit Uhrzeit ersetzt. |\n| `Details` | bit | Nein | Wählt Einzelzeilen oder eine Summe je Zahlungsart. `NULL` wird als `0` behandelt. |\n| `ShopID` | varchar(3) | Nein | Optionaler Shop-Filter auf `CustomerOf` des Kunden. Leer oder `NULL` liefert alle Shops. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, daher können die Ergebnisse nicht festgeschriebene Daten enthalten.\n- Der Filter verwendet den letzten `PAY`-Log-Eintrag, `OpenAmount` dagegen den letzten Log-Eintrag beliebigen Ereignistyps. Beide Werte können daher voneinander abweichen.\n- Bei aktivierter Mehrwährung fallen Posten ohne passenden Wechselkurs zur Datenbankwährung durch Inner Joins weg (über `pixi.ExchRate`, Quelle aus Einstellung `DatabaseCurrencyExchRateSourceId`, Basiswährung aus Einstellung `HomeCurrency`).\n- Im Mehrwährungszweig filtert die Unterabfrage für den zugeordneten Betrag die Kursquelle über den äußeren Alias statt über ihren eigenen. Bei mehreren Kursquellen ist nicht deterministisch, welcher Kurs per `TOP 1` verwendet wird.\n- Der Join auf `Payments` verknüpft die Zahlungsart von Auftrag und Rechnung per ODER. Sind beide verknüpft und verschieden, kann ein Posten doppelt erscheinen und wird dann in der Summe doppelt gezählt.\n- Im Einwährungsmodus ist `dbCurrency` `NULL`, daher werden in der Summe Beträge unterschiedlicher Originalwährungen innerhalb einer Zahlungsart vermischt.\n- Der Stichtagsvergleich ist echt kleiner (`EventDate < Date`). Bei Übergabe nur eines Datums ist die Uhrzeit Mitternacht, Ereignisse dieses Tages sind also ausgeschlossen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPendingPayments"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert zu einem Stichtag nicht vollständig zugeordnete Zahlungen auf Kundenkonten, summiert je Zahlungsart oder als Einzelposten.\n\nListet Zahlungen auf Kundenkonten (`CustomerAccount`), die zu einem Stichtag noch offen, also nicht vollständig zugeordnet, waren.\n\n**Parameterbehandlung**\n- `Date`: Bei `NULL` oder einem Wert vor dem 01.01.1990 wird das aktuelle Datum mit Uhrzeit (`GETDATE()`) verwendet.\n- `Details`: `NULL` wird als `0` behandelt.\n- `ShopID`: Ein Leerstring wird als `NULL` behandelt, also ohne Shop-Filter.\n\n**Auswahl**\n1. Für jeden Kundenkontoposten wird aus `CustomerAccountLog` der letzte Log-Eintrag mit Ereignis `PAY` ermittelt, dessen `EventDate` echt vor `Date` liegt.\n2. Der Posten wird nur berücksichtigt, wenn `Amount - Matched` dieses `PAY`-Eintrags mindestens 0,01 beträgt.\n3. `OpenAmount` ist der Betrag des Kundenkontopostens abzüglich des `Matched`-Werts des letzten Log-Eintrags beliebigen Ereignistyps vor `Date`. Gibt es keinen solchen Eintrag, wird 0 abgezogen.\n4. Die Zahlungsart stammt aus der Zahlungsart des Auftrags (Lieferadresse, `APayment`) oder der Rechnung (`Payment`), die über `BankMatch` mit der Bankzeile verknüpft ist. Wird keine Zahlungsart gefunden, wird `ZZZ unbekannt` verwendet.\n5. Ist `ShopID` gesetzt, werden nur Kunden geliefert, deren `CustomerOf` gleich `ShopID` ist.\n\n**Währung**\n- Ist die Einstellung `MultiCurrencyEnabled` nicht `1`, werden die Beträge in der Originalwährung des Postens geliefert und `dbCurrency` ist `NULL`.\n- Ist `MultiCurrencyEnabled` = `1`, werden `Amount` und `OpenAmount` durch Division mit dem Wechselkurs in die Datenbankwährung (Hauswährung) umgerechnet. `dbCurrency` enthält dann den Code der Datenbankwährung.\n\n**Ausgabe**\n- `Details = 1`: eine Zeile je Kundenkontoposten, sortiert nach `PaymentType`, `CustRef` und `CustomerAccountKey`.\n- `Details = 0` (Standard): eine Zeile je `PaymentType` und `dbCurrency` mit summiertem `OpenAmount` und dem verwendeten Stichtag, sortiert nach `PaymentType`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Date` | datetime | Nein | Stichtag. Berücksichtigt werden nur Log-Einträge echt vor diesem Zeitpunkt. `NULL` oder Werte vor dem 01.01.1990 werden durch das aktuelle Datum mit Uhrzeit ersetzt. |\n| `Details` | bit | Nein | Wählt Einzelzeilen oder eine Summe je Zahlungsart. `NULL` wird als `0` behandelt. |\n| `ShopID` | varchar(3) | Nein | Optionaler Shop-Filter auf `CustomerOf` des Kunden. Leer oder `NULL` liefert alle Shops. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, daher können die Ergebnisse nicht festgeschriebene Daten enthalten.\n- Der Filter verwendet den letzten `PAY`-Log-Eintrag, `OpenAmount` dagegen den letzten Log-Eintrag beliebigen Ereignistyps. Beide Werte können daher voneinander abweichen.\n- Bei aktivierter Mehrwährung fallen Posten ohne passenden Wechselkurs zur Datenbankwährung durch Inner Joins weg (über `pixi.ExchRate`, Quelle aus Einstellung `DatabaseCurrencyExchRateSourceId`, Basiswährung aus Einstellung `HomeCurrency`).\n- Im Mehrwährungszweig filtert die Unterabfrage für den zugeordneten Betrag die Kursquelle über den äußeren Alias statt über ihren eigenen. Bei mehreren Kursquellen ist nicht deterministisch, welcher Kurs per `TOP 1` verwendet wird.\n- Der Join auf `Payments` verknüpft die Zahlungsart von Auftrag und Rechnung per ODER. Sind beide verknüpft und verschieden, kann ein Posten doppelt erscheinen und wird dann in der Summe doppelt gezählt.\n- Im Einwährungsmodus ist `dbCurrency` `NULL`, daher werden in der Summe Beträge unterschiedlicher Originalwährungen innerhalb einer Zahlungsart vermischt.\n- Der Stichtagsvergleich ist echt kleiner (`EventDate < Date`). Bei Übergabe nur eines Datums ist die Uhrzeit Mitternacht, Ereignisse dieses Tages sind also ausgeschlossen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPendingPayments"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Vorkasse\n 1250.4000\n 2024-04-01T00:00:00\n EUR\n \n \n ZZZ unbekannt\n 89.9000\n 2024-04-01T00:00:00\n EUR\n \n"
}
]
},
{
"name": "pixiGetPosJournal",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert das POS-Kassenbuch (Kassenereignisse mit Beträgen, Rechnungen und laufendem Kassenstand) für Zeitraum, Lager und Kasse.\n\nLiefert das Kassenbuch des Pixi-POS-Moduls. Die Arbeit übernimmt die interne Prozedur `CR_POS_Kassenbuch`. Ihre Zeilen werden zwischengespeichert und mit einer reduzierten Spaltenauswahl zurückgegeben.\n\nAblauf:\n\n1. Der gemeinsame API-Rahmen prüft die Aufrufhäufigkeit. Ist der für diese Funktion konfigurierte Mindestabstand noch nicht verstrichen, wird nur eine Statuszeile mit `ResultCode` `502` geliefert, und es werden keine Kassenbuchdaten gelesen.\n2. Standardwerte werden gesetzt:\n - `FromDate` und `ToDate` sind standardmäßig das heutige Datum.\n - `FromDate` wird unverändert inklusive Uhrzeit verwendet.\n - `ToDate` wird auf das Tagesende erweitert.\n3. POS-Sitzungsereignisse im Zeitraum werden ausgewählt. Ereignisse vom Typ `I` werden ausgeschlossen.\n - `LocID` schränkt auf ein Lager ein. `NULL` oder leer bedeutet alle Lager.\n - `RegisterID` schränkt auf eine Kasse ein. `''` oder `NULL` bedeutet alle Kassen.\n4. Jedes Ereignis wird, falls vorhanden, mit dem POS-Rechnungskopf und mit einer Beschreibung des Ereignistyps verknüpft:\n - `S` = POS Start\n - `E` = POS Stop\n - `P` = Invoice\n - `D` = Drawer Open\n5. `RegisterValue` ist die laufende Summe von `AmountIn - AmountOut` über alle ausgewählten Ereignisse mit einer `EventTime` bis einschließlich der aktuellen.\n6. `EventComment` kombiniert Ereigniskommentar und Rechnungskommentar, getrennt durch einen Zeilenumbruch.\n\nDie interne Prozedur sortiert nach `EventTime`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Nein | Beginn des Zeitraums (inklusive, Uhrzeit wird berücksichtigt). `NULL` bedeutet heute 00:00. |\n| `ToDate` | datetime | Nein | Ende des Zeitraums. Es wird auf das Tagesende erweitert; Uhrzeiten ab 12:00 runden auf den Folgetag. `NULL` bedeutet heute. |\n| `LocID` | varchar(3) | Nein | Lager der POS-Sitzung. `NULL` oder leer liefert alle Lager. |\n| `RegisterID` | varchar(30) | Nein | Kassen-ID. Leer oder `NULL` liefert alle Kassen. |\n| `ResultCode` | char(3) | Nein | Ergebniscode des API-Rahmens. |\n| `ResultText` | varchar(1024) | Nein | Ergebnistext: `OK` oder die Meldung zur Aufrufhäufigkeit. |\n\n- **Aufrufstatistik:** Der API-Rahmen schreibt den Aufrufzeitpunkt in `API_STATISTICS`. Das ist der einzige Schreibzugriff.\n- **Lesezugriffe:** Alle Lesezugriffe auf Kassenbuchdaten erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten erscheinen.\n- **Sortierung:** Das abschließende `SELECT` liest aus einer Tabellenvariable ohne eigenes `ORDER BY`. Die Sortierung nach `EventTime` ist daher nicht streng garantiert.\n- **Laufende Summe:** `RegisterValue` wird über alle ausgewählten Ereignisse berechnet, nicht je Kasse oder je Lager. Bei gleichzeitiger Abfrage mehrerer Kassen oder Lager werden diese vermischt. Der Wert beginnt außerdem bei 0 ab `FromDate`; ein Anfangsbestand vor dem Zeitraum wird nicht berücksichtigt.\n- **Ende des Zeitraums:** `ToDate` wird mit `CAST(... AS INTEGER)` umgewandelt. Bei `datetime` wird dabei auf den nächsten Tag gerundet, sodass ein `ToDate` mit Uhrzeit ab 12:00 den Zeitraum bis zum Ende des Folgetags erweitert. `ToDate` sollte ohne Uhrzeit übergeben werden.\n- **MwSt-Sätze:** Ereignisse werden per Inner Join mit den MwSt-Sätzen aus `fPixi_GetVATRate` (nicht beigefügt) verknüpft. Liefert diese Funktion für ein Lager keinen Satz, fehlen die Ereignisse dieses Lagers im Ergebnis.\n- **Immer leer:** `CreatedBy` und `UpdatedBy` sind immer `NULL`.\n- **Unbekannte Typen:** `EventDescription` ist `NULL` für andere Ereignistypen als `S`, `E`, `P` und `D`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPosJournal"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert das POS-Kassenbuch (Kassenereignisse mit Beträgen, Rechnungen und laufendem Kassenstand) für Zeitraum, Lager und Kasse.\n\nLiefert das Kassenbuch des Pixi-POS-Moduls. Die Arbeit übernimmt die interne Prozedur `CR_POS_Kassenbuch`. Ihre Zeilen werden zwischengespeichert und mit einer reduzierten Spaltenauswahl zurückgegeben.\n\nAblauf:\n\n1. Der gemeinsame API-Rahmen prüft die Aufrufhäufigkeit. Ist der für diese Funktion konfigurierte Mindestabstand noch nicht verstrichen, wird nur eine Statuszeile mit `ResultCode` `502` geliefert, und es werden keine Kassenbuchdaten gelesen.\n2. Standardwerte werden gesetzt:\n - `FromDate` und `ToDate` sind standardmäßig das heutige Datum.\n - `FromDate` wird unverändert inklusive Uhrzeit verwendet.\n - `ToDate` wird auf das Tagesende erweitert.\n3. POS-Sitzungsereignisse im Zeitraum werden ausgewählt. Ereignisse vom Typ `I` werden ausgeschlossen.\n - `LocID` schränkt auf ein Lager ein. `NULL` oder leer bedeutet alle Lager.\n - `RegisterID` schränkt auf eine Kasse ein. `''` oder `NULL` bedeutet alle Kassen.\n4. Jedes Ereignis wird, falls vorhanden, mit dem POS-Rechnungskopf und mit einer Beschreibung des Ereignistyps verknüpft:\n - `S` = POS Start\n - `E` = POS Stop\n - `P` = Invoice\n - `D` = Drawer Open\n5. `RegisterValue` ist die laufende Summe von `AmountIn - AmountOut` über alle ausgewählten Ereignisse mit einer `EventTime` bis einschließlich der aktuellen.\n6. `EventComment` kombiniert Ereigniskommentar und Rechnungskommentar, getrennt durch einen Zeilenumbruch.\n\nDie interne Prozedur sortiert nach `EventTime`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Nein | Beginn des Zeitraums (inklusive, Uhrzeit wird berücksichtigt). `NULL` bedeutet heute 00:00. |\n| `ToDate` | datetime | Nein | Ende des Zeitraums. Es wird auf das Tagesende erweitert; Uhrzeiten ab 12:00 runden auf den Folgetag. `NULL` bedeutet heute. |\n| `LocID` | varchar(3) | Nein | Lager der POS-Sitzung. `NULL` oder leer liefert alle Lager. |\n| `RegisterID` | varchar(30) | Nein | Kassen-ID. Leer oder `NULL` liefert alle Kassen. |\n| `ResultCode` | char(3) | Nein | Ergebniscode des API-Rahmens. |\n| `ResultText` | varchar(1024) | Nein | Ergebnistext: `OK` oder die Meldung zur Aufrufhäufigkeit. |\n\n- **Aufrufstatistik:** Der API-Rahmen schreibt den Aufrufzeitpunkt in `API_STATISTICS`. Das ist der einzige Schreibzugriff.\n- **Lesezugriffe:** Alle Lesezugriffe auf Kassenbuchdaten erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten erscheinen.\n- **Sortierung:** Das abschließende `SELECT` liest aus einer Tabellenvariable ohne eigenes `ORDER BY`. Die Sortierung nach `EventTime` ist daher nicht streng garantiert.\n- **Laufende Summe:** `RegisterValue` wird über alle ausgewählten Ereignisse berechnet, nicht je Kasse oder je Lager. Bei gleichzeitiger Abfrage mehrerer Kassen oder Lager werden diese vermischt. Der Wert beginnt außerdem bei 0 ab `FromDate`; ein Anfangsbestand vor dem Zeitraum wird nicht berücksichtigt.\n- **Ende des Zeitraums:** `ToDate` wird mit `CAST(... AS INTEGER)` umgewandelt. Bei `datetime` wird dabei auf den nächsten Tag gerundet, sodass ein `ToDate` mit Uhrzeit ab 12:00 den Zeitraum bis zum Ende des Folgetags erweitert. `ToDate` sollte ohne Uhrzeit übergeben werden.\n- **MwSt-Sätze:** Ereignisse werden per Inner Join mit den MwSt-Sätzen aus `fPixi_GetVATRate` (nicht beigefügt) verknüpft. Liefert diese Funktion für ein Lager keinen Satz, fehlen die Ereignisse dieses Lagers im Ergebnis.\n- **Immer leer:** `CreatedBy` und `UpdatedBy` sind immer `NULL`.\n- **Unbekannte Typen:** `EventDescription` ist `NULL` für andere Ereignistypen als `S`, `E`, `P` und `D`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPosJournal"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 2024-05-01T08:00:12\n KASSE01\n S\n POS Start\n 0.0000\n 150.0000\n 150.0000\n \n \n 2024-05-01T09:15:40\n KASSE01\n P\n Invoice\n K2024-000123\n 39.9000\n 0.0000\n 6.3700\n 0.0000\n 39.9000\n 189.9000\n \n"
}
]
},
{
"name": "pixiPayGetInvoicesToCapture",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n C\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert unbezahlte, ausgelieferte Rechnungen einer Zahlungsart, die zur Abbuchung anstehen, mit Auftrags-, Betrags-, Adress- und Kartendaten.\n\nErmittelt die Rechnungen, die eine Zahlungsanbindung (z. B. ein Kreditkartenanbieter) als Nächstes abbuchen soll, und liefert sie mit allen für die Abbuchung nötigen Daten.\n\nEine Rechnung wird gewählt, wenn **alle** folgenden Bedingungen gelten:\n\n- `Payment` entspricht `@PaymentCode`.\n- Es wurde noch nichts bezahlt (`PayedSum = 0`) und `Total > 0`.\n- Die Abbuchung ist nicht als erledigt markiert (`CCPPaymentDone` ist `N` oder NULL).\n- Die Rechnung wurde ausgescannt (`ScanOutDate` ist gesetzt).\n- `InvoiceKey` ist größer als `@FromInvoiceId`.\n- Eine der Wiederholungsbedingungen trifft zu:\n - noch kein Abbuchungsversuch (`CCPNumOfTries = 0`), oder\n - eine erneute Belastung ist angefordert (`CCPRecharge = 'Y'`), oder\n - 1 bis 3 Fehlversuche (`ccpSetFailTries`) und der letzte Fehlversuch (`ccpSetFailLastTime`) liegt mehr als 10 Minuten zurück, oder\n - `@ShowAll = 1`, wodurch die Wiederholungsbedingungen vollständig entfallen.\n\nEs werden höchstens `@RowCount` Rechnungen gewählt, aufsteigend sortiert nach `InvoiceKey`. Je Rechnung werden Rechnungsnummer, die kommagetrennte Liste der externen Auftragsnummern, Gesamtbetrag, bezahlter Betrag, abzubuchender Betrag (`Total - PayedSum`), die Summe der verknüpften Auftragspositionen im Status `ANG`, Währungscode, Shop (`CustomerOf` des Kunden), Karten- und Adressdaten der Rechnungsadresse sowie die Abbuchungsstatusfelder geliefert.\n\n**Paging:** Die `InvoiceId` der letzten gelieferten Zeile als `@FromInvoiceId` übergeben, um den nächsten Block zu erhalten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PaymentCode` | char(1) | Ja | Code der Zahlungsart; nur Rechnungen, deren Feld `Payment` diesem Wert entspricht, werden geliefert. |\n| `ShowAll` | bit | Nein | Bei 1 werden die Wiederholungsbedingungen (noch kein Versuch, erneute Belastung angefordert oder 1–3 Fehlversuche mit dem letzten älter als 10 Minuten) ignoriert. |\n| `RowCount` | int | Nein | Maximale Anzahl der gelieferten Rechnungen. |\n| `FromInvoiceId` | int | Nein | Nur Rechnungen mit einem `InvoiceKey` größer als dieser Wert werden geliefert; für Paging die zuletzt gelieferte `InvoiceId` übergeben. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, nicht festgeschriebene Änderungen können sichtbar sein.\n- Der Aufruf ändert keine Daten; das Markieren von Rechnungen als abgebucht oder fehlgeschlagen muss separat erfolgen.\n- `@ShowAll = 1` hebt nur die Wiederholungs-/Wartebedingung auf; alle anderen Filter (Zahlungsart, unbezahlt, ausgescannt, nicht erledigt) gelten weiterhin. Dabei werden auch Rechnungen mit mehr als 3 Fehlversuchen geliefert.\n- Die Begrenzung `TOP (@RowCount)` greift vor dem Join auf Währung, Kunde und Adresse. Rechnungen ohne passenden Datensatz dort entfallen, daher können weniger als `@RowCount` Zeilen geliefert werden, obwohl weitere Rechnungen existieren.\n- Da nur Rechnungen mit `PayedSum = 0` gewählt werden, entspricht `TotalToCapture` immer `Total`.\n- `Total_OrderCurr` ist ein Duplikat von `Total`; ein Code-Kommentar sieht die Entfernung vor, Clients sollten sich nicht darauf verlassen.\n- Das Ergebnis enthält sensible Kartendaten (Nummer, Ablaufdatum, CVC); entsprechend sorgfältig verarbeiten und protokollieren.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiPayGetInvoicesToCapture"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n C\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert unbezahlte, ausgelieferte Rechnungen einer Zahlungsart, die zur Abbuchung anstehen, mit Auftrags-, Betrags-, Adress- und Kartendaten.\n\nErmittelt die Rechnungen, die eine Zahlungsanbindung (z. B. ein Kreditkartenanbieter) als Nächstes abbuchen soll, und liefert sie mit allen für die Abbuchung nötigen Daten.\n\nEine Rechnung wird gewählt, wenn **alle** folgenden Bedingungen gelten:\n\n- `Payment` entspricht `@PaymentCode`.\n- Es wurde noch nichts bezahlt (`PayedSum = 0`) und `Total > 0`.\n- Die Abbuchung ist nicht als erledigt markiert (`CCPPaymentDone` ist `N` oder NULL).\n- Die Rechnung wurde ausgescannt (`ScanOutDate` ist gesetzt).\n- `InvoiceKey` ist größer als `@FromInvoiceId`.\n- Eine der Wiederholungsbedingungen trifft zu:\n - noch kein Abbuchungsversuch (`CCPNumOfTries = 0`), oder\n - eine erneute Belastung ist angefordert (`CCPRecharge = 'Y'`), oder\n - 1 bis 3 Fehlversuche (`ccpSetFailTries`) und der letzte Fehlversuch (`ccpSetFailLastTime`) liegt mehr als 10 Minuten zurück, oder\n - `@ShowAll = 1`, wodurch die Wiederholungsbedingungen vollständig entfallen.\n\nEs werden höchstens `@RowCount` Rechnungen gewählt, aufsteigend sortiert nach `InvoiceKey`. Je Rechnung werden Rechnungsnummer, die kommagetrennte Liste der externen Auftragsnummern, Gesamtbetrag, bezahlter Betrag, abzubuchender Betrag (`Total - PayedSum`), die Summe der verknüpften Auftragspositionen im Status `ANG`, Währungscode, Shop (`CustomerOf` des Kunden), Karten- und Adressdaten der Rechnungsadresse sowie die Abbuchungsstatusfelder geliefert.\n\n**Paging:** Die `InvoiceId` der letzten gelieferten Zeile als `@FromInvoiceId` übergeben, um den nächsten Block zu erhalten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PaymentCode` | char(1) | Ja | Code der Zahlungsart; nur Rechnungen, deren Feld `Payment` diesem Wert entspricht, werden geliefert. |\n| `ShowAll` | bit | Nein | Bei 1 werden die Wiederholungsbedingungen (noch kein Versuch, erneute Belastung angefordert oder 1–3 Fehlversuche mit dem letzten älter als 10 Minuten) ignoriert. |\n| `RowCount` | int | Nein | Maximale Anzahl der gelieferten Rechnungen. |\n| `FromInvoiceId` | int | Nein | Nur Rechnungen mit einem `InvoiceKey` größer als dieser Wert werden geliefert; für Paging die zuletzt gelieferte `InvoiceId` übergeben. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, nicht festgeschriebene Änderungen können sichtbar sein.\n- Der Aufruf ändert keine Daten; das Markieren von Rechnungen als abgebucht oder fehlgeschlagen muss separat erfolgen.\n- `@ShowAll = 1` hebt nur die Wiederholungs-/Wartebedingung auf; alle anderen Filter (Zahlungsart, unbezahlt, ausgescannt, nicht erledigt) gelten weiterhin. Dabei werden auch Rechnungen mit mehr als 3 Fehlversuchen geliefert.\n- Die Begrenzung `TOP (@RowCount)` greift vor dem Join auf Währung, Kunde und Adresse. Rechnungen ohne passenden Datensatz dort entfallen, daher können weniger als `@RowCount` Zeilen geliefert werden, obwohl weitere Rechnungen existieren.\n- Da nur Rechnungen mit `PayedSum = 0` gewählt werden, entspricht `TotalToCapture` immer `Total`.\n- `Total_OrderCurr` ist ein Duplikat von `Total`; ein Code-Kommentar sieht die Entfernung vor, Clients sollten sich nicht darauf verlassen.\n- Das Ergebnis enthält sensible Kartendaten (Nummer, Ablaufdatum, CVC); entsprechend sorgfältig verarbeiten und protokollieren.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiPayGetInvoicesToCapture"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n RE2024001234\n 100045678,100045679\n 149.90\n 0.00\n 0.00\n 149.90\n 149.90\n EUR\n SHOP1\n Max Mustermann\n 411111******1111\n 12/27\n \n Herr\n \n Max\n Mustermann\n Musterstr. 1\n Berlin\n 10115\n DE\n 030123456\n max@example.com\n 0\n N\n PAY-88231\n 0\n 58231\n \n"
}
]
},
{
"name": "pixiPayGetOrdersToAuthorize",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n K\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Aufträge mit Positionen im Status HAL, die für eine Zahlungsart zur Autorisierung anstehen, inklusive Beträgen, Karten- und Adressdaten.\n\nErmittelt Aufträge, die ein Zahlungsanbieter-Connector (z. B. für Kreditkarten) autorisieren soll, und liefert eine Zeile pro Auftrag.\n\nAblauf der Auswahl:\n\n1. Alle Aufträge mit mindestens einer Auftragsposition im Status `HAL` werden ermittelt.\n2. Berücksichtigt werden nur Aufträge, bei denen:\n - der Auftragskopf zuletzt vor mehr als **10 Minuten** geändert wurde (`updatedate`), damit der Auftrag vollständig ist,\n - die Zahlungsart der Auftragsadresse (`Addresses.aPayment`) gleich `PaymentCode` ist,\n - mindestens eine Bedingung erfüllt ist: `ccpNumOfTries` <= 3, `CCPReauthorizeYN` = `Y` (Neuautorisierung angefordert), `ShowAll` = 1 oder `ccpSetFailTries` zwischen 1 und 3 und `ccpSetFailLastTime` älter als 10 Minuten,\n - der Kunde nicht gesperrt ist (`Customers.SLocked` ungleich `Y`).\n3. Die ersten `RowCount` Aufträge werden übernommen, sortiert nach `ccpNumOfTries` aufsteigend, dann `OrderHeaderKey` aufsteigend (Aufträge mit weniger Versuchen zuerst).\n4. Für diese Aufträge wird `OrderLineAmount` der Positionen in den Status `ANG`, `HAL` und `AUS` getrennt summiert (fehlende Status zählen als 0).\n\nDas Ergebnis enthält Auftragssummen, Positionssummen je Status, Währung, Shop-ID, Karten- und Adressdaten der Auftragsadresse sowie die Autorisierungsfelder des Auftragskopfs. Die Ausgabe ist nach `OrderHeaderKey` aufsteigend sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PaymentCode` | char(1) | Ja | Kürzel der Zahlungsart; wird mit `Addresses.aPayment` der Auftragsadresse verglichen. |\n| `ShowAll` | bit | Nein | Bei 1 werden Aufträge unabhängig von der Anzahl bisheriger Autorisierungsversuche geliefert. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Aufträge. |\n\n- Nur lesend; alle permanenten Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- **Fallstrick:** Die Spalte `Addresses.eMail` wird unter dem Alias `CCPPaymentInfoOK` ausgegeben (eine Spalte `eMail` gibt es nicht). Die Spalte enthält daher die E-Mail-Adresse der Auftragsadresse, kein Zahlungsstatus-Kennzeichen.\n- Die Spalten `*_OrderCurr` enthalten exakt dieselben Werte wie die gleichnamigen Spalten ohne Suffix (laut Kommentar zur Entfernung vorgesehen); es findet keine Währungsumrechnung statt.\n- Das Ergebnis enthält sensible Kartendaten (`CardNumber`, `CardCVC`, `CardExpiration`); entsprechend sorgfältig behandeln und übertragen.\n- `ShowAll` = 1 hebt nur die Bedingungen zur Anzahl der Versuche auf; Wartezeit von 10 Minuten, Zahlungsart, `HAL`-Position und Kundensperre gelten weiterhin.\n- `RowCount` begrenzt die Anzahl der Aufträge, nicht der Positionen.\n- Die 10-Minuten-Grenze basiert auf der Serverzeit (`GETDATE()`).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiPayGetOrdersToAuthorize"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n K\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Aufträge mit Positionen im Status HAL, die für eine Zahlungsart zur Autorisierung anstehen, inklusive Beträgen, Karten- und Adressdaten.\n\nErmittelt Aufträge, die ein Zahlungsanbieter-Connector (z. B. für Kreditkarten) autorisieren soll, und liefert eine Zeile pro Auftrag.\n\nAblauf der Auswahl:\n\n1. Alle Aufträge mit mindestens einer Auftragsposition im Status `HAL` werden ermittelt.\n2. Berücksichtigt werden nur Aufträge, bei denen:\n - der Auftragskopf zuletzt vor mehr als **10 Minuten** geändert wurde (`updatedate`), damit der Auftrag vollständig ist,\n - die Zahlungsart der Auftragsadresse (`Addresses.aPayment`) gleich `PaymentCode` ist,\n - mindestens eine Bedingung erfüllt ist: `ccpNumOfTries` <= 3, `CCPReauthorizeYN` = `Y` (Neuautorisierung angefordert), `ShowAll` = 1 oder `ccpSetFailTries` zwischen 1 und 3 und `ccpSetFailLastTime` älter als 10 Minuten,\n - der Kunde nicht gesperrt ist (`Customers.SLocked` ungleich `Y`).\n3. Die ersten `RowCount` Aufträge werden übernommen, sortiert nach `ccpNumOfTries` aufsteigend, dann `OrderHeaderKey` aufsteigend (Aufträge mit weniger Versuchen zuerst).\n4. Für diese Aufträge wird `OrderLineAmount` der Positionen in den Status `ANG`, `HAL` und `AUS` getrennt summiert (fehlende Status zählen als 0).\n\nDas Ergebnis enthält Auftragssummen, Positionssummen je Status, Währung, Shop-ID, Karten- und Adressdaten der Auftragsadresse sowie die Autorisierungsfelder des Auftragskopfs. Die Ausgabe ist nach `OrderHeaderKey` aufsteigend sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PaymentCode` | char(1) | Ja | Kürzel der Zahlungsart; wird mit `Addresses.aPayment` der Auftragsadresse verglichen. |\n| `ShowAll` | bit | Nein | Bei 1 werden Aufträge unabhängig von der Anzahl bisheriger Autorisierungsversuche geliefert. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Aufträge. |\n\n- Nur lesend; alle permanenten Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- **Fallstrick:** Die Spalte `Addresses.eMail` wird unter dem Alias `CCPPaymentInfoOK` ausgegeben (eine Spalte `eMail` gibt es nicht). Die Spalte enthält daher die E-Mail-Adresse der Auftragsadresse, kein Zahlungsstatus-Kennzeichen.\n- Die Spalten `*_OrderCurr` enthalten exakt dieselben Werte wie die gleichnamigen Spalten ohne Suffix (laut Kommentar zur Entfernung vorgesehen); es findet keine Währungsumrechnung statt.\n- Das Ergebnis enthält sensible Kartendaten (`CardNumber`, `CardCVC`, `CardExpiration`); entsprechend sorgfältig behandeln und übertragen.\n- `ShowAll` = 1 hebt nur die Bedingungen zur Anzahl der Versuche auf; Wartezeit von 10 Minuten, Zahlungsart, `HAL`-Position und Kundensperre gelten weiterhin.\n- `RowCount` begrenzt die Anzahl der Aufträge, nicht der Positionen.\n- Die 10-Minuten-Grenze basiert auf der Serverzeit (`GETDATE()`).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiPayGetOrdersToAuthorize"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 104512\n SHOP-2024-0815\n 129.9000\n 125.0000\n 0.0000\n 4.9000\n 0.0000\n 125.0000\n 0.0000\n 125.0000\n 0.0000\n 125.0000\n 0.0000\n 4.9000\n EUR\n SHOP1\n Max Mustermann\n XXXXXXXXXXXX1111\n 12/27\n ***\n Herr\n \n Max\n Mustermann\n Musterstr. 1\n Berlin\n 10115\n DE\n 030123456\n max@example.com\n \n 0\n N\n \n 0\n \n"
}
]
},
{
"name": "pixiPaySetAuthorizationStatus",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100245\n \n PAY-7F3A9C21\n A12345\n Authorization approved\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Speichert das Ergebnis einer Zahlungsautorisierung für einen Auftrag, gibt HAL-Auftragspositionen frei oder belässt sie und schreibt einen Zahlungs-Logeintrag.\n\nWird von einem externen Zahlungsanbieter (protokolliert als *pixi Apps Payment Provider*) genutzt, um das Ergebnis einer Autorisierung für einen Auftrag zu melden.\n\n1. Der Auftrag wird über `OrderNr` in `OrderHeader` gesucht. Daraus werden Kundenreferenz, Rechnungsadressreferenz, Währungscode (`Currency.CodeA`) und das `CustomerOf` (Shop) des Kunden gelesen. Außerdem wird die Summe von `qty * price` aller Auftragspositionen im Status `HAL` berechnet.\n2. Abhängig von `Success`:\n - `1` (autorisiert): Auftragspositionen im Status `HAL` werden auf `ANG` gesetzt; der Logeintrag erhält Transaktionstyp `AU` und Code `AUTHORIZED`.\n - `0` (abgelehnt, Standard): Auftragspositionen bleiben im Status `HAL`; der Logeintrag erhält Typ `DE` und Code `AUTH DECLINED`; der Fehlversuchszähler `ccpSetFailTries` des Auftrags wird um 1 erhöht.\n3. Der Auftragskopf wird aktualisiert: `ccpNumOfTries` wird um 1 erhöht, `CCPLastAuthCode` = `AuthCode`, `ccpPayID` = `AuthID`, `CCPPaymentInfoOK` = `Y`, `CCPReauthorizeYN` = `N`, `ccpSetFailLastTime` und `UpdateDate` = aktuelle Zeit, `UpdateEmp` = `API Call PaySetAuth`.\n4. Alle Auftragspositionen des Auftrags im Status `HAL` erhalten den neuen Status (siehe Schritt 2), inklusive `UpdateEmp`/`UpdateDate`.\n5. In `CCPTranLog` wird eine Zeile mit Vendor `AP`, dem Shop (`CustomerOf`), der Auftragsnummer, `Message` als Notiz, dem berechneten `HAL`-Betrag als Gesamtbetrag, Kunden- und Rechnungsadressreferenz sowie dem Währungscode eingefügt.\n\nDer Aufruf liefert keine Ergebnismenge.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Pixi-Auftragsnummer des Auftrags, dessen Autorisierungsergebnis gemeldet wird. |\n| `Success` | bit | Nein | Ergebnis der Autorisierung. |\n| `AuthID` | varchar(50) | Ja | Zahlungs-/Autorisierungs-ID des Anbieters; wird in `OrderHeader.ccpPayID` gespeichert. |\n| `AuthCode` | varchar(50) | Ja | Autorisierungscode des Anbieters; wird in `OrderHeader.CCPLastAuthCode` gespeichert. |\n| `Message` | varchar(200) | Ja | Freitext-Meldung des Anbieters; wird als Notiz (`CCPNote`) im Transaktionslog gespeichert. |\n\n- Alle Änderungen laufen in einer Transaktion (bzw. einem Savepoint, falls bereits eine Transaktion offen ist). Bei einem Fehler werden die Änderungen zurückgerollt und `log.InsertError` (nicht beigefügt) aufgerufen; der Code selbst wirft den Fehler nicht erneut, der Aufrufer erhält daher eventuell keinen Fehlerhinweis.\n- Existiert `OrderNr` nicht, werden weder Auftragskopf noch Positionen geändert, aber trotzdem eine `CCPTranLog`-Zeile mit leeren (NULL) Werten für Shop, Kunde, Adresse und Währung eingefügt. Es wird kein Fehler gemeldet.\n- `CCPPaymentInfoOK` wird auf `Y` gesetzt und `ccpSetFailLastTime` aktualisiert, auch wenn `Success` = 0 ist.\n- `ccpSetFailTries` wird ohne `ISNULL` erhöht; ist die Spalte NULL, bleibt sie NULL.\n- Der Betrag wird über `Order_Id` berechnet, die zu ändernden Positionen werden über `OrderNr` ermittelt.\n- Lesezugriffe verwenden `NOLOCK`, Updates `ROWLOCK`.\n- `AuthID`, `AuthCode` und `Message` haben keinen Standardwert und müssen übergeben werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiPaySetAuthorizationStatus"
},
"response": []
},
{
"name": "pixiPaySetInvoiceCapture",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE1000123\n 1\n pay_8f3a21c9\n CAPTURE_OK\n Capture confirmed by provider\n 119.90\n \n 0\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Verarbeitet das Ergebnis eines Zahlungseinzugs (Capture) zu einer Rechnung, bucht sie als bezahlt oder setzt sie auf unbezahlt zurück und protokolliert dies in CCPTranLog.\n\nVerarbeitet das Ergebnis eines Zahlungseinzugs (Capture), das ein externer Zahlungsanbieter (\"pixi Apps Payment Provider\") für die Rechnung `InvoiceNr` meldet.\n\nZunächst wird die Rechnung zusammen mit Kunde und Währung gelesen (Shop `CustomerOf` des Kunden, `CustRef`, `AddrRef`, Währungscode). Alle Änderungen laufen in einer Transaktion (bzw. in einem Savepoint, falls bereits eine Transaktion offen ist).\n\n**`Success` = 1 (Einzug erfolgreich)**\n1. Aufruf der internen Prozedur `pixi_SetInvoicePaid` mit `paid = 1`, `EventID` und `PaidSum = CaptureSum`. Diese legt im Kundenkonto ein manuelles Buchungsereignis an und gleicht es mit der Rechnung ab. `EventID` muss ein manuelles, positives Kundenkonto-Ereignis sein, sonst wird keine Buchung erzeugt.\n2. Bei `SetRemainingOrdersToHAL` = 1 werden alle Auftragspositionen mit Status `ANG`, die zu einem Auftrag (gleiche `OrderNr`) mit mindestens einer Position auf dieser Rechnung gehören, auf Status `HAL` gesetzt.\n3. Eintrag in `CCPTranLog` mit Transaktionstyp `CA` und Fehlercode `CAPTURED`, Notiz `Message`, Gesamtbetrag `CaptureSum` und Rechnungswährung.\n4. Rückgabe `Status` = `Success` mit der Meldung *Successfully created CA manual booking event for InvoiceNr …*.\n\n**`Success` = 0 (Einzug fehlgeschlagen)**\n1. Aktualisierung der Rechnung: `ccpSetFailTries` wird erhöht, `CCPNumOfTries` und `ccpSetFailLastTime` gesetzt, `PayedSum` auf 0 und `Payed` auf NULL zurückgesetzt, `CCPPaymentDone` und `CCPReCharge` auf `N` gesetzt.\n2. Die verbleibenden `ANG`-Auftragspositionen der betroffenen Aufträge werden immer auf `HAL` gesetzt (unabhängig von `SetRemainingOrdersToHAL`).\n3. Eintrag in `CCPTranLog` mit Transaktionstyp `ER` und Fehlercode `CAPTURED FAILED`.\n4. Rückgabe `Status` = `Success` mit der Meldung *Reset payment data to unpaid for InvoiceNr …*.\n\nBei einem Fehler wird die Transaktion zurückgerollt und eine Zeile mit `Status` = `Error` und der SQL-Fehlermeldung geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Ja | Nummer der Rechnung, deren Capture-Ergebnis gemeldet wird. |\n| `Success` | bit | Ja | Ergebnis des Einzugs beim Zahlungsanbieter. |\n| `PayID` | varchar(50) | Ja | Zahlungs-ID des Anbieters. Pflichtparameter, wird aber nicht verwendet. |\n| `PayCode` | varchar(50) | Ja | Zahlungscode des Anbieters. Pflichtparameter, wird aber nicht verwendet. |\n| `Message` | varchar(200) | Ja | Freitext, der als Notiz (`CCPNote`) im CCP-Transaktionsprotokoll gespeichert wird. |\n| `CaptureSum` | money | Ja | Eingezogener Betrag; wird als Gesamtbetrag im CCP-Protokoll gespeichert und als `PaidSum` an `pixi_SetInvoicePaid` übergeben. |\n| `EventID` | varchar(3) | Nein | Kundenkonto-Ereignis für die manuelle Zahlungsbuchung bei `Success` = 1. Muss ein manuelles, positives Ereignis sein; ohne Angabe wird keine Buchung erzeugt. |\n| `SetRemainingOrdersToHAL` | bit | Ja | Nur bei `Success` = 1: ob verbleibende `ANG`-Positionen der fakturierten Aufträge auf `HAL` gesetzt werden. Im Fehlerzweig geschieht dies immer. |\n\n- Fehler in `pixi_SetInvoicePaid` (z. B. Rechnung existiert nicht, Rechnung bereits bezahlt, `EventID` fehlt oder ist kein manuelles positives Ereignis) werden abgefangen und nur ins Fehlerprotokoll (`log.InsertError`) geschrieben. Der Aufruf liefert trotzdem `Status` = `Success` und schreibt den `CCPTranLog`-Eintrag; eine `Success`-Zeile garantiert also nicht, dass die Zahlung gebucht wurde.\n- Im beigefügten `pixi_SetInvoicePaid` wird der offene Betrag der Rechnung im Kundenkonto gebucht; `CaptureSum` wird dort nicht als Buchungsbetrag verwendet, sondern nur in `CCPTranLog` gespeichert.\n- `PayID` und `PayCode` sind Pflichtparameter, werden aber nicht verwendet.\n- Jeder Wert von `Success` außer 1 (auch NULL) führt in den Fehlerzweig.\n- `CCPNumOfTries` wird aus `ccpSetFailTries` + 1 gesetzt, nicht aus dem eigenen bisherigen Wert.\n- Wird die Rechnung (bzw. der Join auf Kunde/Währung) nicht gefunden, werden weder Rechnung noch Auftragspositionen geändert, aber ein Protokolleintrag mit leeren Referenzen wird versucht.\n- Änderungen an Auftragspositionen erfolgen mit `UpdateEmp` = `API Call PaySetAuth`, an Rechnungen mit `CCP Process`. Lesezugriffe nutzen `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiPaySetInvoiceCapture"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE1000123\n 1\n pay_8f3a21c9\n CAPTURE_OK\n Capture confirmed by provider\n 119.90\n \n 0\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Verarbeitet das Ergebnis eines Zahlungseinzugs (Capture) zu einer Rechnung, bucht sie als bezahlt oder setzt sie auf unbezahlt zurück und protokolliert dies in CCPTranLog.\n\nVerarbeitet das Ergebnis eines Zahlungseinzugs (Capture), das ein externer Zahlungsanbieter (\"pixi Apps Payment Provider\") für die Rechnung `InvoiceNr` meldet.\n\nZunächst wird die Rechnung zusammen mit Kunde und Währung gelesen (Shop `CustomerOf` des Kunden, `CustRef`, `AddrRef`, Währungscode). Alle Änderungen laufen in einer Transaktion (bzw. in einem Savepoint, falls bereits eine Transaktion offen ist).\n\n**`Success` = 1 (Einzug erfolgreich)**\n1. Aufruf der internen Prozedur `pixi_SetInvoicePaid` mit `paid = 1`, `EventID` und `PaidSum = CaptureSum`. Diese legt im Kundenkonto ein manuelles Buchungsereignis an und gleicht es mit der Rechnung ab. `EventID` muss ein manuelles, positives Kundenkonto-Ereignis sein, sonst wird keine Buchung erzeugt.\n2. Bei `SetRemainingOrdersToHAL` = 1 werden alle Auftragspositionen mit Status `ANG`, die zu einem Auftrag (gleiche `OrderNr`) mit mindestens einer Position auf dieser Rechnung gehören, auf Status `HAL` gesetzt.\n3. Eintrag in `CCPTranLog` mit Transaktionstyp `CA` und Fehlercode `CAPTURED`, Notiz `Message`, Gesamtbetrag `CaptureSum` und Rechnungswährung.\n4. Rückgabe `Status` = `Success` mit der Meldung *Successfully created CA manual booking event for InvoiceNr …*.\n\n**`Success` = 0 (Einzug fehlgeschlagen)**\n1. Aktualisierung der Rechnung: `ccpSetFailTries` wird erhöht, `CCPNumOfTries` und `ccpSetFailLastTime` gesetzt, `PayedSum` auf 0 und `Payed` auf NULL zurückgesetzt, `CCPPaymentDone` und `CCPReCharge` auf `N` gesetzt.\n2. Die verbleibenden `ANG`-Auftragspositionen der betroffenen Aufträge werden immer auf `HAL` gesetzt (unabhängig von `SetRemainingOrdersToHAL`).\n3. Eintrag in `CCPTranLog` mit Transaktionstyp `ER` und Fehlercode `CAPTURED FAILED`.\n4. Rückgabe `Status` = `Success` mit der Meldung *Reset payment data to unpaid for InvoiceNr …*.\n\nBei einem Fehler wird die Transaktion zurückgerollt und eine Zeile mit `Status` = `Error` und der SQL-Fehlermeldung geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Ja | Nummer der Rechnung, deren Capture-Ergebnis gemeldet wird. |\n| `Success` | bit | Ja | Ergebnis des Einzugs beim Zahlungsanbieter. |\n| `PayID` | varchar(50) | Ja | Zahlungs-ID des Anbieters. Pflichtparameter, wird aber nicht verwendet. |\n| `PayCode` | varchar(50) | Ja | Zahlungscode des Anbieters. Pflichtparameter, wird aber nicht verwendet. |\n| `Message` | varchar(200) | Ja | Freitext, der als Notiz (`CCPNote`) im CCP-Transaktionsprotokoll gespeichert wird. |\n| `CaptureSum` | money | Ja | Eingezogener Betrag; wird als Gesamtbetrag im CCP-Protokoll gespeichert und als `PaidSum` an `pixi_SetInvoicePaid` übergeben. |\n| `EventID` | varchar(3) | Nein | Kundenkonto-Ereignis für die manuelle Zahlungsbuchung bei `Success` = 1. Muss ein manuelles, positives Ereignis sein; ohne Angabe wird keine Buchung erzeugt. |\n| `SetRemainingOrdersToHAL` | bit | Ja | Nur bei `Success` = 1: ob verbleibende `ANG`-Positionen der fakturierten Aufträge auf `HAL` gesetzt werden. Im Fehlerzweig geschieht dies immer. |\n\n- Fehler in `pixi_SetInvoicePaid` (z. B. Rechnung existiert nicht, Rechnung bereits bezahlt, `EventID` fehlt oder ist kein manuelles positives Ereignis) werden abgefangen und nur ins Fehlerprotokoll (`log.InsertError`) geschrieben. Der Aufruf liefert trotzdem `Status` = `Success` und schreibt den `CCPTranLog`-Eintrag; eine `Success`-Zeile garantiert also nicht, dass die Zahlung gebucht wurde.\n- Im beigefügten `pixi_SetInvoicePaid` wird der offene Betrag der Rechnung im Kundenkonto gebucht; `CaptureSum` wird dort nicht als Buchungsbetrag verwendet, sondern nur in `CCPTranLog` gespeichert.\n- `PayID` und `PayCode` sind Pflichtparameter, werden aber nicht verwendet.\n- Jeder Wert von `Success` außer 1 (auch NULL) führt in den Fehlerzweig.\n- `CCPNumOfTries` wird aus `ccpSetFailTries` + 1 gesetzt, nicht aus dem eigenen bisherigen Wert.\n- Wird die Rechnung (bzw. der Join auf Kunde/Währung) nicht gefunden, werden weder Rechnung noch Auftragspositionen geändert, aber ein Protokolleintrag mit leeren Referenzen wird versucht.\n- Änderungen an Auftragspositionen erfolgen mit `UpdateEmp` = `API Call PaySetAuth`, an Rechnungen mit `CCP Process`. Lesezugriffe nutzen `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiPaySetInvoiceCapture"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n Successfully created CA manual booking event for InvoiceNr RE1000123\n \n"
}
]
},
{
"name": "pixiReadCustomerAccount",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Buchungen des Kundenkontos (CustomerAccount) per Schlüssel, als Schlüsselbereich mit Paging oder gefiltert nach Anlage- und/oder Änderungsdatum.\n\nLiest Zeilen aus der Tabelle `CustomerAccount`, dem Kundenkonto. Die Buchungen verweisen auf Rechnungen, Bankzeilen, DTAUS-Sätze und manuelle Buchungen. Die Parameter wählen genau einen der folgenden Modi, geprüft in dieser Reihenfolge:\n\n1. **Anlage- oder Änderungsdatum**: `CreateAndUpdateDateFrom` und/oder `CreateAndUpdateDateTo` ist gesetzt. Liefert Einträge mit `CustomerAccountKey` > `CustomerAccountKey`.\n - Von-Bedingung: `CreateDate` >= von **oder** `UpdateDate` >= von.\n - Bis-Bedingung: `CreateDate` < bis **oder** `UpdateDate` < bis.\n2. **Anlagedatum**: `CreateDateFrom` und/oder `CreateDateTo` ist gesetzt. Liefert Einträge mit `CustomerAccountKey` > `CustomerAccountKey` und `CreateDate` im halboffenen Bereich [von, bis).\n3. **Änderungsdatum**: `UpdateDateFrom` und/oder `UpdateDateTo` ist gesetzt. Wie Modus 2, jedoch mit `UpdateDate`.\n4. **Schlüsselbereich**: `RowCount` ist übergeben und kein Datum gesetzt. Liefert alle Einträge mit `CustomerAccountKey` > `CustomerAccountKey`.\n5. **Einzelner Eintrag**: andernfalls. Liefert den Eintrag mit genau diesem `CustomerAccountKey`.\n\nDie Modi 1 bis 4 sind aufsteigend nach `CustomerAccountKey` sortiert. Ist `RowCount` ungleich 0, wird die Anzahl der zurückgegebenen Zeilen auf diesen Wert begrenzt (`SET ROWCOUNT`).\n\nFür Keyset-Paging wird der zuletzt erhaltene `CustomerAccountKey` beim nächsten Aufruf als `CustomerAccountKey` übergeben.\n\n`ExchRateId` wird nur gefüllt, wenn die Einstellung `MultiCurrencyEnabled` den Wert `1` hat; sonst ist die Spalte immer NULL.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustomerAccountKey` | int | Nein | Im Einzelmodus der Schlüssel des gewünschten Eintrags. In allen anderen Modi werden Einträge mit größerem Schlüssel geliefert (Paging-Start). NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `CreateDate`. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `CreateDate`. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `UpdateDate`. Wird nur verwendet, wenn weder ein Anlagedatum noch ein kombinierter Datumsparameter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `UpdateDate`. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusive); trifft zu, wenn `CreateDate` oder `UpdateDate` größer oder gleich diesem Wert ist. Hat Vorrang vor allen anderen Datumsparametern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (exklusiv); trifft zu, wenn `CreateDate` oder `UpdateDate` kleiner als dieser Wert ist. |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen (0 oder NULL = unbegrenzt). Wird der Parameter ohne Datumsparameter übergeben (auch 0), liefert der Aufruf den Schlüsselbereich oberhalb von `CustomerAccountKey` statt eines einzelnen Eintrags. |\n\n- Liest mit `NOLOCK`; nicht festgeschriebene Daten können geliefert werden.\n- Wird `CustomerAccountKey` weggelassen, wird `0` verwendet. Ohne Parameter läuft der Aufruf daher im Einzelmodus für Schlüssel `0` und liefert normalerweise keine Zeile. Der abschließende Zweig \"keine Daten\" im Code ist nie erreichbar.\n- `RowCount` = `0` gilt für Modus 4 trotzdem als \"übergeben\". Der Aufruf liefert dann **alle** Einträge oberhalb des Schlüssels ohne Zeilenbegrenzung.\n- Im kombinierten Datumsmodus ist die ODER-Logik großzügig. Ein Eintrag passt, wenn irgendeines seiner beiden Daten die Von-Bedingung erfüllt und irgendeines die Bis-Bedingung. Das muss nicht dasselbe Datum sein.\n- Die Datumsparameter-Gruppen werden nicht kombiniert. Es gilt nur die erste gesetzte Gruppe (in der Reihenfolge der Modi); die übrigen Gruppen werden ignoriert.\n- Die Spaltentypen von `CustomerAccount` sind nicht Teil des vorliegenden Codes; die angegebenen Spaltentypen sind teilweise angenommen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadCustomerAccount"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Buchungen des Kundenkontos (CustomerAccount) per Schlüssel, als Schlüsselbereich mit Paging oder gefiltert nach Anlage- und/oder Änderungsdatum.\n\nLiest Zeilen aus der Tabelle `CustomerAccount`, dem Kundenkonto. Die Buchungen verweisen auf Rechnungen, Bankzeilen, DTAUS-Sätze und manuelle Buchungen. Die Parameter wählen genau einen der folgenden Modi, geprüft in dieser Reihenfolge:\n\n1. **Anlage- oder Änderungsdatum**: `CreateAndUpdateDateFrom` und/oder `CreateAndUpdateDateTo` ist gesetzt. Liefert Einträge mit `CustomerAccountKey` > `CustomerAccountKey`.\n - Von-Bedingung: `CreateDate` >= von **oder** `UpdateDate` >= von.\n - Bis-Bedingung: `CreateDate` < bis **oder** `UpdateDate` < bis.\n2. **Anlagedatum**: `CreateDateFrom` und/oder `CreateDateTo` ist gesetzt. Liefert Einträge mit `CustomerAccountKey` > `CustomerAccountKey` und `CreateDate` im halboffenen Bereich [von, bis).\n3. **Änderungsdatum**: `UpdateDateFrom` und/oder `UpdateDateTo` ist gesetzt. Wie Modus 2, jedoch mit `UpdateDate`.\n4. **Schlüsselbereich**: `RowCount` ist übergeben und kein Datum gesetzt. Liefert alle Einträge mit `CustomerAccountKey` > `CustomerAccountKey`.\n5. **Einzelner Eintrag**: andernfalls. Liefert den Eintrag mit genau diesem `CustomerAccountKey`.\n\nDie Modi 1 bis 4 sind aufsteigend nach `CustomerAccountKey` sortiert. Ist `RowCount` ungleich 0, wird die Anzahl der zurückgegebenen Zeilen auf diesen Wert begrenzt (`SET ROWCOUNT`).\n\nFür Keyset-Paging wird der zuletzt erhaltene `CustomerAccountKey` beim nächsten Aufruf als `CustomerAccountKey` übergeben.\n\n`ExchRateId` wird nur gefüllt, wenn die Einstellung `MultiCurrencyEnabled` den Wert `1` hat; sonst ist die Spalte immer NULL.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CustomerAccountKey` | int | Nein | Im Einzelmodus der Schlüssel des gewünschten Eintrags. In allen anderen Modi werden Einträge mit größerem Schlüssel geliefert (Paging-Start). NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `CreateDate`. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `CreateDate`. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `UpdateDate`. Wird nur verwendet, wenn weder ein Anlagedatum noch ein kombinierter Datumsparameter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusiv) für `UpdateDate`. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusive); trifft zu, wenn `CreateDate` oder `UpdateDate` größer oder gleich diesem Wert ist. Hat Vorrang vor allen anderen Datumsparametern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (exklusiv); trifft zu, wenn `CreateDate` oder `UpdateDate` kleiner als dieser Wert ist. |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen (0 oder NULL = unbegrenzt). Wird der Parameter ohne Datumsparameter übergeben (auch 0), liefert der Aufruf den Schlüsselbereich oberhalb von `CustomerAccountKey` statt eines einzelnen Eintrags. |\n\n- Liest mit `NOLOCK`; nicht festgeschriebene Daten können geliefert werden.\n- Wird `CustomerAccountKey` weggelassen, wird `0` verwendet. Ohne Parameter läuft der Aufruf daher im Einzelmodus für Schlüssel `0` und liefert normalerweise keine Zeile. Der abschließende Zweig \"keine Daten\" im Code ist nie erreichbar.\n- `RowCount` = `0` gilt für Modus 4 trotzdem als \"übergeben\". Der Aufruf liefert dann **alle** Einträge oberhalb des Schlüssels ohne Zeilenbegrenzung.\n- Im kombinierten Datumsmodus ist die ODER-Logik großzügig. Ein Eintrag passt, wenn irgendeines seiner beiden Daten die Von-Bedingung erfüllt und irgendeines die Bis-Bedingung. Das muss nicht dasselbe Datum sein.\n- Die Datumsparameter-Gruppen werden nicht kombiniert. Es gilt nur die erste gesetzte Gruppe (in der Reihenfolge der Modi); die übrigen Gruppen werden ignoriert.\n- Die Spaltentypen von `CustomerAccount` sind nicht Teil des vorliegenden Codes; die angegebenen Spaltentypen sind teilweise angenommen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadCustomerAccount"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1201\n 4711\n INV\n 2024-01-15T10:22:00\n RE-2024-000123\n -59.90\n 0\n 88123\n 0\n API\n 2024-01-15T10:22:00\n API\n 2024-01-15T10:22:00\n 1\n EUR\n \n \n 1202\n 4711\n PAY\n 2024-01-16T08:05:00\n Bank transfer\n 59.90\n 1\n 30551\n 0\n SYS\n 2024-01-16T08:05:00\n SYS\n 2024-01-16T08:05:00\n 2\n EUR\n \n"
}
]
},
{
"name": "pixiSetCreditCardInfo",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Maskiert die gespeicherte Kreditkartennummer und CVC der Adresse eines Auftrags und/oder speichert einen Autorisierungscode am Auftrag.\n\nAktualisiert kreditkartenbezogene Daten für den über `OrderNr` angegebenen Auftrag. Abhängig von den Parametern laufen zwei voneinander unabhängige Schritte:\n\n1. **Maskierung** (wenn `ScrambleData` = 1, Standard): Die vom Auftrag referenzierte Adresse (`OrderHeader.AddrRef`) wird ermittelt. Enthält deren Kartennummer `ACardNr` noch nicht `****`, wird sie durch `*************` gefolgt von den letzten vier Zeichen der ursprünglichen Nummer ersetzt, und die Kartenprüfnummer `CCCVC` wird auf `***` gesetzt.\n2. **Autorisierungscode** (wenn `AuthCode` nicht NULL ist): Der Wert wird in `OrderHeader.ccpPayID` des Auftrags geschrieben.\n\nBeide Schritte können in einem Aufruf kombiniert werden. Die Prozedur liefert keine Ergebnismenge, sondern setzt nur einen Rückgabewert: `0`, wenn mindestens eine Zeile aktualisiert wurde, sonst `1`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Nummer des Auftrags (`OrderHeader.OrderNR`), dessen Kreditkartendaten aktualisiert werden. |\n| `ScrambleData` | bit | Nein | Legt fest, ob Kartennummer und CVC der Auftragsadresse maskiert werden. |\n| `AuthCode` | varchar(50) | Nein | Autorisierungscode bzw. Zahlungs-ID, der in `OrderHeader.ccpPayID` gespeichert wird. Bei NULL bleibt das Feld unverändert. |\n\n- Der Rückgabewert (`0`/`1`) ist ein T-SQL-`RETURN`-Wert und wird nicht als Zeile geliefert; SOAP-Clients sehen ihn in der Regel nicht. Für eine unbekannte `OrderNr` gibt es keinen expliziten Fehler – es wird dann nichts aktualisiert.\n- Die Maskierung betrifft den Adressdatensatz selbst. Wird dieselbe Adresse von weiteren Aufträgen oder vom Kunden verwendet, sind die Kartendaten für alle maskiert.\n- Adressen mit `ACardNr` = NULL werden nicht maskiert (die `NOT LIKE`-Prüfung ist für NULL nicht wahr). Bereits maskierte Nummern (mit `****`) werden übersprungen, wiederholte Aufrufe sind daher unkritisch.\n- Die Auftragssuche nutzt `NOLOCK`, die Updates `ROWLOCK`. Es wird keine explizite Transaktion verwendet, die beiden Schritte sind also nicht atomar.\n- Um nur einen Autorisierungscode ohne Maskierung zu speichern, `ScrambleData` = 0 übergeben.\n- Zum Löschen der temporären Tabelle wird `util.TempTableDrop` aufgerufen; dessen Definition liegt nicht vor.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetCreditCardInfo"
},
"response": []
}
]
},
{
"name": "Replacements",
"item": [
{
"name": "pixiCreateReplacement",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104512\n 556781;1,556782;2\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen Ersatzauftrag mit negativen Mengen für ausgewählte Auftragspositionen an, basierend auf Kunde und Adressen eines bestehenden Auftrags.\n\nLegt einen neuen Ersatzauftrag an und liefert den Schlüssel des neuen Auftragskopfs. Die Verarbeitung übernimmt die interne Prozedur `Pixi_CreateReplacementOrder`.\n\n1. Liest eine Auftragsposition des Auftrags `OrderNr` (`TOP 1` ohne Sortierung). Daraus werden Kunde, Rechnungsadresse, Lieferadresse, `LocationID` und `LastOrdLocationID` übernommen. Als Erstelldatum dient das aktuelle Datum.\n2. Kopiert die Rechnungsadresse dieser Position als neuen Datensatz in `Addresses`. `Username` wird als Ersteller und Bearbeiter gespeichert. Alle übrigen Felder werden unverändert übernommen.\n3. Liest Lieferland, Umsatzsteuerpflicht (`AddrNoChargeVAT`) und Shop des Kunden (`CustomerOf`) aus der Lieferadresse.\n4. Zerlegt `Orderlines`. Einträge sind durch Kommas getrennt. Jeder Eintrag hat die Form `OrderlineKey;Menge`. Die Menge ist optional; ohne Angabe wird die volle Menge der Originalposition verwendet.\n5. Liest aus dem Auftragskopf einer der angegebenen Positionen folgende Werte: Auftragstyp (Standard `B2C`), Versandkosten, Steuersätze, MwSt.-Einstellungen der Versandkosten, Währung und `Address_Remarks`. Zusätzlich wird die Rechnung dieser Position in `Invlines` ermittelt.\n6. Ermittelt einen Wechselkurs für Währung und aktuelles Datum und legt einen neuen Auftragskopf an (`Pixi_OrderHeader_Insert`). Der Auftrag erhält den Standard-CCP-Merchant aus der Einstellung `DefaultCCPMerchant` und einen Rabatt von 0. Die externe Auftragsnummer ist `P` + neue Auftragsnummer.\n7. Fügt je angegebener Originalposition eine Auftragsposition ein:\n - Menge negiert (`-Menge` bzw. `-Qty`), Status `MIN`;\n - Preise, Artikeldaten, Seriennummer, Charge und MHD übernommen;\n - `LocationID` aus dem Auftrag `OrderNr`;\n - Steuersatz neu berechnet aus Auftragstyp, Steuerpflicht, Lieferland und Steuerklasse des Artikels;\n - Positionsbeträge negiert und gerundet: brutto auf 2 Nachkommastellen bei `B2C` (sonst 4), netto auf 2 bei `B2B` (sonst 4);\n - Betragsdifferenzen negiert.\n8. Verknüpft den neuen Auftrag mit der Originalrechnung über einen Eintrag in `pixi.InvoiceAttribute` (`TypeId` 3, Wert = neue Auftragsnummer).\n9. Liefert den neuen `OrderHeaderKey` und schreibt die Transaktion fest.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Nummer des bestehenden Auftrags. Kunde, Rechnungsadresse, Lieferadresse und `LocationID` werden daraus übernommen. |\n| `Orderlines` | varchar(max) | Ja | Kommagetrennte Liste der Originalpositionen im Format `OrderlineKey;Menge`. Die Menge ist optional; ohne Angabe wird die volle Menge der Position verwendet. Die Menge wird negativ gespeichert. Effektiv auf 8000 Zeichen begrenzt. |\n| `Username` | varchar(50) | Nein | Benutzername, der als Ersteller und Bearbeiter der neuen Adresse und Auftragspositionen gespeichert wird. |\n\n- Die gesamte Verarbeitung läuft in einer Transaktion. Bei einem Fehler führt der `CATCH`-Block nur ein Rollback aus. Es kommen weder Fehlermeldung noch Ergebniszeile beim Aufrufer an. Eine leere Antwort bedeutet, dass kein Ersatzauftrag angelegt wurde.\n- Die Ergebniszeile wird vor dem Commit ausgegeben. Ist der interne Fehlerzähler ungleich 0, wird die Transaktion zurückgerollt, obwohl bereits ein Schlüssel geliefert wurde.\n- `@Orderlines` wird an einen `varchar(8000)`-Parameter der internen Prozedur übergeben. Längere Listen werden abgeschnitten.\n- Die angegebenen Auftragspositionen werden nur über `OrderlineKey` zugeordnet. Es wird nicht geprüft, ob sie zum Auftrag `OrderNr` gehören. Kunde und Adressen stammen aus `OrderNr`; Auftragstyp, Steuersätze, Währung und verknüpfte Rechnung aus einer der angegebenen Positionen. Es sollten nur Positionen desselben Auftrags übergeben werden.\n- Welche Position von `OrderNr` für Kunde und Adressen verwendet wird, ist nicht festgelegt (`TOP 1` ohne `ORDER BY`).\n- Hat eine angegebene Position keine Rechnung, wird der Verknüpfungseintrag in `pixi.InvoiceAttribute` ohne `InvoiceId` geschrieben, oder das Einfügen schlägt je nach Tabellen-Constraints fehl. Ein Fehler rollt den gesamten Aufruf zurück.\n- Positionen werden nur für Artikel angelegt, die in `items` existieren.\n- Lesezugriffe verwenden `NOLOCK`. Während des Einfügens der Positionen wird `CONTEXT_INFO` auf `0x10136` gesetzt, vermutlich zur Steuerung von Triggern.\n- `Pixi_OrderHeader_Insert`, `pixi.GetExchRateID`, `fpixi_GetSetting`, `fPixi_GetCommaSplit` und `fPixi_GetVATRate` liegen nicht vor. Ihr genaues Verhalten, einschließlich der Anlage des Auftragskopfs, ist hier nicht dokumentiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateReplacement"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104512\n 556781;1,556782;2\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen Ersatzauftrag mit negativen Mengen für ausgewählte Auftragspositionen an, basierend auf Kunde und Adressen eines bestehenden Auftrags.\n\nLegt einen neuen Ersatzauftrag an und liefert den Schlüssel des neuen Auftragskopfs. Die Verarbeitung übernimmt die interne Prozedur `Pixi_CreateReplacementOrder`.\n\n1. Liest eine Auftragsposition des Auftrags `OrderNr` (`TOP 1` ohne Sortierung). Daraus werden Kunde, Rechnungsadresse, Lieferadresse, `LocationID` und `LastOrdLocationID` übernommen. Als Erstelldatum dient das aktuelle Datum.\n2. Kopiert die Rechnungsadresse dieser Position als neuen Datensatz in `Addresses`. `Username` wird als Ersteller und Bearbeiter gespeichert. Alle übrigen Felder werden unverändert übernommen.\n3. Liest Lieferland, Umsatzsteuerpflicht (`AddrNoChargeVAT`) und Shop des Kunden (`CustomerOf`) aus der Lieferadresse.\n4. Zerlegt `Orderlines`. Einträge sind durch Kommas getrennt. Jeder Eintrag hat die Form `OrderlineKey;Menge`. Die Menge ist optional; ohne Angabe wird die volle Menge der Originalposition verwendet.\n5. Liest aus dem Auftragskopf einer der angegebenen Positionen folgende Werte: Auftragstyp (Standard `B2C`), Versandkosten, Steuersätze, MwSt.-Einstellungen der Versandkosten, Währung und `Address_Remarks`. Zusätzlich wird die Rechnung dieser Position in `Invlines` ermittelt.\n6. Ermittelt einen Wechselkurs für Währung und aktuelles Datum und legt einen neuen Auftragskopf an (`Pixi_OrderHeader_Insert`). Der Auftrag erhält den Standard-CCP-Merchant aus der Einstellung `DefaultCCPMerchant` und einen Rabatt von 0. Die externe Auftragsnummer ist `P` + neue Auftragsnummer.\n7. Fügt je angegebener Originalposition eine Auftragsposition ein:\n - Menge negiert (`-Menge` bzw. `-Qty`), Status `MIN`;\n - Preise, Artikeldaten, Seriennummer, Charge und MHD übernommen;\n - `LocationID` aus dem Auftrag `OrderNr`;\n - Steuersatz neu berechnet aus Auftragstyp, Steuerpflicht, Lieferland und Steuerklasse des Artikels;\n - Positionsbeträge negiert und gerundet: brutto auf 2 Nachkommastellen bei `B2C` (sonst 4), netto auf 2 bei `B2B` (sonst 4);\n - Betragsdifferenzen negiert.\n8. Verknüpft den neuen Auftrag mit der Originalrechnung über einen Eintrag in `pixi.InvoiceAttribute` (`TypeId` 3, Wert = neue Auftragsnummer).\n9. Liefert den neuen `OrderHeaderKey` und schreibt die Transaktion fest.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Nummer des bestehenden Auftrags. Kunde, Rechnungsadresse, Lieferadresse und `LocationID` werden daraus übernommen. |\n| `Orderlines` | varchar(max) | Ja | Kommagetrennte Liste der Originalpositionen im Format `OrderlineKey;Menge`. Die Menge ist optional; ohne Angabe wird die volle Menge der Position verwendet. Die Menge wird negativ gespeichert. Effektiv auf 8000 Zeichen begrenzt. |\n| `Username` | varchar(50) | Nein | Benutzername, der als Ersteller und Bearbeiter der neuen Adresse und Auftragspositionen gespeichert wird. |\n\n- Die gesamte Verarbeitung läuft in einer Transaktion. Bei einem Fehler führt der `CATCH`-Block nur ein Rollback aus. Es kommen weder Fehlermeldung noch Ergebniszeile beim Aufrufer an. Eine leere Antwort bedeutet, dass kein Ersatzauftrag angelegt wurde.\n- Die Ergebniszeile wird vor dem Commit ausgegeben. Ist der interne Fehlerzähler ungleich 0, wird die Transaktion zurückgerollt, obwohl bereits ein Schlüssel geliefert wurde.\n- `@Orderlines` wird an einen `varchar(8000)`-Parameter der internen Prozedur übergeben. Längere Listen werden abgeschnitten.\n- Die angegebenen Auftragspositionen werden nur über `OrderlineKey` zugeordnet. Es wird nicht geprüft, ob sie zum Auftrag `OrderNr` gehören. Kunde und Adressen stammen aus `OrderNr`; Auftragstyp, Steuersätze, Währung und verknüpfte Rechnung aus einer der angegebenen Positionen. Es sollten nur Positionen desselben Auftrags übergeben werden.\n- Welche Position von `OrderNr` für Kunde und Adressen verwendet wird, ist nicht festgelegt (`TOP 1` ohne `ORDER BY`).\n- Hat eine angegebene Position keine Rechnung, wird der Verknüpfungseintrag in `pixi.InvoiceAttribute` ohne `InvoiceId` geschrieben, oder das Einfügen schlägt je nach Tabellen-Constraints fehl. Ein Fehler rollt den gesamten Aufruf zurück.\n- Positionen werden nur für Artikel angelegt, die in `items` existieren.\n- Lesezugriffe verwenden `NOLOCK`. Während des Einfügens der Positionen wird `CONTEXT_INFO` auf `0x10136` gesetzt, vermutlich zur Steuerung von Triggern.\n- `Pixi_OrderHeader_Insert`, `pixi.GetExchRateID`, `fpixi_GetSetting`, `fPixi_GetCommaSplit` und `fPixi_GetVATRate` liegen nicht vor. Ihr genaues Verhalten, einschließlich der Anlage des Auftragskopfs, ist hier nicht dokumentiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateReplacement"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 98765\n \n"
}
]
},
{
"name": "pixiCreateReplacementOrder",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 1024,1025\n \n \n 1\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen Ersatzauftrag für eine oder mehrere Retourenfall-Positionen an, protokolliert die Anforderung in der Retourenhistorie und liefert die neue Auftragsnummer.\n\nLegt einen Ersatzauftrag für retournierte Artikel an, basierend auf den in `ReturnLines` übergebenen Retourenfall-Positionen.\n\n**Eingabeformat**: `ReturnLines` ist eine Liste von `RET_LINE_ID`-Werten, getrennt durch `,` oder `;` (z. B. `1024,1025`). Semikolons werden in Kommas umgewandelt, die Zeichenkette wird getrimmt und bei Bedarf um ein abschließendes Komma ergänzt.\n\n**Ablauf**\n\n1. **MwSt.-Prüfung**: Nur für die *erste* Retourenposition werden das Lieferland der zugehörigen Rechnung (`Invoices.ShipAdrRef` → `Addresses.Country`) und das Länderkennzeichen `ForceCountryVAT` ermittelt. Existiert in `VATs` kein heute gültiger MwSt.-Satz für dieses Land:\n - bei `ForceCountryVAT = 1` wird ein Fehler ausgelöst und nichts geändert;\n - andernfalls wird `Pixi_InsertDefaultVATRateForCountry` ausgeführt, um einen Standard-MwSt.-Satz aus dem Standardland abzuleiten.\n2. **Historie und Status**: Für jede Retourenposition wird ein Eintrag in `RET_CASES_HISTORY` angelegt (`ACTION_TYPE` = 8, Text aus dem Übersetzungsschlüssel `ReplacementRequestAPI` in der Sprache `Language_Id`, wobei `%ItemName%` durch den Artikelnamen ersetzt wird). Der Status der Position in `RET_CASE_LINES` wird auf `RPL` (Ersatz in Bearbeitung) gesetzt. Als Bearbeiter wird `Employee + ' (API)'` gespeichert, bzw. `API`, wenn `Employee` leer ist.\n3. **Ersatzauftrag**: `Pixi_CreateReplacementForReturnLines` wird mit allen Positionen aufgerufen. In einer eigenen Transaktion werden dort\n - die ursprünglichen Auftragspositionen (nur Positionen mit Status `AUS`, nur Retourenpositionen mit Status `RPL`) mit der retournierten Menge gesammelt,\n - die Retourenpositionen auf Status `SHI` (wartet auf Versand) gesetzt,\n - Adressen für Kunde und Shop angelegt und der Ersatzauftrag über `Pixi_CreateReplacementOrder` erzeugt,\n - die `RET_LINE_ID` in `Orderlines.BackorderRef` der neuen Auftragspositionen mit demselben Artikel geschrieben, damit der Retourenfall beim Versand abgeschlossen werden kann.\n4. Die neue Auftragsnummer wird als einzelne Zeile (`NewOrderNr`), im Ausgabeparameter `NewOrderNr` und als Rückgabewert der Prozedur geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ReturnLines` | varchar(max) | Ja | Liste von Retourenfall-Positions-IDs (`RET_LINE_ID`), getrennt durch `,` oder `;`, für die ein Ersatzauftrag angelegt wird. |\n| `Employee` | varchar(50) | Nein | Name des Mitarbeiters; wird als ` (API)` als Bearbeiter/Ersteller gespeichert. Bei NULL wird `API` verwendet. |\n| `NewOrderNr` | int | Nein | Ausgabe: Auftragsnummer des angelegten Ersatzauftrags. |\n| `Language_Id` | int | Ja | Sprach-ID für die Übersetzung des Historientextes (Übersetzungsschlüssel `ReplacementRequestAPI`). |\n\n- **Keine Gesamttransaktion**: Die Historieneinträge und die Statusänderung auf `RPL` werden *vor* und außerhalb der Transaktion von `Pixi_CreateReplacementForReturnLines` geschrieben. Schlägt die Anlage des Ersatzauftrags fehl, bleiben diese Änderungen bestehen.\n- Die MwSt.-Prüfung verwendet nur die erste Retourenposition. Kunde, Shop und Lager des neuen Auftrags stammen aus der zuletzt verarbeiteten Position; alle Positionen sollten daher zum selben Kunden bzw. zur selben Rechnung gehören.\n- Existiert die erste Retourenposition nicht, kann das Land nicht ermittelt werden, und der Aufruf scheitert mit einem Fehler aus `Pixi_InsertDefaultVATRateForCountry` (unbekannter Ländercode).\n- Retourenpositionen, deren ursprüngliche Auftragsposition nicht im Status `AUS` ist, werden übersprungen; trifft dies auf alle zu, löst die innere Prozedur ` Wrong Data ` aus. Fehler der inneren Prozedur werden über `log.InsertError` protokolliert und über `sp_Exception_ReRaise` erneut ausgelöst (nicht beigefügt; genaues Meldungsformat unbekannt).\n- **Fallstricke beim Parsen der Liste**: IDs werden per Textersetzung von `ID,` aus der Liste entfernt. IDs ohne Leerzeichen und ohne führende Nullen übergeben. Ein leerer Wert für `ReturnLines` oder IDs, die Endstücke anderer IDs der Liste sind (z. B. `12,112`), können zu Parse-Fehlern oder einer Endlosschleife führen.\n- Lesezugriffe erfolgen mit `NOLOCK`.\n- Der Kopfkommentar der Prozedur („Checks pixi* user credentials“) passt nicht zu ihrer Funktion.\n- Die MwSt.-Fehlermeldung enthält die wörtlichen Platzhalter `[Order/Invoice/...]` und `{shipping country}`; sie werden nicht ersetzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateReplacementOrder"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 1024,1025\n \n \n 1\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen Ersatzauftrag für eine oder mehrere Retourenfall-Positionen an, protokolliert die Anforderung in der Retourenhistorie und liefert die neue Auftragsnummer.\n\nLegt einen Ersatzauftrag für retournierte Artikel an, basierend auf den in `ReturnLines` übergebenen Retourenfall-Positionen.\n\n**Eingabeformat**: `ReturnLines` ist eine Liste von `RET_LINE_ID`-Werten, getrennt durch `,` oder `;` (z. B. `1024,1025`). Semikolons werden in Kommas umgewandelt, die Zeichenkette wird getrimmt und bei Bedarf um ein abschließendes Komma ergänzt.\n\n**Ablauf**\n\n1. **MwSt.-Prüfung**: Nur für die *erste* Retourenposition werden das Lieferland der zugehörigen Rechnung (`Invoices.ShipAdrRef` → `Addresses.Country`) und das Länderkennzeichen `ForceCountryVAT` ermittelt. Existiert in `VATs` kein heute gültiger MwSt.-Satz für dieses Land:\n - bei `ForceCountryVAT = 1` wird ein Fehler ausgelöst und nichts geändert;\n - andernfalls wird `Pixi_InsertDefaultVATRateForCountry` ausgeführt, um einen Standard-MwSt.-Satz aus dem Standardland abzuleiten.\n2. **Historie und Status**: Für jede Retourenposition wird ein Eintrag in `RET_CASES_HISTORY` angelegt (`ACTION_TYPE` = 8, Text aus dem Übersetzungsschlüssel `ReplacementRequestAPI` in der Sprache `Language_Id`, wobei `%ItemName%` durch den Artikelnamen ersetzt wird). Der Status der Position in `RET_CASE_LINES` wird auf `RPL` (Ersatz in Bearbeitung) gesetzt. Als Bearbeiter wird `Employee + ' (API)'` gespeichert, bzw. `API`, wenn `Employee` leer ist.\n3. **Ersatzauftrag**: `Pixi_CreateReplacementForReturnLines` wird mit allen Positionen aufgerufen. In einer eigenen Transaktion werden dort\n - die ursprünglichen Auftragspositionen (nur Positionen mit Status `AUS`, nur Retourenpositionen mit Status `RPL`) mit der retournierten Menge gesammelt,\n - die Retourenpositionen auf Status `SHI` (wartet auf Versand) gesetzt,\n - Adressen für Kunde und Shop angelegt und der Ersatzauftrag über `Pixi_CreateReplacementOrder` erzeugt,\n - die `RET_LINE_ID` in `Orderlines.BackorderRef` der neuen Auftragspositionen mit demselben Artikel geschrieben, damit der Retourenfall beim Versand abgeschlossen werden kann.\n4. Die neue Auftragsnummer wird als einzelne Zeile (`NewOrderNr`), im Ausgabeparameter `NewOrderNr` und als Rückgabewert der Prozedur geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ReturnLines` | varchar(max) | Ja | Liste von Retourenfall-Positions-IDs (`RET_LINE_ID`), getrennt durch `,` oder `;`, für die ein Ersatzauftrag angelegt wird. |\n| `Employee` | varchar(50) | Nein | Name des Mitarbeiters; wird als ` (API)` als Bearbeiter/Ersteller gespeichert. Bei NULL wird `API` verwendet. |\n| `NewOrderNr` | int | Nein | Ausgabe: Auftragsnummer des angelegten Ersatzauftrags. |\n| `Language_Id` | int | Ja | Sprach-ID für die Übersetzung des Historientextes (Übersetzungsschlüssel `ReplacementRequestAPI`). |\n\n- **Keine Gesamttransaktion**: Die Historieneinträge und die Statusänderung auf `RPL` werden *vor* und außerhalb der Transaktion von `Pixi_CreateReplacementForReturnLines` geschrieben. Schlägt die Anlage des Ersatzauftrags fehl, bleiben diese Änderungen bestehen.\n- Die MwSt.-Prüfung verwendet nur die erste Retourenposition. Kunde, Shop und Lager des neuen Auftrags stammen aus der zuletzt verarbeiteten Position; alle Positionen sollten daher zum selben Kunden bzw. zur selben Rechnung gehören.\n- Existiert die erste Retourenposition nicht, kann das Land nicht ermittelt werden, und der Aufruf scheitert mit einem Fehler aus `Pixi_InsertDefaultVATRateForCountry` (unbekannter Ländercode).\n- Retourenpositionen, deren ursprüngliche Auftragsposition nicht im Status `AUS` ist, werden übersprungen; trifft dies auf alle zu, löst die innere Prozedur ` Wrong Data ` aus. Fehler der inneren Prozedur werden über `log.InsertError` protokolliert und über `sp_Exception_ReRaise` erneut ausgelöst (nicht beigefügt; genaues Meldungsformat unbekannt).\n- **Fallstricke beim Parsen der Liste**: IDs werden per Textersetzung von `ID,` aus der Liste entfernt. IDs ohne Leerzeichen und ohne führende Nullen übergeben. Ein leerer Wert für `ReturnLines` oder IDs, die Endstücke anderer IDs der Liste sind (z. B. `12,112`), können zu Parse-Fehlern oder einer Endlosschleife führen.\n- Lesezugriffe erfolgen mit `NOLOCK`.\n- Der Kopfkommentar der Prozedur („Checks pixi* user credentials“) passt nicht zu ihrer Funktion.\n- Die MwSt.-Fehlermeldung enthält die wörtlichen Platzhalter `[Order/Invoice/...]` und `{shipping country}`; sie werden nicht ersetzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateReplacementOrder"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 584213\n \n"
}
]
}
]
},
{
"name": "Reports",
"item": [
{
"name": "pixiGetPOSSalesReport",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die POS-Verkaufspositionen (Kassenverkäufe) eines Zeitraums, optional für einen Standort, mit Artikel-, Lieferanten- und Preisdaten.\n\nErstellt einen Bericht über Kassenverkäufe (POS). Laut Kommentar im Code wurde der Aufruf für einen bestimmten Kunden (ERK) erstellt.\n\n- Jede Zeile ist eine POS-Position aus `POSitem2`. Sie wird mit ihrem POS-Kopf (`POSheader2`) und dem Artikel (`items`) verknüpft. Der Lieferant (`Suppliers`) wird optional über die `SupplNr` des Artikels verknüpft, daher kann `SupplName` leer sein.\n- `LocID` filtert auf den Standort des POS-Kopfs (`PHlocID`). Ein Leerstring oder `NULL` bedeutet alle Standorte.\n- `DateFrom` und `DateTo` filtern auf das Datum des POS-Kopfs `PHdate` mit einem einschließenden `BETWEEN`. Ein Wert, der `NULL` ist oder vor dem 01.01.1990 liegt, wird durch das aktuelle Datum mit Uhrzeit ersetzt.\n- Der Bericht stellt den Listen-VK des Artikels (`VK_List`) dem tatsächlich auf der POS-Position berechneten Preis (`VK_Real`) gegenüber. Zusätzlich werden der Lieferanten-Einkaufspreis und die Menge geliefert.\n- Die Sortierung erfolgt aufsteigend nach dem Schlüssel des POS-Kopfs, also in der Reihenfolge, in der die Kassenbelege angelegt wurden.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocID` | char(3) | Nein | Standort-ID der Kassenverkäufe. Ein Leerstring oder `NULL` liefert die Verkäufe aller Standorte. |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (einschließlich), verglichen mit dem Datum des POS-Kopfs. `NULL` oder ein Wert vor dem 01.01.1990 wird durch das aktuelle Datum mit Uhrzeit ersetzt. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (einschließlich), verglichen mit dem Datum des POS-Kopfs. `NULL` oder ein Wert vor dem 01.01.1990 wird durch das aktuelle Datum mit Uhrzeit ersetzt. |\n\n- Werden `DateFrom` und `DateTo` beide weggelassen, erhalten beide die aktuelle Uhrzeit, die nur Millisekunden auseinanderliegt. Das Ergebnis ist dann praktisch immer leer, daher sollten immer beide Datumswerte übergeben werden.\n- `BETWEEN` schließt beide Grenzen ein. Wird `DateTo` als Datum ohne Uhrzeit (Mitternacht) übergeben, fehlen spätere Verkäufe dieses Tages. Um den ganzen Tag abzudecken, den Folgetag oder die Uhrzeit 23:59:59 übergeben.\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten im Ergebnis erscheinen.\n- Es gibt kein Paging. Große Zeiträume können viele Zeilen liefern.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPOSSalesReport"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die POS-Verkaufspositionen (Kassenverkäufe) eines Zeitraums, optional für einen Standort, mit Artikel-, Lieferanten- und Preisdaten.\n\nErstellt einen Bericht über Kassenverkäufe (POS). Laut Kommentar im Code wurde der Aufruf für einen bestimmten Kunden (ERK) erstellt.\n\n- Jede Zeile ist eine POS-Position aus `POSitem2`. Sie wird mit ihrem POS-Kopf (`POSheader2`) und dem Artikel (`items`) verknüpft. Der Lieferant (`Suppliers`) wird optional über die `SupplNr` des Artikels verknüpft, daher kann `SupplName` leer sein.\n- `LocID` filtert auf den Standort des POS-Kopfs (`PHlocID`). Ein Leerstring oder `NULL` bedeutet alle Standorte.\n- `DateFrom` und `DateTo` filtern auf das Datum des POS-Kopfs `PHdate` mit einem einschließenden `BETWEEN`. Ein Wert, der `NULL` ist oder vor dem 01.01.1990 liegt, wird durch das aktuelle Datum mit Uhrzeit ersetzt.\n- Der Bericht stellt den Listen-VK des Artikels (`VK_List`) dem tatsächlich auf der POS-Position berechneten Preis (`VK_Real`) gegenüber. Zusätzlich werden der Lieferanten-Einkaufspreis und die Menge geliefert.\n- Die Sortierung erfolgt aufsteigend nach dem Schlüssel des POS-Kopfs, also in der Reihenfolge, in der die Kassenbelege angelegt wurden.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocID` | char(3) | Nein | Standort-ID der Kassenverkäufe. Ein Leerstring oder `NULL` liefert die Verkäufe aller Standorte. |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (einschließlich), verglichen mit dem Datum des POS-Kopfs. `NULL` oder ein Wert vor dem 01.01.1990 wird durch das aktuelle Datum mit Uhrzeit ersetzt. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (einschließlich), verglichen mit dem Datum des POS-Kopfs. `NULL` oder ein Wert vor dem 01.01.1990 wird durch das aktuelle Datum mit Uhrzeit ersetzt. |\n\n- Werden `DateFrom` und `DateTo` beide weggelassen, erhalten beide die aktuelle Uhrzeit, die nur Millisekunden auseinanderliegt. Das Ergebnis ist dann praktisch immer leer, daher sollten immer beide Datumswerte übergeben werden.\n- `BETWEEN` schließt beide Grenzen ein. Wird `DateTo` als Datum ohne Uhrzeit (Mitternacht) übergeben, fehlen spätere Verkäufe dieses Tages. Um den ganzen Tag abzudecken, den Folgetag oder die Uhrzeit 23:59:59 übergeben.\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten im Ergebnis erscheinen.\n- Es gibt kein Paging. Große Zeiträume können viele Zeilen liefern.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPOSSalesReport"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Trekking Shoe Alpine 42\n 129.90\n 119.90\n 62.50\n Outdoor Supply GmbH\n OSG\n 100245\n TS-ALP-42\n 4012345678901\n 2024-03-05T14:22:10\n 1\n \n"
}
]
},
{
"name": "pixiGetProductSalesReport",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100234\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die verkaufte Menge eines Artikels pro Rechnungsmonat und -jahr, optional eingeschränkt auf einen Shop.\n\nErstellt einen monatlichen Verkaufsbericht für einen einzelnen Artikel auf Basis von Rechnungspositionen.\n\n- Liest Rechnungspositionen aus der View `PV_InvlinesRep` und verknüpft sie über die Rechnungsnummer mit den Rechnungen in `PV_Rechnungen`.\n- Filtert auf die interne Artikelnummer `ItemNrInt`.\n- Ist `ShopID` angegeben, werden nur Rechnungspositionen dieses Shops berücksichtigt; fehlt der Parameter oder ist er `NULL`, werden alle Shops einbezogen.\n- Gruppiert nach Rechnungsmonat und Rechnungsjahr und summiert die verkaufte Menge (`QtySold`).\n- Die Zeilen sind chronologisch sortiert: nach Jahr aufsteigend, dann nach Monat aufsteigend.\n\nEs erscheinen nur Monate, in denen der Artikel berechnet wurde; Monate ohne Verkäufe werden nicht als Nullzeilen geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | Ja | Interne Artikelnummer des Artikels, dessen Verkäufe ausgewertet werden. |\n| `ShopID` | varchar(3) | Nein | Optionale Shop-ID. Ist sie gesetzt, werden nur Rechnungspositionen dieses Shops summiert; `NULL` berücksichtigt alle Shops. |\n\n- Laut Kopfkommentar wurde die Prozedur für einen bestimmten Kunden (JAL) erstellt.\n- Beide Views werden `WITH (NOLOCK)` gelesen, die Werte können daher nicht festgeschriebene Daten enthalten.\n- Die Definitionen von `PV_InvlinesRep` und `PV_Rechnungen` liegen nicht vor; die genaue Bedeutung von `QtySold` (z. B. ob Gutschriften die Menge mindern) sowie die Datentypen der Monats-/Jahresspalten hängen von diesen Views ab.\n- Es gibt keinen Datumsfilter; die gesamte Rechnungshistorie des Artikels wird aggregiert, was bei Artikeln mit vielen Rechnungspositionen langsam sein kann.\n- Eine unbekannte `ItemNrInt` liefert eine leere Ergebnismenge, keinen Fehler.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetProductSalesReport"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100234\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die verkaufte Menge eines Artikels pro Rechnungsmonat und -jahr, optional eingeschränkt auf einen Shop.\n\nErstellt einen monatlichen Verkaufsbericht für einen einzelnen Artikel auf Basis von Rechnungspositionen.\n\n- Liest Rechnungspositionen aus der View `PV_InvlinesRep` und verknüpft sie über die Rechnungsnummer mit den Rechnungen in `PV_Rechnungen`.\n- Filtert auf die interne Artikelnummer `ItemNrInt`.\n- Ist `ShopID` angegeben, werden nur Rechnungspositionen dieses Shops berücksichtigt; fehlt der Parameter oder ist er `NULL`, werden alle Shops einbezogen.\n- Gruppiert nach Rechnungsmonat und Rechnungsjahr und summiert die verkaufte Menge (`QtySold`).\n- Die Zeilen sind chronologisch sortiert: nach Jahr aufsteigend, dann nach Monat aufsteigend.\n\nEs erscheinen nur Monate, in denen der Artikel berechnet wurde; Monate ohne Verkäufe werden nicht als Nullzeilen geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | Ja | Interne Artikelnummer des Artikels, dessen Verkäufe ausgewertet werden. |\n| `ShopID` | varchar(3) | Nein | Optionale Shop-ID. Ist sie gesetzt, werden nur Rechnungspositionen dieses Shops summiert; `NULL` berücksichtigt alle Shops. |\n\n- Laut Kopfkommentar wurde die Prozedur für einen bestimmten Kunden (JAL) erstellt.\n- Beide Views werden `WITH (NOLOCK)` gelesen, die Werte können daher nicht festgeschriebene Daten enthalten.\n- Die Definitionen von `PV_InvlinesRep` und `PV_Rechnungen` liegen nicht vor; die genaue Bedeutung von `QtySold` (z. B. ob Gutschriften die Menge mindern) sowie die Datentypen der Monats-/Jahresspalten hängen von diesen Views ab.\n- Es gibt keinen Datumsfilter; die gesamte Rechnungshistorie des Artikels wird aggregiert, was bei Artikeln mit vielen Rechnungspositionen langsam sein kann.\n- Eine unbekannte `ItemNrInt` liefert eine leere Ergebnismenge, keinen Fehler.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetProductSalesReport"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 11\n 2023\n 42\n \n \n 12\n 2023\n 67\n \n"
}
]
},
{
"name": "pixiReport1SS",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert monatliche Paketstatistiken aus den Rechnungen für die Abrechnung: Pakete gesamt, Ein-Artikel-Pakete und als 1SS markierte Pakete mit Größenklassen.\n\nFührt die interne Report-Prozedur `Report_1SS` aus, die für Abrechnungszwecke verwendet wird. Der Aufruf hat keine Parameter.\n\nAufbau des Reports:\n\n1. Jede Rechnung (Tabelle `invoices`) mit `total >= 0` zählt als ein Paket. Gutschriften mit negativem Betrag sind ausgeschlossen.\n2. Die Rechnungen werden nach Kalendermonat gruppiert, und zwar über den Monatsabstand zwischen `invdate` und dem aktuellen Datum. `Month` und `Year` stammen aus dem jüngsten Rechnungsdatum der Gruppe.\n3. Pro Monat werden gezählt:\n - `Packages`: alle Rechnungen.\n - `Packages_1item`: Rechnungen, deren Rechnungspositionen (`invlines`) in Summe eine `itemqty` von genau 1 ergeben.\n - `Packages_1ss`: Rechnungen, bei denen die Kennzeichenspalte `1SS` gleich 1 ist.\n4. Abgeleitete Werte:\n - `Packages_1item_Percentage`: Anteil der Ein-Artikel-Pakete. Das Verhältnis wird auf zwei Nachkommastellen gerundet und danach mit 100 multipliziert. Das Ergebnis ist daher ein ganzzahliger Prozentwert.\n - `Class_1item` / `Class_1SS`: Größenklasse der Anzahl. Bis 1000 gilt `Small`, bis 2500 `Medium`, bis 5000 `Large`, bis 10000 `Extra Large`, darüber `XXL`.\n - `Extra10000_1Item` / `Extra10000_1SS`: Anzahl vollständiger 10.000er-Blöcke (Ganzzahldivision).\n\nEs gibt keinen Datumsfilter. Jeder Monat der gesamten Rechnungshistorie wird geliefert. Sortiert wird aufsteigend nach `Year` und anschließend nach `Month`.\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`. Die Zahlen können daher nicht festgeschriebene Daten enthalten.\n- Der Report liest die vollständigen Tabellen `invoices` und `invlines` ohne Datumsfilter. Bei großen Datenbanken kann das lange dauern.\n- Eine Rechnung gilt als Ein-Artikel-Paket, wenn die Summe der `itemqty` über alle Positionen 1 ergibt. Das gilt auch, wenn sich mehrere Positionen zu 1 summieren. Rechnungen ohne Positionen zählen nie als Ein-Artikel-Paket.\n- Rechnungen mit NULL in `invdate` bilden eine eigene Gruppe, in der `Month` und `Year` NULL sind.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport1SS"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert monatliche Paketstatistiken aus den Rechnungen für die Abrechnung: Pakete gesamt, Ein-Artikel-Pakete und als 1SS markierte Pakete mit Größenklassen.\n\nFührt die interne Report-Prozedur `Report_1SS` aus, die für Abrechnungszwecke verwendet wird. Der Aufruf hat keine Parameter.\n\nAufbau des Reports:\n\n1. Jede Rechnung (Tabelle `invoices`) mit `total >= 0` zählt als ein Paket. Gutschriften mit negativem Betrag sind ausgeschlossen.\n2. Die Rechnungen werden nach Kalendermonat gruppiert, und zwar über den Monatsabstand zwischen `invdate` und dem aktuellen Datum. `Month` und `Year` stammen aus dem jüngsten Rechnungsdatum der Gruppe.\n3. Pro Monat werden gezählt:\n - `Packages`: alle Rechnungen.\n - `Packages_1item`: Rechnungen, deren Rechnungspositionen (`invlines`) in Summe eine `itemqty` von genau 1 ergeben.\n - `Packages_1ss`: Rechnungen, bei denen die Kennzeichenspalte `1SS` gleich 1 ist.\n4. Abgeleitete Werte:\n - `Packages_1item_Percentage`: Anteil der Ein-Artikel-Pakete. Das Verhältnis wird auf zwei Nachkommastellen gerundet und danach mit 100 multipliziert. Das Ergebnis ist daher ein ganzzahliger Prozentwert.\n - `Class_1item` / `Class_1SS`: Größenklasse der Anzahl. Bis 1000 gilt `Small`, bis 2500 `Medium`, bis 5000 `Large`, bis 10000 `Extra Large`, darüber `XXL`.\n - `Extra10000_1Item` / `Extra10000_1SS`: Anzahl vollständiger 10.000er-Blöcke (Ganzzahldivision).\n\nEs gibt keinen Datumsfilter. Jeder Monat der gesamten Rechnungshistorie wird geliefert. Sortiert wird aufsteigend nach `Year` und anschließend nach `Month`.\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`. Die Zahlen können daher nicht festgeschriebene Daten enthalten.\n- Der Report liest die vollständigen Tabellen `invoices` und `invlines` ohne Datumsfilter. Bei großen Datenbanken kann das lange dauern.\n- Eine Rechnung gilt als Ein-Artikel-Paket, wenn die Summe der `itemqty` über alle Positionen 1 ergibt. Das gilt auch, wenn sich mehrere Positionen zu 1 summieren. Rechnungen ohne Positionen zählen nie als Ein-Artikel-Paket.\n- Rechnungen mit NULL in `invdate` bilden eine eigene Gruppe, in der `Month` und `Year` NULL sind.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport1SS"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4\n 2024\n 8250\n 3120\n 38.0000\n Large\n 2140\n 0\n Medium\n 0\n \n \n 5\n 2024\n 27400\n 12650\n 46.0000\n XXL\n 9800\n 1\n Extra Large\n 0\n \n"
}
]
},
{
"name": "pixiReportActiveLogins",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die aktuell in Pixi angemeldeten Benutzer, die Lizenzen belegen, optional einschließlich mobiler Sitzungen.\n\nListet die aktiven, lizenzrelevanten Anmeldungen aus dem letzten Anmelde-Snapshot in `UsersLoggedIn` auf.\n\n1. Zuerst wird der letzte Snapshot-Zeitstempel (`Tag`) ermittelt. Berücksichtigt werden die Sitzungstypen 1 und 2 (Desktop/Web), bei `IncludeMobileLicences` = 1 die Typen 1, 2, 4 und 5.\n2. Anschließend wird die interne Prozedur `Pixi_ShowConcurrentUsersForTag` im Distinct-Modus aufgerufen. Diese berechnet den Zeitstempel neu als letzten `Tag` der Sitzungstypen 1 und 2. Gibt es keinen Eintrag, wird das aktuelle Datum mit Uhrzeit verwendet.\n3. Desktop-/Web-Sitzungen (Typen 1, 2) mit diesem `Tag` werden nur berücksichtigt, wenn alle folgenden Bedingungen erfüllt sind:\n - ihr `AppName` ist ein Client in `ExeClientVersion` mit `LicenceNeeded` = 1;\n - der Lizenzmanager für den jeweiligen Client-Typ ist aktiv: Einstellung `pixiLicencesManager` für Desktop (`UserActiveSessionTypeRef` = 1) bzw. `pixiLicencesManagerWeb` für Web (`UserActiveSessionTypeRef` = 2).\n4. Bei `IncludeMobileLicences` = 1 werden zusätzlich mobile Sitzungen (Typen 4, 5) mit demselben `Tag` aufgenommen.\n5. Rechner aus `MasterUsers` und der Pixi-Benutzer `master` werden immer ausgeschlossen.\n6. Die Zeilen werden je Sitzung und Pixi-Benutzer gruppiert, sodass jede Sitzung einmal erscheint. `AppName` ist `Desktop/Web` oder `Mobile`. `ComputerName` ist der größte Rechnername der Sitzung.\n\n`NrOfLicences` enthält den Wert der Einstellung `pixiLicences`, wenn `pixiLicencesManager` den Wert `1` hat, sonst `0`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `IncludeMobileLicences` | bit | Nein | Legt fest, ob mobile Sitzungen (Sitzungstypen 4 und 5) in das Ergebnis aufgenommen werden. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Der in dieser Prozedur ermittelte Zeitstempel wird in `Pixi_ShowConcurrentUsersForTag` überschrieben. Dort wird immer der letzte `Tag` der Sitzungstypen 1 und 2 verwendet. Mobile Sitzungen erscheinen daher nur, wenn ihr `Tag` diesem Desktop-/Web-Zeitstempel entspricht.\n- Ist keine Lizenzmanager-Einstellung (`pixiLicencesManager`, `pixiLicencesManagerWeb`) aktiv, werden keine Desktop-/Web-Sitzungen geliefert.\n- `UsersCount` ist immer `0`, da die interne Prozedur mit ihrem Standardwert aufgerufen wird.\n- Das Ergebnis hat keine garantierte Sortierung.\n- Existiert die Einstellung `pixiLicencesManager` nicht (NULL), wird `NrOfLicences` nicht auf 0 gesetzt. Der Wert entspricht dann `pixiLicences`, gelesen über `fpixi_GetSetting` (Definition nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportActiveLogins"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die aktuell in Pixi angemeldeten Benutzer, die Lizenzen belegen, optional einschließlich mobiler Sitzungen.\n\nListet die aktiven, lizenzrelevanten Anmeldungen aus dem letzten Anmelde-Snapshot in `UsersLoggedIn` auf.\n\n1. Zuerst wird der letzte Snapshot-Zeitstempel (`Tag`) ermittelt. Berücksichtigt werden die Sitzungstypen 1 und 2 (Desktop/Web), bei `IncludeMobileLicences` = 1 die Typen 1, 2, 4 und 5.\n2. Anschließend wird die interne Prozedur `Pixi_ShowConcurrentUsersForTag` im Distinct-Modus aufgerufen. Diese berechnet den Zeitstempel neu als letzten `Tag` der Sitzungstypen 1 und 2. Gibt es keinen Eintrag, wird das aktuelle Datum mit Uhrzeit verwendet.\n3. Desktop-/Web-Sitzungen (Typen 1, 2) mit diesem `Tag` werden nur berücksichtigt, wenn alle folgenden Bedingungen erfüllt sind:\n - ihr `AppName` ist ein Client in `ExeClientVersion` mit `LicenceNeeded` = 1;\n - der Lizenzmanager für den jeweiligen Client-Typ ist aktiv: Einstellung `pixiLicencesManager` für Desktop (`UserActiveSessionTypeRef` = 1) bzw. `pixiLicencesManagerWeb` für Web (`UserActiveSessionTypeRef` = 2).\n4. Bei `IncludeMobileLicences` = 1 werden zusätzlich mobile Sitzungen (Typen 4, 5) mit demselben `Tag` aufgenommen.\n5. Rechner aus `MasterUsers` und der Pixi-Benutzer `master` werden immer ausgeschlossen.\n6. Die Zeilen werden je Sitzung und Pixi-Benutzer gruppiert, sodass jede Sitzung einmal erscheint. `AppName` ist `Desktop/Web` oder `Mobile`. `ComputerName` ist der größte Rechnername der Sitzung.\n\n`NrOfLicences` enthält den Wert der Einstellung `pixiLicences`, wenn `pixiLicencesManager` den Wert `1` hat, sonst `0`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `IncludeMobileLicences` | bit | Nein | Legt fest, ob mobile Sitzungen (Sitzungstypen 4 und 5) in das Ergebnis aufgenommen werden. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Der in dieser Prozedur ermittelte Zeitstempel wird in `Pixi_ShowConcurrentUsersForTag` überschrieben. Dort wird immer der letzte `Tag` der Sitzungstypen 1 und 2 verwendet. Mobile Sitzungen erscheinen daher nur, wenn ihr `Tag` diesem Desktop-/Web-Zeitstempel entspricht.\n- Ist keine Lizenzmanager-Einstellung (`pixiLicencesManager`, `pixiLicencesManagerWeb`) aktiv, werden keine Desktop-/Web-Sitzungen geliefert.\n- `UsersCount` ist immer `0`, da die interne Prozedur mit ihrem Standardwert aufgerufen wird.\n- Das Ergebnis hat keine garantierte Sortierung.\n- Existiert die Einstellung `pixiLicencesManager` nicht (NULL), wird `NrOfLicences` nicht auf 0 gesetzt. Der Wert entspricht dann `pixiLicences`, gelesen über `fpixi_GetSetting` (Definition nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportActiveLogins"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 2024-05-14T10:15:00\n 0\n mmueller\n Desktop/Web\n WS-LAGER01\n 10\n \n \n 2024-05-14T10:15:00\n 0\n kschmidt\n Mobile\n MDE-07\n 10\n \n"
}
]
},
{
"name": "pixiReportCustomerSales",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungspositionen mit Kunde, Land, Netto-Positionssumme, Währung und letztem Verkaufsdatum, gefiltert nach Artikel, Shop, Zahlungsart, Kunde und Rechnungsdatum.\n\nUmsatzbericht auf Ebene der Rechnungspositionen. Laut Kopfkommentar handelt es sich um eine *Kundenauswertung für den Kunden BAF*; die Prozedur wurde also für eine bestimmte Installation erstellt.\n\n**Parameterbehandlung**\n- `ItemNrSuppl`, `ShopID`, `PaymentType` und `CustomerNrExternal`: Ein Leerstring wird wie `NULL` behandelt und bedeutet *kein Filter*.\n- `DateFrom`: Bei `NULL` oder einem Datum vor dem 01.01.1990 wird das aktuelle Datum mit Uhrzeit minus einen Tag verwendet.\n- `DateTo`: Bei `NULL` oder einem Datum vor dem 01.01.1990 wird das aktuelle Datum mit Uhrzeit verwendet.\n\n**Filter** (alle mit UND verknüpft)\n- `ItemNrSuppl` muss der Lieferanten-Artikelnummer des Artikels (`Items.ItemNrSuppl`) entsprechen.\n- `ShopID` muss dem Shop der Rechnung (`Invoices.InvShopID`) entsprechen.\n- `PaymentType` muss der an der **Rechnungsadresse** hinterlegten Zahlungsart (`Addresses.APayment`) entsprechen, nicht der Zahlungsart der Rechnung.\n- `CustomerNrExternal` muss der externen Kundennummer der Rechnungsadresse entsprechen.\n- Für das Rechnungsdatum gilt `InvDate >= DateFrom` und `InvDate < DateTo`. Die Obergrenze ist exklusiv.\n\n**Ausgabe**\nEs wird eine Zeile je Rechnungsposition geliefert. Jede Zeile enthält:\n- Lieferanten-Artikelnummer und EAN des Artikels;\n- Firma (`CareOf`), Name und externe Kundennummer der Rechnungsadresse;\n- die Menge;\n- die Netto-Positionssumme;\n- die ISO3-Ländercodes von Rechnungs- und Lieferadresse;\n- den Währungscode der Rechnung;\n- `LastSaleDate`: das späteste Rechnungsdatum aller Rechnungen, die den Artikel enthalten.\n\nDie Netto-Positionssumme wird so berechnet: Der Einzelpreis der Position wird durch `1 + MwSt-Satz` geteilt, auf 2 Nachkommastellen gerundet und anschließend mit der Menge multipliziert. Als MwSt-Satz dient bei MwSt-Kennzeichen `H` der volle Satz der Rechnung, bei `L` der ermäßigte Satz und bei jedem anderen Kennzeichen 0.\n\nDas Ergebnis hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer (`Items.ItemNrSuppl`) als Filter. `NULL` oder Leerstring bedeutet alle Artikel. |\n| `ShopID` | varchar(3) | Nein | Shop-ID der Rechnung (`Invoices.InvShopID`). `NULL` oder Leerstring bedeutet alle Shops. |\n| `PaymentType` | char(1) | Nein | Zahlungsart-Kürzel, verglichen mit `Addresses.APayment` der Rechnungsadresse. `NULL` oder Leerstring bedeutet kein Filter. |\n| `CustomerNrExternal` | varchar(60) | Nein | Externe Kundennummer der Rechnungsadresse. `NULL` oder Leerstring bedeutet alle Kunden. |\n| `DateFrom` | datetime | Nein | Beginn des Rechnungsdatumsbereichs (inklusive). Bei `NULL` oder einem Datum vor dem 01.01.1990 wird das aktuelle Datum mit Uhrzeit minus einen Tag verwendet. |\n| `DateTo` | datetime | Nein | Ende des Rechnungsdatumsbereichs (exklusiv). Bei `NULL` oder einem Datum vor dem 01.01.1990 wird das aktuelle Datum mit Uhrzeit verwendet. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können im Ergebnis erscheinen.\n- Ohne Datumsparameter umfasst der Bericht genau die letzten 24 Stunden bis zum Zeitpunkt des Aufrufs. Das ist ein gleitendes Zeitfenster, nicht der vorherige Kalendertag. Für ganze Tage sollte `DateTo` als Mitternacht des Tages nach dem letzten gewünschten Tag übergeben werden.\n- Alle Joins sind Inner Joins. Positionen fehlen, wenn die Rechnung keine Rechnungs- oder Lieferadresse hat, wenn ein Land nicht in `Countries` aufgelöst werden kann oder wenn die Rechnungswährung nicht in `pixi.Currency` vorhanden ist.\n- `LastSaleDate` berücksichtigt keinen Filter, auch nicht den Datumsbereich. Es zeigt immer das späteste Rechnungsdatum des Artikels über alle Rechnungen. Da es je Zeile als korrelierte Unterabfrage ermittelt wird, können große Datumsbereiche langsam sein.\n- Die Nettoberechnung verwendet `VATHighPerc` / `VATLowPerc` direkt als `1 + Satz`. Das Ergebnis ist nur korrekt, wenn diese Sätze als Dezimalbruch (z. B. 0,19) gespeichert sind.\n- Der Netto-Einzelpreis wird vor der Multiplikation mit der Menge gerundet; geringe Rundungsdifferenzen zu den Rechnungssummen sind daher möglich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportCustomerSales"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Rechnungspositionen mit Kunde, Land, Netto-Positionssumme, Währung und letztem Verkaufsdatum, gefiltert nach Artikel, Shop, Zahlungsart, Kunde und Rechnungsdatum.\n\nUmsatzbericht auf Ebene der Rechnungspositionen. Laut Kopfkommentar handelt es sich um eine *Kundenauswertung für den Kunden BAF*; die Prozedur wurde also für eine bestimmte Installation erstellt.\n\n**Parameterbehandlung**\n- `ItemNrSuppl`, `ShopID`, `PaymentType` und `CustomerNrExternal`: Ein Leerstring wird wie `NULL` behandelt und bedeutet *kein Filter*.\n- `DateFrom`: Bei `NULL` oder einem Datum vor dem 01.01.1990 wird das aktuelle Datum mit Uhrzeit minus einen Tag verwendet.\n- `DateTo`: Bei `NULL` oder einem Datum vor dem 01.01.1990 wird das aktuelle Datum mit Uhrzeit verwendet.\n\n**Filter** (alle mit UND verknüpft)\n- `ItemNrSuppl` muss der Lieferanten-Artikelnummer des Artikels (`Items.ItemNrSuppl`) entsprechen.\n- `ShopID` muss dem Shop der Rechnung (`Invoices.InvShopID`) entsprechen.\n- `PaymentType` muss der an der **Rechnungsadresse** hinterlegten Zahlungsart (`Addresses.APayment`) entsprechen, nicht der Zahlungsart der Rechnung.\n- `CustomerNrExternal` muss der externen Kundennummer der Rechnungsadresse entsprechen.\n- Für das Rechnungsdatum gilt `InvDate >= DateFrom` und `InvDate < DateTo`. Die Obergrenze ist exklusiv.\n\n**Ausgabe**\nEs wird eine Zeile je Rechnungsposition geliefert. Jede Zeile enthält:\n- Lieferanten-Artikelnummer und EAN des Artikels;\n- Firma (`CareOf`), Name und externe Kundennummer der Rechnungsadresse;\n- die Menge;\n- die Netto-Positionssumme;\n- die ISO3-Ländercodes von Rechnungs- und Lieferadresse;\n- den Währungscode der Rechnung;\n- `LastSaleDate`: das späteste Rechnungsdatum aller Rechnungen, die den Artikel enthalten.\n\nDie Netto-Positionssumme wird so berechnet: Der Einzelpreis der Position wird durch `1 + MwSt-Satz` geteilt, auf 2 Nachkommastellen gerundet und anschließend mit der Menge multipliziert. Als MwSt-Satz dient bei MwSt-Kennzeichen `H` der volle Satz der Rechnung, bei `L` der ermäßigte Satz und bei jedem anderen Kennzeichen 0.\n\nDas Ergebnis hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer (`Items.ItemNrSuppl`) als Filter. `NULL` oder Leerstring bedeutet alle Artikel. |\n| `ShopID` | varchar(3) | Nein | Shop-ID der Rechnung (`Invoices.InvShopID`). `NULL` oder Leerstring bedeutet alle Shops. |\n| `PaymentType` | char(1) | Nein | Zahlungsart-Kürzel, verglichen mit `Addresses.APayment` der Rechnungsadresse. `NULL` oder Leerstring bedeutet kein Filter. |\n| `CustomerNrExternal` | varchar(60) | Nein | Externe Kundennummer der Rechnungsadresse. `NULL` oder Leerstring bedeutet alle Kunden. |\n| `DateFrom` | datetime | Nein | Beginn des Rechnungsdatumsbereichs (inklusive). Bei `NULL` oder einem Datum vor dem 01.01.1990 wird das aktuelle Datum mit Uhrzeit minus einen Tag verwendet. |\n| `DateTo` | datetime | Nein | Ende des Rechnungsdatumsbereichs (exklusiv). Bei `NULL` oder einem Datum vor dem 01.01.1990 wird das aktuelle Datum mit Uhrzeit verwendet. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können im Ergebnis erscheinen.\n- Ohne Datumsparameter umfasst der Bericht genau die letzten 24 Stunden bis zum Zeitpunkt des Aufrufs. Das ist ein gleitendes Zeitfenster, nicht der vorherige Kalendertag. Für ganze Tage sollte `DateTo` als Mitternacht des Tages nach dem letzten gewünschten Tag übergeben werden.\n- Alle Joins sind Inner Joins. Positionen fehlen, wenn die Rechnung keine Rechnungs- oder Lieferadresse hat, wenn ein Land nicht in `Countries` aufgelöst werden kann oder wenn die Rechnungswährung nicht in `pixi.Currency` vorhanden ist.\n- `LastSaleDate` berücksichtigt keinen Filter, auch nicht den Datumsbereich. Es zeigt immer das späteste Rechnungsdatum des Artikels über alle Rechnungen. Da es je Zeile als korrelierte Unterabfrage ermittelt wird, können große Datumsbereiche langsam sein.\n- Die Nettoberechnung verwendet `VATHighPerc` / `VATLowPerc` direkt als `1 + Satz`. Das Ergebnis ist nur korrekt, wenn diese Sätze als Dezimalbruch (z. B. 0,19) gespeichert sind.\n- Der Netto-Einzelpreis wird vor der Multiplikation mit der Menge gerundet; geringe Rundungsdifferenzen zu den Rechnungssummen sind daher möglich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportCustomerSales"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n BAF-10045\n 4006381333931\n Muster GmbH\n Max Mustermann\n K-204711\n 2\n 33.60\n DEU\n AUT\n 2024-03-28T14:12:05\n EUR\n \n"
}
]
},
{
"name": "pixiReportGetShippableOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die aus dem aktuellen Bestand versandfähigen Auftragspositionen als Details oder als Summen (Aufträge, Wert, Versandkosten, Picks), optional je Lager.\n\nWertet offene Aufträge aus und prüft je Position, ob genügend Bestand für den Versand vorhanden ist. Anschließend werden entweder die versandfähigen Positionen oder Summenwerte geliefert.\n\n**Kandidaten für Aufträge und Positionen**\n- Berücksichtigt werden nur Auftragspositionen mit Status `ANG` oder `EIN`, gesetztem `ItemRef` und `Qty` > 0.\n- Der Kunde des Auftrags muss zu `ShopId` gehören (`Customers.CustomerOf`). Ein leerer `ShopId` bedeutet alle Shops.\n- Ausgeschlossen werden Aufträge, deren Rechnungsadresse (`AddrRef`) oder Lieferadresse (`ShipAdrRef`) gesperrt ist (`ASlocked = 'Y'`).\n- Ebenfalls ausgeschlossen werden Aufträge, die selbst gesperrt sind (`OhSLocked = 'Y'`).\n- Ohne `IncludeOrdersWithAnyShipDate = 1` werden nur Aufträge ohne `Shipdate` oder mit `Shipdate` vor morgen (heute oder früher) berücksichtigt.\n\n**Bestandsprüfung**\nDie interne Prozedur `pixi_CalculateStockForOrderLines` setzt für jede Kandidatenposition ein Kennzeichen für die Versandfähigkeit. Sie läuft mit übersprungenen Nullbestands-Artikeln, d. h. Positionen von Artikeln ohne Bestand sind nicht versandfähig.\n- In die Berechnung fließen der Bestand in Lagern mit `SpecialStock = 0`, bestehende Reservierungen und frühere nicht reservierte Auftragspositionen ein.\n- Positionen mit Status `EIN` gelten immer als versandfähig.\n- Ein Auftrag gilt als *teilweise oder nicht versandfähig*, wenn mindestens eine seiner Kandidatenpositionen nicht versandfähig ist.\n\n**Filter nach Liefermodus**\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 0`: nur Positionen von Aufträgen, deren Kandidatenpositionen alle versandfähig sind (vollständige Aufträge).\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 1`: alle versandfähigen Positionen aus vollständigen und teilweisen Aufträgen.\n- `OnlyPartDelivery = 1`: nur die versandfähigen Positionen von Teillieferungs-Aufträgen. `IncludePartDelivery` wird in diesem Fall ignoriert.\n\n**Währung**\nIst die Einstellung `MultiCurrencyEnabled` gleich 1, werden `Price` und `ShipCost` in die Datenbankwährung umgerechnet. Verwendet wird der Wechselkurs der Datenbank-Kursquelle mit gleicher Währung und gleichem Datum wie der Kurs des Auftrags. Gibt es keinen solchen Kurs, erfolgt keine Umrechnung. `dbCurrency` enthält dann den Code der Datenbankwährung, sonst NULL.\n\n**Ausgabe**\nEs wird genau eine Ergebnismenge geliefert, abhängig von `ViewDetails` und `PerLocation`:\n- `ViewDetails = 1`: eine Zeile je versandfähiger Position, sortiert nach `OrderNr` und `OrderlineRef`. Bei `PerLocation = 1` kommt die Spalte `LocationId` hinzu.\n- `ViewDetails = 0`, `PerLocation = 0`: eine Summenzeile.\n- `ViewDetails = 0`, `PerLocation = 1`: eine Summenzeile je Lager.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ViewDetails` | bit | Nein | 1 liefert eine Zeile je versandfähiger Position; 0 (oder NULL) liefert Summen. |\n| `IncludePartDelivery` | bit | Nein | 1 berücksichtigt zusätzlich zu vollständigen Aufträgen auch die versandfähigen Positionen von Teillieferungs-Aufträgen. Wird bei `OnlyPartDelivery = 1` ignoriert. |\n| `OnlyPartDelivery` | bit | Nein | 1 liefert nur die versandfähigen Positionen von Aufträgen, die nicht vollständig versandt werden können. |\n| `ShopId` | varchar(3) | Nein | Beschränkt das Ergebnis auf Aufträge von Kunden dieses Shops (`Customers.CustomerOf`). Leer bedeutet alle Shops. |\n| `IncludeOrdersWithAnyShipDate` | bit | Nein | 1 berücksichtigt auch Aufträge mit einem Versanddatum in der Zukunft. |\n| `PerLocation` | bit | Nein | 1 ergänzt das Lager in den Details bzw. gruppiert die Summen nach Lager (im Code als \"old way\" markiert). |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; die Werte können daher nicht festgeschriebene Daten enthalten.\n- Die Einstellung `UseFIFObyLocation` steuert die Bestandsbasis in `pixi_CalculateStockForOrderLines`:\n - `0`: Gesamtbestand aller Lager mit `SpecialStock = 0`.\n - `1`: Bestand im Lager der jeweiligen Position.\n- Nur Positionen im Status `ANG`/`EIN` entscheiden, ob ein Auftrag vollständig ist. Positionen desselben Auftrags in anderen Status werden sowohl bei der Prüfung als auch in der Ausgabe ignoriert.\n- `ShipCost` sind die Versandkosten aus dem Auftragskopf. In den Detail-Ergebnismengen werden sie in jeder Position des Auftrags wiederholt. In den Summen zählen sie einmal je Auftrag, bei `PerLocation = 1` einmal je Auftrag und Lager. Ein Auftrag mit Positionen in mehreren Lagern geht daher mit seinen Versandkosten in jedes dieser Lager ein.\n- `OrderTotal` wird als `SUM(Price * Qty)` berechnet.\n- `NULL`-Werte der Bit-Parameter werden als 0 behandelt. `PerLocation` ist im Code als \"old way\" gekennzeichnet.\n- Die Hilfsprozedur ruft `log.EventDurationInsert` auf (Definition nicht beigefügt), das vermutlich einen Laufzeit-Logeintrag schreibt.\n- Bei großen Datenbeständen kann der Aufruf aufwendig sein, da der Bestand für alle offenen Positionen berechnet wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportGetShippableOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die aus dem aktuellen Bestand versandfähigen Auftragspositionen als Details oder als Summen (Aufträge, Wert, Versandkosten, Picks), optional je Lager.\n\nWertet offene Aufträge aus und prüft je Position, ob genügend Bestand für den Versand vorhanden ist. Anschließend werden entweder die versandfähigen Positionen oder Summenwerte geliefert.\n\n**Kandidaten für Aufträge und Positionen**\n- Berücksichtigt werden nur Auftragspositionen mit Status `ANG` oder `EIN`, gesetztem `ItemRef` und `Qty` > 0.\n- Der Kunde des Auftrags muss zu `ShopId` gehören (`Customers.CustomerOf`). Ein leerer `ShopId` bedeutet alle Shops.\n- Ausgeschlossen werden Aufträge, deren Rechnungsadresse (`AddrRef`) oder Lieferadresse (`ShipAdrRef`) gesperrt ist (`ASlocked = 'Y'`).\n- Ebenfalls ausgeschlossen werden Aufträge, die selbst gesperrt sind (`OhSLocked = 'Y'`).\n- Ohne `IncludeOrdersWithAnyShipDate = 1` werden nur Aufträge ohne `Shipdate` oder mit `Shipdate` vor morgen (heute oder früher) berücksichtigt.\n\n**Bestandsprüfung**\nDie interne Prozedur `pixi_CalculateStockForOrderLines` setzt für jede Kandidatenposition ein Kennzeichen für die Versandfähigkeit. Sie läuft mit übersprungenen Nullbestands-Artikeln, d. h. Positionen von Artikeln ohne Bestand sind nicht versandfähig.\n- In die Berechnung fließen der Bestand in Lagern mit `SpecialStock = 0`, bestehende Reservierungen und frühere nicht reservierte Auftragspositionen ein.\n- Positionen mit Status `EIN` gelten immer als versandfähig.\n- Ein Auftrag gilt als *teilweise oder nicht versandfähig*, wenn mindestens eine seiner Kandidatenpositionen nicht versandfähig ist.\n\n**Filter nach Liefermodus**\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 0`: nur Positionen von Aufträgen, deren Kandidatenpositionen alle versandfähig sind (vollständige Aufträge).\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 1`: alle versandfähigen Positionen aus vollständigen und teilweisen Aufträgen.\n- `OnlyPartDelivery = 1`: nur die versandfähigen Positionen von Teillieferungs-Aufträgen. `IncludePartDelivery` wird in diesem Fall ignoriert.\n\n**Währung**\nIst die Einstellung `MultiCurrencyEnabled` gleich 1, werden `Price` und `ShipCost` in die Datenbankwährung umgerechnet. Verwendet wird der Wechselkurs der Datenbank-Kursquelle mit gleicher Währung und gleichem Datum wie der Kurs des Auftrags. Gibt es keinen solchen Kurs, erfolgt keine Umrechnung. `dbCurrency` enthält dann den Code der Datenbankwährung, sonst NULL.\n\n**Ausgabe**\nEs wird genau eine Ergebnismenge geliefert, abhängig von `ViewDetails` und `PerLocation`:\n- `ViewDetails = 1`: eine Zeile je versandfähiger Position, sortiert nach `OrderNr` und `OrderlineRef`. Bei `PerLocation = 1` kommt die Spalte `LocationId` hinzu.\n- `ViewDetails = 0`, `PerLocation = 0`: eine Summenzeile.\n- `ViewDetails = 0`, `PerLocation = 1`: eine Summenzeile je Lager.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ViewDetails` | bit | Nein | 1 liefert eine Zeile je versandfähiger Position; 0 (oder NULL) liefert Summen. |\n| `IncludePartDelivery` | bit | Nein | 1 berücksichtigt zusätzlich zu vollständigen Aufträgen auch die versandfähigen Positionen von Teillieferungs-Aufträgen. Wird bei `OnlyPartDelivery = 1` ignoriert. |\n| `OnlyPartDelivery` | bit | Nein | 1 liefert nur die versandfähigen Positionen von Aufträgen, die nicht vollständig versandt werden können. |\n| `ShopId` | varchar(3) | Nein | Beschränkt das Ergebnis auf Aufträge von Kunden dieses Shops (`Customers.CustomerOf`). Leer bedeutet alle Shops. |\n| `IncludeOrdersWithAnyShipDate` | bit | Nein | 1 berücksichtigt auch Aufträge mit einem Versanddatum in der Zukunft. |\n| `PerLocation` | bit | Nein | 1 ergänzt das Lager in den Details bzw. gruppiert die Summen nach Lager (im Code als \"old way\" markiert). |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; die Werte können daher nicht festgeschriebene Daten enthalten.\n- Die Einstellung `UseFIFObyLocation` steuert die Bestandsbasis in `pixi_CalculateStockForOrderLines`:\n - `0`: Gesamtbestand aller Lager mit `SpecialStock = 0`.\n - `1`: Bestand im Lager der jeweiligen Position.\n- Nur Positionen im Status `ANG`/`EIN` entscheiden, ob ein Auftrag vollständig ist. Positionen desselben Auftrags in anderen Status werden sowohl bei der Prüfung als auch in der Ausgabe ignoriert.\n- `ShipCost` sind die Versandkosten aus dem Auftragskopf. In den Detail-Ergebnismengen werden sie in jeder Position des Auftrags wiederholt. In den Summen zählen sie einmal je Auftrag, bei `PerLocation = 1` einmal je Auftrag und Lager. Ein Auftrag mit Positionen in mehreren Lagern geht daher mit seinen Versandkosten in jedes dieser Lager ein.\n- `OrderTotal` wird als `SUM(Price * Qty)` berechnet.\n- `NULL`-Werte der Bit-Parameter werden als 0 behandelt. `PerLocation` ist im Code als \"old way\" gekennzeichnet.\n- Die Hilfsprozedur ruft `log.EventDurationInsert` auf (Definition nicht beigefügt), das vermutlich einen Laufzeit-Logeintrag schreibt.\n- Bei großen Datenbeständen kann der Aufruf aufwendig sein, da der Bestand für alle offenen Positionen berechnet wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportGetShippableOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 42\n 3875.4000\n 209.5800\n 118\n EUR\n \n"
}
]
},
{
"name": "pixiReportGetStockItems",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine Lagerbewertung pro Artikel mit Lagerbestand, durchschnittlichem EK, Lagerwert, Lageralter, letzter Bestellung und Absatzmengen für drei Zeiträume.\n\nErstellt eine Lagerbewertung für alle Artikel, die mindestens einen Eintrag in `InvBinItem` haben. Laut Kopfkommentar wurde die Auswertung für die Lagerbewertung und Preisneuberechnung eines bestimmten Kunden (GCH) erstellt.\n\n**Filter**\n- Ist `SupplNr` gesetzt, werden nur Artikel geliefert, deren `Items.SupplNr` diesem Wert entspricht. Bei `NULL` (Standard) werden alle Artikel mit Lagerplatzeinträgen geliefert.\n- Artikel ohne Zeile in `InvBinItem` erscheinen nicht. Artikel, deren Lagerplatzbestände in Summe 0 ergeben, erscheinen trotzdem.\n\n**Berechnete Werte pro Artikel**\n- `EK`: durchschnittlicher Lieferantenpreis aus `fPixi_GetAverageSupplPrice`. Gemittelt wird `AddItems.SupplPrice` aller über `IntLinkNr1` verknüpften Lieferantendatensätze. Preise mit `NULL` oder 0 und der Lieferant `MGS` werden ignoriert. Gibt es keinen solchen Preis, ist der Wert `0`.\n- `AnzahlArtikelAufLager`: Summe von `BinItemQty` über alle Lagerplätze des Artikels.\n- `EKGesamt`: Lagerbestand multipliziert mit `EK`.\n- `AufLagerSeit` / `AufLagerSeitTage`: frühestes `UpdateDate` in `InvBinItemLog` mit positiver Menge und die Anzahl der Tage seitdem.\n- `LetzteBestellung` / `LetzteBestellungTage`: spätestes `OrderDate` einer Auftragsposition des Artikels und die Anzahl der Tage seitdem.\n- `soldRange1`, `soldRange2`, `soldRange3`: Summe von `Orderlines.Qty` aller Auftragspositionen, deren `OrderDate` innerhalb der letzten `SoldRange1`, `SoldRange2` bzw. `SoldRange3` Tage liegt, gerechnet ab der aktuellen Serverzeit.\n\nDas Ergebnis hat keine festgelegte Sortierung und kein Paging.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer (`Items.SupplNr`), auf die die Auswertung eingeschränkt wird. `NULL` liefert alle Artikel mit Lagerplatzeinträgen. |\n| `SoldRange1` | int | Nein | Anzahl der Tage ab heute rückwärts für die Absatzsumme in Spalte `soldRange1`. |\n| `SoldRange2` | int | Nein | Anzahl der Tage ab heute rückwärts für die Absatzsumme in Spalte `soldRange2`. |\n| `SoldRange3` | int | Nein | Anzahl der Tage ab heute rückwärts für die Absatzsumme in Spalte `soldRange3`. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, die Werte können daher nicht festgeschriebene Daten enthalten.\n- Absatzmengen und letzte Bestellung berücksichtigen **alle** Auftragspositionen des Artikels, unabhängig vom Status von Auftrag oder Position (z. B. werden stornierte Positionen nicht ausgeschlossen).\n- `soldRange*`, `LetzteBestellung`, `AufLagerSeit` und die Tagesspalten sind `NULL`, wenn keine passenden Auftragspositionen bzw. Logeinträge existieren.\n- Der durchschnittliche EK schließt den Lieferanten `MGS` immer aus; dies ist in `fPixi_GetAverageSupplPrice` fest codiert. Die Ausweichabfrage der Funktion ist identisch mit der ersten Abfrage, daher ergibt sich ohne gefundenen Preis faktisch `0`.\n- Pro Artikel werden mehrere korrelierte Unterabfragen und ein Aufruf einer Skalarfunktion ausgeführt. Ohne Filter auf `SupplNr` kann der Aufruf bei großen Artikelbeständen lange dauern.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportGetStockItems"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine Lagerbewertung pro Artikel mit Lagerbestand, durchschnittlichem EK, Lagerwert, Lageralter, letzter Bestellung und Absatzmengen für drei Zeiträume.\n\nErstellt eine Lagerbewertung für alle Artikel, die mindestens einen Eintrag in `InvBinItem` haben. Laut Kopfkommentar wurde die Auswertung für die Lagerbewertung und Preisneuberechnung eines bestimmten Kunden (GCH) erstellt.\n\n**Filter**\n- Ist `SupplNr` gesetzt, werden nur Artikel geliefert, deren `Items.SupplNr` diesem Wert entspricht. Bei `NULL` (Standard) werden alle Artikel mit Lagerplatzeinträgen geliefert.\n- Artikel ohne Zeile in `InvBinItem` erscheinen nicht. Artikel, deren Lagerplatzbestände in Summe 0 ergeben, erscheinen trotzdem.\n\n**Berechnete Werte pro Artikel**\n- `EK`: durchschnittlicher Lieferantenpreis aus `fPixi_GetAverageSupplPrice`. Gemittelt wird `AddItems.SupplPrice` aller über `IntLinkNr1` verknüpften Lieferantendatensätze. Preise mit `NULL` oder 0 und der Lieferant `MGS` werden ignoriert. Gibt es keinen solchen Preis, ist der Wert `0`.\n- `AnzahlArtikelAufLager`: Summe von `BinItemQty` über alle Lagerplätze des Artikels.\n- `EKGesamt`: Lagerbestand multipliziert mit `EK`.\n- `AufLagerSeit` / `AufLagerSeitTage`: frühestes `UpdateDate` in `InvBinItemLog` mit positiver Menge und die Anzahl der Tage seitdem.\n- `LetzteBestellung` / `LetzteBestellungTage`: spätestes `OrderDate` einer Auftragsposition des Artikels und die Anzahl der Tage seitdem.\n- `soldRange1`, `soldRange2`, `soldRange3`: Summe von `Orderlines.Qty` aller Auftragspositionen, deren `OrderDate` innerhalb der letzten `SoldRange1`, `SoldRange2` bzw. `SoldRange3` Tage liegt, gerechnet ab der aktuellen Serverzeit.\n\nDas Ergebnis hat keine festgelegte Sortierung und kein Paging.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer (`Items.SupplNr`), auf die die Auswertung eingeschränkt wird. `NULL` liefert alle Artikel mit Lagerplatzeinträgen. |\n| `SoldRange1` | int | Nein | Anzahl der Tage ab heute rückwärts für die Absatzsumme in Spalte `soldRange1`. |\n| `SoldRange2` | int | Nein | Anzahl der Tage ab heute rückwärts für die Absatzsumme in Spalte `soldRange2`. |\n| `SoldRange3` | int | Nein | Anzahl der Tage ab heute rückwärts für die Absatzsumme in Spalte `soldRange3`. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, die Werte können daher nicht festgeschriebene Daten enthalten.\n- Absatzmengen und letzte Bestellung berücksichtigen **alle** Auftragspositionen des Artikels, unabhängig vom Status von Auftrag oder Position (z. B. werden stornierte Positionen nicht ausgeschlossen).\n- `soldRange*`, `LetzteBestellung`, `AufLagerSeit` und die Tagesspalten sind `NULL`, wenn keine passenden Auftragspositionen bzw. Logeinträge existieren.\n- Der durchschnittliche EK schließt den Lieferanten `MGS` immer aus; dies ist in `fPixi_GetAverageSupplPrice` fest codiert. Die Ausweichabfrage der Funktion ist identisch mit der ersten Abfrage, daher ergibt sich ohne gefundenen Preis faktisch `0`.\n- Pro Artikel werden mehrere korrelierte Unterabfragen und ein Aufruf einer Skalarfunktion ausgeführt. Ohne Filter auf `SupplNr` kann der Aufruf bei großen Artikelbeständen lange dauern.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportGetStockItems"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n MG-4711\n 4006381333931\n MGS\n Steckdosenleiste 6-fach\n 24.9900\n 11.2500\n 38\n 427.5000\n 2023-02-14T09:31:00\n 412\n 2024-03-28T16:05:12\n 4\n 12\n 31\n 40\n \n"
}
]
},
{
"name": "pixiReportGetUnpaidInvoices",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Rechnungen, die am Ende eines bestimmten Tages noch ganz oder teilweise unbezahlt waren, optional gefiltert nach Shop und Zahlungsart.\n\nErstellt eine Offene-Posten-Liste der Rechnungen zu einem Stichtag.\n\n1. `Date` wird über `fPixi_GetDateEndOfDay` auf das Tagesende (23:59:59.997) gesetzt. Ohne Angabe wird der aktuelle Tag verwendet. `ShopID` wird getrimmt. Ein leerer Wert in `ShopID` oder `PaymentCode` gilt als „kein Filter“.\n2. Ausgewählt werden Rechnungen, die alle folgenden Bedingungen erfüllen:\n - Das Rechnungsdatum liegt vor dem Stichtag.\n - Die Rechnung ist keine Retoure bzw. Gutschrift, hat also keinen Bezug auf eine andere Rechnung.\n - Der Shop passt (`InvShopID = ShopID`), sofern `ShopID` angegeben ist.\n - Die Zahlungsart passt (`Payment = PaymentCode`), sofern `PaymentCode` angegeben ist.\n3. Jede Rechnung wird mit ihren Debitorenkonto-Einträgen verknüpft. Einträge, die bereits vollständig ausgeglichen sind (`Amount = Matched`) und vor dem Stichtag zuletzt geändert wurden, bleiben unberücksichtigt.\n4. Der offene Betrag ergibt sich aus dem Betrag des Debitorenkonto-Eintrags plus der Summe aller Ausgleichsbuchungen (`AbsoluteMatchAmount`), die vor dem Stichtag angelegt wurden. Dabei zählt ein Ausgleich unabhängig davon, ob der Eintrag als erster oder zweiter Ausgleichspartner referenziert ist. Geliefert werden nur Rechnungen, deren offener Betrag weiterhin kleiner 0 ist.\n5. Je offener Rechnung werden geliefert:\n - Rechnungsnummer, Rechnungsdatum und Rechnungsbetrag\n - offener Betrag\n - externe Kundennummer und DATEV-Kontonummer\n - Nachname und Vorname aus der Rechnungsadresse\n - Shop\n - Land der Lieferadresse\n - Währungscode\n\nDas Ergebnis hat kein `ORDER BY`, die Reihenfolge der Zeilen ist daher nicht definiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Date` | datetime | Nein | Stichtag. Als Grenze dient das Ende dieses Tages. Standard ist der aktuelle Tag. |\n| `ShopID` | varchar(3) | Nein | Beschränkt das Ergebnis auf Rechnungen dieses Shops. Leer oder NULL bedeutet alle Shops. |\n| `PaymentCode` | char(1) | Nein | Beschränkt das Ergebnis auf Rechnungen mit dieser Zahlungsart (`Invoices.Payment`). Leer oder NULL bedeutet alle Zahlungsarten. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen. Die Werte können daher nicht festgeschriebene Daten enthalten.\n- `OffenerRechnungsbetrag` folgt der Vorzeichenlogik des Debitorenkontos: Offene Forderungen sind **negative** Werte.\n- Die abschließende Abfrage verknüpft Rechnungsadresse, Lieferadresse, Kunde und Währung per Inner Join. Rechnungen, denen einer dieser Bezüge fehlt, werden nicht geliefert.\n- Hat eine Rechnung mehrere Debitorenkonto-Einträge, wird `MAX(Amount)` dieser Einträge mit der Summe aller ihrer Ausgleiche verrechnet. Der offene Betrag kann dann vom erwarteten Wert abweichen.\n- Rechnungen mit einem Zeitstempel genau am Tagesende (23:59:59.997) sind ausgeschlossen, da der Vergleich strikt (`<`) erfolgt.\n- Die Spaltennamen des Ergebnisses sind deutsch (`Rechnungsnummer`, `Kundennummer`, ...), mit Ausnahme von `DatevUserAccount`, `ShopID`, `CountryCode` und `CurrencyCode`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportGetUnpaidInvoices"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Rechnungen, die am Ende eines bestimmten Tages noch ganz oder teilweise unbezahlt waren, optional gefiltert nach Shop und Zahlungsart.\n\nErstellt eine Offene-Posten-Liste der Rechnungen zu einem Stichtag.\n\n1. `Date` wird über `fPixi_GetDateEndOfDay` auf das Tagesende (23:59:59.997) gesetzt. Ohne Angabe wird der aktuelle Tag verwendet. `ShopID` wird getrimmt. Ein leerer Wert in `ShopID` oder `PaymentCode` gilt als „kein Filter“.\n2. Ausgewählt werden Rechnungen, die alle folgenden Bedingungen erfüllen:\n - Das Rechnungsdatum liegt vor dem Stichtag.\n - Die Rechnung ist keine Retoure bzw. Gutschrift, hat also keinen Bezug auf eine andere Rechnung.\n - Der Shop passt (`InvShopID = ShopID`), sofern `ShopID` angegeben ist.\n - Die Zahlungsart passt (`Payment = PaymentCode`), sofern `PaymentCode` angegeben ist.\n3. Jede Rechnung wird mit ihren Debitorenkonto-Einträgen verknüpft. Einträge, die bereits vollständig ausgeglichen sind (`Amount = Matched`) und vor dem Stichtag zuletzt geändert wurden, bleiben unberücksichtigt.\n4. Der offene Betrag ergibt sich aus dem Betrag des Debitorenkonto-Eintrags plus der Summe aller Ausgleichsbuchungen (`AbsoluteMatchAmount`), die vor dem Stichtag angelegt wurden. Dabei zählt ein Ausgleich unabhängig davon, ob der Eintrag als erster oder zweiter Ausgleichspartner referenziert ist. Geliefert werden nur Rechnungen, deren offener Betrag weiterhin kleiner 0 ist.\n5. Je offener Rechnung werden geliefert:\n - Rechnungsnummer, Rechnungsdatum und Rechnungsbetrag\n - offener Betrag\n - externe Kundennummer und DATEV-Kontonummer\n - Nachname und Vorname aus der Rechnungsadresse\n - Shop\n - Land der Lieferadresse\n - Währungscode\n\nDas Ergebnis hat kein `ORDER BY`, die Reihenfolge der Zeilen ist daher nicht definiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Date` | datetime | Nein | Stichtag. Als Grenze dient das Ende dieses Tages. Standard ist der aktuelle Tag. |\n| `ShopID` | varchar(3) | Nein | Beschränkt das Ergebnis auf Rechnungen dieses Shops. Leer oder NULL bedeutet alle Shops. |\n| `PaymentCode` | char(1) | Nein | Beschränkt das Ergebnis auf Rechnungen mit dieser Zahlungsart (`Invoices.Payment`). Leer oder NULL bedeutet alle Zahlungsarten. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen. Die Werte können daher nicht festgeschriebene Daten enthalten.\n- `OffenerRechnungsbetrag` folgt der Vorzeichenlogik des Debitorenkontos: Offene Forderungen sind **negative** Werte.\n- Die abschließende Abfrage verknüpft Rechnungsadresse, Lieferadresse, Kunde und Währung per Inner Join. Rechnungen, denen einer dieser Bezüge fehlt, werden nicht geliefert.\n- Hat eine Rechnung mehrere Debitorenkonto-Einträge, wird `MAX(Amount)` dieser Einträge mit der Summe aller ihrer Ausgleiche verrechnet. Der offene Betrag kann dann vom erwarteten Wert abweichen.\n- Rechnungen mit einem Zeitstempel genau am Tagesende (23:59:59.997) sind ausgeschlossen, da der Vergleich strikt (`<`) erfolgt.\n- Die Spaltennamen des Ergebnisses sind deutsch (`Rechnungsnummer`, `Kundennummer`, ...), mit Ausnahme von `DatevUserAccount`, `ShopID`, `CountryCode` und `CurrencyCode`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportGetUnpaidInvoices"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n RE240312\n 2024-03-15T10:24:00\n 119.90\n -59.90\n K100234\n 10234\n Müller\n Anna\n ABC\n DE\n EUR\n \n"
}
]
},
{
"name": "pixiReportGetUnshippableOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert offene Auftragspositionen, die mangels Bestand nicht versendet werden können, als Summenzeile oder als Detailliste je Position.\n\nDer Aufruf ist ein Wrapper um die interne Prozedur `Report_GetUnshippableOrders`. Er übergibt immer `OrderlineStatus = NULL` und `ShopId = NULL`, es werden also alle Status und alle Shops ausgewertet. Das Ergebnis wird in einer temporären Tabelle zwischengespeichert, zurückgegeben wird eine Teilmenge der Spalten.\n\n**Auswahl der Auftragspositionen**\n\n1. Auftragspositionen müssen den Status `ANG` oder `HAL` haben, ein gesetztes `ItemRef` und `Qty > 0`.\n2. Berücksichtigt werden nur Aufträge mit mindestens einer solchen Position in einem Lager mit `SpecialStock = 0`. Ist `LocID` angegeben, muss es dieses Lager sein. Ein Leerstring gilt als kein Filter.\n3. Bei `IncludeCustLock` = `0` oder nicht gesendet werden zwei Arten von Aufträgen ausgeschlossen:\n - Aufträge, deren Kunde `SLocked` mit einem anderen Wert als `N`/NULL hat\n - Aufträge, deren Lieferadresse gesperrt ist (`ASlocked = 'Y'`)\n4. Bei `IncludeCustLock` = `1` werden gesperrte Kunden und Adressen einbezogen.\n5. Für alle `ANG`/`HAL`-Positionen der Kandidatenaufträge berechnet die interne Prozedur `pixi_CalculateStockForOrderLines`, ob die Position versendbar ist. Zurückgegeben werden nur Positionen mit Reservierungsinformation, die **nicht** versendbar sind.\n\n**Ausgabe abhängig von `ViewDetails`**\n\n- `0`: genau eine Summenzeile mit diesen Werten:\n - `Orders`: Anzahl verschiedener Aufträge\n - `OrderTotal`: Summe der Positionspreise\n - `ShipCost`: Summe der Versandkosten, je Auftrag einmal gezählt\n - `DiffrentCustomers`: Anzahl verschiedener Kunden\n - `MissingArticles`: Summe der Mengen\n - `DiffrentArticles`: Anzahl verschiedener Artikel\n - `dbCurrency`\n- `1`: eine Zeile je nicht versendbarer Auftragsposition. Die Zeilen haben keine definierte Sortierung.\n\nAlle Beträge werden in die Datenbankwährung umgerechnet, wenn die Einstellung `MultiCurrencyEnabled` aktiv ist.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ViewDetails` | bit | Nein | Wählt das Ausgabeformat: Summenzeile oder Detailliste je Auftragsposition. Sollte immer explizit gesendet werden (siehe Hinweise). |\n| `IncludeCustLock` | bit | Nein | Ob Aufträge gesperrter Kunden und Aufträge mit gesperrter Lieferadresse einbezogen werden. NULL wird als 0 behandelt. |\n| `LocID` | varchar(3) | Nein | Optionale Lager-ID. Berücksichtigt werden nur Aufträge mit mindestens einer relevanten Position in diesem Lager (mit `SpecialStock = 0`). NULL oder Leerstring bedeutet alle Lager ohne Sonderbestand. |\n\n- **`ViewDetails` immer explizit senden.** Der Wrapper prüft `ViewDetails = 0`. Ein NULL-Wert (Standard) führt daher in den Detailzweig. Die innere Prozedur behandelt NULL jedoch als `0` und liefert die Summenzeile mit 7 Spalten. Das `INSERT ... EXEC` in die Detailtabelle mit 21 Spalten schlägt dann voraussichtlich mit einem Spaltenfehler fehl.\n- Der Kopfkommentar nennt Auftragsstatus OPEN/HOLD und Positionsstatus `NLB`. Der Code filtert nur die Positionsstatus `ANG` und `HAL` und prüft den Auftragsstatus nicht.\n- Der Filter `LocID` wählt nur die Kandidatenaufträge aus. Ist ein Auftrag qualifiziert, werden alle seine `ANG`/`HAL`-Positionen ausgewertet, auch solche in anderen Lagern.\n- Die Versendbarkeitslogik liegt in `pixi_CalculateStockForOrderLines`, das nicht beigefügt ist. Der Aufruf erfolgt mit `SkipZeroStockItemsCalc = 1`. Die genauen Bestands- und Reservierungsregeln lassen sich hier nicht ableiten.\n- `OrderTotal` und `Price` basieren auf dem Positionsfeld `Price` und werden nicht mit `Qty` multipliziert.\n- In der Detailliste wiederholt `ShipCost` die Versandkosten des Auftrags in jeder Position.\n- `SLocked` ist nicht das Sperrkennzeichen des Kunden. Es spiegelt den Parameter: `Y` bei `IncludeCustLock = 1`, sonst `N`.\n- `Shippable` ist immer `0`.\n- `dbCurrency` ist nur bei aktivem `MultiCurrencyEnabled` gefüllt, sonst NULL. Beträge werden durch den Wechselkurs des passenden Datums geteilt. Ohne gefundenen Kurs bleibt der Wert unverändert.\n- In der Summenzeile können `OrderTotal`, `MissingArticles` und `DiffrentArticles` NULL bzw. 0 sein, wenn keine nicht versendbaren Positionen existieren. Eine Zeile wird trotzdem geliefert.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, nicht festgeschriebene Daten können daher enthalten sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportGetUnshippableOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert offene Auftragspositionen, die mangels Bestand nicht versendet werden können, als Summenzeile oder als Detailliste je Position.\n\nDer Aufruf ist ein Wrapper um die interne Prozedur `Report_GetUnshippableOrders`. Er übergibt immer `OrderlineStatus = NULL` und `ShopId = NULL`, es werden also alle Status und alle Shops ausgewertet. Das Ergebnis wird in einer temporären Tabelle zwischengespeichert, zurückgegeben wird eine Teilmenge der Spalten.\n\n**Auswahl der Auftragspositionen**\n\n1. Auftragspositionen müssen den Status `ANG` oder `HAL` haben, ein gesetztes `ItemRef` und `Qty > 0`.\n2. Berücksichtigt werden nur Aufträge mit mindestens einer solchen Position in einem Lager mit `SpecialStock = 0`. Ist `LocID` angegeben, muss es dieses Lager sein. Ein Leerstring gilt als kein Filter.\n3. Bei `IncludeCustLock` = `0` oder nicht gesendet werden zwei Arten von Aufträgen ausgeschlossen:\n - Aufträge, deren Kunde `SLocked` mit einem anderen Wert als `N`/NULL hat\n - Aufträge, deren Lieferadresse gesperrt ist (`ASlocked = 'Y'`)\n4. Bei `IncludeCustLock` = `1` werden gesperrte Kunden und Adressen einbezogen.\n5. Für alle `ANG`/`HAL`-Positionen der Kandidatenaufträge berechnet die interne Prozedur `pixi_CalculateStockForOrderLines`, ob die Position versendbar ist. Zurückgegeben werden nur Positionen mit Reservierungsinformation, die **nicht** versendbar sind.\n\n**Ausgabe abhängig von `ViewDetails`**\n\n- `0`: genau eine Summenzeile mit diesen Werten:\n - `Orders`: Anzahl verschiedener Aufträge\n - `OrderTotal`: Summe der Positionspreise\n - `ShipCost`: Summe der Versandkosten, je Auftrag einmal gezählt\n - `DiffrentCustomers`: Anzahl verschiedener Kunden\n - `MissingArticles`: Summe der Mengen\n - `DiffrentArticles`: Anzahl verschiedener Artikel\n - `dbCurrency`\n- `1`: eine Zeile je nicht versendbarer Auftragsposition. Die Zeilen haben keine definierte Sortierung.\n\nAlle Beträge werden in die Datenbankwährung umgerechnet, wenn die Einstellung `MultiCurrencyEnabled` aktiv ist.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ViewDetails` | bit | Nein | Wählt das Ausgabeformat: Summenzeile oder Detailliste je Auftragsposition. Sollte immer explizit gesendet werden (siehe Hinweise). |\n| `IncludeCustLock` | bit | Nein | Ob Aufträge gesperrter Kunden und Aufträge mit gesperrter Lieferadresse einbezogen werden. NULL wird als 0 behandelt. |\n| `LocID` | varchar(3) | Nein | Optionale Lager-ID. Berücksichtigt werden nur Aufträge mit mindestens einer relevanten Position in diesem Lager (mit `SpecialStock = 0`). NULL oder Leerstring bedeutet alle Lager ohne Sonderbestand. |\n\n- **`ViewDetails` immer explizit senden.** Der Wrapper prüft `ViewDetails = 0`. Ein NULL-Wert (Standard) führt daher in den Detailzweig. Die innere Prozedur behandelt NULL jedoch als `0` und liefert die Summenzeile mit 7 Spalten. Das `INSERT ... EXEC` in die Detailtabelle mit 21 Spalten schlägt dann voraussichtlich mit einem Spaltenfehler fehl.\n- Der Kopfkommentar nennt Auftragsstatus OPEN/HOLD und Positionsstatus `NLB`. Der Code filtert nur die Positionsstatus `ANG` und `HAL` und prüft den Auftragsstatus nicht.\n- Der Filter `LocID` wählt nur die Kandidatenaufträge aus. Ist ein Auftrag qualifiziert, werden alle seine `ANG`/`HAL`-Positionen ausgewertet, auch solche in anderen Lagern.\n- Die Versendbarkeitslogik liegt in `pixi_CalculateStockForOrderLines`, das nicht beigefügt ist. Der Aufruf erfolgt mit `SkipZeroStockItemsCalc = 1`. Die genauen Bestands- und Reservierungsregeln lassen sich hier nicht ableiten.\n- `OrderTotal` und `Price` basieren auf dem Positionsfeld `Price` und werden nicht mit `Qty` multipliziert.\n- In der Detailliste wiederholt `ShipCost` die Versandkosten des Auftrags in jeder Position.\n- `SLocked` ist nicht das Sperrkennzeichen des Kunden. Es spiegelt den Parameter: `Y` bei `IncludeCustLock = 1`, sonst `N`.\n- `Shippable` ist immer `0`.\n- `dbCurrency` ist nur bei aktivem `MultiCurrencyEnabled` gefüllt, sonst NULL. Beträge werden durch den Wechselkurs des passenden Datums geteilt. Ohne gefundenen Kurs bleibt der Wert unverändert.\n- In der Summenzeile können `OrderTotal`, `MissingArticles` und `DiffrentArticles` NULL bzw. 0 sein, wenn keine nicht versendbaren Positionen existieren. Eine Zeile wird trotzdem geliefert.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, nicht festgeschriebene Daten können daher enthalten sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportGetUnshippableOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 42\n 3189.5000\n 209.5800\n 39\n 77\n 25\n EUR\n \n"
}
]
},
{
"name": "pixiReport_GrossProfit",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-01-01T00:00:00\n 2024-01-31T00:00:00\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Rohertragsbericht pro Artikel für einen Rechnungsdatumsbereich mit Verkaufs- und Retourenwerten, optional gefiltert nach Shop, Kategorie, Lieferant, Zahlungsart und Tags.\n\nStellt den Pixi-Bericht *Rohertrag* (`Report_GrossProfit`) als API-Call bereit. Es wird nur die Detailansicht geliefert; der Summenmodus des Berichts ist fest deaktiviert.\n\n**Ablauf**\n\n1. Die Parameter werden normalisiert: `FromDate` wird auf den Tagesbeginn, `ToDate` auf das Tagesende (23:59:59.997) gesetzt. Leere Zeichenketten gelten als `NULL`; ein `TagKey` von `0` gilt ebenfalls als nicht gesetzt.\n2. Die Parameter werden geprüft. Liegt `FromDate` nach `ToDate` oder existiert ein angegebener Shop, eine Kategorie (`TontrArten`), ein Lieferant, eine Zahlungsart, eine auszuschließende Zahlungsart oder ein Tag nicht, wird eine einzelne Statuszeile mit `Status` = `Error` geliefert und der Aufruf beendet.\n3. Der Bericht liest Rechnungspositionen, deren Rechnungsdatum zwischen `FromDate` und `ToDate` liegt, und wendet die optionalen Filter an:\n - `ShopID`: nur Positionen dieses Shops.\n - `Category`: Konfigurationsart des Artikels entspricht der Kategorie.\n - `SupplNr`: nur Artikel dieses Lieferanten.\n - `PaymentType`: nur Positionen mit dieser Zahlungsart; `ExcludePaymentType`: Positionen mit dieser Zahlungsart werden ausgeschlossen.\n - `TagKey1`–`TagKey3`: nur Artikel, die alle angegebenen Tags besitzen (UND-Verknüpfung).\n4. Die Positionen werden pro Artikel gruppiert, getrennt nach verkauften und retournierten Mengen, und zu einer Zeile pro Artikel zusammengeführt.\n\n**Währung**\n\n- Ohne `ShopID` werden alle Beträge (bei aktivierter Mehrwährung) in die Datenbankwährung umgerechnet; `Currency` enthält den Code der Datenbankwährung.\n- Mit `ShopID` werden die Beträge bei aktivierter Mehrwährung in der Basiswährung des Shops geliefert, sonst wird der Code der Datenbankwährung ausgegeben.\n\n**Werte pro Zeile**\n\n- `Sales_*` sind mengengewichtete durchschnittliche Stückwerte der verkauften Positionen (Brutto-Verkaufspreis, MwSt., Lieferantenpreis).\n- `Returns_*` sind die entsprechenden Werte der retournierten Positionen.\n- `SingleGrossProfit` = durchschnittlicher Brutto-VK − durchschnittliche MwSt. − durchschnittlicher EK der verkauften Positionen.\n- `TotalGrossProfit` = Stück-Rohertrag der Verkäufe × verkaufte Menge − Stück-Rohertrag der Retouren × retournierte Menge.\n\nSonderpositionen wie Versandkosten oder Gutscheine (negative interne Artikelschlüssel) können als eigene Zeilen erscheinen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Ja | Beginn des Rechnungsdatumsbereichs. Die Uhrzeit wird ignoriert; der Bereich beginnt mit Tagesbeginn. |\n| `ToDate` | datetime | Ja | Ende des Rechnungsdatumsbereichs. Die Uhrzeit wird ignoriert; der ganze Tag ist eingeschlossen. |\n| `ShopID` | varchar(3) | Nein | Optionaler Shop-Filter. Muss in `Shops` existieren. Wenn gesetzt, werden Beträge (bei aktivierter Mehrwährung) in der Basiswährung des Shops geliefert. |\n| `Category` | varchar(10) | Nein | Optionale Artikelkategorie (Konfigurationsart, `TontrArt`). Muss in `TontrArten` existieren. |\n| `SupplNr` | varchar(10) | Nein | Optionale Lieferantennummer. Muss in `Suppliers` existieren. |\n| `PaymentType` | char(1) | Nein | Optionaler Zahlungsart-Code; nur Rechnungspositionen mit dieser Zahlungsart werden berücksichtigt. Muss in `Payments.Code` existieren. |\n| `ExcludePaymentType` | char(1) | Nein | Optionaler auszuschließender Zahlungsart-Code. Muss in `Payments.Code` existieren. |\n| `TagKey1` | int | Nein | Optionale Artikel-Tag-ID. Nur Artikel mit diesem Tag werden berücksichtigt. `0` bedeutet kein Filter. |\n| `TagKey2` | int | Nein | Optionale zweite Artikel-Tag-ID; Artikel müssen sie zusätzlich zu `TagKey1` besitzen. Wird ohne `TagKey1` nicht als Filter verwendet. |\n| `TagKey3` | int | Nein | Optionale dritte Artikel-Tag-ID; wird nur als Filter verwendet, wenn `TagKey1` und `TagKey2` gesetzt sind. |\n\n- Die Fehlerzeilen enthalten zwei Spalten: `Status` und einen Fehlertext. Nur bei der Prüfung von `ExcludePaymentType` heißt die Textspalte `Message`; bei allen anderen Prüfungen hat die Spalte keinen Alias, sodass sie im SOAP-Client unter einem generierten Namen (z. B. `Column1`) ankommen kann.\n- Der Datumsfehlertext lautet `\"DateTo\" is greater than \"DateFrom\"`, wird aber geliefert, wenn `FromDate` nach `ToDate` liegt.\n- `FromDate` und `ToDate` haben keinen Standardwert. Wird `NULL` übergeben, passen keine Rechnungspositionen und das Ergebnis ist leer.\n- Die Tag-Filterung greift nur, wenn `TagKey1` gesetzt ist. `TagKey2` wird nur zusammen mit `TagKey1` verwendet, `TagKey3` nur wenn `TagKey1` und `TagKey2` gesetzt sind; z. B. wird `TagKey2` allein zwar geprüft, aber nicht als Filter verwendet.\n- Der zugrunde liegende Bericht sortiert nach Artikelname, die Zeilen laufen jedoch über eine temporäre Tabelle und das abschließende `SELECT` hat kein `ORDER BY`; die Reihenfolge ist daher nicht garantiert.\n- Bei jedem Aufruf wird zuerst `Report_SaveSupplierPrices` ausgeführt, das laut Kommentar eine Cache-Tabelle mit Lieferantenpreisen befüllt; die Definition liegt nicht vor. Das Mehrwährungsverhalten hängt von der Einstellung `MultiCurrencyEnabled` ab.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, nicht festgeschriebene Daten können enthalten sein. Große Datumsbereiche können langsam sein.\n- Durchschnittswerte werden durch die Summe der absoluten Mengen geteilt; Gruppen mit Gesamtmenge null könnten einen Division-durch-Null-Fehler auslösen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_GrossProfit"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-01-01T00:00:00\n 2024-01-31T00:00:00\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Rohertragsbericht pro Artikel für einen Rechnungsdatumsbereich mit Verkaufs- und Retourenwerten, optional gefiltert nach Shop, Kategorie, Lieferant, Zahlungsart und Tags.\n\nStellt den Pixi-Bericht *Rohertrag* (`Report_GrossProfit`) als API-Call bereit. Es wird nur die Detailansicht geliefert; der Summenmodus des Berichts ist fest deaktiviert.\n\n**Ablauf**\n\n1. Die Parameter werden normalisiert: `FromDate` wird auf den Tagesbeginn, `ToDate` auf das Tagesende (23:59:59.997) gesetzt. Leere Zeichenketten gelten als `NULL`; ein `TagKey` von `0` gilt ebenfalls als nicht gesetzt.\n2. Die Parameter werden geprüft. Liegt `FromDate` nach `ToDate` oder existiert ein angegebener Shop, eine Kategorie (`TontrArten`), ein Lieferant, eine Zahlungsart, eine auszuschließende Zahlungsart oder ein Tag nicht, wird eine einzelne Statuszeile mit `Status` = `Error` geliefert und der Aufruf beendet.\n3. Der Bericht liest Rechnungspositionen, deren Rechnungsdatum zwischen `FromDate` und `ToDate` liegt, und wendet die optionalen Filter an:\n - `ShopID`: nur Positionen dieses Shops.\n - `Category`: Konfigurationsart des Artikels entspricht der Kategorie.\n - `SupplNr`: nur Artikel dieses Lieferanten.\n - `PaymentType`: nur Positionen mit dieser Zahlungsart; `ExcludePaymentType`: Positionen mit dieser Zahlungsart werden ausgeschlossen.\n - `TagKey1`–`TagKey3`: nur Artikel, die alle angegebenen Tags besitzen (UND-Verknüpfung).\n4. Die Positionen werden pro Artikel gruppiert, getrennt nach verkauften und retournierten Mengen, und zu einer Zeile pro Artikel zusammengeführt.\n\n**Währung**\n\n- Ohne `ShopID` werden alle Beträge (bei aktivierter Mehrwährung) in die Datenbankwährung umgerechnet; `Currency` enthält den Code der Datenbankwährung.\n- Mit `ShopID` werden die Beträge bei aktivierter Mehrwährung in der Basiswährung des Shops geliefert, sonst wird der Code der Datenbankwährung ausgegeben.\n\n**Werte pro Zeile**\n\n- `Sales_*` sind mengengewichtete durchschnittliche Stückwerte der verkauften Positionen (Brutto-Verkaufspreis, MwSt., Lieferantenpreis).\n- `Returns_*` sind die entsprechenden Werte der retournierten Positionen.\n- `SingleGrossProfit` = durchschnittlicher Brutto-VK − durchschnittliche MwSt. − durchschnittlicher EK der verkauften Positionen.\n- `TotalGrossProfit` = Stück-Rohertrag der Verkäufe × verkaufte Menge − Stück-Rohertrag der Retouren × retournierte Menge.\n\nSonderpositionen wie Versandkosten oder Gutscheine (negative interne Artikelschlüssel) können als eigene Zeilen erscheinen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Ja | Beginn des Rechnungsdatumsbereichs. Die Uhrzeit wird ignoriert; der Bereich beginnt mit Tagesbeginn. |\n| `ToDate` | datetime | Ja | Ende des Rechnungsdatumsbereichs. Die Uhrzeit wird ignoriert; der ganze Tag ist eingeschlossen. |\n| `ShopID` | varchar(3) | Nein | Optionaler Shop-Filter. Muss in `Shops` existieren. Wenn gesetzt, werden Beträge (bei aktivierter Mehrwährung) in der Basiswährung des Shops geliefert. |\n| `Category` | varchar(10) | Nein | Optionale Artikelkategorie (Konfigurationsart, `TontrArt`). Muss in `TontrArten` existieren. |\n| `SupplNr` | varchar(10) | Nein | Optionale Lieferantennummer. Muss in `Suppliers` existieren. |\n| `PaymentType` | char(1) | Nein | Optionaler Zahlungsart-Code; nur Rechnungspositionen mit dieser Zahlungsart werden berücksichtigt. Muss in `Payments.Code` existieren. |\n| `ExcludePaymentType` | char(1) | Nein | Optionaler auszuschließender Zahlungsart-Code. Muss in `Payments.Code` existieren. |\n| `TagKey1` | int | Nein | Optionale Artikel-Tag-ID. Nur Artikel mit diesem Tag werden berücksichtigt. `0` bedeutet kein Filter. |\n| `TagKey2` | int | Nein | Optionale zweite Artikel-Tag-ID; Artikel müssen sie zusätzlich zu `TagKey1` besitzen. Wird ohne `TagKey1` nicht als Filter verwendet. |\n| `TagKey3` | int | Nein | Optionale dritte Artikel-Tag-ID; wird nur als Filter verwendet, wenn `TagKey1` und `TagKey2` gesetzt sind. |\n\n- Die Fehlerzeilen enthalten zwei Spalten: `Status` und einen Fehlertext. Nur bei der Prüfung von `ExcludePaymentType` heißt die Textspalte `Message`; bei allen anderen Prüfungen hat die Spalte keinen Alias, sodass sie im SOAP-Client unter einem generierten Namen (z. B. `Column1`) ankommen kann.\n- Der Datumsfehlertext lautet `\"DateTo\" is greater than \"DateFrom\"`, wird aber geliefert, wenn `FromDate` nach `ToDate` liegt.\n- `FromDate` und `ToDate` haben keinen Standardwert. Wird `NULL` übergeben, passen keine Rechnungspositionen und das Ergebnis ist leer.\n- Die Tag-Filterung greift nur, wenn `TagKey1` gesetzt ist. `TagKey2` wird nur zusammen mit `TagKey1` verwendet, `TagKey3` nur wenn `TagKey1` und `TagKey2` gesetzt sind; z. B. wird `TagKey2` allein zwar geprüft, aber nicht als Filter verwendet.\n- Der zugrunde liegende Bericht sortiert nach Artikelname, die Zeilen laufen jedoch über eine temporäre Tabelle und das abschließende `SELECT` hat kein `ORDER BY`; die Reihenfolge ist daher nicht garantiert.\n- Bei jedem Aufruf wird zuerst `Report_SaveSupplierPrices` ausgeführt, das laut Kommentar eine Cache-Tabelle mit Lieferantenpreisen befüllt; die Definition liegt nicht vor. Das Mehrwährungsverhalten hängt von der Einstellung `MultiCurrencyEnabled` ab.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, nicht festgeschriebene Daten können enthalten sein. Große Datumsbereiche können langsam sein.\n- Durchschnittswerte werden durch die Summe der absoluten Mengen geteilt; Gruppen mit Gesamtmenge null könnten einen Division-durch-Null-Fehler auslösen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_GrossProfit"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n HX-4410\n 4012345678901\n Trinkflasche Edelstahl 750 ml\n Hydro Supplies GmbH\n 42\n 19.9900\n 3.1900\n 7.5000\n 19.9900\n 2\n 3.1900\n 7.5000\n 9.3000\n 372.0000\n EUR\n \n"
}
]
},
{
"name": "pixiReport_InvoicesList",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-01-01T00:00:00\n 2024-01-31T00:00:00\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine detaillierte Liste der Rechnungen und Gutschriften eines Zeitraums mit Beträgen, MwSt., Einkaufswerten, Adress- und Zahlungsdaten.\n\nWrapper um die interne Report-Prozedur `Report_InvoicesList`. Leere Strings in `ShopID`, `Payment`, `ShipCountry` und `DocumentType` werden als `NULL` (kein Filter) behandelt. Der Report liefert immer eine Zeile je Rechnung; der Summenmodus und der Filter auf unbezahlte Rechnungen der internen Prozedur sind über diesen Call nicht verfügbar.\n\nAblauf:\n\n1. Zuerst wird der Cache der Lieferantenpreise aktualisiert (`Report_SaveSupplierPrices`).\n2. `DateFrom` wird auf den Tagesbeginn, `DateTo` auf das Tagesende gesetzt. Ausgewählt werden Rechnungen mit `InvDate` in diesem Zeitraum.\n3. Optionale Filter:\n - `ShopID`: nur Rechnungen, deren **Lieferadresse** zu diesem Shop gehört (`AddrShopID`). Rechnungen ohne Lieferadresse fallen dann heraus.\n - `Payment`: nur Rechnungen mit diesem Zahlungsart-Code.\n - `ShipCountry`: nur Rechnungen, deren Lieferadresse diesen Ländercode hat.\n - `DocumentType`: `R` = nur Rechnungen (ohne Bezugsrechnung), `G` = nur Gutschriften (mit Bezugsrechnung).\n4. Währung der Beträge:\n - Mit `ShopID`: Beträge in der Basiswährung der Rechnung (bei aktivierter Mehrwährung durch den Rechnungskurs geteilt); `BaseCurrency` enthält diesen Währungscode.\n - Ohne `ShopID`: Beträge werden über den Wechselkurs der Datenbankquelle zum selben Datum und zur selben Währung in die Datenbankwährung umgerechnet; `BaseCurrency` enthält den Code der Datenbankwährung.\n5. Je Rechnung werden die Artikelmenge (`SumQtyItems`) und der Einkaufswert (`SumEKItems`, Menge × historischer Lieferantenpreis) aus den Rechnungspositionen summiert. Die externe Auftragsnummer wird über den mit der Rechnung verknüpften Auftrag ermittelt (bei Gutschriften über die Bezugsrechnung).\n6. Netto- und MwSt.-Beträge werden auf die Anzahl Nachkommastellen aus der Einstellung `NumberOfDecimalPlacesForPrices` (Standard 2) gerundet. `Total` und `Total_ShipCost` werden nicht gerundet.\n\nName, Anschrift, Telefon und Fax stammen aus der Lieferadresse; `Country`, `CountryName` und `usStID` aus der Rechnungsadresse. Fehlende Textwerte werden als `/` geliefert. Sortiert wird nach `InvoiceNR`. Die `par_*`-Spalten geben die wirksamen Filterwerte zurück (`-alle-`, wenn kein Filter gesetzt ist).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Ja | Beginn des Rechnungsdatum-Zeitraums; die Uhrzeit wird auf den Tagesbeginn gesetzt. |\n| `DateTo` | datetime | Ja | Ende des Rechnungsdatum-Zeitraums; die Uhrzeit wird auf das Tagesende gesetzt. |\n| `ShopID` | char(3) | Nein | Shop der Lieferadresse. Wenn gesetzt, werden nur Rechnungen dieses Shops geliefert und Beträge in der Basiswährung der Rechnung ausgegeben, sonst in der Datenbankwährung. Leer = alle Shops. |\n| `Payment` | char(1) | Nein | Zahlungsart-Code der Rechnung. Leer = alle Zahlungsarten. |\n| `ShipCountry` | varchar(3) | Nein | Ländercode der Lieferadresse. Leer = alle Länder. |\n| `DocumentType` | char(1) | Nein | Filter auf den Belegtyp. Leer = Rechnungen und Gutschriften. |\n\n- Nebeneffekt: Vor dem Lesen wird die interne Prozedur `Report_SaveSupplierPrices` ausgeführt, die laut Code-Kommentar eine Cache-Tabelle füllt (vermutlich die Lieferantenpreis-Historie). Ihre Definition liegt nicht vor, die genauen Schreibvorgänge sind daher unbekannt.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Rechnungen ohne passenden Wechselkurs-Datensatz werden nicht geliefert (Inner Joins auf `pixi.ExchRate`). Ohne `ShopID` muss ein Kurs der Datenbankquelle zum selben Datum und zur selben Währung existieren.\n- Ein `DocumentType` außer `R` oder `G` liefert keine Zeilen.\n- `payed` wird bei unbezahlten Rechnungen als `1900-01-01T00:00:00` geliefert, da `NULL` bei einer Datetime-Spalte durch einen Leerstring ersetzt wird.\n- `SumEKItems` ist 0 oder unvollständig, wenn für die Rechnungspositionen keine Lieferantenpreis-Historie existiert.\n- Liefert die Funktion zur Auftragsermittlung mehrere Aufträge für eine Rechnung, kann die Rechnung mehrfach erscheinen.\n- Das Verhalten hängt von den Einstellungen `MultiCurrencyEnabled` und `NumberOfDecimalPlacesForPrices` ab.\n- Große Zeiträume können langsam sein, da alle Rechnungspositionen aggregiert werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_InvoicesList"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-01-01T00:00:00\n 2024-01-31T00:00:00\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine detaillierte Liste der Rechnungen und Gutschriften eines Zeitraums mit Beträgen, MwSt., Einkaufswerten, Adress- und Zahlungsdaten.\n\nWrapper um die interne Report-Prozedur `Report_InvoicesList`. Leere Strings in `ShopID`, `Payment`, `ShipCountry` und `DocumentType` werden als `NULL` (kein Filter) behandelt. Der Report liefert immer eine Zeile je Rechnung; der Summenmodus und der Filter auf unbezahlte Rechnungen der internen Prozedur sind über diesen Call nicht verfügbar.\n\nAblauf:\n\n1. Zuerst wird der Cache der Lieferantenpreise aktualisiert (`Report_SaveSupplierPrices`).\n2. `DateFrom` wird auf den Tagesbeginn, `DateTo` auf das Tagesende gesetzt. Ausgewählt werden Rechnungen mit `InvDate` in diesem Zeitraum.\n3. Optionale Filter:\n - `ShopID`: nur Rechnungen, deren **Lieferadresse** zu diesem Shop gehört (`AddrShopID`). Rechnungen ohne Lieferadresse fallen dann heraus.\n - `Payment`: nur Rechnungen mit diesem Zahlungsart-Code.\n - `ShipCountry`: nur Rechnungen, deren Lieferadresse diesen Ländercode hat.\n - `DocumentType`: `R` = nur Rechnungen (ohne Bezugsrechnung), `G` = nur Gutschriften (mit Bezugsrechnung).\n4. Währung der Beträge:\n - Mit `ShopID`: Beträge in der Basiswährung der Rechnung (bei aktivierter Mehrwährung durch den Rechnungskurs geteilt); `BaseCurrency` enthält diesen Währungscode.\n - Ohne `ShopID`: Beträge werden über den Wechselkurs der Datenbankquelle zum selben Datum und zur selben Währung in die Datenbankwährung umgerechnet; `BaseCurrency` enthält den Code der Datenbankwährung.\n5. Je Rechnung werden die Artikelmenge (`SumQtyItems`) und der Einkaufswert (`SumEKItems`, Menge × historischer Lieferantenpreis) aus den Rechnungspositionen summiert. Die externe Auftragsnummer wird über den mit der Rechnung verknüpften Auftrag ermittelt (bei Gutschriften über die Bezugsrechnung).\n6. Netto- und MwSt.-Beträge werden auf die Anzahl Nachkommastellen aus der Einstellung `NumberOfDecimalPlacesForPrices` (Standard 2) gerundet. `Total` und `Total_ShipCost` werden nicht gerundet.\n\nName, Anschrift, Telefon und Fax stammen aus der Lieferadresse; `Country`, `CountryName` und `usStID` aus der Rechnungsadresse. Fehlende Textwerte werden als `/` geliefert. Sortiert wird nach `InvoiceNR`. Die `par_*`-Spalten geben die wirksamen Filterwerte zurück (`-alle-`, wenn kein Filter gesetzt ist).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Ja | Beginn des Rechnungsdatum-Zeitraums; die Uhrzeit wird auf den Tagesbeginn gesetzt. |\n| `DateTo` | datetime | Ja | Ende des Rechnungsdatum-Zeitraums; die Uhrzeit wird auf das Tagesende gesetzt. |\n| `ShopID` | char(3) | Nein | Shop der Lieferadresse. Wenn gesetzt, werden nur Rechnungen dieses Shops geliefert und Beträge in der Basiswährung der Rechnung ausgegeben, sonst in der Datenbankwährung. Leer = alle Shops. |\n| `Payment` | char(1) | Nein | Zahlungsart-Code der Rechnung. Leer = alle Zahlungsarten. |\n| `ShipCountry` | varchar(3) | Nein | Ländercode der Lieferadresse. Leer = alle Länder. |\n| `DocumentType` | char(1) | Nein | Filter auf den Belegtyp. Leer = Rechnungen und Gutschriften. |\n\n- Nebeneffekt: Vor dem Lesen wird die interne Prozedur `Report_SaveSupplierPrices` ausgeführt, die laut Code-Kommentar eine Cache-Tabelle füllt (vermutlich die Lieferantenpreis-Historie). Ihre Definition liegt nicht vor, die genauen Schreibvorgänge sind daher unbekannt.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Rechnungen ohne passenden Wechselkurs-Datensatz werden nicht geliefert (Inner Joins auf `pixi.ExchRate`). Ohne `ShopID` muss ein Kurs der Datenbankquelle zum selben Datum und zur selben Währung existieren.\n- Ein `DocumentType` außer `R` oder `G` liefert keine Zeilen.\n- `payed` wird bei unbezahlten Rechnungen als `1900-01-01T00:00:00` geliefert, da `NULL` bei einer Datetime-Spalte durch einen Leerstring ersetzt wird.\n- `SumEKItems` ist 0 oder unvollständig, wenn für die Rechnungspositionen keine Lieferantenpreis-Historie existiert.\n- Liefert die Funktion zur Auftragsermittlung mehrere Aufträge für eine Rechnung, kann die Rechnung mehrfach erscheinen.\n- Das Verhalten hängt von den Einstellungen `MultiCurrencyEnabled` und `NumberOfDecimalPlacesForPrices` ab.\n- Große Zeiträume können langsam sein, da alle Rechnungspositionen aggregiert werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_InvoicesList"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 48211\n \n 2024-01-12T00:00:00\n 2024-01-10T14:22:05\n RE2024-00123\n 119.000000000\n 100.000000000\n 95.800000000\n 4.200000000\n 5.000000000\n 19.000000000\n 0.000000000\n 19.0000\n 7.0000\n 2\n 100045678\n 54.300000000\n 10023\n Herr\n Max Mustermann\n Max\n Mustermann\n /\n Musterstr. 1\n 80331\n München\n DE\n Deutschland\n /\n /\n DE\n Deutschland\n SHP\n Vorkasse\n /\n 2024-01-01T00:00:00\n 2024-01-31T23:59:59.997\n -alle- \n -alle- \n -alle-\n R \n EUR\n \n"
}
]
},
{
"name": "pixiReport_LogisticQuality",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Verteilung der Aufträge der letzten Tage nach Anzahl der Tage zwischen Auftragseingang und erster Lieferung als Logistik-Kennzahl.\n\nBerechnet, wie viele Tage der Versand der Aufträge der letzten Tage gedauert hat, und gruppiert die Aufträge nach dieser Anzahl.\n\n**1. Auswahl der Aufträge**\n\nEin Auftrag wird berücksichtigt, wenn:\n- sein `Orderheader.CreateDate` höchstens `@DaysBack` Tage zurückliegt;\n- er mindestens eine Auftragsposition im Status `ANG` oder `AUS` hat. Ist `@ShopID` nicht leer, muss zusätzlich die `OrdShopId` der Position passen;\n- er keine Position im Status `ANG`/`AUS` hat (angelegt innerhalb von `@DaysBack` Tagen, gleicher Shop-Filter), deren Artikel vor Anlage der Position keinen in `InvBinItemLog` gebuchten Bestand hatte;\n- der Kunde nicht gesperrt ist (`HSLocked = 'Y'` in `CustomersHist`).\n\nAls Bezugsdatum des Auftrags gilt das früheste `StatusChangeDate` eines `ANG`-Eintrags in `Orderhistory` zu seinen Positionen.\n\n**2. Bestandsprüfung**\n\nDie Prozedur sammelt alle Positionen der ausgewählten Aufträge. Ein Auftrag wird entfernt, wenn für einen seiner Artikel die summierte Menge aller gesammelten Positionen höher ist als der bis zum Bezugsdatum in `InvBinItemLog` gebuchte Bestand. Summiert werden nur Positionen, die bis zu diesem Datum angelegt und nicht vorher (oder noch gar nicht) versendet wurden.\n\n**3. Datumsanpassungen**\n\n- Wochenende (mit `DATEFIRST 1`): Aufträge von Freitag nach 14:59 Uhr werden um 3 Tage verschoben. Samstagsaufträge werden um 2 Tage, Sonntagsaufträge um 1 Tag verschoben. Die Uhrzeit bleibt gleich.\n- Tage ohne Versand: Ein Tag gilt als Versandtag, wenn es an ihm innerhalb von `@DaysBack` Tagen mehr als 2 Rechnungen mit `total > 0` gibt. Ein Auftrag, dessen ursprünglicher Eingangstag kein Versandtag ist, erhält ein neues Bezugsdatum: den frühesten Rechnungszeitpunkt des nächsten Versandtags. Dies ersetzt die Wochenendanpassung.\n\n**4. Berechnung**\n\nJe Auftrag ist `DaysToShip` die ganzzahlige Anzahl von 24-Stunden-Intervallen vom angepassten Bezugsdatum bis zum frühesten `ShipDate` seiner Positionen. Negative Werte werden auf 0 gesetzt.\n\nNicht versendete Aufträge werden ausgeschlossen, sowohl aus der Gruppierung als auch aus der Gesamtzahl `AllPackages`.\n\n**5. Ergebnis**\n\nEine Zeile je `DaysToShip`-Wert mit:\n- der Anzahl Aufträge;\n- ihrem Anteil an `AllPackages`;\n- der Gesamtzahl `AllPackages`.\n\nZusätzlich wird immer eine feste Zeile mit `DaysToShip = 99` und 0 Aufträgen angehängt. Die Zeilen sind aufsteigend nach `DaysToShip` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DaysBack` | int | Nein | Anzahl Tage ab heute rückwärts. Ältere Aufträge, Auftragspositionen und Rechnungen werden nicht berücksichtigt. |\n| `OnlyItemsOnStock` | bit | Nein | Deklariert, aber im Code nicht verwendet. Die Bestandsprüfungen werden immer angewendet. |\n| `ShopID` | varchar(3) | Nein | Shop-Filter auf `OrdShopId` der Auftragspositionen. Leer oder NULL bedeutet alle Shops. |\n| `MinutesSinceRefresh` | int | Nein | Deklariert, aber im Code nicht verwendet. |\n\n- Die Parameter `@OnlyItemsOnStock` und `@MinutesSinceRefresh` sind deklariert, werden im Code aber nicht verwendet.\n- `@ShopID` filtert auf das Positionsfeld `OrdShopId`, nicht auf den Auftragskopf.\n- Laut Code-Kommentar gilt Freitag ab 14:00 Uhr. Der Code prüft `hour > 14`, die Wochenendverschiebung beginnt also erst ab 15:00 Uhr.\n- Der Kommentar bezeichnet die ermittelten Tage als „Feiertage“ (Tage ohne Versand). Tatsächlich enthält die Tabelle Tage mit mehr als 2 Rechnungen. Aufträge von allen anderen Tagen werden auf den ersten Rechnungszeitpunkt des nächsten solchen Tags verschoben. Gibt es keinen späteren Versandtag, wird das Bezugsdatum NULL und der Auftrag zählt als nicht versendet.\n- Enthält `CustomersHist.HCustRef` NULL-Werte, schließt der `NOT IN`-Filter alle Aufträge aus.\n- Die Zeile mit `DaysToShip = 99` ist eine feste Markierungszeile mit `NRofORders = 0` und `Percentage = 0`. Sie wird immer geliefert, auch wenn kein Auftrag die Bedingungen erfüllt.\n- `Percentage` ist ein Anteil zwischen 0 und 1, kein Prozentwert.\n- Die meisten Lesezugriffe nutzen `NOLOCK`, die Zahlen können daher nicht festgeschriebene Daten enthalten. Der erste Zugriff auf `Orderheader` erfolgt ohne `NOLOCK`.\n- Die Prozedur verwendet viele korrelierte Unterabfragen auf `Orderhistory`, `Orderlines` und `InvBinItemLog`. Große Werte für `@DaysBack` können langsam sein.\n- Die Prozedur schreibt nur in temporäre Tabellen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_LogisticQuality"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Verteilung der Aufträge der letzten Tage nach Anzahl der Tage zwischen Auftragseingang und erster Lieferung als Logistik-Kennzahl.\n\nBerechnet, wie viele Tage der Versand der Aufträge der letzten Tage gedauert hat, und gruppiert die Aufträge nach dieser Anzahl.\n\n**1. Auswahl der Aufträge**\n\nEin Auftrag wird berücksichtigt, wenn:\n- sein `Orderheader.CreateDate` höchstens `@DaysBack` Tage zurückliegt;\n- er mindestens eine Auftragsposition im Status `ANG` oder `AUS` hat. Ist `@ShopID` nicht leer, muss zusätzlich die `OrdShopId` der Position passen;\n- er keine Position im Status `ANG`/`AUS` hat (angelegt innerhalb von `@DaysBack` Tagen, gleicher Shop-Filter), deren Artikel vor Anlage der Position keinen in `InvBinItemLog` gebuchten Bestand hatte;\n- der Kunde nicht gesperrt ist (`HSLocked = 'Y'` in `CustomersHist`).\n\nAls Bezugsdatum des Auftrags gilt das früheste `StatusChangeDate` eines `ANG`-Eintrags in `Orderhistory` zu seinen Positionen.\n\n**2. Bestandsprüfung**\n\nDie Prozedur sammelt alle Positionen der ausgewählten Aufträge. Ein Auftrag wird entfernt, wenn für einen seiner Artikel die summierte Menge aller gesammelten Positionen höher ist als der bis zum Bezugsdatum in `InvBinItemLog` gebuchte Bestand. Summiert werden nur Positionen, die bis zu diesem Datum angelegt und nicht vorher (oder noch gar nicht) versendet wurden.\n\n**3. Datumsanpassungen**\n\n- Wochenende (mit `DATEFIRST 1`): Aufträge von Freitag nach 14:59 Uhr werden um 3 Tage verschoben. Samstagsaufträge werden um 2 Tage, Sonntagsaufträge um 1 Tag verschoben. Die Uhrzeit bleibt gleich.\n- Tage ohne Versand: Ein Tag gilt als Versandtag, wenn es an ihm innerhalb von `@DaysBack` Tagen mehr als 2 Rechnungen mit `total > 0` gibt. Ein Auftrag, dessen ursprünglicher Eingangstag kein Versandtag ist, erhält ein neues Bezugsdatum: den frühesten Rechnungszeitpunkt des nächsten Versandtags. Dies ersetzt die Wochenendanpassung.\n\n**4. Berechnung**\n\nJe Auftrag ist `DaysToShip` die ganzzahlige Anzahl von 24-Stunden-Intervallen vom angepassten Bezugsdatum bis zum frühesten `ShipDate` seiner Positionen. Negative Werte werden auf 0 gesetzt.\n\nNicht versendete Aufträge werden ausgeschlossen, sowohl aus der Gruppierung als auch aus der Gesamtzahl `AllPackages`.\n\n**5. Ergebnis**\n\nEine Zeile je `DaysToShip`-Wert mit:\n- der Anzahl Aufträge;\n- ihrem Anteil an `AllPackages`;\n- der Gesamtzahl `AllPackages`.\n\nZusätzlich wird immer eine feste Zeile mit `DaysToShip = 99` und 0 Aufträgen angehängt. Die Zeilen sind aufsteigend nach `DaysToShip` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DaysBack` | int | Nein | Anzahl Tage ab heute rückwärts. Ältere Aufträge, Auftragspositionen und Rechnungen werden nicht berücksichtigt. |\n| `OnlyItemsOnStock` | bit | Nein | Deklariert, aber im Code nicht verwendet. Die Bestandsprüfungen werden immer angewendet. |\n| `ShopID` | varchar(3) | Nein | Shop-Filter auf `OrdShopId` der Auftragspositionen. Leer oder NULL bedeutet alle Shops. |\n| `MinutesSinceRefresh` | int | Nein | Deklariert, aber im Code nicht verwendet. |\n\n- Die Parameter `@OnlyItemsOnStock` und `@MinutesSinceRefresh` sind deklariert, werden im Code aber nicht verwendet.\n- `@ShopID` filtert auf das Positionsfeld `OrdShopId`, nicht auf den Auftragskopf.\n- Laut Code-Kommentar gilt Freitag ab 14:00 Uhr. Der Code prüft `hour > 14`, die Wochenendverschiebung beginnt also erst ab 15:00 Uhr.\n- Der Kommentar bezeichnet die ermittelten Tage als „Feiertage“ (Tage ohne Versand). Tatsächlich enthält die Tabelle Tage mit mehr als 2 Rechnungen. Aufträge von allen anderen Tagen werden auf den ersten Rechnungszeitpunkt des nächsten solchen Tags verschoben. Gibt es keinen späteren Versandtag, wird das Bezugsdatum NULL und der Auftrag zählt als nicht versendet.\n- Enthält `CustomersHist.HCustRef` NULL-Werte, schließt der `NOT IN`-Filter alle Aufträge aus.\n- Die Zeile mit `DaysToShip = 99` ist eine feste Markierungszeile mit `NRofORders = 0` und `Percentage = 0`. Sie wird immer geliefert, auch wenn kein Auftrag die Bedingungen erfüllt.\n- `Percentage` ist ein Anteil zwischen 0 und 1, kein Prozentwert.\n- Die meisten Lesezugriffe nutzen `NOLOCK`, die Zahlen können daher nicht festgeschriebene Daten enthalten. Der erste Zugriff auf `Orderheader` erfolgt ohne `NOLOCK`.\n- Die Prozedur verwendet viele korrelierte Unterabfragen auf `Orderhistory`, `Orderlines` und `InvBinItemLog`. Große Werte für `@DaysBack` können langsam sein.\n- Die Prozedur schreibt nur in temporäre Tabellen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_LogisticQuality"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 0\n 132\n 0.825\n 160\n \n \n 1\n 28\n 0.175\n 160\n \n \n 99\n 0\n 0\n 160\n \n"
}
]
},
{
"name": "pixiReport_LogisticQuality_Details",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Logistikqualitäts-Report: Tage von Auftragsanlage bis Versand je Auftrag oder eine prozentuale Verteilung für das Versandsiegel.\n\nMisst, wie viele Tage (in 24-Stunden-Schritten) der Versand von Aufträgen gedauert hat, die in den letzten `DaysBack` Tagen angelegt wurden.\n\n**Zeitraum**: `FromDate` ist der Tagesbeginn vor `DaysBack` Tagen, `ToDate` das Ende des heutigen Tages.\n\n**Auftragsauswahl**:\n- Aufträge, deren Kopf-`CreateDate` am oder nach `FromDate` liegt.\n- Das Anlagedatum des Auftrags ist der früheste `ANG`-Eintrag in `OrderHistory` innerhalb des Zeitraums. Das Versanddatum ist das früheste `ShipDate` der Auftragspositionen.\n- Das `ShipDate` im Auftragskopf muss `NULL` sein.\n- Mindestens eine Auftragsposition muss den Status `ANG` oder `AUS` haben. Ist `ShopID` gesetzt, muss diese Position zusätzlich zu diesem Shop gehören (`OrdShopID`).\n- Aufträge von Kunden, die nach `FromDate` in `CustomersHist` gesperrt wurden (`HSLocked = 'Y'`), werden ausgeschlossen.\n\n**Weitere Ausschlüsse** (der gesamte Auftrag entfällt, sobald eine Position betroffen ist):\n- Auftragspositionen, deren Anlagezeitpunkte mehr als 5 Minuten auseinanderliegen. Solche Aufträge gelten als nach dem Import manuell geändert.\n- Nicht ausreichender Bestand zum Auftragsdatum. Der Bedarf wird je Artikel aus Anlage- und Versandereignissen kumuliert. Der Bestand wird aus `InvBinItemLog` in Lagern ohne Sonderbestand (`SpecialStock = 0`) berechnet. Ist der Bedarf größer oder gleich dem Bestand, entfällt der Auftrag.\n- Positionen auf `ANG`, deren verfügbarer Bestand `<= 1` ist. Als verfügbarer Bestand gilt `ItemLocationSpecific.LocationQuantity`, wenn Sonderbestandslager existieren, sonst `Items.Quantity`. Bei `CalcSeal = 0` werden frühere Reservierungen offener Aufträge (nicht finale Status außer `EIN`, `FUT`, `FUS`) abgezogen.\n\n**Datumsanpassungen**:\n- Aufträge, die an einem Freitag, Samstag oder Sonntag angelegt wurden, werden auf den folgenden Montag verschoben. Die Uhrzeit bleibt erhalten.\n- Als Feiertage gelten Tage ohne Rechnungen mit positivem Betrag. Ein Auftrag wird auf den ersten Rechnungszeitpunkt des nächsten Tages mit Rechnungen verschoben, wenn einer dieser Fälle zutrifft:\n - sein Anlagetag hat keine solchen Rechnungen;\n - der Folgetag hat keine solchen Rechnungen.\n\n**Ausgabe** (nur Aufträge mit Versanddatum):\n- `CalcSeal = 0` (pixi* Report-Client): eine Zeile je Auftrag mit `DaysToShip`, Auftragsnummer und Datumswerten, sortiert nach `DaysToShip` und `CreateDate`. Mit `ExcludeZeros = 1` werden nur Aufträge mit `DaysToShip > 0` geliefert.\n- `CalcSeal = 1` (Seal-/Dashboard-Apps): eine Zeile je `DaysToShip`-Wert mit der Anzahl der Aufträge, ihrem Anteil an allen Paketen und der Gesamtzahl. Zusätzlich wird immer eine Zeile mit `DaysToShip = 99` und Nullwerten angefügt. Die Zeilen sind nach `DaysToShip` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DaysBack` | int | Nein | Anzahl der Tage ab heute rückwärts, die den Auswertungszeitraum bilden. |\n| `ShopID` | varchar(3) | Nein | Beschränkt den Report auf Aufträge mit einer `ANG`/`AUS`-Position dieses Shops. Leer bedeutet alle Shops. |\n| `ExcludeZeros` | bit | Nein | Nur bei `CalcSeal = 0`: Bei 1 werden Aufträge, die innerhalb der ersten 24 Stunden versendet wurden (`DaysToShip = 0`), ausgelassen. |\n| `OnlyItemsOnStock` | bit | Nein | Wird im Code nicht verwendet. |\n| `CalcSeal` | bit | Nein | Wählt den Ausgabemodus: Detailzeilen je Auftrag oder aggregierte Verteilung für das Versandsiegel. |\n\n- Der Parameter `OnlyItemsOnStock` ist deklariert, wird im Code aber nirgends verwendet.\n- Alle permanenten Tabellen werden mit `NOLOCK` gelesen, das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Innerhalb der Prozedur wird `SET DATEFIRST 1` gesetzt. Die Wochentage 5–7 sind Freitag bis Sonntag.\n- Das ausgegebene `CreateDate` ist das angepasste Datum (Wochenend-/Feiertagsverschiebung), nicht das ursprüngliche Auftragsdatum.\n- Aufträge mit gesetztem `ShipDate` im Auftragskopf werden nicht berücksichtigt. Als Versanddatum dient das früheste `ShipDate` der Positionen.\n- Aufträge, deren `ANG`-Positionen keinen passenden `ItemLocationSpecific`-Eintrag für das Lager der Position haben, werden von der Reservierungsbestandsprüfung nicht entfernt.\n- Die Feiertagserkennung basiert auf Rechnungen mit `total > 0`. Tage ohne Rechnungen gelten als Feiertage.\n- Laut Codekommentar müssen Änderungen auch in `pixiReport_LogisticQuality_NonCached` nachgezogen werden.\n- Die Berechnung läuft über viele temporäre Tabellen und Fensterfunktionen. Große `DaysBack`-Werte können langsam sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_LogisticQuality_Details"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Logistikqualitäts-Report: Tage von Auftragsanlage bis Versand je Auftrag oder eine prozentuale Verteilung für das Versandsiegel.\n\nMisst, wie viele Tage (in 24-Stunden-Schritten) der Versand von Aufträgen gedauert hat, die in den letzten `DaysBack` Tagen angelegt wurden.\n\n**Zeitraum**: `FromDate` ist der Tagesbeginn vor `DaysBack` Tagen, `ToDate` das Ende des heutigen Tages.\n\n**Auftragsauswahl**:\n- Aufträge, deren Kopf-`CreateDate` am oder nach `FromDate` liegt.\n- Das Anlagedatum des Auftrags ist der früheste `ANG`-Eintrag in `OrderHistory` innerhalb des Zeitraums. Das Versanddatum ist das früheste `ShipDate` der Auftragspositionen.\n- Das `ShipDate` im Auftragskopf muss `NULL` sein.\n- Mindestens eine Auftragsposition muss den Status `ANG` oder `AUS` haben. Ist `ShopID` gesetzt, muss diese Position zusätzlich zu diesem Shop gehören (`OrdShopID`).\n- Aufträge von Kunden, die nach `FromDate` in `CustomersHist` gesperrt wurden (`HSLocked = 'Y'`), werden ausgeschlossen.\n\n**Weitere Ausschlüsse** (der gesamte Auftrag entfällt, sobald eine Position betroffen ist):\n- Auftragspositionen, deren Anlagezeitpunkte mehr als 5 Minuten auseinanderliegen. Solche Aufträge gelten als nach dem Import manuell geändert.\n- Nicht ausreichender Bestand zum Auftragsdatum. Der Bedarf wird je Artikel aus Anlage- und Versandereignissen kumuliert. Der Bestand wird aus `InvBinItemLog` in Lagern ohne Sonderbestand (`SpecialStock = 0`) berechnet. Ist der Bedarf größer oder gleich dem Bestand, entfällt der Auftrag.\n- Positionen auf `ANG`, deren verfügbarer Bestand `<= 1` ist. Als verfügbarer Bestand gilt `ItemLocationSpecific.LocationQuantity`, wenn Sonderbestandslager existieren, sonst `Items.Quantity`. Bei `CalcSeal = 0` werden frühere Reservierungen offener Aufträge (nicht finale Status außer `EIN`, `FUT`, `FUS`) abgezogen.\n\n**Datumsanpassungen**:\n- Aufträge, die an einem Freitag, Samstag oder Sonntag angelegt wurden, werden auf den folgenden Montag verschoben. Die Uhrzeit bleibt erhalten.\n- Als Feiertage gelten Tage ohne Rechnungen mit positivem Betrag. Ein Auftrag wird auf den ersten Rechnungszeitpunkt des nächsten Tages mit Rechnungen verschoben, wenn einer dieser Fälle zutrifft:\n - sein Anlagetag hat keine solchen Rechnungen;\n - der Folgetag hat keine solchen Rechnungen.\n\n**Ausgabe** (nur Aufträge mit Versanddatum):\n- `CalcSeal = 0` (pixi* Report-Client): eine Zeile je Auftrag mit `DaysToShip`, Auftragsnummer und Datumswerten, sortiert nach `DaysToShip` und `CreateDate`. Mit `ExcludeZeros = 1` werden nur Aufträge mit `DaysToShip > 0` geliefert.\n- `CalcSeal = 1` (Seal-/Dashboard-Apps): eine Zeile je `DaysToShip`-Wert mit der Anzahl der Aufträge, ihrem Anteil an allen Paketen und der Gesamtzahl. Zusätzlich wird immer eine Zeile mit `DaysToShip = 99` und Nullwerten angefügt. Die Zeilen sind nach `DaysToShip` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DaysBack` | int | Nein | Anzahl der Tage ab heute rückwärts, die den Auswertungszeitraum bilden. |\n| `ShopID` | varchar(3) | Nein | Beschränkt den Report auf Aufträge mit einer `ANG`/`AUS`-Position dieses Shops. Leer bedeutet alle Shops. |\n| `ExcludeZeros` | bit | Nein | Nur bei `CalcSeal = 0`: Bei 1 werden Aufträge, die innerhalb der ersten 24 Stunden versendet wurden (`DaysToShip = 0`), ausgelassen. |\n| `OnlyItemsOnStock` | bit | Nein | Wird im Code nicht verwendet. |\n| `CalcSeal` | bit | Nein | Wählt den Ausgabemodus: Detailzeilen je Auftrag oder aggregierte Verteilung für das Versandsiegel. |\n\n- Der Parameter `OnlyItemsOnStock` ist deklariert, wird im Code aber nirgends verwendet.\n- Alle permanenten Tabellen werden mit `NOLOCK` gelesen, das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Innerhalb der Prozedur wird `SET DATEFIRST 1` gesetzt. Die Wochentage 5–7 sind Freitag bis Sonntag.\n- Das ausgegebene `CreateDate` ist das angepasste Datum (Wochenend-/Feiertagsverschiebung), nicht das ursprüngliche Auftragsdatum.\n- Aufträge mit gesetztem `ShipDate` im Auftragskopf werden nicht berücksichtigt. Als Versanddatum dient das früheste `ShipDate` der Positionen.\n- Aufträge, deren `ANG`-Positionen keinen passenden `ItemLocationSpecific`-Eintrag für das Lager der Position haben, werden von der Reservierungsbestandsprüfung nicht entfernt.\n- Die Feiertagserkennung basiert auf Rechnungen mit `total > 0`. Tage ohne Rechnungen gelten als Feiertage.\n- Laut Codekommentar müssen Änderungen auch in `pixiReport_LogisticQuality_NonCached` nachgezogen werden.\n- Die Berechnung läuft über viele temporäre Tabellen und Fensterfunktionen. Große `DaysBack`-Werte können langsam sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_LogisticQuality_Details"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 0\n 100234\n 2024-05-06T09:12:00\n 2024-05-06T15:40:00\n -alle-\n 14\n \n \n 1\n 100251\n 2024-05-07T11:05:00\n 2024-05-08T14:20:00\n -alle-\n 14\n \n"
}
]
},
{
"name": "pixiReport_LogisticQuality_NonCached",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Verteilung versendeter Aufträge nach Tagen zwischen Bestellung und Versand der letzten Tage, wie sie für die Versandsiegel-Quote verwendet wird.\n\nWrapper für die pixi* Seal-App und die Dashboard-App. `NULL`-Werte werden durch die Standardwerte (`14`, `''`, `1`) ersetzt. Danach wird `pipiReport_LogisticQuality_Details` mit `@CalcSeal = 1` ausgeführt; die Daten werden direkt berechnet (nicht aus einem Cache).\n\n**Auswahl der Aufträge**\n- Zeitraum: vom Tagesbeginn vor `@DaysBack` Tagen bis zum Ende des heutigen Tages.\n- Als Erstelldatum eines Auftrags gilt der erste Statuswechsel nach `ANG` seiner Auftragspositionen in `OrderHistory` im Zeitraum. Als Versanddatum gilt das früheste `ShipDate` seiner Positionen.\n- Berücksichtigt werden nur Aufträge, deren `OrderHeader.ShipDate` leer ist und die mindestens eine Position im Status `ANG` oder `AUS` haben. Ist `ShopID` nicht leer, muss diese Position zu diesem Shop gehören (`OrdShopID`).\n- Aufträge von Kunden, die im Zeitraum gesperrt waren (`CustomersHist.HSLocked = 'Y'`), werden ausgeschlossen.\n\n**Ausschlüsse**\n- Manuell geänderte Aufträge: Die Erstellzeiten der Positionen liegen mehr als 5 Minuten auseinander.\n- Aufträge, bei denen der Bestand zum Bestelldatum nicht ausreichte. Der Bestand wird aus `InvBinItemLog` auf Lagern ohne Sonderbestand berechnet, abzüglich des kumulierten offenen Bedarfs je Artikel.\n- Aufträge mit einer Position im Status `ANG`, deren Artikelbestand höchstens 1 beträgt. Als Bestand gilt `ItemLocationSpecific.LocationQuantity`, wenn Sonderbestandslager existieren, sonst `Items.Quantity`.\n\n**Datumsanpassungen**\n- Aufträge von Freitag, Samstag oder Sonntag werden auf den folgenden Montag verschoben.\n- Tage ohne Rechnung mit `total > 0` gelten als Feiertage. Aufträge an einem solchen Tag oder am Tag davor werden auf das erste Rechnungsdatum eines späteren Arbeitstags verschoben.\n\n**Ergebnis**\n- Gezählt werden nur Aufträge mit Versanddatum.\n- `DaysToShip` ist die Anzahl voller 24-Stunden-Intervalle zwischen dem angepassten Erstelldatum und dem Versanddatum. Negative Werte werden zu 0.\n- Je `DaysToShip`-Wert wird eine Zeile mit der Anzahl und dem Anteil an allen gezählten Aufträgen geliefert.\n- Zusätzlich wird immer eine feste Zeile mit `DaysToShip = 99` und 0 Aufträgen angehängt.\n- Die Zeilen sind nach `DaysToShip` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DaysBack` | int | Nein | Anzahl der Tage ab heute rückwärts, die ausgewertet werden. `NULL` wird zu 14. |\n| `ShopID` | varchar(3) | Nein | Shop-Filter auf den Shop der Auftragsposition (`OrdShopID`). Leer oder `NULL` bedeutet alle Shops. |\n| `OnlyItemsOnStock` | bit | Nein | Wird an die Detailprozedur weitergegeben, dort aber nicht ausgewertet; ohne Wirkung. |\n\n- Der Parameter `OnlyItemsOnStock` wird an `pipiReport_LogisticQuality_Details` weitergegeben, dort aber nicht verwendet. Er hat keine Wirkung.\n- Alle Lesezugriffe verwenden `NOLOCK`; die Zahlen können daher nicht festgeschriebene Daten enthalten.\n- Die Berechnung läuft bei jedem Aufruf und kann bei großen `DaysBack`-Werten aufwendig sein.\n- Qualifiziert sich kein Auftrag, wird nur die Zeile mit `DaysToShip = 99` geliefert und `AllPackages` ist 0.\n- Die Spalten `Percentage` und `AllPackages` sind Gleitkommawerte. `Percentage` ist ein Anteil zwischen 0 und 1, nicht mit 100 multipliziert.\n- Feiertage werden aus Tagen ohne Rechnungen abgeleitet; auch Tage ohne Fakturierung gelten daher als arbeitsfreie Tage.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_LogisticQuality_NonCached"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Verteilung versendeter Aufträge nach Tagen zwischen Bestellung und Versand der letzten Tage, wie sie für die Versandsiegel-Quote verwendet wird.\n\nWrapper für die pixi* Seal-App und die Dashboard-App. `NULL`-Werte werden durch die Standardwerte (`14`, `''`, `1`) ersetzt. Danach wird `pipiReport_LogisticQuality_Details` mit `@CalcSeal = 1` ausgeführt; die Daten werden direkt berechnet (nicht aus einem Cache).\n\n**Auswahl der Aufträge**\n- Zeitraum: vom Tagesbeginn vor `@DaysBack` Tagen bis zum Ende des heutigen Tages.\n- Als Erstelldatum eines Auftrags gilt der erste Statuswechsel nach `ANG` seiner Auftragspositionen in `OrderHistory` im Zeitraum. Als Versanddatum gilt das früheste `ShipDate` seiner Positionen.\n- Berücksichtigt werden nur Aufträge, deren `OrderHeader.ShipDate` leer ist und die mindestens eine Position im Status `ANG` oder `AUS` haben. Ist `ShopID` nicht leer, muss diese Position zu diesem Shop gehören (`OrdShopID`).\n- Aufträge von Kunden, die im Zeitraum gesperrt waren (`CustomersHist.HSLocked = 'Y'`), werden ausgeschlossen.\n\n**Ausschlüsse**\n- Manuell geänderte Aufträge: Die Erstellzeiten der Positionen liegen mehr als 5 Minuten auseinander.\n- Aufträge, bei denen der Bestand zum Bestelldatum nicht ausreichte. Der Bestand wird aus `InvBinItemLog` auf Lagern ohne Sonderbestand berechnet, abzüglich des kumulierten offenen Bedarfs je Artikel.\n- Aufträge mit einer Position im Status `ANG`, deren Artikelbestand höchstens 1 beträgt. Als Bestand gilt `ItemLocationSpecific.LocationQuantity`, wenn Sonderbestandslager existieren, sonst `Items.Quantity`.\n\n**Datumsanpassungen**\n- Aufträge von Freitag, Samstag oder Sonntag werden auf den folgenden Montag verschoben.\n- Tage ohne Rechnung mit `total > 0` gelten als Feiertage. Aufträge an einem solchen Tag oder am Tag davor werden auf das erste Rechnungsdatum eines späteren Arbeitstags verschoben.\n\n**Ergebnis**\n- Gezählt werden nur Aufträge mit Versanddatum.\n- `DaysToShip` ist die Anzahl voller 24-Stunden-Intervalle zwischen dem angepassten Erstelldatum und dem Versanddatum. Negative Werte werden zu 0.\n- Je `DaysToShip`-Wert wird eine Zeile mit der Anzahl und dem Anteil an allen gezählten Aufträgen geliefert.\n- Zusätzlich wird immer eine feste Zeile mit `DaysToShip = 99` und 0 Aufträgen angehängt.\n- Die Zeilen sind nach `DaysToShip` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DaysBack` | int | Nein | Anzahl der Tage ab heute rückwärts, die ausgewertet werden. `NULL` wird zu 14. |\n| `ShopID` | varchar(3) | Nein | Shop-Filter auf den Shop der Auftragsposition (`OrdShopID`). Leer oder `NULL` bedeutet alle Shops. |\n| `OnlyItemsOnStock` | bit | Nein | Wird an die Detailprozedur weitergegeben, dort aber nicht ausgewertet; ohne Wirkung. |\n\n- Der Parameter `OnlyItemsOnStock` wird an `pipiReport_LogisticQuality_Details` weitergegeben, dort aber nicht verwendet. Er hat keine Wirkung.\n- Alle Lesezugriffe verwenden `NOLOCK`; die Zahlen können daher nicht festgeschriebene Daten enthalten.\n- Die Berechnung läuft bei jedem Aufruf und kann bei großen `DaysBack`-Werten aufwendig sein.\n- Qualifiziert sich kein Auftrag, wird nur die Zeile mit `DaysToShip = 99` geliefert und `AllPackages` ist 0.\n- Die Spalten `Percentage` und `AllPackages` sind Gleitkommawerte. `Percentage` ist ein Anteil zwischen 0 und 1, nicht mit 100 multipliziert.\n- Feiertage werden aus Tagen ohne Rechnungen abgeleitet; auch Tage ohne Fakturierung gelten daher als arbeitsfreie Tage.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_LogisticQuality_NonCached"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 0\n 152\n 0.76\n 200\n \n \n 99\n 0\n 0\n 200\n \n"
}
]
},
{
"name": "pixiReport_NewCustomersStats",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert für ein Jahr einen Monatsbericht, der Bestellanzahl, Bestellwerte und Durchschnittswerte von Neukunden und Bestandskunden vergleicht.\n\nErstellt einen pivotierten Bericht mit einer Zeile je Berichtszeile und einer Spalte je Monat (`Month01`–`Month12`) sowie einer Spalte `Average`.\n\n**Parameter und Filter**\n- `Year` wird bei `NULL` auf das aktuelle Jahr gesetzt.\n- `Shop` (Vergleich mit `Customers.CustomerOf`) und `Country` (Vergleich mit dem Land der Adresse der Auftragsposition) sind optional; ein Leerstring wird wie `NULL` behandelt, also ohne Filter.\n\n**Neukunden**\nEin Kunde gilt in einem Monat als Neukunde, wenn das früheste `OrderDate` aller seiner Auftragspositionen (innerhalb des Shop-/Länderfilters) in diesem Monat von `Year` liegt. Nur die Positionen mit genau diesem Erstbestelldatum zählen als Neukundenbestellung; weitere Bestellungen im selben Monat gelten als Bestellungen von Bestandskunden.\n\n**Berichtszeilen** (`GroupNumber` / `LineNumber`)\n- Gruppe 1 – Bestellanzahl:\n - 1 `Orders new customers`: Anzahl der Kunden, deren Erstbestellung in den Monat fällt.\n - 2 `Orders customers`: Zeile 3 minus Zeile 1.\n - 3 `Total`: Anzahl unterschiedlicher Auftragsnummern im Monat, ohne Positionen mit Status `STO` oder `NLB`.\n - 4 `rate new customers`: Zeile 1 / Zeile 3 × 100 (0, wenn Zeile 3 gleich 0).\n- Gruppe 2 – Bestellwerte (Summe von `OrderLineAmount`, Positionen mit Status `STO`/`NLB` ausgeschlossen):\n - 5 Wert der Erstbestellungen von Neukunden.\n - 6 Zeile 7 minus Zeile 5.\n - 7 `Total`: Wert aller Auftragspositionen des Monats.\n - 8 Anteil Neukunden (Zeile 5 / Zeile 7 × 100), 9 Anteil Bestandskunden (Zeile 6 / Zeile 7 × 100).\n- Gruppe 3 – Durchschnitt je Auftragsposition:\n - 10 durchschnittlicher `OrderLineAmount` aller Kandidatenpositionen im Monat.\n - 11 durchschnittlicher `OrderLineAmount` der Erstbestellpositionen von Neukunden.\n\n**Spalte Average**: arithmetisches Mittel der für die Zeile vorhandenen Monatswerte.\n\nDie Zeilen sind nach `LineNumber` sortiert. `ParYear`, `ParShop` und `ParCountry` geben die wirksamen Parameter zurück; `dbCurrency` enthält den Code der Datenbankwährung, wenn Multi-Currency aktiv ist.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Year` | int | Nein | Berichtsjahr. `NULL` bedeutet das aktuelle Jahr. |\n| `Shop` | varchar(3) | Nein | Shop-ID, verglichen mit `Customers.CustomerOf`. `NULL` oder Leerstring bedeutet alle Shops. |\n| `Country` | varchar(3) | Nein | Ländercode der Adresse der Auftragsposition. `NULL` oder Leerstring bedeutet alle Länder. |\n\n- **Multi-Currency**: Ist die Einstellung `MultiCurrencyEnabled` gleich `1`, werden Bestellwerte in die Datenbankwährung umgerechnet (Einstellung `HomeCurrency`, Kursquelle aus `DatabaseCurrencyExchRateSourceId`), über `pixi.ExchRate` zum Kursdatum des Auftragskopfs. Auftragspositionen ohne passenden `OrderHeader` bzw. Kurs fallen dann aus den Wertzeilen heraus. Andernfalls ist der Kurs 1 und `dbCurrency` ist `NULL`.\n- **Fallstrick Beschriftung**: Zeile 10 ist als Durchschnitt der Neukunden beschriftet, mittelt aber *alle* Kandidatenpositionen (inklusive Status `STO`/`NLB`); Zeile 11 ist als Durchschnitt der Kunden beschriftet, mittelt aber die Erstbestellpositionen der Neukunden. Zeilen 10 und 11 schließen `STO`/`NLB` nicht aus.\n- Die Durchschnitte in Gruppe 3 beziehen sich auf Auftragspositionen, nicht auf Aufträge.\n- Zeilen 6, 7, 8, 9 und 10 enthalten nur Monate mit Auftragspositionen; andere Monate bleiben `0` und fließen nicht in `Average` ein, `Average` ist also nur der Mittelwert der Monate mit Daten.\n- Erstbestellungen werden ohne Statusfilter ermittelt; ein Kunde, dessen früheste Position Status `STO`/`NLB` hat, wird trotzdem in Zeile 1 gezählt.\n- Die Neukundenermittlung nutzt Inner Joins auf Adresse und Kunde, daher werden Positionen ohne Land oder `CustomerOf` nicht berücksichtigt, während die Gesamtzeilen `NULL`-Werte für Land/Shop akzeptieren.\n- Ein Monat kann in den Zeilen 2–4 fehlen, wenn alle seine Aufträge durch die Filter entfallen.\n- Alle Lesezugriffe erfolgen mit `NOLOCK` (Dirty Reads möglich). Zeile 3 verknüpft Auftragspositionen über `MONTH(OrderDate)`, was die gesamte Tabelle `Orderlines` durchsucht und bei großen Datenbanken langsam sein kann.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_NewCustomersStats"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert für ein Jahr einen Monatsbericht, der Bestellanzahl, Bestellwerte und Durchschnittswerte von Neukunden und Bestandskunden vergleicht.\n\nErstellt einen pivotierten Bericht mit einer Zeile je Berichtszeile und einer Spalte je Monat (`Month01`–`Month12`) sowie einer Spalte `Average`.\n\n**Parameter und Filter**\n- `Year` wird bei `NULL` auf das aktuelle Jahr gesetzt.\n- `Shop` (Vergleich mit `Customers.CustomerOf`) und `Country` (Vergleich mit dem Land der Adresse der Auftragsposition) sind optional; ein Leerstring wird wie `NULL` behandelt, also ohne Filter.\n\n**Neukunden**\nEin Kunde gilt in einem Monat als Neukunde, wenn das früheste `OrderDate` aller seiner Auftragspositionen (innerhalb des Shop-/Länderfilters) in diesem Monat von `Year` liegt. Nur die Positionen mit genau diesem Erstbestelldatum zählen als Neukundenbestellung; weitere Bestellungen im selben Monat gelten als Bestellungen von Bestandskunden.\n\n**Berichtszeilen** (`GroupNumber` / `LineNumber`)\n- Gruppe 1 – Bestellanzahl:\n - 1 `Orders new customers`: Anzahl der Kunden, deren Erstbestellung in den Monat fällt.\n - 2 `Orders customers`: Zeile 3 minus Zeile 1.\n - 3 `Total`: Anzahl unterschiedlicher Auftragsnummern im Monat, ohne Positionen mit Status `STO` oder `NLB`.\n - 4 `rate new customers`: Zeile 1 / Zeile 3 × 100 (0, wenn Zeile 3 gleich 0).\n- Gruppe 2 – Bestellwerte (Summe von `OrderLineAmount`, Positionen mit Status `STO`/`NLB` ausgeschlossen):\n - 5 Wert der Erstbestellungen von Neukunden.\n - 6 Zeile 7 minus Zeile 5.\n - 7 `Total`: Wert aller Auftragspositionen des Monats.\n - 8 Anteil Neukunden (Zeile 5 / Zeile 7 × 100), 9 Anteil Bestandskunden (Zeile 6 / Zeile 7 × 100).\n- Gruppe 3 – Durchschnitt je Auftragsposition:\n - 10 durchschnittlicher `OrderLineAmount` aller Kandidatenpositionen im Monat.\n - 11 durchschnittlicher `OrderLineAmount` der Erstbestellpositionen von Neukunden.\n\n**Spalte Average**: arithmetisches Mittel der für die Zeile vorhandenen Monatswerte.\n\nDie Zeilen sind nach `LineNumber` sortiert. `ParYear`, `ParShop` und `ParCountry` geben die wirksamen Parameter zurück; `dbCurrency` enthält den Code der Datenbankwährung, wenn Multi-Currency aktiv ist.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Year` | int | Nein | Berichtsjahr. `NULL` bedeutet das aktuelle Jahr. |\n| `Shop` | varchar(3) | Nein | Shop-ID, verglichen mit `Customers.CustomerOf`. `NULL` oder Leerstring bedeutet alle Shops. |\n| `Country` | varchar(3) | Nein | Ländercode der Adresse der Auftragsposition. `NULL` oder Leerstring bedeutet alle Länder. |\n\n- **Multi-Currency**: Ist die Einstellung `MultiCurrencyEnabled` gleich `1`, werden Bestellwerte in die Datenbankwährung umgerechnet (Einstellung `HomeCurrency`, Kursquelle aus `DatabaseCurrencyExchRateSourceId`), über `pixi.ExchRate` zum Kursdatum des Auftragskopfs. Auftragspositionen ohne passenden `OrderHeader` bzw. Kurs fallen dann aus den Wertzeilen heraus. Andernfalls ist der Kurs 1 und `dbCurrency` ist `NULL`.\n- **Fallstrick Beschriftung**: Zeile 10 ist als Durchschnitt der Neukunden beschriftet, mittelt aber *alle* Kandidatenpositionen (inklusive Status `STO`/`NLB`); Zeile 11 ist als Durchschnitt der Kunden beschriftet, mittelt aber die Erstbestellpositionen der Neukunden. Zeilen 10 und 11 schließen `STO`/`NLB` nicht aus.\n- Die Durchschnitte in Gruppe 3 beziehen sich auf Auftragspositionen, nicht auf Aufträge.\n- Zeilen 6, 7, 8, 9 und 10 enthalten nur Monate mit Auftragspositionen; andere Monate bleiben `0` und fließen nicht in `Average` ein, `Average` ist also nur der Mittelwert der Monate mit Daten.\n- Erstbestellungen werden ohne Statusfilter ermittelt; ein Kunde, dessen früheste Position Status `STO`/`NLB` hat, wird trotzdem in Zeile 1 gezählt.\n- Die Neukundenermittlung nutzt Inner Joins auf Adresse und Kunde, daher werden Positionen ohne Land oder `CustomerOf` nicht berücksichtigt, während die Gesamtzeilen `NULL`-Werte für Land/Shop akzeptieren.\n- Ein Monat kann in den Zeilen 2–4 fehlen, wenn alle seine Aufträge durch die Filter entfallen.\n- Alle Lesezugriffe erfolgen mit `NOLOCK` (Dirty Reads möglich). Zeile 3 verknüpft Auftragspositionen über `MONTH(OrderDate)`, was die gesamte Tabelle `Orderlines` durchsucht und bei großen Datenbanken langsam sein kann.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_NewCustomersStats"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 1\n Orders new customers (Bestellungen Neukunden)\n 42\n 37\n 51\n 0\n 0\n 0\n 0\n 0\n 0\n 0\n 0\n 0\n 10.83\n 2024\n DE\n EUR\n \n \n 1\n 2\n Orders customers (Bestellungen Bestandskunden)\n 118\n 104\n 129\n 0\n 0\n 0\n 0\n 0\n 0\n 0\n 0\n 0\n 29.25\n 2024\n DE\n EUR\n \n"
}
]
},
{
"name": "pixiReportOrderOverview",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine Übersicht der Aufträge mit Rechnungsadresse, Auftragssummen, Netto-Rohertrag und Währung, optional gefiltert nach Auftragsdatum und Auftragsnummer.\n\nLiefert eine Zeile pro Auftrag aus `OrderHeader`, verknüpft mit der zugehörigen Adresse (`AddrRef` = `AddrKey`) und der Auftragswährung.\n\n**Filter**\n- **Datumsbereich:** Ist `OrderDateFrom` gesetzt, werden nur Aufträge geliefert, deren `OrderDate` zwischen `OrderDateFrom` und `OrderDateTo` liegt (einschließlich). Ist `OrderDateTo` leer, wird das aktuelle Datum mit Uhrzeit verwendet. Ist `OrderDateFrom` leer, wird nicht nach Datum gefiltert, auch wenn `OrderDateTo` gesetzt ist.\n- **Auftragsnummer:** Ist `OrderNrStart` gesetzt, werden nur Aufträge mit `OrderNr` >= `OrderNrStart` geliefert.\n- Beide Filter werden mit UND verknüpft.\n\n**Zeilenlimit und Sortierung**\n- Die Anzahl der Zeilen wird auf `RowCount` begrenzt (Standard 1000).\n- Sortiert wird absteigend nach `OrderNr`, die neuesten Aufträge (höchste Auftragsnummern) stehen also zuerst.\n\n**Berechneter Wert**\n- `GrossProfit_Netto` ist die Summe von `Qty * (Price_Net - SupplPrice)` über alle Auftragspositionen des Auftrags.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderDateFrom` | datetime | Nein | Beginn des Auftragsdatumsbereichs (einschließlich). Bei `NULL` wird nicht nach Datum gefiltert. |\n| `OrderDateTo` | datetime | Nein | Ende des Auftragsdatumsbereichs (einschließlich). Bei `NULL` und gesetztem `OrderDateFrom` wird das aktuelle Datum mit Uhrzeit verwendet. Wird ignoriert, wenn `OrderDateFrom` `NULL` ist. |\n| `OrderNrStart` | int | Nein | Niedrigste zu liefernde Auftragsnummer (`OrderNr` >= Wert). Bei `NULL` wird nicht nach Auftragsnummer gefiltert. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. `0` bedeutet keine Begrenzung. |\n\n- Laut Code-Kommentar wird der Rohertrag aus dem Standard-Lieferantenpreis berechnet, der zum Zeitpunkt der Bestellung an der Auftragsposition gespeichert wurde (`SupplPrice`). Er ist **nicht vergleichbar** mit anderen Rohertrags-Reports in Pixi.\n- `GrossProfit_Netto` ist `NULL` bei Aufträgen ohne Auftragspositionen.\n- Aufträge ohne passende Adresse oder Währung werden wegen der Inner Joins nicht geliefert.\n- Der Datumsvergleich erfolgt per `BETWEEN` auf einem `datetime`-Wert. Ein `OrderDateTo` ohne Uhrzeit (z. B. `2024-03-31`) bedeutet Mitternacht. Spätere Aufträge dieses Tages fehlen dann. Stattdessen den Folgetag oder die Uhrzeit `23:59:59` übergeben.\n- Da absteigend sortiert und per `RowCount` abgeschnitten wird, eignet sich `OrderNrStart` nicht als Cursor zum Vorwärtsblättern: Es werden immer die höchsten passenden Auftragsnummern geliefert. Passen mehr als `RowCount` Aufträge, fehlen die älteren.\n- `RowCount` wird per `SET ROWCOUNT` angewendet. Der Wert `0` hebt die Begrenzung auf.\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- Der Aufruf liest nur Daten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportOrderOverview"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine Übersicht der Aufträge mit Rechnungsadresse, Auftragssummen, Netto-Rohertrag und Währung, optional gefiltert nach Auftragsdatum und Auftragsnummer.\n\nLiefert eine Zeile pro Auftrag aus `OrderHeader`, verknüpft mit der zugehörigen Adresse (`AddrRef` = `AddrKey`) und der Auftragswährung.\n\n**Filter**\n- **Datumsbereich:** Ist `OrderDateFrom` gesetzt, werden nur Aufträge geliefert, deren `OrderDate` zwischen `OrderDateFrom` und `OrderDateTo` liegt (einschließlich). Ist `OrderDateTo` leer, wird das aktuelle Datum mit Uhrzeit verwendet. Ist `OrderDateFrom` leer, wird nicht nach Datum gefiltert, auch wenn `OrderDateTo` gesetzt ist.\n- **Auftragsnummer:** Ist `OrderNrStart` gesetzt, werden nur Aufträge mit `OrderNr` >= `OrderNrStart` geliefert.\n- Beide Filter werden mit UND verknüpft.\n\n**Zeilenlimit und Sortierung**\n- Die Anzahl der Zeilen wird auf `RowCount` begrenzt (Standard 1000).\n- Sortiert wird absteigend nach `OrderNr`, die neuesten Aufträge (höchste Auftragsnummern) stehen also zuerst.\n\n**Berechneter Wert**\n- `GrossProfit_Netto` ist die Summe von `Qty * (Price_Net - SupplPrice)` über alle Auftragspositionen des Auftrags.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderDateFrom` | datetime | Nein | Beginn des Auftragsdatumsbereichs (einschließlich). Bei `NULL` wird nicht nach Datum gefiltert. |\n| `OrderDateTo` | datetime | Nein | Ende des Auftragsdatumsbereichs (einschließlich). Bei `NULL` und gesetztem `OrderDateFrom` wird das aktuelle Datum mit Uhrzeit verwendet. Wird ignoriert, wenn `OrderDateFrom` `NULL` ist. |\n| `OrderNrStart` | int | Nein | Niedrigste zu liefernde Auftragsnummer (`OrderNr` >= Wert). Bei `NULL` wird nicht nach Auftragsnummer gefiltert. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. `0` bedeutet keine Begrenzung. |\n\n- Laut Code-Kommentar wird der Rohertrag aus dem Standard-Lieferantenpreis berechnet, der zum Zeitpunkt der Bestellung an der Auftragsposition gespeichert wurde (`SupplPrice`). Er ist **nicht vergleichbar** mit anderen Rohertrags-Reports in Pixi.\n- `GrossProfit_Netto` ist `NULL` bei Aufträgen ohne Auftragspositionen.\n- Aufträge ohne passende Adresse oder Währung werden wegen der Inner Joins nicht geliefert.\n- Der Datumsvergleich erfolgt per `BETWEEN` auf einem `datetime`-Wert. Ein `OrderDateTo` ohne Uhrzeit (z. B. `2024-03-31`) bedeutet Mitternacht. Spätere Aufträge dieses Tages fehlen dann. Stattdessen den Folgetag oder die Uhrzeit `23:59:59` übergeben.\n- Da absteigend sortiert und per `RowCount` abgeschnitten wird, eignet sich `OrderNrStart` nicht als Cursor zum Vorwärtsblättern: Es werden immer die höchsten passenden Auftragsnummern geliefert. Passen mehr als `RowCount` Aufträge, fehlen die älteren.\n- `RowCount` wird per `SET ROWCOUNT` angewendet. Der Wert `0` hebt die Begrenzung auf.\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- Der Aufruf liest nur Daten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportOrderOverview"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 150231\n Herr\n Max Mustermann\n \n Hauptstraße 12\n München\n 80331\n DE\n max@example.com\n \n \n \n VK\n AUF\n 119.90\n 0.00\n 4.90\n 0.00\n 124.80\n 38.45\n 2024-03-15T10:22:31\n SHOP1\n EUR\n \n"
}
]
},
{
"name": "pixiReportOrdersOnPicklist",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Anzahl der verschiedenen Aufträge, deren Auftragspositionen aktuell auf einer aktiven (nicht abgelaufenen) Pickliste stehen, optional je Shop.\n\nZählt, wie viele Aufträge sich aktuell auf einer Pickliste befinden.\n\n- Eine Auftragsposition zählt, wenn ihr `orderLineKey` von einer Picklistenposition (`PLItem.PLIorderlineRef`) mit `Expired = 0` referenziert wird.\n- Ergebnis ist die Anzahl der **verschiedenen** Auftragsnummern (`ordernr`) dieser Positionen; ein Auftrag mit mehreren Positionen auf Picklisten zählt nur einmal.\n- Ist `ShopID` leer oder `NULL`, werden alle Shops berücksichtigt. Andernfalls werden nur Auftragspositionen gezählt, deren `OrdShopId` gleich `ShopID` ist.\n\nDer Aufruf liefert eine Zeile mit der einzigen Spalte `NrOfOrders`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | Nein | Shop-ID als Filter. Leer oder NULL zählt Aufträge aller Shops. |\n\n- Beide Tabellen werden mit `NOLOCK` gelesen; die Zahl kann nicht festgeschriebene Änderungen enthalten und ist als Dashboard-Kennzahl gedacht.\n- Der Kopfkommentar erwähnt Output-Parameter, die Prozedur deklariert jedoch keine; der Wert wird nur als Ergebnismenge zurückgegeben.\n- Der Shop-Filter wird auf `OrdShopId` der Auftragsposition angewendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportOrdersOnPicklist"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Anzahl der verschiedenen Aufträge, deren Auftragspositionen aktuell auf einer aktiven (nicht abgelaufenen) Pickliste stehen, optional je Shop.\n\nZählt, wie viele Aufträge sich aktuell auf einer Pickliste befinden.\n\n- Eine Auftragsposition zählt, wenn ihr `orderLineKey` von einer Picklistenposition (`PLItem.PLIorderlineRef`) mit `Expired = 0` referenziert wird.\n- Ergebnis ist die Anzahl der **verschiedenen** Auftragsnummern (`ordernr`) dieser Positionen; ein Auftrag mit mehreren Positionen auf Picklisten zählt nur einmal.\n- Ist `ShopID` leer oder `NULL`, werden alle Shops berücksichtigt. Andernfalls werden nur Auftragspositionen gezählt, deren `OrdShopId` gleich `ShopID` ist.\n\nDer Aufruf liefert eine Zeile mit der einzigen Spalte `NrOfOrders`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | Nein | Shop-ID als Filter. Leer oder NULL zählt Aufträge aller Shops. |\n\n- Beide Tabellen werden mit `NOLOCK` gelesen; die Zahl kann nicht festgeschriebene Änderungen enthalten und ist als Dashboard-Kennzahl gedacht.\n- Der Kopfkommentar erwähnt Output-Parameter, die Prozedur deklariert jedoch keine; der Wert wird nur als Ergebnismenge zurückgegeben.\n- Der Shop-Filter wird auf `OrdShopId` der Auftragsposition angewendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportOrdersOnPicklist"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 42\n \n"
}
]
},
{
"name": "pixiReportReceivedOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Anzahl der in einem Zeitraum angelegten Aufträge (Standard: heute ab 0:00 bis jetzt), optional nach Shop gefiltert und nach Lager gruppiert.\n\nDashboard-Report, der eingegangene Aufträge anhand ihres Anlagedatums (`OrderHeader.CreateDate`) zählt.\n\n**Zeitraum**\n- `FromTime` ist standardmäßig der Beginn des aktuellen Tages (0:00).\n- `UntilTime` ist standardmäßig das aktuelle Datum mit Uhrzeit.\n- Beide Grenzen sind inklusive.\n\n**Shop-Filter**\n- Ist `ShopID` gesetzt, werden nur Aufträge gezählt, die mindestens eine Auftragsposition mit `OrdShopID` = `ShopID` haben. Leerer String oder NULL bedeutet alle Shops.\n\n**Modus abhängig von `PerLocation`**\n- `0` (Standard, auch bei NULL): zählt alle Aufträge im Zeitraum, die mindestens eine Auftragsposition haben (passend zum Shop-Filter). Die Anzahl wird als eine Zeile mit der Spalte `ReceivedOrders` geliefert und zusätzlich in den Output-Parameter `ReceivedOrders` geschrieben.\n- `1`: verknüpft Aufträge mit ihren Auftragspositionen und liefert je `LocationID` der Positionen eine Zeile mit der Anzahl unterschiedlicher Aufträge pro Lager. Es wird keine Sortierung angewendet.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromTime` | datetime | Nein | Beginn des Zeitraums (inklusive) für das Anlagedatum des Auftrags. Standard: heute 0:00. |\n| `UntilTime` | datetime | Nein | Ende des Zeitraums (inklusive). Standard: aktuelles Datum mit Uhrzeit. |\n| `ShopID` | varchar(3) | Nein | Optionaler Shop-Filter auf `Orderlines.OrdShopID`. Leer oder NULL zählt Aufträge aller Shops. |\n| `ReceivedOrders` | int | Nein | Ausgabe: Anzahl eingegangener Aufträge. Wird nur bei `PerLocation` = 0 gesetzt. |\n| `MinutesSinceRefresh` | int | Nein | Output-Parameter, der von der Prozedur nie gesetzt wird; immer NULL. |\n| `PerLocation` | bit | Nein | Wählt den Ausgabemodus: Gesamtanzahl oder Anzahl pro Lager. NULL wird wie 0 behandelt. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; die Zahlen können daher nicht festgeschriebene Daten enthalten.\n- Der Output-Parameter `MinutesSinceRefresh` wird von der Prozedur nie gesetzt und liefert immer NULL.\n- Im Modus pro Lager wird der Output-Parameter `ReceivedOrders` nicht gesetzt. Ein Auftrag mit Positionen in mehreren Lagern wird je Lager einmal gezählt, die Summe aller Zeilen kann daher die Gesamtzahl aus Modus `0` übersteigen.\n- Aufträge ohne Auftragspositionen werden nie gezählt.\n- Wegen `NULLIF(..., '')` auf Datumswerten wird `1900-01-01 00:00:00` für `FromTime` oder `UntilTime` wie NULL behandelt und durch den Standardwert ersetzt.\n- Der Parameter `PerLocation` trägt im Code den Kommentar \"old way\".\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportReceivedOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Anzahl der in einem Zeitraum angelegten Aufträge (Standard: heute ab 0:00 bis jetzt), optional nach Shop gefiltert und nach Lager gruppiert.\n\nDashboard-Report, der eingegangene Aufträge anhand ihres Anlagedatums (`OrderHeader.CreateDate`) zählt.\n\n**Zeitraum**\n- `FromTime` ist standardmäßig der Beginn des aktuellen Tages (0:00).\n- `UntilTime` ist standardmäßig das aktuelle Datum mit Uhrzeit.\n- Beide Grenzen sind inklusive.\n\n**Shop-Filter**\n- Ist `ShopID` gesetzt, werden nur Aufträge gezählt, die mindestens eine Auftragsposition mit `OrdShopID` = `ShopID` haben. Leerer String oder NULL bedeutet alle Shops.\n\n**Modus abhängig von `PerLocation`**\n- `0` (Standard, auch bei NULL): zählt alle Aufträge im Zeitraum, die mindestens eine Auftragsposition haben (passend zum Shop-Filter). Die Anzahl wird als eine Zeile mit der Spalte `ReceivedOrders` geliefert und zusätzlich in den Output-Parameter `ReceivedOrders` geschrieben.\n- `1`: verknüpft Aufträge mit ihren Auftragspositionen und liefert je `LocationID` der Positionen eine Zeile mit der Anzahl unterschiedlicher Aufträge pro Lager. Es wird keine Sortierung angewendet.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromTime` | datetime | Nein | Beginn des Zeitraums (inklusive) für das Anlagedatum des Auftrags. Standard: heute 0:00. |\n| `UntilTime` | datetime | Nein | Ende des Zeitraums (inklusive). Standard: aktuelles Datum mit Uhrzeit. |\n| `ShopID` | varchar(3) | Nein | Optionaler Shop-Filter auf `Orderlines.OrdShopID`. Leer oder NULL zählt Aufträge aller Shops. |\n| `ReceivedOrders` | int | Nein | Ausgabe: Anzahl eingegangener Aufträge. Wird nur bei `PerLocation` = 0 gesetzt. |\n| `MinutesSinceRefresh` | int | Nein | Output-Parameter, der von der Prozedur nie gesetzt wird; immer NULL. |\n| `PerLocation` | bit | Nein | Wählt den Ausgabemodus: Gesamtanzahl oder Anzahl pro Lager. NULL wird wie 0 behandelt. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; die Zahlen können daher nicht festgeschriebene Daten enthalten.\n- Der Output-Parameter `MinutesSinceRefresh` wird von der Prozedur nie gesetzt und liefert immer NULL.\n- Im Modus pro Lager wird der Output-Parameter `ReceivedOrders` nicht gesetzt. Ein Auftrag mit Positionen in mehreren Lagern wird je Lager einmal gezählt, die Summe aller Zeilen kann daher die Gesamtzahl aus Modus `0` übersteigen.\n- Aufträge ohne Auftragspositionen werden nie gezählt.\n- Wegen `NULLIF(..., '')` auf Datumswerten wird `1900-01-01 00:00:00` für `FromTime` oder `UntilTime` wie NULL behandelt und durch den Standardwert ersetzt.\n- Der Parameter `PerLocation` trägt im Code den Kommentar \"old way\".\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportReceivedOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 127\n \n"
}
]
},
{
"name": "pixiReportReturnsCount",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Gesamtmenge zurückgegebener Artikel (negative Rechnungspositionen) für einen Stichtag, den Vortag, den laufenden Monat bis zum Stichtag und den Vormonat.\n\nBerechnet vier Retourenkennzahlen für ein Dashboard. Als Retoure gilt eine Rechnungsposition mit negativer Menge (`ItemQty < 0`). Der Wert ist die Summe der absoluten Mengen (`SUM(ABS(ItemQty))`), nicht die Anzahl der Belege.\n\nAblauf:\n\n- Der Stichtag ist `@EndDate`. Ist der Wert `NULL`, wird das aktuelle Datum verwendet. Die Uhrzeit wird auf das Tagesende (23:59:59.997) gesetzt.\n- Aus dem Stichtag werden vier Zeiträume abgeleitet und mit dem Rechnungsdatum (`InvDate`) verglichen:\n - **Stichtag**: Beginn bis Ende des Stichtags.\n - **Vortag**: der vollständige Kalendertag vor dem Stichtag.\n - **Laufender Monat**: vom Ersten des Stichtagsmonats bis zum Ende des Stichtags.\n - **Vormonat**: der vollständige Kalendermonat vor dem Stichtagsmonat.\n- Rechnungspositionen werden mit der Rechnung und dem Kunden der Rechnung verknüpft. Ist `@ShopID` gefüllt, zählen nur Kunden, deren `CustomerOf` gleich `@ShopID` ist. Ist der Wert leer oder `NULL`, werden alle Shops berücksichtigt.\n\nDer Aufruf liefert eine Zeile mit den vier Werten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | Nein | Wird von der Prozedur nicht verwendet und hat keinen Einfluss auf das Ergebnis. |\n| `EndDate` | datetime | Nein | Stichtag, aus dem alle vier Zeiträume abgeleitet werden. Die Uhrzeit wird ignoriert und auf das Tagesende gesetzt. Bei `NULL` wird das aktuelle Datum verwendet. |\n| `ShopID` | varchar(3) | Nein | Optionaler Shop-Filter, verglichen mit `Customers.CustomerOf` des Rechnungskunden. Leer oder `NULL` berücksichtigt alle Shops. |\n\n- `@StartDate` ist deklariert, wird aber **nicht verwendet**. Alle Zeiträume ergeben sich ausschließlich aus `@EndDate`.\n- Alle Lesezugriffe verwenden `NOLOCK`. Die Werte können nicht festgeschriebene Daten enthalten.\n- Retouren werden aus Rechnungspositionen ermittelt (Gutschriftpositionen mit negativer Menge), nicht aus einer eigenen Retourentabelle.\n- Die Werte werden in `varchar(10)`-Variablen gespeichert und als Zeichenketten geliefert. Je nach Datentyp von `ItemQty` können sie Nachkommastellen enthalten.\n- Gibt es in einem Zeitraum keine passenden Positionen, ist der Wert `NULL`. In der SOAP-Antwort fehlt das Element dann in der Regel.\n- Tritt bei der Berechnung ein Fehler auf, endet die Prozedur mit Rückgabewert `-1` und liefert **keine** Ergebnismenge. Eine mögliche Ursache ist eine Summe, die nicht in `varchar(10)` passt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportReturnsCount"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Gesamtmenge zurückgegebener Artikel (negative Rechnungspositionen) für einen Stichtag, den Vortag, den laufenden Monat bis zum Stichtag und den Vormonat.\n\nBerechnet vier Retourenkennzahlen für ein Dashboard. Als Retoure gilt eine Rechnungsposition mit negativer Menge (`ItemQty < 0`). Der Wert ist die Summe der absoluten Mengen (`SUM(ABS(ItemQty))`), nicht die Anzahl der Belege.\n\nAblauf:\n\n- Der Stichtag ist `@EndDate`. Ist der Wert `NULL`, wird das aktuelle Datum verwendet. Die Uhrzeit wird auf das Tagesende (23:59:59.997) gesetzt.\n- Aus dem Stichtag werden vier Zeiträume abgeleitet und mit dem Rechnungsdatum (`InvDate`) verglichen:\n - **Stichtag**: Beginn bis Ende des Stichtags.\n - **Vortag**: der vollständige Kalendertag vor dem Stichtag.\n - **Laufender Monat**: vom Ersten des Stichtagsmonats bis zum Ende des Stichtags.\n - **Vormonat**: der vollständige Kalendermonat vor dem Stichtagsmonat.\n- Rechnungspositionen werden mit der Rechnung und dem Kunden der Rechnung verknüpft. Ist `@ShopID` gefüllt, zählen nur Kunden, deren `CustomerOf` gleich `@ShopID` ist. Ist der Wert leer oder `NULL`, werden alle Shops berücksichtigt.\n\nDer Aufruf liefert eine Zeile mit den vier Werten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | Nein | Wird von der Prozedur nicht verwendet und hat keinen Einfluss auf das Ergebnis. |\n| `EndDate` | datetime | Nein | Stichtag, aus dem alle vier Zeiträume abgeleitet werden. Die Uhrzeit wird ignoriert und auf das Tagesende gesetzt. Bei `NULL` wird das aktuelle Datum verwendet. |\n| `ShopID` | varchar(3) | Nein | Optionaler Shop-Filter, verglichen mit `Customers.CustomerOf` des Rechnungskunden. Leer oder `NULL` berücksichtigt alle Shops. |\n\n- `@StartDate` ist deklariert, wird aber **nicht verwendet**. Alle Zeiträume ergeben sich ausschließlich aus `@EndDate`.\n- Alle Lesezugriffe verwenden `NOLOCK`. Die Werte können nicht festgeschriebene Daten enthalten.\n- Retouren werden aus Rechnungspositionen ermittelt (Gutschriftpositionen mit negativer Menge), nicht aus einer eigenen Retourentabelle.\n- Die Werte werden in `varchar(10)`-Variablen gespeichert und als Zeichenketten geliefert. Je nach Datentyp von `ItemQty` können sie Nachkommastellen enthalten.\n- Gibt es in einem Zeitraum keine passenden Positionen, ist der Wert `NULL`. In der SOAP-Antwort fehlt das Element dann in der Regel.\n- Tritt bei der Berechnung ein Fehler auf, endet die Prozedur mit Rückgabewert `-1` und liefert **keine** Ergebnismenge. Eine mögliche Ursache ist eine Summe, die nicht in `varchar(10)` passt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportReturnsCount"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4\n 7\n 58\n 131\n \n"
}
]
},
{
"name": "pixiReportScanInPerTimeQuant",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Anzahl der Einscannungen (Auftragshistorie-Status `EIN`) je Zeitabschnitt einer wählbaren Länge in Stunden innerhalb eines Zeitraums, optional für einen Shop.\n\nErstellt eine Zeitreihe der Einscannungen für Dashboards.\n\n1. Standardwerte: Ist `startDateTime` NULL, wird der Beginn des aktuellen Tages (Mitternacht) verwendet; ist `endDateTime` NULL, das aktuelle Datum mit Uhrzeit; wird `timePeriod` explizit als NULL übergeben, wird `1` verwendet (der deklarierte Standard bei Weglassen des Parameters ist `2`).\n2. Der Zeitraum von `startDateTime` bis `endDateTime` wird in aufeinanderfolgende Abschnitte von `timePeriod` Stunden aufgeteilt (Bruchteile wie `0.5` für 30 Minuten sind möglich). Der letzte Abschnitt wird bei `endDateTime` abgeschnitten.\n3. Je Abschnitt werden die Einträge in `orderHistory` mit `status = 'EIN'` gezählt, deren `StatusChangeDate` zwischen Abschnittsbeginn und Abschnittsende liegt (beide Grenzen eingeschlossen).\n4. Ist `shopID` leer oder NULL, werden alle Shops gezählt, sonst nur Historieneinträge dieses Shops.\n5. Je Abschnitt wird eine Zeile in chronologischer Reihenfolge geliefert, auch Abschnitte mit Anzahl `0`.\n\nLiegt `startDateTime` nicht vor `endDateTime`, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `startDateTime` | datetime | Nein | Beginn des ausgewerteten Zeitraums. NULL bedeutet Beginn des aktuellen Tages (00:00). |\n| `endDateTime` | datetime | Nein | Ende des ausgewerteten Zeitraums. NULL bedeutet aktuelles Datum mit Uhrzeit. |\n| `timePeriod` | float | Nein | Länge eines Zeitabschnitts in Stunden; Bruchteile sind erlaubt. Explizites NULL wird als 1 behandelt. Muss größer als 0 sein. |\n| `shopID` | varchar(3) | Nein | Shop, dessen Einscannungen gezählt werden. Leer oder NULL zählt alle Shops. |\n\n- `orderHistory` wird mit `WITH (NOLOCK)` gelesen; die Zählung kann nicht festgeschriebene Daten enthalten.\n- Da `BETWEEN` beide Grenzen einschließt, wird ein Historieneintrag genau auf einer Abschnittsgrenze in zwei benachbarten Abschnitten gezählt.\n- `startTimePeriod` und `endTimePeriod` sind Zeichenketten aus `CONVERT(VARCHAR, …)` im Standardformat (z. B. `Jan 15 2024 8:00AM`); Sekunden fehlen und das Format hängt von der Serversprache ab. Die Werte sind entsprechend zu parsen oder die Abschnittszeiten clientseitig zu berechnen.\n- Die Spalte `shopID` gibt den übergebenen Parameter zurück und ist daher leer (bzw. NULL), wenn alle Shops gezählt werden.\n- Achtung: Ein `timePeriod` von `0` oder ein negativer Wert führt zu einer Endlosschleife; es ist immer ein positiver Wert zu übergeben.\n- Große Zeiträume mit kleinen Abschnitten führen je Abschnitt eine Zählabfrage aus und können langsam sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportScanInPerTimeQuant"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Anzahl der Einscannungen (Auftragshistorie-Status `EIN`) je Zeitabschnitt einer wählbaren Länge in Stunden innerhalb eines Zeitraums, optional für einen Shop.\n\nErstellt eine Zeitreihe der Einscannungen für Dashboards.\n\n1. Standardwerte: Ist `startDateTime` NULL, wird der Beginn des aktuellen Tages (Mitternacht) verwendet; ist `endDateTime` NULL, das aktuelle Datum mit Uhrzeit; wird `timePeriod` explizit als NULL übergeben, wird `1` verwendet (der deklarierte Standard bei Weglassen des Parameters ist `2`).\n2. Der Zeitraum von `startDateTime` bis `endDateTime` wird in aufeinanderfolgende Abschnitte von `timePeriod` Stunden aufgeteilt (Bruchteile wie `0.5` für 30 Minuten sind möglich). Der letzte Abschnitt wird bei `endDateTime` abgeschnitten.\n3. Je Abschnitt werden die Einträge in `orderHistory` mit `status = 'EIN'` gezählt, deren `StatusChangeDate` zwischen Abschnittsbeginn und Abschnittsende liegt (beide Grenzen eingeschlossen).\n4. Ist `shopID` leer oder NULL, werden alle Shops gezählt, sonst nur Historieneinträge dieses Shops.\n5. Je Abschnitt wird eine Zeile in chronologischer Reihenfolge geliefert, auch Abschnitte mit Anzahl `0`.\n\nLiegt `startDateTime` nicht vor `endDateTime`, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `startDateTime` | datetime | Nein | Beginn des ausgewerteten Zeitraums. NULL bedeutet Beginn des aktuellen Tages (00:00). |\n| `endDateTime` | datetime | Nein | Ende des ausgewerteten Zeitraums. NULL bedeutet aktuelles Datum mit Uhrzeit. |\n| `timePeriod` | float | Nein | Länge eines Zeitabschnitts in Stunden; Bruchteile sind erlaubt. Explizites NULL wird als 1 behandelt. Muss größer als 0 sein. |\n| `shopID` | varchar(3) | Nein | Shop, dessen Einscannungen gezählt werden. Leer oder NULL zählt alle Shops. |\n\n- `orderHistory` wird mit `WITH (NOLOCK)` gelesen; die Zählung kann nicht festgeschriebene Daten enthalten.\n- Da `BETWEEN` beide Grenzen einschließt, wird ein Historieneintrag genau auf einer Abschnittsgrenze in zwei benachbarten Abschnitten gezählt.\n- `startTimePeriod` und `endTimePeriod` sind Zeichenketten aus `CONVERT(VARCHAR, …)` im Standardformat (z. B. `Jan 15 2024 8:00AM`); Sekunden fehlen und das Format hängt von der Serversprache ab. Die Werte sind entsprechend zu parsen oder die Abschnittszeiten clientseitig zu berechnen.\n- Die Spalte `shopID` gibt den übergebenen Parameter zurück und ist daher leer (bzw. NULL), wenn alle Shops gezählt werden.\n- Achtung: Ein `timePeriod` von `0` oder ein negativer Wert führt zu einer Endlosschleife; es ist immer ein positiver Wert zu übergeben.\n- Große Zeiträume mit kleinen Abschnitten führen je Abschnitt eine Zählabfrage aus und können langsam sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportScanInPerTimeQuant"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n SHP\n 42\n Jan 15 2024 6:00AM\n Jan 15 2024 7:00AM\n \n \n SHP\n 57\n Jan 15 2024 7:00AM\n Jan 15 2024 8:00AM\n \n"
}
]
},
{
"name": "pixiReportShipOutPerTimeQuant",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Anzahl ausgescannter (versendeter) Rechnungen je Zeitabschnitt einstellbarer Länge in einem Zeitraum, optional für einen Shop.\n\nTeilt den Zeitraum von `startDateTime` bis `endDateTime` in aufeinanderfolgende Abschnitte von `timePeriod` Stunden. Für jeden Abschnitt werden die Rechnungen gezählt, deren `ScanOutdate` (Ausscan-Zeitpunkt beim Versand) in den Abschnitt fällt. Je Abschnitt wird eine Zeile geliefert.\n\n- `startDateTime` ist standardmäßig der Beginn des aktuellen Tages (00:00), `endDateTime` standardmäßig der aktuelle Zeitpunkt.\n- `timePeriod` ist die Abschnittslänge in Stunden und darf Nachkommastellen haben (z. B. `0.5` = 30 Minuten). Standard ist `2`. Wird ausdrücklich `NULL` übergeben, gilt `1` Stunde.\n- Der letzte Abschnitt endet bei `endDateTime` und kann kürzer als die übrigen sein.\n- `shopID` filtert auf den Shop, zu dem der Kunde der Rechnung gehört (`Customers.CustomerOf`). Ein Leerstring (Standard) zählt die Rechnungen aller Shops.\n- Jeder Abschnitt erzeugt eine Zeile, auch Abschnitte mit der Anzahl `0`.\n- Die Zeilen erscheinen in der Reihenfolge, in der die Abschnitte erzeugt wurden, also chronologisch. Die abschließende Abfrage hat allerdings kein explizites `ORDER BY`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `startDateTime` | datetime | Nein | Beginn des ausgewerteten Zeitraums. `NULL` bedeutet Beginn des aktuellen Tages (00:00). |\n| `endDateTime` | datetime | Nein | Ende des ausgewerteten Zeitraums. `NULL` bedeutet aktueller Zeitpunkt. |\n| `timePeriod` | float | Nein | Länge eines Zeitabschnitts in Stunden; Nachkommastellen sind erlaubt. Ein ausdrückliches `NULL` bedeutet 1 Stunde. Muss größer als 0 sein. |\n| `shopID` | varchar(3) | Nein | Shop-Kürzel, zu dem der Kunde der Rechnung gehören muss (`Customers.CustomerOf`). Ein Leerstring zählt alle Shops. |\n\n- Liest `Invoices` und `Customers` mit `NOLOCK`, die Zählungen können daher nicht festgeschriebene Daten enthalten.\n- Der Abschnittsfilter verwendet `BETWEEN`, beide Grenzen sind also eingeschlossen. Eine Rechnung, die genau auf einer Abschnittsgrenze ausgescannt wurde, wird in zwei benachbarten Abschnitten gezählt.\n- `startTimePeriod` und `endTimePeriod` sind Text im Standard-Datumsformat von SQL Server (z. B. `Jan 15 2024 2:00PM`). Sie sind minutengenau, Sekunden gehen verloren.\n- Die Beschriftung `endTimePeriod` des letzten Abschnitts wird nicht auf `endDateTime` gekürzt. Sie zeigt das volle rechnerische Abschnittsende, obwohl nur bis `endDateTime` gezählt wird.\n- Die Spalte `shopID` gibt den übergebenen Parameterwert zurück; bei Zählung aller Shops ist sie ein Leerstring.\n- Die Abschnittsgrenzen werden durch Addition von Tagesbruchteilen als `float` berechnet, bei sehr kleinen Abschnitten kann daher eine Rundungsabweichung entstehen.\n- Ein `timePeriod` von `0` oder ein negativer Wert führt zu einer Endlosschleife, weil der Abschnittsbeginn nie fortschreitet. Es sollte immer ein positiver Wert übergeben werden.\n- Je Abschnitt wird eine Abfrage ausgeführt, lange Zeiträume mit kurzen Abschnitten können daher langsam sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportShipOutPerTimeQuant"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Anzahl ausgescannter (versendeter) Rechnungen je Zeitabschnitt einstellbarer Länge in einem Zeitraum, optional für einen Shop.\n\nTeilt den Zeitraum von `startDateTime` bis `endDateTime` in aufeinanderfolgende Abschnitte von `timePeriod` Stunden. Für jeden Abschnitt werden die Rechnungen gezählt, deren `ScanOutdate` (Ausscan-Zeitpunkt beim Versand) in den Abschnitt fällt. Je Abschnitt wird eine Zeile geliefert.\n\n- `startDateTime` ist standardmäßig der Beginn des aktuellen Tages (00:00), `endDateTime` standardmäßig der aktuelle Zeitpunkt.\n- `timePeriod` ist die Abschnittslänge in Stunden und darf Nachkommastellen haben (z. B. `0.5` = 30 Minuten). Standard ist `2`. Wird ausdrücklich `NULL` übergeben, gilt `1` Stunde.\n- Der letzte Abschnitt endet bei `endDateTime` und kann kürzer als die übrigen sein.\n- `shopID` filtert auf den Shop, zu dem der Kunde der Rechnung gehört (`Customers.CustomerOf`). Ein Leerstring (Standard) zählt die Rechnungen aller Shops.\n- Jeder Abschnitt erzeugt eine Zeile, auch Abschnitte mit der Anzahl `0`.\n- Die Zeilen erscheinen in der Reihenfolge, in der die Abschnitte erzeugt wurden, also chronologisch. Die abschließende Abfrage hat allerdings kein explizites `ORDER BY`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `startDateTime` | datetime | Nein | Beginn des ausgewerteten Zeitraums. `NULL` bedeutet Beginn des aktuellen Tages (00:00). |\n| `endDateTime` | datetime | Nein | Ende des ausgewerteten Zeitraums. `NULL` bedeutet aktueller Zeitpunkt. |\n| `timePeriod` | float | Nein | Länge eines Zeitabschnitts in Stunden; Nachkommastellen sind erlaubt. Ein ausdrückliches `NULL` bedeutet 1 Stunde. Muss größer als 0 sein. |\n| `shopID` | varchar(3) | Nein | Shop-Kürzel, zu dem der Kunde der Rechnung gehören muss (`Customers.CustomerOf`). Ein Leerstring zählt alle Shops. |\n\n- Liest `Invoices` und `Customers` mit `NOLOCK`, die Zählungen können daher nicht festgeschriebene Daten enthalten.\n- Der Abschnittsfilter verwendet `BETWEEN`, beide Grenzen sind also eingeschlossen. Eine Rechnung, die genau auf einer Abschnittsgrenze ausgescannt wurde, wird in zwei benachbarten Abschnitten gezählt.\n- `startTimePeriod` und `endTimePeriod` sind Text im Standard-Datumsformat von SQL Server (z. B. `Jan 15 2024 2:00PM`). Sie sind minutengenau, Sekunden gehen verloren.\n- Die Beschriftung `endTimePeriod` des letzten Abschnitts wird nicht auf `endDateTime` gekürzt. Sie zeigt das volle rechnerische Abschnittsende, obwohl nur bis `endDateTime` gezählt wird.\n- Die Spalte `shopID` gibt den übergebenen Parameterwert zurück; bei Zählung aller Shops ist sie ein Leerstring.\n- Die Abschnittsgrenzen werden durch Addition von Tagesbruchteilen als `float` berechnet, bei sehr kleinen Abschnitten kann daher eine Rundungsabweichung entstehen.\n- Ein `timePeriod` von `0` oder ein negativer Wert führt zu einer Endlosschleife, weil der Abschnittsbeginn nie fortschreitet. Es sollte immer ein positiver Wert übergeben werden.\n- Je Abschnitt wird eine Abfrage ausgeführt, lange Zeiträume mit kurzen Abschnitten können daher langsam sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportShipOutPerTimeQuant"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n ABC\n 42\n Jan 15 2024 12:00AM\n Jan 15 2024 1:00AM\n \n \n ABC\n 17\n Jan 15 2024 1:00AM\n Jan 15 2024 2:00AM\n \n"
}
]
},
{
"name": "pixiReport_StockMovementsForItemsWithBnBbd",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Lagerbewegungen von Artikeln mit Chargen- bzw. MHD-Verwaltung, gefiltert nach Zeitraum, Bewegungsart, Benutzer, Lager, Tag, Kategorie und Lieferant.\n\nWrapper um die interne Report-Prozedur `Report_StockMovementsForItemsWithBnBbd`. Geliefert werden Einträge des Lagerbewegungsprotokolls (`InvBinItemLog`) für Artikel mit dem Artikel-Tag `-6` oder `-7` (Charge / MHD).\n\n**Parameterbehandlung**\n- Leere Werte (sowie `0` bei den Integer-Parametern) werden als `NULL` behandelt, also als „kein Filter“.\n- Fehlt `DateFrom`, gilt der Beginn des aktuellen Tages. Fehlt `DateTo`, gilt das Ende des aktuellen Tages. Die Uhrzeit beider Werte wird ignoriert: `DateFrom` wird auf 00:00:00 und `DateTo` auf 23:59:59.997 des jeweiligen Tages gesetzt.\n\n**Parameterprüfungen** (bei einem Fehler wird eine Zeile mit `Status`/`Message` geliefert und der Aufruf beendet)\n1. `LocID` muss in `Location` existieren.\n2. `ItemTag` muss, falls angegeben, `-6` oder `-7` sein.\n3. `UserName` muss als Teilstring von `UpdateEmp` in mindestens einem Protokolleintrag vorkommen.\n4. `SMTKey` muss in `StockMovementTypes` existieren.\n5. `Category` muss in `TontrArten` existieren.\n\n`SupplNr` wird nicht geprüft.\n\n**Filter**\n- Bewegungsdatum (`UpdateDate`) zwischen `DateFrom` und `DateTo`. Dieser Filter ist immer aktiv.\n- `SMTKey`: Lagerbewegungsart des Protokolleintrags.\n- `UserName`: Teilstring-Suche (`LIKE '%…%'`) auf den Benutzer des Eintrags.\n- `LocID`: Lager des aktuellen Lagerplatzes (`InvBin.BinLocID`).\n- `ItemTag`: nur Artikel mit diesem Tag (`-6` oder `-7`).\n- `Category`: `ConfigType` des Artikels.\n- `SupplNr`: Lieferant aus der zum Bewegungsdatum gültigen, jüngsten Lieferanteninformation.\n\n**Ausgabe**\nEine Zeile je Bewegung mit Artikel, Lagerplatz, bewegter Menge, Charge, MHD, Bewegungsart mit übersetztem Namen, Benutzer, historischem Lieferantenpreis und Datenbankwährung. Der Report sortiert die Zeilen aufsteigend nach Bewegungsdatum.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (Bewegungsdatum). Die Uhrzeit wird ignoriert, der Tag beginnt um 00:00:00. Standard: Beginn des aktuellen Tages. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (Bewegungsdatum). Die Uhrzeit wird ignoriert, der ganze Tag bis 23:59:59.997 ist eingeschlossen. Standard: Ende des aktuellen Tages. |\n| `SMTKey` | int | Nein | Schlüssel der Lagerbewegungsart (`StockMovementTypes.SMTKey`). Er muss existieren. `NULL` oder `0` bedeutet alle Bewegungsarten. |\n| `UserName` | varchar(100) | Nein | Teilstring des im Bewegungsprotokoll gespeicherten Benutzernamens (`UpdateEmp`). Mindestens ein Protokolleintrag muss passen. |\n| `LocID` | varchar(3) | Nein | Lager-ID (`Location.LocID`). Sie muss existieren. Filtert auf das Lager des aktuellen Lagerplatzes. |\n| `ItemTag` | int | Nein | Schränkt auf Artikel mit diesem Tag ein. Nur `-6` und `-7` sind zulässig. `NULL` oder `0` bedeutet beide. |\n| `Category` | varchar(4) | Nein | Artikelkategorie (`TontrArten.TontrArt`). Sie muss existieren und wird mit `Items.ConfigType` verglichen. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Sie wird mit dem Lieferanten der zum Bewegungsdatum gültigen, jüngsten Lieferanteninformation verglichen. Sie wird nicht validiert. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten im Ergebnis erscheinen.\n- Der Report selbst sortiert nach Bewegungsdatum. Das abschließende `SELECT` aus der temporären Tabelle enthält kein `ORDER BY`, die Reihenfolge ist daher nicht streng garantiert.\n- Da leere Werte auf `NULL` abgebildet werden, gelten `SMTKey` bzw. `ItemTag` mit dem Wert `0` sowie das Datum `1900-01-01` als „nicht gesetzt“.\n- `Stock` ist `SUM(Items.Quantity)`. Das ist der Gesamtbestand des Artikels, nicht der Bestand auf dem Lagerplatz. Fallen mehrere verknüpfte Zeilen in eine Gruppe, kann der Wert ein Vielfaches dieses Bestands sein.\n- `BinName` enthält den aktuellen Lagerplatznamen. Bei gelöschten Lagerplätzen enthält er den historischen Namen gefolgt von ` Deleted`. Gelöschte Lagerplätze fallen bei gesetztem `LocID` aus dem Ergebnis, da der Lagerfilter nur den aktuellen Lagerplatz verwendet.\n- Hat eine Bewegung weder einen aktuellen noch einen gelöschten Lagerplatzeintrag, ist `BinName` leer und das Einfügen in die Ergebnistabelle schlägt fehl. Dann wird die Zeile „Unexpected error“ geliefert.\n- `SMTName` ist die Übersetzung mit `LanguageID = 2`.\n- `UserName` ist der Teil von `UpdateEmp` vor dem ersten `/`.\n- Die Prüfung für `UserName` (bzw. `LocID`) schlägt auch fehl, wenn `InvBinItemLog` (bzw. `Location`) leer ist, selbst wenn kein Wert übergeben wurde.\n- Die Lieferantendaten stammen aus der Funktion `fPixi_GetLatestSupplierInfo`. Deren Definition liegt nicht vor, die genaue Auswahllogik ist hier daher nicht dokumentiert.\n- Der Report läuft als dynamisches SQL über `sp_executesql`.\n- Der Report berechnet zusätzlich die Spalten `ParamDateFrom` … `ParamSupplier`, diese werden aber nicht an den Aufrufer geliefert.\n- Ein Code-Kommentar nennt die Tags `-6` und `-7` zusammen als „BN & BBD“.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_StockMovementsForItemsWithBnBbd"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Lagerbewegungen von Artikeln mit Chargen- bzw. MHD-Verwaltung, gefiltert nach Zeitraum, Bewegungsart, Benutzer, Lager, Tag, Kategorie und Lieferant.\n\nWrapper um die interne Report-Prozedur `Report_StockMovementsForItemsWithBnBbd`. Geliefert werden Einträge des Lagerbewegungsprotokolls (`InvBinItemLog`) für Artikel mit dem Artikel-Tag `-6` oder `-7` (Charge / MHD).\n\n**Parameterbehandlung**\n- Leere Werte (sowie `0` bei den Integer-Parametern) werden als `NULL` behandelt, also als „kein Filter“.\n- Fehlt `DateFrom`, gilt der Beginn des aktuellen Tages. Fehlt `DateTo`, gilt das Ende des aktuellen Tages. Die Uhrzeit beider Werte wird ignoriert: `DateFrom` wird auf 00:00:00 und `DateTo` auf 23:59:59.997 des jeweiligen Tages gesetzt.\n\n**Parameterprüfungen** (bei einem Fehler wird eine Zeile mit `Status`/`Message` geliefert und der Aufruf beendet)\n1. `LocID` muss in `Location` existieren.\n2. `ItemTag` muss, falls angegeben, `-6` oder `-7` sein.\n3. `UserName` muss als Teilstring von `UpdateEmp` in mindestens einem Protokolleintrag vorkommen.\n4. `SMTKey` muss in `StockMovementTypes` existieren.\n5. `Category` muss in `TontrArten` existieren.\n\n`SupplNr` wird nicht geprüft.\n\n**Filter**\n- Bewegungsdatum (`UpdateDate`) zwischen `DateFrom` und `DateTo`. Dieser Filter ist immer aktiv.\n- `SMTKey`: Lagerbewegungsart des Protokolleintrags.\n- `UserName`: Teilstring-Suche (`LIKE '%…%'`) auf den Benutzer des Eintrags.\n- `LocID`: Lager des aktuellen Lagerplatzes (`InvBin.BinLocID`).\n- `ItemTag`: nur Artikel mit diesem Tag (`-6` oder `-7`).\n- `Category`: `ConfigType` des Artikels.\n- `SupplNr`: Lieferant aus der zum Bewegungsdatum gültigen, jüngsten Lieferanteninformation.\n\n**Ausgabe**\nEine Zeile je Bewegung mit Artikel, Lagerplatz, bewegter Menge, Charge, MHD, Bewegungsart mit übersetztem Namen, Benutzer, historischem Lieferantenpreis und Datenbankwährung. Der Report sortiert die Zeilen aufsteigend nach Bewegungsdatum.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (Bewegungsdatum). Die Uhrzeit wird ignoriert, der Tag beginnt um 00:00:00. Standard: Beginn des aktuellen Tages. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (Bewegungsdatum). Die Uhrzeit wird ignoriert, der ganze Tag bis 23:59:59.997 ist eingeschlossen. Standard: Ende des aktuellen Tages. |\n| `SMTKey` | int | Nein | Schlüssel der Lagerbewegungsart (`StockMovementTypes.SMTKey`). Er muss existieren. `NULL` oder `0` bedeutet alle Bewegungsarten. |\n| `UserName` | varchar(100) | Nein | Teilstring des im Bewegungsprotokoll gespeicherten Benutzernamens (`UpdateEmp`). Mindestens ein Protokolleintrag muss passen. |\n| `LocID` | varchar(3) | Nein | Lager-ID (`Location.LocID`). Sie muss existieren. Filtert auf das Lager des aktuellen Lagerplatzes. |\n| `ItemTag` | int | Nein | Schränkt auf Artikel mit diesem Tag ein. Nur `-6` und `-7` sind zulässig. `NULL` oder `0` bedeutet beide. |\n| `Category` | varchar(4) | Nein | Artikelkategorie (`TontrArten.TontrArt`). Sie muss existieren und wird mit `Items.ConfigType` verglichen. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Sie wird mit dem Lieferanten der zum Bewegungsdatum gültigen, jüngsten Lieferanteninformation verglichen. Sie wird nicht validiert. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten im Ergebnis erscheinen.\n- Der Report selbst sortiert nach Bewegungsdatum. Das abschließende `SELECT` aus der temporären Tabelle enthält kein `ORDER BY`, die Reihenfolge ist daher nicht streng garantiert.\n- Da leere Werte auf `NULL` abgebildet werden, gelten `SMTKey` bzw. `ItemTag` mit dem Wert `0` sowie das Datum `1900-01-01` als „nicht gesetzt“.\n- `Stock` ist `SUM(Items.Quantity)`. Das ist der Gesamtbestand des Artikels, nicht der Bestand auf dem Lagerplatz. Fallen mehrere verknüpfte Zeilen in eine Gruppe, kann der Wert ein Vielfaches dieses Bestands sein.\n- `BinName` enthält den aktuellen Lagerplatznamen. Bei gelöschten Lagerplätzen enthält er den historischen Namen gefolgt von ` Deleted`. Gelöschte Lagerplätze fallen bei gesetztem `LocID` aus dem Ergebnis, da der Lagerfilter nur den aktuellen Lagerplatz verwendet.\n- Hat eine Bewegung weder einen aktuellen noch einen gelöschten Lagerplatzeintrag, ist `BinName` leer und das Einfügen in die Ergebnistabelle schlägt fehl. Dann wird die Zeile „Unexpected error“ geliefert.\n- `SMTName` ist die Übersetzung mit `LanguageID = 2`.\n- `UserName` ist der Teil von `UpdateEmp` vor dem ersten `/`.\n- Die Prüfung für `UserName` (bzw. `LocID`) schlägt auch fehl, wenn `InvBinItemLog` (bzw. `Location`) leer ist, selbst wenn kein Wert übergeben wurde.\n- Die Lieferantendaten stammen aus der Funktion `fPixi_GetLatestSupplierInfo`. Deren Definition liegt nicht vor, die genaue Auswahllogik ist hier daher nicht dokumentiert.\n- Der Report läuft als dynamisches SQL über `sp_executesql`.\n- Der Report berechnet zusätzlich die Spalten `ParamDateFrom` … `ParamSupplier`, diese werden aber nicht an den Aufrufer geliefert.\n- Ein Code-Kommentar nennt die Tags `-6` und `-7` zusammen als „BN & BBD“.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_StockMovementsForItemsWithBnBbd"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4012345678901\n Bio Honig 500g\n A-01-03\n 120\n -5\n -17.5000\n 2024-03-12T10:15:22\n OUT\n Ausbuchung MHD abgelaufen\n CH2023-117\n 2024-03-10T00:00:00\n mmueller\n EUR\n L001\n 4711\n HON-500\n 100234\n \n"
}
]
},
{
"name": "pixiReportStockRange",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert einen seitenweise abrufbaren Reichweitenbericht je Artikel mit Bestand, Verkäufen im Zeitraum, Verkäufen pro Tag und der daraus berechneten Reichweite in Tagen.\n\nBerechnet, wie viele Tage der aktuelle Bestand jedes Artikels auf Basis der bisherigen Verkäufe reicht, und liefert die Artikel, deren Reichweite mindestens `MinStockRange` Tage beträgt. Typischer Einsatz ist die Suche nach Ladenhütern oder Überbeständen.\n\n**Berechnung**\n\n1. Für jeden Artikel mit mindestens einem Bestandsdatensatz (`InvBinItem` verknüpft mit `InvBin`) wird ermittelt:\n - `Stock`: Summe von `BinItemQty` über alle Lagerplätze des Artikels.\n - `Sales`: Summe von `ItemQty` der Rechnungspositionen (`Invlines`) des Artikels, die in den letzten `SalesDaysBack` Kalendertagen angelegt wurden. Standardmäßig zählen nur Positionen mit positiver Menge. Mit `DeductReturns` = 1 werden alle Positionen gezählt, negative Positionen wie Gutschriften verringern also die Summe.\n - `LastStockInc`: Anzahl Tage seit dem jüngsten `UpdateDate` der Bestandsdatensätze des Artikels.\n2. `SalesPerDay` = `Sales` / `SalesDaysBack`.\n3. `StockRange` = `Stock` / `SalesPerDay` in Tagen. Ist `Sales` 0 oder kleiner, wird `StockRange` auf `9999` gesetzt.\n\n**Filter** (alle mit UND verknüpft)\n\n- `SupplNr`: nur Artikel dieses Lieferanten (`items.SupplNR`).\n- `PriceMin` / `PriceMax`: Grenzen für den Verkaufspreis (`items.Price`).\n- `LastStockIncDays`: nur Artikel, deren `LastStockInc` größer als dieser Wert ist.\n- `StockMin`: nur Artikel mit `Stock` >= diesem Wert (Standard 0, Artikel mit negativem Bestand fallen also heraus).\n- `MinStockRange`: nur Artikel mit `StockRange` >= diesem Wert.\n- `ExcludeInhouseEAN` = 1: Artikel, deren `EANUPC` mit `2` beginnt (interne EAN-Nummern), werden ausgeschlossen.\n\n**Sortierung und Paging**\n\nDie gefilterten Zeilen werden in `Row` nach `StockRange` absteigend, dann `ItemName` nummeriert. Zurückgegeben werden höchstens `RowCount` Zeilen mit `Row` > `StartRow` in derselben Reihenfolge. Für die nächste Seite wird die zuletzt erhaltene `Row` als `StartRow` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen (Seitengröße). 0 liefert alle Zeilen. |\n| `StartRow` | int | Nein | Es werden nur Zeilen mit `Row` größer als dieser Wert geliefert. NULL wird als 0 behandelt (erste Seite). |\n| `MinStockRange` | int | Nein | Mindestreichweite in Tagen; nur Artikel mit `StockRange` >= diesem Wert werden geliefert. NULL wird als 0 behandelt. |\n| `SalesDaysBack` | int | Nein | Länge des Verkaufszeitraums in Tagen, rückwärts ab jetzt gerechnet. Zugleich Divisor für `SalesPerDay`; darf nicht 0 sein. |\n| `LastStockIncDays` | int | Nein | Wenn gesetzt, nur Artikel, deren Bestandsdatensätze zuletzt vor mehr als dieser Anzahl Tage aktualisiert wurden (`LastStockInc` > Wert). |\n| `StockMin` | int | Nein | Mindestgesamtbestand; nur Artikel mit `Stock` >= diesem Wert. NULL wird als 0 behandelt. |\n| `PriceMin` | money | Nein | Mindestverkaufspreis des Artikels (`items.Price`). NULL oder 0 bedeutet kein Filter. |\n| `PriceMax` | money | Nein | Höchstverkaufspreis des Artikels (`items.Price`). NULL oder 0 bedeutet kein Filter. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer; nur Artikel dieses Lieferanten (`items.SupplNR`). NULL oder leer bedeutet alle Lieferanten. |\n| `ExcludeInhouseEAN` | bit | Nein | Legt fest, ob Artikel mit internen EAN-Nummern (beginnend mit `2`) ausgeschlossen werden. |\n| `DeductReturns` | bit | Nein | Legt fest, ob Rechnungspositionen mit negativer Menge (z. B. Gutschriften) von der Verkaufsmenge abgezogen werden. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen, die Werte können also nicht festgeschriebene Daten enthalten.\n- Die Berechnung läuft über alle Artikel mit Bestandsdatensätzen und nutzt je Artikel eine korrelierte Unterabfrage auf `Invlines`. Jeder Aufruf (auch jede Seite) berechnet den vollständigen Bericht neu; bei großen Datenbanken kann das langsam sein.\n- `SalesDaysBack` = 0 führt zu einem SQL-Fehler wegen Division durch null, der als `SqlMessage` zurückkommt. Bei `SalesDaysBack` = NULL werden keine Verkäufe gezählt, `SalesPerDay` ist NULL und jeder Artikel erhält `StockRange` 9999.\n- `PriceMin` und `PriceMax` werden mit `NULLIF(…, '')` normalisiert; die leere Zeichenkette wird in den Money-Wert 0 umgewandelt, daher bedeutet `0` *kein Filter*. Insbesondere schränkt `PriceMax` = 0 das Ergebnis nicht ein.\n- `SupplNr` als leere Zeichenkette wird wie NULL behandelt (kein Filter). `StartRow`, `StockMin` und `MinStockRange` = NULL werden als 0 behandelt.\n- `RowCount` wird per `SET ROWCOUNT` angewendet; `RowCount` = 0 liefert alle passenden Zeilen.\n- Bei `ExcludeInhouseEAN` = 1 werden auch Artikel ohne `EANUPC` (NULL) ausgeschlossen, da der `NOT LIKE`-Vergleich für NULL nicht wahr ist.\n- Trotz des Namens basiert `LastStockInc` auf dem jüngsten `UpdateDate` der Bestandsdatensätze und nicht speziell auf dem letzten Bestandszugang.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportStockRange"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert einen seitenweise abrufbaren Reichweitenbericht je Artikel mit Bestand, Verkäufen im Zeitraum, Verkäufen pro Tag und der daraus berechneten Reichweite in Tagen.\n\nBerechnet, wie viele Tage der aktuelle Bestand jedes Artikels auf Basis der bisherigen Verkäufe reicht, und liefert die Artikel, deren Reichweite mindestens `MinStockRange` Tage beträgt. Typischer Einsatz ist die Suche nach Ladenhütern oder Überbeständen.\n\n**Berechnung**\n\n1. Für jeden Artikel mit mindestens einem Bestandsdatensatz (`InvBinItem` verknüpft mit `InvBin`) wird ermittelt:\n - `Stock`: Summe von `BinItemQty` über alle Lagerplätze des Artikels.\n - `Sales`: Summe von `ItemQty` der Rechnungspositionen (`Invlines`) des Artikels, die in den letzten `SalesDaysBack` Kalendertagen angelegt wurden. Standardmäßig zählen nur Positionen mit positiver Menge. Mit `DeductReturns` = 1 werden alle Positionen gezählt, negative Positionen wie Gutschriften verringern also die Summe.\n - `LastStockInc`: Anzahl Tage seit dem jüngsten `UpdateDate` der Bestandsdatensätze des Artikels.\n2. `SalesPerDay` = `Sales` / `SalesDaysBack`.\n3. `StockRange` = `Stock` / `SalesPerDay` in Tagen. Ist `Sales` 0 oder kleiner, wird `StockRange` auf `9999` gesetzt.\n\n**Filter** (alle mit UND verknüpft)\n\n- `SupplNr`: nur Artikel dieses Lieferanten (`items.SupplNR`).\n- `PriceMin` / `PriceMax`: Grenzen für den Verkaufspreis (`items.Price`).\n- `LastStockIncDays`: nur Artikel, deren `LastStockInc` größer als dieser Wert ist.\n- `StockMin`: nur Artikel mit `Stock` >= diesem Wert (Standard 0, Artikel mit negativem Bestand fallen also heraus).\n- `MinStockRange`: nur Artikel mit `StockRange` >= diesem Wert.\n- `ExcludeInhouseEAN` = 1: Artikel, deren `EANUPC` mit `2` beginnt (interne EAN-Nummern), werden ausgeschlossen.\n\n**Sortierung und Paging**\n\nDie gefilterten Zeilen werden in `Row` nach `StockRange` absteigend, dann `ItemName` nummeriert. Zurückgegeben werden höchstens `RowCount` Zeilen mit `Row` > `StartRow` in derselben Reihenfolge. Für die nächste Seite wird die zuletzt erhaltene `Row` als `StartRow` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen (Seitengröße). 0 liefert alle Zeilen. |\n| `StartRow` | int | Nein | Es werden nur Zeilen mit `Row` größer als dieser Wert geliefert. NULL wird als 0 behandelt (erste Seite). |\n| `MinStockRange` | int | Nein | Mindestreichweite in Tagen; nur Artikel mit `StockRange` >= diesem Wert werden geliefert. NULL wird als 0 behandelt. |\n| `SalesDaysBack` | int | Nein | Länge des Verkaufszeitraums in Tagen, rückwärts ab jetzt gerechnet. Zugleich Divisor für `SalesPerDay`; darf nicht 0 sein. |\n| `LastStockIncDays` | int | Nein | Wenn gesetzt, nur Artikel, deren Bestandsdatensätze zuletzt vor mehr als dieser Anzahl Tage aktualisiert wurden (`LastStockInc` > Wert). |\n| `StockMin` | int | Nein | Mindestgesamtbestand; nur Artikel mit `Stock` >= diesem Wert. NULL wird als 0 behandelt. |\n| `PriceMin` | money | Nein | Mindestverkaufspreis des Artikels (`items.Price`). NULL oder 0 bedeutet kein Filter. |\n| `PriceMax` | money | Nein | Höchstverkaufspreis des Artikels (`items.Price`). NULL oder 0 bedeutet kein Filter. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer; nur Artikel dieses Lieferanten (`items.SupplNR`). NULL oder leer bedeutet alle Lieferanten. |\n| `ExcludeInhouseEAN` | bit | Nein | Legt fest, ob Artikel mit internen EAN-Nummern (beginnend mit `2`) ausgeschlossen werden. |\n| `DeductReturns` | bit | Nein | Legt fest, ob Rechnungspositionen mit negativer Menge (z. B. Gutschriften) von der Verkaufsmenge abgezogen werden. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen, die Werte können also nicht festgeschriebene Daten enthalten.\n- Die Berechnung läuft über alle Artikel mit Bestandsdatensätzen und nutzt je Artikel eine korrelierte Unterabfrage auf `Invlines`. Jeder Aufruf (auch jede Seite) berechnet den vollständigen Bericht neu; bei großen Datenbanken kann das langsam sein.\n- `SalesDaysBack` = 0 führt zu einem SQL-Fehler wegen Division durch null, der als `SqlMessage` zurückkommt. Bei `SalesDaysBack` = NULL werden keine Verkäufe gezählt, `SalesPerDay` ist NULL und jeder Artikel erhält `StockRange` 9999.\n- `PriceMin` und `PriceMax` werden mit `NULLIF(…, '')` normalisiert; die leere Zeichenkette wird in den Money-Wert 0 umgewandelt, daher bedeutet `0` *kein Filter*. Insbesondere schränkt `PriceMax` = 0 das Ergebnis nicht ein.\n- `SupplNr` als leere Zeichenkette wird wie NULL behandelt (kein Filter). `StartRow`, `StockMin` und `MinStockRange` = NULL werden als 0 behandelt.\n- `RowCount` wird per `SET ROWCOUNT` angewendet; `RowCount` = 0 liefert alle passenden Zeilen.\n- Bei `ExcludeInhouseEAN` = 1 werden auch Artikel ohne `EANUPC` (NULL) ausgeschlossen, da der `NOT LIKE`-Vergleich für NULL nicht wahr ist.\n- Trotz des Namens basiert `LastStockInc` auf dem jüngsten `UpdateDate` der Bestandsdatensätze und nicht speziell auf dem letzten Bestandszugang.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportStockRange"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 4711\n Winterjacke Herren XL\n 129.9000\n 54.0000\n 4006381333931\n WJ-XL-01\n 100245\n 35\n 0\n 0.000000000000000\n 210\n 9999.00000000000\n \n \n 2\n 5120\n Regenschirm schwarz\n 19.9000\n 6.5000\n 4012345678901\n RS-100\n 100388\n 120\n 36\n 0.100000000000000\n 45\n 1200.00000000000\n \n"
}
]
},
{
"name": "pixiReportStockSalesOverview",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert pro Artikel eine Übersicht über aktuellen Bestand, Lagerbewegungen, fakturierte Verkäufe und Retouren seit einem Stichtag, mit Paging über den Artikelschlüssel.\n\nErstellt einen Bestands- und Verkaufsbericht für alle Artikel aus `Items`.\n\nPro Artikel werden berechnet:\n\n- **Durchschnittlicher Lieferanten-EK** (`SupplPrice`): Durchschnitt von `SupplPrice` aus `AddItems` für die `IntLinkNr1` des Artikels. Lieferant `MGS` sowie leere Preise und Nullpreise werden ignoriert. Wird kein Preis gefunden, ist der Wert `0`.\n- **Aktueller Bestand** (`StockQty`): Summe von `BinItemQty` über alle Lagerplätze in `InvBinItem`, `0` ohne Lagerplatzeintrag.\n- **Zugänge / Abgänge** (`StockInc`, `StockDec`): Summe der positiven bzw. negativen Mengen im Lagerplatzprotokoll `InvBinItemLog` mit `UpdateDate >= @StatDateFrom`.\n- **Erste Einlagerung** (`FirstPutToStock`): frühester Protokolleintrag mit positiver Menge. Dieser Wert berücksichtigt `@StatDateFrom` **nicht**.\n- **Verkaufte / retournierte Menge** (`ItemQtySold`, `ItemQtyReturned`): Summe der positiven bzw. negativen `ItemQty` aus Rechnungspositionen (`InvLines`) mit `CreateDate >= @StatDateFrom`.\n- **Letztes Verkaufsdatum** (`LastSaleDate`): späteste `CreateDate` dieser Rechnungspositionen.\n\nDer Kategorietext stammt aus `TontrArten` und wird über den `ConfigType` des Artikels zugeordnet.\n\nFilter:\n\n- `@StatDateFrom`: Beginn des Auswertungszeitraums. Bei `NULL` wird `1970-01-01` verwendet, also die gesamte Historie.\n- `@ItemKeyStart`: nur Artikel mit `ItemKey >= @ItemKeyStart`. `NULL` bedeutet keine Untergrenze.\n- `@OnlyItemsOnStock = 1`: nur Artikel mit aktuellem Bestand größer 0.\n\nSortierung nach `ItemKey` aufsteigend. `SET ROWCOUNT @RowCount` begrenzt die Zeilenanzahl. Für Paging wird im nächsten Aufruf der zuletzt gelieferte `ItemKey` + 1 als `@ItemKeyStart` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StatDateFrom` | datetime | Nein | Beginn des Auswertungszeitraums für Lagerbewegungen und Rechnungspositionen. Bei `NULL` wird `1970-01-01` verwendet. |\n| `ItemKeyStart` | int | Nein | Liefert nur Artikel mit `ItemKey` größer oder gleich diesem Wert. Dient dem Paging. `NULL` bedeutet keine Untergrenze. |\n| `OnlyItemsOnStock` | bit | Nein | Beschränkt das Ergebnis auf Artikel mit aktuellem Bestand größer 0. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen, umgesetzt über `SET ROWCOUNT`. `0` bedeutet keine Begrenzung. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen. Die Werte können daher nicht festgeschriebene Daten enthalten.\n- Die Aggregationen in den CTEs laufen über **alle** Artikel. Die Filter `@ItemKeyStart` und `@OnlyItemsOnStock` greifen erst im abschließenden `SELECT`. Je nach Optimizer kann der Aufruf bei großen Datenbeständen langsam sein. Zusätzlich wird die Skalarfunktion `fPixi_GetAverageSupplPrice` pro Artikel ausgewertet.\n- `StockDec` und `ItemQtyReturned` sind negative Werte oder `0`.\n- `LastSaleDate` ist `NULL`, wenn im Zeitraum keine Rechnungspositionen vorhanden sind. `FirstPutToStock` ist `NULL`, wenn der Artikel nie eingelagert wurde.\n- `@RowCount = 0` hebt die Zeilenbegrenzung auf, da `SET ROWCOUNT 0` so arbeitet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportStockSalesOverview"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert pro Artikel eine Übersicht über aktuellen Bestand, Lagerbewegungen, fakturierte Verkäufe und Retouren seit einem Stichtag, mit Paging über den Artikelschlüssel.\n\nErstellt einen Bestands- und Verkaufsbericht für alle Artikel aus `Items`.\n\nPro Artikel werden berechnet:\n\n- **Durchschnittlicher Lieferanten-EK** (`SupplPrice`): Durchschnitt von `SupplPrice` aus `AddItems` für die `IntLinkNr1` des Artikels. Lieferant `MGS` sowie leere Preise und Nullpreise werden ignoriert. Wird kein Preis gefunden, ist der Wert `0`.\n- **Aktueller Bestand** (`StockQty`): Summe von `BinItemQty` über alle Lagerplätze in `InvBinItem`, `0` ohne Lagerplatzeintrag.\n- **Zugänge / Abgänge** (`StockInc`, `StockDec`): Summe der positiven bzw. negativen Mengen im Lagerplatzprotokoll `InvBinItemLog` mit `UpdateDate >= @StatDateFrom`.\n- **Erste Einlagerung** (`FirstPutToStock`): frühester Protokolleintrag mit positiver Menge. Dieser Wert berücksichtigt `@StatDateFrom` **nicht**.\n- **Verkaufte / retournierte Menge** (`ItemQtySold`, `ItemQtyReturned`): Summe der positiven bzw. negativen `ItemQty` aus Rechnungspositionen (`InvLines`) mit `CreateDate >= @StatDateFrom`.\n- **Letztes Verkaufsdatum** (`LastSaleDate`): späteste `CreateDate` dieser Rechnungspositionen.\n\nDer Kategorietext stammt aus `TontrArten` und wird über den `ConfigType` des Artikels zugeordnet.\n\nFilter:\n\n- `@StatDateFrom`: Beginn des Auswertungszeitraums. Bei `NULL` wird `1970-01-01` verwendet, also die gesamte Historie.\n- `@ItemKeyStart`: nur Artikel mit `ItemKey >= @ItemKeyStart`. `NULL` bedeutet keine Untergrenze.\n- `@OnlyItemsOnStock = 1`: nur Artikel mit aktuellem Bestand größer 0.\n\nSortierung nach `ItemKey` aufsteigend. `SET ROWCOUNT @RowCount` begrenzt die Zeilenanzahl. Für Paging wird im nächsten Aufruf der zuletzt gelieferte `ItemKey` + 1 als `@ItemKeyStart` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StatDateFrom` | datetime | Nein | Beginn des Auswertungszeitraums für Lagerbewegungen und Rechnungspositionen. Bei `NULL` wird `1970-01-01` verwendet. |\n| `ItemKeyStart` | int | Nein | Liefert nur Artikel mit `ItemKey` größer oder gleich diesem Wert. Dient dem Paging. `NULL` bedeutet keine Untergrenze. |\n| `OnlyItemsOnStock` | bit | Nein | Beschränkt das Ergebnis auf Artikel mit aktuellem Bestand größer 0. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen, umgesetzt über `SET ROWCOUNT`. `0` bedeutet keine Begrenzung. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen. Die Werte können daher nicht festgeschriebene Daten enthalten.\n- Die Aggregationen in den CTEs laufen über **alle** Artikel. Die Filter `@ItemKeyStart` und `@OnlyItemsOnStock` greifen erst im abschließenden `SELECT`. Je nach Optimizer kann der Aufruf bei großen Datenbeständen langsam sein. Zusätzlich wird die Skalarfunktion `fPixi_GetAverageSupplPrice` pro Artikel ausgewertet.\n- `StockDec` und `ItemQtyReturned` sind negative Werte oder `0`.\n- `LastSaleDate` ist `NULL`, wenn im Zeitraum keine Rechnungspositionen vorhanden sind. `FirstPutToStock` ist `NULL`, wenn der Artikel nie eingelagert wurde.\n- `@RowCount = 0` hebt die Zeilenbegrenzung auf, da `SET ROWCOUNT 0` so arbeitet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportStockSalesOverview"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1001\n A-10045\n SUP-778\n LIEF01\n Trekking Rucksack 40L\n Standardartikel\n 89.9000\n 41.5000\n 23\n 60\n -37\n 39\n -2\n 2021-03-15T10:22:00\n 2024-05-28T14:03:11\n \n"
}
]
},
{
"name": "pixiReport_StockValue",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Lagerwertbericht: Bestand je Artikel und Lager zu einem Stichtag mit VK brutto/netto, EK, Rohertrag und Summenwerten.\n\nWrapper um die interne Berichtsprozedur `Report_StockValue`. Alle Parameter werden unverändert weitergereicht.\n\n**Ablauf**\n\n1. Der Stichtag wird auf das Tagesende von `ParamDate` gesetzt. Ohne `ParamDate` gilt das Ende des aktuellen Tages.\n2. Der Bestand wird aus dem Lagerbewegungsprotokoll `InvBinItemLog` rekonstruiert. Alle Bewegungen mit `UpdateDate` bis zum Stichtag werden je Lager (`LocID`) und Artikel summiert. Nur Kombinationen mit einer Summe ungleich 0 bleiben erhalten, negative Bestände sind also enthalten.\n3. Ist `LocID` angegeben und nicht leer, werden nur Bewegungen dieses Lagers berücksichtigt. Andernfalls werden alle Lager einbezogen.\n4. Jede Bestandszeile wird mit dem Artikel (`Items`) verknüpft. Zeilen ohne existierenden Artikel entfallen.\n5. Je Artikel wird die zum Stichtag letzte gültige Lieferanteninformation ermittelt. Sie liefert den Verkaufspreis `Price`, den Einkaufspreis `SupplPrice` und die Lieferantennummer. Der Lieferantenname stammt aus `Suppliers`, der Kategorietext über `Items.ConfigType` aus `TontrArten`.\n6. Der Mehrwertsteuersatz wird für das Standardland und den Stichtag anhand von `MwStSatz` des Artikels bestimmt:\n - `1` = voller Satz\n - `2` = ermäßigter Satz\n - jeder andere Wert = keine MwSt.; der Preis gilt als netto.\n7. Filter:\n - Ist `SupplNr` angegeben und nicht leer, werden nur Artikel geliefert, deren letzter Lieferant dieser Lieferant ist.\n - Ist `Category` angegeben und nicht leer, werden nur Artikel mit `ConfigType` = `Category` geliefert.\n8. Es wird eine Zeile je Artikel und Lager geliefert, sortiert nach dem internen Artikelschlüssel.\n\n**Berechnete Werte**\n\n- `VK_Netto` = Bruttopreis geteilt durch (1 + MwSt.-Satz)\n- `Rohertrag` = `VK_Netto` − `EK` je Stück\n- `Sum_*` = Bestandsmenge × Stückwert\n\nDie Spalten `par_*` geben die wirksamen Filterwerte zurück. Nicht gesetzte Filter erscheinen als `-alle-`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ParamDate` | datetime | Nein | Stichtag des Berichts. Bestand und Preise werden zum Ende dieses Tages ermittelt. NULL = heute. |\n| `LocID` | varchar(10) | Nein | Filter auf das Lager. NULL oder leer = alle Lager. |\n| `Category` | varchar(10) | Nein | Filter auf die Artikelkategorie, verglichen mit `Items.ConfigType`. NULL oder leer = alle Kategorien. |\n| `SupplNr` | varchar(10) | Nein | Filter auf den Lieferanten der zum Stichtag letzten Lieferanteninformation. NULL oder leer = alle Lieferanten. |\n\n- Nur lesend. Die meisten Tabellen werden `WITH (NOLOCK)` gelesen, das Ergebnis kann daher nicht festgeschriebene Daten enthalten. `Items` wird ohne Hinweis gelesen.\n- Der Bestand wird aus dem gesamten Bewegungsprotokoll bis zum Stichtag neu berechnet. Bei großer Historie kann das langsam sein; Filter nach Möglichkeit verwenden.\n- Von `ParamDate` zählt nur das Datum, da die Uhrzeit immer auf das Tagesende gesetzt wird.\n- Die Lagerspalte der internen Zwischentabelle ist `varchar(3)`, obwohl `LocID` bis zu 10 Zeichen annimmt.\n- Ist `SupplNr` gesetzt, entfallen Artikel ohne Lieferanteninformation. Ohne Filter werden sie mit NULL-Preisen geliefert.\n- `Rohertrah` (sic, abweichend von `Rohertrag` geschrieben) ist der Gesamt-Rohertrag. Er ist `0` für Artikel, deren `MwStSatz` weder 1 noch 2 ist, während `Rohertrag` für diese Artikel trotzdem berechnet wird.\n- Die Ausgabespalte `MwStSatz` enthält den MwSt.-Satz in Prozent, nicht den Steuerschlüssel des Artikels.\n- Die Hilfsfunktionen `fPixi_GetLatestSupplierInfo`, `fPixi_GetVATRate`, `fPixi_GetDefaultCountryCode`, `fPixi_GetDateEndOfDay` und `pixi.GetDatabaseCurrency` liegen nicht vor. Ihre genaue Logik, etwa wie die \"letzte\" Lieferanteninformation gewählt wird, und die Datentypen der Preisspalten sind daher hier nicht dokumentiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_StockValue"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Lagerwertbericht: Bestand je Artikel und Lager zu einem Stichtag mit VK brutto/netto, EK, Rohertrag und Summenwerten.\n\nWrapper um die interne Berichtsprozedur `Report_StockValue`. Alle Parameter werden unverändert weitergereicht.\n\n**Ablauf**\n\n1. Der Stichtag wird auf das Tagesende von `ParamDate` gesetzt. Ohne `ParamDate` gilt das Ende des aktuellen Tages.\n2. Der Bestand wird aus dem Lagerbewegungsprotokoll `InvBinItemLog` rekonstruiert. Alle Bewegungen mit `UpdateDate` bis zum Stichtag werden je Lager (`LocID`) und Artikel summiert. Nur Kombinationen mit einer Summe ungleich 0 bleiben erhalten, negative Bestände sind also enthalten.\n3. Ist `LocID` angegeben und nicht leer, werden nur Bewegungen dieses Lagers berücksichtigt. Andernfalls werden alle Lager einbezogen.\n4. Jede Bestandszeile wird mit dem Artikel (`Items`) verknüpft. Zeilen ohne existierenden Artikel entfallen.\n5. Je Artikel wird die zum Stichtag letzte gültige Lieferanteninformation ermittelt. Sie liefert den Verkaufspreis `Price`, den Einkaufspreis `SupplPrice` und die Lieferantennummer. Der Lieferantenname stammt aus `Suppliers`, der Kategorietext über `Items.ConfigType` aus `TontrArten`.\n6. Der Mehrwertsteuersatz wird für das Standardland und den Stichtag anhand von `MwStSatz` des Artikels bestimmt:\n - `1` = voller Satz\n - `2` = ermäßigter Satz\n - jeder andere Wert = keine MwSt.; der Preis gilt als netto.\n7. Filter:\n - Ist `SupplNr` angegeben und nicht leer, werden nur Artikel geliefert, deren letzter Lieferant dieser Lieferant ist.\n - Ist `Category` angegeben und nicht leer, werden nur Artikel mit `ConfigType` = `Category` geliefert.\n8. Es wird eine Zeile je Artikel und Lager geliefert, sortiert nach dem internen Artikelschlüssel.\n\n**Berechnete Werte**\n\n- `VK_Netto` = Bruttopreis geteilt durch (1 + MwSt.-Satz)\n- `Rohertrag` = `VK_Netto` − `EK` je Stück\n- `Sum_*` = Bestandsmenge × Stückwert\n\nDie Spalten `par_*` geben die wirksamen Filterwerte zurück. Nicht gesetzte Filter erscheinen als `-alle-`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ParamDate` | datetime | Nein | Stichtag des Berichts. Bestand und Preise werden zum Ende dieses Tages ermittelt. NULL = heute. |\n| `LocID` | varchar(10) | Nein | Filter auf das Lager. NULL oder leer = alle Lager. |\n| `Category` | varchar(10) | Nein | Filter auf die Artikelkategorie, verglichen mit `Items.ConfigType`. NULL oder leer = alle Kategorien. |\n| `SupplNr` | varchar(10) | Nein | Filter auf den Lieferanten der zum Stichtag letzten Lieferanteninformation. NULL oder leer = alle Lieferanten. |\n\n- Nur lesend. Die meisten Tabellen werden `WITH (NOLOCK)` gelesen, das Ergebnis kann daher nicht festgeschriebene Daten enthalten. `Items` wird ohne Hinweis gelesen.\n- Der Bestand wird aus dem gesamten Bewegungsprotokoll bis zum Stichtag neu berechnet. Bei großer Historie kann das langsam sein; Filter nach Möglichkeit verwenden.\n- Von `ParamDate` zählt nur das Datum, da die Uhrzeit immer auf das Tagesende gesetzt wird.\n- Die Lagerspalte der internen Zwischentabelle ist `varchar(3)`, obwohl `LocID` bis zu 10 Zeichen annimmt.\n- Ist `SupplNr` gesetzt, entfallen Artikel ohne Lieferanteninformation. Ohne Filter werden sie mit NULL-Preisen geliefert.\n- `Rohertrah` (sic, abweichend von `Rohertrag` geschrieben) ist der Gesamt-Rohertrag. Er ist `0` für Artikel, deren `MwStSatz` weder 1 noch 2 ist, während `Rohertrag` für diese Artikel trotzdem berechnet wird.\n- Die Ausgabespalte `MwStSatz` enthält den MwSt.-Satz in Prozent, nicht den Steuerschlüssel des Artikels.\n- Die Hilfsfunktionen `fPixi_GetLatestSupplierInfo`, `fPixi_GetVATRate`, `fPixi_GetDefaultCountryCode`, `fPixi_GetDateEndOfDay` und `pixi.GetDatabaseCurrency` liegen nicht vor. Ihre genaue Logik, etwa wie die \"letzte\" Lieferanteninformation gewählt wird, und die Datentypen der Preisspalten sind daher hier nicht dokumentiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_StockValue"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n SUP-4711\n 100234\n 4006381333931\n Notizbuch A5 kariert\n Standard\n Papierwaren GmbH\n 001\n 25\n 11.9000\n 10.0000\n 4.5000\n 5.5000\n 250.0000\n 297.5000\n 112.5000\n 19.00\n 137.5000\n EUR\n 2024-03-31T23:59:59.997\n 001\n -alle-\n -alle-\n \n"
}
]
},
{
"name": "pixiReport_StockValue_Hist",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den historischen Lagerwert je Artikel zu einem Stichtag, bewertet mit historischen Lieferantenpreisen und Netto-Verkaufspreisen.\n\nWrapper um die interne Report-Prozedur `Report_StockValue_Hist`. Sie läuft immer mit `ShowDetails = 0`. Der Lieferantenfilter verwendet immer den Hauptlieferanten des Artikels (`AllItemsForSupplier = 0`).\n\nAblauf:\n\n1. **Stichtag**: `ParamDate` wird auf das Tagesende gesetzt. Ohne Angabe wird das Ende des aktuellen Tages verwendet.\n2. **Artikelfilter**: Leere Zeichenketten für `LocID`, `Category` und `SupplNr` gelten als \"kein Filter\".\n - `SupplNr` filtert auf den Hauptlieferanten des Artikels (`Items.SupplNr`).\n - `Category` filtert auf `Items.ConfigType`.\n3. **Bestand zum Stichtag**: Je Artikel werden alle Mengenbewegungen aus `InvBinItemLog` bis zum Stichtag summiert.\n - Mit `LocID` zählen nur Lagerplätze dieses Lagers (`InvBin.BinLocID`).\n - Bewegungen auf Lagerplätzen, die erst nach dem Stichtag gelöscht wurden, werden ebenfalls berücksichtigt. Diese Lagerplätze stehen in `InvBinHist` mit Vermerk `Deleted`.\n - Artikel mit resultierendem Bestand 0 entfallen.\n4. **Historische Lieferantenpreise**: Die Bestände werden an interne Hilfsprozeduren übergeben. Diese ermitteln historische Einkaufspreise aus Lieferantenlieferungen. Ein Artikel kann daher in mehreren Zeilen erscheinen, je eine pro Lieferantenlieferung, aus der sich der Bestand zusammensetzt.\n5. **Verkaufspreis**:\n - `VK_Netto` ist der Bruttopreis `Items.Price` geteilt durch (1 + MwSt-Satz), gerundet auf 2 Nachkommastellen.\n - Der MwSt-Satz ergibt sich aus dem `MwStSatz` des Artikels: `1` = voller Satz, `2` = ermäßigter Satz, jeder andere Wert = 0. Es gelten die Sätze des Standardlandes.\n\nSortierung nach `Artikelname`, dann `SupplDelDate`, dann MwSt-Satz.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ParamDate` | datetime | Nein | Stichtag für den Lagerwert. Verwendet wird das Ende dieses Tages. Ohne Angabe gilt das Ende des aktuellen Tages. |\n| `LocID` | varchar(10) | Nein | Lager-ID. Nur Bestand auf Lagerplätzen dieses Lagers wird gezählt. Leer oder nicht angegeben bedeutet alle Lager. |\n| `Category` | varchar(10) | Nein | Artikelkategorie, verglichen mit `Items.ConfigType`. Leer oder nicht angegeben bedeutet alle Kategorien. |\n| `SupplNr` | varchar(10) | Nein | Lieferantennummer. Nur Artikel, deren Hauptlieferant (`Items.SupplNr`) übereinstimmt, werden berücksichtigt. Leer oder nicht angegeben bedeutet alle Lieferanten. |\n\n- Alle permanenten Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Die historischen Lieferantenpreise stammen aus `Report_SaveSupplierPrices` und `pixi_HistorySupplierPriceForItems`. Deren Definitionen liegen nicht vor. Ob sie in permanente Tabellen schreiben und wie `SupplPriceHist`, `SupplPriceType` und `SupplPriceMessage` genau ermittelt werden, ist hier nicht ersichtlich.\n- Die MwSt-Sätze werden zum aktuellen Datum ermittelt, nicht zum `ParamDate`. Historische Satzänderungen fließen daher nicht in `VK_Netto` ein.\n- `Bestand` ist der Gesamtbestand des Artikels zum Stichtag und wiederholt sich in jeder Lieferungszeile dieses Artikels. Für zeilenweise Summen `SupplDelQty` verwenden. `Sum_VK_Netto` und `Sum_SupplPriceHist` basieren bereits auf `SupplDelQty`.\n- `par_Category` und `par_SupplNR` enthalten `-alle-`, wenn kein Filter gesetzt ist. Andernfalls enthalten sie den Kategorietext bzw. den **Namen** des Lieferanten des Artikels, nicht die Nummer.\n- Der Report wertet das gesamte Lagerplatz-Bewegungsprotokoll aus und kann bei großen Datenbanken langsam sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_StockValue_Hist"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den historischen Lagerwert je Artikel zu einem Stichtag, bewertet mit historischen Lieferantenpreisen und Netto-Verkaufspreisen.\n\nWrapper um die interne Report-Prozedur `Report_StockValue_Hist`. Sie läuft immer mit `ShowDetails = 0`. Der Lieferantenfilter verwendet immer den Hauptlieferanten des Artikels (`AllItemsForSupplier = 0`).\n\nAblauf:\n\n1. **Stichtag**: `ParamDate` wird auf das Tagesende gesetzt. Ohne Angabe wird das Ende des aktuellen Tages verwendet.\n2. **Artikelfilter**: Leere Zeichenketten für `LocID`, `Category` und `SupplNr` gelten als \"kein Filter\".\n - `SupplNr` filtert auf den Hauptlieferanten des Artikels (`Items.SupplNr`).\n - `Category` filtert auf `Items.ConfigType`.\n3. **Bestand zum Stichtag**: Je Artikel werden alle Mengenbewegungen aus `InvBinItemLog` bis zum Stichtag summiert.\n - Mit `LocID` zählen nur Lagerplätze dieses Lagers (`InvBin.BinLocID`).\n - Bewegungen auf Lagerplätzen, die erst nach dem Stichtag gelöscht wurden, werden ebenfalls berücksichtigt. Diese Lagerplätze stehen in `InvBinHist` mit Vermerk `Deleted`.\n - Artikel mit resultierendem Bestand 0 entfallen.\n4. **Historische Lieferantenpreise**: Die Bestände werden an interne Hilfsprozeduren übergeben. Diese ermitteln historische Einkaufspreise aus Lieferantenlieferungen. Ein Artikel kann daher in mehreren Zeilen erscheinen, je eine pro Lieferantenlieferung, aus der sich der Bestand zusammensetzt.\n5. **Verkaufspreis**:\n - `VK_Netto` ist der Bruttopreis `Items.Price` geteilt durch (1 + MwSt-Satz), gerundet auf 2 Nachkommastellen.\n - Der MwSt-Satz ergibt sich aus dem `MwStSatz` des Artikels: `1` = voller Satz, `2` = ermäßigter Satz, jeder andere Wert = 0. Es gelten die Sätze des Standardlandes.\n\nSortierung nach `Artikelname`, dann `SupplDelDate`, dann MwSt-Satz.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ParamDate` | datetime | Nein | Stichtag für den Lagerwert. Verwendet wird das Ende dieses Tages. Ohne Angabe gilt das Ende des aktuellen Tages. |\n| `LocID` | varchar(10) | Nein | Lager-ID. Nur Bestand auf Lagerplätzen dieses Lagers wird gezählt. Leer oder nicht angegeben bedeutet alle Lager. |\n| `Category` | varchar(10) | Nein | Artikelkategorie, verglichen mit `Items.ConfigType`. Leer oder nicht angegeben bedeutet alle Kategorien. |\n| `SupplNr` | varchar(10) | Nein | Lieferantennummer. Nur Artikel, deren Hauptlieferant (`Items.SupplNr`) übereinstimmt, werden berücksichtigt. Leer oder nicht angegeben bedeutet alle Lieferanten. |\n\n- Alle permanenten Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Die historischen Lieferantenpreise stammen aus `Report_SaveSupplierPrices` und `pixi_HistorySupplierPriceForItems`. Deren Definitionen liegen nicht vor. Ob sie in permanente Tabellen schreiben und wie `SupplPriceHist`, `SupplPriceType` und `SupplPriceMessage` genau ermittelt werden, ist hier nicht ersichtlich.\n- Die MwSt-Sätze werden zum aktuellen Datum ermittelt, nicht zum `ParamDate`. Historische Satzänderungen fließen daher nicht in `VK_Netto` ein.\n- `Bestand` ist der Gesamtbestand des Artikels zum Stichtag und wiederholt sich in jeder Lieferungszeile dieses Artikels. Für zeilenweise Summen `SupplDelQty` verwenden. `Sum_VK_Netto` und `Sum_SupplPriceHist` basieren bereits auf `SupplDelQty`.\n- `par_Category` und `par_SupplNR` enthalten `-alle-`, wenn kein Filter gesetzt ist. Andernfalls enthalten sie den Kategorietext bzw. den **Namen** des Lieferanten des Artikels, nicht die Nummer.\n- Der Report wertet das gesamte Lagerplatz-Bewegungsprotokoll aus und kann bei großen Datenbanken langsam sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_StockValue_Hist"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1234\n SP-100\n A-1000\n 4012345678901\n Beispielartikel\n Standard\n L0042\n Muster GmbH\n 15\n 23.8000\n 20.00\n 19.000000000\n 200.00\n 9.5000\n 9.2000\n 92.0000\n 1\n Supplier delivery\n 10\n 5678\n 2024-11-05T10:12:00\n 2024-12-31T23:59:59.997\n 001\n -alle-\n Muster GmbH\n EUR\n \n"
}
]
},
{
"name": "pixiReportStockValueHistEKPrice",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Artikel mit einem bestimmten Artikel-Tag mit Bestand zum Stichtag, letztem bekannten EK-Preis, Rechnungsrabatten und resultierendem Lagerwert.\n\nErstellt einen Lagerwertbericht auf Basis historischer EK-Preise für alle Artikel, die einen bestimmten Artikel-Tag tragen.\n\nAblauf:\n\n1. Der Artikel-Tag `@ItemTag` (Tag-Typ `1`) wird ermittelt und geprüft, ob der Shop `@ShopID` existiert. Fehlt eines davon, wird der Fehler `Tag or Shop does not exist` ausgelöst (siehe Hinweise, die Ausführung wird nicht abgebrochen).\n2. Alle Artikel, die mit dem Tag verknüpft sind, werden ausgewählt. Pro Artikel wird ermittelt:\n - **Anschaffungsdatum**: das Datum des ersten Lagerplatz-Logeintrags mit positiver Menge (erste Einlagerung, unabhängig vom Datumsbereich).\n - **EK-Preis netto**: der Endpreis der jüngsten Lieferantenlieferposition mit gelieferter Menge > 0 und Preis > 0; gibt es keine, wird der Lieferantenpreis des Artikels verwendet.\n3. Der Bestand wird als Summe aller Lagerplatzbewegungen des Artikels mit Änderungsdatum vor `@DateTo` berechnet (über alle Lager und Lagerplätze).\n4. Die Rabatte aus Rechnungspositionen von Rechnungen des Shops `@ShopID` mit Rechnungsdatum von `@DateFrom` (inklusive) bis `@DateTo` (exklusive) werden summiert. Der Rabatt je Position ist Menge × Rabattwert, umgerechnet in einen Nettobetrag durch Division durch den hohen bzw. niedrigen MwSt-Satz der Rechnung je nach MwSt-Kennzeichen der Position (`H`/`L`).\n - Ist die Einstellung `MultiCurrencyEnabled` gleich `1`, wird der Rabatt zusätzlich über den Wechselkurs der Kursquelle der Datenbankwährung (für Kursdatum und Währung der Rechnung) in die Datenbankwährung umgerechnet.\n5. Pro getaggtem Artikel wird eine Zeile mit Preis, Menge, EK-Gesamtwert, Rabatten und resultierendem Gesamtwert (`EK Gesamt netto` minus `Bewertungsabschläge`) geliefert.\n\nDas Ergebnis hat keine explizite Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | Nein | Shop, dessen Rechnungen für die Rabattberechnung verwendet werden. Muss existieren, sonst wird ein Fehler ausgelöst. |\n| `ItemTag` | varchar(50) | Nein | Name des Artikel-Tags (Tag-Typ 1). Nur mit diesem Tag verknüpfte Artikel werden berücksichtigt. Muss existieren, sonst wird ein Fehler ausgelöst. |\n| `DateFrom` | datetime | Nein | Beginn des Rechnungsdatumsbereichs für Rabatte (inklusive). |\n| `DateTo` | datetime | Nein | Stichtag (exklusive): Ende des Rechnungsdatumsbereichs und Datum, bis zu dem Lagerbewegungen summiert werden. |\n\n- **Fehler bricht die Ausführung nicht ab**: Auf `RAISERROR` mit Schweregrad 16 folgt kein `RETURN`. Der Aufrufer erhält die Fehlermeldung, die Prozedur läuft jedoch weiter. Bei unbekanntem Tag ist die Ergebnismenge leer; bei unbekanntem Shop, aber gültigem Tag werden die Artikel trotzdem geliefert, nur ohne Rabatte.\n- `@ShopID` ist faktisch Pflicht: `NULL` passt nie zu einem existierenden Shop und löst den Fehler aus.\n- `@DateTo` und `@DateFrom` sind faktisch Pflicht: Bei `@DateTo` = `NULL` wird kein Bestand berechnet und der Preis fällt immer auf den Lieferantenpreis des Artikels zurück; bei `@DateFrom` = `NULL` werden keine Rabatte gefunden.\n- **Fallstrick EK-Preis**: Die Datumsbedingung für den letzten Lieferpreis vergleicht das Anlagedatum des Artikels mit `@DateTo`, nicht das Lieferdatum. Der Preis ist daher der jüngste Lieferpreis insgesamt (auch Lieferungen nach `@DateTo`), sofern der Artikel vor `@DateTo` angelegt wurde.\n- Der Bestand ist nicht auf Shop oder Lager eingeschränkt; alle Lagerplatzbewegungen werden summiert.\n- `dbCurrency` enthält den Code der Datenbankwährung nur bei `MultiCurrencyEnabled` = `1`; sonst ist es `NULL` und die Beträge sind in der Originalwährung der Rechnung.\n- Alle Lesezugriffe nutzen `NOLOCK`; Ergebnisse können nicht festgeschriebene Daten enthalten.\n- Spaltennamen enthalten Leerzeichen; im SOAP/DataSet-XML erscheinen sie kodiert, z. B. `EK-Preis_x0020_netto`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportStockValueHistEKPrice"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Artikel mit einem bestimmten Artikel-Tag mit Bestand zum Stichtag, letztem bekannten EK-Preis, Rechnungsrabatten und resultierendem Lagerwert.\n\nErstellt einen Lagerwertbericht auf Basis historischer EK-Preise für alle Artikel, die einen bestimmten Artikel-Tag tragen.\n\nAblauf:\n\n1. Der Artikel-Tag `@ItemTag` (Tag-Typ `1`) wird ermittelt und geprüft, ob der Shop `@ShopID` existiert. Fehlt eines davon, wird der Fehler `Tag or Shop does not exist` ausgelöst (siehe Hinweise, die Ausführung wird nicht abgebrochen).\n2. Alle Artikel, die mit dem Tag verknüpft sind, werden ausgewählt. Pro Artikel wird ermittelt:\n - **Anschaffungsdatum**: das Datum des ersten Lagerplatz-Logeintrags mit positiver Menge (erste Einlagerung, unabhängig vom Datumsbereich).\n - **EK-Preis netto**: der Endpreis der jüngsten Lieferantenlieferposition mit gelieferter Menge > 0 und Preis > 0; gibt es keine, wird der Lieferantenpreis des Artikels verwendet.\n3. Der Bestand wird als Summe aller Lagerplatzbewegungen des Artikels mit Änderungsdatum vor `@DateTo` berechnet (über alle Lager und Lagerplätze).\n4. Die Rabatte aus Rechnungspositionen von Rechnungen des Shops `@ShopID` mit Rechnungsdatum von `@DateFrom` (inklusive) bis `@DateTo` (exklusive) werden summiert. Der Rabatt je Position ist Menge × Rabattwert, umgerechnet in einen Nettobetrag durch Division durch den hohen bzw. niedrigen MwSt-Satz der Rechnung je nach MwSt-Kennzeichen der Position (`H`/`L`).\n - Ist die Einstellung `MultiCurrencyEnabled` gleich `1`, wird der Rabatt zusätzlich über den Wechselkurs der Kursquelle der Datenbankwährung (für Kursdatum und Währung der Rechnung) in die Datenbankwährung umgerechnet.\n5. Pro getaggtem Artikel wird eine Zeile mit Preis, Menge, EK-Gesamtwert, Rabatten und resultierendem Gesamtwert (`EK Gesamt netto` minus `Bewertungsabschläge`) geliefert.\n\nDas Ergebnis hat keine explizite Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | Nein | Shop, dessen Rechnungen für die Rabattberechnung verwendet werden. Muss existieren, sonst wird ein Fehler ausgelöst. |\n| `ItemTag` | varchar(50) | Nein | Name des Artikel-Tags (Tag-Typ 1). Nur mit diesem Tag verknüpfte Artikel werden berücksichtigt. Muss existieren, sonst wird ein Fehler ausgelöst. |\n| `DateFrom` | datetime | Nein | Beginn des Rechnungsdatumsbereichs für Rabatte (inklusive). |\n| `DateTo` | datetime | Nein | Stichtag (exklusive): Ende des Rechnungsdatumsbereichs und Datum, bis zu dem Lagerbewegungen summiert werden. |\n\n- **Fehler bricht die Ausführung nicht ab**: Auf `RAISERROR` mit Schweregrad 16 folgt kein `RETURN`. Der Aufrufer erhält die Fehlermeldung, die Prozedur läuft jedoch weiter. Bei unbekanntem Tag ist die Ergebnismenge leer; bei unbekanntem Shop, aber gültigem Tag werden die Artikel trotzdem geliefert, nur ohne Rabatte.\n- `@ShopID` ist faktisch Pflicht: `NULL` passt nie zu einem existierenden Shop und löst den Fehler aus.\n- `@DateTo` und `@DateFrom` sind faktisch Pflicht: Bei `@DateTo` = `NULL` wird kein Bestand berechnet und der Preis fällt immer auf den Lieferantenpreis des Artikels zurück; bei `@DateFrom` = `NULL` werden keine Rabatte gefunden.\n- **Fallstrick EK-Preis**: Die Datumsbedingung für den letzten Lieferpreis vergleicht das Anlagedatum des Artikels mit `@DateTo`, nicht das Lieferdatum. Der Preis ist daher der jüngste Lieferpreis insgesamt (auch Lieferungen nach `@DateTo`), sofern der Artikel vor `@DateTo` angelegt wurde.\n- Der Bestand ist nicht auf Shop oder Lager eingeschränkt; alle Lagerplatzbewegungen werden summiert.\n- `dbCurrency` enthält den Code der Datenbankwährung nur bei `MultiCurrencyEnabled` = `1`; sonst ist es `NULL` und die Beträge sind in der Originalwährung der Rechnung.\n- Alle Lesezugriffe nutzen `NOLOCK`; Ergebnisse können nicht festgeschriebene Daten enthalten.\n- Spaltennamen enthalten Leerzeichen; im SOAP/DataSet-XML erscheinen sie kodiert, z. B. `EK-Preis_x0020_netto`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportStockValueHistEKPrice"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Bluetooth Kopfhörer X200\n BT-X200\n 14.03.2022\n 24.5000\n 40\n 980.0000\n 35.2100\n 944.7900\n EUR\n \n \n USB-C Ladekabel 1m\n USBC-1M\n \n 2.1000\n 0\n 0.0000\n 0.0000\n 0.0000\n EUR\n \n"
}
]
},
{
"name": "pixiReportTurnover",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Netto-Rechnungsumsatz für den Stichtag, den Vortag, den laufenden Monat und den Vormonat, optional gefiltert nach Shop.\n\nDashboard-Report, der `Total_Net` der Rechnungen (`Invoices`) zu vier Umsatzwerten summiert und diese in einer Zeile zurückgibt.\n\n**Datumslogik**\n- `toDate` ist standardmäßig das aktuelle Datum mit Uhrzeit. Die Uhrzeit ist relevant: Stichtag und laufender Monat werden nur bis `toDate` gezählt, nicht bis zum Tagesende.\n- `fromDate` ist standardmäßig der erste Tag des Vormonats von `toDate`. Liegt `fromDate` nach `toDate`, wird es auf `toDate` gesetzt.\n- Grundsätzlich werden nur Rechnungen mit `InvDate` zwischen dem Beginn des Vormonats und `toDate` berücksichtigt.\n\n**Shop-Filter**\nEine Rechnung wird nur gezählt, wenn der Kunde (`CustRef`) mindestens eine Adresse in `Addresses` mit `AddrShopID` = `ShopID` hat. Ein leerer oder NULL-Wert für `ShopID` schließt alle Rechnungen ein, zu denen überhaupt eine Adresse existiert.\n\n**Die vier Werte**\n- `TurnoverNetGivenDate`: liegt `fromDate` in einem anderen Monat als `toDate`, Rechnungen vom Tagesbeginn von `toDate` bis `toDate`; liegt `fromDate` am selben Tag wie `toDate`, Rechnungen von `fromDate` bis `toDate`.\n- `TurnoverNetDayBefore`: liegt `fromDate` in einem anderen Monat, der gesamte Vortag von `toDate`; zusätzlich, falls `fromDate` auf den Vortag fällt, Rechnungen von `fromDate` bis zum Ende dieses Tages.\n- `TurnoverNetGivenMonth`: liegt `fromDate` in einem anderen Monat, vom 1. des Monats von `toDate` bis `toDate`; im selben Monat von `fromDate` bis `toDate`.\n- `TurnoverNetPreviousMonth`: liegt `fromDate` vor dem Vormonat, der gesamte Vormonat; liegt `fromDate` im Vormonat, von `fromDate` bis zum Ende des Vormonats.\n\nMit dem Standardwert für `fromDate` ergibt sich: heute bis jetzt, gestern, Monat bis heute und der gesamte Vormonat.\n\n**Währung**\nIst die Einstellung `MultiCurrencyEnabled` gleich `1`, wird jeder Rechnungsbetrag durch den Wechselkurs aus `pixi.ExchRate` für die Datenbank-Kursquelle (`DatabaseCurrencyExchRateSourceId`) und die Hauswährung geteilt, zugeordnet über Kursdatum und Währung des Rechnungskurses. `dbCurrency` enthält dann den Code der Datenbankwährung. Andernfalls werden die Beträge wie gespeichert summiert und `dbCurrency` ist NULL.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `fromDate` | datetime | Nein | Beginn des Auswertungszeitraums. Standard ist der erste Tag des Vormonats von `toDate`; wird auf `toDate` gesetzt, falls später. Bestimmt, welchen Zeitraum jeder Wert abdeckt (siehe Beschreibung). |\n| `toDate` | datetime | Nein | Stichtag mit Uhrzeit (Ende des Zeitraums). Standard ist das aktuelle Datum mit Uhrzeit. |\n| `ShopID` | varchar(3) | Nein | Shop-Filter: Nur Rechnungen von Kunden mit einer Adresse dieses Shops werden gezählt. Leer bedeutet alle Shops. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; die Werte können nicht festgeschriebene Daten enthalten.\n- Die Werte werden als Zeichenketten (`varchar(30)`) geliefert. Ein Wert ist NULL (Element fehlt in der Zeile), wenn keine Rechnung in den Zeitraum fällt, z. B. sind `TurnoverNetGivenDate` und `TurnoverNetDayBefore` NULL, wenn `fromDate` im selben Monat wie `toDate` liegt, aber weder auf diesem Tag noch auf dem Vortag. `TurnoverNetPreviousMonth` ist NULL, wenn `fromDate` im laufenden Monat liegt.\n- Ein `fromDate` vor dem Beginn des Vormonats hat keine zusätzliche Wirkung, da ältere Rechnungen nie geladen werden.\n- Im Mehrwährungsmodus werden Rechnungen ohne passenden Wechselkurs-Datensatz (oder ohne `ExchRateId`) wegen Inner Joins stillschweigend ausgeschlossen. Die Anzahl der Nachkommastellen hängt vom Datentyp von `ExchRate` ab, der hier nicht sichtbar ist.\n- Fehlt die Einstellung `MultiCurrencyEnabled` (NULL), wird trotzdem der Umrechnungszweig ausgeführt, `dbCurrency` jedoch als NULL geliefert.\n- Bei einem SQL-Fehler wird nur die Meldung per PRINT ausgegeben und `-1` zurückgegeben; es wird keine Ergebnismenge geliefert.\n- Die temporäre Tabelle wird über `util.TempTableDrop` gelöscht (Definition nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportTurnover"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Netto-Rechnungsumsatz für den Stichtag, den Vortag, den laufenden Monat und den Vormonat, optional gefiltert nach Shop.\n\nDashboard-Report, der `Total_Net` der Rechnungen (`Invoices`) zu vier Umsatzwerten summiert und diese in einer Zeile zurückgibt.\n\n**Datumslogik**\n- `toDate` ist standardmäßig das aktuelle Datum mit Uhrzeit. Die Uhrzeit ist relevant: Stichtag und laufender Monat werden nur bis `toDate` gezählt, nicht bis zum Tagesende.\n- `fromDate` ist standardmäßig der erste Tag des Vormonats von `toDate`. Liegt `fromDate` nach `toDate`, wird es auf `toDate` gesetzt.\n- Grundsätzlich werden nur Rechnungen mit `InvDate` zwischen dem Beginn des Vormonats und `toDate` berücksichtigt.\n\n**Shop-Filter**\nEine Rechnung wird nur gezählt, wenn der Kunde (`CustRef`) mindestens eine Adresse in `Addresses` mit `AddrShopID` = `ShopID` hat. Ein leerer oder NULL-Wert für `ShopID` schließt alle Rechnungen ein, zu denen überhaupt eine Adresse existiert.\n\n**Die vier Werte**\n- `TurnoverNetGivenDate`: liegt `fromDate` in einem anderen Monat als `toDate`, Rechnungen vom Tagesbeginn von `toDate` bis `toDate`; liegt `fromDate` am selben Tag wie `toDate`, Rechnungen von `fromDate` bis `toDate`.\n- `TurnoverNetDayBefore`: liegt `fromDate` in einem anderen Monat, der gesamte Vortag von `toDate`; zusätzlich, falls `fromDate` auf den Vortag fällt, Rechnungen von `fromDate` bis zum Ende dieses Tages.\n- `TurnoverNetGivenMonth`: liegt `fromDate` in einem anderen Monat, vom 1. des Monats von `toDate` bis `toDate`; im selben Monat von `fromDate` bis `toDate`.\n- `TurnoverNetPreviousMonth`: liegt `fromDate` vor dem Vormonat, der gesamte Vormonat; liegt `fromDate` im Vormonat, von `fromDate` bis zum Ende des Vormonats.\n\nMit dem Standardwert für `fromDate` ergibt sich: heute bis jetzt, gestern, Monat bis heute und der gesamte Vormonat.\n\n**Währung**\nIst die Einstellung `MultiCurrencyEnabled` gleich `1`, wird jeder Rechnungsbetrag durch den Wechselkurs aus `pixi.ExchRate` für die Datenbank-Kursquelle (`DatabaseCurrencyExchRateSourceId`) und die Hauswährung geteilt, zugeordnet über Kursdatum und Währung des Rechnungskurses. `dbCurrency` enthält dann den Code der Datenbankwährung. Andernfalls werden die Beträge wie gespeichert summiert und `dbCurrency` ist NULL.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `fromDate` | datetime | Nein | Beginn des Auswertungszeitraums. Standard ist der erste Tag des Vormonats von `toDate`; wird auf `toDate` gesetzt, falls später. Bestimmt, welchen Zeitraum jeder Wert abdeckt (siehe Beschreibung). |\n| `toDate` | datetime | Nein | Stichtag mit Uhrzeit (Ende des Zeitraums). Standard ist das aktuelle Datum mit Uhrzeit. |\n| `ShopID` | varchar(3) | Nein | Shop-Filter: Nur Rechnungen von Kunden mit einer Adresse dieses Shops werden gezählt. Leer bedeutet alle Shops. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; die Werte können nicht festgeschriebene Daten enthalten.\n- Die Werte werden als Zeichenketten (`varchar(30)`) geliefert. Ein Wert ist NULL (Element fehlt in der Zeile), wenn keine Rechnung in den Zeitraum fällt, z. B. sind `TurnoverNetGivenDate` und `TurnoverNetDayBefore` NULL, wenn `fromDate` im selben Monat wie `toDate` liegt, aber weder auf diesem Tag noch auf dem Vortag. `TurnoverNetPreviousMonth` ist NULL, wenn `fromDate` im laufenden Monat liegt.\n- Ein `fromDate` vor dem Beginn des Vormonats hat keine zusätzliche Wirkung, da ältere Rechnungen nie geladen werden.\n- Im Mehrwährungsmodus werden Rechnungen ohne passenden Wechselkurs-Datensatz (oder ohne `ExchRateId`) wegen Inner Joins stillschweigend ausgeschlossen. Die Anzahl der Nachkommastellen hängt vom Datentyp von `ExchRate` ab, der hier nicht sichtbar ist.\n- Fehlt die Einstellung `MultiCurrencyEnabled` (NULL), wird trotzdem der Umrechnungszweig ausgeführt, `dbCurrency` jedoch als NULL geliefert.\n- Bei einem SQL-Fehler wird nur die Meldung per PRINT ausgegeben und `-1` zurückgegeben; es wird keine Ergebnismenge geliefert.\n- Die temporäre Tabelle wird über `util.TempTableDrop` gelöscht (Definition nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportTurnover"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1523.40\n 4210.75\n 58320.10\n 112845.60\n EUR\n \n"
}
]
}
]
},
{
"name": "Returns",
"item": [
{
"name": "pixiAddReturnCaseLine",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n 1\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Fügt einem bestehenden Retourenfall eine Zeile für eine Rechnungsposition hinzu oder legt einen neuen leeren Retourenfall an, wenn keine Retourenfall-ID übergeben wird.\n\nDas Verhalten hängt von `RET_ID` ab.\n\n**`RET_ID` ist `NULL` oder `0`**\n\n- `pixiCreateReturnCase` wird mit `ReturnDate`, `ReceiversComment` und `Employee` ausgeführt. Dabei wird ein neuer Retourenfall-Kopf in `RET_CASES` mit Status `NEW` angelegt, und dessen `RET_ID` und `RET_NUMBER` werden zurückgegeben.\n- **Es wird in diesem Fall keine Retourenzeile angelegt.** Die neue ID wird intern nicht übernommen. Für die Zeile muss der Aufruf mit der zurückgegebenen `RET_ID` wiederholt werden.\n\n**`RET_ID` ist gesetzt (nicht `0`)**\n\nEine Zeile wird nur dann in `RET_CASE_LINES` eingefügt, wenn alle folgenden Bedingungen erfüllt sind:\n\n- die Rechnungsposition `InvLineKey` existiert und hat `ItemQty > 0`;\n- `ItemQty >= QuantityToReturn`;\n- die zugehörige Auftragsposition hat den Status `AUS`;\n- es gibt keine Gutschrift, die sich auf dieselbe Rechnung bezieht (`RefToInvoiceKey`) und eine Position zur selben Auftragsposition enthält.\n\nDie neue Zeile erhält folgende Werte:\n\n- Status `AOK` bei `ItemOk = 1`, sonst `DAM`;\n- Kundenkommentar, Empfängerkommentar und Retourengrund, wobei `NULL` als Leerstring gespeichert wird;\n- die Menge `QuantityToReturn` und den Verweis auf die Rechnungsposition;\n- Anlagedatum `GETDATE()` und Anlage-Mitarbeiter ` (API)` bzw. `API`, wenn kein Mitarbeiter angegeben ist.\n\nAnschließend wird immer eine Zeile mit der Retourenfall-ID und der ID der neuen Zeile geliefert. Wurde wegen einer nicht erfüllten Bedingung keine Zeile eingefügt, ist `RET_LINE_ID` `NULL`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvLineKey` | int | Ja | Schlüssel der Rechnungsposition (`Invlines.InvLineKey`), die retourniert wird. |\n| `QuantityToReturn` | int | Ja | Retournierte Menge. Sie darf die berechnete Menge `ItemQty` nicht übersteigen. |\n| `ItemOk` | bit | Nein | Zustand des retournierten Artikels. Bestimmt den Status der Zeile. |\n| `RET_ID` | int | Nein | ID des bestehenden Retourenfalls, dem die Zeile hinzugefügt wird. Bei `NULL` oder `0` wird stattdessen ein neuer leerer Retourenfall angelegt, ohne Zeile. |\n| `ReturnReason` | varchar(2048) | Nein | Retourengrund, der in der Zeile gespeichert wird. |\n| `CustomersComment` | varchar(2048) | Nein | Kommentar des Kunden, wird in der Zeile gespeichert. |\n| `ReceiversComment` | varchar(2048) | Nein | Kommentar des annehmenden Mitarbeiters. Wird im neuen Retourenfall-Kopf bzw. beim Hinzufügen einer Zeile in der Zeile gespeichert. |\n| `Employee` | varchar(50) | Nein | Mitarbeiterkürzel. Wird als ` (API)` gespeichert bzw. als `API`, wenn leer. |\n| `ReturnDate` | datetime | Nein | Retourendatum eines neu angelegten Retourenfalls, Standard ist das aktuelle Datum. Wird ignoriert, wenn `RET_ID` angegeben ist. |\n\n- **Stolperfalle:** Ohne `RET_ID` wird nur ein leerer Retourenfall angelegt. `InvLineKey`, `QuantityToReturn`, `ItemOk`, `ReturnReason` und `CustomersComment` werden dann ignoriert. Die zurückgegebene `RET_ID` muss in einem zweiten Aufruf verwendet werden.\n- Bei nicht erfüllten Bedingungen wird kein Fehler gemeldet. Ob keine Zeile eingefügt wurde, lässt sich daran erkennen, dass `RET_LINE_ID` `NULL` ist.\n- Es wird nicht geprüft, ob die Rechnungsposition bereits in einer anderen Retourenzeile enthalten ist. Wiederholte Aufrufe können mehrere Retourenzeilen zur selben Rechnungsposition anlegen, solange die jeweilige Menge `ItemQty` nicht übersteigt.\n- Es wird nicht geprüft, ob die angegebene `RET_ID` existiert, und negative Mengen werden nicht abgewiesen.\n- `ReturnDate` wird nur beim Anlegen eines neuen Retourenfalls verwendet.\n- `ReceiversComment` wird beim Anlegen eines Retourenfalls im Kopf gespeichert und beim Hinzufügen einer Zeile in der Zeile.\n- Ist `ItemOk` `NULL`, erhält die Zeile den Status `DAM`.\n- Rechnungs- und Auftragspositionen werden mit `NOLOCK` gelesen.\n- Es wird keine explizite Transaktion verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAddReturnCaseLine"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n 1\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Fügt einem bestehenden Retourenfall eine Zeile für eine Rechnungsposition hinzu oder legt einen neuen leeren Retourenfall an, wenn keine Retourenfall-ID übergeben wird.\n\nDas Verhalten hängt von `RET_ID` ab.\n\n**`RET_ID` ist `NULL` oder `0`**\n\n- `pixiCreateReturnCase` wird mit `ReturnDate`, `ReceiversComment` und `Employee` ausgeführt. Dabei wird ein neuer Retourenfall-Kopf in `RET_CASES` mit Status `NEW` angelegt, und dessen `RET_ID` und `RET_NUMBER` werden zurückgegeben.\n- **Es wird in diesem Fall keine Retourenzeile angelegt.** Die neue ID wird intern nicht übernommen. Für die Zeile muss der Aufruf mit der zurückgegebenen `RET_ID` wiederholt werden.\n\n**`RET_ID` ist gesetzt (nicht `0`)**\n\nEine Zeile wird nur dann in `RET_CASE_LINES` eingefügt, wenn alle folgenden Bedingungen erfüllt sind:\n\n- die Rechnungsposition `InvLineKey` existiert und hat `ItemQty > 0`;\n- `ItemQty >= QuantityToReturn`;\n- die zugehörige Auftragsposition hat den Status `AUS`;\n- es gibt keine Gutschrift, die sich auf dieselbe Rechnung bezieht (`RefToInvoiceKey`) und eine Position zur selben Auftragsposition enthält.\n\nDie neue Zeile erhält folgende Werte:\n\n- Status `AOK` bei `ItemOk = 1`, sonst `DAM`;\n- Kundenkommentar, Empfängerkommentar und Retourengrund, wobei `NULL` als Leerstring gespeichert wird;\n- die Menge `QuantityToReturn` und den Verweis auf die Rechnungsposition;\n- Anlagedatum `GETDATE()` und Anlage-Mitarbeiter ` (API)` bzw. `API`, wenn kein Mitarbeiter angegeben ist.\n\nAnschließend wird immer eine Zeile mit der Retourenfall-ID und der ID der neuen Zeile geliefert. Wurde wegen einer nicht erfüllten Bedingung keine Zeile eingefügt, ist `RET_LINE_ID` `NULL`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvLineKey` | int | Ja | Schlüssel der Rechnungsposition (`Invlines.InvLineKey`), die retourniert wird. |\n| `QuantityToReturn` | int | Ja | Retournierte Menge. Sie darf die berechnete Menge `ItemQty` nicht übersteigen. |\n| `ItemOk` | bit | Nein | Zustand des retournierten Artikels. Bestimmt den Status der Zeile. |\n| `RET_ID` | int | Nein | ID des bestehenden Retourenfalls, dem die Zeile hinzugefügt wird. Bei `NULL` oder `0` wird stattdessen ein neuer leerer Retourenfall angelegt, ohne Zeile. |\n| `ReturnReason` | varchar(2048) | Nein | Retourengrund, der in der Zeile gespeichert wird. |\n| `CustomersComment` | varchar(2048) | Nein | Kommentar des Kunden, wird in der Zeile gespeichert. |\n| `ReceiversComment` | varchar(2048) | Nein | Kommentar des annehmenden Mitarbeiters. Wird im neuen Retourenfall-Kopf bzw. beim Hinzufügen einer Zeile in der Zeile gespeichert. |\n| `Employee` | varchar(50) | Nein | Mitarbeiterkürzel. Wird als ` (API)` gespeichert bzw. als `API`, wenn leer. |\n| `ReturnDate` | datetime | Nein | Retourendatum eines neu angelegten Retourenfalls, Standard ist das aktuelle Datum. Wird ignoriert, wenn `RET_ID` angegeben ist. |\n\n- **Stolperfalle:** Ohne `RET_ID` wird nur ein leerer Retourenfall angelegt. `InvLineKey`, `QuantityToReturn`, `ItemOk`, `ReturnReason` und `CustomersComment` werden dann ignoriert. Die zurückgegebene `RET_ID` muss in einem zweiten Aufruf verwendet werden.\n- Bei nicht erfüllten Bedingungen wird kein Fehler gemeldet. Ob keine Zeile eingefügt wurde, lässt sich daran erkennen, dass `RET_LINE_ID` `NULL` ist.\n- Es wird nicht geprüft, ob die Rechnungsposition bereits in einer anderen Retourenzeile enthalten ist. Wiederholte Aufrufe können mehrere Retourenzeilen zur selben Rechnungsposition anlegen, solange die jeweilige Menge `ItemQty` nicht übersteigt.\n- Es wird nicht geprüft, ob die angegebene `RET_ID` existiert, und negative Mengen werden nicht abgewiesen.\n- `ReturnDate` wird nur beim Anlegen eines neuen Retourenfalls verwendet.\n- `ReceiversComment` wird beim Anlegen eines Retourenfalls im Kopf gespeichert und beim Hinzufügen einer Zeile in der Zeile.\n- Ist `ItemOk` `NULL`, erhält die Zeile den Status `DAM`.\n- Rechnungs- und Auftragspositionen werden mit `NOLOCK` gelesen.\n- Es wird keine explizite Transaktion verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAddReturnCaseLine"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4711\n 98231\n \n"
}
]
},
{
"name": "pixiCreateReturn",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE2024001234\n 501234;501235;\n 1;2;\n 19.99;5.50;\n U\n \n \n Max Mustermann\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine Retouren-Gutschrift für ausgewählte Positionen einer Rechnung an, setzt die Auftragspositionen auf retourniert und bucht die Gutschrift auf das Kundenkonto.\n\nDas API-Gegenstück zum Retouren-Assistenten im Kundenservice. Die Werte werden aufbereitet und anschließend die interne Prozedur `Pixi_CreateReturn` aufgerufen.\n\n**Eingabelisten**\n- `InvoiceLines`, `Quantities` und `Prices` sind parallele, mit `;` getrennte Listen (ein fehlendes abschließendes `;` wird ergänzt). Eintrag *n* jeder Liste gehört zur selben Rechnungsposition.\n- `Prices` sind Brutto-Einzelpreise. Der Nettopreis wird je Position als `Price / (1 + TaxRate/100)` mit dem Steuersatz der Rechnungsposition berechnet.\n- Jeder Rechnungspositionsschlüssel wird in die zugehörige Auftragsposition (`Invlines.OrderLineRef`) übersetzt.\n\n**Ablauf**\n1. Die erste Rechnungsposition in `InvoiceLines` bestimmt das Lieferland sowie die Einstellungen `VATinShipCost` / `ChargeHighVATInShipCost` der Originalrechnung.\n2. Gibt es für das Land heute keinen gültigen MwSt-Satz: Bei aktivem *Force Country VAT* schlägt der Aufruf fehl, sonst wird ein Standard-MwSt-Satz für das Land angelegt (`Pixi_InsertDefaultVATRateForCountry`).\n3. Der Rechnungskopf wird über `InvoiceNr` gelesen: Kunde, Rechnungs- und Lieferadresse, Gutschein, Währung (die Retoure erfolgt immer in Auftragswährung).\n4. Standardwerte: `ShipCost` = negative Versandkosten der Rechnung (volle Erstattung); `Voucher_Amount` = Gutscheinsumme der Rechnung (brutto bei `B2C`, sonst netto).\n5. Gesamtbetrag: minus Summe aus Menge × Preis, plus `ShipCost`, minus `Voucher_Amount`, plus `ReturnCostsAmount`. Würden die Rücksendekosten den Betrag positiv machen, werden sie so reduziert, dass der Betrag 0 ergibt.\n6. `Pixi_CreateReturn` legt die Gutschrift an: Gutgeschrieben werden nur Positionen der referenzierten Rechnung, deren Auftragsposition den Status `AUS` hat. Bei geringerer Menge wird die Auftragsposition vorher geteilt. Die gutgeschriebenen Auftragspositionen erhalten den Status `RET`, die Gutschrift wird auf das Kundenkonto gebucht, Positionen des Retourenfalls `ReturnCaseID` werden geschlossen und ein Historieneintrag geschrieben, passende `pixi.Return`-Datensätze im Status *Erhalten* werden auf *Gutgeschrieben* gesetzt und das Ereignis `InvoiceCreated` wird veröffentlicht.\n7. Bei `MarkReturnDocumentForPrinting` = 1 wird `TimesPrinted` der neuen Gutschrift auf 0 gesetzt, damit sie erneut gedruckt wird.\n\nDer Aufruf liefert den Kopf der neuen Gutschrift als eine Zeile.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Ja | Nummer der Originalrechnung, die retourniert wird. |\n| `InvoiceLines` | varchar(max) | Ja | Mit Semikolon getrennte Liste der gutzuschreibenden Rechnungspositionsschlüssel (`InvLineKey`). Der erste Schlüssel bestimmt die Lieferlandprüfung. |\n| `Quantities` | varchar(max) | Ja | Mit Semikolon getrennte Retourenmengen, je Eintrag in `InvoiceLines` eine. |\n| `Prices` | varchar(max) | Ja | Mit Semikolon getrennte Brutto-Einzelpreise für die Gutschrift, je Eintrag in `InvoiceLines` einer. |\n| `PaymentType` | char(1) | Ja | Zahlungsartcode für die Erstattung, wird an der Gutschrift gespeichert. |\n| `Account` | varchar(10) | Nein | Kontonummer für die Erstattung; Leerzeichen werden entfernt, der Wert wird an der Rechnungsadresse gespeichert. |\n| `BLZ` | char(8) | Nein | Bankleitzahl für die Erstattung; Leerzeichen werden entfernt. |\n| `AccountName` | varchar(27) | Ja | Name des Kontoinhabers. |\n| `ShipCost` | money | Nein | Gutzuschreibende Versandkosten als negativer Wert. NULL erstattet die vollen Versandkosten der Rechnung; 0 erstattet keine Versandkosten. |\n| `Note` | varchar(255) | Nein | Notiz zur Gutschrift. |\n| `ReturnReason` | varchar(100) | Nein | Retourengrund, der an der Gutschrift gespeichert wird. |\n| `CreateDate` | datetime | Nein | Erstellungsdatum; Standard ist jetzt. Wird weitergegeben, von der internen Prozedur aber nicht verwendet. |\n| `CreateEmp` | varchar(50) | Nein | Benutzername, der als Ersteller der Gutschrift und aller Änderungen gespeichert wird. |\n| `InvoiceDate` | datetime | Nein | Datum der Gutschrift; wird in der internen Prozedur durch das aktuelle Datum ersetzt und hat daher keine Wirkung. |\n| `ReturnClosed` | bit | Nein | Ob die Retoure als abgeschlossen markiert wird. |\n| `ReturnCaseID` | int | Nein | ID eines Returns-&-Repairs-Falls; dessen Positionen zu den gutgeschriebenen Rechnungspositionen werden geschlossen und ein Historieneintrag geschrieben. |\n| `CreateDTAUS` | bit | Nein | Ob für die Erstattung ein DTAUS/eine Überweisung erzeugt werden soll. Wird bei `DoNotRefund` = 1 ignoriert (0). |\n| `DoNotRefund` | bit | Nein | Bei 1 wird die Gutschrift nicht über das Kundenkonto erstattet. |\n| `CAComment` | varchar(1000) | Nein | Kommentar, der im Kundenkonto-Historieneintrag der Gutschrift gespeichert wird. |\n| `IBAN` | varchar(30) | Nein | IBAN für die Erstattung, wird an der Rechnungsadresse gespeichert. |\n| `BIC` | varchar(11) | Nein | BIC für die Erstattung, wird an der Rechnungsadresse gespeichert. |\n| `LanguageId` | int | Nein | Sprache des übersetzten Historientexts im Retourenfall. |\n| `ReturnCostsAmount` | money | Nein | Dem Kunden berechnete Rücksendekosten (positiver Wert). Jeder Wert ungleich 0 aktiviert Rücksendekosten; wird reduziert, falls er den Gutschriftbetrag übersteigen würde. |\n| `Voucher_Amount` | money | Nein | Gutscheinbetrag, der von der Gutschrift abgezogen wird. NULL verwendet die Gutscheinsumme der Rechnung (brutto bei B2C, sonst netto). |\n| `MarkReturnDocumentForPrinting` | bit | Nein | Bei 1 wird die neue Gutschrift zum Drucken markiert (`TimesPrinted` = 0). |\n\n- Läuft in einer eigenen Transaktion (bzw. einem Savepoint, falls bereits eine Transaktion offen ist). Fehler werden abgefangen, die Transaktion wird zurückgerollt und der Fehler mit `log.InsertError` (nicht beigefügt) protokolliert; ob der Fehler an den Aufrufer weitergegeben wird, ist im Code nicht erkennbar. Ein fehlgeschlagener Aufruf kann daher wie ein Aufruf mit leerem Ergebnis aussehen.\n- In `Prices` `.` als Dezimaltrenner verwenden; die Werte werden nach `money` konvertiert.\n- Der Listenparser entfernt den verarbeiteten Schlüssel per `REPLACE`. Doppelte Schlüssel oder ein Schlüssel, der das Ende eines späteren Schlüssels bildet (z. B. `23;123;`), stören das Parsen. Jede Rechnungsposition nur einmal übergeben.\n- Positionen, deren Auftragsposition nicht im Status `AUS` ist oder die nicht zur Rechnung `InvoiceNr` gehören, werden stillschweigend übersprungen, fließen aber trotzdem in den berechneten Gesamtbetrag ein.\n- `CreateDate` und `InvoiceDate` haben keine Wirkung: Das Gutschriftsdatum ist immer das aktuelle Datum.\n- `DoNotRefund` = 1 erzwingt `CreateDTAUS` = 0.\n- `TimesPrinted` in der gelieferten Zeile zeigt den Wert vor Anwendung von `MarkReturnDocumentForPrinting`.\n- Die Spalte `1SS` ist kein gültiger XML-Elementname; stattdessen `OneSS` verwenden.\n- Lesezugriffe erfolgen mit `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateReturn"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE2024001234\n 501234;501235;\n 1;2;\n 19.99;5.50;\n U\n \n \n Max Mustermann\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine Retouren-Gutschrift für ausgewählte Positionen einer Rechnung an, setzt die Auftragspositionen auf retourniert und bucht die Gutschrift auf das Kundenkonto.\n\nDas API-Gegenstück zum Retouren-Assistenten im Kundenservice. Die Werte werden aufbereitet und anschließend die interne Prozedur `Pixi_CreateReturn` aufgerufen.\n\n**Eingabelisten**\n- `InvoiceLines`, `Quantities` und `Prices` sind parallele, mit `;` getrennte Listen (ein fehlendes abschließendes `;` wird ergänzt). Eintrag *n* jeder Liste gehört zur selben Rechnungsposition.\n- `Prices` sind Brutto-Einzelpreise. Der Nettopreis wird je Position als `Price / (1 + TaxRate/100)` mit dem Steuersatz der Rechnungsposition berechnet.\n- Jeder Rechnungspositionsschlüssel wird in die zugehörige Auftragsposition (`Invlines.OrderLineRef`) übersetzt.\n\n**Ablauf**\n1. Die erste Rechnungsposition in `InvoiceLines` bestimmt das Lieferland sowie die Einstellungen `VATinShipCost` / `ChargeHighVATInShipCost` der Originalrechnung.\n2. Gibt es für das Land heute keinen gültigen MwSt-Satz: Bei aktivem *Force Country VAT* schlägt der Aufruf fehl, sonst wird ein Standard-MwSt-Satz für das Land angelegt (`Pixi_InsertDefaultVATRateForCountry`).\n3. Der Rechnungskopf wird über `InvoiceNr` gelesen: Kunde, Rechnungs- und Lieferadresse, Gutschein, Währung (die Retoure erfolgt immer in Auftragswährung).\n4. Standardwerte: `ShipCost` = negative Versandkosten der Rechnung (volle Erstattung); `Voucher_Amount` = Gutscheinsumme der Rechnung (brutto bei `B2C`, sonst netto).\n5. Gesamtbetrag: minus Summe aus Menge × Preis, plus `ShipCost`, minus `Voucher_Amount`, plus `ReturnCostsAmount`. Würden die Rücksendekosten den Betrag positiv machen, werden sie so reduziert, dass der Betrag 0 ergibt.\n6. `Pixi_CreateReturn` legt die Gutschrift an: Gutgeschrieben werden nur Positionen der referenzierten Rechnung, deren Auftragsposition den Status `AUS` hat. Bei geringerer Menge wird die Auftragsposition vorher geteilt. Die gutgeschriebenen Auftragspositionen erhalten den Status `RET`, die Gutschrift wird auf das Kundenkonto gebucht, Positionen des Retourenfalls `ReturnCaseID` werden geschlossen und ein Historieneintrag geschrieben, passende `pixi.Return`-Datensätze im Status *Erhalten* werden auf *Gutgeschrieben* gesetzt und das Ereignis `InvoiceCreated` wird veröffentlicht.\n7. Bei `MarkReturnDocumentForPrinting` = 1 wird `TimesPrinted` der neuen Gutschrift auf 0 gesetzt, damit sie erneut gedruckt wird.\n\nDer Aufruf liefert den Kopf der neuen Gutschrift als eine Zeile.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Ja | Nummer der Originalrechnung, die retourniert wird. |\n| `InvoiceLines` | varchar(max) | Ja | Mit Semikolon getrennte Liste der gutzuschreibenden Rechnungspositionsschlüssel (`InvLineKey`). Der erste Schlüssel bestimmt die Lieferlandprüfung. |\n| `Quantities` | varchar(max) | Ja | Mit Semikolon getrennte Retourenmengen, je Eintrag in `InvoiceLines` eine. |\n| `Prices` | varchar(max) | Ja | Mit Semikolon getrennte Brutto-Einzelpreise für die Gutschrift, je Eintrag in `InvoiceLines` einer. |\n| `PaymentType` | char(1) | Ja | Zahlungsartcode für die Erstattung, wird an der Gutschrift gespeichert. |\n| `Account` | varchar(10) | Nein | Kontonummer für die Erstattung; Leerzeichen werden entfernt, der Wert wird an der Rechnungsadresse gespeichert. |\n| `BLZ` | char(8) | Nein | Bankleitzahl für die Erstattung; Leerzeichen werden entfernt. |\n| `AccountName` | varchar(27) | Ja | Name des Kontoinhabers. |\n| `ShipCost` | money | Nein | Gutzuschreibende Versandkosten als negativer Wert. NULL erstattet die vollen Versandkosten der Rechnung; 0 erstattet keine Versandkosten. |\n| `Note` | varchar(255) | Nein | Notiz zur Gutschrift. |\n| `ReturnReason` | varchar(100) | Nein | Retourengrund, der an der Gutschrift gespeichert wird. |\n| `CreateDate` | datetime | Nein | Erstellungsdatum; Standard ist jetzt. Wird weitergegeben, von der internen Prozedur aber nicht verwendet. |\n| `CreateEmp` | varchar(50) | Nein | Benutzername, der als Ersteller der Gutschrift und aller Änderungen gespeichert wird. |\n| `InvoiceDate` | datetime | Nein | Datum der Gutschrift; wird in der internen Prozedur durch das aktuelle Datum ersetzt und hat daher keine Wirkung. |\n| `ReturnClosed` | bit | Nein | Ob die Retoure als abgeschlossen markiert wird. |\n| `ReturnCaseID` | int | Nein | ID eines Returns-&-Repairs-Falls; dessen Positionen zu den gutgeschriebenen Rechnungspositionen werden geschlossen und ein Historieneintrag geschrieben. |\n| `CreateDTAUS` | bit | Nein | Ob für die Erstattung ein DTAUS/eine Überweisung erzeugt werden soll. Wird bei `DoNotRefund` = 1 ignoriert (0). |\n| `DoNotRefund` | bit | Nein | Bei 1 wird die Gutschrift nicht über das Kundenkonto erstattet. |\n| `CAComment` | varchar(1000) | Nein | Kommentar, der im Kundenkonto-Historieneintrag der Gutschrift gespeichert wird. |\n| `IBAN` | varchar(30) | Nein | IBAN für die Erstattung, wird an der Rechnungsadresse gespeichert. |\n| `BIC` | varchar(11) | Nein | BIC für die Erstattung, wird an der Rechnungsadresse gespeichert. |\n| `LanguageId` | int | Nein | Sprache des übersetzten Historientexts im Retourenfall. |\n| `ReturnCostsAmount` | money | Nein | Dem Kunden berechnete Rücksendekosten (positiver Wert). Jeder Wert ungleich 0 aktiviert Rücksendekosten; wird reduziert, falls er den Gutschriftbetrag übersteigen würde. |\n| `Voucher_Amount` | money | Nein | Gutscheinbetrag, der von der Gutschrift abgezogen wird. NULL verwendet die Gutscheinsumme der Rechnung (brutto bei B2C, sonst netto). |\n| `MarkReturnDocumentForPrinting` | bit | Nein | Bei 1 wird die neue Gutschrift zum Drucken markiert (`TimesPrinted` = 0). |\n\n- Läuft in einer eigenen Transaktion (bzw. einem Savepoint, falls bereits eine Transaktion offen ist). Fehler werden abgefangen, die Transaktion wird zurückgerollt und der Fehler mit `log.InsertError` (nicht beigefügt) protokolliert; ob der Fehler an den Aufrufer weitergegeben wird, ist im Code nicht erkennbar. Ein fehlgeschlagener Aufruf kann daher wie ein Aufruf mit leerem Ergebnis aussehen.\n- In `Prices` `.` als Dezimaltrenner verwenden; die Werte werden nach `money` konvertiert.\n- Der Listenparser entfernt den verarbeiteten Schlüssel per `REPLACE`. Doppelte Schlüssel oder ein Schlüssel, der das Ende eines späteren Schlüssels bildet (z. B. `23;123;`), stören das Parsen. Jede Rechnungsposition nur einmal übergeben.\n- Positionen, deren Auftragsposition nicht im Status `AUS` ist oder die nicht zur Rechnung `InvoiceNr` gehören, werden stillschweigend übersprungen, fließen aber trotzdem in den berechneten Gesamtbetrag ein.\n- `CreateDate` und `InvoiceDate` haben keine Wirkung: Das Gutschriftsdatum ist immer das aktuelle Datum.\n- `DoNotRefund` = 1 erzwingt `CreateDTAUS` = 0.\n- `TimesPrinted` in der gelieferten Zeile zeigt den Wert vor Anwendung von `MarkReturnDocumentForPrinting`.\n- Die Spalte `1SS` ist kein gültiger XML-Elementname; stattdessen `OneSS` verwenden.\n- Lesezugriffe erfolgen mit `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateReturn"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 734521\n GS2024000871\n 2024-05-14T10:22:31\n 88123\n 145002\n -30.89\n U\n EUR\n RE2024001234\n 731990\n 1\n Wrong size\n Y\n true\n B2C\n \n"
}
]
},
{
"name": "pixiCreateReturnCase",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-14T10:30:00\n Package received damaged, customer requests refund.\n JD\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen neuen Retourenfall mit Status NEW an und liefert dessen ID und Retourennummer.\n\nFügt einen neuen Datensatz in `RET_CASES` ein und liefert die Kennungen des neuen Retourenfalls.\n\nDer neue Datensatz wird wie folgt befüllt:\n\n- `CreateDate`: aktuelles Datum und Uhrzeit des Servers.\n- `CreateEmp`: der Wert von `Employee`, gefolgt von ` (API)`. Ist `Employee` NULL, wird der Wert `API` verwendet.\n- `RETURN_DATE`: der Wert von `ReturnDate`. Ist dieser NULL, werden aktuelles Datum und Uhrzeit des Servers verwendet.\n- `STATUS`: immer `NEW`.\n- `RECEIVERS_COMMENT`: der Wert von `ReceiversComment`.\n\nNach dem Einfügen wird der neue Datensatz über seinen Identity-Wert (`SCOPE_IDENTITY()`) gelesen und eine Zeile mit `RET_ID` und `RET_NUMBER` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ReturnDate` | datetime | Ja | Datum der Retoure. Bei NULL werden aktuelles Datum und Uhrzeit des Servers verwendet. |\n| `ReceiversComment` | varchar(max) | Ja | Kommentar des Empfängers, wird in `RECEIVERS_COMMENT` gespeichert. Darf NULL sein. |\n| `Employee` | varchar(50) | Ja | Mitarbeiterkürzel. Wird mit dem Zusatz ` (API)` als Ersteller gespeichert; bei NULL wird `API` gespeichert. |\n\n- Alle drei Parameter haben keinen SQL-Standardwert und müssen im Request übergeben werden. NULL-Werte werden akzeptiert: `Employee` und `ReturnDate` werden wie beschrieben ersetzt; `ReceiversComment` wird als NULL gespeichert.\n- Der Aufruf legt nur den Kopf des Retourenfalls an. Es werden kein Auftrag, keine Artikel und keine Retourenpositionen verknüpft; dies muss über andere Aufrufe erfolgen.\n- `RET_NUMBER` wird von dieser Prozedur nicht gesetzt. Vermutlich wird der Wert von der Datenbank erzeugt (Standardwert, berechnete Spalte oder Trigger auf `RET_CASES`), was im Code nicht sichtbar ist.\n- Der Zusatz ` (API)` verlängert `Employee` um 6 Zeichen; ob das Ergebnis in `CreateEmp` passt, hängt von der Spaltenlänge ab, die im Code nicht sichtbar ist.\n- Die Ergebniszeile wird mit `NOLOCK` gelesen. Einfügen und Lesen laufen nicht in einer expliziten Transaktion.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateReturnCase"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-14T10:30:00\n Package received damaged, customer requests refund.\n JD\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen neuen Retourenfall mit Status NEW an und liefert dessen ID und Retourennummer.\n\nFügt einen neuen Datensatz in `RET_CASES` ein und liefert die Kennungen des neuen Retourenfalls.\n\nDer neue Datensatz wird wie folgt befüllt:\n\n- `CreateDate`: aktuelles Datum und Uhrzeit des Servers.\n- `CreateEmp`: der Wert von `Employee`, gefolgt von ` (API)`. Ist `Employee` NULL, wird der Wert `API` verwendet.\n- `RETURN_DATE`: der Wert von `ReturnDate`. Ist dieser NULL, werden aktuelles Datum und Uhrzeit des Servers verwendet.\n- `STATUS`: immer `NEW`.\n- `RECEIVERS_COMMENT`: der Wert von `ReceiversComment`.\n\nNach dem Einfügen wird der neue Datensatz über seinen Identity-Wert (`SCOPE_IDENTITY()`) gelesen und eine Zeile mit `RET_ID` und `RET_NUMBER` zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ReturnDate` | datetime | Ja | Datum der Retoure. Bei NULL werden aktuelles Datum und Uhrzeit des Servers verwendet. |\n| `ReceiversComment` | varchar(max) | Ja | Kommentar des Empfängers, wird in `RECEIVERS_COMMENT` gespeichert. Darf NULL sein. |\n| `Employee` | varchar(50) | Ja | Mitarbeiterkürzel. Wird mit dem Zusatz ` (API)` als Ersteller gespeichert; bei NULL wird `API` gespeichert. |\n\n- Alle drei Parameter haben keinen SQL-Standardwert und müssen im Request übergeben werden. NULL-Werte werden akzeptiert: `Employee` und `ReturnDate` werden wie beschrieben ersetzt; `ReceiversComment` wird als NULL gespeichert.\n- Der Aufruf legt nur den Kopf des Retourenfalls an. Es werden kein Auftrag, keine Artikel und keine Retourenpositionen verknüpft; dies muss über andere Aufrufe erfolgen.\n- `RET_NUMBER` wird von dieser Prozedur nicht gesetzt. Vermutlich wird der Wert von der Datenbank erzeugt (Standardwert, berechnete Spalte oder Trigger auf `RET_CASES`), was im Code nicht sichtbar ist.\n- Der Zusatz ` (API)` verlängert `Employee` um 6 Zeichen; ob das Ergebnis in `CreateEmp` passt, hängt von der Spaltenlänge ab, die im Code nicht sichtbar ist.\n- Die Ergebniszeile wird mit `NOLOCK` gelesen. Einfügen und Lesen laufen nicht in einer expliziten Transaktion.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateReturnCase"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1523\n R001523\n \n"
}
]
},
{
"name": "pixiGetItemsTopReturnReason",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, deren häufigster Retourengrund öfter als ein angegebener Schwellwert vorkommt, zusammen mit diesem Grund und seiner Anzahl.\n\nWertet die auf Rechnungspositionen erfassten Retourengründe aus und listet Artikel auf, die wiederholt aus demselben Grund retourniert werden.\n\nFür jeden Artikel in `Items` werden alle Rechnungspositionen (`invlines`, verknüpft mit `invoices` über `InvoiceRef = InvoiceKey`) betrachtet, die auf den Artikel verweisen (`ItemRef`) und einen `ReturnReason` ungleich NULL besitzen. Diese Positionen werden nach `ReturnReason` gruppiert; der Grund mit der höchsten Anzahl an Positionen gilt als häufigster Retourengrund des Artikels.\n\n- Ein Artikel wird nur geliefert, wenn die Anzahl seines häufigsten Retourengrunds **echt größer** als `MinNrOfReturns` ist. Beim Standardwert `2` muss der Grund mindestens dreimal vorkommen.\n- Artikel ohne Rechnungsposition mit Retourengrund werden nicht geliefert.\n- `ReturnReason` enthält den häufigsten Grund, `NrOfReturns` die Anzahl der Rechnungspositionen mit diesem Grund (nicht die Gesamtzahl aller Retouren des Artikels).\n\nDas Ergebnis ist nach Artikelname sortiert. Es gibt kein Paging.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `MinNrOfReturns` | int | Nein | Schwellwert für die Anzahl der Rechnungspositionen mit dem häufigsten Retourengrund des Artikels. Nur Artikel, deren Anzahl echt größer als dieser Wert ist, werden geliefert. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- Gezählt werden Rechnungspositionen, nicht Mengen; eine Position mit mehreren retournierten Einheiten zählt einmal.\n- Haben zwei Gründe dieselbe höchste Anzahl, ist nicht festgelegt, welcher geliefert wird (keine eindeutige Sortierung).\n- Für jeden Artikel in `Items` werden korrelierte Unterabfragen ausgeführt, was bei großen Datenbanken langsam sein kann.\n- Der Kopfkommentar der Prozedur (\"Checks pixi* user credentials\") passt nicht zur tatsächlichen Funktion.\n- Die Spaltennamen sind im Code nicht qualifiziert; aus welcher der Tabellen `invoices` oder `invlines` die Spalten `ReturnReason` und `ItemRef` stammen, lässt sich allein aus dem Code nicht bestimmen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemsTopReturnReason"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, deren häufigster Retourengrund öfter als ein angegebener Schwellwert vorkommt, zusammen mit diesem Grund und seiner Anzahl.\n\nWertet die auf Rechnungspositionen erfassten Retourengründe aus und listet Artikel auf, die wiederholt aus demselben Grund retourniert werden.\n\nFür jeden Artikel in `Items` werden alle Rechnungspositionen (`invlines`, verknüpft mit `invoices` über `InvoiceRef = InvoiceKey`) betrachtet, die auf den Artikel verweisen (`ItemRef`) und einen `ReturnReason` ungleich NULL besitzen. Diese Positionen werden nach `ReturnReason` gruppiert; der Grund mit der höchsten Anzahl an Positionen gilt als häufigster Retourengrund des Artikels.\n\n- Ein Artikel wird nur geliefert, wenn die Anzahl seines häufigsten Retourengrunds **echt größer** als `MinNrOfReturns` ist. Beim Standardwert `2` muss der Grund mindestens dreimal vorkommen.\n- Artikel ohne Rechnungsposition mit Retourengrund werden nicht geliefert.\n- `ReturnReason` enthält den häufigsten Grund, `NrOfReturns` die Anzahl der Rechnungspositionen mit diesem Grund (nicht die Gesamtzahl aller Retouren des Artikels).\n\nDas Ergebnis ist nach Artikelname sortiert. Es gibt kein Paging.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `MinNrOfReturns` | int | Nein | Schwellwert für die Anzahl der Rechnungspositionen mit dem häufigsten Retourengrund des Artikels. Nur Artikel, deren Anzahl echt größer als dieser Wert ist, werden geliefert. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- Gezählt werden Rechnungspositionen, nicht Mengen; eine Position mit mehreren retournierten Einheiten zählt einmal.\n- Haben zwei Gründe dieselbe höchste Anzahl, ist nicht festgelegt, welcher geliefert wird (keine eindeutige Sortierung).\n- Für jeden Artikel in `Items` werden korrelierte Unterabfragen ausgeführt, was bei großen Datenbanken langsam sein kann.\n- Der Kopfkommentar der Prozedur (\"Checks pixi* user credentials\") passt nicht zur tatsächlichen Funktion.\n- Die Spaltennamen sind im Code nicht qualifiziert; aus welcher der Tabellen `invoices` oder `invlines` die Spalten `ReturnReason` und `ItemRef` stammen, lässt sich allein aus dem Code nicht bestimmen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemsTopReturnReason"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n 4006381333931\n ART-10452\n Laufschuh Pro 42\n Zu klein\n 7\n \n \n 20817\n 4012345678901\n ART-20817\n Regenjacke M\n Gefällt nicht\n 4\n \n"
}
]
},
{
"name": "pixiGetReturnItems",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 1042\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Positionen eines Retourenfalls mit Artikel, Rechnungsposition, Lagerplatz sowie übersetztem Retourengrund und Qualitätsklassifizierung.\n\nLiefert alle Retourenpositionen (`pixi.ReturnLine`), die zum in `ReturnId` angegebenen Retourenfall gehören.\n\nAblauf:\n\n1. Die Übersetzungen der Codetabellenwerte (`DBObjectName = 'CodeTableValue'`) für die Sprache `LanguageId` werden in eine temporäre Tabelle geladen.\n2. Alle Retourenpositionen des Retourenfalls werden gelesen und verknüpft mit:\n - der Rechnungsposition (`Invlines`) und dem zugehörigen Artikel (`items`), die Artikelnummer, EAN, Artikelname und interne Artikelnummer liefern,\n - dem Retourengrund (`ReasonId`) mit Code und übersetzter Beschreibung,\n - der Qualitätsklassifizierung des Artikels (`ItemQualityClassificationId`) mit Code und übersetzter Beschreibung,\n - dem Lagerbuchungseintrag (`InvBinItemLog`), der Menge, Lager, Lagerplatz, Mindesthaltbarkeitsdatum und Charge liefert.\n\nAlle Verknüpfungen sind Inner Joins: Eine Position erscheint nur, wenn alle referenzierten Datensätze existieren und sowohl für den Retourengrund als auch für die Klassifizierung eine Übersetzung in der angeforderten Sprache vorhanden ist.\n\nEine explizite Sortierung erfolgt nicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ReturnId` | int | Ja | ID des Retourenfalls, dessen Positionen geliefert werden. |\n| `LanguageId` | int | Nein | Sprach-ID für die übersetzten Beschreibungen von Retourengrund und Qualitätsklassifizierung. |\n\n- Die meisten Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden; die Verknüpfung zur Qualitätsklassifizierung (`CodeTableValue` als `ct2`) erfolgt ohne `NOLOCK`.\n- Fehlt für einen Retourengrund oder eine Klassifizierung die Übersetzung in der angegebenen `LanguageId`, fehlt die gesamte Position im Ergebnis. Es sollte eine Sprache verwendet werden, für die Übersetzungen vorhanden sind (Standard `1`).\n- Die temporäre Tabelle wird über `util.TempTableDrop` entfernt; dessen Definition liegt nicht vor.\n- Existiert der Retourenfall nicht oder hat er keine Positionen, wird eine leere Ergebnismenge geliefert; ein Fehler wird nicht ausgelöst.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetReturnItems"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 1042\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Positionen eines Retourenfalls mit Artikel, Rechnungsposition, Lagerplatz sowie übersetztem Retourengrund und Qualitätsklassifizierung.\n\nLiefert alle Retourenpositionen (`pixi.ReturnLine`), die zum in `ReturnId` angegebenen Retourenfall gehören.\n\nAblauf:\n\n1. Die Übersetzungen der Codetabellenwerte (`DBObjectName = 'CodeTableValue'`) für die Sprache `LanguageId` werden in eine temporäre Tabelle geladen.\n2. Alle Retourenpositionen des Retourenfalls werden gelesen und verknüpft mit:\n - der Rechnungsposition (`Invlines`) und dem zugehörigen Artikel (`items`), die Artikelnummer, EAN, Artikelname und interne Artikelnummer liefern,\n - dem Retourengrund (`ReasonId`) mit Code und übersetzter Beschreibung,\n - der Qualitätsklassifizierung des Artikels (`ItemQualityClassificationId`) mit Code und übersetzter Beschreibung,\n - dem Lagerbuchungseintrag (`InvBinItemLog`), der Menge, Lager, Lagerplatz, Mindesthaltbarkeitsdatum und Charge liefert.\n\nAlle Verknüpfungen sind Inner Joins: Eine Position erscheint nur, wenn alle referenzierten Datensätze existieren und sowohl für den Retourengrund als auch für die Klassifizierung eine Übersetzung in der angeforderten Sprache vorhanden ist.\n\nEine explizite Sortierung erfolgt nicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ReturnId` | int | Ja | ID des Retourenfalls, dessen Positionen geliefert werden. |\n| `LanguageId` | int | Nein | Sprach-ID für die übersetzten Beschreibungen von Retourengrund und Qualitätsklassifizierung. |\n\n- Die meisten Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden; die Verknüpfung zur Qualitätsklassifizierung (`CodeTableValue` als `ct2`) erfolgt ohne `NOLOCK`.\n- Fehlt für einen Retourengrund oder eine Klassifizierung die Übersetzung in der angegebenen `LanguageId`, fehlt die gesamte Position im Ergebnis. Es sollte eine Sprache verwendet werden, für die Übersetzungen vorhanden sind (Standard `1`).\n- Die temporäre Tabelle wird über `util.TempTableDrop` entfernt; dessen Definition liegt nicht vor.\n- Existiert der Retourenfall nicht oder hat er keine Positionen, wird eine leere Ergebnismenge geliefert; ein Fehler wird nicht ausgelöst.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetReturnItems"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 5531\n 12\n Item does not fit\n 20871\n 4006381333931\n Running shirt blue M\n 1\n 001\n 3345\n 2026-12-31T00:00:00\n B2024-117\n 889120\n false\n Too small\n Checked, as new\n 2024-05-14T10:22:31\n RS-BLU-M\n SIZE\n A\n As new\n \n"
}
]
},
{
"name": "pixiGetReturns",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine seitenweise Liste von Retouren, die in einem Zeitraum geändert wurden, optional gefiltert nach Status und Rechnungsnummer, inklusive zugehöriger Gutschrift.\n\nLiest Retouren aus der Tabelle `pixi.Return` und liefert eine Zeile pro Retoure.\n\n**Filter**\n- `StatusId`: nur Retouren mit dieser Status-ID. `NULL` liefert alle Status.\n- `InvoiceNr`: Die Rechnungsnummer wird zunächst in den Rechnungsschlüssel aufgelöst. Es werden nur Retouren zu dieser Rechnung geliefert.\n- `ChangeDateFrom` / `ChangeDateTo`: `RecordModifiedOn` der Retoure muss zwischen beiden Werten liegen, die Grenzen eingeschlossen.\n - Ist `ChangeDateFrom` `NULL`, beginnt der Zeitraum um 00:00 Uhr am selben Tag vor einem Monat.\n - Ist `ChangeDateTo` `NULL`, endet der Zeitraum am Ende des heutigen Tages (23:59:59.997).\n\n**Gutschrift**\nDie in der Retoure hinterlegte Gutschrift (`CreditInvoiceId`) wird optional verknüpft. Ihre Nummer und ihr Gesamtbetrag werden als `CreditNumber` und `CreditedAmount` geliefert. Beide sind leer, wenn die Retoure keine Gutschrift hat.\n\n**Paging und Sortierung**\n- Alle passenden Retouren werden aufsteigend nach `Id` durchnummeriert.\n- Geliefert werden Zeilen mit einer Zeilennummer größer als `Offset`, höchstens `RowCount` Zeilen.\n- Das Ergebnis ist nach `Id` sortiert.\n\n**Zusätzliche Daten**\nJede Zeile enthält außerdem:\n- den Statuscode,\n- Rechnungsnummer und Kundenreferenz der Ursprungsrechnung,\n- die Namen der Benutzer, die die Retoure angelegt und zuletzt geändert haben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StatusId` | int | Nein | Status-ID der Retouren (`pixi.Status.Id`). `NULL` liefert alle Status. |\n| `ChangeDateFrom` | datetime | Nein | Beginn des Änderungszeitraums, einschließlich. Bei `NULL` beginnt der Zeitraum um 00:00 Uhr am selben Tag vor einem Monat. |\n| `ChangeDateTo` | datetime | Nein | Ende des Änderungszeitraums, einschließlich. Bei `NULL` endet der Zeitraum am Ende des heutigen Tages. |\n| `InvoiceNr` | varchar(20) | Nein | Nummer der Ursprungsrechnung. Es werden nur Retouren zu dieser Rechnung geliefert. Existiert keine Rechnung mit dieser Nummer, wird der Filter ignoriert. |\n| `Offset` | int | Nein | Anzahl der passenden Retouren, die übersprungen werden, gezählt in aufsteigender Reihenfolge von `Id`. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. |\n\n- **Unbekannte Rechnungsnummer:** Passt `InvoiceNr` zu keiner Rechnung, wird der Rechnungsfilter stillschweigend ignoriert. Der Aufruf liefert dann alle Retouren, die den übrigen Filtern entsprechen. Dasselbe gilt für einen Leerstring, zu dem keine Rechnung existiert.\n- **Doppelte Rechnungsnummern:** Haben mehrere Rechnungen dieselbe Nummer, wird nur eine davon verwendet; welche, ist nicht festgelegt.\n- **Lücken beim Paging:** Die Zeilennummern werden vergeben, bevor Status-, Rechnungs- und Benutzerdaten verknüpft werden. Diese Verknüpfungen sind Inner Joins. Eine Retoure, deren Status, Ursprungsrechnung, anlegender oder ändernder Benutzer nicht gefunden wird, fehlt in der Ausgabe. Eine Seite kann daher weniger als `RowCount` Zeilen enthalten, obwohl spätere Seiten noch Daten haben. Beim Paging `Offset` jeweils um `RowCount` erhöhen und nicht um die Anzahl der erhaltenen Zeilen.\n- **Zeitgenauigkeit:** `RecordModifiedOn` wird als `smalldatetime` (Minutengenauigkeit) geführt.\n- **Dirty Reads:** Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetReturns"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine seitenweise Liste von Retouren, die in einem Zeitraum geändert wurden, optional gefiltert nach Status und Rechnungsnummer, inklusive zugehöriger Gutschrift.\n\nLiest Retouren aus der Tabelle `pixi.Return` und liefert eine Zeile pro Retoure.\n\n**Filter**\n- `StatusId`: nur Retouren mit dieser Status-ID. `NULL` liefert alle Status.\n- `InvoiceNr`: Die Rechnungsnummer wird zunächst in den Rechnungsschlüssel aufgelöst. Es werden nur Retouren zu dieser Rechnung geliefert.\n- `ChangeDateFrom` / `ChangeDateTo`: `RecordModifiedOn` der Retoure muss zwischen beiden Werten liegen, die Grenzen eingeschlossen.\n - Ist `ChangeDateFrom` `NULL`, beginnt der Zeitraum um 00:00 Uhr am selben Tag vor einem Monat.\n - Ist `ChangeDateTo` `NULL`, endet der Zeitraum am Ende des heutigen Tages (23:59:59.997).\n\n**Gutschrift**\nDie in der Retoure hinterlegte Gutschrift (`CreditInvoiceId`) wird optional verknüpft. Ihre Nummer und ihr Gesamtbetrag werden als `CreditNumber` und `CreditedAmount` geliefert. Beide sind leer, wenn die Retoure keine Gutschrift hat.\n\n**Paging und Sortierung**\n- Alle passenden Retouren werden aufsteigend nach `Id` durchnummeriert.\n- Geliefert werden Zeilen mit einer Zeilennummer größer als `Offset`, höchstens `RowCount` Zeilen.\n- Das Ergebnis ist nach `Id` sortiert.\n\n**Zusätzliche Daten**\nJede Zeile enthält außerdem:\n- den Statuscode,\n- Rechnungsnummer und Kundenreferenz der Ursprungsrechnung,\n- die Namen der Benutzer, die die Retoure angelegt und zuletzt geändert haben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StatusId` | int | Nein | Status-ID der Retouren (`pixi.Status.Id`). `NULL` liefert alle Status. |\n| `ChangeDateFrom` | datetime | Nein | Beginn des Änderungszeitraums, einschließlich. Bei `NULL` beginnt der Zeitraum um 00:00 Uhr am selben Tag vor einem Monat. |\n| `ChangeDateTo` | datetime | Nein | Ende des Änderungszeitraums, einschließlich. Bei `NULL` endet der Zeitraum am Ende des heutigen Tages. |\n| `InvoiceNr` | varchar(20) | Nein | Nummer der Ursprungsrechnung. Es werden nur Retouren zu dieser Rechnung geliefert. Existiert keine Rechnung mit dieser Nummer, wird der Filter ignoriert. |\n| `Offset` | int | Nein | Anzahl der passenden Retouren, die übersprungen werden, gezählt in aufsteigender Reihenfolge von `Id`. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. |\n\n- **Unbekannte Rechnungsnummer:** Passt `InvoiceNr` zu keiner Rechnung, wird der Rechnungsfilter stillschweigend ignoriert. Der Aufruf liefert dann alle Retouren, die den übrigen Filtern entsprechen. Dasselbe gilt für einen Leerstring, zu dem keine Rechnung existiert.\n- **Doppelte Rechnungsnummern:** Haben mehrere Rechnungen dieselbe Nummer, wird nur eine davon verwendet; welche, ist nicht festgelegt.\n- **Lücken beim Paging:** Die Zeilennummern werden vergeben, bevor Status-, Rechnungs- und Benutzerdaten verknüpft werden. Diese Verknüpfungen sind Inner Joins. Eine Retoure, deren Status, Ursprungsrechnung, anlegender oder ändernder Benutzer nicht gefunden wird, fehlt in der Ausgabe. Eine Seite kann daher weniger als `RowCount` Zeilen enthalten, obwohl spätere Seiten noch Daten haben. Beim Paging `Offset` jeweils um `RowCount` erhöhen und nicht um die Anzahl der erhaltenen Zeilen.\n- **Zeitgenauigkeit:** `RecordModifiedOn` wird als `smalldatetime` (Minutengenauigkeit) geführt.\n- **Dirty Reads:** Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetReturns"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1532\n 2\n RETURN_RECEIVED\n 884512\n RE2024001234\n 100245\n 2024-05-10T09:15:00\n lager01\n 2024-05-12T14:30:00\n service02\n GS2024000311\n 49.9000\n \n"
}
]
},
{
"name": "pixiGetStandardReturnReasons",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Liste der Standard-Retourengründe auf Deutsch oder Englisch aus der Tabelle der Standardgründe, einer Einstellung und der Codetabelle für Retourengründe.\n\nStellt eine Liste von Retourengründen aus drei Quellen zusammen und liefert sie als eine Ergebnismenge.\n\n**Sprachauswahl.** `LanguageID` = `1` wählt Deutsch; jeder andere Wert, auch `NULL`, wählt Englisch. Intern wechselt die Prozedur auf die Tabellenkonvention von Pixi, in der `1` = Englisch und `2` = Deutsch gilt, und filtert die Tabellen mit diesem Wert.\n\n**Quellen**\n1. Einträge aus `RET_STANDARD_REASONS` in der gewählten Sprache. Sie liefern `RET_REASON_ID` und `REASON_TEXT`. `RET_REASON_CODE` und `LANGUAGEID` sind `NULL`.\n2. Die Einstellung `CSD_ReturnWizardReasons_Deutsch` (Deutsch) bzw. `CSD_ReturnWizardReasons_English` (andere Sprachen). Ihr Wert ist eine durch Semikolon getrennte Liste. Jeder Eintrag wird zu einer Zeile mit getrimmtem Text (max. 100 Zeichen) und `RET_REASON_ID` = `NULL`. Dieser Teil wird per `UNION` mit Quelle 1 verbunden, identische Zeilen aus Quelle 1 und 2 erscheinen daher nur einmal.\n3. Einträge aus `pixi.CodeTableValue` mit `CodeTableTypeId` = `2` (Retourengründe), verknüpft mit ihrem `Translation`-Eintrag (`DBObjectName` = `CodeTableValue`) in der gewählten Sprache. Diese Zeilen liefern die ID aus der Codetabelle, den übersetzten Text und den `Code`. `LANGUAGEID` wird in die Konvention des Aufrufers zurückgerechnet (`1` = Deutsch). Sie werden per `UNION ALL` angehängt, Duplikate werden hier also nicht entfernt.\n\n**Filter.** Mit `OnlyReturnReasonsFromPixiWeb` = `1` werden nur Zeilen mit `RET_REASON_ID` geliefert. Damit entfallen die Gründe aus der Einstellung (Quelle 2).\n\n**Sortierung.** Die Zeilen werden nach `RET_REASON_CODE` sortiert. Zeilen ohne Code (`NULL`) stehen vorne, ihre Reihenfolge untereinander ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LanguageID` | int | Nein | Sprache der Texte der Retourengründe: `1` = Deutsch, jeder andere Wert = Englisch. |\n| `OnlyReturnReasonsFromPixiWeb` | bit | Nein | Bei `1` werden nur Gründe mit ID geliefert, also die aus `RET_STANDARD_REASONS` und der Codetabelle. Die Gründe aus der Einstellung entfallen. |\n\n- Die Sprachkonvention des Parameters (`1` = Deutsch) ist umgekehrt zur Konvention der Tabellen (`1` = Englisch, `2` = Deutsch). Nur die Spalte `LANGUAGEID` der Zeilen aus der Codetabelle wird in der Konvention des Aufrufers geliefert; alle anderen Zeilen liefern `NULL`.\n- Existiert die Einstellung nicht oder ist sie leer, liefert Quelle 2 keine Zeilen.\n- Ein abschließendes oder doppeltes Semikolon im Wert der Einstellung erzeugt Zeilen mit leerem `REASON_TEXT`.\n- Zeichen wie `&` oder `<` im Wert der Einstellung können die Umwandlung der Liste in XML scheitern lassen; der Aufruf liefert dann einen SQL-Fehler.\n- `Settings`, `RET_STANDARD_REASONS` und `CodeTableValue` werden mit `NOLOCK` gelesen; `Translation` ohne Sperrhinweis.\n- Der Name der Einstellung wird per `LIKE` verglichen, wobei `_` ein Platzhalter für ein einzelnes Zeichen ist. In der Praxis ist der Vergleich exakt.\n- Nur lesend; es wird lediglich eine temporäre Tabelle verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStandardReturnReasons"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Liste der Standard-Retourengründe auf Deutsch oder Englisch aus der Tabelle der Standardgründe, einer Einstellung und der Codetabelle für Retourengründe.\n\nStellt eine Liste von Retourengründen aus drei Quellen zusammen und liefert sie als eine Ergebnismenge.\n\n**Sprachauswahl.** `LanguageID` = `1` wählt Deutsch; jeder andere Wert, auch `NULL`, wählt Englisch. Intern wechselt die Prozedur auf die Tabellenkonvention von Pixi, in der `1` = Englisch und `2` = Deutsch gilt, und filtert die Tabellen mit diesem Wert.\n\n**Quellen**\n1. Einträge aus `RET_STANDARD_REASONS` in der gewählten Sprache. Sie liefern `RET_REASON_ID` und `REASON_TEXT`. `RET_REASON_CODE` und `LANGUAGEID` sind `NULL`.\n2. Die Einstellung `CSD_ReturnWizardReasons_Deutsch` (Deutsch) bzw. `CSD_ReturnWizardReasons_English` (andere Sprachen). Ihr Wert ist eine durch Semikolon getrennte Liste. Jeder Eintrag wird zu einer Zeile mit getrimmtem Text (max. 100 Zeichen) und `RET_REASON_ID` = `NULL`. Dieser Teil wird per `UNION` mit Quelle 1 verbunden, identische Zeilen aus Quelle 1 und 2 erscheinen daher nur einmal.\n3. Einträge aus `pixi.CodeTableValue` mit `CodeTableTypeId` = `2` (Retourengründe), verknüpft mit ihrem `Translation`-Eintrag (`DBObjectName` = `CodeTableValue`) in der gewählten Sprache. Diese Zeilen liefern die ID aus der Codetabelle, den übersetzten Text und den `Code`. `LANGUAGEID` wird in die Konvention des Aufrufers zurückgerechnet (`1` = Deutsch). Sie werden per `UNION ALL` angehängt, Duplikate werden hier also nicht entfernt.\n\n**Filter.** Mit `OnlyReturnReasonsFromPixiWeb` = `1` werden nur Zeilen mit `RET_REASON_ID` geliefert. Damit entfallen die Gründe aus der Einstellung (Quelle 2).\n\n**Sortierung.** Die Zeilen werden nach `RET_REASON_CODE` sortiert. Zeilen ohne Code (`NULL`) stehen vorne, ihre Reihenfolge untereinander ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LanguageID` | int | Nein | Sprache der Texte der Retourengründe: `1` = Deutsch, jeder andere Wert = Englisch. |\n| `OnlyReturnReasonsFromPixiWeb` | bit | Nein | Bei `1` werden nur Gründe mit ID geliefert, also die aus `RET_STANDARD_REASONS` und der Codetabelle. Die Gründe aus der Einstellung entfallen. |\n\n- Die Sprachkonvention des Parameters (`1` = Deutsch) ist umgekehrt zur Konvention der Tabellen (`1` = Englisch, `2` = Deutsch). Nur die Spalte `LANGUAGEID` der Zeilen aus der Codetabelle wird in der Konvention des Aufrufers geliefert; alle anderen Zeilen liefern `NULL`.\n- Existiert die Einstellung nicht oder ist sie leer, liefert Quelle 2 keine Zeilen.\n- Ein abschließendes oder doppeltes Semikolon im Wert der Einstellung erzeugt Zeilen mit leerem `REASON_TEXT`.\n- Zeichen wie `&` oder `<` im Wert der Einstellung können die Umwandlung der Liste in XML scheitern lassen; der Aufruf liefert dann einen SQL-Fehler.\n- `Settings`, `RET_STANDARD_REASONS` und `CodeTableValue` werden mit `NOLOCK` gelesen; `Translation` ohne Sperrhinweis.\n- Der Name der Einstellung wird per `LIKE` verglichen, wobei `_` ein Platzhalter für ein einzelnes Zeichen ist. In der Praxis ist der Vergleich exakt.\n- Nur lesend; es wird lediglich eine temporäre Tabelle verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStandardReturnReasons"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 3\n Artikel defekt\n \n \n 17\n Falsche Größe\n SIZE\n 1\n \n"
}
]
},
{
"name": "pixiReadReturnLines",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Retourenpositionen seitenweise nach Id sortiert, optional gefiltert nach Anlage- und/oder Änderungsdatum.\n\nLiest Zeilen aus der Tabelle `ReturnLine` (Retourenpositionen) und liefert sie aufsteigend nach `Id` sortiert. Der Aufruf ist für Keyset-Paging und Delta-Abgleiche ausgelegt.\n\n**Paging**\n- `Id` ist eine *exklusive* Untergrenze: Es werden nur Positionen mit `Id > @Id` geliefert. Wird `Id` weggelassen oder ist NULL, wird `0` verwendet, d. h. es wird ab der ersten Position gelesen.\n- Es werden höchstens `RowCount` Zeilen geliefert (Standard `1000`; NULL wird ebenfalls als `1000` behandelt).\n- Für die nächste Seite wird die höchste `Id` der vorherigen Seite als `Id` übergeben.\n\n**Datumsfilter** (es wird nur eine Gruppe angewendet, geprüft in dieser Reihenfolge):\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: Ist mindestens einer gesetzt, passt eine Position, wenn ihr Anlage- **oder** Änderungsdatum `>=` dem Von-Wert ist und ihr Anlage- **oder** Änderungsdatum `<` dem Bis-Wert ist.\n2. Andernfalls `CreateDateFrom` / `CreateDateTo`: Filter auf `RecordCreatedOn` (Von inklusiv, Bis exklusiv).\n3. Andernfalls `UpdateDateFrom` / `UpdateDateTo`: Filter auf `RecordModifiedOn` (Von inklusiv, Bis exklusiv).\n4. Ist kein Datumsparameter gesetzt, werden alle Positionen mit `Id > @Id` geliefert (begrenzt durch `RowCount`).\n\nJede Grenze einer Gruppe kann weggelassen werden, um einen offenen Bereich zu erhalten. Parameter niedrigerer Gruppen werden ignoriert, wenn eine höher priorisierte Gruppe verwendet wird.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Id` | int | Nein | Exklusive Untergrenze für die Id der Retourenposition (Keyset-Paging). Es werden nur Positionen mit größerer Id geliefert. NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Liefert Positionen, die ab diesem Zeitpunkt angelegt wurden (inklusiv). Wird nur verwendet, wenn kein CreateAndUpdateDate-Parameter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Liefert Positionen, die vor diesem Zeitpunkt angelegt wurden (exklusiv). Wird nur verwendet, wenn kein CreateAndUpdateDate-Parameter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Liefert Positionen, die ab diesem Zeitpunkt geändert wurden (inklusiv). Wird nur verwendet, wenn kein CreateAndUpdateDate- oder CreateDate-Parameter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Liefert Positionen, die vor diesem Zeitpunkt geändert wurden (exklusiv). Wird nur verwendet, wenn kein CreateAndUpdateDate- oder CreateDate-Parameter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Liefert Positionen, deren Anlage- oder Änderungsdatum ab diesem Zeitpunkt liegt. Hat Vorrang vor allen anderen Datumsparametern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Liefert Positionen, deren Anlage- oder Änderungsdatum vor diesem Zeitpunkt liegt (exklusiv). Hat Vorrang vor allen anderen Datumsparametern. |\n| `RowCount` | int | Nein | Maximale Anzahl der gelieferten Zeilen pro Aufruf (Seitengröße). NULL wird als 1000 behandelt. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen; es können nicht festgeschriebene oder inkonsistente Daten geliefert werden.\n- Mit `Id` kann keine einzelne Position abgerufen werden: Der Code enthält zwar einen Zweig für `Id = @Id`, dieser ist aber nicht erreichbar, da `Id` immer gesetzt ist (NULL wird zu `0`) und `RowCount` nie NULL ist. Eine übergebene `Id` liefert stets Positionen mit **größerer** `Id`.\n- Der kombinierte Filter (`CreateAndUpdateDate…`) prüft beide Grenzen mit getrennten ODER-Bedingungen. Sind beide Grenzen gesetzt, kann auch eine Position passen, die vor dem Zeitraum angelegt und nach dem Zeitraum geändert wurde (z. B. angelegt vor `To` und geändert nach `From`).\n- Ein negativer `RowCount` führt zu einem SQL-Fehler bei `TOP`; `0` liefert ein leeres Ergebnis.\n- Die Datentypen der Spalten sind im Code nicht ersichtlich (Tabellendefinition nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadReturnLines"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Retourenpositionen seitenweise nach Id sortiert, optional gefiltert nach Anlage- und/oder Änderungsdatum.\n\nLiest Zeilen aus der Tabelle `ReturnLine` (Retourenpositionen) und liefert sie aufsteigend nach `Id` sortiert. Der Aufruf ist für Keyset-Paging und Delta-Abgleiche ausgelegt.\n\n**Paging**\n- `Id` ist eine *exklusive* Untergrenze: Es werden nur Positionen mit `Id > @Id` geliefert. Wird `Id` weggelassen oder ist NULL, wird `0` verwendet, d. h. es wird ab der ersten Position gelesen.\n- Es werden höchstens `RowCount` Zeilen geliefert (Standard `1000`; NULL wird ebenfalls als `1000` behandelt).\n- Für die nächste Seite wird die höchste `Id` der vorherigen Seite als `Id` übergeben.\n\n**Datumsfilter** (es wird nur eine Gruppe angewendet, geprüft in dieser Reihenfolge):\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: Ist mindestens einer gesetzt, passt eine Position, wenn ihr Anlage- **oder** Änderungsdatum `>=` dem Von-Wert ist und ihr Anlage- **oder** Änderungsdatum `<` dem Bis-Wert ist.\n2. Andernfalls `CreateDateFrom` / `CreateDateTo`: Filter auf `RecordCreatedOn` (Von inklusiv, Bis exklusiv).\n3. Andernfalls `UpdateDateFrom` / `UpdateDateTo`: Filter auf `RecordModifiedOn` (Von inklusiv, Bis exklusiv).\n4. Ist kein Datumsparameter gesetzt, werden alle Positionen mit `Id > @Id` geliefert (begrenzt durch `RowCount`).\n\nJede Grenze einer Gruppe kann weggelassen werden, um einen offenen Bereich zu erhalten. Parameter niedrigerer Gruppen werden ignoriert, wenn eine höher priorisierte Gruppe verwendet wird.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Id` | int | Nein | Exklusive Untergrenze für die Id der Retourenposition (Keyset-Paging). Es werden nur Positionen mit größerer Id geliefert. NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Liefert Positionen, die ab diesem Zeitpunkt angelegt wurden (inklusiv). Wird nur verwendet, wenn kein CreateAndUpdateDate-Parameter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Liefert Positionen, die vor diesem Zeitpunkt angelegt wurden (exklusiv). Wird nur verwendet, wenn kein CreateAndUpdateDate-Parameter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Liefert Positionen, die ab diesem Zeitpunkt geändert wurden (inklusiv). Wird nur verwendet, wenn kein CreateAndUpdateDate- oder CreateDate-Parameter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Liefert Positionen, die vor diesem Zeitpunkt geändert wurden (exklusiv). Wird nur verwendet, wenn kein CreateAndUpdateDate- oder CreateDate-Parameter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Liefert Positionen, deren Anlage- oder Änderungsdatum ab diesem Zeitpunkt liegt. Hat Vorrang vor allen anderen Datumsparametern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Liefert Positionen, deren Anlage- oder Änderungsdatum vor diesem Zeitpunkt liegt (exklusiv). Hat Vorrang vor allen anderen Datumsparametern. |\n| `RowCount` | int | Nein | Maximale Anzahl der gelieferten Zeilen pro Aufruf (Seitengröße). NULL wird als 1000 behandelt. |\n\n- Die Tabelle wird mit `NOLOCK` gelesen; es können nicht festgeschriebene oder inkonsistente Daten geliefert werden.\n- Mit `Id` kann keine einzelne Position abgerufen werden: Der Code enthält zwar einen Zweig für `Id = @Id`, dieser ist aber nicht erreichbar, da `Id` immer gesetzt ist (NULL wird zu `0`) und `RowCount` nie NULL ist. Eine übergebene `Id` liefert stets Positionen mit **größerer** `Id`.\n- Der kombinierte Filter (`CreateAndUpdateDate…`) prüft beide Grenzen mit getrennten ODER-Bedingungen. Sind beide Grenzen gesetzt, kann auch eine Position passen, die vor dem Zeitraum angelegt und nach dem Zeitraum geändert wurde (z. B. angelegt vor `To` und geändert nach `From`).\n- Ein negativer `RowCount` führt zu einem SQL-Fehler bei `TOP`; `0` liefert ein leeres Ergebnis.\n- Die Datentypen der Spalten sind im Code nicht ersichtlich (Tabellendefinition nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadReturnLines"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1201\n 3\n 458812\n 0\n Size too small\n Checked, item ok\n 2024-01-15T10:24:11\n 845\n 99231\n 2\n 1\n 29.99\n 25.20\n 2024-01-14T16:02:45\n 12\n 15\n 1\n \n"
}
]
},
{
"name": "pixiReturnCaseUpdate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt die Rücksendekosten eines eingegangenen Retourenfalls, netto bei B2B und brutto bei B2C, nach Prüfung gegen den erstattungsfähigen Betrag.\n\nAktualisiert die Rücksendekosten eines Retourenfalls in `pixi.Return`.\n\nAblauf:\n\n1. `UserName` wird getrimmt. Ein leerer Wert wird zu `API`.\n2. `ReturnId` und `ReturnCost` müssen beide angegeben sein.\n3. Der Retourenfall muss existieren.\n4. Der Retourenfall muss im Status `StatusId = 2` (Eingegangen) sein.\n5. `ReturnCost` darf nicht negativ sein. Der Wert `0` wird akzeptiert.\n6. Die Obergrenze wird aus dem Retourenfall und der zugehörigen Rechnung berechnet (`Invoices.InvoiceKey = Return.InvoiceId`). Sie ergibt sich aus dem Betrag der retournierten Artikel plus der Versandkostenerstattung abzüglich des Gutscheinbetrags:\n - bei `B2B`-Aufträgen: `TotalToRefundNet + ShippingCostRefundNet - VoucherAmountNet`\n - bei `B2C`-Aufträgen: `TotalToRefundGross + ShippingCostRefundGross - VoucherAmountGross`\n \n Liegt `ReturnCost` über dieser Grenze, wird eine Fehlerzeile geliefert.\n7. Die Kosten werden in den Retourenfall geschrieben:\n - `B2C`: der Wert wird in `ReturnCostGross` gespeichert.\n - jeder andere Auftragstyp: der Wert wird in `ReturnCostNet` gespeichert.\n \n Zusätzlich werden `RecordModifiedByUserId` und `RecordModifiedOn` gesetzt.\n\nDie Benutzer-ID wird über `UserName` ermittelt. Existiert dieser Benutzer nicht, wird der Benutzer `pixiAdministration` verwendet.\n\nDer Aufruf liefert genau eine Zeile mit `Status` und `Message`, sowohl bei Erfolg als auch bei Fehlern.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ReturnId` | int | Nein | ID des Retourenfalls (`pixi.Return.id`). Faktisch erforderlich. |\n| `ReturnCost` | money | Nein | Zu speichernde Rücksendekosten. Sie werden bei B2B als Netto- und bei B2C als Bruttowert gespeichert. Der Wert darf weder negativ sein noch den erstattungsfähigen Betrag überschreiten. Faktisch erforderlich. |\n| `UserName` | varchar(50) | Nein | Name des Benutzers, der als Bearbeiter gespeichert wird. Ein leerer Wert wird zu `API`. Bei unbekanntem Benutzer wird `pixiAdministration` verwendet. |\n\n- Die Prüfabfragen verwenden `NOLOCK`, das Update verwendet `ROWLOCK`. Es wird keine explizite Transaktion verwendet.\n- Fallstrick: Die Prüfung der Obergrenze entfällt in drei Fällen:\n - es wird keine passende Rechnung in `Invoices` gefunden, der Auftragstyp bleibt daher `NULL`;\n - der Auftragstyp ist weder `B2B` noch `B2C`;\n - eine der Betragsspalten ist `NULL`.\n \n In den ersten beiden Fällen wird der Wert ohne Grenzprüfung in `ReturnCostNet` geschrieben.\n- Der Fehlertext 'must be greater than 0' ist irreführend: Abgelehnt werden nur negative Werte, `0` wird akzeptiert.\n- Bei Fehlern liefert die Prozedur zusätzlich den Rückgabewert 1. Für SOAP-Clients ist die Statuszeile maßgeblich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReturnCaseUpdate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt die Rücksendekosten eines eingegangenen Retourenfalls, netto bei B2B und brutto bei B2C, nach Prüfung gegen den erstattungsfähigen Betrag.\n\nAktualisiert die Rücksendekosten eines Retourenfalls in `pixi.Return`.\n\nAblauf:\n\n1. `UserName` wird getrimmt. Ein leerer Wert wird zu `API`.\n2. `ReturnId` und `ReturnCost` müssen beide angegeben sein.\n3. Der Retourenfall muss existieren.\n4. Der Retourenfall muss im Status `StatusId = 2` (Eingegangen) sein.\n5. `ReturnCost` darf nicht negativ sein. Der Wert `0` wird akzeptiert.\n6. Die Obergrenze wird aus dem Retourenfall und der zugehörigen Rechnung berechnet (`Invoices.InvoiceKey = Return.InvoiceId`). Sie ergibt sich aus dem Betrag der retournierten Artikel plus der Versandkostenerstattung abzüglich des Gutscheinbetrags:\n - bei `B2B`-Aufträgen: `TotalToRefundNet + ShippingCostRefundNet - VoucherAmountNet`\n - bei `B2C`-Aufträgen: `TotalToRefundGross + ShippingCostRefundGross - VoucherAmountGross`\n \n Liegt `ReturnCost` über dieser Grenze, wird eine Fehlerzeile geliefert.\n7. Die Kosten werden in den Retourenfall geschrieben:\n - `B2C`: der Wert wird in `ReturnCostGross` gespeichert.\n - jeder andere Auftragstyp: der Wert wird in `ReturnCostNet` gespeichert.\n \n Zusätzlich werden `RecordModifiedByUserId` und `RecordModifiedOn` gesetzt.\n\nDie Benutzer-ID wird über `UserName` ermittelt. Existiert dieser Benutzer nicht, wird der Benutzer `pixiAdministration` verwendet.\n\nDer Aufruf liefert genau eine Zeile mit `Status` und `Message`, sowohl bei Erfolg als auch bei Fehlern.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ReturnId` | int | Nein | ID des Retourenfalls (`pixi.Return.id`). Faktisch erforderlich. |\n| `ReturnCost` | money | Nein | Zu speichernde Rücksendekosten. Sie werden bei B2B als Netto- und bei B2C als Bruttowert gespeichert. Der Wert darf weder negativ sein noch den erstattungsfähigen Betrag überschreiten. Faktisch erforderlich. |\n| `UserName` | varchar(50) | Nein | Name des Benutzers, der als Bearbeiter gespeichert wird. Ein leerer Wert wird zu `API`. Bei unbekanntem Benutzer wird `pixiAdministration` verwendet. |\n\n- Die Prüfabfragen verwenden `NOLOCK`, das Update verwendet `ROWLOCK`. Es wird keine explizite Transaktion verwendet.\n- Fallstrick: Die Prüfung der Obergrenze entfällt in drei Fällen:\n - es wird keine passende Rechnung in `Invoices` gefunden, der Auftragstyp bleibt daher `NULL`;\n - der Auftragstyp ist weder `B2B` noch `B2C`;\n - eine der Betragsspalten ist `NULL`.\n \n In den ersten beiden Fällen wird der Wert ohne Grenzprüfung in `ReturnCostNet` geschrieben.\n- Der Fehlertext 'must be greater than 0' ist irreführend: Abgelehnt werden nur negative Werte, `0` wird akzeptiert.\n- Bei Fehlern liefert die Prozedur zusätzlich den Rückgabewert 1. Für SOAP-Clients ist die Statuszeile maßgeblich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReturnCaseUpdate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n Return Case updated successfully.\n \n"
}
]
}
]
},
{
"name": "Shipping",
"item": [
{
"name": "pixiCheckPickListNr",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Prüft, ob eine Picklistennummer existiert und nicht abgelaufen ist, und liefert Kistenbereich, 1SS-Kennzeichen, Scanstatus und Anzahl offener Aufträge.\n\nPrüft eine Pickliste (`PLHeader`) anhand ihres Schlüssels `PickListNr`. Der Aufruf übergibt die gesamte Verarbeitung an die interne Prozedur `Pixi_CheckPickListNr` und liefert immer genau eine Zeile.\n\nAblauf:\n\n1. **Scanstatus:** Es wird geprüft, ob mindestens eine Position der Pickliste (`PLitem`) auf eine Auftragsposition mit Status `EIN` verweist. Ist das der Fall, ist `PicklistNotScannedYet` gleich `0`. Gibt es keine solche Position, ist der Wert `1`.\n2. **Anzahl Aufträge:** Gezählt werden die unterschiedlichen Auftragsnummern der Pickliste, deren Auftragspositionen nicht abgelaufen sind (`Expired = 0`). Aufträge, für die in `boxes` bereits eine Kiste mit `WaitForSend = 'N'` existiert, werden nicht mitgezählt.\n3. **Gültigkeit:** Eine Pickliste ist gültig, wenn eine `PLHeader`-Zeile mit `PLHkey = PickListNr` existiert und ihr `PLHexpiryDate` nach der aktuellen Serverzeit liegt.\n - **Ungültige oder abgelaufene Pickliste:** Die Zeile enthält `ReturnValue = 0`, alle anderen Spalten sind `0`.\n - **Gültige Pickliste:** Die Zeile enthält `ReturnValue = 1`, den Kistenbereich `PLHfromBox`/`PLHtoBox`, das Kennzeichen `1SS` (`NULL` wird zu `0`) sowie die Werte aus Schritt 1 und 2.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PickListNr` | int | Ja | Schlüssel der zu prüfenden Pickliste (`PLHeader.PLHkey`). |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`. Die Werte können gleichzeitig laufende, noch nicht bestätigte Änderungen enthalten.\n- Im ungültigen Zweig heißen die Kistenspalten `PLHFromBox`/`PLHToBox`. Im gültigen Zweig heißen sie `PLHfromBox`/`PLHtoBox`. XML-Elementnamen unterscheiden Groß- und Kleinschreibung, daher sollten Clients sie ohne Beachtung der Schreibweise auslesen.\n- Der Spaltenname `1SS` beginnt mit einer Ziffer. Im SOAP/DataSet-XML wird er üblicherweise als `_x0031_SS` kodiert.\n- Eine nicht vorhandene Pickliste lässt sich nicht von einer abgelaufenen unterscheiden; beide liefern `ReturnValue = 0`.\n- Der Ablauf wird mit der Uhrzeit des Datenbankservers (`GETDATE()`) verglichen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCheckPickListNr"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Prüft, ob eine Picklistennummer existiert und nicht abgelaufen ist, und liefert Kistenbereich, 1SS-Kennzeichen, Scanstatus und Anzahl offener Aufträge.\n\nPrüft eine Pickliste (`PLHeader`) anhand ihres Schlüssels `PickListNr`. Der Aufruf übergibt die gesamte Verarbeitung an die interne Prozedur `Pixi_CheckPickListNr` und liefert immer genau eine Zeile.\n\nAblauf:\n\n1. **Scanstatus:** Es wird geprüft, ob mindestens eine Position der Pickliste (`PLitem`) auf eine Auftragsposition mit Status `EIN` verweist. Ist das der Fall, ist `PicklistNotScannedYet` gleich `0`. Gibt es keine solche Position, ist der Wert `1`.\n2. **Anzahl Aufträge:** Gezählt werden die unterschiedlichen Auftragsnummern der Pickliste, deren Auftragspositionen nicht abgelaufen sind (`Expired = 0`). Aufträge, für die in `boxes` bereits eine Kiste mit `WaitForSend = 'N'` existiert, werden nicht mitgezählt.\n3. **Gültigkeit:** Eine Pickliste ist gültig, wenn eine `PLHeader`-Zeile mit `PLHkey = PickListNr` existiert und ihr `PLHexpiryDate` nach der aktuellen Serverzeit liegt.\n - **Ungültige oder abgelaufene Pickliste:** Die Zeile enthält `ReturnValue = 0`, alle anderen Spalten sind `0`.\n - **Gültige Pickliste:** Die Zeile enthält `ReturnValue = 1`, den Kistenbereich `PLHfromBox`/`PLHtoBox`, das Kennzeichen `1SS` (`NULL` wird zu `0`) sowie die Werte aus Schritt 1 und 2.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PickListNr` | int | Ja | Schlüssel der zu prüfenden Pickliste (`PLHeader.PLHkey`). |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`. Die Werte können gleichzeitig laufende, noch nicht bestätigte Änderungen enthalten.\n- Im ungültigen Zweig heißen die Kistenspalten `PLHFromBox`/`PLHToBox`. Im gültigen Zweig heißen sie `PLHfromBox`/`PLHtoBox`. XML-Elementnamen unterscheiden Groß- und Kleinschreibung, daher sollten Clients sie ohne Beachtung der Schreibweise auslesen.\n- Der Spaltenname `1SS` beginnt mit einer Ziffer. Im SOAP/DataSet-XML wird er üblicherweise als `_x0031_SS` kodiert.\n- Eine nicht vorhandene Pickliste lässt sich nicht von einer abgelaufenen unterscheiden; beide liefern `ReturnValue = 0`.\n- Der Ablauf wird mit der Uhrzeit des Datenbankservers (`GETDATE()`) verglichen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCheckPickListNr"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 1\n 24\n <_x0031_SS>false\n true\n 18\n \n"
}
]
},
{
"name": "pixiCreateInvoicePackage",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt ein Paket (pixi.InvoicePackage) zu einer Rechnung an, optional mit Paketpositionen, Tracking-IDs und Label-URLs, und liefert die neue PackageId.\n\nLegt ein neues Versandpaket zu einer bestehenden Rechnung an und ordnet optional Rechnungspositionen mit Mengen zu.\n\nAblauf:\n1. Prüft die Einstellung `Premium_API`. Ist sie nicht aktiviert, wird eine Fehlerzeile geliefert.\n2. Leere Zeichenketten in den Textparametern werden als `NULL` behandelt; `ShipVendorCode` wird getrimmt.\n3. Die Rechnung wird über `InvoiceNr` und/oder `InvoiceKey` bestimmt. Mindestens einer der Werte ist erforderlich. Werden beide übergeben, müssen sie auf dieselbe Rechnung zeigen.\n4. Der Versanddienstleister wird aus `ShipVendorCode` über `ShipVendor.ShipVendorCode` ermittelt. Ohne Code wird der `ShipVendor` der Rechnung verwendet. Ein explizit übergebener, unbekannter Code wird abgelehnt; kann der Rückfallwert nicht aufgelöst werden, bleibt `ShipVendorId` einfach `NULL`.\n5. Ist `Lines` gesetzt, wird es als XML gelesen (`/Lines/Line` mit `InvlineId` und `Quantity`). Jede Position wird geprüft:\n - `InvlineId` und `Quantity` müssen ganze Zahlen sein,\n - keine doppelten `InvlineId`,\n - jede Position muss zur Rechnung gehören (`Invlines.InvoiceRef`),\n - `Quantity` muss größer als 0 sein,\n - `Quantity` plus die bereits anderen Paketen zugeordnete Menge (`pixi.InvoicePackageLines`) darf `Invlines.ItemQty` nicht überschreiten.\n6. In einer Transaktion wird das Paket in `pixi.InvoicePackage` eingefügt (`TimesLabelPrinted` = 0, Audit-Spalten mit dem Benutzer aus `CreateEmp`), die Positionen in `pixi.InvoicePackageLines` eingefügt und `Invoices.Packages` um 1 erhöht.\n7. Ist `TrackingID` oder `ReturnTrackingId` gesetzt, wird `pixiUpdateInvoicePackageTrackingIds` für das neue Paket ausgeführt, um die Tracking-IDs in die Rechnung zu übernehmen (`ShipmentTrackingID`, `retTrackID`, `retTrackIDhist`), gesteuert durch `Overwrite` und `ResetClientNotifiedFlag`.\n8. MQ-Events werden veröffentlicht: `PackageLabelSaved` (nur bei übergebener Label-URL) und `InvoiceChanged` mit Parameter `CreatePackage`.\n\nDer Aufruf liefert immer genau eine Zeile mit `Status`, `Message` und `PackageId`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Nein | Rechnungsnummer. Dieser Wert oder `InvoiceKey` ist erforderlich; werden beide übergeben, müssen sie übereinstimmen. |\n| `InvoiceKey` | int | Nein | Interner Schlüssel der Rechnung (`Invoices.InvoiceKey`). Dieser Wert oder `InvoiceNr` ist erforderlich. |\n| `TrackingID` | varchar(512) | Nein | Sendungsverfolgungsnummer des Pakets. Wenn gesetzt, wird sie zusätzlich in `ShipmentTrackingID` der Rechnung übernommen. |\n| `ReturnTrackingId` | varchar(512) | Nein | Retouren-Trackingnummer des Pakets. Wenn gesetzt, wird sie in `retTrackID` und `retTrackIDhist` der Rechnung übernommen. |\n| `ShippingLabelUrl` | varchar(8000) | Nein | URL des Versandlabels. Wenn gesetzt, wird das MQ-Event `PackageLabelSaved` veröffentlicht. |\n| `ReturnLabelUrl` | varchar(8000) | Nein | URL des Retourenlabels. Wenn gesetzt, wird das MQ-Event `PackageLabelSaved` veröffentlicht. |\n| `ExternalShipmentId` | varchar(512) | Nein | Sendungs-ID in einem externen Versandsystem; wird unverändert gespeichert. |\n| `GrossWeight` | decimal(9, 3) | Nein | Bruttogewicht des Pakets; wird unverändert gespeichert. |\n| `ShipVendorCode` | varchar(3) | Nein | Code des Versanddienstleisters (`ShipVendor.ShipVendorCode`). Ohne Angabe wird der Versanddienstleister der Rechnung verwendet. Ein unbekannter Code führt zu einem Fehler. |\n| `PackageDimensionId` | int | Nein | ID einer Paketabmessung; wird ohne Prüfung gespeichert. |\n| `Lines` | varchar(max) | Nein | Optionales XML mit den im Paket enthaltenen Rechnungspositionen und Mengen. Jede `Line` benötigt eine ganzzahlige `InvlineId` (`Invlines.InvLineKey` dieser Rechnung) und eine positive ganzzahlige `Quantity`. |\n| `ResetClientNotifiedFlag` | bit | Nein | Wird an den Tracking-Abgleich übergeben; wirkt nur, wenn eine Tracking-ID übergeben wird. |\n| `Overwrite` | bit | Nein | Wird an den Tracking-Abgleich übergeben; steuert, wie `TrackingID` in `ShipmentTrackingID` der Rechnung geschrieben wird. |\n| `CreateEmp` | varchar(50) | Nein | Benutzername für die Audit-Spalten; wird in `UCS_USERS` gesucht, unbekannte Namen werden auf `pixiAdministration` abgebildet. |\n\n- Erfordert die Einstellung `Premium_API` = 1.\n- Die Prüfabfragen verwenden `NOLOCK`. Zwei gleichzeitige Aufrufe für dieselben Rechnungspositionen können daher beide die Mengenprüfung bestehen und eine Position überbuchen.\n- Die Prozedur startet eine eigene Transaktion bzw. setzt einen Savepoint, wenn der Aufrufer bereits eine Transaktion geöffnet hat. Die Erfolgszeile wird vor dem Commit ausgegeben.\n- Unerwartete SQL-Fehler werden abgefangen, die Transaktion (bzw. der Savepoint) wird zurückgerollt, der Fehler über `log.InsertError` protokolliert und als `ERROR`-Zeile mit dem SQL-Fehlertext geliefert.\n- Das Ergebnis von `pixiUpdateInvoicePackageTrackingIds` wird intern abgefangen und **nicht ausgewertet**. Meldet diese Prozedur ein Problem (z. B. Status `411`, weil die zusammengesetzte Tracking-Zeichenkette der Rechnung 512 Zeichen überschreiten würde), wird das Paket trotzdem angelegt und `SUCCESS` geliefert, die Tracking-Felder der Rechnung werden aber ggf. nicht aktualisiert.\n- Ein Code-Kommentar besagt, dass der Tracking-Abgleich nach dem Commit läuft; tatsächlich läuft er innerhalb derselben Transaktion.\n- Enthält eine Tracking-ID mehrere durch `;` getrennte Werte, erhält das Paket selbst nur den letzten Wert (durch den Tracking-Abgleich gesetzt), die Rechnung dagegen den vollständigen Wert.\n- `ResetClientNotifiedFlag` = 1 wirkt nur zusammen mit einer Tracking-ID: In `OrderHistory` wird für den jeweils letzten `AUS`-Status der Auftragspositionen der Rechnung `ClientNotified` = `N` gesetzt, sodass der Versand erneut exportiert wird.\n- `CreateEmp` wird in `UCS_USERS` gesucht; unbekannte Namen werden auf den Benutzer `pixiAdministration` abgebildet.\n- `PackageDimensionId`, `GrossWeight` und `ExternalShipmentId` werden ohne Prüfung gespeichert.\n- MQ-Events werden nur gesendet, wenn `pixiMQ_Enabled` aktiv ist und die Events in `EventConfiguration` konfiguriert sind; Fehler dort ändern das Ergebnis nicht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateInvoicePackage"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt ein Paket (pixi.InvoicePackage) zu einer Rechnung an, optional mit Paketpositionen, Tracking-IDs und Label-URLs, und liefert die neue PackageId.\n\nLegt ein neues Versandpaket zu einer bestehenden Rechnung an und ordnet optional Rechnungspositionen mit Mengen zu.\n\nAblauf:\n1. Prüft die Einstellung `Premium_API`. Ist sie nicht aktiviert, wird eine Fehlerzeile geliefert.\n2. Leere Zeichenketten in den Textparametern werden als `NULL` behandelt; `ShipVendorCode` wird getrimmt.\n3. Die Rechnung wird über `InvoiceNr` und/oder `InvoiceKey` bestimmt. Mindestens einer der Werte ist erforderlich. Werden beide übergeben, müssen sie auf dieselbe Rechnung zeigen.\n4. Der Versanddienstleister wird aus `ShipVendorCode` über `ShipVendor.ShipVendorCode` ermittelt. Ohne Code wird der `ShipVendor` der Rechnung verwendet. Ein explizit übergebener, unbekannter Code wird abgelehnt; kann der Rückfallwert nicht aufgelöst werden, bleibt `ShipVendorId` einfach `NULL`.\n5. Ist `Lines` gesetzt, wird es als XML gelesen (`/Lines/Line` mit `InvlineId` und `Quantity`). Jede Position wird geprüft:\n - `InvlineId` und `Quantity` müssen ganze Zahlen sein,\n - keine doppelten `InvlineId`,\n - jede Position muss zur Rechnung gehören (`Invlines.InvoiceRef`),\n - `Quantity` muss größer als 0 sein,\n - `Quantity` plus die bereits anderen Paketen zugeordnete Menge (`pixi.InvoicePackageLines`) darf `Invlines.ItemQty` nicht überschreiten.\n6. In einer Transaktion wird das Paket in `pixi.InvoicePackage` eingefügt (`TimesLabelPrinted` = 0, Audit-Spalten mit dem Benutzer aus `CreateEmp`), die Positionen in `pixi.InvoicePackageLines` eingefügt und `Invoices.Packages` um 1 erhöht.\n7. Ist `TrackingID` oder `ReturnTrackingId` gesetzt, wird `pixiUpdateInvoicePackageTrackingIds` für das neue Paket ausgeführt, um die Tracking-IDs in die Rechnung zu übernehmen (`ShipmentTrackingID`, `retTrackID`, `retTrackIDhist`), gesteuert durch `Overwrite` und `ResetClientNotifiedFlag`.\n8. MQ-Events werden veröffentlicht: `PackageLabelSaved` (nur bei übergebener Label-URL) und `InvoiceChanged` mit Parameter `CreatePackage`.\n\nDer Aufruf liefert immer genau eine Zeile mit `Status`, `Message` und `PackageId`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Nein | Rechnungsnummer. Dieser Wert oder `InvoiceKey` ist erforderlich; werden beide übergeben, müssen sie übereinstimmen. |\n| `InvoiceKey` | int | Nein | Interner Schlüssel der Rechnung (`Invoices.InvoiceKey`). Dieser Wert oder `InvoiceNr` ist erforderlich. |\n| `TrackingID` | varchar(512) | Nein | Sendungsverfolgungsnummer des Pakets. Wenn gesetzt, wird sie zusätzlich in `ShipmentTrackingID` der Rechnung übernommen. |\n| `ReturnTrackingId` | varchar(512) | Nein | Retouren-Trackingnummer des Pakets. Wenn gesetzt, wird sie in `retTrackID` und `retTrackIDhist` der Rechnung übernommen. |\n| `ShippingLabelUrl` | varchar(8000) | Nein | URL des Versandlabels. Wenn gesetzt, wird das MQ-Event `PackageLabelSaved` veröffentlicht. |\n| `ReturnLabelUrl` | varchar(8000) | Nein | URL des Retourenlabels. Wenn gesetzt, wird das MQ-Event `PackageLabelSaved` veröffentlicht. |\n| `ExternalShipmentId` | varchar(512) | Nein | Sendungs-ID in einem externen Versandsystem; wird unverändert gespeichert. |\n| `GrossWeight` | decimal(9, 3) | Nein | Bruttogewicht des Pakets; wird unverändert gespeichert. |\n| `ShipVendorCode` | varchar(3) | Nein | Code des Versanddienstleisters (`ShipVendor.ShipVendorCode`). Ohne Angabe wird der Versanddienstleister der Rechnung verwendet. Ein unbekannter Code führt zu einem Fehler. |\n| `PackageDimensionId` | int | Nein | ID einer Paketabmessung; wird ohne Prüfung gespeichert. |\n| `Lines` | varchar(max) | Nein | Optionales XML mit den im Paket enthaltenen Rechnungspositionen und Mengen. Jede `Line` benötigt eine ganzzahlige `InvlineId` (`Invlines.InvLineKey` dieser Rechnung) und eine positive ganzzahlige `Quantity`. |\n| `ResetClientNotifiedFlag` | bit | Nein | Wird an den Tracking-Abgleich übergeben; wirkt nur, wenn eine Tracking-ID übergeben wird. |\n| `Overwrite` | bit | Nein | Wird an den Tracking-Abgleich übergeben; steuert, wie `TrackingID` in `ShipmentTrackingID` der Rechnung geschrieben wird. |\n| `CreateEmp` | varchar(50) | Nein | Benutzername für die Audit-Spalten; wird in `UCS_USERS` gesucht, unbekannte Namen werden auf `pixiAdministration` abgebildet. |\n\n- Erfordert die Einstellung `Premium_API` = 1.\n- Die Prüfabfragen verwenden `NOLOCK`. Zwei gleichzeitige Aufrufe für dieselben Rechnungspositionen können daher beide die Mengenprüfung bestehen und eine Position überbuchen.\n- Die Prozedur startet eine eigene Transaktion bzw. setzt einen Savepoint, wenn der Aufrufer bereits eine Transaktion geöffnet hat. Die Erfolgszeile wird vor dem Commit ausgegeben.\n- Unerwartete SQL-Fehler werden abgefangen, die Transaktion (bzw. der Savepoint) wird zurückgerollt, der Fehler über `log.InsertError` protokolliert und als `ERROR`-Zeile mit dem SQL-Fehlertext geliefert.\n- Das Ergebnis von `pixiUpdateInvoicePackageTrackingIds` wird intern abgefangen und **nicht ausgewertet**. Meldet diese Prozedur ein Problem (z. B. Status `411`, weil die zusammengesetzte Tracking-Zeichenkette der Rechnung 512 Zeichen überschreiten würde), wird das Paket trotzdem angelegt und `SUCCESS` geliefert, die Tracking-Felder der Rechnung werden aber ggf. nicht aktualisiert.\n- Ein Code-Kommentar besagt, dass der Tracking-Abgleich nach dem Commit läuft; tatsächlich läuft er innerhalb derselben Transaktion.\n- Enthält eine Tracking-ID mehrere durch `;` getrennte Werte, erhält das Paket selbst nur den letzten Wert (durch den Tracking-Abgleich gesetzt), die Rechnung dagegen den vollständigen Wert.\n- `ResetClientNotifiedFlag` = 1 wirkt nur zusammen mit einer Tracking-ID: In `OrderHistory` wird für den jeweils letzten `AUS`-Status der Auftragspositionen der Rechnung `ClientNotified` = `N` gesetzt, sodass der Versand erneut exportiert wird.\n- `CreateEmp` wird in `UCS_USERS` gesucht; unbekannte Namen werden auf den Benutzer `pixiAdministration` abgebildet.\n- `PackageDimensionId`, `GrossWeight` und `ExternalShipmentId` werden ohne Prüfung gespeichert.\n- MQ-Events werden nur gesendet, wenn `pixiMQ_Enabled` aktiv ist und die Events in `EventConfiguration` konfiguriert sind; Fehler dort ändern das Ergebnis nicht.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateInvoicePackage"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n SUCCESS\n Package created successfully.\n 4711\n \n"
}
]
},
{
"name": "pixiCreatePicklist",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Erstellt eine Pickliste auf Basis eines Picklistenprofils, entweder sofort oder über einen Eintrag in der Ausführungs-Warteschlange.\n\nStartet die Erstellung einer Pickliste mit den Einstellungen eines gespeicherten Picklistenprofils. Einzelne Profilwerte lassen sich über Parameter übersteuern.\n\n1. **Premium-API-Prüfung.** Die Einstellung `Premium_API` muss aktiv sein. Andernfalls wird eine `ERROR`-Zeile geliefert.\n2. **Profil.** Ist `ProfileId` angegeben (0 gilt als nicht angegeben), muss das Profil in `PL_Profile` existieren. Ohne Angabe wird das zuletzt geänderte Standardprofil (`PLP_Default = 1`) verwendet, das kein 1SS-Profil ist (`PLP_1SS = 0`).\n3. **Lager.** Eine leere `LocationId` wird zu `001`.\n4. **Auftragseinschränkung (optional).**\n - Nur `OrderNr`: Der Auftrag muss in `OrderHeader` existieren.\n - Nur `OrderNrExternal`: Ein Auftrag mit dieser externen Nummer muss existieren.\n - Beide: Ein Auftrag mit beiden Werten muss existieren. Danach wird nur `OrderNr` verwendet und `OrderNrExternal` geleert.\n - `OrderNr = 0` und eine leere `OrderNrExternal` gelten als nicht angegeben.\n5. **Lagerplatzbereich (optional).** `BinFrom` und `BinTo` müssen Lagerplatznamen (`InvBin.BinName`) im gewählten Lager sein. Ihre `BinSortNum` ersetzt den Lagerplatz-Sortierbereich des Profils.\n6. **Benutzer und Kommentar.** `UserName` wird getrimmt; ist er leer, wird `API` verwendet. `Comment` wird getrimmt und als Picklistenkommentar übernommen.\n7. **Profilparameter.** Alle Parameter des Profils werden geladen. Danach werden Lager, Profil-ID, Auftragseinschränkung, Lagerplatzbereich, Benutzername und Kommentar mit den Werten aus den Schritten 2–6 überschrieben.\n8. **Exklusive Sperre.** Der Aufruf fordert die Application-Lock `ExclusivePickListCreation` ohne Wartezeit an. Hält eine andere Session die Sperre, wird eine `ERROR`-Zeile geliefert.\n9. **Ausführung.** Aus der aktuellen Zeit wird eine Ausführungsnummer im Format `yyMMddHHmmss` gebildet.\n - `ExecuteAsynchronous = 1` (Standard): Eine Anweisung `EXEC dbo.Pixi_CreatePickList …` mit allen Parametern wird in `ExecQueries` geschrieben. Es wird eine `INFO`-Zeile geliefert.\n - `ExecuteAsynchronous = 0`: `Pixi_CreatePickList` wird sofort ausgeführt. Die Prozedur liest ihre Parameter aus der temporären Parametertabelle.\n\nAnschließend wird die Sperre freigegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ProfileId` | smallint | Nein | Schlüssel des Picklistenprofils (`PL_Profile.PLP_Key`). Bei NULL oder 0 wird das zuletzt geänderte Standardprofil verwendet, das kein 1SS-Profil ist. |\n| `LocationId` | varchar(3) | Nein | Lager für die Pickliste. Bei NULL oder Leerstring wird `001` verwendet. |\n| `OrderNr` | int | Nein | Beschränkt die Pickliste auf diese Auftragsnummer. Bei NULL oder 0 gibt es keine Einschränkung. Der Auftrag muss existieren. |\n| `BinFrom` | varchar(50) | Nein | Name des ersten Lagerplatzes des Bereichs im gewählten Lager. Seine `BinSortNum` ersetzt die untere Lagerplatz-Sortiergrenze des Profils. |\n| `BinTo` | varchar(50) | Nein | Name des letzten Lagerplatzes des Bereichs im gewählten Lager. Seine `BinSortNum` ersetzt die obere Lagerplatz-Sortiergrenze des Profils. |\n| `UserName` | varchar(50) | Nein | Benutzer, der für die Picklistenerstellung vermerkt wird. Bei NULL oder Leerstring wird `API` verwendet. |\n| `Comment` | varchar(8000) | Nein | Kommentar der Pickliste (getrimmt). Ersetzt immer den Profilkommentar, auch wenn er leer ist. |\n| `ExecuteAsynchronous` | bit | Nein | Steuert, ob die Pickliste sofort erstellt oder in die Warteschlange gestellt wird. |\n| `OrderNrExternal` | varchar(50) | Nein | Beschränkt die Pickliste auf den Auftrag mit dieser externen Auftragsnummer. Leer bedeutet keine Einschränkung. Ist auch `OrderNr` angegeben, müssen beide zum selben Auftrag passen; danach wird nur `OrderNr` verwendet. |\n\n**Synchroner Modus (`ExecuteAsynchronous = 0`)**\n- Es wird keine `INFO`-Zeile geliefert.\n- Der Aufrufer erhält die Rückgabe von `Pixi_CreatePickList`. Diese Prozedur ist nicht beigefügt, daher sind ihre Ergebnismengen und weitere Nebeneffekte hier nicht dokumentiert.\n- Die Sperre ist an die Session gebunden. Bricht `Pixi_CreatePickList` mit einem Fehler ab, kann die Freigabe entfallen. Die Sperre bleibt dann bis zum Ende der Datenbank-Session bestehen.\n\n**Asynchroner Modus (Standard)**\n- Die Sperre wird nur während des Schreibens in die Warteschlange gehalten. Sie verhindert nicht, dass mehrere Picklistenerstellungen aus der Warteschlange gleichzeitig laufen.\n- Die Anweisung für die Warteschlange wird als Text zusammengesetzt. Hochkommas in Werten wie `Comment` oder `UserName` werden nicht maskiert und können die Anweisung ungültig machen.\n- Die Profilwerte `OlderThanHour`, `OlderThanMinute`, `NewerThanHour`, `NewerThanMinute` und `DisablePicklistSplitOnBatchManagement` werden in der Anweisung nicht übergeben.\n\n**Stolperfallen**\n- Die Lagerprüfung schlägt nie fehl. Existiert `LocationId` nicht, bleibt der übergebene Wert erhalten und die Lager-Fehlermeldung wird nie geliefert.\n- `Comment` überschreibt immer den Profilkommentar. Ohne Angabe wird der Kommentar aus dem Profil geleert.\n- Ein Leerstring für `BinFrom` oder `BinTo` gilt nicht als fehlend. Er wird als Lagerplatzname gesucht und führt zu einem Fehler.\n- Die Fehlermeldung zur Profil-ID lautet \"could be found\", gemeint ist jedoch, dass das Profil **nicht** gefunden wurde.\n\n**Sonstiges**\n- Alle Abfragen verwenden `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreatePicklist"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Erstellt eine Pickliste auf Basis eines Picklistenprofils, entweder sofort oder über einen Eintrag in der Ausführungs-Warteschlange.\n\nStartet die Erstellung einer Pickliste mit den Einstellungen eines gespeicherten Picklistenprofils. Einzelne Profilwerte lassen sich über Parameter übersteuern.\n\n1. **Premium-API-Prüfung.** Die Einstellung `Premium_API` muss aktiv sein. Andernfalls wird eine `ERROR`-Zeile geliefert.\n2. **Profil.** Ist `ProfileId` angegeben (0 gilt als nicht angegeben), muss das Profil in `PL_Profile` existieren. Ohne Angabe wird das zuletzt geänderte Standardprofil (`PLP_Default = 1`) verwendet, das kein 1SS-Profil ist (`PLP_1SS = 0`).\n3. **Lager.** Eine leere `LocationId` wird zu `001`.\n4. **Auftragseinschränkung (optional).**\n - Nur `OrderNr`: Der Auftrag muss in `OrderHeader` existieren.\n - Nur `OrderNrExternal`: Ein Auftrag mit dieser externen Nummer muss existieren.\n - Beide: Ein Auftrag mit beiden Werten muss existieren. Danach wird nur `OrderNr` verwendet und `OrderNrExternal` geleert.\n - `OrderNr = 0` und eine leere `OrderNrExternal` gelten als nicht angegeben.\n5. **Lagerplatzbereich (optional).** `BinFrom` und `BinTo` müssen Lagerplatznamen (`InvBin.BinName`) im gewählten Lager sein. Ihre `BinSortNum` ersetzt den Lagerplatz-Sortierbereich des Profils.\n6. **Benutzer und Kommentar.** `UserName` wird getrimmt; ist er leer, wird `API` verwendet. `Comment` wird getrimmt und als Picklistenkommentar übernommen.\n7. **Profilparameter.** Alle Parameter des Profils werden geladen. Danach werden Lager, Profil-ID, Auftragseinschränkung, Lagerplatzbereich, Benutzername und Kommentar mit den Werten aus den Schritten 2–6 überschrieben.\n8. **Exklusive Sperre.** Der Aufruf fordert die Application-Lock `ExclusivePickListCreation` ohne Wartezeit an. Hält eine andere Session die Sperre, wird eine `ERROR`-Zeile geliefert.\n9. **Ausführung.** Aus der aktuellen Zeit wird eine Ausführungsnummer im Format `yyMMddHHmmss` gebildet.\n - `ExecuteAsynchronous = 1` (Standard): Eine Anweisung `EXEC dbo.Pixi_CreatePickList …` mit allen Parametern wird in `ExecQueries` geschrieben. Es wird eine `INFO`-Zeile geliefert.\n - `ExecuteAsynchronous = 0`: `Pixi_CreatePickList` wird sofort ausgeführt. Die Prozedur liest ihre Parameter aus der temporären Parametertabelle.\n\nAnschließend wird die Sperre freigegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ProfileId` | smallint | Nein | Schlüssel des Picklistenprofils (`PL_Profile.PLP_Key`). Bei NULL oder 0 wird das zuletzt geänderte Standardprofil verwendet, das kein 1SS-Profil ist. |\n| `LocationId` | varchar(3) | Nein | Lager für die Pickliste. Bei NULL oder Leerstring wird `001` verwendet. |\n| `OrderNr` | int | Nein | Beschränkt die Pickliste auf diese Auftragsnummer. Bei NULL oder 0 gibt es keine Einschränkung. Der Auftrag muss existieren. |\n| `BinFrom` | varchar(50) | Nein | Name des ersten Lagerplatzes des Bereichs im gewählten Lager. Seine `BinSortNum` ersetzt die untere Lagerplatz-Sortiergrenze des Profils. |\n| `BinTo` | varchar(50) | Nein | Name des letzten Lagerplatzes des Bereichs im gewählten Lager. Seine `BinSortNum` ersetzt die obere Lagerplatz-Sortiergrenze des Profils. |\n| `UserName` | varchar(50) | Nein | Benutzer, der für die Picklistenerstellung vermerkt wird. Bei NULL oder Leerstring wird `API` verwendet. |\n| `Comment` | varchar(8000) | Nein | Kommentar der Pickliste (getrimmt). Ersetzt immer den Profilkommentar, auch wenn er leer ist. |\n| `ExecuteAsynchronous` | bit | Nein | Steuert, ob die Pickliste sofort erstellt oder in die Warteschlange gestellt wird. |\n| `OrderNrExternal` | varchar(50) | Nein | Beschränkt die Pickliste auf den Auftrag mit dieser externen Auftragsnummer. Leer bedeutet keine Einschränkung. Ist auch `OrderNr` angegeben, müssen beide zum selben Auftrag passen; danach wird nur `OrderNr` verwendet. |\n\n**Synchroner Modus (`ExecuteAsynchronous = 0`)**\n- Es wird keine `INFO`-Zeile geliefert.\n- Der Aufrufer erhält die Rückgabe von `Pixi_CreatePickList`. Diese Prozedur ist nicht beigefügt, daher sind ihre Ergebnismengen und weitere Nebeneffekte hier nicht dokumentiert.\n- Die Sperre ist an die Session gebunden. Bricht `Pixi_CreatePickList` mit einem Fehler ab, kann die Freigabe entfallen. Die Sperre bleibt dann bis zum Ende der Datenbank-Session bestehen.\n\n**Asynchroner Modus (Standard)**\n- Die Sperre wird nur während des Schreibens in die Warteschlange gehalten. Sie verhindert nicht, dass mehrere Picklistenerstellungen aus der Warteschlange gleichzeitig laufen.\n- Die Anweisung für die Warteschlange wird als Text zusammengesetzt. Hochkommas in Werten wie `Comment` oder `UserName` werden nicht maskiert und können die Anweisung ungültig machen.\n- Die Profilwerte `OlderThanHour`, `OlderThanMinute`, `NewerThanHour`, `NewerThanMinute` und `DisablePicklistSplitOnBatchManagement` werden in der Anweisung nicht übergeben.\n\n**Stolperfallen**\n- Die Lagerprüfung schlägt nie fehl. Existiert `LocationId` nicht, bleibt der übergebene Wert erhalten und die Lager-Fehlermeldung wird nie geliefert.\n- `Comment` überschreibt immer den Profilkommentar. Ohne Angabe wird der Kommentar aus dem Profil geleert.\n- Ein Leerstring für `BinFrom` oder `BinTo` gilt nicht als fehlend. Er wird als Lagerplatzname gesucht und führt zu einem Fehler.\n- Die Fehlermeldung zur Profil-ID lautet \"could be found\", gemeint ist jedoch, dass das Profil **nicht** gefunden wurde.\n\n**Sonstiges**\n- Alle Abfragen verwenden `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreatePicklist"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n INFO\n Picklist creation added to the queue.\n \n"
}
]
},
{
"name": "pixiGetBoxItems",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100245\n 001\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die in eine Box gepackten Artikel, ermittelt über Boxnummer und Lager, mit Auftrags-, Auftragspositions-, Artikel- und Scandaten.\n\nListet den Inhalt einer Packbox auf.\n\n1. `BoxNr` und `LocId` müssen beide angegeben werden. Ist einer der Werte `NULL`, wird eine Statuszeile mit `Status` = `Error` zurückgegeben.\n2. Die Box wird in `boxes` über `BoxNr` und `LocationID` gesucht. Existiert keine Box, wird eine Statuszeile mit `Status` = `Error` zurückgegeben.\n3. Alle `boxitems`-Zeilen der Boxen mit dieser Nummer und diesem Lager werden gesammelt (Menge, Scanzeitpunkt, scannender Benutzer).\n4. Jede Boxposition wird mit ihrer Auftragsposition (`Orderlines`) verknüpft, um Pixi-Auftragsnummer, externe Auftragsnummer, Artikel und verwendete Picklistennummer zu ermitteln.\n5. Die Artikelstammdaten (`items`) liefern Barcode (`EANUPC`), Artikelname und Gewicht. `MeasuredWeight` ist das Artikelgewicht multipliziert mit der gepackten Menge.\n\nPro Boxposition wird eine Zeile geliefert. Eine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BoxNr` | int | Ja | Nummer der Box (`boxes.BoxNr`). |\n| `LocId` | varchar(3) | Ja | Lager-ID der Box (`boxes.LocationID`). |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können erscheinen.\n- Boxpositionen, deren Auftragsposition oder Artikel nicht mehr existiert, entfallen wegen Inner Joins ohne Hinweis.\n- Existiert die Box, enthält aber keine Artikel, wird eine leere Ergebnismenge geliefert (keine Statuszeile).\n- Die Existenzprüfung nutzt `TOP(1)`, die Positionsabfrage filtert jedoch nur nach Boxnummer und Lager. Teilen sich mehrere Boxen Nummer und Lager, werden die Positionen aller dieser Boxen geliefert.\n- `MeasuredWeight` ist kein gemessener Wert, sondern wird aus dem Artikelgewicht berechnet.\n- Die Spalte `oPicklistNumber` behält ihren internen Namen (kein Alias).\n- Bei Fehlern liefert die Prozedur den Rückgabewert 1.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetBoxItems"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100245\n 001\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die in eine Box gepackten Artikel, ermittelt über Boxnummer und Lager, mit Auftrags-, Auftragspositions-, Artikel- und Scandaten.\n\nListet den Inhalt einer Packbox auf.\n\n1. `BoxNr` und `LocId` müssen beide angegeben werden. Ist einer der Werte `NULL`, wird eine Statuszeile mit `Status` = `Error` zurückgegeben.\n2. Die Box wird in `boxes` über `BoxNr` und `LocationID` gesucht. Existiert keine Box, wird eine Statuszeile mit `Status` = `Error` zurückgegeben.\n3. Alle `boxitems`-Zeilen der Boxen mit dieser Nummer und diesem Lager werden gesammelt (Menge, Scanzeitpunkt, scannender Benutzer).\n4. Jede Boxposition wird mit ihrer Auftragsposition (`Orderlines`) verknüpft, um Pixi-Auftragsnummer, externe Auftragsnummer, Artikel und verwendete Picklistennummer zu ermitteln.\n5. Die Artikelstammdaten (`items`) liefern Barcode (`EANUPC`), Artikelname und Gewicht. `MeasuredWeight` ist das Artikelgewicht multipliziert mit der gepackten Menge.\n\nPro Boxposition wird eine Zeile geliefert. Eine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BoxNr` | int | Ja | Nummer der Box (`boxes.BoxNr`). |\n| `LocId` | varchar(3) | Ja | Lager-ID der Box (`boxes.LocationID`). |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können erscheinen.\n- Boxpositionen, deren Auftragsposition oder Artikel nicht mehr existiert, entfallen wegen Inner Joins ohne Hinweis.\n- Existiert die Box, enthält aber keine Artikel, wird eine leere Ergebnismenge geliefert (keine Statuszeile).\n- Die Existenzprüfung nutzt `TOP(1)`, die Positionsabfrage filtert jedoch nur nach Boxnummer und Lager. Teilen sich mehrere Boxen Nummer und Lager, werden die Positionen aller dieser Boxen geliefert.\n- `MeasuredWeight` ist kein gemessener Wert, sondern wird aus dem Artikelgewicht berechnet.\n- Die Spalte `oPicklistNumber` behält ihren internen Namen (kein Alias).\n- Bei Fehlern liefert die Prozedur den Rückgabewert 1.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetBoxItems"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 100245\n 584213\n SHOP-2024-10077\n 1923345\n 4006381333931\n Kugelschreiber blau\n 2\n 0.0400\n 2024-05-14T10:32:11\n mmueller\n 77812\n \n"
}
]
},
{
"name": "pixiGetInvoicePackage",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Versandpakete einer Rechnung (Labels, Tracking-IDs, Gewicht, Paketmaße), ausgewählt über Rechnungsnummer, Rechnungs-ID oder Paket-ID.\n\nLiest die zu einer Rechnung gespeicherten Pakete aus `pixi.InvoicePackage`, zusammen mit dem Code der Paketmaße, der externen Auftragsnummer und der Rechnungsnummer.\n\n**Parameterbehandlung und Prüfungen** (jede fehlgeschlagene Prüfung liefert eine einzelne `Status`/`Message`-Zeile mit `Status` = `Error`):\n\n1. Ein leeres `InvoiceNumber` wird als `NULL` behandelt. Mindestens einer der Parameter `InvoiceNumber`, `InvoiceId`, `PackageId` muss angegeben werden.\n2. `InvoiceNumber` wird in eine Rechnungs-ID aufgelöst (erster Treffer auf `InvoiceNr`).\n3. Ist `InvoiceId` oder die aufgelöste ID gesetzt, muss mindestens eine davon in `Invoices` existieren.\n4. Ist `PackageId` angegeben, muss das Paket existieren.\n5. Verweisen `InvoiceId` und `InvoiceNumber` auf unterschiedliche Rechnungen, schlägt der Aufruf fehl.\n6. Sind Paket und Rechnung angegeben, muss das Paket zu dieser Rechnung gehören.\n\n**Auswahl**\n\n- Die maßgebliche Rechnung ist `InvoiceId`, andernfalls die aus `InvoiceNumber` ermittelte Rechnung.\n- Geliefert werden alle Pakete, deren Paket-ID `PackageId` entspricht **oder** deren Rechnungs-ID der maßgeblichen Rechnung entspricht. Ist eine Rechnung angegeben, werden alle ihre Pakete geliefert, auch wenn zusätzlich `PackageId` angegeben ist. Ist nur `PackageId` angegeben, wird nur dieses Paket geliefert.\n- `InvoiceNr` und `OrderNrExternal` sind in jeder Zeile gleich. Sie stammen von der Rechnung (direkt angegeben oder über das Paket), die mit Auftragspositionen verknüpft ist: `OrderNrExternal` kommt vom Auftrag mit der höchsten `Order_Id` der Rechnungspositionen.\n- Eine Sortierung ist nicht festgelegt.\n\nWird kein Paket gefunden, wird eine `Info`-Zeile geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNumber` | varchar(20) | Nein | Rechnungsnummer (`InvoiceNr`) der Rechnung, deren Pakete abgefragt werden. Ein Leerstring wird als `NULL` behandelt. |\n| `InvoiceId` | int | Nein | Interne Rechnungs-ID (`InvoiceKey`). Hat Vorrang vor der aus `InvoiceNumber` ermittelten ID. Sind beide angegeben, müssen sie auf dieselbe Rechnung verweisen. |\n| `PackageId` | int | Nein | ID eines Pakets in `pixi.InvoicePackage`. Ist zusätzlich eine Rechnung angegeben, muss das Paket zu ihr gehören. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Die Antwortstruktur unterscheidet sich: Bei Fehlern oder ohne Treffer wird statt der Paketzeilen eine `Status`/`Message`-Zeile geliefert. Auf eine Spalte `Status` prüfen.\n- Eine nicht existierende Rechnungsnummer wird ohne `InvoiceId` nicht als Fehler gemeldet. Ohne `PackageId` liefert der Aufruf dann die `Info`-Zeile. Mit `PackageId` liefert er nur dieses Paket.\n- Existiert `InvoiceId` nicht, ist aber `InvoiceNumber` gültig, lautet der Fehler \"Two different invoices\" statt \"No invoice found\".\n- Eine Rechnung wird für `InvoiceNr`/`OrderNrExternal` ignoriert, wenn sie keine Rechnungspositionen hat oder eine ihrer Rechnungspositionen keinen Verweis auf eine Auftragsposition besitzt. Dann sind beide Spalten `NULL`, die Pakete werden aber trotzdem geliefert.\n- Der Rückgabewert ist 1 bei Fehlern und sonst 0. Er ist nicht Teil der SOAP-Ergebniszeilen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoicePackage"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Versandpakete einer Rechnung (Labels, Tracking-IDs, Gewicht, Paketmaße), ausgewählt über Rechnungsnummer, Rechnungs-ID oder Paket-ID.\n\nLiest die zu einer Rechnung gespeicherten Pakete aus `pixi.InvoicePackage`, zusammen mit dem Code der Paketmaße, der externen Auftragsnummer und der Rechnungsnummer.\n\n**Parameterbehandlung und Prüfungen** (jede fehlgeschlagene Prüfung liefert eine einzelne `Status`/`Message`-Zeile mit `Status` = `Error`):\n\n1. Ein leeres `InvoiceNumber` wird als `NULL` behandelt. Mindestens einer der Parameter `InvoiceNumber`, `InvoiceId`, `PackageId` muss angegeben werden.\n2. `InvoiceNumber` wird in eine Rechnungs-ID aufgelöst (erster Treffer auf `InvoiceNr`).\n3. Ist `InvoiceId` oder die aufgelöste ID gesetzt, muss mindestens eine davon in `Invoices` existieren.\n4. Ist `PackageId` angegeben, muss das Paket existieren.\n5. Verweisen `InvoiceId` und `InvoiceNumber` auf unterschiedliche Rechnungen, schlägt der Aufruf fehl.\n6. Sind Paket und Rechnung angegeben, muss das Paket zu dieser Rechnung gehören.\n\n**Auswahl**\n\n- Die maßgebliche Rechnung ist `InvoiceId`, andernfalls die aus `InvoiceNumber` ermittelte Rechnung.\n- Geliefert werden alle Pakete, deren Paket-ID `PackageId` entspricht **oder** deren Rechnungs-ID der maßgeblichen Rechnung entspricht. Ist eine Rechnung angegeben, werden alle ihre Pakete geliefert, auch wenn zusätzlich `PackageId` angegeben ist. Ist nur `PackageId` angegeben, wird nur dieses Paket geliefert.\n- `InvoiceNr` und `OrderNrExternal` sind in jeder Zeile gleich. Sie stammen von der Rechnung (direkt angegeben oder über das Paket), die mit Auftragspositionen verknüpft ist: `OrderNrExternal` kommt vom Auftrag mit der höchsten `Order_Id` der Rechnungspositionen.\n- Eine Sortierung ist nicht festgelegt.\n\nWird kein Paket gefunden, wird eine `Info`-Zeile geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNumber` | varchar(20) | Nein | Rechnungsnummer (`InvoiceNr`) der Rechnung, deren Pakete abgefragt werden. Ein Leerstring wird als `NULL` behandelt. |\n| `InvoiceId` | int | Nein | Interne Rechnungs-ID (`InvoiceKey`). Hat Vorrang vor der aus `InvoiceNumber` ermittelten ID. Sind beide angegeben, müssen sie auf dieselbe Rechnung verweisen. |\n| `PackageId` | int | Nein | ID eines Pakets in `pixi.InvoicePackage`. Ist zusätzlich eine Rechnung angegeben, muss das Paket zu ihr gehören. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Die Antwortstruktur unterscheidet sich: Bei Fehlern oder ohne Treffer wird statt der Paketzeilen eine `Status`/`Message`-Zeile geliefert. Auf eine Spalte `Status` prüfen.\n- Eine nicht existierende Rechnungsnummer wird ohne `InvoiceId` nicht als Fehler gemeldet. Ohne `PackageId` liefert der Aufruf dann die `Info`-Zeile. Mit `PackageId` liefert er nur dieses Paket.\n- Existiert `InvoiceId` nicht, ist aber `InvoiceNumber` gültig, lautet der Fehler \"Two different invoices\" statt \"No invoice found\".\n- Eine Rechnung wird für `InvoiceNr`/`OrderNrExternal` ignoriert, wenn sie keine Rechnungspositionen hat oder eine ihrer Rechnungspositionen keinen Verweis auf eine Auftragsposition besitzt. Dann sind beide Spalten `NULL`, die Pakete werden aber trotzdem geliefert.\n- Der Rückgabewert ist 1 bei Fehlern und sonst 0. Er ist nicht Teil der SOAP-Ergebniszeilen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetInvoicePackage"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4321\n 98765\n 2.3500\n https://labels.example.com/4321.pdf\n 00340434161094042557\n 1\n https://labels.example.com/4321-return.pdf\n 00340434161094042558\n 3\n SHP-778899\n OK\n SHOP-100045\n RE2024-001234\n M\n \n"
}
]
},
{
"name": "pixiGetShippedOrdersPerLocation",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n 2024-01-01 00:00:00\n 2024-01-31 23:59:59\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert versendete Aufträge (auf Basis von Rechnungen) eines Zeitraums je Lager, entweder als Detailzeilen oder als Anzahl und Summe je Lager und Währung.\n\nErmittelt versendete Aufträge über ihre Rechnungen und gibt sie je Lager (`LocationID` der Auftragspositionen) aus.\n\n**Schritt 1 – Rechnungen auswählen.** Eine Rechnung wird berücksichtigt, wenn:\n- mindestens eine ihrer Rechnungspositionen zu einer Auftragsposition gehört, die einen `OrderHistory`-Eintrag mit Status `EIN` hat,\n- ihr Datum zwischen `@FromDate` und `@ToDate` liegt (inklusive). Bei `@SearchByScanOutDate = 1` wird das Scan-Out-Datum (`ScanOutDate`) verwendet, sonst das Rechnungsdatum (`InvDate`),\n- ihr `total` größer als 0 ist. Mit `@IncludeOrdersWithTotalZero = 1` werden zusätzlich Rechnungen mit Summe genau 0 einbezogen. Negative Summen werden nie berücksichtigt,\n- bei gesetztem `@CustomerNrExternal` (Leerzeichen werden entfernt, leer bedeutet kein Filter) der Kunde der Rechnung diese externe Kundennummer hat.\n\n**Schritt 2 – Aufträge je Rechnung und Lager.** Für jede ausgewählte Rechnung werden die eindeutigen Kombinationen aus `LocationID` und `OrderNrExternal` der Auftragspositionen auf der Rechnung gesammelt. Ist `@LocId` gesetzt, werden nur Auftragspositionen dieses Lagers berücksichtigt. Jede Kombination wird je Rechnung nach `OrderNrExternal` durchnummeriert.\n\n**Schritt 3 – Ausgabe.**\n- `@ShowDetails = 1` (Standard): eine Zeile je Rechnung, Lager und externer Auftragsnummer mit Rechnungsdaten, Kundenname, Lieferadresse, Währung, Versanddienstleister und Tracking-ID. Rechnungswerte wiederholen sich, wenn eine Rechnung mehrere externe Aufträge oder Lager enthält. Sortiert nach `InvDate`.\n- Jeder andere Wert: eine Zeile je Lager und Währung mit der Anzahl der Zeilen (`NrOfOrders`) und der Summe der Rechnungsbeträge (`Total`). Eine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShowDetails` | int | Nein | Ausgabemodus: `1` liefert Detailzeilen, jeder andere Wert liefert Anzahl und Summen je Lager und Währung. |\n| `FromDate` | varchar(25) | Ja | Beginn des Zeitraums (inklusive), verglichen mit Rechnungsdatum oder Scan-Out-Datum. |\n| `ToDate` | varchar(25) | Ja | Ende des Zeitraums (inklusive). Ohne Uhrzeit bedeutet der Wert Mitternacht zu Beginn dieses Tages. |\n| `CustomerNrExternal` | varchar(60) | Nein | Optionale externe Kundennummer; nur Rechnungen dieses Kunden werden geliefert. Leer bedeutet kein Filter. |\n| `IncludeOrdersWithTotalZero` | bit | Nein | Bei `1` werden auch Rechnungen mit Summe 0 berücksichtigt, sonst nur Rechnungen mit Summe größer 0. |\n| `SearchByScanOutDate` | bit | Nein | Legt fest, auf welches Datum sich der Zeitraum bezieht. |\n| `LocId` | varchar(3) | Nein | Optionale Lager-ID; nur Auftragspositionen dieses Lagers werden berücksichtigt. Leer bedeutet alle Lager. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- `@FromDate` und `@ToDate` sind `varchar`-Werte, die mit `BETWEEN` verglichen werden. Ein `@ToDate` ohne Uhrzeit (z. B. `2024-01-31`) bedeutet Mitternacht, spätere Rechnungen dieses Tages fehlen dann. Besser `2024-01-31 23:59:59` oder den Folgetag übergeben. Ein eindeutiges Format wie `yyyy-mm-dd hh:mi:ss` verwenden.\n- Im Summenmodus zählt `NrOfOrders` die Kombinationen aus Rechnung, Lager und externer Auftragsnummer, nicht eindeutige Rechnungen.\n- Im Summenmodus wird ein Rechnungsbetrag nur einmal je Rechnung gezählt: Er wird dem Lager der Kombination mit der alphabetisch ersten `OrderNrExternal` der Rechnung zugeordnet. Enthält eine Rechnung Auftragspositionen mehrerer Lager, fällt der gesamte Betrag nur einem Lager zu. Bei gesetztem `@LocId` erfolgt die Nummerierung nur über die gefilterten Zeilen, sodass der volle Rechnungsbetrag diesem Lager zugerechnet wird.\n- Rechnungen ohne zugehörigen Kunden werden ausgeschlossen; im Detailmodus zusätzlich Rechnungen ohne passende Lieferadresse (`ShipAdrRef`) oder Währung (Inner Joins).\n- Rechnungen, deren Auftragspositionen keinen `OrderHistory`-Status `EIN` haben, werden unabhängig vom Datum nicht geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetShippedOrdersPerLocation"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n 2024-01-01 00:00:00\n 2024-01-31 23:59:59\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert versendete Aufträge (auf Basis von Rechnungen) eines Zeitraums je Lager, entweder als Detailzeilen oder als Anzahl und Summe je Lager und Währung.\n\nErmittelt versendete Aufträge über ihre Rechnungen und gibt sie je Lager (`LocationID` der Auftragspositionen) aus.\n\n**Schritt 1 – Rechnungen auswählen.** Eine Rechnung wird berücksichtigt, wenn:\n- mindestens eine ihrer Rechnungspositionen zu einer Auftragsposition gehört, die einen `OrderHistory`-Eintrag mit Status `EIN` hat,\n- ihr Datum zwischen `@FromDate` und `@ToDate` liegt (inklusive). Bei `@SearchByScanOutDate = 1` wird das Scan-Out-Datum (`ScanOutDate`) verwendet, sonst das Rechnungsdatum (`InvDate`),\n- ihr `total` größer als 0 ist. Mit `@IncludeOrdersWithTotalZero = 1` werden zusätzlich Rechnungen mit Summe genau 0 einbezogen. Negative Summen werden nie berücksichtigt,\n- bei gesetztem `@CustomerNrExternal` (Leerzeichen werden entfernt, leer bedeutet kein Filter) der Kunde der Rechnung diese externe Kundennummer hat.\n\n**Schritt 2 – Aufträge je Rechnung und Lager.** Für jede ausgewählte Rechnung werden die eindeutigen Kombinationen aus `LocationID` und `OrderNrExternal` der Auftragspositionen auf der Rechnung gesammelt. Ist `@LocId` gesetzt, werden nur Auftragspositionen dieses Lagers berücksichtigt. Jede Kombination wird je Rechnung nach `OrderNrExternal` durchnummeriert.\n\n**Schritt 3 – Ausgabe.**\n- `@ShowDetails = 1` (Standard): eine Zeile je Rechnung, Lager und externer Auftragsnummer mit Rechnungsdaten, Kundenname, Lieferadresse, Währung, Versanddienstleister und Tracking-ID. Rechnungswerte wiederholen sich, wenn eine Rechnung mehrere externe Aufträge oder Lager enthält. Sortiert nach `InvDate`.\n- Jeder andere Wert: eine Zeile je Lager und Währung mit der Anzahl der Zeilen (`NrOfOrders`) und der Summe der Rechnungsbeträge (`Total`). Eine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShowDetails` | int | Nein | Ausgabemodus: `1` liefert Detailzeilen, jeder andere Wert liefert Anzahl und Summen je Lager und Währung. |\n| `FromDate` | varchar(25) | Ja | Beginn des Zeitraums (inklusive), verglichen mit Rechnungsdatum oder Scan-Out-Datum. |\n| `ToDate` | varchar(25) | Ja | Ende des Zeitraums (inklusive). Ohne Uhrzeit bedeutet der Wert Mitternacht zu Beginn dieses Tages. |\n| `CustomerNrExternal` | varchar(60) | Nein | Optionale externe Kundennummer; nur Rechnungen dieses Kunden werden geliefert. Leer bedeutet kein Filter. |\n| `IncludeOrdersWithTotalZero` | bit | Nein | Bei `1` werden auch Rechnungen mit Summe 0 berücksichtigt, sonst nur Rechnungen mit Summe größer 0. |\n| `SearchByScanOutDate` | bit | Nein | Legt fest, auf welches Datum sich der Zeitraum bezieht. |\n| `LocId` | varchar(3) | Nein | Optionale Lager-ID; nur Auftragspositionen dieses Lagers werden berücksichtigt. Leer bedeutet alle Lager. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- `@FromDate` und `@ToDate` sind `varchar`-Werte, die mit `BETWEEN` verglichen werden. Ein `@ToDate` ohne Uhrzeit (z. B. `2024-01-31`) bedeutet Mitternacht, spätere Rechnungen dieses Tages fehlen dann. Besser `2024-01-31 23:59:59` oder den Folgetag übergeben. Ein eindeutiges Format wie `yyyy-mm-dd hh:mi:ss` verwenden.\n- Im Summenmodus zählt `NrOfOrders` die Kombinationen aus Rechnung, Lager und externer Auftragsnummer, nicht eindeutige Rechnungen.\n- Im Summenmodus wird ein Rechnungsbetrag nur einmal je Rechnung gezählt: Er wird dem Lager der Kombination mit der alphabetisch ersten `OrderNrExternal` der Rechnung zugeordnet. Enthält eine Rechnung Auftragspositionen mehrerer Lager, fällt der gesamte Betrag nur einem Lager zu. Bei gesetztem `@LocId` erfolgt die Nummerierung nur über die gefilterten Zeilen, sodass der volle Rechnungsbetrag diesem Lager zugerechnet wird.\n- Rechnungen ohne zugehörigen Kunden werden ausgeschlossen; im Detailmodus zusätzlich Rechnungen ohne passende Lieferadresse (`ShipAdrRef`) oder Währung (Inner Joins).\n- Rechnungen, deren Auftragspositionen keinen `OrderHistory`-Status `EIN` haben, werden unabhängig vom Datum nicht geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetShippedOrdersPerLocation"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 240117\n 2024-01-15T10:22:00\n 2024-01-15T14:05:00\n 89.90\n 00340434161234567890\n Max Mustermann\n Hauptstr. 12\n München\n 80331\n DE\n SHOP-100512\n EUR\n DHL\n K-100245\n 001\n \n"
}
]
},
{
"name": "pixiGetShippingVendors",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die in Pixi angelegten Versanddienstleister, optional gefiltert nach Schlüssel, Name, Code oder Tracking-Kennzeichen, samt Typ des verbundenen Kanals.\n\nLiest die Versanddienstleister aus der Tabelle `ShipVendor`. Zu jedem Versanddienstleister wird zusätzlich der Name des Kanaltyps des verbundenen Kanals geliefert, sofern vorhanden.\n\n**Filterung**\n\n- Leere Werte gelten als „nicht gesetzt“. Das ist `0` bei `ShipVendorKey` und ein Leerstring bei den Textparametern.\n- Ist kein Parameter gesetzt, werden alle Versanddienstleister geliefert.\n- Sind ein oder mehrere Parameter gesetzt, wird ein Versanddienstleister geliefert, wenn **mindestens einer** der gesetzten Filter exakt passt. Die Filter sind mit **ODER** verknüpft, nicht mit UND.\n - `ShipVendorKey` muss dem angegebenen Schlüssel entsprechen.\n - `ShipVendorName` muss dem angegebenen Namen entsprechen.\n - `ShipVendorCode` muss dem angegebenen Code entsprechen.\n - `Tracking` muss dem angegebenen Kennzeichen entsprechen.\n\n**Kanaltyp**\n\nDie Prozedur verknüpft `ConnectedChannelId` des Versanddienstleisters mit der Kanaltabelle und anschließend mit der Kanaltyptabelle. `ChannelType` ist leer (NULL) bei Versanddienstleistern ohne verbundenen Kanal.\n\nEine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShipVendorKey` | int | Nein | Schlüssel des Versanddienstleisters. `0` bedeutet nicht gesetzt. |\n| `ShipVendorName` | varchar(50) | Nein | Exakter Name des Versanddienstleisters. Leerstring bedeutet nicht gesetzt. |\n| `ShipVendorCode` | varchar(3) | Nein | Exakter Code des Versanddienstleisters. Leerstring bedeutet nicht gesetzt. |\n| `Tracking` | varchar(1) | Nein | Exakter Wert des Tracking-Kennzeichens des Versanddienstleisters. Leerstring bedeutet nicht gesetzt. |\n\n- Da die Filter mit ODER verknüpft sind, kann das Ergebnis größer werden, wenn mehrere Filter gesetzt sind. Beispiel: `ShipVendorCode` = `UPS` und `Tracking` = `Y` liefert jeden UPS-Versanddienstleister sowie jeden Versanddienstleister mit aktiviertem Tracking. Zum Eingrenzen nur einen Filter setzen und clientseitig weiter filtern.\n- Die Vergleiche sind exakt. Platzhalter werden nicht unterstützt. Die Groß-/Kleinschreibung hängt von der Datenbank-Collation ab.\n- Der Code schränkt die Werte von `Tracking` nicht ein. Üblich ist ein einstelliges Kennzeichen wie `Y`/`N`, die Prozedur erzwingt das jedoch nicht.\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetShippingVendors"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die in Pixi angelegten Versanddienstleister, optional gefiltert nach Schlüssel, Name, Code oder Tracking-Kennzeichen, samt Typ des verbundenen Kanals.\n\nLiest die Versanddienstleister aus der Tabelle `ShipVendor`. Zu jedem Versanddienstleister wird zusätzlich der Name des Kanaltyps des verbundenen Kanals geliefert, sofern vorhanden.\n\n**Filterung**\n\n- Leere Werte gelten als „nicht gesetzt“. Das ist `0` bei `ShipVendorKey` und ein Leerstring bei den Textparametern.\n- Ist kein Parameter gesetzt, werden alle Versanddienstleister geliefert.\n- Sind ein oder mehrere Parameter gesetzt, wird ein Versanddienstleister geliefert, wenn **mindestens einer** der gesetzten Filter exakt passt. Die Filter sind mit **ODER** verknüpft, nicht mit UND.\n - `ShipVendorKey` muss dem angegebenen Schlüssel entsprechen.\n - `ShipVendorName` muss dem angegebenen Namen entsprechen.\n - `ShipVendorCode` muss dem angegebenen Code entsprechen.\n - `Tracking` muss dem angegebenen Kennzeichen entsprechen.\n\n**Kanaltyp**\n\nDie Prozedur verknüpft `ConnectedChannelId` des Versanddienstleisters mit der Kanaltabelle und anschließend mit der Kanaltyptabelle. `ChannelType` ist leer (NULL) bei Versanddienstleistern ohne verbundenen Kanal.\n\nEine Sortierung ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShipVendorKey` | int | Nein | Schlüssel des Versanddienstleisters. `0` bedeutet nicht gesetzt. |\n| `ShipVendorName` | varchar(50) | Nein | Exakter Name des Versanddienstleisters. Leerstring bedeutet nicht gesetzt. |\n| `ShipVendorCode` | varchar(3) | Nein | Exakter Code des Versanddienstleisters. Leerstring bedeutet nicht gesetzt. |\n| `Tracking` | varchar(1) | Nein | Exakter Wert des Tracking-Kennzeichens des Versanddienstleisters. Leerstring bedeutet nicht gesetzt. |\n\n- Da die Filter mit ODER verknüpft sind, kann das Ergebnis größer werden, wenn mehrere Filter gesetzt sind. Beispiel: `ShipVendorCode` = `UPS` und `Tracking` = `Y` liefert jeden UPS-Versanddienstleister sowie jeden Versanddienstleister mit aktiviertem Tracking. Zum Eingrenzen nur einen Filter setzen und clientseitig weiter filtern.\n- Die Vergleiche sind exakt. Platzhalter werden nicht unterstützt. Die Groß-/Kleinschreibung hängt von der Datenbank-Collation ab.\n- Der Code schränkt die Werte von `Tracking` nicht ein. Üblich ist ein einstelliges Kennzeichen wie `Y`/`N`, die Prozedur erzwingt das jedoch nicht.\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetShippingVendors"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 3\n UPS Standard\n UPS\n Y\n \n \n 5\n DHL Paket\n DHL\n Y\n Shopware\n \n"
}
]
},
{
"name": "pixiInvoiceSetTrackingIDforPolling",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n RE100234\n 00340434161094042557;00340434161094042558\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt eine oder mehrere Sendungsverfolgungsnummern auf einer Rechnung und deren Paketen, optional mit Ersetzen bestehender Pakete und erneuter Markierung des Auftrags für den Export.\n\nSpeichert Sendungsverfolgungsnummern zu einer Rechnung. Der Aufruf liefert keine Ergebnismenge.\n\n**1. Ermitteln der Rechnung**\n\n- Die Rechnung wird in `Invoices` über `InvoiceNR` gesucht.\n- Zusätzlich werden verkürzte Nummern geprüft. Dazu werden Suffixe nach dem letzten `-` schrittweise entfernt: `R1001-2-1`, dann `R1001-2`, dann `R1001`. Alle passenden Nummern werden geprüft.\n- Wird keine Rechnung gefunden, wird nichts geändert und der Aufruf endet ohne Fehler.\n\n**2. Trennzeichen**\n\n- Ist `Separator` nicht `;` und nicht leer, wird jedes Vorkommen in `TrackingID` durch `;` ersetzt.\n- `TrackingID` kann daher mehrere Sendungsverfolgungsnummern enthalten, z. B. getrennt durch `,` oder `|`.\n\n**3. Überschreiben (`Overwrite` = 1)**\n\n- Alle Rechnungspakete (`pixi.InvoicePackage`) der Rechnung werden gelöscht, zusammen mit ihren Paketpositionen (`pixi.InvoicePackageLines`).\n- Verweise auf diese Pakete in `InvoicePolling` werden auf `NULL` gesetzt.\n\n**4. Setzen der Sendungsverfolgungsnummern**\n\nDie interne Prozedur `Pixi_SetTrackingId` wird aufgerufen. Sie zerlegt die Liste und ignoriert Nummern, die bereits in `Invoices.ShipmentTrackingID` stehen.\n\nHat die Rechnung keine Pakete mit Artikeln aus einer Packstation:\n\n- Hat die Rechnung genau ein Paket ohne Sendungsverfolgungsnummer, erhält dieses Paket die erste neue Nummer.\n- Jede weitere neue Nummer legt ein neues Paket an.\n- `ShipmentTrackingID` der Rechnung wird aus den eindeutigen Nummern aller Pakete neu aufgebaut, sortiert und mit `;` getrennt.\n\nHat die Rechnung Pakete mit Artikeln:\n\n- Bei genau einem Paket erhält dieses Paket die letzte neue Nummer.\n- Bei mehreren Paketen bleiben die Pakete unverändert.\n- `ShipmentTrackingID` wird zur Vereinigung aus bestehenden und neuen Nummern.\n\nIn beiden Fällen gilt für die Rechnung außerdem:\n\n- `Packages` wird auf die Paketanzahl gesetzt.\n- `UpdateDate` und `UpdateEmp` (`TrackingID Import`) werden gesetzt.\n- Ein Ereignis `InvoiceChanged` wird veröffentlicht.\n\n**5. Erneuter Export (`ResetClientNotifiedFlag` = 1)**\n\n- Für jede Auftragsposition der Rechnung wird der jüngste `OrderHistory`-Eintrag mit Status `AUS` ermittelt.\n- Dessen Kennzeichen `ClientNotified` wird auf `N` gesetzt.\n- Der Versandstatus wird dadurch erneut exportiert, nun mit Sendungsverfolgungsnummer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNR` | varchar(20) | Ja | Rechnungsnummer. Suffixe nach `-` werden schrittweise entfernt, falls die vollständige Nummer nicht existiert. |\n| `TrackingID` | varchar(512) | Ja | Eine oder mehrere Sendungsverfolgungsnummern, getrennt durch `Separator`. |\n| `Overwrite` | bit | Nein | Bei 1 werden vor dem Setzen alle bestehenden Pakete und Paketpositionen der Rechnung gelöscht. |\n| `ResetClientNotifiedFlag` | bit | Nein | Bei 1 erhalten die jüngsten `AUS`-Einträge der Auftragshistorie der berechneten Positionen `ClientNotified` = `N` und werden erneut exportiert. |\n| `Separator` | varchar(1) | Nein | Zeichen, das mehrere Nummern in `TrackingID` trennt. Es wird intern in `;` umgewandelt. |\n\n- **Transaktion:** Der Aufruf läuft in einer eigenen Transaktion oder, falls bereits eine Transaktion offen ist, in einem Savepoint.\n- **Fehler werden nicht gemeldet:** Fehler werden abgefangen und in das Pixi-Fehlerprotokoll (`log.InsertError`) geschrieben. Sie werden nicht an den Aufrufer weitergegeben, ein fehlgeschlagener Aufruf sieht also wie ein erfolgreicher aus.\n- **Unbekannte Rechnung:** Eine unbekannte Rechnungsnummer wird stillschweigend ignoriert.\n- **Suffix-Suche:** Passen bei der Suche mehrere Nummern, behält die Variablenzuweisung über ein sortiertes Ergebnis in der Regel die letzte Zeile. Das ist die kürzeste passende Nummer, z. B. die Hauptrechnung `R1001` statt `R1001-2`. Mehrdeutige Nummern sollten vermieden werden.\n- **Stolperfalle bei `Overwrite`:** Die Pakete werden gelöscht, aber bereits in `Invoices.ShipmentTrackingID` gespeicherte Nummern gelten weiterhin als vorhanden und werden nicht erneut importiert. Werden solche Nummern mit `Overwrite` = 1 erneut übergeben, werden sie nicht als Pakete neu angelegt. Sie können aus `ShipmentTrackingID` verschwinden, das sogar `NULL` werden kann.\n- **Mehrere Pakete mit Artikeln:** Hat die Rechnung mehrere Pakete mit Artikeln, erhält kein Paket die neuen Nummern; nur der Rechnungskopf wird aktualisiert. Die interne Prozedur empfiehlt selbst, Sendungsverfolgungsnummern pro Paket zu setzen.\n- **Zerlegung:** Einzelne Nummern werden auf 512 Zeichen gekürzt. Die Zerlegung erfolgt über `dbo.fPixi_GetCommaSplit`, das nicht beigefügt ist.\n- **Sperrhinweise:** Lesezugriffe nutzen `NOLOCK`, Schreibzugriffe `ROWLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiInvoiceSetTrackingIDforPolling"
},
"response": []
},
{
"name": "pixiPutIntoBox",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n ?\n api_user\n \n 1\n 200\n ?\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Scannt eine einzelne Auftragsposition in eine Box ein (Scan-In mit Pickliste), teilt die Position bei Bedarf und prüft Charge und MHD.\n\nFührt den Scan-In einer Auftragsposition in eine Versandbox durch, so wie es der Pixi-Versandclient beim **Scan-In mit Pickliste** tut. Der Aufruf arbeitet mit genau der Auftragsposition aus `OrderlineKey`.\n\nAblauf:\n\n1. Prüft, ob die Einstellung `Premium_API` aktiv ist. Andernfalls wird eine Fehlerzeile geliefert.\n2. Liest Artikel und Lager der Auftragsposition. Ist die Einstellung `BatchManagement` gleich `1`, wird geprüft, ob der Artikel das Chargen-Tag (`TagId` -6) oder das MHD-Tag (`TagId` -7) trägt. Ohne eines dieser Tags gilt die Chargenverwaltung für diesen Artikel als deaktiviert.\n3. Ist die Chargenverwaltung deaktiviert, aber `BatchNumber` oder `BestBeforeDate` werden übergeben, endet der Aufruf mit `Wrong Batch Management data`.\n4. Ist die Chargenverwaltung aktiv, werden die aktiven Picklistenpositionen (`PLitem`, `Expired = 0`) der Auftragsposition gezählt, deren Lagerplatz-Artikel genau die übergebene Charge und das übergebene MHD haben. Gibt es keine, endet der Aufruf mit einem Fehler.\n5. Ist `PickListNr` gleich `0`, die Auftragsposition liegt aber auf einer aktiven Pickliste, endet der Aufruf mit `Item is part of picklist: …`.\n6. Sucht die Auftragsposition über die Scan-In-Suchlogik, eingeschränkt auf diese Position und die übergebene Pickliste. Die Position muss einen Status haben, der Scan-In erlaubt, darf nicht zu einem gesperrten Kunden oder einer gesperrten Adresse gehören (außer der Benutzer hat die Berechtigung `SHILC`) und muss bei Angabe einer Pickliste auf dieser liegen. Wird nichts gefunden: `No order found!`.\n7. Ermittelt die Menge, die in die Box gelegt wird:\n - die Picklistenmenge der Position, bei aktiver Chargenverwaltung begrenzt auf die Anzahl passender Chargen-Positionen;\n - ist `ScannedQty` ungleich `0`, darf sie diese Menge nicht überschreiten und ersetzt sie.\n8. Ist die Positionsmenge größer als diese Menge, wird die Auftragsposition geteilt, sodass der gescannte Teil die ermittelte Menge behält (`GOSBreakOrderline`).\n9. Ruft die interne Logik zum Einlegen in die Box auf (`Pixi_PutIntoBox`). Sie verwendet die Lagerbewegungsoperation `ScanInWithPicklist` der Anwendung `ShippingClient_A` und den Log-Grund `API - ScanIn with picklist`. Die Logik:\n - übernimmt `FromBox`/`ToBox` aus dem Picklistenkopf, falls dort ein Boxbereich hinterlegt ist;\n - sucht eine Box für den Kunden oder führt eine interne Umlagerung durch, wenn das Auftragslager vom letzten Auftragslager abweicht;\n - prüft, dass die Box keine Artikel eines anderen Kunden enthält und der Auftrag nicht bereits in einer anderen offenen Box liegt;\n - aktualisiert die Auftragsposition für den Scan-In und gibt die Picklistenpositionen vom Lagerplatz frei;\n - veröffentlicht das Message-Queue-Ereignis `ScanInPutIntoBox` und `ScanInBoxFull`, wenn die Box nun voll ist.\n\nErgebnis ist eine Zeile mit der Box und einem Wert in `Action`. `IN BOX LEGEN` bedeutet Erfolg; andere Werte beschreiben, warum der Artikel nicht in eine Box gelegt wurde.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Ja | Schlüssel der Auftragsposition, die in eine Box gescannt wird. |\n| `SupplGroup` | varchar(5) | Ja | Lieferantengruppe, die beim Scan-In gespeichert wird. Ist sie leer und der Positionsstatus `SHL`, wird die bereits an der Position gespeicherte Lieferantengruppe verwendet. |\n| `Username` | varchar(50) | Ja | Pixi-Benutzer, der den Scan-In durchführt. Wird für Berechtigungen, Protokollierung und die Aktualisierung der Position verwendet. |\n| `SupplOrderNr` | int | Nein | Lieferantenbestellnummer. Muss `0` sein; jeder andere Wert lässt die interne Positionssuche scheitern. |\n| `FromBox` | int | Ja | Niedrigste zu verwendende Boxnummer. Wird durch den Boxbereich der Pickliste ersetzt, falls der Picklistenkopf einen definiert. |\n| `ToBox` | int | Ja | Höchste zu verwendende Boxnummer. Wird durch den Boxbereich der Pickliste ersetzt, falls der Picklistenkopf einen definiert. |\n| `SerialNr` | varchar(200) | Ja | Seriennummer des gescannten Artikels. `NULL` wird als Leerstring behandelt. |\n| `PickListNr` | int | Nein | Picklistennummer (`PLHkey`). `0` bedeutet Scan-In ohne Pickliste; das wird abgelehnt, wenn die Position auf einer aktiven Pickliste liegt. |\n| `IsPersonalizedScanIn` | bit | Nein | Kennzeichnet den Scan-In eines personalisierten Artikels (Tag -1). Muss zum Tag des Artikels passen, sonst wird eine Fehleraktion geliefert. |\n| `BinRef` | int | Nein | Lagerplatz-Schlüssel, der beim Freigeben der Picklistenpositionen vom Lagerplatz weitergegeben wird. |\n| `BatchNumber` | varchar(50) | Nein | Charge des gescannten Artikels. Nur erlaubt, wenn die Chargenverwaltung für den Artikel aktiv ist; muss zu einer Picklistenposition der Auftragsposition passen. |\n| `BestBeforeDate` | datetime | Nein | MHD des gescannten Artikels. Nur erlaubt, wenn die Chargenverwaltung für den Artikel aktiv ist; muss zu einer Picklistenposition der Auftragsposition passen. |\n| `ScannedQty` | int | Nein | Gescannte Menge. `0` verwendet die volle Picklistenmenge der Position; sonst darf sie die Picklistenmenge nicht überschreiten, und die Position wird bei Bedarf geteilt. |\n\n- Erfordert die Einstellung `Premium_API`.\n- Alle Lesezugriffe verwenden `NOLOCK`.\n- Der Aufruf hat keine eigene Transaktion. Die Teilung der Auftragsposition in Schritt 8 läuft in einer eigenen Transaktion (mit Application-Lock auf der Position) und wird **vor** dem Einlegen in die Box festgeschrieben. Schlägt das Einlegen danach fehl, bleibt die Teilung bestehen.\n- Ohne Pickliste (`PickListNr = 0`) liefert die Scan-In-Suche eine Picklistenmenge von `0`. Jede `ScannedQty` ungleich `0` wird dann abgelehnt, und die Teilung wird mit der neuen Menge `0` aufgerufen. Was die Teilung in diesem Fall tut, hängt von `GOSBreakOrderline_Base` ab, das nicht vorliegt. Der Aufruf ist für den Scan-In mit Pickliste gedacht.\n- Jede `SupplOrderNr` ungleich `0` lässt die interne Positionssuche scheitern. Das Ergebnis ist dann `FEHLER` mit `0010. BESTELL. GEANDERT !`.\n- Ist `SupplGroup` leer und der Positionsstatus `SHL`, wird stattdessen die an der Position gespeicherte Lieferantengruppe (`SupplGroupScanIn`) verwendet. Der Wert wird als `varchar(4)` weitergegeben.\n- `BestBeforeDate` wird als 1900-01-01 weitergegeben, wenn es nicht übergeben wird. Ist die globale Einstellung `BatchManagement` gleich `1` und hat die Pickliste `DaysBeforeBBD` gesetzt, kann dieses Datum zu `MHD nicht zulässig` führen.\n- Die Einstellung `OnlyPicklistScanIn = 1` ohne Pickliste liefert die Aktion `Keine Pickliste`.\n- Deadlocks (Fehler 1205) beim Einlegen in die Box werden bis zu 10-mal wiederholt. Andere Fehler werden abgefangen, in `LogTable` protokolliert und als Aktionszeile statt als SQL-Fehler geliefert.\n- Mehrere aufgerufene Objekte liegen nicht vor: `Pixi_ShipToCustomer`, `Pixi_ShipIntern`, `GOSUpdateOrderlineForScanIn`, `Pixi_ReleasePLitemFromBin`, `GOSBreakOrderline_Base`, `pixi.FullBoxesGet` und `Pixi_MQ_EventPublish`. Deren genaue Datenänderungen und ob sie weitere Ergebnismengen oder Fehler erzeugen, sind nicht ersichtlich.\n- Bei einer internen Umlagerung (Auftragslager weicht vom letzten Auftragslager ab) wird kein Box-Schlüssel ermittelt, das Ergebnis zeigt daher `BoxNr` = 0.\n- Der Text `MHD nicht zulässig` ist im Quellcode falsch kodiert und kann als `MHD nicht zulässig` ankommen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiPutIntoBox"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n ?\n api_user\n \n 1\n 200\n ?\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Scannt eine einzelne Auftragsposition in eine Box ein (Scan-In mit Pickliste), teilt die Position bei Bedarf und prüft Charge und MHD.\n\nFührt den Scan-In einer Auftragsposition in eine Versandbox durch, so wie es der Pixi-Versandclient beim **Scan-In mit Pickliste** tut. Der Aufruf arbeitet mit genau der Auftragsposition aus `OrderlineKey`.\n\nAblauf:\n\n1. Prüft, ob die Einstellung `Premium_API` aktiv ist. Andernfalls wird eine Fehlerzeile geliefert.\n2. Liest Artikel und Lager der Auftragsposition. Ist die Einstellung `BatchManagement` gleich `1`, wird geprüft, ob der Artikel das Chargen-Tag (`TagId` -6) oder das MHD-Tag (`TagId` -7) trägt. Ohne eines dieser Tags gilt die Chargenverwaltung für diesen Artikel als deaktiviert.\n3. Ist die Chargenverwaltung deaktiviert, aber `BatchNumber` oder `BestBeforeDate` werden übergeben, endet der Aufruf mit `Wrong Batch Management data`.\n4. Ist die Chargenverwaltung aktiv, werden die aktiven Picklistenpositionen (`PLitem`, `Expired = 0`) der Auftragsposition gezählt, deren Lagerplatz-Artikel genau die übergebene Charge und das übergebene MHD haben. Gibt es keine, endet der Aufruf mit einem Fehler.\n5. Ist `PickListNr` gleich `0`, die Auftragsposition liegt aber auf einer aktiven Pickliste, endet der Aufruf mit `Item is part of picklist: …`.\n6. Sucht die Auftragsposition über die Scan-In-Suchlogik, eingeschränkt auf diese Position und die übergebene Pickliste. Die Position muss einen Status haben, der Scan-In erlaubt, darf nicht zu einem gesperrten Kunden oder einer gesperrten Adresse gehören (außer der Benutzer hat die Berechtigung `SHILC`) und muss bei Angabe einer Pickliste auf dieser liegen. Wird nichts gefunden: `No order found!`.\n7. Ermittelt die Menge, die in die Box gelegt wird:\n - die Picklistenmenge der Position, bei aktiver Chargenverwaltung begrenzt auf die Anzahl passender Chargen-Positionen;\n - ist `ScannedQty` ungleich `0`, darf sie diese Menge nicht überschreiten und ersetzt sie.\n8. Ist die Positionsmenge größer als diese Menge, wird die Auftragsposition geteilt, sodass der gescannte Teil die ermittelte Menge behält (`GOSBreakOrderline`).\n9. Ruft die interne Logik zum Einlegen in die Box auf (`Pixi_PutIntoBox`). Sie verwendet die Lagerbewegungsoperation `ScanInWithPicklist` der Anwendung `ShippingClient_A` und den Log-Grund `API - ScanIn with picklist`. Die Logik:\n - übernimmt `FromBox`/`ToBox` aus dem Picklistenkopf, falls dort ein Boxbereich hinterlegt ist;\n - sucht eine Box für den Kunden oder führt eine interne Umlagerung durch, wenn das Auftragslager vom letzten Auftragslager abweicht;\n - prüft, dass die Box keine Artikel eines anderen Kunden enthält und der Auftrag nicht bereits in einer anderen offenen Box liegt;\n - aktualisiert die Auftragsposition für den Scan-In und gibt die Picklistenpositionen vom Lagerplatz frei;\n - veröffentlicht das Message-Queue-Ereignis `ScanInPutIntoBox` und `ScanInBoxFull`, wenn die Box nun voll ist.\n\nErgebnis ist eine Zeile mit der Box und einem Wert in `Action`. `IN BOX LEGEN` bedeutet Erfolg; andere Werte beschreiben, warum der Artikel nicht in eine Box gelegt wurde.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Ja | Schlüssel der Auftragsposition, die in eine Box gescannt wird. |\n| `SupplGroup` | varchar(5) | Ja | Lieferantengruppe, die beim Scan-In gespeichert wird. Ist sie leer und der Positionsstatus `SHL`, wird die bereits an der Position gespeicherte Lieferantengruppe verwendet. |\n| `Username` | varchar(50) | Ja | Pixi-Benutzer, der den Scan-In durchführt. Wird für Berechtigungen, Protokollierung und die Aktualisierung der Position verwendet. |\n| `SupplOrderNr` | int | Nein | Lieferantenbestellnummer. Muss `0` sein; jeder andere Wert lässt die interne Positionssuche scheitern. |\n| `FromBox` | int | Ja | Niedrigste zu verwendende Boxnummer. Wird durch den Boxbereich der Pickliste ersetzt, falls der Picklistenkopf einen definiert. |\n| `ToBox` | int | Ja | Höchste zu verwendende Boxnummer. Wird durch den Boxbereich der Pickliste ersetzt, falls der Picklistenkopf einen definiert. |\n| `SerialNr` | varchar(200) | Ja | Seriennummer des gescannten Artikels. `NULL` wird als Leerstring behandelt. |\n| `PickListNr` | int | Nein | Picklistennummer (`PLHkey`). `0` bedeutet Scan-In ohne Pickliste; das wird abgelehnt, wenn die Position auf einer aktiven Pickliste liegt. |\n| `IsPersonalizedScanIn` | bit | Nein | Kennzeichnet den Scan-In eines personalisierten Artikels (Tag -1). Muss zum Tag des Artikels passen, sonst wird eine Fehleraktion geliefert. |\n| `BinRef` | int | Nein | Lagerplatz-Schlüssel, der beim Freigeben der Picklistenpositionen vom Lagerplatz weitergegeben wird. |\n| `BatchNumber` | varchar(50) | Nein | Charge des gescannten Artikels. Nur erlaubt, wenn die Chargenverwaltung für den Artikel aktiv ist; muss zu einer Picklistenposition der Auftragsposition passen. |\n| `BestBeforeDate` | datetime | Nein | MHD des gescannten Artikels. Nur erlaubt, wenn die Chargenverwaltung für den Artikel aktiv ist; muss zu einer Picklistenposition der Auftragsposition passen. |\n| `ScannedQty` | int | Nein | Gescannte Menge. `0` verwendet die volle Picklistenmenge der Position; sonst darf sie die Picklistenmenge nicht überschreiten, und die Position wird bei Bedarf geteilt. |\n\n- Erfordert die Einstellung `Premium_API`.\n- Alle Lesezugriffe verwenden `NOLOCK`.\n- Der Aufruf hat keine eigene Transaktion. Die Teilung der Auftragsposition in Schritt 8 läuft in einer eigenen Transaktion (mit Application-Lock auf der Position) und wird **vor** dem Einlegen in die Box festgeschrieben. Schlägt das Einlegen danach fehl, bleibt die Teilung bestehen.\n- Ohne Pickliste (`PickListNr = 0`) liefert die Scan-In-Suche eine Picklistenmenge von `0`. Jede `ScannedQty` ungleich `0` wird dann abgelehnt, und die Teilung wird mit der neuen Menge `0` aufgerufen. Was die Teilung in diesem Fall tut, hängt von `GOSBreakOrderline_Base` ab, das nicht vorliegt. Der Aufruf ist für den Scan-In mit Pickliste gedacht.\n- Jede `SupplOrderNr` ungleich `0` lässt die interne Positionssuche scheitern. Das Ergebnis ist dann `FEHLER` mit `0010. BESTELL. GEANDERT !`.\n- Ist `SupplGroup` leer und der Positionsstatus `SHL`, wird stattdessen die an der Position gespeicherte Lieferantengruppe (`SupplGroupScanIn`) verwendet. Der Wert wird als `varchar(4)` weitergegeben.\n- `BestBeforeDate` wird als 1900-01-01 weitergegeben, wenn es nicht übergeben wird. Ist die globale Einstellung `BatchManagement` gleich `1` und hat die Pickliste `DaysBeforeBBD` gesetzt, kann dieses Datum zu `MHD nicht zulässig` führen.\n- Die Einstellung `OnlyPicklistScanIn = 1` ohne Pickliste liefert die Aktion `Keine Pickliste`.\n- Deadlocks (Fehler 1205) beim Einlegen in die Box werden bis zu 10-mal wiederholt. Andere Fehler werden abgefangen, in `LogTable` protokolliert und als Aktionszeile statt als SQL-Fehler geliefert.\n- Mehrere aufgerufene Objekte liegen nicht vor: `Pixi_ShipToCustomer`, `Pixi_ShipIntern`, `GOSUpdateOrderlineForScanIn`, `Pixi_ReleasePLitemFromBin`, `GOSBreakOrderline_Base`, `pixi.FullBoxesGet` und `Pixi_MQ_EventPublish`. Deren genaue Datenänderungen und ob sie weitere Ergebnismengen oder Fehler erzeugen, sind nicht ersichtlich.\n- Bei einer internen Umlagerung (Auftragslager weicht vom letzten Auftragslager ab) wird kein Box-Schlüssel ermittelt, das Ergebnis zeigt daher `BoxNr` = 0.\n- Der Text `MHD nicht zulässig` ist im Quellcode falsch kodiert und kann als `MHD nicht zulässig` ankommen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiPutIntoBox"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n ERROR\n Item is part of picklist: 4711\n \n"
}
]
},
{
"name": "pixiSetOrderlinesInBoxToAUS",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Bucht einen Auftrag aus, der allein in genau einer Box liegt: setzt die Auftragspositionen der Box auf Status AUS und leert die Box.\n\nFührt das Ausbuchen (Scan-Out) eines in einer Box gesammelten Auftrags durch und leert die Box.\n\nAblauf:\n\n1. Ermittelt alle Boxen, die Auftragspositionen von `OrderNr` enthalten (über `boxitems`), sowie alle Aufträge, die in diesen Boxen liegen.\n2. Prüft, ob mindestens eine der Einstellungen `Premium_API` oder `Centralized_Ship_Out` aktiviert ist. Andernfalls wird ein Fehler zurückgegeben.\n3. Prüft, ob der Auftrag in genau einer Box liegt. Wird keine Box gefunden oder ist der Auftrag auf mehrere Boxen verteilt, wird ein Fehler zurückgegeben.\n4. Prüft, ob die Box keinen weiteren Auftrag enthält. Ist das der Fall, wird ein Fehler zurückgegeben.\n5. Liest die Lieferadresse der Box (`boxes.SAddrRef`) und prüft die Liefersperre. Geprüft werden das Kundenkennzeichen `Customers.SLocked` und das Adresskennzeichen `Addresses.ASLocked`. Steht eines davon auf `Y`, wird ein Fehler zurückgegeben.\n6. Sind alle Prüfungen bestanden, laufen drei interne Prozeduren:\n - `GOSScanOutOrderline` mit Status `AUS`. Sie setzt die Auftragspositionen der Box mit Status `EIN` auf `AUS`. Ebenso setzt sie Positionen derselben Rechnungen auf `AUS`, die den Status `MIN` oder einen in der Einstellung `PutThisStatusesOnInvoice` genannten Status haben. Für diese Positionen setzt sie `ShipDate`, aktualisiert den Auftragskopfstatus, schreibt die Auftragshistorie, löscht Reservierungen, aktualisiert Bundle-Positionen und schließt zugehörige Retourenpositionen und Retourenfälle.\n - `GOSDeleteAllItemsForBox` entfernt alle `boxitems` der Box.\n - `GOSEmptyBox` setzt die Box zurück: Kunde, Adressen und Auftrag werden auf 0 gesetzt, `BoxEndDate` auf das aktuelle Datum, und die Warte- und Sperrkennzeichen werden zurückgesetzt.\n\nDer Aufruf liefert immer genau eine Zeile mit `Status` (`SUCCESS` oder `ERROR`) und `Info`. `UserName` wird als ändernder Mitarbeiter in den geänderten Datensätzen gespeichert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Nummer des Auftrags, dessen Box ausgebucht und geleert werden soll. |\n| `UserName` | varchar(50) | Nein | Benutzername, der als ändernder Mitarbeiter in Auftragspositionen, Historie und Retourenfällen gespeichert wird. |\n\n- Die gesamte Verarbeitung läuft in der benannten Transaktion `OrderToAUS`. Bei einem Fehler in der Hauptprozedur wird sie zurückgerollt. Die zurückgegebene Zeile enthält dann `Status` = `ERROR` und den SQL-Fehlertext in `Info`. `Info` wird auf 150 Zeichen gekürzt.\n- Die aufgerufenen `GOS…`-Prozeduren fangen eigene Fehler ab und protokollieren sie über `log.InsertError`, ohne sie weiterzureichen. Ein Fehler darin kann daher (vollständig oder bis zu einem Savepoint) zurückgerollt werden, während der Aufruf trotzdem `SUCCESS` meldet. Im Zweifel die Daten prüfen.\n- Die Box- und Auftragszählungen stammen aus gruppierten Abfragen. Verwendet wird der Wert der zuletzt verarbeiteten Gruppe. In gemischten Fällen (z. B. mehrere Boxen mit mehreren Aufträgen) kann die konkret zurückgegebene Fehlermeldung variieren. Abgelehnt wird der Aufruf dennoch, solange der Auftrag nicht allein in einer einzigen Box liegt.\n- Lesezugriffe verwenden `NOLOCK`. Updates in den Unterprozeduren verwenden `ROWLOCK`. `GOSScanOutOrderline` unterdrückt den Update-Trigger auf `Orderlines` über `CONTEXT_INFO` und schreibt `OrderHistory` selbst.\n- Auch bei Prüfungsfehlern wird ein Commit ausgeführt; zu diesem Zeitpunkt wurde jedoch nichts geschrieben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetOrderlinesInBoxToAUS"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 104523\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Bucht einen Auftrag aus, der allein in genau einer Box liegt: setzt die Auftragspositionen der Box auf Status AUS und leert die Box.\n\nFührt das Ausbuchen (Scan-Out) eines in einer Box gesammelten Auftrags durch und leert die Box.\n\nAblauf:\n\n1. Ermittelt alle Boxen, die Auftragspositionen von `OrderNr` enthalten (über `boxitems`), sowie alle Aufträge, die in diesen Boxen liegen.\n2. Prüft, ob mindestens eine der Einstellungen `Premium_API` oder `Centralized_Ship_Out` aktiviert ist. Andernfalls wird ein Fehler zurückgegeben.\n3. Prüft, ob der Auftrag in genau einer Box liegt. Wird keine Box gefunden oder ist der Auftrag auf mehrere Boxen verteilt, wird ein Fehler zurückgegeben.\n4. Prüft, ob die Box keinen weiteren Auftrag enthält. Ist das der Fall, wird ein Fehler zurückgegeben.\n5. Liest die Lieferadresse der Box (`boxes.SAddrRef`) und prüft die Liefersperre. Geprüft werden das Kundenkennzeichen `Customers.SLocked` und das Adresskennzeichen `Addresses.ASLocked`. Steht eines davon auf `Y`, wird ein Fehler zurückgegeben.\n6. Sind alle Prüfungen bestanden, laufen drei interne Prozeduren:\n - `GOSScanOutOrderline` mit Status `AUS`. Sie setzt die Auftragspositionen der Box mit Status `EIN` auf `AUS`. Ebenso setzt sie Positionen derselben Rechnungen auf `AUS`, die den Status `MIN` oder einen in der Einstellung `PutThisStatusesOnInvoice` genannten Status haben. Für diese Positionen setzt sie `ShipDate`, aktualisiert den Auftragskopfstatus, schreibt die Auftragshistorie, löscht Reservierungen, aktualisiert Bundle-Positionen und schließt zugehörige Retourenpositionen und Retourenfälle.\n - `GOSDeleteAllItemsForBox` entfernt alle `boxitems` der Box.\n - `GOSEmptyBox` setzt die Box zurück: Kunde, Adressen und Auftrag werden auf 0 gesetzt, `BoxEndDate` auf das aktuelle Datum, und die Warte- und Sperrkennzeichen werden zurückgesetzt.\n\nDer Aufruf liefert immer genau eine Zeile mit `Status` (`SUCCESS` oder `ERROR`) und `Info`. `UserName` wird als ändernder Mitarbeiter in den geänderten Datensätzen gespeichert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Ja | Nummer des Auftrags, dessen Box ausgebucht und geleert werden soll. |\n| `UserName` | varchar(50) | Nein | Benutzername, der als ändernder Mitarbeiter in Auftragspositionen, Historie und Retourenfällen gespeichert wird. |\n\n- Die gesamte Verarbeitung läuft in der benannten Transaktion `OrderToAUS`. Bei einem Fehler in der Hauptprozedur wird sie zurückgerollt. Die zurückgegebene Zeile enthält dann `Status` = `ERROR` und den SQL-Fehlertext in `Info`. `Info` wird auf 150 Zeichen gekürzt.\n- Die aufgerufenen `GOS…`-Prozeduren fangen eigene Fehler ab und protokollieren sie über `log.InsertError`, ohne sie weiterzureichen. Ein Fehler darin kann daher (vollständig oder bis zu einem Savepoint) zurückgerollt werden, während der Aufruf trotzdem `SUCCESS` meldet. Im Zweifel die Daten prüfen.\n- Die Box- und Auftragszählungen stammen aus gruppierten Abfragen. Verwendet wird der Wert der zuletzt verarbeiteten Gruppe. In gemischten Fällen (z. B. mehrere Boxen mit mehreren Aufträgen) kann die konkret zurückgegebene Fehlermeldung variieren. Abgelehnt wird der Aufruf dennoch, solange der Auftrag nicht allein in einer einzigen Box liegt.\n- Lesezugriffe verwenden `NOLOCK`. Updates in den Unterprozeduren verwenden `ROWLOCK`. `GOSScanOutOrderline` unterdrückt den Update-Trigger auf `Orderlines` über `CONTEXT_INFO` und schreibt `OrderHistory` selbst.\n- Auch bei Prüfungsfehlern wird ein Commit ausgeführt; zu diesem Zeitpunkt wurde jedoch nichts geschrieben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetOrderlinesInBoxToAUS"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n SUCCESS\n Box: 17 was emptied. Order: 104523 was set to status AUS.\n \n"
}
]
},
{
"name": "pixiShipoutInvoice",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Führt den Versand (Ausscannen) einer Rechnung oder einer Box durch: aktualisiert Pakete, Versender, Gewicht und Tracking-IDs und gibt Bestand frei.\n\nFührt den vollständigen Versand (Ausscannen) einer Rechnung per API durch, identifiziert über `InvoiceNr`, über `BoxNr` oder über beide.\n\n**Vorbereitung und Prüfungen**\n- `BoxNr` = 0 wird wie NULL behandelt. `InvoiceNr`, `TrackingID` und `ShipVendorCode` werden getrimmt; leere Werte werden zu NULL.\n- Die Einstellung `Centralized_Ship_Out` oder `Premium_API` muss aktiv sein.\n- Mindestens einer der Parameter `InvoiceNr` / `BoxNr` ist erforderlich.\n- `LocID` muss in `Location` existieren; eine angegebene `BoxNr` muss in `boxes` existieren (an beliebigem Lager).\n- Die Rechnung wird über `InvoiceNr` am Lager `LocID` gesucht und zusätzlich über die Auftragspositionen in der Box `BoxNr` an diesem Lager. Berücksichtigt werden nur Rechnungspositionen, deren Auftragsposition nicht den Status `MIN` hat. Die Box ergibt sich aus den Boxpositionen dieser Auftragspositionen.\n- Wird keine Rechnung gefunden, wird `No invoice found` geliefert. Wird mehr als eine Kombination aus Rechnung/Box gefunden (z. B. Box enthält Positionen mehrerer Rechnungen, Rechnungspositionen liegen in mehreren Boxen oder nur teilweise in einer Box) oder weicht die gefundene Rechnung/Box von der angegebenen ab, wird eine Fehlerzeile geliefert.\n\n**Versand**\n1. Hat die Rechnung einen `RefToInvoiceKey`, wird Boxnummer -2 verwendet (das anschließende Ausscannen schlägt dann mit `0004. NO BOX !!!` fehl). Andernfalls wird eine vorhandene Box am Lager mit den Rechnungspositionen verwendet oder eine neue Box für die Rechnung angelegt. Ist der Kunde oder die Lieferadresse gesperrt oder die Rechnung bereits ausgescannt, ergibt sich eine negative Boxnummer und das Ausscannen schlägt ebenfalls fehl.\n2. Die Paketanzahl wird auf `AmountOfPackages` (mindestens 1) gesetzt; Rechnungspakete werden entsprechend ergänzt oder entfernt.\n3. Der Versender wird auf `ShipVendorCode` gesetzt (bzw. auf den aktuellen Versender der Rechnung, falls nicht angegeben).\n4. Die Box wird ausgescannt: Sperr- und Zahlungsprüfung, Ausscannen der Rechnung, Auftragspositionen auf Status `AUS`, Box geleert, Picklisten-Box-Einträge entfernt, Poll-Datensätze erzeugt.\n5. Nur wenn das Ausscannen nicht `ERROR` liefert:\n - das Gewicht wird auf Rechnung und Pakete geschrieben (nur wenn die Einstellung `CalculateWeightFromItems` nicht aktiv ist; ohne `Weight` wird das aktuelle `PackageGrossWeight` der Rechnung verwendet),\n - `TrackingID` (semikolongetrennte Liste) wird an den Rechnungspaketen und der Rechnung gespeichert,\n - auf der Pickliste reservierter Bestand wird über die Lagerbewegungsoperation `DirectInvoicesWizard` der Anwendung `ShippingClient_A` freigegeben (Benutzer `Shipout (API)`),\n - bei Direktrechnungen (`InvCreationMode` = `Direct`) wird die Box samt Positionen gelöscht.\n\nDer Aufruf liefert genau eine Zeile mit `Status` und `StatusMessage`. Bei Erfolg ist `Status` = `OK` und `StatusMessage` leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Nein | Nummer der zu versendenden Rechnung. Dieser Parameter oder `BoxNr` muss angegeben werden. |\n| `UserName` | varchar(50) | Nein | Benutzername, der bei Box-Anlage, Ausscannen und Tracking-ID-Aktualisierung gespeichert wird. |\n| `LocID` | char(3) | Nein | Lager-ID. Rechnung und Box werden an diesem Lager gesucht. Bei NULL wird das Lager der Rechnung verwendet. |\n| `BoxNr` | int | Nein | Nummer der Box mit den Auftragspositionen der Rechnung. 0 wird wie NULL behandelt. Dieser Parameter oder `InvoiceNr` muss angegeben werden. |\n| `Weight` | float | Nein | Bruttogewicht für Rechnung und Pakete. Bei NULL wird das aktuelle `PackageGrossWeight` der Rechnung verwendet. Wird ignoriert, wenn die Einstellung `CalculateWeightFromItems` aktiv ist. |\n| `AmountOfPackages` | int | Nein | Anzahl der Pakete der Rechnung. Werte kleiner 1 werden als 1 behandelt. |\n| `ShipVendorCode` | varchar(3) | Nein | Versendercode, der an der Rechnung gesetzt wird. Ohne Angabe bleibt der aktuelle Versender der Rechnung erhalten. |\n| `TrackingID` | varchar(8000) | Nein | Eine oder mehrere Tracking-IDs, durch Semikolon getrennt. Werden nur nach erfolgreichem Ausscannen gespeichert. |\n\n- Der Aufruf läuft **nicht in einer gemeinsamen Transaktion**. Paketanzahl und Versender werden *vor* dem Ausscannen aktualisiert und bleiben geändert, auch wenn das Ausscannen `ERROR` liefert. Eine für die Rechnung angelegte Box kann ebenfalls bestehen bleiben.\n- Der Parameter `BoxNr` dient nur zum Finden der Rechnung und zur Prüfung der Kombination; die tatsächlich ausgescannte Box wird intern ermittelt (vorhandene Box mit den Rechnungspositionen am Lager `LocID` oder neu angelegte Box).\n- Bereits ausgescannte Rechnungen, Rechnungen mit `RefToInvoiceKey` sowie Rechnungen gesperrter Kunden/Adressen enden mit `0004. NO BOX !!!` statt mit einer spezifischen Meldung.\n- Der Fehler `Invoice ... could not be found on location ...` ist praktisch nicht erreichbar, da ein leeres Ergebnis bereits als `No invoice found` gemeldet wird.\n- Wird `LocID` als NULL übergeben, wird das Lager der Rechnung verwendet; Fehlermeldungen, die `LocID` verketten, wären dann NULL.\n- Zur Laufzeit gelesene Einstellungen: `Centralized_Ship_Out`, `Premium_API`, `CalculateWeightFromItems`; in aufgerufenen Prozeduren zusätzlich `EnableMultiInvoiceShipOut`, `DoNotReleaseStockOnDirectInvoiceScanOut` und Einstellung `7` (Standardgewicht 0.1, falls Gewicht 0).\n- Das Ausscannen wird bei Deadlocks bis zu fünfmal wiederholt; andere SQL-Fehler werden protokolliert und ausgelöst (Rückgabe als `SqlMessage`).\n- Lesezugriffe mit `NOLOCK`; beim Ausscannen wird die Box-Zeile mit `UPDLOCK` gesperrt. Pakete werden unter dem App-Lock `PixiInvoicePackage` (Timeout 30 s) aktualisiert.\n- Beim Setzen von Tracking-IDs kann das Ereignis `InvoiceChanged` veröffentlicht werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiShipoutInvoice"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Führt den Versand (Ausscannen) einer Rechnung oder einer Box durch: aktualisiert Pakete, Versender, Gewicht und Tracking-IDs und gibt Bestand frei.\n\nFührt den vollständigen Versand (Ausscannen) einer Rechnung per API durch, identifiziert über `InvoiceNr`, über `BoxNr` oder über beide.\n\n**Vorbereitung und Prüfungen**\n- `BoxNr` = 0 wird wie NULL behandelt. `InvoiceNr`, `TrackingID` und `ShipVendorCode` werden getrimmt; leere Werte werden zu NULL.\n- Die Einstellung `Centralized_Ship_Out` oder `Premium_API` muss aktiv sein.\n- Mindestens einer der Parameter `InvoiceNr` / `BoxNr` ist erforderlich.\n- `LocID` muss in `Location` existieren; eine angegebene `BoxNr` muss in `boxes` existieren (an beliebigem Lager).\n- Die Rechnung wird über `InvoiceNr` am Lager `LocID` gesucht und zusätzlich über die Auftragspositionen in der Box `BoxNr` an diesem Lager. Berücksichtigt werden nur Rechnungspositionen, deren Auftragsposition nicht den Status `MIN` hat. Die Box ergibt sich aus den Boxpositionen dieser Auftragspositionen.\n- Wird keine Rechnung gefunden, wird `No invoice found` geliefert. Wird mehr als eine Kombination aus Rechnung/Box gefunden (z. B. Box enthält Positionen mehrerer Rechnungen, Rechnungspositionen liegen in mehreren Boxen oder nur teilweise in einer Box) oder weicht die gefundene Rechnung/Box von der angegebenen ab, wird eine Fehlerzeile geliefert.\n\n**Versand**\n1. Hat die Rechnung einen `RefToInvoiceKey`, wird Boxnummer -2 verwendet (das anschließende Ausscannen schlägt dann mit `0004. NO BOX !!!` fehl). Andernfalls wird eine vorhandene Box am Lager mit den Rechnungspositionen verwendet oder eine neue Box für die Rechnung angelegt. Ist der Kunde oder die Lieferadresse gesperrt oder die Rechnung bereits ausgescannt, ergibt sich eine negative Boxnummer und das Ausscannen schlägt ebenfalls fehl.\n2. Die Paketanzahl wird auf `AmountOfPackages` (mindestens 1) gesetzt; Rechnungspakete werden entsprechend ergänzt oder entfernt.\n3. Der Versender wird auf `ShipVendorCode` gesetzt (bzw. auf den aktuellen Versender der Rechnung, falls nicht angegeben).\n4. Die Box wird ausgescannt: Sperr- und Zahlungsprüfung, Ausscannen der Rechnung, Auftragspositionen auf Status `AUS`, Box geleert, Picklisten-Box-Einträge entfernt, Poll-Datensätze erzeugt.\n5. Nur wenn das Ausscannen nicht `ERROR` liefert:\n - das Gewicht wird auf Rechnung und Pakete geschrieben (nur wenn die Einstellung `CalculateWeightFromItems` nicht aktiv ist; ohne `Weight` wird das aktuelle `PackageGrossWeight` der Rechnung verwendet),\n - `TrackingID` (semikolongetrennte Liste) wird an den Rechnungspaketen und der Rechnung gespeichert,\n - auf der Pickliste reservierter Bestand wird über die Lagerbewegungsoperation `DirectInvoicesWizard` der Anwendung `ShippingClient_A` freigegeben (Benutzer `Shipout (API)`),\n - bei Direktrechnungen (`InvCreationMode` = `Direct`) wird die Box samt Positionen gelöscht.\n\nDer Aufruf liefert genau eine Zeile mit `Status` und `StatusMessage`. Bei Erfolg ist `Status` = `OK` und `StatusMessage` leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Nein | Nummer der zu versendenden Rechnung. Dieser Parameter oder `BoxNr` muss angegeben werden. |\n| `UserName` | varchar(50) | Nein | Benutzername, der bei Box-Anlage, Ausscannen und Tracking-ID-Aktualisierung gespeichert wird. |\n| `LocID` | char(3) | Nein | Lager-ID. Rechnung und Box werden an diesem Lager gesucht. Bei NULL wird das Lager der Rechnung verwendet. |\n| `BoxNr` | int | Nein | Nummer der Box mit den Auftragspositionen der Rechnung. 0 wird wie NULL behandelt. Dieser Parameter oder `InvoiceNr` muss angegeben werden. |\n| `Weight` | float | Nein | Bruttogewicht für Rechnung und Pakete. Bei NULL wird das aktuelle `PackageGrossWeight` der Rechnung verwendet. Wird ignoriert, wenn die Einstellung `CalculateWeightFromItems` aktiv ist. |\n| `AmountOfPackages` | int | Nein | Anzahl der Pakete der Rechnung. Werte kleiner 1 werden als 1 behandelt. |\n| `ShipVendorCode` | varchar(3) | Nein | Versendercode, der an der Rechnung gesetzt wird. Ohne Angabe bleibt der aktuelle Versender der Rechnung erhalten. |\n| `TrackingID` | varchar(8000) | Nein | Eine oder mehrere Tracking-IDs, durch Semikolon getrennt. Werden nur nach erfolgreichem Ausscannen gespeichert. |\n\n- Der Aufruf läuft **nicht in einer gemeinsamen Transaktion**. Paketanzahl und Versender werden *vor* dem Ausscannen aktualisiert und bleiben geändert, auch wenn das Ausscannen `ERROR` liefert. Eine für die Rechnung angelegte Box kann ebenfalls bestehen bleiben.\n- Der Parameter `BoxNr` dient nur zum Finden der Rechnung und zur Prüfung der Kombination; die tatsächlich ausgescannte Box wird intern ermittelt (vorhandene Box mit den Rechnungspositionen am Lager `LocID` oder neu angelegte Box).\n- Bereits ausgescannte Rechnungen, Rechnungen mit `RefToInvoiceKey` sowie Rechnungen gesperrter Kunden/Adressen enden mit `0004. NO BOX !!!` statt mit einer spezifischen Meldung.\n- Der Fehler `Invoice ... could not be found on location ...` ist praktisch nicht erreichbar, da ein leeres Ergebnis bereits als `No invoice found` gemeldet wird.\n- Wird `LocID` als NULL übergeben, wird das Lager der Rechnung verwendet; Fehlermeldungen, die `LocID` verketten, wären dann NULL.\n- Zur Laufzeit gelesene Einstellungen: `Centralized_Ship_Out`, `Premium_API`, `CalculateWeightFromItems`; in aufgerufenen Prozeduren zusätzlich `EnableMultiInvoiceShipOut`, `DoNotReleaseStockOnDirectInvoiceScanOut` und Einstellung `7` (Standardgewicht 0.1, falls Gewicht 0).\n- Das Ausscannen wird bei Deadlocks bis zu fünfmal wiederholt; andere SQL-Fehler werden protokolliert und ausgelöst (Rückgabe als `SqlMessage`).\n- Lesezugriffe mit `NOLOCK`; beim Ausscannen wird die Box-Zeile mit `UPDLOCK` gesperrt. Pakete werden unter dem App-Lock `PixiInvoicePackage` (Timeout 30 s) aktualisiert.\n- Beim Setzen von Tracking-IDs kann das Ereignis `InvoiceChanged` veröffentlicht werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiShipoutInvoice"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n \n \n"
}
]
},
{
"name": "pixiShippingGetPicklistDetails",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Positionen einer Pickliste, gruppiert nach Artikel, Lagerplatz und Auftragsposition, mit Lagerplatz-, Artikel-, Auftrags- und Kistendaten, optional gefiltert.\n\nLiest den Picklistenkopf (`PLheader`) mit dem Schlüssel `PicklistKey` zusammen mit seinen Picklistenpositionen (`PLItem`). Jede Position wird mit dem Lagerplatzbestand (`InvBinItem`), dem Artikel (`Items`), dem Lagerplatz (`InvBin`) und der Auftragsposition (`Orderlines`) verknüpft.\n\nDie Picklistenpositionen werden je Artikel, Lagerplatz und Auftragsposition gruppiert. `Qty` ist die Anzahl der Picklistenpositionen in der Gruppe. Die Artikelnummern (`ItemNrSuppl`, `EanUpc`, `ItemNrInt`) werden in Großbuchstaben geliefert.\n\nJe Gruppe werden zusätzlich geliefert:\n- `OtherItemsCount`: `1`, wenn auf dem Lagerplatz andere Artikel liegen, sonst `0`\n- `PLHfromBox` / `PLHtoBox` des Picklistenkopfs\n- `BundleItemName`: Name der Bundle-Auftragsposition oder Leerstring\n- `TotalItemsOnBin`: Gesamtmenge aller Artikel auf dem Lagerplatz\n- `TotalSimilarItemsOnBin`: Gesamtmenge dieses Artikels auf dem Lagerplatz\n\nOptionale Filter, die bei `NULL` oder Leerstring ignoriert werden:\n- `FilterLocation`: exakter Vergleich mit der Lager-ID des Lagerplatzes\n- `FilterBinGroup`: `LIKE`-Vergleich mit der Lagerplatzgruppe, Platzhalter wie `%` sind möglich\n- `FilterBinName`: `LIKE`-Vergleich mit dem Lagerplatznamen, Platzhalter wie `%` sind möglich\n\nDie Sortierung erfolgt nach `BinGroup`, `BinSortNum` und `ItemName`, was einer Laufreihenfolge durch das Lager entspricht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PicklistKey` | int | Nein | Schlüssel der Pickliste (`PLHkey`). `0` oder `NULL` liefert keine Zeilen. |\n| `FilterLocation` | varchar(3) | Nein | Optionale Lager-ID; nur Lagerplätze dieses Lagers werden geliefert (exakter Vergleich). Leerstring bedeutet kein Filter. |\n| `FilterBinGroup` | varchar(20) | Nein | Optionales Muster für die Lagerplatzgruppe, Vergleich mit `LIKE` (Platzhalter erlaubt). Leerstring bedeutet kein Filter. |\n| `FilterBinName` | varchar(50) | Nein | Optionales Muster für den Lagerplatznamen, Vergleich mit `LIKE` (Platzhalter erlaubt). Leerstring bedeutet kein Filter. |\n\n- `PicklistKey` hat den Standardwert `NULL`, auch `0` wird zu `NULL`. In beiden Fällen passt keine Pickliste, das Ergebnis ist leer. Praktisch muss der Parameter also übergeben werden.\n- Alle Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können daher erscheinen.\n- Die Spalte `PLIorderlineRef` kommt im Ergebnis zweimal vor (aus den gruppierten Daten und als zusätzliche Spalte). Je nach Client wird das zweite Vorkommen umbenannt (z. B. `PLIorderlineRef1`) oder überschreibt das erste; beide enthalten denselben Wert.\n- `OtherItemsCount` ist trotz des Namens ein Kennzeichen (`0`/`1`), keine Anzahl.\n- Die Gruppierung berücksichtigt auch den Ersteller der Pickliste und das Anlagedatum der Auftragsposition, die nicht ausgegeben werden; scheinbar identische Zeilen können daher mehrfach erscheinen.\n- Die Datentypen der meisten Spalten hängen von den Tabellendefinitionen ab, die nicht Teil des Codes sind.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiShippingGetPicklistDetails"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Positionen einer Pickliste, gruppiert nach Artikel, Lagerplatz und Auftragsposition, mit Lagerplatz-, Artikel-, Auftrags- und Kistendaten, optional gefiltert.\n\nLiest den Picklistenkopf (`PLheader`) mit dem Schlüssel `PicklistKey` zusammen mit seinen Picklistenpositionen (`PLItem`). Jede Position wird mit dem Lagerplatzbestand (`InvBinItem`), dem Artikel (`Items`), dem Lagerplatz (`InvBin`) und der Auftragsposition (`Orderlines`) verknüpft.\n\nDie Picklistenpositionen werden je Artikel, Lagerplatz und Auftragsposition gruppiert. `Qty` ist die Anzahl der Picklistenpositionen in der Gruppe. Die Artikelnummern (`ItemNrSuppl`, `EanUpc`, `ItemNrInt`) werden in Großbuchstaben geliefert.\n\nJe Gruppe werden zusätzlich geliefert:\n- `OtherItemsCount`: `1`, wenn auf dem Lagerplatz andere Artikel liegen, sonst `0`\n- `PLHfromBox` / `PLHtoBox` des Picklistenkopfs\n- `BundleItemName`: Name der Bundle-Auftragsposition oder Leerstring\n- `TotalItemsOnBin`: Gesamtmenge aller Artikel auf dem Lagerplatz\n- `TotalSimilarItemsOnBin`: Gesamtmenge dieses Artikels auf dem Lagerplatz\n\nOptionale Filter, die bei `NULL` oder Leerstring ignoriert werden:\n- `FilterLocation`: exakter Vergleich mit der Lager-ID des Lagerplatzes\n- `FilterBinGroup`: `LIKE`-Vergleich mit der Lagerplatzgruppe, Platzhalter wie `%` sind möglich\n- `FilterBinName`: `LIKE`-Vergleich mit dem Lagerplatznamen, Platzhalter wie `%` sind möglich\n\nDie Sortierung erfolgt nach `BinGroup`, `BinSortNum` und `ItemName`, was einer Laufreihenfolge durch das Lager entspricht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PicklistKey` | int | Nein | Schlüssel der Pickliste (`PLHkey`). `0` oder `NULL` liefert keine Zeilen. |\n| `FilterLocation` | varchar(3) | Nein | Optionale Lager-ID; nur Lagerplätze dieses Lagers werden geliefert (exakter Vergleich). Leerstring bedeutet kein Filter. |\n| `FilterBinGroup` | varchar(20) | Nein | Optionales Muster für die Lagerplatzgruppe, Vergleich mit `LIKE` (Platzhalter erlaubt). Leerstring bedeutet kein Filter. |\n| `FilterBinName` | varchar(50) | Nein | Optionales Muster für den Lagerplatznamen, Vergleich mit `LIKE` (Platzhalter erlaubt). Leerstring bedeutet kein Filter. |\n\n- `PicklistKey` hat den Standardwert `NULL`, auch `0` wird zu `NULL`. In beiden Fällen passt keine Pickliste, das Ergebnis ist leer. Praktisch muss der Parameter also übergeben werden.\n- Alle Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können daher erscheinen.\n- Die Spalte `PLIorderlineRef` kommt im Ergebnis zweimal vor (aus den gruppierten Daten und als zusätzliche Spalte). Je nach Client wird das zweite Vorkommen umbenannt (z. B. `PLIorderlineRef1`) oder überschreibt das erste; beide enthalten denselben Wert.\n- `OtherItemsCount` ist trotz des Namens ein Kennzeichen (`0`/`1`), keine Anzahl.\n- Die Gruppierung berücksichtigt auch den Ersteller der Pickliste und das Anlagedatum der Auftragsposition, die nicht ausgegeben werden; scheinbar identische Zeilen können daher mehrfach erscheinen.\n- Die Datentypen der meisten Spalten hängen von den Tabellendefinitionen ab, die nicht Teil des Codes sind.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiShippingGetPicklistDetails"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1234\n 4711\n 10\n T-Shirt Blue M\n A-01-03\n 553\n 2024-05-03T18:00:00\n 2024-05-02T09:15:00\n 2\n Express\n TS-BL-M\n 4012345678901\n 100234\n 553\n A\n 98765\n 001\n https://shop.example.com/img/s/100234.jpg\n https://shop.example.com/img/l/100234.jpg\n 50123\n WEB-2024-0815\n SKU-100234\n 0\n 3321\n 1\n 1\n 20\n 98765\n \n 35\n 12\n \n"
}
]
},
{
"name": "pixiShippingGetPicklistHeaders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Köpfe aller gültigen, nicht reservierten und vollständig erzeugten Picklisten eines Lagers mit erstem/letztem Lagerplatz und Artikelanzahl.\n\nLiefert je Picklistenkopf aus `PLHeader` eine Zeile, sofern die Pickliste aktuell zur Kommissionierung verwendbar ist.\n\n**Filter**\n- `PLHlocID` entspricht `@LocID`. Ist `LocID` leer oder nicht angegeben, wird das Lager `001` verwendet.\n- `PLHexpiryDate` liegt nach dem aktuellen Zeitpunkt (Pickliste nicht abgelaufen).\n- `ReservedOrderNr` ist `NULL` oder `0` (Pickliste ist für keinen Auftrag reserviert).\n- `PLcomment` ist nicht `DirectInvStockRelease`.\n- `ExecutionFinished = 1` (Erzeugung der Pickliste ist abgeschlossen).\n\n**Berechnete Spalten**\n- `FromBinName` / `ToBinName`: Name des Lagerplatzes mit der niedrigsten / höchsten `BinSortNum` unter den Lagerplätzen der Picklistenpositionen (`PLitem.pliBinRef`). Leerer String, wenn die Pickliste keine Positionen hat.\n- `HALcount`: Anzahl der Auftragspositionen von `ReservedOrderNr` mit Status `HAL`.\n- `Item number`: Anzahl der unterschiedlichen Kombinationen aus Artikel und Lagerplatz auf der Pickliste (ein Artikel zählt je Lagerplatz einmal). `0`, wenn keine Positionen vorhanden sind.\n- `ReservedOrderNr`, `IsReservationFull` und `PLHOriginalKey` werden statt `NULL` als `0` / `false` geliefert.\n\nDas Ergebnis hat keine explizite Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | Nein | Lager-ID, deren Picklisten geliefert werden. Leer oder nicht angegeben bedeutet `001`. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können erscheinen.\n- Da nur nicht reservierte Picklisten geliefert werden (`ReservedOrderNr` ist `NULL`/`0`), ist `HALcount` praktisch immer `0` (gezählt würden nur Positionen eines Auftrags mit Nummer `0`).\n- Picklisten mit `PLcomment = NULL` werden ebenfalls ausgeschlossen, da der Vergleich `<> 'DirectInvStockRelease'` für `NULL` nicht wahr ist.\n- Die Spalte `Item number` enthält ein Leerzeichen; im .NET-DataSet-XML der SOAP-Antwort erscheint sie üblicherweise als Element `Item_x0020_number`.\n- In `Item number` werden nur Positionen gezählt, deren `InvBinItem`- und `Items`-Datensätze existieren; `FromBinName`/`ToBinName` berücksichtigen nur Positionen, deren Lagerplatz in `InvBin` existiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiShippingGetPicklistHeaders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Köpfe aller gültigen, nicht reservierten und vollständig erzeugten Picklisten eines Lagers mit erstem/letztem Lagerplatz und Artikelanzahl.\n\nLiefert je Picklistenkopf aus `PLHeader` eine Zeile, sofern die Pickliste aktuell zur Kommissionierung verwendbar ist.\n\n**Filter**\n- `PLHlocID` entspricht `@LocID`. Ist `LocID` leer oder nicht angegeben, wird das Lager `001` verwendet.\n- `PLHexpiryDate` liegt nach dem aktuellen Zeitpunkt (Pickliste nicht abgelaufen).\n- `ReservedOrderNr` ist `NULL` oder `0` (Pickliste ist für keinen Auftrag reserviert).\n- `PLcomment` ist nicht `DirectInvStockRelease`.\n- `ExecutionFinished = 1` (Erzeugung der Pickliste ist abgeschlossen).\n\n**Berechnete Spalten**\n- `FromBinName` / `ToBinName`: Name des Lagerplatzes mit der niedrigsten / höchsten `BinSortNum` unter den Lagerplätzen der Picklistenpositionen (`PLitem.pliBinRef`). Leerer String, wenn die Pickliste keine Positionen hat.\n- `HALcount`: Anzahl der Auftragspositionen von `ReservedOrderNr` mit Status `HAL`.\n- `Item number`: Anzahl der unterschiedlichen Kombinationen aus Artikel und Lagerplatz auf der Pickliste (ein Artikel zählt je Lagerplatz einmal). `0`, wenn keine Positionen vorhanden sind.\n- `ReservedOrderNr`, `IsReservationFull` und `PLHOriginalKey` werden statt `NULL` als `0` / `false` geliefert.\n\nDas Ergebnis hat keine explizite Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | Nein | Lager-ID, deren Picklisten geliefert werden. Leer oder nicht angegeben bedeutet `001`. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können erscheinen.\n- Da nur nicht reservierte Picklisten geliefert werden (`ReservedOrderNr` ist `NULL`/`0`), ist `HALcount` praktisch immer `0` (gezählt würden nur Positionen eines Auftrags mit Nummer `0`).\n- Picklisten mit `PLcomment = NULL` werden ebenfalls ausgeschlossen, da der Vergleich `<> 'DirectInvStockRelease'` für `NULL` nicht wahr ist.\n- Die Spalte `Item number` enthält ein Leerzeichen; im .NET-DataSet-XML der SOAP-Antwort erscheint sie üblicherweise als Element `Item_x0020_number`.\n- In `Item number` werden nur Positionen gezählt, deren `InvBinItem`- und `Items`-Datensätze existieren; `FromBinName`/`ToBinName` berücksichtigen nur Positionen, deren Lagerplatz in `InvBin` existiert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiShippingGetPicklistHeaders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4711\n 001\n 2024-05-14T18:00:00\n MM\n 2024-05-14T08:12:30\n MM\n 2024-05-14T08:13:05\n 1\n 20\n 0\n false\n Morning wave\n 0\n 0\n A-01-01\n C-12-04\n 0\n 37\n \n"
}
]
},
{
"name": "pixiUpdateInvoicePackage",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 48211\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Tracking-IDs, Label-URLs und Providermeldungen eines Rechnungspakets und überträgt die Tracking-IDs auf die zugehörige Rechnung.\n\nSchreibt das Ergebnis eines Versanddienstleisters (Trackingnummer, Label-URLs, Providermeldungen) in ein Paket einer Rechnung (`pixi.InvoicePackage`) und in die Rechnung selbst (`dbo.Invoices`).\n\nAblauf:\n\n1. Alle als Leerstring übergebenen Textparameter werden als `NULL` (= nicht übergeben) behandelt.\n2. Das Paket `PackageId` muss existieren, andernfalls wird eine `400`-Antwort geliefert.\n3. Wird `InvoiceKey` übergeben, muss er zur Rechnung des Pakets passen, andernfalls wird eine `400`-Antwort geliefert. Ohne Angabe wird die Rechnung des Pakets verwendet.\n4. **Paket-Update:** `TrackingID`, `ReturnTrackingId`, `ExternalShipmentId`, `MessageFromProvider` und `MessageFromProviderDetail` werden nur mit übergebenen Werten überschrieben; nicht übergebene Werte bleiben erhalten. `ShippingLabelUrl` und `ReturnLabelUrl` erhalten den neuen Wert oder behalten den aktuellen. Bei Paketen eines Versanddienstleisters mit External-Label-Funktionalität (Funktionalitätsversion 3), die über eine Toolbox-Station versendet wurden, wird `ShippingLabelUrl` auf `NO URL FROM PROVIDER` gesetzt, wenn überhaupt keine URL vorhanden ist. `RecordModifiedOn` und `RecordModifiedByUserId` (Benutzer `API`) werden gesetzt.\n5. **Rechnungs-Update:**\n - `ShipmentTrackingID`: ist das Feld leer, wird es auf `TrackingId` gesetzt; sonst wird `TrackingId` mit `;` angehängt, sofern der vorhandene Wert sie noch nicht enthält.\n - `retTrackID` / `retTrackIDhist`: ist `retTrackID` leer, wird `retTrackID` auf `ReturnTrackingId` und die Historie auf `ReturnTrackingId;` gesetzt. Andernfalls wird die neue ID, falls noch nicht in `retTrackID` enthalten, an die Historie angehängt und `retTrackID` ersetzt.\n - `UpdateDate` und `UpdateEmp` (`TrackingID API Import`) werden gesetzt.\n6. Bei `ResetClientNotifiedFlag` = 1 wird der jeweils letzte `AUS`-Eintrag (ausgeliefert) der Auftragshistorie jeder Auftragsposition der Rechnung auf `ClientNotified = 'N'` zurückgesetzt, damit der Auftrag erneut mit Tracking-ID exportiert wird.\n7. Eine Zeile mit `Response` = `200 OK` wird geliefert und die Transaktion festgeschrieben.\n8. Nach dem Commit werden MQ-Events veröffentlicht: `PackageLabelSaved` (nur bei External-Label-Paketen mit Toolbox-Station, mit Kennzeichen, ob sich Versand- oder Retouren-Label-URL geändert hat) und immer `InvoiceChanged` mit Parameter `SetTrackingId`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PackageId` | int | Ja | ID des Rechnungspakets (`pixi.InvoicePackage.Id`), das aktualisiert wird. |\n| `InvoiceKey` | int | Nein | Optionaler Rechnungsschlüssel zur Prüfung. Wird er übergeben, muss er zur Rechnung des Pakets passen; ohne Angabe wird die Rechnung des Pakets verwendet. |\n| `ShippingLabelUrl` | varchar(8000) | Nein | URL des Versandlabels. Leer oder nicht übergeben behält die aktuelle URL. |\n| `TrackingId` | varchar(512) | Nein | Trackingnummer der Sendung. Überschreibt die Tracking-ID des Pakets und wird an `Invoices.ShipmentTrackingID` angehängt, falls noch nicht enthalten. |\n| `ReturnLabelUrl` | varchar(8000) | Nein | URL des Retourenlabels. Leer oder nicht übergeben behält die aktuelle URL. |\n| `ReturnTrackingId` | varchar(512) | Nein | Trackingnummer des Retourenlabels. Wird in das Paket sowie in `Invoices.retTrackID` / `retTrackIDhist` geschrieben. |\n| `ExternalShipmentId` | varchar(512) | Nein | Sendungs-ID beim Versanddienstleister. Wird nur überschrieben, wenn übergeben. |\n| `MessageFromProvider` | varchar(max) | Nein | Meldung des Versanddienstleisters. Wird nur überschrieben, wenn übergeben. |\n| `MessageFromProviderDetail` | varchar(max) | Nein | Detailmeldung des Versanddienstleisters. Wird nur überschrieben, wenn übergeben. |\n| `ResetClientNotifiedFlag` | bit | Nein | Bei 1 werden die letzten `AUS`-Einträge der Auftragshistorie der Auftragspositionen der Rechnung auf `ClientNotified = 'N'` gesetzt, damit der Versand erneut mit Tracking-ID exportiert wird. |\n\n- Läuft in einer eigenen Transaktion (bzw. einem Savepoint, falls bereits eine Transaktion offen ist). Ein exklusiver Application Lock `PixiInvoicePackage` (Timeout 30 s) serialisiert den Aufruf mit anderen Paket-Updates; kann der Lock nicht erlangt werden, wird das Update trotzdem ausgeführt.\n- Deadlocks (Fehler 1205) werden bis zu 5-mal mit 5 ms Verzögerung wiederholt. Andere Fehler werden über `log.InsertError` protokolliert und mit `500 Internal Server Error` beantwortet. In seltenen Fehlersituationen nach der `200 OK`-Zeile (z. B. beim Commit oder Event-Versand) kann mehr als ein `Response`-Resultset geliefert werden.\n- Die Duplikatprüfung der Tracking-IDs ist ein Teilstring-Vergleich per `LIKE`: Eine ID, die Teil einer vorhandenen ID ist (z. B. `123` in `12345`), wird nicht an die Rechnung angehängt; `%` oder `_` in IDs wirken als Platzhalter.\n- `InvoicePackage.TrackingID` wird überschrieben, während `Invoices.ShipmentTrackingID` alle IDs mit `;` getrennt sammelt.\n- Hat die Rechnung noch keine Retouren-Tracking-ID, wird `retTrackIDhist` durch die neue ID ersetzt (nicht ergänzt).\n- Während des Rechnungs-Updates wird `CONTEXT_INFO` auf `0x11111` gesetzt, vermutlich um Trigger auf `dbo.Invoices` zu beeinflussen.\n- Lesezugriffe erfolgen mit `NOLOCK`.\n- MQ-Events werden nur gesendet, wenn die Einstellung `pixiMQ_Enabled` aktiv ist und die Events in `EventConfiguration` konfiguriert und aktiviert sind.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateInvoicePackage"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 48211\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Tracking-IDs, Label-URLs und Providermeldungen eines Rechnungspakets und überträgt die Tracking-IDs auf die zugehörige Rechnung.\n\nSchreibt das Ergebnis eines Versanddienstleisters (Trackingnummer, Label-URLs, Providermeldungen) in ein Paket einer Rechnung (`pixi.InvoicePackage`) und in die Rechnung selbst (`dbo.Invoices`).\n\nAblauf:\n\n1. Alle als Leerstring übergebenen Textparameter werden als `NULL` (= nicht übergeben) behandelt.\n2. Das Paket `PackageId` muss existieren, andernfalls wird eine `400`-Antwort geliefert.\n3. Wird `InvoiceKey` übergeben, muss er zur Rechnung des Pakets passen, andernfalls wird eine `400`-Antwort geliefert. Ohne Angabe wird die Rechnung des Pakets verwendet.\n4. **Paket-Update:** `TrackingID`, `ReturnTrackingId`, `ExternalShipmentId`, `MessageFromProvider` und `MessageFromProviderDetail` werden nur mit übergebenen Werten überschrieben; nicht übergebene Werte bleiben erhalten. `ShippingLabelUrl` und `ReturnLabelUrl` erhalten den neuen Wert oder behalten den aktuellen. Bei Paketen eines Versanddienstleisters mit External-Label-Funktionalität (Funktionalitätsversion 3), die über eine Toolbox-Station versendet wurden, wird `ShippingLabelUrl` auf `NO URL FROM PROVIDER` gesetzt, wenn überhaupt keine URL vorhanden ist. `RecordModifiedOn` und `RecordModifiedByUserId` (Benutzer `API`) werden gesetzt.\n5. **Rechnungs-Update:**\n - `ShipmentTrackingID`: ist das Feld leer, wird es auf `TrackingId` gesetzt; sonst wird `TrackingId` mit `;` angehängt, sofern der vorhandene Wert sie noch nicht enthält.\n - `retTrackID` / `retTrackIDhist`: ist `retTrackID` leer, wird `retTrackID` auf `ReturnTrackingId` und die Historie auf `ReturnTrackingId;` gesetzt. Andernfalls wird die neue ID, falls noch nicht in `retTrackID` enthalten, an die Historie angehängt und `retTrackID` ersetzt.\n - `UpdateDate` und `UpdateEmp` (`TrackingID API Import`) werden gesetzt.\n6. Bei `ResetClientNotifiedFlag` = 1 wird der jeweils letzte `AUS`-Eintrag (ausgeliefert) der Auftragshistorie jeder Auftragsposition der Rechnung auf `ClientNotified = 'N'` zurückgesetzt, damit der Auftrag erneut mit Tracking-ID exportiert wird.\n7. Eine Zeile mit `Response` = `200 OK` wird geliefert und die Transaktion festgeschrieben.\n8. Nach dem Commit werden MQ-Events veröffentlicht: `PackageLabelSaved` (nur bei External-Label-Paketen mit Toolbox-Station, mit Kennzeichen, ob sich Versand- oder Retouren-Label-URL geändert hat) und immer `InvoiceChanged` mit Parameter `SetTrackingId`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PackageId` | int | Ja | ID des Rechnungspakets (`pixi.InvoicePackage.Id`), das aktualisiert wird. |\n| `InvoiceKey` | int | Nein | Optionaler Rechnungsschlüssel zur Prüfung. Wird er übergeben, muss er zur Rechnung des Pakets passen; ohne Angabe wird die Rechnung des Pakets verwendet. |\n| `ShippingLabelUrl` | varchar(8000) | Nein | URL des Versandlabels. Leer oder nicht übergeben behält die aktuelle URL. |\n| `TrackingId` | varchar(512) | Nein | Trackingnummer der Sendung. Überschreibt die Tracking-ID des Pakets und wird an `Invoices.ShipmentTrackingID` angehängt, falls noch nicht enthalten. |\n| `ReturnLabelUrl` | varchar(8000) | Nein | URL des Retourenlabels. Leer oder nicht übergeben behält die aktuelle URL. |\n| `ReturnTrackingId` | varchar(512) | Nein | Trackingnummer des Retourenlabels. Wird in das Paket sowie in `Invoices.retTrackID` / `retTrackIDhist` geschrieben. |\n| `ExternalShipmentId` | varchar(512) | Nein | Sendungs-ID beim Versanddienstleister. Wird nur überschrieben, wenn übergeben. |\n| `MessageFromProvider` | varchar(max) | Nein | Meldung des Versanddienstleisters. Wird nur überschrieben, wenn übergeben. |\n| `MessageFromProviderDetail` | varchar(max) | Nein | Detailmeldung des Versanddienstleisters. Wird nur überschrieben, wenn übergeben. |\n| `ResetClientNotifiedFlag` | bit | Nein | Bei 1 werden die letzten `AUS`-Einträge der Auftragshistorie der Auftragspositionen der Rechnung auf `ClientNotified = 'N'` gesetzt, damit der Versand erneut mit Tracking-ID exportiert wird. |\n\n- Läuft in einer eigenen Transaktion (bzw. einem Savepoint, falls bereits eine Transaktion offen ist). Ein exklusiver Application Lock `PixiInvoicePackage` (Timeout 30 s) serialisiert den Aufruf mit anderen Paket-Updates; kann der Lock nicht erlangt werden, wird das Update trotzdem ausgeführt.\n- Deadlocks (Fehler 1205) werden bis zu 5-mal mit 5 ms Verzögerung wiederholt. Andere Fehler werden über `log.InsertError` protokolliert und mit `500 Internal Server Error` beantwortet. In seltenen Fehlersituationen nach der `200 OK`-Zeile (z. B. beim Commit oder Event-Versand) kann mehr als ein `Response`-Resultset geliefert werden.\n- Die Duplikatprüfung der Tracking-IDs ist ein Teilstring-Vergleich per `LIKE`: Eine ID, die Teil einer vorhandenen ID ist (z. B. `123` in `12345`), wird nicht an die Rechnung angehängt; `%` oder `_` in IDs wirken als Platzhalter.\n- `InvoicePackage.TrackingID` wird überschrieben, während `Invoices.ShipmentTrackingID` alle IDs mit `;` getrennt sammelt.\n- Hat die Rechnung noch keine Retouren-Tracking-ID, wird `retTrackIDhist` durch die neue ID ersetzt (nicht ergänzt).\n- Während des Rechnungs-Updates wird `CONTEXT_INFO` auf `0x11111` gesetzt, vermutlich um Trigger auf `dbo.Invoices` zu beeinflussen.\n- Lesezugriffe erfolgen mit `NOLOCK`.\n- MQ-Events werden nur gesendet, wenn die Einstellung `pixiMQ_Enabled` aktiv ist und die Events in `EventConfiguration` konfiguriert und aktiviert sind.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateInvoicePackage"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 200 OK\n \n"
}
]
}
]
},
{
"name": "Statistics",
"item": [
{
"name": "pixiAdminGetCULStatistics",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die maximale Anzahl gleichzeitig lizenzierter Benutzer (CULs) pro Stunde oder pro Tag seit einem Startdatum, aufgeteilt nach Pixi-Client-Anwendung.\n\nWertet die Sitzungs-Snapshots in `UsersLoggedIn` aus und liefert, wie viele lizenzrelevante Benutzer gleichzeitig angemeldet waren.\n\n**Zeitraum**\n- Ist `StartDate` leer, wird der früheste `Tag` aller Desktop-/Web-Sitzungen (`UserActiveSessionTypeId` 1 oder 2) verwendet.\n- Es wird ein Kalenderraster von heute zurück bis `StartDate` erzeugt: eine Zeile pro Tag und Stunde 0–23 bei `Hourly` = 1, bzw. eine Zeile pro Tag (Stunde 0) bei `Hourly` = 0.\n\n**Gezählte Sitzungen**\n- Sitzungstyp 1 (Desktop) oder 2 (Web) mit `Tag` nach `StartDate`.\n- Die Anwendung (`AppName`) muss in `ExeClientVersion` mit `LicenceNeeded` = 1 hinterlegt sein, und der Lizenzmanager für ihren Sitzungstyp muss aktiv sein: Einstellung `pixiLicencesManager` für Desktop-Clients, `pixiLicencesManagerWeb` für den Web-Client.\n- Rechner aus `MasterUsers` sowie der Pixi-Benutzer `master` werden ausgeschlossen.\n\n**Berechnung**\n1. Sitzungen werden pro Snapshot (`Tag`) gezählt; eine Sitzung pro `Tag`/`SessionId`/Pixi-Benutzer.\n2. Pro Stunde wird der höchste Snapshot-Wert als `CULs` übernommen.\n3. Pro Tag wird der höchste Stundenwert als `CULsPerDay` an der Stunde vermerkt, in der er zuerst erreicht wurde.\n4. Tage ohne Nutzung erhalten eine Zeile mit `CULs` = 0 und `CULsPerDay` = 0.\n5. Die Spalten pro Anwendung zählen die Sitzungen des Spitzen-Snapshots der Stunde, zugeordnet über den Programmnamen (z. B. `PPOS2.exe` → `POS`, `pixi.Presentation.Web` → `Web`).\n\n**Ausgabe**\n- `Hourly` = 1: eine Zeile pro Tag und Stunde; `CULsPerDay` ist nur in der Spitzenstunde des Tages gefüllt, sonst `NULL`.\n- `Hourly` = 0: eine Zeile pro Tag mit dem Tagesmaximum in `CULs` und `CULsPerDay`; `Hour` ist immer 0.\n- Sortierung nach `Date` aufsteigend, danach nach der Stunde der Nutzungsdaten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | Nein | Beginn des Auswertungszeitraums. Gezählt werden nur Sitzungen mit späterem `Tag`. Ist der Wert leer, wird der früheste Sitzungs-Snapshot aus `UsersLoggedIn` verwendet. |\n| `Hourly` | bit | Nein | Wählt stündliche oder tägliche Ausgabe. |\n\n- Nur lesend; alle Tabellen werden `WITH (NOLOCK)` gelesen, das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Ist weder `pixiLicencesManager` noch `pixiLicencesManagerWeb` auf `1` gesetzt, wird keine Sitzung gezählt und alle Werte sind 0.\n- Enthält `UsersLoggedIn` keine passenden Sitzungen und wird kein `StartDate` übergeben, lässt sich der Zeitraum nicht bestimmen und das Ergebnis ist leer.\n- Der Filter `Tag > StartDate` ist strikt: Mit dem Standard-Startdatum wird der allererste Snapshot nicht mitgezählt.\n- `Date` wird aus dem aktuellen Datum mit Uhrzeit berechnet und enthält daher die aktuelle Uhrzeit, nicht Mitternacht.\n- Die zweite Sortierung erfolgt nach der Stunde der Nutzungsdaten, die bei Stunden ohne Nutzung `NULL` ist; diese Zeilen stehen innerhalb eines Tages zuerst und in unbestimmter Reihenfolge. Bei Bedarf clientseitig nach `Hour` sortieren.\n- Die Spalten pro Anwendung ergeben in Summe nicht zwingend `CULs`: Sitzungen von `Repairs.exe` und von Anwendungen ohne interne Zuordnung zählen in `CULs`, haben aber keine eigene Spalte.\n- Das Kalenderraster basiert auf der Hilfstabelle `Numbers`; sie muss mindestens so viele Zeilen enthalten wie der Zeitraum Tage hat.\n- Bei langen Zeiträumen mit stündlicher Ausgabe kann das Ergebnis groß werden (24 Zeilen pro Tag).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAdminGetCULStatistics"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die maximale Anzahl gleichzeitig lizenzierter Benutzer (CULs) pro Stunde oder pro Tag seit einem Startdatum, aufgeteilt nach Pixi-Client-Anwendung.\n\nWertet die Sitzungs-Snapshots in `UsersLoggedIn` aus und liefert, wie viele lizenzrelevante Benutzer gleichzeitig angemeldet waren.\n\n**Zeitraum**\n- Ist `StartDate` leer, wird der früheste `Tag` aller Desktop-/Web-Sitzungen (`UserActiveSessionTypeId` 1 oder 2) verwendet.\n- Es wird ein Kalenderraster von heute zurück bis `StartDate` erzeugt: eine Zeile pro Tag und Stunde 0–23 bei `Hourly` = 1, bzw. eine Zeile pro Tag (Stunde 0) bei `Hourly` = 0.\n\n**Gezählte Sitzungen**\n- Sitzungstyp 1 (Desktop) oder 2 (Web) mit `Tag` nach `StartDate`.\n- Die Anwendung (`AppName`) muss in `ExeClientVersion` mit `LicenceNeeded` = 1 hinterlegt sein, und der Lizenzmanager für ihren Sitzungstyp muss aktiv sein: Einstellung `pixiLicencesManager` für Desktop-Clients, `pixiLicencesManagerWeb` für den Web-Client.\n- Rechner aus `MasterUsers` sowie der Pixi-Benutzer `master` werden ausgeschlossen.\n\n**Berechnung**\n1. Sitzungen werden pro Snapshot (`Tag`) gezählt; eine Sitzung pro `Tag`/`SessionId`/Pixi-Benutzer.\n2. Pro Stunde wird der höchste Snapshot-Wert als `CULs` übernommen.\n3. Pro Tag wird der höchste Stundenwert als `CULsPerDay` an der Stunde vermerkt, in der er zuerst erreicht wurde.\n4. Tage ohne Nutzung erhalten eine Zeile mit `CULs` = 0 und `CULsPerDay` = 0.\n5. Die Spalten pro Anwendung zählen die Sitzungen des Spitzen-Snapshots der Stunde, zugeordnet über den Programmnamen (z. B. `PPOS2.exe` → `POS`, `pixi.Presentation.Web` → `Web`).\n\n**Ausgabe**\n- `Hourly` = 1: eine Zeile pro Tag und Stunde; `CULsPerDay` ist nur in der Spitzenstunde des Tages gefüllt, sonst `NULL`.\n- `Hourly` = 0: eine Zeile pro Tag mit dem Tagesmaximum in `CULs` und `CULsPerDay`; `Hour` ist immer 0.\n- Sortierung nach `Date` aufsteigend, danach nach der Stunde der Nutzungsdaten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | Nein | Beginn des Auswertungszeitraums. Gezählt werden nur Sitzungen mit späterem `Tag`. Ist der Wert leer, wird der früheste Sitzungs-Snapshot aus `UsersLoggedIn` verwendet. |\n| `Hourly` | bit | Nein | Wählt stündliche oder tägliche Ausgabe. |\n\n- Nur lesend; alle Tabellen werden `WITH (NOLOCK)` gelesen, das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Ist weder `pixiLicencesManager` noch `pixiLicencesManagerWeb` auf `1` gesetzt, wird keine Sitzung gezählt und alle Werte sind 0.\n- Enthält `UsersLoggedIn` keine passenden Sitzungen und wird kein `StartDate` übergeben, lässt sich der Zeitraum nicht bestimmen und das Ergebnis ist leer.\n- Der Filter `Tag > StartDate` ist strikt: Mit dem Standard-Startdatum wird der allererste Snapshot nicht mitgezählt.\n- `Date` wird aus dem aktuellen Datum mit Uhrzeit berechnet und enthält daher die aktuelle Uhrzeit, nicht Mitternacht.\n- Die zweite Sortierung erfolgt nach der Stunde der Nutzungsdaten, die bei Stunden ohne Nutzung `NULL` ist; diese Zeilen stehen innerhalb eines Tages zuerst und in unbestimmter Reihenfolge. Bei Bedarf clientseitig nach `Hour` sortieren.\n- Die Spalten pro Anwendung ergeben in Summe nicht zwingend `CULs`: Sitzungen von `Repairs.exe` und von Anwendungen ohne interne Zuordnung zählen in `CULs`, haben aber keine eigene Spalte.\n- Das Kalenderraster basiert auf der Hilfstabelle `Numbers`; sie muss mindestens so viele Zeilen enthalten wie der Zeitraum Tage hat.\n- Bei langen Zeiträumen mit stündlicher Ausgabe kann das Ergebnis groß werden (24 Zeilen pro Tag).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAdminGetCULStatistics"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 2024-05-13T14:37:00\n 9\n 13\n 5\n 0\n 2\n 1\n 3\n 4\n 0\n 1\n 1\n 2\n 1\n 15\n 15\n \n \n 2024-05-13T14:37:00\n 10\n 13\n 5\n 0\n 1\n 1\n 3\n 3\n 1\n 1\n 0\n 1\n 1\n 12\n \n"
}
]
},
{
"name": "pixiFederalStatisticReport",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert einen monatlichen Bericht für die Bundesstatistik (Intrastat) über gelieferte Lieferantenartikel, gruppiert nach Lieferantenland, Zolltarifnummer und Ursprungsland.\n\nErstellt einen Bericht über Wareneingänge von Lieferanten für die Außenhandelsstatistik (Bundesstatistik).\n\n**Zeitraum**\n- Fehlt `DateFrom`, wird der erste Tag des Vormonats verwendet.\n- Fehlt `DateTo`, wird der letzte Tag des Vormonats verwendet.\n- `DateFrom` wird auf den Tagesbeginn (00:00:00) und `DateTo` auf das Tagesende (23:59:59.997) gesetzt; maßgeblich ist also nur das Datum.\n- Liegt `DateTo` nicht nach `DateFrom` oder umfasst der Zeitraum mehr als 24 Monate, wird statt des Berichts eine Fehlerzeile geliefert.\n\n**Auswahl**\n- Lieferantenlieferungen (`SDelHeader`) mit Status `INV` (berechnet) oder `CLS` (abgeschlossen).\n- Das letzte Änderungsdatum des Lieferungskopfs (`SDelHUpdateDate`) muss im Zeitraum liegen.\n- Nur Lieferpositionen mit gelieferter Menge größer 0.\n- Optionaler Filter auf die Lieferantennummer `SupplNR`; der Wert wird getrimmt, ein leerer Wert bedeutet alle Lieferanten.\n\n**Verdichtung**\nGruppiert wird nach Jahr und Monat des Änderungsdatums, Lieferantenland (ISO2-Code, `N/A` falls dem Lieferanten kein bekanntes Land zugeordnet ist), Ursprungsland des Artikels, Zolltarifnummer, Zolltariftext (bei leerem Wert der Artikelname) und Homepage-URL des Lieferanten. Je Gruppe werden das summierte Gewicht (Artikelgewicht × gelieferte Menge, als `int`), die summierte gelieferte Menge und der summierte Betrag (gelieferte Menge × finaler Lieferantenpreis, als `money`) geliefert.\n\nSortiert wird nach Jahr, Monat und Lieferantenland.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (nur Datum, Tagesbeginn). Standard: erster Tag des Vormonats. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (nur Datum, Tagesende). Standard: letzter Tag des Vormonats. Muss nach `DateFrom` liegen; der Zeitraum darf 24 Monate nicht überschreiten. |\n| `SupplNR` | varchar(4) | Nein | Optionale Lieferantennummer zur Einschränkung des Berichts. Wird getrimmt; leer oder NULL bedeutet alle Lieferanten. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Fehler (auch aus den Parameterprüfungen) werden abgefangen und als Zeile mit `Status` = `Error` und `Message` geliefert, nicht als SOAP-Fault.\n- Der Zeitraum bezieht sich auf `SDelHUpdateDate` (letzte Änderung des Lieferungskopfs), nicht auf ein separates Wareneingangsdatum. Eine spätere Änderung an einer alten Lieferung verschiebt sie in einen späteren Zeitraum.\n- Wird nur `DateFrom` übergeben, bleibt `DateTo` auf dem Ende des Vormonats; ein `DateFrom` im laufenden Monat führt daher zum Fehler, dass `DateTo` kleiner ist.\n- Die 24-Monats-Prüfung verwendet `DATEDIFF(MONTH, ...)` und zählt damit Monatswechsel, nicht volle Monate.\n- Die Lieferantennummer ist nicht Teil der Gruppierung, `HomePageUrl` jedoch schon: Mehrere Lieferanten aus demselben Land mit unterschiedlicher Homepage-URL ergeben getrennte Zeilen.\n- Artikel ohne Gewicht (`NULL`) fließen nicht in `DeliveredWeight` ein. Das Gewicht wird nach dem Summieren auf eine Ganzzahl gekürzt.\n- Die Hilfsprozedur `util.TempTableDrop` zum Löschen der temporären Tabelle liegt nicht vor.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiFederalStatisticReport"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert einen monatlichen Bericht für die Bundesstatistik (Intrastat) über gelieferte Lieferantenartikel, gruppiert nach Lieferantenland, Zolltarifnummer und Ursprungsland.\n\nErstellt einen Bericht über Wareneingänge von Lieferanten für die Außenhandelsstatistik (Bundesstatistik).\n\n**Zeitraum**\n- Fehlt `DateFrom`, wird der erste Tag des Vormonats verwendet.\n- Fehlt `DateTo`, wird der letzte Tag des Vormonats verwendet.\n- `DateFrom` wird auf den Tagesbeginn (00:00:00) und `DateTo` auf das Tagesende (23:59:59.997) gesetzt; maßgeblich ist also nur das Datum.\n- Liegt `DateTo` nicht nach `DateFrom` oder umfasst der Zeitraum mehr als 24 Monate, wird statt des Berichts eine Fehlerzeile geliefert.\n\n**Auswahl**\n- Lieferantenlieferungen (`SDelHeader`) mit Status `INV` (berechnet) oder `CLS` (abgeschlossen).\n- Das letzte Änderungsdatum des Lieferungskopfs (`SDelHUpdateDate`) muss im Zeitraum liegen.\n- Nur Lieferpositionen mit gelieferter Menge größer 0.\n- Optionaler Filter auf die Lieferantennummer `SupplNR`; der Wert wird getrimmt, ein leerer Wert bedeutet alle Lieferanten.\n\n**Verdichtung**\nGruppiert wird nach Jahr und Monat des Änderungsdatums, Lieferantenland (ISO2-Code, `N/A` falls dem Lieferanten kein bekanntes Land zugeordnet ist), Ursprungsland des Artikels, Zolltarifnummer, Zolltariftext (bei leerem Wert der Artikelname) und Homepage-URL des Lieferanten. Je Gruppe werden das summierte Gewicht (Artikelgewicht × gelieferte Menge, als `int`), die summierte gelieferte Menge und der summierte Betrag (gelieferte Menge × finaler Lieferantenpreis, als `money`) geliefert.\n\nSortiert wird nach Jahr, Monat und Lieferantenland.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (nur Datum, Tagesbeginn). Standard: erster Tag des Vormonats. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (nur Datum, Tagesende). Standard: letzter Tag des Vormonats. Muss nach `DateFrom` liegen; der Zeitraum darf 24 Monate nicht überschreiten. |\n| `SupplNR` | varchar(4) | Nein | Optionale Lieferantennummer zur Einschränkung des Berichts. Wird getrimmt; leer oder NULL bedeutet alle Lieferanten. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Fehler (auch aus den Parameterprüfungen) werden abgefangen und als Zeile mit `Status` = `Error` und `Message` geliefert, nicht als SOAP-Fault.\n- Der Zeitraum bezieht sich auf `SDelHUpdateDate` (letzte Änderung des Lieferungskopfs), nicht auf ein separates Wareneingangsdatum. Eine spätere Änderung an einer alten Lieferung verschiebt sie in einen späteren Zeitraum.\n- Wird nur `DateFrom` übergeben, bleibt `DateTo` auf dem Ende des Vormonats; ein `DateFrom` im laufenden Monat führt daher zum Fehler, dass `DateTo` kleiner ist.\n- Die 24-Monats-Prüfung verwendet `DATEDIFF(MONTH, ...)` und zählt damit Monatswechsel, nicht volle Monate.\n- Die Lieferantennummer ist nicht Teil der Gruppierung, `HomePageUrl` jedoch schon: Mehrere Lieferanten aus demselben Land mit unterschiedlicher Homepage-URL ergeben getrennte Zeilen.\n- Artikel ohne Gewicht (`NULL`) fließen nicht in `DeliveredWeight` ein. Das Gewicht wird nach dem Summieren auf eine Ganzzahl gekürzt.\n- Die Hilfsprozedur `util.TempTableDrop` zum Löschen der temporären Tabelle liegt nicht vor.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiFederalStatisticReport"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 2024\n 5\n CN\n CN\n 85176200\n Bluetooth headset\n 48\n 240\n 3120.0000\n www.example-supplier.cn\n \n \n 2024\n 5\n DE\n DE\n 49019900\n Printed books\n 150\n 300\n 2850.0000\n www.verlag-beispiel.de\n \n"
}
]
},
{
"name": "pixiGetApplicationUsageStatistic",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert pro Tag die pixi*-Anwendungen, die zum Zeitpunkt der meisten verbundenen Benutzer geöffnet waren, oder nur die Liste der genutzten Anwendungen.\n\nWertet die in `UsersLoggedIn` gespeicherten Anmelde-Snapshots aus, um zu zeigen, welche pixi*-Clients zum Zeitpunkt der höchsten Lizenznutzung eines Tages verwendet wurden.\n\n1. Für jeden Snapshot (`Tag`) werden die angemeldeten Sitzungen gezählt. Ausgeschlossen werden Sitzungen, deren `UserName` einem `ComputerName` in `MasterUsers` entspricht, sowie Sitzungen mit `UserNameUsingPixi` = `master`.\n2. Pro Kalendertag (Datumsanteil von `Tag`) wird der Snapshot mit der höchsten Anzahl Sitzungen gewählt. Bei Gleichstand gewinnt der späteste Snapshot des Tages.\n3. Für den gewählten Snapshot jedes Tages werden die Sitzungen pro Anwendung (`AppName`) gezählt, mit denselben Ausschlüssen.\n4. Die technischen Anwendungsnamen werden über eine fest hinterlegte Liste in lesbare Namen übersetzt (z. B. `BinClient_A.exe` → `Lager`, `ShippingClient_A.exe` → `Versand`, mehrere Web-Komponenten → `Web pixi*`). Anwendungen, die **nicht** in dieser Liste stehen, fallen aus dem Ergebnis heraus.\n\nDie Ausgabe hängt von `ShowOnlyApplicationsused` ab:\n- `0` (Standard): eine Zeile pro Tag und Anwendung mit Anzahl der Sitzungen, sortiert nach `Tag_Date` und `ApplicationFormatted`.\n- `1`: nur die eindeutige Liste der Anwendungen (technischer und lesbarer Name), die in einem der täglichen Spitzen-Snapshots vorkamen, ohne definierte Sortierung.\n\nEs gibt keinen Datumsfilter; alle Snapshots in `UsersLoggedIn` werden ausgewertet.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShowOnlyApplicationsused` | bit | Nein | Steuert die Ausgabe: `0` liefert die Nutzungszahlen pro Tag und Anwendung, `1` nur die eindeutige Liste der genutzten Anwendungen. |\n\n- Alle Zugriffe auf `UsersLoggedIn` und `MasterUsers` erfolgen mit `NOLOCK`; das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Sitzungen mit `UserNameUsingPixi` = NULL werden ebenfalls ausgeschlossen, da der Vergleich mit `master` für NULL nicht wahr ist.\n- Mehrere technische Namen werden auf denselben lesbaren Namen abgebildet (z. B. `PixiPOS.exe` und `PPOS2.exe` → `POS`; vier Web-Komponenten → `Web pixi*`). Im Modus `0` können dadurch an einem Tag mehrere Zeilen mit gleichem `ApplicationFormatted` entstehen; für eine zusammengefasste Zahl sollte clientseitig nach `ApplicationFormatted` gruppiert werden.\n- Ob `AppName` ohne Berücksichtigung der Groß-/Kleinschreibung mit der Übersetzungsliste übereinstimmt, hängt von der Datenbank-Collation ab.\n- Da die gesamte Historie von `UsersLoggedIn` verarbeitet wird, kann der Aufruf bei großen Tabellen langsam sein.\n- Temporäre Tabellen werden über `util.TempTableDrop` entfernt (Definition nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetApplicationUsageStatistic"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert pro Tag die pixi*-Anwendungen, die zum Zeitpunkt der meisten verbundenen Benutzer geöffnet waren, oder nur die Liste der genutzten Anwendungen.\n\nWertet die in `UsersLoggedIn` gespeicherten Anmelde-Snapshots aus, um zu zeigen, welche pixi*-Clients zum Zeitpunkt der höchsten Lizenznutzung eines Tages verwendet wurden.\n\n1. Für jeden Snapshot (`Tag`) werden die angemeldeten Sitzungen gezählt. Ausgeschlossen werden Sitzungen, deren `UserName` einem `ComputerName` in `MasterUsers` entspricht, sowie Sitzungen mit `UserNameUsingPixi` = `master`.\n2. Pro Kalendertag (Datumsanteil von `Tag`) wird der Snapshot mit der höchsten Anzahl Sitzungen gewählt. Bei Gleichstand gewinnt der späteste Snapshot des Tages.\n3. Für den gewählten Snapshot jedes Tages werden die Sitzungen pro Anwendung (`AppName`) gezählt, mit denselben Ausschlüssen.\n4. Die technischen Anwendungsnamen werden über eine fest hinterlegte Liste in lesbare Namen übersetzt (z. B. `BinClient_A.exe` → `Lager`, `ShippingClient_A.exe` → `Versand`, mehrere Web-Komponenten → `Web pixi*`). Anwendungen, die **nicht** in dieser Liste stehen, fallen aus dem Ergebnis heraus.\n\nDie Ausgabe hängt von `ShowOnlyApplicationsused` ab:\n- `0` (Standard): eine Zeile pro Tag und Anwendung mit Anzahl der Sitzungen, sortiert nach `Tag_Date` und `ApplicationFormatted`.\n- `1`: nur die eindeutige Liste der Anwendungen (technischer und lesbarer Name), die in einem der täglichen Spitzen-Snapshots vorkamen, ohne definierte Sortierung.\n\nEs gibt keinen Datumsfilter; alle Snapshots in `UsersLoggedIn` werden ausgewertet.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ShowOnlyApplicationsused` | bit | Nein | Steuert die Ausgabe: `0` liefert die Nutzungszahlen pro Tag und Anwendung, `1` nur die eindeutige Liste der genutzten Anwendungen. |\n\n- Alle Zugriffe auf `UsersLoggedIn` und `MasterUsers` erfolgen mit `NOLOCK`; das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Sitzungen mit `UserNameUsingPixi` = NULL werden ebenfalls ausgeschlossen, da der Vergleich mit `master` für NULL nicht wahr ist.\n- Mehrere technische Namen werden auf denselben lesbaren Namen abgebildet (z. B. `PixiPOS.exe` und `PPOS2.exe` → `POS`; vier Web-Komponenten → `Web pixi*`). Im Modus `0` können dadurch an einem Tag mehrere Zeilen mit gleichem `ApplicationFormatted` entstehen; für eine zusammengefasste Zahl sollte clientseitig nach `ApplicationFormatted` gruppiert werden.\n- Ob `AppName` ohne Berücksichtigung der Groß-/Kleinschreibung mit der Übersetzungsliste übereinstimmt, hängt von der Datenbank-Collation ab.\n- Da die gesamte Historie von `UsersLoggedIn` verarbeitet wird, kann der Aufruf bei großen Tabellen langsam sein.\n- Temporäre Tabellen werden über `util.TempTableDrop` entfernt (Definition nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetApplicationUsageStatistic"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 2024-03-11T00:00:00\n BinClient_A.exe\n Lager\n 5\n \n \n 2024-03-11T00:00:00\n ShippingClient_A.exe\n Versand\n 3\n \n"
}
]
},
{
"name": "pixiGetItemSalesStats",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Verkaufsstatistiken für einen Artikel: verkaufte Mengen der letzten 30/120/365 Tage, offene und gehaltene Mengen, offene Einzelstück-Aufträge und ABC-Klasse.\n\nLiefert eine Zeile mit Verkaufskennzahlen für einen einzelnen Artikel.\n\n1. **Artikelsuche**: Der Artikel wird über `EANUPC` **oder** `ItemNrInt` ermittelt. Verwendet wird der erste Artikel (niedrigster `ItemKey`), dessen EAN `@EANUPC` oder dessen interne Artikelnummer `@ItemNrInt` entspricht.\n2. **Offene Einzelstück-Aufträge (`Open1SS`)**: Gezählt werden alle Aufträge, die mindestens eine Auftragsposition dieses Artikels mit Status `ANG` enthalten und deren Positionen (alle Positionen des Auftrags, unabhängig vom Status) zusammen genau die Menge 1 ergeben.\n3. **Verkaufszeiträume**: Berücksichtigt werden alle Auftragspositionen des Artikels mit einem Auftragsdatum innerhalb der letzten 365 Tage (bezogen auf aktuelles Datum und Uhrzeit), ausgenommen Positionen mit Status `STO` oder `NLB`.\n - `Sales30`: bestellte Menge der letzten 30 Tage\n - `Sales120`: bestellte Menge der letzten 120 Tage (inklusive 30-Tage-Zeitraum)\n - `Sales365`: bestellte Menge der letzten 365 Tage\n - `OrderQtyANG`: Menge der Positionen mit Status `ANG` innerhalb der letzten 365 Tage\n - `OrderQtyHAL`: Menge der Positionen mit Status `HAL` innerhalb der letzten 365 Tage\n4. **ABC-Klasse**: ermittelt über die Artikel-Tags `A`, `B` oder `C` (in dieser Reihenfolge geprüft); Leerstring, wenn keiner dieser Tags zugeordnet ist.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC des Artikels. Alternative zu `ItemNrInt`. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer. Alternative zu `EANUPC`. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, die Zahlen können daher nicht festgeschriebene Daten enthalten.\n- Werden beide Parameter übergeben, werden sie mit `OR` verknüpft; verwendet wird der Artikel mit dem niedrigsten `ItemKey`, der einem der Werte entspricht. Zur Vermeidung von Mehrdeutigkeiten nur einen Identifikator übergeben.\n- Wird kein Artikel gefunden, erfolgt keine Fehlermeldung: `Open1SS` ist `0`, `ABC` und alle Verkaufsspalten sind `NULL`.\n- Die Verkaufsspalten sind `NULL` (nicht `0`), wenn im jeweiligen Zeitraum keine passenden Auftragspositionen existieren.\n- Die Zeiträume werden ab aktuellem Datum **und Uhrzeit** berechnet (`GETDATE()` minus n Tage), nicht ab Mitternacht.\n- Für `Open1SS` wird die Menge aller Positionen eines Auftrags summiert, auch von Positionen mit anderem Status (z. B. stornierte Positionen).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemSalesStats"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Verkaufsstatistiken für einen Artikel: verkaufte Mengen der letzten 30/120/365 Tage, offene und gehaltene Mengen, offene Einzelstück-Aufträge und ABC-Klasse.\n\nLiefert eine Zeile mit Verkaufskennzahlen für einen einzelnen Artikel.\n\n1. **Artikelsuche**: Der Artikel wird über `EANUPC` **oder** `ItemNrInt` ermittelt. Verwendet wird der erste Artikel (niedrigster `ItemKey`), dessen EAN `@EANUPC` oder dessen interne Artikelnummer `@ItemNrInt` entspricht.\n2. **Offene Einzelstück-Aufträge (`Open1SS`)**: Gezählt werden alle Aufträge, die mindestens eine Auftragsposition dieses Artikels mit Status `ANG` enthalten und deren Positionen (alle Positionen des Auftrags, unabhängig vom Status) zusammen genau die Menge 1 ergeben.\n3. **Verkaufszeiträume**: Berücksichtigt werden alle Auftragspositionen des Artikels mit einem Auftragsdatum innerhalb der letzten 365 Tage (bezogen auf aktuelles Datum und Uhrzeit), ausgenommen Positionen mit Status `STO` oder `NLB`.\n - `Sales30`: bestellte Menge der letzten 30 Tage\n - `Sales120`: bestellte Menge der letzten 120 Tage (inklusive 30-Tage-Zeitraum)\n - `Sales365`: bestellte Menge der letzten 365 Tage\n - `OrderQtyANG`: Menge der Positionen mit Status `ANG` innerhalb der letzten 365 Tage\n - `OrderQtyHAL`: Menge der Positionen mit Status `HAL` innerhalb der letzten 365 Tage\n4. **ABC-Klasse**: ermittelt über die Artikel-Tags `A`, `B` oder `C` (in dieser Reihenfolge geprüft); Leerstring, wenn keiner dieser Tags zugeordnet ist.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC des Artikels. Alternative zu `ItemNrInt`. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer. Alternative zu `EANUPC`. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, die Zahlen können daher nicht festgeschriebene Daten enthalten.\n- Werden beide Parameter übergeben, werden sie mit `OR` verknüpft; verwendet wird der Artikel mit dem niedrigsten `ItemKey`, der einem der Werte entspricht. Zur Vermeidung von Mehrdeutigkeiten nur einen Identifikator übergeben.\n- Wird kein Artikel gefunden, erfolgt keine Fehlermeldung: `Open1SS` ist `0`, `ABC` und alle Verkaufsspalten sind `NULL`.\n- Die Verkaufsspalten sind `NULL` (nicht `0`), wenn im jeweiligen Zeitraum keine passenden Auftragspositionen existieren.\n- Die Zeiträume werden ab aktuellem Datum **und Uhrzeit** berechnet (`GETDATE()` minus n Tage), nicht ab Mitternacht.\n- Für `Open1SS` wird die Menge aller Positionen eines Auftrags summiert, auch von Positionen mit anderem Status (z. B. stornierte Positionen).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemSalesStats"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 3\n A\n 42\n 160\n 512\n 7\n 2\n \n"
}
]
}
]
},
{
"name": "Stock",
"item": [
{
"name": "pixiAssignBoxesForPicklist",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 45872\n 100110021003]]>\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ordnet einer Pickliste eine Menge von Boxen zu und ersetzt die bisherige Zuordnung, nachdem Existenz und ausreichende Anzahl der Boxen geprüft wurden.\n\nErsetzt die Boxenzuordnung einer Pickliste durch die als XML übergebene Liste von Boxnummern.\n\n**Ablauf:**\n\n1. Liest den Lagerort (`PLHlocID`) der Pickliste `@PicklistNr` aus `PLHeader`. Ist `@PicklistNr` NULL, <= 0 oder existiert die Pickliste nicht, wird eine Fehlerzeile geliefert.\n2. Prüft, dass `@BoxNumbers` nicht NULL oder leer ist.\n3. Wertet `@BoxNumbers` als XML aus und liest alle eindeutigen Werte `/BoxNumbers/BoxNr` als Ganzzahlen. Wird kein Wert ungleich `0` gefunden, wird eine Fehlerzeile geliefert.\n4. Sucht jede Boxnummer in `boxes` **am Lagerort der Pickliste** (`LocationID` = Lagerort der Pickliste). Fehlt eine Box dort, wird eine Fehlerzeile mit den fehlenden Nummern geliefert und nichts geändert.\n5. Ermittelt die Anzahl unterschiedlicher Aufträge auf der Pickliste (einschließlich daraus abgeteilter Picklisten über `PLHOriginalKey`). Sind weniger Boxen übergeben als Aufträge vorhanden, wird eine Fehlerzeile geliefert.\n6. In einer Transaktion:\n - werden bestehende `PicklistBox`-Zuordnungen der Pickliste gelöscht, deren Box nicht in der neuen Liste enthalten ist,\n - werden Zuordnungen für noch nicht zugeordnete Boxen der Liste angelegt (angelegt/geändert durch den über `@UserName` ermittelten Benutzer),\n - werden `PLHfromBox` und `PLHtoBox` der Pickliste auf `0` gesetzt.\n7. Liefert eine Zeile mit `Status` = 1 und `Message` = `Success`.\n\nDas Ergebnis ist immer eine einzelne `Status`/`Message`-Zeile; `Status` = 0 bedeutet, dass die Prüfung fehlgeschlagen ist und keine Daten geändert wurden.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PicklistNr` | int | Ja | Schlüssel der Pickliste (`PLHkey`), der die Boxen zugeordnet werden. Muss > 0 sein und auf eine existierende Pickliste verweisen. |\n| `BoxNumbers` | nvarchar(max) | Ja | XML-Dokument mit den zuzuordnenden Boxnummern (`BoxNr` in `boxes`). Wurzelelement `BoxNumbers` mit einem `BoxNr`-Element pro Box. Doppelte Werte werden ignoriert. Alle Boxen müssen am Lagerort der Pickliste existieren, und ihre Anzahl muss mindestens der Anzahl der Aufträge auf der Pickliste entsprechen. |\n| `UserName` | varchar(50) | Nein | Pixi-Benutzername, der als Ersteller/Bearbeiter neuer Boxenzuordnungen gespeichert wird. Existiert der Benutzer nicht, wird `pixiAdministration` verwendet. |\n\n- Der Aufruf ersetzt die Zuordnung vollständig: Boxen, die der Pickliste aktuell zugeordnet sind, aber in `@BoxNumbers` fehlen, werden entfernt.\n- `@BoxNumbers` wird vor der Transaktion und außerhalb der Fehlerbehandlung in XML umgewandelt. Fehlerhaftes XML oder nicht ganzzahlige `BoxNr`-Werte führen zu einem SQL-Konvertierungsfehler, der als `SqlMessage` zurückkommt.\n- Eine `BoxNr` mit Wert `0` wird nicht ignoriert, wenn weitere Nummern vorhanden sind; sie wird wie jede andere Nummer gesucht und löst in der Regel den Fehler \"do not exist\" aus.\n- Die Liste fehlender Boxen in der Fehlermeldung ist auf 100 Zeichen begrenzt (`@ErrorDetails` ist `varchar(100)`) und kann abgeschnitten werden.\n- In der Meldung \"not enough boxes\" wird die benötigte Anzahl in ein `VARCHAR` ohne Längenangabe (Länge 1) umgewandelt, daher erscheint nur die erste Ziffer der Auftragsanzahl (z. B. `needed 1` bei 12 Aufträgen).\n- Wird `@UserName` nicht in `UCS_USERS` gefunden, wird der Benutzer `pixiAdministration` verwendet.\n- Läuft der Aufruf innerhalb einer bestehenden Transaktion, wird ein Savepoint gesetzt und kein Commit ausgeführt.\n- Bei einem Laufzeitfehler innerhalb der Transaktion werden die Änderungen zurückgerollt und der Fehler über `log.InsertError` protokolliert; in diesem Fall wird keine `Status`-Zeile geliefert.\n- Lesezugriffe auf `PLHeader`, `PicklistBox` und `boxes` erfolgen mit `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAssignBoxesForPicklist"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 45872\n 100110021003]]>\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ordnet einer Pickliste eine Menge von Boxen zu und ersetzt die bisherige Zuordnung, nachdem Existenz und ausreichende Anzahl der Boxen geprüft wurden.\n\nErsetzt die Boxenzuordnung einer Pickliste durch die als XML übergebene Liste von Boxnummern.\n\n**Ablauf:**\n\n1. Liest den Lagerort (`PLHlocID`) der Pickliste `@PicklistNr` aus `PLHeader`. Ist `@PicklistNr` NULL, <= 0 oder existiert die Pickliste nicht, wird eine Fehlerzeile geliefert.\n2. Prüft, dass `@BoxNumbers` nicht NULL oder leer ist.\n3. Wertet `@BoxNumbers` als XML aus und liest alle eindeutigen Werte `/BoxNumbers/BoxNr` als Ganzzahlen. Wird kein Wert ungleich `0` gefunden, wird eine Fehlerzeile geliefert.\n4. Sucht jede Boxnummer in `boxes` **am Lagerort der Pickliste** (`LocationID` = Lagerort der Pickliste). Fehlt eine Box dort, wird eine Fehlerzeile mit den fehlenden Nummern geliefert und nichts geändert.\n5. Ermittelt die Anzahl unterschiedlicher Aufträge auf der Pickliste (einschließlich daraus abgeteilter Picklisten über `PLHOriginalKey`). Sind weniger Boxen übergeben als Aufträge vorhanden, wird eine Fehlerzeile geliefert.\n6. In einer Transaktion:\n - werden bestehende `PicklistBox`-Zuordnungen der Pickliste gelöscht, deren Box nicht in der neuen Liste enthalten ist,\n - werden Zuordnungen für noch nicht zugeordnete Boxen der Liste angelegt (angelegt/geändert durch den über `@UserName` ermittelten Benutzer),\n - werden `PLHfromBox` und `PLHtoBox` der Pickliste auf `0` gesetzt.\n7. Liefert eine Zeile mit `Status` = 1 und `Message` = `Success`.\n\nDas Ergebnis ist immer eine einzelne `Status`/`Message`-Zeile; `Status` = 0 bedeutet, dass die Prüfung fehlgeschlagen ist und keine Daten geändert wurden.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PicklistNr` | int | Ja | Schlüssel der Pickliste (`PLHkey`), der die Boxen zugeordnet werden. Muss > 0 sein und auf eine existierende Pickliste verweisen. |\n| `BoxNumbers` | nvarchar(max) | Ja | XML-Dokument mit den zuzuordnenden Boxnummern (`BoxNr` in `boxes`). Wurzelelement `BoxNumbers` mit einem `BoxNr`-Element pro Box. Doppelte Werte werden ignoriert. Alle Boxen müssen am Lagerort der Pickliste existieren, und ihre Anzahl muss mindestens der Anzahl der Aufträge auf der Pickliste entsprechen. |\n| `UserName` | varchar(50) | Nein | Pixi-Benutzername, der als Ersteller/Bearbeiter neuer Boxenzuordnungen gespeichert wird. Existiert der Benutzer nicht, wird `pixiAdministration` verwendet. |\n\n- Der Aufruf ersetzt die Zuordnung vollständig: Boxen, die der Pickliste aktuell zugeordnet sind, aber in `@BoxNumbers` fehlen, werden entfernt.\n- `@BoxNumbers` wird vor der Transaktion und außerhalb der Fehlerbehandlung in XML umgewandelt. Fehlerhaftes XML oder nicht ganzzahlige `BoxNr`-Werte führen zu einem SQL-Konvertierungsfehler, der als `SqlMessage` zurückkommt.\n- Eine `BoxNr` mit Wert `0` wird nicht ignoriert, wenn weitere Nummern vorhanden sind; sie wird wie jede andere Nummer gesucht und löst in der Regel den Fehler \"do not exist\" aus.\n- Die Liste fehlender Boxen in der Fehlermeldung ist auf 100 Zeichen begrenzt (`@ErrorDetails` ist `varchar(100)`) und kann abgeschnitten werden.\n- In der Meldung \"not enough boxes\" wird die benötigte Anzahl in ein `VARCHAR` ohne Längenangabe (Länge 1) umgewandelt, daher erscheint nur die erste Ziffer der Auftragsanzahl (z. B. `needed 1` bei 12 Aufträgen).\n- Wird `@UserName` nicht in `UCS_USERS` gefunden, wird der Benutzer `pixiAdministration` verwendet.\n- Läuft der Aufruf innerhalb einer bestehenden Transaktion, wird ein Savepoint gesetzt und kein Commit ausgeführt.\n- Bei einem Laufzeitfehler innerhalb der Transaktion werden die Änderungen zurückgerollt und der Fehler über `log.InsertError` protokolliert; in diesem Fall wird keine `Status`-Zeile geliefert.\n- Lesezugriffe auf `PLHeader`, `PicklistBox` und `boxes` erfolgen mit `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiAssignBoxesForPicklist"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n Success\n \n"
}
]
},
{
"name": "pixiBinCreate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n A-01-01001Regal A101000TR-0100190001]]>\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen oder mehrere Lagerplätze aus einer XML-Liste an, prüft jeden Eintrag und liefert pro Lagerplatz eine Statuszeile.\n\nLegt neue Lagerplätze in der Tabelle `InvBin` aus dem in `BinsXML` übergebenen XML an. Jedes Element `/Bins/Bin` beschreibt einen Lagerplatz.\n\n**Prüfungen für die gesamte Anfrage**\n- Ist `BinsXML` NULL oder leer oder enthält es kein Element `/Bins/Bin`, wird eine einzelne Statuszeile `ERROR` / `XML contains no data.` geliefert.\n- Kann der Text nicht in XML umgewandelt werden, wird `ERROR` / `Cannot parse XML` geliefert.\n\n**Prüfung je Lagerplatz** (ein Lagerplatz, der eine Prüfung nicht besteht, erhält `Status` = `ERROR` und wird nicht angelegt):\n1. Duplikate innerhalb der Anfrage: Bei Einstellung `FilterStockOperationsWithLocation` = 0 muss der Lagerplatzname in der Anfrage eindeutig sein, bei Einstellung = 1 die Kombination aus Name und Lager. Transportlagerplätze (`TransportBin` = 1) mit gleichem Namen gelten unabhängig vom Lager immer als Duplikat.\n2. `Name` darf nicht leer sein.\n3. `LocId` darf nicht leer sein.\n4. `SortNr` muss eine ganze Zahl ≥ 0 sein (Pflicht).\n5. `MaxItems` muss eine ganze Zahl ≥ 0 sein (Pflicht).\n6. Duplikate in der Datenbank: Bei Einstellung = 0 darf kein vorhandener Lagerplatz in irgendeinem Lager denselben Namen haben, bei Einstellung = 1 kein vorhandener Lagerplatz mit demselben Namen im selben Lager.\n7. Das Lager `LocId` muss in `Location` existieren.\n\n**Anlage**\nAlle fehlerfreien Lagerplätze werden in einer Transaktion in `InvBin` eingefügt (`BinLocID`, `BinName`, `BinMaxItems`, `BinSortNum`, `BinGroup`, `TransportBin`); `CreateEmp`/`UpdateEmp` erhalten den Wert von `CreateEmp` (Standard `API`), `CreateDate`/`UpdateDate` den aktuellen Zeitpunkt. Ein fehlendes `Group` wird als Leerstring, ein fehlendes `TransportBin` als 0 gespeichert.\n\n**Antwort**\nEine Zeile je `Bin`-Element, sortiert nach seiner Position im XML (`Row`). Erfolgreich angelegte Lagerplätze haben `Status` = `CREATED`, eine leere `Message` und den neuen `BinKey` (ermittelt über Name und Lager). Abgelehnte Lagerplätze haben `Status` = `ERROR`, den Grund in `Message` und `BinKey` = NULL.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BinsXML` | varchar(max) | Ja | XML-Liste der anzulegenden Lagerplätze. Wurzel `Bins`, je Lagerplatz ein Element `Bin` mit den Unterelementen `Name` (max. 50 Zeichen, Pflicht), `LocId` (Lager-ID, max. 3 Zeichen, Pflicht), `Group` (Lagerplatzgruppe, max. 20 Zeichen, optional), `SortNr` (ganze Zahl ≥ 0, Pflicht), `MaxItems` (ganze Zahl ≥ 0, Pflicht) und `TransportBin` (0/1, optional, Standard 0). |\n| `CreateEmp` | varchar(50) | Nein | Benutzername, der als Ersteller und letzter Bearbeiter der neuen Lagerplätze gespeichert wird. Ein leerer Wert wird durch `API` ersetzt. |\n\n- Das Verhalten hängt von der Einstellung `FilterStockOperationsWithLocation` ab (gelesen über `SettingGet`, Standard 0): Bei 0 sind Lagerplatznamen systemweit eindeutig, bei 1 nur je Lager.\n- Je Lagerplatz wird nur eine Fehlermeldung behalten. Ein leerer Name überschreibt eine zuvor gesetzte Duplikatmeldung; spätere Prüfungen laufen nur für Zeilen ohne bisherigen Fehler.\n- Welcher von mehreren doppelten Einträgen der Anfrage angenommen wird, ist nicht garantiert der erste im XML, da die Nummerierung innerhalb einer Duplikatgruppe nur nach dem Lagerplatznamen sortiert.\n- `SortNr` und `MaxItems` werden mit `TRY_PARSE` (Kultur der Sitzungssprache) umgewandelt. Ein fehlender Wert scheitert bereits als `Datatype error`, daher werden die Meldungen `SortNr is empty.` / `MaxItems is empty.` praktisch nie geliefert. Die Spalten `SortNr` und `MaxItems` der Antwort zeigen den umgewandelten Eingabewert und sind bei nicht numerischen Werten NULL.\n- `TransportBin` wird direkt als `bit` gelesen. Ein nicht umwandelbarer Wert (z. B. `yes`) löst außerhalb der Fehlerbehandlung einen SQL-Fehler aus, der als `SqlMessage` zurückkommt.\n- Die Existenzprüfungen gegen `InvBin` und `Location` verwenden `NOLOCK`; parallele Aufrufe mit gleichen Lagerplatznamen können daher dennoch Duplikate erzeugen.\n- Das Einfügen läuft in einer eigenen Transaktion (bzw. einem Savepoint, wenn bereits eine Transaktion offen ist). Bei einem unerwarteten Fehler wird alles zurückgerollt, der Fehler über `log.InsertError` (nicht beigefügt) protokolliert und eine einzelne Zeile `ERROR` mit dem SQL-Fehlertext geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiBinCreate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n A-01-01001Regal A101000TR-0100190001]]>\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen oder mehrere Lagerplätze aus einer XML-Liste an, prüft jeden Eintrag und liefert pro Lagerplatz eine Statuszeile.\n\nLegt neue Lagerplätze in der Tabelle `InvBin` aus dem in `BinsXML` übergebenen XML an. Jedes Element `/Bins/Bin` beschreibt einen Lagerplatz.\n\n**Prüfungen für die gesamte Anfrage**\n- Ist `BinsXML` NULL oder leer oder enthält es kein Element `/Bins/Bin`, wird eine einzelne Statuszeile `ERROR` / `XML contains no data.` geliefert.\n- Kann der Text nicht in XML umgewandelt werden, wird `ERROR` / `Cannot parse XML` geliefert.\n\n**Prüfung je Lagerplatz** (ein Lagerplatz, der eine Prüfung nicht besteht, erhält `Status` = `ERROR` und wird nicht angelegt):\n1. Duplikate innerhalb der Anfrage: Bei Einstellung `FilterStockOperationsWithLocation` = 0 muss der Lagerplatzname in der Anfrage eindeutig sein, bei Einstellung = 1 die Kombination aus Name und Lager. Transportlagerplätze (`TransportBin` = 1) mit gleichem Namen gelten unabhängig vom Lager immer als Duplikat.\n2. `Name` darf nicht leer sein.\n3. `LocId` darf nicht leer sein.\n4. `SortNr` muss eine ganze Zahl ≥ 0 sein (Pflicht).\n5. `MaxItems` muss eine ganze Zahl ≥ 0 sein (Pflicht).\n6. Duplikate in der Datenbank: Bei Einstellung = 0 darf kein vorhandener Lagerplatz in irgendeinem Lager denselben Namen haben, bei Einstellung = 1 kein vorhandener Lagerplatz mit demselben Namen im selben Lager.\n7. Das Lager `LocId` muss in `Location` existieren.\n\n**Anlage**\nAlle fehlerfreien Lagerplätze werden in einer Transaktion in `InvBin` eingefügt (`BinLocID`, `BinName`, `BinMaxItems`, `BinSortNum`, `BinGroup`, `TransportBin`); `CreateEmp`/`UpdateEmp` erhalten den Wert von `CreateEmp` (Standard `API`), `CreateDate`/`UpdateDate` den aktuellen Zeitpunkt. Ein fehlendes `Group` wird als Leerstring, ein fehlendes `TransportBin` als 0 gespeichert.\n\n**Antwort**\nEine Zeile je `Bin`-Element, sortiert nach seiner Position im XML (`Row`). Erfolgreich angelegte Lagerplätze haben `Status` = `CREATED`, eine leere `Message` und den neuen `BinKey` (ermittelt über Name und Lager). Abgelehnte Lagerplätze haben `Status` = `ERROR`, den Grund in `Message` und `BinKey` = NULL.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BinsXML` | varchar(max) | Ja | XML-Liste der anzulegenden Lagerplätze. Wurzel `Bins`, je Lagerplatz ein Element `Bin` mit den Unterelementen `Name` (max. 50 Zeichen, Pflicht), `LocId` (Lager-ID, max. 3 Zeichen, Pflicht), `Group` (Lagerplatzgruppe, max. 20 Zeichen, optional), `SortNr` (ganze Zahl ≥ 0, Pflicht), `MaxItems` (ganze Zahl ≥ 0, Pflicht) und `TransportBin` (0/1, optional, Standard 0). |\n| `CreateEmp` | varchar(50) | Nein | Benutzername, der als Ersteller und letzter Bearbeiter der neuen Lagerplätze gespeichert wird. Ein leerer Wert wird durch `API` ersetzt. |\n\n- Das Verhalten hängt von der Einstellung `FilterStockOperationsWithLocation` ab (gelesen über `SettingGet`, Standard 0): Bei 0 sind Lagerplatznamen systemweit eindeutig, bei 1 nur je Lager.\n- Je Lagerplatz wird nur eine Fehlermeldung behalten. Ein leerer Name überschreibt eine zuvor gesetzte Duplikatmeldung; spätere Prüfungen laufen nur für Zeilen ohne bisherigen Fehler.\n- Welcher von mehreren doppelten Einträgen der Anfrage angenommen wird, ist nicht garantiert der erste im XML, da die Nummerierung innerhalb einer Duplikatgruppe nur nach dem Lagerplatznamen sortiert.\n- `SortNr` und `MaxItems` werden mit `TRY_PARSE` (Kultur der Sitzungssprache) umgewandelt. Ein fehlender Wert scheitert bereits als `Datatype error`, daher werden die Meldungen `SortNr is empty.` / `MaxItems is empty.` praktisch nie geliefert. Die Spalten `SortNr` und `MaxItems` der Antwort zeigen den umgewandelten Eingabewert und sind bei nicht numerischen Werten NULL.\n- `TransportBin` wird direkt als `bit` gelesen. Ein nicht umwandelbarer Wert (z. B. `yes`) löst außerhalb der Fehlerbehandlung einen SQL-Fehler aus, der als `SqlMessage` zurückkommt.\n- Die Existenzprüfungen gegen `InvBin` und `Location` verwenden `NOLOCK`; parallele Aufrufe mit gleichen Lagerplatznamen können daher dennoch Duplikate erzeugen.\n- Das Einfügen läuft in einer eigenen Transaktion (bzw. einem Savepoint, wenn bereits eine Transaktion offen ist). Bei einem unerwarteten Fehler wird alles zurückgerollt, der Fehler über `log.InsertError` (nicht beigefügt) protokolliert und eine einzelne Zeile `ERROR` mit dem SQL-Fehlertext geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiBinCreate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 4711\n A-01-01\n 001\n Regal A\n 10\n 100\n CREATED\n \n false\n \n \n 2\n A-01-02\n 099\n Regal A\n 20\n 100\n ERROR\n Bin not created (Location does not exist).\n false\n \n"
}
]
},
{
"name": "pixiBinUpdate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 1234A-01-02001Regal A10500123520]]>\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert einen oder mehrere bestehende Lagerplätze aus einer XML-Liste und liefert je Lagerplatz eine Statuszeile.\n\nAktualisiert bestehende Lagerplätze in `InvBin`. Lagerplätze werden über `BinKey` identifiziert; neue Lagerplätze werden nicht angelegt.\n\n1. Ist `BinsXML` leer oder nicht als XML lesbar, wird eine einzelne `ERROR`-Zeile geliefert und nichts geändert.\n2. Jedes Element `/Bins/Bin` wird gelesen: `BinKey`, `Name`, `LocId`, `Group`, `SortNr`, `MaxItems`, `TransportBin`.\n3. Jeder Lagerplatz wird geprüft. Ein Lagerplatz, der eine Prüfung nicht besteht, erhält `Status` = `ERROR` und eine Meldung und wird übersprungen. Die erste fehlgeschlagene Prüfung gilt. Die Prüfungen sind:\n - `BinKey` fehlt oder ist `0`.\n - `SortNr` oder `MaxItems` ist keine ganze Zahl oder ist negativ.\n - `LocId` weicht vom aktuellen Lager ab und der Lagerplatz hat noch Bestand (`InvBinItem`).\n - Der resultierende Name existiert bereits bei einem anderen Lagerplatz:\n - im selben Lager, immer geprüft;\n - in einem anderen Lager, nur geprüft, wenn die Einstellung `FilterStockOperationsWithLocation` den Wert `0` hat;\n - bei übergebenem `TransportBin` = 1 unter allen Transportlagerplätzen.\n - Die angegebene `LocId` existiert nicht in `Location`.\n - Es gibt keinen Lagerplatz mit diesem `BinKey`.\n4. Alle gültigen Lagerplätze werden in einer Transaktion aktualisiert. Nicht übergebene Elemente behalten ihren aktuellen Wert. Die Aktualisierung setzt `BinName`, `BinLocID`, `BinGroup`, `BinSortNum`, `BinMaxItems` und `TransportBin` sowie `UpdateEmp` und `UpdateDate`.\n5. Pro `Bin`-Element wird eine Zeile geliefert, sortiert nach der Position im XML (`Row`). Jede Zeile hat `Status` = `UPDATED` oder `ERROR`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BinsXML` | varchar(max) | Ja | XML-Liste der zu aktualisierenden Lagerplätze, Wurzel `Bins` mit einem `Bin`-Element je Lagerplatz. `BinKey` ist Pflicht. `Name`, `LocId`, `Group`, `SortNr`, `MaxItems` und `TransportBin` sind optional; nicht übergebene Werte bleiben erhalten. |\n| `UpdateEmp` | varchar(50) | Nein | Benutzername, der in `InvBin.UpdateEmp` geschrieben wird. Ein leerer Wert wird durch `API` ersetzt. |\n\n- **Beibehaltene Werte:** Die meisten Elemente werden über `text()` gelesen. Ein leeres Element (z. B. ``) gilt daher als nicht übergeben, und der aktuelle Wert bleibt erhalten. `Group` wird ohne `text()` gelesen: Ein leeres `` setzt die Gruppe auf einen Leerstring.\n- **Gelieferte Werte:** Die Ergebniszeilen enthalten die Werte wie im XML übergeben, nicht die zusammengeführten, in `InvBin` gespeicherten Werte. Nicht übergebene Felder werden als `NULL` geliefert.\n- **Transportlagerplätze:** Die Duplikatprüfung für Transportlagerplätze schließt den Lagerplatz selbst nicht aus. Wird `TransportBin` = 1 für einen Lagerplatz übergeben, der bereits Transportlagerplatz ist, wird daher `Bin Name not updated (Duplicated).` gemeldet.\n- **Duplikate innerhalb eines Aufrufs:** Namen werden nur gegen bestehende Zeilen in `InvBin` geprüft, nicht gegen andere `Bin`-Elemente desselben Aufrufs.\n- **Wirkungslose Prüfung:** Die Prüfung `Bin not updated. Name is empty.` greift nur bei Zeilen ohne `BinKey`. Solche Zeilen scheitern bereits an der `BinKey`-Prüfung, die Meldung tritt daher praktisch nicht auf.\n- **Konvertierungsfehler:** Ein nicht ganzzahliger `BinKey` oder ein ungültiger `TransportBin`-Wert (alles außer `0`, `1`, `true`, `false`) schlägt beim Lesen des XML fehl. Das geschieht vor dem `TRY`-Block und kommt als `SqlMessage` zurück. `SortNr` und `MaxItems` werden mit `TRY_PARSE` gelesen und erzeugen stattdessen Statuszeilen.\n- **Lesehinweise:** Die Prüfungen lesen `InvBin`, `InvBinItem` und `Location` mit `NOLOCK`.\n- **Transaktion:** Die Aktualisierung erfolgt mit `ROWLOCK` in einer eigenen Transaktion bzw. einem Savepoint, wenn bereits eine Transaktion offen ist.\n- **Unerwartete Fehler:** Der Fehler wird über `log.InsertError` protokolliert (nicht beigefügt), die Transaktion zurückgerollt und eine Zeile `Status` = `ERROR` geliefert. Deren `Message` enthält `@@ERROR` nach dem Protokollaufruf, also eine Zahl (meist `0`) und nicht den Fehlertext.\n- **UpdateEmp:** Ein leerer Wert für `UpdateEmp` wird durch `API` ersetzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiBinUpdate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 1234A-01-02001Regal A10500123520]]>\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert einen oder mehrere bestehende Lagerplätze aus einer XML-Liste und liefert je Lagerplatz eine Statuszeile.\n\nAktualisiert bestehende Lagerplätze in `InvBin`. Lagerplätze werden über `BinKey` identifiziert; neue Lagerplätze werden nicht angelegt.\n\n1. Ist `BinsXML` leer oder nicht als XML lesbar, wird eine einzelne `ERROR`-Zeile geliefert und nichts geändert.\n2. Jedes Element `/Bins/Bin` wird gelesen: `BinKey`, `Name`, `LocId`, `Group`, `SortNr`, `MaxItems`, `TransportBin`.\n3. Jeder Lagerplatz wird geprüft. Ein Lagerplatz, der eine Prüfung nicht besteht, erhält `Status` = `ERROR` und eine Meldung und wird übersprungen. Die erste fehlgeschlagene Prüfung gilt. Die Prüfungen sind:\n - `BinKey` fehlt oder ist `0`.\n - `SortNr` oder `MaxItems` ist keine ganze Zahl oder ist negativ.\n - `LocId` weicht vom aktuellen Lager ab und der Lagerplatz hat noch Bestand (`InvBinItem`).\n - Der resultierende Name existiert bereits bei einem anderen Lagerplatz:\n - im selben Lager, immer geprüft;\n - in einem anderen Lager, nur geprüft, wenn die Einstellung `FilterStockOperationsWithLocation` den Wert `0` hat;\n - bei übergebenem `TransportBin` = 1 unter allen Transportlagerplätzen.\n - Die angegebene `LocId` existiert nicht in `Location`.\n - Es gibt keinen Lagerplatz mit diesem `BinKey`.\n4. Alle gültigen Lagerplätze werden in einer Transaktion aktualisiert. Nicht übergebene Elemente behalten ihren aktuellen Wert. Die Aktualisierung setzt `BinName`, `BinLocID`, `BinGroup`, `BinSortNum`, `BinMaxItems` und `TransportBin` sowie `UpdateEmp` und `UpdateDate`.\n5. Pro `Bin`-Element wird eine Zeile geliefert, sortiert nach der Position im XML (`Row`). Jede Zeile hat `Status` = `UPDATED` oder `ERROR`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BinsXML` | varchar(max) | Ja | XML-Liste der zu aktualisierenden Lagerplätze, Wurzel `Bins` mit einem `Bin`-Element je Lagerplatz. `BinKey` ist Pflicht. `Name`, `LocId`, `Group`, `SortNr`, `MaxItems` und `TransportBin` sind optional; nicht übergebene Werte bleiben erhalten. |\n| `UpdateEmp` | varchar(50) | Nein | Benutzername, der in `InvBin.UpdateEmp` geschrieben wird. Ein leerer Wert wird durch `API` ersetzt. |\n\n- **Beibehaltene Werte:** Die meisten Elemente werden über `text()` gelesen. Ein leeres Element (z. B. ``) gilt daher als nicht übergeben, und der aktuelle Wert bleibt erhalten. `Group` wird ohne `text()` gelesen: Ein leeres `` setzt die Gruppe auf einen Leerstring.\n- **Gelieferte Werte:** Die Ergebniszeilen enthalten die Werte wie im XML übergeben, nicht die zusammengeführten, in `InvBin` gespeicherten Werte. Nicht übergebene Felder werden als `NULL` geliefert.\n- **Transportlagerplätze:** Die Duplikatprüfung für Transportlagerplätze schließt den Lagerplatz selbst nicht aus. Wird `TransportBin` = 1 für einen Lagerplatz übergeben, der bereits Transportlagerplatz ist, wird daher `Bin Name not updated (Duplicated).` gemeldet.\n- **Duplikate innerhalb eines Aufrufs:** Namen werden nur gegen bestehende Zeilen in `InvBin` geprüft, nicht gegen andere `Bin`-Elemente desselben Aufrufs.\n- **Wirkungslose Prüfung:** Die Prüfung `Bin not updated. Name is empty.` greift nur bei Zeilen ohne `BinKey`. Solche Zeilen scheitern bereits an der `BinKey`-Prüfung, die Meldung tritt daher praktisch nicht auf.\n- **Konvertierungsfehler:** Ein nicht ganzzahliger `BinKey` oder ein ungültiger `TransportBin`-Wert (alles außer `0`, `1`, `true`, `false`) schlägt beim Lesen des XML fehl. Das geschieht vor dem `TRY`-Block und kommt als `SqlMessage` zurück. `SortNr` und `MaxItems` werden mit `TRY_PARSE` gelesen und erzeugen stattdessen Statuszeilen.\n- **Lesehinweise:** Die Prüfungen lesen `InvBin`, `InvBinItem` und `Location` mit `NOLOCK`.\n- **Transaktion:** Die Aktualisierung erfolgt mit `ROWLOCK` in einer eigenen Transaktion bzw. einem Savepoint, wenn bereits eine Transaktion offen ist.\n- **Unerwartete Fehler:** Der Fehler wird über `log.InsertError` protokolliert (nicht beigefügt), die Transaktion zurückgerollt und eine Zeile `Status` = `ERROR` geliefert. Deren `Message` enthält `@@ERROR` nach dem Protokollaufruf, also eine Zahl (meist `0`) und nicht den Fehlertext.\n- **UpdateEmp:** Ein leerer Wert für `UpdateEmp` wird durch `API` ersetzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiBinUpdate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 1234\n A-01-02\n 001\n Regal A\n 10\n 50\n UPDATED\n \n false\n \n \n 2\n 9999\n 20\n ERROR\n Bin not updated (Bin does not exist).\n \n"
}
]
},
{
"name": "pixiDispoGetItemBinLog",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 0\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert verdichtete Lagerbewegungen aus dem Lagerplatz-Artikel-Log für eine externe Dispositionssoftware (LogControl), optional pro Artikel summiert im Inventurmodus.\n\nExportiert Lagerbewegungen aus `InvBinItemLog` für ein externes Dispositionswerkzeug (LogControl).\n\n**Auswahl**\n- Nur Log-Einträge mit `IBILKEY` > `@ItemBinLogKeyStart`, `Qty` <> 0 und `UpdateDate` zwischen `@DateStart` und `@DateEnd` (jeweils inklusive). Ist `@DateStart` NULL, wird `1900-01-01` verwendet; ist `@DateEnd` NULL, das aktuelle Datum mit Uhrzeit.\n- Die Einträge werden nach Änderungszeitpunkt, `ForOrderline`, Lager, Artikel, Grund, ändernder Mitarbeiter und Lagerbewegungsart gruppiert. Gruppen mit Mengensumme 0 entfallen.\n- Es werden die ersten `@RowCount` Gruppen (Standard 10000) nach ihrem kleinsten Log-Schlüssel übernommen. Der kleinste Log-Schlüssel einer Gruppe wird als `ItemBinLogKey` und `PItemBinLogKey` geliefert.\n\n**Bewegungsart-Code**\nPro Gruppe wird eine fest codierte Art ermittelt:\n- `0300`: Abgang (negative Summe) ohne Bezug zu einer Auftragsposition\n- `2000`: Abgang mit Bezug zu einer Auftragsposition (`ForOrderline` gesetzt und nicht 0)\n- `0200`: Zugang, gebucht von einem Mitarbeiter, dessen Name mit dem Wert der Einstellung `DispoInventoryUser` beginnt\n- `1000`: alle übrigen Bewegungen\n\nIst die Einstellung `DispoExportAllImportTypes` gleich `1`, liefert Modus 0 stattdessen den `Type` des verknüpften `StockMovementTypes`-Datensatzes.\n\n**Lieferantenbestelldaten**\nEnthält der Grund `Picco Del.Nr. ` gefolgt von einer numerischen Lieferscheinnummer und hat die Bewegung keine Auftragsposition, wird über die Lieferantenlieferung (`SDelHeader`/`SDelDetail`) und den Buying-Match die zugehörige Lieferantenbestellposition ermittelt. Bestelldatum, interne Lieferantenbestellnummer und voraussichtliches Lieferdatum werden ausgegeben; ohne Treffer enthalten diese Spalten `'0'`.\n\n**Ausgabemodi**\n- `@InventoryMode` = 0: eine Zeile pro Gruppe, sortiert nach `ItemBinLogKey`, mit absoluter Menge und Lager.\n- `@InventoryMode` = 1: Bewegungen ohne Auftragsposition werden pro Artikel summiert (Art `0300` bei negativer Summe, sonst `0200`); Bewegungen mit Auftragsposition werden einzeln geliefert (Art `2000` für Abgang, `1000` für Zugang). Beide Teile werden per `UNION` zusammengeführt und nach `Type` sortiert. Dieser Modus liefert weder `EstimatedDeliveryDate` noch `LocationID`.\n\nFür einen inkrementellen Export wird der höchste `ItemBinLogKey` des vorherigen Aufrufs als `@ItemBinLogKeyStart` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemBinLogKeyStart` | int | Ja | Nur Log-Einträge mit einem Schlüssel größer als dieser Wert werden exportiert. 0 für einen Vollexport oder den zuletzt exportierten `ItemBinLogKey` für einen inkrementellen Export. |\n| `DateStart` | datetime | Nein | Frühester Änderungszeitpunkt (inklusive). NULL bedeutet 1900-01-01. |\n| `DateEnd` | datetime | Nein | Spätester Änderungszeitpunkt (inklusive). NULL bedeutet aktuelles Datum mit Uhrzeit. |\n| `InventoryMode` | bit | Nein | Wählt das Ausgabeformat: einzelne Bewegungen oder pro Artikel summierte Bewegungen. |\n| `RowCount` | int | Nein | Maximale Anzahl gruppierter Bewegungen, die aus dem Log übernommen werden. NULL bedeutet 10000. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; nicht festgeschriebene Daten können enthalten sein.\n- `SET NOCOUNT` ist bewusst nicht gesetzt; die internen `SELECT ... INTO`-Anweisungen erzeugen Zeilenanzahl-Meldungen.\n- `fpixi_GetSetting` liefert `'0'`, wenn eine Einstellung nicht existiert. Fehlt `DispoInventoryUser`, ist das Präfix des Inventurbenutzers `'0'` statt NULL; Zugänge von Mitarbeitern, deren Name mit `0` beginnt, erhalten dann Art `0200`.\n- `@DateEnd` wird mit dem vollständigen Zeitstempel verglichen: ein Datum wie `20110820` bedeutet Mitternacht, spätere Bewegungen dieses Tages fehlen.\n- `UpdateDate` wird als Text im Format `dd.mm.yyyy` geliefert. Im Inventurmodus vergleicht `MAX(UpdateDate)` diese Texte alphabetisch; das Ergebnis ist daher nicht zwingend das jüngste Datum.\n- Im Inventurmodus wird über alle Lager eines Artikels summiert, `@RowCount` begrenzt die zugrunde liegenden Gruppen (nicht die Ausgabezeilen) und `UNION` entfernt identische Zeilen. Die Spaltenreihenfolge weicht von Modus 0 ab (`SupplOrderNr` vor `SupplOrderDate`), und die Artikelspalte heißt `ItemKey` statt `ITemKey`.\n- Die Lieferscheinnummer wird ab Position 14 von `Reason` gelesen; es wird vorausgesetzt, dass der Grund mit `Picco Del.Nr. ` beginnt.\n- Ein nicht verwendeter `LEFT JOIN` auf `SDelHeader` über den Teil von `UpdateEmp` nach `/` kann Zeilen vervielfachen und Summen verfälschen, wenn mehrere Lieferungen diese Nummer tragen.\n- Temporäre Tabellen werden über `util.TempTableDrop` gelöscht (Definition nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDispoGetItemBinLog"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 0\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert verdichtete Lagerbewegungen aus dem Lagerplatz-Artikel-Log für eine externe Dispositionssoftware (LogControl), optional pro Artikel summiert im Inventurmodus.\n\nExportiert Lagerbewegungen aus `InvBinItemLog` für ein externes Dispositionswerkzeug (LogControl).\n\n**Auswahl**\n- Nur Log-Einträge mit `IBILKEY` > `@ItemBinLogKeyStart`, `Qty` <> 0 und `UpdateDate` zwischen `@DateStart` und `@DateEnd` (jeweils inklusive). Ist `@DateStart` NULL, wird `1900-01-01` verwendet; ist `@DateEnd` NULL, das aktuelle Datum mit Uhrzeit.\n- Die Einträge werden nach Änderungszeitpunkt, `ForOrderline`, Lager, Artikel, Grund, ändernder Mitarbeiter und Lagerbewegungsart gruppiert. Gruppen mit Mengensumme 0 entfallen.\n- Es werden die ersten `@RowCount` Gruppen (Standard 10000) nach ihrem kleinsten Log-Schlüssel übernommen. Der kleinste Log-Schlüssel einer Gruppe wird als `ItemBinLogKey` und `PItemBinLogKey` geliefert.\n\n**Bewegungsart-Code**\nPro Gruppe wird eine fest codierte Art ermittelt:\n- `0300`: Abgang (negative Summe) ohne Bezug zu einer Auftragsposition\n- `2000`: Abgang mit Bezug zu einer Auftragsposition (`ForOrderline` gesetzt und nicht 0)\n- `0200`: Zugang, gebucht von einem Mitarbeiter, dessen Name mit dem Wert der Einstellung `DispoInventoryUser` beginnt\n- `1000`: alle übrigen Bewegungen\n\nIst die Einstellung `DispoExportAllImportTypes` gleich `1`, liefert Modus 0 stattdessen den `Type` des verknüpften `StockMovementTypes`-Datensatzes.\n\n**Lieferantenbestelldaten**\nEnthält der Grund `Picco Del.Nr. ` gefolgt von einer numerischen Lieferscheinnummer und hat die Bewegung keine Auftragsposition, wird über die Lieferantenlieferung (`SDelHeader`/`SDelDetail`) und den Buying-Match die zugehörige Lieferantenbestellposition ermittelt. Bestelldatum, interne Lieferantenbestellnummer und voraussichtliches Lieferdatum werden ausgegeben; ohne Treffer enthalten diese Spalten `'0'`.\n\n**Ausgabemodi**\n- `@InventoryMode` = 0: eine Zeile pro Gruppe, sortiert nach `ItemBinLogKey`, mit absoluter Menge und Lager.\n- `@InventoryMode` = 1: Bewegungen ohne Auftragsposition werden pro Artikel summiert (Art `0300` bei negativer Summe, sonst `0200`); Bewegungen mit Auftragsposition werden einzeln geliefert (Art `2000` für Abgang, `1000` für Zugang). Beide Teile werden per `UNION` zusammengeführt und nach `Type` sortiert. Dieser Modus liefert weder `EstimatedDeliveryDate` noch `LocationID`.\n\nFür einen inkrementellen Export wird der höchste `ItemBinLogKey` des vorherigen Aufrufs als `@ItemBinLogKeyStart` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemBinLogKeyStart` | int | Ja | Nur Log-Einträge mit einem Schlüssel größer als dieser Wert werden exportiert. 0 für einen Vollexport oder den zuletzt exportierten `ItemBinLogKey` für einen inkrementellen Export. |\n| `DateStart` | datetime | Nein | Frühester Änderungszeitpunkt (inklusive). NULL bedeutet 1900-01-01. |\n| `DateEnd` | datetime | Nein | Spätester Änderungszeitpunkt (inklusive). NULL bedeutet aktuelles Datum mit Uhrzeit. |\n| `InventoryMode` | bit | Nein | Wählt das Ausgabeformat: einzelne Bewegungen oder pro Artikel summierte Bewegungen. |\n| `RowCount` | int | Nein | Maximale Anzahl gruppierter Bewegungen, die aus dem Log übernommen werden. NULL bedeutet 10000. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; nicht festgeschriebene Daten können enthalten sein.\n- `SET NOCOUNT` ist bewusst nicht gesetzt; die internen `SELECT ... INTO`-Anweisungen erzeugen Zeilenanzahl-Meldungen.\n- `fpixi_GetSetting` liefert `'0'`, wenn eine Einstellung nicht existiert. Fehlt `DispoInventoryUser`, ist das Präfix des Inventurbenutzers `'0'` statt NULL; Zugänge von Mitarbeitern, deren Name mit `0` beginnt, erhalten dann Art `0200`.\n- `@DateEnd` wird mit dem vollständigen Zeitstempel verglichen: ein Datum wie `20110820` bedeutet Mitternacht, spätere Bewegungen dieses Tages fehlen.\n- `UpdateDate` wird als Text im Format `dd.mm.yyyy` geliefert. Im Inventurmodus vergleicht `MAX(UpdateDate)` diese Texte alphabetisch; das Ergebnis ist daher nicht zwingend das jüngste Datum.\n- Im Inventurmodus wird über alle Lager eines Artikels summiert, `@RowCount` begrenzt die zugrunde liegenden Gruppen (nicht die Ausgabezeilen) und `UNION` entfernt identische Zeilen. Die Spaltenreihenfolge weicht von Modus 0 ab (`SupplOrderNr` vor `SupplOrderDate`), und die Artikelspalte heißt `ItemKey` statt `ITemKey`.\n- Die Lieferscheinnummer wird ab Position 14 von `Reason` gelesen; es wird vorausgesetzt, dass der Grund mit `Picco Del.Nr. ` beginnt.\n- Ein nicht verwendeter `LEFT JOIN` auf `SDelHeader` über den Teil von `UpdateEmp` nach `/` kann Zeilen vervielfachen und Summen verfälschen, wenn mehrere Lieferungen diese Nummer tragen.\n- Temporäre Tabellen werden über `util.TempTableDrop` gelöscht (Definition nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDispoGetItemBinLog"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 154873\n 154873\n 4711\n 02.08.2011\n 5\n 1000\n L100\n ART-4711\n SUP-998\n 25.07.2011\n BE-2011-0815\n 01.08.2011\n 001\n \n \n 154880\n 154880\n 4711\n 03.08.2011\n 1\n 2000\n L100\n ART-4711\n SUP-998\n 0\n 0\n 0\n 001\n \n"
}
]
},
{
"name": "pixiExportItemStock",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Artikel mit positivem exportierbarem Bestand für einen Lagerort oder alle Lagerorte, mit Artikelnummern, EAN, Name, Hersteller, Preisen und Kategorie.\n\nExportiert eine Bestandsliste aller Artikel, deren berechneter Bestand größer als 0 ist.\n\n**Auswahl des Lagerorts**\n- Zuerst wird die Pixi-Einstellung `ExportStock_locations` gelesen. Ein leerer Wert bedeutet `ALL`, der Wert `0` bedeutet `001`.\n- Ist `Location` nicht leer, überschreibt der Parameter die Einstellung. Da `Location` den Standardwert `ALL` hat, greift die Einstellung nur, wenn ein leerer Wert oder `NULL` übergeben wird.\n- `ALL` umfasst alle Lagerorte. Jeder andere Wert wird als einzelne Lagerort-ID (`LocID`) behandelt.\n\n**Bestandsberechnung**\n\nDer Bestand wird je Artikel über die Funktion `fPixi_GetStockForExport` ermittelt:\n- **Normale Artikel:** Summe von `BinItemQty` über alle Lagerplätze (`InvBin`) in Lagerorten, die nicht als Sonderlager markiert sind (`SpecialStock <> 1`). Außer bei `ALL` wird auf den gewählten Lagerort eingeschränkt.\n- **Stücklistenartikel** (in `BundleItems` referenziert): `Items.Quantity` bei `ALL`, sonst `LocationQuantity` aus `ItemLocationSpecific` für den gewählten Lagerort, sofern dieser kein Sonderlager ist.\n\n**Ausgabe**\n\nGelesen werden alle Artikel aus `Items`, per Left Join ergänzt um den Kategorietext aus `TontrArten`. Zurückgegeben werden nur Zeilen mit `Stock > 0`. Es gibt keinen Filter auf den Artikelstatus und keine Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Location` | varchar(3) | Nein | Lagerort-ID, deren Bestand exportiert wird, oder `ALL` für alle Lagerorte. Bei leerem Wert oder `NULL` wird die Einstellung `ExportStock_locations` verwendet. |\n\n- Die Bestandsfunktion wird für ihr Kennzeichen für physischen Bestand mit dem festen Wert `'N'` aufgerufen. Offene Auftragsmengen (Status `ANG`, oder `HAL` innerhalb der letzten `HalOrdersActiveDays` Tage) bzw. Reservierungen zieht die Funktion nur ab, wenn dieses Kennzeichen `'0'` ist. Daher werden **keine Auftrags- oder Reservierungsmengen abgezogen**, und exportiert wird faktisch der physische Lagerplatzbestand.\n- Die Einstellungen `StockExportUsePhysicalStock` und `OldStockExport` werden gelesen, aber nicht verwendet. `ReservePrepaymentOrders`, `ShowLocationStockInItemSearch` und `HalOrdersActiveDays` werden an die Bestandsfunktion übergeben, wirken sich aus dem oben genannten Grund aber nicht auf das Ergebnis aus. `HalOrdersActiveDays = 0` wird durch 7 ersetzt.\n- Alle Tabellen werden mit `NOLOCK` gelesen, außer `InvBinItem` in der Bestandsfunktion, die ohne diesen Hinweis gelesen wird.\n- Der Bestand wird für jeden Artikel in `Items` über eine Skalarfunktion berechnet. Bei großen Artikelstämmen kann das langsam sein.\n- Bei Übergabe einer nicht existierenden Lagerort-ID ist das Ergebnis leer.\n- Die Join-Bedingung `TontrArt = ConfigType` nennt keine Tabellen. Welche Spalte zu `Items` und welche zu `TontrArten` gehört, lässt sich aus dem Code nicht bestimmen.\n- Der Kopfkommentar erwähnt XML-Eingaben, die Prozedur hat jedoch keinen XML-Parameter.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiExportItemStock"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Artikel mit positivem exportierbarem Bestand für einen Lagerort oder alle Lagerorte, mit Artikelnummern, EAN, Name, Hersteller, Preisen und Kategorie.\n\nExportiert eine Bestandsliste aller Artikel, deren berechneter Bestand größer als 0 ist.\n\n**Auswahl des Lagerorts**\n- Zuerst wird die Pixi-Einstellung `ExportStock_locations` gelesen. Ein leerer Wert bedeutet `ALL`, der Wert `0` bedeutet `001`.\n- Ist `Location` nicht leer, überschreibt der Parameter die Einstellung. Da `Location` den Standardwert `ALL` hat, greift die Einstellung nur, wenn ein leerer Wert oder `NULL` übergeben wird.\n- `ALL` umfasst alle Lagerorte. Jeder andere Wert wird als einzelne Lagerort-ID (`LocID`) behandelt.\n\n**Bestandsberechnung**\n\nDer Bestand wird je Artikel über die Funktion `fPixi_GetStockForExport` ermittelt:\n- **Normale Artikel:** Summe von `BinItemQty` über alle Lagerplätze (`InvBin`) in Lagerorten, die nicht als Sonderlager markiert sind (`SpecialStock <> 1`). Außer bei `ALL` wird auf den gewählten Lagerort eingeschränkt.\n- **Stücklistenartikel** (in `BundleItems` referenziert): `Items.Quantity` bei `ALL`, sonst `LocationQuantity` aus `ItemLocationSpecific` für den gewählten Lagerort, sofern dieser kein Sonderlager ist.\n\n**Ausgabe**\n\nGelesen werden alle Artikel aus `Items`, per Left Join ergänzt um den Kategorietext aus `TontrArten`. Zurückgegeben werden nur Zeilen mit `Stock > 0`. Es gibt keinen Filter auf den Artikelstatus und keine Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Location` | varchar(3) | Nein | Lagerort-ID, deren Bestand exportiert wird, oder `ALL` für alle Lagerorte. Bei leerem Wert oder `NULL` wird die Einstellung `ExportStock_locations` verwendet. |\n\n- Die Bestandsfunktion wird für ihr Kennzeichen für physischen Bestand mit dem festen Wert `'N'` aufgerufen. Offene Auftragsmengen (Status `ANG`, oder `HAL` innerhalb der letzten `HalOrdersActiveDays` Tage) bzw. Reservierungen zieht die Funktion nur ab, wenn dieses Kennzeichen `'0'` ist. Daher werden **keine Auftrags- oder Reservierungsmengen abgezogen**, und exportiert wird faktisch der physische Lagerplatzbestand.\n- Die Einstellungen `StockExportUsePhysicalStock` und `OldStockExport` werden gelesen, aber nicht verwendet. `ReservePrepaymentOrders`, `ShowLocationStockInItemSearch` und `HalOrdersActiveDays` werden an die Bestandsfunktion übergeben, wirken sich aus dem oben genannten Grund aber nicht auf das Ergebnis aus. `HalOrdersActiveDays = 0` wird durch 7 ersetzt.\n- Alle Tabellen werden mit `NOLOCK` gelesen, außer `InvBinItem` in der Bestandsfunktion, die ohne diesen Hinweis gelesen wird.\n- Der Bestand wird für jeden Artikel in `Items` über eine Skalarfunktion berechnet. Bei großen Artikelstämmen kann das langsam sein.\n- Bei Übergabe einer nicht existierenden Lagerort-ID ist das Ergebnis leer.\n- Die Join-Bedingung `TontrArt = ConfigType` nennt keine Tabellen. Welche Spalte zu `Items` und welche zu `TontrArten` gehört, lässt sich aus dem Code nicht bestimmen.\n- Der Kopfkommentar erwähnt XML-Eingaben, die Prozedur hat jedoch keinen XML-Parameter.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiExportItemStock"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n SUP-4711\n 4006381333931\n Kugelschreiber blau\n 100245\n 37\n Stabilo\n 2.9900\n 1.1000\n Schreibwaren\n \n \n SUP-4712\n 4006381333948\n Kugelschreiber rot\n 100246\n 12\n Stabilo\n 2.9900\n 1.1000\n Schreibwaren\n \n"
}
]
},
{
"name": "pixiGetChangedItems",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T08:00:00\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle seit einem Zeitpunkt geänderten Artikel mit verfügbarem Bestand und frühestem erwarteten Liefertermin aus offenen Lieferantenbestellungen.\n\nLiefert je Artikel aus `Items`, dessen `UpdateDate` größer oder gleich `@Since` ist, eine Zeile. Damit eignet sich der Aufruf für einen Delta-Abgleich von Beständen, z. B. mit einem Onlineshop.\n\nJe Artikel wird berechnet:\n\n- **`AvailableStock`**: Artikelbestand (`Items.Quantity`) abzüglich offener Auftragsmengen und offener Reservierungen. Negative Ergebnisse werden als `0` geliefert.\n - *Offene Aufträge* ermittelt `fPIXI_OpenOrdersCountForItem_ForStockExport`. Die Funktion summiert `OrderLines.Qty` für Positionen mit Status `ANG` oder `BES` sowie für Positionen mit Status `HAL`, deren Bestelldatum höchstens `HalOrdersActiveDays` Tage zurückliegt.\n - *Offene Reservierungen* sind die Summe von `InvBinItem.BinItemQty` über Picklistenpositionen, deren Picklistenkopf eine `ReservedOrderNr` und ein Ablaufdatum (`PLHexpiryDate`) in der Zukunft hat.\n- **`EstimatedDelivery`**: frühester `EstimatedDeliveryDate` der Lieferantenbestellpositionen des Artikels mit offener Restmenge, also bestellt minus geliefert minus nicht geliefert größer 0. Berücksichtigt werden nur Lieferantenbestellungen, deren Status `IsOrderedConfirmed = 1` hat; ein Code-Kommentar nennt diese als bestellt/bestätigt. Der Wert ist `NULL`, wenn keine solche Position existiert.\n\nDie Zeilen werden nicht sortiert, und es gibt kein Paging.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Ja | Untergrenze für `Items.UpdateDate` (inklusive). Es werden nur Artikel geliefert, die zu oder nach diesem Zeitpunkt geändert wurden. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Das HAL-Zeitfenster stammt aus der Einstellung `HalOrdersActiveDays`, gelesen über `fPIXI_GetSetting` (nicht beigefügt). Ist die Einstellung `0` oder leer, gelten 7 Tage.\n- Ein Artikel wird nur über Änderungen an `Items.UpdateDate` ausgewählt. Aus dem Code geht nicht hervor, ob neue Aufträge, Reservierungen oder Lieferantenbestellungen diese Spalte aktualisieren. Bestandsänderungen durch solche Datensätze werden daher möglicherweise nicht gemeldet.\n- Ist `@Since` `NULL`, werden keine Zeilen geliefert.\n- Die Berechnung führt je Artikel eine Skalarfunktion und zwei Unterabfragen aus. Ein möglichst aktueller Wert für `@Since` hält das Ergebnis klein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedItems"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T08:00:00\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle seit einem Zeitpunkt geänderten Artikel mit verfügbarem Bestand und frühestem erwarteten Liefertermin aus offenen Lieferantenbestellungen.\n\nLiefert je Artikel aus `Items`, dessen `UpdateDate` größer oder gleich `@Since` ist, eine Zeile. Damit eignet sich der Aufruf für einen Delta-Abgleich von Beständen, z. B. mit einem Onlineshop.\n\nJe Artikel wird berechnet:\n\n- **`AvailableStock`**: Artikelbestand (`Items.Quantity`) abzüglich offener Auftragsmengen und offener Reservierungen. Negative Ergebnisse werden als `0` geliefert.\n - *Offene Aufträge* ermittelt `fPIXI_OpenOrdersCountForItem_ForStockExport`. Die Funktion summiert `OrderLines.Qty` für Positionen mit Status `ANG` oder `BES` sowie für Positionen mit Status `HAL`, deren Bestelldatum höchstens `HalOrdersActiveDays` Tage zurückliegt.\n - *Offene Reservierungen* sind die Summe von `InvBinItem.BinItemQty` über Picklistenpositionen, deren Picklistenkopf eine `ReservedOrderNr` und ein Ablaufdatum (`PLHexpiryDate`) in der Zukunft hat.\n- **`EstimatedDelivery`**: frühester `EstimatedDeliveryDate` der Lieferantenbestellpositionen des Artikels mit offener Restmenge, also bestellt minus geliefert minus nicht geliefert größer 0. Berücksichtigt werden nur Lieferantenbestellungen, deren Status `IsOrderedConfirmed = 1` hat; ein Code-Kommentar nennt diese als bestellt/bestätigt. Der Wert ist `NULL`, wenn keine solche Position existiert.\n\nDie Zeilen werden nicht sortiert, und es gibt kein Paging.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Ja | Untergrenze für `Items.UpdateDate` (inklusive). Es werden nur Artikel geliefert, die zu oder nach diesem Zeitpunkt geändert wurden. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Das HAL-Zeitfenster stammt aus der Einstellung `HalOrdersActiveDays`, gelesen über `fPIXI_GetSetting` (nicht beigefügt). Ist die Einstellung `0` oder leer, gelten 7 Tage.\n- Ein Artikel wird nur über Änderungen an `Items.UpdateDate` ausgewählt. Aus dem Code geht nicht hervor, ob neue Aufträge, Reservierungen oder Lieferantenbestellungen diese Spalte aktualisieren. Bestandsänderungen durch solche Datensätze werden daher möglicherweise nicht gemeldet.\n- Ist `@Since` `NULL`, werden keine Zeilen geliefert.\n- Die Berechnung führt je Artikel eine Skalarfunktion und zwei Unterabfragen aus. Ein möglichst aktueller Wert für `@Since` hält das Ergebnis klein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedItems"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n A-10023\n 10023\n 4012345678901\n SUP-7781\n 14\n 2024-05-15T00:00:00\n \n \n A-10045\n 10045\n 4012345678925\n SUP-7790\n 0\n \n"
}
]
},
{
"name": "pixiGetChangedItemStock",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T00:00:00\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, deren Bestand sich in einem Zeitraum geändert hat, mit physischem und verfügbarem Bestand, offener Lieferantenbestellmenge und Meldebestand, seitenweise.\n\nErstellt eine Delta-Liste von Bestandsänderungen für einen Bestandsexport.\n\n**Zeitraum und Lager**\n- `Since` bis `DateTo` definiert den Zeitraum. `DateTo` ist standardmäßig die aktuelle Zeit; Werte bis `1990-01-01` werden ebenfalls durch die aktuelle Zeit ersetzt.\n- `LocID` schränkt auf ein Lager ein; leer bedeutet alle Lager.\n\n**Kandidaten**\n1. Nicht-Bundle-Artikel mit Einträgen in `InvBinItemLog` im Zeitraum in den gewählten Lagern. `StockChange` ist die Summe der protokollierten Mengen, `UpdateDate` das letzte Protokolldatum.\n2. Bei `IncludeOrderLineChanges` = 1 werden Artikel mit im Zeitraum geänderten Auftragspositionen in den gewählten Lagern ergänzt (sofern nicht bereits Kandidat). Sie benötigen mindestens einen `InvBinItemLog`-Eintrag; `StockChange` ist dann die Summe **aller** protokollierten Mengen in den Lagern, `UpdateDate` ist `items.LastCalculateStockDate` (Ersatz: letztes Protokolldatum, dann jetzt).\n3. Für jeden Kandidaten, der Bestandteil eines Bundles ist (`BundleItems`), wird auch der Bundle-Artikel ergänzt, mit `StockChange` = Änderung des Bestandteils ganzzahlig geteilt durch die Bestandteilmenge.\n\n**Sortierung und Paging**\nDie Kandidaten werden nach `UpdateDate` aufsteigend, dann nach dem letzten `InvBinItemLog`-Schlüssel nummeriert. Es werden Zeilen mit Nummer >= `Start` + 1 übernommen, höchstens `Rowcount`. Bundle-Artikel ohne Bundle-Kennzeichen sowie nicht mehr in `items` vorhandene Artikel werden übersprungen. Die gelieferte `RowNr` wird innerhalb der Seite ab 1 neu nummeriert.\n\n**Bestandswerte**\n- `PhysicalStock` = `items.Quantity`.\n- `MinStockQty` = Summe der nicht negativen `ItemLocationSpecific.MinStockQty` für das Lager (oder alle Lager).\n- Für Nicht-Bundles: `AvailableStock` = Summe von `ItemLocationSpecific.LocationQuantity` über alle Lager ohne Sonderbestand, abzüglich je nach Einstellung entweder offener Auftragsmengen (`ANG`-Positionen plus `HAL`-Positionen nicht älter als `HalOrdersActiveDays` Tage) oder der Anzahl Reservierungen auf nicht finalen Auftragspositionen (ohne Status `EIN`, `FUT`, `FUS`). `OpenSupplierOrderQTY` ist die offene Menge der Lieferantenbestellpositionen mit vollständig offenem Status; `EstimatedDelivery` stammt aus `Item_EstimatedDelivery.ExportEstimatedDelivery`.\n- Für Bundles: `AvailableStock` bleibt `items.Quantity`, `OpenSupplierOrderQTY` 0, `EstimatedDelivery` NULL.\n\n**Ausgeschlossene Lagerplatzgruppen**\nIst `ExcludeBinGroups` angegeben (kommagetrennt), wird die bis `DateTo` protokollierte Menge auf Lagerplätzen dieser Gruppen (Lager ohne Sonderbestand) von `AvailableStock`, `PhysicalStock` und `StockChange` abgezogen; bei Bundles über die Bestandteilmenge abgeleitet. `PhysicalStockLoc` ist dann die Lagerplatzmenge in den gewählten Lagern außerhalb dieser Gruppen. Ohne `ExcludeBinGroups` ist `PhysicalStockLoc` die Summe von `ItemLocationSpecific.LocationQuantity` in den gewählten Lagern für Nicht-Bundles (0 für Bundles).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Ja | Beginn des Änderungszeitraums (inklusive). |\n| `Rowcount` | int | Nein | Maximale Anzahl Zeilen pro Seite. |\n| `LocID` | varchar(3) | Nein | Lager-ID zur Einschränkung; leer oder NULL für alle Lager. |\n| `DateTo` | datetime | Nein | Ende des Änderungszeitraums (inklusive). NULL oder ein Datum bis 1990-01-01 bedeutet die aktuelle Zeit. |\n| `Start` | int | Nein | Anzahl zu überspringender Kandidatenzeilen (Paging-Offset). |\n| `ExcludeBinGroups` | varchar(max) | Nein | Kommagetrennte Liste von Lagerplatzgruppen, deren Mengen von den Bestandswerten abgezogen werden. |\n| `IncludeOrderLineChanges` | smallint | Nein | Bei 1 werden auch Artikel mit im Zeitraum geänderten Auftragspositionen geliefert. |\n\n- Nur lesend; alle permanenten Tabellen werden mit `NOLOCK` gelesen, Werte können daher nicht festgeschriebene Daten enthalten.\n- Wird `1900-01-01` (Wert 0) als `Since` übergeben, wird es zu NULL; der Zeitraumfilter trifft dann nichts und das Ergebnis ist leer.\n- Zur Laufzeit gelesene Einstellungen: `StockExportUsePhysicalStock` (ungleich `0`: keine Auftrags- oder Reservierungsmengen abgezogen), `ReservePrepaymentOrders` und `ExportAvailableStock_WhenReservationsAreEnabled` (Wahl zwischen offenen Auftragsmengen und Reservierungsanzahl), `HalOrdersActiveDays` (0 bedeutet 7; fehlt die Einstellung, werden `HAL`-Positionen nicht gezählt). `ExportStock_locations` wird gelesen, aber nicht verwendet.\n- Reservierungsanzahlen werden aufgrund der Verknüpfung der Zwischenergebnisse nur bei Artikeln berücksichtigt, die auch offene `ANG`/`HAL`-Auftragspositionen haben.\n- `AvailableStock` für Nicht-Bundles berücksichtigt alle Lager ohne Sonderbestand unabhängig von `LocID`; nur `PhysicalStockLoc`, `MinStockQty` und die Kandidatenauswahl beachten `LocID`.\n- Für die nächste Seite `Start` um `Rowcount` erhöhen; die gelieferte `RowNr` beginnt immer bei 1. Da nach `UpdateDate` aufsteigend sortiert wird, können neue Änderungen während des Pagings Positionen verschieben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedItemStock"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T00:00:00\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, deren Bestand sich in einem Zeitraum geändert hat, mit physischem und verfügbarem Bestand, offener Lieferantenbestellmenge und Meldebestand, seitenweise.\n\nErstellt eine Delta-Liste von Bestandsänderungen für einen Bestandsexport.\n\n**Zeitraum und Lager**\n- `Since` bis `DateTo` definiert den Zeitraum. `DateTo` ist standardmäßig die aktuelle Zeit; Werte bis `1990-01-01` werden ebenfalls durch die aktuelle Zeit ersetzt.\n- `LocID` schränkt auf ein Lager ein; leer bedeutet alle Lager.\n\n**Kandidaten**\n1. Nicht-Bundle-Artikel mit Einträgen in `InvBinItemLog` im Zeitraum in den gewählten Lagern. `StockChange` ist die Summe der protokollierten Mengen, `UpdateDate` das letzte Protokolldatum.\n2. Bei `IncludeOrderLineChanges` = 1 werden Artikel mit im Zeitraum geänderten Auftragspositionen in den gewählten Lagern ergänzt (sofern nicht bereits Kandidat). Sie benötigen mindestens einen `InvBinItemLog`-Eintrag; `StockChange` ist dann die Summe **aller** protokollierten Mengen in den Lagern, `UpdateDate` ist `items.LastCalculateStockDate` (Ersatz: letztes Protokolldatum, dann jetzt).\n3. Für jeden Kandidaten, der Bestandteil eines Bundles ist (`BundleItems`), wird auch der Bundle-Artikel ergänzt, mit `StockChange` = Änderung des Bestandteils ganzzahlig geteilt durch die Bestandteilmenge.\n\n**Sortierung und Paging**\nDie Kandidaten werden nach `UpdateDate` aufsteigend, dann nach dem letzten `InvBinItemLog`-Schlüssel nummeriert. Es werden Zeilen mit Nummer >= `Start` + 1 übernommen, höchstens `Rowcount`. Bundle-Artikel ohne Bundle-Kennzeichen sowie nicht mehr in `items` vorhandene Artikel werden übersprungen. Die gelieferte `RowNr` wird innerhalb der Seite ab 1 neu nummeriert.\n\n**Bestandswerte**\n- `PhysicalStock` = `items.Quantity`.\n- `MinStockQty` = Summe der nicht negativen `ItemLocationSpecific.MinStockQty` für das Lager (oder alle Lager).\n- Für Nicht-Bundles: `AvailableStock` = Summe von `ItemLocationSpecific.LocationQuantity` über alle Lager ohne Sonderbestand, abzüglich je nach Einstellung entweder offener Auftragsmengen (`ANG`-Positionen plus `HAL`-Positionen nicht älter als `HalOrdersActiveDays` Tage) oder der Anzahl Reservierungen auf nicht finalen Auftragspositionen (ohne Status `EIN`, `FUT`, `FUS`). `OpenSupplierOrderQTY` ist die offene Menge der Lieferantenbestellpositionen mit vollständig offenem Status; `EstimatedDelivery` stammt aus `Item_EstimatedDelivery.ExportEstimatedDelivery`.\n- Für Bundles: `AvailableStock` bleibt `items.Quantity`, `OpenSupplierOrderQTY` 0, `EstimatedDelivery` NULL.\n\n**Ausgeschlossene Lagerplatzgruppen**\nIst `ExcludeBinGroups` angegeben (kommagetrennt), wird die bis `DateTo` protokollierte Menge auf Lagerplätzen dieser Gruppen (Lager ohne Sonderbestand) von `AvailableStock`, `PhysicalStock` und `StockChange` abgezogen; bei Bundles über die Bestandteilmenge abgeleitet. `PhysicalStockLoc` ist dann die Lagerplatzmenge in den gewählten Lagern außerhalb dieser Gruppen. Ohne `ExcludeBinGroups` ist `PhysicalStockLoc` die Summe von `ItemLocationSpecific.LocationQuantity` in den gewählten Lagern für Nicht-Bundles (0 für Bundles).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Ja | Beginn des Änderungszeitraums (inklusive). |\n| `Rowcount` | int | Nein | Maximale Anzahl Zeilen pro Seite. |\n| `LocID` | varchar(3) | Nein | Lager-ID zur Einschränkung; leer oder NULL für alle Lager. |\n| `DateTo` | datetime | Nein | Ende des Änderungszeitraums (inklusive). NULL oder ein Datum bis 1990-01-01 bedeutet die aktuelle Zeit. |\n| `Start` | int | Nein | Anzahl zu überspringender Kandidatenzeilen (Paging-Offset). |\n| `ExcludeBinGroups` | varchar(max) | Nein | Kommagetrennte Liste von Lagerplatzgruppen, deren Mengen von den Bestandswerten abgezogen werden. |\n| `IncludeOrderLineChanges` | smallint | Nein | Bei 1 werden auch Artikel mit im Zeitraum geänderten Auftragspositionen geliefert. |\n\n- Nur lesend; alle permanenten Tabellen werden mit `NOLOCK` gelesen, Werte können daher nicht festgeschriebene Daten enthalten.\n- Wird `1900-01-01` (Wert 0) als `Since` übergeben, wird es zu NULL; der Zeitraumfilter trifft dann nichts und das Ergebnis ist leer.\n- Zur Laufzeit gelesene Einstellungen: `StockExportUsePhysicalStock` (ungleich `0`: keine Auftrags- oder Reservierungsmengen abgezogen), `ReservePrepaymentOrders` und `ExportAvailableStock_WhenReservationsAreEnabled` (Wahl zwischen offenen Auftragsmengen und Reservierungsanzahl), `HalOrdersActiveDays` (0 bedeutet 7; fehlt die Einstellung, werden `HAL`-Positionen nicht gezählt). `ExportStock_locations` wird gelesen, aber nicht verwendet.\n- Reservierungsanzahlen werden aufgrund der Verknüpfung der Zwischenergebnisse nur bei Artikeln berücksichtigt, die auch offene `ANG`/`HAL`-Auftragspositionen haben.\n- `AvailableStock` für Nicht-Bundles berücksichtigt alle Lager ohne Sonderbestand unabhängig von `LocID`; nur `PhysicalStockLoc`, `MinStockQty` und die Kandidatenauswahl beachten `LocID`.\n- Für die nächste Seite `Start` um `Rowcount` erhöhen; die gelieferte `RowNr` beginnt immer bei 1. Da nach `UpdateDate` aufsteigend sortiert wird, können neue Änderungen während des Pagings Positionen verschieben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedItemStock"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4711\n ART-1001\n 4006381333931\n SUP-55\n 25\n 21\n -3\n 2024-05-10T00:00:00\n 5\n true\n 50\n 2024-05-01T08:15:00\n 2024-05-01T08:20:00\n false\n 1\n 25\n \n"
}
]
},
{
"name": "pixiGetChangedItemStock2",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T00:00:00\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, deren Bestand sich in einem Zeitraum geändert hat, mit physischem, verfügbarem und lagerbezogenem Bestand, Meldebestand und offener Lieferantenbestellmenge, mit Paging.\n\nDelta-Export von Bestandsänderungen, typischerweise zum Abgleich der Shop-Bestände.\n\n**1. Lager.** Alle Lager oder nur `LocID`, falls gesetzt.\n\n**2. Geänderte Artikel.** Nicht-Bundle-Artikel mit Einträgen im Lagerplatz-Log (`InvBinItemLog`), deren `UpdateDate` zwischen `Since` und `DateTo` liegt, in den gewählten Lagern.\n- `StockChange` ist die Summe der protokollierten Mengen im Zeitraum.\n- `UpdateDate` ist das letzte Log-Datum.\n- `OriginalUpdateDate` ist `LastCalculateStockDate` des Artikels, ersatzweise das letzte Log-Datum.\n\n**3. Auftragspositions-Änderungen.** Bei `IncludeOrderLineChanges = 1` werden Artikel mit Auftragspositionen ergänzt, die im Zeitraum geändert wurden, sofern sie noch nicht enthalten sind. Die `LocationID` der Position muss zu den gewählten Lagern gehören, und der Artikel muss in diesen Lagern Log-Einträge haben.\n- Für diese Artikel ist `StockChange` die Summe **aller** Log-Einträge in diesen Lagern, nicht nur der Einträge im Zeitraum.\n- `UpdateDate` ist `LastCalculateStockDate`, ersatzweise das letzte Log-Datum, ersatzweise die aktuelle Zeit.\n\n**4. Bundles.** Zu jeder geänderten Komponente werden die Bundle-Artikel ergänzt, die sie enthalten (`BundleItem = 1`). Ihr `StockChange` ist die größte Komponentenänderung, ganzzahlig geteilt durch die Komponentenmenge im Bundle. Bundle-Kopfartikel werden nur als Bundle-Zeile geliefert.\n\n**5. Sortierung und Paging.** Die Kandidaten werden nach `UpdateDate` aufsteigend nummeriert, danach nach dem höchsten Log-Schlüssel. Geliefert werden Zeilen mit einer Nummer ab `Start + 1`, höchstens `Rowcount` Stück.\n\n**6. Bestandswerte.**\n- `PhysicalStock`: `items.Quantity`.\n- `MinStockQty`: Summe der nicht negativen `MinStockQty`-Werte aus `ItemLocationSpecific` für `LocID` bzw. für alle Lager.\n- Für Nicht-Bundles:\n - `AvailableStock` = Summe von `LocationQuantity` über alle Lager ohne Sonderbestand, abzüglich der reservierten Menge (siehe Hinweise).\n - `OpenSupplierOrderQTY` = Summe von `Qty - DeliveredQty - UndeliveredQty` über Lieferantenbestellungen, deren Status `IsAllOpen = 1` hat.\n - `EstimatedDelivery` stammt aus `Item_EstimatedDelivery.ExportEstimatedDelivery`.\n- Für Bundles bleibt `AvailableStock` = `items.Quantity`, `OpenSupplierOrderQTY` ist 0 und `EstimatedDelivery` leer.\n\n**7. Ausgeschlossene Lagerplatzgruppen.** Ist `ExcludeBinGroups` gesetzt, wird die Menge in Lagerplätzen dieser Gruppen von `PhysicalStock`, `AvailableStock` und `StockChange` abgezogen. Diese Menge ist die Summe aller Log-Einträge bis `DateTo`. Für Bundles wird sie aus den Komponenten abgeleitet. `PhysicalStockLoc` ist dann die Summe der Lagerplatzmengen in den gewählten Lagern ohne die ausgeschlossenen Gruppen.\n\nOhne `ExcludeBinGroups` ist `PhysicalStockLoc` die Summe von `LocationQuantity` in den gewählten Lagern, nur für Nicht-Bundles.\n\nDas gelieferte `RowNr` wird innerhalb der Seite ab 1 neu nummeriert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Ja | Beginn des Änderungszeitraums. Lagerplatz-Log-Einträge und, falls aktiviert, Auftragspositions-Änderungen ab diesem Zeitpunkt werden berücksichtigt. |\n| `Rowcount` | int | Nein | Maximale Anzahl gelieferter Zeilen (Seitengröße). |\n| `LocID` | varchar(3) | Nein | Lager-ID zur Einschränkung von Änderungen, Meldebestand und `PhysicalStockLoc`. Leer bedeutet alle Lager. |\n| `DateTo` | datetime | Nein | Ende des Änderungszeitraums. NULL, 0 oder ein Datum bis 1990-01-01 bedeutet aktuelle Zeit. |\n| `Start` | int | Nein | Anzahl zu überspringender Kandidatenzeilen (Paging-Offset). 0 beginnt mit der ersten Zeile. |\n| `ExcludeBinGroups` | varchar(max) | Nein | Kommagetrennte Liste von Lagerplatzgruppen, deren Mengen von den Bestandswerten abgezogen werden. Leer oder NULL deaktiviert den Ausschluss. |\n| `IncludeOrderLineChanges` | smallint | Nein | Bei 1 werden auch Artikel mit im Zeitraum geänderten Auftragspositionen geliefert. |\n\n- Nur lesend. Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten enthalten sein.\n\n**Zur Laufzeit gelesene Einstellungen:**\n- `StockExportUsePhysicalStock`: Nur bei `0` werden offene Auftragsmengen bzw. Reservierungen von `AvailableStock` abgezogen.\n- `ReservePrepaymentOrders` und `ExportAvailableStock_WhenReservationsAreEnabled`:\n - Sind Reservierungen aus oder beide Einstellungen `1`, wird die Summe der Auftragspositionen im Status `ANG` abgezogen, dazu `HAL`-Positionen mit Auftragsdatum innerhalb der letzten `HalOrdersActiveDays` Tage (Standard 7).\n - Sonst wird die Anzahl der Reservierungen abgezogen, deren Auftragsposition einen nicht finalen Status außer `EIN`, `FUT` und `FUS` hat. Wegen des Joins zählen Reservierungen nur, wenn der Artikel auch `ANG`/`HAL`-Positionen hat.\n- `ExportStock_locations` wird gelesen, aber nicht verwendet.\n\n**Stolperfallen:**\n- `Since` muss ein echtes Datum sein. Der Wert 0 (1900-01-01) wird zu NULL, dann passen keine Log-Einträge.\n- `DateTo`-Werte bis 1990-01-01 werden durch die aktuelle Zeit ersetzt.\n- Die Basis für `AvailableStock` umfasst alle Lager ohne Sonderbestand, auch wenn `LocID` gesetzt ist.\n- Der Ausschluss von Lagerplatzgruppen berücksichtigt Lagerplätze aller Lager.\n- Für die nächste Seite `Start` um die Anzahl gelieferter Zeilen erhöhen oder mit späterem `Since` fortfahren. Das gelieferte `RowNr` ist seitenbezogen.\n- Laut Code-Kommentar nutzen Bundles `LocationQuantity`, der Code aktualisiert `PhysicalStockLoc` aber nur für Nicht-Bundles; für Bundles bleibt der Wert 0.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedItemStock2"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T00:00:00\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, deren Bestand sich in einem Zeitraum geändert hat, mit physischem, verfügbarem und lagerbezogenem Bestand, Meldebestand und offener Lieferantenbestellmenge, mit Paging.\n\nDelta-Export von Bestandsänderungen, typischerweise zum Abgleich der Shop-Bestände.\n\n**1. Lager.** Alle Lager oder nur `LocID`, falls gesetzt.\n\n**2. Geänderte Artikel.** Nicht-Bundle-Artikel mit Einträgen im Lagerplatz-Log (`InvBinItemLog`), deren `UpdateDate` zwischen `Since` und `DateTo` liegt, in den gewählten Lagern.\n- `StockChange` ist die Summe der protokollierten Mengen im Zeitraum.\n- `UpdateDate` ist das letzte Log-Datum.\n- `OriginalUpdateDate` ist `LastCalculateStockDate` des Artikels, ersatzweise das letzte Log-Datum.\n\n**3. Auftragspositions-Änderungen.** Bei `IncludeOrderLineChanges = 1` werden Artikel mit Auftragspositionen ergänzt, die im Zeitraum geändert wurden, sofern sie noch nicht enthalten sind. Die `LocationID` der Position muss zu den gewählten Lagern gehören, und der Artikel muss in diesen Lagern Log-Einträge haben.\n- Für diese Artikel ist `StockChange` die Summe **aller** Log-Einträge in diesen Lagern, nicht nur der Einträge im Zeitraum.\n- `UpdateDate` ist `LastCalculateStockDate`, ersatzweise das letzte Log-Datum, ersatzweise die aktuelle Zeit.\n\n**4. Bundles.** Zu jeder geänderten Komponente werden die Bundle-Artikel ergänzt, die sie enthalten (`BundleItem = 1`). Ihr `StockChange` ist die größte Komponentenänderung, ganzzahlig geteilt durch die Komponentenmenge im Bundle. Bundle-Kopfartikel werden nur als Bundle-Zeile geliefert.\n\n**5. Sortierung und Paging.** Die Kandidaten werden nach `UpdateDate` aufsteigend nummeriert, danach nach dem höchsten Log-Schlüssel. Geliefert werden Zeilen mit einer Nummer ab `Start + 1`, höchstens `Rowcount` Stück.\n\n**6. Bestandswerte.**\n- `PhysicalStock`: `items.Quantity`.\n- `MinStockQty`: Summe der nicht negativen `MinStockQty`-Werte aus `ItemLocationSpecific` für `LocID` bzw. für alle Lager.\n- Für Nicht-Bundles:\n - `AvailableStock` = Summe von `LocationQuantity` über alle Lager ohne Sonderbestand, abzüglich der reservierten Menge (siehe Hinweise).\n - `OpenSupplierOrderQTY` = Summe von `Qty - DeliveredQty - UndeliveredQty` über Lieferantenbestellungen, deren Status `IsAllOpen = 1` hat.\n - `EstimatedDelivery` stammt aus `Item_EstimatedDelivery.ExportEstimatedDelivery`.\n- Für Bundles bleibt `AvailableStock` = `items.Quantity`, `OpenSupplierOrderQTY` ist 0 und `EstimatedDelivery` leer.\n\n**7. Ausgeschlossene Lagerplatzgruppen.** Ist `ExcludeBinGroups` gesetzt, wird die Menge in Lagerplätzen dieser Gruppen von `PhysicalStock`, `AvailableStock` und `StockChange` abgezogen. Diese Menge ist die Summe aller Log-Einträge bis `DateTo`. Für Bundles wird sie aus den Komponenten abgeleitet. `PhysicalStockLoc` ist dann die Summe der Lagerplatzmengen in den gewählten Lagern ohne die ausgeschlossenen Gruppen.\n\nOhne `ExcludeBinGroups` ist `PhysicalStockLoc` die Summe von `LocationQuantity` in den gewählten Lagern, nur für Nicht-Bundles.\n\nDas gelieferte `RowNr` wird innerhalb der Seite ab 1 neu nummeriert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Ja | Beginn des Änderungszeitraums. Lagerplatz-Log-Einträge und, falls aktiviert, Auftragspositions-Änderungen ab diesem Zeitpunkt werden berücksichtigt. |\n| `Rowcount` | int | Nein | Maximale Anzahl gelieferter Zeilen (Seitengröße). |\n| `LocID` | varchar(3) | Nein | Lager-ID zur Einschränkung von Änderungen, Meldebestand und `PhysicalStockLoc`. Leer bedeutet alle Lager. |\n| `DateTo` | datetime | Nein | Ende des Änderungszeitraums. NULL, 0 oder ein Datum bis 1990-01-01 bedeutet aktuelle Zeit. |\n| `Start` | int | Nein | Anzahl zu überspringender Kandidatenzeilen (Paging-Offset). 0 beginnt mit der ersten Zeile. |\n| `ExcludeBinGroups` | varchar(max) | Nein | Kommagetrennte Liste von Lagerplatzgruppen, deren Mengen von den Bestandswerten abgezogen werden. Leer oder NULL deaktiviert den Ausschluss. |\n| `IncludeOrderLineChanges` | smallint | Nein | Bei 1 werden auch Artikel mit im Zeitraum geänderten Auftragspositionen geliefert. |\n\n- Nur lesend. Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten enthalten sein.\n\n**Zur Laufzeit gelesene Einstellungen:**\n- `StockExportUsePhysicalStock`: Nur bei `0` werden offene Auftragsmengen bzw. Reservierungen von `AvailableStock` abgezogen.\n- `ReservePrepaymentOrders` und `ExportAvailableStock_WhenReservationsAreEnabled`:\n - Sind Reservierungen aus oder beide Einstellungen `1`, wird die Summe der Auftragspositionen im Status `ANG` abgezogen, dazu `HAL`-Positionen mit Auftragsdatum innerhalb der letzten `HalOrdersActiveDays` Tage (Standard 7).\n - Sonst wird die Anzahl der Reservierungen abgezogen, deren Auftragsposition einen nicht finalen Status außer `EIN`, `FUT` und `FUS` hat. Wegen des Joins zählen Reservierungen nur, wenn der Artikel auch `ANG`/`HAL`-Positionen hat.\n- `ExportStock_locations` wird gelesen, aber nicht verwendet.\n\n**Stolperfallen:**\n- `Since` muss ein echtes Datum sein. Der Wert 0 (1900-01-01) wird zu NULL, dann passen keine Log-Einträge.\n- `DateTo`-Werte bis 1990-01-01 werden durch die aktuelle Zeit ersetzt.\n- Die Basis für `AvailableStock` umfasst alle Lager ohne Sonderbestand, auch wenn `LocID` gesetzt ist.\n- Der Ausschluss von Lagerplatzgruppen berücksichtigt Lagerplätze aller Lager.\n- Für die nächste Seite `Start` um die Anzahl gelieferter Zeilen erhöhen oder mit späterem `Since` fortfahren. Das gelieferte `RowNr` ist seitenbezogen.\n- Laut Code-Kommentar nutzen Bundles `LocationQuantity`, der Code aktualisiert `PhysicalStockLoc` aber nur für Nicht-Bundles; für Bundles bleibt der Wert 0.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedItemStock2"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n ART-10452\n 4012345678901\n SUP-889\n 25\n 21\n -3\n 5\n true\n 50\n 2024-05-01T09:15:22\n 2024-05-01T09:16:00\n false\n 1\n 25\n \n \n 20877\n SET-20877\n 4012345678918\n \n 0\n 4\n -1\n 0\n true\n 0\n 2024-05-01T09:15:22\n 2024-05-01T09:15:22\n true\n 2\n 0\n \n"
}
]
},
{
"name": "pixiGetChangedItemStock_LocID",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T00:00:00\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, deren Bestand sich in einem Zeitraum geändert hat, mit physischem und verfügbarem Bestand, optional je Lager und ohne bestimmte Lagerplatzgruppen.\n\nDelta-Bestandsexport je Lager. Der Aufruf sammelt geänderte Artikel, berechnet deren Bestandswerte und liefert eine Seite von Zeilen.\n\n**1. Kandidaten**\n\n- Kandidaten sind Nicht-Bundle-Artikel mit Einträgen im Bestandsbewegungsprotokoll `InvBinItemLog`.\n- Als Änderungsdatum gilt `COALESCE(items.LastCalculateStockDate, InvBinItemLog.UpdateDate, jetzt)`. Es muss zwischen `Since` und `DateTo` liegen.\n- Ist `LocID` nicht leer, zählen nur Protokolleinträge dieses Lagers.\n- `StockChange` ist die Summe der protokollierten Mengen.\n\n**2. Bundles**\n\n- Zu jeder geänderten Komponente werden die zugehörigen Bundle-Artikel mit `BundleItem = 1` ergänzt.\n- Deren `StockChange` ist die Komponentenänderung geteilt durch die Komponentenmenge im Bundle (Ganzzahldivision).\n\n**3. Paging**\n\n- Die Zeilen werden nach Änderungsdatum aufsteigend, dann nach dem höchsten Protokollschlüssel nummeriert (`RowNr`).\n- `Start` ist ein nullbasierter Offset. Zeilen ab `Start + 1` werden übernommen, höchstens `Rowcount` Zeilen werden geliefert.\n\n**4. Bereinigung**\n\n- Zeilen für nicht mehr existierende Artikel werden entfernt.\n- Zeilen für Artikel, die inzwischen Bundles sind, aber als Nicht-Bundle gesammelt wurden, werden entfernt.\n\n**5. Artikeldaten**\n\n- `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `Enabled` und `MinStockQty` stammen aus dem Artikelstamm.\n- `PhysicalStock` ist bei leerem `LocID` die Summe aller positiven `LocationQuantity`-Werte, sonst die Lagermenge von `LocID`.\n- `AvailableStock` wird zunächst auf `items.Quantity` gesetzt.\n\n**6. Nur Nicht-Bundle-Artikel**\n\n`AvailableStock` wird neu berechnet als Summe der Lagerplatzmengen (`InvBinItem`) im Lager (bzw. allen Lagern) abzüglich eines Abzugs:\n\n- Ist die Einstellung `ReservePrepaymentOrders` nicht `1`: Die Mengen der Auftragspositionen mit Status `ANG` oder `HAL` werden abgezogen.\n- Sonst: Die **Anzahl** der Reservierungsdatensätze wird abgezogen. Gezählt werden Auftragspositionen in nicht-finalen Status außer `EIN`, `FUT` und `FUS`.\n- Beide Abzüge greifen nur, wenn die Einstellung `StockExportUsePhysicalStock` den Wert `0` hat.\n\nZusätzlich werden befüllt:\n\n- `OpenSupplierOrderQTY`: offene Menge der Lieferantenbestellpositionen, deren Status `IsAllOpen = 1` hat.\n- `EstimatedDelivery`: aus `Item_EstimatedDelivery.ExportEstimatedDelivery`.\n\n**7. Ausgeschlossene Lagerplatzgruppen**\n\n- Ist `ExcludeBinGroups` gesetzt (kommagetrennte Liste), werden die protokollierten Mengen aller Lagerplätze dieser Gruppen je Artikel summiert. Es zählen nur Protokolleinträge bis `DateTo`.\n- Für Bundles wird das Ergebnis in Bundle-Einheiten umgerechnet.\n- Diese Menge wird von `AvailableStock`, `PhysicalStock` und `StockChange` abgezogen.\n\n**8. Ergebnis**\n\nDas Ergebnis ist nach `RowNr` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Ja | Beginn des Änderungszeitraums (inklusive). `0` führt zu einem leeren Ergebnis. |\n| `Rowcount` | int | Nein | Maximale Anzahl gelieferter Zeilen (Seitengröße). |\n| `LocID` | varchar(3) | Nein | Lager-ID, auf die Änderungen und Bestände beschränkt werden. Leer oder NULL bedeutet alle Lager. |\n| `DateTo` | datetime | Nein | Ende des Änderungszeitraums (inklusive). NULL, `0` oder ein Datum bis einschließlich 1990-01-01 bedeutet die aktuelle Zeit. |\n| `Start` | int | Nein | Nullbasierter Offset für das Paging. Geliefert werden Zeilen mit `RowNr` größer als `Start`. |\n| `ExcludeBinGroups` | varchar(max) | Nein | Kommagetrennte Liste von Lagerplatzgruppen, deren Mengen von den Bestandswerten abgezogen werden. Leer oder NULL deaktiviert den Ausschluss. |\n\n**Nebeneffekt**\n\n- Jeder Aufruf schreibt einen Eintrag mit `Since`, `Rowcount` und Laufzeit in `LogTable`. Der Eintrag trägt die Bezeichnung `pipiGetChangedItemStock`.\n\n**Sperren**\n\n- Alle Lesezugriffe verwenden `NOLOCK`; nicht festgeschriebene Daten sind möglich.\n\n**Fallstricke**\n\n- `Since` = `0` / `1900-01-01` wird zu NULL. Der Datumsfilter trifft dann nichts und das Ergebnis ist leer.\n- `DateTo` wird bei NULL, `0` oder Werten bis einschließlich `1990-01-01` durch die aktuelle Zeit ersetzt.\n- Das Zeitfenster basiert vorrangig auf `items.LastCalculateStockDate`, nicht auf dem Datum des einzelnen Protokolleintrags.\n- Der Filter für `HAL`-Positionen subtrahiert ein Datum von einem Datum. Mit der Einstellung `HalOrdersActiveDays` (Standard 7 bei `0`) werden dadurch praktisch alle `HAL`-Positionen berücksichtigt statt nur die der letzten N Tage.\n- Bei aktivierten Reservierungen wird die Anzahl der Reservierungszeilen abgezogen, keine Menge.\n- Artikel ohne `ItemLocationSpecific`-Zeile (bzw. ohne Zeile für `LocID`) behalten leere Artikelnummern, Bestand `0` und `Enabled` NULL.\n- `PhysicalStock` kann NULL sein, wenn bei leerem `LocID` keine positive Lagermenge existiert.\n- Der Ausschluss von Lagerplatzgruppen ist nicht auf `LocID` beschränkt.\n- Für Bundles bleiben `OpenSupplierOrderQTY` auf `0` und `EstimatedDelivery` NULL.\n- Die Einstellungen `ShowLocationStockInItemSearch` und `OldStockExport` werden gelesen, aber nicht verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedItemStock_LocID"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T00:00:00\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, deren Bestand sich in einem Zeitraum geändert hat, mit physischem und verfügbarem Bestand, optional je Lager und ohne bestimmte Lagerplatzgruppen.\n\nDelta-Bestandsexport je Lager. Der Aufruf sammelt geänderte Artikel, berechnet deren Bestandswerte und liefert eine Seite von Zeilen.\n\n**1. Kandidaten**\n\n- Kandidaten sind Nicht-Bundle-Artikel mit Einträgen im Bestandsbewegungsprotokoll `InvBinItemLog`.\n- Als Änderungsdatum gilt `COALESCE(items.LastCalculateStockDate, InvBinItemLog.UpdateDate, jetzt)`. Es muss zwischen `Since` und `DateTo` liegen.\n- Ist `LocID` nicht leer, zählen nur Protokolleinträge dieses Lagers.\n- `StockChange` ist die Summe der protokollierten Mengen.\n\n**2. Bundles**\n\n- Zu jeder geänderten Komponente werden die zugehörigen Bundle-Artikel mit `BundleItem = 1` ergänzt.\n- Deren `StockChange` ist die Komponentenänderung geteilt durch die Komponentenmenge im Bundle (Ganzzahldivision).\n\n**3. Paging**\n\n- Die Zeilen werden nach Änderungsdatum aufsteigend, dann nach dem höchsten Protokollschlüssel nummeriert (`RowNr`).\n- `Start` ist ein nullbasierter Offset. Zeilen ab `Start + 1` werden übernommen, höchstens `Rowcount` Zeilen werden geliefert.\n\n**4. Bereinigung**\n\n- Zeilen für nicht mehr existierende Artikel werden entfernt.\n- Zeilen für Artikel, die inzwischen Bundles sind, aber als Nicht-Bundle gesammelt wurden, werden entfernt.\n\n**5. Artikeldaten**\n\n- `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `Enabled` und `MinStockQty` stammen aus dem Artikelstamm.\n- `PhysicalStock` ist bei leerem `LocID` die Summe aller positiven `LocationQuantity`-Werte, sonst die Lagermenge von `LocID`.\n- `AvailableStock` wird zunächst auf `items.Quantity` gesetzt.\n\n**6. Nur Nicht-Bundle-Artikel**\n\n`AvailableStock` wird neu berechnet als Summe der Lagerplatzmengen (`InvBinItem`) im Lager (bzw. allen Lagern) abzüglich eines Abzugs:\n\n- Ist die Einstellung `ReservePrepaymentOrders` nicht `1`: Die Mengen der Auftragspositionen mit Status `ANG` oder `HAL` werden abgezogen.\n- Sonst: Die **Anzahl** der Reservierungsdatensätze wird abgezogen. Gezählt werden Auftragspositionen in nicht-finalen Status außer `EIN`, `FUT` und `FUS`.\n- Beide Abzüge greifen nur, wenn die Einstellung `StockExportUsePhysicalStock` den Wert `0` hat.\n\nZusätzlich werden befüllt:\n\n- `OpenSupplierOrderQTY`: offene Menge der Lieferantenbestellpositionen, deren Status `IsAllOpen = 1` hat.\n- `EstimatedDelivery`: aus `Item_EstimatedDelivery.ExportEstimatedDelivery`.\n\n**7. Ausgeschlossene Lagerplatzgruppen**\n\n- Ist `ExcludeBinGroups` gesetzt (kommagetrennte Liste), werden die protokollierten Mengen aller Lagerplätze dieser Gruppen je Artikel summiert. Es zählen nur Protokolleinträge bis `DateTo`.\n- Für Bundles wird das Ergebnis in Bundle-Einheiten umgerechnet.\n- Diese Menge wird von `AvailableStock`, `PhysicalStock` und `StockChange` abgezogen.\n\n**8. Ergebnis**\n\nDas Ergebnis ist nach `RowNr` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Ja | Beginn des Änderungszeitraums (inklusive). `0` führt zu einem leeren Ergebnis. |\n| `Rowcount` | int | Nein | Maximale Anzahl gelieferter Zeilen (Seitengröße). |\n| `LocID` | varchar(3) | Nein | Lager-ID, auf die Änderungen und Bestände beschränkt werden. Leer oder NULL bedeutet alle Lager. |\n| `DateTo` | datetime | Nein | Ende des Änderungszeitraums (inklusive). NULL, `0` oder ein Datum bis einschließlich 1990-01-01 bedeutet die aktuelle Zeit. |\n| `Start` | int | Nein | Nullbasierter Offset für das Paging. Geliefert werden Zeilen mit `RowNr` größer als `Start`. |\n| `ExcludeBinGroups` | varchar(max) | Nein | Kommagetrennte Liste von Lagerplatzgruppen, deren Mengen von den Bestandswerten abgezogen werden. Leer oder NULL deaktiviert den Ausschluss. |\n\n**Nebeneffekt**\n\n- Jeder Aufruf schreibt einen Eintrag mit `Since`, `Rowcount` und Laufzeit in `LogTable`. Der Eintrag trägt die Bezeichnung `pipiGetChangedItemStock`.\n\n**Sperren**\n\n- Alle Lesezugriffe verwenden `NOLOCK`; nicht festgeschriebene Daten sind möglich.\n\n**Fallstricke**\n\n- `Since` = `0` / `1900-01-01` wird zu NULL. Der Datumsfilter trifft dann nichts und das Ergebnis ist leer.\n- `DateTo` wird bei NULL, `0` oder Werten bis einschließlich `1990-01-01` durch die aktuelle Zeit ersetzt.\n- Das Zeitfenster basiert vorrangig auf `items.LastCalculateStockDate`, nicht auf dem Datum des einzelnen Protokolleintrags.\n- Der Filter für `HAL`-Positionen subtrahiert ein Datum von einem Datum. Mit der Einstellung `HalOrdersActiveDays` (Standard 7 bei `0`) werden dadurch praktisch alle `HAL`-Positionen berücksichtigt statt nur die der letzten N Tage.\n- Bei aktivierten Reservierungen wird die Anzahl der Reservierungszeilen abgezogen, keine Menge.\n- Artikel ohne `ItemLocationSpecific`-Zeile (bzw. ohne Zeile für `LocID`) behalten leere Artikelnummern, Bestand `0` und `Enabled` NULL.\n- `PhysicalStock` kann NULL sein, wenn bei leerem `LocID` keine positive Lagermenge existiert.\n- Der Ausschluss von Lagerplatzgruppen ist nicht auf `LocID` beschränkt.\n- Für Bundles bleiben `OpenSupplierOrderQTY` auf `0` und `EstimatedDelivery` NULL.\n- Die Einstellungen `ShowLocationStockInItemSearch` und `OldStockExport` werden gelesen, aber nicht verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedItemStock_LocID"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4711\n ART-1001\n 4006381333931\n SUP-55\n 25\n 20\n -3\n 2024-05-10T00:00:00\n 5\n true\n 50\n 2024-05-01T08:15:00\n 2024-05-01T08:15:00\n false\n 1\n \n"
}
]
},
{
"name": "pixiGetChangedItemStockSince",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T08:00:00\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, deren Bestand seit einem Zeitpunkt neu berechnet wurde, mit physischem und verfügbarem Bestand, Liefertermin und offener Lieferantenbestellmenge, seitenweise.\n\nDelta-Export der Artikelbestände auf Basis der Artikelspalte `LastCalculateStockDate`.\n\n1. Ist `Since` `NULL`, wird `0` (1900-01-01) verwendet, d. h. alle Artikel werden berücksichtigt. Ein `NULL` in `Start` wird als `0` behandelt.\n2. Die ersten `Start + Rowcount` Artikel mit `LastCalculateStockDate >= Since` werden ermittelt, sortiert nach `LastCalculateStockDate` und dann `ItemKey`. Jede Zeile erhält in dieser Reihenfolge eine fortlaufende `RowNr`.\n3. Für die Zeilen mit `RowNr > Start` werden die Artikeldaten ergänzt: Artikelnummern, EAN, physischer Bestand (`Quantity`), Mindestbestand, Aktiv-Kennzeichen, Stücklisten-/Bundle-Kennzeichen, der voraussichtliche Liefertermin aus der Tabelle der Liefertermine sowie der verfügbare Bestand.\n4. **Verfügbarer Bestand** ist der Exportbestand der Lagerplätze des Artikels abzüglich eines von Einstellungen abhängigen Abzugs:\n - Ist `StockExportUsePhysicalStock` gleich `'1'`, wird nichts abgezogen.\n - Andernfalls wird, wenn Reservierungen (`ReservePrepaymentOrders` = `'1'`) deaktiviert sind oder aktiv sind und `ExportAvailableStock_WhenReservationsAreEnabled` = `1` gilt, die Menge offener Auftragspositionen abgezogen.\n - Andernfalls wird bei aktiven Reservierungen die Menge offener Reservierungen abgezogen.\n - Bei Bundle-Artikeln erfolgt nie ein Abzug.\n5. Die offene Lieferantenbestellmenge wird je Artikel als Summe aus bestellter minus gelieferter minus nicht gelieferter Menge über Lieferantenbestellpositionen berechnet, deren Lieferantenbestellung einen als offen gekennzeichneten Status (`IsAllOpen = 1`) hat und deren Berücksichtigungs-Startdatum leer oder nicht in der Zukunft liegt.\n6. Zurückgegeben werden bis zu `Rowcount` Zeilen mit `RowNr > Start`, sortiert nach `RowNr`.\n\nPaging: `Start` ist die Anzahl zu überspringender Zeilen, `Rowcount` die Seitengröße. Für die nächste Seite `Start + Rowcount` mit gleichem `Since` übergeben oder mit dem letzten `UpdateDate` als neuem `Since` neu beginnen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Ja | Untergrenze (inklusive) für das Datum der letzten Bestandsberechnung des Artikels. `NULL` liefert alle Artikel. |\n| `Rowcount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen (Seitengröße). |\n| `Start` | int | Nein | Anzahl zu überspringender Zeilen; nur Zeilen mit `RowNr > Start` werden geliefert. `NULL` wird als `0` behandelt. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; Ergebnisse können nicht festgeschriebene Daten enthalten und sich zwischen Paging-Aufrufen verschieben, wenn Bestände zwischenzeitlich neu berechnet werden (die Reihenfolge hängt von `LastCalculateStockDate` ab).\n- Der Filter lautet `>= Since`; wird mit dem letzten `UpdateDate` als `Since` fortgesetzt, werden Artikel mit genau diesem Zeitstempel erneut geliefert.\n- Die Spalte `OpenSupplierOrderQTY` wird nie befüllt und ist immer `0`. Die tatsächliche offene Lieferantenbestellmenge steht in `OpenSupplOrdersQty`; sie ist `NULL`, wenn der Artikel keine offenen Lieferantenbestellpositionen hat.\n- `Rowcount` darf nicht `NULL` sein; `TOP` mit `NULL` führt zu einem SQL-Fehler.\n- Einstellungen werden über `fpixi_GetSetting` gelesen; fehlende Einstellungen gelten als `'0'`. Die Einstellung `ExportAvailableStock_WhenReservationsAreEnabled` wird nach `int` konvertiert, ein nicht numerischer Wert führt zu einem Konvertierungsfehler.\n- Der Aufwand steigt mit `Start`, da bei jedem Aufruf `Start + Rowcount` Zeilen vorbereitet werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedItemStockSince"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T08:00:00\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, deren Bestand seit einem Zeitpunkt neu berechnet wurde, mit physischem und verfügbarem Bestand, Liefertermin und offener Lieferantenbestellmenge, seitenweise.\n\nDelta-Export der Artikelbestände auf Basis der Artikelspalte `LastCalculateStockDate`.\n\n1. Ist `Since` `NULL`, wird `0` (1900-01-01) verwendet, d. h. alle Artikel werden berücksichtigt. Ein `NULL` in `Start` wird als `0` behandelt.\n2. Die ersten `Start + Rowcount` Artikel mit `LastCalculateStockDate >= Since` werden ermittelt, sortiert nach `LastCalculateStockDate` und dann `ItemKey`. Jede Zeile erhält in dieser Reihenfolge eine fortlaufende `RowNr`.\n3. Für die Zeilen mit `RowNr > Start` werden die Artikeldaten ergänzt: Artikelnummern, EAN, physischer Bestand (`Quantity`), Mindestbestand, Aktiv-Kennzeichen, Stücklisten-/Bundle-Kennzeichen, der voraussichtliche Liefertermin aus der Tabelle der Liefertermine sowie der verfügbare Bestand.\n4. **Verfügbarer Bestand** ist der Exportbestand der Lagerplätze des Artikels abzüglich eines von Einstellungen abhängigen Abzugs:\n - Ist `StockExportUsePhysicalStock` gleich `'1'`, wird nichts abgezogen.\n - Andernfalls wird, wenn Reservierungen (`ReservePrepaymentOrders` = `'1'`) deaktiviert sind oder aktiv sind und `ExportAvailableStock_WhenReservationsAreEnabled` = `1` gilt, die Menge offener Auftragspositionen abgezogen.\n - Andernfalls wird bei aktiven Reservierungen die Menge offener Reservierungen abgezogen.\n - Bei Bundle-Artikeln erfolgt nie ein Abzug.\n5. Die offene Lieferantenbestellmenge wird je Artikel als Summe aus bestellter minus gelieferter minus nicht gelieferter Menge über Lieferantenbestellpositionen berechnet, deren Lieferantenbestellung einen als offen gekennzeichneten Status (`IsAllOpen = 1`) hat und deren Berücksichtigungs-Startdatum leer oder nicht in der Zukunft liegt.\n6. Zurückgegeben werden bis zu `Rowcount` Zeilen mit `RowNr > Start`, sortiert nach `RowNr`.\n\nPaging: `Start` ist die Anzahl zu überspringender Zeilen, `Rowcount` die Seitengröße. Für die nächste Seite `Start + Rowcount` mit gleichem `Since` übergeben oder mit dem letzten `UpdateDate` als neuem `Since` neu beginnen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Ja | Untergrenze (inklusive) für das Datum der letzten Bestandsberechnung des Artikels. `NULL` liefert alle Artikel. |\n| `Rowcount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen (Seitengröße). |\n| `Start` | int | Nein | Anzahl zu überspringender Zeilen; nur Zeilen mit `RowNr > Start` werden geliefert. `NULL` wird als `0` behandelt. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; Ergebnisse können nicht festgeschriebene Daten enthalten und sich zwischen Paging-Aufrufen verschieben, wenn Bestände zwischenzeitlich neu berechnet werden (die Reihenfolge hängt von `LastCalculateStockDate` ab).\n- Der Filter lautet `>= Since`; wird mit dem letzten `UpdateDate` als `Since` fortgesetzt, werden Artikel mit genau diesem Zeitstempel erneut geliefert.\n- Die Spalte `OpenSupplierOrderQTY` wird nie befüllt und ist immer `0`. Die tatsächliche offene Lieferantenbestellmenge steht in `OpenSupplOrdersQty`; sie ist `NULL`, wenn der Artikel keine offenen Lieferantenbestellpositionen hat.\n- `Rowcount` darf nicht `NULL` sein; `TOP` mit `NULL` führt zu einem SQL-Fehler.\n- Einstellungen werden über `fpixi_GetSetting` gelesen; fehlende Einstellungen gelten als `'0'`. Die Einstellung `ExportAvailableStock_WhenReservationsAreEnabled` wird nach `int` konvertiert, ein nicht numerischer Wert führt zu einem Konvertierungsfehler.\n- Der Aufwand steigt mit `Start`, da bei jedem Aufruf `Start + Rowcount` Zeilen vorbereitet werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetChangedItemStockSince"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 10452\n ART-10452\n 4006381333931\n SUP-7781\n 25\n 21\n 2024-05-10T00:00:00\n 5\n true\n 0\n 2024-05-01T08:15:22.380\n false\n 40\n \n \n 2\n 10987\n ART-10987\n 4006381345675\n SUP-9012\n 0\n 0\n 0\n true\n 0\n 2024-05-01T08:16:03.120\n false\n \n"
}
]
},
{
"name": "pixiGetItemLogisticsStock",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10452\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den gesamten Lagerplatzbestand eines Artikels an einem Standort und die nach Abzug offener FUT-Auftragspositionen noch verfügbare Menge.\n\nBerechnet den Bestand eines einzelnen Artikels für Direct-Fulfillment-Zwecke (DF), laut Code-Kommentar *Bestand auf Basis offener DF-Aufträge*.\n\nAblauf:\n\n1. Summiert `BinItemQty` aller Lagerplatzeinträge in `InvBinItem` für den Artikel `@ItemKey`, deren Lagerplatz (`InvBin`) zum Standort `@Location` (`BinLocId`) gehört. Diese Summe wird als `TotalQty` zurückgegeben (0, wenn keine passenden Lagerplätze existieren).\n2. Summiert `Qty` aller Auftragspositionen in `Orderlines` für den Artikel, die\n - den Status `FUT` haben,\n - `Qty > 0` haben und\n - **keinen** Eintrag in `OrderHistory` mit Status `FUT` und `ClientNotified = 'N'` besitzen.\n3. Liefert `TotalQty` abzüglich dieser Positionssumme als `FulfillmentAvailableQty` sowie den übergebenen `@Location`.\n\nDer Aufruf liefert immer genau eine Zeile, da ohne Gruppierung aggregiert wird.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Ja | Interner Schlüssel des Artikels, dessen Bestand berechnet wird (Abgleich mit `InvBinItem.BinItemRef` und `Orderlines.ItemRef`). |\n| `Location` | char(3) | Nein | Standortkürzel (`InvBin.BinLocId`), dessen Lagerplätze summiert werden. Wird im Ergebnis zurückgegeben. Bei NULL passt kein Lagerplatz und der Bestand ist 0. |\n\n- Wird `@Location` weggelassen (NULL), trifft der Vergleich `BinLocId = NULL` nie zu; `TotalQty` ist dann immer 0 und `FulfillmentAvailableQty` 0 oder negativ. Es sollte daher immer ein Standort übergeben werden.\n- Die Menge offener Auftragspositionen wird **nicht** nach Standort gefiltert: FUT-Positionen aller Standorte werden vom Bestand des angegebenen Standorts abgezogen.\n- `FulfillmentAvailableQty` kann negativ werden, wenn die offenen FUT-Mengen den Lagerplatzbestand übersteigen.\n- Ein unbekannter `@ItemKey` erzeugt keinen Fehler; es wird eine Zeile mit Werten 0 geliefert.\n- Alle Tabellen werden mit `NOLOCK` gelesen, das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemLogisticsStock"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10452\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den gesamten Lagerplatzbestand eines Artikels an einem Standort und die nach Abzug offener FUT-Auftragspositionen noch verfügbare Menge.\n\nBerechnet den Bestand eines einzelnen Artikels für Direct-Fulfillment-Zwecke (DF), laut Code-Kommentar *Bestand auf Basis offener DF-Aufträge*.\n\nAblauf:\n\n1. Summiert `BinItemQty` aller Lagerplatzeinträge in `InvBinItem` für den Artikel `@ItemKey`, deren Lagerplatz (`InvBin`) zum Standort `@Location` (`BinLocId`) gehört. Diese Summe wird als `TotalQty` zurückgegeben (0, wenn keine passenden Lagerplätze existieren).\n2. Summiert `Qty` aller Auftragspositionen in `Orderlines` für den Artikel, die\n - den Status `FUT` haben,\n - `Qty > 0` haben und\n - **keinen** Eintrag in `OrderHistory` mit Status `FUT` und `ClientNotified = 'N'` besitzen.\n3. Liefert `TotalQty` abzüglich dieser Positionssumme als `FulfillmentAvailableQty` sowie den übergebenen `@Location`.\n\nDer Aufruf liefert immer genau eine Zeile, da ohne Gruppierung aggregiert wird.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Ja | Interner Schlüssel des Artikels, dessen Bestand berechnet wird (Abgleich mit `InvBinItem.BinItemRef` und `Orderlines.ItemRef`). |\n| `Location` | char(3) | Nein | Standortkürzel (`InvBin.BinLocId`), dessen Lagerplätze summiert werden. Wird im Ergebnis zurückgegeben. Bei NULL passt kein Lagerplatz und der Bestand ist 0. |\n\n- Wird `@Location` weggelassen (NULL), trifft der Vergleich `BinLocId = NULL` nie zu; `TotalQty` ist dann immer 0 und `FulfillmentAvailableQty` 0 oder negativ. Es sollte daher immer ein Standort übergeben werden.\n- Die Menge offener Auftragspositionen wird **nicht** nach Standort gefiltert: FUT-Positionen aller Standorte werden vom Bestand des angegebenen Standorts abgezogen.\n- `FulfillmentAvailableQty` kann negativ werden, wenn die offenen FUT-Mengen den Lagerplatzbestand übersteigen.\n- Ein unbekannter `@ItemKey` erzeugt keinen Fehler; es wird eine Zeile mit Werten 0 geliefert.\n- Alle Tabellen werden mit `NOLOCK` gelesen, das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemLogisticsStock"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 37\n 45\n 001\n \n"
}
]
},
{
"name": "pixiGetItemsOnStockBin",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Artikel auf einem Lagerplatz oder einer Lagerplatzgruppe mit Bestand, Charge und Mindesthaltbarkeitsdatum.\n\nListet den Lagerplatzbestand (`InvBinItem`) eines Lagerplatzes oder aller Lagerplätze einer Lagerplatzgruppe zusammen mit den Artikelstammdaten auf.\n\n- Leere Zeichenketten in `BinName`, `LocID` und `BinGroup` werden wie `NULL` behandelt.\n- Mindestens einer der Parameter `BinName` oder `BinGroup` muss gesetzt sein. Sind beide leer, liefert der Aufruf eine leere Ergebnismenge.\n- `BinName` filtert auf den exakten Lagerplatznamen, `BinGroup` auf die exakte Lagerplatzgruppe, `LocID` beschränkt die Lagerplätze auf ein Lager. Alle gesetzten Filter werden mit UND verknüpft.\n- Die interne Artikelnummer in `InternalItemNumber` stammt aus den Artikelcodes mit Codetyp `3`. Sie ist leer, wenn der Artikel keinen solchen Code hat.\n\nDer Parameter `GroupItems` steuert die Gruppierung:\n\n- `0` (Standard): eine Zeile je Artikel, Lagerplatz, Charge, Mindesthaltbarkeitsdatum **und** Änderungsdatum des Lagerplatzbestands. Sortierung aufsteigend nach `UpdateDate`.\n- `1`: eine Zeile je Artikel, Lagerplatz, Charge und Mindesthaltbarkeitsdatum. Die Mengen werden summiert, `UpdateDate` enthält das jüngste Änderungsdatum. Sortierung aufsteigend nach diesem Datum.\n\n`StockLevel` ist die Summe der Lagerplatzmengen innerhalb jeder Gruppe.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BinName` | varchar(50) | Nein | Exakter Name des Lagerplatzes. Eine leere Zeichenkette wird wie NULL behandelt. Dieser Parameter oder `BinGroup` muss gesetzt sein. |\n| `LocID` | varchar(3) | Nein | Lagerkennung; beschränkt die Lagerplätze auf dieses Lager. Leer oder NULL bedeutet alle Lager. |\n| `GroupItems` | bit | Nein | Steuert, ob Lagerplatzbestände mit unterschiedlichem Änderungsdatum zu einer Zeile zusammengefasst werden. |\n| `BinGroup` | varchar(20) | Nein | Exakte Lagerplatzgruppe; liefert die Artikel aller Lagerplätze dieser Gruppe. Eine leere Zeichenkette wird wie NULL behandelt. Dieser Parameter oder `BinName` muss gesetzt sein. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Bei `GroupItems = 0` kann derselbe Artikel auf demselben Lagerplatz mehrfach erscheinen, wenn seine Lagerplatzbestände unterschiedliche Änderungsdaten haben. Für eine Zeile je Artikel, Lagerplatz, Charge und Mindesthaltbarkeitsdatum `GroupItems = 1` verwenden.\n- Hat ein Artikel mehrere Artikelcodes vom Typ `3`, erscheint er einmal je Code.\n- Wird nur `BinName` ohne `LocID` übergeben, werden gleichnamige Lagerplätze aller Lager geliefert. Das Lager ist nicht Teil der Ausgabe; daher `LocID` angeben, wenn Lagerplatznamen nicht lagerübergreifend eindeutig sind.\n- Jeder Wert von `GroupItems` ungleich 0 wirkt wie `1`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemsOnStockBin"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Artikel auf einem Lagerplatz oder einer Lagerplatzgruppe mit Bestand, Charge und Mindesthaltbarkeitsdatum.\n\nListet den Lagerplatzbestand (`InvBinItem`) eines Lagerplatzes oder aller Lagerplätze einer Lagerplatzgruppe zusammen mit den Artikelstammdaten auf.\n\n- Leere Zeichenketten in `BinName`, `LocID` und `BinGroup` werden wie `NULL` behandelt.\n- Mindestens einer der Parameter `BinName` oder `BinGroup` muss gesetzt sein. Sind beide leer, liefert der Aufruf eine leere Ergebnismenge.\n- `BinName` filtert auf den exakten Lagerplatznamen, `BinGroup` auf die exakte Lagerplatzgruppe, `LocID` beschränkt die Lagerplätze auf ein Lager. Alle gesetzten Filter werden mit UND verknüpft.\n- Die interne Artikelnummer in `InternalItemNumber` stammt aus den Artikelcodes mit Codetyp `3`. Sie ist leer, wenn der Artikel keinen solchen Code hat.\n\nDer Parameter `GroupItems` steuert die Gruppierung:\n\n- `0` (Standard): eine Zeile je Artikel, Lagerplatz, Charge, Mindesthaltbarkeitsdatum **und** Änderungsdatum des Lagerplatzbestands. Sortierung aufsteigend nach `UpdateDate`.\n- `1`: eine Zeile je Artikel, Lagerplatz, Charge und Mindesthaltbarkeitsdatum. Die Mengen werden summiert, `UpdateDate` enthält das jüngste Änderungsdatum. Sortierung aufsteigend nach diesem Datum.\n\n`StockLevel` ist die Summe der Lagerplatzmengen innerhalb jeder Gruppe.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BinName` | varchar(50) | Nein | Exakter Name des Lagerplatzes. Eine leere Zeichenkette wird wie NULL behandelt. Dieser Parameter oder `BinGroup` muss gesetzt sein. |\n| `LocID` | varchar(3) | Nein | Lagerkennung; beschränkt die Lagerplätze auf dieses Lager. Leer oder NULL bedeutet alle Lager. |\n| `GroupItems` | bit | Nein | Steuert, ob Lagerplatzbestände mit unterschiedlichem Änderungsdatum zu einer Zeile zusammengefasst werden. |\n| `BinGroup` | varchar(20) | Nein | Exakte Lagerplatzgruppe; liefert die Artikel aller Lagerplätze dieser Gruppe. Eine leere Zeichenkette wird wie NULL behandelt. Dieser Parameter oder `BinName` muss gesetzt sein. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; das Ergebnis kann daher nicht festgeschriebene Daten enthalten.\n- Bei `GroupItems = 0` kann derselbe Artikel auf demselben Lagerplatz mehrfach erscheinen, wenn seine Lagerplatzbestände unterschiedliche Änderungsdaten haben. Für eine Zeile je Artikel, Lagerplatz, Charge und Mindesthaltbarkeitsdatum `GroupItems = 1` verwenden.\n- Hat ein Artikel mehrere Artikelcodes vom Typ `3`, erscheint er einmal je Code.\n- Wird nur `BinName` ohne `LocID` übergeben, werden gleichnamige Lagerplätze aller Lager geliefert. Das Lager ist nicht Teil der Ausgabe; daher `LocID` angeben, wenn Lagerplatznamen nicht lagerübergreifend eindeutig sind.\n- Jeder Wert von `GroupItems` ungleich 0 wirkt wie `1`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemsOnStockBin"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n 4006381333931\n ART-10452\n SUP-7781\n 24\n 2024-03-12T09:41:00\n Kugelschreiber blau\n INT-10452\n PICK\n A-01-03\n CH2024-03\n 2026-03-31T00:00:00\n \n"
}
]
},
{
"name": "pixiGetItemsOnStockBinPickList",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n A-01-02\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Artikel auf einem Lagerplatz, die Artikel dieses Lagerplatzes auf offenen Picklisten und in Boxen sowie einen kombinierten Statuscode.\n\nErmittelt den Lagerplatz anhand von `BinName` und `LocID` in `InvBin` und liefert anschließend vier Ergebnismengen.\n\n1. **Artikel auf dem Lagerplatz** aus `InvBinItem` verknüpft mit `Items`, mit EAN, interner und Lieferanten-Artikelnummer sowie der summierten Menge als `StockLevel`.\n - `GroupItems = 0` (Standard): eine Zeile je Artikel und `UpdateDate` des Lagerplatzeintrags, sortiert nach `UpdateDate`.\n - `GroupItems = 1`: eine Zeile je Artikel; `UpdateDate` ist das jüngste Änderungsdatum, danach sortiert.\n2. **Picklisteneinträge** aus `PLitem` für diesen Lagerplatz, die nicht abgelaufen sind (`Expired = 0`) und deren Auftragspositionsstatus nicht `AUS`, `NLB`, `RET`, `STO` oder `EIN` ist. Gruppiert nach Artikel und Pickliste; `Sum_PickListItem` ist die Anzahl der Picklistenpositionen. Keine explizite Sortierung.\n3. **Boxinhalte**: nicht abgelaufene Picklisteneinträge für diesen Lagerplatz, deren Auftragsposition den Status `EIN` hat, verknüpft mit `boxitems` und `boxes`. Gruppiert nach Artikel und Boxnummer; `sum_box_item` ist die summierte Boxmenge. Keine explizite Sortierung.\n4. **Status**-Zeile mit einem vierstelligen Code:\n - `1000`: keine Artikel auf dem Lagerplatz (unabhängig von Picklisten und Boxen)\n - `1100`: Artikel vorhanden, keine auf Picklisten, keine in Boxen\n - `1101`: Artikel vorhanden, keine auf Picklisten, welche in Boxen\n - `1110`: Artikel vorhanden, welche auf Picklisten, keine in Boxen\n - `1111`: Artikel vorhanden, auf Picklisten und in Boxen\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BinName` | varchar(50) | Ja | Name des zu prüfenden Lagerplatzes. |\n| `LocID` | varchar(3) | Nein | Lager-ID des Lagerplatzes. Faktisch erforderlich, da NULL keinen Lagerplatz trifft. |\n| `GroupItems` | bit | Nein | Steuert die Gruppierung der ersten Ergebnismenge. |\n\n- Die Suche nach dem Lagerplatz vergleicht `BinLocID = @LocID`. Wird `LocID` weggelassen (NULL), wird bei standardmäßigem NULL-Vergleich kein Lagerplatz gefunden, alle Ergebnismengen sind leer und der Status ist `1000`. `LocID` sollte daher immer übergeben werden.\n- Bei Status `1000` können trotzdem Picklisten- und Boxzeilen geliefert worden sein; der Code wertet sie in diesem Fall nicht aus.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, die Daten können daher nicht festgeschriebene Änderungen enthalten.\n- Die zweite Ergebnismenge wiederholt den übergebenen `BinName` in jeder Zeile.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemsOnStockBinPickList"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n A-01-02\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Artikel auf einem Lagerplatz, die Artikel dieses Lagerplatzes auf offenen Picklisten und in Boxen sowie einen kombinierten Statuscode.\n\nErmittelt den Lagerplatz anhand von `BinName` und `LocID` in `InvBin` und liefert anschließend vier Ergebnismengen.\n\n1. **Artikel auf dem Lagerplatz** aus `InvBinItem` verknüpft mit `Items`, mit EAN, interner und Lieferanten-Artikelnummer sowie der summierten Menge als `StockLevel`.\n - `GroupItems = 0` (Standard): eine Zeile je Artikel und `UpdateDate` des Lagerplatzeintrags, sortiert nach `UpdateDate`.\n - `GroupItems = 1`: eine Zeile je Artikel; `UpdateDate` ist das jüngste Änderungsdatum, danach sortiert.\n2. **Picklisteneinträge** aus `PLitem` für diesen Lagerplatz, die nicht abgelaufen sind (`Expired = 0`) und deren Auftragspositionsstatus nicht `AUS`, `NLB`, `RET`, `STO` oder `EIN` ist. Gruppiert nach Artikel und Pickliste; `Sum_PickListItem` ist die Anzahl der Picklistenpositionen. Keine explizite Sortierung.\n3. **Boxinhalte**: nicht abgelaufene Picklisteneinträge für diesen Lagerplatz, deren Auftragsposition den Status `EIN` hat, verknüpft mit `boxitems` und `boxes`. Gruppiert nach Artikel und Boxnummer; `sum_box_item` ist die summierte Boxmenge. Keine explizite Sortierung.\n4. **Status**-Zeile mit einem vierstelligen Code:\n - `1000`: keine Artikel auf dem Lagerplatz (unabhängig von Picklisten und Boxen)\n - `1100`: Artikel vorhanden, keine auf Picklisten, keine in Boxen\n - `1101`: Artikel vorhanden, keine auf Picklisten, welche in Boxen\n - `1110`: Artikel vorhanden, welche auf Picklisten, keine in Boxen\n - `1111`: Artikel vorhanden, auf Picklisten und in Boxen\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BinName` | varchar(50) | Ja | Name des zu prüfenden Lagerplatzes. |\n| `LocID` | varchar(3) | Nein | Lager-ID des Lagerplatzes. Faktisch erforderlich, da NULL keinen Lagerplatz trifft. |\n| `GroupItems` | bit | Nein | Steuert die Gruppierung der ersten Ergebnismenge. |\n\n- Die Suche nach dem Lagerplatz vergleicht `BinLocID = @LocID`. Wird `LocID` weggelassen (NULL), wird bei standardmäßigem NULL-Vergleich kein Lagerplatz gefunden, alle Ergebnismengen sind leer und der Status ist `1000`. `LocID` sollte daher immer übergeben werden.\n- Bei Status `1000` können trotzdem Picklisten- und Boxzeilen geliefert worden sein; der Code wertet sie in diesem Fall nicht aus.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, die Daten können daher nicht festgeschriebene Änderungen enthalten.\n- Die zweite Ergebnismenge wiederholt den übergebenen `BinName` in jeder Zeile.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemsOnStockBinPickList"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n 4006381333931\n ART-10452\n SUP-7781\n 12\n 2024-03-11T09:15:00\n \n \n 10877\n 4006381334112\n ART-10877\n SUP-8020\n 4\n 2024-03-12T14:02:00\n \n"
}
]
},
{
"name": "pixiGetItemsStockHistory",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T00:00:00\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert das Lagerplatz-Bewegungsprotokoll aller Artikel in einem Zeitraum, optional gefiltert nach Lager, Auftrag, Lieferung und Umlagerungstransaktion.\n\nLiefert Einträge des Lagerplatz-Artikelprotokolls (Bestandsbewegungen auf Lagerplätzen), ähnlich der Lagerplatzhistorie im Pixi-Client, jedoch für alle Artikel gleichzeitig.\n\nAblauf:\n\n1. Normalisiert die Eingaben: ein leeres oder fehlendes `DateTo` wird zum aktuellen Zeitpunkt, leere Werte in `Location` und `OrderNumberExternal` werden (nach Trimmen) zu `NULL`, `DeliveryNumber` = `0` gilt als kein Filter, `RowCount` ist standardmäßig `1000` und `IbilKey` `0`.\n2. Wählt Protokolleinträge mit:\n - `IBILkey` größer als `IbilKey` (für Paging),\n - `UpdateDate` >= `DateFrom` und < `DateTo` (die Obergrenze ist exklusiv),\n - optional `LocID` = `Location`,\n - optional externe Auftragsnummer der verknüpften Auftragsposition = `OrderNumberExternal`,\n - optional Nummer der verknüpften Lieferantenlieferung = `DeliveryNumber`,\n - optional verknüpfte Umlagerungstransaktion = `RelocateTransactionID`,\n - Einträge des Benutzers `AutoExport` werden immer ausgeschlossen.\n3. Ergänzt jeden Eintrag um Artikeldaten (interne Artikelnummer, EAN, Lieferanten-Artikelnummer), Lagerplatzname, Bewegungstyp und -operation, Chargennummer, Mindesthaltbarkeitsdatum, Umlagerungstransaktions-ID, Liefernummer und externe Auftragsnummer.\n4. Liefert höchstens `RowCount` Zeilen, sortiert nach `IBILkey` aufsteigend.\n\n**Paging:** Den höchsten `IBILkey` der vorherigen Antwort als `IbilKey` übergeben, um die nächste Seite abzurufen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Ja | Beginn des Zeitraums (inklusive), verglichen mit `UpdateDate` des Protokolleintrags. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (exklusiv). Bei `NULL` oder leer wird der aktuelle Zeitpunkt verwendet. |\n| `Location` | varchar(3) | Nein | Optionale Lager-ID; nur Einträge mit dieser `LocID` werden geliefert. Leer bedeutet alle Lager. |\n| `OrderNumberExternal` | varchar(50) | Nein | Optionale externe Auftragsnummer; nur Einträge, die mit einer Auftragsposition mit dieser `OrderNrExternal` verknüpft sind, werden geliefert. Leer bedeutet kein Filter. |\n| `DeliveryNumber` | int | Nein | Optionale Nummer der Lieferantenlieferung (`SDelHNr`); nur Einträge dieser Lieferung werden geliefert. `0` bedeutet kein Filter. |\n| `RelocateTransactionID` | uniqueidentifier | Nein | Optionale Umlagerungstransaktions-ID; nur Einträge dieser Umlagerungstransaktion werden geliefert. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. `NULL` wird als `1000` behandelt. |\n| `IbilKey` | int | Nein | Paging-Cursor: nur Einträge mit `IBILkey` größer als dieser Wert werden geliefert. Den letzten `IBILkey` der vorherigen Seite übergeben. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Bewegungen können erscheinen, und die Ergebnisse sind nicht garantiert konsistent.\n- Die Prozedur ist mit `WITH RECOMPILE` angelegt; bei jedem Aufruf wird ein neuer Ausführungsplan erstellt.\n- Einträge mit `UpdateEmp` = `AutoExport` oder `NULL` werden nie geliefert (der Vergleich `<> 'AutoExport'` schließt `NULL` aus).\n- Lagerplätze werden per LEFT JOIN verknüpft; Einträge gelöschter Lagerplätze erscheinen mit leerem `BinName`. Protokolleinträge, deren Artikel nicht mehr in `Items` existiert, werden nicht geliefert.\n- Wird `OrderNumberExternal`, `DeliveryNumber` oder `RelocateTransactionID` gesetzt, werden implizit nur Einträge geliefert, die mit einer Auftragsposition, Lieferung bzw. Umlagerungstransaktion verknüpft sind.\n- Ist ein Protokolleintrag mit mehreren Umlagerungstransaktionen verknüpft, kann er mehrfach erscheinen.\n- Ein negativer `RowCount` führt zu einem SQL-Fehler bei `TOP`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemsStockHistory"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 2024-05-01T00:00:00\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert das Lagerplatz-Bewegungsprotokoll aller Artikel in einem Zeitraum, optional gefiltert nach Lager, Auftrag, Lieferung und Umlagerungstransaktion.\n\nLiefert Einträge des Lagerplatz-Artikelprotokolls (Bestandsbewegungen auf Lagerplätzen), ähnlich der Lagerplatzhistorie im Pixi-Client, jedoch für alle Artikel gleichzeitig.\n\nAblauf:\n\n1. Normalisiert die Eingaben: ein leeres oder fehlendes `DateTo` wird zum aktuellen Zeitpunkt, leere Werte in `Location` und `OrderNumberExternal` werden (nach Trimmen) zu `NULL`, `DeliveryNumber` = `0` gilt als kein Filter, `RowCount` ist standardmäßig `1000` und `IbilKey` `0`.\n2. Wählt Protokolleinträge mit:\n - `IBILkey` größer als `IbilKey` (für Paging),\n - `UpdateDate` >= `DateFrom` und < `DateTo` (die Obergrenze ist exklusiv),\n - optional `LocID` = `Location`,\n - optional externe Auftragsnummer der verknüpften Auftragsposition = `OrderNumberExternal`,\n - optional Nummer der verknüpften Lieferantenlieferung = `DeliveryNumber`,\n - optional verknüpfte Umlagerungstransaktion = `RelocateTransactionID`,\n - Einträge des Benutzers `AutoExport` werden immer ausgeschlossen.\n3. Ergänzt jeden Eintrag um Artikeldaten (interne Artikelnummer, EAN, Lieferanten-Artikelnummer), Lagerplatzname, Bewegungstyp und -operation, Chargennummer, Mindesthaltbarkeitsdatum, Umlagerungstransaktions-ID, Liefernummer und externe Auftragsnummer.\n4. Liefert höchstens `RowCount` Zeilen, sortiert nach `IBILkey` aufsteigend.\n\n**Paging:** Den höchsten `IBILkey` der vorherigen Antwort als `IbilKey` übergeben, um die nächste Seite abzurufen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Ja | Beginn des Zeitraums (inklusive), verglichen mit `UpdateDate` des Protokolleintrags. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (exklusiv). Bei `NULL` oder leer wird der aktuelle Zeitpunkt verwendet. |\n| `Location` | varchar(3) | Nein | Optionale Lager-ID; nur Einträge mit dieser `LocID` werden geliefert. Leer bedeutet alle Lager. |\n| `OrderNumberExternal` | varchar(50) | Nein | Optionale externe Auftragsnummer; nur Einträge, die mit einer Auftragsposition mit dieser `OrderNrExternal` verknüpft sind, werden geliefert. Leer bedeutet kein Filter. |\n| `DeliveryNumber` | int | Nein | Optionale Nummer der Lieferantenlieferung (`SDelHNr`); nur Einträge dieser Lieferung werden geliefert. `0` bedeutet kein Filter. |\n| `RelocateTransactionID` | uniqueidentifier | Nein | Optionale Umlagerungstransaktions-ID; nur Einträge dieser Umlagerungstransaktion werden geliefert. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. `NULL` wird als `1000` behandelt. |\n| `IbilKey` | int | Nein | Paging-Cursor: nur Einträge mit `IBILkey` größer als dieser Wert werden geliefert. Den letzten `IBILkey` der vorherigen Seite übergeben. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Bewegungen können erscheinen, und die Ergebnisse sind nicht garantiert konsistent.\n- Die Prozedur ist mit `WITH RECOMPILE` angelegt; bei jedem Aufruf wird ein neuer Ausführungsplan erstellt.\n- Einträge mit `UpdateEmp` = `AutoExport` oder `NULL` werden nie geliefert (der Vergleich `<> 'AutoExport'` schließt `NULL` aus).\n- Lagerplätze werden per LEFT JOIN verknüpft; Einträge gelöschter Lagerplätze erscheinen mit leerem `BinName`. Protokolleinträge, deren Artikel nicht mehr in `Items` existiert, werden nicht geliefert.\n- Wird `OrderNumberExternal`, `DeliveryNumber` oder `RelocateTransactionID` gesetzt, werden implizit nur Einträge geliefert, die mit einer Auftragsposition, Lieferung bzw. Umlagerungstransaktion verknüpft sind.\n- Ist ein Protokolleintrag mit mehreren Umlagerungstransaktionen verknüpft, kann er mehrfach erscheinen.\n- Ein negativer `RowCount` führt zu einem SQL-Fehler bei `TOP`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemsStockHistory"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1520345\n 8812\n ART-10023\n 4012345678901\n SUP-5521\n -1\n MMU\n 2024-05-01T09:15:22\n A-01-03\n 001\n 334455\n Picking\n OUT\n PickApp/Pick\n SHOP-100234\n \n \n 1520346\n 9021\n ART-20077\n 4012345678918\n SUP-7710\n 24\n KOB\n 2024-05-01T10:02:05\n B-12-01\n 001\n Goods receipt\n IN\n Client/Booking\n CH2024-05\n 2025-12-31T00:00:00\n 4711\n \n"
}
]
},
{
"name": "pixiGetItemStock",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert verfügbaren und physischen Bestand, Lieferantenpreis und offene Auftragspositionsmengen für einen oder mehrere Artikel, optional je Lager.\n\nSucht Artikel und liefert deren Bestandswerte.\n\n**Artikelidentifikation**\n- Leere Zeichenketten werden als `NULL` behandelt; `ItemKey = 0` gilt als `NULL`.\n- Mindestens einer der Parameter `ItemKey`, `EAN`, `ItemNrSuppl`, `ItemNrInt` oder `ItemXML` ist erforderlich, sonst wird eine Fehlerzeile geliefert.\n- Die Einzelparameter werden mit **ODER** gegen `pixi.ItemCode` verknüpft: `EAN` entspricht Codetyp 1 (Barcode), `ItemNrInt` Codetyp 2 (Shop-Artikelnr.), `ItemNrSuppl` Codetyp 4 (Lieferanten-Artikelnr.), `ItemKey` der Artikel-ID einer beliebigen Codezeile.\n- `ItemXML` ergänzt weitere Artikel: Jedes Element `/ITEMS/ITEM` kann `ITEMKEY` (direkt übernommen), `ITEMNRINT`, `ITEMNRSUPPL` oder `EAN` enthalten (Abgleich mit `items.ItemNrInt`, `items.ItemNrSuppl` und `items.EANUPC`).\n- Wird kein Kandidat gefunden, wird eine Fehlerzeile geliefert.\n\n**Bestandsberechnung** (je Artikel aus `items`)\n- `AvailableStock` = `ItemQtyIBIExportStock_locations` abzüglich – bei Nicht-Bundle-Artikeln und wenn die Einstellung `StockExportUsePhysicalStock` `0` ist –\n - `ItemQtyOpenOrderLines`, wenn Reservierungen (`ReservePrepaymentOrders`) deaktiviert sind oder `ExportAvailableStock_WhenReservationsAreEnabled` = 1 ist,\n - sonst `ItemQtyOpenReservations`, wenn Reservierungen aktiv sind,\n - andernfalls wird nichts abgezogen.\n- `PhysicalStock` = Bestand außerhalb von Sonderlagern, `PhysicalStockAllLocations` = inklusive Sonderlager.\n- `OnlyEnabledItems = 1` beschränkt die Ausgabe auf aktive Artikel.\n\n**Ausschluss von Lagerplatzgruppen**\nIst `ExcludeBinGroups` (kommagetrennte Liste) angegeben, werden die Mengen auf Lagerplätzen (`InvBin`/`InvBinItemLog`) dieser Gruppen je Artikel summiert und von `AvailableStock`, `PhysicalStock` und `PhysicalStockAllLocations` abgezogen. Für Bundles mit solchen Komponenten wird zusätzlich eine abgeleitete Menge (Minimum über die Komponenten aus ausgeschlossener Menge geteilt durch Komponentenmenge, aufgerundet) abgezogen.\n\n**Aufschlüsselung nach Lager**\nMit `LocationStock = 1` werden zwei zusätzliche Textspalten geliefert:\n- `Locations`: `All:; :; …` mit Gesamtmenge und Menge je Lager.\n- `OpenOrderlineSumLocations`: `:; …; All:;` mit offenen Kundenauftragsmengen (ANG/FUT sowie aktuelle HAL-Aufträge) je Lager und gesamt, berechnet durch `pixi.ItemInfoStockPerLocation`.\n\nJe gefundenem Artikel wird eine Zeile geliefert; eine explizite Sortierung erfolgt nicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel. `0` gilt als nicht gesetzt. |\n| `EAN` | varchar(50) | Nein | Barcode des Artikels (Codetyp 1). |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer (Codetyp 4). |\n| `ItemNrInt` | varchar(50) | Nein | Shop-Artikelnummer (Codetyp 2). |\n| `LocationStock` | bit | Nein | Bei 1 enthält das Ergebnis zusätzlich die Spalten `Locations` und `OpenOrderlineSumLocations` je Lager. |\n| `OnlyEnabledItems` | bit | Nein | Beschränkt das Ergebnis auf aktive Artikel. |\n| `ExcludeBinGroups` | varchar(max) | Nein | Kommagetrennte Liste von Lagerplatzgruppen, deren Mengen von den Bestandswerten abgezogen werden. |\n| `ItemXML` | varchar(max) | Nein | XML-Liste weiterer Artikel. Jedes Element `/ITEMS/ITEM` kann `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL` und `EAN` (max. 13 Zeichen) enthalten. |\n\n- Nur lesend; alle Tabellen werden `WITH (NOLOCK)` gelesen, Werte können daher nicht festgeschriebene Daten enthalten.\n- Bei Fehlern liefert die Prozedur zusätzlich zur Statuszeile den Rückgabewert `1`.\n- `ItemKey` als Einzelparameter trifft nur, wenn der Artikel mindestens eine Zeile in `pixi.ItemCode` besitzt. `ITEMKEY`-Werte aus `ItemXML` werden nicht geprüft; unbekannte Schlüssel gelten als gefunden, erzeugen aber keine Ausgabezeile, sodass das Ergebnis ohne Fehlerzeile leer sein kann.\n- Ein Artikel, der sowohl über Einzelparameter als auch über `ItemXML` gefunden wird, kann doppelt im Ergebnis erscheinen.\n- `EAN` in `ItemXML` wird als `varchar(13)` gelesen; längere Werte werden abgeschnitten.\n- Wird `OnlyEnabledItems` explizit als NULL übergeben, werden keine Zeilen geliefert.\n- Der Ausschluss von Lagerplatzgruppen wirkt nur auf Artikel mit Shop-Artikelnr. (Codetyp 2), deren `ItemNrInt` diesem Code entspricht.\n- Die Reihenfolge der Einträge in `Locations` und `OpenOrderlineSumLocations` ist nicht garantiert.\n- `pixi.ItemInfoStockPerLocation` wird auch ausgeführt, wenn `LocationStock` nicht 1 ist; bei vielen Artikeln werden dabei Auftragspositionen und Lieferantenbestellungen aggregiert, was aufwendig sein kann. Das Ergebnis hängt von den Einstellungen `HalOrdersActiveDays` und `Include_FUT_StatusInOpenOrdersForSupplierOrdering` ab.\n- Ungültiges XML in `ItemXML` führt zu einem SQL-Fehler aus `sp_xml_preparedocument`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemStock"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert verfügbaren und physischen Bestand, Lieferantenpreis und offene Auftragspositionsmengen für einen oder mehrere Artikel, optional je Lager.\n\nSucht Artikel und liefert deren Bestandswerte.\n\n**Artikelidentifikation**\n- Leere Zeichenketten werden als `NULL` behandelt; `ItemKey = 0` gilt als `NULL`.\n- Mindestens einer der Parameter `ItemKey`, `EAN`, `ItemNrSuppl`, `ItemNrInt` oder `ItemXML` ist erforderlich, sonst wird eine Fehlerzeile geliefert.\n- Die Einzelparameter werden mit **ODER** gegen `pixi.ItemCode` verknüpft: `EAN` entspricht Codetyp 1 (Barcode), `ItemNrInt` Codetyp 2 (Shop-Artikelnr.), `ItemNrSuppl` Codetyp 4 (Lieferanten-Artikelnr.), `ItemKey` der Artikel-ID einer beliebigen Codezeile.\n- `ItemXML` ergänzt weitere Artikel: Jedes Element `/ITEMS/ITEM` kann `ITEMKEY` (direkt übernommen), `ITEMNRINT`, `ITEMNRSUPPL` oder `EAN` enthalten (Abgleich mit `items.ItemNrInt`, `items.ItemNrSuppl` und `items.EANUPC`).\n- Wird kein Kandidat gefunden, wird eine Fehlerzeile geliefert.\n\n**Bestandsberechnung** (je Artikel aus `items`)\n- `AvailableStock` = `ItemQtyIBIExportStock_locations` abzüglich – bei Nicht-Bundle-Artikeln und wenn die Einstellung `StockExportUsePhysicalStock` `0` ist –\n - `ItemQtyOpenOrderLines`, wenn Reservierungen (`ReservePrepaymentOrders`) deaktiviert sind oder `ExportAvailableStock_WhenReservationsAreEnabled` = 1 ist,\n - sonst `ItemQtyOpenReservations`, wenn Reservierungen aktiv sind,\n - andernfalls wird nichts abgezogen.\n- `PhysicalStock` = Bestand außerhalb von Sonderlagern, `PhysicalStockAllLocations` = inklusive Sonderlager.\n- `OnlyEnabledItems = 1` beschränkt die Ausgabe auf aktive Artikel.\n\n**Ausschluss von Lagerplatzgruppen**\nIst `ExcludeBinGroups` (kommagetrennte Liste) angegeben, werden die Mengen auf Lagerplätzen (`InvBin`/`InvBinItemLog`) dieser Gruppen je Artikel summiert und von `AvailableStock`, `PhysicalStock` und `PhysicalStockAllLocations` abgezogen. Für Bundles mit solchen Komponenten wird zusätzlich eine abgeleitete Menge (Minimum über die Komponenten aus ausgeschlossener Menge geteilt durch Komponentenmenge, aufgerundet) abgezogen.\n\n**Aufschlüsselung nach Lager**\nMit `LocationStock = 1` werden zwei zusätzliche Textspalten geliefert:\n- `Locations`: `All:; :; …` mit Gesamtmenge und Menge je Lager.\n- `OpenOrderlineSumLocations`: `:; …; All:;` mit offenen Kundenauftragsmengen (ANG/FUT sowie aktuelle HAL-Aufträge) je Lager und gesamt, berechnet durch `pixi.ItemInfoStockPerLocation`.\n\nJe gefundenem Artikel wird eine Zeile geliefert; eine explizite Sortierung erfolgt nicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel. `0` gilt als nicht gesetzt. |\n| `EAN` | varchar(50) | Nein | Barcode des Artikels (Codetyp 1). |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer (Codetyp 4). |\n| `ItemNrInt` | varchar(50) | Nein | Shop-Artikelnummer (Codetyp 2). |\n| `LocationStock` | bit | Nein | Bei 1 enthält das Ergebnis zusätzlich die Spalten `Locations` und `OpenOrderlineSumLocations` je Lager. |\n| `OnlyEnabledItems` | bit | Nein | Beschränkt das Ergebnis auf aktive Artikel. |\n| `ExcludeBinGroups` | varchar(max) | Nein | Kommagetrennte Liste von Lagerplatzgruppen, deren Mengen von den Bestandswerten abgezogen werden. |\n| `ItemXML` | varchar(max) | Nein | XML-Liste weiterer Artikel. Jedes Element `/ITEMS/ITEM` kann `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL` und `EAN` (max. 13 Zeichen) enthalten. |\n\n- Nur lesend; alle Tabellen werden `WITH (NOLOCK)` gelesen, Werte können daher nicht festgeschriebene Daten enthalten.\n- Bei Fehlern liefert die Prozedur zusätzlich zur Statuszeile den Rückgabewert `1`.\n- `ItemKey` als Einzelparameter trifft nur, wenn der Artikel mindestens eine Zeile in `pixi.ItemCode` besitzt. `ITEMKEY`-Werte aus `ItemXML` werden nicht geprüft; unbekannte Schlüssel gelten als gefunden, erzeugen aber keine Ausgabezeile, sodass das Ergebnis ohne Fehlerzeile leer sein kann.\n- Ein Artikel, der sowohl über Einzelparameter als auch über `ItemXML` gefunden wird, kann doppelt im Ergebnis erscheinen.\n- `EAN` in `ItemXML` wird als `varchar(13)` gelesen; längere Werte werden abgeschnitten.\n- Wird `OnlyEnabledItems` explizit als NULL übergeben, werden keine Zeilen geliefert.\n- Der Ausschluss von Lagerplatzgruppen wirkt nur auf Artikel mit Shop-Artikelnr. (Codetyp 2), deren `ItemNrInt` diesem Code entspricht.\n- Die Reihenfolge der Einträge in `Locations` und `OpenOrderlineSumLocations` ist nicht garantiert.\n- `pixi.ItemInfoStockPerLocation` wird auch ausgeführt, wenn `LocationStock` nicht 1 ist; bei vielen Artikeln werden dabei Auftragspositionen und Lieferantenbestellungen aggregiert, was aufwendig sein kann. Das Ergebnis hängt von den Einstellungen `HalOrdersActiveDays` und `Include_FUT_StatusInOpenOrdersForSupplierOrdering` ab.\n- Ungültiges XML in `ItemXML` führt zu einem SQL-Fehler aus `sp_xml_preparedocument`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemStock"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 18\n 25\n 27\n 12.5000\n 1234\n 4006381333931\n SUP-55012\n A-1001\n All:27; 001:20; 002:7; \n 7\n 001:5; 002:2; All:7; \n \n"
}
]
},
{
"name": "pixiGetItemStockBins",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Lagerplätze mit Mengen je Charge und MHD für einen oder mehrere Artikel, identifiziert über Key, EAN, Artikelnummern oder eine XML-Liste.\n\nErmittelt den Bestand je Lagerplatz für einen oder mehrere Artikel.\n\n**Normalisierung der Eingaben**\n- `ItemKey` = `0` wird als `NULL` behandelt.\n- Textparameter werden getrimmt; leere Zeichenketten gelten als `NULL`.\n- Ist danach kein Parameter gefüllt, wird eine Statuszeile mit `Status` = `Error` zurückgegeben.\n\n**Ermittlung der Artikel** (alle Kriterien werden mit ODER verknüpft, das Ergebnis ist die Vereinigung aller Treffer):\n- `EAN` wird gegen Artikelcodes vom Typ Barcode (Codetyp 1) in `ItemCode` geprüft.\n- `ItemNrInt` wird gegen Artikelcodes vom Typ Shop-Artikelnummer (Codetyp 2) geprüft.\n- `ItemNrSuppl` wird gegen Artikelcodes vom Typ Lieferanten-Artikelnummer (Codetyp 4) geprüft.\n- `ItemKey` wird gegen die Artikel-ID in `ItemCode` geprüft.\n- `ItemXML` (elementbasiertes XML, Pfad `/ITEMS/ITEM`) kann mehrere Artikel enthalten. Je `ITEM` wird `ITEMKEY` direkt übernommen, `ITEMNRINT`, `ITEMNRSUPPL` und `EAN` werden gegen die Spalten `ItemNrInt`, `ItemNrSuppl` und `EANUPC` der Tabelle `items` geprüft.\n\nWird kein Artikel gefunden, kommt die Statuszeile `No items found with given parameters.` zurück.\n\n**Ergebnis**\nJe gefundenem Artikel eine Zeile pro Lagerplatz, Chargennummer und Mindesthaltbarkeitsdatum mit der summierten Menge aus `InvBinItem`. Die Lagerplatzdaten (Name, Sortiernummer, Lager, Lagerplatzgruppe, Kennzeichen Transportlagerplatz) stammen aus `InvBin`. Sortierung nach `LocID` und danach nach `BinName` (ohne Beachtung der Groß-/Kleinschreibung). Gefundene Artikel ohne Lagerplatzbestand liefern keine Zeilen (leeres Ergebnis, kein Fehler).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikel-Key. `0` gilt als nicht gesetzt. Wird gegen die Artikel-ID in `ItemCode` geprüft. |\n| `EAN` | varchar(13) | Nein | Barcode/EAN des Artikels, geprüft gegen Artikelcodes vom Typ Barcode (Codetyp 1). |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer, geprüft gegen Artikelcodes vom Typ Lieferanten-Artikelnummer (Codetyp 4). |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer bzw. Shop-Artikelnummer, geprüft gegen Artikelcodes vom Typ Shop-Artikelnummer (Codetyp 2). |\n| `ItemXML` | varchar(max) | Nein | Optionale XML-Liste von Artikeln (`/ITEMS/ITEM`, elementbasiert). Je Artikel wird `ITEMKEY` direkt verwendet; `ITEMNRINT`, `ITEMNRSUPPL` und `EAN` werden gegen `items.ItemNrInt`, `items.ItemNrSuppl` und `items.EANUPC` geprüft. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Der Einzelparameter `ItemKey` wird über die Tabelle `ItemCode` gesucht, nicht über `items`. Ein Artikel ohne Eintrag in `ItemCode` wird über `ItemKey` nicht gefunden; alternativ `ItemXML` mit `ITEMKEY` verwenden, das direkt übernommen wird.\n- Der Einzelparameter `EAN` durchsucht alle Barcodes vom Typ 1 in `ItemCode`, während `EAN` im `ItemXML` nur gegen die Haupt-EAN (`items.EANUPC`) geprüft wird.\n- Wird derselbe Artikel sowohl über Einzelparameter als auch über `ItemXML` gefunden, steht er doppelt in der internen Kandidatenliste und `Quantity` wird doppelt summiert. Jeden Artikel daher nur auf einem Weg angeben.\n- Ein nicht existierender `ITEMKEY` im XML verhindert den Fehler \"No items found\", liefert aber keine Zeilen.\n- Die Elementnamen für OPENXML beachten die Groß-/Kleinschreibung (`ITEMS`, `ITEM`, `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL`, `EAN`).\n- `BestBeforeDate` wird als Text im Format `yyyy-mm-dd hh:mi:ss.mmm` geliefert; eine leere Zeichenkette bedeutet kein Datum. `BatchNumber` ist leer, wenn keine Charge gesetzt ist.\n- Im Fehlerfall gibt die Prozedur nach der Statuszeile den Rückgabewert 1 zurück.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemStockBins"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Lagerplätze mit Mengen je Charge und MHD für einen oder mehrere Artikel, identifiziert über Key, EAN, Artikelnummern oder eine XML-Liste.\n\nErmittelt den Bestand je Lagerplatz für einen oder mehrere Artikel.\n\n**Normalisierung der Eingaben**\n- `ItemKey` = `0` wird als `NULL` behandelt.\n- Textparameter werden getrimmt; leere Zeichenketten gelten als `NULL`.\n- Ist danach kein Parameter gefüllt, wird eine Statuszeile mit `Status` = `Error` zurückgegeben.\n\n**Ermittlung der Artikel** (alle Kriterien werden mit ODER verknüpft, das Ergebnis ist die Vereinigung aller Treffer):\n- `EAN` wird gegen Artikelcodes vom Typ Barcode (Codetyp 1) in `ItemCode` geprüft.\n- `ItemNrInt` wird gegen Artikelcodes vom Typ Shop-Artikelnummer (Codetyp 2) geprüft.\n- `ItemNrSuppl` wird gegen Artikelcodes vom Typ Lieferanten-Artikelnummer (Codetyp 4) geprüft.\n- `ItemKey` wird gegen die Artikel-ID in `ItemCode` geprüft.\n- `ItemXML` (elementbasiertes XML, Pfad `/ITEMS/ITEM`) kann mehrere Artikel enthalten. Je `ITEM` wird `ITEMKEY` direkt übernommen, `ITEMNRINT`, `ITEMNRSUPPL` und `EAN` werden gegen die Spalten `ItemNrInt`, `ItemNrSuppl` und `EANUPC` der Tabelle `items` geprüft.\n\nWird kein Artikel gefunden, kommt die Statuszeile `No items found with given parameters.` zurück.\n\n**Ergebnis**\nJe gefundenem Artikel eine Zeile pro Lagerplatz, Chargennummer und Mindesthaltbarkeitsdatum mit der summierten Menge aus `InvBinItem`. Die Lagerplatzdaten (Name, Sortiernummer, Lager, Lagerplatzgruppe, Kennzeichen Transportlagerplatz) stammen aus `InvBin`. Sortierung nach `LocID` und danach nach `BinName` (ohne Beachtung der Groß-/Kleinschreibung). Gefundene Artikel ohne Lagerplatzbestand liefern keine Zeilen (leeres Ergebnis, kein Fehler).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikel-Key. `0` gilt als nicht gesetzt. Wird gegen die Artikel-ID in `ItemCode` geprüft. |\n| `EAN` | varchar(13) | Nein | Barcode/EAN des Artikels, geprüft gegen Artikelcodes vom Typ Barcode (Codetyp 1). |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer, geprüft gegen Artikelcodes vom Typ Lieferanten-Artikelnummer (Codetyp 4). |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer bzw. Shop-Artikelnummer, geprüft gegen Artikelcodes vom Typ Shop-Artikelnummer (Codetyp 2). |\n| `ItemXML` | varchar(max) | Nein | Optionale XML-Liste von Artikeln (`/ITEMS/ITEM`, elementbasiert). Je Artikel wird `ITEMKEY` direkt verwendet; `ITEMNRINT`, `ITEMNRSUPPL` und `EAN` werden gegen `items.ItemNrInt`, `items.ItemNrSuppl` und `items.EANUPC` geprüft. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Der Einzelparameter `ItemKey` wird über die Tabelle `ItemCode` gesucht, nicht über `items`. Ein Artikel ohne Eintrag in `ItemCode` wird über `ItemKey` nicht gefunden; alternativ `ItemXML` mit `ITEMKEY` verwenden, das direkt übernommen wird.\n- Der Einzelparameter `EAN` durchsucht alle Barcodes vom Typ 1 in `ItemCode`, während `EAN` im `ItemXML` nur gegen die Haupt-EAN (`items.EANUPC`) geprüft wird.\n- Wird derselbe Artikel sowohl über Einzelparameter als auch über `ItemXML` gefunden, steht er doppelt in der internen Kandidatenliste und `Quantity` wird doppelt summiert. Jeden Artikel daher nur auf einem Weg angeben.\n- Ein nicht existierender `ITEMKEY` im XML verhindert den Fehler \"No items found\", liefert aber keine Zeilen.\n- Die Elementnamen für OPENXML beachten die Groß-/Kleinschreibung (`ITEMS`, `ITEM`, `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL`, `EAN`).\n- `BestBeforeDate` wird als Text im Format `yyyy-mm-dd hh:mi:ss.mmm` geliefert; eine leere Zeichenkette bedeutet kein Datum. `BatchNumber` ist leer, wenn keine Charge gesetzt ist.\n- Im Fehlerfall gibt die Prozedur nach der Statuszeile den Rückgabewert 1 zurück.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemStockBins"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n A-01-02\n 12\n 1020\n 4006381333931\n ART-1001\n 001\n CH2024-07\n 2025-06-30 00:00:00.000\n A\n false\n \n \n B-03-01\n 5\n 2010\n 4006381333931\n ART-1001\n 001\n \n \n B\n false\n \n"
}
]
},
{
"name": "pixiGetItemStockHistory",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Lagerplatz-Bestandshistorie eines Artikels, ermittelt über Artikelschlüssel, EAN, Lieferanten- oder interne Artikelnummer, mit Paging.\n\nLiefert das Bestandsbewegungsprotokoll eines Artikels je Lagerplatz, ähnlich der Lagerplatzhistorie im Pixi-Client.\n\n1. **Artikelsuche:** Der Artikel wird in `items` über die gefüllten Kennungen gesucht, die per **ODER** verknüpft sind: `ItemKey` (wenn nicht 0/NULL), `EANUPC` = `EAN`, `ItemNrSuppl` oder `ItemNrInt` (jeweils nur wenn nicht leer). Verwendet wird der erste Treffer (`TOP 1`, ohne Sortierung).\n2. Wird kein Artikel gefunden, kommt eine einzelne Statuszeile mit `Status` = `Error` zurück und der Aufruf endet.\n3. Andernfalls werden die Protokolleinträge des Artikels aus `InvBinItemLog` geladen, absteigend nach Protokollschlüssel (neueste zuerst) nummeriert, und die über `PageNumber` und `PageSize` bestimmte Seite wird ausgewählt.\n4. Der Lagerplatzname stammt aus dem aktuellen Lagerplatz (`InvBin`). Existiert der Lagerplatz nicht mehr, wird der Name aus der Lagerplatzhistorie (`InvBinHist`) samt Historienbemerkung genommen.\n5. Namen von Bestandsbewegungsvorgang und -typ werden in die über `LanguageID` angegebene Sprache übersetzt. `SMTName` besteht aus der Typnummer, einem Leerzeichen und dem übersetzten Typnamen.\n6. Einträge mit `UpdateEmp` = `AutoExport` werden nach dem Paging aus dem Ergebnis entfernt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. Wird bei NULL oder 0 ignoriert. |\n| `EAN` | varchar(13) | Nein | EAN/UPC des Artikels (Vergleich mit `EANUPC`). Wird ignoriert, wenn leer. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer. Wird ignoriert, wenn leer. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer. Wird ignoriert, wenn leer. |\n| `LanguageID` | int | Nein | Sprache für die Übersetzung der Namen von Bestandsbewegungsvorgängen und -typen. |\n| `PageSize` | int | Nein | Anzahl der Protokolleinträge pro Seite (vor dem Filter auf `AutoExport`). |\n| `PageNumber` | int | Nein | Zurückzugebende Seite, beginnend bei 1. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Werden mehrere Kennungen übergeben, sind sie per ODER verknüpft; es kann ein beliebiger passender Artikel gewählt werden. Für ein eindeutiges Ergebnis nur eine Kennung übergeben.\n- Der Filter auf `AutoExport` greift **nach** dem Paging, daher kann eine Seite weniger Zeilen als `PageSize` enthalten. `TotalPages` wird aus allen Protokolleinträgen berechnet, einschließlich der gefilterten.\n- `TotalPages` ergibt sich aus der ganzzahligen Division der Gesamtzeilen durch `PageSize` plus 1. Ist die Gesamtzahl ein exaktes Vielfaches von `PageSize`, wird eine zusätzliche (leere) Seite gemeldet.\n- Die abschließende Abfrage hat kein explizites `ORDER BY`. Die Zeilen kommen in der Regel, aber ohne Garantie, mit den neuesten zuerst.\n- `SMOName`/`SMTName` sind NULL, wenn für die angegebene `LanguageID` keine Übersetzung existiert.\n- Die Prozedur gibt den Rückgabewert 1 zurück, wenn kein Artikel gefunden wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemStockHistory"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Lagerplatz-Bestandshistorie eines Artikels, ermittelt über Artikelschlüssel, EAN, Lieferanten- oder interne Artikelnummer, mit Paging.\n\nLiefert das Bestandsbewegungsprotokoll eines Artikels je Lagerplatz, ähnlich der Lagerplatzhistorie im Pixi-Client.\n\n1. **Artikelsuche:** Der Artikel wird in `items` über die gefüllten Kennungen gesucht, die per **ODER** verknüpft sind: `ItemKey` (wenn nicht 0/NULL), `EANUPC` = `EAN`, `ItemNrSuppl` oder `ItemNrInt` (jeweils nur wenn nicht leer). Verwendet wird der erste Treffer (`TOP 1`, ohne Sortierung).\n2. Wird kein Artikel gefunden, kommt eine einzelne Statuszeile mit `Status` = `Error` zurück und der Aufruf endet.\n3. Andernfalls werden die Protokolleinträge des Artikels aus `InvBinItemLog` geladen, absteigend nach Protokollschlüssel (neueste zuerst) nummeriert, und die über `PageNumber` und `PageSize` bestimmte Seite wird ausgewählt.\n4. Der Lagerplatzname stammt aus dem aktuellen Lagerplatz (`InvBin`). Existiert der Lagerplatz nicht mehr, wird der Name aus der Lagerplatzhistorie (`InvBinHist`) samt Historienbemerkung genommen.\n5. Namen von Bestandsbewegungsvorgang und -typ werden in die über `LanguageID` angegebene Sprache übersetzt. `SMTName` besteht aus der Typnummer, einem Leerzeichen und dem übersetzten Typnamen.\n6. Einträge mit `UpdateEmp` = `AutoExport` werden nach dem Paging aus dem Ergebnis entfernt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. Wird bei NULL oder 0 ignoriert. |\n| `EAN` | varchar(13) | Nein | EAN/UPC des Artikels (Vergleich mit `EANUPC`). Wird ignoriert, wenn leer. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer. Wird ignoriert, wenn leer. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer. Wird ignoriert, wenn leer. |\n| `LanguageID` | int | Nein | Sprache für die Übersetzung der Namen von Bestandsbewegungsvorgängen und -typen. |\n| `PageSize` | int | Nein | Anzahl der Protokolleinträge pro Seite (vor dem Filter auf `AutoExport`). |\n| `PageNumber` | int | Nein | Zurückzugebende Seite, beginnend bei 1. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Werden mehrere Kennungen übergeben, sind sie per ODER verknüpft; es kann ein beliebiger passender Artikel gewählt werden. Für ein eindeutiges Ergebnis nur eine Kennung übergeben.\n- Der Filter auf `AutoExport` greift **nach** dem Paging, daher kann eine Seite weniger Zeilen als `PageSize` enthalten. `TotalPages` wird aus allen Protokolleinträgen berechnet, einschließlich der gefilterten.\n- `TotalPages` ergibt sich aus der ganzzahligen Division der Gesamtzeilen durch `PageSize` plus 1. Ist die Gesamtzahl ein exaktes Vielfaches von `PageSize`, wird eine zusätzliche (leere) Seite gemeldet.\n- Die abschließende Abfrage hat kein explizites `ORDER BY`. Die Zeilen kommen in der Regel, aber ohne Garantie, mit den neuesten zuerst.\n- `SMOName`/`SMTName` sind NULL, wenn für die angegebene `LanguageID` keine Übersetzung existiert.\n- Die Prozedur gibt den Rückgabewert 1 zurück, wenn kein Artikel gefunden wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemStockHistory"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 5\n mmueller\n 2024-03-12T10:15:22.000\n A-01-03\n 001\n 884512\n Picking\n Pick\n 2 Outgoing\n 1\n \n"
}
]
},
{
"name": "pixiGetItemStockOnForOrder2Store",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den physischen und verfügbaren Bestand von Artikeln je Lagerort sowie eine zusammengefasste Zeile 'All' je Artikel unter Berücksichtigung offener Aufträge bzw. Reservierungen.\n\nLiefert je Artikel und Lagerort (`ItemLocationSpecific` verknüpft mit `Location`) eine Zeile und zusätzlich, per `UNION` kombiniert, je Artikel eine Zeile mit `Location` = `All`.\n\n**Zur Laufzeit gelesene Einstellungen**\n- `HalOrdersActiveDays`: Anzahl Tage, die Auftragspositionen im Status `HAL` als offen gelten. Der Wert `0` wird durch `7` ersetzt.\n- `ReservePrepaymentOrders`: bei `1` wird die Verfügbarkeit aus Reservierungen berechnet, sonst aus offenen Auftragspositionen.\n\n**Zeilen je Lagerort**\n- `PhysicalQTY` ist die `LocationQuantity` des Artikels auf diesem Lagerort.\n- `OpenOrders` ist die Summe von `Qty` der Auftragspositionen des Artikels auf diesem Lagerort mit Status `ANG` oder Status `HAL` und einem `OrderDate` innerhalb der letzten `HalOrdersActiveDays` Tage.\n- `ReservedOrders` ist die Anzahl der Reservierungsdatensätze des Artikels, deren Auftragsposition auf diesem Lagerort liegt und einen nicht finalen Auftragsstatus außer `EIN`, `FUT`, `FUS` hat.\n- `AvailQTY` = `PhysicalQTY` abzüglich `ReservedOrders` (Reservierung aktiv) bzw. abzüglich `OpenOrders` (Reservierung inaktiv).\n- `SpecialStock` ist das Sonderbestand-Kennzeichen des Lagerorts.\n- Gefiltert nach `LocationId`, falls angegeben.\n\n**Zeilen 'All'**\n- `PhysicalQTY` ist der Gesamtbestand des Artikels (`Items.Quantity`).\n- `OpenOrders` und `ReservedOrders` werden wie oben, jedoch über alle Lagerorte berechnet.\n- `AvailQTY` = Gesamtbestand abzüglich des Bestands auf Sonderbestand-Lagerorten (`Location.SpecialStock = 1`) abzüglich `ReservedOrders` bzw. `OpenOrders` (je nach Einstellung).\n- `SpecialStock` ist immer `0`.\n- `LocationId` wird auf diese Zeilen **nicht** angewendet; sie werden für die ausgewählten Artikel immer geliefert.\n\n**Artikelauswahl**\nDie Artikelparameter `ItemKey`, `EAN`, `ItemNrSuppl` und `ItemNrInt` werden mit ODER verknüpft, und jede Bedingung ist erfüllt, wenn der jeweilige Parameter `NULL` ist. Folgen siehe Hinweise. Eine Sortierung ist nicht definiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel. Wirkt nur als Filter, wenn auch alle anderen Artikelparameter gesetzt sind (siehe Hinweise). |\n| `EAN` | varchar(13) | Nein | EAN/UPC des Artikels (`Items.EANUPC`). Mit den anderen Artikelparametern ODER-verknüpft. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer (`Items.ItemNrSuppl`). Mit den anderen Artikelparametern ODER-verknüpft. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer (`Items.ItemNrInt`). Mit den anderen Artikelparametern ODER-verknüpft. |\n| `LocationId` | varchar(50) | Nein | Beschränkt die Zeilen je Lagerort auf diese Lagerort-ID. `NULL` liefert alle Lagerorte. Wirkt nicht auf die Zeilen 'All'. |\n| `Quantity` | int | Nein | Ausgabeparameter, der im Code nie gesetzt wird; er wird unverändert zurückgegeben. |\n\n- **Filterfalle:** Da die vier Artikelbedingungen mit ODER verknüpft sind und jede bei `NULL` erfüllt ist, liefert das Weglassen *eines beliebigen* der Parameter `ItemKey`, `EAN`, `ItemNrSuppl`, `ItemNrInt` **alle Artikel**. Die Übergabe nur von `ItemKey` schränkt das Ergebnis daher nicht ein. Erst wenn alle vier Parameter gefüllt sind, werden die Artikel geliefert, die mindestens einem davon entsprechen.\n- Ohne Filter liefert der Aufruf Zeilen für jeden Artikel und Lagerort; das kann wegen der korrelierten Unterabfragen je Zeile sehr umfangreich und langsam sein.\n- Der Ausgabeparameter `Quantity` wird im Code nie gesetzt und unverändert zurückgegeben.\n- `ReservedOrders` zählt Reservierungsdatensätze, keine Mengen.\n- Existiert die Einstellung `HalOrdersActiveDays` nicht, ist das Stichtagsdatum `NULL` und Auftragspositionen im Status `HAL` werden nie als offen gezählt.\n- Ein Code-Kommentar nennt 14 Tage für `HAL`-Aufträge, der tatsächliche Zeitraum stammt jedoch aus `HalOrdersActiveDays` (7, falls auf 0 gesetzt).\n- Alle Tabellen werden mit `NOLOCK` gelesen; Werte können nicht festgeschriebene Daten enthalten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemStockOnForOrder2Store"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den physischen und verfügbaren Bestand von Artikeln je Lagerort sowie eine zusammengefasste Zeile 'All' je Artikel unter Berücksichtigung offener Aufträge bzw. Reservierungen.\n\nLiefert je Artikel und Lagerort (`ItemLocationSpecific` verknüpft mit `Location`) eine Zeile und zusätzlich, per `UNION` kombiniert, je Artikel eine Zeile mit `Location` = `All`.\n\n**Zur Laufzeit gelesene Einstellungen**\n- `HalOrdersActiveDays`: Anzahl Tage, die Auftragspositionen im Status `HAL` als offen gelten. Der Wert `0` wird durch `7` ersetzt.\n- `ReservePrepaymentOrders`: bei `1` wird die Verfügbarkeit aus Reservierungen berechnet, sonst aus offenen Auftragspositionen.\n\n**Zeilen je Lagerort**\n- `PhysicalQTY` ist die `LocationQuantity` des Artikels auf diesem Lagerort.\n- `OpenOrders` ist die Summe von `Qty` der Auftragspositionen des Artikels auf diesem Lagerort mit Status `ANG` oder Status `HAL` und einem `OrderDate` innerhalb der letzten `HalOrdersActiveDays` Tage.\n- `ReservedOrders` ist die Anzahl der Reservierungsdatensätze des Artikels, deren Auftragsposition auf diesem Lagerort liegt und einen nicht finalen Auftragsstatus außer `EIN`, `FUT`, `FUS` hat.\n- `AvailQTY` = `PhysicalQTY` abzüglich `ReservedOrders` (Reservierung aktiv) bzw. abzüglich `OpenOrders` (Reservierung inaktiv).\n- `SpecialStock` ist das Sonderbestand-Kennzeichen des Lagerorts.\n- Gefiltert nach `LocationId`, falls angegeben.\n\n**Zeilen 'All'**\n- `PhysicalQTY` ist der Gesamtbestand des Artikels (`Items.Quantity`).\n- `OpenOrders` und `ReservedOrders` werden wie oben, jedoch über alle Lagerorte berechnet.\n- `AvailQTY` = Gesamtbestand abzüglich des Bestands auf Sonderbestand-Lagerorten (`Location.SpecialStock = 1`) abzüglich `ReservedOrders` bzw. `OpenOrders` (je nach Einstellung).\n- `SpecialStock` ist immer `0`.\n- `LocationId` wird auf diese Zeilen **nicht** angewendet; sie werden für die ausgewählten Artikel immer geliefert.\n\n**Artikelauswahl**\nDie Artikelparameter `ItemKey`, `EAN`, `ItemNrSuppl` und `ItemNrInt` werden mit ODER verknüpft, und jede Bedingung ist erfüllt, wenn der jeweilige Parameter `NULL` ist. Folgen siehe Hinweise. Eine Sortierung ist nicht definiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel. Wirkt nur als Filter, wenn auch alle anderen Artikelparameter gesetzt sind (siehe Hinweise). |\n| `EAN` | varchar(13) | Nein | EAN/UPC des Artikels (`Items.EANUPC`). Mit den anderen Artikelparametern ODER-verknüpft. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer (`Items.ItemNrSuppl`). Mit den anderen Artikelparametern ODER-verknüpft. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer (`Items.ItemNrInt`). Mit den anderen Artikelparametern ODER-verknüpft. |\n| `LocationId` | varchar(50) | Nein | Beschränkt die Zeilen je Lagerort auf diese Lagerort-ID. `NULL` liefert alle Lagerorte. Wirkt nicht auf die Zeilen 'All'. |\n| `Quantity` | int | Nein | Ausgabeparameter, der im Code nie gesetzt wird; er wird unverändert zurückgegeben. |\n\n- **Filterfalle:** Da die vier Artikelbedingungen mit ODER verknüpft sind und jede bei `NULL` erfüllt ist, liefert das Weglassen *eines beliebigen* der Parameter `ItemKey`, `EAN`, `ItemNrSuppl`, `ItemNrInt` **alle Artikel**. Die Übergabe nur von `ItemKey` schränkt das Ergebnis daher nicht ein. Erst wenn alle vier Parameter gefüllt sind, werden die Artikel geliefert, die mindestens einem davon entsprechen.\n- Ohne Filter liefert der Aufruf Zeilen für jeden Artikel und Lagerort; das kann wegen der korrelierten Unterabfragen je Zeile sehr umfangreich und langsam sein.\n- Der Ausgabeparameter `Quantity` wird im Code nie gesetzt und unverändert zurückgegeben.\n- `ReservedOrders` zählt Reservierungsdatensätze, keine Mengen.\n- Existiert die Einstellung `HalOrdersActiveDays` nicht, ist das Stichtagsdatum `NULL` und Auftragspositionen im Status `HAL` werden nie als offen gezählt.\n- Ein Code-Kommentar nennt 14 Tage für `HAL`-Aufträge, der tatsächliche Zeitraum stammt jedoch aus `HalOrdersActiveDays` (7, falls auf 0 gesetzt).\n- Alle Tabellen werden mit `NOLOCK` gelesen; Werte können nicht festgeschriebene Daten enthalten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemStockOnForOrder2Store"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 001\n 12345\n 20\n 3\n 0\n 17\n 0\n \n \n All\n 12345\n 25\n 4\n 0\n 16\n 0\n \n"
}
]
},
{
"name": "pixiGetItemStockOnLocations",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den physischen Bestand eines Artikels je Lagerplatz sowie eine Summenzeile 'All' mit physischem, verfügbarem und real verfügbarem Bestand.\n\nLiefert Bestandszahlen für **einen Artikel**, entweder auf allen Lagerplätzen oder auf einem einzelnen Lagerplatz.\n\n1. **Artikelsuche**: Ist `ItemKey` angegeben, wird dieser direkt verwendet. Andernfalls wird der Artikel in `pixi.ItemCode` über `EAN`, `ItemNrSuppl` oder `ItemNrInt` gesucht. Ein Code passt, wenn er einem der drei Werte entspricht und den Codetyp 1, 2 oder 4 hat. Der erste Treffer wird verwendet (`TOP 1`).\n2. **Summenzeile**: Aus `items` wird eine Zeile mit `Location` = `All` gebildet:\n - `PhysicalQTY` = Artikelbestand\n - `AvailQTY` = Bestand minus Sonderbestand (`ItemQtyIBISpecialStock_1`) minus offene Reservierungen\n - `RealQtyAvail` = Bestand minus Sonderbestand minus offene Auftragspositionen\n - `SpecialStock` = 0\n3. **Lagerplatzzeilen**: Für jeden Eintrag in `ItemLocationSpecific` des Artikels wird eine Zeile mit der Lagerplatz-ID, dem Lagerplatzbestand als `PhysicalQTY` und dem `SpecialStock`-Kennzeichen des Lagerplatzes geliefert. Ist `LocationId` gesetzt (nicht leer), wird nur der Lagerplatz mit dieser `LocID` geliefert.\n4. Lagerplatzzeilen und Summenzeile werden per `UNION` zusammengeführt; identische Zeilen werden dabei entfernt.\n\nDie Zeile `All` ist immer Teil des Ergebnisses, sofern der Artikel existiert, auch wenn `LocationId` gesetzt ist. Wird kein Artikel gefunden, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. Ist er gesetzt, werden die Code-Parameter ignoriert. |\n| `EAN` | varchar(13) | Nein | EAN zur Artikelsuche, wenn `ItemKey` nicht gesetzt ist. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer zur Artikelsuche, wenn `ItemKey` nicht gesetzt ist. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer zur Artikelsuche, wenn `ItemKey` nicht gesetzt ist. |\n| `LocationId` | varchar(50) | Nein | Lagerplatz-ID (`LocID`), auf die die Lagerplatzzeilen eingeschränkt werden. Leer oder NULL liefert alle Lagerplätze des Artikels. Die Zeile `All` wird in jedem Fall geliefert. |\n| `Quantity` | int | Nein | Ausgabeparameter, der von der Prozedur nie gesetzt wird; er liefert den übergebenen Wert zurück. |\n\n- `AvailQTY` und `RealQtyAvail` sind **Werte auf Artikelebene**; sie werden unverändert in jeder Lagerplatzzeile wiederholt und nicht je Lagerplatz berechnet.\n- Der Ausgabeparameter `Quantity` wird von der Prozedur nie gesetzt; er liefert nur den übergebenen Wert zurück (Standard `NULL`).\n- Die Artikelsuche über Codes verwendet `TOP 1` ohne `ORDER BY`. Teilen sich mehrere Artikel einen Code, ist nicht festgelegt, welcher Artikel verwendet wird. Die Bedeutung der Codetypen 1, 2 und 4 ist im Code nicht definiert.\n- Kein `ORDER BY` im Ergebnis: Die Reihenfolge der Zeilen (auch die Position der Zeile `All`) ist nicht garantiert.\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können geliefert werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemStockOnLocations"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den physischen Bestand eines Artikels je Lagerplatz sowie eine Summenzeile 'All' mit physischem, verfügbarem und real verfügbarem Bestand.\n\nLiefert Bestandszahlen für **einen Artikel**, entweder auf allen Lagerplätzen oder auf einem einzelnen Lagerplatz.\n\n1. **Artikelsuche**: Ist `ItemKey` angegeben, wird dieser direkt verwendet. Andernfalls wird der Artikel in `pixi.ItemCode` über `EAN`, `ItemNrSuppl` oder `ItemNrInt` gesucht. Ein Code passt, wenn er einem der drei Werte entspricht und den Codetyp 1, 2 oder 4 hat. Der erste Treffer wird verwendet (`TOP 1`).\n2. **Summenzeile**: Aus `items` wird eine Zeile mit `Location` = `All` gebildet:\n - `PhysicalQTY` = Artikelbestand\n - `AvailQTY` = Bestand minus Sonderbestand (`ItemQtyIBISpecialStock_1`) minus offene Reservierungen\n - `RealQtyAvail` = Bestand minus Sonderbestand minus offene Auftragspositionen\n - `SpecialStock` = 0\n3. **Lagerplatzzeilen**: Für jeden Eintrag in `ItemLocationSpecific` des Artikels wird eine Zeile mit der Lagerplatz-ID, dem Lagerplatzbestand als `PhysicalQTY` und dem `SpecialStock`-Kennzeichen des Lagerplatzes geliefert. Ist `LocationId` gesetzt (nicht leer), wird nur der Lagerplatz mit dieser `LocID` geliefert.\n4. Lagerplatzzeilen und Summenzeile werden per `UNION` zusammengeführt; identische Zeilen werden dabei entfernt.\n\nDie Zeile `All` ist immer Teil des Ergebnisses, sofern der Artikel existiert, auch wenn `LocationId` gesetzt ist. Wird kein Artikel gefunden, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. Ist er gesetzt, werden die Code-Parameter ignoriert. |\n| `EAN` | varchar(13) | Nein | EAN zur Artikelsuche, wenn `ItemKey` nicht gesetzt ist. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferanten-Artikelnummer zur Artikelsuche, wenn `ItemKey` nicht gesetzt ist. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer zur Artikelsuche, wenn `ItemKey` nicht gesetzt ist. |\n| `LocationId` | varchar(50) | Nein | Lagerplatz-ID (`LocID`), auf die die Lagerplatzzeilen eingeschränkt werden. Leer oder NULL liefert alle Lagerplätze des Artikels. Die Zeile `All` wird in jedem Fall geliefert. |\n| `Quantity` | int | Nein | Ausgabeparameter, der von der Prozedur nie gesetzt wird; er liefert den übergebenen Wert zurück. |\n\n- `AvailQTY` und `RealQtyAvail` sind **Werte auf Artikelebene**; sie werden unverändert in jeder Lagerplatzzeile wiederholt und nicht je Lagerplatz berechnet.\n- Der Ausgabeparameter `Quantity` wird von der Prozedur nie gesetzt; er liefert nur den übergebenen Wert zurück (Standard `NULL`).\n- Die Artikelsuche über Codes verwendet `TOP 1` ohne `ORDER BY`. Teilen sich mehrere Artikel einen Code, ist nicht festgelegt, welcher Artikel verwendet wird. Die Bedeutung der Codetypen 1, 2 und 4 ist im Code nicht definiert.\n- Kein `ORDER BY` im Ergebnis: Die Reihenfolge der Zeilen (auch die Position der Zeile `All`) ist nicht garantiert.\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können geliefert werden.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemStockOnLocations"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n A-01-02\n 4711\n 12\n 15\n 13\n false\n \n \n All\n 4711\n 20\n 15\n 13\n false\n \n"
}
]
},
{
"name": "pixiGetLocations",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Stammdaten der Lager, entweder aller sichtbaren Lager oder eines einzelnen Lagers anhand seiner ID.\n\nLiefert pro Lager eine Zeile aus der Tabelle `Location`. Jede Zeile enthält die Adressdaten, das Versandkennzeichen, die Reservierungs- und Umlagerungseinstellungen sowie ein Kennzeichen, ob das Lager als Kassen-Lager (POS) verwendet wird.\n\nFilterung:\n\n- Ist `LocID` nicht angegeben, `NULL` oder leer, werden alle Lager mit `ShowLocation <> 0` (sichtbare Lager) geliefert.\n- Ist `LocID` gesetzt, wird nur das Lager mit dieser ID geliefert. Der Filter auf `ShowLocation` greift in diesem Fall **nicht**, ausgeblendete Lager werden also ebenfalls geliefert.\n\n`IsPosLocation` ist `'1'`, wenn mindestens ein Datensatz in `POSheader2` über `PHlocID` auf das Lager verweist, sonst `'0'`.\n\nDie Abfrage hat kein `ORDER BY`, die Reihenfolge der Zeilen ist daher nicht garantiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | Nein | ID des Lagers, das geliefert werden soll. Leer oder `NULL` liefert alle sichtbaren Lager. |\n\n- `Location` wird mit `NOLOCK` gelesen, nicht festgeschriebene Änderungen können daher im Ergebnis erscheinen. Die Unterabfrage auf `POSheader2` verwendet keinen Sperrhinweis.\n- Da in der `WHERE`-Klausel `AND` stärker bindet als `OR`, greift der Sichtbarkeitsfilter `ShowLocation <> 0` nur, wenn keine `LocID` übergeben wird. Die Abfrage eines einzelnen ausgeblendeten Lagers liefert dieses Lager trotzdem.\n- Eine unbekannte `LocID` liefert ein leeres Ergebnis. Es wird kein Fehler ausgelöst.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetLocations"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Stammdaten der Lager, entweder aller sichtbaren Lager oder eines einzelnen Lagers anhand seiner ID.\n\nLiefert pro Lager eine Zeile aus der Tabelle `Location`. Jede Zeile enthält die Adressdaten, das Versandkennzeichen, die Reservierungs- und Umlagerungseinstellungen sowie ein Kennzeichen, ob das Lager als Kassen-Lager (POS) verwendet wird.\n\nFilterung:\n\n- Ist `LocID` nicht angegeben, `NULL` oder leer, werden alle Lager mit `ShowLocation <> 0` (sichtbare Lager) geliefert.\n- Ist `LocID` gesetzt, wird nur das Lager mit dieser ID geliefert. Der Filter auf `ShowLocation` greift in diesem Fall **nicht**, ausgeblendete Lager werden also ebenfalls geliefert.\n\n`IsPosLocation` ist `'1'`, wenn mindestens ein Datensatz in `POSheader2` über `PHlocID` auf das Lager verweist, sonst `'0'`.\n\nDie Abfrage hat kein `ORDER BY`, die Reihenfolge der Zeilen ist daher nicht garantiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | Nein | ID des Lagers, das geliefert werden soll. Leer oder `NULL` liefert alle sichtbaren Lager. |\n\n- `Location` wird mit `NOLOCK` gelesen, nicht festgeschriebene Änderungen können daher im Ergebnis erscheinen. Die Unterabfrage auf `POSheader2` verwendet keinen Sperrhinweis.\n- Da in der `WHERE`-Klausel `AND` stärker bindet als `OR`, greift der Sichtbarkeitsfilter `ShowLocation <> 0` nur, wenn keine `LocID` übergeben wird. Die Abfrage eines einzelnen ausgeblendeten Lagers liefert dieses Lager trotzdem.\n- Eine unbekannte `LocID` liefert ein leeres Ergebnis. Es wird kein Fehler ausgelöst.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetLocations"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 001\n MAIN\n Zentrallager\n Industriestr. 5\n München\n 80331\n DE\n BY\n Muster GmbH\n 1\n 0\n 001\n 002\n 14\n 0\n \n"
}
]
},
{
"name": "pixiGetMinStockChanges",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, deren aus den letzten Verkäufen errechneter empfohlener Mindestbestand bzw. Mindestbestellmenge um mindestens einen Anteil vom aktuellen Wert abweicht.\n\nBerechnet pro Artikel Dispositionsempfehlungen für einen Lagerort und liefert nur Artikel mit einer deutlichen Abweichung. Das Ergebnis wird sortiert und seitenweise ausgegeben.\n\n**Normalisierung der Eingaben**\n- `0` bei `HistoryDays`, `SecurityDays`, `ShowChangesAbovePercentage` und `Rows` wird durch den Standardwert ersetzt. `ConfigtypeKey` = `0` und leere Zeichenketten bei den Text- und XML-Parametern gelten als `NULL`.\n- Ist `Location` leer, wird der erste Lagerort mit `ShowLocation = 1` verwendet.\n- `SortColumn` und `SortDirection` werden in Kleinbuchstaben umgewandelt.\n\n**Verkaufsquelle (`Pos` / `Shops`)**\n- Nur `Shops` gesetzt: nur Verkäufe aus Auftragspositionen.\n- Nur `Pos` gesetzt: nur abgeschlossene POS-Belege.\n- Beide oder keiner gesetzt: Auftragspositionen plus POS-Verkäufe.\nDer Inhalt von `Pos` wird nie ausgewertet. `Shops` wird zwar geparst, die Shopliste filtert die Daten aber nicht.\n\n**Artikelfilter**\nDie Filter werden in dieser Reihenfolge angewendet und bilden eine Liste von Artikelschlüsseln:\n1. `Categories` (`/CATS/CAT/CatId`, über `TontrArten` auf `items.ConfigType` abgebildet).\n2. `Suppliers` (`/SUPPLIERS/SUP/SupplNr`), Schnittmenge mit der bisherigen Liste.\n3. `Tags` (`/TAGS/TAG` mit `TAGKEY` und `TAGTYPE`): `a` = Artikel muss alle diese Tags haben, `o` = mindestens einen, `n` = Artikel darf den Tag nicht haben. Passende Artikel werden der Liste hinzugefügt.\n4. `ConfigtypeKey` (aktive Artikel mit diesem `ConfigType`), Schnittmenge mit der Liste, falls diese nicht leer ist.\n5. `SupplNR`, Schnittmenge mit der Liste, falls diese nicht leer ist.\n\nAnschließend werden deaktivierte Artikel entfernt. Ohne Filter werden alle aktiven Artikel ausgewertet.\n\n**Berechnung pro Artikel**\n- `MinStockQty` / `MinOrderQty`: aktuelle Werte aus `ItemLocationSpecific` für `Location`.\n- `Quantity`: Summe von `LocationQuantity` über die Lagerorte in `Locations` (Standard: alle Lagerorte mit `ShowLocation = 1`).\n- `DailyQty`: verkaufte Menge der letzten `HistoryDays` Tage am `Location` (Auftragspositionen mit Status `AUS`, POS-Belege mit Status `CLO`) geteilt durch `HistoryDays`. `DailyQtyBefore`: dasselbe für den gleich langen Vorzeitraum. `Trend` ist `+`, `-` oder ein Leerzeichen.\n- `RecommendedMinStockQty` = FLOOR(`DailyQty` × (Liefertage + `SecurityDays`)); ohne Liefertage beim Lieferanten werden 7 Tage angenommen.\n- `RecommendedMinOrderQty` = FLOOR(`DailyQty` × `DesiredStockTurnOver`); ein Ergebnis von 1 wird zu 0. Negative Empfehlungen werden als 0 ausgegeben.\n- `ChangeMinStockQty` / `ChangeMinOrderQty`: relative Änderung (Empfehlung − aktuell) / aktuell; ist der aktuelle Wert 0 und eine Empfehlung vorhanden, 1.\n- `StockTurnover` = FLOOR(`Quantity` / `DailyQty`), 0 ohne Verkäufe.\n- `NumOfOrders`: Anzahl unterschiedlicher Aufträge / POS-Belege im Zeitraum über die `Locations`-Liste.\n\n**Auswahl, Sortierung und Paging**\nNur Artikel mit ABS(`ChangeMinStockQty`) oder ABS(`ChangeMinOrderQty`) ≥ `ShowChangesAbovePercentage` bleiben übrig. Sie werden nach `SortColumn` / `SortDirection` und danach nach `ItemName` aufsteigend nummeriert (`RowNr`). Ausgegeben werden Zeilen mit `RowNr` > `Start`, `RowNr` ≤ `Start` + `Rows` und `ItemKey` > `ItemKeyStart`, zusammen mit `TotalRows` (alle passenden Artikel) und `NrOfRecordsLeft` (Zeilen nach `Start` mit `ItemKey` > `ItemKeyStart`).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `HistoryDays` | int | Nein | Länge des Verkaufszeitraums in Tagen zur Berechnung der Tagesmenge. Der gleich lange Vorzeitraum wird für `DailyQtyBefore` verwendet. `0` bedeutet Standardwert. |\n| `SecurityDays` | int | Nein | Sicherheitstage, die bei der Berechnung des empfohlenen Mindestbestands zu den Liefertagen des Lieferanten addiert werden. `0` bedeutet Standardwert. |\n| `DesiredStockTurnOver` | int | Nein | Anzahl Verkaufstage, die eine Bestellung abdecken soll; Grundlage der empfohlenen Mindestbestellmenge. |\n| `ShowChangesAbovePercentage` | float | Nein | Minimale relative Änderung (z. B. `0.1` = 10 %) von Mindestbestand oder Mindestbestellmenge, ab der ein Artikel geliefert wird. `0` bedeutet Standardwert. |\n| `SupplNR` | varchar(4) | Nein | Beschränkt das Ergebnis auf Artikel dieser Lieferantennummer. |\n| `Rows` | int | Nein | Seitengröße: maximale Anzahl gelieferter Zeilen. `0` bedeutet Standardwert. |\n| `ItemKeyStart` | int | Nein | Es werden nur Zeilen mit `ItemKey` größer als dieser Wert geliefert. |\n| `ConfigtypeKey` | int | Nein | Beschränkt das Ergebnis auf Artikel mit diesem `ConfigType`. `0` gilt als `NULL`. |\n| `Tags` | varchar(max) | Nein | XML-Liste von Tag-Filtern `/TAGS/TAG` mit `TAGKEY` und `TAGTYPE` (`a` = alle erforderlich, `o` = mindestens einer, `n` = darf nicht vorhanden sein). |\n| `SortColumn` | varchar(50) | Nein | Spalte für Sortierung und `RowNr`. Groß-/Kleinschreibung wird ignoriert. Unbekannte Werte sortieren nach `ItemName`. |\n| `SortDirection` | varchar(1) | Nein | Sortierrichtung. Groß-/Kleinschreibung wird ignoriert. |\n| `Start` | int | Nein | Paging-Offset: Es werden Zeilen mit `RowNr` größer als dieser Wert geliefert. |\n| `Suppliers` | varchar(max) | Nein | XML-Liste von Lieferantennummern `/SUPPLIERS/SUP/SupplNr`; nur Artikel dieser Lieferanten werden ausgewertet. |\n| `Categories` | varchar(max) | Nein | XML-Liste von Kategorieschlüsseln `/CATS/CAT/CatId` (`TontrArtKey`); nur Artikel mit passendem `ConfigType` werden ausgewertet. |\n| `Locations` | varchar(max) | Nein | XML-Liste von Lagerort-IDs `/LOCATIONS/LOC/LocationID` für `Quantity` und `NumOfOrders`. Standard: alle Lagerorte mit `ShowLocation = 1`. |\n| `Shops` | varchar(max) | Nein | XML-Liste `/SHOPS/SHOP/ShopID`. Nur das Vorhandensein zählt: Zusammen mit `Pos` bestimmt es die Verkaufsquelle (siehe Beschreibung). Die Shop-IDs filtern die Daten nicht. |\n| `Pos` | varchar(max) | Nein | Kennzeichen für POS-Verkäufe: Jeder nicht leere Wert gilt als gesetzt; der Inhalt wird nicht gelesen. Zusammen mit `Shops` bestimmt es die Verkaufsquelle. |\n| `Location` | varchar(max) | Nein | Lagerort-ID für die aktuellen Mindestwerte und die Verkaufszahlen. Standard: erster Lagerort mit `ShowLocation = 1`. |\n\n- Nur lesend; alle permanenten Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten erscheinen. Pro Artikel werden mehrere Aggregate über `Orderlines` und `POSitem2`/`POSheader2` berechnet; bei großen Datenbeständen kann der Aufruf langsam sein, Filter verwenden.\n- **Fehler im Code:** Im Standardmodus (Auftragspositionen plus POS) ist `ChangeMinOrderQty` immer `NULL`, da der Code den Nur-POS-Fall doppelt prüft. Dann entscheidet nur `ChangeMinStockQty`, ob ein Artikel geliefert wird.\n- Artikel ohne `ItemLocationSpecific`-Zeile für `Location` oder ohne Zeile in der `Locations`-Liste werden nicht geliefert.\n- Der Vorzeitraum schließt den Tag genau `HistoryDays` Tage zurück aus.\n- `Tags` fügt Artikel zur Liste hinzu, statt die Schnittmenge mit `Categories`/`Suppliers` zu bilden. Ein Filter nur mit `n`-Tags liefert keine Artikel, sobald irgendein Artikel einen dieser Tags trägt.\n- Treffen `Categories` oder `Suppliers` keinen Artikel und sind weder `Tags`, `ConfigtypeKey` noch `SupplNR` angegeben, wird der Filter ignoriert und alle aktiven Artikel werden ausgewertet.\n- `SortColumn` wird in Kleinbuchstaben umgewandelt und mit Namen in gemischter Schreibweise verglichen; die Sortierung funktioniert nur bei einer Datenbank-Collation ohne Unterscheidung der Groß-/Kleinschreibung. Unbekannte Werte sortieren nach `ItemName`.\n- `DesiredStockTurnOver` = `0` wird nicht durch den Standardwert ersetzt und führt zu empfohlenen Bestellmengen von 0.\n- Ungültiges XML in den XML-Parametern führt zu einem SQL-Fehler aus `sp_xml_preparedocument`.\n- Zum Übernehmen einer Empfehlung dient `pixiSetItemBuyingInfo`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetMinStockChanges"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Artikel, deren aus den letzten Verkäufen errechneter empfohlener Mindestbestand bzw. Mindestbestellmenge um mindestens einen Anteil vom aktuellen Wert abweicht.\n\nBerechnet pro Artikel Dispositionsempfehlungen für einen Lagerort und liefert nur Artikel mit einer deutlichen Abweichung. Das Ergebnis wird sortiert und seitenweise ausgegeben.\n\n**Normalisierung der Eingaben**\n- `0` bei `HistoryDays`, `SecurityDays`, `ShowChangesAbovePercentage` und `Rows` wird durch den Standardwert ersetzt. `ConfigtypeKey` = `0` und leere Zeichenketten bei den Text- und XML-Parametern gelten als `NULL`.\n- Ist `Location` leer, wird der erste Lagerort mit `ShowLocation = 1` verwendet.\n- `SortColumn` und `SortDirection` werden in Kleinbuchstaben umgewandelt.\n\n**Verkaufsquelle (`Pos` / `Shops`)**\n- Nur `Shops` gesetzt: nur Verkäufe aus Auftragspositionen.\n- Nur `Pos` gesetzt: nur abgeschlossene POS-Belege.\n- Beide oder keiner gesetzt: Auftragspositionen plus POS-Verkäufe.\nDer Inhalt von `Pos` wird nie ausgewertet. `Shops` wird zwar geparst, die Shopliste filtert die Daten aber nicht.\n\n**Artikelfilter**\nDie Filter werden in dieser Reihenfolge angewendet und bilden eine Liste von Artikelschlüsseln:\n1. `Categories` (`/CATS/CAT/CatId`, über `TontrArten` auf `items.ConfigType` abgebildet).\n2. `Suppliers` (`/SUPPLIERS/SUP/SupplNr`), Schnittmenge mit der bisherigen Liste.\n3. `Tags` (`/TAGS/TAG` mit `TAGKEY` und `TAGTYPE`): `a` = Artikel muss alle diese Tags haben, `o` = mindestens einen, `n` = Artikel darf den Tag nicht haben. Passende Artikel werden der Liste hinzugefügt.\n4. `ConfigtypeKey` (aktive Artikel mit diesem `ConfigType`), Schnittmenge mit der Liste, falls diese nicht leer ist.\n5. `SupplNR`, Schnittmenge mit der Liste, falls diese nicht leer ist.\n\nAnschließend werden deaktivierte Artikel entfernt. Ohne Filter werden alle aktiven Artikel ausgewertet.\n\n**Berechnung pro Artikel**\n- `MinStockQty` / `MinOrderQty`: aktuelle Werte aus `ItemLocationSpecific` für `Location`.\n- `Quantity`: Summe von `LocationQuantity` über die Lagerorte in `Locations` (Standard: alle Lagerorte mit `ShowLocation = 1`).\n- `DailyQty`: verkaufte Menge der letzten `HistoryDays` Tage am `Location` (Auftragspositionen mit Status `AUS`, POS-Belege mit Status `CLO`) geteilt durch `HistoryDays`. `DailyQtyBefore`: dasselbe für den gleich langen Vorzeitraum. `Trend` ist `+`, `-` oder ein Leerzeichen.\n- `RecommendedMinStockQty` = FLOOR(`DailyQty` × (Liefertage + `SecurityDays`)); ohne Liefertage beim Lieferanten werden 7 Tage angenommen.\n- `RecommendedMinOrderQty` = FLOOR(`DailyQty` × `DesiredStockTurnOver`); ein Ergebnis von 1 wird zu 0. Negative Empfehlungen werden als 0 ausgegeben.\n- `ChangeMinStockQty` / `ChangeMinOrderQty`: relative Änderung (Empfehlung − aktuell) / aktuell; ist der aktuelle Wert 0 und eine Empfehlung vorhanden, 1.\n- `StockTurnover` = FLOOR(`Quantity` / `DailyQty`), 0 ohne Verkäufe.\n- `NumOfOrders`: Anzahl unterschiedlicher Aufträge / POS-Belege im Zeitraum über die `Locations`-Liste.\n\n**Auswahl, Sortierung und Paging**\nNur Artikel mit ABS(`ChangeMinStockQty`) oder ABS(`ChangeMinOrderQty`) ≥ `ShowChangesAbovePercentage` bleiben übrig. Sie werden nach `SortColumn` / `SortDirection` und danach nach `ItemName` aufsteigend nummeriert (`RowNr`). Ausgegeben werden Zeilen mit `RowNr` > `Start`, `RowNr` ≤ `Start` + `Rows` und `ItemKey` > `ItemKeyStart`, zusammen mit `TotalRows` (alle passenden Artikel) und `NrOfRecordsLeft` (Zeilen nach `Start` mit `ItemKey` > `ItemKeyStart`).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `HistoryDays` | int | Nein | Länge des Verkaufszeitraums in Tagen zur Berechnung der Tagesmenge. Der gleich lange Vorzeitraum wird für `DailyQtyBefore` verwendet. `0` bedeutet Standardwert. |\n| `SecurityDays` | int | Nein | Sicherheitstage, die bei der Berechnung des empfohlenen Mindestbestands zu den Liefertagen des Lieferanten addiert werden. `0` bedeutet Standardwert. |\n| `DesiredStockTurnOver` | int | Nein | Anzahl Verkaufstage, die eine Bestellung abdecken soll; Grundlage der empfohlenen Mindestbestellmenge. |\n| `ShowChangesAbovePercentage` | float | Nein | Minimale relative Änderung (z. B. `0.1` = 10 %) von Mindestbestand oder Mindestbestellmenge, ab der ein Artikel geliefert wird. `0` bedeutet Standardwert. |\n| `SupplNR` | varchar(4) | Nein | Beschränkt das Ergebnis auf Artikel dieser Lieferantennummer. |\n| `Rows` | int | Nein | Seitengröße: maximale Anzahl gelieferter Zeilen. `0` bedeutet Standardwert. |\n| `ItemKeyStart` | int | Nein | Es werden nur Zeilen mit `ItemKey` größer als dieser Wert geliefert. |\n| `ConfigtypeKey` | int | Nein | Beschränkt das Ergebnis auf Artikel mit diesem `ConfigType`. `0` gilt als `NULL`. |\n| `Tags` | varchar(max) | Nein | XML-Liste von Tag-Filtern `/TAGS/TAG` mit `TAGKEY` und `TAGTYPE` (`a` = alle erforderlich, `o` = mindestens einer, `n` = darf nicht vorhanden sein). |\n| `SortColumn` | varchar(50) | Nein | Spalte für Sortierung und `RowNr`. Groß-/Kleinschreibung wird ignoriert. Unbekannte Werte sortieren nach `ItemName`. |\n| `SortDirection` | varchar(1) | Nein | Sortierrichtung. Groß-/Kleinschreibung wird ignoriert. |\n| `Start` | int | Nein | Paging-Offset: Es werden Zeilen mit `RowNr` größer als dieser Wert geliefert. |\n| `Suppliers` | varchar(max) | Nein | XML-Liste von Lieferantennummern `/SUPPLIERS/SUP/SupplNr`; nur Artikel dieser Lieferanten werden ausgewertet. |\n| `Categories` | varchar(max) | Nein | XML-Liste von Kategorieschlüsseln `/CATS/CAT/CatId` (`TontrArtKey`); nur Artikel mit passendem `ConfigType` werden ausgewertet. |\n| `Locations` | varchar(max) | Nein | XML-Liste von Lagerort-IDs `/LOCATIONS/LOC/LocationID` für `Quantity` und `NumOfOrders`. Standard: alle Lagerorte mit `ShowLocation = 1`. |\n| `Shops` | varchar(max) | Nein | XML-Liste `/SHOPS/SHOP/ShopID`. Nur das Vorhandensein zählt: Zusammen mit `Pos` bestimmt es die Verkaufsquelle (siehe Beschreibung). Die Shop-IDs filtern die Daten nicht. |\n| `Pos` | varchar(max) | Nein | Kennzeichen für POS-Verkäufe: Jeder nicht leere Wert gilt als gesetzt; der Inhalt wird nicht gelesen. Zusammen mit `Shops` bestimmt es die Verkaufsquelle. |\n| `Location` | varchar(max) | Nein | Lagerort-ID für die aktuellen Mindestwerte und die Verkaufszahlen. Standard: erster Lagerort mit `ShowLocation = 1`. |\n\n- Nur lesend; alle permanenten Tabellen werden `WITH (NOLOCK)` gelesen, daher können nicht festgeschriebene Daten erscheinen. Pro Artikel werden mehrere Aggregate über `Orderlines` und `POSitem2`/`POSheader2` berechnet; bei großen Datenbeständen kann der Aufruf langsam sein, Filter verwenden.\n- **Fehler im Code:** Im Standardmodus (Auftragspositionen plus POS) ist `ChangeMinOrderQty` immer `NULL`, da der Code den Nur-POS-Fall doppelt prüft. Dann entscheidet nur `ChangeMinStockQty`, ob ein Artikel geliefert wird.\n- Artikel ohne `ItemLocationSpecific`-Zeile für `Location` oder ohne Zeile in der `Locations`-Liste werden nicht geliefert.\n- Der Vorzeitraum schließt den Tag genau `HistoryDays` Tage zurück aus.\n- `Tags` fügt Artikel zur Liste hinzu, statt die Schnittmenge mit `Categories`/`Suppliers` zu bilden. Ein Filter nur mit `n`-Tags liefert keine Artikel, sobald irgendein Artikel einen dieser Tags trägt.\n- Treffen `Categories` oder `Suppliers` keinen Artikel und sind weder `Tags`, `ConfigtypeKey` noch `SupplNR` angegeben, wird der Filter ignoriert und alle aktiven Artikel werden ausgewertet.\n- `SortColumn` wird in Kleinbuchstaben umgewandelt und mit Namen in gemischter Schreibweise verglichen; die Sortierung funktioniert nur bei einer Datenbank-Collation ohne Unterscheidung der Groß-/Kleinschreibung. Unbekannte Werte sortieren nach `ItemName`.\n- `DesiredStockTurnOver` = `0` wird nicht durch den Standardwert ersetzt und führt zu empfohlenen Bestellmengen von 0.\n- Ungültiges XML in den XML-Parametern führt zu einem SQL-Fehler aus `sp_xml_preparedocument`.\n- Zum Übernehmen einer Empfehlung dient `pixiSetItemBuyingInfo`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetMinStockChanges"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1052\n 4006381333931\n Kugelschreiber blau\n 2.50000000000000\n 1.80000000000000\n +\n 20\n 35\n 50\n 75\n 0.750000000000\n 48\n 19\n LIE1\n Bürobedarf GmbH\n 7\n 312\n 1\n 27\n 27\n \n"
}
]
},
{
"name": "pixiGetPhysicalItemStock",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n 001\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den physischen Bestand eines Artikels an einem Lager, wobei der Artikel über ItemKey, EAN, Lieferanten-Artikelnummer oder interne Artikelnummer bestimmt wird.\n\nSkalarfunktion, die einen einzelnen Ganzzahlwert liefert: den Wert von `LocationQuantity` aus den lagerspezifischen Artikeldaten für das angegebene Lager.\n\nAblauf:\n\n1. Die Artikelkennungen werden normalisiert: `ItemKey` = `0` sowie leere Zeichenketten für `EAN`, `ItemNrSuppl` und `ItemNrInt` gelten als nicht gesetzt (`NULL`).\n2. Lagerspezifische Artikeldatensätze (`ItemLocationSpecific`) werden mit den Artikelstammdaten (`Items`) verknüpft und auf `LocID` = `LocationId` gefiltert.\n3. Ein Datensatz passt, wenn **eine** der übergebenen Kennungen übereinstimmt: `ItemKey`, `EANUPC` = `EAN`, `ItemNrSuppl` oder `ItemNrInt`. Die Kennungen werden mit ODER verknüpft, nicht mit UND.\n4. Der `LocationQuantity`-Wert des passenden Datensatzes wird als `Result` zurückgegeben.\n\nWird kein passender Datensatz gefunden oder keine Kennung übergeben, ist das Ergebnis `NULL`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. `0` gilt als nicht gesetzt. |\n| `EAN` | varchar(13) | Nein | EAN/UPC des Artikels, verglichen mit `EANUPC`. Leere Zeichenkette gilt als nicht gesetzt. |\n| `ItemNrSuppl` | varchar(50) | Nein | Artikelnummer des Lieferanten. Leere Zeichenkette gilt als nicht gesetzt. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer. Leere Zeichenkette gilt als nicht gesetzt. |\n| `LocationId` | char(50) | Ja | Lager-ID, verglichen mit `LocID` der lagerspezifischen Artikeldaten. |\n\n- Liest mit `NOLOCK`; der Wert kann nicht festgeschriebene Änderungen enthalten.\n- Da die Kennungen mit ODER verknüpft werden, können mehrere übergebene Kennungen, die zu unterschiedlichen Artikeln gehören, mehrere Datensätze treffen. Dann wird der Bestand eines dieser Datensätze geliefert, welcher genau, ist nicht definiert (keine Sortierung). Für ein eindeutiges Ergebnis nur eine Kennung übergeben, idealerweise `ItemKey`.\n- `EAN`, `ItemNrSuppl` oder `ItemNrInt` sind ggf. nicht eindeutig über alle Artikel; dann besteht dieselbe Mehrdeutigkeit.\n- `LocationId` hat keinen Standardwert und muss immer übergeben werden.\n- Die Funktion liefert nur den gespeicherten `LocationQuantity`-Wert; Reservierungen oder offene Aufträge werden nicht abgezogen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPhysicalItemStock"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n 001\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den physischen Bestand eines Artikels an einem Lager, wobei der Artikel über ItemKey, EAN, Lieferanten-Artikelnummer oder interne Artikelnummer bestimmt wird.\n\nSkalarfunktion, die einen einzelnen Ganzzahlwert liefert: den Wert von `LocationQuantity` aus den lagerspezifischen Artikeldaten für das angegebene Lager.\n\nAblauf:\n\n1. Die Artikelkennungen werden normalisiert: `ItemKey` = `0` sowie leere Zeichenketten für `EAN`, `ItemNrSuppl` und `ItemNrInt` gelten als nicht gesetzt (`NULL`).\n2. Lagerspezifische Artikeldatensätze (`ItemLocationSpecific`) werden mit den Artikelstammdaten (`Items`) verknüpft und auf `LocID` = `LocationId` gefiltert.\n3. Ein Datensatz passt, wenn **eine** der übergebenen Kennungen übereinstimmt: `ItemKey`, `EANUPC` = `EAN`, `ItemNrSuppl` oder `ItemNrInt`. Die Kennungen werden mit ODER verknüpft, nicht mit UND.\n4. Der `LocationQuantity`-Wert des passenden Datensatzes wird als `Result` zurückgegeben.\n\nWird kein passender Datensatz gefunden oder keine Kennung übergeben, ist das Ergebnis `NULL`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels. `0` gilt als nicht gesetzt. |\n| `EAN` | varchar(13) | Nein | EAN/UPC des Artikels, verglichen mit `EANUPC`. Leere Zeichenkette gilt als nicht gesetzt. |\n| `ItemNrSuppl` | varchar(50) | Nein | Artikelnummer des Lieferanten. Leere Zeichenkette gilt als nicht gesetzt. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer. Leere Zeichenkette gilt als nicht gesetzt. |\n| `LocationId` | char(50) | Ja | Lager-ID, verglichen mit `LocID` der lagerspezifischen Artikeldaten. |\n\n- Liest mit `NOLOCK`; der Wert kann nicht festgeschriebene Änderungen enthalten.\n- Da die Kennungen mit ODER verknüpft werden, können mehrere übergebene Kennungen, die zu unterschiedlichen Artikeln gehören, mehrere Datensätze treffen. Dann wird der Bestand eines dieser Datensätze geliefert, welcher genau, ist nicht definiert (keine Sortierung). Für ein eindeutiges Ergebnis nur eine Kennung übergeben, idealerweise `ItemKey`.\n- `EAN`, `ItemNrSuppl` oder `ItemNrInt` sind ggf. nicht eindeutig über alle Artikel; dann besteht dieselbe Mehrdeutigkeit.\n- `LocationId` hat keinen Standardwert und muss immer übergeben werden.\n- Die Funktion liefert nur den gespeicherten `LocationQuantity`-Wert; Reservierungen oder offene Aufträge werden nicht abgezogen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPhysicalItemStock"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 42\n \n"
}
]
},
{
"name": "pixiGetPickListDetailForPico",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 48213\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Positionen einer fertig erzeugten Pickliste inklusive ihrer Split-Picklisten mit Lagerplatz-, Artikel-, Charge- und Auftragsdaten für die Pico-App.\n\nLiefert eine Zeile je Pickposition der Pickliste `PLHkey`. Der Aufruf übergibt den Schlüssel an eine interne Prozedur, `Pixi_GetPickListDetailForPico`, und ändert deren Standardfilter nicht.\n\n**Welche Picklisten enthalten sind**\n- Der Picklistenkopf mit `PLHkey` = `@PLHkey`.\n- Alle Split-Picklisten mit `PLHOriginalKey` = `@PLHkey`.\n- Nur Köpfe mit `ExecutionFinished = 1`.\n- Köpfe mit beliebigem Pickstatus.\n\n**Wie die Zeilen gebildet werden**\n- Die Picklistenpositionen (`PLitem`) werden zu einer Zeile je Kombination zusammengefasst aus:\n - Picklistenkopf, Auftragsposition und Lagerplatz (`InvBinItem.BinRef`);\n - Charge und Mindesthaltbarkeitsdatum;\n - Artikel (`BinItemRef`) und `pliBinRef`.\n- `Qty` ist die Anzahl der Picklistenpositionen in der Gruppe; jeder Datensatz steht für ein Stück.\n- `MinPlItemKey` ist der kleinste `PLIkey` der Gruppe.\n- Jede Zeile wird ergänzt um Daten aus:\n - dem Lagerplatz: Name, Sortiernummer, Lagerplatzgruppe;\n - dem Picklistenkopf: Ablaufdatum, Erstellungsdatum und -mitarbeiter, Kommentar, Kistenbereich, Pickstatus-Code, Originalschlüssel;\n - der Auftragsposition: Auftragsnummer und externe Auftragsnummer;\n - dem Artikel: Namen, Nummern, Bildlinks, Hersteller (`items.Artist`), Tags und Verpackungseinheit.\n\n**Berechnete Spalten**\n- `ItemName` ist der Artikelname mit einer vorangestellten Artikelnummer in Großbuchstaben und einem Leerzeichen. Die Einstellung `PickListNumberColumn` bestimmt die Nummer: `EANUPC`, `ItemNrInt` oder `ItemNrSuppl`. Bei einem anderen Wert oder ohne Einstellung entfällt das Präfix.\n- `OtherItemsCount` zählt die `InvBinItem`-Datensätze desselben Lagerplatzes, die zu einem anderen Artikel gehören.\n- `DistinctBins` ist die Anzahl unterschiedlicher Lagerplätze über alle Zeilen des Ergebnisses. Der Wert ist in jeder Zeile gleich.\n- `ItemTags` listet die Tag-Namen des Artikels. Jeder Name endet mit einem Komma, die Namen sind durch Leerzeichen getrennt, z. B. `Fragile, Heavy,`.\n- `BestBeforeDate_Text` ist das Mindesthaltbarkeitsdatum im Format `dd.mm.yyyy`.\n- `OrderUnit` ist `items.OrderUnit` als Ganzzahl. Der Wert ist `NULL`, wenn er leer oder nicht numerisch ist.\n\n**Vertauschte Artikelnummer-Spalten**\n- `ItemNrInt` enthält die **Lieferanten-Artikelnummer** (`ItemNrSuppl`). Das dient der Abwärtskompatibilität.\n- `ItemNrInt1` enthält die **interne Artikelnummer**.\n\nExistiert die Pickliste nicht oder ist sie nicht fertig erzeugt, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PLHkey` | int | Ja | Schlüssel des Picklistenkopfes (`PLHeader.PLHkey`). Daraus entstandene Split-Picklisten werden einbezogen. |\n\n- **Reihenfolge nicht garantiert:** Die interne Prozedur sortiert nach `BinGroup`, `BinSortNum`, `BinItemRef` absteigend und danach nach dem Erstellungsdatum des Kopfes. Ihre Zeilen werden in einer temporären Tabelle zwischengespeichert, und das abschließende `SELECT` hat kein `ORDER BY`. Die gelieferte Reihenfolge ist daher nicht garantiert. Bei Bedarf clientseitig sortieren.\n- **Nur lesend:** Alle Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können erscheinen.\n- **Laufzeit-Einstellung:** Das Präfix in `ItemName` hängt von der Einstellung `PickListNumberColumn` ab. Sie wird über `fpixi_GetSetting` gelesen, dessen Definition nicht beiliegt.\n- **Spaltenreihenfolge:** `OrderUnit` ist als letzte Spalte angehängt, damit positionsbasiert lesende Clients nicht betroffen sind.\n- **Kürzungsrisiko:** Die temporäre Zwischentabelle begrenzt einige Spalten, z. B. `EanUpc` auf 13 und `ItemNrSuppl` auf 50 Zeichen. Längere Quellwerte können zu einem Kürzungsfehler führen.\n- **Weitere Filter nicht verfügbar:** Der interne Pickstatus-Filter und die Option zum Ausschluss von Split-Picklisten sind über diesen Aufruf nicht nutzbar.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPickListDetailForPico"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 48213\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Positionen einer fertig erzeugten Pickliste inklusive ihrer Split-Picklisten mit Lagerplatz-, Artikel-, Charge- und Auftragsdaten für die Pico-App.\n\nLiefert eine Zeile je Pickposition der Pickliste `PLHkey`. Der Aufruf übergibt den Schlüssel an eine interne Prozedur, `Pixi_GetPickListDetailForPico`, und ändert deren Standardfilter nicht.\n\n**Welche Picklisten enthalten sind**\n- Der Picklistenkopf mit `PLHkey` = `@PLHkey`.\n- Alle Split-Picklisten mit `PLHOriginalKey` = `@PLHkey`.\n- Nur Köpfe mit `ExecutionFinished = 1`.\n- Köpfe mit beliebigem Pickstatus.\n\n**Wie die Zeilen gebildet werden**\n- Die Picklistenpositionen (`PLitem`) werden zu einer Zeile je Kombination zusammengefasst aus:\n - Picklistenkopf, Auftragsposition und Lagerplatz (`InvBinItem.BinRef`);\n - Charge und Mindesthaltbarkeitsdatum;\n - Artikel (`BinItemRef`) und `pliBinRef`.\n- `Qty` ist die Anzahl der Picklistenpositionen in der Gruppe; jeder Datensatz steht für ein Stück.\n- `MinPlItemKey` ist der kleinste `PLIkey` der Gruppe.\n- Jede Zeile wird ergänzt um Daten aus:\n - dem Lagerplatz: Name, Sortiernummer, Lagerplatzgruppe;\n - dem Picklistenkopf: Ablaufdatum, Erstellungsdatum und -mitarbeiter, Kommentar, Kistenbereich, Pickstatus-Code, Originalschlüssel;\n - der Auftragsposition: Auftragsnummer und externe Auftragsnummer;\n - dem Artikel: Namen, Nummern, Bildlinks, Hersteller (`items.Artist`), Tags und Verpackungseinheit.\n\n**Berechnete Spalten**\n- `ItemName` ist der Artikelname mit einer vorangestellten Artikelnummer in Großbuchstaben und einem Leerzeichen. Die Einstellung `PickListNumberColumn` bestimmt die Nummer: `EANUPC`, `ItemNrInt` oder `ItemNrSuppl`. Bei einem anderen Wert oder ohne Einstellung entfällt das Präfix.\n- `OtherItemsCount` zählt die `InvBinItem`-Datensätze desselben Lagerplatzes, die zu einem anderen Artikel gehören.\n- `DistinctBins` ist die Anzahl unterschiedlicher Lagerplätze über alle Zeilen des Ergebnisses. Der Wert ist in jeder Zeile gleich.\n- `ItemTags` listet die Tag-Namen des Artikels. Jeder Name endet mit einem Komma, die Namen sind durch Leerzeichen getrennt, z. B. `Fragile, Heavy,`.\n- `BestBeforeDate_Text` ist das Mindesthaltbarkeitsdatum im Format `dd.mm.yyyy`.\n- `OrderUnit` ist `items.OrderUnit` als Ganzzahl. Der Wert ist `NULL`, wenn er leer oder nicht numerisch ist.\n\n**Vertauschte Artikelnummer-Spalten**\n- `ItemNrInt` enthält die **Lieferanten-Artikelnummer** (`ItemNrSuppl`). Das dient der Abwärtskompatibilität.\n- `ItemNrInt1` enthält die **interne Artikelnummer**.\n\nExistiert die Pickliste nicht oder ist sie nicht fertig erzeugt, ist die Ergebnismenge leer.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PLHkey` | int | Ja | Schlüssel des Picklistenkopfes (`PLHeader.PLHkey`). Daraus entstandene Split-Picklisten werden einbezogen. |\n\n- **Reihenfolge nicht garantiert:** Die interne Prozedur sortiert nach `BinGroup`, `BinSortNum`, `BinItemRef` absteigend und danach nach dem Erstellungsdatum des Kopfes. Ihre Zeilen werden in einer temporären Tabelle zwischengespeichert, und das abschließende `SELECT` hat kein `ORDER BY`. Die gelieferte Reihenfolge ist daher nicht garantiert. Bei Bedarf clientseitig sortieren.\n- **Nur lesend:** Alle Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können erscheinen.\n- **Laufzeit-Einstellung:** Das Präfix in `ItemName` hängt von der Einstellung `PickListNumberColumn` ab. Sie wird über `fpixi_GetSetting` gelesen, dessen Definition nicht beiliegt.\n- **Spaltenreihenfolge:** `OrderUnit` ist als letzte Spalte angehängt, damit positionsbasiert lesende Clients nicht betroffen sind.\n- **Kürzungsrisiko:** Die temporäre Zwischentabelle begrenzt einige Spalten, z. B. `EanUpc` auf 13 und `ItemNrSuppl` auf 50 Zeichen. Längere Quellwerte können zu einem Kürzungsfehler führen.\n- **Weitere Filter nicht verfügbar:** Der interne Pickstatus-Filter und die Option zum Ausschluss von Split-Picklisten sind über diesen Aufruf nicht nutzbar.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetPickListDetailForPico"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10234\n 48213\n 120\n Coffee Mug Blue\n A-01-03\n 5521\n 2024-05-15T18:00:00\n 2024-05-14T08:12:00\n JD\n 2\n Express\n 4006381333931 Coffee Mug Blue\n SUP-7781\n 4006381333931\n MUG-BL-01\n 5521\n A\n 998877\n 1\n 20\n https://shop.example.com/img/mug_l.jpg\n https://shop.example.com/img/mug_s.jpg\n B2024-03\n 31.12.2025\n 2025-12-31T00:00:00\n 345678\n SHOP-100234\n 3\n 7\n Fragile,\n OPEN\n Acme\n 7712345\n 48213\n 6\n \n"
}
]
},
{
"name": "pixiGetRelocations",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Umlagerungen von Artikeln zwischen Lagern (Auslagerung und Einlagerung) aus dem Lagerplatz-Artikel-Log für einen Zeitraum von höchstens 31 Tagen, mit Paging.\n\nLiefert die Lagerbewegungen, die beim Umlagern von Artikeln von einem Lager in ein anderes entstehen.\n\n1. **Standardwerte und Bereinigung**: Ist `ChangeDateFrom` leer, wird der Beginn des aktuellen Monats (00:00) verwendet; ist `ChangeDateTo` leer, das Ende des aktuellen Tages (23:59:59.997). `FromLocation` und `ToLocation` werden getrimmt; leere Zeichenketten gelten als \"kein Filter\".\n2. **Prüfung**: Liegen zwischen `ChangeDateFrom` und `ChangeDateTo` mehr als 31 Tage (gezählt als Tagesgrenzen), wird eine einzelne Statuszeile mit `Status` = `Error` zurückgegeben und der Aufruf beendet.\n3. **Kandidaten**: Aus dem Lagerplatz-Artikel-Log werden alle Einträge mit `UpdateDate` im Zeitraum in zwei Gruppen gelesen:\n - Auslagerungen (`SMTRef` = 19, `SMORef` = 11),\n - Einlagerungen (`SMTRef` = 11, `SMORef` = 12).\n Jede Gruppe wird getrennt in der Reihenfolge des Log-Schlüssels nummeriert.\n4. **Zuordnung**: Der n-te Auslagerungseintrag wird mit dem n-ten Einlagerungseintrag verknüpft. Zurückgegeben werden nur Paare, bei denen ein Einlagerungseintrag existiert und der Artikel des Auslagerungseintrags im Artikelstamm vorhanden ist. `FromLocation` ist das Lager des Auslagerungseintrags, `ToLocation` das Lager des Einlagerungseintrags.\n5. **Lagerfilter**: `FromLocation` filtert auf das Quelllager, `ToLocation` auf das Ziellager; beide sind kombinierbar.\n6. **Paging**: Die verbleibenden Zeilen werden erneut (in Reihenfolge des Log-Schlüssels) in `RowNumber` nummeriert. Zurückgegeben werden höchstens `RowCount` Zeilen mit `RowNumber` > `Offset`, sortiert nach `RowNumber`.\n\n`Qty` ist die Menge des Auslagerungseintrags multipliziert mit -1, also die umgelagerte Menge als positive Zahl.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromLocation` | varchar(3) | Nein | Quelllager (Lager-ID des Auslagerungseintrags). Leer oder NULL bedeutet alle Quelllager. |\n| `ToLocation` | varchar(3) | Nein | Ziellager (Lager-ID des Einlagerungseintrags). Leer oder NULL bedeutet alle Ziellager. |\n| `ChangeDateFrom` | datetime | Nein | Beginn des Zeitraums (inklusive) auf `UpdateDate`. NULL bedeutet Beginn des aktuellen Monats. |\n| `ChangeDateTo` | datetime | Nein | Ende des Zeitraums (inklusive) auf `UpdateDate`. NULL bedeutet Ende des aktuellen Tages. Der Zeitraum darf 31 Tage nicht überschreiten. |\n| `Offset` | int | Nein | Anzahl zu überspringender Zeilen; zurückgegeben werden Zeilen mit `RowNumber` größer als dieser Wert. |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen. |\n\n- Aus- und Einlagerungseinträge werden **nur über die Position** verknüpft (n-te Auslagerung mit n-ter Einlagerung in Reihenfolge des Log-Schlüssels), nicht über Artikel oder Umlagerungsbeleg. Weicht die Anzahl der Aus- und Einlagerungen im Zeitraum voneinander ab oder liegt eine Umlagerung über der Zeitraumgrenze, können Paare verschoben sein und `ToLocation` zu einer anderen Bewegung gehören.\n- Die Bedeutung der Codes `SMTRef`/`SMORef` (19/11 und 11/12) ist im Code nicht dokumentiert; die Deutung als Aus-/Einlagerung stammt aus den Namen der temporären Tabellen.\n- Wird `ChangeDateTo` als Datum ohne Uhrzeit übergeben, gilt Mitternacht zu Beginn dieses Tages; spätere Bewegungen dieses Tages fehlen dann.\n- Alle Lesezugriffe verwenden `NOLOCK`, nicht festgeschriebene Daten können daher erscheinen.\n- Die Hilfsprozeduren `util.IndexCreate` und `util.TempTableDrop` werden nur für temporäre Tabellen genutzt; ihre Definitionen liegen nicht vor.\n- `RowNumber` wird nach den Lagerfiltern berechnet, Paging über `Offset` ist daher bei gleichen Filterwerten konsistent.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetRelocations"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Umlagerungen von Artikeln zwischen Lagern (Auslagerung und Einlagerung) aus dem Lagerplatz-Artikel-Log für einen Zeitraum von höchstens 31 Tagen, mit Paging.\n\nLiefert die Lagerbewegungen, die beim Umlagern von Artikeln von einem Lager in ein anderes entstehen.\n\n1. **Standardwerte und Bereinigung**: Ist `ChangeDateFrom` leer, wird der Beginn des aktuellen Monats (00:00) verwendet; ist `ChangeDateTo` leer, das Ende des aktuellen Tages (23:59:59.997). `FromLocation` und `ToLocation` werden getrimmt; leere Zeichenketten gelten als \"kein Filter\".\n2. **Prüfung**: Liegen zwischen `ChangeDateFrom` und `ChangeDateTo` mehr als 31 Tage (gezählt als Tagesgrenzen), wird eine einzelne Statuszeile mit `Status` = `Error` zurückgegeben und der Aufruf beendet.\n3. **Kandidaten**: Aus dem Lagerplatz-Artikel-Log werden alle Einträge mit `UpdateDate` im Zeitraum in zwei Gruppen gelesen:\n - Auslagerungen (`SMTRef` = 19, `SMORef` = 11),\n - Einlagerungen (`SMTRef` = 11, `SMORef` = 12).\n Jede Gruppe wird getrennt in der Reihenfolge des Log-Schlüssels nummeriert.\n4. **Zuordnung**: Der n-te Auslagerungseintrag wird mit dem n-ten Einlagerungseintrag verknüpft. Zurückgegeben werden nur Paare, bei denen ein Einlagerungseintrag existiert und der Artikel des Auslagerungseintrags im Artikelstamm vorhanden ist. `FromLocation` ist das Lager des Auslagerungseintrags, `ToLocation` das Lager des Einlagerungseintrags.\n5. **Lagerfilter**: `FromLocation` filtert auf das Quelllager, `ToLocation` auf das Ziellager; beide sind kombinierbar.\n6. **Paging**: Die verbleibenden Zeilen werden erneut (in Reihenfolge des Log-Schlüssels) in `RowNumber` nummeriert. Zurückgegeben werden höchstens `RowCount` Zeilen mit `RowNumber` > `Offset`, sortiert nach `RowNumber`.\n\n`Qty` ist die Menge des Auslagerungseintrags multipliziert mit -1, also die umgelagerte Menge als positive Zahl.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromLocation` | varchar(3) | Nein | Quelllager (Lager-ID des Auslagerungseintrags). Leer oder NULL bedeutet alle Quelllager. |\n| `ToLocation` | varchar(3) | Nein | Ziellager (Lager-ID des Einlagerungseintrags). Leer oder NULL bedeutet alle Ziellager. |\n| `ChangeDateFrom` | datetime | Nein | Beginn des Zeitraums (inklusive) auf `UpdateDate`. NULL bedeutet Beginn des aktuellen Monats. |\n| `ChangeDateTo` | datetime | Nein | Ende des Zeitraums (inklusive) auf `UpdateDate`. NULL bedeutet Ende des aktuellen Tages. Der Zeitraum darf 31 Tage nicht überschreiten. |\n| `Offset` | int | Nein | Anzahl zu überspringender Zeilen; zurückgegeben werden Zeilen mit `RowNumber` größer als dieser Wert. |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen. |\n\n- Aus- und Einlagerungseinträge werden **nur über die Position** verknüpft (n-te Auslagerung mit n-ter Einlagerung in Reihenfolge des Log-Schlüssels), nicht über Artikel oder Umlagerungsbeleg. Weicht die Anzahl der Aus- und Einlagerungen im Zeitraum voneinander ab oder liegt eine Umlagerung über der Zeitraumgrenze, können Paare verschoben sein und `ToLocation` zu einer anderen Bewegung gehören.\n- Die Bedeutung der Codes `SMTRef`/`SMORef` (19/11 und 11/12) ist im Code nicht dokumentiert; die Deutung als Aus-/Einlagerung stammt aus den Namen der temporären Tabellen.\n- Wird `ChangeDateTo` als Datum ohne Uhrzeit übergeben, gilt Mitternacht zu Beginn dieses Tages; spätere Bewegungen dieses Tages fehlen dann.\n- Alle Lesezugriffe verwenden `NOLOCK`, nicht festgeschriebene Daten können daher erscheinen.\n- Die Hilfsprozeduren `util.IndexCreate` und `util.TempTableDrop` werden nur für temporäre Tabellen genutzt; ihre Definitionen liegen nicht vor.\n- `RowNumber` wird nach den Lagerfiltern berechnet, Paging über `Offset` ist daher bei gleichen Filterwerten konsistent.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetRelocations"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 10452\n 2024-05-03T10:15:22.473\n 4006381333931\n Ballpoint pen blue\n 001\n 002\n 25\n \n \n 2\n 10987\n 2024-05-03T11:02:05.110\n 4006381333948\n Notebook A5\n 001\n 003\n 10\n \n"
}
]
},
{
"name": "pixiGetStockBins",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Lagerplätze, optional gefiltert nach Lager und Lagerplatzgruppe, mit der Gesamtmenge je Lagerplatz und optionalem Paging.\n\nLiest die Lagerplätze aus `InvBin` und berechnet je Lagerplatz die Summe von `BinItemQTY` aller Einträge in `InvBinItem` auf diesem Lagerplatz (`NrOfItemOnBin`, 0 bei leerem Lagerplatz).\n\nFilter:\n- `LocID`: nur Lagerplätze dieses Lagers (`BinLocID`). Leerer String oder NULL bedeutet alle Lager.\n- `BinGroup`: nur Lagerplätze dieser Lagerplatzgruppe. Leerer String oder NULL bedeutet alle Gruppen.\n\nPaging:\n- Ist `RowCount` 0 oder NULL, werden alle passenden Lagerplätze ohne Spalte `RowNr` geliefert.\n- Ist `RowCount` größer als 0, werden die Zeilen nach `BinSortNum` nummeriert (`RowNr`), und es werden höchstens `RowCount` Zeilen mit `RowNr` größer als `Start` geliefert. `Start` ist also die Anzahl der zu überspringenden Zeilen.\n\nDas Ergebnis ist immer nach `BinSortNum` und danach `BinKey` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | Nein | Lager-ID als Filter. NULL oder leerer String liefert Lagerplätze aller Lager. |\n| `RowCount` | int | Nein | Maximale Anzahl Zeilen pro Seite. 0 oder NULL deaktiviert das Paging und liefert alle Zeilen. |\n| `Start` | int | Nein | Anzahl zu überspringender Zeilen bei aktivem Paging; geliefert werden Zeilen mit `RowNr` größer als dieser Wert. Wird ignoriert, wenn `RowCount` 0 ist. |\n| `BinGroup` | varchar(20) | Nein | Lagerplatzgruppe als Filter. NULL oder leerer String liefert Lagerplätze aller Gruppen. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, das Ergebnis kann also nicht festgeschriebene Daten enthalten.\n- Die Nummerierung für das Paging sortiert nur nach `BinSortNum`, die Ausgabe dagegen nach `BinSortNum, BinKey`. Haben mehrere Lagerplätze dieselbe `BinSortNum`, ist die Vergabe von `RowNr` unter ihnen nicht deterministisch; Seiten können sich überschneiden oder Lagerplätze auslassen. In diesem Fall eindeutige Sortiernummern verwenden oder ohne Paging abfragen.\n- Die Spalten unterscheiden sich je nach Modus: `RowNr` ist nur bei `RowCount` > 0 enthalten.\n- Ein negativer `RowCount` wird nicht abgefangen und führt bei `TOP` zu einem SQL-Fehler.\n- `NrOfItemOnBin` ist die Gesamtmenge auf dem Lagerplatz, nicht die Anzahl unterschiedlicher Artikel.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStockBins"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Lagerplätze, optional gefiltert nach Lager und Lagerplatzgruppe, mit der Gesamtmenge je Lagerplatz und optionalem Paging.\n\nLiest die Lagerplätze aus `InvBin` und berechnet je Lagerplatz die Summe von `BinItemQTY` aller Einträge in `InvBinItem` auf diesem Lagerplatz (`NrOfItemOnBin`, 0 bei leerem Lagerplatz).\n\nFilter:\n- `LocID`: nur Lagerplätze dieses Lagers (`BinLocID`). Leerer String oder NULL bedeutet alle Lager.\n- `BinGroup`: nur Lagerplätze dieser Lagerplatzgruppe. Leerer String oder NULL bedeutet alle Gruppen.\n\nPaging:\n- Ist `RowCount` 0 oder NULL, werden alle passenden Lagerplätze ohne Spalte `RowNr` geliefert.\n- Ist `RowCount` größer als 0, werden die Zeilen nach `BinSortNum` nummeriert (`RowNr`), und es werden höchstens `RowCount` Zeilen mit `RowNr` größer als `Start` geliefert. `Start` ist also die Anzahl der zu überspringenden Zeilen.\n\nDas Ergebnis ist immer nach `BinSortNum` und danach `BinKey` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | Nein | Lager-ID als Filter. NULL oder leerer String liefert Lagerplätze aller Lager. |\n| `RowCount` | int | Nein | Maximale Anzahl Zeilen pro Seite. 0 oder NULL deaktiviert das Paging und liefert alle Zeilen. |\n| `Start` | int | Nein | Anzahl zu überspringender Zeilen bei aktivem Paging; geliefert werden Zeilen mit `RowNr` größer als dieser Wert. Wird ignoriert, wenn `RowCount` 0 ist. |\n| `BinGroup` | varchar(20) | Nein | Lagerplatzgruppe als Filter. NULL oder leerer String liefert Lagerplätze aller Gruppen. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, das Ergebnis kann also nicht festgeschriebene Daten enthalten.\n- Die Nummerierung für das Paging sortiert nur nach `BinSortNum`, die Ausgabe dagegen nach `BinSortNum, BinKey`. Haben mehrere Lagerplätze dieselbe `BinSortNum`, ist die Vergabe von `RowNr` unter ihnen nicht deterministisch; Seiten können sich überschneiden oder Lagerplätze auslassen. In diesem Fall eindeutige Sortiernummern verwenden oder ohne Paging abfragen.\n- Die Spalten unterscheiden sich je nach Modus: `RowNr` ist nur bei `RowCount` > 0 enthalten.\n- Ein negativer `RowCount` wird nicht abgefangen und führt bei `TOP` zu einem SQL-Fehler.\n- `NrOfItemOnBin` ist die Gesamtmenge auf dem Lagerplatz, nicht die Anzahl unterschiedlicher Artikel.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStockBins"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1201\n A-01-01\n 001\n 10\n HAUPTLAGER\n 42\n \n \n 1202\n A-01-02\n 001\n 20\n HAUPTLAGER\n 0\n \n"
}
]
},
{
"name": "pixiGetStockBinsEmpty",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert leere Lagerplätze (ohne Lagerplatzbestand-Datensatz), optional nur die in der Sortierung nahe an einem Referenz-Lagerplatz liegenden.\n\nSucht leere Lagerplätze. Ein Lagerplatz gilt als leer, wenn keine Zeile in `InvBinItem` auf ihn verweist (`BinRef = BinKey`).\n\n1. Werden `BinName` und `LocID` übergeben, wird der Schlüssel des Lagerplatzes mit diesem Namen in diesem Lager ermittelt und als Referenz-Lagerplatz (`NearBinKey`) verwendet. Existiert kein solcher Lagerplatz, bleibt ein übergebener `NearBinKey` unverändert.\n2. `LocID` leer oder `NULL` bedeutet alle Lager; andernfalls werden nur Lagerplätze dieses Lagers (`BinLocID`) berücksichtigt.\n3. **Ohne Referenz-Lagerplatz** (`NearBinKey` ist `NULL` oder `0`): Liefert die ersten `Rows` leeren Lagerplätze, aufsteigend nach `BinSortNum` sortiert.\n4. **Mit Referenz-Lagerplatz**: Ermittelt die `BinSortNum` des Referenz-Lagerplatzes und liefert bis zu `Rows / 2` (Ganzzahldivision) leere Lagerplätze mit `BinSortNum` kleiner oder gleich der Referenz (die nächstgelegenen, also die höchsten Sortiernummern darunter) sowie bis zu `Rows / 2` leere Lagerplätze mit höherer `BinSortNum` (die nächstgelegenen darüber). Die Gesamtliste wird aufsteigend nach `BinSortNum` sortiert.\n\nDer Referenz-Lagerplatz selbst ist im Ergebnis enthalten, wenn er leer ist und zum Lagerfilter passt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | Nein | Lager-ID, auf die die Suche beschränkt wird. `NULL` oder leer sucht in allen Lagern. Wird auch für die Suche über `BinName` benötigt. |\n| `Rows` | int | Nein | Maximale Anzahl zurückgegebener Lagerplätze. Mit Referenz-Lagerplatz wird jeweils die Hälfte (Ganzzahldivision) unterhalb und oberhalb der Referenz geliefert. |\n| `NearBinKey` | int | Nein | Schlüssel (`BinKey`) des Referenz-Lagerplatzes. `NULL` oder `0` bedeutet keine Referenz. Wird überschrieben, wenn `BinName` und `LocID` einen existierenden Lagerplatz bezeichnen. |\n| `BinName` | varchar(50) | Nein | Name des Referenz-Lagerplatzes; wird nur zusammen mit `LocID` ausgewertet. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; das Ergebnis kann nicht festgeschriebene Änderungen enthalten, ein als leer gemeldeter Lagerplatz kann bereits belegt sein.\n- Jede `InvBinItem`-Zeile macht einen Lagerplatz nicht-leer, unabhängig von der Menge.\n- Mit Referenz-Lagerplatz und ungeradem `Rows` werden höchstens `Rows - 1` Lagerplätze geliefert (z. B. liefert `Rows = 1` nichts).\n- Verweist `NearBinKey` auf einen nicht existierenden Lagerplatz, ist die Referenz-Sortiernummer `NULL` und das Ergebnis leer.\n- Das Lager des Referenz-Lagerplatzes wird nicht gegen `LocID` geprüft; wird nur `NearBinKey` übergeben, wird dessen Sortiernummer mit Lagerplätzen des gefilterten Lagers verglichen.\n- `BinName` wird nur zusammen mit `LocID` ausgewertet; allein wird es ignoriert.\n- `Rows` darf nicht `NULL` oder negativ sein, sonst löst die `TOP`-Klausel einen SQL-Fehler aus.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStockBinsEmpty"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert leere Lagerplätze (ohne Lagerplatzbestand-Datensatz), optional nur die in der Sortierung nahe an einem Referenz-Lagerplatz liegenden.\n\nSucht leere Lagerplätze. Ein Lagerplatz gilt als leer, wenn keine Zeile in `InvBinItem` auf ihn verweist (`BinRef = BinKey`).\n\n1. Werden `BinName` und `LocID` übergeben, wird der Schlüssel des Lagerplatzes mit diesem Namen in diesem Lager ermittelt und als Referenz-Lagerplatz (`NearBinKey`) verwendet. Existiert kein solcher Lagerplatz, bleibt ein übergebener `NearBinKey` unverändert.\n2. `LocID` leer oder `NULL` bedeutet alle Lager; andernfalls werden nur Lagerplätze dieses Lagers (`BinLocID`) berücksichtigt.\n3. **Ohne Referenz-Lagerplatz** (`NearBinKey` ist `NULL` oder `0`): Liefert die ersten `Rows` leeren Lagerplätze, aufsteigend nach `BinSortNum` sortiert.\n4. **Mit Referenz-Lagerplatz**: Ermittelt die `BinSortNum` des Referenz-Lagerplatzes und liefert bis zu `Rows / 2` (Ganzzahldivision) leere Lagerplätze mit `BinSortNum` kleiner oder gleich der Referenz (die nächstgelegenen, also die höchsten Sortiernummern darunter) sowie bis zu `Rows / 2` leere Lagerplätze mit höherer `BinSortNum` (die nächstgelegenen darüber). Die Gesamtliste wird aufsteigend nach `BinSortNum` sortiert.\n\nDer Referenz-Lagerplatz selbst ist im Ergebnis enthalten, wenn er leer ist und zum Lagerfilter passt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | Nein | Lager-ID, auf die die Suche beschränkt wird. `NULL` oder leer sucht in allen Lagern. Wird auch für die Suche über `BinName` benötigt. |\n| `Rows` | int | Nein | Maximale Anzahl zurückgegebener Lagerplätze. Mit Referenz-Lagerplatz wird jeweils die Hälfte (Ganzzahldivision) unterhalb und oberhalb der Referenz geliefert. |\n| `NearBinKey` | int | Nein | Schlüssel (`BinKey`) des Referenz-Lagerplatzes. `NULL` oder `0` bedeutet keine Referenz. Wird überschrieben, wenn `BinName` und `LocID` einen existierenden Lagerplatz bezeichnen. |\n| `BinName` | varchar(50) | Nein | Name des Referenz-Lagerplatzes; wird nur zusammen mit `LocID` ausgewertet. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`; das Ergebnis kann nicht festgeschriebene Änderungen enthalten, ein als leer gemeldeter Lagerplatz kann bereits belegt sein.\n- Jede `InvBinItem`-Zeile macht einen Lagerplatz nicht-leer, unabhängig von der Menge.\n- Mit Referenz-Lagerplatz und ungeradem `Rows` werden höchstens `Rows - 1` Lagerplätze geliefert (z. B. liefert `Rows = 1` nichts).\n- Verweist `NearBinKey` auf einen nicht existierenden Lagerplatz, ist die Referenz-Sortiernummer `NULL` und das Ergebnis leer.\n- Das Lager des Referenz-Lagerplatzes wird nicht gegen `LocID` geprüft; wird nur `NearBinKey` übergeben, wird dessen Sortiernummer mit Lagerplätzen des gefilterten Lagers verglichen.\n- `BinName` wird nur zusammen mit `LocID` ausgewertet; allein wird es ignoriert.\n- `Rows` darf nicht `NULL` oder negativ sein, sonst löst die `TOP`-Klausel einen SQL-Fehler aus.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStockBinsEmpty"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1020\n 001\n A-01-02\n 4711\n REGAL\n \n \n 1030\n 001\n A-01-03\n 4712\n REGAL\n \n"
}
]
},
{
"name": "pixiGetStockForItems",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den verfügbaren Bestand aller Artikel, berechnet nach den Einstellungen für den Bestandsexport.\n\nLiefert je Artikel eine Zeile mit der internen Artikelnummer und einer verfügbaren Menge. Die Berechnung hängt von Pixi-Einstellungen ab, die zur Laufzeit gelesen werden.\n\n**Alter Bestandsexport (`OldStockExport` = `1`)**\n\n- Alle Artikel aus `Items` werden mit `Quantity` als `AvailableQty` geliefert. `NULL` wird zu `0`.\n\n**Standardmodus (jeder andere Wert von `OldStockExport`)**\n\n1. Der Lagerort wird aus der Einstellung `ExportStock_locations` ermittelt:\n - Einstellung fehlt oder ist `0`: Lager `001`\n - leerer String: alle Lager (`ALL`)\n - jeder andere Wert: diese Lager-ID\n2. Je Artikel wird der Lagerplatzbestand als Summe von `BinItemQty` über alle Lagerplätze des gewählten Lagers bzw. aller Lager gebildet. Lager mit `SpecialStock` = 1 werden immer ausgeschlossen.\n3. Vom Lagerplatzbestand wird offener Bedarf abgezogen:\n - **Einstellung `ReservePrepaymentOrders` ≠ `1`:** Abgezogen wird die Summe von `Qty` der Auftragspositionen mit Status `ANG`. Positionen mit Status `HAL` zählen zusätzlich, wenn ihr `OrderDate` innerhalb der letzten `HalOrdersActiveDays` Tage liegt. Der Wert `0` dieser Einstellung bedeutet 7 Tage.\n - **Einstellung `ReservePrepaymentOrders` = `1`:** Abgezogen wird die Anzahl der Reservierungsdatensätze des Artikels. Gezählt werden nur Reservierungen, deren Positionsstatus kein Endstatus ist; die Status `EIN`, `FUT` und `FUS` sind ebenfalls ausgeschlossen.\n4. Negative Ergebnisse werden als `0` geliefert.\n5. Stücklistenartikel (Artikel mit Einträgen in `BundleItems`) werden per UNION ergänzt. Ihre Menge stammt nicht aus den Lagerplätzen. Sie ist `Items.Quantity` bei `ALL` bzw. `LocationQuantity` aus `ItemLocationSpecific` für das gewählte Lager. Für offene Aufträge oder Reservierungen wird nichts abgezogen, negative Werte werden zu `0`.\n\n**Filterung**\n\nBei `ExcludeZeros` = `1` werden vor der Ausgabe alle Zeilen mit `AvailableQty` = `0` entfernt.\n\nDas Ergebnis hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ExcludeZeros` | bit | Nein | Bei `1` werden Artikel mit verfügbarer Menge `0` aus dem Ergebnis entfernt. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, die Werte können daher nicht festgeschriebene Daten enthalten.\n- **Stücklistenartikel können doppelt erscheinen.** Im Standardmodus umfasst die erste Abfrage alle Artikel, auch Stücklisten. Eine Stückliste erhält daher eine Zeile aus der lagerplatzbasierten Berechnung und eine aus der Stücklistenberechnung. `UNION` entfernt nur vollständig identische Zeilen.\n- **Fehlendes `HalOrdersActiveDays`.** Fehlt die Einstellung, ist der Wert `NULL` und nicht `0`. Dann greift der Ersatzwert von 7 Tagen nicht, und Positionen mit Status `HAL` werden nie abgezogen.\n- **Reservierungen werden gezählt, nicht summiert.** Bei aktivierten Reservierungen wird die Anzahl der Reservierungsdatensätze abgezogen, keine Menge.\n- Die Einstellung `ShowLocationStockInItemSearch` wird gelesen, wirkt sich aber nicht auf das Ergebnis aus.\n- `ExportStock_locations` wird in einer `varchar(3)`-Variablen gespeichert, längere Werte werden auf 3 Zeichen gekürzt.\n- Der Aufruf berechnet korrelierte Unterabfragen je Artikel über alle Artikel und kann bei großen Datenbeständen langsam sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStockForItems"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den verfügbaren Bestand aller Artikel, berechnet nach den Einstellungen für den Bestandsexport.\n\nLiefert je Artikel eine Zeile mit der internen Artikelnummer und einer verfügbaren Menge. Die Berechnung hängt von Pixi-Einstellungen ab, die zur Laufzeit gelesen werden.\n\n**Alter Bestandsexport (`OldStockExport` = `1`)**\n\n- Alle Artikel aus `Items` werden mit `Quantity` als `AvailableQty` geliefert. `NULL` wird zu `0`.\n\n**Standardmodus (jeder andere Wert von `OldStockExport`)**\n\n1. Der Lagerort wird aus der Einstellung `ExportStock_locations` ermittelt:\n - Einstellung fehlt oder ist `0`: Lager `001`\n - leerer String: alle Lager (`ALL`)\n - jeder andere Wert: diese Lager-ID\n2. Je Artikel wird der Lagerplatzbestand als Summe von `BinItemQty` über alle Lagerplätze des gewählten Lagers bzw. aller Lager gebildet. Lager mit `SpecialStock` = 1 werden immer ausgeschlossen.\n3. Vom Lagerplatzbestand wird offener Bedarf abgezogen:\n - **Einstellung `ReservePrepaymentOrders` ≠ `1`:** Abgezogen wird die Summe von `Qty` der Auftragspositionen mit Status `ANG`. Positionen mit Status `HAL` zählen zusätzlich, wenn ihr `OrderDate` innerhalb der letzten `HalOrdersActiveDays` Tage liegt. Der Wert `0` dieser Einstellung bedeutet 7 Tage.\n - **Einstellung `ReservePrepaymentOrders` = `1`:** Abgezogen wird die Anzahl der Reservierungsdatensätze des Artikels. Gezählt werden nur Reservierungen, deren Positionsstatus kein Endstatus ist; die Status `EIN`, `FUT` und `FUS` sind ebenfalls ausgeschlossen.\n4. Negative Ergebnisse werden als `0` geliefert.\n5. Stücklistenartikel (Artikel mit Einträgen in `BundleItems`) werden per UNION ergänzt. Ihre Menge stammt nicht aus den Lagerplätzen. Sie ist `Items.Quantity` bei `ALL` bzw. `LocationQuantity` aus `ItemLocationSpecific` für das gewählte Lager. Für offene Aufträge oder Reservierungen wird nichts abgezogen, negative Werte werden zu `0`.\n\n**Filterung**\n\nBei `ExcludeZeros` = `1` werden vor der Ausgabe alle Zeilen mit `AvailableQty` = `0` entfernt.\n\nDas Ergebnis hat keine definierte Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ExcludeZeros` | bit | Nein | Bei `1` werden Artikel mit verfügbarer Menge `0` aus dem Ergebnis entfernt. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, die Werte können daher nicht festgeschriebene Daten enthalten.\n- **Stücklistenartikel können doppelt erscheinen.** Im Standardmodus umfasst die erste Abfrage alle Artikel, auch Stücklisten. Eine Stückliste erhält daher eine Zeile aus der lagerplatzbasierten Berechnung und eine aus der Stücklistenberechnung. `UNION` entfernt nur vollständig identische Zeilen.\n- **Fehlendes `HalOrdersActiveDays`.** Fehlt die Einstellung, ist der Wert `NULL` und nicht `0`. Dann greift der Ersatzwert von 7 Tagen nicht, und Positionen mit Status `HAL` werden nie abgezogen.\n- **Reservierungen werden gezählt, nicht summiert.** Bei aktivierten Reservierungen wird die Anzahl der Reservierungsdatensätze abgezogen, keine Menge.\n- Die Einstellung `ShowLocationStockInItemSearch` wird gelesen, wirkt sich aber nicht auf das Ergebnis aus.\n- `ExportStock_locations` wird in einer `varchar(3)`-Variablen gespeichert, längere Werte werden auf 3 Zeichen gekürzt.\n- Der Aufruf berechnet korrelierte Unterabfragen je Artikel über alle Artikel und kann bei großen Datenbeständen langsam sein.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStockForItems"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 100234\n 17\n \n \n 100235\n 0\n \n"
}
]
},
{
"name": "pixiGetStockMovementForOrderline",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Lagerbewegungen (Einträge des Lagerplatz-Artikel-Protokolls), die für eine Auftragsposition gebucht wurden, samt zugehörigem Lagerplatz.\n\nLiest das Lagerbewegungsprotokoll `InvBinItemLog` und liefert jeden Eintrag, dessen `ForOrderline` dem Wert von `OrderlineKey` entspricht.\n\n- Jeder Protokolleintrag wird über die Lagerplatzreferenz (`BinKey = BinRef`) mit der Lagerplatztabelle `InvBin` verknüpft. Es handelt sich um einen Inner Join, daher werden Einträge, deren Lagerplatz in `InvBin` nicht mehr existiert, nicht geliefert.\n- Pro Bewegung werden Menge, Artikelreferenz, Mitarbeiter und Datum der Buchung, der Grund sowie die Lagerplatzdaten (`BinKey`, `LocID`, `BinName`) zurückgegeben.\n- Eine Sortierung ist nicht festgelegt; die Zeilen kommen in der Reihenfolge, die SQL Server liefert.\n- Es gibt kein Paging; alle passenden Zeilen werden geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Ja | Schlüssel der Auftragsposition, deren Lagerbewegungen geliefert werden. Wird mit `InvBinItemLog.ForOrderline` verglichen. |\n\n- Existiert für die Auftragsposition keine Bewegung (oder der Schlüssel existiert nicht), wird eine leere Ergebnismenge geliefert; es wird kein Fehler ausgelöst.\n- Der Kopfkommentar der Prozedur ist ein allgemeiner Vorlagentext und beschreibt diesen Aufruf nicht.\n- Die Abfrage verwendet keine `NOLOCK`-Hinweise. Die Spaltentypen sind im Code nicht deklariert und hängen von den Tabellendefinitionen von `InvBinItemLog` und `InvBin` ab.\n- Die Vorzeichenkonvention von `Qty` (z. B. negativ bei Abgängen) ist im Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStockMovementForOrderline"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 123456\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle Lagerbewegungen (Einträge des Lagerplatz-Artikel-Protokolls), die für eine Auftragsposition gebucht wurden, samt zugehörigem Lagerplatz.\n\nLiest das Lagerbewegungsprotokoll `InvBinItemLog` und liefert jeden Eintrag, dessen `ForOrderline` dem Wert von `OrderlineKey` entspricht.\n\n- Jeder Protokolleintrag wird über die Lagerplatzreferenz (`BinKey = BinRef`) mit der Lagerplatztabelle `InvBin` verknüpft. Es handelt sich um einen Inner Join, daher werden Einträge, deren Lagerplatz in `InvBin` nicht mehr existiert, nicht geliefert.\n- Pro Bewegung werden Menge, Artikelreferenz, Mitarbeiter und Datum der Buchung, der Grund sowie die Lagerplatzdaten (`BinKey`, `LocID`, `BinName`) zurückgegeben.\n- Eine Sortierung ist nicht festgelegt; die Zeilen kommen in der Reihenfolge, die SQL Server liefert.\n- Es gibt kein Paging; alle passenden Zeilen werden geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Ja | Schlüssel der Auftragsposition, deren Lagerbewegungen geliefert werden. Wird mit `InvBinItemLog.ForOrderline` verglichen. |\n\n- Existiert für die Auftragsposition keine Bewegung (oder der Schlüssel existiert nicht), wird eine leere Ergebnismenge geliefert; es wird kein Fehler ausgelöst.\n- Der Kopfkommentar der Prozedur ist ein allgemeiner Vorlagentext und beschreibt diesen Aufruf nicht.\n- Die Abfrage verwendet keine `NOLOCK`-Hinweise. Die Spaltentypen sind im Code nicht deklariert und hängen von den Tabellendefinitionen von `InvBinItemLog` und `InvBin` ab.\n- Die Vorzeichenkonvention von `Qty` (z. B. negativ bei Abgängen) ist im Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStockMovementForOrderline"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n -2\n 4711\n JD\n 2024-03-12T10:15:32.000\n 123456\n PICK\n 812\n 001\n A-01-03\n \n"
}
]
},
{
"name": "pixiGetStockMovementOperations",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die für eine Anwendung definierten Lagerbewegungsvorgänge mit in die gewünschte Sprache übersetzten Namen.\n\nLiest die Lagerbewegungsvorgänge (Tabelle `StockMovementOperations`), die zu der in `Application` angegebenen Anwendung gehören. Typischer Einsatz ist das Befüllen einer Auswahlliste von Bewegungsgründen in einem Client wie Picco.\n\n- Es werden nur Vorgänge geliefert, deren gespeicherter Wert `Application` exakt `@Application` entspricht. Der Filter verwendet den unübersetzten Rohwert.\n- Anwendungsname und Vorgangsname werden über die Tabelle `Translation` in die Sprache aus `@LanguageID` übersetzt:\n - Für den Anwendungsnamen wird der `DBObjectName` `ApplicationNames` verwendet.\n - Für den Vorgangsnamen wird `StockMovementOperations` verwendet, zugeordnet über `SMOKey`.\n- Fehlt eine Übersetzung, wird der unübersetzte Wert aus `StockMovementOperations` geliefert.\n- `App_SMOName` kombiniert beide Texte im Format `Anwendung - Name`.\n- Der originale, unübersetzte Vorgangsname steht immer in `NameId`.\n\nDie Zeilen sind nach Anwendung und danach nach dem übersetzten Vorgangsnamen sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LanguageID` | int | Nein | Sprache, in die Anwendungs- und Vorgangsnamen über die Tabelle `Translation` übersetzt werden. |\n| `Application` | varchar(100) | Nein | Anwendung, deren Lagerbewegungsvorgänge geliefert werden. Der Wert wird exakt mit dem unübersetzten Wert `Application` in `StockMovementOperations` verglichen. |\n\n- Die Bedeutung der Sprach-IDs (z. B. für welche Sprache `2` steht) ist in den Pixi-Sprachstammdaten festgelegt, nicht in dieser Prozedur.\n- `@Application` muss dem unübersetzten Anwendungsschlüssel in `StockMovementOperations` entsprechen, nicht einem übersetzten Anzeigenamen.\n- Existiert für die Anwendung kein Vorgang, wird eine leere Ergebnismenge geliefert. Es wird kein Fehler ausgelöst.\n- Die Datentypen von `SMOKey`, `NameId`, `AskInGUI` und `Editable` stammen aus der Tabellendefinition, die nicht beigefügt ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStockMovementOperations"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die für eine Anwendung definierten Lagerbewegungsvorgänge mit in die gewünschte Sprache übersetzten Namen.\n\nLiest die Lagerbewegungsvorgänge (Tabelle `StockMovementOperations`), die zu der in `Application` angegebenen Anwendung gehören. Typischer Einsatz ist das Befüllen einer Auswahlliste von Bewegungsgründen in einem Client wie Picco.\n\n- Es werden nur Vorgänge geliefert, deren gespeicherter Wert `Application` exakt `@Application` entspricht. Der Filter verwendet den unübersetzten Rohwert.\n- Anwendungsname und Vorgangsname werden über die Tabelle `Translation` in die Sprache aus `@LanguageID` übersetzt:\n - Für den Anwendungsnamen wird der `DBObjectName` `ApplicationNames` verwendet.\n - Für den Vorgangsnamen wird `StockMovementOperations` verwendet, zugeordnet über `SMOKey`.\n- Fehlt eine Übersetzung, wird der unübersetzte Wert aus `StockMovementOperations` geliefert.\n- `App_SMOName` kombiniert beide Texte im Format `Anwendung - Name`.\n- Der originale, unübersetzte Vorgangsname steht immer in `NameId`.\n\nDie Zeilen sind nach Anwendung und danach nach dem übersetzten Vorgangsnamen sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LanguageID` | int | Nein | Sprache, in die Anwendungs- und Vorgangsnamen über die Tabelle `Translation` übersetzt werden. |\n| `Application` | varchar(100) | Nein | Anwendung, deren Lagerbewegungsvorgänge geliefert werden. Der Wert wird exakt mit dem unübersetzten Wert `Application` in `StockMovementOperations` verglichen. |\n\n- Die Bedeutung der Sprach-IDs (z. B. für welche Sprache `2` steht) ist in den Pixi-Sprachstammdaten festgelegt, nicht in dieser Prozedur.\n- `@Application` muss dem unübersetzten Anwendungsschlüssel in `StockMovementOperations` entsprechen, nicht einem übersetzten Anzeigenamen.\n- Existiert für die Anwendung kein Vorgang, wird eine leere Ergebnismenge geliefert. Es wird kein Fehler ausgelöst.\n- Die Datentypen von `SMOKey`, `NameId`, `AskInGUI` und `Editable` stammen aus der Tabellendefinition, die nicht beigefügt ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStockMovementOperations"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 12\n Picco\n Inventurkorrektur\n Inventory correction\n Picco - Inventurkorrektur\n 1\n 0\n \n \n 15\n Picco\n Umlagerung\n Relocation\n Picco - Umlagerung\n 1\n 1\n \n"
}
]
},
{
"name": "pixiGetStockMovementTypes",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle in Pixi definierten Lagerbewegungsarten mit Schlüssel, Bezeichnung und System-Kennzeichen, sortiert nach Bezeichnung.\n\nLiefert die vollständige Liste der Lagerbewegungsarten aus der Tabelle `StockMovementTypes`.\n\n- Der Aufruf hat keine Parameter und filtert nicht.\n- Jede Zeile enthält den Schlüssel `SMTKey`, die Bezeichnung `Type` und das Kennzeichen `IsSystemType` (Quellspalte `System`), das vom System vordefinierte Arten markiert.\n- Die Zeilen sind aufsteigend nach `Type` sortiert.\n\nDer Aufruf dient als Nachschlagetabelle, um Schlüssel von Lagerbewegungsarten zu übersetzen, die andere lagerbezogene Aufrufe liefern oder erwarten.\n\nDie Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können daher sichtbar sein. Die SQL-Datentypen der Spalten sind im Code nicht ersichtlich; die angegebenen Typen sind aus den Spaltennamen abgeleitete Annahmen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStockMovementTypes"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert alle in Pixi definierten Lagerbewegungsarten mit Schlüssel, Bezeichnung und System-Kennzeichen, sortiert nach Bezeichnung.\n\nLiefert die vollständige Liste der Lagerbewegungsarten aus der Tabelle `StockMovementTypes`.\n\n- Der Aufruf hat keine Parameter und filtert nicht.\n- Jede Zeile enthält den Schlüssel `SMTKey`, die Bezeichnung `Type` und das Kennzeichen `IsSystemType` (Quellspalte `System`), das vom System vordefinierte Arten markiert.\n- Die Zeilen sind aufsteigend nach `Type` sortiert.\n\nDer Aufruf dient als Nachschlagetabelle, um Schlüssel von Lagerbewegungsarten zu übersetzen, die andere lagerbezogene Aufrufe liefern oder erwarten.\n\nDie Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Änderungen können daher sichtbar sein. Die SQL-Datentypen der Spalten sind im Code nicht ersichtlich; die angegebenen Typen sind aus den Spaltennamen abgeleitete Annahmen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStockMovementTypes"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 3\n Inventory\n 1\n \n \n 12\n Rebooking\n 0\n \n"
}
]
},
{
"name": "pixiGetStockMovementTypesForOperation",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die den Lagerbewegungsoperationen einer Anwendung zugeordneten Lagerbewegungstypen mit übersetztem Namen und Standardtyp-Kennzeichen.\n\nLiefert die Lagerbewegungstypen, die über die Zuordnungstabelle `StockMovementMatching` mit Lagerbewegungsoperationen verknüpft sind.\n\n- Es werden nur Operationen berücksichtigt, deren `Application` dem Wert von `@Application` entspricht. Der Standardwert ist `Picco`.\n- Ist `@SMOKey` angegeben, werden nur die Bewegungstypen dieser einen Operation geliefert. Ist `@SMOKey` `NULL`, werden die Typen aller Operationen der Anwendung geliefert.\n- Der Name des Bewegungstyps (`SMTName`) stammt aus der Tabelle `Translation` (Objekt `StockMovementTypes.Name`) in der Sprache `@LanguageID`. Die Standard-Sprach-ID ist `2`.\n- Jede Zeile steht für eine Kombination aus Bewegungstyp und Operation. Ein Bewegungstyp, der mehreren Operationen zugeordnet ist, erscheint einmal je Operation.\n\nDas Ergebnis hat keine explizite Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Application` | varchar(100) | Nein | Anwendung, deren Lagerbewegungsoperationen ausgewertet werden. Der Wert wird mit `StockMovementOperations.Application` verglichen. |\n| `SMOKey` | int | Nein | Schlüssel einer Lagerbewegungsoperation, auf die das Ergebnis eingeschränkt wird. `NULL` (oder `0`) liefert alle Operationen der Anwendung. |\n| `LanguageID` | int | Nein | Sprach-ID, mit der der übersetzte Name des Bewegungstyps aus `Translation` gelesen wird. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- Der Filter auf `Application` entfernt Zeilen ohne zugeordnete Operation. Trotz der `LEFT JOIN`s werden Bewegungstypen, die keiner Operation zugeordnet sind, daher nie geliefert.\n- Der Code prüft `@SMOKey` mit `COALESCE(@SMOKey, '') = ''`. Da der Parameter vom Typ `int` ist, wird die leere Zeichenkette in `0` umgewandelt. Der Wert `0` verhält sich daher wie `NULL` und liefert alle Operationen der Anwendung.\n- Existiert keine Übersetzung in der angeforderten Sprache, ist `SMTName` `NULL`. Es erfolgt kein Rückgriff auf eine andere Sprache.\n- Welche Sprache `@LanguageID = 2` bezeichnet, geht aus dem Code nicht hervor. Dies hängt von den in der Pixi-Datenbank eingerichteten Sprach-IDs ab.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStockMovementTypesForOperation"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die den Lagerbewegungsoperationen einer Anwendung zugeordneten Lagerbewegungstypen mit übersetztem Namen und Standardtyp-Kennzeichen.\n\nLiefert die Lagerbewegungstypen, die über die Zuordnungstabelle `StockMovementMatching` mit Lagerbewegungsoperationen verknüpft sind.\n\n- Es werden nur Operationen berücksichtigt, deren `Application` dem Wert von `@Application` entspricht. Der Standardwert ist `Picco`.\n- Ist `@SMOKey` angegeben, werden nur die Bewegungstypen dieser einen Operation geliefert. Ist `@SMOKey` `NULL`, werden die Typen aller Operationen der Anwendung geliefert.\n- Der Name des Bewegungstyps (`SMTName`) stammt aus der Tabelle `Translation` (Objekt `StockMovementTypes.Name`) in der Sprache `@LanguageID`. Die Standard-Sprach-ID ist `2`.\n- Jede Zeile steht für eine Kombination aus Bewegungstyp und Operation. Ein Bewegungstyp, der mehreren Operationen zugeordnet ist, erscheint einmal je Operation.\n\nDas Ergebnis hat keine explizite Sortierung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Application` | varchar(100) | Nein | Anwendung, deren Lagerbewegungsoperationen ausgewertet werden. Der Wert wird mit `StockMovementOperations.Application` verglichen. |\n| `SMOKey` | int | Nein | Schlüssel einer Lagerbewegungsoperation, auf die das Ergebnis eingeschränkt wird. `NULL` (oder `0`) liefert alle Operationen der Anwendung. |\n| `LanguageID` | int | Nein | Sprach-ID, mit der der übersetzte Name des Bewegungstyps aus `Translation` gelesen wird. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten erscheinen.\n- Der Filter auf `Application` entfernt Zeilen ohne zugeordnete Operation. Trotz der `LEFT JOIN`s werden Bewegungstypen, die keiner Operation zugeordnet sind, daher nie geliefert.\n- Der Code prüft `@SMOKey` mit `COALESCE(@SMOKey, '') = ''`. Da der Parameter vom Typ `int` ist, wird die leere Zeichenkette in `0` umgewandelt. Der Wert `0` verhält sich daher wie `NULL` und liefert alle Operationen der Anwendung.\n- Existiert keine Übersetzung in der angeforderten Sprache, ist `SMTName` `NULL`. Es erfolgt kein Rückgriff auf eine andere Sprache.\n- Welche Sprache `@LanguageID = 2` bezeichnet, geht aus dem Code nicht hervor. Dies hängt von den in der Pixi-Datenbank eingerichteten Sprach-IDs ab.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetStockMovementTypesForOperation"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 12\n 3\n 1\n 1\n Umlagerung\n 1\n \n \n 15\n 3\n 1\n 2\n Korrektur\n 0\n \n"
}
]
},
{
"name": "pixiInventoryItemsToRefill",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 001\n 002\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Artikel, die von einem Quell- an ein Ziellager umgelagert werden müssen, um Mindestbestand und offene Kundenaufträge zu decken, samt Quell-Lagerplätzen.\n\nErstellt eine Nachschubliste (Umlagerungsliste) zwischen zwei Lagern. Der Aufruf reicht alle Parameter an die interne Prozedur `CR_InventoryItemsToRefill` weiter, die die eigentliche Arbeit erledigt.\n\n**Bedarf im Ziellager (`ToLocID`)**\n- *Offene Kundenaufträge*: Summe von `Orderlines.Qty` je Artikel in `ToLocID` mit Status `ANG`, `BES`, `BOR` und `HAL`. `HAL` entfällt, wenn die Einstellung `InventoryItemsToRefill_NoHAL` den Wert `1` hat.\n- *Zurückgehaltene Aufträge*: Summe von `Qty` der Auftragspositionen mit Status `HAL` in `ToLocID`. Dieser Wert dient nur zur Information.\n- Bestände je Lager stammen aus `ItemLocationSpecific` (`LocationQuantity`, `MinStockQty`, `TargetStock`).\n\n**Welche Artikel ausgewählt werden**\n- Der Artikel hat einen `ItemLocationSpecific`-Eintrag für `ToLocID`.\n- `FromLocID` ist ungleich `ToLocID`.\n- Positiver Mindestbestand plus offene Kundenauftragsmenge ist größer als der Bestand in `ToLocID`.\n- Der Artikel liegt auf mindestens einem Lagerplatz (`InvBin`) von `FromLocID`.\n\n**Fehlmenge**\n\nSie wird berechnet als positiver `MinStockQty` + offene Kundenauftragsmenge − Bestand in `ToLocID` − Bestand in `AdditionalLocID` (der letzte Term nur, wenn `AdditionalLocID` gesetzt ist).\n\n**Zuordnung zu Quell-Lagerplätzen**\n- Verwendet werden alle Lagerplatzeinträge (`InvBinItem`) des Artikels in `FromLocID`. Einträge, die von einer nicht abgelaufenen Picklistenposition (`PLitem`) referenziert werden, werden übersprungen.\n- Die Einträge werden nach Alter nummeriert, älteste zuerst (`CreateDate`). Nur die ersten *Fehlmenge* Einträge bleiben erhalten.\n- Das Ergebnis enthält eine Zeile je Artikel und Quell-Lagerplatz. `MissingQty` ist die Anzahl der Einträge, die von diesem Lagerplatz genommen werden. `FromBinqty` ist die Gesamtmenge des Artikels auf diesem Lagerplatz.\n- `ToLocIDbinName`/`ToLocIDbinSortNum` zeigen einen Lagerplatz des Artikels in `ToLocID`, sofern vorhanden.\n\n**Sortierung**\n\nBei `SortBy = '1'` wird nach `ToLocIDbinSortNum` sortiert, sonst nach `FromLocIDbinSortNum`. Innerhalb davon wird nach `ItemName` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromLocID` | varchar(3) | Ja | Quelllager, von dessen Lagerplätzen die Ware entnommen wird. |\n| `ToLocID` | varchar(3) | Ja | Ziellager, das aufgefüllt werden soll. Für dieses Lager werden Bestand, Mindestbestand und offene Kundenaufträge ausgewertet. |\n| `AdditionalLocID` | varchar(3) | Nein | Optionales Zusatzlager, dessen Bestand von der Fehlmenge abgezogen wird. Bei NULL oder leer wird kein Zusatzlager berücksichtigt. |\n| `SortBy` | varchar(1) | Nein | Sortierung des Ergebnisses. |\n\n- Nur lesend. Alle Tabellen werden `WITH (NOLOCK)` gelesen, daher kann das Ergebnis nicht festgeschriebene Daten enthalten.\n- Die Zuordnung zählt Lagerplatzeinträge (`InvBinItem`-Zeilen), keine Mengen. Das je Lagerplatz gelieferte `MissingQty` ist daher die Anzahl der Einträge, die von diesem Lagerplatz genommen werden. Die Summe über alle Lagerplätze eines Artikels kann kleiner als die berechnete Fehlmenge sein, wenn weniger Einträge vorhanden sind.\n- Der Auswahlfilter zieht den Bestand von `AdditionalLocID` nicht ab, die Fehlmenge dagegen schon. Deckt das Zusatzlager den Bedarf, ist die Fehlmenge 0 oder kleiner und der Artikel erscheint nicht.\n- `ToLocIDbinName` wird per `TOP 1` ohne `ORDER BY` ermittelt. Hat der Artikel mehrere Lagerplätze in `ToLocID`, ist nicht festgelegt, welcher angezeigt wird.\n- Die Einstellung wird über `fpixi_GetSetting` gelesen, deren Definition nicht vorliegt. Liefert sie `NULL` statt eines leeren Werts, wird `HAL` ebenfalls ausgeschlossen.\n- `FromLocQty` und `MinStockQty` können leer sein, wenn kein passender `ItemLocationSpecific`-Wert existiert.\n- Ist `FromLocID` gleich `ToLocID`, ist das Ergebnis immer leer.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiInventoryItemsToRefill"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 001\n 002\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Artikel, die von einem Quell- an ein Ziellager umgelagert werden müssen, um Mindestbestand und offene Kundenaufträge zu decken, samt Quell-Lagerplätzen.\n\nErstellt eine Nachschubliste (Umlagerungsliste) zwischen zwei Lagern. Der Aufruf reicht alle Parameter an die interne Prozedur `CR_InventoryItemsToRefill` weiter, die die eigentliche Arbeit erledigt.\n\n**Bedarf im Ziellager (`ToLocID`)**\n- *Offene Kundenaufträge*: Summe von `Orderlines.Qty` je Artikel in `ToLocID` mit Status `ANG`, `BES`, `BOR` und `HAL`. `HAL` entfällt, wenn die Einstellung `InventoryItemsToRefill_NoHAL` den Wert `1` hat.\n- *Zurückgehaltene Aufträge*: Summe von `Qty` der Auftragspositionen mit Status `HAL` in `ToLocID`. Dieser Wert dient nur zur Information.\n- Bestände je Lager stammen aus `ItemLocationSpecific` (`LocationQuantity`, `MinStockQty`, `TargetStock`).\n\n**Welche Artikel ausgewählt werden**\n- Der Artikel hat einen `ItemLocationSpecific`-Eintrag für `ToLocID`.\n- `FromLocID` ist ungleich `ToLocID`.\n- Positiver Mindestbestand plus offene Kundenauftragsmenge ist größer als der Bestand in `ToLocID`.\n- Der Artikel liegt auf mindestens einem Lagerplatz (`InvBin`) von `FromLocID`.\n\n**Fehlmenge**\n\nSie wird berechnet als positiver `MinStockQty` + offene Kundenauftragsmenge − Bestand in `ToLocID` − Bestand in `AdditionalLocID` (der letzte Term nur, wenn `AdditionalLocID` gesetzt ist).\n\n**Zuordnung zu Quell-Lagerplätzen**\n- Verwendet werden alle Lagerplatzeinträge (`InvBinItem`) des Artikels in `FromLocID`. Einträge, die von einer nicht abgelaufenen Picklistenposition (`PLitem`) referenziert werden, werden übersprungen.\n- Die Einträge werden nach Alter nummeriert, älteste zuerst (`CreateDate`). Nur die ersten *Fehlmenge* Einträge bleiben erhalten.\n- Das Ergebnis enthält eine Zeile je Artikel und Quell-Lagerplatz. `MissingQty` ist die Anzahl der Einträge, die von diesem Lagerplatz genommen werden. `FromBinqty` ist die Gesamtmenge des Artikels auf diesem Lagerplatz.\n- `ToLocIDbinName`/`ToLocIDbinSortNum` zeigen einen Lagerplatz des Artikels in `ToLocID`, sofern vorhanden.\n\n**Sortierung**\n\nBei `SortBy = '1'` wird nach `ToLocIDbinSortNum` sortiert, sonst nach `FromLocIDbinSortNum`. Innerhalb davon wird nach `ItemName` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromLocID` | varchar(3) | Ja | Quelllager, von dessen Lagerplätzen die Ware entnommen wird. |\n| `ToLocID` | varchar(3) | Ja | Ziellager, das aufgefüllt werden soll. Für dieses Lager werden Bestand, Mindestbestand und offene Kundenaufträge ausgewertet. |\n| `AdditionalLocID` | varchar(3) | Nein | Optionales Zusatzlager, dessen Bestand von der Fehlmenge abgezogen wird. Bei NULL oder leer wird kein Zusatzlager berücksichtigt. |\n| `SortBy` | varchar(1) | Nein | Sortierung des Ergebnisses. |\n\n- Nur lesend. Alle Tabellen werden `WITH (NOLOCK)` gelesen, daher kann das Ergebnis nicht festgeschriebene Daten enthalten.\n- Die Zuordnung zählt Lagerplatzeinträge (`InvBinItem`-Zeilen), keine Mengen. Das je Lagerplatz gelieferte `MissingQty` ist daher die Anzahl der Einträge, die von diesem Lagerplatz genommen werden. Die Summe über alle Lagerplätze eines Artikels kann kleiner als die berechnete Fehlmenge sein, wenn weniger Einträge vorhanden sind.\n- Der Auswahlfilter zieht den Bestand von `AdditionalLocID` nicht ab, die Fehlmenge dagegen schon. Deckt das Zusatzlager den Bedarf, ist die Fehlmenge 0 oder kleiner und der Artikel erscheint nicht.\n- `ToLocIDbinName` wird per `TOP 1` ohne `ORDER BY` ermittelt. Hat der Artikel mehrere Lagerplätze in `ToLocID`, ist nicht festgelegt, welcher angezeigt wird.\n- Die Einstellung wird über `fpixi_GetSetting` gelesen, deren Definition nicht vorliegt. Liefert sie `NULL` statt eines leeren Werts, wird `HAL` ebenfalls ausgeschlossen.\n- `FromLocQty` und `MinStockQty` können leer sein, wenn kein passender `ItemLocationSpecific`-Wert existiert.\n- Ist `FromLocID` gleich `ToLocID`, ist das Ergebnis immer leer.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiInventoryItemsToRefill"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n A-01-03\n 103\n S-02-01\n 201\n 4012345678901\n Trinkflasche 0,75 l blau\n 2\n 40\n 12\n 3\n 5\n 3.4500\n 0\n 0\n 001\n 002\n 0\n https://shop.example.com/img/s/4711.jpg\n https://shop.example.com/img/l/4711.jpg\n 4711\n 10\n \n"
}
]
},
{
"name": "pixiMobixGetBinItemInfo",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Artikel mit positivem Bestand auf einem Lagerplatz (oder allen Lagerplätzen) inkl. Tags, Lieferantennummern, offenen Picklisten und gepackten Mengen.\n\nListet alle Artikel, die aktuell Bestand auf einem Lagerplatz haben; gedacht für den mobilen Lagerclient Mobix.\n\n**Lagerplatzbestand**\n- Lagerplätze (`InvBin`) werden mit dem Lagerplatz-Artikel-Log (`InvBinItemLog`, verknüpft über Lagerplatz und Lager) und dem Artikelstamm (`items`) verbunden.\n- Ist `BinName` angegeben, werden nur Lagerplätze mit genau diesem Namen berücksichtigt (in jedem Lager). Fehlt der Parameter oder ist er `NULL`, werden alle Lagerplätze ausgewertet.\n- Die Mengen werden je Lagerplatz und Artikel summiert; nur Kombinationen mit einer Summe größer 0 werden geliefert.\n\n**Zusätzliche Artikelinformationen**\n- `Tags`: Namen der dem Artikel zugeordneten Artikel-Tags, alphabetisch sortiert, kommagetrennt.\n- `ItemNrSuppls`: eindeutige Lieferanten-Artikelnummern aus `additems`.\n- `SupplNrs`: Lieferantennummern aus `additems`.\n\n**Picklisten-Informationen**\n- Auftragspositionen des Artikels, die auf einer nicht abgelaufenen Picklistenposition stehen (`PLitem.Expired = 0`) und deren Status nicht `AUS`, `NLB`, `RET`, `STO` oder `EIN` ist, werden je Pickliste gezählt.\n- `PicklistsUsed` listet die Picklisten-Kopfreferenzen, `QtyOnPiclists` die Anzahl der Picklistenpositionen.\n\n**Karton-Informationen**\n- Auftragspositionen mit Status `EIN`, die in Kartons gepackt sind (`boxitems`, `boxes`), werden je Karton summiert.\n- `BoxesUsed` listet die Kartonnummern, `QtyInBoxes` die gepackte Menge.\n\n`LocId` schränkt nur die Picklisten- und Karton-Informationen auf Auftragspositionen dieses Lagers ein (`Orderlines.LocationID`). Ein leerer Wert oder `NULL` bedeutet alle Lager. Der Lagerplatzbestand selbst wird **nicht** nach `LocId` gefiltert.\n\nEine explizite Sortierung erfolgt nicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BinName` | varchar(50) | Nein | Name des auszuwertenden Lagerplatzes. `NULL` oder nicht angegeben liefert alle Lagerplätze mit positivem Bestand. |\n| `LocId` | varchar(3) | Nein | Lager-ID, mit der die Picklisten- und Karton-Informationen auf Auftragspositionen dieses Lagers eingeschränkt werden. `NULL` oder leer bedeutet alle Lager. Filtert nicht den Lagerplatzbestand. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- `QtyOnPiclists` und `QtyInBoxes` werden über skalare Unterabfragen ermittelt. Liegt ein Artikel auf mehr als einer Pickliste oder in mehr als einem Karton, löst SQL Server den Fehler 512 aus (Unterabfrage liefert mehr als einen Wert) und der Aufruf schlägt fehl.\n- Liegt derselbe Artikel im Ergebnis auf mehreren Lagerplätzen, wird die Picklisten-Anzahl durch den Join mit der Lagerplatzliste mit der Anzahl dieser Lagerplätze multipliziert.\n- Die Listen in `Tags`, `ItemNrSuppls`, `SupplNrs`, `PicklistsUsed` und `BoxesUsed` entstehen durch String-Verkettung und enden meist mit einem Komma; Trennzeichen können zusätzliche Leerzeichen enthalten.\n- Der Statusfilter für Picklisten verwendet eine nicht qualifizierte Spalte `Status`; vermutlich handelt es sich um den Status der Auftragsposition.\n- Ohne `BinName` werden alle Lagerplätze mit Bestand ausgewertet; das kann langsam sein und viele Zeilen liefern.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiMobixGetBinItemInfo"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Artikel mit positivem Bestand auf einem Lagerplatz (oder allen Lagerplätzen) inkl. Tags, Lieferantennummern, offenen Picklisten und gepackten Mengen.\n\nListet alle Artikel, die aktuell Bestand auf einem Lagerplatz haben; gedacht für den mobilen Lagerclient Mobix.\n\n**Lagerplatzbestand**\n- Lagerplätze (`InvBin`) werden mit dem Lagerplatz-Artikel-Log (`InvBinItemLog`, verknüpft über Lagerplatz und Lager) und dem Artikelstamm (`items`) verbunden.\n- Ist `BinName` angegeben, werden nur Lagerplätze mit genau diesem Namen berücksichtigt (in jedem Lager). Fehlt der Parameter oder ist er `NULL`, werden alle Lagerplätze ausgewertet.\n- Die Mengen werden je Lagerplatz und Artikel summiert; nur Kombinationen mit einer Summe größer 0 werden geliefert.\n\n**Zusätzliche Artikelinformationen**\n- `Tags`: Namen der dem Artikel zugeordneten Artikel-Tags, alphabetisch sortiert, kommagetrennt.\n- `ItemNrSuppls`: eindeutige Lieferanten-Artikelnummern aus `additems`.\n- `SupplNrs`: Lieferantennummern aus `additems`.\n\n**Picklisten-Informationen**\n- Auftragspositionen des Artikels, die auf einer nicht abgelaufenen Picklistenposition stehen (`PLitem.Expired = 0`) und deren Status nicht `AUS`, `NLB`, `RET`, `STO` oder `EIN` ist, werden je Pickliste gezählt.\n- `PicklistsUsed` listet die Picklisten-Kopfreferenzen, `QtyOnPiclists` die Anzahl der Picklistenpositionen.\n\n**Karton-Informationen**\n- Auftragspositionen mit Status `EIN`, die in Kartons gepackt sind (`boxitems`, `boxes`), werden je Karton summiert.\n- `BoxesUsed` listet die Kartonnummern, `QtyInBoxes` die gepackte Menge.\n\n`LocId` schränkt nur die Picklisten- und Karton-Informationen auf Auftragspositionen dieses Lagers ein (`Orderlines.LocationID`). Ein leerer Wert oder `NULL` bedeutet alle Lager. Der Lagerplatzbestand selbst wird **nicht** nach `LocId` gefiltert.\n\nEine explizite Sortierung erfolgt nicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BinName` | varchar(50) | Nein | Name des auszuwertenden Lagerplatzes. `NULL` oder nicht angegeben liefert alle Lagerplätze mit positivem Bestand. |\n| `LocId` | varchar(3) | Nein | Lager-ID, mit der die Picklisten- und Karton-Informationen auf Auftragspositionen dieses Lagers eingeschränkt werden. `NULL` oder leer bedeutet alle Lager. Filtert nicht den Lagerplatzbestand. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- `QtyOnPiclists` und `QtyInBoxes` werden über skalare Unterabfragen ermittelt. Liegt ein Artikel auf mehr als einer Pickliste oder in mehr als einem Karton, löst SQL Server den Fehler 512 aus (Unterabfrage liefert mehr als einen Wert) und der Aufruf schlägt fehl.\n- Liegt derselbe Artikel im Ergebnis auf mehreren Lagerplätzen, wird die Picklisten-Anzahl durch den Join mit der Lagerplatzliste mit der Anzahl dieser Lagerplätze multipliziert.\n- Die Listen in `Tags`, `ItemNrSuppls`, `SupplNrs`, `PicklistsUsed` und `BoxesUsed` entstehen durch String-Verkettung und enden meist mit einem Komma; Trennzeichen können zusätzliche Leerzeichen enthalten.\n- Der Statusfilter für Picklisten verwendet eine nicht qualifizierte Spalte `Status`; vermutlich handelt es sich um den Status der Auftragsposition.\n- Ohne `BinName` werden alle Lagerplätze mit Bestand ausgewertet; das kann langsam sein und viele Zeilen liefern.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiMobixGetBinItemInfo"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1523\n A-01-03\n 001\n T-Shirt Basic Black M\n 4012345678901\n tshirt_black.jpg\n 12\n Cotton, Sale,\n TS-BLK-M, \n 70001, \n 4711, \n 2\n \n 0\n \n"
}
]
},
{
"name": "pixiReadItemBinLog",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Einträge des Lagerplatz-Artikel-Protokolls (InvBinItemLog), optional nach Datumsbereichen gefiltert und über den Protokollschlüssel geblättert.\n\nLiest Zeilen aus dem Lagerplatz-Artikel-Protokoll `InvBinItemLog`. Jede Zeile beschreibt eine Mengenbuchung eines Artikels auf einem Lagerplatz.\n\n**Blättern (Paging)**\n\n- `ItemBinLogKey` ist eine exklusive Untergrenze. Es werden nur Zeilen mit `IBILkey` größer als dieser Wert geliefert. Fehlt der Parameter oder ist er NULL, wird `0` verwendet; der Abruf beginnt dann am Anfang des Protokolls.\n- `RowCount` begrenzt die Anzahl der Zeilen. Standard ist 1000; NULL wird ebenfalls als 1000 behandelt.\n- Die Sortierung erfolgt immer aufsteigend nach `IBILkey`. Für die nächste Seite wird der höchste `IBILkey` der vorherigen Seite als `ItemBinLogKey` übergeben.\n\n**Datumsfilter**\n\nEs wird nur eine Gruppe von Datumsfiltern verwendet. Die Gruppen werden in dieser Reihenfolge geprüft; die erste Gruppe mit mindestens einem gesetzten Wert gilt:\n\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: Die Untergrenze trifft zu, wenn `UpdateDate` **oder** `ReportedDate` >= From ist. Die Obergrenze trifft zu, wenn `UpdateDate` **oder** `ReportedDate` < To ist.\n2. `CreateDateFrom` / `CreateDateTo`: filtert auf die Spalte `UpdateDate` (>= From, < To).\n3. `UpdateDateFrom` / `UpdateDateTo`: filtert auf die Spalte `ReportedDate` (>= From, < To).\n\nIn jeder Gruppe kann eine der beiden Grenzen fehlen. Obergrenzen sind exklusiv. Ist kein Datumsparameter gesetzt, liefert der Aufruf die nächsten `RowCount` Zeilen nach `ItemBinLogKey`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemBinLogKey` | int | Nein | Exklusive Untergrenze für `IBILkey`. Es werden nur Zeilen mit größerem Schlüssel geliefert. NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Liefert Zeilen mit `UpdateDate` >= diesem Wert. Wird ignoriert, wenn ein kombinierter Datumsfilter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Liefert Zeilen mit `UpdateDate` < diesem Wert (exklusiv). Wird ignoriert, wenn ein kombinierter Datumsfilter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Liefert Zeilen mit `ReportedDate` >= diesem Wert. Wird nur verwendet, wenn weder ein kombinierter Filter noch ein CreateDate-Filter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Liefert Zeilen mit `ReportedDate` < diesem Wert (exklusiv). Wird nur verwendet, wenn weder ein kombinierter Filter noch ein CreateDate-Filter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze des kombinierten Filters. Eine Zeile trifft zu, wenn `UpdateDate` oder `ReportedDate` >= diesem Wert ist. Diese Gruppe hat die höchste Priorität. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze des kombinierten Filters (exklusiv). Eine Zeile trifft zu, wenn `UpdateDate` oder `ReportedDate` < diesem Wert ist. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. NULL wird als 1000 behandelt. |\n\n- Die Tabelle wird `WITH (NOLOCK)` gelesen. Noch nicht festgeschriebene Zeilen können erscheinen, und Zeilen können fehlen oder doppelt auftreten.\n- Mit `ItemBinLogKey` lässt sich kein einzelner Eintrag abrufen. Ein übergebener Schlüssel liefert die Zeilen **nach** diesem Schlüssel, nie die Zeile mit diesem Schlüssel. Der Code enthält Zweige für eine exakte Schlüsselsuche und für ein leeres Ergebnis. Diese werden nie erreicht, da `ItemBinLogKey` und `RowCount` zu Beginn durch Werte ungleich NULL ersetzt werden.\n- Die Parameternamen entsprechen nicht den Spaltennamen. `CreateDate*` filtert auf `UpdateDate`, `UpdateDate*` filtert auf `ReportedDate`.\n- Im kombinierten Filter werden die From- und To-Bedingung unabhängig ausgewertet. Eine Zeile kann die Untergrenze über eine Spalte und die Obergrenze über die andere erfüllen.\n- Datumsparameter einer nachrangigen Gruppe werden ignoriert, sobald eine vorrangige Gruppe einen Wert hat.\n- Die Datentypen der Spalten sind im Code nicht ersichtlich, außer bei `IBILkey` (Vergleich mit int) und den Datumsspalten (Vergleich mit datetime-Werten).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadItemBinLog"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Einträge des Lagerplatz-Artikel-Protokolls (InvBinItemLog), optional nach Datumsbereichen gefiltert und über den Protokollschlüssel geblättert.\n\nLiest Zeilen aus dem Lagerplatz-Artikel-Protokoll `InvBinItemLog`. Jede Zeile beschreibt eine Mengenbuchung eines Artikels auf einem Lagerplatz.\n\n**Blättern (Paging)**\n\n- `ItemBinLogKey` ist eine exklusive Untergrenze. Es werden nur Zeilen mit `IBILkey` größer als dieser Wert geliefert. Fehlt der Parameter oder ist er NULL, wird `0` verwendet; der Abruf beginnt dann am Anfang des Protokolls.\n- `RowCount` begrenzt die Anzahl der Zeilen. Standard ist 1000; NULL wird ebenfalls als 1000 behandelt.\n- Die Sortierung erfolgt immer aufsteigend nach `IBILkey`. Für die nächste Seite wird der höchste `IBILkey` der vorherigen Seite als `ItemBinLogKey` übergeben.\n\n**Datumsfilter**\n\nEs wird nur eine Gruppe von Datumsfiltern verwendet. Die Gruppen werden in dieser Reihenfolge geprüft; die erste Gruppe mit mindestens einem gesetzten Wert gilt:\n\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: Die Untergrenze trifft zu, wenn `UpdateDate` **oder** `ReportedDate` >= From ist. Die Obergrenze trifft zu, wenn `UpdateDate` **oder** `ReportedDate` < To ist.\n2. `CreateDateFrom` / `CreateDateTo`: filtert auf die Spalte `UpdateDate` (>= From, < To).\n3. `UpdateDateFrom` / `UpdateDateTo`: filtert auf die Spalte `ReportedDate` (>= From, < To).\n\nIn jeder Gruppe kann eine der beiden Grenzen fehlen. Obergrenzen sind exklusiv. Ist kein Datumsparameter gesetzt, liefert der Aufruf die nächsten `RowCount` Zeilen nach `ItemBinLogKey`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemBinLogKey` | int | Nein | Exklusive Untergrenze für `IBILkey`. Es werden nur Zeilen mit größerem Schlüssel geliefert. NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Liefert Zeilen mit `UpdateDate` >= diesem Wert. Wird ignoriert, wenn ein kombinierter Datumsfilter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Liefert Zeilen mit `UpdateDate` < diesem Wert (exklusiv). Wird ignoriert, wenn ein kombinierter Datumsfilter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Liefert Zeilen mit `ReportedDate` >= diesem Wert. Wird nur verwendet, wenn weder ein kombinierter Filter noch ein CreateDate-Filter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Liefert Zeilen mit `ReportedDate` < diesem Wert (exklusiv). Wird nur verwendet, wenn weder ein kombinierter Filter noch ein CreateDate-Filter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze des kombinierten Filters. Eine Zeile trifft zu, wenn `UpdateDate` oder `ReportedDate` >= diesem Wert ist. Diese Gruppe hat die höchste Priorität. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze des kombinierten Filters (exklusiv). Eine Zeile trifft zu, wenn `UpdateDate` oder `ReportedDate` < diesem Wert ist. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. NULL wird als 1000 behandelt. |\n\n- Die Tabelle wird `WITH (NOLOCK)` gelesen. Noch nicht festgeschriebene Zeilen können erscheinen, und Zeilen können fehlen oder doppelt auftreten.\n- Mit `ItemBinLogKey` lässt sich kein einzelner Eintrag abrufen. Ein übergebener Schlüssel liefert die Zeilen **nach** diesem Schlüssel, nie die Zeile mit diesem Schlüssel. Der Code enthält Zweige für eine exakte Schlüsselsuche und für ein leeres Ergebnis. Diese werden nie erreicht, da `ItemBinLogKey` und `RowCount` zu Beginn durch Werte ungleich NULL ersetzt werden.\n- Die Parameternamen entsprechen nicht den Spaltennamen. `CreateDate*` filtert auf `UpdateDate`, `UpdateDate*` filtert auf `ReportedDate`.\n- Im kombinierten Filter werden die From- und To-Bedingung unabhängig ausgewertet. Eine Zeile kann die Untergrenze über eine Spalte und die Obergrenze über die andere erfüllen.\n- Datumsparameter einer nachrangigen Gruppe werden ignoriert, sobald eine vorrangige Gruppe einen Wert hat.\n- Die Datentypen der Spalten sind im Code nicht ersichtlich, außer bei `IBILkey` (Vergleich mit int) und den Datumsspalten (Vergleich mit datetime-Werten).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadItemBinLog"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 125431\n 001\n 4711\n -2\n 88213\n MM\n 2024-05-01T09:14:22.000\n 2024-05-01T09:14:22.000\n 553201\n Pick\n 0\n 0\n DL-20240501-17\n \n \n 125432\n 001\n 4802\n 10\n 88214\n JS\n 2024-05-01T09:20:05.000\n 2024-05-01T09:20:05.000\n 0\n Booking\n 0\n 0\n \n \n"
}
]
},
{
"name": "pixiRemoveItemFromPicklist",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 12345\n 4006381333931\n A-01-02-03\n 1\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Entfernt eine angegebene Menge eines per Barcode bestimmten Artikels eines Lagerplatzes von einer Pickliste und liefert eine Statuszeile.\n\nEntfernt Picklistenpositionen für einen Artikel und einen Lagerplatz von einer Pickliste.\n\nAblauf:\n\n1. `Quantity` muss mindestens 1 sein. Bei `NULL` oder kleineren Werten wird ein Fehler geliefert.\n2. Der Lagerplatz wird über seinen Namen (`BinName`) in `InvBin` ermittelt.\n3. Der Artikel wird über seinen Barcode (`EanUpc`) ermittelt. Dabei werden die Artikelcodes mit Codetyp 1 (Barcode) verwendet.\n4. Gezählt werden die Picklistenpositionen (`PLitem`-Zeilen mit verknüpfter Auftragsposition) der Pickliste für diesen Lagerplatz und Artikel. **Jede Position zählt als ein Stück.**\n5. Wird keine Position gefunden, ermittelt der Aufruf den Grund und liefert einen passenden Fehler: Die Pickliste existiert nicht, die Pickliste hat keine Positionen von diesem Lagerplatz, oder der Artikel steht auf diesem Lagerplatz nicht auf der Pickliste.\n6. Gibt es weniger Positionen als `Quantity`, wird ein Fehler geliefert und nichts gelöscht.\n7. Andernfalls werden `Quantity` Positionen entfernt, beginnend mit den neuesten Positionen (höchster Positionsschlüssel, also vom Ende der Pickliste). Bei den betroffenen Auftragspositionen wird der Picklistenbezug (`PickListNrUsed`) auf `NULL` zurückgesetzt. Alle Pickfortschritts-Einträge für diese Pickliste, diesen Artikel und Lagerplatz werden gelöscht. Danach werden zugeordnete Kisten von nun leeren Picklisten bereinigt.\n8. Eine `SUCCESS`-Zeile meldet die Anzahl der gelöschten Positionen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PickListNr` | int | Ja | Nummer (Schlüssel) der Pickliste (`PLHkey`). |\n| `EanUpc` | varchar(50) | Ja | Barcode (EAN/UPC) des Artikels. Er wird mit den Artikelcodes vom Codetyp 1 (Barcode) abgeglichen. |\n| `BinName` | varchar(50) | Ja | Name des Lagerplatzes, von dem der Artikel gepickt wird. |\n| `Quantity` | int | Ja | Anzahl der zu entfernenden Picklistenpositionen (Stück). Muss mindestens 1 sein und darf die Anzahl der passenden Positionen nicht überschreiten. |\n\n- Das Löschen läuft in einer eigenen Transaktion oder, falls bereits eine Transaktion offen ist, in einem Savepoint. Bei einem Datenbankfehler werden die Änderungen zurückgerollt und der Fehler wird über `log.InsertError` protokolliert. **Der Aufruf liefert in diesem Fall trotzdem `SUCCESS`**, mit der Meldung `0 items deleted from picklist.` Eine Anzahl von 0 ist daher als Fehlschlag zu werten.\n- Gelöscht werden alle Pickfortschritts-Einträge (`PL_ItemPickingProgress`) für Pickliste, Artikel und Lagerplatz, nicht nur die für die entfernte Menge.\n- Die Bereinigung der Kisten erfolgt über `dbo.pixi_RemoveAssignedBoxesFromEmptyPicklist`. Dessen Definition liegt nicht vor, die genauen Auswirkungen sind daher hier nicht dokumentiert.\n- Die Abfragen und Zählungen verwenden `NOLOCK`. Haben mehrere Lagerplätze denselben Namen oder mehrere Artikel denselben Barcode, ist nicht festgelegt, welcher Datensatz verwendet wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiRemoveItemFromPicklist"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 12345\n 4006381333931\n A-01-02-03\n 1\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Entfernt eine angegebene Menge eines per Barcode bestimmten Artikels eines Lagerplatzes von einer Pickliste und liefert eine Statuszeile.\n\nEntfernt Picklistenpositionen für einen Artikel und einen Lagerplatz von einer Pickliste.\n\nAblauf:\n\n1. `Quantity` muss mindestens 1 sein. Bei `NULL` oder kleineren Werten wird ein Fehler geliefert.\n2. Der Lagerplatz wird über seinen Namen (`BinName`) in `InvBin` ermittelt.\n3. Der Artikel wird über seinen Barcode (`EanUpc`) ermittelt. Dabei werden die Artikelcodes mit Codetyp 1 (Barcode) verwendet.\n4. Gezählt werden die Picklistenpositionen (`PLitem`-Zeilen mit verknüpfter Auftragsposition) der Pickliste für diesen Lagerplatz und Artikel. **Jede Position zählt als ein Stück.**\n5. Wird keine Position gefunden, ermittelt der Aufruf den Grund und liefert einen passenden Fehler: Die Pickliste existiert nicht, die Pickliste hat keine Positionen von diesem Lagerplatz, oder der Artikel steht auf diesem Lagerplatz nicht auf der Pickliste.\n6. Gibt es weniger Positionen als `Quantity`, wird ein Fehler geliefert und nichts gelöscht.\n7. Andernfalls werden `Quantity` Positionen entfernt, beginnend mit den neuesten Positionen (höchster Positionsschlüssel, also vom Ende der Pickliste). Bei den betroffenen Auftragspositionen wird der Picklistenbezug (`PickListNrUsed`) auf `NULL` zurückgesetzt. Alle Pickfortschritts-Einträge für diese Pickliste, diesen Artikel und Lagerplatz werden gelöscht. Danach werden zugeordnete Kisten von nun leeren Picklisten bereinigt.\n8. Eine `SUCCESS`-Zeile meldet die Anzahl der gelöschten Positionen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `PickListNr` | int | Ja | Nummer (Schlüssel) der Pickliste (`PLHkey`). |\n| `EanUpc` | varchar(50) | Ja | Barcode (EAN/UPC) des Artikels. Er wird mit den Artikelcodes vom Codetyp 1 (Barcode) abgeglichen. |\n| `BinName` | varchar(50) | Ja | Name des Lagerplatzes, von dem der Artikel gepickt wird. |\n| `Quantity` | int | Ja | Anzahl der zu entfernenden Picklistenpositionen (Stück). Muss mindestens 1 sein und darf die Anzahl der passenden Positionen nicht überschreiten. |\n\n- Das Löschen läuft in einer eigenen Transaktion oder, falls bereits eine Transaktion offen ist, in einem Savepoint. Bei einem Datenbankfehler werden die Änderungen zurückgerollt und der Fehler wird über `log.InsertError` protokolliert. **Der Aufruf liefert in diesem Fall trotzdem `SUCCESS`**, mit der Meldung `0 items deleted from picklist.` Eine Anzahl von 0 ist daher als Fehlschlag zu werten.\n- Gelöscht werden alle Pickfortschritts-Einträge (`PL_ItemPickingProgress`) für Pickliste, Artikel und Lagerplatz, nicht nur die für die entfernte Menge.\n- Die Bereinigung der Kisten erfolgt über `dbo.pixi_RemoveAssignedBoxesFromEmptyPicklist`. Dessen Definition liegt nicht vor, die genauen Auswirkungen sind daher hier nicht dokumentiert.\n- Die Abfragen und Zählungen verwenden `NOLOCK`. Haben mehrere Lagerplätze denselben Namen oder mehrere Artikel denselben Barcode, ist nicht festgelegt, welcher Datensatz verwendet wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiRemoveItemFromPicklist"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n SUCCESS\n 2 items deleted from picklist.\n \n"
}
]
},
{
"name": "pixiReportInventoryItemsToRefillMinStock",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 002\n \n 001\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine Pickliste der Artikel, die von einem Quell- an einen Ziellagerort umzulagern sind, mit Menge je Quell-Lagerplatz nach einem von drei Auffüllmodi.\n\nDer Aufruf gibt alle Parameter unverändert an die interne Report-Prozedur `Report_InventoryItemsToRefillMinStock` weiter und liefert deren Ergebnis.\n\n**Schritt 1 – Kandidaten-Artikel**\n\nEin Artikel ist nur dann ein Kandidat, wenn:\n- `FromLocID` und `ToLocID` verschieden sind,\n- der Artikel für `FromLocID` und `ToLocID` je einen `ItemLocationSpecific`-Datensatz hat,\n- der Artikel mindestens einem Lagerplatz (`InvBinItem`/`InvBin`) in `FromLocID` zugeordnet ist,\n- die berechnete Fehlmenge größer als 0 ist.\n\nOffene Auftragsmengen werden aus den `Orderlines` des Artikels an einem *Auftragslagerort* summiert. Dieser ist `ToLocID` bei `Type` 1 und 3, sonst `FromLocID`. Die Status `ANG`, `BES` und `BOR` zählen als offene Kundenaufträge, `HAL` als angehaltene Aufträge. Steht die Einstellung `InventoryItemsToRefill_NoHAL` auf `1`, bleiben angehaltene Mengen in den Berechnungen unberücksichtigt.\n\nDer **verfügbare Bestand** am Quelllagerort ist der Lagerortbestand in `FromLocID`, abzüglich:\n- des Mindestbestands von `FromLocID` (nur bei `MinStock` = 1 und `Type` = 2),\n- der offenen Kundenauftragsmenge (nur wenn der Auftragslagerort `FromLocID` ist),\n- der angehaltenen Menge (sofern die Einstellung sie nicht ausschließt).\n\nDie **Fehlmenge am zusätzlichen Lagerort** ist Mindestbestand minus Lagerortbestand in `AdditionalLocID`. Liegt der Bestand nicht unter dem Mindestbestand, ist sie 0.\n\nDie Fehlmenge hängt von `Type` ab:\n- `1`: Bedarf = offene Kundenaufträge in `ToLocID` + angehaltene Menge + Mindestbestand von `ToLocID` (nur bei `MinStock` = 1). Passt der Bedarf in den verfügbaren Bestand, ist das Ziel die Fehlmenge am zusätzlichen Lagerort plus Bedarf, sonst der verfügbare Bestand. Ergebnis ist Ziel minus aktueller Bestand in `ToLocID`, mindestens 0.\n- `2`: Fehlmenge am zusätzlichen Lagerort, begrenzt auf den verfügbaren Bestand am Quelllagerort.\n- `3`: Nur wenn alle folgenden Bedingungen erfüllt sind: Mindestbestand in `ToLocID` ist 0, Bestand in `AdditionalLocID` ist 0, Bestand in `FromLocID` ist größer 0 und es gibt offene Kundenaufträge in `ToLocID`. Ergebnis ist der kleinere Wert aus offenen Kundenaufträgen und Bestand in `FromLocID`.\n\n**Schritt 2 – Verteilung auf Lagerplätze**\n\nJe Kandidat werden die `InvBinItem`-Datensätze des Artikels auf Lagerplätzen in `FromLocID` nach `InvBinItemKey` nummeriert. Verwendet werden nur die ersten *n* Datensätze, wobei *n* die Fehlmenge ist. Die Zeilen werden je Quell-Lagerplatz gruppiert. `MissingQty` in der Ausgabe ist die Anzahl dieser Datensätze auf dem jeweiligen Lagerplatz. Das entspricht einer Stückzahl, wenn jeder Lagerplatz-Datensatz für ein Stück steht. Zusätzlich wird ein Lagerplatz in `ToLocID` als Ziel-Lagerplatz ausgegeben, falls vorhanden.\n\n**Sortierung**\n\nBei `SortBy` = `1` wird nach der Sortiernummer des Ziel-Lagerplatzes sortiert, sonst nach der des Quell-Lagerplatzes. Innerhalb davon wird nach `ItemName` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromLocID` | varchar(3) | Ja | Quelllagerort, aus dem entnommen wird. Der Artikel muss hier Lagerplätze und einen `ItemLocationSpecific`-Datensatz haben. |\n| `MinStock` | bit | Nein | Steuert, ob der Mindestbestand berücksichtigt wird. Bei `Type` 1 wird der Mindestbestand von `ToLocID` zum Bedarf addiert. Bei `Type` 2 wird der Mindestbestand von `FromLocID` vom verfügbaren Bestand zurückgehalten. Keine Wirkung bei `Type` 3. |\n| `ToLocID` | varchar(3) | Ja | Ziellagerort, der aufgefüllt werden soll. Muss sich von `FromLocID` unterscheiden, sonst werden keine Zeilen geliefert. Der Artikel muss hier einen `ItemLocationSpecific`-Datensatz haben. |\n| `AdditionalLocID` | varchar(3) | Nein | Zusätzlicher Lagerort, dessen Unterschreitung des Mindestbestands einbezogen wird (`Type` 1 und 2). Bei `Type` 3 muss sein Bestand 0 sein. |\n| `SortBy` | varchar(1) | Nein | Sortierung des Ergebnisses. Der Wert wird auch in der Spalte `SortBy` zurückgegeben. |\n| `Type` | int | Nein | Berechnungsmodus für die Fehlmenge. Ohne gültigen Wert werden keine Zeilen geliefert. |\n\n- Der Kopfkommentar der Wrapper-Prozedur beschreibt sie als Aufruf des *1SS-Reports zu Abrechnungszwecken*.\n- `Type` ist im Wrapper standardmäßig `NULL`. Bei `NULL` oder einem anderen Wert als 1, 2 oder 3 ist die Fehlmenge `NULL` und es werden keine Zeilen geliefert. `Type` sollte daher immer übergeben werden.\n- Die Fehlmenge am zusätzlichen Lagerort stammt aus einer Outer-Verknüpfung. Ist `AdditionalLocID` `NULL` oder hat der Artikel dort keinen `ItemLocationSpecific`-Datensatz, ist der Wert `NULL` statt 0:\n - `Type` 2 und `Type` 3 liefern dann für den Artikel keine Zeile.\n - `Type` 1 liefert nur dann eine Zeile, wenn der Bedarf den verfügbaren Bestand übersteigt.\n- Der Ziel-Lagerplatz wird per `TOP 1` ohne `ORDER BY` ermittelt. Bei mehreren Lagerplätzen in `ToLocID` ist der angezeigte Lagerplatz nicht deterministisch.\n- Der Wert der Einstellung `InventoryItemsToRefill_NoHAL` wird zur Laufzeit über `fPIXI_GetSetting` gelesen; diese Funktion liegt nicht vor.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten enthalten sein.\n- Der Aufruf liest nur Daten. Intern wird eine temporäre Tabelle verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportInventoryItemsToRefillMinStock"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 002\n \n 001\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert eine Pickliste der Artikel, die von einem Quell- an einen Ziellagerort umzulagern sind, mit Menge je Quell-Lagerplatz nach einem von drei Auffüllmodi.\n\nDer Aufruf gibt alle Parameter unverändert an die interne Report-Prozedur `Report_InventoryItemsToRefillMinStock` weiter und liefert deren Ergebnis.\n\n**Schritt 1 – Kandidaten-Artikel**\n\nEin Artikel ist nur dann ein Kandidat, wenn:\n- `FromLocID` und `ToLocID` verschieden sind,\n- der Artikel für `FromLocID` und `ToLocID` je einen `ItemLocationSpecific`-Datensatz hat,\n- der Artikel mindestens einem Lagerplatz (`InvBinItem`/`InvBin`) in `FromLocID` zugeordnet ist,\n- die berechnete Fehlmenge größer als 0 ist.\n\nOffene Auftragsmengen werden aus den `Orderlines` des Artikels an einem *Auftragslagerort* summiert. Dieser ist `ToLocID` bei `Type` 1 und 3, sonst `FromLocID`. Die Status `ANG`, `BES` und `BOR` zählen als offene Kundenaufträge, `HAL` als angehaltene Aufträge. Steht die Einstellung `InventoryItemsToRefill_NoHAL` auf `1`, bleiben angehaltene Mengen in den Berechnungen unberücksichtigt.\n\nDer **verfügbare Bestand** am Quelllagerort ist der Lagerortbestand in `FromLocID`, abzüglich:\n- des Mindestbestands von `FromLocID` (nur bei `MinStock` = 1 und `Type` = 2),\n- der offenen Kundenauftragsmenge (nur wenn der Auftragslagerort `FromLocID` ist),\n- der angehaltenen Menge (sofern die Einstellung sie nicht ausschließt).\n\nDie **Fehlmenge am zusätzlichen Lagerort** ist Mindestbestand minus Lagerortbestand in `AdditionalLocID`. Liegt der Bestand nicht unter dem Mindestbestand, ist sie 0.\n\nDie Fehlmenge hängt von `Type` ab:\n- `1`: Bedarf = offene Kundenaufträge in `ToLocID` + angehaltene Menge + Mindestbestand von `ToLocID` (nur bei `MinStock` = 1). Passt der Bedarf in den verfügbaren Bestand, ist das Ziel die Fehlmenge am zusätzlichen Lagerort plus Bedarf, sonst der verfügbare Bestand. Ergebnis ist Ziel minus aktueller Bestand in `ToLocID`, mindestens 0.\n- `2`: Fehlmenge am zusätzlichen Lagerort, begrenzt auf den verfügbaren Bestand am Quelllagerort.\n- `3`: Nur wenn alle folgenden Bedingungen erfüllt sind: Mindestbestand in `ToLocID` ist 0, Bestand in `AdditionalLocID` ist 0, Bestand in `FromLocID` ist größer 0 und es gibt offene Kundenaufträge in `ToLocID`. Ergebnis ist der kleinere Wert aus offenen Kundenaufträgen und Bestand in `FromLocID`.\n\n**Schritt 2 – Verteilung auf Lagerplätze**\n\nJe Kandidat werden die `InvBinItem`-Datensätze des Artikels auf Lagerplätzen in `FromLocID` nach `InvBinItemKey` nummeriert. Verwendet werden nur die ersten *n* Datensätze, wobei *n* die Fehlmenge ist. Die Zeilen werden je Quell-Lagerplatz gruppiert. `MissingQty` in der Ausgabe ist die Anzahl dieser Datensätze auf dem jeweiligen Lagerplatz. Das entspricht einer Stückzahl, wenn jeder Lagerplatz-Datensatz für ein Stück steht. Zusätzlich wird ein Lagerplatz in `ToLocID` als Ziel-Lagerplatz ausgegeben, falls vorhanden.\n\n**Sortierung**\n\nBei `SortBy` = `1` wird nach der Sortiernummer des Ziel-Lagerplatzes sortiert, sonst nach der des Quell-Lagerplatzes. Innerhalb davon wird nach `ItemName` sortiert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromLocID` | varchar(3) | Ja | Quelllagerort, aus dem entnommen wird. Der Artikel muss hier Lagerplätze und einen `ItemLocationSpecific`-Datensatz haben. |\n| `MinStock` | bit | Nein | Steuert, ob der Mindestbestand berücksichtigt wird. Bei `Type` 1 wird der Mindestbestand von `ToLocID` zum Bedarf addiert. Bei `Type` 2 wird der Mindestbestand von `FromLocID` vom verfügbaren Bestand zurückgehalten. Keine Wirkung bei `Type` 3. |\n| `ToLocID` | varchar(3) | Ja | Ziellagerort, der aufgefüllt werden soll. Muss sich von `FromLocID` unterscheiden, sonst werden keine Zeilen geliefert. Der Artikel muss hier einen `ItemLocationSpecific`-Datensatz haben. |\n| `AdditionalLocID` | varchar(3) | Nein | Zusätzlicher Lagerort, dessen Unterschreitung des Mindestbestands einbezogen wird (`Type` 1 und 2). Bei `Type` 3 muss sein Bestand 0 sein. |\n| `SortBy` | varchar(1) | Nein | Sortierung des Ergebnisses. Der Wert wird auch in der Spalte `SortBy` zurückgegeben. |\n| `Type` | int | Nein | Berechnungsmodus für die Fehlmenge. Ohne gültigen Wert werden keine Zeilen geliefert. |\n\n- Der Kopfkommentar der Wrapper-Prozedur beschreibt sie als Aufruf des *1SS-Reports zu Abrechnungszwecken*.\n- `Type` ist im Wrapper standardmäßig `NULL`. Bei `NULL` oder einem anderen Wert als 1, 2 oder 3 ist die Fehlmenge `NULL` und es werden keine Zeilen geliefert. `Type` sollte daher immer übergeben werden.\n- Die Fehlmenge am zusätzlichen Lagerort stammt aus einer Outer-Verknüpfung. Ist `AdditionalLocID` `NULL` oder hat der Artikel dort keinen `ItemLocationSpecific`-Datensatz, ist der Wert `NULL` statt 0:\n - `Type` 2 und `Type` 3 liefern dann für den Artikel keine Zeile.\n - `Type` 1 liefert nur dann eine Zeile, wenn der Bedarf den verfügbaren Bestand übersteigt.\n- Der Ziel-Lagerplatz wird per `TOP 1` ohne `ORDER BY` ermittelt. Bei mehreren Lagerplätzen in `ToLocID` ist der angezeigte Lagerplatz nicht deterministisch.\n- Der Wert der Einstellung `InventoryItemsToRefill_NoHAL` wird zur Laufzeit über `fPIXI_GetSetting` gelesen; diese Funktion liegt nicht vor.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten enthalten sein.\n- Der Aufruf liest nur Daten. Intern wird eine temporäre Tabelle verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReportInventoryItemsToRefillMinStock"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n A-01-03\n 103\n S-12-01\n 1201\n 4012345678901\n Trinkflasche 750 ml\n 2\n 40\n 5\n 3.20\n 4\n 0\n 002\n 001\n 1\n 7\n 12\n https://shop.example.com/img/s/4711.jpg\n https://shop.example.com/img/l/4711.jpg\n \n"
}
]
},
{
"name": "pixiReport_ItemsOnStockWithBatchManagement",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Bestand je Artikel, Lagerplatz, Chargennummer und MHD für Artikel mit Chargenverwaltung auf Basis des pixi*-Reports \"Items on stock with BN/BBD\".\n\nStellt den pixi*-Report *Items on stock with BN/BBD* (Chargennummer / Mindesthaltbarkeitsdatum) als API-Call bereit.\n\n1. **Normalisierung:** Leere Zeichenketten werden bei allen Textfiltern als `NULL` behandelt. `ItemTag` = `0` gilt als `NULL`. Fehlen `BestBeforeDateFrom` oder `BestBeforeDateTo` (oder sind sie `1900-01-01`), werden Beginn bzw. Ende des **aktuellen Tages** verwendet.\n2. **Vorprüfungen:** Jeder angegebene Filter wird geprüft. Der Aufruf endet mit einer `Error`-Zeile, wenn:\n - `LocId` nicht in `Location` existiert,\n - `ItemTag` nicht `-6` oder `-7` ist,\n - `Ean` kein Barcode (Codetyp 1) in `pixi.ItemCode` ist,\n - `ItemNrInt` keine Shop-Artikelnummer (Codetyp 2) in `pixi.ItemCode` ist,\n - `BinGroup` nicht in `InvBin` existiert,\n - `SupplierNr` nicht in `Suppliers` existiert,\n - `Category` weder zu `TontrArt` noch zu `TontrText` in `TontrArten` passt,\n - `BatchNumber` nicht in `InvBinItem` existiert.\n3. **Report:** Die interne Report-Prozedur `Report_ItemsOnStockWithBatchManagement` wird ausgeführt:\n - Berücksichtigt werden nur Artikel mit dem Tag `-6` (Chargennummer) oder `-7` (MHD).\n - Der Lagerplatzbestand aus `InvBinItem` wird je Artikel, Lagerplatz, Charge und MHD summiert (`QtyInBin`).\n - Der MHD-Filter wird immer angewendet. Enthalten sind Zeilen, deren `BestBeforeDate` zwischen den beiden Daten liegt, sowie Zeilen ohne MHD.\n - Optionale Filter:\n - `BatchNumber`: exakte Chargennummer.\n - `LocId`: Lager des Lagerplatzes.\n - `Ean`: Barcode des Artikels.\n - `ItemNrInt`: Shop-Artikelnummer.\n - `ItemTag`: Der Artikel muss diesen Tag tragen.\n - `SupplierNr`: Der Artikel ist diesem Lieferanten in `AddItems` zugeordnet.\n - `BinGroup`: Lagerplatzgruppe.\n - `Category`: `ConfigType` des Artikels, abgeglichen über Code oder Text.\n4. Die Zeilen werden nach `ItemName` und dann `BinName` sortiert zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BatchNumber` | varchar(50) | Nein | Filter auf exakte Chargennummer. Muss in `InvBinItem` existieren. Leer bedeutet kein Filter. |\n| `BestBeforeDateFrom` | datetime | Nein | Beginn des MHD-Zeitraums. Standard ist der Beginn des aktuellen Tages; nur der Datumsteil wird verwendet. |\n| `BestBeforeDateTo` | datetime | Nein | Ende des MHD-Zeitraums. Standard ist das Ende des aktuellen Tages; nur der Datumsteil wird verwendet. |\n| `LocId` | varchar(3) | Nein | Lager-ID. Nur Lagerplätze dieses Lagers werden berücksichtigt. Muss in `Location` existieren. |\n| `Ean` | varchar(13) | Nein | Barcode (Artikelcode-Typ 1) des Artikels. Muss in `pixi.ItemCode` existieren. |\n| `ItemTag` | int | Nein | Beschränkt auf Artikel mit diesem Tag. `0` oder leer bedeutet kein Filter. |\n| `SupplierNr` | varchar(4) | Nein | Lieferantennummer. Nur diesem Lieferanten zugeordnete Artikel (`AddItems`) werden berücksichtigt. Muss in `Suppliers` existieren. |\n| `BinGroup` | varchar(20) | Nein | Lagerplatzgruppe. Nur Lagerplätze dieser Gruppe werden berücksichtigt. Muss in `InvBin` existieren. |\n| `Category` | varchar(50) | Nein | Artikelkategorie, als Code (`TontrArt`) oder Text (`TontrText`) aus `TontrArten`. Wird mit `ConfigType` des Artikels abgeglichen. |\n| `ItemNrInt` | varchar(50) | Nein | Shop-Artikelnummer (Artikelcode-Typ 2). Muss in `pixi.ItemCode` existieren. |\n\n- **Standard-Datumsbereich ist nur der heutige Tag.** Ohne `BestBeforeDateFrom`/`BestBeforeDateTo` wird nur Bestand mit MHD heute oder ohne MHD geliefert. Für alle Chargen einen weiten Zeitraum übergeben.\n- Die Daten werden an den internen Report als `DATE` übergeben, die Uhrzeit entfällt. Ein `BestBeforeDate` am Endtag mit Uhrzeit nach Mitternacht kann dadurch herausfallen.\n- Die Vorprüfungen prüfen nur, ob irgendwo ein passender Datensatz existiert. So akzeptiert etwa die `Ean`-Prüfung jeden vorhandenen Barcode, nicht nur Barcodes chargenverwalteter Artikel. Ohne Filterwert verlangen sie trotzdem mindestens eine Zeile in der jeweiligen Tabelle. Eine leere Datenbank oder leere Tabelle führt daher zum entsprechenden Fehler mit leerem Wert.\n- Der interne Report baut seine `WHERE`-Klausel als dynamisches SQL auf. SQL-Fehler daraus werden abgefangen und als `Error`-Zeile mit dem Originaltext zurückgegeben.\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten erscheinen.\n- Der Report erzeugt intern zusätzliche Parameter-Spalten (`ParamBatchNumber` usw.). Diese werden nicht an den Aufrufer zurückgegeben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_ItemsOnStockWithBatchManagement"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den Bestand je Artikel, Lagerplatz, Chargennummer und MHD für Artikel mit Chargenverwaltung auf Basis des pixi*-Reports \"Items on stock with BN/BBD\".\n\nStellt den pixi*-Report *Items on stock with BN/BBD* (Chargennummer / Mindesthaltbarkeitsdatum) als API-Call bereit.\n\n1. **Normalisierung:** Leere Zeichenketten werden bei allen Textfiltern als `NULL` behandelt. `ItemTag` = `0` gilt als `NULL`. Fehlen `BestBeforeDateFrom` oder `BestBeforeDateTo` (oder sind sie `1900-01-01`), werden Beginn bzw. Ende des **aktuellen Tages** verwendet.\n2. **Vorprüfungen:** Jeder angegebene Filter wird geprüft. Der Aufruf endet mit einer `Error`-Zeile, wenn:\n - `LocId` nicht in `Location` existiert,\n - `ItemTag` nicht `-6` oder `-7` ist,\n - `Ean` kein Barcode (Codetyp 1) in `pixi.ItemCode` ist,\n - `ItemNrInt` keine Shop-Artikelnummer (Codetyp 2) in `pixi.ItemCode` ist,\n - `BinGroup` nicht in `InvBin` existiert,\n - `SupplierNr` nicht in `Suppliers` existiert,\n - `Category` weder zu `TontrArt` noch zu `TontrText` in `TontrArten` passt,\n - `BatchNumber` nicht in `InvBinItem` existiert.\n3. **Report:** Die interne Report-Prozedur `Report_ItemsOnStockWithBatchManagement` wird ausgeführt:\n - Berücksichtigt werden nur Artikel mit dem Tag `-6` (Chargennummer) oder `-7` (MHD).\n - Der Lagerplatzbestand aus `InvBinItem` wird je Artikel, Lagerplatz, Charge und MHD summiert (`QtyInBin`).\n - Der MHD-Filter wird immer angewendet. Enthalten sind Zeilen, deren `BestBeforeDate` zwischen den beiden Daten liegt, sowie Zeilen ohne MHD.\n - Optionale Filter:\n - `BatchNumber`: exakte Chargennummer.\n - `LocId`: Lager des Lagerplatzes.\n - `Ean`: Barcode des Artikels.\n - `ItemNrInt`: Shop-Artikelnummer.\n - `ItemTag`: Der Artikel muss diesen Tag tragen.\n - `SupplierNr`: Der Artikel ist diesem Lieferanten in `AddItems` zugeordnet.\n - `BinGroup`: Lagerplatzgruppe.\n - `Category`: `ConfigType` des Artikels, abgeglichen über Code oder Text.\n4. Die Zeilen werden nach `ItemName` und dann `BinName` sortiert zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `BatchNumber` | varchar(50) | Nein | Filter auf exakte Chargennummer. Muss in `InvBinItem` existieren. Leer bedeutet kein Filter. |\n| `BestBeforeDateFrom` | datetime | Nein | Beginn des MHD-Zeitraums. Standard ist der Beginn des aktuellen Tages; nur der Datumsteil wird verwendet. |\n| `BestBeforeDateTo` | datetime | Nein | Ende des MHD-Zeitraums. Standard ist das Ende des aktuellen Tages; nur der Datumsteil wird verwendet. |\n| `LocId` | varchar(3) | Nein | Lager-ID. Nur Lagerplätze dieses Lagers werden berücksichtigt. Muss in `Location` existieren. |\n| `Ean` | varchar(13) | Nein | Barcode (Artikelcode-Typ 1) des Artikels. Muss in `pixi.ItemCode` existieren. |\n| `ItemTag` | int | Nein | Beschränkt auf Artikel mit diesem Tag. `0` oder leer bedeutet kein Filter. |\n| `SupplierNr` | varchar(4) | Nein | Lieferantennummer. Nur diesem Lieferanten zugeordnete Artikel (`AddItems`) werden berücksichtigt. Muss in `Suppliers` existieren. |\n| `BinGroup` | varchar(20) | Nein | Lagerplatzgruppe. Nur Lagerplätze dieser Gruppe werden berücksichtigt. Muss in `InvBin` existieren. |\n| `Category` | varchar(50) | Nein | Artikelkategorie, als Code (`TontrArt`) oder Text (`TontrText`) aus `TontrArten`. Wird mit `ConfigType` des Artikels abgeglichen. |\n| `ItemNrInt` | varchar(50) | Nein | Shop-Artikelnummer (Artikelcode-Typ 2). Muss in `pixi.ItemCode` existieren. |\n\n- **Standard-Datumsbereich ist nur der heutige Tag.** Ohne `BestBeforeDateFrom`/`BestBeforeDateTo` wird nur Bestand mit MHD heute oder ohne MHD geliefert. Für alle Chargen einen weiten Zeitraum übergeben.\n- Die Daten werden an den internen Report als `DATE` übergeben, die Uhrzeit entfällt. Ein `BestBeforeDate` am Endtag mit Uhrzeit nach Mitternacht kann dadurch herausfallen.\n- Die Vorprüfungen prüfen nur, ob irgendwo ein passender Datensatz existiert. So akzeptiert etwa die `Ean`-Prüfung jeden vorhandenen Barcode, nicht nur Barcodes chargenverwalteter Artikel. Ohne Filterwert verlangen sie trotzdem mindestens eine Zeile in der jeweiligen Tabelle. Eine leere Datenbank oder leere Tabelle führt daher zum entsprechenden Fehler mit leerem Wert.\n- Der interne Report baut seine `WHERE`-Klausel als dynamisches SQL auf. SQL-Fehler daraus werden abgefangen und als `Error`-Zeile mit dem Originaltext zurückgegeben.\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten erscheinen.\n- Der Report erzeugt intern zusätzliche Parameter-Spalten (`ParamBatchNumber` usw.). Diese werden nicht an den Aufrufer zurückgegeben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReport_ItemsOnStockWithBatchManagement"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4711\n SUP-998\n 100234\n 4006381333931\n Bio Honig 500g\n L2024-0815\n 2025-06-30T00:00:00\n A-01-03\n FOOD\n 24\n \n \n 4711\n SUP-998\n 100234\n 4006381333931\n Bio Honig 500g\n L2024-0901\n 2025-09-15T00:00:00\n A-01-04\n FOOD\n 12\n \n"
}
]
},
{
"name": "pixiSetStock",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 4012345678901\n A-01-02\n \n 25\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt den Bestand eines Artikels auf einem Lagerplatz auf einen absoluten Wert, indem die Differenz als Einbuchung oder Ausbuchung gebucht wird.\n\nSetzt die Menge eines Artikels auf einem Lagerplatz auf `NewStockQty`. Die Menge wird nicht direkt überschrieben. Es wird die Differenz zur aktuellen Menge berechnet und als Lagerbewegung gebucht.\n\nAblauf:\n\n1. Prüft die Einstellung `API_Stock_Movements`. Ist sie nicht aktiviert, wird eine Statuszeile mit `Status` = `ERROR` geliefert und die Verarbeitung beendet.\n2. Prüft, ob `SMORef` eine Lagerbewegungsoperation (`StockMovementOperations.SMOKey`) mit `Application` = `API` ist. Andernfalls wird ein Fehler ausgelöst.\n3. Sucht den Artikel über `EANUPC` = `EanUpc`.\n4. Ermittelt, ob der Artikel Chargennummern bzw. Mindesthaltbarkeitsdaten benötigt (Artikel-Tags `-6` und `-7`). Benötigt der Artikel sie nicht, werden `BatchNumber` und `BestBeforeDate` ignoriert. Benötigt er sie, müssen sie gefüllt sein; sonst wird nichts gebucht.\n5. Sucht den Lagerplatz über `BinName`. Ist `LocId` angegeben, werden nur Lagerplätze dieses Lagers berücksichtigt; sonst wird der erste Lagerplatz mit diesem Namen in einem beliebigen Lager verwendet und dessen Lager für die Buchung übernommen.\n6. Berechnet die Differenz: `NewStockQty` minus Summe von `BinItemQTY` des Artikels auf diesem Lagerplatz (alle Zeilen, unabhängig von Charge oder MHD).\n - Differenz > 0: Einbuchung (`Pixi_InvBinScanIn`) der Differenz.\n - Differenz < 0: Ausbuchung (`Pixi_InvBinTakeOut`) der absoluten Differenz.\n - Differenz = 0: keine Buchung.\n7. Vor der Buchung muss die Kombination aus `SMORef` und `SMTref` in `StockMovementMatching` existieren; sonst wird ein Fehler protokolliert und ausgelöst.\n - Ist `SMTref` nicht angegeben, werden **beide** Werte ersetzt: bei Einbuchung die API-Operation `PutToStock` mit Bewegungstyp `0201`, bei Ausbuchung die API-Operation `TakeOut` mit Bewegungstyp `0301`.\n - Ist `SMTref` angegeben, werden die übergebenen Werte `SMORef` und `SMTref` verwendet.\n8. Abschließend wird der Artikel zur Bestandsneuberechnung und zum Shop-Export eingereiht (`Pixi_ExportItemChangesToShop`), auch wenn nichts gebucht wurde.\n\nDie Prozedur liefert einen Rückgabewert: `0` = verarbeitet, `1` = Artikel nicht gefunden oder benötigte Charge/MHD fehlt, `2` = Lagerplatz nicht gefunden. Im Erfolgsfall wird keine Ergebnismenge geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `EanUpc` | varchar(13) | Ja | EAN/UPC des Artikels (`Items.EANUPC`). |\n| `BinName` | varchar(50) | Ja | Name des Lagerplatzes (`InvBin.BinName`), dessen Bestand gesetzt wird. |\n| `LocId` | varchar(3) | Nein | Lager-ID des Lagerplatzes. Bei `NULL` wird der erste Lagerplatz mit dem Namen in einem beliebigen Lager verwendet. |\n| `NewStockQty` | int | Ja | Zielmenge des Artikels auf dem Lagerplatz. |\n| `Username` | varchar(50) | Nein | Benutzername, der für die Lagerbewegung gespeichert wird. |\n| `SMORef` | int | Nein | Schlüssel der Lagerbewegungsoperation (`StockMovementOperations.SMOKey`). Muss zur Anwendung `API` gehören; faktisch Pflicht. Wird durch `PutToStock`/`TakeOut` ersetzt, wenn `SMTref` fehlt. |\n| `SMTref` | int | Nein | Schlüssel des Lagerbewegungstyps (`StockMovementTypes.SMTKey`). Muss in `StockMovementMatching` mit `SMORef` verknüpft sein. Bei `NULL` wird Typ `0201` (Einbuchung) bzw. `0301` (Ausbuchung) verwendet. |\n| `BatchNumber` | varchar(50) | Nein | Chargennummer. Pflicht bei Artikeln mit Chargen-Tag, sonst ignoriert. |\n| `BestBeforeDate` | datetime | Nein | Mindesthaltbarkeitsdatum. Pflicht bei Artikeln mit MHD-Tag, sonst ignoriert. Der Standardwert `''` entspricht `1900-01-01` und gilt als leer. |\n\n- `SMORef` hat den Standardwert `NULL`, der Aufruf scheitert ohne diesen Parameter aber immer mit *SMO is not assigned to API*. Es muss der Schlüssel einer API-Lagerbewegungsoperation übergeben werden.\n- Die Rückgabewerte `1` und `2` sind nur Rückgabewerte der Prozedur; es wird keine Statuszeile geliefert. Je nach Client sieht ein fehlender Artikel oder Lagerplatz daher wie ein Erfolg aus.\n- Wird `SMTref` weggelassen, dient das übergebene `SMORef` nur der Eingangsprüfung und wird anschließend durch die Operation `PutToStock`/`TakeOut` ersetzt.\n- Die Differenz wird über alle Chargen und MHDs auf dem Lagerplatz berechnet, aber mit der angegebenen `BatchNumber`/`BestBeforeDate` gebucht. Bei Artikeln mit Chargen kann das Ergebnis je Charge von der Erwartung abweichen.\n- `BestBeforeDate` hat den Standardwert `''`, den SQL Server in `1900-01-01` umwandelt. Dieser Wert gilt als leer; Artikel mit MHD-Tag benötigen ein echtes Datum.\n- Ohne `LocId` wird der Lagerplatz per `TOP 1` ohne `ORDER BY` gewählt; existiert der Name in mehreren Lagern, ist die Auswahl nicht deterministisch.\n- Abfragen verwenden `NOLOCK`.\n- Die aufgerufenen Prozeduren `Pixi_InvBinScanIn`/`Pixi_InvBinTakeOut` lehnen Mengen über der Einstellung `MaxStockOperationLimit` ab und laufen in einer eigenen Transaktion; ihre Basisprozeduren liegen nicht vor. Fehler in den Basisprozeduren werden über `log.InsertError` protokolliert und erreichen den Aufrufer möglicherweise nicht.\n- Fehler aus den aufgerufenen Prozeduren landen im CATCH-Block dieses Aufrufs, der einen Eintrag in `LogTable` schreibt und einen Fehler mit dem Inhalt der internen Fehlervariablen auslöst. Bei Fehlern, die nicht von dieser Prozedur selbst stammen, ist diese Meldung leer; der ursprüngliche Fehlertext geht verloren.\n- Beim Fehler *SMT is not matched* entstehen zwei Einträge in `LogTable` (einer vor dem Auslösen, einer im CATCH-Block).\n- Jeder Aufruf, der die Eingangsprüfungen besteht, legt eine Zeile in `pixi.ItemRecalculateStockQueue` an, auch wenn nichts gebucht oder der Artikel nicht gefunden wurde.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetStock"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 4012345678901\n A-01-02\n \n 25\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt den Bestand eines Artikels auf einem Lagerplatz auf einen absoluten Wert, indem die Differenz als Einbuchung oder Ausbuchung gebucht wird.\n\nSetzt die Menge eines Artikels auf einem Lagerplatz auf `NewStockQty`. Die Menge wird nicht direkt überschrieben. Es wird die Differenz zur aktuellen Menge berechnet und als Lagerbewegung gebucht.\n\nAblauf:\n\n1. Prüft die Einstellung `API_Stock_Movements`. Ist sie nicht aktiviert, wird eine Statuszeile mit `Status` = `ERROR` geliefert und die Verarbeitung beendet.\n2. Prüft, ob `SMORef` eine Lagerbewegungsoperation (`StockMovementOperations.SMOKey`) mit `Application` = `API` ist. Andernfalls wird ein Fehler ausgelöst.\n3. Sucht den Artikel über `EANUPC` = `EanUpc`.\n4. Ermittelt, ob der Artikel Chargennummern bzw. Mindesthaltbarkeitsdaten benötigt (Artikel-Tags `-6` und `-7`). Benötigt der Artikel sie nicht, werden `BatchNumber` und `BestBeforeDate` ignoriert. Benötigt er sie, müssen sie gefüllt sein; sonst wird nichts gebucht.\n5. Sucht den Lagerplatz über `BinName`. Ist `LocId` angegeben, werden nur Lagerplätze dieses Lagers berücksichtigt; sonst wird der erste Lagerplatz mit diesem Namen in einem beliebigen Lager verwendet und dessen Lager für die Buchung übernommen.\n6. Berechnet die Differenz: `NewStockQty` minus Summe von `BinItemQTY` des Artikels auf diesem Lagerplatz (alle Zeilen, unabhängig von Charge oder MHD).\n - Differenz > 0: Einbuchung (`Pixi_InvBinScanIn`) der Differenz.\n - Differenz < 0: Ausbuchung (`Pixi_InvBinTakeOut`) der absoluten Differenz.\n - Differenz = 0: keine Buchung.\n7. Vor der Buchung muss die Kombination aus `SMORef` und `SMTref` in `StockMovementMatching` existieren; sonst wird ein Fehler protokolliert und ausgelöst.\n - Ist `SMTref` nicht angegeben, werden **beide** Werte ersetzt: bei Einbuchung die API-Operation `PutToStock` mit Bewegungstyp `0201`, bei Ausbuchung die API-Operation `TakeOut` mit Bewegungstyp `0301`.\n - Ist `SMTref` angegeben, werden die übergebenen Werte `SMORef` und `SMTref` verwendet.\n8. Abschließend wird der Artikel zur Bestandsneuberechnung und zum Shop-Export eingereiht (`Pixi_ExportItemChangesToShop`), auch wenn nichts gebucht wurde.\n\nDie Prozedur liefert einen Rückgabewert: `0` = verarbeitet, `1` = Artikel nicht gefunden oder benötigte Charge/MHD fehlt, `2` = Lagerplatz nicht gefunden. Im Erfolgsfall wird keine Ergebnismenge geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `EanUpc` | varchar(13) | Ja | EAN/UPC des Artikels (`Items.EANUPC`). |\n| `BinName` | varchar(50) | Ja | Name des Lagerplatzes (`InvBin.BinName`), dessen Bestand gesetzt wird. |\n| `LocId` | varchar(3) | Nein | Lager-ID des Lagerplatzes. Bei `NULL` wird der erste Lagerplatz mit dem Namen in einem beliebigen Lager verwendet. |\n| `NewStockQty` | int | Ja | Zielmenge des Artikels auf dem Lagerplatz. |\n| `Username` | varchar(50) | Nein | Benutzername, der für die Lagerbewegung gespeichert wird. |\n| `SMORef` | int | Nein | Schlüssel der Lagerbewegungsoperation (`StockMovementOperations.SMOKey`). Muss zur Anwendung `API` gehören; faktisch Pflicht. Wird durch `PutToStock`/`TakeOut` ersetzt, wenn `SMTref` fehlt. |\n| `SMTref` | int | Nein | Schlüssel des Lagerbewegungstyps (`StockMovementTypes.SMTKey`). Muss in `StockMovementMatching` mit `SMORef` verknüpft sein. Bei `NULL` wird Typ `0201` (Einbuchung) bzw. `0301` (Ausbuchung) verwendet. |\n| `BatchNumber` | varchar(50) | Nein | Chargennummer. Pflicht bei Artikeln mit Chargen-Tag, sonst ignoriert. |\n| `BestBeforeDate` | datetime | Nein | Mindesthaltbarkeitsdatum. Pflicht bei Artikeln mit MHD-Tag, sonst ignoriert. Der Standardwert `''` entspricht `1900-01-01` und gilt als leer. |\n\n- `SMORef` hat den Standardwert `NULL`, der Aufruf scheitert ohne diesen Parameter aber immer mit *SMO is not assigned to API*. Es muss der Schlüssel einer API-Lagerbewegungsoperation übergeben werden.\n- Die Rückgabewerte `1` und `2` sind nur Rückgabewerte der Prozedur; es wird keine Statuszeile geliefert. Je nach Client sieht ein fehlender Artikel oder Lagerplatz daher wie ein Erfolg aus.\n- Wird `SMTref` weggelassen, dient das übergebene `SMORef` nur der Eingangsprüfung und wird anschließend durch die Operation `PutToStock`/`TakeOut` ersetzt.\n- Die Differenz wird über alle Chargen und MHDs auf dem Lagerplatz berechnet, aber mit der angegebenen `BatchNumber`/`BestBeforeDate` gebucht. Bei Artikeln mit Chargen kann das Ergebnis je Charge von der Erwartung abweichen.\n- `BestBeforeDate` hat den Standardwert `''`, den SQL Server in `1900-01-01` umwandelt. Dieser Wert gilt als leer; Artikel mit MHD-Tag benötigen ein echtes Datum.\n- Ohne `LocId` wird der Lagerplatz per `TOP 1` ohne `ORDER BY` gewählt; existiert der Name in mehreren Lagern, ist die Auswahl nicht deterministisch.\n- Abfragen verwenden `NOLOCK`.\n- Die aufgerufenen Prozeduren `Pixi_InvBinScanIn`/`Pixi_InvBinTakeOut` lehnen Mengen über der Einstellung `MaxStockOperationLimit` ab und laufen in einer eigenen Transaktion; ihre Basisprozeduren liegen nicht vor. Fehler in den Basisprozeduren werden über `log.InsertError` protokolliert und erreichen den Aufrufer möglicherweise nicht.\n- Fehler aus den aufgerufenen Prozeduren landen im CATCH-Block dieses Aufrufs, der einen Eintrag in `LogTable` schreibt und einen Fehler mit dem Inhalt der internen Fehlervariablen auslöst. Bei Fehlern, die nicht von dieser Prozedur selbst stammen, ist diese Meldung leer; der ursprüngliche Fehlertext geht verloren.\n- Beim Fehler *SMT is not matched* entstehen zwei Einträge in `LogTable` (einer vor dem Auslösen, einer im CATCH-Block).\n- Jeder Aufruf, der die Eingangsprüfungen besteht, legt eine Zeile in `pixi.ItemRecalculateStockQueue` an, auch wenn nichts gebucht oder der Artikel nicht gefunden wurde.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetStock"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n ERROR\n Setting \"API Calls Stock Movements\" (API_Stock_Movements) is not enabled.\n \n"
}
]
},
{
"name": "pixiSetStockMultiple",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder ändert den Bestand von Artikeln auf Lagerplätzen anhand eines XML-Dokuments und liefert je verarbeitetem Lagerplatz-Eintrag eine Ergebniszeile.\n\nVerarbeitet eine Liste von Artikeln mit Lagerplatz-Einträgen und bucht je Eintrag Lagerbewegungen (Einlagern / Auslagern).\n\n**Ablauf**\n\n1. Prüft die Einstellung `API_Stock_Movements`. Ist sie nicht aktiviert, wird eine einzelne `ERROR`-Zeile geliefert, ansonsten passiert nichts.\n2. Ist `ParameterXML` nicht leer, ersetzt es `XML`. Der gesamte XML-Text wird in Großbuchstaben umgewandelt (Elementnamen **und** Werte).\n3. Das XML wird über `/ITEMSTOCK/ITEM/INVBINS/INVBIN` gelesen. Je `ITEM`: `ITEMKEY`, `ITEMNRINT`, `EANUPC`, `OVERWRITESTOCK`. Je `INVBIN`: `BINNAME`, `STOCK`, `STOCKADD`, `STOCKREMOVE`, `NEUTRALINVENTORY`, `SMTREF`, `SMOREF`, `BATCHNUMBER`, `BESTBEFOREDATE`. Leere Werte für `SMTREF`, `SMOREF`, `BATCHNUMBER` und `BESTBEFOREDATE` gelten als NULL.\n4. Der Artikel wird in dieser Reihenfolge ermittelt: über `ITEMKEY`, dann `ITEMNRINT`, dann `EANUPC`. Artikelschlüssel, Artikelnummer und EAN des gefundenen Artikels werden ergänzt.\n5. Bei `OVERWRITESTOCK` = 1 wird für jeden weiteren Lagerplatz (nach Name) mit positivem Bestand des Artikels, der nicht im XML steht, ein zusätzlicher Eintrag mit Zielbestand 0 angelegt – der Bestand dort wird also geleert.\n6. Übersteigt der höchste Wert von `STOCK` (bzw. `STOCKADD`, wenn `STOCK` leer ist) die Einstellung `MaxStockOperationLimit`, bricht der Aufruf mit einem Fehler ab, bevor Bestand geändert wird.\n7. Jeder Eintrag mit gefundenem Artikel und existierendem Lagerplatznamen wird verarbeitet:\n - Ist der Artikel für Charge (Tag -6) markiert, aber kein `BATCHNUMBER` angegeben, oder für MHD (Tag -7) markiert, aber kein `BESTBEFOREDATE` angegeben, wird der Eintrag übersprungen. Ohne entsprechende Markierung wird der Wert ignoriert.\n - Ist `STOCK` gesetzt, wird die Differenz zum aktuellen Bestand auf allen Lagerplätzen dieses Namens berechnet. Eine positive Differenz wird eingelagert, eine negative ausgelagert; bei Differenz 0 entsteht die Erfolgsmeldung `No stock change needed`.\n - Andernfalls werden `STOCKADD` / `STOCKREMOVE` wie angegeben gebucht.\n - Fehlt `SMOREF` oder `SMTREF`, werden Standardwerte verwendet: Lagerbewegungsoperation `API`/`PutToStock` mit Bewegungsart `0201` beim Einlagern, `API`/`TakeOut` mit Bewegungsart `0301` beim Auslagern.\n - Die Kombination aus SMO und SMT muss in der Zuordnungstabelle der Lagerbewegungen existieren, sonst schlägt der Eintrag mit einer Fehlermeldung fehl.\n - Die Buchung erfolgt über `Pixi_InvBinScanIn` (Einlagern) bzw. `Pixi_InvBinTakeOut` (Auslagern) mit dem übergebenen `Username`, Charge und MHD.\n8. Je Eintrag wird eine Ergebniszeile geliefert: verarbeitete Einträge mit Erfolgs- oder Fehlermeldung, Einträge mit nicht gefundenem Artikel oder Lagerplatz sowie übrige, nicht verarbeitete Einträge mit der Charge/MHD-Meldung.\n9. Alle ermittelten Artikel werden in `pixi.ItemRecalculateStockQueue` zur Bestandsneuberechnung und zum Export eingereiht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | Nein | XML-Dokument mit Artikeln und deren Lagerplatz-Einträgen (Wurzel `ITEMSTOCK`). Wird ignoriert, wenn `ParameterXML` nicht leer ist. |\n| `ParameterXML` | varchar(max) | Nein | Alternative zu `XML` mit gleicher Struktur. Ist es nicht leer, wird es statt `XML` verwendet. |\n| `Username` | varchar(50) | Nein | Benutzername, der für die Lagerbewegungen erfasst wird. NULL wird durch `pipiSetStockMultiple` ersetzt. |\n\n- **Keine Gesamttransaktion:** Jede Buchung wird einzeln durch `Pixi_InvBinScanIn` / `Pixi_InvBinTakeOut` festgeschrieben. Ein Aufruf kann teilweise erfolgreich sein; `status` ist je Zeile zu prüfen.\n- Das XML wird vollständig in Großbuchstaben umgewandelt, Lagerplatznamen und Chargen werden also in Großschreibung verarbeitet.\n- Numerische Elemente besser weglassen statt leer zu senden: ein leeres `STOCK` kann als 0 gelesen werden und setzt den Bestand dann auf 0.\n- Lagerplätze werden nur über `BINNAME` identifiziert. Existiert derselbe Name in mehreren Lagern, wird der aktuelle Bestand über alle summiert und das Lager von einem beliebigen passenden Lagerplatz (`TOP 1`) genommen. Die Einstellung `FilterStockOperationsWithLocation` wird gelesen, aber nicht verwendet.\n- `OVERWRITESTOCK` = 1 leert den Artikel auf allen anderen Lagerplätzen mit positivem Bestand, in allen Lagern.\n- `MaxStockOperationLimit` wird hier nur für `STOCK`/`STOCKADD` geprüft. Die aufgerufenen Prozeduren prüfen die Menge erneut (auch beim Auslagern); ein solcher Fehler wird abgefangen, protokolliert und als Zeile mit `status` 0 und leerem `Error` geliefert.\n- `STOCK` nicht mit `STOCKADD`/`STOCKREMOVE` im selben Eintrag kombinieren: die expliziten Werte können zusätzlich gebucht werden. Die berechnete Differenz wird zudem zwischen Einträgen nicht zurückgesetzt, was Einträge ohne `STOCK` beeinflussen kann.\n- Ist die SMO nicht der Anwendung `API` zugeordnet, wird nur eine Informationsmeldung (Schweregrad 10) gesendet; die Zeile erscheint dann mit der irreführenden Charge/MHD-Meldung.\n- Einträge ohne zu buchende Menge (z. B. nur `NEUTRALINVENTORY`, das gelesen, aber nicht verwendet wird) erhalten ebenfalls die Charge/MHD-Meldung.\n- Im Ergebnis zeigen `STOCKADD`/`STOCKREMOVE`/`SMOREF`/`SMTREF` die Eingabewerte, nicht die berechneten oder Standardwerte. `Reason` ist bei XML-Einträgen leer und enthält bei durch `OVERWRITESTOCK` ergänzten Einträgen den Grund des Lagerplatz-Bestands. Das Ergebnis hat keine definierte Sortierung.\n- SMT/SMO-Fehlzuordnungen und abgefangene Fehler werden in `LogTable` geschrieben. Die Meldungstexte der Buchungsprozeduren stammen aus `Pixi_InvBinScanIn_Base` / `Pixi_InvBinTakeOut_Base`, die nicht beigefügt sind.\n- Lesezugriffe erfolgen mit `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetStockMultiple"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt oder ändert den Bestand von Artikeln auf Lagerplätzen anhand eines XML-Dokuments und liefert je verarbeitetem Lagerplatz-Eintrag eine Ergebniszeile.\n\nVerarbeitet eine Liste von Artikeln mit Lagerplatz-Einträgen und bucht je Eintrag Lagerbewegungen (Einlagern / Auslagern).\n\n**Ablauf**\n\n1. Prüft die Einstellung `API_Stock_Movements`. Ist sie nicht aktiviert, wird eine einzelne `ERROR`-Zeile geliefert, ansonsten passiert nichts.\n2. Ist `ParameterXML` nicht leer, ersetzt es `XML`. Der gesamte XML-Text wird in Großbuchstaben umgewandelt (Elementnamen **und** Werte).\n3. Das XML wird über `/ITEMSTOCK/ITEM/INVBINS/INVBIN` gelesen. Je `ITEM`: `ITEMKEY`, `ITEMNRINT`, `EANUPC`, `OVERWRITESTOCK`. Je `INVBIN`: `BINNAME`, `STOCK`, `STOCKADD`, `STOCKREMOVE`, `NEUTRALINVENTORY`, `SMTREF`, `SMOREF`, `BATCHNUMBER`, `BESTBEFOREDATE`. Leere Werte für `SMTREF`, `SMOREF`, `BATCHNUMBER` und `BESTBEFOREDATE` gelten als NULL.\n4. Der Artikel wird in dieser Reihenfolge ermittelt: über `ITEMKEY`, dann `ITEMNRINT`, dann `EANUPC`. Artikelschlüssel, Artikelnummer und EAN des gefundenen Artikels werden ergänzt.\n5. Bei `OVERWRITESTOCK` = 1 wird für jeden weiteren Lagerplatz (nach Name) mit positivem Bestand des Artikels, der nicht im XML steht, ein zusätzlicher Eintrag mit Zielbestand 0 angelegt – der Bestand dort wird also geleert.\n6. Übersteigt der höchste Wert von `STOCK` (bzw. `STOCKADD`, wenn `STOCK` leer ist) die Einstellung `MaxStockOperationLimit`, bricht der Aufruf mit einem Fehler ab, bevor Bestand geändert wird.\n7. Jeder Eintrag mit gefundenem Artikel und existierendem Lagerplatznamen wird verarbeitet:\n - Ist der Artikel für Charge (Tag -6) markiert, aber kein `BATCHNUMBER` angegeben, oder für MHD (Tag -7) markiert, aber kein `BESTBEFOREDATE` angegeben, wird der Eintrag übersprungen. Ohne entsprechende Markierung wird der Wert ignoriert.\n - Ist `STOCK` gesetzt, wird die Differenz zum aktuellen Bestand auf allen Lagerplätzen dieses Namens berechnet. Eine positive Differenz wird eingelagert, eine negative ausgelagert; bei Differenz 0 entsteht die Erfolgsmeldung `No stock change needed`.\n - Andernfalls werden `STOCKADD` / `STOCKREMOVE` wie angegeben gebucht.\n - Fehlt `SMOREF` oder `SMTREF`, werden Standardwerte verwendet: Lagerbewegungsoperation `API`/`PutToStock` mit Bewegungsart `0201` beim Einlagern, `API`/`TakeOut` mit Bewegungsart `0301` beim Auslagern.\n - Die Kombination aus SMO und SMT muss in der Zuordnungstabelle der Lagerbewegungen existieren, sonst schlägt der Eintrag mit einer Fehlermeldung fehl.\n - Die Buchung erfolgt über `Pixi_InvBinScanIn` (Einlagern) bzw. `Pixi_InvBinTakeOut` (Auslagern) mit dem übergebenen `Username`, Charge und MHD.\n8. Je Eintrag wird eine Ergebniszeile geliefert: verarbeitete Einträge mit Erfolgs- oder Fehlermeldung, Einträge mit nicht gefundenem Artikel oder Lagerplatz sowie übrige, nicht verarbeitete Einträge mit der Charge/MHD-Meldung.\n9. Alle ermittelten Artikel werden in `pixi.ItemRecalculateStockQueue` zur Bestandsneuberechnung und zum Export eingereiht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | Nein | XML-Dokument mit Artikeln und deren Lagerplatz-Einträgen (Wurzel `ITEMSTOCK`). Wird ignoriert, wenn `ParameterXML` nicht leer ist. |\n| `ParameterXML` | varchar(max) | Nein | Alternative zu `XML` mit gleicher Struktur. Ist es nicht leer, wird es statt `XML` verwendet. |\n| `Username` | varchar(50) | Nein | Benutzername, der für die Lagerbewegungen erfasst wird. NULL wird durch `pipiSetStockMultiple` ersetzt. |\n\n- **Keine Gesamttransaktion:** Jede Buchung wird einzeln durch `Pixi_InvBinScanIn` / `Pixi_InvBinTakeOut` festgeschrieben. Ein Aufruf kann teilweise erfolgreich sein; `status` ist je Zeile zu prüfen.\n- Das XML wird vollständig in Großbuchstaben umgewandelt, Lagerplatznamen und Chargen werden also in Großschreibung verarbeitet.\n- Numerische Elemente besser weglassen statt leer zu senden: ein leeres `STOCK` kann als 0 gelesen werden und setzt den Bestand dann auf 0.\n- Lagerplätze werden nur über `BINNAME` identifiziert. Existiert derselbe Name in mehreren Lagern, wird der aktuelle Bestand über alle summiert und das Lager von einem beliebigen passenden Lagerplatz (`TOP 1`) genommen. Die Einstellung `FilterStockOperationsWithLocation` wird gelesen, aber nicht verwendet.\n- `OVERWRITESTOCK` = 1 leert den Artikel auf allen anderen Lagerplätzen mit positivem Bestand, in allen Lagern.\n- `MaxStockOperationLimit` wird hier nur für `STOCK`/`STOCKADD` geprüft. Die aufgerufenen Prozeduren prüfen die Menge erneut (auch beim Auslagern); ein solcher Fehler wird abgefangen, protokolliert und als Zeile mit `status` 0 und leerem `Error` geliefert.\n- `STOCK` nicht mit `STOCKADD`/`STOCKREMOVE` im selben Eintrag kombinieren: die expliziten Werte können zusätzlich gebucht werden. Die berechnete Differenz wird zudem zwischen Einträgen nicht zurückgesetzt, was Einträge ohne `STOCK` beeinflussen kann.\n- Ist die SMO nicht der Anwendung `API` zugeordnet, wird nur eine Informationsmeldung (Schweregrad 10) gesendet; die Zeile erscheint dann mit der irreführenden Charge/MHD-Meldung.\n- Einträge ohne zu buchende Menge (z. B. nur `NEUTRALINVENTORY`, das gelesen, aber nicht verwendet wird) erhalten ebenfalls die Charge/MHD-Meldung.\n- Im Ergebnis zeigen `STOCKADD`/`STOCKREMOVE`/`SMOREF`/`SMTREF` die Eingabewerte, nicht die berechneten oder Standardwerte. `Reason` ist bei XML-Einträgen leer und enthält bei durch `OVERWRITESTOCK` ergänzten Einträgen den Grund des Lagerplatz-Bestands. Das Ergebnis hat keine definierte Sortierung.\n- SMT/SMO-Fehlzuordnungen und abgefangene Fehler werden in `LogTable` geschrieben. Die Meldungstexte der Buchungsprozeduren stammen aus `Pixi_InvBinScanIn_Base` / `Pixi_InvBinTakeOut_Base`, die nicht beigefügt sind.\n- Lesezugriffe erfolgen mit `NOLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetStockMultiple"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n ART-1001\n 1234\n 4006381333931\n A-01-01\n 25\n 0\n 0\n \n true\n No stock change needed\n \n \n ART-1002\n 1235\n 4006381333948\n Z-99-99\n 5\n Bin not found\n \n false\n \n"
}
]
},
{
"name": "pixiSetStockMultiple_AH",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt, erhöht oder verringert den Bestand mehrerer Artikel auf Lagerplätzen in einem Aufruf anhand eines XML-Dokuments mit Bestandswerten je Lagerplatz.\n\nVerarbeitet ein XML-Dokument mit einem oder mehreren Artikeln und deren Lagerplätzen und bucht die Bestandsänderungen als Lagerbewegungen.\n\n**Eingabe**\n- Ist `ParameterXML` nicht leer, ersetzt es `XML`.\n- Der gesamte XML-Text wird vor dem Parsen in Großbuchstaben umgewandelt. Das betrifft Elementnamen und alle Werte, auch Lagerplatznamen und Chargennummern.\n- Zeilen werden aus `/ITEMSTOCK/ITEM/INVBINS/INVBIN` gelesen. Jedes `INVBIN` ergibt eine Zeile. Die Artikelfelder `ITEMNRINT`, `ITEMKEY`, `EANUPC` und `OVERWRITESTOCK` stammen aus dem übergeordneten `ITEM`.\n- Leere Werte für `SMTREF`, `SMOREF`, `BATCHNUMBER` und `BESTBEFOREDATE` werden als NULL behandelt.\n\n**Artikelermittlung**\nDer Artikel wird in dieser Reihenfolge ermittelt:\n1. über `ITEMKEY`\n2. über `ITEMNRINT`, falls kein Schlüssel gefunden wurde\n3. über `EANUPC`, falls weiterhin kein Schlüssel gefunden wurde\n\nArtikelschlüssel, Artikelnummer und EAN werden anschließend aus dem Artikelstamm übernommen.\n\n**Überschreibmodus**\nIst `OVERWRITESTOCK` = 1 für einen Artikel, wird für jeden weiteren Lagerplatz dieses Artikels eine Zeile mit Zielbestand 0 ergänzt. Das gilt für Lagerplätze, die aktuell Bestand haben (Summe > 0) und nicht im XML stehen. Diese Lagerplätze werden geleert.\n\n**Verarbeitung je Zeile**\nNur Zeilen mit ermitteltem Artikel und existierendem Lagerplatznamen werden einzeln verarbeitet:\n- Hat der Artikel das Chargen-Tag, aber die Zeile keine `BATCHNUMBER`, wird die Zeile ohne Meldung übersprungen. Ohne Chargen-Tag wird eine angegebene Charge ignoriert. Dieselbe Regel gilt für das MHD-Tag und `BESTBEFOREDATE`.\n- Ist `STOCK` angegeben, wird die Differenz zum aktuellen Bestand auf dem Lagerplatz berechnet. Eine positive Differenz wird zu `StockAdd`, eine negative zu `StockRemove`. Ohne Differenz wird eine Zeile mit Status 1 und `No stock change needed` erfasst.\n- Fehlt `SMOREF` oder `SMTREF`, werden Standardwerte verwendet:\n - für Zugänge: Operation `API`/`PutToStock` und Bewegungsart `0201`\n - für Abgänge: Operation `API`/`TakeOut` und Bewegungsart `0301`\n- Die Lagerbewegungsoperation muss zur Anwendung `API` gehören, und das Paar aus Operation und Bewegungsart muss in der Zuordnungstabelle für Lagerbewegungen existieren. Andernfalls wird die Zeile nicht gebucht.\n- Bei `StockAdd` > 0 wird mit `Pixi_InvBinScanIn` eingebucht. Andernfalls wird bei `StockRemove` > 0 mit `Pixi_InvBinTakeOut` ausgebucht. Als Lager dient die `BinLocID` des ersten Lagerplatzes mit diesem Namen.\n\n**Ergebnis und Folgeverarbeitung**\n- Die abschließende Ergebnismenge listet die verarbeiteten Zeilen mit Status und Meldung.\n- Zeilen, deren Artikel oder Lagerplatz nicht gefunden wurde, werden mit Status 0 ergänzt.\n- Alle ermittelten Artikel werden zur Bestandsneuberechnung und zum Export in `pixi.ItemRecalculateStockQueue` eingetragen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | Nein | XML-Dokument mit Artikeln, deren Lagerplätzen und Bestandswerten. Wird ignoriert, wenn `ParameterXML` nicht leer ist. |\n| `ParameterXML` | varchar(max) | Nein | Alternative Eingabe mit derselben Struktur wie `XML`. Hat Vorrang vor `XML`, wenn nicht leer. |\n| `Username` | varchar(50) | Nein | Benutzername, der bei den Lagerbewegungen protokolliert wird. |\n\n- **Zusätzliche Ergebnismengen:** Für jede verarbeitete Zeile führt der Code ein `SELECT` ohne Alias auf den aktuellen `SMTREF`-Wert aus. Jedes davon wird als eigene Ergebnismenge geliefert. Die eigentliche Status-Ergebnismenge kommt daher zuletzt, nach je einer zusätzlichen Ergebnismenge pro verarbeiteter Zeile. Auszuwerten ist das letzte `SqlRowSetN`.\n- **Großschreibung:** Da das XML in Großbuchstaben umgewandelt wird, werden Chargennummern in Großbuchstaben gebucht.\n- **Element `STOCK`:** Ein leeres `` wird zu 0 und leert den Lagerplatz. Ist kein absoluter Wert gemeint, das Element weglassen.\n- **Kombination von Feldern:** Bei Angabe von `STOCK` überschreibt die berechnete Differenz nur eines der Felder `StockAdd`/`StockRemove`. Ein im XML übergebenes `STOCKADD` kann daher bei negativer oder fehlender Differenz trotzdem eine Einbuchung auslösen. `STOCK` daher nicht mit `STOCKADD`/`STOCKREMOVE` kombinieren.\n- **Variable `@delta` wird nicht je Zeile zurückgesetzt:** Bei Zeilen ohne `STOCK` verwenden die Prüfungen die Differenz der vorherigen Zeile. Bei der ersten solchen Zeile ist der Wert NULL, die SMO-Prüfung entfällt dann.\n- **Fehlende Zeilen im Ergebnis:** Zeilen, die wegen fehlender Charge oder fehlendem MHD übersprungen werden, und Zeilen, die an der Prüfung \"SMO not assigned to API\" scheitern, erzeugen keine Ergebniszeile.\n- **Nicht ausgewertet:** `NEUTRALINVENTORY` wird gelesen, aber nicht verwendet. Die Einstellung `FilterStockOperationsWithLocation` wird gelesen, aber nicht weitergegeben.\n- **Aktueller Bestand:** Die Differenz wird über alle Lagerplätze gleichen Namens und über alle Chargen berechnet. Das Lager wird per `TOP 1` ohne Sortierung ermittelt, doppelte Lagerplatznamen in verschiedenen Lagern können daher zu unerwarteten Buchungen führen.\n- **Transaktionen:** Es gibt keine Gesamttransaktion. Jede Buchung läuft in einer eigenen Transaktion innerhalb von `Pixi_InvBinScanIn`/`Pixi_InvBinTakeOut`. Eine fehlerhafte Zeile macht frühere Zeilen nicht rückgängig.\n- **Aufgerufene Prozeduren:** `Pixi_InvBinScanIn_Base` und `Pixi_InvBinTakeOut_Base` liegen nicht vor, deren genaue Prüfungen und Meldungen sind daher unbekannt. Es gilt das Mengenlimit `MaxStockOperationLimit`.\n- Stammdaten werden mit `NOLOCK` gelesen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetStockMultiple_AH"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt, erhöht oder verringert den Bestand mehrerer Artikel auf Lagerplätzen in einem Aufruf anhand eines XML-Dokuments mit Bestandswerten je Lagerplatz.\n\nVerarbeitet ein XML-Dokument mit einem oder mehreren Artikeln und deren Lagerplätzen und bucht die Bestandsänderungen als Lagerbewegungen.\n\n**Eingabe**\n- Ist `ParameterXML` nicht leer, ersetzt es `XML`.\n- Der gesamte XML-Text wird vor dem Parsen in Großbuchstaben umgewandelt. Das betrifft Elementnamen und alle Werte, auch Lagerplatznamen und Chargennummern.\n- Zeilen werden aus `/ITEMSTOCK/ITEM/INVBINS/INVBIN` gelesen. Jedes `INVBIN` ergibt eine Zeile. Die Artikelfelder `ITEMNRINT`, `ITEMKEY`, `EANUPC` und `OVERWRITESTOCK` stammen aus dem übergeordneten `ITEM`.\n- Leere Werte für `SMTREF`, `SMOREF`, `BATCHNUMBER` und `BESTBEFOREDATE` werden als NULL behandelt.\n\n**Artikelermittlung**\nDer Artikel wird in dieser Reihenfolge ermittelt:\n1. über `ITEMKEY`\n2. über `ITEMNRINT`, falls kein Schlüssel gefunden wurde\n3. über `EANUPC`, falls weiterhin kein Schlüssel gefunden wurde\n\nArtikelschlüssel, Artikelnummer und EAN werden anschließend aus dem Artikelstamm übernommen.\n\n**Überschreibmodus**\nIst `OVERWRITESTOCK` = 1 für einen Artikel, wird für jeden weiteren Lagerplatz dieses Artikels eine Zeile mit Zielbestand 0 ergänzt. Das gilt für Lagerplätze, die aktuell Bestand haben (Summe > 0) und nicht im XML stehen. Diese Lagerplätze werden geleert.\n\n**Verarbeitung je Zeile**\nNur Zeilen mit ermitteltem Artikel und existierendem Lagerplatznamen werden einzeln verarbeitet:\n- Hat der Artikel das Chargen-Tag, aber die Zeile keine `BATCHNUMBER`, wird die Zeile ohne Meldung übersprungen. Ohne Chargen-Tag wird eine angegebene Charge ignoriert. Dieselbe Regel gilt für das MHD-Tag und `BESTBEFOREDATE`.\n- Ist `STOCK` angegeben, wird die Differenz zum aktuellen Bestand auf dem Lagerplatz berechnet. Eine positive Differenz wird zu `StockAdd`, eine negative zu `StockRemove`. Ohne Differenz wird eine Zeile mit Status 1 und `No stock change needed` erfasst.\n- Fehlt `SMOREF` oder `SMTREF`, werden Standardwerte verwendet:\n - für Zugänge: Operation `API`/`PutToStock` und Bewegungsart `0201`\n - für Abgänge: Operation `API`/`TakeOut` und Bewegungsart `0301`\n- Die Lagerbewegungsoperation muss zur Anwendung `API` gehören, und das Paar aus Operation und Bewegungsart muss in der Zuordnungstabelle für Lagerbewegungen existieren. Andernfalls wird die Zeile nicht gebucht.\n- Bei `StockAdd` > 0 wird mit `Pixi_InvBinScanIn` eingebucht. Andernfalls wird bei `StockRemove` > 0 mit `Pixi_InvBinTakeOut` ausgebucht. Als Lager dient die `BinLocID` des ersten Lagerplatzes mit diesem Namen.\n\n**Ergebnis und Folgeverarbeitung**\n- Die abschließende Ergebnismenge listet die verarbeiteten Zeilen mit Status und Meldung.\n- Zeilen, deren Artikel oder Lagerplatz nicht gefunden wurde, werden mit Status 0 ergänzt.\n- Alle ermittelten Artikel werden zur Bestandsneuberechnung und zum Export in `pixi.ItemRecalculateStockQueue` eingetragen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | Nein | XML-Dokument mit Artikeln, deren Lagerplätzen und Bestandswerten. Wird ignoriert, wenn `ParameterXML` nicht leer ist. |\n| `ParameterXML` | varchar(max) | Nein | Alternative Eingabe mit derselben Struktur wie `XML`. Hat Vorrang vor `XML`, wenn nicht leer. |\n| `Username` | varchar(50) | Nein | Benutzername, der bei den Lagerbewegungen protokolliert wird. |\n\n- **Zusätzliche Ergebnismengen:** Für jede verarbeitete Zeile führt der Code ein `SELECT` ohne Alias auf den aktuellen `SMTREF`-Wert aus. Jedes davon wird als eigene Ergebnismenge geliefert. Die eigentliche Status-Ergebnismenge kommt daher zuletzt, nach je einer zusätzlichen Ergebnismenge pro verarbeiteter Zeile. Auszuwerten ist das letzte `SqlRowSetN`.\n- **Großschreibung:** Da das XML in Großbuchstaben umgewandelt wird, werden Chargennummern in Großbuchstaben gebucht.\n- **Element `STOCK`:** Ein leeres `` wird zu 0 und leert den Lagerplatz. Ist kein absoluter Wert gemeint, das Element weglassen.\n- **Kombination von Feldern:** Bei Angabe von `STOCK` überschreibt die berechnete Differenz nur eines der Felder `StockAdd`/`StockRemove`. Ein im XML übergebenes `STOCKADD` kann daher bei negativer oder fehlender Differenz trotzdem eine Einbuchung auslösen. `STOCK` daher nicht mit `STOCKADD`/`STOCKREMOVE` kombinieren.\n- **Variable `@delta` wird nicht je Zeile zurückgesetzt:** Bei Zeilen ohne `STOCK` verwenden die Prüfungen die Differenz der vorherigen Zeile. Bei der ersten solchen Zeile ist der Wert NULL, die SMO-Prüfung entfällt dann.\n- **Fehlende Zeilen im Ergebnis:** Zeilen, die wegen fehlender Charge oder fehlendem MHD übersprungen werden, und Zeilen, die an der Prüfung \"SMO not assigned to API\" scheitern, erzeugen keine Ergebniszeile.\n- **Nicht ausgewertet:** `NEUTRALINVENTORY` wird gelesen, aber nicht verwendet. Die Einstellung `FilterStockOperationsWithLocation` wird gelesen, aber nicht weitergegeben.\n- **Aktueller Bestand:** Die Differenz wird über alle Lagerplätze gleichen Namens und über alle Chargen berechnet. Das Lager wird per `TOP 1` ohne Sortierung ermittelt, doppelte Lagerplatznamen in verschiedenen Lagern können daher zu unerwarteten Buchungen führen.\n- **Transaktionen:** Es gibt keine Gesamttransaktion. Jede Buchung läuft in einer eigenen Transaktion innerhalb von `Pixi_InvBinScanIn`/`Pixi_InvBinTakeOut`. Eine fehlerhafte Zeile macht frühere Zeilen nicht rückgängig.\n- **Aufgerufene Prozeduren:** `Pixi_InvBinScanIn_Base` und `Pixi_InvBinTakeOut_Base` liegen nicht vor, deren genaue Prüfungen und Meldungen sind daher unbekannt. Es gilt das Mengenlimit `MaxStockOperationLimit`.\n- Stammdaten werden mit `NOLOCK` gelesen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetStockMultiple_AH"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 12\n \n"
}
]
},
{
"name": "pixiSetSupplierStockMultiple",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n mad56650mad60230]]>\n \n \n A-10-A-1\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Gleicht den Bestand der Artikel eines Lieferanten auf einem Lagerplatz mit einer Liste aus Lieferanten-Artikelnummern und Mengen ab und liefert den resultierenden Bestand.\n\nÜbernimmt eine Liste aus Lieferanten-Artikelnummern mit Zielmengen und versucht, den Bestand des angegebenen Lagerplatzes daran anzugleichen.\n\n1. Das XML in `Items` wird ausgewertet: Jeder Knoten `/ITEMS/ITEM` liefert `ItemNrSuppl` und `Quantity`.\n2. Der Lagerplatz wird in `InvBin` über `Location` (`BinLocID`) und `BinName` gesucht. Wird kein Lagerplatz gefunden, wird eine einzelne Zeile mit `Code` = `500` und `Message` = `Bin Not Found` geliefert; sonst geschieht nichts.\n3. Die zu ändernden Artikel werden ermittelt:\n - Artikel aus dem XML, deren `ItemNrSuppl` zu einem `AddItems`-Eintrag des Lieferanten `SupplNr` passt, deren Artikel aktiv ist (`Items.Enabled = 1`) und deren Zielmenge von der aktuellen Gesamtmenge auf dem Lagerplatz abweicht (fehlender Bestand zählt als 0).\n - Artikel desselben Lieferanten, die aktuell Bestand auf dem Lagerplatz haben, aber **nicht** im XML enthalten sind. Ihre Zielmenge ist 0, sie sollen also vom Lagerplatz entfernt werden. Das Flag `Enabled` wird hier nicht geprüft.\n4. Für jeden dieser Artikel wird `pixiSetStock` mit der `EANUPC` des Artikels, dem `BinName`, der Zielmenge und `Username` ausgeführt.\n5. Abschließend wird je Artikel eine Zeile mit Lieferanten-Artikelnummer und der nun auf dem Lagerplatz vorhandenen Gesamtmenge geliefert, beschränkt auf Artikel mit `AddItems`-Eintrag für `SupplNr`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Items` | xml | Ja | Liste der Lieferanten-Artikelnummern mit Zielmengen für den Lagerplatz. Wurzel `ITEMS`, je Artikel ein `ITEM` mit `ItemNrSuppl` und `Quantity` (Ganzzahl). |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer (`AddItems.SupplNr`), über die die Lieferanten-Artikelnummern aufgelöst und die Artikel auf dem Lagerplatz eingeschränkt werden. |\n| `Location` | varchar(3) | Nein | Lager-ID (`InvBin.BinLocID`), über die der Lagerplatz gesucht wird. Sie wird nicht an `pixiSetStock` weitergegeben. |\n| `BinName` | varchar(50) | Ja | Name des Lagerplatzes (`InvBin.BinName`), dessen Bestand abgeglichen wird. |\n| `Username` | varchar(50) | Nein | Benutzername, der für die Lagerbewegungen an `pixiSetStock` übergeben wird. |\n\n- **Der Bestand wird in der Praxis nicht geändert.** Laut einem Kommentar im Code schlägt der Aufruf von `pixiSetStock` immer fehl, weil kein `SMORef` übergeben wird. `pixiSetStock` löst `Error Message: API pipiSetStockMultiple: SMO is not assigned to API!` aus, sobald `SMORef` NULL ist, schreibt einen Eintrag in `LogTable` und löst den Fehler erneut aus. Die äußere Prozedur hat keine Fehlerbehandlung. Sie fährt mit dem nächsten Artikel fort, und die Fehlermeldungen erreichen den Aufrufer als `SqlMessage`-Einträge neben der abschließenden Ergebnismenge.\n- Ist die Einstellung `API_Stock_Movements` deaktiviert, liefert `pixiSetStock` für jeden zu ändernden Artikel eine zusätzliche Statuszeile (`Status`/`StatusMessage`), statt einen Fehler auszulösen. Diese Zeilen kommen als zusätzliche Ergebnismengen vor der abschließenden Bestandsliste und verschieben die Nummerierung der `SqlRowSet`.\n- `pixiSetStock` wird ohne Lager aufgerufen. Der Lagerplatz wird dort nur über `BinName` gesucht; existiert derselbe Name in mehreren Lagern, kann ein anderer Lagerplatz als der hier geprüfte verwendet werden.\n- Artikel werden über `EANUPC` an `pixiSetStock` übergeben. Artikel ohne EAN oder mit doppelter EAN lassen sich nicht zuverlässig ansprechen.\n- Fehlt in einem `ITEM` des XML die `ItemNrSuppl`, liefert die `NOT IN`-Prüfung keine Zeilen, und es werden keine Artikel vom Lagerplatz entfernt.\n- Artikel mit fehlender oder nicht numerischer `Quantity` werden bei der Aktualisierung ignoriert.\n- Alle Lesezugriffe verwenden `NOLOCK`. Um die Schleife liegt keine Transaktion.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetSupplierStockMultiple"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n mad56650mad60230]]>\n \n \n A-10-A-1\n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Gleicht den Bestand der Artikel eines Lieferanten auf einem Lagerplatz mit einer Liste aus Lieferanten-Artikelnummern und Mengen ab und liefert den resultierenden Bestand.\n\nÜbernimmt eine Liste aus Lieferanten-Artikelnummern mit Zielmengen und versucht, den Bestand des angegebenen Lagerplatzes daran anzugleichen.\n\n1. Das XML in `Items` wird ausgewertet: Jeder Knoten `/ITEMS/ITEM` liefert `ItemNrSuppl` und `Quantity`.\n2. Der Lagerplatz wird in `InvBin` über `Location` (`BinLocID`) und `BinName` gesucht. Wird kein Lagerplatz gefunden, wird eine einzelne Zeile mit `Code` = `500` und `Message` = `Bin Not Found` geliefert; sonst geschieht nichts.\n3. Die zu ändernden Artikel werden ermittelt:\n - Artikel aus dem XML, deren `ItemNrSuppl` zu einem `AddItems`-Eintrag des Lieferanten `SupplNr` passt, deren Artikel aktiv ist (`Items.Enabled = 1`) und deren Zielmenge von der aktuellen Gesamtmenge auf dem Lagerplatz abweicht (fehlender Bestand zählt als 0).\n - Artikel desselben Lieferanten, die aktuell Bestand auf dem Lagerplatz haben, aber **nicht** im XML enthalten sind. Ihre Zielmenge ist 0, sie sollen also vom Lagerplatz entfernt werden. Das Flag `Enabled` wird hier nicht geprüft.\n4. Für jeden dieser Artikel wird `pixiSetStock` mit der `EANUPC` des Artikels, dem `BinName`, der Zielmenge und `Username` ausgeführt.\n5. Abschließend wird je Artikel eine Zeile mit Lieferanten-Artikelnummer und der nun auf dem Lagerplatz vorhandenen Gesamtmenge geliefert, beschränkt auf Artikel mit `AddItems`-Eintrag für `SupplNr`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Items` | xml | Ja | Liste der Lieferanten-Artikelnummern mit Zielmengen für den Lagerplatz. Wurzel `ITEMS`, je Artikel ein `ITEM` mit `ItemNrSuppl` und `Quantity` (Ganzzahl). |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer (`AddItems.SupplNr`), über die die Lieferanten-Artikelnummern aufgelöst und die Artikel auf dem Lagerplatz eingeschränkt werden. |\n| `Location` | varchar(3) | Nein | Lager-ID (`InvBin.BinLocID`), über die der Lagerplatz gesucht wird. Sie wird nicht an `pixiSetStock` weitergegeben. |\n| `BinName` | varchar(50) | Ja | Name des Lagerplatzes (`InvBin.BinName`), dessen Bestand abgeglichen wird. |\n| `Username` | varchar(50) | Nein | Benutzername, der für die Lagerbewegungen an `pixiSetStock` übergeben wird. |\n\n- **Der Bestand wird in der Praxis nicht geändert.** Laut einem Kommentar im Code schlägt der Aufruf von `pixiSetStock` immer fehl, weil kein `SMORef` übergeben wird. `pixiSetStock` löst `Error Message: API pipiSetStockMultiple: SMO is not assigned to API!` aus, sobald `SMORef` NULL ist, schreibt einen Eintrag in `LogTable` und löst den Fehler erneut aus. Die äußere Prozedur hat keine Fehlerbehandlung. Sie fährt mit dem nächsten Artikel fort, und die Fehlermeldungen erreichen den Aufrufer als `SqlMessage`-Einträge neben der abschließenden Ergebnismenge.\n- Ist die Einstellung `API_Stock_Movements` deaktiviert, liefert `pixiSetStock` für jeden zu ändernden Artikel eine zusätzliche Statuszeile (`Status`/`StatusMessage`), statt einen Fehler auszulösen. Diese Zeilen kommen als zusätzliche Ergebnismengen vor der abschließenden Bestandsliste und verschieben die Nummerierung der `SqlRowSet`.\n- `pixiSetStock` wird ohne Lager aufgerufen. Der Lagerplatz wird dort nur über `BinName` gesucht; existiert derselbe Name in mehreren Lagern, kann ein anderer Lagerplatz als der hier geprüfte verwendet werden.\n- Artikel werden über `EANUPC` an `pixiSetStock` übergeben. Artikel ohne EAN oder mit doppelter EAN lassen sich nicht zuverlässig ansprechen.\n- Fehlt in einem `ITEM` des XML die `ItemNrSuppl`, liefert die `NOT IN`-Prüfung keine Zeilen, und es werden keine Artikel vom Lagerplatz entfernt.\n- Artikel mit fehlender oder nicht numerischer `Quantity` werden bei der Aktualisierung ignoriert.\n- Alle Lesezugriffe verwenden `NOLOCK`. Um die Schleife liegt keine Transaktion.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetSupplierStockMultiple"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n mad566\n 50\n \n \n mad602\n 30\n \n"
}
]
},
{
"name": "pixiShopConnectionSetStockNonReported",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt die Exportmarkierung der Bestandsänderungen in InvBinItemLog zurück, sodass alle Änderungen ab einem Datum erneut an den Shop gemeldet werden.\n\nSteuert, welche Bestandsänderungen im Bestandsänderungsprotokoll `InvBinItemLog` als noch nicht an den Shop gemeldet gelten.\n\n1. Wird `Since` nicht übergeben, werden das aktuelle Datum und die aktuelle Uhrzeit (`GETDATE()`) verwendet. Damit werden alle Einträge als gemeldet markiert.\n2. Alle noch nicht gemeldeten Einträge (`ReportedDate IS NULL`) mit `UpdateDate` vor `Since` werden als gemeldet markiert. `ReportedDate` erhält dabei den Wert von `UpdateDate`.\n3. Alle Einträge mit `UpdateDate` ab `Since` (einschließlich) werden als nicht gemeldet markiert. `ReportedDate` wird auf `NULL` gesetzt, auch wenn sie bereits gemeldet waren.\n4. Zurückgegeben wird die Anzahl der jetzt nicht gemeldeten Protokolleinträge. Das ist die Anzahl der Bestandsänderungen, die noch an den Shop zu exportieren sind.\n\nBerücksichtigt werden nur normale Artikel. Laut Code-Kommentar werden Stücklisten (Bundles) noch nicht unterstützt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Nein | Zeitpunkt, ab dem Bestandsänderungen erneut an den Shop gemeldet werden. Änderungen davor werden als gemeldet markiert. Fehlt der Wert oder ist er `NULL`, werden das aktuelle Datum und die aktuelle Uhrzeit verwendet. |\n\n- Ohne `Since` wird das gesamte Protokoll als gemeldet markiert. Danach steht für den Shop-Export keine offene Bestandsänderung mehr an.\n- Die beiden `UPDATE`-Anweisungen laufen nicht in einer expliziten Transaktion.\n- Die abschließende Zählung erfolgt mit `NOLOCK` und kann daher nicht festgeschriebene Änderungen enthalten.\n- Gezählt werden Protokolleinträge, nicht einzelne Artikel oder Lagerplätze.\n- Bei großen Protokollen können die Updates viele Zeilen betreffen und entsprechend länger dauern.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiShopConnectionSetStockNonReported"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Setzt die Exportmarkierung der Bestandsänderungen in InvBinItemLog zurück, sodass alle Änderungen ab einem Datum erneut an den Shop gemeldet werden.\n\nSteuert, welche Bestandsänderungen im Bestandsänderungsprotokoll `InvBinItemLog` als noch nicht an den Shop gemeldet gelten.\n\n1. Wird `Since` nicht übergeben, werden das aktuelle Datum und die aktuelle Uhrzeit (`GETDATE()`) verwendet. Damit werden alle Einträge als gemeldet markiert.\n2. Alle noch nicht gemeldeten Einträge (`ReportedDate IS NULL`) mit `UpdateDate` vor `Since` werden als gemeldet markiert. `ReportedDate` erhält dabei den Wert von `UpdateDate`.\n3. Alle Einträge mit `UpdateDate` ab `Since` (einschließlich) werden als nicht gemeldet markiert. `ReportedDate` wird auf `NULL` gesetzt, auch wenn sie bereits gemeldet waren.\n4. Zurückgegeben wird die Anzahl der jetzt nicht gemeldeten Protokolleinträge. Das ist die Anzahl der Bestandsänderungen, die noch an den Shop zu exportieren sind.\n\nBerücksichtigt werden nur normale Artikel. Laut Code-Kommentar werden Stücklisten (Bundles) noch nicht unterstützt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `Since` | datetime | Nein | Zeitpunkt, ab dem Bestandsänderungen erneut an den Shop gemeldet werden. Änderungen davor werden als gemeldet markiert. Fehlt der Wert oder ist er `NULL`, werden das aktuelle Datum und die aktuelle Uhrzeit verwendet. |\n\n- Ohne `Since` wird das gesamte Protokoll als gemeldet markiert. Danach steht für den Shop-Export keine offene Bestandsänderung mehr an.\n- Die beiden `UPDATE`-Anweisungen laufen nicht in einer expliziten Transaktion.\n- Die abschließende Zählung erfolgt mit `NOLOCK` und kann daher nicht festgeschriebene Änderungen enthalten.\n- Gezählt werden Protokolleinträge, nicht einzelne Artikel oder Lagerplätze.\n- Bei großen Protokollen können die Updates viele Zeilen betreffen und entsprechend länger dauern.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiShopConnectionSetStockNonReported"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1532\n \n"
}
]
},
{
"name": "pixiShopLinkGetItemsStock",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den verfügbaren Bestand aller Artikel für den Shop-Bestandsexport, optional ohne Nullbestände und ohne Bestand in ausgeschlossenen Lagerplatzgruppen.\n\nLiefert je Artikel eine Zeile mit der internen Artikelnummer und der Menge, die an den Shop exportiert werden kann.\n\nDas Verhalten hängt von der Einstellung `OldStockExport` ab:\n\n- **`OldStockExport` = 1:** Die Prozedur sammelt `Quantity` aus `Items` in einer temporären Tabelle, liefert aber **keine Ergebnismenge** (das abschließende `SELECT` steht nur im anderen Zweig).\n- **Sonst (Standard):** Die verfügbare Menge wird je Artikel als `ItemQtyIBIExportStock_locations` abzüglich eines Abzugs berechnet:\n - `ItemQtyOpenOrderLines`, wenn Reservierungen deaktiviert sind (`ReservePrepaymentOrders` <> `1`) oder `ExportAvailableStock_WhenReservationsAreEnabled` = 1 ist, und zugleich `StockExportUsePhysicalStock` = `0` ist und der Artikel kein Bundle ist;\n - `ItemQtyOpenReservations`, wenn Reservierungen aktiv sind, `StockExportUsePhysicalStock` = `0` ist und der Artikel kein Bundle ist;\n - kein Abzug (0) in allen anderen Fällen (Export des physischen Bestands oder Bundle-Artikel).\n\nFilter und Korrekturen (nicht-Legacy-Zweig):\n\n1. Bei `ExcludeZeros` = 1 bleiben nur Artikel mit einer berechneten Menge größer 0. `NULL` wird als 0 behandelt (alle Artikel).\n2. Ist `ExcludeBinGroups` angegeben (kommagetrennte Liste von Lagerplatzgruppen), wird der Bestand je Artikel auf Lagerplätzen dieser Gruppen aus `InvBinItemLog` summiert und abgezogen. Für Bundles, deren Komponenten auf diesen Lagerplätzen liegen, ist der Abzug das Minimum über die Komponenten von `CEILING(Komponentenmenge / Menge im Bundle)`. Die Zuordnung zur Ergebniszeile erfolgt über den Artikelcode mit `CodeTypeId` = 2 (Shop-Artikelnummer) gegen `ItemNrInt`.\n3. Negative Mengen werden auf 0 gesetzt.\n\nDie Zeilen werden ohne definierte Sortierung geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ExcludeZeros` | bit | Nein | Bei 1 werden nur Artikel mit einer berechneten Menge größer 0 geliefert. NULL wird als 0 behandelt. |\n| `ExcludeBinGroups` | varchar(max) | Nein | Kommagetrennte Liste von Lagerplatzgruppen (`InvBin.BinGroup`), deren Bestand von der verfügbaren Menge abgezogen wird. Leere Einträge werden ignoriert, Leerzeichen um die Einträge entfernt. |\n\n- Ist die Einstellung `OldStockExport` = 1, liefert der Aufruf **gar keine Zeilen**; `ExcludeZeros` und `ExcludeBinGroups` haben dann keine sichtbare Wirkung.\n- `ExcludeZeros` wird **vor** dem Abzug der Lagerplatzgruppen und vor dem Begrenzen auf 0 angewendet. Artikel können daher bei `ExcludeZeros` = 1 und gesetztem `ExcludeBinGroups` trotzdem mit `AvailableQty` = 0 erscheinen.\n- Der Abzug der Lagerplatzgruppen vergleicht `pixi.ItemCode.Code` (Codetyp 2, Shop-Artikelnummer) mit `Items.ItemNrInt`. Weichen diese Nummern bei einem Artikel ab, wird für ihn nichts abgezogen.\n- Einstellungen werden über `fpixi_GetSetting` gelesen; eine fehlende Einstellung gilt als `0`.\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Ohne Paging liefert der Aufruf alle Artikel, was bei großen Sortimenten eine umfangreiche Antwort ergibt.\n- Ein großer Block älterer Logik ist im Code auskommentiert und wird nicht ausgeführt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiShopLinkGetItemsStock"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den verfügbaren Bestand aller Artikel für den Shop-Bestandsexport, optional ohne Nullbestände und ohne Bestand in ausgeschlossenen Lagerplatzgruppen.\n\nLiefert je Artikel eine Zeile mit der internen Artikelnummer und der Menge, die an den Shop exportiert werden kann.\n\nDas Verhalten hängt von der Einstellung `OldStockExport` ab:\n\n- **`OldStockExport` = 1:** Die Prozedur sammelt `Quantity` aus `Items` in einer temporären Tabelle, liefert aber **keine Ergebnismenge** (das abschließende `SELECT` steht nur im anderen Zweig).\n- **Sonst (Standard):** Die verfügbare Menge wird je Artikel als `ItemQtyIBIExportStock_locations` abzüglich eines Abzugs berechnet:\n - `ItemQtyOpenOrderLines`, wenn Reservierungen deaktiviert sind (`ReservePrepaymentOrders` <> `1`) oder `ExportAvailableStock_WhenReservationsAreEnabled` = 1 ist, und zugleich `StockExportUsePhysicalStock` = `0` ist und der Artikel kein Bundle ist;\n - `ItemQtyOpenReservations`, wenn Reservierungen aktiv sind, `StockExportUsePhysicalStock` = `0` ist und der Artikel kein Bundle ist;\n - kein Abzug (0) in allen anderen Fällen (Export des physischen Bestands oder Bundle-Artikel).\n\nFilter und Korrekturen (nicht-Legacy-Zweig):\n\n1. Bei `ExcludeZeros` = 1 bleiben nur Artikel mit einer berechneten Menge größer 0. `NULL` wird als 0 behandelt (alle Artikel).\n2. Ist `ExcludeBinGroups` angegeben (kommagetrennte Liste von Lagerplatzgruppen), wird der Bestand je Artikel auf Lagerplätzen dieser Gruppen aus `InvBinItemLog` summiert und abgezogen. Für Bundles, deren Komponenten auf diesen Lagerplätzen liegen, ist der Abzug das Minimum über die Komponenten von `CEILING(Komponentenmenge / Menge im Bundle)`. Die Zuordnung zur Ergebniszeile erfolgt über den Artikelcode mit `CodeTypeId` = 2 (Shop-Artikelnummer) gegen `ItemNrInt`.\n3. Negative Mengen werden auf 0 gesetzt.\n\nDie Zeilen werden ohne definierte Sortierung geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ExcludeZeros` | bit | Nein | Bei 1 werden nur Artikel mit einer berechneten Menge größer 0 geliefert. NULL wird als 0 behandelt. |\n| `ExcludeBinGroups` | varchar(max) | Nein | Kommagetrennte Liste von Lagerplatzgruppen (`InvBin.BinGroup`), deren Bestand von der verfügbaren Menge abgezogen wird. Leere Einträge werden ignoriert, Leerzeichen um die Einträge entfernt. |\n\n- Ist die Einstellung `OldStockExport` = 1, liefert der Aufruf **gar keine Zeilen**; `ExcludeZeros` und `ExcludeBinGroups` haben dann keine sichtbare Wirkung.\n- `ExcludeZeros` wird **vor** dem Abzug der Lagerplatzgruppen und vor dem Begrenzen auf 0 angewendet. Artikel können daher bei `ExcludeZeros` = 1 und gesetztem `ExcludeBinGroups` trotzdem mit `AvailableQty` = 0 erscheinen.\n- Der Abzug der Lagerplatzgruppen vergleicht `pixi.ItemCode.Code` (Codetyp 2, Shop-Artikelnummer) mit `Items.ItemNrInt`. Weichen diese Nummern bei einem Artikel ab, wird für ihn nichts abgezogen.\n- Einstellungen werden über `fpixi_GetSetting` gelesen; eine fehlende Einstellung gilt als `0`.\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen; das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Ohne Paging liefert der Aufruf alle Artikel, was bei großen Sortimenten eine umfangreiche Antwort ergibt.\n- Ein großer Block älterer Logik ist im Code auskommentiert und wird nicht ausgeführt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiShopLinkGetItemsStock"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 100245\n 17\n \n \n 100246\n 0\n \n"
}
]
},
{
"name": "pixiShopLinkGetItemsStockRange",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den exportierbaren verfügbaren Bestand und Mindestbestand der Artikel, seitenweise nach Artikelschlüssel, zum Abgleich der Shop-Bestände.\n\nLiefert je Artikel eine Zeile mit dem verfügbaren Bestand für den Bestandsexport an einen Shop. Das Verhalten hängt von den Einstellungen `OldStockExport`, `StockExportUsePhysicalStock`, `ReservePrepaymentOrders` und `ExportAvailableStock_WhenReservationsAreEnabled` ab. Eine fehlende Einstellung gilt als `0`.\n\nStandardwerte der Parameter: `FromItemKey` NULL wird zu `0`, `RowCount` NULL wird zu `1000`, `ExcludeZeros` NULL wird zu `0`.\n\n**Standardmodus** (`OldStockExport` ist nicht `1`):\n\n- Es werden nur Artikel mit `ItemKey >= FromItemKey` gelesen. Höchstens `RowCount` Zeilen werden geliefert, aufsteigend sortiert nach `ItemKey`.\n- `AvailableQty` ist der vorberechnete Exportbestand des Artikels (`ItemQtyIBIExportStock_locations`) abzüglich eines Abzugs:\n - Die Menge offener Auftragspositionen (`ItemQtyOpenOrderLines`), wenn Reservierungen deaktiviert sind oder wenn sie aktiv sind und `ExportAvailableStock_WhenReservationsAreEnabled` = `1` ist. Dies gilt nur, wenn `StockExportUsePhysicalStock` = `0` ist und der Artikel kein Bundle ist.\n - Die offenen Reservierungen (`ItemQtyOpenReservations`), wenn Reservierungen aktiv sind und die andere Einstellung nicht `1` ist. Auch dies gilt nur, wenn `StockExportUsePhysicalStock` = `0` ist und der Artikel kein Bundle ist.\n - Kein Abzug in allen anderen Fällen: physischer Bestand wird verwendet oder der Artikel ist ein Bundle.\n- Mit `ExcludeZeros` = `1` werden nur Artikel mit `AvailableQty > 0` geliefert.\n- Mit `ExcludeZeros` = `0` werden alle Artikel im Bereich geliefert und negative Mengen auf `0` gesetzt.\n\n**Alter Modus** (`OldStockExport` = `1`):\n\n- Liefert `ItemNrInt`, `Quantity` als `AvailableQty` (NULL wird zu 0) und `MinStockQty` für alle Artikel.\n- Es gibt keine Spalte `ItemKey`, kein Paging und keine Sortierung.\n- Mit `ExcludeZeros` = `1` werden Artikel mit Menge `0` ausgelassen.\n\n**Paging:** Im Standardmodus erneut aufrufen mit `FromItemKey` = zuletzt geliefertes `ItemKey` + 1, bis weniger als `RowCount` Zeilen zurückkommen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromItemKey` | int | Nein | Kleinster zu liefernder `ItemKey` (einschließlich). NULL bedeutet `0`. Wird im alten Modus ignoriert. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. NULL bedeutet `1000`. Wird im alten Modus ignoriert. |\n| `ExcludeZeros` | bit | Nein | Steuert, ob Artikel ohne Bestand ausgelassen werden. NULL bedeutet `0`. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten enthalten sein.\n- Die Mengen stammen aus vorberechneten Spalten der Tabelle `Items` (`ItemQtyIBIExportStock_locations`, `ItemQtyOpenOrderLines`, `ItemQtyOpenReservations`). Welche Lager oder Lagerplätze darin enthalten sind, wird an anderer Stelle festgelegt und ist in dieser Prozedur nicht sichtbar.\n- **Unterschiede im alten Modus:**\n - `FromItemKey` und `RowCount` werden ignoriert und alle Artikel in einem Aufruf geliefert.\n - `ItemKey` fehlt im Ergebnis.\n - Bei `ExcludeZeros` = `1` werden negative Mengen weiterhin geliefert.\n - Bei `ExcludeZeros` = `0` werden negative Mengen nicht auf 0 gesetzt.\n- Im Standardmodus mit `ExcludeZeros` = `1` entfallen auch Artikel, deren berechnete Menge NULL ist.\n- `RowCount` = `0` liefert keine Zeilen. Ein negativer Wert führt zu einem SQL-Fehler bei `TOP`.\n- Der Wert von `OldStockExport` wird in `int` umgewandelt. Ein nicht numerischer Einstellungswert würde zu einem Konvertierungsfehler führen.\n- Der große auskommentierte Altcode im Quelltext hat keine Wirkung.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiShopLinkGetItemsStockRange"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert den exportierbaren verfügbaren Bestand und Mindestbestand der Artikel, seitenweise nach Artikelschlüssel, zum Abgleich der Shop-Bestände.\n\nLiefert je Artikel eine Zeile mit dem verfügbaren Bestand für den Bestandsexport an einen Shop. Das Verhalten hängt von den Einstellungen `OldStockExport`, `StockExportUsePhysicalStock`, `ReservePrepaymentOrders` und `ExportAvailableStock_WhenReservationsAreEnabled` ab. Eine fehlende Einstellung gilt als `0`.\n\nStandardwerte der Parameter: `FromItemKey` NULL wird zu `0`, `RowCount` NULL wird zu `1000`, `ExcludeZeros` NULL wird zu `0`.\n\n**Standardmodus** (`OldStockExport` ist nicht `1`):\n\n- Es werden nur Artikel mit `ItemKey >= FromItemKey` gelesen. Höchstens `RowCount` Zeilen werden geliefert, aufsteigend sortiert nach `ItemKey`.\n- `AvailableQty` ist der vorberechnete Exportbestand des Artikels (`ItemQtyIBIExportStock_locations`) abzüglich eines Abzugs:\n - Die Menge offener Auftragspositionen (`ItemQtyOpenOrderLines`), wenn Reservierungen deaktiviert sind oder wenn sie aktiv sind und `ExportAvailableStock_WhenReservationsAreEnabled` = `1` ist. Dies gilt nur, wenn `StockExportUsePhysicalStock` = `0` ist und der Artikel kein Bundle ist.\n - Die offenen Reservierungen (`ItemQtyOpenReservations`), wenn Reservierungen aktiv sind und die andere Einstellung nicht `1` ist. Auch dies gilt nur, wenn `StockExportUsePhysicalStock` = `0` ist und der Artikel kein Bundle ist.\n - Kein Abzug in allen anderen Fällen: physischer Bestand wird verwendet oder der Artikel ist ein Bundle.\n- Mit `ExcludeZeros` = `1` werden nur Artikel mit `AvailableQty > 0` geliefert.\n- Mit `ExcludeZeros` = `0` werden alle Artikel im Bereich geliefert und negative Mengen auf `0` gesetzt.\n\n**Alter Modus** (`OldStockExport` = `1`):\n\n- Liefert `ItemNrInt`, `Quantity` als `AvailableQty` (NULL wird zu 0) und `MinStockQty` für alle Artikel.\n- Es gibt keine Spalte `ItemKey`, kein Paging und keine Sortierung.\n- Mit `ExcludeZeros` = `1` werden Artikel mit Menge `0` ausgelassen.\n\n**Paging:** Im Standardmodus erneut aufrufen mit `FromItemKey` = zuletzt geliefertes `ItemKey` + 1, bis weniger als `RowCount` Zeilen zurückkommen.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `FromItemKey` | int | Nein | Kleinster zu liefernder `ItemKey` (einschließlich). NULL bedeutet `0`. Wird im alten Modus ignoriert. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. NULL bedeutet `1000`. Wird im alten Modus ignoriert. |\n| `ExcludeZeros` | bit | Nein | Steuert, ob Artikel ohne Bestand ausgelassen werden. NULL bedeutet `0`. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten enthalten sein.\n- Die Mengen stammen aus vorberechneten Spalten der Tabelle `Items` (`ItemQtyIBIExportStock_locations`, `ItemQtyOpenOrderLines`, `ItemQtyOpenReservations`). Welche Lager oder Lagerplätze darin enthalten sind, wird an anderer Stelle festgelegt und ist in dieser Prozedur nicht sichtbar.\n- **Unterschiede im alten Modus:**\n - `FromItemKey` und `RowCount` werden ignoriert und alle Artikel in einem Aufruf geliefert.\n - `ItemKey` fehlt im Ergebnis.\n - Bei `ExcludeZeros` = `1` werden negative Mengen weiterhin geliefert.\n - Bei `ExcludeZeros` = `0` werden negative Mengen nicht auf 0 gesetzt.\n- Im Standardmodus mit `ExcludeZeros` = `1` entfallen auch Artikel, deren berechnete Menge NULL ist.\n- `RowCount` = `0` liefert keine Zeilen. Ein negativer Wert führt zu einem SQL-Fehler bei `TOP`.\n- Der Wert von `OldStockExport` wird in `int` umgewandelt. Ein nicht numerischer Einstellungswert würde zu einem Konvertierungsfehler führen.\n- Der große auskommentierte Altcode im Quelltext hat keine Wirkung.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiShopLinkGetItemsStockRange"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1001\n ART-10001\n 25\n 5\n \n \n 1002\n ART-10002\n 0\n 0\n \n"
}
]
}
]
},
{
"name": "Suppliers",
"item": [
{
"name": "pixiCreateDelivery",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine Lieferantenlieferung (Wareneingang) mit Status NEW an, entweder aus einer bestätigten Lieferantenbestellung oder aus per XML übergebenen Artikelzeilen.\n\nDer Aufruf legt einen Lieferungskopf in `SDelHeader` (Status `NEW`) und die zugehörigen Positionen in `SDelDetail` an. Es gibt zwei Modi, gesteuert über `OrderNr`.\n\n**Kopfwerte**\n- Ohne `ParameterXML` werden die einfachen Parameter verwendet.\n- Mit `ParameterXML` ersetzen die Werte des einzigen Knotens `/CREATE_DELIVERY/Delivery` die Werte `LocID` (Standard `001`), `OrderNr` (Standard `0`), `UserName` (Standard `API`), die Notiz und die externe Bestellnummer. `SupplNr` aus dem XML hat Vorrang, sonst gilt der Parameter `SupplNr`. `ExternalReceiptNr` kann nur im XML übergeben werden. Ist die `LocID` unbekannt, wird eine Fehlerzeile geliefert.\n\n**Modus 1: `OrderNr` <> 0 (Vorlage aus Lieferantenbestellung)**\n1. Der Lieferant wird aus der Bestellung ermittelt (`pixi.SupplierOrder.InternalNumber` = `OrderNr`). Deren Lieferlager muss `LocID` entsprechen.\n2. Die Bestellung muss einen lieferbaren Status haben: bestätigt (`IsConfirmed`) bei Einstellung `ConfirmOrderedDocumentOnDelivery` = `0`, bestellt oder bestätigt (`IsOrderedConfirmed`) bei `1`.\n3. Es darf noch keine Lieferung im Status `NEW` existieren, die die Bestellnummer referenziert.\n4. Die Lieferung wird über `Pixi_CreateSDeliveryByTemplate` erzeugt. Sie erhält je Bestellposition mit offener Menge (bestellt minus geliefert minus nicht geliefert) eine Position. Die gelieferte Menge ist `0`, Preis und Rabatt stammen aus der Bestellposition.\n\n**Modus 2: `OrderNr` = 0 (freie Lieferung / XML-Positionen)**\n1. Der Lieferant (`SupplNr`) muss angegeben sein und existieren.\n2. Jeder Knoten `ITEMS/Item` wird über `AddItems` dieses Lieferanten einem Artikel zugeordnet, per `ItemNrInt`, `EAN` oder `ItemNrSuppl`. Zeilen ohne passenden Artikel werden als fehlgeschlagen gemeldet.\n3. Eine Zeile mit `InternalNumber` wird der Bestellung mit dieser internen Nummer zugeordnet. Eine Zeile nur mit `ExternalCode` wird der Bestellung mit diesem externen Code zugeordnet. Es zählen nur Bestellungen mit Lieferlager `LocID`, und der Artikel wird in den Bestellpositionen gesucht.\n4. Zeilen, die eine Zuordnungsregel verletzen (`Error01`–`Error07`), werden als fehlgeschlagen gemeldet und nicht geliefert. Zeilen ohne `InternalNumber` und `ExternalCode` werden ohne Bezug zu einer Bestellposition geliefert.\n5. Für jede verbleibende Zeile gilt:\n - `Ordered` ist der XML-Wert, falls ungleich 0, sonst die Menge der Bestellposition.\n - `SupplPrice` ist der XML-Wert, sonst der Preis der Bestellposition.\n - `Delivered` wird mit der Bestelleinheit des Artikels multipliziert, wenn beim Lieferanten `UsePackingUnitAtCreateDelivery` gesetzt ist.\n - Der Rabatt ist 0.\n6. Das Kopffeld `PurchaseOrderNr` enthält eine kommagetrennte Liste aller zugeordneten Bestellnummern. Wurde keine Bestellung zugeordnet, enthält es die externe Bestellnummer ohne abschließendes `;`.\n7. Bei fehlgeschlagenen Zeilen wird ein Block `Failed To Import Line Items:` mit diesen Zeilen an die Lieferungsnotiz angehängt. Die Notiz ist insgesamt auf 8000 Zeichen begrenzt.\n8. Ohne Positionen wird nur ein Kopf angelegt.\n\n**Ergebnis**\n- Ergebnismenge 1: der angelegte Lieferungskopf.\n- Ergebnismenge 2: die Positionen, ergänzt um die Kennungen aus der Anfrage.\n- Ergebnismenge 3 (nur bei XML-Positionen in Modus 2): die fehlgeschlagenen Zeilen.\n\nBei Validierungsfehlern wird statt dieser Ergebnismengen eine einzelne Zeile mit der Spalte `ERROR` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | Nein | Lager der Lieferung. Wird durch `LocID` im XML überschrieben. |\n| `OrderNr` | int | Nein | Interne Nummer der Lieferantenbestellung. `0` legt eine freie Lieferung aus XML-Positionen an; jeder andere Wert legt die Lieferung aus dieser Bestellung als Vorlage an. Wird durch `OrderNr` im XML überschrieben. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Bei `OrderNr` = 0 erforderlich, sofern nicht im XML angegeben. Bei `OrderNr` <> 0 wird der Lieferant der Bestellung verwendet. |\n| `SuplierOrderNRExternal` | varchar(8000) | Nein | Externe Bestellnummer, Ersatzwert für `PurchaseOrderNr`, wenn keine Bestellung zugeordnet wird. Ein abschließendes `;` wird entfernt. Faktisch nur ohne XML wirksam. |\n| `UserName` | varchar(50) | Nein | Benutzer, der als Ersteller und letzter Bearbeiter gespeichert wird. Wird durch `Username` im XML überschrieben. |\n| `Note` | ntext | Nein | Notiz zur Lieferung, auf 8000 Zeichen gekürzt. Mit XML wird sie durch die XML-Notiz ersetzt; im Vorlagenmodus dient sie als Ersatz bei leerer XML-Notiz. |\n| `ParameterXML` | xml | Nein | Optionales XML mit genau einem Kopf `CREATE_DELIVERY/Delivery` und, bei `OrderNr` = 0, Positionen unter `ITEMS/Item`. |\n\n- **Keine Transaktion.** Kopf und Positionen werden in dieser Prozedur nacheinander ohne explizite Transaktion eingefügt. Ein Laufzeitfehler mittendrin kann einen Kopf mit nur einem Teil der Positionen hinterlassen. Der Vorlagenweg verwendet nur für die Positionen eine eigene Transaktion.\n- **Vorlagenweg ändert den Bestellstatus.** Bei `ConfirmOrderedDocumentOnDelivery` = `1` setzt `Pixi_CreateSDeliveryByTemplate` die Lieferantenbestellung auf den bestätigten Status. Fehler dieser Prozedur werden als `ERROR --- …` ausgelöst.\n- **Prüfung auf offene Lieferung ist ein Teilstring-Vergleich.** Die Prüfung auf eine bestehende `NEW`-Lieferung sucht die Bestellnummer als Text in `SDelHextOrderNr`. Bestellung `123` wird daher auch durch eine offene Lieferung zu Bestellung `1234` blockiert.\n- **`ExternalReceiptNr`** wird nur aus dem XML gelesen. Duplikate je Lieferant werden abgewiesen.\n- **`SuplierOrderNRExternal` wird meist überschrieben.** Mit XML wird der Wert bei `OrderNr` = 0 auf `NULL` gesetzt. Bei `OrderNr` <> 0 wird er gar nicht weitergegeben. Wirksam ist er daher nur ohne XML, als Ersatzwert für `PurchaseOrderNr`.\n- **Vorrang der Notiz.** Mit XML ersetzt die Notiz aus dem XML (oder ein Leerstring) den Parameter `Note`. Im Vorlagenmodus wird bei leerer XML-Notiz auf den Parameter `Note` zurückgegriffen.\n- **`LocID` wird nur auf dem XML-Weg geprüft.** Ohne XML und mit `OrderNr` = 0 wird auch bei unbekannter `LocID` ein Kopf angelegt.\n- **Ignorierte XML-Elemente.** `ItemName` und `ItemKey` in den XML-Positionen werden gelesen, aber ignoriert. Name und Schlüssel stammen immer aus den Artikelstammdaten.\n- **Eine Anfragezeile kann mehrere Lieferpositionen erzeugen.** Steht der Artikel mehrfach in der zugeordneten Bestellung, entsteht je Bestellposition eine Lieferposition, jeweils mit der vollen Liefermenge.\n- **Error02 bei geteilten externen Codes.** Die Zuordnung per `ExternalCode` findet auch Bestellungen anderer Lieferanten am selben Lager, und solche Zeilen werden mit `Error02` abgewiesen.\n- **Ungesicherte Lesezugriffe.** Die meisten Lesezugriffe verwenden `NOLOCK`.\n- **Nummerierung in Kommentaren.** Kommentare im Code nennen die Menge der fehlgeschlagenen Zeilen \"result set 4\", tatsächlich ist es die dritte gelieferte Ergebnismenge.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateDelivery"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine Lieferantenlieferung (Wareneingang) mit Status NEW an, entweder aus einer bestätigten Lieferantenbestellung oder aus per XML übergebenen Artikelzeilen.\n\nDer Aufruf legt einen Lieferungskopf in `SDelHeader` (Status `NEW`) und die zugehörigen Positionen in `SDelDetail` an. Es gibt zwei Modi, gesteuert über `OrderNr`.\n\n**Kopfwerte**\n- Ohne `ParameterXML` werden die einfachen Parameter verwendet.\n- Mit `ParameterXML` ersetzen die Werte des einzigen Knotens `/CREATE_DELIVERY/Delivery` die Werte `LocID` (Standard `001`), `OrderNr` (Standard `0`), `UserName` (Standard `API`), die Notiz und die externe Bestellnummer. `SupplNr` aus dem XML hat Vorrang, sonst gilt der Parameter `SupplNr`. `ExternalReceiptNr` kann nur im XML übergeben werden. Ist die `LocID` unbekannt, wird eine Fehlerzeile geliefert.\n\n**Modus 1: `OrderNr` <> 0 (Vorlage aus Lieferantenbestellung)**\n1. Der Lieferant wird aus der Bestellung ermittelt (`pixi.SupplierOrder.InternalNumber` = `OrderNr`). Deren Lieferlager muss `LocID` entsprechen.\n2. Die Bestellung muss einen lieferbaren Status haben: bestätigt (`IsConfirmed`) bei Einstellung `ConfirmOrderedDocumentOnDelivery` = `0`, bestellt oder bestätigt (`IsOrderedConfirmed`) bei `1`.\n3. Es darf noch keine Lieferung im Status `NEW` existieren, die die Bestellnummer referenziert.\n4. Die Lieferung wird über `Pixi_CreateSDeliveryByTemplate` erzeugt. Sie erhält je Bestellposition mit offener Menge (bestellt minus geliefert minus nicht geliefert) eine Position. Die gelieferte Menge ist `0`, Preis und Rabatt stammen aus der Bestellposition.\n\n**Modus 2: `OrderNr` = 0 (freie Lieferung / XML-Positionen)**\n1. Der Lieferant (`SupplNr`) muss angegeben sein und existieren.\n2. Jeder Knoten `ITEMS/Item` wird über `AddItems` dieses Lieferanten einem Artikel zugeordnet, per `ItemNrInt`, `EAN` oder `ItemNrSuppl`. Zeilen ohne passenden Artikel werden als fehlgeschlagen gemeldet.\n3. Eine Zeile mit `InternalNumber` wird der Bestellung mit dieser internen Nummer zugeordnet. Eine Zeile nur mit `ExternalCode` wird der Bestellung mit diesem externen Code zugeordnet. Es zählen nur Bestellungen mit Lieferlager `LocID`, und der Artikel wird in den Bestellpositionen gesucht.\n4. Zeilen, die eine Zuordnungsregel verletzen (`Error01`–`Error07`), werden als fehlgeschlagen gemeldet und nicht geliefert. Zeilen ohne `InternalNumber` und `ExternalCode` werden ohne Bezug zu einer Bestellposition geliefert.\n5. Für jede verbleibende Zeile gilt:\n - `Ordered` ist der XML-Wert, falls ungleich 0, sonst die Menge der Bestellposition.\n - `SupplPrice` ist der XML-Wert, sonst der Preis der Bestellposition.\n - `Delivered` wird mit der Bestelleinheit des Artikels multipliziert, wenn beim Lieferanten `UsePackingUnitAtCreateDelivery` gesetzt ist.\n - Der Rabatt ist 0.\n6. Das Kopffeld `PurchaseOrderNr` enthält eine kommagetrennte Liste aller zugeordneten Bestellnummern. Wurde keine Bestellung zugeordnet, enthält es die externe Bestellnummer ohne abschließendes `;`.\n7. Bei fehlgeschlagenen Zeilen wird ein Block `Failed To Import Line Items:` mit diesen Zeilen an die Lieferungsnotiz angehängt. Die Notiz ist insgesamt auf 8000 Zeichen begrenzt.\n8. Ohne Positionen wird nur ein Kopf angelegt.\n\n**Ergebnis**\n- Ergebnismenge 1: der angelegte Lieferungskopf.\n- Ergebnismenge 2: die Positionen, ergänzt um die Kennungen aus der Anfrage.\n- Ergebnismenge 3 (nur bei XML-Positionen in Modus 2): die fehlgeschlagenen Zeilen.\n\nBei Validierungsfehlern wird statt dieser Ergebnismengen eine einzelne Zeile mit der Spalte `ERROR` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | Nein | Lager der Lieferung. Wird durch `LocID` im XML überschrieben. |\n| `OrderNr` | int | Nein | Interne Nummer der Lieferantenbestellung. `0` legt eine freie Lieferung aus XML-Positionen an; jeder andere Wert legt die Lieferung aus dieser Bestellung als Vorlage an. Wird durch `OrderNr` im XML überschrieben. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Bei `OrderNr` = 0 erforderlich, sofern nicht im XML angegeben. Bei `OrderNr` <> 0 wird der Lieferant der Bestellung verwendet. |\n| `SuplierOrderNRExternal` | varchar(8000) | Nein | Externe Bestellnummer, Ersatzwert für `PurchaseOrderNr`, wenn keine Bestellung zugeordnet wird. Ein abschließendes `;` wird entfernt. Faktisch nur ohne XML wirksam. |\n| `UserName` | varchar(50) | Nein | Benutzer, der als Ersteller und letzter Bearbeiter gespeichert wird. Wird durch `Username` im XML überschrieben. |\n| `Note` | ntext | Nein | Notiz zur Lieferung, auf 8000 Zeichen gekürzt. Mit XML wird sie durch die XML-Notiz ersetzt; im Vorlagenmodus dient sie als Ersatz bei leerer XML-Notiz. |\n| `ParameterXML` | xml | Nein | Optionales XML mit genau einem Kopf `CREATE_DELIVERY/Delivery` und, bei `OrderNr` = 0, Positionen unter `ITEMS/Item`. |\n\n- **Keine Transaktion.** Kopf und Positionen werden in dieser Prozedur nacheinander ohne explizite Transaktion eingefügt. Ein Laufzeitfehler mittendrin kann einen Kopf mit nur einem Teil der Positionen hinterlassen. Der Vorlagenweg verwendet nur für die Positionen eine eigene Transaktion.\n- **Vorlagenweg ändert den Bestellstatus.** Bei `ConfirmOrderedDocumentOnDelivery` = `1` setzt `Pixi_CreateSDeliveryByTemplate` die Lieferantenbestellung auf den bestätigten Status. Fehler dieser Prozedur werden als `ERROR --- …` ausgelöst.\n- **Prüfung auf offene Lieferung ist ein Teilstring-Vergleich.** Die Prüfung auf eine bestehende `NEW`-Lieferung sucht die Bestellnummer als Text in `SDelHextOrderNr`. Bestellung `123` wird daher auch durch eine offene Lieferung zu Bestellung `1234` blockiert.\n- **`ExternalReceiptNr`** wird nur aus dem XML gelesen. Duplikate je Lieferant werden abgewiesen.\n- **`SuplierOrderNRExternal` wird meist überschrieben.** Mit XML wird der Wert bei `OrderNr` = 0 auf `NULL` gesetzt. Bei `OrderNr` <> 0 wird er gar nicht weitergegeben. Wirksam ist er daher nur ohne XML, als Ersatzwert für `PurchaseOrderNr`.\n- **Vorrang der Notiz.** Mit XML ersetzt die Notiz aus dem XML (oder ein Leerstring) den Parameter `Note`. Im Vorlagenmodus wird bei leerer XML-Notiz auf den Parameter `Note` zurückgegriffen.\n- **`LocID` wird nur auf dem XML-Weg geprüft.** Ohne XML und mit `OrderNr` = 0 wird auch bei unbekannter `LocID` ein Kopf angelegt.\n- **Ignorierte XML-Elemente.** `ItemName` und `ItemKey` in den XML-Positionen werden gelesen, aber ignoriert. Name und Schlüssel stammen immer aus den Artikelstammdaten.\n- **Eine Anfragezeile kann mehrere Lieferpositionen erzeugen.** Steht der Artikel mehrfach in der zugeordneten Bestellung, entsteht je Bestellposition eine Lieferposition, jeweils mit der vollen Liefermenge.\n- **Error02 bei geteilten externen Codes.** Die Zuordnung per `ExternalCode` findet auch Bestellungen anderer Lieferanten am selben Lager, und solche Zeilen werden mit `Error02` abgewiesen.\n- **Ungesicherte Lesezugriffe.** Die meisten Lesezugriffe verwenden `NOLOCK`.\n- **Nummerierung in Kommentaren.** Kommentare im Code nennen die Menge der fehlgeschlagenen Zeilen \"result set 4\", tatsächlich ist es die dritte gelieferte Ergebnismenge.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateDelivery"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 48213\n 48213\n LIE1\n Lieferung per Spedition\n WE-2024-0815\n 10234\n \n"
}
]
},
{
"name": "pixiCreateDeliveryItem",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine neue Artikelposition in einer offenen Lieferantenlieferung an, die über Lieferungs-Key oder -Nummer bestimmt wird, und liefert die angelegte Position zurück.\n\nLegt eine neue Position (`SDelDetail`) in einer Lieferantenlieferung (`SDelHeader`) an.\n\n1. **Normalisierung:** Leere Werte gelten als nicht übergeben. Bei den numerischen Parametern zählt dadurch auch `0` als leer: `SDelHKey = 0` und `SDelHNr = 0` werden zu `NULL`. Nicht übergebene Mengen und Preise werden zu `0`.\n2. **Pflichtangaben:** Es muss entweder `SDelHKey` oder `SDelHNr` sowie entweder `EANUPC` oder `ItemNrInternal` gesetzt sein.\n3. **Artikelsuche:** Der Artikel wird über `COALESCE(EANUPC, ItemNrInternal)` unter den *scanbaren* Artikelcodes gesucht (`pixi.ItemCode` verknüpft mit `ItemCodeType`, `Scannable = 1`). Ist `EANUPC` gesetzt, wird `ItemNrInternal` ignoriert.\n4. **Lieferungssuche:** Ist `SDelHKey` leer, wird der Key der ersten Lieferung mit `SDelHNr` verwendet. Sind beide angegeben, hat `SDelHKey` Vorrang.\n5. **Prüfungen:**\n - Die Lieferung muss existieren und darf nicht den Status `CLS` (abgeschlossen) oder `INV` (berechnet) haben.\n - Die Lieferung darf nicht durch Picco gesperrt sein (`LockedByPicco = 'Y'`).\n - `LocID` muss leer sein, oder es muss mindestens eine Lieferantenlieferung mit `SDelHLocationID = LocID` existieren.\n6. **Anlage:** Der Artikelname wird aus `items` übernommen, der Lieferant aus dem Lieferungskopf. Es wird immer eine neue Position eingefügt, mit bestellter und gelieferter Menge, Einkaufspreis, Endpreis, Charge und Mindesthaltbarkeitsdatum. Ein Bestellpositionsbezug wird nicht gesetzt. Rabatte und Mittelpreis werden auf `0` gesetzt.\n7. **Preis-Fallback:** Ist `SupplPrice` `0` oder nicht übergeben und hat die Lieferung einen Lieferanten, wird der Einkaufspreis aus dem Lieferantenartikel (`AddItems.SupplPrice`) übernommen. Dieser Wert gilt für Preis, Mittelpreis und Endpreis. Ein übergebener `SupplFinalPrice` wird in diesem Fall ebenfalls überschrieben.\n8. **Ergebnis:** Die neu angelegte Lieferposition wird mit Zusatzinformationen zurückgegeben:\n - auf Lieferantenbestellpositionen zugeordnete Menge\n - offene Kunden, offene Aufträge und offene Menge zum Artikel im Lager der Lieferung\n - Lieferanten-Artikelnummer und interne Artikelnummer aus dem Lieferantenartikel\n\nAlle Fehler werden per `RAISERROR` (Schweregrad 16) ausgelöst. In diesem Fall wird keine Position angelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | Nein | Interner Key der Lieferantenlieferung. Hat Vorrang vor `SDelHNr`; `0` gilt als nicht übergeben. |\n| `SDelHNr` | int | Nein | Lieferungsnummer. Wird nur verwendet, wenn `SDelHKey` leer ist. Dieser Parameter oder `SDelHKey` ist Pflicht. |\n| `UserName` | varchar(50) | Nein | Benutzername, der als Anleger und letzter Bearbeiter der Position gespeichert wird. |\n| `ItemNrInternal` | varchar(50) | Nein | Artikelcode für die Suche, falls `EANUPC` leer ist. Er wird gegen die scanbaren Artikelcodes geprüft. |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC des Artikels, die unter den scanbaren Artikelcodes gesucht wird. Hat Vorrang vor `ItemNrInternal`. |\n| `SupplPrice` | money | Nein | Einkaufspreis der Position. Bei `0` oder ohne Angabe wird der Preis aus dem Lieferantenartikel übernommen. |\n| `SupplFinalPrice` | money | Nein | Endpreis im Einkauf. Er wird durch den Fallback-Preis überschrieben, wenn `SupplPrice` `0` ist. |\n| `SDelHSupplNr` | varchar(4) | Nein | Wird nicht verwendet (DEV-4203). Der Lieferant wird aus dem Lieferungskopf übernommen. |\n| `OrderdQty` | money | Nein | Bestellte Menge der Position. |\n| `DeliverdQty` | money | Nein | Gelieferte Menge der Position. |\n| `LocID` | varchar(255) | Nein | Optionale Lager-ID. Ist sie gesetzt, muss mindestens eine Lieferantenlieferung mit dieser Lager-ID existieren, sonst wird ein Fehler ausgelöst. |\n| `PiccoUser` | varchar(59) | Nein | Wird im Code nicht verwendet. |\n| `BatchNumber` | varchar(50) | Nein | Charge, die an der Lieferposition gespeichert wird. |\n| `BestBeforeDate` | datetime | Nein | Mindesthaltbarkeitsdatum, das an der Lieferposition gespeichert wird. |\n\n- `SDelHSupplNr` und `PiccoUser` werden angenommen, aber nicht verwendet; `SDelHSupplNr` ist im Code als ungenutzt markiert (DEV-4203). Der Lieferant stammt immer aus dem Lieferungskopf.\n- **Lagerprüfung:** Die Prüfung von `LocID` vergleicht nicht mit dem Lager der Ziel-Lieferung. Es wird nur geprüft, ob *irgendeine* Lieferantenlieferung mit dieser Lager-ID existiert.\n- **Doppelte Positionen:** Ein erneuter Aufruf für denselben Artikel legt eine weitere Position an. Bestehende Positionen werden nie aktualisiert; der Fehlertext verweist für Änderungen auf `pixiUpdateDeliveryItem`.\n- **Anlage von Lieferantenartikeln:** Ist die Einstellung `InsertAddItemOnSOrdersDragDrop` auf `1` und existiert für Lieferant und Artikel kein Lieferantenartikel (`AddItems`), wird die interne Prozedur `Pixi_InsertAddItemOnDelivery` aufgerufen. Diese Prozedur liegt nicht vor, daher sind ihre genauen Auswirkungen hier nicht dokumentiert; vermutlich legt sie einen solchen Eintrag an.\n- **Preis kann NULL sein:** Beim Preis-Fallback wird der Preis `NULL`, wenn für den Artikel beim Lieferanten kein Lieferantenartikel existiert.\n- **Doppelter Fehlertext:** Fehlt nur die Lieferungsreferenz, verkettet die Prüflogik die Meldung doppelt, sodass der Fehlertext zweimal erscheint.\n- **Benutzername:** Wird `UserName` als leerer String übergeben, wird er zu `NULL` und als `NULL` für Anleger/Bearbeiter gespeichert.\n- Lesezugriffe erfolgen mit `NOLOCK`. Es wird keine explizite Transaktion verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateDeliveryItem"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine neue Artikelposition in einer offenen Lieferantenlieferung an, die über Lieferungs-Key oder -Nummer bestimmt wird, und liefert die angelegte Position zurück.\n\nLegt eine neue Position (`SDelDetail`) in einer Lieferantenlieferung (`SDelHeader`) an.\n\n1. **Normalisierung:** Leere Werte gelten als nicht übergeben. Bei den numerischen Parametern zählt dadurch auch `0` als leer: `SDelHKey = 0` und `SDelHNr = 0` werden zu `NULL`. Nicht übergebene Mengen und Preise werden zu `0`.\n2. **Pflichtangaben:** Es muss entweder `SDelHKey` oder `SDelHNr` sowie entweder `EANUPC` oder `ItemNrInternal` gesetzt sein.\n3. **Artikelsuche:** Der Artikel wird über `COALESCE(EANUPC, ItemNrInternal)` unter den *scanbaren* Artikelcodes gesucht (`pixi.ItemCode` verknüpft mit `ItemCodeType`, `Scannable = 1`). Ist `EANUPC` gesetzt, wird `ItemNrInternal` ignoriert.\n4. **Lieferungssuche:** Ist `SDelHKey` leer, wird der Key der ersten Lieferung mit `SDelHNr` verwendet. Sind beide angegeben, hat `SDelHKey` Vorrang.\n5. **Prüfungen:**\n - Die Lieferung muss existieren und darf nicht den Status `CLS` (abgeschlossen) oder `INV` (berechnet) haben.\n - Die Lieferung darf nicht durch Picco gesperrt sein (`LockedByPicco = 'Y'`).\n - `LocID` muss leer sein, oder es muss mindestens eine Lieferantenlieferung mit `SDelHLocationID = LocID` existieren.\n6. **Anlage:** Der Artikelname wird aus `items` übernommen, der Lieferant aus dem Lieferungskopf. Es wird immer eine neue Position eingefügt, mit bestellter und gelieferter Menge, Einkaufspreis, Endpreis, Charge und Mindesthaltbarkeitsdatum. Ein Bestellpositionsbezug wird nicht gesetzt. Rabatte und Mittelpreis werden auf `0` gesetzt.\n7. **Preis-Fallback:** Ist `SupplPrice` `0` oder nicht übergeben und hat die Lieferung einen Lieferanten, wird der Einkaufspreis aus dem Lieferantenartikel (`AddItems.SupplPrice`) übernommen. Dieser Wert gilt für Preis, Mittelpreis und Endpreis. Ein übergebener `SupplFinalPrice` wird in diesem Fall ebenfalls überschrieben.\n8. **Ergebnis:** Die neu angelegte Lieferposition wird mit Zusatzinformationen zurückgegeben:\n - auf Lieferantenbestellpositionen zugeordnete Menge\n - offene Kunden, offene Aufträge und offene Menge zum Artikel im Lager der Lieferung\n - Lieferanten-Artikelnummer und interne Artikelnummer aus dem Lieferantenartikel\n\nAlle Fehler werden per `RAISERROR` (Schweregrad 16) ausgelöst. In diesem Fall wird keine Position angelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | Nein | Interner Key der Lieferantenlieferung. Hat Vorrang vor `SDelHNr`; `0` gilt als nicht übergeben. |\n| `SDelHNr` | int | Nein | Lieferungsnummer. Wird nur verwendet, wenn `SDelHKey` leer ist. Dieser Parameter oder `SDelHKey` ist Pflicht. |\n| `UserName` | varchar(50) | Nein | Benutzername, der als Anleger und letzter Bearbeiter der Position gespeichert wird. |\n| `ItemNrInternal` | varchar(50) | Nein | Artikelcode für die Suche, falls `EANUPC` leer ist. Er wird gegen die scanbaren Artikelcodes geprüft. |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC des Artikels, die unter den scanbaren Artikelcodes gesucht wird. Hat Vorrang vor `ItemNrInternal`. |\n| `SupplPrice` | money | Nein | Einkaufspreis der Position. Bei `0` oder ohne Angabe wird der Preis aus dem Lieferantenartikel übernommen. |\n| `SupplFinalPrice` | money | Nein | Endpreis im Einkauf. Er wird durch den Fallback-Preis überschrieben, wenn `SupplPrice` `0` ist. |\n| `SDelHSupplNr` | varchar(4) | Nein | Wird nicht verwendet (DEV-4203). Der Lieferant wird aus dem Lieferungskopf übernommen. |\n| `OrderdQty` | money | Nein | Bestellte Menge der Position. |\n| `DeliverdQty` | money | Nein | Gelieferte Menge der Position. |\n| `LocID` | varchar(255) | Nein | Optionale Lager-ID. Ist sie gesetzt, muss mindestens eine Lieferantenlieferung mit dieser Lager-ID existieren, sonst wird ein Fehler ausgelöst. |\n| `PiccoUser` | varchar(59) | Nein | Wird im Code nicht verwendet. |\n| `BatchNumber` | varchar(50) | Nein | Charge, die an der Lieferposition gespeichert wird. |\n| `BestBeforeDate` | datetime | Nein | Mindesthaltbarkeitsdatum, das an der Lieferposition gespeichert wird. |\n\n- `SDelHSupplNr` und `PiccoUser` werden angenommen, aber nicht verwendet; `SDelHSupplNr` ist im Code als ungenutzt markiert (DEV-4203). Der Lieferant stammt immer aus dem Lieferungskopf.\n- **Lagerprüfung:** Die Prüfung von `LocID` vergleicht nicht mit dem Lager der Ziel-Lieferung. Es wird nur geprüft, ob *irgendeine* Lieferantenlieferung mit dieser Lager-ID existiert.\n- **Doppelte Positionen:** Ein erneuter Aufruf für denselben Artikel legt eine weitere Position an. Bestehende Positionen werden nie aktualisiert; der Fehlertext verweist für Änderungen auf `pixiUpdateDeliveryItem`.\n- **Anlage von Lieferantenartikeln:** Ist die Einstellung `InsertAddItemOnSOrdersDragDrop` auf `1` und existiert für Lieferant und Artikel kein Lieferantenartikel (`AddItems`), wird die interne Prozedur `Pixi_InsertAddItemOnDelivery` aufgerufen. Diese Prozedur liegt nicht vor, daher sind ihre genauen Auswirkungen hier nicht dokumentiert; vermutlich legt sie einen solchen Eintrag an.\n- **Preis kann NULL sein:** Beim Preis-Fallback wird der Preis `NULL`, wenn für den Artikel beim Lieferanten kein Lieferantenartikel existiert.\n- **Doppelter Fehlertext:** Fehlt nur die Lieferungsreferenz, verkettet die Prüflogik die Meldung doppelt, sodass der Fehlertext zweimal erscheint.\n- **Benutzername:** Wird `UserName` als leerer String übergeben, wird er zu `NULL` und als `NULL` für Anleger/Bearbeiter gespeichert.\n- Lesezugriffe erfolgen mit `NOLOCK`. Es wird keine explizite Transaktion verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateDeliveryItem"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 88412\n 5321\n 10045\n Kaffeebecher Steingut 300ml\n 10.0000\n 10.0000\n 12.5000\n 0.0000\n 12.5000\n 2024-05-14T09:32:11.237\n API\n 2024-05-14T09:32:11.237\n API\n 0.0000\n 0.0000\n CH-2024-0815\n 2025-12-31T00:00:00\n 0.0000\n 3\n 3\n 5.0000\n LF-77812\n ART-10045\n 4006381333931\n \n"
}
]
},
{
"name": "pixi_CreateSDeliveryByTemplate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100234;100235\n 001\n jdoe\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt aus einer oder mehreren bestätigten Lieferantenbestellungen eine neue Lieferantenlieferung (Status NEW) an und führt anschließend eine Abfrage der Lieferungsköpfe aus.\n\nVeralteter Wrapper, der anhand von Lieferantenbestellungen als Vorlage einen Lieferantenlieferschein (`SDelHeader` / `SDelDetail`) anlegt. Anschließend ruft er eine seitenweise Liste der Lieferungsköpfe auf.\n\n**Schritt 1 – Lieferung anlegen** (über `Pixi_CreateSDeliveryByTemplate`):\n\n1. `OrderNr` wird an `;` getrennt. Jedes Element wird mit der internen Nummer (`InternalNumber`) einer Lieferantenbestellung abgeglichen.\n2. Es werden nur Lieferantenbestellungen in einem passenden Status verwendet. Das hängt von der Einstellung `ConfirmOrderedDocumentOnDelivery` ab:\n - `0`: Bestellungen, deren Status als bestätigt markiert ist (`IsConfirmed = 1`).\n - `1`: Bestellungen, deren Status als bestellt-bestätigt markiert ist (`IsOrderedConfirmed = 1`). Diese Bestellungen werden danach auf den ersten bestätigten Status gesetzt. Zusätzlich werden Bestätigungsdatum, bestätigender Benutzer, Änderungsdatum und ändernder Benutzer gesetzt.\n3. Qualifiziert sich keine Bestellung, wird nichts angelegt.\n4. Andernfalls wird ein Lieferungskopf mit folgenden Werten eingefügt:\n - Status `NEW` und Lager `LocID`\n - die Lieferantennummer einer der gefundenen Bestellungen\n - der vollständige `OrderNr`-String als externe Bestellnummer\n - `UserName` als anlegender und ändernder Mitarbeiter sowie das aktuelle Datum\n5. Für jede Bestellposition mit offener Menge > 0 wird eine Lieferposition angelegt. Die offene Menge ist `Qty - DeliveredQty - UndeliveredQty`.\n - Die gelieferte Menge ist `0`, die bestellte Menge ist die offene Menge.\n - Lieferantenpreis und Rabatt stammen aus der Bestellposition. Ein Prozentrabatt wird direkt übernommen; ein Betragsrabatt wird pro Stück in einen Prozentwert umgerechnet.\n - End- und Mittelpreis sind Preis minus Rabattbetrag.\n\n**Schritt 2 – Listenabfrage** (über `Pixi_GetSDelHeaderByPage`): Der Code fragt Lieferungsköpfe des Lagers `LocID` mit Status `NEW` oder `INV` ab (das Argument `ShowInv = NULL` wird zu `1`). Der Aufruf übergibt Seitennummer `0`, daher lautet das Zeilenfenster `RowNum BETWEEN -PerPage+1 AND 0`. Die zurückgegebene Ergebnismenge enthält deshalb nie Zeilen.\n\nDie ID der neuen Lieferung wird nicht zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | varchar(1000) | Ja | Interne Nummern der Lieferantenbestellungen, die als Vorlage dienen, getrennt durch `;`. Der gesamte String wird zudem als externe Bestellnummer der Lieferung gespeichert. |\n| `LocID` | varchar(3) | Ja | Lager-ID der neuen Lieferung. Die Listenabfrage wird ebenfalls nach diesem Lager gefiltert. |\n| `UserName` | varchar(50) | Ja | Benutzername, der als anlegender/ändernder Mitarbeiter gespeichert wird. Er dient bei Einstellung `1` auch zur Bestätigung der Bestellungen. NULL wird zu `TemplateFromBuying`. |\n\n- Laut Code-Kommentar wird dieser API-Call **nicht mehr gepflegt**.\n- Die zurückgegebene Ergebnismenge ist immer leer, weil Seite `0` angefordert wird. Sie eignet sich nicht, um die neue Lieferung zu finden. Die Lieferungsköpfe sind separat abzufragen, z. B. über Lager, Status `NEW` und externe Bestellnummer.\n- Nur das Einfügen der Positionen läuft in einer Transaktion. Folgende Schritte laufen davor und werden bei einem Fehler beim Einfügen der Positionen **nicht** zurückgerollt:\n - die Statusänderung der Lieferantenbestellungen (Einstellung `1`)\n - das Einfügen des Kopfes\n \n Ein Fehler kann daher einen Lieferungskopf ohne Positionen hinterlassen.\n- Hat die Einstellung `ConfirmOrderedDocumentOnDelivery` einen anderen Wert als `0` oder `1`, qualifiziert sich keine Bestellung und es wird nichts angelegt.\n- Gehören die Bestellungen zu verschiedenen Lieferanten, erhält der Kopf die Lieferantennummer einer beliebigen Bestellung (`TOP (1)` ohne `ORDER BY`). Die Positionen aller Bestellungen werden dennoch übernommen.\n- Ist `UserName` NULL, verwendet die innere Prozedur `TemplateFromBuying`.\n- Während des Einfügens der Positionen wird `CONTEXT_INFO` auf `0x10005` gesetzt, um den Trigger `SDelDetail_IUD` zu umgehen.\n- Bestelldaten werden mit `NOLOCK` gelesen.\n- Die Seitengröße der Listenabfrage stammt aus der Einstellung `BuyingShowPerTab` (Standard 500).\n- `OrderNr` ist in diesem Wrapper auf 1000 Zeichen begrenzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixi_CreateSDeliveryByTemplate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 100234;100235\n 001\n jdoe\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt aus einer oder mehreren bestätigten Lieferantenbestellungen eine neue Lieferantenlieferung (Status NEW) an und führt anschließend eine Abfrage der Lieferungsköpfe aus.\n\nVeralteter Wrapper, der anhand von Lieferantenbestellungen als Vorlage einen Lieferantenlieferschein (`SDelHeader` / `SDelDetail`) anlegt. Anschließend ruft er eine seitenweise Liste der Lieferungsköpfe auf.\n\n**Schritt 1 – Lieferung anlegen** (über `Pixi_CreateSDeliveryByTemplate`):\n\n1. `OrderNr` wird an `;` getrennt. Jedes Element wird mit der internen Nummer (`InternalNumber`) einer Lieferantenbestellung abgeglichen.\n2. Es werden nur Lieferantenbestellungen in einem passenden Status verwendet. Das hängt von der Einstellung `ConfirmOrderedDocumentOnDelivery` ab:\n - `0`: Bestellungen, deren Status als bestätigt markiert ist (`IsConfirmed = 1`).\n - `1`: Bestellungen, deren Status als bestellt-bestätigt markiert ist (`IsOrderedConfirmed = 1`). Diese Bestellungen werden danach auf den ersten bestätigten Status gesetzt. Zusätzlich werden Bestätigungsdatum, bestätigender Benutzer, Änderungsdatum und ändernder Benutzer gesetzt.\n3. Qualifiziert sich keine Bestellung, wird nichts angelegt.\n4. Andernfalls wird ein Lieferungskopf mit folgenden Werten eingefügt:\n - Status `NEW` und Lager `LocID`\n - die Lieferantennummer einer der gefundenen Bestellungen\n - der vollständige `OrderNr`-String als externe Bestellnummer\n - `UserName` als anlegender und ändernder Mitarbeiter sowie das aktuelle Datum\n5. Für jede Bestellposition mit offener Menge > 0 wird eine Lieferposition angelegt. Die offene Menge ist `Qty - DeliveredQty - UndeliveredQty`.\n - Die gelieferte Menge ist `0`, die bestellte Menge ist die offene Menge.\n - Lieferantenpreis und Rabatt stammen aus der Bestellposition. Ein Prozentrabatt wird direkt übernommen; ein Betragsrabatt wird pro Stück in einen Prozentwert umgerechnet.\n - End- und Mittelpreis sind Preis minus Rabattbetrag.\n\n**Schritt 2 – Listenabfrage** (über `Pixi_GetSDelHeaderByPage`): Der Code fragt Lieferungsköpfe des Lagers `LocID` mit Status `NEW` oder `INV` ab (das Argument `ShowInv = NULL` wird zu `1`). Der Aufruf übergibt Seitennummer `0`, daher lautet das Zeilenfenster `RowNum BETWEEN -PerPage+1 AND 0`. Die zurückgegebene Ergebnismenge enthält deshalb nie Zeilen.\n\nDie ID der neuen Lieferung wird nicht zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | varchar(1000) | Ja | Interne Nummern der Lieferantenbestellungen, die als Vorlage dienen, getrennt durch `;`. Der gesamte String wird zudem als externe Bestellnummer der Lieferung gespeichert. |\n| `LocID` | varchar(3) | Ja | Lager-ID der neuen Lieferung. Die Listenabfrage wird ebenfalls nach diesem Lager gefiltert. |\n| `UserName` | varchar(50) | Ja | Benutzername, der als anlegender/ändernder Mitarbeiter gespeichert wird. Er dient bei Einstellung `1` auch zur Bestätigung der Bestellungen. NULL wird zu `TemplateFromBuying`. |\n\n- Laut Code-Kommentar wird dieser API-Call **nicht mehr gepflegt**.\n- Die zurückgegebene Ergebnismenge ist immer leer, weil Seite `0` angefordert wird. Sie eignet sich nicht, um die neue Lieferung zu finden. Die Lieferungsköpfe sind separat abzufragen, z. B. über Lager, Status `NEW` und externe Bestellnummer.\n- Nur das Einfügen der Positionen läuft in einer Transaktion. Folgende Schritte laufen davor und werden bei einem Fehler beim Einfügen der Positionen **nicht** zurückgerollt:\n - die Statusänderung der Lieferantenbestellungen (Einstellung `1`)\n - das Einfügen des Kopfes\n \n Ein Fehler kann daher einen Lieferungskopf ohne Positionen hinterlassen.\n- Hat die Einstellung `ConfirmOrderedDocumentOnDelivery` einen anderen Wert als `0` oder `1`, qualifiziert sich keine Bestellung und es wird nichts angelegt.\n- Gehören die Bestellungen zu verschiedenen Lieferanten, erhält der Kopf die Lieferantennummer einer beliebigen Bestellung (`TOP (1)` ohne `ORDER BY`). Die Positionen aller Bestellungen werden dennoch übernommen.\n- Ist `UserName` NULL, verwendet die innere Prozedur `TemplateFromBuying`.\n- Während des Einfügens der Positionen wird `CONTEXT_INFO` auf `0x10005` gesetzt, um den Trigger `SDelDetail_IUD` zu umgehen.\n- Bestelldaten werden mit `NOLOCK` gelesen.\n- Die Seitengröße der Listenabfrage stammt aus der Einstellung `BuyingShowPerTab` (Standard 500).\n- `OrderNr` ist in diesem Wrapper auf 1000 Zeichen begrenzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixi_CreateSDeliveryByTemplate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": ""
}
]
},
{
"name": "pixiCreateSDeliveryByTemplate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n BES0001234;BES0001235\n 001\n jdoe\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt aus einer oder mehreren bestätigten Lieferantenbestellungen eine neue Lieferantenlieferung (Status NEW) an einem Lager an und liefert deren Kopfdaten.\n\nLegt einen Lieferantenlieferschein (`SDelHeader` mit Positionen in `SDelDetail`) auf Basis einer oder mehrerer Lieferantenbestellungen als Vorlage an.\n\n1. `OrderNr` wird an `;` in einzelne Bestellnummern zerlegt (die `InternalNumber` der Lieferantenbestellung, z. B. eine BES-Nummer). Führende und abschließende Leerzeichen werden entfernt.\n2. Existiert am Lager `LocID` bereits eine Lieferung mit Status `NEW`, deren `SDelHextOrderNr` eine der übergebenen Nummern enthält, bricht der Aufruf ab und liefert eine Zeile mit der Spalte `ERROR`.\n3. Andernfalls wird die interne Prozedur `Pixi_CreateSDeliveryByTemplate` ausgeführt:\n - Es werden nur Lieferantenbestellungen verwendet, deren Status als bestätigt gilt. Welches Statuskennzeichen geprüft wird, hängt von der Einstellung `ConfirmOrderedDocumentOnDelivery` ab: `0` verlangt `IsConfirmed = 1`, `1` verlangt `IsOrderedConfirmed = 1`.\n - Qualifiziert sich keine Bestellung, wird nichts angelegt.\n - Bei Einstellung `1` werden die betroffenen, noch nicht bestätigten Lieferantenbestellungen auf den bestätigten Status gesetzt (Bestätigungsdatum und -benutzer werden gesetzt).\n - Es wird ein Lieferungskopf mit Status `NEW`, dem angegebenen Lager, dem Lieferanten einer der Bestellungen, `SDelHextOrderNr` = vollständiger `OrderNr`-String und `UserName` als anlegender/ändernder Benutzer angelegt (Standard `TemplateFromBuying`, falls NULL).\n - Für jede Bestellposition mit offener Menge (`Qty - DeliveredQty - UndeliveredQty > 0`) wird eine Lieferposition mit gelieferter Menge 0, der offenen Menge als bestellter Menge, dem Lieferantenpreis sowie dem in Prozent und Endpreis umgerechneten Rabatt angelegt.\n4. Abschließend werden die Kopfdaten der angelegten Lieferung geliefert (`SDelHKey`, Datum, Lager, Nummer, Status, externe Bestellnummer, Lieferant).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | varchar(1000) | Ja | Eine oder mehrere Nummern von Lieferantenbestellungen (`InternalNumber`), getrennt durch `;`. |\n| `LocID` | varchar(3) | Ja | Lager-ID, für die die Lieferung angelegt wird; wird auch für die Prüfung auf offene Lieferungen verwendet. |\n| `UserName` | varchar(50) | Ja | Benutzer, der als Ersteller/Bearbeiter der Lieferung gespeichert wird; bei NULL wird `TemplateFromBuying` verwendet. |\n\n- Laut Code-Kommentar wird dieser API-Aufruf **nicht mehr gepflegt**.\n- Die Dublettenprüfung arbeitet mit einem Teilstring-Vergleich (`CHARINDEX`) auf `SDelHextOrderNr`: Eine Nummer wie `BES100` wird auch in `BES1000` gefunden, daher sind Fehlalarme möglich.\n- Qualifiziert sich keine Lieferantenbestellung (unbekannte Nummer, falscher Status oder Einstellung `ConfirmOrderedDocumentOnDelivery` weder `0` noch `1`), wird keine Lieferung angelegt und die Ergebnismenge mit den Kopfdaten ist leer; ein Fehler wird nicht gemeldet.\n- Gehören die Bestellungen zu verschiedenen Lieferanten, erhält der Kopf den Lieferanten einer beliebigen Bestellung (`TOP (1)` ohne Sortierung), die Positionen aller Bestellungen werden jedoch übernommen.\n- Das Anlegen des Kopfes und die optionale Statusänderung der Lieferantenbestellungen laufen **außerhalb** der Transaktion; nur das Einfügen der Positionen ist transaktional. Schlägt dieses fehl, bleibt der Kopf ohne Positionen bestehen und der Fehler wird als `ERROR --- ` ausgelöst.\n- Während des Einfügens der Positionen wird `CONTEXT_INFO` gesetzt, um den Trigger auf `SDelDetail` zu unterdrücken.\n- Lesezugriffe verwenden `NOLOCK`. Die Benutzer-ID für die Bestätigung wird über `inf.UserGetByName` ermittelt (nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateSDeliveryByTemplate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n BES0001234;BES0001235\n 001\n jdoe\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt aus einer oder mehreren bestätigten Lieferantenbestellungen eine neue Lieferantenlieferung (Status NEW) an einem Lager an und liefert deren Kopfdaten.\n\nLegt einen Lieferantenlieferschein (`SDelHeader` mit Positionen in `SDelDetail`) auf Basis einer oder mehrerer Lieferantenbestellungen als Vorlage an.\n\n1. `OrderNr` wird an `;` in einzelne Bestellnummern zerlegt (die `InternalNumber` der Lieferantenbestellung, z. B. eine BES-Nummer). Führende und abschließende Leerzeichen werden entfernt.\n2. Existiert am Lager `LocID` bereits eine Lieferung mit Status `NEW`, deren `SDelHextOrderNr` eine der übergebenen Nummern enthält, bricht der Aufruf ab und liefert eine Zeile mit der Spalte `ERROR`.\n3. Andernfalls wird die interne Prozedur `Pixi_CreateSDeliveryByTemplate` ausgeführt:\n - Es werden nur Lieferantenbestellungen verwendet, deren Status als bestätigt gilt. Welches Statuskennzeichen geprüft wird, hängt von der Einstellung `ConfirmOrderedDocumentOnDelivery` ab: `0` verlangt `IsConfirmed = 1`, `1` verlangt `IsOrderedConfirmed = 1`.\n - Qualifiziert sich keine Bestellung, wird nichts angelegt.\n - Bei Einstellung `1` werden die betroffenen, noch nicht bestätigten Lieferantenbestellungen auf den bestätigten Status gesetzt (Bestätigungsdatum und -benutzer werden gesetzt).\n - Es wird ein Lieferungskopf mit Status `NEW`, dem angegebenen Lager, dem Lieferanten einer der Bestellungen, `SDelHextOrderNr` = vollständiger `OrderNr`-String und `UserName` als anlegender/ändernder Benutzer angelegt (Standard `TemplateFromBuying`, falls NULL).\n - Für jede Bestellposition mit offener Menge (`Qty - DeliveredQty - UndeliveredQty > 0`) wird eine Lieferposition mit gelieferter Menge 0, der offenen Menge als bestellter Menge, dem Lieferantenpreis sowie dem in Prozent und Endpreis umgerechneten Rabatt angelegt.\n4. Abschließend werden die Kopfdaten der angelegten Lieferung geliefert (`SDelHKey`, Datum, Lager, Nummer, Status, externe Bestellnummer, Lieferant).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OrderNr` | varchar(1000) | Ja | Eine oder mehrere Nummern von Lieferantenbestellungen (`InternalNumber`), getrennt durch `;`. |\n| `LocID` | varchar(3) | Ja | Lager-ID, für die die Lieferung angelegt wird; wird auch für die Prüfung auf offene Lieferungen verwendet. |\n| `UserName` | varchar(50) | Ja | Benutzer, der als Ersteller/Bearbeiter der Lieferung gespeichert wird; bei NULL wird `TemplateFromBuying` verwendet. |\n\n- Laut Code-Kommentar wird dieser API-Aufruf **nicht mehr gepflegt**.\n- Die Dublettenprüfung arbeitet mit einem Teilstring-Vergleich (`CHARINDEX`) auf `SDelHextOrderNr`: Eine Nummer wie `BES100` wird auch in `BES1000` gefunden, daher sind Fehlalarme möglich.\n- Qualifiziert sich keine Lieferantenbestellung (unbekannte Nummer, falscher Status oder Einstellung `ConfirmOrderedDocumentOnDelivery` weder `0` noch `1`), wird keine Lieferung angelegt und die Ergebnismenge mit den Kopfdaten ist leer; ein Fehler wird nicht gemeldet.\n- Gehören die Bestellungen zu verschiedenen Lieferanten, erhält der Kopf den Lieferanten einer beliebigen Bestellung (`TOP (1)` ohne Sortierung), die Positionen aller Bestellungen werden jedoch übernommen.\n- Das Anlegen des Kopfes und die optionale Statusänderung der Lieferantenbestellungen laufen **außerhalb** der Transaktion; nur das Einfügen der Positionen ist transaktional. Schlägt dieses fehl, bleibt der Kopf ohne Positionen bestehen und der Fehler wird als `ERROR --- ` ausgelöst.\n- Während des Einfügens der Positionen wird `CONTEXT_INFO` gesetzt, um den Trigger auf `SDelDetail` zu unterdrücken.\n- Lesezugriffe verwenden `NOLOCK`. Die Benutzer-ID für die Bestätigung wird über `inf.UserGetByName` ermittelt (nicht beigefügt).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateSDeliveryByTemplate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 4711\n 2024-05-14T10:23:45.123+02:00\n 001\n 4711\n NEW\n BES0001234;BES0001235\n L001\n \n"
}
]
},
{
"name": "pixiCreateSupplier",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen neuen Lieferanten samt Hauptkontakt an und liefert eine Statuszeile mit ReturnCode und Message.\n\nLegt einen neuen Lieferanten in `Suppliers` und einen Hauptkontakt in `pixi.Contact` an. Beide sind über `ContactId` verknüpft.\n\nAblauf:\n\n1. Jeder als Leerstring übergebene String-Parameter wird als `NULL` behandelt. `SupplCtry` wird vorher getrimmt.\n2. Ohne `CurrencyId` wird die Datenbankwährung verwendet. Das ist die Währung aus der Einstellung `HomeCurrency`, ermittelt über `pixi.GetDatabaseCurrency`.\n3. `CanDoDirectFulfillment` wird in ein Bit umgewandelt: `Y` ergibt 1. `N` und jeder andere Wert ergeben 0.\n4. Die Prüfungen laufen in dieser Reihenfolge und brechen beim ersten Fehler ab:\n - `SupplNr` muss angegeben sein.\n - `SupplName` muss angegeben sein.\n - `CanDoDirectFulfillment` darf nicht `NULL` sein.\n - Es darf noch kein Lieferant mit derselben `SupplNr` existieren.\n5. Sind alle Prüfungen erfolgreich, wird zuerst ein Kontakt angelegt. Nicht übergebene Kontaktfelder werden als Leerstring gespeichert. Danach wird der Lieferant angelegt mit:\n - `ContactId` = Identity des neuen Kontakts\n - `CreateDate` = aktuelle Zeit\n - `CreateEmp` = `API`\n - `MailBox` = `eMail`\n - `SupplComment` = `SupplierComment`\n\nDer Aufruf liefert immer genau eine Statuszeile. `ReturnCode` ist `OK` bei Erfolg und `Error` bei einem Validierungsfehler oder einem unerwarteten SQL-Fehler.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer (Schlüssel). Fachlich Pflicht; darf noch nicht existieren. |\n| `SupplName` | varchar(60) | Nein | Name des Lieferanten. Fachlich Pflicht. |\n| `SupplNameExt` | varchar(50) | Nein | Namenszusatz. |\n| `SupplGroup` | varchar(4) | Nein | Code der Lieferantengruppe (wird nicht geprüft). |\n| `DefaultDeliveryDays` | int | Nein | Standard-Lieferzeit in Tagen. Der Wert 0 wird als NULL gespeichert. |\n| `SupplFaxNR` | varchar(100) | Nein | Faxnummer des Lieferanten. |\n| `CustNR` | varchar(20) | Nein | Eigene Kundennummer beim Lieferanten. |\n| `eMail` | varchar(60) | Nein | Allgemeine E-Mail-Adresse; wird in der Spalte `MailBox` gespeichert. |\n| `SupAnrede` | varchar(20) | Nein | Anrede der Lieferantenadresse. |\n| `SupName2` | varchar(60) | Nein | Zweite Namenszeile der Adresse. |\n| `SupAddress` | varchar(50) | Nein | Straße und Hausnummer. |\n| `SupZip` | varchar(20) | Nein | Postleitzahl. |\n| `SupPhone1` | varchar(50) | Nein | Erste Telefonnummer. |\n| `CanDoDirectFulfillment` | varchar(1) | Nein | Gibt an, ob der Lieferant Direktversand (Streckengeschäft) durchführen kann. Fachlich Pflicht (darf nicht NULL sein). |\n| `SupCity` | varchar(50) | Nein | Ort. |\n| `SupPhone2` | varchar(50) | Nein | Zweite Telefonnummer. |\n| `SupplCtry` | varchar(3) | Nein | Ländercode; wird getrimmt, nicht geprüft. |\n| `CurrencyId` | smallint | Nein | Währungs-ID des Lieferanten. Ohne Angabe wird die Datenbankwährung (Einstellung `HomeCurrency`) verwendet. |\n| `eMailSupplOrder` | varchar(255) | Nein | E-Mail-Adresse für Lieferantenbestellungen. |\n| `HomePageUrl` | nvarchar(2000) | Nein | Webseite des Lieferanten. |\n| `MainContact_Title` | nvarchar(100) | Nein | Titel/Anrede des Hauptkontakts. |\n| `MainContact_FirstName` | nvarchar(20) | Nein | Vorname des Hauptkontakts. |\n| `MainContact_LastName` | nvarchar(200) | Nein | Nachname des Hauptkontakts. |\n| `MainContact_JobTitle` | nvarchar(200) | Nein | Berufsbezeichnung des Hauptkontakts. |\n| `MainContact_JobFunction` | nvarchar(200) | Nein | Funktion des Hauptkontakts. |\n| `MainContact_Phone` | varchar(200) | Nein | Telefonnummer des Hauptkontakts. |\n| `MainContact_MobilePhone` | varchar(200) | Nein | Mobilnummer des Hauptkontakts. |\n| `MainContact_Fax` | nvarchar(200) | Nein | Faxnummer des Hauptkontakts. |\n| `MainContact_Email` | nvarchar(200) | Nein | E-Mail-Adresse des Hauptkontakts. |\n| `SupplierComment` | varchar(8000) | Nein | Kommentar zum Lieferanten; wird in `SupplComment` gespeichert. |\n\n- Alles läuft in der benannten Transaktion `CreateSupplier`. Bei einem SQL-Fehler wird die Transaktion zurückgerollt, und `ErrorMessage` enthält den SQL-Fehlertext. Validierungsfehler sind keine SQL-Fehler: Die Transaktion wird committet, es wurde aber nichts geschrieben.\n- Die Dublettenprüfung auf `SupplNr` verwendet `NOLOCK`. Zwei parallele Aufrufe mit derselben Nummer können die Prüfung daher beide bestehen. Ein eventuell vorhandener Unique-Constraint der Tabelle würde dann den generischen Fehler auslösen.\n- `RowsAffected` wird nie aktualisiert und ist immer `0`.\n- `DefaultDeliveryDays` wird mit einem Leerstring verglichen. Als `int` wird der Wert `0` dadurch als `NULL` gespeichert.\n- Ein Leerstring für `CanDoDirectFulfillment` besteht die Pflichtprüfung und wird als 0 gespeichert.\n- `SupplGroup`, `SupplCtry` und `CurrencyId` werden nicht gegen Stammdaten geprüft.\n- Kann keine Datenbankwährung ermittelt werden, bleibt `CurrencyId` `NULL`.\n- Ein Kontaktdatensatz wird immer angelegt, auch wenn kein `MainContact_*`-Parameter übergeben wird.\n- Werte, die länger als die deklarierte Parameterlänge sind (z. B. `SupplNr` mit mehr als 4 Zeichen), werden unter Umständen stillschweigend abgeschnitten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateSupplier"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt einen neuen Lieferanten samt Hauptkontakt an und liefert eine Statuszeile mit ReturnCode und Message.\n\nLegt einen neuen Lieferanten in `Suppliers` und einen Hauptkontakt in `pixi.Contact` an. Beide sind über `ContactId` verknüpft.\n\nAblauf:\n\n1. Jeder als Leerstring übergebene String-Parameter wird als `NULL` behandelt. `SupplCtry` wird vorher getrimmt.\n2. Ohne `CurrencyId` wird die Datenbankwährung verwendet. Das ist die Währung aus der Einstellung `HomeCurrency`, ermittelt über `pixi.GetDatabaseCurrency`.\n3. `CanDoDirectFulfillment` wird in ein Bit umgewandelt: `Y` ergibt 1. `N` und jeder andere Wert ergeben 0.\n4. Die Prüfungen laufen in dieser Reihenfolge und brechen beim ersten Fehler ab:\n - `SupplNr` muss angegeben sein.\n - `SupplName` muss angegeben sein.\n - `CanDoDirectFulfillment` darf nicht `NULL` sein.\n - Es darf noch kein Lieferant mit derselben `SupplNr` existieren.\n5. Sind alle Prüfungen erfolgreich, wird zuerst ein Kontakt angelegt. Nicht übergebene Kontaktfelder werden als Leerstring gespeichert. Danach wird der Lieferant angelegt mit:\n - `ContactId` = Identity des neuen Kontakts\n - `CreateDate` = aktuelle Zeit\n - `CreateEmp` = `API`\n - `MailBox` = `eMail`\n - `SupplComment` = `SupplierComment`\n\nDer Aufruf liefert immer genau eine Statuszeile. `ReturnCode` ist `OK` bei Erfolg und `Error` bei einem Validierungsfehler oder einem unerwarteten SQL-Fehler.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer (Schlüssel). Fachlich Pflicht; darf noch nicht existieren. |\n| `SupplName` | varchar(60) | Nein | Name des Lieferanten. Fachlich Pflicht. |\n| `SupplNameExt` | varchar(50) | Nein | Namenszusatz. |\n| `SupplGroup` | varchar(4) | Nein | Code der Lieferantengruppe (wird nicht geprüft). |\n| `DefaultDeliveryDays` | int | Nein | Standard-Lieferzeit in Tagen. Der Wert 0 wird als NULL gespeichert. |\n| `SupplFaxNR` | varchar(100) | Nein | Faxnummer des Lieferanten. |\n| `CustNR` | varchar(20) | Nein | Eigene Kundennummer beim Lieferanten. |\n| `eMail` | varchar(60) | Nein | Allgemeine E-Mail-Adresse; wird in der Spalte `MailBox` gespeichert. |\n| `SupAnrede` | varchar(20) | Nein | Anrede der Lieferantenadresse. |\n| `SupName2` | varchar(60) | Nein | Zweite Namenszeile der Adresse. |\n| `SupAddress` | varchar(50) | Nein | Straße und Hausnummer. |\n| `SupZip` | varchar(20) | Nein | Postleitzahl. |\n| `SupPhone1` | varchar(50) | Nein | Erste Telefonnummer. |\n| `CanDoDirectFulfillment` | varchar(1) | Nein | Gibt an, ob der Lieferant Direktversand (Streckengeschäft) durchführen kann. Fachlich Pflicht (darf nicht NULL sein). |\n| `SupCity` | varchar(50) | Nein | Ort. |\n| `SupPhone2` | varchar(50) | Nein | Zweite Telefonnummer. |\n| `SupplCtry` | varchar(3) | Nein | Ländercode; wird getrimmt, nicht geprüft. |\n| `CurrencyId` | smallint | Nein | Währungs-ID des Lieferanten. Ohne Angabe wird die Datenbankwährung (Einstellung `HomeCurrency`) verwendet. |\n| `eMailSupplOrder` | varchar(255) | Nein | E-Mail-Adresse für Lieferantenbestellungen. |\n| `HomePageUrl` | nvarchar(2000) | Nein | Webseite des Lieferanten. |\n| `MainContact_Title` | nvarchar(100) | Nein | Titel/Anrede des Hauptkontakts. |\n| `MainContact_FirstName` | nvarchar(20) | Nein | Vorname des Hauptkontakts. |\n| `MainContact_LastName` | nvarchar(200) | Nein | Nachname des Hauptkontakts. |\n| `MainContact_JobTitle` | nvarchar(200) | Nein | Berufsbezeichnung des Hauptkontakts. |\n| `MainContact_JobFunction` | nvarchar(200) | Nein | Funktion des Hauptkontakts. |\n| `MainContact_Phone` | varchar(200) | Nein | Telefonnummer des Hauptkontakts. |\n| `MainContact_MobilePhone` | varchar(200) | Nein | Mobilnummer des Hauptkontakts. |\n| `MainContact_Fax` | nvarchar(200) | Nein | Faxnummer des Hauptkontakts. |\n| `MainContact_Email` | nvarchar(200) | Nein | E-Mail-Adresse des Hauptkontakts. |\n| `SupplierComment` | varchar(8000) | Nein | Kommentar zum Lieferanten; wird in `SupplComment` gespeichert. |\n\n- Alles läuft in der benannten Transaktion `CreateSupplier`. Bei einem SQL-Fehler wird die Transaktion zurückgerollt, und `ErrorMessage` enthält den SQL-Fehlertext. Validierungsfehler sind keine SQL-Fehler: Die Transaktion wird committet, es wurde aber nichts geschrieben.\n- Die Dublettenprüfung auf `SupplNr` verwendet `NOLOCK`. Zwei parallele Aufrufe mit derselben Nummer können die Prüfung daher beide bestehen. Ein eventuell vorhandener Unique-Constraint der Tabelle würde dann den generischen Fehler auslösen.\n- `RowsAffected` wird nie aktualisiert und ist immer `0`.\n- `DefaultDeliveryDays` wird mit einem Leerstring verglichen. Als `int` wird der Wert `0` dadurch als `NULL` gespeichert.\n- Ein Leerstring für `CanDoDirectFulfillment` besteht die Pflichtprüfung und wird als 0 gespeichert.\n- `SupplGroup`, `SupplCtry` und `CurrencyId` werden nicht gegen Stammdaten geprüft.\n- Kann keine Datenbankwährung ermittelt werden, bleibt `CurrencyId` `NULL`.\n- Ein Kontaktdatensatz wird immer angelegt, auch wenn kein `MainContact_*`-Parameter übergeben wird.\n- Werte, die länger als die deklarierte Parameterlänge sind (z. B. `SupplNr` mit mehr als 4 Zeichen), werden unter Umständen stillschweigend abgeschnitten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateSupplier"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 0\n OK\n Supplier with SupplNr: \"L042\" successfully created.\n \n \n"
}
]
},
{
"name": "pixiCreateSupplierOrderFromProfile",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt Lieferantenbestellungen anhand eines gespeicherten Bestellvorschlagsprofils an und liefert die Nummern der erzeugten Bestellungen.\n\nFührt den Bestellvorschlag für ein gespeichertes Profil aus und bestätigt das Ergebnis in einem Schritt. Dadurch werden Lieferantenbestellungen angelegt oder erweitert.\n\nAblauf:\n1. Prüft, ob `ProfileId` übergeben wurde und ob ein Pixi-Benutzer mit dem Namen `API` existiert. Dieser Benutzer wird als ausführender Benutzer weitergegeben.\n2. Liest das Profil-XML aus `pixi.SupplierOrderSuggestionProfile.Data` zur angegebenen `Id`. Fehlen Profil oder Daten, wird eine Fehlerzeile geliefert.\n3. Überträgt die Profileinstellungen unter `/SuggestionProfileDbo` auf die Parameter des Bestellvorschlags:\n - `OrderMethod`: `OrderOnDemand` = 1, `OrderForTargetStock` = 2, `OrderOnStockTurnover` = 3.\n - `SupplierPriority`: `LowestPrice` = 1 (Standard), `FastestDelivery` = 2, `LatestDelivery` = 3.\n - `CalculationSuggestionLocation`: `CalculateSuggestionForEachLocationSeparately` = 0 (Standard), `CalculateSuggestionsBasedOnSummarizedParametersForSelectedLocations` = 1.\n - `ConsiderationOfSuppliers`: `FromSelectedSuppliers` = 0 (Standard), `IfSelectedSupplierIsOptimal` = 1.\n - `SupplierOrdersCreation`: `CreateOnlyNewSupplierOrders` = 0 (Standard), `AddSuggestedItemsToOpenSupplierOrders` = 1.\n - `SelectedLocations/int`, `SelectedSuppliers/int` sowie die Tag-IDs in `TagKeysOr`, `TagKeysAnd` und `TagKeysNot` werden zu kommagetrennten Listen zusammengefasst.\n - `ConsiderPackagingUnit`, `ConsiderMinimumOrderAmount`, `DeliveryLocationId`, `OrderLocationId`, `ExcludeSuppliersWithZeroPrice` und `IncludeOversoldItems` werden direkt übernommen.\n - Nur bei `OrderOnStockTurnover`: `TurnoverInDays`, `ConsiderReorderLevel` und der Verkaufszeitraum. Bei `StockTurnoverSalesOption` = `SalesPerDayForLastXDays` umfasst der Zeitraum die letzten `SalesForLastXDays` Tage bis jetzt, sonst gelten `SalesFrom`/`SalesTo`.\n4. Erzeugt aus der aktuellen Uhrzeit eine Laufnummer (`yyMMddHHmmss`) und ruft `pixi.SupplierOrderSuggestionPrepareData` und danach `pixi.SupplierOrderSuggestionConfirmData` auf. Die Validierung wird beim Bestätigen übersprungen.\n5. Liefert je Lieferantenbestellung dieses Laufs eine Zeile mit der internen Bestellnummer und der Lieferantennummer. Wurde keine Bestellung verknüpft, wird eine `INFO`-Zeile geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ProfileId` | smallint | Nein | Id des Bestellvorschlagsprofils in `pixi.SupplierOrderSuggestionProfile`. Fachlich erforderlich; ohne Angabe wird eine Fehlerzeile geliefert. |\n\n- Das eigentliche Anlegen der Lieferantenbestellungen erfolgt in `pixi.SupplierOrderSuggestionPrepareData` und `pixi.SupplierOrderSuggestionConfirmData`. Deren Definitionen liegen nicht vor, daher sind die beschriebenen Tabellen und die genauen Regeln hier nicht dokumentiert. Beide werden mit `@ShowOutputSet = 0` aufgerufen, was vermutlich deren eigene Ergebnismengen unterdrückt.\n- Die gesamte Verarbeitung läuft in einer Transaktion. Besteht beim Aufrufer bereits eine offene Transaktion, wird stattdessen ein Savepoint gesetzt. Bei einer Ausnahme wird zurückgerollt und statt eines SQL-Fehlers eine `ERROR`-Zeile geliefert.\n- Der Benutzer `API` muss in `UCS_USERS` vorhanden sein. Es gibt keinen Rückgriff auf einen anderen Benutzer.\n- Die Laufnummer wird sekundengenau aus der aktuellen Uhrzeit gebildet. Zwei Aufrufe in derselben Sekunde können dieselbe Nummer erhalten und ihre Ergebnisse vermischen.\n- Werte im Profil, die nicht den genannten Texten entsprechen, lassen die Standardwerte unverändert. Bei unbekannter `OrderMethod` bleibt die Bestellmethode `NULL`.\n- Enthält eine Tag-Liste keine Einträge, wird dafür `NULL` statt einer leeren Zeichenkette übergeben.\n- Profil und Ergebnis werden mit `NOLOCK` gelesen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateSupplierOrderFromProfile"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt Lieferantenbestellungen anhand eines gespeicherten Bestellvorschlagsprofils an und liefert die Nummern der erzeugten Bestellungen.\n\nFührt den Bestellvorschlag für ein gespeichertes Profil aus und bestätigt das Ergebnis in einem Schritt. Dadurch werden Lieferantenbestellungen angelegt oder erweitert.\n\nAblauf:\n1. Prüft, ob `ProfileId` übergeben wurde und ob ein Pixi-Benutzer mit dem Namen `API` existiert. Dieser Benutzer wird als ausführender Benutzer weitergegeben.\n2. Liest das Profil-XML aus `pixi.SupplierOrderSuggestionProfile.Data` zur angegebenen `Id`. Fehlen Profil oder Daten, wird eine Fehlerzeile geliefert.\n3. Überträgt die Profileinstellungen unter `/SuggestionProfileDbo` auf die Parameter des Bestellvorschlags:\n - `OrderMethod`: `OrderOnDemand` = 1, `OrderForTargetStock` = 2, `OrderOnStockTurnover` = 3.\n - `SupplierPriority`: `LowestPrice` = 1 (Standard), `FastestDelivery` = 2, `LatestDelivery` = 3.\n - `CalculationSuggestionLocation`: `CalculateSuggestionForEachLocationSeparately` = 0 (Standard), `CalculateSuggestionsBasedOnSummarizedParametersForSelectedLocations` = 1.\n - `ConsiderationOfSuppliers`: `FromSelectedSuppliers` = 0 (Standard), `IfSelectedSupplierIsOptimal` = 1.\n - `SupplierOrdersCreation`: `CreateOnlyNewSupplierOrders` = 0 (Standard), `AddSuggestedItemsToOpenSupplierOrders` = 1.\n - `SelectedLocations/int`, `SelectedSuppliers/int` sowie die Tag-IDs in `TagKeysOr`, `TagKeysAnd` und `TagKeysNot` werden zu kommagetrennten Listen zusammengefasst.\n - `ConsiderPackagingUnit`, `ConsiderMinimumOrderAmount`, `DeliveryLocationId`, `OrderLocationId`, `ExcludeSuppliersWithZeroPrice` und `IncludeOversoldItems` werden direkt übernommen.\n - Nur bei `OrderOnStockTurnover`: `TurnoverInDays`, `ConsiderReorderLevel` und der Verkaufszeitraum. Bei `StockTurnoverSalesOption` = `SalesPerDayForLastXDays` umfasst der Zeitraum die letzten `SalesForLastXDays` Tage bis jetzt, sonst gelten `SalesFrom`/`SalesTo`.\n4. Erzeugt aus der aktuellen Uhrzeit eine Laufnummer (`yyMMddHHmmss`) und ruft `pixi.SupplierOrderSuggestionPrepareData` und danach `pixi.SupplierOrderSuggestionConfirmData` auf. Die Validierung wird beim Bestätigen übersprungen.\n5. Liefert je Lieferantenbestellung dieses Laufs eine Zeile mit der internen Bestellnummer und der Lieferantennummer. Wurde keine Bestellung verknüpft, wird eine `INFO`-Zeile geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ProfileId` | smallint | Nein | Id des Bestellvorschlagsprofils in `pixi.SupplierOrderSuggestionProfile`. Fachlich erforderlich; ohne Angabe wird eine Fehlerzeile geliefert. |\n\n- Das eigentliche Anlegen der Lieferantenbestellungen erfolgt in `pixi.SupplierOrderSuggestionPrepareData` und `pixi.SupplierOrderSuggestionConfirmData`. Deren Definitionen liegen nicht vor, daher sind die beschriebenen Tabellen und die genauen Regeln hier nicht dokumentiert. Beide werden mit `@ShowOutputSet = 0` aufgerufen, was vermutlich deren eigene Ergebnismengen unterdrückt.\n- Die gesamte Verarbeitung läuft in einer Transaktion. Besteht beim Aufrufer bereits eine offene Transaktion, wird stattdessen ein Savepoint gesetzt. Bei einer Ausnahme wird zurückgerollt und statt eines SQL-Fehlers eine `ERROR`-Zeile geliefert.\n- Der Benutzer `API` muss in `UCS_USERS` vorhanden sein. Es gibt keinen Rückgriff auf einen anderen Benutzer.\n- Die Laufnummer wird sekundengenau aus der aktuellen Uhrzeit gebildet. Zwei Aufrufe in derselben Sekunde können dieselbe Nummer erhalten und ihre Ergebnisse vermischen.\n- Werte im Profil, die nicht den genannten Texten entsprechen, lassen die Standardwerte unverändert. Bei unbekannter `OrderMethod` bleibt die Bestellmethode `NULL`.\n- Enthält eine Tag-Liste keine Einträge, wird dafür `NULL` statt einer leeren Zeichenkette übergeben.\n- Profil und Ergebnis werden mit `NOLOCK` gelesen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiCreateSupplierOrderFromProfile"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n BE-2024-00125\n L1001\n \n \n BE-2024-00126\n L1017\n \n"
}
]
},
{
"name": "pixiDeleteDelivery",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht eine Lieferantenlieferung (Kopf und Positionen) im Status NEW, identifiziert über Lieferungsreferenz oder Lieferungsnummer.\n\nLöscht eine Lieferantenlieferung aus `SDelHeader` zusammen mit ihren Positionen in `SDelDetail`.\n\n1. Mindestens einer der Parameter `SDelHkey` oder `DeliveryNumber` muss angegeben werden; andernfalls wird ein Fehler ausgelöst und die Prozedur gibt `-1` zurück.\n2. Ist nur `DeliveryNumber` angegeben, wird der Lieferungsschlüssel in `SDelHeader` über `SDelHNr` ermittelt (erster Treffer, ohne definierte Sortierung). Ist `SDelHkey` angegeben, wird dieser verwendet und `DeliveryNumber` ignoriert; die beiden Werte werden nicht gegeneinander geprüft.\n3. Die Lieferung wird nur gelöscht, wenn sie\n - nicht durch Picco gesperrt ist (`LockedByPicco` ungleich `Y`) **oder** durch Picco für denselben in `PiccoUser` übergebenen Benutzer gesperrt ist, und\n - den Status `NULL` oder `NEW` hat.\n4. Sind diese Bedingungen erfüllt, läuft die interne Löschroutine:\n - alle Lieferpositionen (`SDelDetail`) der Lieferung werden gelöscht,\n - Einträge in `InvBinItemLog_In_Price`, die auf die Lieferung verweisen (über `DeliveryId` oder `DeliveryId_Assigned`), werden entkoppelt: Lieferungsbezüge und `SupplierId` werden auf `NULL`, `Price` auf `0`, `QuerySource` auf `7` und `RecordModifiedOn` auf die aktuelle Zeit gesetzt,\n - der Lieferungskopf (`SDelHeader`) wird gelöscht.\n Anschließend wird die Zeile `ReturnMSG` = `Deleting was successfull` geliefert.\n5. Andernfalls wird die Zeile `ReturnMSG` = `Delivery Header does not exists` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHkey` | int | Nein | Interner Schlüssel der Lieferantenlieferung (`SDelHeader.SDelHKey`). Hat Vorrang vor `DeliveryNumber`. Dieser Wert oder `DeliveryNumber` ist erforderlich. |\n| `DeliveryNumber` | int | Nein | Lieferungsnummer (`SDelHeader.SDelHNr`). Wird zur Ermittlung des Lieferungsschlüssels verwendet, wenn `SDelHkey` nicht angegeben ist. |\n| `PiccoUser` | varchar(50) | Nein | Picco-Benutzername. Eine durch Picco gesperrte Lieferung kann nur gelöscht werden, wenn dieser Wert dem in `SDelHeader.PiccoUser` gespeicherten Benutzer entspricht. |\n\n- Die Prüfung auf fehlende Werte verwendet `ISNULL(..., '')`; bei `int`-Parametern wird der Wert `0` wie \"nicht angegeben\" behandelt.\n- Die Meldung `Delivery Header does not exists` wird auch geliefert, wenn die Lieferung existiert, aber durch Picco für einen anderen Benutzer gesperrt ist oder einen anderen Status als `NULL`/`NEW` hat.\n- Die Vorprüfung akzeptiert den Status `NULL`, die interne Löschroutine löscht jedoch nur Lieferungen mit Status exakt `NEW`. Bei einer Lieferung mit Status `NULL` wird nichts gelöscht, trotzdem wird `Deleting was successfull` geliefert.\n- Das interne Löschen läuft in einer eigenen Transaktion (bzw. einem Savepoint, falls bereits eine Transaktion offen ist). Fehler werden abgefangen, zurückgerollt und über `log.InsertError` protokolliert; sie werden **nicht** an den Aufrufer weitergegeben, und die Erfolgsmeldung wird dennoch geliefert. Das Ergebnis sollte bei Bedarf geprüft werden.\n- Lieferung und Positionen werden vor dem Löschen mit `NOLOCK` gelesen; Löschungen und Aktualisierungen verwenden `ROWLOCK`.\n- Bei der Suche über `DeliveryNumber` führt eine mehrfach vorhandene Nummer dazu, dass eine beliebige Lieferung gewählt wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDeleteDelivery"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht eine Lieferantenlieferung (Kopf und Positionen) im Status NEW, identifiziert über Lieferungsreferenz oder Lieferungsnummer.\n\nLöscht eine Lieferantenlieferung aus `SDelHeader` zusammen mit ihren Positionen in `SDelDetail`.\n\n1. Mindestens einer der Parameter `SDelHkey` oder `DeliveryNumber` muss angegeben werden; andernfalls wird ein Fehler ausgelöst und die Prozedur gibt `-1` zurück.\n2. Ist nur `DeliveryNumber` angegeben, wird der Lieferungsschlüssel in `SDelHeader` über `SDelHNr` ermittelt (erster Treffer, ohne definierte Sortierung). Ist `SDelHkey` angegeben, wird dieser verwendet und `DeliveryNumber` ignoriert; die beiden Werte werden nicht gegeneinander geprüft.\n3. Die Lieferung wird nur gelöscht, wenn sie\n - nicht durch Picco gesperrt ist (`LockedByPicco` ungleich `Y`) **oder** durch Picco für denselben in `PiccoUser` übergebenen Benutzer gesperrt ist, und\n - den Status `NULL` oder `NEW` hat.\n4. Sind diese Bedingungen erfüllt, läuft die interne Löschroutine:\n - alle Lieferpositionen (`SDelDetail`) der Lieferung werden gelöscht,\n - Einträge in `InvBinItemLog_In_Price`, die auf die Lieferung verweisen (über `DeliveryId` oder `DeliveryId_Assigned`), werden entkoppelt: Lieferungsbezüge und `SupplierId` werden auf `NULL`, `Price` auf `0`, `QuerySource` auf `7` und `RecordModifiedOn` auf die aktuelle Zeit gesetzt,\n - der Lieferungskopf (`SDelHeader`) wird gelöscht.\n Anschließend wird die Zeile `ReturnMSG` = `Deleting was successfull` geliefert.\n5. Andernfalls wird die Zeile `ReturnMSG` = `Delivery Header does not exists` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHkey` | int | Nein | Interner Schlüssel der Lieferantenlieferung (`SDelHeader.SDelHKey`). Hat Vorrang vor `DeliveryNumber`. Dieser Wert oder `DeliveryNumber` ist erforderlich. |\n| `DeliveryNumber` | int | Nein | Lieferungsnummer (`SDelHeader.SDelHNr`). Wird zur Ermittlung des Lieferungsschlüssels verwendet, wenn `SDelHkey` nicht angegeben ist. |\n| `PiccoUser` | varchar(50) | Nein | Picco-Benutzername. Eine durch Picco gesperrte Lieferung kann nur gelöscht werden, wenn dieser Wert dem in `SDelHeader.PiccoUser` gespeicherten Benutzer entspricht. |\n\n- Die Prüfung auf fehlende Werte verwendet `ISNULL(..., '')`; bei `int`-Parametern wird der Wert `0` wie \"nicht angegeben\" behandelt.\n- Die Meldung `Delivery Header does not exists` wird auch geliefert, wenn die Lieferung existiert, aber durch Picco für einen anderen Benutzer gesperrt ist oder einen anderen Status als `NULL`/`NEW` hat.\n- Die Vorprüfung akzeptiert den Status `NULL`, die interne Löschroutine löscht jedoch nur Lieferungen mit Status exakt `NEW`. Bei einer Lieferung mit Status `NULL` wird nichts gelöscht, trotzdem wird `Deleting was successfull` geliefert.\n- Das interne Löschen läuft in einer eigenen Transaktion (bzw. einem Savepoint, falls bereits eine Transaktion offen ist). Fehler werden abgefangen, zurückgerollt und über `log.InsertError` protokolliert; sie werden **nicht** an den Aufrufer weitergegeben, und die Erfolgsmeldung wird dennoch geliefert. Das Ergebnis sollte bei Bedarf geprüft werden.\n- Lieferung und Positionen werden vor dem Löschen mit `NOLOCK` gelesen; Löschungen und Aktualisierungen verwenden `ROWLOCK`.\n- Bei der Suche über `DeliveryNumber` führt eine mehrfach vorhandene Nummer dazu, dass eine beliebige Lieferung gewählt wird.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDeleteDelivery"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Deleting was successfull\n \n"
}
]
},
{
"name": "pixiDeleteDeliveryItem",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht eine oder mehrere Artikelpositionen aus einer Lieferantenlieferung, identifiziert über Positionsschlüssel, interne Artikelnummer oder EAN.\n\nEntfernt Artikelpositionen (`SDelDetail`) aus einer Lieferantenlieferung (`SDelHeader`).\n\n**Bestimmung der Lieferung.** Anzugeben ist entweder `SDelHKey` oder `DeliveryNumber`, die mit `SDelHNr` verglichen wird. Ist nur `DeliveryNumber` angegeben, wird der erste passende `SDelHKey` verwendet.\n\n**Bestimmung der Positionen.** Anzugeben ist mindestens einer der Werte `SDelDKey`, `ItemNrInternal` oder `EANUPC`.\n\n**Prüfungen in dieser Reihenfolge:**\n1. Eine Lieferungsreferenz oder Lieferungsnummer ist vorhanden.\n2. Eine Artikelkennung ist vorhanden.\n3. Die Lieferung ist nicht durch Picco gesperrt (`LockedByPicco` ist NULL).\n4. Der `SDelDKey` existiert in `SDelDetail`, sofern angegeben.\n5. Die `EANUPC` existiert in `Items`, sofern angegeben.\n6. Die `ItemNrInternal` existiert in `Items` (`ItemNrInt`), sofern angegeben.\n7. Die Lieferung existiert und hat nicht den Status `CLS` (abgeschlossen) oder `INV` (berechnet).\n\nSchlägt eine Prüfung fehl, wird ein Fehler ausgelöst und nichts gelöscht.\n\n**Löschen.**\n- Ist `SDelDKey` angegeben, wird genau diese Lieferposition gelöscht. `ItemNrInternal` und `EANUPC` werden dann für das Löschen ignoriert.\n- Andernfalls werden alle Positionen der Lieferung gelöscht, deren Artikel zu `ItemNrInternal` **oder** `EANUPC` passt. Dabei können mehrere Positionen entfernt werden.\n\nDer Aufruf liefert keine Ergebnismenge.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | Nein | Interner Schlüssel der Lieferantenlieferung (`SDelHeader.SDelHKey`). Dieser Wert oder `DeliveryNumber` ist erforderlich. |\n| `DeliveryNumber` | int | Nein | Lieferungsnummer (`SDelHeader.SDelHNr`). Wird zur Ermittlung des Lieferungsschlüssels verwendet, wenn `SDelHKey` nicht angegeben ist. |\n| `SDelDKey` | int | Nein | Schlüssel der zu löschenden Lieferposition (`SDelDetail.SDelDkey`). Ist er angegeben, wird nur diese Position gelöscht. |\n| `ItemNrInternal` | varchar(50) | Nein | Interne Artikelnummer (`Items.ItemNrInt`). Ohne `SDelDKey` werden alle Positionen der Lieferung mit diesem Artikel gelöscht. |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC des Artikels (`Items.EANUPC`). Ohne `SDelDKey` werden alle Positionen der Lieferung mit diesem Artikel gelöscht. |\n\n- **Positionsschlüssel wird nicht gegen die Lieferung geprüft.** Beim Löschen über `SDelDKey` prüft der Code nicht, ob die Position zur angegebenen Lieferung gehört. Status- und Sperrprüfung beziehen sich auf die übergebene Lieferung, die Position mit diesem Schlüssel wird aber auch dann gelöscht, wenn sie zu einer anderen Lieferung gehört.\n- **Unbekannte Lieferungsnummer führt zu irreführendem Fehler.** Passt `DeliveryNumber` zu keiner Lieferung, bleibt der Schlüssel NULL. Der Aufruf scheitert dann mit `You cant delete items from closed or invoiced deliveries.`\n- **Artikelprüfungen sind global.** Die Prüfungen von `EANUPC` und `ItemNrInternal` testen nur, ob der Artikel in `Items` existiert. Existiert der Artikel, ist aber nicht in der Lieferung enthalten, wird nichts gelöscht und kein Fehler ausgelöst.\n- **Beide Kennungen werden mit ODER verknüpft.** Sind ohne `SDelDKey` sowohl `ItemNrInternal` als auch `EANUPC` angegeben, werden Positionen gelöscht, die zu einem der beiden Werte passen.\n- **Null gilt als leer.** Leere Werte werden in NULL umgewandelt. Da die Integer-Parameter mit `''` verglichen werden, gilt auch der Wert `0` für `SDelHKey`, `DeliveryNumber` oder `SDelDKey` als nicht angegeben.\n- **Keine Transaktion und ungesperrtes Lesen.** Die Prozedur verwendet keine explizite Transaktion. Das Sperrkennzeichen `LockedByPicco` wird `WITH (NOLOCK)` gelesen.\n- **Rückgabewert.** Bei Fehlern gibt die Prozedur nach `RAISERROR` mit Schweregrad 16 den Wert `-1` zurück.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDeleteDeliveryItem"
},
"response": []
},
{
"name": "pixiDispoClearSOrderlinesOnNEW",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht alle Positionen und anschließend die leeren Lieferantenbestellungen im Status NEW, die vom angegebenen Benutzer angelegt wurden.\n\nBereinigt Lieferantenbestellungen (Disposition), die sich noch im Status NEW (`StatusId = 1`) befinden, für einen anlegenden Benutzer.\n\n1. Die Einstellung `LogControl_DoNotDeleteOrderlinesOnNew` wird gelesen. Ist sie `1`, führt der Aufruf nichts aus.\n2. `@CreateEmp` wird über `inf.UserGetByName` in eine Benutzer-ID aufgelöst. Ein Ersatzbenutzer wird nicht verwendet.\n3. Alle Zeilen in `pixi.SupplierOrderLine` werden gelöscht, die zu Lieferantenbestellungen mit `StatusId = 1` und `RecordCreatedByUserId` gleich dieser Benutzer-ID gehören.\n4. Die Lieferantenbestellungen mit `StatusId = 1`, die von diesem Benutzer angelegt wurden und keine Positionen mehr haben, werden gelöscht.\n\nBetroffen sind nur Bestellungen des angegebenen Benutzers. Bestellungen anderer Benutzer und Bestellungen in anderen Status bleiben unverändert. Der Aufruf liefert keine Ergebnismenge.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `CreateEmp` | varchar(50) | Nein | Benutzername (aus `UCS_USERS`), dessen Lieferantenbestellungen im Status NEW samt Positionen gelöscht werden. |\n\n- Existiert `@CreateEmp` nicht in `UCS_USERS`, ist die Benutzer-ID `NULL` und es wird nichts gelöscht. Eine Rückmeldung erfolgt in diesem Fall nicht.\n- Fehlt die Einstellung `LogControl_DoNotDeleteOrderlinesOnNew`, gilt sie als `0`, und die Löschung wird ausgeführt.\n- Beide `DELETE`-Anweisungen laufen ohne explizite Transaktion. Die Unterabfragen lesen mit `NOLOCK`.\n- Die Bestellungen werden mit einer `NOT IN`-Prüfung gegen alle `SupplierOrderId`-Werte aus `pixi.SupplierOrderLine` gelöscht. Hat eine Position eine `SupplierOrderId` mit `NULL`, wird keine Bestellung gelöscht.\n- Eine frühere Löschung der Historie (`SOrderlinesHist`) ist auskommentiert und wird nicht ausgeführt.\n- Die Löschung ist endgültig. Der Aufruf liefert keine Zeilen und keine Zeilenanzahl.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDispoClearSOrderlinesOnNEW"
},
"response": []
},
{
"name": "pixiDispoGetOpenSupplierOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert offene Lieferantenbestellpositionen und Auftragspositionen im Status ANG mit offener Menge und erwartetem Liefertermin, seitenweise nach Positionsschlüssel.\n\nSammelt offene Bestellmengen für die Disposition aus zwei Quellen und liefert sie als gemeinsame Liste.\n\n**Typ `1200` – Lieferantenbestellpositionen** (`pixi.SupplierOrderLine`):\n- Nur Positionen, deren Lieferantenbestellung einen Status mit `IsOrderedConfirmed = 1` hat (bestellt bzw. bestätigt).\n- Nur Positionen mit einer offenen Menge ungleich 0. Die offene Menge ist `Qty - DeliveredQty - UndeliveredQty`, fehlende Werte zählen als 0.\n- `EstimatedDeliveryDate` ist der erwartete Liefertermin der Position oder `'0'`, wenn keiner gesetzt ist.\n- `SupplOrderNR` ist die interne Nummer der Lieferantenbestellung. `SupplOrderDate` ist das Anlagedatum der Position.\n\n**Typ `2200` – Auftragspositionen im Status `ANG`** (`Orderlines`):\n- Nur Positionen mit `Status = 'ANG'` und einer Menge ungleich 0.\n- `Qty` und `QtyOrdered` entsprechen der Positionsmenge. `QtyReceived` und `QtyNotDelivered` sind immer 0.\n- `EstimatedDeliveryDate` ist das heutige Datum plus `DefaultDeliveryDays` des Lieferanten. Ohne Wert beim Lieferanten wird 1 Tag verwendet.\n- `SupplOrderNR` ist die Auftragsnummer. `SupplOrderDate` ist das Anlagedatum der Position.\n\nFür beide Typen stammen die Artikeldaten (`SupplNr`, `ItemNrInt`, `ItemNrSuppl`) per Left Join aus `Items`. `ItemNrSuppl` fällt auf `ItemNrInt` zurück, wenn der Artikel keine Lieferantenartikelnummer hat.\n\n**Paging:** Es werden nur Positionen geliefert, deren Schlüssel größer als `SOrderlineKeyStart` ist. Die gemeinsame Liste wird aufsteigend nach `SOrderlineKey` sortiert und auf `RowCount` Zeilen begrenzt. Für die nächste Seite wird der zuletzt erhaltene `SOrderlineKey` als neuer `SOrderlineKeyStart` übergeben.\n\nAlle Datumswerte werden als Text im Format `dd.mm.yyyy` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SOrderlineKeyStart` | int | Nein | Es werden nur Positionen mit einem Schlüssel größer als dieser Wert geliefert. Dient dem Paging; NULL wird als 0 behandelt. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. NULL wird als 10000 behandelt. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher kann das Ergebnis nicht festgeschriebene Daten enthalten.\n- `SOrderlineKey` stammt aus zwei verschiedenen Schlüsselräumen: `SupplierOrderLine.Id` für Typ `1200` und `Orderlines.OrderlineKey` für Typ `2200`. Derselbe Schlüsselwert kann daher in beiden Typen vorkommen.\n - Das Paging verwendet eine gemeinsame Schwelle für beide Quellen.\n - Endet eine Seite mitten in einem solchen doppelten Schlüssel, wird die verbleibende Zeile mit diesem Schlüssel auf der nächsten Seite übersprungen.\n - `Type` sollte immer zusammen mit `SOrderlineKey` ausgewertet werden.\n- Die beiden Quellen werden mit `UNION` verbunden, vollständig identische Zeilen erscheinen daher nur einmal.\n- Ist `RowCount` NULL, wird 10000 verwendet.\n- `EstimatedDeliveryDate` für Typ `2200` wird aus dem aktuellen Serverdatum zum Zeitpunkt des Aufrufs berechnet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDispoGetOpenSupplierOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert offene Lieferantenbestellpositionen und Auftragspositionen im Status ANG mit offener Menge und erwartetem Liefertermin, seitenweise nach Positionsschlüssel.\n\nSammelt offene Bestellmengen für die Disposition aus zwei Quellen und liefert sie als gemeinsame Liste.\n\n**Typ `1200` – Lieferantenbestellpositionen** (`pixi.SupplierOrderLine`):\n- Nur Positionen, deren Lieferantenbestellung einen Status mit `IsOrderedConfirmed = 1` hat (bestellt bzw. bestätigt).\n- Nur Positionen mit einer offenen Menge ungleich 0. Die offene Menge ist `Qty - DeliveredQty - UndeliveredQty`, fehlende Werte zählen als 0.\n- `EstimatedDeliveryDate` ist der erwartete Liefertermin der Position oder `'0'`, wenn keiner gesetzt ist.\n- `SupplOrderNR` ist die interne Nummer der Lieferantenbestellung. `SupplOrderDate` ist das Anlagedatum der Position.\n\n**Typ `2200` – Auftragspositionen im Status `ANG`** (`Orderlines`):\n- Nur Positionen mit `Status = 'ANG'` und einer Menge ungleich 0.\n- `Qty` und `QtyOrdered` entsprechen der Positionsmenge. `QtyReceived` und `QtyNotDelivered` sind immer 0.\n- `EstimatedDeliveryDate` ist das heutige Datum plus `DefaultDeliveryDays` des Lieferanten. Ohne Wert beim Lieferanten wird 1 Tag verwendet.\n- `SupplOrderNR` ist die Auftragsnummer. `SupplOrderDate` ist das Anlagedatum der Position.\n\nFür beide Typen stammen die Artikeldaten (`SupplNr`, `ItemNrInt`, `ItemNrSuppl`) per Left Join aus `Items`. `ItemNrSuppl` fällt auf `ItemNrInt` zurück, wenn der Artikel keine Lieferantenartikelnummer hat.\n\n**Paging:** Es werden nur Positionen geliefert, deren Schlüssel größer als `SOrderlineKeyStart` ist. Die gemeinsame Liste wird aufsteigend nach `SOrderlineKey` sortiert und auf `RowCount` Zeilen begrenzt. Für die nächste Seite wird der zuletzt erhaltene `SOrderlineKey` als neuer `SOrderlineKeyStart` übergeben.\n\nAlle Datumswerte werden als Text im Format `dd.mm.yyyy` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SOrderlineKeyStart` | int | Nein | Es werden nur Positionen mit einem Schlüssel größer als dieser Wert geliefert. Dient dem Paging; NULL wird als 0 behandelt. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. NULL wird als 10000 behandelt. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher kann das Ergebnis nicht festgeschriebene Daten enthalten.\n- `SOrderlineKey` stammt aus zwei verschiedenen Schlüsselräumen: `SupplierOrderLine.Id` für Typ `1200` und `Orderlines.OrderlineKey` für Typ `2200`. Derselbe Schlüsselwert kann daher in beiden Typen vorkommen.\n - Das Paging verwendet eine gemeinsame Schwelle für beide Quellen.\n - Endet eine Seite mitten in einem solchen doppelten Schlüssel, wird die verbleibende Zeile mit diesem Schlüssel auf der nächsten Seite übersprungen.\n - `Type` sollte immer zusammen mit `SOrderlineKey` ausgewertet werden.\n- Die beiden Quellen werden mit `UNION` verbunden, vollständig identische Zeilen erscheinen daher nur einmal.\n- Ist `RowCount` NULL, wird 10000 verwendet.\n- `EstimatedDeliveryDate` für Typ `2200` wird aus dem aktuellen Serverdatum zum Zeitpunkt des Aufrufs berechnet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiDispoGetOpenSupplierOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n 2381\n 15.07.2024\n 8\n 1200\n 104\n ART-4711\n LF-88231\n 02.07.2024\n B-2024-0815\n 10\n 2\n 0\n \n \n 10467\n 5120\n 11.07.2024\n 3\n 2200\n 217\n ART-9902\n ART-9902\n 08.07.2024\n 500123\n 3\n 0\n 0\n \n"
}
]
},
{
"name": "pixiGetDelivery",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kopfdaten von Lieferantenlieferungen (Wareneingängen), gefiltert nach Lieferant, Lieferungsnummer, Artikel, Lager, Status, Datum und Picco-Sperre, mit schlüsselbasiertem Paging.\n\nLiefert Datensätze aus der Kopftabelle der Lieferantenlieferungen (`SDelHeader`) zusammen mit dem Lieferantennamen aus `Suppliers` (Left Join über `SDelHSupplNr`).\n\n**Parameterbehandlung**\n- Leere Zeichenketten gelten bei allen Textfiltern als `NULL`. Bei `SDelHKey` und `DeliveryNumber` bedeutet der Wert `0** \"kein Filter\".\n- `RowCount` ist standardmäßig 100. Auch `NULL` und `0` bedeuten 100.\n- `Offset` ist **kein** Zeilen-Offset, sondern ein Schlüssel-Cursor: Es werden nur Lieferungen mit `SDelHKey` > `Offset` geliefert. `0` oder `NULL` bedeutet kein Cursor.\n\n**Filter (alle per UND verknüpft)**\n- `SDelHKey`, `SupplNr`, `DeliveryNumber` (`SDelHNr`), `LocID` (`SDelHLocationID`) und `ExternalReceiptNr`: exakte Übereinstimmung.\n- Status: Standardmäßig werden abgeschlossene Lieferungen (`SDelHStatus` = `CLS`) und berechnete Lieferungen (`SDelHStatus` = `INV`) ausgeschlossen. Mit `Closed` = 1 bzw. `Invoice` = 1 werden sie einbezogen.\n- Anlagedatum: `SDelHCreateDate` zwischen `CreateDateFrom` und `CreateDateTo`. Hat `CreateDateTo` die Uhrzeit 00:00:00, wird der Wert auf das Tagesende gesetzt.\n- Änderungsdatum: `SDelHUpdateDate` zwischen `UpdateDateFrom` und `UpdateDateTo`, mit derselben Tagesende-Regel.\n- Artikelfilter: Ist mindestens einer der Parameter `ItemNrInt`, `ItemNrSuppl`, `EANUPC` oder `ItemName` gesetzt, werden nur Lieferungen geliefert, die mindestens eine Lieferposition (`SDelDetail`) zu einem passenden Artikel enthalten. Alle angegebenen Artikelwerte müssen exakt auf denselben Artikel passen.\n- Picco-Benutzer: Ist `PiccoUser` gesetzt, werden Lieferungen ausgeschlossen, die per Picco (`LockedByPicco` = `Y`) für einen anderen Picco-Benutzer gesperrt sind. Nicht gesperrte Lieferungen und Lieferungen, die für den angegebenen Benutzer gesperrt sind, werden geliefert.\n\n**Sortierung und Paging**\nDas Ergebnis ist aufsteigend nach `SDelHKey` sortiert. Es werden höchstens `RowCount` Zeilen geliefert. Für die nächste Seite wird der zuletzt erhaltene `SDelHKey` als `Offset` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | Nein | Interner Schlüssel einer Lieferantenlieferung. `0` oder NULL bedeutet kein Filter. |\n| `SupplNr` | varchar(200) | Nein | Lieferantennummer (`SDelHSupplNr`), exakte Übereinstimmung. |\n| `DeliveryNumber` | int | Nein | Lieferungsnummer (`SDelHNr`). `0` oder NULL bedeutet kein Filter. |\n| `ItemNrInt` | varchar(200) | Nein | Interne Artikelnummer. Liefert nur Lieferungen mit einer Position zu diesem Artikel. |\n| `ItemNrSuppl` | varchar(200) | Nein | Lieferantenartikelnummer. Liefert nur Lieferungen mit einer Position zu einem passenden Artikel. |\n| `EANUPC` | varchar(200) | Nein | EAN/UPC des Artikels. Liefert nur Lieferungen mit einer Position zu einem passenden Artikel. |\n| `ItemName` | varchar(200) | Nein | Artikelname, exakte Übereinstimmung. Liefert nur Lieferungen mit einer Position zu einem passenden Artikel. |\n| `RowCount` | int | Nein | Maximale Anzahl Zeilen. NULL oder `0` bedeutet 100. |\n| `Offset` | int | Nein | Schlüssel-Cursor für das Paging: Es werden nur Lieferungen mit `SDelHKey` größer als dieser Wert geliefert. Den letzten `SDelHKey` der vorherigen Seite übergeben. |\n| `Closed` | bit | Nein | Abgeschlossene Lieferungen (Status `CLS`) einbeziehen. |\n| `Invoice` | bit | Nein | Berechnete Lieferungen (Status `INV`) einbeziehen. |\n| `LocID` | varchar(3) | Nein | Lager-ID (`SDelHLocationID`), exakte Übereinstimmung. |\n| `PiccoUser` | varchar(50) | Nein | Picco-Benutzer. Ist er gesetzt, werden Lieferungen ausgeschlossen, die per Picco für einen anderen Benutzer gesperrt sind. |\n| `CreateDateFrom` | datetime | Nein | Beginn des Anlagedatum-Bereichs. Muss zusammen mit `CreateDateTo` verwendet werden. |\n| `CreateDateTo` | datetime | Nein | Ende des Anlagedatum-Bereichs. Bei Uhrzeit 00:00:00 wird der Wert auf das Tagesende gesetzt. |\n| `UpdateDateFrom` | datetime | Nein | Beginn des Änderungsdatum-Bereichs. Muss zusammen mit `UpdateDateTo` verwendet werden. |\n| `UpdateDateTo` | datetime | Nein | Ende des Änderungsdatum-Bereichs. Bei Uhrzeit 00:00:00 wird der Wert auf das Tagesende gesetzt. |\n| `ExternalReceiptNr` | varchar(50) | Nein | Externe Belegnummer, exakte Übereinstimmung. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen. Das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Datumsbereiche benötigen **beide** Grenzen. Ist nur `CreateDateFrom` oder nur `CreateDateTo` gesetzt, vergleicht `BETWEEN` mit `NULL`, und es werden keine Zeilen geliefert. Dasselbe gilt für das Paar zum Änderungsdatum.\n- Die Tagesende-Anpassung nutzt `fPixi_GetDateEndOfDay`. Deren Definition liegt nicht vor, daher ist die genaue Uhrzeit des Tagesendes nicht bekannt. `CreateDateFrom`/`UpdateDateFrom` werden unverändert verwendet und nicht auf den Tagesbeginn gesetzt.\n- Lieferungen, die per Picco gesperrt sind und keinen Wert in `PiccoUser` haben, werden bei Übergabe von `PiccoUser` ebenfalls ausgeschlossen.\n- Ein negativer Wert für `RowCount` führt zu einem SQL-Fehler bei `TOP`.\n- Der Artikelfilter prüft auf exakte Gleichheit; `ItemName` unterstützt keine Platzhalter.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetDelivery"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Kopfdaten von Lieferantenlieferungen (Wareneingängen), gefiltert nach Lieferant, Lieferungsnummer, Artikel, Lager, Status, Datum und Picco-Sperre, mit schlüsselbasiertem Paging.\n\nLiefert Datensätze aus der Kopftabelle der Lieferantenlieferungen (`SDelHeader`) zusammen mit dem Lieferantennamen aus `Suppliers` (Left Join über `SDelHSupplNr`).\n\n**Parameterbehandlung**\n- Leere Zeichenketten gelten bei allen Textfiltern als `NULL`. Bei `SDelHKey` und `DeliveryNumber` bedeutet der Wert `0** \"kein Filter\".\n- `RowCount` ist standardmäßig 100. Auch `NULL` und `0` bedeuten 100.\n- `Offset` ist **kein** Zeilen-Offset, sondern ein Schlüssel-Cursor: Es werden nur Lieferungen mit `SDelHKey` > `Offset` geliefert. `0` oder `NULL` bedeutet kein Cursor.\n\n**Filter (alle per UND verknüpft)**\n- `SDelHKey`, `SupplNr`, `DeliveryNumber` (`SDelHNr`), `LocID` (`SDelHLocationID`) und `ExternalReceiptNr`: exakte Übereinstimmung.\n- Status: Standardmäßig werden abgeschlossene Lieferungen (`SDelHStatus` = `CLS`) und berechnete Lieferungen (`SDelHStatus` = `INV`) ausgeschlossen. Mit `Closed` = 1 bzw. `Invoice` = 1 werden sie einbezogen.\n- Anlagedatum: `SDelHCreateDate` zwischen `CreateDateFrom` und `CreateDateTo`. Hat `CreateDateTo` die Uhrzeit 00:00:00, wird der Wert auf das Tagesende gesetzt.\n- Änderungsdatum: `SDelHUpdateDate` zwischen `UpdateDateFrom` und `UpdateDateTo`, mit derselben Tagesende-Regel.\n- Artikelfilter: Ist mindestens einer der Parameter `ItemNrInt`, `ItemNrSuppl`, `EANUPC` oder `ItemName` gesetzt, werden nur Lieferungen geliefert, die mindestens eine Lieferposition (`SDelDetail`) zu einem passenden Artikel enthalten. Alle angegebenen Artikelwerte müssen exakt auf denselben Artikel passen.\n- Picco-Benutzer: Ist `PiccoUser` gesetzt, werden Lieferungen ausgeschlossen, die per Picco (`LockedByPicco` = `Y`) für einen anderen Picco-Benutzer gesperrt sind. Nicht gesperrte Lieferungen und Lieferungen, die für den angegebenen Benutzer gesperrt sind, werden geliefert.\n\n**Sortierung und Paging**\nDas Ergebnis ist aufsteigend nach `SDelHKey` sortiert. Es werden höchstens `RowCount` Zeilen geliefert. Für die nächste Seite wird der zuletzt erhaltene `SDelHKey` als `Offset` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | Nein | Interner Schlüssel einer Lieferantenlieferung. `0` oder NULL bedeutet kein Filter. |\n| `SupplNr` | varchar(200) | Nein | Lieferantennummer (`SDelHSupplNr`), exakte Übereinstimmung. |\n| `DeliveryNumber` | int | Nein | Lieferungsnummer (`SDelHNr`). `0` oder NULL bedeutet kein Filter. |\n| `ItemNrInt` | varchar(200) | Nein | Interne Artikelnummer. Liefert nur Lieferungen mit einer Position zu diesem Artikel. |\n| `ItemNrSuppl` | varchar(200) | Nein | Lieferantenartikelnummer. Liefert nur Lieferungen mit einer Position zu einem passenden Artikel. |\n| `EANUPC` | varchar(200) | Nein | EAN/UPC des Artikels. Liefert nur Lieferungen mit einer Position zu einem passenden Artikel. |\n| `ItemName` | varchar(200) | Nein | Artikelname, exakte Übereinstimmung. Liefert nur Lieferungen mit einer Position zu einem passenden Artikel. |\n| `RowCount` | int | Nein | Maximale Anzahl Zeilen. NULL oder `0` bedeutet 100. |\n| `Offset` | int | Nein | Schlüssel-Cursor für das Paging: Es werden nur Lieferungen mit `SDelHKey` größer als dieser Wert geliefert. Den letzten `SDelHKey` der vorherigen Seite übergeben. |\n| `Closed` | bit | Nein | Abgeschlossene Lieferungen (Status `CLS`) einbeziehen. |\n| `Invoice` | bit | Nein | Berechnete Lieferungen (Status `INV`) einbeziehen. |\n| `LocID` | varchar(3) | Nein | Lager-ID (`SDelHLocationID`), exakte Übereinstimmung. |\n| `PiccoUser` | varchar(50) | Nein | Picco-Benutzer. Ist er gesetzt, werden Lieferungen ausgeschlossen, die per Picco für einen anderen Benutzer gesperrt sind. |\n| `CreateDateFrom` | datetime | Nein | Beginn des Anlagedatum-Bereichs. Muss zusammen mit `CreateDateTo` verwendet werden. |\n| `CreateDateTo` | datetime | Nein | Ende des Anlagedatum-Bereichs. Bei Uhrzeit 00:00:00 wird der Wert auf das Tagesende gesetzt. |\n| `UpdateDateFrom` | datetime | Nein | Beginn des Änderungsdatum-Bereichs. Muss zusammen mit `UpdateDateTo` verwendet werden. |\n| `UpdateDateTo` | datetime | Nein | Ende des Änderungsdatum-Bereichs. Bei Uhrzeit 00:00:00 wird der Wert auf das Tagesende gesetzt. |\n| `ExternalReceiptNr` | varchar(50) | Nein | Externe Belegnummer, exakte Übereinstimmung. |\n\n- Alle Tabellen werden `WITH (NOLOCK)` gelesen. Das Ergebnis kann nicht festgeschriebene Daten enthalten.\n- Datumsbereiche benötigen **beide** Grenzen. Ist nur `CreateDateFrom` oder nur `CreateDateTo` gesetzt, vergleicht `BETWEEN` mit `NULL`, und es werden keine Zeilen geliefert. Dasselbe gilt für das Paar zum Änderungsdatum.\n- Die Tagesende-Anpassung nutzt `fPixi_GetDateEndOfDay`. Deren Definition liegt nicht vor, daher ist die genaue Uhrzeit des Tagesendes nicht bekannt. `CreateDateFrom`/`UpdateDateFrom` werden unverändert verwendet und nicht auf den Tagesbeginn gesetzt.\n- Lieferungen, die per Picco gesperrt sind und keinen Wert in `PiccoUser` haben, werden bei Übergabe von `PiccoUser` ebenfalls ausgeschlossen.\n- Ein negativer Wert für `RowCount` führt zu einem SQL-Fehler bei `TOP`.\n- Der Artikelfilter prüft auf exakte Gleichheit; `ItemName` unterstützt keine Platzhalter.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetDelivery"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 15234\n L1001\n 2024-03-12T00:00:00\n 001\n 4711\n Teillieferung\n OPN\n 2024-03-12T08:15:22\n MM\n 2024-03-12T09:40:03\n MM\n RE-88231\n B-2024-118\n 0\n lager01\n N\n Muster Bürobedarf GmbH\n WE-2024-00315\n \n"
}
]
},
{
"name": "pixiGetDeliveryItem",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Positionen von Lieferantenlieferungen (Wareneingängen) mit Artikeldaten, Preisen, Tags und Chargendetails, gefiltert nach Lieferung, Artikel und Zeitraum.\n\nLiest Lieferpositionen aus `SDelDetail` zusammen mit dem Lieferkopf (`SDelHeader`) und liefert eine Zeile pro Position.\n\n**Normalisierung der Parameter**\n- `0` bei `SDelHKey`/`DeliveryNumber` und Leerstrings bei `ItemNrInternal`/`EANUPC` gelten als nicht gesetzt.\n- `RowCount` ist bei NULL standardmäßig 100, `Offset` standardmäßig 0.\n\n**Auflösung der Filter**\n- **Artikel:** `ItemNrInternal` wird als interne Artikelnummer und `EANUPC` als EAN in der Artikelcode-Tabelle gesucht. Sind beide angegeben, wird der erste Artikel verwendet, auf den *einer* der beiden Codes passt.\n- **Lieferung:** Ist `SDelHKey` nicht gesetzt, wird `DeliveryNumber` auf den Schlüssel der ersten Lieferung mit dieser Nummer aufgelöst. Ist `SDelHKey` gesetzt, wird `DeliveryNumber` ignoriert.\n- **Startdatum:** Ist `DateFrom` leer und eine Lieferung bekannt, ist das Startdatum der Tag der ältesten Position dieser Lieferung. Andernfalls gilt standardmäßig heute minus 700 Tage.\n- **Enddatum:** `DateTo` ist standardmäßig heute plus 365 Tage.\n\n**Auswahl**\nEine Position wird ausgewählt, wenn alle folgenden Bedingungen zutreffen:\n- `SDelDkey` > `Offset`.\n- Sie gehört zur aufgelösten Lieferung, sofern vorhanden.\n- Sie gehört zum aufgelösten Artikel, sofern vorhanden.\n- Ihr Anlagedatum liegt zwischen `DateFrom` (inklusive) und `DateTo` (exklusive).\n\nEs werden die ersten `RowCount` Positionen in aufsteigender `SDelDkey`-Reihenfolge übernommen. Geliefert werden nur Positionen, die auch in der Wareneingangs-View `pvGoodsReceiptItemDbo` vorhanden sind; diese liefert die interne Lieferantenbestellnummer.\n\n**Anreicherung**\n- Artikelstammdaten (interne und Lieferanten-Artikelnummer, EAN, Bildlinks) stammen aus `items`.\n- `DeliveryItemNrSuppl` ist die Lieferanten-Artikelnummer des liefernden Lieferanten aus `AddItems`.\n- `ItemTAGs` enthält alle Tag-Namen des Artikels, durch `|` getrennt und alphabetisch sortiert.\n- `BatchManagementDetails` wird nur für Artikel mit Tag `-6` oder `-7` (Chargen-/MHD-Verwaltung) gefüllt. Das Feld enthält ein XML-Fragment mit einem `row`-Element pro Lagerplatz-Logeintrag dieser Lieferung und dieses Artikels, der eine Charge oder ein MHD trägt. Jedes `row`-Element hat das Attribut `BinItemLogId` und die Unterelemente `BinItemLogId`, `LocationId`, `BinRef`, `ItemRef`, `DeliveredQty`, `BatchNumber` und `BestBeforeDate`.\n\n**Paging**\nDas Paging ist schlüsselbasiert. Für die nächste Seite wird der höchste `SDelDkey` der vorherigen Seite als `Offset` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | Nein | Interner Schlüssel der Lieferantenlieferung (Wareneingangskopf). `0` oder NULL bedeutet keinen Lieferungsfilter. Hat Vorrang vor `DeliveryNumber`. |\n| `DeliveryNumber` | int | Nein | Liefernummer (`SDelHNr`). Wird nur verwendet, wenn `SDelHKey` nicht gesetzt ist, und auf die erste passende Lieferung aufgelöst. Passt keine Lieferung, wird kein Lieferungsfilter angewendet. |\n| `ItemNrInternal` | varchar(50) | Nein | Interne Artikelnummer zur Filterung nach Artikel. Ein Leerstring bedeutet keinen Filter. Wird die Nummer nicht gefunden, wird kein Artikelfilter angewendet. |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC-Code zur Filterung nach Artikel. In Kombination mit `ItemNrInternal` wird der erste Artikel verwendet, auf den einer der beiden Codes passt. |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Lieferpositionen (Seitengröße). NULL wird als 100 behandelt. |\n| `Offset` | int | Nein | Cursor für schlüsselbasiertes Paging. Es werden nur Positionen mit `SDelDkey` größer als dieser Wert geliefert; der letzte `SDelDkey` der vorherigen Seite wird übergeben. |\n| `DateFrom` | datetime | Nein | Untergrenze (inklusive) für das Anlagedatum der Position. Standard: Tag der ältesten Position der angegebenen Lieferung, sonst heute minus 700 Tage. |\n| `DateTo` | datetime | Nein | Obergrenze (exklusiv) für das Anlagedatum der Position. Standard: heute plus 365 Tage. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten erscheinen.\n- **Nicht auflösbare Filter:** Kann `DeliveryNumber`, `ItemNrInternal` oder `EANUPC` nicht aufgelöst werden, entfällt der jeweilige Filter stillschweigend. Der Aufruf liefert dann Positionen aller Lieferungen bzw. Artikel im Zeitraum statt eines leeren Ergebnisses.\n- **Lieferung ohne Positionen:** Ist ein Lieferschlüssel bekannt, `DateFrom` aber leer und hat die Lieferung keine Positionen, wird das Startdatum NULL und es werden keine Zeilen geliefert.\n- **`DateTo` ist exklusiv und wird nicht auf das Tagesende erweitert.** Ein reiner Datumswert wie `2024-05-31` schließt diesen Tag aus.\n- **Standard-Startdatum:** Der Standardwert liegt 700 Tage zurück, nicht exakt zwei Jahre.\n- **`Offset` ist keine Anzahl zu überspringender Zeilen.** Der Wert wird mit `SDelDkey` verglichen.\n- **Sortierung:** Das Endergebnis hat kein `ORDER BY`, die Ausgabereihenfolge ist daher nicht garantiert. Bei Bedarf clientseitig nach `SDelDkey` sortieren.\n- **Weniger Zeilen als `RowCount`:** Positionen, deren Artikel nicht in `items` existiert, entfallen erst nach der `RowCount`-Begrenzung. Eine Seite kann daher weniger Zeilen enthalten.\n- **Doppelte Zeilen:** Enthält `AddItems` mehrere Zeilen für denselben Artikel und Lieferanten, kann eine Position mehrfach erscheinen.\n- **Chargendetails pro Lieferung, nicht pro Position:** Lagerplatz-Logeinträge werden nur über Lieferung und Artikel zugeordnet. Kommt ein Artikel auf mehreren Positionen einer Lieferung vor, zeigt jede Position alle Einträge. `DeliveredQty` im XML wird in eine Ganzzahl umgewandelt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetDeliveryItem"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Positionen von Lieferantenlieferungen (Wareneingängen) mit Artikeldaten, Preisen, Tags und Chargendetails, gefiltert nach Lieferung, Artikel und Zeitraum.\n\nLiest Lieferpositionen aus `SDelDetail` zusammen mit dem Lieferkopf (`SDelHeader`) und liefert eine Zeile pro Position.\n\n**Normalisierung der Parameter**\n- `0` bei `SDelHKey`/`DeliveryNumber` und Leerstrings bei `ItemNrInternal`/`EANUPC` gelten als nicht gesetzt.\n- `RowCount` ist bei NULL standardmäßig 100, `Offset` standardmäßig 0.\n\n**Auflösung der Filter**\n- **Artikel:** `ItemNrInternal` wird als interne Artikelnummer und `EANUPC` als EAN in der Artikelcode-Tabelle gesucht. Sind beide angegeben, wird der erste Artikel verwendet, auf den *einer* der beiden Codes passt.\n- **Lieferung:** Ist `SDelHKey` nicht gesetzt, wird `DeliveryNumber` auf den Schlüssel der ersten Lieferung mit dieser Nummer aufgelöst. Ist `SDelHKey` gesetzt, wird `DeliveryNumber` ignoriert.\n- **Startdatum:** Ist `DateFrom` leer und eine Lieferung bekannt, ist das Startdatum der Tag der ältesten Position dieser Lieferung. Andernfalls gilt standardmäßig heute minus 700 Tage.\n- **Enddatum:** `DateTo` ist standardmäßig heute plus 365 Tage.\n\n**Auswahl**\nEine Position wird ausgewählt, wenn alle folgenden Bedingungen zutreffen:\n- `SDelDkey` > `Offset`.\n- Sie gehört zur aufgelösten Lieferung, sofern vorhanden.\n- Sie gehört zum aufgelösten Artikel, sofern vorhanden.\n- Ihr Anlagedatum liegt zwischen `DateFrom` (inklusive) und `DateTo` (exklusive).\n\nEs werden die ersten `RowCount` Positionen in aufsteigender `SDelDkey`-Reihenfolge übernommen. Geliefert werden nur Positionen, die auch in der Wareneingangs-View `pvGoodsReceiptItemDbo` vorhanden sind; diese liefert die interne Lieferantenbestellnummer.\n\n**Anreicherung**\n- Artikelstammdaten (interne und Lieferanten-Artikelnummer, EAN, Bildlinks) stammen aus `items`.\n- `DeliveryItemNrSuppl` ist die Lieferanten-Artikelnummer des liefernden Lieferanten aus `AddItems`.\n- `ItemTAGs` enthält alle Tag-Namen des Artikels, durch `|` getrennt und alphabetisch sortiert.\n- `BatchManagementDetails` wird nur für Artikel mit Tag `-6` oder `-7` (Chargen-/MHD-Verwaltung) gefüllt. Das Feld enthält ein XML-Fragment mit einem `row`-Element pro Lagerplatz-Logeintrag dieser Lieferung und dieses Artikels, der eine Charge oder ein MHD trägt. Jedes `row`-Element hat das Attribut `BinItemLogId` und die Unterelemente `BinItemLogId`, `LocationId`, `BinRef`, `ItemRef`, `DeliveredQty`, `BatchNumber` und `BestBeforeDate`.\n\n**Paging**\nDas Paging ist schlüsselbasiert. Für die nächste Seite wird der höchste `SDelDkey` der vorherigen Seite als `Offset` übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | Nein | Interner Schlüssel der Lieferantenlieferung (Wareneingangskopf). `0` oder NULL bedeutet keinen Lieferungsfilter. Hat Vorrang vor `DeliveryNumber`. |\n| `DeliveryNumber` | int | Nein | Liefernummer (`SDelHNr`). Wird nur verwendet, wenn `SDelHKey` nicht gesetzt ist, und auf die erste passende Lieferung aufgelöst. Passt keine Lieferung, wird kein Lieferungsfilter angewendet. |\n| `ItemNrInternal` | varchar(50) | Nein | Interne Artikelnummer zur Filterung nach Artikel. Ein Leerstring bedeutet keinen Filter. Wird die Nummer nicht gefunden, wird kein Artikelfilter angewendet. |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC-Code zur Filterung nach Artikel. In Kombination mit `ItemNrInternal` wird der erste Artikel verwendet, auf den einer der beiden Codes passt. |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Lieferpositionen (Seitengröße). NULL wird als 100 behandelt. |\n| `Offset` | int | Nein | Cursor für schlüsselbasiertes Paging. Es werden nur Positionen mit `SDelDkey` größer als dieser Wert geliefert; der letzte `SDelDkey` der vorherigen Seite wird übergeben. |\n| `DateFrom` | datetime | Nein | Untergrenze (inklusive) für das Anlagedatum der Position. Standard: Tag der ältesten Position der angegebenen Lieferung, sonst heute minus 700 Tage. |\n| `DateTo` | datetime | Nein | Obergrenze (exklusiv) für das Anlagedatum der Position. Standard: heute plus 365 Tage. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten erscheinen.\n- **Nicht auflösbare Filter:** Kann `DeliveryNumber`, `ItemNrInternal` oder `EANUPC` nicht aufgelöst werden, entfällt der jeweilige Filter stillschweigend. Der Aufruf liefert dann Positionen aller Lieferungen bzw. Artikel im Zeitraum statt eines leeren Ergebnisses.\n- **Lieferung ohne Positionen:** Ist ein Lieferschlüssel bekannt, `DateFrom` aber leer und hat die Lieferung keine Positionen, wird das Startdatum NULL und es werden keine Zeilen geliefert.\n- **`DateTo` ist exklusiv und wird nicht auf das Tagesende erweitert.** Ein reiner Datumswert wie `2024-05-31` schließt diesen Tag aus.\n- **Standard-Startdatum:** Der Standardwert liegt 700 Tage zurück, nicht exakt zwei Jahre.\n- **`Offset` ist keine Anzahl zu überspringender Zeilen.** Der Wert wird mit `SDelDkey` verglichen.\n- **Sortierung:** Das Endergebnis hat kein `ORDER BY`, die Ausgabereihenfolge ist daher nicht garantiert. Bei Bedarf clientseitig nach `SDelDkey` sortieren.\n- **Weniger Zeilen als `RowCount`:** Positionen, deren Artikel nicht in `items` existiert, entfallen erst nach der `RowCount`-Begrenzung. Eine Seite kann daher weniger Zeilen enthalten.\n- **Doppelte Zeilen:** Enthält `AddItems` mehrere Zeilen für denselben Artikel und Lieferanten, kann eine Position mehrfach erscheinen.\n- **Chargendetails pro Lieferung, nicht pro Position:** Lagerplatz-Logeinträge werden nur über Lieferung und Artikel zugeordnet. Kommt ein Artikel auf mehreren Positionen einer Lieferung vor, zeigt jede Position alle Einträge. `DeliveredQty` im XML wird in eine Ganzzahl umgewandelt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetDeliveryItem"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 88231\n 20240315\n 15432\n 4711\n ART-10045\n SUP-998\n SUP-998\n Bio Olive Oil 500ml\n 4006381333931\n 24.0000\n 24.0000\n 4.1000\n 0.0000\n 4.2000\n 4.2000\n Batch|Food\n https://shop.example.com/img/4711_l.jpg\n https://shop.example.com/img/4711_s.jpg\n 2024-03-15T08:12:00\n 2024-03-15T08:14:31\n 2024-03-15T09:02:10\n BOO\n L2403-17\n 2025-09-30T00:00:00\n \n \n 551203\n 001\n 3021\n 4711\n 24\n L2403-17\n 2025-09-30T00:00:00\n \n \n PO-2024-0312\n LS-778812\n \n"
}
]
},
{
"name": "pixiGetHistoricalSupplierPriceMatching",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert FIFO-zugeordnete Lieferanten-Einkaufspreise und Verkaufspreise für Lagerbewegungen eines oder aller Artikel in einem Zeitraum von bis zu 31 Tagen.\n\nLiefert die historische FIFO-Zuordnung zwischen Lagerzugängen (mit Lieferantenpreis) und Lagerabgängen (mit Verkaufspreis) auf Basis des Lagerplatz-Artikelprotokolls.\n\n**Parameterprüfung**\n- `DateFrom` und `DateTo` müssen beide übergeben werden, obwohl sie mit dem Standardwert `NULL` deklariert sind.\n- Beide Werte werden auf den Datumsanteil reduziert. Das Ende des Zeitraums ist `DateTo` + 1 Tag.\n- Der Zeitraum von `DateFrom` bis `DateTo` + 1 Tag darf 31 Tage nicht überschreiten.\n- `DateTo` darf höchstens der gestrige Tag sein; Daten für den aktuellen Tag können nicht abgefragt werden.\n\n**Auswahl**\n- Wird `ItemKey` übergeben, wird nur dieser Artikel geliefert, andernfalls alle Artikel.\n- Ein Zugang wird berücksichtigt, wenn sein Erstelldatum oder das Änderungsdatum seines Lieferantenpreis-Datensatzes zwischen `DateFrom` und `DateTo` + 1 Tag liegt (beide Grenzen inklusive, Vergleich als Datum um Mitternacht).\n- Zugänge werden auf zwei Arten mit Abgängen verknüpft, die Ergebnisse beider Wege werden zusammengeführt:\n 1. Abgänge, die direkt auf den Zugangsdatensatz verweisen,\n 2. Abgänge, die über Artikel und FIFO-Zeilennummer zum Zugang passen.\n- Für jede Zuordnung werden Lieferantenpreis, Verkaufspreis, die Herkunftsbeschreibungen beider Preise, die Lieferung (eigene oder zugewiesene Lieferung) und die Verkaufsbelegzeile (Rechnungsposition oder POS-Position) ermittelt.\n\n**Ausgabe**\n- Wurden keine Zeilen gefunden, wird eine einzelne Zeile mit `Staus` = `Warning` geliefert.\n- Andernfalls werden die Datenzeilen sortiert nach `InvBinItemLogId` geliefert. Die Lieferscheinnummer des Lieferanten stammt aus der Lieferantenlieferung; Datum und Nummer des Verkaufsbelegs stammen aus der Rechnung oder, falls keine vorhanden ist, aus dem POS-Beleg.\n- Jeder Fehler, auch die Prüfungsfehler, wird als Zeile mit `Staus` = `Error` und dem Fehlertext in `Message` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Schlüssel des Artikels, auf den das Ergebnis beschränkt wird. `NULL` liefert Daten für alle Artikel. |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (nur Datumsanteil). Faktisch Pflicht: Fehlt der Wert, wird eine Fehlerzeile geliefert. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (nur Datumsanteil, inklusive). Darf höchstens der gestrige Tag sein, und der Zeitraum von `DateFrom` bis `DateTo` + 1 Tag darf 31 Tage nicht überschreiten. Faktisch Pflicht. |\n\n- Die Statusspalte heißt `Staus` (nicht `Status`), sowohl in der Warnungs- als auch in der Fehlerzeile.\n- Fehler werden nie als `SqlMessage` geliefert; die `RAISERROR`-Aufrufe werden abgefangen und als normale Zeile zurückgegeben. Anhand des ersten Spaltennamens lassen sich Daten- und Statuszeilen unterscheiden.\n- Die Obergrenze gilt inklusive Mitternacht von `DateTo` + 1 Tag, daher werden auch Datensätze mit Zeitpunkt genau 00:00 am Folgetag berücksichtigt.\n- Liegt `DateFrom` nach `DateTo`, tritt kein Prüfungsfehler auf; es wird lediglich die `Warning`-Zeile geliefert.\n- Ein Paar aus Zugang und Abgang kann doppelt erscheinen, wenn es über beide Verknüpfungswege (direkter Verweis sowie Artikel + Zeilennummer) passt; es erfolgt keine Duplikatbereinigung.\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- Die temporäre Tabelle wird über `util.TempTableDrop` gelöscht, dessen Definition nicht beigefügt ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetHistoricalSupplierPriceMatching"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert FIFO-zugeordnete Lieferanten-Einkaufspreise und Verkaufspreise für Lagerbewegungen eines oder aller Artikel in einem Zeitraum von bis zu 31 Tagen.\n\nLiefert die historische FIFO-Zuordnung zwischen Lagerzugängen (mit Lieferantenpreis) und Lagerabgängen (mit Verkaufspreis) auf Basis des Lagerplatz-Artikelprotokolls.\n\n**Parameterprüfung**\n- `DateFrom` und `DateTo` müssen beide übergeben werden, obwohl sie mit dem Standardwert `NULL` deklariert sind.\n- Beide Werte werden auf den Datumsanteil reduziert. Das Ende des Zeitraums ist `DateTo` + 1 Tag.\n- Der Zeitraum von `DateFrom` bis `DateTo` + 1 Tag darf 31 Tage nicht überschreiten.\n- `DateTo` darf höchstens der gestrige Tag sein; Daten für den aktuellen Tag können nicht abgefragt werden.\n\n**Auswahl**\n- Wird `ItemKey` übergeben, wird nur dieser Artikel geliefert, andernfalls alle Artikel.\n- Ein Zugang wird berücksichtigt, wenn sein Erstelldatum oder das Änderungsdatum seines Lieferantenpreis-Datensatzes zwischen `DateFrom` und `DateTo` + 1 Tag liegt (beide Grenzen inklusive, Vergleich als Datum um Mitternacht).\n- Zugänge werden auf zwei Arten mit Abgängen verknüpft, die Ergebnisse beider Wege werden zusammengeführt:\n 1. Abgänge, die direkt auf den Zugangsdatensatz verweisen,\n 2. Abgänge, die über Artikel und FIFO-Zeilennummer zum Zugang passen.\n- Für jede Zuordnung werden Lieferantenpreis, Verkaufspreis, die Herkunftsbeschreibungen beider Preise, die Lieferung (eigene oder zugewiesene Lieferung) und die Verkaufsbelegzeile (Rechnungsposition oder POS-Position) ermittelt.\n\n**Ausgabe**\n- Wurden keine Zeilen gefunden, wird eine einzelne Zeile mit `Staus` = `Warning` geliefert.\n- Andernfalls werden die Datenzeilen sortiert nach `InvBinItemLogId` geliefert. Die Lieferscheinnummer des Lieferanten stammt aus der Lieferantenlieferung; Datum und Nummer des Verkaufsbelegs stammen aus der Rechnung oder, falls keine vorhanden ist, aus dem POS-Beleg.\n- Jeder Fehler, auch die Prüfungsfehler, wird als Zeile mit `Staus` = `Error` und dem Fehlertext in `Message` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Schlüssel des Artikels, auf den das Ergebnis beschränkt wird. `NULL` liefert Daten für alle Artikel. |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (nur Datumsanteil). Faktisch Pflicht: Fehlt der Wert, wird eine Fehlerzeile geliefert. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (nur Datumsanteil, inklusive). Darf höchstens der gestrige Tag sein, und der Zeitraum von `DateFrom` bis `DateTo` + 1 Tag darf 31 Tage nicht überschreiten. Faktisch Pflicht. |\n\n- Die Statusspalte heißt `Staus` (nicht `Status`), sowohl in der Warnungs- als auch in der Fehlerzeile.\n- Fehler werden nie als `SqlMessage` geliefert; die `RAISERROR`-Aufrufe werden abgefangen und als normale Zeile zurückgegeben. Anhand des ersten Spaltennamens lassen sich Daten- und Statuszeilen unterscheiden.\n- Die Obergrenze gilt inklusive Mitternacht von `DateTo` + 1 Tag, daher werden auch Datensätze mit Zeitpunkt genau 00:00 am Folgetag berücksichtigt.\n- Liegt `DateFrom` nach `DateTo`, tritt kein Prüfungsfehler auf; es wird lediglich die `Warning`-Zeile geliefert.\n- Ein Paar aus Zugang und Abgang kann doppelt erscheinen, wenn es über beide Verknüpfungswege (direkter Verweis sowie Artikel + Zeilennummer) passt; es erfolgt keine Duplikatbereinigung.\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- Die temporäre Tabelle wird über `util.TempTableDrop` gelöscht, dessen Definition nicht beigefügt ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetHistoricalSupplierPriceMatching"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1583321\n 4711\n 2024-03-04T09:15:22\n 2\n 12.50\n 17\n Supplier delivery\n LS-2024-0815\n 2024-03-12T14:02:10\n 24.90\n Invoice\n RE240312001\n \n"
}
]
},
{
"name": "pixiGetHistoricalSupplierPrices",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die FIFO-Lieferantenpreise von Einlagerungsbewegungen für einen oder alle Artikel in einem Zeitraum von höchstens 31 Tagen.\n\nLiefert die Lieferantenpreise, die Pixi den Einlagerungsbewegungen zugeordnet hat (FIFO-Preise), zusammen mit Artikel, Menge, Lieferant und Referenzbeleg.\n\n**Prüfungen** (bei Fehler wird eine einzelne `Error`-Zeile geliefert, siehe Fehler):\n- `DateFrom` und `DateTo` sind Pflicht, obwohl sie den Standardwert `NULL` haben.\n- Beide Werte werden auf das Datum reduziert. Das Ende des Zeitraums ist der Tag nach `DateTo`, `DateTo` ist also inklusive.\n- Der Zeitraum von `DateFrom` bis `DateTo` darf höchstens 31 Kalendertage (inklusive) umfassen.\n- `DateTo` darf höchstens gestern sein; Daten für den aktuellen Tag können nicht abgefragt werden.\n\n**Auswahl**:\n- Ist `ItemKey` angegeben, werden nur Bewegungen dieses Artikels geliefert, sonst alle Artikel.\n- Ein Datensatz wird geliefert, wenn entweder das Einlagerungsdatum der Bewegung (`DatePutToStock`) oder das letzte Änderungsdatum des zugehörigen Preisdatensatzes im Zeitraum liegt. Datensätze, deren Preis im Zeitraum neu berechnet wurde, erscheinen also auch dann, wenn die Einlagerung früher erfolgte.\n- `RefType` beschreibt die Quelle, aus der der Preis stammt; `RefDocumentNumber` ist die Nummer der verknüpften Lieferantenlieferung (direkt zugeordnete Lieferung, ersatzweise die nachträglich zugeordnete), sofern vorhanden.\n\n**Ergebnis**: Die Zeilen sind nach `InvBinItemLogId` sortiert. Gibt es keine Treffer, wird stattdessen eine einzelne `Warning`-Zeile geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel (`ItemRef` der Lagerbewegung). Bei `NULL` werden Bewegungen aller Artikel geliefert. |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (inklusive, Uhrzeit wird ignoriert). Faktisch Pflicht: Fehlt der Wert, wird eine `Error`-Zeile geliefert. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (inklusive, Uhrzeit wird ignoriert). Faktisch Pflicht; darf höchstens gestern sein und höchstens 31 Tage (inklusive) nach `DateFrom` liegen. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können daher erscheinen.\n- Fehler werden nicht als `SqlMessage` geliefert: Prüffehler und alle anderen Laufzeitfehler werden abgefangen und als normale Zeile mit den Spalten `Staus` (sic, falsch geschrieben) und `Message` zurückgegeben. Vor dem Auswerten der Datenzeilen sollte auf eine Spalte `Staus` geprüft werden.\n- Liegt `DateFrom` nach `DateTo`, entsteht kein Prüffehler; es wird lediglich die `Warning`-Zeile geliefert.\n- Das Ende des Zeitraums wird mit `<=` gegen Mitternacht des Folgetags von `DateTo` verglichen, Datensätze mit genau diesem Zeitstempel werden daher ebenfalls geliefert.\n- Ob eine Einlagerungsbewegung mehrere Preisdatensätze haben kann (und damit in mehreren Zeilen erscheint), hängt von den Daten in `InvBinItemLog_In_Price` ab und ist aus dem Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetHistoricalSupplierPrices"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die FIFO-Lieferantenpreise von Einlagerungsbewegungen für einen oder alle Artikel in einem Zeitraum von höchstens 31 Tagen.\n\nLiefert die Lieferantenpreise, die Pixi den Einlagerungsbewegungen zugeordnet hat (FIFO-Preise), zusammen mit Artikel, Menge, Lieferant und Referenzbeleg.\n\n**Prüfungen** (bei Fehler wird eine einzelne `Error`-Zeile geliefert, siehe Fehler):\n- `DateFrom` und `DateTo` sind Pflicht, obwohl sie den Standardwert `NULL` haben.\n- Beide Werte werden auf das Datum reduziert. Das Ende des Zeitraums ist der Tag nach `DateTo`, `DateTo` ist also inklusive.\n- Der Zeitraum von `DateFrom` bis `DateTo` darf höchstens 31 Kalendertage (inklusive) umfassen.\n- `DateTo` darf höchstens gestern sein; Daten für den aktuellen Tag können nicht abgefragt werden.\n\n**Auswahl**:\n- Ist `ItemKey` angegeben, werden nur Bewegungen dieses Artikels geliefert, sonst alle Artikel.\n- Ein Datensatz wird geliefert, wenn entweder das Einlagerungsdatum der Bewegung (`DatePutToStock`) oder das letzte Änderungsdatum des zugehörigen Preisdatensatzes im Zeitraum liegt. Datensätze, deren Preis im Zeitraum neu berechnet wurde, erscheinen also auch dann, wenn die Einlagerung früher erfolgte.\n- `RefType` beschreibt die Quelle, aus der der Preis stammt; `RefDocumentNumber` ist die Nummer der verknüpften Lieferantenlieferung (direkt zugeordnete Lieferung, ersatzweise die nachträglich zugeordnete), sofern vorhanden.\n\n**Ergebnis**: Die Zeilen sind nach `InvBinItemLogId` sortiert. Gibt es keine Treffer, wird stattdessen eine einzelne `Warning`-Zeile geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel (`ItemRef` der Lagerbewegung). Bei `NULL` werden Bewegungen aller Artikel geliefert. |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (inklusive, Uhrzeit wird ignoriert). Faktisch Pflicht: Fehlt der Wert, wird eine `Error`-Zeile geliefert. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums (inklusive, Uhrzeit wird ignoriert). Faktisch Pflicht; darf höchstens gestern sein und höchstens 31 Tage (inklusive) nach `DateFrom` liegen. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Daten können daher erscheinen.\n- Fehler werden nicht als `SqlMessage` geliefert: Prüffehler und alle anderen Laufzeitfehler werden abgefangen und als normale Zeile mit den Spalten `Staus` (sic, falsch geschrieben) und `Message` zurückgegeben. Vor dem Auswerten der Datenzeilen sollte auf eine Spalte `Staus` geprüft werden.\n- Liegt `DateFrom` nach `DateTo`, entsteht kein Prüffehler; es wird lediglich die `Warning`-Zeile geliefert.\n- Das Ende des Zeitraums wird mit `<=` gegen Mitternacht des Folgetags von `DateTo` verglichen, Datensätze mit genau diesem Zeitstempel werden daher ebenfalls geliefert.\n- Ob eine Einlagerungsbewegung mehrere Preisdatensätze haben kann (und damit in mehreren Zeilen erscheint), hängt von den Daten in `InvBinItemLog_In_Price` ab und ist aus dem Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetHistoricalSupplierPrices"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1583321\n 4711\n 2024-05-06T09:14:22\n 24\n 12.50\n 17\n Supplier delivery\n LS-2024-00871\n \n \n 1583402\n 4711\n 2024-05-08T14:02:10\n 6\n 12.80\n 17\n Last purchase price\n \n"
}
]
},
{
"name": "pixiGetItemDeliveryInfo",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die bestellten bzw. bestätigten Lieferantenbestellpositionen eines Artikels mit Lieferantennummer, Menge und voraussichtlichem Liefertermin.\n\nErmittelt die erwarteten Lieferantenlieferungen für einen Artikel.\n\n1. Leere Zeichenketten in `EAN`, `ItemNrSuppl` und `ItemNrInt` sowie der Wert `0` in `ItemKey` werden als nicht gesetzt behandelt.\n2. Der Artikel wird über einen der übergebenen Identifikatoren bestimmt. Die Kriterien werden mit **ODER** verknüpft: Eine Lieferantenbestellposition wird geliefert, wenn ihr Artikel zu `ItemKey` **oder** zur EAN/UPC (`EANUPC`) **oder** zur Lieferantenartikelnummer **oder** zur internen Artikelnummer passt.\n3. Es werden nur Lieferantenbestellpositionen geliefert, deren Lieferantenbestellung einen als bestellt/bestätigt gekennzeichneten Status hat (`IsOrderedConfirmed = 1`, also die Status `BES` und `BGT`) und deren Menge größer als 0 ist.\n4. Je Position werden Lieferantenbestellnummer, Lieferantennummer, bestellte Menge und voraussichtlicher Liefertermin ausgegeben.\n\nSortierung: Positionen mit voraussichtlichem Liefertermin zuerst, aufsteigend nach diesem Datum; Positionen ohne Liefertermin am Ende.\n\nWird kein Identifikator übergeben, werden keine Zeilen geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels (`ItemKey`). `0` wird als nicht gesetzt behandelt. |\n| `EAN` | varchar(13) | Nein | EAN/UPC des Artikels, verglichen mit `EANUPC`. Eine leere Zeichenkette wird als nicht gesetzt behandelt. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferantenartikelnummer des Artikels (`ItemNrSuppl`). Eine leere Zeichenkette wird als nicht gesetzt behandelt. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer (`ItemNrInt`). Eine leere Zeichenkette wird als nicht gesetzt behandelt. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können erscheinen.\n- Da die Identifikatoren mit ODER verknüpft werden, liefert die Übergabe mehrerer Identifikatoren verschiedener Artikel die Positionen aller dieser Artikel. Das Ergebnis enthält keine Artikelspalte, sodass die Zeilen nachträglich keinem Artikel zugeordnet werden können. Für eindeutige Ergebnisse nur einen Identifikator übergeben.\n- `SupplierOrderQty` ist die gespeicherte Menge der Lieferantenbestellposition; bereits eingegangene Mengen werden nicht abgezogen.\n- `EstimatedDelivery` wird nach `datetime` konvertiert und ist leer, wenn die Position keinen voraussichtlichen Liefertermin hat.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemDeliveryInfo"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die bestellten bzw. bestätigten Lieferantenbestellpositionen eines Artikels mit Lieferantennummer, Menge und voraussichtlichem Liefertermin.\n\nErmittelt die erwarteten Lieferantenlieferungen für einen Artikel.\n\n1. Leere Zeichenketten in `EAN`, `ItemNrSuppl` und `ItemNrInt` sowie der Wert `0` in `ItemKey` werden als nicht gesetzt behandelt.\n2. Der Artikel wird über einen der übergebenen Identifikatoren bestimmt. Die Kriterien werden mit **ODER** verknüpft: Eine Lieferantenbestellposition wird geliefert, wenn ihr Artikel zu `ItemKey` **oder** zur EAN/UPC (`EANUPC`) **oder** zur Lieferantenartikelnummer **oder** zur internen Artikelnummer passt.\n3. Es werden nur Lieferantenbestellpositionen geliefert, deren Lieferantenbestellung einen als bestellt/bestätigt gekennzeichneten Status hat (`IsOrderedConfirmed = 1`, also die Status `BES` und `BGT`) und deren Menge größer als 0 ist.\n4. Je Position werden Lieferantenbestellnummer, Lieferantennummer, bestellte Menge und voraussichtlicher Liefertermin ausgegeben.\n\nSortierung: Positionen mit voraussichtlichem Liefertermin zuerst, aufsteigend nach diesem Datum; Positionen ohne Liefertermin am Ende.\n\nWird kein Identifikator übergeben, werden keine Zeilen geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Schlüssel des Artikels (`ItemKey`). `0` wird als nicht gesetzt behandelt. |\n| `EAN` | varchar(13) | Nein | EAN/UPC des Artikels, verglichen mit `EANUPC`. Eine leere Zeichenkette wird als nicht gesetzt behandelt. |\n| `ItemNrSuppl` | varchar(50) | Nein | Lieferantenartikelnummer des Artikels (`ItemNrSuppl`). Eine leere Zeichenkette wird als nicht gesetzt behandelt. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer (`ItemNrInt`). Eine leere Zeichenkette wird als nicht gesetzt behandelt. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können erscheinen.\n- Da die Identifikatoren mit ODER verknüpft werden, liefert die Übergabe mehrerer Identifikatoren verschiedener Artikel die Positionen aller dieser Artikel. Das Ergebnis enthält keine Artikelspalte, sodass die Zeilen nachträglich keinem Artikel zugeordnet werden können. Für eindeutige Ergebnisse nur einen Identifikator übergeben.\n- `SupplierOrderQty` ist die gespeicherte Menge der Lieferantenbestellposition; bereits eingegangene Mengen werden nicht abgezogen.\n- `EstimatedDelivery` wird nach `datetime` konvertiert und ist leer, wenn die Position keinen voraussichtlichen Liefertermin hat.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemDeliveryInfo"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10234\n L1001\n 50\n 2024-06-12T00:00:00\n \n \n 10251\n L1007\n 20\n \n"
}
]
},
{
"name": "pixiGetItemSuppliers",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Lieferantenzuordnungen von Artikeln (Lieferantenartikelnummer, EAN, Einkaufspreis, Mindestbestellmenge, Lieferzeiten), gefiltert nach Artikel oder Lieferant.\n\nLiest die Artikel-Lieferanten-Zuordnungen aus `AddItems` und verknüpft sie mit den Stammdaten aus `Suppliers`. Es werden nur Zuordnungen geliefert, deren Lieferant in `Suppliers` existiert.\n\n**Normalisierung der Parameter**\n- `ItemKey` = `0` und leere Zeichenketten bei `EAN`, `ItemNrSuppl`, `ItemNrInt` und `SupplNr` gelten als *nicht gesetzt*.\n\n**Prüfungen**\n1. Mindestens einer der Parameter `ItemKey`, `EAN`, `ItemNrSuppl`, `ItemNrInt` oder `SupplNr` muss gesetzt sein. `OnlyActiveSuppliers` allein genügt nicht. Andernfalls wird eine Fehlerzeile geliefert.\n2. Ist `SupplNr` gesetzt, muss der Lieferant existieren. Andernfalls wird eine Fehlerzeile geliefert.\n\n**Filterlogik**\n- Die Artikelfilter `ItemKey`, `EAN`, `ItemNrSuppl` und `ItemNrInt` werden mit **ODER** verknüpft. Eine Zeile wird geliefert, wenn einer der angegebenen Werte passt. Jeder Filter wird mit seiner Spalte in `AddItems` verglichen: `ItemRef`, `EANUPC`, `ItemNrSuppl` und `ItemNrInt`.\n- `SupplNr` wird mit **UND** verknüpft. Es schränkt das Ergebnis auf diesen einen Lieferanten ein.\n- Ist nur `SupplNr` angegeben, werden alle diesem Lieferanten zugeordneten Artikel geliefert.\n- Bei `OnlyActiveSuppliers` = `1` werden nur Zeilen geliefert, bei denen der Lieferant nicht deaktiviert ist und die Artikel-Lieferanten-Zuordnung aktiv ist (`AddItems.Active` = `1`).\n\nEine Sortierreihenfolge ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel (`AddItems.ItemRef`). `0` gilt als nicht gesetzt. |\n| `EAN` | varchar(13) | Nein | EAN/UPC der Lieferantenzuordnung (`AddItems.EANUPC`). Eine leere Zeichenkette gilt als nicht gesetzt. |\n| `ItemNrSuppl` | varchar(50) | Nein | Artikelnummer des Lieferanten (`AddItems.ItemNrSuppl`). Eine leere Zeichenkette gilt als nicht gesetzt. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer (`AddItems.ItemNrInt`). Eine leere Zeichenkette gilt als nicht gesetzt. |\n| `OnlyActiveSuppliers` | bit | Nein | Bei `1` werden nur Zuordnungen geliefert, deren Lieferant nicht deaktiviert ist und deren Zuordnung aktiv ist. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Schränkt das Ergebnis auf diesen Lieferanten ein und muss in `Suppliers` existieren. Eine leere Zeichenkette gilt als nicht gesetzt. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- `EAN` wird mit der lieferantenspezifischen EAN `AddItems.EANUPC` verglichen, nicht mit einem anderen EAN-Feld des Artikels.\n- Fehler werden nicht als SQL-Fehler ausgelöst. Sie werden als normale Zeile mit den Spalten `Error` und `ErrorMsg` geliefert. Vor dem Auswerten der Datenspalten sollte auf die Spalte `Error` geprüft werden.\n- Werden mehrere Artikelfilter angegeben, ist das Ergebnis die Vereinigung aller Treffer, nicht deren Schnittmenge.\n- Ein Aufruf nur mit `SupplNr` kann bei Lieferanten mit vielen Artikeln eine große Ergebnismenge liefern. Paging ist nicht vorgesehen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemSuppliers"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Lieferantenzuordnungen von Artikeln (Lieferantenartikelnummer, EAN, Einkaufspreis, Mindestbestellmenge, Lieferzeiten), gefiltert nach Artikel oder Lieferant.\n\nLiest die Artikel-Lieferanten-Zuordnungen aus `AddItems` und verknüpft sie mit den Stammdaten aus `Suppliers`. Es werden nur Zuordnungen geliefert, deren Lieferant in `Suppliers` existiert.\n\n**Normalisierung der Parameter**\n- `ItemKey` = `0` und leere Zeichenketten bei `EAN`, `ItemNrSuppl`, `ItemNrInt` und `SupplNr` gelten als *nicht gesetzt*.\n\n**Prüfungen**\n1. Mindestens einer der Parameter `ItemKey`, `EAN`, `ItemNrSuppl`, `ItemNrInt` oder `SupplNr` muss gesetzt sein. `OnlyActiveSuppliers` allein genügt nicht. Andernfalls wird eine Fehlerzeile geliefert.\n2. Ist `SupplNr` gesetzt, muss der Lieferant existieren. Andernfalls wird eine Fehlerzeile geliefert.\n\n**Filterlogik**\n- Die Artikelfilter `ItemKey`, `EAN`, `ItemNrSuppl` und `ItemNrInt` werden mit **ODER** verknüpft. Eine Zeile wird geliefert, wenn einer der angegebenen Werte passt. Jeder Filter wird mit seiner Spalte in `AddItems` verglichen: `ItemRef`, `EANUPC`, `ItemNrSuppl` und `ItemNrInt`.\n- `SupplNr` wird mit **UND** verknüpft. Es schränkt das Ergebnis auf diesen einen Lieferanten ein.\n- Ist nur `SupplNr` angegeben, werden alle diesem Lieferanten zugeordneten Artikel geliefert.\n- Bei `OnlyActiveSuppliers` = `1` werden nur Zeilen geliefert, bei denen der Lieferant nicht deaktiviert ist und die Artikel-Lieferanten-Zuordnung aktiv ist (`AddItems.Active` = `1`).\n\nEine Sortierreihenfolge ist nicht festgelegt.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interner Artikelschlüssel (`AddItems.ItemRef`). `0` gilt als nicht gesetzt. |\n| `EAN` | varchar(13) | Nein | EAN/UPC der Lieferantenzuordnung (`AddItems.EANUPC`). Eine leere Zeichenkette gilt als nicht gesetzt. |\n| `ItemNrSuppl` | varchar(50) | Nein | Artikelnummer des Lieferanten (`AddItems.ItemNrSuppl`). Eine leere Zeichenkette gilt als nicht gesetzt. |\n| `ItemNrInt` | varchar(50) | Nein | Interne Artikelnummer (`AddItems.ItemNrInt`). Eine leere Zeichenkette gilt als nicht gesetzt. |\n| `OnlyActiveSuppliers` | bit | Nein | Bei `1` werden nur Zuordnungen geliefert, deren Lieferant nicht deaktiviert ist und deren Zuordnung aktiv ist. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Schränkt das Ergebnis auf diesen Lieferanten ein und muss in `Suppliers` existieren. Eine leere Zeichenkette gilt als nicht gesetzt. |\n\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- `EAN` wird mit der lieferantenspezifischen EAN `AddItems.EANUPC` verglichen, nicht mit einem anderen EAN-Feld des Artikels.\n- Fehler werden nicht als SQL-Fehler ausgelöst. Sie werden als normale Zeile mit den Spalten `Error` und `ErrorMsg` geliefert. Vor dem Auswerten der Datenspalten sollte auf die Spalte `Error` geprüft werden.\n- Werden mehrere Artikelfilter angegeben, ist das Ergebnis die Vereinigung aller Treffer, nicht deren Schnittmenge.\n- Ein Aufruf nur mit `SupplNr` kann bei Lieferanten mit vielen Artikeln eine große Ergebnismenge liefern. Paging ist nicht vorgesehen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetItemSuppliers"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 12345\n 4006381333931\n LF-98765\n ART-1001\n L001\n 4.9500\n false\n 10\n false\n 5\n 3\n \n"
}
]
},
{
"name": "pixiGetMatchesForDeliveredItem",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Lieferantenbestellpositionen, die einer Artikelposition eines Lieferscheins zugeordnet sind, mit bestellten, gelieferten, offenen und zugeordneten Mengen.\n\nLiefert die Zuordnungen (`BuyingMatch`-Datensätze) zwischen einer Position eines Lieferscheins und den Lieferantenbestellpositionen, gegen die sie gebucht wurde.\n\n- Berücksichtigt werden nur Zuordnungen, deren Lieferscheinreferenz `SDelDkey` entspricht.\n- Jede Zuordnung wird mit ihrer Bestellposition und der Lieferantenbestellung verknüpft. Zuordnungen ohne vorhandene Bestellposition oder Bestellung werden nicht zurückgegeben.\n- Die Zeilen werden nach Bestelldatum und Bestellposition gruppiert, es entsteht also eine Zeile je zugeordneter Bestellposition:\n - `OrderNr` ist die interne Nummer der Lieferantenbestellung, `OrderId` deren ID.\n - `OrderQty`, `QtyReceived` und `QtyNotDelivered` stammen aus der Bestellposition (`QtyNotDelivered` ist `0`, wenn kein Wert hinterlegt ist).\n - `BuyingMatchQty` ist die Summe aller zugeordneten Mengen dieser Lieferscheinposition zur Bestellposition.\n - `SupplName` ist der Name des Lieferanten zur in der Zuordnung gespeicherten Lieferantennummer.\n\nDer Aufruf ist ein Wrapper: Er führt die interne Prozedur `Pixi_Buy_GetMatchesForDeliveredItem` aus, puffert deren Zeilen in einer temporären Tabelle und gibt sie zurück.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelDkey` | int | Nein | Schlüssel der Lieferscheinposition (Artikelposition), deren Zuordnungen zu Lieferantenbestellpositionen geliefert werden. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Wird `SDelDkey` weggelassen (Standard `NULL`), werden keine Zeilen geliefert, da der Filter mit `=` vergleicht.\n- Die interne Prozedur sortiert nach Bestelldatum und Bestellmenge, der Wrapper liest die temporäre Tabelle jedoch ohne `ORDER BY`. Die Reihenfolge ist daher nicht garantiert; bei Bedarf clientseitig sortieren.\n- Alle Mengenspalten werden in der Puffertabelle als `int` gespeichert; Dezimalmengen würden abgeschnitten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetMatchesForDeliveredItem"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Lieferantenbestellpositionen, die einer Artikelposition eines Lieferscheins zugeordnet sind, mit bestellten, gelieferten, offenen und zugeordneten Mengen.\n\nLiefert die Zuordnungen (`BuyingMatch`-Datensätze) zwischen einer Position eines Lieferscheins und den Lieferantenbestellpositionen, gegen die sie gebucht wurde.\n\n- Berücksichtigt werden nur Zuordnungen, deren Lieferscheinreferenz `SDelDkey` entspricht.\n- Jede Zuordnung wird mit ihrer Bestellposition und der Lieferantenbestellung verknüpft. Zuordnungen ohne vorhandene Bestellposition oder Bestellung werden nicht zurückgegeben.\n- Die Zeilen werden nach Bestelldatum und Bestellposition gruppiert, es entsteht also eine Zeile je zugeordneter Bestellposition:\n - `OrderNr` ist die interne Nummer der Lieferantenbestellung, `OrderId` deren ID.\n - `OrderQty`, `QtyReceived` und `QtyNotDelivered` stammen aus der Bestellposition (`QtyNotDelivered` ist `0`, wenn kein Wert hinterlegt ist).\n - `BuyingMatchQty` ist die Summe aller zugeordneten Mengen dieser Lieferscheinposition zur Bestellposition.\n - `SupplName` ist der Name des Lieferanten zur in der Zuordnung gespeicherten Lieferantennummer.\n\nDer Aufruf ist ein Wrapper: Er führt die interne Prozedur `Pixi_Buy_GetMatchesForDeliveredItem` aus, puffert deren Zeilen in einer temporären Tabelle und gibt sie zurück.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelDkey` | int | Nein | Schlüssel der Lieferscheinposition (Artikelposition), deren Zuordnungen zu Lieferantenbestellpositionen geliefert werden. |\n\n- Alle Lesezugriffe verwenden `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Wird `SDelDkey` weggelassen (Standard `NULL`), werden keine Zeilen geliefert, da der Filter mit `=` vergleicht.\n- Die interne Prozedur sortiert nach Bestelldatum und Bestellmenge, der Wrapper liest die temporäre Tabelle jedoch ohne `ORDER BY`. Die Reihenfolge ist daher nicht garantiert; bei Bedarf clientseitig sortieren.\n- Alle Mengenspalten werden in der Puffertabelle als `int` gespeichert; Dezimalmengen würden abgeschnitten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetMatchesForDeliveredItem"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n 88213\n Muster Großhandel GmbH\n 2024-03-12T00:00:00\n 50\n 30\n 20\n 30\n 7731\n \n"
}
]
},
{
"name": "pixiGetSOrderlines",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Positionen einer Lieferantenbestellung mit Artikel-, Preis-, Liefer- und Bestandsdaten sowie Bedarfs- und Verkaufszahlen je Artikel.\n\nLiefert alle Positionen der Lieferantenbestellung, deren ID in `SOrderRef` übergeben wird. Intern wird `Pixi_GetSorderlines` mit allen optionalen Feldern ausgeführt, die Zeilen werden in einer temporären Tabelle zwischengespeichert und unverändert zurückgegeben.\n\nJe Position enthält das Ergebnis:\n\n- **Positionsdaten**: Artikelname, Bestellmenge, Statuscode der Lieferantenbestellung, Kommentar, voraussichtliches Lieferdatum, Ersteller und letzter Bearbeiter mit Zeitstempeln.\n- **Artikeldaten**: EAN (`ArtNr`), Lieferanten-Artikelnummer und interne Artikelnummer aus den lieferantenspezifischen Artikeldaten des Lieferanten der Bestellung, Verkaufspreis (`VKPrice`), Bestelleinheit, zum Erstellungsdatum der Position gültiger MwSt-Satz.\n- **Einkaufspreise**: `EKprice` ist der auf der Position gespeicherte Lieferantenpreis. Ist der Bestellstatus als *neu* gekennzeichnet und der Positionspreis 0 oder leer, wird stattdessen der Lieferantenpreis aus den lieferantenspezifischen Artikeldaten verwendet. `EKValue` ist Menge × `EKprice`. `FinalPrice` ist Lieferantenpreis × Menge abzüglich des Positionsrabatts.\n- **Lieferdaten**: gelieferte und nicht lieferbare Menge der Position sowie die über alle Wareneingangsdetails summierte Eingangsmenge (`TotalQtyReceived`).\n- **Bestand und Bedarf am Lieferlager** der Bestellung: Lagerbestand am Lager, Mindestbestell- und Mindestbestandsmenge, Menge in Auftragspositionen mit Status `HAL` (`Hal_Cust_O`) bzw. `ANG`, `BES`, `BOR` (`Open_Cust_O`), Menge in anderen offenen, bestellten/bestätigten Lieferantenbestellungen (`Open_Suppl_O`) sowie Verkaufsmengen der letzten 30, 120 und 365 Tage (`L30`, `L120`, `L365`, alle Auftragspositionen außer Status `STO`).\n\nBei `OpenOrderlines` = 1 werden nur Positionen geliefert, deren Bestellmenge größer ist als gelieferte plus nicht lieferbare Menge. Die Positionen werden in der Reihenfolge der Positions-ID erzeugt.\n\nEs werden nur Positionen geliefert, für die Artikel, der lagerspezifische Artikeldatensatz am Lieferlager der Bestellung, Lieferant sowie anlegender und ändernder Benutzer existieren (Inner Joins).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SOrderRef` | int | Nein | ID der Lieferantenbestellung, deren Positionen geliefert werden. NULL wird als 0 behandelt. |\n| `LocID` | char(3) | Nein | Lager-ID. Wird intern weitergereicht, hat aber keinen Einfluss auf das Ergebnis; Lagerwerte beziehen sich immer auf das Lieferlager der Bestellung. |\n| `OpenOrderlines` | bit | Nein | Schränkt das Ergebnis auf noch nicht vollständig gelieferte Positionen ein. NULL wird als 0 behandelt. |\n\n- `LocID` wird an die innere Prozedur übergeben, in der Abfrage aber nicht verwendet. Lagerbezogene Werte beziehen sich immer auf das Lieferlager der Lieferantenbestellung, unabhängig von `LocID`.\n- Ist die Einstellung `Include_FUT_StatusInOpenOrdersForSupplierOrdering` auf `1` gesetzt, werden in `Open_Cust_O` auch Auftragspositionen mit Status `FUT` gezählt.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; die Werte können nicht festgeschriebene Daten enthalten.\n- Die Abfrage wird als dynamisches SQL aufgebaut; die vielen korrelierten Unterabfragen (Verkäufe 30/120/365 Tage, offene Aufträge) können den Aufruf bei großen Bestellungen verlangsamen.\n- Feste Werte: `Detail`, `Detail2` und `Price` sind immer 0, `ReceiveDate` ist immer leer. `StockQty` entspricht `SummaryQuantity`.\n- `SOrderlineNr` enthält tatsächlich die ID der Lieferantenbestellung (wie `SOrderRef`), keine Positionsnummer. Zur Identifikation einer Position `SOrderlineKey` verwenden.\n- Die Sortierung nach Positions-ID erfolgt in der inneren Abfrage; das abschließende Select aus der temporären Tabelle hat kein explizites `ORDER BY`.\n- Mehrere Spalten der internen temporären Tabelle sind als `NOT NULL` deklariert (z. B. `VKPrice`, `FinalPrice`). Enthalten die Quelldaten dort NULL (z. B. Position ohne Lieferantenpreis), kann das Einfügen mit einem SQL-Fehler fehlschlagen.\n- Wird `SOrderRef` weggelassen (Standard 0), werden keine Zeilen geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetSOrderlines"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert die Positionen einer Lieferantenbestellung mit Artikel-, Preis-, Liefer- und Bestandsdaten sowie Bedarfs- und Verkaufszahlen je Artikel.\n\nLiefert alle Positionen der Lieferantenbestellung, deren ID in `SOrderRef` übergeben wird. Intern wird `Pixi_GetSorderlines` mit allen optionalen Feldern ausgeführt, die Zeilen werden in einer temporären Tabelle zwischengespeichert und unverändert zurückgegeben.\n\nJe Position enthält das Ergebnis:\n\n- **Positionsdaten**: Artikelname, Bestellmenge, Statuscode der Lieferantenbestellung, Kommentar, voraussichtliches Lieferdatum, Ersteller und letzter Bearbeiter mit Zeitstempeln.\n- **Artikeldaten**: EAN (`ArtNr`), Lieferanten-Artikelnummer und interne Artikelnummer aus den lieferantenspezifischen Artikeldaten des Lieferanten der Bestellung, Verkaufspreis (`VKPrice`), Bestelleinheit, zum Erstellungsdatum der Position gültiger MwSt-Satz.\n- **Einkaufspreise**: `EKprice` ist der auf der Position gespeicherte Lieferantenpreis. Ist der Bestellstatus als *neu* gekennzeichnet und der Positionspreis 0 oder leer, wird stattdessen der Lieferantenpreis aus den lieferantenspezifischen Artikeldaten verwendet. `EKValue` ist Menge × `EKprice`. `FinalPrice` ist Lieferantenpreis × Menge abzüglich des Positionsrabatts.\n- **Lieferdaten**: gelieferte und nicht lieferbare Menge der Position sowie die über alle Wareneingangsdetails summierte Eingangsmenge (`TotalQtyReceived`).\n- **Bestand und Bedarf am Lieferlager** der Bestellung: Lagerbestand am Lager, Mindestbestell- und Mindestbestandsmenge, Menge in Auftragspositionen mit Status `HAL` (`Hal_Cust_O`) bzw. `ANG`, `BES`, `BOR` (`Open_Cust_O`), Menge in anderen offenen, bestellten/bestätigten Lieferantenbestellungen (`Open_Suppl_O`) sowie Verkaufsmengen der letzten 30, 120 und 365 Tage (`L30`, `L120`, `L365`, alle Auftragspositionen außer Status `STO`).\n\nBei `OpenOrderlines` = 1 werden nur Positionen geliefert, deren Bestellmenge größer ist als gelieferte plus nicht lieferbare Menge. Die Positionen werden in der Reihenfolge der Positions-ID erzeugt.\n\nEs werden nur Positionen geliefert, für die Artikel, der lagerspezifische Artikeldatensatz am Lieferlager der Bestellung, Lieferant sowie anlegender und ändernder Benutzer existieren (Inner Joins).\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SOrderRef` | int | Nein | ID der Lieferantenbestellung, deren Positionen geliefert werden. NULL wird als 0 behandelt. |\n| `LocID` | char(3) | Nein | Lager-ID. Wird intern weitergereicht, hat aber keinen Einfluss auf das Ergebnis; Lagerwerte beziehen sich immer auf das Lieferlager der Bestellung. |\n| `OpenOrderlines` | bit | Nein | Schränkt das Ergebnis auf noch nicht vollständig gelieferte Positionen ein. NULL wird als 0 behandelt. |\n\n- `LocID` wird an die innere Prozedur übergeben, in der Abfrage aber nicht verwendet. Lagerbezogene Werte beziehen sich immer auf das Lieferlager der Lieferantenbestellung, unabhängig von `LocID`.\n- Ist die Einstellung `Include_FUT_StatusInOpenOrdersForSupplierOrdering` auf `1` gesetzt, werden in `Open_Cust_O` auch Auftragspositionen mit Status `FUT` gezählt.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`; die Werte können nicht festgeschriebene Daten enthalten.\n- Die Abfrage wird als dynamisches SQL aufgebaut; die vielen korrelierten Unterabfragen (Verkäufe 30/120/365 Tage, offene Aufträge) können den Aufruf bei großen Bestellungen verlangsamen.\n- Feste Werte: `Detail`, `Detail2` und `Price` sind immer 0, `ReceiveDate` ist immer leer. `StockQty` entspricht `SummaryQuantity`.\n- `SOrderlineNr` enthält tatsächlich die ID der Lieferantenbestellung (wie `SOrderRef`), keine Positionsnummer. Zur Identifikation einer Position `SOrderlineKey` verwenden.\n- Die Sortierung nach Positions-ID erfolgt in der inneren Abfrage; das abschließende Select aus der temporären Tabelle hat kein explizites `ORDER BY`.\n- Mehrere Spalten der internen temporären Tabelle sind als `NOT NULL` deklariert (z. B. `VKPrice`, `FinalPrice`). Enthalten die Quelldaten dort NULL (z. B. Position ohne Lieferantenpreis), kann das Einfügen mit einem SQL-Fehler fehlschlagen.\n- Wird `SOrderRef` weggelassen (Standard 0), werden keine Zeilen geliefert.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetSOrderlines"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 0\n 0\n 4006381333931\n Kugelschreiber blau\n 100\n BES\n 2024-03-04T09:12:00\n mmueller\n 2024-03-05T14:30:00\n mmueller\n 18233\n 5521\n 4711\n false\n 4711\n 2024-03-15T00:00:00\n 2.9900\n 40\n 25\n 60\n 0\n 50\n 20\n Stk\n KS-100-B\n A-5521\n 19\n 0.8500\n 85.0000\n 3\n 12\n 100\n 45\n 160\n 520\n 40\n 0.0000\n 60\n 80.0000\n \n"
}
]
},
{
"name": "pixiGetSOrders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Lieferantenbestellungen eines Standorts, gefiltert nach Status, überfälligen/fehlenden Lieferterminen, Statusänderungsdatum und externen Bestellnummern.\n\nLiefert Lieferantenbestellungen aus `pixi.SupplierOrder` zusammen mit Lieferant, Status, Standort, anlegendem/änderndem Benutzer und den zugehörigen Wareneingängen. Die Abfrage wird als dynamisches SQL aufgebaut und mit `sp_executesql` ausgeführt.\n\n**Filter**\n- Nur Bestellungen, deren Lieferstandort die `LocID` = `LocationID` hat (Standard `001`).\n- Es werden höchstens `RLimit` Zeilen geliefert (`TOP (@RLimit)`). Der Standardwert `0` liefert **keine Zeilen**; daher muss ein positiver Wert übergeben werden.\n- **Statusfilter:**\n - Sind `ShowDueDate` und `ShowNoDate` beide `0`, werden die Flags per ODER verknüpft: `ShowNew` → Statusflag `IsNew`, `ShowOrd` → `IsOrdered`, `ShowCon` → `IsConfirmed`, `ShowCls` → `IsClosed`.\n - Bei `ShowNoDate` = `1` werden nur bestellte Bestellungen (`IsOrdered`) geliefert, die mindestens eine Position ohne voraussichtlichen Liefertermin haben. Dieser Filter hat Vorrang vor `ShowDueDate`.\n - Bei `ShowDueDate` = `1` (und `ShowNoDate` = `0`) werden nur bestellte Bestellungen geliefert, die mindestens eine Position mit voraussichtlichem Liefertermin vor dem aktuellen Zeitpunkt haben.\n - In beiden Terminmodi werden `ShowNew`, `ShowOrd`, `ShowCon` und `ShowCls` ignoriert.\n - Sind alle sechs Flags `0`, entfällt der Statusfilter.\n- **Statusänderungsdatum:** Ist `StatusChangeDateFrom` und/oder `StatusChangeDateTo` gesetzt, werden nur Bestellungen geliefert, deren letzter Historieneintrag in `hist.pixi_SupplierOrder` (`MAX(AuditDate)`) im Bereich `>= From` und `< To` liegt.\n- **Externe Bestellnummern:** Ist `ExtOrderNrs` gesetzt (XML-Liste), werden nur Bestellungen geliefert, deren `ExternalCode` einer der übergebenen Nummern entspricht.\n\n**Wareneingänge**\nFür jeden Wareneingang in `SDelHeader` wird das Feld `SDelHextOrderNr` am `;` aufgeteilt. Numerische Teile werden der `InternalNumber` der Bestellung zugeordnet. Die Wareneingangsnummern (`SDelHNr`) werden in `GoodsReceipts` als mit `; ` getrennte Liste geliefert.\n\nSortierung nach `OrderDate` absteigend.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocationID` | varchar(3) | Nein | Standortkürzel (`LocID`) des Lieferstandorts. Nur Bestellungen dieses Standorts werden geliefert. |\n| `RLimit` | int | Nein | Maximale Anzahl Zeilen (`TOP`). `0` liefert keine Zeilen; daher einen positiven Wert übergeben. |\n| `ShowNew` | bit | Nein | Bestellungen mit Status „neu“ (`IsNew`) einbeziehen. Nur wirksam, wenn `ShowDueDate` und `ShowNoDate` `0` sind. |\n| `ShowOrd` | bit | Nein | Bestellte Bestellungen (`IsOrdered`, Status BES) einbeziehen. Nur wirksam, wenn `ShowDueDate` und `ShowNoDate` `0` sind. |\n| `ShowCon` | bit | Nein | Bestätigte Bestellungen (`IsConfirmed`, Status CON) einbeziehen. Nur wirksam, wenn `ShowDueDate` und `ShowNoDate` `0` sind. |\n| `ShowCls` | bit | Nein | Abgeschlossene Bestellungen (`IsClosed`, Status CLS) einbeziehen. Nur wirksam, wenn `ShowDueDate` und `ShowNoDate` `0` sind. |\n| `ShowDueDate` | bit | Nein | Bei `1` (und `ShowNoDate` = `0`): nur bestellte Bestellungen mit mindestens einer Position, deren voraussichtlicher Liefertermin in der Vergangenheit liegt. |\n| `ShowNoDate` | bit | Nein | Bei `1`: nur bestellte Bestellungen mit mindestens einer Position ohne voraussichtlichen Liefertermin. Hat Vorrang vor `ShowDueDate`. |\n| `StatusChangeDateFrom` | datetime | Nein | Untergrenze (inklusiv) für die letzte Änderung in der Bestellhistorie. Allein übergeben liefert der Parameter keine Zeilen (siehe Hinweise). |\n| `StatusChangeDateTo` | datetime | Nein | Obergrenze (exklusiv) für die letzte Änderung in der Bestellhistorie. |\n| `ExtOrderNrs` | varchar(max) | Nein | Optionale XML-Liste externer Bestellnummern. Nur Bestellungen mit passendem `ExternalCode` werden geliefert. |\n\n- **Stolperfalle `RLimit`:** Der Standardwert `0` führt zu `TOP (0)` und damit zu einem leeren Ergebnis. Einen Wert für „unbegrenzt“ gibt es nicht.\n- **Stolperfalle Statusänderungsdatum:** Wird nur `StatusChangeDateFrom` übergeben, fällt die Obergrenze auf `MAX(AuditDate)` zurück. Die Bedingung `MAX(AuditDate) < MAX(AuditDate)` ist nie erfüllt, daher werden keine Bestellungen geliefert. Zusätzlich `StatusChangeDateTo` oder nur `StatusChangeDateTo` übergeben. Die Obergrenze ist exklusiv.\n- `NULL` für die Flags, `LocationID` und `RLimit` wird durch die Standardwerte ersetzt. Ein leeres oder nur aus Leerzeichen bestehendes `ExtOrderNrs` wird als `NULL` behandelt.\n- `ExtOrderNrs` wird elementbasiert per `OPENXML` unter dem Pfad `/ExtOrders/ExtOrder` gelesen, mit dem Kindelement `ExtOrderNr`. Das XML-Dokument wird nicht mit `sp_xml_removedocument` freigegeben.\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können enthalten sein.\n- Bestellungen werden per `INNER JOIN` mit Lieferant, Status, Standort und für anlegenden wie ändernden Benutzer mit `ucs_users` verknüpft. Bestellungen ohne passenden Datensatz fehlen im Ergebnis.\n- `GoodsReceipts` wird über eine `varchar(100)`-Konvertierung gebildet; lange Listen werden abgeschnitten. Die Wareneingangsliste wird bei jedem Aufruf über die gesamte Tabelle `SDelHeader` berechnet, was bei großen Datenbanken langsam sein kann.\n- `RecordBatchNr` und `PixiOrderCreated` sind immer `NULL` und dienen nur der Kompatibilität.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetSOrders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Lieferantenbestellungen eines Standorts, gefiltert nach Status, überfälligen/fehlenden Lieferterminen, Statusänderungsdatum und externen Bestellnummern.\n\nLiefert Lieferantenbestellungen aus `pixi.SupplierOrder` zusammen mit Lieferant, Status, Standort, anlegendem/änderndem Benutzer und den zugehörigen Wareneingängen. Die Abfrage wird als dynamisches SQL aufgebaut und mit `sp_executesql` ausgeführt.\n\n**Filter**\n- Nur Bestellungen, deren Lieferstandort die `LocID` = `LocationID` hat (Standard `001`).\n- Es werden höchstens `RLimit` Zeilen geliefert (`TOP (@RLimit)`). Der Standardwert `0` liefert **keine Zeilen**; daher muss ein positiver Wert übergeben werden.\n- **Statusfilter:**\n - Sind `ShowDueDate` und `ShowNoDate` beide `0`, werden die Flags per ODER verknüpft: `ShowNew` → Statusflag `IsNew`, `ShowOrd` → `IsOrdered`, `ShowCon` → `IsConfirmed`, `ShowCls` → `IsClosed`.\n - Bei `ShowNoDate` = `1` werden nur bestellte Bestellungen (`IsOrdered`) geliefert, die mindestens eine Position ohne voraussichtlichen Liefertermin haben. Dieser Filter hat Vorrang vor `ShowDueDate`.\n - Bei `ShowDueDate` = `1` (und `ShowNoDate` = `0`) werden nur bestellte Bestellungen geliefert, die mindestens eine Position mit voraussichtlichem Liefertermin vor dem aktuellen Zeitpunkt haben.\n - In beiden Terminmodi werden `ShowNew`, `ShowOrd`, `ShowCon` und `ShowCls` ignoriert.\n - Sind alle sechs Flags `0`, entfällt der Statusfilter.\n- **Statusänderungsdatum:** Ist `StatusChangeDateFrom` und/oder `StatusChangeDateTo` gesetzt, werden nur Bestellungen geliefert, deren letzter Historieneintrag in `hist.pixi_SupplierOrder` (`MAX(AuditDate)`) im Bereich `>= From` und `< To` liegt.\n- **Externe Bestellnummern:** Ist `ExtOrderNrs` gesetzt (XML-Liste), werden nur Bestellungen geliefert, deren `ExternalCode` einer der übergebenen Nummern entspricht.\n\n**Wareneingänge**\nFür jeden Wareneingang in `SDelHeader` wird das Feld `SDelHextOrderNr` am `;` aufgeteilt. Numerische Teile werden der `InternalNumber` der Bestellung zugeordnet. Die Wareneingangsnummern (`SDelHNr`) werden in `GoodsReceipts` als mit `; ` getrennte Liste geliefert.\n\nSortierung nach `OrderDate` absteigend.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `LocationID` | varchar(3) | Nein | Standortkürzel (`LocID`) des Lieferstandorts. Nur Bestellungen dieses Standorts werden geliefert. |\n| `RLimit` | int | Nein | Maximale Anzahl Zeilen (`TOP`). `0` liefert keine Zeilen; daher einen positiven Wert übergeben. |\n| `ShowNew` | bit | Nein | Bestellungen mit Status „neu“ (`IsNew`) einbeziehen. Nur wirksam, wenn `ShowDueDate` und `ShowNoDate` `0` sind. |\n| `ShowOrd` | bit | Nein | Bestellte Bestellungen (`IsOrdered`, Status BES) einbeziehen. Nur wirksam, wenn `ShowDueDate` und `ShowNoDate` `0` sind. |\n| `ShowCon` | bit | Nein | Bestätigte Bestellungen (`IsConfirmed`, Status CON) einbeziehen. Nur wirksam, wenn `ShowDueDate` und `ShowNoDate` `0` sind. |\n| `ShowCls` | bit | Nein | Abgeschlossene Bestellungen (`IsClosed`, Status CLS) einbeziehen. Nur wirksam, wenn `ShowDueDate` und `ShowNoDate` `0` sind. |\n| `ShowDueDate` | bit | Nein | Bei `1` (und `ShowNoDate` = `0`): nur bestellte Bestellungen mit mindestens einer Position, deren voraussichtlicher Liefertermin in der Vergangenheit liegt. |\n| `ShowNoDate` | bit | Nein | Bei `1`: nur bestellte Bestellungen mit mindestens einer Position ohne voraussichtlichen Liefertermin. Hat Vorrang vor `ShowDueDate`. |\n| `StatusChangeDateFrom` | datetime | Nein | Untergrenze (inklusiv) für die letzte Änderung in der Bestellhistorie. Allein übergeben liefert der Parameter keine Zeilen (siehe Hinweise). |\n| `StatusChangeDateTo` | datetime | Nein | Obergrenze (exklusiv) für die letzte Änderung in der Bestellhistorie. |\n| `ExtOrderNrs` | varchar(max) | Nein | Optionale XML-Liste externer Bestellnummern. Nur Bestellungen mit passendem `ExternalCode` werden geliefert. |\n\n- **Stolperfalle `RLimit`:** Der Standardwert `0` führt zu `TOP (0)` und damit zu einem leeren Ergebnis. Einen Wert für „unbegrenzt“ gibt es nicht.\n- **Stolperfalle Statusänderungsdatum:** Wird nur `StatusChangeDateFrom` übergeben, fällt die Obergrenze auf `MAX(AuditDate)` zurück. Die Bedingung `MAX(AuditDate) < MAX(AuditDate)` ist nie erfüllt, daher werden keine Bestellungen geliefert. Zusätzlich `StatusChangeDateTo` oder nur `StatusChangeDateTo` übergeben. Die Obergrenze ist exklusiv.\n- `NULL` für die Flags, `LocationID` und `RLimit` wird durch die Standardwerte ersetzt. Ein leeres oder nur aus Leerzeichen bestehendes `ExtOrderNrs` wird als `NULL` behandelt.\n- `ExtOrderNrs` wird elementbasiert per `OPENXML` unter dem Pfad `/ExtOrders/ExtOrder` gelesen, mit dem Kindelement `ExtOrderNr`. Das XML-Dokument wird nicht mit `sp_xml_removedocument` freigegeben.\n- Alle Tabellen werden mit `NOLOCK` gelesen; nicht festgeschriebene Daten können enthalten sein.\n- Bestellungen werden per `INNER JOIN` mit Lieferant, Status, Standort und für anlegenden wie ändernden Benutzer mit `ucs_users` verknüpft. Bestellungen ohne passenden Datensatz fehlen im Ergebnis.\n- `GoodsReceipts` wird über eine `varchar(100)`-Konvertierung gebildet; lange Listen werden abgeschnitten. Die Wareneingangsliste wird bei jedem Aufruf über die gesamte Tabelle `SDelHeader` berechnet, was bei großen Datenbanken langsam sein kann.\n- `RecordBatchNr` und `PixiOrderCreated` sind immer `NULL` und dienen nur der Kompatibilität.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetSOrders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10452\n 70001\n A\n 2024-05-14T09:12:00\n BES\n 2024-05-14T09:10:00\n mmueller\n 2024-05-15T11:30:00\n mmueller\n 001\n 8831\n PO-2024-0012\n false\n false\n Bitte Liefertermin bestätigen\n Muster Buchvertrieb GmbH\n 5521; 5530\n \n"
}
]
},
{
"name": "pixiGetSOrdersBySupplier",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n L001\n 001\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert bestätigte Lieferantenbestellungen eines Lieferanten für einen Lagerstandort oder die Liste der Lieferanten mit solchen Bestellungen als Basis für Lieferscheinvorlagen.\n\nDer Aufruf gibt beide Parameter an die interne Prozedur `Pixi_GetSOrdersBySupplier` weiter. Er dient der Auswahl von Lieferantenbestellungen, aus denen eine Lieferscheinvorlage (Lieferantenlieferung) erstellt werden kann.\n\n**Vorfilter:** Lieferantenbestellungen, bei denen mindestens eine Bestellposition bereits in einer Lieferantenlieferung mit Status `NEW` (`SDelHeader.SDelHStatus = 'NEW'`) referenziert ist, werden in beiden Modi ausgeschlossen.\n\n**Statusfilter:** Berücksichtigt werden nur Bestellungen, deren Status `IsConfirmed = 1` hat. Ist die Einstellung `ConfirmOrderedDocumentOnDelivery` auf `1` gesetzt, werden zusätzlich Bestellungen mit Status `IsOrderedConfirmed = 1` einbezogen.\n\n**Standortfilter:** Der Lieferstandort der Bestellung (`DeliveryLocationId`) muss `LocID` entsprechen.\n\n**Modus abhängig von `SupplNr`:**\n- `SupplNr` gesetzt: liefert die passenden Bestellungen dieses Lieferanten (`OrderNr`, `ExternalCode`, `Code`, `OrderDate`), absteigend sortiert nach interner Bestellnummer. Der Statuscode `BES` wird als `ORD` ausgegeben.\n- `SupplNr` ist `NULL`: liefert die eindeutigen Lieferanten (`SupplNr`, `SupplName`), die mindestens eine passende Bestellung am Standort haben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Ja | Lieferantennummer. Ist sie gesetzt, werden die Bestellungen dieses Lieferanten geliefert; bei NULL die Liste der Lieferanten mit passenden Bestellungen. |\n| `LocID` | varchar(3) | Ja | Standort-ID des Lieferstandorts der Lieferantenbestellungen. |\n\n- Beide Parameter haben in diesem Wrapper keinen Standardwert und müssen übergeben werden. Der Modus mit der Lieferantenliste wird nur erreicht, wenn `SupplNr` explizit als NULL übergeben wird; ein Leerstring ist nicht NULL und liefert keine Bestellungen.\n- Ist `LocID` NULL, werden keine Zeilen geliefert, da der Vergleich `lo.LocID = @LocID` nie auf NULL zutrifft.\n- Der Wrapper übergibt `@LanguageID` nicht, daher verwendet die interne Prozedur immer `1`: `BES` wird zu `ORD`; die Übersetzung von `CON` zu `BGT` (Sprache 2) greift nie.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Die Einstellung `ConfirmOrderedDocumentOnDelivery` wird zur Laufzeit über `fpixi_GetSetting` gelesen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetSOrdersBySupplier"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n L001\n 001\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert bestätigte Lieferantenbestellungen eines Lieferanten für einen Lagerstandort oder die Liste der Lieferanten mit solchen Bestellungen als Basis für Lieferscheinvorlagen.\n\nDer Aufruf gibt beide Parameter an die interne Prozedur `Pixi_GetSOrdersBySupplier` weiter. Er dient der Auswahl von Lieferantenbestellungen, aus denen eine Lieferscheinvorlage (Lieferantenlieferung) erstellt werden kann.\n\n**Vorfilter:** Lieferantenbestellungen, bei denen mindestens eine Bestellposition bereits in einer Lieferantenlieferung mit Status `NEW` (`SDelHeader.SDelHStatus = 'NEW'`) referenziert ist, werden in beiden Modi ausgeschlossen.\n\n**Statusfilter:** Berücksichtigt werden nur Bestellungen, deren Status `IsConfirmed = 1` hat. Ist die Einstellung `ConfirmOrderedDocumentOnDelivery` auf `1` gesetzt, werden zusätzlich Bestellungen mit Status `IsOrderedConfirmed = 1` einbezogen.\n\n**Standortfilter:** Der Lieferstandort der Bestellung (`DeliveryLocationId`) muss `LocID` entsprechen.\n\n**Modus abhängig von `SupplNr`:**\n- `SupplNr` gesetzt: liefert die passenden Bestellungen dieses Lieferanten (`OrderNr`, `ExternalCode`, `Code`, `OrderDate`), absteigend sortiert nach interner Bestellnummer. Der Statuscode `BES` wird als `ORD` ausgegeben.\n- `SupplNr` ist `NULL`: liefert die eindeutigen Lieferanten (`SupplNr`, `SupplName`), die mindestens eine passende Bestellung am Standort haben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Ja | Lieferantennummer. Ist sie gesetzt, werden die Bestellungen dieses Lieferanten geliefert; bei NULL die Liste der Lieferanten mit passenden Bestellungen. |\n| `LocID` | varchar(3) | Ja | Standort-ID des Lieferstandorts der Lieferantenbestellungen. |\n\n- Beide Parameter haben in diesem Wrapper keinen Standardwert und müssen übergeben werden. Der Modus mit der Lieferantenliste wird nur erreicht, wenn `SupplNr` explizit als NULL übergeben wird; ein Leerstring ist nicht NULL und liefert keine Bestellungen.\n- Ist `LocID` NULL, werden keine Zeilen geliefert, da der Vergleich `lo.LocID = @LocID` nie auf NULL zutrifft.\n- Der Wrapper übergibt `@LanguageID` nicht, daher verwendet die interne Prozedur immer `1`: `BES` wird zu `ORD`; die Übersetzung von `CON` zu `BGT` (Sprache 2) greift nie.\n- Alle Lesezugriffe erfolgen mit `NOLOCK`, daher können nicht festgeschriebene Daten geliefert werden.\n- Die Einstellung `ConfirmOrderedDocumentOnDelivery` wird zur Laufzeit über `fpixi_GetSetting` gelesen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetSOrdersBySupplier"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 100245\n AB-2024-0815\n ORD\n 2024-03-12T00:00:00\n \n \n 100198\n AB-2024-0790\n CON\n 2024-03-05T00:00:00\n \n"
}
]
},
{
"name": "pixiGetSupplierOrder",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Lieferantenbestellungen positionsweise, optional gefiltert nach Lieferant, Bestellnummer, Zeitraum und Status, mit einfachem zeilenbasiertem Paging.\n\nLiefert eine Zeile pro **Position einer Lieferantenbestellung**, zusammen mit Kopfdaten der Bestellung, dem Lieferanten, dem Artikel, dem Lieferlager (Location) und den Benutzern, die die Datensätze angelegt bzw. zuletzt geändert haben.\n\n**Filter** (alle per UND verknüpft):\n- `SupplNr`: nur Bestellungen dieses Lieferanten. Ein Leerstring gilt als nicht gesetzt.\n- `SupplOrderNr`: nur die Bestellung mit dieser internen Nummer (`InternalNumber`). `0` gilt als nicht gesetzt.\n- `Status`: nur Bestellungen mit diesem Statuscode, z. B. `NEW`, `CLS`, `BES`, `CON`. Ein Leerstring gilt als nicht gesetzt.\n- `DateFrom` / `DateTo`: verglichen wird das Bestelldatum; fehlt es, wird das Anlagedatum der Bestellung verwendet.\n - `DateFrom` wird auf den Tagesbeginn abgerundet. Fehlt der Wert oder liegt er vor dem 01.01.1970, wird 01.01.1970 00:00 verwendet.\n - `DateTo` wird auf das Tagesende (23:59:59.997) erweitert. Fehlt der Wert oder liegt er vor dem 01.01.1970, wird das aktuelle Datum mit Uhrzeit verwendet.\n\n**Paging**: Die Zeilen werden über `RowNr` aufsteigend nach der internen ID der Lieferantenbestellung nummeriert. Zurückgegeben werden nur Zeilen mit `RowNr` größer als `Start`, höchstens `RowCount` Zeilen. Für die nächste Seite wird `Start` um `RowCount` erhöht.\n\n**Berechnete Spalten**:\n- `OrderQty` ist die noch offene Menge: bestellte Menge abzüglich nicht gelieferter und gelieferter Menge.\n- `SupplPrice` ist der Preis der Position; ist dieser 0 oder leer, wird der Lieferantenpreis aus den Zusatz-Lieferantendaten des Artikels für diesen Lieferanten verwendet, ansonsten der Lieferantenpreis aus dem Artikelstamm.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Nur Bestellungen dieses Lieferanten werden geliefert. NULL oder Leerstring: alle Lieferanten. |\n| `SupplOrderNr` | int | Nein | Interne Nummer der Lieferantenbestellung. NULL oder 0: alle Bestellungen. |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (Bestelldatum, bzw. Anlagedatum ohne Bestelldatum). Wird auf den Tagesbeginn abgerundet; NULL oder vor dem 01.01.1970 bedeutet 01.01.1970. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums. Wird auf das Ende des angegebenen Tages erweitert; NULL oder vor dem 01.01.1970 bedeutet aktuelles Datum mit Uhrzeit. |\n| `Status` | varchar(3) | Nein | Statuscode der Lieferantenbestellung. NULL oder Leerstring: alle Status. Der Code-Kommentar nennt NEW, CLS, BES und CON. |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen (Bestellpositionen). |\n| `Start` | int | Nein | Paging-Offset: Nur Zeilen mit `RowNr` größer als dieser Wert werden geliefert. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- Das Paging zählt **Bestellpositionen**, nicht Bestellungen: Eine Bestellung mit mehreren Positionen kann auf zwei Seiten verteilt werden.\n- `RowNr` wird nur nach der ID der Lieferantenbestellung vergeben; Positionen derselben Bestellung erhalten Nummern in nicht definierter Reihenfolge, und das Endergebnis hat kein `ORDER BY`. Das Paging innerhalb einer Bestellung ist daher nicht streng deterministisch.\n- Alle Joins sind Inner Joins: Bestellungen ohne Positionen sowie Bestellungen oder Positionen, deren Typ, Status, Lieferlager, Lieferant, Artikel oder anlegender/ändernder Benutzer nicht aufgelöst werden kann, werden nicht geliefert.\n- Ohne `DateTo` ist die aktuelle Uhrzeit (nicht das Tagesende) die Obergrenze.\n- Der Spaltenname `SupplierOrderLineUpateUser` enthält einen Tippfehler (`Upate`) und muss genau so ausgelesen werden.\n- `SupplierOrderlineKey` und `SupplierOrderlineId` enthalten denselben Wert, ebenso `SupplierOrderNRExternal` und `ExtOrderNr`.\n- Der Ersatzpreis aus den Zusatz-Lieferantendaten wird per `TOP 1` ohne Sortierung ermittelt; bei mehreren Einträgen für Artikel und Lieferant ist nicht definiert, welcher verwendet wird.\n- Die Statuswerte `NEW`, `CLS`, `BES`, `CON` sind nur in einem Code-Kommentar genannt; die tatsächlichen Codes stammen aus der Statustabelle der Lieferantenbestellungen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetSupplierOrder"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Lieferantenbestellungen positionsweise, optional gefiltert nach Lieferant, Bestellnummer, Zeitraum und Status, mit einfachem zeilenbasiertem Paging.\n\nLiefert eine Zeile pro **Position einer Lieferantenbestellung**, zusammen mit Kopfdaten der Bestellung, dem Lieferanten, dem Artikel, dem Lieferlager (Location) und den Benutzern, die die Datensätze angelegt bzw. zuletzt geändert haben.\n\n**Filter** (alle per UND verknüpft):\n- `SupplNr`: nur Bestellungen dieses Lieferanten. Ein Leerstring gilt als nicht gesetzt.\n- `SupplOrderNr`: nur die Bestellung mit dieser internen Nummer (`InternalNumber`). `0` gilt als nicht gesetzt.\n- `Status`: nur Bestellungen mit diesem Statuscode, z. B. `NEW`, `CLS`, `BES`, `CON`. Ein Leerstring gilt als nicht gesetzt.\n- `DateFrom` / `DateTo`: verglichen wird das Bestelldatum; fehlt es, wird das Anlagedatum der Bestellung verwendet.\n - `DateFrom` wird auf den Tagesbeginn abgerundet. Fehlt der Wert oder liegt er vor dem 01.01.1970, wird 01.01.1970 00:00 verwendet.\n - `DateTo` wird auf das Tagesende (23:59:59.997) erweitert. Fehlt der Wert oder liegt er vor dem 01.01.1970, wird das aktuelle Datum mit Uhrzeit verwendet.\n\n**Paging**: Die Zeilen werden über `RowNr` aufsteigend nach der internen ID der Lieferantenbestellung nummeriert. Zurückgegeben werden nur Zeilen mit `RowNr` größer als `Start`, höchstens `RowCount` Zeilen. Für die nächste Seite wird `Start` um `RowCount` erhöht.\n\n**Berechnete Spalten**:\n- `OrderQty` ist die noch offene Menge: bestellte Menge abzüglich nicht gelieferter und gelieferter Menge.\n- `SupplPrice` ist der Preis der Position; ist dieser 0 oder leer, wird der Lieferantenpreis aus den Zusatz-Lieferantendaten des Artikels für diesen Lieferanten verwendet, ansonsten der Lieferantenpreis aus dem Artikelstamm.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Nur Bestellungen dieses Lieferanten werden geliefert. NULL oder Leerstring: alle Lieferanten. |\n| `SupplOrderNr` | int | Nein | Interne Nummer der Lieferantenbestellung. NULL oder 0: alle Bestellungen. |\n| `DateFrom` | datetime | Nein | Beginn des Zeitraums (Bestelldatum, bzw. Anlagedatum ohne Bestelldatum). Wird auf den Tagesbeginn abgerundet; NULL oder vor dem 01.01.1970 bedeutet 01.01.1970. |\n| `DateTo` | datetime | Nein | Ende des Zeitraums. Wird auf das Ende des angegebenen Tages erweitert; NULL oder vor dem 01.01.1970 bedeutet aktuelles Datum mit Uhrzeit. |\n| `Status` | varchar(3) | Nein | Statuscode der Lieferantenbestellung. NULL oder Leerstring: alle Status. Der Code-Kommentar nennt NEW, CLS, BES und CON. |\n| `RowCount` | int | Nein | Maximale Anzahl zurückgegebener Zeilen (Bestellpositionen). |\n| `Start` | int | Nein | Paging-Offset: Nur Zeilen mit `RowNr` größer als dieser Wert werden geliefert. |\n\n- Alle Tabellen werden mit `NOLOCK` gelesen, daher können nicht festgeschriebene Daten geliefert werden.\n- Das Paging zählt **Bestellpositionen**, nicht Bestellungen: Eine Bestellung mit mehreren Positionen kann auf zwei Seiten verteilt werden.\n- `RowNr` wird nur nach der ID der Lieferantenbestellung vergeben; Positionen derselben Bestellung erhalten Nummern in nicht definierter Reihenfolge, und das Endergebnis hat kein `ORDER BY`. Das Paging innerhalb einer Bestellung ist daher nicht streng deterministisch.\n- Alle Joins sind Inner Joins: Bestellungen ohne Positionen sowie Bestellungen oder Positionen, deren Typ, Status, Lieferlager, Lieferant, Artikel oder anlegender/ändernder Benutzer nicht aufgelöst werden kann, werden nicht geliefert.\n- Ohne `DateTo` ist die aktuelle Uhrzeit (nicht das Tagesende) die Obergrenze.\n- Der Spaltenname `SupplierOrderLineUpateUser` enthält einen Tippfehler (`Upate`) und muss genau so ausgelesen werden.\n- `SupplierOrderlineKey` und `SupplierOrderlineId` enthalten denselben Wert, ebenso `SupplierOrderNRExternal` und `ExtOrderNr`.\n- Der Ersatzpreis aus den Zusatz-Lieferantendaten wird per `TOP 1` ohne Sortierung ermittelt; bei mehreren Einträgen für Artikel und Lieferant ist nicht definiert, welcher verwendet wird.\n- Die Statuswerte `NEW`, `CLS`, `BES`, `CON` sind nur in einem Code-Kommentar genannt; die tatsächlichen Codes stammen aus der Statustabelle der Lieferantenbestellungen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetSupplierOrder"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n 88231\n 10452\n PO-2024-0117\n 2024-02-12T09:15:00\n L001\n BES\n 2024-02-26T00:00:00\n Please deliver on pallets\n 4006381333931\n SUP-7781\n 40\n 10\n Ballpoint pen blue\n 2024-02-12T09:20:00\n mmueller\n 2024-02-12T09:18:00\n mmueller\n 5123\n 0.45\n 50\n 0\n 10\n Standard\n 100245\n 100245\n 001\n PO-2024-0117\n 3310\n 88231\n 2024-02-12T09:10:00\n mmueller\n \n \n"
}
]
},
{
"name": "pixiGetSuppliers",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Stammdaten der Lieferanten inklusive Hauptansprechpartner, optional beschränkt auf aktive Lieferanten oder eine Lieferantennummer.\n\nLiest die Lieferantenstammdaten aus `Suppliers`. Jeder Lieferant wird über `ContactId` mit seinem Hauptansprechpartner aus `pixi.Contact` verknüpft.\n\nFilterung:\n\n- Ein leerer Wert in `SupplNr` wird wie `NULL` behandelt.\n- Ist `SupplNr` gesetzt, wird nur der Lieferant mit dieser Nummer geliefert, und zwar **unabhängig vom Aktiv-Status**. `OnlyActive` hat in diesem Fall keine Wirkung.\n- Ist `SupplNr` nicht gesetzt und `OnlyActive` gleich `0`, werden alle Lieferanten geliefert, auch inaktive.\n- Ist `SupplNr` nicht gesetzt und `OnlyActive` hat einen anderen Wert (Standard `1`), werden nur Lieferanten mit `Disabled = 0` geliefert.\n\nDas Ergebnis ist nach `SupplName` sortiert.\n\nDie Felder des Hauptansprechpartners (`MainContact_*`) werden als Leerstring geliefert, wenn kein Ansprechpartner hinterlegt ist oder das Feld leer ist. Die Spalte `SupplierIsInactive` enthält das `Disabled`-Kennzeichen des Lieferanten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OnlyActive` | int | Nein | `0` liefert alle Lieferanten inklusive inaktiver; jeder andere Wert liefert nur aktive Lieferanten. Wird ignoriert, wenn `SupplNr` gesetzt ist. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Wenn gesetzt, wird nur dieser Lieferant geliefert, auch wenn er inaktiv ist. Leerstring oder `NULL` liefert alle Lieferanten gemäß `OnlyActive`. |\n\n- Beide Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Änderungen können daher sichtbar sein.\n- Jeder Wert ungleich `0` in `OnlyActive` wirkt wie `1`. Mit diesem Filter werden Lieferanten, deren `Disabled`-Wert `NULL` ist, nicht geliefert.\n- Einige Spalten sind gegenüber der Tabelle umbenannt: `SupplFaxNr` → `SupplFaxNR`, `CustNr` → `CustNR`, `MailBox` → `eMail`, `Disabled` → `SupplierIsInactive`, `SupplComment` → `SupplierComment`.\n- Die Spaltentypen sind im Code nicht sichtbar; sie stammen aus den Tabellen `Suppliers` und `pixi.Contact`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetSuppliers"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Stammdaten der Lieferanten inklusive Hauptansprechpartner, optional beschränkt auf aktive Lieferanten oder eine Lieferantennummer.\n\nLiest die Lieferantenstammdaten aus `Suppliers`. Jeder Lieferant wird über `ContactId` mit seinem Hauptansprechpartner aus `pixi.Contact` verknüpft.\n\nFilterung:\n\n- Ein leerer Wert in `SupplNr` wird wie `NULL` behandelt.\n- Ist `SupplNr` gesetzt, wird nur der Lieferant mit dieser Nummer geliefert, und zwar **unabhängig vom Aktiv-Status**. `OnlyActive` hat in diesem Fall keine Wirkung.\n- Ist `SupplNr` nicht gesetzt und `OnlyActive` gleich `0`, werden alle Lieferanten geliefert, auch inaktive.\n- Ist `SupplNr` nicht gesetzt und `OnlyActive` hat einen anderen Wert (Standard `1`), werden nur Lieferanten mit `Disabled = 0` geliefert.\n\nDas Ergebnis ist nach `SupplName` sortiert.\n\nDie Felder des Hauptansprechpartners (`MainContact_*`) werden als Leerstring geliefert, wenn kein Ansprechpartner hinterlegt ist oder das Feld leer ist. Die Spalte `SupplierIsInactive` enthält das `Disabled`-Kennzeichen des Lieferanten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `OnlyActive` | int | Nein | `0` liefert alle Lieferanten inklusive inaktiver; jeder andere Wert liefert nur aktive Lieferanten. Wird ignoriert, wenn `SupplNr` gesetzt ist. |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer. Wenn gesetzt, wird nur dieser Lieferant geliefert, auch wenn er inaktiv ist. Leerstring oder `NULL` liefert alle Lieferanten gemäß `OnlyActive`. |\n\n- Beide Tabellen werden mit `NOLOCK` gelesen, nicht festgeschriebene Änderungen können daher sichtbar sein.\n- Jeder Wert ungleich `0` in `OnlyActive` wirkt wie `1`. Mit diesem Filter werden Lieferanten, deren `Disabled`-Wert `NULL` ist, nicht geliefert.\n- Einige Spalten sind gegenüber der Tabelle umbenannt: `SupplFaxNr` → `SupplFaxNR`, `CustNr` → `CustNR`, `MailBox` → `eMail`, `Disabled` → `SupplierIsInactive`, `SupplComment` → `SupplierComment`.\n- Die Spaltentypen sind im Code nicht sichtbar; sie stammen aus den Tabellen `Suppliers` und `pixi.Contact`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiGetSuppliers"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n LI01\n Muster Großhandel GmbH\n Abteilung Einkauf\n 3\n +49 89 1234567-9\n K-100234\n info@muster-grosshandel.de\n Firma\n \n Industriestraße 12\n 80331\n +49 89 1234567-0\n 0\n A\n München\n \n DE\n EUR\n bestellung@muster-grosshandel.de\n https://www.muster-grosshandel.de\n \n Anna\n Schmidt\n Key Account Managerin\n Vertrieb\n +49 89 1234567-21\n +49 171 2345678\n \n a.schmidt@muster-grosshandel.de\n 0\n Lieferung nur werktags\n \n"
}
]
},
{
"name": "pixiReadDeliveryHeaders",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Lieferungskopfdaten (Wareneingänge von Lieferanten) aus `SDelHeader`, seitenweise nach Schlüssel und optional nach Anlage- und/oder Änderungsdatum gefiltert.\n\nLiest Lieferungskopfdaten (Lieferungen von Lieferanten / Wareneingänge) aus der Tabelle `SDelHeader`.\n\n**Vorbereitung**\n- Wird `SDelHKey` nicht übergeben, wird er auf `0` gesetzt.\n- Ist `RowCount` NULL, wird `1000` verwendet.\n\n**Auswahl des Filters** – es wird genau ein Filtermodus angewendet, in dieser Priorität:\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: Ein Datensatz erfüllt die Untergrenze, wenn Anlage- **oder** Änderungsdatum `>=` dem From-Wert ist, und die Obergrenze, wenn Anlage- **oder** Änderungsdatum `<` dem To-Wert ist.\n2. `CreateDateFrom` / `CreateDateTo`: Filter auf `SDelHCreateDate` (From inklusive, To exklusive).\n3. `UpdateDateFrom` / `UpdateDateTo`: Filter auf `SDelHUpdateDate` (From inklusive, To exklusive).\n4. Kein Datumsparameter: alle Datensätze.\n\nParameter eines niedriger priorisierten Modus werden ignoriert, sobald ein höher priorisierter Modus verwendet wird (z. B. wird `CreateDateFrom` ignoriert, wenn `CreateAndUpdateDateFrom` gesetzt ist).\n\n**Paging**\nIn jedem Modus werden nur Datensätze mit `SDelHKey` **größer als** `SDelHKey` geliefert, höchstens `RowCount` Zeilen, aufsteigend sortiert nach `SDelHKey`. Für die nächste Seite wird der höchste `SDelHKey` der vorherigen Seite übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | Nein | Paging-Cursor: Es werden nur Lieferungsköpfe mit einem Schlüssel größer als dieser Wert geliefert. NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `SDelHCreateDate`. Wird ignoriert, wenn ein CreateAndUpdate-Datum gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusive) für `SDelHCreateDate`. Wird ignoriert, wenn ein CreateAndUpdate-Datum gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `SDelHUpdateDate`. Wird nur verwendet, wenn weder ein CreateAndUpdate- noch ein Create-Datum gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusive) für `SDelHUpdateDate`. Wird nur verwendet, wenn weder ein CreateAndUpdate- noch ein Create-Datum gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusive): trifft zu, wenn Anlage- oder Änderungsdatum an oder nach diesem Wert liegt. Hat die höchste Priorität unter den Datumsfiltern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (exklusive): trifft zu, wenn Anlage- oder Änderungsdatum vor diesem Wert liegt. Hat die höchste Priorität unter den Datumsfiltern. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. NULL wird als 1000 behandelt. |\n\n- `SDelHKey` ist **kein** Filter auf genaue Übereinstimmung: Bei Übergabe eines Schlüssels werden die Datensätze *nach* diesem Schlüssel geliefert. Der Code enthält zwar einen Zweig für die Abfrage eines einzelnen Schlüssels und einen Zweig mit leerem Ergebnis, beide sind aber nicht erreichbar, da `SDelHKey` und `RowCount` nach der Vorbelegung nie NULL sind. Für einen bestimmten Lieferungskopf `SDelHKey` = Schlüssel − 1 und `RowCount` = 1 übergeben und den gelieferten Schlüssel prüfen.\n- Der kombinierte Anlage-/Änderungsfilter verknüpft beide Grenzen per ODER und ist daher weiter als ein strikter Zeitraum: Ein vor From angelegter, aber nach To geänderter Datensatz kann beide Grenzen erfüllen.\n- Die Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Daten können enthalten sein.\n- Ein negativer `RowCount` führt zu einem SQL-Fehler bei `TOP`; `0` liefert keine Zeilen.\n- Die Spalte `SDelHfinalDicsount` ist in der Datenbank so geschrieben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadDeliveryHeaders"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Lieferungskopfdaten (Wareneingänge von Lieferanten) aus `SDelHeader`, seitenweise nach Schlüssel und optional nach Anlage- und/oder Änderungsdatum gefiltert.\n\nLiest Lieferungskopfdaten (Lieferungen von Lieferanten / Wareneingänge) aus der Tabelle `SDelHeader`.\n\n**Vorbereitung**\n- Wird `SDelHKey` nicht übergeben, wird er auf `0` gesetzt.\n- Ist `RowCount` NULL, wird `1000` verwendet.\n\n**Auswahl des Filters** – es wird genau ein Filtermodus angewendet, in dieser Priorität:\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: Ein Datensatz erfüllt die Untergrenze, wenn Anlage- **oder** Änderungsdatum `>=` dem From-Wert ist, und die Obergrenze, wenn Anlage- **oder** Änderungsdatum `<` dem To-Wert ist.\n2. `CreateDateFrom` / `CreateDateTo`: Filter auf `SDelHCreateDate` (From inklusive, To exklusive).\n3. `UpdateDateFrom` / `UpdateDateTo`: Filter auf `SDelHUpdateDate` (From inklusive, To exklusive).\n4. Kein Datumsparameter: alle Datensätze.\n\nParameter eines niedriger priorisierten Modus werden ignoriert, sobald ein höher priorisierter Modus verwendet wird (z. B. wird `CreateDateFrom` ignoriert, wenn `CreateAndUpdateDateFrom` gesetzt ist).\n\n**Paging**\nIn jedem Modus werden nur Datensätze mit `SDelHKey` **größer als** `SDelHKey` geliefert, höchstens `RowCount` Zeilen, aufsteigend sortiert nach `SDelHKey`. Für die nächste Seite wird der höchste `SDelHKey` der vorherigen Seite übergeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | Nein | Paging-Cursor: Es werden nur Lieferungsköpfe mit einem Schlüssel größer als dieser Wert geliefert. NULL wird als 0 behandelt. |\n| `CreateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `SDelHCreateDate`. Wird ignoriert, wenn ein CreateAndUpdate-Datum gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Obergrenze (exklusive) für `SDelHCreateDate`. Wird ignoriert, wenn ein CreateAndUpdate-Datum gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Untergrenze (inklusive) für `SDelHUpdateDate`. Wird nur verwendet, wenn weder ein CreateAndUpdate- noch ein Create-Datum gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Obergrenze (exklusive) für `SDelHUpdateDate`. Wird nur verwendet, wenn weder ein CreateAndUpdate- noch ein Create-Datum gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Untergrenze (inklusive): trifft zu, wenn Anlage- oder Änderungsdatum an oder nach diesem Wert liegt. Hat die höchste Priorität unter den Datumsfiltern. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Obergrenze (exklusive): trifft zu, wenn Anlage- oder Änderungsdatum vor diesem Wert liegt. Hat die höchste Priorität unter den Datumsfiltern. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. NULL wird als 1000 behandelt. |\n\n- `SDelHKey` ist **kein** Filter auf genaue Übereinstimmung: Bei Übergabe eines Schlüssels werden die Datensätze *nach* diesem Schlüssel geliefert. Der Code enthält zwar einen Zweig für die Abfrage eines einzelnen Schlüssels und einen Zweig mit leerem Ergebnis, beide sind aber nicht erreichbar, da `SDelHKey` und `RowCount` nach der Vorbelegung nie NULL sind. Für einen bestimmten Lieferungskopf `SDelHKey` = Schlüssel − 1 und `RowCount` = 1 übergeben und den gelieferten Schlüssel prüfen.\n- Der kombinierte Anlage-/Änderungsfilter verknüpft beide Grenzen per ODER und ist daher weiter als ein strikter Zeitraum: Ein vor From angelegter, aber nach To geänderter Datensatz kann beide Grenzen erfüllen.\n- Die Tabelle wird mit `NOLOCK` gelesen; nicht festgeschriebene Daten können enthalten sein.\n- Ein negativer `RowCount` führt zu einem SQL-Fehler bei `TOP`; `0` liefert keine Zeilen.\n- Die Spalte `SDelHfinalDicsount` ist in der Datenbank so geschrieben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadDeliveryHeaders"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1201\n 2024-01-15T00:00:00\n 001\n 70012\n LS-458812\n Teillieferung\n OK\n 2024-01-15T09:12:44\n MM\n 2024-01-15T10:03:10\n MM\n RE-2024-0099\n B-10234\n 0.00\n \n 0\n 0\n \n"
}
]
},
{
"name": "pixiReadDeliveryItems",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Lieferpositionen aus SDelDetail, gefiltert nach Anlage- und/oder Änderungsdatum und nach Schlüssel aufsteigend seitenweise.\n\nLiest Lieferpositionen (Tabelle `SDelDetail`) und liefert höchstens `@RowCount` Zeilen, immer aufsteigend nach `SDelDkey` sortiert.\n\nVorbereitung:\n- Ist `SDelDkey` NULL, wird der Wert auf `0` gesetzt.\n- Ist `RowCount` NULL, wird der Wert auf `1000` gesetzt.\n\nEs greift genau ein Filtermodus. Die Prozedur prüft die Modi in dieser Reihenfolge und verwendet den ersten zutreffenden:\n1. **Anlage- oder Änderungsdatum**: `CreateAndUpdateDateFrom` und/oder `CreateAndUpdateDateTo` ist gesetzt. Eine Zeile erfüllt die Untergrenze, wenn ihr Anlagedatum **oder** ihr Änderungsdatum `>=` dem From-Wert ist. Sie erfüllt die Obergrenze, wenn ihr Anlagedatum **oder** ihr Änderungsdatum `<` dem To-Wert ist.\n2. **Anlagedatum**: `CreateDateFrom` und/oder `CreateDateTo` ist gesetzt. Der Filter lautet `SDelDcreateDate >= From` und `SDelDcreateDate < To`.\n3. **Änderungsdatum**: `UpdateDateFrom` und/oder `UpdateDateTo` ist gesetzt. Der Filter lautet `SDelDupdateDate >= From` und `SDelDupdateDate < To`.\n4. **Schlüsselbereich**: Kein Datumsparameter ist gesetzt. Der Aufruf liefert die nächsten Zeilen nach `SDelDkey`.\n\nIn jedem Modus werden nur Zeilen mit `SDelDkey > @SDelDkey` geliefert. Zum seitenweisen Abruf wird der höchste `SDelDkey` der vorherigen Antwort als `SDelDkey` im nächsten Aufruf übergeben. Der Abruf endet, sobald weniger als `RowCount` Zeilen zurückkommen.\n\nDie Obergrenzen der Datumsbereiche sind exklusiv. Parameter eines niedriger priorisierten Modus werden ignoriert, wenn ein höher priorisierter Modus aktiv ist.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelDkey` | int | Nein | Exklusive Untergrenze für den Schlüssel der Lieferposition. Es werden nur Zeilen mit größerem `SDelDkey` geliefert. NULL wird als `0` behandelt. Für den seitenweisen Abruf den letzten Schlüssel der vorherigen Seite übergeben. |\n| `CreateDateFrom` | datetime | Nein | Inklusive Untergrenze für `SDelDcreateDate`. Wird nur verwendet, wenn keiner der kombinierten Anlage-/Änderungsdatumsparameter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Exklusive Obergrenze für `SDelDcreateDate`. Wird nur verwendet, wenn keiner der kombinierten Anlage-/Änderungsdatumsparameter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Inklusive Untergrenze für `SDelDupdateDate`. Wird nur verwendet, wenn weder ein kombinierter Datumsparameter noch ein Anlagedatumsparameter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Exklusive Obergrenze für `SDelDupdateDate`. Wird nur verwendet, wenn weder ein kombinierter Datumsparameter noch ein Anlagedatumsparameter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Inklusive Untergrenze, die zutrifft, wenn `SDelDcreateDate` oder `SDelDupdateDate` auf oder nach diesem Wert liegt. Hat die höchste Priorität unter den Filtermodi. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Exklusive Obergrenze, die zutrifft, wenn `SDelDcreateDate` oder `SDelDupdateDate` vor diesem Wert liegt. Hat die höchste Priorität unter den Filtermodi. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. NULL wird als `1000` behandelt. |\n\n- Alle Lesezugriffe verwenden `WITH (NOLOCK)`. Nicht festgeschriebene Daten können geliefert werden, und während Datenänderungen können Zeilen fehlen oder doppelt erscheinen.\n- `SDelDkey` wird immer als exklusive Untergrenze (`>`) verwendet. Die Übergabe eines bestimmten Schlüssels liefert diese Zeile **nicht**, sondern die Zeilen danach. Der Code enthält einen Zweig für den exakten Schlüsselabruf und einen Zweig für ein leeres Ergebnis, beide sind jedoch nicht erreichbar, weil `SDelDkey` und `RowCount` nach der Vorbereitung nie NULL sind.\n- Im kombinierten Anlage-/Änderungsmodus werden die From- und die To-Prüfung unabhängig voneinander ausgewertet. Eine Zeile kann die From-Grenze über das eine Datum und die To-Grenze über das andere Datum erfüllen. Zum Beispiel wird eine Zeile, die vor To angelegt und nach To geändert wurde, trotzdem geliefert.\n- Ein negativer Wert für `RowCount` führt zu einem SQL-Fehler bei `TOP`. `RowCount = 0` liefert keine Zeilen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadDeliveryItems"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Lieferpositionen aus SDelDetail, gefiltert nach Anlage- und/oder Änderungsdatum und nach Schlüssel aufsteigend seitenweise.\n\nLiest Lieferpositionen (Tabelle `SDelDetail`) und liefert höchstens `@RowCount` Zeilen, immer aufsteigend nach `SDelDkey` sortiert.\n\nVorbereitung:\n- Ist `SDelDkey` NULL, wird der Wert auf `0` gesetzt.\n- Ist `RowCount` NULL, wird der Wert auf `1000` gesetzt.\n\nEs greift genau ein Filtermodus. Die Prozedur prüft die Modi in dieser Reihenfolge und verwendet den ersten zutreffenden:\n1. **Anlage- oder Änderungsdatum**: `CreateAndUpdateDateFrom` und/oder `CreateAndUpdateDateTo` ist gesetzt. Eine Zeile erfüllt die Untergrenze, wenn ihr Anlagedatum **oder** ihr Änderungsdatum `>=` dem From-Wert ist. Sie erfüllt die Obergrenze, wenn ihr Anlagedatum **oder** ihr Änderungsdatum `<` dem To-Wert ist.\n2. **Anlagedatum**: `CreateDateFrom` und/oder `CreateDateTo` ist gesetzt. Der Filter lautet `SDelDcreateDate >= From` und `SDelDcreateDate < To`.\n3. **Änderungsdatum**: `UpdateDateFrom` und/oder `UpdateDateTo` ist gesetzt. Der Filter lautet `SDelDupdateDate >= From` und `SDelDupdateDate < To`.\n4. **Schlüsselbereich**: Kein Datumsparameter ist gesetzt. Der Aufruf liefert die nächsten Zeilen nach `SDelDkey`.\n\nIn jedem Modus werden nur Zeilen mit `SDelDkey > @SDelDkey` geliefert. Zum seitenweisen Abruf wird der höchste `SDelDkey` der vorherigen Antwort als `SDelDkey` im nächsten Aufruf übergeben. Der Abruf endet, sobald weniger als `RowCount` Zeilen zurückkommen.\n\nDie Obergrenzen der Datumsbereiche sind exklusiv. Parameter eines niedriger priorisierten Modus werden ignoriert, wenn ein höher priorisierter Modus aktiv ist.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelDkey` | int | Nein | Exklusive Untergrenze für den Schlüssel der Lieferposition. Es werden nur Zeilen mit größerem `SDelDkey` geliefert. NULL wird als `0` behandelt. Für den seitenweisen Abruf den letzten Schlüssel der vorherigen Seite übergeben. |\n| `CreateDateFrom` | datetime | Nein | Inklusive Untergrenze für `SDelDcreateDate`. Wird nur verwendet, wenn keiner der kombinierten Anlage-/Änderungsdatumsparameter gesetzt ist. |\n| `CreateDateTo` | datetime | Nein | Exklusive Obergrenze für `SDelDcreateDate`. Wird nur verwendet, wenn keiner der kombinierten Anlage-/Änderungsdatumsparameter gesetzt ist. |\n| `UpdateDateFrom` | datetime | Nein | Inklusive Untergrenze für `SDelDupdateDate`. Wird nur verwendet, wenn weder ein kombinierter Datumsparameter noch ein Anlagedatumsparameter gesetzt ist. |\n| `UpdateDateTo` | datetime | Nein | Exklusive Obergrenze für `SDelDupdateDate`. Wird nur verwendet, wenn weder ein kombinierter Datumsparameter noch ein Anlagedatumsparameter gesetzt ist. |\n| `CreateAndUpdateDateFrom` | datetime | Nein | Inklusive Untergrenze, die zutrifft, wenn `SDelDcreateDate` oder `SDelDupdateDate` auf oder nach diesem Wert liegt. Hat die höchste Priorität unter den Filtermodi. |\n| `CreateAndUpdateDateTo` | datetime | Nein | Exklusive Obergrenze, die zutrifft, wenn `SDelDcreateDate` oder `SDelDupdateDate` vor diesem Wert liegt. Hat die höchste Priorität unter den Filtermodi. |\n| `RowCount` | int | Nein | Maximale Anzahl gelieferter Zeilen. NULL wird als `1000` behandelt. |\n\n- Alle Lesezugriffe verwenden `WITH (NOLOCK)`. Nicht festgeschriebene Daten können geliefert werden, und während Datenänderungen können Zeilen fehlen oder doppelt erscheinen.\n- `SDelDkey` wird immer als exklusive Untergrenze (`>`) verwendet. Die Übergabe eines bestimmten Schlüssels liefert diese Zeile **nicht**, sondern die Zeilen danach. Der Code enthält einen Zweig für den exakten Schlüsselabruf und einen Zweig für ein leeres Ergebnis, beide sind jedoch nicht erreichbar, weil `SDelDkey` und `RowCount` nach der Vorbereitung nie NULL sind.\n- Im kombinierten Anlage-/Änderungsmodus werden die From- und die To-Prüfung unabhängig voneinander ausgewertet. Eine Zeile kann die From-Grenze über das eine Datum und die To-Grenze über das andere Datum erfüllen. Zum Beispiel wird eine Zeile, die vor To angelegt und nach To geändert wurde, trotzdem geliefert.\n- Ein negativer Wert für `RowCount` führt zu einem SQL-Fehler bei `TOP`. `RowCount = 0` liefert keine Zeilen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiReadDeliveryItems"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 10235\n 4120\n 88231\n USB-C Ladekabel 1m\n 50\n 50\n 77812\n 2.50\n 0.00\n 2.50\n 2024-01-15T09:12:44\n MK\n 2024-01-15T10:03:10\n MK\n 0.00\n 2.50\n CH-2024-001\n 2026-12-31T00:00:00\n \n"
}
]
},
{
"name": "pixiSetHistoricalSupplierPrice",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Lieferantenpreis und Lieferant eines historischen Wareneingangs-Preisdatensatzes (InvBinItemLog_In_Price) ohne zugeordnete Lieferung.\n\nSetzt den Lieferantenpreis eines einzelnen historischen (FIFO-)Wareneingangs-Preisdatensatzes manuell. Der Datensatz wird über `InvBinItemLogId` identifiziert.\n\nAblauf:\n\n1. Alle vier Parameter sind Pflicht. Fehlt einer davon, wird eine Fehlerzeile zurückgegeben.\n2. Ein negativer `SupplierPrice` wird abgelehnt.\n3. `SupplierId` muss als `SuppliersKey` in `Suppliers` existieren.\n4. `UserName` muss als `USER_NAME` in `UCS_USERS` existieren. Die zugehörige Benutzer-ID wird als ändernder Benutzer gespeichert.\n5. Der Datensatz `InvBinItemLogId` muss in `InvBinItemLog_In_Price` existieren.\n6. Nur Datensätze ohne `DeliveryId` können geändert werden. Datensätze mit bereits zugeordneter Lieferung werden abgelehnt.\n7. Der Datensatz wird aktualisiert:\n - `Price` wird auf `SupplierPrice` gesetzt.\n - `SupplierId` wird auf `SupplierId` gesetzt.\n - `DeliveryId` und `DeliveryId_Assigned` werden auf NULL gesetzt.\n - `QuerySource` wird auf `5` gesetzt (manuelle Änderung über API).\n - `RecordModifiedByUserId` und `RecordModifiedOn` werden gesetzt; der Zeitstempel ist die aktuelle Zeit als `smalldatetime`.\n\nDer Aufruf liefert genau eine Zeile mit Status und Meldung zurück, entweder einen Fehler oder eine Erfolgsbestätigung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvBinItemLogId` | int | Nein | ID des historischen Wareneingangs-Preisdatensatzes in `InvBinItemLog_In_Price`. Faktisch Pflicht. |\n| `SupplierPrice` | money | Nein | Neuer Lieferantenpreis. Darf nicht negativ sein. Faktisch Pflicht. |\n| `SupplierId` | int | Nein | Lieferantenschlüssel (`SuppliersKey`), der am Datensatz gespeichert wird. Muss existieren. Faktisch Pflicht. |\n| `UserName` | varchar(30) | Nein | Pixi-Benutzername (`USER_NAME` in `UCS_USERS`), der als ändernder Benutzer gespeichert wird. Faktisch Pflicht. |\n\n- **Spaltennamen-Falle:** Fehlerzeilen der Validierung verwenden die Spalte `Status`. Die Erfolgszeile und die Fehlerzeile aus dem CATCH-Block verwenden die falsch geschriebene Spalte `Staus`. Clients sollten beide Spaltennamen prüfen.\n- Der Kopfkommentar der Prozedur („Returns FIFO supplier prices“) passt nicht zum Verhalten. Die Prozedur ändert Daten.\n- Die Prozedur öffnet eine eigene Transaktion oder einen Savepoint, falls der Aufrufer bereits eine offene Transaktion hat.\n- Die Validierungsprüfungen kehren vor einem Commit oder Rollback zurück. Ohne äußere Transaktion kann der Aufruf mit noch offener Transaktion enden. SQL Server kann dann eine Abweichung der Transaktionsanzahl melden.\n- Bei einem Laufzeitfehler wird die Transaktion bzw. der Savepoint zurückgerollt. Der Fehler wird über `log.InsertError` protokolliert (nicht beigefügt).\n- Lookups verwenden `NOLOCK`. Das Update verwendet `ROWLOCK`.\n- In der Erfolgsmeldung wird der Preis als `money`-nach-`varchar`-Konvertierung ausgegeben, also mit zwei Nachkommastellen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetHistoricalSupplierPrice"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Lieferantenpreis und Lieferant eines historischen Wareneingangs-Preisdatensatzes (InvBinItemLog_In_Price) ohne zugeordnete Lieferung.\n\nSetzt den Lieferantenpreis eines einzelnen historischen (FIFO-)Wareneingangs-Preisdatensatzes manuell. Der Datensatz wird über `InvBinItemLogId` identifiziert.\n\nAblauf:\n\n1. Alle vier Parameter sind Pflicht. Fehlt einer davon, wird eine Fehlerzeile zurückgegeben.\n2. Ein negativer `SupplierPrice` wird abgelehnt.\n3. `SupplierId` muss als `SuppliersKey` in `Suppliers` existieren.\n4. `UserName` muss als `USER_NAME` in `UCS_USERS` existieren. Die zugehörige Benutzer-ID wird als ändernder Benutzer gespeichert.\n5. Der Datensatz `InvBinItemLogId` muss in `InvBinItemLog_In_Price` existieren.\n6. Nur Datensätze ohne `DeliveryId` können geändert werden. Datensätze mit bereits zugeordneter Lieferung werden abgelehnt.\n7. Der Datensatz wird aktualisiert:\n - `Price` wird auf `SupplierPrice` gesetzt.\n - `SupplierId` wird auf `SupplierId` gesetzt.\n - `DeliveryId` und `DeliveryId_Assigned` werden auf NULL gesetzt.\n - `QuerySource` wird auf `5` gesetzt (manuelle Änderung über API).\n - `RecordModifiedByUserId` und `RecordModifiedOn` werden gesetzt; der Zeitstempel ist die aktuelle Zeit als `smalldatetime`.\n\nDer Aufruf liefert genau eine Zeile mit Status und Meldung zurück, entweder einen Fehler oder eine Erfolgsbestätigung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `InvBinItemLogId` | int | Nein | ID des historischen Wareneingangs-Preisdatensatzes in `InvBinItemLog_In_Price`. Faktisch Pflicht. |\n| `SupplierPrice` | money | Nein | Neuer Lieferantenpreis. Darf nicht negativ sein. Faktisch Pflicht. |\n| `SupplierId` | int | Nein | Lieferantenschlüssel (`SuppliersKey`), der am Datensatz gespeichert wird. Muss existieren. Faktisch Pflicht. |\n| `UserName` | varchar(30) | Nein | Pixi-Benutzername (`USER_NAME` in `UCS_USERS`), der als ändernder Benutzer gespeichert wird. Faktisch Pflicht. |\n\n- **Spaltennamen-Falle:** Fehlerzeilen der Validierung verwenden die Spalte `Status`. Die Erfolgszeile und die Fehlerzeile aus dem CATCH-Block verwenden die falsch geschriebene Spalte `Staus`. Clients sollten beide Spaltennamen prüfen.\n- Der Kopfkommentar der Prozedur („Returns FIFO supplier prices“) passt nicht zum Verhalten. Die Prozedur ändert Daten.\n- Die Prozedur öffnet eine eigene Transaktion oder einen Savepoint, falls der Aufrufer bereits eine offene Transaktion hat.\n- Die Validierungsprüfungen kehren vor einem Commit oder Rollback zurück. Ohne äußere Transaktion kann der Aufruf mit noch offener Transaktion enden. SQL Server kann dann eine Abweichung der Transaktionsanzahl melden.\n- Bei einem Laufzeitfehler wird die Transaktion bzw. der Savepoint zurückgerollt. Der Fehler wird über `log.InsertError` protokolliert (nicht beigefügt).\n- Lookups verwenden `NOLOCK`. Das Update verwendet `ROWLOCK`.\n- In der Erfolgsmeldung wird der Preis als `money`-nach-`varchar`-Konvertierung ausgegeben, also mit zwei Nachkommastellen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSetHistoricalSupplierPrice"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n Price (12.50) successfully updated for record: 123456.\n \n"
}
]
},
{
"name": "pixiSupplierOrderChangeStatus",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n MyWarehouseTool\n \n jdoe\n 3\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ändert den Status einer oder mehrerer Lieferantenbestellungen über die interne Prozedur pixi.SupplierOrderChangeStatus und liefert eine Statuszeile.\n\nSetzt einen neuen Status (`ChangeStatusIdTo`) für Lieferantenbestellungen.\n\n1. **Benutzerermittlung:** Ist `UserId` nicht angegeben, wird die Benutzer-ID anhand von `UserName` in `UCS_USERS` ermittelt. Existiert der Name nicht, wird die ID des Benutzers `pixiAdministration` verwendet.\n2. **Auswahl der Bestellungen:** Die Bestellungen werden über einen dieser Parameter bestimmt:\n - `SupplierOrderId`: ID einer einzelnen Lieferantenbestellung. Der Wert `0` wird wie `NULL` behandelt.\n - `SupplierOrderIds`: Liste von Lieferantenbestellungs-IDs, die unverändert an die interne Prozedur übergeben wird.\n - `SupplierOrderNR`: wird nur verwendet, wenn `SupplierOrderId` und `SupplierOrderIds` beide leer sind. Ermittelt wird die Lieferantenbestellung mit dieser `InternalNumber`. Passen mehrere Bestellungen, wird die mit der höchsten `Id` verwendet.\n - Ist keiner der drei Parameter angegeben, liefert der Aufruf `Invalid parameters`.\n3. **Statusprüfung:** Ist `ChangeStatusIdTo` = `3` (bestätigt, CON), muss die einzelne Bestellung in `SupplierOrderId` den Status `2` (bestellt, BES) haben. Andernfalls wird eine Fehlerzeile geliefert.\n4. **Statusänderung:** Der Aufruf führt `pixi.SupplierOrderChangeStatus` über `sp_executesql` aus. Übergeben werden Benutzer-ID, Zielstatus, die einzelne ID und die ID-Liste.\n5. Der Aufruf liefert eine Zeile mit `ReturnCode` = `Success`. Tritt ein Fehler auf, enthält die Zeile `ERROR` und die Fehlermeldung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Wird im Code nicht verwendet. |\n| `UserId` | int | Nein | ID des Benutzers, der die Änderung durchführt. Bei `NULL` wird die ID anhand von `UserName` ermittelt. |\n| `UserName` | varchar(50) | Ja | Benutzername, über den die Benutzer-ID ermittelt wird, wenn `UserId` leer ist. Bei unbekanntem Namen wird der Benutzer `pixiAdministration` verwendet. |\n| `ChangeStatusIdTo` | int | Ja | ID des Zielstatus. `3` (bestätigt, CON) ist nur zulässig, wenn die Bestellung den Status `2` (bestellt, BES) hat. Weitere gültige Werte sind in `pixi.SupplierOrderChangeStatus` festgelegt. |\n| `SupplierOrderId` | int | Nein | ID einer einzelnen Lieferantenbestellung. `0` wird wie `NULL` behandelt. |\n| `SupplierOrderIds` | varchar(8000) | Nein | Liste von Lieferantenbestellungs-IDs für eine Massenänderung, unverändert an `pixi.SupplierOrderChangeStatus` übergeben. Das Format ist dort festgelegt, vermutlich kommagetrennt. |\n| `SupplierOrderNR` | int | Nein | Interne Nummer (`InternalNumber`) einer Lieferantenbestellung. Wird nur verwendet, wenn `SupplierOrderId` und `SupplierOrderIds` leer sind. Passen mehrere Bestellungen, wird die mit der höchsten `Id` verwendet. |\n\n- Die eigentliche Statusänderung erfolgt in `pixi.SupplierOrderChangeStatus`, deren Definition nicht vorliegt. Daher sind unbekannt: die genaue Logik, die geschriebenen Tabellen, die gültigen Zielstatus-IDs, das erwartete Format von `SupplierOrderIds` (vermutlich kommagetrennt) und eventuelle eigene Ergebnismengen.\n- Die CON/BES-Prüfung gilt nur für `SupplierOrderId`, auch für die über `SupplierOrderNR` ermittelte ID. Bestellungen, die nur in `SupplierOrderIds` übergeben werden, werden hier nicht geprüft.\n- Findet `SupplierOrderNR` keine Bestellung, wird kein Fehler geliefert. Der Aufruf läuft mit leerer ID weiter.\n- Die Statusprüfung liest `SupplierOrder` mit `NOLOCK`.\n- Der Aufruf läuft in einer eigenen Transaktion. Besteht beim Aufrufer bereits eine offene Transaktion, wird stattdessen ein Savepoint verwendet. Bei einem Fehler wird auf diesen Punkt zurückgerollt. Eine nicht mehr commitfähige Transaktion kann bei diesem Rollback einen weiteren Fehler auslösen.\n- `AppName` ist deklariert, wird aber nicht verwendet.\n- `UserName` hat keinen Standardwert und muss immer übergeben werden, auch wenn `UserId` angegeben ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderChangeStatus"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n MyWarehouseTool\n \n jdoe\n 3\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Ändert den Status einer oder mehrerer Lieferantenbestellungen über die interne Prozedur pixi.SupplierOrderChangeStatus und liefert eine Statuszeile.\n\nSetzt einen neuen Status (`ChangeStatusIdTo`) für Lieferantenbestellungen.\n\n1. **Benutzerermittlung:** Ist `UserId` nicht angegeben, wird die Benutzer-ID anhand von `UserName` in `UCS_USERS` ermittelt. Existiert der Name nicht, wird die ID des Benutzers `pixiAdministration` verwendet.\n2. **Auswahl der Bestellungen:** Die Bestellungen werden über einen dieser Parameter bestimmt:\n - `SupplierOrderId`: ID einer einzelnen Lieferantenbestellung. Der Wert `0` wird wie `NULL` behandelt.\n - `SupplierOrderIds`: Liste von Lieferantenbestellungs-IDs, die unverändert an die interne Prozedur übergeben wird.\n - `SupplierOrderNR`: wird nur verwendet, wenn `SupplierOrderId` und `SupplierOrderIds` beide leer sind. Ermittelt wird die Lieferantenbestellung mit dieser `InternalNumber`. Passen mehrere Bestellungen, wird die mit der höchsten `Id` verwendet.\n - Ist keiner der drei Parameter angegeben, liefert der Aufruf `Invalid parameters`.\n3. **Statusprüfung:** Ist `ChangeStatusIdTo` = `3` (bestätigt, CON), muss die einzelne Bestellung in `SupplierOrderId` den Status `2` (bestellt, BES) haben. Andernfalls wird eine Fehlerzeile geliefert.\n4. **Statusänderung:** Der Aufruf führt `pixi.SupplierOrderChangeStatus` über `sp_executesql` aus. Übergeben werden Benutzer-ID, Zielstatus, die einzelne ID und die ID-Liste.\n5. Der Aufruf liefert eine Zeile mit `ReturnCode` = `Success`. Tritt ein Fehler auf, enthält die Zeile `ERROR` und die Fehlermeldung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Wird im Code nicht verwendet. |\n| `UserId` | int | Nein | ID des Benutzers, der die Änderung durchführt. Bei `NULL` wird die ID anhand von `UserName` ermittelt. |\n| `UserName` | varchar(50) | Ja | Benutzername, über den die Benutzer-ID ermittelt wird, wenn `UserId` leer ist. Bei unbekanntem Namen wird der Benutzer `pixiAdministration` verwendet. |\n| `ChangeStatusIdTo` | int | Ja | ID des Zielstatus. `3` (bestätigt, CON) ist nur zulässig, wenn die Bestellung den Status `2` (bestellt, BES) hat. Weitere gültige Werte sind in `pixi.SupplierOrderChangeStatus` festgelegt. |\n| `SupplierOrderId` | int | Nein | ID einer einzelnen Lieferantenbestellung. `0` wird wie `NULL` behandelt. |\n| `SupplierOrderIds` | varchar(8000) | Nein | Liste von Lieferantenbestellungs-IDs für eine Massenänderung, unverändert an `pixi.SupplierOrderChangeStatus` übergeben. Das Format ist dort festgelegt, vermutlich kommagetrennt. |\n| `SupplierOrderNR` | int | Nein | Interne Nummer (`InternalNumber`) einer Lieferantenbestellung. Wird nur verwendet, wenn `SupplierOrderId` und `SupplierOrderIds` leer sind. Passen mehrere Bestellungen, wird die mit der höchsten `Id` verwendet. |\n\n- Die eigentliche Statusänderung erfolgt in `pixi.SupplierOrderChangeStatus`, deren Definition nicht vorliegt. Daher sind unbekannt: die genaue Logik, die geschriebenen Tabellen, die gültigen Zielstatus-IDs, das erwartete Format von `SupplierOrderIds` (vermutlich kommagetrennt) und eventuelle eigene Ergebnismengen.\n- Die CON/BES-Prüfung gilt nur für `SupplierOrderId`, auch für die über `SupplierOrderNR` ermittelte ID. Bestellungen, die nur in `SupplierOrderIds` übergeben werden, werden hier nicht geprüft.\n- Findet `SupplierOrderNR` keine Bestellung, wird kein Fehler geliefert. Der Aufruf läuft mit leerer ID weiter.\n- Die Statusprüfung liest `SupplierOrder` mit `NOLOCK`.\n- Der Aufruf läuft in einer eigenen Transaktion. Besteht beim Aufrufer bereits eine offene Transaktion, wird stattdessen ein Savepoint verwendet. Bei einem Fehler wird auf diesen Punkt zurückgerollt. Eine nicht mehr commitfähige Transaktion kann bei diesem Rollback einen weiteren Fehler auslösen.\n- `AppName` ist deklariert, wird aber nicht verwendet.\n- `UserName` hat keinen Standardwert und muss immer übergeben werden, auch wenn `UserId` angegeben ist.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderChangeStatus"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Success\n \n \n"
}
]
},
{
"name": "pixiSupplierOrderCreate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n ShopConnector\n \n jdoe\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine Lieferantenbestellung oder Vorbestellung aus einem XML-Dokument für einen Lieferanten, Liefer- und Bestelllager an.\n\nLegt eine Lieferantenbestellung (`Type` = 1) oder eine Vorbestellung (`Type` = 2) an. Die eigentliche Anlage übernimmt die interne Prozedur `pixi.SupplierOrderCreate`. Dieser Wrapper löst die Eingabewerte auf und bereitet die Rückgabe auf.\n\nAblauf:\n\n1. Jeder `Type` außer `2` wird als `1` behandelt.\n2. Bei Lieferantenbestellungen (`Type` = 1) muss `OrderConsiderationStartDate` leer sein. Andernfalls wird eine Fehlerzeile geliefert und nichts angelegt.\n3. Eine Transaktion wird gestartet. Besteht bereits eine äußere Transaktion, wird stattdessen ein Savepoint gesetzt.\n4. `UserId` wird aus `UserName` ermittelt, falls nicht angegeben. Bei unbekanntem Benutzernamen wird auf den Benutzer `pixiAdministration` zurückgegriffen.\n5. Der Lieferant wird über `SupplierId` (`Suppliers.SuppliersKey`) ermittelt, oder über `SupplierNr` (`SupplNr`), wenn `SupplierId` NULL ist.\n6. Lieferlager und Bestelllager werden über ihren Schlüssel (`DeliveryLocationId`, `OrderLocationId`) ermittelt, oder über das Lagerkürzel `LocID` (`DeliveryLocation`, `OrderLocation`), wenn der Schlüssel NULL ist. Eine angegebene, aber nicht existierende ID ergibt NULL. Auf das Kürzel wird dann nicht ausgewichen.\n7. Die Eingabewerte werden normalisiert:\n - `ConsiderPackageUnits` und `ConsiderMinOrderQty`: NULL wird zu `0`.\n - `EstimatedDeliveryDate` und `OrderConsiderationStartDate`: Der Zeitanteil wird entfernt.\n - `ExternalCode`: Ein Leerstring wird zu NULL.\n8. `pixi.SupplierOrderCreate` wird mit dem Bestelldokument `SupplOrderDocument` und allen aufgelösten Werten ausgeführt.\n9. Bei `ShowDetailedReturn` = 1 wird eine Detail-Ergebnismenge geliefert. Sie enthält je Artikelzeile der Eingabe eine Zeile und zeigt, wie die Zeile zugeordnet wurde. Der Status ist einer der Werte `OK`, `Item not found`, `Item does not have the correct supplier assigned` oder `Item number supplier is missing for the item`. Die Zeile enthält außerdem die angelegte Bestellung und Bestellposition, sofern vorhanden. Bei `ShowDetailedReturn` = 0 wird die innere Prozedur stattdessen angewiesen, die angelegten IDs zurückzugeben.\n10. Hat der Aufruf eine eigene Transaktion geöffnet, wird sie committet. Nach dem Commit wird eine `ReturnCode`/`ErrorMessage`-Zeile geliefert, falls Lieferant, Lieferlager oder Bestelllager nicht aufgelöst werden konnten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Wird im Code nicht verwendet. |\n| `UserId` | int | Nein | ID des Pixi-Benutzers. Bei NULL wird sie aus `UserName` ermittelt. |\n| `UserName` | varchar(50) | Ja | Pixi-Benutzername. Wird nur verwendet, wenn `UserId` NULL ist. Unbekannte Namen fallen auf `pixiAdministration` zurück. |\n| `SupplierId` | int | Nein | Lieferantenschlüssel (`SuppliersKey`). Hat Vorrang vor `SupplierNr`. |\n| `SupplierNr` | varchar(4) | Nein | Lieferantennummer (`SupplNr`). Wird verwendet, wenn `SupplierId` NULL ist. |\n| `DeliveryLocation` | varchar(3) | Nein | Lagerkürzel (`LocID`) des Liefer- und Rechnungslagers. Wird verwendet, wenn `DeliveryLocationId` NULL ist. |\n| `DeliveryLocationId` | int | Nein | Lagerschlüssel des Liefer- und Rechnungslagers. Hat Vorrang vor `DeliveryLocation`. |\n| `OrderLocation` | varchar(3) | Nein | Lagerkürzel (`LocID`) des Bestelllagers. Wird verwendet, wenn `OrderLocationId` NULL ist. |\n| `OrderLocationId` | int | Nein | Lagerschlüssel des Bestelllagers. Hat Vorrang vor `OrderLocation`. |\n| `SupplOrderDocument` | xml | Ja | XML-Dokument mit den Bestellpositionen. Es wird von `pixi.SupplierOrderCreate` ausgewertet, das nicht vorliegt. Die genaue Struktur ist aus diesem Code daher nicht bekannt. |\n| `ConsiderPackageUnits` | bit | Nein | Ob Verpackungseinheiten bei den Mengen berücksichtigt werden. NULL wird als 0 behandelt. |\n| `ConsiderMinOrderQty` | bit | Nein | Ob die Mindestbestellmenge berücksichtigt wird. NULL wird als 0 behandelt. |\n| `ExternalCode` | nvarchar(50) | Nein | Externe Referenz der Bestellung. Ein Leerstring wird als NULL behandelt. |\n| `EstimatedDeliveryDate` | datetime | Nein | Voraussichtliches Lieferdatum. Der Zeitanteil wird entfernt. |\n| `ShowDetailedReturn` | bit | Nein | 1 liefert je Eingabezeile eine Detailzeile mit Zuordnungsstatus. Bei 0 liefert die innere Prozedur die angelegten IDs. |\n| `Type` | int | Nein | Bestellart. Jeder Wert außer 2 wird als 1 behandelt. |\n| `OrderConsiderationStartDate` | datetime | Nein | Startdatum der Bestellberücksichtigung. Nur bei Vorbestellungen (`Type` = 2) zulässig. Der Zeitanteil wird entfernt. |\n\n- Aufbau von `SupplOrderDocument` und die eigentlichen Inserts sind in `pixi.SupplierOrderCreate` definiert, das nicht vorliegt. XML-Struktur, die Ergebnismenge mit den angelegten IDs und die geschriebenen Tabellen lassen sich aus diesem Code nicht ableiten. Die Detailrückgabe deutet darauf hin, dass Zeilen Artikel über die interne Artikelnummer (Abgleich mit `pixi.ItemCode` mit `CodeTypeId` = 2), die Lieferantenartikelnummer oder die Artikel-ID identifizieren.\n- Lieferant und Lager werden erst **nach** Ausführung der inneren Prozedur und dem Commit geprüft. Deren Prüfmeldung garantiert daher nicht, dass nichts geschrieben wurde.\n- Läuft der Aufruf in einer äußeren Transaktion, wird keine Prüfmeldung geliefert. Der Commit liegt dann ebenfalls beim Aufrufer.\n- Die Prüfzeile verwendet den `ReturnCode`-Wert `Error ` mit nachgestelltem Leerzeichen, andere Fehler verwenden `ERROR`.\n- Im Detailmodus wird die angelegte Bestellung als `MAX(Id)` von `pixi.SupplierOrder` ermittelt. Bei parallel angelegten Bestellungen kann dies eine andere Bestellung sein.\n- Lookups verwenden `NOLOCK`.\n- Fehler werden abgefangen. Transaktion bzw. Savepoint werden zurückgerollt, und der Fehler wird als Zeile mit `ReturnCode` = `ERROR` geliefert, nicht als SQL-Fehler.\n- `AppName` ist Pflicht, wird im Code aber nicht verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderCreate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n ShopConnector\n \n jdoe\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine Lieferantenbestellung oder Vorbestellung aus einem XML-Dokument für einen Lieferanten, Liefer- und Bestelllager an.\n\nLegt eine Lieferantenbestellung (`Type` = 1) oder eine Vorbestellung (`Type` = 2) an. Die eigentliche Anlage übernimmt die interne Prozedur `pixi.SupplierOrderCreate`. Dieser Wrapper löst die Eingabewerte auf und bereitet die Rückgabe auf.\n\nAblauf:\n\n1. Jeder `Type` außer `2` wird als `1` behandelt.\n2. Bei Lieferantenbestellungen (`Type` = 1) muss `OrderConsiderationStartDate` leer sein. Andernfalls wird eine Fehlerzeile geliefert und nichts angelegt.\n3. Eine Transaktion wird gestartet. Besteht bereits eine äußere Transaktion, wird stattdessen ein Savepoint gesetzt.\n4. `UserId` wird aus `UserName` ermittelt, falls nicht angegeben. Bei unbekanntem Benutzernamen wird auf den Benutzer `pixiAdministration` zurückgegriffen.\n5. Der Lieferant wird über `SupplierId` (`Suppliers.SuppliersKey`) ermittelt, oder über `SupplierNr` (`SupplNr`), wenn `SupplierId` NULL ist.\n6. Lieferlager und Bestelllager werden über ihren Schlüssel (`DeliveryLocationId`, `OrderLocationId`) ermittelt, oder über das Lagerkürzel `LocID` (`DeliveryLocation`, `OrderLocation`), wenn der Schlüssel NULL ist. Eine angegebene, aber nicht existierende ID ergibt NULL. Auf das Kürzel wird dann nicht ausgewichen.\n7. Die Eingabewerte werden normalisiert:\n - `ConsiderPackageUnits` und `ConsiderMinOrderQty`: NULL wird zu `0`.\n - `EstimatedDeliveryDate` und `OrderConsiderationStartDate`: Der Zeitanteil wird entfernt.\n - `ExternalCode`: Ein Leerstring wird zu NULL.\n8. `pixi.SupplierOrderCreate` wird mit dem Bestelldokument `SupplOrderDocument` und allen aufgelösten Werten ausgeführt.\n9. Bei `ShowDetailedReturn` = 1 wird eine Detail-Ergebnismenge geliefert. Sie enthält je Artikelzeile der Eingabe eine Zeile und zeigt, wie die Zeile zugeordnet wurde. Der Status ist einer der Werte `OK`, `Item not found`, `Item does not have the correct supplier assigned` oder `Item number supplier is missing for the item`. Die Zeile enthält außerdem die angelegte Bestellung und Bestellposition, sofern vorhanden. Bei `ShowDetailedReturn` = 0 wird die innere Prozedur stattdessen angewiesen, die angelegten IDs zurückzugeben.\n10. Hat der Aufruf eine eigene Transaktion geöffnet, wird sie committet. Nach dem Commit wird eine `ReturnCode`/`ErrorMessage`-Zeile geliefert, falls Lieferant, Lieferlager oder Bestelllager nicht aufgelöst werden konnten.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Wird im Code nicht verwendet. |\n| `UserId` | int | Nein | ID des Pixi-Benutzers. Bei NULL wird sie aus `UserName` ermittelt. |\n| `UserName` | varchar(50) | Ja | Pixi-Benutzername. Wird nur verwendet, wenn `UserId` NULL ist. Unbekannte Namen fallen auf `pixiAdministration` zurück. |\n| `SupplierId` | int | Nein | Lieferantenschlüssel (`SuppliersKey`). Hat Vorrang vor `SupplierNr`. |\n| `SupplierNr` | varchar(4) | Nein | Lieferantennummer (`SupplNr`). Wird verwendet, wenn `SupplierId` NULL ist. |\n| `DeliveryLocation` | varchar(3) | Nein | Lagerkürzel (`LocID`) des Liefer- und Rechnungslagers. Wird verwendet, wenn `DeliveryLocationId` NULL ist. |\n| `DeliveryLocationId` | int | Nein | Lagerschlüssel des Liefer- und Rechnungslagers. Hat Vorrang vor `DeliveryLocation`. |\n| `OrderLocation` | varchar(3) | Nein | Lagerkürzel (`LocID`) des Bestelllagers. Wird verwendet, wenn `OrderLocationId` NULL ist. |\n| `OrderLocationId` | int | Nein | Lagerschlüssel des Bestelllagers. Hat Vorrang vor `OrderLocation`. |\n| `SupplOrderDocument` | xml | Ja | XML-Dokument mit den Bestellpositionen. Es wird von `pixi.SupplierOrderCreate` ausgewertet, das nicht vorliegt. Die genaue Struktur ist aus diesem Code daher nicht bekannt. |\n| `ConsiderPackageUnits` | bit | Nein | Ob Verpackungseinheiten bei den Mengen berücksichtigt werden. NULL wird als 0 behandelt. |\n| `ConsiderMinOrderQty` | bit | Nein | Ob die Mindestbestellmenge berücksichtigt wird. NULL wird als 0 behandelt. |\n| `ExternalCode` | nvarchar(50) | Nein | Externe Referenz der Bestellung. Ein Leerstring wird als NULL behandelt. |\n| `EstimatedDeliveryDate` | datetime | Nein | Voraussichtliches Lieferdatum. Der Zeitanteil wird entfernt. |\n| `ShowDetailedReturn` | bit | Nein | 1 liefert je Eingabezeile eine Detailzeile mit Zuordnungsstatus. Bei 0 liefert die innere Prozedur die angelegten IDs. |\n| `Type` | int | Nein | Bestellart. Jeder Wert außer 2 wird als 1 behandelt. |\n| `OrderConsiderationStartDate` | datetime | Nein | Startdatum der Bestellberücksichtigung. Nur bei Vorbestellungen (`Type` = 2) zulässig. Der Zeitanteil wird entfernt. |\n\n- Aufbau von `SupplOrderDocument` und die eigentlichen Inserts sind in `pixi.SupplierOrderCreate` definiert, das nicht vorliegt. XML-Struktur, die Ergebnismenge mit den angelegten IDs und die geschriebenen Tabellen lassen sich aus diesem Code nicht ableiten. Die Detailrückgabe deutet darauf hin, dass Zeilen Artikel über die interne Artikelnummer (Abgleich mit `pixi.ItemCode` mit `CodeTypeId` = 2), die Lieferantenartikelnummer oder die Artikel-ID identifizieren.\n- Lieferant und Lager werden erst **nach** Ausführung der inneren Prozedur und dem Commit geprüft. Deren Prüfmeldung garantiert daher nicht, dass nichts geschrieben wurde.\n- Läuft der Aufruf in einer äußeren Transaktion, wird keine Prüfmeldung geliefert. Der Commit liegt dann ebenfalls beim Aufrufer.\n- Die Prüfzeile verwendet den `ReturnCode`-Wert `Error ` mit nachgestelltem Leerzeichen, andere Fehler verwenden `ERROR`.\n- Im Detailmodus wird die angelegte Bestellung als `MAX(Id)` von `pixi.SupplierOrder` ermittelt. Bei parallel angelegten Bestellungen kann dies eine andere Bestellung sein.\n- Lookups verwenden `NOLOCK`.\n- Fehler werden abgefangen. Transaktion bzw. Savepoint werden zurückgerollt, und der Fehler wird als Zeile mit `ReturnCode` = `ERROR` geliefert, nicht als SQL-Fehler.\n- `AppName` ist Pflicht, wird im Code aber nicht verwendet.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderCreate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1534\n SO-001534\n 8821\n 4711\n Kaffeetasse weiß\n KT-100\n 100200\n OK\n 100200\n \n \n 999999\n Item not found\n \n"
}
]
},
{
"name": "pixiSupplierOrderDelete",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht eine oder mehrere Lieferantenbestellungen, identifiziert über ID oder interne Nummer, und liefert eine Statuszeile.\n\nLöscht Lieferantenbestellungen. Die zu löschenden Bestellungen können auf vier Arten übergeben werden, die sich **beliebig kombinieren** lassen:\n\n- `SupplierOrderId`: eine einzelne ID einer Lieferantenbestellung.\n- `SupplierOrderIds`: eine kommagetrennte Liste von IDs.\n- `SupplierOrderNr`: eine einzelne interne Bestellnummer (`SupplierOrder.InternalNumber`). Sie wird in die zugehörige ID aufgelöst.\n- `SupplierOrderNrs`: eine kommagetrennte Liste interner Bestellnummern. Sie werden in IDs aufgelöst.\n\nWerte `0`, `NULL` oder Leerstring gelten als \"nicht angegeben\". Alle aus diesen Parametern ermittelten IDs werden zu einer Kandidatenliste zusammengeführt. Diese Liste wird als kommagetrennter String an die interne Prozedur `pixi.SupplierOrderDelete` übergeben, die das eigentliche Löschen ausführt.\n\nAnschließend wird geprüft, ob noch eine der Kandidaten-IDs in `SupplierOrder` vorhanden ist:\n\n- Ist keine mehr vorhanden, wird `ReturnCode` = `SUCCESS` mit leerer `ErrorMessage` geliefert.\n- Ist mindestens eine noch vorhanden, wird `ReturnCode` = `WARNING` mit der Meldung *Some Purchase Orders from list were not deleted.* geliefert. Welche Bestellungen nicht gelöscht wurden, wird nicht angegeben.\n\nBei einem Fehler wird die Transaktion zurückgerollt und eine Zeile mit `ReturnCode` = `ERROR` und dem SQL-Fehlertext geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Nein | Name der aufrufenden Anwendung. Deklariert, aber im Code nicht verwendet. |\n| `SupplierOrderId` | int | Nein | ID einer einzelnen zu löschenden Lieferantenbestellung. `0` oder `NULL` bedeutet nicht angegeben. |\n| `SupplierOrderIds` | varchar(8000) | Nein | Kommagetrennte Liste von IDs der zu löschenden Lieferantenbestellungen. Leerzeichen um Einträge werden entfernt. Leer bedeutet nicht angegeben. |\n| `SupplierOrderNr` | int | Nein | Interne Nummer (`InternalNumber`) einer einzelnen zu löschenden Lieferantenbestellung. `0` oder `NULL` bedeutet nicht angegeben. |\n| `SupplierOrderNrs` | varchar(8000) | Nein | Kommagetrennte Liste interner Nummern der zu löschenden Lieferantenbestellungen. Jeder Eintrag muss eine Ganzzahl sein. Leer bedeutet nicht angegeben. |\n\n- Die eigentliche Löschlogik (welche Bestellungen gelöscht werden dürfen, welche abhängigen Daten entfernt werden) liegt in `pixi.SupplierOrderDelete`, deren Definition nicht vorliegt. Deren Regeln und eventuelle eigene Ergebnismengen sind unbekannt.\n- Die Verarbeitung läuft in einer Transaktion. Besteht beim Aufrufer bereits eine offene Transaktion, wird stattdessen ein Savepoint verwendet, und **bei Erfolg wird keine Statuszeile geliefert**; nur die Fehlerzeile wird dann zurückgegeben. Ein normaler SOAP-Aufruf hat keine äußere Transaktion und erhält immer eine Statuszeile.\n- `AppName` ist deklariert, wird aber nicht verwendet.\n- IDs in `SupplierOrderIds` werden nicht auf Existenz geprüft. Nicht existierende IDs führen nicht zu einer Warnung, da die abschließende Prüfung nur noch vorhandene Kandidaten betrachtet.\n- Nicht numerische Einträge in `SupplierOrderIds` oder `SupplierOrderNrs` führen zu einem Konvertierungsfehler und einer `ERROR`-Zeile; es wird nichts gelöscht.\n- Wird keine Bestellung angegeben, wird eine leere Liste (`NULL`) an `pixi.SupplierOrderDelete` übergeben. Wie diese Prozedur damit umgeht, ist nicht ersichtlich.\n- Die Auflösung interner Nummern und die abschließende Existenzprüfung verwenden `NOLOCK`.\n- `SupplierOrderIds` und `SupplierOrderNrs` sind auf 8000 Zeichen begrenzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderDelete"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht eine oder mehrere Lieferantenbestellungen, identifiziert über ID oder interne Nummer, und liefert eine Statuszeile.\n\nLöscht Lieferantenbestellungen. Die zu löschenden Bestellungen können auf vier Arten übergeben werden, die sich **beliebig kombinieren** lassen:\n\n- `SupplierOrderId`: eine einzelne ID einer Lieferantenbestellung.\n- `SupplierOrderIds`: eine kommagetrennte Liste von IDs.\n- `SupplierOrderNr`: eine einzelne interne Bestellnummer (`SupplierOrder.InternalNumber`). Sie wird in die zugehörige ID aufgelöst.\n- `SupplierOrderNrs`: eine kommagetrennte Liste interner Bestellnummern. Sie werden in IDs aufgelöst.\n\nWerte `0`, `NULL` oder Leerstring gelten als \"nicht angegeben\". Alle aus diesen Parametern ermittelten IDs werden zu einer Kandidatenliste zusammengeführt. Diese Liste wird als kommagetrennter String an die interne Prozedur `pixi.SupplierOrderDelete` übergeben, die das eigentliche Löschen ausführt.\n\nAnschließend wird geprüft, ob noch eine der Kandidaten-IDs in `SupplierOrder` vorhanden ist:\n\n- Ist keine mehr vorhanden, wird `ReturnCode` = `SUCCESS` mit leerer `ErrorMessage` geliefert.\n- Ist mindestens eine noch vorhanden, wird `ReturnCode` = `WARNING` mit der Meldung *Some Purchase Orders from list were not deleted.* geliefert. Welche Bestellungen nicht gelöscht wurden, wird nicht angegeben.\n\nBei einem Fehler wird die Transaktion zurückgerollt und eine Zeile mit `ReturnCode` = `ERROR` und dem SQL-Fehlertext geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Nein | Name der aufrufenden Anwendung. Deklariert, aber im Code nicht verwendet. |\n| `SupplierOrderId` | int | Nein | ID einer einzelnen zu löschenden Lieferantenbestellung. `0` oder `NULL` bedeutet nicht angegeben. |\n| `SupplierOrderIds` | varchar(8000) | Nein | Kommagetrennte Liste von IDs der zu löschenden Lieferantenbestellungen. Leerzeichen um Einträge werden entfernt. Leer bedeutet nicht angegeben. |\n| `SupplierOrderNr` | int | Nein | Interne Nummer (`InternalNumber`) einer einzelnen zu löschenden Lieferantenbestellung. `0` oder `NULL` bedeutet nicht angegeben. |\n| `SupplierOrderNrs` | varchar(8000) | Nein | Kommagetrennte Liste interner Nummern der zu löschenden Lieferantenbestellungen. Jeder Eintrag muss eine Ganzzahl sein. Leer bedeutet nicht angegeben. |\n\n- Die eigentliche Löschlogik (welche Bestellungen gelöscht werden dürfen, welche abhängigen Daten entfernt werden) liegt in `pixi.SupplierOrderDelete`, deren Definition nicht vorliegt. Deren Regeln und eventuelle eigene Ergebnismengen sind unbekannt.\n- Die Verarbeitung läuft in einer Transaktion. Besteht beim Aufrufer bereits eine offene Transaktion, wird stattdessen ein Savepoint verwendet, und **bei Erfolg wird keine Statuszeile geliefert**; nur die Fehlerzeile wird dann zurückgegeben. Ein normaler SOAP-Aufruf hat keine äußere Transaktion und erhält immer eine Statuszeile.\n- `AppName` ist deklariert, wird aber nicht verwendet.\n- IDs in `SupplierOrderIds` werden nicht auf Existenz geprüft. Nicht existierende IDs führen nicht zu einer Warnung, da die abschließende Prüfung nur noch vorhandene Kandidaten betrachtet.\n- Nicht numerische Einträge in `SupplierOrderIds` oder `SupplierOrderNrs` führen zu einem Konvertierungsfehler und einer `ERROR`-Zeile; es wird nichts gelöscht.\n- Wird keine Bestellung angegeben, wird eine leere Liste (`NULL`) an `pixi.SupplierOrderDelete` übergeben. Wie diese Prozedur damit umgeht, ist nicht ersichtlich.\n- Die Auflösung interner Nummern und die abschließende Existenzprüfung verwenden `NOLOCK`.\n- `SupplierOrderIds` und `SupplierOrderNrs` sind auf 8000 Zeichen begrenzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderDelete"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n SUCCESS\n \n"
}
]
},
{
"name": "pixiSupplierOrderLineCreate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n 471110]]>\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt Positionen zu einer bestehenden Lieferantenbestellung im Status NEW oder BES anhand eines XML-Dokuments mit Artikeln an.\n\nFügt Positionen zu einer bestehenden Lieferantenbestellung hinzu.\n\n1. Der Benutzer wird über `UserName` ermittelt. Ist der Name unbekannt, wird der Benutzer `pixiAdministration` verwendet.\n2. `ConsiderPackageUnits` und `ConsiderMinOrderQty` werden bei `NULL` auf `0` gesetzt.\n3. Die Lieferantenbestellung wird in `SupplierOrder` über `Id = SupplierOrderId` **oder** `InternalNumber = SupplierOrderNr` gesucht. Es muss genau eine Bestellung gefunden werden:\n - kein Treffer: Fehler *Purchase order does not exist!*\n - mehr als ein Treffer: Fehler *Parameters @SupplierOrderId and @SupplierOrderNr belong to different purchase order!*\n4. Die Bestellung muss den Status `1` (NEW) oder `2` (BES) haben. Andernfalls liefert der Aufruf *Purchase order is not in status NEW or BES!*\n5. Sind alle Prüfungen erfolgreich, legt die interne Prozedur `pixi.SupplierOrderLineCreate` die Positionen an. Sie erhält die Bestell-ID, die Benutzer-ID, beide Schalter und `PurchaseOrderXML`.\n\nDer Aufruf liefert eine Ergebnismenge mit Statuszeilen (`Status`, `StatusDescription`, `ItemId`), sortiert nach `Status` und `ItemId`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplierOrderId` | int | Nein | Interne ID der Lieferantenbestellung (`SupplierOrder.Id`). Alternative zu `SupplierOrderNr`. |\n| `SupplierOrderNr` | int | Nein | Interne Nummer der Lieferantenbestellung (`SupplierOrder.InternalNumber`). Alternative zu `SupplierOrderId`. |\n| `UserName` | varchar(50) | Nein | Pixi-Benutzername, unter dem die Positionen angelegt werden. Bei unbekanntem Namen wird `pixiAdministration` verwendet. |\n| `ConsiderPackageUnits` | bit | Nein | Legt fest, ob Verpackungseinheiten beim Anlegen der Positionen berücksichtigt werden. `NULL` wird als `0` behandelt. |\n| `ConsiderMinOrderQty` | bit | Nein | Legt fest, ob die Mindestbestellmenge beim Anlegen der Positionen berücksichtigt wird. `NULL` wird als `0` behandelt. |\n| `PurchaseOrderXML` | xml | Ja | XML-Dokument mit den anzulegenden Positionen. Es wird unverändert an `pixi.SupplierOrderLineCreate` übergeben. Die Struktur ist dort festgelegt und in diesem Code nicht sichtbar, das Beispiel ist daher nur illustrativ. |\n\n- Das eigentliche Anlegen der Positionen erfolgt in `pixi.SupplierOrderLineCreate`, das nicht beigefügt ist. Daher lässt sich hier Folgendes nicht dokumentieren:\n - die erwartete Struktur von `PurchaseOrderXML`\n - wie Verpackungseinheiten und Mindestbestellmengen angewendet werden\n - welche Tabellen geschrieben werden\n - welche Status- und Beschreibungswerte bei Erfolg im Ergebnis erscheinen\n- `pixi.SupplierOrderLineCreate` wird mit `@pipiSupplierOrderLineCreate_ReturnInfo = 1` aufgerufen. Vermutlich schreibt es seine Ergebnisse je Artikel in die temporäre Ergebnistabelle, die dieser Aufruf zurückgibt.\n- Nur einen der Parameter `SupplierOrderId` oder `SupplierOrderNr` übergeben oder sicherstellen, dass beide zur selben Bestellung gehören. Die Suche verwendet `OR`, daher führen zwei verschiedene Treffer zu einem Fehler. Sind beide `NULL`, wird nichts gefunden und *Purchase order does not exist!* zurückgegeben.\n- Die Suche nach der Bestellung verwendet `NOLOCK`.\n- Der Aufruf läuft in einer eigenen Transaktion bzw. in einem Savepoint, falls bereits eine Transaktion offen ist.\n- Bei einem SQL-Fehler wird die Transaktion zurückgerollt und der Fehler über `log.InsertError` protokolliert. Ob der Fehler an den Aufrufer weitergegeben wird, hängt von dieser nicht beigefügten Prozedur ab. In diesem Fall kann die Status-Ergebnismenge fehlen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderLineCreate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n 471110]]>\n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt Positionen zu einer bestehenden Lieferantenbestellung im Status NEW oder BES anhand eines XML-Dokuments mit Artikeln an.\n\nFügt Positionen zu einer bestehenden Lieferantenbestellung hinzu.\n\n1. Der Benutzer wird über `UserName` ermittelt. Ist der Name unbekannt, wird der Benutzer `pixiAdministration` verwendet.\n2. `ConsiderPackageUnits` und `ConsiderMinOrderQty` werden bei `NULL` auf `0` gesetzt.\n3. Die Lieferantenbestellung wird in `SupplierOrder` über `Id = SupplierOrderId` **oder** `InternalNumber = SupplierOrderNr` gesucht. Es muss genau eine Bestellung gefunden werden:\n - kein Treffer: Fehler *Purchase order does not exist!*\n - mehr als ein Treffer: Fehler *Parameters @SupplierOrderId and @SupplierOrderNr belong to different purchase order!*\n4. Die Bestellung muss den Status `1` (NEW) oder `2` (BES) haben. Andernfalls liefert der Aufruf *Purchase order is not in status NEW or BES!*\n5. Sind alle Prüfungen erfolgreich, legt die interne Prozedur `pixi.SupplierOrderLineCreate` die Positionen an. Sie erhält die Bestell-ID, die Benutzer-ID, beide Schalter und `PurchaseOrderXML`.\n\nDer Aufruf liefert eine Ergebnismenge mit Statuszeilen (`Status`, `StatusDescription`, `ItemId`), sortiert nach `Status` und `ItemId`.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplierOrderId` | int | Nein | Interne ID der Lieferantenbestellung (`SupplierOrder.Id`). Alternative zu `SupplierOrderNr`. |\n| `SupplierOrderNr` | int | Nein | Interne Nummer der Lieferantenbestellung (`SupplierOrder.InternalNumber`). Alternative zu `SupplierOrderId`. |\n| `UserName` | varchar(50) | Nein | Pixi-Benutzername, unter dem die Positionen angelegt werden. Bei unbekanntem Namen wird `pixiAdministration` verwendet. |\n| `ConsiderPackageUnits` | bit | Nein | Legt fest, ob Verpackungseinheiten beim Anlegen der Positionen berücksichtigt werden. `NULL` wird als `0` behandelt. |\n| `ConsiderMinOrderQty` | bit | Nein | Legt fest, ob die Mindestbestellmenge beim Anlegen der Positionen berücksichtigt wird. `NULL` wird als `0` behandelt. |\n| `PurchaseOrderXML` | xml | Ja | XML-Dokument mit den anzulegenden Positionen. Es wird unverändert an `pixi.SupplierOrderLineCreate` übergeben. Die Struktur ist dort festgelegt und in diesem Code nicht sichtbar, das Beispiel ist daher nur illustrativ. |\n\n- Das eigentliche Anlegen der Positionen erfolgt in `pixi.SupplierOrderLineCreate`, das nicht beigefügt ist. Daher lässt sich hier Folgendes nicht dokumentieren:\n - die erwartete Struktur von `PurchaseOrderXML`\n - wie Verpackungseinheiten und Mindestbestellmengen angewendet werden\n - welche Tabellen geschrieben werden\n - welche Status- und Beschreibungswerte bei Erfolg im Ergebnis erscheinen\n- `pixi.SupplierOrderLineCreate` wird mit `@pipiSupplierOrderLineCreate_ReturnInfo = 1` aufgerufen. Vermutlich schreibt es seine Ergebnisse je Artikel in die temporäre Ergebnistabelle, die dieser Aufruf zurückgibt.\n- Nur einen der Parameter `SupplierOrderId` oder `SupplierOrderNr` übergeben oder sicherstellen, dass beide zur selben Bestellung gehören. Die Suche verwendet `OR`, daher führen zwei verschiedene Treffer zu einem Fehler. Sind beide `NULL`, wird nichts gefunden und *Purchase order does not exist!* zurückgegeben.\n- Die Suche nach der Bestellung verwendet `NOLOCK`.\n- Der Aufruf läuft in einer eigenen Transaktion bzw. in einem Savepoint, falls bereits eine Transaktion offen ist.\n- Bei einem SQL-Fehler wird die Transaktion zurückgerollt und der Fehler über `log.InsertError` protokolliert. Ob der Fehler an den Aufrufer weitergegeben wird, hängt von dieser nicht beigefügten Prozedur ab. In diesem Fall kann die Status-Ergebnismenge fehlen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderLineCreate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Error\n Purchase order is not in status NEW or BES!\n \n"
}
]
},
{
"name": "pixiSupplierOrderLineDelete",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n MyShopConnector\n \n api.user\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht eine oder mehrere Lieferantenbestellpositionen und liefert eine Statuszeile mit SUCCESS, WARNING oder ERROR.\n\nLöscht Lieferantenbestellpositionen anhand ihrer IDs. Das eigentliche Löschen übernimmt die interne Prozedur `pixi.SupplierOrderLineDelete`. Laut Kopfkommentar wird dabei gegebenenfalls auch die Lieferantenbestellung aktualisiert.\n\nAblauf:\n\n1. Eine Transaktion wird geöffnet. Ist bereits eine äußere Transaktion offen, wird stattdessen ein Savepoint gesetzt.\n2. Der Benutzer wird ermittelt. Ohne `UserId` wird die ID über `inf.UserGetByName` aus `UserName` bestimmt. Existiert der Name nicht, wird die ID des Benutzers `pixiAdministration` verwendet.\n3. Die zu löschenden Positionen werden gesammelt:\n - die einzelne ID aus `SupplierOrderLineId` (der Wert `0` wird wie `NULL` behandelt);\n - alle IDs aus der kommagetrennten Liste `SupplierOrderLineIds`. Die Elemente werden getrimmt, leere Elemente ignoriert und Duplikate entfernt.\n \n Beide Parameter lassen sich kombinieren.\n4. `pixi.SupplierOrderLineDelete` wird mit Benutzer-ID, Einzel-ID und ID-Liste aufgerufen.\n5. Es wird geprüft, ob eine der angeforderten IDs noch in `SupplierOrderLine` existiert. In diesem Fall lautet das Ergebnis `WARNING` mit der Meldung `Some Purchase Orderlines items from list were not deleted.`, sonst `SUCCESS`.\n6. Die Transaktion wird bestätigt und eine Statuszeile mit `ReturnCode` und `ErrorMessage` geliefert.\n\nTritt ein Fehler auf, wird die Transaktion zurückgerollt und eine Zeile mit `ReturnCode` = `ERROR` und dem SQL-Fehlertext zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Pflichtparameter, wird von der Prozedur aber nicht verwendet. |\n| `UserId` | int | Nein | ID des Pixi-Benutzers, der das Löschen ausführt. Bei `NULL` wird die ID aus `UserName` ermittelt. |\n| `UserName` | varchar(50) | Ja | Pixi-Benutzername. Dient zur Ermittlung der Benutzer-ID, wenn `UserId` nicht gesetzt ist. Existiert der Name nicht, wird der Benutzer `pixiAdministration` verwendet. |\n| `SupplierOrderLineId` | int | Nein | ID einer einzelnen zu löschenden Lieferantenbestellposition. `0` wird wie `NULL` behandelt. |\n| `SupplierOrderLineIds` | varchar(8000) | Nein | Kommagetrennte Liste der zu löschenden Lieferantenbestellpositions-IDs. Leerzeichen um die Elemente werden entfernt, leere Elemente ignoriert. Alle Elemente müssen Ganzzahlen sein. Kombinierbar mit `SupplierOrderLineId`. |\n\n- Die Definition von `pixi.SupplierOrderLineDelete` liegt nicht vor. Offen bleibt daher:\n - welche Tabellen sie ändert;\n - unter welchen Bedingungen sie das Löschen einer Position verweigert, etwa bei bereits gebuchtem Wareneingang;\n - ob sie den Kopf der Lieferantenbestellung aktualisiert.\n- `WARNING` führt nicht zu einem Rollback. Löschbare Positionen bleiben gelöscht und die Transaktion wird bestätigt.\n- Die Existenzprüfung nach dem Löschen liest `SupplierOrderLine` mit `NOLOCK`.\n- Jedes nicht leere Element von `SupplierOrderLineIds` muss eine Ganzzahl sein. Ein nicht numerisches Element führt zu einem Konvertierungsfehler. Der gesamte Aufruf wird dann zurückgerollt und liefert `ERROR`.\n- `AppName` ist Pflicht, wird von der Prozedur aber nicht verwendet.\n- `UserName` hat keinen Standardwert und muss immer übergeben werden, auch wenn `UserId` gesetzt ist.\n- Läuft die Prozedur innerhalb einer äußeren Transaktion, liefert sie bei Erfolg keine Statuszeile. Das betrifft normale SOAP-Aufrufe nicht.\n- Tritt innerhalb einer äußeren, noch bestätigbaren Transaktion ein Fehler auf, wird der Savepoint nicht zurückgerollt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderLineDelete"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n MyShopConnector\n \n api.user\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht eine oder mehrere Lieferantenbestellpositionen und liefert eine Statuszeile mit SUCCESS, WARNING oder ERROR.\n\nLöscht Lieferantenbestellpositionen anhand ihrer IDs. Das eigentliche Löschen übernimmt die interne Prozedur `pixi.SupplierOrderLineDelete`. Laut Kopfkommentar wird dabei gegebenenfalls auch die Lieferantenbestellung aktualisiert.\n\nAblauf:\n\n1. Eine Transaktion wird geöffnet. Ist bereits eine äußere Transaktion offen, wird stattdessen ein Savepoint gesetzt.\n2. Der Benutzer wird ermittelt. Ohne `UserId` wird die ID über `inf.UserGetByName` aus `UserName` bestimmt. Existiert der Name nicht, wird die ID des Benutzers `pixiAdministration` verwendet.\n3. Die zu löschenden Positionen werden gesammelt:\n - die einzelne ID aus `SupplierOrderLineId` (der Wert `0` wird wie `NULL` behandelt);\n - alle IDs aus der kommagetrennten Liste `SupplierOrderLineIds`. Die Elemente werden getrimmt, leere Elemente ignoriert und Duplikate entfernt.\n \n Beide Parameter lassen sich kombinieren.\n4. `pixi.SupplierOrderLineDelete` wird mit Benutzer-ID, Einzel-ID und ID-Liste aufgerufen.\n5. Es wird geprüft, ob eine der angeforderten IDs noch in `SupplierOrderLine` existiert. In diesem Fall lautet das Ergebnis `WARNING` mit der Meldung `Some Purchase Orderlines items from list were not deleted.`, sonst `SUCCESS`.\n6. Die Transaktion wird bestätigt und eine Statuszeile mit `ReturnCode` und `ErrorMessage` geliefert.\n\nTritt ein Fehler auf, wird die Transaktion zurückgerollt und eine Zeile mit `ReturnCode` = `ERROR` und dem SQL-Fehlertext zurückgegeben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Pflichtparameter, wird von der Prozedur aber nicht verwendet. |\n| `UserId` | int | Nein | ID des Pixi-Benutzers, der das Löschen ausführt. Bei `NULL` wird die ID aus `UserName` ermittelt. |\n| `UserName` | varchar(50) | Ja | Pixi-Benutzername. Dient zur Ermittlung der Benutzer-ID, wenn `UserId` nicht gesetzt ist. Existiert der Name nicht, wird der Benutzer `pixiAdministration` verwendet. |\n| `SupplierOrderLineId` | int | Nein | ID einer einzelnen zu löschenden Lieferantenbestellposition. `0` wird wie `NULL` behandelt. |\n| `SupplierOrderLineIds` | varchar(8000) | Nein | Kommagetrennte Liste der zu löschenden Lieferantenbestellpositions-IDs. Leerzeichen um die Elemente werden entfernt, leere Elemente ignoriert. Alle Elemente müssen Ganzzahlen sein. Kombinierbar mit `SupplierOrderLineId`. |\n\n- Die Definition von `pixi.SupplierOrderLineDelete` liegt nicht vor. Offen bleibt daher:\n - welche Tabellen sie ändert;\n - unter welchen Bedingungen sie das Löschen einer Position verweigert, etwa bei bereits gebuchtem Wareneingang;\n - ob sie den Kopf der Lieferantenbestellung aktualisiert.\n- `WARNING` führt nicht zu einem Rollback. Löschbare Positionen bleiben gelöscht und die Transaktion wird bestätigt.\n- Die Existenzprüfung nach dem Löschen liest `SupplierOrderLine` mit `NOLOCK`.\n- Jedes nicht leere Element von `SupplierOrderLineIds` muss eine Ganzzahl sein. Ein nicht numerisches Element führt zu einem Konvertierungsfehler. Der gesamte Aufruf wird dann zurückgerollt und liefert `ERROR`.\n- `AppName` ist Pflicht, wird von der Prozedur aber nicht verwendet.\n- `UserName` hat keinen Standardwert und muss immer übergeben werden, auch wenn `UserId` gesetzt ist.\n- Läuft die Prozedur innerhalb einer äußeren Transaktion, liefert sie bei Erfolg keine Statuszeile. Das betrifft normale SOAP-Aufrufe nicht.\n- Tritt innerhalb einer äußeren, noch bestätigbaren Transaktion ein Fehler auf, wird der Savepoint nicht zurückgerollt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderLineDelete"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n WARNING\n Some Purchase Orderlines items from list were not deleted.\n \n"
}
]
},
{
"name": "pixiSupplierOrderLineLocQtyCreate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n MyWarehouseTool\n \n jdoe\n 45871\n \n \n 24\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine lagerortbezogene Menge für eine Lieferantenbestellposition an, optional gerundet auf Verpackungseinheiten und Mindestbestellmenge.\n\nFügt einer bestehenden Lieferantenbestellposition eine Menge für einen bestimmten Lagerort hinzu. Das eigentliche Anlegen erledigt die interne Prozedur `pixi.SupplierOrderLineLocQtyCreate`.\n\nAblauf:\n\n1. Öffnet eine Transaktion bzw. setzt einen Savepoint, falls beim Aufruf bereits eine Transaktion offen ist.\n2. Ermittelt den Benutzer: Ist `UserId` leer, wird der Benutzer über `UserName` gesucht. Existiert dieser Name nicht, wird der Benutzer `pixiAdministration` verwendet.\n3. Ermittelt den Lagerort in `dbo.Location`. Wird `LocationId` übergeben, erfolgt der Abgleich mit `LocationKey`. Andernfalls wird `Location` mit dem Lagerortkürzel `LocID` abgeglichen. `LocationId` hat Vorrang vor `Location`.\n4. Prüft, ob für diese Bestellposition und diesen Lagerort bereits eine Menge in `pixi.SupplierOrderLineLocQty` existiert. Falls ja, wird die Meldung `Location already exists for sent location.` vorgemerkt.\n5. Wurde der Lagerort gefunden:\n - `NULL`-Werte bei `ConsiderPackageUnits` und `ConsiderMinOrderQty` werden als `0` behandelt.\n - Die interne Anlage-Prozedur wird mit Bestellposition, Lagerort, Menge und beiden Schaltern aufgerufen. Sie soll die eingefügten IDs zurückliefern.\n6. Wurde der Lagerort nicht gefunden, wird die Meldung `Match value for parameter Location does not exists in db.` vorgemerkt und nichts angelegt.\n7. Ist eine Meldung vorgemerkt, wird eine Zeile mit `ReturnCode` = `ERROR` und `ErrorMessage` geliefert.\n8. Die eigene Transaktion wird festgeschrieben.\n\nBei einem SQL-Fehler wird die Transaktion nach Möglichkeit zurückgerollt und eine `ERROR`-Zeile mit dem SQL-Fehlertext geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Pflicht, wird im Code aber nicht verwendet. |\n| `UserId` | int | Nein | ID des ausführenden Benutzers. Ist der Wert leer, wird der Benutzer über `UserName` ermittelt. |\n| `UserName` | varchar(50) | Ja | Benutzername, der verwendet wird, wenn `UserId` leer ist. Unbekannte Namen führen zu `pixiAdministration`. |\n| `SupplierOrderLineId` | int | Ja | ID der Lieferantenbestellposition, die die Lagerortmenge erhält. |\n| `Location` | varchar(3) | Nein | Lagerortkürzel (`LocID`). Wird nur verwendet, wenn `LocationId` leer ist. |\n| `LocationId` | int | Nein | Lagerortschlüssel (`LocationKey`). Hat Vorrang vor `Location`. |\n| `Qty` | int | Ja | Menge für den Lagerort. |\n| `ConsiderPackageUnits` | bit | Nein | Gibt an, ob die interne Anlage-Prozedur Verpackungseinheiten berücksichtigt. `NULL` wird als `0` behandelt. |\n| `ConsiderMinOrderQty` | bit | Nein | Gibt an, ob die interne Anlage-Prozedur die Mindestbestellmenge berücksichtigt. `NULL` wird als `0` behandelt. |\n\n- **Die Duplikatprüfung verhindert das Anlegen nicht.** Existiert für den Lagerort bereits eine Menge, wird zwar die Fehlermeldung vorgemerkt, die interne Anlage-Prozedur wird aber trotzdem aufgerufen. Der Aufruf liefert dann das Ergebnis der internen Prozedur, gefolgt von einer `ERROR`-Zeile. Ob dabei ein Duplikat entsteht oder abgewiesen wird, hängt von `pixi.SupplierOrderLineLocQtyCreate` ab, deren Definition nicht beiliegt.\n- Das Verhalten der internen Prozedur ist hier nicht sichtbar. Das betrifft die gelieferten IDs, die Anwendung von Verpackungseinheiten und Mindestbestellmenge sowie weitere beschriebene Tabellen.\n- `AppName` ist Pflicht, wird im Code aber nicht verwendet.\n- `UserName` ist auch dann Pflicht, wenn `UserId` übergeben wird.\n- `dbo.Location` und `pixi.SupplierOrderLineLocQty` werden mit `NOLOCK` gelesen.\n- Bei einer äußeren Transaktion und einem nicht fatalen Fehler erfolgt kein Rollback. Bis zum Fehler vorgenommene Änderungen können in der äußeren Transaktion verbleiben.\n- Bei Erfolg gibt es keine explizite Statuszeile. Geliefert wird nur das Ergebnis der internen Prozedur.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderLineLocQtyCreate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n MyWarehouseTool\n \n jdoe\n 45871\n \n \n 24\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Legt eine lagerortbezogene Menge für eine Lieferantenbestellposition an, optional gerundet auf Verpackungseinheiten und Mindestbestellmenge.\n\nFügt einer bestehenden Lieferantenbestellposition eine Menge für einen bestimmten Lagerort hinzu. Das eigentliche Anlegen erledigt die interne Prozedur `pixi.SupplierOrderLineLocQtyCreate`.\n\nAblauf:\n\n1. Öffnet eine Transaktion bzw. setzt einen Savepoint, falls beim Aufruf bereits eine Transaktion offen ist.\n2. Ermittelt den Benutzer: Ist `UserId` leer, wird der Benutzer über `UserName` gesucht. Existiert dieser Name nicht, wird der Benutzer `pixiAdministration` verwendet.\n3. Ermittelt den Lagerort in `dbo.Location`. Wird `LocationId` übergeben, erfolgt der Abgleich mit `LocationKey`. Andernfalls wird `Location` mit dem Lagerortkürzel `LocID` abgeglichen. `LocationId` hat Vorrang vor `Location`.\n4. Prüft, ob für diese Bestellposition und diesen Lagerort bereits eine Menge in `pixi.SupplierOrderLineLocQty` existiert. Falls ja, wird die Meldung `Location already exists for sent location.` vorgemerkt.\n5. Wurde der Lagerort gefunden:\n - `NULL`-Werte bei `ConsiderPackageUnits` und `ConsiderMinOrderQty` werden als `0` behandelt.\n - Die interne Anlage-Prozedur wird mit Bestellposition, Lagerort, Menge und beiden Schaltern aufgerufen. Sie soll die eingefügten IDs zurückliefern.\n6. Wurde der Lagerort nicht gefunden, wird die Meldung `Match value for parameter Location does not exists in db.` vorgemerkt und nichts angelegt.\n7. Ist eine Meldung vorgemerkt, wird eine Zeile mit `ReturnCode` = `ERROR` und `ErrorMessage` geliefert.\n8. Die eigene Transaktion wird festgeschrieben.\n\nBei einem SQL-Fehler wird die Transaktion nach Möglichkeit zurückgerollt und eine `ERROR`-Zeile mit dem SQL-Fehlertext geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Pflicht, wird im Code aber nicht verwendet. |\n| `UserId` | int | Nein | ID des ausführenden Benutzers. Ist der Wert leer, wird der Benutzer über `UserName` ermittelt. |\n| `UserName` | varchar(50) | Ja | Benutzername, der verwendet wird, wenn `UserId` leer ist. Unbekannte Namen führen zu `pixiAdministration`. |\n| `SupplierOrderLineId` | int | Ja | ID der Lieferantenbestellposition, die die Lagerortmenge erhält. |\n| `Location` | varchar(3) | Nein | Lagerortkürzel (`LocID`). Wird nur verwendet, wenn `LocationId` leer ist. |\n| `LocationId` | int | Nein | Lagerortschlüssel (`LocationKey`). Hat Vorrang vor `Location`. |\n| `Qty` | int | Ja | Menge für den Lagerort. |\n| `ConsiderPackageUnits` | bit | Nein | Gibt an, ob die interne Anlage-Prozedur Verpackungseinheiten berücksichtigt. `NULL` wird als `0` behandelt. |\n| `ConsiderMinOrderQty` | bit | Nein | Gibt an, ob die interne Anlage-Prozedur die Mindestbestellmenge berücksichtigt. `NULL` wird als `0` behandelt. |\n\n- **Die Duplikatprüfung verhindert das Anlegen nicht.** Existiert für den Lagerort bereits eine Menge, wird zwar die Fehlermeldung vorgemerkt, die interne Anlage-Prozedur wird aber trotzdem aufgerufen. Der Aufruf liefert dann das Ergebnis der internen Prozedur, gefolgt von einer `ERROR`-Zeile. Ob dabei ein Duplikat entsteht oder abgewiesen wird, hängt von `pixi.SupplierOrderLineLocQtyCreate` ab, deren Definition nicht beiliegt.\n- Das Verhalten der internen Prozedur ist hier nicht sichtbar. Das betrifft die gelieferten IDs, die Anwendung von Verpackungseinheiten und Mindestbestellmenge sowie weitere beschriebene Tabellen.\n- `AppName` ist Pflicht, wird im Code aber nicht verwendet.\n- `UserName` ist auch dann Pflicht, wenn `UserId` übergeben wird.\n- `dbo.Location` und `pixi.SupplierOrderLineLocQty` werden mit `NOLOCK` gelesen.\n- Bei einer äußeren Transaktion und einem nicht fatalen Fehler erfolgt kein Rollback. Bis zum Fehler vorgenommene Änderungen können in der äußeren Transaktion verbleiben.\n- Bei Erfolg gibt es keine explizite Statuszeile. Geliefert wird nur das Ergebnis der internen Prozedur.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderLineLocQtyCreate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n ERROR\n Match value for parameter Location does not exists in db. \n \n"
}
]
},
{
"name": "pixiSupplierOrderLineLocQtyDelete",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n MyShopConnector\n \n jdoe\n 45871\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht einen Lagerplatz-Mengeneintrag einer Lieferantenbestellposition und liefert eine Statuszeile mit ReturnCode und ErrorMessage.\n\nEntfernt einen Lagerplatz-Mengeneintrag (`SupplierOrderLineLocQty`) einer Lieferantenbestellposition (Bestellung beim Lieferanten). Die Lieferantenbestellung wird durch die interne Prozedur entsprechend aktualisiert.\n\nAblauf:\n1. Eröffnet eine eigene Transaktion oder setzt einen Savepoint, falls bereits eine Transaktion offen ist.\n2. Ermittelt den Benutzer: Ist `UserId` leer, wird die Benutzer-ID über `UserName` gesucht. Existiert dieser Name nicht, wird der Benutzer `pixiAdministration` verwendet.\n3. `NULL` in `ConsiderPackageUnits` und `ConsiderMinOrderQty` wird als `0` behandelt.\n4. Ruft die interne Prozedur `pixi.SupplierOrderLineLocQtyDelete` mit Benutzer, Datensatz-ID und beiden Schaltern auf. Diese Prozedur führt das eigentliche Löschen aus.\n5. Prüft, ob der Datensatz mit `SupplierOrderLineLocQtyId` noch existiert. Ist das der Fall, lautet das Ergebnis `WARNING` mit einer Meldung.\n6. Schreibt die Transaktion fest und liefert eine Zeile mit `ReturnCode` (`SUCCESS` oder `WARNING`) und `ErrorMessage`.\n\nBei einem Fehler wird die Transaktion bzw. der Savepoint zurückgerollt. Zurückgegeben wird eine Zeile mit `ReturnCode` = `ERROR` und dem SQL-Fehlertext.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Pflichtangabe, wird im Code aber nicht verwendet. |\n| `UserId` | int | Nein | ID des ausführenden Benutzers. Ist der Wert leer, wird der Benutzer über `UserName` ermittelt. |\n| `UserName` | varchar(50) | Ja | Benutzername, wird nur verwendet, wenn `UserId` leer ist. Unbekannte Namen führen zum Benutzer `pixiAdministration`. |\n| `SupplierOrderLineLocQtyId` | int | Ja | ID des zu löschenden Lagerplatz-Mengeneintrags der Lieferantenbestellposition (`pixi.SupplierOrderLineLocQty.Id`). |\n| `ConsiderPackageUnits` | bit | Nein | Legt fest, ob Verpackungseinheiten bei der Aktualisierung der Lieferantenbestellung berücksichtigt werden. `NULL` wird als `0` behandelt. |\n| `ConsiderMinOrderQty` | bit | Nein | Legt fest, ob Mindestbestellmengen bei der Aktualisierung der Lieferantenbestellung berücksichtigt werden. `NULL` wird als `0` behandelt. |\n\n- Die Löschlogik ist in `pixi.SupplierOrderLineLocQtyDelete` enthalten. Dazu gehören die Berücksichtigung von Verpackungseinheiten und Mindestbestellmengen sowie die Aktualisierung der Lieferantenbestellung. Diese Prozedur liegt nicht vor; ihr genaues Verhalten und die von ihr geänderten Tabellen sind daher hier nicht dokumentiert.\n- `AppName` ist ein Pflichtparameter, wird im Code aber nicht verwendet.\n- Die Existenzprüfung nach dem Löschen liest `pixi.SupplierOrderLineLocQty` mit `NOLOCK`.\n- Bei Erfolg oder Warnung wird die Statuszeile nur geliefert, wenn der Aufruf eine eigene Transaktion eröffnet hat. Innerhalb einer äußeren Transaktion gibt es bei Erfolg keine Zeile. Fehlerzeilen werden immer geliefert.\n- Ein `WARNING` führt zu keinem Rollback. Änderungen der internen Prozedur werden festgeschrieben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderLineLocQtyDelete"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n MyShopConnector\n \n jdoe\n 45871\n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Löscht einen Lagerplatz-Mengeneintrag einer Lieferantenbestellposition und liefert eine Statuszeile mit ReturnCode und ErrorMessage.\n\nEntfernt einen Lagerplatz-Mengeneintrag (`SupplierOrderLineLocQty`) einer Lieferantenbestellposition (Bestellung beim Lieferanten). Die Lieferantenbestellung wird durch die interne Prozedur entsprechend aktualisiert.\n\nAblauf:\n1. Eröffnet eine eigene Transaktion oder setzt einen Savepoint, falls bereits eine Transaktion offen ist.\n2. Ermittelt den Benutzer: Ist `UserId` leer, wird die Benutzer-ID über `UserName` gesucht. Existiert dieser Name nicht, wird der Benutzer `pixiAdministration` verwendet.\n3. `NULL` in `ConsiderPackageUnits` und `ConsiderMinOrderQty` wird als `0` behandelt.\n4. Ruft die interne Prozedur `pixi.SupplierOrderLineLocQtyDelete` mit Benutzer, Datensatz-ID und beiden Schaltern auf. Diese Prozedur führt das eigentliche Löschen aus.\n5. Prüft, ob der Datensatz mit `SupplierOrderLineLocQtyId` noch existiert. Ist das der Fall, lautet das Ergebnis `WARNING` mit einer Meldung.\n6. Schreibt die Transaktion fest und liefert eine Zeile mit `ReturnCode` (`SUCCESS` oder `WARNING`) und `ErrorMessage`.\n\nBei einem Fehler wird die Transaktion bzw. der Savepoint zurückgerollt. Zurückgegeben wird eine Zeile mit `ReturnCode` = `ERROR` und dem SQL-Fehlertext.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Pflichtangabe, wird im Code aber nicht verwendet. |\n| `UserId` | int | Nein | ID des ausführenden Benutzers. Ist der Wert leer, wird der Benutzer über `UserName` ermittelt. |\n| `UserName` | varchar(50) | Ja | Benutzername, wird nur verwendet, wenn `UserId` leer ist. Unbekannte Namen führen zum Benutzer `pixiAdministration`. |\n| `SupplierOrderLineLocQtyId` | int | Ja | ID des zu löschenden Lagerplatz-Mengeneintrags der Lieferantenbestellposition (`pixi.SupplierOrderLineLocQty.Id`). |\n| `ConsiderPackageUnits` | bit | Nein | Legt fest, ob Verpackungseinheiten bei der Aktualisierung der Lieferantenbestellung berücksichtigt werden. `NULL` wird als `0` behandelt. |\n| `ConsiderMinOrderQty` | bit | Nein | Legt fest, ob Mindestbestellmengen bei der Aktualisierung der Lieferantenbestellung berücksichtigt werden. `NULL` wird als `0` behandelt. |\n\n- Die Löschlogik ist in `pixi.SupplierOrderLineLocQtyDelete` enthalten. Dazu gehören die Berücksichtigung von Verpackungseinheiten und Mindestbestellmengen sowie die Aktualisierung der Lieferantenbestellung. Diese Prozedur liegt nicht vor; ihr genaues Verhalten und die von ihr geänderten Tabellen sind daher hier nicht dokumentiert.\n- `AppName` ist ein Pflichtparameter, wird im Code aber nicht verwendet.\n- Die Existenzprüfung nach dem Löschen liest `pixi.SupplierOrderLineLocQty` mit `NOLOCK`.\n- Bei Erfolg oder Warnung wird die Statuszeile nur geliefert, wenn der Aufruf eine eigene Transaktion eröffnet hat. Innerhalb einer äußeren Transaktion gibt es bei Erfolg keine Zeile. Fehlerzeilen werden immer geliefert.\n- Ein `WARNING` führt zu keinem Rollback. Änderungen der internen Prozedur werden festgeschrieben.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderLineLocQtyDelete"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n SUCCESS\n \n"
}
]
},
{
"name": "pixiSupplierOrderLineLocQtyGet",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n MyShopConnector\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Liefert Lagerplatz-Mengendaten zu einer oder mehreren Lieferantenbestellungen, Bestellpositionen oder Positions-Lagerplatzmengen.\n\nWrapper um die interne Prozedur `pixi.SupplierOrderLineLocQtyGet`. Sie liefert Lagerplatz-Mengendaten (Mengen je Lagerplatz) zu Positionen von Lieferantenbestellungen.\n\nAblauf:\n\n1. Öffnet eine eigene Transaktion bzw. setzt einen Savepoint, wenn bereits eine äußere Transaktion offen ist.\n2. Ruft `pixi.SupplierOrderLineLocQtyGet` auf. Die Parameter werden so übergeben:\n - `SupplierOrderIds` → `@SoIds`\n - `SupplierOrderLinesIds` → `@SolIds`\n - `SupplierOrderLinesLocQtyIds` → `@SolLocQtyIds`\n3. Gibt die Ergebnismengen dieser Prozedur unverändert zurück und schließt anschließend die eigene Transaktion ab.\n\nBei einem Fehler wird die Transaktion bzw. der Savepoint zurückgerollt und eine einzelne Zeile mit `ReturnCode` = `ERROR` und dem SQL-Fehlertext in `ErrorMessage` zurückgegeben.\n\n`AppName` ist ein Pflichtparameter, wird im Code aber nicht verwendet.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Pflichtparameter, wird im Code nicht verwendet. |\n| `SupplierOrderIds` | varchar(8000) | Nein | Liste von Lieferantenbestellungs-IDs, wird als `@SoIds` an `pixi.SupplierOrderLineLocQtyGet` übergeben. Das Listenformat legt diese Prozedur fest, deren Code nicht vorliegt. |\n| `SupplierOrderLinesIds` | varchar(8000) | Nein | Liste von Bestellpositions-IDs, wird als `@SolIds` an die innere Prozedur übergeben. |\n| `SupplierOrderLinesLocQtyIds` | varchar(8000) | Nein | Liste von IDs der Positions-Lagerplatzmengen, wird als `@SolLocQtyIds` an die innere Prozedur übergeben. |\n\n- Die Definition von `pixi.SupplierOrderLineLocQtyGet` liegt nicht vor. Folgende Punkte lassen sich daher nicht aus dem Code ableiten:\n - das Format der ID-Listen (vermutlich kommagetrennte Schlüssel, nicht bestätigt);\n - wie die drei Filter kombiniert werden;\n - was bei durchgehend leeren Filtern geschieht;\n - Spalten, Sortierung und Anzahl der zurückgegebenen Ergebnismengen.\n- Der Aufruf läuft in einer Transaktion (bzw. einem Savepoint), obwohl es ein Lesezugriff ist; die eigentlichen Lesezugriffe erfolgen in der inneren Prozedur.\n- Schlägt die innere Prozedur fehl, nachdem sie bereits Zeilen geliefert hat, kann der Aufrufer diese Zeilen und danach die Fehlerzeile erhalten.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderLineLocQtyGet"
},
"response": []
},
{
"name": "pixiSupplierOrderLineLocQtyUpdate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n MyWarehouseTool\n \n jdoe\n 4711\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert die Menge und/oder offene Menge eines Lagerort-Mengendatensatzes einer Lieferantenbestellposition.\n\nAktualisiert einen einzelnen Lagerort-Mengendatensatz einer Lieferantenbestellposition, identifiziert über `SupplierOrderLineLocQtyId`. Die eigentliche Aktualisierung übernimmt die interne Prozedur `pixi.SupplierOrderLineLocQtyUpdate`. Dieser Wrapper geht so vor:\n\n1. Öffnet eine Transaktion. Besteht beim Aufrufer bereits eine offene Transaktion, wird stattdessen ein Savepoint gesetzt.\n2. Ermittelt den Benutzer. Ist `UserId` angegeben, wird diese unverändert verwendet. Andernfalls wird der Benutzer über `UserName` in `UCS_USERS` gesucht. Existiert kein Benutzer mit diesem Namen, wird der Benutzer `pixiAdministration` verwendet.\n3. Normalisiert die Parameter:\n - `ConsiderPackageUnits` und `ConsiderMinOrderQty` werden bei `NULL` zu `0`.\n - `Qty` und `UndeliveredQty` werden bei `NULL` oder `0` zu `NULL`.\n4. Ruft `pixi.SupplierOrderLineLocQtyUpdate` mit diesen Werten auf. Dabei wird immer `ReturnUpdatedIds = 1` übergeben, die interne Prozedur soll also die aktualisierten IDs zurückgeben.\n5. Bestätigt die Transaktion, sofern sie von diesem Aufruf geöffnet wurde.\n\nBei einem Fehler wird die Transaktion bzw. der Savepoint zurückgerollt. Der Aufruf liefert dann eine Zeile mit `ReturnCode = 'ERROR'` und der SQL-Fehlermeldung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Pflichtfeld, wird im Code aber nicht verwendet. |\n| `UserId` | int | Nein | ID des ausführenden Benutzers. Fehlt sie, wird der Benutzer über `UserName` ermittelt. |\n| `UserName` | varchar(50) | Ja | Benutzername, über den der Benutzer ermittelt wird, wenn `UserId` fehlt. Wird der Name nicht gefunden, wird `pixiAdministration` verwendet. |\n| `SupplierOrderLineLocQtyId` | int | Ja | ID des zu aktualisierenden Lagerort-Mengendatensatzes der Lieferantenbestellposition. |\n| `ConsiderPackageUnits` | bit | Nein | Ob Verpackungseinheiten berücksichtigt werden. `NULL` wird als `0` behandelt. |\n| `ConsiderMinOrderQty` | bit | Nein | Ob die Mindestbestellmenge berücksichtigt wird. `NULL` wird als `0` behandelt. |\n| `Qty` | int | Nein | Neue Bestellmenge. `0` wird wie `NULL` (nicht angegeben) behandelt. |\n| `UndeliveredQty` | int | Nein | Neue offene (nicht gelieferte) Menge. `0` wird wie `NULL` (nicht angegeben) behandelt. |\n\n- **Interne Prozedur nicht beigefügt:** Die Definition von `pixi.SupplierOrderLineLocQtyUpdate` liegt nicht vor. Daher ist offen:\n - welche Tabellen sie ändert,\n - welche Prüfungen sie durchführt,\n - welche Spalten ihre Ergebnismenge im Erfolgsfall hat,\n - wie sie `NULL` für `Qty` oder `UndeliveredQty` behandelt (vermutlich \"unverändert lassen\").\n- **Wert `0` nicht setzbar:** Wegen der Prüfung `ISNULL(@Qty, '') = ''` wird der Wert `0` wie \"nicht angegeben\" behandelt und als `NULL` weitergegeben. Dasselbe gilt für `UndeliveredQty`. Eine Menge lässt sich über diesen Aufruf also nicht auf `0` setzen.\n- **Ungenutzter Parameter:** `AppName` ist Pflicht, wird im Code aber nicht verwendet.\n- **Rollback im Fehlerfall:** Wird die Transaktion durch einen Fehler nicht mehr festschreibbar, rollt der Code auf den Savepoint zurück. SQL Server erlaubt das bei nicht festschreibbaren Transaktionen nicht und kann einen weiteren Fehler auslösen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderLineLocQtyUpdate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n MyWarehouseTool\n \n jdoe\n 4711\n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert die Menge und/oder offene Menge eines Lagerort-Mengendatensatzes einer Lieferantenbestellposition.\n\nAktualisiert einen einzelnen Lagerort-Mengendatensatz einer Lieferantenbestellposition, identifiziert über `SupplierOrderLineLocQtyId`. Die eigentliche Aktualisierung übernimmt die interne Prozedur `pixi.SupplierOrderLineLocQtyUpdate`. Dieser Wrapper geht so vor:\n\n1. Öffnet eine Transaktion. Besteht beim Aufrufer bereits eine offene Transaktion, wird stattdessen ein Savepoint gesetzt.\n2. Ermittelt den Benutzer. Ist `UserId` angegeben, wird diese unverändert verwendet. Andernfalls wird der Benutzer über `UserName` in `UCS_USERS` gesucht. Existiert kein Benutzer mit diesem Namen, wird der Benutzer `pixiAdministration` verwendet.\n3. Normalisiert die Parameter:\n - `ConsiderPackageUnits` und `ConsiderMinOrderQty` werden bei `NULL` zu `0`.\n - `Qty` und `UndeliveredQty` werden bei `NULL` oder `0` zu `NULL`.\n4. Ruft `pixi.SupplierOrderLineLocQtyUpdate` mit diesen Werten auf. Dabei wird immer `ReturnUpdatedIds = 1` übergeben, die interne Prozedur soll also die aktualisierten IDs zurückgeben.\n5. Bestätigt die Transaktion, sofern sie von diesem Aufruf geöffnet wurde.\n\nBei einem Fehler wird die Transaktion bzw. der Savepoint zurückgerollt. Der Aufruf liefert dann eine Zeile mit `ReturnCode = 'ERROR'` und der SQL-Fehlermeldung.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Pflichtfeld, wird im Code aber nicht verwendet. |\n| `UserId` | int | Nein | ID des ausführenden Benutzers. Fehlt sie, wird der Benutzer über `UserName` ermittelt. |\n| `UserName` | varchar(50) | Ja | Benutzername, über den der Benutzer ermittelt wird, wenn `UserId` fehlt. Wird der Name nicht gefunden, wird `pixiAdministration` verwendet. |\n| `SupplierOrderLineLocQtyId` | int | Ja | ID des zu aktualisierenden Lagerort-Mengendatensatzes der Lieferantenbestellposition. |\n| `ConsiderPackageUnits` | bit | Nein | Ob Verpackungseinheiten berücksichtigt werden. `NULL` wird als `0` behandelt. |\n| `ConsiderMinOrderQty` | bit | Nein | Ob die Mindestbestellmenge berücksichtigt wird. `NULL` wird als `0` behandelt. |\n| `Qty` | int | Nein | Neue Bestellmenge. `0` wird wie `NULL` (nicht angegeben) behandelt. |\n| `UndeliveredQty` | int | Nein | Neue offene (nicht gelieferte) Menge. `0` wird wie `NULL` (nicht angegeben) behandelt. |\n\n- **Interne Prozedur nicht beigefügt:** Die Definition von `pixi.SupplierOrderLineLocQtyUpdate` liegt nicht vor. Daher ist offen:\n - welche Tabellen sie ändert,\n - welche Prüfungen sie durchführt,\n - welche Spalten ihre Ergebnismenge im Erfolgsfall hat,\n - wie sie `NULL` für `Qty` oder `UndeliveredQty` behandelt (vermutlich \"unverändert lassen\").\n- **Wert `0` nicht setzbar:** Wegen der Prüfung `ISNULL(@Qty, '') = ''` wird der Wert `0` wie \"nicht angegeben\" behandelt und als `NULL` weitergegeben. Dasselbe gilt für `UndeliveredQty`. Eine Menge lässt sich über diesen Aufruf also nicht auf `0` setzen.\n- **Ungenutzter Parameter:** `AppName` ist Pflicht, wird im Code aber nicht verwendet.\n- **Rollback im Fehlerfall:** Wird die Transaktion durch einen Fehler nicht mehr festschreibbar, rollt der Code auf den Savepoint zurück. SQL Server erlaubt das bei nicht festschreibbaren Transaktionen nicht und kann einen weiteren Fehler auslösen.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderLineLocQtyUpdate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n ERROR\n Supplier order line location quantity not found.\n \n"
}
]
},
{
"name": "pixiSupplierOrderLineUpdate",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n MyShopConnector\n \n jdoe\n 45871\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Lieferantenpreis, voraussichtliches Lieferdatum und Kommentar einer Lieferantenbestellposition.\n\nAktualisiert eine einzelne Lieferantenbestellposition, die über `SupplierOrderLineId` bestimmt wird. Die eigentliche Änderung erfolgt in der internen Prozedur `pixi.SupplierOrderLineUpdate`, die mit `ReturnUpdatedIds = 1` aufgerufen wird.\n\nAblauf:\n\n1. Startet eine Transaktion oder setzt einen Savepoint, falls beim Aufruf bereits eine Transaktion offen ist.\n2. Ermittelt den Benutzer: Ist `UserId` angegeben, wird dieser Wert direkt verwendet; andernfalls wird der Benutzer über `UserName` mit `inf.UserGetByName` gesucht. Existiert der Benutzername nicht, wird der Benutzer `pixiAdministration` verwendet.\n3. Normalisiert die Eingabewerte:\n - `SupplierPrice`: Ein Wert, der einem Leerstring entspricht, wird zu `NULL`.\n - `EstimatedDeliveryDate`: Der Zeitanteil wird entfernt, nur das Datum wird weitergegeben.\n - `Comment`: Ein Leerstring wird zu `NULL`.\n4. Ruft `pixi.SupplierOrderLineUpdate` mit Benutzer, Positions-ID und den drei Werten auf.\n5. Bestätigt die selbst gestartete Transaktion.\n\nBei einem Fehler wird die Transaktion bzw. der Savepoint zurückgerollt und eine Zeile mit `ReturnCode` = `ERROR` und der SQL-Fehlermeldung geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Pflicht, wird im Code aber nicht verwendet. |\n| `UserId` | int | Nein | ID des Pixi-Benutzers, der die Änderung durchführt. Fehlt der Wert, wird der Benutzer über `UserName` ermittelt. |\n| `UserName` | varchar(50) | Ja | Pixi-Benutzername. Wird nur verwendet, wenn `UserId` fehlt; unbekannte Namen führen zum Benutzer `pixiAdministration`. |\n| `SupplierOrderLineId` | int | Ja | ID der zu aktualisierenden Lieferantenbestellposition. |\n| `SupplierPrice` | money | Nein | Neuer Lieferanten-(Einkaufs-)preis der Position. Der Wert `0` wird zu `NULL` umgewandelt. |\n| `EstimatedDeliveryDate` | datetime | Nein | Neues voraussichtliches Lieferdatum. Der Zeitanteil wird entfernt. |\n| `Comment` | nvarchar(2000) | Nein | Neuer Kommentar zur Position. Ein Leerstring wird zu `NULL` umgewandelt. |\n\n- Die interne Prozedur `pixi.SupplierOrderLineUpdate` liegt nicht vor. Welche Tabellen sie ändert, wie `NULL`-Werte behandelt werden (z. B. ob `NULL` \"unverändert lassen\" bedeutet) und die genauen Spalten der Erfolgs-Ergebnismenge (angefordert über `ReturnUpdatedIds = 1`) lassen sich aus diesem Code nicht ableiten.\n- Stolperfalle: `SupplierPrice` ist ein `money`-Wert, der mit einem Leerstring verglichen wird; SQL Server wandelt den Leerstring in `0` um. Ein Preis von `0` wird daher zu `NULL` und kann nicht explizit gesetzt werden.\n- Ebenso wird ein leerer `Comment` zu `NULL`; ein Kommentar lässt sich mit einem Leerstring daher möglicherweise nicht löschen.\n- `EstimatedDeliveryDate` wird auf das Datum gekürzt; ein Zeitanteil geht verloren.\n- `AppName` ist Pflicht, wird im Code aber nicht verwendet. `UserName` ist Pflicht, wird aber nur ausgewertet, wenn `UserId` nicht angegeben ist.\n- Verwendet eine benannte Transaktion bzw. einen Savepoint und kann daher innerhalb einer äußeren Transaktion laufen; im Fehlerfall wird nur die eigene Arbeit zurückgerollt (sofern die Transaktion nicht unbrauchbar ist).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderLineUpdate"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n MyShopConnector\n \n jdoe\n 45871\n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Lieferantenpreis, voraussichtliches Lieferdatum und Kommentar einer Lieferantenbestellposition.\n\nAktualisiert eine einzelne Lieferantenbestellposition, die über `SupplierOrderLineId` bestimmt wird. Die eigentliche Änderung erfolgt in der internen Prozedur `pixi.SupplierOrderLineUpdate`, die mit `ReturnUpdatedIds = 1` aufgerufen wird.\n\nAblauf:\n\n1. Startet eine Transaktion oder setzt einen Savepoint, falls beim Aufruf bereits eine Transaktion offen ist.\n2. Ermittelt den Benutzer: Ist `UserId` angegeben, wird dieser Wert direkt verwendet; andernfalls wird der Benutzer über `UserName` mit `inf.UserGetByName` gesucht. Existiert der Benutzername nicht, wird der Benutzer `pixiAdministration` verwendet.\n3. Normalisiert die Eingabewerte:\n - `SupplierPrice`: Ein Wert, der einem Leerstring entspricht, wird zu `NULL`.\n - `EstimatedDeliveryDate`: Der Zeitanteil wird entfernt, nur das Datum wird weitergegeben.\n - `Comment`: Ein Leerstring wird zu `NULL`.\n4. Ruft `pixi.SupplierOrderLineUpdate` mit Benutzer, Positions-ID und den drei Werten auf.\n5. Bestätigt die selbst gestartete Transaktion.\n\nBei einem Fehler wird die Transaktion bzw. der Savepoint zurückgerollt und eine Zeile mit `ReturnCode` = `ERROR` und der SQL-Fehlermeldung geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Ja | Name der aufrufenden Anwendung. Pflicht, wird im Code aber nicht verwendet. |\n| `UserId` | int | Nein | ID des Pixi-Benutzers, der die Änderung durchführt. Fehlt der Wert, wird der Benutzer über `UserName` ermittelt. |\n| `UserName` | varchar(50) | Ja | Pixi-Benutzername. Wird nur verwendet, wenn `UserId` fehlt; unbekannte Namen führen zum Benutzer `pixiAdministration`. |\n| `SupplierOrderLineId` | int | Ja | ID der zu aktualisierenden Lieferantenbestellposition. |\n| `SupplierPrice` | money | Nein | Neuer Lieferanten-(Einkaufs-)preis der Position. Der Wert `0` wird zu `NULL` umgewandelt. |\n| `EstimatedDeliveryDate` | datetime | Nein | Neues voraussichtliches Lieferdatum. Der Zeitanteil wird entfernt. |\n| `Comment` | nvarchar(2000) | Nein | Neuer Kommentar zur Position. Ein Leerstring wird zu `NULL` umgewandelt. |\n\n- Die interne Prozedur `pixi.SupplierOrderLineUpdate` liegt nicht vor. Welche Tabellen sie ändert, wie `NULL`-Werte behandelt werden (z. B. ob `NULL` \"unverändert lassen\" bedeutet) und die genauen Spalten der Erfolgs-Ergebnismenge (angefordert über `ReturnUpdatedIds = 1`) lassen sich aus diesem Code nicht ableiten.\n- Stolperfalle: `SupplierPrice` ist ein `money`-Wert, der mit einem Leerstring verglichen wird; SQL Server wandelt den Leerstring in `0` um. Ein Preis von `0` wird daher zu `NULL` und kann nicht explizit gesetzt werden.\n- Ebenso wird ein leerer `Comment` zu `NULL`; ein Kommentar lässt sich mit einem Leerstring daher möglicherweise nicht löschen.\n- `EstimatedDeliveryDate` wird auf das Datum gekürzt; ein Zeitanteil geht verloren.\n- `AppName` ist Pflicht, wird im Code aber nicht verwendet. `UserName` ist Pflicht, wird aber nur ausgewertet, wenn `UserId` nicht angegeben ist.\n- Verwendet eine benannte Transaktion bzw. einen Savepoint und kann daher innerhalb einer äußeren Transaktion laufen; im Fehlerfall wird nur die eigene Arbeit zurückgerollt (sofern die Transaktion nicht unbrauchbar ist).\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiSupplierOrderLineUpdate"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n ERROR\n Supplier order line 45871 not found.\n \n"
}
]
},
{
"name": "pixiUpdateDelivery",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert den Kopf einer Lieferantenlieferung (Notiz, externe Nummern, Status, Picco-/Mobix-Sperre) per Liefer-ID oder Liefernummer.\n\nAktualisiert einen Datensatz in `SDelHeader` (Kopf einer Lieferantenlieferung) und liefert immer genau eine Zeile mit der Spalte `ReturnMSG`.\n\n**Ermittlung der Lieferung**\n- `SDelHkey` und `DeliveryNumber` gelten bei `0` als nicht angegeben. Mindestens einer der Werte ist erforderlich.\n- Ist `SDelHkey` angegeben, wird dieser verwendet und `DeliveryNumber` ignoriert.\n- Andernfalls wird die Lieferung mit `SDelHNr = DeliveryNumber` und dem kleinsten Schlüssel verwendet.\n\n**Prüfungen**\n- `Status` muss `NEW`, `INV` oder `CLS` sein oder weggelassen werden (`NULL`); dann bleibt der aktuelle Status erhalten. Ein Leerstring wird abgelehnt.\n- Ist `ExternalReceiptNr` angegeben, darf keine andere Lieferung desselben Lieferanten diese externe Belegnummer bereits besitzen.\n- Ohne `PiccoUser`: Die Lieferung muss existieren und darf nicht durch Picco gesperrt sein (`LockedByPicco` ungleich `Y`).\n- Mit `PiccoUser` (Mobix-/Picco-Client): Die Lieferung muss existieren und entweder diesem `PiccoUser` zugeordnet oder nicht durch Picco gesperrt sein.\n\n**Behandlung der Felder**\n- `Note`, `extInvoiceNr` und `extOrderNr` werden getrimmt. Leere oder fehlende Werte behalten den gespeicherten Wert.\n- `ExternalReceiptNr` und `Status`: Fehlende oder leere Werte behalten den gespeicherten Wert.\n- `UserName` ist standardmäßig `API` und wird als letzter Bearbeiter gespeichert; das Änderungsdatum wird auf die aktuelle Zeit gesetzt.\n- Die Picco-Informationen werden immer neu geschrieben:\n - Ohne `PiccoUser` werden `PiccoUser` und `LockedByPicco` der Lieferung geleert.\n - Mit `PiccoUser` wird der Benutzer gespeichert; `LockedByPicco` wird auf `Y` gesetzt, wenn `LockDelivery = 1`. Bei `Status = CLS` werden Picco-Benutzer und Sperre entfernt.\n- `SupplNr` ist veraltet. Der Lieferant wird nie geändert.\n\nÄndert sich der Status tatsächlich, wird ein Ereignis „Lieferstatus geändert“ veröffentlicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHkey` | int | Nein | Interner Schlüssel der Lieferung (`SDelHKey`). `0` gilt als nicht angegeben. Hat Vorrang vor `DeliveryNumber`. |\n| `SupplNr` | varchar(4) | Nein | Veraltet. Wird ignoriert; der Lieferant wird aus dem Lieferkopf gelesen und nie geändert. |\n| `DeliveryNumber` | int | Nein | Liefernummer (`SDelHNr`). Wird nur verwendet, wenn `SDelHkey` fehlt; `0` gilt als nicht angegeben. |\n| `Note` | varchar(8000) | Nein | Neue Notiz der Lieferung. Wird getrimmt; leer oder fehlend behält die gespeicherte Notiz. |\n| `extInvoiceNr` | varchar(25) | Nein | Externe Rechnungsnummer des Lieferanten. Wird getrimmt; leer oder fehlend behält den gespeicherten Wert. |\n| `extOrderNr` | varchar(8000) | Nein | Externe Bestellnummer(n). Wird getrimmt; leer oder fehlend behält den gespeicherten Wert. Effektiv auf 1000 Zeichen begrenzt. |\n| `UserName` | varchar(50) | Nein | Als letzter Bearbeiter gespeicherter Benutzer. Standard ist `API`. |\n| `PiccoUser` | varchar(59) | Nein | Picco-/Mobix-Benutzer, der die Lieferung bearbeitet. Leer gilt als nicht angegeben. Fehlt der Wert, werden Picco-Zuordnung und Sperre entfernt. |\n| `Status` | varchar(3) | Nein | Neuer Lieferstatus. Fehlend behält den aktuellen Status; ein Leerstring wird abgelehnt. |\n| `LockDelivery` | bit | Nein | Nur mit `PiccoUser`: `1` sperrt die Lieferung für diesen Picco-Benutzer (`LockedByPicco = Y`), sofern `Status` nicht `CLS` ist. |\n| `ExternalReceiptNr` | varchar(50) | Nein | Externe Belegnummer. Muss je Lieferant eindeutig sein; leer oder fehlend behält den gespeicherten Wert. |\n\n- `Note`, `extInvoiceNr`, `extOrderNr` und `ExternalReceiptNr` lassen sich mit diesem Aufruf nicht leeren. Leere Werte behalten den bestehenden Inhalt.\n- `extOrderNr` ist als `varchar(8000)` deklariert, die interne Update-Prozedur nimmt aber nur `varchar(1000)` an. Längere Werte werden abgeschnitten.\n- Ein Aufruf ohne `PiccoUser` entfernt eine bestehende Picco-Benutzerzuordnung der Lieferung.\n- Bei einer durch Picco gesperrten Lieferung schlägt ein Aufruf ohne `PiccoUser` mit `Delivery header does not exist` fehl, obwohl die Lieferung existiert.\n- Findet `DeliveryNumber` keine Lieferung, erscheint dieselbe Meldung.\n- Die Prozedur gibt bei Fehlern den Rückgabewert `-1` zurück. Fehler werden nur als `ReturnMSG`-Zeile gemeldet, nicht als SQL-Fehler.\n- Die Existenzprüfungen lesen `SDelHeader` mit `NOLOCK`. Eine explizite Transaktion wird nicht verwendet.\n- Bei einer Statusänderung wird `pixi_MQ_DeliveryStatusChanged_EventPublish` ausgeführt. Die Definition liegt nicht vor, daher ist der Inhalt der veröffentlichten Nachricht unbekannt.\n- Die genaue fachliche Bedeutung des Status `INV` ist im Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateDelivery"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert den Kopf einer Lieferantenlieferung (Notiz, externe Nummern, Status, Picco-/Mobix-Sperre) per Liefer-ID oder Liefernummer.\n\nAktualisiert einen Datensatz in `SDelHeader` (Kopf einer Lieferantenlieferung) und liefert immer genau eine Zeile mit der Spalte `ReturnMSG`.\n\n**Ermittlung der Lieferung**\n- `SDelHkey` und `DeliveryNumber` gelten bei `0` als nicht angegeben. Mindestens einer der Werte ist erforderlich.\n- Ist `SDelHkey` angegeben, wird dieser verwendet und `DeliveryNumber` ignoriert.\n- Andernfalls wird die Lieferung mit `SDelHNr = DeliveryNumber` und dem kleinsten Schlüssel verwendet.\n\n**Prüfungen**\n- `Status` muss `NEW`, `INV` oder `CLS` sein oder weggelassen werden (`NULL`); dann bleibt der aktuelle Status erhalten. Ein Leerstring wird abgelehnt.\n- Ist `ExternalReceiptNr` angegeben, darf keine andere Lieferung desselben Lieferanten diese externe Belegnummer bereits besitzen.\n- Ohne `PiccoUser`: Die Lieferung muss existieren und darf nicht durch Picco gesperrt sein (`LockedByPicco` ungleich `Y`).\n- Mit `PiccoUser` (Mobix-/Picco-Client): Die Lieferung muss existieren und entweder diesem `PiccoUser` zugeordnet oder nicht durch Picco gesperrt sein.\n\n**Behandlung der Felder**\n- `Note`, `extInvoiceNr` und `extOrderNr` werden getrimmt. Leere oder fehlende Werte behalten den gespeicherten Wert.\n- `ExternalReceiptNr` und `Status`: Fehlende oder leere Werte behalten den gespeicherten Wert.\n- `UserName` ist standardmäßig `API` und wird als letzter Bearbeiter gespeichert; das Änderungsdatum wird auf die aktuelle Zeit gesetzt.\n- Die Picco-Informationen werden immer neu geschrieben:\n - Ohne `PiccoUser` werden `PiccoUser` und `LockedByPicco` der Lieferung geleert.\n - Mit `PiccoUser` wird der Benutzer gespeichert; `LockedByPicco` wird auf `Y` gesetzt, wenn `LockDelivery = 1`. Bei `Status = CLS` werden Picco-Benutzer und Sperre entfernt.\n- `SupplNr` ist veraltet. Der Lieferant wird nie geändert.\n\nÄndert sich der Status tatsächlich, wird ein Ereignis „Lieferstatus geändert“ veröffentlicht.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHkey` | int | Nein | Interner Schlüssel der Lieferung (`SDelHKey`). `0` gilt als nicht angegeben. Hat Vorrang vor `DeliveryNumber`. |\n| `SupplNr` | varchar(4) | Nein | Veraltet. Wird ignoriert; der Lieferant wird aus dem Lieferkopf gelesen und nie geändert. |\n| `DeliveryNumber` | int | Nein | Liefernummer (`SDelHNr`). Wird nur verwendet, wenn `SDelHkey` fehlt; `0` gilt als nicht angegeben. |\n| `Note` | varchar(8000) | Nein | Neue Notiz der Lieferung. Wird getrimmt; leer oder fehlend behält die gespeicherte Notiz. |\n| `extInvoiceNr` | varchar(25) | Nein | Externe Rechnungsnummer des Lieferanten. Wird getrimmt; leer oder fehlend behält den gespeicherten Wert. |\n| `extOrderNr` | varchar(8000) | Nein | Externe Bestellnummer(n). Wird getrimmt; leer oder fehlend behält den gespeicherten Wert. Effektiv auf 1000 Zeichen begrenzt. |\n| `UserName` | varchar(50) | Nein | Als letzter Bearbeiter gespeicherter Benutzer. Standard ist `API`. |\n| `PiccoUser` | varchar(59) | Nein | Picco-/Mobix-Benutzer, der die Lieferung bearbeitet. Leer gilt als nicht angegeben. Fehlt der Wert, werden Picco-Zuordnung und Sperre entfernt. |\n| `Status` | varchar(3) | Nein | Neuer Lieferstatus. Fehlend behält den aktuellen Status; ein Leerstring wird abgelehnt. |\n| `LockDelivery` | bit | Nein | Nur mit `PiccoUser`: `1` sperrt die Lieferung für diesen Picco-Benutzer (`LockedByPicco = Y`), sofern `Status` nicht `CLS` ist. |\n| `ExternalReceiptNr` | varchar(50) | Nein | Externe Belegnummer. Muss je Lieferant eindeutig sein; leer oder fehlend behält den gespeicherten Wert. |\n\n- `Note`, `extInvoiceNr`, `extOrderNr` und `ExternalReceiptNr` lassen sich mit diesem Aufruf nicht leeren. Leere Werte behalten den bestehenden Inhalt.\n- `extOrderNr` ist als `varchar(8000)` deklariert, die interne Update-Prozedur nimmt aber nur `varchar(1000)` an. Längere Werte werden abgeschnitten.\n- Ein Aufruf ohne `PiccoUser` entfernt eine bestehende Picco-Benutzerzuordnung der Lieferung.\n- Bei einer durch Picco gesperrten Lieferung schlägt ein Aufruf ohne `PiccoUser` mit `Delivery header does not exist` fehl, obwohl die Lieferung existiert.\n- Findet `DeliveryNumber` keine Lieferung, erscheint dieselbe Meldung.\n- Die Prozedur gibt bei Fehlern den Rückgabewert `-1` zurück. Fehler werden nur als `ReturnMSG`-Zeile gemeldet, nicht als SQL-Fehler.\n- Die Existenzprüfungen lesen `SDelHeader` mit `NOLOCK`. Eine explizite Transaktion wird nicht verwendet.\n- Bei einer Statusänderung wird `pixi_MQ_DeliveryStatusChanged_EventPublish` ausgeführt. Die Definition liegt nicht vor, daher ist der Inhalt der veröffentlichten Nachricht unbekannt.\n- Die genaue fachliche Bedeutung des Status `INV` ist im Code nicht ersichtlich.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateDelivery"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Update successful\n \n"
}
]
},
{
"name": "pixiUpdateDeliveryItem",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert eine bestehende Artikelposition einer Lieferantenlieferung (Menge, Einkaufspreis, Charge, MHD), optional mit Zuordnung zu einer Bestellposition.\n\nÄndert eine bestehende Position (`SDelDetail`) einer Lieferantenlieferung. Der Aufruf legt keine neuen Positionen an. Aktualisiert wird nur eine Position, die für den Artikel auf der Lieferung bereits vorhanden ist.\n\n1. **Lieferung ermitteln.** `SDelHKey` oder `DeliveryNumber` (`SDelHNr`) angeben. `SDelHSupplNr` kann die Suche einschränken. Verwendet wird der erste passende `SDelHeader`-Datensatz. Der Aufruf bricht ab, wenn:\n - keine Lieferung gefunden wird,\n - der Lieferungsstatus `CLS` oder `INV` ist,\n - die Lieferung durch Picco gesperrt ist (`LockedByPicco` gesetzt) und `PiccoUser` nicht dem sperrenden Benutzer entspricht.\n\n Danach wird für alle weiteren Schritte die Lieferantennummer der Lieferung selbst verwendet.\n2. **Artikel ermitteln.** `fpixi_GetItemKey` ermittelt den Artikel über `EANUPC` oder, wenn keine EAN angegeben ist, über `ItemNrInternal`. Gesucht wird in scanbaren Artikelcodes (`pixi.ItemCode` verknüpft mit `ItemCodeType`, `Scannable = 1`). Sind beide Werte angegeben, wird nur `EANUPC` verwendet.\n3. **Optionale Bestellzuordnung.** Dieser Schritt läuft nur, wenn `InternalNumber` oder `ExternalCode` angegeben ist. `InternalNumber` hat Vorrang. Der Aufruf sucht in `pixi.SupplierOrder` nach `InternalNumber` bzw. `ExternalCode` und prüft die Regeln `Error01` bis `Error07`:\n - der externe Code darf nicht auf mehreren Bestellungen des Lieferanten der Lieferung vorkommen,\n - eine Bestellung muss gefunden werden,\n - die Bestellung muss zum Lieferanten der Lieferung gehören,\n - der Artikel muss auf der Bestellung stehen,\n - der Bestellstatus muss für die Lieferung zulässig sein.\n\n Die zulässigen Status hängen von der Einstellung `ConfirmOrderedDocumentOnDelivery` ab: `0` verwendet Status mit `IsConfirmed = 1`, `1` verwendet Status mit `IsOrderedConfirmed = 1`. Mit der Id der gefundenen Bestellposition wird anschließend die Lieferposition gesucht, deren `SDelDsorderlineRef` auf diese Bestellposition verweist.\n4. **Lieferposition ohne Bestellzuordnung ermitteln.** Gelesen werden alle Positionen der Lieferung für den Artikel, bei Angabe von `SdelDkey` nur diese Position. Gibt es keine Position oder mehrere Positionen ohne `SdelDkey`, wird ein Fehler zurückgegeben.\n5. **Fehlende Werte ergänzen.** Nicht angegebene Parameter behalten die Werte der bestehenden Position: gelieferte Menge, Charge, Mindesthaltbarkeitsdatum und Bestellpositionsreferenz. Die bestellte Menge wird immer aus der bestehenden Position übernommen.\n6. **Einkaufspreis aktualisieren.** Ist `SupplPrice` ungleich 0, schreibt `Pixi_SetAddItemsSupPrice` den Preis in die Lieferanten-Artikeldaten (`AddItems`). Das geschieht nur bei positiven Preisen. Die Position erhält dann Preis, Mittelpreis und Endpreis = `SupplPrice`, die Rabatte werden auf 0 gesetzt. Ist `SupplPrice` 0, bleiben die bisherigen Preise der Position erhalten.\n7. **Position schreiben.** `GOS_SDelDetailInsertOrUpdate` aktualisiert die Position und gibt sie vollständig zurück, einschließlich Auftragskennzahlen zum Artikel.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | Nein | Interner Schlüssel der Lieferung (`SDelHeader.SDelHKey`). Dieser Wert oder `DeliveryNumber` ist erforderlich; 0 gilt als nicht angegeben. |\n| `DeliveryNumber` | int | Nein | Lieferungsnummer (`SDelHNr`). Alternative zu `SDelHKey`; beide können kombiniert als Filter verwendet werden. |\n| `UserName` | varchar(50) | Nein | Benutzername, der als letzter Bearbeiter der Lieferposition gespeichert wird (`SDelDupdateEmp`). |\n| `ItemNrInternal` | varchar(50) | Nein | Artikelkennung, die unter den scanbaren Artikelcodes gesucht wird. Wird nur verwendet, wenn `EANUPC` leer ist. Dieser Wert oder `EANUPC` ist erforderlich. |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC des Artikels, gesucht unter den scanbaren Artikelcodes. Hat Vorrang vor `ItemNrInternal`. |\n| `SDelHSupplNr` | varchar(4) | Nein | Optionaler Filter auf die Lieferantennummer bei der Suche der Lieferung. Danach wird die Lieferantennummer der gefundenen Lieferung verwendet. |\n| `DeliverdQty` | int | Nein | Neue gelieferte Menge. NULL oder 0 behält die bestehende Menge der Position. |\n| `SupplPrice` | money | Nein | Neuer Einkaufspreis. Ist er ungleich 0, wird er in die Position geschrieben (Preis, Mittelpreis und Endpreis; Rabatte werden auf 0 gesetzt). Positive Werte werden zusätzlich in `AddItems` gespeichert. 0 behält die bestehenden Preise der Position. |\n| `PiccoUser` | varchar(50) | Nein | Picco-Benutzername. Wird benötigt, um eine durch Picco gesperrte Lieferung zu bearbeiten; er muss dem sperrenden Benutzer entsprechen. |\n| `InternalNumber` | int | Nein | Interne Nummer einer Bestellung (`pixi.SupplierOrder.InternalNumber`). Dient der Zuordnung der Lieferposition zur Bestellposition. Hat Vorrang vor `ExternalCode`; 0 gilt als nicht angegeben. |\n| `ExternalCode` | varchar(50) | Nein | Externer Code einer Bestellung (`pixi.SupplierOrder.ExternalCode`). Wird nur verwendet, wenn `InternalNumber` leer ist. |\n| `BatchNumber` | varchar(50) | Nein | Chargennummer der Position. NULL oder leer behält den bisherigen Wert. |\n| `BestBeforeDate` | datetime | Nein | Mindesthaltbarkeitsdatum der Position. NULL behält den bisherigen Wert. |\n| `SdelDkey` | int | Nein | Schlüssel der Lieferposition (`SDelDetail.SDelDkey`). Erforderlich, wenn der Artikel auf mehreren Positionen der Lieferung vorkommt. |\n\n- Behandlung leerer Werte: Der Code wendet `NULLIF(x, '')` auf `int`- und `datetime`-Parameter an. Dadurch werden `0` (und bei `BestBeforeDate` das Datum `1900-01-01`) zu NULL. Folgen:\n - `DeliverdQty = 0` setzt die Menge nicht auf 0; die bestehende Menge bleibt erhalten.\n - `SDelHKey = 0` und `InternalNumber = 0` gelten als nicht angegeben.\n - Charge und Mindesthaltbarkeitsdatum können nicht geleert werden; NULL oder leer behält den bisherigen Wert.\n- `DeliverdQty` ist als `int` deklariert, Bruchmengen sind über diesen Aufruf nicht möglich.\n- Passt `DeliveryNumber` auf mehrere Lieferungen, wird eine beliebige verwendet (`TOP (1)` ohne `ORDER BY`). Für eine eindeutige Auswahl `SDelHKey` oder `SDelHSupplNr` mitgeben.\n- Die Bestellsuche ist nicht auf den Lieferanten der Lieferung beschränkt. Existiert derselbe `ExternalCode` bzw. dieselbe `InternalNumber` auch bei einer Bestellung eines anderen Lieferanten, wird `Error02` zurückgegeben.\n- Enthält die Einstellung `ConfirmOrderedDocumentOnDelivery` einen anderen Wert als `0` oder `1`, ist kein Status zulässig und es wird immer `Error06` zurückgegeben. Ausgewertet wird nur das erste Zeichen der Einstellung. Eine fehlende Einstellung gilt als `0`.\n- Wird die Bestellzuordnung zusammen mit `SdelDkey` verwendet, wird die angegebene `SdelDkey`-Position aktualisiert. Sie wird nicht gegen die gefundene Bestellposition geprüft.\n- Ein negativer `SupplPrice` wird nicht in `AddItems` geschrieben, aber trotzdem in die Lieferposition übernommen.\n- `Pixi_SetAddItemsSupPrice` aktualisiert `AddItems.SupplPrice` für alle Lieferanten-Artikeldatensätze mit derselben `IntLinkNr1` und Lieferantennummer, nicht nur für den gelieferten Artikel.\n- Ist die Einstellung `InsertAddItemOnSOrdersDragDrop` = `1` und hat der Artikel keinen `AddItems`-Datensatz für den Lieferanten, legt `GOS_SDelDetailInsertOrUpdate` einen über `Pixi_InsertAddItemOnDelivery` an. Diese Prozedur liegt nicht vor; ob sie eine zusätzliche Ergebnismenge liefert, ist unbekannt.\n- Fehler werden als Zeile mit der Spalte `ERROR` zurückgegeben. Die Prozedur liefert in diesem Fall zusätzlich den Rückgabewert `1`. `Error04` wird ohne Spaltenalias zurückgegeben.\n- Es wird keine explizite Transaktion verwendet. Lesezugriffe erfolgen mit `NOLOCK`, das Update mit `ROWLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateDeliveryItem"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert eine bestehende Artikelposition einer Lieferantenlieferung (Menge, Einkaufspreis, Charge, MHD), optional mit Zuordnung zu einer Bestellposition.\n\nÄndert eine bestehende Position (`SDelDetail`) einer Lieferantenlieferung. Der Aufruf legt keine neuen Positionen an. Aktualisiert wird nur eine Position, die für den Artikel auf der Lieferung bereits vorhanden ist.\n\n1. **Lieferung ermitteln.** `SDelHKey` oder `DeliveryNumber` (`SDelHNr`) angeben. `SDelHSupplNr` kann die Suche einschränken. Verwendet wird der erste passende `SDelHeader`-Datensatz. Der Aufruf bricht ab, wenn:\n - keine Lieferung gefunden wird,\n - der Lieferungsstatus `CLS` oder `INV` ist,\n - die Lieferung durch Picco gesperrt ist (`LockedByPicco` gesetzt) und `PiccoUser` nicht dem sperrenden Benutzer entspricht.\n\n Danach wird für alle weiteren Schritte die Lieferantennummer der Lieferung selbst verwendet.\n2. **Artikel ermitteln.** `fpixi_GetItemKey` ermittelt den Artikel über `EANUPC` oder, wenn keine EAN angegeben ist, über `ItemNrInternal`. Gesucht wird in scanbaren Artikelcodes (`pixi.ItemCode` verknüpft mit `ItemCodeType`, `Scannable = 1`). Sind beide Werte angegeben, wird nur `EANUPC` verwendet.\n3. **Optionale Bestellzuordnung.** Dieser Schritt läuft nur, wenn `InternalNumber` oder `ExternalCode` angegeben ist. `InternalNumber` hat Vorrang. Der Aufruf sucht in `pixi.SupplierOrder` nach `InternalNumber` bzw. `ExternalCode` und prüft die Regeln `Error01` bis `Error07`:\n - der externe Code darf nicht auf mehreren Bestellungen des Lieferanten der Lieferung vorkommen,\n - eine Bestellung muss gefunden werden,\n - die Bestellung muss zum Lieferanten der Lieferung gehören,\n - der Artikel muss auf der Bestellung stehen,\n - der Bestellstatus muss für die Lieferung zulässig sein.\n\n Die zulässigen Status hängen von der Einstellung `ConfirmOrderedDocumentOnDelivery` ab: `0` verwendet Status mit `IsConfirmed = 1`, `1` verwendet Status mit `IsOrderedConfirmed = 1`. Mit der Id der gefundenen Bestellposition wird anschließend die Lieferposition gesucht, deren `SDelDsorderlineRef` auf diese Bestellposition verweist.\n4. **Lieferposition ohne Bestellzuordnung ermitteln.** Gelesen werden alle Positionen der Lieferung für den Artikel, bei Angabe von `SdelDkey` nur diese Position. Gibt es keine Position oder mehrere Positionen ohne `SdelDkey`, wird ein Fehler zurückgegeben.\n5. **Fehlende Werte ergänzen.** Nicht angegebene Parameter behalten die Werte der bestehenden Position: gelieferte Menge, Charge, Mindesthaltbarkeitsdatum und Bestellpositionsreferenz. Die bestellte Menge wird immer aus der bestehenden Position übernommen.\n6. **Einkaufspreis aktualisieren.** Ist `SupplPrice` ungleich 0, schreibt `Pixi_SetAddItemsSupPrice` den Preis in die Lieferanten-Artikeldaten (`AddItems`). Das geschieht nur bei positiven Preisen. Die Position erhält dann Preis, Mittelpreis und Endpreis = `SupplPrice`, die Rabatte werden auf 0 gesetzt. Ist `SupplPrice` 0, bleiben die bisherigen Preise der Position erhalten.\n7. **Position schreiben.** `GOS_SDelDetailInsertOrUpdate` aktualisiert die Position und gibt sie vollständig zurück, einschließlich Auftragskennzahlen zum Artikel.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | Nein | Interner Schlüssel der Lieferung (`SDelHeader.SDelHKey`). Dieser Wert oder `DeliveryNumber` ist erforderlich; 0 gilt als nicht angegeben. |\n| `DeliveryNumber` | int | Nein | Lieferungsnummer (`SDelHNr`). Alternative zu `SDelHKey`; beide können kombiniert als Filter verwendet werden. |\n| `UserName` | varchar(50) | Nein | Benutzername, der als letzter Bearbeiter der Lieferposition gespeichert wird (`SDelDupdateEmp`). |\n| `ItemNrInternal` | varchar(50) | Nein | Artikelkennung, die unter den scanbaren Artikelcodes gesucht wird. Wird nur verwendet, wenn `EANUPC` leer ist. Dieser Wert oder `EANUPC` ist erforderlich. |\n| `EANUPC` | varchar(13) | Nein | EAN/UPC des Artikels, gesucht unter den scanbaren Artikelcodes. Hat Vorrang vor `ItemNrInternal`. |\n| `SDelHSupplNr` | varchar(4) | Nein | Optionaler Filter auf die Lieferantennummer bei der Suche der Lieferung. Danach wird die Lieferantennummer der gefundenen Lieferung verwendet. |\n| `DeliverdQty` | int | Nein | Neue gelieferte Menge. NULL oder 0 behält die bestehende Menge der Position. |\n| `SupplPrice` | money | Nein | Neuer Einkaufspreis. Ist er ungleich 0, wird er in die Position geschrieben (Preis, Mittelpreis und Endpreis; Rabatte werden auf 0 gesetzt). Positive Werte werden zusätzlich in `AddItems` gespeichert. 0 behält die bestehenden Preise der Position. |\n| `PiccoUser` | varchar(50) | Nein | Picco-Benutzername. Wird benötigt, um eine durch Picco gesperrte Lieferung zu bearbeiten; er muss dem sperrenden Benutzer entsprechen. |\n| `InternalNumber` | int | Nein | Interne Nummer einer Bestellung (`pixi.SupplierOrder.InternalNumber`). Dient der Zuordnung der Lieferposition zur Bestellposition. Hat Vorrang vor `ExternalCode`; 0 gilt als nicht angegeben. |\n| `ExternalCode` | varchar(50) | Nein | Externer Code einer Bestellung (`pixi.SupplierOrder.ExternalCode`). Wird nur verwendet, wenn `InternalNumber` leer ist. |\n| `BatchNumber` | varchar(50) | Nein | Chargennummer der Position. NULL oder leer behält den bisherigen Wert. |\n| `BestBeforeDate` | datetime | Nein | Mindesthaltbarkeitsdatum der Position. NULL behält den bisherigen Wert. |\n| `SdelDkey` | int | Nein | Schlüssel der Lieferposition (`SDelDetail.SDelDkey`). Erforderlich, wenn der Artikel auf mehreren Positionen der Lieferung vorkommt. |\n\n- Behandlung leerer Werte: Der Code wendet `NULLIF(x, '')` auf `int`- und `datetime`-Parameter an. Dadurch werden `0` (und bei `BestBeforeDate` das Datum `1900-01-01`) zu NULL. Folgen:\n - `DeliverdQty = 0` setzt die Menge nicht auf 0; die bestehende Menge bleibt erhalten.\n - `SDelHKey = 0` und `InternalNumber = 0` gelten als nicht angegeben.\n - Charge und Mindesthaltbarkeitsdatum können nicht geleert werden; NULL oder leer behält den bisherigen Wert.\n- `DeliverdQty` ist als `int` deklariert, Bruchmengen sind über diesen Aufruf nicht möglich.\n- Passt `DeliveryNumber` auf mehrere Lieferungen, wird eine beliebige verwendet (`TOP (1)` ohne `ORDER BY`). Für eine eindeutige Auswahl `SDelHKey` oder `SDelHSupplNr` mitgeben.\n- Die Bestellsuche ist nicht auf den Lieferanten der Lieferung beschränkt. Existiert derselbe `ExternalCode` bzw. dieselbe `InternalNumber` auch bei einer Bestellung eines anderen Lieferanten, wird `Error02` zurückgegeben.\n- Enthält die Einstellung `ConfirmOrderedDocumentOnDelivery` einen anderen Wert als `0` oder `1`, ist kein Status zulässig und es wird immer `Error06` zurückgegeben. Ausgewertet wird nur das erste Zeichen der Einstellung. Eine fehlende Einstellung gilt als `0`.\n- Wird die Bestellzuordnung zusammen mit `SdelDkey` verwendet, wird die angegebene `SdelDkey`-Position aktualisiert. Sie wird nicht gegen die gefundene Bestellposition geprüft.\n- Ein negativer `SupplPrice` wird nicht in `AddItems` geschrieben, aber trotzdem in die Lieferposition übernommen.\n- `Pixi_SetAddItemsSupPrice` aktualisiert `AddItems.SupplPrice` für alle Lieferanten-Artikeldatensätze mit derselben `IntLinkNr1` und Lieferantennummer, nicht nur für den gelieferten Artikel.\n- Ist die Einstellung `InsertAddItemOnSOrdersDragDrop` = `1` und hat der Artikel keinen `AddItems`-Datensatz für den Lieferanten, legt `GOS_SDelDetailInsertOrUpdate` einen über `Pixi_InsertAddItemOnDelivery` an. Diese Prozedur liegt nicht vor; ob sie eine zusätzliche Ergebnismenge liefert, ist unbekannt.\n- Fehler werden als Zeile mit der Spalte `ERROR` zurückgegeben. Die Prozedur liefert in diesem Fall zusätzlich den Rückgabewert `1`. `Error04` wird ohne Spaltenalias zurückgegeben.\n- Es wird keine explizite Transaktion verwendet. Lesezugriffe erfolgen mit `NOLOCK`, das Update mit `ROWLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateDeliveryItem"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Item not exist on delivery\n \n"
}
]
},
{
"name": "pixiUpdateItemSupplier",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n L001\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert einen Lieferantenartikel-Datensatz (AddItems) eines Artikels: EAN, Lieferantenpreis, Lieferanten-Artikelnummer, Hauptlieferant, Mindestmenge, Lieferzeit, Aktiv-Flag.\n\nAktualisiert genau einen Lieferantenartikel-Datensatz in `AddItems`. Ein Lieferantenartikel ist die Kombination aus Artikel, Lieferant und EAN (`EANUPC`).\n\nAblauf:\n\n1. `SupplNr` ist Pflicht. Ein Leerstring gilt als nicht angegeben. Der Lieferant wird in `Suppliers` über `SupplNr` gesucht; existiert er nicht, wird eine Fehlerzeile geliefert.\n2. Mindestens ein Änderungsparameter muss gesetzt sein: `NewEAN`, `SupplPrice`, `ItemNrSuppl`, `PreferredSupplier`, `MinOrderQty`, `OnlyPU`, `ItemDeliveryTime` oder `IsActive`. Bei `NewEAN` und `ItemNrSuppl` gilt ein Leerstring als nicht gesetzt.\n3. Der Artikel wird über `ItemKey`, `EAN` (Barcode, Codetyp 1) und/oder `ItemNrInt` (Shop-Artikelnummer, Codetyp 2) in `pixi.ItemCode` ermittelt. Jede übergebene Kennung muss existieren, und alle müssen auf denselben Artikel zeigen. `ItemKey = 0` gilt als nicht gesetzt.\n4. Wird `NewEAN` übergeben, darf dieser Code nicht bereits als scanbarer Code eines anderen Artikels existieren.\n5. Alle Lieferantenartikel des Artikels werden geladen. Der zu ändernde Datensatz wird über den ermittelten Lieferanten und, falls `EAN` übergeben wurde, über `EANUPC = EAN` bestimmt. Es muss genau ein Datensatz passen. Hat der Lieferant mehrere EANs für den Artikel, ist `EAN` zur eindeutigen Auswahl anzugeben.\n6. Wird `NewEAN` übergeben, darf kein anderer Lieferantenartikel desselben Artikels diese EAN bereits für dieselbe `SupplNr` haben.\n7. Bei `PreferredSupplier = 1` werden alle anderen derzeit bevorzugten Lieferantenartikel des Artikels auf `PreferredSupplier = 0` gesetzt.\n8. Die Aktualisierung läuft in einer Transaktion.\n\nAm Zieldatensatz werden nur die übergebenen Werte geändert. Nicht übergebene Werte behalten ihren bisherigen Inhalt. Zusätzlich gilt:\n\n- `UpdateDate` wird auf die aktuelle Zeit gesetzt.\n- `RowVersion` wird um 1 erhöht.\n- `SupplPriceUpdateDate` wird auf jetzt gesetzt, wenn sich der neue `SupplPrice` vom gespeicherten Preis unterscheidet.\n\nGeliefert wird eine Statuszeile (`Status`, `Message`). Bei Erfolg ist `Status` gleich `Record updated`, und `Message` enthält den resultierenden Preis, die Lieferanten-Artikelnummer und die EAN des Zieldatensatzes.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interne Artikel-ID zur Identifikation des Artikels. 0 gilt als nicht gesetzt. |\n| `ItemNrInt` | varchar(50) | Nein | Shop-Artikelnummer (Codetyp 2 in `pixi.ItemCode`) zur Identifikation des Artikels. |\n| `EAN` | varchar(13) | Nein | Aktuelle EAN. Identifiziert den Artikel (Codetyp 1) und wählt den Lieferantenartikel über `EANUPC` aus. Erforderlich, wenn der Lieferant mehrere EANs für den Artikel hat. |\n| `NewEAN` | varchar(13) | Nein | Neue EAN für `EANUPC`. Sie darf weder als scanbarer Code eines anderen Artikels noch bei einem anderen Lieferantenartikel desselben Artikels und Lieferanten existieren. Ein Leerstring behält den aktuellen Wert. |\n| `SupplNr` | varchar(4) | Ja | Lieferantennummer. Pflicht. Muss in `Suppliers` existieren. |\n| `SupplPrice` | money | Nein | Neuer Lieferanten-(Einkaufs-)Preis. Weicht er vom gespeicherten Preis ab, wird `SupplPriceUpdateDate` auf jetzt gesetzt. |\n| `ItemNrSuppl` | varchar(50) | Nein | Neue Lieferanten-Artikelnummer. Ein Leerstring behält den aktuellen Wert. |\n| `PreferredSupplier` | bit | Nein | Setzt oder entfernt das Hauptlieferanten-Kennzeichen. |\n| `MinOrderQty` | int | Nein | Neue Mindestbestellmenge. |\n| `OnlyPU` | bit | Nein | Neuer Wert für `OrderOnlyPackageUnits` (nur in Verpackungseinheiten bestellen). |\n| `ItemDeliveryTime` | int | Nein | Neue Lieferzeit des Lieferanten (`SupplDeliveryTime`). |\n| `IsActive` | bit | Nein | Setzt das `Active`-Kennzeichen des Lieferantenartikels. |\n\n- **Werte leeren ist nicht möglich.** Parameter mit NULL sowie Leerstrings bei `NewEAN` und `ItemNrSuppl` behalten den bisherigen Wert. Ein Feld kann mit diesem Aufruf nicht auf NULL gesetzt werden.\n- **`EAN` hat zwei Aufgaben.** Die EAN identifiziert den Artikel: Sie muss als Barcode (Codetyp 1) in `pixi.ItemCode` existieren. Außerdem wählt sie den `AddItems`-Datensatz über `EANUPC` aus.\n- **`NewEAN` ändert nur `AddItems.EANUPC`.** Die Prozedur aktualisiert `pixi.ItemCode` nicht direkt. Ob Trigger den Code abgleichen, ist aus diesem Code nicht ersichtlich.\n- **`PreferredSupplier = 0`** entfernt das Kennzeichen nur am Zieldatensatz. Kein anderer Lieferant wird zum Hauptlieferanten gemacht.\n- **`SupplPriceUpdateDate`** wird nicht aktualisiert, wenn der gespeicherte Preis NULL war, da der Vergleich `SupplPrice <> @SupplPrice` dann nicht zutrifft.\n- **NULL-Meldungen.** Wird kein Lieferantenartikel gefunden und wurde `ItemKey` nicht übergeben, ist die Fehler-`Message` wegen der String-Verkettung mit NULL selbst NULL. Dasselbe gilt für die Erfolgs-`Message`, wenn der resultierende `SupplPrice` NULL ist.\n- **Sperren.** Lesezugriffe auf `Suppliers`, `pixi.ItemCode` und `AddItems` erfolgen mit `NOLOCK`. Das Update verwendet `ROWLOCK`.\n- **Transaktionen.** Die Prozedur öffnet eine eigene Transaktion oder setzt einen Savepoint, wenn bereits eine Transaktion offen ist. Im Fehlerfall wird zurückgerollt, über `log.InsertError` (Definition nicht beigefügt) protokolliert und `ERROR_MESSAGE()` als Statuszeile geliefert.\n- **Lieferantensuche.** Sie verwendet `TOP (1)` auf `Suppliers` über `SupplNr`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateItemSupplier"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n L001\n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert einen Lieferantenartikel-Datensatz (AddItems) eines Artikels: EAN, Lieferantenpreis, Lieferanten-Artikelnummer, Hauptlieferant, Mindestmenge, Lieferzeit, Aktiv-Flag.\n\nAktualisiert genau einen Lieferantenartikel-Datensatz in `AddItems`. Ein Lieferantenartikel ist die Kombination aus Artikel, Lieferant und EAN (`EANUPC`).\n\nAblauf:\n\n1. `SupplNr` ist Pflicht. Ein Leerstring gilt als nicht angegeben. Der Lieferant wird in `Suppliers` über `SupplNr` gesucht; existiert er nicht, wird eine Fehlerzeile geliefert.\n2. Mindestens ein Änderungsparameter muss gesetzt sein: `NewEAN`, `SupplPrice`, `ItemNrSuppl`, `PreferredSupplier`, `MinOrderQty`, `OnlyPU`, `ItemDeliveryTime` oder `IsActive`. Bei `NewEAN` und `ItemNrSuppl` gilt ein Leerstring als nicht gesetzt.\n3. Der Artikel wird über `ItemKey`, `EAN` (Barcode, Codetyp 1) und/oder `ItemNrInt` (Shop-Artikelnummer, Codetyp 2) in `pixi.ItemCode` ermittelt. Jede übergebene Kennung muss existieren, und alle müssen auf denselben Artikel zeigen. `ItemKey = 0` gilt als nicht gesetzt.\n4. Wird `NewEAN` übergeben, darf dieser Code nicht bereits als scanbarer Code eines anderen Artikels existieren.\n5. Alle Lieferantenartikel des Artikels werden geladen. Der zu ändernde Datensatz wird über den ermittelten Lieferanten und, falls `EAN` übergeben wurde, über `EANUPC = EAN` bestimmt. Es muss genau ein Datensatz passen. Hat der Lieferant mehrere EANs für den Artikel, ist `EAN` zur eindeutigen Auswahl anzugeben.\n6. Wird `NewEAN` übergeben, darf kein anderer Lieferantenartikel desselben Artikels diese EAN bereits für dieselbe `SupplNr` haben.\n7. Bei `PreferredSupplier = 1` werden alle anderen derzeit bevorzugten Lieferantenartikel des Artikels auf `PreferredSupplier = 0` gesetzt.\n8. Die Aktualisierung läuft in einer Transaktion.\n\nAm Zieldatensatz werden nur die übergebenen Werte geändert. Nicht übergebene Werte behalten ihren bisherigen Inhalt. Zusätzlich gilt:\n\n- `UpdateDate` wird auf die aktuelle Zeit gesetzt.\n- `RowVersion` wird um 1 erhöht.\n- `SupplPriceUpdateDate` wird auf jetzt gesetzt, wenn sich der neue `SupplPrice` vom gespeicherten Preis unterscheidet.\n\nGeliefert wird eine Statuszeile (`Status`, `Message`). Bei Erfolg ist `Status` gleich `Record updated`, und `Message` enthält den resultierenden Preis, die Lieferanten-Artikelnummer und die EAN des Zieldatensatzes.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Nein | Interne Artikel-ID zur Identifikation des Artikels. 0 gilt als nicht gesetzt. |\n| `ItemNrInt` | varchar(50) | Nein | Shop-Artikelnummer (Codetyp 2 in `pixi.ItemCode`) zur Identifikation des Artikels. |\n| `EAN` | varchar(13) | Nein | Aktuelle EAN. Identifiziert den Artikel (Codetyp 1) und wählt den Lieferantenartikel über `EANUPC` aus. Erforderlich, wenn der Lieferant mehrere EANs für den Artikel hat. |\n| `NewEAN` | varchar(13) | Nein | Neue EAN für `EANUPC`. Sie darf weder als scanbarer Code eines anderen Artikels noch bei einem anderen Lieferantenartikel desselben Artikels und Lieferanten existieren. Ein Leerstring behält den aktuellen Wert. |\n| `SupplNr` | varchar(4) | Ja | Lieferantennummer. Pflicht. Muss in `Suppliers` existieren. |\n| `SupplPrice` | money | Nein | Neuer Lieferanten-(Einkaufs-)Preis. Weicht er vom gespeicherten Preis ab, wird `SupplPriceUpdateDate` auf jetzt gesetzt. |\n| `ItemNrSuppl` | varchar(50) | Nein | Neue Lieferanten-Artikelnummer. Ein Leerstring behält den aktuellen Wert. |\n| `PreferredSupplier` | bit | Nein | Setzt oder entfernt das Hauptlieferanten-Kennzeichen. |\n| `MinOrderQty` | int | Nein | Neue Mindestbestellmenge. |\n| `OnlyPU` | bit | Nein | Neuer Wert für `OrderOnlyPackageUnits` (nur in Verpackungseinheiten bestellen). |\n| `ItemDeliveryTime` | int | Nein | Neue Lieferzeit des Lieferanten (`SupplDeliveryTime`). |\n| `IsActive` | bit | Nein | Setzt das `Active`-Kennzeichen des Lieferantenartikels. |\n\n- **Werte leeren ist nicht möglich.** Parameter mit NULL sowie Leerstrings bei `NewEAN` und `ItemNrSuppl` behalten den bisherigen Wert. Ein Feld kann mit diesem Aufruf nicht auf NULL gesetzt werden.\n- **`EAN` hat zwei Aufgaben.** Die EAN identifiziert den Artikel: Sie muss als Barcode (Codetyp 1) in `pixi.ItemCode` existieren. Außerdem wählt sie den `AddItems`-Datensatz über `EANUPC` aus.\n- **`NewEAN` ändert nur `AddItems.EANUPC`.** Die Prozedur aktualisiert `pixi.ItemCode` nicht direkt. Ob Trigger den Code abgleichen, ist aus diesem Code nicht ersichtlich.\n- **`PreferredSupplier = 0`** entfernt das Kennzeichen nur am Zieldatensatz. Kein anderer Lieferant wird zum Hauptlieferanten gemacht.\n- **`SupplPriceUpdateDate`** wird nicht aktualisiert, wenn der gespeicherte Preis NULL war, da der Vergleich `SupplPrice <> @SupplPrice` dann nicht zutrifft.\n- **NULL-Meldungen.** Wird kein Lieferantenartikel gefunden und wurde `ItemKey` nicht übergeben, ist die Fehler-`Message` wegen der String-Verkettung mit NULL selbst NULL. Dasselbe gilt für die Erfolgs-`Message`, wenn der resultierende `SupplPrice` NULL ist.\n- **Sperren.** Lesezugriffe auf `Suppliers`, `pixi.ItemCode` und `AddItems` erfolgen mit `NOLOCK`. Das Update verwendet `ROWLOCK`.\n- **Transaktionen.** Die Prozedur öffnet eine eigene Transaktion oder setzt einen Savepoint, wenn bereits eine Transaktion offen ist. Im Fehlerfall wird zurückgerollt, über `log.InsertError` (Definition nicht beigefügt) protokolliert und `ERROR_MESSAGE()` als Statuszeile geliefert.\n- **Lieferantensuche.** Sie verwendet `TOP (1)` auf `Suppliers` über `SupplNr`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateItemSupplier"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Record updated\n SupplPrice:12.50, ItemNrSuppl:LF-4711, EANUPC:4006381333931\n \n"
}
]
},
{
"name": "pixiUpdateSOrderline",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 48213\n API\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Menge, Lieferantenpreis, Kommentar, voraussichtliches Lieferdatum oder nicht gelieferte Menge einer Lieferantenbestellposition und berechnet die Bestellsummen neu.\n\nÄndert eine einzelne Position einer Lieferantenbestellung, identifiziert über `SorderlineKey` (`SupplierOrderLine.Id`).\n\n**Prüfungen** (bei einem Fehler wird eine Zeile mit `ReturnCode = 'Error'` geliefert und nichts geändert):\n1. Die Position muss existieren.\n2. Eine `QtyNotDelivered` ungleich 0 wird nur akzeptiert, wenn die Lieferantenbestellung den Status `CON` (bestätigt) hat.\n3. Hat die Lieferantenbestellung den Status `CON` oder `CLS`, dürfen weder `SupplPrice` (nicht NULL) noch `OrderQty` (ungleich 0) übergeben werden.\n\n**Vorbereitung**\n- `UserName` NULL wird zu `API`; der Benutzer wird für den Änderungsstempel über den Namen ermittelt.\n- `EstimatedDelivery` NULL behält das bisherige voraussichtliche Lieferdatum der Position bei.\n- Wird `QtyNotDelivered` explizit als NULL übergeben, bleibt die bisherige nicht gelieferte Menge erhalten.\n\n**Aktualisierung** (durch die interne Prozedur `GOS_SOrderlinesUpdate`):\n- Immer: Kommentar (`Comment` = `Note`), voraussichtliches Lieferdatum, Änderungsbenutzer/-datum und Zeilenversion der Position.\n- Lieferantenbestellung in bearbeitbarem Status (interne Status-Id 1 oder 2): `Qty` (ein `OrderQty` von 0 behält die bisherige Menge), Anzahl Verpackungseinheiten (Menge geteilt durch Verpackungseinheit, aufgerundet), `SupplierPrice` (nur wenn `SupplPrice` ungleich 0), Rabattbetrag/-prozent und Positionssumme werden neu berechnet.\n- Lieferantenbestellung im Status `CON` (interne Status-Id 3): `UndeliveredQty` wird auf `QtyNotDelivered` gesetzt.\n- Der Bestellkopf (`SupplierOrder`) wird neu berechnet: Zwischensumme aus allen Positionssummen, Kopfrabatt, Frachtkosten (auf 0 gesetzt, wenn die Frachtfreigrenze erreicht ist), Gesamtbetrag inklusive Mindermengenzuschlag.\n- Der Lagerplatz-Mengensatz der Position (`SupplierOrderLineLocQty`) erhält die Menge und bei Status `CON` die nicht gelieferte Menge.\n- Hat die Position nach der Aktualisierung ein voraussichtliches Lieferdatum, wird der Artikel für einen erzwungenen Export in den Shop vorgemerkt.\n\nBei Erfolg wird eine Zeile mit `ReturnCode = 'OK'` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SorderlineKey` | int | Ja | Id der zu ändernden Lieferantenbestellposition (`SupplierOrderLine.Id`). |\n| `UserName` | varchar(50) | Ja | Pixi-Benutzername, der als Bearbeiter gespeichert wird. NULL wird durch `API` ersetzt. |\n| `OrderQty` | int | Nein | Neue Bestellmenge. 0 oder NULL behält die bisherige Menge. Nur zulässig, solange die Lieferantenbestellung nicht im Status `CON` oder `CLS` ist. |\n| `Note` | varchar(1024) | Nein | Kommentar der Position. Wird immer geschrieben; ein leerer Wert löscht den bestehenden Kommentar. Darf keine einfachen Anführungszeichen enthalten. |\n| `QtyReceived` | int | Nein | Veraltet, wird ignoriert. |\n| `QtyNotDelivered` | int | Nein | Nicht gelieferte Menge. Ein Wert ungleich 0 ist nur zulässig, wenn die Lieferantenbestellung den Status `CON` hat; dort wird er in `UndeliveredQty` geschrieben (auch der Standardwert 0). Explizites NULL behält den bisherigen Wert. |\n| `EstimatedDelivery` | datetime | Nein | Neues voraussichtliches Lieferdatum der Position. NULL behält das bisherige Datum. |\n| `SupplPrice` | decimal(9, 2) | Nein | Neuer Lieferanten-Einzelpreis. NULL oder 0 behält den bisherigen Preis. Nur zulässig, solange die Lieferantenbestellung nicht im Status `CON` oder `CLS` ist. |\n\n- **Kommentar wird immer überschrieben**: `Note` hat den Standardwert Leerstring, daher löscht ein Weglassen den bestehenden Kommentar der Position. Zum Beibehalten den aktuellen Kommentar mitsenden.\n- **Nicht gelieferte Menge im Status `CON`**: `QtyNotDelivered` hat den Standardwert 0. Bei einer bestätigten Bestellung setzt ein Weglassen `UndeliveredQty` auf 0. Zum Beibehalten explizit NULL (nil) oder den aktuellen Wert senden.\n- `QtyReceived` ist veraltet und wird ignoriert.\n- Die Aktualisierung der Position wird als dynamisches SQL aufgebaut; `Note` wird ohne Maskierung eingefügt, ein einfaches Anführungszeichen (`'`) im Kommentar führt daher zu einem fehlerhaften Statement. SQL-Fehler der internen Prozedur kommen als `SqlMessage` zurück; die abschließende `OK`-Zeile kann trotzdem geliefert werden.\n- Für die Aktualisierungszweige werden die internen Status-Ids 1, 2 und 3 verwendet; Id 3 entspricht laut Code-Kommentar `CON`. Bei anderen Status (z. B. `CLS`) werden nur Kommentar und voraussichtliches Lieferdatum geändert.\n- Die Rabattneuberechnung teilt bei betragsbasiertem Rabatt (`DiscountType = 1`) durch Menge × Preis; Preis oder Menge 0 bei vorhandenem Rabatt kann eine Division durch Null auslösen.\n- Der Shop-Export wird immer ausgelöst, wenn die Position ein voraussichtliches Lieferdatum hat, auch wenn `EstimatedDelivery` nicht übergeben wurde. Die Exportprozedur `Pixi_ExportItemChangesToShop` liegt nicht vor.\n- Keine explizite Transaktion; Lesezugriffe mit `NOLOCK`, Updates mit `ROWLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateSOrderline"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 48213\n API\n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Menge, Lieferantenpreis, Kommentar, voraussichtliches Lieferdatum oder nicht gelieferte Menge einer Lieferantenbestellposition und berechnet die Bestellsummen neu.\n\nÄndert eine einzelne Position einer Lieferantenbestellung, identifiziert über `SorderlineKey` (`SupplierOrderLine.Id`).\n\n**Prüfungen** (bei einem Fehler wird eine Zeile mit `ReturnCode = 'Error'` geliefert und nichts geändert):\n1. Die Position muss existieren.\n2. Eine `QtyNotDelivered` ungleich 0 wird nur akzeptiert, wenn die Lieferantenbestellung den Status `CON` (bestätigt) hat.\n3. Hat die Lieferantenbestellung den Status `CON` oder `CLS`, dürfen weder `SupplPrice` (nicht NULL) noch `OrderQty` (ungleich 0) übergeben werden.\n\n**Vorbereitung**\n- `UserName` NULL wird zu `API`; der Benutzer wird für den Änderungsstempel über den Namen ermittelt.\n- `EstimatedDelivery` NULL behält das bisherige voraussichtliche Lieferdatum der Position bei.\n- Wird `QtyNotDelivered` explizit als NULL übergeben, bleibt die bisherige nicht gelieferte Menge erhalten.\n\n**Aktualisierung** (durch die interne Prozedur `GOS_SOrderlinesUpdate`):\n- Immer: Kommentar (`Comment` = `Note`), voraussichtliches Lieferdatum, Änderungsbenutzer/-datum und Zeilenversion der Position.\n- Lieferantenbestellung in bearbeitbarem Status (interne Status-Id 1 oder 2): `Qty` (ein `OrderQty` von 0 behält die bisherige Menge), Anzahl Verpackungseinheiten (Menge geteilt durch Verpackungseinheit, aufgerundet), `SupplierPrice` (nur wenn `SupplPrice` ungleich 0), Rabattbetrag/-prozent und Positionssumme werden neu berechnet.\n- Lieferantenbestellung im Status `CON` (interne Status-Id 3): `UndeliveredQty` wird auf `QtyNotDelivered` gesetzt.\n- Der Bestellkopf (`SupplierOrder`) wird neu berechnet: Zwischensumme aus allen Positionssummen, Kopfrabatt, Frachtkosten (auf 0 gesetzt, wenn die Frachtfreigrenze erreicht ist), Gesamtbetrag inklusive Mindermengenzuschlag.\n- Der Lagerplatz-Mengensatz der Position (`SupplierOrderLineLocQty`) erhält die Menge und bei Status `CON` die nicht gelieferte Menge.\n- Hat die Position nach der Aktualisierung ein voraussichtliches Lieferdatum, wird der Artikel für einen erzwungenen Export in den Shop vorgemerkt.\n\nBei Erfolg wird eine Zeile mit `ReturnCode = 'OK'` geliefert.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SorderlineKey` | int | Ja | Id der zu ändernden Lieferantenbestellposition (`SupplierOrderLine.Id`). |\n| `UserName` | varchar(50) | Ja | Pixi-Benutzername, der als Bearbeiter gespeichert wird. NULL wird durch `API` ersetzt. |\n| `OrderQty` | int | Nein | Neue Bestellmenge. 0 oder NULL behält die bisherige Menge. Nur zulässig, solange die Lieferantenbestellung nicht im Status `CON` oder `CLS` ist. |\n| `Note` | varchar(1024) | Nein | Kommentar der Position. Wird immer geschrieben; ein leerer Wert löscht den bestehenden Kommentar. Darf keine einfachen Anführungszeichen enthalten. |\n| `QtyReceived` | int | Nein | Veraltet, wird ignoriert. |\n| `QtyNotDelivered` | int | Nein | Nicht gelieferte Menge. Ein Wert ungleich 0 ist nur zulässig, wenn die Lieferantenbestellung den Status `CON` hat; dort wird er in `UndeliveredQty` geschrieben (auch der Standardwert 0). Explizites NULL behält den bisherigen Wert. |\n| `EstimatedDelivery` | datetime | Nein | Neues voraussichtliches Lieferdatum der Position. NULL behält das bisherige Datum. |\n| `SupplPrice` | decimal(9, 2) | Nein | Neuer Lieferanten-Einzelpreis. NULL oder 0 behält den bisherigen Preis. Nur zulässig, solange die Lieferantenbestellung nicht im Status `CON` oder `CLS` ist. |\n\n- **Kommentar wird immer überschrieben**: `Note` hat den Standardwert Leerstring, daher löscht ein Weglassen den bestehenden Kommentar der Position. Zum Beibehalten den aktuellen Kommentar mitsenden.\n- **Nicht gelieferte Menge im Status `CON`**: `QtyNotDelivered` hat den Standardwert 0. Bei einer bestätigten Bestellung setzt ein Weglassen `UndeliveredQty` auf 0. Zum Beibehalten explizit NULL (nil) oder den aktuellen Wert senden.\n- `QtyReceived` ist veraltet und wird ignoriert.\n- Die Aktualisierung der Position wird als dynamisches SQL aufgebaut; `Note` wird ohne Maskierung eingefügt, ein einfaches Anführungszeichen (`'`) im Kommentar führt daher zu einem fehlerhaften Statement. SQL-Fehler der internen Prozedur kommen als `SqlMessage` zurück; die abschließende `OK`-Zeile kann trotzdem geliefert werden.\n- Für die Aktualisierungszweige werden die internen Status-Ids 1, 2 und 3 verwendet; Id 3 entspricht laut Code-Kommentar `CON`. Bei anderen Status (z. B. `CLS`) werden nur Kommentar und voraussichtliches Lieferdatum geändert.\n- Die Rabattneuberechnung teilt bei betragsbasiertem Rabatt (`DiscountType = 1`) durch Menge × Preis; Preis oder Menge 0 bei vorhandenem Rabatt kann eine Division durch Null auslösen.\n- Der Shop-Export wird immer ausgelöst, wenn die Position ein voraussichtliches Lieferdatum hat, auch wenn `EstimatedDelivery` nicht übergeben wurde. Die Exportprozedur `Pixi_ExportItemChangesToShop` liegt nicht vor.\n- Keine explizite Transaktion; Lesezugriffe mit `NOLOCK`, Updates mit `ROWLOCK`.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateSOrderline"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n OK\n Update done successfully.\n \n"
}
]
},
{
"name": "pixiUpdateSupplier",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Stammdaten, Hauptansprechpartner sowie Sperr- und Deaktivierungskennzeichen eines bestehenden Lieferanten anhand seiner Lieferantennummer.\n\nFührt eine Teilaktualisierung eines Lieferanten in `Suppliers` durch, identifiziert über `SupplNr`.\n\n1. Leere Zeichenketten in den meisten Parametern werden in `NULL` umgewandelt. `SupplCtry` wird vorher getrimmt. Ein Parameter mit `NULL` oder Leerwert lässt den gespeicherten Wert unverändert (`ISNULL(neu, alt)`).\n2. Der Lieferant wird über `SupplNr` gesucht. Existiert er nicht, wird eine Fehlerzeile zurückgegeben.\n3. Bei `IsLocked = 1` oder `IsDisabled = 1` ist `SupplierNote` Pflicht. Ist die Notiz angegeben, wird in `SupplierNote` eine Notiz mit dem Titel `Supplier Locked by UserId: {id}` bzw. `Supplier Disabled by UserId: {id}` angelegt. Als Benutzer dient der Pixi-Benutzer `api`, ersatzweise `pixiAdministration`. Sind beide Kennzeichen 1, entstehen zwei Notizen.\n4. Innerhalb einer Transaktion (bzw. eines Savepoints bei bereits offener Transaktion des Aufrufers):\n - Hat der Lieferant noch keine `ContactId`, wird ein leerer `Contact`-Datensatz angelegt und verknüpft.\n - Die Lieferantenfelder werden aktualisiert. `UpdateDate` erhält den aktuellen Zeitpunkt, `UpdateEmp` den Wert `API`.\n - Der verknüpfte Kontakt wird mit den `MainContact_*`-Werten aktualisiert.\n5. Es wird eine Statuszeile mit `RowsAffected`, `ReturnCode`, `Message` und `ErrorMessage` zurückgegeben.\n\n`CanDoDirectFulfillment` akzeptiert `Y`/`N`. Andere Werte lassen das Kennzeichen unverändert. `IsLocked = 0` bzw. `IsDisabled = 0` entsperren bzw. aktivieren den Lieferanten ohne Pflichtnotiz.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer des zu aktualisierenden Lieferanten. Faktisch Pflicht; ohne sie wird eine Fehlerzeile geliefert. |\n| `SupplName` | varchar(60) | Nein | Neuer Lieferantenname (`SupplName`). Leer oder NULL behält den aktuellen Wert. |\n| `SupplNameExt` | varchar(50) | Nein | Namenszusatz (`SupplNameExt`). |\n| `SupplGroup` | varchar(4) | Nein | Lieferantengruppe. Deklariert, aber im Code nicht verwendet. |\n| `DefaultDeliveryDays` | int | Nein | Standard-Lieferzeit in Tagen (`DefaultDeliveryDays`). Der Wert 0 gilt als nicht angegeben. |\n| `SupplFaxNR` | varchar(100) | Nein | Faxnummer (`SupplFaxNr`). |\n| `CustNR` | varchar(20) | Nein | Eigene Kundennummer beim Lieferanten (`CustNr`). |\n| `eMail` | varchar(60) | Nein | Allgemeine E-Mail-Adresse, gespeichert in `MailBox`. |\n| `SupAnrede` | varchar(20) | Nein | Anrede (`SupAnrede`). |\n| `SupName2` | varchar(60) | Nein | Zweite Namenszeile (`SupName2`). |\n| `SupAddress` | varchar(50) | Nein | Straße und Hausnummer (`SupAddress`). |\n| `SupZip` | varchar(20) | Nein | Postleitzahl (`SupZip`). |\n| `SupPhone1` | varchar(50) | Nein | Erste Telefonnummer (`SupPhone1`). |\n| `CanDoDirectFulfillment` | varchar(1) | Nein | Ob der Lieferant Direktversand (Streckengeschäft) durchführen kann. Andere Werte lassen das Kennzeichen unverändert. |\n| `SupCity` | varchar(50) | Nein | Ort (`SupCity`). |\n| `SupPhone2` | varchar(50) | Nein | Zweite Telefonnummer (`SupPhone2`). |\n| `SupplCtry` | varchar(3) | Nein | Ländercode (`SupplCtry`). Führende und nachfolgende Leerzeichen werden entfernt. |\n| `CurrencyId` | smallint | Nein | Währungs-ID des Lieferanten (`CurrencyId`). Der Wert 0 gilt als nicht angegeben. |\n| `eMailSupplOrder` | varchar(255) | Nein | E-Mail-Adresse für Lieferantenbestellungen (`eMailSupplOrder`). |\n| `HomePageUrl` | nvarchar(2000) | Nein | URL der Website (`HomePageUrl`). |\n| `MainContact_Title` | nvarchar(100) | Nein | Titel des Hauptansprechpartners (`Contact.Title`). |\n| `MainContact_FirstName` | nvarchar(20) | Nein | Vorname des Hauptansprechpartners. |\n| `MainContact_LastName` | nvarchar(200) | Nein | Nachname des Hauptansprechpartners. |\n| `MainContact_JobTitle` | nvarchar(200) | Nein | Positionsbezeichnung des Hauptansprechpartners. |\n| `MainContact_JobFunction` | nvarchar(200) | Nein | Funktion des Hauptansprechpartners. |\n| `MainContact_Phone` | varchar(200) | Nein | Telefonnummer des Hauptansprechpartners. |\n| `MainContact_MobilePhone` | varchar(200) | Nein | Mobilnummer des Hauptansprechpartners. |\n| `MainContact_Fax` | nvarchar(200) | Nein | Faxnummer des Hauptansprechpartners. |\n| `MainContact_Email` | nvarchar(200) | Nein | E-Mail-Adresse des Hauptansprechpartners. |\n| `SupplierComment` | varchar(8000) | Nein | Lieferantenkommentar, gespeichert in `SupplComment`. |\n| `SupplierNote` | varchar(8000) | Nein | Text der Lieferantennotiz. Pflicht bei `IsLocked = 1` oder `IsDisabled = 1`, sonst ohne Wirkung. |\n| `IsDisabled` | bit | Nein | Setzt das Kennzeichen `Disabled`. NULL lässt es unverändert. |\n| `IsLocked` | bit | Nein | Setzt das Kennzeichen `Locked`. NULL lässt es unverändert. |\n\n- **Notizen außerhalb der Transaktion:** Das Anlegen der `SupplierNote` beim Sperren oder Deaktivieren erfolgt vor Beginn der Transaktion. Es wird bei einem späteren Fehler im Update nicht zurückgerollt. Es wird auch versucht, wenn der Lieferant nicht existiert; `SupplierId` ist dann `NULL`. Datenbankfehler dieses Inserts werden nicht abgefangen und kommen als `SqlMessage` zurück.\n- **Fehlende `SupplNr`:** Die Meldung für eine leere `SupplNr` wird durch die Meldung \"does not exist\" überschrieben. Diese wird durch Verkettung mit `NULL` selbst `NULL`. Der Aufrufer erhält `ReturnCode = Error` mit leerem bzw. `NULL`-`ErrorMessage`.\n- **Vorrang der Fehler:** Ein Fehler wegen fehlender Notiz beim Sperren oder Deaktivieren überschreibt die Meldung \"does not exist\" in `ErrorMessage`.\n- **Nullwerte:** `DefaultDeliveryDays` und `CurrencyId` werden mit `''` verglichen, was zu 0 konvertiert wird. Der Wert `0` gilt daher als \"nicht angegeben\" und kann nicht gesetzt werden.\n- **Felder lassen sich nicht leeren:** Eine leere Zeichenkette leert kein Feld, da sie als \"keine Änderung\" behandelt wird.\n- **Ungenutzter Parameter:** `SupplGroup` ist deklariert, wird aber nicht verwendet.\n- **Meldungstext:** Die generische Meldung enthält den Tippfehler `conntact`.\n- **Sperrhinweise:** Lesezugriffe nutzen `NOLOCK`, Updates `ROWLOCK`. `XACT_ABORT` ist aktiv. Bei einem abgefangenen Fehler wird die Transaktion bzw. der Savepoint zurückgerollt und eine Fehlerzeile geliefert.\n- **Kontakt-Update:** `RowVersion` des Kontakts wird immer auf 1 gesetzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateSupplier"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Stammdaten, Hauptansprechpartner sowie Sperr- und Deaktivierungskennzeichen eines bestehenden Lieferanten anhand seiner Lieferantennummer.\n\nFührt eine Teilaktualisierung eines Lieferanten in `Suppliers` durch, identifiziert über `SupplNr`.\n\n1. Leere Zeichenketten in den meisten Parametern werden in `NULL` umgewandelt. `SupplCtry` wird vorher getrimmt. Ein Parameter mit `NULL` oder Leerwert lässt den gespeicherten Wert unverändert (`ISNULL(neu, alt)`).\n2. Der Lieferant wird über `SupplNr` gesucht. Existiert er nicht, wird eine Fehlerzeile zurückgegeben.\n3. Bei `IsLocked = 1` oder `IsDisabled = 1` ist `SupplierNote` Pflicht. Ist die Notiz angegeben, wird in `SupplierNote` eine Notiz mit dem Titel `Supplier Locked by UserId: {id}` bzw. `Supplier Disabled by UserId: {id}` angelegt. Als Benutzer dient der Pixi-Benutzer `api`, ersatzweise `pixiAdministration`. Sind beide Kennzeichen 1, entstehen zwei Notizen.\n4. Innerhalb einer Transaktion (bzw. eines Savepoints bei bereits offener Transaktion des Aufrufers):\n - Hat der Lieferant noch keine `ContactId`, wird ein leerer `Contact`-Datensatz angelegt und verknüpft.\n - Die Lieferantenfelder werden aktualisiert. `UpdateDate` erhält den aktuellen Zeitpunkt, `UpdateEmp` den Wert `API`.\n - Der verknüpfte Kontakt wird mit den `MainContact_*`-Werten aktualisiert.\n5. Es wird eine Statuszeile mit `RowsAffected`, `ReturnCode`, `Message` und `ErrorMessage` zurückgegeben.\n\n`CanDoDirectFulfillment` akzeptiert `Y`/`N`. Andere Werte lassen das Kennzeichen unverändert. `IsLocked = 0` bzw. `IsDisabled = 0` entsperren bzw. aktivieren den Lieferanten ohne Pflichtnotiz.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Nein | Lieferantennummer des zu aktualisierenden Lieferanten. Faktisch Pflicht; ohne sie wird eine Fehlerzeile geliefert. |\n| `SupplName` | varchar(60) | Nein | Neuer Lieferantenname (`SupplName`). Leer oder NULL behält den aktuellen Wert. |\n| `SupplNameExt` | varchar(50) | Nein | Namenszusatz (`SupplNameExt`). |\n| `SupplGroup` | varchar(4) | Nein | Lieferantengruppe. Deklariert, aber im Code nicht verwendet. |\n| `DefaultDeliveryDays` | int | Nein | Standard-Lieferzeit in Tagen (`DefaultDeliveryDays`). Der Wert 0 gilt als nicht angegeben. |\n| `SupplFaxNR` | varchar(100) | Nein | Faxnummer (`SupplFaxNr`). |\n| `CustNR` | varchar(20) | Nein | Eigene Kundennummer beim Lieferanten (`CustNr`). |\n| `eMail` | varchar(60) | Nein | Allgemeine E-Mail-Adresse, gespeichert in `MailBox`. |\n| `SupAnrede` | varchar(20) | Nein | Anrede (`SupAnrede`). |\n| `SupName2` | varchar(60) | Nein | Zweite Namenszeile (`SupName2`). |\n| `SupAddress` | varchar(50) | Nein | Straße und Hausnummer (`SupAddress`). |\n| `SupZip` | varchar(20) | Nein | Postleitzahl (`SupZip`). |\n| `SupPhone1` | varchar(50) | Nein | Erste Telefonnummer (`SupPhone1`). |\n| `CanDoDirectFulfillment` | varchar(1) | Nein | Ob der Lieferant Direktversand (Streckengeschäft) durchführen kann. Andere Werte lassen das Kennzeichen unverändert. |\n| `SupCity` | varchar(50) | Nein | Ort (`SupCity`). |\n| `SupPhone2` | varchar(50) | Nein | Zweite Telefonnummer (`SupPhone2`). |\n| `SupplCtry` | varchar(3) | Nein | Ländercode (`SupplCtry`). Führende und nachfolgende Leerzeichen werden entfernt. |\n| `CurrencyId` | smallint | Nein | Währungs-ID des Lieferanten (`CurrencyId`). Der Wert 0 gilt als nicht angegeben. |\n| `eMailSupplOrder` | varchar(255) | Nein | E-Mail-Adresse für Lieferantenbestellungen (`eMailSupplOrder`). |\n| `HomePageUrl` | nvarchar(2000) | Nein | URL der Website (`HomePageUrl`). |\n| `MainContact_Title` | nvarchar(100) | Nein | Titel des Hauptansprechpartners (`Contact.Title`). |\n| `MainContact_FirstName` | nvarchar(20) | Nein | Vorname des Hauptansprechpartners. |\n| `MainContact_LastName` | nvarchar(200) | Nein | Nachname des Hauptansprechpartners. |\n| `MainContact_JobTitle` | nvarchar(200) | Nein | Positionsbezeichnung des Hauptansprechpartners. |\n| `MainContact_JobFunction` | nvarchar(200) | Nein | Funktion des Hauptansprechpartners. |\n| `MainContact_Phone` | varchar(200) | Nein | Telefonnummer des Hauptansprechpartners. |\n| `MainContact_MobilePhone` | varchar(200) | Nein | Mobilnummer des Hauptansprechpartners. |\n| `MainContact_Fax` | nvarchar(200) | Nein | Faxnummer des Hauptansprechpartners. |\n| `MainContact_Email` | nvarchar(200) | Nein | E-Mail-Adresse des Hauptansprechpartners. |\n| `SupplierComment` | varchar(8000) | Nein | Lieferantenkommentar, gespeichert in `SupplComment`. |\n| `SupplierNote` | varchar(8000) | Nein | Text der Lieferantennotiz. Pflicht bei `IsLocked = 1` oder `IsDisabled = 1`, sonst ohne Wirkung. |\n| `IsDisabled` | bit | Nein | Setzt das Kennzeichen `Disabled`. NULL lässt es unverändert. |\n| `IsLocked` | bit | Nein | Setzt das Kennzeichen `Locked`. NULL lässt es unverändert. |\n\n- **Notizen außerhalb der Transaktion:** Das Anlegen der `SupplierNote` beim Sperren oder Deaktivieren erfolgt vor Beginn der Transaktion. Es wird bei einem späteren Fehler im Update nicht zurückgerollt. Es wird auch versucht, wenn der Lieferant nicht existiert; `SupplierId` ist dann `NULL`. Datenbankfehler dieses Inserts werden nicht abgefangen und kommen als `SqlMessage` zurück.\n- **Fehlende `SupplNr`:** Die Meldung für eine leere `SupplNr` wird durch die Meldung \"does not exist\" überschrieben. Diese wird durch Verkettung mit `NULL` selbst `NULL`. Der Aufrufer erhält `ReturnCode = Error` mit leerem bzw. `NULL`-`ErrorMessage`.\n- **Vorrang der Fehler:** Ein Fehler wegen fehlender Notiz beim Sperren oder Deaktivieren überschreibt die Meldung \"does not exist\" in `ErrorMessage`.\n- **Nullwerte:** `DefaultDeliveryDays` und `CurrencyId` werden mit `''` verglichen, was zu 0 konvertiert wird. Der Wert `0` gilt daher als \"nicht angegeben\" und kann nicht gesetzt werden.\n- **Felder lassen sich nicht leeren:** Eine leere Zeichenkette leert kein Feld, da sie als \"keine Änderung\" behandelt wird.\n- **Ungenutzter Parameter:** `SupplGroup` ist deklariert, wird aber nicht verwendet.\n- **Meldungstext:** Die generische Meldung enthält den Tippfehler `conntact`.\n- **Sperrhinweise:** Lesezugriffe nutzen `NOLOCK`, Updates `ROWLOCK`. `XACT_ABORT` ist aktiv. Bei einem abgefangenen Fehler wird die Transaktion bzw. der Savepoint zurückgerollt und eine Fehlerzeile geliefert.\n- **Kontakt-Update:** `RowVersion` des Kontakts wird immer auf 1 gesetzt.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateSupplier"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n 1\n OK\n Supplier with SupplNr: \"L001\" successfully updated.\n \n \n"
}
]
},
{
"name": "pixiUpdateSupplierOrder",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10234\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Status, Notiz für den Lieferanten, externe Bestellnummer und voraussichtliches Lieferdatum einer Lieferantenbestellung anhand ihrer internen Nummer.\n\nÄndert eine Lieferantenbestellung (Bestellung beim Lieferanten), die über `SupplierOrderNR` (die `InternalNumber` der Bestellung) identifiziert wird.\n\n**Ablauf**\n\n1. Leere Zeichenketten in `Status` und `SupplierOrderNRExtdrnal` sowie eine leere `Note` gelten als `NULL` (nicht übergeben).\n2. `UserName` muss als Pixi-Benutzer existieren; andernfalls wird eine `ERROR`-Zeile geliefert und ein SQL-Fehler ausgelöst.\n3. Bestellung und aktueller Status werden gelesen. Wird `Status` nicht übergeben, gilt der aktuelle Statuscode der Bestellung.\n4. Prüfungen (bei einem Fehler wird eine `ERROR`-Zeile geliefert, es wird nichts geändert):\n - die Bestellung muss existieren;\n - `Status` muss `NEW`, `BES`, `CON` oder `CLS` sein;\n - eine abgeschlossene Bestellung (`CLS`) akzeptiert kein neues `EstimatedDeliveryDate` und keine neue `SupplierOrderNRExtdrnal`;\n - eine bestätigte Bestellung (`CON`) akzeptiert keine neue `SupplierOrderNRExtdrnal`;\n - kein Rückwärtswechsel von `CLS` nach `NEW`/`BES`/`CON` und von `CON` nach `NEW` (`CON` → `BES` ist erlaubt);\n - kein Überspringen: `NEW` kann nicht direkt nach `CON` oder `CLS`, `BES` nicht direkt nach `CLS` wechseln.\n5. Der Bestellkopf wird aktualisiert:\n - der Status wird gesetzt (`NEW`=1, `BES`=2, `CON`=3, `CLS`=4);\n - bei `BES` werden Bestelldatum und bestellender Benutzer auf jetzt bzw. den aufrufenden Benutzer gesetzt, bei `CON` Bestätigungsdatum und bestätigender Benutzer;\n - externe Nummer, Notiz für den Lieferanten und voraussichtliches Lieferdatum werden nur überschrieben, wenn ein Wert übergeben wird;\n - Änderungsbenutzer und -zeitpunkt werden gesetzt.\n6. Wird `EstimatedDeliveryDate` übergeben, wird es zusätzlich in **alle** Positionen der Lieferantenbestellung geschrieben.\n7. Hat sich der Status tatsächlich geändert, wird das Ereignis `SupplierOrderStatusChanged` mit der internen Bestell-`Id` veröffentlicht.\n8. Eine Zeile mit `ReturnCode` = `Ok` wird geliefert und die Transaktion festgeschrieben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplierOrderNR` | int | Ja | Interne Nummer (`InternalNumber`) der zu ändernden Lieferantenbestellung. |\n| `Status` | varchar(3) | Nein | Neuer Statuscode. Fehlt der Wert oder ist er leer, bleibt der aktuelle Status erhalten (und wird erneut angewendet). |\n| `Note` | text | Nein | Notiz für den Lieferanten (`NoteForSupplier`). Ersetzt die gespeicherte Notiz, wenn nicht leer. |\n| `EstimatedDeliveryDate` | datetime | Nein | Voraussichtliches Lieferdatum; wird in den Bestellkopf und alle Positionen geschrieben. Bei abgeschlossenen Bestellungen nicht erlaubt. |\n| `SupplierOrderNRExtdrnal` | varchar(25) | Nein | Externe Bestellnummer des Lieferanten (`ExternalCode`). Bei bestätigten oder abgeschlossenen Bestellungen nicht erlaubt. |\n| `UserName` | varchar(50) | Nein | Pixi-Benutzername, der als ändernder (und bestellender/bestätigender) Benutzer gespeichert wird. Muss existieren. |\n\n- **Stolperfalle – Datumswerte werden zurückgesetzt:** Da ein nicht übergebener `Status` auf den aktuellen Status zurückfällt, setzt jeder Aufruf bei einer Bestellung im Status `BES` `OrderDate`/`OrderedByUserId` erneut auf jetzt bzw. den aufrufenden Benutzer; bei Status `CON` gilt dasselbe für `ConfirmationDate`/`ConfirmedByUserId`. Das gilt auch, wenn nur Notiz oder Lieferdatum geändert werden.\n- Felder können nicht geleert werden: ein leerer oder fehlender Wert behält den gespeicherten Wert. Ein `EstimatedDeliveryDate` von `1900-01-01` gilt als nicht übergeben.\n- Die Notiz wird auch bei abgeschlossenen Bestellungen akzeptiert; gesperrt sind nur Lieferdatum und externe Nummer.\n- Laut Code-Kommentar kann `NEW` nicht erneut gesetzt werden, der Code sperrt `NEW` jedoch nur aus `CON`/`CLS`; ein Wechsel `BES` → `NEW` wird akzeptiert.\n- `SupplierOrderNRExtdrnal` ist durch den Parametertyp auf 25 Zeichen begrenzt. Die Notiz wird in einer Nicht-Unicode-Spalte gespeichert; Zeichen außerhalb der Codepage der Datenbank können verloren gehen.\n- Die Status-IDs 1–4 sind in der Prozedur fest hinterlegt.\n- Wegen der Operatorrangfolge in der Prüfung kann eine Fehlermeldung zum Rückwärts-/Überspringen-Wechsel eine frühere Prüfmeldung überschreiben; der Aufruf schlägt in beiden Fällen fehl.\n- Läuft in einer eigenen Transaktion (bzw. einem Savepoint bei äußerer Transaktion). Fehler werden abgefangen, zurückgerollt und ins Fehlerprotokoll geschrieben; außer bei der Benutzerprüfung wird kein SQL-Fehler ausgelöst, nur die `ERROR`-Zeile geliefert. Innerhalb einer äußeren Transaktion wird keine `Ok`-Zeile geliefert und nicht festgeschrieben.\n- Das erste Lesen der Bestellung erfolgt mit `NOLOCK`.\n- Das Ereignis zur Statusänderung wird über `Pixi_MQ_EventPublish` veröffentlicht; ob tatsächlich eine Nachricht versendet wird, hängt von der Einstellung `pixiMQ_Enabled` und der Ereigniskonfiguration ab.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateSupplierOrder"
},
"response": [
{
"name": "Example",
"originalRequest": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": {
"mode": "raw",
"raw": "\n\n \n \n 10234\n \n \n \n \n \n \n \n\n",
"options": {
"raw": {
"language": "xml"
}
}
},
"url": {
"raw": "{{baseUrl}}",
"host": [
"{{baseUrl}}"
]
},
"description": "Aktualisiert Status, Notiz für den Lieferanten, externe Bestellnummer und voraussichtliches Lieferdatum einer Lieferantenbestellung anhand ihrer internen Nummer.\n\nÄndert eine Lieferantenbestellung (Bestellung beim Lieferanten), die über `SupplierOrderNR` (die `InternalNumber` der Bestellung) identifiziert wird.\n\n**Ablauf**\n\n1. Leere Zeichenketten in `Status` und `SupplierOrderNRExtdrnal` sowie eine leere `Note` gelten als `NULL` (nicht übergeben).\n2. `UserName` muss als Pixi-Benutzer existieren; andernfalls wird eine `ERROR`-Zeile geliefert und ein SQL-Fehler ausgelöst.\n3. Bestellung und aktueller Status werden gelesen. Wird `Status` nicht übergeben, gilt der aktuelle Statuscode der Bestellung.\n4. Prüfungen (bei einem Fehler wird eine `ERROR`-Zeile geliefert, es wird nichts geändert):\n - die Bestellung muss existieren;\n - `Status` muss `NEW`, `BES`, `CON` oder `CLS` sein;\n - eine abgeschlossene Bestellung (`CLS`) akzeptiert kein neues `EstimatedDeliveryDate` und keine neue `SupplierOrderNRExtdrnal`;\n - eine bestätigte Bestellung (`CON`) akzeptiert keine neue `SupplierOrderNRExtdrnal`;\n - kein Rückwärtswechsel von `CLS` nach `NEW`/`BES`/`CON` und von `CON` nach `NEW` (`CON` → `BES` ist erlaubt);\n - kein Überspringen: `NEW` kann nicht direkt nach `CON` oder `CLS`, `BES` nicht direkt nach `CLS` wechseln.\n5. Der Bestellkopf wird aktualisiert:\n - der Status wird gesetzt (`NEW`=1, `BES`=2, `CON`=3, `CLS`=4);\n - bei `BES` werden Bestelldatum und bestellender Benutzer auf jetzt bzw. den aufrufenden Benutzer gesetzt, bei `CON` Bestätigungsdatum und bestätigender Benutzer;\n - externe Nummer, Notiz für den Lieferanten und voraussichtliches Lieferdatum werden nur überschrieben, wenn ein Wert übergeben wird;\n - Änderungsbenutzer und -zeitpunkt werden gesetzt.\n6. Wird `EstimatedDeliveryDate` übergeben, wird es zusätzlich in **alle** Positionen der Lieferantenbestellung geschrieben.\n7. Hat sich der Status tatsächlich geändert, wird das Ereignis `SupplierOrderStatusChanged` mit der internen Bestell-`Id` veröffentlicht.\n8. Eine Zeile mit `ReturnCode` = `Ok` wird geliefert und die Transaktion festgeschrieben.\n\n| Parameter | Typ | Pflicht | Beschreibung |\n| --- | --- | --- | --- |\n| `SupplierOrderNR` | int | Ja | Interne Nummer (`InternalNumber`) der zu ändernden Lieferantenbestellung. |\n| `Status` | varchar(3) | Nein | Neuer Statuscode. Fehlt der Wert oder ist er leer, bleibt der aktuelle Status erhalten (und wird erneut angewendet). |\n| `Note` | text | Nein | Notiz für den Lieferanten (`NoteForSupplier`). Ersetzt die gespeicherte Notiz, wenn nicht leer. |\n| `EstimatedDeliveryDate` | datetime | Nein | Voraussichtliches Lieferdatum; wird in den Bestellkopf und alle Positionen geschrieben. Bei abgeschlossenen Bestellungen nicht erlaubt. |\n| `SupplierOrderNRExtdrnal` | varchar(25) | Nein | Externe Bestellnummer des Lieferanten (`ExternalCode`). Bei bestätigten oder abgeschlossenen Bestellungen nicht erlaubt. |\n| `UserName` | varchar(50) | Nein | Pixi-Benutzername, der als ändernder (und bestellender/bestätigender) Benutzer gespeichert wird. Muss existieren. |\n\n- **Stolperfalle – Datumswerte werden zurückgesetzt:** Da ein nicht übergebener `Status` auf den aktuellen Status zurückfällt, setzt jeder Aufruf bei einer Bestellung im Status `BES` `OrderDate`/`OrderedByUserId` erneut auf jetzt bzw. den aufrufenden Benutzer; bei Status `CON` gilt dasselbe für `ConfirmationDate`/`ConfirmedByUserId`. Das gilt auch, wenn nur Notiz oder Lieferdatum geändert werden.\n- Felder können nicht geleert werden: ein leerer oder fehlender Wert behält den gespeicherten Wert. Ein `EstimatedDeliveryDate` von `1900-01-01` gilt als nicht übergeben.\n- Die Notiz wird auch bei abgeschlossenen Bestellungen akzeptiert; gesperrt sind nur Lieferdatum und externe Nummer.\n- Laut Code-Kommentar kann `NEW` nicht erneut gesetzt werden, der Code sperrt `NEW` jedoch nur aus `CON`/`CLS`; ein Wechsel `BES` → `NEW` wird akzeptiert.\n- `SupplierOrderNRExtdrnal` ist durch den Parametertyp auf 25 Zeichen begrenzt. Die Notiz wird in einer Nicht-Unicode-Spalte gespeichert; Zeichen außerhalb der Codepage der Datenbank können verloren gehen.\n- Die Status-IDs 1–4 sind in der Prozedur fest hinterlegt.\n- Wegen der Operatorrangfolge in der Prüfung kann eine Fehlermeldung zum Rückwärts-/Überspringen-Wechsel eine frühere Prüfmeldung überschreiben; der Aufruf schlägt in beiden Fällen fehl.\n- Läuft in einer eigenen Transaktion (bzw. einem Savepoint bei äußerer Transaktion). Fehler werden abgefangen, zurückgerollt und ins Fehlerprotokoll geschrieben; außer bei der Benutzerprüfung wird kein SQL-Fehler ausgelöst, nur die `ERROR`-Zeile geliefert. Innerhalb einer äußeren Transaktion wird keine `Ok`-Zeile geliefert und nicht festgeschrieben.\n- Das erste Lesen der Bestellung erfolgt mit `NOLOCK`.\n- Das Ereignis zur Statusänderung wird über `Pixi_MQ_EventPublish` veröffentlicht; ob tatsächlich eine Nachricht versendet wird, hängt von der Einstellung `pixiMQ_Enabled` und der Ereigniskonfiguration ab.\n\nDokumentation: https://pixi-api-docs.de/de/api/pixiUpdateSupplierOrder"
},
"status": "OK",
"code": 200,
"_postman_previewlanguage": "xml",
"header": [
{
"key": "Content-Type",
"value": "text/xml; charset=utf-8"
}
],
"body": "\n \n Ok\n Supplier Order with SupplierOrderNR 10234 updated.\n \n"
}
]
}
]
}
]
}