{
"info": {
"name": "Pixi SOAP API",
"description": "Unofficial collection of all Pixi SOAP calls. Set the variables `username` and `password` (Basic Auth) before sending a request. Documentation: https://pixi-api-docs.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": "Sets the comment field `CHisNote` of a customer identified by its external customer number and returns 1 on success or 0 if no customer was found.\n\nWrites a comment into the `CHisNote` column of a customer record.\n\n1. The call checks whether a customer exists in `Customers` with `CustomerNrExternal` = `CustomerNrExternal`.\n2. If `ShopID` is passed, only customers with `CustomerOf` = `ShopID` are considered. If `ShopID` is omitted (`NULL`), the shop is not checked.\n3. If no matching customer exists, the call returns one row with `ReturnMessage` = `0`. Nothing is changed.\n4. Otherwise `CHisNote` of **all** matching customers is set to `Comment` and the call returns one row with `ReturnMessage` = `1`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustomerNrExternal` | varchar(250) | Yes | External customer number (`Customers.CustomerNrExternal`) of the customer to update. |\n| `Comment` | ntext | Yes | Comment text. It replaces the current content of `CHisNote`. |\n| `ShopID` | varchar(3) | No | Optional shop ID (`Customers.CustomerOf`). If set, only customers of this shop are matched. If `NULL`, customers of all shops are matched. |\n\n- Despite the call name and the header comment (\"create a manual booking event\"), the code does not add a new entry. It **overwrites** the existing content of `CHisNote`. A previous comment is lost unless the caller includes it in `Comment`.\n- If `ShopID` is omitted and the same external customer number exists in several shops, the comment is written to all of these customers.\n- The existence check reads with `NOLOCK`. The check and the update do not run in an explicit transaction.\n- If the customer exists but `Comment` is omitted, `CHisNote` is set to `NULL`, because `Comment` has no default value.\n\nDocumentation: https://pixi-api-docs.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": "Sets the comment field `CHisNote` of a customer identified by its external customer number and returns 1 on success or 0 if no customer was found.\n\nWrites a comment into the `CHisNote` column of a customer record.\n\n1. The call checks whether a customer exists in `Customers` with `CustomerNrExternal` = `CustomerNrExternal`.\n2. If `ShopID` is passed, only customers with `CustomerOf` = `ShopID` are considered. If `ShopID` is omitted (`NULL`), the shop is not checked.\n3. If no matching customer exists, the call returns one row with `ReturnMessage` = `0`. Nothing is changed.\n4. Otherwise `CHisNote` of **all** matching customers is set to `Comment` and the call returns one row with `ReturnMessage` = `1`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustomerNrExternal` | varchar(250) | Yes | External customer number (`Customers.CustomerNrExternal`) of the customer to update. |\n| `Comment` | ntext | Yes | Comment text. It replaces the current content of `CHisNote`. |\n| `ShopID` | varchar(3) | No | Optional shop ID (`Customers.CustomerOf`). If set, only customers of this shop are matched. If `NULL`, customers of all shops are matched. |\n\n- Despite the call name and the header comment (\"create a manual booking event\"), the code does not add a new entry. It **overwrites** the existing content of `CHisNote`. A previous comment is lost unless the caller includes it in `Comment`.\n- If `ShopID` is omitted and the same external customer number exists in several shops, the comment is written to all of these customers.\n- The existence check reads with `NOLOCK`. The check and the update do not run in an explicit transaction.\n- If the customer exists but `Comment` is omitted, `CHisNote` is set to `NULL`, because `Comment` has no default value.\n\nDocumentation: https://pixi-api-docs.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": "Returns pairs of potentially duplicate customer addresses from the duplicate check, with address, order, invoice and customer details for both sides.\n\nReads the results of a previous duplicate check from `Addresses_Duplicates`. Each record there links two addresses (`AddrRef1`/`AddrRef2`) and two customers (`CustRef1`/`CustRef2`) together with a match level and a match text.\n\nFor each pair the call returns:\n- match level and match text,\n- name, company (`CareOf`), street, house number, city, ZIP and country of both addresses,\n- the number of invoices and the date of the latest invoice (`LastDelivery1`/`2`) for each customer,\n- the external customer number and the DATEV account number of both customers,\n- order number and order status of the orders that use each address,\n- `NrOfRecords`, the total number of unused duplicate records.\n\nFiltering:\n- Only records with `CustRef1` greater than `StartCustRef` are returned. A `NULL` value is treated as `0`.\n- With `ShowUsed` = `0` only records whose `UsedFlag` is `0` or `NULL` are returned. With `ShowUsed` = `1` all records are returned, including those already processed.\n- `RowCount` limits the number of returned rows through `SET ROWCOUNT`.\n\nRows are sorted by `CustRef1` ascending. For paging, pass the highest returned `CustRef1` as `StartCustRef` of the next call.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartCustRef` | int | No | Only records with `CustRef1` greater than this value are returned. Used for paging. `NULL` is treated as `0`. |\n| `ShowUsed` | bit | No | Controls whether duplicate records that are already marked as used are included. |\n| `RowCount` | int | No | Maximum number of rows returned (applied with `SET ROWCOUNT`). `0` means no limit. |\n\n- All tables are read with `NOLOCK`, so uncommitted data can appear.\n- Addresses are joined to `OrderHeader` with inner joins. A pair is only returned if both addresses are used by at least one Auftrag, and a pair produces one row for every combination of orders of address 1 and orders of address 2. Rows are therefore not unique per duplicate record.\n- Because one `CustRef1` can produce several rows, a page limited by `RowCount` can end in the middle of a `CustRef1`. Continuing with that `CustRef1` as `StartCustRef` skips the remaining rows of it.\n- `RowCount` = `0` turns the limit off (`SET ROWCOUNT 0`).\n- `NrOfRecords` is the same in every row. It counts all unused records whose two customers exist and ignores `StartCustRef`, `ShowUsed` and the order join, so it can differ from the number of rows that can actually be fetched.\n- `CustKeyMatchedTo` is `NULL` when `ShowUsed` = `0`. Otherwise it always equals the key of customer 1 (`CustRef1`), because customer 1 is joined with an inner join.\n- The call only displays data. It does not merge customers or set `UsedFlag`. How `Addresses_Duplicates` is filled is not visible in this code.\n\nDocumentation: https://pixi-api-docs.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": "Returns pairs of potentially duplicate customer addresses from the duplicate check, with address, order, invoice and customer details for both sides.\n\nReads the results of a previous duplicate check from `Addresses_Duplicates`. Each record there links two addresses (`AddrRef1`/`AddrRef2`) and two customers (`CustRef1`/`CustRef2`) together with a match level and a match text.\n\nFor each pair the call returns:\n- match level and match text,\n- name, company (`CareOf`), street, house number, city, ZIP and country of both addresses,\n- the number of invoices and the date of the latest invoice (`LastDelivery1`/`2`) for each customer,\n- the external customer number and the DATEV account number of both customers,\n- order number and order status of the orders that use each address,\n- `NrOfRecords`, the total number of unused duplicate records.\n\nFiltering:\n- Only records with `CustRef1` greater than `StartCustRef` are returned. A `NULL` value is treated as `0`.\n- With `ShowUsed` = `0` only records whose `UsedFlag` is `0` or `NULL` are returned. With `ShowUsed` = `1` all records are returned, including those already processed.\n- `RowCount` limits the number of returned rows through `SET ROWCOUNT`.\n\nRows are sorted by `CustRef1` ascending. For paging, pass the highest returned `CustRef1` as `StartCustRef` of the next call.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartCustRef` | int | No | Only records with `CustRef1` greater than this value are returned. Used for paging. `NULL` is treated as `0`. |\n| `ShowUsed` | bit | No | Controls whether duplicate records that are already marked as used are included. |\n| `RowCount` | int | No | Maximum number of rows returned (applied with `SET ROWCOUNT`). `0` means no limit. |\n\n- All tables are read with `NOLOCK`, so uncommitted data can appear.\n- Addresses are joined to `OrderHeader` with inner joins. A pair is only returned if both addresses are used by at least one Auftrag, and a pair produces one row for every combination of orders of address 1 and orders of address 2. Rows are therefore not unique per duplicate record.\n- Because one `CustRef1` can produce several rows, a page limited by `RowCount` can end in the middle of a `CustRef1`. Continuing with that `CustRef1` as `StartCustRef` skips the remaining rows of it.\n- `RowCount` = `0` turns the limit off (`SET ROWCOUNT 0`).\n- `NrOfRecords` is the same in every row. It counts all unused records whose two customers exist and ignores `StartCustRef`, `ShowUsed` and the order join, so it can differ from the number of rows that can actually be fetched.\n- `CustKeyMatchedTo` is `NULL` when `ShowUsed` = `0`. Otherwise it always equals the key of customer 1 (`CustRef1`), because customer 1 is joined with an inner join.\n- The call only displays data. It does not merge customers or set `UsedFlag`. How `Addresses_Duplicates` is filled is not visible in this code.\n\nDocumentation: https://pixi-api-docs.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": "Marks a stored pair of potential duplicate customers as used by setting `UsedFlag` = 1 in the duplicates list.\n\nFlags an entry of the address duplicates list (`Addresses_Duplicates`) as used.\n\n1. The call checks whether at least one row exists with `CustRef1` = `@CustRef1` and `CustRef2` = `@CustRef2`.\n2. If no such row exists, a status row with `ReturnCode` = `ERROR` is returned and nothing is changed.\n3. Otherwise `UsedFlag` is set to `1` on **all** rows matching this pair, and a status row with `ReturnCode` = `OK` is returned.\n\nThe pair is matched in the exact order given: `CustRef1`/`CustRef2` are not swapped, so a pair stored as (B, A) is not found when calling with (A, B).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustRef1` | int | Yes | Reference of the first customer of the duplicate pair, compared with `Addresses_Duplicates.CustRef1`. |\n| `CustRef2` | int | Yes | Reference of the second customer of the duplicate pair, compared with `Addresses_Duplicates.CustRef2`. |\n\n- The existence check reads with `NOLOCK`; check and update are not wrapped in a transaction.\n- The error text \"At least one customers not existing\" is misleading: it is returned when the duplicate pair is not in `Addresses_Duplicates`, not after checking the customer table.\n- Calling the procedure again for an already flagged pair returns `OK` again (idempotent).\n- The status text is always in the column `ErrorMessage`, also on success.\n\nDocumentation: https://pixi-api-docs.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": "Marks a stored pair of potential duplicate customers as used by setting `UsedFlag` = 1 in the duplicates list.\n\nFlags an entry of the address duplicates list (`Addresses_Duplicates`) as used.\n\n1. The call checks whether at least one row exists with `CustRef1` = `@CustRef1` and `CustRef2` = `@CustRef2`.\n2. If no such row exists, a status row with `ReturnCode` = `ERROR` is returned and nothing is changed.\n3. Otherwise `UsedFlag` is set to `1` on **all** rows matching this pair, and a status row with `ReturnCode` = `OK` is returned.\n\nThe pair is matched in the exact order given: `CustRef1`/`CustRef2` are not swapped, so a pair stored as (B, A) is not found when calling with (A, B).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustRef1` | int | Yes | Reference of the first customer of the duplicate pair, compared with `Addresses_Duplicates.CustRef1`. |\n| `CustRef2` | int | Yes | Reference of the second customer of the duplicate pair, compared with `Addresses_Duplicates.CustRef2`. |\n\n- The existence check reads with `NOLOCK`; check and update are not wrapped in a transaction.\n- The error text \"At least one customers not existing\" is misleading: it is returned when the duplicate pair is not in `Addresses_Duplicates`, not after checking the customer table.\n- Calling the procedure again for an already flagged pair returns `OK` again (idempotent).\n- The status text is always in the column `ErrorMessage`, also on success.\n\nDocumentation: https://pixi-api-docs.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": "Finds probable duplicate customers by fuzzy address matching in batches of 2500 addresses and stores scored customer pairs in Addresses_Duplicates.\n\nBatch job that detects duplicate customers by comparing their addresses. It returns no result set. It writes its findings to the table `Addresses_Duplicates`.\n\n**Time window**\n\nThe procedure only works between 21:00 and 06:59 server time. If the current hour is between 7 and 20, it prints a message and ends without doing anything. The only exception is a session whose `CONTEXT_INFO` is `0x00999`, which is used for unit tests.\n\n**Steps**\n\n1. Creates the helper tables `tmp.Addresses_Process` and `tmp.Addresses_Simple` if they do not exist yet.\n2. If `ReCreateAll` = 1, empties `Addresses_Duplicates`, `tmp.Addresses_Simple` and `tmp.Addresses_Process` with `TRUNCATE`. All existing matches are deleted.\n3. Selects up to 2500 customer main addresses (`Customers.AddrRef`) as candidates, newest address key first. A candidate must meet all of these conditions:\n - It is not yet in `tmp.Addresses_Simple`.\n - Its key is above the highest or below the lowest key already processed.\n - The customer has no order with an order header attribute of type 3 (archived orders).\n4. Removes titles from the names: `Frau`, `Herr`, `Prof.`, `Dipl.`, `Ing.`, `Mag.`, `med.`, `Dr.`. If the last name is empty, the field `Name` is split at the first space into first name and last name.\n5. Stores a simplified copy of each address in `tmp.Addresses_Simple`:\n - the first 3 characters of `SOUNDEX` for street, city, last name, first name and CareOf (company);\n - the cross sum of the ZIP code (`fCrossSum`);\n - address, customer and shop ID.\n6. Marks up to 2500 of these addresses as processed in `tmp.Addresses_Process`, newest first.\n7. Compares the newly processed addresses with all simplified addresses. A pair counts as a match if all of these conditions hold:\n - different customer;\n - same shop;\n - same soundex code for city, street and CareOf;\n - same ZIP cross sum;\n - same soundex codes for first and last name, also when first and last name are swapped.\n\n A customer is skipped if it already appears as `CustRef1` or `CustRef2` in `Addresses_Duplicates`.\n8. Gives each pair a score (`MatchLevel`). The score is the sum of these parts:\n - name: 40 full, 30 swapped, 20 soundex match, 10 weak match or different first name;\n - street: 20 full, 10 partial, 5 weak;\n - city: 20 full, 10 partial, 5 weak;\n - ZIP: 20 full, 10 same cross sum;\n - company (CareOf): 0 full, -10 partial, -15 weak.\n\n `MatchText` lists the non-full match flags, for example `STREET_PARTIAL_MATCH;`, cut to 100 characters.\n9. Inserts each new pair once. `CustRef1`/`AddrRef1` is the newly processed customer and `CustRef2`/`AddrRef2` is the matched customer. Pairs that already exist in either direction are skipped.\n10. If `tmp.Addresses_Simple` still contains addresses that are not in `tmp.Addresses_Process`, the procedure queues `EXEC pipiAddressesFindDuplicates` in `ExecQueries`. In this way the run continues in the next batch.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ReCreateAll` | bit | No | If 1, deletes all existing duplicate matches and the progress tables and starts the matching from scratch. This is effective only inside the nightly time window. |\n\n- **No result set:** the call returns no rows. Informational output comes only via `PRINT`, for example `RUN BEFORE 07:00 or AFTER 20:00` during the day. These messages may appear as `SqlMessage` entries, depending on the client. A daytime call therefore looks successful but does nothing.\n- **ReCreateAll in the daytime:** the truncation for `ReCreateAll` = 1 happens only after the time check. During the day the parameter has no effect.\n- **Continuation:** the follow-up run is queued in `ExecQueries`. How and when that queue is executed is not part of this code. A comment speaks of \"1 minute\" and of runs until 7 AM. The batch size is 2500 addresses, although a comment mentions 100.\n- **Permanent helper tables:** the procedure creates and fills the permanent tables `tmp.Addresses_Simple` and `tmp.Addresses_Process` to remember its progress between runs.\n- **No transaction:** all reads use `NOLOCK` and there is no explicit transaction.\n- **Pitfalls visible in the code:**\n - The partial checks for street and city compare an address with itself. Whenever street or city do not match exactly, the result is therefore always `STREET_PARTIAL_MATCH;` or `CITY_PARTIAL_MATCH;`. The `_LOW` variants never occur.\n - Pairs are numbered per sum of the two customer IDs (`s.CustRef + c.CustRef`). Different pairs whose IDs add up to the same value can therefore be dropped, because only the first one is kept.\n - If the names match only in swapped soundex form but not exactly swapped, the name category is empty. `MatchLevel` and `MatchText` then become NULL.\n- **Runtime:** matching is CPU-intensive. A code comment warns not to increase the batch size.\n\nDocumentation: https://pixi-api-docs.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": "Returns all customer account events (bookings, including deleted ones) of a customer together with the customer's account statistics such as balance and suggested refund.\n\nLists the customer account (Kundenkonto) of one customer.\n\n**Identifying the customer**\n- Pass `CustRef` (the internal customer key), **or**\n- pass both `ShopID` and `CustNrExt` (the external customer number in that shop). The procedure then looks up `CustKey` in `Customers` where `CustomerOf` = `ShopID` and `CustomerNrExternal` = `CustNrExt`.\n- If `CustRef` is empty or 0 and one of `ShopID`/`CustNrExt` is missing, an error is raised.\n- If `CustRef` is given, `ShopID` and `CustNrExt` are ignored.\n\n**Events**\nAll account events of the customer are collected (no filter, translations in language 1):\n- active bookings from `CustomerAccount` (`IsDeleted` = 0),\n- deleted bookings from `CustomerAccountLog` with history remark `DELETE` (`IsDeleted` = 1).\n\n`Number` is the invoice number, bank line text, direct debit account number or manual booking reference, depending on what the event refers to. `OpenTOMatch` is `Amount` minus the matched amount.\n\n**Statistics**\nThe account statistics (balance, open orders, suggested refund, matched flag, account currency) are calculated per customer and joined to every event row.\n\n**Result**\nOne row per event, each carrying the same statistics columns. If the customer has no events, a single row with only the statistics columns filled is returned (event columns, including `CustRef`, are NULL).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustRef` | int | No | Internal customer key (`CustKey`). If given (not 0), it takes precedence over `ShopID`/`CustNrExt`. |\n| `CustNrExt` | varchar(60) | No | External customer number (`CustomerNrExternal`). Only used together with `ShopID` when `CustRef` is not given. |\n| `ShopID` | varchar(3) | No | Shop the customer belongs to (`CustomerOf`). Only used together with `CustNrExt` when `CustRef` is not given. |\n\n- Read-only; all permanent tables are read with `NOLOCK`, so uncommitted data may appear.\n- The final `SELECT` has no `ORDER BY`; the events are produced in ascending `EventDate` order by the helper procedure, but the order of the returned rows is not guaranteed.\n- If `ShopID`/`CustNrExt` do not match a customer, no customer key is found; the result then depends on the statistics procedure `Pixi_CA_GetCustomerAccountSummary` (not attached) and is typically empty.\n- The statistics temp table has a unique index on `CustRef`. If the summary returns more than one row per customer (e.g. several currencies), the insert fails with a duplicate key error.\n- The column `DoNotRefund` is the per-event flag, not the do-not-refund total of the statistics.\n- Currency conversion of the statistics depends on the setting `MultiCurrencyEnabled`; `AccountCurrencyCode` may be the order or the base currency.\n- Column names `IsAcountMatched` and `SuggestedRefound` are spelled exactly like this.\n\nDocumentation: https://pixi-api-docs.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": "Returns all customer account events (bookings, including deleted ones) of a customer together with the customer's account statistics such as balance and suggested refund.\n\nLists the customer account (Kundenkonto) of one customer.\n\n**Identifying the customer**\n- Pass `CustRef` (the internal customer key), **or**\n- pass both `ShopID` and `CustNrExt` (the external customer number in that shop). The procedure then looks up `CustKey` in `Customers` where `CustomerOf` = `ShopID` and `CustomerNrExternal` = `CustNrExt`.\n- If `CustRef` is empty or 0 and one of `ShopID`/`CustNrExt` is missing, an error is raised.\n- If `CustRef` is given, `ShopID` and `CustNrExt` are ignored.\n\n**Events**\nAll account events of the customer are collected (no filter, translations in language 1):\n- active bookings from `CustomerAccount` (`IsDeleted` = 0),\n- deleted bookings from `CustomerAccountLog` with history remark `DELETE` (`IsDeleted` = 1).\n\n`Number` is the invoice number, bank line text, direct debit account number or manual booking reference, depending on what the event refers to. `OpenTOMatch` is `Amount` minus the matched amount.\n\n**Statistics**\nThe account statistics (balance, open orders, suggested refund, matched flag, account currency) are calculated per customer and joined to every event row.\n\n**Result**\nOne row per event, each carrying the same statistics columns. If the customer has no events, a single row with only the statistics columns filled is returned (event columns, including `CustRef`, are NULL).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustRef` | int | No | Internal customer key (`CustKey`). If given (not 0), it takes precedence over `ShopID`/`CustNrExt`. |\n| `CustNrExt` | varchar(60) | No | External customer number (`CustomerNrExternal`). Only used together with `ShopID` when `CustRef` is not given. |\n| `ShopID` | varchar(3) | No | Shop the customer belongs to (`CustomerOf`). Only used together with `CustNrExt` when `CustRef` is not given. |\n\n- Read-only; all permanent tables are read with `NOLOCK`, so uncommitted data may appear.\n- The final `SELECT` has no `ORDER BY`; the events are produced in ascending `EventDate` order by the helper procedure, but the order of the returned rows is not guaranteed.\n- If `ShopID`/`CustNrExt` do not match a customer, no customer key is found; the result then depends on the statistics procedure `Pixi_CA_GetCustomerAccountSummary` (not attached) and is typically empty.\n- The statistics temp table has a unique index on `CustRef`. If the summary returns more than one row per customer (e.g. several currencies), the insert fails with a duplicate key error.\n- The column `DoNotRefund` is the per-event flag, not the do-not-refund total of the statistics.\n- Currency conversion of the statistics depends on the setting `MultiCurrencyEnabled`; `AccountCurrencyCode` may be the order or the base currency.\n- Column names `IsAcountMatched` and `SuggestedRefound` are spelled exactly like this.\n\nDocumentation: https://pixi-api-docs.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": "Updates the invoice due days and reminder (dunning) settings of one customer identified by CustKey or by external customer number/email plus shop.\n\nChanges the payment and reminder settings of exactly one customer record in `Customers`.\n\n**Identifying the customer**\n\n- Pass `CustKey`, **or** pass `ShopId` together with `CustomerNrExternal` and/or `CustomerEmail`.\n- `CustomerNrExternal`, `CustomerEmail` and `ReminderAction` are trimmed; empty strings count as not provided.\n- The lookup matches customers where (`CustomerNrExternal` matches **or** `CeMail` matches `CustomerEmail`) and `CustomerOf` = `ShopId`, **or** where `CustKey` matches.\n- If no customer matches, or more than one customer matches, the call fails.\n\n**Validation**\n\n- `ReminderAction` must be one of `NONE`, `PRINT`, `MAIL`, `PRINT&MAIL` or `0`.\n- `InvoiceDueDays`, `DaysForFirstReminder`, `DaysForNextReminder`, `ReminderDueDays` and `ReminderCost` must not be negative.\n\n**How values are applied**\n\n- A parameter that is omitted (NULL) keeps the value currently stored for the customer.\n- A value of `0` (or `'0'` for `ReminderAction`) clears the setting, i.e. it is stored as NULL (option disabled).\n- Any other value overwrites the stored value.\n\nThe update also sets `UpdateDate` to the current date/time and `UpdateEmp` to `API-CustomerInfoSet`.\n\nThe call always returns one status row with `Status` (`OK` or `ERROR`) and `StatusMessage`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | No | Internal Pixi customer key. Identifies the customer on its own; alternatively use `ShopId` with `CustomerNrExternal`/`CustomerEmail`. |\n| `CustomerNrExternal` | varchar(60) | No | External (shop) customer number, matched against `CustomerNrExternal` of customers of `ShopId`. Trimmed; empty means not provided. |\n| `CustomerEmail` | varchar(256) | No | Customer email address, matched against `CeMail` of customers of `ShopId`. Trimmed; empty means not provided. |\n| `ShopId` | varchar(3) | No | Shop the customer belongs to (`CustomerOf`). Required when the customer is identified by `CustomerNrExternal` or `CustomerEmail`. |\n| `InvoiceDueDays` | smallint | No | Payment term of invoices in days. NULL keeps the current value, 0 clears it, negative values are rejected. |\n| `ReminderAction` | varchar(20) | No | How reminders are sent to the customer. NULL or empty keeps the current value. |\n| `DaysForFirstReminder` | smallint | No | Days that must pass before the first reminder. NULL keeps the current value, 0 clears it, negative values are rejected. |\n| `DaysForNextReminder` | smallint | No | Days until the next reminder. NULL keeps the current value, 0 clears it, negative values are rejected. |\n| `ReminderDueDays` | smallint | No | Payment term printed on reminders, in days. NULL keeps the current value, 0 clears it, negative values are rejected. |\n| `ReminderCost` | money | No | Fee charged per reminder. NULL keeps the current value, 0 clears it (stored as NULL), negative values are rejected. |\n\n- All validation errors are raised inside a `TRY` block and caught; they are returned as a status row with `Status` = `ERROR`, not as a `SqlMessage`. Only the first failing check is reported.\n- The procedure's return value is `0` on success and `1` on error; SOAP clients should evaluate the `Status` column.\n- The candidate lookup reads `Customers` with `NOLOCK`. There is no explicit transaction around lookup and update.\n- Pitfall: the search conditions are combined with `OR`. If `CustKey` is passed together with `ShopId` and `CustomerNrExternal`/`CustomerEmail`, or if both `CustomerNrExternal` and `CustomerEmail` are passed and point to different customers, several records can match and the call fails with \"More than one customer found\". Pass only one identifier for a reliable result.\n- `ShopId` is not trimmed, unlike the other identifiers.\n- `NONE` and `0` differ for `ReminderAction`: `NONE` stores the value `NONE`, `0` stores NULL. Whether the value check is case-sensitive depends on the database collation.\n- A `ReminderCost` of `0` is stored as NULL, so a cost of exactly zero cannot be saved explicitly.\n\nDocumentation: https://pixi-api-docs.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": "Updates the invoice due days and reminder (dunning) settings of one customer identified by CustKey or by external customer number/email plus shop.\n\nChanges the payment and reminder settings of exactly one customer record in `Customers`.\n\n**Identifying the customer**\n\n- Pass `CustKey`, **or** pass `ShopId` together with `CustomerNrExternal` and/or `CustomerEmail`.\n- `CustomerNrExternal`, `CustomerEmail` and `ReminderAction` are trimmed; empty strings count as not provided.\n- The lookup matches customers where (`CustomerNrExternal` matches **or** `CeMail` matches `CustomerEmail`) and `CustomerOf` = `ShopId`, **or** where `CustKey` matches.\n- If no customer matches, or more than one customer matches, the call fails.\n\n**Validation**\n\n- `ReminderAction` must be one of `NONE`, `PRINT`, `MAIL`, `PRINT&MAIL` or `0`.\n- `InvoiceDueDays`, `DaysForFirstReminder`, `DaysForNextReminder`, `ReminderDueDays` and `ReminderCost` must not be negative.\n\n**How values are applied**\n\n- A parameter that is omitted (NULL) keeps the value currently stored for the customer.\n- A value of `0` (or `'0'` for `ReminderAction`) clears the setting, i.e. it is stored as NULL (option disabled).\n- Any other value overwrites the stored value.\n\nThe update also sets `UpdateDate` to the current date/time and `UpdateEmp` to `API-CustomerInfoSet`.\n\nThe call always returns one status row with `Status` (`OK` or `ERROR`) and `StatusMessage`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | No | Internal Pixi customer key. Identifies the customer on its own; alternatively use `ShopId` with `CustomerNrExternal`/`CustomerEmail`. |\n| `CustomerNrExternal` | varchar(60) | No | External (shop) customer number, matched against `CustomerNrExternal` of customers of `ShopId`. Trimmed; empty means not provided. |\n| `CustomerEmail` | varchar(256) | No | Customer email address, matched against `CeMail` of customers of `ShopId`. Trimmed; empty means not provided. |\n| `ShopId` | varchar(3) | No | Shop the customer belongs to (`CustomerOf`). Required when the customer is identified by `CustomerNrExternal` or `CustomerEmail`. |\n| `InvoiceDueDays` | smallint | No | Payment term of invoices in days. NULL keeps the current value, 0 clears it, negative values are rejected. |\n| `ReminderAction` | varchar(20) | No | How reminders are sent to the customer. NULL or empty keeps the current value. |\n| `DaysForFirstReminder` | smallint | No | Days that must pass before the first reminder. NULL keeps the current value, 0 clears it, negative values are rejected. |\n| `DaysForNextReminder` | smallint | No | Days until the next reminder. NULL keeps the current value, 0 clears it, negative values are rejected. |\n| `ReminderDueDays` | smallint | No | Payment term printed on reminders, in days. NULL keeps the current value, 0 clears it, negative values are rejected. |\n| `ReminderCost` | money | No | Fee charged per reminder. NULL keeps the current value, 0 clears it (stored as NULL), negative values are rejected. |\n\n- All validation errors are raised inside a `TRY` block and caught; they are returned as a status row with `Status` = `ERROR`, not as a `SqlMessage`. Only the first failing check is reported.\n- The procedure's return value is `0` on success and `1` on error; SOAP clients should evaluate the `Status` column.\n- The candidate lookup reads `Customers` with `NOLOCK`. There is no explicit transaction around lookup and update.\n- Pitfall: the search conditions are combined with `OR`. If `CustKey` is passed together with `ShopId` and `CustomerNrExternal`/`CustomerEmail`, or if both `CustomerNrExternal` and `CustomerEmail` are passed and point to different customers, several records can match and the call fails with \"More than one customer found\". Pass only one identifier for a reliable result.\n- `ShopId` is not trimmed, unlike the other identifiers.\n- `NONE` and `0` differ for `ReminderAction`: `NONE` stores the value `NONE`, `0` stores NULL. Whether the value check is case-sensitive depends on the database collation.\n- A `ReminderCost` of `0` is stored as NULL, so a cost of exactly zero cannot be saved explicitly.\n\nDocumentation: https://pixi-api-docs.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": "Returns the customer key (`CustKey`) of the customer in a given shop whose primary or secondary e-mail address matches the given address.\n\nLooks up a customer by e-mail address within one shop and returns its internal key as a single integer value.\n\n- A customer matches if `@eMail` equals either the `eMail` or the `eMail2` field and the customer belongs to the shop `@ShopId` (`CustomerOf`).\n- Only customers that have at least one address record (`Addresses.AdrCustRef = CustKey`) can be returned, because the lookup uses an inner join on the addresses.\n- With `@AllowAmbiguous = 0` (default) a key is returned only if **exactly one** customer in the shop has this e-mail address. If several customers share the address, the result is `NULL`.\n- With `@AllowAmbiguous = 1` the uniqueness check is skipped and the key of one of the matching customers is returned.\n- If no customer matches, the result is `NULL`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `eMail` | varchar(60) | Yes | E-mail address to search for; compared with the customer's `eMail` and `eMail2` fields. |\n| `ShopId` | char(3) | Yes | Shop ID the customer must belong to (`CustomerOf`). |\n| `AllowAmbiguous` | bit | No | Controls whether a key is returned when several customers of the shop share the e-mail address. |\n\n- All reads use `NOLOCK`, so uncommitted data may be seen.\n- When `@AllowAmbiguous = 1` and several customers match, the choice is made with `TOP 1` without `ORDER BY`; which customer is returned is not deterministic.\n- The uniqueness count only considers the `Customers` table, not the address join. A single matching customer without any address therefore yields `NULL`.\n- `NULL` is returned both for \"not found\" and for \"ambiguous\"; the caller cannot distinguish these cases from the result alone. Call again with `AllowAmbiguous = 1` to check whether matches exist.\n- Whether the comparison is case-sensitive depends on the database collation; no trimming or normalisation of the e-mail address is done.\n\nDocumentation: https://pixi-api-docs.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": "Returns the customer key (`CustKey`) of the customer in a given shop whose primary or secondary e-mail address matches the given address.\n\nLooks up a customer by e-mail address within one shop and returns its internal key as a single integer value.\n\n- A customer matches if `@eMail` equals either the `eMail` or the `eMail2` field and the customer belongs to the shop `@ShopId` (`CustomerOf`).\n- Only customers that have at least one address record (`Addresses.AdrCustRef = CustKey`) can be returned, because the lookup uses an inner join on the addresses.\n- With `@AllowAmbiguous = 0` (default) a key is returned only if **exactly one** customer in the shop has this e-mail address. If several customers share the address, the result is `NULL`.\n- With `@AllowAmbiguous = 1` the uniqueness check is skipped and the key of one of the matching customers is returned.\n- If no customer matches, the result is `NULL`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `eMail` | varchar(60) | Yes | E-mail address to search for; compared with the customer's `eMail` and `eMail2` fields. |\n| `ShopId` | char(3) | Yes | Shop ID the customer must belong to (`CustomerOf`). |\n| `AllowAmbiguous` | bit | No | Controls whether a key is returned when several customers of the shop share the e-mail address. |\n\n- All reads use `NOLOCK`, so uncommitted data may be seen.\n- When `@AllowAmbiguous = 1` and several customers match, the choice is made with `TOP 1` without `ORDER BY`; which customer is returned is not deterministic.\n- The uniqueness count only considers the `Customers` table, not the address join. A single matching customer without any address therefore yields `NULL`.\n- `NULL` is returned both for \"not found\" and for \"ambiguous\"; the caller cannot distinguish these cases from the result alone. Call again with `AllowAmbiguous = 1` to check whether matches exist.\n- Whether the comparison is case-sensitive depends on the database collation; no trimming or normalisation of the e-mail address is done.\n\nDocumentation: https://pixi-api-docs.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": "Returns the internal customer key (CustKey) for an external customer number within a given shop.\n\nLooks up a customer in the `Customers` table by the external customer number (`CustomerNrExternal`) and the shop the customer belongs to (`CustomerOf` = `ShopId`).\n\n- If `AllowAmbiguous` = 1, the key of one matching customer is returned, even if several customers share the same external number in that shop.\n- If `AllowAmbiguous` = 0, a key is returned only if exactly one customer matches. If there are several matches, the result set is empty.\n- If no customer matches, the result set is empty.\n\nAt most one row is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustomerNrExternal` | varchar(60) | Yes | External customer number, e.g. the customer number in the online shop. |\n| `ShopId` | char(3) | Yes | Shop ID the customer belongs to. It is compared with `Customers.CustomerOf`. |\n| `AllowAmbiguous` | bit | Yes | Controls whether a key is returned when several customers match. |\n\n- All parameters are required; none has a default value.\n- The query uses `TOP 1` without `ORDER BY`. When `AllowAmbiguous` = 1 and several customers match, it is not defined which `CustKey` is returned.\n- Reads use `NOLOCK`, so uncommitted data may be seen.\n- An empty result means either no match or, with `AllowAmbiguous` = 0, an ambiguous match. The caller cannot tell which case applies.\n\nDocumentation: https://pixi-api-docs.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": "Returns the internal customer key (CustKey) for an external customer number within a given shop.\n\nLooks up a customer in the `Customers` table by the external customer number (`CustomerNrExternal`) and the shop the customer belongs to (`CustomerOf` = `ShopId`).\n\n- If `AllowAmbiguous` = 1, the key of one matching customer is returned, even if several customers share the same external number in that shop.\n- If `AllowAmbiguous` = 0, a key is returned only if exactly one customer matches. If there are several matches, the result set is empty.\n- If no customer matches, the result set is empty.\n\nAt most one row is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustomerNrExternal` | varchar(60) | Yes | External customer number, e.g. the customer number in the online shop. |\n| `ShopId` | char(3) | Yes | Shop ID the customer belongs to. It is compared with `Customers.CustomerOf`. |\n| `AllowAmbiguous` | bit | Yes | Controls whether a key is returned when several customers match. |\n\n- All parameters are required; none has a default value.\n- The query uses `TOP 1` without `ORDER BY`. When `AllowAmbiguous` = 1 and several customers match, it is not defined which `CustKey` is returned.\n- Reads use `NOLOCK`, so uncommitted data may be seen.\n- An empty result means either no match or, with `AllowAmbiguous` = 0, an ambiguous match. The caller cannot tell which case applies.\n\nDocumentation: https://pixi-api-docs.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": "Searches customers by external customer number, e-mail, name, address, city, ZIP, country, shop, order or invoice number.\n\nWrapper around the internal procedure `Pixi_CustomerSearch`. The call first normalizes the search parameters and then passes them on. The internal procedure produces the result.\n\nNormalization:\n- Empty strings and `NULL` are replaced by the wildcard `%`. For `Name` and `Address` the replacement is `%%`.\n- `CustNrExternal`: if a value other than `%` is given, a trailing `%` is appended. This makes it a prefix search, for example `K100` becomes `K100%`.\n- `OrderNr`: `0` (and `NULL`) is treated as no filter (`NULL`).\n\nParameter mapping to `Pixi_CustomerSearch`:\n- `CustNrExternal` is passed as `@CustID`, and `@CustomerNrExternal` is passed as `NULL`.\n- `RowCount`, `eMail`, `Name`, `Address`, `City`, `Zip`, `Country`, `ShopID`, `OrderNr`, `OrderNrExternal` and `InvoiceNr` are passed through after normalization.\n- The other filters of the internal procedure are fixed to `NULL`: `CardNr`, `BoxNr`, `ItemName`, `ItemEAN`, `Status` and `ShipCode`. `SerialNr` is fixed to `%`.\n\n`RowCount` (default 1500) is passed to the internal procedure and most likely limits the number of returned rows.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `RowCount` | integer | No | Maximum number of rows. Passed to `Pixi_CustomerSearch`. |\n| `CustNrExternal` | varchar(255) | No | External customer number. A trailing `%` is appended, which makes it a prefix search. Passed as `@CustID`. |\n| `eMail` | varchar(255) | No | E-mail filter (wildcard pattern). An empty value means no filter. |\n| `Name` | varchar(255) | No | Customer name filter (wildcard pattern). An empty value is replaced by `%%`. |\n| `Address` | varchar(255) | No | Address/street filter (wildcard pattern). An empty value is replaced by `%%`. |\n| `City` | varchar(255) | No | City filter (wildcard pattern). |\n| `Zip` | varchar(255) | No | ZIP code filter (wildcard pattern). |\n| `Country` | varchar(255) | No | Country filter (wildcard pattern). |\n| `ShopID` | varchar(3) | No | Shop ID. Passed unchanged; the default is an empty string. |\n| `OrderNr` | integer | No | Pixi order number. `NULL` or `0` means no filter. |\n| `OrderNrExternal` | varchar(255) | No | External (shop) order number filter (wildcard pattern). |\n| `InvoiceNr` | varchar(255) | No | Invoice number filter (wildcard pattern). |\n\n- The definition of `Pixi_CustomerSearch` is not attached. The columns of the result, the exact matching logic and the sort order cannot be derived from this code. The `%` defaults suggest `LIKE` pattern matching, but this is not confirmed.\n- Because the code compares `OrderNr` with an empty string, the value `0` is treated as `NULL` (no filter).\n- The header comment (\"Template for getting items…\") was copied from a template and does not describe this call.\n- The call itself writes no data. Whether the internal procedure has side effects is unknown.\n\nDocumentation: https://pixi-api-docs.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": "Returns the lock flag, open orders, unpaid invoices, invoice debt and open order amount of one customer, with the currency code the amounts refer to.\n\nReturns a single row that sums up the open business of the customer identified by `CustKey`.\n\nThe behaviour depends on the setting `MultiCurrencyEnabled`.\n\n**Multi-currency disabled** (setting is not `1`):\n- `Locked` is `1` if the customer's `SLocked` flag is set to anything other than `N`, otherwise `0`.\n- `OpenOrders` is the number of distinct order numbers that have at least one order line of this customer (`Orderlines.CustRef`) whose status is not a final state in `OrderStates` (`FinalState = 'Y'`).\n- `OpenOrderAmount` is the sum of `OrderLineAmount` of these non-final order lines. The amounts are added up as stored, without currency conversion.\n- `UnpaidInvoices` is the number of invoices of the customer where the paid sum is not equal to the invoice total. A missing paid sum counts as `0`.\n- `DebtByInvoices` is the sum of `total - PayedSum` over all invoices of the customer.\n- `BaseCurrency` is the database currency code. It comes from the setting `HomeCurrency` and must be a parent currency in `pixi.Currency`.\n\n**Multi-currency enabled** (setting is `1`):\n- The counts are calculated in the same way.\n- Each order line amount is divided by the exchange rate of its order header (`OrderHeader.ExchRateId`).\n- Each invoice debt is divided by the exchange rate of the invoice (`Invoices.ExchRateId`).\n- The results are therefore amounts in base currency.\n- `BaseCurrency` is the code of the base currency of the customer's shop (`Shops.BaseCurrencyId`).\n\nIf no customer with the given `CustKey` exists, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | Yes | Key of the customer (`Customers.CustKey`). |\n\n- All tables are read with `NOLOCK`, so the figures may include uncommitted data.\n- Without multi-currency, order and invoice amounts in different currencies are added up unconverted. `BaseCurrency` then only gives the database currency code; it is not the actual currency of the sum.\n- With multi-currency enabled, the following records are left out of the amounts and counts: order lines whose order header has no matching exchange rate, and invoices without a matching exchange rate. No row is returned if the customer's shop or its base currency cannot be found.\n- Invoices with a `NULL` paid sum are counted in `UnpaidInvoices`. Their debt is not part of `DebtByInvoices`, because `total - NULL` is ignored by `SUM`.\n- Overpaid invoices are also counted as unpaid and reduce `DebtByInvoices`.\n- `DebtByInvoices` is `0` if the customer has no invoices.\n- The setting value is converted to `BIT`. A non-numeric value other than `true`/`false` causes a conversion error.\n\nDocumentation: https://pixi-api-docs.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": "Returns the lock flag, open orders, unpaid invoices, invoice debt and open order amount of one customer, with the currency code the amounts refer to.\n\nReturns a single row that sums up the open business of the customer identified by `CustKey`.\n\nThe behaviour depends on the setting `MultiCurrencyEnabled`.\n\n**Multi-currency disabled** (setting is not `1`):\n- `Locked` is `1` if the customer's `SLocked` flag is set to anything other than `N`, otherwise `0`.\n- `OpenOrders` is the number of distinct order numbers that have at least one order line of this customer (`Orderlines.CustRef`) whose status is not a final state in `OrderStates` (`FinalState = 'Y'`).\n- `OpenOrderAmount` is the sum of `OrderLineAmount` of these non-final order lines. The amounts are added up as stored, without currency conversion.\n- `UnpaidInvoices` is the number of invoices of the customer where the paid sum is not equal to the invoice total. A missing paid sum counts as `0`.\n- `DebtByInvoices` is the sum of `total - PayedSum` over all invoices of the customer.\n- `BaseCurrency` is the database currency code. It comes from the setting `HomeCurrency` and must be a parent currency in `pixi.Currency`.\n\n**Multi-currency enabled** (setting is `1`):\n- The counts are calculated in the same way.\n- Each order line amount is divided by the exchange rate of its order header (`OrderHeader.ExchRateId`).\n- Each invoice debt is divided by the exchange rate of the invoice (`Invoices.ExchRateId`).\n- The results are therefore amounts in base currency.\n- `BaseCurrency` is the code of the base currency of the customer's shop (`Shops.BaseCurrencyId`).\n\nIf no customer with the given `CustKey` exists, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | Yes | Key of the customer (`Customers.CustKey`). |\n\n- All tables are read with `NOLOCK`, so the figures may include uncommitted data.\n- Without multi-currency, order and invoice amounts in different currencies are added up unconverted. `BaseCurrency` then only gives the database currency code; it is not the actual currency of the sum.\n- With multi-currency enabled, the following records are left out of the amounts and counts: order lines whose order header has no matching exchange rate, and invoices without a matching exchange rate. No row is returned if the customer's shop or its base currency cannot be found.\n- Invoices with a `NULL` paid sum are counted in `UnpaidInvoices`. Their debt is not part of `DebtByInvoices`, because `total - NULL` is ignored by `SUM`.\n- Overpaid invoices are also counted as unpaid and reduce `DebtByInvoices`.\n- `DebtByInvoices` is `0` if the customer has no invoices.\n- The setting value is converted to `BIT`. A non-numeric value other than `true`/`false` causes a conversion error.\n\nDocumentation: https://pixi-api-docs.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": "Returns customers whose number of orders with order lines in status ANG or recent AUS reaches a minimum count, optionally filtered by shop.\n\nLists customers who have several qualifying orders, for example to spot duplicate or suspicious orders by the same customer.\n\nSteps:\n\n1. An empty `ShopID` is treated as `NULL`, which means no shop filter.\n2. An order qualifies if at least one of its lines in `Orderlines` meets either condition:\n - status `ANG`, regardless of date, or\n - status `AUS` and `OrderDate` less than `DayRange` days ago, measured as calendar-day difference to today.\n3. Qualifying orders in `OrderHeader` are joined to `Customers` via `CustRef` = `CustKey`.\n4. If `ShopID` is set, only customers whose `CustomerOf` equals `ShopID` are included.\n5. Results are grouped per customer (`CustRef`). Only customers with at least `MinOrderCount` qualifying orders are returned.\n\nEach row contains the customer's name, e-mail address, number of qualifying orders and shop. The result has no explicit sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DayRange` | int | No | Number of days back from today in which the order date must lie. Applies only to order lines in status `AUS`. |\n| `MinOrderCount` | int | No | Minimum number of qualifying orders a customer must have to be returned. |\n| `ShopID` | varchar(3) | No | Shop of the customer (`CustomerOf`). `NULL` or an empty string returns customers of all shops. |\n\n- All tables are read with `NOLOCK`. Results may include uncommitted data.\n- Because of SQL operator precedence (`AND` before `OR`), the `DayRange` restriction applies only to lines in status `AUS`. Orders with `ANG` lines are counted no matter how old they are.\n- The code does not show which table the unqualified `OrderDate` column belongs to. If `Orderlines` has no such column, the order date from `OrderHeader` is used.\n- The shop filter uses the customer's shop (`CustomerOf`), not the shop of the order.\n- `Name`, `eMail` and `ShopID` are built with `MAX()` per customer group.\n\nDocumentation: https://pixi-api-docs.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": "Returns customers whose number of orders with order lines in status ANG or recent AUS reaches a minimum count, optionally filtered by shop.\n\nLists customers who have several qualifying orders, for example to spot duplicate or suspicious orders by the same customer.\n\nSteps:\n\n1. An empty `ShopID` is treated as `NULL`, which means no shop filter.\n2. An order qualifies if at least one of its lines in `Orderlines` meets either condition:\n - status `ANG`, regardless of date, or\n - status `AUS` and `OrderDate` less than `DayRange` days ago, measured as calendar-day difference to today.\n3. Qualifying orders in `OrderHeader` are joined to `Customers` via `CustRef` = `CustKey`.\n4. If `ShopID` is set, only customers whose `CustomerOf` equals `ShopID` are included.\n5. Results are grouped per customer (`CustRef`). Only customers with at least `MinOrderCount` qualifying orders are returned.\n\nEach row contains the customer's name, e-mail address, number of qualifying orders and shop. The result has no explicit sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DayRange` | int | No | Number of days back from today in which the order date must lie. Applies only to order lines in status `AUS`. |\n| `MinOrderCount` | int | No | Minimum number of qualifying orders a customer must have to be returned. |\n| `ShopID` | varchar(3) | No | Shop of the customer (`CustomerOf`). `NULL` or an empty string returns customers of all shops. |\n\n- All tables are read with `NOLOCK`. Results may include uncommitted data.\n- Because of SQL operator precedence (`AND` before `OR`), the `DayRange` restriction applies only to lines in status `AUS`. Orders with `ANG` lines are counted no matter how old they are.\n- The code does not show which table the unqualified `OrderDate` column belongs to. If `Orderlines` has no such column, the order date from `OrderHeader` is used.\n- The shop filter uses the customer's shop (`CustomerOf`), not the shop of the order.\n- `Name`, `eMail` and `ShopID` are built with `MAX()` per customer group.\n\nDocumentation: https://pixi-api-docs.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": "Returns customers with email address and name, optionally filtered by order or ship date, item, payment and shipping status or shop, with key-based paging.\n\nReturns a list of customers (key, email, first name, last name, shop) for use in email marketing tools. The procedure builds a dynamic query on `Customers` joined to `Addresses` (inner join on the customer's address reference). All filters are optional and combined with AND:\n\n- `orderdate`: only customers with at least one order line whose order date falls on the same calendar day (year, month and day are compared; the time is ignored).\n- `ShipDate`: only customers with at least one order line shipped on that calendar day.\n- `EanUpc`: only customers who ordered an item with this EAN/UPC.\n- `ArticleNr`: only customers who ordered an item whose **supplier item number** (`ItemNrSuppl`) matches.\n- `paid`: `1` = customers with at least one invoice where the paid sum equals the total; `0` = customers with at least one invoice where the paid sum differs from the total.\n- `Shipped`: `1` = customers with at least one shipped order line; `0` = customers with at least one order line without ship date.\n- `ShopID`: only customers belonging to this shop (`CustomerOf`). An empty string is treated as no filter.\n\nThe result is sorted by customer key ascending and limited to `Top` rows. For paging, pass the highest `custkey` of the previous page as `resumeKey`; only customers with a larger key are returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `orderdate` | datetime | No | Only customers with an order line ordered on this calendar day. Time part is ignored. |\n| `ShipDate` | datetime | No | Only customers with an order line shipped on this calendar day. Time part is ignored. |\n| `EanUpc` | varchar(13) | No | Only customers who ordered an item with this EAN/UPC. |\n| `ArticleNr` | varchar(50) | No | Only customers who ordered an item with this supplier item number (`ItemNrSuppl`). |\n| `paid` | bit | No | Filter on invoice payment status. `NULL` = no filter. |\n| `Shipped` | bit | No | Filter on shipping status of order lines. `NULL` = no filter. |\n| `resumeKey` | int | No | Paging key: only customers with a customer key greater than this value are returned. Pass the last `custkey` of the previous page. |\n| `Top` | int | No | Maximum number of rows returned (applied via `SET ROWCOUNT`; `0` = no limit). |\n| `ShopID` | varchar(3) | No | Only customers of this shop (`CustomerOf`). Empty string is treated as `NULL` (no filter). |\n\n- All reads use `NOLOCK`, so results can contain uncommitted data.\n- The row limit is applied with `SET ROWCOUNT`; `Top` = `0` returns all matching rows.\n- Customers without a matching address record are not returned because of the inner join.\n- The `paid` and `Shipped` filters test for *at least one* matching invoice or order line, not for all of them. `paid = 1` therefore also returns customers who additionally have unpaid invoices.\n- Date filters use `DATEPART` on the column, so indexes on order or ship date cannot be used; on large databases these filters can be slow.\n- `ArticleNr` is compared with the supplier item number (`ItemNrSuppl`), not with the internal item number.\n- The statement is passed to `sp_executesql` under the parameter name `@statment` instead of the documented `@stmt`; the call relies on positional handling of this parameter.\n\nDocumentation: https://pixi-api-docs.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": "Returns customers with email address and name, optionally filtered by order or ship date, item, payment and shipping status or shop, with key-based paging.\n\nReturns a list of customers (key, email, first name, last name, shop) for use in email marketing tools. The procedure builds a dynamic query on `Customers` joined to `Addresses` (inner join on the customer's address reference). All filters are optional and combined with AND:\n\n- `orderdate`: only customers with at least one order line whose order date falls on the same calendar day (year, month and day are compared; the time is ignored).\n- `ShipDate`: only customers with at least one order line shipped on that calendar day.\n- `EanUpc`: only customers who ordered an item with this EAN/UPC.\n- `ArticleNr`: only customers who ordered an item whose **supplier item number** (`ItemNrSuppl`) matches.\n- `paid`: `1` = customers with at least one invoice where the paid sum equals the total; `0` = customers with at least one invoice where the paid sum differs from the total.\n- `Shipped`: `1` = customers with at least one shipped order line; `0` = customers with at least one order line without ship date.\n- `ShopID`: only customers belonging to this shop (`CustomerOf`). An empty string is treated as no filter.\n\nThe result is sorted by customer key ascending and limited to `Top` rows. For paging, pass the highest `custkey` of the previous page as `resumeKey`; only customers with a larger key are returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `orderdate` | datetime | No | Only customers with an order line ordered on this calendar day. Time part is ignored. |\n| `ShipDate` | datetime | No | Only customers with an order line shipped on this calendar day. Time part is ignored. |\n| `EanUpc` | varchar(13) | No | Only customers who ordered an item with this EAN/UPC. |\n| `ArticleNr` | varchar(50) | No | Only customers who ordered an item with this supplier item number (`ItemNrSuppl`). |\n| `paid` | bit | No | Filter on invoice payment status. `NULL` = no filter. |\n| `Shipped` | bit | No | Filter on shipping status of order lines. `NULL` = no filter. |\n| `resumeKey` | int | No | Paging key: only customers with a customer key greater than this value are returned. Pass the last `custkey` of the previous page. |\n| `Top` | int | No | Maximum number of rows returned (applied via `SET ROWCOUNT`; `0` = no limit). |\n| `ShopID` | varchar(3) | No | Only customers of this shop (`CustomerOf`). Empty string is treated as `NULL` (no filter). |\n\n- All reads use `NOLOCK`, so results can contain uncommitted data.\n- The row limit is applied with `SET ROWCOUNT`; `Top` = `0` returns all matching rows.\n- Customers without a matching address record are not returned because of the inner join.\n- The `paid` and `Shipped` filters test for *at least one* matching invoice or order line, not for all of them. `paid = 1` therefore also returns customers who additionally have unpaid invoices.\n- Date filters use `DATEPART` on the column, so indexes on order or ship date cannot be used; on large databases these filters can be slow.\n- `ArticleNr` is compared with the supplier item number (`ItemNrSuppl`), not with the internal item number.\n- The statement is passed to `sp_executesql` under the parameter name `@statment` instead of the documented `@stmt`; the call relies on positional handling of this parameter.\n\nDocumentation: https://pixi-api-docs.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": "Returns a list of customers with their billing address and latest order data, filtered by item, order, payment and customer attributes.\n\nReturns one row per customer who has at least one order line matching all given filters. The customer is joined with the customer's address (`AddrRef`), the order lines, the item, the item category (`tontrArten` via `configType`) and optionally the invoice, supplier and additional item data. All filters are combined with AND. A filter whose parameter is `NULL` is not applied.\n\n**Shop**\n- `ShopID`: only customers whose `CustomerOf` equals this value. An empty string counts as `NULL`.\n\n**Item filters** (applied to the order lines)\n- `ArticleName` with `ArticleNameCmp`: `0` = exact match on the item name of the order line, `1` = name contains the value.\n- `ArticleNr` with `ArticleNrCmp`: matches the supplier item number, the EAN/UPC or the internal item number. `0` = exact, `1` = contains.\n- `ArtCategory`: key of the item category (`tontrArtKey`).\n- `ArtSupplier`: supplier number of the order line (`SupplInfo`) or supplier name.\n\n**Order filters**\n- `orderStatus`: status of the order line, e.g. `AUS` or `RET`.\n- `ShipDateFrom`/`ShipDateTo`: ship date of the order line between both values. The filter applies only if **both** are set.\n- `ShipDateDays` with `ShipDateDaysCmp`: number of days between the ship date and now. `0` = more than, `1` = exactly, `2` = fewer than `ShipDateDays` days.\n- `PaymentType`: payment type of the invoice linked to the order line.\n\n**Customer filters**\n- `CustTurnover` with `CustTurnoverCmp`: sum of all invoice totals of the customer. `0` = turnover greater than the value, `1` = equal, `2` = less than.\n- `CustReturn`: `0` = ignore, `1` = only customers with at least one order line in status `RET`, `-1` = only customers without such lines.\n- `CustBlocked`: `0` = only customers that are not blocked, `1` = blocked and unblocked customers.\n- `CustOpenOrders`: `0` = ignore, `1` = only customers with at least one order whose overall state is `OPEN`.\n\nThe columns `OrderDate`, `ShipDate` and `Status` are the maximum values over the matching order lines of the customer. The result is sorted by `CustKey`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ArticleName` | varchar(100) | No | Item name of the order line to filter by; compared according to `ArticleNameCmp`. |\n| `ArticleNameCmp` | int | No | Comparison mode for `ArticleName`. `NULL` is treated as `0`. |\n| `ArticleNr` | varchar(50) | No | Item number to filter by; compared with supplier item number, EAN/UPC and internal item number according to `ArticleNrCmp`. |\n| `ArticleNrCmp` | int | No | Comparison mode for `ArticleNr`. `NULL` is treated as `0`. |\n| `ArtCategory` | int | No | Key of the item category (`tontrArtKey` in `tontrArten`). |\n| `ArtSupplier` | varchar(50) | No | Supplier number of the order line or supplier name. |\n| `orderStatus` | varchar(3) | No | Status of the order line, e.g. `AUS` or `RET`. |\n| `ShipDateFrom` | datetime | No | Start of the ship date range. Applied only together with `ShipDateTo`. |\n| `ShipDateTo` | datetime | No | End of the ship date range (inclusive). Applied only together with `ShipDateFrom`. |\n| `ShipDateDays` | int | No | Number of days since the ship date of the order line; compared according to `ShipDateDaysCmp`. |\n| `ShipDateDaysCmp` | int | No | Comparison mode for `ShipDateDays`. `NULL` is treated as `1`. |\n| `PaymentType` | varchar(30) | No | Payment type of the invoice linked to the order line. |\n| `CustTurnover` | int | No | Turnover threshold, compared with the sum of all invoice totals of the customer according to `CustTurnoverCmp`. |\n| `CustTurnoverCmp` | int | No | Comparison mode for `CustTurnover`. `NULL` is treated as `1`. |\n| `CustReturn` | int | No | Filter on returns of the customer. `NULL` is treated as `0`. |\n| `CustBlocked` | int | No | Controls whether blocked customers are included. `NULL` is treated as `0`. |\n| `CustOpenOrders` | int | No | Filter on open orders of the customer. `NULL` is treated as `0`. |\n| `resumeKey` | int | No | Not used by the procedure. |\n| `ShopID` | varchar(3) | No | Shop the customer belongs to (`CustomerOf`). Empty string or `NULL` means all shops. |\n\n- All tables are read with `NOLOCK`, so uncommitted data can appear.\n- `resumeKey` is declared but not used; there is no paging.\n- `Status` is the alphabetically highest status of the matching order lines, not necessarily the status of the newest order. `OrderDate` and `ShipDate` are computed independently of each other.\n- Comparison parameters with values other than those documented (e.g. `ArticleNameCmp = 2` with `ArticleName` set, or `CustBlocked = 2`) make the filter match nothing, so the result is empty.\n- `CustTurnover` excludes customers without any invoice, because their turnover sum is `NULL`.\n- Setting `PaymentType` only returns order lines linked to an invoice of the same customer.\n- Order lines whose `configType` has no entry in `tontrArten` are never considered.\n- `CustOpenOrders = 1` calls the scalar function `fPixi_GetWholeOrderState` per order of the customer, which can be slow for customers with many orders.\n\nDocumentation: https://pixi-api-docs.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": "Returns a list of customers with their billing address and latest order data, filtered by item, order, payment and customer attributes.\n\nReturns one row per customer who has at least one order line matching all given filters. The customer is joined with the customer's address (`AddrRef`), the order lines, the item, the item category (`tontrArten` via `configType`) and optionally the invoice, supplier and additional item data. All filters are combined with AND. A filter whose parameter is `NULL` is not applied.\n\n**Shop**\n- `ShopID`: only customers whose `CustomerOf` equals this value. An empty string counts as `NULL`.\n\n**Item filters** (applied to the order lines)\n- `ArticleName` with `ArticleNameCmp`: `0` = exact match on the item name of the order line, `1` = name contains the value.\n- `ArticleNr` with `ArticleNrCmp`: matches the supplier item number, the EAN/UPC or the internal item number. `0` = exact, `1` = contains.\n- `ArtCategory`: key of the item category (`tontrArtKey`).\n- `ArtSupplier`: supplier number of the order line (`SupplInfo`) or supplier name.\n\n**Order filters**\n- `orderStatus`: status of the order line, e.g. `AUS` or `RET`.\n- `ShipDateFrom`/`ShipDateTo`: ship date of the order line between both values. The filter applies only if **both** are set.\n- `ShipDateDays` with `ShipDateDaysCmp`: number of days between the ship date and now. `0` = more than, `1` = exactly, `2` = fewer than `ShipDateDays` days.\n- `PaymentType`: payment type of the invoice linked to the order line.\n\n**Customer filters**\n- `CustTurnover` with `CustTurnoverCmp`: sum of all invoice totals of the customer. `0` = turnover greater than the value, `1` = equal, `2` = less than.\n- `CustReturn`: `0` = ignore, `1` = only customers with at least one order line in status `RET`, `-1` = only customers without such lines.\n- `CustBlocked`: `0` = only customers that are not blocked, `1` = blocked and unblocked customers.\n- `CustOpenOrders`: `0` = ignore, `1` = only customers with at least one order whose overall state is `OPEN`.\n\nThe columns `OrderDate`, `ShipDate` and `Status` are the maximum values over the matching order lines of the customer. The result is sorted by `CustKey`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ArticleName` | varchar(100) | No | Item name of the order line to filter by; compared according to `ArticleNameCmp`. |\n| `ArticleNameCmp` | int | No | Comparison mode for `ArticleName`. `NULL` is treated as `0`. |\n| `ArticleNr` | varchar(50) | No | Item number to filter by; compared with supplier item number, EAN/UPC and internal item number according to `ArticleNrCmp`. |\n| `ArticleNrCmp` | int | No | Comparison mode for `ArticleNr`. `NULL` is treated as `0`. |\n| `ArtCategory` | int | No | Key of the item category (`tontrArtKey` in `tontrArten`). |\n| `ArtSupplier` | varchar(50) | No | Supplier number of the order line or supplier name. |\n| `orderStatus` | varchar(3) | No | Status of the order line, e.g. `AUS` or `RET`. |\n| `ShipDateFrom` | datetime | No | Start of the ship date range. Applied only together with `ShipDateTo`. |\n| `ShipDateTo` | datetime | No | End of the ship date range (inclusive). Applied only together with `ShipDateFrom`. |\n| `ShipDateDays` | int | No | Number of days since the ship date of the order line; compared according to `ShipDateDaysCmp`. |\n| `ShipDateDaysCmp` | int | No | Comparison mode for `ShipDateDays`. `NULL` is treated as `1`. |\n| `PaymentType` | varchar(30) | No | Payment type of the invoice linked to the order line. |\n| `CustTurnover` | int | No | Turnover threshold, compared with the sum of all invoice totals of the customer according to `CustTurnoverCmp`. |\n| `CustTurnoverCmp` | int | No | Comparison mode for `CustTurnover`. `NULL` is treated as `1`. |\n| `CustReturn` | int | No | Filter on returns of the customer. `NULL` is treated as `0`. |\n| `CustBlocked` | int | No | Controls whether blocked customers are included. `NULL` is treated as `0`. |\n| `CustOpenOrders` | int | No | Filter on open orders of the customer. `NULL` is treated as `0`. |\n| `resumeKey` | int | No | Not used by the procedure. |\n| `ShopID` | varchar(3) | No | Shop the customer belongs to (`CustomerOf`). Empty string or `NULL` means all shops. |\n\n- All tables are read with `NOLOCK`, so uncommitted data can appear.\n- `resumeKey` is declared but not used; there is no paging.\n- `Status` is the alphabetically highest status of the matching order lines, not necessarily the status of the newest order. `OrderDate` and `ShipDate` are computed independently of each other.\n- Comparison parameters with values other than those documented (e.g. `ArticleNameCmp = 2` with `ArticleName` set, or `CustBlocked = 2`) make the filter match nothing, so the result is empty.\n- `CustTurnover` excludes customers without any invoice, because their turnover sum is `NULL`.\n- Setting `PaymentType` only returns order lines linked to an invoice of the same customer.\n- Order lines whose `configType` has no entry in `tontrArten` are never considered.\n- `CustOpenOrders = 1` calls the scalar function `fPixi_GetWholeOrderState` per order of the customer, which can be slow for customers with many orders.\n\nDocumentation: https://pixi-api-docs.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": "Returns a single address record identified by its address key, including country details, bank data and payment type.\n\nReads one address from the Pixi address table by its primary key `AddrKey`.\n\n- The address is filtered by `AddrKey = @AddrKey`. At most one row is returned.\n- The country of the address (`Country`) is joined with the country table via the country code. The country name and the ISO-2 and ISO-3 codes are added to the result. If no matching country exists, these columns are empty.\n- Besides contact data (name, company, street, ZIP, city, phone, fax, e-mail), the result contains the external customer number, the linked customer key (`CustKey`), the VAT ID, the birth date, a note, bank data (account number, account owner, BLZ, bank name, BIC, IBAN) and the payment type stored at the address.\n- Several columns are renamed in the output, e.g. `Anrede` becomes `Title`, `CareOf` becomes `Company`, `AdrCustRef` becomes `CustKey` and `UsStId` becomes `VatID`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AddrKey` | int | Yes | Primary key of the address to return. |\n\n- Both tables are read `WITH (NOLOCK)`, so uncommitted changes may be visible.\n- If no address with the given key exists, the result set is empty; no error message is returned.\n- The result contains bank data (IBAN, BIC, account number). Handle it according to data protection requirements.\n- The column data types are not visible in the procedure; the types listed here are not confirmed by the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns a single address record identified by its address key, including country details, bank data and payment type.\n\nReads one address from the Pixi address table by its primary key `AddrKey`.\n\n- The address is filtered by `AddrKey = @AddrKey`. At most one row is returned.\n- The country of the address (`Country`) is joined with the country table via the country code. The country name and the ISO-2 and ISO-3 codes are added to the result. If no matching country exists, these columns are empty.\n- Besides contact data (name, company, street, ZIP, city, phone, fax, e-mail), the result contains the external customer number, the linked customer key (`CustKey`), the VAT ID, the birth date, a note, bank data (account number, account owner, BLZ, bank name, BIC, IBAN) and the payment type stored at the address.\n- Several columns are renamed in the output, e.g. `Anrede` becomes `Title`, `CareOf` becomes `Company`, `AdrCustRef` becomes `CustKey` and `UsStId` becomes `VatID`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AddrKey` | int | Yes | Primary key of the address to return. |\n\n- Both tables are read `WITH (NOLOCK)`, so uncommitted changes may be visible.\n- If no address with the given key exists, the result set is empty; no error message is returned.\n- The result contains bank data (IBAN, BIC, account number). Handle it according to data protection requirements.\n- The column data types are not visible in the procedure; the types listed here are not confirmed by the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns all addresses whose e-mail address matches the given value, optionally restricted to one shop.\n\nSearches the address table for records whose `eMail` equals `Email`.\n\n- If `ShopId` is `NULL` or an empty string, addresses from all shops are returned.\n- Otherwise only addresses whose shop (`AddrShopID`) equals `ShopId` are returned.\n\nFor each address the call returns the address data, the external customer number, the linked customer key (`CustKey`) and the country name and ISO codes from the country table. The country data is joined with a left outer join, so addresses with an unknown country code are still returned with empty country columns.\n\nNo sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Email` | varchar(60) | Yes | E-mail address to search for (exact match on the address e-mail). |\n| `ShopId` | char(3) | No | Optional shop ID. If set, only addresses of this shop are returned; `NULL` or empty returns addresses of all shops. |\n\n- Reads with `NOLOCK`; uncommitted data may be returned.\n- The e-mail comparison is an exact equality; whether it is case-insensitive depends on the database collation. No wildcards are supported.\n- An address can appear for several customers or address types (e.g. invoice and delivery addresses), so multiple rows per e-mail are normal.\n- If no address matches, an empty result set is returned.\n\nDocumentation: https://pixi-api-docs.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": "Returns all addresses whose e-mail address matches the given value, optionally restricted to one shop.\n\nSearches the address table for records whose `eMail` equals `Email`.\n\n- If `ShopId` is `NULL` or an empty string, addresses from all shops are returned.\n- Otherwise only addresses whose shop (`AddrShopID`) equals `ShopId` are returned.\n\nFor each address the call returns the address data, the external customer number, the linked customer key (`CustKey`) and the country name and ISO codes from the country table. The country data is joined with a left outer join, so addresses with an unknown country code are still returned with empty country columns.\n\nNo sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Email` | varchar(60) | Yes | E-mail address to search for (exact match on the address e-mail). |\n| `ShopId` | char(3) | No | Optional shop ID. If set, only addresses of this shop are returned; `NULL` or empty returns addresses of all shops. |\n\n- Reads with `NOLOCK`; uncommitted data may be returned.\n- The e-mail comparison is an exact equality; whether it is case-insensitive depends on the database collation. No wildcards are supported.\n- An address can appear for several customers or address types (e.g. invoice and delivery addresses), so multiple rows per e-mail are normal.\n- If no address matches, an empty result set is returned.\n\nDocumentation: https://pixi-api-docs.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": "Returns customer account events (invoices, matches/payments, reminders and virtual full-payment events) of one shop within a date range, with balance and reminder levels.\n\nCollects all customer account events of the customers of shop `ShopId` that happened in a date range and returns them as one event list. Reminder sendings and full payments of invoices are treated as additional events.\n\n**Date range**\n- If `StartDate` is NULL, the range starts on the first day of the current month. Otherwise it starts at 00:00 of `StartDate`.\n- If `EndDate` is NULL, the range ends at the end of today. Otherwise it ends at 23:59:59.997 of `EndDate`.\n\n**Event types collected**\n1. **Invoice events**: `CustomerAccount` entries with `EventID = 'INV'` whose `EventDate` is in the range. `EventKey` = `CAE_`.\n2. **Reminder events**: reminders (`Reminders` joined with `ReminderLines`) whose `ReminderSentDate` is in the range. They are returned with `EventID = 'REM'`. The amount is the negative of reminder total minus reminder costs, and `ReminderLevel` comes from the reminder line. `EventKey` = `REM_`.\n3. **Match events**: `CustomerAccountMatch` records created in the range that link an invoice entry (`EventID = 'INV'`) with another, different customer account entry. Both link directions are taken into account. The row carries the `EventID` and `EventDate` of the counterpart entry (for example a payment). The amount is the absolute match amount, and `EventUpdateDate` is the match creation date. `EventKey` = `CAM_`.\n4. **Virtual full-payment events**: for an invoice of a returned customer whose matches up to `EndDate` add up exactly to the invoice total, a virtual event is created with `EventID = 'REM'` and amount 0. Its date is the last match creation date plus 1 ms. The customer must also have at least one match event in the range, and the event is dropped if its date is before the range start. `EventKey` = `FPY_`.\n\n**Customer filter**\n- Only customers whose `CustomerOf` equals `ShopId` are returned.\n- If `CustomerNumberIsNumeric = 1`, only customers whose `CustomerNrExternal` consists solely of digits are returned. With `0` (default, or NULL) all customers of the shop are returned.\n\n**Reminder levels**\n- For every invoice without a virtual full-payment event, the highest `HighestReminderLevel` of all reminders containing the invoice is determined (invoice dated before `EndDate`).\n- This value is written to `ReminderLevel` of all non-`REM` events of the invoice.\n- `CustomerReminderLevel` is the maximum of these levels over all open invoices of the customer. It is set on all events of the customer.\n\n**Amounts and currencies**\n- `Balance_ShopCurr` is the sum of all customer account amounts with `EventDate` before `EndDate`.\n- If the setting `MultiCurrencyEnabled` is 1, these amounts are converted with the exchange rate of the current day.\n- `Amount_ShopCurr` is the event amount converted the same way. A missing rate counts as 1.\n\n**Output**\n- Each event row contains the external customer number, invoice number and external order number.\n- Only events that can be linked to an invoice in `Invoices` are returned.\n- The result is `DISTINCT` and sorted by `EventUpdateDate`, then `EventDate`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | No | Start of the date range (time part is ignored, 00:00 is used). NULL means the first day of the current month. |\n| `EndDate` | datetime | No | End of the date range (end of the given day is used). NULL means the end of today. |\n| `ShopId` | varchar(3) | Yes | Shop whose customers are returned (compared with `Customers.CustomerOf`). Must not be empty. |\n| `CustomerNumberIsNumeric` | bit | No | Restricts the result to customers with a purely numeric external customer number. NULL is treated as 0. |\n\n- All reads use `NOLOCK`; results may contain uncommitted data.\n- Exchange rates are always taken for the **current date** (`ExchDate` = today), not for the event date. With `MultiCurrencyEnabled = 1` and no rate for today, entries in foreign currency are left out of `Balance_ShopCurr` (division by NULL). `Amount_ShopCurr` falls back to a rate of 1 in that case.\n- The setting `DoNOTChargeShipCostOnSecondDelivery` is read but not used.\n- An invoice with order lines from several external orders produces one row per `OrderNrExternal`.\n- Reminder rows are built by joining the reminder lines twice. A reminder with several lines can therefore return several rows with different `InvoiceNr`/`ReminderLevel` combinations.\n- Virtual `FPY_` events are produced once per customer account entry of the invoice, so more than one `FPY_` row per invoice is possible.\n- An unknown `ShopId` returns an empty result, not an error.\n- Temporary tables are dropped at the end via `util.TempTableDrop` (not attached).\n\nDocumentation: https://pixi-api-docs.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": "Returns customer account events (invoices, matches/payments, reminders and virtual full-payment events) of one shop within a date range, with balance and reminder levels.\n\nCollects all customer account events of the customers of shop `ShopId` that happened in a date range and returns them as one event list. Reminder sendings and full payments of invoices are treated as additional events.\n\n**Date range**\n- If `StartDate` is NULL, the range starts on the first day of the current month. Otherwise it starts at 00:00 of `StartDate`.\n- If `EndDate` is NULL, the range ends at the end of today. Otherwise it ends at 23:59:59.997 of `EndDate`.\n\n**Event types collected**\n1. **Invoice events**: `CustomerAccount` entries with `EventID = 'INV'` whose `EventDate` is in the range. `EventKey` = `CAE_`.\n2. **Reminder events**: reminders (`Reminders` joined with `ReminderLines`) whose `ReminderSentDate` is in the range. They are returned with `EventID = 'REM'`. The amount is the negative of reminder total minus reminder costs, and `ReminderLevel` comes from the reminder line. `EventKey` = `REM_`.\n3. **Match events**: `CustomerAccountMatch` records created in the range that link an invoice entry (`EventID = 'INV'`) with another, different customer account entry. Both link directions are taken into account. The row carries the `EventID` and `EventDate` of the counterpart entry (for example a payment). The amount is the absolute match amount, and `EventUpdateDate` is the match creation date. `EventKey` = `CAM_`.\n4. **Virtual full-payment events**: for an invoice of a returned customer whose matches up to `EndDate` add up exactly to the invoice total, a virtual event is created with `EventID = 'REM'` and amount 0. Its date is the last match creation date plus 1 ms. The customer must also have at least one match event in the range, and the event is dropped if its date is before the range start. `EventKey` = `FPY_`.\n\n**Customer filter**\n- Only customers whose `CustomerOf` equals `ShopId` are returned.\n- If `CustomerNumberIsNumeric = 1`, only customers whose `CustomerNrExternal` consists solely of digits are returned. With `0` (default, or NULL) all customers of the shop are returned.\n\n**Reminder levels**\n- For every invoice without a virtual full-payment event, the highest `HighestReminderLevel` of all reminders containing the invoice is determined (invoice dated before `EndDate`).\n- This value is written to `ReminderLevel` of all non-`REM` events of the invoice.\n- `CustomerReminderLevel` is the maximum of these levels over all open invoices of the customer. It is set on all events of the customer.\n\n**Amounts and currencies**\n- `Balance_ShopCurr` is the sum of all customer account amounts with `EventDate` before `EndDate`.\n- If the setting `MultiCurrencyEnabled` is 1, these amounts are converted with the exchange rate of the current day.\n- `Amount_ShopCurr` is the event amount converted the same way. A missing rate counts as 1.\n\n**Output**\n- Each event row contains the external customer number, invoice number and external order number.\n- Only events that can be linked to an invoice in `Invoices` are returned.\n- The result is `DISTINCT` and sorted by `EventUpdateDate`, then `EventDate`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | No | Start of the date range (time part is ignored, 00:00 is used). NULL means the first day of the current month. |\n| `EndDate` | datetime | No | End of the date range (end of the given day is used). NULL means the end of today. |\n| `ShopId` | varchar(3) | Yes | Shop whose customers are returned (compared with `Customers.CustomerOf`). Must not be empty. |\n| `CustomerNumberIsNumeric` | bit | No | Restricts the result to customers with a purely numeric external customer number. NULL is treated as 0. |\n\n- All reads use `NOLOCK`; results may contain uncommitted data.\n- Exchange rates are always taken for the **current date** (`ExchDate` = today), not for the event date. With `MultiCurrencyEnabled = 1` and no rate for today, entries in foreign currency are left out of `Balance_ShopCurr` (division by NULL). `Amount_ShopCurr` falls back to a rate of 1 in that case.\n- The setting `DoNOTChargeShipCostOnSecondDelivery` is read but not used.\n- An invoice with order lines from several external orders produces one row per `OrderNrExternal`.\n- Reminder rows are built by joining the reminder lines twice. A reminder with several lines can therefore return several rows with different `InvoiceNr`/`ReminderLevel` combinations.\n- Virtual `FPY_` events are produced once per customer account entry of the invoice, so more than one `FPY_` row per invoice is possible.\n- An unknown `ShopId` returns an empty result, not an error.\n- Temporary tables are dropped at the end via `util.TempTableDrop` (not attached).\n\nDocumentation: https://pixi-api-docs.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": "Returns customers created or changed since a given point in time, optionally up to an end date, ordered by change date and limited to a maximum row count.\n\nReads the customer master table and returns all customers whose change date lies in the requested time window. This call is typically used for incremental (delta) synchronisation of customers into an external system.\n\n- The **change date** of a customer is its `UpdateDate`, or its `CreateDate` if the customer has never been updated. This value is also returned as column `UpdateDate`.\n- If `To` is omitted or empty, all customers with a change date `>= Since` are returned.\n- If `To` is set, customers with a change date between `Since` and `To` (both inclusive) are returned.\n- The result is sorted by change date in ascending order (oldest change first).\n- At most `Rowcount` rows are returned (default `1000`).\n\nFor each customer the call returns the customer key, the keys of the billing and shipping address, a shipping lock flag, the `CustomerOf` value, e-mail address and name.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | Yes | Start of the time window (inclusive). Customers whose change date (`UpdateDate`, otherwise `CreateDate`) is on or after this value are returned. |\n| `To` | datetime | No | Optional end of the time window (inclusive). If omitted or empty, there is no upper limit. |\n| `Rowcount` | int | No | Maximum number of rows to return. `0` means no limit. |\n\n- The table is read `WITH (NOLOCK)`, so uncommitted changes may be returned.\n- The limit is applied with `SET ROWCOUNT`. Passing `Rowcount` = `0` removes the limit and returns all matching rows.\n- The check for an empty `To` compares against `''`, which SQL Server converts to `1900-01-01 00:00:00`. Passing exactly this date as `To` is therefore treated like no end date.\n- Paging pattern: use the highest returned `UpdateDate` as the next `Since`. Because the filter is `>=`, the last record(s) are returned again; deduplicate by `CustKey`. There is no secondary sort key, so if more than `Rowcount` customers share the same change date, the loop cannot advance past them – increase `Rowcount` in that case.\n- `ShipLock` is `1` when the customer field `SLocked` is `Y`, otherwise `0`.\n\nDocumentation: https://pixi-api-docs.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": "Returns customers created or changed since a given point in time, optionally up to an end date, ordered by change date and limited to a maximum row count.\n\nReads the customer master table and returns all customers whose change date lies in the requested time window. This call is typically used for incremental (delta) synchronisation of customers into an external system.\n\n- The **change date** of a customer is its `UpdateDate`, or its `CreateDate` if the customer has never been updated. This value is also returned as column `UpdateDate`.\n- If `To` is omitted or empty, all customers with a change date `>= Since` are returned.\n- If `To` is set, customers with a change date between `Since` and `To` (both inclusive) are returned.\n- The result is sorted by change date in ascending order (oldest change first).\n- At most `Rowcount` rows are returned (default `1000`).\n\nFor each customer the call returns the customer key, the keys of the billing and shipping address, a shipping lock flag, the `CustomerOf` value, e-mail address and name.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | Yes | Start of the time window (inclusive). Customers whose change date (`UpdateDate`, otherwise `CreateDate`) is on or after this value are returned. |\n| `To` | datetime | No | Optional end of the time window (inclusive). If omitted or empty, there is no upper limit. |\n| `Rowcount` | int | No | Maximum number of rows to return. `0` means no limit. |\n\n- The table is read `WITH (NOLOCK)`, so uncommitted changes may be returned.\n- The limit is applied with `SET ROWCOUNT`. Passing `Rowcount` = `0` removes the limit and returns all matching rows.\n- The check for an empty `To` compares against `''`, which SQL Server converts to `1900-01-01 00:00:00`. Passing exactly this date as `To` is therefore treated like no end date.\n- Paging pattern: use the highest returned `UpdateDate` as the next `Since`. Because the filter is `>=`, the last record(s) are returned again; deduplicate by `CustKey`. There is no secondary sort key, so if more than `Rowcount` customers share the same change date, the loop cannot advance past them – increase `Rowcount` in that case.\n- `ShipLock` is `1` when the customer field `SLocked` is `Y`, otherwise `0`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the comments of a customer (from the customer history) and/or of an order, newest first, with offset-based paging.\n\nCollects comments for a customer, an order or both and returns them in one list.\n\n1. If both `CustomerNrExternal` and `OrderNr` are `NULL` or empty, a single error row (`ReturnCode` = `ERROR`) is returned and nothing else happens.\n2. If `CustomerNrExternal` is not `NULL`, all entries of the customer history whose note text is not `NULL` are collected for the customer with this external customer number, as type `CustomerComment`. They are numbered newest first by history update date.\n3. If `OrderNr` is not `NULL`, all order comments of this order number are appended as type `OrderComment` (no defined order within this group).\n4. Each collected row gets a running number `Offset` starting at 0, in the order of collection (customer comments first, then order comments).\n5. The result returns at most `RowCount` rows whose `Offset` is greater than or equal to `@Offset`, sorted by `Date` descending.\n\nBoth filters can be combined; the comments are then merged into one result set.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustomerNrExternal` | varchar(255) | No | External customer number. If set, the customer's history comments are returned. |\n| `OrderNr` | varchar(50) | No | Order number. If set, the comments of this order are returned. |\n| `Offset` | int | No | Zero-based running number from which rows are returned (paging). |\n| `RowCount` | int | No | Maximum number of rows returned; 0 means no limit. |\n\n- The `Offset` numbering follows the collection order (customer comments by date descending, then order comments in undefined order), while the output is sorted by `Date` descending. With both filters set, paging via `@Offset` therefore does not necessarily correspond to the displayed date order.\n- `SET ROWCOUNT` limits the output; `RowCount` = 0 returns all rows.\n- The empty-check only rejects the call if both values are empty. An empty string (not `NULL`) for one parameter still runs that branch, e.g. `CustomerNrExternal` = '' searches for customers with an empty external number.\n- `Offset` is a `smallint`; more than 32,767 collected comments would cause an overflow error.\n- No `NOLOCK` hints are used.\n\nDocumentation: https://pixi-api-docs.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": "Returns the comments of a customer (from the customer history) and/or of an order, newest first, with offset-based paging.\n\nCollects comments for a customer, an order or both and returns them in one list.\n\n1. If both `CustomerNrExternal` and `OrderNr` are `NULL` or empty, a single error row (`ReturnCode` = `ERROR`) is returned and nothing else happens.\n2. If `CustomerNrExternal` is not `NULL`, all entries of the customer history whose note text is not `NULL` are collected for the customer with this external customer number, as type `CustomerComment`. They are numbered newest first by history update date.\n3. If `OrderNr` is not `NULL`, all order comments of this order number are appended as type `OrderComment` (no defined order within this group).\n4. Each collected row gets a running number `Offset` starting at 0, in the order of collection (customer comments first, then order comments).\n5. The result returns at most `RowCount` rows whose `Offset` is greater than or equal to `@Offset`, sorted by `Date` descending.\n\nBoth filters can be combined; the comments are then merged into one result set.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustomerNrExternal` | varchar(255) | No | External customer number. If set, the customer's history comments are returned. |\n| `OrderNr` | varchar(50) | No | Order number. If set, the comments of this order are returned. |\n| `Offset` | int | No | Zero-based running number from which rows are returned (paging). |\n| `RowCount` | int | No | Maximum number of rows returned; 0 means no limit. |\n\n- The `Offset` numbering follows the collection order (customer comments by date descending, then order comments in undefined order), while the output is sorted by `Date` descending. With both filters set, paging via `@Offset` therefore does not necessarily correspond to the displayed date order.\n- `SET ROWCOUNT` limits the output; `RowCount` = 0 returns all rows.\n- The empty-check only rejects the call if both values are empty. An empty string (not `NULL`) for one parameter still runs that branch, e.g. `CustomerNrExternal` = '' searches for customers with an empty external number.\n- `Offset` is a `smallint`; more than 32,767 collected comments would cause an overflow error.\n- No `NOLOCK` hints are used.\n\nDocumentation: https://pixi-api-docs.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": "Returns customers with their main address data in pages ordered by CustKey, intended for synchronisation with CRM systems.\n\nReturns customer records together with the address referenced by the customer (`AddrRef`).\n\n- Only customers with `CustKey` greater than `CustKeyStart` are returned.\n- If `CustomerOf` is empty or NULL, customers of all shops are returned; otherwise only customers whose `CustomerOf` matches.\n- At most `Rows` rows are returned, sorted by `CustKey` ascending.\n\n**Paging:** start with `CustKeyStart = 0`, then pass the highest `CustKey` of the previous page as `CustKeyStart` for the next call. Stop when fewer than `Rows` rows come back.\n\nAn empty `VATID` is returned as NULL. `Locked` is `Y` if the customer is locked for sales (`SLocked`) or for delivery (`DLocked`), otherwise `N`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKeyStart` | int | No | Only customers with a `CustKey` greater than this value are returned. Use the last `CustKey` of the previous page for paging. |\n| `Rows` | int | No | Maximum number of rows returned (page size). |\n| `CustomerOf` | varchar(3) | No | Shop code the customer belongs to. Empty or NULL returns customers of all shops. |\n\n- Tables are read with `NOLOCK`, so uncommitted changes may be visible and rows can occasionally be missed or duplicated during concurrent writes.\n- The address is joined with a LEFT JOIN; customers without a matching address are still returned with NULL address columns.\n- Despite the header comment about \"safe XML values\", the code does not transform the values apart from `VATID` and `Locked`.\n\nDocumentation: https://pixi-api-docs.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": "Returns customers with their main address data in pages ordered by CustKey, intended for synchronisation with CRM systems.\n\nReturns customer records together with the address referenced by the customer (`AddrRef`).\n\n- Only customers with `CustKey` greater than `CustKeyStart` are returned.\n- If `CustomerOf` is empty or NULL, customers of all shops are returned; otherwise only customers whose `CustomerOf` matches.\n- At most `Rows` rows are returned, sorted by `CustKey` ascending.\n\n**Paging:** start with `CustKeyStart = 0`, then pass the highest `CustKey` of the previous page as `CustKeyStart` for the next call. Stop when fewer than `Rows` rows come back.\n\nAn empty `VATID` is returned as NULL. `Locked` is `Y` if the customer is locked for sales (`SLocked`) or for delivery (`DLocked`), otherwise `N`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKeyStart` | int | No | Only customers with a `CustKey` greater than this value are returned. Use the last `CustKey` of the previous page for paging. |\n| `Rows` | int | No | Maximum number of rows returned (page size). |\n| `CustomerOf` | varchar(3) | No | Shop code the customer belongs to. Empty or NULL returns customers of all shops. |\n\n- Tables are read with `NOLOCK`, so uncommitted changes may be visible and rows can occasionally be missed or duplicated during concurrent writes.\n- The address is joined with a LEFT JOIN; customers without a matching address are still returned with NULL address columns.\n- Despite the header comment about \"safe XML values\", the code does not transform the values apart from `VATID` and `Locked`.\n\nDocumentation: https://pixi-api-docs.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": "Returns CRM key figures per customer (order intervals, order counts, net revenue and return amounts per period) calculated from invoices and orders.\n\nCalculates one row of customer lifetime statistics per customer, based on invoices and orders.\n\n**Invoices**\n- Only invoices with `Total > 0` are used as the base. They are filtered by `InvDate` between `CalculationStart` and `CalculationEnd` (each bound only if set), by the invoice shop `InvShopID` = `CustomerOf` (if not empty) and by `CustRef` (if not 0/NULL).\n- Amounts are **net** amounts (`Total_Net`, and `Total_Net - Total_ShipCost_Net` for the values without shipping costs).\n- Return amounts per invoice are 0 minus the sum of the net amounts of all invoices that reference it via `RefToInvoiceKey` (credit notes). These referencing invoices are not filtered by date or shop.\n- If the setting `MultiCurrencyEnabled` is `1`, all amounts are divided by the exchange rate of the invoice (`ExchRateId`) and `BaseCurrency` contains the code of the base currency of that exchange rate. Otherwise the amounts are returned in the original invoice currency and `BaseCurrency` is NULL.\n\n**Orders**\n- Orders are filtered by `UpdateDate` between `CalculationStart` and `CalculationEnd`, by the customer's `CustomerOf` and by `CustRef`. They are grouped by order number; the order date is the latest `CreateDate` of the order.\n- From these orders the first, second (next higher order number) and last order date per customer are determined.\n\n**Result**\n- Per customer: days since first/last order and between first/second and first/last order (relative to the current date), order counts in the last 90/365/730 days and in total, amounts of the first, second and last invoice (columns named `FirstOrder…`, `SecondOrder…`, `LastOrder…`), amounts in the first and second year after the first invoice, in the 365 days before the last invoice, in the two 365-day windows before `CalculationEnd` (or now), and overall totals.\n- Only customers with at least one matching invoice are returned.\n- Paging: at most `Rows` rows with `CustKey > Offset`, sorted by `CustKey` ascending. `Offset` is a customer key, not a row count: for the next page pass the last `CustKey` of the previous page.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustomerOf` | varchar(3) | No | Shop ID. Filters invoices by `InvShopID` and orders by the customer's `CustomerOf`. NULL or empty = all shops. |\n| `CalculationStart` | datetime | No | Lower bound for invoice date (`InvDate`) and order update date (`UpdateDate`). NULL = no lower bound. |\n| `CalculationEnd` | datetime | No | Upper bound for invoice date and order update date. Also the reference date for the `…FromNow…` columns; if NULL, the current date is used as reference and there is no upper bound. |\n| `CustRef` | int | No | Customer key to restrict the calculation to one customer. NULL or 0 = all customers. |\n| `Rows` | int | No | Maximum number of rows returned (page size). |\n| `Offset` | int | No | Only customers with `CustKey` greater than this value are returned. Pass the last `CustKey` of the previous page to get the next page. |\n\n- Read-only; all permanent tables except `Customers` are read `WITH (NOLOCK)`, so uncommitted data may be included.\n- The columns `FirstOrderTotal`, `SecondOrderTotal`, `LastOrderTotal` etc. are taken from the first, second and last **invoice** (by `InvoiceKey`), not from orders.\n- Day statistics and the 90/365/730-day order counts are always relative to `GETDATE()`, while the `…FromNow…` amounts are relative to `CalculationEnd` (or the current date if it is not set).\n- Window bounds are partly exclusive: e.g. `SecondYear…` uses dates strictly after first invoice + 365 days and strictly before + 730 days, so invoices exactly on the boundary are not counted in either year.\n- The shop filter uses `InvShopID` of the invoice for amounts but `CustomerOf` of the customer for orders; date filters use `InvDate` for invoices but `UpdateDate` for orders.\n- With multi-currency enabled, invoices without a matching exchange rate are skipped. A customer with invoices in different base currencies appears once per base currency; the period sums (`FirstYear…`, `LastYear…`, etc.) are then not separated by currency.\n- `DaysSince…` columns are NULL if no order of the customer matches the filters.\n- Computation is done with several temporary tables and correlated subqueries; restricting the date range or `CustRef` improves performance on large databases.\n\nDocumentation: https://pixi-api-docs.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": "Returns CRM key figures per customer (order intervals, order counts, net revenue and return amounts per period) calculated from invoices and orders.\n\nCalculates one row of customer lifetime statistics per customer, based on invoices and orders.\n\n**Invoices**\n- Only invoices with `Total > 0` are used as the base. They are filtered by `InvDate` between `CalculationStart` and `CalculationEnd` (each bound only if set), by the invoice shop `InvShopID` = `CustomerOf` (if not empty) and by `CustRef` (if not 0/NULL).\n- Amounts are **net** amounts (`Total_Net`, and `Total_Net - Total_ShipCost_Net` for the values without shipping costs).\n- Return amounts per invoice are 0 minus the sum of the net amounts of all invoices that reference it via `RefToInvoiceKey` (credit notes). These referencing invoices are not filtered by date or shop.\n- If the setting `MultiCurrencyEnabled` is `1`, all amounts are divided by the exchange rate of the invoice (`ExchRateId`) and `BaseCurrency` contains the code of the base currency of that exchange rate. Otherwise the amounts are returned in the original invoice currency and `BaseCurrency` is NULL.\n\n**Orders**\n- Orders are filtered by `UpdateDate` between `CalculationStart` and `CalculationEnd`, by the customer's `CustomerOf` and by `CustRef`. They are grouped by order number; the order date is the latest `CreateDate` of the order.\n- From these orders the first, second (next higher order number) and last order date per customer are determined.\n\n**Result**\n- Per customer: days since first/last order and between first/second and first/last order (relative to the current date), order counts in the last 90/365/730 days and in total, amounts of the first, second and last invoice (columns named `FirstOrder…`, `SecondOrder…`, `LastOrder…`), amounts in the first and second year after the first invoice, in the 365 days before the last invoice, in the two 365-day windows before `CalculationEnd` (or now), and overall totals.\n- Only customers with at least one matching invoice are returned.\n- Paging: at most `Rows` rows with `CustKey > Offset`, sorted by `CustKey` ascending. `Offset` is a customer key, not a row count: for the next page pass the last `CustKey` of the previous page.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustomerOf` | varchar(3) | No | Shop ID. Filters invoices by `InvShopID` and orders by the customer's `CustomerOf`. NULL or empty = all shops. |\n| `CalculationStart` | datetime | No | Lower bound for invoice date (`InvDate`) and order update date (`UpdateDate`). NULL = no lower bound. |\n| `CalculationEnd` | datetime | No | Upper bound for invoice date and order update date. Also the reference date for the `…FromNow…` columns; if NULL, the current date is used as reference and there is no upper bound. |\n| `CustRef` | int | No | Customer key to restrict the calculation to one customer. NULL or 0 = all customers. |\n| `Rows` | int | No | Maximum number of rows returned (page size). |\n| `Offset` | int | No | Only customers with `CustKey` greater than this value are returned. Pass the last `CustKey` of the previous page to get the next page. |\n\n- Read-only; all permanent tables except `Customers` are read `WITH (NOLOCK)`, so uncommitted data may be included.\n- The columns `FirstOrderTotal`, `SecondOrderTotal`, `LastOrderTotal` etc. are taken from the first, second and last **invoice** (by `InvoiceKey`), not from orders.\n- Day statistics and the 90/365/730-day order counts are always relative to `GETDATE()`, while the `…FromNow…` amounts are relative to `CalculationEnd` (or the current date if it is not set).\n- Window bounds are partly exclusive: e.g. `SecondYear…` uses dates strictly after first invoice + 365 days and strictly before + 730 days, so invoices exactly on the boundary are not counted in either year.\n- The shop filter uses `InvShopID` of the invoice for amounts but `CustomerOf` of the customer for orders; date filters use `InvDate` for invoices but `UpdateDate` for orders.\n- With multi-currency enabled, invoices without a matching exchange rate are skipped. A customer with invoices in different base currencies appears once per base currency; the period sums (`FirstYear…`, `LastYear…`, etc.) are then not separated by currency.\n- `DaysSince…` columns are NULL if no order of the customer matches the filters.\n- Computation is done with several temporary tables and correlated subqueries; restricting the date range or `CustRef` improves performance on large databases.\n\nDocumentation: https://pixi-api-docs.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": "Returns the cumulated net sales per customer from invoices, reduced by referencing credit notes, optionally filtered by shops and invoice date, with keyset paging.\n\nCalculates a sales figure per customer (`CustKey`) from the invoice table and returns one row per customer and base currency.\n\n**Steps**\n\n1. An empty `CustomerOf` is treated as `NULL`. If given, it is parsed as XML (`/SHOPS/SHOP`, value `SHOPID`, as element or attribute). Only shop IDs that exist in `Shops` are kept.\n2. Invoices are selected if:\n - the gross total `Total` is greater than 0 (credit notes with negative totals are not counted as primary invoices),\n - the invoice date `InvDate` lies within `CalculationStart` … `CalculationEnd` (each bound inclusive and optional),\n - when `CustomerOf` is set, the customer's `CustomerOf` shop is one of the given shops.\n3. For each invoice, the net total (`Total_Net`) and the net total without shipping costs (`Total_Net - Total_ShipCost_Net`) are taken. The net totals of all invoices that reference it via `RefToInvoiceKey` (typically credit notes) are added to these values.\n4. **Currency handling** depends on the setting `MultiCurrencyEnabled`:\n - not `1`: amounts stay in the original invoice currency and `BaseCurrency` is `NULL`;\n - `1`: every amount is divided by the exchange rate of the invoice (`pixi.ExchRate`) and `BaseCurrency` contains the code of the base currency of that rate.\n5. The results are grouped by `CustKey` and `BaseCurrency`.\n\n**Paging**\n\nPaging uses keys: only customers with `CustKey` greater than `Offset` are returned, sorted by `CustKey` ascending, limited to `Rows` rows. For the next page, pass the last returned `CustKey` as `Offset`. `Offset` is not a row count.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustomerOf` | varchar(max) | No | XML list of pixi* shops (`/SHOPS/SHOP/SHOPID`). Only customers belonging to these shops are evaluated. `NULL` or empty: all customers. |\n| `CalculationStart` | datetime | No | Earliest invoice date (inclusive). `NULL`: no lower bound. |\n| `CalculationEnd` | datetime | No | Latest invoice date (inclusive). `NULL`: no upper bound. |\n| `Rows` | int | No | Maximum number of rows returned. |\n| `Offset` | int | No | Only customers with `CustKey` greater than this value are returned. Pass the last `CustKey` of the previous page. |\n\n- All reads use `NOLOCK`, so results may include uncommitted data.\n- If `CustomerOf` is set but none of the shop IDs exist in `Shops`, no rows are returned. Invalid XML causes an error raised by `sp_xml_preparedocument`.\n- Without multi-currency (`MultiCurrencyEnabled` not `1`), amounts in different invoice currencies are summed together without conversion.\n- With multi-currency, invoices without an exchange rate (`ExchRateId` not found in `pixi.ExchRate`) are excluded, and referencing credit notes without an exchange rate are ignored in the sums. Converted amounts are stored with 9 decimal places.\n- With multi-currency a customer can appear in several rows (one per base currency). Because `Rows` limits rows, not customers, a page can end in the middle of a customer's rows; using that `CustKey` as the next `Offset` skips the remaining rows of that customer.\n- The date filter is applied only to the primary invoice; referencing credit notes are included regardless of their date.\n- A total-return flag is calculated internally but not returned.\n- The database currency is read via `pixi.GetDatabaseCurrency()`, but the values are not used in the result.\n\nDocumentation: https://pixi-api-docs.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": "Returns the cumulated net sales per customer from invoices, reduced by referencing credit notes, optionally filtered by shops and invoice date, with keyset paging.\n\nCalculates a sales figure per customer (`CustKey`) from the invoice table and returns one row per customer and base currency.\n\n**Steps**\n\n1. An empty `CustomerOf` is treated as `NULL`. If given, it is parsed as XML (`/SHOPS/SHOP`, value `SHOPID`, as element or attribute). Only shop IDs that exist in `Shops` are kept.\n2. Invoices are selected if:\n - the gross total `Total` is greater than 0 (credit notes with negative totals are not counted as primary invoices),\n - the invoice date `InvDate` lies within `CalculationStart` … `CalculationEnd` (each bound inclusive and optional),\n - when `CustomerOf` is set, the customer's `CustomerOf` shop is one of the given shops.\n3. For each invoice, the net total (`Total_Net`) and the net total without shipping costs (`Total_Net - Total_ShipCost_Net`) are taken. The net totals of all invoices that reference it via `RefToInvoiceKey` (typically credit notes) are added to these values.\n4. **Currency handling** depends on the setting `MultiCurrencyEnabled`:\n - not `1`: amounts stay in the original invoice currency and `BaseCurrency` is `NULL`;\n - `1`: every amount is divided by the exchange rate of the invoice (`pixi.ExchRate`) and `BaseCurrency` contains the code of the base currency of that rate.\n5. The results are grouped by `CustKey` and `BaseCurrency`.\n\n**Paging**\n\nPaging uses keys: only customers with `CustKey` greater than `Offset` are returned, sorted by `CustKey` ascending, limited to `Rows` rows. For the next page, pass the last returned `CustKey` as `Offset`. `Offset` is not a row count.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustomerOf` | varchar(max) | No | XML list of pixi* shops (`/SHOPS/SHOP/SHOPID`). Only customers belonging to these shops are evaluated. `NULL` or empty: all customers. |\n| `CalculationStart` | datetime | No | Earliest invoice date (inclusive). `NULL`: no lower bound. |\n| `CalculationEnd` | datetime | No | Latest invoice date (inclusive). `NULL`: no upper bound. |\n| `Rows` | int | No | Maximum number of rows returned. |\n| `Offset` | int | No | Only customers with `CustKey` greater than this value are returned. Pass the last `CustKey` of the previous page. |\n\n- All reads use `NOLOCK`, so results may include uncommitted data.\n- If `CustomerOf` is set but none of the shop IDs exist in `Shops`, no rows are returned. Invalid XML causes an error raised by `sp_xml_preparedocument`.\n- Without multi-currency (`MultiCurrencyEnabled` not `1`), amounts in different invoice currencies are summed together without conversion.\n- With multi-currency, invoices without an exchange rate (`ExchRateId` not found in `pixi.ExchRate`) are excluded, and referencing credit notes without an exchange rate are ignored in the sums. Converted amounts are stored with 9 decimal places.\n- With multi-currency a customer can appear in several rows (one per base currency). Because `Rows` limits rows, not customers, a page can end in the middle of a customer's rows; using that `CustKey` as the next `Offset` skips the remaining rows of that customer.\n- The date filter is applied only to the primary invoice; referencing credit notes are included regardless of their date.\n- A total-return flag is calculated internally but not returned.\n- The database currency is read via `pixi.GetDatabaseCurrency()`, but the values are not used in the result.\n\nDocumentation: https://pixi-api-docs.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": "Returns the customer account balance (sum of all account entries up to an optional date) for a customer identified by internal key or external customer number.\n\nCalculates the balance of the customer account (`CustomerAccount`) for one or more customers.\n\n**Customer lookup**\n- `CustKey` is compared with the external customer number (`CustomerNrExternal`) and, if it can be converted to an integer, with the internal customer key (`CustKey`). A customer matches if **either** comparison is true.\n- If `ShopId` is given (not empty), only customers whose `CustomerOf` equals this shop are considered.\n\n**Date limit**\n- If `DateTo` is given, it is extended to the end of that day (23:59:59.997). Only account entries with an `EventDate` up to this point, or without an `EventDate`, are summed.\n- Without `DateTo`, all entries are summed.\n\n**Currency handling**\n- The setting `MultiCurrencyEnabled` is read at runtime.\n- If it is `1`, each entry amount is divided by the exchange rate of the entry (`ExchRateId`) and the result is grouped by the base currency of that exchange rate (`BaseCurrency`).\n- Otherwise amounts are summed as stored and `BaseCurrency` is the database (home) currency from the setting `HomeCurrency`.\n\n**Result**\nOne row per matching customer (and per base currency in multi-currency mode) with the balance `CAbalance` (as `money`) and the date of the latest included account entry `LastEventDate`. Customers without any account entries are returned with balance `0` and `LastEventDate` = NULL. No row is returned if no customer matches.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | varchar(200) | Yes | Customer identifier: either the external customer number (`CustomerNrExternal`) or the internal customer key (`CustKey`, if numeric). |\n| `DateTo` | datetime | No | Optional cut-off date. Only account entries up to the end of this day are included. NULL means all entries. |\n| `ShopId` | varchar(3) | No | Optional shop filter on the customer's `CustomerOf`. NULL or empty means all shops. |\n\n- All tables are read with `NOLOCK`; the balance may include uncommitted data.\n- Because `CustKey` is matched against both the external number and the internal key, more than one customer can be returned (e.g. one customer with internal key `123` and another with external number `123`). Use `ShopId` or check `CustomerId` in the result.\n- Pitfall with `DateTo`: the date filter is applied after the outer join. A customer whose account entries all lie **after** `DateTo` is not returned at all (no row instead of a row with balance 0).\n- Multi-currency mode: entries without an exchange rate produce NULL in the division and are ignored in the sum; they also form their own group with `BaseCurrency` = NULL. Entries with different base currencies yield separate rows for the same customer.\n- An empty `ShopId` is treated like NULL (no shop filter).\n\nDocumentation: https://pixi-api-docs.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": "Returns the customer account balance (sum of all account entries up to an optional date) for a customer identified by internal key or external customer number.\n\nCalculates the balance of the customer account (`CustomerAccount`) for one or more customers.\n\n**Customer lookup**\n- `CustKey` is compared with the external customer number (`CustomerNrExternal`) and, if it can be converted to an integer, with the internal customer key (`CustKey`). A customer matches if **either** comparison is true.\n- If `ShopId` is given (not empty), only customers whose `CustomerOf` equals this shop are considered.\n\n**Date limit**\n- If `DateTo` is given, it is extended to the end of that day (23:59:59.997). Only account entries with an `EventDate` up to this point, or without an `EventDate`, are summed.\n- Without `DateTo`, all entries are summed.\n\n**Currency handling**\n- The setting `MultiCurrencyEnabled` is read at runtime.\n- If it is `1`, each entry amount is divided by the exchange rate of the entry (`ExchRateId`) and the result is grouped by the base currency of that exchange rate (`BaseCurrency`).\n- Otherwise amounts are summed as stored and `BaseCurrency` is the database (home) currency from the setting `HomeCurrency`.\n\n**Result**\nOne row per matching customer (and per base currency in multi-currency mode) with the balance `CAbalance` (as `money`) and the date of the latest included account entry `LastEventDate`. Customers without any account entries are returned with balance `0` and `LastEventDate` = NULL. No row is returned if no customer matches.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | varchar(200) | Yes | Customer identifier: either the external customer number (`CustomerNrExternal`) or the internal customer key (`CustKey`, if numeric). |\n| `DateTo` | datetime | No | Optional cut-off date. Only account entries up to the end of this day are included. NULL means all entries. |\n| `ShopId` | varchar(3) | No | Optional shop filter on the customer's `CustomerOf`. NULL or empty means all shops. |\n\n- All tables are read with `NOLOCK`; the balance may include uncommitted data.\n- Because `CustKey` is matched against both the external number and the internal key, more than one customer can be returned (e.g. one customer with internal key `123` and another with external number `123`). Use `ShopId` or check `CustomerId` in the result.\n- Pitfall with `DateTo`: the date filter is applied after the outer join. A customer whose account entries all lie **after** `DateTo` is not returned at all (no row instead of a row with balance 0).\n- Multi-currency mode: entries without an exchange rate produce NULL in the division and are ignored in the sum; they also form their own group with `BaseCurrency` = NULL. Entries with different base currencies yield separate rows for the same customer.\n- An empty `ShopId` is treated like NULL (no shop filter).\n\nDocumentation: https://pixi-api-docs.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": "Returns the customer account events (debits, credits, payments, direct debits, manual bookings) filtered by customer, event type and date range.\n\nReads entries from the customer account ledger (`CustomerAccount`) and enriches them with display and status information.\n\n**Filters** (all optional, combined with AND; a parameter left out or `NULL` does not filter):\n- `CustKey`: only entries whose `CustRef` equals this customer key.\n- `EventID`: only entries of this event type.\n- `DateFrom` / `DateTo`: only entries with `EventDate` in the range (both bounds inclusive).\n\nIf no parameter is given, all customer account entries are returned.\n\n**Enrichment per entry:**\n- `EventName`: description of the event type from `CustomerAccountEvents`, translated via the translation table (language ID 2, falls back to the untranslated text). For entries linked to a direct debit (`DTAUSref` set), the translated direct debit state is appended in square brackets, e.g. `Lastschrift [Exportiert]`.\n- `Number`: a human-readable reference depending on the linked object, checked in this order: invoice number (`InvoiceRef`), bank line text `BankText01` (`BanklineRef`), account number of the direct debit (`DTAUSref`), reference of the manual booking (`ManualBookingRef`), otherwise an empty string.\n- `OpenTOMatch`: `Amount` minus the already matched amount (NULL counts as 0).\n- `AllowToDelete`: 1 if the entry may be deleted, otherwise 0. An entry is deletable only if it is not matched with other entries and either the event type and the direct debit state allow deletion, or it belongs to an invoice that is not paid, not paid by credit card (`CCPPaymentDone` not `Y`), has no reminder lines and whose lines are all in status `EIN` or all in status `RET` (or has no lines).\n- `CCPTranLogKey`: a credit card transaction log entry of the same customer whose invoice number equals the invoice number or the referenced invoice number of the linked invoice.\n- `OrderCurrency`: currency code (`CodeA`) of the entry.\n- `IsDeleted`: always 0.\n\nThe result has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | No | Customer key (`CustRef`). Only entries of this customer are returned. NULL = all customers. |\n| `EventID` | varchar(3) | No | Event type ID from `CustomerAccountEvents`. NULL = all event types. |\n| `DateFrom` | datetime | No | Lower bound for `EventDate` (inclusive). NULL = no lower bound. |\n| `DateTo` | datetime | No | Upper bound for `EventDate` (inclusive). NULL = no upper bound. |\n\n- All reads use `NOLOCK`, so uncommitted data may appear.\n- The setting `CaEnabled` changes the \"paid\" check for `AllowToDelete`: if it is `0` or missing, `Invoices.Payed` is used; otherwise the latest creation date in `CustomerAccountMatch` for the entry is used.\n- The deletion rule is an inline copy of `fPixi_CA_canIdeleteEvent`, but without that function's additional check on the invoice scan-out date (`ScanOutDate`). Results may therefore differ from the function.\n- Entries whose `CurrencyId` has no row in `pixi.Currency` are not returned (inner join).\n- If the event type has no row in `CustomerAccountEvents`, `EventName` and `AllowToDelete` are NULL.\n- `DateTo` is compared with `<=`; a pure date such as `2024-03-31` means midnight, so entries later that day are excluded.\n- If several returned entries reference the same direct debit (`DTAUSref`), the creation of a unique index on an internal temporary table can fail with a SQL error; filtering by customer usually avoids this.\n- The view `PV_CustomerAccountMatchGroup` is based on `PV_CustomerAccountBond`, whose definition is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Returns the customer account events (debits, credits, payments, direct debits, manual bookings) filtered by customer, event type and date range.\n\nReads entries from the customer account ledger (`CustomerAccount`) and enriches them with display and status information.\n\n**Filters** (all optional, combined with AND; a parameter left out or `NULL` does not filter):\n- `CustKey`: only entries whose `CustRef` equals this customer key.\n- `EventID`: only entries of this event type.\n- `DateFrom` / `DateTo`: only entries with `EventDate` in the range (both bounds inclusive).\n\nIf no parameter is given, all customer account entries are returned.\n\n**Enrichment per entry:**\n- `EventName`: description of the event type from `CustomerAccountEvents`, translated via the translation table (language ID 2, falls back to the untranslated text). For entries linked to a direct debit (`DTAUSref` set), the translated direct debit state is appended in square brackets, e.g. `Lastschrift [Exportiert]`.\n- `Number`: a human-readable reference depending on the linked object, checked in this order: invoice number (`InvoiceRef`), bank line text `BankText01` (`BanklineRef`), account number of the direct debit (`DTAUSref`), reference of the manual booking (`ManualBookingRef`), otherwise an empty string.\n- `OpenTOMatch`: `Amount` minus the already matched amount (NULL counts as 0).\n- `AllowToDelete`: 1 if the entry may be deleted, otherwise 0. An entry is deletable only if it is not matched with other entries and either the event type and the direct debit state allow deletion, or it belongs to an invoice that is not paid, not paid by credit card (`CCPPaymentDone` not `Y`), has no reminder lines and whose lines are all in status `EIN` or all in status `RET` (or has no lines).\n- `CCPTranLogKey`: a credit card transaction log entry of the same customer whose invoice number equals the invoice number or the referenced invoice number of the linked invoice.\n- `OrderCurrency`: currency code (`CodeA`) of the entry.\n- `IsDeleted`: always 0.\n\nThe result has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | No | Customer key (`CustRef`). Only entries of this customer are returned. NULL = all customers. |\n| `EventID` | varchar(3) | No | Event type ID from `CustomerAccountEvents`. NULL = all event types. |\n| `DateFrom` | datetime | No | Lower bound for `EventDate` (inclusive). NULL = no lower bound. |\n| `DateTo` | datetime | No | Upper bound for `EventDate` (inclusive). NULL = no upper bound. |\n\n- All reads use `NOLOCK`, so uncommitted data may appear.\n- The setting `CaEnabled` changes the \"paid\" check for `AllowToDelete`: if it is `0` or missing, `Invoices.Payed` is used; otherwise the latest creation date in `CustomerAccountMatch` for the entry is used.\n- The deletion rule is an inline copy of `fPixi_CA_canIdeleteEvent`, but without that function's additional check on the invoice scan-out date (`ScanOutDate`). Results may therefore differ from the function.\n- Entries whose `CurrencyId` has no row in `pixi.Currency` are not returned (inner join).\n- If the event type has no row in `CustomerAccountEvents`, `EventName` and `AllowToDelete` are NULL.\n- `DateTo` is compared with `<=`; a pure date such as `2024-03-31` means midnight, so entries later that day are excluded.\n- If several returned entries reference the same direct debit (`DTAUSref`), the creation of a unique index on an internal temporary table can fail with a SQL error; filtering by customer usually avoids this.\n- The view `PV_CustomerAccountMatchGroup` is based on `PV_CustomerAccountBond`, whose definition is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Returns basic information about a customer: name, comment, DATEV account, lock flag, number of invoices per reminder level and external customer number.\n\nLooks up the customer with the internal key `CustKey` and joins its main address (`Customers.AddrRef` → `Addresses.AddrKey`).\n\nReturns one row with:\n- the name from the address record,\n- the customer history note (`CHisNote`) as `Comment`,\n- the DATEV account number as text,\n- the lock flag (`N` if not set),\n- the number of the customer's invoices at reminder level 1, 2 and 3,\n- the external customer number.\n\nIf no customer with this key exists, or the customer has no matching address record, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | Yes | Internal key of the customer (`Customers.CustKey`). |\n\n- All reads use `NOLOCK`, so the values may include uncommitted data.\n- Invoices at reminder levels higher than 3 are not counted.\n- The DATEV account number is cast to `varchar(10)`.\n- A comment in the code says that the column list is meant to be extended later.\n\nDocumentation: https://pixi-api-docs.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": "Returns basic information about a customer: name, comment, DATEV account, lock flag, number of invoices per reminder level and external customer number.\n\nLooks up the customer with the internal key `CustKey` and joins its main address (`Customers.AddrRef` → `Addresses.AddrKey`).\n\nReturns one row with:\n- the name from the address record,\n- the customer history note (`CHisNote`) as `Comment`,\n- the DATEV account number as text,\n- the lock flag (`N` if not set),\n- the number of the customer's invoices at reminder level 1, 2 and 3,\n- the external customer number.\n\nIf no customer with this key exists, or the customer has no matching address record, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | Yes | Internal key of the customer (`Customers.CustKey`). |\n\n- All reads use `NOLOCK`, so the values may include uncommitted data.\n- Invoices at reminder levels higher than 3 are not counted.\n- The DATEV account number is cast to `varchar(10)`.\n- A comment in the code says that the column list is meant to be extended later.\n\nDocumentation: https://pixi-api-docs.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": "Returns up to 10,000 customers with orders, starting at a customer key, with order, turnover, return and reminder statistics plus main address data.\n\nBuilds a customer list with key figures, driven by the orders in `OrderHeader`.\n\n1. `StartCustKey` (NULL is treated as `0`) selects the first customer. The call takes the first **10,000** distinct `CustRef` values from `OrderHeader` with `CustRef >= StartCustKey`, in ascending order, and counts their orders (`OrderCount`). Customers without any order are never listed.\n2. For each of these customers it calculates:\n - `DaysSinceLastOrder` / `DaysSinceFirstOrder`: days between today and the latest `OrderDate` in `Orderlines` of the order with the highest / lowest order number of the customer.\n - From `Invoices`: `Turnover_all` (sum of invoices with a positive total), `Turnover_avgPerOrder` (average of positive invoice totals), `ReturnCount` (number of invoices with a negative total), `ReturnValue` (sum of negative totals) and `ReminderLevel` (highest reminder level).\n - From `Invlines`: `ItemCount_all`, the sum of all positive `ItemQty` values.\n3. Currency handling depends on the setting `MultiCurrencyEnabled`:\n - not `1`: amounts are summed in the original invoice currency, `BaseCurrency` is NULL.\n - `1`: each invoice total is divided by the exchange rate of the invoice (`pixi.ExchRate`), and `BaseCurrency` holds the ISO code of the base currency.\n4. The result is joined with `Customers` and the customer's main address (`Customers.AddrRef` → `Addresses`) and sorted by `CustKey` ascending.\n\n**Paging:** to read the next block, call again with `StartCustKey` = last returned `CustKey` + 1 (the filter is inclusive).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartCustKey` | int | No | Lowest customer key (`CustKey`) to include (inclusive). NULL or omitted starts at 0. For paging pass the last returned `CustKey` + 1. |\n\n- All permanent tables are read with `NOLOCK`; figures may include uncommitted data.\n- Without multi-currency, `Turnover_all`, `Turnover_avgPerOrder` and `ReturnValue` can mix different currencies if a customer has invoices in several currencies.\n- With multi-currency enabled, invoices without a matching exchange rate record are ignored. If a customer's invoices refer to more than one base currency, the unique index on the temporary invoice table fails and the call ends with a SQL error.\n- `Turnover_avgPerOrder` is the average per positive invoice, not per order.\n- Days since first/last order are based on the lowest/highest order number, not on the earliest/latest order date; they are NULL if that order has no lines.\n- The block of 10,000 is taken from `OrderHeader` before the join with `Customers`/`Addresses`; customers missing there are dropped, so a block can contain fewer than 10,000 rows even if more customers follow. Continue paging until an empty result is returned.\n- The address is the main address (`AddrRef`), not the shipping address.\n- The aggregation over all orders and invoices can be expensive on large databases.\n\nDocumentation: https://pixi-api-docs.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": "Returns up to 10,000 customers with orders, starting at a customer key, with order, turnover, return and reminder statistics plus main address data.\n\nBuilds a customer list with key figures, driven by the orders in `OrderHeader`.\n\n1. `StartCustKey` (NULL is treated as `0`) selects the first customer. The call takes the first **10,000** distinct `CustRef` values from `OrderHeader` with `CustRef >= StartCustKey`, in ascending order, and counts their orders (`OrderCount`). Customers without any order are never listed.\n2. For each of these customers it calculates:\n - `DaysSinceLastOrder` / `DaysSinceFirstOrder`: days between today and the latest `OrderDate` in `Orderlines` of the order with the highest / lowest order number of the customer.\n - From `Invoices`: `Turnover_all` (sum of invoices with a positive total), `Turnover_avgPerOrder` (average of positive invoice totals), `ReturnCount` (number of invoices with a negative total), `ReturnValue` (sum of negative totals) and `ReminderLevel` (highest reminder level).\n - From `Invlines`: `ItemCount_all`, the sum of all positive `ItemQty` values.\n3. Currency handling depends on the setting `MultiCurrencyEnabled`:\n - not `1`: amounts are summed in the original invoice currency, `BaseCurrency` is NULL.\n - `1`: each invoice total is divided by the exchange rate of the invoice (`pixi.ExchRate`), and `BaseCurrency` holds the ISO code of the base currency.\n4. The result is joined with `Customers` and the customer's main address (`Customers.AddrRef` → `Addresses`) and sorted by `CustKey` ascending.\n\n**Paging:** to read the next block, call again with `StartCustKey` = last returned `CustKey` + 1 (the filter is inclusive).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartCustKey` | int | No | Lowest customer key (`CustKey`) to include (inclusive). NULL or omitted starts at 0. For paging pass the last returned `CustKey` + 1. |\n\n- All permanent tables are read with `NOLOCK`; figures may include uncommitted data.\n- Without multi-currency, `Turnover_all`, `Turnover_avgPerOrder` and `ReturnValue` can mix different currencies if a customer has invoices in several currencies.\n- With multi-currency enabled, invoices without a matching exchange rate record are ignored. If a customer's invoices refer to more than one base currency, the unique index on the temporary invoice table fails and the call ends with a SQL error.\n- `Turnover_avgPerOrder` is the average per positive invoice, not per order.\n- Days since first/last order are based on the lowest/highest order number, not on the earliest/latest order date; they are NULL if that order has no lines.\n- The block of 10,000 is taken from `OrderHeader` before the join with `Customers`/`Addresses`; customers missing there are dropped, so a block can contain fewer than 10,000 rows even if more customers follow. Continue paging until an empty result is returned.\n- The address is the main address (`AddrRef`), not the shipping address.\n- The aggregation over all orders and invoices can be expensive on large databases.\n\nDocumentation: https://pixi-api-docs.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": "Returns a customer's master data, addresses, orders, order lines, bundle lines, invoices, invoice lines and customer account summary and entries.\n\nCollects everything needed for a customer account view of one customer (`CustKey`) and returns it as nine result sets.\n\n**Order selection**\n\nThe orders come from `Orderlines` with `CustRef = @CustKey`. The procedure applies an optional filter on `Orderlines.OrderDate`:\n\n- `OrderDateFrom` and `OrderDateTo` set: `OrderDate >= OrderDateFrom` and `OrderDate < OrderDateTo`. The upper bound is exclusive.\n- Only `OrderDateFrom` set: `OrderDate >= OrderDateFrom`.\n- Otherwise: no date filter. This also applies when only `OrderDateTo` is set (see notes).\n\nAn order is included if at least one of its lines matches. All lines of a selected order are returned afterwards.\n\nThe invoices are all distinct `InvRef` values of the lines of the selected orders.\n\n**Result sets**\n\n1. Customer master data from `Customers`.\n2. All addresses of the customer (`AdrCustRef = @CustKey`), including bank and credit card data and the ISO country codes from `Countries`.\n3. Order headers of the selected orders, with the currency code.\n4. Order lines of the selected orders, sorted by `OrderNr`. Includes supplier item number, estimated delivery and a computed `ResQty`.\n5. Bundle order lines (`BundleOrderlines`) of the selected orders, sorted by `OrderNr`.\n6. Invoices linked to the selected orders.\n7. Invoice lines of these invoices, sorted by `InvoiceRef`.\n8. Financial summary of the customer account. It is calculated by `Pixi_CA_GetCustomerAccountSummary` and is not date-filtered.\n9. All customer account entries (`CustomerAccount`) of the customer, sorted by `CustomerAccountKey`. They are not date-filtered.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | Yes | Internal customer key (`Customers.CustKey`). |\n| `OrderDateFrom` | datetime | No | Lower bound (inclusive) for the order line date. NULL means no lower bound. |\n| `OrderDateTo` | datetime | No | Upper bound (exclusive) for the order line date. Only used together with `OrderDateFrom`; ignored if passed alone. |\n\n- **Date filter bug:** the third branch repeats the condition of the second one (`OrderDateFrom IS NOT NULL AND OrderDateTo IS NULL`). If only `OrderDateTo` is passed, it is ignored and all orders of the customer are returned. To set only an upper bound, also pass a very early `OrderDateFrom`.\n- **No locking:** all reads use `NOLOCK`, so uncommitted data can appear.\n- **Currency joins:** order headers, order lines, bundle lines, invoices, invoice lines and account entries are joined to `pixi.Currency` with an inner join. Records without a matching currency are not returned.\n- **`ResQty` in result set 4:**\n - The code ranks the active reservations of the same item by `ResDate` and `ResOrderlineRef`, across all customers and locations. Active means: order status in `OrderStates` with `FinalState = 'N'`, excluding `EIN`, `FUT` and `FUS`.\n - `ResQty` is the location stock (`ItemLocationSpecific.LocationQuantity`) minus the number of earlier reservations.\n - Lines without an active reservation get the full location stock.\n- **Always-NULL column:** `SOrderlineRef` is always NULL.\n- **Duplicate columns:** columns ending in `_OrderCurr` repeat the base column. The code marks them for removal.\n- **Repeated values:** `ShipCost` in result sets 4 and 5 is the order header value, repeated on every line.\n- **Sensitive data:** result set 2 returns credit card number, CVC and bank data. Handle the response accordingly.\n- **Result set 8:**\n - It depends on `Pixi_CA_GetCustomerAccountSummary`, which reads the settings `DoNOTChargeShipCostOnSecondDelivery`, `MultiCurrencyEnabled` and `HomeCurrency`.\n - It can be empty if the customer's shop or the `HomeCurrency` setting cannot be resolved.\n - With several currencies and multi-currency enabled, amounts are converted with the exchange rate of the current day.\n- **Non-existent customer:** for an unknown `CustKey` the result sets are simply empty. No error is raised.\n\nDocumentation: https://pixi-api-docs.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": "Returns a customer's master data, addresses, orders, order lines, bundle lines, invoices, invoice lines and customer account summary and entries.\n\nCollects everything needed for a customer account view of one customer (`CustKey`) and returns it as nine result sets.\n\n**Order selection**\n\nThe orders come from `Orderlines` with `CustRef = @CustKey`. The procedure applies an optional filter on `Orderlines.OrderDate`:\n\n- `OrderDateFrom` and `OrderDateTo` set: `OrderDate >= OrderDateFrom` and `OrderDate < OrderDateTo`. The upper bound is exclusive.\n- Only `OrderDateFrom` set: `OrderDate >= OrderDateFrom`.\n- Otherwise: no date filter. This also applies when only `OrderDateTo` is set (see notes).\n\nAn order is included if at least one of its lines matches. All lines of a selected order are returned afterwards.\n\nThe invoices are all distinct `InvRef` values of the lines of the selected orders.\n\n**Result sets**\n\n1. Customer master data from `Customers`.\n2. All addresses of the customer (`AdrCustRef = @CustKey`), including bank and credit card data and the ISO country codes from `Countries`.\n3. Order headers of the selected orders, with the currency code.\n4. Order lines of the selected orders, sorted by `OrderNr`. Includes supplier item number, estimated delivery and a computed `ResQty`.\n5. Bundle order lines (`BundleOrderlines`) of the selected orders, sorted by `OrderNr`.\n6. Invoices linked to the selected orders.\n7. Invoice lines of these invoices, sorted by `InvoiceRef`.\n8. Financial summary of the customer account. It is calculated by `Pixi_CA_GetCustomerAccountSummary` and is not date-filtered.\n9. All customer account entries (`CustomerAccount`) of the customer, sorted by `CustomerAccountKey`. They are not date-filtered.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | Yes | Internal customer key (`Customers.CustKey`). |\n| `OrderDateFrom` | datetime | No | Lower bound (inclusive) for the order line date. NULL means no lower bound. |\n| `OrderDateTo` | datetime | No | Upper bound (exclusive) for the order line date. Only used together with `OrderDateFrom`; ignored if passed alone. |\n\n- **Date filter bug:** the third branch repeats the condition of the second one (`OrderDateFrom IS NOT NULL AND OrderDateTo IS NULL`). If only `OrderDateTo` is passed, it is ignored and all orders of the customer are returned. To set only an upper bound, also pass a very early `OrderDateFrom`.\n- **No locking:** all reads use `NOLOCK`, so uncommitted data can appear.\n- **Currency joins:** order headers, order lines, bundle lines, invoices, invoice lines and account entries are joined to `pixi.Currency` with an inner join. Records without a matching currency are not returned.\n- **`ResQty` in result set 4:**\n - The code ranks the active reservations of the same item by `ResDate` and `ResOrderlineRef`, across all customers and locations. Active means: order status in `OrderStates` with `FinalState = 'N'`, excluding `EIN`, `FUT` and `FUS`.\n - `ResQty` is the location stock (`ItemLocationSpecific.LocationQuantity`) minus the number of earlier reservations.\n - Lines without an active reservation get the full location stock.\n- **Always-NULL column:** `SOrderlineRef` is always NULL.\n- **Duplicate columns:** columns ending in `_OrderCurr` repeat the base column. The code marks them for removal.\n- **Repeated values:** `ShipCost` in result sets 4 and 5 is the order header value, repeated on every line.\n- **Sensitive data:** result set 2 returns credit card number, CVC and bank data. Handle the response accordingly.\n- **Result set 8:**\n - It depends on `Pixi_CA_GetCustomerAccountSummary`, which reads the settings `DoNOTChargeShipCostOnSecondDelivery`, `MultiCurrencyEnabled` and `HomeCurrency`.\n - It can be empty if the customer's shop or the `HomeCurrency` setting cannot be resolved.\n - With several currencies and multi-currency enabled, amounts are converted with the exchange rate of the current day.\n- **Non-existent customer:** for an unknown `CustKey` the result sets are simply empty. No error is raised.\n\nDocumentation: https://pixi-api-docs.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": "Returns customers whose customer account has a positive suggested refund, with balance, open orders and match status, optionally filtered by shop and amount.\n\nDetermines which customers should receive a refund from their customer account (`CustomerAccount`).\n\n1. Empty `ShopId` is treated as `NULL`. `NULL` values for `AmountFrom` / `AmountTo` fall back to `0` / `1000000`.\n2. All customers whose customer account entries sum up to a positive amount are selected as candidates.\n3. For these candidates the internal procedure `Pixi_CA_GetSummaryList` calculates per customer:\n - `FinancialBalance`: sum of all customer account amounts.\n - `OpenOrders`: value of order lines in an open state (`OrderStates.CA_IsOpenOrder = 1`) that are not yet invoiced, reduced by unused vouchers and increased by shipping costs. Only orders whose payment method has `CA_SubstractFromopenOrdersWhenRefund = 0` count; negative values per currency are set to 0.\n - `SuggestedRefund`: refundable account amount (entries without `DoNotRefund`, plus the matched part of entries with `DoNotRefund`) minus `OpenOrders`.\n - `OpenToMatch`: amount not yet matched.\n - `IsMatched`: match flag derived from the open-to-match sums per currency.\n - `CurrencyId`: currency of the values.\n4. The result contains only customers with `SuggestedRefund > 0` and `SuggestedRefund` between `AmountFrom` and `AmountTo` (inclusive). If `ShopId` is given, only customers of that shop (`Customers.CustomerOf`) are returned; if `IsAccountMatched` is given, only customers with the matching `IsMatched` value.\n\nNo sort order is defined; there is no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShopId` | varchar(3) | No | Shop of the customers (`Customers.CustomerOf`). `NULL` or empty returns customers of all shops. |\n| `AmountFrom` | money | No | Minimum suggested refund (inclusive). `NULL` is treated as 0. |\n| `AmountTo` | money | No | Maximum suggested refund (inclusive). `NULL` is treated as 1000000. |\n| `IsAccountMatched` | bit | No | Filter on the match flag `IsMatched`. `NULL` returns both. |\n\n- Read-only; all tables are read with `NOLOCK`, so values can reflect uncommitted data.\n- Behaviour depends on the settings `DoNOTChargeShipCostOnSecondDelivery` (whether shipping costs are added to open orders when an order is already partly invoiced), `MultiCurrencyEnabled` and `HomeCurrency`.\n- If `MultiCurrencyEnabled = 1` and a customer has account entries or open orders in more than one currency, the amounts are converted to the shop's base currency using the exchange rate of the current day (`pixi.ExchRate`). If no rate exists for today, the amounts in that currency drop out of the sums. Without multi-currency, `CurrencyId` is the home currency.\n- The calculation runs over all customers with a positive account balance before the filters are applied, so the call can be expensive on large databases even with a restrictive `ShopId`.\n\nDocumentation: https://pixi-api-docs.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": "Returns customers whose customer account has a positive suggested refund, with balance, open orders and match status, optionally filtered by shop and amount.\n\nDetermines which customers should receive a refund from their customer account (`CustomerAccount`).\n\n1. Empty `ShopId` is treated as `NULL`. `NULL` values for `AmountFrom` / `AmountTo` fall back to `0` / `1000000`.\n2. All customers whose customer account entries sum up to a positive amount are selected as candidates.\n3. For these candidates the internal procedure `Pixi_CA_GetSummaryList` calculates per customer:\n - `FinancialBalance`: sum of all customer account amounts.\n - `OpenOrders`: value of order lines in an open state (`OrderStates.CA_IsOpenOrder = 1`) that are not yet invoiced, reduced by unused vouchers and increased by shipping costs. Only orders whose payment method has `CA_SubstractFromopenOrdersWhenRefund = 0` count; negative values per currency are set to 0.\n - `SuggestedRefund`: refundable account amount (entries without `DoNotRefund`, plus the matched part of entries with `DoNotRefund`) minus `OpenOrders`.\n - `OpenToMatch`: amount not yet matched.\n - `IsMatched`: match flag derived from the open-to-match sums per currency.\n - `CurrencyId`: currency of the values.\n4. The result contains only customers with `SuggestedRefund > 0` and `SuggestedRefund` between `AmountFrom` and `AmountTo` (inclusive). If `ShopId` is given, only customers of that shop (`Customers.CustomerOf`) are returned; if `IsAccountMatched` is given, only customers with the matching `IsMatched` value.\n\nNo sort order is defined; there is no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShopId` | varchar(3) | No | Shop of the customers (`Customers.CustomerOf`). `NULL` or empty returns customers of all shops. |\n| `AmountFrom` | money | No | Minimum suggested refund (inclusive). `NULL` is treated as 0. |\n| `AmountTo` | money | No | Maximum suggested refund (inclusive). `NULL` is treated as 1000000. |\n| `IsAccountMatched` | bit | No | Filter on the match flag `IsMatched`. `NULL` returns both. |\n\n- Read-only; all tables are read with `NOLOCK`, so values can reflect uncommitted data.\n- Behaviour depends on the settings `DoNOTChargeShipCostOnSecondDelivery` (whether shipping costs are added to open orders when an order is already partly invoiced), `MultiCurrencyEnabled` and `HomeCurrency`.\n- If `MultiCurrencyEnabled = 1` and a customer has account entries or open orders in more than one currency, the amounts are converted to the shop's base currency using the exchange rate of the current day (`pixi.ExchRate`). If no rate exists for today, the amounts in that currency drop out of the sums. Without multi-currency, `CurrencyId` is the home currency.\n- The calculation runs over all customers with a positive account balance before the filters are applied, so the call can be expensive on large databases even with a restrictive `ShopId`.\n\nDocumentation: https://pixi-api-docs.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": "Returns customer (and optionally supplier) address data for the DATEV export file, filtered by period, shop, country, e-mail, DATEV account and cost center.\n\nProvides the address master data (debtors and optionally creditors) for a DATEV export.\n\n1. The call first checks the setting `BookExportDatevActive`. If it is not `1`, only a single error row (`Status` = `ERROR`) is returned.\n2. Otherwise, all customers are selected that have at least one Rechnung with `InvDate` or at least one order line with `OrderDate` in the period `@DateFrom` (inclusive) to `@DateTo` (exclusive). The date values are used exactly as passed, including the time portion.\n3. For these customers, the main address of the customer is returned, together with shop and country data. Optional filters (each ignored when `NULL`):\n - `ShopId`: shop of the address\n - `CostCenter`: cost center of the shop (an empty string counts as `NULL`)\n - `Country`: Pixi country code of the address\n - `Email`: exact e-mail address\n - `DatevUserAccount`: DATEV account number of the customer\n4. If the setting `BookExportDatevKreditorenActive` is `1`, all Lieferanten with a non-empty customer number (`CustNr`) are appended as creditors. For suppliers only the filters `Country`, `Email` and `DatevUserAccount` apply; period, shop and cost center are not considered.\n5. Double quotes are removed from all values and semicolons are replaced by spaces, so the values can be written directly to a semicolon-separated file.\n\nThe result is sorted by `CustomerNr` (as text).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Yes | Start of the period (inclusive) for invoice and order dates used to select customers. |\n| `DateTo` | datetime | Yes | End of the period (exclusive) for invoice and order dates. |\n| `ShopId` | varchar(3) | No | Optional shop ID; only customers whose address belongs to this shop. Not applied to suppliers. |\n| `Country` | varchar(3) | No | Optional Pixi country code of the address (customer address or supplier country). |\n| `Email` | varchar(60) | No | Optional exact e-mail address of the customer address or supplier. |\n| `DatevUserAccount` | varchar(10) | No | Optional DATEV account number: customer DATEV account number or supplier customer number (first 10 characters). |\n| `CostCenter` | varchar(8) | No | Optional cost center of the shop; an empty string is treated as no filter. Not applied to suppliers. |\n\n- Read-only; all tables are read with `NOLOCK`, so uncommitted data may appear.\n- `@DateTo` is exclusive and no start/end-of-day adjustment is applied. To export a full day, pass the following day at 00:00 as `@DateTo`.\n- Settings that change the output (a missing setting counts as `0`):\n - `BookExportDatevActive`: must be `1`, otherwise only the error row is returned.\n - `BookExportDatevKreditorenActive`: appends suppliers as creditors.\n - `BookUseISOCntCode`: `ZipOld` is prefixed with the ISO3 country code instead of the Pixi country code (for suppliers the ISO3 code is prepended in addition to the Pixi code).\n - `RemoveNonASCII`: removes non-ASCII characters from `City`.\n- Customers whose address country is not found in the country table, or whose address shop does not exist, are not returned (inner joins).\n- The internal procedure can resolve a shop short name longer than 3 characters, but this call declares `ShopId` as `varchar(3)`, so only the 3-character shop ID can be used.\n- `Company` contains the full c/o field of the address, `Name2` the same field truncated to 40 characters. `ShortCode` is always empty, `Empty1` is always an empty string.\n- Supplier rows can appear without a country match; then `Country` defaults to `D`, `CountryISO3` to `DEU`, `CountryISO2` to `DE` and `CountryKFZ` to `D`, but such rows are excluded as soon as `Country` is filtered.\n\nDocumentation: https://pixi-api-docs.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": "Returns customer (and optionally supplier) address data for the DATEV export file, filtered by period, shop, country, e-mail, DATEV account and cost center.\n\nProvides the address master data (debtors and optionally creditors) for a DATEV export.\n\n1. The call first checks the setting `BookExportDatevActive`. If it is not `1`, only a single error row (`Status` = `ERROR`) is returned.\n2. Otherwise, all customers are selected that have at least one Rechnung with `InvDate` or at least one order line with `OrderDate` in the period `@DateFrom` (inclusive) to `@DateTo` (exclusive). The date values are used exactly as passed, including the time portion.\n3. For these customers, the main address of the customer is returned, together with shop and country data. Optional filters (each ignored when `NULL`):\n - `ShopId`: shop of the address\n - `CostCenter`: cost center of the shop (an empty string counts as `NULL`)\n - `Country`: Pixi country code of the address\n - `Email`: exact e-mail address\n - `DatevUserAccount`: DATEV account number of the customer\n4. If the setting `BookExportDatevKreditorenActive` is `1`, all Lieferanten with a non-empty customer number (`CustNr`) are appended as creditors. For suppliers only the filters `Country`, `Email` and `DatevUserAccount` apply; period, shop and cost center are not considered.\n5. Double quotes are removed from all values and semicolons are replaced by spaces, so the values can be written directly to a semicolon-separated file.\n\nThe result is sorted by `CustomerNr` (as text).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Yes | Start of the period (inclusive) for invoice and order dates used to select customers. |\n| `DateTo` | datetime | Yes | End of the period (exclusive) for invoice and order dates. |\n| `ShopId` | varchar(3) | No | Optional shop ID; only customers whose address belongs to this shop. Not applied to suppliers. |\n| `Country` | varchar(3) | No | Optional Pixi country code of the address (customer address or supplier country). |\n| `Email` | varchar(60) | No | Optional exact e-mail address of the customer address or supplier. |\n| `DatevUserAccount` | varchar(10) | No | Optional DATEV account number: customer DATEV account number or supplier customer number (first 10 characters). |\n| `CostCenter` | varchar(8) | No | Optional cost center of the shop; an empty string is treated as no filter. Not applied to suppliers. |\n\n- Read-only; all tables are read with `NOLOCK`, so uncommitted data may appear.\n- `@DateTo` is exclusive and no start/end-of-day adjustment is applied. To export a full day, pass the following day at 00:00 as `@DateTo`.\n- Settings that change the output (a missing setting counts as `0`):\n - `BookExportDatevActive`: must be `1`, otherwise only the error row is returned.\n - `BookExportDatevKreditorenActive`: appends suppliers as creditors.\n - `BookUseISOCntCode`: `ZipOld` is prefixed with the ISO3 country code instead of the Pixi country code (for suppliers the ISO3 code is prepended in addition to the Pixi code).\n - `RemoveNonASCII`: removes non-ASCII characters from `City`.\n- Customers whose address country is not found in the country table, or whose address shop does not exist, are not returned (inner joins).\n- The internal procedure can resolve a shop short name longer than 3 characters, but this call declares `ShopId` as `varchar(3)`, so only the 3-character shop ID can be used.\n- `Company` contains the full c/o field of the address, `Name2` the same field truncated to 40 characters. `ShortCode` is always empty, `Empty1` is always an empty string.\n- Supplier rows can appear without a country match; then `Country` defaults to `D`, `CountryISO3` to `DEU`, `CountryISO2` to `DE` and `CountryKFZ` to `D`, but such rows are excluded as soon as `Country` is filtered.\n\nDocumentation: https://pixi-api-docs.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": "Merges a duplicate customer into another customer by moving all related records to the target and deleting the source customer.\n\nMoves everything that belongs to customer `CustRefFrom` to customer `CustRefTo`, then deletes `CustRefFrom`.\n\n**Validation.** The checks run in this order. The first one that fails ends the call with `ReturnCode` = `ERROR`:\n1. `CustRefTo` and `CustRefFrom` must differ.\n2. The pair must be listed in `Addresses_Duplicates`. Either direction counts (`CustRef1`/`CustRef2`).\n3. Both customers must exist in `Customers`.\n4. Neither customer may have an order with an `OrderHeaderAttribute` of type `3` (archived orders).\n5. The base currencies (`Shops.BaseCurrencyId`) of both customers' shops (`Customers.CustomerOf`) must be the same.\n\n**Merge.** Inside a transaction, the customer reference is changed from `CustRefFrom` to `CustRefTo` in these tables:\n- orders and order lines: `OrderHeader`, `Orderlines`, `BundleOrderlines`, `OrderHistory`\n- invoices and reminders: `Invoices`, `Invlines`, `InvoicesDeleted`, `InvlinesDeleted`, `Reminders`\n- interface tables: `C_Int_OrderHeader`, `C_Int_Orderlines`, `C_Int_Addresses`\n- addresses and history: `Addresses`, `AddressesHist`, `CustomersHist`\n- customer account: `CustomerAccount`, `CustomerAccountLog`, `CustomerAccountManualBookings`, `CustomerAccountManualBookingsLog`\n- payments and direct debits: `CCPTranLog`, `DTAUS`, `DTAUSLog`\n- other: `Voucher`, `eMaillogs`, `AM_Mail`, `AM_MailHist`, `Boxes`, `pixi.Offer`, `lastsdetail`\n\nIn `Addresses` and `C_Int_Addresses`, `CustomerNrExternal` is also set to the external customer number of the target customer.\n\nAfter that, the duplicate entries of `CustRefFrom` are removed from `Addresses_Duplicates` and the source row is deleted from `Customers`.\n\n**Finish.** This step always runs, also after a failed validation or an error. Rows with `CustRefFrom` are deleted from `Addresses_Duplicates` and `tmp.Addresses_Simple`, and an event is logged. One status row with `ReturnCode` and `ErrorMessage` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustRefTo` | int | Yes | Customer key (`Customers.CustKey`) of the target customer that remains and receives all data. |\n| `CustRefFrom` | int | Yes | Customer key (`Customers.CustKey`) of the source customer whose data is moved and who is deleted afterwards. |\n\n- **Pitfall:** the final cleanup always runs. All `Addresses_Duplicates` and `tmp.Addresses_Simple` entries of `CustRefFrom` are deleted even when validation fails. If both parameters are equal, this removes the duplicate entries of that customer.\n- If an outer transaction is open, the call uses a savepoint and does not commit. Otherwise it opens and commits its own transaction. On error it rolls back, logs the error via `log.EventInsert` and `log.InsertError`, and returns `Unexpected error: \"…\"` with the error text cut to 80 characters.\n- The final cleanup and logging run after the merge transaction has been committed, or inside the caller's transaction if one is open.\n- `XACT_ABORT` is on.\n- `CONTEXT_INFO` is set to several values during the merge to bypass triggers on `OrderHeader`, `Addresses`, `CCPTranLog`, `Invoices`, `Invlines`, `Orderlines` and `CustomerAccount`. The triggers are not attached, so their skipped logic is unknown.\n- After the merge, the code tries to refresh the customer account sums with a dummy update on `CustomerAccount`. The update filters on `CustRefFrom`, whose rows have already been moved, so it probably affects no row.\n- If one of the two customers has no matching shop, the currency is `NULL` and the currency check does not stop the merge.\n- Validation reads use `NOLOCK`. The rows to be moved are collected with `UPDLOCK`.\n- The tables written by the logging procedures `log.EventInsert` and `log.InsertError` are not visible because their definitions are not attached.\n- The call is irreversible: the source customer is deleted.\n\nDocumentation: https://pixi-api-docs.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": "Merges a duplicate customer into another customer by moving all related records to the target and deleting the source customer.\n\nMoves everything that belongs to customer `CustRefFrom` to customer `CustRefTo`, then deletes `CustRefFrom`.\n\n**Validation.** The checks run in this order. The first one that fails ends the call with `ReturnCode` = `ERROR`:\n1. `CustRefTo` and `CustRefFrom` must differ.\n2. The pair must be listed in `Addresses_Duplicates`. Either direction counts (`CustRef1`/`CustRef2`).\n3. Both customers must exist in `Customers`.\n4. Neither customer may have an order with an `OrderHeaderAttribute` of type `3` (archived orders).\n5. The base currencies (`Shops.BaseCurrencyId`) of both customers' shops (`Customers.CustomerOf`) must be the same.\n\n**Merge.** Inside a transaction, the customer reference is changed from `CustRefFrom` to `CustRefTo` in these tables:\n- orders and order lines: `OrderHeader`, `Orderlines`, `BundleOrderlines`, `OrderHistory`\n- invoices and reminders: `Invoices`, `Invlines`, `InvoicesDeleted`, `InvlinesDeleted`, `Reminders`\n- interface tables: `C_Int_OrderHeader`, `C_Int_Orderlines`, `C_Int_Addresses`\n- addresses and history: `Addresses`, `AddressesHist`, `CustomersHist`\n- customer account: `CustomerAccount`, `CustomerAccountLog`, `CustomerAccountManualBookings`, `CustomerAccountManualBookingsLog`\n- payments and direct debits: `CCPTranLog`, `DTAUS`, `DTAUSLog`\n- other: `Voucher`, `eMaillogs`, `AM_Mail`, `AM_MailHist`, `Boxes`, `pixi.Offer`, `lastsdetail`\n\nIn `Addresses` and `C_Int_Addresses`, `CustomerNrExternal` is also set to the external customer number of the target customer.\n\nAfter that, the duplicate entries of `CustRefFrom` are removed from `Addresses_Duplicates` and the source row is deleted from `Customers`.\n\n**Finish.** This step always runs, also after a failed validation or an error. Rows with `CustRefFrom` are deleted from `Addresses_Duplicates` and `tmp.Addresses_Simple`, and an event is logged. One status row with `ReturnCode` and `ErrorMessage` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustRefTo` | int | Yes | Customer key (`Customers.CustKey`) of the target customer that remains and receives all data. |\n| `CustRefFrom` | int | Yes | Customer key (`Customers.CustKey`) of the source customer whose data is moved and who is deleted afterwards. |\n\n- **Pitfall:** the final cleanup always runs. All `Addresses_Duplicates` and `tmp.Addresses_Simple` entries of `CustRefFrom` are deleted even when validation fails. If both parameters are equal, this removes the duplicate entries of that customer.\n- If an outer transaction is open, the call uses a savepoint and does not commit. Otherwise it opens and commits its own transaction. On error it rolls back, logs the error via `log.EventInsert` and `log.InsertError`, and returns `Unexpected error: \"…\"` with the error text cut to 80 characters.\n- The final cleanup and logging run after the merge transaction has been committed, or inside the caller's transaction if one is open.\n- `XACT_ABORT` is on.\n- `CONTEXT_INFO` is set to several values during the merge to bypass triggers on `OrderHeader`, `Addresses`, `CCPTranLog`, `Invoices`, `Invlines`, `Orderlines` and `CustomerAccount`. The triggers are not attached, so their skipped logic is unknown.\n- After the merge, the code tries to refresh the customer account sums with a dummy update on `CustomerAccount`. The update filters on `CustRefFrom`, whose rows have already been moved, so it probably affects no row.\n- If one of the two customers has no matching shop, the currency is `NULL` and the currency check does not stop the merge.\n- Validation reads use `NOLOCK`. The rows to be moved are collected with `UPDLOCK`.\n- The tables written by the logging procedures `log.EventInsert` and `log.InsertError` are not visible because their definitions are not attached.\n- The call is irreversible: the source customer is deleted.\n\nDocumentation: https://pixi-api-docs.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": "Returns address records from the Addresses table, either a single address by key or a list filtered by creation and/or update date with key-based paging.\n\nReads addresses (customer and other address records) from the `Addresses` table. All branches return the same 66 columns.\n\n**Preparation**\n- If `RowCount` is set to a value other than 0, the number of returned rows is limited to that value (`SET ROWCOUNT`).\n- If `AddrKey` is omitted, it is treated as `0`.\n\n**Filter mode** – the first matching rule wins:\n1. `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` set: returns addresses with `AddrKey` > `AddrKey` where (`CreateDate` >= From **or** `UpdateDate` >= From) and (`CreateDate` < To **or** `UpdateDate` < To). Each bound is optional.\n2. `CreateDateFrom` or `CreateDateTo` set: returns addresses with `AddrKey` > `AddrKey` and `CreateDate` in the range `[From, To)`.\n3. `UpdateDateFrom` or `UpdateDateTo` set: returns addresses with `AddrKey` > `AddrKey` and `UpdateDate` in the range `[From, To)`.\n4. `RowCount` passed (any value, including `0`): returns all addresses with `AddrKey` > `AddrKey`.\n5. Otherwise: returns the single address whose `AddrKey` equals the passed value.\n\nIn modes 1–4 the result is sorted by `AddrKey` ascending, and `AddrKey` acts as an exclusive lower bound. This allows paging: pass the last `AddrKey` received as `AddrKey` of the next call together with `RowCount`.\n\nThe lower date bounds are inclusive and the upper date bounds are exclusive.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AddrKey` | int | No | Address key. Without date filter and `RowCount` it selects exactly this address. Otherwise it is the exclusive lower bound for paging. NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Inclusive lower bound for `CreateDate`. It is only used if no combined date filter is set. |\n| `CreateDateTo` | datetime | No | Exclusive upper bound for `CreateDate`. It is only used if no combined date filter is set. |\n| `UpdateDateFrom` | datetime | No | Inclusive lower bound for `UpdateDate`. It is only used if neither combined nor create date filters are set. |\n| `UpdateDateTo` | datetime | No | Exclusive upper bound for `UpdateDate`. It is only used if neither combined nor create date filters are set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Inclusive lower bound that matches if `CreateDate` or `UpdateDate` is on or after this value. It has the highest priority. |\n| `CreateAndUpdateDateTo` | datetime | No | Exclusive upper bound that matches if `CreateDate` or `UpdateDate` is before this value. It has the highest priority. |\n| `RowCount` | int | No | Maximum number of rows to return. 0 or NULL means no limit. If passed (even as 0) without date filters, all addresses with a key greater than `AddrKey` are returned. |\n\n- The table is read `WITH (NOLOCK)`. Uncommitted changes may be returned, and rows can be missed or duplicated while data is being changed.\n- The date filter groups are not combined: only the group with the highest priority is applied (combined date > create date > update date), and the others are ignored.\n- In combined mode the From and To conditions are evaluated independently. For example, an address created before the To bound and updated after the From bound is returned even if neither date lies inside the window. A row whose `UpdateDate` is NULL can only match through `CreateDate`.\n- If `AddrKey` is passed together with a date filter or `RowCount`, it is **not** an exact match but an exclusive lower bound.\n- `RowCount = 0` switches to mode 4 without a row limit and therefore returns **all** addresses above `AddrKey`.\n- Calling without any parameter returns the address with `AddrKey = 0`, which usually returns no row.\n- The result contains sensitive payment data such as card number, card verification code (`CCCVC`), IBAN and bank account data. Restrict access and logging accordingly.\n- The column types of `Addresses` are not visible in the code. The column meanings in this documentation are derived from the column names.\n\nDocumentation: https://pixi-api-docs.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": "Returns address records from the Addresses table, either a single address by key or a list filtered by creation and/or update date with key-based paging.\n\nReads addresses (customer and other address records) from the `Addresses` table. All branches return the same 66 columns.\n\n**Preparation**\n- If `RowCount` is set to a value other than 0, the number of returned rows is limited to that value (`SET ROWCOUNT`).\n- If `AddrKey` is omitted, it is treated as `0`.\n\n**Filter mode** – the first matching rule wins:\n1. `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` set: returns addresses with `AddrKey` > `AddrKey` where (`CreateDate` >= From **or** `UpdateDate` >= From) and (`CreateDate` < To **or** `UpdateDate` < To). Each bound is optional.\n2. `CreateDateFrom` or `CreateDateTo` set: returns addresses with `AddrKey` > `AddrKey` and `CreateDate` in the range `[From, To)`.\n3. `UpdateDateFrom` or `UpdateDateTo` set: returns addresses with `AddrKey` > `AddrKey` and `UpdateDate` in the range `[From, To)`.\n4. `RowCount` passed (any value, including `0`): returns all addresses with `AddrKey` > `AddrKey`.\n5. Otherwise: returns the single address whose `AddrKey` equals the passed value.\n\nIn modes 1–4 the result is sorted by `AddrKey` ascending, and `AddrKey` acts as an exclusive lower bound. This allows paging: pass the last `AddrKey` received as `AddrKey` of the next call together with `RowCount`.\n\nThe lower date bounds are inclusive and the upper date bounds are exclusive.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AddrKey` | int | No | Address key. Without date filter and `RowCount` it selects exactly this address. Otherwise it is the exclusive lower bound for paging. NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Inclusive lower bound for `CreateDate`. It is only used if no combined date filter is set. |\n| `CreateDateTo` | datetime | No | Exclusive upper bound for `CreateDate`. It is only used if no combined date filter is set. |\n| `UpdateDateFrom` | datetime | No | Inclusive lower bound for `UpdateDate`. It is only used if neither combined nor create date filters are set. |\n| `UpdateDateTo` | datetime | No | Exclusive upper bound for `UpdateDate`. It is only used if neither combined nor create date filters are set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Inclusive lower bound that matches if `CreateDate` or `UpdateDate` is on or after this value. It has the highest priority. |\n| `CreateAndUpdateDateTo` | datetime | No | Exclusive upper bound that matches if `CreateDate` or `UpdateDate` is before this value. It has the highest priority. |\n| `RowCount` | int | No | Maximum number of rows to return. 0 or NULL means no limit. If passed (even as 0) without date filters, all addresses with a key greater than `AddrKey` are returned. |\n\n- The table is read `WITH (NOLOCK)`. Uncommitted changes may be returned, and rows can be missed or duplicated while data is being changed.\n- The date filter groups are not combined: only the group with the highest priority is applied (combined date > create date > update date), and the others are ignored.\n- In combined mode the From and To conditions are evaluated independently. For example, an address created before the To bound and updated after the From bound is returned even if neither date lies inside the window. A row whose `UpdateDate` is NULL can only match through `CreateDate`.\n- If `AddrKey` is passed together with a date filter or `RowCount`, it is **not** an exact match but an exclusive lower bound.\n- `RowCount = 0` switches to mode 4 without a row limit and therefore returns **all** addresses above `AddrKey`.\n- Calling without any parameter returns the address with `AddrKey = 0`, which usually returns no row.\n- The result contains sensitive payment data such as card number, card verification code (`CCCVC`), IBAN and bank account data. Restrict access and logging accordingly.\n- The column types of `Addresses` are not visible in the code. The column meanings in this documentation are derived from the column names.\n\nDocumentation: https://pixi-api-docs.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": "Returns customer account match records (pairs of matched customer account entries), filtered by date, customer or account entry, with keyset paging.\n\nReads rows from the `CustomerAccountMatch` table. Each row links two customer account entries (`CAref1`, `CAref2`) with the matched amount `AbsoluteMatchAmount`.\n\n**Paging:** `CustomerAccountMatchKey` works as a cursor. Only records with a key **greater than** the given value are returned (NULL is treated as `0`). At most `RowCount` rows are returned (NULL is treated as `1000`), sorted by `CustomerAccountMatchKey` ascending. For the next page, pass the highest key of the previous page.\n\n**Date filters:** only one date filter group is applied. The groups are checked in this order:\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: a record matches the lower bound if `CreateDate` **or** `UpdateDate` is >= the from value, and the upper bound if `CreateDate` **or** `UpdateDate` is < the to value.\n2. `CreateDateFrom` / `CreateDateTo`: filters on `CreateDate` (from inclusive, to exclusive).\n3. `UpdateDateFrom` / `UpdateDateTo`: filters on `UpdateDate` (from inclusive, to exclusive).\n\nIf a higher-ranking group has at least one value set, the date parameters of the lower groups are ignored. Without any date parameter, only the key and the other filters are applied.\n\n**Additional filters (always applied):**\n- `CustRef`: the customer of the first or the second linked customer account entry must match.\n- `CustomerAccountKey`: `CAref1` or `CAref2` must equal the given value.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustomerAccountMatchKey` | int | No | Paging cursor: only records with a key greater than this value are returned. NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for `CreateDate`. Ignored if a combined create/update date parameter is set. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for `CreateDate`. Ignored if a combined create/update date parameter is set. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for `UpdateDate`. Only used if no combined and no create date parameter is set. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for `UpdateDate`. Only used if no combined and no create date parameter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive): a record matches if `CreateDate` or `UpdateDate` is on or after this value. Takes precedence over all other date parameters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (exclusive): a record matches if `CreateDate` or `UpdateDate` is before this value. Takes precedence over all other date parameters. |\n| `RowCount` | int | No | Maximum number of rows returned. NULL is treated as 1000. |\n| `CustRef` | int | No | Customer reference: returns only matches where one of the two linked customer account entries belongs to this customer. |\n| `CustomerAccountKey` | int | No | Customer account entry key: returns only matches where `CAref1` or `CAref2` equals this value. |\n\n- `CustomerAccountMatchKey` is **not** an exact lookup: because NULL values of `CustomerAccountMatchKey` and `RowCount` are replaced by defaults at the start, the code always uses the range branch (`key > value`). The branch for an exact key match and the empty-result branch in the code are never reached. To read a single record with key `n`, pass `n - 1` and `RowCount = 1`.\n- The combined create/update date filter combines its conditions with OR, so the from and to bounds may be satisfied by different date columns; the result can therefore be broader than an exact time window.\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- `RowCount = 0` returns no rows.\n\nDocumentation: https://pixi-api-docs.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": "Returns customer account match records (pairs of matched customer account entries), filtered by date, customer or account entry, with keyset paging.\n\nReads rows from the `CustomerAccountMatch` table. Each row links two customer account entries (`CAref1`, `CAref2`) with the matched amount `AbsoluteMatchAmount`.\n\n**Paging:** `CustomerAccountMatchKey` works as a cursor. Only records with a key **greater than** the given value are returned (NULL is treated as `0`). At most `RowCount` rows are returned (NULL is treated as `1000`), sorted by `CustomerAccountMatchKey` ascending. For the next page, pass the highest key of the previous page.\n\n**Date filters:** only one date filter group is applied. The groups are checked in this order:\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: a record matches the lower bound if `CreateDate` **or** `UpdateDate` is >= the from value, and the upper bound if `CreateDate` **or** `UpdateDate` is < the to value.\n2. `CreateDateFrom` / `CreateDateTo`: filters on `CreateDate` (from inclusive, to exclusive).\n3. `UpdateDateFrom` / `UpdateDateTo`: filters on `UpdateDate` (from inclusive, to exclusive).\n\nIf a higher-ranking group has at least one value set, the date parameters of the lower groups are ignored. Without any date parameter, only the key and the other filters are applied.\n\n**Additional filters (always applied):**\n- `CustRef`: the customer of the first or the second linked customer account entry must match.\n- `CustomerAccountKey`: `CAref1` or `CAref2` must equal the given value.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustomerAccountMatchKey` | int | No | Paging cursor: only records with a key greater than this value are returned. NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for `CreateDate`. Ignored if a combined create/update date parameter is set. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for `CreateDate`. Ignored if a combined create/update date parameter is set. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for `UpdateDate`. Only used if no combined and no create date parameter is set. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for `UpdateDate`. Only used if no combined and no create date parameter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive): a record matches if `CreateDate` or `UpdateDate` is on or after this value. Takes precedence over all other date parameters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (exclusive): a record matches if `CreateDate` or `UpdateDate` is before this value. Takes precedence over all other date parameters. |\n| `RowCount` | int | No | Maximum number of rows returned. NULL is treated as 1000. |\n| `CustRef` | int | No | Customer reference: returns only matches where one of the two linked customer account entries belongs to this customer. |\n| `CustomerAccountKey` | int | No | Customer account entry key: returns only matches where `CAref1` or `CAref2` equals this value. |\n\n- `CustomerAccountMatchKey` is **not** an exact lookup: because NULL values of `CustomerAccountMatchKey` and `RowCount` are replaced by defaults at the start, the code always uses the range branch (`key > value`). The branch for an exact key match and the empty-result branch in the code are never reached. To read a single record with key `n`, pass `n - 1` and `RowCount = 1`.\n- The combined create/update date filter combines its conditions with OR, so the from and to bounds may be satisfied by different date columns; the result can therefore be broader than an exact time window.\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- `RowCount = 0` returns no rows.\n\nDocumentation: https://pixi-api-docs.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": "Returns customer master records from the `Customers` table, either one customer by key or a page filtered by create/update date ranges.\n\nReads customer master data from `Customers`. Every branch returns the same column list. The parameters select exactly one branch, checked in this order:\n\n1. **Create *or* update date**: if `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` is set, customers with `CustKey > @CustKey` are returned whose `CreateDate` **or** `UpdateDate` is `>= From` and whose `CreateDate` **or** `UpdateDate` is `< To`. Each bound is ignored if it is NULL.\n2. **Create date**: otherwise, if `CreateDateFrom` or `CreateDateTo` is set, customers with `CustKey > @CustKey` and `CreateDate >= From` and `CreateDate < To` are returned.\n3. **Update date**: otherwise, if `UpdateDateFrom` or `UpdateDateTo` is set, customers with `CustKey > @CustKey` and `UpdateDate >= From` and `UpdateDate < To` are returned.\n4. **Key range**: otherwise, if `RowCount` is passed (any value, including `0`), all customers with `CustKey > @CustKey` are returned.\n5. **Single customer**: otherwise the customer with `CustKey = @CustKey` is returned.\n\nIf `CustKey` is not passed, it is set to `0`. In the date and key range branches this means \"start at the beginning\". In the single customer branch it means a lookup of key `0`, which normally returns no row.\n\nThe lower date bounds are inclusive and the upper bounds are exclusive. Branches 1–4 are sorted by `CustKey` ascending. If `RowCount` is not 0, the number of rows is limited with `SET ROWCOUNT`.\n\n**Paging:** pass the last `CustKey` of the previous page as `CustKey` together with `RowCount`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | No | Customer key. Exact match in the single customer branch. Exclusive lower bound (`CustKey > value`) in the date and key range branches. NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Inclusive lower bound for `CreateDate`. Used only if no `CreateAndUpdateDate*` parameter is set. |\n| `CreateDateTo` | datetime | No | Exclusive upper bound for `CreateDate`. Used only if no `CreateAndUpdateDate*` parameter is set. |\n| `UpdateDateFrom` | datetime | No | Inclusive lower bound for `UpdateDate`. Used only if neither `CreateAndUpdateDate*` nor `CreateDate*` parameters are set. |\n| `UpdateDateTo` | datetime | No | Exclusive upper bound for `UpdateDate`. Used only if neither `CreateAndUpdateDate*` nor `CreateDate*` parameters are set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Inclusive lower bound that matches if `CreateDate` or `UpdateDate` is on or after this value. Takes precedence over all other date parameters. |\n| `CreateAndUpdateDateTo` | datetime | No | Exclusive upper bound that matches if `CreateDate` or `UpdateDate` is before this value. Takes precedence over all other date parameters. |\n| `RowCount` | int | No | Maximum number of rows (via `SET ROWCOUNT`). 0 or NULL means no limit. Any non-NULL value without date filters selects the key range branch (`CustKey > @CustKey`). |\n\n- In the date branches `CustKey` is an **exclusive lower bound**, not an exact match. Passing a customer key together with a date filter returns the customers *after* that key.\n- Only one date filter group is used. `CreateAndUpdateDate*` takes precedence over `CreateDate*`, which takes precedence over `UpdateDate*`. If more groups are passed, the others are ignored.\n- In the combined filter the upper bound is also an OR condition. A customer created before `CreateAndUpdateDateTo` matches even if it was last updated after that date, and the other way round.\n- `RowCount = 0` selects the key range branch but does not limit the rows, so all customers after `CustKey` are returned.\n- The table is read `WITH (NOLOCK)`, so uncommitted data can be returned.\n- The result contains sensitive data such as `Password`, credit card fields (`CardNr`, `CardExp`) and bank details (`Account`, `BLZ`). Handle it accordingly.\n- The final \"no data\" branch (`WHERE 1 = 0`) cannot be reached, because `CustKey` is never NULL after the default replacement.\n- Column data types are not visible in the procedure. They come from the `Customers` table.\n\nDocumentation: https://pixi-api-docs.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": "Returns customer master records from the `Customers` table, either one customer by key or a page filtered by create/update date ranges.\n\nReads customer master data from `Customers`. Every branch returns the same column list. The parameters select exactly one branch, checked in this order:\n\n1. **Create *or* update date**: if `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` is set, customers with `CustKey > @CustKey` are returned whose `CreateDate` **or** `UpdateDate` is `>= From` and whose `CreateDate` **or** `UpdateDate` is `< To`. Each bound is ignored if it is NULL.\n2. **Create date**: otherwise, if `CreateDateFrom` or `CreateDateTo` is set, customers with `CustKey > @CustKey` and `CreateDate >= From` and `CreateDate < To` are returned.\n3. **Update date**: otherwise, if `UpdateDateFrom` or `UpdateDateTo` is set, customers with `CustKey > @CustKey` and `UpdateDate >= From` and `UpdateDate < To` are returned.\n4. **Key range**: otherwise, if `RowCount` is passed (any value, including `0`), all customers with `CustKey > @CustKey` are returned.\n5. **Single customer**: otherwise the customer with `CustKey = @CustKey` is returned.\n\nIf `CustKey` is not passed, it is set to `0`. In the date and key range branches this means \"start at the beginning\". In the single customer branch it means a lookup of key `0`, which normally returns no row.\n\nThe lower date bounds are inclusive and the upper bounds are exclusive. Branches 1–4 are sorted by `CustKey` ascending. If `RowCount` is not 0, the number of rows is limited with `SET ROWCOUNT`.\n\n**Paging:** pass the last `CustKey` of the previous page as `CustKey` together with `RowCount`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | No | Customer key. Exact match in the single customer branch. Exclusive lower bound (`CustKey > value`) in the date and key range branches. NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Inclusive lower bound for `CreateDate`. Used only if no `CreateAndUpdateDate*` parameter is set. |\n| `CreateDateTo` | datetime | No | Exclusive upper bound for `CreateDate`. Used only if no `CreateAndUpdateDate*` parameter is set. |\n| `UpdateDateFrom` | datetime | No | Inclusive lower bound for `UpdateDate`. Used only if neither `CreateAndUpdateDate*` nor `CreateDate*` parameters are set. |\n| `UpdateDateTo` | datetime | No | Exclusive upper bound for `UpdateDate`. Used only if neither `CreateAndUpdateDate*` nor `CreateDate*` parameters are set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Inclusive lower bound that matches if `CreateDate` or `UpdateDate` is on or after this value. Takes precedence over all other date parameters. |\n| `CreateAndUpdateDateTo` | datetime | No | Exclusive upper bound that matches if `CreateDate` or `UpdateDate` is before this value. Takes precedence over all other date parameters. |\n| `RowCount` | int | No | Maximum number of rows (via `SET ROWCOUNT`). 0 or NULL means no limit. Any non-NULL value without date filters selects the key range branch (`CustKey > @CustKey`). |\n\n- In the date branches `CustKey` is an **exclusive lower bound**, not an exact match. Passing a customer key together with a date filter returns the customers *after* that key.\n- Only one date filter group is used. `CreateAndUpdateDate*` takes precedence over `CreateDate*`, which takes precedence over `UpdateDate*`. If more groups are passed, the others are ignored.\n- In the combined filter the upper bound is also an OR condition. A customer created before `CreateAndUpdateDateTo` matches even if it was last updated after that date, and the other way round.\n- `RowCount = 0` selects the key range branch but does not limit the rows, so all customers after `CustKey` are returned.\n- The table is read `WITH (NOLOCK)`, so uncommitted data can be returned.\n- The result contains sensitive data such as `Password`, credit card fields (`CardNr`, `CardExp`) and bank details (`Account`, `BLZ`). Handle it accordingly.\n- The final \"no data\" branch (`WHERE 1 = 0`) cannot be reached, because `CustKey` is never NULL after the default replacement.\n- Column data types are not visible in the procedure. They come from the `Customers` table.\n\nDocumentation: https://pixi-api-docs.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": "Returns the billing and shipping addresses and shop notes of orders created in a date range, as a preview for repairing strange characters.\n\nAccording to its header comment, the procedure is meant to *repair strange characters for API output* in customer data. The current code does not change any data. It only selects the affected records.\n\nSteps:\n\n1. If `FromDate` is not passed, it is set to the start of the current day (00:00:00). If `ToDate` is not passed, it is set to the end of the current day (23:59:59.997).\n2. It collects all orders from `OrderHeader` whose `CreateDate` lies between `FromDate` and `ToDate` (both inclusive) and that have both a billing address (`AddrRef <> 0`) and a shipping address (`ShipAdrRef <> 0`).\n3. It collects the billing and shipping address keys of these orders.\n4. It opens a transaction:\n - With `CommitResult = 1` the empty transaction is committed. No result set is returned.\n - Otherwise (0 or NULL) two result sets are returned and the transaction is rolled back:\n - the name, address and phone fields of all collected addresses from `Addresses`. Each address appears only once.\n - `OrderNr` and `Shop_Note` of all collected orders.\n\nThe sort order of both result sets is not defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | No | Start of the order creation date range (inclusive). If NULL, the start of the current day is used. |\n| `ToDate` | datetime | No | End of the order creation date range (inclusive). If NULL, the end of the current day (23:59:59.997) is used. |\n| `CommitResult` | bit | No | Controls whether the transaction is committed or the affected data is returned as a preview. |\n\n- Despite its name, the procedure performs no updates. The transaction contains no data changes, so `CommitResult = 1` has no effect except suppressing the output. The actual repair logic appears to have been removed.\n- All reads use `NOLOCK`. Uncommitted data may therefore be returned.\n- Orders without a billing or shipping address (reference 0) are ignored entirely.\n- Large date ranges can produce large result sets.\n\nDocumentation: https://pixi-api-docs.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": "Returns the billing and shipping addresses and shop notes of orders created in a date range, as a preview for repairing strange characters.\n\nAccording to its header comment, the procedure is meant to *repair strange characters for API output* in customer data. The current code does not change any data. It only selects the affected records.\n\nSteps:\n\n1. If `FromDate` is not passed, it is set to the start of the current day (00:00:00). If `ToDate` is not passed, it is set to the end of the current day (23:59:59.997).\n2. It collects all orders from `OrderHeader` whose `CreateDate` lies between `FromDate` and `ToDate` (both inclusive) and that have both a billing address (`AddrRef <> 0`) and a shipping address (`ShipAdrRef <> 0`).\n3. It collects the billing and shipping address keys of these orders.\n4. It opens a transaction:\n - With `CommitResult = 1` the empty transaction is committed. No result set is returned.\n - Otherwise (0 or NULL) two result sets are returned and the transaction is rolled back:\n - the name, address and phone fields of all collected addresses from `Addresses`. Each address appears only once.\n - `OrderNr` and `Shop_Note` of all collected orders.\n\nThe sort order of both result sets is not defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | No | Start of the order creation date range (inclusive). If NULL, the start of the current day is used. |\n| `ToDate` | datetime | No | End of the order creation date range (inclusive). If NULL, the end of the current day (23:59:59.997) is used. |\n| `CommitResult` | bit | No | Controls whether the transaction is committed or the affected data is returned as a preview. |\n\n- Despite its name, the procedure performs no updates. The transaction contains no data changes, so `CommitResult = 1` has no effect except suppressing the output. The actual repair logic appears to have been removed.\n- All reads use `NOLOCK`. Uncommitted data may therefore be returned.\n- Orders without a billing or shipping address (reference 0) are ignored entirely.\n- Large date ranges can produce large result sets.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoiced customers (or one customer's invoice lines) within a delivery and order date window, e.g. for satisfaction surveys or review requests.\n\nSelects invoice lines joined with their order lines and the invoice address. Results can be used to contact customers who recently received goods.\n\n**Date window**: the day parameters are relative to the current server date (`GETDATE()`):\n- `MaxDaysSinceDelivery`: invoice date (`InvDate`) must be on or after the start of the day *N* days ago.\n- `MinDaysSinceDelivery`: invoice date must be on or before the end of the day *N* days ago.\n- `MaxDaysSinceOrder` / `MinDaysSinceOrder`: the same for the order date of the order line.\n- A `NULL` value disables the respective bound.\n\n**Further filters**:\n- Invoices referenced by another invoice (`RefToInvoiceKey`, e.g. a credit note) with an invoice date on or after the `MaxDaysSinceDelivery` date are excluded.\n- Lines whose order line has status `MIN` and an order date on or after the `MaxDaysSinceDelivery` date are excluded.\n- `ExcludePartialDeliveries = 1`: orders (by `OrderNr`) that still have order lines in status `ANG` or `EIN` are excluded.\n- `NoOrderSince = 1`: customers who have any order line with an order date on or after the `MinDaysSinceDelivery` date are excluded.\n- Only lines with `ItemQty >= 0`.\n\n**Two modes**:\n- `CustomerNrExternal` is `NULL`: one row per external customer number (`GROUP BY Addresses.CustomerNrExternal`), sorted by customer number. `ItemQty` is the **number** of matching invoice lines.\n- `CustomerNrExternal` is set: only lines of that customer, one row per invoice line (`GROUP BY Invlinekey`), no explicit sort order. `ItemQty` is the quantity of the line.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `MaxDaysSinceDelivery` | int | No | Oldest invoice date as days before today; invoice date must be on or after the start of that day. NULL = no lower bound. |\n| `MinDaysSinceDelivery` | int | No | Newest invoice date as days before today; invoice date must be on or before the end of that day. Also used by NoOrderSince. NULL = no upper bound. |\n| `MaxDaysSinceOrder` | int | No | Oldest order date as days before today (start of day). NULL = no lower bound. |\n| `MinDaysSinceOrder` | int | No | Newest order date as days before today (end of day). NULL = no upper bound. |\n| `CustomerNrExternal` | varchar(60) | No | External customer number of the invoice address. If set, returns one row per invoice line of this customer; if NULL, one row per customer. |\n| `ExcludePartialDeliveries` | bit | No | Excludes orders that still have order lines in status ANG or EIN. |\n| `NoOrderSince` | bit | No | Excludes customers who placed any order on or after the MinDaysSinceDelivery date. |\n\n- All tables are read `WITH (NOLOCK)`; results may contain uncommitted data.\n- In customer mode every column is aggregated independently with `MAX`/`MIN`, so `InvoiceNr`, `ItemText`, `ItemPrice`, `ItemNrShop` etc. can come from different invoices or lines of the same customer.\n- Addresses without an external customer number are grouped together into one `NULL` row in customer mode.\n- The credit-note filter and the `MIN` status filter only work when `MaxDaysSinceDelivery` is set; with `NULL` the comparison never matches and nothing is excluded.\n- `NoOrderSince = 1` only has an effect when `MinDaysSinceDelivery` is set, because it compares against that date.\n- The table owning `ItemQty`, `ItemText`, `ItemPrice`, `orderdate` and `Status` is not qualified in the code; presumably invoice lines resp. order lines.\n- The meaning of the order line statuses `MIN`, `ANG` and `EIN` is not defined in the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoiced customers (or one customer's invoice lines) within a delivery and order date window, e.g. for satisfaction surveys or review requests.\n\nSelects invoice lines joined with their order lines and the invoice address. Results can be used to contact customers who recently received goods.\n\n**Date window**: the day parameters are relative to the current server date (`GETDATE()`):\n- `MaxDaysSinceDelivery`: invoice date (`InvDate`) must be on or after the start of the day *N* days ago.\n- `MinDaysSinceDelivery`: invoice date must be on or before the end of the day *N* days ago.\n- `MaxDaysSinceOrder` / `MinDaysSinceOrder`: the same for the order date of the order line.\n- A `NULL` value disables the respective bound.\n\n**Further filters**:\n- Invoices referenced by another invoice (`RefToInvoiceKey`, e.g. a credit note) with an invoice date on or after the `MaxDaysSinceDelivery` date are excluded.\n- Lines whose order line has status `MIN` and an order date on or after the `MaxDaysSinceDelivery` date are excluded.\n- `ExcludePartialDeliveries = 1`: orders (by `OrderNr`) that still have order lines in status `ANG` or `EIN` are excluded.\n- `NoOrderSince = 1`: customers who have any order line with an order date on or after the `MinDaysSinceDelivery` date are excluded.\n- Only lines with `ItemQty >= 0`.\n\n**Two modes**:\n- `CustomerNrExternal` is `NULL`: one row per external customer number (`GROUP BY Addresses.CustomerNrExternal`), sorted by customer number. `ItemQty` is the **number** of matching invoice lines.\n- `CustomerNrExternal` is set: only lines of that customer, one row per invoice line (`GROUP BY Invlinekey`), no explicit sort order. `ItemQty` is the quantity of the line.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `MaxDaysSinceDelivery` | int | No | Oldest invoice date as days before today; invoice date must be on or after the start of that day. NULL = no lower bound. |\n| `MinDaysSinceDelivery` | int | No | Newest invoice date as days before today; invoice date must be on or before the end of that day. Also used by NoOrderSince. NULL = no upper bound. |\n| `MaxDaysSinceOrder` | int | No | Oldest order date as days before today (start of day). NULL = no lower bound. |\n| `MinDaysSinceOrder` | int | No | Newest order date as days before today (end of day). NULL = no upper bound. |\n| `CustomerNrExternal` | varchar(60) | No | External customer number of the invoice address. If set, returns one row per invoice line of this customer; if NULL, one row per customer. |\n| `ExcludePartialDeliveries` | bit | No | Excludes orders that still have order lines in status ANG or EIN. |\n| `NoOrderSince` | bit | No | Excludes customers who placed any order on or after the MinDaysSinceDelivery date. |\n\n- All tables are read `WITH (NOLOCK)`; results may contain uncommitted data.\n- In customer mode every column is aggregated independently with `MAX`/`MIN`, so `InvoiceNr`, `ItemText`, `ItemPrice`, `ItemNrShop` etc. can come from different invoices or lines of the same customer.\n- Addresses without an external customer number are grouped together into one `NULL` row in customer mode.\n- The credit-note filter and the `MIN` status filter only work when `MaxDaysSinceDelivery` is set; with `NULL` the comparison never matches and nothing is excluded.\n- `NoOrderSince = 1` only has an effect when `MinDaysSinceDelivery` is set, because it compares against that date.\n- The table owning `ItemQty`, `ItemText`, `ItemPrice`, `orderdate` and `Status` is not qualified in the code; presumably invoice lines resp. order lines.\n- The meaning of the order line statuses `MIN`, `ANG` and `EIN` is not defined in the code.\n\nDocumentation: https://pixi-api-docs.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": "Sets the discount percentage (`Rabat`) of one customer identified by e-mail address and/or external customer number.\n\nUpdates the field `Rabat` of exactly one customer in `Customers` and returns a status row.\n\n**Validation**\n- `Discount` is mandatory and must be between 0 and 100, inclusive.\n- Empty strings in `CustMail` and `CustNr` are treated as `NULL`. At least one of them must be supplied.\n\n**Customer lookup**\n\nThe procedure counts customers matching `CeMail = CustMail`, customers matching `CustomerNrExternal = CustNr`, and customers matching both. If `CustNr` is not supplied, the last check only requires a matching e-mail and a non-NULL customer number. The customer is then chosen as follows:\n1. If exactly one customer has the e-mail address, that customer is used. `CustNr` is ignored in this case.\n2. If no customer has the e-mail address and exactly one customer has the customer number, that customer is used.\n3. If several customers share the e-mail address and exactly one of them matches the customer number, that one is used.\n4. Otherwise an error row is returned. The message is either *More then one customer found…* or *No customer found…*.\n\n**Update and result**\n\nThe procedure sets `Rabat` to `Discount` for the chosen customer. It then returns one row with `Status` = `Success` and a message containing the new discount, the customer's e-mail address and the external customer number. Every error, including validation errors, is returned as a single row with `Status` = `Error` and the error text in `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustMail` | varchar(256) | No | E-mail address of the customer (`CeMail`). An empty string is treated as NULL. Either this parameter or `CustNr` must be supplied. |\n| `CustNr` | varchar(60) | No | External customer number (`CustomerNrExternal`). An empty string is treated as NULL. Used when no customer has the e-mail address, or to choose between several customers with the same e-mail address. |\n| `Discount` | numeric(6, 2) | No | Discount in percent to store in `Rabat`. Mandatory in practice: it must be supplied and must be between 0 and 100. |\n\n- Errors never arrive as `SqlMessage`. They are caught and returned as a row with `Status` = `Error`, so always check the `Status` column.\n- Pitfall: if the e-mail address matches exactly one customer, that customer is updated even when the supplied `CustNr` belongs to a different customer or matches no customer.\n- The success message is built by string concatenation. If the customer's `CeMail` or `CustomerNrExternal` is `NULL`, `Message` is likely to be `NULL` (the usual SQL Server behaviour with `CONCAT_NULL_YIELDS_NULL`), although the update has been done.\n- Lookups use `NOLOCK` and the update uses `ROWLOCK`. No explicit transaction is used.\n- E-mail and customer number are compared with `=`. Whether the comparison is case-sensitive depends on the database collation.\n\nDocumentation: https://pixi-api-docs.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": "Sets the discount percentage (`Rabat`) of one customer identified by e-mail address and/or external customer number.\n\nUpdates the field `Rabat` of exactly one customer in `Customers` and returns a status row.\n\n**Validation**\n- `Discount` is mandatory and must be between 0 and 100, inclusive.\n- Empty strings in `CustMail` and `CustNr` are treated as `NULL`. At least one of them must be supplied.\n\n**Customer lookup**\n\nThe procedure counts customers matching `CeMail = CustMail`, customers matching `CustomerNrExternal = CustNr`, and customers matching both. If `CustNr` is not supplied, the last check only requires a matching e-mail and a non-NULL customer number. The customer is then chosen as follows:\n1. If exactly one customer has the e-mail address, that customer is used. `CustNr` is ignored in this case.\n2. If no customer has the e-mail address and exactly one customer has the customer number, that customer is used.\n3. If several customers share the e-mail address and exactly one of them matches the customer number, that one is used.\n4. Otherwise an error row is returned. The message is either *More then one customer found…* or *No customer found…*.\n\n**Update and result**\n\nThe procedure sets `Rabat` to `Discount` for the chosen customer. It then returns one row with `Status` = `Success` and a message containing the new discount, the customer's e-mail address and the external customer number. Every error, including validation errors, is returned as a single row with `Status` = `Error` and the error text in `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustMail` | varchar(256) | No | E-mail address of the customer (`CeMail`). An empty string is treated as NULL. Either this parameter or `CustNr` must be supplied. |\n| `CustNr` | varchar(60) | No | External customer number (`CustomerNrExternal`). An empty string is treated as NULL. Used when no customer has the e-mail address, or to choose between several customers with the same e-mail address. |\n| `Discount` | numeric(6, 2) | No | Discount in percent to store in `Rabat`. Mandatory in practice: it must be supplied and must be between 0 and 100. |\n\n- Errors never arrive as `SqlMessage`. They are caught and returned as a row with `Status` = `Error`, so always check the `Status` column.\n- Pitfall: if the e-mail address matches exactly one customer, that customer is updated even when the supplied `CustNr` belongs to a different customer or matches no customer.\n- The success message is built by string concatenation. If the customer's `CeMail` or `CustomerNrExternal` is `NULL`, `Message` is likely to be `NULL` (the usual SQL Server behaviour with `CONCAT_NULL_YIELDS_NULL`), although the update has been done.\n- Lookups use `NOLOCK` and the update uses `ROWLOCK`. No explicit transaction is used.\n- E-mail and customer number are compared with `=`. Whether the comparison is case-sensitive depends on the database collation.\n\nDocumentation: https://pixi-api-docs.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": "Sets or removes the shipping lock (`SLocked`) of a customer, identified by `CustKey` or by external customer number and shop.\n\nSets the shipping lock flag of one customer record in `Customers`.\n\n1. `UserName` is trimmed. If it is empty or missing, `API` is used. The value is written to `Customers.UpdateEmp`.\n2. `Locked` is converted to the stored value: `1` becomes `Y`. Any other value, including `0` and `NULL`, becomes `N`.\n3. If `CustomerNrExternal` is not empty, the procedure looks up the `CustKey` of the customer whose `CustomerNrExternal` matches and whose `CustomerOf` equals `ShopID`. If several customers match, only one of them (`TOP 1`, no defined order) is used.\n4. The customer with the resulting `CustKey` gets `SLocked` and `UpdateEmp` updated.\n5. A single row with the column `Result` is returned: `0` if exactly one customer was updated, `1` otherwise.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | No | Internal key of the customer. Used if `CustomerNrExternal` is empty or no matching customer is found by it. |\n| `Locked` | bit | No | `1` sets the shipping lock (`SLocked` = `Y`). Any other value removes it (`SLocked` = `N`). |\n| `CustomerNrExternal` | varchar(250) | No | External customer number, for example from the shop. If set, the customer is looked up by this number together with `ShopID`. |\n| `ShopID` | varchar(3) | No | Shop code compared with `Customers.CustomerOf`. Required for the lookup by `CustomerNrExternal`. |\n| `UserName` | varchar(50) | No | User name written to `UpdateEmp`. If empty or missing, `API` is used. |\n\n- If `CustomerNrExternal` is given but no customer matches, the variable keeps the passed `CustKey`. In that case the customer with that `CustKey` is updated, or nothing is updated if `CustKey` is `NULL`.\n- `ShopID` is compared with `=`. If `ShopID` is `NULL` while `CustomerNrExternal` is set, the lookup never finds a match.\n- If neither `CustKey` nor a matching external number is given, no row is updated and `Result` = `1` is returned.\n- The lookup uses `UPDLOCK`. There is no explicit transaction, so the lock is held only for the duration of that statement.\n- No error messages are produced. Only the `Result` value indicates success or failure.\n\nDocumentation: https://pixi-api-docs.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": "Sets or removes the shipping lock (`SLocked`) of a customer, identified by `CustKey` or by external customer number and shop.\n\nSets the shipping lock flag of one customer record in `Customers`.\n\n1. `UserName` is trimmed. If it is empty or missing, `API` is used. The value is written to `Customers.UpdateEmp`.\n2. `Locked` is converted to the stored value: `1` becomes `Y`. Any other value, including `0` and `NULL`, becomes `N`.\n3. If `CustomerNrExternal` is not empty, the procedure looks up the `CustKey` of the customer whose `CustomerNrExternal` matches and whose `CustomerOf` equals `ShopID`. If several customers match, only one of them (`TOP 1`, no defined order) is used.\n4. The customer with the resulting `CustKey` gets `SLocked` and `UpdateEmp` updated.\n5. A single row with the column `Result` is returned: `0` if exactly one customer was updated, `1` otherwise.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | No | Internal key of the customer. Used if `CustomerNrExternal` is empty or no matching customer is found by it. |\n| `Locked` | bit | No | `1` sets the shipping lock (`SLocked` = `Y`). Any other value removes it (`SLocked` = `N`). |\n| `CustomerNrExternal` | varchar(250) | No | External customer number, for example from the shop. If set, the customer is looked up by this number together with `ShopID`. |\n| `ShopID` | varchar(3) | No | Shop code compared with `Customers.CustomerOf`. Required for the lookup by `CustomerNrExternal`. |\n| `UserName` | varchar(50) | No | User name written to `UpdateEmp`. If empty or missing, `API` is used. |\n\n- If `CustomerNrExternal` is given but no customer matches, the variable keeps the passed `CustKey`. In that case the customer with that `CustKey` is updated, or nothing is updated if `CustKey` is `NULL`.\n- `ShopID` is compared with `=`. If `ShopID` is `NULL` while `CustomerNrExternal` is set, the lookup never finds a match.\n- If neither `CustKey` nor a matching external number is given, no row is updated and `Result` = `1` is returned.\n- The lookup uses `UPDLOCK`. There is no explicit transaction, so the lock is held only for the duration of that statement.\n- No error messages are produced. Only the `Result` value indicates success or failure.\n\nDocumentation: https://pixi-api-docs.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": "Returns customers with a customer history note (CHisNote) together with their invoices, optionally filtered by an invoice number.\n\nReads customer account entries (`CustomerAccount`) and joins the customer, the invoice and the invoice currency. Each row of the result is one customer account entry.\n\nThe call works in two modes:\n\n- **`InvoiceNr` given**: returns the entries whose invoice has exactly this invoice number. The customer note `CHisNote` is **not** checked in this mode, so customers without a note are returned as well. No sort order is applied.\n- **`InvoiceNr` empty or omitted**: returns all entries whose customer has a non-empty `CHisNote` and whose invoice has a non-empty invoice number. The rows are sorted by invoice date, newest first (`InvDate DESC`).\n\nThe number of returned rows is limited by `Rows` (default 300). An empty string for `InvoiceNr` is treated like `NULL`, and a `NULL` value for `Rows` is replaced by 300.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Rows` | int | No | Maximum number of rows to return (applied via `SET ROWCOUNT`). `NULL` is replaced by 300; `0` means no limit. |\n| `InvoiceNr` | varchar(64) | No | Invoice number to look up. If set, only entries for this invoice are returned and the customer note is not checked. Empty string is treated as `NULL` (list mode). |\n\n- The row limit is applied with `SET ROWCOUNT`. Passing `Rows` = `0` therefore removes the limit and returns **all** matching rows, which can be slow on large databases.\n- All tables are read `WITH (NOLOCK)`; uncommitted data may appear.\n- Although the joins are `LEFT JOIN`s, the `WHERE` conditions on the invoice (and in list mode on the customer) make them behave like inner joins: entries without invoice are never returned.\n- `CHisNote != ''` excludes customers whose note is `NULL`.\n- If a customer account has several entries referring to the same invoice, that invoice appears several times.\n- `Addresses` is joined but none of its columns is returned.\n- According to the header comment, the call was created for a specific customer project (ticket PC-95).\n\nDocumentation: https://pixi-api-docs.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": "Returns customers with a customer history note (CHisNote) together with their invoices, optionally filtered by an invoice number.\n\nReads customer account entries (`CustomerAccount`) and joins the customer, the invoice and the invoice currency. Each row of the result is one customer account entry.\n\nThe call works in two modes:\n\n- **`InvoiceNr` given**: returns the entries whose invoice has exactly this invoice number. The customer note `CHisNote` is **not** checked in this mode, so customers without a note are returned as well. No sort order is applied.\n- **`InvoiceNr` empty or omitted**: returns all entries whose customer has a non-empty `CHisNote` and whose invoice has a non-empty invoice number. The rows are sorted by invoice date, newest first (`InvDate DESC`).\n\nThe number of returned rows is limited by `Rows` (default 300). An empty string for `InvoiceNr` is treated like `NULL`, and a `NULL` value for `Rows` is replaced by 300.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Rows` | int | No | Maximum number of rows to return (applied via `SET ROWCOUNT`). `NULL` is replaced by 300; `0` means no limit. |\n| `InvoiceNr` | varchar(64) | No | Invoice number to look up. If set, only entries for this invoice are returned and the customer note is not checked. Empty string is treated as `NULL` (list mode). |\n\n- The row limit is applied with `SET ROWCOUNT`. Passing `Rows` = `0` therefore removes the limit and returns **all** matching rows, which can be slow on large databases.\n- All tables are read `WITH (NOLOCK)`; uncommitted data may appear.\n- Although the joins are `LEFT JOIN`s, the `WHERE` conditions on the invoice (and in list mode on the customer) make them behave like inner joins: entries without invoice are never returned.\n- `CHisNote != ''` excludes customers whose note is `NULL`.\n- If a customer account has several entries referring to the same invoice, that invoice appears several times.\n- `Addresses` is joined but none of its columns is returned.\n- According to the header comment, the call was created for a specific customer project (ticket PC-95).\n\nDocumentation: https://pixi-api-docs.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": "Updates the e-mail, name and postal address of an existing customer and its linked address, saving the previous address to the address history.\n\nUpdates a customer identified by `CustKey` together with the address linked to it through `Customers.AddrRef`.\n\n1. All text parameters are trimmed. Empty strings are treated as `NULL`.\n2. The customer is looked up by `CustKey`, joined to its address. The customer must have a linked address.\n - No match: status `404`.\n - More than one match: status `409`.\n3. If exactly one customer is found, the following steps run in one transaction:\n - The current address is copied to the address history. `HUpdateEmp` is set to `API` and `HNoteHist` to `Duplicate Check App`.\n - The customer's e-mail (`Customers.CeMail`) is set to `eMail`. This is **always** done, even if `eMail` is `NULL`.\n - The address is updated. Only parameters that are not `NULL` change the stored value:\n - `FirstName`, `LastName`, `Street`, `HouseNr`, `City`, `ZIP` and `eMail` are updated individually.\n - `Name` is rebuilt as first name + space + last name.\n - `Address` is rebuilt as street + space + house number.\n - The call returns status `200`.\n4. Any SQL error rolls back the transaction and returns status `500` with the SQL error text.\n\nThe call always returns exactly one status row with `StatusCode` and `ErrorMsg`. `ErrorMsg` also holds the success message.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | Yes | Key of the customer to update. |\n| `Street` | varchar(255) | No | New street. Trimmed; empty or `NULL` keeps the stored street. Also used to rebuild `Address`. |\n| `HouseNr` | varchar(10) | No | New house number. Trimmed; empty or `NULL` keeps the stored value. Also used to rebuild `Address`. |\n| `City` | varchar(60) | No | New city. Trimmed; empty or `NULL` keeps the stored city. |\n| `Zip` | varchar(10) | No | New postal code. Trimmed; empty or `NULL` keeps the stored value. |\n| `eMail` | varchar(256) | No | New e-mail address. Trimmed. Always written to `Customers.CeMail`, so `NULL` or empty clears it there. Written to `Addresses.eMail` only if not `NULL`. |\n| `FirstName` | varchar(60) | No | New first name. Trimmed; empty or `NULL` keeps the stored value. Also used to rebuild `Name`. |\n| `LastName` | varchar(60) | No | New last name. Trimmed; empty or `NULL` keeps the stored value. Also used to rebuild `Name`. |\n\n- **Pitfall – customer e-mail is cleared:** `Customers.CeMail` is overwritten with `eMail` without a `NULL` check. Leaving out `eMail`, or passing an empty value, clears the customer's e-mail. Only the address e-mail (`Addresses.eMail`) keeps its old value. Always pass the current e-mail if it must not change.\n- **Pitfall – rebuilt fields:** `Name` and `Address` are always rebuilt from first/last name and street/house number. The rebuild uses the parameters, or the stored column values if a parameter is `NULL`. If one of the two parts is `NULL` in both the parameter and the stored column, the result is usually `NULL` (standard `CONCAT_NULL_YIELDS_NULL` behaviour). A manually maintained value in `Name` or `Address` is overwritten.\n- **Not written to history:** the history row stores only the classic address fields (for example `Name`, `Address`, `City`, `ZIP`). `FirstName`, `LastName`, `Street`, `HouseNr` and `eMail` are not saved there.\n- **Context info:** during the address update the session `CONTEXT_INFO` is set to `0x33999` and reset to `0x00000` afterwards. Its purpose is not visible in the code; it is probably evaluated by triggers on `Addresses`.\n- **Locking:** the lookup reads with `NOLOCK`. The updates use `ROWLOCK` inside the named transaction `UpdateCustomer`.\n- **Error handling:** the CATCH block always issues `ROLLBACK TRANSACTION`. If an error occurs before the transaction has started, this rollback may raise an additional SQL error, which arrives as a `SqlMessage` alongside the `500` status row.\n- **Cleanup:** the temporary table is dropped via `util.TempTableDrop`. Its definition is not attached.\n- **NULL key:** if `CustKey` is `NULL`, status `404` is returned and `ErrorMsg` is `NULL`.\n\nDocumentation: https://pixi-api-docs.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": "Updates the e-mail, name and postal address of an existing customer and its linked address, saving the previous address to the address history.\n\nUpdates a customer identified by `CustKey` together with the address linked to it through `Customers.AddrRef`.\n\n1. All text parameters are trimmed. Empty strings are treated as `NULL`.\n2. The customer is looked up by `CustKey`, joined to its address. The customer must have a linked address.\n - No match: status `404`.\n - More than one match: status `409`.\n3. If exactly one customer is found, the following steps run in one transaction:\n - The current address is copied to the address history. `HUpdateEmp` is set to `API` and `HNoteHist` to `Duplicate Check App`.\n - The customer's e-mail (`Customers.CeMail`) is set to `eMail`. This is **always** done, even if `eMail` is `NULL`.\n - The address is updated. Only parameters that are not `NULL` change the stored value:\n - `FirstName`, `LastName`, `Street`, `HouseNr`, `City`, `ZIP` and `eMail` are updated individually.\n - `Name` is rebuilt as first name + space + last name.\n - `Address` is rebuilt as street + space + house number.\n - The call returns status `200`.\n4. Any SQL error rolls back the transaction and returns status `500` with the SQL error text.\n\nThe call always returns exactly one status row with `StatusCode` and `ErrorMsg`. `ErrorMsg` also holds the success message.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | Yes | Key of the customer to update. |\n| `Street` | varchar(255) | No | New street. Trimmed; empty or `NULL` keeps the stored street. Also used to rebuild `Address`. |\n| `HouseNr` | varchar(10) | No | New house number. Trimmed; empty or `NULL` keeps the stored value. Also used to rebuild `Address`. |\n| `City` | varchar(60) | No | New city. Trimmed; empty or `NULL` keeps the stored city. |\n| `Zip` | varchar(10) | No | New postal code. Trimmed; empty or `NULL` keeps the stored value. |\n| `eMail` | varchar(256) | No | New e-mail address. Trimmed. Always written to `Customers.CeMail`, so `NULL` or empty clears it there. Written to `Addresses.eMail` only if not `NULL`. |\n| `FirstName` | varchar(60) | No | New first name. Trimmed; empty or `NULL` keeps the stored value. Also used to rebuild `Name`. |\n| `LastName` | varchar(60) | No | New last name. Trimmed; empty or `NULL` keeps the stored value. Also used to rebuild `Name`. |\n\n- **Pitfall – customer e-mail is cleared:** `Customers.CeMail` is overwritten with `eMail` without a `NULL` check. Leaving out `eMail`, or passing an empty value, clears the customer's e-mail. Only the address e-mail (`Addresses.eMail`) keeps its old value. Always pass the current e-mail if it must not change.\n- **Pitfall – rebuilt fields:** `Name` and `Address` are always rebuilt from first/last name and street/house number. The rebuild uses the parameters, or the stored column values if a parameter is `NULL`. If one of the two parts is `NULL` in both the parameter and the stored column, the result is usually `NULL` (standard `CONCAT_NULL_YIELDS_NULL` behaviour). A manually maintained value in `Name` or `Address` is overwritten.\n- **Not written to history:** the history row stores only the classic address fields (for example `Name`, `Address`, `City`, `ZIP`). `FirstName`, `LastName`, `Street`, `HouseNr` and `eMail` are not saved there.\n- **Context info:** during the address update the session `CONTEXT_INFO` is set to `0x33999` and reset to `0x00000` afterwards. Its purpose is not visible in the code; it is probably evaluated by triggers on `Addresses`.\n- **Locking:** the lookup reads with `NOLOCK`. The updates use `ROWLOCK` inside the named transaction `UpdateCustomer`.\n- **Error handling:** the CATCH block always issues `ROLLBACK TRANSACTION`. If an error occurs before the transaction has started, this rollback may raise an additional SQL error, which arrives as a `SqlMessage` alongside the `500` status row.\n- **Cleanup:** the temporary table is dropped via `util.TempTableDrop`. Its definition is not attached.\n- **NULL key:** if `CustKey` is `NULL`, status `404` is returned and `ErrorMsg` is `NULL`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the customer key (`CustKey`) of a customer whose billing or shipping address matches the given e-mail/customer number and ZIP code.\n\nSimple web login lookup: identifies a customer by an e-mail address (or external customer number) combined with a ZIP code and returns the customer's `CustKey`.\n\nHow the match works:\n\n- Both `Email` and `ZIP` must be at least 4 characters long (`LEN`), otherwise no customer is found.\n- The customer's **billing address** (`Customers.AddrRef`) and **shipping address** (`Customers.ShipRef`) are checked separately. A customer matches if *one* of the two addresses satisfies both conditions:\n - `Email` matches the address field `CustomerNrExternal` **or** `eMail`.\n - `ZIP` matches the address field `ZIP`.\n- Each comparison is a bidirectional substring match: the input contains the stored value, or the stored value contains the input (`LIKE '%…%'` in both directions).\n- The first matching customer (`TOP 1`) is returned. There is no `ORDER BY`, so with several matches the returned customer is not deterministic.\n\nIf no customer matches, the function returns `NULL`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Email` | varchar(60) | Yes | E-mail address or external customer number (`CustomerNrExternal`) of the customer. Must be at least 4 characters long. |\n| `ZIP` | varchar(10) | Yes | ZIP code of the customer's billing or shipping address. Must be at least 4 characters long. |\n\n- **Not a secure authentication.** There is no password; knowledge of e-mail (or customer number) and ZIP code is enough. Use it only as a lightweight identification.\n- **Pitfall with empty stored values:** because of the reverse match (input `LIKE '%' + stored + '%'`), an address whose `eMail`, `CustomerNrExternal` or `ZIP` is an empty string matches *any* input of sufficient length. Stored `NULL` values do not match.\n- Substring matching is fuzzy: e.g. `ZIP` `1234` also matches a stored `12345`. Wildcard characters in the input (`%`, `_`, `[`) are interpreted by `LIKE`.\n- `LEN` ignores trailing spaces, so they do not count towards the minimum length of 4.\n- Tables are read with `NOLOCK`; uncommitted data may be returned.\n- Matching with leading wildcards cannot use indexes and may be slow on large customer tables.\n\nDocumentation: https://pixi-api-docs.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": "Returns the customer key (`CustKey`) of a customer whose billing or shipping address matches the given e-mail/customer number and ZIP code.\n\nSimple web login lookup: identifies a customer by an e-mail address (or external customer number) combined with a ZIP code and returns the customer's `CustKey`.\n\nHow the match works:\n\n- Both `Email` and `ZIP` must be at least 4 characters long (`LEN`), otherwise no customer is found.\n- The customer's **billing address** (`Customers.AddrRef`) and **shipping address** (`Customers.ShipRef`) are checked separately. A customer matches if *one* of the two addresses satisfies both conditions:\n - `Email` matches the address field `CustomerNrExternal` **or** `eMail`.\n - `ZIP` matches the address field `ZIP`.\n- Each comparison is a bidirectional substring match: the input contains the stored value, or the stored value contains the input (`LIKE '%…%'` in both directions).\n- The first matching customer (`TOP 1`) is returned. There is no `ORDER BY`, so with several matches the returned customer is not deterministic.\n\nIf no customer matches, the function returns `NULL`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Email` | varchar(60) | Yes | E-mail address or external customer number (`CustomerNrExternal`) of the customer. Must be at least 4 characters long. |\n| `ZIP` | varchar(10) | Yes | ZIP code of the customer's billing or shipping address. Must be at least 4 characters long. |\n\n- **Not a secure authentication.** There is no password; knowledge of e-mail (or customer number) and ZIP code is enough. Use it only as a lightweight identification.\n- **Pitfall with empty stored values:** because of the reverse match (input `LIKE '%' + stored + '%'`), an address whose `eMail`, `CustomerNrExternal` or `ZIP` is an empty string matches *any* input of sufficient length. Stored `NULL` values do not match.\n- Substring matching is fuzzy: e.g. `ZIP` `1234` also matches a stored `12345`. Wildcard characters in the input (`%`, `_`, `[`) are interpreted by `LIKE`.\n- `LEN` ignores trailing spaces, so they do not count towards the minimum length of 4.\n- Tables are read with `NOLOCK`; uncommitted data may be returned.\n- Matching with leading wildcards cannot use indexes and may be slow on large customer tables.\n\nDocumentation: https://pixi-api-docs.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": "Returns customs data (tariff number, country of origin, weight, dimensions) of one item, identified by item key, internal item number or EAN/UPC.\n\nReturns the customs-relevant master data of a single item from the item master data.\n\n1. If none of `ItemKey`, `ItemNrInt` and `EanUpc` is supplied, one status row is returned. All data columns are `NULL`, `ResultCode` is `501` and the call stops.\n2. If `ItemKey` is `NULL` or `0`, the item key is looked up by `ItemNrInt`, which is the internal item number.\n3. If no item key has been found yet, it is looked up by `EanUpc`.\n4. The item with the resolved key is returned. The country of origin `CustomsCountryOfOrigin` is joined to the country table to also return its ISO2 code. On success, `ResultCode` is `200` and `ResultMessage` is `OK`.\n\nIdentifier priority: `ItemKey`, then `ItemNrInt`, then `EanUpc`. If no matching item exists, the result set is empty and no error row is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item. Takes priority over the other identifiers. `NULL` or `0` means the item is looked up by `ItemNrInt` or `EanUpc`. |\n| `ItemNrInt` | varchar(50) | No | Internal item number. Used only if `ItemKey` is not supplied. |\n| `EanUpc` | varchar(50) | No | EAN/UPC of the item. Used only if no item was found by `ItemKey` or `ItemNrInt`. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- If a non-zero `ItemKey` is supplied that does not exist, `ItemNrInt` and `EanUpc` are **not** used as fallback. The result is simply empty.\n- The lookups by `ItemNrInt` and `EanUpc` use `TOP 1` without an `ORDER BY`. If several items share the same EAN, which item is returned is not defined.\n- Passing only `ItemKey = 0` passes the parameter check but returns an empty result set.\n- The column name `Heigth` is misspelled in the source and must be read exactly like this.\n- `CustomsCountryOfOriginISO2` is `NULL` if the country code is not found in the country table.\n\nDocumentation: https://pixi-api-docs.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": "Returns customs data (tariff number, country of origin, weight, dimensions) of one item, identified by item key, internal item number or EAN/UPC.\n\nReturns the customs-relevant master data of a single item from the item master data.\n\n1. If none of `ItemKey`, `ItemNrInt` and `EanUpc` is supplied, one status row is returned. All data columns are `NULL`, `ResultCode` is `501` and the call stops.\n2. If `ItemKey` is `NULL` or `0`, the item key is looked up by `ItemNrInt`, which is the internal item number.\n3. If no item key has been found yet, it is looked up by `EanUpc`.\n4. The item with the resolved key is returned. The country of origin `CustomsCountryOfOrigin` is joined to the country table to also return its ISO2 code. On success, `ResultCode` is `200` and `ResultMessage` is `OK`.\n\nIdentifier priority: `ItemKey`, then `ItemNrInt`, then `EanUpc`. If no matching item exists, the result set is empty and no error row is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item. Takes priority over the other identifiers. `NULL` or `0` means the item is looked up by `ItemNrInt` or `EanUpc`. |\n| `ItemNrInt` | varchar(50) | No | Internal item number. Used only if `ItemKey` is not supplied. |\n| `EanUpc` | varchar(50) | No | EAN/UPC of the item. Used only if no item was found by `ItemKey` or `ItemNrInt`. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- If a non-zero `ItemKey` is supplied that does not exist, `ItemNrInt` and `EanUpc` are **not** used as fallback. The result is simply empty.\n- The lookups by `ItemNrInt` and `EanUpc` use `TOP 1` without an `ORDER BY`. If several items share the same EAN, which item is returned is not defined.\n- Passing only `ItemKey = 0` passes the parameter check but returns an empty result set.\n- The column name `Heigth` is misspelled in the source and must be read exactly like this.\n- `CustomsCountryOfOriginISO2` is `NULL` if the country code is not found in the country table.\n\nDocumentation: https://pixi-api-docs.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": "Returns items that are not yet tagged with the system tag `AtlasData`, including master data and customs fields, paged by `ItemKey`.\n\nLists items whose customs information has not been marked as complete yet.\n\n1. The ID of the system tag `AtlasData` (tag type `1`, `IsSystemTag = 1`) is looked up in `Tag`.\n2. All items that have **no** assignment of this tag in `TagMatch` are selected.\n3. Only items with `ItemKey` greater than `ItemKeyStart` are returned.\n4. The result is sorted by `ItemKey` ascending and limited to `Rowcount` rows.\n\nFor each item the call returns master data (name, supplier, numbers, EAN, sales price, VAT level, weight and dimensions), all assigned item tags as a pipe-separated string, the ABC classification and the current customs fields (tariff number, country of origin with ISO2 code, tariff text, previous process).\n\n**Paging:** pass the highest `ItemKey` of the previous page as `ItemKeyStart` to get the next page. Start with `0`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Rowcount` | int | No | Maximum number of rows returned (page size). `0` means no limit. |\n| `ItemKeyStart` | int | No | Only items with `ItemKey` greater than this value are returned. Use the last `ItemKey` of the previous page for paging. |\n\n- \"Missing customs info\" is defined only by the absence of the `AtlasData` tag. The customs columns of returned items may already be filled; items with empty customs fields are not returned if they carry the tag.\n- If the system tag `AtlasData` does not exist, the tag ID is `NULL`, the `NOT EXISTS` check never matches and **all** items (above `ItemKeyStart`) are returned.\n- The row limit uses `SET ROWCOUNT`; `Rowcount = 0` removes the limit.\n- Inactive items are included; check the `Enabled` column.\n- All reads use `NOLOCK`, so uncommitted data may appear.\n- `ItemTAGs` and `ABC` are computed per row by scalar functions, which can be slow for large pages.\n- The column `Heigth` is spelled as in the database.\n\nDocumentation: https://pixi-api-docs.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": "Returns items that are not yet tagged with the system tag `AtlasData`, including master data and customs fields, paged by `ItemKey`.\n\nLists items whose customs information has not been marked as complete yet.\n\n1. The ID of the system tag `AtlasData` (tag type `1`, `IsSystemTag = 1`) is looked up in `Tag`.\n2. All items that have **no** assignment of this tag in `TagMatch` are selected.\n3. Only items with `ItemKey` greater than `ItemKeyStart` are returned.\n4. The result is sorted by `ItemKey` ascending and limited to `Rowcount` rows.\n\nFor each item the call returns master data (name, supplier, numbers, EAN, sales price, VAT level, weight and dimensions), all assigned item tags as a pipe-separated string, the ABC classification and the current customs fields (tariff number, country of origin with ISO2 code, tariff text, previous process).\n\n**Paging:** pass the highest `ItemKey` of the previous page as `ItemKeyStart` to get the next page. Start with `0`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Rowcount` | int | No | Maximum number of rows returned (page size). `0` means no limit. |\n| `ItemKeyStart` | int | No | Only items with `ItemKey` greater than this value are returned. Use the last `ItemKey` of the previous page for paging. |\n\n- \"Missing customs info\" is defined only by the absence of the `AtlasData` tag. The customs columns of returned items may already be filled; items with empty customs fields are not returned if they carry the tag.\n- If the system tag `AtlasData` does not exist, the tag ID is `NULL`, the `NOT EXISTS` check never matches and **all** items (above `ItemKeyStart`) are returned.\n- The row limit uses `SET ROWCOUNT`; `Rowcount = 0` removes the limit.\n- Inactive items are included; check the `Enabled` column.\n- All reads use `NOLOCK`, so uncommitted data may appear.\n- `ItemTAGs` and `ABC` are computed per row by scalar functions, which can be slow for large pages.\n- The column `Heigth` is spelled as in the database.\n\nDocumentation: https://pixi-api-docs.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": "Updates the customs data (tariff number, country of origin, tariff text, previous procedure) and the weight and dimensions of an item.\n\nUpdates customs-related fields and physical dimensions of one item, identified by `ItemKey`.\n\n1. If `CustomsCountryOfOriginISO2` is passed and not empty, the two-letter ISO code is looked up in the country table. The Pixi country code (`CntCode`) found there replaces the value of `CustomsCountryOfOrigin`.\n2. The item is updated. Only parameters that are not `NULL` overwrite the stored value. A parameter that is left out or passed as `NULL` keeps the current value.\n3. The update runs only if at least one passed value differs from the stored value, or if a stored value is `NULL` and a value is passed.\n4. On an update, `UpdateEmp` is set to ` (API)` and `UpdateDate` is set to the current date and time.\n\nThe call returns one status row:\n- `200` / `OK`: the item was changed.\n- `200` / `Accepted - no changes needed`: the item exists, but all passed values already match the stored values.\n- `401` / `Not found`: no item with this `ItemKey` exists.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Yes | Internal key of the item to update. |\n| `UserName` | varchar(50) | Yes | Name of the user or system that makes the change. It is stored in `UpdateEmp` with the suffix ` (API)`. |\n| `CustomsTariffNumber` | varchar(50) | No | Customs tariff number (HS code). `NULL` keeps the current value. |\n| `CustomsCountryOfOrigin` | varchar(3) | No | Pixi country code of the country of origin. It is overridden if `CustomsCountryOfOriginISO2` resolves to a country. `NULL` keeps the current value. |\n| `CustomsCountryOfOriginISO2` | varchar(2) | No | ISO 3166-1 alpha-2 code of the country of origin. If it is not empty, it is translated into the Pixi country code and takes precedence over `CustomsCountryOfOrigin`. |\n| `Weight` | numeric | No | Weight of the item. Decimal places are lost because the parameter is `numeric(18,0)`. `NULL` keeps the current value. |\n| `Heigth` | numeric | No | Height of the item (spelled `Heigth`). Decimal places are lost. `NULL` keeps the current value. |\n| `Width` | numeric | No | Width of the item. Decimal places are lost. `NULL` keeps the current value. |\n| `Length` | numeric | No | Length of the item. Decimal places are lost. `NULL` keeps the current value. |\n| `CustomsTariffText` | varchar(max) | No | Description of the goods for customs purposes. `NULL` keeps the current value. |\n| `CustomsPreviousProcess` | varchar(10) | No | Customs previous procedure code. `NULL` keeps the current value. |\n\n- `Weight`, `Heigth`, `Width` and `Length` are declared as plain `NUMERIC`. Without precision and scale this means `numeric(18,0)`, so decimal places are rounded away before the values are stored. Pass whole numbers in the unit Pixi uses for these fields.\n- The parameter for the height is spelled `Heigth`, as is the column.\n- A field cannot be reset to `NULL` with this call, because `NULL` means \"keep the current value\". An empty string, however, is stored as an empty string.\n- If `CustomsCountryOfOriginISO2` matches no country, the lookup assigns nothing. In that case the value passed in `CustomsCountryOfOrigin` is used, or the stored value is kept if that parameter is `NULL` as well. No error is returned.\n- The code returns `401` for a missing item, not `404`.\n- The update uses `ROWLOCK`. The country lookup and the existence check read with `NOLOCK`.\n- If nothing changes, `UpdateEmp` and `UpdateDate` are not touched.\n\nDocumentation: https://pixi-api-docs.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": "Updates the customs data (tariff number, country of origin, tariff text, previous procedure) and the weight and dimensions of an item.\n\nUpdates customs-related fields and physical dimensions of one item, identified by `ItemKey`.\n\n1. If `CustomsCountryOfOriginISO2` is passed and not empty, the two-letter ISO code is looked up in the country table. The Pixi country code (`CntCode`) found there replaces the value of `CustomsCountryOfOrigin`.\n2. The item is updated. Only parameters that are not `NULL` overwrite the stored value. A parameter that is left out or passed as `NULL` keeps the current value.\n3. The update runs only if at least one passed value differs from the stored value, or if a stored value is `NULL` and a value is passed.\n4. On an update, `UpdateEmp` is set to ` (API)` and `UpdateDate` is set to the current date and time.\n\nThe call returns one status row:\n- `200` / `OK`: the item was changed.\n- `200` / `Accepted - no changes needed`: the item exists, but all passed values already match the stored values.\n- `401` / `Not found`: no item with this `ItemKey` exists.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Yes | Internal key of the item to update. |\n| `UserName` | varchar(50) | Yes | Name of the user or system that makes the change. It is stored in `UpdateEmp` with the suffix ` (API)`. |\n| `CustomsTariffNumber` | varchar(50) | No | Customs tariff number (HS code). `NULL` keeps the current value. |\n| `CustomsCountryOfOrigin` | varchar(3) | No | Pixi country code of the country of origin. It is overridden if `CustomsCountryOfOriginISO2` resolves to a country. `NULL` keeps the current value. |\n| `CustomsCountryOfOriginISO2` | varchar(2) | No | ISO 3166-1 alpha-2 code of the country of origin. If it is not empty, it is translated into the Pixi country code and takes precedence over `CustomsCountryOfOrigin`. |\n| `Weight` | numeric | No | Weight of the item. Decimal places are lost because the parameter is `numeric(18,0)`. `NULL` keeps the current value. |\n| `Heigth` | numeric | No | Height of the item (spelled `Heigth`). Decimal places are lost. `NULL` keeps the current value. |\n| `Width` | numeric | No | Width of the item. Decimal places are lost. `NULL` keeps the current value. |\n| `Length` | numeric | No | Length of the item. Decimal places are lost. `NULL` keeps the current value. |\n| `CustomsTariffText` | varchar(max) | No | Description of the goods for customs purposes. `NULL` keeps the current value. |\n| `CustomsPreviousProcess` | varchar(10) | No | Customs previous procedure code. `NULL` keeps the current value. |\n\n- `Weight`, `Heigth`, `Width` and `Length` are declared as plain `NUMERIC`. Without precision and scale this means `numeric(18,0)`, so decimal places are rounded away before the values are stored. Pass whole numbers in the unit Pixi uses for these fields.\n- The parameter for the height is spelled `Heigth`, as is the column.\n- A field cannot be reset to `NULL` with this call, because `NULL` means \"keep the current value\". An empty string, however, is stored as an empty string.\n- If `CustomsCountryOfOriginISO2` matches no country, the lookup assigns nothing. In that case the value passed in `CustomsCountryOfOrigin` is used, or the stored value is kept if that parameter is `NULL` as well. No error is returned.\n- The code returns `401` for a missing item, not `404`.\n- The update uses `ROWLOCK`. The country lookup and the existence check read with `NOLOCK`.\n- If nothing changes, `UpdateEmp` and `UpdateDate` are not touched.\n\nDocumentation: https://pixi-api-docs.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": "Creates direct fulfilment (DF) invoices for order lines that are ready, optionally restricted to and enriched with ship vendor and tracking data from XML.\n\nThe call creates invoices for direct fulfilment orders. The actual work is done by the internal procedure `Pixi_CreateFulfillmentIncoices`, which runs with `CreateEmp = 'API'`.\n\n**Steps**\n\n1. An exclusive application lock `pipiDFCreateInvoices` is requested with a timeout of 5 seconds, so that parallel runs are serialised.\n2. If `OrderlinesXML` is given (an empty string counts as NULL), the elements `/Orderlines/Orderline` are read with the child elements `OrderlineKey`, `ShipVendor`, `ShipmentTrackingId` and `ReturnTrackingId`.\n3. If `ShowDetailedMessages = 1`, the input is validated first:\n - The XML must be present and contain at least one `Orderline`.\n - The ship vendor code (taken from the first line of each order) may be at most 3 characters long.\n - All shipment tracking IDs of an order, joined with `;`, may be at most 512 characters long. The same limit applies to the return tracking IDs.\n - Every `OrderlineKey` must exist in `Orderlines`.\n \n If any check fails, all error rows are returned and no invoice is created.\n4. Invoices are created. The behaviour depends on the settings `EnableFulfilmentTypeOne` and `EnableFulfilmentTypeTwo`:\n - **Type one:** order lines from the XML that have status `FUT` are first set to `FUS`. Then one invoice is created per order that has `FUS` lines. With XML, only the listed lines are used; without XML, all `FUS` lines are used.\n - **Type two:** candidate orders are those whose lines are all `FUS` or in a final state, and that have at least one `FUS` line without an invoice. The XML does not restrict the candidate orders. It only restricts which `FUS` lines are added to the invoice. Lines with status `MIN` are always added.\n5. Each order is processed in its own transaction:\n - The invoice is created, flagged with `Fulfillment = 1` and given its invoice positions.\n - The ship vendor from the XML overrides the ship vendor of the order.\n - Tracking IDs from the XML are stored on the invoice. Several IDs can be separated by `;`, and each distinct ID becomes its own invoice package.\n - The order lines are set to `AUS` with `InvRef` and `ShipDate`.\n - An invoice number is assigned, an entry is posted to the customer account and the invoice is scanned out.\n - An `InvoiceCreated` event is published.\n6. If `ShowDetailedMessages = 1`, one status table is returned:\n - one `OK` row listing the invoice numbers linked to the given order lines;\n - an `ERROR` row listing orders whose given lines have no invoice position;\n - an `ERROR` row if neither of the two applies.\n\nWith `ShowDetailedMessages = 0`, no result set is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlinesXML` | varchar(max) | No | XML with the order lines to invoice, plus optional ship vendor and tracking data. Expected path: `/Orderlines/Orderline`, with the elements `OrderlineKey`, `ShipVendor` (max. 3 characters), `ShipmentTrackingId` and `ReturnTrackingId`. Several tracking IDs can be separated by `;`. If NULL or empty, all eligible order lines are processed. With `ShowDetailedMessages = 1` the XML is mandatory. |\n| `ShowDetailedMessages` | bit | No | Controls input validation and the status result set. NULL is treated as 0. |\n\n- **Errors are swallowed.** The whole body runs in `TRY/CATCH`. The `CATCH` block only releases the application lock, so SQL errors never reach the caller. With `ShowDetailedMessages = 0` the caller gets no feedback at all.\n- **Lock result is not checked.** The return value of `sp_getapplock` is ignored. If the lock cannot be obtained within 5 seconds, processing continues anyway.\n- **Lock not released on validation errors.** On the early returns after a validation error the lock is not released explicitly. It stays with the session until the session ends.\n- **Truncation risk.** `ErrorMessage` is `varchar(512)` and the list of invoice numbers is held in a `varchar(512)` variable. Long lists of order numbers or invoice numbers can be truncated, or can raise a truncation error that is then silently caught.\n- **Validation is optional.** It only runs with `ShowDetailedMessages = 1`. Without it, the internal procedure reads `ShipVendor` as `varchar(3)` and the tracking IDs as `varchar(512)`, so longer values may be cut.\n- **Meaning of the `OK` row.** It lists every invoice linked to the given order lines, which can include invoices created earlier. The code comment names a supplier without `CanDoDirectFulfillment` or a line status other than `FUT` as typical reasons for a missing invoice.\n- **Settings.**\n - If neither `EnableFulfilmentTypeOne` nor `EnableFulfilmentTypeTwo` is `1`, no invoices are created.\n - With `DoNotSendAUSmailOnFulfillment` = `1`/`Y`, the order lines are additionally marked `CustomerEMailed = 'Y'`.\n- **Invoice numbers.** An existing external invoice number on the order lines (`InvoiceNrExternal`) is used when the invoice is created. The internal procedure then calls `Pixi_GetNextInvNr` and writes its result to `InvoiceNr`. Whether that keeps the external number cannot be seen because that procedure is not attached.\n- **Rollback per order.** An invoice without positions is rolled back and deleted, as is an order that produced errors. Other orders are not affected.\n- **Further side effects.** Several nested procedures are not attached: `GOS_Qi_InvoiceNOD`, `Pixi_CA_AddPixiInvoice`, `GOSScanOutInvoice`, `Pixi_PollCreateRecords`, `Pixi_MQ_EventPublish` and `Pixi_AddDataForSEPAExportToInvoice`. Their side effects are not documented here.\n\nDocumentation: https://pixi-api-docs.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": "Creates direct fulfilment (DF) invoices for order lines that are ready, optionally restricted to and enriched with ship vendor and tracking data from XML.\n\nThe call creates invoices for direct fulfilment orders. The actual work is done by the internal procedure `Pixi_CreateFulfillmentIncoices`, which runs with `CreateEmp = 'API'`.\n\n**Steps**\n\n1. An exclusive application lock `pipiDFCreateInvoices` is requested with a timeout of 5 seconds, so that parallel runs are serialised.\n2. If `OrderlinesXML` is given (an empty string counts as NULL), the elements `/Orderlines/Orderline` are read with the child elements `OrderlineKey`, `ShipVendor`, `ShipmentTrackingId` and `ReturnTrackingId`.\n3. If `ShowDetailedMessages = 1`, the input is validated first:\n - The XML must be present and contain at least one `Orderline`.\n - The ship vendor code (taken from the first line of each order) may be at most 3 characters long.\n - All shipment tracking IDs of an order, joined with `;`, may be at most 512 characters long. The same limit applies to the return tracking IDs.\n - Every `OrderlineKey` must exist in `Orderlines`.\n \n If any check fails, all error rows are returned and no invoice is created.\n4. Invoices are created. The behaviour depends on the settings `EnableFulfilmentTypeOne` and `EnableFulfilmentTypeTwo`:\n - **Type one:** order lines from the XML that have status `FUT` are first set to `FUS`. Then one invoice is created per order that has `FUS` lines. With XML, only the listed lines are used; without XML, all `FUS` lines are used.\n - **Type two:** candidate orders are those whose lines are all `FUS` or in a final state, and that have at least one `FUS` line without an invoice. The XML does not restrict the candidate orders. It only restricts which `FUS` lines are added to the invoice. Lines with status `MIN` are always added.\n5. Each order is processed in its own transaction:\n - The invoice is created, flagged with `Fulfillment = 1` and given its invoice positions.\n - The ship vendor from the XML overrides the ship vendor of the order.\n - Tracking IDs from the XML are stored on the invoice. Several IDs can be separated by `;`, and each distinct ID becomes its own invoice package.\n - The order lines are set to `AUS` with `InvRef` and `ShipDate`.\n - An invoice number is assigned, an entry is posted to the customer account and the invoice is scanned out.\n - An `InvoiceCreated` event is published.\n6. If `ShowDetailedMessages = 1`, one status table is returned:\n - one `OK` row listing the invoice numbers linked to the given order lines;\n - an `ERROR` row listing orders whose given lines have no invoice position;\n - an `ERROR` row if neither of the two applies.\n\nWith `ShowDetailedMessages = 0`, no result set is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlinesXML` | varchar(max) | No | XML with the order lines to invoice, plus optional ship vendor and tracking data. Expected path: `/Orderlines/Orderline`, with the elements `OrderlineKey`, `ShipVendor` (max. 3 characters), `ShipmentTrackingId` and `ReturnTrackingId`. Several tracking IDs can be separated by `;`. If NULL or empty, all eligible order lines are processed. With `ShowDetailedMessages = 1` the XML is mandatory. |\n| `ShowDetailedMessages` | bit | No | Controls input validation and the status result set. NULL is treated as 0. |\n\n- **Errors are swallowed.** The whole body runs in `TRY/CATCH`. The `CATCH` block only releases the application lock, so SQL errors never reach the caller. With `ShowDetailedMessages = 0` the caller gets no feedback at all.\n- **Lock result is not checked.** The return value of `sp_getapplock` is ignored. If the lock cannot be obtained within 5 seconds, processing continues anyway.\n- **Lock not released on validation errors.** On the early returns after a validation error the lock is not released explicitly. It stays with the session until the session ends.\n- **Truncation risk.** `ErrorMessage` is `varchar(512)` and the list of invoice numbers is held in a `varchar(512)` variable. Long lists of order numbers or invoice numbers can be truncated, or can raise a truncation error that is then silently caught.\n- **Validation is optional.** It only runs with `ShowDetailedMessages = 1`. Without it, the internal procedure reads `ShipVendor` as `varchar(3)` and the tracking IDs as `varchar(512)`, so longer values may be cut.\n- **Meaning of the `OK` row.** It lists every invoice linked to the given order lines, which can include invoices created earlier. The code comment names a supplier without `CanDoDirectFulfillment` or a line status other than `FUT` as typical reasons for a missing invoice.\n- **Settings.**\n - If neither `EnableFulfilmentTypeOne` nor `EnableFulfilmentTypeTwo` is `1`, no invoices are created.\n - With `DoNotSendAUSmailOnFulfillment` = `1`/`Y`, the order lines are additionally marked `CustomerEMailed = 'Y'`.\n- **Invoice numbers.** An existing external invoice number on the order lines (`InvoiceNrExternal`) is used when the invoice is created. The internal procedure then calls `Pixi_GetNextInvNr` and writes its result to `InvoiceNr`. Whether that keeps the external number cannot be seen because that procedure is not attached.\n- **Rollback per order.** An invoice without positions is rolled back and deleted, as is an order that produced errors. Other orders are not affected.\n- **Further side effects.** Several nested procedures are not attached: `GOS_Qi_InvoiceNOD`, `Pixi_CA_AddPixiInvoice`, `GOSScanOutInvoice`, `Pixi_PollCreateRecords`, `Pixi_MQ_EventPublish` and `Pixi_AddDataForSEPAExportToInvoice`. Their side effects are not documented here.\n\nDocumentation: https://pixi-api-docs.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": "Returns the latest not yet notified fulfilment status changes of `FUT` order lines for a Direct Fulfillment supplier, with address, item and order data.\n\nAPI call for Direct Fulfillment (DF) suppliers that fetches the order line changes they still have to process.\n\n**Authentication**\n\n- The supplier is looked up in `Suppliers` by `SupplNr`. `Secret` must match the supplier's `CustNr`. The supplier must not be disabled and must have `CanDoDirectFulfillment = 1`.\n- If no supplier matches and the setting `DFAPIAllowFullAccessWithoutSecret` is `0` (or missing), a single row with `Error = 403` is returned.\n- If no supplier matches but the setting is not `0`, the call continues **without a supplier filter** and returns changes of all suppliers.\n\n**Selection**\n\nFor every order line, only the newest `OrderHistory` entry (highest `OrderHistKey`) is considered, and only if all of these conditions apply:\n\n- the order line has status `FUT`;\n- the history status is an `OrderStates` state with `FulfilmentStatus = 'Y'`;\n- the order line's `SupplInfo` equals the authenticated supplier (if one was found);\n- the shipping address (`ASlocked`) and the customer (`SLocked`) are not locked, unless `LockedCustomers = 1`;\n- `OrderNrExternal` matches `OrderNRExternal`, if that parameter is given;\n- the order header was created more than 5 minutes ago.\n\nIn addition, the history entry must have `ClientNotified = 'N'`. Order lines whose status is contained in `ExcludeStatuses` are skipped.\n\n**Output**\n\n- If any order line appears more than once in the result, a single message row is returned instead of the data and the call stops.\n- Otherwise all rows are returned, sorted by `StatusChangeDate`. In databases whose name starts with `pixi_PSP`, they are sorted by `ordernr`, then `StatusChangeDate`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | No | Supplier number of the Direct Fulfillment supplier. Used for authentication and to filter order lines by `SupplInfo`. |\n| `Secret` | varchar(20) | No | Secret of the supplier. Must match the supplier's `CustNr` in `Suppliers`. |\n| `OrderNRExternal` | varchar(50) | No | Optional external order number. Restricts the result to changes of this order; empty or NULL means all orders. |\n| `ExcludeStatuses` | varchar(200) | No | Order line statuses to exclude, matched as substrings (e.g. `STO,AUS`). Defaults to `STO` in `pixi_PSP` databases when empty. |\n| `LockedCustomers` | bit | No | Whether order lines with locked shipping addresses or locked customers are included. |\n\n- The call is read-only. It does **not** set `ClientNotified`, so the same changes are returned again until they are marked as notified by another process. That process is not part of this code.\n- All tables are read `WITH (NOLOCK)`, so uncommitted data may appear.\n- `ExcludeStatuses` is checked with `CHARINDEX` (substring match), so any separator works, e.g. `STO,AUS`. The inner selection already only returns `FUT` lines, so the parameter only matters if it contains `FUT`, which would suppress all rows.\n- If `ExcludeStatuses` is empty and the database name starts with `pixi_PSP`, it defaults to `STO`.\n- If `SupplNr`/`Secret` are wrong but `DFAPIAllowFullAccessWithoutSecret` is not `0`, the data of **all** suppliers is returned.\n- Orders created less than 5 minutes ago are held back.\n- The temporary table is handled by `util.TempTableDrop`. That object is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Returns the latest not yet notified fulfilment status changes of `FUT` order lines for a Direct Fulfillment supplier, with address, item and order data.\n\nAPI call for Direct Fulfillment (DF) suppliers that fetches the order line changes they still have to process.\n\n**Authentication**\n\n- The supplier is looked up in `Suppliers` by `SupplNr`. `Secret` must match the supplier's `CustNr`. The supplier must not be disabled and must have `CanDoDirectFulfillment = 1`.\n- If no supplier matches and the setting `DFAPIAllowFullAccessWithoutSecret` is `0` (or missing), a single row with `Error = 403` is returned.\n- If no supplier matches but the setting is not `0`, the call continues **without a supplier filter** and returns changes of all suppliers.\n\n**Selection**\n\nFor every order line, only the newest `OrderHistory` entry (highest `OrderHistKey`) is considered, and only if all of these conditions apply:\n\n- the order line has status `FUT`;\n- the history status is an `OrderStates` state with `FulfilmentStatus = 'Y'`;\n- the order line's `SupplInfo` equals the authenticated supplier (if one was found);\n- the shipping address (`ASlocked`) and the customer (`SLocked`) are not locked, unless `LockedCustomers = 1`;\n- `OrderNrExternal` matches `OrderNRExternal`, if that parameter is given;\n- the order header was created more than 5 minutes ago.\n\nIn addition, the history entry must have `ClientNotified = 'N'`. Order lines whose status is contained in `ExcludeStatuses` are skipped.\n\n**Output**\n\n- If any order line appears more than once in the result, a single message row is returned instead of the data and the call stops.\n- Otherwise all rows are returned, sorted by `StatusChangeDate`. In databases whose name starts with `pixi_PSP`, they are sorted by `ordernr`, then `StatusChangeDate`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | No | Supplier number of the Direct Fulfillment supplier. Used for authentication and to filter order lines by `SupplInfo`. |\n| `Secret` | varchar(20) | No | Secret of the supplier. Must match the supplier's `CustNr` in `Suppliers`. |\n| `OrderNRExternal` | varchar(50) | No | Optional external order number. Restricts the result to changes of this order; empty or NULL means all orders. |\n| `ExcludeStatuses` | varchar(200) | No | Order line statuses to exclude, matched as substrings (e.g. `STO,AUS`). Defaults to `STO` in `pixi_PSP` databases when empty. |\n| `LockedCustomers` | bit | No | Whether order lines with locked shipping addresses or locked customers are included. |\n\n- The call is read-only. It does **not** set `ClientNotified`, so the same changes are returned again until they are marked as notified by another process. That process is not part of this code.\n- All tables are read `WITH (NOLOCK)`, so uncommitted data may appear.\n- `ExcludeStatuses` is checked with `CHARINDEX` (substring match), so any separator works, e.g. `STO,AUS`. The inner selection already only returns `FUT` lines, so the parameter only matters if it contains `FUT`, which would suppress all rows.\n- If `ExcludeStatuses` is empty and the database name starts with `pixi_PSP`, it defaults to `STO`.\n- If `SupplNr`/`Secret` are wrong but `DFAPIAllowFullAccessWithoutSecret` is not `0`, the data of **all** suppliers is returned.\n- Orders created less than 5 minutes ago are held back.\n- The temporary table is handled by `util.TempTableDrop`. That object is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Confirms a processed order history change for a direct fulfillment supplier by setting its ClientNotified flag and, optionally, the tracking sent date of an invoice.\n\nAcknowledges an order history entry from the Direct Fulfillment API. A supplier calls this after it has processed a change, so that the change is marked as delivered.\n\n1. **Authentication:** The supplier is looked up in `Suppliers` by `SupplNr`, with `CustNr` = `Secret`, not disabled (`Disabled` <> 1) and enabled for direct fulfillment (`CanDoDirectFulfillment` = 1).\n - If no supplier matches and the setting `DFAPIAllowFullAccessWithoutSecret` is `0`, the call returns status `403`. The setting is also treated as `0` if it does not exist.\n - If the setting has any other value, the secret check is skipped.\n2. **Lookup:** If the `OrderHistKey` does not exist in `OrderHistory`, the call returns status `404`.\n3. **Update:** Otherwise the internal procedure `GOSUpdateOHClientNotifiedXML` is executed:\n - The order history entry gets `ClientNotified` = `Y` (only if `OrderHistKey` <> 0).\n - If `InvoiceKey` <> 0, `Invoices.TrackingIDSent` of that Rechnung is set to the current date and time.\n - On success the status is `200`. If an error occurs, the status is `500` with the SQL error message.\n\nThe call always returns exactly one row with `Status` and `ErrorMsg`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Yes | Supplier number of the direct fulfillment supplier. |\n| `Secret` | varchar(20) | Yes | Secret of the supplier. It is compared with the `CustNr` field of the supplier. |\n| `OrderHistKey` | int | Yes | Key of the order history entry to confirm. The entry is marked with `ClientNotified` = `Y`. |\n| `InvoiceKey` | int | No | Optional invoice key. If not 0, `TrackingIDSent` of this Rechnung is set to the current date and time. |\n\n- The code does not check that the `OrderHistKey` or the `InvoiceKey` belongs to the authenticated supplier. Any existing order history entry can be confirmed.\n- `InvoiceKey` is not validated. If the Rechnung does not exist, no row is updated, but the status is still `200`.\n- The two updates are not wrapped in an explicit transaction. If the invoice update fails, the `ClientNotified` flag may already be set while the call returns `500`.\n- The supplier lookup and the existence check use `NOLOCK`.\n- If `OrderHistKey` is `NULL`, the `404` message becomes `NULL` because of the string concatenation.\n\nDocumentation: https://pixi-api-docs.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": "Confirms a processed order history change for a direct fulfillment supplier by setting its ClientNotified flag and, optionally, the tracking sent date of an invoice.\n\nAcknowledges an order history entry from the Direct Fulfillment API. A supplier calls this after it has processed a change, so that the change is marked as delivered.\n\n1. **Authentication:** The supplier is looked up in `Suppliers` by `SupplNr`, with `CustNr` = `Secret`, not disabled (`Disabled` <> 1) and enabled for direct fulfillment (`CanDoDirectFulfillment` = 1).\n - If no supplier matches and the setting `DFAPIAllowFullAccessWithoutSecret` is `0`, the call returns status `403`. The setting is also treated as `0` if it does not exist.\n - If the setting has any other value, the secret check is skipped.\n2. **Lookup:** If the `OrderHistKey` does not exist in `OrderHistory`, the call returns status `404`.\n3. **Update:** Otherwise the internal procedure `GOSUpdateOHClientNotifiedXML` is executed:\n - The order history entry gets `ClientNotified` = `Y` (only if `OrderHistKey` <> 0).\n - If `InvoiceKey` <> 0, `Invoices.TrackingIDSent` of that Rechnung is set to the current date and time.\n - On success the status is `200`. If an error occurs, the status is `500` with the SQL error message.\n\nThe call always returns exactly one row with `Status` and `ErrorMsg`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Yes | Supplier number of the direct fulfillment supplier. |\n| `Secret` | varchar(20) | Yes | Secret of the supplier. It is compared with the `CustNr` field of the supplier. |\n| `OrderHistKey` | int | Yes | Key of the order history entry to confirm. The entry is marked with `ClientNotified` = `Y`. |\n| `InvoiceKey` | int | No | Optional invoice key. If not 0, `TrackingIDSent` of this Rechnung is set to the current date and time. |\n\n- The code does not check that the `OrderHistKey` or the `InvoiceKey` belongs to the authenticated supplier. Any existing order history entry can be confirmed.\n- `InvoiceKey` is not validated. If the Rechnung does not exist, no row is updated, but the status is still `200`.\n- The two updates are not wrapped in an explicit transaction. If the invoice update fails, the `ClientNotified` flag may already be set while the call returns `500`.\n- The supplier lookup and the existence check use `NOLOCK`.\n- If `OrderHistKey` is `NULL`, the `404` message becomes `NULL` because of the string concatenation.\n\nDocumentation: https://pixi-api-docs.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": "Returns the open direct fulfillment order lines (status FUT) of one order for a direct fulfillment supplier, authenticated by supplier number and secret.\n\nUsed by direct fulfillment (drop shipping) suppliers to fetch the order lines of one order they have to ship.\n\n**Authentication**\n\n- Empty strings in `SupplNr` and `Secret` are treated as `NULL`.\n- The call looks for a supplier in `Suppliers` whose `SupplNr` equals `SupplNr` and whose `CustNr` equals `Secret`. The supplier must not be disabled and must have `CanDoDirectFulfillment = 1`.\n- If no such supplier exists and the setting `DFAPIAllowFullAccessWithoutSecret` is `0` (or missing), a single row with `Error = '403'` is returned and nothing else.\n- If the setting is not `0`, the check is skipped and the call works without a valid secret.\n\n**Order lines returned**\n\nOnly lines that meet all of these conditions:\n\n- The line belongs to the order `OrderNR`.\n- The line has status `FUT`, and its latest `OrderHistory` entry with status `FUT` is used (`OrderHistKey`, `StatusChangeDate`, `ClientNotified`).\n- The status `FUT` is marked as a fulfilment status in `OrderStates` (`FulfilmentStatus = 'Y'`).\n- Unless `AllOrderlines = 1`, only lines that have not yet been confirmed (`ClientNotified = 'N'`) are returned.\n- If `SupplNr` is given, only lines with `SupplInfo = SupplNr` are returned, and that supplier must be able to do direct fulfillment. If `SupplNr` is empty (only possible when the secret check is disabled), lines of all suppliers are returned.\n- The shipping address must not be locked (`ASlocked`) and the customer must not be locked (`SLocked`).\n- Order header, invoice address, customer and currency must exist (inner joins).\n\n**Item data**\n\n`EANUPC`, `ItemNrSuppl` and `ItemNrInt` are taken from the supplier-specific `AddItems` record (supplier = `SupplInfo` of the line, the most recently updated one); if no such value exists, the values from `Items` are used.\n\nDuplicate rows are removed (`DISTINCT`). No sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNR` | int | Yes | Number of the order whose direct fulfillment lines are returned. |\n| `SupplNr` | varchar(4) | No | Supplier number of the direct fulfillment supplier. Used for authentication and to restrict the lines to this supplier. Empty string is treated as NULL. |\n| `Secret` | varchar(20) | No | Secret of the supplier; must match the field `CustNr` of the supplier. Empty string is treated as NULL. |\n| `AllOrderlines` | bit | No | Controls whether already confirmed lines are included. |\n\n- The error is returned as a normal result row (`Error`, `ErrorMsg`), not as a SQL error. Check for the column `Error` in the response.\n- `Secret` is compared with the field `CustNr` of the supplier (the customer number under which the shop is known at the supplier).\n- If `DFAPIAllowFullAccessWithoutSecret` is enabled and `SupplNr` is left empty, the order lines of **all** suppliers of the order are returned. Keep this setting at `0` in production.\n- The call is read-only; it does not mark lines as confirmed. `OrderlineConfirmed` reflects `ClientNotified` of the latest `FUT` history entry.\n- All tables are read with `NOLOCK`, so uncommitted data can be returned.\n\nDocumentation: https://pixi-api-docs.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": "Returns the open direct fulfillment order lines (status FUT) of one order for a direct fulfillment supplier, authenticated by supplier number and secret.\n\nUsed by direct fulfillment (drop shipping) suppliers to fetch the order lines of one order they have to ship.\n\n**Authentication**\n\n- Empty strings in `SupplNr` and `Secret` are treated as `NULL`.\n- The call looks for a supplier in `Suppliers` whose `SupplNr` equals `SupplNr` and whose `CustNr` equals `Secret`. The supplier must not be disabled and must have `CanDoDirectFulfillment = 1`.\n- If no such supplier exists and the setting `DFAPIAllowFullAccessWithoutSecret` is `0` (or missing), a single row with `Error = '403'` is returned and nothing else.\n- If the setting is not `0`, the check is skipped and the call works without a valid secret.\n\n**Order lines returned**\n\nOnly lines that meet all of these conditions:\n\n- The line belongs to the order `OrderNR`.\n- The line has status `FUT`, and its latest `OrderHistory` entry with status `FUT` is used (`OrderHistKey`, `StatusChangeDate`, `ClientNotified`).\n- The status `FUT` is marked as a fulfilment status in `OrderStates` (`FulfilmentStatus = 'Y'`).\n- Unless `AllOrderlines = 1`, only lines that have not yet been confirmed (`ClientNotified = 'N'`) are returned.\n- If `SupplNr` is given, only lines with `SupplInfo = SupplNr` are returned, and that supplier must be able to do direct fulfillment. If `SupplNr` is empty (only possible when the secret check is disabled), lines of all suppliers are returned.\n- The shipping address must not be locked (`ASlocked`) and the customer must not be locked (`SLocked`).\n- Order header, invoice address, customer and currency must exist (inner joins).\n\n**Item data**\n\n`EANUPC`, `ItemNrSuppl` and `ItemNrInt` are taken from the supplier-specific `AddItems` record (supplier = `SupplInfo` of the line, the most recently updated one); if no such value exists, the values from `Items` are used.\n\nDuplicate rows are removed (`DISTINCT`). No sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNR` | int | Yes | Number of the order whose direct fulfillment lines are returned. |\n| `SupplNr` | varchar(4) | No | Supplier number of the direct fulfillment supplier. Used for authentication and to restrict the lines to this supplier. Empty string is treated as NULL. |\n| `Secret` | varchar(20) | No | Secret of the supplier; must match the field `CustNr` of the supplier. Empty string is treated as NULL. |\n| `AllOrderlines` | bit | No | Controls whether already confirmed lines are included. |\n\n- The error is returned as a normal result row (`Error`, `ErrorMsg`), not as a SQL error. Check for the column `Error` in the response.\n- `Secret` is compared with the field `CustNr` of the supplier (the customer number under which the shop is known at the supplier).\n- If `DFAPIAllowFullAccessWithoutSecret` is enabled and `SupplNr` is left empty, the order lines of **all** suppliers of the order are returned. Keep this setting at `0` in production.\n- The call is read-only; it does not mark lines as confirmed. `OrderlineConfirmed` reflects `ClientNotified` of the latest `FUT` history entry.\n- All tables are read with `NOLOCK`, so uncommitted data can be returned.\n\nDocumentation: https://pixi-api-docs.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": "Returns the direct-fulfillment (FUT) orderlines of one order for an authorized drop-shipping supplier, including item, status history and currency data.\n\nInterface call for direct-fulfillment (drop-shipping) suppliers to fetch the orderlines of a single order that they have to fulfil.\n\n**Authorization**\n\n1. Empty strings in `SupplNr` and `Secret` are treated as `NULL`.\n2. A supplier is searched in `Suppliers` whose `SupplNr` equals `SupplNr`, whose `CustNr` equals `Secret`, that is not disabled and has `CanDoDirectFulfillment = 1`.\n3. If no such supplier is found and the setting `DFAPIAllowFullAccessWithoutSecret` is `0` (or not present), a single error row with `Error = 403` is returned and nothing else.\n4. Otherwise the orderlines are returned.\n\n**Selection of orderlines**\n\n- Only lines of the order `OrderNR` with orderline status `FUT`.\n- Each line is joined to its most recent `OrderHistory` entry with status `FUT`; that status must be a fulfilment state in `OrderStates` (`FulfilmentStatus = 'Y'`).\n- By default only lines whose history entry is not yet confirmed (`ClientNotified = 'N'`) are returned; with `AllOrderlines = 1` confirmed lines are included as well.\n- If `SupplNr` is given, only lines whose `SupplInfo` equals `SupplNr` and whose supplier is a direct-fulfillment supplier are returned. If `SupplNr` is empty (only possible when full access without secret is allowed), lines of all suppliers are returned.\n- Lines are excluded if the shipping address is locked (`ASLocked = 'Y'`) or the customer is locked (`SLocked = 'Y'`).\n- Lines without a matching billing address, customer, order header or currency are not returned (inner joins).\n\n**Item data**\n\nFor each line the item is read from `Items`; the supplier-specific additional item record in `AddItems` (matching the line's supplier, newest by `UpdateDate`) provides `ItemNrSuppl` with priority, while `EANUPC` is taken from the item first and from `AddItems` only as fallback.\n\nThe result is `DISTINCT` and has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNR` | int | Yes | Pixi order number whose orderlines are returned. |\n| `SupplNr` | varchar(4) | No | Supplier number of the direct-fulfillment supplier. Used for authorization and to restrict the lines to this supplier. Empty string is treated as NULL. |\n| `Secret` | varchar(20) | No | Secret of the supplier; must match the `CustNr` stored for the supplier. Empty string is treated as NULL. |\n| `AllOrderlines` | bit | No | Controls whether already confirmed lines are included. |\n\n- All tables are read with `NOLOCK`; uncommitted data may be returned.\n- The `Secret` is compared with the supplier's `CustNr` field (the customer number Pixi has at the supplier).\n- If the setting `DFAPIAllowFullAccessWithoutSecret` is not `0`, the secret check is effectively disabled: any caller gets data, and with an empty `SupplNr` even the lines of all suppliers of the order.\n- The call is read-only: it does not set `ClientNotified`. Confirming lines must be done with a separate call; the returned column `OrderlineConfirmed` only shows the current flag.\n- The error row has different columns (`Error`, `ErrorMsg`) than the data rows, so clients must check which columns are present.\n\nDocumentation: https://pixi-api-docs.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": "Returns the direct-fulfillment (FUT) orderlines of one order for an authorized drop-shipping supplier, including item, status history and currency data.\n\nInterface call for direct-fulfillment (drop-shipping) suppliers to fetch the orderlines of a single order that they have to fulfil.\n\n**Authorization**\n\n1. Empty strings in `SupplNr` and `Secret` are treated as `NULL`.\n2. A supplier is searched in `Suppliers` whose `SupplNr` equals `SupplNr`, whose `CustNr` equals `Secret`, that is not disabled and has `CanDoDirectFulfillment = 1`.\n3. If no such supplier is found and the setting `DFAPIAllowFullAccessWithoutSecret` is `0` (or not present), a single error row with `Error = 403` is returned and nothing else.\n4. Otherwise the orderlines are returned.\n\n**Selection of orderlines**\n\n- Only lines of the order `OrderNR` with orderline status `FUT`.\n- Each line is joined to its most recent `OrderHistory` entry with status `FUT`; that status must be a fulfilment state in `OrderStates` (`FulfilmentStatus = 'Y'`).\n- By default only lines whose history entry is not yet confirmed (`ClientNotified = 'N'`) are returned; with `AllOrderlines = 1` confirmed lines are included as well.\n- If `SupplNr` is given, only lines whose `SupplInfo` equals `SupplNr` and whose supplier is a direct-fulfillment supplier are returned. If `SupplNr` is empty (only possible when full access without secret is allowed), lines of all suppliers are returned.\n- Lines are excluded if the shipping address is locked (`ASLocked = 'Y'`) or the customer is locked (`SLocked = 'Y'`).\n- Lines without a matching billing address, customer, order header or currency are not returned (inner joins).\n\n**Item data**\n\nFor each line the item is read from `Items`; the supplier-specific additional item record in `AddItems` (matching the line's supplier, newest by `UpdateDate`) provides `ItemNrSuppl` with priority, while `EANUPC` is taken from the item first and from `AddItems` only as fallback.\n\nThe result is `DISTINCT` and has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNR` | int | Yes | Pixi order number whose orderlines are returned. |\n| `SupplNr` | varchar(4) | No | Supplier number of the direct-fulfillment supplier. Used for authorization and to restrict the lines to this supplier. Empty string is treated as NULL. |\n| `Secret` | varchar(20) | No | Secret of the supplier; must match the `CustNr` stored for the supplier. Empty string is treated as NULL. |\n| `AllOrderlines` | bit | No | Controls whether already confirmed lines are included. |\n\n- All tables are read with `NOLOCK`; uncommitted data may be returned.\n- The `Secret` is compared with the supplier's `CustNr` field (the customer number Pixi has at the supplier).\n- If the setting `DFAPIAllowFullAccessWithoutSecret` is not `0`, the secret check is effectively disabled: any caller gets data, and with an empty `SupplNr` even the lines of all suppliers of the order.\n- The call is read-only: it does not set `ClientNotified`. Confirming lines must be done with a separate call; the returned column `OrderlineConfirmed` only shows the current flag.\n- The error row has different columns (`Error`, `ErrorMsg`) than the data rows, so clients must check which columns are present.\n\nDocumentation: https://pixi-api-docs.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": "Returns the order headers with shipping address data of orders that have open direct fulfillment order lines (status FUT) for a supplier.\n\nPart of the Direct Fulfillment (DF) API: a supplier retrieves the orders it has to ship directly to the customer.\n\n**Authentication**\n\n- The setting `DFAPIAllowFullAccessWithoutSecret` is read. If it is not `1`, the supplier is identified by `SupplNr` together with `Secret`, which must match the supplier's `CustNr` (the customer number at the supplier).\n- The supplier must exist, must not be disabled and must have `CanDoDirectFulfillment = 1`.\n- If the supplier cannot be identified and the setting is not `1`, a single error row with `Error = 403` is returned.\n- If the setting is `1`, the secret is not checked. A given `SupplNr` must still match an active DF supplier, otherwise an error row is returned. If `SupplNr` is left out (or `0`), orders of **all** suppliers are returned.\n\n**Order selection**\n\nAn order is returned if it has at least one order line that\n\n- has the status `FUT`,\n- is assigned to the supplier (`SupplInfo`), unless no supplier is set (full access), and\n- has `ClientNotified = 'N'` (not yet transferred), unless `AllOrders = 1`.\n\nOrders whose shipping address or customer is locked are excluded. Only orders with an existing customer, billing address, shipping address, country and currency are returned (inner joins).\n\nThe result contains one row per order, sorted by `OrderNr`. `AddrShopID` and `APayment` come from the billing address, all other address fields from the shipping address.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | No | Supplier number of the direct fulfillment supplier. Required unless the setting `DFAPIAllowFullAccessWithoutSecret` is `1`; then leaving it out returns orders of all suppliers. |\n| `Secret` | varchar(20) | No | Secret of the supplier; must equal the supplier's `CustNr`. Ignored if `DFAPIAllowFullAccessWithoutSecret` is `1`. |\n| `AllOrders` | bit | No | Controls whether already notified order lines are included. NULL is treated as 0. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- The call does not mark the orders as transferred; `ClientNotified` is not changed here. Without `AllOrders = 1` the same orders are returned again until another process updates the order lines.\n- On an authentication error the procedure returns only the error row (return code 1) and no order data.\n- If `DFAPIAllowFullAccessWithoutSecret = 1` and no `SupplNr` is given, the orders of all suppliers are exposed; this setting should be used with care.\n- The order history is joined in the line check, but the history filter is commented out and has no effect on the result.\n- A temporary table is created and dropped via `util.TempTableDrop` (definition not attached).\n\nDocumentation: https://pixi-api-docs.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": "Returns the order headers with shipping address data of orders that have open direct fulfillment order lines (status FUT) for a supplier.\n\nPart of the Direct Fulfillment (DF) API: a supplier retrieves the orders it has to ship directly to the customer.\n\n**Authentication**\n\n- The setting `DFAPIAllowFullAccessWithoutSecret` is read. If it is not `1`, the supplier is identified by `SupplNr` together with `Secret`, which must match the supplier's `CustNr` (the customer number at the supplier).\n- The supplier must exist, must not be disabled and must have `CanDoDirectFulfillment = 1`.\n- If the supplier cannot be identified and the setting is not `1`, a single error row with `Error = 403` is returned.\n- If the setting is `1`, the secret is not checked. A given `SupplNr` must still match an active DF supplier, otherwise an error row is returned. If `SupplNr` is left out (or `0`), orders of **all** suppliers are returned.\n\n**Order selection**\n\nAn order is returned if it has at least one order line that\n\n- has the status `FUT`,\n- is assigned to the supplier (`SupplInfo`), unless no supplier is set (full access), and\n- has `ClientNotified = 'N'` (not yet transferred), unless `AllOrders = 1`.\n\nOrders whose shipping address or customer is locked are excluded. Only orders with an existing customer, billing address, shipping address, country and currency are returned (inner joins).\n\nThe result contains one row per order, sorted by `OrderNr`. `AddrShopID` and `APayment` come from the billing address, all other address fields from the shipping address.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | No | Supplier number of the direct fulfillment supplier. Required unless the setting `DFAPIAllowFullAccessWithoutSecret` is `1`; then leaving it out returns orders of all suppliers. |\n| `Secret` | varchar(20) | No | Secret of the supplier; must equal the supplier's `CustNr`. Ignored if `DFAPIAllowFullAccessWithoutSecret` is `1`. |\n| `AllOrders` | bit | No | Controls whether already notified order lines are included. NULL is treated as 0. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- The call does not mark the orders as transferred; `ClientNotified` is not changed here. Without `AllOrders = 1` the same orders are returned again until another process updates the order lines.\n- On an authentication error the procedure returns only the error row (return code 1) and no order data.\n- If `DFAPIAllowFullAccessWithoutSecret = 1` and no `SupplNr` is given, the orders of all suppliers are exposed; this setting should be used with care.\n- The order history is joined in the line check, but the history filter is commented out and has no effect on the result.\n- A temporary table is created and dropped via `util.TempTableDrop` (definition not attached).\n\nDocumentation: https://pixi-api-docs.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": "Sets the direct fulfillment status of orderlines from an XML list of order history keys and can optionally create the DF invoices afterwards.\n\nUsed by direct fulfillment suppliers to report back the processing state of orderlines (shipped, cancelled, not deliverable) together with shipping date, tracking ID, external invoice number, batch, best-before date and serial number.\n\n**Steps**\n\n1. **Authentication:** looks up a supplier in `Suppliers` with `SupplNr` = `@SupplNr`, `CustNr` = `@Secret`, not disabled and `CanDoDirectFulfillment = 1`. If none is found and the setting `DFAPIAllowFullAccessWithoutSecret` is `0` or missing, the call stops with the message `403 Not Authorized…` and returns no rows.\n2. **XML parsing:** reads all `/SETDFSTATUS/ITEM` elements (element-centric) into a work table. Missing `ERROR`/`ERRORMSG` default to `200`/empty.\n3. **Duplicate check:** if the same `ORDERHISTORYKEY` appears more than once with the same `STATUS`, the call raises `500 Duplicate Orderhistorykey and Status.` and nothing is changed.\n4. **Processing per item** (inside one transaction): the orderline is found via `OrderHistory.OrderHistKey` → `OrderLineRef`, then the internal procedure `Pixi_UpdateOrderlineDFStatusByOrderlineKey` is executed. It:\n - rejects the item if the orderline does not exist, is already in status `FUS` or in a final state, if `QTY` < 1 or larger than the orderline quantity, or if batch number / best-before date are missing for items tagged with the system tags (only when setting `DFRequiredDataForSystemTags` is active);\n - splits the orderline if `QTY` is smaller than the current quantity (the reported quantity stays on the original line, the rest goes to a new line in the old status);\n - maps `STATUS`: `STO` → `STO`, `NLB` → `NLB`, any other value → `FUS` for DF type 1, 3 or empty, otherwise `BES` (then a reservation for the Auftrag is created);\n - updates the orderline with status, ship date, tracking ID, external invoice number, batch number, best-before date and serial number (`UpdateEmp` = `DF API`).\n5. The result text of each item is written to `ERRORMSG`; `ERROR` becomes `500` if the text contains `error`, otherwise `200`. Each item is also logged in `LogTable`.\n6. All items are returned as one result set and the transaction is committed.\n7. If `@CreateInvoices` = `Y`, `pipiDFCreateInvoices` is executed afterwards without parameters.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | Yes | XML document with one `ITEM` per status report under the root `SETDFSTATUS`. Elements: `ORDERHISTORYKEY`, `STATUS` (`STO` = cancel, `NLB` = not deliverable, other values = processed/shipped), `QTY`, `SHIPDATE`, `TRACKINGID`, `INVOICENREXTERNAL`, `BATCHNUMBER`, `BESTBEFOREDATE`, `SERIALNUMBER`; `ERROR`/`ERRORMSG` are read but overwritten by the result. |\n| `CreateInvoices` | varchar(1) | No | If `Y`, `pipiDFCreateInvoices` is executed after a successful run. |\n| `SupplNr` | varchar(4) | No | Supplier number of the direct fulfillment supplier, used for authentication. |\n| `Secret` | varchar(20) | No | Secret of the supplier; compared with `Suppliers.CustNr`. Can be omitted only if the setting `DFAPIAllowFullAccessWithoutSecret` is active. |\n\n- **Partial processing:** item errors do not roll back the other items. The internal error counter is never increased, so the transaction is always committed; check `ERROR` per row.\n- `@SupplNr`/`@Secret` only authenticate the caller. The code does **not** check that the orderlines belong to that supplier.\n- The 403 message is raised with severity 0, i.e. as an informational message, not as an SQL error. Clients must check for it explicitly when no rows are returned.\n- `STATUS` is read with up to 13 characters but processed as `varchar(3)`; longer values are truncated and the result row may then not be updated (keeps `ERROR` `200`).\n- Ship date, tracking ID and external invoice number are always overwritten; omitted elements set these fields to NULL. Batch number, best-before date and serial number keep their existing values when empty.\n- `BESTBEFOREDATE` is converted implicitly to a date; invalid values cause an exception.\n- If an exception occurs, the transaction is rolled back, the error is logged via `log.InsertError` and no result set is returned. Errors caught inside the internal procedure may not show up in `ERROR`.\n- If several error conditions apply to one item, only the last message set is returned.\n- `@CreateInvoices = 'Y'` runs `pipiDFCreateInvoices` for **all** DF orderlines ready for invoicing, not only the ones in this call; it runs after the commit and returns no rows. The invoice creation itself (`Pixi_CreateFulfillmentIncoices`) is not attached.\n- Reads use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Sets the direct fulfillment status of orderlines from an XML list of order history keys and can optionally create the DF invoices afterwards.\n\nUsed by direct fulfillment suppliers to report back the processing state of orderlines (shipped, cancelled, not deliverable) together with shipping date, tracking ID, external invoice number, batch, best-before date and serial number.\n\n**Steps**\n\n1. **Authentication:** looks up a supplier in `Suppliers` with `SupplNr` = `@SupplNr`, `CustNr` = `@Secret`, not disabled and `CanDoDirectFulfillment = 1`. If none is found and the setting `DFAPIAllowFullAccessWithoutSecret` is `0` or missing, the call stops with the message `403 Not Authorized…` and returns no rows.\n2. **XML parsing:** reads all `/SETDFSTATUS/ITEM` elements (element-centric) into a work table. Missing `ERROR`/`ERRORMSG` default to `200`/empty.\n3. **Duplicate check:** if the same `ORDERHISTORYKEY` appears more than once with the same `STATUS`, the call raises `500 Duplicate Orderhistorykey and Status.` and nothing is changed.\n4. **Processing per item** (inside one transaction): the orderline is found via `OrderHistory.OrderHistKey` → `OrderLineRef`, then the internal procedure `Pixi_UpdateOrderlineDFStatusByOrderlineKey` is executed. It:\n - rejects the item if the orderline does not exist, is already in status `FUS` or in a final state, if `QTY` < 1 or larger than the orderline quantity, or if batch number / best-before date are missing for items tagged with the system tags (only when setting `DFRequiredDataForSystemTags` is active);\n - splits the orderline if `QTY` is smaller than the current quantity (the reported quantity stays on the original line, the rest goes to a new line in the old status);\n - maps `STATUS`: `STO` → `STO`, `NLB` → `NLB`, any other value → `FUS` for DF type 1, 3 or empty, otherwise `BES` (then a reservation for the Auftrag is created);\n - updates the orderline with status, ship date, tracking ID, external invoice number, batch number, best-before date and serial number (`UpdateEmp` = `DF API`).\n5. The result text of each item is written to `ERRORMSG`; `ERROR` becomes `500` if the text contains `error`, otherwise `200`. Each item is also logged in `LogTable`.\n6. All items are returned as one result set and the transaction is committed.\n7. If `@CreateInvoices` = `Y`, `pipiDFCreateInvoices` is executed afterwards without parameters.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | Yes | XML document with one `ITEM` per status report under the root `SETDFSTATUS`. Elements: `ORDERHISTORYKEY`, `STATUS` (`STO` = cancel, `NLB` = not deliverable, other values = processed/shipped), `QTY`, `SHIPDATE`, `TRACKINGID`, `INVOICENREXTERNAL`, `BATCHNUMBER`, `BESTBEFOREDATE`, `SERIALNUMBER`; `ERROR`/`ERRORMSG` are read but overwritten by the result. |\n| `CreateInvoices` | varchar(1) | No | If `Y`, `pipiDFCreateInvoices` is executed after a successful run. |\n| `SupplNr` | varchar(4) | No | Supplier number of the direct fulfillment supplier, used for authentication. |\n| `Secret` | varchar(20) | No | Secret of the supplier; compared with `Suppliers.CustNr`. Can be omitted only if the setting `DFAPIAllowFullAccessWithoutSecret` is active. |\n\n- **Partial processing:** item errors do not roll back the other items. The internal error counter is never increased, so the transaction is always committed; check `ERROR` per row.\n- `@SupplNr`/`@Secret` only authenticate the caller. The code does **not** check that the orderlines belong to that supplier.\n- The 403 message is raised with severity 0, i.e. as an informational message, not as an SQL error. Clients must check for it explicitly when no rows are returned.\n- `STATUS` is read with up to 13 characters but processed as `varchar(3)`; longer values are truncated and the result row may then not be updated (keeps `ERROR` `200`).\n- Ship date, tracking ID and external invoice number are always overwritten; omitted elements set these fields to NULL. Batch number, best-before date and serial number keep their existing values when empty.\n- `BESTBEFOREDATE` is converted implicitly to a date; invalid values cause an exception.\n- If an exception occurs, the transaction is rolled back, the error is logged via `log.InsertError` and no result set is returned. Errors caught inside the internal procedure may not show up in `ERROR`.\n- If several error conditions apply to one item, only the last message set is returned.\n- `@CreateInvoices = 'Y'` runs `pipiDFCreateInvoices` for **all** DF orderlines ready for invoicing, not only the ones in this call; it runs after the commit and returns no rows. The invoice creation itself (`Pixi_CreateFulfillmentIncoices`) is not attached.\n- Reads use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Sets or clears the notified flag (`ClientNotified`) on the latest `FUT` history entry of the order lines of a direct-fulfillment order or of a single order line.\n\nMarks order lines as notified (or not notified) to the supplier in a direct-fulfillment (drop-shipping) process.\n\n1. Candidate order lines are selected from `Orderlines` where `OrderlineKey = @OrderlineKey` **or** `OrderNr = @OrderNr`. Lines with status `HAL` are excluded.\n2. Each candidate is checked for editability: a line is editable only if it has **no** entry in `OrderHistory` whose status is outside `HAL`, `ANG`, `BES`, `FUT`, `NEW`. Lines that already have any other history status are skipped.\n3. For every editable line, the `OrderHistory` entry with the highest `OrderHistKey` among its entries with status `FUT` is updated: `ClientNotified` is set to `Y` if `@IsNotified = 1`, otherwise to `N`.\n\nLines without a `FUT` history entry are not changed. The call returns no result set and no status row.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Key of a single order line to process. Combined with `OrderNr` via OR. |\n| `OrderNr` | int | No | Order number; all order lines of this order (except status `HAL`) are processed. Combined with `OrderlineKey` via OR. |\n| `IsNotified` | bit | No | Value of the notified flag to set. |\n\n- The two filter parameters are combined with `OR`: if both are passed, lines matching either the order line key or the order number are processed. If neither is passed, nothing is updated.\n- The check `IF @IsNotified = NULL` never evaluates to true under standard `ANSI_NULLS` settings. Passing `IsNotified` explicitly as NULL therefore does **not** fall back to 1; the flag is set to `N`. Omit the parameter to get the default 1.\n- Despite the call name, the column written is `OrderHistory.ClientNotified`.\n- No feedback is given about how many rows were updated (`SET NOCOUNT ON`, no result set); the caller cannot tell whether a line was skipped as not editable.\n- Candidate selection reads with `NOLOCK`; the update uses `ROWLOCK`. No explicit transaction.\n\nDocumentation: https://pixi-api-docs.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": "Sets the direct-fulfillment status of an orderline for an authenticated supplier, optionally with ship date, tracking ID, invoice number, partial quantity and batch data.\n\nAPI call for direct-fulfillment suppliers to report the processing state of an orderline back to Pixi.\n\n**1. Authentication**\n- The supplier is looked up in `Suppliers` by `SupplNr`; `Secret` must match the supplier's `CustNr`, the supplier must not be disabled and must have `CanDoDirectFulfillment = 1`.\n- If no supplier matches and the setting `DFAPIAllowFullAccessWithoutSecret` is `0` (or missing), a single row with `Error = '403'` is returned and nothing is changed.\n- If that setting is not `0`, the call continues even with a wrong secret.\n\n**2. Finding the orderline**\n- If `OrderlineRef` is less than 1 (default), the orderline key is read from `OrderHistory` using `OrderHistoryKey`.\n- Empty strings in `BatchNumber`, `BestBeforeDate` and `SerialNumber` are treated as NULL.\n\n**3. Validation** (done by the internal procedure `Pixi_UpdateOrderlineDFStatusByOrderlineKey`). The update is rejected if:\n- the orderline does not exist;\n- the setting `DFRequiredDataForSystemTags` is active and the item carries the system tag for batch number (tag `-6`) and/or best-before date (tag `-7`) but the corresponding value is not sent;\n- `Qty` is less than 1 or greater than the current orderline quantity;\n- the orderline already has status `FUS` or a status marked as final in `OrderStates`.\n\n**4. Update**\n- If `Qty` is smaller than the current quantity, the orderline is split first: the original line keeps `Qty`, a new line with the remaining quantity is created with the old status.\n- The new status is derived from `Status`: `STO` and `NLB` are taken over as they are; any other value results in `FUS` for DF type 1, 3 or no DF type, otherwise `BES`.\n- The orderline gets the new status, `DFShipDate`, `DFShipmentTrackingID` (from `DFTrackingID`), `InvoiceNrExternal`, batch number, best-before date, serial number, `UpdateDate` and `UpdateEmp = 'DF API'`.\n- If the resulting status is `BES`, a reservation is created for the whole order.\n\n**5. Response**\nOne row with `Error` (`200` or `500`) and `ErrorMsg`. `500` is returned if the message contains the word `error`. On success `ErrorMsg` is empty or contains the split info. Each call that passes authentication writes a line to `LogTable`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Yes | Supplier number of the direct-fulfillment supplier. |\n| `Secret` | varchar(20) | Yes | Secret of the supplier; must match the `CustNr` stored for the supplier. |\n| `Status` | varchar(3) | Yes | Requested status. `STO` and `NLB` are set as they are; any other value sets `FUS` (DF type 1, 3 or none) or `BES` (other DF types). |\n| `OrderHistoryKey` | int | No | Key of the `OrderHistory` entry; used to find the orderline when `OrderlineRef` is not given. |\n| `DFShipDate` | datetime | No | Ship date reported by the supplier; stored in `DFShipDate` (overwritten with NULL if omitted). |\n| `DFTrackingID` | varchar(100) | No | Shipment tracking ID; stored in `DFShipmentTrackingID` (overwritten with NULL if omitted). |\n| `Qty` | int | No | Processed quantity. Must be between 1 and the current orderline quantity; a smaller value splits the orderline. NULL keeps the full quantity. |\n| `InvoiceNrExternal` | varchar(20) | No | Invoice number of the supplier; stored in `InvoiceNrExternal` (overwritten with NULL if omitted). |\n| `OrderlineRef` | int | No | Key of the orderline (`OrderlineKey`). If less than 1, the key is taken from `OrderHistoryKey`. |\n| `BatchNumber` | varchar(50) | No | Batch number (Charge). Required if the item has the batch system tag and `DFRequiredDataForSystemTags` is active; if omitted, the existing value is kept. |\n| `BestBeforeDate` | datetime | No | Best-before date. Required if the item has the best-before system tag and `DFRequiredDataForSystemTags` is active; if omitted, the existing value is kept. |\n| `SerialNumber` | varchar(50) | No | Serial number; stored in `SerialNr`. If omitted, the existing value is kept. |\n\n- The call does **not** check that the orderline belongs to the authenticated supplier; any orderline key can be addressed.\n- `DFShipDate`, `DFTrackingID` and `InvoiceNrExternal` are always written; omitting them overwrites existing values with NULL. `BatchNumber`, `BestBeforeDate` and `SerialNumber` keep their existing values when not sent.\n- Validation messages overwrite each other; only the last failing check is reported.\n- The detection of errors relies on `CHARINDEX('error', ErrorMsg)`; this works for the upper-case `ERROR:` messages only with a case-insensitive database collation.\n- Runtime exceptions inside the update are caught, rolled back and logged via `log.InsertError`, but they do not change `ErrorMsg`; the response can therefore be `200` with an empty or INFO message although nothing was saved. Check the orderline afterwards if in doubt.\n- The check for a failed reservation (`ERROR: Error Creating Reservation`) reads `@@ERROR` after a `SET` statement and is therefore practically never triggered.\n- The work runs in its own transaction or savepoint if called inside an existing transaction. Lookups use `NOLOCK`.\n- The behaviour of `GOSBreakOrderline`, `Pixi_Res_CreateReservationForOrder`, `dbo.SettingGet` and `log.InsertError` is not visible here; further tables may be written by them.\n- A best-before date of `1900-01-01` is treated like an empty value because of the comparison with `''`.\n\nDocumentation: https://pixi-api-docs.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": "Sets the direct-fulfillment status of an orderline for an authenticated supplier, optionally with ship date, tracking ID, invoice number, partial quantity and batch data.\n\nAPI call for direct-fulfillment suppliers to report the processing state of an orderline back to Pixi.\n\n**1. Authentication**\n- The supplier is looked up in `Suppliers` by `SupplNr`; `Secret` must match the supplier's `CustNr`, the supplier must not be disabled and must have `CanDoDirectFulfillment = 1`.\n- If no supplier matches and the setting `DFAPIAllowFullAccessWithoutSecret` is `0` (or missing), a single row with `Error = '403'` is returned and nothing is changed.\n- If that setting is not `0`, the call continues even with a wrong secret.\n\n**2. Finding the orderline**\n- If `OrderlineRef` is less than 1 (default), the orderline key is read from `OrderHistory` using `OrderHistoryKey`.\n- Empty strings in `BatchNumber`, `BestBeforeDate` and `SerialNumber` are treated as NULL.\n\n**3. Validation** (done by the internal procedure `Pixi_UpdateOrderlineDFStatusByOrderlineKey`). The update is rejected if:\n- the orderline does not exist;\n- the setting `DFRequiredDataForSystemTags` is active and the item carries the system tag for batch number (tag `-6`) and/or best-before date (tag `-7`) but the corresponding value is not sent;\n- `Qty` is less than 1 or greater than the current orderline quantity;\n- the orderline already has status `FUS` or a status marked as final in `OrderStates`.\n\n**4. Update**\n- If `Qty` is smaller than the current quantity, the orderline is split first: the original line keeps `Qty`, a new line with the remaining quantity is created with the old status.\n- The new status is derived from `Status`: `STO` and `NLB` are taken over as they are; any other value results in `FUS` for DF type 1, 3 or no DF type, otherwise `BES`.\n- The orderline gets the new status, `DFShipDate`, `DFShipmentTrackingID` (from `DFTrackingID`), `InvoiceNrExternal`, batch number, best-before date, serial number, `UpdateDate` and `UpdateEmp = 'DF API'`.\n- If the resulting status is `BES`, a reservation is created for the whole order.\n\n**5. Response**\nOne row with `Error` (`200` or `500`) and `ErrorMsg`. `500` is returned if the message contains the word `error`. On success `ErrorMsg` is empty or contains the split info. Each call that passes authentication writes a line to `LogTable`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Yes | Supplier number of the direct-fulfillment supplier. |\n| `Secret` | varchar(20) | Yes | Secret of the supplier; must match the `CustNr` stored for the supplier. |\n| `Status` | varchar(3) | Yes | Requested status. `STO` and `NLB` are set as they are; any other value sets `FUS` (DF type 1, 3 or none) or `BES` (other DF types). |\n| `OrderHistoryKey` | int | No | Key of the `OrderHistory` entry; used to find the orderline when `OrderlineRef` is not given. |\n| `DFShipDate` | datetime | No | Ship date reported by the supplier; stored in `DFShipDate` (overwritten with NULL if omitted). |\n| `DFTrackingID` | varchar(100) | No | Shipment tracking ID; stored in `DFShipmentTrackingID` (overwritten with NULL if omitted). |\n| `Qty` | int | No | Processed quantity. Must be between 1 and the current orderline quantity; a smaller value splits the orderline. NULL keeps the full quantity. |\n| `InvoiceNrExternal` | varchar(20) | No | Invoice number of the supplier; stored in `InvoiceNrExternal` (overwritten with NULL if omitted). |\n| `OrderlineRef` | int | No | Key of the orderline (`OrderlineKey`). If less than 1, the key is taken from `OrderHistoryKey`. |\n| `BatchNumber` | varchar(50) | No | Batch number (Charge). Required if the item has the batch system tag and `DFRequiredDataForSystemTags` is active; if omitted, the existing value is kept. |\n| `BestBeforeDate` | datetime | No | Best-before date. Required if the item has the best-before system tag and `DFRequiredDataForSystemTags` is active; if omitted, the existing value is kept. |\n| `SerialNumber` | varchar(50) | No | Serial number; stored in `SerialNr`. If omitted, the existing value is kept. |\n\n- The call does **not** check that the orderline belongs to the authenticated supplier; any orderline key can be addressed.\n- `DFShipDate`, `DFTrackingID` and `InvoiceNrExternal` are always written; omitting them overwrites existing values with NULL. `BatchNumber`, `BestBeforeDate` and `SerialNumber` keep their existing values when not sent.\n- Validation messages overwrite each other; only the last failing check is reported.\n- The detection of errors relies on `CHARINDEX('error', ErrorMsg)`; this works for the upper-case `ERROR:` messages only with a case-insensitive database collation.\n- Runtime exceptions inside the update are caught, rolled back and logged via `log.InsertError`, but they do not change `ErrorMsg`; the response can therefore be `200` with an empty or INFO message although nothing was saved. Check the orderline afterwards if in doubt.\n- The check for a failed reservation (`ERROR: Error Creating Reservation`) reads `@@ERROR` after a `SET` statement and is therefore practically never triggered.\n- The work runs in its own transaction or savepoint if called inside an existing transaction. Lookups use `NOLOCK`.\n- The behaviour of `GOSBreakOrderline`, `Pixi_Res_CreateReservationForOrder`, `dbo.SettingGet` and `log.InsertError` is not visible here; further tables may be written by them.\n- A best-before date of `1900-01-01` is treated like an empty value because of the comparison with `''`.\n\nDocumentation: https://pixi-api-docs.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": "Sets the direct fulfillment type (DF_type) of one orderline or of all orderlines of an order and resets editable lines to status ANG.\n\nAssigns a direct fulfillment type to orderlines and returns the result per orderline.\n\n1. If `DF_Type` is `0`, it is treated as `NULL`, i.e. the fulfillment type is removed.\n2. The orderlines to process are collected:\n - `OrderlineKey` > 0: this single orderline is added (without checking its status or whether it exists).\n - `OrderNr` > 0: all orderlines of this order whose `Status` is not `HAL` (on hold) are added.\n - Both parameters can be combined; if neither is > 0, nothing is processed and an empty result set is returned.\n3. Each collected orderline is checked for editability. An orderline is **not editable** (`IsEditable` = 0) if\n - the order history (`OrderHistory`) contains an entry for it with a status other than `HAL`, `ANG`, `BES`, `FUT`, `NEW`, or a `FUT` entry with `ClientNotified` = `Y`, or\n - it is on a picklist (`PLitem`/`PLHeader`) whose expiry date `PLHexpiryDate` is in the future.\n Otherwise it is editable (`IsEditable` = 1).\n4. For all editable orderlines `DF_type` is set to the given value and `Status` is set to `ANG`.\n5. One row per collected orderline is returned with the current order number, key, status, DF type and the editability flag.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Key of a single orderline to update. Ignored if NULL or <= 0. |\n| `OrderNr` | int | No | Order number; all orderlines of this order that are not on hold (`HAL`) are processed. Ignored if NULL or <= 0. |\n| `DF_Type` | int | No | Direct fulfillment type to set on the orderlines. `0` or NULL removes the type (sets `DF_type` to NULL). |\n\n- The update runs in its own transaction, or as a savepoint if the caller already has an open transaction.\n- The status of every editable orderline is set to `ANG`, regardless of its previous status. An orderline passed directly via `OrderlineKey` is not filtered for `HAL`, so an orderline on hold can be released to `ANG` this way.\n- If the same orderline is passed via `OrderlineKey` and belongs to `OrderNr`, it appears twice in the result.\n- If `OrderlineKey` does not exist, a row with `NULL` in all orderline columns and `IsEditable` = 1 is returned.\n- Lookups on `Orderlines`, `OrderHistory`, `PLitem` and `PLHeader` use `NOLOCK`; the result set is also read with `NOLOCK`.\n- On an error the transaction is rolled back, the error is logged via `log.InsertError` (definition not attached) and an error row is returned instead of the result rows.\n\nDocumentation: https://pixi-api-docs.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": "Sets the direct fulfillment type (DF_type) of one orderline or of all orderlines of an order and resets editable lines to status ANG.\n\nAssigns a direct fulfillment type to orderlines and returns the result per orderline.\n\n1. If `DF_Type` is `0`, it is treated as `NULL`, i.e. the fulfillment type is removed.\n2. The orderlines to process are collected:\n - `OrderlineKey` > 0: this single orderline is added (without checking its status or whether it exists).\n - `OrderNr` > 0: all orderlines of this order whose `Status` is not `HAL` (on hold) are added.\n - Both parameters can be combined; if neither is > 0, nothing is processed and an empty result set is returned.\n3. Each collected orderline is checked for editability. An orderline is **not editable** (`IsEditable` = 0) if\n - the order history (`OrderHistory`) contains an entry for it with a status other than `HAL`, `ANG`, `BES`, `FUT`, `NEW`, or a `FUT` entry with `ClientNotified` = `Y`, or\n - it is on a picklist (`PLitem`/`PLHeader`) whose expiry date `PLHexpiryDate` is in the future.\n Otherwise it is editable (`IsEditable` = 1).\n4. For all editable orderlines `DF_type` is set to the given value and `Status` is set to `ANG`.\n5. One row per collected orderline is returned with the current order number, key, status, DF type and the editability flag.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Key of a single orderline to update. Ignored if NULL or <= 0. |\n| `OrderNr` | int | No | Order number; all orderlines of this order that are not on hold (`HAL`) are processed. Ignored if NULL or <= 0. |\n| `DF_Type` | int | No | Direct fulfillment type to set on the orderlines. `0` or NULL removes the type (sets `DF_type` to NULL). |\n\n- The update runs in its own transaction, or as a savepoint if the caller already has an open transaction.\n- The status of every editable orderline is set to `ANG`, regardless of its previous status. An orderline passed directly via `OrderlineKey` is not filtered for `HAL`, so an orderline on hold can be released to `ANG` this way.\n- If the same orderline is passed via `OrderlineKey` and belongs to `OrderNr`, it appears twice in the result.\n- If `OrderlineKey` does not exist, a row with `NULL` in all orderline columns and `IsEditable` = 1 is returned.\n- Lookups on `Orderlines`, `OrderHistory`, `PLitem` and `PLHeader` use `NOLOCK`; the result set is also read with `NOLOCK`.\n- On an error the transaction is rolled back, the error is logged via `log.InsertError` (definition not attached) and an error row is returned instead of the result rows.\n\nDocumentation: https://pixi-api-docs.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": "Returns the users logged in to licence-relevant Pixi clients at a given snapshot time, or at the latest snapshot if no date is passed.\n\nLists the currently logged-in users (CUL) as recorded in the login snapshot table `UsersLoggedIn`.\n\n1. If `Date` is not passed, the call uses the most recent snapshot time (`MAX(Tag)`) of all sessions with session type 1 or 2.\n2. Only rows whose `Tag` equals that date **exactly** are taken, and only sessions of type 1 or 2.\n3. Only applications that need a licence are included. An application counts if it is listed in `ExeClientVersion` with `LicenceNeeded = 1` and either:\n - the setting `pixiLicencesManager` is `1` and the client's session type reference is `1` (desktop), or\n - the setting `pixiLicencesManagerWeb` is `1` and the client's session type reference is `2` (web).\n Missing settings are treated as `0`.\n4. Master users are excluded: rows whose `UserName` is a `ComputerName` in `MasterUsers`, and rows whose `UserNameUsingPixi` is `master`.\n5. Known executables are given a sortable display name (for example `PPOS2.exe` becomes `1_POS`, `supplorders_a.exe` becomes `2_SupplOrders`, through to `ControlCenter.exe` as `9_ControlCenter`). Other application names stay as they are.\n\nThe result is sorted by `UserName`, `UserNameUsingPixi` and the mapped `AppName`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Date` | datetime | No | Snapshot time (`Tag` in `UsersLoggedIn`) to evaluate. Must match exactly. If omitted, the latest snapshot of session types 1 and 2 is used. |\n\n- All reads use `NOLOCK`, so the result may contain uncommitted data.\n- If both licence manager settings are `0` or missing, no application qualifies and the result is always empty.\n- `Date` must match a snapshot `Tag` exactly (including time); a date without the snapshot's exact time returns no rows. Passing `1900-01-01` behaves like passing no date, because the code compares `ISNULL(@Date, '')` with an empty string.\n- `AppName_clean` simply removes the first two characters of `AppName`. For mapped applications this strips the numeric prefix (`1_POS` → `POS`); for unmapped applications it cuts off the first two characters of the original executable name.\n- Full mapping: `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\nDocumentation: https://pixi-api-docs.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": "Returns the users logged in to licence-relevant Pixi clients at a given snapshot time, or at the latest snapshot if no date is passed.\n\nLists the currently logged-in users (CUL) as recorded in the login snapshot table `UsersLoggedIn`.\n\n1. If `Date` is not passed, the call uses the most recent snapshot time (`MAX(Tag)`) of all sessions with session type 1 or 2.\n2. Only rows whose `Tag` equals that date **exactly** are taken, and only sessions of type 1 or 2.\n3. Only applications that need a licence are included. An application counts if it is listed in `ExeClientVersion` with `LicenceNeeded = 1` and either:\n - the setting `pixiLicencesManager` is `1` and the client's session type reference is `1` (desktop), or\n - the setting `pixiLicencesManagerWeb` is `1` and the client's session type reference is `2` (web).\n Missing settings are treated as `0`.\n4. Master users are excluded: rows whose `UserName` is a `ComputerName` in `MasterUsers`, and rows whose `UserNameUsingPixi` is `master`.\n5. Known executables are given a sortable display name (for example `PPOS2.exe` becomes `1_POS`, `supplorders_a.exe` becomes `2_SupplOrders`, through to `ControlCenter.exe` as `9_ControlCenter`). Other application names stay as they are.\n\nThe result is sorted by `UserName`, `UserNameUsingPixi` and the mapped `AppName`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Date` | datetime | No | Snapshot time (`Tag` in `UsersLoggedIn`) to evaluate. Must match exactly. If omitted, the latest snapshot of session types 1 and 2 is used. |\n\n- All reads use `NOLOCK`, so the result may contain uncommitted data.\n- If both licence manager settings are `0` or missing, no application qualifies and the result is always empty.\n- `Date` must match a snapshot `Tag` exactly (including time); a date without the snapshot's exact time returns no rows. Passing `1900-01-01` behaves like passing no date, because the code compares `ISNULL(@Date, '')` with an empty string.\n- `AppName_clean` simply removes the first two characters of `AppName`. For mapped applications this strips the numeric prefix (`1_POS` → `POS`); for unmapped applications it cuts off the first two characters of the original executable name.\n- Full mapping: `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\nDocumentation: https://pixi-api-docs.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": "Checks a Pixi user name and password, optionally a permission code, and returns whether the login is valid together with the user's e-mail and real name.\n\nValidates the credentials of a Pixi user (table `UCS_USERS`).\n\n1. The password is passed through `dbo.PixiEncrypt`. The stored password `USER_PWD` is compared with this encrypted value.\n2. The user is looked up by `UserName`. If the user's `USER_PWD` is `NULL`, the procedure uses *version 2* password validation and calls `pixi.UserPassword_ValidateV2` with user name and plain password. If that procedure reports success, the password check counts as passed.\n3. `ValidUser` is `1` only if a user with the given `UserName` exists and all of these conditions are met:\n - the password matches, either by the classic comparison or by the V2 validation;\n - if `CheckPermission` is set, the user has a role (`USER_HAS_ROLES` → `USER_ROLES` → `ROLE_HAS_PERMISSIONS`) that grants a permission whose `Permission_Code` equals `CheckPermission`. An empty string counts as \"no permission check\";\n - the account has not expired: `User_expire` is not `1`, or it is `1` and `Expiration_date` is later than the current time;\n - `User_active = 1`.\n Otherwise `ValidUser` is `0`.\n4. If the login is valid, the output parameters `UserEmail` and `UserRealName` are filled from `User_Email` and `REAL_NAME`. `NULL` values become empty strings.\n5. Unless `SuppressDataset = 1`, the procedure returns one row with `ValidUser`, `UserName`, `UserEmail` and `UserRealName`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `UserName` | varchar(1024) | Yes | Pixi user name (`UCS_USERS.USER_NAME`). |\n| `Password` | varchar(1024) | Yes | Plain-text password of the user. |\n| `CheckPermission` | varchar(5) | No | Optional permission code (`User_Permissions.Permission_Code`) that the user must have through one of the roles. `NULL` or an empty string skips the permission check. |\n| `ValidUser` | bit | No | Output: `1` if the login is valid, otherwise `0`. |\n| `SuppressDataset` | bit | No | If `1`, no result set is returned and only the output parameters are set. `NULL` is treated as `0`. |\n| `UserEmail` | varchar(100) | No | Output: the user's e-mail address, set only if the login is valid. An empty string if none is stored. |\n| `UserRealName` | varchar(40) | No | Output: the user's real name, set only if the login is valid. An empty string if none is stored. |\n\n- The returned row contains `UserEmail` and `UserRealName` whenever the user name exists, **even if `ValidUser` is 0**, for example after a wrong password. If the user does not exist, both columns are `NULL`. The output parameters `UserEmail`/`UserRealName`, by contrast, are set only on a valid login.\n- `dbo.PixiEncrypt` is only a simple XOR obfuscation, not a cryptographic hash. Send the password only over the encrypted connection.\n- `pixi.UserPassword_ValidateV2` is not attached. Its exact logic and any side effects, such as logging or lockout, are unknown.\n- If `User_expire` is `NULL`, the expiry condition does not evaluate to true, so such users are rejected.\n- The comparison of the user name depends on the database collation. The initial V2 lookup uses `COLLATE DATABASE_DEFAULT`, the validity check does not.\n- All reads in the validity check use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Checks a Pixi user name and password, optionally a permission code, and returns whether the login is valid together with the user's e-mail and real name.\n\nValidates the credentials of a Pixi user (table `UCS_USERS`).\n\n1. The password is passed through `dbo.PixiEncrypt`. The stored password `USER_PWD` is compared with this encrypted value.\n2. The user is looked up by `UserName`. If the user's `USER_PWD` is `NULL`, the procedure uses *version 2* password validation and calls `pixi.UserPassword_ValidateV2` with user name and plain password. If that procedure reports success, the password check counts as passed.\n3. `ValidUser` is `1` only if a user with the given `UserName` exists and all of these conditions are met:\n - the password matches, either by the classic comparison or by the V2 validation;\n - if `CheckPermission` is set, the user has a role (`USER_HAS_ROLES` → `USER_ROLES` → `ROLE_HAS_PERMISSIONS`) that grants a permission whose `Permission_Code` equals `CheckPermission`. An empty string counts as \"no permission check\";\n - the account has not expired: `User_expire` is not `1`, or it is `1` and `Expiration_date` is later than the current time;\n - `User_active = 1`.\n Otherwise `ValidUser` is `0`.\n4. If the login is valid, the output parameters `UserEmail` and `UserRealName` are filled from `User_Email` and `REAL_NAME`. `NULL` values become empty strings.\n5. Unless `SuppressDataset = 1`, the procedure returns one row with `ValidUser`, `UserName`, `UserEmail` and `UserRealName`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `UserName` | varchar(1024) | Yes | Pixi user name (`UCS_USERS.USER_NAME`). |\n| `Password` | varchar(1024) | Yes | Plain-text password of the user. |\n| `CheckPermission` | varchar(5) | No | Optional permission code (`User_Permissions.Permission_Code`) that the user must have through one of the roles. `NULL` or an empty string skips the permission check. |\n| `ValidUser` | bit | No | Output: `1` if the login is valid, otherwise `0`. |\n| `SuppressDataset` | bit | No | If `1`, no result set is returned and only the output parameters are set. `NULL` is treated as `0`. |\n| `UserEmail` | varchar(100) | No | Output: the user's e-mail address, set only if the login is valid. An empty string if none is stored. |\n| `UserRealName` | varchar(40) | No | Output: the user's real name, set only if the login is valid. An empty string if none is stored. |\n\n- The returned row contains `UserEmail` and `UserRealName` whenever the user name exists, **even if `ValidUser` is 0**, for example after a wrong password. If the user does not exist, both columns are `NULL`. The output parameters `UserEmail`/`UserRealName`, by contrast, are set only on a valid login.\n- `dbo.PixiEncrypt` is only a simple XOR obfuscation, not a cryptographic hash. Send the password only over the encrypted connection.\n- `pixi.UserPassword_ValidateV2` is not attached. Its exact logic and any side effects, such as logging or lockout, are unknown.\n- If `User_expire` is `NULL`, the expiry condition does not evaluate to true, so such users are rejected.\n- The comparison of the user name depends on the database collation. The initial V2 lookup uses `COLLATE DATABASE_DEFAULT`, the validity check does not.\n- All reads in the validity check use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the latest version and the minimum allowed version of one or all Pixi client applications.\n\nReads the version information of Pixi client applications from the table `ExeClientVersion`.\n\n- If `Client` is omitted, `NULL` or an empty string, one row per client stored in the table is returned.\n- If `Client` is given, only the row whose `ClientName` equals the given value is returned. If no client with that name exists, the result set is empty.\n\nNo sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Client` | varchar(64) | No | Name of the client application. Empty string or `NULL` returns all clients. |\n\nThe table is read with `NOLOCK`, so uncommitted changes may be visible. The comparison on `ClientName` follows the collation of the database (usually case-insensitive). The column types are not visible in the code; the values are presumably version strings.\n\nDocumentation: https://pixi-api-docs.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": "Returns the latest version and the minimum allowed version of one or all Pixi client applications.\n\nReads the version information of Pixi client applications from the table `ExeClientVersion`.\n\n- If `Client` is omitted, `NULL` or an empty string, one row per client stored in the table is returned.\n- If `Client` is given, only the row whose `ClientName` equals the given value is returned. If no client with that name exists, the result set is empty.\n\nNo sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Client` | varchar(64) | No | Name of the client application. Empty string or `NULL` returns all clients. |\n\nThe table is read with `NOLOCK`, so uncommitted changes may be visible. The comparison on `ClientName` follows the collation of the database (usually case-insensitive). The column types are not visible in the code; the values are presumably version strings.\n\nDocumentation: https://pixi-api-docs.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": "Returns one country or all countries from the Pixi country master data, optionally only countries that are used in addresses.\n\nReads the country master data from the `Countries` table.\n\n- If `CntCode` is set, only the country with this code is returned.\n- If `CntCode` is empty or `NULL`, all countries are returned. An empty string is treated like `NULL`.\n- If `OnlyActive` = `1` and no `CntCode` is given, the list is limited to countries whose code appears in the `Country` column of at least one record in `Addresses`.\n- If `OnlyActive` = `1` and a `CntCode` is given, the country is returned whether or not it is used in an address.\n\nThe result is sorted by `CntName`. Each row contains the internal country code, the name, the default shipping cost, the date format, the language code, the ISO-2 and ISO-3 codes, VAT settings and the EU flag.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CntCode` | varchar(3) | No | Internal Pixi country code of the country to return. If empty or `NULL`, all countries are returned. |\n| `OnlyActive` | bit | No | If `1` and no `CntCode` is given, only countries used in at least one address are returned. |\n\n- \"Active\" in `OnlyActive` does not refer to an active flag in the country data. It only means that the country is used in at least one address in `Addresses`.\n- The ISO-3 column is returned with the alias `CntCodeIsO3` (lowercase `s`). XML element names are case-sensitive, so clients must read exactly this name.\n- Both tables are read with `NOLOCK`. The result can contain uncommitted data.\n- The column types are not visible in the code. The SQL types are therefore given as `unknown`.\n\nDocumentation: https://pixi-api-docs.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": "Returns one country or all countries from the Pixi country master data, optionally only countries that are used in addresses.\n\nReads the country master data from the `Countries` table.\n\n- If `CntCode` is set, only the country with this code is returned.\n- If `CntCode` is empty or `NULL`, all countries are returned. An empty string is treated like `NULL`.\n- If `OnlyActive` = `1` and no `CntCode` is given, the list is limited to countries whose code appears in the `Country` column of at least one record in `Addresses`.\n- If `OnlyActive` = `1` and a `CntCode` is given, the country is returned whether or not it is used in an address.\n\nThe result is sorted by `CntName`. Each row contains the internal country code, the name, the default shipping cost, the date format, the language code, the ISO-2 and ISO-3 codes, VAT settings and the EU flag.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CntCode` | varchar(3) | No | Internal Pixi country code of the country to return. If empty or `NULL`, all countries are returned. |\n| `OnlyActive` | bit | No | If `1` and no `CntCode` is given, only countries used in at least one address are returned. |\n\n- \"Active\" in `OnlyActive` does not refer to an active flag in the country data. It only means that the country is used in at least one address in `Addresses`.\n- The ISO-3 column is returned with the alias `CntCodeIsO3` (lowercase `s`). XML element names are case-sensitive, so clients must read exactly this name.\n- Both tables are read with `NOLOCK`. The result can contain uncommitted data.\n- The column types are not visible in the code. The SQL types are therefore given as `unknown`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the parent currencies from the Pixi currency code table, optionally filtered by ISO code or currency ID.\n\nReads the currency code table `pixi.Currency` and returns only entries marked as parent currency (`ParentCurrency = 1`).\n\n- Without parameters, all parent currencies are returned.\n- `CurrencyCode` filters by the alphabetic ISO code (`CodeA`), e.g. `EUR`.\n- `CurrencyId` filters by the internal currency ID.\n- Both filters can be combined; a row must then match both.\n- `NULL` values are treated like the defaults (empty string or `0`), i.e. the filter is not applied.\n\nInactive currencies are included as well; the `Active` column shows their state. No explicit sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CurrencyCode` | varchar(3) | No | Alphabetic ISO currency code (`CodeA`) to filter by. Empty string or NULL returns all parent currencies. |\n| `CurrencyId` | smallint | No | Internal currency ID to filter by. `0` or NULL disables this filter. |\n\n- The table is read with `NOLOCK`, so uncommitted changes may be visible.\n- Currencies that are not parent currencies (`ParentCurrency` other than 1) are never returned, even when their code or ID is passed explicitly; the result is then empty.\n- The row order is not guaranteed because the query has no `ORDER BY`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the parent currencies from the Pixi currency code table, optionally filtered by ISO code or currency ID.\n\nReads the currency code table `pixi.Currency` and returns only entries marked as parent currency (`ParentCurrency = 1`).\n\n- Without parameters, all parent currencies are returned.\n- `CurrencyCode` filters by the alphabetic ISO code (`CodeA`), e.g. `EUR`.\n- `CurrencyId` filters by the internal currency ID.\n- Both filters can be combined; a row must then match both.\n- `NULL` values are treated like the defaults (empty string or `0`), i.e. the filter is not applied.\n\nInactive currencies are included as well; the `Active` column shows their state. No explicit sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CurrencyCode` | varchar(3) | No | Alphabetic ISO currency code (`CodeA`) to filter by. Empty string or NULL returns all parent currencies. |\n| `CurrencyId` | smallint | No | Internal currency ID to filter by. `0` or NULL disables this filter. |\n\n- The table is read with `NOLOCK`, so uncommitted changes may be visible.\n- Currencies that are not parent currencies (`ParentCurrency` other than 1) are never returned, even when their code or ID is passed explicitly; the result is then empty.\n- The row order is not guaranteed because the query has no `ORDER BY`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the version of the current Pixi database, its revision name, the consistency status with the master database and endpoint information.\n\nThe call takes no parameters. It forwards directly to the internal procedure `Pixi_GetCurrentPixiVersion` and returns one row.\n\nSteps:\n\n1. The version information is read through `Pixi_GetCurrentVersion`. This yields the version from the local change log (`DB_Change_Log`) and from the master database.\n2. The endpoint data of the client is read from the master database through `util.Master_EndpointGet`. This includes the default entry point URI, the client ID and the internal version name.\n3. The column `InformationQualityDescription` is set:\n - `200 OK`: the master database was reachable and its version matches the local change log.\n - `401 ...`: the master database was reachable, but its version differs from the local `DB_Change_Log`.\n - `301 ...`: the master database could not be accessed. The information comes from the local change log only.\n4. A trailing slash is appended to `DefaultEntryPointUri` if it is missing.\n\nVersion selection:\n\n- `Version` and `RevisionName` use the values from the local change log.\n- If those are `NULL`, the master values are used instead.\n\nThe row also contains:\n\n- the database name\n- the setting `DesktopLoginEnabled` (defaults to `1` if not set)\n\n- The objects `Pixi_GetCurrentVersion`, `util.Master_EndpointGet` and `dbo.SettingGet` are not attached. Which tables they read, and when the master endpoint returns a status other than 200, cannot be seen from the code.\n- If `Pixi_GetCurrentVersion` returns no row, the call returns an empty result set.\n- If the local change log version is `NULL`, the comparison with the master version is not true. In that case the status stays `200 OK` even though nothing was compared.\n- If the master database is not reachable, `Version_Master`, `DefaultEntryPointUri` and `ClientId` can be `NULL`. A `NULL` `DefaultEntryPointUri` stays `NULL`; no slash is appended.\n- The information quality is returned as a text column, not as an SQL error. The leading number (200, 301, 401) can be evaluated.\n\nDocumentation: https://pixi-api-docs.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": "Returns the version of the current Pixi database, its revision name, the consistency status with the master database and endpoint information.\n\nThe call takes no parameters. It forwards directly to the internal procedure `Pixi_GetCurrentPixiVersion` and returns one row.\n\nSteps:\n\n1. The version information is read through `Pixi_GetCurrentVersion`. This yields the version from the local change log (`DB_Change_Log`) and from the master database.\n2. The endpoint data of the client is read from the master database through `util.Master_EndpointGet`. This includes the default entry point URI, the client ID and the internal version name.\n3. The column `InformationQualityDescription` is set:\n - `200 OK`: the master database was reachable and its version matches the local change log.\n - `401 ...`: the master database was reachable, but its version differs from the local `DB_Change_Log`.\n - `301 ...`: the master database could not be accessed. The information comes from the local change log only.\n4. A trailing slash is appended to `DefaultEntryPointUri` if it is missing.\n\nVersion selection:\n\n- `Version` and `RevisionName` use the values from the local change log.\n- If those are `NULL`, the master values are used instead.\n\nThe row also contains:\n\n- the database name\n- the setting `DesktopLoginEnabled` (defaults to `1` if not set)\n\n- The objects `Pixi_GetCurrentVersion`, `util.Master_EndpointGet` and `dbo.SettingGet` are not attached. Which tables they read, and when the master endpoint returns a status other than 200, cannot be seen from the code.\n- If `Pixi_GetCurrentVersion` returns no row, the call returns an empty result set.\n- If the local change log version is `NULL`, the comparison with the master version is not true. In that case the status stays `200 OK` even though nothing was compared.\n- If the master database is not reachable, `Version_Master`, `DefaultEntryPointUri` and `ClientId` can be `NULL`. A `NULL` `DefaultEntryPointUri` stays `NULL`; no slash is appended.\n- The information quality is returned as a text column, not as an SQL error. The leading number (200, 301, 401) can be evaluated.\n\nDocumentation: https://pixi-api-docs.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": "Returns the database change log entries that carry a revision number, newest revision first, to determine the installed Pixi version.\n\nReads the database change log (`DB_change_log`) and returns every entry whose `revision` is not `NULL`.\n\n- The call has no parameters.\n- Rows are sorted by `revision` in descending order. Sorting is numeric per segment: the revision string is split at `.` and every segment is left-padded with zeros to 7 digits, so `6.10.2` ranks above `6.9.15`.\n- The first row therefore holds the highest revision, which a caller can use as the current Pixi version.\n\n- The table is read with `NOLOCK`, so uncommitted entries may be visible.\n- All matching rows are returned without paging; the result can be long. Take the first row if only the current version is needed.\n- Segments longer than 7 characters are not padded and can distort the sort order. Non-numeric segments are sorted as text.\n- The column types are not visible in the code, because the definition of `DB_change_log` is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Returns the database change log entries that carry a revision number, newest revision first, to determine the installed Pixi version.\n\nReads the database change log (`DB_change_log`) and returns every entry whose `revision` is not `NULL`.\n\n- The call has no parameters.\n- Rows are sorted by `revision` in descending order. Sorting is numeric per segment: the revision string is split at `.` and every segment is left-padded with zeros to 7 digits, so `6.10.2` ranks above `6.9.15`.\n- The first row therefore holds the highest revision, which a caller can use as the current Pixi version.\n\n- The table is read with `NOLOCK`, so uncommitted entries may be visible.\n- All matching rows are returned without paging; the result can be long. Take the first row if only the current version is needed.\n- Segments longer than 7 characters are not padded and can distort the sort order. Non-numeric segments are sorted as text.\n- The column types are not visible in the code, because the definition of `DB_change_log` is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Returns the current local date and time of the Pixi database server together with the current UTC time.\n\nReturns a single row with two columns:\n\n- `ServerTime`: the current local date and time of the SQL Server (`CURRENT_TIMESTAMP`).\n- `ServerTimeUTC`: the current date and time in UTC (`GETUTCDATE()`).\n\nThe call has no parameters and does not access any tables.\n\n- Useful to determine the time zone offset of the Pixi server, e.g. before passing date filters such as \"changed since\" to other calls that compare against server-local timestamps.\n- Both values are `datetime` with a precision of about 3 milliseconds.\n- `ServerTime` reflects the time zone setting of the database server's operating system.\n- Also suitable as a lightweight connectivity or authentication check.\n\nDocumentation: https://pixi-api-docs.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": "Returns the current local date and time of the Pixi database server together with the current UTC time.\n\nReturns a single row with two columns:\n\n- `ServerTime`: the current local date and time of the SQL Server (`CURRENT_TIMESTAMP`).\n- `ServerTimeUTC`: the current date and time in UTC (`GETUTCDATE()`).\n\nThe call has no parameters and does not access any tables.\n\n- Useful to determine the time zone offset of the Pixi server, e.g. before passing date filters such as \"changed since\" to other calls that compare against server-local timestamps.\n- Both values are `datetime` with a precision of about 3 milliseconds.\n- `ServerTime` reflects the time zone setting of the database server's operating system.\n- Also suitable as a lightweight connectivity or authentication check.\n\nDocumentation: https://pixi-api-docs.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": "Returns the value of a single Pixi setting or, if no name is given, an overview of selected settings, licence counters and master data counts.\n\nReads system settings from the `Settings` table. Empty strings in any parameter are treated as `NULL`.\n\nThe call works in three modes:\n\n- **`SettingName` = `LocID`**: returns one row with `SettingName` = `LocID` and a `SettingValue` that lists all location IDs from `Location`, each followed by `; ` (e.g. `001; 002; `).\n- **Any other `SettingName`**: returns one row with the requested name and its value from `Settings` (first match). If the setting does not exist or its value is `NULL`, `SettingValue` is `'0'`.\n- **No `SettingName`** (omitted or empty): returns an overview with several rows:\n - the settings `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` (only those that exist in `Settings`),\n - `Mobile_Licenses`: number of active user sessions with session type 4 or 5,\n - `Suppliers`, `Shops`, `Locations`: number of records in the respective tables,\n - `ShipVendors`: all shipping vendor names, each followed by `, `,\n - `LocID`: all location IDs, each followed by `; `,\n - `PIM`: `'1'` if a `ShopUrl` setting points to `pim.pixi.eu` or `pim-beta.pixi.eu`, otherwise `'0'`. If the setting `C_OrderImportEnabled` is `1`, the channel settings (`C_ChannelSettings`) are checked as well.\n\nThe overview rows are combined with `UNION`, so duplicate rows are removed and no sort order is guaranteed.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SettingName` | varchar(50) | No | Name of the setting to read. `LocID` returns the list of all location IDs. Empty or omitted returns the overview of selected settings and counters. |\n| `ShopID` | varchar(3) | No | Shop ID. Passed to the setting lookup but currently without effect. |\n| `LocID` | varchar(3) | No | Location ID. Passed to the setting lookup but currently without effect. |\n\n- `ShopID` and `LocID` are passed to the internal setting lookup function, but that function ignores them. Shop- or location-specific values are therefore **not** returned; the result is always the global value from `Settings`.\n- A missing setting is indistinguishable from a setting with value `'0'`.\n- All reads use `NOLOCK`, so values may reflect uncommitted changes.\n- The lists for `LocID` and `ShipVendors` are built with `FOR XML PATH`, so they end with a trailing separator, special characters such as `&` may appear XML-escaped, and the value is `NULL` if the table is empty.\n- In overview mode, `C_OrderImportEnabled` is compared with the number `1`; a non-numeric value of this setting would cause a conversion error.\n\nDocumentation: https://pixi-api-docs.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": "Returns the value of a single Pixi setting or, if no name is given, an overview of selected settings, licence counters and master data counts.\n\nReads system settings from the `Settings` table. Empty strings in any parameter are treated as `NULL`.\n\nThe call works in three modes:\n\n- **`SettingName` = `LocID`**: returns one row with `SettingName` = `LocID` and a `SettingValue` that lists all location IDs from `Location`, each followed by `; ` (e.g. `001; 002; `).\n- **Any other `SettingName`**: returns one row with the requested name and its value from `Settings` (first match). If the setting does not exist or its value is `NULL`, `SettingValue` is `'0'`.\n- **No `SettingName`** (omitted or empty): returns an overview with several rows:\n - the settings `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` (only those that exist in `Settings`),\n - `Mobile_Licenses`: number of active user sessions with session type 4 or 5,\n - `Suppliers`, `Shops`, `Locations`: number of records in the respective tables,\n - `ShipVendors`: all shipping vendor names, each followed by `, `,\n - `LocID`: all location IDs, each followed by `; `,\n - `PIM`: `'1'` if a `ShopUrl` setting points to `pim.pixi.eu` or `pim-beta.pixi.eu`, otherwise `'0'`. If the setting `C_OrderImportEnabled` is `1`, the channel settings (`C_ChannelSettings`) are checked as well.\n\nThe overview rows are combined with `UNION`, so duplicate rows are removed and no sort order is guaranteed.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SettingName` | varchar(50) | No | Name of the setting to read. `LocID` returns the list of all location IDs. Empty or omitted returns the overview of selected settings and counters. |\n| `ShopID` | varchar(3) | No | Shop ID. Passed to the setting lookup but currently without effect. |\n| `LocID` | varchar(3) | No | Location ID. Passed to the setting lookup but currently without effect. |\n\n- `ShopID` and `LocID` are passed to the internal setting lookup function, but that function ignores them. Shop- or location-specific values are therefore **not** returned; the result is always the global value from `Settings`.\n- A missing setting is indistinguishable from a setting with value `'0'`.\n- All reads use `NOLOCK`, so values may reflect uncommitted changes.\n- The lists for `LocID` and `ShipVendors` are built with `FOR XML PATH`, so they end with a trailing separator, special characters such as `&` may appear XML-escaped, and the value is `NULL` if the table is empty.\n- In overview mode, `C_OrderImportEnabled` is compared with the number `1`; a non-numeric value of this setting would cause a conversion error.\n\nDocumentation: https://pixi-api-docs.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": "Returns the master data of all shops or of a single shop, including address, contact, footer-based bank details and cost center.\n\nReads the shop master data from the `shops` table.\n\n- If `ShopID` is passed, only the shop with this ID is returned.\n- If `ShopID` is omitted, `NULL` or an empty string, all shops are returned.\n\nNo sort order is defined, so rows come back in whatever order the database returns them. Some columns are renamed in the result: `SI_WebAddr` becomes `ShopURL`, `SI_Address` becomes `ShopCompany`, and the footer lines `SI_FootLine1` to `SI_FootLine4` are returned as `BIC`, `IBAN`, `KontoBLZ` and `BankName`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | No | ID of the shop to return. If it is empty or `NULL`, all shops are returned. |\n\n- The table is read with `NOLOCK`, so uncommitted data can appear in the result.\n- The bank-related column names (`BIC`, `IBAN`, `KontoBLZ`, `BankName`) are only aliases for the generic footer lines `SI_FootLine1` to `SI_FootLine4`. They contain whatever has been entered in these footer lines, which is not necessarily bank data.\n- An unknown `ShopID` does not raise an error; the result set is simply empty.\n\nDocumentation: https://pixi-api-docs.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": "Returns the master data of all shops or of a single shop, including address, contact, footer-based bank details and cost center.\n\nReads the shop master data from the `shops` table.\n\n- If `ShopID` is passed, only the shop with this ID is returned.\n- If `ShopID` is omitted, `NULL` or an empty string, all shops are returned.\n\nNo sort order is defined, so rows come back in whatever order the database returns them. Some columns are renamed in the result: `SI_WebAddr` becomes `ShopURL`, `SI_Address` becomes `ShopCompany`, and the footer lines `SI_FootLine1` to `SI_FootLine4` are returned as `BIC`, `IBAN`, `KontoBLZ` and `BankName`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | No | ID of the shop to return. If it is empty or `NULL`, all shops are returned. |\n\n- The table is read with `NOLOCK`, so uncommitted data can appear in the result.\n- The bank-related column names (`BIC`, `IBAN`, `KontoBLZ`, `BankName`) are only aliases for the generic footer lines `SI_FootLine1` to `SI_FootLine4`. They contain whatever has been entered in these footer lines, which is not necessarily bank data.\n- An unknown `ShopID` does not raise an error; the result set is simply empty.\n\nDocumentation: https://pixi-api-docs.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": "Returns Pixi users with their names and a semicolon-separated list of permission codes derived from their roles.\n\nReturns the permission codes of one Pixi user or of all users.\n\n- If `UserName` is given, only that user is returned. If it is empty or `NULL`, all users are returned.\n- The built-in user `master` is always excluded.\n- Only users that have at least one role assigned are considered. Users without roles are not returned at all.\n- Permission codes come from the user's roles through the role-to-permission assignments. Each code appears at most once per user, even if several roles grant it.\n\nThe call returns one row per user. `PermissionCode` holds all codes of that user joined with `;`.\n\nIf no matching user is found, a status row with `Status` = `Error` is returned instead.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `UserName` | varchar(50) | No | Login name of the user. Empty or `NULL` returns all users except `master`. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- Each permission code is converted to `varchar(10)` before it is joined. Longer codes are cut off.\n- If a user's roles grant no permissions, `PermissionCode` is `NULL`.\n- Neither the rows nor the codes inside `PermissionCode` have a guaranteed order.\n- The list is built with `FOR XML PATH`. Characters such as `&`, `<` or `>` would therefore appear XML-escaped.\n- When all users are requested and none is found, the error message names an empty user name (`''`).\n\nDocumentation: https://pixi-api-docs.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": "Returns Pixi users with their names and a semicolon-separated list of permission codes derived from their roles.\n\nReturns the permission codes of one Pixi user or of all users.\n\n- If `UserName` is given, only that user is returned. If it is empty or `NULL`, all users are returned.\n- The built-in user `master` is always excluded.\n- Only users that have at least one role assigned are considered. Users without roles are not returned at all.\n- Permission codes come from the user's roles through the role-to-permission assignments. Each code appears at most once per user, even if several roles grant it.\n\nThe call returns one row per user. `PermissionCode` holds all codes of that user joined with `;`.\n\nIf no matching user is found, a status row with `Status` = `Error` is returned instead.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `UserName` | varchar(50) | No | Login name of the user. Empty or `NULL` returns all users except `master`. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- Each permission code is converted to `varchar(10)` before it is joined. Longer codes are cut off.\n- If a user's roles grant no permissions, `PermissionCode` is `NULL`.\n- Neither the rows nor the codes inside `PermissionCode` have a guaranteed order.\n- The list is built with `FOR XML PATH`. Characters such as `&`, `<` or `>` would therefore appear XML-escaped.\n- When all users are requested and none is found, the error message names an empty user name (`''`).\n\nDocumentation: https://pixi-api-docs.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": "Returns the Pixi users found in the most recent login snapshot of `UsersLoggedIn`, with first name, last name and e-mail address.\n\nThe call has no parameters.\n\n1. It finds the highest `Tag` value in `UsersLoggedIn` among entries with `UserActiveSessionTypeId = 1`. This value identifies the most recent recorded snapshot of logged-in users.\n2. It returns all entries of `UsersLoggedIn` that belong to this `Tag` and have `UserActiveSessionTypeId` 1 or 2.\n3. Each entry is joined to `Users`. The join uses the part of `UsersLoggedIn.UserName` before the first space, which must equal `Users.UserName`.\n4. The rows are grouped by all output columns, so duplicate session entries of the same login name appear only once.\n\nThe result has no explicit sort order.\n\n- All reads use `NOLOCK`, so the result can contain uncommitted or inconsistent data.\n- Entries whose `UserName` in `UsersLoggedIn` contains no space are never returned. In that case `PATINDEX` returns 0 and the extracted name is empty, so the join to `Users` finds no match.\n- The header comment says the procedure returns \"the number of active connections and logged in users\". The code, however, returns a list of users and no counts.\n- The meaning of the `UserActiveSessionTypeId` values 1 and 2 is not defined in the code. How and when `UsersLoggedIn` is filled is also not visible here.\n- If no entry with `UserActiveSessionTypeId = 1` exists, the result is empty.\n\nDocumentation: https://pixi-api-docs.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": "Returns the Pixi users found in the most recent login snapshot of `UsersLoggedIn`, with first name, last name and e-mail address.\n\nThe call has no parameters.\n\n1. It finds the highest `Tag` value in `UsersLoggedIn` among entries with `UserActiveSessionTypeId = 1`. This value identifies the most recent recorded snapshot of logged-in users.\n2. It returns all entries of `UsersLoggedIn` that belong to this `Tag` and have `UserActiveSessionTypeId` 1 or 2.\n3. Each entry is joined to `Users`. The join uses the part of `UsersLoggedIn.UserName` before the first space, which must equal `Users.UserName`.\n4. The rows are grouped by all output columns, so duplicate session entries of the same login name appear only once.\n\nThe result has no explicit sort order.\n\n- All reads use `NOLOCK`, so the result can contain uncommitted or inconsistent data.\n- Entries whose `UserName` in `UsersLoggedIn` contains no space are never returned. In that case `PATINDEX` returns 0 and the extracted name is empty, so the join to `Users` finds no match.\n- The header comment says the procedure returns \"the number of active connections and logged in users\". The code, however, returns a list of users and no counts.\n- The meaning of the `UserActiveSessionTypeId` values 1 and 2 is not defined in the code. How and when `UsersLoggedIn` is filled is also not visible here.\n- If no entry with `UserActiveSessionTypeId = 1` exists, the result is empty.\n\nDocumentation: https://pixi-api-docs.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": "Returns the high and low VAT rates per country that are valid at a given point in time, filtered by ISO country code and/or VAT charge flag.\n\nLooks up VAT rates from the VAT master data (`VATs`) joined with the country master data (`Countries`) on `VATs.Country = Countries.CntCode`.\n\n**Parameter handling**\n- Empty strings in `CntCodeISO2`, `CntCodeISO3` and `ChargeVAT` are treated as not specified (`NULL`).\n- A `Datetime` earlier than `1990-01-01` is replaced by the current date and time.\n\n**Validation**\nAn error row is returned instead of data if `Datetime` is not specified, or if none of `CntCodeISO2`, `CntCodeISO3` and `ChargeVAT` is specified. A date plus at least one further filter is therefore required.\n\n**Filtering**\n- `CntCodeISO2`: only countries with this ISO 3166 alpha-2 code.\n- `CntCodeISO3`: only countries with this ISO 3166 alpha-3 code.\n- `ChargeVAT`: only VAT records with this `ChargeVAT` value.\n- `Datetime`: only VAT records whose validity period contains the date (`DateStart` <= `Datetime` <= `DateEnd`, both bounds inclusive).\n\nAll given filters are combined with AND. The result has no explicit sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CntCodeISO2` | char(2) | No | ISO 3166 alpha-2 country code to filter by. Empty string means no filter. |\n| `CntCodeISO3` | char(3) | No | ISO 3166 alpha-3 country code to filter by. Empty string means no filter. |\n| `ChargeVAT` | char(1) | No | Value of the `ChargeVAT` column of the VAT record to filter by. Empty string means no filter. |\n| `Datetime` | datetime | No | Point in time for which the VAT rates must be valid. Effectively mandatory: without it an error row is returned. Values before 1990-01-01 are replaced by the current date and time. |\n\n- Both tables are read with `NOLOCK`, so uncommitted changes may be visible.\n- VAT records with a `NULL` in `DateStart` or `DateEnd` never match, because the date comparison is not true for `NULL`.\n- Passing a very old date (before 1990) silently returns the currently valid rates instead of historical ones.\n- `DateEnd` is compared inclusively including the time part; if `DateEnd` is stored as midnight, a `Datetime` later on that day no longer matches.\n- The meaning of the `ChargeVAT` values is not defined in this procedure; it depends on the content of the `VATs` table.\n- Several rows per country can be returned, e.g. one per `ChargeVAT` value, if only a country code is given.\n\nDocumentation: https://pixi-api-docs.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": "Returns the high and low VAT rates per country that are valid at a given point in time, filtered by ISO country code and/or VAT charge flag.\n\nLooks up VAT rates from the VAT master data (`VATs`) joined with the country master data (`Countries`) on `VATs.Country = Countries.CntCode`.\n\n**Parameter handling**\n- Empty strings in `CntCodeISO2`, `CntCodeISO3` and `ChargeVAT` are treated as not specified (`NULL`).\n- A `Datetime` earlier than `1990-01-01` is replaced by the current date and time.\n\n**Validation**\nAn error row is returned instead of data if `Datetime` is not specified, or if none of `CntCodeISO2`, `CntCodeISO3` and `ChargeVAT` is specified. A date plus at least one further filter is therefore required.\n\n**Filtering**\n- `CntCodeISO2`: only countries with this ISO 3166 alpha-2 code.\n- `CntCodeISO3`: only countries with this ISO 3166 alpha-3 code.\n- `ChargeVAT`: only VAT records with this `ChargeVAT` value.\n- `Datetime`: only VAT records whose validity period contains the date (`DateStart` <= `Datetime` <= `DateEnd`, both bounds inclusive).\n\nAll given filters are combined with AND. The result has no explicit sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CntCodeISO2` | char(2) | No | ISO 3166 alpha-2 country code to filter by. Empty string means no filter. |\n| `CntCodeISO3` | char(3) | No | ISO 3166 alpha-3 country code to filter by. Empty string means no filter. |\n| `ChargeVAT` | char(1) | No | Value of the `ChargeVAT` column of the VAT record to filter by. Empty string means no filter. |\n| `Datetime` | datetime | No | Point in time for which the VAT rates must be valid. Effectively mandatory: without it an error row is returned. Values before 1990-01-01 are replaced by the current date and time. |\n\n- Both tables are read with `NOLOCK`, so uncommitted changes may be visible.\n- VAT records with a `NULL` in `DateStart` or `DateEnd` never match, because the date comparison is not true for `NULL`.\n- Passing a very old date (before 1990) silently returns the currently valid rates instead of historical ones.\n- `DateEnd` is compared inclusively including the time part; if `DateEnd` is stored as midnight, a `Datetime` later on that day no longer matches.\n- The meaning of the `ChargeVAT` values is not defined in this procedure; it depends on the content of the `VATs` table.\n- Several rows per country can be returned, e.g. one per `ChargeVAT` value, if only a country code is given.\n\nDocumentation: https://pixi-api-docs.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": "Returns all entries of the VAT rate change history from table VATsHist.\n\nReturns every row of the VAT rate history table `VATsHist` without any filter.\n\nEach row contains the old and new text of a change (`HText`, `LText`), a remark, and the date and employee of the change.\n\nThe call has no parameters. No sort order is defined, so the row order is not guaranteed.\n\n- The table is read with `NOLOCK`, so uncommitted changes can appear.\n- The code does not show the meaning of `HText` and `LText`. By the column names they are probably a header text and a long text describing the change, but this cannot be confirmed from the code.\n- The result is not limited or paged. All history entries are returned.\n\nDocumentation: https://pixi-api-docs.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": "Returns all entries of the VAT rate change history from table VATsHist.\n\nReturns every row of the VAT rate history table `VATsHist` without any filter.\n\nEach row contains the old and new text of a change (`HText`, `LText`), a remark, and the date and employee of the change.\n\nThe call has no parameters. No sort order is defined, so the row order is not guaranteed.\n\n- The table is read with `NOLOCK`, so uncommitted changes can appear.\n- The code does not show the meaning of `HText` and `LText`. By the column names they are probably a header text and a long text describing the change, but this cannot be confirmed from the code.\n- The result is not limited or paged. All history entries are returned.\n\nDocumentation: https://pixi-api-docs.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": "Returns the latest and minimum allowed executable versions of Pixi client applications, optionally for one client name.\n\nReads the version information of client executables from the table `ExeClientVersion`.\n\n- If `ClientName` is omitted or `NULL`, all rows of the table are returned.\n- If `ClientName` is given, only the row(s) whose `ClientName` matches the value exactly are returned.\n\nEach row contains the client name, the latest available version and the minimum version a client must have to be allowed to run. No explicit sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ClientName` | varchar(50) | No | Name of the client application to filter by (exact match). `NULL` returns all clients. |\n\n- The table is read with `NOLOCK`, so uncommitted changes may be visible.\n- The result has no `ORDER BY`; the row order is not guaranteed.\n- An unknown `ClientName` returns an empty result set, not an error.\n- The data types of the columns are not visible in the code; they come from the table `ExeClientVersion`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the latest and minimum allowed executable versions of Pixi client applications, optionally for one client name.\n\nReads the version information of client executables from the table `ExeClientVersion`.\n\n- If `ClientName` is omitted or `NULL`, all rows of the table are returned.\n- If `ClientName` is given, only the row(s) whose `ClientName` matches the value exactly are returned.\n\nEach row contains the client name, the latest available version and the minimum version a client must have to be allowed to run. No explicit sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ClientName` | varchar(50) | No | Name of the client application to filter by (exact match). `NULL` returns all clients. |\n\n- The table is read with `NOLOCK`, so uncommitted changes may be visible.\n- The result has no `ORDER BY`; the row order is not guaranteed.\n- An unknown `ClientName` returns an empty result set, not an error.\n- The data types of the columns are not visible in the code; they come from the table `ExeClientVersion`.\n\nDocumentation: https://pixi-api-docs.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": "Stores an order or item import XML in the Pixi XML log (`C_XMLLog`) with status `XIM` and returns the key of the new log entry.\n\nHands an import document over to Pixi's new import mechanism by writing it into the XML log.\n\n1. If `ParameterXML` is not empty, its content replaces `XML`. An empty `OperationType` or `XML` is treated as `NULL`.\n2. `OperationType` is compared case-insensitively:\n - `order` resolves to the operation type `OrderImport`\n - `item` resolves to the operation type `ItemImport`\n - any other value, including `NULL`, is rejected.\n The operation type key is read from `C_OperationTypes`.\n3. `ChannelRef` is looked up in `C_Channels`.\n4. The input is then checked in this order: channel is `NULL`, operation type unknown, XML missing. The first failed check returns a single row with `ErrorNr` = 500 and `ErrorMsg`.\n5. If all checks pass, the XML is written to `C_XMLLog` with `Source` = `API`, `Status` = `XIM`, user `API`, the resolved operation type and the channel. The text is cleaned up and converted to the XML data type. If the conversion fails, the raw text is stored together with the conversion error number and message. The call does not report this as an error.\n6. The call returns the key of the new log entry. It does not import the order or item itself. That happens later in the import processing, which is not part of this call.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ChannelRef` | int | No | Key of the channel (`C_Channels.ChannelKey`) the import belongs to. Only an explicit `NULL` is rejected; unknown keys are stored as passed. |\n| `OperationType` | varchar(20) | No | Kind of import, compared case-insensitively. Any value other than `ORDER` or `ITEM` returns an error. |\n| `XML` | varchar(max) | No | The import document as text, for example an order or a BMEcat item document. It is ignored if `ParameterXML` is filled. If it is empty or missing, the call returns an error. |\n| `ParameterXML` | varchar(max) | No | Alternative to `XML`. If not empty, it replaces the content of `XML`. |\n\n- **Two result sets on success:** the internal procedure `Pixi_C_InsertXML` already returns the new key as `XMLLogKey` (`SqlRowSet1`). The call then returns the same value again as `XMLKey` (`SqlRowSet2`). On error only one row (`ErrorNr`/`ErrorMsg`) is returned, in `SqlRowSet1`.\n- **Channel check is weak:** if `ChannelRef` does not exist in `C_Channels`, the variable keeps the value that was passed. The error `Channel not defined` therefore only occurs when `ChannelRef` is explicitly `NULL`. A non-existent channel, including the default `0`, is stored without an error.\n- If `order` or `item` is passed but the matching row (`OrderImport`/`ItemImport`) is missing in `C_OperationTypes`, the operation type stays `NULL`. The entry is then stored with an empty operation type instead of being rejected.\n- **Invalid XML is not rejected.** A failed XML conversion is only recorded in the log columns `XmlResponseCastErrorNr`/`XmlResponseCastErrorMessage`. Check the XML before sending it.\n- The XML is cleaned by `fPixi_CleanupXmlText`, whose definition is not attached.\n- No explicit transaction is used. The lookups in `C_OperationTypes` and `C_Channels` use `NOLOCK`.\n- Send the XML document escaped (or as CDATA) inside the SOAP element, because the parameter is a `varchar(max)` string.\n\nDocumentation: https://pixi-api-docs.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": "Stores an order or item import XML in the Pixi XML log (`C_XMLLog`) with status `XIM` and returns the key of the new log entry.\n\nHands an import document over to Pixi's new import mechanism by writing it into the XML log.\n\n1. If `ParameterXML` is not empty, its content replaces `XML`. An empty `OperationType` or `XML` is treated as `NULL`.\n2. `OperationType` is compared case-insensitively:\n - `order` resolves to the operation type `OrderImport`\n - `item` resolves to the operation type `ItemImport`\n - any other value, including `NULL`, is rejected.\n The operation type key is read from `C_OperationTypes`.\n3. `ChannelRef` is looked up in `C_Channels`.\n4. The input is then checked in this order: channel is `NULL`, operation type unknown, XML missing. The first failed check returns a single row with `ErrorNr` = 500 and `ErrorMsg`.\n5. If all checks pass, the XML is written to `C_XMLLog` with `Source` = `API`, `Status` = `XIM`, user `API`, the resolved operation type and the channel. The text is cleaned up and converted to the XML data type. If the conversion fails, the raw text is stored together with the conversion error number and message. The call does not report this as an error.\n6. The call returns the key of the new log entry. It does not import the order or item itself. That happens later in the import processing, which is not part of this call.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ChannelRef` | int | No | Key of the channel (`C_Channels.ChannelKey`) the import belongs to. Only an explicit `NULL` is rejected; unknown keys are stored as passed. |\n| `OperationType` | varchar(20) | No | Kind of import, compared case-insensitively. Any value other than `ORDER` or `ITEM` returns an error. |\n| `XML` | varchar(max) | No | The import document as text, for example an order or a BMEcat item document. It is ignored if `ParameterXML` is filled. If it is empty or missing, the call returns an error. |\n| `ParameterXML` | varchar(max) | No | Alternative to `XML`. If not empty, it replaces the content of `XML`. |\n\n- **Two result sets on success:** the internal procedure `Pixi_C_InsertXML` already returns the new key as `XMLLogKey` (`SqlRowSet1`). The call then returns the same value again as `XMLKey` (`SqlRowSet2`). On error only one row (`ErrorNr`/`ErrorMsg`) is returned, in `SqlRowSet1`.\n- **Channel check is weak:** if `ChannelRef` does not exist in `C_Channels`, the variable keeps the value that was passed. The error `Channel not defined` therefore only occurs when `ChannelRef` is explicitly `NULL`. A non-existent channel, including the default `0`, is stored without an error.\n- If `order` or `item` is passed but the matching row (`OrderImport`/`ItemImport`) is missing in `C_OperationTypes`, the operation type stays `NULL`. The entry is then stored with an empty operation type instead of being rejected.\n- **Invalid XML is not rejected.** A failed XML conversion is only recorded in the log columns `XmlResponseCastErrorNr`/`XmlResponseCastErrorMessage`. Check the XML before sending it.\n- The XML is cleaned by `fPixi_CleanupXmlText`, whose definition is not attached.\n- No explicit transaction is used. The lookups in `C_OperationTypes` and `C_Channels` use `NOLOCK`.\n- Send the XML document escaped (or as CDATA) inside the SOAP element, because the parameter is a `varchar(max)` string.\n\nDocumentation: https://pixi-api-docs.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": "Returns the most recent XML import log entry for an order (by ORDER_ID) or an item (by SUPPLIER_AID).\n\nSearches the XML import log `C_XMLLog` for the latest entry that contains a given ID and returns it with request, response and status information.\n\n1. If `Id` is empty or `NULL`, a status row with `StatusCode` 400 is returned and nothing else happens.\n2. `Type` is compared case-insensitively:\n - `order`: looks up the operation type `OrderImport` in `C_OperationTypes` and searches log entries whose `XmlResponseXml` contains an `ORDER_ID` element (at any depth) whose value equals `Id`.\n - `item`: looks up the operation type `ItemImport` and searches for an `SUPPLIER_AID` element (at any depth) whose value equals `Id`.\n - Any other value returns a status row with `StatusCode` 400.\n3. Additional filters for both types:\n - If `Channel` is given, only entries with that `ChannelRef` are considered; if it is `NULL`, all channels are searched.\n - Entries with `Status` = `XNI` are excluded.\n4. The result is sorted by `XMLLogKey` descending and only the first row (the newest matching log entry) is returned. If no entry matches, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Type` | varchar(10) | Yes | Kind of import to search in (case-insensitive). |\n| `Id` | varchar(50) | Yes | Value to search for: the order ID (`ORDER_ID`) for `order`, or the supplier article number (`SUPPLIER_AID`) for `item`. Must not be empty. |\n| `Channel` | int | No | Optional channel key (`ChannelRef`) to restrict the search; `NULL` searches all channels. |\n\n- All reads use `NOLOCK`, so uncommitted log entries may be returned.\n- The ID match is an exact string comparison against the element value inside `XmlResponseXml` using an XPath `exist()` with a descendant search (`//`). This is evaluated for every candidate log row and can be slow on large log tables; using `Channel` narrows the search.\n- The `Id` check happens before the `Type` check, so an empty `Id` always yields the ID error message even if `Type` is invalid.\n- If the operation type `OrderImport` or `ItemImport` does not exist in `C_OperationTypes`, no rows are returned.\n- The meaning of the status value `XNI` is not defined in the code.\n- `Response` is the XML column `XmlResponseXml` converted to `varchar(max)`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the most recent XML import log entry for an order (by ORDER_ID) or an item (by SUPPLIER_AID).\n\nSearches the XML import log `C_XMLLog` for the latest entry that contains a given ID and returns it with request, response and status information.\n\n1. If `Id` is empty or `NULL`, a status row with `StatusCode` 400 is returned and nothing else happens.\n2. `Type` is compared case-insensitively:\n - `order`: looks up the operation type `OrderImport` in `C_OperationTypes` and searches log entries whose `XmlResponseXml` contains an `ORDER_ID` element (at any depth) whose value equals `Id`.\n - `item`: looks up the operation type `ItemImport` and searches for an `SUPPLIER_AID` element (at any depth) whose value equals `Id`.\n - Any other value returns a status row with `StatusCode` 400.\n3. Additional filters for both types:\n - If `Channel` is given, only entries with that `ChannelRef` are considered; if it is `NULL`, all channels are searched.\n - Entries with `Status` = `XNI` are excluded.\n4. The result is sorted by `XMLLogKey` descending and only the first row (the newest matching log entry) is returned. If no entry matches, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Type` | varchar(10) | Yes | Kind of import to search in (case-insensitive). |\n| `Id` | varchar(50) | Yes | Value to search for: the order ID (`ORDER_ID`) for `order`, or the supplier article number (`SUPPLIER_AID`) for `item`. Must not be empty. |\n| `Channel` | int | No | Optional channel key (`ChannelRef`) to restrict the search; `NULL` searches all channels. |\n\n- All reads use `NOLOCK`, so uncommitted log entries may be returned.\n- The ID match is an exact string comparison against the element value inside `XmlResponseXml` using an XPath `exist()` with a descendant search (`//`). This is evaluated for every candidate log row and can be slow on large log tables; using `Channel` narrows the search.\n- The `Id` check happens before the `Type` check, so an empty `Id` always yields the ID error message even if `Type` is invalid.\n- If the operation type `OrderImport` or `ItemImport` does not exist in `C_OperationTypes`, no rows are returned.\n- The meaning of the status value `XNI` is not defined in the code.\n- `Response` is the XML column `XmlResponseXml` converted to `varchar(max)`.\n\nDocumentation: https://pixi-api-docs.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": "Returns all channels defined in Pixi with their key, name and channel type name.\n\nReturns one row per channel stored in `C_Channels`. The call takes no parameters and applies no filter.\n\nFor each channel the call returns:\n\n- the channel key (`ChannelKey`)\n- the channel name (`ChannelName`)\n- the name of the channel type (`ChannelType`). This value is looked up in `C_ChannelTypes` through the channel's `ChannelTypeRef`.\n\nThe code sets no sort order, so the order of the rows is not guaranteed.\n\n- Both tables are read with `NOLOCK`, so uncommitted changes may appear in the result.\n- `ChannelType` is `NULL` if no channel type matches the channel's `ChannelTypeRef`.\n- The column data types are not visible in the code because the table definitions are not attached.\n\nDocumentation: https://pixi-api-docs.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": "Returns all channels defined in Pixi with their key, name and channel type name.\n\nReturns one row per channel stored in `C_Channels`. The call takes no parameters and applies no filter.\n\nFor each channel the call returns:\n\n- the channel key (`ChannelKey`)\n- the channel name (`ChannelName`)\n- the name of the channel type (`ChannelType`). This value is looked up in `C_ChannelTypes` through the channel's `ChannelTypeRef`.\n\nThe code sets no sort order, so the order of the rows is not guaranteed.\n\n- Both tables are read with `NOLOCK`, so uncommitted changes may appear in the result.\n- `ChannelType` is `NULL` if no channel type matches the channel's `ChannelTypeRef`.\n- The column data types are not visible in the code because the table definitions are not attached.\n\nDocumentation: https://pixi-api-docs.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": "Returns the name, channel type and all settings of a single import channel.\n\nReads the channel identified by `ChannelKey` from the channel table and returns one row per setting of that channel.\n\n- The channel type name is joined via the channel's type reference (left join, so it is empty if the type is missing).\n- The settings are joined with a left join. A channel without any settings therefore still returns **one row** with empty `SettingName` and `SettingValue`.\n- If no channel with the given key exists, no rows are returned.\n\nNo sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ChannelKey` | int | No | Key of the channel whose settings are returned. |\n\nAll tables are read with `NOLOCK`, so uncommitted changes may be visible. The default `ChannelKey` of `0` usually matches no channel; always pass the key explicitly.\n\nDocumentation: https://pixi-api-docs.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": "Returns the name, channel type and all settings of a single import channel.\n\nReads the channel identified by `ChannelKey` from the channel table and returns one row per setting of that channel.\n\n- The channel type name is joined via the channel's type reference (left join, so it is empty if the type is missing).\n- The settings are joined with a left join. A channel without any settings therefore still returns **one row** with empty `SettingName` and `SettingValue`.\n- If no channel with the given key exists, no rows are returned.\n\nNo sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ChannelKey` | int | No | Key of the channel whose settings are returned. |\n\nAll tables are read with `NOLOCK`, so uncommitted changes may be visible. The default `ChannelKey` of `0` usually matches no channel; always pass the key explicitly.\n\nDocumentation: https://pixi-api-docs.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": "Returns the entry of the XML import log (`C_XMLLog`) with request, response, status and error information for a given log key.\n\nReads one or more records from the XML import log table `C_XMLLog`.\n\n- A row is returned if `XMLLogKey` equals `@XMLLogKey` **or** `@LogKeyXML`.\n- Both parameters do the same thing. `@LogKeyXML` is an alternative name for the same key. If both are passed with different values, up to two log entries are returned.\n- The result contains the raw request and response, their XML-cast versions, the processing status, the operation type, the channel, the number of processing attempts, error texts and creation/update metadata.\n\nNo sort order is specified.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `XMLLogKey` | int | No | Key of the XML log entry (`C_XMLLog.XMLLogKey`) to return. |\n| `LogKeyXML` | int | No | Alternative parameter for the log key. It is combined with `XMLLogKey` by OR. |\n\n- The table is read with `NOLOCK`. Entries that are being processed may be returned in an uncommitted state.\n- Both parameters default to `0`. If neither is passed, only a log entry with key `0` would match, which normally does not exist. The result is then empty.\n- The definition of `C_XMLLog` is not attached. Column data types are therefore partly unknown. `XmlRequestXml`/`XmlResponseXml` and the `...CastError...` columns appear to hold the result of converting the raw text to XML and any conversion error.\n\nDocumentation: https://pixi-api-docs.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": "Returns the entry of the XML import log (`C_XMLLog`) with request, response, status and error information for a given log key.\n\nReads one or more records from the XML import log table `C_XMLLog`.\n\n- A row is returned if `XMLLogKey` equals `@XMLLogKey` **or** `@LogKeyXML`.\n- Both parameters do the same thing. `@LogKeyXML` is an alternative name for the same key. If both are passed with different values, up to two log entries are returned.\n- The result contains the raw request and response, their XML-cast versions, the processing status, the operation type, the channel, the number of processing attempts, error texts and creation/update metadata.\n\nNo sort order is specified.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `XMLLogKey` | int | No | Key of the XML log entry (`C_XMLLog.XMLLogKey`) to return. |\n| `LogKeyXML` | int | No | Alternative parameter for the log key. It is combined with `XMLLogKey` by OR. |\n\n- The table is read with `NOLOCK`. Entries that are being processed may be returned in an uncommitted state.\n- Both parameters default to `0`. If neither is passed, only a log entry with key `0` would match, which normally does not exist. The result is then empty.\n- The definition of `C_XMLLog` is not attached. Column data types are therefore partly unknown. `XmlRequestXml`/`XmlResponseXml` and the `...CastError...` columns appear to hold the result of converting the raw text to XML and any conversion error.\n\nDocumentation: https://pixi-api-docs.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": "Processes an imported item or order XML from C_XMLLog immediately (parse, check and apply to main tables) instead of waiting for the SQL Agent import job.\n\nTriggers the processing of one imported XML, identified by `XMLLogKey`, right away.\n\n1. **Validation**: the XML must exist in `C_XMLLog`, its operation type (`C_OperationTypes.OperationType`) must be `ItemImport` or `OrderImport`, and its `Status` must be one of `COC`, `ERR`, `NEI`, `XER`, `XIM` or `XPA`. Otherwise a status row with `ReturnCode` = `ERROR API` is returned.\n2. **Item XML** (`ItemImport`):\n - If the application lock `PixiItemImport` is currently held (the item import agent job is running), only the parse step `Pixi_C_ParseAndCheckXMLsFromItemImport` is executed for this XML, and the call ends with an `ERROR API` row saying the XML is already in process and has been parsed.\n - Otherwise the call takes the lock itself, runs the parse/check step and then `Pixi_C_ApplyItemsToMainTables` for this XML, and releases the lock.\n3. **Order XML** (`OrderImport`): same logic with lock `PixiOrderImport`, the parse step `Pixi_C_ParseAndCheckXMLsFromOrderImport` and the apply step `Pixi_C_ApplyOrdersToMainTables`.\n4. At the end a status row with `ReturnCode` = `OK` is returned.\n\nAll called procedures run with the user name `API`.\n\nBecause the called procedures return their own rows, the caller receives several result sets: the `Success` row of the parse step, possibly rows of the apply step, and finally the `ReturnCode`/`ErrorMessage` status row. Always evaluate the **last** result set for the outcome.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `XMLLogKey` | int | Yes | Key of the imported XML in `C_XMLLog` that is to be (re-)processed. Must be an item or order import XML in status `COC`, `ERR`, `NEI`, `XER`, `XIM` or `XPA`. |\n\n- **Errors in parse/apply are swallowed**: the parse and apply steps run in an inner `TRY/CATCH` that only releases the application lock. If one of them fails, the call still returns `ReturnCode` = `OK`. Check `C_XMLLog.Status`/`Error` afterwards to verify the real result.\n- The informational message `XML with XMLLogKey {XMLLogKey} has been processed.` is raised with severity 1 and may appear as `SqlMessage`; it is not an error.\n- In the \"already in process\" case the XML **has** been parsed although `ReturnCode` is `ERROR API`.\n- The application locks `PixiItemImport` / `PixiOrderImport` (session owner) are shared with the SQL Agent import jobs; while the call holds the lock, the agent job cannot process at the same time.\n- The called procedures respect the settings `C_ItemImportEnabled`, `C_ItemImport_ParseAndCheckData_Enabled`, `C_OrderImportEnabled`, `C_OrderImport_ParseAndCheckData_Enabled`, `C_OrderImport_ApplyToMainTables_Enabled` and per-channel-type settings. If they are disabled, the steps do nothing, but the call still returns `OK`.\n- The parse steps only parse XMLs of channel type `URL` whose `Error` column is empty. XMLs of channel types `PlentyREST` or `ShipRush` are only reset to status `XIM` (with `AttemptsToProcess` = 0) so that the Integration Service parses them again.\n- The parse steps also do global work (e.g. `pixi_C_UpdateXMLsAsParsed`, exchange rate import for orders), and the order apply step calls `Pixi_AmazonOrdersMarkOrders`.\n- The setting `C_ParseAndImportDataIntervalMinutes` is read but not used.\n- `Pixi_C_ApplyItemsToMainTables` is not attached; its exact behaviour and returned rows are unknown.\n- Existence and status checks use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Processes an imported item or order XML from C_XMLLog immediately (parse, check and apply to main tables) instead of waiting for the SQL Agent import job.\n\nTriggers the processing of one imported XML, identified by `XMLLogKey`, right away.\n\n1. **Validation**: the XML must exist in `C_XMLLog`, its operation type (`C_OperationTypes.OperationType`) must be `ItemImport` or `OrderImport`, and its `Status` must be one of `COC`, `ERR`, `NEI`, `XER`, `XIM` or `XPA`. Otherwise a status row with `ReturnCode` = `ERROR API` is returned.\n2. **Item XML** (`ItemImport`):\n - If the application lock `PixiItemImport` is currently held (the item import agent job is running), only the parse step `Pixi_C_ParseAndCheckXMLsFromItemImport` is executed for this XML, and the call ends with an `ERROR API` row saying the XML is already in process and has been parsed.\n - Otherwise the call takes the lock itself, runs the parse/check step and then `Pixi_C_ApplyItemsToMainTables` for this XML, and releases the lock.\n3. **Order XML** (`OrderImport`): same logic with lock `PixiOrderImport`, the parse step `Pixi_C_ParseAndCheckXMLsFromOrderImport` and the apply step `Pixi_C_ApplyOrdersToMainTables`.\n4. At the end a status row with `ReturnCode` = `OK` is returned.\n\nAll called procedures run with the user name `API`.\n\nBecause the called procedures return their own rows, the caller receives several result sets: the `Success` row of the parse step, possibly rows of the apply step, and finally the `ReturnCode`/`ErrorMessage` status row. Always evaluate the **last** result set for the outcome.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `XMLLogKey` | int | Yes | Key of the imported XML in `C_XMLLog` that is to be (re-)processed. Must be an item or order import XML in status `COC`, `ERR`, `NEI`, `XER`, `XIM` or `XPA`. |\n\n- **Errors in parse/apply are swallowed**: the parse and apply steps run in an inner `TRY/CATCH` that only releases the application lock. If one of them fails, the call still returns `ReturnCode` = `OK`. Check `C_XMLLog.Status`/`Error` afterwards to verify the real result.\n- The informational message `XML with XMLLogKey {XMLLogKey} has been processed.` is raised with severity 1 and may appear as `SqlMessage`; it is not an error.\n- In the \"already in process\" case the XML **has** been parsed although `ReturnCode` is `ERROR API`.\n- The application locks `PixiItemImport` / `PixiOrderImport` (session owner) are shared with the SQL Agent import jobs; while the call holds the lock, the agent job cannot process at the same time.\n- The called procedures respect the settings `C_ItemImportEnabled`, `C_ItemImport_ParseAndCheckData_Enabled`, `C_OrderImportEnabled`, `C_OrderImport_ParseAndCheckData_Enabled`, `C_OrderImport_ApplyToMainTables_Enabled` and per-channel-type settings. If they are disabled, the steps do nothing, but the call still returns `OK`.\n- The parse steps only parse XMLs of channel type `URL` whose `Error` column is empty. XMLs of channel types `PlentyREST` or `ShipRush` are only reset to status `XIM` (with `AttemptsToProcess` = 0) so that the Integration Service parses them again.\n- The parse steps also do global work (e.g. `pixi_C_UpdateXMLsAsParsed`, exchange rate import for orders), and the order apply step calls `Pixi_AmazonOrdersMarkOrders`.\n- The setting `C_ParseAndImportDataIntervalMinutes` is read but not used.\n- `Pixi_C_ApplyItemsToMainTables` is not attached; its exact behaviour and returned rows are unknown.\n- Existence and status checks use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the change history of Pixi settings within a date range, newest changes first, optionally limited to a number of rows.\n\nReads the setting change log from the table `SettingsHist` and returns one row per logged change.\n\n- The effective change date of an entry is `UpdateDate`, or `CreateDate` if `UpdateDate` is empty. The same logic applies to the employee: `UpdateEmp`, otherwise `CreateEmp`.\n- Only entries whose effective change date lies between `FromDate` and `ToDate` (both inclusive) are returned.\n- If `FromDate` is omitted, `NULL` or has a year before 1990, it is set to `1970-01-01`, so there is no lower bound.\n- If `ToDate` is omitted, `NULL` or has a year before 1990, the current date and time is used.\n- The result is sorted by the effective change date in descending order (newest first).\n- If `Rows` is greater than 0, only that many rows are returned (via `SET ROWCOUNT`). With `0` (default) all matching rows are returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | No | Start of the date range (inclusive) for the effective change date. `NULL` or a year before 1990 means no lower bound (`1970-01-01`). |\n| `ToDate` | datetime | No | End of the date range (inclusive) for the effective change date. `NULL` or a year before 1990 means the current date and time. |\n| `Rows` | int | No | Maximum number of rows to return. `0` or less returns all matching rows. |\n\n- The table is read `WITH(NOLOCK)`, so uncommitted changes may appear.\n- `ToDate` is compared including the time part. A value such as `2024-03-31` (midnight) excludes changes made later on that day; pass `2024-03-31T23:59:59` or the following day to include the whole day.\n- Filtering on an `ISNULL` expression prevents index use on the date columns; on large history tables, narrow date ranges or a `Rows` limit are advisable.\n- The exact data types of the columns of `SettingsHist` are not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns the change history of Pixi settings within a date range, newest changes first, optionally limited to a number of rows.\n\nReads the setting change log from the table `SettingsHist` and returns one row per logged change.\n\n- The effective change date of an entry is `UpdateDate`, or `CreateDate` if `UpdateDate` is empty. The same logic applies to the employee: `UpdateEmp`, otherwise `CreateEmp`.\n- Only entries whose effective change date lies between `FromDate` and `ToDate` (both inclusive) are returned.\n- If `FromDate` is omitted, `NULL` or has a year before 1990, it is set to `1970-01-01`, so there is no lower bound.\n- If `ToDate` is omitted, `NULL` or has a year before 1990, the current date and time is used.\n- The result is sorted by the effective change date in descending order (newest first).\n- If `Rows` is greater than 0, only that many rows are returned (via `SET ROWCOUNT`). With `0` (default) all matching rows are returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | No | Start of the date range (inclusive) for the effective change date. `NULL` or a year before 1990 means no lower bound (`1970-01-01`). |\n| `ToDate` | datetime | No | End of the date range (inclusive) for the effective change date. `NULL` or a year before 1990 means the current date and time. |\n| `Rows` | int | No | Maximum number of rows to return. `0` or less returns all matching rows. |\n\n- The table is read `WITH(NOLOCK)`, so uncommitted changes may appear.\n- `ToDate` is compared including the time part. A value such as `2024-03-31` (midnight) excludes changes made later on that day; pass `2024-03-31T23:59:59` or the following day to include the whole day.\n- Filtering on an `ISNULL` expression prevents index use on the date columns; on large history tables, narrow date ranges or a `Rows` limit are advisable.\n- The exact data types of the columns of `SettingsHist` are not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns the input parameters of a Pixi API call with their names, data types and maximum lengths.\n\nLooks up the input parameters of an API call in the SQL Server catalog view `INFORMATION_SCHEMA.PARAMETERS` of the current database.\n\n1. Every occurrence of `pixi` in `procedure` is replaced by `pipi`. The SOAP name (`pixiItemSearch`) and the SQL name (`pipiItemSearch`) can therefore both be passed.\n2. If the resulting name does not start with `pipi`, a status row with `ErrNr` = `403` and `ErrMessage` = `No such API call` is returned.\n3. Then the parameters of the object are always returned:\n - only objects in the current database (`SPECIFIC_CATALOG = DB_NAME()`),\n - only parameters with `PARAMETER_MODE = 'IN'`,\n - the leading `@` is removed from the parameter name,\n - sorted by the declared parameter position.\n\nIf the call does not exist, the parameter result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `procedure` | varchar(50) | Yes | Name of the API call whose parameters are requested. Either the SOAP name (`pixi…`) or the SQL name (`pipi…`). |\n\n- After the error row the procedure does **not** stop. In that case two result sets are returned: the error row in `SqlRowSet1` and the (usually empty) parameter list in `SqlRowSet2`. Without an error the parameter list is `SqlRowSet1`.\n- Because execution continues, the parameters of a non-`pipi` object are still returned if an object with that name exists.\n- `REPLACE` affects every occurrence of `pixi` in the name, not only the prefix. Case sensitivity of the replacement and the prefix check depends on the database collation.\n- `OUTPUT` parameters (mode `INOUT`) and the return value of scalar functions are not listed. Default values and whether a parameter is required are not returned.\n- `CHARACTER_MAXIMUM_LENGTH` is `NULL` for non-character types and `-1` for `(max)` types.\n- Visibility in `INFORMATION_SCHEMA` depends on the permissions of the database user.\n- The catalog view is read with `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the input parameters of a Pixi API call with their names, data types and maximum lengths.\n\nLooks up the input parameters of an API call in the SQL Server catalog view `INFORMATION_SCHEMA.PARAMETERS` of the current database.\n\n1. Every occurrence of `pixi` in `procedure` is replaced by `pipi`. The SOAP name (`pixiItemSearch`) and the SQL name (`pipiItemSearch`) can therefore both be passed.\n2. If the resulting name does not start with `pipi`, a status row with `ErrNr` = `403` and `ErrMessage` = `No such API call` is returned.\n3. Then the parameters of the object are always returned:\n - only objects in the current database (`SPECIFIC_CATALOG = DB_NAME()`),\n - only parameters with `PARAMETER_MODE = 'IN'`,\n - the leading `@` is removed from the parameter name,\n - sorted by the declared parameter position.\n\nIf the call does not exist, the parameter result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `procedure` | varchar(50) | Yes | Name of the API call whose parameters are requested. Either the SOAP name (`pixi…`) or the SQL name (`pipi…`). |\n\n- After the error row the procedure does **not** stop. In that case two result sets are returned: the error row in `SqlRowSet1` and the (usually empty) parameter list in `SqlRowSet2`. Without an error the parameter list is `SqlRowSet1`.\n- Because execution continues, the parameters of a non-`pipi` object are still returned if an object with that name exists.\n- `REPLACE` affects every occurrence of `pixi` in the name, not only the prefix. Case sensitivity of the replacement and the prefix check depends on the database collation.\n- `OUTPUT` parameters (mode `INOUT`) and the return value of scalar functions are not listed. Default values and whether a parameter is required are not returned.\n- `CHARACTER_MAXIMUM_LENGTH` is `NULL` for non-character types and `-1` for `(max)` types.\n- Visibility in `INFORMATION_SCHEMA` depends on the permissions of the database user.\n- The catalog view is read with `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Returns code table values from pixi.CodeTableValue with their translated description, either a single value by Id or a page of values after a given Id.\n\nReads entries of the code table `pixi.CodeTableValue` together with their description text from `dbo.Translation`.\n\n1. If `Id` is not passed, it is set to `0`.\n2. Translations are loaded where `DBObjectName = 'CodeTableValue'` and `LanguageID = @LanguageId`. The translation is matched on the value's `Id`.\n3. The call then works in one of two modes:\n - **Paging mode** (`RowCount` is set): returns at most `RowCount` values with `Id > @Id`, sorted by `Id` ascending. Pass the last `Id` of a page as `Id` to read the next page. Start with `Id` = `0` or leave it out.\n - **Single mode** (`RowCount` is not set): returns the value with `Id = @Id`.\n\nThe join to the translations is an inner join. Values without a translation in the requested language are not returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Id` | int | No | Without `RowCount`: the `Id` of the code table value to return. With `RowCount`: values with an `Id` greater than this one are returned, which is used for paging. `NULL` is treated as `0`. |\n| `RowCount` | int | No | Maximum number of rows per page. If set, the call switches to paging mode (`Id > @Id`, sorted by `Id`). If `NULL`, a single value by `Id` is returned. |\n| `LanguageId` | int | No | Language of the description text (`LanguageID` in `dbo.Translation`). Only values with a translation in this language are returned. |\n\n- All reads use `NOLOCK`, so uncommitted data can appear.\n- If both `Id` and `RowCount` are left out, the call looks for the value with `Id = 0` and normally returns an empty result. To read all values, pass `RowCount`.\n- The code contains a third branch that returns an empty result set. It can never run, because `Id` is always set to `0` when it is `NULL`.\n- A negative `RowCount` causes a SQL error from `TOP`.\n- `LanguageId` defaults to `1`. Which language this ID stands for depends on the content of `dbo.Translation`.\n\nDocumentation: https://pixi-api-docs.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": "Returns code table values from pixi.CodeTableValue with their translated description, either a single value by Id or a page of values after a given Id.\n\nReads entries of the code table `pixi.CodeTableValue` together with their description text from `dbo.Translation`.\n\n1. If `Id` is not passed, it is set to `0`.\n2. Translations are loaded where `DBObjectName = 'CodeTableValue'` and `LanguageID = @LanguageId`. The translation is matched on the value's `Id`.\n3. The call then works in one of two modes:\n - **Paging mode** (`RowCount` is set): returns at most `RowCount` values with `Id > @Id`, sorted by `Id` ascending. Pass the last `Id` of a page as `Id` to read the next page. Start with `Id` = `0` or leave it out.\n - **Single mode** (`RowCount` is not set): returns the value with `Id = @Id`.\n\nThe join to the translations is an inner join. Values without a translation in the requested language are not returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Id` | int | No | Without `RowCount`: the `Id` of the code table value to return. With `RowCount`: values with an `Id` greater than this one are returned, which is used for paging. `NULL` is treated as `0`. |\n| `RowCount` | int | No | Maximum number of rows per page. If set, the call switches to paging mode (`Id > @Id`, sorted by `Id`). If `NULL`, a single value by `Id` is returned. |\n| `LanguageId` | int | No | Language of the description text (`LanguageID` in `dbo.Translation`). Only values with a translation in this language are returned. |\n\n- All reads use `NOLOCK`, so uncommitted data can appear.\n- If both `Id` and `RowCount` are left out, the call looks for the value with `Id = 0` and normally returns an empty result. To read all values, pass `RowCount`.\n- The code contains a third branch that returns an empty result set. It can never run, because `Id` is always set to `0` when it is `NULL`.\n- A negative `RowCount` causes a SQL error from `TOP`.\n- `LanguageId` defaults to `1`. Which language this ID stands for depends on the content of `dbo.Translation`.\n\nDocumentation: https://pixi-api-docs.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": "Returns entries of the Pixi translation table page by page, ordered by `TranslationKey`, starting after a given key.\n\nReads translation entries (language-specific texts) from the `Translation` table using keyset paging.\n\n- If `TranslationKey` is omitted or `NULL`, it is set to `0`, so reading starts at the beginning of the table.\n- If `RowCount` is omitted or `NULL`, it is set to `1000`.\n- The call returns at most `RowCount` rows whose `TranslationKey` is **greater than** the given `TranslationKey`, sorted by `TranslationKey` ascending.\n\nTo read all translations, start with `TranslationKey = 0` (or omit it). Then call again with the highest `TranslationKey` of the previous page until fewer than `RowCount` rows come back.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TranslationKey` | int | No | Paging cursor. Only entries with a `TranslationKey` greater than this value are returned. `NULL` is treated as `0`. |\n| `RowCount` | int | No | Maximum number of rows returned. `NULL` is treated as `1000`. |\n\n- Because both parameters are replaced by defaults when they are `NULL`, only the paging branch is ever executed. The code also contains branches for an exact lookup by `TranslationKey` and for an empty result, but these are unreachable.\n- Passing a specific `TranslationKey` does **not** return that entry. It returns the entries after it.\n- The table is read `WITH (NOLOCK)`, so uncommitted changes may be visible.\n- `RowCount = 0` returns no rows. A negative `RowCount` causes a SQL Server error from the `TOP` clause.\n- The column types are not visible in the code because the definition of the `Translation` table is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Returns entries of the Pixi translation table page by page, ordered by `TranslationKey`, starting after a given key.\n\nReads translation entries (language-specific texts) from the `Translation` table using keyset paging.\n\n- If `TranslationKey` is omitted or `NULL`, it is set to `0`, so reading starts at the beginning of the table.\n- If `RowCount` is omitted or `NULL`, it is set to `1000`.\n- The call returns at most `RowCount` rows whose `TranslationKey` is **greater than** the given `TranslationKey`, sorted by `TranslationKey` ascending.\n\nTo read all translations, start with `TranslationKey = 0` (or omit it). Then call again with the highest `TranslationKey` of the previous page until fewer than `RowCount` rows come back.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TranslationKey` | int | No | Paging cursor. Only entries with a `TranslationKey` greater than this value are returned. `NULL` is treated as `0`. |\n| `RowCount` | int | No | Maximum number of rows returned. `NULL` is treated as `1000`. |\n\n- Because both parameters are replaced by defaults when they are `NULL`, only the paging branch is ever executed. The code also contains branches for an exact lookup by `TranslationKey` and for an empty result, but these are unreachable.\n- Passing a specific `TranslationKey` does **not** return that entry. It returns the entries after it.\n- The table is read `WITH (NOLOCK)`, so uncommitted changes may be visible.\n- `RowCount = 0` returns no rows. A negative `RowCount` causes a SQL Server error from the `TOP` clause.\n- The column types are not visible in the code because the definition of the `Translation` table is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Refreshes the metadata of all non-schema-bound views and marks all stored procedures of the Pixi database for recompilation.\n\nMaintenance call without parameters. It works through the database objects in two passes:\n\n1. **Views:** All views (`type = 'V'`) in all schemas that are **not** schema-bound (`IsSchemaBound = 0`) are passed one by one to `sp_refreshview`. This updates their stored metadata, for example after columns of underlying tables have changed.\n2. **Stored procedures:** All stored procedures (`type = 'P'`) in all schemas are passed one by one to `sp_recompile`. Their cached execution plans are recompiled on their next execution.\n\nThe objects are addressed as `schema.name`.\n\nIf both passes finish, a single row with `Code = '200'` and `Text = 'OK'` is returned. If any step fails, processing stops at that point and a single row with `Code = '500'` and the SQL error message in `Text` is returned.\n\n- There is no transaction. Views refreshed before an error stay refreshed. If an error occurs during the view pass, no procedure is recompiled.\n- A single broken view stops the whole run. This can be a view that references a dropped table or column. The error is returned as a `500` row.\n- The cursors are not closed or deallocated in the error path. If they are global cursors (database default), they stay open for the connection. A later call on the same connection can then fail because a cursor named `cursor_views` or `cursor_procs` already exists.\n- `sp_refreshview` and `sp_recompile` require `ALTER` permission on each object. They also take schema locks. On a large database the call can run for a long time and block other sessions briefly.\n- Schema-bound views are skipped. Functions and triggers are not touched.\n- Recompiling all procedures causes extra compile load the next time each procedure runs.\n\nDocumentation: https://pixi-api-docs.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": "Refreshes the metadata of all non-schema-bound views and marks all stored procedures of the Pixi database for recompilation.\n\nMaintenance call without parameters. It works through the database objects in two passes:\n\n1. **Views:** All views (`type = 'V'`) in all schemas that are **not** schema-bound (`IsSchemaBound = 0`) are passed one by one to `sp_refreshview`. This updates their stored metadata, for example after columns of underlying tables have changed.\n2. **Stored procedures:** All stored procedures (`type = 'P'`) in all schemas are passed one by one to `sp_recompile`. Their cached execution plans are recompiled on their next execution.\n\nThe objects are addressed as `schema.name`.\n\nIf both passes finish, a single row with `Code = '200'` and `Text = 'OK'` is returned. If any step fails, processing stops at that point and a single row with `Code = '500'` and the SQL error message in `Text` is returned.\n\n- There is no transaction. Views refreshed before an error stay refreshed. If an error occurs during the view pass, no procedure is recompiled.\n- A single broken view stops the whole run. This can be a view that references a dropped table or column. The error is returned as a `500` row.\n- The cursors are not closed or deallocated in the error path. If they are global cursors (database default), they stay open for the connection. A later call on the same connection can then fail because a cursor named `cursor_views` or `cursor_procs` already exists.\n- `sp_refreshview` and `sp_recompile` require `ALTER` permission on each object. They also take schema locks. On a large database the call can run for a long time and block other sessions briefly.\n- Schema-bound views are skipped. Functions and triggers are not touched.\n- Recompiling all procedures causes extra compile load the next time each procedure runs.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new tag of a given tag type (for items or orders), unless a tag with the same type and name already exists.\n\nCreates a tag record in Pixi. Tags are used to label items or orders. The call returns one status row with `Status` and `Message`.\n\nSteps:\n\n1. **Validation.** `TypeID` must refer to an existing tag type and `Name` must not be empty. If validation fails, no tag is created and `Status` is `Error`. The checks are evaluated in this order:\n - both `TypeID` and `Name` missing\n - `TypeID` missing\n - no tag type with this `TypeID` exists\n - `Name` empty\n2. **Duplicate check.** The call counts the existing tags with the same `TypeID` and `Name`. If at least one exists, nothing is inserted and `Status` is `Information`.\n3. **Insert.** Otherwise a new tag is inserted with:\n - the given type and name\n - `Description`; `NULL` is stored as an empty string\n - `IsSystemTag` = 0\n\n `Status` is then `Success`.\n\nThe ID of the new tag is **not** returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TypeID` | int | No | ID of the tag type (`TagType.Id`). Effectively mandatory; it must refer to an existing tag type. |\n| `Name` | varchar(50) | No | Name of the new tag. Effectively mandatory; must not be empty. Together with `TypeID` it must be unique, otherwise no tag is created. |\n| `Description` | varchar(4000) | No | Optional description of the tag. `NULL` is stored as an empty string. |\n\n- **Transactions:** the call runs inside its own transaction. If it is called within an existing transaction, it uses a savepoint instead. `XACT_ABORT` is on.\n- **Error handling:** on an unexpected error the transaction is rolled back and the error is logged via `log.InsertError` (definition not attached). A status row with `Status` = `Error` is still returned; no SQL error is raised.\n- **Duplicates:** the tag type and duplicate checks read with `NOLOCK`. Concurrent calls with the same type and name may therefore both insert a tag, unless a unique constraint on `Tag` prevents this; such a constraint is not visible in the code.\n- **Name matching:** whether names are compared case-sensitively depends on the database collation.\n- **Message text:** in the 'already exists' message the name is cut to 20 characters.\n- **Tag ID:** the call does not return the ID of the new tag. It has to be read separately.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new tag of a given tag type (for items or orders), unless a tag with the same type and name already exists.\n\nCreates a tag record in Pixi. Tags are used to label items or orders. The call returns one status row with `Status` and `Message`.\n\nSteps:\n\n1. **Validation.** `TypeID` must refer to an existing tag type and `Name` must not be empty. If validation fails, no tag is created and `Status` is `Error`. The checks are evaluated in this order:\n - both `TypeID` and `Name` missing\n - `TypeID` missing\n - no tag type with this `TypeID` exists\n - `Name` empty\n2. **Duplicate check.** The call counts the existing tags with the same `TypeID` and `Name`. If at least one exists, nothing is inserted and `Status` is `Information`.\n3. **Insert.** Otherwise a new tag is inserted with:\n - the given type and name\n - `Description`; `NULL` is stored as an empty string\n - `IsSystemTag` = 0\n\n `Status` is then `Success`.\n\nThe ID of the new tag is **not** returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TypeID` | int | No | ID of the tag type (`TagType.Id`). Effectively mandatory; it must refer to an existing tag type. |\n| `Name` | varchar(50) | No | Name of the new tag. Effectively mandatory; must not be empty. Together with `TypeID` it must be unique, otherwise no tag is created. |\n| `Description` | varchar(4000) | No | Optional description of the tag. `NULL` is stored as an empty string. |\n\n- **Transactions:** the call runs inside its own transaction. If it is called within an existing transaction, it uses a savepoint instead. `XACT_ABORT` is on.\n- **Error handling:** on an unexpected error the transaction is rolled back and the error is logged via `log.InsertError` (definition not attached). A status row with `Status` = `Error` is still returned; no SQL error is raised.\n- **Duplicates:** the tag type and duplicate checks read with `NOLOCK`. Concurrent calls with the same type and name may therefore both insert a tag, unless a unique constraint on `Tag` prevents this; such a constraint is not visible in the code.\n- **Name matching:** whether names are compared case-sensitively depends on the database collation.\n- **Message text:** in the 'already exists' message the name is cut to 20 characters.\n- **Tag ID:** the call does not return the ID of the new tag. It has to be read separately.\n\nDocumentation: https://pixi-api-docs.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": "Deletes a tag, identified by its ID or by type and name, and removes all of its assignments to items or orders.\n\nDeletes one tag from `Tag` together with all of its assignments in `TagMatch`. Tags are used to label objects such as items (Artikel) or orders (Aufträge).\n\nThe tag can be identified in two ways:\n\n- by `TagId`, or\n- by the combination of `TypeId` and `Name`. Both values are required together.\n\nThe parameters are checked in this order:\n\n1. If all three parameters are missing, or only one of `TypeId` and `Name` is passed, the call returns an error about missing mandatory parameters.\n2. If `TagId` is passed but no tag with this ID exists, the call returns *Tag does not exist*.\n3. If `TagId` is not passed and no tag matches `TypeId` and `Name`, the call also returns *Tag does not exist*.\n4. If the tag found is a system tag (`IsSystemTag` = 1), it cannot be deleted.\n5. If `TagId` and `TypeId`/`Name` are all passed and point to two different tags, the call returns an error.\n\nIf all checks pass, the call first deletes every `TagMatch` row of the tag, which removes the tag from all assigned objects. It then deletes the tag itself. The call always returns a single row with `Status` and `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagId` | int | No | ID of the tag to delete. Alternative to the combination of `TypeId` and `Name`. |\n| `TypeId` | int | No | Type of the tag (`Tag.TypeId`). Must be passed together with `Name` if the tag is identified by name. |\n| `Name` | varchar(50) | No | Name of the tag (`Tag.Name`). Must be passed together with `TypeId`. |\n\n- The call runs in its own transaction. If a transaction is already open, it uses a savepoint instead. On an unexpected error the changes are rolled back, the error is logged via `log.InsertError` and `Status` = `Error` is returned with the first 80 characters of the SQL error message.\n- Errors are never raised as `SqlMessage`. Always evaluate the `Status` column.\n- Pitfall: if `TagId` is passed together with a `TypeId`/`Name` pair that matches no tag, the conflict check does not apply. In that case the tag with `TagId` is deleted.\n- Passing `TagId` together with only `TypeId` or only `Name` returns the missing-parameters error, even though `TagId` alone would be enough.\n- The checks read `Tag` with `NOLOCK`. The deletes use `ROWLOCK`.\n- The meaning of the `TypeId` values (for example item or order tags) is not defined in this code.\n\nDocumentation: https://pixi-api-docs.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": "Deletes a tag, identified by its ID or by type and name, and removes all of its assignments to items or orders.\n\nDeletes one tag from `Tag` together with all of its assignments in `TagMatch`. Tags are used to label objects such as items (Artikel) or orders (Aufträge).\n\nThe tag can be identified in two ways:\n\n- by `TagId`, or\n- by the combination of `TypeId` and `Name`. Both values are required together.\n\nThe parameters are checked in this order:\n\n1. If all three parameters are missing, or only one of `TypeId` and `Name` is passed, the call returns an error about missing mandatory parameters.\n2. If `TagId` is passed but no tag with this ID exists, the call returns *Tag does not exist*.\n3. If `TagId` is not passed and no tag matches `TypeId` and `Name`, the call also returns *Tag does not exist*.\n4. If the tag found is a system tag (`IsSystemTag` = 1), it cannot be deleted.\n5. If `TagId` and `TypeId`/`Name` are all passed and point to two different tags, the call returns an error.\n\nIf all checks pass, the call first deletes every `TagMatch` row of the tag, which removes the tag from all assigned objects. It then deletes the tag itself. The call always returns a single row with `Status` and `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagId` | int | No | ID of the tag to delete. Alternative to the combination of `TypeId` and `Name`. |\n| `TypeId` | int | No | Type of the tag (`Tag.TypeId`). Must be passed together with `Name` if the tag is identified by name. |\n| `Name` | varchar(50) | No | Name of the tag (`Tag.Name`). Must be passed together with `TypeId`. |\n\n- The call runs in its own transaction. If a transaction is already open, it uses a savepoint instead. On an unexpected error the changes are rolled back, the error is logged via `log.InsertError` and `Status` = `Error` is returned with the first 80 characters of the SQL error message.\n- Errors are never raised as `SqlMessage`. Always evaluate the `Status` column.\n- Pitfall: if `TagId` is passed together with a `TypeId`/`Name` pair that matches no tag, the conflict check does not apply. In that case the tag with `TagId` is deleted.\n- Passing `TagId` together with only `TypeId` or only `Name` returns the missing-parameters error, even though `TagId` alone would be enough.\n- The checks read `Tag` with `NOLOCK`. The deletes use `ROWLOCK`.\n- The meaning of the `TypeId` values (for example item or order tags) is not defined in this code.\n\nDocumentation: https://pixi-api-docs.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": "Returns tag definitions created within a date range, optionally filtered by tag type, together with the tag type name.\n\nReturns the tags defined in Pixi (table `Tag`) joined with their tag type (`TagType`).\n\n- `DateFrom` / `DateTo` filter on the creation date of the tag (`RecordCreatedOn`, inclusive on both ends). If `DateFrom` is omitted, the creation date of the oldest tag is used. If `DateTo` is omitted, the current date and time is used.\n- `TypeId` restricts the result to one tag type. If it is omitted, tags of all types are returned.\n- `RowCount` limits the number of rows (default 1000, also used if `NULL` is passed).\n\nOnly tags whose `TypeId` exists in `TagType` are returned (inner join). The result is sorted by `TagId` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `RowCount` | int | No | Maximum number of rows returned. `NULL` is treated as 1000. |\n| `DateFrom` | smalldatetime | No | Start of the creation date range (inclusive). If `NULL`, the creation date of the oldest tag is used. |\n| `DateTo` | smalldatetime | No | End of the creation date range (inclusive). If `NULL`, the current date and time is used. |\n| `TypeId` | int | No | ID of the tag type (`TagType.Id`) to filter on. `NULL` returns tags of all types. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- The date parameters are `smalldatetime` (minute precision); seconds are rounded.\n- There is no offset parameter. To page through many tags, narrow the date range or increase `RowCount`.\n- The call returns tag definitions only, not the assignments of tags to objects.\n\nDocumentation: https://pixi-api-docs.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": "Returns tag definitions created within a date range, optionally filtered by tag type, together with the tag type name.\n\nReturns the tags defined in Pixi (table `Tag`) joined with their tag type (`TagType`).\n\n- `DateFrom` / `DateTo` filter on the creation date of the tag (`RecordCreatedOn`, inclusive on both ends). If `DateFrom` is omitted, the creation date of the oldest tag is used. If `DateTo` is omitted, the current date and time is used.\n- `TypeId` restricts the result to one tag type. If it is omitted, tags of all types are returned.\n- `RowCount` limits the number of rows (default 1000, also used if `NULL` is passed).\n\nOnly tags whose `TypeId` exists in `TagType` are returned (inner join). The result is sorted by `TagId` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `RowCount` | int | No | Maximum number of rows returned. `NULL` is treated as 1000. |\n| `DateFrom` | smalldatetime | No | Start of the creation date range (inclusive). If `NULL`, the creation date of the oldest tag is used. |\n| `DateTo` | smalldatetime | No | End of the creation date range (inclusive). If `NULL`, the current date and time is used. |\n| `TypeId` | int | No | ID of the tag type (`TagType.Id`) to filter on. `NULL` returns tags of all types. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- The date parameters are `smalldatetime` (minute precision); seconds are rounded.\n- There is no offset parameter. To page through many tags, narrow the date range or increase `RowCount`.\n- The call returns tag definitions only, not the assignments of tags to objects.\n\nDocumentation: https://pixi-api-docs.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": "Assigns an existing tag to an item or an order, depending on the tag type, and returns a status row.\n\nCreates a tag assignment (a row in `TagMatch`) for the tag given in `TagId`.\n\nSteps:\n\n1. Reads the type of the tag from `Tag`. The type decides which object the tag can be assigned to:\n - `TypeId` = 1: item tag, `ItemId` is required and must exist as `ItemKey` in `items`.\n - `TypeId` = 2: order tag, `OrderNr` is required and must exist as `OrderNr` in `OrderHeader`. The order number is translated to the internal `OrderHeaderKey`.\n2. Checks whether the tag is already assigned to the given item or order.\n3. Validates in this order and stops at the first failure: missing `TagId`, unknown tag, missing `ItemId`/`OrderNr` for the tag type, unknown item/order, existing assignment.\n4. If all checks pass, inserts the assignment. For an item tag only the item is stored, for an order tag only the order header key is stored; the other parameter is ignored.\n\nThe call always returns one row with `Status` (`Success`, `Warning` or `Error`) and `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagId` | int | Yes | ID of the tag (`Tag.Id`) to assign. Its type determines whether `ItemId` or `OrderNr` is used. |\n| `OrderNr` | int | No | Order number (`OrderHeader.OrderNr`) the tag is assigned to. Required for order tags (`TypeId` = 2), ignored for item tags. |\n| `ItemId` | int | No | Internal item key (`items.ItemKey`) the tag is assigned to. Required for item tags (`TypeId` = 1), ignored for order tags. |\n\n- The work runs in its own transaction, or in a savepoint if the caller already has an open transaction. On an unexpected error the changes are rolled back, the error is logged via `log.InsertError` and a status row with `Unexpected error: \"…\"` (first 80 characters of the SQL error) is returned instead of a `SqlMessage`.\n- Lookups use `NOLOCK`, so the duplicate check can read uncommitted data; two concurrent calls could both pass the check.\n- The duplicate check matches the tag against the order **or** the item. If both `OrderNr` and `ItemId` are sent, an existing assignment to either one leads to the `Warning`, even if it does not belong to the tag type.\n- For tags whose `TypeId` is neither 1 nor 2 no item/order validation takes place and a `TagMatch` row with both `ItemId` and `OrderHeaderId` empty is inserted.\n- `OrderNr` is the visible order number, not the internal `OrderHeaderKey`; `ItemId` is the internal `ItemKey`.\n- The header comment of the procedure (\"Get tags for objects\") does not match its behaviour; the procedure writes data.\n\nDocumentation: https://pixi-api-docs.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": "Assigns an existing tag to an item or an order, depending on the tag type, and returns a status row.\n\nCreates a tag assignment (a row in `TagMatch`) for the tag given in `TagId`.\n\nSteps:\n\n1. Reads the type of the tag from `Tag`. The type decides which object the tag can be assigned to:\n - `TypeId` = 1: item tag, `ItemId` is required and must exist as `ItemKey` in `items`.\n - `TypeId` = 2: order tag, `OrderNr` is required and must exist as `OrderNr` in `OrderHeader`. The order number is translated to the internal `OrderHeaderKey`.\n2. Checks whether the tag is already assigned to the given item or order.\n3. Validates in this order and stops at the first failure: missing `TagId`, unknown tag, missing `ItemId`/`OrderNr` for the tag type, unknown item/order, existing assignment.\n4. If all checks pass, inserts the assignment. For an item tag only the item is stored, for an order tag only the order header key is stored; the other parameter is ignored.\n\nThe call always returns one row with `Status` (`Success`, `Warning` or `Error`) and `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagId` | int | Yes | ID of the tag (`Tag.Id`) to assign. Its type determines whether `ItemId` or `OrderNr` is used. |\n| `OrderNr` | int | No | Order number (`OrderHeader.OrderNr`) the tag is assigned to. Required for order tags (`TypeId` = 2), ignored for item tags. |\n| `ItemId` | int | No | Internal item key (`items.ItemKey`) the tag is assigned to. Required for item tags (`TypeId` = 1), ignored for order tags. |\n\n- The work runs in its own transaction, or in a savepoint if the caller already has an open transaction. On an unexpected error the changes are rolled back, the error is logged via `log.InsertError` and a status row with `Unexpected error: \"…\"` (first 80 characters of the SQL error) is returned instead of a `SqlMessage`.\n- Lookups use `NOLOCK`, so the duplicate check can read uncommitted data; two concurrent calls could both pass the check.\n- The duplicate check matches the tag against the order **or** the item. If both `OrderNr` and `ItemId` are sent, an existing assignment to either one leads to the `Warning`, even if it does not belong to the tag type.\n- For tags whose `TypeId` is neither 1 nor 2 no item/order validation takes place and a `TagMatch` row with both `ItemId` and `OrderHeaderId` empty is inserted.\n- `OrderNr` is the visible order number, not the internal `OrderHeaderKey`; `ItemId` is the internal `ItemKey`.\n- The header comment of the procedure (\"Get tags for objects\") does not match its behaviour; the procedure writes data.\n\nDocumentation: https://pixi-api-docs.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": "Renames a user-defined tag and optionally updates its description, returning a Status/Message row.\n\nUpdates an existing record in the `Tag` table, the tags that can be assigned to items or orders.\n\nSteps:\n\n1. Reads `IsSystemTag` and `TypeId` of the tag with the given `TagId`.\n2. Checks whether another tag with the same `Name` and the same `TypeId` already exists. Tags of other types may share the name.\n3. Validates the input in this order and stops at the first failure:\n - `TagId` must not be empty.\n - `Name` must not be NULL or an empty string.\n - The tag must not be a system tag (`IsSystemTag = 1`).\n - The tag must exist.\n - No other tag of the same type may already use the new name.\n4. If all checks pass, the tag is updated:\n - `Name` is set to `Name`.\n - `Description` is set to `Description`. If `Description` is NULL or left out, the current description is kept.\n - `RecordModifiedOn` is set to the current time.\n - `RecordModifiedByUserId` is set to the user `API`, or to `pixiAdministration` if no `API` user exists.\n - `RowVersion` is increased by 1.\n\nThe call always returns one row with `Status` (`Success` or `Error`) and `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagId` | int | No | ID of the tag to update. Effectively mandatory: if it is empty, an error row is returned. |\n| `Name` | varchar(50) | No | New name of the tag. Effectively mandatory; it must be unique among tags of the same type. |\n| `Description` | varchar(4000) | No | New description of the tag. If NULL, the current description is kept. |\n\n- Validation errors are not raised as SQL errors. They are returned as a row with `Status = 'Error'`, so check the `Status` column.\n- The update runs in its own transaction. If a transaction is already open, a savepoint is used instead. On an unexpected error the work is rolled back and the error is logged via `log.InsertError`. That object is not attached, so what it writes is not documented here.\n- The lookups for the existing tag and for duplicate names use `NOLOCK`. The update itself uses `ROWLOCK`.\n- `Name` is not trimmed. A name consisting only of spaces passes the empty check, because SQL Server ignores trailing spaces when comparing strings.\n- Passing an empty string as `Description` clears the description. Passing NULL or leaving the parameter out keeps the current description.\n- In unexpected error messages, the original SQL error text is cut to 80 characters.\n\nDocumentation: https://pixi-api-docs.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": "Renames a user-defined tag and optionally updates its description, returning a Status/Message row.\n\nUpdates an existing record in the `Tag` table, the tags that can be assigned to items or orders.\n\nSteps:\n\n1. Reads `IsSystemTag` and `TypeId` of the tag with the given `TagId`.\n2. Checks whether another tag with the same `Name` and the same `TypeId` already exists. Tags of other types may share the name.\n3. Validates the input in this order and stops at the first failure:\n - `TagId` must not be empty.\n - `Name` must not be NULL or an empty string.\n - The tag must not be a system tag (`IsSystemTag = 1`).\n - The tag must exist.\n - No other tag of the same type may already use the new name.\n4. If all checks pass, the tag is updated:\n - `Name` is set to `Name`.\n - `Description` is set to `Description`. If `Description` is NULL or left out, the current description is kept.\n - `RecordModifiedOn` is set to the current time.\n - `RecordModifiedByUserId` is set to the user `API`, or to `pixiAdministration` if no `API` user exists.\n - `RowVersion` is increased by 1.\n\nThe call always returns one row with `Status` (`Success` or `Error`) and `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagId` | int | No | ID of the tag to update. Effectively mandatory: if it is empty, an error row is returned. |\n| `Name` | varchar(50) | No | New name of the tag. Effectively mandatory; it must be unique among tags of the same type. |\n| `Description` | varchar(4000) | No | New description of the tag. If NULL, the current description is kept. |\n\n- Validation errors are not raised as SQL errors. They are returned as a row with `Status = 'Error'`, so check the `Status` column.\n- The update runs in its own transaction. If a transaction is already open, a savepoint is used instead. On an unexpected error the work is rolled back and the error is logged via `log.InsertError`. That object is not attached, so what it writes is not documented here.\n- The lookups for the existing tag and for duplicate names use `NOLOCK`. The update itself uses `ROWLOCK`.\n- `Name` is not trimmed. A name consisting only of spaces passes the empty check, because SQL Server ignores trailing spaces when comparing strings.\n- Passing an empty string as `Description` clears the description. Passing NULL or leaving the parameter out keeps the current description.\n- In unexpected error messages, the original SQL error text is cut to 80 characters.\n\nDocumentation: https://pixi-api-docs.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": "Creates a direct invoice for an order, either for all open orderlines or for a comma-separated list of orderline keys.\n\nThe call is a thin wrapper around the internal procedure `Pixi_CreateDirectInvInvoices`. It passes `LocID`, `CreateEmp`, `OrderNr` and `OrderlineRefs` and uses fixed values for everything else: no \"all items in stock\" check, no bin restriction, no 1SS (one-step-shipping) mode, result row enabled, own transaction, creation mode `Manual`, language 1.\n\n**Pre-checks (no result set, no invoice):**\n- If the order has no orderline in one of the open statuses `RAS`, `OPA`, `NAO`, `ANG`, `BES`, `BOR`, `NAS`, `OPH`, `NAD`, the call ends silently.\n- If `OrderlineRefs` is empty and any orderline of the order is on an active (not expired) picklist, the call ends silently.\n\n**Selection of orderlines:**\n- `OrderlineRefs` is split at commas; only numeric keys > 0 are used. If it is empty, all orderlines of the order are used.\n- Only orderlines of `OrderNr` in the open statuses listed above plus `MIN` are invoiced, and only if they are not already on an invoice line.\n- The customer must not be locked (`SLocked`) and the shipping address must not be locked (`ASlocked`); otherwise nothing is created.\n\n**Invoice creation:**\n1. Depending on the setting `DoNotReleaseStockOnDirectInvoiceScanOut` (value `0`), a picklist for the selected orderlines is created internally (partial orders and partial quantities allowed) and marked with the comment `DirectInvStockRelease`.\n2. Within a transaction the invoice header is created (VAT type `I`, or `N` if the billing address has a VAT ID or the customer has `TaxOnInvoice = 'N'`), the exchange rate and a return tracking ID are determined and SEPA data is added.\n3. Invoice lines are copied from the orderlines (quantity, price, discount, VAT, shipping cost, currency, serial number).\n4. The invoice gets the next invoice number of the shop and a package gross weight (setting `DefaultShippingWeight`, or calculated from item weights if `CalculateWeightFromItems = 1`).\n5. Invoiced open orderlines get status `EIN` and the invoice reference; `MIN` lines only get the invoice reference.\n6. If `Invoice_CancelPartialDelivery = 1`, remaining `ANG`/`HAL`/`BOR` lines of orders flagged for forced partial shipping with cancellation are set to `STO`.\n7. If the shipping vendor (`DoScanOutOnInvoiceCreate`) or the payment method (`AutoScanOutInvoice`) requires it, a box is created and scanned out, and a stock release job is queued.\n8. The event `InvoiceCreated` is published.\n\nOne status row is returned at the end (see result sets).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | No | Location ID used for the internal picklist and box/scan-out handling. |\n| `CreateEmp` | varchar(50) | No | User name stored as creator of the invoice and as updater of the orderlines. |\n| `OrderNr` | int | Yes | Number of the order to invoice. |\n| `OrderlineRefs` | varchar(2000) | Yes | Comma-separated orderline keys to invoice, e.g. `,1234,1235,`. Empty string means all eligible orderlines of the order. Keys not belonging to the order are ignored. |\n\n- `OrderlineRefs` has no default and must be sent; an empty string (or NULL) means \"all eligible orderlines\". The documented format is `,1234,1235,`.\n- **Silent exits:** in the two pre-check cases the call returns no row at all. If the customer or shipping address is locked, the final row reports `Success = 1` but `InvoiceKey = 0` and `CreatedInv = 0`; check `CreatedInv`/`InvoiceKey` rather than only `Success`.\n- On an error inside the invoice transaction, everything is rolled back, the internal picklist is deleted, the error is logged (`LOG.InsertError`), a row with four columns is returned and the error is re-raised via `sp_Exception_ReRaise` (not attached), so the client also receives a `SqlMessage`.\n- An error while creating the internal picklist is not re-raised; it is returned in `ErrorMessage` of the final row with `Success = 0`.\n- `LocID` is used for picklist and box handling; the invoice location is taken from the orderlines.\n- Behaviour depends on the settings `DoNotReleaseStockOnDirectInvoiceScanOut`, `DefaultShippingWeight`, `CalculateWeightFromItems`, `PutThisStatusesOnInvoice`, `Invoice_CancelPartialDelivery` and `1SS_ForceAutoScanOut`.\n- Side effects: MQ event `InvoiceCreated`, a queued `Pixi_ReleaseStockFrominvoicePicklist` entry in `ExecQueries` when scan-out runs, duration logging via `LOG.EventDurationInsert`. Many reads use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Creates a direct invoice for an order, either for all open orderlines or for a comma-separated list of orderline keys.\n\nThe call is a thin wrapper around the internal procedure `Pixi_CreateDirectInvInvoices`. It passes `LocID`, `CreateEmp`, `OrderNr` and `OrderlineRefs` and uses fixed values for everything else: no \"all items in stock\" check, no bin restriction, no 1SS (one-step-shipping) mode, result row enabled, own transaction, creation mode `Manual`, language 1.\n\n**Pre-checks (no result set, no invoice):**\n- If the order has no orderline in one of the open statuses `RAS`, `OPA`, `NAO`, `ANG`, `BES`, `BOR`, `NAS`, `OPH`, `NAD`, the call ends silently.\n- If `OrderlineRefs` is empty and any orderline of the order is on an active (not expired) picklist, the call ends silently.\n\n**Selection of orderlines:**\n- `OrderlineRefs` is split at commas; only numeric keys > 0 are used. If it is empty, all orderlines of the order are used.\n- Only orderlines of `OrderNr` in the open statuses listed above plus `MIN` are invoiced, and only if they are not already on an invoice line.\n- The customer must not be locked (`SLocked`) and the shipping address must not be locked (`ASlocked`); otherwise nothing is created.\n\n**Invoice creation:**\n1. Depending on the setting `DoNotReleaseStockOnDirectInvoiceScanOut` (value `0`), a picklist for the selected orderlines is created internally (partial orders and partial quantities allowed) and marked with the comment `DirectInvStockRelease`.\n2. Within a transaction the invoice header is created (VAT type `I`, or `N` if the billing address has a VAT ID or the customer has `TaxOnInvoice = 'N'`), the exchange rate and a return tracking ID are determined and SEPA data is added.\n3. Invoice lines are copied from the orderlines (quantity, price, discount, VAT, shipping cost, currency, serial number).\n4. The invoice gets the next invoice number of the shop and a package gross weight (setting `DefaultShippingWeight`, or calculated from item weights if `CalculateWeightFromItems = 1`).\n5. Invoiced open orderlines get status `EIN` and the invoice reference; `MIN` lines only get the invoice reference.\n6. If `Invoice_CancelPartialDelivery = 1`, remaining `ANG`/`HAL`/`BOR` lines of orders flagged for forced partial shipping with cancellation are set to `STO`.\n7. If the shipping vendor (`DoScanOutOnInvoiceCreate`) or the payment method (`AutoScanOutInvoice`) requires it, a box is created and scanned out, and a stock release job is queued.\n8. The event `InvoiceCreated` is published.\n\nOne status row is returned at the end (see result sets).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | No | Location ID used for the internal picklist and box/scan-out handling. |\n| `CreateEmp` | varchar(50) | No | User name stored as creator of the invoice and as updater of the orderlines. |\n| `OrderNr` | int | Yes | Number of the order to invoice. |\n| `OrderlineRefs` | varchar(2000) | Yes | Comma-separated orderline keys to invoice, e.g. `,1234,1235,`. Empty string means all eligible orderlines of the order. Keys not belonging to the order are ignored. |\n\n- `OrderlineRefs` has no default and must be sent; an empty string (or NULL) means \"all eligible orderlines\". The documented format is `,1234,1235,`.\n- **Silent exits:** in the two pre-check cases the call returns no row at all. If the customer or shipping address is locked, the final row reports `Success = 1` but `InvoiceKey = 0` and `CreatedInv = 0`; check `CreatedInv`/`InvoiceKey` rather than only `Success`.\n- On an error inside the invoice transaction, everything is rolled back, the internal picklist is deleted, the error is logged (`LOG.InsertError`), a row with four columns is returned and the error is re-raised via `sp_Exception_ReRaise` (not attached), so the client also receives a `SqlMessage`.\n- An error while creating the internal picklist is not re-raised; it is returned in `ErrorMessage` of the final row with `Success = 0`.\n- `LocID` is used for picklist and box handling; the invoice location is taken from the orderlines.\n- Behaviour depends on the settings `DoNotReleaseStockOnDirectInvoiceScanOut`, `DefaultShippingWeight`, `CalculateWeightFromItems`, `PutThisStatusesOnInvoice`, `Invoice_CancelPartialDelivery` and `1SS_ForceAutoScanOut`.\n- Side effects: MQ event `InvoiceCreated`, a queued `Pixi_ReleaseStockFrominvoicePicklist` entry in `ExecQueries` when scan-out runs, duration logging via `LOG.EventDurationInsert`. Many reads use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Creates a direct invoice (Rechnung) for an order, either for selected order lines or for all open lines, and returns the result as a status row.\n\nWrapper around the internal procedure `Pixi_CreateDirectInvInvoices`. It always uses `CreationMode = 'Direct'` and language 1. The 1SS, bin and best-before options of the internal procedure are not used.\n\n**Processing steps**\n\n1. **Open lines check.** If the order has no order line in one of the statuses `RAS`, `OPA`, `NAO`, `ANG`, `BES`, `BOR`, `NAS`, `OPH`, `NAD` (for example only `MIN` lines), the call stops without a result set.\n2. **Line selection.** `OrderlineRefs` is split at commas into order line keys. An empty or NULL value means *all eligible lines of the order*.\n3. **Active picklist check.** If `OrderlineRefs` is empty and any line of the order is on an active picklist (`PLitem.Expired = 0`), the call stops without a result set.\n4. **Customer and address check.** Customer, billing address, shipping address, ship vendor and currency are read from `OrderHeader`. No invoice is created if the customer (`SLocked`) or the shipping address (`ASlocked`) is locked.\n5. **Picklist for stock release.** If setting `DoNotReleaseStockOnDirectInvoiceScanOut` is `'0'` or `AllInvoiceItemsInStock = 'Y'`, a picklist is created for the selected lines (partial orders and partial quantities allowed).\n - With `AllInvoiceItemsInStock = 'Y'`, the picklist is deleted and no invoice is created if it is empty or if the picked quantity differs from the sum of the ordered quantities.\n - If the setting is `'1'`, the picklist is deleted again after the check.\n6. **Invoice creation (in a transaction).**\n - The invoice header is created. VAT type is `N` if the billing address has a VAT ID (`UsStID`) or the customer has `TaxOnInvoice = 'N'`, otherwise `I`.\n - The exchange rate, return tracking ID and SEPA data are determined.\n - Invoice lines are inserted for the selected lines in the statuses above plus `MIN` that are not yet invoiced.\n - The next invoice number of the shop is assigned. The package weight is the setting `DefaultShippingWeight`, or the sum of item weights if `CalculateWeightFromItems = 1`, capped at 999999.999.\n7. **Order line update.** Invoiced non-`MIN` lines get `InvRef` and status `EIN`. `MIN` lines get only `InvRef`.\n8. **Cancel remaining lines.** If setting `Invoice_CancelPartialDelivery = '1'`, remaining `ANG`/`HAL`/`BOR` lines of orders with `ForceToPickListIfNotFULL = 1` and `OHCancelAfterForcedShipOut = 1` are set to `STO`.\n9. **Automatic scan-out.** If the ship vendor (`DoScanOutOnInvoiceCreate`) or the payment method (`AutoScanOutInvoice`) requests it:\n - a box is created and scanned out;\n - a stock release job is queued in `ExecQueries`;\n - the box is deleted if setting `1SS_ForceAutoScanOut = 1`, and `ScanOutDone` becomes 1.\n10. **Event.** The MQ event `InvoiceCreated` is published and the transaction is committed.\n\nThe call finally returns one status row with `Success`, `InvoiceKey`, `CreatedInv` and `InvoicePackageId`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Order number (`OrderHeader.OrderNr`) to invoice. |\n| `OrderlineRefs` | varchar(2000) | Yes | Comma-separated order line keys (`OrderlineKey`) to invoice, enclosed in commas, e.g. `,1234,1235,`. An empty string or NULL invoices all eligible lines of the order. |\n| `AllInvoiceItemsInStock` | varchar(1) | No | If `Y`, the invoice is only created when all selected lines can be fully picked from stock. NULL is treated as `N`. |\n| `LocID` | varchar(3) | No | Location ID used for picklist creation, box creation and scan-out. |\n| `CreateEmp` | varchar(50) | No | User name stored as creator of the invoice, invoice lines and order line updates. |\n\n- **No result set in some cases.** The call returns no result set at all if the order has no open (non-`MIN`) lines, if `OrderlineRefs` is empty and part of the order is on an active picklist, or if `AllInvoiceItemsInStock = 'Y'` and the picked quantity does not match. Clients must handle a missing `SqlRowSet1`.\n- **`Success = 1` does not guarantee an invoice.** In these cases `InvoiceKey`/`CreatedInv` stay 0:\n - the customer or the shipping address is locked;\n - no eligible lines were found;\n - the picklist was empty with `AllInvoiceItemsInStock = 'Y'`.\n Always check `CreatedInv > 0`.\n- **Errors are reported twice.** If an error occurs during invoice creation:\n - the transaction is rolled back and the error is logged via `LOG.InsertError`;\n - the picklist is deleted;\n - a row with `Success = 0` is returned;\n - the error is then re-raised (`sp_Exception_ReRaise`), so a `SqlMessage` is also returned.\n- **`OrderlineRefs` format.** The value must be comma-separated, e.g. `,1234,1235,`. Only numeric elements greater than 0 are used.\n- **`LocID`.** Used for picklist creation and scan-out only. The invoice location comes from the order lines (`LocationID`).\n- **Side effects:**\n - picklists may be created and deleted;\n - a job `Pixi_ReleaseStockFrominvoicePicklist` is queued in `ExecQueries` on auto scan-out;\n - the MQ event `InvoiceCreated` is published;\n - `Pixi_CA_AddPixiInvoice` is executed;\n - duration logging is written via `LOG.EventDurationInsert`.\n- **Settings read at runtime:** `DoNotReleaseStockOnDirectInvoiceScanOut`, `DefaultShippingWeight`, `CalculateWeightFromItems`, `PutThisStatusesOnInvoice`, `Invoice_CancelPartialDelivery`, `1SS_ForceAutoScanOut`.\n- **Not attached.** The behaviour of the called procedures (e.g. `Pixi_CreatePickList`, `GOS_Qi_InvoiceNOD`, `Pixi_ScanOutBox`) is not attached and may raise further errors.\n- **Locking.** Most reads use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Creates a direct invoice (Rechnung) for an order, either for selected order lines or for all open lines, and returns the result as a status row.\n\nWrapper around the internal procedure `Pixi_CreateDirectInvInvoices`. It always uses `CreationMode = 'Direct'` and language 1. The 1SS, bin and best-before options of the internal procedure are not used.\n\n**Processing steps**\n\n1. **Open lines check.** If the order has no order line in one of the statuses `RAS`, `OPA`, `NAO`, `ANG`, `BES`, `BOR`, `NAS`, `OPH`, `NAD` (for example only `MIN` lines), the call stops without a result set.\n2. **Line selection.** `OrderlineRefs` is split at commas into order line keys. An empty or NULL value means *all eligible lines of the order*.\n3. **Active picklist check.** If `OrderlineRefs` is empty and any line of the order is on an active picklist (`PLitem.Expired = 0`), the call stops without a result set.\n4. **Customer and address check.** Customer, billing address, shipping address, ship vendor and currency are read from `OrderHeader`. No invoice is created if the customer (`SLocked`) or the shipping address (`ASlocked`) is locked.\n5. **Picklist for stock release.** If setting `DoNotReleaseStockOnDirectInvoiceScanOut` is `'0'` or `AllInvoiceItemsInStock = 'Y'`, a picklist is created for the selected lines (partial orders and partial quantities allowed).\n - With `AllInvoiceItemsInStock = 'Y'`, the picklist is deleted and no invoice is created if it is empty or if the picked quantity differs from the sum of the ordered quantities.\n - If the setting is `'1'`, the picklist is deleted again after the check.\n6. **Invoice creation (in a transaction).**\n - The invoice header is created. VAT type is `N` if the billing address has a VAT ID (`UsStID`) or the customer has `TaxOnInvoice = 'N'`, otherwise `I`.\n - The exchange rate, return tracking ID and SEPA data are determined.\n - Invoice lines are inserted for the selected lines in the statuses above plus `MIN` that are not yet invoiced.\n - The next invoice number of the shop is assigned. The package weight is the setting `DefaultShippingWeight`, or the sum of item weights if `CalculateWeightFromItems = 1`, capped at 999999.999.\n7. **Order line update.** Invoiced non-`MIN` lines get `InvRef` and status `EIN`. `MIN` lines get only `InvRef`.\n8. **Cancel remaining lines.** If setting `Invoice_CancelPartialDelivery = '1'`, remaining `ANG`/`HAL`/`BOR` lines of orders with `ForceToPickListIfNotFULL = 1` and `OHCancelAfterForcedShipOut = 1` are set to `STO`.\n9. **Automatic scan-out.** If the ship vendor (`DoScanOutOnInvoiceCreate`) or the payment method (`AutoScanOutInvoice`) requests it:\n - a box is created and scanned out;\n - a stock release job is queued in `ExecQueries`;\n - the box is deleted if setting `1SS_ForceAutoScanOut = 1`, and `ScanOutDone` becomes 1.\n10. **Event.** The MQ event `InvoiceCreated` is published and the transaction is committed.\n\nThe call finally returns one status row with `Success`, `InvoiceKey`, `CreatedInv` and `InvoicePackageId`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Order number (`OrderHeader.OrderNr`) to invoice. |\n| `OrderlineRefs` | varchar(2000) | Yes | Comma-separated order line keys (`OrderlineKey`) to invoice, enclosed in commas, e.g. `,1234,1235,`. An empty string or NULL invoices all eligible lines of the order. |\n| `AllInvoiceItemsInStock` | varchar(1) | No | If `Y`, the invoice is only created when all selected lines can be fully picked from stock. NULL is treated as `N`. |\n| `LocID` | varchar(3) | No | Location ID used for picklist creation, box creation and scan-out. |\n| `CreateEmp` | varchar(50) | No | User name stored as creator of the invoice, invoice lines and order line updates. |\n\n- **No result set in some cases.** The call returns no result set at all if the order has no open (non-`MIN`) lines, if `OrderlineRefs` is empty and part of the order is on an active picklist, or if `AllInvoiceItemsInStock = 'Y'` and the picked quantity does not match. Clients must handle a missing `SqlRowSet1`.\n- **`Success = 1` does not guarantee an invoice.** In these cases `InvoiceKey`/`CreatedInv` stay 0:\n - the customer or the shipping address is locked;\n - no eligible lines were found;\n - the picklist was empty with `AllInvoiceItemsInStock = 'Y'`.\n Always check `CreatedInv > 0`.\n- **Errors are reported twice.** If an error occurs during invoice creation:\n - the transaction is rolled back and the error is logged via `LOG.InsertError`;\n - the picklist is deleted;\n - a row with `Success = 0` is returned;\n - the error is then re-raised (`sp_Exception_ReRaise`), so a `SqlMessage` is also returned.\n- **`OrderlineRefs` format.** The value must be comma-separated, e.g. `,1234,1235,`. Only numeric elements greater than 0 are used.\n- **`LocID`.** Used for picklist creation and scan-out only. The invoice location comes from the order lines (`LocationID`).\n- **Side effects:**\n - picklists may be created and deleted;\n - a job `Pixi_ReleaseStockFrominvoicePicklist` is queued in `ExecQueries` on auto scan-out;\n - the MQ event `InvoiceCreated` is published;\n - `Pixi_CA_AddPixiInvoice` is executed;\n - duration logging is written via `LOG.EventDurationInsert`.\n- **Settings read at runtime:** `DoNotReleaseStockOnDirectInvoiceScanOut`, `DefaultShippingWeight`, `CalculateWeightFromItems`, `PutThisStatusesOnInvoice`, `Invoice_CancelPartialDelivery`, `1SS_ForceAutoScanOut`.\n- **Not attached.** The behaviour of the called procedures (e.g. `Pixi_CreatePickList`, `GOS_Qi_InvoiceNOD`, `Pixi_ScanOutBox`) is not attached and may raise further errors.\n- **Locking.** Most reads use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Creates an invoice for a packed box (BoxNr at a location) and returns the new invoice ID and number together with a status row.\n\nCreates the invoice for the contents of one box and always returns exactly one status row.\n\n1. If `BoxNr` or `LocId` is `NULL`, an error row is returned. An empty `UserName` is replaced by `API`.\n2. The box is checked for invoice eligibility with the internal procedure `GOS_BoxesRange` (range `BoxNr`..`BoxNr` at `LocId`). The box is eligible if all of the following apply:\n - it is not yet marked as sent (`WaitForSend` <> `Y`), or it is physically full and contains items without invoice lines;\n - the customer has no ship lock (`SLocked` not `Y`/`1`);\n - no ship address of the order lines in the box has a ship lock (`ASlocked`);\n - the box number is not the location's own box number (`LocBoxNumber`);\n - if order lines in the box have a confirmation date (`ConfDate`), at least one of them is today.\n3. If the box is not eligible, the call tries to find the reason and returns an error row: box not found at this location, box empty, invoice already exists, ship lock on an order address, ship lock on the customer; otherwise a generic \"Invoice creation failed.\" (this also covers the `ConfDate` and location box number rules).\n4. If eligible, the internal procedure `Pixi_CreateInv` creates the invoice with creation mode `API` and language ID `1`. It:\n - marks the box as sent (`WaitForSend = 'Y'`) and locks it against double invoicing;\n - inserts the invoice header (`Invoices`) and one invoice line (`Invlines`) per box item; additionally, not yet invoiced order lines of the same order with status `MIN` or a status listed in the setting `PutThisStatusesOnInvoice`;\n - sets `Orderlines.InvRef`, assigns the final invoice number per shop, the gross weight, a return tracking ID and an `InvoicePackage` record;\n - optionally scans the box out, cancels open partial deliveries, books the invoice on the customer account and publishes the `InvoiceCreated` event.\n If the box already has a draft invoice (`InvoiceStatusId = 0`), that draft is finalized instead (creation mode `MobileShipOut`).\n5. Result: on success a row with `InvoiceId`, `InvoiceNr` and `Status = 'SUCCESS'`; on failure `InvoiceId`/`InvoiceNr` are `NULL` and `Status`/`Message` contain the error.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BoxNr` | int | Yes | Number of the packed box to invoice. |\n| `LocId` | varchar(3) | Yes | Location (warehouse) ID the box belongs to. |\n| `UserName` | varchar(50) | No | User name stored as creator of the invoice and its lines. Empty or NULL is replaced by `API`. |\n\n- Invoice creation runs in its own transaction (or a savepoint if the caller already has one). On deadlock (1205) or duplicate key (2601) it is retried up to 5 times; retries and errors are written to `LogTable` and the error log.\n- Pre-checks use `NOLOCK`; the final protection against double invoices is the `UPDLOCK` on the box inside `Pixi_CreateInv`.\n- The status value differs in case: pre-check errors return `Error`, errors from the invoice creation return `ERROR` (taken from the internal result).\n- Pitfall: some internal errors (e.g. \"ERROR CREATING INVOICE Invoice Total empty\", foreign key errors such as orders of different customers in one box) are caught inside `Pixi_CreateInv` without setting its error message. In that case this call returns `Status = 'SUCCESS'` with `InvoiceId`/`InvoiceNr` = `NULL`. Always check that `InvoiceId` is not `NULL`.\n- Behaviour depends on settings read at runtime: `PutThisStatusesOnInvoice`, `Enforce_CheckKuhlung` (shipping cost adjustment for chilled items), `DefaultShippingWeight`, `CalculateWeightFromItems`, `Invoice_CancelPartialDelivery` (open lines with status `ANG`, `HAL`, `BOR` are set to `STO`).\n- Scan-out happens automatically if the ship vendor (`DoScanOutOnInvoiceCreate`) or payment method (`AutoScanOutInvoice`) requests it.\n- The draft finalization path (`Pixi_CreateInvoiceFromDraft`) is not attached; its exact behaviour and messages are not documented here.\n- The error text for missing parameters mentions the user name, but only `BoxNr` and `LocId` are checked.\n\nDocumentation: https://pixi-api-docs.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": "Creates an invoice for a packed box (BoxNr at a location) and returns the new invoice ID and number together with a status row.\n\nCreates the invoice for the contents of one box and always returns exactly one status row.\n\n1. If `BoxNr` or `LocId` is `NULL`, an error row is returned. An empty `UserName` is replaced by `API`.\n2. The box is checked for invoice eligibility with the internal procedure `GOS_BoxesRange` (range `BoxNr`..`BoxNr` at `LocId`). The box is eligible if all of the following apply:\n - it is not yet marked as sent (`WaitForSend` <> `Y`), or it is physically full and contains items without invoice lines;\n - the customer has no ship lock (`SLocked` not `Y`/`1`);\n - no ship address of the order lines in the box has a ship lock (`ASlocked`);\n - the box number is not the location's own box number (`LocBoxNumber`);\n - if order lines in the box have a confirmation date (`ConfDate`), at least one of them is today.\n3. If the box is not eligible, the call tries to find the reason and returns an error row: box not found at this location, box empty, invoice already exists, ship lock on an order address, ship lock on the customer; otherwise a generic \"Invoice creation failed.\" (this also covers the `ConfDate` and location box number rules).\n4. If eligible, the internal procedure `Pixi_CreateInv` creates the invoice with creation mode `API` and language ID `1`. It:\n - marks the box as sent (`WaitForSend = 'Y'`) and locks it against double invoicing;\n - inserts the invoice header (`Invoices`) and one invoice line (`Invlines`) per box item; additionally, not yet invoiced order lines of the same order with status `MIN` or a status listed in the setting `PutThisStatusesOnInvoice`;\n - sets `Orderlines.InvRef`, assigns the final invoice number per shop, the gross weight, a return tracking ID and an `InvoicePackage` record;\n - optionally scans the box out, cancels open partial deliveries, books the invoice on the customer account and publishes the `InvoiceCreated` event.\n If the box already has a draft invoice (`InvoiceStatusId = 0`), that draft is finalized instead (creation mode `MobileShipOut`).\n5. Result: on success a row with `InvoiceId`, `InvoiceNr` and `Status = 'SUCCESS'`; on failure `InvoiceId`/`InvoiceNr` are `NULL` and `Status`/`Message` contain the error.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BoxNr` | int | Yes | Number of the packed box to invoice. |\n| `LocId` | varchar(3) | Yes | Location (warehouse) ID the box belongs to. |\n| `UserName` | varchar(50) | No | User name stored as creator of the invoice and its lines. Empty or NULL is replaced by `API`. |\n\n- Invoice creation runs in its own transaction (or a savepoint if the caller already has one). On deadlock (1205) or duplicate key (2601) it is retried up to 5 times; retries and errors are written to `LogTable` and the error log.\n- Pre-checks use `NOLOCK`; the final protection against double invoices is the `UPDLOCK` on the box inside `Pixi_CreateInv`.\n- The status value differs in case: pre-check errors return `Error`, errors from the invoice creation return `ERROR` (taken from the internal result).\n- Pitfall: some internal errors (e.g. \"ERROR CREATING INVOICE Invoice Total empty\", foreign key errors such as orders of different customers in one box) are caught inside `Pixi_CreateInv` without setting its error message. In that case this call returns `Status = 'SUCCESS'` with `InvoiceId`/`InvoiceNr` = `NULL`. Always check that `InvoiceId` is not `NULL`.\n- Behaviour depends on settings read at runtime: `PutThisStatusesOnInvoice`, `Enforce_CheckKuhlung` (shipping cost adjustment for chilled items), `DefaultShippingWeight`, `CalculateWeightFromItems`, `Invoice_CancelPartialDelivery` (open lines with status `ANG`, `HAL`, `BOR` are set to `STO`).\n- Scan-out happens automatically if the ship vendor (`DoScanOutOnInvoiceCreate`) or payment method (`AutoScanOutInvoice`) requests it.\n- The draft finalization path (`Pixi_CreateInvoiceFromDraft`) is not attached; its exact behaviour and messages are not documented here.\n- The error text for missing parameters mentions the user name, but only `BoxNr` and `LocId` are checked.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new POS invoice, or adds lines to an open one, from an XML document and books the sold items out of stock.\n\nCreates a point-of-sale (POS) invoice for a cash register. All data is passed in one XML document in `XML`.\n\n**Parsing**\n- Header from `POSINVOICE/HEADER`: `REGISTERID` (required), `POSHEADERKEY` (optional, an existing invoice to extend), `COMMENT`, `CUSTOMERNREXTERNAL` (optional) and `GENERALBIN` (optional general POS bin).\n- Lines from `POSINVOICE/LINES/LINE`: `ITEMNRINT`, `QUANTITY`, `PRICE`, `DISCOUNTPERCENT` (default 0) and `BIN` (preferred bin, default empty). `COMMAND` is read but not used.\n\n**Lookups**\n- The customer is looked up by `Customers.CustomerNrExternal`; its address key is stored on the invoice.\n- The open POS session (`EndTime` is NULL) of the register with the latest `StartTime` supplies the location, the session ID and the user name.\n- Each line's item is looked up by `ItemNrInt`; the item's EAN/UPC is taken over.\n\n**Validation** (in this order; the first failure ends the call with an `ERROR` row)\n1. `REGISTERID` is present.\n2. If `POSHEADERKEY` is given, the invoice exists in `POSheader2` and its status is not `CLO` or `STO`.\n3. An open POS session exists for the register.\n4. All items exist.\n5. If `CUSTOMERNREXTERNAL` is given, the customer exists.\n6. No quantity is negative.\n7. `DISCOUNTPERCENT` is between 0 and 100.\n\n**Execution** (in one transaction)\n- Without `POSHEADERKEY` a new invoice header is created with the internal procedure `Pixi_POSNewInvoice` (document type `INV`). That procedure also records a session event and publishes the MQ event `POSInoviceCreated`.\n- The header is updated: customer address, `InvoiceComment`, update user and update date.\n- For every line:\n - A `POSitem2` row is inserted with quantity, price, discount and EAN/UPC.\n - Take-out bins are suggested with `BIN` as priority bin and `GENERALBIN` as general bin, in ascending order.\n - The suggestions are stored in `POSItemBinSelection`.\n - The stock is booked out of the bins (action type 4, stock movement refs `SMORef` 15 / `SMTRef` 12).\n - If the booking fails for a line, the whole call is rolled back.\n- On success one row with `ReturnCode` = `OK` and the invoice key in `Message` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | No | XML document with the root `POSINVOICE`. It contains a `HEADER` element (`REGISTERID`, `POSHEADERKEY`, `COMMENT`, `CUSTOMERNREXTERNAL`, `GENERALBIN`) and `LINES/LINE` elements (`ITEMNRINT`, `QUANTITY`, `PRICE`, `DISCOUNTPERCENT`, `BIN`, `COMMAND`). Values can be given as child elements or as attributes. Although the SQL default is NULL, the call cannot work without it. |\n\n- **Column name differs by case:** the success row has the column `Message`, the error row has `MESSAGE`. XML element names are case-sensitive, so a client has to read both.\n- **XML parsing outside the error handling:** `sp_xml_preparedocument` runs outside the `TRY` block. A NULL or malformed `XML` therefore comes back as `SqlMessage` and not as an `ERROR` row. The XML document handle is never released with `sp_xml_removedocument`.\n- **Data type errors:** values in the XML that cannot be converted (for example non-numeric `QUANTITY` or `PRICE`) cause an `ERROR` row with the SQL Server message.\n- **Overwritten header fields:** when an existing invoice is extended, its lines are appended and existing lines stay unchanged. `PHCusAddrKey` and `InvoiceComment` are always overwritten, with NULL if `CUSTOMERNREXTERNAL` or `COMMENT` is missing.\n- **New invoice for key 0:** an empty or `0` `POSHEADERKEY` is treated as \"create new\".\n- **Misleading item error:** the 'Item not found' message takes the item number of an arbitrary line, not necessarily the missing one. If that `ITEMNRINT` is missing, the message is empty. The message is truncated to 150 characters.\n- **Unchecked line values:** a NULL quantity and a NULL price are not rejected; a quantity of 0 is accepted. `PRICE` is stored as given and not taken from the item master data.\n- **Batch numbers and best-before dates:** the stock booking passes no batch number or best-before date, so only bin stock without batch number or best-before date qualifies. Items managed by Charge or best-before date will probably fail with a stock message.\n- **Bin logic not attached:** the actual choice of bins happens in `Pixi_POS_GetTakeOutBins` and `Pixi_POSSuggestBinTakeOut`. Stock is booked out in `Pixi_InvBinTakeOut`. These are not attached, so the exact bin order and the take-out messages cannot be documented here.\n- **Side effects of the called procedures:** `POSSession_event` and `POSBinTrack` are written, the MQ event `POSInoviceCreated` is published, and take-out errors are logged in `LogTable`.\n- **Transaction:** all changes run in one transaction and are rolled back on any error. Lookups use `NOLOCK`, and the header update uses `ROWLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new POS invoice, or adds lines to an open one, from an XML document and books the sold items out of stock.\n\nCreates a point-of-sale (POS) invoice for a cash register. All data is passed in one XML document in `XML`.\n\n**Parsing**\n- Header from `POSINVOICE/HEADER`: `REGISTERID` (required), `POSHEADERKEY` (optional, an existing invoice to extend), `COMMENT`, `CUSTOMERNREXTERNAL` (optional) and `GENERALBIN` (optional general POS bin).\n- Lines from `POSINVOICE/LINES/LINE`: `ITEMNRINT`, `QUANTITY`, `PRICE`, `DISCOUNTPERCENT` (default 0) and `BIN` (preferred bin, default empty). `COMMAND` is read but not used.\n\n**Lookups**\n- The customer is looked up by `Customers.CustomerNrExternal`; its address key is stored on the invoice.\n- The open POS session (`EndTime` is NULL) of the register with the latest `StartTime` supplies the location, the session ID and the user name.\n- Each line's item is looked up by `ItemNrInt`; the item's EAN/UPC is taken over.\n\n**Validation** (in this order; the first failure ends the call with an `ERROR` row)\n1. `REGISTERID` is present.\n2. If `POSHEADERKEY` is given, the invoice exists in `POSheader2` and its status is not `CLO` or `STO`.\n3. An open POS session exists for the register.\n4. All items exist.\n5. If `CUSTOMERNREXTERNAL` is given, the customer exists.\n6. No quantity is negative.\n7. `DISCOUNTPERCENT` is between 0 and 100.\n\n**Execution** (in one transaction)\n- Without `POSHEADERKEY` a new invoice header is created with the internal procedure `Pixi_POSNewInvoice` (document type `INV`). That procedure also records a session event and publishes the MQ event `POSInoviceCreated`.\n- The header is updated: customer address, `InvoiceComment`, update user and update date.\n- For every line:\n - A `POSitem2` row is inserted with quantity, price, discount and EAN/UPC.\n - Take-out bins are suggested with `BIN` as priority bin and `GENERALBIN` as general bin, in ascending order.\n - The suggestions are stored in `POSItemBinSelection`.\n - The stock is booked out of the bins (action type 4, stock movement refs `SMORef` 15 / `SMTRef` 12).\n - If the booking fails for a line, the whole call is rolled back.\n- On success one row with `ReturnCode` = `OK` and the invoice key in `Message` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | No | XML document with the root `POSINVOICE`. It contains a `HEADER` element (`REGISTERID`, `POSHEADERKEY`, `COMMENT`, `CUSTOMERNREXTERNAL`, `GENERALBIN`) and `LINES/LINE` elements (`ITEMNRINT`, `QUANTITY`, `PRICE`, `DISCOUNTPERCENT`, `BIN`, `COMMAND`). Values can be given as child elements or as attributes. Although the SQL default is NULL, the call cannot work without it. |\n\n- **Column name differs by case:** the success row has the column `Message`, the error row has `MESSAGE`. XML element names are case-sensitive, so a client has to read both.\n- **XML parsing outside the error handling:** `sp_xml_preparedocument` runs outside the `TRY` block. A NULL or malformed `XML` therefore comes back as `SqlMessage` and not as an `ERROR` row. The XML document handle is never released with `sp_xml_removedocument`.\n- **Data type errors:** values in the XML that cannot be converted (for example non-numeric `QUANTITY` or `PRICE`) cause an `ERROR` row with the SQL Server message.\n- **Overwritten header fields:** when an existing invoice is extended, its lines are appended and existing lines stay unchanged. `PHCusAddrKey` and `InvoiceComment` are always overwritten, with NULL if `CUSTOMERNREXTERNAL` or `COMMENT` is missing.\n- **New invoice for key 0:** an empty or `0` `POSHEADERKEY` is treated as \"create new\".\n- **Misleading item error:** the 'Item not found' message takes the item number of an arbitrary line, not necessarily the missing one. If that `ITEMNRINT` is missing, the message is empty. The message is truncated to 150 characters.\n- **Unchecked line values:** a NULL quantity and a NULL price are not rejected; a quantity of 0 is accepted. `PRICE` is stored as given and not taken from the item master data.\n- **Batch numbers and best-before dates:** the stock booking passes no batch number or best-before date, so only bin stock without batch number or best-before date qualifies. Items managed by Charge or best-before date will probably fail with a stock message.\n- **Bin logic not attached:** the actual choice of bins happens in `Pixi_POS_GetTakeOutBins` and `Pixi_POSSuggestBinTakeOut`. Stock is booked out in `Pixi_InvBinTakeOut`. These are not attached, so the exact bin order and the take-out messages cannot be documented here.\n- **Side effects of the called procedures:** `POSSession_event` and `POSBinTrack` are written, the MQ event `POSInoviceCreated` is published, and take-out errors are logged in `LogTable`.\n- **Transaction:** all changes run in one transaction and are rolled back on any error. Lookups use `NOLOCK`, and the header update uses `ROWLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Returns POS sales and POS payments of a date range as DATEV booking lines (revenue per VAT rate and payment entries) for export to accounting.\n\nWrapper for the internal procedure `Pixi_DatevExportPOSInvoices`. It builds DATEV booking lines from point-of-sale documents (`POSheader2`/`POSitem2`) and POS payments (`POSPayment`).\n\n**Date range**: `DateFrom` is moved to the start of its day and `DateTo` to the end of its day. Both are compared with the POS document date `PHdate`.\n\n**Revenue lines (`Source` = `INV`)**\n- One line per POS document and VAT rate, sign, item booking account and some other grouping attributes. Line amounts are `PIQty * PIEndPrice`. A header discount (amount or percent) is spread proportionally over the lines.\n- `MwstSatz` is the item VAT rate (1 = high, 2 = low, 3 = zero). It is set to 3 if the customer address has `AddrNoChargeVAT`.\n- `BookKeepingAccount` depends on the VAT rate and comes from the settings `AccountNumberPOSInvoice`, `AccountNumberPOSInvoiceVatLow` and `AccountNumberPOSInvoiceVatZero`.\n- `VatCode` and `BookKeepingAccount` can then be overridden by `DatevVatCodeOverrideHigh/Low` and `DatevAccountOverrideHigh/Low` from the `VATs` table. A country-specific entry valid on the document date wins over a generic one. Accounts that appear as values of settings named like `book%accounteucompanies%` are not overridden.\n- Groups whose sum is 0 are skipped.\n\n**Payment lines (`Source` = `PAY`)**\n- One line per POS payment amount, except payment codes `B` and `-`. The amount is `POSPayment.Amount`.\n- `BookKeepingAccount` is the `BookkeepingAccountPos` of the payment type, or the setting `AccountNumberPOSPayment` as fallback.\n- `Gegenkonto` comes from the shop (`Shops.Gegenkonto`) of the customer (`Customers.CustomerOf`) linked through the invoice with the same number.\n\n**Filters** (each one is ignored when `NULL`):\n- `ShopId`: shop of the address. For `INV` lines this is the POS customer address. For `PAY` lines it is the address of the invoice with the same number.\n- `Country`: country of the POS customer address.\n- `InvoiceNr`: POS document number (`PHdocNr`).\n- `OrderNrExternal`: external order number of the order line (`INV`) or of the order header (`PAY`).\n- `BookKeepingAccount`: works as an all-or-nothing switch, not as a per-row filter. `INV` lines are returned only if the value equals one of the three POS invoice account settings. `PAY` lines are returned only if it equals `AccountNumberPOSPayment`.\n\n**Output**\n- With `ShowOnlySums` = 0, all lines are returned. Only lines whose country exists in `Countries` are included.\n- `Price` and `PriceInCents` are absolute values; the direction is in `Sign`.\n- `CustomerNr` falls back to the setting `DefaultCustomerAccountNumber`.\n- Sort order: `InvoiceNr`, `Source`, `InvText`, `Price`.\n\nWith `ShowOnlySums` = 1, only one placeholder row with `ReportName` = `DATEVExportInvoices` is returned. All its sum columns are `NULL`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Yes | Start of the period (POS document date). The time part is reset to the start of the day. |\n| `DateTo` | datetime | Yes | End of the period (POS document date). Extended to the end of the day. |\n| `ShopId` | varchar(3) | No | Optional shop filter on the shop of the customer address. Sales without an address are excluded when set. |\n| `ShowOnlySums` | bit | No | Selects the output mode: booking lines or a placeholder sum row. |\n| `Country` | varchar(3) | No | Optional filter on the Pixi country code of the POS customer address. |\n| `InvoiceNr` | varchar(20) | No | Optional filter on the POS document number (`PHdocNr`). |\n| `OrderNrExternal` | varchar(50) | No | Optional filter on the external order number linked to the POS sale. |\n| `BookKeepingAccount` | varchar(255) | No | Optional account switch. `INV` lines are returned only if it equals one of the POS invoice account settings. `PAY` lines are returned only if it equals `AccountNumberPOSPayment`. |\n\n- Read-only. All tables are read with `NOLOCK`, except `POSheader2` and `Addresses` in the payment part. Uncommitted data can therefore appear.\n- Many settings change the output:\n - `BookExportDatevPro`: sign `s`/`h` instead of `+`/`-`.\n - `BookExportDatevHomeCountry`: home country, default `D`.\n - `BookExportDatevUseOrderNrExternal`: comma list of payment types for which `InvoiceNr` holds the external order number instead of the POS document number.\n - `BookExportBookAccountAsKostenStelle`: puts the item booking account into `Empty2`.\n - `ExportPaymentTypeAsKostenStelle2`: `Empty3` gets the payment type (1). With 2 it gets `NULL` for `INV` lines and the shop `Gegenkonto` for `PAY` lines.\n - VAT code settings `BookEu*VatCode`, `BookGer*VatCode` and `BookNonEuVatCode`.\n- VAT code settings are cast to `int`. A non-numeric value causes a conversion error.\n- `Country` falls back to the country of the POS location (`Location.LocCountry`). `VatCode` and `AccountNrItems`, however, are derived only from the customer address country, so they can be `NULL` for anonymous POS sales.\n- Payment lines are joined to the POS items. A payment can therefore be split into several lines if the items have different VAT codes or item accounts.\n- The currency is always the database home currency (`pixi.GetDatabaseCurrency`).\n- `OrderNrExternal` is cut to 12 characters and `InvText` to 60 characters.\n- The `ShowOnlySums` mode currently returns no real sums, only `NULL` values.\n\nDocumentation: https://pixi-api-docs.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": "Returns POS sales and POS payments of a date range as DATEV booking lines (revenue per VAT rate and payment entries) for export to accounting.\n\nWrapper for the internal procedure `Pixi_DatevExportPOSInvoices`. It builds DATEV booking lines from point-of-sale documents (`POSheader2`/`POSitem2`) and POS payments (`POSPayment`).\n\n**Date range**: `DateFrom` is moved to the start of its day and `DateTo` to the end of its day. Both are compared with the POS document date `PHdate`.\n\n**Revenue lines (`Source` = `INV`)**\n- One line per POS document and VAT rate, sign, item booking account and some other grouping attributes. Line amounts are `PIQty * PIEndPrice`. A header discount (amount or percent) is spread proportionally over the lines.\n- `MwstSatz` is the item VAT rate (1 = high, 2 = low, 3 = zero). It is set to 3 if the customer address has `AddrNoChargeVAT`.\n- `BookKeepingAccount` depends on the VAT rate and comes from the settings `AccountNumberPOSInvoice`, `AccountNumberPOSInvoiceVatLow` and `AccountNumberPOSInvoiceVatZero`.\n- `VatCode` and `BookKeepingAccount` can then be overridden by `DatevVatCodeOverrideHigh/Low` and `DatevAccountOverrideHigh/Low` from the `VATs` table. A country-specific entry valid on the document date wins over a generic one. Accounts that appear as values of settings named like `book%accounteucompanies%` are not overridden.\n- Groups whose sum is 0 are skipped.\n\n**Payment lines (`Source` = `PAY`)**\n- One line per POS payment amount, except payment codes `B` and `-`. The amount is `POSPayment.Amount`.\n- `BookKeepingAccount` is the `BookkeepingAccountPos` of the payment type, or the setting `AccountNumberPOSPayment` as fallback.\n- `Gegenkonto` comes from the shop (`Shops.Gegenkonto`) of the customer (`Customers.CustomerOf`) linked through the invoice with the same number.\n\n**Filters** (each one is ignored when `NULL`):\n- `ShopId`: shop of the address. For `INV` lines this is the POS customer address. For `PAY` lines it is the address of the invoice with the same number.\n- `Country`: country of the POS customer address.\n- `InvoiceNr`: POS document number (`PHdocNr`).\n- `OrderNrExternal`: external order number of the order line (`INV`) or of the order header (`PAY`).\n- `BookKeepingAccount`: works as an all-or-nothing switch, not as a per-row filter. `INV` lines are returned only if the value equals one of the three POS invoice account settings. `PAY` lines are returned only if it equals `AccountNumberPOSPayment`.\n\n**Output**\n- With `ShowOnlySums` = 0, all lines are returned. Only lines whose country exists in `Countries` are included.\n- `Price` and `PriceInCents` are absolute values; the direction is in `Sign`.\n- `CustomerNr` falls back to the setting `DefaultCustomerAccountNumber`.\n- Sort order: `InvoiceNr`, `Source`, `InvText`, `Price`.\n\nWith `ShowOnlySums` = 1, only one placeholder row with `ReportName` = `DATEVExportInvoices` is returned. All its sum columns are `NULL`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Yes | Start of the period (POS document date). The time part is reset to the start of the day. |\n| `DateTo` | datetime | Yes | End of the period (POS document date). Extended to the end of the day. |\n| `ShopId` | varchar(3) | No | Optional shop filter on the shop of the customer address. Sales without an address are excluded when set. |\n| `ShowOnlySums` | bit | No | Selects the output mode: booking lines or a placeholder sum row. |\n| `Country` | varchar(3) | No | Optional filter on the Pixi country code of the POS customer address. |\n| `InvoiceNr` | varchar(20) | No | Optional filter on the POS document number (`PHdocNr`). |\n| `OrderNrExternal` | varchar(50) | No | Optional filter on the external order number linked to the POS sale. |\n| `BookKeepingAccount` | varchar(255) | No | Optional account switch. `INV` lines are returned only if it equals one of the POS invoice account settings. `PAY` lines are returned only if it equals `AccountNumberPOSPayment`. |\n\n- Read-only. All tables are read with `NOLOCK`, except `POSheader2` and `Addresses` in the payment part. Uncommitted data can therefore appear.\n- Many settings change the output:\n - `BookExportDatevPro`: sign `s`/`h` instead of `+`/`-`.\n - `BookExportDatevHomeCountry`: home country, default `D`.\n - `BookExportDatevUseOrderNrExternal`: comma list of payment types for which `InvoiceNr` holds the external order number instead of the POS document number.\n - `BookExportBookAccountAsKostenStelle`: puts the item booking account into `Empty2`.\n - `ExportPaymentTypeAsKostenStelle2`: `Empty3` gets the payment type (1). With 2 it gets `NULL` for `INV` lines and the shop `Gegenkonto` for `PAY` lines.\n - VAT code settings `BookEu*VatCode`, `BookGer*VatCode` and `BookNonEuVatCode`.\n- VAT code settings are cast to `int`. A non-numeric value causes a conversion error.\n- `Country` falls back to the country of the POS location (`Location.LocCountry`). `VatCode` and `AccountNrItems`, however, are derived only from the customer address country, so they can be `NULL` for anonymous POS sales.\n- Payment lines are joined to the POS items. A payment can therefore be split into several lines if the items have different VAT codes or item accounts.\n- The currency is always the database home currency (`pixi.GetDatabaseCurrency`).\n- `OrderNrExternal` is cut to 12 characters and `InvText` to 60 characters.\n- The `ShowOnlySums` mode currently returns no real sums, only `NULL` values.\n\nDocumentation: https://pixi-api-docs.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": "Deletes a shipping package and its package lines from an invoice and updates the invoice's tracking IDs and package count.\n\nRemoves one package record (`pixi.InvoicePackage`) that belongs to an invoice (Rechnung), for example after a shipping label was cancelled.\n\nThe call runs these checks in order and returns a single `Response` row in every case:\n\n1. The package `PackageId` must exist. Otherwise: `400 Bad Request - Package ID does not exist.`\n2. The package must belong to the invoice `InvoiceKey`. Otherwise: `400 Bad Request - Invoice ID does not match the package.`\n3. The invoice must have more than one package. The last remaining package of an invoice cannot be deleted: `400 Bad Request - This is the last package for invoice and delete is not allowed.`\n\nIf all checks pass:\n\n- all package lines (`pixi.InvoicePackageLines`) of the package are deleted,\n- the package itself is deleted,\n- in `Invoices` the package's tracking ID followed by `;` is removed from `ShipmentTrackingID`, and `Packages` is set to the number of packages that remain for the invoice,\n- `200 OK` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PackageId` | int | Yes | ID of the package to delete (`pixi.InvoicePackage.Id`). |\n| `InvoiceKey` | int | Yes | Key of the invoice the package belongs to. Must match `InvoiceId` of the package. |\n\n- All changes run in a transaction (or a savepoint if the caller already has an open transaction). On any SQL error the changes are rolled back, the error is logged via `log.InsertError` and `500 Internal Server Error` is returned as a normal row, not as a `SqlMessage`.\n- The existence and count checks read `pixi.InvoicePackage` with `NOLOCK`, so concurrent changes may not be seen.\n- The tracking ID is only removed from `ShipmentTrackingID` when it is followed by `;`. A tracking ID at the end of the list without a trailing semicolon stays in the field. `REPLACE` removes every occurrence of the pattern.\n- If the package has no `TrackingID` (NULL), the `REPLACE` expression yields NULL, so `ShipmentTrackingID` of the invoice is set to NULL.\n- `ReturnTrackingId` of the package is read but not removed from the invoice.\n- Passing NULL for `InvoiceKey` always leads to the \"does not match\" response.\n\nDocumentation: https://pixi-api-docs.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": "Deletes a shipping package and its package lines from an invoice and updates the invoice's tracking IDs and package count.\n\nRemoves one package record (`pixi.InvoicePackage`) that belongs to an invoice (Rechnung), for example after a shipping label was cancelled.\n\nThe call runs these checks in order and returns a single `Response` row in every case:\n\n1. The package `PackageId` must exist. Otherwise: `400 Bad Request - Package ID does not exist.`\n2. The package must belong to the invoice `InvoiceKey`. Otherwise: `400 Bad Request - Invoice ID does not match the package.`\n3. The invoice must have more than one package. The last remaining package of an invoice cannot be deleted: `400 Bad Request - This is the last package for invoice and delete is not allowed.`\n\nIf all checks pass:\n\n- all package lines (`pixi.InvoicePackageLines`) of the package are deleted,\n- the package itself is deleted,\n- in `Invoices` the package's tracking ID followed by `;` is removed from `ShipmentTrackingID`, and `Packages` is set to the number of packages that remain for the invoice,\n- `200 OK` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PackageId` | int | Yes | ID of the package to delete (`pixi.InvoicePackage.Id`). |\n| `InvoiceKey` | int | Yes | Key of the invoice the package belongs to. Must match `InvoiceId` of the package. |\n\n- All changes run in a transaction (or a savepoint if the caller already has an open transaction). On any SQL error the changes are rolled back, the error is logged via `log.InsertError` and `500 Internal Server Error` is returned as a normal row, not as a `SqlMessage`.\n- The existence and count checks read `pixi.InvoicePackage` with `NOLOCK`, so concurrent changes may not be seen.\n- The tracking ID is only removed from `ShipmentTrackingID` when it is followed by `;`. A tracking ID at the end of the list without a trailing semicolon stays in the field. `REPLACE` removes every occurrence of the pattern.\n- If the package has no `TrackingID` (NULL), the `REPLACE` expression yields NULL, so `ShipmentTrackingID` of the invoice is set to NULL.\n- `ReturnTrackingId` of the package is read but not removed from the invoice.\n- Passing NULL for `InvoiceKey` always leads to the \"does not match\" response.\n\nDocumentation: https://pixi-api-docs.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": "Returns all invoices of a date range, optionally limited to one shop, with customer data and the related order, for the eMill integration.\n\nLists invoices for the eMill integration.\n\n- `ShopID`: if empty or omitted, invoices of all shops are returned; otherwise only invoices whose `InvShopID` equals `ShopID`.\n- `DateFrom`: if omitted or earlier than 1990-01-01, the start of the current day (00:00:00) is used.\n- `DateTo`: if omitted or earlier than 1990-01-01, the end of the current day (23:59:59.997) is used.\n- An invoice is returned if its `InvDate` lies between `DateFrom` and `DateTo` (both inclusive).\n\nFor each invoice the call adds:\n\n- customer data (external customer number, salutation, names, e-mail) from the customer referenced by the invoice; these columns are empty if no customer is found;\n- order data (`OrderNr`, `OrderNrExternal`, `OrdShopID`, `OrderDate`) from the order line with the highest key among the invoice lines of the invoice.\n\nThe result has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | No | Shop ID to filter invoices by (`InvShopID`). Empty or omitted returns invoices of all shops. |\n| `DateFrom` | datetime | No | Start of the invoice date range (inclusive). Omitted or before 1990-01-01: start of the current day. |\n| `DateTo` | datetime | No | End of the invoice date range (inclusive). Omitted or before 1990-01-01: end of the current day (23:59:59.997). |\n\n- All tables are read `WITH (NOLOCK)`; uncommitted data may appear.\n- Invoices without invoice lines, or whose highest referenced order line does not exist, are **not** returned (inner join on the order line).\n- If only one date is passed, the other defaults to today: passing only a `DateTo` in the past results in `DateFrom` = today and therefore an empty result.\n- `DateTo` without time part means midnight, so invoices later on that day are excluded; pass the end of the day explicitly.\n- Only one order is reported per invoice, even if the invoice covers lines of several orders.\n\nDocumentation: https://pixi-api-docs.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": "Returns all invoices of a date range, optionally limited to one shop, with customer data and the related order, for the eMill integration.\n\nLists invoices for the eMill integration.\n\n- `ShopID`: if empty or omitted, invoices of all shops are returned; otherwise only invoices whose `InvShopID` equals `ShopID`.\n- `DateFrom`: if omitted or earlier than 1990-01-01, the start of the current day (00:00:00) is used.\n- `DateTo`: if omitted or earlier than 1990-01-01, the end of the current day (23:59:59.997) is used.\n- An invoice is returned if its `InvDate` lies between `DateFrom` and `DateTo` (both inclusive).\n\nFor each invoice the call adds:\n\n- customer data (external customer number, salutation, names, e-mail) from the customer referenced by the invoice; these columns are empty if no customer is found;\n- order data (`OrderNr`, `OrderNrExternal`, `OrdShopID`, `OrderDate`) from the order line with the highest key among the invoice lines of the invoice.\n\nThe result has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | No | Shop ID to filter invoices by (`InvShopID`). Empty or omitted returns invoices of all shops. |\n| `DateFrom` | datetime | No | Start of the invoice date range (inclusive). Omitted or before 1990-01-01: start of the current day. |\n| `DateTo` | datetime | No | End of the invoice date range (inclusive). Omitted or before 1990-01-01: end of the current day (23:59:59.997). |\n\n- All tables are read `WITH (NOLOCK)`; uncommitted data may appear.\n- Invoices without invoice lines, or whose highest referenced order line does not exist, are **not** returned (inner join on the order line).\n- If only one date is passed, the other defaults to today: passing only a `DateTo` in the past results in `DateFrom` = today and therefore an empty result.\n- `DateTo` without time part means midnight, so invoices later on that day are excluded; pass the end of the day explicitly.\n- Only one order is reported per invoice, even if the invoice covers lines of several orders.\n\nDocumentation: https://pixi-api-docs.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": "Returns the distinct list of countries (code and name) that appear in the invoice addresses of all invoices.\n\nCollects the country of the address linked to each invoice and returns each country once, with its code and name.\n\n- Every invoice in `Invoices` is joined to its address in `Addresses` via `AddrRef` = `AddrKey`. Invoices without a matching address are left out.\n- The country value of the address is looked up in the `countries` table by `CntCode`.\n- The result is deduplicated (`DISTINCT`) and sorted by `CntName` ascending.\n\nThe call has no parameters and always covers all invoices in the database.\n\n- The lookup in `countries` is a `LEFT JOIN`. If an address contains a country value that does not exist in `countries` (or is empty/NULL), a row with `CntCode` and `CntName` both NULL is returned. Because of the ascending sort on `CntName`, this row appears first.\n- The unmatched country value itself is not returned, only the NULL columns.\n- `Invoices` and `Addresses` are read with `NOLOCK` (dirty reads possible); `countries` is read without a locking hint.\n- The query scans all invoices; on large databases the call can take some time.\n\nDocumentation: https://pixi-api-docs.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": "Returns the distinct list of countries (code and name) that appear in the invoice addresses of all invoices.\n\nCollects the country of the address linked to each invoice and returns each country once, with its code and name.\n\n- Every invoice in `Invoices` is joined to its address in `Addresses` via `AddrRef` = `AddrKey`. Invoices without a matching address are left out.\n- The country value of the address is looked up in the `countries` table by `CntCode`.\n- The result is deduplicated (`DISTINCT`) and sorted by `CntName` ascending.\n\nThe call has no parameters and always covers all invoices in the database.\n\n- The lookup in `countries` is a `LEFT JOIN`. If an address contains a country value that does not exist in `countries` (or is empty/NULL), a row with `CntCode` and `CntName` both NULL is returned. Because of the ascending sort on `CntName`, this row appears first.\n- The unmatched country value itself is not returned, only the NULL columns.\n- `Invoices` and `Addresses` are read with `NOLOCK` (dirty reads possible); `countries` is read without a locking hint.\n- The query scans all invoices; on large databases the call can take some time.\n\nDocumentation: https://pixi-api-docs.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": "Returns the DATEV export data for invoices in a date range, optionally filtered by shop, country, invoice number, external order number, account and cost center.\n\nProvides the DATEV export file \"Invoices\" through the API.\n\n1. The call reads the setting `BookExportDatevActive` (shown in Pixi as \"DATEV API Calls\").\n2. If the setting is `1`, it passes all parameters unchanged to the internal procedure `Pixi_DatevExportInvoices` and returns that procedure's result. It also passes `@SetStartAndEndOfDay = 0`.\n3. If the setting is not `1`, the call does not run an export. It returns one status row with `Status` = `ERROR` and a message saying that the setting is not enabled.\n\nParameters:\n- `DateFrom` and `DateTo` are required and define the period of the export.\n- All other parameters are optional filters. If a filter is left out (`NULL`), no restriction is applied on that criterion. This assumes that the internal procedure treats `NULL` this way.\n- `ShowOnlySums` asks for a summed output instead of individual lines.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Yes | Start of the export period. |\n| `DateTo` | datetime | Yes | End of the export period. The value is presumably used exactly as sent, so include the time of day. |\n| `ShopId` | varchar(3) | No | Optional filter by shop ID. |\n| `ShowOnlySums` | bit | No | If `1`, only sums are requested from the export instead of individual lines. |\n| `Country` | varchar(3) | No | Optional filter by country code. |\n| `InvoiceNr` | varchar(20) | No | Optional filter by invoice number. |\n| `OrderNrExternal` | varchar(50) | No | Optional filter by external (shop) order number. |\n| `BookKeepingAccount` | varchar(255) | No | Optional filter by bookkeeping account number. |\n| `CostCenter` | varchar(8) | No | Optional filter by cost center. |\n\n- The actual export logic, the filter semantics and the columns of the export result set are in `Pixi_DatevExportInvoices`. Its definition is not attached, so the columns and any side effects of the export cannot be documented here.\n- Because `@SetStartAndEndOfDay = 0` is passed, `DateFrom` and `DateTo` are presumably used exactly as sent and are not extended to 00:00 / 23:59:59. To cover whole days, send explicit times, e.g. `2024-01-31T23:59:59`.\n- The setting is read through `fpixi_GetSetting`. If the setting does not exist, this function returns `0`, so the call returns the error row. A setting value that cannot be converted to `BIT` causes a conversion error.\n- The setting is read from `Settings` with `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the DATEV export data for invoices in a date range, optionally filtered by shop, country, invoice number, external order number, account and cost center.\n\nProvides the DATEV export file \"Invoices\" through the API.\n\n1. The call reads the setting `BookExportDatevActive` (shown in Pixi as \"DATEV API Calls\").\n2. If the setting is `1`, it passes all parameters unchanged to the internal procedure `Pixi_DatevExportInvoices` and returns that procedure's result. It also passes `@SetStartAndEndOfDay = 0`.\n3. If the setting is not `1`, the call does not run an export. It returns one status row with `Status` = `ERROR` and a message saying that the setting is not enabled.\n\nParameters:\n- `DateFrom` and `DateTo` are required and define the period of the export.\n- All other parameters are optional filters. If a filter is left out (`NULL`), no restriction is applied on that criterion. This assumes that the internal procedure treats `NULL` this way.\n- `ShowOnlySums` asks for a summed output instead of individual lines.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Yes | Start of the export period. |\n| `DateTo` | datetime | Yes | End of the export period. The value is presumably used exactly as sent, so include the time of day. |\n| `ShopId` | varchar(3) | No | Optional filter by shop ID. |\n| `ShowOnlySums` | bit | No | If `1`, only sums are requested from the export instead of individual lines. |\n| `Country` | varchar(3) | No | Optional filter by country code. |\n| `InvoiceNr` | varchar(20) | No | Optional filter by invoice number. |\n| `OrderNrExternal` | varchar(50) | No | Optional filter by external (shop) order number. |\n| `BookKeepingAccount` | varchar(255) | No | Optional filter by bookkeeping account number. |\n| `CostCenter` | varchar(8) | No | Optional filter by cost center. |\n\n- The actual export logic, the filter semantics and the columns of the export result set are in `Pixi_DatevExportInvoices`. Its definition is not attached, so the columns and any side effects of the export cannot be documented here.\n- Because `@SetStartAndEndOfDay = 0` is passed, `DateFrom` and `DateTo` are presumably used exactly as sent and are not extended to 00:00 / 23:59:59. To cover whole days, send explicit times, e.g. `2024-01-31T23:59:59`.\n- The setting is read through `fpixi_GetSetting`. If the setting does not exist, this function returns `0`, so the call returns the error row. A setting value that cannot be converted to `BIT` causes a conversion error.\n- The setting is read from `Settings` with `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoices handed over to debt collection (Inkasso) in a date range, with customer address and amounts; only supported on the pixi_GCH databases.\n\nThis call is customer-specific and only works when the Pixi database is named `pixi_GCH` or `pixi_GCH_test`. On all other databases it returns one status row with `Status` = `Info` and the message that the call is no longer supported.\n\nOn the supported databases the call runs the internal procedure `Pixi_CA_GetInkassoBookings` and returns its rows:\n\n1. The booking event ID for manual Inkasso bookings is read from the setting `CA_Inkasso_ManualBookingID` (default `INU`).\n2. All customer account bookings (`CustomerAccount`) with this event ID and an `EventDate` between `FromDate` and `ToDate` (both inclusive) are selected.\n3. Through `CustomerAccountMatch` the matched bookings are found, in both directions, and the invoices those bookings refer to are determined.\n4. One row per invoice is returned with the customer (`Customers`) and the customer address (`Addresses`), sorted by invoice date (`InvDate`) ascending.\n\nThe row layout is a fixed export format for a debt collection agency:\n- Fixed values: `KundenNr` = `975503`, `RecordCode` = `0`, `CompanyType` = `99`, `Land` = `001`, `Adresszusatz` and `Rechnungsgrund` empty.\n- `Sprachcode` is `D` if the address belongs to shop `GCH`, otherwise `F`.\n- `Geschlecht` is `m` for salutation `Herr`, `w` for `Frau`, otherwise `f`.\n- Dates (`Geburtsdatum`, `Rechnungsdatum`) are formatted as `dd.mm.yyyy`.\n- Amounts (`BetragCHF`, `Mahnkosten`, `BetragCHFtotal`) are returned as text with a dot as decimal separator. `BetragCHF` is the amount of the matched Inkasso booking, `BetragCHFtotal` the invoice total, `Mahnkosten` the reminder costs (0 if none).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Yes | Start of the period (inclusive) for the `EventDate` of the Inkasso bookings. |\n| `ToDate` | datetime | Yes | End of the period (inclusive) for the `EventDate` of the Inkasso bookings. Include the time, e.g. 23:59:59, to cover the whole last day. |\n\n- Outside the databases `pixi_GCH` / `pixi_GCH_test` the call is effectively retired: it always returns the `Info` row and never queries data.\n- Before the export, the helper `util.TableDrop` is called for the legacy table `tmp.pipiGetInkassoBookings_Output`; the data itself is collected in a temporary table that is dropped at the end. The helper procedures are not attached.\n- The event ID depends on the setting `CA_Inkasso_ManualBookingID`, read at runtime via `dbo.SettingGet`.\n- The customer account tables are read `WITH (NOLOCK)`, so uncommitted bookings may appear.\n- `EventDate BETWEEN FromDate AND ToDate` is compared on `datetime`: a `ToDate` without time (midnight) excludes bookings later on that day.\n- `Geburtsjahr` is `0` if no birth date is stored; `Geburtsdatum` is then empty.\n- `BetragCHF` can be empty (NULL) if no matching Inkasso booking amount is found. The amount lookups use scalar subqueries; if an invoice has several customer account entries, SQL Server may raise a 'subquery returned more than 1 value' error.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoices handed over to debt collection (Inkasso) in a date range, with customer address and amounts; only supported on the pixi_GCH databases.\n\nThis call is customer-specific and only works when the Pixi database is named `pixi_GCH` or `pixi_GCH_test`. On all other databases it returns one status row with `Status` = `Info` and the message that the call is no longer supported.\n\nOn the supported databases the call runs the internal procedure `Pixi_CA_GetInkassoBookings` and returns its rows:\n\n1. The booking event ID for manual Inkasso bookings is read from the setting `CA_Inkasso_ManualBookingID` (default `INU`).\n2. All customer account bookings (`CustomerAccount`) with this event ID and an `EventDate` between `FromDate` and `ToDate` (both inclusive) are selected.\n3. Through `CustomerAccountMatch` the matched bookings are found, in both directions, and the invoices those bookings refer to are determined.\n4. One row per invoice is returned with the customer (`Customers`) and the customer address (`Addresses`), sorted by invoice date (`InvDate`) ascending.\n\nThe row layout is a fixed export format for a debt collection agency:\n- Fixed values: `KundenNr` = `975503`, `RecordCode` = `0`, `CompanyType` = `99`, `Land` = `001`, `Adresszusatz` and `Rechnungsgrund` empty.\n- `Sprachcode` is `D` if the address belongs to shop `GCH`, otherwise `F`.\n- `Geschlecht` is `m` for salutation `Herr`, `w` for `Frau`, otherwise `f`.\n- Dates (`Geburtsdatum`, `Rechnungsdatum`) are formatted as `dd.mm.yyyy`.\n- Amounts (`BetragCHF`, `Mahnkosten`, `BetragCHFtotal`) are returned as text with a dot as decimal separator. `BetragCHF` is the amount of the matched Inkasso booking, `BetragCHFtotal` the invoice total, `Mahnkosten` the reminder costs (0 if none).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Yes | Start of the period (inclusive) for the `EventDate` of the Inkasso bookings. |\n| `ToDate` | datetime | Yes | End of the period (inclusive) for the `EventDate` of the Inkasso bookings. Include the time, e.g. 23:59:59, to cover the whole last day. |\n\n- Outside the databases `pixi_GCH` / `pixi_GCH_test` the call is effectively retired: it always returns the `Info` row and never queries data.\n- Before the export, the helper `util.TableDrop` is called for the legacy table `tmp.pipiGetInkassoBookings_Output`; the data itself is collected in a temporary table that is dropped at the end. The helper procedures are not attached.\n- The event ID depends on the setting `CA_Inkasso_ManualBookingID`, read at runtime via `dbo.SettingGet`.\n- The customer account tables are read `WITH (NOLOCK)`, so uncommitted bookings may appear.\n- `EventDate BETWEEN FromDate AND ToDate` is compared on `datetime`: a `ToDate` without time (midnight) excludes bookings later on that day.\n- `Geburtsjahr` is `0` if no birth date is stored; `Geburtsdatum` is then empty.\n- `BetragCHF` can be empty (NULL) if no matching Inkasso booking amount is found. The amount lookups use scalar subqueries; if an invoice has several customer account entries, SQL Server may raise a 'subquery returned more than 1 value' error.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoice headers with totals, VAT, payment status, bank data and linked order numbers, filtered by invoice number, shop, dates, order or payment state, with key-based paging.\n\nSelects invoices from `Invoices` (joined with `Customers`) and returns one row per invoice with amounts, payment and shipping data.\n\n**Parameter normalisation**\n- Empty strings in `InvoiceNr`, `ShopID`, `PaymentType`, `OrderNRExternal` and `OrderNR = 0` are treated as *no filter*.\n- `RowCount` NULL or 0 becomes 1000.\n- Date parameters before 1990-01-01 are ignored.\n\n**Filters** (all combined with AND, only applied when set)\n- `StartKey` > 0: only invoices with `InvoiceKey` greater than `StartKey`.\n- `InvoiceNr`: exact invoice number.\n- `InvDateFrom`/`InvDateTo`: invoice date, `ShipDateFrom`/`ShipDateTo`: scan-out (ship) date, `UpdateDateFrom`/`UpdateDateTo`: last update. All date comparisons are **exclusive** (`>` and `<`).\n- `ShopID`: shop of the customer (`Customers.CustomerOF`).\n- `PaymentType`: payment code of the invoice.\n- `OrderNR` / `OrderNRExternal`: invoice must have at least one invoice line belonging to an order line with that order number / external order number.\n- `OnlyUnpaidInvoices` = 1: paid sum differs from the rounded total, and there is no open customer account entry (without bank line, DTAUS or manual booking) flagged `DoNotRefund`.\n\n**Paging**\nThe first `RowCount` matching invoices ordered by `InvoiceKey` are selected. To read the next page, pass the highest `InvoiceKey` of the previous result as `StartKey`.\n\n**Result**\n- `OrderNr`/`OrderNrExternal` are the highest order numbers of the orders linked through the invoice lines (restricted to matching order lines if an order filter is set).\n- `CcpPayID` is filled only with `AddCCPPayID` = 1 and contains a comma-separated list of payment IDs of the linked orders.\n- `PaymentDate` is the latest matching date from customer account matching.\n- `Paid` is 1 if the paid sum equals the total rounded to 2 decimals.\n- `Discount_Invoice` is the gross voucher sum for `B2C` invoices, otherwise the net voucher sum.\n- `VATHigh`/`VATLow`/`VATSum` include VAT on shipping and return costs.\n\nRows are sorted by `InvoiceDate`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | No | Exact invoice number. Empty = no filter. |\n| `ShopID` | varchar(3) | No | Shop ID of the customer (`Customers.CustomerOF`). Empty = all shops. |\n| `PaymentType` | char(1) | No | Payment code of the invoice (`Invoices.Payment`). Empty = all. |\n| `OrderNR` | int | No | Only invoices containing lines of this order number. 0 = no filter. |\n| `OrderNRExternal` | varchar(50) | No | Only invoices containing lines of this external (shop) order number. Empty = no filter. |\n| `InvDateFrom` | datetime | No | Invoice date strictly after this value. Values before 1990-01-01 are ignored. |\n| `InvDateTo` | datetime | No | Invoice date strictly before this value. Values before 1990-01-01 are ignored. |\n| `UpdateDateFrom` | datetime | No | Last update of the invoice strictly after this value. Values before 1990-01-01 are ignored. |\n| `UpdateDateTo` | datetime | No | Last update of the invoice strictly before this value. Values before 1990-01-01 are ignored. |\n| `RowCount` | int | No | Maximum number of invoices to select (page size). NULL or 0 = 1000. |\n| `AddCCPPayID` | bit | No | If 1, column `CcpPayID` is filled with the comma-separated payment IDs of the linked orders. |\n| `OnlyUnpaidInvoices` | bit | No | If 1, only invoices whose paid sum differs from the rounded total and that have no open `DoNotRefund` customer account entry. |\n| `StartKey` | int | No | Paging key: only invoices with `InvoiceKey` greater than this value. 0 = start from the beginning; negative values return nothing. |\n| `ShipDateFrom` | datetime | No | Scan-out (ship) date strictly after this value. Values before 1990-01-01 are ignored. |\n| `ShipDateTo` | datetime | No | Scan-out (ship) date strictly before this value. Values before 1990-01-01 are ignored. |\n\n- All reads use `NOLOCK`; uncommitted data may appear.\n- The main selection is built as dynamic SQL (`sp_executesql`) with parameters.\n- `TotalRows` is the number of rows of the selection step, which is limited by `RowCount`; it is **not** the total number of matching invoices.\n- A negative `StartKey` returns no rows.\n- Date filters are exclusive: `InvDateTo = 2024-03-31` excludes invoices dated exactly at that moment and later on that day.\n- The final query uses inner joins to `CustomerAccount`, `Payments`, `Addresses`, `pixi.Currency` and `pixi.ExchRate`. Invoices without a matching record there are not returned (but are counted in `TotalRows`). An invoice with several customer account entries, or linked orders with different `ccpPayID` values, can appear in several rows.\n- Temporary tables use unique indexes on the invoice key; if an invoice has several customer account entries or ambiguous order data, the call may fail with a duplicate key error from SQL Server.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoice headers with totals, VAT, payment status, bank data and linked order numbers, filtered by invoice number, shop, dates, order or payment state, with key-based paging.\n\nSelects invoices from `Invoices` (joined with `Customers`) and returns one row per invoice with amounts, payment and shipping data.\n\n**Parameter normalisation**\n- Empty strings in `InvoiceNr`, `ShopID`, `PaymentType`, `OrderNRExternal` and `OrderNR = 0` are treated as *no filter*.\n- `RowCount` NULL or 0 becomes 1000.\n- Date parameters before 1990-01-01 are ignored.\n\n**Filters** (all combined with AND, only applied when set)\n- `StartKey` > 0: only invoices with `InvoiceKey` greater than `StartKey`.\n- `InvoiceNr`: exact invoice number.\n- `InvDateFrom`/`InvDateTo`: invoice date, `ShipDateFrom`/`ShipDateTo`: scan-out (ship) date, `UpdateDateFrom`/`UpdateDateTo`: last update. All date comparisons are **exclusive** (`>` and `<`).\n- `ShopID`: shop of the customer (`Customers.CustomerOF`).\n- `PaymentType`: payment code of the invoice.\n- `OrderNR` / `OrderNRExternal`: invoice must have at least one invoice line belonging to an order line with that order number / external order number.\n- `OnlyUnpaidInvoices` = 1: paid sum differs from the rounded total, and there is no open customer account entry (without bank line, DTAUS or manual booking) flagged `DoNotRefund`.\n\n**Paging**\nThe first `RowCount` matching invoices ordered by `InvoiceKey` are selected. To read the next page, pass the highest `InvoiceKey` of the previous result as `StartKey`.\n\n**Result**\n- `OrderNr`/`OrderNrExternal` are the highest order numbers of the orders linked through the invoice lines (restricted to matching order lines if an order filter is set).\n- `CcpPayID` is filled only with `AddCCPPayID` = 1 and contains a comma-separated list of payment IDs of the linked orders.\n- `PaymentDate` is the latest matching date from customer account matching.\n- `Paid` is 1 if the paid sum equals the total rounded to 2 decimals.\n- `Discount_Invoice` is the gross voucher sum for `B2C` invoices, otherwise the net voucher sum.\n- `VATHigh`/`VATLow`/`VATSum` include VAT on shipping and return costs.\n\nRows are sorted by `InvoiceDate`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | No | Exact invoice number. Empty = no filter. |\n| `ShopID` | varchar(3) | No | Shop ID of the customer (`Customers.CustomerOF`). Empty = all shops. |\n| `PaymentType` | char(1) | No | Payment code of the invoice (`Invoices.Payment`). Empty = all. |\n| `OrderNR` | int | No | Only invoices containing lines of this order number. 0 = no filter. |\n| `OrderNRExternal` | varchar(50) | No | Only invoices containing lines of this external (shop) order number. Empty = no filter. |\n| `InvDateFrom` | datetime | No | Invoice date strictly after this value. Values before 1990-01-01 are ignored. |\n| `InvDateTo` | datetime | No | Invoice date strictly before this value. Values before 1990-01-01 are ignored. |\n| `UpdateDateFrom` | datetime | No | Last update of the invoice strictly after this value. Values before 1990-01-01 are ignored. |\n| `UpdateDateTo` | datetime | No | Last update of the invoice strictly before this value. Values before 1990-01-01 are ignored. |\n| `RowCount` | int | No | Maximum number of invoices to select (page size). NULL or 0 = 1000. |\n| `AddCCPPayID` | bit | No | If 1, column `CcpPayID` is filled with the comma-separated payment IDs of the linked orders. |\n| `OnlyUnpaidInvoices` | bit | No | If 1, only invoices whose paid sum differs from the rounded total and that have no open `DoNotRefund` customer account entry. |\n| `StartKey` | int | No | Paging key: only invoices with `InvoiceKey` greater than this value. 0 = start from the beginning; negative values return nothing. |\n| `ShipDateFrom` | datetime | No | Scan-out (ship) date strictly after this value. Values before 1990-01-01 are ignored. |\n| `ShipDateTo` | datetime | No | Scan-out (ship) date strictly before this value. Values before 1990-01-01 are ignored. |\n\n- All reads use `NOLOCK`; uncommitted data may appear.\n- The main selection is built as dynamic SQL (`sp_executesql`) with parameters.\n- `TotalRows` is the number of rows of the selection step, which is limited by `RowCount`; it is **not** the total number of matching invoices.\n- A negative `StartKey` returns no rows.\n- Date filters are exclusive: `InvDateTo = 2024-03-31` excludes invoices dated exactly at that moment and later on that day.\n- The final query uses inner joins to `CustomerAccount`, `Payments`, `Addresses`, `pixi.Currency` and `pixi.ExchRate`. Invoices without a matching record there are not returned (but are counted in `TotalRows`). An invoice with several customer account entries, or linked orders with different `ccpPayID` values, can appear in several rows.\n- Temporary tables use unique indexes on the invoice key; if an invoice has several customer account entries or ambiguous order data, the call may fail with a duplicate key error from SQL Server.\n\nDocumentation: https://pixi-api-docs.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": "Returns all lines of one invoice with item, order line, price, VAT, batch and drop-shipping data, optionally including shipping cost, voucher and manual invoice lines.\n\nReturns the invoice lines of the invoice whose number equals `InvoiceNr` (exact match). The data comes from the reporting view `PV_Invlines`, which combines real invoice lines with synthetic lines for invoice-level amounts. Each line is enriched with the order line (`BatchNumber`, `BestBeforeDate`, `TaxRate` as `VATPercent`) and the item (`PicLinkLarge`).\n\n**Special lines** (controlled by `IncludeSpecialInvLines`):\n\n- `-2`: shipping costs of the invoice (`ArtName` = `ZZZ Versandkosten`), only if the invoice has shipping costs other than 0.\n- `-1`: vouchers (`ArtName` = `ZZZ Gutscheine`), price shown as negative voucher sum.\n- `-3`: manual invoice without any invoice lines (`ArtName` = `ZZZ Manuelle Rechnung ohne Artikel`), amount = invoice total minus shipping costs.\n\nWith `IncludeSpecialInvLines` = 0 (default) these lines are excluded; with 1 they are returned as well. For special lines, `OrderLineKey` holds the special value (-1, -2, -3), `ItemQty` is 1, and most item/order fields (`InvoiceLineKey`, `ArtNr`, `OrderNr`, `BoxNr`, …) are `NULL`.\n\n`ItemPriceNoVAT` is the net price rounded to the number of decimals defined in the setting `PrintInvLineMoneyPrecision` (2 if the setting is missing or 0). No sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(50) | Yes | Number of the invoice whose lines are returned (exact match on the invoice number). |\n| `IncludeSpecialInvLines` | bit | No | Whether synthetic lines for shipping costs, vouchers and manual invoices are included. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- The filter on special lines compares the item key with `NOT IN (-1, -2, -3)`. Real invoice lines without an order line or whose order line has no item have an item key of `NULL` and are therefore **also excluded** when `IncludeSpecialInvLines` = 0. Pass 1 to be sure to get every line of the invoice.\n- `SerialNr` falls back to the serial number of another invoice line referencing the same order line if the line itself has none.\n- The setting `PrintInvLineMoneyPrecision` is read at runtime from `Settings`; shop or location specific values are not considered.\n- The result order is undefined; sort on the client side if needed.\n- An unknown invoice number returns an empty result set, no error.\n\nDocumentation: https://pixi-api-docs.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": "Returns all lines of one invoice with item, order line, price, VAT, batch and drop-shipping data, optionally including shipping cost, voucher and manual invoice lines.\n\nReturns the invoice lines of the invoice whose number equals `InvoiceNr` (exact match). The data comes from the reporting view `PV_Invlines`, which combines real invoice lines with synthetic lines for invoice-level amounts. Each line is enriched with the order line (`BatchNumber`, `BestBeforeDate`, `TaxRate` as `VATPercent`) and the item (`PicLinkLarge`).\n\n**Special lines** (controlled by `IncludeSpecialInvLines`):\n\n- `-2`: shipping costs of the invoice (`ArtName` = `ZZZ Versandkosten`), only if the invoice has shipping costs other than 0.\n- `-1`: vouchers (`ArtName` = `ZZZ Gutscheine`), price shown as negative voucher sum.\n- `-3`: manual invoice without any invoice lines (`ArtName` = `ZZZ Manuelle Rechnung ohne Artikel`), amount = invoice total minus shipping costs.\n\nWith `IncludeSpecialInvLines` = 0 (default) these lines are excluded; with 1 they are returned as well. For special lines, `OrderLineKey` holds the special value (-1, -2, -3), `ItemQty` is 1, and most item/order fields (`InvoiceLineKey`, `ArtNr`, `OrderNr`, `BoxNr`, …) are `NULL`.\n\n`ItemPriceNoVAT` is the net price rounded to the number of decimals defined in the setting `PrintInvLineMoneyPrecision` (2 if the setting is missing or 0). No sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(50) | Yes | Number of the invoice whose lines are returned (exact match on the invoice number). |\n| `IncludeSpecialInvLines` | bit | No | Whether synthetic lines for shipping costs, vouchers and manual invoices are included. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- The filter on special lines compares the item key with `NOT IN (-1, -2, -3)`. Real invoice lines without an order line or whose order line has no item have an item key of `NULL` and are therefore **also excluded** when `IncludeSpecialInvLines` = 0. Pass 1 to be sure to get every line of the invoice.\n- `SerialNr` falls back to the serial number of another invoice line referencing the same order line if the line itself has none.\n- The setting `PrintInvLineMoneyPrecision` is read at runtime from `Settings`; shop or location specific values are not considered.\n- The result order is undefined; sort on the client side if needed.\n- An unknown invoice number returns an empty result set, no error.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoice headers combined with their invoice lines in one flat result set, filtered by invoice, shop, order, customer, payment and date criteria.\n\nCombines invoice header data and invoice line data into one call. Each result row is one invoice line, with all header, billing address and payment fields repeated on every line of the same invoice.\n\n**Parameter normalisation**\n- Empty strings are treated as `NULL` for all string and date filters; `OrderNR = 0` is treated as `NULL`.\n- `RowCount` defaults to 1000; `NULL`, 0 or negative values are also replaced by 1000.\n\n**Step 1 – candidate invoices** (dynamic SQL, executed with `sp_executesql`)\nUp to `RowCount * 3` invoices are selected from `Invoices` (joined to `Customers`, left-joined to `InvLines`), ordered by invoice date. Only the filters that are set are added:\n- `InvoiceNr`: exact invoice number.\n- `ShopID`: `Customers.CustomerOf`.\n- `PaymentType`: `Invoices.Payment`.\n- `InvDateFrom` / `InvDateTo`: invoice date strictly greater / strictly less than the value.\n- `UpdateDateFrom` / `UpdateDateTo`: strictly greater / less than the value, on `InvLines.UpdateDate` (default) or on `Invoices.UpdateDate` if `ConsiderInvoiceUpdates = 1`. Records with `UpdateDate` `NULL` never match.\n- `OrderNR`: the invoice has at least one invoice line linked to an order line of that Auftrag.\n- `OrderNRExternal`: resolved to an internal order number via `OrderHeader.OrderNrExternal`, then filtered like `OrderNR`.\n- `OnlyUnpaidInvoices = 1`: paid sum differs from the total, and there is no open `CustomerAccount` entry for the invoice marked `DoNotRefund = 1` (without bank line, DTAUS or manual booking reference).\n- `CustomerNrExternal`: `Customers.CustomerNrExternal`.\n\n**Step 2 – headers and lines**\n- The first `RowCount` candidates (ordered by invoice date and invoice key) are loaded as headers. Only invoices with a matching currency, a payment code that exists in `Payments` and a billing address in `Addresses` are kept.\n- Lines are read from the view `PV_Invlines`, which also contains pseudo lines: `ItemKey = -2` shipping costs, `-1` vouchers, `-3` manual invoices without lines. Supplier price and supplier number are taken from `SupplierPrice_History` if present.\n- If `AddCCPPayID = 1`, the `ccpPayID` values of all Aufträge on the invoice are concatenated with commas into `CcpPayID`.\n\n**Step 3 – final filter and output**\n- Pseudo lines (`ItemKey` -1, -2, -3) are only returned if `IncludeSpecialInvLines = 1`.\n- `Status` filters on the order line status of the line (`AUS` if the line has no status).\n- `IsReplacementOnly = 1` returns only lines whose order line has status `MIN` or has an `OrderHistory` entry with status `MIN` (replacement deliveries).\n- At most `RowCount` rows (lines) are returned, ordered by invoice date and invoice key.\n- `UpdateDate` in the output is the line's update/create date (falling back to the invoice date) by default, or the invoice's update/create date if `ConsiderInvoiceUpdates = 1`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | No | Exact invoice number. Empty string means no filter. |\n| `ShopID` | varchar(3) | No | Shop ID of the customer (`Customers.CustomerOf`). |\n| `PaymentType` | char(1) | No | Payment code of the invoice (`Invoices.Payment`). |\n| `OrderNR` | int | No | Internal order number; returns invoices with at least one line of this Auftrag. 0 means no filter. |\n| `OrderNRExternal` | varchar(50) | No | External order number; resolved to the internal order number via `OrderHeader`. |\n| `InvDateFrom` | datetime | No | Returns invoices with invoice date strictly after this value. |\n| `InvDateTo` | datetime | No | Returns invoices with invoice date strictly before this value. |\n| `UpdateDateFrom` | datetime | No | Update date strictly after this value, on invoice lines or on the invoice depending on `ConsiderInvoiceUpdates`. |\n| `UpdateDateTo` | datetime | No | Update date strictly before this value, on invoice lines or on the invoice depending on `ConsiderInvoiceUpdates`. |\n| `RowCount` | int | No | Maximum number of invoices and of returned rows. `NULL`, 0 or negative values are replaced by 1000. |\n| `AddCCPPayID` | bit | No | If 1, fills `CcpPayID` with the comma-separated payment provider IDs of the invoice's Aufträge. |\n| `OnlyUnpaidInvoices` | bit | No | If 1, returns only invoices whose paid sum differs from the total and that have no open `DoNotRefund` customer account entry. |\n| `IncludeSpecialInvLines` | bit | No | If 1, also returns pseudo lines for shipping costs (`ItemKey` -2), vouchers (-1) and manual invoices without lines (-3). |\n| `Status` | varchar(3) | No | Order line status of the line; lines without status count as `AUS`. |\n| `CustomerNrExternal` | varchar(60) | No | External customer number (`Customers.CustomerNrExternal`). |\n| `IsReplacementOnly` | bit | No | If 1, returns only lines whose order line has or had status `MIN` (replacement). |\n| `ConsiderInvoiceUpdates` | bit | No | Selects which update date the update date filters and the output column `UpdateDate` use. |\n\n- All reads use `NOLOCK`, so uncommitted data can appear.\n- `RowCount` limits invoices **and** the final line rows. Because the final `TOP` counts lines, the lines of the last invoice can be cut off. For complete invoices, query by `InvoiceNr` or use a `RowCount` well above the expected number of lines.\n- Date bounds are exclusive (`>` and `<`), not inclusive.\n- With the default `ConsiderInvoiceUpdates = 0`, the update date filters work on invoice lines, so invoices without lines (e.g. manual invoices) never match them.\n- If `OrderNRExternal` cannot be resolved in `OrderHeader`, the result is empty. If several orders share the external number, only one of them is used.\n- Lines whose `ItemKey` is `NULL` (invoice lines without order line or item) are dropped by the `NOT IN (-1,-2,-3)` test unless `IncludeSpecialInvLines = 1`.\n- With `IsReplacementOnly = 1`, pseudo lines are never returned because they have no order line.\n- `CcpPayID` is truncated to 50 characters.\n- `Currency` is always the constant `EUR`; the actual order currency is in `OrderCurrency`.\n- `OrderDate` returns `1900-01-01` if the line has no Auftrag (empty string converted to a date). `EANUPC` is `0` for lines without an Artikel.\n- `OrderNr` appears twice in each row.\n- `Paid` is 1 only if the paid sum equals the invoice total exactly.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoice headers combined with their invoice lines in one flat result set, filtered by invoice, shop, order, customer, payment and date criteria.\n\nCombines invoice header data and invoice line data into one call. Each result row is one invoice line, with all header, billing address and payment fields repeated on every line of the same invoice.\n\n**Parameter normalisation**\n- Empty strings are treated as `NULL` for all string and date filters; `OrderNR = 0` is treated as `NULL`.\n- `RowCount` defaults to 1000; `NULL`, 0 or negative values are also replaced by 1000.\n\n**Step 1 – candidate invoices** (dynamic SQL, executed with `sp_executesql`)\nUp to `RowCount * 3` invoices are selected from `Invoices` (joined to `Customers`, left-joined to `InvLines`), ordered by invoice date. Only the filters that are set are added:\n- `InvoiceNr`: exact invoice number.\n- `ShopID`: `Customers.CustomerOf`.\n- `PaymentType`: `Invoices.Payment`.\n- `InvDateFrom` / `InvDateTo`: invoice date strictly greater / strictly less than the value.\n- `UpdateDateFrom` / `UpdateDateTo`: strictly greater / less than the value, on `InvLines.UpdateDate` (default) or on `Invoices.UpdateDate` if `ConsiderInvoiceUpdates = 1`. Records with `UpdateDate` `NULL` never match.\n- `OrderNR`: the invoice has at least one invoice line linked to an order line of that Auftrag.\n- `OrderNRExternal`: resolved to an internal order number via `OrderHeader.OrderNrExternal`, then filtered like `OrderNR`.\n- `OnlyUnpaidInvoices = 1`: paid sum differs from the total, and there is no open `CustomerAccount` entry for the invoice marked `DoNotRefund = 1` (without bank line, DTAUS or manual booking reference).\n- `CustomerNrExternal`: `Customers.CustomerNrExternal`.\n\n**Step 2 – headers and lines**\n- The first `RowCount` candidates (ordered by invoice date and invoice key) are loaded as headers. Only invoices with a matching currency, a payment code that exists in `Payments` and a billing address in `Addresses` are kept.\n- Lines are read from the view `PV_Invlines`, which also contains pseudo lines: `ItemKey = -2` shipping costs, `-1` vouchers, `-3` manual invoices without lines. Supplier price and supplier number are taken from `SupplierPrice_History` if present.\n- If `AddCCPPayID = 1`, the `ccpPayID` values of all Aufträge on the invoice are concatenated with commas into `CcpPayID`.\n\n**Step 3 – final filter and output**\n- Pseudo lines (`ItemKey` -1, -2, -3) are only returned if `IncludeSpecialInvLines = 1`.\n- `Status` filters on the order line status of the line (`AUS` if the line has no status).\n- `IsReplacementOnly = 1` returns only lines whose order line has status `MIN` or has an `OrderHistory` entry with status `MIN` (replacement deliveries).\n- At most `RowCount` rows (lines) are returned, ordered by invoice date and invoice key.\n- `UpdateDate` in the output is the line's update/create date (falling back to the invoice date) by default, or the invoice's update/create date if `ConsiderInvoiceUpdates = 1`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | No | Exact invoice number. Empty string means no filter. |\n| `ShopID` | varchar(3) | No | Shop ID of the customer (`Customers.CustomerOf`). |\n| `PaymentType` | char(1) | No | Payment code of the invoice (`Invoices.Payment`). |\n| `OrderNR` | int | No | Internal order number; returns invoices with at least one line of this Auftrag. 0 means no filter. |\n| `OrderNRExternal` | varchar(50) | No | External order number; resolved to the internal order number via `OrderHeader`. |\n| `InvDateFrom` | datetime | No | Returns invoices with invoice date strictly after this value. |\n| `InvDateTo` | datetime | No | Returns invoices with invoice date strictly before this value. |\n| `UpdateDateFrom` | datetime | No | Update date strictly after this value, on invoice lines or on the invoice depending on `ConsiderInvoiceUpdates`. |\n| `UpdateDateTo` | datetime | No | Update date strictly before this value, on invoice lines or on the invoice depending on `ConsiderInvoiceUpdates`. |\n| `RowCount` | int | No | Maximum number of invoices and of returned rows. `NULL`, 0 or negative values are replaced by 1000. |\n| `AddCCPPayID` | bit | No | If 1, fills `CcpPayID` with the comma-separated payment provider IDs of the invoice's Aufträge. |\n| `OnlyUnpaidInvoices` | bit | No | If 1, returns only invoices whose paid sum differs from the total and that have no open `DoNotRefund` customer account entry. |\n| `IncludeSpecialInvLines` | bit | No | If 1, also returns pseudo lines for shipping costs (`ItemKey` -2), vouchers (-1) and manual invoices without lines (-3). |\n| `Status` | varchar(3) | No | Order line status of the line; lines without status count as `AUS`. |\n| `CustomerNrExternal` | varchar(60) | No | External customer number (`Customers.CustomerNrExternal`). |\n| `IsReplacementOnly` | bit | No | If 1, returns only lines whose order line has or had status `MIN` (replacement). |\n| `ConsiderInvoiceUpdates` | bit | No | Selects which update date the update date filters and the output column `UpdateDate` use. |\n\n- All reads use `NOLOCK`, so uncommitted data can appear.\n- `RowCount` limits invoices **and** the final line rows. Because the final `TOP` counts lines, the lines of the last invoice can be cut off. For complete invoices, query by `InvoiceNr` or use a `RowCount` well above the expected number of lines.\n- Date bounds are exclusive (`>` and `<`), not inclusive.\n- With the default `ConsiderInvoiceUpdates = 0`, the update date filters work on invoice lines, so invoices without lines (e.g. manual invoices) never match them.\n- If `OrderNRExternal` cannot be resolved in `OrderHeader`, the result is empty. If several orders share the external number, only one of them is used.\n- Lines whose `ItemKey` is `NULL` (invoice lines without order line or item) are dropped by the `NOT IN (-1,-2,-3)` test unless `IncludeSpecialInvLines = 1`.\n- With `IsReplacementOnly = 1`, pseudo lines are never returned because they have no order line.\n- `CcpPayID` is truncated to 50 characters.\n- `Currency` is always the constant `EUR`; the actual order currency is in `OrderCurrency`.\n- `OrderDate` returns `1900-01-01` if the line has no Auftrag (empty string converted to a date). `EANUPC` is `0` for lines without an Artikel.\n- `OrderNr` appears twice in each row.\n- `Paid` is 1 only if the paid sum equals the invoice total exactly.\n\nDocumentation: https://pixi-api-docs.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": "Returns the lines of an invoice prepared for printing, grouped per order line, with optional bundle combining and a fallback line for invoices without lines.\n\nThe call passes `InvoiceNr` to the internal procedure `GOS_PrintInvLine` and returns its single result set.\n\n**Steps:**\n\n1. The invoice is looked up by `InvoiceNr` in `Invoices` (joined with `pixi.Currency`). Its key, pick list header (`PLHref`), credit-note reference (`RefToInvoiceKey`) and `DiscountTotal` are read.\n2. All invoice lines (`Invlines`) of the invoice are joined with their order lines, items, country of origin and the item code of type 3 (`InternalItemNumber`). Lines are grouped by the parent order line (`OriginalOrderlineRef`, or the order line itself if it was not split) plus price, VAT, discount, serial number, batch, best-before date and further attributes. Quantities and amounts are summed per group.\n3. For each line the first bin name and the number of pick list items are taken from the pick list of the invoice (`BinName`, `QtyFromBin`).\n4. **Bundles:** if the setting `CombineBundles` = 1 and the invoice is not a credit note (`RefToInvoiceKey` is NULL), all component lines of a bundle are combined into one line with the data of the bundle order line (`BundleOrderlines`) and the bundle item. The number of bundles is derived from the component quantity divided by the quantity per bundle from `BundleItemsHistDetail` (or the bundle order line quantity if no history exists). Otherwise every component line is returned on its own.\n5. If no line results (invoice without lines), one pseudo line is built from the invoice header: text from `TextIfNoInvlines`, `OrderQty` = 1, price = invoice total minus shipping cost, VAT code and tax rate derived from the high/low VAT bases. In this row `OrderNr` holds the invoice key and `OrderNrExternal` the invoice number.\n6. The result is sorted by `ArtName`. Each row additionally carries the invoice-level discount as `InvoiceTotalDiscount`.\n\nThe setting `UseInitialOrderDate` controls `OrderDate`: 0 returns the latest order date of the grouped order lines, 1 the earliest.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(50) | Yes | Invoice number (`Invoices.InvoiceNr`) of the invoice whose lines are returned. Only the first 25 characters are used. |\n\n- The parameter is declared as `varchar(50)`, but the internal procedure accepts only `varchar(25)`; longer invoice numbers are silently truncated.\n- If the invoice number does not exist (or the invoice has no matching currency in `pixi.Currency`), the result set is empty; no error is returned.\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- The settings `CombineBundles` and `UseInitialOrderDate` are read at runtime via `fpixi_GetSetting`; `ItemTagList` is built by `fpixi_GetItemTAGsNamesAsString`. Neither function is attached.\n- Columns such as `itemprice_ordercurr`, `ItemAmount_OrderCurr`, `USDamount` and `EURamount` are legacy duplicates (comments mark them for removal); they contain the same values as the invoice-currency columns.\n- `ItemAmount` includes the line amount differences (`InvLineAmountDiff`), whereas `ItemAmountNoVAT_OrderCurr` is the plain sum of the net line amounts.\n\nDocumentation: https://pixi-api-docs.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": "Returns the lines of an invoice prepared for printing, grouped per order line, with optional bundle combining and a fallback line for invoices without lines.\n\nThe call passes `InvoiceNr` to the internal procedure `GOS_PrintInvLine` and returns its single result set.\n\n**Steps:**\n\n1. The invoice is looked up by `InvoiceNr` in `Invoices` (joined with `pixi.Currency`). Its key, pick list header (`PLHref`), credit-note reference (`RefToInvoiceKey`) and `DiscountTotal` are read.\n2. All invoice lines (`Invlines`) of the invoice are joined with their order lines, items, country of origin and the item code of type 3 (`InternalItemNumber`). Lines are grouped by the parent order line (`OriginalOrderlineRef`, or the order line itself if it was not split) plus price, VAT, discount, serial number, batch, best-before date and further attributes. Quantities and amounts are summed per group.\n3. For each line the first bin name and the number of pick list items are taken from the pick list of the invoice (`BinName`, `QtyFromBin`).\n4. **Bundles:** if the setting `CombineBundles` = 1 and the invoice is not a credit note (`RefToInvoiceKey` is NULL), all component lines of a bundle are combined into one line with the data of the bundle order line (`BundleOrderlines`) and the bundle item. The number of bundles is derived from the component quantity divided by the quantity per bundle from `BundleItemsHistDetail` (or the bundle order line quantity if no history exists). Otherwise every component line is returned on its own.\n5. If no line results (invoice without lines), one pseudo line is built from the invoice header: text from `TextIfNoInvlines`, `OrderQty` = 1, price = invoice total minus shipping cost, VAT code and tax rate derived from the high/low VAT bases. In this row `OrderNr` holds the invoice key and `OrderNrExternal` the invoice number.\n6. The result is sorted by `ArtName`. Each row additionally carries the invoice-level discount as `InvoiceTotalDiscount`.\n\nThe setting `UseInitialOrderDate` controls `OrderDate`: 0 returns the latest order date of the grouped order lines, 1 the earliest.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(50) | Yes | Invoice number (`Invoices.InvoiceNr`) of the invoice whose lines are returned. Only the first 25 characters are used. |\n\n- The parameter is declared as `varchar(50)`, but the internal procedure accepts only `varchar(25)`; longer invoice numbers are silently truncated.\n- If the invoice number does not exist (or the invoice has no matching currency in `pixi.Currency`), the result set is empty; no error is returned.\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- The settings `CombineBundles` and `UseInitialOrderDate` are read at runtime via `fpixi_GetSetting`; `ItemTagList` is built by `fpixi_GetItemTAGsNamesAsString`. Neither function is attached.\n- Columns such as `itemprice_ordercurr`, `ItemAmount_OrderCurr`, `USDamount` and `EURamount` are legacy duplicates (comments mark them for removal); they contain the same values as the invoice-currency columns.\n- `ItemAmount` includes the line amount differences (`InvLineAmountDiff`), whereas `ItemAmountNoVAT_OrderCurr` is the plain sum of the net line amounts.\n\nDocumentation: https://pixi-api-docs.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": "Returns the package lines of invoice packages for an invoice (by ID or number) or for a single package, with item number, invoice line and quantity.\n\nReturns the lines of invoice packages (`pixi.InvoicePackageLines`). Each line links a package to an invoice line and a quantity.\n\n**Input and validation**\n\n- At least one of `InvoiceNumber`, `InvoiceId` or `PackageId` must be given. An empty `InvoiceNumber` counts as not given.\n- `InvoiceNumber` is resolved to an invoice key. If both `InvoiceId` and `InvoiceNumber` are given, they must point to the same invoice.\n- If `PackageId` is given, the package must have package lines. If an invoice is also given, the package must belong to that invoice.\n- If an invoice is given, at least one package of that invoice must have package lines.\n- If a check fails, the call returns one `Status`/`Message` row with `Status` = `Error`. No further result set follows.\n\n**Selection**\n\n- **Only an invoice given:** all packages of the invoice are used.\n- **`PackageId` given, with or without an invoice:** only this package is used.\n- Invoices are discarded if they have no invoice lines, or if a joined invoice line has no order line reference (`OrderLineRef`).\n- The call matches the package lines with the invoice lines of the selected invoices. It returns only lines whose item has an internal item number (`pixi.ItemCode`, code type 2).\n- `InvoiceNr` is the same value in all rows. It is the number of the selected invoice.\n\nThe result has no explicit sort order. If no line matches, the call returns an `Info` status row.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNumber` | varchar(20) | No | Invoice number (`InvoiceNr`). An empty string is treated as NULL. If `InvoiceId` is also given, both must refer to the same invoice. |\n| `InvoiceId` | int | No | Invoice key (`InvoiceKey`) of the invoice whose package lines are returned. |\n| `PackageId` | int | No | ID of an invoice package. If given, only the lines of this package are returned. If an invoice is also given, the package must belong to it. |\n\n- All reads use `NOLOCK`. Data that is being written at the same time can show up uncommitted.\n- A code comment says that these packages are created by the Delphi ShipOut process.\n- Pitfall: the invoice is discarded completely if any of its joined invoice lines has no `OrderLineRef`. In that case the call returns the `Info` row and no lines, even if the invoice has package lines.\n- Lines whose item has no internal item number (code type 2 in `pixi.ItemCode`) do not appear. If an item has several codes of type 2, its lines are returned more than once.\n- Error and info rows come back in the normal result set with the columns `Status` and `Message`. No SQL error is raised. The return code is 1 for errors and 0 otherwise.\n\nDocumentation: https://pixi-api-docs.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": "Returns the package lines of invoice packages for an invoice (by ID or number) or for a single package, with item number, invoice line and quantity.\n\nReturns the lines of invoice packages (`pixi.InvoicePackageLines`). Each line links a package to an invoice line and a quantity.\n\n**Input and validation**\n\n- At least one of `InvoiceNumber`, `InvoiceId` or `PackageId` must be given. An empty `InvoiceNumber` counts as not given.\n- `InvoiceNumber` is resolved to an invoice key. If both `InvoiceId` and `InvoiceNumber` are given, they must point to the same invoice.\n- If `PackageId` is given, the package must have package lines. If an invoice is also given, the package must belong to that invoice.\n- If an invoice is given, at least one package of that invoice must have package lines.\n- If a check fails, the call returns one `Status`/`Message` row with `Status` = `Error`. No further result set follows.\n\n**Selection**\n\n- **Only an invoice given:** all packages of the invoice are used.\n- **`PackageId` given, with or without an invoice:** only this package is used.\n- Invoices are discarded if they have no invoice lines, or if a joined invoice line has no order line reference (`OrderLineRef`).\n- The call matches the package lines with the invoice lines of the selected invoices. It returns only lines whose item has an internal item number (`pixi.ItemCode`, code type 2).\n- `InvoiceNr` is the same value in all rows. It is the number of the selected invoice.\n\nThe result has no explicit sort order. If no line matches, the call returns an `Info` status row.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNumber` | varchar(20) | No | Invoice number (`InvoiceNr`). An empty string is treated as NULL. If `InvoiceId` is also given, both must refer to the same invoice. |\n| `InvoiceId` | int | No | Invoice key (`InvoiceKey`) of the invoice whose package lines are returned. |\n| `PackageId` | int | No | ID of an invoice package. If given, only the lines of this package are returned. If an invoice is also given, the package must belong to it. |\n\n- All reads use `NOLOCK`. Data that is being written at the same time can show up uncommitted.\n- A code comment says that these packages are created by the Delphi ShipOut process.\n- Pitfall: the invoice is discarded completely if any of its joined invoice lines has no `OrderLineRef`. In that case the call returns the `Info` row and no lines, even if the invoice has package lines.\n- Lines whose item has no internal item number (code type 2 in `pixi.ItemCode`) do not appear. If an item has several codes of type 2, its lines are returned more than once.\n- Error and info rows come back in the normal result set with the columns `Status` and `Message`. No SQL error is raised. The return code is 1 for errors and 0 otherwise.\n\nDocumentation: https://pixi-api-docs.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": "Returns a public download link with expiration date for the stored document of an invoice, identified by invoice ID and/or invoice number.\n\nResolves an invoice and returns a public download link for its stored document.\n\n1. `InvoiceNr` is trimmed. An empty value is treated as not provided.\n2. At least one of `InvoiceId` or `InvoiceNr` must be given. Otherwise an error row is returned.\n3. **Both given:** the invoice must match both `InvoiceKey = InvoiceId` and `InvoiceNr`.\n - If no invoice matches both, but an invoice exists with either the ID or the number, the call returns the error `InvoiceId and InvoiceNr do not match.`\n - If neither exists, it returns `Invoice Not Found.`\n4. **Only one given:** the invoice is looked up by that value. If nothing is found, it returns `Invoice Not Found.`\n5. If the invoice has no linked document (`DocumentStorageId` is empty), it returns `Document Not Found.`\n6. The download link and its expiration date are generated by the internal procedure `pixi.DocumentPublicLink_Get`. If that procedure reports a non-zero status, it returns `Failed to generate invoice download link.`\n7. On success, one row is returned with the invoice ID, the resolved invoice number, the download link and the link expiration date.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceId` | int | No | Internal invoice key (`InvoiceKey`). Optional if `InvoiceNr` is given. If both are given, they must belong to the same invoice. |\n| `InvoiceNr` | varchar(20) | No | Invoice number. It is trimmed, and an empty value is treated as not provided. Optional if `InvoiceId` is given. |\n\n- The link itself is produced by `pixi.DocumentPublicLink_Get`. Its definition is not attached, so the following is not visible from this code:\n - the link format,\n - the validity period,\n - whether link records are stored in the database.\n- Errors are returned as a normal row with `Status` = `Error` and `Message`. They are not raised as SQL errors. The procedure return code is 1 on error and 0 on success.\n- Invoices are read with `NOLOCK`, so uncommitted data may be seen.\n- The lookup uses `TOP (1)` without `ORDER BY`. If several invoices share the same `InvoiceNr`, the invoice returned for a lookup by number alone is arbitrary. Pass `InvoiceId` to get a deterministic result.\n\nDocumentation: https://pixi-api-docs.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": "Returns a public download link with expiration date for the stored document of an invoice, identified by invoice ID and/or invoice number.\n\nResolves an invoice and returns a public download link for its stored document.\n\n1. `InvoiceNr` is trimmed. An empty value is treated as not provided.\n2. At least one of `InvoiceId` or `InvoiceNr` must be given. Otherwise an error row is returned.\n3. **Both given:** the invoice must match both `InvoiceKey = InvoiceId` and `InvoiceNr`.\n - If no invoice matches both, but an invoice exists with either the ID or the number, the call returns the error `InvoiceId and InvoiceNr do not match.`\n - If neither exists, it returns `Invoice Not Found.`\n4. **Only one given:** the invoice is looked up by that value. If nothing is found, it returns `Invoice Not Found.`\n5. If the invoice has no linked document (`DocumentStorageId` is empty), it returns `Document Not Found.`\n6. The download link and its expiration date are generated by the internal procedure `pixi.DocumentPublicLink_Get`. If that procedure reports a non-zero status, it returns `Failed to generate invoice download link.`\n7. On success, one row is returned with the invoice ID, the resolved invoice number, the download link and the link expiration date.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceId` | int | No | Internal invoice key (`InvoiceKey`). Optional if `InvoiceNr` is given. If both are given, they must belong to the same invoice. |\n| `InvoiceNr` | varchar(20) | No | Invoice number. It is trimmed, and an empty value is treated as not provided. Optional if `InvoiceId` is given. |\n\n- The link itself is produced by `pixi.DocumentPublicLink_Get`. Its definition is not attached, so the following is not visible from this code:\n - the link format,\n - the validity period,\n - whether link records are stored in the database.\n- Errors are returned as a normal row with `Status` = `Error` and `Message`. They are not raised as SQL errors. The procedure return code is 1 on error and 0 on success.\n- Invoices are read with `NOLOCK`, so uncommitted data may be seen.\n- The lookup uses `TOP (1)` without `ORDER BY`. If several invoices share the same `InvoiceNr`, the invoice returned for a lookup by number alone is arbitrary. Pass `InvoiceId` to get a deterministic result.\n\nDocumentation: https://pixi-api-docs.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": "Returns all invoices that contain lines of the given order, with payment, bank/credit card, shipping and currency data.\n\nLooks up every invoice that is linked to the order `OrderNr` through its invoice lines: the order lines of the order are joined to the invoice lines (`OrderLineRef`), and each referenced invoice is returned once.\n\nFor each invoice the call returns:\n\n- **Invoice data**: number, date, payment and shipment address IDs, total.\n- **Payment data**:\n - the payment code and its text from the payment types. If no text exists, the code itself is returned as text.\n - payment date and paid sum.\n - a computed `Paid` flag.\n- **Bank and credit card data** of the payment address (`AddrRef`).\n- **Shipping data**: tracking ID, scan-out date as ship date, and the reminder level.\n- **Order data**: `OrderNr`, plus `OrderNrExternal` with surrounding spaces removed.\n- **Currency**: the ISO code (`CodeA`) of the invoice currency.\n\n`Paid` is `1` when `PayedSum` (NULL treated as 0) equals `total`, otherwise `0`.\n\nThe result has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Pixi order number whose invoices are returned. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may appear.\n- Invoices are only returned if the payment address exists in `Addresses` and the currency exists in `Currency`. Both are inner joins.\n- `Paid` is `0` for overpaid invoices as well, because the code checks for equality, not for 'paid sum ≥ total'.\n- If `total` is NULL, `Paid` is `1`.\n- If the order lines carry different `OrderNrExternal` values, the maximum value is returned for all invoices.\n- The result contains sensitive payment data (account number, credit card number), so the output must be handled accordingly.\n\nDocumentation: https://pixi-api-docs.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": "Returns all invoices that contain lines of the given order, with payment, bank/credit card, shipping and currency data.\n\nLooks up every invoice that is linked to the order `OrderNr` through its invoice lines: the order lines of the order are joined to the invoice lines (`OrderLineRef`), and each referenced invoice is returned once.\n\nFor each invoice the call returns:\n\n- **Invoice data**: number, date, payment and shipment address IDs, total.\n- **Payment data**:\n - the payment code and its text from the payment types. If no text exists, the code itself is returned as text.\n - payment date and paid sum.\n - a computed `Paid` flag.\n- **Bank and credit card data** of the payment address (`AddrRef`).\n- **Shipping data**: tracking ID, scan-out date as ship date, and the reminder level.\n- **Order data**: `OrderNr`, plus `OrderNrExternal` with surrounding spaces removed.\n- **Currency**: the ISO code (`CodeA`) of the invoice currency.\n\n`Paid` is `1` when `PayedSum` (NULL treated as 0) equals `total`, otherwise `0`.\n\nThe result has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Pixi order number whose invoices are returned. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may appear.\n- Invoices are only returned if the payment address exists in `Addresses` and the currency exists in `Currency`. Both are inner joins.\n- `Paid` is `0` for overpaid invoices as well, because the code checks for equality, not for 'paid sum ≥ total'.\n- If `total` is NULL, `Paid` is `1`.\n- If the order lines carry different `OrderNrExternal` values, the maximum value is returned for all invoices.\n- The result contains sensitive payment data (account number, credit card number), so the output must be handled accordingly.\n\nDocumentation: https://pixi-api-docs.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": "Returns the invoices of one customer, identified by customer key or external customer number, optionally filtered to a single invoice number.\n\nLists invoices together with payment, bank or card, shipping and order information for one customer.\n\n**Identifying the customer**\n\n`NULL` values are first replaced by `0` (for `CustKey`) or an empty string. Then exactly one identifier must be set:\n\n- `CustKey` <> 0 and `CustomerNrExternal` empty: the invoices of this customer key are returned.\n- `CustKey` = 0 and `CustomerNrExternal` set: all customers in `Customers` with this `CustomerNrExternal` are used. If several customers share the number, the invoices of all of them are returned.\n- Both set or both empty: no customer is selected and the result set is empty.\n\n**Invoice filter**\n\n- If `InvoiceNr` is empty or `NULL`, all invoices of the customer are returned.\n- Otherwise only the invoice with exactly this `InvoiceNr` is returned.\n\n**Returned data per invoice**\n\n- Invoice data from `Invoices`: number, date, payment and shipment address IDs, total, payment code, payment date, paid amount, tracking ID, ship date and reminder level.\n- `PaymentText` comes from `Payments`. If the code is not found there, the payment code itself is returned.\n- `Paid` is `1` if the paid amount (a missing amount counts as 0) equals the total, otherwise `0`.\n- Card and bank data (`Cc…`, `Account`, `Blz`, `BankName`, `AccountName`) come from the payment address in `Addresses`.\n- `OrderNr` and `OrderNrExternal` are the highest values found among the order lines linked to the invoice lines. They are `NULL` if the invoice has no linked order lines.\n- `OrderCurrencyCode` is the currency code from `pixi.Currency`.\n\nThe code does not define a sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | No | Internal customer key. Use either this or `CustomerNrExternal`. 0 or `NULL` means not set. |\n| `CustomerNrExternal` | varchar(60) | No | External customer number, for example the shop customer number. It is used only if `CustKey` is 0. Empty or `NULL` means not set. |\n| `InvoiceNr` | varchar(20) | No | Optional invoice number. If it is set, only this invoice is returned. Empty or `NULL` returns all invoices of the customer. |\n\n- All tables are read `WITH (NOLOCK)`, so uncommitted data can appear in the result.\n- `pixi.Currency` is joined with an inner join. Invoices whose `CurrencyId` has no matching currency are not returned.\n- If `CustKey` and `CustomerNrExternal` are both sent, the call returns no rows and no error. Send only one of them.\n- If the invoice total is `NULL`, the comparison for `Paid` is not true and the column returns `1`.\n- The result contains sensitive payment data: card number, card holder, card expiry and bank account.\n\nDocumentation: https://pixi-api-docs.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": "Returns the invoices of one customer, identified by customer key or external customer number, optionally filtered to a single invoice number.\n\nLists invoices together with payment, bank or card, shipping and order information for one customer.\n\n**Identifying the customer**\n\n`NULL` values are first replaced by `0` (for `CustKey`) or an empty string. Then exactly one identifier must be set:\n\n- `CustKey` <> 0 and `CustomerNrExternal` empty: the invoices of this customer key are returned.\n- `CustKey` = 0 and `CustomerNrExternal` set: all customers in `Customers` with this `CustomerNrExternal` are used. If several customers share the number, the invoices of all of them are returned.\n- Both set or both empty: no customer is selected and the result set is empty.\n\n**Invoice filter**\n\n- If `InvoiceNr` is empty or `NULL`, all invoices of the customer are returned.\n- Otherwise only the invoice with exactly this `InvoiceNr` is returned.\n\n**Returned data per invoice**\n\n- Invoice data from `Invoices`: number, date, payment and shipment address IDs, total, payment code, payment date, paid amount, tracking ID, ship date and reminder level.\n- `PaymentText` comes from `Payments`. If the code is not found there, the payment code itself is returned.\n- `Paid` is `1` if the paid amount (a missing amount counts as 0) equals the total, otherwise `0`.\n- Card and bank data (`Cc…`, `Account`, `Blz`, `BankName`, `AccountName`) come from the payment address in `Addresses`.\n- `OrderNr` and `OrderNrExternal` are the highest values found among the order lines linked to the invoice lines. They are `NULL` if the invoice has no linked order lines.\n- `OrderCurrencyCode` is the currency code from `pixi.Currency`.\n\nThe code does not define a sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | No | Internal customer key. Use either this or `CustomerNrExternal`. 0 or `NULL` means not set. |\n| `CustomerNrExternal` | varchar(60) | No | External customer number, for example the shop customer number. It is used only if `CustKey` is 0. Empty or `NULL` means not set. |\n| `InvoiceNr` | varchar(20) | No | Optional invoice number. If it is set, only this invoice is returned. Empty or `NULL` returns all invoices of the customer. |\n\n- All tables are read `WITH (NOLOCK)`, so uncommitted data can appear in the result.\n- `pixi.Currency` is joined with an inner join. Invoices whose `CurrencyId` has no matching currency are not returned.\n- If `CustKey` and `CustomerNrExternal` are both sent, the call returns no rows and no error. Send only one of them.\n- If the invoice total is `NULL`, the comparison for `Paid` is not true and the column returns `1`.\n- The result contains sensitive payment data: card number, card holder, card expiry and bank account.\n\nDocumentation: https://pixi-api-docs.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": "Returns shipping-relevant information for one invoice: payment, ship vendor, totals, shipping address with country data, order details and package weights.\n\nLooks up the invoice with the given `InvoiceNr` and returns one row of data that a shipping or label tool typically needs.\n\nThe row is built as follows:\n- **Invoice**: number, date, shop, payment code, ship vendor code, total and shipping cost from `Invoices`.\n- **Currency**: the currency code (`CodeA`) of the invoice currency. This join is an inner join, so an invoice without a matching currency record returns no row.\n- **Payment and ship vendor**: text of the payment method and name of the ship vendor (optional, may be empty).\n- **Shipping address**: the address referenced by the invoice's shipping address reference (`ShipAdrRef`), including name parts, street, house number, city, ZIP, mailbox, phone, e-mail and VAT ID.\n- **Country**: country name, EasyLog country name and ISO2/ISO3 codes of the address country.\n- **Order**: the related order is determined via the invoice lines: the first invoice line found points to an order line, and the order of that order line is used. From it the call returns address remarks, DHL procedure/product/extras, gift message, ship date, shop note, order number and external order number.\n- **Weights**: net and gross package weight, rounded to 3 decimals.\n\nIf no invoice with this number exists, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(50) | Yes | Number of the invoice (`Invoices.InvoiceNr`) to return shipping information for. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- The order is found with `TOP 1` subqueries without `ORDER BY`. If an invoice contains lines from several orders, only one of them is used and which one is not deterministic.\n- `Total_OrderCurr` always equals `Total` and `ShipCost_OrderCurr` always equals `ShipCost`; code comments mark these columns for removal, so do not rely on them.\n- `PackageNetWeight` and `PackageGrossWeight` are referenced without a table alias; from the code it cannot be seen whether they come from `Invoices` or `OrderHeader`.\n- No error rows are returned; an unknown invoice number simply yields no rows.\n\nDocumentation: https://pixi-api-docs.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": "Returns shipping-relevant information for one invoice: payment, ship vendor, totals, shipping address with country data, order details and package weights.\n\nLooks up the invoice with the given `InvoiceNr` and returns one row of data that a shipping or label tool typically needs.\n\nThe row is built as follows:\n- **Invoice**: number, date, shop, payment code, ship vendor code, total and shipping cost from `Invoices`.\n- **Currency**: the currency code (`CodeA`) of the invoice currency. This join is an inner join, so an invoice without a matching currency record returns no row.\n- **Payment and ship vendor**: text of the payment method and name of the ship vendor (optional, may be empty).\n- **Shipping address**: the address referenced by the invoice's shipping address reference (`ShipAdrRef`), including name parts, street, house number, city, ZIP, mailbox, phone, e-mail and VAT ID.\n- **Country**: country name, EasyLog country name and ISO2/ISO3 codes of the address country.\n- **Order**: the related order is determined via the invoice lines: the first invoice line found points to an order line, and the order of that order line is used. From it the call returns address remarks, DHL procedure/product/extras, gift message, ship date, shop note, order number and external order number.\n- **Weights**: net and gross package weight, rounded to 3 decimals.\n\nIf no invoice with this number exists, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(50) | Yes | Number of the invoice (`Invoices.InvoiceNr`) to return shipping information for. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- The order is found with `TOP 1` subqueries without `ORDER BY`. If an invoice contains lines from several orders, only one of them is used and which one is not deterministic.\n- `Total_OrderCurr` always equals `Total` and `ShipCost_OrderCurr` always equals `ShipCost`; code comments mark these columns for removal, so do not rely on them.\n- `PackageNetWeight` and `PackageGrossWeight` are referenced without a table alias; from the code it cannot be seen whether they come from `Invoices` or `OrderHeader`.\n- No error rows are returned; an unknown invoice number simply yields no rows.\n\nDocumentation: https://pixi-api-docs.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": "Returns all invoices in a date range with the DATEV account number of the customer and the shipping address, optionally filtered by shop.\n\nLists invoices together with the customer's DATEV account number and the shipping address of the invoice. According to the header comment, the call was created for one specific customer (\"Customer LLL\").\n\nSteps:\n\n1. An empty `ShopID` is treated like `NULL`, which means all shops.\n2. If `DateFrom` is not passed, it is set to the start of the day 30 days ago (00:00:00).\n3. If `DateTo` is not passed, it is set to the end of the current day (23:59:59.997).\n4. The invoices come from the view or table `PV_Rechnungen`. Only invoices with `Rechnungsdatum >= DateFrom` and `Rechnungsdatum < DateTo` are returned. The upper bound is **exclusive**.\n5. Each invoice is joined via its invoice number to `Invoices`. From there the customer (`Customers`, for the DATEV account number) and the shipping address (`Addresses` via `ShipAdrRef`) are read. The country name comes from `Countries`.\n6. If `ShopID` is set, only invoices whose `InvShopID` matches are returned.\n\nThe result has no defined sort order and no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | No | Shop ID to filter by (`InvShopID` of the invoice). `NULL` or empty returns invoices of all shops. |\n| `DateFrom` | datetime | No | Start of the period (inclusive), compared with the invoice date. If `NULL`, the start of the day 30 days ago is used. |\n| `DateTo` | datetime | No | End of the period (exclusive), compared with the invoice date. If `NULL`, the end of the current day (23:59:59.997) is used. |\n\n- All tables are read with `NOLOCK`. The result can contain uncommitted data.\n- `DateTo` is compared with `<`. If a pure date such as `2024-03-31T00:00:00` is passed, invoices from that day are **not** included. To include them, pass the following day or a time at the end of the day.\n- The joins are `LEFT JOIN`s. Without a shop filter, invoices that have no matching entry in `Invoices`, `Customers`, `Addresses` or `Countries` are still returned, with `NULL` values in the missing columns. With a shop filter, invoices without a matching `Invoices` row are excluded.\n- `Firma` is filled from the `CareOf` field of the address.\n- `PV_Rechnungen` is not attached. Whether it is a view and how it selects invoices cannot be seen from the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns all invoices in a date range with the DATEV account number of the customer and the shipping address, optionally filtered by shop.\n\nLists invoices together with the customer's DATEV account number and the shipping address of the invoice. According to the header comment, the call was created for one specific customer (\"Customer LLL\").\n\nSteps:\n\n1. An empty `ShopID` is treated like `NULL`, which means all shops.\n2. If `DateFrom` is not passed, it is set to the start of the day 30 days ago (00:00:00).\n3. If `DateTo` is not passed, it is set to the end of the current day (23:59:59.997).\n4. The invoices come from the view or table `PV_Rechnungen`. Only invoices with `Rechnungsdatum >= DateFrom` and `Rechnungsdatum < DateTo` are returned. The upper bound is **exclusive**.\n5. Each invoice is joined via its invoice number to `Invoices`. From there the customer (`Customers`, for the DATEV account number) and the shipping address (`Addresses` via `ShipAdrRef`) are read. The country name comes from `Countries`.\n6. If `ShopID` is set, only invoices whose `InvShopID` matches are returned.\n\nThe result has no defined sort order and no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | No | Shop ID to filter by (`InvShopID` of the invoice). `NULL` or empty returns invoices of all shops. |\n| `DateFrom` | datetime | No | Start of the period (inclusive), compared with the invoice date. If `NULL`, the start of the day 30 days ago is used. |\n| `DateTo` | datetime | No | End of the period (exclusive), compared with the invoice date. If `NULL`, the end of the current day (23:59:59.997) is used. |\n\n- All tables are read with `NOLOCK`. The result can contain uncommitted data.\n- `DateTo` is compared with `<`. If a pure date such as `2024-03-31T00:00:00` is passed, invoices from that day are **not** included. To include them, pass the following day or a time at the end of the day.\n- The joins are `LEFT JOIN`s. Without a shop filter, invoices that have no matching entry in `Invoices`, `Customers`, `Addresses` or `Countries` are still returned, with `NULL` values in the missing columns. With a shop filter, invoices without a matching `Invoices` row are excluded.\n- `Firma` is filled from the `CareOf` field of the address.\n- `PV_Rechnungen` is not attached. Whether it is a view and how it selects invoices cannot be seen from the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns all unpaid invoices, or with `PaidInvoices` = 1 all paid invoices, with payment, bank, address and currency details, sorted by invoice date.\n\nReads invoices from `Invoices` together with the customer, the payment method, the invoice (billing) address, its country and the invoice currency.\n\nThe parameter `PaidInvoices` selects one of two modes:\n\n- `0` (default): **unpaid invoices**. An invoice is returned if the paid sum (`PayedSum`, NULL counts as 0) is not exactly equal to the invoice total rounded to 2 decimals, **and** there is no entry in `CustomerAccount` for this customer and invoice that has `DoNotRefund = 1` and no bank line, DTAUS or manual booking reference.\n- `1`: **paid invoices**. An invoice is returned if the paid sum differs from the rounded total by less than 0.01, **or** such a `DoNotRefund` entry in `CustomerAccount` exists.\n\nOnly invoices for which a currency, a customer, a payment method (`Payments.Code` = invoice payment code) and an invoice address exist are returned (inner joins). The country is optional.\n\nThe result is sorted by invoice date ascending. There is no paging; all matching invoices are returned.\n\nColumn logic:\n- `Paid` is 1 only if the paid sum equals the rounded total exactly; otherwise 0.\n- `PaymentDate` is the invoice pay day if `Paid` = 1, otherwise NULL.\n- `PaymentText` is the text of the payment method, falling back to the payment code.\n- `Currency` and `OrderCurrency` both contain the currency code of the invoice; `total`, `TotalToPay` and `TotalToPay_OrderCurr` all contain the invoice total.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PaidInvoices` | bit | No | Selects the mode: 0 returns unpaid invoices, 1 returns paid invoices. |\n\n- All tables are read `WITH (NOLOCK)`; results can contain uncommitted data.\n- In mode `1` the filter uses a tolerance of 0.01, but `Paid` and `PaymentDate` use an exact comparison. Invoices with a tiny difference or invoices included only because of a `DoNotRefund` entry are therefore returned with `Paid` = 0 and `PaymentDate` = NULL.\n- Passing NULL for `PaidInvoices` returns no rows.\n- Invoices whose payment code has no entry in `Payments`, or whose customer, address or currency is missing, are silently excluded.\n- The result contains sensitive payment data (credit card number, name and expiry, bank account, BLZ).\n- Without paging the result can be large on databases with many invoices.\n- A code comment states that the currency handling (`Currency` = invoice currency) is provisional until multi-currency is fully supported.\n\nDocumentation: https://pixi-api-docs.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": "Returns all unpaid invoices, or with `PaidInvoices` = 1 all paid invoices, with payment, bank, address and currency details, sorted by invoice date.\n\nReads invoices from `Invoices` together with the customer, the payment method, the invoice (billing) address, its country and the invoice currency.\n\nThe parameter `PaidInvoices` selects one of two modes:\n\n- `0` (default): **unpaid invoices**. An invoice is returned if the paid sum (`PayedSum`, NULL counts as 0) is not exactly equal to the invoice total rounded to 2 decimals, **and** there is no entry in `CustomerAccount` for this customer and invoice that has `DoNotRefund = 1` and no bank line, DTAUS or manual booking reference.\n- `1`: **paid invoices**. An invoice is returned if the paid sum differs from the rounded total by less than 0.01, **or** such a `DoNotRefund` entry in `CustomerAccount` exists.\n\nOnly invoices for which a currency, a customer, a payment method (`Payments.Code` = invoice payment code) and an invoice address exist are returned (inner joins). The country is optional.\n\nThe result is sorted by invoice date ascending. There is no paging; all matching invoices are returned.\n\nColumn logic:\n- `Paid` is 1 only if the paid sum equals the rounded total exactly; otherwise 0.\n- `PaymentDate` is the invoice pay day if `Paid` = 1, otherwise NULL.\n- `PaymentText` is the text of the payment method, falling back to the payment code.\n- `Currency` and `OrderCurrency` both contain the currency code of the invoice; `total`, `TotalToPay` and `TotalToPay_OrderCurr` all contain the invoice total.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PaidInvoices` | bit | No | Selects the mode: 0 returns unpaid invoices, 1 returns paid invoices. |\n\n- All tables are read `WITH (NOLOCK)`; results can contain uncommitted data.\n- In mode `1` the filter uses a tolerance of 0.01, but `Paid` and `PaymentDate` use an exact comparison. Invoices with a tiny difference or invoices included only because of a `DoNotRefund` entry are therefore returned with `Paid` = 0 and `PaymentDate` = NULL.\n- Passing NULL for `PaidInvoices` returns no rows.\n- Invoices whose payment code has no entry in `Payments`, or whose customer, address or currency is missing, are silently excluded.\n- The result contains sensitive payment data (credit card number, name and expiry, bank account, BLZ).\n- Without paging the result can be large on databases with many invoices.\n- A code comment states that the currency handling (`Currency` = invoice currency) is provisional until multi-currency is fully supported.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoices that are fully paid through customer account matches with a payment posted in the given date range.\n\nFinds invoices that have been settled in the customer account (`CustomerAccount`) and returns one row per invoice entry.\n\nSteps:\n\n1. Selects all customer account entries with `EventDate` between `@From` and `@To` (inclusive, `BETWEEN`) and `Amount > 0`. These are typically the payment entries.\n2. Uses `CustomerAccountMatch` to find all customer account entries that are matched against those entries, in both directions (`CARef1` ↔ `CARef2`).\n3. Keeps only matched entries that reference an invoice (`InvoiceRef IS NOT NULL`).\n4. Keeps only entries that are fully settled: the sum of `AbsoluteMatchAmount` over all matches of the entry plus the entry's own `Amount` must be exactly `0`.\n\nFor each remaining entry the call returns:\n\n- the invoice key and invoice number from `Invoices`,\n- `DatePaid`: the latest `EventDate` of all customer account entries matched against the invoice entry (not limited to the date range),\n- `ShopID`: the shop of the customer (`Customers.CustomerOf`),\n- `OrderNRExternal`: the highest external order number of the order lines linked to the invoice through `Invlines`,\n- `PaymentType`: the payment method of the invoice.\n\nNo sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `From` | datetime | Yes | Start of the period (inclusive) for the posting date (`EventDate`) of the payment entries. |\n| `To` | datetime | Yes | End of the period (inclusive) for the posting date (`EventDate`) of the payment entries. |\n\n- All tables are read `WITH (NOLOCK)`; results can contain uncommitted data.\n- `BETWEEN` includes both limits. If `@To` is passed as a date without time (midnight), payments later on that day are not included.\n- The full-settlement check is an exact comparison with `0`; rounding differences in the matches exclude an invoice.\n- If an invoice has several customer account entries that each qualify, the invoice can appear more than once.\n- `DatePaid` is the latest matched entry date overall and can lie outside `@From`/`@To`.\n- In the settlement check the columns `Amount` and `CustomerAccountKey` are not qualified; the code relies on them resolving to the outer `CustomerAccount` entry.\n- The header comment of the procedure (\"Checks pixi* user credentials\") does not match its function and is apparently a copy leftover.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoices that are fully paid through customer account matches with a payment posted in the given date range.\n\nFinds invoices that have been settled in the customer account (`CustomerAccount`) and returns one row per invoice entry.\n\nSteps:\n\n1. Selects all customer account entries with `EventDate` between `@From` and `@To` (inclusive, `BETWEEN`) and `Amount > 0`. These are typically the payment entries.\n2. Uses `CustomerAccountMatch` to find all customer account entries that are matched against those entries, in both directions (`CARef1` ↔ `CARef2`).\n3. Keeps only matched entries that reference an invoice (`InvoiceRef IS NOT NULL`).\n4. Keeps only entries that are fully settled: the sum of `AbsoluteMatchAmount` over all matches of the entry plus the entry's own `Amount` must be exactly `0`.\n\nFor each remaining entry the call returns:\n\n- the invoice key and invoice number from `Invoices`,\n- `DatePaid`: the latest `EventDate` of all customer account entries matched against the invoice entry (not limited to the date range),\n- `ShopID`: the shop of the customer (`Customers.CustomerOf`),\n- `OrderNRExternal`: the highest external order number of the order lines linked to the invoice through `Invlines`,\n- `PaymentType`: the payment method of the invoice.\n\nNo sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `From` | datetime | Yes | Start of the period (inclusive) for the posting date (`EventDate`) of the payment entries. |\n| `To` | datetime | Yes | End of the period (inclusive) for the posting date (`EventDate`) of the payment entries. |\n\n- All tables are read `WITH (NOLOCK)`; results can contain uncommitted data.\n- `BETWEEN` includes both limits. If `@To` is passed as a date without time (midnight), payments later on that day are not included.\n- The full-settlement check is an exact comparison with `0`; rounding differences in the matches exclude an invoice.\n- If an invoice has several customer account entries that each qualify, the invoice can appear more than once.\n- `DatePaid` is the latest matched entry date overall and can lie outside `@From`/`@To`.\n- In the settlement check the columns `Amount` and `CustomerAccountKey` are not qualified; the code relies on them resolving to the outer `CustomerAccount` entry.\n- The header comment of the procedure (\"Checks pixi* user credentials\") does not match its function and is apparently a copy leftover.\n\nDocumentation: https://pixi-api-docs.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": "Returns the lines of a POS (point of sale) invoice, with item number, EAN, name, quantity, prices and discount, for a given document number.\n\nReturns all lines of the POS document whose document number (`POSheader2.PHdocNr`) equals `InvoiceNr`.\n\n1. The call first runs the common API envelope `Pixi_ApiEnvelope`. It checks the call frequency limit for this function and records the time of the call.\n2. If the envelope returns result code `200`, the procedure selects the POS lines (`POSitem2`) of the matching POS header (`POSheader2`). It joins each line to its item (`items`) with an inner join.\n3. Each row contains the internal item number, EAN, item name, quantity, the document date and number, and the price fields of the line. A missing discount is returned as `0.0`.\n\nThe filter is an exact match on the document number. The code sets no sort order, so the order of the lines is not guaranteed. If no POS document matches, an empty result set is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Yes | Document number of the POS invoice (`POSheader2.PHdocNr`). Exact match. |\n| `ResultCode` | char(3) | No | Result code of the API envelope: `200` on success, `502` if the call frequency limit was exceeded. |\n| `ResultText` | varchar(1024) | No | Result text of the API envelope, e.g. `OK` or the throttling message. |\n\n- All reads use `NOLOCK`. Uncommitted data can be returned.\n- Lines whose item no longer exists in `items` are not returned, because the item is joined with an inner join.\n- `ItemPrice_Netto` is calculated as `PIendPrice - PIvatInPrice`, i.e. the line total minus the VAT included in it.\n- `ItemPrice_Brutto` is taken directly from `PIprice`. The code does not show whether this is a unit price or a line price.\n- `Pixi_ApiEnvelope` writes the call time to `API_STATISTICS`. If a minimum interval is configured in `API_CONTROL` and the last call was too recent, the envelope returns a `ResultCode`/`ResultText` row with code `502` instead of the invoice lines.\n- The output parameters `ResultCode` and `ResultText` carry the envelope result (`200`/`OK` on success).\n\nDocumentation: https://pixi-api-docs.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": "Returns the lines of a POS (point of sale) invoice, with item number, EAN, name, quantity, prices and discount, for a given document number.\n\nReturns all lines of the POS document whose document number (`POSheader2.PHdocNr`) equals `InvoiceNr`.\n\n1. The call first runs the common API envelope `Pixi_ApiEnvelope`. It checks the call frequency limit for this function and records the time of the call.\n2. If the envelope returns result code `200`, the procedure selects the POS lines (`POSitem2`) of the matching POS header (`POSheader2`). It joins each line to its item (`items`) with an inner join.\n3. Each row contains the internal item number, EAN, item name, quantity, the document date and number, and the price fields of the line. A missing discount is returned as `0.0`.\n\nThe filter is an exact match on the document number. The code sets no sort order, so the order of the lines is not guaranteed. If no POS document matches, an empty result set is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Yes | Document number of the POS invoice (`POSheader2.PHdocNr`). Exact match. |\n| `ResultCode` | char(3) | No | Result code of the API envelope: `200` on success, `502` if the call frequency limit was exceeded. |\n| `ResultText` | varchar(1024) | No | Result text of the API envelope, e.g. `OK` or the throttling message. |\n\n- All reads use `NOLOCK`. Uncommitted data can be returned.\n- Lines whose item no longer exists in `items` are not returned, because the item is joined with an inner join.\n- `ItemPrice_Netto` is calculated as `PIendPrice - PIvatInPrice`, i.e. the line total minus the VAT included in it.\n- `ItemPrice_Brutto` is taken directly from `PIprice`. The code does not show whether this is a unit price or a line price.\n- `Pixi_ApiEnvelope` writes the call time to `API_STATISTICS`. If a minimum interval is configured in `API_CONTROL` and the last call was too recent, the envelope returns a `ResultCode`/`ResultText` row with code `502` instead of the invoice lines.\n- The output parameters `ResultCode` and `ResultText` carry the envelope result (`200`/`OK` on success).\n\nDocumentation: https://pixi-api-docs.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": "Returns unpaid invoices of a payment type that are due for the given reminder (dunning) level, including address and shop data.\n\nLists open invoices that are candidates for the next payment reminder. The call delegates to the internal procedure `pixi_GetReminders`.\n\nAn invoice is returned when all of the following apply:\n\n- `Invoices.Payed` is NULL (not paid).\n- `Invoices.Payment` equals `@PaymentType`.\n- `Invoices.total` is greater than 0.\n- More than the threshold number of days have passed between `Invoices.ScanOutDate` and the current server date.\n- The invoice's current reminder level matches the level that precedes `@ReminderLevel`:\n - level `1`: `ReminderLevel` is NULL or 0,\n - level `2`: `ReminderLevel` = 1,\n - level `3`: `ReminderLevel` = 2,\n - level greater than 3: `ReminderLevel` = `@ReminderLevel` - 1.\n- The address referenced by `Invoices.AddrRef` belongs to shop `@ShopID`, or `@ShopID` is NULL (all shops).\n\nThe day threshold is determined as follows:\n\n- Levels 1 to 3: `@ReminderDays` if given, otherwise the setting `ReminderLevel1_Days` (if not 0), otherwise 15 (level 1), 30 (level 2) or 45 (level 3).\n- Levels above 3: `@ReminderDays` if given, otherwise 45. The setting is not used.\n\nEach row contains invoice data, the invoice address and the shop name and customer e-mail of the shop. No sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ReminderLevel` | int | Yes | Reminder level to prepare. Selects invoices whose current reminder level is one below this value. |\n| `PaymentType` | char(1) | Yes | Payment type code; only invoices with `Invoices.Payment` equal to this value are returned. |\n| `ShopID` | char(3) | Yes | Shop ID of the invoice address. NULL returns invoices of all shops. |\n| `ReminderDays` | int | No | Minimum number of days since `ScanOutDate` (strictly greater). If NULL, the setting or the level default is used. |\n\n- Read-only: the call does **not** raise the reminder level of the returned invoices. The caller has to update the reminder level by other means, otherwise the same invoices are returned again.\n- Pitfall: levels 2 and 3 also read the setting `ReminderLevel1_Days` (not a level-specific setting). If that setting is set, it replaces the defaults 30 and 45 for these levels, so all three levels use the same threshold unless `@ReminderDays` is passed.\n- The setting is read via the function `fpixi_GetSetting`, whose definition is not attached.\n- If `@ReminderLevel` is NULL or less than 1, no result set is returned at all.\n- The age is measured from `ScanOutDate` (scan-out/shipping date), not from `InvDate`. Invoices without `ScanOutDate` are never returned.\n- Invoices without a matching address or shop are excluded because of inner joins.\n- `@ShopID` has no default and must be sent; pass NULL to include all shops.\n- All tables are read with `NOLOCK`, so uncommitted data may appear.\n\nDocumentation: https://pixi-api-docs.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": "Returns unpaid invoices of a payment type that are due for the given reminder (dunning) level, including address and shop data.\n\nLists open invoices that are candidates for the next payment reminder. The call delegates to the internal procedure `pixi_GetReminders`.\n\nAn invoice is returned when all of the following apply:\n\n- `Invoices.Payed` is NULL (not paid).\n- `Invoices.Payment` equals `@PaymentType`.\n- `Invoices.total` is greater than 0.\n- More than the threshold number of days have passed between `Invoices.ScanOutDate` and the current server date.\n- The invoice's current reminder level matches the level that precedes `@ReminderLevel`:\n - level `1`: `ReminderLevel` is NULL or 0,\n - level `2`: `ReminderLevel` = 1,\n - level `3`: `ReminderLevel` = 2,\n - level greater than 3: `ReminderLevel` = `@ReminderLevel` - 1.\n- The address referenced by `Invoices.AddrRef` belongs to shop `@ShopID`, or `@ShopID` is NULL (all shops).\n\nThe day threshold is determined as follows:\n\n- Levels 1 to 3: `@ReminderDays` if given, otherwise the setting `ReminderLevel1_Days` (if not 0), otherwise 15 (level 1), 30 (level 2) or 45 (level 3).\n- Levels above 3: `@ReminderDays` if given, otherwise 45. The setting is not used.\n\nEach row contains invoice data, the invoice address and the shop name and customer e-mail of the shop. No sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ReminderLevel` | int | Yes | Reminder level to prepare. Selects invoices whose current reminder level is one below this value. |\n| `PaymentType` | char(1) | Yes | Payment type code; only invoices with `Invoices.Payment` equal to this value are returned. |\n| `ShopID` | char(3) | Yes | Shop ID of the invoice address. NULL returns invoices of all shops. |\n| `ReminderDays` | int | No | Minimum number of days since `ScanOutDate` (strictly greater). If NULL, the setting or the level default is used. |\n\n- Read-only: the call does **not** raise the reminder level of the returned invoices. The caller has to update the reminder level by other means, otherwise the same invoices are returned again.\n- Pitfall: levels 2 and 3 also read the setting `ReminderLevel1_Days` (not a level-specific setting). If that setting is set, it replaces the defaults 30 and 45 for these levels, so all three levels use the same threshold unless `@ReminderDays` is passed.\n- The setting is read via the function `fpixi_GetSetting`, whose definition is not attached.\n- If `@ReminderLevel` is NULL or less than 1, no result set is returned at all.\n- The age is measured from `ScanOutDate` (scan-out/shipping date), not from `InvDate`. Invoices without `ScanOutDate` are never returned.\n- Invoices without a matching address or shop are excluded because of inner joins.\n- `@ShopID` has no default and must be sent; pass NULL to include all shops.\n- All tables are read with `NOLOCK`, so uncommitted data may appear.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoices with their reminder history, reminder costs, open amount, customer account status and billing address, optionally filtered by reminder level, shop, payment type and date.\n\nReturns one row per invoice that matches the filters, enriched with reminder (dunning) data, customer account (CA) figures and the invoice address.\n\n**Parameter normalisation**\n- `ReminderLevel` = 0, `ShopID` = '' and `PaymentType` = '' are treated as NULL (no filter).\n- `ReminderDays` = 0 is treated as NULL. If `ReminderDays` > 0, `InvoiceFrom` and `InvoiceTo` are **overwritten** with the period from now minus `ReminderDays` days until now.\n- If `InvoiceFrom` is set and `InvoiceTo` is empty, `InvoiceTo` is set to the current date and time.\n\n**Filters** (all combined with AND)\n- `ReminderLevel`: only invoices that have at least one reminder line with exactly this level. If NULL, **all** invoices are candidates, including invoices without any reminder.\n- `InvoiceFrom`/`InvoiceTo`: invoice date between both values (inclusive). Only applied if `InvoiceFrom` is set.\n- `PaymentType`: invoice payment type equals the value.\n- `ShopID`: the customer belongs to this shop (`CustomerOf`).\n- `OnlyUnmatched` = 1: only invoices whose paid sum differs from the total.\n- `OnlyWhenCAUnbalanced`: see notes – the effective value is taken from `OnlyUnmatched`; when active, only invoices of customers whose customer account balance is not 0.\n\nOnly invoices whose customer exists, belongs to an existing shop and whose invoice address exists are returned.\n\n**Returned data**\n- Invoice data: key, number, customer and address key, shop, highest order number and the external order number of that order, date and total.\n- Reminder data: highest reminder level, earliest reminder date per level 1–6 (`ReminderDate1` … `ReminderDate6`), costs of the latest reminder (highest reminder key) and the sum of costs of all reminders of the invoice.\n- `OpenInvoiceAmount` = total minus paid sum.\n- Customer account: `CAMatched` (1 if all positive or all negative account entries are fully matched, otherwise 0) and `CAFinancialBalance` (sum of the customer account; with multiple currencies converted with today's exchange rate if multi-currency is enabled).\n- Customer and address data (external customer number, company, name, street, ZIP, city, country, phone, fax, e-mail).\n\nRows are sorted by customer key; there is no further sort order within a customer and no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ReminderLevel` | int | No | Only invoices with at least one reminder line of this reminder level. NULL or 0: no filter (also invoices without reminders). |\n| `PaymentType` | char(1) | No | Payment type code of the invoice. NULL or empty: no filter. |\n| `ShopID` | char(3) | No | Shop the customer belongs to (`CustomerOf`). NULL or empty: all shops. |\n| `ReminderDays` | int | No | If > 0, restricts the invoice date to the last N days up to now and overrides `InvoiceFrom`/`InvoiceTo`. 0: not used. |\n| `InvoiceFrom` | datetime | No | Start of the invoice date range (inclusive). NULL: no date filter. |\n| `InvoiceTo` | datetime | No | End of the invoice date range (inclusive). Defaults to now if `InvoiceFrom` is set. Ignored without `InvoiceFrom`. |\n| `OnlyUnmatched` | bit | No | 1: only invoices whose paid sum differs from the total. Also activates the customer account balance filter (see notes). |\n| `OnlyWhenCAUnbalanced` | bit | No | Intended to return only customers with a customer account balance <> 0. The passed value is ignored; the code uses the value of `OnlyUnmatched` instead. |\n\n- **Pitfall:** the code sets `OnlyWhenCAUnbalanced` to the value of `OnlyUnmatched`. The value passed for `OnlyWhenCAUnbalanced` is therefore ignored; sending `OnlyUnmatched` = 1 activates both the paid-sum filter and the customer-account-balance filter.\n- Without `ReminderLevel` the call is not limited to reminded or open invoices. Without further filters it returns every invoice in the database, which can be very slow. Use `OnlyUnmatched`, a date range or `ReminderLevel` to narrow the result.\n- `ReminderDays` > 0 takes precedence over explicitly passed `InvoiceFrom`/`InvoiceTo`. `InvoiceTo` alone (without `InvoiceFrom`) has no effect.\n- `CAMatched` is stored in a temporary `money` column, so it is returned as a decimal value (1.00 / 0.00) instead of a boolean.\n- The customer account figures are calculated for all customers via `fPixi_CA_IsMatched` and `fPixi_CA_FinancialBalance`. The currency conversion depends on the setting `MultiCurrencyEnabled` and today's exchange rate; if no rate exists for today, the converted amount becomes NULL.\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- Only reminder levels 1 to 6 have their own date column.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoices with their reminder history, reminder costs, open amount, customer account status and billing address, optionally filtered by reminder level, shop, payment type and date.\n\nReturns one row per invoice that matches the filters, enriched with reminder (dunning) data, customer account (CA) figures and the invoice address.\n\n**Parameter normalisation**\n- `ReminderLevel` = 0, `ShopID` = '' and `PaymentType` = '' are treated as NULL (no filter).\n- `ReminderDays` = 0 is treated as NULL. If `ReminderDays` > 0, `InvoiceFrom` and `InvoiceTo` are **overwritten** with the period from now minus `ReminderDays` days until now.\n- If `InvoiceFrom` is set and `InvoiceTo` is empty, `InvoiceTo` is set to the current date and time.\n\n**Filters** (all combined with AND)\n- `ReminderLevel`: only invoices that have at least one reminder line with exactly this level. If NULL, **all** invoices are candidates, including invoices without any reminder.\n- `InvoiceFrom`/`InvoiceTo`: invoice date between both values (inclusive). Only applied if `InvoiceFrom` is set.\n- `PaymentType`: invoice payment type equals the value.\n- `ShopID`: the customer belongs to this shop (`CustomerOf`).\n- `OnlyUnmatched` = 1: only invoices whose paid sum differs from the total.\n- `OnlyWhenCAUnbalanced`: see notes – the effective value is taken from `OnlyUnmatched`; when active, only invoices of customers whose customer account balance is not 0.\n\nOnly invoices whose customer exists, belongs to an existing shop and whose invoice address exists are returned.\n\n**Returned data**\n- Invoice data: key, number, customer and address key, shop, highest order number and the external order number of that order, date and total.\n- Reminder data: highest reminder level, earliest reminder date per level 1–6 (`ReminderDate1` … `ReminderDate6`), costs of the latest reminder (highest reminder key) and the sum of costs of all reminders of the invoice.\n- `OpenInvoiceAmount` = total minus paid sum.\n- Customer account: `CAMatched` (1 if all positive or all negative account entries are fully matched, otherwise 0) and `CAFinancialBalance` (sum of the customer account; with multiple currencies converted with today's exchange rate if multi-currency is enabled).\n- Customer and address data (external customer number, company, name, street, ZIP, city, country, phone, fax, e-mail).\n\nRows are sorted by customer key; there is no further sort order within a customer and no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ReminderLevel` | int | No | Only invoices with at least one reminder line of this reminder level. NULL or 0: no filter (also invoices without reminders). |\n| `PaymentType` | char(1) | No | Payment type code of the invoice. NULL or empty: no filter. |\n| `ShopID` | char(3) | No | Shop the customer belongs to (`CustomerOf`). NULL or empty: all shops. |\n| `ReminderDays` | int | No | If > 0, restricts the invoice date to the last N days up to now and overrides `InvoiceFrom`/`InvoiceTo`. 0: not used. |\n| `InvoiceFrom` | datetime | No | Start of the invoice date range (inclusive). NULL: no date filter. |\n| `InvoiceTo` | datetime | No | End of the invoice date range (inclusive). Defaults to now if `InvoiceFrom` is set. Ignored without `InvoiceFrom`. |\n| `OnlyUnmatched` | bit | No | 1: only invoices whose paid sum differs from the total. Also activates the customer account balance filter (see notes). |\n| `OnlyWhenCAUnbalanced` | bit | No | Intended to return only customers with a customer account balance <> 0. The passed value is ignored; the code uses the value of `OnlyUnmatched` instead. |\n\n- **Pitfall:** the code sets `OnlyWhenCAUnbalanced` to the value of `OnlyUnmatched`. The value passed for `OnlyWhenCAUnbalanced` is therefore ignored; sending `OnlyUnmatched` = 1 activates both the paid-sum filter and the customer-account-balance filter.\n- Without `ReminderLevel` the call is not limited to reminded or open invoices. Without further filters it returns every invoice in the database, which can be very slow. Use `OnlyUnmatched`, a date range or `ReminderLevel` to narrow the result.\n- `ReminderDays` > 0 takes precedence over explicitly passed `InvoiceFrom`/`InvoiceTo`. `InvoiceTo` alone (without `InvoiceFrom`) has no effect.\n- `CAMatched` is stored in a temporary `money` column, so it is returned as a decimal value (1.00 / 0.00) instead of a boolean.\n- The customer account figures are calculated for all customers via `fPixi_CA_IsMatched` and `fPixi_CA_FinancialBalance`. The currency conversion depends on the setting `MultiCurrencyEnabled` and today's exchange rate; if no rate exists for today, the converted amount becomes NULL.\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- Only reminder levels 1 to 6 have their own date column.\n\nDocumentation: https://pixi-api-docs.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": "Returns the invoices that were created or changed (including changes to their invoice lines) after a given point in time, with optional paging and payment filter.\n\nUse this call for delta synchronisation of invoices.\n\n1. If `Since` is not passed, the start of the current day (00:00) is used. An empty `PaymentType` is treated like `NULL`.\n2. Candidates are collected from three sources, each restricted to an `InvoiceKey` greater than `OffSet`:\n - invoices whose `CreateDate` is later than `Since`,\n - invoices whose `UpdateDate` is later than `Since`,\n - invoice lines (`Invlines`) whose `UpdateDate` is later than `Since`; the invoice they belong to is the candidate.\n3. The candidates are grouped per invoice. `UpdateDate` in the result is the latest of the matching timestamps.\n4. If `PaymentType` is set, only invoices with this payment code are kept.\n5. The list is sorted by `InvoiceKey` ascending and limited to `Rows` invoices (`0` = no limit).\n6. For every remaining invoice the call returns key, invoice number, change date, shop (`CustomerOf` of the customer) and payment code with payment text, sorted by `InvoiceKey`.\n\n**Paging:** pass the highest `InvoiceKey` of the previous page as `OffSet` with the same `Since` to fetch the next page.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | No | Only invoices created or changed (including their lines) after this point in time are returned. `NULL` means start of the current day. |\n| `Rows` | int | No | Maximum number of invoices per call (page size). `0` returns all matching invoices. |\n| `PaymentType` | varchar(1) | No | Optional payment code (`Invoices.Payment`). Only invoices with this payment type are returned. `NULL` or empty means all payment types. |\n| `OffSet` | int | No | Paging offset: only invoices with an `InvoiceKey` greater than this value are considered. Pass the highest `InvoiceKey` of the previous page. |\n\n- All tables are read `WITH (NOLOCK)`; uncommitted changes may be visible.\n- The comparison with `Since` is strict (`>`); records changed exactly at `Since` are not returned.\n- `UpdateDate` only reflects timestamps later than `Since`, so it is the latest change within the requested window.\n- The `Rows` limit (via `SET ROWCOUNT`) is applied before the joins to `Customers` and `Payments`. Invoices without a matching customer or payment code are dropped afterwards, so a page can contain fewer than `Rows` rows even if more data exists. Always continue paging with the highest `InvoiceKey` returned until no rows come back.\n- Only the final select is wrapped in error handling; on an unexpected error a status row is returned and the procedure returns `3`, otherwise `0`.\n- Temporary tables are cleaned up with `util.TempTableDrop` (definition not attached).\n\nDocumentation: https://pixi-api-docs.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": "Returns the invoices that were created or changed (including changes to their invoice lines) after a given point in time, with optional paging and payment filter.\n\nUse this call for delta synchronisation of invoices.\n\n1. If `Since` is not passed, the start of the current day (00:00) is used. An empty `PaymentType` is treated like `NULL`.\n2. Candidates are collected from three sources, each restricted to an `InvoiceKey` greater than `OffSet`:\n - invoices whose `CreateDate` is later than `Since`,\n - invoices whose `UpdateDate` is later than `Since`,\n - invoice lines (`Invlines`) whose `UpdateDate` is later than `Since`; the invoice they belong to is the candidate.\n3. The candidates are grouped per invoice. `UpdateDate` in the result is the latest of the matching timestamps.\n4. If `PaymentType` is set, only invoices with this payment code are kept.\n5. The list is sorted by `InvoiceKey` ascending and limited to `Rows` invoices (`0` = no limit).\n6. For every remaining invoice the call returns key, invoice number, change date, shop (`CustomerOf` of the customer) and payment code with payment text, sorted by `InvoiceKey`.\n\n**Paging:** pass the highest `InvoiceKey` of the previous page as `OffSet` with the same `Since` to fetch the next page.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | No | Only invoices created or changed (including their lines) after this point in time are returned. `NULL` means start of the current day. |\n| `Rows` | int | No | Maximum number of invoices per call (page size). `0` returns all matching invoices. |\n| `PaymentType` | varchar(1) | No | Optional payment code (`Invoices.Payment`). Only invoices with this payment type are returned. `NULL` or empty means all payment types. |\n| `OffSet` | int | No | Paging offset: only invoices with an `InvoiceKey` greater than this value are considered. Pass the highest `InvoiceKey` of the previous page. |\n\n- All tables are read `WITH (NOLOCK)`; uncommitted changes may be visible.\n- The comparison with `Since` is strict (`>`); records changed exactly at `Since` are not returned.\n- `UpdateDate` only reflects timestamps later than `Since`, so it is the latest change within the requested window.\n- The `Rows` limit (via `SET ROWCOUNT`) is applied before the joins to `Customers` and `Payments`. Invoices without a matching customer or payment code are dropped afterwards, so a page can contain fewer than `Rows` rows even if more data exists. Always continue paging with the highest `InvoiceKey` returned until no rows come back.\n- Only the final select is wrapped in error handling; on an unexpected error a status row is returned and the procedure returns `3`, otherwise `0`.\n- Temporary tables are cleaned up with `util.TempTableDrop` (definition not attached).\n\nDocumentation: https://pixi-api-docs.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": "Sets or replaces the note (`Note`) of a single invoice identified by invoice number or invoice key.\n\nUpdates the `Note` field of exactly one invoice in the `Invoices` table.\n\n1. The invoice is looked up with the condition `InvoiceNr = @InvoiceNr OR InvoiceKey = @InvoiceKey`.\n2. If this condition matches no invoice, or more than one invoice, the call returns a status row with `ErrorNr` = `404` and changes nothing. This happens if:\n - neither `InvoiceNr` nor `InvoiceKey` is passed,\n - the given number or key does not exist,\n - `InvoiceNr` and `InvoiceKey` point to two different invoices.\n3. If exactly one invoice matches, its `Note` is overwritten with `@Note`, and a status row with `ErrorNr` = `200` and an empty `ErrorMessage` is returned.\n4. If the update fails, a status row with `ErrorNr` = `500` is returned.\n\nPassing both parameters is allowed if they refer to the same invoice.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | No | Invoice number of the invoice to update. Either this or `InvoiceKey` must identify exactly one invoice. |\n| `InvoiceKey` | int | No | Internal key of the invoice to update. Alternative to `InvoiceNr`; if both are given, they must refer to the same invoice. |\n| `Note` | varchar(255) | No | New note text for the invoice. Replaces the existing note; `NULL` (or omitting the parameter) clears it. |\n\n- The existing note is **replaced**, not appended. If `Note` is omitted, it defaults to `NULL` and the note of the invoice is cleared.\n- The existence check reads `Invoices` with `NOLOCK`; check and update are not wrapped in a transaction.\n- The `500` status row does not contain the original SQL error text.\n- `ErrorNr` is returned as a string (`'200'`, `'404'`, `'500'`), not as a number.\n- `@Note` is declared as `varchar(255)`; longer texts may be truncated.\n\nDocumentation: https://pixi-api-docs.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": "Sets or replaces the note (`Note`) of a single invoice identified by invoice number or invoice key.\n\nUpdates the `Note` field of exactly one invoice in the `Invoices` table.\n\n1. The invoice is looked up with the condition `InvoiceNr = @InvoiceNr OR InvoiceKey = @InvoiceKey`.\n2. If this condition matches no invoice, or more than one invoice, the call returns a status row with `ErrorNr` = `404` and changes nothing. This happens if:\n - neither `InvoiceNr` nor `InvoiceKey` is passed,\n - the given number or key does not exist,\n - `InvoiceNr` and `InvoiceKey` point to two different invoices.\n3. If exactly one invoice matches, its `Note` is overwritten with `@Note`, and a status row with `ErrorNr` = `200` and an empty `ErrorMessage` is returned.\n4. If the update fails, a status row with `ErrorNr` = `500` is returned.\n\nPassing both parameters is allowed if they refer to the same invoice.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | No | Invoice number of the invoice to update. Either this or `InvoiceKey` must identify exactly one invoice. |\n| `InvoiceKey` | int | No | Internal key of the invoice to update. Alternative to `InvoiceNr`; if both are given, they must refer to the same invoice. |\n| `Note` | varchar(255) | No | New note text for the invoice. Replaces the existing note; `NULL` (or omitting the parameter) clears it. |\n\n- The existing note is **replaced**, not appended. If `Note` is omitted, it defaults to `NULL` and the note of the invoice is cleared.\n- The existence check reads `Invoices` with `NOLOCK`; check and update are not wrapped in a transaction.\n- The `500` status row does not contain the original SQL error text.\n- `ErrorNr` is returned as a string (`'200'`, `'404'`, `'500'`), not as a number.\n- `@Note` is declared as `varchar(255)`; longer texts may be truncated.\n\nDocumentation: https://pixi-api-docs.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": "Sets or adds shipment tracking IDs for an invoice and its packages, optionally replacing existing ones and resetting the client-notified flag.\n\nAssigns one or more tracking IDs to an invoice (`Invoices.ShipmentTrackingID`) and its packages (`pixi.InvoicePackage`).\n\n1. **Invoice lookup**: `InvoiceNR` is matched against `Invoices.InvoiceNr`. If it contains `-`, suffixes after the last `-` are stripped one at a time and every shortened variant is also tried (for example `RE1000-2-1` → `RE1000-2` → `RE1000`). Only invoice numbers that actually exist are used.\n2. **Separator**: if `Separator` is not `;` and not empty, every occurrence of it in `TrackingID` is replaced by `;`. Internally `;` is always used as the delimiter.\n3. If no invoice is found, the row `InvoiceNR is not existing` is returned and nothing is changed.\n4. If the invoice is found, the row `InvoiceNR found and Updated` is returned first. Then:\n - **`Overwrite` = 1**: `Invoices.ShipmentTrackingID` is cleared. All packages of the invoice that have no package lines are detached from `InvoicePolling` (`InvoicePackageId` set to NULL). Packages without package lines are deleted, except the package with the lowest Id.\n - The internal procedure `Pixi_SetTrackingId` is executed. It splits the tracking IDs, ignores IDs already stored on the invoice and distributes the new IDs to packages:\n - If no package has package lines from a packing station, a single existing package with an empty tracking ID receives the first new ID. All other new IDs, or all new IDs if no such package exists, are inserted as new packages. `ShipmentTrackingID` on the invoice is then rebuilt from all distinct package tracking IDs, sorted and separated by `;`.\n - If packages with package lines exist and there is exactly one package, that package receives the last new ID. If there are several packages, the packages are left unchanged. `ShipmentTrackingID` becomes the union of the existing and the new IDs.\n - `Invoices.Packages` is set to the number of packages, and `UpdateDate` and `UpdateEmp` (`TrackingID Import`) are updated. An `InvoiceChanged` event is published.\n - **`ResetClientNotifiedFlag` = 1**: for all order lines on the invoice, the most recent `OrderHistory` entry with status `AUS` gets `ClientNotified = 'N'`. The shipment is then reported to the client or shop again with the tracking ID.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNR` | varchar(20) | Yes | Invoice number. Suffixes separated by `-` are stripped step by step if the full number does not exist. |\n| `TrackingID` | varchar(8000) | Yes | One or more tracking IDs separated by `Separator`. Each ID is truncated to 512 characters. |\n| `Overwrite` | bit | No | If 1, the invoice tracking field is cleared and packages without package lines (except the first one) are deleted before the new IDs are set. |\n| `ResetClientNotifiedFlag` | bit | No | If 1, the latest `AUS` entry in the order history of each order line on the invoice is set to `ClientNotified = 'N'`, so that the shipment is exported again. |\n| `Separator` | varchar(1) | No | Delimiter used in `TrackingID`. It is converted to `;` internally; an empty value means `;`. |\n\n- The procedure runs in its own transaction, or in a savepoint if a transaction is already open.\n- **Errors are swallowed**: they are caught, the transaction is rolled back and the error is logged via `log.InsertError`. No error is raised to the caller. Because the message `InvoiceNR found and Updated` is selected *before* the changes are made, it can be returned even though all changes were rolled back.\n- Invoice number resolution: if several variants match (e.g. `RE1000-1` and `RE1000`), the result of the ordered variable assignment typically picks the shortest matching number. Pass the exact invoice number to avoid ambiguity.\n- `Overwrite` does not reset the tracking ID of the package that is kept (lowest Id). If that package already has a tracking ID, the new IDs are added as additional packages, and the old ID reappears in `ShipmentTrackingID`, which is rebuilt from all packages.\n- `Overwrite` detaches `InvoicePolling` rows also from the kept package if it has no package lines.\n- Packages with package lines are never deleted. If several such packages exist, package tracking IDs are not changed at all; only the invoice field is extended. The internal procedure itself warns that tracking IDs should preferably be set per package.\n- Tracking IDs are truncated to 512 characters each. Splitting is done by `dbo.fPixi_GetCommaSplit`, the user lookup by `inf.UserGetByName` and event publishing by `dbo.Pixi_MQ_EventPublish`. Their definitions are not attached.\n- Lookups use `NOLOCK`; updates use `ROWLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Sets or adds shipment tracking IDs for an invoice and its packages, optionally replacing existing ones and resetting the client-notified flag.\n\nAssigns one or more tracking IDs to an invoice (`Invoices.ShipmentTrackingID`) and its packages (`pixi.InvoicePackage`).\n\n1. **Invoice lookup**: `InvoiceNR` is matched against `Invoices.InvoiceNr`. If it contains `-`, suffixes after the last `-` are stripped one at a time and every shortened variant is also tried (for example `RE1000-2-1` → `RE1000-2` → `RE1000`). Only invoice numbers that actually exist are used.\n2. **Separator**: if `Separator` is not `;` and not empty, every occurrence of it in `TrackingID` is replaced by `;`. Internally `;` is always used as the delimiter.\n3. If no invoice is found, the row `InvoiceNR is not existing` is returned and nothing is changed.\n4. If the invoice is found, the row `InvoiceNR found and Updated` is returned first. Then:\n - **`Overwrite` = 1**: `Invoices.ShipmentTrackingID` is cleared. All packages of the invoice that have no package lines are detached from `InvoicePolling` (`InvoicePackageId` set to NULL). Packages without package lines are deleted, except the package with the lowest Id.\n - The internal procedure `Pixi_SetTrackingId` is executed. It splits the tracking IDs, ignores IDs already stored on the invoice and distributes the new IDs to packages:\n - If no package has package lines from a packing station, a single existing package with an empty tracking ID receives the first new ID. All other new IDs, or all new IDs if no such package exists, are inserted as new packages. `ShipmentTrackingID` on the invoice is then rebuilt from all distinct package tracking IDs, sorted and separated by `;`.\n - If packages with package lines exist and there is exactly one package, that package receives the last new ID. If there are several packages, the packages are left unchanged. `ShipmentTrackingID` becomes the union of the existing and the new IDs.\n - `Invoices.Packages` is set to the number of packages, and `UpdateDate` and `UpdateEmp` (`TrackingID Import`) are updated. An `InvoiceChanged` event is published.\n - **`ResetClientNotifiedFlag` = 1**: for all order lines on the invoice, the most recent `OrderHistory` entry with status `AUS` gets `ClientNotified = 'N'`. The shipment is then reported to the client or shop again with the tracking ID.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNR` | varchar(20) | Yes | Invoice number. Suffixes separated by `-` are stripped step by step if the full number does not exist. |\n| `TrackingID` | varchar(8000) | Yes | One or more tracking IDs separated by `Separator`. Each ID is truncated to 512 characters. |\n| `Overwrite` | bit | No | If 1, the invoice tracking field is cleared and packages without package lines (except the first one) are deleted before the new IDs are set. |\n| `ResetClientNotifiedFlag` | bit | No | If 1, the latest `AUS` entry in the order history of each order line on the invoice is set to `ClientNotified = 'N'`, so that the shipment is exported again. |\n| `Separator` | varchar(1) | No | Delimiter used in `TrackingID`. It is converted to `;` internally; an empty value means `;`. |\n\n- The procedure runs in its own transaction, or in a savepoint if a transaction is already open.\n- **Errors are swallowed**: they are caught, the transaction is rolled back and the error is logged via `log.InsertError`. No error is raised to the caller. Because the message `InvoiceNR found and Updated` is selected *before* the changes are made, it can be returned even though all changes were rolled back.\n- Invoice number resolution: if several variants match (e.g. `RE1000-1` and `RE1000`), the result of the ordered variable assignment typically picks the shortest matching number. Pass the exact invoice number to avoid ambiguity.\n- `Overwrite` does not reset the tracking ID of the package that is kept (lowest Id). If that package already has a tracking ID, the new IDs are added as additional packages, and the old ID reappears in `ShipmentTrackingID`, which is rebuilt from all packages.\n- `Overwrite` detaches `InvoicePolling` rows also from the kept package if it has no package lines.\n- Packages with package lines are never deleted. If several such packages exist, package tracking IDs are not changed at all; only the invoice field is extended. The internal procedure itself warns that tracking IDs should preferably be set per package.\n- Tracking IDs are truncated to 512 characters each. Splitting is done by `dbo.fPixi_GetCommaSplit`, the user lookup by `inf.UserGetByName` and event publishing by `dbo.Pixi_MQ_EventPublish`. Their definitions are not attached.\n- Lookups use `NOLOCK`; updates use `ROWLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Creates a manual credit note (negative invoice) for an existing invoice with a single amount and VAT rate.\n\nCreates a credit note that references an existing invoice. The credit has no item lines; it consists of one amount and one VAT rate.\n\n1. **Validation**\n - `Amount` must be greater than 0.\n - `VATRate` must be `H`, `L` or `N`.\n - At least one of `InvoiceKey` or `InvoiceNr` must be given. If only `InvoiceNr` is given, the key is looked up in `Invoices`. The invoice must exist. If both are given, they must belong to the same invoice.\n2. **Invoice data**: order type, invoice location, customer, billing and shipping address and currency are taken from the original invoice. The country comes from the billing address.\n3. **Position text**: if `PositionText` is empty, a default text is built. With `LanguageId` = 1 it is `Manual Credit: Created From: {InvoiceNr}`. Otherwise it is `Manuell Gutschrift: Erstellt von: {InvoiceNr}`. `LanguageId` defaults to 2.\n4. **VAT calculation**: the VAT rates for the country and order type are read with `Pixi_CA_GetVATList`. The row with the requested `VATRate` is used.\n - For order type `B2B`, `Amount` is treated as **net**: net = −`Amount`, gross = −`Amount` × (1 + VAT), rounded to 2 decimals.\n - For all other order types, `Amount` is treated as **gross**: gross = −`Amount`, net = −`Amount` / (1 + VAT), rounded to 2 decimals.\n5. **Limit check**: the absolute gross amount of the new credit is added to the absolute sum of the totals of all invoices that already reference the original invoice (`RefToInvoiceKey`). If the result is greater than the original invoice total, the call is rejected.\n6. **Creation**: `Pixi_CA_InsertManualInvoice` creates the credit. It does the following:\n - assigns the next invoice number;\n - inserts the record into `Invoices` with `RefToInvoiceKey`/`RefToInvoiceNr` pointing to the original invoice;\n - adds SEPA data and an `InvoicePackage` record;\n - books the credit to the customer account;\n - publishes the MQ event `InvoiceCreated`.\n\nThe call returns one status row with `Status` and `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceKey` | int | No | Key of the original invoice. Either this or `InvoiceNr` is required; if both are given they must match. |\n| `InvoiceNr` | varchar(20) | No | Number of the original invoice. Used to look up the key if `InvoiceKey` is not given. |\n| `PositionText` | varchar(120) | No | Text of the credit note, stored as the invoice text without lines. If empty, a default text with the original invoice number is used. |\n| `LanguageId` | tinyint | No | Language for the default position text. `NULL` is treated as 2. It is also passed to the inner procedure. |\n| `VATRate` | varchar(1) | No | VAT rate class of the credit amount. |\n| `Amount` | money | No | Positive credit amount. It is net for order type `B2B` and gross for all other order types. It is stored negative. |\n| `UserName` | varchar(50) | No | User name stored as creator of the credit note. |\n\n- The call runs in its own transaction. If a transaction is already open, it uses a savepoint instead. Validation errors roll back and return return code 2. Unexpected errors are logged via `log.InsertError` and return return code 3. Success returns 0. Return codes are not part of the SOAP rows.\n- **Always pass `Amount` and `VATRate`.** A `NULL` value does not trigger the validation checks, because comparisons with `NULL` are not true. The calculated totals then stay `NULL`, and the limit check is skipped as well.\n- The same applies when the VAT list contains no row for the requested `VATRate`, for example `L` for a country without a reduced rate. Totals stay `NULL`.\n- `Pixi_CA_GetVATList` can return both the current rate and a rate valid 12 months ago for the same `VATRate`. Which row is used for the calculation is then not determined by the code.\n- The limit check adds the absolute value of the **sum** of existing referencing invoices, not the sum of absolute values.\n- Invoice lookups use `NOLOCK`, so concurrent credits for the same invoice are not strictly prevented from exceeding the invoice total.\n- `Pixi_CA_InsertManualInvoice` catches its own errors, logs them and does not re-raise them. If it fails, the caller may still receive the `OK` row. This can be followed by an `Error` row if the final commit fails because the transaction was already rolled back.\n- The text of the generic error (`...getting the report values...`) is misleading; it covers any unexpected error of this call.\n- The inner procedures `Pixi_GetNextInvNr`, `Pixi_CA_AddPixiInvoice`, `Pixi_AddDataForSEPAExportToInvoice` and `Pixi_MQ_EventPublish` are not attached. Their exact effects, such as customer account bookings and the MQ event, are not documented here.\n\nDocumentation: https://pixi-api-docs.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": "Creates a manual credit note (negative invoice) for an existing invoice with a single amount and VAT rate.\n\nCreates a credit note that references an existing invoice. The credit has no item lines; it consists of one amount and one VAT rate.\n\n1. **Validation**\n - `Amount` must be greater than 0.\n - `VATRate` must be `H`, `L` or `N`.\n - At least one of `InvoiceKey` or `InvoiceNr` must be given. If only `InvoiceNr` is given, the key is looked up in `Invoices`. The invoice must exist. If both are given, they must belong to the same invoice.\n2. **Invoice data**: order type, invoice location, customer, billing and shipping address and currency are taken from the original invoice. The country comes from the billing address.\n3. **Position text**: if `PositionText` is empty, a default text is built. With `LanguageId` = 1 it is `Manual Credit: Created From: {InvoiceNr}`. Otherwise it is `Manuell Gutschrift: Erstellt von: {InvoiceNr}`. `LanguageId` defaults to 2.\n4. **VAT calculation**: the VAT rates for the country and order type are read with `Pixi_CA_GetVATList`. The row with the requested `VATRate` is used.\n - For order type `B2B`, `Amount` is treated as **net**: net = −`Amount`, gross = −`Amount` × (1 + VAT), rounded to 2 decimals.\n - For all other order types, `Amount` is treated as **gross**: gross = −`Amount`, net = −`Amount` / (1 + VAT), rounded to 2 decimals.\n5. **Limit check**: the absolute gross amount of the new credit is added to the absolute sum of the totals of all invoices that already reference the original invoice (`RefToInvoiceKey`). If the result is greater than the original invoice total, the call is rejected.\n6. **Creation**: `Pixi_CA_InsertManualInvoice` creates the credit. It does the following:\n - assigns the next invoice number;\n - inserts the record into `Invoices` with `RefToInvoiceKey`/`RefToInvoiceNr` pointing to the original invoice;\n - adds SEPA data and an `InvoicePackage` record;\n - books the credit to the customer account;\n - publishes the MQ event `InvoiceCreated`.\n\nThe call returns one status row with `Status` and `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceKey` | int | No | Key of the original invoice. Either this or `InvoiceNr` is required; if both are given they must match. |\n| `InvoiceNr` | varchar(20) | No | Number of the original invoice. Used to look up the key if `InvoiceKey` is not given. |\n| `PositionText` | varchar(120) | No | Text of the credit note, stored as the invoice text without lines. If empty, a default text with the original invoice number is used. |\n| `LanguageId` | tinyint | No | Language for the default position text. `NULL` is treated as 2. It is also passed to the inner procedure. |\n| `VATRate` | varchar(1) | No | VAT rate class of the credit amount. |\n| `Amount` | money | No | Positive credit amount. It is net for order type `B2B` and gross for all other order types. It is stored negative. |\n| `UserName` | varchar(50) | No | User name stored as creator of the credit note. |\n\n- The call runs in its own transaction. If a transaction is already open, it uses a savepoint instead. Validation errors roll back and return return code 2. Unexpected errors are logged via `log.InsertError` and return return code 3. Success returns 0. Return codes are not part of the SOAP rows.\n- **Always pass `Amount` and `VATRate`.** A `NULL` value does not trigger the validation checks, because comparisons with `NULL` are not true. The calculated totals then stay `NULL`, and the limit check is skipped as well.\n- The same applies when the VAT list contains no row for the requested `VATRate`, for example `L` for a country without a reduced rate. Totals stay `NULL`.\n- `Pixi_CA_GetVATList` can return both the current rate and a rate valid 12 months ago for the same `VATRate`. Which row is used for the calculation is then not determined by the code.\n- The limit check adds the absolute value of the **sum** of existing referencing invoices, not the sum of absolute values.\n- Invoice lookups use `NOLOCK`, so concurrent credits for the same invoice are not strictly prevented from exceeding the invoice total.\n- `Pixi_CA_InsertManualInvoice` catches its own errors, logs them and does not re-raise them. If it fails, the caller may still receive the `OK` row. This can be followed by an `Error` row if the final commit fails because the transaction was already rolled back.\n- The text of the generic error (`...getting the report values...`) is misleading; it covers any unexpected error of this call.\n- The inner procedures `Pixi_GetNextInvNr`, `Pixi_CA_AddPixiInvoice`, `Pixi_AddDataForSEPAExportToInvoice` and `Pixi_MQ_EventPublish` are not attached. Their exact effects, such as customer account bookings and the MQ event, are not documented here.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoice lines, either one line by key or a list filtered by creation and/or update date, with key-based paging.\n\nReads invoice lines from `Invlines`. Each line is joined to its invoice (`Invoices`) and to the invoice currency (`pixi.Currency`). Only one filter mode is used. The procedure checks the modes in this order:\n\n1. **Create or update date**: `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` is set. A line matches if `CreateDate` **or** `UpdateDate` is `>=` the from value, and `CreateDate` **or** `UpdateDate` is `<` the to value.\n2. **Create date**: `CreateDateFrom` or `CreateDateTo` is set. Filters on `CreateDate` (from inclusive, to exclusive).\n3. **Update date**: `UpdateDateFrom` or `UpdateDateTo` is set. Filters on `UpdateDate` (from inclusive, to exclusive).\n4. **Key range**: `RowCount` is passed (any non-NULL value). Returns all lines with `InvLineKey` greater than `InvlineKey`.\n5. **Single key**: none of the above applies. Returns the line whose `InvLineKey` equals `InvlineKey`.\n\nIn modes 1–4 only lines with `InvLineKey` > `InvlineKey` are returned, sorted by `InvLineKey` ascending. `InvlineKey` defaults to `0`, so all keys qualify by default.\n\nA non-zero `RowCount` limits the number of rows (`SET ROWCOUNT`). This enables paging: pass the last `InvLineKey` received as `InvlineKey` in the next call.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvlineKey` | int | No | Invoice line key. NULL is treated as `0`. In single-key mode the line with exactly this key is returned. In all other modes only lines with a greater key are returned (paging cursor). |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for `CreateDate`. Ignored if a `CreateAndUpdateDate*` parameter is set. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for `CreateDate`. Ignored if a `CreateAndUpdateDate*` parameter is set. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for `UpdateDate`. Used only if no `CreateAndUpdateDate*` or `CreateDate*` parameter is set. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for `UpdateDate`. Used only if no `CreateAndUpdateDate*` or `CreateDate*` parameter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive): matches if `CreateDate` or `UpdateDate` is on or after this value. Has the highest priority among the date filters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (exclusive): matches if `CreateDate` or `UpdateDate` is before this value. |\n| `RowCount` | int | No | Maximum number of rows to return. `0` or NULL means no limit. Any non-NULL value (including `0`) without a date filter switches to key-range mode. |\n\n- All reads use `NOLOCK`. Uncommitted data can be returned.\n- Lines are returned only if their invoice exists and the invoice's `CurrencyId` resolves to a currency (inner joins).\n- Calling without any parameters returns no rows: `InvlineKey` becomes `0` and the single-key mode looks for key `0`.\n- Passing `RowCount` = `0` switches to key-range mode without a row limit. This returns **all** invoice lines above `InvlineKey`.\n- Date filter modes exclude each other. For example, when `CreateAndUpdateDate*` is set, the `CreateDate*` and `UpdateDate*` parameters are ignored.\n- In the combined date mode, from and to are checked independently against either date. A line can therefore match even if neither date lies within the range.\n- `ItemPrice_OrderCurr` and `ShipCost_OrderCurr` are copies of `ItemPrice` and `ShipCost`. Code comments mark them for removal, so new integrations should not rely on them.\n- The final fallback branch of the code (empty result) can never be reached, because `InvlineKey` is never NULL at that point.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoice lines, either one line by key or a list filtered by creation and/or update date, with key-based paging.\n\nReads invoice lines from `Invlines`. Each line is joined to its invoice (`Invoices`) and to the invoice currency (`pixi.Currency`). Only one filter mode is used. The procedure checks the modes in this order:\n\n1. **Create or update date**: `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` is set. A line matches if `CreateDate` **or** `UpdateDate` is `>=` the from value, and `CreateDate` **or** `UpdateDate` is `<` the to value.\n2. **Create date**: `CreateDateFrom` or `CreateDateTo` is set. Filters on `CreateDate` (from inclusive, to exclusive).\n3. **Update date**: `UpdateDateFrom` or `UpdateDateTo` is set. Filters on `UpdateDate` (from inclusive, to exclusive).\n4. **Key range**: `RowCount` is passed (any non-NULL value). Returns all lines with `InvLineKey` greater than `InvlineKey`.\n5. **Single key**: none of the above applies. Returns the line whose `InvLineKey` equals `InvlineKey`.\n\nIn modes 1–4 only lines with `InvLineKey` > `InvlineKey` are returned, sorted by `InvLineKey` ascending. `InvlineKey` defaults to `0`, so all keys qualify by default.\n\nA non-zero `RowCount` limits the number of rows (`SET ROWCOUNT`). This enables paging: pass the last `InvLineKey` received as `InvlineKey` in the next call.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvlineKey` | int | No | Invoice line key. NULL is treated as `0`. In single-key mode the line with exactly this key is returned. In all other modes only lines with a greater key are returned (paging cursor). |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for `CreateDate`. Ignored if a `CreateAndUpdateDate*` parameter is set. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for `CreateDate`. Ignored if a `CreateAndUpdateDate*` parameter is set. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for `UpdateDate`. Used only if no `CreateAndUpdateDate*` or `CreateDate*` parameter is set. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for `UpdateDate`. Used only if no `CreateAndUpdateDate*` or `CreateDate*` parameter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive): matches if `CreateDate` or `UpdateDate` is on or after this value. Has the highest priority among the date filters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (exclusive): matches if `CreateDate` or `UpdateDate` is before this value. |\n| `RowCount` | int | No | Maximum number of rows to return. `0` or NULL means no limit. Any non-NULL value (including `0`) without a date filter switches to key-range mode. |\n\n- All reads use `NOLOCK`. Uncommitted data can be returned.\n- Lines are returned only if their invoice exists and the invoice's `CurrencyId` resolves to a currency (inner joins).\n- Calling without any parameters returns no rows: `InvlineKey` becomes `0` and the single-key mode looks for key `0`.\n- Passing `RowCount` = `0` switches to key-range mode without a row limit. This returns **all** invoice lines above `InvlineKey`.\n- Date filter modes exclude each other. For example, when `CreateAndUpdateDate*` is set, the `CreateDate*` and `UpdateDate*` parameters are ignored.\n- In the combined date mode, from and to are checked independently against either date. A line can therefore match even if neither date lies within the range.\n- `ItemPrice_OrderCurr` and `ShipCost_OrderCurr` are copies of `ItemPrice` and `ShipCost`. Code comments mark them for removal, so new integrations should not rely on them.\n- The final fallback branch of the code (empty result) can never be reached, because `InvlineKey` is never NULL at that point.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoice headers from Pixi, filtered by invoice key or number, by creation and/or update date, or as a key-ordered page.\n\nReads invoice header records from `Invoices`. The currency code is taken from `pixi.Currency`, and the highest-level per-invoice reminder from `Reminders` is used for reminder data. All modes return the same columns, sorted by `InvoiceKey` ascending.\n\nIf `RowCount` is set to a value other than 0, the number of returned rows is limited to it. A missing `InvoiceKey` is treated as `0`.\n\nThe first matching mode is used:\n\n1. **Create or update date**: `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` is set. Returns invoices with `InvoiceKey` > `InvoiceKey` whose `CreateDate` **or** `UpdateDate` lies between the two values. Both bounds are inclusive (`BETWEEN`).\n2. **Create date**: `CreateDateFrom` or `CreateDateTo` is set. Returns invoices with `InvoiceKey` > `InvoiceKey` and `CreateDate` >= from and < to. Either bound may be left out.\n3. **Update date**: `UpdateDateFrom` or `UpdateDateTo` is set. Same logic on `UpdateDate`.\n4. **Key range / paging**: `RowCount` is passed. Returns invoices with `InvoiceKey` greater than the given `InvoiceKey`. For paging, pass the last key received as the next `InvoiceKey`.\n5. **Single invoice**: otherwise returns the invoices with `InvoiceKey` = `InvoiceKey` **or** `InvoiceNr` = `InvoiceNr`.\n\nIn modes 1–3 the key condition also applies, so date filters can be combined with `InvoiceKey` and `RowCount` for keyset paging. `InvoiceNr` is only used in mode 5.\n\nThe column `ReminderLevel` returns the highest `HighestReminderLevel` from `Reminders` for the invoice, and `ReminderCosts` returns that reminder's costs. If no such reminder exists, both columns fall back to the values stored on the invoice. `VoucherSum_OrderCurr` is the gross voucher sum for `OrderType` `B2C` and the net voucher sum otherwise.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceKey` | int | No | Invoice key. In mode 5 it selects this invoice. In all other modes only invoices with a greater key are returned (paging start). NULL is treated as 0. |\n| `InvoiceNr` | varchar(20) | No | Invoice number to look up. Only used in mode 5, i.e. when no date filter and no `RowCount` is passed. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for `CreateDate`. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for `CreateDate`. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for `UpdateDate`. Only used if no create-date filter is given. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for `UpdateDate`. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive) for invoices created or updated in the period. Takes priority over all other filters. Pass it together with `CreateAndUpdateDateTo`. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (inclusive) for invoices created or updated in the period. |\n| `RowCount` | int | No | Maximum number of rows (0 or NULL = no limit). If passed, it also activates the key-range mode when no date filter is set. |\n\n- All reads use `NOLOCK`, so uncommitted data can be returned.\n- Invoices without a matching record in `pixi.Currency` (inner join on `CurrencyId`) are never returned.\n- Pitfall in mode 1: if only one of `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo` is given, the OR condition is always true. All invoices above `InvoiceKey` are then returned. Always pass both bounds.\n- Pitfall in mode 4: passing `InvoiceKey` together with `RowCount` returns the invoices **after** that key, not the invoice itself. `InvoiceNr` is ignored as soon as `RowCount` or a date filter is passed.\n- `RowCount` = 0 still selects mode 4, but without any row limit. This can return all invoices.\n- Without any parameters, mode 5 searches for `InvoiceKey` = 0 and normally returns an empty result. The final fallback branch (`WHERE 1 = 0`) is never reached.\n- The row limit uses `SET ROWCOUNT`.\n- The columns `Total_OrderCurr`, `Total_ShipCost_OrderCurr`, `VATBaseHigh_OrderCurr`, `VATBaseLow_OrderCurr`, `VATHigh_OrderCurr`, `VATLow_OrderCurr`, `VATBaseHigh_ShipCost_OrderCurr` and `VATBaseLow_ShipCost_OrderCurr` are only copies of other columns. Code comments mark them for removal, so they should not be relied on.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoice headers from Pixi, filtered by invoice key or number, by creation and/or update date, or as a key-ordered page.\n\nReads invoice header records from `Invoices`. The currency code is taken from `pixi.Currency`, and the highest-level per-invoice reminder from `Reminders` is used for reminder data. All modes return the same columns, sorted by `InvoiceKey` ascending.\n\nIf `RowCount` is set to a value other than 0, the number of returned rows is limited to it. A missing `InvoiceKey` is treated as `0`.\n\nThe first matching mode is used:\n\n1. **Create or update date**: `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` is set. Returns invoices with `InvoiceKey` > `InvoiceKey` whose `CreateDate` **or** `UpdateDate` lies between the two values. Both bounds are inclusive (`BETWEEN`).\n2. **Create date**: `CreateDateFrom` or `CreateDateTo` is set. Returns invoices with `InvoiceKey` > `InvoiceKey` and `CreateDate` >= from and < to. Either bound may be left out.\n3. **Update date**: `UpdateDateFrom` or `UpdateDateTo` is set. Same logic on `UpdateDate`.\n4. **Key range / paging**: `RowCount` is passed. Returns invoices with `InvoiceKey` greater than the given `InvoiceKey`. For paging, pass the last key received as the next `InvoiceKey`.\n5. **Single invoice**: otherwise returns the invoices with `InvoiceKey` = `InvoiceKey` **or** `InvoiceNr` = `InvoiceNr`.\n\nIn modes 1–3 the key condition also applies, so date filters can be combined with `InvoiceKey` and `RowCount` for keyset paging. `InvoiceNr` is only used in mode 5.\n\nThe column `ReminderLevel` returns the highest `HighestReminderLevel` from `Reminders` for the invoice, and `ReminderCosts` returns that reminder's costs. If no such reminder exists, both columns fall back to the values stored on the invoice. `VoucherSum_OrderCurr` is the gross voucher sum for `OrderType` `B2C` and the net voucher sum otherwise.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceKey` | int | No | Invoice key. In mode 5 it selects this invoice. In all other modes only invoices with a greater key are returned (paging start). NULL is treated as 0. |\n| `InvoiceNr` | varchar(20) | No | Invoice number to look up. Only used in mode 5, i.e. when no date filter and no `RowCount` is passed. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for `CreateDate`. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for `CreateDate`. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for `UpdateDate`. Only used if no create-date filter is given. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for `UpdateDate`. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive) for invoices created or updated in the period. Takes priority over all other filters. Pass it together with `CreateAndUpdateDateTo`. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (inclusive) for invoices created or updated in the period. |\n| `RowCount` | int | No | Maximum number of rows (0 or NULL = no limit). If passed, it also activates the key-range mode when no date filter is set. |\n\n- All reads use `NOLOCK`, so uncommitted data can be returned.\n- Invoices without a matching record in `pixi.Currency` (inner join on `CurrencyId`) are never returned.\n- Pitfall in mode 1: if only one of `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo` is given, the OR condition is always true. All invoices above `InvoiceKey` are then returned. Always pass both bounds.\n- Pitfall in mode 4: passing `InvoiceKey` together with `RowCount` returns the invoices **after** that key, not the invoice itself. `InvoiceNr` is ignored as soon as `RowCount` or a date filter is passed.\n- `RowCount` = 0 still selects mode 4, but without any row limit. This can return all invoices.\n- Without any parameters, mode 5 searches for `InvoiceKey` = 0 and normally returns an empty result. The final fallback branch (`WHERE 1 = 0`) is never reached.\n- The row limit uses `SET ROWCOUNT`.\n- The columns `Total_OrderCurr`, `Total_ShipCost_OrderCurr`, `VATBaseHigh_OrderCurr`, `VATBaseLow_OrderCurr`, `VATHigh_OrderCurr`, `VATLow_OrderCurr`, `VATBaseHigh_ShipCost_OrderCurr` and `VATBaseLow_ShipCost_OrderCurr` are only copies of other columns. Code comments mark them for removal, so they should not be relied on.\n\nDocumentation: https://pixi-api-docs.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": "Returns POS document headers (cash register receipts) from POSheader2, either a single header by key or a list filtered by create/update dates with key-based paging.\n\nReads header records of POS documents from table `POSheader2`. All branches return the same column set. If `POSHeaderKey` is not passed, it is treated as `0`.\n\nIf `RowCount` is set to a value other than `0`, the number of returned rows is limited via `SET ROWCOUNT`.\n\nThe parameters are evaluated in this order; only the first matching branch runs:\n\n1. **Create or update date** – if `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` is set: returns headers with `POSheaderKey > POSHeaderKey` where `PHcreateDate` or `PHupdateDate` is `>= CreateAndUpdateDateFrom` and `PHcreateDate` or `PHupdateDate` is `< CreateAndUpdateDateTo`.\n2. **Create date** – if `CreateDateFrom` or `CreateDateTo` is set: headers with `POSheaderKey > POSHeaderKey` and `PHcreateDate` in the range `[CreateDateFrom, CreateDateTo)`.\n3. **Update date** – if `UpdateDateFrom` or `UpdateDateTo` is set: headers with `POSheaderKey > POSHeaderKey` and `PHupdateDate` in the range `[UpdateDateFrom, UpdateDateTo)`.\n4. **Key range** – if `RowCount` is passed (not NULL): headers with `POSheaderKey > POSHeaderKey`.\n5. **Single header** – otherwise: the header with `POSheaderKey = POSHeaderKey`.\n\nBranches 1–4 are sorted by `POSheaderKey` ascending. For paging, pass the last `POSheaderKey` received as `POSHeaderKey` in the next call together with `RowCount`.\n\nLower date bounds are inclusive, upper bounds exclusive. Omitting one bound leaves that side open.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `POSHeaderKey` | int | No | Key of the POS header. Exact match in single-record mode; exclusive lower bound (`>`) for paging in the date and key-range modes. NULL is treated as `0`. |\n| `CreateDateFrom` | datetime | No | Inclusive lower bound for `PHcreateDate`. |\n| `CreateDateTo` | datetime | No | Exclusive upper bound for `PHcreateDate`. |\n| `UpdateDateFrom` | datetime | No | Inclusive lower bound for `PHupdateDate`. Ignored if a create date or combined filter is set. |\n| `UpdateDateTo` | datetime | No | Exclusive upper bound for `PHupdateDate`. Ignored if a create date or combined filter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Inclusive lower bound checked against `PHcreateDate` or `PHupdateDate`. Takes precedence over all other date filters. |\n| `CreateAndUpdateDateTo` | datetime | No | Exclusive upper bound checked against `PHcreateDate` or `PHupdateDate`. |\n| `RowCount` | int | No | Maximum number of rows (via `SET ROWCOUNT`); `0` or NULL means no limit. If passed without date filters, switches to key-range mode (`POSheaderKey > POSHeaderKey`). |\n\n- The table is read `WITH (NOLOCK)`; uncommitted data can be returned.\n- In the date branches `POSHeaderKey` is a lower bound (`>`), not an exact match. Passing a specific key together with a date filter does not return that header itself.\n- In the combined create/update filter the two bounds are checked independently: a row matches if any of the two dates is `>=` the lower bound and any of the two dates is `<` the upper bound, which is not necessarily the same date.\n- Calling without any parameter returns no rows (it searches for `POSheaderKey = 0`).\n- Passing `RowCount = 0` explicitly selects the key-range branch without a row limit, i.e. all headers with a key greater than `POSHeaderKey` are returned.\n- Column data types are not visible in the code; they come from table `POSheader2`.\n\nDocumentation: https://pixi-api-docs.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": "Returns POS document headers (cash register receipts) from POSheader2, either a single header by key or a list filtered by create/update dates with key-based paging.\n\nReads header records of POS documents from table `POSheader2`. All branches return the same column set. If `POSHeaderKey` is not passed, it is treated as `0`.\n\nIf `RowCount` is set to a value other than `0`, the number of returned rows is limited via `SET ROWCOUNT`.\n\nThe parameters are evaluated in this order; only the first matching branch runs:\n\n1. **Create or update date** – if `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` is set: returns headers with `POSheaderKey > POSHeaderKey` where `PHcreateDate` or `PHupdateDate` is `>= CreateAndUpdateDateFrom` and `PHcreateDate` or `PHupdateDate` is `< CreateAndUpdateDateTo`.\n2. **Create date** – if `CreateDateFrom` or `CreateDateTo` is set: headers with `POSheaderKey > POSHeaderKey` and `PHcreateDate` in the range `[CreateDateFrom, CreateDateTo)`.\n3. **Update date** – if `UpdateDateFrom` or `UpdateDateTo` is set: headers with `POSheaderKey > POSHeaderKey` and `PHupdateDate` in the range `[UpdateDateFrom, UpdateDateTo)`.\n4. **Key range** – if `RowCount` is passed (not NULL): headers with `POSheaderKey > POSHeaderKey`.\n5. **Single header** – otherwise: the header with `POSheaderKey = POSHeaderKey`.\n\nBranches 1–4 are sorted by `POSheaderKey` ascending. For paging, pass the last `POSheaderKey` received as `POSHeaderKey` in the next call together with `RowCount`.\n\nLower date bounds are inclusive, upper bounds exclusive. Omitting one bound leaves that side open.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `POSHeaderKey` | int | No | Key of the POS header. Exact match in single-record mode; exclusive lower bound (`>`) for paging in the date and key-range modes. NULL is treated as `0`. |\n| `CreateDateFrom` | datetime | No | Inclusive lower bound for `PHcreateDate`. |\n| `CreateDateTo` | datetime | No | Exclusive upper bound for `PHcreateDate`. |\n| `UpdateDateFrom` | datetime | No | Inclusive lower bound for `PHupdateDate`. Ignored if a create date or combined filter is set. |\n| `UpdateDateTo` | datetime | No | Exclusive upper bound for `PHupdateDate`. Ignored if a create date or combined filter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Inclusive lower bound checked against `PHcreateDate` or `PHupdateDate`. Takes precedence over all other date filters. |\n| `CreateAndUpdateDateTo` | datetime | No | Exclusive upper bound checked against `PHcreateDate` or `PHupdateDate`. |\n| `RowCount` | int | No | Maximum number of rows (via `SET ROWCOUNT`); `0` or NULL means no limit. If passed without date filters, switches to key-range mode (`POSheaderKey > POSHeaderKey`). |\n\n- The table is read `WITH (NOLOCK)`; uncommitted data can be returned.\n- In the date branches `POSHeaderKey` is a lower bound (`>`), not an exact match. Passing a specific key together with a date filter does not return that header itself.\n- In the combined create/update filter the two bounds are checked independently: a row matches if any of the two dates is `>=` the lower bound and any of the two dates is `<` the upper bound, which is not necessarily the same date.\n- Calling without any parameter returns no rows (it searches for `POSheaderKey = 0`).\n- Passing `RowCount = 0` explicitly selects the key-range branch without a row limit, i.e. all headers with a key greater than `POSHeaderKey` are returned.\n- Column data types are not visible in the code; they come from table `POSheader2`.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoice lines within a date range, optionally filtered by shop, payment type, supplier, category, EAN and internal item number.\n\nReads invoice lines from the view `PV_Invlines` and adds the currency code of the order from the exchange rate (`pixi.ExchRate`) and currency (`pixi.Currency`) tables.\n\nSteps:\n\n1. The number of returned rows is limited to `Rowcount` (default 1000).\n2. `DateFrom` is moved to the start of its day (00:00:00).\n3. If `DateTo` is empty or `NULL`, the current date and time is used. Otherwise it is moved to the end of its day (23:59:59.997).\n4. Empty strings in the optional filter parameters are treated as `NULL`, so the filter is not applied.\n5. Only invoice lines whose invoice date lies between `DateFrom` and `DateTo` are returned. These optional filters are combined with AND:\n - `ShopID`: `ShopID LIKE @ShopID`\n - `PaymentType`: exact match on `PaymentType`\n - `SupplNr`: the item must have an entry for this supplier in `AddItems`. Any supplier assigned to the item counts, not only the supplier stored on the invoice line.\n - `Category`: the category text is looked up in `TontrArten.TontrText`. The matching `TontrArt` is compared with `LIKE` against the `configtype` of the line.\n - `EAN`: `EANUPC LIKE @EAN`\n - `ItemNrInt`: `ItemNrInt LIKE @ItemNrInt`\n\nThe code has no `ORDER BY`, so the order of the rows is not defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Rowcount` | int | No | Maximum number of rows returned; 0 means no limit. |\n| `DateFrom` | datetime | Yes | Start of the invoice date range. The time is set to the start of the day. |\n| `DateTo` | datetime | No | End of the invoice date range, moved to the end of the day. If empty, the current date and time is used. |\n| `ShopID` | varchar(3) | No | Filter on the shop ID, compared with LIKE. Empty means all shops. |\n| `PaymentType` | char(1) | No | Filter on the payment type of the invoice (exact match). Empty means all payment types. |\n| `SupplNr` | varchar(4) | No | Supplier number. Returns only lines of items that have this supplier assigned in `AddItems`. |\n| `Category` | varchar(50) | No | Category text as stored in `TontrArten.TontrText`. It is translated to the category code and matched against the line's `configtype`. |\n| `EAN` | varchar(13) | No | Filter on the EAN/UPC of the item, compared with LIKE. |\n| `ItemNrInt` | varchar(50) | No | Filter on the internal item number, compared with LIKE. |\n\n- All tables are read `WITH (NOLOCK)`. Uncommitted data can appear in the result.\n- The row limit uses `SET ROWCOUNT`. `Rowcount` = 0 removes the limit.\n- `ShopID`, `EAN` and `ItemNrInt` are compared with `LIKE`, so wildcards such as `%` and `_` can be used.\n- If the `Category` text is not found in `TontrArten`, no rows are returned. If the text exists more than once, the subquery returns several values and SQL Server raises an error.\n- If `DateTo` is omitted, the range ends at the current time, not at the end of the current day.\n- Invoice lines without a matching exchange rate or currency are excluded by the inner joins.\n- `InvDate` is returned as a string in the format `yyyy-mm-dd hh:mi:ss`.\n- The header comment of the procedure is a generic template text and does not describe this call.\n- `PV_Invlines` is a view whose definition is not attached. The data types of most columns therefore cannot be derived.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoice lines within a date range, optionally filtered by shop, payment type, supplier, category, EAN and internal item number.\n\nReads invoice lines from the view `PV_Invlines` and adds the currency code of the order from the exchange rate (`pixi.ExchRate`) and currency (`pixi.Currency`) tables.\n\nSteps:\n\n1. The number of returned rows is limited to `Rowcount` (default 1000).\n2. `DateFrom` is moved to the start of its day (00:00:00).\n3. If `DateTo` is empty or `NULL`, the current date and time is used. Otherwise it is moved to the end of its day (23:59:59.997).\n4. Empty strings in the optional filter parameters are treated as `NULL`, so the filter is not applied.\n5. Only invoice lines whose invoice date lies between `DateFrom` and `DateTo` are returned. These optional filters are combined with AND:\n - `ShopID`: `ShopID LIKE @ShopID`\n - `PaymentType`: exact match on `PaymentType`\n - `SupplNr`: the item must have an entry for this supplier in `AddItems`. Any supplier assigned to the item counts, not only the supplier stored on the invoice line.\n - `Category`: the category text is looked up in `TontrArten.TontrText`. The matching `TontrArt` is compared with `LIKE` against the `configtype` of the line.\n - `EAN`: `EANUPC LIKE @EAN`\n - `ItemNrInt`: `ItemNrInt LIKE @ItemNrInt`\n\nThe code has no `ORDER BY`, so the order of the rows is not defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Rowcount` | int | No | Maximum number of rows returned; 0 means no limit. |\n| `DateFrom` | datetime | Yes | Start of the invoice date range. The time is set to the start of the day. |\n| `DateTo` | datetime | No | End of the invoice date range, moved to the end of the day. If empty, the current date and time is used. |\n| `ShopID` | varchar(3) | No | Filter on the shop ID, compared with LIKE. Empty means all shops. |\n| `PaymentType` | char(1) | No | Filter on the payment type of the invoice (exact match). Empty means all payment types. |\n| `SupplNr` | varchar(4) | No | Supplier number. Returns only lines of items that have this supplier assigned in `AddItems`. |\n| `Category` | varchar(50) | No | Category text as stored in `TontrArten.TontrText`. It is translated to the category code and matched against the line's `configtype`. |\n| `EAN` | varchar(13) | No | Filter on the EAN/UPC of the item, compared with LIKE. |\n| `ItemNrInt` | varchar(50) | No | Filter on the internal item number, compared with LIKE. |\n\n- All tables are read `WITH (NOLOCK)`. Uncommitted data can appear in the result.\n- The row limit uses `SET ROWCOUNT`. `Rowcount` = 0 removes the limit.\n- `ShopID`, `EAN` and `ItemNrInt` are compared with `LIKE`, so wildcards such as `%` and `_` can be used.\n- If the `Category` text is not found in `TontrArten`, no rows are returned. If the text exists more than once, the subquery returns several values and SQL Server raises an error.\n- If `DateTo` is omitted, the range ends at the current time, not at the end of the current day.\n- Invoice lines without a matching exchange rate or currency are excluded by the inner joins.\n- `InvDate` is returned as a string in the format `yyyy-mm-dd hh:mi:ss`.\n- The header comment of the procedure is a generic template text and does not describe this call.\n- `PV_Invlines` is a view whose definition is not attached. The data types of most columns therefore cannot be derived.\n\nDocumentation: https://pixi-api-docs.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": "Creates a Pixi automail of type `API_Invoice_eMail` for an invoice from the matching mail template and places it in the outbox or drafts.\n\nGenerates and queues an e-mail for one invoice using the Pixi automail module (AM) and the mail type `API_Invoice_eMail`.\n\nSteps:\n\n1. An empty `InvoiceNr` is treated as missing. A missing `Subject` or `Message` becomes an empty string.\n2. `Subject`, `Message` and `InvoiceNr` are stored in a temporary table (`Api_Subject`, `Api_Message`, `InvoiceNr`). The mail type's SQL query can read them when it builds the mail.\n3. The mail type `API_Invoice_eMail` is looked up in `AM_Type`. It must be enabled.\n4. The invoice is read from `Invoices` and joined to its billing address in `Addresses`. This gives the customer, shop ID, country, shipping vendor and payment type.\n5. A mail template of this type is selected with `fPixi_AM_GetTemplate`. It looks for an enabled template that matches shop, country, payment type and shipping vendor. If no template matches all four, it falls back to templates that match fewer of these criteria, and finally to a generic template.\n6. `pixi_AM_CreateMailForCSD` builds the mail: recipient, subject, body and body type.\n7. `Pixi_AM_SendManual` stores the mail in `AM_Mail` with status `CREATED`. It may also attach the invoice document.\n8. The key of the new mail record is returned in the column `AM_TypeKey`.\n\nIf a check fails, the call returns a row with `ReturnCode` = `ERROR` and an `ErrorMsg` and stops.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Yes | Number of the invoice the mail is created for (`Invoices.InvoiceNr`). An empty value is rejected. |\n| `Subject` | varchar(255) | Yes | Subject text. It is provided to the mail type query as `Api_Subject`. The final mail subject comes from the template. NULL is treated as an empty string. |\n| `Message` | varchar(1024) | Yes | Free message text. It is provided to the mail type query as `Api_Message`. NULL is treated as an empty string. |\n| `UserName` | varchar(50) | Yes | User stored as creator and last editor of the mail record. Values longer than 20 characters are truncated. |\n\n- The call does not send the mail directly. It creates an `AM_Mail` record in folder 1 (outbox), or in folder 0 (drafts) if the setting `PixiMail_ForceManualMode` = `1` or the mail type is in manual mode. It also publishes the MQ event `MailCreated`.\n- **Test mode:** if the setting `PixiMail_ForceTestMode` = `1` or the mail type has test mode enabled, the recipient is replaced by the address in the setting `PixiMail_Test_eMail`.\n- **Subject and message:** the passed `Subject` is overwritten by the subject that the template generates. `Subject` and `Message` only appear in the mail if the mail type's SQL query or the template uses `Api_Subject` / `Api_Message`. That query is stored in `AM_Type.AM_TypeSQLproc` and runs as dynamic SQL. Its exact behaviour cannot be seen from the code.\n- If the dynamic query fails, the error is only written to the AM log and the call returns `eMail was not created!`.\n- If the query returns no rows, an empty placeholder mail row is created. That row may then be stored with an empty recipient.\n- **Mail type must also be a folder-1 type:** `Pixi_AM_SendManual` requires the type with `AM_TypeFolder` = 1. Otherwise it raises `Email Type is disabled`. In that case the caller receives a `SqlMessage` and a row with `AM_TypeKey` = 0.\n- **Misleading column name:** `AM_TypeKey` holds the new mail key (identity of `AM_Mail`), not the type key.\n- **Invoice attachment:** the invoice document is attached via `AM_MailAttachment` only if the mail type allows attachments, the template has `AttachInvoiceDocument` = 1 and an attachment path is found.\n- `AM_MailInvoiceNr` is stored as NULL in the mail record.\n- `UserName` is passed to a `varchar(20)` parameter, so longer values are truncated.\n- Reads use `NOLOCK`. No explicit transaction is used.\n\nDocumentation: https://pixi-api-docs.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": "Creates a Pixi automail of type `API_Invoice_eMail` for an invoice from the matching mail template and places it in the outbox or drafts.\n\nGenerates and queues an e-mail for one invoice using the Pixi automail module (AM) and the mail type `API_Invoice_eMail`.\n\nSteps:\n\n1. An empty `InvoiceNr` is treated as missing. A missing `Subject` or `Message` becomes an empty string.\n2. `Subject`, `Message` and `InvoiceNr` are stored in a temporary table (`Api_Subject`, `Api_Message`, `InvoiceNr`). The mail type's SQL query can read them when it builds the mail.\n3. The mail type `API_Invoice_eMail` is looked up in `AM_Type`. It must be enabled.\n4. The invoice is read from `Invoices` and joined to its billing address in `Addresses`. This gives the customer, shop ID, country, shipping vendor and payment type.\n5. A mail template of this type is selected with `fPixi_AM_GetTemplate`. It looks for an enabled template that matches shop, country, payment type and shipping vendor. If no template matches all four, it falls back to templates that match fewer of these criteria, and finally to a generic template.\n6. `pixi_AM_CreateMailForCSD` builds the mail: recipient, subject, body and body type.\n7. `Pixi_AM_SendManual` stores the mail in `AM_Mail` with status `CREATED`. It may also attach the invoice document.\n8. The key of the new mail record is returned in the column `AM_TypeKey`.\n\nIf a check fails, the call returns a row with `ReturnCode` = `ERROR` and an `ErrorMsg` and stops.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Yes | Number of the invoice the mail is created for (`Invoices.InvoiceNr`). An empty value is rejected. |\n| `Subject` | varchar(255) | Yes | Subject text. It is provided to the mail type query as `Api_Subject`. The final mail subject comes from the template. NULL is treated as an empty string. |\n| `Message` | varchar(1024) | Yes | Free message text. It is provided to the mail type query as `Api_Message`. NULL is treated as an empty string. |\n| `UserName` | varchar(50) | Yes | User stored as creator and last editor of the mail record. Values longer than 20 characters are truncated. |\n\n- The call does not send the mail directly. It creates an `AM_Mail` record in folder 1 (outbox), or in folder 0 (drafts) if the setting `PixiMail_ForceManualMode` = `1` or the mail type is in manual mode. It also publishes the MQ event `MailCreated`.\n- **Test mode:** if the setting `PixiMail_ForceTestMode` = `1` or the mail type has test mode enabled, the recipient is replaced by the address in the setting `PixiMail_Test_eMail`.\n- **Subject and message:** the passed `Subject` is overwritten by the subject that the template generates. `Subject` and `Message` only appear in the mail if the mail type's SQL query or the template uses `Api_Subject` / `Api_Message`. That query is stored in `AM_Type.AM_TypeSQLproc` and runs as dynamic SQL. Its exact behaviour cannot be seen from the code.\n- If the dynamic query fails, the error is only written to the AM log and the call returns `eMail was not created!`.\n- If the query returns no rows, an empty placeholder mail row is created. That row may then be stored with an empty recipient.\n- **Mail type must also be a folder-1 type:** `Pixi_AM_SendManual` requires the type with `AM_TypeFolder` = 1. Otherwise it raises `Email Type is disabled`. In that case the caller receives a `SqlMessage` and a row with `AM_TypeKey` = 0.\n- **Misleading column name:** `AM_TypeKey` holds the new mail key (identity of `AM_Mail`), not the type key.\n- **Invoice attachment:** the invoice document is attached via `AM_MailAttachment` only if the mail type allows attachments, the template has `AttachInvoiceDocument` = 1 and an attachment path is found.\n- `AM_MailInvoiceNr` is stored as NULL in the mail record.\n- `UserName` is passed to a `varchar(20)` parameter, so longer values are truncated.\n- Reads use `NOLOCK`. No explicit transaction is used.\n\nDocumentation: https://pixi-api-docs.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": "Marks an invoice as paid by creating a manual booking event in the customer account and matching it against the invoice's open amount.\n\nWrapper around the internal procedure `pixi_SetInvoicePaid`. It returns a status row with `Status` and `Message`.\n\nSteps of the internal procedure:\n\n1. Looks up the invoice in `Invoices` by `InvoiceNR`. It reads the customer, the total, the paid sum, the currency and the exchange rate.\n2. Determines the customer account entry of the invoice with `Pixi_CA_GetCustomerAccountforInvoice`. The booking amount is the negated `OpenToMatch` of that entry.\n3. Validates the input in this order:\n - `paid` must be `1`. Setting an invoice to unpaid is not supported.\n - The invoice must exist.\n - The invoice must not be fully paid already (`total` = `PayedSum`).\n - `eventID` must be given.\n - The event must exist in `CustomerAccountEvents` with `IsManual = 1` and `OriginalAmountMultiply = 1`, i.e. a manual, positive event.\n - `PaidDate` (default: current date and time) must not lie in the future.\n4. Creates a manual booking event with `Pixi_CA_InsertManualBookingEvent`:\n - The event uses the invoice's currency and exchange rate.\n - The user name is `API`.\n - The event is matched against the invoice's customer account entry.\n\nOn success the call returns `Status = Success`. If an error reaches the wrapper, it returns `Status = Error` with the error text.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNR` | varchar(20) | Yes | Number of the invoice to set to paid (`Invoices.InvoiceNr`). |\n| `paid` | bit | Yes | Must be `1`. The value `0` (set to unpaid) is rejected with an error. |\n| `PaidDate` | datetime | No | Entry date of the booking. NULL uses the current date and time. Must not be in the future. |\n| `eventID` | varchar(3) | No | ID of the customer account event to book (`CustomerAccountEvents.EventID`). Although it has a default, it is mandatory. The event must be manual (`IsManual = 1`) and positive (`OriginalAmountMultiply = 1`). |\n| `PaidSum` | money | No | Paid amount. It is passed on but not used for the booking; the full open amount is always booked. |\n\n- `PaidSum` has no effect on the booked amount. A value of `0` is replaced by NULL, but the parameter is not used otherwise. The booking always covers the full open amount (`OpenToMatch`) of the invoice's customer account entry.\n- The internal procedure runs in its own transaction, or in a savepoint if a transaction is already open. `XACT_ABORT` is on, and the transaction is rolled back on error.\n- In its CATCH block the internal procedure calls `log.InsertError` with parameter `1`. That object is not attached. Whether it re-raises the error is therefore unknown. Only if it does will the wrapper return the `Error` row; otherwise a failed call could still report `Success`.\n- The customer account lookup runs before the validation. For a non-existing invoice it is called with NULL keys.\n- `Invoices` and `CustomerAccountEvents` are read with `NOLOCK`.\n- The tables written by `Pixi_CA_InsertManualBookingEvent` are not visible in the attached code.\n- The 'already paid' check compares `total` and `PayedSum` for exact equality. A partially paid invoice is booked with its remaining open amount.\n\nDocumentation: https://pixi-api-docs.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": "Marks an invoice as paid by creating a manual booking event in the customer account and matching it against the invoice's open amount.\n\nWrapper around the internal procedure `pixi_SetInvoicePaid`. It returns a status row with `Status` and `Message`.\n\nSteps of the internal procedure:\n\n1. Looks up the invoice in `Invoices` by `InvoiceNR`. It reads the customer, the total, the paid sum, the currency and the exchange rate.\n2. Determines the customer account entry of the invoice with `Pixi_CA_GetCustomerAccountforInvoice`. The booking amount is the negated `OpenToMatch` of that entry.\n3. Validates the input in this order:\n - `paid` must be `1`. Setting an invoice to unpaid is not supported.\n - The invoice must exist.\n - The invoice must not be fully paid already (`total` = `PayedSum`).\n - `eventID` must be given.\n - The event must exist in `CustomerAccountEvents` with `IsManual = 1` and `OriginalAmountMultiply = 1`, i.e. a manual, positive event.\n - `PaidDate` (default: current date and time) must not lie in the future.\n4. Creates a manual booking event with `Pixi_CA_InsertManualBookingEvent`:\n - The event uses the invoice's currency and exchange rate.\n - The user name is `API`.\n - The event is matched against the invoice's customer account entry.\n\nOn success the call returns `Status = Success`. If an error reaches the wrapper, it returns `Status = Error` with the error text.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNR` | varchar(20) | Yes | Number of the invoice to set to paid (`Invoices.InvoiceNr`). |\n| `paid` | bit | Yes | Must be `1`. The value `0` (set to unpaid) is rejected with an error. |\n| `PaidDate` | datetime | No | Entry date of the booking. NULL uses the current date and time. Must not be in the future. |\n| `eventID` | varchar(3) | No | ID of the customer account event to book (`CustomerAccountEvents.EventID`). Although it has a default, it is mandatory. The event must be manual (`IsManual = 1`) and positive (`OriginalAmountMultiply = 1`). |\n| `PaidSum` | money | No | Paid amount. It is passed on but not used for the booking; the full open amount is always booked. |\n\n- `PaidSum` has no effect on the booked amount. A value of `0` is replaced by NULL, but the parameter is not used otherwise. The booking always covers the full open amount (`OpenToMatch`) of the invoice's customer account entry.\n- The internal procedure runs in its own transaction, or in a savepoint if a transaction is already open. `XACT_ABORT` is on, and the transaction is rolled back on error.\n- In its CATCH block the internal procedure calls `log.InsertError` with parameter `1`. That object is not attached. Whether it re-raises the error is therefore unknown. Only if it does will the wrapper return the `Error` row; otherwise a failed call could still report `Success`.\n- The customer account lookup runs before the validation. For a non-existing invoice it is called with NULL keys.\n- `Invoices` and `CustomerAccountEvents` are read with `NOLOCK`.\n- The tables written by `Pixi_CA_InsertManualBookingEvent` are not visible in the attached code.\n- The 'already paid' check compares `total` and `PayedSum` for exact equality. A partially paid invoice is booked with its remaining open amount.\n\nDocumentation: https://pixi-api-docs.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": "Updates the package count, net and gross package weight and shipping vendor of an existing invoice and returns the stored values.\n\nSets shipping information on a single invoice in table `Invoices`, identified by `InvoiceNr`.\n\n1. The call checks whether an invoice with the given `InvoiceNr` exists. If not, it returns a status row with `Status` = `400` and nothing is changed.\n2. It reads the current values of `PackageNetWeight`, `PackageGrossWeight`, `Packages` and `ShipVendor`.\n3. It updates the invoice. Each field is only overwritten if the matching parameter is not `NULL`. Parameters that are left out or sent as `NULL` keep the current value. This allows partial updates, e.g. only the number of packages.\n4. If at least one row was updated, it returns `Status` = `200` with the stored values of the invoice. Otherwise it returns `Status` = `500` with the current values.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | No | Number of the invoice to update. Practically mandatory: without a matching invoice the call returns status `400`. |\n| `PackageNetWeight` | float | No | New net weight of the package(s). `NULL` keeps the current value. |\n| `PackageGrossWeight` | float | No | New gross weight of the package(s). `NULL` keeps the current value. |\n| `Packages` | int | No | New number of packages. `NULL` keeps the current value. |\n| `ShipVendor` | varchar(3) | No | New shipping vendor code, up to 3 characters. The value is not validated. `NULL` keeps the current value. |\n\n- A field cannot be reset to `NULL` with this call, because `NULL` parameters mean \"keep current value\".\n- `ShipVendor` is not validated. Any value of up to 3 characters is written as is.\n- Weights are not checked for plausibility, e.g. gross weight smaller than net weight or negative values.\n- The existence check and the reading of the old values use `NOLOCK`. No explicit transaction is used.\n- In practice the `500` branch only occurs if the invoice is deleted between the check and the update. In that case the row of the `500` result usually contains no data.\n- If several rows share the same `InvoiceNr`, all of them are updated and all are returned.\n- The column types in the result are taken from the variables declared in the code. The table definition of `Invoices` is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Updates the package count, net and gross package weight and shipping vendor of an existing invoice and returns the stored values.\n\nSets shipping information on a single invoice in table `Invoices`, identified by `InvoiceNr`.\n\n1. The call checks whether an invoice with the given `InvoiceNr` exists. If not, it returns a status row with `Status` = `400` and nothing is changed.\n2. It reads the current values of `PackageNetWeight`, `PackageGrossWeight`, `Packages` and `ShipVendor`.\n3. It updates the invoice. Each field is only overwritten if the matching parameter is not `NULL`. Parameters that are left out or sent as `NULL` keep the current value. This allows partial updates, e.g. only the number of packages.\n4. If at least one row was updated, it returns `Status` = `200` with the stored values of the invoice. Otherwise it returns `Status` = `500` with the current values.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | No | Number of the invoice to update. Practically mandatory: without a matching invoice the call returns status `400`. |\n| `PackageNetWeight` | float | No | New net weight of the package(s). `NULL` keeps the current value. |\n| `PackageGrossWeight` | float | No | New gross weight of the package(s). `NULL` keeps the current value. |\n| `Packages` | int | No | New number of packages. `NULL` keeps the current value. |\n| `ShipVendor` | varchar(3) | No | New shipping vendor code, up to 3 characters. The value is not validated. `NULL` keeps the current value. |\n\n- A field cannot be reset to `NULL` with this call, because `NULL` parameters mean \"keep current value\".\n- `ShipVendor` is not validated. Any value of up to 3 characters is written as is.\n- Weights are not checked for plausibility, e.g. gross weight smaller than net weight or negative values.\n- The existence check and the reading of the old values use `NOLOCK`. No explicit transaction is used.\n- In practice the `500` branch only occurs if the invoice is deleted between the check and the update. In that case the row of the `500` result usually contains no data.\n- If several rows share the same `InvoiceNr`, all of them are updated and all are returned.\n- The column types in the result are taken from the variables declared in the code. The table definition of `Invoices` is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Sets the reminder (dunning) level of an invoice identified by its invoice number.\n\nLooks up the invoice by `InvoiceNR` (`Invoices.InvoiceNr`) and passes its key to the internal procedure `Pixi_CA_R_SetLevel`, using `API` as user name.\n\nThat procedure works as follows:\n\n- **Level greater than 0:** It searches the reminders (`Reminders`) that contain a reminder line (`ReminderLines`) for this invoice and whose `HighestReminderLevel` equals `ReminderLevel`.\n - **If a matching reminder exists:**\n - The invoice gets the new `ReminderLevel`.\n - `UpdateEmp` is set to `API`.\n - `UpdateDate` is set to the **date of that reminder**, not to the current time.\n - All reminder lines of the invoice are reassigned to that reminder (`ReminderRef`).\n - **If no matching reminder exists:** Only the invoice is updated, with `UpdateDate` set to the current time.\n- **Level 0 or `NULL`:** The invoice's `ReminderLevel` is reset to `NULL`. `UpdateEmp` = `API` and `UpdateDate` = now.\n\nThe call returns no result set.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ReminderLevel` | int | Yes | New reminder level of the invoice. 0 or NULL resets the level to NULL. |\n| `InvoiceNR` | varchar(20) | Yes | Invoice number (`Invoices.InvoiceNr`) of the invoice to update. |\n\n- **No feedback:** There is no status row and no error handling. If the invoice number does not exist, nothing is updated and the call still succeeds silently.\n- **Ambiguous invoice numbers:** The invoice key is read with a scalar subquery. If several invoices share the same `InvoiceNr`, SQL Server raises error 512 (\"Subquery returned more than 1 value\").\n- **Locking:** The lookups in `Invoices`, `Reminders` and `ReminderLines` use `NOLOCK`.\n- **Transactions:** The updates run without an explicit transaction.\n- **No validation:** `ReminderLevel` is not checked against a range; any integer is written.\n- **Several matching reminders:** The reminder is picked by variable assignment with `ORDER BY ReminderDate`. In practice this usually yields the latest one, but SQL Server does not guarantee which row is used.\n- **Reassignment of lines:** When a matching reminder is found, all reminder lines of the invoice are moved to it, including lines that belonged to other reminders.\n- **Level 0:** The check that is meant to treat 0 as \"no level\" never applies (`NULLIF(@ReminderLevel, 0) = 0` is never true). With 0 the code therefore still searches for reminders with `HighestReminderLevel = 0`. The invoice level ends up as `NULL` either way.\n\nDocumentation: https://pixi-api-docs.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": "Sets the shipment and return tracking IDs of an invoice and, where it can be identified, of its invoice package, and publishes an `InvoiceChanged` event.\n\nUpdates tracking information on a Rechnung (`Invoices`) and its package (`pixi.InvoicePackage`). The result is always one status row with `Status` and `Message`.\n\n**Validation**\n- At least one of `PackageId` or `InvoiceNr` and at least one of `TrackingId` or `ReturnTrackingId` must be filled. Otherwise status `400` is returned. A `PackageId` of `0` counts as empty.\n- One leading and one trailing `;` is removed from `TrackingId` and `ReturnTrackingId`.\n\n**Finding invoice and package**\n- With `InvoiceNr`, the invoice is read by its number. All packages with `Id = PackageId` or belonging to that invoice are loaded.\n- With only `PackageId`, the package is loaded and its invoice is read.\n- If only `InvoiceNr` is sent, the invoice has more than one package and `Overwrite = 1`, status `400` is returned (`PackageId` is required).\n- If no package is found, status `400` is returned. This also happens when the invoice does not exist or has no package. The same applies if `PackageId` and `InvoiceNr` are both sent but the package does not belong to the invoice.\n- If the combined length of the stored value and the new value exceeds 512 characters, status `411` is returned. This is checked for `ShipmentTrackingID` and for `retTrackIDhist`.\n\n**Which records are updated**\n- The invoice is always updated.\n- The package is also updated in three cases:\n - `PackageId` and `InvoiceNr` match.\n - Only `InvoiceNr` is sent and the invoice has exactly one package.\n - Only `PackageId` is sent.\n- If only `InvoiceNr` is sent, the invoice has several packages and `Overwrite = 0`, only the invoice is updated.\n\n**Shipment tracking (`TrackingId`)**\n- `Overwrite = 0`: `TrackingId` is appended to `Invoices.ShipmentTrackingID`, separated by `;`. This only happens if the existing value does not already contain it (substring match).\n- `Overwrite = 1`: `ShipmentTrackingID` is rebuilt from the tracking IDs of all other packages of the invoice, each followed by `;`, plus `TrackingId`. If `TrackingId` is already contained in the sibling list, `ShipmentTrackingID` becomes `TrackingId` alone.\n- The package gets only the last `;`-separated segment of `TrackingId` as its `TrackingID`.\n\n**Return tracking (`ReturnTrackingId`)**\n- `Overwrite` does not affect return tracking.\n- If `ReturnTrackingId` is not yet contained in `Invoices.retTrackID`:\n - `retTrackID` is set to its last `;`-separated segment.\n - The full value plus a trailing `;` is appended to `retTrackIDhist`.\n- The package gets the last segment as its `ReturnTrackingId`.\n\n**Further steps**\n- The invoice gets `UpdateDate = GETDATE()` and `UpdateEmp = '(Return) TrackingID API Update'`.\n- The package gets `RecordModifiedOn` and `RecordModifiedByUserId`, the ID of the user `API`.\n- With `ResetClientNotifiedFlag = 1`, `ClientNotified` is set to `N` on the latest `AUS` (shipped) `OrderHistory` entry of each order line on the invoice. The shipment is then exported or notified again.\n- Finally the MQ event `InvoiceChanged` is published with the invoice key and the parameter `SetTrackingId`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PackageId` | int | No | ID of the invoice package (`pixi.InvoicePackage.Id`). Required if `InvoiceNr` is not sent. Also required when the invoice has several packages and `Overwrite = 1`. `0` counts as empty. |\n| `InvoiceNr` | varchar(20) | No | Invoice number (`Invoices.InvoiceNr`). Required if `PackageId` is not sent. If both are sent, the package must belong to this invoice. |\n| `TrackingId` | varchar(512) | No | Shipment tracking ID, optionally several IDs separated by `;`. The value goes into `Invoices.ShipmentTrackingID`. The package receives the last segment. Either this or `ReturnTrackingId` must be filled. |\n| `ReturnTrackingId` | varchar(512) | No | Return tracking ID, optionally several IDs separated by `;`. The last segment is stored in `Invoices.retTrackID` and in the package. The full value is appended to `retTrackIDhist`. |\n| `Overwrite` | bit | No | Controls how `TrackingId` is written to the invoice. It has no effect on the return tracking ID. |\n| `ResetClientNotifiedFlag` | bit | No | If `1`, sets `ClientNotified = 'N'` on the latest `AUS` order history entries of the invoice's order lines, so that the shipment is exported/notified again. |\n\n- **Transaction:** all changes run in one transaction. A savepoint is used if the caller already has an open transaction. Validation errors (`400`/`411`) change nothing; the transaction is still committed and the status row is returned.\n- **Unexpected SQL errors:** the transaction is rolled back and the error is written via `log.InsertError`. No status row is returned in this case.\n- **Status as string:** `Status` is a string (`200`, `400`, `411`), not an HTTP status. The SOAP call itself succeeds.\n- **Duplicate check:** the check for an existing tracking ID is a `LIKE '%…%'` substring match. A new ID that is part of an existing longer ID, or that contains `%` / `_`, may wrongly be treated as already present and not be appended.\n- **Messages:** they mention `InvoiceKey`, but the parameter is `PackageId`.\n- **NOLOCK:** invoices and packages are read with `NOLOCK`.\n- **Triggers:** `CONTEXT_INFO` is set to `0x11111` during the invoice update, presumably so that triggers can recognise this update. Their behaviour is not visible here.\n- **Unknown API user:** if no user `API` exists in `UCS_USERS`, `RecordModifiedByUserId` is set to `NULL`.\n- **MQ event:** `InvoiceChanged` is only sent if the setting `pixiMQ_Enabled` is active and the event is configured and enabled in `EventConfiguration`. Delivery failures are queued in `EventQueue` and do not cause an error in this call.\n\nDocumentation: https://pixi-api-docs.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": "Sets the shipment and return tracking IDs of an invoice and, where it can be identified, of its invoice package, and publishes an `InvoiceChanged` event.\n\nUpdates tracking information on a Rechnung (`Invoices`) and its package (`pixi.InvoicePackage`). The result is always one status row with `Status` and `Message`.\n\n**Validation**\n- At least one of `PackageId` or `InvoiceNr` and at least one of `TrackingId` or `ReturnTrackingId` must be filled. Otherwise status `400` is returned. A `PackageId` of `0` counts as empty.\n- One leading and one trailing `;` is removed from `TrackingId` and `ReturnTrackingId`.\n\n**Finding invoice and package**\n- With `InvoiceNr`, the invoice is read by its number. All packages with `Id = PackageId` or belonging to that invoice are loaded.\n- With only `PackageId`, the package is loaded and its invoice is read.\n- If only `InvoiceNr` is sent, the invoice has more than one package and `Overwrite = 1`, status `400` is returned (`PackageId` is required).\n- If no package is found, status `400` is returned. This also happens when the invoice does not exist or has no package. The same applies if `PackageId` and `InvoiceNr` are both sent but the package does not belong to the invoice.\n- If the combined length of the stored value and the new value exceeds 512 characters, status `411` is returned. This is checked for `ShipmentTrackingID` and for `retTrackIDhist`.\n\n**Which records are updated**\n- The invoice is always updated.\n- The package is also updated in three cases:\n - `PackageId` and `InvoiceNr` match.\n - Only `InvoiceNr` is sent and the invoice has exactly one package.\n - Only `PackageId` is sent.\n- If only `InvoiceNr` is sent, the invoice has several packages and `Overwrite = 0`, only the invoice is updated.\n\n**Shipment tracking (`TrackingId`)**\n- `Overwrite = 0`: `TrackingId` is appended to `Invoices.ShipmentTrackingID`, separated by `;`. This only happens if the existing value does not already contain it (substring match).\n- `Overwrite = 1`: `ShipmentTrackingID` is rebuilt from the tracking IDs of all other packages of the invoice, each followed by `;`, plus `TrackingId`. If `TrackingId` is already contained in the sibling list, `ShipmentTrackingID` becomes `TrackingId` alone.\n- The package gets only the last `;`-separated segment of `TrackingId` as its `TrackingID`.\n\n**Return tracking (`ReturnTrackingId`)**\n- `Overwrite` does not affect return tracking.\n- If `ReturnTrackingId` is not yet contained in `Invoices.retTrackID`:\n - `retTrackID` is set to its last `;`-separated segment.\n - The full value plus a trailing `;` is appended to `retTrackIDhist`.\n- The package gets the last segment as its `ReturnTrackingId`.\n\n**Further steps**\n- The invoice gets `UpdateDate = GETDATE()` and `UpdateEmp = '(Return) TrackingID API Update'`.\n- The package gets `RecordModifiedOn` and `RecordModifiedByUserId`, the ID of the user `API`.\n- With `ResetClientNotifiedFlag = 1`, `ClientNotified` is set to `N` on the latest `AUS` (shipped) `OrderHistory` entry of each order line on the invoice. The shipment is then exported or notified again.\n- Finally the MQ event `InvoiceChanged` is published with the invoice key and the parameter `SetTrackingId`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PackageId` | int | No | ID of the invoice package (`pixi.InvoicePackage.Id`). Required if `InvoiceNr` is not sent. Also required when the invoice has several packages and `Overwrite = 1`. `0` counts as empty. |\n| `InvoiceNr` | varchar(20) | No | Invoice number (`Invoices.InvoiceNr`). Required if `PackageId` is not sent. If both are sent, the package must belong to this invoice. |\n| `TrackingId` | varchar(512) | No | Shipment tracking ID, optionally several IDs separated by `;`. The value goes into `Invoices.ShipmentTrackingID`. The package receives the last segment. Either this or `ReturnTrackingId` must be filled. |\n| `ReturnTrackingId` | varchar(512) | No | Return tracking ID, optionally several IDs separated by `;`. The last segment is stored in `Invoices.retTrackID` and in the package. The full value is appended to `retTrackIDhist`. |\n| `Overwrite` | bit | No | Controls how `TrackingId` is written to the invoice. It has no effect on the return tracking ID. |\n| `ResetClientNotifiedFlag` | bit | No | If `1`, sets `ClientNotified = 'N'` on the latest `AUS` order history entries of the invoice's order lines, so that the shipment is exported/notified again. |\n\n- **Transaction:** all changes run in one transaction. A savepoint is used if the caller already has an open transaction. Validation errors (`400`/`411`) change nothing; the transaction is still committed and the status row is returned.\n- **Unexpected SQL errors:** the transaction is rolled back and the error is written via `log.InsertError`. No status row is returned in this case.\n- **Status as string:** `Status` is a string (`200`, `400`, `411`), not an HTTP status. The SOAP call itself succeeds.\n- **Duplicate check:** the check for an existing tracking ID is a `LIKE '%…%'` substring match. A new ID that is part of an existing longer ID, or that contains `%` / `_`, may wrongly be treated as already present and not be appended.\n- **Messages:** they mention `InvoiceKey`, but the parameter is `PackageId`.\n- **NOLOCK:** invoices and packages are read with `NOLOCK`.\n- **Triggers:** `CONTEXT_INFO` is set to `0x11111` during the invoice update, presumably so that triggers can recognise this update. Their behaviour is not visible here.\n- **Unknown API user:** if no user `API` exists in `UCS_USERS`, `RecordModifiedByUserId` is set to `NULL`.\n- **MQ event:** `InvoiceChanged` is only sent if the setting `pixiMQ_Enabled` is active and the event is configured and enabled in `EventConfiguration`. Delivery failures are queued in `EventQueue` and do not cause an error in this call.\n\nDocumentation: https://pixi-api-docs.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": "Checks whether an item can be converted to or from a bundle and returns its key data together with a `CanConvert` flag.\n\nIdentifies an item and checks whether it is already in use, which would prevent converting it (changing its bundle status).\n\n**Identifying the item** (empty strings are treated as `NULL`):\n1. If `ItemKey` is passed, `ItemNrInt` and `EAN` are ignored.\n2. Otherwise, if `ItemNrInt` is passed, the item is looked up in the item codes (code type 2 = internal item number); `EAN` is then ignored.\n3. Otherwise, if `EAN` is passed, the item is looked up in the item codes (code type 1 = EAN).\n\nIf several items match a code, the first match found is used.\n\n**Check:** `CanConvert` is `0` if the item is referenced in at least one of the following, otherwise `1`:\n- order lines (`Orderlines`)\n- bundle order lines (`BundleOrderlines`)\n- bin location stock records (`InvBinItem`)\n\n**Result:** one row with the item's key, internal item number, EAN, bundle flag and the `CanConvert` flag. If no item is found, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item. Takes precedence over `ItemNrInt` and `EAN`. |\n| `ItemNrInt` | varchar(50) | No | Internal item number, looked up in the item codes (code type 2). Used only if `ItemKey` is empty; takes precedence over `EAN`. |\n| `EAN` | varchar(13) | No | EAN of the item, looked up in the item codes (code type 1). Used only if neither `ItemKey` nor `ItemNrInt` is passed. |\n\n- The call only checks; it does not convert anything.\n- All reads use `NOLOCK`, so the result may reflect uncommitted data.\n- If the item was found via `EAN`, the `EAN` column returns the passed EAN (which may be an additional EAN code) instead of the item's main `EANUPC`.\n- An unknown `ItemNrInt` does not fall back to `EAN`; the result is then empty.\n- There is no error row: an empty result means the item was not found.\n\nDocumentation: https://pixi-api-docs.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": "Checks whether an item can be converted to or from a bundle and returns its key data together with a `CanConvert` flag.\n\nIdentifies an item and checks whether it is already in use, which would prevent converting it (changing its bundle status).\n\n**Identifying the item** (empty strings are treated as `NULL`):\n1. If `ItemKey` is passed, `ItemNrInt` and `EAN` are ignored.\n2. Otherwise, if `ItemNrInt` is passed, the item is looked up in the item codes (code type 2 = internal item number); `EAN` is then ignored.\n3. Otherwise, if `EAN` is passed, the item is looked up in the item codes (code type 1 = EAN).\n\nIf several items match a code, the first match found is used.\n\n**Check:** `CanConvert` is `0` if the item is referenced in at least one of the following, otherwise `1`:\n- order lines (`Orderlines`)\n- bundle order lines (`BundleOrderlines`)\n- bin location stock records (`InvBinItem`)\n\n**Result:** one row with the item's key, internal item number, EAN, bundle flag and the `CanConvert` flag. If no item is found, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item. Takes precedence over `ItemNrInt` and `EAN`. |\n| `ItemNrInt` | varchar(50) | No | Internal item number, looked up in the item codes (code type 2). Used only if `ItemKey` is empty; takes precedence over `EAN`. |\n| `EAN` | varchar(13) | No | EAN of the item, looked up in the item codes (code type 1). Used only if neither `ItemKey` nor `ItemNrInt` is passed. |\n\n- The call only checks; it does not convert anything.\n- All reads use `NOLOCK`, so the result may reflect uncommitted data.\n- If the item was found via `EAN`, the `EAN` column returns the passed EAN (which may be an additional EAN code) instead of the item's main `EANUPC`.\n- An unknown `ItemNrInt` does not fall back to `EAN`; the result is then empty.\n- There is no error row: an empty result means the item was not found.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new supplier assignment (AddItems record) for an existing item, optionally with its own EAN and as preferred supplier.\n\nAdds a supplier to an item by inserting a row into `AddItems`. The call returns exactly one status row (`Status`, `Message`).\n\nSteps:\n\n1. **Supplier check**: `SupplNr` is mandatory. An empty string counts as missing. The supplier must exist in `Suppliers`.\n2. **Item identification**: the item is resolved from `ItemKey`, `EAN` (barcode, code type 1) and/or `ItemNrInt` (shop item number, code type 2) through `pixi.ItemCode`. At least one of them is required. If several are given, all of them must point to the same item. Each given value must be found.\n3. **NewEAN check**: if `NewEAN` is given, it must not exist as a code of a scannable code type on any other item.\n4. **EAN of the new record**: the EAN stored on the new supplier record is `NewEAN`. If that is empty, `EAN` is used. If both are empty, the item's `EANUPC` from `items` is used. `ItemNrInt` (if not given), `IntLinkNR1`, `IntLinkNR` and the sales `Price` are taken from the item.\n5. **Duplicate check**: if the item already has a barcode entry in `pixi.ItemCode` with this EAN for this supplier, the call stops with an error.\n6. **Preferred supplier**: if `PreferredSupplier` = 1, the item's current preferred supplier record (one record, `TOP (1)`) is reset to `PreferredSupplier` = 0 first.\n7. **Insert**: a new `AddItems` row is created. It gets `SupplPrice`, `ItemNrSuppl`, `SupplDeliveryTime` (= `ItemDeliveryTime`), `MinOrderQty`, `OrderOnlyPackageUnits` (= `OnlyPU`), `Active` (= `IsActive`) and `PreferredSupplier`. `AutoPrice` is set to 0 and `CreateDate` to the current time.\n\nOn success the status is `New record inserted`. The message lists the stored supplier price, supplier item number and EAN.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Item key used to identify the item. 0 is treated as not given. |\n| `ItemNrInt` | varchar(50) | No | Shop item number used to identify the item (code type 2). If omitted, the item's own `ItemNrInt` is stored on the new record. |\n| `EAN` | varchar(13) | No | Barcode used to identify the item (code type 1). It is also stored as the EAN of the new record if `NewEAN` is empty. |\n| `NewEAN` | varchar(13) | No | EAN to store on the new supplier record. It must not exist as a scannable code on another item. |\n| `SupplNr` | varchar(4) | Yes | Supplier number (mandatory). It must exist in `Suppliers`. |\n| `SupplPrice` | money | No | Purchase price from this supplier. NULL becomes 0. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier's item number. An empty string is stored as NULL. |\n| `PreferredSupplier` | bit | No | Marks the new record as preferred supplier. The previous preferred supplier record is reset first. |\n| `MinOrderQty` | int | No | Minimum order quantity. NULL becomes 0. |\n| `OnlyPU` | bit | No | Order only in package units. Stored in `OrderOnlyPackageUnits`. |\n| `ItemDeliveryTime` | int | No | Supplier delivery time. Stored in `SupplDeliveryTime`. |\n| `IsActive` | bit | No | Whether the supplier record is active. NULL becomes 1. |\n\n- All errors are returned as a normal row with `Status` = `Error`; no `RAISERROR` is used.\n- The reset of the old preferred supplier and the insert run in a transaction. If the call is already inside a transaction, a savepoint is used instead.\n- On an exception the transaction is rolled back and the error is logged via `log.InsertError`. The SQL error text is then returned in `Message`.\n- Lookups use `NOLOCK`, so uncommitted data may be read.\n- The duplicate check reads `pixi.ItemCode`, not `AddItems`. Whether `pixi.ItemCode` is kept in sync with `AddItems` (e.g. by triggers) is not visible in this code.\n- If no EAN can be determined at all (no `NewEAN`, no `EAN`, item without `EANUPC`), the duplicate check never matches. The record is then inserted with an empty EAN.\n- `NewEAN` only sets the EAN of the new supplier record. The item's main EAN in `items` is not changed.\n- `ItemNrInt` is not converted from an empty string to NULL. Sending an empty `ItemNrInt` together with another identifier stores an empty `ItemNrInt` on the new record.\n- `ItemDeliveryTime` is not replaced by 0 when NULL is sent explicitly.\n- Only one previously preferred record (`TOP (1)`) is reset. Other records flagged as preferred remain unchanged.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new supplier assignment (AddItems record) for an existing item, optionally with its own EAN and as preferred supplier.\n\nAdds a supplier to an item by inserting a row into `AddItems`. The call returns exactly one status row (`Status`, `Message`).\n\nSteps:\n\n1. **Supplier check**: `SupplNr` is mandatory. An empty string counts as missing. The supplier must exist in `Suppliers`.\n2. **Item identification**: the item is resolved from `ItemKey`, `EAN` (barcode, code type 1) and/or `ItemNrInt` (shop item number, code type 2) through `pixi.ItemCode`. At least one of them is required. If several are given, all of them must point to the same item. Each given value must be found.\n3. **NewEAN check**: if `NewEAN` is given, it must not exist as a code of a scannable code type on any other item.\n4. **EAN of the new record**: the EAN stored on the new supplier record is `NewEAN`. If that is empty, `EAN` is used. If both are empty, the item's `EANUPC` from `items` is used. `ItemNrInt` (if not given), `IntLinkNR1`, `IntLinkNR` and the sales `Price` are taken from the item.\n5. **Duplicate check**: if the item already has a barcode entry in `pixi.ItemCode` with this EAN for this supplier, the call stops with an error.\n6. **Preferred supplier**: if `PreferredSupplier` = 1, the item's current preferred supplier record (one record, `TOP (1)`) is reset to `PreferredSupplier` = 0 first.\n7. **Insert**: a new `AddItems` row is created. It gets `SupplPrice`, `ItemNrSuppl`, `SupplDeliveryTime` (= `ItemDeliveryTime`), `MinOrderQty`, `OrderOnlyPackageUnits` (= `OnlyPU`), `Active` (= `IsActive`) and `PreferredSupplier`. `AutoPrice` is set to 0 and `CreateDate` to the current time.\n\nOn success the status is `New record inserted`. The message lists the stored supplier price, supplier item number and EAN.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Item key used to identify the item. 0 is treated as not given. |\n| `ItemNrInt` | varchar(50) | No | Shop item number used to identify the item (code type 2). If omitted, the item's own `ItemNrInt` is stored on the new record. |\n| `EAN` | varchar(13) | No | Barcode used to identify the item (code type 1). It is also stored as the EAN of the new record if `NewEAN` is empty. |\n| `NewEAN` | varchar(13) | No | EAN to store on the new supplier record. It must not exist as a scannable code on another item. |\n| `SupplNr` | varchar(4) | Yes | Supplier number (mandatory). It must exist in `Suppliers`. |\n| `SupplPrice` | money | No | Purchase price from this supplier. NULL becomes 0. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier's item number. An empty string is stored as NULL. |\n| `PreferredSupplier` | bit | No | Marks the new record as preferred supplier. The previous preferred supplier record is reset first. |\n| `MinOrderQty` | int | No | Minimum order quantity. NULL becomes 0. |\n| `OnlyPU` | bit | No | Order only in package units. Stored in `OrderOnlyPackageUnits`. |\n| `ItemDeliveryTime` | int | No | Supplier delivery time. Stored in `SupplDeliveryTime`. |\n| `IsActive` | bit | No | Whether the supplier record is active. NULL becomes 1. |\n\n- All errors are returned as a normal row with `Status` = `Error`; no `RAISERROR` is used.\n- The reset of the old preferred supplier and the insert run in a transaction. If the call is already inside a transaction, a savepoint is used instead.\n- On an exception the transaction is rolled back and the error is logged via `log.InsertError`. The SQL error text is then returned in `Message`.\n- Lookups use `NOLOCK`, so uncommitted data may be read.\n- The duplicate check reads `pixi.ItemCode`, not `AddItems`. Whether `pixi.ItemCode` is kept in sync with `AddItems` (e.g. by triggers) is not visible in this code.\n- If no EAN can be determined at all (no `NewEAN`, no `EAN`, item without `EANUPC`), the duplicate check never matches. The record is then inserted with an empty EAN.\n- `NewEAN` only sets the EAN of the new supplier record. The item's main EAN in `items` is not changed.\n- `ItemNrInt` is not converted from an empty string to NULL. Sending an empty `ItemNrInt` together with another identifier stores an empty `ItemNrInt` on the new record.\n- `ItemDeliveryTime` is not replaced by 0 when NULL is sent explicitly.\n- Only one previously preferred record (`TOP (1)`) is reset. Other records flagged as preferred remain unchanged.\n\nDocumentation: https://pixi-api-docs.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": "Deletes the supplier assignment (AddItems record) of an Artikel for a given Lieferant, provided no open supplier orders exist for it.\n\nRemoves exactly one item-supplier record from `AddItems`.\n\n1. `ItemKey` = `0` is treated as `NULL`, an empty `ItemNrInt` as `NULL`.\n2. **Candidate items** are all rows in `Items` where `ItemNrInt` = `@ItemNrInt` **or** `ItemKey` = `@ItemKey` **or** `EANUPC` = `@EAN`. The criteria are combined with OR, so several items can become candidates.\n3. In `AddItems`, the records of these candidate items are searched that belong to `@SupplNr`. If `@EAN` is given, the `EanUpc` of the `AddItems` record must also match.\n4. If no record is found, the error *No records found with provided parameters.* is returned. If more than one record is found, the error *Item could not be uniquely identified.* is returned. In both cases nothing is changed.\n5. If any candidate item appears on a supplier order of this Lieferant whose status is flagged as open (`IsAllOpen` = 1, e.g. NEW, BES, CON), an error is returned and nothing is deleted.\n6. Otherwise the `AddItems` record is deleted inside a transaction (or a savepoint if the caller already has an open transaction).\n7. If `@EAN` was given, the item's main barcode in `Items.EanUpc` equals `@EAN`, and no `AddItems` record of the candidate items carries that EAN anymore, `Items.EanUpc` is replaced by the `EanUpc` of one of the remaining `AddItems` records of the item. Records of suppliers other than `MGS` are preferred.\n8. A single status row with `STATUS` and `MESSAGE` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the Artikel. `0` is treated as not set. |\n| `ItemNrInt` | varchar(50) | No | Internal item number of the Artikel. An empty string is treated as not set. |\n| `SupplNr` | varchar(4) | Yes | Supplier number of the Lieferant whose assignment is deleted. |\n| `EAN` | varchar(13) | No | EAN/UPC barcode. Used to find the Artikel via `Items.EANUPC` and, if set, additionally restricts the `AddItems` record to this EAN. Also triggers the replacement of the main barcode if it is no longer used. |\n\n- All lookups use `NOLOCK`, so the uniqueness and open-order checks can see uncommitted data.\n- Because the item criteria are combined with OR, passing several identifiers that point to different items widens the candidate set. The open supplier order check and the barcode update apply to **all** candidate items, not only to the item whose `AddItems` record was deleted.\n- If no `AddItems` record remains for an item when the barcode is replaced, `Items.EanUpc` is set to `NULL`.\n- An empty string for `EAN` is not converted to `NULL`; it is used as a filter value.\n- The success message only contains `ItemNrInt` if it was passed; when calling with `ItemKey` or `EAN` only, that part is empty.\n- The success row is produced before the temporary tables are dropped via `util.TempTableDrop` (not attached) and before the commit. If an error occurs at that point, an additional error row may follow.\n- Errors inside the delete/update block are caught, the transaction (or savepoint) is rolled back and an `Error` row is returned instead of a SQL error.\n\nDocumentation: https://pixi-api-docs.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": "Deletes the supplier assignment (AddItems record) of an Artikel for a given Lieferant, provided no open supplier orders exist for it.\n\nRemoves exactly one item-supplier record from `AddItems`.\n\n1. `ItemKey` = `0` is treated as `NULL`, an empty `ItemNrInt` as `NULL`.\n2. **Candidate items** are all rows in `Items` where `ItemNrInt` = `@ItemNrInt` **or** `ItemKey` = `@ItemKey` **or** `EANUPC` = `@EAN`. The criteria are combined with OR, so several items can become candidates.\n3. In `AddItems`, the records of these candidate items are searched that belong to `@SupplNr`. If `@EAN` is given, the `EanUpc` of the `AddItems` record must also match.\n4. If no record is found, the error *No records found with provided parameters.* is returned. If more than one record is found, the error *Item could not be uniquely identified.* is returned. In both cases nothing is changed.\n5. If any candidate item appears on a supplier order of this Lieferant whose status is flagged as open (`IsAllOpen` = 1, e.g. NEW, BES, CON), an error is returned and nothing is deleted.\n6. Otherwise the `AddItems` record is deleted inside a transaction (or a savepoint if the caller already has an open transaction).\n7. If `@EAN` was given, the item's main barcode in `Items.EanUpc` equals `@EAN`, and no `AddItems` record of the candidate items carries that EAN anymore, `Items.EanUpc` is replaced by the `EanUpc` of one of the remaining `AddItems` records of the item. Records of suppliers other than `MGS` are preferred.\n8. A single status row with `STATUS` and `MESSAGE` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the Artikel. `0` is treated as not set. |\n| `ItemNrInt` | varchar(50) | No | Internal item number of the Artikel. An empty string is treated as not set. |\n| `SupplNr` | varchar(4) | Yes | Supplier number of the Lieferant whose assignment is deleted. |\n| `EAN` | varchar(13) | No | EAN/UPC barcode. Used to find the Artikel via `Items.EANUPC` and, if set, additionally restricts the `AddItems` record to this EAN. Also triggers the replacement of the main barcode if it is no longer used. |\n\n- All lookups use `NOLOCK`, so the uniqueness and open-order checks can see uncommitted data.\n- Because the item criteria are combined with OR, passing several identifiers that point to different items widens the candidate set. The open supplier order check and the barcode update apply to **all** candidate items, not only to the item whose `AddItems` record was deleted.\n- If no `AddItems` record remains for an item when the barcode is replaced, `Items.EanUpc` is set to `NULL`.\n- An empty string for `EAN` is not converted to `NULL`; it is used as a filter value.\n- The success message only contains `ItemNrInt` if it was passed; when calling with `ItemKey` or `EAN` only, that part is empty.\n- The success row is produced before the temporary tables are dropped via `util.TempTableDrop` (not attached) and before the commit. If an error occurs at that point, an additional error row may follow.\n- Errors inside the delete/update block are caught, the transaction (or savepoint) is rolled back and an `Error` row is returned instead of a SQL error.\n\nDocumentation: https://pixi-api-docs.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": "Returns a batch of items with preferred supplier, prices, stock and location-specific planning data for export to the Logcontrol Dispo software.\n\nExports item master data for the Logcontrol disposition (purchase planning) software. The call works in batches of items.\n\n1. **Candidate selection:** the first `ItemCount` items with `ItemKey` greater than `ItemKeyStart` are taken from `items`, ordered by `ItemKey` ascending, together with their default supplier.\n2. **Preferred supplier:** if an `AddItems` record with `PreferredSupplier = 1` exists, its supplier replaces the default supplier of the item.\n3. **Additional data per item:**\n - item tags (tags of type `TypeId = 1`) as a comma-separated list,\n - the earliest `OrderDate` of all order lines of the item,\n - the summed bin quantity (`BinItemQTY`) over all bins in locations that are not special stock (`SpecialStock <> 1`).\n4. **Result:** one row per item **and location** from `ItemLocationSpecific`. Only rows are returned where\n - the supplier exists in `Suppliers`,\n - an `AddItems` record exists for the item and this supplier,\n - the location is not a special stock location,\n - and, if `LocationIds` is given, the `LocID` is contained in the comma-separated list.\n\nThe result is sorted by `ItemKey` ascending. Decimal values (`SupplPrice`, `Price`) are returned as text with a comma as decimal separator; dates are formatted as `dd.mm.yyyy`. Single and double quotes are removed from the item name.\n\n**Paging:** call again with `ItemKeyStart` set to the highest `ItemKey` of the previous batch.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKeyStart` | int | No | Only items with an `ItemKey` greater than this value are considered. Use `0` for the first batch and the highest returned `ItemKey` for the next one. |\n| `LocationIds` | varchar(max) | No | Optional comma-separated list of location IDs (`LocID`). Only rows for these locations are returned. `NULL` or empty returns all locations that are not special stock. |\n| `ItemCount` | int | No | Maximum number of candidate items read from `items` per call (batch size). |\n\n- All reads use `NOLOCK`; results may contain uncommitted data.\n- `ItemCount` limits the number of **candidate items**, not the number of result rows. Because of the per-location rows the result can contain more rows; because of the inner joins (supplier, `AddItems`, `ItemLocationSpecific`, non-special-stock location, location filter) it can contain fewer or even none, although further items exist. An empty result therefore does not necessarily mean the end of the item list; a caller should advance `ItemKeyStart` by the batch range rather than stop.\n- `Quantity` is joined via the order line data: for items without any order line `Quantity` is always `0`, even if stock exists.\n- `Quantity` is the total over all non-special-stock locations, not the quantity of the location in `LocationId` (see `LocationQuantity` for that).\n- `Tags` starts with a leading space (only the first comma is removed), and special characters such as `&` are XML-escaped by the concatenation.\n- An empty or whitespace-only `LocationIds` is treated like `NULL` (no location filter). List entries are trimmed; each entry is compared as `varchar(10)`.\n- `VATLevel`: `L` for `MwStSatz = 2`, `0` for `MwStSatz = 3`, otherwise `H`. `Typ` is always `0100`.\n- Temporary tables are dropped via `util.TempTableDrop` (not attached).\n\nDocumentation: https://pixi-api-docs.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": "Returns a batch of items with preferred supplier, prices, stock and location-specific planning data for export to the Logcontrol Dispo software.\n\nExports item master data for the Logcontrol disposition (purchase planning) software. The call works in batches of items.\n\n1. **Candidate selection:** the first `ItemCount` items with `ItemKey` greater than `ItemKeyStart` are taken from `items`, ordered by `ItemKey` ascending, together with their default supplier.\n2. **Preferred supplier:** if an `AddItems` record with `PreferredSupplier = 1` exists, its supplier replaces the default supplier of the item.\n3. **Additional data per item:**\n - item tags (tags of type `TypeId = 1`) as a comma-separated list,\n - the earliest `OrderDate` of all order lines of the item,\n - the summed bin quantity (`BinItemQTY`) over all bins in locations that are not special stock (`SpecialStock <> 1`).\n4. **Result:** one row per item **and location** from `ItemLocationSpecific`. Only rows are returned where\n - the supplier exists in `Suppliers`,\n - an `AddItems` record exists for the item and this supplier,\n - the location is not a special stock location,\n - and, if `LocationIds` is given, the `LocID` is contained in the comma-separated list.\n\nThe result is sorted by `ItemKey` ascending. Decimal values (`SupplPrice`, `Price`) are returned as text with a comma as decimal separator; dates are formatted as `dd.mm.yyyy`. Single and double quotes are removed from the item name.\n\n**Paging:** call again with `ItemKeyStart` set to the highest `ItemKey` of the previous batch.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKeyStart` | int | No | Only items with an `ItemKey` greater than this value are considered. Use `0` for the first batch and the highest returned `ItemKey` for the next one. |\n| `LocationIds` | varchar(max) | No | Optional comma-separated list of location IDs (`LocID`). Only rows for these locations are returned. `NULL` or empty returns all locations that are not special stock. |\n| `ItemCount` | int | No | Maximum number of candidate items read from `items` per call (batch size). |\n\n- All reads use `NOLOCK`; results may contain uncommitted data.\n- `ItemCount` limits the number of **candidate items**, not the number of result rows. Because of the per-location rows the result can contain more rows; because of the inner joins (supplier, `AddItems`, `ItemLocationSpecific`, non-special-stock location, location filter) it can contain fewer or even none, although further items exist. An empty result therefore does not necessarily mean the end of the item list; a caller should advance `ItemKeyStart` by the batch range rather than stop.\n- `Quantity` is joined via the order line data: for items without any order line `Quantity` is always `0`, even if stock exists.\n- `Quantity` is the total over all non-special-stock locations, not the quantity of the location in `LocationId` (see `LocationQuantity` for that).\n- `Tags` starts with a leading space (only the first comma is removed), and special characters such as `&` are XML-escaped by the concatenation.\n- An empty or whitespace-only `LocationIds` is treated like `NULL` (no location filter). List entries are trimmed; each entry is compared as `varchar(10)`.\n- `VATLevel`: `L` for `MwStSatz = 2`, `0` for `MwStSatz = 3`, otherwise `H`. `Typ` is always `0100`.\n- Temporary tables are dropped via `util.TempTableDrop` (not attached).\n\nDocumentation: https://pixi-api-docs.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": "Returns all item categories with their ID and description, sorted by description.\n\nReturns the complete list of item categories (Artikelkategorien) from the table `TontrArten`.\n\n- The call takes no parameters and applies no filter.\n- Each row contains the category ID (`ArtCategory`) and its description (`ArtCategoryDescription`).\n- Rows are sorted alphabetically by description.\n\nThe call is part of the eMill integration (tag `Tech_eMill`).\n\nThe table is read with `NOLOCK`, so uncommitted changes may be visible. Column data types are not visible in the code and are therefore marked as `unknown`.\n\nDocumentation: https://pixi-api-docs.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": "Returns all item categories with their ID and description, sorted by description.\n\nReturns the complete list of item categories (Artikelkategorien) from the table `TontrArten`.\n\n- The call takes no parameters and applies no filter.\n- Each row contains the category ID (`ArtCategory`) and its description (`ArtCategoryDescription`).\n- Rows are sorted alphabetically by description.\n\nThe call is part of the eMill integration (tag `Tech_eMill`).\n\nThe table is read with `NOLOCK`, so uncommitted changes may be visible. Column data types are not visible in the code and are therefore marked as `unknown`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the item categories (table TontrArten), optionally filtered by key, short code or text.\n\nReads the category master data from `TontrArten` and returns key, short code and description of each category.\n\nEmpty values are normalized first: `TontrArtKey` = `0` and empty strings for `TontrShort` or `TontrText` are treated as `NULL`.\n\nOnly **one** filter is applied, chosen in this order of priority:\n\n1. If `TontrArtKey` is set, only the category with this key is returned.\n2. Otherwise, if `TontrShort` is set, categories whose short code matches exactly are returned.\n3. Otherwise, if `TontrText` is set, categories whose text matches exactly are returned.\n4. If no parameter is set, all categories are returned.\n\nThe result is always sorted by `TontrText` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TontrArtKey` | int | No | Key of the category. `0` is treated as `NULL`. Has the highest filter priority. |\n| `TontrShort` | varchar(50) | No | Short code of the category (exact match). Empty string is treated as `NULL`. Used only if `TontrArtKey` is not set. |\n| `TontrText` | varchar(50) | No | Description text of the category (exact match). Empty string is treated as `NULL`. Used only if neither `TontrArtKey` nor `TontrShort` is set. |\n\n- Filters are not combined: if several parameters are passed, only the one with the highest priority (`TontrArtKey` > `TontrShort` > `TontrText`) is used; the others are ignored.\n- Matching is exact (`=`), no wildcard or partial search.\n- The table is read `WITH (NOLOCK)`, so uncommitted changes may be visible.\n- If nothing matches, an empty result set is returned; there is no error row.\n\nDocumentation: https://pixi-api-docs.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": "Returns the item categories (table TontrArten), optionally filtered by key, short code or text.\n\nReads the category master data from `TontrArten` and returns key, short code and description of each category.\n\nEmpty values are normalized first: `TontrArtKey` = `0` and empty strings for `TontrShort` or `TontrText` are treated as `NULL`.\n\nOnly **one** filter is applied, chosen in this order of priority:\n\n1. If `TontrArtKey` is set, only the category with this key is returned.\n2. Otherwise, if `TontrShort` is set, categories whose short code matches exactly are returned.\n3. Otherwise, if `TontrText` is set, categories whose text matches exactly are returned.\n4. If no parameter is set, all categories are returned.\n\nThe result is always sorted by `TontrText` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TontrArtKey` | int | No | Key of the category. `0` is treated as `NULL`. Has the highest filter priority. |\n| `TontrShort` | varchar(50) | No | Short code of the category (exact match). Empty string is treated as `NULL`. Used only if `TontrArtKey` is not set. |\n| `TontrText` | varchar(50) | No | Description text of the category (exact match). Empty string is treated as `NULL`. Used only if neither `TontrArtKey` nor `TontrShort` is set. |\n\n- Filters are not combined: if several parameters are passed, only the one with the highest priority (`TontrArtKey` > `TontrShort` > `TontrText`) is used; the others are ignored.\n- Matching is exact (`=`), no wildcard or partial search.\n- The table is read `WITH (NOLOCK)`, so uncommitted changes may be visible.\n- If nothing matches, an empty result set is returned; there is no error row.\n\nDocumentation: https://pixi-api-docs.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": "Returns the EAN/UPC code of an item identified by its internal item number.\n\nScalar function that looks up the item in `Items` whose `ItemNrInt` equals `ItemNrInt` and returns its `EANUPC` value.\n\n- If no item matches, the result is `NULL`.\n- If `EANUPC` is empty or `NULL` for the item, that value is returned as is.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | Yes | Internal item number (`ItemNrInt`) of the item whose EAN is requested. |\n\n- The table is read with `NOLOCK`, so uncommitted changes may be returned.\n- The return type is `varchar(13)`; longer values in `EANUPC` would be truncated to 13 characters.\n- If several rows had the same `ItemNrInt`, the value of one of them would be returned without defined order.\n\nDocumentation: https://pixi-api-docs.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": "Returns the EAN/UPC code of an item identified by its internal item number.\n\nScalar function that looks up the item in `Items` whose `ItemNrInt` equals `ItemNrInt` and returns its `EANUPC` value.\n\n- If no item matches, the result is `NULL`.\n- If `EANUPC` is empty or `NULL` for the item, that value is returned as is.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | Yes | Internal item number (`ItemNrInt`) of the item whose EAN is requested. |\n\n- The table is read with `NOLOCK`, so uncommitted changes may be returned.\n- The return type is `varchar(13)`; longer values in `EANUPC` would be truncated to 13 characters.\n- If several rows had the same `ItemNrInt`, the value of one of them would be returned without defined order.\n\nDocumentation: https://pixi-api-docs.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": "Returns the history of purchase (EK) and sales prices from the item history, optionally filtered by item number and date range, with paging.\n\nReads price history records from `ItemsHist` and returns them page by page.\n\n**Filters**\n- `ItemNrInternal`: if not empty, only history rows whose internal item number (`ItemNrInt`) equals this value are returned. Empty or `NULL` returns all items.\n- `FromDate` / `ToDate`: filter on `UpdateDate` (inclusive on both ends).\n - both set: `UpdateDate` between `FromDate` and `ToDate`\n - only `FromDate`: `UpdateDate` >= `FromDate`\n - only `ToDate`: `UpdateDate` <= `ToDate`\n - none: no date filter\n\n**Sort order and paging**\n- Rows are numbered with `RowNumber` (starting at 1) ordered by `UpdateDate`, then item key, then purchase price, all ascending (oldest change first).\n- Only rows with `RowNumber` between `StartRow` and `StartRow + RowCount` (both inclusive) are returned, sorted by `RowNumber`.\n- `RowCount = 0` is treated as 100.\n\nFor each history row the current supplier number (`SupplNr`) is joined from the item master `Items`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemNrInternal` | varchar(250) | No | Internal item number to filter on (`ItemNrInt`). Empty or `NULL` returns the history of all items. |\n| `FromDate` | datetime | No | Lower bound (inclusive) for `UpdateDate`. Empty, `NULL` or `1900-01-01` means no lower bound. |\n| `ToDate` | datetime | No | Upper bound (inclusive, including time) for `UpdateDate`. Empty, `NULL` or `1900-01-01` means no upper bound. |\n| `RowCount` | int | No | Page size offset. Rows from `StartRow` to `StartRow + RowCount` are returned. `0` is treated as 100. |\n| `StartRow` | int | No | First `RowNumber` of the page (inclusive). Row numbering starts at 1. |\n\n- **Paging overlap:** the page range is inclusive on both ends. With `StartRow = 0` and `RowCount = 100` rows 1–100 are returned; with `StartRow = 100` rows 100–200 (101 rows) are returned, so consecutive pages share one row unless `StartRow` is advanced by `RowCount + 1`.\n- A code comment mentions a fallback of 1000 rows, but the code actually uses 100 when `RowCount` is 0.\n- The empty-string default of the datetime parameters is converted to `1900-01-01`; passing exactly that date is treated as \"no filter\".\n- `ToDate` is compared including the time part. A date without time (e.g. `2024-06-30T00:00:00`) excludes changes later that day.\n- History rows with `NULL` in `UpdateDate` or `ItemNrInt` are never returned, because the filter conditions are always evaluated.\n- `SupplNr` is the supplier currently stored in `Items`, not the supplier at the time of the change; it is `NULL` if the item no longer exists.\n- No `NOLOCK` hints are used. Without an item filter the numbering runs over the whole history table, which can be slow on large data sets.\n\nDocumentation: https://pixi-api-docs.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": "Returns the history of purchase (EK) and sales prices from the item history, optionally filtered by item number and date range, with paging.\n\nReads price history records from `ItemsHist` and returns them page by page.\n\n**Filters**\n- `ItemNrInternal`: if not empty, only history rows whose internal item number (`ItemNrInt`) equals this value are returned. Empty or `NULL` returns all items.\n- `FromDate` / `ToDate`: filter on `UpdateDate` (inclusive on both ends).\n - both set: `UpdateDate` between `FromDate` and `ToDate`\n - only `FromDate`: `UpdateDate` >= `FromDate`\n - only `ToDate`: `UpdateDate` <= `ToDate`\n - none: no date filter\n\n**Sort order and paging**\n- Rows are numbered with `RowNumber` (starting at 1) ordered by `UpdateDate`, then item key, then purchase price, all ascending (oldest change first).\n- Only rows with `RowNumber` between `StartRow` and `StartRow + RowCount` (both inclusive) are returned, sorted by `RowNumber`.\n- `RowCount = 0` is treated as 100.\n\nFor each history row the current supplier number (`SupplNr`) is joined from the item master `Items`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemNrInternal` | varchar(250) | No | Internal item number to filter on (`ItemNrInt`). Empty or `NULL` returns the history of all items. |\n| `FromDate` | datetime | No | Lower bound (inclusive) for `UpdateDate`. Empty, `NULL` or `1900-01-01` means no lower bound. |\n| `ToDate` | datetime | No | Upper bound (inclusive, including time) for `UpdateDate`. Empty, `NULL` or `1900-01-01` means no upper bound. |\n| `RowCount` | int | No | Page size offset. Rows from `StartRow` to `StartRow + RowCount` are returned. `0` is treated as 100. |\n| `StartRow` | int | No | First `RowNumber` of the page (inclusive). Row numbering starts at 1. |\n\n- **Paging overlap:** the page range is inclusive on both ends. With `StartRow = 0` and `RowCount = 100` rows 1–100 are returned; with `StartRow = 100` rows 100–200 (101 rows) are returned, so consecutive pages share one row unless `StartRow` is advanced by `RowCount + 1`.\n- A code comment mentions a fallback of 1000 rows, but the code actually uses 100 when `RowCount` is 0.\n- The empty-string default of the datetime parameters is converted to `1900-01-01`; passing exactly that date is treated as \"no filter\".\n- `ToDate` is compared including the time part. A date without time (e.g. `2024-06-30T00:00:00`) excludes changes later that day.\n- History rows with `NULL` in `UpdateDate` or `ItemNrInt` are never returned, because the filter conditions are always evaluated.\n- `SupplNr` is the supplier currently stored in `Items`, not the supplier at the time of the change; it is `NULL` if the item no longer exists.\n- No `NOLOCK` hints are used. Without an item filter the numbering runs over the whole history table, which can be slow on large data sets.\n\nDocumentation: https://pixi-api-docs.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": "Returns the component items and quantities of a bundle item, identified by item key, internal item number, EAN/UPC or supplier item number.\n\nLooks up the bundle definition stored in `BundleItems` for a bundle item and returns one row per component item. Master data for each component comes from `Items`.\n\nOnly one identifier is used. They are checked in this order of priority:\n\n1. `ItemKey`, if it is greater than 0.\n2. `ItemNrInt`, if it is not empty. The first item with this internal item number is used (`TOP 1` without a sort order).\n3. `EANUPC`, if it is not empty. The first item with this EAN/UPC is used (`TOP 1` without a sort order).\n4. `ItemNrSuppl`, if it is not empty. **All** items with this supplier item number are used. The components of all matching bundles are returned together in one result.\n\nThe other parameters are ignored as soon as one with higher priority is set.\n\nThe call returns no rows in these cases:\n\n- no identifier is given\n- the identifier does not match any item\n- the item is not a bundle\n\nIn all cases the result set has the same columns. No sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the bundle item. Has the highest priority if greater than 0. |\n| `ItemNrInt` | varchar(50) | No | Internal item number of the bundle item. Used only if `ItemKey` is not set. |\n| `EANUPC` | varchar(13) | No | EAN/UPC of the bundle item. Used only if `ItemKey` and `ItemNrInt` are not set. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number of the bundle item. Used only if no other identifier is set. All items with this number are taken into account. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- If several items share the same `ItemNrInt` or `EANUPC`, the item that is used is not deterministic.\n- With `ItemNrSuppl` the components of different bundles cannot be told apart, because the result has no column for the parent bundle item.\n- The component item data is joined with `LEFT JOIN`. If a component item no longer exists in `Items`, its item columns are empty (NULL), while `BundleItemKey` and `Qty` are still filled.\n\nDocumentation: https://pixi-api-docs.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": "Returns the component items and quantities of a bundle item, identified by item key, internal item number, EAN/UPC or supplier item number.\n\nLooks up the bundle definition stored in `BundleItems` for a bundle item and returns one row per component item. Master data for each component comes from `Items`.\n\nOnly one identifier is used. They are checked in this order of priority:\n\n1. `ItemKey`, if it is greater than 0.\n2. `ItemNrInt`, if it is not empty. The first item with this internal item number is used (`TOP 1` without a sort order).\n3. `EANUPC`, if it is not empty. The first item with this EAN/UPC is used (`TOP 1` without a sort order).\n4. `ItemNrSuppl`, if it is not empty. **All** items with this supplier item number are used. The components of all matching bundles are returned together in one result.\n\nThe other parameters are ignored as soon as one with higher priority is set.\n\nThe call returns no rows in these cases:\n\n- no identifier is given\n- the identifier does not match any item\n- the item is not a bundle\n\nIn all cases the result set has the same columns. No sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the bundle item. Has the highest priority if greater than 0. |\n| `ItemNrInt` | varchar(50) | No | Internal item number of the bundle item. Used only if `ItemKey` is not set. |\n| `EANUPC` | varchar(13) | No | EAN/UPC of the bundle item. Used only if `ItemKey` and `ItemNrInt` are not set. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number of the bundle item. Used only if no other identifier is set. All items with this number are taken into account. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- If several items share the same `ItemNrInt` or `EANUPC`, the item that is used is not deterministic.\n- With `ItemNrSuppl` the components of different bundles cannot be told apart, because the result has no column for the parent bundle item.\n- The component item data is joined with `LEFT JOIN`. If a component item no longer exists in `Items`, its item columns are empty (NULL), while `BundleItemKey` and `Qty` are still filled.\n\nDocumentation: https://pixi-api-docs.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": "Returns master data, stock, supplier, VAT, tag and customs information for one or more items found by item key, EAN, item numbers or an XML list.\n\nLooks up items and returns one row per matching item with its master data.\n\n**Input normalisation**\n- `ItemKey` = 0 and empty strings are treated as `NULL`.\n- If none of `ItemKey`, `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `ItemXML` or `InternalItemNumber` is set, a single error row is returned instead of item data. `LocID` alone is not enough.\n\n**Search criteria**\n\nThe scalar parameters and every `/ITEMS/ITEM` entry of `ItemXML` form a list of search criteria. Each criterion is matched against `pixi.ItemCode`:\n- `ItemKey` / `ITEMKEY`: item id\n- `EANUPC` / `EAN`: code type 1 (EAN)\n- `ItemNrInt` / `ITEMNRINT`: code type 2 (internal item number)\n- `InternalItemNumber` / `INTERNALITEMNUMBER`: code type 3\n- `ItemNrSuppl` / `ITEMNRSUPPL`: code type 4 (supplier item number)\n\nAll matches are combined with **OR** semantics (union): an item is returned if it matches any of the given values. Duplicate matches are removed.\n\n**Output values**\n- `LocID` selects location-specific values from `ItemLocationSpecific`: `MinStockQty`, `Quantity`, `SafetyStock`, `TargetStock`. Without a location (or without a location record) the global item values are used and `SafetyStock`/`TargetStock` are 0.\n- `ConsiderFavouriteSupplier` = 1 uses the active preferred supplier (`AddItems.PreferredSupplier` = 1, supplier not disabled) for `SupplPrice`, `SupplNr`, `ItemNrSuppl`, `EANUPC` and `MinOrderQty`. With the default 0, the item's own values and the `AddItems` record of the item's main supplier are used.\n- `VATLevel` is derived from the VAT rate: 2 = `MwSt_Low`, 3 = `MwSt_Null`, any other value = `MwSt_High`.\n- `ItemTAGs` lists all tags of the item separated by `|`. `ABC` contains only the system tags `A`, `B` or `C`.\n\nThe rows are returned without a defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Item key (item id) to look up. 0 is treated as not set. |\n| `ItemNrInt` | varchar(50) | No | Internal item number (code type 2 in `pixi.ItemCode`). |\n| `EANUPC` | varchar(13) | No | EAN/UPC code (code type 1 in `pixi.ItemCode`). |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number (code type 4 in `pixi.ItemCode`). |\n| `LocID` | varchar(3) | No | Location (warehouse) ID for location-specific stock values (`MinStockQty`, `Quantity`, `SafetyStock`, `TargetStock`). Does not act as a search criterion. |\n| `ItemXML` | varchar(max) | No | XML list of items to look up: one `ITEM` element per criterion set below `ITEMS`, with optional child elements `ITEMKEY`, `ITEMNRSUPPL`, `ITEMNRINT`, `EAN`, `INTERNALITEMNUMBER`. |\n| `InternalItemNumber` | varchar(50) | No | Additional internal item number (code type 3 in `pixi.ItemCode`). |\n| `ConsiderFavouriteSupplier` | bit | No | If 1, supplier values are taken from the active preferred supplier. Marked as \"not used anymore\" in a code comment, but still evaluated. |\n\n- All tables are read `WITH (NOLOCK)`; results may contain uncommitted data.\n- The code comment marks `ConsiderFavouriteSupplier` as \"not used anymore\", but the code still evaluates it: with 1 the preferred-supplier values are used and `MinOrderQty` becomes 0 if no active preferred supplier exists.\n- Lookup by `ItemKey` also goes through `pixi.ItemCode`. An item without any entry in `pixi.ItemCode` is not found, even with a valid key.\n- Combining several parameters widens the result (OR), it does not narrow it.\n- In `ItemXML` the EAN element is named `EAN`, not `EANUPC`. Tabs are removed from `ITEMKEY`. A non-numeric `ITEMKEY` or malformed XML raises a SQL error.\n- `EANUPC` is limited to 13 characters.\n- Because of the outer joins (e.g. several code-type-3 entries or several active preferred suppliers), an item can appear more than once in the result.\n- No data is changed; only temporary tables are used.\n\nDocumentation: https://pixi-api-docs.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": "Returns master data, stock, supplier, VAT, tag and customs information for one or more items found by item key, EAN, item numbers or an XML list.\n\nLooks up items and returns one row per matching item with its master data.\n\n**Input normalisation**\n- `ItemKey` = 0 and empty strings are treated as `NULL`.\n- If none of `ItemKey`, `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `ItemXML` or `InternalItemNumber` is set, a single error row is returned instead of item data. `LocID` alone is not enough.\n\n**Search criteria**\n\nThe scalar parameters and every `/ITEMS/ITEM` entry of `ItemXML` form a list of search criteria. Each criterion is matched against `pixi.ItemCode`:\n- `ItemKey` / `ITEMKEY`: item id\n- `EANUPC` / `EAN`: code type 1 (EAN)\n- `ItemNrInt` / `ITEMNRINT`: code type 2 (internal item number)\n- `InternalItemNumber` / `INTERNALITEMNUMBER`: code type 3\n- `ItemNrSuppl` / `ITEMNRSUPPL`: code type 4 (supplier item number)\n\nAll matches are combined with **OR** semantics (union): an item is returned if it matches any of the given values. Duplicate matches are removed.\n\n**Output values**\n- `LocID` selects location-specific values from `ItemLocationSpecific`: `MinStockQty`, `Quantity`, `SafetyStock`, `TargetStock`. Without a location (or without a location record) the global item values are used and `SafetyStock`/`TargetStock` are 0.\n- `ConsiderFavouriteSupplier` = 1 uses the active preferred supplier (`AddItems.PreferredSupplier` = 1, supplier not disabled) for `SupplPrice`, `SupplNr`, `ItemNrSuppl`, `EANUPC` and `MinOrderQty`. With the default 0, the item's own values and the `AddItems` record of the item's main supplier are used.\n- `VATLevel` is derived from the VAT rate: 2 = `MwSt_Low`, 3 = `MwSt_Null`, any other value = `MwSt_High`.\n- `ItemTAGs` lists all tags of the item separated by `|`. `ABC` contains only the system tags `A`, `B` or `C`.\n\nThe rows are returned without a defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Item key (item id) to look up. 0 is treated as not set. |\n| `ItemNrInt` | varchar(50) | No | Internal item number (code type 2 in `pixi.ItemCode`). |\n| `EANUPC` | varchar(13) | No | EAN/UPC code (code type 1 in `pixi.ItemCode`). |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number (code type 4 in `pixi.ItemCode`). |\n| `LocID` | varchar(3) | No | Location (warehouse) ID for location-specific stock values (`MinStockQty`, `Quantity`, `SafetyStock`, `TargetStock`). Does not act as a search criterion. |\n| `ItemXML` | varchar(max) | No | XML list of items to look up: one `ITEM` element per criterion set below `ITEMS`, with optional child elements `ITEMKEY`, `ITEMNRSUPPL`, `ITEMNRINT`, `EAN`, `INTERNALITEMNUMBER`. |\n| `InternalItemNumber` | varchar(50) | No | Additional internal item number (code type 3 in `pixi.ItemCode`). |\n| `ConsiderFavouriteSupplier` | bit | No | If 1, supplier values are taken from the active preferred supplier. Marked as \"not used anymore\" in a code comment, but still evaluated. |\n\n- All tables are read `WITH (NOLOCK)`; results may contain uncommitted data.\n- The code comment marks `ConsiderFavouriteSupplier` as \"not used anymore\", but the code still evaluates it: with 1 the preferred-supplier values are used and `MinOrderQty` becomes 0 if no active preferred supplier exists.\n- Lookup by `ItemKey` also goes through `pixi.ItemCode`. An item without any entry in `pixi.ItemCode` is not found, even with a valid key.\n- Combining several parameters widens the result (OR), it does not narrow it.\n- In `ItemXML` the EAN element is named `EAN`, not `EANUPC`. Tabs are removed from `ITEMKEY`. A non-numeric `ITEMKEY` or malformed XML raises a SQL error.\n- `EANUPC` is limited to 13 characters.\n- Because of the outer joins (e.g. several code-type-3 entries or several active preferred suppliers), an item can appear more than once in the result.\n- No data is changed; only temporary tables are used.\n\nDocumentation: https://pixi-api-docs.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": "Returns master data, prices, stock, tags and supplier information for one or more items found by item key, EAN, item numbers or an XML list.\n\nLooks up items and returns one row per found item with master data, prices, stock and tags.\n\n**Input normalisation**\n- `ItemKey` = 0 and empty strings in `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `ItemXML` and `InternalItemNumber` are treated as not given. An empty `LocID` is treated as NULL.\n- If none of `ItemKey`, `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `ItemXML` or `InternalItemNumber` is given, the call returns a single error row (`Error`, `ErrorMsg`). `LocID` alone is not enough.\n\n**Item search**\n- The single parameters and every `/ITEMS/ITEM` element of `ItemXML` form a list of search criteria. Spaces are removed from `ITEMKEY` in the XML.\n- Items are searched in the item code table and all hits are combined (logical OR, duplicates removed):\n - `ItemKey` matches the item ID,\n - `EANUPC` / `EAN` matches a code of type 1 (EAN),\n - `ItemNrInt` matches a code of type 2,\n - `InternalItemNumber` matches a code of type 3,\n - `ItemNrSuppl` matches a code of type 4.\n\n**Output**\n- One row per found item, sorted by `ItemKey`.\n- If `LocID` is given, `MinStockQty`, `Quantity`, `SafetyStock` and `TargetStock` come from the location-specific item data of that location; otherwise (or if there is no such data) `MinStockQty` and `Quantity` come from the item master and `SafetyStock`/`TargetStock` are 0.\n- With `ConsiderFavouriteSupplier` = 1, price, supplier number, supplier item number, EAN and minimum order quantity are taken from the active preferred supplier entry (supplier not disabled), falling back to the item master. With 0 (default), `MinOrderQty` and `EANUPC` come from the supplier entry of the item's main supplier, falling back to the item master.\n- `VATLevel` maps the VAT rate code 1/2/3 to `MwSt_High`/`MwSt_Low`/`MwSt_Null`.\n- `ItemTAGs` lists all tags of the item separated by `|`; `ABC` contains the system tag `A`, `B` or `C` of the item.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal item key. 0 is treated as not given. |\n| `ItemNrInt` | varchar(50) | No | Internal item number (item code type 2). Empty string is treated as not given. |\n| `EANUPC` | varchar(13) | No | EAN/UPC of the item (item code type 1). Empty string is treated as not given. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number (item code type 4). Empty string is treated as not given. |\n| `LocID` | varchar(3) | No | Location (warehouse) ID. If given, stock quantity, minimum stock, safety stock and target stock are taken from the location-specific item data. Not a search criterion. |\n| `ItemXML` | varchar(max) | No | XML list of items to look up. Each `/ITEMS/ITEM` element may contain `ITEMKEY`, `ITEMNRSUPPL`, `ITEMNRINT`, `EAN` and `INTERNALITEMNUMBER`. Combined with the single parameters. |\n| `InternalItemNumber` | varchar(50) | No | Internal item number (item code type 3). Empty string is treated as not given. |\n| `ConsiderFavouriteSupplier` | bit | No | If 1, supplier price, supplier number, supplier item number, EAN and minimum order quantity are taken from the active preferred supplier. Commented as no longer used, but still evaluated by the code. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- The search runs entirely over the item code table: an item is only found by `ItemKey` if it has at least one item code entry.\n- Although `ConsiderFavouriteSupplier` is commented as \"Not used anymore\", the code still evaluates it. With value 1 and no active preferred supplier, `MinOrderQty` is 0.\n- The output joins can produce more than one row per item, e.g. if an item has several internal item numbers (code type 3), several supplier entries for the main supplier, several preferred suppliers or several of the system tags `A`/`B`/`C`.\n- `ITEMKEY` values in the XML are converted to `int`; a non-numeric value causes a SQL conversion error. An invalid XML document also causes a SQL error.\n- `ItemTAGs` is read from the tag assignment table `TagMatch`, while `ABC` is read from `ItemTagMatching`; `ItemTAGs` is NULL if the item has no tags.\n- `VATLevel` is NULL for VAT rate codes other than 1, 2 and 3.\n\nDocumentation: https://pixi-api-docs.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": "Returns master data, prices, stock, tags and supplier information for one or more items found by item key, EAN, item numbers or an XML list.\n\nLooks up items and returns one row per found item with master data, prices, stock and tags.\n\n**Input normalisation**\n- `ItemKey` = 0 and empty strings in `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `ItemXML` and `InternalItemNumber` are treated as not given. An empty `LocID` is treated as NULL.\n- If none of `ItemKey`, `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `ItemXML` or `InternalItemNumber` is given, the call returns a single error row (`Error`, `ErrorMsg`). `LocID` alone is not enough.\n\n**Item search**\n- The single parameters and every `/ITEMS/ITEM` element of `ItemXML` form a list of search criteria. Spaces are removed from `ITEMKEY` in the XML.\n- Items are searched in the item code table and all hits are combined (logical OR, duplicates removed):\n - `ItemKey` matches the item ID,\n - `EANUPC` / `EAN` matches a code of type 1 (EAN),\n - `ItemNrInt` matches a code of type 2,\n - `InternalItemNumber` matches a code of type 3,\n - `ItemNrSuppl` matches a code of type 4.\n\n**Output**\n- One row per found item, sorted by `ItemKey`.\n- If `LocID` is given, `MinStockQty`, `Quantity`, `SafetyStock` and `TargetStock` come from the location-specific item data of that location; otherwise (or if there is no such data) `MinStockQty` and `Quantity` come from the item master and `SafetyStock`/`TargetStock` are 0.\n- With `ConsiderFavouriteSupplier` = 1, price, supplier number, supplier item number, EAN and minimum order quantity are taken from the active preferred supplier entry (supplier not disabled), falling back to the item master. With 0 (default), `MinOrderQty` and `EANUPC` come from the supplier entry of the item's main supplier, falling back to the item master.\n- `VATLevel` maps the VAT rate code 1/2/3 to `MwSt_High`/`MwSt_Low`/`MwSt_Null`.\n- `ItemTAGs` lists all tags of the item separated by `|`; `ABC` contains the system tag `A`, `B` or `C` of the item.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal item key. 0 is treated as not given. |\n| `ItemNrInt` | varchar(50) | No | Internal item number (item code type 2). Empty string is treated as not given. |\n| `EANUPC` | varchar(13) | No | EAN/UPC of the item (item code type 1). Empty string is treated as not given. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number (item code type 4). Empty string is treated as not given. |\n| `LocID` | varchar(3) | No | Location (warehouse) ID. If given, stock quantity, minimum stock, safety stock and target stock are taken from the location-specific item data. Not a search criterion. |\n| `ItemXML` | varchar(max) | No | XML list of items to look up. Each `/ITEMS/ITEM` element may contain `ITEMKEY`, `ITEMNRSUPPL`, `ITEMNRINT`, `EAN` and `INTERNALITEMNUMBER`. Combined with the single parameters. |\n| `InternalItemNumber` | varchar(50) | No | Internal item number (item code type 3). Empty string is treated as not given. |\n| `ConsiderFavouriteSupplier` | bit | No | If 1, supplier price, supplier number, supplier item number, EAN and minimum order quantity are taken from the active preferred supplier. Commented as no longer used, but still evaluated by the code. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- The search runs entirely over the item code table: an item is only found by `ItemKey` if it has at least one item code entry.\n- Although `ConsiderFavouriteSupplier` is commented as \"Not used anymore\", the code still evaluates it. With value 1 and no active preferred supplier, `MinOrderQty` is 0.\n- The output joins can produce more than one row per item, e.g. if an item has several internal item numbers (code type 3), several supplier entries for the main supplier, several preferred suppliers or several of the system tags `A`/`B`/`C`.\n- `ITEMKEY` values in the XML are converted to `int`; a non-numeric value causes a SQL conversion error. An invalid XML document also causes a SQL error.\n- `ItemTAGs` is read from the tag assignment table `TagMatch`, while `ABC` is read from `ItemTagMatching`; `ItemTAGs` is NULL if the item has no tags.\n- `VATLevel` is NULL for VAT rate codes other than 1, 2 and 3.\n\nDocumentation: https://pixi-api-docs.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": "Returns item master data for one or more items at a location, plus the open pick list lines and packed box quantities for these items and a combined status code.\n\nLooks up one or more items and returns their master data together with information about pick lists and boxes in which they currently appear.\n\n**Validation**\n- If `ItemKey`, `EANUPC`, `ItemNrSuppl`, `ItemNrInt` and `ItemXML` are all empty, the call returns a row with `Status` = `0` and a message, followed by the final status row `0000`. `LocID` alone is not enough. `ItemKey` = `0` also counts as empty.\n\n**Item lookup**\n- A single item is resolved from `COALESCE(EANUPC, ItemNrInt, ItemNrSuppl)` against the scannable item codes (`pixi.ItemCode` with a code type where `Scannable` = 1). The first matching item is used. If `ItemKey` is passed, it takes precedence over the code lookup.\n- In addition, `ItemXML` can list several items (`/ITEMS/ITEM` with child elements `ITEMNRINT`, `ITEMNRSUPPL`, `ITEMKEY`, `EAN`). Each entry matches items whose internal number, EAN, item key **or** supplier number equals one of the given values. These items are added to the single item from the parameters.\n\n**Result sets on success** (in this order)\n1. Item data from `items`, joined with the location-specific values from `ItemLocationSpecific` for `LocID` (stock, minimum stock, minimum order quantity), category name, VAT level, tags, ABC class, estimated delivery and picture links.\n2. Pick list lines: for each item and pick list, the number of non-expired pick list items whose order line is not in status `AUS`, `NLB`, `RET`, `STO` or `EIN`. Filtered by the order line location if `LocID` is set.\n3. Box items: for each item, box and used pick list number, the summed quantity in boxes for order lines with status `EIN`. Filtered by the order line location if `LocID` is set.\n4. A status row with a four-digit code: access / item found / on pick list / in box. Possible values are `0000` (no parameter), `1000` (no item data found), `1100`, `1101`, `1110` and `1111`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal item key. Takes precedence over the code lookup. `0` is treated as empty. |\n| `ItemNrInt` | varchar(50) | No | Internal item number; used for the scannable code lookup if `EANUPC` is NULL. |\n| `EANUPC` | varchar(13) | No | EAN/UPC code; first value used for the scannable code lookup. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number; used for the code lookup if `EANUPC` and `ItemNrInt` are NULL. |\n| `LocID` | varchar(3) | No | Location (warehouse) ID. Needed for the item data result set (location-specific values); filters pick list and box data by order line location if set. |\n| `ItemXML` | varchar(max) | No | Optional list of additional items as XML (`/ITEMS/ITEM`, element-centric). Each entry may contain `ITEMNRINT`, `ITEMNRSUPPL`, `ITEMKEY` and `EAN`; any matching value selects the item. |\n\n- The item data result set uses an INNER JOIN on `ItemLocationSpecific` with `LocID = @LocID`. If `LocID` is not passed (NULL), **no item rows** are returned and the status becomes `1000`, although the pick list and box result sets are still filled for all locations.\n- The lookup uses `COALESCE`, so an empty string in `EANUPC` (instead of omitting it) prevents the lookup by `ItemNrInt` or `ItemNrSuppl`.\n- The XML matching uses OR conditions; one `ITEM` entry can match several different items.\n- If the same item is listed several times (e.g. via parameter and XML), the pick list and box result sets can contain duplicate rows; the item data set does not.\n- `Sum_PickListItem`, `Sum_BoxItem`, `PickListNr` and `BoxNr` are wrapped in `ISNULL(..., '')`; for numeric columns an empty value becomes `0`.\n- All reads use `NOLOCK`, so uncommitted data may be returned. Pick list and box aggregates are computed for all items before they are filtered, which can be slow on large databases.\n- Invalid XML in `ItemXML` raises a SQL error from `sp_xml_preparedocument`.\n\nDocumentation: https://pixi-api-docs.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": "Returns item master data for one or more items at a location, plus the open pick list lines and packed box quantities for these items and a combined status code.\n\nLooks up one or more items and returns their master data together with information about pick lists and boxes in which they currently appear.\n\n**Validation**\n- If `ItemKey`, `EANUPC`, `ItemNrSuppl`, `ItemNrInt` and `ItemXML` are all empty, the call returns a row with `Status` = `0` and a message, followed by the final status row `0000`. `LocID` alone is not enough. `ItemKey` = `0` also counts as empty.\n\n**Item lookup**\n- A single item is resolved from `COALESCE(EANUPC, ItemNrInt, ItemNrSuppl)` against the scannable item codes (`pixi.ItemCode` with a code type where `Scannable` = 1). The first matching item is used. If `ItemKey` is passed, it takes precedence over the code lookup.\n- In addition, `ItemXML` can list several items (`/ITEMS/ITEM` with child elements `ITEMNRINT`, `ITEMNRSUPPL`, `ITEMKEY`, `EAN`). Each entry matches items whose internal number, EAN, item key **or** supplier number equals one of the given values. These items are added to the single item from the parameters.\n\n**Result sets on success** (in this order)\n1. Item data from `items`, joined with the location-specific values from `ItemLocationSpecific` for `LocID` (stock, minimum stock, minimum order quantity), category name, VAT level, tags, ABC class, estimated delivery and picture links.\n2. Pick list lines: for each item and pick list, the number of non-expired pick list items whose order line is not in status `AUS`, `NLB`, `RET`, `STO` or `EIN`. Filtered by the order line location if `LocID` is set.\n3. Box items: for each item, box and used pick list number, the summed quantity in boxes for order lines with status `EIN`. Filtered by the order line location if `LocID` is set.\n4. A status row with a four-digit code: access / item found / on pick list / in box. Possible values are `0000` (no parameter), `1000` (no item data found), `1100`, `1101`, `1110` and `1111`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal item key. Takes precedence over the code lookup. `0` is treated as empty. |\n| `ItemNrInt` | varchar(50) | No | Internal item number; used for the scannable code lookup if `EANUPC` is NULL. |\n| `EANUPC` | varchar(13) | No | EAN/UPC code; first value used for the scannable code lookup. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number; used for the code lookup if `EANUPC` and `ItemNrInt` are NULL. |\n| `LocID` | varchar(3) | No | Location (warehouse) ID. Needed for the item data result set (location-specific values); filters pick list and box data by order line location if set. |\n| `ItemXML` | varchar(max) | No | Optional list of additional items as XML (`/ITEMS/ITEM`, element-centric). Each entry may contain `ITEMNRINT`, `ITEMNRSUPPL`, `ITEMKEY` and `EAN`; any matching value selects the item. |\n\n- The item data result set uses an INNER JOIN on `ItemLocationSpecific` with `LocID = @LocID`. If `LocID` is not passed (NULL), **no item rows** are returned and the status becomes `1000`, although the pick list and box result sets are still filled for all locations.\n- The lookup uses `COALESCE`, so an empty string in `EANUPC` (instead of omitting it) prevents the lookup by `ItemNrInt` or `ItemNrSuppl`.\n- The XML matching uses OR conditions; one `ITEM` entry can match several different items.\n- If the same item is listed several times (e.g. via parameter and XML), the pick list and box result sets can contain duplicate rows; the item data set does not.\n- `Sum_PickListItem`, `Sum_BoxItem`, `PickListNr` and `BoxNr` are wrapped in `ISNULL(..., '')`; for numeric columns an empty value becomes `0`.\n- All reads use `NOLOCK`, so uncommitted data may be returned. Pick list and box aggregates are computed for all items before they are filtered, which can be slow on large databases.\n- Invalid XML in `ItemXML` raises a SQL error from `sp_xml_preparedocument`.\n\nDocumentation: https://pixi-api-docs.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": "Returns active, non-bundle items with packaging unit (VPE) and tags for a fulfillment provider, paged by item key.\n\nReturns master data of items for an external fulfillment provider.\n\n**Filter**\n- Only items with `Enabled = 1` (active items).\n- Only items with `IsBundle = 0`. Bundle items themselves are not returned.\n- Only items with `ItemKey` greater than `StartKey`.\n\n**Paging**\n- The result is sorted by `ItemKey` ascending and limited to `RowCount` rows.\n- To read the next page, pass the highest `ItemKey` of the previous page as `StartKey`. Stop when fewer than `RowCount` rows are returned.\n\n**VPE (packaging unit)**\n- An item gets its `OrderUnit` (or 1 if `OrderUnit` is NULL) as `VPE` if it is the only component of at least one bundle and the bundle quantity of that component equals the item's `OrderUnit` (cast to integer). Such bundles represent a packaging unit of the item.\n- All other items get `VPE = 1`.\n\n**Tags**\n- `Tags` contains the names of all tags assigned to the item, sorted alphabetically and separated by `|`. Empty string if the item has no tags.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartKey` | int | No | Only items with an `ItemKey` greater than this value are returned. Use 0 for the first page, then the last `ItemKey` of the previous page. |\n| `RowCount` | int | No | Maximum number of rows returned per call. |\n\n- All tables are read with `NOLOCK`; results may contain uncommitted data.\n- `OrderUnit` is cast to `INT` for the comparison with the bundle quantity; fractional order units are truncated in that check.\n- The tag string is built per row by the scalar function `fpixi_GetItemTAGsAsString` and is limited to 8000 characters; large `RowCount` values can be slow.\n- The exact data types of `ItemName` and `OrderUnit` are defined in the `items` table and are not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns active, non-bundle items with packaging unit (VPE) and tags for a fulfillment provider, paged by item key.\n\nReturns master data of items for an external fulfillment provider.\n\n**Filter**\n- Only items with `Enabled = 1` (active items).\n- Only items with `IsBundle = 0`. Bundle items themselves are not returned.\n- Only items with `ItemKey` greater than `StartKey`.\n\n**Paging**\n- The result is sorted by `ItemKey` ascending and limited to `RowCount` rows.\n- To read the next page, pass the highest `ItemKey` of the previous page as `StartKey`. Stop when fewer than `RowCount` rows are returned.\n\n**VPE (packaging unit)**\n- An item gets its `OrderUnit` (or 1 if `OrderUnit` is NULL) as `VPE` if it is the only component of at least one bundle and the bundle quantity of that component equals the item's `OrderUnit` (cast to integer). Such bundles represent a packaging unit of the item.\n- All other items get `VPE = 1`.\n\n**Tags**\n- `Tags` contains the names of all tags assigned to the item, sorted alphabetically and separated by `|`. Empty string if the item has no tags.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartKey` | int | No | Only items with an `ItemKey` greater than this value are returned. Use 0 for the first page, then the last `ItemKey` of the previous page. |\n| `RowCount` | int | No | Maximum number of rows returned per call. |\n\n- All tables are read with `NOLOCK`; results may contain uncommitted data.\n- `OrderUnit` is cast to `INT` for the comparison with the bundle quantity; fractional order units are truncated in that check.\n- The tag string is built per row by the scalar function `fpixi_GetItemTAGsAsString` and is limited to 8000 characters; large `RowCount` values can be slow.\n- The exact data types of `ItemName` and `OrderUnit` are defined in the `items` table and are not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns the EANs of enabled non-bundle items page by page, plus the EANs of single-item bundles that act as packaging units (VPE).\n\nProvides item EAN data for a fulfillment provider, including EANs of packaging units that are modelled as bundles.\n\n**Paging**\n\n1. Selects the first `@RowCount` items with `ItemKey` greater than `@StartKey`, ordered by `ItemKey` ascending.\n2. Only items with `Enabled = 1` and `IsBundle = 0` are included in the page.\n\n**Result rows**\n\n- For every item in the page there is one row with the item's own `EANUPC` and `VPE = 1`.\n- In addition, the call looks for *packaging-unit bundles*: bundles that have exactly one bundle line, where the line quantity equals the component item's `OrderUnit` (cast to `int`). For each such bundle whose component item is in the current page, a row is returned with:\n - `ItemKey` = the **component** item,\n - `EANUPC` = the EAN of the **bundle**,\n - `VPE` = the `OrderUnit` of the component item.\n\nThe two parts are combined with `UNION` (exact duplicates removed) and sorted by `ItemKey`.\n\n**Paging through all items**\n\nStart with `StartKey = 0` and pass the highest `ItemKey` of the last response as the next `StartKey`. Stop when a call returns no rows.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartKey` | int | No | Only items with an `ItemKey` greater than this value are returned. Use `0` for the first page and the highest `ItemKey` of the previous response for the next page. |\n| `RowCount` | int | No | Maximum number of items (enabled, non-bundle) per page. The number of returned rows can be higher because of additional packaging-unit rows. |\n\n- The same `ItemKey` can appear in several rows (own EAN plus one row per packaging-unit bundle). The number of rows can therefore exceed `@RowCount`; `@RowCount` limits the number of distinct items, not rows.\n- The bundle itself is not filtered by `Enabled`; disabled bundles that meet the packaging-unit criteria are also returned.\n- Bundles with more than one bundle line, or whose quantity does not match the component's `OrderUnit`, are ignored.\n- Reads use `NOLOCK` for most joins (dirty reads possible); the join for the item's own EAN does not use a locking hint.\n- `EANUPC` may be empty or `NULL` if no EAN is maintained.\n- The exact data type of `VPE` depends on the column type of `Items.OrderUnit`, which is not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns the EANs of enabled non-bundle items page by page, plus the EANs of single-item bundles that act as packaging units (VPE).\n\nProvides item EAN data for a fulfillment provider, including EANs of packaging units that are modelled as bundles.\n\n**Paging**\n\n1. Selects the first `@RowCount` items with `ItemKey` greater than `@StartKey`, ordered by `ItemKey` ascending.\n2. Only items with `Enabled = 1` and `IsBundle = 0` are included in the page.\n\n**Result rows**\n\n- For every item in the page there is one row with the item's own `EANUPC` and `VPE = 1`.\n- In addition, the call looks for *packaging-unit bundles*: bundles that have exactly one bundle line, where the line quantity equals the component item's `OrderUnit` (cast to `int`). For each such bundle whose component item is in the current page, a row is returned with:\n - `ItemKey` = the **component** item,\n - `EANUPC` = the EAN of the **bundle**,\n - `VPE` = the `OrderUnit` of the component item.\n\nThe two parts are combined with `UNION` (exact duplicates removed) and sorted by `ItemKey`.\n\n**Paging through all items**\n\nStart with `StartKey = 0` and pass the highest `ItemKey` of the last response as the next `StartKey`. Stop when a call returns no rows.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartKey` | int | No | Only items with an `ItemKey` greater than this value are returned. Use `0` for the first page and the highest `ItemKey` of the previous response for the next page. |\n| `RowCount` | int | No | Maximum number of items (enabled, non-bundle) per page. The number of returned rows can be higher because of additional packaging-unit rows. |\n\n- The same `ItemKey` can appear in several rows (own EAN plus one row per packaging-unit bundle). The number of rows can therefore exceed `@RowCount`; `@RowCount` limits the number of distinct items, not rows.\n- The bundle itself is not filtered by `Enabled`; disabled bundles that meet the packaging-unit criteria are also returned.\n- Bundles with more than one bundle line, or whose quantity does not match the component's `OrderUnit`, are ignored.\n- Reads use `NOLOCK` for most joins (dirty reads possible); the join for the item's own EAN does not use a locking hint.\n- `EANUPC` may be empty or `NULL` if no EAN is maintained.\n- The exact data type of `VPE` depends on the column type of `Items.OrderUnit`, which is not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns the active/inactive status (`Enabled`) of one item, identified by item key or internal item number.\n\nLooks up a single item and returns its enabled status.\n\n1. The item is resolved from table `Items`. A row matches if its `ItemKey` equals `ItemKey` (only when `ItemKey` is passed) **or** its `ItemNrInt` equals `ItemNrInt`. The first matching row (`TOP 1`, no sort order) provides the item key.\n2. The procedure then returns `ItemKey`, `ItemNrInt` and `Enabled` of that item.\n\nIf neither parameter matches an item, or both parameters are left out, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | No | Internal item number of the item. Used if `ItemKey` is not passed or does not match. |\n| `ItemKey` | int | No | Internal key of the item in table `Items`. |\n\n- Both parameters are combined with **OR**. If both are passed and refer to different items, it is not defined which item is returned (`TOP 1` without `ORDER BY`). Pass only one of them.\n- If `ItemKey` is passed but does not exist and `ItemNrInt` does not match either, the result set is simply empty; no error is returned.\n- If `ItemKey` does not exist but `ItemNrInt` matches, the item found by `ItemNrInt` is returned.\n- Reads with `NOLOCK`, so uncommitted changes may be visible.\n- The data type and meaning of the values of `Enabled` are not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns the active/inactive status (`Enabled`) of one item, identified by item key or internal item number.\n\nLooks up a single item and returns its enabled status.\n\n1. The item is resolved from table `Items`. A row matches if its `ItemKey` equals `ItemKey` (only when `ItemKey` is passed) **or** its `ItemNrInt` equals `ItemNrInt`. The first matching row (`TOP 1`, no sort order) provides the item key.\n2. The procedure then returns `ItemKey`, `ItemNrInt` and `Enabled` of that item.\n\nIf neither parameter matches an item, or both parameters are left out, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | No | Internal item number of the item. Used if `ItemKey` is not passed or does not match. |\n| `ItemKey` | int | No | Internal key of the item in table `Items`. |\n\n- Both parameters are combined with **OR**. If both are passed and refer to different items, it is not defined which item is returned (`TOP 1` without `ORDER BY`). Pass only one of them.\n- If `ItemKey` is passed but does not exist and `ItemNrInt` does not match either, the result set is simply empty; no error is returned.\n- If `ItemKey` does not exist but `ItemNrInt` matches, the item found by `ItemNrInt` is returned.\n- Reads with `NOLOCK`, so uncommitted changes may be visible.\n- The data type and meaning of the values of `Enabled` are not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns the list of item tags (tag type 1), optionally including system tags, sorted by name.\n\nReads all tags of type `TypeId = 1` (item tags) from the `Tag` table.\n\n- With `SystemTags = 0` (default) only user-defined tags are returned (`IsSystemTag = 0`).\n- With `SystemTags = 1` system tags are included as well.\n\nThe result is sorted by tag name in ascending order. Each row contains the tag key, name and description.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SystemTags` | bit | No | Controls whether system tags are included in the result. |\n\nThe table is read with `NOLOCK`, so uncommitted changes may be visible. The header comment of the procedure (\"Template for getting items…\") is a leftover from a template and does not describe the actual behaviour. Any value of `SystemTags` other than `1` behaves like `0`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the list of item tags (tag type 1), optionally including system tags, sorted by name.\n\nReads all tags of type `TypeId = 1` (item tags) from the `Tag` table.\n\n- With `SystemTags = 0` (default) only user-defined tags are returned (`IsSystemTag = 0`).\n- With `SystemTags = 1` system tags are included as well.\n\nThe result is sorted by tag name in ascending order. Each row contains the tag key, name and description.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SystemTags` | bit | No | Controls whether system tags are included in the result. |\n\nThe table is read with `NOLOCK`, so uncommitted changes may be visible. The header comment of the procedure (\"Template for getting items…\") is a leftover from a template and does not describe the actual behaviour. Any value of `SystemTags` other than `1` behaves like `0`.\n\nDocumentation: https://pixi-api-docs.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": "Resolves a list of items into the actual stock items: non-bundle items are returned as they are, bundles are replaced by their components with multiplied quantities.\n\nTakes a list of items with quantities as XML and returns the items that the request actually depends on, for example to check or reserve stock for an order.\n\nSteps:\n\n1. The XML in `ItemXML` is parsed from `/Items/Item`. Each `Item` can identify the article by `ItemKey`, by `ItemNrInt` or by both, and carries a `Qty`.\n2. Missing identifiers are completed from the `Items` table: if `ItemKey` is missing it is looked up by `ItemNrInt`; if `ItemNrInt` is missing it is looked up by `ItemKey`.\n3. Entries whose `ItemKey` cannot be determined (unknown item number) are silently discarded.\n4. Resolution:\n - Items with `IsBundle = 0` are returned with the requested `Qty`.\n - Items with `IsBundle = 1` are not returned themselves. Instead every component from `BundleItems` is returned with quantity `Qty` × component quantity.\n5. The result is grouped by `ItemKey`: quantities of the same item (listed several times or contained in several bundles) are summed up.\n\nIf `ItemXML` is not passed, an empty result set is returned. No sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemXML` | varchar(max) | No | XML list of requested items. Root `Items`, one `Item` element per entry with the child elements `ItemKey` and/or `ItemNrInt` and `Qty`. If NULL, the result is empty. |\n\n- Read-only; all reads on `Items` and `BundleItems` use `NOLOCK`, so uncommitted data may be returned.\n- Bundles are resolved only one level deep. A component that is itself a bundle is returned as it is and is not expanded further.\n- If both `ItemKey` and `ItemNrInt` are given, `ItemKey` is used and `ItemNrInt` is not checked against it.\n- Unknown items are dropped without any error message; compare the result with the request if this matters.\n- If `Qty` is omitted for an entry, its quantity is `NULL` and does not contribute to the summed `Qty` (the sum becomes `NULL` if all contributions are `NULL`).\n- Invalid XML causes an SQL error from `sp_xml_preparedocument`, returned as `SqlMessage`.\n- The data type of the returned `Qty` depends on the type of `BundleItems.Qty`, which is not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Resolves a list of items into the actual stock items: non-bundle items are returned as they are, bundles are replaced by their components with multiplied quantities.\n\nTakes a list of items with quantities as XML and returns the items that the request actually depends on, for example to check or reserve stock for an order.\n\nSteps:\n\n1. The XML in `ItemXML` is parsed from `/Items/Item`. Each `Item` can identify the article by `ItemKey`, by `ItemNrInt` or by both, and carries a `Qty`.\n2. Missing identifiers are completed from the `Items` table: if `ItemKey` is missing it is looked up by `ItemNrInt`; if `ItemNrInt` is missing it is looked up by `ItemKey`.\n3. Entries whose `ItemKey` cannot be determined (unknown item number) are silently discarded.\n4. Resolution:\n - Items with `IsBundle = 0` are returned with the requested `Qty`.\n - Items with `IsBundle = 1` are not returned themselves. Instead every component from `BundleItems` is returned with quantity `Qty` × component quantity.\n5. The result is grouped by `ItemKey`: quantities of the same item (listed several times or contained in several bundles) are summed up.\n\nIf `ItemXML` is not passed, an empty result set is returned. No sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemXML` | varchar(max) | No | XML list of requested items. Root `Items`, one `Item` element per entry with the child elements `ItemKey` and/or `ItemNrInt` and `Qty`. If NULL, the result is empty. |\n\n- Read-only; all reads on `Items` and `BundleItems` use `NOLOCK`, so uncommitted data may be returned.\n- Bundles are resolved only one level deep. A component that is itself a bundle is returned as it is and is not expanded further.\n- If both `ItemKey` and `ItemNrInt` are given, `ItemKey` is used and `ItemNrInt` is not checked against it.\n- Unknown items are dropped without any error message; compare the result with the request if this matters.\n- If `Qty` is omitted for an entry, its quantity is `NULL` and does not contribute to the summed `Qty` (the sum becomes `NULL` if all contributions are `NULL`).\n- Invalid XML causes an SQL error from `sp_xml_preparedocument`, returned as `SqlMessage`.\n- The data type of the returned `Qty` depends on the type of `BundleItems.Qty`, which is not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns items whose assigned tags match an XML tag filter with AND, OR and NOT groups, identifying tags by ID or by (partial) name.\n\nSearches items by the tags assigned to them (table `TagMatch`).\n\n**1. Parsing the filter**\n\n`TagFilter` is an XML document with a root `TagFilter` and the groups `AND`, `OR` and `NOT`. Each group can contain any number of `TagId` and `TagName` elements. Names are trimmed; empty names count as missing.\n\n**2. Resolving tags**\n\nEach entry is resolved against tags of type `TypeId = 1`:\n- `TagId` is compared with the tag ID.\n- `TagName` is compared exactly when `PartialTagNameMatch = 0`, or with `LIKE '%name%'` when `PartialTagNameMatch = 1`. A partial name can resolve to several tags.\n\n**3. Validation**\n\nThe call stops with a status result set and returns no items when:\n- an entry cannot be resolved to any tag, or\n- the same tag is resolved more than once. This applies across groups, within a group, and when a tag is given both by ID and by name.\n\nIn that case one row is returned per filter entry:\n- Faulty entries get `Status = ERROR`.\n- Valid entries get `OK` with `Complete match on TagName`, `Partial match on TagName` or `Complete match on TagId`.\n\n**4. Selecting items**\n\nOnly items that have at least one tag assigned in `TagMatch` are considered. An item is returned if it has **none** of the NOT tags and at least one of these is true:\n- no AND and no OR tags were given (only NOT, or an empty filter);\n- it has **all** AND tags. With `StrictANDCondition = 1` it must also have no other tags at all, so its tag set equals the AND set exactly;\n- it has **at least one** OR tag.\n\nAND and OR are combined with OR. OR tags therefore widen the result instead of narrowing it.\n\nThe result contains `ItemId`, `ItemNrInt` and `ItemName`. Rows are distinct and not sorted.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagFilter` | varchar(max) | Yes | XML filter with root `TagFilter` and optional groups `AND`, `OR` and `NOT`, each containing `TagId` and/or `TagName` elements. |\n| `PartialTagNameMatch` | bit | No | Controls how `TagName` entries are matched against tag names. |\n| `StrictANDCondition` | bit | No | Controls how strictly the AND group is applied to the tags of an item. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may be read.\n- The conversion of `TagFilter` to XML happens **before** the error handling. Malformed XML therefore comes back as a SQL error (`SqlMessage`), not as a status row.\n- A non-numeric `TagId` value causes a conversion error inside the error handling. The result is the single status row `Unexpected error occured while parsing the @TagFilter parameter`.\n- The behaviour for a `NULL` `TagFilter` is not handled explicitly in the code.\n- Only tags with `TypeId = 1` can be used in the filter.\n- The strict AND check considers every tag assigned to the item in `TagMatch`, regardless of its type.\n- The procedure returns 1 after a status result set. Status rows and item rows never appear in the same call; both arrive as `SqlRowSet1`. Check for a `Status` column to tell them apart.\n- With `PartialTagNameMatch = 1`, a short name can hit several tags. It can easily overlap with other entries and trigger `Tag used in another operation`.\n\nDocumentation: https://pixi-api-docs.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": "Returns items whose assigned tags match an XML tag filter with AND, OR and NOT groups, identifying tags by ID or by (partial) name.\n\nSearches items by the tags assigned to them (table `TagMatch`).\n\n**1. Parsing the filter**\n\n`TagFilter` is an XML document with a root `TagFilter` and the groups `AND`, `OR` and `NOT`. Each group can contain any number of `TagId` and `TagName` elements. Names are trimmed; empty names count as missing.\n\n**2. Resolving tags**\n\nEach entry is resolved against tags of type `TypeId = 1`:\n- `TagId` is compared with the tag ID.\n- `TagName` is compared exactly when `PartialTagNameMatch = 0`, or with `LIKE '%name%'` when `PartialTagNameMatch = 1`. A partial name can resolve to several tags.\n\n**3. Validation**\n\nThe call stops with a status result set and returns no items when:\n- an entry cannot be resolved to any tag, or\n- the same tag is resolved more than once. This applies across groups, within a group, and when a tag is given both by ID and by name.\n\nIn that case one row is returned per filter entry:\n- Faulty entries get `Status = ERROR`.\n- Valid entries get `OK` with `Complete match on TagName`, `Partial match on TagName` or `Complete match on TagId`.\n\n**4. Selecting items**\n\nOnly items that have at least one tag assigned in `TagMatch` are considered. An item is returned if it has **none** of the NOT tags and at least one of these is true:\n- no AND and no OR tags were given (only NOT, or an empty filter);\n- it has **all** AND tags. With `StrictANDCondition = 1` it must also have no other tags at all, so its tag set equals the AND set exactly;\n- it has **at least one** OR tag.\n\nAND and OR are combined with OR. OR tags therefore widen the result instead of narrowing it.\n\nThe result contains `ItemId`, `ItemNrInt` and `ItemName`. Rows are distinct and not sorted.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagFilter` | varchar(max) | Yes | XML filter with root `TagFilter` and optional groups `AND`, `OR` and `NOT`, each containing `TagId` and/or `TagName` elements. |\n| `PartialTagNameMatch` | bit | No | Controls how `TagName` entries are matched against tag names. |\n| `StrictANDCondition` | bit | No | Controls how strictly the AND group is applied to the tags of an item. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may be read.\n- The conversion of `TagFilter` to XML happens **before** the error handling. Malformed XML therefore comes back as a SQL error (`SqlMessage`), not as a status row.\n- A non-numeric `TagId` value causes a conversion error inside the error handling. The result is the single status row `Unexpected error occured while parsing the @TagFilter parameter`.\n- The behaviour for a `NULL` `TagFilter` is not handled explicitly in the code.\n- Only tags with `TypeId = 1` can be used in the filter.\n- The strict AND check considers every tag assigned to the item in `TagMatch`, regardless of its type.\n- The procedure returns 1 after a status result set. Status rows and item rows never appear in the same call; both arrive as `SqlRowSet1`. Check for a `Status` column to tell them apart.\n- With `PartialTagNameMatch = 1`, a short name can hit several tags. It can easily overlap with other entries and trigger `Tag used in another operation`.\n\nDocumentation: https://pixi-api-docs.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": "Returns a paged list of the items supplied by a given supplier, with EAN, item name and total stock quantity across all bin locations.\n\nReturns all items that are linked to the supplier `SupplNr`.\n\n1. The procedure looks up all `IntLinkNr1` values in `AddItems` that have the given `SupplNr`. It then selects every record in `Items` with one of these `IntLinkNr1` values.\n2. For each item, `StockQty` is calculated as the sum of `BinItemQTY` in `InvBinItem` for the item (`BinItemRef` = `ItemKey`). This covers all bin locations and is `0` if the item has no stock records.\n3. The rows are numbered consecutively (`RowNr`, starting at 1) in a temporary table.\n4. The call returns only the rows with `RowNr` between `FromRow` and `FromRow + Rows - 1`.\n\nEvery row also carries paging information:\n- `RecordsTotal`: number of all matching items.\n- `RecordsFrom`: the value passed in `FromRow`.\n- `RecordsRequested`: the value passed in `Rows`.\n\nTo page through the list, increase `FromRow` by `Rows` until `FromRow` is greater than `RecordsTotal`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | char(4) | Yes | Supplier number. Matched against `AddItems.SupplNr`. |\n| `FromRow` | int | No | Number of the first row to return (1-based). `NULL` returns all rows. |\n| `Rows` | int | No | Maximum number of rows to return. `NULL` returns all rows from `FromRow` onwards. |\n\n- The row numbering has no `ORDER BY`. The order of the items, and therefore the content of each page, is not guaranteed. It can differ between calls, so paging may return items twice or skip items.\n- If `Rows` is `NULL`, all rows from `FromRow` onwards are returned. If `FromRow` is `NULL`, the complete list is returned, regardless of `Rows`.\n- `RecordsFrom` and `RecordsRequested` echo the parameter values unchanged, including `NULL`.\n- All tables are read `WITH (NOLOCK)`. The results can contain uncommitted data.\n- `StockQty` is the sum over all bin locations and warehouses. Reservations and stock locks are not taken into account.\n- If no item matches the supplier, an empty result set is returned. There is no error row.\n\nDocumentation: https://pixi-api-docs.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": "Returns a paged list of the items supplied by a given supplier, with EAN, item name and total stock quantity across all bin locations.\n\nReturns all items that are linked to the supplier `SupplNr`.\n\n1. The procedure looks up all `IntLinkNr1` values in `AddItems` that have the given `SupplNr`. It then selects every record in `Items` with one of these `IntLinkNr1` values.\n2. For each item, `StockQty` is calculated as the sum of `BinItemQTY` in `InvBinItem` for the item (`BinItemRef` = `ItemKey`). This covers all bin locations and is `0` if the item has no stock records.\n3. The rows are numbered consecutively (`RowNr`, starting at 1) in a temporary table.\n4. The call returns only the rows with `RowNr` between `FromRow` and `FromRow + Rows - 1`.\n\nEvery row also carries paging information:\n- `RecordsTotal`: number of all matching items.\n- `RecordsFrom`: the value passed in `FromRow`.\n- `RecordsRequested`: the value passed in `Rows`.\n\nTo page through the list, increase `FromRow` by `Rows` until `FromRow` is greater than `RecordsTotal`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | char(4) | Yes | Supplier number. Matched against `AddItems.SupplNr`. |\n| `FromRow` | int | No | Number of the first row to return (1-based). `NULL` returns all rows. |\n| `Rows` | int | No | Maximum number of rows to return. `NULL` returns all rows from `FromRow` onwards. |\n\n- The row numbering has no `ORDER BY`. The order of the items, and therefore the content of each page, is not guaranteed. It can differ between calls, so paging may return items twice or skip items.\n- If `Rows` is `NULL`, all rows from `FromRow` onwards are returned. If `FromRow` is `NULL`, the complete list is returned, regardless of `Rows`.\n- `RecordsFrom` and `RecordsRequested` echo the parameter values unchanged, including `NULL`.\n- All tables are read `WITH (NOLOCK)`. The results can contain uncommitted data.\n- `StockQty` is the sum over all bin locations and warehouses. Reservations and stock locks are not taken into account.\n- If no item matches the supplier, an empty result set is returned. There is no error row.\n\nDocumentation: https://pixi-api-docs.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": "Searches items by name or item code, EAN/UPC, configuration type and supplier, and returns item rows including supplier prices and open supplier order quantities.\n\nWrapper around the internal procedure `GOSItemSearch1`. It passes its parameters on and always requests supplier prices and statistics. No user name is passed, so supplier (purchase) prices are always visible.\n\nSteps:\n\n1. If `SupplNr` is empty, `ShowOnlyItemsForExactSupplier` is forced to `0`.\n2. `RowCount` = `0` is replaced by the setting `ItemSearchLimit`. If that setting is also `0`, `300` is used.\n3. If `EANUPC` is set, the item IDs whose code in `pixi.ItemCode` matches exactly are collected. Only code types flagged as scannable count.\n4. If `ItemName` is set and the EAN step found nothing, `ItemName` is compared with **all** item codes:\n - If exactly one code matches exactly, that item is the result. The free-text search is then switched off and code type `1` is used.\n - Otherwise all items whose code starts with `ItemName` are collected. `ItemName` is then also used as a smart search term.\n5. `ConfigType` is passed on as the configuration type filter (`TonTrArt`).\n6. `SupplNr` is passed on as the supplier filter. `LocID` selects the location (default `001`).\n7. The database currency is always used. No exchange rate is passed.\n8. For each item, the open quantity on supplier orders is calculated: ordered minus delivered minus undelivered quantity. Only supplier orders with a fully open status and quantities for the selected location are counted. If `SupplNr` is given, only that supplier's orders count.\n9. The final query returns `SELECT DISTINCT TOP (RowCount)` rows. It is built dynamically.\n\nThe query has no `ORDER BY`; the ORDER BY clause is commented out in the code. The row order is therefore not guaranteed.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `RowCount` | int | No | Maximum number of rows. `0` uses the setting `ItemSearchLimit`; if that is also `0`, the limit is 300. |\n| `ItemName` | varchar(100) | No | Search term. An exact single match on any item code returns that item. Otherwise items whose code starts with the term are collected, and the term is also used as a smart search on item data. |\n| `ConfigType` | varchar(4) | No | Configuration type filter, passed on as `TonTrArt`. Empty means no filter. |\n| `SupplNr` | varchar(4) | No | Supplier number. Used as the supplier filter and to limit the open supplier order quantities to this supplier. |\n| `EANUPC` | varchar(13) | No | EAN/UPC code. Matched exactly against item codes whose code type is scannable. |\n| `LocID` | varchar(3) | No | Location (Lager) ID used for stock data and open supplier order quantities. |\n| `ShowOnlyItemsForExactSupplier` | bit | No | If `1`, only items of exactly the given supplier are returned. It is ignored (set to `0`) when `SupplNr` is empty. |\n\n- The result columns, the item filters (supplier, configuration type, smart search) and the joins come from the procedure `pixi_ItemSearchPrepareDynamicQuery`. Its definition is not attached, so the exact column list cannot be documented here.\n- All reads use `NOLOCK`, so results may include uncommitted data.\n- Behaviour depends on the settings `ItemSearchLimit`, `MultiCurrencyEnabled` and `HalOrdersActiveDays`. The legacy setting `ShowSupplPriceOnlyToTheseUsers` is read but has no effect, because no user name is passed.\n- `ShowStatistics = 1` is passed to `GOSItemSearch1`, but the attached code of that procedure does not use this parameter.\n- Pitfall: on an exact single code match via `ItemName`, the code sets `ItemName` to NULL first and then copies it into `EANUPC`. As a result `EANUPC` also becomes NULL.\n- Single quotes in `ItemName` and `SupplNr` are escaped before they are put into the dynamic SQL.\n\nDocumentation: https://pixi-api-docs.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": "Returns additional item records (supplier-specific item data such as EAN, supplier item number and prices) from `AddItems`, filtered by key, date range and supplier.\n\nReads rows from the table `AddItems`. These rows hold supplier-specific item data: EAN/UPC, supplier item number, internal item number, prices, VAT rate and the preferred-supplier flag.\n\nThe procedure first prepares the parameters:\n\n- If `RowCount` is set and not `0`, the number of returned rows is limited to `RowCount`.\n- If `AddItemKey` is not passed, it is set to `0`.\n- If `SupplNr` is empty or contains only spaces, it is treated as not set.\n\nIt then runs exactly one of the following queries. The first branch whose condition matches wins:\n\n1. **Create or update date** (`CreateAndUpdateDateFrom` and/or `CreateAndUpdateDateTo` set): returns records with `AddItemKey` > `AddItemKey`.\n - The *from* bound matches if `CreateDate` **or** `UpdateDate` is >= `CreateAndUpdateDateFrom`.\n - The *to* bound matches if `CreateDate` **or** `UpdateDate` is < `CreateAndUpdateDateTo`.\n2. **Create date** (`CreateDateFrom` and/or `CreateDateTo` set): returns records with `AddItemKey` > `AddItemKey` and `CreateDate` >= from and < to.\n3. **Update date** (`UpdateDateFrom` and/or `UpdateDateTo` set): returns records with `AddItemKey` > `AddItemKey` and `UpdateDate` >= from and < to.\n4. **Key range** (`RowCount` passed, even as `0`): returns records with `AddItemKey` > `AddItemKey`.\n5. **Single key** (otherwise): returns the record with `AddItemKey` = `AddItemKey`.\n\nIn all branches the optional `SupplNr` filter limits the result to one supplier. Branches 1 to 4 are sorted by `AddItemKey` ascending. This allows paging: pass the last received `AddItemKey` together with `RowCount` to get the next page.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AddItemKey` | int | No | Key of the additional item. Without a date filter or `RowCount`, the record with exactly this key is returned. Otherwise only records with a larger key are returned (paging start). `NULL` is treated as `0`. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for `CreateDate`. Used only if no combined create/update date is set. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for `CreateDate`. Used only if no combined create/update date is set. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for `UpdateDate`. Used only if neither a combined date nor a create date is set. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for `UpdateDate`. Used only if neither a combined date nor a create date is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive). Matches if `CreateDate` or `UpdateDate` is on or after this value. Takes precedence over all other date parameters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (exclusive). Matches if `CreateDate` or `UpdateDate` is before this value. Takes precedence over all other date parameters. |\n| `RowCount` | int | No | Maximum number of rows returned (via `SET ROWCOUNT`). If passed without a date filter, the key-range query runs (`AddItemKey` > given key). `0` means no limit. |\n| `SupplNr` | varchar(4) | No | Supplier number. If set, only records of this supplier are returned. Empty or blank values are ignored. |\n\n- The table is read with `NOLOCK`, so uncommitted changes may be visible.\n- Without any parameter, `AddItemKey` becomes `0` and the single-key branch runs. This normally returns no rows.\n- Passing `RowCount` = `0` selects the key-range branch without a row limit. This returns **all** matching records, which can be slow on large tables.\n- The bounds of the combined create/update filter are each checked against either date column. A record can therefore match even if neither date lies inside the range, for example when `CreateDate` is before the range and `UpdateDate` is after it.\n- Only blank values of `SupplNr` are normalised. Leading spaces are not trimmed and can cause no match.\n- Date filters take precedence over each other in this order: combined create/update, create, update. Lower-priority date parameters are ignored when a higher-priority one is set.\n- All upper bounds are exclusive (`<`).\n- The header comment says \"supplier data\", but the procedure returns additional item records.\n- Column types are not visible in the code. Types marked `unknown` are assumed from the column names.\n\nDocumentation: https://pixi-api-docs.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": "Returns additional item records (supplier-specific item data such as EAN, supplier item number and prices) from `AddItems`, filtered by key, date range and supplier.\n\nReads rows from the table `AddItems`. These rows hold supplier-specific item data: EAN/UPC, supplier item number, internal item number, prices, VAT rate and the preferred-supplier flag.\n\nThe procedure first prepares the parameters:\n\n- If `RowCount` is set and not `0`, the number of returned rows is limited to `RowCount`.\n- If `AddItemKey` is not passed, it is set to `0`.\n- If `SupplNr` is empty or contains only spaces, it is treated as not set.\n\nIt then runs exactly one of the following queries. The first branch whose condition matches wins:\n\n1. **Create or update date** (`CreateAndUpdateDateFrom` and/or `CreateAndUpdateDateTo` set): returns records with `AddItemKey` > `AddItemKey`.\n - The *from* bound matches if `CreateDate` **or** `UpdateDate` is >= `CreateAndUpdateDateFrom`.\n - The *to* bound matches if `CreateDate` **or** `UpdateDate` is < `CreateAndUpdateDateTo`.\n2. **Create date** (`CreateDateFrom` and/or `CreateDateTo` set): returns records with `AddItemKey` > `AddItemKey` and `CreateDate` >= from and < to.\n3. **Update date** (`UpdateDateFrom` and/or `UpdateDateTo` set): returns records with `AddItemKey` > `AddItemKey` and `UpdateDate` >= from and < to.\n4. **Key range** (`RowCount` passed, even as `0`): returns records with `AddItemKey` > `AddItemKey`.\n5. **Single key** (otherwise): returns the record with `AddItemKey` = `AddItemKey`.\n\nIn all branches the optional `SupplNr` filter limits the result to one supplier. Branches 1 to 4 are sorted by `AddItemKey` ascending. This allows paging: pass the last received `AddItemKey` together with `RowCount` to get the next page.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AddItemKey` | int | No | Key of the additional item. Without a date filter or `RowCount`, the record with exactly this key is returned. Otherwise only records with a larger key are returned (paging start). `NULL` is treated as `0`. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for `CreateDate`. Used only if no combined create/update date is set. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for `CreateDate`. Used only if no combined create/update date is set. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for `UpdateDate`. Used only if neither a combined date nor a create date is set. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for `UpdateDate`. Used only if neither a combined date nor a create date is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive). Matches if `CreateDate` or `UpdateDate` is on or after this value. Takes precedence over all other date parameters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (exclusive). Matches if `CreateDate` or `UpdateDate` is before this value. Takes precedence over all other date parameters. |\n| `RowCount` | int | No | Maximum number of rows returned (via `SET ROWCOUNT`). If passed without a date filter, the key-range query runs (`AddItemKey` > given key). `0` means no limit. |\n| `SupplNr` | varchar(4) | No | Supplier number. If set, only records of this supplier are returned. Empty or blank values are ignored. |\n\n- The table is read with `NOLOCK`, so uncommitted changes may be visible.\n- Without any parameter, `AddItemKey` becomes `0` and the single-key branch runs. This normally returns no rows.\n- Passing `RowCount` = `0` selects the key-range branch without a row limit. This returns **all** matching records, which can be slow on large tables.\n- The bounds of the combined create/update filter are each checked against either date column. A record can therefore match even if neither date lies inside the range, for example when `CreateDate` is before the range and `UpdateDate` is after it.\n- Only blank values of `SupplNr` are normalised. Leading spaces are not trimmed and can cause no match.\n- Date filters take precedence over each other in this order: combined create/update, create, update. Lower-priority date parameters are ignored when a higher-priority one is set.\n- All upper bounds are exclusive (`<`).\n- The header comment says \"supplier data\", but the procedure returns additional item records.\n- Column types are not visible in the code. Types marked `unknown` are assumed from the column names.\n\nDocumentation: https://pixi-api-docs.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": "Returns bundle item records (bundle components) from BundleItems, filtered by key, creation date and/or update date, with optional key-based paging.\n\nReads rows from the table `BundleItems`. Each row links an item (`ItemRef`) with a bundled item (`BundleItemRef`) and a quantity (`Qty`).\n\nIf `RowCount` is set to a value other than 0, the number of returned rows is limited to that value. If `BundleItemKey` is not passed, it is treated as `0`.\n\nThe call checks the filter parameters in a fixed order. Only the **first** matching filter group is used:\n\n1. **Combined date filter**: `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` is set. A row matches the lower bound if `CreateDate` **or** `UpdateDate` is on or after `CreateAndUpdateDateFrom`. It matches the upper bound if `CreateDate` **or** `UpdateDate` is before `CreateAndUpdateDateTo`. Only rows with `BundleItemKey` > `BundleItemKey` are returned.\n2. **Creation date filter**: `CreateDateFrom` or `CreateDateTo` is set. The filter is `CreateDate` >= from and `CreateDate` < to, together with `BundleItemKey` > `BundleItemKey`.\n3. **Update date filter**: `UpdateDateFrom` or `UpdateDateTo` is set. The filter is `UpdateDate` >= from and `UpdateDate` < to, together with `BundleItemKey` > `BundleItemKey`.\n4. **Key range / paging**: no date filter is set, but `RowCount` is passed. Returns all rows with `BundleItemKey` > `BundleItemKey`.\n5. **Single record**: neither a date filter nor `RowCount` is passed. Returns the row with exactly `BundleItemKey` = `BundleItemKey`.\n\nThe lower bounds include the given value, the upper bounds exclude it. Branches 1 to 4 are sorted by `BundleItemKey` ascending.\n\nFor paging, pass `RowCount` and set `BundleItemKey` to the last `BundleItemKey` of the previous page.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BundleItemKey` | int | No | With date filters or `RowCount`: only rows with a key greater than this value are returned (paging start). Otherwise: the exact key of the record to read. NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for `CreateDate`. Used only if no combined date filter is set. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for `CreateDate`. Used only if no combined date filter is set. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for `UpdateDate`. Used only if neither a combined filter nor a creation date filter is set. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for `UpdateDate`. Used only if neither a combined filter nor a creation date filter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive) that `CreateDate` or `UpdateDate` must reach. Takes precedence over all other date filters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (exclusive): `CreateDate` or `UpdateDate` must be before this value. Takes precedence over all other date filters. |\n| `RowCount` | int | No | Maximum number of rows to return (0 or NULL = no limit). If set and no date filter is given, the call returns rows with a key greater than `BundleItemKey` instead of a single record. |\n\n- All reads use `WITH (NOLOCK)`. Results may contain uncommitted data.\n- The row limit uses `SET ROWCOUNT`.\n- Passing `RowCount` = `0` still selects branch 4 (key range), because the value is not NULL. No row limit applies in that case, so all rows above the key are returned.\n- Calling without any parameters returns the row with `BundleItemKey` = 0. This normally yields an empty result.\n- The final \"no data\" branch in the code can never be reached, because `BundleItemKey` is never NULL at that point.\n- The exact meaning of `ItemRef` and `BundleItemRef` is not defined in the code. Presumably `ItemRef` is the bundle (parent) item and `BundleItemRef` the component item.\n- The column data types of `ItemRef`, `BundleItemRef` and `Qty` are not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns bundle item records (bundle components) from BundleItems, filtered by key, creation date and/or update date, with optional key-based paging.\n\nReads rows from the table `BundleItems`. Each row links an item (`ItemRef`) with a bundled item (`BundleItemRef`) and a quantity (`Qty`).\n\nIf `RowCount` is set to a value other than 0, the number of returned rows is limited to that value. If `BundleItemKey` is not passed, it is treated as `0`.\n\nThe call checks the filter parameters in a fixed order. Only the **first** matching filter group is used:\n\n1. **Combined date filter**: `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` is set. A row matches the lower bound if `CreateDate` **or** `UpdateDate` is on or after `CreateAndUpdateDateFrom`. It matches the upper bound if `CreateDate` **or** `UpdateDate` is before `CreateAndUpdateDateTo`. Only rows with `BundleItemKey` > `BundleItemKey` are returned.\n2. **Creation date filter**: `CreateDateFrom` or `CreateDateTo` is set. The filter is `CreateDate` >= from and `CreateDate` < to, together with `BundleItemKey` > `BundleItemKey`.\n3. **Update date filter**: `UpdateDateFrom` or `UpdateDateTo` is set. The filter is `UpdateDate` >= from and `UpdateDate` < to, together with `BundleItemKey` > `BundleItemKey`.\n4. **Key range / paging**: no date filter is set, but `RowCount` is passed. Returns all rows with `BundleItemKey` > `BundleItemKey`.\n5. **Single record**: neither a date filter nor `RowCount` is passed. Returns the row with exactly `BundleItemKey` = `BundleItemKey`.\n\nThe lower bounds include the given value, the upper bounds exclude it. Branches 1 to 4 are sorted by `BundleItemKey` ascending.\n\nFor paging, pass `RowCount` and set `BundleItemKey` to the last `BundleItemKey` of the previous page.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BundleItemKey` | int | No | With date filters or `RowCount`: only rows with a key greater than this value are returned (paging start). Otherwise: the exact key of the record to read. NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for `CreateDate`. Used only if no combined date filter is set. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for `CreateDate`. Used only if no combined date filter is set. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for `UpdateDate`. Used only if neither a combined filter nor a creation date filter is set. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for `UpdateDate`. Used only if neither a combined filter nor a creation date filter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive) that `CreateDate` or `UpdateDate` must reach. Takes precedence over all other date filters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (exclusive): `CreateDate` or `UpdateDate` must be before this value. Takes precedence over all other date filters. |\n| `RowCount` | int | No | Maximum number of rows to return (0 or NULL = no limit). If set and no date filter is given, the call returns rows with a key greater than `BundleItemKey` instead of a single record. |\n\n- All reads use `WITH (NOLOCK)`. Results may contain uncommitted data.\n- The row limit uses `SET ROWCOUNT`.\n- Passing `RowCount` = `0` still selects branch 4 (key range), because the value is not NULL. No row limit applies in that case, so all rows above the key are returned.\n- Calling without any parameters returns the row with `BundleItemKey` = 0. This normally yields an empty result.\n- The final \"no data\" branch in the code can never be reached, because `BundleItemKey` is never NULL at that point.\n- The exact meaning of `ItemRef` and `BundleItemRef` is not defined in the code. Presumably `ItemRef` is the bundle (parent) item and `BundleItemRef` the component item.\n- The column data types of `ItemRef`, `BundleItemRef` and `Qty` are not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns Artikel master data for a single item, a key range or items created/updated in a date window, ordered by ItemKey.\n\nReads Artikel records from `items`, enriched with the estimated delivery export value, the supplier name and the configuration type text. All modes return the same columns.\n\nFirst, if `RowCount` is non-zero, the number of returned rows is limited to that value. A missing `ItemKey` is treated as `0`.\n\nThe first matching mode is used:\n\n1. **Created or updated** (`CreateAndUpdateDateFrom` and/or `CreateAndUpdateDateTo` set): items with `ItemKey > ItemKey` where `CreateDate` **or** `UpdateDate` is `>=` the from value, and `CreateDate` **or** `UpdateDate` is `<` the to value. Sorted by `ItemKey` ascending.\n2. **Created** (`CreateDateFrom` and/or `CreateDateTo` set): items with `ItemKey > ItemKey` and `CreateDate` in `[from, to)`. Sorted by `ItemKey`.\n3. **Updated** (`UpdateDateFrom` and/or `UpdateDateTo` set): items with `ItemKey > ItemKey` and `UpdateDate` in `[from, to)`. Sorted by `ItemKey`.\n4. **Key range** (`RowCount` is not NULL): all items with `ItemKey > ItemKey`, sorted by `ItemKey`.\n5. **Single item** (otherwise): the item whose `ItemKey` equals the parameter.\n\nIn modes 1–4, `ItemKey` is an exclusive lower bound. This allows keyset paging: pass the last `ItemKey` of the previous page together with `RowCount`.\n\nThe date checks only apply the bounds that are given. The to values are exclusive.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal Artikel key. In single-item mode it is the exact key. In range and date modes it is an exclusive lower bound (`ItemKey > value`). NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Returns items with `CreateDate >=` this value (inclusive). |\n| `CreateDateTo` | datetime | No | Returns items with `CreateDate <` this value (exclusive). |\n| `UpdateDateFrom` | datetime | No | Returns items with `UpdateDate >=` this value. Ignored if a create date or combined date is given. |\n| `UpdateDateTo` | datetime | No | Returns items with `UpdateDate <` this value (exclusive). Ignored if a create date or combined date is given. |\n| `CreateAndUpdateDateFrom` | datetime | No | Returns items whose `CreateDate` or `UpdateDate` is `>=` this value. Takes precedence over all other date parameters. |\n| `CreateAndUpdateDateTo` | datetime | No | Returns items whose `CreateDate` or `UpdateDate` is `<` this value (exclusive). Takes precedence over all other date parameters. |\n| `RowCount` | int | No | Maximum number of rows (page size). Non-zero values limit the result. Any non-NULL value without date filters selects key-range mode. `0` means no limit. |\n\n- All tables are read `WITH (NOLOCK)`. Results can contain uncommitted or inconsistent data.\n- Calling without any parameter falls into mode 5 with `ItemKey = 0`. This normally returns an empty result. The final `ELSE` branch of the code, which returns an empty result set, is never reached.\n- `RowCount = 0` selects mode 4 (no date filter) without a row limit. It returns all items with `ItemKey > ItemKey`, which can be very large.\n- `RowCount` is applied via `SET ROWCOUNT`, so it also limits mode 5. That mode returns at most one row anyway.\n- In the combined mode, the from and to bounds are checked independently against `CreateDate` or `UpdateDate`. For example, an item created before the from date but updated after it matches the from condition.\n- Date parameters of different modes are not combined. If combined dates are set, the separate create/update dates are ignored, and create dates take precedence over update dates.\n- If several rows exist in `Item_EstimatedDelivery` for one item, the item is returned multiple times.\n\nDocumentation: https://pixi-api-docs.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": "Returns Artikel master data for a single item, a key range or items created/updated in a date window, ordered by ItemKey.\n\nReads Artikel records from `items`, enriched with the estimated delivery export value, the supplier name and the configuration type text. All modes return the same columns.\n\nFirst, if `RowCount` is non-zero, the number of returned rows is limited to that value. A missing `ItemKey` is treated as `0`.\n\nThe first matching mode is used:\n\n1. **Created or updated** (`CreateAndUpdateDateFrom` and/or `CreateAndUpdateDateTo` set): items with `ItemKey > ItemKey` where `CreateDate` **or** `UpdateDate` is `>=` the from value, and `CreateDate` **or** `UpdateDate` is `<` the to value. Sorted by `ItemKey` ascending.\n2. **Created** (`CreateDateFrom` and/or `CreateDateTo` set): items with `ItemKey > ItemKey` and `CreateDate` in `[from, to)`. Sorted by `ItemKey`.\n3. **Updated** (`UpdateDateFrom` and/or `UpdateDateTo` set): items with `ItemKey > ItemKey` and `UpdateDate` in `[from, to)`. Sorted by `ItemKey`.\n4. **Key range** (`RowCount` is not NULL): all items with `ItemKey > ItemKey`, sorted by `ItemKey`.\n5. **Single item** (otherwise): the item whose `ItemKey` equals the parameter.\n\nIn modes 1–4, `ItemKey` is an exclusive lower bound. This allows keyset paging: pass the last `ItemKey` of the previous page together with `RowCount`.\n\nThe date checks only apply the bounds that are given. The to values are exclusive.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal Artikel key. In single-item mode it is the exact key. In range and date modes it is an exclusive lower bound (`ItemKey > value`). NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Returns items with `CreateDate >=` this value (inclusive). |\n| `CreateDateTo` | datetime | No | Returns items with `CreateDate <` this value (exclusive). |\n| `UpdateDateFrom` | datetime | No | Returns items with `UpdateDate >=` this value. Ignored if a create date or combined date is given. |\n| `UpdateDateTo` | datetime | No | Returns items with `UpdateDate <` this value (exclusive). Ignored if a create date or combined date is given. |\n| `CreateAndUpdateDateFrom` | datetime | No | Returns items whose `CreateDate` or `UpdateDate` is `>=` this value. Takes precedence over all other date parameters. |\n| `CreateAndUpdateDateTo` | datetime | No | Returns items whose `CreateDate` or `UpdateDate` is `<` this value (exclusive). Takes precedence over all other date parameters. |\n| `RowCount` | int | No | Maximum number of rows (page size). Non-zero values limit the result. Any non-NULL value without date filters selects key-range mode. `0` means no limit. |\n\n- All tables are read `WITH (NOLOCK)`. Results can contain uncommitted or inconsistent data.\n- Calling without any parameter falls into mode 5 with `ItemKey = 0`. This normally returns an empty result. The final `ELSE` branch of the code, which returns an empty result set, is never reached.\n- `RowCount = 0` selects mode 4 (no date filter) without a row limit. It returns all items with `ItemKey > ItemKey`, which can be very large.\n- `RowCount` is applied via `SET ROWCOUNT`, so it also limits mode 5. That mode returns at most one row anyway.\n- In the combined mode, the from and to bounds are checked independently against `CreateDate` or `UpdateDate`. For example, an item created before the from date but updated after it matches the from condition.\n- Date parameters of different modes are not combined. If combined dates are set, the separate create/update dates are ignored, and create dates take precedence over update dates.\n- If several rows exist in `Item_EstimatedDelivery` for one item, the item is returned multiple times.\n\nDocumentation: https://pixi-api-docs.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": "Returns the assignments of item tags to items, page by page with keyset paging on the assignment ID.\n\nReads tag assignments from `TagMatch` and returns only those whose tag in `Tag` has `TypeId = 1`. According to the code comment, these are item tags.\n\n- Only assignments with an ID greater than `@Start` are returned.\n- At most `@RowCount` rows are returned.\n- Rows are sorted by the assignment ID (`ItemMatchKey`) in ascending order.\n\n**Paging:** `@Start` is not a row offset. It is the last `ItemMatchKey` already received. To read all assignments, start with `Start = 0`. Then call again with `Start` set to the highest `ItemMatchKey` of the previous page. Stop when fewer than `RowCount` rows come back.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Start` | int | No | Only assignments with an ID (`ItemMatchKey`) greater than this value are returned. Pass the last `ItemMatchKey` of the previous page to get the next page. |\n| `RowCount` | int | No | Maximum number of rows to return. |\n\n- Both tables are read with `NOLOCK`, so uncommitted changes may be visible and rows may be missing or duplicated under concurrent writes.\n- The meaning of `TypeId = 1` (item tags) is taken from the procedure comment; other tag types are ignored.\n- The call returns only IDs. Tag names and item details must be read with other calls.\n\nDocumentation: https://pixi-api-docs.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": "Returns the assignments of item tags to items, page by page with keyset paging on the assignment ID.\n\nReads tag assignments from `TagMatch` and returns only those whose tag in `Tag` has `TypeId = 1`. According to the code comment, these are item tags.\n\n- Only assignments with an ID greater than `@Start` are returned.\n- At most `@RowCount` rows are returned.\n- Rows are sorted by the assignment ID (`ItemMatchKey`) in ascending order.\n\n**Paging:** `@Start` is not a row offset. It is the last `ItemMatchKey` already received. To read all assignments, start with `Start = 0`. Then call again with `Start` set to the highest `ItemMatchKey` of the previous page. Stop when fewer than `RowCount` rows come back.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Start` | int | No | Only assignments with an ID (`ItemMatchKey`) greater than this value are returned. Pass the last `ItemMatchKey` of the previous page to get the next page. |\n| `RowCount` | int | No | Maximum number of rows to return. |\n\n- Both tables are read with `NOLOCK`, so uncommitted changes may be visible and rows may be missing or duplicated under concurrent writes.\n- The meaning of `TypeId = 1` (item tags) is taken from the procedure comment; other tag types are ignored.\n- The call returns only IDs. Tag names and item details must be read with other calls.\n\nDocumentation: https://pixi-api-docs.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": "Returns the item tags defined in Pixi, ordered by tag key, with keyset paging via a start key and row count.\n\nReads tags of type item (`TypeId = 1`) from the tag table.\n\n- Only tags whose key is greater than `Start` are returned.\n- The result is sorted by `TagKey` ascending and limited to `RowCount` rows.\n- If `RowCount` is `NULL` or less than 1, 1000 rows are returned.\n\n**Paging:** to read the next page, pass the highest `TagKey` of the previous page as `Start`. Repeat until fewer than `RowCount` rows come back.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Start` | int | No | Only tags with a key greater than this value are returned. Use the last `TagKey` of the previous page for paging. |\n| `RowCount` | int | No | Maximum number of rows to return. `NULL` or values below 1 are replaced by 1000. |\n\nThe table is read with `NOLOCK`, so uncommitted changes may be visible. Tags of other types (other `TypeId` values) are not returned. The call only lists tag definitions; it does not return which items carry a tag.\n\nDocumentation: https://pixi-api-docs.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": "Returns the item tags defined in Pixi, ordered by tag key, with keyset paging via a start key and row count.\n\nReads tags of type item (`TypeId = 1`) from the tag table.\n\n- Only tags whose key is greater than `Start` are returned.\n- The result is sorted by `TagKey` ascending and limited to `RowCount` rows.\n- If `RowCount` is `NULL` or less than 1, 1000 rows are returned.\n\n**Paging:** to read the next page, pass the highest `TagKey` of the previous page as `Start`. Repeat until fewer than `RowCount` rows come back.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Start` | int | No | Only tags with a key greater than this value are returned. Use the last `TagKey` of the previous page for paging. |\n| `RowCount` | int | No | Maximum number of rows to return. `NULL` or values below 1 are replaced by 1000. |\n\nThe table is read with `NOLOCK`, so uncommitted changes may be visible. Tags of other types (other `TypeId` values) are not returned. The call only lists tag definitions; it does not return which items carry a tag.\n\nDocumentation: https://pixi-api-docs.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": "Sets minimum stock, minimum order quantity, target stock and safety stock of an item, globally or for a specific location.\n\nUpdates the purchasing-related quantities of one item.\n\n**Normalising the input**\n- `ItemKey` = `0` and empty strings in all other parameters are treated as `NULL`, which means \"not provided\".\n- A negative `TargetStock` is replaced by `0`.\n\n**Finding the item**\n\nThe item is looked up in `items` by `ItemKey`, `ItemNrInt` **or** `EANUPC`. The conditions are combined with OR, so any record that matches one of the identifiers is used. If no item matches, the passed `ItemKey` stays unchanged.\n\n**Item level (`items`)**\n\nThis step runs only if `Location` is not provided and at least one of `MinStockQty` or `MinOrderQty` is set. It updates `MinStockQty` and `MinOrderQty` of the item. A value that is not provided keeps its current value.\n\n**Location level (`ItemLocationSpecific`)**\n\nThis step runs if at least one of the four quantities is set. It updates `MinStockQty`, `MinOrderQty`, `TargetStock` and `SafetyStock` of the location-specific records of the item:\n- If `Location` is set, only the record with that `LocID` is updated.\n- If `Location` is not set, **all** location records of the item are updated.\n\nValues that are not provided keep their current value.\n\n`TargetStock` and `SafetyStock` exist only at location level.\n\nThe procedure returns no result set.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item. `0` is treated as not provided. |\n| `ItemNrInt` | varchar(50) | No | Internal item number, used as an alternative identifier. An empty string is treated as not provided. |\n| `EANUPC` | varchar(13) | No | EAN/UPC of the item, used as an alternative identifier. An empty string is treated as not provided. |\n| `Location` | varchar(3) | No | Location ID (`LocID`). If set, only the location-specific record of this location is updated and the item-level values remain unchanged. If empty, the item-level values and all location records are updated. |\n| `MinStockQty` | varchar(10) | No | New minimum stock quantity as an integer string. Empty means the value is not changed. |\n| `MinOrderQty` | varchar(10) | No | New minimum order quantity as an integer string. Empty means the value is not changed. |\n| `TargetStock` | varchar(10) | No | New target stock, location level only, as an integer string. Negative values are set to `0`. Empty means the value is not changed. |\n| `SafetyStock` | varchar(10) | No | New safety stock, location level only, as an integer string. Empty means the value is not changed. |\n\n- **Transactions:** the procedure runs in its own transaction, or in a savepoint if a transaction is already open.\n- **Errors are not reported back:** all errors are caught and passed to `log.InsertError`. Examples are a non-numeric quantity that fails the conversion to `int`, or a value longer than 10 characters. That object is not attached, so it is unknown whether anything is returned to the caller. A successful call and a failed call can therefore look identical.\n- **Ambiguous identifiers:** if several items match the combined OR condition, which happens when the identifiers belong to different items, one of them is picked arbitrarily. Pass only one identifier, or consistent ones.\n- **Item not found:** if no item is found, nothing is updated and no message is returned.\n- **No range check:** only `TargetStock` is clamped at `0`. Negative values for `MinStockQty`, `MinOrderQty` and `SafetyStock` are written as they are.\n- **Locking:** the reads use `NOLOCK`; the updates use `ROWLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Updates buying data such as minimum stock, minimum order quantity, order unit, target and safety stock for several items from an XML document.\n\nReads one `Item` element per article from `/BuyingInfo/Item` (element-centric) and writes the given values to the item master, the location-specific item data and the supplier item data.\n\n**Identifying the item**\n\nAn item can be identified by `ItemKey`, `ItemNrInt` or `EAN`. The lookup runs in this order: by `ItemKey`, then by `ItemNrInt`, then by `EAN`. Each match overwrites the identifiers with those of the found item, so a later match wins. Entries for which no item is found are silently skipped.\n\n**Value cleanup**\n\n- Empty text fields (`ItemNrInt`, `EAN`, `Location`, `SupplierCode`) and an empty or `0` `ItemKey` are treated as not given.\n- Quantity fields (`MinStockQty`, `MinOrderQty`, `OrderUnit`, `VPE`, `TargetStock`, `SafetyStock`) are only used if they are numeric; otherwise they are ignored.\n- `OrderUnit` and `VPE` are merged: if `OrderUnit` is given, its value is used for both; otherwise `VPE` is used for both.\n- A negative `TargetStock` is set to `0`.\n- Fields that are not given (NULL) are not changed.\n\n**What is updated**\n\n- `MinStockQty`: on the item master (`items`) only if no `Location` is given; in `ItemLocationSpecific` for all locations of the item if no `Location` is given, otherwise only for that location.\n- `MinOrderQty`: same rule as `MinStockQty`; additionally on the supplier item (`AddItems`) for the supplier given in `SupplierCode` (independent of `Location`).\n- `OrderUnit` / `VPE`: on the item master only, and only if no `Location` is given.\n- `TargetStock` and `SafetyStock`: only in `ItemLocationSpecific`, for all locations or only for the given `Location`.\n\n**Result**\n\nReturns one row per item that was found, with the resolved identifiers and the values that were applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BuyingXML` | varchar(max) | No | XML document with one `Item` element per article below the root `BuyingInfo`. Each item is identified by `ItemKey`, `ItemNrInt` or `EAN`; the other elements carry the values to set. `Location` (max. 3 characters) restricts location-specific updates to one location, `SupplierCode` (max. 4 characters) selects the supplier item for `MinOrderQty`. |\n\n- All updates run in one transaction (or a savepoint if the caller already has an open transaction). On any error the changes are rolled back and the error is logged via `log.InsertError`; that object is not attached, so it is unknown whether the error is passed on to the caller. In that case no result set is returned.\n- `ISNUMERIC` also accepts values such as `1.5` or `1e3`. Such values pass the check but fail when converted to `int`, which aborts and rolls back the whole call. Send integers only.\n- Item lookups use `NOLOCK`. If several items share the same EAN, the EAN lookup can pick any of them and override a match by `ItemKey` or `ItemNrInt`.\n- Values cannot be cleared: an empty element means \"do not change\". Use `0` to reset a quantity.\n- `Location` is not returned in the result set, and the returned row does not show whether a location or supplier record actually existed.\n- The header comment (\"Set Tags for Items\") does not match the actual function of the procedure.\n\nDocumentation: https://pixi-api-docs.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": "Updates buying data such as minimum stock, minimum order quantity, order unit, target and safety stock for several items from an XML document.\n\nReads one `Item` element per article from `/BuyingInfo/Item` (element-centric) and writes the given values to the item master, the location-specific item data and the supplier item data.\n\n**Identifying the item**\n\nAn item can be identified by `ItemKey`, `ItemNrInt` or `EAN`. The lookup runs in this order: by `ItemKey`, then by `ItemNrInt`, then by `EAN`. Each match overwrites the identifiers with those of the found item, so a later match wins. Entries for which no item is found are silently skipped.\n\n**Value cleanup**\n\n- Empty text fields (`ItemNrInt`, `EAN`, `Location`, `SupplierCode`) and an empty or `0` `ItemKey` are treated as not given.\n- Quantity fields (`MinStockQty`, `MinOrderQty`, `OrderUnit`, `VPE`, `TargetStock`, `SafetyStock`) are only used if they are numeric; otherwise they are ignored.\n- `OrderUnit` and `VPE` are merged: if `OrderUnit` is given, its value is used for both; otherwise `VPE` is used for both.\n- A negative `TargetStock` is set to `0`.\n- Fields that are not given (NULL) are not changed.\n\n**What is updated**\n\n- `MinStockQty`: on the item master (`items`) only if no `Location` is given; in `ItemLocationSpecific` for all locations of the item if no `Location` is given, otherwise only for that location.\n- `MinOrderQty`: same rule as `MinStockQty`; additionally on the supplier item (`AddItems`) for the supplier given in `SupplierCode` (independent of `Location`).\n- `OrderUnit` / `VPE`: on the item master only, and only if no `Location` is given.\n- `TargetStock` and `SafetyStock`: only in `ItemLocationSpecific`, for all locations or only for the given `Location`.\n\n**Result**\n\nReturns one row per item that was found, with the resolved identifiers and the values that were applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BuyingXML` | varchar(max) | No | XML document with one `Item` element per article below the root `BuyingInfo`. Each item is identified by `ItemKey`, `ItemNrInt` or `EAN`; the other elements carry the values to set. `Location` (max. 3 characters) restricts location-specific updates to one location, `SupplierCode` (max. 4 characters) selects the supplier item for `MinOrderQty`. |\n\n- All updates run in one transaction (or a savepoint if the caller already has an open transaction). On any error the changes are rolled back and the error is logged via `log.InsertError`; that object is not attached, so it is unknown whether the error is passed on to the caller. In that case no result set is returned.\n- `ISNUMERIC` also accepts values such as `1.5` or `1e3`. Such values pass the check but fail when converted to `int`, which aborts and rolls back the whole call. Send integers only.\n- Item lookups use `NOLOCK`. If several items share the same EAN, the EAN lookup can pick any of them and override a match by `ItemKey` or `ItemNrInt`.\n- Values cannot be cleared: an empty element means \"do not change\". Use `0` to reset a quantity.\n- `Location` is not returned in the result set, and the returned row does not show whether a location or supplier record actually existed.\n- The header comment (\"Set Tags for Items\") does not match the actual function of the procedure.\n\nDocumentation: https://pixi-api-docs.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": "Assigns a category (from the TontrArten category table) to an Artikel, identified by item key or internal item number.\n\nSets the category of a single Artikel.\n\n1. **Identify the item:** If `ItemKEy` is given, it is used directly. If it is `NULL`, the item is looked up by `ItemNRInt` (internal item number) in `items`. If several items match, an arbitrary one is taken (`TOP (1)` without sort order).\n2. If no item key can be determined, a row with `Error` = `Item not found.` is returned and nothing is changed.\n3. **Look up the category:** The category is searched in `TontrArten` by its text (`TontrText` = `Category`). The fields `TontrArt` (config type) and `TontrArtKey` (category ID) of the first match are read.\n4. If no category is found, or the matching row has no `TontrArt`, a row with `Error` = `Category is not existing.` is returned and nothing is changed.\n5. Otherwise the columns `ConfigType` and `CategoryId` of the item are updated and a row with `Error` = `OK` is returned.\n\nThe call always returns exactly one row with one column `Error` that holds the status text.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKEy` | int | No | Internal key of the Artikel (`items.ItemKey`). Takes precedence over `ItemNRInt`. |\n| `ItemNRInt` | varchar(50) | No | Internal item number (`items.ItemNrInt`). Used only if `ItemKEy` is `NULL`. |\n| `Category` | varchar(50) | Yes | Text of the category as stored in `TontrArten.TontrText`. |\n\n- If `ItemKEy` is passed, its existence is **not** checked. For a non-existing key the update affects no row, but the call still returns `OK`.\n- If both `ItemKEy` and `ItemNRInt` are passed, `ItemNRInt` is ignored.\n- The category is matched by its display text, not by key. If several categories share the same text, an arbitrary one is used.\n- Lookups use `NOLOCK` (dirty reads possible); the update uses `ROWLOCK`. No explicit transaction is used.\n- The status column is named `Error` even on success (`OK`).\n\nDocumentation: https://pixi-api-docs.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": "Assigns a category (from the TontrArten category table) to an Artikel, identified by item key or internal item number.\n\nSets the category of a single Artikel.\n\n1. **Identify the item:** If `ItemKEy` is given, it is used directly. If it is `NULL`, the item is looked up by `ItemNRInt` (internal item number) in `items`. If several items match, an arbitrary one is taken (`TOP (1)` without sort order).\n2. If no item key can be determined, a row with `Error` = `Item not found.` is returned and nothing is changed.\n3. **Look up the category:** The category is searched in `TontrArten` by its text (`TontrText` = `Category`). The fields `TontrArt` (config type) and `TontrArtKey` (category ID) of the first match are read.\n4. If no category is found, or the matching row has no `TontrArt`, a row with `Error` = `Category is not existing.` is returned and nothing is changed.\n5. Otherwise the columns `ConfigType` and `CategoryId` of the item are updated and a row with `Error` = `OK` is returned.\n\nThe call always returns exactly one row with one column `Error` that holds the status text.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKEy` | int | No | Internal key of the Artikel (`items.ItemKey`). Takes precedence over `ItemNRInt`. |\n| `ItemNRInt` | varchar(50) | No | Internal item number (`items.ItemNrInt`). Used only if `ItemKEy` is `NULL`. |\n| `Category` | varchar(50) | Yes | Text of the category as stored in `TontrArten.TontrText`. |\n\n- If `ItemKEy` is passed, its existence is **not** checked. For a non-existing key the update affects no row, but the call still returns `OK`.\n- If both `ItemKEy` and `ItemNRInt` are passed, `ItemNRInt` is ignored.\n- The category is matched by its display text, not by key. If several categories share the same text, an arbitrary one is used.\n- Lookups use `NOLOCK` (dirty reads possible); the update uses `ROWLOCK`. No explicit transaction is used.\n- The status column is named `Error` even on success (`OK`).\n\nDocumentation: https://pixi-api-docs.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": "Sets a new EAN/UPC code for exactly one item identified by item key, internal item number, supplier item number or current EAN.\n\nReplaces the EAN/UPC code of a single item.\n\n1. At least one identifier must be passed: `ItemKey`, `ItemNrInt`, `OldEan` or `ItemNrSuppl`. Otherwise the result is `401 No item ID provided`.\n2. The procedure counts the items that match **any** of the passed identifiers. The identifiers are combined with `OR`, not with `AND`.\n - No match: `402 Item not found`.\n - More than one match: `403 More than one item is found`. This also happens when several identifiers are passed that point to different items.\n3. If exactly one item matches, the setting `BMECatImport_Update_EANUPC` is checked. If it is `0` or missing, nothing is changed and the result is `405 ...`.\n4. Otherwise, inside a transaction, `EANUPC` is set to `NewEan`:\n - in `Items` for the item,\n - in `AddItems` for all records whose `ItemRef` points to the item.\n\n On success the result is `200 Item updated`. On an SQL error the transaction is rolled back and the result is `404 Unexpected error: ...`.\n\nThe result text is always written to the output parameter `ResultMessage`. It is also returned as a one-row result set unless `SupressDataset` = 1.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item (`Items.ItemKey`). Optional identifier. |\n| `ItemNrInt` | varchar(50) | No | Internal item number (`Items.ItemNrInt`). Optional identifier. |\n| `OldEan` | varchar(13) | No | Current EAN/UPC of the item (`Items.EANUPC`). Optional identifier. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number (`Items.ItemNrSuppl`). Optional identifier. |\n| `NewEan` | varchar(13) | Yes | New EAN/UPC code to store in `Items` and `AddItems`. |\n| `SupressDataset` | bit | No | Controls whether the result is also returned as a result set. `NULL` is treated as 0. |\n| `ResultMessage` | varchar(256) | No | Output: status code followed by a message text, e.g. `200 Item updated`. |\n\n- Errors are not raised. They are returned as text whose first three characters are a status code (`200`, `401`–`405`). Callers should evaluate this prefix.\n- The setting `BMECatImport_Update_EANUPC` is read via `fpixi_GetSetting`. A missing setting counts as `0`, so the setting must exist with a value other than `0`.\n- `NewEan` is not validated:\n - no check digit or format check,\n - no uniqueness check against other items,\n - `NULL` is not rejected and would clear the EAN.\n- Because `ItemKey` is compared with `''`, an `ItemKey` of `0` is treated as \"not provided\".\n- Item lookups use `NOLOCK`.\n- The text of a `404` message is truncated to 256 characters.\n\nDocumentation: https://pixi-api-docs.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": "Sets a new EAN/UPC code for exactly one item identified by item key, internal item number, supplier item number or current EAN.\n\nReplaces the EAN/UPC code of a single item.\n\n1. At least one identifier must be passed: `ItemKey`, `ItemNrInt`, `OldEan` or `ItemNrSuppl`. Otherwise the result is `401 No item ID provided`.\n2. The procedure counts the items that match **any** of the passed identifiers. The identifiers are combined with `OR`, not with `AND`.\n - No match: `402 Item not found`.\n - More than one match: `403 More than one item is found`. This also happens when several identifiers are passed that point to different items.\n3. If exactly one item matches, the setting `BMECatImport_Update_EANUPC` is checked. If it is `0` or missing, nothing is changed and the result is `405 ...`.\n4. Otherwise, inside a transaction, `EANUPC` is set to `NewEan`:\n - in `Items` for the item,\n - in `AddItems` for all records whose `ItemRef` points to the item.\n\n On success the result is `200 Item updated`. On an SQL error the transaction is rolled back and the result is `404 Unexpected error: ...`.\n\nThe result text is always written to the output parameter `ResultMessage`. It is also returned as a one-row result set unless `SupressDataset` = 1.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item (`Items.ItemKey`). Optional identifier. |\n| `ItemNrInt` | varchar(50) | No | Internal item number (`Items.ItemNrInt`). Optional identifier. |\n| `OldEan` | varchar(13) | No | Current EAN/UPC of the item (`Items.EANUPC`). Optional identifier. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number (`Items.ItemNrSuppl`). Optional identifier. |\n| `NewEan` | varchar(13) | Yes | New EAN/UPC code to store in `Items` and `AddItems`. |\n| `SupressDataset` | bit | No | Controls whether the result is also returned as a result set. `NULL` is treated as 0. |\n| `ResultMessage` | varchar(256) | No | Output: status code followed by a message text, e.g. `200 Item updated`. |\n\n- Errors are not raised. They are returned as text whose first three characters are a status code (`200`, `401`–`405`). Callers should evaluate this prefix.\n- The setting `BMECatImport_Update_EANUPC` is read via `fpixi_GetSetting`. A missing setting counts as `0`, so the setting must exist with a value other than `0`.\n- `NewEan` is not validated:\n - no check digit or format check,\n - no uniqueness check against other items,\n - `NULL` is not rejected and would clear the EAN.\n- Because `ItemKey` is compared with `''`, an `ItemKey` of `0` is treated as \"not provided\".\n- Item lookups use `NOLOCK`.\n- The text of a `404` message is truncated to 256 characters.\n\nDocumentation: https://pixi-api-docs.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": "Updates master data of one or more items (name, description, category, price, VAT level, dimensions, customs data, manufacturer, internal item number).\n\nChanges item master data in `items` and the internal item number in `ItemCode`. Two input channels can be used, alone or together:\n\n- `ItemKey` + `ItemDescription`: sets the description of a single item. An omitted or empty `ItemDescription` removes the description.\n- `ItemInfoXML`: any number of `Item` elements below `/ItemInfo` (element-centric). Each entry identifies the item by `ItemKey`; if `ItemKey` is missing or `0`, the item is looked up by `ItemNrInt` (item code of type 2).\n\n**Processing**\n\n1. Empty elements are treated as not supplied.\n2. Entries whose `Enabled` is not an integer or whose `PriceVK` is not numeric are discarded and reported with a status row.\n3. Field mapping (fields that are not supplied keep their current value, except `ItemDescription`):\n - `ItemName` → `ItemName`, `PicLinkSmall`/`PicLinkLarge`, `CustomsTariffNumber`, `CustomsCountryOfOrigin`, `CustomsTariffText` → same columns, `Manufacturer` → `Artist`.\n - `ItemDescription` → `ItemDescription`, always written; `NULL` if the entry has none.\n - `Enabled` → bit (`0` = disabled, any other number = enabled).\n - `PriceVK` → `Price` (money, decimal point).\n - `VATLevel`: `HIGH`, `LOW`, `ZERO` → `MwStSatz` 1, 2, 3; other values are ignored.\n - `Weight` → whole number `decimal(10,0)`; `Heigth`, `Width`, `Length` → whole numbers `decimal(4,0)`; values that cannot be converted are ignored.\n - `Category`: looked up by text in `TontrArten`. Unknown categories are created with the next free hexadecimal code. The item gets `CategoryId` and `ConfigType` of that category.\n - `InternalItemNumber`: item code of type 3 in `ItemCode`; inserted if the item has none, updated if it differs.\n4. An item is updated only if it exists in `items` and the entry contains at least one field other than `ItemDescription`/`InternalItemNumber`, or it is the item given in the `ItemKey` parameter.\n5. If the same item appears in several entries with different data, it is not updated at all.\n6. Updated items get `UpdateDate` = current time and `UpdateEmp` = `API user SetItemInfo`.\n\n**Result**\n\nIf at least one item qualified for the update and no SQL error occurred, one row per entry is returned with `Status` = `Updated` or a reason why the entry was skipped. Otherwise a single row with `Status` (`404` or `500`) and `ErrorMsg` is returned. The rows are not sorted.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Key of a single item whose description is set from `ItemDescription`. `0` is treated as not supplied. This item is updated even if no other field is given. |\n| `ItemDescription` | varchar(4000) | No | New description for the item given in `ItemKey`. Only used together with `ItemKey`. Empty or omitted clears the description. |\n| `ItemInfoXML` | varchar(max) | No | XML document with one `Item` element per item below `/ItemInfo`. Child elements: `ItemKey`, `ItemNrInt`, `ItemName`, `ItemDescription`, `InternalItemNumber`, `Category`, `Enabled`, `PriceVK`, `PicLinkSmall`, `PicLinkLarge`, `VATLevel`, `Weight`, `Heigth`, `Width`, `Length`, `CustomsTariffNumber`, `CustomsCountryOfOrigin`, `CustomsTariffText`, `Manufacturer`. Empty elements are ignored. |\n\n- **Description is overwritten:** every updated item gets `ItemDescription` from its entry. An XML entry without `ItemDescription` therefore clears the existing description. Always send the description if it must be kept.\n- Sending the same item via the `ItemKey` parameter and in the XML usually produces two different entries and the item is reported as `Duplicated entries found in input parameters` without any change.\n- An entry that only contains `InternalItemNumber` (and/or `ItemDescription`) is not processed and reported as `No item/s found or have no data for update`, unless it is the item of the `ItemKey` parameter.\n- New categories in `TontrArten` are created before the item update and independently of it, even if the item does not exist, the entry is a duplicate or the update later fails.\n- There is no explicit transaction: the `ItemCode` changes and the `items` update are separate statements inside one `TRY` block. If a later statement fails, earlier changes remain and the call returns `500` instead of the per-item rows.\n- During the `items` update `CONTEXT_INFO` is set to `0x11199` to suppress the item triggers; the previous value is restored afterwards.\n- The element for height is spelled `Heigth` in the XML.\n- `Weight` and the dimensions are rounded to whole numbers; dimensions above 9999 are ignored.\n- Malformed XML or a conversion problem before the `TRY` block raises a SQL error (`SqlMessage`) instead of a status row. The code does not check explicitly whether `ItemInfoXML` is empty.\n- If no entry qualifies for an update, only `404` is returned, even when entries were discarded because of non-numeric `Enabled`/`PriceVK`.\n- Reads from `items`, `ItemCode`, `TontrArten` and `Numbers` use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Updates master data of one or more items (name, description, category, price, VAT level, dimensions, customs data, manufacturer, internal item number).\n\nChanges item master data in `items` and the internal item number in `ItemCode`. Two input channels can be used, alone or together:\n\n- `ItemKey` + `ItemDescription`: sets the description of a single item. An omitted or empty `ItemDescription` removes the description.\n- `ItemInfoXML`: any number of `Item` elements below `/ItemInfo` (element-centric). Each entry identifies the item by `ItemKey`; if `ItemKey` is missing or `0`, the item is looked up by `ItemNrInt` (item code of type 2).\n\n**Processing**\n\n1. Empty elements are treated as not supplied.\n2. Entries whose `Enabled` is not an integer or whose `PriceVK` is not numeric are discarded and reported with a status row.\n3. Field mapping (fields that are not supplied keep their current value, except `ItemDescription`):\n - `ItemName` → `ItemName`, `PicLinkSmall`/`PicLinkLarge`, `CustomsTariffNumber`, `CustomsCountryOfOrigin`, `CustomsTariffText` → same columns, `Manufacturer` → `Artist`.\n - `ItemDescription` → `ItemDescription`, always written; `NULL` if the entry has none.\n - `Enabled` → bit (`0` = disabled, any other number = enabled).\n - `PriceVK` → `Price` (money, decimal point).\n - `VATLevel`: `HIGH`, `LOW`, `ZERO` → `MwStSatz` 1, 2, 3; other values are ignored.\n - `Weight` → whole number `decimal(10,0)`; `Heigth`, `Width`, `Length` → whole numbers `decimal(4,0)`; values that cannot be converted are ignored.\n - `Category`: looked up by text in `TontrArten`. Unknown categories are created with the next free hexadecimal code. The item gets `CategoryId` and `ConfigType` of that category.\n - `InternalItemNumber`: item code of type 3 in `ItemCode`; inserted if the item has none, updated if it differs.\n4. An item is updated only if it exists in `items` and the entry contains at least one field other than `ItemDescription`/`InternalItemNumber`, or it is the item given in the `ItemKey` parameter.\n5. If the same item appears in several entries with different data, it is not updated at all.\n6. Updated items get `UpdateDate` = current time and `UpdateEmp` = `API user SetItemInfo`.\n\n**Result**\n\nIf at least one item qualified for the update and no SQL error occurred, one row per entry is returned with `Status` = `Updated` or a reason why the entry was skipped. Otherwise a single row with `Status` (`404` or `500`) and `ErrorMsg` is returned. The rows are not sorted.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Key of a single item whose description is set from `ItemDescription`. `0` is treated as not supplied. This item is updated even if no other field is given. |\n| `ItemDescription` | varchar(4000) | No | New description for the item given in `ItemKey`. Only used together with `ItemKey`. Empty or omitted clears the description. |\n| `ItemInfoXML` | varchar(max) | No | XML document with one `Item` element per item below `/ItemInfo`. Child elements: `ItemKey`, `ItemNrInt`, `ItemName`, `ItemDescription`, `InternalItemNumber`, `Category`, `Enabled`, `PriceVK`, `PicLinkSmall`, `PicLinkLarge`, `VATLevel`, `Weight`, `Heigth`, `Width`, `Length`, `CustomsTariffNumber`, `CustomsCountryOfOrigin`, `CustomsTariffText`, `Manufacturer`. Empty elements are ignored. |\n\n- **Description is overwritten:** every updated item gets `ItemDescription` from its entry. An XML entry without `ItemDescription` therefore clears the existing description. Always send the description if it must be kept.\n- Sending the same item via the `ItemKey` parameter and in the XML usually produces two different entries and the item is reported as `Duplicated entries found in input parameters` without any change.\n- An entry that only contains `InternalItemNumber` (and/or `ItemDescription`) is not processed and reported as `No item/s found or have no data for update`, unless it is the item of the `ItemKey` parameter.\n- New categories in `TontrArten` are created before the item update and independently of it, even if the item does not exist, the entry is a duplicate or the update later fails.\n- There is no explicit transaction: the `ItemCode` changes and the `items` update are separate statements inside one `TRY` block. If a later statement fails, earlier changes remain and the call returns `500` instead of the per-item rows.\n- During the `items` update `CONTEXT_INFO` is set to `0x11199` to suppress the item triggers; the previous value is restored afterwards.\n- The element for height is spelled `Heigth` in the XML.\n- `Weight` and the dimensions are rounded to whole numbers; dimensions above 9999 are ignored.\n- Malformed XML or a conversion problem before the `TRY` block raises a SQL error (`SqlMessage`) instead of a status row. The code does not check explicitly whether `ItemInfoXML` is empty.\n- If no entry qualifies for an update, only `404` is returned, even when entries were discarded because of non-numeric `Enabled`/`PriceVK`.\n- Reads from `items`, `ItemCode`, `TontrArten` and `Numbers` use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Enables or disables an item, or activates or deactivates its supplier assignment, and queues the item for export to the shop.\n\nSets the status of an item.\n\n1. **Find the item.** The item is searched in `Items` by `ItemKey` (only if `ItemKey` is passed) **or** by `ItemNrInt`. If no item matches, status `404` is returned. If more than one item matches, status `409` is returned. This can also happen when both `ItemKey` and `ItemNrInt` are passed and they point to different items.\n2. **Update the status.**\n - Without `SupplierID` (or with an empty string): the `Enabled` flag of the item in `Items` is set to the value of `Enabled`.\n - With `SupplierID`: the item's supplier record in `AddItems` (matched by item and `SupplNr` = `SupplierID`) is searched. If none or more than one is found, status `404` or `409` is returned. If exactly one is found, its `Active` flag is set to `Enabled`. In this case the item's own `Enabled` flag is **not** changed.\n - If the update fails, status `500` with the SQL error message is returned.\n3. **On success** the item is queued for recalculation and forced export to the shop. Then the item is returned with `ItemKey`, `ItemNrInt`, `Enabled`, the passed `SupplNr` and, if a supplier was passed, the supplier record's `Active` flag.\n\nIn case of an error, a single row with `Status` and `ErrorMsg` is returned instead.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | No | Internal item number. Used to find the item if `ItemKey` is not passed (or in addition to it). |\n| `ItemKey` | int | No | Internal key of the item. Alternative to `ItemNrInt`. |\n| `Enabled` | bit | No | New status. It is written to `Items.Enabled`, or to `AddItems.Active` if `SupplierID` is passed. |\n| `SupplierID` | varchar(4) | No | Supplier number (`SupplNr`). If set, only the item's supplier record in `AddItems` is activated or deactivated. An empty string is treated as NULL. |\n\n- **Empty error message:** if `ItemKey` is not passed and the item is not found, the `404` message evaluates to NULL. The reason is that the message concatenates `ItemKey` without NULL handling, so `ErrorMsg` may be empty. Rely on `Status`.\n- **Empty result on success:** the success result joins `Items` with `AddItems`. An item without any supplier record (`AddItems`) therefore returns no rows, even though the update succeeded.\n- **Side effect on success:** `Pixi_ExportItemChangesToShop` inserts the item into `pixi.ItemRecalculateStockQueue` with `ForceToExport = 1`. No export is queued when an error occurs.\n- **Transactions and locking:** no explicit transaction is used. Reads use `NOLOCK` and updates use `ROWLOCK`.\n- **Temporary tables:** they are dropped via `util.TempTableDrop`, whose definition is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Enables or disables an item, or activates or deactivates its supplier assignment, and queues the item for export to the shop.\n\nSets the status of an item.\n\n1. **Find the item.** The item is searched in `Items` by `ItemKey` (only if `ItemKey` is passed) **or** by `ItemNrInt`. If no item matches, status `404` is returned. If more than one item matches, status `409` is returned. This can also happen when both `ItemKey` and `ItemNrInt` are passed and they point to different items.\n2. **Update the status.**\n - Without `SupplierID` (or with an empty string): the `Enabled` flag of the item in `Items` is set to the value of `Enabled`.\n - With `SupplierID`: the item's supplier record in `AddItems` (matched by item and `SupplNr` = `SupplierID`) is searched. If none or more than one is found, status `404` or `409` is returned. If exactly one is found, its `Active` flag is set to `Enabled`. In this case the item's own `Enabled` flag is **not** changed.\n - If the update fails, status `500` with the SQL error message is returned.\n3. **On success** the item is queued for recalculation and forced export to the shop. Then the item is returned with `ItemKey`, `ItemNrInt`, `Enabled`, the passed `SupplNr` and, if a supplier was passed, the supplier record's `Active` flag.\n\nIn case of an error, a single row with `Status` and `ErrorMsg` is returned instead.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | No | Internal item number. Used to find the item if `ItemKey` is not passed (or in addition to it). |\n| `ItemKey` | int | No | Internal key of the item. Alternative to `ItemNrInt`. |\n| `Enabled` | bit | No | New status. It is written to `Items.Enabled`, or to `AddItems.Active` if `SupplierID` is passed. |\n| `SupplierID` | varchar(4) | No | Supplier number (`SupplNr`). If set, only the item's supplier record in `AddItems` is activated or deactivated. An empty string is treated as NULL. |\n\n- **Empty error message:** if `ItemKey` is not passed and the item is not found, the `404` message evaluates to NULL. The reason is that the message concatenates `ItemKey` without NULL handling, so `ErrorMsg` may be empty. Rely on `Status`.\n- **Empty result on success:** the success result joins `Items` with `AddItems`. An item without any supplier record (`AddItems`) therefore returns no rows, even though the update succeeded.\n- **Side effect on success:** `Pixi_ExportItemChangesToShop` inserts the item into `pixi.ItemRecalculateStockQueue` with `ForceToExport = 1`. No export is queued when an error occurs.\n- **Transactions and locking:** no explicit transaction is used. Reads use `NOLOCK` and updates use `ROWLOCK`.\n- **Temporary tables:** they are dropped via `util.TempTableDrop`, whose definition is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Creates or updates the supplier assignment (AddItems row) of an item, including supplier price, supplier item number, EAN and order settings.\n\nMaintains the supplier data of an item in `AddItems` for the supplier given in `SupplNr`.\n\n**Validation**\n1. `ItemKey = 0` and empty strings in `EAN`, `ItemNrSuppl` and `ItemNrInt` are treated as NULL.\n2. If both `ItemKey` and `ItemNrInt` are passed, they must belong to the same item in `items`.\n3. The supplier `SupplNr` must exist in `Suppliers`.\n4. At least one of `ItemKey`, `EAN`, `ItemNrSuppl` or `ItemNrInt` must be passed.\n\n**Identifying the item**\nThe item is searched in the existing `AddItems` rows (joined with `items`). A row matches if any of these is true:\n- `ItemRef = ItemKey`\n- `EANUPC = EAN`\n- `ItemNrInt = ItemNrInt`\n- `ItemNrSuppl = ItemNrSuppl` **and** `SupplNr = SupplNr`\n\nExactly one distinct item must be found; otherwise an error row is returned.\n- With `AddEAN = 0`, it is an error if more than one matching `AddItems` row exists for the given supplier.\n- With `AddEAN = 1`, a warning is returned if a row with the same `EAN` and supplier already exists.\n\n**Writing**\n- If `PreferredSupplier = 1`, `PreferredSupplier` is first reset to 0 on all `AddItems` rows of the item, so only one row stays preferred.\n- If `AddEAN = 0` and a matching `AddItems` row of that supplier exists, the oldest one (lowest `UpdateDate`) is updated. Parameters that are not passed keep the existing values; for price, supplier item number and EAN the item master values are used as fallback. The call returns `Record updated`.\n- Otherwise (no row for this supplier yet, or `AddEAN = 1`), a new `AddItems` row is inserted. Values come from the parameters, with fallback to the item master (`EANUPC`, `ItemNrSuppl`, `SupplPrice`). `ItemNrInt`, `IntLinkNR1`, `IntLinkNR` and `Price` are copied from the item, and `AutoPrice` is set to 0. The call returns `New record inserted`.\n\nThe call always returns exactly one status row with `Status` and `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item (`items.ItemKey`). 0 is treated as NULL. |\n| `ItemNrInt` | varchar(50) | No | Internal item number. If `ItemKey` is also passed, both must belong to the same item. Empty string is treated as NULL. |\n| `SupplNr` | varchar(4) | Yes | Supplier number. It must exist in `Suppliers` and determines which `AddItems` row is updated or created. |\n| `SupplPrice` | money | No | Purchase price at the supplier. If omitted, the existing value is kept; for a new row the item master price is used. |\n| `EAN` | varchar(13) | No | EAN/UPC. It is used to find the item and is stored in `AddItems.EANUPC`. Empty string is treated as NULL. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier's item number. It is used for the lookup only together with `SupplNr` and is stored in `AddItems.ItemNrSuppl`. Empty string is treated as NULL. |\n| `AddEAN` | bit | No | If 1, a new `AddItems` row is always inserted (e.g. for an additional EAN) instead of updating an existing one. |\n| `PreferredSupplier` | smallint | No | Preferred supplier flag. With 1, all other `AddItems` rows of the item are reset to 0. If omitted, the existing value is kept on update; a new row gets 0. |\n| `MinOrderQty` | int | No | Minimum order quantity at the supplier. If omitted, the existing value is kept; a new row gets NULL. |\n| `OnlyPU` | bit | No | Order only in package units (`OrderOnlyPackageUnits`). If omitted, the existing value is kept; a new row gets 0. |\n| `ItemDeliveryTime` | int | No | Supplier delivery time (`SupplDeliveryTime`). If omitted, the existing value is kept; a new row gets NULL. |\n\n- **The item must already have at least one `AddItems` row.** The lookup only searches `AddItems`, so an item without any supplier row returns `No items found with given parameters.`, even if `ItemKey` is valid.\n- With `AddEAN = 1` and a new EAN, the item can only be identified through an existing value. Pass `ItemKey` or `ItemNrInt`, because the new EAN cannot be found in `AddItems` yet.\n- The search conditions are combined with OR. Passing several identifiers that point to different items leads to `More then one item was identified ...`.\n- When a new row is inserted, `MinOrderQty` and `SupplDeliveryTime` take only the passed values (NULL if omitted). `OrderOnlyPackageUnits` and `PreferredSupplier` default to 0.\n- In the success message, NULL values are not handled. If the resulting `ItemNrSuppl` or `EANUPC` is NULL, `Message` is NULL.\n- Writes run in a transaction. If the caller already has an open transaction, a savepoint is used instead. On error the changes are rolled back, the error is logged via `log.InsertError` (definition not attached) and an `Error` row with the SQL error text is returned.\n- Reads use `NOLOCK`; updates use `ROWLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Creates or updates the supplier assignment (AddItems row) of an item, including supplier price, supplier item number, EAN and order settings.\n\nMaintains the supplier data of an item in `AddItems` for the supplier given in `SupplNr`.\n\n**Validation**\n1. `ItemKey = 0` and empty strings in `EAN`, `ItemNrSuppl` and `ItemNrInt` are treated as NULL.\n2. If both `ItemKey` and `ItemNrInt` are passed, they must belong to the same item in `items`.\n3. The supplier `SupplNr` must exist in `Suppliers`.\n4. At least one of `ItemKey`, `EAN`, `ItemNrSuppl` or `ItemNrInt` must be passed.\n\n**Identifying the item**\nThe item is searched in the existing `AddItems` rows (joined with `items`). A row matches if any of these is true:\n- `ItemRef = ItemKey`\n- `EANUPC = EAN`\n- `ItemNrInt = ItemNrInt`\n- `ItemNrSuppl = ItemNrSuppl` **and** `SupplNr = SupplNr`\n\nExactly one distinct item must be found; otherwise an error row is returned.\n- With `AddEAN = 0`, it is an error if more than one matching `AddItems` row exists for the given supplier.\n- With `AddEAN = 1`, a warning is returned if a row with the same `EAN` and supplier already exists.\n\n**Writing**\n- If `PreferredSupplier = 1`, `PreferredSupplier` is first reset to 0 on all `AddItems` rows of the item, so only one row stays preferred.\n- If `AddEAN = 0` and a matching `AddItems` row of that supplier exists, the oldest one (lowest `UpdateDate`) is updated. Parameters that are not passed keep the existing values; for price, supplier item number and EAN the item master values are used as fallback. The call returns `Record updated`.\n- Otherwise (no row for this supplier yet, or `AddEAN = 1`), a new `AddItems` row is inserted. Values come from the parameters, with fallback to the item master (`EANUPC`, `ItemNrSuppl`, `SupplPrice`). `ItemNrInt`, `IntLinkNR1`, `IntLinkNR` and `Price` are copied from the item, and `AutoPrice` is set to 0. The call returns `New record inserted`.\n\nThe call always returns exactly one status row with `Status` and `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item (`items.ItemKey`). 0 is treated as NULL. |\n| `ItemNrInt` | varchar(50) | No | Internal item number. If `ItemKey` is also passed, both must belong to the same item. Empty string is treated as NULL. |\n| `SupplNr` | varchar(4) | Yes | Supplier number. It must exist in `Suppliers` and determines which `AddItems` row is updated or created. |\n| `SupplPrice` | money | No | Purchase price at the supplier. If omitted, the existing value is kept; for a new row the item master price is used. |\n| `EAN` | varchar(13) | No | EAN/UPC. It is used to find the item and is stored in `AddItems.EANUPC`. Empty string is treated as NULL. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier's item number. It is used for the lookup only together with `SupplNr` and is stored in `AddItems.ItemNrSuppl`. Empty string is treated as NULL. |\n| `AddEAN` | bit | No | If 1, a new `AddItems` row is always inserted (e.g. for an additional EAN) instead of updating an existing one. |\n| `PreferredSupplier` | smallint | No | Preferred supplier flag. With 1, all other `AddItems` rows of the item are reset to 0. If omitted, the existing value is kept on update; a new row gets 0. |\n| `MinOrderQty` | int | No | Minimum order quantity at the supplier. If omitted, the existing value is kept; a new row gets NULL. |\n| `OnlyPU` | bit | No | Order only in package units (`OrderOnlyPackageUnits`). If omitted, the existing value is kept; a new row gets 0. |\n| `ItemDeliveryTime` | int | No | Supplier delivery time (`SupplDeliveryTime`). If omitted, the existing value is kept; a new row gets NULL. |\n\n- **The item must already have at least one `AddItems` row.** The lookup only searches `AddItems`, so an item without any supplier row returns `No items found with given parameters.`, even if `ItemKey` is valid.\n- With `AddEAN = 1` and a new EAN, the item can only be identified through an existing value. Pass `ItemKey` or `ItemNrInt`, because the new EAN cannot be found in `AddItems` yet.\n- The search conditions are combined with OR. Passing several identifiers that point to different items leads to `More then one item was identified ...`.\n- When a new row is inserted, `MinOrderQty` and `SupplDeliveryTime` take only the passed values (NULL if omitted). `OrderOnlyPackageUnits` and `PreferredSupplier` default to 0.\n- In the success message, NULL values are not handled. If the resulting `ItemNrSuppl` or `EANUPC` is NULL, `Message` is NULL.\n- Writes run in a transaction. If the caller already has an open transaction, a savepoint is used instead. On error the changes are rolled back, the error is logged via `log.InsertError` (definition not attached) and an `Error` row with the SQL error text is returned.\n- Reads use `NOLOCK`; updates use `ROWLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Synchronises the prefixed item tags of the items given in an XML document: creates missing tags, adds new tag assignments and removes prefixed assignments no longer listed.\n\nSets the tags of one or more items from the XML document in `TagsXML`. The call works as a **replace per item** for all tags whose name starts with `TagPrefix`.\n\nSteps:\n\n1. Every `/ItemTags/Item/TagList/Tag` element becomes one row. The tag name is stored as `TagPrefix` + `Name` (an empty `Name` gives no name). Empty values for `ItemNrInt`, `EANUPC` and `ItemKey` = 0 are treated as missing.\n2. The item is resolved in three passes against `Items`: first by `ItemKey`, then by `ItemNrInt`, then by `EANUPC`. A later match overwrites an earlier one, so if several identifiers are given and point to different items, the EAN match wins. Rows whose item cannot be found are silently dropped.\n3. Tags (type 1, not a system tag) that do not exist yet by name are created in `Tag`. If the same tag name appears with different descriptions, the alphabetically highest description is used; an empty description is stored as empty string. Descriptions of existing tags are not changed.\n4. For each item contained in the XML, all existing assignments in `TagMatch` to tags of type 1 whose name matches `TagPrefix%` and which are not listed for that item are deleted. Tags without the prefix are not touched. An item sent only with an empty tag name therefore loses all its prefixed tags.\n5. Listed tag assignments that do not exist yet are inserted into `TagMatch`.\n\nThe result lists the newly inserted assignments with `Action` = `ADDED`. Items that were sent with an empty tag name additionally appear once with `Action` = `DELETED` and `TagKey`/`TagName` empty. The individual removed assignments are **not** returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | No | XML document with the items and their tag list. Each `Item` identifies the item by `ItemKey`, `ItemNrInt` and/or `EANUPC` and contains a `TagList` with `Tag` elements (`Name`, `Description`). An empty `Name` signals that all prefixed tags of the item are removed. |\n| `TagPrefix` | varchar(20) | No | Prefix placed in front of every tag name from the XML. Only assignments to tags whose name starts with this prefix are synchronised (removed if not listed). Note the trailing space in the default. |\n\n- No explicit transaction: tag creation, deletions and inserts are separate statements; a failure in between can leave a partial state.\n- Reads of `Items` and `Tag` use `NOLOCK`.\n- `TagPrefix` is used in a `LIKE` pattern; `%` or `_` in the prefix act as wildcards and can widen the set of tags that get removed. An empty prefix makes **all** type-1 tags of the listed items subject to removal. A `NULL` prefix yields no tag names, so nothing is added and nothing is removed.\n- The XML element `Name` is read as `varchar(50)`, `Description` as `varchar(500)`, `EANUPC` as `varchar(13)`; longer values are truncated. Whether prefix + name fits into `Tag.Name` depends on the table definition, which is not visible.\n- The XML document handle from `sp_xml_preparedocument` is never released with `sp_xml_removedocument`; it stays allocated until the connection ends.\n- No error rows are returned; unknown items are ignored silently.\n\nDocumentation: https://pixi-api-docs.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": "Synchronises the prefixed item tags of the items given in an XML document: creates missing tags, adds new tag assignments and removes prefixed assignments no longer listed.\n\nSets the tags of one or more items from the XML document in `TagsXML`. The call works as a **replace per item** for all tags whose name starts with `TagPrefix`.\n\nSteps:\n\n1. Every `/ItemTags/Item/TagList/Tag` element becomes one row. The tag name is stored as `TagPrefix` + `Name` (an empty `Name` gives no name). Empty values for `ItemNrInt`, `EANUPC` and `ItemKey` = 0 are treated as missing.\n2. The item is resolved in three passes against `Items`: first by `ItemKey`, then by `ItemNrInt`, then by `EANUPC`. A later match overwrites an earlier one, so if several identifiers are given and point to different items, the EAN match wins. Rows whose item cannot be found are silently dropped.\n3. Tags (type 1, not a system tag) that do not exist yet by name are created in `Tag`. If the same tag name appears with different descriptions, the alphabetically highest description is used; an empty description is stored as empty string. Descriptions of existing tags are not changed.\n4. For each item contained in the XML, all existing assignments in `TagMatch` to tags of type 1 whose name matches `TagPrefix%` and which are not listed for that item are deleted. Tags without the prefix are not touched. An item sent only with an empty tag name therefore loses all its prefixed tags.\n5. Listed tag assignments that do not exist yet are inserted into `TagMatch`.\n\nThe result lists the newly inserted assignments with `Action` = `ADDED`. Items that were sent with an empty tag name additionally appear once with `Action` = `DELETED` and `TagKey`/`TagName` empty. The individual removed assignments are **not** returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | No | XML document with the items and their tag list. Each `Item` identifies the item by `ItemKey`, `ItemNrInt` and/or `EANUPC` and contains a `TagList` with `Tag` elements (`Name`, `Description`). An empty `Name` signals that all prefixed tags of the item are removed. |\n| `TagPrefix` | varchar(20) | No | Prefix placed in front of every tag name from the XML. Only assignments to tags whose name starts with this prefix are synchronised (removed if not listed). Note the trailing space in the default. |\n\n- No explicit transaction: tag creation, deletions and inserts are separate statements; a failure in between can leave a partial state.\n- Reads of `Items` and `Tag` use `NOLOCK`.\n- `TagPrefix` is used in a `LIKE` pattern; `%` or `_` in the prefix act as wildcards and can widen the set of tags that get removed. An empty prefix makes **all** type-1 tags of the listed items subject to removal. A `NULL` prefix yields no tag names, so nothing is added and nothing is removed.\n- The XML element `Name` is read as `varchar(50)`, `Description` as `varchar(500)`, `EANUPC` as `varchar(13)`; longer values are truncated. Whether prefix + name fits into `Tag.Name` depends on the table definition, which is not visible.\n- The XML document handle from `sp_xml_preparedocument` is never released with `sp_xml_removedocument`; it stays allocated until the connection ends.\n- No error rows are returned; unknown items are ignored silently.\n\nDocumentation: https://pixi-api-docs.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": "Assigns one or more item tags to items given as XML and returns one status row per requested tag/item assignment.\n\nCreates entries in `TagMatch` that link tags of type 1 (item tags) to items.\n\n**Input processing**\n\n- `TagsXML` is parsed with `OPENXML` on the path `/Tags/Item/TagList/Tag` (element-centric). Every `Tag` element is one requested assignment.\n- `TagId` is read from the `Tag` element; `ItemId` and `ItemNrInt` are read from the parent `Item` element. The values `0` and the empty string are treated as missing.\n- The item is resolved as follows: if `ItemId` is given, it is used as is. Otherwise `ItemNrInt` is looked up in `pixi.ItemCode` (`Code` with `CodeTypeId = 2`) to find the item key.\n\n**Validation, in this order**\n\n1. Requests where the item key does not exist in `items` or the tag does not exist in `Tag` with `TypeId = 1` get a status:\n - `TagId` missing, or `TagId` given but neither `ItemId` nor `ItemNrInt` given: `Error` / *Mandatory parameter is missing*.\n - `ItemNrInt` not found, `ItemId` unknown, or tag unknown or not an item tag: `Error` / *One of the provided values is not valid*.\n2. Remaining requests where the tag/item pair already exists in `TagMatch` (for a tag of type 1): `Warning` / *Tag is already assigned to that item*.\n3. All other requests: `Success` / *Tag was successfully assigned to item*. These pairs are inserted into `TagMatch` (duplicates within the XML are inserted only once).\n\n**Result**\n\nOne row per requested assignment, ordered by the position of the `Tag` element in the XML, with the tag ID, the resolved item ID, the item number given, and `Status`/`Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | No | XML document with the items and the tags to assign. Each `Item` contains `ItemId` and/or `ItemNrInt` and a `TagList` with one or more `Tag` elements holding a `TagId`. |\n\n- The procedure runs in its own transaction, or sets a savepoint if the caller already has an open transaction.\n- Lookups on `items`, `Tag`, `TagMatch` and `pixi.ItemCode` use `NOLOCK`; concurrent calls may therefore insert the same pair twice or see uncommitted data.\n- If an unexpected error occurs, the transaction is rolled back and the error is logged via `log.InsertError` (not attached). The CATCH block sets an \"Unexpected error\" message internally but does **not** return it as a row, so the caller receives no result set in that case. Whether `log.InsertError` re-raises the error is not visible in the code.\n- `ItemId` takes precedence over `ItemNrInt`; if both are given, `ItemNrInt` is only echoed back.\n- If an `ItemNrInt` matches several `pixi.ItemCode` entries, the request may produce several result rows.\n- Tags whose `TypeId` is not 1 are rejected as invalid.\n\nDocumentation: https://pixi-api-docs.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": "Assigns one or more item tags to items given as XML and returns one status row per requested tag/item assignment.\n\nCreates entries in `TagMatch` that link tags of type 1 (item tags) to items.\n\n**Input processing**\n\n- `TagsXML` is parsed with `OPENXML` on the path `/Tags/Item/TagList/Tag` (element-centric). Every `Tag` element is one requested assignment.\n- `TagId` is read from the `Tag` element; `ItemId` and `ItemNrInt` are read from the parent `Item` element. The values `0` and the empty string are treated as missing.\n- The item is resolved as follows: if `ItemId` is given, it is used as is. Otherwise `ItemNrInt` is looked up in `pixi.ItemCode` (`Code` with `CodeTypeId = 2`) to find the item key.\n\n**Validation, in this order**\n\n1. Requests where the item key does not exist in `items` or the tag does not exist in `Tag` with `TypeId = 1` get a status:\n - `TagId` missing, or `TagId` given but neither `ItemId` nor `ItemNrInt` given: `Error` / *Mandatory parameter is missing*.\n - `ItemNrInt` not found, `ItemId` unknown, or tag unknown or not an item tag: `Error` / *One of the provided values is not valid*.\n2. Remaining requests where the tag/item pair already exists in `TagMatch` (for a tag of type 1): `Warning` / *Tag is already assigned to that item*.\n3. All other requests: `Success` / *Tag was successfully assigned to item*. These pairs are inserted into `TagMatch` (duplicates within the XML are inserted only once).\n\n**Result**\n\nOne row per requested assignment, ordered by the position of the `Tag` element in the XML, with the tag ID, the resolved item ID, the item number given, and `Status`/`Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | No | XML document with the items and the tags to assign. Each `Item` contains `ItemId` and/or `ItemNrInt` and a `TagList` with one or more `Tag` elements holding a `TagId`. |\n\n- The procedure runs in its own transaction, or sets a savepoint if the caller already has an open transaction.\n- Lookups on `items`, `Tag`, `TagMatch` and `pixi.ItemCode` use `NOLOCK`; concurrent calls may therefore insert the same pair twice or see uncommitted data.\n- If an unexpected error occurs, the transaction is rolled back and the error is logged via `log.InsertError` (not attached). The CATCH block sets an \"Unexpected error\" message internally but does **not** return it as a row, so the caller receives no result set in that case. Whether `log.InsertError` re-raises the error is not visible in the code.\n- `ItemId` takes precedence over `ItemNrInt`; if both are given, `ItemNrInt` is only echoed back.\n- If an `ItemNrInt` matches several `pixi.ItemCode` entries, the request may produce several result rows.\n- Tags whose `TypeId` is not 1 are rejected as invalid.\n\nDocumentation: https://pixi-api-docs.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": "Removes tag assignments (TagMatch) from items for a list of tag/item pairs passed as XML and returns a status row per pair.\n\nDeletes the assignment of item tags to items in bulk.\n\n**Input**\n\n`TagsXML` contains one `Item` element per item, each with a `TagList` of `Tag` elements. Every `Tag` element is one request (tag/item pair). The item is identified either by `ItemId` (the item key) or by `ItemNrInt` (internal item number, looked up in `ItemCode` with code type `2`). If `ItemId` is given, it takes precedence over `ItemNrInt`. Values `0` for `TagId`/`ItemId` and empty `ItemNrInt` are treated as missing.\n\n**Validation per pair**\n\n- `TagId` missing, or neither `ItemId` nor `ItemNrInt` given → `Error` / *Mandatory parameter is missing*.\n- `ItemNrInt` given but not found, `ItemId` not found in `items`, or `TagId` not an existing tag of type `1` (item tag) → `Error` / *One of the provided values is not valid*.\n- Tag and item valid and an assignment exists in `TagMatch` → assignment is deleted, `Success` / *Tag was successfully removed from item*.\n- Tag and item valid but no assignment exists → `Warning` / *Tag is not assigned to that item*.\n\n**Output**\n\nOne result set with one row per processed `Tag` element (ordered by the position in the XML) containing `TagId`, the resolved `ItemId`, the given `ItemNrInt`, `Status` and `Message`. Invalid pairs do not stop the processing of the other pairs.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | No | XML document with the items and the tags to remove. Path `/Tags/Item/TagList/Tag`, element-centric: `Item` has `ItemId` or `ItemNrInt`, each `Tag` has `TagId`. |\n\n- The whole call runs in a transaction (`XACT_ABORT ON`); if called inside an existing transaction, a savepoint is used instead.\n- On an unexpected SQL error the transaction is rolled back and the error is written to the error log via `log.InsertError`. The procedure does **not** return a result set in this case, so an empty response must be treated as failure.\n- If `TagsXML` is omitted (`NULL`) or contains no `Tag` elements, nothing is deleted and no rows (or no result set) are returned.\n- When `ItemId` and `ItemNrInt` are both given, only `ItemId` is used; consistency between the two is not checked.\n- If an `ItemNrInt` matches several items in `ItemCode`, the pair can produce several result rows.\n- Lookups use `NOLOCK`; the delete uses `ROWLOCK`.\n- Only tags with `TypeId = 1` (item tags) are considered.\n\nDocumentation: https://pixi-api-docs.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": "Removes tag assignments (TagMatch) from items for a list of tag/item pairs passed as XML and returns a status row per pair.\n\nDeletes the assignment of item tags to items in bulk.\n\n**Input**\n\n`TagsXML` contains one `Item` element per item, each with a `TagList` of `Tag` elements. Every `Tag` element is one request (tag/item pair). The item is identified either by `ItemId` (the item key) or by `ItemNrInt` (internal item number, looked up in `ItemCode` with code type `2`). If `ItemId` is given, it takes precedence over `ItemNrInt`. Values `0` for `TagId`/`ItemId` and empty `ItemNrInt` are treated as missing.\n\n**Validation per pair**\n\n- `TagId` missing, or neither `ItemId` nor `ItemNrInt` given → `Error` / *Mandatory parameter is missing*.\n- `ItemNrInt` given but not found, `ItemId` not found in `items`, or `TagId` not an existing tag of type `1` (item tag) → `Error` / *One of the provided values is not valid*.\n- Tag and item valid and an assignment exists in `TagMatch` → assignment is deleted, `Success` / *Tag was successfully removed from item*.\n- Tag and item valid but no assignment exists → `Warning` / *Tag is not assigned to that item*.\n\n**Output**\n\nOne result set with one row per processed `Tag` element (ordered by the position in the XML) containing `TagId`, the resolved `ItemId`, the given `ItemNrInt`, `Status` and `Message`. Invalid pairs do not stop the processing of the other pairs.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | No | XML document with the items and the tags to remove. Path `/Tags/Item/TagList/Tag`, element-centric: `Item` has `ItemId` or `ItemNrInt`, each `Tag` has `TagId`. |\n\n- The whole call runs in a transaction (`XACT_ABORT ON`); if called inside an existing transaction, a savepoint is used instead.\n- On an unexpected SQL error the transaction is rolled back and the error is written to the error log via `log.InsertError`. The procedure does **not** return a result set in this case, so an empty response must be treated as failure.\n- If `TagsXML` is omitted (`NULL`) or contains no `Tag` elements, nothing is deleted and no rows (or no result set) are returned.\n- When `ItemId` and `ItemNrInt` are both given, only `ItemId` is used; consistency between the two is not checked.\n- If an `ItemNrInt` matches several items in `ItemCode`, the pair can produce several result rows.\n- Lookups use `NOLOCK`; the delete uses `ROWLOCK`.\n- Only tags with `TypeId = 1` (item tags) are considered.\n\nDocumentation: https://pixi-api-docs.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": "Returns dashboard counts of shipped invoices for the given day, the previous day, the current month up to the end date and the previous month.\n\nCounts shipments for a dashboard. A shipment is a record in `Invoices` with a `ScanOutDate`. Only invoices with at least one order line (`Orderlines.InvRef`) are counted. Each invoice counts once, so the values are invoice counts, not order counts.\n\nHow the parameters work:\n- `EndDate` defaults to the current date and time (`GETDATE()`). It is the reference date for all periods.\n- `StartDate` defaults to the first day of the month before `EndDate`. It is only used for the given-day value, and only if it is on the same calendar day as `EndDate`. If `StartDate` is later than `EndDate`, it is set to `EndDate`.\n- `ShopID` limits the count to invoices that have at least one order line with `OrdShopID` = `ShopID`. An empty value or `NULL` means all shops.\n\nThe call first collects all matching invoices whose `ScanOutDate` lies between the start of the previous month and the end of the `EndDate` day. It then returns one row with four counts (all ranges include both ends):\n- `ShipoutOnGivenDay`: from `StartDate` (same day) or else midnight of the `EndDate` day, up to `EndDate`.\n- `ShipoutOnPreviousDay`: the whole calendar day before `EndDate`.\n- `ShipoutInGivenMonth`: from the 1st of the `EndDate` month, 00:00, up to `EndDate`.\n- `ShipoutInPreviousMonth`: the whole previous calendar month.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | No | Start time for the given-day count. Only used if it is on the same calendar day as `EndDate`. Default: first day of the month before `EndDate`, which means the count starts at midnight of the `EndDate` day. |\n| `EndDate` | datetime | No | Reference date and time. All periods are calculated from it, and the given-day and given-month counts run up to this moment. Default: current date and time. |\n| `ShopID` | varchar(3) | No | Shop filter. Only invoices with at least one order line of this shop (`OrdShopID`) are counted. Empty or `NULL` means all shops. |\n\n- All four counts are uppercase-free strings in SQL terms: they are stored in `varchar(10)` variables, so they come back as strings, not integers.\n- The counts run up to `EndDate` itself, not to the end of that day. If `EndDate` is passed without a time (midnight), `ShipoutOnGivenDay` only counts invoices scanned exactly at midnight, and `ShipoutInGivenMonth` leaves out the whole `EndDate` day. Pass a time such as 23:59:59, or omit `EndDate` to use the current time.\n- `StartDate` cannot be used for a range over several days. If it is on another day than `EndDate`, it is ignored and the given-day count starts at midnight of the `EndDate` day.\n- Reads use `NOLOCK`, so the counts can include uncommitted data.\n- If an error occurs, the message is only printed and the procedure returns -1 without any result set.\n\nDocumentation: https://pixi-api-docs.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": "Returns dashboard counts of shipped invoices for the given day, the previous day, the current month up to the end date and the previous month.\n\nCounts shipments for a dashboard. A shipment is a record in `Invoices` with a `ScanOutDate`. Only invoices with at least one order line (`Orderlines.InvRef`) are counted. Each invoice counts once, so the values are invoice counts, not order counts.\n\nHow the parameters work:\n- `EndDate` defaults to the current date and time (`GETDATE()`). It is the reference date for all periods.\n- `StartDate` defaults to the first day of the month before `EndDate`. It is only used for the given-day value, and only if it is on the same calendar day as `EndDate`. If `StartDate` is later than `EndDate`, it is set to `EndDate`.\n- `ShopID` limits the count to invoices that have at least one order line with `OrdShopID` = `ShopID`. An empty value or `NULL` means all shops.\n\nThe call first collects all matching invoices whose `ScanOutDate` lies between the start of the previous month and the end of the `EndDate` day. It then returns one row with four counts (all ranges include both ends):\n- `ShipoutOnGivenDay`: from `StartDate` (same day) or else midnight of the `EndDate` day, up to `EndDate`.\n- `ShipoutOnPreviousDay`: the whole calendar day before `EndDate`.\n- `ShipoutInGivenMonth`: from the 1st of the `EndDate` month, 00:00, up to `EndDate`.\n- `ShipoutInPreviousMonth`: the whole previous calendar month.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | No | Start time for the given-day count. Only used if it is on the same calendar day as `EndDate`. Default: first day of the month before `EndDate`, which means the count starts at midnight of the `EndDate` day. |\n| `EndDate` | datetime | No | Reference date and time. All periods are calculated from it, and the given-day and given-month counts run up to this moment. Default: current date and time. |\n| `ShopID` | varchar(3) | No | Shop filter. Only invoices with at least one order line of this shop (`OrdShopID`) are counted. Empty or `NULL` means all shops. |\n\n- All four counts are uppercase-free strings in SQL terms: they are stored in `varchar(10)` variables, so they come back as strings, not integers.\n- The counts run up to `EndDate` itself, not to the end of that day. If `EndDate` is passed without a time (midnight), `ShipoutOnGivenDay` only counts invoices scanned exactly at midnight, and `ShipoutInGivenMonth` leaves out the whole `EndDate` day. Pass a time such as 23:59:59, or omit `EndDate` to use the current time.\n- `StartDate` cannot be used for a range over several days. If it is on another day than `EndDate`, it is ignored and the given-day count starts at midnight of the `EndDate` day.\n- Reads use `NOLOCK`, so the counts can include uncommitted data.\n- If an error occurs, the message is only printed and the procedure returns -1 without any result set.\n\nDocumentation: https://pixi-api-docs.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": "Returns the average order throughput time in days and the percentage of orders shipped within 24 hours for the last N days.\n\nCalculates two shipping efficiency KPIs for the CEO dashboard. The values are returned as one row and also through the two `OUTPUT` parameters.\n\n1. **Sampling window**: The window starts at midnight of the day that lies `@SamplingPeriod` days before today and ends at the current time. If `@SamplingPeriod` is `NULL`, 7 days are used.\n2. **Orders considered**: An order counts as shipped if it has at least one order line with status `AUS` and a `ShipDate` inside the window, and none of its lines has a status other than `AUS`. Orders that are only partly shipped or that contain lines in any other status are ignored.\n3. **Throughput time per order**: For the shipped lines inside the window, the code reads the `ANG` and `AUS` entries from the order history. The throughput time of an order is the difference in hours (`DATEDIFF(hh, …)`) between the earliest `ANG` status change and the latest `AUS` status change.\n4. **KPIs**:\n - `AVGThroughputTimeInDays`: the sum of the per-order throughput times converted to days (`hoursPassed / 24`), divided by the number of shipped orders. The result is rounded to 2 decimals.\n - `PercThroughputTimeIn24h`: the number of orders with a throughput time of at most 24 hours, divided by the number of shipped orders and multiplied by 100. The result is rounded to 2 decimals.\n5. If no shipped orders are found, both values are `0`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SamplingPeriod` | int | No | Number of days back from today over which the KPIs are calculated. The window starts at midnight of that day. `NULL` is treated as 7. |\n| `AVGThroughputTimeInDays` | float | No | Output: average throughput time in days (full days per order), rounded to 2 decimals. Any input value is ignored. |\n| `PercThroughputTimeIn24h` | float | No | Output: percentage of shipped orders with a throughput time of at most 24 hours, rounded to 2 decimals. Any input value is ignored. |\n\n- All reads use `NOLOCK`, so the values can include uncommitted data.\n- `hoursPassed` is an integer, so `hoursPassed / 24` is an integer division. Each order contributes only full days to the average, and fractions of a day are cut off. An order with 30 hours counts as 1 day, and an order with 20 hours counts as 0 days.\n- `DATEDIFF(hh, …)` counts hour boundaries that are crossed. It does not measure exact elapsed time.\n- The divisor is the number of all fully shipped orders. This also includes orders that have no `ANG`/`AUS` history entries. Such orders have no throughput time or a `NULL` throughput time. They lower both KPIs.\n- Edge case: if shipped orders exist but none has matching history entries, the sum is `NULL`. `AVGThroughputTimeInDays` is then returned as `NULL` and `PercThroughputTimeIn24h` as `0`.\n- Only lines with a `ShipDate` inside the window are used to determine the earliest `ANG` and the latest `AUS` date.\n- The call can be expensive on large order histories, because `orderhistory` is scanned for all `ANG`/`AUS` entries.\n\nDocumentation: https://pixi-api-docs.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": "Returns the average order throughput time in days and the percentage of orders shipped within 24 hours for the last N days.\n\nCalculates two shipping efficiency KPIs for the CEO dashboard. The values are returned as one row and also through the two `OUTPUT` parameters.\n\n1. **Sampling window**: The window starts at midnight of the day that lies `@SamplingPeriod` days before today and ends at the current time. If `@SamplingPeriod` is `NULL`, 7 days are used.\n2. **Orders considered**: An order counts as shipped if it has at least one order line with status `AUS` and a `ShipDate` inside the window, and none of its lines has a status other than `AUS`. Orders that are only partly shipped or that contain lines in any other status are ignored.\n3. **Throughput time per order**: For the shipped lines inside the window, the code reads the `ANG` and `AUS` entries from the order history. The throughput time of an order is the difference in hours (`DATEDIFF(hh, …)`) between the earliest `ANG` status change and the latest `AUS` status change.\n4. **KPIs**:\n - `AVGThroughputTimeInDays`: the sum of the per-order throughput times converted to days (`hoursPassed / 24`), divided by the number of shipped orders. The result is rounded to 2 decimals.\n - `PercThroughputTimeIn24h`: the number of orders with a throughput time of at most 24 hours, divided by the number of shipped orders and multiplied by 100. The result is rounded to 2 decimals.\n5. If no shipped orders are found, both values are `0`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SamplingPeriod` | int | No | Number of days back from today over which the KPIs are calculated. The window starts at midnight of that day. `NULL` is treated as 7. |\n| `AVGThroughputTimeInDays` | float | No | Output: average throughput time in days (full days per order), rounded to 2 decimals. Any input value is ignored. |\n| `PercThroughputTimeIn24h` | float | No | Output: percentage of shipped orders with a throughput time of at most 24 hours, rounded to 2 decimals. Any input value is ignored. |\n\n- All reads use `NOLOCK`, so the values can include uncommitted data.\n- `hoursPassed` is an integer, so `hoursPassed / 24` is an integer division. Each order contributes only full days to the average, and fractions of a day are cut off. An order with 30 hours counts as 1 day, and an order with 20 hours counts as 0 days.\n- `DATEDIFF(hh, …)` counts hour boundaries that are crossed. It does not measure exact elapsed time.\n- The divisor is the number of all fully shipped orders. This also includes orders that have no `ANG`/`AUS` history entries. Such orders have no throughput time or a `NULL` throughput time. They lower both KPIs.\n- Edge case: if shipped orders exist but none has matching history entries, the sum is `NULL`. `AVGThroughputTimeInDays` is then returned as `NULL` and `PercThroughputTimeIn24h` as `0`.\n- Only lines with a `ShipDate` inside the window are used to determine the earliest `ANG` and the latest `AUS` date.\n- The call can be expensive on large order histories, because `orderhistory` is scanned for all `ANG`/`AUS` entries.\n\nDocumentation: https://pixi-api-docs.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": "Adds a new order line for an item to an existing order, calculates prices and discounts, and returns the new order line ID or validation errors.\n\nAdds one order line (`Orderlines` row) to the order `PixiOrderNr`.\n\n**1. Normalisation**\n- `ItemKey` = 0 is treated as NULL and `ItemNrInt` = '' as NULL.\n- An empty `Date` becomes the current date/time.\n- An empty `Status` becomes `NEW`.\n- A NULL `UsePaymentStatus` becomes 0 and a NULL `LocationID` becomes `001`.\n\n**2. Validation**\nAll failed checks are collected, and each one adds an error row:\n- `UsePaymentStatus` = 1 together with a `Status` other than `NEW` is rejected.\n- `Status` must be one of `NEW`, `ANG`, `HAL`, `FUT`, `STO`, `NLB`.\n- If `ItemNrInt` is given, the item is looked up by `ItemNrInt`. The found key replaces `ItemKey`. If no item matches, an error is raised.\n- If no error has occurred so far, the item must have an entry in `pixi.ItemCode`.\n- A non-zero `Discount` (voucher amount) requires `VoucherID`.\n- If the order already has a line with a voucher, a different `VoucherID` is rejected. Only one voucher per order is allowed.\n\nIf any check fails, the error rows are returned and nothing is written.\n\n**3. Status from payment method**\nWith `UsePaymentStatus` = 1, the line status is taken from `Payments.IniOrderStatus` of the payment method of the order's billing address.\n\n**4. Can lines be added?**\n`pipiCanAddOrderlines` checks whether the order still accepts new lines:\n- For payment methods `K`/`C`, all existing lines must be in `NEW`, `ANG`, `HAL`, `MIN`, `OPH`, `BES`, `STO` or `NLB`.\n- For other payment methods, no line may be in `EIN` or `AUS`.\n\nOnly if the result is 1 is the line created.\n\n**5. Header data**\n- Customer, addresses, order type, currency and the existing header values are read from the order.\n- `OrderNrExternal` is taken from the order header. If the header has none, the parameter is used. If that is also missing, a timestamp string is generated.\n- `Employee` is stored as ` (API)`, or as `API` if `Employee` is not given.\n\n**6. Currency**\nIf the setting `MultiCurrencyEnabled` is off, or the order has no exchange rate, the database currency is used with rate 1. Otherwise:\n- Today's exchange rates are read from `pixi.ExchRate`.\n- The database currency uses its rate source.\n- The base currency of the order's exchange rate record uses the shop's `ExchRateSourceID` as source.\n\n**7. Prices**\n- `FullPrice` (gross) and its net counterpart come from the parameter if it is non-zero.\n- Otherwise the item price is used: the price in the order currency first, then the base-currency price × rate, then the database-currency price × rate, else 0.\n- For `B2B` orders, the `FullPrice` parameter is interpreted as the net price, and the gross price is always taken from the item prices.\n- `ItemName` overrides the item name.\n\n**8. Discount per line**\n- `FullPriceDiscountValue` is used if it is given.\n- Otherwise `DiscountPercent` % of the gross price (`B2C`) or of the net price (other order types) is used.\n- Otherwise the full price minus `DiscountedPrice` is used.\n- Otherwise the discount is 0.\n\nThe same discount value is subtracted from both the gross and the net price to get `Price` and `Price_Net`.\n\n**9. Order header values**\n- `ShipCost`, `Discount`, `AddressRemarks`, `Verfahren`, `Product` and `Extras` are taken from the parameters if they are non-empty or non-zero. Otherwise the existing header values are kept.\n- An existing voucher of the order always wins over `VoucherID`.\n\n**10. Insert**\nThe line is inserted via `Pixi_InsertOrderline` with these fixed values:\n- source `I`\n- line type `ORD`\n- wait days 15\n- `LocationID` as stock location and last order location\n\nThe call then returns a row with `CanAdd` = 1 and the new `OrderlineId`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PixiOrderNr` | int | Yes | Pixi order number of the existing order. |\n| `ItemKey` | int | No | Internal item key. 0 is treated as NULL. It is replaced by the key found via `ItemNrInt` if that parameter is given. |\n| `ItemNrInt` | varchar(50) | No | Shop item number used to look up the item. An empty string is treated as NULL. |\n| `Quantity` | int | No | Quantity of the order line. |\n| `ShipCost` | money | No | Shipping cost of the line. If 0, the shipping cost of the order header is used. |\n| `LocationID` | varchar(3) | No | Stock location ID of the line. NULL becomes `001`. |\n| `GiftMessage` | varchar(8000) | No | Gift message. It is written to the order header and overwrites the existing value, including with the default empty string. |\n| `DiscountPercent` | numeric(6, 2) | No | Line discount in percent of the full price (gross for B2C, net otherwise). Used only if `FullPriceDiscountValue` is NULL. |\n| `VoucherID` | varchar(50) | No | Voucher code. Required if `Discount` is not 0. An existing voucher on the order takes precedence; a different code is rejected. |\n| `Discount` | money | No | Voucher amount for the order header. If NULL or 0, the existing header value is kept. If the resulting value is > 0, a voucher record is created if it does not exist yet. |\n| `AddressRemarks` | varchar(255) | No | Address remarks for the order header. If empty, the existing value is kept. |\n| `Verfahren` | varchar(50) | No | Value for the header field `Verfahren`. If empty, the existing value is kept. |\n| `Product` | varchar(50) | No | Value for the header field `Product`. If empty, the existing value is kept. |\n| `Extras` | varchar(50) | No | Value for the header field `Extras`. If empty, the existing value is kept. |\n| `Employee` | varchar(50) | No | Creating employee. It is stored with the suffix ` (API)`; if NULL, `API` is stored. |\n| `Date` | datetime | No | Creation date of the line (`CreateDate`/`UpdateDate`). If empty, the current date/time is used. `OrderDate` of the line is always the current time. |\n| `Status` | varchar(3) | No | Status of the new line. If empty, `NEW` is used. |\n| `UsePaymentStatus` | bit | No | If 1, the line status is taken from the initial order status of the order's payment method. It cannot be combined with a `Status` other than `NEW`. |\n| `ItemNrExternal` | varchar(50) | No | External item number stored in the line. |\n| `FullPrice` | money | No | Full gross price before discount. For B2B orders this value is used as the net price. If NULL or 0, the item price is used. |\n| `FullPriceDiscountValue` | money | No | Absolute discount per unit. It has priority over `DiscountPercent` and `DiscountedPrice`. |\n| `DiscountedPrice` | money | No | Price after discount. The discount is computed as the full price minus this value; used only if no other discount parameter is given. |\n| `ItemName` | varchar(120) | No | Item name for the line. If NULL, the item master name is used. |\n| `ItemSpecialNote` | varchar(8000) | No | Special note for the line (`oItemSpecialNote`). |\n| `OrderNrExternal` | varchar(50) | No | External order number. It is used only if the order header has none; otherwise the header value wins. Without either, a timestamp string is generated. |\n| `DF_Type` | varchar(1) | No | Direct fulfillment type, stored in `DF_type` of the line. |\n| `SerialNumber` | varchar(50) | No | Serial number stored in `SerialNr` of the line. |\n\n- **No result when lines cannot be added:** if `pipiCanAddOrderlines` returns 0 or NULL, the call returns no rows at all. This happens when the order is not found or a line is already in a blocking status. Treat an empty response as \"not added\".\n- **Duplicate error row:** the check for `UsePaymentStatus` = 1 with `Status` ≠ `NEW` runs twice, so that error appears twice in the result.\n- **Status not re-checked:** a status taken from the payment method (`UsePaymentStatus` = 1) is not validated against the allowed list.\n- **Item price required:** the item must have a price row in the database currency (inner join on `pixi.ItemPrice`). Otherwise item data and prices are not filled and the line may be created without EAN or price.\n- **Order header is overwritten:** `Pixi_InsertOrderline` updates the header columns `GiftMessage`, `ShipInstruct`, `Discount`, `Address_Remarks`, `Verfahren`, `Product`, `Extras`, `Shipdate` and the tax rates.\n - `GiftMessage` defaults to '' and therefore overwrites an existing gift message.\n - `ShipInstruct` is set to '' and `Shipdate` to NULL.\n- **Voucher creation:** if the resulting `Discount` > 0 and no `Voucher` row with that ID exists, a voucher is created with shop `GRM` and the order currency. The expiry is computed with `DATEADD(y, 1, …)`; datepart `y` means day of year, so it lies one day after the order date.\n- **Logging:** if `OrderNrExternal` differs from the header value, an entry is written to `LogTable`.\n- **Transaction:** the insert runs in a transaction inside `Pixi_InsertOrderline`.\n- **Order line ID:** the new ID is read from a temp table that is filled by an `INSTEAD OF` trigger on `Orderlines`. The trigger is not attached. If no ID is returned, `OrderlineId` is NULL although `CanAdd` = 1.\n- **Reads:** all reads use `NOLOCK`.\n- **Exchange rates:** rates are looked up only for the current date. If no rate exists for today, converted prices become NULL.\n\nDocumentation: https://pixi-api-docs.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": "Adds a new order line for an item to an existing order, calculates prices and discounts, and returns the new order line ID or validation errors.\n\nAdds one order line (`Orderlines` row) to the order `PixiOrderNr`.\n\n**1. Normalisation**\n- `ItemKey` = 0 is treated as NULL and `ItemNrInt` = '' as NULL.\n- An empty `Date` becomes the current date/time.\n- An empty `Status` becomes `NEW`.\n- A NULL `UsePaymentStatus` becomes 0 and a NULL `LocationID` becomes `001`.\n\n**2. Validation**\nAll failed checks are collected, and each one adds an error row:\n- `UsePaymentStatus` = 1 together with a `Status` other than `NEW` is rejected.\n- `Status` must be one of `NEW`, `ANG`, `HAL`, `FUT`, `STO`, `NLB`.\n- If `ItemNrInt` is given, the item is looked up by `ItemNrInt`. The found key replaces `ItemKey`. If no item matches, an error is raised.\n- If no error has occurred so far, the item must have an entry in `pixi.ItemCode`.\n- A non-zero `Discount` (voucher amount) requires `VoucherID`.\n- If the order already has a line with a voucher, a different `VoucherID` is rejected. Only one voucher per order is allowed.\n\nIf any check fails, the error rows are returned and nothing is written.\n\n**3. Status from payment method**\nWith `UsePaymentStatus` = 1, the line status is taken from `Payments.IniOrderStatus` of the payment method of the order's billing address.\n\n**4. Can lines be added?**\n`pipiCanAddOrderlines` checks whether the order still accepts new lines:\n- For payment methods `K`/`C`, all existing lines must be in `NEW`, `ANG`, `HAL`, `MIN`, `OPH`, `BES`, `STO` or `NLB`.\n- For other payment methods, no line may be in `EIN` or `AUS`.\n\nOnly if the result is 1 is the line created.\n\n**5. Header data**\n- Customer, addresses, order type, currency and the existing header values are read from the order.\n- `OrderNrExternal` is taken from the order header. If the header has none, the parameter is used. If that is also missing, a timestamp string is generated.\n- `Employee` is stored as ` (API)`, or as `API` if `Employee` is not given.\n\n**6. Currency**\nIf the setting `MultiCurrencyEnabled` is off, or the order has no exchange rate, the database currency is used with rate 1. Otherwise:\n- Today's exchange rates are read from `pixi.ExchRate`.\n- The database currency uses its rate source.\n- The base currency of the order's exchange rate record uses the shop's `ExchRateSourceID` as source.\n\n**7. Prices**\n- `FullPrice` (gross) and its net counterpart come from the parameter if it is non-zero.\n- Otherwise the item price is used: the price in the order currency first, then the base-currency price × rate, then the database-currency price × rate, else 0.\n- For `B2B` orders, the `FullPrice` parameter is interpreted as the net price, and the gross price is always taken from the item prices.\n- `ItemName` overrides the item name.\n\n**8. Discount per line**\n- `FullPriceDiscountValue` is used if it is given.\n- Otherwise `DiscountPercent` % of the gross price (`B2C`) or of the net price (other order types) is used.\n- Otherwise the full price minus `DiscountedPrice` is used.\n- Otherwise the discount is 0.\n\nThe same discount value is subtracted from both the gross and the net price to get `Price` and `Price_Net`.\n\n**9. Order header values**\n- `ShipCost`, `Discount`, `AddressRemarks`, `Verfahren`, `Product` and `Extras` are taken from the parameters if they are non-empty or non-zero. Otherwise the existing header values are kept.\n- An existing voucher of the order always wins over `VoucherID`.\n\n**10. Insert**\nThe line is inserted via `Pixi_InsertOrderline` with these fixed values:\n- source `I`\n- line type `ORD`\n- wait days 15\n- `LocationID` as stock location and last order location\n\nThe call then returns a row with `CanAdd` = 1 and the new `OrderlineId`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PixiOrderNr` | int | Yes | Pixi order number of the existing order. |\n| `ItemKey` | int | No | Internal item key. 0 is treated as NULL. It is replaced by the key found via `ItemNrInt` if that parameter is given. |\n| `ItemNrInt` | varchar(50) | No | Shop item number used to look up the item. An empty string is treated as NULL. |\n| `Quantity` | int | No | Quantity of the order line. |\n| `ShipCost` | money | No | Shipping cost of the line. If 0, the shipping cost of the order header is used. |\n| `LocationID` | varchar(3) | No | Stock location ID of the line. NULL becomes `001`. |\n| `GiftMessage` | varchar(8000) | No | Gift message. It is written to the order header and overwrites the existing value, including with the default empty string. |\n| `DiscountPercent` | numeric(6, 2) | No | Line discount in percent of the full price (gross for B2C, net otherwise). Used only if `FullPriceDiscountValue` is NULL. |\n| `VoucherID` | varchar(50) | No | Voucher code. Required if `Discount` is not 0. An existing voucher on the order takes precedence; a different code is rejected. |\n| `Discount` | money | No | Voucher amount for the order header. If NULL or 0, the existing header value is kept. If the resulting value is > 0, a voucher record is created if it does not exist yet. |\n| `AddressRemarks` | varchar(255) | No | Address remarks for the order header. If empty, the existing value is kept. |\n| `Verfahren` | varchar(50) | No | Value for the header field `Verfahren`. If empty, the existing value is kept. |\n| `Product` | varchar(50) | No | Value for the header field `Product`. If empty, the existing value is kept. |\n| `Extras` | varchar(50) | No | Value for the header field `Extras`. If empty, the existing value is kept. |\n| `Employee` | varchar(50) | No | Creating employee. It is stored with the suffix ` (API)`; if NULL, `API` is stored. |\n| `Date` | datetime | No | Creation date of the line (`CreateDate`/`UpdateDate`). If empty, the current date/time is used. `OrderDate` of the line is always the current time. |\n| `Status` | varchar(3) | No | Status of the new line. If empty, `NEW` is used. |\n| `UsePaymentStatus` | bit | No | If 1, the line status is taken from the initial order status of the order's payment method. It cannot be combined with a `Status` other than `NEW`. |\n| `ItemNrExternal` | varchar(50) | No | External item number stored in the line. |\n| `FullPrice` | money | No | Full gross price before discount. For B2B orders this value is used as the net price. If NULL or 0, the item price is used. |\n| `FullPriceDiscountValue` | money | No | Absolute discount per unit. It has priority over `DiscountPercent` and `DiscountedPrice`. |\n| `DiscountedPrice` | money | No | Price after discount. The discount is computed as the full price minus this value; used only if no other discount parameter is given. |\n| `ItemName` | varchar(120) | No | Item name for the line. If NULL, the item master name is used. |\n| `ItemSpecialNote` | varchar(8000) | No | Special note for the line (`oItemSpecialNote`). |\n| `OrderNrExternal` | varchar(50) | No | External order number. It is used only if the order header has none; otherwise the header value wins. Without either, a timestamp string is generated. |\n| `DF_Type` | varchar(1) | No | Direct fulfillment type, stored in `DF_type` of the line. |\n| `SerialNumber` | varchar(50) | No | Serial number stored in `SerialNr` of the line. |\n\n- **No result when lines cannot be added:** if `pipiCanAddOrderlines` returns 0 or NULL, the call returns no rows at all. This happens when the order is not found or a line is already in a blocking status. Treat an empty response as \"not added\".\n- **Duplicate error row:** the check for `UsePaymentStatus` = 1 with `Status` ≠ `NEW` runs twice, so that error appears twice in the result.\n- **Status not re-checked:** a status taken from the payment method (`UsePaymentStatus` = 1) is not validated against the allowed list.\n- **Item price required:** the item must have a price row in the database currency (inner join on `pixi.ItemPrice`). Otherwise item data and prices are not filled and the line may be created without EAN or price.\n- **Order header is overwritten:** `Pixi_InsertOrderline` updates the header columns `GiftMessage`, `ShipInstruct`, `Discount`, `Address_Remarks`, `Verfahren`, `Product`, `Extras`, `Shipdate` and the tax rates.\n - `GiftMessage` defaults to '' and therefore overwrites an existing gift message.\n - `ShipInstruct` is set to '' and `Shipdate` to NULL.\n- **Voucher creation:** if the resulting `Discount` > 0 and no `Voucher` row with that ID exists, a voucher is created with shop `GRM` and the order currency. The expiry is computed with `DATEADD(y, 1, …)`; datepart `y` means day of year, so it lies one day after the order date.\n- **Logging:** if `OrderNrExternal` differs from the header value, an entry is written to `LogTable`.\n- **Transaction:** the insert runs in a transaction inside `Pixi_InsertOrderline`.\n- **Order line ID:** the new ID is read from a temp table that is filled by an `INSTEAD OF` trigger on `Orderlines`. The trigger is not attached. If no ID is returned, `OrderlineId` is NULL although `CanAdd` = 1.\n- **Reads:** all reads use `NOLOCK`.\n- **Exchange rates:** rates are looked up only for the current date. If no rate exists for today, converted prices become NULL.\n\nDocumentation: https://pixi-api-docs.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": "Splits (breaks) an order line into two lines by moving a given quantity into a new order line, optionally with a new status.\n\nBreaks an existing order line, identified by `OrderlineKey`, into two order lines. The call is a thin wrapper around the internal procedure `GOSBreakOrderline`. All parameters are passed through unchanged.\n\nSteps:\n\n1. `GOSBreakOrderline` is executed with `OrderlineKey`, `NewQty`, `NewStatus`, `InvlineRef`, `UserName` and `BinRef`. Its internal parameters `TermID`, `LargeOrderToBreak` and `PLHKey` keep their defaults.\n2. `GOSBreakOrderline` opens a transaction, or sets a savepoint if a transaction is already open. It takes an exclusive application lock named `Orderline_` with a 5-second timeout, then calls `GOSBreakOrderline_Base` to do the actual split.\n3. The inner procedure returns a row with `Success` and `NewOrderlineKey`. The wrapper captures this row internally and does **not** pass it to the caller.\n4. If the captured `Success` value is not `1`, the call raises an error with severity 11.\n\nOn success the call returns no result set. The key of the newly created order line is not returned. Callers must find it afterwards, for example by reading the order lines of the order again.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | integer | Yes | Key of the order line to be split. Also used for the application lock name `Orderline_`. |\n| `NewQty` | integer | Yes | Quantity used for the split. It is passed to `GOSBreakOrderline_Base`; its exact meaning is defined there. |\n| `NewStatus` | varchar(3) | No | Optional order line status for the split-off line. An empty string means no explicit status is given. Valid values are checked in the inner procedure. |\n| `InvlineRef` | int | No | Optional reference to an invoice line, passed through to the split logic. `0` means no reference. |\n| `UserName` | varchar(50) | No | Name of the user performing the split, passed through to the split logic. |\n| `BinRef` | int | No | Optional reference to a bin location (Lagerplatz), passed through to the split logic. |\n\n- The split logic lives in `GOSBreakOrderline_Base`, which is not attached. The exact meaning of `NewQty` (quantity of the new line or of the remaining line), the valid values of `NewStatus`, the effect of `InvlineRef` and `BinRef`, and the tables changed cannot be derived from the available code.\n- `GOSBreakOrderline` uses an exclusive application lock per order line (`sp_getapplock`, 5-second timeout). Concurrent splits of the same line are serialized. If the lock cannot be obtained, the error `Could not obtain the lock` is raised internally.\n- Errors inside `GOSBreakOrderline` are caught. The transaction is rolled back and the error is logged via `log.InsertError`. Whether the original error then reaches the caller depends on `log.InsertError`, which is not attached.\n- The result of the inner procedure is captured with `INSERT ... EXEC`. A `ROLLBACK` inside an `INSERT ... EXEC` can itself cause a SQL Server error, so failures may surface with a different message than expected.\n- Pitfall: if the inner procedure returns no row, the check on `Success` evaluates to NULL. In that case no error is raised, even though nothing may have been split.\n\nDocumentation: https://pixi-api-docs.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": "Checks whether new order lines may still be added to an order, based on the payment type and the status of its existing order lines.\n\nDetermines for the order `PixiOrderNr` whether further order lines can be added. It sets the output parameter `CanAdd`, optionally returns a status row and also uses the value as the procedure return value.\n\nThe order header (`OrderHeader`) is joined to its address (`Addresses`, via `AddrRef`). The decision depends on the payment type column `APayment`:\n\n- **Payment type other than `K` or `C`**: `CanAdd = 1` if the order has **no** order lines with status `EIN` or `AUS`. Otherwise `0`.\n- **Payment type `K` or `C`**: `CanAdd = 1` only if **all** order lines of the order have one of the statuses `NEW`, `ANG`, `HAL`, `MIN`, `OPH`, `BES`, `STO`, `NLB`. As soon as one line has a different status, the result is `0`.\n- An order without any order lines therefore always returns `1`, provided the payment type is set.\n- If `APayment` is `NULL`, neither condition is met and the result is `0`.\n\nIf `SupressOutput = 0` (default), one row with `CanAdd`, `OrderNr` and `ErrorMessage` (always `NULL`) is returned. With `SupressOutput = 1` no result set is returned and only the output parameter and the return value carry the result.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PixiOrderNr` | int | Yes | Pixi order number (`OrderHeader.OrderNr`) of the order to check. |\n| `CanAdd` | bit | No | Output: `1` if order lines can be added, `0` if not. Keeps the passed value if the order is not found. |\n| `SupressOutput` | bit | No | Controls whether the result row is returned. |\n\n- All reads use `NOLOCK`, so the result can reflect uncommitted changes.\n- If the order does not exist (or has no matching address record), no value is assigned: `CanAdd` keeps the value the caller passed in (typically `NULL`), and the returned row shows that value. No error message is produced; `ErrorMessage` is always `NULL`. Treat a `NULL` `CanAdd` as \"order not found\".\n- `CanAdd` is declared as `OUTPUT` without a default, so it must be sent in the request (e.g. empty or `0`).\n- The column `APayment` is referenced without a table alias; it is resolved from `OrderHeader` or `Addresses`. The meaning of the payment types `K` and `C` is not defined in the code.\n- Order lines with a `NULL` status are not counted in the check for payment types `K`/`C`.\n- The procedure does not change any data.\n\nDocumentation: https://pixi-api-docs.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": "Checks whether new order lines may still be added to an order, based on the payment type and the status of its existing order lines.\n\nDetermines for the order `PixiOrderNr` whether further order lines can be added. It sets the output parameter `CanAdd`, optionally returns a status row and also uses the value as the procedure return value.\n\nThe order header (`OrderHeader`) is joined to its address (`Addresses`, via `AddrRef`). The decision depends on the payment type column `APayment`:\n\n- **Payment type other than `K` or `C`**: `CanAdd = 1` if the order has **no** order lines with status `EIN` or `AUS`. Otherwise `0`.\n- **Payment type `K` or `C`**: `CanAdd = 1` only if **all** order lines of the order have one of the statuses `NEW`, `ANG`, `HAL`, `MIN`, `OPH`, `BES`, `STO`, `NLB`. As soon as one line has a different status, the result is `0`.\n- An order without any order lines therefore always returns `1`, provided the payment type is set.\n- If `APayment` is `NULL`, neither condition is met and the result is `0`.\n\nIf `SupressOutput = 0` (default), one row with `CanAdd`, `OrderNr` and `ErrorMessage` (always `NULL`) is returned. With `SupressOutput = 1` no result set is returned and only the output parameter and the return value carry the result.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PixiOrderNr` | int | Yes | Pixi order number (`OrderHeader.OrderNr`) of the order to check. |\n| `CanAdd` | bit | No | Output: `1` if order lines can be added, `0` if not. Keeps the passed value if the order is not found. |\n| `SupressOutput` | bit | No | Controls whether the result row is returned. |\n\n- All reads use `NOLOCK`, so the result can reflect uncommitted changes.\n- If the order does not exist (or has no matching address record), no value is assigned: `CanAdd` keeps the value the caller passed in (typically `NULL`), and the returned row shows that value. No error message is produced; `ErrorMessage` is always `NULL`. Treat a `NULL` `CanAdd` as \"order not found\".\n- `CanAdd` is declared as `OUTPUT` without a default, so it must be sent in the request (e.g. empty or `0`).\n- The column `APayment` is referenced without a table alias; it is resolved from `OrderHeader` or `Addresses`. The meaning of the payment types `K` and `C` is not defined in the code.\n- Order lines with a `NULL` status are not counted in the check for payment types `K`/`C`.\n- The procedure does not change any data.\n\nDocumentation: https://pixi-api-docs.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": "Checks whether an order line can still be cancelled and returns 1 (yes) or 0 (no).\n\nScalar function that evaluates a single order line identified by `OrderlineKey`.\n\nThe order line is joined with `OrderStates` on its `Status`. The function returns `1` only if **all** of the following conditions are met:\n\n- the status of the order line is not a final state (`OrderStates.FinalState` is `N` or NULL),\n- the status of the order line is not `EIN`,\n- the order line is not referenced in `BoxItems` (not packed into a box),\n- the order line is not referenced in `InvLines` (not invoiced).\n\nIf any of these conditions fails, the function returns `0`.\n\nThe function only checks; it does not change any data.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Yes | Key of the order line to check (`Orderlines.OrderlineKey`). |\n\n- The result is `NULL` if no order line with the given key exists or if its `Status` has no matching entry in `OrderStates` (inner join).\n- All tables are read with `NOLOCK`, so the result can reflect uncommitted data.\n- The checks against `BoxItems` and `InvLines` use `NOT IN`. If `BoxItems.OrderLineRef` or `InvLines.OrderlineRef` contains NULL values, the condition never evaluates to true and the function returns `0` for every order line.\n- The function does not cancel anything; it only indicates whether a cancellation is allowed.\n\nDocumentation: https://pixi-api-docs.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": "Checks whether an order line can still be cancelled and returns 1 (yes) or 0 (no).\n\nScalar function that evaluates a single order line identified by `OrderlineKey`.\n\nThe order line is joined with `OrderStates` on its `Status`. The function returns `1` only if **all** of the following conditions are met:\n\n- the status of the order line is not a final state (`OrderStates.FinalState` is `N` or NULL),\n- the status of the order line is not `EIN`,\n- the order line is not referenced in `BoxItems` (not packed into a box),\n- the order line is not referenced in `InvLines` (not invoiced).\n\nIf any of these conditions fails, the function returns `0`.\n\nThe function only checks; it does not change any data.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Yes | Key of the order line to check (`Orderlines.OrderlineKey`). |\n\n- The result is `NULL` if no order line with the given key exists or if its `Status` has no matching entry in `OrderStates` (inner join).\n- All tables are read with `NOLOCK`, so the result can reflect uncommitted data.\n- The checks against `BoxItems` and `InvLines` use `NOT IN`. If `BoxItems.OrderLineRef` or `InvLines.OrderlineRef` contains NULL values, the condition never evaluates to true and the function returns `0` for every order line.\n- The function does not cancel anything; it only indicates whether a cancellation is allowed.\n\nDocumentation: https://pixi-api-docs.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": "Returns the status of an order line and a flag that tells whether the order line can still be cancelled.\n\nChecks whether a single order line can be cancelled and returns one row for it.\n\nThe order line given in `OrderlineKey` is read from `Orderlines` and joined with `OrderStates` on its status code. The row contains the order line key, the status code, the status text and the flag `CanCancel`.\n\n`CanCancel` is `1` only if all of these conditions are true:\n\n- the status is not a final state (`FinalState` of the status is `N` or empty),\n- the status is not `EIN`,\n- the order line is not referenced in `BoxItems` (no box item exists for it),\n- the order line is not referenced in `InvLines` (it has not been invoiced).\n\nIn every other case `CanCancel` is `0`.\n\nThe call only checks. It does not cancel anything and does not change any data.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Yes | Key of the order line to check (`Orderlines.OrderlineKey`). |\n\n- All tables are read `WITH (NOLOCK)`. The result can reflect uncommitted changes, so check again right before you cancel.\n- The result set is empty if the order line does not exist or if its status code has no entry in `OrderStates` (inner join).\n- The checks against `BoxItems` and `InvLines` use `NOT IN` subqueries. If one of these tables contains a row with an empty (`NULL`) order line reference, the condition is never true and `CanCancel` is `0` for every order line.\n\nDocumentation: https://pixi-api-docs.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": "Returns the status of an order line and a flag that tells whether the order line can still be cancelled.\n\nChecks whether a single order line can be cancelled and returns one row for it.\n\nThe order line given in `OrderlineKey` is read from `Orderlines` and joined with `OrderStates` on its status code. The row contains the order line key, the status code, the status text and the flag `CanCancel`.\n\n`CanCancel` is `1` only if all of these conditions are true:\n\n- the status is not a final state (`FinalState` of the status is `N` or empty),\n- the status is not `EIN`,\n- the order line is not referenced in `BoxItems` (no box item exists for it),\n- the order line is not referenced in `InvLines` (it has not been invoiced).\n\nIn every other case `CanCancel` is `0`.\n\nThe call only checks. It does not cancel anything and does not change any data.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Yes | Key of the order line to check (`Orderlines.OrderlineKey`). |\n\n- All tables are read `WITH (NOLOCK)`. The result can reflect uncommitted changes, so check again right before you cancel.\n- The result set is empty if the order line does not exist or if its status code has no entry in `OrderStates` (inner join).\n- The checks against `BoxItems` and `InvLines` use `NOT IN` subqueries. If one of these tables contains a row with an empty (`NULL`) order line reference, the condition is never true and `CanCancel` is `0` for every order line.\n\nDocumentation: https://pixi-api-docs.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": "Cancels all open order lines of an order by setting their status to `STO` (cancelled) or `NLB` (not deliverable).\n\nSets the status of the order lines of the order `OrderNr` to the value of `Status`.\n\n1. If `Status` is empty or `NULL`, `STO` is used.\n2. Only `STO` and `NLB` are accepted. Any other value returns a row with `ErrorMessage` and nothing is changed.\n3. The call selects the order lines of the order that meet all of these conditions:\n - the line's current status is not a final status (`OrderStates.FinalState = 'Y'`);\n - no order line of the order is referenced in `BoxItems`;\n - no order line of the order is referenced in `InvLines`.\n4. The selected lines get the new `Status`. `UpdateDate` is set to the current time and `UpdateEmp` to `API`.\n5. If at least one line was updated, the call returns a row with `SuccessfulMessage`. If no line was updated, the call returns no result set; the procedure's return code is then `1` (on success it is `0`).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Number of the order whose order lines are cancelled (`Orderlines.OrderNr`). |\n| `Status` | varchar(3) | No | New status for the order lines. Empty or `NULL` is treated as `STO`. |\n\n- **Order-wide check:** The comments in the code suggest a per-line check. However, the `BoxItems` and `InvLines` subqueries are only correlated on the order number. If **any** line of the order is already in a box or on an invoice, **no** line is cancelled, not only that one line.\n- Lines in a final status are skipped. Calling the call again for an order that is already cancelled therefore usually returns no rows.\n- If nothing was changed, no message is returned (e.g. unknown order, all lines final, lines boxed or invoiced). Callers should treat a missing `SuccessfulMessage` row as \"not cancelled\".\n- The selection reads with `NOLOCK`; the update uses `ROWLOCK`. There is no explicit transaction.\n- Only the order line statuses are changed. The order header and stock reservations are not touched directly by this procedure.\n\nDocumentation: https://pixi-api-docs.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": "Cancels all open order lines of an order by setting their status to `STO` (cancelled) or `NLB` (not deliverable).\n\nSets the status of the order lines of the order `OrderNr` to the value of `Status`.\n\n1. If `Status` is empty or `NULL`, `STO` is used.\n2. Only `STO` and `NLB` are accepted. Any other value returns a row with `ErrorMessage` and nothing is changed.\n3. The call selects the order lines of the order that meet all of these conditions:\n - the line's current status is not a final status (`OrderStates.FinalState = 'Y'`);\n - no order line of the order is referenced in `BoxItems`;\n - no order line of the order is referenced in `InvLines`.\n4. The selected lines get the new `Status`. `UpdateDate` is set to the current time and `UpdateEmp` to `API`.\n5. If at least one line was updated, the call returns a row with `SuccessfulMessage`. If no line was updated, the call returns no result set; the procedure's return code is then `1` (on success it is `0`).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Number of the order whose order lines are cancelled (`Orderlines.OrderNr`). |\n| `Status` | varchar(3) | No | New status for the order lines. Empty or `NULL` is treated as `STO`. |\n\n- **Order-wide check:** The comments in the code suggest a per-line check. However, the `BoxItems` and `InvLines` subqueries are only correlated on the order number. If **any** line of the order is already in a box or on an invoice, **no** line is cancelled, not only that one line.\n- Lines in a final status are skipped. Calling the call again for an order that is already cancelled therefore usually returns no rows.\n- If nothing was changed, no message is returned (e.g. unknown order, all lines final, lines boxed or invoiced). Callers should treat a missing `SuccessfulMessage` row as \"not cancelled\".\n- The selection reads with `NOLOCK`; the update uses `ROWLOCK`. There is no explicit transaction.\n- Only the order line statuses are changed. The order header and stock reservations are not touched directly by this procedure.\n\nDocumentation: https://pixi-api-docs.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": "Cancels a single orderline or a whole bundle orderline, or marks it as not available (`STO`/`NLB`), if it is not final, not boxed and not invoiced.\n\nSets the status of an orderline, or of a bundle orderline together with all of its orderlines, to `STO` (cancelled) or `NLB` (not available).\n\n1. `Status` defaults to `STO`; an empty value or NULL is also treated as `STO`.\n2. A value of `0` for `OrderlineKey` or `BundleOrderlineKey` counts as not sent. If neither key is sent, an error row is returned.\n3. If only `OrderlineKey` is sent and this orderline belongs to an existing bundle orderline (`BundleOrderlineRef`), the call switches to that bundle. The **whole bundle** is then processed, not just the single line.\n4. If a bundle key is known (sent or looked up), `OrderlineKey` is ignored. All orderlines with this `BundleOrderlineRef` are processed.\n5. Only orderlines that meet all of these conditions are updated:\n - their current status is not a final state in `OrderStates` (`FinalState = 'Y'`)\n - they are not packed in a box (`boxitems`)\n - they are not on an invoice line (`Invlines`)\n6. The selected orderlines get the new `Status`, `UpdateEmp = 'API'` and the current date as `UpdateDate`. The related bundle orderlines are updated in the same way.\n7. On success, a row with `SuccessfulMessage` is returned. The text depends on whether a single orderline or a bundle was cancelled.\n\nIf `Status` is not `STO` or `NLB`, or if no orderline meets the conditions, a row with `ErrorMessage` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Key of the orderline to cancel. `0` is treated as not sent. If the line belongs to a bundle, the whole bundle is processed. |\n| `Status` | varchar(3) | No | New status for the orderlines. Empty or NULL means `STO`. |\n| `BundleOrderlineKey` | int | No | Key of the bundle orderline whose orderlines are cancelled. If set, `OrderlineKey` is ignored. `0` is treated as not sent. |\n\n- The message `ONLY Status STO or NLB Allowed` is also returned when the status is valid but no orderline qualifies. This happens when the key does not exist, or when all lines are in a final state, boxed or invoiced. The text is therefore misleading in this case.\n- For bundles, only the qualifying orderlines are updated. The bundle orderline itself still gets the new status as soon as at least one of its lines qualifies. Lines that are boxed, invoiced or final keep their old status.\n- The success or error message is returned in a column whose name differs (`ErrorMessage` vs. `SuccessfulMessage`). Clients should check which column is present.\n- The checks read with `NOLOCK`. The two updates do not run in an explicit transaction.\n- The procedure's return value (0/1) is not part of the result rows.\n- The status value is written as sent. Its comparison with `STO`/`NLB` depends on the database collation.\n\nDocumentation: https://pixi-api-docs.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": "Cancels a single orderline or a whole bundle orderline, or marks it as not available (`STO`/`NLB`), if it is not final, not boxed and not invoiced.\n\nSets the status of an orderline, or of a bundle orderline together with all of its orderlines, to `STO` (cancelled) or `NLB` (not available).\n\n1. `Status` defaults to `STO`; an empty value or NULL is also treated as `STO`.\n2. A value of `0` for `OrderlineKey` or `BundleOrderlineKey` counts as not sent. If neither key is sent, an error row is returned.\n3. If only `OrderlineKey` is sent and this orderline belongs to an existing bundle orderline (`BundleOrderlineRef`), the call switches to that bundle. The **whole bundle** is then processed, not just the single line.\n4. If a bundle key is known (sent or looked up), `OrderlineKey` is ignored. All orderlines with this `BundleOrderlineRef` are processed.\n5. Only orderlines that meet all of these conditions are updated:\n - their current status is not a final state in `OrderStates` (`FinalState = 'Y'`)\n - they are not packed in a box (`boxitems`)\n - they are not on an invoice line (`Invlines`)\n6. The selected orderlines get the new `Status`, `UpdateEmp = 'API'` and the current date as `UpdateDate`. The related bundle orderlines are updated in the same way.\n7. On success, a row with `SuccessfulMessage` is returned. The text depends on whether a single orderline or a bundle was cancelled.\n\nIf `Status` is not `STO` or `NLB`, or if no orderline meets the conditions, a row with `ErrorMessage` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Key of the orderline to cancel. `0` is treated as not sent. If the line belongs to a bundle, the whole bundle is processed. |\n| `Status` | varchar(3) | No | New status for the orderlines. Empty or NULL means `STO`. |\n| `BundleOrderlineKey` | int | No | Key of the bundle orderline whose orderlines are cancelled. If set, `OrderlineKey` is ignored. `0` is treated as not sent. |\n\n- The message `ONLY Status STO or NLB Allowed` is also returned when the status is valid but no orderline qualifies. This happens when the key does not exist, or when all lines are in a final state, boxed or invoiced. The text is therefore misleading in this case.\n- For bundles, only the qualifying orderlines are updated. The bundle orderline itself still gets the new status as soon as at least one of its lines qualifies. Lines that are boxed, invoiced or final keep their old status.\n- The success or error message is returned in a column whose name differs (`ErrorMessage` vs. `SuccessfulMessage`). Clients should check which column is present.\n- The checks read with `NOLOCK`. The two updates do not run in an explicit transaction.\n- The procedure's return value (0/1) is not part of the result rows.\n- The status value is written as sent. Its comparison with `STO`/`NLB` depends on the database collation.\n\nDocumentation: https://pixi-api-docs.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": "Returns the status of an order line and whether it can still be changed or cancelled.\n\nLooks up the order line given by `OrderlineKey` in `Orderlines` and joins its status code to `OrderStates` to get the status text.\n\nThe column `CanCancel` is `1` only if all of these conditions are met:\n\n- the status is not a final state (`FinalState` of the status is `N` or not set),\n- the status is not `EIN`,\n- the order line is not referenced in any box item (`boxitems.OrderLineRef`), i.e. it has not been packed,\n- the order line is not referenced in any invoice line (`Invlines.OrderLineRef`), i.e. it has not been invoiced.\n\nOtherwise `CanCancel` is `0`.\n\nIf the order line does not exist, or its status has no entry in `OrderStates` (inner join), no row is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Yes | Key of the order line to check (`Orderlines.OrderlineKey`). |\n\nAll tables are read with `NOLOCK`, so the result can reflect uncommitted data. The call only checks; it does not change the order line. An empty result means the order line key is unknown (or its status is missing in `OrderStates`), not that it cannot be cancelled.\n\nDocumentation: https://pixi-api-docs.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": "Returns the status of an order line and whether it can still be changed or cancelled.\n\nLooks up the order line given by `OrderlineKey` in `Orderlines` and joins its status code to `OrderStates` to get the status text.\n\nThe column `CanCancel` is `1` only if all of these conditions are met:\n\n- the status is not a final state (`FinalState` of the status is `N` or not set),\n- the status is not `EIN`,\n- the order line is not referenced in any box item (`boxitems.OrderLineRef`), i.e. it has not been packed,\n- the order line is not referenced in any invoice line (`Invlines.OrderLineRef`), i.e. it has not been invoiced.\n\nOtherwise `CanCancel` is `0`.\n\nIf the order line does not exist, or its status has no entry in `OrderStates` (inner join), no row is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Yes | Key of the order line to check (`Orderlines.OrderlineKey`). |\n\nAll tables are read with `NOLOCK`, so the result can reflect uncommitted data. The call only checks; it does not change the order line. An empty result means the order line key is unknown (or its status is missing in `OrderStates`), not that it cannot be cancelled.\n\nDocumentation: https://pixi-api-docs.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": "Deletes an orderline (or the whole bundle it belongs to) and removes the order if no orderlines remain.\n\nDeletes the orderline identified by `OrderlineKey` inside one transaction.\n\n1. **Check:** the orderline must exist in `Orderlines` and have one of the statuses `HAL`, `ANG`, `STO`, `NLB` or `FUT`. Otherwise an `ERROR` row is returned and nothing is changed.\n2. **Bundle handling:** if the orderline has a `BundleOrderlineRef`, the **whole bundle** is deleted, not only the given line.\n3. **Status reset:** the orderline (or all lines of the bundle) of the same order that have no `BoxNr` are set to status `NEW` with `UpdateEmp` = `API`.\n4. **Deletion:** all affected lines in status `NEW` are detached from the order: `OrderNr`, `CustRef`, `AddrRef`, `ShipAdrRef`, `Qty`, prices, discounts and `ShipCost` are set to 0, `ItemRef`, `ShipRef`, `Order_Id` and `BundleOrderlineRef` to NULL. The bundle header in `BundleOrderlines` is deleted if it has status `NEW`. Reservations (`Reservation`) of the affected lines are deleted.\n5. **Empty order:** if the order has no orderlines left afterwards, the order header is deleted together with its entries in `PL_NotReservedOrdersCheck`, `TagMatch` and `OrderHeaderAttribute`.\n\nThe call returns exactly one row with `ReturnCode` (`OK` or `ERROR`) and a text in `ErrorMessage`. For bundles the success text names both the given orderline and the bundle key.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Yes | Key of the orderline to delete. It must be in status `HAL`, `ANG`, `STO`, `NLB` or `FUT`. If it belongs to a bundle, the whole bundle is deleted. |\n\n- All changes run in one transaction; on an error caught by the call it is rolled back and an `ERROR` row is returned.\n- The orderline rows are **not physically deleted**. They are reset (`OrderNr` = 0 etc.); according to a code comment a job removes them overnight. That job is not part of this call.\n- The status check uses `NOLOCK`, so it may read uncommitted data.\n- Triggers on `Orderlines` and `Reservation` are suppressed via `CONTEXT_INFO` during the update/delete.\n- Only the given orderline is checked for an allowed status. For bundles, all other component lines without `BoxNr` are set to `NEW` regardless of their current status and deleted. Lines that already have a `BoxNr` keep their status and are not deleted.\n- The called sub-procedures catch their own errors and write them to `log.InsertError` without re-raising. Depending on the transaction state, a failure inside them may surface as a transaction-count error in the `ERROR` row, or the call may report `OK` although the sub-step was rolled back to its savepoint.\n\nDocumentation: https://pixi-api-docs.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": "Deletes an orderline (or the whole bundle it belongs to) and removes the order if no orderlines remain.\n\nDeletes the orderline identified by `OrderlineKey` inside one transaction.\n\n1. **Check:** the orderline must exist in `Orderlines` and have one of the statuses `HAL`, `ANG`, `STO`, `NLB` or `FUT`. Otherwise an `ERROR` row is returned and nothing is changed.\n2. **Bundle handling:** if the orderline has a `BundleOrderlineRef`, the **whole bundle** is deleted, not only the given line.\n3. **Status reset:** the orderline (or all lines of the bundle) of the same order that have no `BoxNr` are set to status `NEW` with `UpdateEmp` = `API`.\n4. **Deletion:** all affected lines in status `NEW` are detached from the order: `OrderNr`, `CustRef`, `AddrRef`, `ShipAdrRef`, `Qty`, prices, discounts and `ShipCost` are set to 0, `ItemRef`, `ShipRef`, `Order_Id` and `BundleOrderlineRef` to NULL. The bundle header in `BundleOrderlines` is deleted if it has status `NEW`. Reservations (`Reservation`) of the affected lines are deleted.\n5. **Empty order:** if the order has no orderlines left afterwards, the order header is deleted together with its entries in `PL_NotReservedOrdersCheck`, `TagMatch` and `OrderHeaderAttribute`.\n\nThe call returns exactly one row with `ReturnCode` (`OK` or `ERROR`) and a text in `ErrorMessage`. For bundles the success text names both the given orderline and the bundle key.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Yes | Key of the orderline to delete. It must be in status `HAL`, `ANG`, `STO`, `NLB` or `FUT`. If it belongs to a bundle, the whole bundle is deleted. |\n\n- All changes run in one transaction; on an error caught by the call it is rolled back and an `ERROR` row is returned.\n- The orderline rows are **not physically deleted**. They are reset (`OrderNr` = 0 etc.); according to a code comment a job removes them overnight. That job is not part of this call.\n- The status check uses `NOLOCK`, so it may read uncommitted data.\n- Triggers on `Orderlines` and `Reservation` are suppressed via `CONTEXT_INFO` during the update/delete.\n- Only the given orderline is checked for an allowed status. For bundles, all other component lines without `BoxNr` are set to `NEW` regardless of their current status and deleted. Lines that already have a `BoxNr` keep their status and are not deleted.\n- The called sub-procedures catch their own errors and write them to `log.InsertError` without re-raising. Depending on the transaction state, a failure inside them may surface as a transaction-count error in the `ERROR` row, or the call may report `OK` although the sub-step was rolled back to its savepoint.\n\nDocumentation: https://pixi-api-docs.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": "Recalculates the estimated delivery dates of order lines and items for an order, a shop order number or an item, and queues changed items for export.\n\nWrapper around the internal procedure `Pixi_EstimatedDeliveryUpdates`.\n\n1. `OrderNr = 0`, `ShopOrderNr = ''` and `ItemRef = 0` are treated as NULL.\n2. If all three parameters are NULL, the call ends immediately and does nothing. A full recalculation for all items cannot be started through this call.\n3. Otherwise the internal procedure runs with the given values.\n\n**Selection of items**\n\n- `OrderNr`: items of the order lines of this Auftrag (not deleted, `OrderNr <> 0`) with status `ANG` or `HAL`, or lines that belong to a bundle line.\n- `ShopOrderNr`: the same, matched on `Orderlines.OrderNrExternal`.\n- `ItemRef`: the item itself. If it is a bundle, its components are added and the bundle is recalculated too.\n- Only non-bundle items are calculated directly. If no item is found, the procedure ends without changes.\n\n**Calculation** (setting `EstimatedDeliveryCalcUsesFIFO`)\n\n- `1` (FIFO): stock units in locations with `ParticipateInEstDelivery = 1` and open quantities of confirmed supplier order lines (`IsOrderedConfirmed = 1`, with an estimated delivery date, at participating locations) are assigned unit by unit to open order lines with status `ANG`/`HAL`. The lines are sorted by `AutoReservationDone` descending, order date and order line key. Each order line gets the date of its last assigned unit and the supplier order line used (`RealSorderlineRef`). Stock and past dates become today. The item gets the date of the next unit that is still free after all open lines, or NULL.\n- `0` (MAX) / `2` (MIN): the latest or earliest estimated delivery date of confirmed supplier order lines with a participating delivery location. It is used only if the date is after today and open quantity remains. All order lines of the item and the item itself get this date.\n- Any other value calculates nothing.\n\n**Cleanup and bundles**\n\n- Unless all three parameters are filled, existing entries in `Orderline_EstimatedDelivery` and `Item_EstimatedDelivery` (non-bundle items) that were not recalculated are set to NULL, which deletes them.\n- Bundles get the latest date of their components. If one component has no date, the bundle gets no date.\n\n**Saving**\n\n- `Item_EstimatedDelivery` and `Orderline_EstimatedDelivery` are updated with MERGE. A NULL result deletes the row, a changed value is updated with a new update date, a new item or line is inserted.\n- Changed bundles, and changed items that already have an `InvBinItemLog` entry, are written to `pixi.ItemRecalculateStockQueue` with `ForceToExport = 1`.\n- Changed items without any `InvBinItemLog` entry get a log row with quantity 0 and `UpdateEmp = 'AutoEstDelExp'`, so that they are exported.\n\nThe call returns no result set.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. Items of the open order lines of this Auftrag are recalculated. 0 is treated as NULL. |\n| `ShopOrderNr` | varchar(50) | No | External shop order number, matched on `Orderlines.OrderNrExternal`. An empty string is treated as NULL. |\n| `ItemRef` | int | No | Item key (`ItemKey`) to recalculate. For a bundle, its components are included. 0 is treated as NULL. |\n\n- **Pitfall:** the cleanup step is not limited to the selected order or item. Unless `OrderNr`, `ShopOrderNr` and `ItemRef` are all filled, every entry in `Orderline_EstimatedDelivery` and `Item_EstimatedDelivery` (non-bundle items) that was not recalculated in this run is deleted, across the whole system.\n- If no bundle is involved in the selection, all bundles in the system are recalculated from the current results.\n- In MAX/MIN mode all order lines of the item get the date, regardless of their status. In FIFO mode only open lines with status `ANG`/`HAL` are considered.\n- The calculation mode comes from the setting `EstimatedDeliveryCalcUsesFIFO`, read at runtime through `fpixi_GetSetting`. Its definition is not attached.\n- The procedure returns 0 if nothing was done and 1 otherwise. The SOAP response does not contain this return value as a row.\n- There is no explicit transaction. Reads use `NOLOCK`.\n- The FIFO mode expands quantities into single units using `dbo.Numbers`. This can be slow for large quantities.\n\nDocumentation: https://pixi-api-docs.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": "Returns order line status changes from the order history since a given date, either all changes or only the latest change per order line.\n\nReads status changes of order lines from the order history and returns them with item and order references.\n\n- Only history entries with `StatusChangeDate` >= `Since` are returned. If `Since` is `NULL`, the current date and time (`GETDATE()`) is used.\n- `WholeHistory` = `1` (default): every matching history entry is returned, so an order line can appear several times.\n- `WholeHistory` = `0`: only the entry whose `StatusChangeDate` equals the most recent `StatusChangeDate` of that order line in the whole history is returned. An order line whose latest change is older than `Since` does not appear.\n- History entries are joined to the order line and to the item (inner joins). History entries without a matching order line or item are not returned.\n- Identical rows are collapsed (`DISTINCT`).\n- The result is sorted by `StatusChangeDate` ascending.\n- `Rows` limits the number of returned rows; `0` (default) or `NULL` means no limit.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | Yes | Start of the time window. Only history entries with `StatusChangeDate` >= this value are returned. `NULL` is replaced by the current date and time. |\n| `WholeHistory` | bit | No | Controls whether all status changes or only the latest change per order line are returned. |\n| `Rows` | int | No | Maximum number of rows to return. `0` or `NULL` means no limit. |\n\n- All tables are read with `NOLOCK`, so uncommitted changes may be returned (dirty reads).\n- Passing `NULL` for `Since` effectively returns only changes made at or after the moment of the call, which is usually an empty result.\n- The row limit is implemented with `SET ROWCOUNT`; there is no offset. For incremental polling, use the highest `StatusChangeDate` of the last call as the next `Since`. Because the filter uses `>=`, rows with exactly that timestamp are returned again and must be de-duplicated by the caller (e.g. by `OrderlineKey` and `StatusChangeDate`). If more rows share the same timestamp than `Rows` allows, polling can get stuck; choose a sufficiently large `Rows` value.\n- With `WholeHistory` = `0`, several rows per order line are still possible if multiple history entries share the same latest `StatusChangeDate` with different status values.\n\nDocumentation: https://pixi-api-docs.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": "Returns order line status changes from the order history since a given date, either all changes or only the latest change per order line.\n\nReads status changes of order lines from the order history and returns them with item and order references.\n\n- Only history entries with `StatusChangeDate` >= `Since` are returned. If `Since` is `NULL`, the current date and time (`GETDATE()`) is used.\n- `WholeHistory` = `1` (default): every matching history entry is returned, so an order line can appear several times.\n- `WholeHistory` = `0`: only the entry whose `StatusChangeDate` equals the most recent `StatusChangeDate` of that order line in the whole history is returned. An order line whose latest change is older than `Since` does not appear.\n- History entries are joined to the order line and to the item (inner joins). History entries without a matching order line or item are not returned.\n- Identical rows are collapsed (`DISTINCT`).\n- The result is sorted by `StatusChangeDate` ascending.\n- `Rows` limits the number of returned rows; `0` (default) or `NULL` means no limit.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | Yes | Start of the time window. Only history entries with `StatusChangeDate` >= this value are returned. `NULL` is replaced by the current date and time. |\n| `WholeHistory` | bit | No | Controls whether all status changes or only the latest change per order line are returned. |\n| `Rows` | int | No | Maximum number of rows to return. `0` or `NULL` means no limit. |\n\n- All tables are read with `NOLOCK`, so uncommitted changes may be returned (dirty reads).\n- Passing `NULL` for `Since` effectively returns only changes made at or after the moment of the call, which is usually an empty result.\n- The row limit is implemented with `SET ROWCOUNT`; there is no offset. For incremental polling, use the highest `StatusChangeDate` of the last call as the next `Since`. Because the filter uses `>=`, rows with exactly that timestamp are returned again and must be de-duplicated by the caller (e.g. by `OrderlineKey` and `StatusChangeDate`). If more rows share the same timestamp than `Rows` allows, polling can get stuck; choose a sufficiently large `Rows` value.\n- With `WholeHistory` = `0`, several rows per order line are still possible if multiple history entries share the same latest `StatusChangeDate` with different status values.\n\nDocumentation: https://pixi-api-docs.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": "Returns order lines filtered by key, order, status, shop, payment type, dates or invoice, including prices, VAT, shipping data and available stock.\n\nReturns order lines (`Orderlines`) and bundle order lines (`BundleOrderlines`) that match all given filters, sorted by `OrderlineKey`.\n\n**Input normalisation**\n- `OrderlineKey` and `OrderNR` with value `0` and empty strings for the text and date parameters are treated as *not set*.\n- `RowCount` NULL becomes `1000`.\n- If `OrderNRExternal` contains `DROP`, `ALTER`, `DELETE`, `TRUNCATE` or `UPDATE`, the procedure returns immediately without any result set.\n\n**Filters** (combined with AND, only applied when set)\n- `OrderlineKey`, `OrderNR`, `OrderNRExternal`, `Status`: exact match on the order line.\n- `ShopID`: `CustomerOF` of the customer of the order line.\n- `PaymentType`: `APayment` of the address of the order line.\n- `OrderDateFrom`/`OrderDateTo` and `UpdateDateFrom`/`UpdateDateTo`: exclusive bounds (`>` and `<`).\n- `InvoiceNr`: only lines that appear as invoice lines of the invoice with this number.\n\n**Bundle handling** (`ShowOrderlines`)\n- `1`: bundles are not processed as normal items; all order lines, including the components of bundles, are returned.\n- `0`: bundles are processed as normal items; component lines (with a bundle reference) are skipped and the bundle line itself is returned from `BundleOrderlines`.\n- not set: taken from the setting `ProcessBundleItemsAsNormalItems` (default `0`).\n\nBundle lines are selected with the same filters; the date and invoice filters are checked against the component order lines, and the `OrderNR`/`OrderNRExternal` filters only match bundle lines when bundles are processed as normal items.\n\n**Row limit**: first up to `RowCount` normal order lines are collected (ascending `OrderlineKey`), then bundle lines fill the remaining quota. There is no offset; for paging, use `OrderlineKey` or date filters.\n\n**Computed values**\n- `FullPrice` = `Qty` × `Price`; `FullPriceForItem` is the stored full price of the line.\n- `VATRate` and `PriceNoVAT` (rounded to 2 decimals) come from the first invoice line of the order line if present, otherwise from the item VAT class (`H`, `L`, `N`) and the net price of the line.\n- `ShipDate` is the scan-out date of the invoice (or the invoice it refers to).\n- `AvailStockOrderLine` = stock quantity of the item at the order line's location minus the number of earlier reservations of the same item by order lines in active (non-final) states other than `EIN`, `FUT`, `FUS`.\n- `ReservedCount` = the smaller of `Qty` and `AvailStockOrderLine`, but not below 0.\n\nBundle lines have no shipping, stock or estimated-delivery data (NULL).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Key of a single order line; 0 means not set. |\n| `OrderNR` | int | No | Pixi order number; 0 means not set. |\n| `OrderNRExternal` | varchar(50) | No | External (shop) order number, exact match. Values containing DROP, ALTER, DELETE, TRUNCATE or UPDATE end the call without result. |\n| `Status` | varchar(3) | No | Order line status code (from `OrderStates`). |\n| `ShopID` | varchar(3) | No | Shop ID; matched against `CustomerOF` of the customer of the order line. |\n| `PaymentType` | char(1) | No | Payment type; matched against `APayment` of the address of the order line. |\n| `OrderDateFrom` | datetime | No | Only lines with order date strictly after this value. |\n| `OrderDateTo` | datetime | No | Only lines with order date strictly before this value. |\n| `UpdateDateFrom` | datetime | No | Only lines changed strictly after this value. |\n| `UpdateDateTo` | datetime | No | Only lines changed strictly before this value. |\n| `RowCount` | int | No | Maximum number of candidate lines (normal lines first, then bundle lines). NULL means 1000. |\n| `InvoiceNr` | varchar(50) | No | Only lines contained in the invoice with this number. |\n| `ShowOrderlines` | bit | No | Controls bundle handling. NULL uses the setting `ProcessBundleItemsAsNormalItems`. |\n\n- Read-only; all tables are read with `NOLOCK`, so uncommitted data may appear.\n- The filter query is built as dynamic SQL but executed with parameters via `sp_executesql`.\n- The keyword check on `OrderNRExternal` returns silently (no rows, no error) – an external order number that merely contains e.g. `UPDATE` cannot be searched.\n- `RowCount` limits the candidate lines before the final joins. Order lines without an order header, currency, item, order state or an `ItemLocationSpecific` row for their item and location are dropped, so fewer rows than `RowCount` may be returned.\n- If `ShowOrderlines` = 1 (or the setting is `0`) and no `OrderNR`/`OrderNRExternal` filter is set, bundle lines from `BundleOrderlines` can appear in addition to their component lines.\n- `ReservedCount` is NULL for bundle lines because `AvailStockOrderLine` is NULL there.\n\nDocumentation: https://pixi-api-docs.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": "Returns order lines filtered by key, order, status, shop, payment type, dates or invoice, including prices, VAT, shipping data and available stock.\n\nReturns order lines (`Orderlines`) and bundle order lines (`BundleOrderlines`) that match all given filters, sorted by `OrderlineKey`.\n\n**Input normalisation**\n- `OrderlineKey` and `OrderNR` with value `0` and empty strings for the text and date parameters are treated as *not set*.\n- `RowCount` NULL becomes `1000`.\n- If `OrderNRExternal` contains `DROP`, `ALTER`, `DELETE`, `TRUNCATE` or `UPDATE`, the procedure returns immediately without any result set.\n\n**Filters** (combined with AND, only applied when set)\n- `OrderlineKey`, `OrderNR`, `OrderNRExternal`, `Status`: exact match on the order line.\n- `ShopID`: `CustomerOF` of the customer of the order line.\n- `PaymentType`: `APayment` of the address of the order line.\n- `OrderDateFrom`/`OrderDateTo` and `UpdateDateFrom`/`UpdateDateTo`: exclusive bounds (`>` and `<`).\n- `InvoiceNr`: only lines that appear as invoice lines of the invoice with this number.\n\n**Bundle handling** (`ShowOrderlines`)\n- `1`: bundles are not processed as normal items; all order lines, including the components of bundles, are returned.\n- `0`: bundles are processed as normal items; component lines (with a bundle reference) are skipped and the bundle line itself is returned from `BundleOrderlines`.\n- not set: taken from the setting `ProcessBundleItemsAsNormalItems` (default `0`).\n\nBundle lines are selected with the same filters; the date and invoice filters are checked against the component order lines, and the `OrderNR`/`OrderNRExternal` filters only match bundle lines when bundles are processed as normal items.\n\n**Row limit**: first up to `RowCount` normal order lines are collected (ascending `OrderlineKey`), then bundle lines fill the remaining quota. There is no offset; for paging, use `OrderlineKey` or date filters.\n\n**Computed values**\n- `FullPrice` = `Qty` × `Price`; `FullPriceForItem` is the stored full price of the line.\n- `VATRate` and `PriceNoVAT` (rounded to 2 decimals) come from the first invoice line of the order line if present, otherwise from the item VAT class (`H`, `L`, `N`) and the net price of the line.\n- `ShipDate` is the scan-out date of the invoice (or the invoice it refers to).\n- `AvailStockOrderLine` = stock quantity of the item at the order line's location minus the number of earlier reservations of the same item by order lines in active (non-final) states other than `EIN`, `FUT`, `FUS`.\n- `ReservedCount` = the smaller of `Qty` and `AvailStockOrderLine`, but not below 0.\n\nBundle lines have no shipping, stock or estimated-delivery data (NULL).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Key of a single order line; 0 means not set. |\n| `OrderNR` | int | No | Pixi order number; 0 means not set. |\n| `OrderNRExternal` | varchar(50) | No | External (shop) order number, exact match. Values containing DROP, ALTER, DELETE, TRUNCATE or UPDATE end the call without result. |\n| `Status` | varchar(3) | No | Order line status code (from `OrderStates`). |\n| `ShopID` | varchar(3) | No | Shop ID; matched against `CustomerOF` of the customer of the order line. |\n| `PaymentType` | char(1) | No | Payment type; matched against `APayment` of the address of the order line. |\n| `OrderDateFrom` | datetime | No | Only lines with order date strictly after this value. |\n| `OrderDateTo` | datetime | No | Only lines with order date strictly before this value. |\n| `UpdateDateFrom` | datetime | No | Only lines changed strictly after this value. |\n| `UpdateDateTo` | datetime | No | Only lines changed strictly before this value. |\n| `RowCount` | int | No | Maximum number of candidate lines (normal lines first, then bundle lines). NULL means 1000. |\n| `InvoiceNr` | varchar(50) | No | Only lines contained in the invoice with this number. |\n| `ShowOrderlines` | bit | No | Controls bundle handling. NULL uses the setting `ProcessBundleItemsAsNormalItems`. |\n\n- Read-only; all tables are read with `NOLOCK`, so uncommitted data may appear.\n- The filter query is built as dynamic SQL but executed with parameters via `sp_executesql`.\n- The keyword check on `OrderNRExternal` returns silently (no rows, no error) – an external order number that merely contains e.g. `UPDATE` cannot be searched.\n- `RowCount` limits the candidate lines before the final joins. Order lines without an order header, currency, item, order state or an `ItemLocationSpecific` row for their item and location are dropped, so fewer rows than `RowCount` may be returned.\n- If `ShowOrderlines` = 1 (or the setting is `0`) and no `OrderNR`/`OrderNRExternal` filter is set, bundle lines from `BundleOrderlines` can appear in addition to their component lines.\n- `ReservedCount` is NULL for bundle lines because `AvailStockOrderLine` is NULL there.\n\nDocumentation: https://pixi-api-docs.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": "Returns order lines and bundle order lines with prices, VAT, stock availability, reservation, shipping and picklist data, filtered by order, item, status, shop, payment or date.\n\nReturns extended data for order lines. All filters are optional and combined with AND. Empty strings and `0` for `OrderlineKey`/`OrderNR` are treated as \"no filter\".\n\n**Item filter (`ItemXML`)**: items can be given by `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL` or `EAN`. All matching item keys are collected; only order lines of these items are returned.\n\n**Bundle handling (`ShowOrderlines`)**:\n- `1`: bundles are not treated as normal items, so the component order lines of bundles are included.\n- `0`: bundles are treated as normal items, so order lines that belong to a bundle (`BundleOrderlineRef` set) are excluded.\n- not sent / `NULL`: taken from the setting `ProcessBundleItemsAsNormalItems`.\n\n**Selection steps**:\n1. Up to `RowCount` (default 1000) rows from `Orderlines` matching the filters, ordered by `OrderlineKey`.\n2. The remaining row budget is filled with rows from `BundleOrderlines` (grouped per bundle line). Filters on `OrderNR` and `OrderNRExternal` only match bundle lines if bundles are processed as normal items; date and invoice filters are applied to the component order lines.\n\n**Key filter**: with `IsStartKey = 0`, `OrderlineKey` returns exactly this line; with `IsStartKey = 1`, all lines with `OrderlineKey >=` the given value, which allows paging together with `RowCount`.\n\n**Other filters**: `Status` (order line status), `ShopID` (customer's shop), `PaymentType` (payment type of the address), `OrderDateFrom`/`OrderDateTo` and `UpdateDateFrom`/`UpdateDateTo` (exclusive bounds), `InvoiceNr` (line is contained in this invoice).\n\n**Replacements (`IsReplacementOnly = 1`)**: only order lines with status `MIN` or with a `MIN` entry in the order history are returned.\n\n**Calculated values**:\n- `AvailStockOrderLine`: stock quantity of the item at the line's location minus the number of earlier reservations for the same item among the selected lines (only lines in non-final states other than `EIN`, `FUT`, `FUS` are ranked).\n- `ReservedCount`: the smaller of `Qty` and `AvailStockOrderLine`, at least 0.\n- `VATRate`, `PriceNoVAT`, `ShipDate` come from the first invoice line of the order line if there is one, otherwise from the order line and item.\n\nThe result is sorted by `OrderlineKey`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Order line key. Exact match or start key depending on `IsStartKey`. `0` means no filter. |\n| `OrderNR` | int | No | Pixi order number. `0` means no filter. |\n| `OrderNRExternal` | varchar(50) | No | External (shop) order number. |\n| `Status` | varchar(3) | No | Order line status code. |\n| `ShopID` | varchar(3) | No | Shop ID; filters on the shop of the customer (`CustomerOF`). |\n| `PaymentType` | char(1) | No | Payment type of the order address (`APayment`). |\n| `OrderDateFrom` | datetime | No | Only lines with order date after this value (exclusive). |\n| `OrderDateTo` | datetime | No | Only lines with order date before this value (exclusive). |\n| `UpdateDateFrom` | datetime | No | Only lines updated after this value (exclusive). |\n| `UpdateDateTo` | datetime | No | Only lines updated before this value (exclusive). |\n| `RowCount` | int | No | Maximum number of selected lines (order lines first, then bundle lines). NULL means 1000. |\n| `InvoiceNr` | varchar(50) | No | Only lines contained in the invoice with this number. |\n| `ShowOrderlines` | bit | No | Controls how bundle component lines are handled. |\n| `IsStartKey` | bit | No | Defines how `OrderlineKey` is compared. |\n| `ItemXML` | varchar(max) | No | Optional list of items to filter by; each `ITEM` may contain `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL` or `EAN`. |\n| `IsReplacementOnly` | bit | No | Restricts normal order lines to replacement lines. |\n\n- All reads use `NOLOCK`; results may contain uncommitted data.\n- The selection is built as dynamic SQL. The row limit comes from `RowCount` (NULL becomes 1000); the `RowCount` parameter itself is not used otherwise.\n- If `ItemXML` is sent but none of the given items can be resolved, **no item filter is applied** and lines of all items are returned.\n- Invalid XML in `ItemXML` causes an SQL error from `sp_xml_preparedocument`.\n- For bundle lines the key filter is always an exact match (`IsStartKey` is ignored there).\n- `IsReplacementOnly` only restricts normal order lines; selected bundle lines are still returned.\n- Normal order lines are only returned if an `ItemLocationSpecific` record exists for the item and the line's `LocationID`, and if the order header and its currency exist.\n- An order line on several picklists appears once per picklist (`PicklistNr`).\n- For bundle lines `ShipDate`, `DFShipDate`, `DFShipmentTrackingID`, `AvailStockOrderLine`, `EstimatedDelivery` and therefore `ReservedCount` are NULL; `OrderDate`/`UpdateDate` come from one of the component lines.\n\nDocumentation: https://pixi-api-docs.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": "Returns order lines and bundle order lines with prices, VAT, stock availability, reservation, shipping and picklist data, filtered by order, item, status, shop, payment or date.\n\nReturns extended data for order lines. All filters are optional and combined with AND. Empty strings and `0` for `OrderlineKey`/`OrderNR` are treated as \"no filter\".\n\n**Item filter (`ItemXML`)**: items can be given by `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL` or `EAN`. All matching item keys are collected; only order lines of these items are returned.\n\n**Bundle handling (`ShowOrderlines`)**:\n- `1`: bundles are not treated as normal items, so the component order lines of bundles are included.\n- `0`: bundles are treated as normal items, so order lines that belong to a bundle (`BundleOrderlineRef` set) are excluded.\n- not sent / `NULL`: taken from the setting `ProcessBundleItemsAsNormalItems`.\n\n**Selection steps**:\n1. Up to `RowCount` (default 1000) rows from `Orderlines` matching the filters, ordered by `OrderlineKey`.\n2. The remaining row budget is filled with rows from `BundleOrderlines` (grouped per bundle line). Filters on `OrderNR` and `OrderNRExternal` only match bundle lines if bundles are processed as normal items; date and invoice filters are applied to the component order lines.\n\n**Key filter**: with `IsStartKey = 0`, `OrderlineKey` returns exactly this line; with `IsStartKey = 1`, all lines with `OrderlineKey >=` the given value, which allows paging together with `RowCount`.\n\n**Other filters**: `Status` (order line status), `ShopID` (customer's shop), `PaymentType` (payment type of the address), `OrderDateFrom`/`OrderDateTo` and `UpdateDateFrom`/`UpdateDateTo` (exclusive bounds), `InvoiceNr` (line is contained in this invoice).\n\n**Replacements (`IsReplacementOnly = 1`)**: only order lines with status `MIN` or with a `MIN` entry in the order history are returned.\n\n**Calculated values**:\n- `AvailStockOrderLine`: stock quantity of the item at the line's location minus the number of earlier reservations for the same item among the selected lines (only lines in non-final states other than `EIN`, `FUT`, `FUS` are ranked).\n- `ReservedCount`: the smaller of `Qty` and `AvailStockOrderLine`, at least 0.\n- `VATRate`, `PriceNoVAT`, `ShipDate` come from the first invoice line of the order line if there is one, otherwise from the order line and item.\n\nThe result is sorted by `OrderlineKey`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Order line key. Exact match or start key depending on `IsStartKey`. `0` means no filter. |\n| `OrderNR` | int | No | Pixi order number. `0` means no filter. |\n| `OrderNRExternal` | varchar(50) | No | External (shop) order number. |\n| `Status` | varchar(3) | No | Order line status code. |\n| `ShopID` | varchar(3) | No | Shop ID; filters on the shop of the customer (`CustomerOF`). |\n| `PaymentType` | char(1) | No | Payment type of the order address (`APayment`). |\n| `OrderDateFrom` | datetime | No | Only lines with order date after this value (exclusive). |\n| `OrderDateTo` | datetime | No | Only lines with order date before this value (exclusive). |\n| `UpdateDateFrom` | datetime | No | Only lines updated after this value (exclusive). |\n| `UpdateDateTo` | datetime | No | Only lines updated before this value (exclusive). |\n| `RowCount` | int | No | Maximum number of selected lines (order lines first, then bundle lines). NULL means 1000. |\n| `InvoiceNr` | varchar(50) | No | Only lines contained in the invoice with this number. |\n| `ShowOrderlines` | bit | No | Controls how bundle component lines are handled. |\n| `IsStartKey` | bit | No | Defines how `OrderlineKey` is compared. |\n| `ItemXML` | varchar(max) | No | Optional list of items to filter by; each `ITEM` may contain `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL` or `EAN`. |\n| `IsReplacementOnly` | bit | No | Restricts normal order lines to replacement lines. |\n\n- All reads use `NOLOCK`; results may contain uncommitted data.\n- The selection is built as dynamic SQL. The row limit comes from `RowCount` (NULL becomes 1000); the `RowCount` parameter itself is not used otherwise.\n- If `ItemXML` is sent but none of the given items can be resolved, **no item filter is applied** and lines of all items are returned.\n- Invalid XML in `ItemXML` causes an SQL error from `sp_xml_preparedocument`.\n- For bundle lines the key filter is always an exact match (`IsStartKey` is ignored there).\n- `IsReplacementOnly` only restricts normal order lines; selected bundle lines are still returned.\n- Normal order lines are only returned if an `ItemLocationSpecific` record exists for the item and the line's `LocationID`, and if the order header and its currency exist.\n- An order line on several picklists appears once per picklist (`PicklistNr`).\n- For bundle lines `ShipDate`, `DFShipDate`, `DFShipmentTrackingID`, `AvailStockOrderLine`, `EstimatedDelivery` and therefore `ReservedCount` are NULL; `OrderDate`/`UpdateDate` come from one of the component lines.\n\nDocumentation: https://pixi-api-docs.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": "Returns the status change history of a single order line, sorted chronologically.\n\nReads all entries from the `orderhistory` table that belong to the order line given in `OrderlineKey` (column `OrderLineRef`).\n\nFor each status change the call returns:\n- the date of the change,\n- the status that was set,\n- the user who made the change,\n- whether the customer was notified,\n- the key of the history entry.\n\nRows are sorted by `StatusChangeDate` ascending, so the oldest change comes first. If the order line has no history entries or does not exist, an empty result set is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Yes | Key of the order line whose status history is returned (matched against `OrderLineRef` in `orderhistory`). |\n\n- The table is read with `NOLOCK`, so uncommitted changes may be visible.\n- No error is raised for an unknown order line key; the result is simply empty.\n- The column `UpdateEmp` is returned as `UpdateUser` and `OrderHistKey` as `OrderlineHistKey`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the status change history of a single order line, sorted chronologically.\n\nReads all entries from the `orderhistory` table that belong to the order line given in `OrderlineKey` (column `OrderLineRef`).\n\nFor each status change the call returns:\n- the date of the change,\n- the status that was set,\n- the user who made the change,\n- whether the customer was notified,\n- the key of the history entry.\n\nRows are sorted by `StatusChangeDate` ascending, so the oldest change comes first. If the order line has no history entries or does not exist, an empty result set is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Yes | Key of the order line whose status history is returned (matched against `OrderLineRef` in `orderhistory`). |\n\n- The table is read with `NOLOCK`, so uncommitted changes may be visible.\n- No error is raised for an unknown order line key; the result is simply empty.\n- The column `UpdateEmp` is returned as `UpdateUser` and `OrderHistKey` as `OrderlineHistKey`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the orderlines of one or more orders, optionally with bundle orderlines collapsed into a single line, including stock, invoice and shipping data.\n\nCollects the orders to read and returns their orderlines in a single result set.\n\n**Order selection**\n- The order with `OrderNr` = `@OrderNr` is always included (if it exists).\n- If `@OrderXML` is given, every `/ORDERS/ORDER` element is read (element-centric) with the child elements `ORDERNR` and `ORDERNREXTERNAL`. Each order whose `OrderNr` matches `ORDERNR` **or** whose `OrderNrExternal` matches `ORDERNREXTERNAL` is added.\n\n**Bundle mode**\n- `@ReturnBundle` decides the mode. If it is `NULL`, the setting `APIBundleOrderlines` is used (missing setting = `0`).\n- `0`: every orderline is returned with its own values (`ArtName`, `Qty`, `Price`, `Status`, ...).\n- `1`: orderlines that belong to a bundle (`BundleOrderlineRef` set) are collapsed to one row per bundle (the line with the lowest `OrderlineKey`). Name, quantity, price, external numbers, dates, item, note, discounts, amount, tax rate and net price are taken from the bundle orderline (`BundleOrderlines`) where available. The status of the bundle is computed from all its orderlines depending on the setting `APIBundleOneAllAUS`: with `1` the common status is returned if all lines have the same status, otherwise the status with the lowest `OrderStateKey`; with `0` the status with the highest `OrderStateKey` is returned.\n\n**Calculated columns**\n- `StatusText`: text of the status from `OrderStates`.\n- `OrderCurrency`: currency code (`CodeA`) of the order.\n- `VATRate`: `H` if the tax rate of the invoice line (or bundle) equals the order's `TaxRateHigh`, `L` if it equals `TaxRateLow`, otherwise `N` (also when no invoice line exists).\n- `PriceNoVAT`: net price of the invoice line (or bundle), rounded to 2 decimals.\n- `AvailStockOrderLine`: available quantity of the item at the orderline's location (location quantity minus open reservations of the item).\n- `ReservedCount`: the smaller of `Qty` and `AvailStockOrderLine`, but not below 0.\n- `ShipDate`: `ScanOutDate` of the related invoice.\n\nThe result has no explicit sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Pixi order number (`OrderHeader.OrderNr`) whose orderlines are returned. |\n| `OrderXML` | varchar(max) | No | Optional XML with further orders, matched by `ORDERNR` or `ORDERNREXTERNAL`. |\n| `ReturnBundle` | bit | No | Controls whether bundle orderlines are collapsed. `NULL` uses the setting `APIBundleOrderlines`. |\n\n- All tables are read `WITH (NOLOCK)`; uncommitted data may be returned.\n- `@OrderNr` has no default and must always be sent. When only `@OrderXML` is used, a non-existing number (e.g. `0`) can be passed.\n- If the same order is selected both by `@OrderNr` and by `@OrderXML`, its key is added twice and its orderlines appear twice in the result.\n- Orderlines with several invoice lines with `ItemQty` >= 0 can appear more than once (one row per invoice line). Invoice lines with negative quantity (returns) are ignored.\n- In bundle mode only lines with `BundleOrderlineRef IS NULL` or the first line of a partition are returned. If non-bundle orderlines store `0` instead of `NULL` in `BundleOrderlineRef`, they would be grouped together and only one of them returned; this depends on the data, which is not visible in the code.\n- `AvailStockOrderLine` subtracts the number of reservation rows of the item across all orders (open states except `EIN`, `FUT`, `FUS`), not per location. It is `NULL` if the item has no `ItemLocationSpecific` row for the location; then `ReservedCount` is also `NULL`.\n- `PriceNoVAT` is `NULL` for orderlines that are not yet invoiced (unless taken from a bundle orderline).\n- Invalid XML in `@OrderXML` causes an SQL error from `sp_xml_preparedocument`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the orderlines of one or more orders, optionally with bundle orderlines collapsed into a single line, including stock, invoice and shipping data.\n\nCollects the orders to read and returns their orderlines in a single result set.\n\n**Order selection**\n- The order with `OrderNr` = `@OrderNr` is always included (if it exists).\n- If `@OrderXML` is given, every `/ORDERS/ORDER` element is read (element-centric) with the child elements `ORDERNR` and `ORDERNREXTERNAL`. Each order whose `OrderNr` matches `ORDERNR` **or** whose `OrderNrExternal` matches `ORDERNREXTERNAL` is added.\n\n**Bundle mode**\n- `@ReturnBundle` decides the mode. If it is `NULL`, the setting `APIBundleOrderlines` is used (missing setting = `0`).\n- `0`: every orderline is returned with its own values (`ArtName`, `Qty`, `Price`, `Status`, ...).\n- `1`: orderlines that belong to a bundle (`BundleOrderlineRef` set) are collapsed to one row per bundle (the line with the lowest `OrderlineKey`). Name, quantity, price, external numbers, dates, item, note, discounts, amount, tax rate and net price are taken from the bundle orderline (`BundleOrderlines`) where available. The status of the bundle is computed from all its orderlines depending on the setting `APIBundleOneAllAUS`: with `1` the common status is returned if all lines have the same status, otherwise the status with the lowest `OrderStateKey`; with `0` the status with the highest `OrderStateKey` is returned.\n\n**Calculated columns**\n- `StatusText`: text of the status from `OrderStates`.\n- `OrderCurrency`: currency code (`CodeA`) of the order.\n- `VATRate`: `H` if the tax rate of the invoice line (or bundle) equals the order's `TaxRateHigh`, `L` if it equals `TaxRateLow`, otherwise `N` (also when no invoice line exists).\n- `PriceNoVAT`: net price of the invoice line (or bundle), rounded to 2 decimals.\n- `AvailStockOrderLine`: available quantity of the item at the orderline's location (location quantity minus open reservations of the item).\n- `ReservedCount`: the smaller of `Qty` and `AvailStockOrderLine`, but not below 0.\n- `ShipDate`: `ScanOutDate` of the related invoice.\n\nThe result has no explicit sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Pixi order number (`OrderHeader.OrderNr`) whose orderlines are returned. |\n| `OrderXML` | varchar(max) | No | Optional XML with further orders, matched by `ORDERNR` or `ORDERNREXTERNAL`. |\n| `ReturnBundle` | bit | No | Controls whether bundle orderlines are collapsed. `NULL` uses the setting `APIBundleOrderlines`. |\n\n- All tables are read `WITH (NOLOCK)`; uncommitted data may be returned.\n- `@OrderNr` has no default and must always be sent. When only `@OrderXML` is used, a non-existing number (e.g. `0`) can be passed.\n- If the same order is selected both by `@OrderNr` and by `@OrderXML`, its key is added twice and its orderlines appear twice in the result.\n- Orderlines with several invoice lines with `ItemQty` >= 0 can appear more than once (one row per invoice line). Invoice lines with negative quantity (returns) are ignored.\n- In bundle mode only lines with `BundleOrderlineRef IS NULL` or the first line of a partition are returned. If non-bundle orderlines store `0` instead of `NULL` in `BundleOrderlineRef`, they would be grouped together and only one of them returned; this depends on the data, which is not visible in the code.\n- `AvailStockOrderLine` subtracts the number of reservation rows of the item across all orders (open states except `EIN`, `FUT`, `FUS`), not per location. It is `NULL` if the item has no `ItemLocationSpecific` row for the location; then `ReservedCount` is also `NULL`.\n- `PriceNoVAT` is `NULL` for orderlines that are not yet invoiced (unless taken from a bundle orderline).\n- Invalid XML in `@OrderXML` causes an SQL error from `sp_xml_preparedocument`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the descriptive text for an object code; currently only order line status codes (`ORDERLINE_STATUS`) are supported.\n\nScalar function that translates a code into its text.\n\n- If `ObjectType` equals `ORDERLINE_STATUS` (case-insensitive, compared via `UPPER`), the function looks up the row in `OrderStates` whose `State` matches `ObjectId` and returns its `StateText`.\n- For any other `ObjectType`, or if no matching status exists, the function returns `NULL`.\n\nThe result is a single value of type `varchar(1024)`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ObjectType` | varchar(100) | Yes | Type of the object whose text is requested. Compared case-insensitively. |\n| `ObjectId` | varchar(100) | Yes | Code of the object, for `ORDERLINE_STATUS` the status code (`State`) of the order line. |\n\n- The lookup uses `NOLOCK`, so uncommitted data may be read.\n- `ObjectId` is passed as `varchar(100)` and compared to `State`; implicit conversion depends on the column type of `State`, which is not visible in the code.\n- If several rows match, the value of the last row read is returned (variable assignment in `SELECT`).\n\nDocumentation: https://pixi-api-docs.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": "Returns the descriptive text for an object code; currently only order line status codes (`ORDERLINE_STATUS`) are supported.\n\nScalar function that translates a code into its text.\n\n- If `ObjectType` equals `ORDERLINE_STATUS` (case-insensitive, compared via `UPPER`), the function looks up the row in `OrderStates` whose `State` matches `ObjectId` and returns its `StateText`.\n- For any other `ObjectType`, or if no matching status exists, the function returns `NULL`.\n\nThe result is a single value of type `varchar(1024)`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ObjectType` | varchar(100) | Yes | Type of the object whose text is requested. Compared case-insensitively. |\n| `ObjectId` | varchar(100) | Yes | Code of the object, for `ORDERLINE_STATUS` the status code (`State`) of the order line. |\n\n- The lookup uses `NOLOCK`, so uncommitted data may be read.\n- `ObjectId` is passed as `varchar(100)` and compared to `State`; implicit conversion depends on the column type of `State`, which is not visible in the code.\n- If several rows match, the value of the last row read is returned (variable assignment in `SELECT`).\n\nDocumentation: https://pixi-api-docs.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": "Returns bundle order lines from `BundleOrderlines`, filtered by create and/or update date and paged by key.\n\nReads bundle order lines (the bundle header lines of orders) from the table `BundleOrderlines`, using keyset paging.\n\n**Selection of candidates.** Only the first matching filter group is applied, in this priority:\n\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: lines whose `CreateDate` **or** `UpdateDate` lies in the range.\n2. `CreateDateFrom` / `CreateDateTo`: lines whose `CreateDate` lies in the range.\n3. `UpdateDateFrom` / `UpdateDateTo`: lines whose `UpdateDate` lies in the range.\n4. No date filter: all lines.\n\nWithin a date group, a missing *From* value defaults to two years before the current date, and a missing *To* value defaults to the current date and time. The ranges are inclusive (`BETWEEN`).\n\n**Paging.** In every case only lines with `BundleOrderlineKey` > `OrderlineKey` are returned. `OrderlineKey` defaults to `0`. At most `RowCount` lines are returned (default `1000`), ordered by `BundleOrderlineKey` ascending. To read the next page, pass the highest `OrderlineKey` of the previous page.\n\nThe result is one result set with selected columns of `BundleOrderlines`, sorted by `OrderlineKey` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Paging cursor: only lines with a key greater than this value are returned. NULL is treated as `0`. |\n| `CreateDateFrom` | datetime | No | Start of the create date range. Used only if no create-and-update range is given. If only the end is set, defaults to two years ago. |\n| `CreateDateTo` | datetime | No | End of the create date range (inclusive). If only the start is set, defaults to the current date and time. |\n| `UpdateDateFrom` | datetime | No | Start of the update date range. Used only if neither a create-and-update nor a create date range is given. If only the end is set, defaults to two years ago. |\n| `UpdateDateTo` | datetime | No | End of the update date range (inclusive). If only the start is set, defaults to the current date and time. |\n| `CreateAndUpdateDateFrom` | datetime | No | Start of a range matched against `CreateDate` or `UpdateDate`. Takes priority over all other date filters. If only the end is set, defaults to two years ago. |\n| `CreateAndUpdateDateTo` | datetime | No | End of the combined create/update range (inclusive). If only the start is set, defaults to the current date and time. |\n| `RowCount` | int | No | Maximum number of lines returned per call. NULL is treated as `1000`. |\n\n- `OrderlineKey` is **not** an exact-match filter. Because a NULL value is replaced by `0` and `RowCount` by `1000` at the start, the code branch for reading a single key is never reached. To read exactly one line with key *n*, pass `OrderlineKey` = *n*-1 and `RowCount` = `1`.\n- Passing `RowCount` as NULL is treated as `1000`.\n- All reads use `NOLOCK`, so uncommitted data can be returned and rows may be missed or duplicated while data changes concurrently.\n- Date defaults use the server time (`GETDATE()`); without any *From* value, lines older than two years are not returned by the date filters.\n- Column data types are not visible in the code; they come from the table `BundleOrderlines`.\n\nDocumentation: https://pixi-api-docs.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": "Returns bundle order lines from `BundleOrderlines`, filtered by create and/or update date and paged by key.\n\nReads bundle order lines (the bundle header lines of orders) from the table `BundleOrderlines`, using keyset paging.\n\n**Selection of candidates.** Only the first matching filter group is applied, in this priority:\n\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: lines whose `CreateDate` **or** `UpdateDate` lies in the range.\n2. `CreateDateFrom` / `CreateDateTo`: lines whose `CreateDate` lies in the range.\n3. `UpdateDateFrom` / `UpdateDateTo`: lines whose `UpdateDate` lies in the range.\n4. No date filter: all lines.\n\nWithin a date group, a missing *From* value defaults to two years before the current date, and a missing *To* value defaults to the current date and time. The ranges are inclusive (`BETWEEN`).\n\n**Paging.** In every case only lines with `BundleOrderlineKey` > `OrderlineKey` are returned. `OrderlineKey` defaults to `0`. At most `RowCount` lines are returned (default `1000`), ordered by `BundleOrderlineKey` ascending. To read the next page, pass the highest `OrderlineKey` of the previous page.\n\nThe result is one result set with selected columns of `BundleOrderlines`, sorted by `OrderlineKey` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Paging cursor: only lines with a key greater than this value are returned. NULL is treated as `0`. |\n| `CreateDateFrom` | datetime | No | Start of the create date range. Used only if no create-and-update range is given. If only the end is set, defaults to two years ago. |\n| `CreateDateTo` | datetime | No | End of the create date range (inclusive). If only the start is set, defaults to the current date and time. |\n| `UpdateDateFrom` | datetime | No | Start of the update date range. Used only if neither a create-and-update nor a create date range is given. If only the end is set, defaults to two years ago. |\n| `UpdateDateTo` | datetime | No | End of the update date range (inclusive). If only the start is set, defaults to the current date and time. |\n| `CreateAndUpdateDateFrom` | datetime | No | Start of a range matched against `CreateDate` or `UpdateDate`. Takes priority over all other date filters. If only the end is set, defaults to two years ago. |\n| `CreateAndUpdateDateTo` | datetime | No | End of the combined create/update range (inclusive). If only the start is set, defaults to the current date and time. |\n| `RowCount` | int | No | Maximum number of lines returned per call. NULL is treated as `1000`. |\n\n- `OrderlineKey` is **not** an exact-match filter. Because a NULL value is replaced by `0` and `RowCount` by `1000` at the start, the code branch for reading a single key is never reached. To read exactly one line with key *n*, pass `OrderlineKey` = *n*-1 and `RowCount` = `1`.\n- Passing `RowCount` as NULL is treated as `1000`.\n- All reads use `NOLOCK`, so uncommitted data can be returned and rows may be missed or duplicated while data changes concurrently.\n- Date defaults use the server time (`GETDATE()`); without any *From* value, lines older than two years are not returned by the date filters.\n- Column data types are not visible in the code; they come from the table `BundleOrderlines`.\n\nDocumentation: https://pixi-api-docs.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": "Returns order lines from `Orderlines`, selected by key, key range or creation/update date range, with currency, exchange rate, shipping cost and estimated delivery.\n\nReads order lines (Auftragspositionen) in one of several selection modes. A missing `OrderlineKey` is treated as `0`. The first mode that applies is used:\n\n1. **Created or updated** – if `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` is set: lines with `OrderlineKey` > `OrderlineKey` whose `CreateDate` **or** `UpdateDate` lies in the range.\n2. **Created** – else if `CreateDateFrom` or `CreateDateTo` is set: lines with key > `OrderlineKey` whose `CreateDate` lies in the range.\n3. **Updated** – else if `UpdateDateFrom` or `UpdateDateTo` is set: lines with key > `OrderlineKey` whose `UpdateDate` lies in the range.\n4. **Key range** – else if `RowCount` is passed (any value, including `0`): all lines with key > `OrderlineKey`.\n5. **Single line** – otherwise: the line with exactly `OrderlineKey`.\n\nIn the date modes a missing lower bound defaults to 10 years before the current server time, a missing upper bound to the current server time (`GETDATE()`). Bounds are inclusive (`BETWEEN`).\n\nIf `RowCount` > 0, the number of rows is limited to `RowCount`, taking the lowest keys first. The result is sorted by `OrderlineKey` ascending. This allows keyset paging: pass the last returned `OrderlineKey` as `OrderlineKey` in the next call.\n\nEach line is joined with its order header (`OrderHeader`), the order's exchange rate and currency, and optionally with `Orderline_EstimatedDelivery`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | In single-line mode the key of the line to return; in all other modes only lines with a greater key are returned (paging start). `NULL` is treated as `0`. |\n| `CreateDateFrom` | datetime | No | Lower bound for `CreateDate` (inclusive). Defaults to 10 years ago if only the upper bound is set. |\n| `CreateDateTo` | datetime | No | Upper bound for `CreateDate` (inclusive). Defaults to the current server time if only the lower bound is set. |\n| `UpdateDateFrom` | datetime | No | Lower bound for `UpdateDate` (inclusive). Used only if no create or create-and-update filter is set. |\n| `UpdateDateTo` | datetime | No | Upper bound for `UpdateDate` (inclusive). Defaults to the current server time. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound; lines whose `CreateDate` or `UpdateDate` lies in the range are returned. Has priority over all other date filters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound for the combined create/update filter. Defaults to the current server time. |\n| `RowCount` | int | No | Maximum number of rows if > 0. If passed without date filters, switches to key-range mode (all lines with key > `OrderlineKey`). |\n\n- All tables are read `WITH (NOLOCK)`; uncommitted or inconsistent data can be returned.\n- The limit is applied with `SET ROWCOUNT`, which affects both the candidate selection and the final query.\n- Lines are only returned if their order header, exchange rate (`pixi.ExchRate`) and currency (`pixi.Currency`) exist (inner joins). A page can therefore contain fewer than `RowCount` rows even though more data follows; continue paging from the last key, and stop only when no row is returned.\n- If `Orderline_EstimatedDelivery` holds more than one row per order line, the line appears several times.\n- Passing `RowCount = 0` without date filters returns **all** lines above `OrderlineKey` without a limit.\n- Calling without any parameter looks up `OrderlineKey = 0` and normally returns no rows.\n- Date filters have priority over each other in the order listed; only one date mode is used per call.\n- `Price_OrderCurr` equals `Price`, `ShipCost_OrderCurr` equals `ShipCost`, `Price_OrderCurr_Set` and `ShipCost_OrderCurr_Set` are always `0`, `SOrderlineRef` is always `NULL`. Code comments mark the `_OrderCurr` columns for removal.\n- `ShipCost` is the shipping cost of the whole order header and is repeated on every line of the order.\n\nDocumentation: https://pixi-api-docs.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": "Returns order lines from `Orderlines`, selected by key, key range or creation/update date range, with currency, exchange rate, shipping cost and estimated delivery.\n\nReads order lines (Auftragspositionen) in one of several selection modes. A missing `OrderlineKey` is treated as `0`. The first mode that applies is used:\n\n1. **Created or updated** – if `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` is set: lines with `OrderlineKey` > `OrderlineKey` whose `CreateDate` **or** `UpdateDate` lies in the range.\n2. **Created** – else if `CreateDateFrom` or `CreateDateTo` is set: lines with key > `OrderlineKey` whose `CreateDate` lies in the range.\n3. **Updated** – else if `UpdateDateFrom` or `UpdateDateTo` is set: lines with key > `OrderlineKey` whose `UpdateDate` lies in the range.\n4. **Key range** – else if `RowCount` is passed (any value, including `0`): all lines with key > `OrderlineKey`.\n5. **Single line** – otherwise: the line with exactly `OrderlineKey`.\n\nIn the date modes a missing lower bound defaults to 10 years before the current server time, a missing upper bound to the current server time (`GETDATE()`). Bounds are inclusive (`BETWEEN`).\n\nIf `RowCount` > 0, the number of rows is limited to `RowCount`, taking the lowest keys first. The result is sorted by `OrderlineKey` ascending. This allows keyset paging: pass the last returned `OrderlineKey` as `OrderlineKey` in the next call.\n\nEach line is joined with its order header (`OrderHeader`), the order's exchange rate and currency, and optionally with `Orderline_EstimatedDelivery`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | In single-line mode the key of the line to return; in all other modes only lines with a greater key are returned (paging start). `NULL` is treated as `0`. |\n| `CreateDateFrom` | datetime | No | Lower bound for `CreateDate` (inclusive). Defaults to 10 years ago if only the upper bound is set. |\n| `CreateDateTo` | datetime | No | Upper bound for `CreateDate` (inclusive). Defaults to the current server time if only the lower bound is set. |\n| `UpdateDateFrom` | datetime | No | Lower bound for `UpdateDate` (inclusive). Used only if no create or create-and-update filter is set. |\n| `UpdateDateTo` | datetime | No | Upper bound for `UpdateDate` (inclusive). Defaults to the current server time. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound; lines whose `CreateDate` or `UpdateDate` lies in the range are returned. Has priority over all other date filters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound for the combined create/update filter. Defaults to the current server time. |\n| `RowCount` | int | No | Maximum number of rows if > 0. If passed without date filters, switches to key-range mode (all lines with key > `OrderlineKey`). |\n\n- All tables are read `WITH (NOLOCK)`; uncommitted or inconsistent data can be returned.\n- The limit is applied with `SET ROWCOUNT`, which affects both the candidate selection and the final query.\n- Lines are only returned if their order header, exchange rate (`pixi.ExchRate`) and currency (`pixi.Currency`) exist (inner joins). A page can therefore contain fewer than `RowCount` rows even though more data follows; continue paging from the last key, and stop only when no row is returned.\n- If `Orderline_EstimatedDelivery` holds more than one row per order line, the line appears several times.\n- Passing `RowCount = 0` without date filters returns **all** lines above `OrderlineKey` without a limit.\n- Calling without any parameter looks up `OrderlineKey = 0` and normally returns no rows.\n- Date filters have priority over each other in the order listed; only one date mode is used per call.\n- `Price_OrderCurr` equals `Price`, `ShipCost_OrderCurr` equals `ShipCost`, `Price_OrderCurr_Set` and `ShipCost_OrderCurr_Set` are always `0`, `SOrderlineRef` is always `NULL`. Code comments mark the `_OrderCurr` columns for removal.\n- `ShipCost` is the shipping cost of the whole order header and is repeated on every line of the order.\n\nDocumentation: https://pixi-api-docs.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": "Returns POS (point of sale) receipt lines from `POSitem2`, filtered by key or by the create/update date of the POS header, with optional key-based paging.\n\nReads POS item rows (lines of point-of-sale receipts). If `POSItemKey` is not passed, it is treated as `0`. The first matching branch decides the filter:\n\n1. **Create or update date** – if `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` is set: items whose POS header (`POSheader2`) was created *or* updated in the range. A row matches the lower bound if `PHCreateDate` or `PHUpdateDate` is `>=` the from value, and the upper bound if `PHCreateDate` or `PHUpdateDate` is `<` the to value.\n2. **Create date** – else if `CreateDateFrom` or `CreateDateTo` is set: header `PHCreateDate` `>=` from and `<` to.\n3. **Update date** – else if `UpdateDateFrom` or `UpdateDateTo` is set: header `PHUpdateDate` `>=` from and `<` to.\n4. **Key range** – else if `RowCount` is passed: all items with `POSitemKey` greater than `POSItemKey`.\n5. **Single item** – otherwise: the item with exactly `POSitemKey` = `POSItemKey`.\n\nIn branches 1–4 only items with `POSitemKey` > `POSItemKey` are returned, sorted by `POSitemKey` ascending. Branches 1–3 only return items that have a matching POS header (inner join).\n\n`RowCount` limits the number of returned rows (if not 0). For paging, pass the last received `POSitemKey` as `POSItemKey` in the next call.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `POSItemKey` | int | No | Key of a POS item. Exact match in the single-item branch; otherwise only items with a greater key are returned (paging start). NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for the creation date of the POS header. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for the creation date of the POS header. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for the update date of the POS header. Ignored if a create-date or combined filter is set. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for the update date of the POS header. Ignored if a create-date or combined filter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive) matched against the header's create or update date. Takes precedence over all other date filters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (exclusive) matched against the header's create or update date. Takes precedence over all other date filters. |\n| `RowCount` | int | No | Maximum number of rows (0 or NULL = no limit). If passed without date filters, switches to the key-range branch (`POSitemKey` > `POSItemKey`). |\n\n- All reads use `NOLOCK`; uncommitted data may be returned.\n- The row limit is applied with `SET ROWCOUNT`.\n- Calling without any parameter falls into the single-item branch with key `0` and normally returns an empty result.\n- Passing `RowCount` = `0` still selects the key-range branch (the value is not NULL) but applies no row limit, so all items above `POSItemKey` are returned.\n- Date upper bounds are exclusive (`<`). In the combined create/update filter the bounds are evaluated independently, so a row can match the from bound via one date and the to bound via the other.\n- The date filters refer to the POS header, not to the item itself.\n- The final \"no data\" branch in the code is unreachable because `POSItemKey` is never NULL after the default handling.\n\nDocumentation: https://pixi-api-docs.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": "Returns POS (point of sale) receipt lines from `POSitem2`, filtered by key or by the create/update date of the POS header, with optional key-based paging.\n\nReads POS item rows (lines of point-of-sale receipts). If `POSItemKey` is not passed, it is treated as `0`. The first matching branch decides the filter:\n\n1. **Create or update date** – if `CreateAndUpdateDateFrom` or `CreateAndUpdateDateTo` is set: items whose POS header (`POSheader2`) was created *or* updated in the range. A row matches the lower bound if `PHCreateDate` or `PHUpdateDate` is `>=` the from value, and the upper bound if `PHCreateDate` or `PHUpdateDate` is `<` the to value.\n2. **Create date** – else if `CreateDateFrom` or `CreateDateTo` is set: header `PHCreateDate` `>=` from and `<` to.\n3. **Update date** – else if `UpdateDateFrom` or `UpdateDateTo` is set: header `PHUpdateDate` `>=` from and `<` to.\n4. **Key range** – else if `RowCount` is passed: all items with `POSitemKey` greater than `POSItemKey`.\n5. **Single item** – otherwise: the item with exactly `POSitemKey` = `POSItemKey`.\n\nIn branches 1–4 only items with `POSitemKey` > `POSItemKey` are returned, sorted by `POSitemKey` ascending. Branches 1–3 only return items that have a matching POS header (inner join).\n\n`RowCount` limits the number of returned rows (if not 0). For paging, pass the last received `POSitemKey` as `POSItemKey` in the next call.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `POSItemKey` | int | No | Key of a POS item. Exact match in the single-item branch; otherwise only items with a greater key are returned (paging start). NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for the creation date of the POS header. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for the creation date of the POS header. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for the update date of the POS header. Ignored if a create-date or combined filter is set. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for the update date of the POS header. Ignored if a create-date or combined filter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive) matched against the header's create or update date. Takes precedence over all other date filters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (exclusive) matched against the header's create or update date. Takes precedence over all other date filters. |\n| `RowCount` | int | No | Maximum number of rows (0 or NULL = no limit). If passed without date filters, switches to the key-range branch (`POSitemKey` > `POSItemKey`). |\n\n- All reads use `NOLOCK`; uncommitted data may be returned.\n- The row limit is applied with `SET ROWCOUNT`.\n- Calling without any parameter falls into the single-item branch with key `0` and normally returns an empty result.\n- Passing `RowCount` = `0` still selects the key-range branch (the value is not NULL) but applies no row limit, so all items above `POSItemKey` are returned.\n- Date upper bounds are exclusive (`<`). In the combined create/update filter the bounds are evaluated independently, so a row can match the from bound via one date and the to bound via the other.\n- The date filters refer to the POS header, not to the item itself.\n- The final \"no data\" branch in the code is unreachable because `POSItemKey` is never NULL after the default handling.\n\nDocumentation: https://pixi-api-docs.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": "Moves a single order line or a bundle order line, together with the related bundle lines, to another location (LocID).\n\nChanges the location (`LocationID` and `LastOrdLocationID`) of order lines. The call delegates to the internal procedure `Pixi_UpdateOrderLocation` with user name `API` and returns one status row.\n\n**Which records are changed**\n\n- **Only `OrderlineKey` given:** the order line itself is moved. If the line belongs to a bundle, all other lines of the same bundle and the bundle order line (`BundleOrderlines`) are moved as well.\n- **Only `BundleOrderlineKey` given:** all component order lines of this bundle and the bundle order line itself are moved. The component lines are moved only if the bundle order line has an eligible status.\n- **Neither key given:** the call fails, because no order can be determined.\n\nOnly lines with an eligible status are updated. Eligible statuses are all non-final states from `OrderStates` (`FinalState = 'N'`) except `EIN`, `FUT` and `FUS`. Lines with any other status are skipped silently, and the call still returns `OK`.\n\n**Validation**\n\nThe internal procedure checks the following and rejects the call if a check fails:\n\n- The order line or bundle order line exists.\n- `LocationId` exists in `Location`.\n- At least one line of the order has the status `NEW`, `ANG`, `HAL`, `MIN`, `BES`, `STO` or `NLB`.\n- None of the affected order lines is on a picklist (`PLitem`).\n\n**POS / reservation locations**\n\nIf the target location has a `ResLocID`, `ResOnLocDate` of the order header is reset to NULL. The procedure then looks at other orders that have eligible lines on the same location with the same items. If the latest `ResOnLocDate` of those orders is earlier than the earliest reservation date of this order, all reservations of this order get that latest `ResOnLocDate` plus one second as their new `ResDate`.\n\n**Result**\n\nThe call returns `ReturnCode = 'OK'` on success. Otherwise it returns `ReturnCode = 'ERROR'` with the generic message `Ilegal parameters`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Key of the order line to move. If the line belongs to a bundle, the other bundle lines and the bundle order line are moved too. Either this or `BundleOrderlineKey` must be given. |\n| `BundleOrderlineKey` | int | No | Key of the bundle order line (`BundleOrderlines`) to move together with all its component lines. Either this or `OrderlineKey` must be given. |\n| `LocationId` | char(3) | Yes | Target location (`LocID` from table `Location`). Must exist. |\n\n- All failure reasons of the internal procedure collapse into the single message `Ilegal parameters`. The detailed reasons are only emitted via `PRINT`, for example `ERROR: Wrong LocationID: ...` or `... must not be on Picklist`. Whether a SOAP client receives these texts is not visible in the code.\n- `UpdateEmp` is set to `API` and `UpdateDate` to the current time on all updated rows.\n- The internal procedure runs in its own transaction, or uses a savepoint if a transaction is already open. On a runtime error it rolls back, logs the error via `log.InsertError` and the call returns `ERROR`.\n- During the update of `BundleOrderlines`, `CONTEXT_INFO` is temporarily set to `0x30000`. According to a code comment this avoids recalculating bundles; the triggers that evaluate it are not attached.\n- Validation reads use `NOLOCK`; updates use `ROWLOCK`.\n- Passing both `OrderlineKey` and `BundleOrderlineKey` is not recommended:\n - The bundle key determines the order.\n - The bundle order line itself is not updated.\n - The same order lines can be collected twice, so creating the unique index on the internal temp table fails and the call returns `ERROR`.\n\n Pass only one of the two keys.\n- The status check (`NEW`, `ANG`, `HAL`, ...) only requires one line of the whole order in such a status, not necessarily the target line.\n\nDocumentation: https://pixi-api-docs.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": "Moves a single order line or a bundle order line, together with the related bundle lines, to another location (LocID).\n\nChanges the location (`LocationID` and `LastOrdLocationID`) of order lines. The call delegates to the internal procedure `Pixi_UpdateOrderLocation` with user name `API` and returns one status row.\n\n**Which records are changed**\n\n- **Only `OrderlineKey` given:** the order line itself is moved. If the line belongs to a bundle, all other lines of the same bundle and the bundle order line (`BundleOrderlines`) are moved as well.\n- **Only `BundleOrderlineKey` given:** all component order lines of this bundle and the bundle order line itself are moved. The component lines are moved only if the bundle order line has an eligible status.\n- **Neither key given:** the call fails, because no order can be determined.\n\nOnly lines with an eligible status are updated. Eligible statuses are all non-final states from `OrderStates` (`FinalState = 'N'`) except `EIN`, `FUT` and `FUS`. Lines with any other status are skipped silently, and the call still returns `OK`.\n\n**Validation**\n\nThe internal procedure checks the following and rejects the call if a check fails:\n\n- The order line or bundle order line exists.\n- `LocationId` exists in `Location`.\n- At least one line of the order has the status `NEW`, `ANG`, `HAL`, `MIN`, `BES`, `STO` or `NLB`.\n- None of the affected order lines is on a picklist (`PLitem`).\n\n**POS / reservation locations**\n\nIf the target location has a `ResLocID`, `ResOnLocDate` of the order header is reset to NULL. The procedure then looks at other orders that have eligible lines on the same location with the same items. If the latest `ResOnLocDate` of those orders is earlier than the earliest reservation date of this order, all reservations of this order get that latest `ResOnLocDate` plus one second as their new `ResDate`.\n\n**Result**\n\nThe call returns `ReturnCode = 'OK'` on success. Otherwise it returns `ReturnCode = 'ERROR'` with the generic message `Ilegal parameters`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Key of the order line to move. If the line belongs to a bundle, the other bundle lines and the bundle order line are moved too. Either this or `BundleOrderlineKey` must be given. |\n| `BundleOrderlineKey` | int | No | Key of the bundle order line (`BundleOrderlines`) to move together with all its component lines. Either this or `OrderlineKey` must be given. |\n| `LocationId` | char(3) | Yes | Target location (`LocID` from table `Location`). Must exist. |\n\n- All failure reasons of the internal procedure collapse into the single message `Ilegal parameters`. The detailed reasons are only emitted via `PRINT`, for example `ERROR: Wrong LocationID: ...` or `... must not be on Picklist`. Whether a SOAP client receives these texts is not visible in the code.\n- `UpdateEmp` is set to `API` and `UpdateDate` to the current time on all updated rows.\n- The internal procedure runs in its own transaction, or uses a savepoint if a transaction is already open. On a runtime error it rolls back, logs the error via `log.InsertError` and the call returns `ERROR`.\n- During the update of `BundleOrderlines`, `CONTEXT_INFO` is temporarily set to `0x30000`. According to a code comment this avoids recalculating bundles; the triggers that evaluate it are not attached.\n- Validation reads use `NOLOCK`; updates use `ROWLOCK`.\n- Passing both `OrderlineKey` and `BundleOrderlineKey` is not recommended:\n - The bundle key determines the order.\n - The bundle order line itself is not updated.\n - The same order lines can be collected twice, so creating the unique index on the internal temp table fails and the call returns `ERROR`.\n\n Pass only one of the two keys.\n- The status check (`NEW`, `ANG`, `HAL`, ...) only requires one line of the whole order in such a status, not necessarily the target line.\n\nDocumentation: https://pixi-api-docs.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": "Updates name, quantity, prices, discounts, note, serial number and DF type of an order line or bundle order line, provided the line can still be changed.\n\nChanges a single order line (`OrderlineKey`) or a bundle order line (`BundleOrderlineKey`) and returns a `result` row with `1` (executed) or `0` (rejected).\n\n**Key selection**\n- `BundleOrderlineKey = 0` is treated as `NULL`.\n- If both keys are missing, an informational message is raised and `result = 0` is returned.\n- If `BundleOrderlineKey` is set, `OrderlineKey` is ignored.\n\n**Changeability check**\nThe line, or for a bundle every component order line, must fulfil all of the following:\n- its order state (`OrderStates`) is not a final state (`FinalState` is `N` or empty),\n- its status is not `EIN`,\n- it is not packed in a box (`boxitems`),\n- it is not on an invoice (`Invlines`).\n\nIf a single line fails the check, nothing is changed and `result = 0` is returned.\n\n**Merging with current values**\nEvery parameter left out (`NULL`) keeps the value stored on the line. For `ArtName`, `oItemSpecialNote` and `SerialNumber` an empty string also keeps the stored value. For bundles the serial number is not processed. If the resulting `Price` is higher than `FullPrice`, `FullPrice` is raised to `Price`. The same rule applies to the net values.\n\n**Update**\nThe internal procedure `Pixi_UpdateOrderline` is then run with update user `API`. It does the following:\n- updates the order line, or the bundle order line, with quantity, gross/net price, confirmation date, name, note, serial number, full prices, discount percentage/value and `DF_type`;\n- for bundles, also sets `DF_type` on all component order lines;\n- writes the current header values (address remarks, gift message and, if a shipping instruction exists, shipping instruction, `Verfahren`, `Product`, `Extras`) back to `OrderHeader`;\n- synchronises the voucher of the order (see notes);\n- rebuilds the reservations of the whole order if any of its lines has a reservation.\n\nFinally `result = 1` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Key of the order line to change. Ignored if `BundleOrderlineKey` is set. |\n| `ArtName` | varchar(120) | No | New item name on the line. `NULL` or empty keeps the current name. |\n| `Qty` | int | No | New quantity. `NULL` keeps the current quantity. |\n| `Price` | money | No | New unit price, also used as the input for the net price. `NULL` keeps the current price. |\n| `FullPrice` | money | No | New full (undiscounted) price, also stored as net full price. Raised to `Price` if lower. `NULL` keeps the current value. |\n| `oItemSpecialNote` | varchar(8000) | No | Special note for the line. `NULL` or empty keeps the current note. |\n| `DiscountValue` | money | No | Discount amount of the line. `NULL` keeps the current value. |\n| `DiscountPerc` | float | No | Discount percentage of the line, stored with two decimals. `NULL` keeps the current value. |\n| `DF_Type` | varchar(1) | No | Direct-fulfillment type of the line (`DF_type`). For bundles also applied to all component lines. `NULL` keeps the current value. |\n| `SerialNumber` | varchar(50) | No | Serial number of the order line. `NULL` or empty keeps the current value. Not processed for bundle order lines. |\n| `BundleOrderlineKey` | int | No | Key of the bundle order line to change. `0` is treated as `NULL`. Takes precedence over `OrderlineKey`. |\n\n- **Non-existent key:** if `OrderlineKey` or `BundleOrderlineKey` does not exist, the check finds no row and does not reject the call. Nothing is updated, but `result = 1` is still returned.\n- **Messages instead of errors:** all `RAISERROR` calls use severity 0. They arrive only as `SqlMessage`, not as SQL errors.\n- **Invoice check:** if `Pixi_UpdateOrderline` finds an invoice line, it raises its message and changes nothing. `result = 1` is still returned afterwards.\n- **Net prices:** the net price and net full price are initialised with the passed gross values (`Price`, `FullPrice`). The line price is then converted by `dbo.fPixi_CalculatePrices` (not attached) using tax rate and order type. `FullPrice_Net` is stored without conversion, so after passing `FullPrice` it holds the same value as `FullPrice`.\n- **Types:** `DiscountPerc` is passed as `numeric(6,2)` and is therefore rounded to two decimals. `GiftMessage` is passed as `varchar(1000)`.\n- **Values cannot be cleared:** `ArtName`, `oItemSpecialNote` and `SerialNumber` cannot be cleared through this call.\n- **Voucher handling** (based on the voucher code of the line and `OrderHeader.Discount`):\n - If the voucher exists with a different amount, its amount is set to the order discount.\n - If that discount is 0, `VoucherID` is cleared on all lines and bundle lines of the order.\n - If the voucher does not exist and the code is not `NULL`, a voucher is created (valid for about one year from the order date, single use, shop `GRM`) and assigned to all lines of the order.\n- **Reservations:** reservations are removed and recreated by `Pixi_Res_RemoveReservationForOrder` and `Pixi_Res_CreateReservationForOrder`. These procedures are not attached and may produce further output.\n- **Transactions and errors:** the update runs in a transaction, or a savepoint if a transaction is already open. On an exception it is rolled back, a row with the error message and the error count is returned (unnamed columns), the error is logged via `log.InsertError`, and `result = 1` follows anyway.\n- **Locking:** the checks read with `NOLOCK`; updates use `ROWLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Updates name, quantity, prices, discounts, note, serial number and DF type of an order line or bundle order line, provided the line can still be changed.\n\nChanges a single order line (`OrderlineKey`) or a bundle order line (`BundleOrderlineKey`) and returns a `result` row with `1` (executed) or `0` (rejected).\n\n**Key selection**\n- `BundleOrderlineKey = 0` is treated as `NULL`.\n- If both keys are missing, an informational message is raised and `result = 0` is returned.\n- If `BundleOrderlineKey` is set, `OrderlineKey` is ignored.\n\n**Changeability check**\nThe line, or for a bundle every component order line, must fulfil all of the following:\n- its order state (`OrderStates`) is not a final state (`FinalState` is `N` or empty),\n- its status is not `EIN`,\n- it is not packed in a box (`boxitems`),\n- it is not on an invoice (`Invlines`).\n\nIf a single line fails the check, nothing is changed and `result = 0` is returned.\n\n**Merging with current values**\nEvery parameter left out (`NULL`) keeps the value stored on the line. For `ArtName`, `oItemSpecialNote` and `SerialNumber` an empty string also keeps the stored value. For bundles the serial number is not processed. If the resulting `Price` is higher than `FullPrice`, `FullPrice` is raised to `Price`. The same rule applies to the net values.\n\n**Update**\nThe internal procedure `Pixi_UpdateOrderline` is then run with update user `API`. It does the following:\n- updates the order line, or the bundle order line, with quantity, gross/net price, confirmation date, name, note, serial number, full prices, discount percentage/value and `DF_type`;\n- for bundles, also sets `DF_type` on all component order lines;\n- writes the current header values (address remarks, gift message and, if a shipping instruction exists, shipping instruction, `Verfahren`, `Product`, `Extras`) back to `OrderHeader`;\n- synchronises the voucher of the order (see notes);\n- rebuilds the reservations of the whole order if any of its lines has a reservation.\n\nFinally `result = 1` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | No | Key of the order line to change. Ignored if `BundleOrderlineKey` is set. |\n| `ArtName` | varchar(120) | No | New item name on the line. `NULL` or empty keeps the current name. |\n| `Qty` | int | No | New quantity. `NULL` keeps the current quantity. |\n| `Price` | money | No | New unit price, also used as the input for the net price. `NULL` keeps the current price. |\n| `FullPrice` | money | No | New full (undiscounted) price, also stored as net full price. Raised to `Price` if lower. `NULL` keeps the current value. |\n| `oItemSpecialNote` | varchar(8000) | No | Special note for the line. `NULL` or empty keeps the current note. |\n| `DiscountValue` | money | No | Discount amount of the line. `NULL` keeps the current value. |\n| `DiscountPerc` | float | No | Discount percentage of the line, stored with two decimals. `NULL` keeps the current value. |\n| `DF_Type` | varchar(1) | No | Direct-fulfillment type of the line (`DF_type`). For bundles also applied to all component lines. `NULL` keeps the current value. |\n| `SerialNumber` | varchar(50) | No | Serial number of the order line. `NULL` or empty keeps the current value. Not processed for bundle order lines. |\n| `BundleOrderlineKey` | int | No | Key of the bundle order line to change. `0` is treated as `NULL`. Takes precedence over `OrderlineKey`. |\n\n- **Non-existent key:** if `OrderlineKey` or `BundleOrderlineKey` does not exist, the check finds no row and does not reject the call. Nothing is updated, but `result = 1` is still returned.\n- **Messages instead of errors:** all `RAISERROR` calls use severity 0. They arrive only as `SqlMessage`, not as SQL errors.\n- **Invoice check:** if `Pixi_UpdateOrderline` finds an invoice line, it raises its message and changes nothing. `result = 1` is still returned afterwards.\n- **Net prices:** the net price and net full price are initialised with the passed gross values (`Price`, `FullPrice`). The line price is then converted by `dbo.fPixi_CalculatePrices` (not attached) using tax rate and order type. `FullPrice_Net` is stored without conversion, so after passing `FullPrice` it holds the same value as `FullPrice`.\n- **Types:** `DiscountPerc` is passed as `numeric(6,2)` and is therefore rounded to two decimals. `GiftMessage` is passed as `varchar(1000)`.\n- **Values cannot be cleared:** `ArtName`, `oItemSpecialNote` and `SerialNumber` cannot be cleared through this call.\n- **Voucher handling** (based on the voucher code of the line and `OrderHeader.Discount`):\n - If the voucher exists with a different amount, its amount is set to the order discount.\n - If that discount is 0, `VoucherID` is cleared on all lines and bundle lines of the order.\n - If the voucher does not exist and the code is not `NULL`, a voucher is created (valid for about one year from the order date, single use, shop `GRM`) and assigned to all lines of the order.\n- **Reservations:** reservations are removed and recreated by `Pixi_Res_RemoveReservationForOrder` and `Pixi_Res_CreateReservationForOrder`. These procedures are not attached and may produce further output.\n- **Transactions and errors:** the update runs in a transaction, or a savepoint if a transaction is already open. On an exception it is rolled back, a row with the error message and the error count is returned (unnamed columns), the error is logged via `log.InsertError`, and `result = 1` follows anyway.\n- **Locking:** the checks read with `NOLOCK`; updates use `ROWLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Sets the shop note (`Shop_Note`) of an order identified by its order number and returns 1 on success or 0 if the order is missing or masked.\n\nWrites a comment into the shop note field of an order.\n\n1. The order is looked up in `OrderHeader` by `OrderNr`. If no order exists, the call returns a row with `ReturnMessage` = `0` and stops.\n2. The call checks whether the order is editable. An order counts as not editable (masked) if it has an order header attribute of type `2` with value `2`. For a masked order the call returns `ReturnMessage` = `0` and changes nothing.\n3. Otherwise `Shop_Note` of the order is set to `@Comment` and the call returns `ReturnMessage` = `1`.\n\nDespite the name, the comment is **not appended**: the existing content of `Shop_Note` is replaced completely.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Order number of the order whose shop note is set. |\n| `Comment` | nvarchar(max) | Yes | Text written into `Shop_Note`. Replaces the previous note completely; `NULL` results in an empty note. |\n\n- The existing shop note is overwritten. To keep previous text, read the current note first and send the combined text.\n- If `Comment` is `NULL` or omitted in the XML as nil, the note is set to an empty string (the blacklist function currently only replaces `NULL` with `''`).\n- `ReturnMessage` = `0` does not distinguish between \"order not found\" and \"order masked\".\n- The lookups of the order and its attributes use `NOLOCK`.\n- The update runs in its own transaction, or in a savepoint if the caller already has an open transaction. On an error the transaction is rolled back and the error is logged via `log.InsertError` (definition not attached); in that case no `ReturnMessage` row is returned by this procedure, and whether an error is passed on to the caller depends on `log.InsertError`.\n- The order lookup by `OrderNr` is outside the error handling; if several orders shared the same `OrderNr`, the subquery would fail with a SQL error.\n\nDocumentation: https://pixi-api-docs.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": "Sets the shop note (`Shop_Note`) of an order identified by its order number and returns 1 on success or 0 if the order is missing or masked.\n\nWrites a comment into the shop note field of an order.\n\n1. The order is looked up in `OrderHeader` by `OrderNr`. If no order exists, the call returns a row with `ReturnMessage` = `0` and stops.\n2. The call checks whether the order is editable. An order counts as not editable (masked) if it has an order header attribute of type `2` with value `2`. For a masked order the call returns `ReturnMessage` = `0` and changes nothing.\n3. Otherwise `Shop_Note` of the order is set to `@Comment` and the call returns `ReturnMessage` = `1`.\n\nDespite the name, the comment is **not appended**: the existing content of `Shop_Note` is replaced completely.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Order number of the order whose shop note is set. |\n| `Comment` | nvarchar(max) | Yes | Text written into `Shop_Note`. Replaces the previous note completely; `NULL` results in an empty note. |\n\n- The existing shop note is overwritten. To keep previous text, read the current note first and send the combined text.\n- If `Comment` is `NULL` or omitted in the XML as nil, the note is set to an empty string (the blacklist function currently only replaces `NULL` with `''`).\n- `ReturnMessage` = `0` does not distinguish between \"order not found\" and \"order masked\".\n- The lookups of the order and its attributes use `NOLOCK`.\n- The update runs in its own transaction, or in a savepoint if the caller already has an open transaction. On an error the transaction is rolled back and the error is logged via `log.InsertError` (definition not attached); in that case no `ReturnMessage` row is returned by this procedure, and whether an error is passed on to the caller depends on `log.InsertError`.\n- The order lookup by `OrderNr` is outside the error handling; if several orders shared the same `OrderNr`, the subquery would fail with a SQL error.\n\nDocumentation: https://pixi-api-docs.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": "Returns 1 if the address of an order may still be changed because no invoice lines exist for its order lines, otherwise 0.\n\nChecks whether the address of an order can still be changed. The check is based only on whether the order has already been invoiced, completely or partially.\n\n1. If both `OrderNr` and `OrderNrExternal` are `NULL`, the function returns `0` right away.\n2. Otherwise it identifies the order lines (`Orderlines`) of the order:\n - by `OrderNr` if only `OrderNr` is given, or\n - by `OrderNrExternal` if only `OrderNrExternal` is given.\n3. It counts the invoice lines (`InvLines`) that reference one of these order lines through `OrderlineRef`.\n4. It returns `0` if at least one invoice line exists (the order is invoiced at least partially). It returns `1` if no invoice line exists, which means the address may be changed.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Internal Pixi order number. Used only if `OrderNrExternal` is `NULL`. |\n| `OrderNrExternal` | varchar(50) | No | External order number, for example the shop order number. Used only if `OrderNr` is `NULL`. |\n\n- Pass **only one** of the two parameters. If both are given, neither filter condition applies. No order lines are found, and the function returns `1` (change allowed), even if the order is invoiced.\n- A non-existent order number also returns `1`, because no invoice lines are found. The function does not check whether the order exists.\n- Both tables are read with `NOLOCK`, so the result can reflect uncommitted data.\n- The function only checks for invoice lines. Other states, such as shipped or cancelled orders, are not considered.\n\nDocumentation: https://pixi-api-docs.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": "Returns 1 if the address of an order may still be changed because no invoice lines exist for its order lines, otherwise 0.\n\nChecks whether the address of an order can still be changed. The check is based only on whether the order has already been invoiced, completely or partially.\n\n1. If both `OrderNr` and `OrderNrExternal` are `NULL`, the function returns `0` right away.\n2. Otherwise it identifies the order lines (`Orderlines`) of the order:\n - by `OrderNr` if only `OrderNr` is given, or\n - by `OrderNrExternal` if only `OrderNrExternal` is given.\n3. It counts the invoice lines (`InvLines`) that reference one of these order lines through `OrderlineRef`.\n4. It returns `0` if at least one invoice line exists (the order is invoiced at least partially). It returns `1` if no invoice line exists, which means the address may be changed.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Internal Pixi order number. Used only if `OrderNrExternal` is `NULL`. |\n| `OrderNrExternal` | varchar(50) | No | External order number, for example the shop order number. Used only if `OrderNr` is `NULL`. |\n\n- Pass **only one** of the two parameters. If both are given, neither filter condition applies. No order lines are found, and the function returns `1` (change allowed), even if the order is invoiced.\n- A non-existent order number also returns `1`, because no invoice lines are found. The function does not check whether the order exists.\n- Both tables are read with `NOLOCK`, so the result can reflect uncommitted data.\n- The function only checks for invoice lines. Other states, such as shipped or cancelled orders, are not considered.\n\nDocumentation: https://pixi-api-docs.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": "Checks whether two orders can be merged and returns a flag and a reason code with text.\n\nValidates whether the source order (`SourceOrderNr`) can be merged into the target order (`TargetOrderNr`). The call does not change any data.\n\nThe checks run in this order. The first check that fails sets `CanMerge = 0` and the matching reason. The remaining checks are then skipped:\n\n1. **Both orders exist**: exactly two rows must exist in `OrderHeader` for the two order numbers. Otherwise the reason is `401`.\n2. **Same customer**: `CustRef` of both orders must be equal. Otherwise the reason is `402`.\n3. **Orderline status**: no orderline of either order may have a status other than `ANG`. Otherwise the reason is `403`.\n4. **Payment type**: `APayment` of the addresses referenced by the orders (`AddrRef`) must be equal and must not be `K` (credit card). Otherwise the reason is `404`.\n5. **Picklists**: no orderline of either order may be on a picklist whose `PLHexpiryDate` is in the future and whose `ReservedOrderNr` is empty or 0. Otherwise the reason is `405`.\n6. **Currency and order type**: `CurrencyId` must match, otherwise the reason is `406`. Then `OrderType` must match, otherwise the reason is `407`.\n\nIf all checks pass, the call returns `CanMerge = 1` and `Reason = '200 OK'`. It always returns one row with `CanMerge` and `Reason`. The same values are set in the output parameters, and `CanMerge` is also the procedure's return value.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TargetOrderNr` | int | Yes | Order number of the target order into which the source order would be merged. |\n| `SourceOrderNr` | int | Yes | Order number of the source order that would be merged into the target order. |\n| `CanMerge` | int | No | Output: 1 if the orders can be merged, otherwise 0. An input value is ignored. |\n| `Reason` | varchar(128) | No | Output: reason code with text, e.g. `200 OK` or `402 Orders must belong to the same customer`. An input value is ignored. |\n\n- All reads use `NOLOCK`, so the result can be based on uncommitted data. Re-check right before the actual merge.\n- If `TargetOrderNr` and `SourceOrderNr` are equal, only one header row is found, so the result is `401`.\n- A `NULL` value in `CustRef`, `APayment`, `CurrencyId` or `OrderType` makes the comparison fail and leads to the corresponding error code.\n- Orders without orderlines pass the status check (`403`).\n- If an order's address (`AddrRef`) is not found in `Addresses`, the join returns no row and the payment check (`404`) is effectively skipped.\n- The column `ReservedOrderNr` in the picklist check is not qualified with a table name. From the code it is not clear whether it belongs to `PLitem` or `plheader`.\n- The reason text starts with an HTTP-like numeric code (`200`, `401`–`407`), which is useful for programmatic evaluation.\n\nDocumentation: https://pixi-api-docs.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": "Checks whether two orders can be merged and returns a flag and a reason code with text.\n\nValidates whether the source order (`SourceOrderNr`) can be merged into the target order (`TargetOrderNr`). The call does not change any data.\n\nThe checks run in this order. The first check that fails sets `CanMerge = 0` and the matching reason. The remaining checks are then skipped:\n\n1. **Both orders exist**: exactly two rows must exist in `OrderHeader` for the two order numbers. Otherwise the reason is `401`.\n2. **Same customer**: `CustRef` of both orders must be equal. Otherwise the reason is `402`.\n3. **Orderline status**: no orderline of either order may have a status other than `ANG`. Otherwise the reason is `403`.\n4. **Payment type**: `APayment` of the addresses referenced by the orders (`AddrRef`) must be equal and must not be `K` (credit card). Otherwise the reason is `404`.\n5. **Picklists**: no orderline of either order may be on a picklist whose `PLHexpiryDate` is in the future and whose `ReservedOrderNr` is empty or 0. Otherwise the reason is `405`.\n6. **Currency and order type**: `CurrencyId` must match, otherwise the reason is `406`. Then `OrderType` must match, otherwise the reason is `407`.\n\nIf all checks pass, the call returns `CanMerge = 1` and `Reason = '200 OK'`. It always returns one row with `CanMerge` and `Reason`. The same values are set in the output parameters, and `CanMerge` is also the procedure's return value.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TargetOrderNr` | int | Yes | Order number of the target order into which the source order would be merged. |\n| `SourceOrderNr` | int | Yes | Order number of the source order that would be merged into the target order. |\n| `CanMerge` | int | No | Output: 1 if the orders can be merged, otherwise 0. An input value is ignored. |\n| `Reason` | varchar(128) | No | Output: reason code with text, e.g. `200 OK` or `402 Orders must belong to the same customer`. An input value is ignored. |\n\n- All reads use `NOLOCK`, so the result can be based on uncommitted data. Re-check right before the actual merge.\n- If `TargetOrderNr` and `SourceOrderNr` are equal, only one header row is found, so the result is `401`.\n- A `NULL` value in `CustRef`, `APayment`, `CurrencyId` or `OrderType` makes the comparison fail and leads to the corresponding error code.\n- Orders without orderlines pass the status check (`403`).\n- If an order's address (`AddrRef`) is not found in `Addresses`, the join returns no row and the payment check (`404`) is effectively skipped.\n- The column `ReservedOrderNr` in the picklist check is not qualified with a table name. From the code it is not clear whether it belongs to `PLitem` or `plheader`.\n- The reason text starts with an HTTP-like numeric code (`200`, `401`–`407`), which is useful for programmatic evaluation.\n\nDocumentation: https://pixi-api-docs.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": "Changes the billing or shipping address of an order, as long as the order has not been invoiced yet.\n\nUpdates the address record that is linked to an order and returns a status text.\n\n1. The order is identified **either** by `OrderNr` **or** by `OrderNrExternal`. `OrderNr = 0` and an empty `OrderNrExternal` are treated as not set.\n2. The function `pipiCanChangeAddress` checks whether the address may be changed. It returns 0 if no order is given or if any order line of the order already has an invoice line (`InvLines`). Otherwise it returns 1.\n3. The address key is read from the order lines (`Orderlines`):\n - If `AddrType` contains `B` (not case-sensitive), the billing address (`AddrRef`) is used.\n - Otherwise the shipping address (`ShipAdrRef`) is used. This also applies to `S`, other values and an empty value.\n4. If changing is allowed and an address was found, the address is updated:\n - Empty strings are treated as \"not passed\". Every parameter that is not passed keeps the current value of the address. Only the fields that are passed are changed.\n - `ASlocked` sets the shipping lock: `1` sets `ASlocked = 'Y'`, any other numeric value sets `'N'`. If it is omitted, the current value is kept.\n - For shipping addresses (`AddrType = 'S'` in `Addresses`), a row is written to `pixi.AddressesShippingLockHistory` when the lock state changes.\n - `UpdateDate` is set to the current date and `UpdateEmp` to `api`.\n5. The status is returned in the output parameter `FunctionResult` and as a single row with the column `Result`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. 0 is treated as NULL. Pass either this or `OrderNrExternal`, not both. |\n| `OrderNrExternal` | varchar(50) | No | External (shop) order number. An empty string is treated as NULL. Used only if `OrderNr` is not set. |\n| `AddrType` | char(2) | Yes | Selects which address of the order is changed. A value containing `B` selects the billing address; all other values select the shipping address. |\n| `Anrede` | varchar(60) | No | Salutation. If empty or omitted, the current value is kept. |\n| `FirstName` | varchar(60) | No | First name. If empty or omitted, the current value is kept. |\n| `LastName` | varchar(60) | No | Last name. If empty or omitted, the current value is kept. |\n| `CareOf` | varchar(60) | No | Address addition (c/o). If omitted, the current value is kept. Unlike the other fields, an empty string is stored as an empty string. |\n| `Street` | varchar(100) | No | Street. If empty or omitted, the current value is kept. |\n| `HouseNr` | varchar(12) | No | House number. If empty or omitted, the current value is kept. |\n| `City` | varchar(50) | No | City. If empty or omitted, the current value is kept. |\n| `State` | varchar(3) | No | State or region code. If empty or omitted, the current value is kept. |\n| `ZIP` | varchar(10) | No | Postal code. If empty or omitted, the current value is kept. |\n| `Country` | varchar(3) | No | Country code. If empty or omitted, the current value is kept. |\n| `Phone` | varchar(60) | No | Phone number. If empty or omitted, the current value is kept. |\n| `Phone2` | varchar(60) | No | Second phone number. If empty or omitted, the current value is kept. |\n| `Fax` | varchar(60) | No | Fax number. If empty or omitted, the current value is kept. |\n| `Fax2` | varchar(60) | No | Second fax number. If empty or omitted, the current value is kept. |\n| `eMail` | varchar(60) | No | E-mail address. If empty or omitted, the current value is kept. |\n| `Account` | varchar(10) | No | Bank account number (column `AAccount`). If empty or omitted, the current value is kept. |\n| `BLZ` | varchar(8) | No | German bank code (column `ABLZ`). If empty or omitted, the current value is kept. |\n| `BankName` | varchar(50) | No | Bank name (column `ABankName`). If empty or omitted, the current value is kept. |\n| `AccName` | varchar(27) | No | Account holder (column `AAccName`). If empty or omitted, the current value is kept. |\n| `BIC` | varchar(11) | No | BIC. If empty or omitted, the current value is kept. |\n| `IBAN` | varchar(35) | No | IBAN. If empty or omitted, the current value is kept. |\n| `ASlocked` | varchar(1) | No | Shipping lock. `1` stores `Y`, any other numeric value stores `N`. If empty or omitted, the current value is kept. Non-numeric values cause a conversion error. |\n| `FunctionResult` | varchar(128) | No | Output: status text, for example `200 OK`. The same text is returned in the column `Result`. |\n| `CardHolderName` | varchar(60) | No | Card holder name (column `ACardName`). If empty or omitted, the current value is kept. |\n| `Note` | varchar(8000) | No | Note on the address. If empty or omitted, the current value is kept. |\n| `VatId` | varchar(20) | No | VAT ID (column `UsStId`). If empty or omitted, the current value is kept. |\n\n- **Pass only one order identifier.** If both `OrderNr` and `OrderNrExternal` are passed, no order line matches. The result is then `402 Address not found`.\n- **Fields cannot be cleared.** Empty values are ignored and the existing value is kept. The exception is `CareOf`: an empty string is written as an empty string.\n- **`ASlocked` must be numeric.** The code compares it with the number 1. A value such as `Y` therefore causes an SQL conversion error, which is returned as `SqlMessage`. Use `1` or `0`.\n- **Lock history.** The history row is only written if the stored `ASlocked` value differs from the new value. If the stored value is NULL, no history row is written. The user ID for the history is the user `api`, or `pixiAdministration` as a fallback.\n- **Orders with several lines.** The address key is taken from one of the order lines; the code does not determine which one. Orders whose lines reference different addresses are not handled specifically.\n- **Reads and transactions.** Order lines and addresses are read with `NOLOCK`. There is no explicit transaction.\n- **Status codes.** The codes 200–403 are plain text codes and not HTTP statuses. If neither changing is allowed nor an address is found, `402` overrides `401`.\n\nDocumentation: https://pixi-api-docs.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": "Changes the billing or shipping address of an order, as long as the order has not been invoiced yet.\n\nUpdates the address record that is linked to an order and returns a status text.\n\n1. The order is identified **either** by `OrderNr` **or** by `OrderNrExternal`. `OrderNr = 0` and an empty `OrderNrExternal` are treated as not set.\n2. The function `pipiCanChangeAddress` checks whether the address may be changed. It returns 0 if no order is given or if any order line of the order already has an invoice line (`InvLines`). Otherwise it returns 1.\n3. The address key is read from the order lines (`Orderlines`):\n - If `AddrType` contains `B` (not case-sensitive), the billing address (`AddrRef`) is used.\n - Otherwise the shipping address (`ShipAdrRef`) is used. This also applies to `S`, other values and an empty value.\n4. If changing is allowed and an address was found, the address is updated:\n - Empty strings are treated as \"not passed\". Every parameter that is not passed keeps the current value of the address. Only the fields that are passed are changed.\n - `ASlocked` sets the shipping lock: `1` sets `ASlocked = 'Y'`, any other numeric value sets `'N'`. If it is omitted, the current value is kept.\n - For shipping addresses (`AddrType = 'S'` in `Addresses`), a row is written to `pixi.AddressesShippingLockHistory` when the lock state changes.\n - `UpdateDate` is set to the current date and `UpdateEmp` to `api`.\n5. The status is returned in the output parameter `FunctionResult` and as a single row with the column `Result`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. 0 is treated as NULL. Pass either this or `OrderNrExternal`, not both. |\n| `OrderNrExternal` | varchar(50) | No | External (shop) order number. An empty string is treated as NULL. Used only if `OrderNr` is not set. |\n| `AddrType` | char(2) | Yes | Selects which address of the order is changed. A value containing `B` selects the billing address; all other values select the shipping address. |\n| `Anrede` | varchar(60) | No | Salutation. If empty or omitted, the current value is kept. |\n| `FirstName` | varchar(60) | No | First name. If empty or omitted, the current value is kept. |\n| `LastName` | varchar(60) | No | Last name. If empty or omitted, the current value is kept. |\n| `CareOf` | varchar(60) | No | Address addition (c/o). If omitted, the current value is kept. Unlike the other fields, an empty string is stored as an empty string. |\n| `Street` | varchar(100) | No | Street. If empty or omitted, the current value is kept. |\n| `HouseNr` | varchar(12) | No | House number. If empty or omitted, the current value is kept. |\n| `City` | varchar(50) | No | City. If empty or omitted, the current value is kept. |\n| `State` | varchar(3) | No | State or region code. If empty or omitted, the current value is kept. |\n| `ZIP` | varchar(10) | No | Postal code. If empty or omitted, the current value is kept. |\n| `Country` | varchar(3) | No | Country code. If empty or omitted, the current value is kept. |\n| `Phone` | varchar(60) | No | Phone number. If empty or omitted, the current value is kept. |\n| `Phone2` | varchar(60) | No | Second phone number. If empty or omitted, the current value is kept. |\n| `Fax` | varchar(60) | No | Fax number. If empty or omitted, the current value is kept. |\n| `Fax2` | varchar(60) | No | Second fax number. If empty or omitted, the current value is kept. |\n| `eMail` | varchar(60) | No | E-mail address. If empty or omitted, the current value is kept. |\n| `Account` | varchar(10) | No | Bank account number (column `AAccount`). If empty or omitted, the current value is kept. |\n| `BLZ` | varchar(8) | No | German bank code (column `ABLZ`). If empty or omitted, the current value is kept. |\n| `BankName` | varchar(50) | No | Bank name (column `ABankName`). If empty or omitted, the current value is kept. |\n| `AccName` | varchar(27) | No | Account holder (column `AAccName`). If empty or omitted, the current value is kept. |\n| `BIC` | varchar(11) | No | BIC. If empty or omitted, the current value is kept. |\n| `IBAN` | varchar(35) | No | IBAN. If empty or omitted, the current value is kept. |\n| `ASlocked` | varchar(1) | No | Shipping lock. `1` stores `Y`, any other numeric value stores `N`. If empty or omitted, the current value is kept. Non-numeric values cause a conversion error. |\n| `FunctionResult` | varchar(128) | No | Output: status text, for example `200 OK`. The same text is returned in the column `Result`. |\n| `CardHolderName` | varchar(60) | No | Card holder name (column `ACardName`). If empty or omitted, the current value is kept. |\n| `Note` | varchar(8000) | No | Note on the address. If empty or omitted, the current value is kept. |\n| `VatId` | varchar(20) | No | VAT ID (column `UsStId`). If empty or omitted, the current value is kept. |\n\n- **Pass only one order identifier.** If both `OrderNr` and `OrderNrExternal` are passed, no order line matches. The result is then `402 Address not found`.\n- **Fields cannot be cleared.** Empty values are ignored and the existing value is kept. The exception is `CareOf`: an empty string is written as an empty string.\n- **`ASlocked` must be numeric.** The code compares it with the number 1. A value such as `Y` therefore causes an SQL conversion error, which is returned as `SqlMessage`. Use `1` or `0`.\n- **Lock history.** The history row is only written if the stored `ASlocked` value differs from the new value. If the stored value is NULL, no history row is written. The user ID for the history is the user `api`, or `pixiAdministration` as a fallback.\n- **Orders with several lines.** The address key is taken from one of the order lines; the code does not determine which one. Orders whose lines reference different addresses are not handled specifically.\n- **Reads and transactions.** Order lines and addresses are read with `NOLOCK`. There is no explicit transaction.\n- **Status codes.** The codes 200–403 are plain text codes and not HTTP statuses. If neither changing is allowed nor an address is found, `402` overrides `401`.\n\nDocumentation: https://pixi-api-docs.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": "Adds a free-text comment to an existing order and records the user and timestamp of its creation.\n\nCreates a new entry in the order comments for the given order.\n\nSteps:\n\n1. **Validation:** if `OrderNr` is missing or `0`, or `Comment` is missing or empty, the call returns an error row and does nothing else.\n2. **Order check:** the call counts the orders in `OrderHeader` with the given `OrderNr`. If there is none, it returns an error row that contains the order number.\n3. **Insert:** otherwise it inserts one row into `OrderComments` with the order number, the comment text, the value of `User` as creating employee (`CreateEmp`) and the current server time as `CreateDate`.\n4. It then returns a single row with `ReturnCode` = `SUCCESS`.\n\nEach call adds a new comment. Existing comments are never changed or replaced.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Internal Pixi order number (`OrderHeader.OrderNr`) the comment is attached to. Must be set and not `0`, otherwise an error row is returned. |\n| `Comment` | varchar(max) | No | Text of the comment. Must not be empty, otherwise an error row is returned. |\n| `User` | varchar(50) | No | Name or short code of the user stored as creator of the comment (`CreateEmp`). |\n\n- The header comment in the code says the procedure *gets* order comments; this is wrong. The procedure only inserts a comment.\n- The shape of the result row differs: error rows have the columns `ReturnCode` and `ErrorMsg`, the success row has only `ReturnCode`. Clients should check `ReturnCode` first.\n- No explicit transaction is used. Calling the procedure again creates a duplicate comment, so retries after timeouts can lead to double entries.\n- `CreateDate` is set with `CURRENT_TIMESTAMP`, i.e. the local time of the database server.\n- `Comment` is `varchar`, not `nvarchar`; characters outside the database code page may be lost.\n- Because SQL Server ignores trailing spaces in string comparisons, a comment consisting only of spaces is rejected as empty.\n- Values for `User` longer than 50 characters are truncated by the parameter type.\n- The order is identified only by the internal `OrderNr`; an external order number is not supported.\n\nDocumentation: https://pixi-api-docs.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": "Adds a free-text comment to an existing order and records the user and timestamp of its creation.\n\nCreates a new entry in the order comments for the given order.\n\nSteps:\n\n1. **Validation:** if `OrderNr` is missing or `0`, or `Comment` is missing or empty, the call returns an error row and does nothing else.\n2. **Order check:** the call counts the orders in `OrderHeader` with the given `OrderNr`. If there is none, it returns an error row that contains the order number.\n3. **Insert:** otherwise it inserts one row into `OrderComments` with the order number, the comment text, the value of `User` as creating employee (`CreateEmp`) and the current server time as `CreateDate`.\n4. It then returns a single row with `ReturnCode` = `SUCCESS`.\n\nEach call adds a new comment. Existing comments are never changed or replaced.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Internal Pixi order number (`OrderHeader.OrderNr`) the comment is attached to. Must be set and not `0`, otherwise an error row is returned. |\n| `Comment` | varchar(max) | No | Text of the comment. Must not be empty, otherwise an error row is returned. |\n| `User` | varchar(50) | No | Name or short code of the user stored as creator of the comment (`CreateEmp`). |\n\n- The header comment in the code says the procedure *gets* order comments; this is wrong. The procedure only inserts a comment.\n- The shape of the result row differs: error rows have the columns `ReturnCode` and `ErrorMsg`, the success row has only `ReturnCode`. Clients should check `ReturnCode` first.\n- No explicit transaction is used. Calling the procedure again creates a duplicate comment, so retries after timeouts can lead to double entries.\n- `CreateDate` is set with `CURRENT_TIMESTAMP`, i.e. the local time of the database server.\n- `Comment` is `varchar`, not `nvarchar`; characters outside the database code page may be lost.\n- Because SQL Server ignores trailing spaces in string comparisons, a comment consisting only of spaces is rejected as empty.\n- Values for `User` longer than 50 characters are truncated by the parameter type.\n- The order is identified only by the internal `OrderNr`; an external order number is not supported.\n\nDocumentation: https://pixi-api-docs.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": "Deletes a complete order (Auftrag) if all orderlines are in status ANG, HAL or STO and none is on an active pick list.\n\nDeletes the order identified by `OrderNr` together with its dependent data and returns one status row.\n\n**Checks** (run before any change):\n1. The order header is looked up by `OrderNr`, joined with its orderlines, bank matches, customer account events and pick list items. If no row is found, the result is `404`.\n2. If any orderline has a status other than `ANG`, `HAL` or `STO`, the result is `409`.\n3. If any orderline is on a pick list whose expiry date (`PLHexpiryDate`) lies in the future, the result is `409` with the pick list message. This check runs last, so its message wins if both 409 conditions apply.\n\nIf a check fails, nothing is changed.\n\n**Deletion steps** (inside one transaction):\n- An `OrderHistory` entry with status `NEW` and employee `API` is written for each orderline.\n- The orderlines are **not physically deleted** but detached and reset: `OrderNr`, `CustRef`, `AddrRef`, `ShipAdrRef` become `0`, `Status` becomes `NEW`, `UpdateEmp` becomes `API`, quantity, prices, amounts, discounts, tax and shipping cost are set to `0`, and `ItemRef`, `ShipRef`, `Order_Id`, `BundleOrderlineRef` are set to NULL.\n- Bundle orderlines (`BundleOrderlines`) referenced by the orderlines are deleted.\n- Order header attributes (`OrderHeaderAttribute`) are deleted.\n- Stock reservations (`Reservation`) of the orderlines are deleted.\n- The customer account event linked to the order's bank match is deleted via `Pixi_CA_DeleteEvent` (this may also delete the related invoice, bank matches, customer account matches, DTAUS records or manual bookings).\n- Finally `Pixi_DeleteEmptyOrder` deletes pick list check entries, tag matches, remaining header attributes and the order header itself.\n\nOn success the status row contains `200` and a confirmation text. Unexpected SQL errors are logged and returned as `500` with the SQL error message.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Number of the order (Auftrag) to delete (`OrderHeader.OrderNr`). |\n\n- The candidate data is read with `NOLOCK`; changes use `ROWLOCK`. `XACT_ABORT` is on. If the caller already has an open transaction, a savepoint is used instead of a new transaction.\n- `CONTEXT_INFO` is temporarily set to suppress the triggers on `Orderlines` and `Reservation`; trigger logic for these changes therefore does not run.\n- Pitfall: the procedure creates a unique index on the orderline key of the candidate data. If an orderline appears more than once in the joined data (e.g. several bank matches for the order, or the line is contained in several pick lists, including expired ones), the index creation fails and the call returns `500`.\n- Only one customer account event is deleted (`TOP 1` without sort order) even if several bank matches exist. Whether it may be deleted is decided by `fPixi_CA_canIdeleteEvent`, and invoices are removed by `Pixi_DeleteInvoice`; both are not attached, so their exact behaviour is not documented here.\n- `Pixi_CA_DeleteEvent` rolls back the whole transaction on error and re-raises the message, which then comes back as status `500`.\n- Errors inside `Pixi_DeleteEmptyOrder` are logged there via `log.InsertError` and not re-raised.\n- A 404 or 409 result still opens and commits an empty transaction.\n\nDocumentation: https://pixi-api-docs.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": "Deletes a complete order (Auftrag) if all orderlines are in status ANG, HAL or STO and none is on an active pick list.\n\nDeletes the order identified by `OrderNr` together with its dependent data and returns one status row.\n\n**Checks** (run before any change):\n1. The order header is looked up by `OrderNr`, joined with its orderlines, bank matches, customer account events and pick list items. If no row is found, the result is `404`.\n2. If any orderline has a status other than `ANG`, `HAL` or `STO`, the result is `409`.\n3. If any orderline is on a pick list whose expiry date (`PLHexpiryDate`) lies in the future, the result is `409` with the pick list message. This check runs last, so its message wins if both 409 conditions apply.\n\nIf a check fails, nothing is changed.\n\n**Deletion steps** (inside one transaction):\n- An `OrderHistory` entry with status `NEW` and employee `API` is written for each orderline.\n- The orderlines are **not physically deleted** but detached and reset: `OrderNr`, `CustRef`, `AddrRef`, `ShipAdrRef` become `0`, `Status` becomes `NEW`, `UpdateEmp` becomes `API`, quantity, prices, amounts, discounts, tax and shipping cost are set to `0`, and `ItemRef`, `ShipRef`, `Order_Id`, `BundleOrderlineRef` are set to NULL.\n- Bundle orderlines (`BundleOrderlines`) referenced by the orderlines are deleted.\n- Order header attributes (`OrderHeaderAttribute`) are deleted.\n- Stock reservations (`Reservation`) of the orderlines are deleted.\n- The customer account event linked to the order's bank match is deleted via `Pixi_CA_DeleteEvent` (this may also delete the related invoice, bank matches, customer account matches, DTAUS records or manual bookings).\n- Finally `Pixi_DeleteEmptyOrder` deletes pick list check entries, tag matches, remaining header attributes and the order header itself.\n\nOn success the status row contains `200` and a confirmation text. Unexpected SQL errors are logged and returned as `500` with the SQL error message.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Number of the order (Auftrag) to delete (`OrderHeader.OrderNr`). |\n\n- The candidate data is read with `NOLOCK`; changes use `ROWLOCK`. `XACT_ABORT` is on. If the caller already has an open transaction, a savepoint is used instead of a new transaction.\n- `CONTEXT_INFO` is temporarily set to suppress the triggers on `Orderlines` and `Reservation`; trigger logic for these changes therefore does not run.\n- Pitfall: the procedure creates a unique index on the orderline key of the candidate data. If an orderline appears more than once in the joined data (e.g. several bank matches for the order, or the line is contained in several pick lists, including expired ones), the index creation fails and the call returns `500`.\n- Only one customer account event is deleted (`TOP 1` without sort order) even if several bank matches exist. Whether it may be deleted is decided by `fPixi_CA_canIdeleteEvent`, and invoices are removed by `Pixi_DeleteInvoice`; both are not attached, so their exact behaviour is not documented here.\n- `Pixi_CA_DeleteEvent` rolls back the whole transaction on error and re-raises the message, which then comes back as status `500`.\n- Errors inside `Pixi_DeleteEmptyOrder` are logged there via `log.InsertError` and not re-raised.\n- A 404 or 409 result still opens and commits an empty transaction.\n\nDocumentation: https://pixi-api-docs.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": "Returns the list of all order states with their ID and description, sorted by description.\n\nReturns all entries of the order state table `OrderStates`.\n\n- No parameters, no filters: every defined order state is returned.\n- Each row contains the state code (`orderStatus`) and its text (`StateDesc`).\n- Rows are sorted alphabetically by the state text.\n\nUse the result to translate the status codes returned by other order calls into readable descriptions, or to fill selection lists.\n\n- The table is read with `NOLOCK`, so uncommitted changes may be visible.\n- The procedure was originally written for the eMill integration (tags `Tech_eMill`), but it is a generic lookup.\n- The language of `StateDesc` depends on the content of `OrderStates`; the code does not translate it.\n\nDocumentation: https://pixi-api-docs.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": "Returns the list of all order states with their ID and description, sorted by description.\n\nReturns all entries of the order state table `OrderStates`.\n\n- No parameters, no filters: every defined order state is returned.\n- Each row contains the state code (`orderStatus`) and its text (`StateDesc`).\n- Rows are sorted alphabetically by the state text.\n\nUse the result to translate the status codes returned by other order calls into readable descriptions, or to fill selection lists.\n\n- The table is read with `NOLOCK`, so uncommitted changes may be visible.\n- The procedure was originally written for the eMill integration (tags `Tech_eMill`), but it is a generic lookup.\n- The language of `StateDesc` depends on the content of `OrderStates`; the code does not translate it.\n\nDocumentation: https://pixi-api-docs.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": "Returns the header data of all orders that were created or changed, including changes to their order lines or addresses, since a given point in time.\n\nUse this call for delta synchronisation of orders. It returns one row per changed order.\n\n**Time window**\n\n- The end of the window, `DateTimeTo`, is the server time at execution (`GETDATE()`). It is returned in every row.\n- If `DateTimeFrom` is later than five minutes before the server time, it is moved back to *now minus 5 minutes*. Every call therefore covers at least the last five minutes.\n\n**Which orders count as changed**\n\nAn order is selected if at least one of the following timestamps is at or after `DateTimeFrom` and not after `DateTimeTo`:\n\n1. The order header: `UpdateDate`, or `CreateDate` if the order was never updated.\n2. An order line: its `UpdateDate`, or `CreateDate` for lines that were never updated.\n3. The billing address (`AddrRef`) or the shipping address (`ShipAdrRef`) of the order: `UpdateDate`, or `CreateDate` if never updated.\n\n**Direct fulfillment filter**\n\n- `ReturnOnlyDFOrders = 0` (default): all changed orders are returned.\n- `ReturnOnlyDFOrders = 1`: only changed orders that have at least one order line with an `OrderHistory` entry with status `FUT` are returned.\n\n**Returned data**\n\n- Header fields come from the order header, the customer (`ShopID` is the customer's `CustomerOf`) and the addresses. `PaymentType` is the payment type of the billing address. `OrderLocked` is the lock flag of the shipping address (`N` if empty).\n- Aggregated order line fields per order: `OrderDate`, which is the latest order line date or the earliest one if the setting `UseInitialOrderDate` is `1`; the highest `VoucherID` with its `VoucherAmount`; the currency code `OrderCurrency`; the latest `EstimatedDelivery`.\n- Only orders with an existing customer, billing address and shipping address are returned. The rows are not sorted.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateTimeFrom` | datetime | Yes | Start of the change window. Values later than five minutes before the server time are moved back to now minus 5 minutes. |\n| `skipGetXMLValue` | bit | No | Not used by the code. It has no effect. |\n| `ReturnOnlyDFOrders` | bit | No | Restricts the result to direct fulfillment orders, meaning orders with an order line that has an `OrderHistory` entry with status `FUT`. |\n\n- **Polling:** Pass the `DateTimeTo` value of the previous response as `DateTimeFrom` of the next call. Because of the minimum window of five minutes, the same order can be returned in consecutive calls. Process the rows idempotently.\n- If `DateTimeFrom` is `NULL`, no order matches and the result is empty.\n- **Unused parameter:** `skipGetXMLValue` is declared but not used by the code.\n- **Dirty reads:** All permanent tables are read with `NOLOCK`. Uncommitted data can appear, and rows can be missed or duplicated during concurrent changes.\n- **Setting:** `UseInitialOrderDate` is read from the `Settings` table and controls whether `OrderDate` is the earliest or the latest order line date.\n- **Missing currency:** The order line aggregates (`OrderDate`, `VoucherID`, `VoucherAmount`, `OrderCurrency`, `EstimatedDelivery`) are `NULL` if the order's currency is not found in `pixi.Currency` or the order has no lines.\n- **EstimatedDelivery:** The code compares it with a placeholder date (now + 999 days, including the time of day). In practice this almost never matches, so the value is returned unchanged.\n- **Performance:** The call scans addresses, order headers and order lines by date. Very old `DateTimeFrom` values can produce large results and long run times.\n\nDocumentation: https://pixi-api-docs.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": "Returns the header data of all orders that were created or changed, including changes to their order lines or addresses, since a given point in time.\n\nUse this call for delta synchronisation of orders. It returns one row per changed order.\n\n**Time window**\n\n- The end of the window, `DateTimeTo`, is the server time at execution (`GETDATE()`). It is returned in every row.\n- If `DateTimeFrom` is later than five minutes before the server time, it is moved back to *now minus 5 minutes*. Every call therefore covers at least the last five minutes.\n\n**Which orders count as changed**\n\nAn order is selected if at least one of the following timestamps is at or after `DateTimeFrom` and not after `DateTimeTo`:\n\n1. The order header: `UpdateDate`, or `CreateDate` if the order was never updated.\n2. An order line: its `UpdateDate`, or `CreateDate` for lines that were never updated.\n3. The billing address (`AddrRef`) or the shipping address (`ShipAdrRef`) of the order: `UpdateDate`, or `CreateDate` if never updated.\n\n**Direct fulfillment filter**\n\n- `ReturnOnlyDFOrders = 0` (default): all changed orders are returned.\n- `ReturnOnlyDFOrders = 1`: only changed orders that have at least one order line with an `OrderHistory` entry with status `FUT` are returned.\n\n**Returned data**\n\n- Header fields come from the order header, the customer (`ShopID` is the customer's `CustomerOf`) and the addresses. `PaymentType` is the payment type of the billing address. `OrderLocked` is the lock flag of the shipping address (`N` if empty).\n- Aggregated order line fields per order: `OrderDate`, which is the latest order line date or the earliest one if the setting `UseInitialOrderDate` is `1`; the highest `VoucherID` with its `VoucherAmount`; the currency code `OrderCurrency`; the latest `EstimatedDelivery`.\n- Only orders with an existing customer, billing address and shipping address are returned. The rows are not sorted.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateTimeFrom` | datetime | Yes | Start of the change window. Values later than five minutes before the server time are moved back to now minus 5 minutes. |\n| `skipGetXMLValue` | bit | No | Not used by the code. It has no effect. |\n| `ReturnOnlyDFOrders` | bit | No | Restricts the result to direct fulfillment orders, meaning orders with an order line that has an `OrderHistory` entry with status `FUT`. |\n\n- **Polling:** Pass the `DateTimeTo` value of the previous response as `DateTimeFrom` of the next call. Because of the minimum window of five minutes, the same order can be returned in consecutive calls. Process the rows idempotently.\n- If `DateTimeFrom` is `NULL`, no order matches and the result is empty.\n- **Unused parameter:** `skipGetXMLValue` is declared but not used by the code.\n- **Dirty reads:** All permanent tables are read with `NOLOCK`. Uncommitted data can appear, and rows can be missed or duplicated during concurrent changes.\n- **Setting:** `UseInitialOrderDate` is read from the `Settings` table and controls whether `OrderDate` is the earliest or the latest order line date.\n- **Missing currency:** The order line aggregates (`OrderDate`, `VoucherID`, `VoucherAmount`, `OrderCurrency`, `EstimatedDelivery`) are `NULL` if the order's currency is not found in `pixi.Currency` or the order has no lines.\n- **EstimatedDelivery:** The code compares it with a placeholder date (now + 999 days, including the time of day). In practice this almost never matches, so the value is returned unchanged.\n- **Performance:** The call scans addresses, order headers and order lines by date. Very old `DateTimeFrom` values can produce large results and long run times.\n\nDocumentation: https://pixi-api-docs.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": "Returns orders at a POS location whose order lines are older than the reservation expiry period and have no reservation.\n\nReturns the distinct order numbers and customer references of orders at a POS location whose reservation period has expired.\n\nAn order line is included if all of the following apply:\n\n- `LocationID` of the order line equals `@LocationId` (the POS location).\n- The POS location has a reservation location assigned (`Location.ResLocID`), and that location exists in `Location`.\n- The customer referenced by `CustRef` exists in `Customers`.\n- No entry in `Reservation` exists for the order line (`ResOrderlineRef`).\n- The order line status is `ANG` or `HAL`.\n- More full days have passed since `OrderDate` than the expiry period. The period is `ResExpDays` of the reservation location. If that value is NULL, the global setting `ReservationExpiry` is used.\n- Every order line of the same order has an `ItemLocationSpecific` record for the reservation location. If a single line has no such record, the whole order is excluded.\n\nEach order appears only once. The result is sorted by `ordernr` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocationId` | varchar(50) | No | ID of the POS location (`Location.LocID`) whose order lines are checked. Without a value, no rows are returned. |\n\n- If `LocationId` is omitted (NULL), the comparison `LocationID = NULL` is never true and the result is always empty. Always pass a location.\n- How the expiry period is resolved from the setting `ReservationExpiry`:\n - The setting is read via `fpixi_GetSetting`. That function returns `'0'` when the setting does not exist.\n - A missing setting therefore gives an expiry of 0 days, not 14. Any order line older than one day then qualifies.\n - The fallback of 14 days applies only if the setting exists with an empty value.\n - A non-numeric setting value causes a conversion error.\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- The header comment of the procedure (\"orders ready to pick up\") does not match its name or logic. The behaviour described here follows the code.\n- The procedure only reads data. It does not cancel orders or change any data.\n\nDocumentation: https://pixi-api-docs.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": "Returns orders at a POS location whose order lines are older than the reservation expiry period and have no reservation.\n\nReturns the distinct order numbers and customer references of orders at a POS location whose reservation period has expired.\n\nAn order line is included if all of the following apply:\n\n- `LocationID` of the order line equals `@LocationId` (the POS location).\n- The POS location has a reservation location assigned (`Location.ResLocID`), and that location exists in `Location`.\n- The customer referenced by `CustRef` exists in `Customers`.\n- No entry in `Reservation` exists for the order line (`ResOrderlineRef`).\n- The order line status is `ANG` or `HAL`.\n- More full days have passed since `OrderDate` than the expiry period. The period is `ResExpDays` of the reservation location. If that value is NULL, the global setting `ReservationExpiry` is used.\n- Every order line of the same order has an `ItemLocationSpecific` record for the reservation location. If a single line has no such record, the whole order is excluded.\n\nEach order appears only once. The result is sorted by `ordernr` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocationId` | varchar(50) | No | ID of the POS location (`Location.LocID`) whose order lines are checked. Without a value, no rows are returned. |\n\n- If `LocationId` is omitted (NULL), the comparison `LocationID = NULL` is never true and the result is always empty. Always pass a location.\n- How the expiry period is resolved from the setting `ReservationExpiry`:\n - The setting is read via `fpixi_GetSetting`. That function returns `'0'` when the setting does not exist.\n - A missing setting therefore gives an expiry of 0 days, not 14. Any order line older than one day then qualifies.\n - The fallback of 14 days applies only if the setting exists with an empty value.\n - A non-numeric setting value causes a conversion error.\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- The header comment of the procedure (\"orders ready to pick up\") does not match its name or logic. The behaviour described here follows the code.\n- The procedure only reads data. It does not cancel orders or change any data.\n\nDocumentation: https://pixi-api-docs.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": "Returns the orders that can be merged with a given order: same customer, order type, currency and payment method, all lines in status ANG and not on an active picklist.\n\nFinds candidate orders for merging with the reference order `OrderNr`.\n\n1. The reference order is read from `OrderHeader`: customer (`CustRef`), currency (`CurrencyId`), order type (`OrderType`) and the payment method (`APayment`) of the address linked via `AddrRef`.\n2. Other orders are returned when **all** of the following apply:\n - same customer (`CustRef`), but a different order number;\n - same `OrderType` and same `CurrencyId`;\n - the address of the candidate order has the same payment method as the reference order, and that payment method is not `K` (if the reference order uses `K`, no orders are returned at all);\n - none of the candidate's orderlines is on a picklist item whose picklist has not yet expired (`PLHexpiryDate` later than now) and whose `ReservedOrderNr` is empty or 0;\n - every orderline of the candidate order has status `ANG` (orders without any orderlines are therefore excluded).\n3. The result is sorted by `CreateDate` ascending (oldest order first).\n\nIf the reference order does not exist, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Internal number of the reference order for which mergeable orders are searched. |\n\n- Read-only; all tables are read `WITH (NOLOCK)`, so uncommitted data may be seen.\n- The reference order itself is not checked for line status or picklist assignment; only the candidates are filtered.\n- The meaning of payment method code `K` is not defined in the code; it is simply excluded from merging.\n- The column `ReservedOrderNr` is referenced without table alias; it belongs to either `PLitem` or `PLHeader`, which the code does not make explicit.\n- The call only lists candidates; it does not merge anything.\n\nDocumentation: https://pixi-api-docs.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": "Returns the orders that can be merged with a given order: same customer, order type, currency and payment method, all lines in status ANG and not on an active picklist.\n\nFinds candidate orders for merging with the reference order `OrderNr`.\n\n1. The reference order is read from `OrderHeader`: customer (`CustRef`), currency (`CurrencyId`), order type (`OrderType`) and the payment method (`APayment`) of the address linked via `AddrRef`.\n2. Other orders are returned when **all** of the following apply:\n - same customer (`CustRef`), but a different order number;\n - same `OrderType` and same `CurrencyId`;\n - the address of the candidate order has the same payment method as the reference order, and that payment method is not `K` (if the reference order uses `K`, no orders are returned at all);\n - none of the candidate's orderlines is on a picklist item whose picklist has not yet expired (`PLHexpiryDate` later than now) and whose `ReservedOrderNr` is empty or 0;\n - every orderline of the candidate order has status `ANG` (orders without any orderlines are therefore excluded).\n3. The result is sorted by `CreateDate` ascending (oldest order first).\n\nIf the reference order does not exist, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Internal number of the reference order for which mergeable orders are searched. |\n\n- Read-only; all tables are read `WITH (NOLOCK)`, so uncommitted data may be seen.\n- The reference order itself is not checked for line status or picklist assignment; only the candidates are filtered.\n- The meaning of payment method code `K` is not defined in the code; it is simply excluded from merging.\n- The column `ReservedOrderNr` is referenced without table alias; it belongs to either `PLitem` or `PLHeader`, which the code does not make explicit.\n- The call only lists candidates; it does not merge anything.\n\nDocumentation: https://pixi-api-docs.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": "Returns full details of one or more orders, including addresses, customer, order lines, bundle lines, invoices and customer account entries as nested XML.\n\nCollects a set of order numbers from the three input parameters and returns one row per distinct order number with the order header fields and several nested XML documents.\n\n**Selecting orders** (all parameters can be combined; the results are merged and de-duplicated):\n- `OrderNr`: used directly if it is greater than 0. It is **not** checked against `OrderHeader`.\n- `OrderNrExternal`: every order whose `OrderNrExternal` matches exactly is added.\n- `OrderNrXML`: an XML document with root `OrderNrs`; each `OrderNr` element adds that order number, each `OrderNrExternal` element adds all orders with this external number.\n\nIf no order number is collected, the call returns **no result set** at all.\n\n**Per order the row contains:**\n- Order header fields from `OrderHeader` (shipping vendor, gift message, status, totals, references, flags, `OrderType`, `ShipCost` …).\n- `BillingAddress` and `ShippingAddress`: XML of the address referenced by `AddrRef` / `ShipAdrRef`, enriched with country names and country codes (ISO2, ISO3, Afterbuy, Plenty).\n- `Customer`: XML of the customer referenced by `CustRef`.\n- `Orderlines`: XML of all order lines with currency code (`OrderCurrency`), item data and `PickListNr`.\n- `BundleOrderlines`: XML of the bundle order lines of the order.\n- `Invoices`: XML of all invoices that contain at least one invoice line referencing an order line of this order; each invoice contains its `InvoiceLines`.\n- `CustomerAccount`: XML of customer account entries of the order's customer that either belong to one of these invoices, or have no invoice and are linked to the order via a bank match; sorted by `CustomerAccountKey` ascending.\n- `OnPicklist`: picklist state of the order lines (`None`, `Partial`, `All`).\n- `VoucherID`: the highest `VoucherID` found on the order lines.\n\nThe order of the rows is not defined (no `ORDER BY`).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Internal Pixi order number. Used only if greater than 0. |\n| `OrderNrXML` | varchar(max) | No | XML list of order numbers and/or external order numbers (root `OrderNrs`, children `OrderNr` and `OrderNrExternal`). Malformed XML is ignored. |\n| `OrderNrExternal` | varchar(50) | No | External (shop) order number; all orders with exactly this value are returned. |\n\n- All reads use `NOLOCK`; data can be uncommitted or inconsistent.\n- A non-existing `OrderNr` still produces a row: `OrderNr` is filled, all header fields and XML columns are NULL.\n- Malformed `OrderNrXML` is silently ignored (empty `CATCH`). The XML document handle is never released with `sp_xml_removedocument`.\n- `OnPicklist` logic: `None` if no line is on a picklist, `Partial` if some lines have a picklist and some do not, `All` if all lines are on one or more picklists. It is NULL for orders without order lines.\n- Order lines and bundle lines are joined to `Items` and `Currency` with inner joins; lines whose item no longer exists are missing from the XML.\n- The nested XML uses `FOR XML PATH` without a row name, so every record is a `row` element; NULL values are omitted.\n- Fields ending in `_OrderCurr` (e.g. `Price_OrderCurr`, `Total_OrderCurr`) are duplicates of the base fields and are marked in the code to be removed; do not rely on them.\n- Fetching many orders at once can be expensive because of the many correlated subqueries per order.\n\nDocumentation: https://pixi-api-docs.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": "Returns full details of one or more orders, including addresses, customer, order lines, bundle lines, invoices and customer account entries as nested XML.\n\nCollects a set of order numbers from the three input parameters and returns one row per distinct order number with the order header fields and several nested XML documents.\n\n**Selecting orders** (all parameters can be combined; the results are merged and de-duplicated):\n- `OrderNr`: used directly if it is greater than 0. It is **not** checked against `OrderHeader`.\n- `OrderNrExternal`: every order whose `OrderNrExternal` matches exactly is added.\n- `OrderNrXML`: an XML document with root `OrderNrs`; each `OrderNr` element adds that order number, each `OrderNrExternal` element adds all orders with this external number.\n\nIf no order number is collected, the call returns **no result set** at all.\n\n**Per order the row contains:**\n- Order header fields from `OrderHeader` (shipping vendor, gift message, status, totals, references, flags, `OrderType`, `ShipCost` …).\n- `BillingAddress` and `ShippingAddress`: XML of the address referenced by `AddrRef` / `ShipAdrRef`, enriched with country names and country codes (ISO2, ISO3, Afterbuy, Plenty).\n- `Customer`: XML of the customer referenced by `CustRef`.\n- `Orderlines`: XML of all order lines with currency code (`OrderCurrency`), item data and `PickListNr`.\n- `BundleOrderlines`: XML of the bundle order lines of the order.\n- `Invoices`: XML of all invoices that contain at least one invoice line referencing an order line of this order; each invoice contains its `InvoiceLines`.\n- `CustomerAccount`: XML of customer account entries of the order's customer that either belong to one of these invoices, or have no invoice and are linked to the order via a bank match; sorted by `CustomerAccountKey` ascending.\n- `OnPicklist`: picklist state of the order lines (`None`, `Partial`, `All`).\n- `VoucherID`: the highest `VoucherID` found on the order lines.\n\nThe order of the rows is not defined (no `ORDER BY`).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Internal Pixi order number. Used only if greater than 0. |\n| `OrderNrXML` | varchar(max) | No | XML list of order numbers and/or external order numbers (root `OrderNrs`, children `OrderNr` and `OrderNrExternal`). Malformed XML is ignored. |\n| `OrderNrExternal` | varchar(50) | No | External (shop) order number; all orders with exactly this value are returned. |\n\n- All reads use `NOLOCK`; data can be uncommitted or inconsistent.\n- A non-existing `OrderNr` still produces a row: `OrderNr` is filled, all header fields and XML columns are NULL.\n- Malformed `OrderNrXML` is silently ignored (empty `CATCH`). The XML document handle is never released with `sp_xml_removedocument`.\n- `OnPicklist` logic: `None` if no line is on a picklist, `Partial` if some lines have a picklist and some do not, `All` if all lines are on one or more picklists. It is NULL for orders without order lines.\n- Order lines and bundle lines are joined to `Items` and `Currency` with inner joins; lines whose item no longer exists are missing from the XML.\n- The nested XML uses `FOR XML PATH` without a row name, so every record is a `row` element; NULL values are omitted.\n- Fields ending in `_OrderCurr` (e.g. `Price_OrderCurr`, `Total_OrderCurr`) are duplicates of the base fields and are marked in the code to be removed; do not rely on them.\n- Fetching many orders at once can be expensive because of the many correlated subqueries per order.\n\nDocumentation: https://pixi-api-docs.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": "Returns orders that were created, changed, invoiced or scanned out within a time window, with one row per detected change.\n\nCollects change events for orders in the time window from `DateFrom` (inclusive) to `DateTo` (exclusive) and returns them as a flat list. It is meant for polling clients that synchronise orders into an external system.\n\nIf `DateFrom` is not given, it defaults to the current time minus one day. If `DateTo` is not given, it defaults to the current time.\n\nDepending on `ChangeType`, one or all of these checks run:\n\n- `CORDER`: order headers whose `CreateDate` is in the window. `Param1` is empty.\n- `UORDER`: order headers whose `UpdateDate` is in the window. `Param1` is empty.\n- `CORDERL`: order lines whose `CreateDate` is in the window. One row per order line; `Param1` holds the `OrderlineKey`.\n- `UORDERL`: order lines whose `UpdateDate` is in the window. One row per order line; `Param1` holds the `OrderlineKey`.\n- `IORDER`: invoices whose `InvDate` is in the window. One row per order and invoice; `Param1` holds the `InvoiceNr`.\n- `SORDER`: invoices whose `ScanOutDate` is in the window. One row per order and invoice; `Param1` holds the `InvoiceNr`.\n\n`ALL` (default) runs all six checks.\n\nOptional filters:\n\n- `ShopID`: for header events, the shop of the order address (`AddrShopId`). For line events, the shop of the order line (`OrdShopID`). For invoice events, the shop of the invoice (`InvShopID`).\n- `PaymentType`: for header and line events, the payment type of the address (`APayment`). For invoice events, the payment type of the invoice (`Payment`).\n\nOnly rows with `OrderNr` > 0 are returned. Rows are sorted by `OrderNr`, then `ChangeType`, then `Param1`, all ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ChangeType` | varchar(10) | No | Type of change to report. `ALL` returns all types. |\n| `ShopID` | varchar(3) | No | Optional shop filter. It is applied to the address shop, the order line shop or the invoice shop, depending on the change type. `NULL` returns all shops. |\n| `PaymentType` | char(1) | No | Optional payment type filter. It is applied to the address payment type (`APayment`) or the invoice payment type (`Payment`). `NULL` returns all payment types. |\n| `DateFrom` | datetime | No | Start of the time window (inclusive). Defaults to the current time minus one day. |\n| `DateTo` | datetime | No | End of the time window (exclusive). Defaults to the current time. |\n\n- All reads use `NOLOCK`, so uncommitted changes can appear and rows can be missed or duplicated under concurrent load.\n- The window is half-open (`>= DateFrom`, `< DateTo`). Use the previous `DateTo` as the next `DateFrom` to poll without gaps or overlaps.\n- Results are not de-duplicated. The same order can appear several times: with several change types, with several order lines or with several invoices.\n- `CORDER`/`UORDER` use an inner join on the order address. Order headers without a matching address are not reported.\n- `Param1` is a `varchar`, so it sorts as text: `OrderlineKey` and `InvoiceNr` values sort alphabetically, not numerically.\n- An unknown `ChangeType` value raises no error; it simply returns an empty result.\n- No error rows are produced.\n\nDocumentation: https://pixi-api-docs.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": "Returns orders that were created, changed, invoiced or scanned out within a time window, with one row per detected change.\n\nCollects change events for orders in the time window from `DateFrom` (inclusive) to `DateTo` (exclusive) and returns them as a flat list. It is meant for polling clients that synchronise orders into an external system.\n\nIf `DateFrom` is not given, it defaults to the current time minus one day. If `DateTo` is not given, it defaults to the current time.\n\nDepending on `ChangeType`, one or all of these checks run:\n\n- `CORDER`: order headers whose `CreateDate` is in the window. `Param1` is empty.\n- `UORDER`: order headers whose `UpdateDate` is in the window. `Param1` is empty.\n- `CORDERL`: order lines whose `CreateDate` is in the window. One row per order line; `Param1` holds the `OrderlineKey`.\n- `UORDERL`: order lines whose `UpdateDate` is in the window. One row per order line; `Param1` holds the `OrderlineKey`.\n- `IORDER`: invoices whose `InvDate` is in the window. One row per order and invoice; `Param1` holds the `InvoiceNr`.\n- `SORDER`: invoices whose `ScanOutDate` is in the window. One row per order and invoice; `Param1` holds the `InvoiceNr`.\n\n`ALL` (default) runs all six checks.\n\nOptional filters:\n\n- `ShopID`: for header events, the shop of the order address (`AddrShopId`). For line events, the shop of the order line (`OrdShopID`). For invoice events, the shop of the invoice (`InvShopID`).\n- `PaymentType`: for header and line events, the payment type of the address (`APayment`). For invoice events, the payment type of the invoice (`Payment`).\n\nOnly rows with `OrderNr` > 0 are returned. Rows are sorted by `OrderNr`, then `ChangeType`, then `Param1`, all ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ChangeType` | varchar(10) | No | Type of change to report. `ALL` returns all types. |\n| `ShopID` | varchar(3) | No | Optional shop filter. It is applied to the address shop, the order line shop or the invoice shop, depending on the change type. `NULL` returns all shops. |\n| `PaymentType` | char(1) | No | Optional payment type filter. It is applied to the address payment type (`APayment`) or the invoice payment type (`Payment`). `NULL` returns all payment types. |\n| `DateFrom` | datetime | No | Start of the time window (inclusive). Defaults to the current time minus one day. |\n| `DateTo` | datetime | No | End of the time window (exclusive). Defaults to the current time. |\n\n- All reads use `NOLOCK`, so uncommitted changes can appear and rows can be missed or duplicated under concurrent load.\n- The window is half-open (`>= DateFrom`, `< DateTo`). Use the previous `DateTo` as the next `DateFrom` to poll without gaps or overlaps.\n- Results are not de-duplicated. The same order can appear several times: with several change types, with several order lines or with several invoices.\n- `CORDER`/`UORDER` use an inner join on the order address. Order headers without a matching address are not reported.\n- `Param1` is a `varchar`, so it sorts as text: `OrderlineKey` and `InvoiceNr` values sort alphabetically, not numerically.\n- An unknown `ChangeType` value raises no error; it simply returns an empty result.\n- No error rows are produced.\n\nDocumentation: https://pixi-api-docs.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": "Returns the comments of orders created after a given date, optionally filtered by Pixi order number or shop order number.\n\nReturns the comments stored for orders, together with the order numbers they belong to.\n\n**Parameter handling**\n- `OrderNr` = `0` is treated as not set (`NULL`).\n- An empty `OrderNrShop` is treated as not set (`NULL`).\n- `RowCount` is limited to the range 1 to 1000. A value that is `NULL`, smaller than 1 or greater than 1000 is replaced by `1000`.\n- `Since` defaults to `2000-01-01` if it is `NULL`.\n\n**Filter**\n- Only comments whose `CreateDate` is **strictly later** than `Since` are returned.\n- If neither `OrderNr` nor `OrderNrShop` is set, comments of all orders are returned.\n- If `OrderNr` is set, comments of the order with this Pixi order number are returned.\n- If `OrderNrShop` is set, comments of orders whose external (shop) order number `OrderNrExternal` matches are returned.\n- If both are set, they are combined with **OR**: comments of either order are returned.\n\n**Sorting and limit**\n\nThe rows are sorted by `CreateDate` ascending, and at most `RowCount` rows are returned. This allows incremental retrieval: pass the `CreateDate` of the last row received as `Since` in the next call.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. `0` or `NULL` means no filter on this number. |\n| `OrderNrShop` | varchar(50) | No | External (shop) order number, compared with `OrderNrExternal`. Empty or `NULL` means no filter on this number. |\n| `Since` | datetime | No | Only comments created strictly after this point in time are returned. `NULL` is replaced by `2000-01-01`. |\n| `RowCount` | int | No | Maximum number of rows to return (1 to 1000). Values outside this range or `NULL` are replaced by 1000. |\n\n- Both tables are read with `NOLOCK`, so uncommitted data may be returned or rows may be missed during concurrent changes.\n- The sort order has no tie-breaker beyond `CreateDate`. When paging with `Since` = last `CreateDate`, comments with exactly the same `CreateDate` as the last returned row are skipped because the filter is strictly greater (`>`). If a page ends in the middle of rows sharing one timestamp, those remaining rows are lost.\n- The maximum page size is 1000 rows; larger values for `RowCount` do not raise an error but are silently reset to 1000.\n- Only comments whose order exists in `OrderHeader` are returned (inner join).\n- A `Since` value of `1900-01-01` (the value of an empty datetime) is also replaced by `2000-01-01`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the comments of orders created after a given date, optionally filtered by Pixi order number or shop order number.\n\nReturns the comments stored for orders, together with the order numbers they belong to.\n\n**Parameter handling**\n- `OrderNr` = `0` is treated as not set (`NULL`).\n- An empty `OrderNrShop` is treated as not set (`NULL`).\n- `RowCount` is limited to the range 1 to 1000. A value that is `NULL`, smaller than 1 or greater than 1000 is replaced by `1000`.\n- `Since` defaults to `2000-01-01` if it is `NULL`.\n\n**Filter**\n- Only comments whose `CreateDate` is **strictly later** than `Since` are returned.\n- If neither `OrderNr` nor `OrderNrShop` is set, comments of all orders are returned.\n- If `OrderNr` is set, comments of the order with this Pixi order number are returned.\n- If `OrderNrShop` is set, comments of orders whose external (shop) order number `OrderNrExternal` matches are returned.\n- If both are set, they are combined with **OR**: comments of either order are returned.\n\n**Sorting and limit**\n\nThe rows are sorted by `CreateDate` ascending, and at most `RowCount` rows are returned. This allows incremental retrieval: pass the `CreateDate` of the last row received as `Since` in the next call.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. `0` or `NULL` means no filter on this number. |\n| `OrderNrShop` | varchar(50) | No | External (shop) order number, compared with `OrderNrExternal`. Empty or `NULL` means no filter on this number. |\n| `Since` | datetime | No | Only comments created strictly after this point in time are returned. `NULL` is replaced by `2000-01-01`. |\n| `RowCount` | int | No | Maximum number of rows to return (1 to 1000). Values outside this range or `NULL` are replaced by 1000. |\n\n- Both tables are read with `NOLOCK`, so uncommitted data may be returned or rows may be missed during concurrent changes.\n- The sort order has no tie-breaker beyond `CreateDate`. When paging with `Since` = last `CreateDate`, comments with exactly the same `CreateDate` as the last returned row are skipped because the filter is strictly greater (`>`). If a page ends in the middle of rows sharing one timestamp, those remaining rows are lost.\n- The maximum page size is 1000 rows; larger values for `RowCount` do not raise an error but are silently reset to 1000.\n- Only comments whose order exists in `OrderHeader` are returned (inner join).\n- A `Since` value of `1900-01-01` (the value of an empty datetime) is also replaced by `2000-01-01`.\n\nDocumentation: https://pixi-api-docs.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": "Returns order headers with customer, billing and shipping address, invoice, shipment, voucher and tag data, selected by order number, external order number or filters.\n\nThe call selects order headers in one of three modes and returns one row per order.\n\n**Parameter normalisation**\n- `OrderNr` = 0, `CustKey` = 0 and empty strings for `OrderNrExternal`, `ShopID`, `PaymentType`, `ShippingCountry` are treated as *not set*.\n- Date parameters (`FromTime`, `UntilTime`, `FromUpdateTime`) that lie more than 100 years in the past (e.g. `1900-01-01`) are treated as *not set*.\n- `RowCount` = NULL becomes 1000.\n\n**Selection modes** (the first matching rule wins)\n1. `OrderNr` set: the order with this `OrderNr`. Optionally restricted by `CustKey` and `ShopID` (the customer's `CustomerOf`). All other filters are ignored.\n2. `OrderNrExternal` set: orders with this external order number, optionally restricted by `CustKey` and `ShopID`. All other filters are ignored.\n3. Any of `FromTime`, `UntilTime`, `ShopID`, `PaymentType`, `ShippingCountry`, `CustKey`, `FromUpdateTime` set: filter search, combined with AND:\n - `OrderDate` > `FromTime` and `OrderDate` < `UntilTime` (both exclusive)\n - `UpdateDate` > `FromUpdateTime` (exclusive)\n - `CustRef` = `CustKey`\n - customer's `CustomerOf` = `ShopID`\n - country of the shipping address = `ShippingCountry`\n - payment type (`APayment`) of the billing address = `PaymentType`\n \n At most `RowCount` orders are taken, oldest `CreateDate` first.\n4. No parameter set: an empty result is returned (backward compatibility).\n\n**Returned data**\n- Header fields from the order, customer data, billing address payment/bank data and shipping address name/address data.\n- Aggregates over the order lines: `Shipdate`/`LastShipdate` (earliest/latest `ScanOutDate` of linked invoices), `TrackingID`, `ShipVendor`, `LastInvoiceNr` (highest invoice number), `VoucherID` (highest voucher ID on the lines) with `VoucherAmount` from the voucher table, `EstimatedDelivery` (latest estimated delivery date) and `TotalDiscount` (sum of `DiscountValue` × `Qty` for lines not in status `STO` or `NLB`).\n- Only invoices that are not credit notes (no reference to another invoice) are considered. Lines in status `MIN` are always considered; other lines only if the invoice line quantity is > 0 or no invoice line exists.\n- `Gender` is derived from the salutation of the shipping address: 1 for `Herr`, `Hr.`, `M.`, `Monsieur`, `Mr`, `Mr.`; 2 for `Mrs`, `Mrs.`, `Ms`, `Ms.`, `Frau`, `Fr.`; otherwise 0.\n- `Tags` contains the names of the order's tags, sorted by name and separated by `|`.\n\nThe rows are sorted by `CreateDate` ascending and limited to `RowCount`. If no order matches, an empty result set with the same columns is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. If set (not 0), exactly this order is searched (mode 1); only `CustKey` and `ShopID` are applied as additional restrictions. |\n| `OrderNrExternal` | varchar(50) | No | External order number (e.g. shop order number). Used if `OrderNr` is not set (mode 2); only `CustKey` and `ShopID` are applied as additional restrictions. |\n| `CustKey` | int | No | Customer key. Restricts the result to orders of this customer. 0 is treated as not set. |\n| `FromTime` | datetime | No | Filter search only: returns orders with `OrderDate` later than this value (exclusive). Dates more than 100 years in the past are ignored. |\n| `UntilTime` | datetime | No | Filter search only: returns orders with `OrderDate` earlier than this value (exclusive). Dates more than 100 years in the past are ignored. |\n| `ShopID` | char(3) | No | Shop ID. Restricts the result to orders of customers whose `CustomerOf` equals this value. Applied in all modes. |\n| `PaymentType` | char(1) | No | Filter search only: payment type code of the billing address (`APayment`). |\n| `ShippingCountry` | varchar(3) | No | Filter search only: country code of the shipping address. |\n| `RowCount` | int | No | Maximum number of orders returned. NULL is treated as 1000. |\n| `FromUpdateTime` | datetime | No | Filter search only: returns orders with `UpdateDate` later than this value (exclusive). Dates more than 100 years in the past are ignored. |\n\n- All tables are read `WITH (NOLOCK)`; uncommitted data may be returned.\n- The filter search (mode 3) is built as dynamic SQL; only the set filters are added to the `WHERE` clause.\n- For paging/incremental export use `FromUpdateTime` or `FromTime` together with `RowCount`. Note that the selection is ordered by `CreateDate`, not by `UpdateDate`, and the time filters are exclusive (`>`/`<`).\n- `RowCount` = 0 returns no rows; a negative value causes a SQL error from `TOP`.\n- Orders without matching currency, customer, billing address or shipping address record are not returned (inner joins). Orders without order lines are returned with empty aggregate columns.\n- If an order line is linked to several invoice lines, its discount is counted once per invoice line in `TotalDiscount`.\n- `OrderTotal_OrderCurr` contains the same value as `OrderTotal`. `OrderLocked` comes from the lock flag of the shipping address (`N` if empty). `CustomerNr` is the customer's DATEV account number.\n- The settings `NumberOfDecimalPlacesForPrices` and `UseInitialOrderDate` are read but do not affect the result.\n- If the call runs longer than 5 seconds, the parameters and the dynamic SQL are passed to `LOG.EventDurationInsert` (definition not attached; presumably writes a duration log entry).\n\nDocumentation: https://pixi-api-docs.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": "Returns order headers with customer, billing and shipping address, invoice, shipment, voucher and tag data, selected by order number, external order number or filters.\n\nThe call selects order headers in one of three modes and returns one row per order.\n\n**Parameter normalisation**\n- `OrderNr` = 0, `CustKey` = 0 and empty strings for `OrderNrExternal`, `ShopID`, `PaymentType`, `ShippingCountry` are treated as *not set*.\n- Date parameters (`FromTime`, `UntilTime`, `FromUpdateTime`) that lie more than 100 years in the past (e.g. `1900-01-01`) are treated as *not set*.\n- `RowCount` = NULL becomes 1000.\n\n**Selection modes** (the first matching rule wins)\n1. `OrderNr` set: the order with this `OrderNr`. Optionally restricted by `CustKey` and `ShopID` (the customer's `CustomerOf`). All other filters are ignored.\n2. `OrderNrExternal` set: orders with this external order number, optionally restricted by `CustKey` and `ShopID`. All other filters are ignored.\n3. Any of `FromTime`, `UntilTime`, `ShopID`, `PaymentType`, `ShippingCountry`, `CustKey`, `FromUpdateTime` set: filter search, combined with AND:\n - `OrderDate` > `FromTime` and `OrderDate` < `UntilTime` (both exclusive)\n - `UpdateDate` > `FromUpdateTime` (exclusive)\n - `CustRef` = `CustKey`\n - customer's `CustomerOf` = `ShopID`\n - country of the shipping address = `ShippingCountry`\n - payment type (`APayment`) of the billing address = `PaymentType`\n \n At most `RowCount` orders are taken, oldest `CreateDate` first.\n4. No parameter set: an empty result is returned (backward compatibility).\n\n**Returned data**\n- Header fields from the order, customer data, billing address payment/bank data and shipping address name/address data.\n- Aggregates over the order lines: `Shipdate`/`LastShipdate` (earliest/latest `ScanOutDate` of linked invoices), `TrackingID`, `ShipVendor`, `LastInvoiceNr` (highest invoice number), `VoucherID` (highest voucher ID on the lines) with `VoucherAmount` from the voucher table, `EstimatedDelivery` (latest estimated delivery date) and `TotalDiscount` (sum of `DiscountValue` × `Qty` for lines not in status `STO` or `NLB`).\n- Only invoices that are not credit notes (no reference to another invoice) are considered. Lines in status `MIN` are always considered; other lines only if the invoice line quantity is > 0 or no invoice line exists.\n- `Gender` is derived from the salutation of the shipping address: 1 for `Herr`, `Hr.`, `M.`, `Monsieur`, `Mr`, `Mr.`; 2 for `Mrs`, `Mrs.`, `Ms`, `Ms.`, `Frau`, `Fr.`; otherwise 0.\n- `Tags` contains the names of the order's tags, sorted by name and separated by `|`.\n\nThe rows are sorted by `CreateDate` ascending and limited to `RowCount`. If no order matches, an empty result set with the same columns is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. If set (not 0), exactly this order is searched (mode 1); only `CustKey` and `ShopID` are applied as additional restrictions. |\n| `OrderNrExternal` | varchar(50) | No | External order number (e.g. shop order number). Used if `OrderNr` is not set (mode 2); only `CustKey` and `ShopID` are applied as additional restrictions. |\n| `CustKey` | int | No | Customer key. Restricts the result to orders of this customer. 0 is treated as not set. |\n| `FromTime` | datetime | No | Filter search only: returns orders with `OrderDate` later than this value (exclusive). Dates more than 100 years in the past are ignored. |\n| `UntilTime` | datetime | No | Filter search only: returns orders with `OrderDate` earlier than this value (exclusive). Dates more than 100 years in the past are ignored. |\n| `ShopID` | char(3) | No | Shop ID. Restricts the result to orders of customers whose `CustomerOf` equals this value. Applied in all modes. |\n| `PaymentType` | char(1) | No | Filter search only: payment type code of the billing address (`APayment`). |\n| `ShippingCountry` | varchar(3) | No | Filter search only: country code of the shipping address. |\n| `RowCount` | int | No | Maximum number of orders returned. NULL is treated as 1000. |\n| `FromUpdateTime` | datetime | No | Filter search only: returns orders with `UpdateDate` later than this value (exclusive). Dates more than 100 years in the past are ignored. |\n\n- All tables are read `WITH (NOLOCK)`; uncommitted data may be returned.\n- The filter search (mode 3) is built as dynamic SQL; only the set filters are added to the `WHERE` clause.\n- For paging/incremental export use `FromUpdateTime` or `FromTime` together with `RowCount`. Note that the selection is ordered by `CreateDate`, not by `UpdateDate`, and the time filters are exclusive (`>`/`<`).\n- `RowCount` = 0 returns no rows; a negative value causes a SQL error from `TOP`.\n- Orders without matching currency, customer, billing address or shipping address record are not returned (inner joins). Orders without order lines are returned with empty aggregate columns.\n- If an order line is linked to several invoice lines, its discount is counted once per invoice line in `TotalDiscount`.\n- `OrderTotal_OrderCurr` contains the same value as `OrderTotal`. `OrderLocked` comes from the lock flag of the shipping address (`N` if empty). `CustomerNr` is the customer's DATEV account number.\n- The settings `NumberOfDecimalPlacesForPrices` and `UseInitialOrderDate` are read but do not affect the result.\n- If the call runs longer than 5 seconds, the parameters and the dynamic SQL are passed to `LOG.EventDurationInsert` (definition not attached; presumably writes a duration log entry).\n\nDocumentation: https://pixi-api-docs.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": "Returns header data for several orders identified by their external order numbers, including customer, address, payment, shipping and invoice information.\n\nTakes a list of external order numbers (`OrderNrExternal`) as XML and returns one row per matching order from `OrderHeader`.\n\n**Steps:**\n\n1. The XML is split into values. Every child element of the root element is read, whatever its name. Duplicate values are removed.\n2. If the list is empty, the procedure prints `No Data!` and returns **no result set**.\n3. Two settings are read:\n - `UseInitialOrderDate`: if `1`, `OrderDate` is the earliest order date of the order lines, otherwise the latest.\n - `NumberOfDecimalPlacesForPrices`: number of decimals used to round `Qty * Price` per order line (default `2` if the setting is missing or `0`).\n4. Orders are matched on `OrderHeader.OrderNrExternal`. External numbers that do not match an order are skipped without notice.\n5. An order is returned only if it has a currency, a customer, a billing address (`AddrRef`) and a shipping address (`ShipAdrRef`). These joins are inner joins.\n6. Per order, the order lines are aggregated together with their invoice lines, their invoices (only invoices with `RefToInvoiceKey IS NULL`) and their estimated delivery dates:\n - shipping dates (min/max `ScanOutDate`), tracking ID, carrier, last invoice number;\n - `Paid`/`PayedSum` from the invoices;\n - `OrderTotal_OrderCurr` = sum of rounded `Qty * Price` of all lines except status `STO` and `NLB`, plus `ShipCost`, minus `Discount`.\n7. `Gender` is derived from the salutation (`Anrede`) of the shipping address:\n - `1` for `Herr`, `Hr.`, `M.`, `Monsieur`, `Mr`, `Mr.`\n - `2` for `Mrs`, `Mrs.`, `Ms`, `Ms.`, `Frau`, `Fr.`\n - `0` for any other value.\n\nThe result is sorted by `CreateDate` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNrExternalXml` | xml | Yes | XML list of external order numbers. Each child element of the root element holds one number. Element names are not checked; the code comment uses `…`. |\n\n- Read-only. Most tables are read `WITH (NOLOCK)`, so uncommitted data can appear. The subquery for `OrderLocked` on `Addresses` runs without `NOLOCK`.\n- Values are shredded as `varchar(256)` but stored in a `varchar(50)` key column. An external order number longer than 50 characters can make the call fail with a truncation error.\n- Empty input does not return an error row. It only produces the PRINT message `No Data!` and no rows.\n- `EstimatedDelivery` is filled only if **every** order line has an estimated delivery date. In that case the latest date is returned. If any line has no date, the column is `NULL`. Internally, a placeholder date of now + 999 days is used for missing dates and then turned back into `NULL`.\n- `Paid` is computed per joined line. Order lines that have no invoice also count as paid, so `Paid` can be `1` even if the order is not invoiced at all. `PayedSum` is the highest paid sum among invoices whose `PayedSum` equals their total rounded to 2 decimals.\n- The order lines are joined to invoice lines and estimated delivery rows. If one order line has several invoice lines or several delivery rows, it is counted more than once in `OrderTotal_OrderCurr`.\n- Line prices come from `Price` (not the order-currency price), although the column is called `OrderTotal_OrderCurr`.\n- The source table of `SubShopName` and `SubShopLogo` is not qualified in the code. Most likely they come from `OrderHeader`.\n- `Gender` mapping uses exact matches on the salutation. Whether the match is case-sensitive depends on the database collation.\n\nDocumentation: https://pixi-api-docs.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": "Returns header data for several orders identified by their external order numbers, including customer, address, payment, shipping and invoice information.\n\nTakes a list of external order numbers (`OrderNrExternal`) as XML and returns one row per matching order from `OrderHeader`.\n\n**Steps:**\n\n1. The XML is split into values. Every child element of the root element is read, whatever its name. Duplicate values are removed.\n2. If the list is empty, the procedure prints `No Data!` and returns **no result set**.\n3. Two settings are read:\n - `UseInitialOrderDate`: if `1`, `OrderDate` is the earliest order date of the order lines, otherwise the latest.\n - `NumberOfDecimalPlacesForPrices`: number of decimals used to round `Qty * Price` per order line (default `2` if the setting is missing or `0`).\n4. Orders are matched on `OrderHeader.OrderNrExternal`. External numbers that do not match an order are skipped without notice.\n5. An order is returned only if it has a currency, a customer, a billing address (`AddrRef`) and a shipping address (`ShipAdrRef`). These joins are inner joins.\n6. Per order, the order lines are aggregated together with their invoice lines, their invoices (only invoices with `RefToInvoiceKey IS NULL`) and their estimated delivery dates:\n - shipping dates (min/max `ScanOutDate`), tracking ID, carrier, last invoice number;\n - `Paid`/`PayedSum` from the invoices;\n - `OrderTotal_OrderCurr` = sum of rounded `Qty * Price` of all lines except status `STO` and `NLB`, plus `ShipCost`, minus `Discount`.\n7. `Gender` is derived from the salutation (`Anrede`) of the shipping address:\n - `1` for `Herr`, `Hr.`, `M.`, `Monsieur`, `Mr`, `Mr.`\n - `2` for `Mrs`, `Mrs.`, `Ms`, `Ms.`, `Frau`, `Fr.`\n - `0` for any other value.\n\nThe result is sorted by `CreateDate` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNrExternalXml` | xml | Yes | XML list of external order numbers. Each child element of the root element holds one number. Element names are not checked; the code comment uses `…`. |\n\n- Read-only. Most tables are read `WITH (NOLOCK)`, so uncommitted data can appear. The subquery for `OrderLocked` on `Addresses` runs without `NOLOCK`.\n- Values are shredded as `varchar(256)` but stored in a `varchar(50)` key column. An external order number longer than 50 characters can make the call fail with a truncation error.\n- Empty input does not return an error row. It only produces the PRINT message `No Data!` and no rows.\n- `EstimatedDelivery` is filled only if **every** order line has an estimated delivery date. In that case the latest date is returned. If any line has no date, the column is `NULL`. Internally, a placeholder date of now + 999 days is used for missing dates and then turned back into `NULL`.\n- `Paid` is computed per joined line. Order lines that have no invoice also count as paid, so `Paid` can be `1` even if the order is not invoiced at all. `PayedSum` is the highest paid sum among invoices whose `PayedSum` equals their total rounded to 2 decimals.\n- The order lines are joined to invoice lines and estimated delivery rows. If one order line has several invoice lines or several delivery rows, it is counted more than once in `OrderTotal_OrderCurr`.\n- Line prices come from `Price` (not the order-currency price), although the column is called `OrderTotal_OrderCurr`.\n- The source table of `SubShopName` and `SubShopLogo` is not qualified in the code. Most likely they come from `OrderHeader`.\n- `Gender` mapping uses exact matches on the salutation. Whether the match is case-sensitive depends on the database collation.\n\nDocumentation: https://pixi-api-docs.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": "Returns order headers with payment, shipping, voucher and tracking data for all orders that have order lines with an order date in the given range.\n\nReturns one row per order header for all orders that have at least one order line whose `Orderdate` lies between `FromDate` and `ToDate` (inclusive, `BETWEEN`).\n\n**Filter**\n- `ShopID` restricts the order lines to those whose `CustomerOF` equals the given shop. An empty string is treated like `NULL`, which means all shops.\n- Only orders for which a customer, a payment address (`AddrRef`) and a currency exist are returned (inner joins on `Customers`, `Addresses` and `pixi.Currency`).\n\n**Building the result**\n1. Basic data is taken from the order header, the customer, the payment address (bank and credit card data, ZIP) and the currency (`CurrencyCode`). `OrderLocked` is the lock flag of the shipping address, `N` if none is found.\n2. `PaymentType` is filled from the payment type of the payment address.\n3. `OrderNrExternal`, `OrderDate`, `VoucherID` and `VoucherAmount` are taken from the order lines (and the voucher), `ShipCost` from the order header.\n4. `TrackingID` (shipment tracking ID, otherwise the Direct-Fulfillment tracking ID) and `ShipVendor` are taken from the invoices of the order's lines.\n5. `Shipdate` is the earliest and `LastShipdate` the latest scan-out date of all invoices belonging to the order's lines.\n\nThe result is sorted by `OrderDate` ascending. There is no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Yes | Start of the range for the order date of the order lines (inclusive). |\n| `ToDate` | datetime | Yes | End of the range for the order date of the order lines (inclusive). |\n| `ShopID` | varchar(3) | No | Shop ID used to filter the order lines (`CustomerOF`). `NULL` or an empty string returns orders of all shops. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- `BETWEEN` is inclusive: if `ToDate` is a date without time (midnight), order lines later on that day are not included. Pass e.g. `2024-01-31T23:59:59` to cover the whole day.\n- The shop filter applies to `CustomerOF` of the order lines, while the returned `ShopID` is the `CustomerOf` of the customer.\n- For orders with several lines or several invoices, `OrderNrExternal`, `OrderDate`, `VoucherID`, `VoucherAmount`, `TrackingID` and `ShipVendor` are taken from an arbitrary matching row. `OrderDate` may therefore come from a line outside the requested date range.\n- `Shipdate`, `LastShipdate`, `TrackingID` and `ShipVendor` are `NULL` as long as no invoice exists.\n- The result contains sensitive payment data (credit card number, bank account) of the payment address.\n- No paging: large date ranges can produce large results and run slowly.\n\nDocumentation: https://pixi-api-docs.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": "Returns order headers with payment, shipping, voucher and tracking data for all orders that have order lines with an order date in the given range.\n\nReturns one row per order header for all orders that have at least one order line whose `Orderdate` lies between `FromDate` and `ToDate` (inclusive, `BETWEEN`).\n\n**Filter**\n- `ShopID` restricts the order lines to those whose `CustomerOF` equals the given shop. An empty string is treated like `NULL`, which means all shops.\n- Only orders for which a customer, a payment address (`AddrRef`) and a currency exist are returned (inner joins on `Customers`, `Addresses` and `pixi.Currency`).\n\n**Building the result**\n1. Basic data is taken from the order header, the customer, the payment address (bank and credit card data, ZIP) and the currency (`CurrencyCode`). `OrderLocked` is the lock flag of the shipping address, `N` if none is found.\n2. `PaymentType` is filled from the payment type of the payment address.\n3. `OrderNrExternal`, `OrderDate`, `VoucherID` and `VoucherAmount` are taken from the order lines (and the voucher), `ShipCost` from the order header.\n4. `TrackingID` (shipment tracking ID, otherwise the Direct-Fulfillment tracking ID) and `ShipVendor` are taken from the invoices of the order's lines.\n5. `Shipdate` is the earliest and `LastShipdate` the latest scan-out date of all invoices belonging to the order's lines.\n\nThe result is sorted by `OrderDate` ascending. There is no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Yes | Start of the range for the order date of the order lines (inclusive). |\n| `ToDate` | datetime | Yes | End of the range for the order date of the order lines (inclusive). |\n| `ShopID` | varchar(3) | No | Shop ID used to filter the order lines (`CustomerOF`). `NULL` or an empty string returns orders of all shops. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- `BETWEEN` is inclusive: if `ToDate` is a date without time (midnight), order lines later on that day are not included. Pass e.g. `2024-01-31T23:59:59` to cover the whole day.\n- The shop filter applies to `CustomerOF` of the order lines, while the returned `ShopID` is the `CustomerOf` of the customer.\n- For orders with several lines or several invoices, `OrderNrExternal`, `OrderDate`, `VoucherID`, `VoucherAmount`, `TrackingID` and `ShipVendor` are taken from an arbitrary matching row. `OrderDate` may therefore come from a line outside the requested date range.\n- `Shipdate`, `LastShipdate`, `TrackingID` and `ShipVendor` are `NULL` as long as no invoice exists.\n- The result contains sensitive payment data (credit card number, bank account) of the payment address.\n- No paging: large date ranges can produce large results and run slowly.\n\nDocumentation: https://pixi-api-docs.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": "Returns the order headers of a customer, identified by customer key or by external customer number or e-mail, with payment, voucher and shipping data.\n\nReturns one row per order (`OrderHeader`) of a customer, sorted by `OrderDate` descending.\n\n**Customer selection**\n- If `CustKey` is not `0`, only orders with `CustRef = CustKey` are returned. `CustomerNrExternal` and `ShopID` are ignored in this case.\n- If `CustKey` is `0` (default), orders of all customers whose `CustomerNrExternal` **or** e-mail address (`CeMail`) equals `CustomerNrExternal` are returned. If `ShopID` is given, the customer must also belong to that shop (`CustomerOf`). An empty `ShopID` is treated as `NULL` (no shop filter).\n\n**Further filters**\n- `OrderDateFrom`: only orders with `OrderDate` on or after this value. `NULL` or empty means `1900-01-01`.\n- `OrderStatus`: `OPEN`, `HOLD` or `CLOSED` filters on the order status. Any other value (or `NULL`) disables the status filter.\n\n**Returned data per order**\n- Header data such as order number, external order number, totals, ship cost, shop note, address remarks and currency code (`OrderCurrencyCode` from the currency of the order).\n- Payment data from the payment address (`AddrRef`): payment type, credit card and bank account fields, ZIP.\n- `ShopID` is the shop the **customer** belongs to (`CustomerOf`).\n- `OrderLocked` is the lock flag (`ASlocked`) of the shipping address, `N` if not set.\n- `VoucherID` / `VoucherAmount`: highest voucher ID and highest voucher amount found on the order lines (vouchers referenced by order lines); `NULL` if the order has no voucher.\n- `Shipdate` / `LastShipdate`: earliest and latest scan-out date of all invoices linked to the order lines.\n- `TrackingID` / `ShipVendor`: taken from the invoice with the highest `InvoiceKey`; the tracking ID falls back to the drop-shipment tracking ID of the order line if the invoice has none. `NULL` if the order has not been invoiced.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | No | Internal customer key. If not `0`, orders are selected by this key and `CustomerNrExternal`/`ShopID` are ignored. |\n| `CustomerNrExternal` | varchar(60) | No | External customer number or customer e-mail address. Used only if `CustKey` is `0`. |\n| `ShopID` | varchar(3) | No | Shop the customer must belong to. Used only if `CustKey` is `0`; empty or `NULL` means all shops. |\n| `OrderStatus` | varchar(10) | No | Optional filter on the order status. Other values than the listed ones disable the filter. |\n| `OrderDateFrom` | datetime | No | Only orders with an order date on or after this value. `NULL` or empty means `1900-01-01`. |\n\n- All tables are read `WITH (NOLOCK)`; results may contain uncommitted data.\n- If `CustKey` is `0` and `CustomerNrExternal` is left empty, the filter matches customers with an empty external customer number or an empty e-mail address. Always pass either `CustKey` or a non-empty `CustomerNrExternal`.\n- Because the e-mail address is also matched, several customers (e.g. in different shops) can match; use `ShopID` to restrict.\n- The intermediate temporary table has unique indexes on `OrderNr` and `AddrRef`. If two selected orders share the same payment address or more than one has `OrderNr` `NULL`, the call fails with a SQL duplicate-key error.\n- `VoucherID` and `VoucherAmount` are aggregated independently with `MAX`; with several vouchers on one order they may come from different vouchers.\n- If the latest invoice has several lines with different fallback tracking IDs, the selection is not deterministic and an order may in rare cases appear more than once.\n- The result contains sensitive payment data (card number, bank account).\n\nDocumentation: https://pixi-api-docs.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": "Returns the order headers of a customer, identified by customer key or by external customer number or e-mail, with payment, voucher and shipping data.\n\nReturns one row per order (`OrderHeader`) of a customer, sorted by `OrderDate` descending.\n\n**Customer selection**\n- If `CustKey` is not `0`, only orders with `CustRef = CustKey` are returned. `CustomerNrExternal` and `ShopID` are ignored in this case.\n- If `CustKey` is `0` (default), orders of all customers whose `CustomerNrExternal` **or** e-mail address (`CeMail`) equals `CustomerNrExternal` are returned. If `ShopID` is given, the customer must also belong to that shop (`CustomerOf`). An empty `ShopID` is treated as `NULL` (no shop filter).\n\n**Further filters**\n- `OrderDateFrom`: only orders with `OrderDate` on or after this value. `NULL` or empty means `1900-01-01`.\n- `OrderStatus`: `OPEN`, `HOLD` or `CLOSED` filters on the order status. Any other value (or `NULL`) disables the status filter.\n\n**Returned data per order**\n- Header data such as order number, external order number, totals, ship cost, shop note, address remarks and currency code (`OrderCurrencyCode` from the currency of the order).\n- Payment data from the payment address (`AddrRef`): payment type, credit card and bank account fields, ZIP.\n- `ShopID` is the shop the **customer** belongs to (`CustomerOf`).\n- `OrderLocked` is the lock flag (`ASlocked`) of the shipping address, `N` if not set.\n- `VoucherID` / `VoucherAmount`: highest voucher ID and highest voucher amount found on the order lines (vouchers referenced by order lines); `NULL` if the order has no voucher.\n- `Shipdate` / `LastShipdate`: earliest and latest scan-out date of all invoices linked to the order lines.\n- `TrackingID` / `ShipVendor`: taken from the invoice with the highest `InvoiceKey`; the tracking ID falls back to the drop-shipment tracking ID of the order line if the invoice has none. `NULL` if the order has not been invoiced.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | No | Internal customer key. If not `0`, orders are selected by this key and `CustomerNrExternal`/`ShopID` are ignored. |\n| `CustomerNrExternal` | varchar(60) | No | External customer number or customer e-mail address. Used only if `CustKey` is `0`. |\n| `ShopID` | varchar(3) | No | Shop the customer must belong to. Used only if `CustKey` is `0`; empty or `NULL` means all shops. |\n| `OrderStatus` | varchar(10) | No | Optional filter on the order status. Other values than the listed ones disable the filter. |\n| `OrderDateFrom` | datetime | No | Only orders with an order date on or after this value. `NULL` or empty means `1900-01-01`. |\n\n- All tables are read `WITH (NOLOCK)`; results may contain uncommitted data.\n- If `CustKey` is `0` and `CustomerNrExternal` is left empty, the filter matches customers with an empty external customer number or an empty e-mail address. Always pass either `CustKey` or a non-empty `CustomerNrExternal`.\n- Because the e-mail address is also matched, several customers (e.g. in different shops) can match; use `ShopID` to restrict.\n- The intermediate temporary table has unique indexes on `OrderNr` and `AddrRef`. If two selected orders share the same payment address or more than one has `OrderNr` `NULL`, the call fails with a SQL duplicate-key error.\n- `VoucherID` and `VoucherAmount` are aggregated independently with `MAX`; with several vouchers on one order they may come from different vouchers.\n- If the latest invoice has several lines with different fallback tracking IDs, the selection is not deterministic and an order may in rare cases appear more than once.\n- The result contains sensitive payment data (card number, bank account).\n\nDocumentation: https://pixi-api-docs.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": "Returns one order number whose order lines reference the given address key as billing or shipping address.\n\nLooks up an order number for an address key. According to the code comment, it is used for desktop notifications.\n\n- Searches the table `Orderlines` for rows where `AddrRef` (billing address) **or** `ShipAdrRef` (shipping address) equals `@AddrKey`.\n- Only rows with `OrderNr > 0` are considered.\n- Returns at most one row (`TOP 1`) with the column `OrderNr`.\n\nIf no matching order line exists, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AddrKey` | int | Yes | Address key. It is compared with the billing address reference `AddrRef` and the shipping address reference `ShipAdrRef` of the order lines. |\n\n- `TOP 1` is used without `ORDER BY`. If several orders reference the same address, which order number is returned is not defined and can change between calls.\n- The table is read `WITH (NOLOCK)`, so uncommitted data may be visible.\n- The lookup works on order lines, not on an order header table. Orders without order lines are not found.\n\nDocumentation: https://pixi-api-docs.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": "Returns one order number whose order lines reference the given address key as billing or shipping address.\n\nLooks up an order number for an address key. According to the code comment, it is used for desktop notifications.\n\n- Searches the table `Orderlines` for rows where `AddrRef` (billing address) **or** `ShipAdrRef` (shipping address) equals `@AddrKey`.\n- Only rows with `OrderNr > 0` are considered.\n- Returns at most one row (`TOP 1`) with the column `OrderNr`.\n\nIf no matching order line exists, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AddrKey` | int | Yes | Address key. It is compared with the billing address reference `AddrRef` and the shipping address reference `ShipAdrRef` of the order lines. |\n\n- `TOP 1` is used without `ORDER BY`. If several orders reference the same address, which order number is returned is not defined and can change between calls.\n- The table is read `WITH (NOLOCK)`, so uncommitted data may be visible.\n- The lookup works on order lines, not on an order header table. Orders without order lines are not found.\n\nDocumentation: https://pixi-api-docs.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": "Returns the Pixi order number (OrderNr) for an external order number, or 0 if no matching order exists.\n\nScalar function that resolves an external order number (for example the order number of an online shop) to the internal Pixi order number.\n\n- Searches the order lines (`Orderlines`) whose `OrderNrExternal` equals `OrderNrExternal` exactly.\n- Joins each matching line to its order header (`OrderHeader`) via `OrderNr`, so only orders that still have a header are considered.\n- If several orders match, the highest `OrderNr` is returned.\n- If nothing matches, `0` is returned instead of NULL.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNrExternal` | varchar(50) | Yes | External order number as stored in `Orderlines.OrderNrExternal`; compared for exact equality. |\n\n- The external order number is read from the order lines, not from the order header. An order without lines is not found.\n- Both tables are read `WITH(NOLOCK)`, so uncommitted data may be seen.\n- If the same external number was used for several orders, only the highest `OrderNr` is returned; other matches are silently ignored.\n- Passing NULL never matches and returns `0`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the Pixi order number (OrderNr) for an external order number, or 0 if no matching order exists.\n\nScalar function that resolves an external order number (for example the order number of an online shop) to the internal Pixi order number.\n\n- Searches the order lines (`Orderlines`) whose `OrderNrExternal` equals `OrderNrExternal` exactly.\n- Joins each matching line to its order header (`OrderHeader`) via `OrderNr`, so only orders that still have a header are considered.\n- If several orders match, the highest `OrderNr` is returned.\n- If nothing matches, `0` is returned instead of NULL.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNrExternal` | varchar(50) | Yes | External order number as stored in `Orderlines.OrderNrExternal`; compared for exact equality. |\n\n- The external order number is read from the order lines, not from the order header. An order without lines is not found.\n- Both tables are read `WITH(NOLOCK)`, so uncommitted data may be seen.\n- If the same external number was used for several orders, only the highest `OrderNr` is returned; other matches are silently ignored.\n- Passing NULL never matches and returns `0`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the Pixi order numbers and external order numbers of all orders that have order lines packed in a given box.\n\nLooks up a box by its number and returns the orders whose order lines are contained in that box.\n\n- The box is identified by `BoxNr` from the `boxes` table.\n- The box items (`boxitems`) are linked to their order lines (`Orderlines`) and the order lines to the order header (`OrderHeader`).\n- If `LocId` is given, only boxes of that location (`LocationID`) are considered. An empty string is treated like `NULL`, so all locations are searched.\n- The result is `DISTINCT`: each order appears only once, even if several of its lines are in the box. A box can contain lines of several orders, so more than one row can be returned.\n- No explicit sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BoxNr` | int | Yes | Number of the box (`boxes.BoxNr`) whose orders are to be returned. |\n| `LocId` | varchar(3) | No | Optional location ID to restrict the box search to one location (`boxes.LocationID`). `NULL` or empty string searches all locations. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- If no box with the given number exists (or it belongs to a different location), or the box contains no order lines, an empty result set is returned; there is no error row.\n- `OrderNrExternal` is returned as an empty string if the order has no external order number. The `ISNULL` on `OrderNr` has no practical effect because of the inner joins.\n- Without `LocId`, boxes with the same number at different locations are all included.\n\nDocumentation: https://pixi-api-docs.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": "Returns the Pixi order numbers and external order numbers of all orders that have order lines packed in a given box.\n\nLooks up a box by its number and returns the orders whose order lines are contained in that box.\n\n- The box is identified by `BoxNr` from the `boxes` table.\n- The box items (`boxitems`) are linked to their order lines (`Orderlines`) and the order lines to the order header (`OrderHeader`).\n- If `LocId` is given, only boxes of that location (`LocationID`) are considered. An empty string is treated like `NULL`, so all locations are searched.\n- The result is `DISTINCT`: each order appears only once, even if several of its lines are in the box. A box can contain lines of several orders, so more than one row can be returned.\n- No explicit sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BoxNr` | int | Yes | Number of the box (`boxes.BoxNr`) whose orders are to be returned. |\n| `LocId` | varchar(3) | No | Optional location ID to restrict the box search to one location (`boxes.LocationID`). `NULL` or empty string searches all locations. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- If no box with the given number exists (or it belongs to a different location), or the box contains no order lines, an empty result set is returned; there is no error row.\n- `OrderNrExternal` is returned as an empty string if the order has no external order number. The `ISNULL` on `OrderNr` has no practical effect because of the inner joins.\n- Without `LocId`, boxes with the same number at different locations are all included.\n\nDocumentation: https://pixi-api-docs.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": "Returns orders with their shipping address whose delivery date (ShipDate) is a given number of days ahead, equals a given date, or lies in the future.\n\nSelects orders from `OrderHeader` joined with their shipping address (`Addresses` via `ShipAdrRef`) and returns order number, order date, delivery date, shipping vendor and the shipping address fields.\n\nThe date filter is a combination of three alternatives joined with **OR**:\n\n- `DaysToDeliveryDate`: orders whose `ShipDate` lies exactly this many calendar days after today (day boundaries via `DATEDIFF(DAY, ...)`; `0` = today, negative values = past days).\n- `DeliveryDate`: orders whose `ShipDate` is **exactly equal** to the given datetime value.\n- If both `DaysToDeliveryDate` and `DeliveryDate` are omitted, all orders whose `ShipDate` is later than the current date and time are returned.\n\nIf both date parameters are passed, orders matching either of them are returned.\n\nAdditional filters (combined with AND):\n\n- `ShipVendor`: only orders with this `ShipVendorCode`.\n- `ShopID`: only orders whose shipping address has this `AddrShopID`.\n\nNo sort order is defined; rows are returned in arbitrary order. There is no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DaysToDeliveryDate` | int | No | Number of calendar days from today to the delivery date (`ShipDate`). `0` = today, `1` = tomorrow. Combined with `DeliveryDate` by OR. |\n| `DeliveryDate` | datetime | No | Exact delivery date; matched by equality with `ShipDate` including the time part. Combined with `DaysToDeliveryDate` by OR. |\n| `ShipVendor` | varchar(3) | No | Shipping vendor code (`ShipVendorCode`) to filter by. `NULL` = all vendors. |\n| `ShopID` | varchar(3) | No | Shop ID of the shipping address (`AddrShopID`) to filter by. `NULL` = all shops. |\n\n- `DeliveryDate` is compared with `ShipDate` by exact equality including the time part. If `ShipDate` contains a time component, pass the exact value or use `DaysToDeliveryDate` instead.\n- The shop filter uses the shop of the shipping address (`AddrShopID`), not a shop field of the order header.\n- Orders without a matching shipping address are not returned (inner join).\n- The order status is not filtered, so cancelled or already shipped orders can be included.\n- Without any parameters, all orders with a future delivery date are returned, which can be a large result.\n- The header comment of the procedure (\"Template for getting items...\") is a leftover and does not describe the procedure.\n\nDocumentation: https://pixi-api-docs.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": "Returns orders with their shipping address whose delivery date (ShipDate) is a given number of days ahead, equals a given date, or lies in the future.\n\nSelects orders from `OrderHeader` joined with their shipping address (`Addresses` via `ShipAdrRef`) and returns order number, order date, delivery date, shipping vendor and the shipping address fields.\n\nThe date filter is a combination of three alternatives joined with **OR**:\n\n- `DaysToDeliveryDate`: orders whose `ShipDate` lies exactly this many calendar days after today (day boundaries via `DATEDIFF(DAY, ...)`; `0` = today, negative values = past days).\n- `DeliveryDate`: orders whose `ShipDate` is **exactly equal** to the given datetime value.\n- If both `DaysToDeliveryDate` and `DeliveryDate` are omitted, all orders whose `ShipDate` is later than the current date and time are returned.\n\nIf both date parameters are passed, orders matching either of them are returned.\n\nAdditional filters (combined with AND):\n\n- `ShipVendor`: only orders with this `ShipVendorCode`.\n- `ShopID`: only orders whose shipping address has this `AddrShopID`.\n\nNo sort order is defined; rows are returned in arbitrary order. There is no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DaysToDeliveryDate` | int | No | Number of calendar days from today to the delivery date (`ShipDate`). `0` = today, `1` = tomorrow. Combined with `DeliveryDate` by OR. |\n| `DeliveryDate` | datetime | No | Exact delivery date; matched by equality with `ShipDate` including the time part. Combined with `DaysToDeliveryDate` by OR. |\n| `ShipVendor` | varchar(3) | No | Shipping vendor code (`ShipVendorCode`) to filter by. `NULL` = all vendors. |\n| `ShopID` | varchar(3) | No | Shop ID of the shipping address (`AddrShopID`) to filter by. `NULL` = all shops. |\n\n- `DeliveryDate` is compared with `ShipDate` by exact equality including the time part. If `ShipDate` contains a time component, pass the exact value or use `DaysToDeliveryDate` instead.\n- The shop filter uses the shop of the shipping address (`AddrShopID`), not a shop field of the order header.\n- Orders without a matching shipping address are not returned (inner join).\n- The order status is not filtered, so cancelled or already shipped orders can be included.\n- Without any parameters, all orders with a future delivery date are returned, which can be a large result.\n- The header comment of the procedure (\"Template for getting items...\") is a leftover and does not describe the procedure.\n\nDocumentation: https://pixi-api-docs.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": "Returns the orders with reserved order lines that customers can pick up at a given POS location, together with the customer reference.\n\nLists orders that are ready for pickup by the customer at a point-of-sale location.\n\nAn order is returned if it has at least one order line that meets all of these conditions:\n\n- the order line's `LocationID` equals `LocationId`;\n- the line's location exists in `Location` and has a reservation location (`ResLocID`) that also exists in `Location`;\n- the line's `CustRef` refers to an existing customer in `Customers`;\n- a reservation exists for the line in `Reservation` (`ResOrderlineRef` = order line key);\n- the line status is `ANG` or `HAL`;\n- the order date is not older than the reservation expiry in days: `ResExpDays` of the reservation location, or, if that is NULL, the value of the setting `ReservationExpiry`.\n\nIn addition, the whole order is excluded if **any** of its order lines refers to an item that has no `ItemLocationSpecific` record for the reservation location. Only the existence of that record is checked, not stock quantities.\n\nThe result is distinct per order number and customer and is sorted by order number in ascending order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocationId` | varchar(50) | No | ID of the POS location (`Location.LocID`) whose order lines are checked. Must be set; with NULL no rows are returned. |\n\n- If `LocationId` is omitted (NULL), the comparison with `LocationID` never matches and the result is always empty. Always pass a location.\n- Pitfall with the expiry fallback: the code falls back to 14 days only if the setting `ReservationExpiry` returns an empty string. `fPIXI_GetSetting` returns `'0'` when the setting does not exist, so without the setting and without `ResExpDays` on the reservation location only orders dated today are returned.\n- The expiry is measured in calendar days between the order date and the current server date (`DATEDIFF` in days).\n- All tables are read with `NOLOCK`, so uncommitted data may appear.\n- Read only; no data is changed.\n\nDocumentation: https://pixi-api-docs.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": "Returns the orders with reserved order lines that customers can pick up at a given POS location, together with the customer reference.\n\nLists orders that are ready for pickup by the customer at a point-of-sale location.\n\nAn order is returned if it has at least one order line that meets all of these conditions:\n\n- the order line's `LocationID` equals `LocationId`;\n- the line's location exists in `Location` and has a reservation location (`ResLocID`) that also exists in `Location`;\n- the line's `CustRef` refers to an existing customer in `Customers`;\n- a reservation exists for the line in `Reservation` (`ResOrderlineRef` = order line key);\n- the line status is `ANG` or `HAL`;\n- the order date is not older than the reservation expiry in days: `ResExpDays` of the reservation location, or, if that is NULL, the value of the setting `ReservationExpiry`.\n\nIn addition, the whole order is excluded if **any** of its order lines refers to an item that has no `ItemLocationSpecific` record for the reservation location. Only the existence of that record is checked, not stock quantities.\n\nThe result is distinct per order number and customer and is sorted by order number in ascending order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocationId` | varchar(50) | No | ID of the POS location (`Location.LocID`) whose order lines are checked. Must be set; with NULL no rows are returned. |\n\n- If `LocationId` is omitted (NULL), the comparison with `LocationID` never matches and the result is always empty. Always pass a location.\n- Pitfall with the expiry fallback: the code falls back to 14 days only if the setting `ReservationExpiry` returns an empty string. `fPIXI_GetSetting` returns `'0'` when the setting does not exist, so without the setting and without `ResExpDays` on the reservation location only orders dated today are returned.\n- The expiry is measured in calendar days between the order date and the current server date (`DATEDIFF` in days).\n- All tables are read with `NOLOCK`, so uncommitted data may appear.\n- Read only; no data is changed.\n\nDocumentation: https://pixi-api-docs.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": "Returns the order lines of an order together with the order totals, VAT and shipping amounts, matching what the invoice would produce.\n\nLooks up an order and returns one row per order line, with the order header totals repeated on every row.\n\n**Selecting the order**\n- If `OrderNr` is set (not `0`/`NULL`), the lines of that Pixi order number are used. `OrderNrExternal` is then ignored.\n- Otherwise, if `OrderNrExternal` is not empty, the lines with that external order number are used.\n- If neither is given, nothing is found.\n- `CustKey` optionally restricts the result to lines of that customer. `0` or `NULL` disables this filter.\n\n**Joins**\n\nThe lines must have a matching article, billing address, shipping address, customer, shop of the customer, payment method of the billing address, order header and order currency. Lines that miss any of these are not returned.\n\n**Status evaluation**\n- If no lines are found, a single row with `ErrorMessage` = `No results found` is returned.\n- If all found lines have status `STO` (cancelled), a single row with `ErrorMessage` = `Only orderlines with status STO found` is returned.\n- Otherwise all lines whose status is not `STO` are returned with line values (EAN, supplier item number, name, quantity, price, net values, note) and header values (order total, discount, VAT total/high/low including shipping cost VAT, net total of the lines, shipping cost gross and net, tax rates, currency code).\n\nNo sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. Takes precedence over `OrderNrExternal`; `0` means not set. |\n| `OrderNrExternal` | varchar(50) | No | External (shop) order number. Used only if `OrderNr` is `0` or `NULL`; empty means not set. |\n| `CustKey` | int | No | Optional customer key; restricts the result to lines of this customer. `0` or `NULL` disables the filter. |\n\n- All tables are read with `NOLOCK`, so uncommitted data can be returned.\n- Header values (`OrderTotal`, `Discount`, `VATTotal`, `ShipCost` etc.) are repeated on every line row; do not sum them across rows.\n- `VATTotal`, `VATHigh` and `VATLow` include the VAT on shipping costs, while `NettoTotal` is the net total of the order lines only and does not include shipping.\n- Several amounts are rounded to 2 decimals and converted to `float`.\n- Lines with a `NULL` status are counted neither as cancelled nor as not cancelled and are not returned.\n- The first result set has a different structure depending on the outcome: either the line columns or a single `ErrorMessage` column. Check for `ErrorMessage` before reading the data.\n- Only cancelled lines are excluded from the output; the status itself is not returned.\n\nDocumentation: https://pixi-api-docs.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": "Returns the order lines of an order together with the order totals, VAT and shipping amounts, matching what the invoice would produce.\n\nLooks up an order and returns one row per order line, with the order header totals repeated on every row.\n\n**Selecting the order**\n- If `OrderNr` is set (not `0`/`NULL`), the lines of that Pixi order number are used. `OrderNrExternal` is then ignored.\n- Otherwise, if `OrderNrExternal` is not empty, the lines with that external order number are used.\n- If neither is given, nothing is found.\n- `CustKey` optionally restricts the result to lines of that customer. `0` or `NULL` disables this filter.\n\n**Joins**\n\nThe lines must have a matching article, billing address, shipping address, customer, shop of the customer, payment method of the billing address, order header and order currency. Lines that miss any of these are not returned.\n\n**Status evaluation**\n- If no lines are found, a single row with `ErrorMessage` = `No results found` is returned.\n- If all found lines have status `STO` (cancelled), a single row with `ErrorMessage` = `Only orderlines with status STO found` is returned.\n- Otherwise all lines whose status is not `STO` are returned with line values (EAN, supplier item number, name, quantity, price, net values, note) and header values (order total, discount, VAT total/high/low including shipping cost VAT, net total of the lines, shipping cost gross and net, tax rates, currency code).\n\nNo sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. Takes precedence over `OrderNrExternal`; `0` means not set. |\n| `OrderNrExternal` | varchar(50) | No | External (shop) order number. Used only if `OrderNr` is `0` or `NULL`; empty means not set. |\n| `CustKey` | int | No | Optional customer key; restricts the result to lines of this customer. `0` or `NULL` disables the filter. |\n\n- All tables are read with `NOLOCK`, so uncommitted data can be returned.\n- Header values (`OrderTotal`, `Discount`, `VATTotal`, `ShipCost` etc.) are repeated on every line row; do not sum them across rows.\n- `VATTotal`, `VATHigh` and `VATLow` include the VAT on shipping costs, while `NettoTotal` is the net total of the order lines only and does not include shipping.\n- Several amounts are rounded to 2 decimals and converted to `float`.\n- Lines with a `NULL` status are counted neither as cancelled nor as not cancelled and are not returned.\n- The first result set has a different structure depending on the outcome: either the line columns or a single `ErrorMessage` column. Check for `ErrorMessage` before reading the data.\n- Only cancelled lines are excluded from the output; the status itself is not returned.\n\nDocumentation: https://pixi-api-docs.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": "Returns the partial delivery settings of an order: whether partial delivery is active, unavailable items are cancelled and the remainder is also shipped partially.\n\nReads the order header identified by `OrderNr` and returns its partial delivery flags.\n\n- `PartialDeliveryActive` comes from `ForceToPicklistIfNotFULL`. If that value is NULL, the call returns `0`.\n- `CancelUnavailableItems` comes from `OHCancelAfterForcedShipOut`.\n- `PartialDeliveryForRemaining` comes from `OHMultiForceToPicklist`.\n\nIf no order with this number exists, the call returns an empty result set.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Internal order number (`OrderHeader.OrderNr`) of the order to check. |\n\n- The table is read with `NOLOCK`, so uncommitted changes may be visible.\n- No error row is returned for an unknown order number; check whether the result set contains a row.\n\nDocumentation: https://pixi-api-docs.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": "Returns the partial delivery settings of an order: whether partial delivery is active, unavailable items are cancelled and the remainder is also shipped partially.\n\nReads the order header identified by `OrderNr` and returns its partial delivery flags.\n\n- `PartialDeliveryActive` comes from `ForceToPicklistIfNotFULL`. If that value is NULL, the call returns `0`.\n- `CancelUnavailableItems` comes from `OHCancelAfterForcedShipOut`.\n- `PartialDeliveryForRemaining` comes from `OHMultiForceToPicklist`.\n\nIf no order with this number exists, the call returns an empty result set.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Internal order number (`OrderHeader.OrderNr`) of the order to check. |\n\n- The table is read with `NOLOCK`, so uncommitted changes may be visible.\n- No error row is returned for an unknown order number; check whether the result set contains a row.\n\nDocumentation: https://pixi-api-docs.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": "Returns the order lines of orders that can be shipped completely from stock, or a summary of those orders.\n\nWrapper around `pipiReportGetShippableOrders`. `ShowDetails` is converted to a bit and passed as `@ViewDetails`. The remaining options are fixed: no partial deliveries, no shop filter, `@IncludeOrdersWithAnyShipDate = 0`, per-location output off.\n\n**Which orders are considered**\n- Order lines with status `ANG` or `EIN`, an item reference (`ItemRef` not NULL) and `Qty > 0`.\n- The order must belong to an existing customer.\n- Neither the shipping address nor the billing address of the order may be locked (`ASlocked = 'Y'`).\n- The order must not be locked (`OhSLocked = 'Y'`).\n- The ship date must be empty or earlier than tomorrow. Orders with a ship date in the future are excluded.\n\n**Stock check**\n- Stock is calculated per line by `pixi_CalculateStockForOrderLines`, using the locations with `SpecialStock = 0`.\n- Only **complete orders** are returned. If a single line of an order is not shippable, the whole order is left out.\n\n**Output**\n- `ShowDetails` ≠ 0 (default `1`): one row per order line, sorted by `OrderNr` and `OrderlineRef`.\n- `ShowDetails` = 0 or NULL: a single summary row with the number of orders, the order total (sum of `Price * Qty`), the summed shipping cost and the number of picks (sum of `Qty`).\n\n**Currency**\n- If the setting `MultiCurrencyEnabled` is active, prices and shipping costs are converted into the database currency. The conversion uses the exchange rate of the same date, and the currency code is returned in `dbCurrency`.\n- Otherwise the values stay in the order currency and `dbCurrency` is NULL.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShowDetails` | int | No | Controls the output. Any non-zero value returns one row per order line; 0 or NULL returns one summary row. |\n\n- All reads use `NOLOCK`, so results may include uncommitted data.\n- The stock calculation in `pixi_CalculateStockForOrderLines` is not attached, so its exact rules (reservations, minimum stock) cannot be documented here. It is called with `@SkipZeroStockItemsCalc = 1`.\n- With multi-currency enabled, the code divides by 1 if no matching exchange rate is found. In that case the value silently stays in the order currency.\n- In detail mode, `ShipCost` is the shipping cost of the whole order and is repeated on every line. Do not add it up per line.\n- In summary mode, shipping costs are summed over distinct `OrderNr`/`ShipCost` pairs.\n- If no orders qualify, the summary row still returns `Orders = 0` and `ShipCost = 0`; `OrderTotal` and `Picks` are then NULL.\n- For partial deliveries, shop filters or per-location output, call `pixiReportGetShippableOrders` directly.\n\nDocumentation: https://pixi-api-docs.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": "Returns the order lines of orders that can be shipped completely from stock, or a summary of those orders.\n\nWrapper around `pipiReportGetShippableOrders`. `ShowDetails` is converted to a bit and passed as `@ViewDetails`. The remaining options are fixed: no partial deliveries, no shop filter, `@IncludeOrdersWithAnyShipDate = 0`, per-location output off.\n\n**Which orders are considered**\n- Order lines with status `ANG` or `EIN`, an item reference (`ItemRef` not NULL) and `Qty > 0`.\n- The order must belong to an existing customer.\n- Neither the shipping address nor the billing address of the order may be locked (`ASlocked = 'Y'`).\n- The order must not be locked (`OhSLocked = 'Y'`).\n- The ship date must be empty or earlier than tomorrow. Orders with a ship date in the future are excluded.\n\n**Stock check**\n- Stock is calculated per line by `pixi_CalculateStockForOrderLines`, using the locations with `SpecialStock = 0`.\n- Only **complete orders** are returned. If a single line of an order is not shippable, the whole order is left out.\n\n**Output**\n- `ShowDetails` ≠ 0 (default `1`): one row per order line, sorted by `OrderNr` and `OrderlineRef`.\n- `ShowDetails` = 0 or NULL: a single summary row with the number of orders, the order total (sum of `Price * Qty`), the summed shipping cost and the number of picks (sum of `Qty`).\n\n**Currency**\n- If the setting `MultiCurrencyEnabled` is active, prices and shipping costs are converted into the database currency. The conversion uses the exchange rate of the same date, and the currency code is returned in `dbCurrency`.\n- Otherwise the values stay in the order currency and `dbCurrency` is NULL.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShowDetails` | int | No | Controls the output. Any non-zero value returns one row per order line; 0 or NULL returns one summary row. |\n\n- All reads use `NOLOCK`, so results may include uncommitted data.\n- The stock calculation in `pixi_CalculateStockForOrderLines` is not attached, so its exact rules (reservations, minimum stock) cannot be documented here. It is called with `@SkipZeroStockItemsCalc = 1`.\n- With multi-currency enabled, the code divides by 1 if no matching exchange rate is found. In that case the value silently stays in the order currency.\n- In detail mode, `ShipCost` is the shipping cost of the whole order and is repeated on every line. Do not add it up per line.\n- In summary mode, shipping costs are summed over distinct `OrderNr`/`ShipCost` pairs.\n- If no orders qualify, the summary row still returns `Orders = 0` and `ShipCost = 0`; `OrderTotal` and `Picks` are then NULL.\n- For partial deliveries, shop filters or per-location output, call `pixiReportGetShippableOrders` directly.\n\nDocumentation: https://pixi-api-docs.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": "Returns the shipped orders (invoiced with history status EIN) for a date range, either as detail rows or as order count and total per currency.\n\nDetermines all invoices of a period that count as shipped and returns them either in detail or aggregated.\n\n**Selection of invoices**\n- An invoice qualifies if at least one of its invoice lines (`Invlines`) refers to an order line that has an `OrderHistory` entry with status `EIN`.\n- The period is checked with `BETWEEN @FromDate AND @ToDate` against `Invoices.InvDate` (default) or against `Invoices.ScanOutDate` if `SearchByScanOutDate = 1`.\n- By default only invoices with `total > 0` are returned; with `IncludeOrdersWithTotalZero = 1` invoices with `total >= 0` are included. Negative totals are never returned.\n- If `CustomerNrExternal` is filled (it is trimmed; an empty value means no filter), only invoices of the customer with that external customer number are returned.\n\nFor each selected invoice the distinct external order numbers (`Orderlines.OrderNrExternal`) of its lines are determined.\n\n**`ShowDetails = 1` (default)**\nReturns one row per combination of invoice and external order number, sorted by `InvDate`. An invoice that covers several orders therefore appears several times. The rows contain invoice data, shipping address, currency, carrier, tracking ID and the employee who scanned the invoice out (`ScanOutEmp`: alphabetically smallest `UpdateEmp` of the `OrderHistory` entries with status `AUS`).\n\n**Any other value of `ShowDetails`**\nReturns one row per currency with the number of orders (invoice/order number combinations) and the sum of the invoice totals, where each invoice total is counted only once.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShowDetails` | int | No | Controls the output: `1` returns detail rows, any other value returns count and total per currency. |\n| `FromDate` | varchar(25) | Yes | Start of the period (inclusive), compared with the invoice date or scan-out date. |\n| `ToDate` | varchar(25) | Yes | End of the period (inclusive). Without a time component it means midnight of that day. |\n| `CustomerNrExternal` | varchar(60) | No | Optional external customer number to restrict the result to one customer. Empty means all customers. |\n| `IncludeOrdersWithTotalZero` | bit | No | If `1`, invoices with a total of zero are included; otherwise only invoices with a positive total. |\n| `SearchByScanOutDate` | bit | No | If `1`, the period is applied to `ScanOutDate`; otherwise to the invoice date `InvDate`. |\n\n- All reads use `NOLOCK`; results may contain uncommitted data.\n- `FromDate` and `ToDate` are strings that are implicitly converted for the `BETWEEN` comparison. A date without time (e.g. `2024-01-31`) means midnight, so invoices later on that day are excluded. Pass a time such as `2024-01-31 23:59:59` or the following day. Use an unambiguous format such as ISO `yyyy-mm-ddThh:mi:ss`.\n- In detail mode, invoices without a matching shipping address (`ShipAdrRef`) or currency are dropped because of inner joins.\n- In summary mode no row is returned if no invoice matches (the query uses `GROUP BY`).\n- `ScanOutEmp` is empty if no `OrderHistory` entry with status `AUS` exists for the invoice lines.\n\nDocumentation: https://pixi-api-docs.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": "Returns the shipped orders (invoiced with history status EIN) for a date range, either as detail rows or as order count and total per currency.\n\nDetermines all invoices of a period that count as shipped and returns them either in detail or aggregated.\n\n**Selection of invoices**\n- An invoice qualifies if at least one of its invoice lines (`Invlines`) refers to an order line that has an `OrderHistory` entry with status `EIN`.\n- The period is checked with `BETWEEN @FromDate AND @ToDate` against `Invoices.InvDate` (default) or against `Invoices.ScanOutDate` if `SearchByScanOutDate = 1`.\n- By default only invoices with `total > 0` are returned; with `IncludeOrdersWithTotalZero = 1` invoices with `total >= 0` are included. Negative totals are never returned.\n- If `CustomerNrExternal` is filled (it is trimmed; an empty value means no filter), only invoices of the customer with that external customer number are returned.\n\nFor each selected invoice the distinct external order numbers (`Orderlines.OrderNrExternal`) of its lines are determined.\n\n**`ShowDetails = 1` (default)**\nReturns one row per combination of invoice and external order number, sorted by `InvDate`. An invoice that covers several orders therefore appears several times. The rows contain invoice data, shipping address, currency, carrier, tracking ID and the employee who scanned the invoice out (`ScanOutEmp`: alphabetically smallest `UpdateEmp` of the `OrderHistory` entries with status `AUS`).\n\n**Any other value of `ShowDetails`**\nReturns one row per currency with the number of orders (invoice/order number combinations) and the sum of the invoice totals, where each invoice total is counted only once.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShowDetails` | int | No | Controls the output: `1` returns detail rows, any other value returns count and total per currency. |\n| `FromDate` | varchar(25) | Yes | Start of the period (inclusive), compared with the invoice date or scan-out date. |\n| `ToDate` | varchar(25) | Yes | End of the period (inclusive). Without a time component it means midnight of that day. |\n| `CustomerNrExternal` | varchar(60) | No | Optional external customer number to restrict the result to one customer. Empty means all customers. |\n| `IncludeOrdersWithTotalZero` | bit | No | If `1`, invoices with a total of zero are included; otherwise only invoices with a positive total. |\n| `SearchByScanOutDate` | bit | No | If `1`, the period is applied to `ScanOutDate`; otherwise to the invoice date `InvDate`. |\n\n- All reads use `NOLOCK`; results may contain uncommitted data.\n- `FromDate` and `ToDate` are strings that are implicitly converted for the `BETWEEN` comparison. A date without time (e.g. `2024-01-31`) means midnight, so invoices later on that day are excluded. Pass a time such as `2024-01-31 23:59:59` or the following day. Use an unambiguous format such as ISO `yyyy-mm-ddThh:mi:ss`.\n- In detail mode, invoices without a matching shipping address (`ShipAdrRef`) or currency are dropped because of inner joins.\n- In summary mode no row is returned if no invoice matches (the query uses `GROUP BY`).\n- `ScanOutEmp` is empty if no `OrderHistory` entry with status `AUS` exists for the invoice lines.\n\nDocumentation: https://pixi-api-docs.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": "Merges a source order into a target order by moving all orderlines and bundle orderlines, recalculating tax rates and shipping costs.\n\nMoves the content of the order `SourceOrderNr` into the order `TargetOrderNr`.\n\n1. Reads the order headers of both orders (order type, currency, shipping cost).\n2. Raises an error and stops if the two orders have different order types or different currencies. This also happens if neither order exists.\n3. Runs `pipiCanMergeOrders`, which checks the following conditions and returns its own result row (`CanMerge`, `Reason`):\n - both orders exist\n - both belong to the same customer\n - all orderlines have status `ANG`\n - both use the same payment type, which must not be credit card `K`\n - no orderline is on an active picklist\n - both have the same currency and order type\n4. If the merge is allowed, the following steps run in one transaction:\n - The shipping cost of the target order header is set to the higher shipping cost of the two orders.\n - All existing orderlines and bundle orderlines of the target order get this shipping cost, `UpdateEmp` and `UpdateDate`.\n - The orderlines of the source order are moved to the target order. They take over the billing and shipping address, `Order_Id`, `OrderNrExternal` and `VoucherID` of the target order's orderlines.\n - Their `TaxRate` is recalculated with `fPixi_GetVATRate`. The calculation uses the source order type and the country and VAT liability of the target shipping address.\n - With setting `CalculateBundleVAT` = `0`, bundle components take the tax rate of their bundle orderline.\n - The bundle orderlines of the source order are moved the same way. With `CalculateBundleVAT` = `1`, their tax rate is the net-weighted average of their components; otherwise it comes from the VAT function.\n - Bank matches (`BankMatch`) of the source order are reassigned to the target order.\n - The `Discount` of the source order header is set to 0.\n5. Returns `ResultMessage`:\n - `200 OK` on success\n - the reason code from `pipiCanMergeOrders` (401–407) if the merge is not allowed\n - `500 Unexpected error` if the transaction failed\n\n`UpdateEmp` is set to `Employee` plus ` (API)`, or to `API` if no employee is given.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TargetOrderNr` | int | Yes | Order number of the target order that receives the orderlines. |\n| `SourceOrderNr` | int | Yes | Order number of the source order whose orderlines are moved into the target order. |\n| `Employee` | varchar(50) | No | Employee name written to `UpdateEmp` with the suffix ` (API)`. If NULL, `API` is used. |\n| `ResultMessage` | varchar(128) | No | Output: result code with text, e.g. `200 OK`, a 401–407 reason from `pipiCanMergeOrders` or `500 Unexpected error`. |\n\n- The call returns **two** result sets. `SqlRowSet1` comes from `pipiCanMergeOrders` (`CanMerge`, `Reason`). `SqlRowSet2` holds `ResultMessage`.\n- The source order header itself is **not** deleted. It remains without orderlines, with `Discount` = 0.\n- The shipping cost update on `OrderHeader` sets `CONTEXT_INFO` 0x66666 to bypass the update trigger.\n- Values taken from the target orderlines (addresses, `Order_Id`, `OrderNrExternal`, `VoucherID`) are read from an arbitrary orderline of the target order. If the target order has no orderlines, these values become NULL on the moved lines.\n- Source orderlines whose `ItemRef` has no matching row in `items` are not moved.\n- Bundle orderlines without component lines are not moved either.\n- With `CalculateBundleVAT` = `1`, a net sum of 0 over the components of a bundle causes a division error. This rolls back the transaction and returns `500 Unexpected error`.\n- Error details are not returned in that case; any failure in the transaction only yields `500 Unexpected error`.\n- Reads use `NOLOCK`.\n- `fPixi_GetDefaultCountryCode`, used inside `fPixi_GetVATRate`, is not attached, so the default-country logic cannot be fully described here.\n\nDocumentation: https://pixi-api-docs.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": "Merges a source order into a target order by moving all orderlines and bundle orderlines, recalculating tax rates and shipping costs.\n\nMoves the content of the order `SourceOrderNr` into the order `TargetOrderNr`.\n\n1. Reads the order headers of both orders (order type, currency, shipping cost).\n2. Raises an error and stops if the two orders have different order types or different currencies. This also happens if neither order exists.\n3. Runs `pipiCanMergeOrders`, which checks the following conditions and returns its own result row (`CanMerge`, `Reason`):\n - both orders exist\n - both belong to the same customer\n - all orderlines have status `ANG`\n - both use the same payment type, which must not be credit card `K`\n - no orderline is on an active picklist\n - both have the same currency and order type\n4. If the merge is allowed, the following steps run in one transaction:\n - The shipping cost of the target order header is set to the higher shipping cost of the two orders.\n - All existing orderlines and bundle orderlines of the target order get this shipping cost, `UpdateEmp` and `UpdateDate`.\n - The orderlines of the source order are moved to the target order. They take over the billing and shipping address, `Order_Id`, `OrderNrExternal` and `VoucherID` of the target order's orderlines.\n - Their `TaxRate` is recalculated with `fPixi_GetVATRate`. The calculation uses the source order type and the country and VAT liability of the target shipping address.\n - With setting `CalculateBundleVAT` = `0`, bundle components take the tax rate of their bundle orderline.\n - The bundle orderlines of the source order are moved the same way. With `CalculateBundleVAT` = `1`, their tax rate is the net-weighted average of their components; otherwise it comes from the VAT function.\n - Bank matches (`BankMatch`) of the source order are reassigned to the target order.\n - The `Discount` of the source order header is set to 0.\n5. Returns `ResultMessage`:\n - `200 OK` on success\n - the reason code from `pipiCanMergeOrders` (401–407) if the merge is not allowed\n - `500 Unexpected error` if the transaction failed\n\n`UpdateEmp` is set to `Employee` plus ` (API)`, or to `API` if no employee is given.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TargetOrderNr` | int | Yes | Order number of the target order that receives the orderlines. |\n| `SourceOrderNr` | int | Yes | Order number of the source order whose orderlines are moved into the target order. |\n| `Employee` | varchar(50) | No | Employee name written to `UpdateEmp` with the suffix ` (API)`. If NULL, `API` is used. |\n| `ResultMessage` | varchar(128) | No | Output: result code with text, e.g. `200 OK`, a 401–407 reason from `pipiCanMergeOrders` or `500 Unexpected error`. |\n\n- The call returns **two** result sets. `SqlRowSet1` comes from `pipiCanMergeOrders` (`CanMerge`, `Reason`). `SqlRowSet2` holds `ResultMessage`.\n- The source order header itself is **not** deleted. It remains without orderlines, with `Discount` = 0.\n- The shipping cost update on `OrderHeader` sets `CONTEXT_INFO` 0x66666 to bypass the update trigger.\n- Values taken from the target orderlines (addresses, `Order_Id`, `OrderNrExternal`, `VoucherID`) are read from an arbitrary orderline of the target order. If the target order has no orderlines, these values become NULL on the moved lines.\n- Source orderlines whose `ItemRef` has no matching row in `items` are not moved.\n- Bundle orderlines without component lines are not moved either.\n- With `CalculateBundleVAT` = `1`, a net sum of 0 over the components of a bundle causes a division error. This rolls back the transaction and returns `500 Unexpected error`.\n- Error details are not returned in that case; any failure in the transaction only yields `500 Unexpected error`.\n- Reads use `NOLOCK`.\n- `fPixi_GetDefaultCountryCode`, used inside `fPixi_GetVATRate`, is not attached, so the default-country logic cannot be fully described here.\n\nDocumentation: https://pixi-api-docs.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": "Returns orders in a date range filtered by order tags combined with AND, OR and NOT conditions passed as XML.\n\nSearches orders by their assigned tags. The filter is passed as XML in `TagFilter`.\n\n**Parsing and validation**\n\n- The XML is read from `/TagFilter/AND`, `/TagFilter/OR` and `/TagFilter/NOT`. Each block can contain any number of `TagId` and `TagName` elements. Tag names are trimmed, and empty names are ignored.\n- Each entry is resolved against the tags of type `2` (order tags):\n - by `Id` when `TagId` is given;\n - by exact `Name` when `PartialTagNameMatch` = 0;\n - by `Name LIKE '%…%'` when `PartialTagNameMatch` = 1.\n- A partial name match can resolve one entry to several tags.\n- An entry that resolves to no tag gets the status `ERROR`.\n- A tag that appears more than once in the resolved list also gets `ERROR`. This applies across operations and also within the same operation, for example when it is referenced both by Id and by name.\n- If any entry has an error, the call returns the complete validation list (one row per resolved entry) and no orders.\n- If the XML cannot be parsed (or a `TagId` is not numeric), a single error row is returned.\n\n**Order search** (only if validation passed)\n\n- `DateFrom` defaults to 6 months before now, `DateTo` to now, and `RowCount` to 1000.\n- The date range is turned into a key range. It starts at the smallest `OrderHeaderKey` with `OrderDate >= DateFrom` and ends at the largest `OrderHeaderKey` with `OrderDate < DateTo`. All orders whose key lies in this range are considered.\n- **NOT**: the order must not carry any of the NOT tags.\n- **OR**: the order must carry at least one of the OR tags.\n- **AND**: the order must carry all of the AND tags.\n- Blocks that are left empty are not applied. If the filter contains no tags at all (or `TagFilter` is empty), all orders in the range are returned.\n- The result is limited to `TOP (RowCount)` and sorted by `OrderHeaderKey` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagFilter` | varchar(max) | Yes | XML filter with `AND`, `OR` and `NOT` blocks under `TagFilter`, each containing `TagId` and/or `TagName` elements. Empty value means no tag filter. |\n| `PartialTagNameMatch` | bit | No | Controls how `TagName` entries are matched. |\n| `StrictANDCondition` | bit | No | Obsolete, not used. |\n| `RowCount` | int | No | Maximum number of orders returned. NULL is treated as 1000. |\n| `DateFrom` | datetime | No | Start of the order date range (inclusive). NULL means 6 months before now. |\n| `DateTo` | datetime | No | End of the order date range (exclusive). NULL means now. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- `StrictANDCondition` is marked obsolete and is not used.\n- The date filter works on the key range, not on `OrderDate` itself. Orders whose key lies inside the range but whose date is outside it are still returned.\n- `DateTo` is exclusive.\n- If no order matches a date bound, the key range is empty and no rows are returned.\n- The AND check compares the number of matching tag assignments with the number of AND tags. Duplicate assignments of the same tag to an order could distort it.\n- With `PartialTagNameMatch` = 1, every tag matched by the name pattern counts as a separate tag. In AND, this means all matched tags are required.\n- A code comment notes that the OR condition may not work properly.\n- The message `Tag used in another operation` is also set when the same tag is referenced twice within one operation.\n- Both possible first result sets arrive as `SqlRowSet1`. Check for the `Status` column to distinguish the validation list from the order list.\n- A negative `RowCount` raises a SQL error outside the error handling.\n\nDocumentation: https://pixi-api-docs.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": "Returns orders in a date range filtered by order tags combined with AND, OR and NOT conditions passed as XML.\n\nSearches orders by their assigned tags. The filter is passed as XML in `TagFilter`.\n\n**Parsing and validation**\n\n- The XML is read from `/TagFilter/AND`, `/TagFilter/OR` and `/TagFilter/NOT`. Each block can contain any number of `TagId` and `TagName` elements. Tag names are trimmed, and empty names are ignored.\n- Each entry is resolved against the tags of type `2` (order tags):\n - by `Id` when `TagId` is given;\n - by exact `Name` when `PartialTagNameMatch` = 0;\n - by `Name LIKE '%…%'` when `PartialTagNameMatch` = 1.\n- A partial name match can resolve one entry to several tags.\n- An entry that resolves to no tag gets the status `ERROR`.\n- A tag that appears more than once in the resolved list also gets `ERROR`. This applies across operations and also within the same operation, for example when it is referenced both by Id and by name.\n- If any entry has an error, the call returns the complete validation list (one row per resolved entry) and no orders.\n- If the XML cannot be parsed (or a `TagId` is not numeric), a single error row is returned.\n\n**Order search** (only if validation passed)\n\n- `DateFrom` defaults to 6 months before now, `DateTo` to now, and `RowCount` to 1000.\n- The date range is turned into a key range. It starts at the smallest `OrderHeaderKey` with `OrderDate >= DateFrom` and ends at the largest `OrderHeaderKey` with `OrderDate < DateTo`. All orders whose key lies in this range are considered.\n- **NOT**: the order must not carry any of the NOT tags.\n- **OR**: the order must carry at least one of the OR tags.\n- **AND**: the order must carry all of the AND tags.\n- Blocks that are left empty are not applied. If the filter contains no tags at all (or `TagFilter` is empty), all orders in the range are returned.\n- The result is limited to `TOP (RowCount)` and sorted by `OrderHeaderKey` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagFilter` | varchar(max) | Yes | XML filter with `AND`, `OR` and `NOT` blocks under `TagFilter`, each containing `TagId` and/or `TagName` elements. Empty value means no tag filter. |\n| `PartialTagNameMatch` | bit | No | Controls how `TagName` entries are matched. |\n| `StrictANDCondition` | bit | No | Obsolete, not used. |\n| `RowCount` | int | No | Maximum number of orders returned. NULL is treated as 1000. |\n| `DateFrom` | datetime | No | Start of the order date range (inclusive). NULL means 6 months before now. |\n| `DateTo` | datetime | No | End of the order date range (exclusive). NULL means now. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- `StrictANDCondition` is marked obsolete and is not used.\n- The date filter works on the key range, not on `OrderDate` itself. Orders whose key lies inside the range but whose date is outside it are still returned.\n- `DateTo` is exclusive.\n- If no order matches a date bound, the key range is empty and no rows are returned.\n- The AND check compares the number of matching tag assignments with the number of AND tags. Duplicate assignments of the same tag to an order could distort it.\n- With `PartialTagNameMatch` = 1, every tag matched by the name pattern counts as a separate tag. In AND, this means all matched tags are required.\n- A code comment notes that the OR condition may not work properly.\n- The message `Tag used in another operation` is also set when the same tag is referenced twice within one operation.\n- Both possible first result sets arrive as `SqlRowSet1`. Check for the `Status` column to distinguish the validation list from the order list.\n- A negative `RowCount` raises a SQL error outside the error handling.\n\nDocumentation: https://pixi-api-docs.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": "Sets or clears the GDPR polling export flag (`ExportGdprDataForPolling`) of an order identified by order number or external order number.\n\nUpdates the column `ExportGdprDataForPolling` of one order in `OrderHeader`.\n\n1. `OrderNr` = `0` and an empty `OrderNrExternal` are treated as not supplied.\n2. The order is looked up by `OrderNr` first. If no order is found that way, it is looked up by `OrderNrExternal`. If both are given and `OrderNr` matches, `OrderNrExternal` is ignored.\n3. Validation, in this order:\n - neither `OrderNr` nor `OrderNrExternal` supplied → error,\n - no order found → error,\n - `ExportGdprDataForPolling` is NULL → error.\n4. If the order already has the requested flag value, nothing is changed and a `Warning` row is returned.\n5. Otherwise the flag is updated, `UpdateEmp` is set to `User` (default `API user`), and a `Success` row is returned.\n\nThe call always returns exactly one row with `Status` and `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. `0` is treated as NULL. Checked before `OrderNrExternal`. |\n| `OrderNrExternal` | varchar(50) | No | External order number (e.g. shop order number). Empty string is treated as NULL. Used if no order is found via `OrderNr`. |\n| `ExportGdprDataForPolling` | bit | Yes | New value of the GDPR polling export flag. |\n| `User` | varchar(50) | No | User name written to `UpdateEmp`. NULL or empty becomes `API user`. |\n\n- Runs in its own transaction, or in a savepoint if a transaction is already open. With `XACT_ABORT ON`, unexpected errors roll back the change and are logged via `log.InsertError` (not attached); the error text is truncated to 80 characters in `Message`.\n- The lookups and the existence check read `OrderHeader` with `NOLOCK`; the update uses `ROWLOCK`.\n- If several orders share the same `OrderNrExternal`, only one of them (the first row read) is updated.\n- `ExportGdprDataForPolling` has no default value; omitting it makes SQL Server reject the call before the procedure runs. Only an explicit NULL produces the status row \"Mandatory parameter ExportGdprDataForPolling is missing\".\n- Validation errors are returned as a normal row with `Status` = `Error`, not as a SQL error.\n\nDocumentation: https://pixi-api-docs.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": "Sets or clears the GDPR polling export flag (`ExportGdprDataForPolling`) of an order identified by order number or external order number.\n\nUpdates the column `ExportGdprDataForPolling` of one order in `OrderHeader`.\n\n1. `OrderNr` = `0` and an empty `OrderNrExternal` are treated as not supplied.\n2. The order is looked up by `OrderNr` first. If no order is found that way, it is looked up by `OrderNrExternal`. If both are given and `OrderNr` matches, `OrderNrExternal` is ignored.\n3. Validation, in this order:\n - neither `OrderNr` nor `OrderNrExternal` supplied → error,\n - no order found → error,\n - `ExportGdprDataForPolling` is NULL → error.\n4. If the order already has the requested flag value, nothing is changed and a `Warning` row is returned.\n5. Otherwise the flag is updated, `UpdateEmp` is set to `User` (default `API user`), and a `Success` row is returned.\n\nThe call always returns exactly one row with `Status` and `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. `0` is treated as NULL. Checked before `OrderNrExternal`. |\n| `OrderNrExternal` | varchar(50) | No | External order number (e.g. shop order number). Empty string is treated as NULL. Used if no order is found via `OrderNr`. |\n| `ExportGdprDataForPolling` | bit | Yes | New value of the GDPR polling export flag. |\n| `User` | varchar(50) | No | User name written to `UpdateEmp`. NULL or empty becomes `API user`. |\n\n- Runs in its own transaction, or in a savepoint if a transaction is already open. With `XACT_ABORT ON`, unexpected errors roll back the change and are logged via `log.InsertError` (not attached); the error text is truncated to 80 characters in `Message`.\n- The lookups and the existence check read `OrderHeader` with `NOLOCK`; the update uses `ROWLOCK`.\n- If several orders share the same `OrderNrExternal`, only one of them (the first row read) is updated.\n- `ExportGdprDataForPolling` has no default value; omitting it makes SQL Server reject the call before the procedure runs. Only an explicit NULL produces the status row \"Mandatory parameter ExportGdprDataForPolling is missing\".\n- Validation errors are returned as a normal row with `Status` = `Error`, not as a SQL error.\n\nDocumentation: https://pixi-api-docs.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": "Updates the sub-shop name, sub-shop logo and referrer of an order, identified by Pixi order number or external order number.\n\nSets informational fields in the header of an existing order.\n\n1. **Order lookup:** The procedure searches `Orderlines` for rows where `OrderNrExternal` equals `@OrderNrExternal` **or** `OrderNr` equals `@OrderNr`, and takes the `OrderNr` from a matching row. If no row matches, `@OrderNr` keeps the value that was passed in.\n2. **Check:** If there is not exactly one `OrderHeader` record with the resulting `OrderNr`, an error row with `ErrorNr` `404` is returned and nothing is changed.\n3. **Update:** Otherwise the `OrderHeader` record is updated:\n - `SubShopName` is set to `@SubShopName`,\n - `SubShopLogo` is set to `@SubShopLogo`,\n - `Referrer` is set to `@Referrer`.\n\n A parameter that is omitted or `NULL` leaves the existing value unchanged. This allows partial updates.\n4. If the update fails, an error row with `ErrorNr` `500` is returned.\n\nOn success the call returns **no result set**.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. Alternative to `OrderNrExternal`. |\n| `OrderNrExternal` | varchar(50) | No | External order number, for example from the shop. It is resolved through `Orderlines`. Alternative to `OrderNr`. |\n| `SubShopName` | varchar(50) | No | New sub-shop name. `NULL` keeps the current value. |\n| `SubShopLogo` | varchar(50) | No | New sub-shop logo reference. `NULL` keeps the current value. |\n| `Referrer` | varchar(50) | No | New referrer, i.e. the source of the order. `NULL` keeps the current value. |\n\n- The lookup by `@OrderNrExternal` goes through `Orderlines`, not `OrderHeader`. An order without order lines cannot be found by its external number and returns `404`. Lookup by `@OrderNr` alone still works in that case, because the passed value is kept.\n- If both `@OrderNr` and `@OrderNrExternal` are passed and they point to different orders, the code does **not** detect the conflict, although the error text suggests it does. The lookup then takes the `OrderNr` from one of the matching order lines, and the row that is used is not defined. That order is updated. Pass only one of the two identifiers.\n- The lookup reads with `NOLOCK`.\n- An empty string is not `NULL`. It overwrites the field with an empty value. Only `NULL` or an omitted parameter keeps the existing value.\n- Values longer than 50 characters can make the update fail, which returns the `500` row. Whether this happens depends on the column sizes in `OrderHeader`, which are not visible in the code.\n- The error texts mention an \"invoice\", but the call works on orders.\n- No transaction is opened explicitly. The update is a single statement.\n\nDocumentation: https://pixi-api-docs.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": "Updates the sub-shop name, sub-shop logo and referrer of an order, identified by Pixi order number or external order number.\n\nSets informational fields in the header of an existing order.\n\n1. **Order lookup:** The procedure searches `Orderlines` for rows where `OrderNrExternal` equals `@OrderNrExternal` **or** `OrderNr` equals `@OrderNr`, and takes the `OrderNr` from a matching row. If no row matches, `@OrderNr` keeps the value that was passed in.\n2. **Check:** If there is not exactly one `OrderHeader` record with the resulting `OrderNr`, an error row with `ErrorNr` `404` is returned and nothing is changed.\n3. **Update:** Otherwise the `OrderHeader` record is updated:\n - `SubShopName` is set to `@SubShopName`,\n - `SubShopLogo` is set to `@SubShopLogo`,\n - `Referrer` is set to `@Referrer`.\n\n A parameter that is omitted or `NULL` leaves the existing value unchanged. This allows partial updates.\n4. If the update fails, an error row with `ErrorNr` `500` is returned.\n\nOn success the call returns **no result set**.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. Alternative to `OrderNrExternal`. |\n| `OrderNrExternal` | varchar(50) | No | External order number, for example from the shop. It is resolved through `Orderlines`. Alternative to `OrderNr`. |\n| `SubShopName` | varchar(50) | No | New sub-shop name. `NULL` keeps the current value. |\n| `SubShopLogo` | varchar(50) | No | New sub-shop logo reference. `NULL` keeps the current value. |\n| `Referrer` | varchar(50) | No | New referrer, i.e. the source of the order. `NULL` keeps the current value. |\n\n- The lookup by `@OrderNrExternal` goes through `Orderlines`, not `OrderHeader`. An order without order lines cannot be found by its external number and returns `404`. Lookup by `@OrderNr` alone still works in that case, because the passed value is kept.\n- If both `@OrderNr` and `@OrderNrExternal` are passed and they point to different orders, the code does **not** detect the conflict, although the error text suggests it does. The lookup then takes the `OrderNr` from one of the matching order lines, and the row that is used is not defined. That order is updated. Pass only one of the two identifiers.\n- The lookup reads with `NOLOCK`.\n- An empty string is not `NULL`. It overwrites the field with an empty value. Only `NULL` or an omitted parameter keeps the existing value.\n- Values longer than 50 characters can make the update fail, which returns the `500` row. Whether this happens depends on the column sizes in `OrderHeader`, which are not visible in the code.\n- The error texts mention an \"invoice\", but the call works on orders.\n- No transaction is opened explicitly. The update is a single statement.\n\nDocumentation: https://pixi-api-docs.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": "Deletes a picklist with its items, picking progress, picklist boxes and transport bin assignments.\n\nDeletes the picklist identified by `PicklistNumber` (`PLHkey` in `PLHeader`).\n\nSteps:\n1. If `PicklistNumber` is not passed, an error row is returned.\n2. If no picklist with this number exists, an error row is returned.\n3. The number of entries in `PL_ItemPickingProgress` for the picklist is counted. If there are any and `ForceDelete = 0`, the call stops with an error row, because items of the picklist are currently being picked.\n4. Otherwise the internal procedure `Pixi_DeletePickList` is executed. It deletes, in this order, the picking progress entries, the picklist boxes (`PicklistBox`), the transport bin assignments with document type 1 (`TransportBinMatch`), the picklist items (`PLitem`) and finally the picklist header (`PLHeader`).\n5. A row with `Status = Success` and a confirmation message is returned.\n\nExactly one row with `Status` and `Message` is returned in every case.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PicklistNumber` | int | No | Number of the picklist to delete (`PLHkey`). Technically optional, but the call returns an error if it is missing. |\n| `ForceDelete` | bit | No | Deletes the picklist even if items are currently being picked. |\n\n- The deletion runs inside a transaction in `Pixi_DeletePickList` (or a savepoint if a transaction is already open). On an error it is rolled back and logged via `log.InsertError` (not attached).\n- Pitfall: `Pixi_DeletePickList` catches its own errors and does not re-raise them. Therefore an error during the deletion is usually not seen by this call, and the `Success` row may be returned even though the rollback left the picklist in place. Verify the deletion if in doubt. The message `Unexpected error. Picklist was not deleted.` only appears for errors that escape the inner procedure.\n- Existence and picking-progress checks use `NOLOCK`, so they can read uncommitted data.\n- `ForceDelete = 1` also removes picklists that are being picked right now; pickers working on it lose their progress.\n\nDocumentation: https://pixi-api-docs.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": "Deletes a picklist with its items, picking progress, picklist boxes and transport bin assignments.\n\nDeletes the picklist identified by `PicklistNumber` (`PLHkey` in `PLHeader`).\n\nSteps:\n1. If `PicklistNumber` is not passed, an error row is returned.\n2. If no picklist with this number exists, an error row is returned.\n3. The number of entries in `PL_ItemPickingProgress` for the picklist is counted. If there are any and `ForceDelete = 0`, the call stops with an error row, because items of the picklist are currently being picked.\n4. Otherwise the internal procedure `Pixi_DeletePickList` is executed. It deletes, in this order, the picking progress entries, the picklist boxes (`PicklistBox`), the transport bin assignments with document type 1 (`TransportBinMatch`), the picklist items (`PLitem`) and finally the picklist header (`PLHeader`).\n5. A row with `Status = Success` and a confirmation message is returned.\n\nExactly one row with `Status` and `Message` is returned in every case.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PicklistNumber` | int | No | Number of the picklist to delete (`PLHkey`). Technically optional, but the call returns an error if it is missing. |\n| `ForceDelete` | bit | No | Deletes the picklist even if items are currently being picked. |\n\n- The deletion runs inside a transaction in `Pixi_DeletePickList` (or a savepoint if a transaction is already open). On an error it is rolled back and logged via `log.InsertError` (not attached).\n- Pitfall: `Pixi_DeletePickList` catches its own errors and does not re-raise them. Therefore an error during the deletion is usually not seen by this call, and the `Success` row may be returned even though the rollback left the picklist in place. Verify the deletion if in doubt. The message `Unexpected error. Picklist was not deleted.` only appears for errors that escape the inner procedure.\n- Existence and picking-progress checks use `NOLOCK`, so they can read uncommitted data.\n- `ForceDelete = 1` also removes picklists that are being picked right now; pickers working on it lose their progress.\n\nDocumentation: https://pixi-api-docs.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": "Returns order headers selected by key or order number, or by create/update date ranges, with key-based paging.\n\nReads records from `OrderHeader`. The parameters select one of several **mutually exclusive modes**, checked in this order:\n\n1. **Create-or-update range**: `CreateAndUpdateDateFrom` and/or `CreateAndUpdateDateTo` is set. Returns orders where `CreateDate` **or** `UpdateDate` is `>=` From, and `CreateDate` **or** `UpdateDate` is `<` To.\n2. **Create range**: `CreateDateFrom` and/or `CreateDateTo` is set. Filters `CreateDate >= From` and `CreateDate < To`.\n3. **Update range**: `UpdateDateFrom` and/or `UpdateDateTo` is set. Filters `UpdateDate >= From` and `UpdateDate < To`.\n4. **Paging without date filter**: `RowCount` is set and no date parameter is set. Returns the next orders after `OrderHeaderKey`.\n5. **Single order**: otherwise. Returns at most one order where `OrderHeaderKey` equals the given key **or** `OrderNr` equals the given order number.\n\nOnly the first matching mode is used. Parameters of later modes are ignored. For example, `OrderNr` has no effect if any date parameter or `RowCount` is set.\n\n**Paging**: In modes 1–4, `OrderHeaderKey` is an *exclusive* lower bound. Only orders with a key greater than the passed value are returned. If `OrderHeaderKey` is not passed, it is treated as `0`. To read the next page, pass the last `OrderHeaderKey` you received.\n\n**Row limit**: The output is limited to `RowCount` rows. If `RowCount` is `NULL` or `0`, the limit is 1000 rows. Values above 100000 are capped to 100000. Rows are always sorted by `OrderHeaderKey` ascending.\n\n**Computed columns**:\n- `ShipDate` is the latest `ShipDate` of the order's `Orderlines`.\n- `ShopNote` is wrapped in a CDATA section if it starts with `<`.\n- `ExchRateId` is only filled if the setting `MultiCurrencyEnabled` is `1`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderHeaderKey` | int | No | In date and paging modes: exclusive lower bound (paging cursor); `NULL` is treated as `0`. In single-order mode: exact key of the order to return. |\n| `OrderNr` | int | No | Order number. Only used in single-order mode, i.e. when no date parameter and no `RowCount` is set. |\n| `CreateDateFrom` | datetime | No | Inclusive lower bound for `CreateDate` (create range mode). |\n| `CreateDateTo` | datetime | No | Exclusive upper bound for `CreateDate` (create range mode). |\n| `UpdateDateFrom` | datetime | No | Inclusive lower bound for `UpdateDate`. Only used if no create-or-update or create-range parameter is set. |\n| `UpdateDateTo` | datetime | No | Exclusive upper bound for `UpdateDate` (update range mode). |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound: an order matches if `CreateDate` or `UpdateDate` is on or after this value. Has priority over all other filters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound: an order matches if `CreateDate` or `UpdateDate` is before this value. |\n| `RowCount` | int | No | Maximum number of rows to return (capped at 100000; `NULL` or `0` means 1000). If set without date parameters, it enables paging mode after `OrderHeaderKey`. |\n\n- All reads use `NOLOCK`, so uncommitted data can be returned.\n- **No filter**: A call without any parameter returns no rows, unless an order with key `0` exists. The call falls into the single-order mode with key `0`.\n- **Single-order mode**: If both `OrderHeaderKey` and `OrderNr` are passed, the filter is an OR. One arbitrary matching order is returned, because there is no sort before `TOP 1`.\n- **Create-or-update mode**: The OR logic is loose. The To bound only excludes an order if both `CreateDate` and `UpdateDate` are at or after To. This mode collects all matching keys before applying the row limit, which can be slow for wide ranges.\n- **`RowCount = 0`**: In modes 2–4, `RowCount = 0` leads to zero candidates, so no rows are returned. Pass `NULL` instead to use the default of 1000. Negative values cause a SQL error.\n- The row limit is applied with `SET ROWCOUNT`.\n\nDocumentation: https://pixi-api-docs.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": "Returns order headers selected by key or order number, or by create/update date ranges, with key-based paging.\n\nReads records from `OrderHeader`. The parameters select one of several **mutually exclusive modes**, checked in this order:\n\n1. **Create-or-update range**: `CreateAndUpdateDateFrom` and/or `CreateAndUpdateDateTo` is set. Returns orders where `CreateDate` **or** `UpdateDate` is `>=` From, and `CreateDate` **or** `UpdateDate` is `<` To.\n2. **Create range**: `CreateDateFrom` and/or `CreateDateTo` is set. Filters `CreateDate >= From` and `CreateDate < To`.\n3. **Update range**: `UpdateDateFrom` and/or `UpdateDateTo` is set. Filters `UpdateDate >= From` and `UpdateDate < To`.\n4. **Paging without date filter**: `RowCount` is set and no date parameter is set. Returns the next orders after `OrderHeaderKey`.\n5. **Single order**: otherwise. Returns at most one order where `OrderHeaderKey` equals the given key **or** `OrderNr` equals the given order number.\n\nOnly the first matching mode is used. Parameters of later modes are ignored. For example, `OrderNr` has no effect if any date parameter or `RowCount` is set.\n\n**Paging**: In modes 1–4, `OrderHeaderKey` is an *exclusive* lower bound. Only orders with a key greater than the passed value are returned. If `OrderHeaderKey` is not passed, it is treated as `0`. To read the next page, pass the last `OrderHeaderKey` you received.\n\n**Row limit**: The output is limited to `RowCount` rows. If `RowCount` is `NULL` or `0`, the limit is 1000 rows. Values above 100000 are capped to 100000. Rows are always sorted by `OrderHeaderKey` ascending.\n\n**Computed columns**:\n- `ShipDate` is the latest `ShipDate` of the order's `Orderlines`.\n- `ShopNote` is wrapped in a CDATA section if it starts with `<`.\n- `ExchRateId` is only filled if the setting `MultiCurrencyEnabled` is `1`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderHeaderKey` | int | No | In date and paging modes: exclusive lower bound (paging cursor); `NULL` is treated as `0`. In single-order mode: exact key of the order to return. |\n| `OrderNr` | int | No | Order number. Only used in single-order mode, i.e. when no date parameter and no `RowCount` is set. |\n| `CreateDateFrom` | datetime | No | Inclusive lower bound for `CreateDate` (create range mode). |\n| `CreateDateTo` | datetime | No | Exclusive upper bound for `CreateDate` (create range mode). |\n| `UpdateDateFrom` | datetime | No | Inclusive lower bound for `UpdateDate`. Only used if no create-or-update or create-range parameter is set. |\n| `UpdateDateTo` | datetime | No | Exclusive upper bound for `UpdateDate` (update range mode). |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound: an order matches if `CreateDate` or `UpdateDate` is on or after this value. Has priority over all other filters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound: an order matches if `CreateDate` or `UpdateDate` is before this value. |\n| `RowCount` | int | No | Maximum number of rows to return (capped at 100000; `NULL` or `0` means 1000). If set without date parameters, it enables paging mode after `OrderHeaderKey`. |\n\n- All reads use `NOLOCK`, so uncommitted data can be returned.\n- **No filter**: A call without any parameter returns no rows, unless an order with key `0` exists. The call falls into the single-order mode with key `0`.\n- **Single-order mode**: If both `OrderHeaderKey` and `OrderNr` are passed, the filter is an OR. One arbitrary matching order is returned, because there is no sort before `TOP 1`.\n- **Create-or-update mode**: The OR logic is loose. The To bound only excludes an order if both `CreateDate` and `UpdateDate` are at or after To. This mode collects all matching keys before applying the row limit, which can be slow for wide ranges.\n- **`RowCount = 0`**: In modes 2–4, `RowCount = 0` leads to zero candidates, so no rows are returned. Pass `NULL` instead to use the default of 1000. Negative values cause a SQL error.\n- The row limit is applied with `SET ROWCOUNT`.\n\nDocumentation: https://pixi-api-docs.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": "Releases an on-hold order identified by its external order number and shop by setting its order lines from status HAL to ANG.\n\nReleases an order that is on hold (status `HAL`) so it can be processed again.\n\n1. The internal order number (`OrderNr`) is looked up in `Orderlines` via `OrderNrExternal` = `@OrderNrExternal`, joined to `Customers` with `CustomerOf` = `@ShopId`.\n2. The internal procedure `GOS_ReleaseOnHold` is called with that order number and the user `API`. It sets every order line of the order that has status `HAL` to `ANG`, sets `UpdateDate` to the current date and `UpdateEmp` to `API (payments)`.\n3. Finally one status row is returned: the number of order lines with the given external order number and shop that now have status `ANG`. `ReturnCode` is `OK` if this number is greater than 0, otherwise `ERROR`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNrExternal` | varchar(50) | Yes | External order number (e.g. the shop's order number) of the order to release. |\n| `ShopId` | char(3) | Yes | Shop ID; compared with `CustomerOf` of the order's customer. |\n\n- `AffectedRows` is not the number of lines actually released: it counts **all** lines with status `ANG`, including lines that already had `ANG` before the call. Calling the procedure for an order that was not on hold but has `ANG` lines therefore also returns `OK`.\n- If no order is found, nothing is updated and the result is `ERROR` with `AffectedRows` = 0. The same happens if the order exists but none of its lines is in status `ANG` afterwards (e.g. lines in other statuses).\n- If several orders share the same external order number within the shop, only one of them (the last row read by the lookup) is released, while the count covers lines of all matching orders.\n- Lookups and the final count use `NOLOCK`, so the result can reflect uncommitted data.\n- The update runs inside a transaction (or savepoint if a transaction is already open). On an error the transaction is rolled back, the error details are written to `LogTable` and the error is re-raised.\n\nDocumentation: https://pixi-api-docs.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": "Releases an on-hold order identified by its external order number and shop by setting its order lines from status HAL to ANG.\n\nReleases an order that is on hold (status `HAL`) so it can be processed again.\n\n1. The internal order number (`OrderNr`) is looked up in `Orderlines` via `OrderNrExternal` = `@OrderNrExternal`, joined to `Customers` with `CustomerOf` = `@ShopId`.\n2. The internal procedure `GOS_ReleaseOnHold` is called with that order number and the user `API`. It sets every order line of the order that has status `HAL` to `ANG`, sets `UpdateDate` to the current date and `UpdateEmp` to `API (payments)`.\n3. Finally one status row is returned: the number of order lines with the given external order number and shop that now have status `ANG`. `ReturnCode` is `OK` if this number is greater than 0, otherwise `ERROR`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNrExternal` | varchar(50) | Yes | External order number (e.g. the shop's order number) of the order to release. |\n| `ShopId` | char(3) | Yes | Shop ID; compared with `CustomerOf` of the order's customer. |\n\n- `AffectedRows` is not the number of lines actually released: it counts **all** lines with status `ANG`, including lines that already had `ANG` before the call. Calling the procedure for an order that was not on hold but has `ANG` lines therefore also returns `OK`.\n- If no order is found, nothing is updated and the result is `ERROR` with `AffectedRows` = 0. The same happens if the order exists but none of its lines is in status `ANG` afterwards (e.g. lines in other statuses).\n- If several orders share the same external order number within the shop, only one of them (the last row read by the lookup) is released, while the count covers lines of all matching orders.\n- Lookups and the final count use `NOLOCK`, so the result can reflect uncommitted data.\n- The update runs inside a transaction (or savepoint if a transaction is already open). On an error the transaction is rolled back, the error details are written to `LogTable` and the error is re-raised.\n\nDocumentation: https://pixi-api-docs.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": "Returns open orders or order lines that can be shipped from current stock, either as line details or as totals, optionally per location.\n\nDetermines which open orders can be shipped with the current stock and returns them as line details or as aggregated totals.\n\n**1. Candidate orders**\n- Only order lines in status `ANG` or `EIN` (as far as these exist in `OrderStates`) with an `ItemRef` and `Qty > 0` are considered. Replacement lines without an item are skipped.\n- `ShopId`: only orders whose customer has `CustomerOf = @ShopId`. An empty string (the default) means all shops.\n- Orders whose shipping or billing address is locked (`ASlocked = 'Y'`) are excluded.\n- Orders whose header is locked (`OhSLocked = 'Y'`) are excluded.\n- Ship date: by default only orders without a ship date or with a ship date before tomorrow are included. With `IncludeOrdersWithAnyShipDate = 1` the ship date is ignored.\n\n**2. Stock check**\nFor every candidate line, the internal procedure `pixi_CalculateStockForOrderLines` decides whether the line is shippable. Stock of locations with `SpecialStock = 0` is used. Earlier reservations and older unreserved order lines (FIFO by reservation date / order line key) are subtracted from the stock. Lines in status `EIN` always count as shippable. `UseFIFObyLocationV2` selects whether stock is checked per location of the line (`1`) or summed over all locations (`0`). `NULL` means the value of the setting `UseFIFObyLocation` is used.\n\n**3. Filter by part delivery**\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 0`: all lines of orders in which every candidate line is shippable (complete orders only).\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 1`: all shippable lines, regardless of whether the order is complete.\n- `OnlyPartDelivery = 1`: only shippable lines of orders that also contain at least one line that is not shippable. `IncludePartDelivery` is ignored.\n\n**4. Currency**\nIf the setting `MultiCurrencyEnabled` is `1`, `Price` and `ShipCost` are divided by the exchange rate of the database currency source for the order's currency and exchange date. The result is in the database currency, and `dbCurrency` holds its code. If no matching rate is found, the amounts are left unchanged. Without multi-currency, amounts are returned as stored and `dbCurrency` is `NULL`.\n\n**5. Output** (exactly one result set, chosen by `ViewDetails` and `PerLocation`)\n- `ViewDetails = 1`, `PerLocation = 0`: one row per line, sorted by `OrderNr`, `OrderlineRef`.\n- `ViewDetails = 0`, `PerLocation = 0`: one total row with the number of orders, order value (`Price * Qty`), shipping cost and picks.\n- `ViewDetails = 1`, `PerLocation = 1`: like the details, with an additional `LocationId` column.\n- `ViewDetails = 0`, `PerLocation = 1`: one total row per location.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ViewDetails` | bit | No | `1` returns one row per order line, `0` (or `NULL`) returns totals. |\n| `IncludePartDelivery` | bit | No | With `OnlyPartDelivery = 0`: `1` returns all shippable lines, including lines of orders that can only be partly shipped. `0` returns complete orders only. Ignored if `OnlyPartDelivery = 1`. |\n| `OnlyPartDelivery` | bit | No | `1` returns only the shippable lines of orders that also contain unshippable lines (part deliveries). |\n| `ShopId` | varchar(3) | No | Shop code. Only orders of customers with `CustomerOf` equal to this value are returned. Empty means all shops. |\n| `IncludeOrdersWithAnyShipDate` | bit | No | `0`: only orders without a ship date or with a ship date up to today. `1`: the ship date is ignored. |\n| `PerLocation` | bit | No | `1` adds `LocationId` to the details or groups the totals by location. Marked as the \"old way\" in the code. |\n| `UseFIFObyLocationV2` | bit | No | Controls the stock check: `1` checks the stock of the line's location, `0` checks the total stock of all non-special-stock locations. `NULL` uses the setting `UseFIFObyLocation`. |\n\n- All reads use `NOLOCK`. The result can contain uncommitted data and is a snapshot only; nothing is reserved or changed.\n- `NULL` values for `ViewDetails`, `IncludePartDelivery`, `OnlyPartDelivery` and `PerLocation` are treated as `0`. An empty `ShopId` is treated as \"all shops\". A `NULL` value for `IncludeOrdersWithAnyShipDate` acts like `0`.\n- **Settings that change the behaviour:**\n - `MultiCurrencyEnabled`: currency conversion and the `dbCurrency` column.\n - `HomeCurrency` and `DatabaseCurrencyExchRateSourceId`: which database currency and rate source are used.\n - `UseFIFObyLocation`: used when `UseFIFObyLocationV2` is `NULL`.\n- Whether an order is \"complete\" is judged only by its `ANG`/`EIN` lines with an item and positive quantity. Lines in other statuses are ignored.\n- `ShipCost` is the shipping cost of the order header, repeated on every line. The totals add it once per order. In the per-location totals it is added once per order and location, so an order spread over several locations counts its shipping cost in each of them.\n- In the overall totals (`ViewDetails = 0`, `PerLocation = 0`) one row is always returned. If nothing is shippable, `Orders` = 0, `ShipCost` = 0, and `OrderTotal`/`Picks` are `NULL`. The per-location totals return no rows in that case.\n- The comment in the code marks `PerLocation` as the \"old way\".\n- The internal stock procedure calls `log.EventDurationInsert` (definition not attached), which presumably writes a duration log entry.\n- The call scans all open `ANG`/`EIN` order lines and their reservations and can be expensive on large databases.\n\nDocumentation: https://pixi-api-docs.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": "Returns open orders or order lines that can be shipped from current stock, either as line details or as totals, optionally per location.\n\nDetermines which open orders can be shipped with the current stock and returns them as line details or as aggregated totals.\n\n**1. Candidate orders**\n- Only order lines in status `ANG` or `EIN` (as far as these exist in `OrderStates`) with an `ItemRef` and `Qty > 0` are considered. Replacement lines without an item are skipped.\n- `ShopId`: only orders whose customer has `CustomerOf = @ShopId`. An empty string (the default) means all shops.\n- Orders whose shipping or billing address is locked (`ASlocked = 'Y'`) are excluded.\n- Orders whose header is locked (`OhSLocked = 'Y'`) are excluded.\n- Ship date: by default only orders without a ship date or with a ship date before tomorrow are included. With `IncludeOrdersWithAnyShipDate = 1` the ship date is ignored.\n\n**2. Stock check**\nFor every candidate line, the internal procedure `pixi_CalculateStockForOrderLines` decides whether the line is shippable. Stock of locations with `SpecialStock = 0` is used. Earlier reservations and older unreserved order lines (FIFO by reservation date / order line key) are subtracted from the stock. Lines in status `EIN` always count as shippable. `UseFIFObyLocationV2` selects whether stock is checked per location of the line (`1`) or summed over all locations (`0`). `NULL` means the value of the setting `UseFIFObyLocation` is used.\n\n**3. Filter by part delivery**\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 0`: all lines of orders in which every candidate line is shippable (complete orders only).\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 1`: all shippable lines, regardless of whether the order is complete.\n- `OnlyPartDelivery = 1`: only shippable lines of orders that also contain at least one line that is not shippable. `IncludePartDelivery` is ignored.\n\n**4. Currency**\nIf the setting `MultiCurrencyEnabled` is `1`, `Price` and `ShipCost` are divided by the exchange rate of the database currency source for the order's currency and exchange date. The result is in the database currency, and `dbCurrency` holds its code. If no matching rate is found, the amounts are left unchanged. Without multi-currency, amounts are returned as stored and `dbCurrency` is `NULL`.\n\n**5. Output** (exactly one result set, chosen by `ViewDetails` and `PerLocation`)\n- `ViewDetails = 1`, `PerLocation = 0`: one row per line, sorted by `OrderNr`, `OrderlineRef`.\n- `ViewDetails = 0`, `PerLocation = 0`: one total row with the number of orders, order value (`Price * Qty`), shipping cost and picks.\n- `ViewDetails = 1`, `PerLocation = 1`: like the details, with an additional `LocationId` column.\n- `ViewDetails = 0`, `PerLocation = 1`: one total row per location.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ViewDetails` | bit | No | `1` returns one row per order line, `0` (or `NULL`) returns totals. |\n| `IncludePartDelivery` | bit | No | With `OnlyPartDelivery = 0`: `1` returns all shippable lines, including lines of orders that can only be partly shipped. `0` returns complete orders only. Ignored if `OnlyPartDelivery = 1`. |\n| `OnlyPartDelivery` | bit | No | `1` returns only the shippable lines of orders that also contain unshippable lines (part deliveries). |\n| `ShopId` | varchar(3) | No | Shop code. Only orders of customers with `CustomerOf` equal to this value are returned. Empty means all shops. |\n| `IncludeOrdersWithAnyShipDate` | bit | No | `0`: only orders without a ship date or with a ship date up to today. `1`: the ship date is ignored. |\n| `PerLocation` | bit | No | `1` adds `LocationId` to the details or groups the totals by location. Marked as the \"old way\" in the code. |\n| `UseFIFObyLocationV2` | bit | No | Controls the stock check: `1` checks the stock of the line's location, `0` checks the total stock of all non-special-stock locations. `NULL` uses the setting `UseFIFObyLocation`. |\n\n- All reads use `NOLOCK`. The result can contain uncommitted data and is a snapshot only; nothing is reserved or changed.\n- `NULL` values for `ViewDetails`, `IncludePartDelivery`, `OnlyPartDelivery` and `PerLocation` are treated as `0`. An empty `ShopId` is treated as \"all shops\". A `NULL` value for `IncludeOrdersWithAnyShipDate` acts like `0`.\n- **Settings that change the behaviour:**\n - `MultiCurrencyEnabled`: currency conversion and the `dbCurrency` column.\n - `HomeCurrency` and `DatabaseCurrencyExchRateSourceId`: which database currency and rate source are used.\n - `UseFIFObyLocation`: used when `UseFIFObyLocationV2` is `NULL`.\n- Whether an order is \"complete\" is judged only by its `ANG`/`EIN` lines with an item and positive quantity. Lines in other statuses are ignored.\n- `ShipCost` is the shipping cost of the order header, repeated on every line. The totals add it once per order. In the per-location totals it is added once per order and location, so an order spread over several locations counts its shipping cost in each of them.\n- In the overall totals (`ViewDetails = 0`, `PerLocation = 0`) one row is always returned. If nothing is shippable, `Orders` = 0, `ShipCost` = 0, and `OrderTotal`/`Picks` are `NULL`. The per-location totals return no rows in that case.\n- The comment in the code marks `PerLocation` as the \"old way\".\n- The internal stock procedure calls `log.EventDurationInsert` (definition not attached), which presumably writes a duration log entry.\n- The call scans all open `ANG`/`EIN` order lines and their reservations and can be expensive on large databases.\n\nDocumentation: https://pixi-api-docs.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": "Enables or disables partial delivery for an order and sets the related cancel and multi-partial-delivery flags, unless the order is closed or on hold.\n\nChanges the partial delivery settings in the header of one order.\n\n1. The overall state of the order is determined from its order lines:\n - `CLOSED` – all lines are in a final state, or the order has no order lines at all (this also applies to order numbers that do not exist).\n - `HOLD` – every line is either in status `HAL`, in status `MIN` or in a final state.\n - `OPEN` – otherwise.\n2. Only if the state is neither `CLOSED` nor `HOLD`, the order header with `OrderNr` = `@OrderNr` is updated:\n - `ForceToPicklistIfNotFULL` is set to `1` if `@PartialDeliveryActive` is `1`; if it is `0` or `NULL`, the field is set to `NULL` (partial delivery off). This value is always written.\n - `OHCancelAfterForcedShipOut` is set to `@CancelUnavailableItems`; if the parameter is omitted or `NULL`, the current value is kept.\n - `OHMultiForceToPicklist` is set to `@PartialDeliveryForRemaining`; if the parameter is omitted or `NULL`, the current value is kept.\n3. The number of affected rows is returned in the column `RowsUpdated` (`1` if the order header was updated).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Internal Pixi order number (`OrderHeader.OrderNr`) of the order to change. |\n| `PartialDeliveryActive` | bit | Yes | Switches partial delivery on or off (`ForceToPicklistIfNotFULL`). `1` sets the flag, `0` or `NULL` clears it to `NULL`. |\n| `CancelUnavailableItems` | bit | No | Value for `OHCancelAfterForcedShipOut` (cancel unavailable items after the forced partial shipment). `NULL` keeps the current value. |\n| `PartialDeliveryForRemaining` | bit | No | Value for `OHMultiForceToPicklist` (allow further partial deliveries for the remaining items). `NULL` keeps the current value. |\n\n- No error is raised if the order is closed, on hold or does not exist; the call simply performs no update. Check `RowsUpdated` to see whether the change was applied.\n- `RowsUpdated` is read from `@@ROWCOUNT` after the conditional update. If the update is skipped, the value is not explicitly set to `0` but taken from SQL Server's row count handling of the preceding statements; do not rely on it alone to distinguish states – query the order state separately if exact feedback is needed.\n- Unlike the other two flags, `@PartialDeliveryActive` has no keep-current fallback: passing `NULL` switches partial delivery off.\n- The order state is determined with `NOLOCK` reads on order lines, so concurrently changing lines may lead to a slightly outdated state check.\n- No explicit transaction is used.\n\nDocumentation: https://pixi-api-docs.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": "Enables or disables partial delivery for an order and sets the related cancel and multi-partial-delivery flags, unless the order is closed or on hold.\n\nChanges the partial delivery settings in the header of one order.\n\n1. The overall state of the order is determined from its order lines:\n - `CLOSED` – all lines are in a final state, or the order has no order lines at all (this also applies to order numbers that do not exist).\n - `HOLD` – every line is either in status `HAL`, in status `MIN` or in a final state.\n - `OPEN` – otherwise.\n2. Only if the state is neither `CLOSED` nor `HOLD`, the order header with `OrderNr` = `@OrderNr` is updated:\n - `ForceToPicklistIfNotFULL` is set to `1` if `@PartialDeliveryActive` is `1`; if it is `0` or `NULL`, the field is set to `NULL` (partial delivery off). This value is always written.\n - `OHCancelAfterForcedShipOut` is set to `@CancelUnavailableItems`; if the parameter is omitted or `NULL`, the current value is kept.\n - `OHMultiForceToPicklist` is set to `@PartialDeliveryForRemaining`; if the parameter is omitted or `NULL`, the current value is kept.\n3. The number of affected rows is returned in the column `RowsUpdated` (`1` if the order header was updated).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Internal Pixi order number (`OrderHeader.OrderNr`) of the order to change. |\n| `PartialDeliveryActive` | bit | Yes | Switches partial delivery on or off (`ForceToPicklistIfNotFULL`). `1` sets the flag, `0` or `NULL` clears it to `NULL`. |\n| `CancelUnavailableItems` | bit | No | Value for `OHCancelAfterForcedShipOut` (cancel unavailable items after the forced partial shipment). `NULL` keeps the current value. |\n| `PartialDeliveryForRemaining` | bit | No | Value for `OHMultiForceToPicklist` (allow further partial deliveries for the remaining items). `NULL` keeps the current value. |\n\n- No error is raised if the order is closed, on hold or does not exist; the call simply performs no update. Check `RowsUpdated` to see whether the change was applied.\n- `RowsUpdated` is read from `@@ROWCOUNT` after the conditional update. If the update is skipped, the value is not explicitly set to `0` but taken from SQL Server's row count handling of the preceding statements; do not rely on it alone to distinguish states – query the order state separately if exact feedback is needed.\n- Unlike the other two flags, `@PartialDeliveryActive` has no keep-current fallback: passing `NULL` switches partial delivery off.\n- The order state is determined with `NOLOCK` reads on order lines, so concurrently changing lines may lead to a slightly outdated state check.\n- No explicit transaction is used.\n\nDocumentation: https://pixi-api-docs.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": "Sets or changes the box range (first and last box number) assigned to a picklist after validating boxes, overlaps and box capacity.\n\nAssigns the box range `BoxNrFrom`–`BoxNrTo` to the picklist `Picklist`.\n\nThe call validates the input in this order and stops at the first failure, returning a row with `Status` = `Error` and a `Message`:\n\n1. The picklist must exist in `PLHeader`.\n2. `BoxNrFrom` must exist as a box in `boxes`.\n3. `BoxNrTo` must exist as a box in `boxes`.\n4. `BoxNrTo` must not be smaller than `BoxNrFrom`.\n5. If the setting `Picklist_Creation_Allow_BoxRange_OverLap` is `0`, no box number in the requested range may lie within the box range of any other picklist.\n6. The number of distinct orders on the picklist (via its picklist items and order lines) must not exceed the number of free boxes in the range. A box counts as free if its `BOrderNr` is `NULL` or `0`.\n\nIf all checks pass, the call:\n\n- deletes all existing box assignments of the picklist from `pixi.PicklistBox`,\n- writes the new range into `PLHeader.PLHfromBox` / `PLHeader.PLHtoBox`,\n- returns one row with the picklist key, the new range and a status text. The text says *set* if the picklist had no complete range before, otherwise *changed*.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Picklist` | int | Yes | Key of the picklist (`PLHeader.PLHkey`) whose box range is set. |\n| `BoxNrFrom` | int | Yes | First box number of the range. Must exist in `boxes`. |\n| `BoxNrTo` | int | Yes | Last box number of the range. Must exist in `boxes` and must not be smaller than `BoxNrFrom`. |\n\n- The delete and update run in a transaction. If the call is already inside an open transaction, a savepoint is used instead and the outer transaction is not committed.\n- On an unexpected SQL error the transaction (or savepoint) is rolled back, a row with `Status` = `Error` and the SQL error text is returned, and the error is logged via `log.InsertError` (definition not attached).\n- Validation queries use `NOLOCK`, so concurrent changes may not be seen.\n- The overlap check only runs if the setting value equals `0`. If the setting is missing (`NULL`) or has another value, overlapping ranges are allowed. The check relies on the `Numbers` helper table, so box numbers beyond its range are not checked.\n- Boxes that already hold an order (`BOrderNr` set) count as unavailable, even if that order belongs to the same picklist.\n- A former check that blocked changes once items of the picklist had been put into boxes was removed for backward compatibility. The range can therefore be changed even after items have been put into boxes; existing `pixi.PicklistBox` assignments are deleted in any case.\n- The success status text contains the spelling `succesfully` exactly as produced by the code.\n\nDocumentation: https://pixi-api-docs.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": "Sets or changes the box range (first and last box number) assigned to a picklist after validating boxes, overlaps and box capacity.\n\nAssigns the box range `BoxNrFrom`–`BoxNrTo` to the picklist `Picklist`.\n\nThe call validates the input in this order and stops at the first failure, returning a row with `Status` = `Error` and a `Message`:\n\n1. The picklist must exist in `PLHeader`.\n2. `BoxNrFrom` must exist as a box in `boxes`.\n3. `BoxNrTo` must exist as a box in `boxes`.\n4. `BoxNrTo` must not be smaller than `BoxNrFrom`.\n5. If the setting `Picklist_Creation_Allow_BoxRange_OverLap` is `0`, no box number in the requested range may lie within the box range of any other picklist.\n6. The number of distinct orders on the picklist (via its picklist items and order lines) must not exceed the number of free boxes in the range. A box counts as free if its `BOrderNr` is `NULL` or `0`.\n\nIf all checks pass, the call:\n\n- deletes all existing box assignments of the picklist from `pixi.PicklistBox`,\n- writes the new range into `PLHeader.PLHfromBox` / `PLHeader.PLHtoBox`,\n- returns one row with the picklist key, the new range and a status text. The text says *set* if the picklist had no complete range before, otherwise *changed*.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Picklist` | int | Yes | Key of the picklist (`PLHeader.PLHkey`) whose box range is set. |\n| `BoxNrFrom` | int | Yes | First box number of the range. Must exist in `boxes`. |\n| `BoxNrTo` | int | Yes | Last box number of the range. Must exist in `boxes` and must not be smaller than `BoxNrFrom`. |\n\n- The delete and update run in a transaction. If the call is already inside an open transaction, a savepoint is used instead and the outer transaction is not committed.\n- On an unexpected SQL error the transaction (or savepoint) is rolled back, a row with `Status` = `Error` and the SQL error text is returned, and the error is logged via `log.InsertError` (definition not attached).\n- Validation queries use `NOLOCK`, so concurrent changes may not be seen.\n- The overlap check only runs if the setting value equals `0`. If the setting is missing (`NULL`) or has another value, overlapping ranges are allowed. The check relies on the `Numbers` helper table, so box numbers beyond its range are not checked.\n- Boxes that already hold an order (`BOrderNr` set) count as unavailable, even if that order belongs to the same picklist.\n- A former check that blocked changes once items of the picklist had been put into boxes was removed for backward compatibility. The range can therefore be changed even after items have been put into boxes; existing `pixi.PicklistBox` assignments are deleted in any case.\n- The success status text contains the spelling `succesfully` exactly as produced by the code.\n\nDocumentation: https://pixi-api-docs.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": "Sets the shipping vendor and the DHL product, procedure and extras on an order header, identified by Pixi order number or external order number.\n\nUpdates the shipping information of one order in `OrderHeader`.\n\n1. The order is looked up with `OrderNr = @OrderNr OR OrderNrExternal = @OrderNrExternal`. If no order matches (including when both parameters are NULL), a row with `Status` 400 is returned and nothing is changed.\n2. If an order is found, the order row is read with `UPDLOCK, ROWLOCK`. `OrderNr` and `OrderNrExternal` are taken from the stored order. Each of `ShipVendor`, `DHLProdukt`, `DHLVerfahren` and `DHLExtra` that is passed as NULL or left out keeps its current value (`ShipVendorCode`, `Product`, `Verfahren`, `Extras`).\n3. The order is updated by its `OrderNr`. The update runs in its own transaction, or in a savepoint if the caller already has an open transaction.\n4. The call returns one status row with the current values of the order:\n - `Status` 200 with `Data updated in pixi` if a row was updated.\n - `Status` 500 with `Data could not be updated in pixi` if no row was updated, for example because an SQL error occurred.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number of the order to update. Either this or `OrderNrExternal` must identify the order. |\n| `OrderNrExternal` | varchar(50) | No | External order number (e.g. from the shop) used to find the order if `OrderNr` is not given. |\n| `ShipVendor` | varchar(3) | No | Shipping vendor code written to `ShipVendorCode`. NULL keeps the current value. |\n| `DHLProdukt` | varchar(50) | No | DHL product written to `Product`. NULL keeps the current value. |\n| `DHLVerfahren` | varchar(50) | No | DHL procedure (Verfahren) written to `Verfahren`. NULL keeps the current value. |\n| `DHLExtra` | varchar(50) | No | DHL extras written to `Extras`. NULL keeps the current value. |\n\n- A value cannot be reset to NULL with this call: NULL means \"keep the current value\". An empty string is written as such.\n- Because the lookup uses `OR`, passing both `OrderNr` and `OrderNrExternal` can match two different orders, or an external number can match several orders. In that case the variables are assigned from one of the matching rows without a defined order, and only that order is updated. Pass only one identifier to avoid ambiguity.\n- SQL errors are caught, the transaction (or savepoint) is rolled back and the error is logged via `log.InsertError` (definition not attached). No `SqlMessage` is returned; the caller only sees `Status` 500. If the transaction becomes uncommittable, a full `ROLLBACK` is executed, which also rolls back an outer transaction of the caller.\n- The existence check and the final status row read `OrderHeader` with `NOLOCK`.\n- The column types of `Product`, `Verfahren` and `Extras` are not visible in the code; values longer than the column size cause an error and therefore `Status` 500.\n\nDocumentation: https://pixi-api-docs.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": "Sets the shipping vendor and the DHL product, procedure and extras on an order header, identified by Pixi order number or external order number.\n\nUpdates the shipping information of one order in `OrderHeader`.\n\n1. The order is looked up with `OrderNr = @OrderNr OR OrderNrExternal = @OrderNrExternal`. If no order matches (including when both parameters are NULL), a row with `Status` 400 is returned and nothing is changed.\n2. If an order is found, the order row is read with `UPDLOCK, ROWLOCK`. `OrderNr` and `OrderNrExternal` are taken from the stored order. Each of `ShipVendor`, `DHLProdukt`, `DHLVerfahren` and `DHLExtra` that is passed as NULL or left out keeps its current value (`ShipVendorCode`, `Product`, `Verfahren`, `Extras`).\n3. The order is updated by its `OrderNr`. The update runs in its own transaction, or in a savepoint if the caller already has an open transaction.\n4. The call returns one status row with the current values of the order:\n - `Status` 200 with `Data updated in pixi` if a row was updated.\n - `Status` 500 with `Data could not be updated in pixi` if no row was updated, for example because an SQL error occurred.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number of the order to update. Either this or `OrderNrExternal` must identify the order. |\n| `OrderNrExternal` | varchar(50) | No | External order number (e.g. from the shop) used to find the order if `OrderNr` is not given. |\n| `ShipVendor` | varchar(3) | No | Shipping vendor code written to `ShipVendorCode`. NULL keeps the current value. |\n| `DHLProdukt` | varchar(50) | No | DHL product written to `Product`. NULL keeps the current value. |\n| `DHLVerfahren` | varchar(50) | No | DHL procedure (Verfahren) written to `Verfahren`. NULL keeps the current value. |\n| `DHLExtra` | varchar(50) | No | DHL extras written to `Extras`. NULL keeps the current value. |\n\n- A value cannot be reset to NULL with this call: NULL means \"keep the current value\". An empty string is written as such.\n- Because the lookup uses `OR`, passing both `OrderNr` and `OrderNrExternal` can match two different orders, or an external number can match several orders. In that case the variables are assigned from one of the matching rows without a defined order, and only that order is updated. Pass only one identifier to avoid ambiguity.\n- SQL errors are caught, the transaction (or savepoint) is rolled back and the error is logged via `log.InsertError` (definition not attached). No `SqlMessage` is returned; the caller only sees `Status` 500. If the transaction becomes uncommittable, a full `ROLLBACK` is executed, which also rolls back an outer transaction of the caller.\n- The existence check and the final status row read `OrderHeader` with `NOLOCK`.\n- The column types of `Product`, `Verfahren` and `Extras` are not visible in the code; values longer than the column size cause an error and therefore `Status` 500.\n\nDocumentation: https://pixi-api-docs.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": "Sets or removes the shipping lock of an order by updating its delivery address and writing a shipping lock history entry.\n\nSets the shipping lock (`ASlocked`) on the delivery address of an order.\n\n1. `Locked` = `NULL` is treated as `1`; an empty or `NULL` `UserName` becomes `API`.\n2. The delivery address reference (`ShipAdrRef`) is read from `OrderHeader` for `OrderNr`. If the order does not exist, or its `ShipAdrRef` is `NULL`, an `ERROR` row is returned.\n3. The referenced record in `Addresses` is selected only if it has `AddrType = 'S'` and its current `ASlocked` value differs from the target value (`Y` for lock, `N` for unlock). If no such address is found, an `INFO` row is returned and nothing is changed.\n4. If `Reason` is empty or `NULL`, it is replaced with `Order was locked by {UserName}` or `Order was unlocked by {UserName}`.\n5. A record is inserted into `pixi.AddressesShippingLockHistory`. It holds the user ID, the address key, the lock flag and the reason. The user ID is resolved from `UserName` via `inf.UserGetByName`, which falls back to the `pixiAdministration` user if the name is unknown.\n6. The address is updated:\n - `ASlocked` is set to `Y`/`N`.\n - `UpdateDate` is set to the current time.\n - `UpdateEmp` is set to the user name. The default `API` is written as `API SetOrderShippingLock`.\n7. An `OK` row is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Number of the order whose shipping lock is changed. |\n| `Locked` | bit | No | Target state of the shipping lock. `NULL` is treated as `1`. |\n| `UserName` | varchar(50) | No | Name of the user making the change. Empty or `NULL` becomes `API`. It is used to resolve the user ID for the history entry, falling back to `pixiAdministration`. It is also written to `UpdateEmp`, where `API` is stored as `API SetOrderShippingLock`. |\n| `Reason` | varchar(255) | No | Reason stored as `CustomerComment` in the shipping lock history. If empty, a default text `Order was locked by …` / `Order was unlocked by …` is used. |\n\n- The lock is stored on the address record referenced by the order's `ShipAdrRef`, not on the order header itself.\n- The `INFO` row (`already set to …`) is also returned when the referenced address does not exist or does not have `AddrType = 'S'`. In that case the message can be misleading.\n- `OrderHeader` is read with `NOLOCK`; the address is selected with `UPDLOCK`.\n- No explicit transaction is used. The history insert and the address update are separate statements, so they are not rolled back together.\n- During the update, `CONTEXT_INFO` is temporarily set to `0x33999` and restored afterwards. This is presumably evaluated by triggers on `Addresses`, which are not attached.\n- Status rows always use the column name `ErrorMessage`, also for the `OK` case.\n\nDocumentation: https://pixi-api-docs.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": "Sets or removes the shipping lock of an order by updating its delivery address and writing a shipping lock history entry.\n\nSets the shipping lock (`ASlocked`) on the delivery address of an order.\n\n1. `Locked` = `NULL` is treated as `1`; an empty or `NULL` `UserName` becomes `API`.\n2. The delivery address reference (`ShipAdrRef`) is read from `OrderHeader` for `OrderNr`. If the order does not exist, or its `ShipAdrRef` is `NULL`, an `ERROR` row is returned.\n3. The referenced record in `Addresses` is selected only if it has `AddrType = 'S'` and its current `ASlocked` value differs from the target value (`Y` for lock, `N` for unlock). If no such address is found, an `INFO` row is returned and nothing is changed.\n4. If `Reason` is empty or `NULL`, it is replaced with `Order was locked by {UserName}` or `Order was unlocked by {UserName}`.\n5. A record is inserted into `pixi.AddressesShippingLockHistory`. It holds the user ID, the address key, the lock flag and the reason. The user ID is resolved from `UserName` via `inf.UserGetByName`, which falls back to the `pixiAdministration` user if the name is unknown.\n6. The address is updated:\n - `ASlocked` is set to `Y`/`N`.\n - `UpdateDate` is set to the current time.\n - `UpdateEmp` is set to the user name. The default `API` is written as `API SetOrderShippingLock`.\n7. An `OK` row is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Number of the order whose shipping lock is changed. |\n| `Locked` | bit | No | Target state of the shipping lock. `NULL` is treated as `1`. |\n| `UserName` | varchar(50) | No | Name of the user making the change. Empty or `NULL` becomes `API`. It is used to resolve the user ID for the history entry, falling back to `pixiAdministration`. It is also written to `UpdateEmp`, where `API` is stored as `API SetOrderShippingLock`. |\n| `Reason` | varchar(255) | No | Reason stored as `CustomerComment` in the shipping lock history. If empty, a default text `Order was locked by …` / `Order was unlocked by …` is used. |\n\n- The lock is stored on the address record referenced by the order's `ShipAdrRef`, not on the order header itself.\n- The `INFO` row (`already set to …`) is also returned when the referenced address does not exist or does not have `AddrType = 'S'`. In that case the message can be misleading.\n- `OrderHeader` is read with `NOLOCK`; the address is selected with `UPDLOCK`.\n- No explicit transaction is used. The history insert and the address update are separate statements, so they are not rolled back together.\n- During the update, `CONTEXT_INFO` is temporarily set to `0x33999` and restored afterwards. This is presumably evaluated by triggers on `Addresses`, which are not attached.\n- Status rows always use the column name `ErrorMessage`, also for the `OK` case.\n\nDocumentation: https://pixi-api-docs.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": "Assigns one or more tags to orders, passed as XML, and returns a status row for every tag/order pair.\n\nCreates tag assignments (`TagMatch` entries) between tags and orders.\n\n1. The XML in `TagsXML` is parsed element-centric along `/Tags/Order/TagList/Tag`. Every `Tag` element becomes one candidate. Its `TagId` is combined with `OrderId` and `OrderNrExternal` from the enclosing `Order` element. The values `0` and empty strings are treated as missing.\n2. The order is resolved via `OrderHeader`:\n - `OrderId` is matched against `OrderHeader.OrderNr`.\n - `OrderNrExternal` is matched against `OrderHeader.OrderNrExternal`.\n - If both are given, the order number (`OrderId`) takes precedence.\n3. Each candidate is validated:\n - No `TagId`, or neither an order number nor an external order number: `Mandatory parameter is missing`.\n - The order cannot be found, or the tag does not exist as an order tag (`Tag.TypeId = 2`): `One of the provided values is not valid`.\n - The tag is already assigned to the order: warning `Tag is already assigned to that order`.\n4. All remaining candidates are inserted into `TagMatch` (`TagId`, `OrderHeaderId`). Duplicate pairs in the XML are written only once.\n\nThe call returns one row per processed candidate, in the order of the `Tag` elements in the XML. Each row carries the status and the message.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | No | XML with orders and the tags to assign. Each `Order` element identifies the order by `OrderId` (Pixi order number) or `OrderNrExternal`. Its `TagList` holds `Tag` elements, each with a `TagId`. |\n\n- The call runs in its own transaction. If it is called inside an existing transaction, it uses a savepoint instead.\n- Lookups on `OrderHeader`, `Tag` and `TagMatch` use `NOLOCK`.\n- If an unexpected error occurs (for example invalid XML), the `CATCH` block rolls the transaction back and logs the error via `log.InsertError`. No result set is returned in that case. The internal message `Unexpected error: ...` is built but never selected.\n- Only tags with `TypeId = 2` (order tags) are accepted.\n- If an `OrderNrExternal` matches several orders, one candidate can produce several result rows.\n- If `TagsXML` is omitted (`NULL`) or contains no `Tag` elements, nothing is assigned.\n\nDocumentation: https://pixi-api-docs.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": "Assigns one or more tags to orders, passed as XML, and returns a status row for every tag/order pair.\n\nCreates tag assignments (`TagMatch` entries) between tags and orders.\n\n1. The XML in `TagsXML` is parsed element-centric along `/Tags/Order/TagList/Tag`. Every `Tag` element becomes one candidate. Its `TagId` is combined with `OrderId` and `OrderNrExternal` from the enclosing `Order` element. The values `0` and empty strings are treated as missing.\n2. The order is resolved via `OrderHeader`:\n - `OrderId` is matched against `OrderHeader.OrderNr`.\n - `OrderNrExternal` is matched against `OrderHeader.OrderNrExternal`.\n - If both are given, the order number (`OrderId`) takes precedence.\n3. Each candidate is validated:\n - No `TagId`, or neither an order number nor an external order number: `Mandatory parameter is missing`.\n - The order cannot be found, or the tag does not exist as an order tag (`Tag.TypeId = 2`): `One of the provided values is not valid`.\n - The tag is already assigned to the order: warning `Tag is already assigned to that order`.\n4. All remaining candidates are inserted into `TagMatch` (`TagId`, `OrderHeaderId`). Duplicate pairs in the XML are written only once.\n\nThe call returns one row per processed candidate, in the order of the `Tag` elements in the XML. Each row carries the status and the message.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | No | XML with orders and the tags to assign. Each `Order` element identifies the order by `OrderId` (Pixi order number) or `OrderNrExternal`. Its `TagList` holds `Tag` elements, each with a `TagId`. |\n\n- The call runs in its own transaction. If it is called inside an existing transaction, it uses a savepoint instead.\n- Lookups on `OrderHeader`, `Tag` and `TagMatch` use `NOLOCK`.\n- If an unexpected error occurs (for example invalid XML), the `CATCH` block rolls the transaction back and logs the error via `log.InsertError`. No result set is returned in that case. The internal message `Unexpected error: ...` is built but never selected.\n- Only tags with `TypeId = 2` (order tags) are accepted.\n- If an `OrderNrExternal` matches several orders, one candidate can produce several result rows.\n- If `TagsXML` is omitted (`NULL`) or contains no `Tag` elements, nothing is assigned.\n\nDocumentation: https://pixi-api-docs.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": "Removes tag assignments (TagMatch) from orders for the tag/order pairs passed as XML and returns one status row per pair.\n\nDeletes the assignment of order tags to orders. The pairs are passed in `TagsXML`; every `Tag` element below `/Tags/Order/TagList` is one request entry.\n\nSteps:\n\n1. The XML is read element-centric. For each `Tag` the `TagId` is taken from the `Tag` element, `OrderId` and `OrderNrExternal` from the parent `Order` element. A `TagId` or `OrderId` of `0` and an empty `OrderNrExternal` are treated as missing.\n2. The order is resolved in `OrderHeader`: by `OrderNr` = `OrderId` and by `OrderNrExternal`. The order header key found via `OrderId` takes precedence; if none is found, the key found via `OrderNrExternal` is used. If only `OrderNrExternal` is given, the returned `OrderId` is the `OrderNr` of the matched order.\n3. Each entry is validated:\n - no `TagId`, or neither `OrderId` nor `OrderNrExternal` → `Error` *Mandatory parameter is missing*\n - order not found, or tag not found as an order tag (`Tag.TypeId = 2`) → `Error` *One of the provided values is not valid*\n4. For valid entries an existing `TagMatch` row with this tag and order header is looked up. If it exists, the entry gets `Success` *Tag was successfully removed from order* and the `TagMatch` row is deleted. If it does not exist, the entry gets `Warning` *Tag is not assigned to that order*.\n5. One result row per entry is returned, sorted in the order of the entries in the XML.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | No | XML document with the orders and the tags to remove. Each `Order` element contains `OrderId` (Pixi `OrderNr`) and/or `OrderNrExternal` and a `TagList` with one or more `Tag` elements, each with a `TagId`. |\n\n- Only tags with `TypeId = 2` (order tags) are considered.\n- The call runs in its own transaction, or in a savepoint if a transaction is already open.\n- If an unexpected error occurs (e.g. malformed XML), the transaction is rolled back, the error is logged via `log.InsertError` (not attached) and **no result set is returned**. The text `Unexpected error: \"…\"` is built internally but not selected.\n- Lookups in `OrderHeader`, `Tag` and `TagMatch` use `NOLOCK`; the delete uses `ROWLOCK`.\n- If several orders share the same `OrderNrExternal`, the entry can produce several result rows and the tag is removed from all matching orders.\n- The same tag/order pair listed twice returns `Success` for both entries; the `TagMatch` row is deleted once.\n- The header comment of the procedure says *Create TagMatch for Order*, but the code only deletes assignments.\n\nDocumentation: https://pixi-api-docs.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": "Removes tag assignments (TagMatch) from orders for the tag/order pairs passed as XML and returns one status row per pair.\n\nDeletes the assignment of order tags to orders. The pairs are passed in `TagsXML`; every `Tag` element below `/Tags/Order/TagList` is one request entry.\n\nSteps:\n\n1. The XML is read element-centric. For each `Tag` the `TagId` is taken from the `Tag` element, `OrderId` and `OrderNrExternal` from the parent `Order` element. A `TagId` or `OrderId` of `0` and an empty `OrderNrExternal` are treated as missing.\n2. The order is resolved in `OrderHeader`: by `OrderNr` = `OrderId` and by `OrderNrExternal`. The order header key found via `OrderId` takes precedence; if none is found, the key found via `OrderNrExternal` is used. If only `OrderNrExternal` is given, the returned `OrderId` is the `OrderNr` of the matched order.\n3. Each entry is validated:\n - no `TagId`, or neither `OrderId` nor `OrderNrExternal` → `Error` *Mandatory parameter is missing*\n - order not found, or tag not found as an order tag (`Tag.TypeId = 2`) → `Error` *One of the provided values is not valid*\n4. For valid entries an existing `TagMatch` row with this tag and order header is looked up. If it exists, the entry gets `Success` *Tag was successfully removed from order* and the `TagMatch` row is deleted. If it does not exist, the entry gets `Warning` *Tag is not assigned to that order*.\n5. One result row per entry is returned, sorted in the order of the entries in the XML.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `TagsXML` | varchar(max) | No | XML document with the orders and the tags to remove. Each `Order` element contains `OrderId` (Pixi `OrderNr`) and/or `OrderNrExternal` and a `TagList` with one or more `Tag` elements, each with a `TagId`. |\n\n- Only tags with `TypeId = 2` (order tags) are considered.\n- The call runs in its own transaction, or in a savepoint if a transaction is already open.\n- If an unexpected error occurs (e.g. malformed XML), the transaction is rolled back, the error is logged via `log.InsertError` (not attached) and **no result set is returned**. The text `Unexpected error: \"…\"` is built internally but not selected.\n- Lookups in `OrderHeader`, `Tag` and `TagMatch` use `NOLOCK`; the delete uses `ROWLOCK`.\n- If several orders share the same `OrderNrExternal`, the entry can produce several result rows and the tag is removed from all matching orders.\n- The same tag/order pair listed twice returns `Success` for both entries; the `TagMatch` row is deleted once.\n- The header comment of the procedure says *Create TagMatch for Order*, but the code only deletes assignments.\n\nDocumentation: https://pixi-api-docs.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": "Updates shipping costs, ship date, shop note, voucher, address remarks and payment type of an existing open order.\n\nUpdates selected header data of an existing order. The order is found by `OrderNr` or `OrderNrExternal`.\n\n**Validation steps (each returns an `Error` row and stops):**\n1. At least one of `OrderNr` or `OrderNrExternal` must be given.\n2. The order is looked up with `OrderNr = @OrderNr OR OrderNrExternal = @OrderNrExternal` (first match). If none is found, an error is returned.\n3. `VoucherID` and `VoucherAmount` must be given together.\n4. The voucher must not be used on order lines of another order.\n5. If `PaymentType` is given, it must exist as a `Code` in the `Payments` table.\n6. The order must still be editable: the overall order state, calculated from the order lines, must be `OPEN` or `HOLD`. In addition, the number of non-final order lines that already have invoice lines must be lower than the number of lines that are neither final nor in status `MIN` or `FUS`.\n\n**Update:**\n- Parameters that are left out keep the current values of the order.\n- `ShipCosts` is applied to the net shipping costs for `B2B` orders and to the gross shipping costs for `B2C` orders.\n- `ShipDate` replaces the ship date. The value `1900-01-01` clears it to `NULL`.\n- `ShopNote` and `AddressRemarks` replace the stored texts.\n- All other header fields, such as gift message, shipping instructions, ship vendor, CCP merchant, `ccpPayID`, Verfahren/Product/Extras and order type, are passed through unchanged.\n- The actual update is done by the internal procedure `Pixi_UpdateOrder`. It sets `UpdateDate` to the current time.\n- If the shipping costs change and no voucher or discount applies, the `ShipCost` of the order lines is updated as well.\n- If a voucher is given, it is created in `Voucher` if it does not exist yet. Otherwise its amount is updated. The voucher ID is then written to all order lines.\n- If `PaymentType` is given, it is written to `APayment` of the order's address (`AddrRef`).\n\nOn success, a `Success` row is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. Either this or `OrderNrExternal` is required. |\n| `OrderNrExternal` | varchar(50) | No | External (shop) order number. Used if `OrderNr` is not given; empty string counts as not given. |\n| `ShipCosts` | money | No | New shipping costs (net for `B2B`, gross for `B2C` orders). If omitted, the current value is kept. |\n| `ShipDate` | datetime | No | New ship date. If omitted, the current value is kept; `1900-01-01` clears it. |\n| `ShopNote` | varchar(max) | No | Note received from the shop with this order (shop comment). If omitted, the current note is kept. |\n| `VoucherID` | varchar(50) | No | Voucher ID. Must be given together with `VoucherAmount` and must not be used on another order. |\n| `VoucherAmount` | money | No | Amount covered by the voucher. Requires `VoucherID`; `0` is treated as not provided. |\n| `PaymentType` | varchar(1) | No | Payment type code; must exist in `Payments`. Written to `APayment` of the order address. Empty string counts as not given. |\n| `AddressRemarks` | varchar(255) | No | New address remarks of the order. If omitted, the current value is kept. |\n\n- `VoucherAmount` is passed through `NULLIF(@VoucherAmount, '')`. Because `''` converts to `0` for `money`, an amount of `0` is treated as *not provided*. Passing `VoucherID` with amount `0` therefore returns `VoucherID provided without VoucherAmount.`\n- An empty `VoucherID` is treated as not provided.\n- If both `OrderNr` and `OrderNrExternal` are given and match different orders, an arbitrary one of them is updated (`TOP (1)` without `ORDER BY`).\n- In the *does not exist* error, the message is built by string concatenation. If one of the two identifiers is `NULL`, the `Message` column is `NULL`.\n- `Pixi_UpdateOrder` runs in its own transaction and catches its own errors. It logs them via `log.InsertError` and does not re-raise them, so the outer error handler may not see them. A `Success` row can therefore be returned even if the inner update was rolled back. `log.InsertError` is not attached.\n- The `Addresses` update for the payment type happens after the inner transaction and outside of it.\n- If the order has no CCP merchant, the inner procedure may set one based on the setting `DefaultCCPMerchant`.\n- If `ccpPayID` is `NULL` on an open order, it is stored as an empty string.\n- `ShopNote` is declared as `varchar(max)`. Characters outside the database code page are lost, even though the target column is `nvarchar`.\n- Reads in the validation part use `NOLOCK`; the inner procedure uses `UPDLOCK` on `OrderHeader` and `Orderlines`.\n\nDocumentation: https://pixi-api-docs.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": "Updates shipping costs, ship date, shop note, voucher, address remarks and payment type of an existing open order.\n\nUpdates selected header data of an existing order. The order is found by `OrderNr` or `OrderNrExternal`.\n\n**Validation steps (each returns an `Error` row and stops):**\n1. At least one of `OrderNr` or `OrderNrExternal` must be given.\n2. The order is looked up with `OrderNr = @OrderNr OR OrderNrExternal = @OrderNrExternal` (first match). If none is found, an error is returned.\n3. `VoucherID` and `VoucherAmount` must be given together.\n4. The voucher must not be used on order lines of another order.\n5. If `PaymentType` is given, it must exist as a `Code` in the `Payments` table.\n6. The order must still be editable: the overall order state, calculated from the order lines, must be `OPEN` or `HOLD`. In addition, the number of non-final order lines that already have invoice lines must be lower than the number of lines that are neither final nor in status `MIN` or `FUS`.\n\n**Update:**\n- Parameters that are left out keep the current values of the order.\n- `ShipCosts` is applied to the net shipping costs for `B2B` orders and to the gross shipping costs for `B2C` orders.\n- `ShipDate` replaces the ship date. The value `1900-01-01` clears it to `NULL`.\n- `ShopNote` and `AddressRemarks` replace the stored texts.\n- All other header fields, such as gift message, shipping instructions, ship vendor, CCP merchant, `ccpPayID`, Verfahren/Product/Extras and order type, are passed through unchanged.\n- The actual update is done by the internal procedure `Pixi_UpdateOrder`. It sets `UpdateDate` to the current time.\n- If the shipping costs change and no voucher or discount applies, the `ShipCost` of the order lines is updated as well.\n- If a voucher is given, it is created in `Voucher` if it does not exist yet. Otherwise its amount is updated. The voucher ID is then written to all order lines.\n- If `PaymentType` is given, it is written to `APayment` of the order's address (`AddrRef`).\n\nOn success, a `Success` row is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | No | Pixi order number. Either this or `OrderNrExternal` is required. |\n| `OrderNrExternal` | varchar(50) | No | External (shop) order number. Used if `OrderNr` is not given; empty string counts as not given. |\n| `ShipCosts` | money | No | New shipping costs (net for `B2B`, gross for `B2C` orders). If omitted, the current value is kept. |\n| `ShipDate` | datetime | No | New ship date. If omitted, the current value is kept; `1900-01-01` clears it. |\n| `ShopNote` | varchar(max) | No | Note received from the shop with this order (shop comment). If omitted, the current note is kept. |\n| `VoucherID` | varchar(50) | No | Voucher ID. Must be given together with `VoucherAmount` and must not be used on another order. |\n| `VoucherAmount` | money | No | Amount covered by the voucher. Requires `VoucherID`; `0` is treated as not provided. |\n| `PaymentType` | varchar(1) | No | Payment type code; must exist in `Payments`. Written to `APayment` of the order address. Empty string counts as not given. |\n| `AddressRemarks` | varchar(255) | No | New address remarks of the order. If omitted, the current value is kept. |\n\n- `VoucherAmount` is passed through `NULLIF(@VoucherAmount, '')`. Because `''` converts to `0` for `money`, an amount of `0` is treated as *not provided*. Passing `VoucherID` with amount `0` therefore returns `VoucherID provided without VoucherAmount.`\n- An empty `VoucherID` is treated as not provided.\n- If both `OrderNr` and `OrderNrExternal` are given and match different orders, an arbitrary one of them is updated (`TOP (1)` without `ORDER BY`).\n- In the *does not exist* error, the message is built by string concatenation. If one of the two identifiers is `NULL`, the `Message` column is `NULL`.\n- `Pixi_UpdateOrder` runs in its own transaction and catches its own errors. It logs them via `log.InsertError` and does not re-raise them, so the outer error handler may not see them. A `Success` row can therefore be returned even if the inner update was rolled back. `log.InsertError` is not attached.\n- The `Addresses` update for the payment type happens after the inner transaction and outside of it.\n- If the order has no CCP merchant, the inner procedure may set one based on the setting `DefaultCCPMerchant`.\n- If `ccpPayID` is `NULL` on an open order, it is stored as an empty string.\n- `ShopNote` is declared as `varchar(max)`. Characters outside the database code page are lost, even though the target column is `nvarchar`.\n- Reads in the validation part use `NOLOCK`; the inner procedure uses `UPDLOCK` on `OrderHeader` and `Orderlines`.\n\nDocumentation: https://pixi-api-docs.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": "Automatically matches the bank lines of a bank header to open orders or invoices, confirms the match and releases the order if it is fully paid.\n\nRuns the automatic payment matching for one bank header (`BankHeaderKey`) and, if a match was found, confirms it and tries to release the matched order.\n\n1. If `BankHeaderKey` is NULL, a single row with NULL values and the message `Parameter BankHeaderKey is mandatory!` is returned and nothing else happens.\n2. The internal automatic matching (`Pixi_BankAutomaticMatching`) is executed for all bank lines of this header that do not yet have an entry in `BankMatch`. It looks for 100% hits:\n - **Orders** whose payment method (`Payments.MatchToOrders = 1`) allows matching and that have at least one order line in status `HAL`. The bank amount must equal the open amount (`OrderTotal - PaidByCustomer`, rounded to 2 decimals) in the same currency, and the bank text (`BankText01`–`BankText03`) must contain the external order number (optionally without prefix), the `ccpPayID`, a unique external customer number or a unique e-mail address.\n - **Invoices** that are completely unpaid and whose payment method has `MatchToInvoices = 1`. The bank amount must equal the invoice total; the bank text must contain the invoice number, the external order number, the customer number or the e-mail.\n - Ambiguous candidates are discarded. Found matches are written to `BankMatch` as prematches (`IsPrematch = 1`).\n3. If no match was found, the returned `message` is `0 matched orders/invoices found.` followed by a line break and the statistics text of the matching (number of bank lines, open and matched orders/invoices).\n4. Otherwise the `BankMatch` entry of the bank line of this header is read, and all prematches of this bank line are confirmed (`IsPrematch` set to 0).\n5. For the matched order, `OrderNr` and the difference `ABS(OrderTotal - PaidByCustomer)` are read from `OrderHeader`:\n - Difference 0: all order lines of the order in status `HAL` (on hold) are set to `ANG` with update user `IPN_API (payments)`; message `Delta: 0; releasing order: {OrderNr}`.\n - Otherwise: message `Delta: {Delta}; cannot release order:{OrderNr}`; the order stays on hold.\n6. Unless `SuppressOutput = 1`, one row with `OrderHeaderKey`, `OrderNr`, `AmountMatched`, `BankLineKey` and `message` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BankHeaderKey` | int | No | Key of the bank header whose bank lines are matched. Effectively mandatory; if omitted, an error row is returned. |\n| `SuppressOutput` | bit | No | Suppresses the result row after processing. NULL is treated as 0. The error row for a missing `BankHeaderKey` is always returned. |\n\n- **One bank line per header expected:** the bank line is determined by a subquery on `BankLines` filtered by `BankHeaderRef`. If the bank header has more than one bank line and a match was found, SQL Server raises error 512 (subquery returned more than one value), returned as `SqlMessage`. At that point the prematches are already written to `BankMatch`. The call is designed for headers with a single line (e.g. one payment notification per header, update user `IPN_API`).\n- **No transaction:** matching, confirmation and order release run as separate steps. An error in a later step does not undo earlier steps.\n- The `BankMatch` entry is read without filtering on `IsPrematch`; if several entries exist for the bank line, an arbitrary one is returned.\n- If the match refers to an invoice instead of an order, `OrderHeaderKey`, `OrderNr` are NULL, no order is released and `message` is NULL (string concatenation with NULL).\n- If no `BankMatch` row is found despite a match (so `BankLineKey` is NULL), the confirmation step falls into its mass branch and confirms up to 100 arbitrary prematches of all bank lines.\n- Whether `PaidByCustomer` is already updated when the difference is calculated depends on logic not visible in the code (e.g. triggers on `BankMatch`).\n- Matching behaviour is influenced by the settings `AutomatchBanklines_Enforce_CustomerNrExternal` (order/invoice number must be accompanied by the customer number unless set to `0`) and `AutomatchBanklinesStrictOrderNrExternalMatchOnly` (`1` disables matching by external order number without prefix). Unprefixed order numbers are only used with at least 5 characters.\n- Reads use `NOLOCK`, so uncommitted data may be considered.\n- If releasing the order fails, the error is written to `LogTable` and re-raised.\n\nDocumentation: https://pixi-api-docs.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": "Automatically matches the bank lines of a bank header to open orders or invoices, confirms the match and releases the order if it is fully paid.\n\nRuns the automatic payment matching for one bank header (`BankHeaderKey`) and, if a match was found, confirms it and tries to release the matched order.\n\n1. If `BankHeaderKey` is NULL, a single row with NULL values and the message `Parameter BankHeaderKey is mandatory!` is returned and nothing else happens.\n2. The internal automatic matching (`Pixi_BankAutomaticMatching`) is executed for all bank lines of this header that do not yet have an entry in `BankMatch`. It looks for 100% hits:\n - **Orders** whose payment method (`Payments.MatchToOrders = 1`) allows matching and that have at least one order line in status `HAL`. The bank amount must equal the open amount (`OrderTotal - PaidByCustomer`, rounded to 2 decimals) in the same currency, and the bank text (`BankText01`–`BankText03`) must contain the external order number (optionally without prefix), the `ccpPayID`, a unique external customer number or a unique e-mail address.\n - **Invoices** that are completely unpaid and whose payment method has `MatchToInvoices = 1`. The bank amount must equal the invoice total; the bank text must contain the invoice number, the external order number, the customer number or the e-mail.\n - Ambiguous candidates are discarded. Found matches are written to `BankMatch` as prematches (`IsPrematch = 1`).\n3. If no match was found, the returned `message` is `0 matched orders/invoices found.` followed by a line break and the statistics text of the matching (number of bank lines, open and matched orders/invoices).\n4. Otherwise the `BankMatch` entry of the bank line of this header is read, and all prematches of this bank line are confirmed (`IsPrematch` set to 0).\n5. For the matched order, `OrderNr` and the difference `ABS(OrderTotal - PaidByCustomer)` are read from `OrderHeader`:\n - Difference 0: all order lines of the order in status `HAL` (on hold) are set to `ANG` with update user `IPN_API (payments)`; message `Delta: 0; releasing order: {OrderNr}`.\n - Otherwise: message `Delta: {Delta}; cannot release order:{OrderNr}`; the order stays on hold.\n6. Unless `SuppressOutput = 1`, one row with `OrderHeaderKey`, `OrderNr`, `AmountMatched`, `BankLineKey` and `message` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BankHeaderKey` | int | No | Key of the bank header whose bank lines are matched. Effectively mandatory; if omitted, an error row is returned. |\n| `SuppressOutput` | bit | No | Suppresses the result row after processing. NULL is treated as 0. The error row for a missing `BankHeaderKey` is always returned. |\n\n- **One bank line per header expected:** the bank line is determined by a subquery on `BankLines` filtered by `BankHeaderRef`. If the bank header has more than one bank line and a match was found, SQL Server raises error 512 (subquery returned more than one value), returned as `SqlMessage`. At that point the prematches are already written to `BankMatch`. The call is designed for headers with a single line (e.g. one payment notification per header, update user `IPN_API`).\n- **No transaction:** matching, confirmation and order release run as separate steps. An error in a later step does not undo earlier steps.\n- The `BankMatch` entry is read without filtering on `IsPrematch`; if several entries exist for the bank line, an arbitrary one is returned.\n- If the match refers to an invoice instead of an order, `OrderHeaderKey`, `OrderNr` are NULL, no order is released and `message` is NULL (string concatenation with NULL).\n- If no `BankMatch` row is found despite a match (so `BankLineKey` is NULL), the confirmation step falls into its mass branch and confirms up to 100 arbitrary prematches of all bank lines.\n- Whether `PaidByCustomer` is already updated when the difference is calculated depends on logic not visible in the code (e.g. triggers on `BankMatch`).\n- Matching behaviour is influenced by the settings `AutomatchBanklines_Enforce_CustomerNrExternal` (order/invoice number must be accompanied by the customer number unless set to `0`) and `AutomatchBanklinesStrictOrderNrExternalMatchOnly` (`1` disables matching by external order number without prefix). Unprefixed order numbers are only used with at least 5 characters.\n- Reads use `NOLOCK`, so uncommitted data may be considered.\n- If releasing the order fails, the error is written to `LogTable` and re-raised.\n\nDocumentation: https://pixi-api-docs.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": "Returns the number of bank lines that match the given bank texts and, optionally, the amount.\n\nChecks whether bank lines (`BankLines`) with the given values already exist, for example before importing a bank statement.\n\n- Empty strings in `BankText01`, `BankText02` and `BankText03` are treated as `NULL`.\n- At least one of the three text parameters must be filled. If all three are empty or missing, no search is done; the result row has `count` = 0 and the column `error` contains a message.\n- Otherwise all bank lines are counted where each **given** parameter matches the column of the same name exactly (`=` comparison, no `LIKE`). Parameters that are not given do not restrict the search.\n- `BankAmount` is optional and is compared exactly with `BankAmount`.\n\nThe call always returns exactly one row with the count, a text message and an error text (or `NULL`).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BankText01` | varchar(1024) | No | First bank text to search for (exact match on `BankText01`). Empty string counts as not given. At least one of the three text parameters is required. |\n| `BankText02` | varchar(1024) | No | Second bank text to search for (exact match on `BankText02`). Empty string counts as not given. |\n| `BankText03` | varchar(1024) | No | Third bank text to search for (exact match on `BankText03`). Empty string counts as not given. |\n| `BankAmount` | money | No | Optional amount of the bank line (exact match on `BankAmount`). If not given, the amount is not used as a filter. |\n\n- Errors are not raised as SQL errors. Check the column `error`: if it is not `NULL`, the parameters were invalid. In that case `message` still says `No bankline was found.`.\n- Pitfall: a parameter that is not given is replaced by the column itself (`ISNULL(@Param, Column)`). Bank lines where one of the columns `BankText01`, `BankText02`, `BankText03` or `BankAmount` is `NULL` are therefore **never** counted, even if that parameter was not passed.\n- Text comparison uses the collation of the database (usually case-insensitive). Trailing spaces are ignored in the comparison, leading spaces are not.\n- The query reads without `NOLOCK`. There are no side effects.\n\nDocumentation: https://pixi-api-docs.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": "Returns the number of bank lines that match the given bank texts and, optionally, the amount.\n\nChecks whether bank lines (`BankLines`) with the given values already exist, for example before importing a bank statement.\n\n- Empty strings in `BankText01`, `BankText02` and `BankText03` are treated as `NULL`.\n- At least one of the three text parameters must be filled. If all three are empty or missing, no search is done; the result row has `count` = 0 and the column `error` contains a message.\n- Otherwise all bank lines are counted where each **given** parameter matches the column of the same name exactly (`=` comparison, no `LIKE`). Parameters that are not given do not restrict the search.\n- `BankAmount` is optional and is compared exactly with `BankAmount`.\n\nThe call always returns exactly one row with the count, a text message and an error text (or `NULL`).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BankText01` | varchar(1024) | No | First bank text to search for (exact match on `BankText01`). Empty string counts as not given. At least one of the three text parameters is required. |\n| `BankText02` | varchar(1024) | No | Second bank text to search for (exact match on `BankText02`). Empty string counts as not given. |\n| `BankText03` | varchar(1024) | No | Third bank text to search for (exact match on `BankText03`). Empty string counts as not given. |\n| `BankAmount` | money | No | Optional amount of the bank line (exact match on `BankAmount`). If not given, the amount is not used as a filter. |\n\n- Errors are not raised as SQL errors. Check the column `error`: if it is not `NULL`, the parameters were invalid. In that case `message` still says `No bankline was found.`.\n- Pitfall: a parameter that is not given is replaced by the column itself (`ISNULL(@Param, Column)`). Bank lines where one of the columns `BankText01`, `BankText02`, `BankText03` or `BankAmount` is `NULL` are therefore **never** counted, even if that parameter was not passed.\n- Text comparison uses the collation of the database (usually case-insensitive). Trailing spaces are ignored in the comparison, leading spaces are not.\n- The query reads without `NOLOCK`. There are no side effects.\n\nDocumentation: https://pixi-api-docs.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": "Creates a manual booking event in a customer's account and optionally matches it to an existing account entry or invoice.\n\nAdds a manual booking (for example a manual payment or a correction) to the customer account of the customer `CustKey`.\n\nSteps:\n\n1. `EventDate` defaults to the current date and time if it is not passed.\n2. If `MatchToInvoiceNr` is set, the call looks up the newest customer account entry (`MAX(CustomerAccountKey)`) that refers to this invoice. The invoice must belong to `CustKey`. The key found replaces any value passed in `MatchKey`. If no entry is found, an error is returned.\n3. `EventID` must exist in the customer account event definitions and must be flagged as manual (`IsManual = 1`).\n4. `EventDate` must not be in the future.\n5. If `CurrencyId` is not passed, the base currency of the shop the customer belongs to is used.\n6. The booking is inserted with the user name `API`. The exchange rate is determined automatically for the shop, currency and `EventDate`.\n7. If a match key is known (from `MatchToInvoiceNr` or `MatchKey`), the new entry is matched with that entry. The match is only created if both entries still have an open amount, the signs of the two entries are opposite, `Amount` is not 0 and the amount of the target entry is not 0. The matched amount is the smaller of the two open amounts.\n\nThe whole call runs in one transaction. It returns a single row with `ReturnCode` = `OK` on success or `ERROR` with the error text.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | Yes | Key of the customer whose account receives the booking. |\n| `EventID` | varchar(3) | Yes | ID of the customer account event to book. The event must exist and be flagged as manual. |\n| `Amount` | money | Yes | Amount of the booking. |\n| `EventDate` | datetime | No | Date and time of the booking. Must not be in the future. If `NULL`, the current date and time is used. |\n| `Comment` | varchar(512) | No | Comment stored as reference of the booking. `NULL` is stored as an empty string. |\n| `MatchToInvoiceNr` | varchar(20) | No | Number of an invoice of this customer. The new booking is matched with the newest account entry of this invoice. Overrides `MatchKey`. |\n| `MatchKey` | int | No | Key of the customer account entry (`CustomerAccountKey`) to match the new booking with. Ignored if `MatchToInvoiceNr` is set. |\n| `CurrencyId` | smallint | No | Currency of the booking. If `NULL`, the base currency of the customer's shop is used. |\n\n- Validation errors and errors from the exchange rate lookup roll back the transaction and return an `ERROR` row.\n- Errors during the insert or the match inside the internal booking procedure are caught there and not passed on. In that case the call can still return `OK` although no booking was created. Check the customer account afterwards if this matters.\n- The customer account entry for the new booking is read back via `ManualBookingRef`. It is probably created by logic on the manual booking table that is not visible here.\n- The exchange rate lookup (`pixi.GetExchRateID`) and the match procedure (`Pixi_CA_InsertMatch`) are not attached; their exact behaviour is unknown.\n- `MatchKey` is not checked for belonging to the customer. Prefer `MatchToInvoiceNr`, which is checked.\n- `CustKey` is not validated explicitly. For an unknown customer, `CurrencyId` stays `NULL` if it is not passed.\n- The error text for a future date mentions a \"paid date\"; it refers to `EventDate`.\n- Lookups use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Creates a manual booking event in a customer's account and optionally matches it to an existing account entry or invoice.\n\nAdds a manual booking (for example a manual payment or a correction) to the customer account of the customer `CustKey`.\n\nSteps:\n\n1. `EventDate` defaults to the current date and time if it is not passed.\n2. If `MatchToInvoiceNr` is set, the call looks up the newest customer account entry (`MAX(CustomerAccountKey)`) that refers to this invoice. The invoice must belong to `CustKey`. The key found replaces any value passed in `MatchKey`. If no entry is found, an error is returned.\n3. `EventID` must exist in the customer account event definitions and must be flagged as manual (`IsManual = 1`).\n4. `EventDate` must not be in the future.\n5. If `CurrencyId` is not passed, the base currency of the shop the customer belongs to is used.\n6. The booking is inserted with the user name `API`. The exchange rate is determined automatically for the shop, currency and `EventDate`.\n7. If a match key is known (from `MatchToInvoiceNr` or `MatchKey`), the new entry is matched with that entry. The match is only created if both entries still have an open amount, the signs of the two entries are opposite, `Amount` is not 0 and the amount of the target entry is not 0. The matched amount is the smaller of the two open amounts.\n\nThe whole call runs in one transaction. It returns a single row with `ReturnCode` = `OK` on success or `ERROR` with the error text.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustKey` | int | Yes | Key of the customer whose account receives the booking. |\n| `EventID` | varchar(3) | Yes | ID of the customer account event to book. The event must exist and be flagged as manual. |\n| `Amount` | money | Yes | Amount of the booking. |\n| `EventDate` | datetime | No | Date and time of the booking. Must not be in the future. If `NULL`, the current date and time is used. |\n| `Comment` | varchar(512) | No | Comment stored as reference of the booking. `NULL` is stored as an empty string. |\n| `MatchToInvoiceNr` | varchar(20) | No | Number of an invoice of this customer. The new booking is matched with the newest account entry of this invoice. Overrides `MatchKey`. |\n| `MatchKey` | int | No | Key of the customer account entry (`CustomerAccountKey`) to match the new booking with. Ignored if `MatchToInvoiceNr` is set. |\n| `CurrencyId` | smallint | No | Currency of the booking. If `NULL`, the base currency of the customer's shop is used. |\n\n- Validation errors and errors from the exchange rate lookup roll back the transaction and return an `ERROR` row.\n- Errors during the insert or the match inside the internal booking procedure are caught there and not passed on. In that case the call can still return `OK` although no booking was created. Check the customer account afterwards if this matters.\n- The customer account entry for the new booking is read back via `ManualBookingRef`. It is probably created by logic on the manual booking table that is not visible here.\n- The exchange rate lookup (`pixi.GetExchRateID`) and the match procedure (`Pixi_CA_InsertMatch`) are not attached; their exact behaviour is unknown.\n- `MatchKey` is not checked for belonging to the customer. Prefer `MatchToInvoiceNr`, which is checked.\n- `CustKey` is not validated explicitly. For an unknown customer, `CurrencyId` stays `NULL` if it is not passed.\n- The error text for a future date mentions a \"paid date\"; it refers to `EventDate`.\n- Lookups use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Deletes a customer account event (CustomerAccount entry) together with its invoice, bank matches and account matches, if deletion is allowed.\n\nDeletes one event from the customer account (`CustomerAccount`), identified by its key `CAref`.\n\nSteps:\n1. The common API envelope checks the call frequency limit. If the limit is exceeded, a `ResultCode`/`ResultText` row with code `502` is returned and nothing else happens.\n2. If `CAref` is NULL, a row with `ReturnCode = 'ERROR'` is returned.\n3. Otherwise the internal procedure `Pixi_CA_DeleteEvent` runs with the user name `API` inside a transaction:\n - The function `fPixi_CA_canIdeleteEvent` decides whether the event may be deleted. If not, nothing is changed and `Success = 0` is returned.\n - If the event has a linked invoice (`InvoiceRef`), the invoice is deleted via `Pixi_DeleteInvoice`.\n - Bank matches (`BankMatch`) of the linked bank line (`BanklineRef`) are deleted.\n - `UpdateEmp`/`UpdateDate` are stamped on the event and on all `CustomerAccountMatch` rows where the event is `CAref1` or `CAref2`. Those match rows are then deleted.\n - The `CustomerAccount` row itself is deleted.\n - Afterwards the code tries to clean up a linked `DTAUS` record (only if its state allows deletion) or a linked manual booking (`CustomerAccountManualBookings`).\n4. A row with `Success` (1 = deleted, 0 = not deleted) and `ErrorMessage` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CAref` | int | Yes | Key of the customer account event (`CustomerAccount.CustomerAccountKey`) to delete. Must not be NULL. |\n| `ResultCode` | char(3) | No | Output: result code of the API envelope, `200` on normal execution, `502` if the call frequency limit is exceeded. |\n| `ResultText` | varchar(1024) | No | Output: result text of the API envelope, `OK` or the frequency limit message. |\n\n- All changes run in one transaction; on any error it is rolled back, the error is re-raised with `RAISERROR` (severity 16, returned as `SqlMessage`) and a row with `Success = 0` and the error text is still returned.\n- The rules of `fPixi_CA_canIdeleteEvent` and the behaviour of `Pixi_DeleteInvoice` are not attached; which events are deletable and whether the invoice deletion returns additional result sets cannot be determined from this code.\n- The lookup of the linked `DTAUS` record and manual booking reads `DTAUSref`/`ManualBookingRef` from `CustomerAccount` **after** that row has already been deleted, so in practice these subqueries find nothing. A code comment states that a trigger handles deleting from `DTAUS` and `CustomerAccountManualBookings`; that trigger is not attached.\n- If deletion is not allowed, the internal procedure only issues a `PRINT` ('Event CANNOT Be Deleted'), which is not visible as a row; check `Success = 0`.\n- `ResultCode`/`ResultText` output parameters carry the envelope result (`200`/`OK` on normal execution).\n- Reads use `NOLOCK`, writes use `ROWLOCK`. Each call updates `API_STATISTICS`.\n\nDocumentation: https://pixi-api-docs.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": "Deletes a customer account event (CustomerAccount entry) together with its invoice, bank matches and account matches, if deletion is allowed.\n\nDeletes one event from the customer account (`CustomerAccount`), identified by its key `CAref`.\n\nSteps:\n1. The common API envelope checks the call frequency limit. If the limit is exceeded, a `ResultCode`/`ResultText` row with code `502` is returned and nothing else happens.\n2. If `CAref` is NULL, a row with `ReturnCode = 'ERROR'` is returned.\n3. Otherwise the internal procedure `Pixi_CA_DeleteEvent` runs with the user name `API` inside a transaction:\n - The function `fPixi_CA_canIdeleteEvent` decides whether the event may be deleted. If not, nothing is changed and `Success = 0` is returned.\n - If the event has a linked invoice (`InvoiceRef`), the invoice is deleted via `Pixi_DeleteInvoice`.\n - Bank matches (`BankMatch`) of the linked bank line (`BanklineRef`) are deleted.\n - `UpdateEmp`/`UpdateDate` are stamped on the event and on all `CustomerAccountMatch` rows where the event is `CAref1` or `CAref2`. Those match rows are then deleted.\n - The `CustomerAccount` row itself is deleted.\n - Afterwards the code tries to clean up a linked `DTAUS` record (only if its state allows deletion) or a linked manual booking (`CustomerAccountManualBookings`).\n4. A row with `Success` (1 = deleted, 0 = not deleted) and `ErrorMessage` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CAref` | int | Yes | Key of the customer account event (`CustomerAccount.CustomerAccountKey`) to delete. Must not be NULL. |\n| `ResultCode` | char(3) | No | Output: result code of the API envelope, `200` on normal execution, `502` if the call frequency limit is exceeded. |\n| `ResultText` | varchar(1024) | No | Output: result text of the API envelope, `OK` or the frequency limit message. |\n\n- All changes run in one transaction; on any error it is rolled back, the error is re-raised with `RAISERROR` (severity 16, returned as `SqlMessage`) and a row with `Success = 0` and the error text is still returned.\n- The rules of `fPixi_CA_canIdeleteEvent` and the behaviour of `Pixi_DeleteInvoice` are not attached; which events are deletable and whether the invoice deletion returns additional result sets cannot be determined from this code.\n- The lookup of the linked `DTAUS` record and manual booking reads `DTAUSref`/`ManualBookingRef` from `CustomerAccount` **after** that row has already been deleted, so in practice these subqueries find nothing. A code comment states that a trigger handles deleting from `DTAUS` and `CustomerAccountManualBookings`; that trigger is not attached.\n- If deletion is not allowed, the internal procedure only issues a `PRINT` ('Event CANNOT Be Deleted'), which is not visible as a row; check `Success = 0`.\n- `ResultCode`/`ResultText` output parameters carry the envelope result (`200`/`OK` on normal execution).\n- Reads use `NOLOCK`, writes use `ROWLOCK`. Each call updates `API_STATISTICS`.\n\nDocumentation: https://pixi-api-docs.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": "Deletes all customer account matches of a customer account entry (CAref), including the bank matches derived from them.\n\nRemoves every match in which the given customer account entry takes part.\n\n1. The common API envelope runs first. It checks the call-frequency limit and records the call time. If the limit is exceeded, the call returns a `ResultCode`/`ResultText` row with code `502` and does nothing else.\n2. If `CAref` is `NULL`, a row with `ReturnCode` = `ERROR` is returned and nothing is deleted.\n3. Otherwise the procedure collects all records in `CustomerAccountMatch` where `CAref1` or `CAref2` equals `CAref`. For each match key it then does the following:\n - It sets `UpdateDate` to the current time and `UpdateEmp` to `API` on the match.\n - It deletes all `BankMatch` rows whose `SourceCustomerAccountMatchKey` points to the match.\n - It deletes the match itself.\n\nOn success the call returns no result set. The output parameters `ResultCode`/`ResultText` hold `200`/`OK`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CAref` | int | Yes | Key of the customer account entry. All matches in which it appears as `CAref1` or `CAref2` are deleted. |\n| `ResultCode` | char(3) | No | Result code set by the API envelope: `200` if the call was executed, `502` if the frequency limit was exceeded. |\n| `ResultText` | varchar(1024) | No | Result text of the API envelope: `OK` or the frequency limit message. |\n\n- Each match is deleted in its own transaction inside `Pixi_CA_DeleteMatch`. There is no overall transaction. If deleting one match fails, only that match is rolled back and its error is re-raised with `RAISERROR` (severity 16). Matches deleted before it stay deleted. The loop continues with the remaining matches.\n- The list of matches is read with `NOLOCK`. The deletes use `ROWLOCK`.\n- The update of `UpdateDate`/`UpdateEmp` right before the delete is probably meant for audit or trigger logic. The code does not show this.\n- The match is found if `CAref` appears on either side (`CAref1` or `CAref2`).\n- If no match exists for `CAref`, the call succeeds silently without any result.\n- `ResultCode` stays `200` even when the `CAref cannot be NULL` row is returned. Evaluate the returned row as well.\n- The frequency limit comes from `API_CONTROL.MIN_BREATHING_MSEC` for this function name.\n\nDocumentation: https://pixi-api-docs.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": "Deletes all customer account matches of a customer account entry (CAref), including the bank matches derived from them.\n\nRemoves every match in which the given customer account entry takes part.\n\n1. The common API envelope runs first. It checks the call-frequency limit and records the call time. If the limit is exceeded, the call returns a `ResultCode`/`ResultText` row with code `502` and does nothing else.\n2. If `CAref` is `NULL`, a row with `ReturnCode` = `ERROR` is returned and nothing is deleted.\n3. Otherwise the procedure collects all records in `CustomerAccountMatch` where `CAref1` or `CAref2` equals `CAref`. For each match key it then does the following:\n - It sets `UpdateDate` to the current time and `UpdateEmp` to `API` on the match.\n - It deletes all `BankMatch` rows whose `SourceCustomerAccountMatchKey` points to the match.\n - It deletes the match itself.\n\nOn success the call returns no result set. The output parameters `ResultCode`/`ResultText` hold `200`/`OK`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CAref` | int | Yes | Key of the customer account entry. All matches in which it appears as `CAref1` or `CAref2` are deleted. |\n| `ResultCode` | char(3) | No | Result code set by the API envelope: `200` if the call was executed, `502` if the frequency limit was exceeded. |\n| `ResultText` | varchar(1024) | No | Result text of the API envelope: `OK` or the frequency limit message. |\n\n- Each match is deleted in its own transaction inside `Pixi_CA_DeleteMatch`. There is no overall transaction. If deleting one match fails, only that match is rolled back and its error is re-raised with `RAISERROR` (severity 16). Matches deleted before it stay deleted. The loop continues with the remaining matches.\n- The list of matches is read with `NOLOCK`. The deletes use `ROWLOCK`.\n- The update of `UpdateDate`/`UpdateEmp` right before the delete is probably meant for audit or trigger logic. The code does not show this.\n- The match is found if `CAref` appears on either side (`CAref1` or `CAref2`).\n- If no match exists for `CAref`, the call succeeds silently without any result.\n- `ResultCode` stays `200` even when the `CAref cannot be NULL` row is returned. Evaluate the returned row as well.\n- The frequency limit comes from `API_CONTROL.MIN_BREATHING_MSEC` for this function name.\n\nDocumentation: https://pixi-api-docs.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": "Returns customer account events (bookings), filtered by event type, dates, amounts, invoice, payment method or customer, optionally including deleted events.\n\nReads entries from the customer account (`CustomerAccount`) together with the currency code from `pixi.Currency`.\n\nAll filter parameters are optional and combined with `AND`. A filter is applied only if its parameter is not `NULL`:\n\n- `EventID`: exact match on the event type.\n- `CreateDateFrom`/`CreateDateTo`, `UpdateDateFrom`/`UpdateDateTo`, `EventDateFrom`/`EventDateTo`: inclusive ranges (`>=` / `<=`) on `CreateDate`, `UpdateDate` and `EventDate`.\n- `MinAmount`/`MaxAmount`: inclusive range on `Amount`.\n- `MinMatchedAmount`/`MaxMatchedAmount`: inclusive range on `Matched`.\n- `InvoiceRef`: exact match on the linked invoice.\n- `DoNotRefund`: exact match on the flag.\n- `PaymentCode`: joins `Invoices` via `InvoiceRef` and keeps only events whose invoice has this `Payment` code.\n- `CustRef`: applied only if the value is greater than `0`.\n\nIf `ShowDeleted` = `1`, deleted events are added from the history table `CustomerAccountLog` (rows with `HistRemark` = `DELETE`), using the same filters. These rows have `IsDeleted` = `1`; active rows have `IsDeleted` = `0`.\n\nWithout any filter, all customer account events are returned. The result has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `EventID` | varchar(3) | No | Event type to filter on (exact match). `NULL` = all event types. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for the creation date. |\n| `CreateDateTo` | datetime | No | Upper bound (inclusive) for the creation date. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for the last update date. |\n| `UpdateDateTo` | datetime | No | Upper bound (inclusive) for the last update date. |\n| `EventDateFrom` | datetime | No | Lower bound (inclusive) for the event date. |\n| `EventDateTo` | datetime | No | Upper bound (inclusive) for the event date. |\n| `MinAmount` | money | No | Minimum value (inclusive) of `Amount`. |\n| `MaxAmount` | money | No | Maximum value (inclusive) of `Amount`. |\n| `MinMatchedAmount` | money | No | Minimum value (inclusive) of the matched amount `Matched`. |\n| `MaxMatchedAmount` | money | No | Maximum value (inclusive) of the matched amount `Matched`. |\n| `InvoiceRef` | int | No | Invoice key (`InvoiceKey`) the event is linked to (exact match). |\n| `DoNotRefund` | bit | No | Filter on the `DoNotRefund` flag. `NULL` = no filter. |\n| `PaymentCode` | char(1) | No | Payment method code of the linked invoice (`Invoices.Payment`). Only events with a linked invoice of this payment method are returned. |\n| `CustRef` | int | No | Customer key. Applied only if greater than `0`. |\n| `ShowDeleted` | bit | No | Whether deleted events from `CustomerAccountLog` are included. |\n\n- The query is built as dynamic SQL and executed with `sp_executesql`; all values are passed as parameters.\n- All tables are read with `NOLOCK`, so uncommitted data may appear.\n- Active and deleted rows are combined with `UNION` (not `UNION ALL`), so completely identical rows are returned only once.\n- Although `Invoices` is joined with a `LEFT JOIN`, the `PaymentCode` filter excludes all events without a linked invoice.\n- Events whose `CurrencyId` has no match in `pixi.Currency` are not returned (inner join).\n- Without filters, the call may return a very large number of rows; restricting by customer or date is recommended.\n\nDocumentation: https://pixi-api-docs.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": "Returns customer account events (bookings), filtered by event type, dates, amounts, invoice, payment method or customer, optionally including deleted events.\n\nReads entries from the customer account (`CustomerAccount`) together with the currency code from `pixi.Currency`.\n\nAll filter parameters are optional and combined with `AND`. A filter is applied only if its parameter is not `NULL`:\n\n- `EventID`: exact match on the event type.\n- `CreateDateFrom`/`CreateDateTo`, `UpdateDateFrom`/`UpdateDateTo`, `EventDateFrom`/`EventDateTo`: inclusive ranges (`>=` / `<=`) on `CreateDate`, `UpdateDate` and `EventDate`.\n- `MinAmount`/`MaxAmount`: inclusive range on `Amount`.\n- `MinMatchedAmount`/`MaxMatchedAmount`: inclusive range on `Matched`.\n- `InvoiceRef`: exact match on the linked invoice.\n- `DoNotRefund`: exact match on the flag.\n- `PaymentCode`: joins `Invoices` via `InvoiceRef` and keeps only events whose invoice has this `Payment` code.\n- `CustRef`: applied only if the value is greater than `0`.\n\nIf `ShowDeleted` = `1`, deleted events are added from the history table `CustomerAccountLog` (rows with `HistRemark` = `DELETE`), using the same filters. These rows have `IsDeleted` = `1`; active rows have `IsDeleted` = `0`.\n\nWithout any filter, all customer account events are returned. The result has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `EventID` | varchar(3) | No | Event type to filter on (exact match). `NULL` = all event types. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for the creation date. |\n| `CreateDateTo` | datetime | No | Upper bound (inclusive) for the creation date. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for the last update date. |\n| `UpdateDateTo` | datetime | No | Upper bound (inclusive) for the last update date. |\n| `EventDateFrom` | datetime | No | Lower bound (inclusive) for the event date. |\n| `EventDateTo` | datetime | No | Upper bound (inclusive) for the event date. |\n| `MinAmount` | money | No | Minimum value (inclusive) of `Amount`. |\n| `MaxAmount` | money | No | Maximum value (inclusive) of `Amount`. |\n| `MinMatchedAmount` | money | No | Minimum value (inclusive) of the matched amount `Matched`. |\n| `MaxMatchedAmount` | money | No | Maximum value (inclusive) of the matched amount `Matched`. |\n| `InvoiceRef` | int | No | Invoice key (`InvoiceKey`) the event is linked to (exact match). |\n| `DoNotRefund` | bit | No | Filter on the `DoNotRefund` flag. `NULL` = no filter. |\n| `PaymentCode` | char(1) | No | Payment method code of the linked invoice (`Invoices.Payment`). Only events with a linked invoice of this payment method are returned. |\n| `CustRef` | int | No | Customer key. Applied only if greater than `0`. |\n| `ShowDeleted` | bit | No | Whether deleted events from `CustomerAccountLog` are included. |\n\n- The query is built as dynamic SQL and executed with `sp_executesql`; all values are passed as parameters.\n- All tables are read with `NOLOCK`, so uncommitted data may appear.\n- Active and deleted rows are combined with `UNION` (not `UNION ALL`), so completely identical rows are returned only once.\n- Although `Invoices` is joined with a `LEFT JOIN`, the `PaymentCode` filter excludes all events without a linked invoice.\n- Events whose `CurrencyId` has no match in `pixi.Currency` are not returned (inner join).\n- Without filters, the call may return a very large number of rows; restricting by customer or date is recommended.\n\nDocumentation: https://pixi-api-docs.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": "Returns the customer account entries that are matched against the customer account entry of a given invoice.\n\nLooks up the customer account (CA) entry of an invoice and lists all CA entries that are matched with it, for example payments or credit notes that settle the invoice.\n\n1. At least one of `InvoiceKey` or `InvoiceNr` must be set (a value of `0` or an empty string counts as not set). Otherwise an error is raised.\n2. If `InvoiceKey` is not set, it is resolved from `Invoices` via `InvoiceNr`.\n3. The CA entry whose `InvoiceRef` equals the invoice key is determined.\n4. All match records in `CustomerAccountMatch` where this CA entry is on either side (`CAref1` or `CAref2`) are read, and the **counterpart** CA entries are returned. A match record that references the invoice entry on both sides (self-match) returns the invoice entry itself.\n5. The currency code is taken from `pixi.Currency` via the entry's currency ID.\n\nThe result has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceKey` | int | No | Internal key of the invoice. Takes precedence over `InvoiceNr`. `0` or NULL means not set. |\n| `InvoiceNr` | varchar(20) | No | Invoice number. Used to resolve the invoice key if `InvoiceKey` is not set. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- The column `InvoiceNr` only echoes the input parameter. If the call is made with `InvoiceKey` only, `InvoiceNr` is empty (NULL) in the result.\n- If both parameters are passed, `InvoiceKey` is used and `InvoiceNr` is not checked against it.\n- If no invoice or no CA entry is found for the invoice, an empty result set is returned without an error.\n- If several CA entries reference the same invoice, only one of them (not deterministically chosen) is used.\n- The header comment of the procedure (\"show all CA Events and Statistics for a selected customer\") does not match the actual behaviour.\n\nDocumentation: https://pixi-api-docs.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": "Returns the customer account entries that are matched against the customer account entry of a given invoice.\n\nLooks up the customer account (CA) entry of an invoice and lists all CA entries that are matched with it, for example payments or credit notes that settle the invoice.\n\n1. At least one of `InvoiceKey` or `InvoiceNr` must be set (a value of `0` or an empty string counts as not set). Otherwise an error is raised.\n2. If `InvoiceKey` is not set, it is resolved from `Invoices` via `InvoiceNr`.\n3. The CA entry whose `InvoiceRef` equals the invoice key is determined.\n4. All match records in `CustomerAccountMatch` where this CA entry is on either side (`CAref1` or `CAref2`) are read, and the **counterpart** CA entries are returned. A match record that references the invoice entry on both sides (self-match) returns the invoice entry itself.\n5. The currency code is taken from `pixi.Currency` via the entry's currency ID.\n\nThe result has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceKey` | int | No | Internal key of the invoice. Takes precedence over `InvoiceNr`. `0` or NULL means not set. |\n| `InvoiceNr` | varchar(20) | No | Invoice number. Used to resolve the invoice key if `InvoiceKey` is not set. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- The column `InvoiceNr` only echoes the input parameter. If the call is made with `InvoiceKey` only, `InvoiceNr` is empty (NULL) in the result.\n- If both parameters are passed, `InvoiceKey` is used and `InvoiceNr` is not checked against it.\n- If no invoice or no CA entry is found for the invoice, an empty result set is returned without an error.\n- If several CA entries reference the same invoice, only one of them (not deterministically chosen) is used.\n- The header comment of the procedure (\"show all CA Events and Statistics for a selected customer\") does not match the actual behaviour.\n\nDocumentation: https://pixi-api-docs.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": "Creates a match between two customer account entries with a given match amount.\n\nLinks two customer account entries, for example a payment and an invoice, with a match amount.\n\n1. The call first runs the common API envelope. This checks the call frequency limit for `pipiCAInsertMatch` and records the time of the call. If the limit is exceeded, a row with `ResultCode` `502` and `ResultText` is returned and nothing else happens.\n2. If `CAref1`, `CAref2` or `MatchAmount` is `NULL`, a status row with `ReturnCode` = `ERROR` and `ErrorMessage` is returned. No data is written.\n3. Otherwise one record is inserted into `CustomerAccountMatch`:\n - `CAref1` and `CAref2` are stored as passed.\n - `AbsoluteMatchAmount` is set to `MatchAmount` rounded to 2 decimal places.\n - Creation and update user are set to `API`, with the current date and time.\n\nOn success the call returns no result set.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CAref1` | int | Yes | Key of the first customer account entry to be matched. |\n| `CAref2` | int | Yes | Key of the second customer account entry to be matched. |\n| `MatchAmount` | money | Yes | Amount to be matched. It is rounded to 2 decimal places and stored as `AbsoluteMatchAmount`. |\n| `ResultCode` | char(3) | No | Output: result code of the API envelope, `200` if the call was allowed or `502` if the frequency limit was exceeded. |\n| `ResultText` | varchar(1024) | No | Output: text belonging to `ResultCode`, either `OK` or the frequency limit message. |\n\n- The insert runs in its own transaction, or in a savepoint if a transaction is already open.\n- SQL errors during the insert are caught, rolled back and logged via `log.InsertError`, which is not attached. Examples are constraint violations for non-existing `CAref` values. The caller receives **no error row** in this case, so success cannot be told apart from a failed insert by the response alone.\n- The code does not check whether `CAref1` and `CAref2` exist, whether they belong to the same customer, or whether the amount matches the open balances. Any such checks depend on table constraints that are not visible here.\n- The ID of the new match record is only used as the internal procedure return value and is not returned to the SOAP caller.\n- `CAref1`, `CAref2` and `MatchAmount` have no default. Leaving them out of the request causes a SQL error for the missing parameter. The `ERROR` row only appears if they are passed explicitly as `NULL`.\n- The error text contains a typo: it names `CAref1` twice instead of `CAref1` and `CAref2`.\n- Frequency limits are configured in `API_CONTROL` (`MIN_BREATHING_MSEC`).\n\nDocumentation: https://pixi-api-docs.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": "Creates a match between two customer account entries with a given match amount.\n\nLinks two customer account entries, for example a payment and an invoice, with a match amount.\n\n1. The call first runs the common API envelope. This checks the call frequency limit for `pipiCAInsertMatch` and records the time of the call. If the limit is exceeded, a row with `ResultCode` `502` and `ResultText` is returned and nothing else happens.\n2. If `CAref1`, `CAref2` or `MatchAmount` is `NULL`, a status row with `ReturnCode` = `ERROR` and `ErrorMessage` is returned. No data is written.\n3. Otherwise one record is inserted into `CustomerAccountMatch`:\n - `CAref1` and `CAref2` are stored as passed.\n - `AbsoluteMatchAmount` is set to `MatchAmount` rounded to 2 decimal places.\n - Creation and update user are set to `API`, with the current date and time.\n\nOn success the call returns no result set.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CAref1` | int | Yes | Key of the first customer account entry to be matched. |\n| `CAref2` | int | Yes | Key of the second customer account entry to be matched. |\n| `MatchAmount` | money | Yes | Amount to be matched. It is rounded to 2 decimal places and stored as `AbsoluteMatchAmount`. |\n| `ResultCode` | char(3) | No | Output: result code of the API envelope, `200` if the call was allowed or `502` if the frequency limit was exceeded. |\n| `ResultText` | varchar(1024) | No | Output: text belonging to `ResultCode`, either `OK` or the frequency limit message. |\n\n- The insert runs in its own transaction, or in a savepoint if a transaction is already open.\n- SQL errors during the insert are caught, rolled back and logged via `log.InsertError`, which is not attached. Examples are constraint violations for non-existing `CAref` values. The caller receives **no error row** in this case, so success cannot be told apart from a failed insert by the response alone.\n- The code does not check whether `CAref1` and `CAref2` exist, whether they belong to the same customer, or whether the amount matches the open balances. Any such checks depend on table constraints that are not visible here.\n- The ID of the new match record is only used as the internal procedure return value and is not returned to the SOAP caller.\n- `CAref1`, `CAref2` and `MatchAmount` have no default. Leaving them out of the request causes a SQL error for the missing parameter. The `ERROR` row only appears if they are passed explicitly as `NULL`.\n- The error text contains a typo: it names `CAref1` twice instead of `CAref1` and `CAref2`.\n- Frequency limits are configured in `API_CONTROL` (`MIN_BREATHING_MSEC`).\n\nDocumentation: https://pixi-api-docs.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": "Creates a new bank header together with a single bank line (bank transaction) and returns the keys of both new records.\n\nImports a single bank transaction into Pixi, for example for later matching against Aufträge or Rechnungen.\n\nSteps:\n\n1. Determines the database (home) currency via `pixi.GetDatabaseCurrency()`. This is the currency whose code matches the setting `HomeCurrency` and that is marked as parent currency.\n2. If `SourceType` is `NULL` or empty, it is set to `API`.\n3. Inserts a new record into `BankHeader` with `SourceType`, the current server time as `BankImportDate` and `BankFileName`.\n4. Inserts one record into `BankLines` that references the new header:\n - `BankDate` = `BankDate`.\n - `BookDate` = month and day of `BankDate` as a four-character string `MMDD` (e.g. `0315`).\n - `BusinessCode` is always `051`.\n - `BankCode` = `BLZ`, `AccountNr`, `CustomerName`, `BankText01`–`BankText03`, `ParsedBIC` = `BIC`, `ParsedIBAN` = `IBAN`, `AccountingBankAccount`.\n - `CurrencyId` = `CurrencyId`, or the database currency if `CurrencyId` is not given.\n5. Returns one row with the new `BankHeaderKey` and `BanklineKey`.\n\nEvery call creates its own bank header; several lines cannot be added to an existing header with this call.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BankFileName` | varchar(1024) | Yes | Name of the bank file or source the transaction comes from; stored in `BankHeader.BankFileName`. |\n| `BankDate` | datetime | Yes | Date of the bank transaction. Also used to derive `BookDate` (format `MMDD`). |\n| `BankAmount` | money | Yes | Amount of the transaction. |\n| `BankText01` | varchar(1024) | Yes | First line of the payment reference / booking text. |\n| `BankText02` | varchar(1024) | Yes | Second line of the payment reference / booking text. |\n| `BankText03` | varchar(1024) | Yes | Third line of the payment reference / booking text. |\n| `BLZ` | char(11) | Yes | Bank code of the counterparty; stored in `BankLines.BankCode`. |\n| `AccountNr` | char(24) | Yes | Account number of the counterparty. |\n| `CustomerName` | varchar(60) | Yes | Name of the account holder / payer. |\n| `BIC` | varchar(50) | No | BIC of the counterparty; stored in `BankLines.ParsedBIC`. |\n| `IBAN` | varchar(150) | No | IBAN of the counterparty; stored in `BankLines.ParsedIBAN`. |\n| `AccountingBankAccount` | varchar(250) | No | Own bank account (accounting account) the transaction belongs to. |\n| `SourceType` | varchar(3) | No | Source type stored in `BankHeader.SourceType`. `NULL` or an empty string is replaced by `API`. |\n| `CurrencyId` | smallint | No | Id of the currency of the amount. If `NULL`, the database (home) currency is used. |\n\n- No explicit transaction is used. If the insert into `BankLines` fails, the already inserted `BankHeader` record remains without lines.\n- No validation is performed: duplicates are not detected, IBAN/BIC are not checked, and the amount sign is taken as passed.\n- `BankFileName`, `BankDate`, `BankAmount`, `BankText01`–`BankText03`, `BLZ`, `AccountNr` and `CustomerName` have no default value and must be present in the request (they may be empty or `NULL` as far as the table allows).\n- If `BankDate` is `NULL`, `BookDate` is also `NULL`.\n- If no currency matching the `HomeCurrency` setting is found and `CurrencyId` is not passed, `CurrencyId` is stored as `NULL`.\n- `BLZ` and `AccountNr` are `char` parameters and are padded with spaces; `SourceType` is limited to 3 characters.\n- `BanklineKey` comes from `SCOPE_IDENTITY()` and is therefore returned as a decimal value.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new bank header together with a single bank line (bank transaction) and returns the keys of both new records.\n\nImports a single bank transaction into Pixi, for example for later matching against Aufträge or Rechnungen.\n\nSteps:\n\n1. Determines the database (home) currency via `pixi.GetDatabaseCurrency()`. This is the currency whose code matches the setting `HomeCurrency` and that is marked as parent currency.\n2. If `SourceType` is `NULL` or empty, it is set to `API`.\n3. Inserts a new record into `BankHeader` with `SourceType`, the current server time as `BankImportDate` and `BankFileName`.\n4. Inserts one record into `BankLines` that references the new header:\n - `BankDate` = `BankDate`.\n - `BookDate` = month and day of `BankDate` as a four-character string `MMDD` (e.g. `0315`).\n - `BusinessCode` is always `051`.\n - `BankCode` = `BLZ`, `AccountNr`, `CustomerName`, `BankText01`–`BankText03`, `ParsedBIC` = `BIC`, `ParsedIBAN` = `IBAN`, `AccountingBankAccount`.\n - `CurrencyId` = `CurrencyId`, or the database currency if `CurrencyId` is not given.\n5. Returns one row with the new `BankHeaderKey` and `BanklineKey`.\n\nEvery call creates its own bank header; several lines cannot be added to an existing header with this call.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BankFileName` | varchar(1024) | Yes | Name of the bank file or source the transaction comes from; stored in `BankHeader.BankFileName`. |\n| `BankDate` | datetime | Yes | Date of the bank transaction. Also used to derive `BookDate` (format `MMDD`). |\n| `BankAmount` | money | Yes | Amount of the transaction. |\n| `BankText01` | varchar(1024) | Yes | First line of the payment reference / booking text. |\n| `BankText02` | varchar(1024) | Yes | Second line of the payment reference / booking text. |\n| `BankText03` | varchar(1024) | Yes | Third line of the payment reference / booking text. |\n| `BLZ` | char(11) | Yes | Bank code of the counterparty; stored in `BankLines.BankCode`. |\n| `AccountNr` | char(24) | Yes | Account number of the counterparty. |\n| `CustomerName` | varchar(60) | Yes | Name of the account holder / payer. |\n| `BIC` | varchar(50) | No | BIC of the counterparty; stored in `BankLines.ParsedBIC`. |\n| `IBAN` | varchar(150) | No | IBAN of the counterparty; stored in `BankLines.ParsedIBAN`. |\n| `AccountingBankAccount` | varchar(250) | No | Own bank account (accounting account) the transaction belongs to. |\n| `SourceType` | varchar(3) | No | Source type stored in `BankHeader.SourceType`. `NULL` or an empty string is replaced by `API`. |\n| `CurrencyId` | smallint | No | Id of the currency of the amount. If `NULL`, the database (home) currency is used. |\n\n- No explicit transaction is used. If the insert into `BankLines` fails, the already inserted `BankHeader` record remains without lines.\n- No validation is performed: duplicates are not detected, IBAN/BIC are not checked, and the amount sign is taken as passed.\n- `BankFileName`, `BankDate`, `BankAmount`, `BankText01`–`BankText03`, `BLZ`, `AccountNr` and `CustomerName` have no default value and must be present in the request (they may be empty or `NULL` as far as the table allows).\n- If `BankDate` is `NULL`, `BookDate` is also `NULL`.\n- If no currency matching the `HomeCurrency` setting is found and `CurrencyId` is not passed, `CurrencyId` is stored as `NULL`.\n- `BLZ` and `AccountNr` are `char` parameters and are padded with spaces; `SourceType` is limited to 3 characters.\n- `BanklineKey` comes from `SCOPE_IDENTITY()` and is therefore returned as a decimal value.\n\nDocumentation: https://pixi-api-docs.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": "Matches a bank line to an order by creating a manual bank match and can optionally release the order from hold.\n\nCreates a manual entry in `BankMatch` that links a bank line (`BanklineKey`) to an order.\n\n1. Either `OrderNr` or `OrderNrExternal` must be passed, otherwise an error row is returned.\n2. The order is looked up in `OrderHeader` with `OrderNr = @OrderNr OR OrderNrExternal = @OrderNrExternal`. The open amount is the order total, rounded to the number of decimal places from the setting `NumberOfDecimalPlacesForPrices` (default 2), minus `PaidByCustomer`.\n3. The match difference is calculated as the absolute value of the remaining bank amount (`BankAmount - UsedAmount`) minus the open amount. If `MaxMatchDelta` is set and this difference is larger, nothing is written and an error row is returned.\n4. If a match between this order and this bank line already exists, an error row is returned.\n5. Otherwise a row is inserted into `BankMatch` with `ManualMatch = 1`, the current date and `AmountMatched` = the smaller of the remaining bank amount and the open amount.\n6. If `AutoReleaseOrder = 1`, the difference between `OrderTotal` and `PaidByCustomer` of the order is checked again. If it is less than or equal to `MaxMatchDelta` (or 0 if not set), the order lines with status `HAL` are set to `ANG` (order released from hold). Otherwise the newly created match is deleted again.\n\nThe call always returns exactly one row with `Status`, `Message` and the current values of the bank line.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BanklineKey` | int | Yes | Key of the bank line (`BankLines.BankLineKey`) to be matched. |\n| `OrderNr` | int | No | Pixi order number. Either this or `OrderNrExternal` must be supplied. |\n| `OrderNrExternal` | varchar(50) | No | External order number (e.g. shop order number). Used when `OrderNr` is not supplied. |\n| `MaxMatchDelta` | money | No | Maximum allowed difference between the remaining bank amount and the open order amount. If NULL, no check is done before matching; for the auto-release check NULL counts as 0. |\n| `AutoReleaseOrder` | bit | No | If 1, the order is released from hold after matching when the remaining difference is within `MaxMatchDelta`; otherwise the new match is removed again. |\n\n- **Status does not reveal the auto-release outcome:** after the insert, `Status` is always `OK` and `Message` is always empty, even when the match was deleted again because the order could not be released. Check the order or `BankMatch` afterwards if this matters.\n- The auto-release check relies on `PaidByCustomer` having been updated after the insert. The code itself does not update it; this presumably happens via logic outside this procedure (e.g. a trigger), which is not visible here. If `PaidByCustomer` is NULL, the order is never released and the match is removed.\n- If both `OrderNr` and `OrderNrExternal` are passed, the `OR` filter may match several orders; then one of them is taken arbitrarily.\n- The existence of the bank line is not checked. For a non-existing `BanklineKey` no match is inserted, but `Status` is still `OK`. In this case the match key is taken from `IDENT_CURRENT('BankMatch')`, which is not session-scoped; together with `AutoReleaseOrder = 1` and a failed release check this can delete an unrelated `BankMatch` row. The same risk exists under concurrent inserts.\n- If `UsedAmount` is NULL, `AmountMatched` becomes NULL (no `ISNULL` in the insert), while the delta check treats it as 0.\n- Reads use `NOLOCK`. The work runs in one transaction that is committed in all branches after the order lookup.\n- Errors in the release step (`GOS_ReleaseOnHold`) are logged to `LogTable` and re-raised; they reach the caller as `SqlMessage`.\n- Released order lines get `UpdateEmp` = `BanklineMatch - API (payments)`, truncated to 20 characters.\n\nDocumentation: https://pixi-api-docs.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": "Matches a bank line to an order by creating a manual bank match and can optionally release the order from hold.\n\nCreates a manual entry in `BankMatch` that links a bank line (`BanklineKey`) to an order.\n\n1. Either `OrderNr` or `OrderNrExternal` must be passed, otherwise an error row is returned.\n2. The order is looked up in `OrderHeader` with `OrderNr = @OrderNr OR OrderNrExternal = @OrderNrExternal`. The open amount is the order total, rounded to the number of decimal places from the setting `NumberOfDecimalPlacesForPrices` (default 2), minus `PaidByCustomer`.\n3. The match difference is calculated as the absolute value of the remaining bank amount (`BankAmount - UsedAmount`) minus the open amount. If `MaxMatchDelta` is set and this difference is larger, nothing is written and an error row is returned.\n4. If a match between this order and this bank line already exists, an error row is returned.\n5. Otherwise a row is inserted into `BankMatch` with `ManualMatch = 1`, the current date and `AmountMatched` = the smaller of the remaining bank amount and the open amount.\n6. If `AutoReleaseOrder = 1`, the difference between `OrderTotal` and `PaidByCustomer` of the order is checked again. If it is less than or equal to `MaxMatchDelta` (or 0 if not set), the order lines with status `HAL` are set to `ANG` (order released from hold). Otherwise the newly created match is deleted again.\n\nThe call always returns exactly one row with `Status`, `Message` and the current values of the bank line.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BanklineKey` | int | Yes | Key of the bank line (`BankLines.BankLineKey`) to be matched. |\n| `OrderNr` | int | No | Pixi order number. Either this or `OrderNrExternal` must be supplied. |\n| `OrderNrExternal` | varchar(50) | No | External order number (e.g. shop order number). Used when `OrderNr` is not supplied. |\n| `MaxMatchDelta` | money | No | Maximum allowed difference between the remaining bank amount and the open order amount. If NULL, no check is done before matching; for the auto-release check NULL counts as 0. |\n| `AutoReleaseOrder` | bit | No | If 1, the order is released from hold after matching when the remaining difference is within `MaxMatchDelta`; otherwise the new match is removed again. |\n\n- **Status does not reveal the auto-release outcome:** after the insert, `Status` is always `OK` and `Message` is always empty, even when the match was deleted again because the order could not be released. Check the order or `BankMatch` afterwards if this matters.\n- The auto-release check relies on `PaidByCustomer` having been updated after the insert. The code itself does not update it; this presumably happens via logic outside this procedure (e.g. a trigger), which is not visible here. If `PaidByCustomer` is NULL, the order is never released and the match is removed.\n- If both `OrderNr` and `OrderNrExternal` are passed, the `OR` filter may match several orders; then one of them is taken arbitrarily.\n- The existence of the bank line is not checked. For a non-existing `BanklineKey` no match is inserted, but `Status` is still `OK`. In this case the match key is taken from `IDENT_CURRENT('BankMatch')`, which is not session-scoped; together with `AutoReleaseOrder = 1` and a failed release check this can delete an unrelated `BankMatch` row. The same risk exists under concurrent inserts.\n- If `UsedAmount` is NULL, `AmountMatched` becomes NULL (no `ISNULL` in the insert), while the delta check treats it as 0.\n- Reads use `NOLOCK`. The work runs in one transaction that is committed in all branches after the order lookup.\n- Errors in the release step (`GOS_ReleaseOnHold`) are logged to `LogTable` and re-raised; they reach the caller as `SqlMessage`.\n- Released order lines get `UpdateEmp` = `BanklineMatch - API (payments)`, truncated to 20 characters.\n\nDocumentation: https://pixi-api-docs.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": "Creates manual customer account bookings for open, reminded invoices handed over to debt collection (Inkasso); deprecated outside specific databases.\n\nThe call checks the name of the current database.\n\n- **Database `pixi_GCH` or `pixi_GCH_test`:** the internal procedure `Pixi_CA_CreateinkassoManualBookings` is executed with the three parameters. It creates manual booking events on the customer account so that the affected invoices are no longer open. No result set is returned in this case.\n- **Any other database:** nothing is booked. The call returns a single row with `Status` = `Info` and a message saying that the call is no longer supported.\n\nThe internal procedure works as follows:\n\n1. It reads the booking event ID from the setting `CA_Inkasso_ManualBookingID`. If the setting is empty or `0`, `INU` is used.\n2. It only continues if a customer account event with this ID exists in `CustomerAccountEvents` and has `OriginalAmountMultiply = -1` (negative event).\n3. It selects invoices with `Total` > 0 and an open amount (`Total` - `PayedSum`) > 0. The customer must be matched according to `fPixi_CA_IsMatched`. The customer must also have at least one open invoice that meets all of these conditions:\n - reminder level between `MinimumReminderLevel` and `MaxReminderLevel`;\n - invoice date older than `MinimumAgeInDays` days.\n4. For each selected invoice it writes a log entry to `LogTable`. It then calls `Pixi_CA_InsertManualBookingEvent` with the negated open amount, the text `Manual booking`, the user `pixi* Automatic`, the customer account key of the invoice and its currency.\n\nAll open invoices of a qualifying customer are booked, not only the invoices that meet the age and reminder criteria.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `MinimumAgeInDays` | int | Yes | Minimum age of a reminded invoice in days (invoice date older than today minus this value) for its customer to qualify. |\n| `MinimumReminderLevel` | smallint | Yes | Lowest reminder level (inclusive) of the qualifying invoice. NULL reminder levels count as 0. |\n| `MaxReminderLevel` | int | Yes | Highest reminder level (inclusive) of the qualifying invoice. |\n\n- **Deprecated:** outside the databases `pixi_GCH` and `pixi_GCH_test` the call does nothing except return the `Info` row. The message text contains the typo `suported`.\n- **No feedback:** in the supported databases no result set is returned. Success can only be checked via `LogTable` or the customer account.\n- **Not documented here:** the definitions of `Pixi_CA_InsertManualBookingEvent`, `fPixi_CA_IsMatched` and `fPixi_GetSetting` are not attached. Their exact behaviour is therefore not documented.\n- **Dynamic SQL, no transaction:** bookings and log entries are built as dynamic SQL and executed without an explicit transaction. The log entries are written before the bookings, so a failing booking can leave log entries without matching bookings.\n- **Dirty reads:** reads use `NOLOCK`.\n- **No duplicate protection:** repeated calls can create further bookings while invoices still appear open.\n\nDocumentation: https://pixi-api-docs.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": "Creates manual customer account bookings for open, reminded invoices handed over to debt collection (Inkasso); deprecated outside specific databases.\n\nThe call checks the name of the current database.\n\n- **Database `pixi_GCH` or `pixi_GCH_test`:** the internal procedure `Pixi_CA_CreateinkassoManualBookings` is executed with the three parameters. It creates manual booking events on the customer account so that the affected invoices are no longer open. No result set is returned in this case.\n- **Any other database:** nothing is booked. The call returns a single row with `Status` = `Info` and a message saying that the call is no longer supported.\n\nThe internal procedure works as follows:\n\n1. It reads the booking event ID from the setting `CA_Inkasso_ManualBookingID`. If the setting is empty or `0`, `INU` is used.\n2. It only continues if a customer account event with this ID exists in `CustomerAccountEvents` and has `OriginalAmountMultiply = -1` (negative event).\n3. It selects invoices with `Total` > 0 and an open amount (`Total` - `PayedSum`) > 0. The customer must be matched according to `fPixi_CA_IsMatched`. The customer must also have at least one open invoice that meets all of these conditions:\n - reminder level between `MinimumReminderLevel` and `MaxReminderLevel`;\n - invoice date older than `MinimumAgeInDays` days.\n4. For each selected invoice it writes a log entry to `LogTable`. It then calls `Pixi_CA_InsertManualBookingEvent` with the negated open amount, the text `Manual booking`, the user `pixi* Automatic`, the customer account key of the invoice and its currency.\n\nAll open invoices of a qualifying customer are booked, not only the invoices that meet the age and reminder criteria.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `MinimumAgeInDays` | int | Yes | Minimum age of a reminded invoice in days (invoice date older than today minus this value) for its customer to qualify. |\n| `MinimumReminderLevel` | smallint | Yes | Lowest reminder level (inclusive) of the qualifying invoice. NULL reminder levels count as 0. |\n| `MaxReminderLevel` | int | Yes | Highest reminder level (inclusive) of the qualifying invoice. |\n\n- **Deprecated:** outside the databases `pixi_GCH` and `pixi_GCH_test` the call does nothing except return the `Info` row. The message text contains the typo `suported`.\n- **No feedback:** in the supported databases no result set is returned. Success can only be checked via `LogTable` or the customer account.\n- **Not documented here:** the definitions of `Pixi_CA_InsertManualBookingEvent`, `fPixi_CA_IsMatched` and `fPixi_GetSetting` are not attached. Their exact behaviour is therefore not documented.\n- **Dynamic SQL, no transaction:** bookings and log entries are built as dynamic SQL and executed without an explicit transaction. The log entries are written before the bookings, so a failing booking can leave log entries without matching bookings.\n- **Dirty reads:** reads use `NOLOCK`.\n- **No duplicate protection:** repeated calls can create further bookings while invoices still appear open.\n\nDocumentation: https://pixi-api-docs.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": "Returns POS (point of sale) cash payments and, optionally, cash drawer session events in a period as booking lines for a DATEV export.\n\nThe call passes all parameters unchanged to the internal procedure `Pixi_DatevExportPOSWires` and returns its result. Each row is one booking line for a DATEV export.\n\n**Date range**\n\n- `DateFrom` is moved to the start of its day.\n- `DateTo` is moved to the end of its day.\n- Records are included if their date lies between `DateFrom` and one second before the adjusted `DateTo`.\n\n**Part 1 – POS payments** (`POSPayment`, joined to the POS receipt header and the customer address)\n\n- If the setting `ConsiderAllPosEvents` is `0` (default), only payments with payment code `B` are exported. If it is `1`, payments with any payment code are exported.\n- `ShopId` filters on the shop of the customer address (`AddrShopID`).\n- `Country` filters on the `Country` column.\n- `AmoutFrom` / `AmoutTo` filter on the absolute amount; both limits are inclusive.\n- `Sign` is the minus sign for payment code `-` (change) or negative amounts, otherwise the plus sign.\n- `CustomerNr` is the first 10 characters of the external customer number. If that is empty, the setting `DefaultCustomerAccountNumber` is used, otherwise `0`.\n- `InvoiceNr` is the document number of the POS receipt.\n- `WireText` is `Change` for payment code `-`, otherwise empty.\n\n**Part 2 – Session events** (`POSSession_event`)\n\n- Only included if `ConsiderAllPosEvents` is `1`.\n- Covers the event types `D` (Drawer Open), `E` (Session Stop) and `S` (Session Start) within the date range.\n- `ShopId`, `Country` and the amount filters do **not** apply to this part.\n- `Amount` is the absolute value of incoming minus outgoing amount. `Sign` is plus if that difference is ≥ 0, otherwise minus.\n- `CustomerNr` is the default customer account number. `InvoiceNr` is empty.\n- `WireText` is the event name, followed by ` - ` and the event comment if there is one.\n\n**Signs**\n\nIf the setting `BookExportDatevPro` is set (not `0`), the signs are `s` (debit) and `h` (credit). Otherwise they are `+` and `-`.\n\n**Common columns**\n\n- `Currency` is always `EUR`.\n- `BankAccountNr` is the setting `AccountNumberPOSPayment`, or `0` if it is not set.\n- The columns `Empty1`–`Empty6` are empty placeholders for the DATEV file layout.\n\n**Sort order**: `BankAccountNr`, then `BankDate`, then `Sign` descending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Yes | Start of the period. It is moved to the start of the day. |\n| `DateTo` | datetime | Yes | End of the period. It is moved to the end of the day, so the given day is included. |\n| `ShopId` | varchar(3) | No | Optional shop filter on the shop of the customer address (`AddrShopID`). Applies only to POS payments, not to session events. |\n| `Country` | varchar(3) | No | Optional filter on the `Country` column. Applies only to POS payments. |\n| `AmoutFrom` | money | No | Optional minimum absolute payment amount (inclusive). Applies only to POS payments. Note the spelling. |\n| `AmoutTo` | money | No | Optional maximum absolute payment amount (inclusive). Applies only to POS payments. Note the spelling. |\n\n- The parameter names `AmoutFrom` and `AmoutTo` are misspelled in the code (missing `n`). They must be sent exactly like this.\n- The behaviour depends on the settings `BookExportDatevPro`, `AccountNumberPOSPayment`, `DefaultCustomerAccountNumber` and `ConsiderAllPosEvents`. They are read at runtime via `dbo.SettingGet`.\n- The exact day boundaries come from `fPixi_GetDateStartOfDay` / `fPixi_GetDateEndOfDay`, which are not attached. The code comment says one second is subtracted from the end so that lines at 00:00:00 are not exported twice.\n- Both parts are combined with `UNION`, not `UNION ALL`. Completely identical rows therefore appear only once. This can happen, for example, with two equal payments on the same receipt at the same time.\n- All tables are read with `NOLOCK`, so uncommitted data may be included.\n- The `ShopId` filter only matches payments that have a linked customer address.\n- The currency is always reported as `EUR`, regardless of the actual payment currency.\n- Read-only; no data is changed.\n\nDocumentation: https://pixi-api-docs.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": "Returns POS (point of sale) cash payments and, optionally, cash drawer session events in a period as booking lines for a DATEV export.\n\nThe call passes all parameters unchanged to the internal procedure `Pixi_DatevExportPOSWires` and returns its result. Each row is one booking line for a DATEV export.\n\n**Date range**\n\n- `DateFrom` is moved to the start of its day.\n- `DateTo` is moved to the end of its day.\n- Records are included if their date lies between `DateFrom` and one second before the adjusted `DateTo`.\n\n**Part 1 – POS payments** (`POSPayment`, joined to the POS receipt header and the customer address)\n\n- If the setting `ConsiderAllPosEvents` is `0` (default), only payments with payment code `B` are exported. If it is `1`, payments with any payment code are exported.\n- `ShopId` filters on the shop of the customer address (`AddrShopID`).\n- `Country` filters on the `Country` column.\n- `AmoutFrom` / `AmoutTo` filter on the absolute amount; both limits are inclusive.\n- `Sign` is the minus sign for payment code `-` (change) or negative amounts, otherwise the plus sign.\n- `CustomerNr` is the first 10 characters of the external customer number. If that is empty, the setting `DefaultCustomerAccountNumber` is used, otherwise `0`.\n- `InvoiceNr` is the document number of the POS receipt.\n- `WireText` is `Change` for payment code `-`, otherwise empty.\n\n**Part 2 – Session events** (`POSSession_event`)\n\n- Only included if `ConsiderAllPosEvents` is `1`.\n- Covers the event types `D` (Drawer Open), `E` (Session Stop) and `S` (Session Start) within the date range.\n- `ShopId`, `Country` and the amount filters do **not** apply to this part.\n- `Amount` is the absolute value of incoming minus outgoing amount. `Sign` is plus if that difference is ≥ 0, otherwise minus.\n- `CustomerNr` is the default customer account number. `InvoiceNr` is empty.\n- `WireText` is the event name, followed by ` - ` and the event comment if there is one.\n\n**Signs**\n\nIf the setting `BookExportDatevPro` is set (not `0`), the signs are `s` (debit) and `h` (credit). Otherwise they are `+` and `-`.\n\n**Common columns**\n\n- `Currency` is always `EUR`.\n- `BankAccountNr` is the setting `AccountNumberPOSPayment`, or `0` if it is not set.\n- The columns `Empty1`–`Empty6` are empty placeholders for the DATEV file layout.\n\n**Sort order**: `BankAccountNr`, then `BankDate`, then `Sign` descending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Yes | Start of the period. It is moved to the start of the day. |\n| `DateTo` | datetime | Yes | End of the period. It is moved to the end of the day, so the given day is included. |\n| `ShopId` | varchar(3) | No | Optional shop filter on the shop of the customer address (`AddrShopID`). Applies only to POS payments, not to session events. |\n| `Country` | varchar(3) | No | Optional filter on the `Country` column. Applies only to POS payments. |\n| `AmoutFrom` | money | No | Optional minimum absolute payment amount (inclusive). Applies only to POS payments. Note the spelling. |\n| `AmoutTo` | money | No | Optional maximum absolute payment amount (inclusive). Applies only to POS payments. Note the spelling. |\n\n- The parameter names `AmoutFrom` and `AmoutTo` are misspelled in the code (missing `n`). They must be sent exactly like this.\n- The behaviour depends on the settings `BookExportDatevPro`, `AccountNumberPOSPayment`, `DefaultCustomerAccountNumber` and `ConsiderAllPosEvents`. They are read at runtime via `dbo.SettingGet`.\n- The exact day boundaries come from `fPixi_GetDateStartOfDay` / `fPixi_GetDateEndOfDay`, which are not attached. The code comment says one second is subtracted from the end so that lines at 00:00:00 are not exported twice.\n- Both parts are combined with `UNION`, not `UNION ALL`. Completely identical rows therefore appear only once. This can happen, for example, with two equal payments on the same receipt at the same time.\n- All tables are read with `NOLOCK`, so uncommitted data may be included.\n- The `ShopId` filter only matches payments that have a linked customer address.\n- The currency is always reported as `EUR`, regardless of the actual payment currency.\n- Read-only; no data is changed.\n\nDocumentation: https://pixi-api-docs.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": "Returns the list of all payment types (code and description), sorted by description.\n\nReturns every record of the payment type master data (`Payments`).\n\n- No parameters, no filters: all payment types are returned.\n- Each row contains the payment type code (`PaymentType`) and its description text (`PaymentTypeDesc`).\n- Rows are sorted alphabetically by the description text.\n\nThe table is read with `NOLOCK`, so uncommitted changes may be visible. The call is part of the `Emill` group of calls and is typically used to map payment type codes to readable names.\n\nDocumentation: https://pixi-api-docs.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": "Returns the list of all payment types (code and description), sorted by description.\n\nReturns every record of the payment type master data (`Payments`).\n\n- No parameters, no filters: all payment types are returned.\n- Each row contains the payment type code (`PaymentType`) and its description text (`PaymentTypeDesc`).\n- Rows are sorted alphabetically by the description text.\n\nThe table is read with `NOLOCK`, so uncommitted changes may be visible. The call is part of the `Emill` group of calls and is typically used to map payment type codes to readable names.\n\nDocumentation: https://pixi-api-docs.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": "Returns the credit card data and the credit card processor authorization ID stored for an order.\n\nLooks up the order with the given `OrderNr` in `OrderHeader` and joins its address record (`OrderHeader.AddrRef` = `Addresses.AddrKey`). The credit card fields are read from that address record.\n\nThe returned row contains:\n- the card type text, resolved from `Creditcards.CardText` via `Addresses.ACardType`\n- card holder, card number, expiry date and CVC\n- the authorization ID of the credit card processor (`OrderHeader.ccpPayID`)\n- the flag `CCPIDUsedBefore`. It is `1` if another order of the same customer (`CustRef`) with a lower order number already has the same `ccpPayID`, otherwise `0`.\n\nIf no order with this number exists, or the order has no matching address record, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Order number (`OrderHeader.OrderNr`) of the order whose credit card data is returned. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- The call returns sensitive payment data (full card number and CVC) exactly as stored. Access to this call should be restricted.\n- If `ccpPayID` is `NULL`, the comparison with earlier orders never matches and `CCPIDUsedBefore` is `0`.\n- The card type is resolved with a scalar subquery. If `Creditcards` contains more than one row for the same `CardType`, SQL Server raises an error (subquery returned more than one value). If there is no matching row, `CreditCardType` is `NULL`.\n- The column data types depend on the table definitions, which are not part of the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns the credit card data and the credit card processor authorization ID stored for an order.\n\nLooks up the order with the given `OrderNr` in `OrderHeader` and joins its address record (`OrderHeader.AddrRef` = `Addresses.AddrKey`). The credit card fields are read from that address record.\n\nThe returned row contains:\n- the card type text, resolved from `Creditcards.CardText` via `Addresses.ACardType`\n- card holder, card number, expiry date and CVC\n- the authorization ID of the credit card processor (`OrderHeader.ccpPayID`)\n- the flag `CCPIDUsedBefore`. It is `1` if another order of the same customer (`CustRef`) with a lower order number already has the same `ccpPayID`, otherwise `0`.\n\nIf no order with this number exists, or the order has no matching address record, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Order number (`OrderHeader.OrderNr`) of the order whose credit card data is returned. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- The call returns sensitive payment data (full card number and CVC) exactly as stored. Access to this call should be restricted.\n- If `ccpPayID` is `NULL`, the comparison with earlier orders never matches and `CCPIDUsedBefore` is `0`.\n- The card type is resolved with a scalar subquery. If `Creditcards` contains more than one row for the same `CardType`, SQL Server raises an error (subquery returned more than one value). If there is no matching row, `CreditCardType` is `NULL`.\n- The column data types depend on the table definitions, which are not part of the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns the DATEV export rows for payments (bank lines and customer account events) in a date range, optionally filtered by shop, country, bank account, amount range and cost center.\n\nProduces the content of the DATEV export file \"Payment\" (wires).\n\n1. The setting `BookExportDatevActive` is checked. If it is not `1`, only a status row with `Status` = `ERROR` is returned.\n2. Otherwise the internal procedure `Pixi_DatevExportWires` is executed with the given parameters and `SetStartAndEndOfDay = 0`, i.e. `DateFrom` and `DateTo` are used **exactly as passed**, without expanding them to start/end of day.\n\nThe result combines two sources (`UNION ALL`):\n\n**Bank lines** (`BankLines`)\n- Bank lines with `BankDate` between `DateFrom` and `DateTo` (inclusive). If the setting `BookExportWiresWithBookDate` = 1, the date is derived from the bank line's book date (MMDD plus year, with year-change correction), taken from a window of two weeks before/after the range.\n- Bank lines from bank headers with source type `APY` are always excluded; `CCP` only if `BookExportCcpTransactions` is set; `UPD` and business code `020` only if `BookExportUpdTransactions` is set.\n- Customer, shop and invoice are determined from the final (non-prematch) bank match: invoice, order, direct debit (`DTAUS`) or customer account entry, in this order.\n- `CustomerNr` is the customer's `DatevAccNr`, or the setting `BookDefaultCustomerNr` if no customer is found.\n- `InvoiceNr` is the external order number if the payment method is listed in the setting `BookExportDatevUseOrderNrExternal`; otherwise the invoice number (for direct debits the matched invoice). Fallback is `BookDefaultInvoiceNr`; the value is cut to 12 characters.\n- `BankAccountNr` is the bank line's accounting bank account (if `BookExportQueryAndUseAccountingBankAccount` is set), the PayPal account `BookDefaultBankAccountNrPayPal` for source types `PPL`/`PLL`, otherwise `BookDefaultBankAccountNr`.\n- `WireText` combines external order number, bank texts 1–3 and, for credit card payments, `Kreditkarte` plus the payment ID; max. 60 characters, double quotes removed.\n\n**Customer account events** (`CustomerAccount`, events `RPP`, `RCC`, `BTC`)\n- Events with `EventDate` >= `DateFrom` and < `DateTo`.\n- Included if a manual booking is linked, or if the setting `BookExportDatevExportAutomaticCAEvents` is active and the event type is marked manual; additionally direct-debit-related entries with a matched invoice if `BookExportManualDtausToDatev` is set.\n- `BankAccountNr` is the booking account of the event type; `BTC` gets the plus sign, the others the minus sign.\n\n**Filters** (both parts): `ShopId` (shop of the customer), `CostCenter` (cost center of the shop), `Country` (country of the invoice/order address or customer address), `AmoutFrom`/`AmoutTo` (on the absolute amount) and `BankAccountNr` (on the computed bank account).\n\nThe sign is `s`/`h` if the setting `BookExportDatevPro` is active, otherwise `+`/`-`. Rows are sorted by `BankAccountNr`, `BankDate`, `Amount`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Yes | Start of the period (used exactly as passed). |\n| `DateTo` | datetime | Yes | End of the period (used exactly as passed; inclusive for bank lines, exclusive for customer account events). |\n| `ShopId` | varchar(3) | No | Optional shop ID; only payments of customers of this shop are returned. |\n| `Country` | varchar(3) | No | Optional country code of the invoice/order address (bank lines) or customer address (customer account events). |\n| `BankAccountNr` | varchar(10) | No | Optional booking bank account; compared with the computed `BankAccountNr` column. Empty string is treated as NULL. |\n| `AmoutFrom` | money | No | Optional minimum absolute amount. |\n| `AmoutTo` | money | No | Optional maximum absolute amount. |\n| `CostCenter` | varchar(8) | No | Optional cost center of the shop. Empty string is treated as NULL. |\n\n- Read-only; all tables are read `WITH (NOLOCK)`, so uncommitted data may appear.\n- Because `SetStartAndEndOfDay = 0`, a `DateTo` of `2024-01-31` means midnight at the start of that day: bank lines of that day after 00:00 and customer account events of that day are **not** included. Pass e.g. `2024-01-31T23:59:59` to include the whole day.\n- Bank lines use an inclusive upper bound (`BETWEEN`), customer account events an exclusive one (`<`).\n- Despite the comment \"amount range in €\", `AmoutFrom`/`AmoutTo` are compared with the absolute amount in the currency of the bank line/event, not converted.\n- `ShopId` is declared as `varchar(3)`; the internal lookup by shop short name (values longer than 3 characters) can therefore not take effect through this call. An empty `ShopId` is not treated as NULL and yields no rows, whereas empty `BankAccountNr` and `CostCenter` are treated as NULL.\n- Customer account events are only returned if their exchange rate is found in the internally reduced exchange rate set (rates of the database currency source within ±2 weeks for currencies that occur in the selected bank lines).\n- Bank lines without a bank header are excluded by the source type filters.\n- The behaviour depends on many settings read at runtime (see description); `dbo.SettingGet` and `pixi.GetDatabaseCurrency` are not attached, so their exact semantics are not documented here.\n\nDocumentation: https://pixi-api-docs.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": "Returns the DATEV export rows for payments (bank lines and customer account events) in a date range, optionally filtered by shop, country, bank account, amount range and cost center.\n\nProduces the content of the DATEV export file \"Payment\" (wires).\n\n1. The setting `BookExportDatevActive` is checked. If it is not `1`, only a status row with `Status` = `ERROR` is returned.\n2. Otherwise the internal procedure `Pixi_DatevExportWires` is executed with the given parameters and `SetStartAndEndOfDay = 0`, i.e. `DateFrom` and `DateTo` are used **exactly as passed**, without expanding them to start/end of day.\n\nThe result combines two sources (`UNION ALL`):\n\n**Bank lines** (`BankLines`)\n- Bank lines with `BankDate` between `DateFrom` and `DateTo` (inclusive). If the setting `BookExportWiresWithBookDate` = 1, the date is derived from the bank line's book date (MMDD plus year, with year-change correction), taken from a window of two weeks before/after the range.\n- Bank lines from bank headers with source type `APY` are always excluded; `CCP` only if `BookExportCcpTransactions` is set; `UPD` and business code `020` only if `BookExportUpdTransactions` is set.\n- Customer, shop and invoice are determined from the final (non-prematch) bank match: invoice, order, direct debit (`DTAUS`) or customer account entry, in this order.\n- `CustomerNr` is the customer's `DatevAccNr`, or the setting `BookDefaultCustomerNr` if no customer is found.\n- `InvoiceNr` is the external order number if the payment method is listed in the setting `BookExportDatevUseOrderNrExternal`; otherwise the invoice number (for direct debits the matched invoice). Fallback is `BookDefaultInvoiceNr`; the value is cut to 12 characters.\n- `BankAccountNr` is the bank line's accounting bank account (if `BookExportQueryAndUseAccountingBankAccount` is set), the PayPal account `BookDefaultBankAccountNrPayPal` for source types `PPL`/`PLL`, otherwise `BookDefaultBankAccountNr`.\n- `WireText` combines external order number, bank texts 1–3 and, for credit card payments, `Kreditkarte` plus the payment ID; max. 60 characters, double quotes removed.\n\n**Customer account events** (`CustomerAccount`, events `RPP`, `RCC`, `BTC`)\n- Events with `EventDate` >= `DateFrom` and < `DateTo`.\n- Included if a manual booking is linked, or if the setting `BookExportDatevExportAutomaticCAEvents` is active and the event type is marked manual; additionally direct-debit-related entries with a matched invoice if `BookExportManualDtausToDatev` is set.\n- `BankAccountNr` is the booking account of the event type; `BTC` gets the plus sign, the others the minus sign.\n\n**Filters** (both parts): `ShopId` (shop of the customer), `CostCenter` (cost center of the shop), `Country` (country of the invoice/order address or customer address), `AmoutFrom`/`AmoutTo` (on the absolute amount) and `BankAccountNr` (on the computed bank account).\n\nThe sign is `s`/`h` if the setting `BookExportDatevPro` is active, otherwise `+`/`-`. Rows are sorted by `BankAccountNr`, `BankDate`, `Amount`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Yes | Start of the period (used exactly as passed). |\n| `DateTo` | datetime | Yes | End of the period (used exactly as passed; inclusive for bank lines, exclusive for customer account events). |\n| `ShopId` | varchar(3) | No | Optional shop ID; only payments of customers of this shop are returned. |\n| `Country` | varchar(3) | No | Optional country code of the invoice/order address (bank lines) or customer address (customer account events). |\n| `BankAccountNr` | varchar(10) | No | Optional booking bank account; compared with the computed `BankAccountNr` column. Empty string is treated as NULL. |\n| `AmoutFrom` | money | No | Optional minimum absolute amount. |\n| `AmoutTo` | money | No | Optional maximum absolute amount. |\n| `CostCenter` | varchar(8) | No | Optional cost center of the shop. Empty string is treated as NULL. |\n\n- Read-only; all tables are read `WITH (NOLOCK)`, so uncommitted data may appear.\n- Because `SetStartAndEndOfDay = 0`, a `DateTo` of `2024-01-31` means midnight at the start of that day: bank lines of that day after 00:00 and customer account events of that day are **not** included. Pass e.g. `2024-01-31T23:59:59` to include the whole day.\n- Bank lines use an inclusive upper bound (`BETWEEN`), customer account events an exclusive one (`<`).\n- Despite the comment \"amount range in €\", `AmoutFrom`/`AmoutTo` are compared with the absolute amount in the currency of the bank line/event, not converted.\n- `ShopId` is declared as `varchar(3)`; the internal lookup by shop short name (values longer than 3 characters) can therefore not take effect through this call. An empty `ShopId` is not treated as NULL and yields no rows, whereas empty `BankAccountNr` and `CostCenter` are treated as NULL.\n- Customer account events are only returned if their exchange rate is found in the internally reduced exchange rate set (rates of the database currency source within ±2 weeks for currencies that occur in the selected bank lines).\n- Bank lines without a bank header are excluded by the source type filters.\n- The behaviour depends on many settings read at runtime (see description); `dbo.SettingGet` and `pixi.GetDatabaseCurrency` are not attached, so their exact semantics are not documented here.\n\nDocumentation: https://pixi-api-docs.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": "Returns the customer account entry of an invoice together with all matched account entries and their bank line and bank import details.\n\nLooks up the payment situation of a single invoice via the customer account (`CustomerAccount`).\n\n1. The invoice is identified by `InvoiceNr` in `Invoices`. The customer account entry whose `InvoiceRef` points to this invoice is determined (the invoice entry).\n2. All customer account entries that are matched with this invoice entry in `CustomerAccountMatch` are collected. The match is evaluated in both directions (`CARef1` and `CARef2`), so payments, credit notes or other entries linked to the invoice are found regardless of how the match was stored.\n3. For the invoice entry and all matched entries, one row each is returned with the account entry data. If an entry was created from a bank line (`BanklineRef`), the bank line data (`BankLines`) and the data of the bank import file (`BankHeader`) are added; otherwise these columns are empty.\n\nSort order: the invoice entry itself comes first, followed by the matched entries in ascending order of `CustomerAccountKey`.\n\nIf no invoice with the given number exists or it has no customer account entry, an empty result set is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Yes | Number of the invoice (`Invoices.InvoiceNr`) whose payment details are requested. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- Only direct matches of the invoice entry are returned; entries that are matched only indirectly (via another matched entry) are not included.\n- If several invoices share the same `InvoiceNr`, the subquery returns more than one value and SQL Server raises error 512 (returned as `SqlMessage`).\n- If several customer account entries reference the invoice, only one of them (not deterministically chosen) is used as the invoice entry.\n- Column types are not visible in the code; types in this documentation are derived from column names and usage.\n\nDocumentation: https://pixi-api-docs.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": "Returns the customer account entry of an invoice together with all matched account entries and their bank line and bank import details.\n\nLooks up the payment situation of a single invoice via the customer account (`CustomerAccount`).\n\n1. The invoice is identified by `InvoiceNr` in `Invoices`. The customer account entry whose `InvoiceRef` points to this invoice is determined (the invoice entry).\n2. All customer account entries that are matched with this invoice entry in `CustomerAccountMatch` are collected. The match is evaluated in both directions (`CARef1` and `CARef2`), so payments, credit notes or other entries linked to the invoice are found regardless of how the match was stored.\n3. For the invoice entry and all matched entries, one row each is returned with the account entry data. If an entry was created from a bank line (`BanklineRef`), the bank line data (`BankLines`) and the data of the bank import file (`BankHeader`) are added; otherwise these columns are empty.\n\nSort order: the invoice entry itself comes first, followed by the matched entries in ascending order of `CustomerAccountKey`.\n\nIf no invoice with the given number exists or it has no customer account entry, an empty result set is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Yes | Number of the invoice (`Invoices.InvoiceNr`) whose payment details are requested. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- Only direct matches of the invoice entry are returned; entries that are matched only indirectly (via another matched entry) are not included.\n- If several invoices share the same `InvoiceNr`, the subquery returns more than one value and SQL Server raises error 512 (returned as `SqlMessage`).\n- If several customer account entries reference the invoice, only one of them (not deterministically chosen) is used as the invoice entry.\n- Column types are not visible in the code; types in this documentation are derived from column names and usage.\n\nDocumentation: https://pixi-api-docs.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": "Returns the payment types defined in Pixi, optionally filtered by code, payment text, initial order status or XML tag.\n\nReads the payment types from the `Payments` table and returns, for each one, its `Code`, `PaymentText`, `IniOrderStatus` and `XMLTag`.\n\n- Parameters sent as an empty string are treated as not set (`NULL`).\n- If **no** parameter is set, all payment types are returned.\n- If one or more parameters are set, a payment type is returned when it matches **at least one** of the given values:\n - `Code` equals `Code`\n - `PaymentText` equals `PaymentText`\n - `IniOrderStatus` equals `IniOrderStatus`\n - `XMLTag` equals `TagXML`\n\nAll comparisons are exact matches; there is no wildcard search. No sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Code` | varchar(1) | No | One-character code of the payment type. Empty means no filter on the code. |\n| `PaymentText` | varchar(32) | No | Exact text (name) of the payment type. Empty means no filter on the text. |\n| `IniOrderStatus` | varchar(3) | No | Initial order status assigned to orders with this payment type. Empty means no filter on the status. |\n| `TagXML` | varchar(32) | No | XML tag of the payment type, compared with the column `XMLTag`. Empty means no filter on the tag. |\n\n- The filters are combined with **OR**, not AND. Passing e.g. both `Code` and `IniOrderStatus` returns payment types that match either value, not only those that match both.\n- The table is read `WITH (NOLOCK)`, so uncommitted changes may be visible.\n- The parameter for the XML tag is named `TagXML`, while the returned column is named `XMLTag`.\n- Because SQL Server ignores trailing spaces in string comparisons, a value consisting only of spaces is also treated as not set.\n- The column types in the result are not visible in the code; the types given here mirror the parameter types used for the comparisons.\n\nDocumentation: https://pixi-api-docs.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": "Returns the payment types defined in Pixi, optionally filtered by code, payment text, initial order status or XML tag.\n\nReads the payment types from the `Payments` table and returns, for each one, its `Code`, `PaymentText`, `IniOrderStatus` and `XMLTag`.\n\n- Parameters sent as an empty string are treated as not set (`NULL`).\n- If **no** parameter is set, all payment types are returned.\n- If one or more parameters are set, a payment type is returned when it matches **at least one** of the given values:\n - `Code` equals `Code`\n - `PaymentText` equals `PaymentText`\n - `IniOrderStatus` equals `IniOrderStatus`\n - `XMLTag` equals `TagXML`\n\nAll comparisons are exact matches; there is no wildcard search. No sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Code` | varchar(1) | No | One-character code of the payment type. Empty means no filter on the code. |\n| `PaymentText` | varchar(32) | No | Exact text (name) of the payment type. Empty means no filter on the text. |\n| `IniOrderStatus` | varchar(3) | No | Initial order status assigned to orders with this payment type. Empty means no filter on the status. |\n| `TagXML` | varchar(32) | No | XML tag of the payment type, compared with the column `XMLTag`. Empty means no filter on the tag. |\n\n- The filters are combined with **OR**, not AND. Passing e.g. both `Code` and `IniOrderStatus` returns payment types that match either value, not only those that match both.\n- The table is read `WITH (NOLOCK)`, so uncommitted changes may be visible.\n- The parameter for the XML tag is named `TagXML`, while the returned column is named `XMLTag`.\n- Because SQL Server ignores trailing spaces in string comparisons, a value consisting only of spaces is also treated as not set.\n- The column types in the result are not visible in the code; the types given here mirror the parameter types used for the comparisons.\n\nDocumentation: https://pixi-api-docs.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": "Returns customer account payments that were not fully matched at a given key date, either summed per payment type or as single entries.\n\nLists payments booked on customer accounts (`CustomerAccount`) that were still open, meaning not fully matched, at a given point in time.\n\n**Parameter handling**\n- `Date`: if `NULL` or earlier than 1990-01-01, the current date and time (`GETDATE()`) is used.\n- `Details`: `NULL` is treated as `0`.\n- `ShopID`: an empty string is treated as `NULL`, which means no shop filter.\n\n**Selection**\n1. For every customer account entry the latest log entry with event `PAY` and an `EventDate` strictly before `Date` is taken from `CustomerAccountLog`.\n2. The entry is included only if `Amount - Matched` of that `PAY` log entry is at least 0.01.\n3. `OpenAmount` is the amount of the customer account entry minus the `Matched` value of the latest log entry of *any* event type before `Date`. If there is no such entry, 0 is subtracted.\n4. The payment type comes from the payment method of the Auftrag (delivery address `APayment`) or the Rechnung (`Payment`) that is linked to the bank line through `BankMatch`. If no payment method is found, `ZZZ unbekannt` is used.\n5. With `ShopID` set, only customers whose `CustomerOf` equals `ShopID` are returned.\n\n**Currency**\n- If the setting `MultiCurrencyEnabled` is not `1`, amounts are returned in the original currency of the entry and `dbCurrency` is `NULL`.\n- If `MultiCurrencyEnabled` = `1`, `Amount` and `OpenAmount` are converted into the database (home) currency by dividing them by the exchange rate. `dbCurrency` then holds the code of the database currency.\n\n**Output**\n- `Details = 1`: one row per customer account entry, sorted by `PaymentType`, `CustRef` and `CustomerAccountKey`.\n- `Details = 0` (default): one row per `PaymentType` and `dbCurrency` with the summed `OpenAmount` and the key date that was used, sorted by `PaymentType`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Date` | datetime | No | Key date. Only log entries strictly before this point in time are considered. `NULL` or values before 1990-01-01 are replaced by the current date and time. |\n| `Details` | bit | No | Selects detail rows or a summary per payment type. `NULL` is treated as `0`. |\n| `ShopID` | varchar(3) | No | Optional shop filter on the customer's `CustomerOf`. Empty or `NULL` returns all shops. |\n\n- All reads use `NOLOCK`, so results can include uncommitted data.\n- The filter uses the latest `PAY` log entry, but `OpenAmount` uses the latest log entry of any event type. The two values can therefore differ.\n- With multi-currency enabled, entries without a matching exchange rate for the database currency (via `pixi.ExchRate`, source from setting `DatabaseCurrencyExchRateSourceId`, base currency from setting `HomeCurrency`) are dropped by inner joins.\n- In the multi-currency branch, the subquery for the matched amount filters the exchange rate source on the outer alias instead of its own. If several rate sources exist, the `TOP 1` rate that is used is not deterministic.\n- The join to `Payments` uses an OR on the Auftrag and Rechnung payment codes. If both are linked and differ, an entry can appear twice and is then counted twice in the summary.\n- In single-currency mode `dbCurrency` is `NULL`, so the summary mixes amounts of different original currencies within one payment type.\n- The key date comparison is strict (`EventDate < Date`). If only a date is passed, its time part is midnight, so events of that day are excluded.\n\nDocumentation: https://pixi-api-docs.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": "Returns customer account payments that were not fully matched at a given key date, either summed per payment type or as single entries.\n\nLists payments booked on customer accounts (`CustomerAccount`) that were still open, meaning not fully matched, at a given point in time.\n\n**Parameter handling**\n- `Date`: if `NULL` or earlier than 1990-01-01, the current date and time (`GETDATE()`) is used.\n- `Details`: `NULL` is treated as `0`.\n- `ShopID`: an empty string is treated as `NULL`, which means no shop filter.\n\n**Selection**\n1. For every customer account entry the latest log entry with event `PAY` and an `EventDate` strictly before `Date` is taken from `CustomerAccountLog`.\n2. The entry is included only if `Amount - Matched` of that `PAY` log entry is at least 0.01.\n3. `OpenAmount` is the amount of the customer account entry minus the `Matched` value of the latest log entry of *any* event type before `Date`. If there is no such entry, 0 is subtracted.\n4. The payment type comes from the payment method of the Auftrag (delivery address `APayment`) or the Rechnung (`Payment`) that is linked to the bank line through `BankMatch`. If no payment method is found, `ZZZ unbekannt` is used.\n5. With `ShopID` set, only customers whose `CustomerOf` equals `ShopID` are returned.\n\n**Currency**\n- If the setting `MultiCurrencyEnabled` is not `1`, amounts are returned in the original currency of the entry and `dbCurrency` is `NULL`.\n- If `MultiCurrencyEnabled` = `1`, `Amount` and `OpenAmount` are converted into the database (home) currency by dividing them by the exchange rate. `dbCurrency` then holds the code of the database currency.\n\n**Output**\n- `Details = 1`: one row per customer account entry, sorted by `PaymentType`, `CustRef` and `CustomerAccountKey`.\n- `Details = 0` (default): one row per `PaymentType` and `dbCurrency` with the summed `OpenAmount` and the key date that was used, sorted by `PaymentType`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Date` | datetime | No | Key date. Only log entries strictly before this point in time are considered. `NULL` or values before 1990-01-01 are replaced by the current date and time. |\n| `Details` | bit | No | Selects detail rows or a summary per payment type. `NULL` is treated as `0`. |\n| `ShopID` | varchar(3) | No | Optional shop filter on the customer's `CustomerOf`. Empty or `NULL` returns all shops. |\n\n- All reads use `NOLOCK`, so results can include uncommitted data.\n- The filter uses the latest `PAY` log entry, but `OpenAmount` uses the latest log entry of any event type. The two values can therefore differ.\n- With multi-currency enabled, entries without a matching exchange rate for the database currency (via `pixi.ExchRate`, source from setting `DatabaseCurrencyExchRateSourceId`, base currency from setting `HomeCurrency`) are dropped by inner joins.\n- In the multi-currency branch, the subquery for the matched amount filters the exchange rate source on the outer alias instead of its own. If several rate sources exist, the `TOP 1` rate that is used is not deterministic.\n- The join to `Payments` uses an OR on the Auftrag and Rechnung payment codes. If both are linked and differ, an entry can appear twice and is then counted twice in the summary.\n- In single-currency mode `dbCurrency` is `NULL`, so the summary mixes amounts of different original currencies within one payment type.\n- The key date comparison is strict (`EventDate < Date`). If only a date is passed, its time part is midnight, so events of that day are excluded.\n\nDocumentation: https://pixi-api-docs.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": "Returns the POS cash journal (register events with amounts, invoices and running register value) for a date range, location and register.\n\nReturns the cash journal (Kassenbuch) of the Pixi POS module. The work is done by the internal procedure `CR_POS_Kassenbuch`. Its rows are buffered, and a reduced set of columns is returned.\n\nSteps:\n\n1. The common API envelope checks the call frequency. If the minimum interval configured for this function has not passed, only a status row with `ResultCode` `502` is returned and no journal data is read.\n2. Defaults are applied:\n - `FromDate` and `ToDate` default to today.\n - `FromDate` is used as given, including its time.\n - `ToDate` is extended to the end of its day.\n3. POS session events in the range are selected. Events of type `I` are excluded.\n - `LocID` limits the result to one location. `NULL` or empty means all locations.\n - `RegisterID` limits the result to one register. `''` or `NULL` means all registers.\n4. Each event is joined with the POS invoice header, if one exists, and with a description of the event type:\n - `S` = POS Start\n - `E` = POS Stop\n - `P` = Invoice\n - `D` = Drawer Open\n5. `RegisterValue` is the running total of `AmountIn - AmountOut` over all selected events with an `EventTime` up to and including the current one.\n6. `EventComment` combines the event comment and the invoice comment, separated by a line break.\n\nThe internal procedure sorts by `EventTime`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | No | Start of the period (inclusive, time is respected). `NULL` means today 00:00. |\n| `ToDate` | datetime | No | End of the period. It is extended to the end of its day; times of 12:00 or later round to the next day. `NULL` means today. |\n| `LocID` | varchar(3) | No | Location (Lager) of the POS session. `NULL` or empty returns all locations. |\n| `RegisterID` | varchar(30) | No | POS register ID. Empty or `NULL` returns all registers. |\n| `ResultCode` | char(3) | No | Result code of the API envelope. |\n| `ResultText` | varchar(1024) | No | Result text: `OK` or the frequency limit message. |\n\n- **Call statistics:** the API envelope writes the time of the call into `API_STATISTICS`. This is the only write access.\n- **Reads:** all reads of journal data use `NOLOCK`, so uncommitted data may appear.\n- **Sort order:** the final `SELECT` reads from a table variable without its own `ORDER BY`. The order by `EventTime` is therefore not strictly guaranteed.\n- **Running total:** `RegisterValue` is calculated over all selected events, not per register or per location. When several registers or locations are queried at once, the value mixes them. It also starts at 0 at `FromDate`; there is no opening balance from before the range.\n- **End of range:** `ToDate` is converted with `CAST(... AS INTEGER)`. For `datetime` values this rounds to the nearest day, so a `ToDate` with a time of 12:00 or later extends the range to the end of the following day. Pass `ToDate` without a time.\n- **VAT rates:** events are inner-joined with VAT rates from `fPixi_GetVATRate` (not attached). If that function returns no rate for a location, the events of that location are missing from the result.\n- **Always empty:** `CreatedBy` and `UpdatedBy` are always `NULL`.\n- **Unknown types:** `EventDescription` is `NULL` for event types other than `S`, `E`, `P` and `D`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the POS cash journal (register events with amounts, invoices and running register value) for a date range, location and register.\n\nReturns the cash journal (Kassenbuch) of the Pixi POS module. The work is done by the internal procedure `CR_POS_Kassenbuch`. Its rows are buffered, and a reduced set of columns is returned.\n\nSteps:\n\n1. The common API envelope checks the call frequency. If the minimum interval configured for this function has not passed, only a status row with `ResultCode` `502` is returned and no journal data is read.\n2. Defaults are applied:\n - `FromDate` and `ToDate` default to today.\n - `FromDate` is used as given, including its time.\n - `ToDate` is extended to the end of its day.\n3. POS session events in the range are selected. Events of type `I` are excluded.\n - `LocID` limits the result to one location. `NULL` or empty means all locations.\n - `RegisterID` limits the result to one register. `''` or `NULL` means all registers.\n4. Each event is joined with the POS invoice header, if one exists, and with a description of the event type:\n - `S` = POS Start\n - `E` = POS Stop\n - `P` = Invoice\n - `D` = Drawer Open\n5. `RegisterValue` is the running total of `AmountIn - AmountOut` over all selected events with an `EventTime` up to and including the current one.\n6. `EventComment` combines the event comment and the invoice comment, separated by a line break.\n\nThe internal procedure sorts by `EventTime`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | No | Start of the period (inclusive, time is respected). `NULL` means today 00:00. |\n| `ToDate` | datetime | No | End of the period. It is extended to the end of its day; times of 12:00 or later round to the next day. `NULL` means today. |\n| `LocID` | varchar(3) | No | Location (Lager) of the POS session. `NULL` or empty returns all locations. |\n| `RegisterID` | varchar(30) | No | POS register ID. Empty or `NULL` returns all registers. |\n| `ResultCode` | char(3) | No | Result code of the API envelope. |\n| `ResultText` | varchar(1024) | No | Result text: `OK` or the frequency limit message. |\n\n- **Call statistics:** the API envelope writes the time of the call into `API_STATISTICS`. This is the only write access.\n- **Reads:** all reads of journal data use `NOLOCK`, so uncommitted data may appear.\n- **Sort order:** the final `SELECT` reads from a table variable without its own `ORDER BY`. The order by `EventTime` is therefore not strictly guaranteed.\n- **Running total:** `RegisterValue` is calculated over all selected events, not per register or per location. When several registers or locations are queried at once, the value mixes them. It also starts at 0 at `FromDate`; there is no opening balance from before the range.\n- **End of range:** `ToDate` is converted with `CAST(... AS INTEGER)`. For `datetime` values this rounds to the nearest day, so a `ToDate` with a time of 12:00 or later extends the range to the end of the following day. Pass `ToDate` without a time.\n- **VAT rates:** events are inner-joined with VAT rates from `fPixi_GetVATRate` (not attached). If that function returns no rate for a location, the events of that location are missing from the result.\n- **Always empty:** `CreatedBy` and `UpdatedBy` are always `NULL`.\n- **Unknown types:** `EventDescription` is `NULL` for event types other than `S`, `E`, `P` and `D`.\n\nDocumentation: https://pixi-api-docs.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": "Returns unpaid, shipped invoices of a payment method that are due for capture, with order, amount, customer address and card data.\n\nSelects the invoices that a payment integration (for example a credit card provider) should capture next and returns them with all data needed for the capture.\n\nAn invoice is selected when **all** of the following apply:\n\n- `Payment` equals `@PaymentCode`.\n- Nothing has been paid yet (`PayedSum = 0`) and `Total > 0`.\n- The capture is not marked as done (`CCPPaymentDone` is `N` or NULL).\n- The invoice has been scanned out (`ScanOutDate` is set).\n- `InvoiceKey` is greater than `@FromInvoiceId`.\n- One of the retry conditions holds:\n - no capture attempt yet (`CCPNumOfTries = 0`), or\n - a recharge is requested (`CCPRecharge = 'Y'`), or\n - 1 to 3 failed attempts (`ccpSetFailTries`) and the last failure (`ccpSetFailLastTime`) is older than 10 minutes, or\n - `@ShowAll = 1`, which skips the retry conditions entirely.\n\nAt most `@RowCount` invoices are selected, ordered by `InvoiceKey` ascending. For each one the call returns invoice number, the comma-separated list of external order numbers, total, paid amount, amount to capture (`Total - PayedSum`), the sum of linked order lines in status `ANG`, currency code, shop (`CustomerOf` of the customer), the card and address data of the invoice address, and the capture status fields.\n\n**Paging:** pass the `InvoiceId` of the last returned row as `@FromInvoiceId` to get the next block.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PaymentCode` | char(1) | Yes | Payment method code; only invoices whose `Payment` field equals this value are returned. |\n| `ShowAll` | bit | No | If 1, the retry conditions (no attempt yet, recharge requested, or 1–3 failures with the last one older than 10 minutes) are ignored. |\n| `RowCount` | int | No | Maximum number of invoices to return. |\n| `FromInvoiceId` | int | No | Only invoices with an `InvoiceKey` greater than this value are returned; use the last returned `InvoiceId` for paging. |\n\n- All reads use `NOLOCK`, so uncommitted changes may be visible.\n- The call does not change any data; marking invoices as captured or failed must be done separately.\n- `@ShowAll = 1` only removes the retry/back-off condition; all other filters (payment code, unpaid, scanned out, not done) still apply. It also returns invoices with more than 3 failed attempts.\n- The `TOP (@RowCount)` limit is applied before joining currency, customer and address. Invoices without a matching row there are dropped, so fewer than `@RowCount` rows may be returned although more invoices exist.\n- Because only invoices with `PayedSum = 0` are selected, `TotalToCapture` always equals `Total`.\n- `Total_OrderCurr` is a duplicate of `Total`; a code comment marks it for removal, so clients should not rely on it.\n- The result contains sensitive card data (number, expiry, CVC); handle and log it accordingly.\n\nDocumentation: https://pixi-api-docs.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": "Returns unpaid, shipped invoices of a payment method that are due for capture, with order, amount, customer address and card data.\n\nSelects the invoices that a payment integration (for example a credit card provider) should capture next and returns them with all data needed for the capture.\n\nAn invoice is selected when **all** of the following apply:\n\n- `Payment` equals `@PaymentCode`.\n- Nothing has been paid yet (`PayedSum = 0`) and `Total > 0`.\n- The capture is not marked as done (`CCPPaymentDone` is `N` or NULL).\n- The invoice has been scanned out (`ScanOutDate` is set).\n- `InvoiceKey` is greater than `@FromInvoiceId`.\n- One of the retry conditions holds:\n - no capture attempt yet (`CCPNumOfTries = 0`), or\n - a recharge is requested (`CCPRecharge = 'Y'`), or\n - 1 to 3 failed attempts (`ccpSetFailTries`) and the last failure (`ccpSetFailLastTime`) is older than 10 minutes, or\n - `@ShowAll = 1`, which skips the retry conditions entirely.\n\nAt most `@RowCount` invoices are selected, ordered by `InvoiceKey` ascending. For each one the call returns invoice number, the comma-separated list of external order numbers, total, paid amount, amount to capture (`Total - PayedSum`), the sum of linked order lines in status `ANG`, currency code, shop (`CustomerOf` of the customer), the card and address data of the invoice address, and the capture status fields.\n\n**Paging:** pass the `InvoiceId` of the last returned row as `@FromInvoiceId` to get the next block.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PaymentCode` | char(1) | Yes | Payment method code; only invoices whose `Payment` field equals this value are returned. |\n| `ShowAll` | bit | No | If 1, the retry conditions (no attempt yet, recharge requested, or 1–3 failures with the last one older than 10 minutes) are ignored. |\n| `RowCount` | int | No | Maximum number of invoices to return. |\n| `FromInvoiceId` | int | No | Only invoices with an `InvoiceKey` greater than this value are returned; use the last returned `InvoiceId` for paging. |\n\n- All reads use `NOLOCK`, so uncommitted changes may be visible.\n- The call does not change any data; marking invoices as captured or failed must be done separately.\n- `@ShowAll = 1` only removes the retry/back-off condition; all other filters (payment code, unpaid, scanned out, not done) still apply. It also returns invoices with more than 3 failed attempts.\n- The `TOP (@RowCount)` limit is applied before joining currency, customer and address. Invoices without a matching row there are dropped, so fewer than `@RowCount` rows may be returned although more invoices exist.\n- Because only invoices with `PayedSum = 0` are selected, `TotalToCapture` always equals `Total`.\n- `Total_OrderCurr` is a duplicate of `Total`; a code comment marks it for removal, so clients should not rely on it.\n- The result contains sensitive card data (number, expiry, CVC); handle and log it accordingly.\n\nDocumentation: https://pixi-api-docs.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": "Returns orders with lines in status HAL that are due for payment authorization for a given payment method, including amounts, card and address data.\n\nSelects orders that a payment connector (for example a credit card processor) should authorize, and returns one row per order.\n\nSelection steps:\n\n1. Collect all orders that have at least one order line in status `HAL`.\n2. Keep only orders where:\n - the order header was last updated more than **10 minutes** ago (`updatedate`), so that the order is complete before it is processed,\n - the payment code of the order address (`Addresses.aPayment`) equals `PaymentCode`,\n - at least one of these holds: `ccpNumOfTries` <= 3, `CCPReauthorizeYN` = `Y` (re-authorization requested), `ShowAll` = 1, or `ccpSetFailTries` between 1 and 3 and `ccpSetFailLastTime` older than 10 minutes,\n - the customer is not locked (`Customers.SLocked` is not `Y`).\n3. Take the first `RowCount` orders, ordered by `ccpNumOfTries` ascending, then `OrderHeaderKey` ascending (orders with fewer attempts first).\n4. For these orders, sum `OrderLineAmount` of the lines in status `ANG`, `HAL` and `AUS` separately (missing statuses count as 0).\n\nThe result contains order totals, the per-status line totals, currency, shop ID, card data and address data of the order address, plus the authorization tracking fields of the order header. The final result is sorted by `OrderHeaderKey` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PaymentCode` | char(1) | Yes | Payment method code; compared with `Addresses.aPayment` of the order address. |\n| `ShowAll` | bit | No | If 1, orders are returned regardless of the number of previous authorization attempts. |\n| `RowCount` | int | No | Maximum number of orders returned. |\n\n- Read-only; all permanent tables are read `WITH (NOLOCK)`, so uncommitted data may be returned.\n- **Pitfall:** in the result the column `Addresses.eMail` is returned under the alias `CCPPaymentInfoOK` (there is no column `eMail`). The column therefore contains the e-mail address of the order address, not a payment status flag.\n- The `*_OrderCurr` columns contain exactly the same values as their counterparts without suffix (comments in the code mark them for removal); no currency conversion happens.\n- The result contains sensitive card data (`CardNumber`, `CardCVC`, `CardExpiration`); handle and transport it accordingly.\n- `ShowAll` = 1 only bypasses the retry-count conditions; the 10-minute waiting time, payment code, `HAL` line and customer lock filters still apply.\n- `RowCount` limits the number of orders, not lines.\n- The 10-minute threshold is based on the server time (`GETDATE()`).\n\nDocumentation: https://pixi-api-docs.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": "Returns orders with lines in status HAL that are due for payment authorization for a given payment method, including amounts, card and address data.\n\nSelects orders that a payment connector (for example a credit card processor) should authorize, and returns one row per order.\n\nSelection steps:\n\n1. Collect all orders that have at least one order line in status `HAL`.\n2. Keep only orders where:\n - the order header was last updated more than **10 minutes** ago (`updatedate`), so that the order is complete before it is processed,\n - the payment code of the order address (`Addresses.aPayment`) equals `PaymentCode`,\n - at least one of these holds: `ccpNumOfTries` <= 3, `CCPReauthorizeYN` = `Y` (re-authorization requested), `ShowAll` = 1, or `ccpSetFailTries` between 1 and 3 and `ccpSetFailLastTime` older than 10 minutes,\n - the customer is not locked (`Customers.SLocked` is not `Y`).\n3. Take the first `RowCount` orders, ordered by `ccpNumOfTries` ascending, then `OrderHeaderKey` ascending (orders with fewer attempts first).\n4. For these orders, sum `OrderLineAmount` of the lines in status `ANG`, `HAL` and `AUS` separately (missing statuses count as 0).\n\nThe result contains order totals, the per-status line totals, currency, shop ID, card data and address data of the order address, plus the authorization tracking fields of the order header. The final result is sorted by `OrderHeaderKey` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PaymentCode` | char(1) | Yes | Payment method code; compared with `Addresses.aPayment` of the order address. |\n| `ShowAll` | bit | No | If 1, orders are returned regardless of the number of previous authorization attempts. |\n| `RowCount` | int | No | Maximum number of orders returned. |\n\n- Read-only; all permanent tables are read `WITH (NOLOCK)`, so uncommitted data may be returned.\n- **Pitfall:** in the result the column `Addresses.eMail` is returned under the alias `CCPPaymentInfoOK` (there is no column `eMail`). The column therefore contains the e-mail address of the order address, not a payment status flag.\n- The `*_OrderCurr` columns contain exactly the same values as their counterparts without suffix (comments in the code mark them for removal); no currency conversion happens.\n- The result contains sensitive card data (`CardNumber`, `CardCVC`, `CardExpiration`); handle and transport it accordingly.\n- `ShowAll` = 1 only bypasses the retry-count conditions; the 10-minute waiting time, payment code, `HAL` line and customer lock filters still apply.\n- `RowCount` limits the number of orders, not lines.\n- The 10-minute threshold is based on the server time (`GETDATE()`).\n\nDocumentation: https://pixi-api-docs.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": "Records the result of a payment authorization for an order, releases or keeps its HAL orderlines and writes a payment transaction log entry.\n\nUsed by an external payment provider (logged as *pixi Apps Payment Provider*) to report the outcome of an authorization for an order.\n\n1. The order is looked up by `OrderNr` in `OrderHeader`. From it the procedure reads the customer reference, billing address reference, currency code (`Currency.CodeA`) and the `CustomerOf` (shop) of the customer. It also calculates the sum of `qty * price` of all orderlines of the order that are currently in status `HAL`.\n2. Depending on `Success`:\n - `1` (authorized): orderlines in status `HAL` are set to `ANG`; the log entry gets transaction type `AU` and code `AUTHORIZED`.\n - `0` (declined, default): orderlines stay in status `HAL`; the log entry gets type `DE` and code `AUTH DECLINED`; the order's fail counter `ccpSetFailTries` is increased by 1.\n3. The order header is updated: `ccpNumOfTries` is increased by 1, `CCPLastAuthCode` = `AuthCode`, `ccpPayID` = `AuthID`, `CCPPaymentInfoOK` = `Y`, `CCPReauthorizeYN` = `N`, `ccpSetFailLastTime` and `UpdateDate` = current time, `UpdateEmp` = `API Call PaySetAuth`.\n4. All orderlines of the order with status `HAL` get the new status (see step 2), with `UpdateEmp`/`UpdateDate` set.\n5. A row is inserted into `CCPTranLog` with vendor `AP`, the shop (`CustomerOf`), the order number, `Message` as note, the calculated `HAL` amount as total amount, customer and billing address references and the currency code.\n\nThe call returns no result set.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Pixi order number of the order whose authorization result is reported. |\n| `Success` | bit | No | Result of the authorization. |\n| `AuthID` | varchar(50) | Yes | Payment/authorization ID of the provider; stored in `OrderHeader.ccpPayID`. |\n| `AuthCode` | varchar(50) | Yes | Authorization code of the provider; stored in `OrderHeader.CCPLastAuthCode`. |\n| `Message` | varchar(200) | Yes | Free text message of the provider; stored as note (`CCPNote`) in the transaction log. |\n\n- All changes run in one transaction (or a savepoint if a transaction is already open). On error the changes are rolled back and `log.InsertError` (not attached) is called; the code itself does not re-raise the error, so the caller may receive no error indication.\n- If `OrderNr` does not exist, no order header or orderlines are updated, but a `CCPTranLog` row is still inserted with empty (NULL) shop, customer, address and currency values. No error is returned.\n- `CCPPaymentInfoOK` is set to `Y` and `ccpSetFailLastTime` is updated even when `Success` = 0.\n- `ccpSetFailTries` is incremented without `ISNULL`; if the column is NULL it stays NULL.\n- The amount is calculated via `Order_Id`, while the orderlines to update are selected via `OrderNr`.\n- Lookups use `NOLOCK`; updates use `ROWLOCK`.\n- `AuthID`, `AuthCode` and `Message` have no default and must be sent.\n\nDocumentation: https://pixi-api-docs.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": "Records the result of a payment capture for an invoice, books it as paid or resets it to unpaid, logs it in CCPTranLog and can set open orderlines to HAL.\n\nProcesses the outcome of a payment capture reported by an external payment provider (\"pixi Apps Payment Provider\") for the invoice `InvoiceNr`.\n\nFirst the invoice is looked up together with its customer and currency (customer's `CustomerOf` shop, `CustRef`, `AddrRef`, currency code). All changes then run in one transaction (or a savepoint if the caller already has an open transaction).\n\n**`Success` = 1 (capture succeeded)**\n1. Calls the internal procedure `pixi_SetInvoicePaid` with `paid = 1`, `EventID` and `PaidSum = CaptureSum`, which inserts a manual booking event in the customer account and matches it with the invoice. `EventID` must be a manual, positive customer-account event, otherwise the booking is not created.\n2. If `SetRemainingOrdersToHAL` = 1, all orderlines with status `ANG` that belong to an order (same `OrderNr`) having at least one orderline on this invoice are set to status `HAL`.\n3. Inserts a row into `CCPTranLog` with transaction type `CA` and error code `CAPTURED`, the note `Message`, total amount `CaptureSum` and the invoice currency.\n4. Returns `Status` = `Success` with the message *Successfully created CA manual booking event for InvoiceNr …*.\n\n**`Success` = 0 (capture failed)**\n1. Updates the invoice: increments `ccpSetFailTries`, sets `CCPNumOfTries`, `ccpSetFailLastTime`, resets `PayedSum` to 0 and `Payed` to NULL, sets `CCPPaymentDone` and `CCPReCharge` to `N`.\n2. Always sets the remaining `ANG` orderlines of the affected orders to `HAL` (independent of `SetRemainingOrdersToHAL`).\n3. Inserts a row into `CCPTranLog` with transaction type `ER` and error code `CAPTURED FAILED`.\n4. Returns `Status` = `Success` with the message *Reset payment data to unpaid for InvoiceNr …*.\n\nIf an error occurs, the transaction is rolled back and a row with `Status` = `Error` and the SQL error message is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Yes | Number of the invoice whose capture result is reported. |\n| `Success` | bit | Yes | Result of the capture at the payment provider. |\n| `PayID` | varchar(50) | Yes | Payment ID of the provider. Required but not used by the code. |\n| `PayCode` | varchar(50) | Yes | Payment code of the provider. Required but not used by the code. |\n| `Message` | varchar(200) | Yes | Free text stored as note (`CCPNote`) in the CCP transaction log. |\n| `CaptureSum` | money | Yes | Captured amount; stored as total amount in the CCP log and passed as `PaidSum` to `pixi_SetInvoicePaid`. |\n| `EventID` | varchar(3) | No | Customer account event used for the manual payment booking when `Success` = 1. Must be a manual, positive event; without it no booking is created. |\n| `SetRemainingOrdersToHAL` | bit | Yes | Only for `Success` = 1: whether remaining `ANG` orderlines of the invoiced orders are set to `HAL`. In the failure branch this always happens. |\n\n- Errors inside `pixi_SetInvoicePaid` (e.g. invoice does not exist, invoice already paid, `EventID` missing or not a manual positive event) are caught and only written to the error log (`log.InsertError`). The call still returns `Status` = `Success` and writes the `CCPTranLog` entry, so a `Success` row does not guarantee that the payment was booked.\n- In the attached `pixi_SetInvoicePaid` the booked amount is the open amount of the invoice in the customer account; `CaptureSum` is not used as booking amount there, only stored in `CCPTranLog`.\n- `PayID` and `PayCode` are required but not used by the code.\n- Any value of `Success` other than 1 (including NULL) takes the failure branch.\n- `CCPNumOfTries` is set from `ccpSetFailTries` + 1, not from its own previous value.\n- If the invoice (or its customer/currency join) is not found, no invoice or orderline is updated, but a log entry with empty references is attempted.\n- Orderline updates use `UpdateEmp` = `API Call PaySetAuth`; invoice updates use `CCP Process`. Lookups use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Records the result of a payment capture for an invoice, books it as paid or resets it to unpaid, logs it in CCPTranLog and can set open orderlines to HAL.\n\nProcesses the outcome of a payment capture reported by an external payment provider (\"pixi Apps Payment Provider\") for the invoice `InvoiceNr`.\n\nFirst the invoice is looked up together with its customer and currency (customer's `CustomerOf` shop, `CustRef`, `AddrRef`, currency code). All changes then run in one transaction (or a savepoint if the caller already has an open transaction).\n\n**`Success` = 1 (capture succeeded)**\n1. Calls the internal procedure `pixi_SetInvoicePaid` with `paid = 1`, `EventID` and `PaidSum = CaptureSum`, which inserts a manual booking event in the customer account and matches it with the invoice. `EventID` must be a manual, positive customer-account event, otherwise the booking is not created.\n2. If `SetRemainingOrdersToHAL` = 1, all orderlines with status `ANG` that belong to an order (same `OrderNr`) having at least one orderline on this invoice are set to status `HAL`.\n3. Inserts a row into `CCPTranLog` with transaction type `CA` and error code `CAPTURED`, the note `Message`, total amount `CaptureSum` and the invoice currency.\n4. Returns `Status` = `Success` with the message *Successfully created CA manual booking event for InvoiceNr …*.\n\n**`Success` = 0 (capture failed)**\n1. Updates the invoice: increments `ccpSetFailTries`, sets `CCPNumOfTries`, `ccpSetFailLastTime`, resets `PayedSum` to 0 and `Payed` to NULL, sets `CCPPaymentDone` and `CCPReCharge` to `N`.\n2. Always sets the remaining `ANG` orderlines of the affected orders to `HAL` (independent of `SetRemainingOrdersToHAL`).\n3. Inserts a row into `CCPTranLog` with transaction type `ER` and error code `CAPTURED FAILED`.\n4. Returns `Status` = `Success` with the message *Reset payment data to unpaid for InvoiceNr …*.\n\nIf an error occurs, the transaction is rolled back and a row with `Status` = `Error` and the SQL error message is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Yes | Number of the invoice whose capture result is reported. |\n| `Success` | bit | Yes | Result of the capture at the payment provider. |\n| `PayID` | varchar(50) | Yes | Payment ID of the provider. Required but not used by the code. |\n| `PayCode` | varchar(50) | Yes | Payment code of the provider. Required but not used by the code. |\n| `Message` | varchar(200) | Yes | Free text stored as note (`CCPNote`) in the CCP transaction log. |\n| `CaptureSum` | money | Yes | Captured amount; stored as total amount in the CCP log and passed as `PaidSum` to `pixi_SetInvoicePaid`. |\n| `EventID` | varchar(3) | No | Customer account event used for the manual payment booking when `Success` = 1. Must be a manual, positive event; without it no booking is created. |\n| `SetRemainingOrdersToHAL` | bit | Yes | Only for `Success` = 1: whether remaining `ANG` orderlines of the invoiced orders are set to `HAL`. In the failure branch this always happens. |\n\n- Errors inside `pixi_SetInvoicePaid` (e.g. invoice does not exist, invoice already paid, `EventID` missing or not a manual positive event) are caught and only written to the error log (`log.InsertError`). The call still returns `Status` = `Success` and writes the `CCPTranLog` entry, so a `Success` row does not guarantee that the payment was booked.\n- In the attached `pixi_SetInvoicePaid` the booked amount is the open amount of the invoice in the customer account; `CaptureSum` is not used as booking amount there, only stored in `CCPTranLog`.\n- `PayID` and `PayCode` are required but not used by the code.\n- Any value of `Success` other than 1 (including NULL) takes the failure branch.\n- `CCPNumOfTries` is set from `ccpSetFailTries` + 1, not from its own previous value.\n- If the invoice (or its customer/currency join) is not found, no invoice or orderline is updated, but a log entry with empty references is attempted.\n- Orderline updates use `UpdateEmp` = `API Call PaySetAuth`; invoice updates use `CCP Process`. Lookups use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Returns entries of the customer account (CustomerAccount) by key, by key range with paging, or filtered by creation and/or update date.\n\nReads rows from the `CustomerAccount` table, the customer account ledger. Entries reference invoices, bank lines, DTAUS records and manual bookings. The parameters select exactly one of the following modes, checked in this order:\n\n1. **Create or update date**: `CreateAndUpdateDateFrom` and/or `CreateAndUpdateDateTo` is set. Returns entries with `CustomerAccountKey` > `CustomerAccountKey`.\n - From-condition: `CreateDate` >= from **or** `UpdateDate` >= from.\n - To-condition: `CreateDate` < to **or** `UpdateDate` < to.\n2. **Create date**: `CreateDateFrom` and/or `CreateDateTo` is set. Returns entries with `CustomerAccountKey` > `CustomerAccountKey` and `CreateDate` in the half-open range [from, to).\n3. **Update date**: `UpdateDateFrom` and/or `UpdateDateTo` is set. Same as mode 2, but uses `UpdateDate`.\n4. **Key range**: `RowCount` is passed and no date is set. Returns all entries with `CustomerAccountKey` > `CustomerAccountKey`.\n5. **Single entry**: otherwise. Returns the entry with exactly `CustomerAccountKey`.\n\nModes 1 to 4 are sorted by `CustomerAccountKey` ascending. If `RowCount` is non-zero, the number of returned rows is limited to that value (`SET ROWCOUNT`).\n\nFor keyset paging, pass the last `CustomerAccountKey` you received as `CustomerAccountKey` in the next call.\n\n`ExchRateId` is only filled when the setting `MultiCurrencyEnabled` is `1`; otherwise it is always NULL.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustomerAccountKey` | int | No | In single-entry mode, the key of the entry to return. In all other modes, entries with a key greater than this value are returned (paging start). NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for `CreateDate`. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for `CreateDate`. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for `UpdateDate`. Only used if no create date and no combined date parameter is set. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for `UpdateDate`. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive); matches if `CreateDate` or `UpdateDate` is on or after this value. Takes precedence over all other date parameters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (exclusive); matches if `CreateDate` or `UpdateDate` is before this value. |\n| `RowCount` | int | No | Maximum number of rows to return (0 or NULL = unlimited). If passed (even 0) without date parameters, the call returns the key range above `CustomerAccountKey` instead of a single entry. |\n\n- Reads with `NOLOCK`, so uncommitted data can be returned.\n- If `CustomerAccountKey` is omitted, it is treated as `0`. Called without any parameter, the call therefore runs the single-entry mode for key `0` and normally returns no row. The final \"no data\" branch in the code can never be reached.\n- `RowCount` = `0` still counts as \"passed\" for mode 4. The call then returns **all** entries above the key without a row limit.\n- In the combined date mode the OR logic is loose. An entry matches if any one of its two dates fulfils the from-condition and any one fulfils the to-condition. This is not necessarily the same date.\n- The date parameter groups do not combine. Only the first group that is set (in the order of the modes) is used; the other groups are ignored.\n- The column types of `CustomerAccount` are not part of the supplied code; the column types shown here are partly assumed.\n\nDocumentation: https://pixi-api-docs.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": "Returns entries of the customer account (CustomerAccount) by key, by key range with paging, or filtered by creation and/or update date.\n\nReads rows from the `CustomerAccount` table, the customer account ledger. Entries reference invoices, bank lines, DTAUS records and manual bookings. The parameters select exactly one of the following modes, checked in this order:\n\n1. **Create or update date**: `CreateAndUpdateDateFrom` and/or `CreateAndUpdateDateTo` is set. Returns entries with `CustomerAccountKey` > `CustomerAccountKey`.\n - From-condition: `CreateDate` >= from **or** `UpdateDate` >= from.\n - To-condition: `CreateDate` < to **or** `UpdateDate` < to.\n2. **Create date**: `CreateDateFrom` and/or `CreateDateTo` is set. Returns entries with `CustomerAccountKey` > `CustomerAccountKey` and `CreateDate` in the half-open range [from, to).\n3. **Update date**: `UpdateDateFrom` and/or `UpdateDateTo` is set. Same as mode 2, but uses `UpdateDate`.\n4. **Key range**: `RowCount` is passed and no date is set. Returns all entries with `CustomerAccountKey` > `CustomerAccountKey`.\n5. **Single entry**: otherwise. Returns the entry with exactly `CustomerAccountKey`.\n\nModes 1 to 4 are sorted by `CustomerAccountKey` ascending. If `RowCount` is non-zero, the number of returned rows is limited to that value (`SET ROWCOUNT`).\n\nFor keyset paging, pass the last `CustomerAccountKey` you received as `CustomerAccountKey` in the next call.\n\n`ExchRateId` is only filled when the setting `MultiCurrencyEnabled` is `1`; otherwise it is always NULL.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CustomerAccountKey` | int | No | In single-entry mode, the key of the entry to return. In all other modes, entries with a key greater than this value are returned (paging start). NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for `CreateDate`. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for `CreateDate`. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for `UpdateDate`. Only used if no create date and no combined date parameter is set. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for `UpdateDate`. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive); matches if `CreateDate` or `UpdateDate` is on or after this value. Takes precedence over all other date parameters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (exclusive); matches if `CreateDate` or `UpdateDate` is before this value. |\n| `RowCount` | int | No | Maximum number of rows to return (0 or NULL = unlimited). If passed (even 0) without date parameters, the call returns the key range above `CustomerAccountKey` instead of a single entry. |\n\n- Reads with `NOLOCK`, so uncommitted data can be returned.\n- If `CustomerAccountKey` is omitted, it is treated as `0`. Called without any parameter, the call therefore runs the single-entry mode for key `0` and normally returns no row. The final \"no data\" branch in the code can never be reached.\n- `RowCount` = `0` still counts as \"passed\" for mode 4. The call then returns **all** entries above the key without a row limit.\n- In the combined date mode the OR logic is loose. An entry matches if any one of its two dates fulfils the from-condition and any one fulfils the to-condition. This is not necessarily the same date.\n- The date parameter groups do not combine. Only the first group that is set (in the order of the modes) is used; the other groups are ignored.\n- The column types of `CustomerAccount` are not part of the supplied code; the column types shown here are partly assumed.\n\nDocumentation: https://pixi-api-docs.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": "Masks the stored credit card number and CVC of an order's address and/or stores a payment authorization code on the order.\n\nUpdates credit card related data for the order identified by `OrderNr`. Two independent steps run, depending on the parameters:\n\n1. **Scrambling** (if `ScrambleData` = 1, the default): the address referenced by the order (`OrderHeader.AddrRef`) is looked up. If its card number `ACardNr` does not already contain `****`, it is replaced by `*************` followed by the last four characters of the original number, and the card verification code `CCCVC` is set to `***`.\n2. **Authorization code** (if `AuthCode` is not NULL): the value is written to `OrderHeader.ccpPayID` of the order.\n\nBoth steps can be combined in one call. The procedure returns no result set. It only sets a return code: `0` if at least one row was updated, otherwise `1`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Number of the order (`OrderHeader.OrderNR`) whose credit card data is updated. |\n| `ScrambleData` | bit | No | Whether the card number and CVC of the order's address are masked. |\n| `AuthCode` | varchar(50) | No | Payment authorization code / payment ID stored in `OrderHeader.ccpPayID`. If NULL, the field is not changed. |\n\n- The return code (`0`/`1`) is a T-SQL `RETURN` value and is not delivered as a row; SOAP clients usually cannot see it. There is no explicit error for an unknown `OrderNr` – nothing is updated in that case.\n- The masking affects the address record itself. If the same address is referenced by other orders or the customer, the card data is masked for all of them.\n- Addresses whose `ACardNr` is NULL are not masked (the `NOT LIKE` check is not true for NULL). Already masked numbers (containing `****`) are skipped, so repeated calls are safe.\n- The order lookup uses `NOLOCK`; updates use `ROWLOCK`. No explicit transaction is used, so the two steps are not atomic.\n- To only store an authorization code without masking, pass `ScrambleData` = 0.\n- The helper `util.TempTableDrop` is called to drop the temporary table; its definition is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Creates a replacement order with negative quantities for selected order lines, based on the customer and addresses of an existing order.\n\nCreates a new replacement order and returns the key of the new order header. The work is done by the internal procedure `Pixi_CreateReplacementOrder`.\n\n1. Reads one order line of the order `OrderNr` (`TOP 1` without sort order). Customer, invoice address, shipping address, `LocationID` and `LastOrdLocationID` are taken from it. The current date is used as creation date.\n2. Copies the invoice address of that order line as a new record in `Addresses`. The `Username` is stored as creator and editor. All other fields are copied unchanged.\n3. Reads the shipping country, the VAT liability (`AddrNoChargeVAT`) and the shop of the customer (`CustomerOf`) from the shipping address.\n4. Parses `Orderlines`. Entries are separated by commas. Each entry has the form `OrderlineKey;Quantity`. The quantity is optional; without it the full quantity of the original line is used.\n5. Reads the order type (default `B2C`), shipping costs, tax rates, VAT settings for shipping costs, currency and `Address_Remarks` from the order header of one of the listed order lines. It also looks up the invoice of that line in `Invlines`.\n6. Determines an exchange rate for the currency and the current date and creates a new order header (`Pixi_OrderHeader_Insert`). The order uses the default CCP merchant from setting `DefaultCCPMerchant` and a discount of 0. The external order number is `P` + the new order number.\n7. Inserts one order line per listed original line:\n - quantity negated (`-Quantity` or `-Qty`), status `MIN`;\n - prices, article data, serial number, Charge and best-before date copied;\n - `LocationID` taken from the order `OrderNr`;\n - tax rate recalculated from the order type, the VAT liability, the shipping country and the item's VAT class;\n - line amounts negated and rounded: gross to 2 decimals for `B2C` (else 4), net to 2 decimals for `B2B` (else 4);\n - amount differences negated.\n8. Links the new order to the original invoice with a `pixi.InvoiceAttribute` record (`TypeId` 3, value = new order number).\n9. Returns the new `OrderHeaderKey` and commits the transaction.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Number of the existing order. Customer, invoice address, shipping address and `LocationID` are taken from it. |\n| `Orderlines` | varchar(max) | Yes | Comma-separated list of original order lines in the form `OrderlineKey;Quantity`. The quantity is optional; without it the full quantity of the line is used. The quantity is stored as a negative value. Effectively limited to 8000 characters. |\n| `Username` | varchar(50) | No | User name stored as creator and editor of the new address and order lines. |\n\n- All work runs in one transaction. If an error occurs, the `CATCH` block only rolls back. No error message and no result row reach the caller. An empty response means that no replacement order was created.\n- The result row is sent before the commit. If the internal error counter is not 0, the transaction is rolled back although a key has already been returned.\n- `@Orderlines` is passed to a `varchar(8000)` parameter of the internal procedure. Longer lists are truncated.\n- The listed order lines are matched only by `OrderlineKey`. The code does not check that they belong to `OrderNr`. Customer and addresses come from `OrderNr`; order type, tax rates, currency and the linked invoice come from one of the listed lines. Pass only lines of the same order.\n- Which line of `OrderNr` is used for customer and addresses is not defined (`TOP 1` without `ORDER BY`).\n- If a listed line has no invoice, the link record in `pixi.InvoiceAttribute` is written with an empty `InvoiceId`, or the insert fails depending on table constraints. A failure rolls back the whole call.\n- Order lines are only created for items that exist in `items`.\n- Reads use `NOLOCK`. `CONTEXT_INFO` is set to `0x10136` while the order lines are inserted, presumably to control triggers.\n- `Pixi_OrderHeader_Insert`, `pixi.GetExchRateID`, `fpixi_GetSetting`, `fPixi_GetCommaSplit` and `fPixi_GetVATRate` are not attached. Their exact behaviour, including how the order header is written, is not documented here.\n\nDocumentation: https://pixi-api-docs.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": "Creates a replacement order with negative quantities for selected order lines, based on the customer and addresses of an existing order.\n\nCreates a new replacement order and returns the key of the new order header. The work is done by the internal procedure `Pixi_CreateReplacementOrder`.\n\n1. Reads one order line of the order `OrderNr` (`TOP 1` without sort order). Customer, invoice address, shipping address, `LocationID` and `LastOrdLocationID` are taken from it. The current date is used as creation date.\n2. Copies the invoice address of that order line as a new record in `Addresses`. The `Username` is stored as creator and editor. All other fields are copied unchanged.\n3. Reads the shipping country, the VAT liability (`AddrNoChargeVAT`) and the shop of the customer (`CustomerOf`) from the shipping address.\n4. Parses `Orderlines`. Entries are separated by commas. Each entry has the form `OrderlineKey;Quantity`. The quantity is optional; without it the full quantity of the original line is used.\n5. Reads the order type (default `B2C`), shipping costs, tax rates, VAT settings for shipping costs, currency and `Address_Remarks` from the order header of one of the listed order lines. It also looks up the invoice of that line in `Invlines`.\n6. Determines an exchange rate for the currency and the current date and creates a new order header (`Pixi_OrderHeader_Insert`). The order uses the default CCP merchant from setting `DefaultCCPMerchant` and a discount of 0. The external order number is `P` + the new order number.\n7. Inserts one order line per listed original line:\n - quantity negated (`-Quantity` or `-Qty`), status `MIN`;\n - prices, article data, serial number, Charge and best-before date copied;\n - `LocationID` taken from the order `OrderNr`;\n - tax rate recalculated from the order type, the VAT liability, the shipping country and the item's VAT class;\n - line amounts negated and rounded: gross to 2 decimals for `B2C` (else 4), net to 2 decimals for `B2B` (else 4);\n - amount differences negated.\n8. Links the new order to the original invoice with a `pixi.InvoiceAttribute` record (`TypeId` 3, value = new order number).\n9. Returns the new `OrderHeaderKey` and commits the transaction.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Number of the existing order. Customer, invoice address, shipping address and `LocationID` are taken from it. |\n| `Orderlines` | varchar(max) | Yes | Comma-separated list of original order lines in the form `OrderlineKey;Quantity`. The quantity is optional; without it the full quantity of the line is used. The quantity is stored as a negative value. Effectively limited to 8000 characters. |\n| `Username` | varchar(50) | No | User name stored as creator and editor of the new address and order lines. |\n\n- All work runs in one transaction. If an error occurs, the `CATCH` block only rolls back. No error message and no result row reach the caller. An empty response means that no replacement order was created.\n- The result row is sent before the commit. If the internal error counter is not 0, the transaction is rolled back although a key has already been returned.\n- `@Orderlines` is passed to a `varchar(8000)` parameter of the internal procedure. Longer lists are truncated.\n- The listed order lines are matched only by `OrderlineKey`. The code does not check that they belong to `OrderNr`. Customer and addresses come from `OrderNr`; order type, tax rates, currency and the linked invoice come from one of the listed lines. Pass only lines of the same order.\n- Which line of `OrderNr` is used for customer and addresses is not defined (`TOP 1` without `ORDER BY`).\n- If a listed line has no invoice, the link record in `pixi.InvoiceAttribute` is written with an empty `InvoiceId`, or the insert fails depending on table constraints. A failure rolls back the whole call.\n- Order lines are only created for items that exist in `items`.\n- Reads use `NOLOCK`. `CONTEXT_INFO` is set to `0x10136` while the order lines are inserted, presumably to control triggers.\n- `Pixi_OrderHeader_Insert`, `pixi.GetExchRateID`, `fpixi_GetSetting`, `fPixi_GetCommaSplit` and `fPixi_GetVATRate` are not attached. Their exact behaviour, including how the order header is written, is not documented here.\n\nDocumentation: https://pixi-api-docs.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": "Creates a replacement order for one or more return case lines, logs the request in the return case history and returns the new order number.\n\nCreates a replacement (Ersatzauftrag) for returned items, based on the return case lines passed in `ReturnLines`.\n\n**Input format**: `ReturnLines` is a list of `RET_LINE_ID` values separated by `,` or `;` (e.g. `1024,1025`). Semicolons are converted to commas, the string is trimmed and a trailing comma is added if missing.\n\n**Steps**\n\n1. **VAT check**: For the *first* return line only, the shipping country of the related Rechnung (`Invoices.ShipAdrRef` → `Addresses.Country`) and the country flag `ForceCountryVAT` are determined. If no VAT rate valid today exists in `VATs` for that country:\n - with `ForceCountryVAT = 1` an error is raised and nothing is changed;\n - otherwise `Pixi_InsertDefaultVATRateForCountry` is executed to derive a default VAT rate from the default country.\n2. **History and status**: For every return line a row is inserted into `RET_CASES_HISTORY` (`ACTION_TYPE` = 8, text from the translation key `ReplacementRequestAPI` in language `Language_Id`, with `%ItemName%` replaced by the Artikel name). The line status in `RET_CASE_LINES` is set to `RPL` (processing replacement). The editor is stored as `Employee + ' (API)'`, or `API` if `Employee` is empty.\n3. **Replacement order**: `Pixi_CreateReplacementForReturnLines` is called with all lines. Within its own transaction it\n - collects the original order lines (only order lines with status `AUS`, only return lines with status `RPL`) with the returned quantity,\n - sets the return lines to status `SHI` (waiting for shipping),\n - creates addresses for the customer and shop and creates the replacement order via `Pixi_CreateReplacementOrder`,\n - writes the `RET_LINE_ID` into `Orderlines.BackorderRef` of the new order lines with the same Artikel, so that the return case can be closed at ship-out.\n4. The new order number is returned as a single row (`NewOrderNr`), in the output parameter `NewOrderNr` and as the procedure return value.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ReturnLines` | varchar(max) | Yes | List of return case line IDs (`RET_LINE_ID`) separated by `,` or `;`, for which a replacement order is created. |\n| `Employee` | varchar(50) | No | Name of the employee; stored as ` (API)` as editor/creator. If NULL, `API` is used. |\n| `NewOrderNr` | int | No | Output: order number of the created replacement order. |\n| `Language_Id` | int | Yes | Language ID used to translate the history text (translation key `ReplacementRequestAPI`). |\n\n- **No overall transaction**: the history rows and the status change to `RPL` are written *before* and outside the transaction of `Pixi_CreateReplacementForReturnLines`. If the replacement creation fails, these changes remain.\n- The VAT check uses only the first return line. Customer, shop and location of the new order are taken from the last processed line, so all lines should belong to the same customer/Rechnung.\n- If the first return line does not exist, the country cannot be determined and the call fails with an error from `Pixi_InsertDefaultVATRateForCountry` (unknown country code).\n- Return lines whose original order line is not in status `AUS` are skipped; if no line qualifies, the inner procedure raises ` Wrong Data `. Errors from the inner procedure are logged via `log.InsertError` and re-raised via `sp_Exception_ReRaise` (not attached; exact message format unknown).\n- **Pitfalls in list parsing**: IDs are removed from the list by text replacement of `ID,`. Pass plain IDs without spaces or leading zeros. An empty `ReturnLines` value, or IDs that are suffixes of other IDs in the list (e.g. `12,112`), can lead to parsing errors or an endless loop.\n- Lookups use `NOLOCK`.\n- The header comment of the procedure (\"Checks pixi* user credentials\") does not match its function.\n- The VAT error message contains the literal placeholders `[Order/Invoice/...]` and `{shipping country}`; they are not filled in.\n\nDocumentation: https://pixi-api-docs.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": "Creates a replacement order for one or more return case lines, logs the request in the return case history and returns the new order number.\n\nCreates a replacement (Ersatzauftrag) for returned items, based on the return case lines passed in `ReturnLines`.\n\n**Input format**: `ReturnLines` is a list of `RET_LINE_ID` values separated by `,` or `;` (e.g. `1024,1025`). Semicolons are converted to commas, the string is trimmed and a trailing comma is added if missing.\n\n**Steps**\n\n1. **VAT check**: For the *first* return line only, the shipping country of the related Rechnung (`Invoices.ShipAdrRef` → `Addresses.Country`) and the country flag `ForceCountryVAT` are determined. If no VAT rate valid today exists in `VATs` for that country:\n - with `ForceCountryVAT = 1` an error is raised and nothing is changed;\n - otherwise `Pixi_InsertDefaultVATRateForCountry` is executed to derive a default VAT rate from the default country.\n2. **History and status**: For every return line a row is inserted into `RET_CASES_HISTORY` (`ACTION_TYPE` = 8, text from the translation key `ReplacementRequestAPI` in language `Language_Id`, with `%ItemName%` replaced by the Artikel name). The line status in `RET_CASE_LINES` is set to `RPL` (processing replacement). The editor is stored as `Employee + ' (API)'`, or `API` if `Employee` is empty.\n3. **Replacement order**: `Pixi_CreateReplacementForReturnLines` is called with all lines. Within its own transaction it\n - collects the original order lines (only order lines with status `AUS`, only return lines with status `RPL`) with the returned quantity,\n - sets the return lines to status `SHI` (waiting for shipping),\n - creates addresses for the customer and shop and creates the replacement order via `Pixi_CreateReplacementOrder`,\n - writes the `RET_LINE_ID` into `Orderlines.BackorderRef` of the new order lines with the same Artikel, so that the return case can be closed at ship-out.\n4. The new order number is returned as a single row (`NewOrderNr`), in the output parameter `NewOrderNr` and as the procedure return value.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ReturnLines` | varchar(max) | Yes | List of return case line IDs (`RET_LINE_ID`) separated by `,` or `;`, for which a replacement order is created. |\n| `Employee` | varchar(50) | No | Name of the employee; stored as ` (API)` as editor/creator. If NULL, `API` is used. |\n| `NewOrderNr` | int | No | Output: order number of the created replacement order. |\n| `Language_Id` | int | Yes | Language ID used to translate the history text (translation key `ReplacementRequestAPI`). |\n\n- **No overall transaction**: the history rows and the status change to `RPL` are written *before* and outside the transaction of `Pixi_CreateReplacementForReturnLines`. If the replacement creation fails, these changes remain.\n- The VAT check uses only the first return line. Customer, shop and location of the new order are taken from the last processed line, so all lines should belong to the same customer/Rechnung.\n- If the first return line does not exist, the country cannot be determined and the call fails with an error from `Pixi_InsertDefaultVATRateForCountry` (unknown country code).\n- Return lines whose original order line is not in status `AUS` are skipped; if no line qualifies, the inner procedure raises ` Wrong Data `. Errors from the inner procedure are logged via `log.InsertError` and re-raised via `sp_Exception_ReRaise` (not attached; exact message format unknown).\n- **Pitfalls in list parsing**: IDs are removed from the list by text replacement of `ID,`. Pass plain IDs without spaces or leading zeros. An empty `ReturnLines` value, or IDs that are suffixes of other IDs in the list (e.g. `12,112`), can lead to parsing errors or an endless loop.\n- Lookups use `NOLOCK`.\n- The header comment of the procedure (\"Checks pixi* user credentials\") does not match its function.\n- The VAT error message contains the literal placeholders `[Order/Invoice/...]` and `{shipping country}`; they are not filled in.\n\nDocumentation: https://pixi-api-docs.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": "Returns the POS (point of sale) sales lines of a date range, optionally limited to one location, with item, supplier and price data.\n\nBuilds a report of point-of-sale sales. According to the code comment, it was created for a specific customer (ERK).\n\n- Each row is one POS line from `POSitem2`. It is joined to its POS header (`POSheader2`) and to the item (`items`). The supplier (`Suppliers`) is joined optionally through the item's `SupplNr`, so `SupplName` can be empty.\n- `LocID` filters on the location of the POS header (`PHlocID`). An empty string or `NULL` means all locations.\n- `DateFrom` and `DateTo` filter on the POS header date `PHdate` with an inclusive `BETWEEN`. A value that is `NULL` or earlier than 1990-01-01 is replaced by the current date and time.\n- The report shows the list sales price of the item (`VK_List`) next to the price actually charged on the POS line (`VK_Real`). It also returns the purchase price of the supplier and the quantity.\n- Rows are sorted by POS header key in ascending order, so they appear in the order the POS receipts were created.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocID` | char(3) | No | Location ID of the POS sales. An empty string or `NULL` returns sales of all locations. |\n| `DateFrom` | datetime | No | Start of the period (inclusive), compared with the POS header date. `NULL` or a value before 1990-01-01 is replaced by the current date and time. |\n| `DateTo` | datetime | No | End of the period (inclusive), compared with the POS header date. `NULL` or a value before 1990-01-01 is replaced by the current date and time. |\n\n- If `DateFrom` and `DateTo` are both omitted, both are set to the current time, which is only milliseconds apart. The result is then practically always empty, so always pass both dates.\n- `BETWEEN` includes both ends. If `DateTo` is passed as a date without a time (midnight), sales later on that day are not included. To cover the whole day, pass the next day or a time of 23:59:59.\n- All tables are read with `NOLOCK`, so uncommitted data can appear in the result.\n- There is no paging. Large date ranges can return many rows.\n\nDocumentation: https://pixi-api-docs.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": "Returns the POS (point of sale) sales lines of a date range, optionally limited to one location, with item, supplier and price data.\n\nBuilds a report of point-of-sale sales. According to the code comment, it was created for a specific customer (ERK).\n\n- Each row is one POS line from `POSitem2`. It is joined to its POS header (`POSheader2`) and to the item (`items`). The supplier (`Suppliers`) is joined optionally through the item's `SupplNr`, so `SupplName` can be empty.\n- `LocID` filters on the location of the POS header (`PHlocID`). An empty string or `NULL` means all locations.\n- `DateFrom` and `DateTo` filter on the POS header date `PHdate` with an inclusive `BETWEEN`. A value that is `NULL` or earlier than 1990-01-01 is replaced by the current date and time.\n- The report shows the list sales price of the item (`VK_List`) next to the price actually charged on the POS line (`VK_Real`). It also returns the purchase price of the supplier and the quantity.\n- Rows are sorted by POS header key in ascending order, so they appear in the order the POS receipts were created.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocID` | char(3) | No | Location ID of the POS sales. An empty string or `NULL` returns sales of all locations. |\n| `DateFrom` | datetime | No | Start of the period (inclusive), compared with the POS header date. `NULL` or a value before 1990-01-01 is replaced by the current date and time. |\n| `DateTo` | datetime | No | End of the period (inclusive), compared with the POS header date. `NULL` or a value before 1990-01-01 is replaced by the current date and time. |\n\n- If `DateFrom` and `DateTo` are both omitted, both are set to the current time, which is only milliseconds apart. The result is then practically always empty, so always pass both dates.\n- `BETWEEN` includes both ends. If `DateTo` is passed as a date without a time (midnight), sales later on that day are not included. To cover the whole day, pass the next day or a time of 23:59:59.\n- All tables are read with `NOLOCK`, so uncommitted data can appear in the result.\n- There is no paging. Large date ranges can return many rows.\n\nDocumentation: https://pixi-api-docs.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": "Returns the quantity sold of one item per invoice month and year, optionally restricted to one shop.\n\nBuilds a monthly sales report for a single item based on invoice lines.\n\n- Reads invoice lines from the view `PV_InvlinesRep` and joins them with the invoices in `PV_Rechnungen` via the invoice number.\n- Filters on the internal item number `ItemNrInt`.\n- If `ShopID` is given, only invoice lines of that shop are counted; if it is omitted or `NULL`, all shops are included.\n- Groups by invoice month and invoice year and sums the sold quantity (`QtySold`).\n- Rows are sorted chronologically: by year ascending, then month ascending.\n\nOnly months in which the item was invoiced appear in the result; months without sales are not returned as zero rows.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | Yes | Internal item number of the item whose sales are reported. |\n| `ShopID` | varchar(3) | No | Optional shop ID. If set, only invoice lines of this shop are summed; `NULL` includes all shops. |\n\n- According to the header comment the procedure was created for a specific customer (JAL).\n- Both views are read `WITH (NOLOCK)`, so the figures may include uncommitted data.\n- The definitions of `PV_InvlinesRep` and `PV_Rechnungen` are not attached; the exact meaning of `QtySold` (e.g. whether credit notes reduce it) and the data types of the month/year columns depend on these views.\n- There is no date range filter; the full invoice history of the item is aggregated, which can be slow for items with many invoice lines.\n- An unknown `ItemNrInt` returns an empty result set, not an error.\n\nDocumentation: https://pixi-api-docs.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": "Returns the quantity sold of one item per invoice month and year, optionally restricted to one shop.\n\nBuilds a monthly sales report for a single item based on invoice lines.\n\n- Reads invoice lines from the view `PV_InvlinesRep` and joins them with the invoices in `PV_Rechnungen` via the invoice number.\n- Filters on the internal item number `ItemNrInt`.\n- If `ShopID` is given, only invoice lines of that shop are counted; if it is omitted or `NULL`, all shops are included.\n- Groups by invoice month and invoice year and sums the sold quantity (`QtySold`).\n- Rows are sorted chronologically: by year ascending, then month ascending.\n\nOnly months in which the item was invoiced appear in the result; months without sales are not returned as zero rows.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemNrInt` | varchar(50) | Yes | Internal item number of the item whose sales are reported. |\n| `ShopID` | varchar(3) | No | Optional shop ID. If set, only invoice lines of this shop are summed; `NULL` includes all shops. |\n\n- According to the header comment the procedure was created for a specific customer (JAL).\n- Both views are read `WITH (NOLOCK)`, so the figures may include uncommitted data.\n- The definitions of `PV_InvlinesRep` and `PV_Rechnungen` are not attached; the exact meaning of `QtySold` (e.g. whether credit notes reduce it) and the data types of the month/year columns depend on these views.\n- There is no date range filter; the full invoice history of the item is aggregated, which can be slow for items with many invoice lines.\n- An unknown `ItemNrInt` returns an empty result set, not an error.\n\nDocumentation: https://pixi-api-docs.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": "Returns monthly package statistics from invoices for billing: total packages, single-item packages and packages flagged as 1SS, with size classes.\n\nRuns the internal report procedure `Report_1SS`, which is used for billing purposes. The call takes no parameters.\n\nHow the report is built:\n\n1. Every invoice (table `invoices`) with `total >= 0` counts as one package. Credit notes with a negative total are excluded.\n2. Invoices are grouped by calendar month, using the month offset between `invdate` and the current date. `Month` and `Year` come from the latest invoice date in each group.\n3. For each month the report counts:\n - `Packages`: all invoices.\n - `Packages_1item`: invoices whose invoice lines (`invlines`) add up to a total `itemqty` of exactly 1.\n - `Packages_1ss`: invoices whose flag column `1SS` equals 1.\n4. Derived values:\n - `Packages_1item_Percentage`: share of single-item packages. The ratio is rounded to two decimals and then multiplied by 100, so the result is a whole percent.\n - `Class_1item` / `Class_1SS`: size class of the count. Up to 1000 is `Small`, up to 2500 `Medium`, up to 5000 `Large`, up to 10000 `Extra Large`, above that `XXL`.\n - `Extra10000_1Item` / `Extra10000_1SS`: number of complete blocks of 10,000 (integer division).\n\nThere is no date filter, so every month in the invoice history is returned. Rows are sorted by `Year`, then `Month`, ascending.\n\n- All reads use `NOLOCK`, so the figures can include uncommitted data.\n- The report scans the complete `invoices` and `invlines` tables without a date filter. On large databases this can be slow.\n- An invoice counts as a single-item package if the sum of `itemqty` over all its lines is 1. This is also true when several lines add up to 1. Invoices without any lines never count as single-item packages.\n- Invoices with a NULL `invdate` form a separate group, in which `Month` and `Year` are NULL.\n\nDocumentation: https://pixi-api-docs.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": "Returns monthly package statistics from invoices for billing: total packages, single-item packages and packages flagged as 1SS, with size classes.\n\nRuns the internal report procedure `Report_1SS`, which is used for billing purposes. The call takes no parameters.\n\nHow the report is built:\n\n1. Every invoice (table `invoices`) with `total >= 0` counts as one package. Credit notes with a negative total are excluded.\n2. Invoices are grouped by calendar month, using the month offset between `invdate` and the current date. `Month` and `Year` come from the latest invoice date in each group.\n3. For each month the report counts:\n - `Packages`: all invoices.\n - `Packages_1item`: invoices whose invoice lines (`invlines`) add up to a total `itemqty` of exactly 1.\n - `Packages_1ss`: invoices whose flag column `1SS` equals 1.\n4. Derived values:\n - `Packages_1item_Percentage`: share of single-item packages. The ratio is rounded to two decimals and then multiplied by 100, so the result is a whole percent.\n - `Class_1item` / `Class_1SS`: size class of the count. Up to 1000 is `Small`, up to 2500 `Medium`, up to 5000 `Large`, up to 10000 `Extra Large`, above that `XXL`.\n - `Extra10000_1Item` / `Extra10000_1SS`: number of complete blocks of 10,000 (integer division).\n\nThere is no date filter, so every month in the invoice history is returned. Rows are sorted by `Year`, then `Month`, ascending.\n\n- All reads use `NOLOCK`, so the figures can include uncommitted data.\n- The report scans the complete `invoices` and `invlines` tables without a date filter. On large databases this can be slow.\n- An invoice counts as a single-item package if the sum of `itemqty` over all its lines is 1. This is also true when several lines add up to 1. Invoices without any lines never count as single-item packages.\n- Invoices with a NULL `invdate` form a separate group, in which `Month` and `Year` are NULL.\n\nDocumentation: https://pixi-api-docs.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": "Returns the users currently logged in to Pixi that count against licences, optionally including mobile sessions.\n\nLists the active, licence-relevant logins from the latest login snapshot in `UsersLoggedIn`.\n\n1. The procedure first determines the latest snapshot timestamp (`Tag`). It considers session types 1 and 2 (desktop/web), or types 1, 2, 4 and 5 if `IncludeMobileLicences` = 1.\n2. It then delegates to the internal procedure `Pixi_ShowConcurrentUsersForTag` in distinct mode. That procedure recalculates the timestamp as the latest `Tag` of session types 1 and 2 only. If there is no entry, it uses the current date and time.\n3. Desktop/web sessions (types 1, 2) with that `Tag` are included only if all of these apply:\n - their `AppName` is a client in `ExeClientVersion` with `LicenceNeeded` = 1;\n - the licence manager for that client type is enabled: setting `pixiLicencesManager` for desktop (`UserActiveSessionTypeRef` = 1) or `pixiLicencesManagerWeb` for web (`UserActiveSessionTypeRef` = 2).\n4. If `IncludeMobileLicences` = 1, mobile sessions (types 4, 5) with the same `Tag` are added.\n5. Computers listed in `MasterUsers` and the Pixi user `master` are always excluded.\n6. Rows are grouped per session and Pixi user, so each session appears once. `AppName` is `Desktop/Web` or `Mobile`. `ComputerName` is the maximum computer name of the session.\n\n`NrOfLicences` contains the value of the setting `pixiLicences` if `pixiLicencesManager` is `1`; otherwise it is `0`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `IncludeMobileLicences` | bit | No | Whether mobile sessions (session types 4 and 5) are included in the result. |\n\n- All reads use `NOLOCK`, so results may include uncommitted data.\n- The timestamp computed by this procedure is overwritten inside `Pixi_ShowConcurrentUsersForTag`, which always uses the latest `Tag` of session types 1 and 2. Mobile sessions therefore appear only if their `Tag` equals that desktop/web timestamp.\n- If no licence manager setting (`pixiLicencesManager`, `pixiLicencesManagerWeb`) is enabled, no desktop/web sessions are returned.\n- `UsersCount` is always `0`, because the internal procedure is called with its default.\n- The result has no guaranteed sort order.\n- If the setting `pixiLicencesManager` does not exist (NULL), `NrOfLicences` is not reset to 0. It then reflects `pixiLicences`, as read by `fpixi_GetSetting` (definition not attached).\n\nDocumentation: https://pixi-api-docs.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": "Returns the users currently logged in to Pixi that count against licences, optionally including mobile sessions.\n\nLists the active, licence-relevant logins from the latest login snapshot in `UsersLoggedIn`.\n\n1. The procedure first determines the latest snapshot timestamp (`Tag`). It considers session types 1 and 2 (desktop/web), or types 1, 2, 4 and 5 if `IncludeMobileLicences` = 1.\n2. It then delegates to the internal procedure `Pixi_ShowConcurrentUsersForTag` in distinct mode. That procedure recalculates the timestamp as the latest `Tag` of session types 1 and 2 only. If there is no entry, it uses the current date and time.\n3. Desktop/web sessions (types 1, 2) with that `Tag` are included only if all of these apply:\n - their `AppName` is a client in `ExeClientVersion` with `LicenceNeeded` = 1;\n - the licence manager for that client type is enabled: setting `pixiLicencesManager` for desktop (`UserActiveSessionTypeRef` = 1) or `pixiLicencesManagerWeb` for web (`UserActiveSessionTypeRef` = 2).\n4. If `IncludeMobileLicences` = 1, mobile sessions (types 4, 5) with the same `Tag` are added.\n5. Computers listed in `MasterUsers` and the Pixi user `master` are always excluded.\n6. Rows are grouped per session and Pixi user, so each session appears once. `AppName` is `Desktop/Web` or `Mobile`. `ComputerName` is the maximum computer name of the session.\n\n`NrOfLicences` contains the value of the setting `pixiLicences` if `pixiLicencesManager` is `1`; otherwise it is `0`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `IncludeMobileLicences` | bit | No | Whether mobile sessions (session types 4 and 5) are included in the result. |\n\n- All reads use `NOLOCK`, so results may include uncommitted data.\n- The timestamp computed by this procedure is overwritten inside `Pixi_ShowConcurrentUsersForTag`, which always uses the latest `Tag` of session types 1 and 2. Mobile sessions therefore appear only if their `Tag` equals that desktop/web timestamp.\n- If no licence manager setting (`pixiLicencesManager`, `pixiLicencesManagerWeb`) is enabled, no desktop/web sessions are returned.\n- `UsersCount` is always `0`, because the internal procedure is called with its default.\n- The result has no guaranteed sort order.\n- If the setting `pixiLicencesManager` does not exist (NULL), `NrOfLicences` is not reset to 0. It then reflects `pixiLicences`, as read by `fpixi_GetSetting` (definition not attached).\n\nDocumentation: https://pixi-api-docs.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": "Returns invoiced item lines with customer, country, net line total, currency and last sale date, filtered by item, shop, payment type, customer and invoice date.\n\nSales report on invoice line level. The header comment describes it as a *customer evaluation for customer BAF*, so it was written for a specific installation.\n\n**Parameter handling**\n- `ItemNrSuppl`, `ShopID`, `PaymentType` and `CustomerNrExternal`: an empty string is treated like `NULL`, which means *no filter*.\n- `DateFrom`: if it is `NULL` or earlier than 1990-01-01, the current date and time minus one day is used.\n- `DateTo`: if it is `NULL` or earlier than 1990-01-01, the current date and time is used.\n\n**Filters** (all combined with AND)\n- `ItemNrSuppl` must match the item's supplier item number (`Items.ItemNrSuppl`).\n- `ShopID` must match the invoice shop (`Invoices.InvShopID`).\n- `PaymentType` must match the payment type stored on the **billing address** (`Addresses.APayment`), not the payment type of the invoice.\n- `CustomerNrExternal` must match the external customer number of the billing address.\n- The invoice date must satisfy `InvDate >= DateFrom` and `InvDate < DateTo`. The upper bound is exclusive.\n\n**Output**\nOne row is returned per invoice line. Each row contains:\n- the item's supplier number and EAN;\n- company (`CareOf`), name and external customer number from the billing address;\n- the quantity;\n- the net line total;\n- the ISO3 country codes of the billing address and the shipping address;\n- the currency code of the invoice;\n- `LastSaleDate`: the latest invoice date of any invoice that contains the item.\n\nThe net line total is calculated like this: the unit price of the line is divided by `1 + VAT rate`, rounded to 2 decimals and then multiplied by the quantity. The VAT rate is the invoice's high rate for VAT code `H`, the low rate for `L`, and 0 for any other code.\n\nThe result has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number (`Items.ItemNrSuppl`) to filter by. `NULL` or an empty string means all items. |\n| `ShopID` | varchar(3) | No | Shop ID of the invoice (`Invoices.InvShopID`). `NULL` or an empty string means all shops. |\n| `PaymentType` | char(1) | No | Payment type code compared with `Addresses.APayment` of the billing address. `NULL` or an empty string means no filter. |\n| `CustomerNrExternal` | varchar(60) | No | External customer number of the billing address. `NULL` or an empty string means all customers. |\n| `DateFrom` | datetime | No | Start of the invoice date range (inclusive). If it is `NULL` or before 1990-01-01, the current date and time minus one day is used. |\n| `DateTo` | datetime | No | End of the invoice date range (exclusive). If it is `NULL` or before 1990-01-01, the current date and time is used. |\n\n- All tables are read with `NOLOCK`, so uncommitted data can appear in the result.\n- Without date parameters, the report covers exactly the last 24 hours up to the moment of the call. This is a rolling window, not the previous calendar day. To get whole days, pass `DateTo` as midnight of the day after the last day you want.\n- All joins are inner joins. Lines are left out if the invoice has no billing or shipping address, if a country cannot be resolved in `Countries`, or if the invoice currency is not found in `pixi.Currency`.\n- `LastSaleDate` ignores all filters, including the date range. It always shows the latest invoice date of the item across all invoices. Because it is a correlated subquery per row, large date ranges can be slow.\n- The net calculation uses `VATHighPerc` / `VATLowPerc` directly as `1 + rate`. The result is only correct if these rates are stored as fractions (e.g. 0.19).\n- The unit net price is rounded before it is multiplied by the quantity, so small rounding differences against the invoice totals are possible.\n\nDocumentation: https://pixi-api-docs.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": "Returns invoiced item lines with customer, country, net line total, currency and last sale date, filtered by item, shop, payment type, customer and invoice date.\n\nSales report on invoice line level. The header comment describes it as a *customer evaluation for customer BAF*, so it was written for a specific installation.\n\n**Parameter handling**\n- `ItemNrSuppl`, `ShopID`, `PaymentType` and `CustomerNrExternal`: an empty string is treated like `NULL`, which means *no filter*.\n- `DateFrom`: if it is `NULL` or earlier than 1990-01-01, the current date and time minus one day is used.\n- `DateTo`: if it is `NULL` or earlier than 1990-01-01, the current date and time is used.\n\n**Filters** (all combined with AND)\n- `ItemNrSuppl` must match the item's supplier item number (`Items.ItemNrSuppl`).\n- `ShopID` must match the invoice shop (`Invoices.InvShopID`).\n- `PaymentType` must match the payment type stored on the **billing address** (`Addresses.APayment`), not the payment type of the invoice.\n- `CustomerNrExternal` must match the external customer number of the billing address.\n- The invoice date must satisfy `InvDate >= DateFrom` and `InvDate < DateTo`. The upper bound is exclusive.\n\n**Output**\nOne row is returned per invoice line. Each row contains:\n- the item's supplier number and EAN;\n- company (`CareOf`), name and external customer number from the billing address;\n- the quantity;\n- the net line total;\n- the ISO3 country codes of the billing address and the shipping address;\n- the currency code of the invoice;\n- `LastSaleDate`: the latest invoice date of any invoice that contains the item.\n\nThe net line total is calculated like this: the unit price of the line is divided by `1 + VAT rate`, rounded to 2 decimals and then multiplied by the quantity. The VAT rate is the invoice's high rate for VAT code `H`, the low rate for `L`, and 0 for any other code.\n\nThe result has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number (`Items.ItemNrSuppl`) to filter by. `NULL` or an empty string means all items. |\n| `ShopID` | varchar(3) | No | Shop ID of the invoice (`Invoices.InvShopID`). `NULL` or an empty string means all shops. |\n| `PaymentType` | char(1) | No | Payment type code compared with `Addresses.APayment` of the billing address. `NULL` or an empty string means no filter. |\n| `CustomerNrExternal` | varchar(60) | No | External customer number of the billing address. `NULL` or an empty string means all customers. |\n| `DateFrom` | datetime | No | Start of the invoice date range (inclusive). If it is `NULL` or before 1990-01-01, the current date and time minus one day is used. |\n| `DateTo` | datetime | No | End of the invoice date range (exclusive). If it is `NULL` or before 1990-01-01, the current date and time is used. |\n\n- All tables are read with `NOLOCK`, so uncommitted data can appear in the result.\n- Without date parameters, the report covers exactly the last 24 hours up to the moment of the call. This is a rolling window, not the previous calendar day. To get whole days, pass `DateTo` as midnight of the day after the last day you want.\n- All joins are inner joins. Lines are left out if the invoice has no billing or shipping address, if a country cannot be resolved in `Countries`, or if the invoice currency is not found in `pixi.Currency`.\n- `LastSaleDate` ignores all filters, including the date range. It always shows the latest invoice date of the item across all invoices. Because it is a correlated subquery per row, large date ranges can be slow.\n- The net calculation uses `VATHighPerc` / `VATLowPerc` directly as `1 + rate`. The result is only correct if these rates are stored as fractions (e.g. 0.19).\n- The unit net price is rounded before it is multiplied by the quantity, so small rounding differences against the invoice totals are possible.\n\nDocumentation: https://pixi-api-docs.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": "Returns the order lines that can be shipped from current stock, either as line details or as totals (orders, value, shipping cost, picks), optionally per location.\n\nEvaluates open orders and checks, line by line, whether there is enough stock to ship them. It then returns either the shippable lines or summary figures.\n\n**Candidate orders and lines**\n- Only order lines with status `ANG` or `EIN`, a non-NULL `ItemRef` and `Qty` > 0 are considered.\n- The order's customer must belong to `ShopId` (`Customers.CustomerOf`). An empty `ShopId` means all shops.\n- Orders are excluded if the invoice address (`AddrRef`) or the shipping address (`ShipAdrRef`) is locked (`ASlocked = 'Y'`).\n- Orders are also excluded if the order itself is locked (`OhSLocked = 'Y'`).\n- Unless `IncludeOrdersWithAnyShipDate = 1`, only orders with no `Shipdate` or a `Shipdate` before tomorrow (today or earlier) are included.\n\n**Stock check**\nThe internal procedure `pixi_CalculateStockForOrderLines` sets a shippable flag on each candidate line. It runs with zero-stock items skipped, so lines of items without stock are not shippable.\n- The calculation takes into account the stock in locations with `SpecialStock = 0`, existing reservations and earlier unreserved order lines.\n- Lines with status `EIN` always count as shippable.\n- An order counts as *partial or unshippable* if at least one of its candidate lines is not shippable.\n\n**Filter by delivery mode**\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 0`: only lines of orders whose candidate lines are all shippable (complete orders).\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 1`: all shippable lines, from complete and from partial orders.\n- `OnlyPartDelivery = 1`: only the shippable lines of partial orders. `IncludePartDelivery` is ignored in this case.\n\n**Currency**\nIf the setting `MultiCurrencyEnabled` is 1, `Price` and `ShipCost` are converted into the database currency. The conversion uses the exchange rate of the database rate source that has the same currency and date as the order's exchange rate. If no such rate exists, the values are not converted. `dbCurrency` then contains the database currency code; otherwise it is NULL.\n\n**Output**\nExactly one result set is returned, chosen by `ViewDetails` and `PerLocation`:\n- `ViewDetails = 1`: one row per shippable line, sorted by `OrderNr` and `OrderlineRef`. With `PerLocation = 1` the column `LocationId` is added.\n- `ViewDetails = 0`, `PerLocation = 0`: one total row.\n- `ViewDetails = 0`, `PerLocation = 1`: one total row per location.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ViewDetails` | bit | No | 1 returns one row per shippable line; 0 (or NULL) returns totals. |\n| `IncludePartDelivery` | bit | No | 1 includes the shippable lines of partial orders in addition to complete orders. Ignored when `OnlyPartDelivery = 1`. |\n| `OnlyPartDelivery` | bit | No | 1 returns only the shippable lines of orders that cannot be shipped completely. |\n| `ShopId` | varchar(3) | No | Restricts the result to orders of customers of this shop (`Customers.CustomerOf`). Empty means all shops. |\n| `IncludeOrdersWithAnyShipDate` | bit | No | 1 also includes orders whose ship date lies in the future. |\n| `PerLocation` | bit | No | 1 adds the location to the details or groups the totals by location (marked as \"old way\" in the code). |\n\n- All reads use `NOLOCK`, so the figures can include uncommitted data.\n- The setting `UseFIFObyLocation` controls the stock basis inside `pixi_CalculateStockForOrderLines`:\n - `0`: total stock of all locations with `SpecialStock = 0`.\n - `1`: stock of the line's own location.\n- Only lines in status `ANG`/`EIN` decide whether an order is complete. Lines of the same order in other statuses are ignored, both in the check and in the output.\n- `ShipCost` is the shipping cost of the order header. In the detail result sets it is repeated on every line of the order. In the totals it is counted once per order, or once per order and location with `PerLocation = 1`. An order with lines in several locations therefore contributes its shipping cost to each of those locations.\n- `OrderTotal` is computed as `SUM(Price * Qty)`.\n- `NULL` values for the bit parameters are treated as 0. `PerLocation` is marked in the code as the \"old way\".\n- The helper procedure calls `log.EventDurationInsert` (definition not attached), which probably writes a duration log entry.\n- On large databases the call can be expensive, because it calculates stock for all open lines.\n\nDocumentation: https://pixi-api-docs.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": "Returns the order lines that can be shipped from current stock, either as line details or as totals (orders, value, shipping cost, picks), optionally per location.\n\nEvaluates open orders and checks, line by line, whether there is enough stock to ship them. It then returns either the shippable lines or summary figures.\n\n**Candidate orders and lines**\n- Only order lines with status `ANG` or `EIN`, a non-NULL `ItemRef` and `Qty` > 0 are considered.\n- The order's customer must belong to `ShopId` (`Customers.CustomerOf`). An empty `ShopId` means all shops.\n- Orders are excluded if the invoice address (`AddrRef`) or the shipping address (`ShipAdrRef`) is locked (`ASlocked = 'Y'`).\n- Orders are also excluded if the order itself is locked (`OhSLocked = 'Y'`).\n- Unless `IncludeOrdersWithAnyShipDate = 1`, only orders with no `Shipdate` or a `Shipdate` before tomorrow (today or earlier) are included.\n\n**Stock check**\nThe internal procedure `pixi_CalculateStockForOrderLines` sets a shippable flag on each candidate line. It runs with zero-stock items skipped, so lines of items without stock are not shippable.\n- The calculation takes into account the stock in locations with `SpecialStock = 0`, existing reservations and earlier unreserved order lines.\n- Lines with status `EIN` always count as shippable.\n- An order counts as *partial or unshippable* if at least one of its candidate lines is not shippable.\n\n**Filter by delivery mode**\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 0`: only lines of orders whose candidate lines are all shippable (complete orders).\n- `OnlyPartDelivery = 0`, `IncludePartDelivery = 1`: all shippable lines, from complete and from partial orders.\n- `OnlyPartDelivery = 1`: only the shippable lines of partial orders. `IncludePartDelivery` is ignored in this case.\n\n**Currency**\nIf the setting `MultiCurrencyEnabled` is 1, `Price` and `ShipCost` are converted into the database currency. The conversion uses the exchange rate of the database rate source that has the same currency and date as the order's exchange rate. If no such rate exists, the values are not converted. `dbCurrency` then contains the database currency code; otherwise it is NULL.\n\n**Output**\nExactly one result set is returned, chosen by `ViewDetails` and `PerLocation`:\n- `ViewDetails = 1`: one row per shippable line, sorted by `OrderNr` and `OrderlineRef`. With `PerLocation = 1` the column `LocationId` is added.\n- `ViewDetails = 0`, `PerLocation = 0`: one total row.\n- `ViewDetails = 0`, `PerLocation = 1`: one total row per location.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ViewDetails` | bit | No | 1 returns one row per shippable line; 0 (or NULL) returns totals. |\n| `IncludePartDelivery` | bit | No | 1 includes the shippable lines of partial orders in addition to complete orders. Ignored when `OnlyPartDelivery = 1`. |\n| `OnlyPartDelivery` | bit | No | 1 returns only the shippable lines of orders that cannot be shipped completely. |\n| `ShopId` | varchar(3) | No | Restricts the result to orders of customers of this shop (`Customers.CustomerOf`). Empty means all shops. |\n| `IncludeOrdersWithAnyShipDate` | bit | No | 1 also includes orders whose ship date lies in the future. |\n| `PerLocation` | bit | No | 1 adds the location to the details or groups the totals by location (marked as \"old way\" in the code). |\n\n- All reads use `NOLOCK`, so the figures can include uncommitted data.\n- The setting `UseFIFObyLocation` controls the stock basis inside `pixi_CalculateStockForOrderLines`:\n - `0`: total stock of all locations with `SpecialStock = 0`.\n - `1`: stock of the line's own location.\n- Only lines in status `ANG`/`EIN` decide whether an order is complete. Lines of the same order in other statuses are ignored, both in the check and in the output.\n- `ShipCost` is the shipping cost of the order header. In the detail result sets it is repeated on every line of the order. In the totals it is counted once per order, or once per order and location with `PerLocation = 1`. An order with lines in several locations therefore contributes its shipping cost to each of those locations.\n- `OrderTotal` is computed as `SUM(Price * Qty)`.\n- `NULL` values for the bit parameters are treated as 0. `PerLocation` is marked in the code as the \"old way\".\n- The helper procedure calls `log.EventDurationInsert` (definition not attached), which probably writes a duration log entry.\n- On large databases the call can be expensive, because it calculates stock for all open lines.\n\nDocumentation: https://pixi-api-docs.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": "Returns a stock evaluation per item with stock quantity, average purchase price, stock value, stock age, last order date and sales quantities for three periods.\n\nBuilds a stock evaluation report for all items that have at least one bin entry in `InvBinItem`. According to the header comment it was made for stock evaluation and price recalculation for a specific customer (GCH).\n\n**Filter**\n- If `SupplNr` is set, only items whose `Items.SupplNr` equals this value are included. If it is `NULL` (default), all items with bin entries are returned.\n- Items without any `InvBinItem` row are not returned. Items whose bin rows add up to 0 are still returned.\n\n**Calculated values per item**\n- `EK`: average supplier price from `fPixi_GetAverageSupplPrice`. It averages `AddItems.SupplPrice` of all supplier records linked through the item's `IntLinkNr1`, ignoring `NULL` and 0 prices and the supplier `MGS`. If no such price exists, `0` is returned.\n- `AnzahlArtikelAufLager`: sum of `BinItemQty` over all bin locations of the item.\n- `EKGesamt`: stock quantity multiplied by `EK`.\n- `AufLagerSeit` / `AufLagerSeitTage`: earliest `UpdateDate` in `InvBinItemLog` with a positive quantity, and the number of days since then.\n- `LetzteBestellung` / `LetzteBestellungTage`: latest `OrderDate` of any order line for the item, and the number of days since then.\n- `soldRange1`, `soldRange2`, `soldRange3`: sum of `Orderlines.Qty` for order lines with an `OrderDate` within the last `SoldRange1`, `SoldRange2` or `SoldRange3` days, counted back from the current server time.\n\nThe result has no defined sort order and no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | No | Supplier number (`Items.SupplNr`) to restrict the report to. `NULL` returns all items with bin entries. |\n| `SoldRange1` | int | No | Number of days back from now for the sales sum in column `soldRange1`. |\n| `SoldRange2` | int | No | Number of days back from now for the sales sum in column `soldRange2`. |\n| `SoldRange3` | int | No | Number of days back from now for the sales sum in column `soldRange3`. |\n\n- All tables are read with `NOLOCK`, so the figures can include uncommitted data.\n- Sales quantities and the last order date count **all** order lines of the item, regardless of order or line status (for example cancelled lines are not excluded).\n- `soldRange*`, `LetzteBestellung`, `AufLagerSeit` and the day columns are `NULL` if there are no matching order lines or log entries.\n- The average purchase price always excludes the supplier `MGS`; this is hard-coded in `fPixi_GetAverageSupplPrice`. The function's fallback query is identical to the first query, so it effectively returns `0` if no price is found.\n- Each item triggers several correlated subqueries and a scalar function call. Without a `SupplNr` filter the call can run for a long time on large catalogues.\n\nDocumentation: https://pixi-api-docs.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": "Returns a stock evaluation per item with stock quantity, average purchase price, stock value, stock age, last order date and sales quantities for three periods.\n\nBuilds a stock evaluation report for all items that have at least one bin entry in `InvBinItem`. According to the header comment it was made for stock evaluation and price recalculation for a specific customer (GCH).\n\n**Filter**\n- If `SupplNr` is set, only items whose `Items.SupplNr` equals this value are included. If it is `NULL` (default), all items with bin entries are returned.\n- Items without any `InvBinItem` row are not returned. Items whose bin rows add up to 0 are still returned.\n\n**Calculated values per item**\n- `EK`: average supplier price from `fPixi_GetAverageSupplPrice`. It averages `AddItems.SupplPrice` of all supplier records linked through the item's `IntLinkNr1`, ignoring `NULL` and 0 prices and the supplier `MGS`. If no such price exists, `0` is returned.\n- `AnzahlArtikelAufLager`: sum of `BinItemQty` over all bin locations of the item.\n- `EKGesamt`: stock quantity multiplied by `EK`.\n- `AufLagerSeit` / `AufLagerSeitTage`: earliest `UpdateDate` in `InvBinItemLog` with a positive quantity, and the number of days since then.\n- `LetzteBestellung` / `LetzteBestellungTage`: latest `OrderDate` of any order line for the item, and the number of days since then.\n- `soldRange1`, `soldRange2`, `soldRange3`: sum of `Orderlines.Qty` for order lines with an `OrderDate` within the last `SoldRange1`, `SoldRange2` or `SoldRange3` days, counted back from the current server time.\n\nThe result has no defined sort order and no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | No | Supplier number (`Items.SupplNr`) to restrict the report to. `NULL` returns all items with bin entries. |\n| `SoldRange1` | int | No | Number of days back from now for the sales sum in column `soldRange1`. |\n| `SoldRange2` | int | No | Number of days back from now for the sales sum in column `soldRange2`. |\n| `SoldRange3` | int | No | Number of days back from now for the sales sum in column `soldRange3`. |\n\n- All tables are read with `NOLOCK`, so the figures can include uncommitted data.\n- Sales quantities and the last order date count **all** order lines of the item, regardless of order or line status (for example cancelled lines are not excluded).\n- `soldRange*`, `LetzteBestellung`, `AufLagerSeit` and the day columns are `NULL` if there are no matching order lines or log entries.\n- The average purchase price always excludes the supplier `MGS`; this is hard-coded in `fPixi_GetAverageSupplPrice`. The function's fallback query is identical to the first query, so it effectively returns `0` if no price is found.\n- Each item triggers several correlated subqueries and a scalar function call. Without a `SupplNr` filter the call can run for a long time on large catalogues.\n\nDocumentation: https://pixi-api-docs.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": "Returns all invoices that were still unpaid (fully or partially) at the end of a given day, optionally filtered by shop and payment code.\n\nBuilds an open-items list of invoices as of a reference date.\n\n1. `Date` is moved to the end of that day (23:59:59.997) by `fPixi_GetDateEndOfDay`. If it is omitted, the current day is used. `ShopID` is trimmed, and an empty `ShopID` or `PaymentCode` counts as \"no filter\".\n2. The call selects invoices that meet all of these conditions:\n - The invoice date is before the reference date.\n - The invoice is not a return or credit note, i.e. it has no reference to another invoice.\n - The shop matches (`InvShopID = ShopID`), if `ShopID` is given.\n - The payment code matches (`Payment = PaymentCode`), if `PaymentCode` is given.\n3. Each invoice is joined to its customer account entries. Entries that were already fully matched (`Amount = Matched`) and last updated before the reference date are ignored.\n4. The open amount is the customer account amount plus the sum of all matches (`AbsoluteMatchAmount`) created before the reference date. A match counts whether the entry is referenced as first or second match partner. Only invoices whose open amount is still below 0 are returned.\n5. For each open invoice the call returns:\n - invoice number, date and total\n - open amount\n - external customer number and DATEV account number\n - last and first name from the invoice address\n - shop\n - country of the shipping address\n - currency code\n\nThe result has no `ORDER BY`, so the row order is not defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Date` | datetime | No | Reference date. The end of this day is used as cutoff. Defaults to today. |\n| `ShopID` | varchar(3) | No | Restricts the result to invoices of this shop. Empty or NULL means all shops. |\n| `PaymentCode` | char(1) | No | Restricts the result to invoices with this payment code (`Invoices.Payment`). Empty or NULL means all payment codes. |\n\n- All tables are read with `NOLOCK`. The figures can therefore include uncommitted data.\n- `OffenerRechnungsbetrag` uses the sign convention of the customer account: open receivables are **negative** values.\n- The final query uses inner joins to invoice address, shipping address, customer and currency. Invoices missing one of these references are not returned.\n- If an invoice has several customer account entries, `MAX(Amount)` of these entries is combined with the sum of all their matches. The open amount may then differ from the expected value.\n- Invoices dated exactly at the end-of-day timestamp (23:59:59.997) are excluded because the comparison is strict (`<`).\n- Column names of the result are German (`Rechnungsnummer`, `Kundennummer`, ...), except `DatevUserAccount`, `ShopID`, `CountryCode` and `CurrencyCode`.\n\nDocumentation: https://pixi-api-docs.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": "Returns all invoices that were still unpaid (fully or partially) at the end of a given day, optionally filtered by shop and payment code.\n\nBuilds an open-items list of invoices as of a reference date.\n\n1. `Date` is moved to the end of that day (23:59:59.997) by `fPixi_GetDateEndOfDay`. If it is omitted, the current day is used. `ShopID` is trimmed, and an empty `ShopID` or `PaymentCode` counts as \"no filter\".\n2. The call selects invoices that meet all of these conditions:\n - The invoice date is before the reference date.\n - The invoice is not a return or credit note, i.e. it has no reference to another invoice.\n - The shop matches (`InvShopID = ShopID`), if `ShopID` is given.\n - The payment code matches (`Payment = PaymentCode`), if `PaymentCode` is given.\n3. Each invoice is joined to its customer account entries. Entries that were already fully matched (`Amount = Matched`) and last updated before the reference date are ignored.\n4. The open amount is the customer account amount plus the sum of all matches (`AbsoluteMatchAmount`) created before the reference date. A match counts whether the entry is referenced as first or second match partner. Only invoices whose open amount is still below 0 are returned.\n5. For each open invoice the call returns:\n - invoice number, date and total\n - open amount\n - external customer number and DATEV account number\n - last and first name from the invoice address\n - shop\n - country of the shipping address\n - currency code\n\nThe result has no `ORDER BY`, so the row order is not defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Date` | datetime | No | Reference date. The end of this day is used as cutoff. Defaults to today. |\n| `ShopID` | varchar(3) | No | Restricts the result to invoices of this shop. Empty or NULL means all shops. |\n| `PaymentCode` | char(1) | No | Restricts the result to invoices with this payment code (`Invoices.Payment`). Empty or NULL means all payment codes. |\n\n- All tables are read with `NOLOCK`. The figures can therefore include uncommitted data.\n- `OffenerRechnungsbetrag` uses the sign convention of the customer account: open receivables are **negative** values.\n- The final query uses inner joins to invoice address, shipping address, customer and currency. Invoices missing one of these references are not returned.\n- If an invoice has several customer account entries, `MAX(Amount)` of these entries is combined with the sum of all their matches. The open amount may then differ from the expected value.\n- Invoices dated exactly at the end-of-day timestamp (23:59:59.997) are excluded because the comparison is strict (`<`).\n- Column names of the result are German (`Rechnungsnummer`, `Kundennummer`, ...), except `DatevUserAccount`, `ShopID`, `CountryCode` and `CurrencyCode`.\n\nDocumentation: https://pixi-api-docs.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": "Returns open order lines that cannot be shipped because of missing stock, either as a summary row or as a per-line detail list.\n\nThe call is a wrapper around the internal procedure `Report_GetUnshippableOrders`. It always passes `OrderlineStatus = NULL` and `ShopId = NULL`, so all statuses and all shops are evaluated. It captures the result in a temporary table and returns a subset of the columns.\n\n**Selection of order lines**\n\n1. Order lines must have status `ANG` or `HAL`, a set `ItemRef` and `Qty > 0`.\n2. Only orders are considered that have at least one such line in a location with `SpecialStock = 0`. If `LocID` is given, that location must be the one. An empty string counts as no filter.\n3. If `IncludeCustLock` is `0` or not sent, two kinds of orders are excluded:\n - orders whose customer has `SLocked` set to a value other than `N`/NULL\n - orders whose shipping address is locked (`ASlocked = 'Y'`)\n4. If `IncludeCustLock` is `1`, locked customers and addresses are included.\n5. For all `ANG`/`HAL` lines of the candidate orders, the internal procedure `pixi_CalculateStockForOrderLines` calculates whether each line can be shipped. Only lines with reservation info that are **not** shippable are returned.\n\n**Output depending on `ViewDetails`**\n\n- `0`: exactly one summary row with these values:\n - `Orders`: number of distinct orders\n - `OrderTotal`: sum of line prices\n - `ShipCost`: sum of shipping costs, counted once per order\n - `DiffrentCustomers`: number of distinct customers\n - `MissingArticles`: sum of quantities\n - `DiffrentArticles`: number of distinct items\n - `dbCurrency`\n- `1`: one row per unshippable order line. The rows carry no defined sort order.\n\nAll amounts are converted into the database currency if the setting `MultiCurrencyEnabled` is active.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ViewDetails` | bit | No | Selects the output format: summary row or detail list per order line. Should always be sent explicitly (see notes). |\n| `IncludeCustLock` | bit | No | Whether orders of locked customers and orders with locked shipping addresses are included. NULL is treated as 0. |\n| `LocID` | varchar(3) | No | Optional location ID. Only orders with at least one relevant line in this location (with `SpecialStock = 0`) are considered. NULL or an empty string means all non-special-stock locations. |\n\n- **Always send `ViewDetails` explicitly.** The wrapper checks `ViewDetails = 0`. A NULL value (the default) therefore takes the detail branch. The inner procedure, however, treats NULL as `0` and returns the 7-column summary. The `INSERT ... EXEC` into the 21-column detail table then most likely fails with a column mismatch error.\n- The header comment mentions order status OPEN/HOLD and line status `NLB`. The code only filters line statuses `ANG` and `HAL` and does not check the order status.\n- The `LocID` filter only selects candidate orders. Once an order qualifies, all its `ANG`/`HAL` lines are evaluated, including lines in other locations.\n- The shippability logic is in `pixi_CalculateStockForOrderLines`, which is not attached. It is called with `SkipZeroStockItemsCalc = 1`. The exact stock and reservation rules cannot be derived here.\n- `OrderTotal` and `Price` are based on the line field `Price` and are not multiplied by `Qty`.\n- In the detail list, `ShipCost` repeats the order's shipping cost on every line.\n- `SLocked` is not the customer's lock flag. It reflects the parameter: `Y` if `IncludeCustLock = 1`, otherwise `N`.\n- `Shippable` is always `0`.\n- `dbCurrency` is only filled when `MultiCurrencyEnabled` is active, otherwise it is NULL. Amounts are divided by the exchange rate of the matching date. If no rate is found, the value is left unconverted.\n- In the summary, `OrderTotal`, `MissingArticles` and `DiffrentArticles` can be NULL or 0 when no unshippable lines exist, but a row is still returned.\n- All reads use `NOLOCK`, so uncommitted data may be included.\n\nDocumentation: https://pixi-api-docs.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": "Returns open order lines that cannot be shipped because of missing stock, either as a summary row or as a per-line detail list.\n\nThe call is a wrapper around the internal procedure `Report_GetUnshippableOrders`. It always passes `OrderlineStatus = NULL` and `ShopId = NULL`, so all statuses and all shops are evaluated. It captures the result in a temporary table and returns a subset of the columns.\n\n**Selection of order lines**\n\n1. Order lines must have status `ANG` or `HAL`, a set `ItemRef` and `Qty > 0`.\n2. Only orders are considered that have at least one such line in a location with `SpecialStock = 0`. If `LocID` is given, that location must be the one. An empty string counts as no filter.\n3. If `IncludeCustLock` is `0` or not sent, two kinds of orders are excluded:\n - orders whose customer has `SLocked` set to a value other than `N`/NULL\n - orders whose shipping address is locked (`ASlocked = 'Y'`)\n4. If `IncludeCustLock` is `1`, locked customers and addresses are included.\n5. For all `ANG`/`HAL` lines of the candidate orders, the internal procedure `pixi_CalculateStockForOrderLines` calculates whether each line can be shipped. Only lines with reservation info that are **not** shippable are returned.\n\n**Output depending on `ViewDetails`**\n\n- `0`: exactly one summary row with these values:\n - `Orders`: number of distinct orders\n - `OrderTotal`: sum of line prices\n - `ShipCost`: sum of shipping costs, counted once per order\n - `DiffrentCustomers`: number of distinct customers\n - `MissingArticles`: sum of quantities\n - `DiffrentArticles`: number of distinct items\n - `dbCurrency`\n- `1`: one row per unshippable order line. The rows carry no defined sort order.\n\nAll amounts are converted into the database currency if the setting `MultiCurrencyEnabled` is active.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ViewDetails` | bit | No | Selects the output format: summary row or detail list per order line. Should always be sent explicitly (see notes). |\n| `IncludeCustLock` | bit | No | Whether orders of locked customers and orders with locked shipping addresses are included. NULL is treated as 0. |\n| `LocID` | varchar(3) | No | Optional location ID. Only orders with at least one relevant line in this location (with `SpecialStock = 0`) are considered. NULL or an empty string means all non-special-stock locations. |\n\n- **Always send `ViewDetails` explicitly.** The wrapper checks `ViewDetails = 0`. A NULL value (the default) therefore takes the detail branch. The inner procedure, however, treats NULL as `0` and returns the 7-column summary. The `INSERT ... EXEC` into the 21-column detail table then most likely fails with a column mismatch error.\n- The header comment mentions order status OPEN/HOLD and line status `NLB`. The code only filters line statuses `ANG` and `HAL` and does not check the order status.\n- The `LocID` filter only selects candidate orders. Once an order qualifies, all its `ANG`/`HAL` lines are evaluated, including lines in other locations.\n- The shippability logic is in `pixi_CalculateStockForOrderLines`, which is not attached. It is called with `SkipZeroStockItemsCalc = 1`. The exact stock and reservation rules cannot be derived here.\n- `OrderTotal` and `Price` are based on the line field `Price` and are not multiplied by `Qty`.\n- In the detail list, `ShipCost` repeats the order's shipping cost on every line.\n- `SLocked` is not the customer's lock flag. It reflects the parameter: `Y` if `IncludeCustLock = 1`, otherwise `N`.\n- `Shippable` is always `0`.\n- `dbCurrency` is only filled when `MultiCurrencyEnabled` is active, otherwise it is NULL. Amounts are divided by the exchange rate of the matching date. If no rate is found, the value is left unconverted.\n- In the summary, `OrderTotal`, `MissingArticles` and `DiffrentArticles` can be NULL or 0 when no unshippable lines exist, but a row is still returned.\n- All reads use `NOLOCK`, so uncommitted data may be included.\n\nDocumentation: https://pixi-api-docs.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": "Returns the gross profit report per item for an invoice date range, with sales and returns figures, optionally filtered by shop, category, supplier, payment type and tags.\n\nExposes the Pixi report *Gross Profit* (`Report_GrossProfit`) as an API call. Only the detail view is returned; the sums-only mode of the report is hard-coded off.\n\n**Steps**\n\n1. Parameters are normalised: `FromDate` is set to the start of its day, `ToDate` to the end of its day (23:59:59.997). Empty strings are treated as `NULL`; a `TagKey` of `0` also counts as not set.\n2. Parameters are validated. If `FromDate` is later than `ToDate`, or a given shop, category (`TontrArten`), supplier, payment type, excluded payment type or tag does not exist, a single status row with `Status` = `Error` is returned and the call ends.\n3. The report reads invoice lines whose invoice date lies between `FromDate` and `ToDate` and applies the optional filters:\n - `ShopID`: only lines of this shop.\n - `Category`: item configuration type equals the category.\n - `SupplNr`: only items of this supplier.\n - `PaymentType`: only lines with this payment type; `ExcludePaymentType`: lines with this payment type are excluded.\n - `TagKey1`–`TagKey3`: only items carrying all given tags (AND combination).\n4. Lines are grouped per item, separately for sold and returned quantities, and combined into one row per item.\n\n**Currency**\n\n- Without `ShopID`, all amounts are converted into the database currency (if multi-currency is enabled) and `Currency` is the database currency code.\n- With `ShopID`, amounts are returned in the shop's base currency when multi-currency is enabled; otherwise the database currency code is reported.\n\n**Figures per row**\n\n- `Sales_*` are quantity-weighted average unit values of the sold lines (gross selling price, VAT, supplier price).\n- `Returns_*` are the corresponding values of the returned lines.\n- `SingleGrossProfit` = average gross selling price − average VAT − average supplier price of the sold lines.\n- `TotalGrossProfit` = per-unit profit of sales × sold quantity − per-unit profit of returns × returned quantity.\n\nSpecial invoice lines such as shipping costs or vouchers (negative internal item keys) can appear as their own rows.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Yes | Start of the invoice date range. The time part is ignored; the range starts at the beginning of this day. |\n| `ToDate` | datetime | Yes | End of the invoice date range. The time part is ignored; the whole day is included. |\n| `ShopID` | varchar(3) | No | Optional shop filter. Must exist in `Shops`. When set, amounts are reported in the shop's base currency (if multi-currency is enabled). |\n| `Category` | varchar(10) | No | Optional item category (configuration type, `TontrArt`). Must exist in `TontrArten`. |\n| `SupplNr` | varchar(10) | No | Optional supplier number. Must exist in `Suppliers`. |\n| `PaymentType` | char(1) | No | Optional payment type code; only invoice lines with this payment type are included. Must exist in `Payments.Code`. |\n| `ExcludePaymentType` | char(1) | No | Optional payment type code to exclude. Must exist in `Payments.Code`. |\n| `TagKey1` | int | No | Optional item tag ID. Only items with this tag are included. `0` means no filter. |\n| `TagKey2` | int | No | Optional second item tag ID; items must carry it in addition to `TagKey1`. Ignored as a filter if `TagKey1` is not set. |\n| `TagKey3` | int | No | Optional third item tag ID; only used as a filter if `TagKey1` and `TagKey2` are set. |\n\n- The error rows contain two columns: `Status` and an error text. Only for the `ExcludePaymentType` check is the text column named `Message`; in all other checks the column has no alias, so the SOAP client may receive it under a generated name (e.g. `Column1`).\n- The date error text says `\"DateTo\" is greater than \"DateFrom\"`, but it is returned when `FromDate` is later than `ToDate`.\n- `FromDate` and `ToDate` have no default. If `NULL` is passed, no invoice lines match and the result is empty.\n- Tag filtering only takes effect if `TagKey1` is set. `TagKey2` is only used together with `TagKey1`, and `TagKey3` only if `TagKey1` and `TagKey2` are set; e.g. `TagKey2` alone is validated but ignored as a filter.\n- The underlying report sorts by item name, but the rows pass through a temporary table and the final `SELECT` has no `ORDER BY`, so the order is not guaranteed.\n- Each call first runs `Report_SaveSupplierPrices`, which according to a comment fills a cache table of supplier prices; its definition is not attached. The multi-currency behaviour depends on the setting `MultiCurrencyEnabled`.\n- All reads use `NOLOCK`, so uncommitted data may be included. Large date ranges can be slow.\n- Averages are divided by the sum of absolute quantities; groups with a total quantity of zero could cause a division-by-zero error.\n\nDocumentation: https://pixi-api-docs.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": "Returns the gross profit report per item for an invoice date range, with sales and returns figures, optionally filtered by shop, category, supplier, payment type and tags.\n\nExposes the Pixi report *Gross Profit* (`Report_GrossProfit`) as an API call. Only the detail view is returned; the sums-only mode of the report is hard-coded off.\n\n**Steps**\n\n1. Parameters are normalised: `FromDate` is set to the start of its day, `ToDate` to the end of its day (23:59:59.997). Empty strings are treated as `NULL`; a `TagKey` of `0` also counts as not set.\n2. Parameters are validated. If `FromDate` is later than `ToDate`, or a given shop, category (`TontrArten`), supplier, payment type, excluded payment type or tag does not exist, a single status row with `Status` = `Error` is returned and the call ends.\n3. The report reads invoice lines whose invoice date lies between `FromDate` and `ToDate` and applies the optional filters:\n - `ShopID`: only lines of this shop.\n - `Category`: item configuration type equals the category.\n - `SupplNr`: only items of this supplier.\n - `PaymentType`: only lines with this payment type; `ExcludePaymentType`: lines with this payment type are excluded.\n - `TagKey1`–`TagKey3`: only items carrying all given tags (AND combination).\n4. Lines are grouped per item, separately for sold and returned quantities, and combined into one row per item.\n\n**Currency**\n\n- Without `ShopID`, all amounts are converted into the database currency (if multi-currency is enabled) and `Currency` is the database currency code.\n- With `ShopID`, amounts are returned in the shop's base currency when multi-currency is enabled; otherwise the database currency code is reported.\n\n**Figures per row**\n\n- `Sales_*` are quantity-weighted average unit values of the sold lines (gross selling price, VAT, supplier price).\n- `Returns_*` are the corresponding values of the returned lines.\n- `SingleGrossProfit` = average gross selling price − average VAT − average supplier price of the sold lines.\n- `TotalGrossProfit` = per-unit profit of sales × sold quantity − per-unit profit of returns × returned quantity.\n\nSpecial invoice lines such as shipping costs or vouchers (negative internal item keys) can appear as their own rows.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromDate` | datetime | Yes | Start of the invoice date range. The time part is ignored; the range starts at the beginning of this day. |\n| `ToDate` | datetime | Yes | End of the invoice date range. The time part is ignored; the whole day is included. |\n| `ShopID` | varchar(3) | No | Optional shop filter. Must exist in `Shops`. When set, amounts are reported in the shop's base currency (if multi-currency is enabled). |\n| `Category` | varchar(10) | No | Optional item category (configuration type, `TontrArt`). Must exist in `TontrArten`. |\n| `SupplNr` | varchar(10) | No | Optional supplier number. Must exist in `Suppliers`. |\n| `PaymentType` | char(1) | No | Optional payment type code; only invoice lines with this payment type are included. Must exist in `Payments.Code`. |\n| `ExcludePaymentType` | char(1) | No | Optional payment type code to exclude. Must exist in `Payments.Code`. |\n| `TagKey1` | int | No | Optional item tag ID. Only items with this tag are included. `0` means no filter. |\n| `TagKey2` | int | No | Optional second item tag ID; items must carry it in addition to `TagKey1`. Ignored as a filter if `TagKey1` is not set. |\n| `TagKey3` | int | No | Optional third item tag ID; only used as a filter if `TagKey1` and `TagKey2` are set. |\n\n- The error rows contain two columns: `Status` and an error text. Only for the `ExcludePaymentType` check is the text column named `Message`; in all other checks the column has no alias, so the SOAP client may receive it under a generated name (e.g. `Column1`).\n- The date error text says `\"DateTo\" is greater than \"DateFrom\"`, but it is returned when `FromDate` is later than `ToDate`.\n- `FromDate` and `ToDate` have no default. If `NULL` is passed, no invoice lines match and the result is empty.\n- Tag filtering only takes effect if `TagKey1` is set. `TagKey2` is only used together with `TagKey1`, and `TagKey3` only if `TagKey1` and `TagKey2` are set; e.g. `TagKey2` alone is validated but ignored as a filter.\n- The underlying report sorts by item name, but the rows pass through a temporary table and the final `SELECT` has no `ORDER BY`, so the order is not guaranteed.\n- Each call first runs `Report_SaveSupplierPrices`, which according to a comment fills a cache table of supplier prices; its definition is not attached. The multi-currency behaviour depends on the setting `MultiCurrencyEnabled`.\n- All reads use `NOLOCK`, so uncommitted data may be included. Large date ranges can be slow.\n- Averages are divided by the sum of absolute quantities; groups with a total quantity of zero could cause a division-by-zero error.\n\nDocumentation: https://pixi-api-docs.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": "Returns a detailed list of invoices and credit notes in a date range, with amounts, VAT, purchase values, address and payment data.\n\nWrapper around the internal report procedure `Report_InvoicesList`. Empty strings in `ShopID`, `Payment`, `ShipCountry` and `DocumentType` are treated as `NULL` (no filter). The report always returns one row per invoice; the sum mode and the unpaid-only filter of the internal procedure are not available through this call.\n\nProcessing steps:\n\n1. The supplier price cache is refreshed first (`Report_SaveSupplierPrices`).\n2. `DateFrom` is moved to the start of its day and `DateTo` to the end of its day. Invoices with `InvDate` in this range are selected.\n3. Optional filters:\n - `ShopID`: only invoices whose **shipping address** belongs to this shop (`AddrShopID`). Invoices without a shipping address are then excluded.\n - `Payment`: only invoices with this payment method code.\n - `ShipCountry`: only invoices whose shipping address has this country code.\n - `DocumentType`: `R` = invoices only (no reference invoice), `G` = credit notes only (with reference invoice).\n4. Currency of the amounts:\n - With `ShopID`: amounts are in the invoice's base currency (divided by the invoice exchange rate if multi-currency is enabled); `BaseCurrency` is that currency code.\n - Without `ShopID`: amounts are converted to the database currency using the exchange rate of the database source for the same date and currency; `BaseCurrency` is the database currency code.\n5. Per invoice, the item quantity (`SumQtyItems`) and the purchase value (`SumEKItems`, quantity × historical supplier price) are summed from the invoice lines. The external order number is determined via the order linked to the invoice (for credit notes via the referenced invoice).\n6. Net amounts and VAT amounts are rounded to the number of decimal places from the setting `NumberOfDecimalPlacesForPrices` (default 2). `Total` and `Total_ShipCost` are not rounded.\n\nName, address, phone and fax come from the shipping address; `Country`, `CountryName` and `usStID` come from the billing address. Missing text values are returned as `/`. The result is sorted by `InvoiceNR`. The `par_*` columns echo the effective filter values (`-alle-` if no filter was set).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Yes | Start of the invoice date range; the time is set to the start of the day. |\n| `DateTo` | datetime | Yes | End of the invoice date range; the time is set to the end of the day. |\n| `ShopID` | char(3) | No | Shop of the shipping address. If set, only invoices of this shop are returned and amounts are in the invoice base currency; otherwise in the database currency. Empty = all shops. |\n| `Payment` | char(1) | No | Payment method code of the invoice. Empty = all payment methods. |\n| `ShipCountry` | varchar(3) | No | Country code of the shipping address. Empty = all countries. |\n| `DocumentType` | char(1) | No | Document type filter. Empty = invoices and credit notes. |\n\n- Side effect: before reading, the internal procedure `Report_SaveSupplierPrices` is executed, which according to the code comment fills a cache table (presumably the supplier price history). Its definition is not attached, so the exact writes are unknown.\n- All reads use `NOLOCK`; the result may contain uncommitted data.\n- Invoices without a matching exchange rate record are not returned (inner joins on `pixi.ExchRate`). Without `ShopID`, an exchange rate of the database source for the same date and currency must exist.\n- A `DocumentType` other than `R` or `G` returns no rows.\n- `payed` is returned as `1900-01-01T00:00:00` for unpaid invoices, because `NULL` is replaced by an empty string on a datetime column.\n- `SumEKItems` is 0 or incomplete if no supplier price history exists for the invoice lines.\n- If the order lookup function returns several orders for one invoice, the invoice can appear in several rows.\n- The behaviour depends on the settings `MultiCurrencyEnabled` and `NumberOfDecimalPlacesForPrices`.\n- Large date ranges can be slow because all invoice lines are aggregated.\n\nDocumentation: https://pixi-api-docs.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": "Returns a detailed list of invoices and credit notes in a date range, with amounts, VAT, purchase values, address and payment data.\n\nWrapper around the internal report procedure `Report_InvoicesList`. Empty strings in `ShopID`, `Payment`, `ShipCountry` and `DocumentType` are treated as `NULL` (no filter). The report always returns one row per invoice; the sum mode and the unpaid-only filter of the internal procedure are not available through this call.\n\nProcessing steps:\n\n1. The supplier price cache is refreshed first (`Report_SaveSupplierPrices`).\n2. `DateFrom` is moved to the start of its day and `DateTo` to the end of its day. Invoices with `InvDate` in this range are selected.\n3. Optional filters:\n - `ShopID`: only invoices whose **shipping address** belongs to this shop (`AddrShopID`). Invoices without a shipping address are then excluded.\n - `Payment`: only invoices with this payment method code.\n - `ShipCountry`: only invoices whose shipping address has this country code.\n - `DocumentType`: `R` = invoices only (no reference invoice), `G` = credit notes only (with reference invoice).\n4. Currency of the amounts:\n - With `ShopID`: amounts are in the invoice's base currency (divided by the invoice exchange rate if multi-currency is enabled); `BaseCurrency` is that currency code.\n - Without `ShopID`: amounts are converted to the database currency using the exchange rate of the database source for the same date and currency; `BaseCurrency` is the database currency code.\n5. Per invoice, the item quantity (`SumQtyItems`) and the purchase value (`SumEKItems`, quantity × historical supplier price) are summed from the invoice lines. The external order number is determined via the order linked to the invoice (for credit notes via the referenced invoice).\n6. Net amounts and VAT amounts are rounded to the number of decimal places from the setting `NumberOfDecimalPlacesForPrices` (default 2). `Total` and `Total_ShipCost` are not rounded.\n\nName, address, phone and fax come from the shipping address; `Country`, `CountryName` and `usStID` come from the billing address. Missing text values are returned as `/`. The result is sorted by `InvoiceNR`. The `par_*` columns echo the effective filter values (`-alle-` if no filter was set).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Yes | Start of the invoice date range; the time is set to the start of the day. |\n| `DateTo` | datetime | Yes | End of the invoice date range; the time is set to the end of the day. |\n| `ShopID` | char(3) | No | Shop of the shipping address. If set, only invoices of this shop are returned and amounts are in the invoice base currency; otherwise in the database currency. Empty = all shops. |\n| `Payment` | char(1) | No | Payment method code of the invoice. Empty = all payment methods. |\n| `ShipCountry` | varchar(3) | No | Country code of the shipping address. Empty = all countries. |\n| `DocumentType` | char(1) | No | Document type filter. Empty = invoices and credit notes. |\n\n- Side effect: before reading, the internal procedure `Report_SaveSupplierPrices` is executed, which according to the code comment fills a cache table (presumably the supplier price history). Its definition is not attached, so the exact writes are unknown.\n- All reads use `NOLOCK`; the result may contain uncommitted data.\n- Invoices without a matching exchange rate record are not returned (inner joins on `pixi.ExchRate`). Without `ShopID`, an exchange rate of the database source for the same date and currency must exist.\n- A `DocumentType` other than `R` or `G` returns no rows.\n- `payed` is returned as `1900-01-01T00:00:00` for unpaid invoices, because `NULL` is replaced by an empty string on a datetime column.\n- `SumEKItems` is 0 or incomplete if no supplier price history exists for the invoice lines.\n- If the order lookup function returns several orders for one invoice, the invoice can appear in several rows.\n- The behaviour depends on the settings `MultiCurrencyEnabled` and `NumberOfDecimalPlacesForPrices`.\n- Large date ranges can be slow because all invoice lines are aggregated.\n\nDocumentation: https://pixi-api-docs.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": "Returns the distribution of recent orders by the number of days between order receipt and first shipment, as a logistics quality KPI.\n\nCalculates how many days it took to ship recent orders and groups the orders by that number.\n\n**1. Order selection**\n\nAn order is included if:\n- its `Orderheader.CreateDate` is at most `@DaysBack` days ago;\n- it has at least one order line in status `ANG` or `AUS`. If `@ShopID` is not empty, the line's `OrdShopId` must also match;\n- it has no line in status `ANG`/`AUS` (created within `@DaysBack` days, same shop filter) whose Artikel had no stock booked in `InvBinItemLog` before the line was created;\n- its customer is not locked (`HSLocked = 'Y'` in `CustomersHist`).\n\nThe order's reference date is the earliest `StatusChangeDate` of an `ANG` entry in `Orderhistory` for its lines.\n\n**2. Stock check**\n\nThe procedure collects all lines of the selected orders. It removes an order if, for one of its Artikel, the summed quantity of all collected lines is higher than the stock booked in `InvBinItemLog` up to the order's reference date. Only lines created up to that date and not shipped before it (or not shipped at all) are summed.\n\n**3. Date adjustments**\n\n- Weekend (with `DATEFIRST 1`): orders from Friday after 14:59 move 3 days later. Saturday orders move 2 days later and Sunday orders 1 day later. The time of day stays the same.\n- Days without shipping: a day counts as a shipping day if it has more than 2 invoices with `total > 0` within `@DaysBack` days. An order whose original receipt day is not a shipping day gets a new reference date: the earliest invoice time of the next shipping day. This replaces the weekend adjustment.\n\n**4. Calculation**\n\nFor each order, `DaysToShip` is the whole number of 24-hour periods from the adjusted reference date to the earliest `ShipDate` of its lines. Negative values are set to 0.\n\nUnshipped orders are excluded, both from the grouping and from the total `AllPackages`.\n\n**5. Result**\n\nOne row per `DaysToShip` value with:\n- the number of orders;\n- their share of `AllPackages`;\n- the total `AllPackages`.\n\nA fixed extra row with `DaysToShip = 99` and 0 orders is always added. Rows are sorted by `DaysToShip` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DaysBack` | int | No | Number of days back from today. Orders, order lines and invoices older than this are not considered. |\n| `OnlyItemsOnStock` | bit | No | Declared but not used by the code. The stock checks are always applied. |\n| `ShopID` | varchar(3) | No | Shop filter on the order lines' `OrdShopId`. Empty or NULL means all shops. |\n| `MinutesSinceRefresh` | int | No | Declared but not used by the code. |\n\n- The parameters `@OnlyItemsOnStock` and `@MinutesSinceRefresh` are declared but not used by the code.\n- `@ShopID` filters on the order line field `OrdShopId`, not on the order header.\n- The code comment says Friday from 14:00. The code uses `hour > 14`, so the weekend shift starts at 15:00.\n- The comment calls the derived days \"holidays\" (days without shipment). The table actually contains days with more than 2 invoices. Orders created on any other day are moved to the first invoice time of the next such day. If no later shipping day exists, the reference date becomes NULL and the order counts as unshipped.\n- If `CustomersHist.HCustRef` contains NULL values, the `NOT IN` filter excludes all orders.\n- The row with `DaysToShip = 99` is a fixed marker row with `NRofORders = 0` and `Percentage = 0`. It is always returned, even if no order qualifies.\n- `Percentage` is a fraction between 0 and 1, not a percent value.\n- Most reads use `NOLOCK`, so the figures may include uncommitted data. The first read on `Orderheader` does not use `NOLOCK`.\n- The procedure uses many correlated subqueries on `Orderhistory`, `Orderlines` and `InvBinItemLog`. Large values for `@DaysBack` can be slow.\n- The procedure only writes to temporary tables.\n\nDocumentation: https://pixi-api-docs.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": "Returns the distribution of recent orders by the number of days between order receipt and first shipment, as a logistics quality KPI.\n\nCalculates how many days it took to ship recent orders and groups the orders by that number.\n\n**1. Order selection**\n\nAn order is included if:\n- its `Orderheader.CreateDate` is at most `@DaysBack` days ago;\n- it has at least one order line in status `ANG` or `AUS`. If `@ShopID` is not empty, the line's `OrdShopId` must also match;\n- it has no line in status `ANG`/`AUS` (created within `@DaysBack` days, same shop filter) whose Artikel had no stock booked in `InvBinItemLog` before the line was created;\n- its customer is not locked (`HSLocked = 'Y'` in `CustomersHist`).\n\nThe order's reference date is the earliest `StatusChangeDate` of an `ANG` entry in `Orderhistory` for its lines.\n\n**2. Stock check**\n\nThe procedure collects all lines of the selected orders. It removes an order if, for one of its Artikel, the summed quantity of all collected lines is higher than the stock booked in `InvBinItemLog` up to the order's reference date. Only lines created up to that date and not shipped before it (or not shipped at all) are summed.\n\n**3. Date adjustments**\n\n- Weekend (with `DATEFIRST 1`): orders from Friday after 14:59 move 3 days later. Saturday orders move 2 days later and Sunday orders 1 day later. The time of day stays the same.\n- Days without shipping: a day counts as a shipping day if it has more than 2 invoices with `total > 0` within `@DaysBack` days. An order whose original receipt day is not a shipping day gets a new reference date: the earliest invoice time of the next shipping day. This replaces the weekend adjustment.\n\n**4. Calculation**\n\nFor each order, `DaysToShip` is the whole number of 24-hour periods from the adjusted reference date to the earliest `ShipDate` of its lines. Negative values are set to 0.\n\nUnshipped orders are excluded, both from the grouping and from the total `AllPackages`.\n\n**5. Result**\n\nOne row per `DaysToShip` value with:\n- the number of orders;\n- their share of `AllPackages`;\n- the total `AllPackages`.\n\nA fixed extra row with `DaysToShip = 99` and 0 orders is always added. Rows are sorted by `DaysToShip` ascending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DaysBack` | int | No | Number of days back from today. Orders, order lines and invoices older than this are not considered. |\n| `OnlyItemsOnStock` | bit | No | Declared but not used by the code. The stock checks are always applied. |\n| `ShopID` | varchar(3) | No | Shop filter on the order lines' `OrdShopId`. Empty or NULL means all shops. |\n| `MinutesSinceRefresh` | int | No | Declared but not used by the code. |\n\n- The parameters `@OnlyItemsOnStock` and `@MinutesSinceRefresh` are declared but not used by the code.\n- `@ShopID` filters on the order line field `OrdShopId`, not on the order header.\n- The code comment says Friday from 14:00. The code uses `hour > 14`, so the weekend shift starts at 15:00.\n- The comment calls the derived days \"holidays\" (days without shipment). The table actually contains days with more than 2 invoices. Orders created on any other day are moved to the first invoice time of the next such day. If no later shipping day exists, the reference date becomes NULL and the order counts as unshipped.\n- If `CustomersHist.HCustRef` contains NULL values, the `NOT IN` filter excludes all orders.\n- The row with `DaysToShip = 99` is a fixed marker row with `NRofORders = 0` and `Percentage = 0`. It is always returned, even if no order qualifies.\n- `Percentage` is a fraction between 0 and 1, not a percent value.\n- Most reads use `NOLOCK`, so the figures may include uncommitted data. The first read on `Orderheader` does not use `NOLOCK`.\n- The procedure uses many correlated subqueries on `Orderhistory`, `Orderlines` and `InvBinItemLog`. Large values for `@DaysBack` can be slow.\n- The procedure only writes to temporary tables.\n\nDocumentation: https://pixi-api-docs.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": "Returns the logistic quality report: days from order creation to shipment per order, or a percentage distribution for the shipping seal.\n\nMeasures how many days (in 24-hour steps) it took to ship orders created in the last `DaysBack` days.\n\n**Date range**: `FromDate` is the start of the day `DaysBack` days ago, `ToDate` is the end of today.\n\n**Order selection**:\n- Orders whose header `CreateDate` is on or after `FromDate`.\n- The order's creation date is the earliest `ANG` entry in `OrderHistory` within the date range. The ship date is the earliest `ShipDate` of its order lines.\n- The order header `ShipDate` must be `NULL`.\n- At least one order line must have status `ANG` or `AUS`. If `ShopID` is set, that line must also belong to this shop (`OrdShopID`).\n- Orders of customers that were locked (`HSLocked = 'Y'`) in `CustomersHist` after `FromDate` are excluded.\n\n**Further exclusions** (the whole order is removed if one line qualifies):\n- Order lines created more than 5 minutes apart. Such orders count as changed manually after the import.\n- Not enough stock on the order date. Demand is accumulated per item from order creation and shipment events. Stock is calculated from `InvBinItemLog` in locations without special stock (`SpecialStock = 0`). If demand is greater than or equal to stock, the order is removed.\n- Lines on `ANG` whose available stock is `<= 1`. Available stock is `ItemLocationSpecific.LocationQuantity` if special-stock locations exist, otherwise `Items.Quantity`. With `CalcSeal = 0`, reservations made earlier by open orders (non-final states except `EIN`, `FUT`, `FUS`) are subtracted.\n\n**Date adjustments**:\n- Orders created on Friday, Saturday or Sunday are moved to the following Monday. The time of day is kept.\n- Holidays are taken as days without invoices that have a positive total. An order is moved to the first invoice time of the next day with invoices if one of these applies:\n - its creation day has no such invoices;\n - the following day has no such invoices.\n\n**Output** (only orders with a ship date):\n- `CalcSeal = 0` (pixi* Report client): one row per order with `DaysToShip`, order number and dates, sorted by `DaysToShip` and `CreateDate`. With `ExcludeZeros = 1`, only orders with `DaysToShip > 0` are returned.\n- `CalcSeal = 1` (Seal / Dashboard apps): one row per `DaysToShip` value with the order count, its share of all packages and the total. An extra row with `DaysToShip = 99` and zero values is always added. The rows are sorted by `DaysToShip`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DaysBack` | int | No | Number of days back from today that define the evaluation period. |\n| `ShopID` | varchar(3) | No | Restricts the report to orders with an `ANG`/`AUS` line of this shop. Empty means all shops. |\n| `ExcludeZeros` | bit | No | Only with `CalcSeal = 0`: if 1, orders shipped within the first 24 hours (`DaysToShip = 0`) are omitted. |\n| `OnlyItemsOnStock` | bit | No | Not used by the code. |\n| `CalcSeal` | bit | No | Selects the output mode: detail rows per order or aggregated distribution for the shipping seal. |\n\n- The parameter `OnlyItemsOnStock` is declared but not used anywhere in the code.\n- All permanent tables are read with `NOLOCK`, so results can include uncommitted data.\n- `SET DATEFIRST 1` is applied inside the procedure. Weekdays 5–7 are Friday to Sunday.\n- The reported `CreateDate` is the adjusted date (weekend/holiday shift), not the original order date.\n- Orders whose header `ShipDate` is set are not included. The ship date used is the earliest line `ShipDate`.\n- Orders whose `ANG` lines have no matching `ItemLocationSpecific` row for the line's location are not removed by the reservation-stock check.\n- Holiday detection depends on invoices with `total > 0`. Days without invoices are treated as holidays.\n- The code comment states that changes must also be applied to `pixiReport_LogisticQuality_NonCached`.\n- The calculation runs over many temporary tables and window functions. Large `DaysBack` values can be slow.\n\nDocumentation: https://pixi-api-docs.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": "Returns the logistic quality report: days from order creation to shipment per order, or a percentage distribution for the shipping seal.\n\nMeasures how many days (in 24-hour steps) it took to ship orders created in the last `DaysBack` days.\n\n**Date range**: `FromDate` is the start of the day `DaysBack` days ago, `ToDate` is the end of today.\n\n**Order selection**:\n- Orders whose header `CreateDate` is on or after `FromDate`.\n- The order's creation date is the earliest `ANG` entry in `OrderHistory` within the date range. The ship date is the earliest `ShipDate` of its order lines.\n- The order header `ShipDate` must be `NULL`.\n- At least one order line must have status `ANG` or `AUS`. If `ShopID` is set, that line must also belong to this shop (`OrdShopID`).\n- Orders of customers that were locked (`HSLocked = 'Y'`) in `CustomersHist` after `FromDate` are excluded.\n\n**Further exclusions** (the whole order is removed if one line qualifies):\n- Order lines created more than 5 minutes apart. Such orders count as changed manually after the import.\n- Not enough stock on the order date. Demand is accumulated per item from order creation and shipment events. Stock is calculated from `InvBinItemLog` in locations without special stock (`SpecialStock = 0`). If demand is greater than or equal to stock, the order is removed.\n- Lines on `ANG` whose available stock is `<= 1`. Available stock is `ItemLocationSpecific.LocationQuantity` if special-stock locations exist, otherwise `Items.Quantity`. With `CalcSeal = 0`, reservations made earlier by open orders (non-final states except `EIN`, `FUT`, `FUS`) are subtracted.\n\n**Date adjustments**:\n- Orders created on Friday, Saturday or Sunday are moved to the following Monday. The time of day is kept.\n- Holidays are taken as days without invoices that have a positive total. An order is moved to the first invoice time of the next day with invoices if one of these applies:\n - its creation day has no such invoices;\n - the following day has no such invoices.\n\n**Output** (only orders with a ship date):\n- `CalcSeal = 0` (pixi* Report client): one row per order with `DaysToShip`, order number and dates, sorted by `DaysToShip` and `CreateDate`. With `ExcludeZeros = 1`, only orders with `DaysToShip > 0` are returned.\n- `CalcSeal = 1` (Seal / Dashboard apps): one row per `DaysToShip` value with the order count, its share of all packages and the total. An extra row with `DaysToShip = 99` and zero values is always added. The rows are sorted by `DaysToShip`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DaysBack` | int | No | Number of days back from today that define the evaluation period. |\n| `ShopID` | varchar(3) | No | Restricts the report to orders with an `ANG`/`AUS` line of this shop. Empty means all shops. |\n| `ExcludeZeros` | bit | No | Only with `CalcSeal = 0`: if 1, orders shipped within the first 24 hours (`DaysToShip = 0`) are omitted. |\n| `OnlyItemsOnStock` | bit | No | Not used by the code. |\n| `CalcSeal` | bit | No | Selects the output mode: detail rows per order or aggregated distribution for the shipping seal. |\n\n- The parameter `OnlyItemsOnStock` is declared but not used anywhere in the code.\n- All permanent tables are read with `NOLOCK`, so results can include uncommitted data.\n- `SET DATEFIRST 1` is applied inside the procedure. Weekdays 5–7 are Friday to Sunday.\n- The reported `CreateDate` is the adjusted date (weekend/holiday shift), not the original order date.\n- Orders whose header `ShipDate` is set are not included. The ship date used is the earliest line `ShipDate`.\n- Orders whose `ANG` lines have no matching `ItemLocationSpecific` row for the line's location are not removed by the reservation-stock check.\n- Holiday detection depends on invoices with `total > 0`. Days without invoices are treated as holidays.\n- The code comment states that changes must also be applied to `pixiReport_LogisticQuality_NonCached`.\n- The calculation runs over many temporary tables and window functions. Large `DaysBack` values can be slow.\n\nDocumentation: https://pixi-api-docs.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": "Returns the distribution of shipped orders by days from order to shipment for the last days, as used for the pixi* shipping seal (Versandsiegel) percentage.\n\nWrapper used by the pixi* Seal app and the Dashboard app. `NULL` values are replaced by the defaults (`14`, `''`, `1`). The call then runs `pipiReport_LogisticQuality_Details` with `@CalcSeal = 1`, which computes the data directly (not from a cache).\n\n**Order selection**\n- Date range: from the start of the day `@DaysBack` days ago until the end of today.\n- The order creation date is the first `ANG` status change of its orderlines in `OrderHistory` within the range. The ship date is the earliest `ShipDate` of its orderlines.\n- Only orders whose `OrderHeader.ShipDate` is empty and that have at least one orderline in status `ANG` or `AUS`. If `ShopID` is not empty, that orderline must belong to this shop (`OrdShopID`).\n- Orders of customers that were locked (`CustomersHist.HSLocked = 'Y'`) during the range are excluded.\n\n**Exclusions**\n- Orders that were changed manually: the orderline creation times differ by more than 5 minutes.\n- Orders where the stock was not sufficient at the order date. Stock is calculated from `InvBinItemLog` on locations without special stock, minus the cumulated open demand per Artikel.\n- Orders with an orderline in status `ANG` whose Artikel stock is at most 1. The stock is `ItemLocationSpecific.LocationQuantity` if special stock locations exist, otherwise `Items.Quantity`.\n\n**Date adjustments**\n- Orders created on Friday, Saturday or Sunday are moved to the following Monday.\n- Days without an invoice with `total > 0` count as holidays. Orders on such a day, or on a day whose next day is such a day, are moved to the first invoice date of a later working day.\n\n**Result**\n- Only orders with a ship date are counted.\n- `DaysToShip` is the number of full 24-hour periods between the adjusted creation date and the ship date. Negative values become 0.\n- One row is returned per `DaysToShip` value, with the count and its share of all counted orders.\n- An additional fixed row with `DaysToShip = 99` and 0 orders is always appended.\n- The rows are sorted by `DaysToShip`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DaysBack` | int | No | Number of days back from today that are evaluated. `NULL` becomes 14. |\n| `ShopID` | varchar(3) | No | Shop filter on the orderline shop (`OrdShopID`). Empty or `NULL` means all shops. |\n| `OnlyItemsOnStock` | bit | No | Passed on to the detail procedure but not evaluated there; has no effect. |\n\n- The parameter `OnlyItemsOnStock` is passed on to `pipiReport_LogisticQuality_Details`, but that procedure does not use it. It has no effect.\n- All reads use `NOLOCK`, so the numbers can include uncommitted data.\n- The calculation runs on every call and can be expensive for large `DaysBack` values.\n- If no order qualifies, only the row with `DaysToShip = 99` is returned and `AllPackages` is 0.\n- Columns `Percentage` and `AllPackages` are floating-point values. `Percentage` is a fraction between 0 and 1, not a value multiplied by 100.\n- Holidays are derived from days without invoices, so days without invoicing also count as non-working days.\n\nDocumentation: https://pixi-api-docs.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": "Returns the distribution of shipped orders by days from order to shipment for the last days, as used for the pixi* shipping seal (Versandsiegel) percentage.\n\nWrapper used by the pixi* Seal app and the Dashboard app. `NULL` values are replaced by the defaults (`14`, `''`, `1`). The call then runs `pipiReport_LogisticQuality_Details` with `@CalcSeal = 1`, which computes the data directly (not from a cache).\n\n**Order selection**\n- Date range: from the start of the day `@DaysBack` days ago until the end of today.\n- The order creation date is the first `ANG` status change of its orderlines in `OrderHistory` within the range. The ship date is the earliest `ShipDate` of its orderlines.\n- Only orders whose `OrderHeader.ShipDate` is empty and that have at least one orderline in status `ANG` or `AUS`. If `ShopID` is not empty, that orderline must belong to this shop (`OrdShopID`).\n- Orders of customers that were locked (`CustomersHist.HSLocked = 'Y'`) during the range are excluded.\n\n**Exclusions**\n- Orders that were changed manually: the orderline creation times differ by more than 5 minutes.\n- Orders where the stock was not sufficient at the order date. Stock is calculated from `InvBinItemLog` on locations without special stock, minus the cumulated open demand per Artikel.\n- Orders with an orderline in status `ANG` whose Artikel stock is at most 1. The stock is `ItemLocationSpecific.LocationQuantity` if special stock locations exist, otherwise `Items.Quantity`.\n\n**Date adjustments**\n- Orders created on Friday, Saturday or Sunday are moved to the following Monday.\n- Days without an invoice with `total > 0` count as holidays. Orders on such a day, or on a day whose next day is such a day, are moved to the first invoice date of a later working day.\n\n**Result**\n- Only orders with a ship date are counted.\n- `DaysToShip` is the number of full 24-hour periods between the adjusted creation date and the ship date. Negative values become 0.\n- One row is returned per `DaysToShip` value, with the count and its share of all counted orders.\n- An additional fixed row with `DaysToShip = 99` and 0 orders is always appended.\n- The rows are sorted by `DaysToShip`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DaysBack` | int | No | Number of days back from today that are evaluated. `NULL` becomes 14. |\n| `ShopID` | varchar(3) | No | Shop filter on the orderline shop (`OrdShopID`). Empty or `NULL` means all shops. |\n| `OnlyItemsOnStock` | bit | No | Passed on to the detail procedure but not evaluated there; has no effect. |\n\n- The parameter `OnlyItemsOnStock` is passed on to `pipiReport_LogisticQuality_Details`, but that procedure does not use it. It has no effect.\n- All reads use `NOLOCK`, so the numbers can include uncommitted data.\n- The calculation runs on every call and can be expensive for large `DaysBack` values.\n- If no order qualifies, only the row with `DaysToShip = 99` is returned and `AllPackages` is 0.\n- Columns `Percentage` and `AllPackages` are floating-point values. `Percentage` is a fraction between 0 and 1, not a value multiplied by 100.\n- Holidays are derived from days without invoices, so days without invoicing also count as non-working days.\n\nDocumentation: https://pixi-api-docs.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": "Returns a monthly report for one year that compares order counts, order values and averages of new customers with those of existing customers.\n\nBuilds a pivoted report with one row per report line and one column per month (`Month01`–`Month12`) plus an `Average` column.\n\n**Parameters and filters**\n- `Year` defaults to the current year if `NULL`.\n- `Shop` (compared with `Customers.CustomerOf`) and `Country` (compared with the country of the order line address) are optional; an empty string is treated like `NULL`, i.e. no filter.\n\n**New customers**\nA customer counts as new in a month if the earliest `OrderDate` of all his order lines (within the shop/country filter) lies in that month of `Year`. Only the order lines with exactly this first order date are treated as the new-customer order; further orders in the same month count as orders of existing customers.\n\n**Report lines** (`GroupNumber` / `LineNumber`)\n- Group 1 – order counts:\n - 1 `Orders new customers`: number of customers whose first order falls in the month.\n - 2 `Orders customers`: line 3 minus line 1.\n - 3 `Total`: number of distinct order numbers in the month, excluding order lines with status `STO` or `NLB`.\n - 4 `rate new customers`: line 1 / line 3 × 100 (0 if line 3 is 0).\n- Group 2 – order values (sum of `OrderLineAmount`, order lines with status `STO`/`NLB` excluded):\n - 5 value of first orders of new customers.\n - 6 line 7 minus line 5.\n - 7 `Total`: value of all order lines of the month.\n - 8 share of new customers (line 5 / line 7 × 100), 9 share of existing customers (line 6 / line 7 × 100).\n- Group 3 – averages per order line:\n - 10 average `OrderLineAmount` of all candidate order lines in the month.\n - 11 average `OrderLineAmount` of the first-order lines of new customers.\n\n**Average column**: the arithmetic mean of the monthly values that exist for the line.\n\nRows are sorted by `LineNumber`. The columns `ParYear`, `ParShop` and `ParCountry` echo the effective parameters; `dbCurrency` contains the database currency code if multi-currency is enabled.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Year` | int | No | Report year. `NULL` means the current year. |\n| `Shop` | varchar(3) | No | Shop ID, compared with `Customers.CustomerOf`. `NULL` or empty string means all shops. |\n| `Country` | varchar(3) | No | Country code of the order line address. `NULL` or empty string means all countries. |\n\n- **Multi-currency**: if the setting `MultiCurrencyEnabled` is `1`, order values are converted into the database currency (setting `HomeCurrency`, exchange rate source from `DatabaseCurrencyExchRateSourceId`) using `pixi.ExchRate` of the order header's exchange date. Order lines without matching `OrderHeader` / exchange rate then drop out of the value lines. Otherwise the rate is 1 and `dbCurrency` is `NULL`.\n- **Label pitfall**: line 10 is labelled as average of new customers but averages *all* candidate order lines (including status `STO`/`NLB`), while line 11 is labelled as average of customers but averages the first-order lines of new customers. Lines 10 and 11 do not exclude `STO`/`NLB` order lines.\n- Averages in group 3 are per order line, not per order.\n- Lines 6, 7, 8, 9 and 10 only contain months that have order lines; other months stay `0` and are not included in `Average`, so `Average` is the mean of the months with data only.\n- First orders are determined without status filter; a customer whose earliest order line has status `STO`/`NLB` is still counted in line 1.\n- The new-customer determination uses inner joins on address and customer, so lines without country or `CustomerOf` are not considered, while the total lines accept `NULL` country/shop values.\n- A month can disappear from lines 2–4 if all its orders are removed by the filters.\n- All reads use `NOLOCK` (dirty reads possible). Line 3 joins order lines via `MONTH(OrderDate)`, which scans the whole `Orderlines` table and can be slow on large databases.\n\nDocumentation: https://pixi-api-docs.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": "Returns a monthly report for one year that compares order counts, order values and averages of new customers with those of existing customers.\n\nBuilds a pivoted report with one row per report line and one column per month (`Month01`–`Month12`) plus an `Average` column.\n\n**Parameters and filters**\n- `Year` defaults to the current year if `NULL`.\n- `Shop` (compared with `Customers.CustomerOf`) and `Country` (compared with the country of the order line address) are optional; an empty string is treated like `NULL`, i.e. no filter.\n\n**New customers**\nA customer counts as new in a month if the earliest `OrderDate` of all his order lines (within the shop/country filter) lies in that month of `Year`. Only the order lines with exactly this first order date are treated as the new-customer order; further orders in the same month count as orders of existing customers.\n\n**Report lines** (`GroupNumber` / `LineNumber`)\n- Group 1 – order counts:\n - 1 `Orders new customers`: number of customers whose first order falls in the month.\n - 2 `Orders customers`: line 3 minus line 1.\n - 3 `Total`: number of distinct order numbers in the month, excluding order lines with status `STO` or `NLB`.\n - 4 `rate new customers`: line 1 / line 3 × 100 (0 if line 3 is 0).\n- Group 2 – order values (sum of `OrderLineAmount`, order lines with status `STO`/`NLB` excluded):\n - 5 value of first orders of new customers.\n - 6 line 7 minus line 5.\n - 7 `Total`: value of all order lines of the month.\n - 8 share of new customers (line 5 / line 7 × 100), 9 share of existing customers (line 6 / line 7 × 100).\n- Group 3 – averages per order line:\n - 10 average `OrderLineAmount` of all candidate order lines in the month.\n - 11 average `OrderLineAmount` of the first-order lines of new customers.\n\n**Average column**: the arithmetic mean of the monthly values that exist for the line.\n\nRows are sorted by `LineNumber`. The columns `ParYear`, `ParShop` and `ParCountry` echo the effective parameters; `dbCurrency` contains the database currency code if multi-currency is enabled.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Year` | int | No | Report year. `NULL` means the current year. |\n| `Shop` | varchar(3) | No | Shop ID, compared with `Customers.CustomerOf`. `NULL` or empty string means all shops. |\n| `Country` | varchar(3) | No | Country code of the order line address. `NULL` or empty string means all countries. |\n\n- **Multi-currency**: if the setting `MultiCurrencyEnabled` is `1`, order values are converted into the database currency (setting `HomeCurrency`, exchange rate source from `DatabaseCurrencyExchRateSourceId`) using `pixi.ExchRate` of the order header's exchange date. Order lines without matching `OrderHeader` / exchange rate then drop out of the value lines. Otherwise the rate is 1 and `dbCurrency` is `NULL`.\n- **Label pitfall**: line 10 is labelled as average of new customers but averages *all* candidate order lines (including status `STO`/`NLB`), while line 11 is labelled as average of customers but averages the first-order lines of new customers. Lines 10 and 11 do not exclude `STO`/`NLB` order lines.\n- Averages in group 3 are per order line, not per order.\n- Lines 6, 7, 8, 9 and 10 only contain months that have order lines; other months stay `0` and are not included in `Average`, so `Average` is the mean of the months with data only.\n- First orders are determined without status filter; a customer whose earliest order line has status `STO`/`NLB` is still counted in line 1.\n- The new-customer determination uses inner joins on address and customer, so lines without country or `CustomerOf` are not considered, while the total lines accept `NULL` country/shop values.\n- A month can disappear from lines 2–4 if all its orders are removed by the filters.\n- All reads use `NOLOCK` (dirty reads possible). Line 3 joins order lines via `MONTH(OrderDate)`, which scans the whole `Orderlines` table and can be slow on large databases.\n\nDocumentation: https://pixi-api-docs.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": "Returns an overview of orders with billing address, order totals, net gross profit and currency, optionally filtered by order date and order number.\n\nReturns one row per order from `OrderHeader`, joined with the linked address (`AddrRef` = `AddrKey`) and the order currency.\n\n**Filters**\n- **Date range:** if `OrderDateFrom` is set, only orders whose `OrderDate` lies between `OrderDateFrom` and `OrderDateTo` (inclusive) are returned. If `OrderDateTo` is empty, it is set to the current date and time. If `OrderDateFrom` is empty, no date filter is applied, even if `OrderDateTo` is set.\n- **Order number:** if `OrderNrStart` is set, only orders with `OrderNr` >= `OrderNrStart` are returned.\n- Both filters are combined with AND.\n\n**Row limit and sort order**\n- The number of rows is limited to `RowCount` (default 1000).\n- Rows are sorted by `OrderNr` descending, so the newest orders (highest order numbers) come first.\n\n**Calculated value**\n- `GrossProfit_Netto` is the sum of `Qty * (Price_Net - SupplPrice)` over all order lines of the order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderDateFrom` | datetime | No | Start of the order date range (inclusive). If `NULL`, no date filter is applied. |\n| `OrderDateTo` | datetime | No | End of the order date range (inclusive). If `NULL` while `OrderDateFrom` is set, the current date and time is used. Ignored if `OrderDateFrom` is `NULL`. |\n| `OrderNrStart` | int | No | Lowest order number to return (`OrderNr` >= value). If `NULL`, no order number filter is applied. |\n| `RowCount` | int | No | Maximum number of rows to return. `0` means no limit. |\n\n- According to the code comment, the gross profit is calculated from the standard supplier price stored on the order line at the time of order (`SupplPrice`). It is **not comparable** with other gross profit reports in Pixi.\n- `GrossProfit_Netto` is `NULL` for orders without order lines.\n- Orders without a matching address or currency are excluded because of the inner joins.\n- The date comparison uses `BETWEEN` on a `datetime` value. A date-only `OrderDateTo` (e.g. `2024-03-31`) means midnight, so orders later on that day are not included. Pass the following day or a time of `23:59:59` instead.\n- Because rows are sorted descending and cut off by `RowCount`, `OrderNrStart` does not work as a forward paging cursor: you always get the highest order numbers that meet the filters. If more than `RowCount` orders match, the older ones are not returned.\n- `RowCount` is applied with `SET ROWCOUNT`. A value of `0` removes the limit.\n- All tables are read with `NOLOCK`, so uncommitted data may appear.\n- The call only reads data.\n\nDocumentation: https://pixi-api-docs.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": "Returns an overview of orders with billing address, order totals, net gross profit and currency, optionally filtered by order date and order number.\n\nReturns one row per order from `OrderHeader`, joined with the linked address (`AddrRef` = `AddrKey`) and the order currency.\n\n**Filters**\n- **Date range:** if `OrderDateFrom` is set, only orders whose `OrderDate` lies between `OrderDateFrom` and `OrderDateTo` (inclusive) are returned. If `OrderDateTo` is empty, it is set to the current date and time. If `OrderDateFrom` is empty, no date filter is applied, even if `OrderDateTo` is set.\n- **Order number:** if `OrderNrStart` is set, only orders with `OrderNr` >= `OrderNrStart` are returned.\n- Both filters are combined with AND.\n\n**Row limit and sort order**\n- The number of rows is limited to `RowCount` (default 1000).\n- Rows are sorted by `OrderNr` descending, so the newest orders (highest order numbers) come first.\n\n**Calculated value**\n- `GrossProfit_Netto` is the sum of `Qty * (Price_Net - SupplPrice)` over all order lines of the order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderDateFrom` | datetime | No | Start of the order date range (inclusive). If `NULL`, no date filter is applied. |\n| `OrderDateTo` | datetime | No | End of the order date range (inclusive). If `NULL` while `OrderDateFrom` is set, the current date and time is used. Ignored if `OrderDateFrom` is `NULL`. |\n| `OrderNrStart` | int | No | Lowest order number to return (`OrderNr` >= value). If `NULL`, no order number filter is applied. |\n| `RowCount` | int | No | Maximum number of rows to return. `0` means no limit. |\n\n- According to the code comment, the gross profit is calculated from the standard supplier price stored on the order line at the time of order (`SupplPrice`). It is **not comparable** with other gross profit reports in Pixi.\n- `GrossProfit_Netto` is `NULL` for orders without order lines.\n- Orders without a matching address or currency are excluded because of the inner joins.\n- The date comparison uses `BETWEEN` on a `datetime` value. A date-only `OrderDateTo` (e.g. `2024-03-31`) means midnight, so orders later on that day are not included. Pass the following day or a time of `23:59:59` instead.\n- Because rows are sorted descending and cut off by `RowCount`, `OrderNrStart` does not work as a forward paging cursor: you always get the highest order numbers that meet the filters. If more than `RowCount` orders match, the older ones are not returned.\n- `RowCount` is applied with `SET ROWCOUNT`. A value of `0` removes the limit.\n- All tables are read with `NOLOCK`, so uncommitted data may appear.\n- The call only reads data.\n\nDocumentation: https://pixi-api-docs.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": "Returns the number of distinct orders that currently have order lines on an active (non-expired) picklist, optionally filtered by shop.\n\nCounts how many orders are currently on a picklist.\n\n- An order line counts if its `orderLineKey` is referenced by a picklist item (`PLItem.PLIorderlineRef`) with `Expired = 0`.\n- The result is the number of **distinct** order numbers (`ordernr`) among these order lines, so an order with several lines on picklists counts once.\n- If `ShopID` is empty or `NULL`, all shops are included. Otherwise only order lines whose `OrdShopId` equals `ShopID` are counted.\n\nThe call returns one row with the single column `NrOfOrders`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | No | Shop ID to filter by. Empty or NULL counts orders of all shops. |\n\n- Both tables are read `WITH (NOLOCK)`; the count may include uncommitted changes and is meant as a dashboard figure.\n- The header comment mentions output parameters, but the procedure declares none; the value is only returned as a result set.\n- The shop filter is applied to the order line's `OrdShopId`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the number of distinct orders that currently have order lines on an active (non-expired) picklist, optionally filtered by shop.\n\nCounts how many orders are currently on a picklist.\n\n- An order line counts if its `orderLineKey` is referenced by a picklist item (`PLItem.PLIorderlineRef`) with `Expired = 0`.\n- The result is the number of **distinct** order numbers (`ordernr`) among these order lines, so an order with several lines on picklists counts once.\n- If `ShopID` is empty or `NULL`, all shops are included. Otherwise only order lines whose `OrdShopId` equals `ShopID` are counted.\n\nThe call returns one row with the single column `NrOfOrders`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | No | Shop ID to filter by. Empty or NULL counts orders of all shops. |\n\n- Both tables are read `WITH (NOLOCK)`; the count may include uncommitted changes and is meant as a dashboard figure.\n- The header comment mentions output parameters, but the procedure declares none; the value is only returned as a result set.\n- The shop filter is applied to the order line's `OrdShopId`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the number of orders created in a time range (default: today from 0:00 until now), optionally filtered by shop and grouped by location.\n\nDashboard report that counts received orders by their creation date (`OrderHeader.CreateDate`).\n\n**Time range**\n- `FromTime` defaults to the start of the current day (0:00).\n- `UntilTime` defaults to the current date and time.\n- Both bounds are inclusive.\n\n**Shop filter**\n- If `ShopID` is set, only orders that have at least one order line with `OrdShopID` = `ShopID` are counted. An empty string or NULL means all shops.\n\n**Mode depends on `PerLocation`**\n- `0` (default, also used for NULL): counts all orders in the range that have at least one order line (matching the shop filter). The count is returned as a single row with column `ReceivedOrders` and is also written to the output parameter `ReceivedOrders`.\n- `1`: joins orders with their order lines and returns one row per `LocationID` of the order lines with the number of distinct orders per location. No sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromTime` | datetime | No | Start of the time range (inclusive) for the order creation date. Defaults to today 0:00. |\n| `UntilTime` | datetime | No | End of the time range (inclusive). Defaults to the current date and time. |\n| `ShopID` | varchar(3) | No | Optional shop filter on `Orderlines.OrdShopID`. Empty or NULL counts orders of all shops. |\n| `ReceivedOrders` | int | No | Output: number of received orders. Only set when `PerLocation` = 0. |\n| `MinutesSinceRefresh` | int | No | Output parameter that is never set by the procedure; always NULL. |\n| `PerLocation` | bit | No | Selects the output mode: total count or count per location. NULL is treated as 0. |\n\n- All reads use `NOLOCK`, so counts may include uncommitted data.\n- The output parameter `MinutesSinceRefresh` is never set by the procedure and always returns NULL.\n- In per-location mode the output parameter `ReceivedOrders` is not set. An order with lines in several locations is counted once for each location, so the sum of all rows can exceed the total count of mode `0`.\n- Orders without any order lines are never counted.\n- Because of `NULLIF(..., '')` on datetime values, passing `1900-01-01 00:00:00` for `FromTime` or `UntilTime` is treated like NULL and replaced with the default.\n- The parameter `PerLocation` is marked with the code comment \"old way\".\n\nDocumentation: https://pixi-api-docs.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": "Returns the number of orders created in a time range (default: today from 0:00 until now), optionally filtered by shop and grouped by location.\n\nDashboard report that counts received orders by their creation date (`OrderHeader.CreateDate`).\n\n**Time range**\n- `FromTime` defaults to the start of the current day (0:00).\n- `UntilTime` defaults to the current date and time.\n- Both bounds are inclusive.\n\n**Shop filter**\n- If `ShopID` is set, only orders that have at least one order line with `OrdShopID` = `ShopID` are counted. An empty string or NULL means all shops.\n\n**Mode depends on `PerLocation`**\n- `0` (default, also used for NULL): counts all orders in the range that have at least one order line (matching the shop filter). The count is returned as a single row with column `ReceivedOrders` and is also written to the output parameter `ReceivedOrders`.\n- `1`: joins orders with their order lines and returns one row per `LocationID` of the order lines with the number of distinct orders per location. No sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromTime` | datetime | No | Start of the time range (inclusive) for the order creation date. Defaults to today 0:00. |\n| `UntilTime` | datetime | No | End of the time range (inclusive). Defaults to the current date and time. |\n| `ShopID` | varchar(3) | No | Optional shop filter on `Orderlines.OrdShopID`. Empty or NULL counts orders of all shops. |\n| `ReceivedOrders` | int | No | Output: number of received orders. Only set when `PerLocation` = 0. |\n| `MinutesSinceRefresh` | int | No | Output parameter that is never set by the procedure; always NULL. |\n| `PerLocation` | bit | No | Selects the output mode: total count or count per location. NULL is treated as 0. |\n\n- All reads use `NOLOCK`, so counts may include uncommitted data.\n- The output parameter `MinutesSinceRefresh` is never set by the procedure and always returns NULL.\n- In per-location mode the output parameter `ReceivedOrders` is not set. An order with lines in several locations is counted once for each location, so the sum of all rows can exceed the total count of mode `0`.\n- Orders without any order lines are never counted.\n- Because of `NULLIF(..., '')` on datetime values, passing `1900-01-01 00:00:00` for `FromTime` or `UntilTime` is treated like NULL and replaced with the default.\n- The parameter `PerLocation` is marked with the code comment \"old way\".\n\nDocumentation: https://pixi-api-docs.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": "Returns the total quantity of returned items (negative invoice lines) for a reference day, the previous day, the current month to date and the previous month.\n\nCalculates four return figures for a dashboard. A return is counted as an invoice line with a negative quantity (`ItemQty < 0`). The figure is the sum of the absolute quantities (`SUM(ABS(ItemQty))`), not the number of documents.\n\nSteps:\n\n- The reference day is `@EndDate`. If it is `NULL`, the current date is used. The time is set to the end of that day (23:59:59.997).\n- From the reference day, four periods are derived and matched against the invoice date (`InvDate`):\n - **Given day**: start to end of the reference day.\n - **Previous day**: the full calendar day before the reference day.\n - **Given month**: from the first day of the reference month up to the end of the reference day (month to date).\n - **Previous month**: the full calendar month before the reference month.\n- Invoice lines are joined to their invoice and the invoice's customer. If `@ShopID` is filled, only customers whose `CustomerOf` equals `@ShopID` are counted. If it is empty or `NULL`, all shops are included.\n\nThe call returns one row with the four values.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | No | Not used by the procedure. It has no effect on the result. |\n| `EndDate` | datetime | No | Reference day. All four periods are derived from it. The time part is ignored and set to the end of the day. If `NULL`, the current date is used. |\n| `ShopID` | varchar(3) | No | Optional shop filter, compared with `Customers.CustomerOf` of the invoice customer. Empty or `NULL` includes all shops. |\n\n- `@StartDate` is declared but **not used**. All periods are derived only from `@EndDate`.\n- All reads use `NOLOCK`. The figures can include uncommitted data.\n- Returns are taken from invoice lines (credit lines with negative quantity), not from a separate returns table.\n- The values are stored in `varchar(10)` variables and are returned as strings. Depending on the data type of `ItemQty`, they can contain decimal places.\n- If a period has no matching lines, its value is `NULL`. In the SOAP response the element is then usually missing.\n- If an error occurs while calculating, the procedure ends with return code `-1` and returns **no** result set. One possible cause is a sum that does not fit into `varchar(10)`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the total quantity of returned items (negative invoice lines) for a reference day, the previous day, the current month to date and the previous month.\n\nCalculates four return figures for a dashboard. A return is counted as an invoice line with a negative quantity (`ItemQty < 0`). The figure is the sum of the absolute quantities (`SUM(ABS(ItemQty))`), not the number of documents.\n\nSteps:\n\n- The reference day is `@EndDate`. If it is `NULL`, the current date is used. The time is set to the end of that day (23:59:59.997).\n- From the reference day, four periods are derived and matched against the invoice date (`InvDate`):\n - **Given day**: start to end of the reference day.\n - **Previous day**: the full calendar day before the reference day.\n - **Given month**: from the first day of the reference month up to the end of the reference day (month to date).\n - **Previous month**: the full calendar month before the reference month.\n- Invoice lines are joined to their invoice and the invoice's customer. If `@ShopID` is filled, only customers whose `CustomerOf` equals `@ShopID` are counted. If it is empty or `NULL`, all shops are included.\n\nThe call returns one row with the four values.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | No | Not used by the procedure. It has no effect on the result. |\n| `EndDate` | datetime | No | Reference day. All four periods are derived from it. The time part is ignored and set to the end of the day. If `NULL`, the current date is used. |\n| `ShopID` | varchar(3) | No | Optional shop filter, compared with `Customers.CustomerOf` of the invoice customer. Empty or `NULL` includes all shops. |\n\n- `@StartDate` is declared but **not used**. All periods are derived only from `@EndDate`.\n- All reads use `NOLOCK`. The figures can include uncommitted data.\n- Returns are taken from invoice lines (credit lines with negative quantity), not from a separate returns table.\n- The values are stored in `varchar(10)` variables and are returned as strings. Depending on the data type of `ItemQty`, they can contain decimal places.\n- If a period has no matching lines, its value is `NULL`. In the SOAP response the element is then usually missing.\n- If an error occurs while calculating, the procedure ends with return code `-1` and returns **no** result set. One possible cause is a sum that does not fit into `varchar(10)`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the number of scan-ins (order history status `EIN`) per time slot of a given length in hours within a date range, optionally for one shop.\n\nBuilds a time series of scan-in counts for dashboards.\n\n1. Defaults are applied: if `startDateTime` is NULL, the start of the current day (midnight) is used; if `endDateTime` is NULL, the current date and time is used; if `timePeriod` is passed as NULL, it becomes `1` (the declared default when the parameter is omitted is `2`).\n2. The range from `startDateTime` to `endDateTime` is split into consecutive slots of `timePeriod` hours (fractions such as `0.5` for 30 minutes are possible). The last slot is cut off at `endDateTime`.\n3. For each slot, the rows in `orderHistory` with `status = 'EIN'` and a `StatusChangeDate` between slot start and slot end (both inclusive) are counted.\n4. If `shopID` is empty or NULL, all shops are counted; otherwise only history rows of that shop.\n5. One row per slot is returned in chronological order, including slots with a count of `0`.\n\nIf `startDateTime` is not before `endDateTime`, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `startDateTime` | datetime | No | Start of the evaluated range. NULL means the start of the current day (00:00). |\n| `endDateTime` | datetime | No | End of the evaluated range. NULL means the current date and time. |\n| `timePeriod` | float | No | Length of one time slot in hours; fractions are allowed. Explicit NULL is treated as 1. Must be greater than 0. |\n| `shopID` | varchar(3) | No | Shop whose scan-ins are counted. Empty or NULL counts all shops. |\n\n- `orderHistory` is read `WITH (NOLOCK)`; counts may include uncommitted data.\n- Because `BETWEEN` includes both boundaries, a history entry exactly on a slot boundary is counted in two adjacent slots.\n- `startTimePeriod` and `endTimePeriod` are strings produced by `CONVERT(VARCHAR, …)` with the default style (e.g. `Jan 15 2024 8:00AM`); seconds are not shown and the format depends on the server language. Parse them accordingly or compute the slot times on the client side.\n- The `shopID` column echoes the passed parameter, so it is empty (or NULL) when all shops are counted.\n- Pitfall: a `timePeriod` of `0` or a negative value makes the loop never end; always pass a positive value.\n- Large ranges with small slots run one count query per slot and can be slow.\n\nDocumentation: https://pixi-api-docs.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": "Returns the number of scan-ins (order history status `EIN`) per time slot of a given length in hours within a date range, optionally for one shop.\n\nBuilds a time series of scan-in counts for dashboards.\n\n1. Defaults are applied: if `startDateTime` is NULL, the start of the current day (midnight) is used; if `endDateTime` is NULL, the current date and time is used; if `timePeriod` is passed as NULL, it becomes `1` (the declared default when the parameter is omitted is `2`).\n2. The range from `startDateTime` to `endDateTime` is split into consecutive slots of `timePeriod` hours (fractions such as `0.5` for 30 minutes are possible). The last slot is cut off at `endDateTime`.\n3. For each slot, the rows in `orderHistory` with `status = 'EIN'` and a `StatusChangeDate` between slot start and slot end (both inclusive) are counted.\n4. If `shopID` is empty or NULL, all shops are counted; otherwise only history rows of that shop.\n5. One row per slot is returned in chronological order, including slots with a count of `0`.\n\nIf `startDateTime` is not before `endDateTime`, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `startDateTime` | datetime | No | Start of the evaluated range. NULL means the start of the current day (00:00). |\n| `endDateTime` | datetime | No | End of the evaluated range. NULL means the current date and time. |\n| `timePeriod` | float | No | Length of one time slot in hours; fractions are allowed. Explicit NULL is treated as 1. Must be greater than 0. |\n| `shopID` | varchar(3) | No | Shop whose scan-ins are counted. Empty or NULL counts all shops. |\n\n- `orderHistory` is read `WITH (NOLOCK)`; counts may include uncommitted data.\n- Because `BETWEEN` includes both boundaries, a history entry exactly on a slot boundary is counted in two adjacent slots.\n- `startTimePeriod` and `endTimePeriod` are strings produced by `CONVERT(VARCHAR, …)` with the default style (e.g. `Jan 15 2024 8:00AM`); seconds are not shown and the format depends on the server language. Parse them accordingly or compute the slot times on the client side.\n- The `shopID` column echoes the passed parameter, so it is empty (or NULL) when all shops are counted.\n- Pitfall: a `timePeriod` of `0` or a negative value makes the loop never end; always pass a positive value.\n- Large ranges with small slots run one count query per slot and can be slow.\n\nDocumentation: https://pixi-api-docs.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": "Returns the number of scanned-out (shipped) invoices per time slot of a configurable length within a date range, optionally for one shop.\n\nSplits the range from `startDateTime` to `endDateTime` into consecutive slots of `timePeriod` hours. For each slot it counts the invoices whose `ScanOutdate` (scan-out time at shipping) lies in the slot, and returns one row per slot.\n\n- `startDateTime` defaults to the start of the current day (00:00), `endDateTime` defaults to the current time.\n- `timePeriod` is the slot length in hours and may be fractional (e.g. `0.5` = 30 minutes). Default is `2`. If `NULL` is passed explicitly, `1` hour is used.\n- The last slot ends at `endDateTime` and can be shorter than the others.\n- `shopID` filters on the shop the invoice's customer belongs to (`Customers.CustomerOf`). An empty string (default) counts invoices of all shops.\n- Every slot produces a row, including slots with a count of `0`.\n- Rows are returned in the order the slots were created, i.e. chronologically, although the final select has no explicit `ORDER BY`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `startDateTime` | datetime | No | Start of the evaluated range. `NULL` means the start of the current day (00:00). |\n| `endDateTime` | datetime | No | End of the evaluated range. `NULL` means the current time. |\n| `timePeriod` | float | No | Length of each time slot in hours; fractional values are allowed. An explicit `NULL` means 1 hour. Must be greater than 0. |\n| `shopID` | varchar(3) | No | Shop ID that the invoice's customer must belong to (`Customers.CustomerOf`). An empty string counts all shops. |\n\n- Reads `Invoices` and `Customers` with `NOLOCK`, so counts may include uncommitted data.\n- The slot filter uses `BETWEEN`, so both limits are included. An invoice scanned out exactly on a slot boundary is counted in two adjacent slots.\n- `startTimePeriod` and `endTimePeriod` are text in SQL Server's default datetime format (e.g. `Jan 15 2024 2:00PM`). They have minute precision, so seconds are lost.\n- The label `endTimePeriod` of the last slot is not shortened to `endDateTime`. It shows the full nominal slot end, even though the count only goes up to `endDateTime`.\n- The column `shopID` repeats the passed parameter value; it is an empty string when all shops are counted.\n- Slot limits are calculated by adding fractions of a day as `float`, so very small periods can produce rounding drift.\n- A `timePeriod` of `0` or a negative value makes the loop never end, because the slot start never moves forward. Always pass a positive value.\n- One query runs per slot, so long ranges with short periods can be slow.\n\nDocumentation: https://pixi-api-docs.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": "Returns the number of scanned-out (shipped) invoices per time slot of a configurable length within a date range, optionally for one shop.\n\nSplits the range from `startDateTime` to `endDateTime` into consecutive slots of `timePeriod` hours. For each slot it counts the invoices whose `ScanOutdate` (scan-out time at shipping) lies in the slot, and returns one row per slot.\n\n- `startDateTime` defaults to the start of the current day (00:00), `endDateTime` defaults to the current time.\n- `timePeriod` is the slot length in hours and may be fractional (e.g. `0.5` = 30 minutes). Default is `2`. If `NULL` is passed explicitly, `1` hour is used.\n- The last slot ends at `endDateTime` and can be shorter than the others.\n- `shopID` filters on the shop the invoice's customer belongs to (`Customers.CustomerOf`). An empty string (default) counts invoices of all shops.\n- Every slot produces a row, including slots with a count of `0`.\n- Rows are returned in the order the slots were created, i.e. chronologically, although the final select has no explicit `ORDER BY`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `startDateTime` | datetime | No | Start of the evaluated range. `NULL` means the start of the current day (00:00). |\n| `endDateTime` | datetime | No | End of the evaluated range. `NULL` means the current time. |\n| `timePeriod` | float | No | Length of each time slot in hours; fractional values are allowed. An explicit `NULL` means 1 hour. Must be greater than 0. |\n| `shopID` | varchar(3) | No | Shop ID that the invoice's customer must belong to (`Customers.CustomerOf`). An empty string counts all shops. |\n\n- Reads `Invoices` and `Customers` with `NOLOCK`, so counts may include uncommitted data.\n- The slot filter uses `BETWEEN`, so both limits are included. An invoice scanned out exactly on a slot boundary is counted in two adjacent slots.\n- `startTimePeriod` and `endTimePeriod` are text in SQL Server's default datetime format (e.g. `Jan 15 2024 2:00PM`). They have minute precision, so seconds are lost.\n- The label `endTimePeriod` of the last slot is not shortened to `endDateTime`. It shows the full nominal slot end, even though the count only goes up to `endDateTime`.\n- The column `shopID` repeats the passed parameter value; it is an empty string when all shops are counted.\n- Slot limits are calculated by adding fractions of a day as `float`, so very small periods can produce rounding drift.\n- A `timePeriod` of `0` or a negative value makes the loop never end, because the slot start never moves forward. Always pass a positive value.\n- One query runs per slot, so long ranges with short periods can be slow.\n\nDocumentation: https://pixi-api-docs.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": "Returns the stock movements of items with batch number or best-before-date management, filtered by date range, movement type, user, location, tag, category and supplier.\n\nWrapper around the internal report procedure `Report_StockMovementsForItemsWithBnBbd`. It lists entries of the stock movement log (`InvBinItemLog`) for items that carry the item tag `-6` or `-7` (batch number / best-before date).\n\n**Parameter handling**\n- Empty values (and `0` for the integer parameters) are treated as `NULL`, which means \"no filter\".\n- If `DateFrom` is missing, the start of the current day is used. If `DateTo` is missing, the end of the current day is used. The time part of both dates is ignored: `DateFrom` is moved to 00:00:00 and `DateTo` to 23:59:59.997 of the given day.\n\n**Parameter checks** (each failure returns one `Status`/`Message` row and stops the call)\n1. `LocID` must exist in `Location`.\n2. `ItemTag`, if given, must be `-6` or `-7`.\n3. `UserName` must occur as a substring of `UpdateEmp` in at least one log entry.\n4. `SMTKey` must exist in `StockMovementTypes`.\n5. `Category` must exist in `TontrArten`.\n\n`SupplNr` is not checked.\n\n**Filters**\n- Movement date (`UpdateDate`) between `DateFrom` and `DateTo`. This filter is always active.\n- `SMTKey`: the stock movement type of the log entry.\n- `UserName`: substring match (`LIKE '%…%'`) on the user who made the entry.\n- `LocID`: the location of the current bin (`InvBin.BinLocID`).\n- `ItemTag`: only items that carry this tag (`-6` or `-7`).\n- `Category`: the item's `ConfigType`.\n- `SupplNr`: the supplier taken from the latest supplier information valid at the movement date.\n\n**Output**\nOne row per movement with the item, bin, moved quantity, batch number, best-before date, movement type with its translated name, user, historical supplier price and database currency. The report sorts the rows by movement date in ascending order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | No | Start of the period (movement date). The time part is ignored and the day starts at 00:00:00. Default: start of the current day. |\n| `DateTo` | datetime | No | End of the period (movement date). The time part is ignored and the whole day up to 23:59:59.997 is included. Default: end of the current day. |\n| `SMTKey` | int | No | Key of the stock movement type (`StockMovementTypes.SMTKey`). It must exist. `NULL` or `0` means all types. |\n| `UserName` | varchar(100) | No | Substring of the user name stored in the movement log (`UpdateEmp`). At least one log entry must match. |\n| `LocID` | varchar(3) | No | Location ID (`Location.LocID`). It must exist. Filters on the location of the current bin. |\n| `ItemTag` | int | No | Restricts the result to items with this tag. Only `-6` and `-7` are accepted. `NULL` or `0` means both. |\n| `Category` | varchar(4) | No | Item category (`TontrArten.TontrArt`). It must exist and is compared with `Items.ConfigType`. |\n| `SupplNr` | varchar(4) | No | Supplier number. It is compared with the supplier of the latest supplier information valid at the movement date. It is not validated. |\n\n- All tables are read with `NOLOCK`, so uncommitted data can appear in the result.\n- The report itself sorts by movement date. The final `SELECT` from the temporary table has no `ORDER BY`, so the row order is not strictly guaranteed.\n- Because empty values are mapped to `NULL`, a `SMTKey` or `ItemTag` of `0` and a date of `1900-01-01` count as \"not set\".\n- `Stock` is `SUM(Items.Quantity)`. It is the item's total stock, not the stock in the bin. If several joined rows collapse into one group, the value can be a multiple of that stock.\n- `BinName` holds the current bin name. For deleted bins it holds the historical name followed by ` Deleted`. Deleted bins drop out of the result when `LocID` is set, because the location filter uses the current bin only.\n- If a movement has neither a current nor a deleted bin record, `BinName` is empty and the insert into the result table fails. This returns the \"Unexpected error\" row.\n- `SMTName` is the translation with `LanguageID = 2`.\n- `UserName` is the part of `UpdateEmp` before the first `/`.\n- The precheck for `UserName` (and for `LocID`) also fails when `InvBinItemLog` (or `Location`) is empty, even if no value was passed.\n- The supplier data come from the function `fPixi_GetLatestSupplierInfo`. Its definition is not attached, so the exact selection logic is not documented here.\n- The report runs as dynamic SQL via `sp_executesql`.\n- The report also computes the columns `ParamDateFrom` … `ParamSupplier`, but they are not returned to the caller.\n- A code comment names the tags `-6` and `-7` together as \"BN & BBD\".\n\nDocumentation: https://pixi-api-docs.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": "Returns the stock movements of items with batch number or best-before-date management, filtered by date range, movement type, user, location, tag, category and supplier.\n\nWrapper around the internal report procedure `Report_StockMovementsForItemsWithBnBbd`. It lists entries of the stock movement log (`InvBinItemLog`) for items that carry the item tag `-6` or `-7` (batch number / best-before date).\n\n**Parameter handling**\n- Empty values (and `0` for the integer parameters) are treated as `NULL`, which means \"no filter\".\n- If `DateFrom` is missing, the start of the current day is used. If `DateTo` is missing, the end of the current day is used. The time part of both dates is ignored: `DateFrom` is moved to 00:00:00 and `DateTo` to 23:59:59.997 of the given day.\n\n**Parameter checks** (each failure returns one `Status`/`Message` row and stops the call)\n1. `LocID` must exist in `Location`.\n2. `ItemTag`, if given, must be `-6` or `-7`.\n3. `UserName` must occur as a substring of `UpdateEmp` in at least one log entry.\n4. `SMTKey` must exist in `StockMovementTypes`.\n5. `Category` must exist in `TontrArten`.\n\n`SupplNr` is not checked.\n\n**Filters**\n- Movement date (`UpdateDate`) between `DateFrom` and `DateTo`. This filter is always active.\n- `SMTKey`: the stock movement type of the log entry.\n- `UserName`: substring match (`LIKE '%…%'`) on the user who made the entry.\n- `LocID`: the location of the current bin (`InvBin.BinLocID`).\n- `ItemTag`: only items that carry this tag (`-6` or `-7`).\n- `Category`: the item's `ConfigType`.\n- `SupplNr`: the supplier taken from the latest supplier information valid at the movement date.\n\n**Output**\nOne row per movement with the item, bin, moved quantity, batch number, best-before date, movement type with its translated name, user, historical supplier price and database currency. The report sorts the rows by movement date in ascending order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | No | Start of the period (movement date). The time part is ignored and the day starts at 00:00:00. Default: start of the current day. |\n| `DateTo` | datetime | No | End of the period (movement date). The time part is ignored and the whole day up to 23:59:59.997 is included. Default: end of the current day. |\n| `SMTKey` | int | No | Key of the stock movement type (`StockMovementTypes.SMTKey`). It must exist. `NULL` or `0` means all types. |\n| `UserName` | varchar(100) | No | Substring of the user name stored in the movement log (`UpdateEmp`). At least one log entry must match. |\n| `LocID` | varchar(3) | No | Location ID (`Location.LocID`). It must exist. Filters on the location of the current bin. |\n| `ItemTag` | int | No | Restricts the result to items with this tag. Only `-6` and `-7` are accepted. `NULL` or `0` means both. |\n| `Category` | varchar(4) | No | Item category (`TontrArten.TontrArt`). It must exist and is compared with `Items.ConfigType`. |\n| `SupplNr` | varchar(4) | No | Supplier number. It is compared with the supplier of the latest supplier information valid at the movement date. It is not validated. |\n\n- All tables are read with `NOLOCK`, so uncommitted data can appear in the result.\n- The report itself sorts by movement date. The final `SELECT` from the temporary table has no `ORDER BY`, so the row order is not strictly guaranteed.\n- Because empty values are mapped to `NULL`, a `SMTKey` or `ItemTag` of `0` and a date of `1900-01-01` count as \"not set\".\n- `Stock` is `SUM(Items.Quantity)`. It is the item's total stock, not the stock in the bin. If several joined rows collapse into one group, the value can be a multiple of that stock.\n- `BinName` holds the current bin name. For deleted bins it holds the historical name followed by ` Deleted`. Deleted bins drop out of the result when `LocID` is set, because the location filter uses the current bin only.\n- If a movement has neither a current nor a deleted bin record, `BinName` is empty and the insert into the result table fails. This returns the \"Unexpected error\" row.\n- `SMTName` is the translation with `LanguageID = 2`.\n- `UserName` is the part of `UpdateEmp` before the first `/`.\n- The precheck for `UserName` (and for `LocID`) also fails when `InvBinItemLog` (or `Location`) is empty, even if no value was passed.\n- The supplier data come from the function `fPixi_GetLatestSupplierInfo`. Its definition is not attached, so the exact selection logic is not documented here.\n- The report runs as dynamic SQL via `sp_executesql`.\n- The report also computes the columns `ParamDateFrom` … `ParamSupplier`, but they are not returned to the caller.\n- A code comment names the tags `-6` and `-7` together as \"BN & BBD\".\n\nDocumentation: https://pixi-api-docs.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": "Returns a paged stock range report per item: current stock, sales in a period, sales per day and the resulting stock range in days, sorted by stock range descending.\n\nCalculates how many days the current stock of each item will last based on past sales, and returns the items whose stock range is at least `MinStockRange` days. It is typically used to find slow-moving or overstocked items.\n\n**Calculation**\n\n1. For every item that has at least one stock record (`InvBinItem` joined to `InvBin`), the procedure computes:\n - `Stock`: sum of `BinItemQty` over all bins of the item.\n - `Sales`: sum of `ItemQty` of the invoice lines (`Invlines`) of the item that were created within the last `SalesDaysBack` days (calendar days). By default only lines with a positive quantity are counted. With `DeductReturns` = 1, all lines are counted, so negative lines such as credit notes reduce the sum.\n - `LastStockInc`: number of days since the most recent `UpdateDate` of the item's stock records.\n2. `SalesPerDay` = `Sales` / `SalesDaysBack`.\n3. `StockRange` = `Stock` / `SalesPerDay`, in days. If `Sales` is 0 or less, `StockRange` is set to `9999`.\n\n**Filters** (all combined with AND)\n\n- `SupplNr`: only items of this supplier (`items.SupplNR`).\n- `PriceMin` / `PriceMax`: limits on the item sales price (`items.Price`).\n- `LastStockIncDays`: only items whose `LastStockInc` is greater than this value.\n- `StockMin`: only items with `Stock` >= this value (default 0, so items with negative stock are excluded).\n- `MinStockRange`: only items with `StockRange` >= this value.\n- `ExcludeInhouseEAN` = 1: items whose `EANUPC` starts with `2` (in-house EAN numbers) are excluded.\n\n**Sorting and paging**\n\nThe filtered rows are numbered in `Row` by `StockRange` descending, then `ItemName`. The call returns at most `RowCount` rows with `Row` > `StartRow`, in the same order. To fetch the next page, pass the last `Row` received as `StartRow`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `RowCount` | int | No | Maximum number of rows returned (page size). 0 returns all rows. |\n| `StartRow` | int | No | Only rows with `Row` greater than this value are returned. NULL is treated as 0 (first page). |\n| `MinStockRange` | int | No | Minimum stock range in days; only items with `StockRange` >= this value are returned. NULL is treated as 0. |\n| `SalesDaysBack` | int | No | Length of the sales period in days, counted back from now. Also the divisor for `SalesPerDay`; must not be 0. |\n| `LastStockIncDays` | int | No | If set, only items whose stock records were last updated more than this number of days ago (`LastStockInc` > value). |\n| `StockMin` | int | No | Minimum total stock; only items with `Stock` >= this value. NULL is treated as 0. |\n| `PriceMin` | money | No | Minimum item sales price (`items.Price`). NULL or 0 means no filter. |\n| `PriceMax` | money | No | Maximum item sales price (`items.Price`). NULL or 0 means no filter. |\n| `SupplNr` | varchar(4) | No | Supplier number; only items of this supplier (`items.SupplNR`). NULL or empty means all suppliers. |\n| `ExcludeInhouseEAN` | bit | No | Whether items with in-house EAN numbers (starting with `2`) are excluded. |\n| `DeductReturns` | bit | No | Whether invoice lines with negative quantities (e.g. credit notes) are deducted from the sales quantity. |\n\n- All tables are read `WITH (NOLOCK)`, so the figures can include uncommitted data.\n- The calculation runs over all items with stock records and uses a correlated subquery on `Invlines` per item, so every call (also every page) recalculates the full report. On large databases this can be slow.\n- `SalesDaysBack` = 0 causes a division-by-zero SQL error, returned as `SqlMessage`. With `SalesDaysBack` = NULL no sales are counted, `SalesPerDay` is NULL and every item gets `StockRange` 9999.\n- `PriceMin` and `PriceMax` are normalised with `NULLIF(…, '')`; the empty string converts to the money value 0, so a value of `0` means *no filter*. In particular `PriceMax` = 0 does not restrict the result.\n- `SupplNr` = empty string is treated as NULL (no filter). `StartRow`, `StockMin` and `MinStockRange` = NULL are treated as 0.\n- `RowCount` is applied with `SET ROWCOUNT`; `RowCount` = 0 returns all matching rows.\n- With `ExcludeInhouseEAN` = 1, items without an `EANUPC` (NULL) are also excluded, because the `NOT LIKE` comparison is not true for NULL.\n- Despite its name, `LastStockInc` is based on the latest `UpdateDate` of the stock records, not specifically on the last stock increase.\n\nDocumentation: https://pixi-api-docs.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": "Returns a paged stock range report per item: current stock, sales in a period, sales per day and the resulting stock range in days, sorted by stock range descending.\n\nCalculates how many days the current stock of each item will last based on past sales, and returns the items whose stock range is at least `MinStockRange` days. It is typically used to find slow-moving or overstocked items.\n\n**Calculation**\n\n1. For every item that has at least one stock record (`InvBinItem` joined to `InvBin`), the procedure computes:\n - `Stock`: sum of `BinItemQty` over all bins of the item.\n - `Sales`: sum of `ItemQty` of the invoice lines (`Invlines`) of the item that were created within the last `SalesDaysBack` days (calendar days). By default only lines with a positive quantity are counted. With `DeductReturns` = 1, all lines are counted, so negative lines such as credit notes reduce the sum.\n - `LastStockInc`: number of days since the most recent `UpdateDate` of the item's stock records.\n2. `SalesPerDay` = `Sales` / `SalesDaysBack`.\n3. `StockRange` = `Stock` / `SalesPerDay`, in days. If `Sales` is 0 or less, `StockRange` is set to `9999`.\n\n**Filters** (all combined with AND)\n\n- `SupplNr`: only items of this supplier (`items.SupplNR`).\n- `PriceMin` / `PriceMax`: limits on the item sales price (`items.Price`).\n- `LastStockIncDays`: only items whose `LastStockInc` is greater than this value.\n- `StockMin`: only items with `Stock` >= this value (default 0, so items with negative stock are excluded).\n- `MinStockRange`: only items with `StockRange` >= this value.\n- `ExcludeInhouseEAN` = 1: items whose `EANUPC` starts with `2` (in-house EAN numbers) are excluded.\n\n**Sorting and paging**\n\nThe filtered rows are numbered in `Row` by `StockRange` descending, then `ItemName`. The call returns at most `RowCount` rows with `Row` > `StartRow`, in the same order. To fetch the next page, pass the last `Row` received as `StartRow`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `RowCount` | int | No | Maximum number of rows returned (page size). 0 returns all rows. |\n| `StartRow` | int | No | Only rows with `Row` greater than this value are returned. NULL is treated as 0 (first page). |\n| `MinStockRange` | int | No | Minimum stock range in days; only items with `StockRange` >= this value are returned. NULL is treated as 0. |\n| `SalesDaysBack` | int | No | Length of the sales period in days, counted back from now. Also the divisor for `SalesPerDay`; must not be 0. |\n| `LastStockIncDays` | int | No | If set, only items whose stock records were last updated more than this number of days ago (`LastStockInc` > value). |\n| `StockMin` | int | No | Minimum total stock; only items with `Stock` >= this value. NULL is treated as 0. |\n| `PriceMin` | money | No | Minimum item sales price (`items.Price`). NULL or 0 means no filter. |\n| `PriceMax` | money | No | Maximum item sales price (`items.Price`). NULL or 0 means no filter. |\n| `SupplNr` | varchar(4) | No | Supplier number; only items of this supplier (`items.SupplNR`). NULL or empty means all suppliers. |\n| `ExcludeInhouseEAN` | bit | No | Whether items with in-house EAN numbers (starting with `2`) are excluded. |\n| `DeductReturns` | bit | No | Whether invoice lines with negative quantities (e.g. credit notes) are deducted from the sales quantity. |\n\n- All tables are read `WITH (NOLOCK)`, so the figures can include uncommitted data.\n- The calculation runs over all items with stock records and uses a correlated subquery on `Invlines` per item, so every call (also every page) recalculates the full report. On large databases this can be slow.\n- `SalesDaysBack` = 0 causes a division-by-zero SQL error, returned as `SqlMessage`. With `SalesDaysBack` = NULL no sales are counted, `SalesPerDay` is NULL and every item gets `StockRange` 9999.\n- `PriceMin` and `PriceMax` are normalised with `NULLIF(…, '')`; the empty string converts to the money value 0, so a value of `0` means *no filter*. In particular `PriceMax` = 0 does not restrict the result.\n- `SupplNr` = empty string is treated as NULL (no filter). `StartRow`, `StockMin` and `MinStockRange` = NULL are treated as 0.\n- `RowCount` is applied with `SET ROWCOUNT`; `RowCount` = 0 returns all matching rows.\n- With `ExcludeInhouseEAN` = 1, items without an `EANUPC` (NULL) are also excluded, because the `NOT LIKE` comparison is not true for NULL.\n- Despite its name, `LastStockInc` is based on the latest `UpdateDate` of the stock records, not specifically on the last stock increase.\n\nDocumentation: https://pixi-api-docs.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": "Returns a per-item overview of current stock, stock movements, invoiced sales and returns since a given date, with paging by item key.\n\nBuilds a stock and sales report for all items in `Items`.\n\nFor each item the call calculates:\n\n- **Average supplier price** (`SupplPrice`): the average `SupplPrice` from `AddItems` for the item's `IntLinkNr1`. Supplier `MGS` and empty or zero prices are ignored. If no price is found, the value is `0`.\n- **Current stock** (`StockQty`): the sum of `BinItemQty` over all bin locations (Lagerplätze) in `InvBinItem`, `0` if the item has no bin entry.\n- **Stock increases / decreases** (`StockInc`, `StockDec`): the sum of positive or negative quantities in the bin item log `InvBinItemLog` with `UpdateDate >= @StatDateFrom`.\n- **First put to stock** (`FirstPutToStock`): the earliest log entry with a positive quantity. This value does **not** use `@StatDateFrom`.\n- **Sold / returned quantity** (`ItemQtySold`, `ItemQtyReturned`): the sum of positive or negative `ItemQty` in invoice lines (`InvLines`) with `CreateDate >= @StatDateFrom`.\n- **Last sale date** (`LastSaleDate`): the latest `CreateDate` of these invoice lines.\n\nThe category text comes from `TontrArten` and is matched by the item's `ConfigType`.\n\nFilters:\n\n- `@StatDateFrom`: start of the statistics period. If it is `NULL`, `1970-01-01` is used, so all history is included.\n- `@ItemKeyStart`: only items with `ItemKey >= @ItemKeyStart` are returned. `NULL` means no lower limit.\n- `@OnlyItemsOnStock = 1`: only items with a current stock greater than 0 are returned.\n\nThe result is sorted by `ItemKey` ascending. `SET ROWCOUNT @RowCount` limits the number of rows. For paging, pass the last returned `ItemKey` + 1 as `@ItemKeyStart` in the next call.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StatDateFrom` | datetime | No | Start of the statistics period for stock movements and invoice lines. If it is `NULL`, `1970-01-01` is used. |\n| `ItemKeyStart` | int | No | Returns only items with `ItemKey` greater than or equal to this value. Used for paging. `NULL` means no lower limit. |\n| `OnlyItemsOnStock` | bit | No | Restricts the result to items with a current stock greater than 0. |\n| `RowCount` | int | No | Maximum number of rows returned, applied via `SET ROWCOUNT`. `0` means no limit. |\n\n- All tables are read with `NOLOCK`. Values can therefore include uncommitted data.\n- The aggregations in the CTEs run over **all** items. The filters `@ItemKeyStart` and `@OnlyItemsOnStock` are applied only in the final `SELECT`. Depending on the optimizer, the call can be slow on large databases. In addition, the scalar function `fPixi_GetAverageSupplPrice` is evaluated per item.\n- `StockDec` and `ItemQtyReturned` are negative values or `0`.\n- `LastSaleDate` is `NULL` if there are no invoice lines in the period. `FirstPutToStock` is `NULL` if the item was never put to stock.\n- `@RowCount = 0` removes the row limit, because this is the behaviour of `SET ROWCOUNT 0`.\n\nDocumentation: https://pixi-api-docs.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": "Returns a per-item overview of current stock, stock movements, invoiced sales and returns since a given date, with paging by item key.\n\nBuilds a stock and sales report for all items in `Items`.\n\nFor each item the call calculates:\n\n- **Average supplier price** (`SupplPrice`): the average `SupplPrice` from `AddItems` for the item's `IntLinkNr1`. Supplier `MGS` and empty or zero prices are ignored. If no price is found, the value is `0`.\n- **Current stock** (`StockQty`): the sum of `BinItemQty` over all bin locations (Lagerplätze) in `InvBinItem`, `0` if the item has no bin entry.\n- **Stock increases / decreases** (`StockInc`, `StockDec`): the sum of positive or negative quantities in the bin item log `InvBinItemLog` with `UpdateDate >= @StatDateFrom`.\n- **First put to stock** (`FirstPutToStock`): the earliest log entry with a positive quantity. This value does **not** use `@StatDateFrom`.\n- **Sold / returned quantity** (`ItemQtySold`, `ItemQtyReturned`): the sum of positive or negative `ItemQty` in invoice lines (`InvLines`) with `CreateDate >= @StatDateFrom`.\n- **Last sale date** (`LastSaleDate`): the latest `CreateDate` of these invoice lines.\n\nThe category text comes from `TontrArten` and is matched by the item's `ConfigType`.\n\nFilters:\n\n- `@StatDateFrom`: start of the statistics period. If it is `NULL`, `1970-01-01` is used, so all history is included.\n- `@ItemKeyStart`: only items with `ItemKey >= @ItemKeyStart` are returned. `NULL` means no lower limit.\n- `@OnlyItemsOnStock = 1`: only items with a current stock greater than 0 are returned.\n\nThe result is sorted by `ItemKey` ascending. `SET ROWCOUNT @RowCount` limits the number of rows. For paging, pass the last returned `ItemKey` + 1 as `@ItemKeyStart` in the next call.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StatDateFrom` | datetime | No | Start of the statistics period for stock movements and invoice lines. If it is `NULL`, `1970-01-01` is used. |\n| `ItemKeyStart` | int | No | Returns only items with `ItemKey` greater than or equal to this value. Used for paging. `NULL` means no lower limit. |\n| `OnlyItemsOnStock` | bit | No | Restricts the result to items with a current stock greater than 0. |\n| `RowCount` | int | No | Maximum number of rows returned, applied via `SET ROWCOUNT`. `0` means no limit. |\n\n- All tables are read with `NOLOCK`. Values can therefore include uncommitted data.\n- The aggregations in the CTEs run over **all** items. The filters `@ItemKeyStart` and `@OnlyItemsOnStock` are applied only in the final `SELECT`. Depending on the optimizer, the call can be slow on large databases. In addition, the scalar function `fPixi_GetAverageSupplPrice` is evaluated per item.\n- `StockDec` and `ItemQtyReturned` are negative values or `0`.\n- `LastSaleDate` is `NULL` if there are no invoice lines in the period. `FirstPutToStock` is `NULL` if the item was never put to stock.\n- `@RowCount = 0` removes the row limit, because this is the behaviour of `SET ROWCOUNT 0`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the stock value report: stock per article and location at a given date, with gross/net sales price, purchase price, gross profit and totals.\n\nWrapper around the internal report procedure `Report_StockValue`. All parameters are passed through unchanged.\n\n**Steps**\n\n1. The key date is set to the end of the day of `ParamDate`. If `ParamDate` is omitted, the end of the current day is used.\n2. The stock is rebuilt from the stock movement log `InvBinItemLog`. All movements with `UpdateDate` up to the key date are summed per location (`LocID`) and article. Only combinations with a non-zero sum are kept, so negative stock is included.\n3. If `LocID` is given and not empty, only movements of that location are considered. Otherwise all locations are included.\n4. Each stock row is joined to the article (`Items`). Rows whose article does not exist are dropped.\n5. Per article, the latest supplier information valid at the key date is determined. It provides the sales price `Price`, the purchase price `SupplPrice` and the supplier number. The supplier name comes from `Suppliers`, and the category text comes from `TontrArten` via `Items.ConfigType`.\n6. The VAT rate is determined for the default country and the key date, based on the article's `MwStSatz`:\n - `1` = high rate\n - `2` = low rate\n - any other value = no VAT; the price is treated as net.\n7. Filters:\n - If `SupplNr` is given and not empty, only articles whose latest supplier is that supplier are returned.\n - If `Category` is given and not empty, only articles with `ConfigType` = `Category` are returned.\n8. One row per article and location is returned, sorted by the internal article key.\n\n**Calculated values**\n\n- `VK_Netto` = gross price divided by (1 + VAT rate)\n- `Rohertrag` = `VK_Netto` − `EK` per unit\n- `Sum_*` = stock quantity × unit value\n\nThe columns `par_*` echo the effective filter values. Filters that are not set appear as `-alle-`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ParamDate` | datetime | No | Key date of the report. The stock and prices are evaluated as of the end of this day. NULL = today. |\n| `LocID` | varchar(10) | No | Location (warehouse) filter. NULL or empty = all locations. |\n| `Category` | varchar(10) | No | Article category filter, compared with `Items.ConfigType`. NULL or empty = all categories. |\n| `SupplNr` | varchar(10) | No | Supplier filter, compared with the supplier of the latest supplier information at the key date. NULL or empty = all suppliers. |\n\n- Read-only. Most tables are read `WITH (NOLOCK)`, so the result can contain uncommitted data. `Items` is read without a hint.\n- The stock is recalculated from the complete movement log up to the key date. This can be slow for large histories; use filters where possible.\n- Only the date part of `ParamDate` matters, because the time is always moved to the end of the day.\n- The location column of the internal stage table is `varchar(3)`, although `LocID` accepts up to 10 characters.\n- When `SupplNr` is set, articles without supplier information are excluded. Without the filter they are returned with NULL prices.\n- `Rohertrah` (sic, spelled differently from `Rohertrag`) is the total gross profit. It is `0` for articles whose `MwStSatz` is neither 1 nor 2, whereas `Rohertrag` is still calculated for them.\n- The output column `MwStSatz` contains the VAT rate in percent, not the article's VAT code.\n- The helper functions `fPixi_GetLatestSupplierInfo`, `fPixi_GetVATRate`, `fPixi_GetDefaultCountryCode`, `fPixi_GetDateEndOfDay` and `pixi.GetDatabaseCurrency` are not attached. Their exact logic, for example how the \"latest\" supplier information is chosen, and the data types of the price columns are therefore not documented here.\n\nDocumentation: https://pixi-api-docs.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": "Returns the stock value report: stock per article and location at a given date, with gross/net sales price, purchase price, gross profit and totals.\n\nWrapper around the internal report procedure `Report_StockValue`. All parameters are passed through unchanged.\n\n**Steps**\n\n1. The key date is set to the end of the day of `ParamDate`. If `ParamDate` is omitted, the end of the current day is used.\n2. The stock is rebuilt from the stock movement log `InvBinItemLog`. All movements with `UpdateDate` up to the key date are summed per location (`LocID`) and article. Only combinations with a non-zero sum are kept, so negative stock is included.\n3. If `LocID` is given and not empty, only movements of that location are considered. Otherwise all locations are included.\n4. Each stock row is joined to the article (`Items`). Rows whose article does not exist are dropped.\n5. Per article, the latest supplier information valid at the key date is determined. It provides the sales price `Price`, the purchase price `SupplPrice` and the supplier number. The supplier name comes from `Suppliers`, and the category text comes from `TontrArten` via `Items.ConfigType`.\n6. The VAT rate is determined for the default country and the key date, based on the article's `MwStSatz`:\n - `1` = high rate\n - `2` = low rate\n - any other value = no VAT; the price is treated as net.\n7. Filters:\n - If `SupplNr` is given and not empty, only articles whose latest supplier is that supplier are returned.\n - If `Category` is given and not empty, only articles with `ConfigType` = `Category` are returned.\n8. One row per article and location is returned, sorted by the internal article key.\n\n**Calculated values**\n\n- `VK_Netto` = gross price divided by (1 + VAT rate)\n- `Rohertrag` = `VK_Netto` − `EK` per unit\n- `Sum_*` = stock quantity × unit value\n\nThe columns `par_*` echo the effective filter values. Filters that are not set appear as `-alle-`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ParamDate` | datetime | No | Key date of the report. The stock and prices are evaluated as of the end of this day. NULL = today. |\n| `LocID` | varchar(10) | No | Location (warehouse) filter. NULL or empty = all locations. |\n| `Category` | varchar(10) | No | Article category filter, compared with `Items.ConfigType`. NULL or empty = all categories. |\n| `SupplNr` | varchar(10) | No | Supplier filter, compared with the supplier of the latest supplier information at the key date. NULL or empty = all suppliers. |\n\n- Read-only. Most tables are read `WITH (NOLOCK)`, so the result can contain uncommitted data. `Items` is read without a hint.\n- The stock is recalculated from the complete movement log up to the key date. This can be slow for large histories; use filters where possible.\n- Only the date part of `ParamDate` matters, because the time is always moved to the end of the day.\n- The location column of the internal stage table is `varchar(3)`, although `LocID` accepts up to 10 characters.\n- When `SupplNr` is set, articles without supplier information are excluded. Without the filter they are returned with NULL prices.\n- `Rohertrah` (sic, spelled differently from `Rohertrag`) is the total gross profit. It is `0` for articles whose `MwStSatz` is neither 1 nor 2, whereas `Rohertrag` is still calculated for them.\n- The output column `MwStSatz` contains the VAT rate in percent, not the article's VAT code.\n- The helper functions `fPixi_GetLatestSupplierInfo`, `fPixi_GetVATRate`, `fPixi_GetDefaultCountryCode`, `fPixi_GetDateEndOfDay` and `pixi.GetDatabaseCurrency` are not attached. Their exact logic, for example how the \"latest\" supplier information is chosen, and the data types of the price columns are therefore not documented here.\n\nDocumentation: https://pixi-api-docs.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": "Returns the historical stock value per item on a given date, valued at historical supplier prices and net sales prices.\n\nWrapper around the internal report procedure `Report_StockValue_Hist`. It always runs with `ShowDetails = 0`. Supplier matching always uses the main supplier of the item (`AllItemsForSupplier = 0`).\n\nSteps:\n\n1. **Reference date**: `ParamDate` is moved to the end of that day. If it is omitted, the end of the current day is used.\n2. **Item filter**: Empty strings for `LocID`, `Category` and `SupplNr` count as \"no filter\".\n - `SupplNr` filters on the item's main supplier (`Items.SupplNr`).\n - `Category` filters on `Items.ConfigType`.\n3. **Stock at the reference date**: For each item, all quantity movements in `InvBinItemLog` up to the reference date are summed.\n - With `LocID`, only bins of that location (`InvBin.BinLocID`) are counted.\n - Movements on bins that were deleted after the reference date are also counted. These bins are found in `InvBinHist` with remark `Deleted`.\n - Items whose resulting quantity is 0 are dropped.\n4. **Historical supplier prices**: The stock quantities are passed to internal helper procedures. These determine historical purchase prices from supplier deliveries, so one item can appear in several rows, one per supplier delivery that makes up the stock.\n5. **Sales price**:\n - `VK_Netto` is the gross price `Items.Price` divided by (1 + VAT rate), rounded to 2 decimals.\n - The VAT rate comes from the item's `MwStSatz`: `1` = high rate, `2` = reduced rate, any other value = 0. Rates are those of the default country.\n\nThe result is sorted by `Artikelname`, then `SupplDelDate`, then VAT rate.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ParamDate` | datetime | No | Reference date for the stock value. The end of that day is used. If omitted, the end of the current day is used. |\n| `LocID` | varchar(10) | No | Location ID. Only stock on bins of this location is counted. Empty or omitted means all locations. |\n| `Category` | varchar(10) | No | Item category, compared with `Items.ConfigType`. Empty or omitted means all categories. |\n| `SupplNr` | varchar(10) | No | Supplier number. Only items whose main supplier (`Items.SupplNr`) matches are included. Empty or omitted means all suppliers. |\n\n- All permanent tables are read `WITH (NOLOCK)`, so the result can contain uncommitted data.\n- The historical supplier prices come from `Report_SaveSupplierPrices` and `pixi_HistorySupplierPriceForItems`. Their definitions are not attached. Whether they write to permanent tables, and exactly how `SupplPriceHist`, `SupplPriceType` and `SupplPriceMessage` are determined, cannot be seen here.\n- VAT rates are taken for the current date, not for `ParamDate`. Historical rate changes are therefore not reflected in `VK_Netto`.\n- `Bestand` is the total stock of the item on the reference date and is repeated on every delivery row of that item. Use `SupplDelQty` for per-row sums. `Sum_VK_Netto` and `Sum_SupplPriceHist` are already based on `SupplDelQty`.\n- `par_Category` and `par_SupplNR` contain `-alle-` when no filter is set. Otherwise they contain the category text and the supplier **name** of the item, not the number.\n- The report evaluates the whole bin movement log and can be slow on large databases.\n\nDocumentation: https://pixi-api-docs.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": "Returns the historical stock value per item on a given date, valued at historical supplier prices and net sales prices.\n\nWrapper around the internal report procedure `Report_StockValue_Hist`. It always runs with `ShowDetails = 0`. Supplier matching always uses the main supplier of the item (`AllItemsForSupplier = 0`).\n\nSteps:\n\n1. **Reference date**: `ParamDate` is moved to the end of that day. If it is omitted, the end of the current day is used.\n2. **Item filter**: Empty strings for `LocID`, `Category` and `SupplNr` count as \"no filter\".\n - `SupplNr` filters on the item's main supplier (`Items.SupplNr`).\n - `Category` filters on `Items.ConfigType`.\n3. **Stock at the reference date**: For each item, all quantity movements in `InvBinItemLog` up to the reference date are summed.\n - With `LocID`, only bins of that location (`InvBin.BinLocID`) are counted.\n - Movements on bins that were deleted after the reference date are also counted. These bins are found in `InvBinHist` with remark `Deleted`.\n - Items whose resulting quantity is 0 are dropped.\n4. **Historical supplier prices**: The stock quantities are passed to internal helper procedures. These determine historical purchase prices from supplier deliveries, so one item can appear in several rows, one per supplier delivery that makes up the stock.\n5. **Sales price**:\n - `VK_Netto` is the gross price `Items.Price` divided by (1 + VAT rate), rounded to 2 decimals.\n - The VAT rate comes from the item's `MwStSatz`: `1` = high rate, `2` = reduced rate, any other value = 0. Rates are those of the default country.\n\nThe result is sorted by `Artikelname`, then `SupplDelDate`, then VAT rate.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ParamDate` | datetime | No | Reference date for the stock value. The end of that day is used. If omitted, the end of the current day is used. |\n| `LocID` | varchar(10) | No | Location ID. Only stock on bins of this location is counted. Empty or omitted means all locations. |\n| `Category` | varchar(10) | No | Item category, compared with `Items.ConfigType`. Empty or omitted means all categories. |\n| `SupplNr` | varchar(10) | No | Supplier number. Only items whose main supplier (`Items.SupplNr`) matches are included. Empty or omitted means all suppliers. |\n\n- All permanent tables are read `WITH (NOLOCK)`, so the result can contain uncommitted data.\n- The historical supplier prices come from `Report_SaveSupplierPrices` and `pixi_HistorySupplierPriceForItems`. Their definitions are not attached. Whether they write to permanent tables, and exactly how `SupplPriceHist`, `SupplPriceType` and `SupplPriceMessage` are determined, cannot be seen here.\n- VAT rates are taken for the current date, not for `ParamDate`. Historical rate changes are therefore not reflected in `VK_Netto`.\n- `Bestand` is the total stock of the item on the reference date and is repeated on every delivery row of that item. Use `SupplDelQty` for per-row sums. `Sum_VK_Netto` and `Sum_SupplPriceHist` are already based on `SupplDelQty`.\n- `par_Category` and `par_SupplNR` contain `-alle-` when no filter is set. Otherwise they contain the category text and the supplier **name** of the item, not the number.\n- The report evaluates the whole bin movement log and can be slow on large databases.\n\nDocumentation: https://pixi-api-docs.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": "Returns all items with a given item tag together with stock quantity at a cut-off date, last known purchase price, invoice discounts and resulting stock value.\n\nBuilds a stock valuation report based on historical purchase (EK) prices for all items that carry a specific item tag.\n\nSteps:\n\n1. Looks up the item tag `@ItemTag` (tag type `1`) and checks that the shop `@ShopID` exists. If either is missing, the error `Tag or Shop does not exist` is raised (see notes, execution is not stopped).\n2. Selects all items linked to the tag. For each item it determines:\n - **Anschaffungsdatum**: the date of the first bin log entry with a positive quantity (first put to stock, not limited by the date range).\n - **EK-Preis netto**: the final price of the most recent supplier delivery line with a delivered quantity > 0 and a price > 0; if there is none, the item's supplier price is used.\n3. Calculates the stock quantity as the sum of all bin log movements of the item with an update date before `@DateTo` (across all locations and bins).\n4. Sums the discounts from invoice lines of invoices of shop `@ShopID` with an invoice date in the range `@DateFrom` (inclusive) to `@DateTo` (exclusive). The discount per line is quantity × discount value, converted to a net amount by dividing by the high or low VAT rate of the invoice depending on the line's VAT code (`H`/`L`).\n - If the setting `MultiCurrencyEnabled` is `1`, the discount is additionally converted into the database currency using the exchange rate of the database currency's exchange rate source for the invoice's exchange date and currency.\n5. Returns one row per tagged item with price, quantity, total purchase value, discounts and the resulting total (`EK Gesamt netto` minus `Bewertungsabschläge`).\n\nThe result has no explicit sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | No | Shop whose invoices are used for the discount calculation. Must exist, otherwise an error is raised. |\n| `ItemTag` | varchar(50) | No | Name of the item tag (tag type 1). Only items linked to this tag are reported. Must exist, otherwise an error is raised. |\n| `DateFrom` | datetime | No | Start of the invoice date range for discounts (inclusive). |\n| `DateTo` | datetime | No | Cut-off date (exclusive): end of the invoice date range and date up to which stock movements are summed. |\n\n- **Error does not stop execution**: `RAISERROR` with severity 16 is not followed by a `RETURN`. The caller receives the error message, but the procedure continues. With an unknown tag the result set is empty; with an unknown shop but a valid tag the items are still returned, only without discounts.\n- `@ShopID` is effectively required: `NULL` never matches an existing shop and triggers the error.\n- `@DateTo` and `@DateFrom` are effectively required: with `@DateTo` = `NULL` no stock is calculated and the price always falls back to the item's supplier price; with `@DateFrom` = `NULL` no discounts are found.\n- **Purchase price pitfall**: the date condition for the last delivery price compares the item's creation date with `@DateTo`, not the delivery date. The price is therefore the most recent delivery price overall (including deliveries after `@DateTo`), as long as the item was created before `@DateTo`.\n- Stock is not restricted to a shop or location; all bin log movements are summed.\n- `dbCurrency` contains the database currency code only if `MultiCurrencyEnabled` = `1`; otherwise it is `NULL` and amounts are in the original invoice currency.\n- All reads use `NOLOCK`, so results may include uncommitted data.\n- Column names contain spaces; in the SOAP/DataSet XML they appear encoded, e.g. `EK-Preis_x0020_netto`.\n\nDocumentation: https://pixi-api-docs.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": "Returns all items with a given item tag together with stock quantity at a cut-off date, last known purchase price, invoice discounts and resulting stock value.\n\nBuilds a stock valuation report based on historical purchase (EK) prices for all items that carry a specific item tag.\n\nSteps:\n\n1. Looks up the item tag `@ItemTag` (tag type `1`) and checks that the shop `@ShopID` exists. If either is missing, the error `Tag or Shop does not exist` is raised (see notes, execution is not stopped).\n2. Selects all items linked to the tag. For each item it determines:\n - **Anschaffungsdatum**: the date of the first bin log entry with a positive quantity (first put to stock, not limited by the date range).\n - **EK-Preis netto**: the final price of the most recent supplier delivery line with a delivered quantity > 0 and a price > 0; if there is none, the item's supplier price is used.\n3. Calculates the stock quantity as the sum of all bin log movements of the item with an update date before `@DateTo` (across all locations and bins).\n4. Sums the discounts from invoice lines of invoices of shop `@ShopID` with an invoice date in the range `@DateFrom` (inclusive) to `@DateTo` (exclusive). The discount per line is quantity × discount value, converted to a net amount by dividing by the high or low VAT rate of the invoice depending on the line's VAT code (`H`/`L`).\n - If the setting `MultiCurrencyEnabled` is `1`, the discount is additionally converted into the database currency using the exchange rate of the database currency's exchange rate source for the invoice's exchange date and currency.\n5. Returns one row per tagged item with price, quantity, total purchase value, discounts and the resulting total (`EK Gesamt netto` minus `Bewertungsabschläge`).\n\nThe result has no explicit sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShopID` | varchar(3) | No | Shop whose invoices are used for the discount calculation. Must exist, otherwise an error is raised. |\n| `ItemTag` | varchar(50) | No | Name of the item tag (tag type 1). Only items linked to this tag are reported. Must exist, otherwise an error is raised. |\n| `DateFrom` | datetime | No | Start of the invoice date range for discounts (inclusive). |\n| `DateTo` | datetime | No | Cut-off date (exclusive): end of the invoice date range and date up to which stock movements are summed. |\n\n- **Error does not stop execution**: `RAISERROR` with severity 16 is not followed by a `RETURN`. The caller receives the error message, but the procedure continues. With an unknown tag the result set is empty; with an unknown shop but a valid tag the items are still returned, only without discounts.\n- `@ShopID` is effectively required: `NULL` never matches an existing shop and triggers the error.\n- `@DateTo` and `@DateFrom` are effectively required: with `@DateTo` = `NULL` no stock is calculated and the price always falls back to the item's supplier price; with `@DateFrom` = `NULL` no discounts are found.\n- **Purchase price pitfall**: the date condition for the last delivery price compares the item's creation date with `@DateTo`, not the delivery date. The price is therefore the most recent delivery price overall (including deliveries after `@DateTo`), as long as the item was created before `@DateTo`.\n- Stock is not restricted to a shop or location; all bin log movements are summed.\n- `dbCurrency` contains the database currency code only if `MultiCurrencyEnabled` = `1`; otherwise it is `NULL` and amounts are in the original invoice currency.\n- All reads use `NOLOCK`, so results may include uncommitted data.\n- Column names contain spaces; in the SOAP/DataSet XML they appear encoded, e.g. `EK-Preis_x0020_netto`.\n\nDocumentation: https://pixi-api-docs.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": "Returns net invoice turnover for the given day, the day before, the current month and the previous month, optionally filtered by shop.\n\nDashboard report that sums `Total_Net` of invoices (`Invoices`) into four turnover figures and returns them as one row.\n\n**Date handling**\n- `toDate` defaults to the current date and time. Its time part matters: the given day and the given month are counted only up to `toDate`, not to the end of that day.\n- `fromDate` defaults to the first day of the month before `toDate`. If `fromDate` is later than `toDate`, it is set to `toDate`.\n- Only invoices with `InvDate` between the start of the previous month and `toDate` are considered at all.\n\n**Shop filter**\nAn invoice is counted only if its customer (`CustRef`) has at least one address in `Addresses` with `AddrShopID` = `ShopID`. An empty or NULL `ShopID` includes all invoices that have any address.\n\n**The four figures**\n- `TurnoverNetGivenDate`: if `fromDate` is in a different month than `toDate`, invoices from the start of the `toDate` day up to `toDate`; if `fromDate` is on the same day as `toDate`, invoices from `fromDate` to `toDate`.\n- `TurnoverNetDayBefore`: if `fromDate` is in a different month, the whole day before `toDate`; additionally, if `fromDate` falls on the day before `toDate`, invoices from `fromDate` to the end of that day.\n- `TurnoverNetGivenMonth`: if `fromDate` is in a different month, from the 1st of the `toDate` month up to `toDate`; if in the same month, from `fromDate` up to `toDate`.\n- `TurnoverNetPreviousMonth`: if `fromDate` is before the previous month, the whole previous month; if `fromDate` is in the previous month, from `fromDate` to the end of the previous month.\n\nWith the default `fromDate` the result is: today up to now, yesterday, month to date and the full previous month.\n\n**Currency**\nIf the setting `MultiCurrencyEnabled` is `1`, each invoice amount is divided by the exchange rate from `pixi.ExchRate` for the database exchange-rate source (`DatabaseCurrencyExchRateSourceId`) and home currency, matched by exchange-rate date and currency of the invoice's rate. `dbCurrency` then contains the database currency code. Otherwise the amounts are summed as stored and `dbCurrency` is NULL.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `fromDate` | datetime | No | Start of the evaluation period. Defaults to the first day of the month before `toDate`; set to `toDate` if later than `toDate`. Determines which period each figure covers (see description). |\n| `toDate` | datetime | No | Reference date and time (end of the period). Defaults to the current date and time. |\n| `ShopID` | varchar(3) | No | Shop filter: only invoices of customers with an address of this shop are counted. Empty means all shops. |\n\n- All reads use `NOLOCK`; figures may include uncommitted data.\n- The values are returned as strings (`varchar(30)`). A figure is NULL (element missing in the row) if no invoice matches its period, e.g. `TurnoverNetGivenDate` and `TurnoverNetDayBefore` are NULL when `fromDate` is in the same month as `toDate` but neither on that day nor on the day before. `TurnoverNetPreviousMonth` is NULL when `fromDate` lies in the current month.\n- A `fromDate` earlier than the start of the previous month has no extra effect, because older invoices are never loaded.\n- In multi-currency mode, invoices without a matching exchange rate record (or without `ExchRateId`) are silently excluded because of inner joins. The number of decimal places in the string depends on the data type of `ExchRate`, which is not visible here.\n- If the setting `MultiCurrencyEnabled` is missing (NULL), the code still takes the conversion branch, but `dbCurrency` is returned as NULL.\n- On any SQL error the procedure only prints the message and returns `-1`; no result set is returned.\n- The temporary table is dropped via `util.TempTableDrop` (definition not attached).\n\nDocumentation: https://pixi-api-docs.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": "Returns net invoice turnover for the given day, the day before, the current month and the previous month, optionally filtered by shop.\n\nDashboard report that sums `Total_Net` of invoices (`Invoices`) into four turnover figures and returns them as one row.\n\n**Date handling**\n- `toDate` defaults to the current date and time. Its time part matters: the given day and the given month are counted only up to `toDate`, not to the end of that day.\n- `fromDate` defaults to the first day of the month before `toDate`. If `fromDate` is later than `toDate`, it is set to `toDate`.\n- Only invoices with `InvDate` between the start of the previous month and `toDate` are considered at all.\n\n**Shop filter**\nAn invoice is counted only if its customer (`CustRef`) has at least one address in `Addresses` with `AddrShopID` = `ShopID`. An empty or NULL `ShopID` includes all invoices that have any address.\n\n**The four figures**\n- `TurnoverNetGivenDate`: if `fromDate` is in a different month than `toDate`, invoices from the start of the `toDate` day up to `toDate`; if `fromDate` is on the same day as `toDate`, invoices from `fromDate` to `toDate`.\n- `TurnoverNetDayBefore`: if `fromDate` is in a different month, the whole day before `toDate`; additionally, if `fromDate` falls on the day before `toDate`, invoices from `fromDate` to the end of that day.\n- `TurnoverNetGivenMonth`: if `fromDate` is in a different month, from the 1st of the `toDate` month up to `toDate`; if in the same month, from `fromDate` up to `toDate`.\n- `TurnoverNetPreviousMonth`: if `fromDate` is before the previous month, the whole previous month; if `fromDate` is in the previous month, from `fromDate` to the end of the previous month.\n\nWith the default `fromDate` the result is: today up to now, yesterday, month to date and the full previous month.\n\n**Currency**\nIf the setting `MultiCurrencyEnabled` is `1`, each invoice amount is divided by the exchange rate from `pixi.ExchRate` for the database exchange-rate source (`DatabaseCurrencyExchRateSourceId`) and home currency, matched by exchange-rate date and currency of the invoice's rate. `dbCurrency` then contains the database currency code. Otherwise the amounts are summed as stored and `dbCurrency` is NULL.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `fromDate` | datetime | No | Start of the evaluation period. Defaults to the first day of the month before `toDate`; set to `toDate` if later than `toDate`. Determines which period each figure covers (see description). |\n| `toDate` | datetime | No | Reference date and time (end of the period). Defaults to the current date and time. |\n| `ShopID` | varchar(3) | No | Shop filter: only invoices of customers with an address of this shop are counted. Empty means all shops. |\n\n- All reads use `NOLOCK`; figures may include uncommitted data.\n- The values are returned as strings (`varchar(30)`). A figure is NULL (element missing in the row) if no invoice matches its period, e.g. `TurnoverNetGivenDate` and `TurnoverNetDayBefore` are NULL when `fromDate` is in the same month as `toDate` but neither on that day nor on the day before. `TurnoverNetPreviousMonth` is NULL when `fromDate` lies in the current month.\n- A `fromDate` earlier than the start of the previous month has no extra effect, because older invoices are never loaded.\n- In multi-currency mode, invoices without a matching exchange rate record (or without `ExchRateId`) are silently excluded because of inner joins. The number of decimal places in the string depends on the data type of `ExchRate`, which is not visible here.\n- If the setting `MultiCurrencyEnabled` is missing (NULL), the code still takes the conversion branch, but `dbCurrency` is returned as NULL.\n- On any SQL error the procedure only prints the message and returns `-1`; no result set is returned.\n- The temporary table is dropped via `util.TempTableDrop` (definition not attached).\n\nDocumentation: https://pixi-api-docs.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": "Adds a line for an invoice line to an existing return case, or creates a new empty return case if no return case ID is passed.\n\nThe call behaves differently depending on `RET_ID`.\n\n**`RET_ID` is `NULL` or `0`**\n\n- `pixiCreateReturnCase` is executed with `ReturnDate`, `ReceiversComment` and `Employee`. It creates a new return case header in `RET_CASES` with status `NEW` and returns its `RET_ID` and `RET_NUMBER`.\n- **No return line is added** in this case. The new ID is not taken over internally. To add the line, the call has to be repeated with the returned `RET_ID`.\n\n**`RET_ID` is set (not `0`)**\n\nA row is inserted into `RET_CASE_LINES` only if all of these conditions are met:\n\n- the invoice line `InvLineKey` exists and has `ItemQty > 0`;\n- `ItemQty >= QuantityToReturn`;\n- the linked order line has status `AUS`;\n- there is no credit note that refers to the same invoice (`RefToInvoiceKey`) and contains a line for the same order line.\n\nThe new line gets these values:\n\n- status `AOK` if `ItemOk = 1`, otherwise `DAM`;\n- the customer comment, receiver comment and return reason, with `NULL` stored as an empty string;\n- the quantity `QuantityToReturn` and the reference to the invoice line;\n- create date `GETDATE()` and create employee ` (API)`, or `API` if no employee is given.\n\nAfterwards the call always returns one row with the return case ID and the ID of the new line. If no line was inserted because a condition was not met, `RET_LINE_ID` is `NULL`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvLineKey` | int | Yes | Key of the invoice line (`Invlines.InvLineKey`) that is returned. |\n| `QuantityToReturn` | int | Yes | Returned quantity. It must not be larger than the invoiced quantity `ItemQty`. |\n| `ItemOk` | bit | No | Condition of the returned item. It determines the line status. |\n| `RET_ID` | int | No | ID of the existing return case that the line is added to. `NULL` or `0` creates a new empty return case instead, without adding a line. |\n| `ReturnReason` | varchar(2048) | No | Return reason stored on the line. |\n| `CustomersComment` | varchar(2048) | No | Comment of the customer, stored on the line. |\n| `ReceiversComment` | varchar(2048) | No | Comment of the receiving employee. It is stored on the new return case header, or on the line when a line is added. |\n| `Employee` | varchar(50) | No | Employee name. It is stored as ` (API)`, or as `API` if empty. |\n| `ReturnDate` | datetime | No | Return date of a newly created return case. The default is the current date. It is ignored when `RET_ID` is given. |\n\n- **Pitfall:** without `RET_ID` only an empty return case is created. `InvLineKey`, `QuantityToReturn`, `ItemOk`, `ReturnReason` and `CustomersComment` are ignored in that case. Use the returned `RET_ID` in a second call.\n- The call raises no error if a condition fails. Check `RET_LINE_ID` for `NULL` to detect that no line was inserted.\n- The code does not check whether the invoice line is already part of another return line. Repeated calls can create several return lines for the same invoice line, as long as each quantity is not larger than `ItemQty`.\n- The code does not check whether the given `RET_ID` exists, and it does not reject negative quantities.\n- `ReturnDate` is only used when a new return case is created.\n- `ReceiversComment` is stored on the return case header when one is created, and on the line when a line is added.\n- If `ItemOk` is `NULL`, the line gets status `DAM`.\n- The invoice and order lines are read with `NOLOCK`.\n- No explicit transaction is used.\n\nDocumentation: https://pixi-api-docs.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": "Adds a line for an invoice line to an existing return case, or creates a new empty return case if no return case ID is passed.\n\nThe call behaves differently depending on `RET_ID`.\n\n**`RET_ID` is `NULL` or `0`**\n\n- `pixiCreateReturnCase` is executed with `ReturnDate`, `ReceiversComment` and `Employee`. It creates a new return case header in `RET_CASES` with status `NEW` and returns its `RET_ID` and `RET_NUMBER`.\n- **No return line is added** in this case. The new ID is not taken over internally. To add the line, the call has to be repeated with the returned `RET_ID`.\n\n**`RET_ID` is set (not `0`)**\n\nA row is inserted into `RET_CASE_LINES` only if all of these conditions are met:\n\n- the invoice line `InvLineKey` exists and has `ItemQty > 0`;\n- `ItemQty >= QuantityToReturn`;\n- the linked order line has status `AUS`;\n- there is no credit note that refers to the same invoice (`RefToInvoiceKey`) and contains a line for the same order line.\n\nThe new line gets these values:\n\n- status `AOK` if `ItemOk = 1`, otherwise `DAM`;\n- the customer comment, receiver comment and return reason, with `NULL` stored as an empty string;\n- the quantity `QuantityToReturn` and the reference to the invoice line;\n- create date `GETDATE()` and create employee ` (API)`, or `API` if no employee is given.\n\nAfterwards the call always returns one row with the return case ID and the ID of the new line. If no line was inserted because a condition was not met, `RET_LINE_ID` is `NULL`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvLineKey` | int | Yes | Key of the invoice line (`Invlines.InvLineKey`) that is returned. |\n| `QuantityToReturn` | int | Yes | Returned quantity. It must not be larger than the invoiced quantity `ItemQty`. |\n| `ItemOk` | bit | No | Condition of the returned item. It determines the line status. |\n| `RET_ID` | int | No | ID of the existing return case that the line is added to. `NULL` or `0` creates a new empty return case instead, without adding a line. |\n| `ReturnReason` | varchar(2048) | No | Return reason stored on the line. |\n| `CustomersComment` | varchar(2048) | No | Comment of the customer, stored on the line. |\n| `ReceiversComment` | varchar(2048) | No | Comment of the receiving employee. It is stored on the new return case header, or on the line when a line is added. |\n| `Employee` | varchar(50) | No | Employee name. It is stored as ` (API)`, or as `API` if empty. |\n| `ReturnDate` | datetime | No | Return date of a newly created return case. The default is the current date. It is ignored when `RET_ID` is given. |\n\n- **Pitfall:** without `RET_ID` only an empty return case is created. `InvLineKey`, `QuantityToReturn`, `ItemOk`, `ReturnReason` and `CustomersComment` are ignored in that case. Use the returned `RET_ID` in a second call.\n- The call raises no error if a condition fails. Check `RET_LINE_ID` for `NULL` to detect that no line was inserted.\n- The code does not check whether the invoice line is already part of another return line. Repeated calls can create several return lines for the same invoice line, as long as each quantity is not larger than `ItemQty`.\n- The code does not check whether the given `RET_ID` exists, and it does not reject negative quantities.\n- `ReturnDate` is only used when a new return case is created.\n- `ReceiversComment` is stored on the return case header when one is created, and on the line when a line is added.\n- If `ItemOk` is `NULL`, the line gets status `DAM`.\n- The invoice and order lines are read with `NOLOCK`.\n- No explicit transaction is used.\n\nDocumentation: https://pixi-api-docs.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": "Creates a return credit note for selected lines of an invoice, sets the order lines to returned and books the credit to the customer account.\n\nThe API counterpart of the returns wizard in Customer Service. It prepares the values and then calls the internal procedure `Pixi_CreateReturn`.\n\n**Input lists**\n- `InvoiceLines`, `Quantities` and `Prices` are parallel lists separated by `;` (a trailing `;` is added if missing). Entry *n* of each list belongs to the same invoice line.\n- `Prices` are gross unit prices. The net price is calculated per line as `Price / (1 + TaxRate/100)` using the tax rate of the invoice line.\n- Each invoice line key is translated into its order line (`Invlines.OrderLineRef`).\n\n**Steps**\n1. The first invoice line in `InvoiceLines` determines the shipping country and the settings `VATinShipCost` / `ChargeHighVATInShipCost` of the original invoice.\n2. If no VAT rate is valid today for this country: with *Force Country VAT* enabled the call fails; otherwise a default VAT rate is inserted for the country (`Pixi_InsertDefaultVATRateForCountry`).\n3. The invoice header is read by `InvoiceNr`: customer, billing and shipping address, voucher, currency (the return is always done in the order currency).\n4. Defaults: `ShipCost` = minus the shipping cost of the invoice (full shipping refund); `Voucher_Amount` = voucher sum of the invoice (gross for `B2C`, otherwise net).\n5. Total: minus the sum of quantity × price, plus `ShipCost`, minus `Voucher_Amount`, plus `ReturnCostsAmount`. If the return costs would make the total positive, they are reduced so that the total becomes 0.\n6. `Pixi_CreateReturn` creates the credit note: only lines that belong to the referenced invoice and whose order line has status `AUS` are credited. With a smaller quantity the order line is split first. The credited order lines get status `RET`, the credit is booked to the customer account, lines of the return case `ReturnCaseID` are closed and a history entry is written, matching `pixi.Return` records in status *Received* are set to *Credited*, and the event `InvoiceCreated` is published.\n7. If `MarkReturnDocumentForPrinting` = 1, `TimesPrinted` of the new credit note is set to 0 so it is printed again.\n\nThe call returns the header of the new credit note as one row.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Yes | Number of the original invoice that is returned. |\n| `InvoiceLines` | varchar(max) | Yes | Semicolon-separated list of invoice line keys (`InvLineKey`) to credit. The first key determines the shipping country check. |\n| `Quantities` | varchar(max) | Yes | Semicolon-separated return quantities, one per entry in `InvoiceLines`. |\n| `Prices` | varchar(max) | Yes | Semicolon-separated gross unit prices to credit, one per entry in `InvoiceLines`. |\n| `PaymentType` | char(1) | Yes | Payment type code for the refund, stored on the credit note. |\n| `Account` | varchar(10) | No | Bank account number for the refund; spaces are removed and the value is stored on the billing address. |\n| `BLZ` | char(8) | No | Bank code (BLZ) for the refund; spaces are removed. |\n| `AccountName` | varchar(27) | Yes | Account holder name. |\n| `ShipCost` | money | No | Shipping cost to credit, as a negative value. NULL refunds the full shipping cost of the invoice; 0 refunds no shipping cost. |\n| `Note` | varchar(255) | No | Note on the credit note. |\n| `ReturnReason` | varchar(100) | No | Return reason stored on the credit note. |\n| `CreateDate` | datetime | No | Creation date; defaults to now. It is passed on but not used by the internal procedure. |\n| `CreateEmp` | varchar(50) | No | User name recorded as creator of the credit note and of all changes. |\n| `InvoiceDate` | datetime | No | Date of the credit note; overridden by the current date in the internal procedure, so it has no effect. |\n| `ReturnClosed` | bit | No | Whether the return is marked as closed. |\n| `ReturnCaseID` | int | No | ID of a Returns & Repairs case; its lines for the credited invoice lines are closed and a history entry is written. |\n| `CreateDTAUS` | bit | No | Whether a DTAUS/bank transfer is to be created for the refund. Ignored (0) if `DoNotRefund` = 1. |\n| `DoNotRefund` | bit | No | If 1, the credit is not refunded via the customer account. |\n| `CAComment` | varchar(1000) | No | Comment saved to the customer account history entry of the credit note. |\n| `IBAN` | varchar(30) | No | IBAN for the refund, stored on the billing address. |\n| `BIC` | varchar(11) | No | BIC for the refund, stored on the billing address. |\n| `LanguageId` | int | No | Language for the translated return case history text. |\n| `ReturnCostsAmount` | money | No | Return costs charged to the customer (positive value). Any value other than 0 enables return costs; reduced if it would exceed the credited amount. |\n| `Voucher_Amount` | money | No | Voucher amount deducted from the credit. NULL uses the voucher sum of the invoice (gross for B2C, net otherwise). |\n| `MarkReturnDocumentForPrinting` | bit | No | If 1, the new credit note is marked for printing (`TimesPrinted` = 0). |\n\n- Runs in its own transaction (or a savepoint if a transaction is already open). Errors are caught, the transaction is rolled back and the error is logged with `log.InsertError` (not attached); whether the error is passed to the caller is not visible in the code. A failed call can therefore look like a call with an empty result.\n- Use `.` as decimal separator in `Prices`; values are cast to `money`.\n- The list parser removes the processed key with `REPLACE`. Duplicate keys or a key that is the ending of a later key (e.g. `23;123;`) break the parsing. Pass each invoice line only once.\n- Lines whose order line is not in status `AUS` or that do not belong to the invoice `InvoiceNr` are silently skipped, but are still included in the calculated total.\n- `CreateDate` and `InvoiceDate` have no effect: the credit note date is always the current date.\n- `DoNotRefund` = 1 forces `CreateDTAUS` to 0.\n- `TimesPrinted` in the returned row shows the value before `MarkReturnDocumentForPrinting` is applied.\n- The column `1SS` is not a valid XML element name; use `OneSS` instead.\n- Reads use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Creates a return credit note for selected lines of an invoice, sets the order lines to returned and books the credit to the customer account.\n\nThe API counterpart of the returns wizard in Customer Service. It prepares the values and then calls the internal procedure `Pixi_CreateReturn`.\n\n**Input lists**\n- `InvoiceLines`, `Quantities` and `Prices` are parallel lists separated by `;` (a trailing `;` is added if missing). Entry *n* of each list belongs to the same invoice line.\n- `Prices` are gross unit prices. The net price is calculated per line as `Price / (1 + TaxRate/100)` using the tax rate of the invoice line.\n- Each invoice line key is translated into its order line (`Invlines.OrderLineRef`).\n\n**Steps**\n1. The first invoice line in `InvoiceLines` determines the shipping country and the settings `VATinShipCost` / `ChargeHighVATInShipCost` of the original invoice.\n2. If no VAT rate is valid today for this country: with *Force Country VAT* enabled the call fails; otherwise a default VAT rate is inserted for the country (`Pixi_InsertDefaultVATRateForCountry`).\n3. The invoice header is read by `InvoiceNr`: customer, billing and shipping address, voucher, currency (the return is always done in the order currency).\n4. Defaults: `ShipCost` = minus the shipping cost of the invoice (full shipping refund); `Voucher_Amount` = voucher sum of the invoice (gross for `B2C`, otherwise net).\n5. Total: minus the sum of quantity × price, plus `ShipCost`, minus `Voucher_Amount`, plus `ReturnCostsAmount`. If the return costs would make the total positive, they are reduced so that the total becomes 0.\n6. `Pixi_CreateReturn` creates the credit note: only lines that belong to the referenced invoice and whose order line has status `AUS` are credited. With a smaller quantity the order line is split first. The credited order lines get status `RET`, the credit is booked to the customer account, lines of the return case `ReturnCaseID` are closed and a history entry is written, matching `pixi.Return` records in status *Received* are set to *Credited*, and the event `InvoiceCreated` is published.\n7. If `MarkReturnDocumentForPrinting` = 1, `TimesPrinted` of the new credit note is set to 0 so it is printed again.\n\nThe call returns the header of the new credit note as one row.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | Yes | Number of the original invoice that is returned. |\n| `InvoiceLines` | varchar(max) | Yes | Semicolon-separated list of invoice line keys (`InvLineKey`) to credit. The first key determines the shipping country check. |\n| `Quantities` | varchar(max) | Yes | Semicolon-separated return quantities, one per entry in `InvoiceLines`. |\n| `Prices` | varchar(max) | Yes | Semicolon-separated gross unit prices to credit, one per entry in `InvoiceLines`. |\n| `PaymentType` | char(1) | Yes | Payment type code for the refund, stored on the credit note. |\n| `Account` | varchar(10) | No | Bank account number for the refund; spaces are removed and the value is stored on the billing address. |\n| `BLZ` | char(8) | No | Bank code (BLZ) for the refund; spaces are removed. |\n| `AccountName` | varchar(27) | Yes | Account holder name. |\n| `ShipCost` | money | No | Shipping cost to credit, as a negative value. NULL refunds the full shipping cost of the invoice; 0 refunds no shipping cost. |\n| `Note` | varchar(255) | No | Note on the credit note. |\n| `ReturnReason` | varchar(100) | No | Return reason stored on the credit note. |\n| `CreateDate` | datetime | No | Creation date; defaults to now. It is passed on but not used by the internal procedure. |\n| `CreateEmp` | varchar(50) | No | User name recorded as creator of the credit note and of all changes. |\n| `InvoiceDate` | datetime | No | Date of the credit note; overridden by the current date in the internal procedure, so it has no effect. |\n| `ReturnClosed` | bit | No | Whether the return is marked as closed. |\n| `ReturnCaseID` | int | No | ID of a Returns & Repairs case; its lines for the credited invoice lines are closed and a history entry is written. |\n| `CreateDTAUS` | bit | No | Whether a DTAUS/bank transfer is to be created for the refund. Ignored (0) if `DoNotRefund` = 1. |\n| `DoNotRefund` | bit | No | If 1, the credit is not refunded via the customer account. |\n| `CAComment` | varchar(1000) | No | Comment saved to the customer account history entry of the credit note. |\n| `IBAN` | varchar(30) | No | IBAN for the refund, stored on the billing address. |\n| `BIC` | varchar(11) | No | BIC for the refund, stored on the billing address. |\n| `LanguageId` | int | No | Language for the translated return case history text. |\n| `ReturnCostsAmount` | money | No | Return costs charged to the customer (positive value). Any value other than 0 enables return costs; reduced if it would exceed the credited amount. |\n| `Voucher_Amount` | money | No | Voucher amount deducted from the credit. NULL uses the voucher sum of the invoice (gross for B2C, net otherwise). |\n| `MarkReturnDocumentForPrinting` | bit | No | If 1, the new credit note is marked for printing (`TimesPrinted` = 0). |\n\n- Runs in its own transaction (or a savepoint if a transaction is already open). Errors are caught, the transaction is rolled back and the error is logged with `log.InsertError` (not attached); whether the error is passed to the caller is not visible in the code. A failed call can therefore look like a call with an empty result.\n- Use `.` as decimal separator in `Prices`; values are cast to `money`.\n- The list parser removes the processed key with `REPLACE`. Duplicate keys or a key that is the ending of a later key (e.g. `23;123;`) break the parsing. Pass each invoice line only once.\n- Lines whose order line is not in status `AUS` or that do not belong to the invoice `InvoiceNr` are silently skipped, but are still included in the calculated total.\n- `CreateDate` and `InvoiceDate` have no effect: the credit note date is always the current date.\n- `DoNotRefund` = 1 forces `CreateDTAUS` to 0.\n- `TimesPrinted` in the returned row shows the value before `MarkReturnDocumentForPrinting` is applied.\n- The column `1SS` is not a valid XML element name; use `OneSS` instead.\n- Reads use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new return case with status NEW and returns its ID and return number.\n\nInserts one new record into `RET_CASES` and returns the identifiers of the new return case.\n\nThe new record is filled as follows:\n\n- `CreateDate`: current server date and time.\n- `CreateEmp`: the value of `Employee` followed by ` (API)`. If `Employee` is NULL, the value `API` is used.\n- `RETURN_DATE`: the value of `ReturnDate`. If it is NULL, the current server date and time is used.\n- `STATUS`: always `NEW`.\n- `RECEIVERS_COMMENT`: the value of `ReceiversComment`.\n\nAfter the insert, the call reads the new record by its identity value (`SCOPE_IDENTITY()`) and returns one row with `RET_ID` and `RET_NUMBER`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ReturnDate` | datetime | Yes | Date of the return. If NULL, the current server date and time is used. |\n| `ReceiversComment` | varchar(max) | Yes | Comment of the receiver, stored in `RECEIVERS_COMMENT`. May be NULL. |\n| `Employee` | varchar(50) | Yes | Employee short name. Stored as creator with the suffix ` (API)`; if NULL, `API` is stored. |\n\n- All three parameters have no SQL default and must be sent in the request. NULL values are accepted: `Employee` and `ReturnDate` are replaced as described; `ReceiversComment` is stored as NULL.\n- The call only creates the return case header. No order, items or return lines are linked; this has to be done with other calls.\n- `RET_NUMBER` is not set by this procedure. It is presumably generated by the database (column default, computed column or trigger on `RET_CASES`), which is not visible in the code.\n- The suffix ` (API)` adds 6 characters to `Employee`; whether the result fits into `CreateEmp` depends on the column length, which is not visible in the code.\n- The result row is read with `NOLOCK`. The insert and the select are not wrapped in an explicit transaction.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new return case with status NEW and returns its ID and return number.\n\nInserts one new record into `RET_CASES` and returns the identifiers of the new return case.\n\nThe new record is filled as follows:\n\n- `CreateDate`: current server date and time.\n- `CreateEmp`: the value of `Employee` followed by ` (API)`. If `Employee` is NULL, the value `API` is used.\n- `RETURN_DATE`: the value of `ReturnDate`. If it is NULL, the current server date and time is used.\n- `STATUS`: always `NEW`.\n- `RECEIVERS_COMMENT`: the value of `ReceiversComment`.\n\nAfter the insert, the call reads the new record by its identity value (`SCOPE_IDENTITY()`) and returns one row with `RET_ID` and `RET_NUMBER`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ReturnDate` | datetime | Yes | Date of the return. If NULL, the current server date and time is used. |\n| `ReceiversComment` | varchar(max) | Yes | Comment of the receiver, stored in `RECEIVERS_COMMENT`. May be NULL. |\n| `Employee` | varchar(50) | Yes | Employee short name. Stored as creator with the suffix ` (API)`; if NULL, `API` is stored. |\n\n- All three parameters have no SQL default and must be sent in the request. NULL values are accepted: `Employee` and `ReturnDate` are replaced as described; `ReceiversComment` is stored as NULL.\n- The call only creates the return case header. No order, items or return lines are linked; this has to be done with other calls.\n- `RET_NUMBER` is not set by this procedure. It is presumably generated by the database (column default, computed column or trigger on `RET_CASES`), which is not visible in the code.\n- The suffix ` (API)` adds 6 characters to `Employee`; whether the result fits into `CreateEmp` depends on the column length, which is not visible in the code.\n- The result row is read with `NOLOCK`. The insert and the select are not wrapped in an explicit transaction.\n\nDocumentation: https://pixi-api-docs.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": "Returns items whose most frequent return reason occurs more often than a given threshold, together with that reason and its count.\n\nAnalyses return reasons recorded on invoice lines and lists the items that are returned repeatedly for the same reason.\n\nFor every item in `Items`, the procedure looks at all invoice lines (`invlines` joined to `invoices` via `InvoiceRef = InvoiceKey`) that reference the item (`ItemRef`) and have a non-NULL `ReturnReason`. These lines are grouped by `ReturnReason`, and the reason with the highest number of lines is taken as the item's top return reason.\n\n- An item is included only if the count of its top return reason is **strictly greater** than `MinNrOfReturns`. With the default of `2`, the top reason must occur at least 3 times.\n- Items without any invoice line with a return reason are not returned.\n- `ReturnReason` holds the most frequent reason, `NrOfReturns` the number of invoice lines with that reason (not the total of all returns of the item).\n\nThe result is sorted by item name. There is no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `MinNrOfReturns` | int | No | Threshold for the number of invoice lines with the item's most frequent return reason. Only items whose count is strictly greater than this value are returned. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may appear.\n- The count is based on invoice lines, not on quantities; a line with several returned units counts once.\n- If two reasons have the same highest count, which one is shown is not deterministic (no tie-breaker in the ordering).\n- The procedure evaluates correlated subqueries for every item in `Items`, which can be slow on large databases.\n- The header comment of the procedure (\"Checks pixi* user credentials\") does not match its actual function.\n- The code does not qualify column names; from which of the tables `invoices` or `invlines` the columns `ReturnReason` and `ItemRef` come cannot be determined from the code alone.\n\nDocumentation: https://pixi-api-docs.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": "Returns items whose most frequent return reason occurs more often than a given threshold, together with that reason and its count.\n\nAnalyses return reasons recorded on invoice lines and lists the items that are returned repeatedly for the same reason.\n\nFor every item in `Items`, the procedure looks at all invoice lines (`invlines` joined to `invoices` via `InvoiceRef = InvoiceKey`) that reference the item (`ItemRef`) and have a non-NULL `ReturnReason`. These lines are grouped by `ReturnReason`, and the reason with the highest number of lines is taken as the item's top return reason.\n\n- An item is included only if the count of its top return reason is **strictly greater** than `MinNrOfReturns`. With the default of `2`, the top reason must occur at least 3 times.\n- Items without any invoice line with a return reason are not returned.\n- `ReturnReason` holds the most frequent reason, `NrOfReturns` the number of invoice lines with that reason (not the total of all returns of the item).\n\nThe result is sorted by item name. There is no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `MinNrOfReturns` | int | No | Threshold for the number of invoice lines with the item's most frequent return reason. Only items whose count is strictly greater than this value are returned. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may appear.\n- The count is based on invoice lines, not on quantities; a line with several returned units counts once.\n- If two reasons have the same highest count, which one is shown is not deterministic (no tie-breaker in the ordering).\n- The procedure evaluates correlated subqueries for every item in `Items`, which can be slow on large databases.\n- The header comment of the procedure (\"Checks pixi* user credentials\") does not match its actual function.\n- The code does not qualify column names; from which of the tables `invoices` or `invlines` the columns `ReturnReason` and `ItemRef` come cannot be determined from the code alone.\n\nDocumentation: https://pixi-api-docs.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": "Returns the lines of a return case with item, invoice line, bin location and translated reason and quality classification.\n\nReturns all return lines (`pixi.ReturnLine`) that belong to the return case given in `ReturnId`.\n\nSteps:\n\n1. Loads the translations of code table values (`DBObjectName = 'CodeTableValue'`) for the language `LanguageId` into a temporary table.\n2. Selects every return line of the return case and joins:\n - the invoice line (`Invlines`) and its item (`items`), which provide item number, EAN, name and internal item number,\n - the return reason code (`ReasonId`) with its code and translated description,\n - the item quality classification code (`ItemQualityClassificationId`) with its code and translated description,\n - the bin item log entry (`InvBinItemLog`), which provides quantity, location, bin, best-before date and batch number.\n\nAll joins are inner joins, so a line only appears if all referenced records exist and both the reason and the classification have a translation in the requested language.\n\nNo explicit sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ReturnId` | int | Yes | ID of the return case whose lines are returned. |\n| `LanguageId` | int | No | Language ID used for the translated descriptions of the return reason and the item quality classification. |\n\n- Most tables are read with `NOLOCK`, so uncommitted data may be returned; the join to the quality classification (`CodeTableValue` as `ct2`) is read without `NOLOCK`.\n- If a reason or classification has no translation for the given `LanguageId`, the whole line is missing from the result. Use a language for which translations exist (default `1`).\n- The temporary table is dropped via `util.TempTableDrop`, whose definition is not attached.\n- If the return case does not exist or has no lines, an empty result set is returned; no error is raised.\n\nDocumentation: https://pixi-api-docs.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": "Returns the lines of a return case with item, invoice line, bin location and translated reason and quality classification.\n\nReturns all return lines (`pixi.ReturnLine`) that belong to the return case given in `ReturnId`.\n\nSteps:\n\n1. Loads the translations of code table values (`DBObjectName = 'CodeTableValue'`) for the language `LanguageId` into a temporary table.\n2. Selects every return line of the return case and joins:\n - the invoice line (`Invlines`) and its item (`items`), which provide item number, EAN, name and internal item number,\n - the return reason code (`ReasonId`) with its code and translated description,\n - the item quality classification code (`ItemQualityClassificationId`) with its code and translated description,\n - the bin item log entry (`InvBinItemLog`), which provides quantity, location, bin, best-before date and batch number.\n\nAll joins are inner joins, so a line only appears if all referenced records exist and both the reason and the classification have a translation in the requested language.\n\nNo explicit sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ReturnId` | int | Yes | ID of the return case whose lines are returned. |\n| `LanguageId` | int | No | Language ID used for the translated descriptions of the return reason and the item quality classification. |\n\n- Most tables are read with `NOLOCK`, so uncommitted data may be returned; the join to the quality classification (`CodeTableValue` as `ct2`) is read without `NOLOCK`.\n- If a reason or classification has no translation for the given `LanguageId`, the whole line is missing from the result. Use a language for which translations exist (default `1`).\n- The temporary table is dropped via `util.TempTableDrop`, whose definition is not attached.\n- If the return case does not exist or has no lines, an empty result set is returned; no error is raised.\n\nDocumentation: https://pixi-api-docs.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": "Returns a paged list of returns (Retouren) modified within a date range, optionally filtered by status and invoice number, including the related credit note.\n\nReads returns from the `pixi.Return` table and returns one row per return.\n\n**Filters**\n- `StatusId`: only returns with this status ID. `NULL` returns all statuses.\n- `InvoiceNr`: the invoice number is first resolved to its invoice key. Only returns of that invoice are listed.\n- `ChangeDateFrom` / `ChangeDateTo`: the return's `RecordModifiedOn` must lie between both values, inclusive.\n - If `ChangeDateFrom` is `NULL`, the range starts at 00:00 on the same day one month ago.\n - If `ChangeDateTo` is `NULL`, the range ends at the end of today (23:59:59.997).\n\n**Credit note**\nThe credit note referenced by the return (`CreditInvoiceId`) is joined optionally. Its number and total are returned as `CreditNumber` and `CreditedAmount`. Both are empty if the return has no credit note.\n\n**Paging and sort order**\n- All matching returns are numbered in ascending order of their `Id`.\n- Rows with a row number greater than `Offset` are returned, at most `RowCount` of them.\n- The result is sorted by `Id`.\n\n**Additional data**\nEach row also contains:\n- the status code,\n- the invoice number and customer reference of the original invoice,\n- the names of the users who created and last modified the return.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StatusId` | int | No | Status ID of the returns (`pixi.Status.Id`). `NULL` returns all statuses. |\n| `ChangeDateFrom` | datetime | No | Start of the modification date range, inclusive. If `NULL`, the range starts at 00:00 on the same day one month ago. |\n| `ChangeDateTo` | datetime | No | End of the modification date range, inclusive. If `NULL`, the range ends at the end of today. |\n| `InvoiceNr` | varchar(20) | No | Number of the original invoice. Only returns of this invoice are listed. If no invoice with this number exists, the filter is ignored. |\n| `Offset` | int | No | Number of matching returns to skip, counted in ascending `Id` order. |\n| `RowCount` | int | No | Maximum number of rows returned. |\n\n- **Unknown invoice number:** If `InvoiceNr` does not match any invoice, the invoice filter is silently ignored. The call then returns all returns that match the other filters. The same happens for an empty string that matches no invoice.\n- **Duplicate invoice numbers:** If several invoices share the same number, only one of them is used; which one is not defined.\n- **Paging gaps:** Row numbers are assigned before the status, invoice and user data are joined. These joins are inner joins. A return whose status, original invoice, creating user or modifying user cannot be found is dropped from the output. A page can therefore contain fewer than `RowCount` rows even though later pages still have data. For paging, increase `Offset` by `RowCount` each time; do not use the number of rows received.\n- **Time precision:** `RecordModifiedOn` is held as `smalldatetime` (minute precision).\n- **Dirty reads:** All tables are read with `NOLOCK`, so uncommitted data may appear.\n\nDocumentation: https://pixi-api-docs.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": "Returns a paged list of returns (Retouren) modified within a date range, optionally filtered by status and invoice number, including the related credit note.\n\nReads returns from the `pixi.Return` table and returns one row per return.\n\n**Filters**\n- `StatusId`: only returns with this status ID. `NULL` returns all statuses.\n- `InvoiceNr`: the invoice number is first resolved to its invoice key. Only returns of that invoice are listed.\n- `ChangeDateFrom` / `ChangeDateTo`: the return's `RecordModifiedOn` must lie between both values, inclusive.\n - If `ChangeDateFrom` is `NULL`, the range starts at 00:00 on the same day one month ago.\n - If `ChangeDateTo` is `NULL`, the range ends at the end of today (23:59:59.997).\n\n**Credit note**\nThe credit note referenced by the return (`CreditInvoiceId`) is joined optionally. Its number and total are returned as `CreditNumber` and `CreditedAmount`. Both are empty if the return has no credit note.\n\n**Paging and sort order**\n- All matching returns are numbered in ascending order of their `Id`.\n- Rows with a row number greater than `Offset` are returned, at most `RowCount` of them.\n- The result is sorted by `Id`.\n\n**Additional data**\nEach row also contains:\n- the status code,\n- the invoice number and customer reference of the original invoice,\n- the names of the users who created and last modified the return.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StatusId` | int | No | Status ID of the returns (`pixi.Status.Id`). `NULL` returns all statuses. |\n| `ChangeDateFrom` | datetime | No | Start of the modification date range, inclusive. If `NULL`, the range starts at 00:00 on the same day one month ago. |\n| `ChangeDateTo` | datetime | No | End of the modification date range, inclusive. If `NULL`, the range ends at the end of today. |\n| `InvoiceNr` | varchar(20) | No | Number of the original invoice. Only returns of this invoice are listed. If no invoice with this number exists, the filter is ignored. |\n| `Offset` | int | No | Number of matching returns to skip, counted in ascending `Id` order. |\n| `RowCount` | int | No | Maximum number of rows returned. |\n\n- **Unknown invoice number:** If `InvoiceNr` does not match any invoice, the invoice filter is silently ignored. The call then returns all returns that match the other filters. The same happens for an empty string that matches no invoice.\n- **Duplicate invoice numbers:** If several invoices share the same number, only one of them is used; which one is not defined.\n- **Paging gaps:** Row numbers are assigned before the status, invoice and user data are joined. These joins are inner joins. A return whose status, original invoice, creating user or modifying user cannot be found is dropped from the output. A page can therefore contain fewer than `RowCount` rows even though later pages still have data. For paging, increase `Offset` by `RowCount` each time; do not use the number of rows received.\n- **Time precision:** `RecordModifiedOn` is held as `smalldatetime` (minute precision).\n- **Dirty reads:** All tables are read with `NOLOCK`, so uncommitted data may appear.\n\nDocumentation: https://pixi-api-docs.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": "Returns the list of standard return reasons in German or English, combined from the standard reasons table, a setting and the return reason code table.\n\nBuilds one list of return reasons from three sources and returns it as a single result set.\n\n**Language selection.** `LanguageID` = `1` selects German; any other value, including `NULL`, selects English. Internally the procedure switches to Pixi's table convention, where `1` = English and `2` = German, and uses that value to filter the tables.\n\n**Sources**\n1. `RET_STANDARD_REASONS` rows of the selected language. They return `RET_REASON_ID` and `REASON_TEXT`. `RET_REASON_CODE` and `LANGUAGEID` are `NULL`.\n2. The setting `CSD_ReturnWizardReasons_Deutsch` (German) or `CSD_ReturnWizardReasons_English` (other languages). Its value is a semicolon-separated list. Each entry becomes one row with trimmed text (max. 100 characters) and `RET_REASON_ID` = `NULL`. This part is combined with source 1 using `UNION`, so identical rows from sources 1 and 2 appear only once.\n3. Entries of `pixi.CodeTableValue` with `CodeTableTypeId` = `2` (return reasons), joined to their `Translation` entry (`DBObjectName` = `CodeTableValue`) in the selected language. These rows return the code table ID, the translated text and the `Code`. `LANGUAGEID` is converted back to the caller's convention (`1` = German). These rows are appended with `UNION ALL`, so duplicates are not removed here.\n\n**Filter.** With `OnlyReturnReasonsFromPixiWeb` = `1`, only rows with a `RET_REASON_ID` are returned. This removes the setting-based reasons from source 2.\n\n**Sort order.** Rows are sorted by `RET_REASON_CODE`. Rows without a code (`NULL`) come first, and their order among each other is not defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LanguageID` | int | No | Language of the reason texts: `1` = German, any other value = English. |\n| `OnlyReturnReasonsFromPixiWeb` | bit | No | If `1`, only reasons with an ID are returned, i.e. those from `RET_STANDARD_REASONS` and the code table. The setting-based reasons are excluded. |\n\n- The language convention of the parameter (`1` = German) is the reverse of the convention used in the tables (`1` = English, `2` = German). Only the `LANGUAGEID` column of code table rows is reported in the caller's convention; all other rows return `NULL`.\n- If the setting does not exist or is empty, source 2 returns no rows.\n- A trailing or doubled semicolon in the setting value produces rows with an empty `REASON_TEXT`.\n- Characters such as `&` or `<` in the setting value can make the conversion of the list to XML fail, and the call then returns an SQL error.\n- `Settings`, `RET_STANDARD_REASONS` and `CodeTableValue` are read with `NOLOCK`; `Translation` is read without a locking hint.\n- The setting name is matched with `LIKE`, where `_` is a single-character wildcard. In practice the match is exact.\n- Read-only; only a temporary table is used.\n\nDocumentation: https://pixi-api-docs.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": "Returns the list of standard return reasons in German or English, combined from the standard reasons table, a setting and the return reason code table.\n\nBuilds one list of return reasons from three sources and returns it as a single result set.\n\n**Language selection.** `LanguageID` = `1` selects German; any other value, including `NULL`, selects English. Internally the procedure switches to Pixi's table convention, where `1` = English and `2` = German, and uses that value to filter the tables.\n\n**Sources**\n1. `RET_STANDARD_REASONS` rows of the selected language. They return `RET_REASON_ID` and `REASON_TEXT`. `RET_REASON_CODE` and `LANGUAGEID` are `NULL`.\n2. The setting `CSD_ReturnWizardReasons_Deutsch` (German) or `CSD_ReturnWizardReasons_English` (other languages). Its value is a semicolon-separated list. Each entry becomes one row with trimmed text (max. 100 characters) and `RET_REASON_ID` = `NULL`. This part is combined with source 1 using `UNION`, so identical rows from sources 1 and 2 appear only once.\n3. Entries of `pixi.CodeTableValue` with `CodeTableTypeId` = `2` (return reasons), joined to their `Translation` entry (`DBObjectName` = `CodeTableValue`) in the selected language. These rows return the code table ID, the translated text and the `Code`. `LANGUAGEID` is converted back to the caller's convention (`1` = German). These rows are appended with `UNION ALL`, so duplicates are not removed here.\n\n**Filter.** With `OnlyReturnReasonsFromPixiWeb` = `1`, only rows with a `RET_REASON_ID` are returned. This removes the setting-based reasons from source 2.\n\n**Sort order.** Rows are sorted by `RET_REASON_CODE`. Rows without a code (`NULL`) come first, and their order among each other is not defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LanguageID` | int | No | Language of the reason texts: `1` = German, any other value = English. |\n| `OnlyReturnReasonsFromPixiWeb` | bit | No | If `1`, only reasons with an ID are returned, i.e. those from `RET_STANDARD_REASONS` and the code table. The setting-based reasons are excluded. |\n\n- The language convention of the parameter (`1` = German) is the reverse of the convention used in the tables (`1` = English, `2` = German). Only the `LANGUAGEID` column of code table rows is reported in the caller's convention; all other rows return `NULL`.\n- If the setting does not exist or is empty, source 2 returns no rows.\n- A trailing or doubled semicolon in the setting value produces rows with an empty `REASON_TEXT`.\n- Characters such as `&` or `<` in the setting value can make the conversion of the list to XML fail, and the call then returns an SQL error.\n- `Settings`, `RET_STANDARD_REASONS` and `CodeTableValue` are read with `NOLOCK`; `Translation` is read without a locking hint.\n- The setting name is matched with `LIKE`, where `_` is a single-character wildcard. In practice the match is exact.\n- Read-only; only a temporary table is used.\n\nDocumentation: https://pixi-api-docs.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": "Returns return lines (Retourenpositionen) in pages ordered by Id, optionally filtered by creation and/or modification date.\n\nReads rows from the table `ReturnLine` (return lines) and returns them sorted by `Id` ascending. The call is designed for keyset paging and delta synchronisation.\n\n**Paging**\n- `Id` is an *exclusive* lower bound: only lines with `Id > @Id` are returned. If `Id` is omitted or NULL, it is treated as `0`, so reading starts at the first line.\n- At most `RowCount` rows are returned (default `1000`; NULL is also treated as `1000`).\n- To read the next page, pass the highest `Id` of the previous page as `Id`.\n\n**Date filters** (only one group is applied, checked in this order):\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: if at least one is set, a line matches if its creation **or** modification date is `>=` the from value and its creation **or** modification date is `<` the to value.\n2. Otherwise `CreateDateFrom` / `CreateDateTo`: filters on `RecordCreatedOn` (from inclusive, to exclusive).\n3. Otherwise `UpdateDateFrom` / `UpdateDateTo`: filters on `RecordModifiedOn` (from inclusive, to exclusive).\n4. If no date parameter is set, all lines with `Id > @Id` are returned (limited by `RowCount`).\n\nEach bound of a group can be omitted to get an open-ended range. Parameters of lower-priority groups are ignored when a higher-priority group is used.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Id` | int | No | Exclusive lower bound for the return line Id (keyset paging). Only lines with a greater Id are returned. NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Returns lines created on or after this date (inclusive). Used only if no CreateAndUpdateDate parameter is set. |\n| `CreateDateTo` | datetime | No | Returns lines created before this date (exclusive). Used only if no CreateAndUpdateDate parameter is set. |\n| `UpdateDateFrom` | datetime | No | Returns lines modified on or after this date (inclusive). Used only if no CreateAndUpdateDate or CreateDate parameter is set. |\n| `UpdateDateTo` | datetime | No | Returns lines modified before this date (exclusive). Used only if no CreateAndUpdateDate or CreateDate parameter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Returns lines whose creation or modification date is on or after this date. Takes precedence over all other date parameters. |\n| `CreateAndUpdateDateTo` | datetime | No | Returns lines whose creation or modification date is before this date (exclusive). Takes precedence over all other date parameters. |\n| `RowCount` | int | No | Maximum number of rows returned per call (page size). NULL is treated as 1000. |\n\n- The table is read with `NOLOCK`; uncommitted or inconsistent data may be returned.\n- `Id` cannot be used to fetch a single line: the code contains a branch for `Id = @Id`, but it is unreachable because `Id` is always set (NULL becomes `0`) and `RowCount` is never NULL. Passing an `Id` always returns lines with a **greater** `Id`.\n- The combined filter (`CreateAndUpdateDate…`) checks both bounds with separate OR conditions. With both bounds set, a line created before the range and modified after the range can still match (e.g. created before `To` and modified after `From`).\n- A negative `RowCount` causes a SQL error from `TOP`; `0` returns an empty result.\n- Column data types are not visible in the code (table definition not attached).\n\nDocumentation: https://pixi-api-docs.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": "Returns return lines (Retourenpositionen) in pages ordered by Id, optionally filtered by creation and/or modification date.\n\nReads rows from the table `ReturnLine` (return lines) and returns them sorted by `Id` ascending. The call is designed for keyset paging and delta synchronisation.\n\n**Paging**\n- `Id` is an *exclusive* lower bound: only lines with `Id > @Id` are returned. If `Id` is omitted or NULL, it is treated as `0`, so reading starts at the first line.\n- At most `RowCount` rows are returned (default `1000`; NULL is also treated as `1000`).\n- To read the next page, pass the highest `Id` of the previous page as `Id`.\n\n**Date filters** (only one group is applied, checked in this order):\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: if at least one is set, a line matches if its creation **or** modification date is `>=` the from value and its creation **or** modification date is `<` the to value.\n2. Otherwise `CreateDateFrom` / `CreateDateTo`: filters on `RecordCreatedOn` (from inclusive, to exclusive).\n3. Otherwise `UpdateDateFrom` / `UpdateDateTo`: filters on `RecordModifiedOn` (from inclusive, to exclusive).\n4. If no date parameter is set, all lines with `Id > @Id` are returned (limited by `RowCount`).\n\nEach bound of a group can be omitted to get an open-ended range. Parameters of lower-priority groups are ignored when a higher-priority group is used.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Id` | int | No | Exclusive lower bound for the return line Id (keyset paging). Only lines with a greater Id are returned. NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Returns lines created on or after this date (inclusive). Used only if no CreateAndUpdateDate parameter is set. |\n| `CreateDateTo` | datetime | No | Returns lines created before this date (exclusive). Used only if no CreateAndUpdateDate parameter is set. |\n| `UpdateDateFrom` | datetime | No | Returns lines modified on or after this date (inclusive). Used only if no CreateAndUpdateDate or CreateDate parameter is set. |\n| `UpdateDateTo` | datetime | No | Returns lines modified before this date (exclusive). Used only if no CreateAndUpdateDate or CreateDate parameter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Returns lines whose creation or modification date is on or after this date. Takes precedence over all other date parameters. |\n| `CreateAndUpdateDateTo` | datetime | No | Returns lines whose creation or modification date is before this date (exclusive). Takes precedence over all other date parameters. |\n| `RowCount` | int | No | Maximum number of rows returned per call (page size). NULL is treated as 1000. |\n\n- The table is read with `NOLOCK`; uncommitted or inconsistent data may be returned.\n- `Id` cannot be used to fetch a single line: the code contains a branch for `Id = @Id`, but it is unreachable because `Id` is always set (NULL becomes `0`) and `RowCount` is never NULL. Passing an `Id` always returns lines with a **greater** `Id`.\n- The combined filter (`CreateAndUpdateDate…`) checks both bounds with separate OR conditions. With both bounds set, a line created before the range and modified after the range can still match (e.g. created before `To` and modified after `From`).\n- A negative `RowCount` causes a SQL error from `TOP`; `0` returns an empty result.\n- Column data types are not visible in the code (table definition not attached).\n\nDocumentation: https://pixi-api-docs.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": "Sets the return cost of a received return case, stored as net for B2B and gross for B2C, after checking it against the refundable amount.\n\nUpdates the return cost of one return case in `pixi.Return`.\n\nSteps:\n\n1. `UserName` is trimmed. An empty value becomes `API`.\n2. Both `ReturnId` and `ReturnCost` must be provided.\n3. The return case must exist.\n4. The return case must be in status `StatusId = 2` (Received).\n5. `ReturnCost` must not be negative. A value of `0` is accepted.\n6. The upper limit is computed from the return case and its invoice (`Invoices.InvoiceKey = Return.InvoiceId`). It is the returned items amount plus the shipping cost refund minus the voucher amount:\n - for `B2B` orders: `TotalToRefundNet + ShippingCostRefundNet - VoucherAmountNet`\n - for `B2C` orders: `TotalToRefundGross + ShippingCostRefundGross - VoucherAmountGross`\n \n If `ReturnCost` is above this limit, an error row is returned.\n7. The cost is written to the return case:\n - `B2C`: the value goes to `ReturnCostGross`.\n - any other order type: the value goes to `ReturnCostNet`.\n \n `RecordModifiedByUserId` and `RecordModifiedOn` are set as well.\n\nThe user ID is resolved from `UserName`. If that user does not exist, the user `pixiAdministration` is used.\n\nThe call returns exactly one row with `Status` and `Message`, both on success and on error.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ReturnId` | int | No | ID of the return case (`pixi.Return.id`). Effectively required. |\n| `ReturnCost` | money | No | Return cost to store. It is stored as net for B2B and as gross for B2C. It must not be negative or exceed the refundable amount. Effectively required. |\n| `UserName` | varchar(50) | No | Name of the user recorded as modifier. An empty value becomes `API`. An unknown user falls back to `pixiAdministration`. |\n\n- Validation reads use `NOLOCK`; the update uses `ROWLOCK`. No explicit transaction is used.\n- Pitfall: the limit check is skipped in three cases:\n - no matching invoice is found in `Invoices`, so the order type stays `NULL`;\n - the order type is neither `B2B` nor `B2C`;\n - one of the amount columns is `NULL`.\n \n In the first two cases the value is written to `ReturnCostNet` without any limit check.\n- The error text 'must be greater than 0' is misleading: only negative values are rejected, so `0` is accepted.\n- On error the procedure also returns the return code 1. The status row is the relevant signal for SOAP clients.\n\nDocumentation: https://pixi-api-docs.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": "Sets the return cost of a received return case, stored as net for B2B and gross for B2C, after checking it against the refundable amount.\n\nUpdates the return cost of one return case in `pixi.Return`.\n\nSteps:\n\n1. `UserName` is trimmed. An empty value becomes `API`.\n2. Both `ReturnId` and `ReturnCost` must be provided.\n3. The return case must exist.\n4. The return case must be in status `StatusId = 2` (Received).\n5. `ReturnCost` must not be negative. A value of `0` is accepted.\n6. The upper limit is computed from the return case and its invoice (`Invoices.InvoiceKey = Return.InvoiceId`). It is the returned items amount plus the shipping cost refund minus the voucher amount:\n - for `B2B` orders: `TotalToRefundNet + ShippingCostRefundNet - VoucherAmountNet`\n - for `B2C` orders: `TotalToRefundGross + ShippingCostRefundGross - VoucherAmountGross`\n \n If `ReturnCost` is above this limit, an error row is returned.\n7. The cost is written to the return case:\n - `B2C`: the value goes to `ReturnCostGross`.\n - any other order type: the value goes to `ReturnCostNet`.\n \n `RecordModifiedByUserId` and `RecordModifiedOn` are set as well.\n\nThe user ID is resolved from `UserName`. If that user does not exist, the user `pixiAdministration` is used.\n\nThe call returns exactly one row with `Status` and `Message`, both on success and on error.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ReturnId` | int | No | ID of the return case (`pixi.Return.id`). Effectively required. |\n| `ReturnCost` | money | No | Return cost to store. It is stored as net for B2B and as gross for B2C. It must not be negative or exceed the refundable amount. Effectively required. |\n| `UserName` | varchar(50) | No | Name of the user recorded as modifier. An empty value becomes `API`. An unknown user falls back to `pixiAdministration`. |\n\n- Validation reads use `NOLOCK`; the update uses `ROWLOCK`. No explicit transaction is used.\n- Pitfall: the limit check is skipped in three cases:\n - no matching invoice is found in `Invoices`, so the order type stays `NULL`;\n - the order type is neither `B2B` nor `B2C`;\n - one of the amount columns is `NULL`.\n \n In the first two cases the value is written to `ReturnCostNet` without any limit check.\n- The error text 'must be greater than 0' is misleading: only negative values are rejected, so `0` is accepted.\n- On error the procedure also returns the return code 1. The status row is the relevant signal for SOAP clients.\n\nDocumentation: https://pixi-api-docs.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": "Checks whether a pick list number exists and has not expired, and returns its box range, 1SS flag, scan state and number of open orders.\n\nValidates a pick list (`PLHeader`) by its key `PickListNr`. The call delegates all work to the internal procedure `Pixi_CheckPickListNr` and always returns exactly one row.\n\nSteps:\n\n1. **Scan state:** It checks whether at least one item of the pick list (`PLitem`) refers to an order line with status `EIN`. If so, `PicklistNotScannedYet` is `0`. If there is no such line, it is `1`.\n2. **Number of orders:** It counts the distinct order numbers of the pick list whose order lines are not expired (`Expired = 0`). Orders that already have a box in `boxes` with `WaitForSend = 'N'` are left out.\n3. **Validity:** A pick list is valid if a `PLHeader` row with `PLHkey = PickListNr` exists and its `PLHexpiryDate` is later than the current server time.\n - **Invalid or expired pick list:** the row contains `ReturnValue = 0` and all other columns are `0`.\n - **Valid pick list:** the row contains `ReturnValue = 1`, the box range `PLHfromBox`/`PLHtoBox`, the `1SS` flag (`NULL` becomes `0`), and the values from steps 1 and 2.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PickListNr` | int | Yes | Key of the pick list (`PLHeader.PLHkey`) to check. |\n\n- All reads use `NOLOCK`. Values may reflect uncommitted changes made at the same time.\n- In the invalid branch the box columns are named `PLHFromBox`/`PLHToBox`. In the valid branch they are named `PLHfromBox`/`PLHtoBox`. XML element names are case-sensitive, so clients should read them case-insensitively.\n- The column name `1SS` starts with a digit. In the SOAP/DataSet XML it is typically encoded as `_x0031_SS`.\n- A non-existing pick list cannot be told apart from an expired one; both return `ReturnValue = 0`.\n- Expiry is compared with the database server time (`GETDATE()`).\n\nDocumentation: https://pixi-api-docs.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": "Checks whether a pick list number exists and has not expired, and returns its box range, 1SS flag, scan state and number of open orders.\n\nValidates a pick list (`PLHeader`) by its key `PickListNr`. The call delegates all work to the internal procedure `Pixi_CheckPickListNr` and always returns exactly one row.\n\nSteps:\n\n1. **Scan state:** It checks whether at least one item of the pick list (`PLitem`) refers to an order line with status `EIN`. If so, `PicklistNotScannedYet` is `0`. If there is no such line, it is `1`.\n2. **Number of orders:** It counts the distinct order numbers of the pick list whose order lines are not expired (`Expired = 0`). Orders that already have a box in `boxes` with `WaitForSend = 'N'` are left out.\n3. **Validity:** A pick list is valid if a `PLHeader` row with `PLHkey = PickListNr` exists and its `PLHexpiryDate` is later than the current server time.\n - **Invalid or expired pick list:** the row contains `ReturnValue = 0` and all other columns are `0`.\n - **Valid pick list:** the row contains `ReturnValue = 1`, the box range `PLHfromBox`/`PLHtoBox`, the `1SS` flag (`NULL` becomes `0`), and the values from steps 1 and 2.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PickListNr` | int | Yes | Key of the pick list (`PLHeader.PLHkey`) to check. |\n\n- All reads use `NOLOCK`. Values may reflect uncommitted changes made at the same time.\n- In the invalid branch the box columns are named `PLHFromBox`/`PLHToBox`. In the valid branch they are named `PLHfromBox`/`PLHtoBox`. XML element names are case-sensitive, so clients should read them case-insensitively.\n- The column name `1SS` starts with a digit. In the SOAP/DataSet XML it is typically encoded as `_x0031_SS`.\n- A non-existing pick list cannot be told apart from an expired one; both return `ReturnValue = 0`.\n- Expiry is compared with the database server time (`GETDATE()`).\n\nDocumentation: https://pixi-api-docs.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": "Creates a package (pixi.InvoicePackage) for an invoice, optionally with package lines, tracking IDs and label URLs, and returns the new PackageId.\n\nCreates a new shipping package for an existing invoice and optionally assigns invoice lines with quantities to it.\n\nSteps:\n1. Checks the setting `Premium_API`. If it is not enabled, an error row is returned.\n2. Empty strings in the text parameters are treated as `NULL`; `ShipVendorCode` is trimmed.\n3. The invoice is identified by `InvoiceNr` and/or `InvoiceKey`. At least one is required. If both are given, they must point to the same invoice.\n4. The shipping vendor is resolved from `ShipVendorCode` via `ShipVendor.ShipVendorCode`. If no code is given, the invoice's own `ShipVendor` is used. An explicitly given code that does not exist is rejected; if the fallback does not resolve, `ShipVendorId` simply stays `NULL`.\n5. If `Lines` is given, it is parsed as XML (`/Lines/Line` with `InvlineId` and `Quantity`). Each line is validated:\n - `InvlineId` and `Quantity` must be integers,\n - no duplicate `InvlineId`,\n - every line must belong to the invoice (`Invlines.InvoiceRef`),\n - `Quantity` must be greater than 0,\n - `Quantity` plus the quantity already allocated to other packages (`pixi.InvoicePackageLines`) must not exceed `Invlines.ItemQty`.\n6. In a transaction the package is inserted into `pixi.InvoicePackage` (with `TimesLabelPrinted` = 0, audit columns from the user `CreateEmp`), the lines are inserted into `pixi.InvoicePackageLines`, and `Invoices.Packages` is incremented by 1.\n7. If `TrackingID` or `ReturnTrackingId` is given, `pixiUpdateInvoicePackageTrackingIds` is executed for the new package to sync the tracking IDs to the invoice (`ShipmentTrackingID`, `retTrackID`, `retTrackIDhist`), controlled by `Overwrite` and `ResetClientNotifiedFlag`.\n8. MQ events are published: `PackageLabelSaved` (only if a label URL was given) and `InvoiceChanged` with parameter `CreatePackage`.\n\nThe call always returns exactly one row with `Status`, `Message` and `PackageId`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | No | Invoice number. Either this or `InvoiceKey` is required; if both are given they must match. |\n| `InvoiceKey` | int | No | Internal key of the invoice (`Invoices.InvoiceKey`). Either this or `InvoiceNr` is required. |\n| `TrackingID` | varchar(512) | No | Shipment tracking ID of the package. If set, it is also synced to the invoice's `ShipmentTrackingID`. |\n| `ReturnTrackingId` | varchar(512) | No | Return tracking ID of the package. If set, it is synced to `retTrackID` and `retTrackIDhist` of the invoice. |\n| `ShippingLabelUrl` | varchar(8000) | No | URL of the shipping label. If set, the MQ event `PackageLabelSaved` is published. |\n| `ReturnLabelUrl` | varchar(8000) | No | URL of the return label. If set, the MQ event `PackageLabelSaved` is published. |\n| `ExternalShipmentId` | varchar(512) | No | Shipment ID in an external shipping system; stored as is. |\n| `GrossWeight` | decimal(9, 3) | No | Gross weight of the package; stored as is. |\n| `ShipVendorCode` | varchar(3) | No | Code of the shipping vendor (`ShipVendor.ShipVendorCode`). If omitted, the invoice's shipping vendor is used. An unknown code causes an error. |\n| `PackageDimensionId` | int | No | ID of a package dimension; stored without validation. |\n| `Lines` | varchar(max) | No | Optional XML with the invoice lines and quantities contained in the package. Each `Line` needs an integer `InvlineId` (`Invlines.InvLineKey` of this invoice) and a positive integer `Quantity`. |\n| `ResetClientNotifiedFlag` | bit | No | Passed to the tracking sync; only effective if a tracking ID is given. |\n| `Overwrite` | bit | No | Passed to the tracking sync; controls how `TrackingID` is written to the invoice's `ShipmentTrackingID`. |\n| `CreateEmp` | varchar(50) | No | User name for the audit columns; resolved in `UCS_USERS`, unknown names fall back to `pixiAdministration`. |\n\n- Requires the setting `Premium_API` = 1.\n- Validation reads use `NOLOCK`. Two concurrent calls for the same invoice lines can therefore both pass the quantity check and over-allocate a line.\n- The procedure starts its own transaction, or sets a savepoint if the caller already has an open transaction. The success row is selected before the commit.\n- Unexpected SQL errors are caught, the transaction (or savepoint) is rolled back, the error is logged via `log.InsertError` and returned as an `ERROR` row with the SQL error text.\n- The result of `pixiUpdateInvoicePackageTrackingIds` is captured internally and **not checked**. If that procedure reports a problem (e.g. status `411` because the combined tracking string on the invoice would exceed 512 characters), the package is still created and `SUCCESS` is returned, but the invoice tracking fields may not be updated.\n- A code comment says the tracking sync runs after the commit; in fact it runs inside the same transaction.\n- If a tracking ID contains several values separated by `;`, the package itself ends up with only the last value (set by the tracking sync), while the invoice receives the full value.\n- `ResetClientNotifiedFlag` = 1 only has an effect together with a tracking ID: it sets `ClientNotified` = `N` in `OrderHistory` for the latest `AUS` status of the order lines on the invoice, so the shipment is exported again.\n- `CreateEmp` is resolved in `UCS_USERS`; unknown names fall back to the user `pixiAdministration`.\n- `PackageDimensionId`, `GrossWeight` and `ExternalShipmentId` are stored without validation.\n- MQ events are only sent if `pixiMQ_Enabled` is active and the events are configured in `EventConfiguration`; failures there do not change the result.\n\nDocumentation: https://pixi-api-docs.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": "Creates a package (pixi.InvoicePackage) for an invoice, optionally with package lines, tracking IDs and label URLs, and returns the new PackageId.\n\nCreates a new shipping package for an existing invoice and optionally assigns invoice lines with quantities to it.\n\nSteps:\n1. Checks the setting `Premium_API`. If it is not enabled, an error row is returned.\n2. Empty strings in the text parameters are treated as `NULL`; `ShipVendorCode` is trimmed.\n3. The invoice is identified by `InvoiceNr` and/or `InvoiceKey`. At least one is required. If both are given, they must point to the same invoice.\n4. The shipping vendor is resolved from `ShipVendorCode` via `ShipVendor.ShipVendorCode`. If no code is given, the invoice's own `ShipVendor` is used. An explicitly given code that does not exist is rejected; if the fallback does not resolve, `ShipVendorId` simply stays `NULL`.\n5. If `Lines` is given, it is parsed as XML (`/Lines/Line` with `InvlineId` and `Quantity`). Each line is validated:\n - `InvlineId` and `Quantity` must be integers,\n - no duplicate `InvlineId`,\n - every line must belong to the invoice (`Invlines.InvoiceRef`),\n - `Quantity` must be greater than 0,\n - `Quantity` plus the quantity already allocated to other packages (`pixi.InvoicePackageLines`) must not exceed `Invlines.ItemQty`.\n6. In a transaction the package is inserted into `pixi.InvoicePackage` (with `TimesLabelPrinted` = 0, audit columns from the user `CreateEmp`), the lines are inserted into `pixi.InvoicePackageLines`, and `Invoices.Packages` is incremented by 1.\n7. If `TrackingID` or `ReturnTrackingId` is given, `pixiUpdateInvoicePackageTrackingIds` is executed for the new package to sync the tracking IDs to the invoice (`ShipmentTrackingID`, `retTrackID`, `retTrackIDhist`), controlled by `Overwrite` and `ResetClientNotifiedFlag`.\n8. MQ events are published: `PackageLabelSaved` (only if a label URL was given) and `InvoiceChanged` with parameter `CreatePackage`.\n\nThe call always returns exactly one row with `Status`, `Message` and `PackageId`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | No | Invoice number. Either this or `InvoiceKey` is required; if both are given they must match. |\n| `InvoiceKey` | int | No | Internal key of the invoice (`Invoices.InvoiceKey`). Either this or `InvoiceNr` is required. |\n| `TrackingID` | varchar(512) | No | Shipment tracking ID of the package. If set, it is also synced to the invoice's `ShipmentTrackingID`. |\n| `ReturnTrackingId` | varchar(512) | No | Return tracking ID of the package. If set, it is synced to `retTrackID` and `retTrackIDhist` of the invoice. |\n| `ShippingLabelUrl` | varchar(8000) | No | URL of the shipping label. If set, the MQ event `PackageLabelSaved` is published. |\n| `ReturnLabelUrl` | varchar(8000) | No | URL of the return label. If set, the MQ event `PackageLabelSaved` is published. |\n| `ExternalShipmentId` | varchar(512) | No | Shipment ID in an external shipping system; stored as is. |\n| `GrossWeight` | decimal(9, 3) | No | Gross weight of the package; stored as is. |\n| `ShipVendorCode` | varchar(3) | No | Code of the shipping vendor (`ShipVendor.ShipVendorCode`). If omitted, the invoice's shipping vendor is used. An unknown code causes an error. |\n| `PackageDimensionId` | int | No | ID of a package dimension; stored without validation. |\n| `Lines` | varchar(max) | No | Optional XML with the invoice lines and quantities contained in the package. Each `Line` needs an integer `InvlineId` (`Invlines.InvLineKey` of this invoice) and a positive integer `Quantity`. |\n| `ResetClientNotifiedFlag` | bit | No | Passed to the tracking sync; only effective if a tracking ID is given. |\n| `Overwrite` | bit | No | Passed to the tracking sync; controls how `TrackingID` is written to the invoice's `ShipmentTrackingID`. |\n| `CreateEmp` | varchar(50) | No | User name for the audit columns; resolved in `UCS_USERS`, unknown names fall back to `pixiAdministration`. |\n\n- Requires the setting `Premium_API` = 1.\n- Validation reads use `NOLOCK`. Two concurrent calls for the same invoice lines can therefore both pass the quantity check and over-allocate a line.\n- The procedure starts its own transaction, or sets a savepoint if the caller already has an open transaction. The success row is selected before the commit.\n- Unexpected SQL errors are caught, the transaction (or savepoint) is rolled back, the error is logged via `log.InsertError` and returned as an `ERROR` row with the SQL error text.\n- The result of `pixiUpdateInvoicePackageTrackingIds` is captured internally and **not checked**. If that procedure reports a problem (e.g. status `411` because the combined tracking string on the invoice would exceed 512 characters), the package is still created and `SUCCESS` is returned, but the invoice tracking fields may not be updated.\n- A code comment says the tracking sync runs after the commit; in fact it runs inside the same transaction.\n- If a tracking ID contains several values separated by `;`, the package itself ends up with only the last value (set by the tracking sync), while the invoice receives the full value.\n- `ResetClientNotifiedFlag` = 1 only has an effect together with a tracking ID: it sets `ClientNotified` = `N` in `OrderHistory` for the latest `AUS` status of the order lines on the invoice, so the shipment is exported again.\n- `CreateEmp` is resolved in `UCS_USERS`; unknown names fall back to the user `pixiAdministration`.\n- `PackageDimensionId`, `GrossWeight` and `ExternalShipmentId` are stored without validation.\n- MQ events are only sent if `pixiMQ_Enabled` is active and the events are configured in `EventConfiguration`; failures there do not change the result.\n\nDocumentation: https://pixi-api-docs.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": "Creates a picklist from a picklist profile, either directly or by adding the creation job to the execution queue.\n\nStarts picklist creation using the settings of a stored picklist profile. Some profile values can be overridden by parameters.\n\n1. **Premium API check.** The setting `Premium_API` must be enabled. Otherwise an `ERROR` row is returned.\n2. **Profile.** If `ProfileId` is given (0 counts as not given), it must exist in `PL_Profile`. If it is not given, the most recently updated default profile (`PLP_Default = 1`) that is not a 1SS profile (`PLP_1SS = 0`) is used.\n3. **Location.** An empty `LocationId` becomes `001`.\n4. **Order restriction (optional).**\n - Only `OrderNr`: the order must exist in `OrderHeader`.\n - Only `OrderNrExternal`: an order with this external number must exist.\n - Both: an order matching both values must exist. Afterwards only `OrderNr` is used and `OrderNrExternal` is cleared.\n - `OrderNr = 0` and an empty `OrderNrExternal` count as not given.\n5. **Bin range (optional).** `BinFrom` and `BinTo` must be bin names (`InvBin.BinName`) in the chosen location. Their `BinSortNum` replaces the bin sort range of the profile.\n6. **User and comment.** `UserName` is trimmed; if it is empty it becomes `API`. `Comment` is trimmed and stored as the picklist comment.\n7. **Profile parameters.** All parameters of the profile are loaded. Location, profile ID, order restriction, bin range, user name and comment are then overwritten with the values from steps 2–6.\n8. **Exclusive lock.** The call requests the application lock `ExclusivePickListCreation` without waiting. If another session holds the lock, an `ERROR` row is returned.\n9. **Execution.** An execution number is built from the current time in the format `yyMMddHHmmss`.\n - `ExecuteAsynchronous = 1` (default): an `EXEC dbo.Pixi_CreatePickList …` statement containing all parameters is written to `ExecQueries`. An `INFO` row is returned.\n - `ExecuteAsynchronous = 0`: `Pixi_CreatePickList` runs immediately. It reads its parameters from the temporary parameter table.\n\nThe lock is released afterwards.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ProfileId` | smallint | No | Key of the picklist profile (`PL_Profile.PLP_Key`). NULL or 0 uses the most recently updated default profile that is not a 1SS profile. |\n| `LocationId` | varchar(3) | No | Location for the picklist. NULL or empty becomes `001`. |\n| `OrderNr` | int | No | Restricts the picklist to this order number. NULL or 0 means no restriction. The order must exist. |\n| `BinFrom` | varchar(50) | No | Name of the first bin of the range in the chosen location. Its `BinSortNum` replaces the lower bin sort limit of the profile. |\n| `BinTo` | varchar(50) | No | Name of the last bin of the range in the chosen location. Its `BinSortNum` replaces the upper bin sort limit of the profile. |\n| `UserName` | varchar(50) | No | User recorded for the picklist creation. NULL or empty becomes `API`. |\n| `Comment` | varchar(8000) | No | Picklist comment (trimmed). Always replaces the profile comment, even when it is empty. |\n| `ExecuteAsynchronous` | bit | No | Controls whether the picklist is created immediately or queued. |\n| `OrderNrExternal` | varchar(50) | No | Restricts the picklist to the order with this external order number. Empty means no restriction. If `OrderNr` is also given, both must match the same order, and then only `OrderNr` is used. |\n\n**Synchronous mode (`ExecuteAsynchronous = 0`)**\n- No `INFO` row is returned.\n- The caller receives whatever `Pixi_CreatePickList` returns. That procedure is not attached, so its result sets and further side effects are not documented here.\n- The lock is session-scoped. If `Pixi_CreatePickList` fails with an error, the release may be skipped. The lock then stays held until the database session ends.\n\n**Asynchronous mode (default)**\n- The lock is held only while the queue entry is written. It does not prevent several queued creations from running at the same time.\n- The queued statement is built as a text string. Quotes in values such as `Comment` or `UserName` are not escaped, so an apostrophe can make the queued statement invalid.\n- The queued statement does not pass the profile values `OlderThanHour`, `OlderThanMinute`, `NewerThanHour`, `NewerThanMinute` and `DisablePicklistSplitOnBatchManagement`.\n\n**Pitfalls**\n- The location check never fails. If `LocationId` does not exist, the given value is kept and the location error message is never returned.\n- `Comment` always overwrites the profile comment. Omitting it clears the comment from the profile.\n- An empty string for `BinFrom` or `BinTo` is not treated as missing. It is looked up as a bin name and leads to an error.\n- The profile ID error message says \"could be found\", but it means that the profile was **not** found.\n\n**Other**\n- All lookups use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Creates a picklist from a picklist profile, either directly or by adding the creation job to the execution queue.\n\nStarts picklist creation using the settings of a stored picklist profile. Some profile values can be overridden by parameters.\n\n1. **Premium API check.** The setting `Premium_API` must be enabled. Otherwise an `ERROR` row is returned.\n2. **Profile.** If `ProfileId` is given (0 counts as not given), it must exist in `PL_Profile`. If it is not given, the most recently updated default profile (`PLP_Default = 1`) that is not a 1SS profile (`PLP_1SS = 0`) is used.\n3. **Location.** An empty `LocationId` becomes `001`.\n4. **Order restriction (optional).**\n - Only `OrderNr`: the order must exist in `OrderHeader`.\n - Only `OrderNrExternal`: an order with this external number must exist.\n - Both: an order matching both values must exist. Afterwards only `OrderNr` is used and `OrderNrExternal` is cleared.\n - `OrderNr = 0` and an empty `OrderNrExternal` count as not given.\n5. **Bin range (optional).** `BinFrom` and `BinTo` must be bin names (`InvBin.BinName`) in the chosen location. Their `BinSortNum` replaces the bin sort range of the profile.\n6. **User and comment.** `UserName` is trimmed; if it is empty it becomes `API`. `Comment` is trimmed and stored as the picklist comment.\n7. **Profile parameters.** All parameters of the profile are loaded. Location, profile ID, order restriction, bin range, user name and comment are then overwritten with the values from steps 2–6.\n8. **Exclusive lock.** The call requests the application lock `ExclusivePickListCreation` without waiting. If another session holds the lock, an `ERROR` row is returned.\n9. **Execution.** An execution number is built from the current time in the format `yyMMddHHmmss`.\n - `ExecuteAsynchronous = 1` (default): an `EXEC dbo.Pixi_CreatePickList …` statement containing all parameters is written to `ExecQueries`. An `INFO` row is returned.\n - `ExecuteAsynchronous = 0`: `Pixi_CreatePickList` runs immediately. It reads its parameters from the temporary parameter table.\n\nThe lock is released afterwards.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ProfileId` | smallint | No | Key of the picklist profile (`PL_Profile.PLP_Key`). NULL or 0 uses the most recently updated default profile that is not a 1SS profile. |\n| `LocationId` | varchar(3) | No | Location for the picklist. NULL or empty becomes `001`. |\n| `OrderNr` | int | No | Restricts the picklist to this order number. NULL or 0 means no restriction. The order must exist. |\n| `BinFrom` | varchar(50) | No | Name of the first bin of the range in the chosen location. Its `BinSortNum` replaces the lower bin sort limit of the profile. |\n| `BinTo` | varchar(50) | No | Name of the last bin of the range in the chosen location. Its `BinSortNum` replaces the upper bin sort limit of the profile. |\n| `UserName` | varchar(50) | No | User recorded for the picklist creation. NULL or empty becomes `API`. |\n| `Comment` | varchar(8000) | No | Picklist comment (trimmed). Always replaces the profile comment, even when it is empty. |\n| `ExecuteAsynchronous` | bit | No | Controls whether the picklist is created immediately or queued. |\n| `OrderNrExternal` | varchar(50) | No | Restricts the picklist to the order with this external order number. Empty means no restriction. If `OrderNr` is also given, both must match the same order, and then only `OrderNr` is used. |\n\n**Synchronous mode (`ExecuteAsynchronous = 0`)**\n- No `INFO` row is returned.\n- The caller receives whatever `Pixi_CreatePickList` returns. That procedure is not attached, so its result sets and further side effects are not documented here.\n- The lock is session-scoped. If `Pixi_CreatePickList` fails with an error, the release may be skipped. The lock then stays held until the database session ends.\n\n**Asynchronous mode (default)**\n- The lock is held only while the queue entry is written. It does not prevent several queued creations from running at the same time.\n- The queued statement is built as a text string. Quotes in values such as `Comment` or `UserName` are not escaped, so an apostrophe can make the queued statement invalid.\n- The queued statement does not pass the profile values `OlderThanHour`, `OlderThanMinute`, `NewerThanHour`, `NewerThanMinute` and `DisablePicklistSplitOnBatchManagement`.\n\n**Pitfalls**\n- The location check never fails. If `LocationId` does not exist, the given value is kept and the location error message is never returned.\n- `Comment` always overwrites the profile comment. Omitting it clears the comment from the profile.\n- An empty string for `BinFrom` or `BinTo` is not treated as missing. It is looked up as a bin name and leads to an error.\n- The profile ID error message says \"could be found\", but it means that the profile was **not** found.\n\n**Other**\n- All lookups use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the items packed into a box, identified by box number and location, with order, orderline, item and scan data.\n\nLists the contents of a packing box.\n\n1. Both `BoxNr` and `LocId` must be given. If one of them is `NULL`, a status row with `Status` = `Error` is returned.\n2. The box is looked up in `boxes` by `BoxNr` and `LocationID`. If no box exists, a status row with `Status` = `Error` is returned.\n3. All `boxitems` rows of boxes with this number and location are collected (quantity, scan date, scanning user).\n4. Each box item is joined to its orderline (`Orderlines`) to get the Pixi order number, the external order number, the item and the picklist number used.\n5. The item master (`items`) supplies barcode (`EANUPC`), item name and weight. `MeasuredWeight` is the item weight multiplied by the packed quantity.\n\nOne row is returned per box item. No sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BoxNr` | int | Yes | Number of the box (`boxes.BoxNr`). |\n| `LocId` | varchar(3) | Yes | Location (warehouse) ID of the box (`boxes.LocationID`). |\n\n- All tables are read with `NOLOCK`, so uncommitted data can appear.\n- Box items whose orderline or item no longer exists are dropped silently because of inner joins.\n- If the box exists but contains no items, an empty result set is returned (no status row).\n- The existence check uses `TOP(1)`, but the item query filters only by box number and location. If several boxes share the same number and location, items of all of them are returned.\n- `MeasuredWeight` is not a measured value; it is calculated from the item master weight.\n- The column `oPicklistNumber` keeps its internal name (no alias).\n- On errors the procedure returns code 1.\n\nDocumentation: https://pixi-api-docs.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": "Returns the items packed into a box, identified by box number and location, with order, orderline, item and scan data.\n\nLists the contents of a packing box.\n\n1. Both `BoxNr` and `LocId` must be given. If one of them is `NULL`, a status row with `Status` = `Error` is returned.\n2. The box is looked up in `boxes` by `BoxNr` and `LocationID`. If no box exists, a status row with `Status` = `Error` is returned.\n3. All `boxitems` rows of boxes with this number and location are collected (quantity, scan date, scanning user).\n4. Each box item is joined to its orderline (`Orderlines`) to get the Pixi order number, the external order number, the item and the picklist number used.\n5. The item master (`items`) supplies barcode (`EANUPC`), item name and weight. `MeasuredWeight` is the item weight multiplied by the packed quantity.\n\nOne row is returned per box item. No sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BoxNr` | int | Yes | Number of the box (`boxes.BoxNr`). |\n| `LocId` | varchar(3) | Yes | Location (warehouse) ID of the box (`boxes.LocationID`). |\n\n- All tables are read with `NOLOCK`, so uncommitted data can appear.\n- Box items whose orderline or item no longer exists are dropped silently because of inner joins.\n- If the box exists but contains no items, an empty result set is returned (no status row).\n- The existence check uses `TOP(1)`, but the item query filters only by box number and location. If several boxes share the same number and location, items of all of them are returned.\n- `MeasuredWeight` is not a measured value; it is calculated from the item master weight.\n- The column `oPicklistNumber` keeps its internal name (no alias).\n- On errors the procedure returns code 1.\n\nDocumentation: https://pixi-api-docs.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": "Returns the shipping packages of an invoice (labels, tracking IDs, weight, dimensions), selected by invoice number, invoice ID or package ID.\n\nReads the packages stored for an invoice in `pixi.InvoicePackage`, together with the package dimension code, the external order number and the invoice number.\n\n**Parameter handling and checks** (each failed check returns a single `Status`/`Message` row with `Status` = `Error`):\n\n1. An empty `InvoiceNumber` is treated as `NULL`. At least one of `InvoiceNumber`, `InvoiceId`, `PackageId` must be given.\n2. `InvoiceNumber` is resolved to an invoice ID (first match on `InvoiceNr`).\n3. If `InvoiceId` or the resolved ID is set, at least one of them must exist in `Invoices`.\n4. If `PackageId` is given, the package must exist.\n5. If `InvoiceId` and `InvoiceNumber` point to different invoices, the call fails.\n6. If both a package and an invoice are given, the package must belong to that invoice.\n\n**Selection**\n\n- The effective invoice is `InvoiceId`, otherwise the invoice resolved from `InvoiceNumber`.\n- Returned are all packages where the package ID equals `PackageId` **or** the invoice ID equals the effective invoice. If an invoice is given, all of its packages are returned, even if `PackageId` is also given. If only `PackageId` is given, only that package is returned.\n- `InvoiceNr` and `OrderNrExternal` are the same in every row. They are taken from the invoice (given directly or via the package) that is linked to order lines: `OrderNrExternal` comes from the order with the highest `Order_Id` of the invoice lines.\n- No sort order is defined.\n\nIf no package matches, an `Info` row is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNumber` | varchar(20) | No | Invoice number (`InvoiceNr`) of the invoice whose packages are requested. An empty string is treated as `NULL`. |\n| `InvoiceId` | int | No | Internal invoice ID (`InvoiceKey`). Takes precedence over the ID resolved from `InvoiceNumber`. Both must point to the same invoice if both are given. |\n| `PackageId` | int | No | ID of a package in `pixi.InvoicePackage`. If an invoice is also given, the package must belong to it. |\n\n- All reads use `NOLOCK`, so uncommitted data can be returned.\n- The response shape differs: on error or when nothing is found, a `Status`/`Message` row is returned instead of package rows. Check for a `Status` column.\n- An invoice number that does not exist is not reported as an error when no `InvoiceId` is given. Without `PackageId` the call then returns the `Info` row. With `PackageId` it returns only that package.\n- If `InvoiceId` does not exist but `InvoiceNumber` is valid, the error is the \"Two different invoices\" message, not \"No invoice found\".\n- An invoice is ignored for `InvoiceNr`/`OrderNrExternal` if it has no invoice lines or if any of its invoice lines has no order line reference. In that case both columns are `NULL`, but the packages are still returned.\n- The return value is 1 on error and 0 otherwise. It is not part of the SOAP result rows.\n\nDocumentation: https://pixi-api-docs.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": "Returns the shipping packages of an invoice (labels, tracking IDs, weight, dimensions), selected by invoice number, invoice ID or package ID.\n\nReads the packages stored for an invoice in `pixi.InvoicePackage`, together with the package dimension code, the external order number and the invoice number.\n\n**Parameter handling and checks** (each failed check returns a single `Status`/`Message` row with `Status` = `Error`):\n\n1. An empty `InvoiceNumber` is treated as `NULL`. At least one of `InvoiceNumber`, `InvoiceId`, `PackageId` must be given.\n2. `InvoiceNumber` is resolved to an invoice ID (first match on `InvoiceNr`).\n3. If `InvoiceId` or the resolved ID is set, at least one of them must exist in `Invoices`.\n4. If `PackageId` is given, the package must exist.\n5. If `InvoiceId` and `InvoiceNumber` point to different invoices, the call fails.\n6. If both a package and an invoice are given, the package must belong to that invoice.\n\n**Selection**\n\n- The effective invoice is `InvoiceId`, otherwise the invoice resolved from `InvoiceNumber`.\n- Returned are all packages where the package ID equals `PackageId` **or** the invoice ID equals the effective invoice. If an invoice is given, all of its packages are returned, even if `PackageId` is also given. If only `PackageId` is given, only that package is returned.\n- `InvoiceNr` and `OrderNrExternal` are the same in every row. They are taken from the invoice (given directly or via the package) that is linked to order lines: `OrderNrExternal` comes from the order with the highest `Order_Id` of the invoice lines.\n- No sort order is defined.\n\nIf no package matches, an `Info` row is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNumber` | varchar(20) | No | Invoice number (`InvoiceNr`) of the invoice whose packages are requested. An empty string is treated as `NULL`. |\n| `InvoiceId` | int | No | Internal invoice ID (`InvoiceKey`). Takes precedence over the ID resolved from `InvoiceNumber`. Both must point to the same invoice if both are given. |\n| `PackageId` | int | No | ID of a package in `pixi.InvoicePackage`. If an invoice is also given, the package must belong to it. |\n\n- All reads use `NOLOCK`, so uncommitted data can be returned.\n- The response shape differs: on error or when nothing is found, a `Status`/`Message` row is returned instead of package rows. Check for a `Status` column.\n- An invoice number that does not exist is not reported as an error when no `InvoiceId` is given. Without `PackageId` the call then returns the `Info` row. With `PackageId` it returns only that package.\n- If `InvoiceId` does not exist but `InvoiceNumber` is valid, the error is the \"Two different invoices\" message, not \"No invoice found\".\n- An invoice is ignored for `InvoiceNr`/`OrderNrExternal` if it has no invoice lines or if any of its invoice lines has no order line reference. In that case both columns are `NULL`, but the packages are still returned.\n- The return value is 1 on error and 0 otherwise. It is not part of the SOAP result rows.\n\nDocumentation: https://pixi-api-docs.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": "Returns shipped orders (based on invoices) for a date range per location, either as detail rows or as order count and total per location and currency.\n\nDetermines shipped orders through their invoices and returns them per location (`LocationID` of the order lines).\n\n**Step 1 – select invoices.** An invoice qualifies if:\n- at least one of its invoice lines belongs to an order line that has an `OrderHistory` entry with status `EIN`,\n- its date is between `@FromDate` and `@ToDate` (inclusive). With `@SearchByScanOutDate = 1` the scan-out date (`ScanOutDate`) is used, otherwise the invoice date (`InvDate`),\n- its `total` is greater than 0. With `@IncludeOrdersWithTotalZero = 1` invoices with a total of exactly 0 are included as well. Negative totals are never included,\n- if `@CustomerNrExternal` is set (blanks are trimmed, empty means no filter), the customer of the invoice has this external customer number.\n\n**Step 2 – orders per invoice and location.** For each selected invoice, the distinct combinations of `LocationID` and `OrderNrExternal` of the order lines on that invoice are collected. If `@LocId` is set, only order lines of this location are considered. Each combination is numbered per invoice, ordered by `OrderNrExternal`.\n\n**Step 3 – output.**\n- `@ShowDetails = 1` (default): one row per invoice, location and external order number with invoice data, customer name, shipping address, currency, shipping vendor and tracking ID. Invoice values are repeated if an invoice contains several external orders or locations. Sorted by `InvDate`.\n- Any other value: one row per location and currency with the number of rows (`NrOfOrders`) and the sum of the invoice totals (`Total`). No sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShowDetails` | int | No | Output mode: `1` returns detail rows, any other value returns counts and totals per location and currency. |\n| `FromDate` | varchar(25) | Yes | Start of the period (inclusive), compared with the invoice date or scan-out date. |\n| `ToDate` | varchar(25) | Yes | End of the period (inclusive). Without a time part it means midnight at the start of that day. |\n| `CustomerNrExternal` | varchar(60) | No | Optional external customer number; only invoices of this customer are returned. Empty or blank means no filter. |\n| `IncludeOrdersWithTotalZero` | bit | No | If `1`, invoices with a total of 0 are included; otherwise only invoices with a total greater than 0. |\n| `SearchByScanOutDate` | bit | No | Selects which date the period refers to. |\n| `LocId` | varchar(3) | No | Optional location ID; only order lines of this location are considered. Empty means all locations. |\n\n- All tables are read with `NOLOCK`; results may contain uncommitted data.\n- `@FromDate` and `@ToDate` are `varchar` values compared with `BETWEEN`. A `@ToDate` without time (e.g. `2024-01-31`) means midnight, so invoices later on that day are excluded. Pass `2024-01-31 23:59:59` or the following day. Use an unambiguous format such as `yyyy-mm-dd hh:mi:ss`.\n- In summary mode `NrOfOrders` counts the combinations of invoice, location and external order number, not distinct invoices.\n- In summary mode an invoice total is counted only once per invoice: it is added to the location of the combination with the alphabetically first `OrderNrExternal` on that invoice. If an invoice contains order lines of several locations, the whole total is assigned to one location only. With `@LocId` set, numbering is done only over the filtered rows, so the full invoice total is attributed to that location.\n- Invoices without a matching customer are excluded; in detail mode also invoices without a matching shipping address (`ShipAdrRef`) or currency are excluded (inner joins).\n- Invoices whose order lines have no `OrderHistory` status `EIN` are not returned, regardless of the date.\n\nDocumentation: https://pixi-api-docs.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": "Returns shipped orders (based on invoices) for a date range per location, either as detail rows or as order count and total per location and currency.\n\nDetermines shipped orders through their invoices and returns them per location (`LocationID` of the order lines).\n\n**Step 1 – select invoices.** An invoice qualifies if:\n- at least one of its invoice lines belongs to an order line that has an `OrderHistory` entry with status `EIN`,\n- its date is between `@FromDate` and `@ToDate` (inclusive). With `@SearchByScanOutDate = 1` the scan-out date (`ScanOutDate`) is used, otherwise the invoice date (`InvDate`),\n- its `total` is greater than 0. With `@IncludeOrdersWithTotalZero = 1` invoices with a total of exactly 0 are included as well. Negative totals are never included,\n- if `@CustomerNrExternal` is set (blanks are trimmed, empty means no filter), the customer of the invoice has this external customer number.\n\n**Step 2 – orders per invoice and location.** For each selected invoice, the distinct combinations of `LocationID` and `OrderNrExternal` of the order lines on that invoice are collected. If `@LocId` is set, only order lines of this location are considered. Each combination is numbered per invoice, ordered by `OrderNrExternal`.\n\n**Step 3 – output.**\n- `@ShowDetails = 1` (default): one row per invoice, location and external order number with invoice data, customer name, shipping address, currency, shipping vendor and tracking ID. Invoice values are repeated if an invoice contains several external orders or locations. Sorted by `InvDate`.\n- Any other value: one row per location and currency with the number of rows (`NrOfOrders`) and the sum of the invoice totals (`Total`). No sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShowDetails` | int | No | Output mode: `1` returns detail rows, any other value returns counts and totals per location and currency. |\n| `FromDate` | varchar(25) | Yes | Start of the period (inclusive), compared with the invoice date or scan-out date. |\n| `ToDate` | varchar(25) | Yes | End of the period (inclusive). Without a time part it means midnight at the start of that day. |\n| `CustomerNrExternal` | varchar(60) | No | Optional external customer number; only invoices of this customer are returned. Empty or blank means no filter. |\n| `IncludeOrdersWithTotalZero` | bit | No | If `1`, invoices with a total of 0 are included; otherwise only invoices with a total greater than 0. |\n| `SearchByScanOutDate` | bit | No | Selects which date the period refers to. |\n| `LocId` | varchar(3) | No | Optional location ID; only order lines of this location are considered. Empty means all locations. |\n\n- All tables are read with `NOLOCK`; results may contain uncommitted data.\n- `@FromDate` and `@ToDate` are `varchar` values compared with `BETWEEN`. A `@ToDate` without time (e.g. `2024-01-31`) means midnight, so invoices later on that day are excluded. Pass `2024-01-31 23:59:59` or the following day. Use an unambiguous format such as `yyyy-mm-dd hh:mi:ss`.\n- In summary mode `NrOfOrders` counts the combinations of invoice, location and external order number, not distinct invoices.\n- In summary mode an invoice total is counted only once per invoice: it is added to the location of the combination with the alphabetically first `OrderNrExternal` on that invoice. If an invoice contains order lines of several locations, the whole total is assigned to one location only. With `@LocId` set, numbering is done only over the filtered rows, so the full invoice total is attributed to that location.\n- Invoices without a matching customer are excluded; in detail mode also invoices without a matching shipping address (`ShipAdrRef`) or currency are excluded (inner joins).\n- Invoices whose order lines have no `OrderHistory` status `EIN` are not returned, regardless of the date.\n\nDocumentation: https://pixi-api-docs.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": "Returns the shipping vendors (carriers) defined in Pixi, optionally filtered by key, name, code or tracking flag, with the type of the connected channel.\n\nReads the shipping vendors from the `ShipVendor` table. For each vendor it also returns the name of the channel type of the connected channel, if any.\n\n**Filtering**\n\n- Empty values are treated as \"not set\". This means `0` for `ShipVendorKey` and an empty string for the text parameters.\n- If no parameter is set, all shipping vendors are returned.\n- If one or more parameters are set, a vendor is returned when **at least one** of the set filters matches exactly. The filters are combined with **OR**, not AND.\n - `ShipVendorKey` must equal the given key.\n - `ShipVendorName` must equal the given name.\n - `ShipVendorCode` must equal the given code.\n - `Tracking` must equal the given flag.\n\n**Channel type**\n\nThe procedure joins the vendor's `ConnectedChannelId` to the channel table and then to the channel type table. `ChannelType` is empty (NULL) for vendors without a connected channel.\n\nNo sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShipVendorKey` | int | No | Key of the shipping vendor. `0` means not set. |\n| `ShipVendorName` | varchar(50) | No | Exact name of the shipping vendor. An empty string means not set. |\n| `ShipVendorCode` | varchar(3) | No | Exact code of the shipping vendor. An empty string means not set. |\n| `Tracking` | varchar(1) | No | Exact value of the tracking flag of the shipping vendor. An empty string means not set. |\n\n- Because the filters are OR-combined, the result can grow when several filters are set. For example, setting `ShipVendorCode` = `UPS` and `Tracking` = `Y` returns every UPS vendor plus every vendor with tracking enabled. To narrow the result, set a single filter and filter further on the client side.\n- The comparisons are exact matches. Wildcards are not supported. Case sensitivity depends on the database collation.\n- The code does not restrict the values of `Tracking`. Typical values are a one-character flag such as `Y`/`N`, but this is not enforced by the procedure.\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n\nDocumentation: https://pixi-api-docs.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": "Returns the shipping vendors (carriers) defined in Pixi, optionally filtered by key, name, code or tracking flag, with the type of the connected channel.\n\nReads the shipping vendors from the `ShipVendor` table. For each vendor it also returns the name of the channel type of the connected channel, if any.\n\n**Filtering**\n\n- Empty values are treated as \"not set\". This means `0` for `ShipVendorKey` and an empty string for the text parameters.\n- If no parameter is set, all shipping vendors are returned.\n- If one or more parameters are set, a vendor is returned when **at least one** of the set filters matches exactly. The filters are combined with **OR**, not AND.\n - `ShipVendorKey` must equal the given key.\n - `ShipVendorName` must equal the given name.\n - `ShipVendorCode` must equal the given code.\n - `Tracking` must equal the given flag.\n\n**Channel type**\n\nThe procedure joins the vendor's `ConnectedChannelId` to the channel table and then to the channel type table. `ChannelType` is empty (NULL) for vendors without a connected channel.\n\nNo sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShipVendorKey` | int | No | Key of the shipping vendor. `0` means not set. |\n| `ShipVendorName` | varchar(50) | No | Exact name of the shipping vendor. An empty string means not set. |\n| `ShipVendorCode` | varchar(3) | No | Exact code of the shipping vendor. An empty string means not set. |\n| `Tracking` | varchar(1) | No | Exact value of the tracking flag of the shipping vendor. An empty string means not set. |\n\n- Because the filters are OR-combined, the result can grow when several filters are set. For example, setting `ShipVendorCode` = `UPS` and `Tracking` = `Y` returns every UPS vendor plus every vendor with tracking enabled. To narrow the result, set a single filter and filter further on the client side.\n- The comparisons are exact matches. Wildcards are not supported. Case sensitivity depends on the database collation.\n- The code does not restrict the values of `Tracking`. Typical values are a one-character flag such as `Y`/`N`, but this is not enforced by the procedure.\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n\nDocumentation: https://pixi-api-docs.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": "Sets one or more shipment tracking IDs on an invoice and its packages, optionally replacing existing packages and re-flagging the order for shipping notification export.\n\nStores tracking IDs for an invoice. The call returns no result set.\n\n**1. Finding the invoice**\n\n- The invoice is looked up in `Invoices` by `InvoiceNR`.\n- The call also tries shortened numbers. It removes suffixes after the last `-`, one at a time: `R1001-2-1`, then `R1001-2`, then `R1001`. All matching numbers are checked.\n- If no invoice matches, nothing is changed and the call ends without an error.\n\n**2. Separator**\n\n- If `Separator` is not `;` and not empty, every occurrence of it in `TrackingID` is replaced by `;`.\n- `TrackingID` can therefore hold several tracking IDs, for example separated by `,` or `|`.\n\n**3. Overwrite (`Overwrite` = 1)**\n\n- All invoice packages (`pixi.InvoicePackage`) of the invoice are deleted, together with their package lines (`pixi.InvoicePackageLines`).\n- References to these packages in `InvoicePolling` are set to `NULL`.\n\n**4. Setting the tracking IDs**\n\nThe internal procedure `Pixi_SetTrackingId` is called. It splits the list and ignores tracking IDs that are already stored in `Invoices.ShipmentTrackingID`.\n\nIf the invoice has no packages with items from a packing station:\n\n- If the invoice has exactly one package and it has no tracking ID yet, that package gets the first new ID.\n- Every further new ID creates a new package.\n- `ShipmentTrackingID` of the invoice is rebuilt from the distinct tracking IDs of all its packages, sorted and separated by `;`.\n\nIf the invoice has packages with items:\n\n- With exactly one package, that package gets the last new ID.\n- With several packages, the packages are not changed.\n- `ShipmentTrackingID` becomes the union of the existing and the new IDs.\n\nIn both cases the invoice also gets:\n\n- `Packages` set to the number of packages;\n- `UpdateDate` and `UpdateEmp` (`TrackingID Import`) set;\n- an `InvoiceChanged` event published.\n\n**5. Re-export (`ResetClientNotifiedFlag` = 1)**\n\n- For each order line on the invoice, the latest `OrderHistory` entry with status `AUS` is selected.\n- Its `ClientNotified` flag is set to `N`.\n- The shipping status is then exported again, now including the tracking ID.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNR` | varchar(20) | Yes | Invoice number. Suffixes after `-` are stripped step by step if the full number does not exist. |\n| `TrackingID` | varchar(512) | Yes | One or more tracking IDs, separated by `Separator`. |\n| `Overwrite` | bit | No | If 1, all existing packages and package lines of the invoice are deleted before the tracking IDs are set. |\n| `ResetClientNotifiedFlag` | bit | No | If 1, the latest `AUS` order history entries of the invoiced order lines get `ClientNotified` = `N`, so they are exported again. |\n| `Separator` | varchar(1) | No | Character that separates several tracking IDs in `TrackingID`. It is converted to `;` internally. |\n\n- **Transaction:** The call runs in its own transaction, or in a savepoint if a transaction is already open.\n- **Errors are not reported:** Errors are caught and written to the Pixi error log (`log.InsertError`). They are not raised to the caller, so a failed call looks like a successful one.\n- **Unknown invoice:** An unknown invoice number is silently ignored.\n- **Suffix lookup:** If several numbers match during the lookup, the variable assignment over an ordered result usually keeps the last row. That is the shortest matching number, for example the main invoice `R1001` rather than `R1001-2`. Avoid ambiguous numbers.\n- **Pitfall with `Overwrite`:** Packages are deleted, but tracking IDs already stored in `Invoices.ShipmentTrackingID` are still treated as existing and are not imported again. If such IDs are passed again together with `Overwrite` = 1, they are not recreated as packages. They can disappear from `ShipmentTrackingID`, which may even become `NULL`.\n- **Several packages with items:** If the invoice has several packages with items, no package gets the new tracking IDs; only the invoice header is updated. The internal procedure itself recommends setting tracking IDs per package instead.\n- **Splitting:** Single tracking IDs are truncated to 512 characters. Splitting is done by `dbo.fPixi_GetCommaSplit`, which is not attached.\n- **Locking hints:** Reads use `NOLOCK`, writes use `ROWLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Scans a single orderline into a box (scan-in with picklist), optionally splitting the orderline and validating batch number and best-before date.\n\nPerforms the scan-in of one orderline into a shipping box, as the Pixi shipping client does for **scan-in with picklist**. The call works on the exact orderline given in `OrderlineKey`.\n\nSteps:\n\n1. Checks that the setting `Premium_API` is enabled. Otherwise an error row is returned.\n2. Reads item and location of the orderline. If the setting `BatchManagement` is `1`, it checks whether the item carries the batch number tag (`TagId` -6) or the best-before tag (`TagId` -7). Without either tag, batch management is treated as off for this item.\n3. If batch management is off but `BatchNumber` or `BestBeforeDate` is sent, the call fails with `Wrong Batch Management data`.\n4. If batch management is on, it counts the active picklist items (`PLitem`, `Expired = 0`) of the orderline whose bin item has exactly the given batch number and best-before date. If there are none, the call fails.\n5. If `PickListNr` is `0` but the orderline is on an active picklist, the call fails with `Item is part of picklist: …`.\n6. Looks up the orderline through the scan-in search logic, restricted to this orderline and the given picklist. The orderline must be in a status that allows scan-in, must not belong to a locked customer or address (unless the user has the permission `SHILC`), and with a picklist it must be on that picklist. If nothing is found: `No order found!`.\n7. Determines the quantity to put into the box:\n - the picklist quantity of the orderline, capped to the number of matching batch items when batch management is on;\n - if `ScannedQty` is not `0`, it must not exceed that quantity and replaces it.\n8. If the orderline quantity is larger than this quantity, the orderline is split so that the scanned part keeps the determined quantity (`GOSBreakOrderline`).\n9. Calls the internal put-into-box logic (`Pixi_PutIntoBox`). It uses the stock movement operation `ScanInWithPicklist` of application `ShippingClient_A` and the log reason `API - ScanIn with picklist`. The logic:\n - takes `FromBox`/`ToBox` from the picklist header if it defines a box range;\n - finds a box for the customer, or performs an internal transfer if the order location differs from the last order location;\n - checks that the box does not contain items of another customer and that the order is not already in another open box;\n - updates the orderline for scan-in and releases the picklist items from the bin;\n - publishes the message queue event `ScanInPutIntoBox`, and `ScanInBoxFull` if the box is now full.\n\nThe result is one row with the box and an `Action` value. `IN BOX LEGEN` means success; other values describe why the item was not put into a box.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Yes | Key of the orderline to scan into a box. |\n| `SupplGroup` | varchar(5) | Yes | Supplier group stored with the scan-in. If it is empty and the orderline status is `SHL`, the supplier group already stored on the orderline is used. |\n| `Username` | varchar(50) | Yes | Pixi user who performs the scan-in. Used for permissions, logging and the orderline update. |\n| `SupplOrderNr` | int | No | Supplier order number. Must be `0`; any other value makes the internal orderline lookup fail. |\n| `FromBox` | int | Yes | Lowest box number to use. Replaced by the picklist's box range if the picklist header defines one. |\n| `ToBox` | int | Yes | Highest box number to use. Replaced by the picklist's box range if the picklist header defines one. |\n| `SerialNr` | varchar(200) | Yes | Serial number of the scanned item. `NULL` is treated as an empty string. |\n| `PickListNr` | int | No | Picklist number (`PLHkey`). `0` means scan-in without picklist, which is rejected if the orderline is on an active picklist. |\n| `IsPersonalizedScanIn` | bit | No | Marks a scan-in of a personalized item (tag -1). Must match the item's tag, otherwise an error action is returned. |\n| `BinRef` | int | No | Bin location key passed on when the picklist items are released from the bin. |\n| `BatchNumber` | varchar(50) | No | Batch number (Charge) of the scanned item. Only allowed if batch management is active for the item; must match a picklist item of the orderline. |\n| `BestBeforeDate` | datetime | No | Best-before date of the scanned item. Only allowed if batch management is active for the item; must match a picklist item of the orderline. |\n| `ScannedQty` | int | No | Quantity scanned. `0` uses the full picklist quantity of the orderline; otherwise it must not exceed the picklist quantity, and the orderline is split if needed. |\n\n- Requires the setting `Premium_API`.\n- All lookups use `NOLOCK`.\n- The call has no transaction of its own. The orderline split in step 8 runs in its own transaction (with an application lock on the orderline) and is committed **before** the item is put into the box. If the put-into-box step then fails, the split remains.\n- Without a picklist (`PickListNr = 0`) the scan-in search returns a picklist quantity of `0`. Any `ScannedQty` other than `0` is then rejected, and the split step is called with a new quantity of `0`. What the split does in that case depends on `GOSBreakOrderline_Base`, which is not attached. The call is designed for scan-in with picklist.\n- Any `SupplOrderNr` other than `0` makes the internal orderline lookup fail, so the result is `FEHLER` with `0010. BESTELL. GEANDERT !`.\n- If `SupplGroup` is empty and the orderline status is `SHL`, the supplier group stored on the orderline (`SupplGroupScanIn`) is used instead. The value is passed on as `varchar(4)`.\n- `BestBeforeDate` is passed on as 1900-01-01 when it is not sent. If the global setting `BatchManagement` is `1` and the picklist has `DaysBeforeBBD` set, this date can lead to `MHD nicht zulässig`.\n- The setting `OnlyPicklistScanIn = 1` without a picklist returns the action `Keine Pickliste`.\n- Deadlocks (error 1205) inside the put-into-box step are retried up to 10 times. Other errors are caught, written to `LogTable` and returned as an action row instead of a SQL error.\n- Several called objects are not attached: `Pixi_ShipToCustomer`, `Pixi_ShipIntern`, `GOSUpdateOrderlineForScanIn`, `Pixi_ReleasePLitemFromBin`, `GOSBreakOrderline_Base`, `pixi.FullBoxesGet` and `Pixi_MQ_EventPublish`. Their exact data changes, and whether they emit additional result sets or errors, cannot be seen.\n- For an internal transfer (order location differs from the last order location) no box key is determined, so the result shows `BoxNr` = 0.\n- The text `MHD nicht zulässig` appears with broken encoding in the source and may arrive as `MHD nicht zulässig`.\n\nDocumentation: https://pixi-api-docs.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": "Scans a single orderline into a box (scan-in with picklist), optionally splitting the orderline and validating batch number and best-before date.\n\nPerforms the scan-in of one orderline into a shipping box, as the Pixi shipping client does for **scan-in with picklist**. The call works on the exact orderline given in `OrderlineKey`.\n\nSteps:\n\n1. Checks that the setting `Premium_API` is enabled. Otherwise an error row is returned.\n2. Reads item and location of the orderline. If the setting `BatchManagement` is `1`, it checks whether the item carries the batch number tag (`TagId` -6) or the best-before tag (`TagId` -7). Without either tag, batch management is treated as off for this item.\n3. If batch management is off but `BatchNumber` or `BestBeforeDate` is sent, the call fails with `Wrong Batch Management data`.\n4. If batch management is on, it counts the active picklist items (`PLitem`, `Expired = 0`) of the orderline whose bin item has exactly the given batch number and best-before date. If there are none, the call fails.\n5. If `PickListNr` is `0` but the orderline is on an active picklist, the call fails with `Item is part of picklist: …`.\n6. Looks up the orderline through the scan-in search logic, restricted to this orderline and the given picklist. The orderline must be in a status that allows scan-in, must not belong to a locked customer or address (unless the user has the permission `SHILC`), and with a picklist it must be on that picklist. If nothing is found: `No order found!`.\n7. Determines the quantity to put into the box:\n - the picklist quantity of the orderline, capped to the number of matching batch items when batch management is on;\n - if `ScannedQty` is not `0`, it must not exceed that quantity and replaces it.\n8. If the orderline quantity is larger than this quantity, the orderline is split so that the scanned part keeps the determined quantity (`GOSBreakOrderline`).\n9. Calls the internal put-into-box logic (`Pixi_PutIntoBox`). It uses the stock movement operation `ScanInWithPicklist` of application `ShippingClient_A` and the log reason `API - ScanIn with picklist`. The logic:\n - takes `FromBox`/`ToBox` from the picklist header if it defines a box range;\n - finds a box for the customer, or performs an internal transfer if the order location differs from the last order location;\n - checks that the box does not contain items of another customer and that the order is not already in another open box;\n - updates the orderline for scan-in and releases the picklist items from the bin;\n - publishes the message queue event `ScanInPutIntoBox`, and `ScanInBoxFull` if the box is now full.\n\nThe result is one row with the box and an `Action` value. `IN BOX LEGEN` means success; other values describe why the item was not put into a box.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Yes | Key of the orderline to scan into a box. |\n| `SupplGroup` | varchar(5) | Yes | Supplier group stored with the scan-in. If it is empty and the orderline status is `SHL`, the supplier group already stored on the orderline is used. |\n| `Username` | varchar(50) | Yes | Pixi user who performs the scan-in. Used for permissions, logging and the orderline update. |\n| `SupplOrderNr` | int | No | Supplier order number. Must be `0`; any other value makes the internal orderline lookup fail. |\n| `FromBox` | int | Yes | Lowest box number to use. Replaced by the picklist's box range if the picklist header defines one. |\n| `ToBox` | int | Yes | Highest box number to use. Replaced by the picklist's box range if the picklist header defines one. |\n| `SerialNr` | varchar(200) | Yes | Serial number of the scanned item. `NULL` is treated as an empty string. |\n| `PickListNr` | int | No | Picklist number (`PLHkey`). `0` means scan-in without picklist, which is rejected if the orderline is on an active picklist. |\n| `IsPersonalizedScanIn` | bit | No | Marks a scan-in of a personalized item (tag -1). Must match the item's tag, otherwise an error action is returned. |\n| `BinRef` | int | No | Bin location key passed on when the picklist items are released from the bin. |\n| `BatchNumber` | varchar(50) | No | Batch number (Charge) of the scanned item. Only allowed if batch management is active for the item; must match a picklist item of the orderline. |\n| `BestBeforeDate` | datetime | No | Best-before date of the scanned item. Only allowed if batch management is active for the item; must match a picklist item of the orderline. |\n| `ScannedQty` | int | No | Quantity scanned. `0` uses the full picklist quantity of the orderline; otherwise it must not exceed the picklist quantity, and the orderline is split if needed. |\n\n- Requires the setting `Premium_API`.\n- All lookups use `NOLOCK`.\n- The call has no transaction of its own. The orderline split in step 8 runs in its own transaction (with an application lock on the orderline) and is committed **before** the item is put into the box. If the put-into-box step then fails, the split remains.\n- Without a picklist (`PickListNr = 0`) the scan-in search returns a picklist quantity of `0`. Any `ScannedQty` other than `0` is then rejected, and the split step is called with a new quantity of `0`. What the split does in that case depends on `GOSBreakOrderline_Base`, which is not attached. The call is designed for scan-in with picklist.\n- Any `SupplOrderNr` other than `0` makes the internal orderline lookup fail, so the result is `FEHLER` with `0010. BESTELL. GEANDERT !`.\n- If `SupplGroup` is empty and the orderline status is `SHL`, the supplier group stored on the orderline (`SupplGroupScanIn`) is used instead. The value is passed on as `varchar(4)`.\n- `BestBeforeDate` is passed on as 1900-01-01 when it is not sent. If the global setting `BatchManagement` is `1` and the picklist has `DaysBeforeBBD` set, this date can lead to `MHD nicht zulässig`.\n- The setting `OnlyPicklistScanIn = 1` without a picklist returns the action `Keine Pickliste`.\n- Deadlocks (error 1205) inside the put-into-box step are retried up to 10 times. Other errors are caught, written to `LogTable` and returned as an action row instead of a SQL error.\n- Several called objects are not attached: `Pixi_ShipToCustomer`, `Pixi_ShipIntern`, `GOSUpdateOrderlineForScanIn`, `Pixi_ReleasePLitemFromBin`, `GOSBreakOrderline_Base`, `pixi.FullBoxesGet` and `Pixi_MQ_EventPublish`. Their exact data changes, and whether they emit additional result sets or errors, cannot be seen.\n- For an internal transfer (order location differs from the last order location) no box key is determined, so the result shows `BoxNr` = 0.\n- The text `MHD nicht zulässig` appears with broken encoding in the source and may arrive as `MHD nicht zulässig`.\n\nDocumentation: https://pixi-api-docs.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": "Ships out an order that sits alone in exactly one box: sets its boxed orderlines to status AUS and empties the box.\n\nPerforms the ship-out (scan-out) of an order that has been collected in a box and empties the box.\n\nSteps:\n\n1. Collects all boxes that contain orderlines of `OrderNr` (via `boxitems`) and every order that is in these boxes.\n2. Checks that at least one of the settings `Premium_API` or `Centralized_Ship_Out` is enabled. Otherwise an error is returned.\n3. Checks that the order is in exactly one box. If no box is found, or the order is spread over several boxes, an error is returned.\n4. Checks that the box contains no other order. If it does, an error is returned.\n5. Reads the shipping address of the box (`boxes.SAddrRef`) and checks the shipping lock. The customer flag `Customers.SLocked` and the address flag `Addresses.ASLocked` are checked. If either is `Y`, an error is returned.\n6. If all checks pass, three internal procedures run:\n - `GOSScanOutOrderline` with status `AUS`. It sets the orderlines in the box with status `EIN` to `AUS`. It also sets orderlines of the same invoices that have status `MIN`, or a status listed in the setting `PutThisStatusesOnInvoice`, to `AUS`. For these lines it sets `ShipDate`, updates the order header status, writes order history, deletes reservations, updates bundle lines and closes related return case lines and return cases.\n - `GOSDeleteAllItemsForBox` removes all `boxitems` of the box.\n - `GOSEmptyBox` resets the box: customer, addresses and order are set to 0, `BoxEndDate` is set to now, and the wait and lock flags are reset.\n\nThe call always returns one row with `Status` (`SUCCESS` or `ERROR`) and `Info`. `UserName` is stored as the updating employee on the changed records.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Number of the order whose box is to be shipped out and emptied. |\n| `UserName` | varchar(50) | No | User name stored as the updating employee on orderlines, history and return cases. |\n\n- All work runs in the named transaction `OrderToAUS`. On an error in the main procedure the transaction is rolled back. The returned row then has `Status` = `ERROR` and the SQL error text in `Info`. `Info` is truncated to 150 characters.\n- The called `GOS…` procedures catch their own errors and log them via `log.InsertError` without re-raising them. A failure inside them can therefore be rolled back (completely or to a savepoint) while the call still reports `SUCCESS`. Check the data if in doubt.\n- The box and order counts are taken from grouped queries. The value of the last processed group is used. In mixed cases (for example several boxes that hold several orders), the specific error message returned may vary. The call is still rejected as long as the order is not alone in a single box.\n- Reads use `NOLOCK`. Updates in the sub-procedures use `ROWLOCK`. `GOSScanOutOrderline` suppresses the `Orderlines` update trigger via `CONTEXT_INFO` and writes `OrderHistory` itself.\n- Validation errors still end with a commit, but nothing has been written at that point.\n\nDocumentation: https://pixi-api-docs.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": "Ships out an order that sits alone in exactly one box: sets its boxed orderlines to status AUS and empties the box.\n\nPerforms the ship-out (scan-out) of an order that has been collected in a box and empties the box.\n\nSteps:\n\n1. Collects all boxes that contain orderlines of `OrderNr` (via `boxitems`) and every order that is in these boxes.\n2. Checks that at least one of the settings `Premium_API` or `Centralized_Ship_Out` is enabled. Otherwise an error is returned.\n3. Checks that the order is in exactly one box. If no box is found, or the order is spread over several boxes, an error is returned.\n4. Checks that the box contains no other order. If it does, an error is returned.\n5. Reads the shipping address of the box (`boxes.SAddrRef`) and checks the shipping lock. The customer flag `Customers.SLocked` and the address flag `Addresses.ASLocked` are checked. If either is `Y`, an error is returned.\n6. If all checks pass, three internal procedures run:\n - `GOSScanOutOrderline` with status `AUS`. It sets the orderlines in the box with status `EIN` to `AUS`. It also sets orderlines of the same invoices that have status `MIN`, or a status listed in the setting `PutThisStatusesOnInvoice`, to `AUS`. For these lines it sets `ShipDate`, updates the order header status, writes order history, deletes reservations, updates bundle lines and closes related return case lines and return cases.\n - `GOSDeleteAllItemsForBox` removes all `boxitems` of the box.\n - `GOSEmptyBox` resets the box: customer, addresses and order are set to 0, `BoxEndDate` is set to now, and the wait and lock flags are reset.\n\nThe call always returns one row with `Status` (`SUCCESS` or `ERROR`) and `Info`. `UserName` is stored as the updating employee on the changed records.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | int | Yes | Number of the order whose box is to be shipped out and emptied. |\n| `UserName` | varchar(50) | No | User name stored as the updating employee on orderlines, history and return cases. |\n\n- All work runs in the named transaction `OrderToAUS`. On an error in the main procedure the transaction is rolled back. The returned row then has `Status` = `ERROR` and the SQL error text in `Info`. `Info` is truncated to 150 characters.\n- The called `GOS…` procedures catch their own errors and log them via `log.InsertError` without re-raising them. A failure inside them can therefore be rolled back (completely or to a savepoint) while the call still reports `SUCCESS`. Check the data if in doubt.\n- The box and order counts are taken from grouped queries. The value of the last processed group is used. In mixed cases (for example several boxes that hold several orders), the specific error message returned may vary. The call is still rejected as long as the order is not alone in a single box.\n- Reads use `NOLOCK`. Updates in the sub-procedures use `ROWLOCK`. `GOSScanOutOrderline` suppresses the `Orderlines` update trigger via `CONTEXT_INFO` and writes `OrderHistory` itself.\n- Validation errors still end with a commit, but nothing has been written at that point.\n\nDocumentation: https://pixi-api-docs.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": "Ships out an invoice or a box: updates packages, shipping vendor, weight and tracking IDs, scans out the box and releases picklist stock.\n\nPerforms a complete ship-out of one invoice via the API, identified by `InvoiceNr`, by `BoxNr` or by both.\n\n**Preparation and checks**\n- `BoxNr` = 0 is treated as NULL. `InvoiceNr`, `TrackingID` and `ShipVendorCode` are trimmed; empty strings become NULL.\n- The setting `Centralized_Ship_Out` or `Premium_API` must be enabled.\n- At least one of `InvoiceNr` / `BoxNr` is required.\n- `LocID` must exist in `Location`; a given `BoxNr` must exist in `boxes` (at any location).\n- The invoice is searched by `InvoiceNr` on location `LocID` and, additionally, via the order lines contained in box `BoxNr` on that location. Only invoice lines whose order line status is not `MIN` are considered. The box is taken from the box items of these order lines.\n- If no invoice is found, `No invoice found` is returned. If more than one combination of invoice/box is found (e.g. the box holds lines of several invoices, or the invoice lines are spread over several boxes or are only partly boxed), or the found invoice/box differs from the given one, an error row is returned.\n\n**Ship-out**\n1. If the invoice has a `RefToInvoiceKey`, box number -2 is used (the subsequent scan-out then fails with `0004. NO BOX !!!`). Otherwise an existing box at the location containing the invoice lines is used, or a new box is created for the invoice. If the customer or shipping address is locked or the invoice is already scanned out, a negative box number results and the scan-out fails as well.\n2. The number of packages is set to `AmountOfPackages` (minimum 1); invoice packages are added or removed accordingly.\n3. The shipping vendor is set to `ShipVendorCode` (or the invoice's current vendor if not given).\n4. The box is scanned out: lock and payment checks, invoice scan-out, order lines set to status `AUS`, box emptied, picklist box entries removed, poll records created.\n5. Only if the scan-out did not return `ERROR`:\n - the weight is written to the invoice and its packages (only if setting `CalculateWeightFromItems` is not enabled; if `Weight` is not given, the current `PackageGrossWeight` of the invoice is used),\n - `TrackingID` (semicolon-separated list) is stored on the invoice packages and the invoice,\n - stock reserved on the picklist is released using the stock movement operation `DirectInvoicesWizard` of application `ShippingClient_A` (user `Shipout (API)`),\n - for direct invoices (`InvCreationMode` = `Direct`) the box including its items is deleted.\n\nThe call returns exactly one row with `Status` and `StatusMessage`. On success `Status` is `OK` and `StatusMessage` is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | No | Number of the invoice to ship out. Either this or `BoxNr` must be provided. |\n| `UserName` | varchar(50) | No | User name recorded for box creation, scan-out and tracking ID update. |\n| `LocID` | char(3) | No | Location (warehouse) ID. Invoice and box are searched on this location. If NULL, the invoice's location is used. |\n| `BoxNr` | int | No | Box number containing the invoice's order lines. 0 is treated as NULL. Either this or `InvoiceNr` must be provided. |\n| `Weight` | float | No | Gross weight to store on the invoice and its packages. If NULL, the current `PackageGrossWeight` of the invoice is used. Ignored if setting `CalculateWeightFromItems` is enabled. |\n| `AmountOfPackages` | int | No | Number of packages for the invoice. Values below 1 are treated as 1. |\n| `ShipVendorCode` | varchar(3) | No | Shipping vendor code to set on the invoice. If empty, the invoice's current vendor is kept. |\n| `TrackingID` | varchar(8000) | No | One or more tracking IDs, separated by semicolons. Stored only after a successful scan-out. |\n\n- The call is **not wrapped in one transaction**. Package count and shipping vendor are updated *before* the scan-out and remain changed even if the scan-out returns `ERROR`. A box created for the invoice may also remain.\n- The parameter `BoxNr` is only used to find the invoice and to validate the combination; the box that is actually scanned out is determined internally (existing box with the invoice lines on `LocID`, or a newly created box).\n- Already scanned-out invoices, invoices with a `RefToInvoiceKey` and invoices of locked customers/addresses end with `0004. NO BOX !!!` rather than a specific message.\n- The error `Invoice ... could not be found on location ...` is practically unreachable, because an empty result is already reported as `No invoice found`.\n- If `LocID` is passed as NULL, the invoice's own location is used; error messages that concatenate `LocID` would then be NULL.\n- Settings read at runtime: `Centralized_Ship_Out`, `Premium_API`, `CalculateWeightFromItems`; in called procedures also `EnableMultiInvoiceShipOut`, `DoNotReleaseStockOnDirectInvoiceScanOut` and setting `7` (default weight 0.1 if weight is 0).\n- The scan-out retries up to five times on deadlocks; other SQL errors are logged and raised (returned as `SqlMessage`).\n- Reads use `NOLOCK`; the scan-out locks the box row with `UPDLOCK`. Pakete are updated under the app lock `PixiInvoicePackage` (timeout 30 s).\n- Events `InvoiceChanged` may be published when tracking IDs are set.\n\nDocumentation: https://pixi-api-docs.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": "Ships out an invoice or a box: updates packages, shipping vendor, weight and tracking IDs, scans out the box and releases picklist stock.\n\nPerforms a complete ship-out of one invoice via the API, identified by `InvoiceNr`, by `BoxNr` or by both.\n\n**Preparation and checks**\n- `BoxNr` = 0 is treated as NULL. `InvoiceNr`, `TrackingID` and `ShipVendorCode` are trimmed; empty strings become NULL.\n- The setting `Centralized_Ship_Out` or `Premium_API` must be enabled.\n- At least one of `InvoiceNr` / `BoxNr` is required.\n- `LocID` must exist in `Location`; a given `BoxNr` must exist in `boxes` (at any location).\n- The invoice is searched by `InvoiceNr` on location `LocID` and, additionally, via the order lines contained in box `BoxNr` on that location. Only invoice lines whose order line status is not `MIN` are considered. The box is taken from the box items of these order lines.\n- If no invoice is found, `No invoice found` is returned. If more than one combination of invoice/box is found (e.g. the box holds lines of several invoices, or the invoice lines are spread over several boxes or are only partly boxed), or the found invoice/box differs from the given one, an error row is returned.\n\n**Ship-out**\n1. If the invoice has a `RefToInvoiceKey`, box number -2 is used (the subsequent scan-out then fails with `0004. NO BOX !!!`). Otherwise an existing box at the location containing the invoice lines is used, or a new box is created for the invoice. If the customer or shipping address is locked or the invoice is already scanned out, a negative box number results and the scan-out fails as well.\n2. The number of packages is set to `AmountOfPackages` (minimum 1); invoice packages are added or removed accordingly.\n3. The shipping vendor is set to `ShipVendorCode` (or the invoice's current vendor if not given).\n4. The box is scanned out: lock and payment checks, invoice scan-out, order lines set to status `AUS`, box emptied, picklist box entries removed, poll records created.\n5. Only if the scan-out did not return `ERROR`:\n - the weight is written to the invoice and its packages (only if setting `CalculateWeightFromItems` is not enabled; if `Weight` is not given, the current `PackageGrossWeight` of the invoice is used),\n - `TrackingID` (semicolon-separated list) is stored on the invoice packages and the invoice,\n - stock reserved on the picklist is released using the stock movement operation `DirectInvoicesWizard` of application `ShippingClient_A` (user `Shipout (API)`),\n - for direct invoices (`InvCreationMode` = `Direct`) the box including its items is deleted.\n\nThe call returns exactly one row with `Status` and `StatusMessage`. On success `Status` is `OK` and `StatusMessage` is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvoiceNr` | varchar(20) | No | Number of the invoice to ship out. Either this or `BoxNr` must be provided. |\n| `UserName` | varchar(50) | No | User name recorded for box creation, scan-out and tracking ID update. |\n| `LocID` | char(3) | No | Location (warehouse) ID. Invoice and box are searched on this location. If NULL, the invoice's location is used. |\n| `BoxNr` | int | No | Box number containing the invoice's order lines. 0 is treated as NULL. Either this or `InvoiceNr` must be provided. |\n| `Weight` | float | No | Gross weight to store on the invoice and its packages. If NULL, the current `PackageGrossWeight` of the invoice is used. Ignored if setting `CalculateWeightFromItems` is enabled. |\n| `AmountOfPackages` | int | No | Number of packages for the invoice. Values below 1 are treated as 1. |\n| `ShipVendorCode` | varchar(3) | No | Shipping vendor code to set on the invoice. If empty, the invoice's current vendor is kept. |\n| `TrackingID` | varchar(8000) | No | One or more tracking IDs, separated by semicolons. Stored only after a successful scan-out. |\n\n- The call is **not wrapped in one transaction**. Package count and shipping vendor are updated *before* the scan-out and remain changed even if the scan-out returns `ERROR`. A box created for the invoice may also remain.\n- The parameter `BoxNr` is only used to find the invoice and to validate the combination; the box that is actually scanned out is determined internally (existing box with the invoice lines on `LocID`, or a newly created box).\n- Already scanned-out invoices, invoices with a `RefToInvoiceKey` and invoices of locked customers/addresses end with `0004. NO BOX !!!` rather than a specific message.\n- The error `Invoice ... could not be found on location ...` is practically unreachable, because an empty result is already reported as `No invoice found`.\n- If `LocID` is passed as NULL, the invoice's own location is used; error messages that concatenate `LocID` would then be NULL.\n- Settings read at runtime: `Centralized_Ship_Out`, `Premium_API`, `CalculateWeightFromItems`; in called procedures also `EnableMultiInvoiceShipOut`, `DoNotReleaseStockOnDirectInvoiceScanOut` and setting `7` (default weight 0.1 if weight is 0).\n- The scan-out retries up to five times on deadlocks; other SQL errors are logged and raised (returned as `SqlMessage`).\n- Reads use `NOLOCK`; the scan-out locks the box row with `UPDLOCK`. Pakete are updated under the app lock `PixiInvoicePackage` (timeout 30 s).\n- Events `InvoiceChanged` may be published when tracking IDs are set.\n\nDocumentation: https://pixi-api-docs.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": "Returns the positions of a picklist grouped by item, bin and order line, with bin, item, order and box details, optionally filtered by location, bin group and bin name.\n\nReads the picklist header (`PLheader`) identified by `PicklistKey` together with its picklist items (`PLItem`). Each picklist item is joined to the bin item (`InvBinItem`), the item (`Items`), the bin (`InvBin`) and the order line (`Orderlines`).\n\nThe picklist items are grouped per item, bin and order line. `Qty` is the number of picklist item rows in each group. Item numbers (`ItemNrSuppl`, `EanUpc`, `ItemNrInt`) are returned in upper case.\n\nFor every group the call also returns:\n- `OtherItemsCount`: `1` if the bin holds other items than this one, otherwise `0`\n- `PLHfromBox` / `PLHtoBox` of the picklist header\n- `BundleItemName`: the name of the bundle order line, or an empty string\n- `TotalItemsOnBin`: total quantity of all items on the bin\n- `TotalSimilarItemsOnBin`: total quantity of this item on the bin\n\nOptional filters, each ignored when `NULL` or empty:\n- `FilterLocation`: exact match on the bin's location ID\n- `FilterBinGroup`: `LIKE` match on the bin group, so wildcards such as `%` work\n- `FilterBinName`: `LIKE` match on the bin name, so wildcards such as `%` work\n\nThe rows are sorted by `BinGroup`, `BinSortNum` and `ItemName`, which gives a walking order through the warehouse.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PicklistKey` | int | No | Key of the picklist (`PLHkey`). `0` or `NULL` returns no rows. |\n| `FilterLocation` | varchar(3) | No | Optional location ID; only bins of this location are returned (exact match). Empty string means no filter. |\n| `FilterBinGroup` | varchar(20) | No | Optional bin group pattern, compared with `LIKE` (wildcards allowed). Empty string means no filter. |\n| `FilterBinName` | varchar(50) | No | Optional bin name pattern, compared with `LIKE` (wildcards allowed). Empty string means no filter. |\n\n- `PicklistKey` has a default of `NULL`, and `0` is also turned into `NULL`. In both cases no picklist matches, so the result set is empty. In practice the parameter must be sent.\n- All tables are read with `NOLOCK`, so uncommitted data can appear.\n- The column `PLIorderlineRef` appears twice in the result set (once from the grouped data and once as an explicit extra column). Depending on the client, the second occurrence may be renamed (for example `PLIorderlineRef1`) or overwrite the first; both hold the same value.\n- Despite its name, `OtherItemsCount` is a flag (`0`/`1`), not a count.\n- The grouping also includes the creator of the picklist and the creation date of the order line, which are not returned; rows that look identical can therefore appear more than once.\n- Data types of most columns depend on the table definitions, which are not part of the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns the positions of a picklist grouped by item, bin and order line, with bin, item, order and box details, optionally filtered by location, bin group and bin name.\n\nReads the picklist header (`PLheader`) identified by `PicklistKey` together with its picklist items (`PLItem`). Each picklist item is joined to the bin item (`InvBinItem`), the item (`Items`), the bin (`InvBin`) and the order line (`Orderlines`).\n\nThe picklist items are grouped per item, bin and order line. `Qty` is the number of picklist item rows in each group. Item numbers (`ItemNrSuppl`, `EanUpc`, `ItemNrInt`) are returned in upper case.\n\nFor every group the call also returns:\n- `OtherItemsCount`: `1` if the bin holds other items than this one, otherwise `0`\n- `PLHfromBox` / `PLHtoBox` of the picklist header\n- `BundleItemName`: the name of the bundle order line, or an empty string\n- `TotalItemsOnBin`: total quantity of all items on the bin\n- `TotalSimilarItemsOnBin`: total quantity of this item on the bin\n\nOptional filters, each ignored when `NULL` or empty:\n- `FilterLocation`: exact match on the bin's location ID\n- `FilterBinGroup`: `LIKE` match on the bin group, so wildcards such as `%` work\n- `FilterBinName`: `LIKE` match on the bin name, so wildcards such as `%` work\n\nThe rows are sorted by `BinGroup`, `BinSortNum` and `ItemName`, which gives a walking order through the warehouse.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PicklistKey` | int | No | Key of the picklist (`PLHkey`). `0` or `NULL` returns no rows. |\n| `FilterLocation` | varchar(3) | No | Optional location ID; only bins of this location are returned (exact match). Empty string means no filter. |\n| `FilterBinGroup` | varchar(20) | No | Optional bin group pattern, compared with `LIKE` (wildcards allowed). Empty string means no filter. |\n| `FilterBinName` | varchar(50) | No | Optional bin name pattern, compared with `LIKE` (wildcards allowed). Empty string means no filter. |\n\n- `PicklistKey` has a default of `NULL`, and `0` is also turned into `NULL`. In both cases no picklist matches, so the result set is empty. In practice the parameter must be sent.\n- All tables are read with `NOLOCK`, so uncommitted data can appear.\n- The column `PLIorderlineRef` appears twice in the result set (once from the grouped data and once as an explicit extra column). Depending on the client, the second occurrence may be renamed (for example `PLIorderlineRef1`) or overwrite the first; both hold the same value.\n- Despite its name, `OtherItemsCount` is a flag (`0`/`1`), not a count.\n- The grouping also includes the creator of the picklist and the creation date of the order line, which are not returned; rows that look identical can therefore appear more than once.\n- Data types of most columns depend on the table definitions, which are not part of the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns the headers of all valid, unreserved and fully executed picklists of a location, with first/last bin and item count.\n\nReturns one row per picklist header from `PLHeader` that is currently usable for picking.\n\n**Filter**\n- `PLHlocID` equals `@LocID`. If `LocID` is empty or omitted, location `001` is used.\n- `PLHexpiryDate` is later than the current date/time (picklist not expired).\n- `ReservedOrderNr` is `NULL` or `0` (picklist is not reserved for an order).\n- `PLcomment` is not `DirectInvStockRelease`.\n- `ExecutionFinished = 1` (picklist generation has finished).\n\n**Calculated columns**\n- `FromBinName` / `ToBinName`: name of the Lagerplatz with the lowest / highest `BinSortNum` among the bins referenced by the picklist items (`PLitem.pliBinRef`). Empty string if the picklist has no items.\n- `HALcount`: number of Orderlines of `ReservedOrderNr` with status `HAL`.\n- `Item number`: number of distinct item/bin combinations on the picklist (items are counted once per Lagerplatz). `0` if the picklist has no items.\n- `ReservedOrderNr`, `IsReservationFull` and `PLHOriginalKey` are returned as `0` / `false` instead of `NULL`.\n\nThe result has no explicit sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | No | Location (Lager) ID whose picklists are returned. Empty or omitted means `001`. |\n\n- All tables are read with `NOLOCK`; uncommitted data may appear.\n- Because only unreserved picklists are returned (`ReservedOrderNr` is `NULL`/`0`), `HALcount` is in practice always `0` (it would only count lines of an order with number `0`).\n- Picklists with `PLcomment = NULL` are excluded as well, because the comparison `<> 'DirectInvStockRelease'` is not true for `NULL`.\n- The column `Item number` contains a space; in the .NET DataSet XML of the SOAP response it typically appears as element `Item_x0020_number`.\n- Only items whose `InvBinItem` and `Items` records exist are counted in `Item number`; `FromBinName`/`ToBinName` only consider items whose bin exists in `InvBin`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the headers of all valid, unreserved and fully executed picklists of a location, with first/last bin and item count.\n\nReturns one row per picklist header from `PLHeader` that is currently usable for picking.\n\n**Filter**\n- `PLHlocID` equals `@LocID`. If `LocID` is empty or omitted, location `001` is used.\n- `PLHexpiryDate` is later than the current date/time (picklist not expired).\n- `ReservedOrderNr` is `NULL` or `0` (picklist is not reserved for an order).\n- `PLcomment` is not `DirectInvStockRelease`.\n- `ExecutionFinished = 1` (picklist generation has finished).\n\n**Calculated columns**\n- `FromBinName` / `ToBinName`: name of the Lagerplatz with the lowest / highest `BinSortNum` among the bins referenced by the picklist items (`PLitem.pliBinRef`). Empty string if the picklist has no items.\n- `HALcount`: number of Orderlines of `ReservedOrderNr` with status `HAL`.\n- `Item number`: number of distinct item/bin combinations on the picklist (items are counted once per Lagerplatz). `0` if the picklist has no items.\n- `ReservedOrderNr`, `IsReservationFull` and `PLHOriginalKey` are returned as `0` / `false` instead of `NULL`.\n\nThe result has no explicit sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | No | Location (Lager) ID whose picklists are returned. Empty or omitted means `001`. |\n\n- All tables are read with `NOLOCK`; uncommitted data may appear.\n- Because only unreserved picklists are returned (`ReservedOrderNr` is `NULL`/`0`), `HALcount` is in practice always `0` (it would only count lines of an order with number `0`).\n- Picklists with `PLcomment = NULL` are excluded as well, because the comparison `<> 'DirectInvStockRelease'` is not true for `NULL`.\n- The column `Item number` contains a space; in the .NET DataSet XML of the SOAP response it typically appears as element `Item_x0020_number`.\n- Only items whose `InvBinItem` and `Items` records exist are counted in `Item number`; `FromBinName`/`ToBinName` only consider items whose bin exists in `InvBin`.\n\nDocumentation: https://pixi-api-docs.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": "Updates tracking IDs, label URLs and provider messages of an invoice package and writes the tracking IDs to the related invoice.\n\nWrites the result of a shipping provider (tracking number, label URLs, provider messages) to a package of an invoice (`pixi.InvoicePackage`) and to the invoice itself (`dbo.Invoices`).\n\nSteps:\n\n1. All string parameters that are passed as empty strings are treated as `NULL` (= not supplied).\n2. The package `PackageId` must exist, otherwise a `400` response is returned.\n3. If `InvoiceKey` is supplied, it must match the invoice of the package, otherwise a `400` response is returned. If it is omitted, the invoice of the package is used.\n4. **Package update:** `TrackingID`, `ReturnTrackingId`, `ExternalShipmentId`, `MessageFromProvider` and `MessageFromProviderDetail` are overwritten only with supplied values; omitted values keep the stored data. `ShippingLabelUrl` and `ReturnLabelUrl` take the new value or keep the current one. For packages of a shipping vendor with external label functionality (functionality version 3) that were shipped via a toolbox station, `ShippingLabelUrl` is set to `NO URL FROM PROVIDER` if no URL exists at all. `RecordModifiedOn` and `RecordModifiedByUserId` (user `API`) are set.\n5. **Invoice update:**\n - `ShipmentTrackingID`: if empty, it is set to `TrackingId`; otherwise `TrackingId` is appended with `;` unless the existing value already contains it.\n - `retTrackID` / `retTrackIDhist`: if `retTrackID` is empty, `retTrackID` becomes `ReturnTrackingId` and the history is set to `ReturnTrackingId;`. Otherwise, if the new ID is not yet contained in `retTrackID`, it is appended to the history and `retTrackID` is replaced.\n - `UpdateDate` and `UpdateEmp` (`TrackingID API Import`) are set.\n6. If `ResetClientNotifiedFlag` = 1, the latest `AUS` (shipped) order history entry of every order line on the invoice is reset to `ClientNotified = 'N'`, so the order is exported again with the tracking ID.\n7. A row with `Response` = `200 OK` is returned and the transaction is committed.\n8. After the commit, MQ events are published: `PackageLabelSaved` (only for external label packages shipped via toolbox station, with flags whether the shipping or return label URL changed) and always `InvoiceChanged` with parameter `SetTrackingId`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PackageId` | int | Yes | ID of the invoice package (`pixi.InvoicePackage.Id`) to update. |\n| `InvoiceKey` | int | No | Optional invoice key for validation. If supplied, it must match the invoice of the package; if omitted, the invoice of the package is used. |\n| `ShippingLabelUrl` | varchar(8000) | No | URL of the shipping label. Empty or omitted keeps the current URL. |\n| `TrackingId` | varchar(512) | No | Tracking number of the shipment. Overwrites the package tracking ID and is appended to `Invoices.ShipmentTrackingID` if not yet contained. |\n| `ReturnLabelUrl` | varchar(8000) | No | URL of the return label. Empty or omitted keeps the current URL. |\n| `ReturnTrackingId` | varchar(512) | No | Tracking number of the return label. Written to the package and to `Invoices.retTrackID` / `retTrackIDhist`. |\n| `ExternalShipmentId` | varchar(512) | No | Shipment ID at the shipping provider. Only overwritten if supplied. |\n| `MessageFromProvider` | varchar(max) | No | Message returned by the shipping provider. Only overwritten if supplied. |\n| `MessageFromProviderDetail` | varchar(max) | No | Detailed message of the shipping provider. Only overwritten if supplied. |\n| `ResetClientNotifiedFlag` | bit | No | If 1, the latest `AUS` order history entries of the invoice's order lines are set to `ClientNotified = 'N'` so the shipment is exported again with the tracking ID. |\n\n- Runs in its own transaction (or a savepoint if a transaction is already open). An exclusive application lock `PixiInvoicePackage` (timeout 30 s) serializes the call with other package updates; if the lock cannot be acquired the update still runs.\n- Deadlocks (error 1205) are retried up to 5 times with a 5 ms delay. Other errors are logged via `log.InsertError` and answered with `500 Internal Server Error`. In rare error situations after the `200 OK` row (e.g. during commit or event publishing), the caller may receive more than one `Response` result set.\n- The duplicate check for tracking IDs is a substring `LIKE` test: an ID that is part of an existing ID (e.g. `123` in `12345`) is not appended to the invoice, and `%` or `_` in IDs act as wildcards.\n- `InvoicePackage.TrackingID` is overwritten, whereas `Invoices.ShipmentTrackingID` collects all IDs separated by `;`.\n- If the invoice has no return tracking ID yet, `retTrackIDhist` is replaced (not appended) by the new ID.\n- `CONTEXT_INFO` is set to `0x11111` during the invoice update, presumably to influence triggers on `dbo.Invoices`.\n- Lookups use `NOLOCK`.\n- MQ events are only sent if the setting `pixiMQ_Enabled` is active and the events are configured and enabled in `EventConfiguration`.\n\nDocumentation: https://pixi-api-docs.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": "Updates tracking IDs, label URLs and provider messages of an invoice package and writes the tracking IDs to the related invoice.\n\nWrites the result of a shipping provider (tracking number, label URLs, provider messages) to a package of an invoice (`pixi.InvoicePackage`) and to the invoice itself (`dbo.Invoices`).\n\nSteps:\n\n1. All string parameters that are passed as empty strings are treated as `NULL` (= not supplied).\n2. The package `PackageId` must exist, otherwise a `400` response is returned.\n3. If `InvoiceKey` is supplied, it must match the invoice of the package, otherwise a `400` response is returned. If it is omitted, the invoice of the package is used.\n4. **Package update:** `TrackingID`, `ReturnTrackingId`, `ExternalShipmentId`, `MessageFromProvider` and `MessageFromProviderDetail` are overwritten only with supplied values; omitted values keep the stored data. `ShippingLabelUrl` and `ReturnLabelUrl` take the new value or keep the current one. For packages of a shipping vendor with external label functionality (functionality version 3) that were shipped via a toolbox station, `ShippingLabelUrl` is set to `NO URL FROM PROVIDER` if no URL exists at all. `RecordModifiedOn` and `RecordModifiedByUserId` (user `API`) are set.\n5. **Invoice update:**\n - `ShipmentTrackingID`: if empty, it is set to `TrackingId`; otherwise `TrackingId` is appended with `;` unless the existing value already contains it.\n - `retTrackID` / `retTrackIDhist`: if `retTrackID` is empty, `retTrackID` becomes `ReturnTrackingId` and the history is set to `ReturnTrackingId;`. Otherwise, if the new ID is not yet contained in `retTrackID`, it is appended to the history and `retTrackID` is replaced.\n - `UpdateDate` and `UpdateEmp` (`TrackingID API Import`) are set.\n6. If `ResetClientNotifiedFlag` = 1, the latest `AUS` (shipped) order history entry of every order line on the invoice is reset to `ClientNotified = 'N'`, so the order is exported again with the tracking ID.\n7. A row with `Response` = `200 OK` is returned and the transaction is committed.\n8. After the commit, MQ events are published: `PackageLabelSaved` (only for external label packages shipped via toolbox station, with flags whether the shipping or return label URL changed) and always `InvoiceChanged` with parameter `SetTrackingId`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PackageId` | int | Yes | ID of the invoice package (`pixi.InvoicePackage.Id`) to update. |\n| `InvoiceKey` | int | No | Optional invoice key for validation. If supplied, it must match the invoice of the package; if omitted, the invoice of the package is used. |\n| `ShippingLabelUrl` | varchar(8000) | No | URL of the shipping label. Empty or omitted keeps the current URL. |\n| `TrackingId` | varchar(512) | No | Tracking number of the shipment. Overwrites the package tracking ID and is appended to `Invoices.ShipmentTrackingID` if not yet contained. |\n| `ReturnLabelUrl` | varchar(8000) | No | URL of the return label. Empty or omitted keeps the current URL. |\n| `ReturnTrackingId` | varchar(512) | No | Tracking number of the return label. Written to the package and to `Invoices.retTrackID` / `retTrackIDhist`. |\n| `ExternalShipmentId` | varchar(512) | No | Shipment ID at the shipping provider. Only overwritten if supplied. |\n| `MessageFromProvider` | varchar(max) | No | Message returned by the shipping provider. Only overwritten if supplied. |\n| `MessageFromProviderDetail` | varchar(max) | No | Detailed message of the shipping provider. Only overwritten if supplied. |\n| `ResetClientNotifiedFlag` | bit | No | If 1, the latest `AUS` order history entries of the invoice's order lines are set to `ClientNotified = 'N'` so the shipment is exported again with the tracking ID. |\n\n- Runs in its own transaction (or a savepoint if a transaction is already open). An exclusive application lock `PixiInvoicePackage` (timeout 30 s) serializes the call with other package updates; if the lock cannot be acquired the update still runs.\n- Deadlocks (error 1205) are retried up to 5 times with a 5 ms delay. Other errors are logged via `log.InsertError` and answered with `500 Internal Server Error`. In rare error situations after the `200 OK` row (e.g. during commit or event publishing), the caller may receive more than one `Response` result set.\n- The duplicate check for tracking IDs is a substring `LIKE` test: an ID that is part of an existing ID (e.g. `123` in `12345`) is not appended to the invoice, and `%` or `_` in IDs act as wildcards.\n- `InvoicePackage.TrackingID` is overwritten, whereas `Invoices.ShipmentTrackingID` collects all IDs separated by `;`.\n- If the invoice has no return tracking ID yet, `retTrackIDhist` is replaced (not appended) by the new ID.\n- `CONTEXT_INFO` is set to `0x11111` during the invoice update, presumably to influence triggers on `dbo.Invoices`.\n- Lookups use `NOLOCK`.\n- MQ events are only sent if the setting `pixiMQ_Enabled` is active and the events are configured and enabled in `EventConfiguration`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the peak number of concurrent licensed users (CULs) per hour or per day since a start date, broken down by Pixi client application.\n\nEvaluates the session snapshots in `UsersLoggedIn` and returns how many licence-relevant users were logged in concurrently.\n\n**Period**\n- If `StartDate` is empty, it is set to the earliest `Tag` of all desktop/web sessions (`UserActiveSessionTypeId` 1 or 2).\n- A calendar grid is built from today back to `StartDate`: one row per day and hour 0–23 if `Hourly` = 1, or one row per day (hour 0) if `Hourly` = 0.\n\n**Which sessions count**\n- Session type 1 (desktop) or 2 (web) with `Tag` later than `StartDate`.\n- The application (`AppName`) must be registered in `ExeClientVersion` with `LicenceNeeded` = 1, and the licence manager for its session type must be enabled: setting `pixiLicencesManager` for desktop clients, `pixiLicencesManagerWeb` for the web client.\n- Computers listed in `MasterUsers` and the Pixi user `master` are excluded.\n\n**Calculation**\n1. Sessions are counted per snapshot (`Tag`); one session per `Tag`/`SessionId`/Pixi user.\n2. Per hour, the maximum snapshot count is taken as `CULs`.\n3. Per day, the highest hourly value is stored as `CULsPerDay` on the hour in which it was first reached.\n4. Days without any usage get a row with `CULs` = 0 and `CULsPerDay` = 0.\n5. The per-application columns count the sessions of the peak snapshot of the hour, mapped by executable name (e.g. `PPOS2.exe` → `POS`, `pixi.Presentation.Web` → `Web`).\n\n**Output**\n- `Hourly` = 1: one row per day and hour; `CULsPerDay` is filled only in the peak hour of the day, otherwise `NULL`.\n- `Hourly` = 0: one row per day with the daily peak in `CULs` and `CULsPerDay`; `Hour` is always 0.\n- Sorted by `Date` ascending, then by the hour of the usage data.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | No | Start of the evaluation period. Only sessions with a later `Tag` are counted. If empty, the earliest session snapshot in `UsersLoggedIn` is used. |\n| `Hourly` | bit | No | Selects hourly or daily output. |\n\n- Read-only; all tables are read `WITH (NOLOCK)`, so results may include uncommitted data.\n- If neither `pixiLicencesManager` nor `pixiLicencesManagerWeb` is `1`, no sessions qualify and all values are 0.\n- If `UsersLoggedIn` contains no qualifying sessions and no `StartDate` is passed, the period cannot be determined and the result is empty.\n- The filter `Tag > StartDate` is strict: with the default start date, the very first snapshot is not counted.\n- `Date` is derived from the current date and time, so it carries the current time of day, not midnight.\n- The secondary sort uses the hour of the usage data, which is `NULL` for hours without usage; within a day these rows come first in undefined order. Sort by `Hour` on the client if needed.\n- The per-application columns do not necessarily add up to `CULs`: sessions of `Repairs.exe` and of applications not in the internal mapping are counted in `CULs` but have no own column.\n- The calendar grid relies on the helper table `Numbers`; it must contain at least as many rows as days in the period.\n- For long periods with hourly output the result can become large (24 rows per day).\n\nDocumentation: https://pixi-api-docs.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": "Returns the peak number of concurrent licensed users (CULs) per hour or per day since a start date, broken down by Pixi client application.\n\nEvaluates the session snapshots in `UsersLoggedIn` and returns how many licence-relevant users were logged in concurrently.\n\n**Period**\n- If `StartDate` is empty, it is set to the earliest `Tag` of all desktop/web sessions (`UserActiveSessionTypeId` 1 or 2).\n- A calendar grid is built from today back to `StartDate`: one row per day and hour 0–23 if `Hourly` = 1, or one row per day (hour 0) if `Hourly` = 0.\n\n**Which sessions count**\n- Session type 1 (desktop) or 2 (web) with `Tag` later than `StartDate`.\n- The application (`AppName`) must be registered in `ExeClientVersion` with `LicenceNeeded` = 1, and the licence manager for its session type must be enabled: setting `pixiLicencesManager` for desktop clients, `pixiLicencesManagerWeb` for the web client.\n- Computers listed in `MasterUsers` and the Pixi user `master` are excluded.\n\n**Calculation**\n1. Sessions are counted per snapshot (`Tag`); one session per `Tag`/`SessionId`/Pixi user.\n2. Per hour, the maximum snapshot count is taken as `CULs`.\n3. Per day, the highest hourly value is stored as `CULsPerDay` on the hour in which it was first reached.\n4. Days without any usage get a row with `CULs` = 0 and `CULsPerDay` = 0.\n5. The per-application columns count the sessions of the peak snapshot of the hour, mapped by executable name (e.g. `PPOS2.exe` → `POS`, `pixi.Presentation.Web` → `Web`).\n\n**Output**\n- `Hourly` = 1: one row per day and hour; `CULsPerDay` is filled only in the peak hour of the day, otherwise `NULL`.\n- `Hourly` = 0: one row per day with the daily peak in `CULs` and `CULsPerDay`; `Hour` is always 0.\n- Sorted by `Date` ascending, then by the hour of the usage data.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `StartDate` | datetime | No | Start of the evaluation period. Only sessions with a later `Tag` are counted. If empty, the earliest session snapshot in `UsersLoggedIn` is used. |\n| `Hourly` | bit | No | Selects hourly or daily output. |\n\n- Read-only; all tables are read `WITH (NOLOCK)`, so results may include uncommitted data.\n- If neither `pixiLicencesManager` nor `pixiLicencesManagerWeb` is `1`, no sessions qualify and all values are 0.\n- If `UsersLoggedIn` contains no qualifying sessions and no `StartDate` is passed, the period cannot be determined and the result is empty.\n- The filter `Tag > StartDate` is strict: with the default start date, the very first snapshot is not counted.\n- `Date` is derived from the current date and time, so it carries the current time of day, not midnight.\n- The secondary sort uses the hour of the usage data, which is `NULL` for hours without usage; within a day these rows come first in undefined order. Sort by `Hour` on the client if needed.\n- The per-application columns do not necessarily add up to `CULs`: sessions of `Repairs.exe` and of applications not in the internal mapping are counted in `CULs` but have no own column.\n- The calendar grid relies on the helper table `Numbers`; it must contain at least as many rows as days in the period.\n- For long periods with hourly output the result can become large (24 rows per day).\n\nDocumentation: https://pixi-api-docs.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": "Returns a monthly federal statistics (Intrastat-style) report of delivered supplier items, grouped by supplier country, customs tariff number and country of origin.\n\nBuilds a report of goods received from suppliers for the federal foreign-trade statistics.\n\n**Time span**\n- If `DateFrom` is omitted, it defaults to the first day of the previous calendar month.\n- If `DateTo` is omitted, it defaults to the last day of the previous calendar month.\n- `DateFrom` is moved to the start of its day (00:00:00) and `DateTo` to the end of its day (23:59:59.997), so only the date part matters.\n- If `DateTo` is not after `DateFrom`, or the span covers more than 24 months, an error row is returned instead of the report.\n\n**Selection**\n- Supplier deliveries (`SDelHeader`) with status `INV` (invoiced) or `CLS` (closed).\n- The delivery header's last update date (`SDelHUpdateDate`) must lie within the time span.\n- Only delivery lines with a delivered quantity greater than 0.\n- Optional filter on the supplier number `SupplNR`; it is trimmed, and an empty value means all suppliers.\n\n**Aggregation**\nRows are grouped by year and month of the update date, the supplier country (ISO2 code, `N/A` if the supplier has no known country), the Artikel's customs country of origin, customs tariff number, customs tariff text (falls back to the Artikel name if empty) and the supplier's home page URL. For each group the call returns the summed weight (Artikel weight × delivered quantity, cast to `int`), the summed delivered quantity and the summed amount (delivered quantity × final supplier price, as `money`).\n\nThe result is sorted by year, month and supplier country.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | No | Start of the period (date part only, start of day). Default: first day of the previous month. |\n| `DateTo` | datetime | No | End of the period (date part only, end of day). Default: last day of the previous month. Must be after `DateFrom`; the span may not exceed 24 months. |\n| `SupplNR` | varchar(4) | No | Optional supplier number to restrict the report. Trimmed; empty or NULL means all suppliers. |\n\n- All tables are read `WITH (NOLOCK)`; results may include uncommitted data.\n- Errors (including the parameter checks) are caught and returned as a row with `Status` = `Error` and `Message`, not as a SOAP fault.\n- The period is based on `SDelHUpdateDate` (last change of the delivery header), not on a separate receipt date. A later change to an old delivery moves it into a later period.\n- If only `DateFrom` is passed, `DateTo` still defaults to the end of the previous month; a `DateFrom` in the current month therefore leads to the error about `DateTo` being smaller.\n- The 24-month check uses `DATEDIFF(MONTH, ...)`, which counts month boundaries, not full months.\n- The supplier number is not part of the grouping, but `HomePageUrl` is: several suppliers from the same country with different home page URLs produce separate rows.\n- Artikel without weight (`NULL`) do not contribute to `DeliveredWeight`. The weight is truncated to an integer after summing.\n- The helper `util.TempTableDrop` used to drop the temporary table is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Returns a monthly federal statistics (Intrastat-style) report of delivered supplier items, grouped by supplier country, customs tariff number and country of origin.\n\nBuilds a report of goods received from suppliers for the federal foreign-trade statistics.\n\n**Time span**\n- If `DateFrom` is omitted, it defaults to the first day of the previous calendar month.\n- If `DateTo` is omitted, it defaults to the last day of the previous calendar month.\n- `DateFrom` is moved to the start of its day (00:00:00) and `DateTo` to the end of its day (23:59:59.997), so only the date part matters.\n- If `DateTo` is not after `DateFrom`, or the span covers more than 24 months, an error row is returned instead of the report.\n\n**Selection**\n- Supplier deliveries (`SDelHeader`) with status `INV` (invoiced) or `CLS` (closed).\n- The delivery header's last update date (`SDelHUpdateDate`) must lie within the time span.\n- Only delivery lines with a delivered quantity greater than 0.\n- Optional filter on the supplier number `SupplNR`; it is trimmed, and an empty value means all suppliers.\n\n**Aggregation**\nRows are grouped by year and month of the update date, the supplier country (ISO2 code, `N/A` if the supplier has no known country), the Artikel's customs country of origin, customs tariff number, customs tariff text (falls back to the Artikel name if empty) and the supplier's home page URL. For each group the call returns the summed weight (Artikel weight × delivered quantity, cast to `int`), the summed delivered quantity and the summed amount (delivered quantity × final supplier price, as `money`).\n\nThe result is sorted by year, month and supplier country.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | No | Start of the period (date part only, start of day). Default: first day of the previous month. |\n| `DateTo` | datetime | No | End of the period (date part only, end of day). Default: last day of the previous month. Must be after `DateFrom`; the span may not exceed 24 months. |\n| `SupplNR` | varchar(4) | No | Optional supplier number to restrict the report. Trimmed; empty or NULL means all suppliers. |\n\n- All tables are read `WITH (NOLOCK)`; results may include uncommitted data.\n- Errors (including the parameter checks) are caught and returned as a row with `Status` = `Error` and `Message`, not as a SOAP fault.\n- The period is based on `SDelHUpdateDate` (last change of the delivery header), not on a separate receipt date. A later change to an old delivery moves it into a later period.\n- If only `DateFrom` is passed, `DateTo` still defaults to the end of the previous month; a `DateFrom` in the current month therefore leads to the error about `DateTo` being smaller.\n- The 24-month check uses `DATEDIFF(MONTH, ...)`, which counts month boundaries, not full months.\n- The supplier number is not part of the grouping, but `HomePageUrl` is: several suppliers from the same country with different home page URLs produce separate rows.\n- Artikel without weight (`NULL`) do not contribute to `DeliveredWeight`. The weight is truncated to an integer after summing.\n- The helper `util.TempTableDrop` used to drop the temporary table is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Returns, per day, the pixi* client applications that were open at the snapshot with the most connected users, or only the list of applications used.\n\nEvaluates the login snapshots stored in `UsersLoggedIn` to show which pixi* clients were in use when the licence usage peaked on each day.\n\n1. For every snapshot (`Tag`), the logged-in sessions are counted. Sessions whose `UserName` matches a `ComputerName` in `MasterUsers` and sessions whose `UserNameUsingPixi` is `master` are excluded.\n2. For each calendar day (date part of `Tag`), the snapshot with the highest session count is selected. On a tie, the latest snapshot of that day wins.\n3. For the selected snapshot of each day, the sessions are counted per application (`AppName`), using the same exclusions.\n4. The technical application names are translated into readable names via a fixed, built-in list (e.g. `BinClient_A.exe` → `Lager`, `ShippingClient_A.exe` → `Versand`, several web components → `Web pixi*`). Applications that are **not** in this list are dropped from the result.\n\nOutput depends on `ShowOnlyApplicationsused`:\n- `0` (default): one row per day and application with the session count, sorted by `Tag_Date` and `ApplicationFormatted`.\n- `1`: only the distinct list of applications (technical and readable name) that occurred in any daily peak snapshot, without a defined sort order.\n\nThere is no date filter; all snapshots in `UsersLoggedIn` are evaluated.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShowOnlyApplicationsused` | bit | No | Controls the output: `0` returns usage counts per day and application, `1` returns only the distinct list of applications used. |\n\n- All reads on `UsersLoggedIn` and `MasterUsers` use `NOLOCK`, so results may include uncommitted data.\n- Sessions with `UserNameUsingPixi` = NULL are also excluded, because the comparison with `master` is not true for NULL.\n- Several technical names map to the same readable name (e.g. `PixiPOS.exe` and `PPOS2.exe` → `POS`; four web components → `Web pixi*`). In mode `0` this can produce several rows with the same `ApplicationFormatted` on one day; group by `ApplicationFormatted` on the client if a combined figure is needed.\n- Whether `AppName` matches the translation list case-insensitively depends on the database collation.\n- Since the whole history of `UsersLoggedIn` is processed, the call can be slow on large tables.\n- Temporary tables are cleaned up via `util.TempTableDrop` (definition not attached).\n\nDocumentation: https://pixi-api-docs.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": "Returns, per day, the pixi* client applications that were open at the snapshot with the most connected users, or only the list of applications used.\n\nEvaluates the login snapshots stored in `UsersLoggedIn` to show which pixi* clients were in use when the licence usage peaked on each day.\n\n1. For every snapshot (`Tag`), the logged-in sessions are counted. Sessions whose `UserName` matches a `ComputerName` in `MasterUsers` and sessions whose `UserNameUsingPixi` is `master` are excluded.\n2. For each calendar day (date part of `Tag`), the snapshot with the highest session count is selected. On a tie, the latest snapshot of that day wins.\n3. For the selected snapshot of each day, the sessions are counted per application (`AppName`), using the same exclusions.\n4. The technical application names are translated into readable names via a fixed, built-in list (e.g. `BinClient_A.exe` → `Lager`, `ShippingClient_A.exe` → `Versand`, several web components → `Web pixi*`). Applications that are **not** in this list are dropped from the result.\n\nOutput depends on `ShowOnlyApplicationsused`:\n- `0` (default): one row per day and application with the session count, sorted by `Tag_Date` and `ApplicationFormatted`.\n- `1`: only the distinct list of applications (technical and readable name) that occurred in any daily peak snapshot, without a defined sort order.\n\nThere is no date filter; all snapshots in `UsersLoggedIn` are evaluated.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ShowOnlyApplicationsused` | bit | No | Controls the output: `0` returns usage counts per day and application, `1` returns only the distinct list of applications used. |\n\n- All reads on `UsersLoggedIn` and `MasterUsers` use `NOLOCK`, so results may include uncommitted data.\n- Sessions with `UserNameUsingPixi` = NULL are also excluded, because the comparison with `master` is not true for NULL.\n- Several technical names map to the same readable name (e.g. `PixiPOS.exe` and `PPOS2.exe` → `POS`; four web components → `Web pixi*`). In mode `0` this can produce several rows with the same `ApplicationFormatted` on one day; group by `ApplicationFormatted` on the client if a combined figure is needed.\n- Whether `AppName` matches the translation list case-insensitively depends on the database collation.\n- Since the whole history of `UsersLoggedIn` is processed, the call can be slow on large tables.\n- Temporary tables are cleaned up via `util.TempTableDrop` (definition not attached).\n\nDocumentation: https://pixi-api-docs.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": "Returns sales statistics for one item: quantities sold in the last 30/120/365 days, open and held quantities, open single-item orders and the ABC class.\n\nReturns one row of sales figures for a single item.\n\n1. **Item lookup**: the item is identified by `EANUPC` **or** `ItemNrInt`. The first item (lowest `ItemKey`) whose EAN matches `@EANUPC` or whose internal item number matches `@ItemNrInt` is used.\n2. **Open single-item orders (`Open1SS`)**: counts all orders that contain at least one order line of this item with status `ANG` and whose order lines (all lines of the order, any status) add up to a total quantity of exactly 1.\n3. **Sales buckets**: all order lines of the item with an order date within the last 365 days (relative to the current date and time) are considered, except lines with status `STO` or `NLB`.\n - `Sales30`: quantity ordered in the last 30 days\n - `Sales120`: quantity ordered in the last 120 days (includes the 30-day range)\n - `Sales365`: quantity ordered in the last 365 days\n - `OrderQtyANG`: quantity of lines with status `ANG` within the last 365 days\n - `OrderQtyHAL`: quantity of lines with status `HAL` within the last 365 days\n4. **ABC class**: determined by the item tags `A`, `B` or `C` (checked in this order); empty string if none of these tags is assigned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `EANUPC` | varchar(13) | No | EAN/UPC of the item. Alternative to `ItemNrInt`. |\n| `ItemNrInt` | varchar(50) | No | Internal item number. Alternative to `EANUPC`. |\n\n- All reads use `NOLOCK`, so figures may include uncommitted data.\n- If both parameters are passed, they are combined with `OR`; the item with the lowest `ItemKey` matching either value is used. Pass only one identifier to avoid ambiguity.\n- If no item is found, no error is returned: `Open1SS` is `0`, `ABC` and all sales columns are `NULL`.\n- The sales columns are `NULL` (not `0`) when there are no matching order lines in the respective range.\n- The time ranges are computed from the current date **and time** (`GETDATE()` minus n days), not from midnight.\n- `Open1SS` sums the quantity of all lines of an order, including lines of other statuses (e.g. cancelled lines), when checking for a total of 1.\n\nDocumentation: https://pixi-api-docs.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": "Returns sales statistics for one item: quantities sold in the last 30/120/365 days, open and held quantities, open single-item orders and the ABC class.\n\nReturns one row of sales figures for a single item.\n\n1. **Item lookup**: the item is identified by `EANUPC` **or** `ItemNrInt`. The first item (lowest `ItemKey`) whose EAN matches `@EANUPC` or whose internal item number matches `@ItemNrInt` is used.\n2. **Open single-item orders (`Open1SS`)**: counts all orders that contain at least one order line of this item with status `ANG` and whose order lines (all lines of the order, any status) add up to a total quantity of exactly 1.\n3. **Sales buckets**: all order lines of the item with an order date within the last 365 days (relative to the current date and time) are considered, except lines with status `STO` or `NLB`.\n - `Sales30`: quantity ordered in the last 30 days\n - `Sales120`: quantity ordered in the last 120 days (includes the 30-day range)\n - `Sales365`: quantity ordered in the last 365 days\n - `OrderQtyANG`: quantity of lines with status `ANG` within the last 365 days\n - `OrderQtyHAL`: quantity of lines with status `HAL` within the last 365 days\n4. **ABC class**: determined by the item tags `A`, `B` or `C` (checked in this order); empty string if none of these tags is assigned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `EANUPC` | varchar(13) | No | EAN/UPC of the item. Alternative to `ItemNrInt`. |\n| `ItemNrInt` | varchar(50) | No | Internal item number. Alternative to `EANUPC`. |\n\n- All reads use `NOLOCK`, so figures may include uncommitted data.\n- If both parameters are passed, they are combined with `OR`; the item with the lowest `ItemKey` matching either value is used. Pass only one identifier to avoid ambiguity.\n- If no item is found, no error is returned: `Open1SS` is `0`, `ABC` and all sales columns are `NULL`.\n- The sales columns are `NULL` (not `0`) when there are no matching order lines in the respective range.\n- The time ranges are computed from the current date **and time** (`GETDATE()` minus n days), not from midnight.\n- `Open1SS` sums the quantity of all lines of an order, including lines of other statuses (e.g. cancelled lines), when checking for a total of 1.\n\nDocumentation: https://pixi-api-docs.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": "Assigns a set of boxes to a picklist, replacing the previous box assignment, after checking that all boxes exist and that there are enough for the orders.\n\nReplaces the box assignment of a picklist with the list of box numbers passed as XML.\n\n**Steps:**\n\n1. Reads the location (`PLHlocID`) of the picklist `@PicklistNr` from `PLHeader`. If `@PicklistNr` is NULL, <= 0 or the picklist does not exist, an error row is returned.\n2. Checks that `@BoxNumbers` is not NULL or empty.\n3. Parses `@BoxNumbers` as XML and reads all distinct `/BoxNumbers/BoxNr` values as integers. If no value other than `0` is found, an error row is returned.\n4. Looks up each box number in `boxes` **at the location of the picklist** (`LocationID` = picklist location). If any box number is not found there, an error row listing the missing numbers is returned and nothing is changed.\n5. Determines the number of distinct orders on the picklist (including picklists split from it via `PLHOriginalKey`). If the number of boxes sent is lower than the number of orders, an error row is returned.\n6. In a transaction:\n - deletes existing `PicklistBox` assignments of the picklist whose box is not in the new list,\n - inserts assignments for boxes in the list that are not yet assigned (created/modified by the user resolved from `@UserName`),\n - resets `PLHfromBox` and `PLHtoBox` of the picklist to `0`.\n7. Returns a row with `Status` = 1 and `Message` = `Success`.\n\nThe result is always a single `Status`/`Message` row; `Status` = 0 means validation failed and no data was changed.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PicklistNr` | int | Yes | Key of the picklist (`PLHkey`) to assign the boxes to. Must be > 0 and refer to an existing picklist. |\n| `BoxNumbers` | nvarchar(max) | Yes | XML document with the box numbers (`BoxNr` in `boxes`) to assign. Root element `BoxNumbers` with one `BoxNr` element per box. Duplicates are ignored. All boxes must exist at the location of the picklist, and their count must be at least the number of orders on the picklist. |\n| `UserName` | varchar(50) | No | Pixi user name stored as creator/modifier of new box assignments. Falls back to `pixiAdministration` if the user does not exist. |\n\n- The call is a full replacement: boxes currently assigned to the picklist but missing from `@BoxNumbers` are removed.\n- `@BoxNumbers` is converted to XML before the transaction and outside the error handling. Malformed XML or non-integer `BoxNr` values cause a SQL conversion error returned as `SqlMessage`.\n- A `BoxNr` of `0` is not ignored when other numbers are present; it is looked up like any other number and usually triggers the \"do not exist\" error.\n- The list of missing boxes in the error message is limited to 100 characters (`@ErrorDetails` is `varchar(100)`) and may be cut off.\n- In the \"not enough boxes\" message the needed count is cast to a `VARCHAR` without length (length 1), so only the first digit of the number of orders appears (e.g. `needed 1` for 12 orders).\n- If `@UserName` is not found in `UCS_USERS`, the user `pixiAdministration` is used.\n- If the call runs inside an existing transaction, a savepoint is used and no commit is done.\n- On a runtime error inside the transaction, the changes are rolled back and the error is logged via `log.InsertError`; in that case no `Status` row is returned.\n- Lookups on `PLHeader`, `PicklistBox` and `boxes` use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Assigns a set of boxes to a picklist, replacing the previous box assignment, after checking that all boxes exist and that there are enough for the orders.\n\nReplaces the box assignment of a picklist with the list of box numbers passed as XML.\n\n**Steps:**\n\n1. Reads the location (`PLHlocID`) of the picklist `@PicklistNr` from `PLHeader`. If `@PicklistNr` is NULL, <= 0 or the picklist does not exist, an error row is returned.\n2. Checks that `@BoxNumbers` is not NULL or empty.\n3. Parses `@BoxNumbers` as XML and reads all distinct `/BoxNumbers/BoxNr` values as integers. If no value other than `0` is found, an error row is returned.\n4. Looks up each box number in `boxes` **at the location of the picklist** (`LocationID` = picklist location). If any box number is not found there, an error row listing the missing numbers is returned and nothing is changed.\n5. Determines the number of distinct orders on the picklist (including picklists split from it via `PLHOriginalKey`). If the number of boxes sent is lower than the number of orders, an error row is returned.\n6. In a transaction:\n - deletes existing `PicklistBox` assignments of the picklist whose box is not in the new list,\n - inserts assignments for boxes in the list that are not yet assigned (created/modified by the user resolved from `@UserName`),\n - resets `PLHfromBox` and `PLHtoBox` of the picklist to `0`.\n7. Returns a row with `Status` = 1 and `Message` = `Success`.\n\nThe result is always a single `Status`/`Message` row; `Status` = 0 means validation failed and no data was changed.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PicklistNr` | int | Yes | Key of the picklist (`PLHkey`) to assign the boxes to. Must be > 0 and refer to an existing picklist. |\n| `BoxNumbers` | nvarchar(max) | Yes | XML document with the box numbers (`BoxNr` in `boxes`) to assign. Root element `BoxNumbers` with one `BoxNr` element per box. Duplicates are ignored. All boxes must exist at the location of the picklist, and their count must be at least the number of orders on the picklist. |\n| `UserName` | varchar(50) | No | Pixi user name stored as creator/modifier of new box assignments. Falls back to `pixiAdministration` if the user does not exist. |\n\n- The call is a full replacement: boxes currently assigned to the picklist but missing from `@BoxNumbers` are removed.\n- `@BoxNumbers` is converted to XML before the transaction and outside the error handling. Malformed XML or non-integer `BoxNr` values cause a SQL conversion error returned as `SqlMessage`.\n- A `BoxNr` of `0` is not ignored when other numbers are present; it is looked up like any other number and usually triggers the \"do not exist\" error.\n- The list of missing boxes in the error message is limited to 100 characters (`@ErrorDetails` is `varchar(100)`) and may be cut off.\n- In the \"not enough boxes\" message the needed count is cast to a `VARCHAR` without length (length 1), so only the first digit of the number of orders appears (e.g. `needed 1` for 12 orders).\n- If `@UserName` is not found in `UCS_USERS`, the user `pixiAdministration` is used.\n- If the call runs inside an existing transaction, a savepoint is used and no commit is done.\n- On a runtime error inside the transaction, the changes are rolled back and the error is logged via `log.InsertError`; in that case no `Status` row is returned.\n- Lookups on `PLHeader`, `PicklistBox` and `boxes` use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Creates one or more bins (Lagerplätze) from an XML list, validates each entry and returns a status row per bin.\n\nCreates new bins in the table `InvBin` from the XML passed in `BinsXML`. Each `/Bins/Bin` element describes one bin.\n\n**Input checks for the whole request**\n- If `BinsXML` is NULL or empty, or contains no `/Bins/Bin` element, a single status row `ERROR` / `XML contains no data.` is returned.\n- If the text cannot be converted to XML, `ERROR` / `Cannot parse XML` is returned.\n\n**Validation per bin** (a bin that fails a check gets `Status` = `ERROR` and is not inserted):\n1. Duplicates within the request: with setting `FilterStockOperationsWithLocation` = 0 the bin name must be unique in the request; with setting = 1 the combination name + location must be unique. Transport bins (`TransportBin` = 1) with the same name are always duplicates, regardless of location.\n2. `Name` must not be empty.\n3. `LocId` must not be empty.\n4. `SortNr` must be an integer ≥ 0 (mandatory).\n5. `MaxItems` must be an integer ≥ 0 (mandatory).\n6. Duplicates in the database: with setting = 0 no existing bin may have the same name in any location; with setting = 1 no existing bin may have the same name in the same location.\n7. The location `LocId` must exist in `Location`.\n\n**Insert**\nAll bins without error are inserted in one transaction into `InvBin` with `BinLocID`, `BinName`, `BinMaxItems`, `BinSortNum`, `BinGroup`, `TransportBin`; `CreateEmp`/`UpdateEmp` are set to `CreateEmp` (default `API`), `CreateDate`/`UpdateDate` to the current time. A missing `Group` is stored as empty string, a missing `TransportBin` as 0.\n\n**Response**\nOne row per `Bin` element, sorted by its position in the XML (`Row`). Successfully created bins have `Status` = `CREATED`, an empty `Message` and the new `BinKey` (looked up by name and location). Rejected bins have `Status` = `ERROR`, the reason in `Message` and `BinKey` = NULL.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BinsXML` | varchar(max) | Yes | XML list of bins to create. Root `Bins`, one `Bin` element per bin with the child elements `Name` (max. 50 chars, required), `LocId` (location ID, max. 3 chars, required), `Group` (bin group, max. 20 chars, optional), `SortNr` (integer ≥ 0, required), `MaxItems` (integer ≥ 0, required) and `TransportBin` (0/1, optional, default 0). |\n| `CreateEmp` | varchar(50) | No | User name stored as creator and last editor of the new bins. An empty value is replaced by `API`. |\n\n- The behaviour depends on the setting `FilterStockOperationsWithLocation` (read via `SettingGet`, default 0): with 0 bin names are unique system-wide, with 1 only per location.\n- Only one error message is kept per bin. An empty name overwrites a previously set duplicate message; later checks only run on rows that have no error yet.\n- Which of several duplicate entries in the request is accepted is not guaranteed to be the first in the XML, because the numbering within a duplicate group is ordered only by the bin name.\n- `SortNr` and `MaxItems` are parsed with `TRY_PARSE` (culture of the session language). A missing value already fails as `Datatype error`, so the messages `SortNr is empty.` / `MaxItems is empty.` are practically never returned. The `SortNr` and `MaxItems` columns of the response show the parsed input, so they are NULL for non-numeric values.\n- `TransportBin` is read directly as `bit`. A value that cannot be converted (e.g. `yes`) raises a SQL error outside the error handling and comes back as `SqlMessage`.\n- Existence checks against `InvBin` and `Location` use `NOLOCK`; parallel calls with the same bin names can therefore still create duplicates.\n- The insert runs in its own transaction (or a savepoint if a transaction is already open). On an unexpected error everything is rolled back, the error is logged via `log.InsertError` (not attached) and a single row `ERROR` with the SQL error text is returned.\n\nDocumentation: https://pixi-api-docs.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": "Creates one or more bins (Lagerplätze) from an XML list, validates each entry and returns a status row per bin.\n\nCreates new bins in the table `InvBin` from the XML passed in `BinsXML`. Each `/Bins/Bin` element describes one bin.\n\n**Input checks for the whole request**\n- If `BinsXML` is NULL or empty, or contains no `/Bins/Bin` element, a single status row `ERROR` / `XML contains no data.` is returned.\n- If the text cannot be converted to XML, `ERROR` / `Cannot parse XML` is returned.\n\n**Validation per bin** (a bin that fails a check gets `Status` = `ERROR` and is not inserted):\n1. Duplicates within the request: with setting `FilterStockOperationsWithLocation` = 0 the bin name must be unique in the request; with setting = 1 the combination name + location must be unique. Transport bins (`TransportBin` = 1) with the same name are always duplicates, regardless of location.\n2. `Name` must not be empty.\n3. `LocId` must not be empty.\n4. `SortNr` must be an integer ≥ 0 (mandatory).\n5. `MaxItems` must be an integer ≥ 0 (mandatory).\n6. Duplicates in the database: with setting = 0 no existing bin may have the same name in any location; with setting = 1 no existing bin may have the same name in the same location.\n7. The location `LocId` must exist in `Location`.\n\n**Insert**\nAll bins without error are inserted in one transaction into `InvBin` with `BinLocID`, `BinName`, `BinMaxItems`, `BinSortNum`, `BinGroup`, `TransportBin`; `CreateEmp`/`UpdateEmp` are set to `CreateEmp` (default `API`), `CreateDate`/`UpdateDate` to the current time. A missing `Group` is stored as empty string, a missing `TransportBin` as 0.\n\n**Response**\nOne row per `Bin` element, sorted by its position in the XML (`Row`). Successfully created bins have `Status` = `CREATED`, an empty `Message` and the new `BinKey` (looked up by name and location). Rejected bins have `Status` = `ERROR`, the reason in `Message` and `BinKey` = NULL.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BinsXML` | varchar(max) | Yes | XML list of bins to create. Root `Bins`, one `Bin` element per bin with the child elements `Name` (max. 50 chars, required), `LocId` (location ID, max. 3 chars, required), `Group` (bin group, max. 20 chars, optional), `SortNr` (integer ≥ 0, required), `MaxItems` (integer ≥ 0, required) and `TransportBin` (0/1, optional, default 0). |\n| `CreateEmp` | varchar(50) | No | User name stored as creator and last editor of the new bins. An empty value is replaced by `API`. |\n\n- The behaviour depends on the setting `FilterStockOperationsWithLocation` (read via `SettingGet`, default 0): with 0 bin names are unique system-wide, with 1 only per location.\n- Only one error message is kept per bin. An empty name overwrites a previously set duplicate message; later checks only run on rows that have no error yet.\n- Which of several duplicate entries in the request is accepted is not guaranteed to be the first in the XML, because the numbering within a duplicate group is ordered only by the bin name.\n- `SortNr` and `MaxItems` are parsed with `TRY_PARSE` (culture of the session language). A missing value already fails as `Datatype error`, so the messages `SortNr is empty.` / `MaxItems is empty.` are practically never returned. The `SortNr` and `MaxItems` columns of the response show the parsed input, so they are NULL for non-numeric values.\n- `TransportBin` is read directly as `bit`. A value that cannot be converted (e.g. `yes`) raises a SQL error outside the error handling and comes back as `SqlMessage`.\n- Existence checks against `InvBin` and `Location` use `NOLOCK`; parallel calls with the same bin names can therefore still create duplicates.\n- The insert runs in its own transaction (or a savepoint if a transaction is already open). On an unexpected error everything is rolled back, the error is logged via `log.InsertError` (not attached) and a single row `ERROR` with the SQL error text is returned.\n\nDocumentation: https://pixi-api-docs.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": "Updates one or more existing bins (Lagerplatz) from an XML list and returns a status row for each bin.\n\nUpdates existing bins in `InvBin`. Bins are identified by `BinKey`; new bins are not created.\n\n1. If `BinsXML` is empty or cannot be parsed as XML, a single `ERROR` row is returned and nothing is changed.\n2. Every `/Bins/Bin` element is read: `BinKey`, `Name`, `LocId`, `Group`, `SortNr`, `MaxItems`, `TransportBin`.\n3. Each bin is validated. A bin that fails a check gets `Status` = `ERROR` and a message, and is skipped. The first failing check wins. The checks are:\n - `BinKey` is missing or `0`.\n - `SortNr` or `MaxItems` is not an integer, or is negative.\n - `LocId` differs from the current location and the bin still has stock (`InvBinItem`).\n - The resulting name already exists on another bin:\n - on the same location, always checked;\n - on another location, only checked if the setting `FilterStockOperationsWithLocation` is `0`;\n - if `TransportBin` = 1 is sent, among all transport bins.\n - The given `LocId` does not exist in `Location`.\n - No bin with that `BinKey` exists.\n4. All valid bins are updated in one transaction. Elements that are left out keep their current value. The update sets `BinName`, `BinLocID`, `BinGroup`, `BinSortNum`, `BinMaxItems` and `TransportBin`, plus `UpdateEmp` and `UpdateDate`.\n5. One row per `Bin` element is returned, ordered by its position in the XML (`Row`). Each row has `Status` = `UPDATED` or `ERROR`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BinsXML` | varchar(max) | Yes | XML list of bins to update, root `Bins` with one `Bin` element per bin. `BinKey` is mandatory. `Name`, `LocId`, `Group`, `SortNr`, `MaxItems` and `TransportBin` are optional; omitted values are kept. |\n| `UpdateEmp` | varchar(50) | No | User name written to `InvBin.UpdateEmp`. An empty value is replaced by `API`. |\n\n- **Retaining values:** most elements are read via `text()`, so an empty element (e.g. ``) counts as omitted and the current value is kept. `Group` is read without `text()`: an empty `` sets the group to an empty string.\n- **Returned values:** the result rows contain the values as sent in the XML, not the merged values stored in `InvBin`. Omitted fields are returned as `NULL`.\n- **Transport bins:** the transport-bin duplicate check does not exclude the bin itself. Sending `TransportBin` = 1 for a bin that already is a transport bin therefore reports `Bin Name not updated (Duplicated).`.\n- **Duplicates within one request:** names are only checked against existing rows in `InvBin`, not against other `Bin` elements of the same request.\n- **Unchecked check:** the check `Bin not updated. Name is empty.` only applies to rows without `BinKey`. Such rows already fail the `BinKey` check, so this message does not occur in practice.\n- **Conversion errors:** a non-integer `BinKey` or an invalid `TransportBin` value (anything other than `0`, `1`, `true`, `false`) fails during XML reading. This happens before the `TRY` block and comes back as `SqlMessage`. `SortNr` and `MaxItems` are parsed with `TRY_PARSE` and produce status rows instead.\n- **Validation hints:** validation reads `InvBin`, `InvBinItem` and `Location` with `NOLOCK`.\n- **Transaction:** the update uses `ROWLOCK` inside its own transaction, or a savepoint if a transaction is already open.\n- **Unexpected errors:** the error is logged via `log.InsertError` (not attached), the transaction is rolled back and a row `Status` = `ERROR` is returned. Its `Message` contains `@@ERROR` after the logging call, so it is a number (typically `0`), not the error text.\n- **UpdateEmp:** an empty `UpdateEmp` is replaced by `API`.\n\nDocumentation: https://pixi-api-docs.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": "Updates one or more existing bins (Lagerplatz) from an XML list and returns a status row for each bin.\n\nUpdates existing bins in `InvBin`. Bins are identified by `BinKey`; new bins are not created.\n\n1. If `BinsXML` is empty or cannot be parsed as XML, a single `ERROR` row is returned and nothing is changed.\n2. Every `/Bins/Bin` element is read: `BinKey`, `Name`, `LocId`, `Group`, `SortNr`, `MaxItems`, `TransportBin`.\n3. Each bin is validated. A bin that fails a check gets `Status` = `ERROR` and a message, and is skipped. The first failing check wins. The checks are:\n - `BinKey` is missing or `0`.\n - `SortNr` or `MaxItems` is not an integer, or is negative.\n - `LocId` differs from the current location and the bin still has stock (`InvBinItem`).\n - The resulting name already exists on another bin:\n - on the same location, always checked;\n - on another location, only checked if the setting `FilterStockOperationsWithLocation` is `0`;\n - if `TransportBin` = 1 is sent, among all transport bins.\n - The given `LocId` does not exist in `Location`.\n - No bin with that `BinKey` exists.\n4. All valid bins are updated in one transaction. Elements that are left out keep their current value. The update sets `BinName`, `BinLocID`, `BinGroup`, `BinSortNum`, `BinMaxItems` and `TransportBin`, plus `UpdateEmp` and `UpdateDate`.\n5. One row per `Bin` element is returned, ordered by its position in the XML (`Row`). Each row has `Status` = `UPDATED` or `ERROR`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BinsXML` | varchar(max) | Yes | XML list of bins to update, root `Bins` with one `Bin` element per bin. `BinKey` is mandatory. `Name`, `LocId`, `Group`, `SortNr`, `MaxItems` and `TransportBin` are optional; omitted values are kept. |\n| `UpdateEmp` | varchar(50) | No | User name written to `InvBin.UpdateEmp`. An empty value is replaced by `API`. |\n\n- **Retaining values:** most elements are read via `text()`, so an empty element (e.g. ``) counts as omitted and the current value is kept. `Group` is read without `text()`: an empty `` sets the group to an empty string.\n- **Returned values:** the result rows contain the values as sent in the XML, not the merged values stored in `InvBin`. Omitted fields are returned as `NULL`.\n- **Transport bins:** the transport-bin duplicate check does not exclude the bin itself. Sending `TransportBin` = 1 for a bin that already is a transport bin therefore reports `Bin Name not updated (Duplicated).`.\n- **Duplicates within one request:** names are only checked against existing rows in `InvBin`, not against other `Bin` elements of the same request.\n- **Unchecked check:** the check `Bin not updated. Name is empty.` only applies to rows without `BinKey`. Such rows already fail the `BinKey` check, so this message does not occur in practice.\n- **Conversion errors:** a non-integer `BinKey` or an invalid `TransportBin` value (anything other than `0`, `1`, `true`, `false`) fails during XML reading. This happens before the `TRY` block and comes back as `SqlMessage`. `SortNr` and `MaxItems` are parsed with `TRY_PARSE` and produce status rows instead.\n- **Validation hints:** validation reads `InvBin`, `InvBinItem` and `Location` with `NOLOCK`.\n- **Transaction:** the update uses `ROWLOCK` inside its own transaction, or a savepoint if a transaction is already open.\n- **Unexpected errors:** the error is logged via `log.InsertError` (not attached), the transaction is rolled back and a row `Status` = `ERROR` is returned. Its `Message` contains `@@ERROR` after the logging call, so it is a number (typically `0`), not the error text.\n- **UpdateEmp:** an empty `UpdateEmp` is replaced by `API`.\n\nDocumentation: https://pixi-api-docs.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": "Returns aggregated stock movements from the bin item log for an external disposition software (LogControl), optionally summed up per item in inventory mode.\n\nExports stock movements from `InvBinItemLog` for an external disposition tool (LogControl).\n\n**Selection**\n- Only log entries with `IBILKEY` > `@ItemBinLogKeyStart`, `Qty` <> 0 and `UpdateDate` between `@DateStart` and `@DateEnd` (both inclusive). If `@DateStart` is NULL, `1900-01-01` is used; if `@DateEnd` is NULL, the current date and time is used.\n- Entries are grouped by update timestamp, `ForOrderline`, location, item, reason, update employee and stock movement type. Groups whose quantity sum is 0 are dropped.\n- The first `@RowCount` groups (default 10000), ordered by their lowest log key, are taken. The lowest log key of a group is returned as `ItemBinLogKey` and `PItemBinLogKey`.\n\n**Movement type code**\nA hard-coded type is derived per group:\n- `0300`: outflow (negative sum) not related to an order line\n- `2000`: outflow related to an order line (`ForOrderline` set and not 0)\n- `0200`: inflow booked by an employee whose name starts with the value of setting `DispoInventoryUser`\n- `1000`: all other movements\n\nIf setting `DispoExportAllImportTypes` is `1`, mode 0 returns the `Type` of the joined `StockMovementTypes` record instead.\n\n**Supplier order data**\nIf the reason contains `Picco Del.Nr. ` followed by a numeric delivery number and the movement has no order line, the procedure looks up the supplier delivery (`SDelHeader`/`SDelDetail`), its buying match and the related supplier order line. Order date, internal supplier order number and estimated delivery date are returned; if nothing is found, these columns contain `'0'`.\n\n**Output modes**\n- `@InventoryMode` = 0: one row per group, ordered by `ItemBinLogKey`, with the absolute quantity and the location.\n- `@InventoryMode` = 1: movements without order line are summed up per item (type `0300` for a negative total, otherwise `0200`); movements with order line are returned individually (type `2000` for outflow, `1000` for inflow). Both parts are combined with `UNION` and ordered by `Type`. This mode returns no `EstimatedDeliveryDate` and no `LocationID`.\n\nFor incremental export, pass the highest `ItemBinLogKey` of the previous call as `@ItemBinLogKeyStart`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemBinLogKeyStart` | int | Yes | Only log entries with a key greater than this value are exported. Pass 0 for a full export or the last exported `ItemBinLogKey` for an incremental export. |\n| `DateStart` | datetime | No | Earliest update timestamp (inclusive). NULL means 1900-01-01. |\n| `DateEnd` | datetime | No | Latest update timestamp (inclusive). NULL means the current date and time. |\n| `InventoryMode` | bit | No | Selects the output format: single movements or movements summed up per item. |\n| `RowCount` | int | No | Maximum number of grouped movements taken from the log. NULL means 10000. |\n\n- All reads use `NOLOCK`, so uncommitted data may be included.\n- `SET NOCOUNT` is intentionally not set; the intermediate `SELECT ... INTO` statements produce row-count messages.\n- `fpixi_GetSetting` returns `'0'` when a setting does not exist. If `DispoInventoryUser` is missing, the inventory user prefix becomes `'0'`, not NULL, so inflows by employees whose name starts with `0` are typed `0200`.\n- `@DateEnd` is compared with the full timestamp: a date like `20110820` means midnight, so movements later on that day are excluded.\n- `UpdateDate` is returned as text in format `dd.mm.yyyy`. In inventory mode, `MAX(UpdateDate)` compares these strings alphabetically, so the result is not necessarily the latest date.\n- In inventory mode, sums run across all locations of an item, `@RowCount` limits the underlying groups (not the output rows), and `UNION` removes identical rows. The column order differs from mode 0 (`SupplOrderNr` before `SupplOrderDate`) and the item column is named `ItemKey` instead of `ITemKey`.\n- The delivery number is taken from position 14 of `Reason`, which assumes the reason starts with `Picco Del.Nr. `.\n- An unused `LEFT JOIN` on `SDelHeader` via the part of `UpdateEmp` after `/` could multiply rows and inflate sums if several deliveries share that number.\n- Temporary tables are dropped via `util.TempTableDrop` (definition not attached).\n\nDocumentation: https://pixi-api-docs.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": "Returns aggregated stock movements from the bin item log for an external disposition software (LogControl), optionally summed up per item in inventory mode.\n\nExports stock movements from `InvBinItemLog` for an external disposition tool (LogControl).\n\n**Selection**\n- Only log entries with `IBILKEY` > `@ItemBinLogKeyStart`, `Qty` <> 0 and `UpdateDate` between `@DateStart` and `@DateEnd` (both inclusive). If `@DateStart` is NULL, `1900-01-01` is used; if `@DateEnd` is NULL, the current date and time is used.\n- Entries are grouped by update timestamp, `ForOrderline`, location, item, reason, update employee and stock movement type. Groups whose quantity sum is 0 are dropped.\n- The first `@RowCount` groups (default 10000), ordered by their lowest log key, are taken. The lowest log key of a group is returned as `ItemBinLogKey` and `PItemBinLogKey`.\n\n**Movement type code**\nA hard-coded type is derived per group:\n- `0300`: outflow (negative sum) not related to an order line\n- `2000`: outflow related to an order line (`ForOrderline` set and not 0)\n- `0200`: inflow booked by an employee whose name starts with the value of setting `DispoInventoryUser`\n- `1000`: all other movements\n\nIf setting `DispoExportAllImportTypes` is `1`, mode 0 returns the `Type` of the joined `StockMovementTypes` record instead.\n\n**Supplier order data**\nIf the reason contains `Picco Del.Nr. ` followed by a numeric delivery number and the movement has no order line, the procedure looks up the supplier delivery (`SDelHeader`/`SDelDetail`), its buying match and the related supplier order line. Order date, internal supplier order number and estimated delivery date are returned; if nothing is found, these columns contain `'0'`.\n\n**Output modes**\n- `@InventoryMode` = 0: one row per group, ordered by `ItemBinLogKey`, with the absolute quantity and the location.\n- `@InventoryMode` = 1: movements without order line are summed up per item (type `0300` for a negative total, otherwise `0200`); movements with order line are returned individually (type `2000` for outflow, `1000` for inflow). Both parts are combined with `UNION` and ordered by `Type`. This mode returns no `EstimatedDeliveryDate` and no `LocationID`.\n\nFor incremental export, pass the highest `ItemBinLogKey` of the previous call as `@ItemBinLogKeyStart`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemBinLogKeyStart` | int | Yes | Only log entries with a key greater than this value are exported. Pass 0 for a full export or the last exported `ItemBinLogKey` for an incremental export. |\n| `DateStart` | datetime | No | Earliest update timestamp (inclusive). NULL means 1900-01-01. |\n| `DateEnd` | datetime | No | Latest update timestamp (inclusive). NULL means the current date and time. |\n| `InventoryMode` | bit | No | Selects the output format: single movements or movements summed up per item. |\n| `RowCount` | int | No | Maximum number of grouped movements taken from the log. NULL means 10000. |\n\n- All reads use `NOLOCK`, so uncommitted data may be included.\n- `SET NOCOUNT` is intentionally not set; the intermediate `SELECT ... INTO` statements produce row-count messages.\n- `fpixi_GetSetting` returns `'0'` when a setting does not exist. If `DispoInventoryUser` is missing, the inventory user prefix becomes `'0'`, not NULL, so inflows by employees whose name starts with `0` are typed `0200`.\n- `@DateEnd` is compared with the full timestamp: a date like `20110820` means midnight, so movements later on that day are excluded.\n- `UpdateDate` is returned as text in format `dd.mm.yyyy`. In inventory mode, `MAX(UpdateDate)` compares these strings alphabetically, so the result is not necessarily the latest date.\n- In inventory mode, sums run across all locations of an item, `@RowCount` limits the underlying groups (not the output rows), and `UNION` removes identical rows. The column order differs from mode 0 (`SupplOrderNr` before `SupplOrderDate`) and the item column is named `ItemKey` instead of `ITemKey`.\n- The delivery number is taken from position 14 of `Reason`, which assumes the reason starts with `Picco Del.Nr. `.\n- An unused `LEFT JOIN` on `SDelHeader` via the part of `UpdateEmp` after `/` could multiply rows and inflate sums if several deliveries share that number.\n- Temporary tables are dropped via `util.TempTableDrop` (definition not attached).\n\nDocumentation: https://pixi-api-docs.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": "Returns all items with a positive exportable stock for one location or all locations, together with item numbers, EAN, name, manufacturer, prices and category.\n\nExports a stock list of all items whose calculated stock is greater than 0.\n\n**Location selection**\n- The Pixi setting `ExportStock_locations` is read first. An empty value means `ALL` and `0` means `001`.\n- If `Location` is not empty, it overrides the setting. Because the default of `Location` is `ALL`, the setting only applies if the caller sends an empty value or `NULL`.\n- `ALL` covers all locations. Any other value is treated as a single location ID (`LocID`).\n\n**Stock calculation**\n\nThe stock is calculated per item by the function `fPixi_GetStockForExport`:\n- **Normal items:** the sum of `BinItemQty` over all bins (`InvBin`) in locations that are not flagged as special stock (`SpecialStock <> 1`), restricted to the selected location unless `ALL` is used.\n- **Bundle items** (items referenced in `BundleItems`): `Items.Quantity` for `ALL`, otherwise `LocationQuantity` from `ItemLocationSpecific` for the selected non-special location.\n\n**Output**\n\nThe call reads all items from `Items` and left-joins `TontrArten` for the category text. Only rows with `Stock > 0` are returned. No item status filter and no sort order are applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Location` | varchar(3) | No | Location ID whose stock is exported, or `ALL` for all locations. An empty value or `NULL` falls back to the setting `ExportStock_locations`. |\n\n- The stock function is called with the fixed value `'N'` for its physical-stock flag. The function only subtracts open order quantities (status `ANG`, or `HAL` within the last `HalOrdersActiveDays` days) or reservations when this flag equals `'0'`. As a result, **no order or reservation quantities are deducted**, and the exported value is the physical bin stock.\n- The settings `StockExportUsePhysicalStock` and `OldStockExport` are read but not used. `ReservePrepaymentOrders`, `ShowLocationStockInItemSearch` and `HalOrdersActiveDays` are passed to the stock function but have no effect on the result, for the reason above. `HalOrdersActiveDays = 0` is replaced by 7.\n- All tables are read with `NOLOCK`, except `InvBinItem` inside the stock function, which is read without the hint.\n- The stock is calculated by a scalar function for every item in `Items`. On large item bases this can be slow.\n- If a location ID that does not exist is passed, the result is empty.\n- The join condition `TontrArt = ConfigType` does not name the tables. Which column belongs to `Items` and which to `TontrArten` cannot be determined from the code.\n- The header comment mentions XML input, but the procedure has no XML parameter.\n\nDocumentation: https://pixi-api-docs.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": "Returns all items with a positive exportable stock for one location or all locations, together with item numbers, EAN, name, manufacturer, prices and category.\n\nExports a stock list of all items whose calculated stock is greater than 0.\n\n**Location selection**\n- The Pixi setting `ExportStock_locations` is read first. An empty value means `ALL` and `0` means `001`.\n- If `Location` is not empty, it overrides the setting. Because the default of `Location` is `ALL`, the setting only applies if the caller sends an empty value or `NULL`.\n- `ALL` covers all locations. Any other value is treated as a single location ID (`LocID`).\n\n**Stock calculation**\n\nThe stock is calculated per item by the function `fPixi_GetStockForExport`:\n- **Normal items:** the sum of `BinItemQty` over all bins (`InvBin`) in locations that are not flagged as special stock (`SpecialStock <> 1`), restricted to the selected location unless `ALL` is used.\n- **Bundle items** (items referenced in `BundleItems`): `Items.Quantity` for `ALL`, otherwise `LocationQuantity` from `ItemLocationSpecific` for the selected non-special location.\n\n**Output**\n\nThe call reads all items from `Items` and left-joins `TontrArten` for the category text. Only rows with `Stock > 0` are returned. No item status filter and no sort order are applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Location` | varchar(3) | No | Location ID whose stock is exported, or `ALL` for all locations. An empty value or `NULL` falls back to the setting `ExportStock_locations`. |\n\n- The stock function is called with the fixed value `'N'` for its physical-stock flag. The function only subtracts open order quantities (status `ANG`, or `HAL` within the last `HalOrdersActiveDays` days) or reservations when this flag equals `'0'`. As a result, **no order or reservation quantities are deducted**, and the exported value is the physical bin stock.\n- The settings `StockExportUsePhysicalStock` and `OldStockExport` are read but not used. `ReservePrepaymentOrders`, `ShowLocationStockInItemSearch` and `HalOrdersActiveDays` are passed to the stock function but have no effect on the result, for the reason above. `HalOrdersActiveDays = 0` is replaced by 7.\n- All tables are read with `NOLOCK`, except `InvBinItem` inside the stock function, which is read without the hint.\n- The stock is calculated by a scalar function for every item in `Items`. On large item bases this can be slow.\n- If a location ID that does not exist is passed, the result is empty.\n- The join condition `TontrArt = ConfigType` does not name the tables. Which column belongs to `Items` and which to `TontrArten` cannot be determined from the code.\n- The header comment mentions XML input, but the procedure has no XML parameter.\n\nDocumentation: https://pixi-api-docs.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": "Returns all items changed since a given point in time with their available stock and the earliest expected delivery date from open supplier orders.\n\nReturns one row per item in `Items` whose `UpdateDate` is greater than or equal to `@Since`. This makes the call suitable for delta synchronisation of stock levels, for example to an online shop.\n\nFor each item the call calculates:\n\n- **`AvailableStock`**: the item quantity (`Items.Quantity`) minus open order quantities minus open reservations. Negative results are returned as `0`.\n - *Open orders* are computed by `fPIXI_OpenOrdersCountForItem_ForStockExport`. It sums `OrderLines.Qty` for lines with status `ANG` or `BES`, plus lines with status `HAL` whose order date is at most `HalOrdersActiveDays` days old.\n - *Open reservations* are the sum of `InvBinItem.BinItemQty` over pick list items whose pick list header has a `ReservedOrderNr` and an expiry date (`PLHexpiryDate`) in the future.\n- **`EstimatedDelivery`**: the earliest `EstimatedDeliveryDate` of supplier order lines for the item that still have an open quantity, meaning ordered minus delivered minus undelivered is greater than 0. Only supplier orders whose status has `IsOrderedConfirmed = 1` count; a code comment names these as ordered/confirmed. The value is `NULL` if there is no such line.\n\nThe call does not sort the rows and has no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | Yes | Lower bound for `Items.UpdateDate` (inclusive). Only items changed at or after this time are returned. |\n\n- All tables are read `WITH (NOLOCK)`, so results may include uncommitted data.\n- The HAL window comes from the setting `HalOrdersActiveDays`, read via `fPIXI_GetSetting` (not attached). If the setting is `0` or empty, 7 days are used.\n- Only changes to `Items.UpdateDate` select an item. The code does not show whether new orders, reservations or supplier orders update this column. Stock changes caused by those records may therefore not be reported.\n- If `@Since` is `NULL`, no rows are returned.\n- The calculation runs a scalar function and two subqueries per item. Use a recent `@Since` to keep the result small.\n\nDocumentation: https://pixi-api-docs.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": "Returns all items changed since a given point in time with their available stock and the earliest expected delivery date from open supplier orders.\n\nReturns one row per item in `Items` whose `UpdateDate` is greater than or equal to `@Since`. This makes the call suitable for delta synchronisation of stock levels, for example to an online shop.\n\nFor each item the call calculates:\n\n- **`AvailableStock`**: the item quantity (`Items.Quantity`) minus open order quantities minus open reservations. Negative results are returned as `0`.\n - *Open orders* are computed by `fPIXI_OpenOrdersCountForItem_ForStockExport`. It sums `OrderLines.Qty` for lines with status `ANG` or `BES`, plus lines with status `HAL` whose order date is at most `HalOrdersActiveDays` days old.\n - *Open reservations* are the sum of `InvBinItem.BinItemQty` over pick list items whose pick list header has a `ReservedOrderNr` and an expiry date (`PLHexpiryDate`) in the future.\n- **`EstimatedDelivery`**: the earliest `EstimatedDeliveryDate` of supplier order lines for the item that still have an open quantity, meaning ordered minus delivered minus undelivered is greater than 0. Only supplier orders whose status has `IsOrderedConfirmed = 1` count; a code comment names these as ordered/confirmed. The value is `NULL` if there is no such line.\n\nThe call does not sort the rows and has no paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | Yes | Lower bound for `Items.UpdateDate` (inclusive). Only items changed at or after this time are returned. |\n\n- All tables are read `WITH (NOLOCK)`, so results may include uncommitted data.\n- The HAL window comes from the setting `HalOrdersActiveDays`, read via `fPIXI_GetSetting` (not attached). If the setting is `0` or empty, 7 days are used.\n- Only changes to `Items.UpdateDate` select an item. The code does not show whether new orders, reservations or supplier orders update this column. Stock changes caused by those records may therefore not be reported.\n- If `@Since` is `NULL`, no rows are returned.\n- The calculation runs a scalar function and two subqueries per item. Use a recent `@Since` to keep the result small.\n\nDocumentation: https://pixi-api-docs.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": "Returns items whose stock changed in a time window, with physical and available stock, open supplier order quantity and reorder level, paged.\n\nBuilds a delta list of stock changes for a stock export.\n\n**Time window and locations**\n- `Since` to `DateTo` defines the window. `DateTo` defaults to the current time; values up to `1990-01-01` are also replaced by the current time.\n- `LocID` restricts to one location; empty means all locations.\n\n**Candidates**\n1. Non-bundle items with entries in `InvBinItemLog` in the window at the selected locations. `StockChange` is the sum of the logged quantities, `UpdateDate` the latest log date.\n2. If `IncludeOrderLineChanges` = 1, items with order lines updated in the window at the selected locations are added (if not already candidates). They need at least one `InvBinItemLog` entry; `StockChange` is then the sum of **all** logged quantities at the locations, `UpdateDate` is `items.LastCalculateStockDate` (fallback: latest log date, then now).\n3. For every candidate that is a component of a bundle (`BundleItems`), the bundle item is added too, with `StockChange` = component change divided (integer) by the component quantity.\n\n**Sort and paging**\nCandidates are numbered by `UpdateDate` ascending, then by the latest `InvBinItemLog` key. Rows with number >= `Start` + 1 are taken, at most `Rowcount`. Bundle items that appear without the bundle flag and items no longer in `items` are skipped. The returned `RowNr` is renumbered from 1 within the page.\n\n**Stock values**\n- `PhysicalStock` = `items.Quantity`.\n- `MinStockQty` = sum of non-negative `ItemLocationSpecific.MinStockQty` for the location (or all locations).\n- For non-bundles: `AvailableStock` = sum of `ItemLocationSpecific.LocationQuantity` over all locations without special stock, minus either open order quantities (`ANG` lines plus `HAL` lines not older than `HalOrdersActiveDays` days) or the number of reservations on non-final order lines (excluding states `EIN`, `FUT`, `FUS`), depending on settings. `OpenSupplierOrderQTY` is the open quantity of supplier order lines whose status is fully open; `EstimatedDelivery` comes from `Item_EstimatedDelivery.ExportEstimatedDelivery`.\n- For bundles: `AvailableStock` stays `items.Quantity`, `OpenSupplierOrderQTY` 0, `EstimatedDelivery` NULL.\n\n**Excluded bin groups**\nIf `ExcludeBinGroups` is given (comma-separated), the quantity logged up to `DateTo` in bins of these groups (locations without special stock) is subtracted from `AvailableStock`, `PhysicalStock` and `StockChange`; for bundles the quantity is derived via the component quantity. `PhysicalStockLoc` is then the bin quantity at the selected locations outside these groups. Without `ExcludeBinGroups`, `PhysicalStockLoc` is the sum of `ItemLocationSpecific.LocationQuantity` at the selected locations for non-bundles (0 for bundles).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | Yes | Start of the change window (inclusive). |\n| `Rowcount` | int | No | Maximum number of rows per page. |\n| `LocID` | varchar(3) | No | Location ID to restrict to; empty or NULL for all locations. |\n| `DateTo` | datetime | No | End of the change window (inclusive). NULL or a date up to 1990-01-01 means the current time. |\n| `Start` | int | No | Number of candidate rows to skip (paging offset). |\n| `ExcludeBinGroups` | varchar(max) | No | Comma-separated list of bin groups whose quantities are subtracted from the stock values. |\n| `IncludeOrderLineChanges` | smallint | No | If 1, items with order lines changed in the window are also returned. |\n\n- Read-only; all permanent tables are read with `NOLOCK`, so values may reflect uncommitted data.\n- Passing `1900-01-01` (value 0) as `Since` turns it into NULL; the window filter then matches nothing and the result is empty.\n- Settings read at runtime: `StockExportUsePhysicalStock` (if not `0`, no order or reservation quantities are subtracted), `ReservePrepaymentOrders` and `ExportAvailableStock_WhenReservationsAreEnabled` (choose between open order quantities and reservation count), `HalOrdersActiveDays` (0 means 7; if the setting is missing, `HAL` lines are not counted). `ExportStock_locations` is read but not used.\n- Reservation counts are only applied to items that also have open `ANG`/`HAL` order lines, because of the way the intermediate results are joined.\n- `AvailableStock` for non-bundles uses all locations without special stock, regardless of `LocID`; only `PhysicalStockLoc`, `MinStockQty` and the candidate selection respect `LocID`.\n- For paging, increase `Start` by `Rowcount` for the next page; the returned `RowNr` always starts at 1. Because `UpdateDate` ascending is the sort key, new changes during paging can shift positions.\n\nDocumentation: https://pixi-api-docs.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": "Returns items whose stock changed in a time window, with physical and available stock, open supplier order quantity and reorder level, paged.\n\nBuilds a delta list of stock changes for a stock export.\n\n**Time window and locations**\n- `Since` to `DateTo` defines the window. `DateTo` defaults to the current time; values up to `1990-01-01` are also replaced by the current time.\n- `LocID` restricts to one location; empty means all locations.\n\n**Candidates**\n1. Non-bundle items with entries in `InvBinItemLog` in the window at the selected locations. `StockChange` is the sum of the logged quantities, `UpdateDate` the latest log date.\n2. If `IncludeOrderLineChanges` = 1, items with order lines updated in the window at the selected locations are added (if not already candidates). They need at least one `InvBinItemLog` entry; `StockChange` is then the sum of **all** logged quantities at the locations, `UpdateDate` is `items.LastCalculateStockDate` (fallback: latest log date, then now).\n3. For every candidate that is a component of a bundle (`BundleItems`), the bundle item is added too, with `StockChange` = component change divided (integer) by the component quantity.\n\n**Sort and paging**\nCandidates are numbered by `UpdateDate` ascending, then by the latest `InvBinItemLog` key. Rows with number >= `Start` + 1 are taken, at most `Rowcount`. Bundle items that appear without the bundle flag and items no longer in `items` are skipped. The returned `RowNr` is renumbered from 1 within the page.\n\n**Stock values**\n- `PhysicalStock` = `items.Quantity`.\n- `MinStockQty` = sum of non-negative `ItemLocationSpecific.MinStockQty` for the location (or all locations).\n- For non-bundles: `AvailableStock` = sum of `ItemLocationSpecific.LocationQuantity` over all locations without special stock, minus either open order quantities (`ANG` lines plus `HAL` lines not older than `HalOrdersActiveDays` days) or the number of reservations on non-final order lines (excluding states `EIN`, `FUT`, `FUS`), depending on settings. `OpenSupplierOrderQTY` is the open quantity of supplier order lines whose status is fully open; `EstimatedDelivery` comes from `Item_EstimatedDelivery.ExportEstimatedDelivery`.\n- For bundles: `AvailableStock` stays `items.Quantity`, `OpenSupplierOrderQTY` 0, `EstimatedDelivery` NULL.\n\n**Excluded bin groups**\nIf `ExcludeBinGroups` is given (comma-separated), the quantity logged up to `DateTo` in bins of these groups (locations without special stock) is subtracted from `AvailableStock`, `PhysicalStock` and `StockChange`; for bundles the quantity is derived via the component quantity. `PhysicalStockLoc` is then the bin quantity at the selected locations outside these groups. Without `ExcludeBinGroups`, `PhysicalStockLoc` is the sum of `ItemLocationSpecific.LocationQuantity` at the selected locations for non-bundles (0 for bundles).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | Yes | Start of the change window (inclusive). |\n| `Rowcount` | int | No | Maximum number of rows per page. |\n| `LocID` | varchar(3) | No | Location ID to restrict to; empty or NULL for all locations. |\n| `DateTo` | datetime | No | End of the change window (inclusive). NULL or a date up to 1990-01-01 means the current time. |\n| `Start` | int | No | Number of candidate rows to skip (paging offset). |\n| `ExcludeBinGroups` | varchar(max) | No | Comma-separated list of bin groups whose quantities are subtracted from the stock values. |\n| `IncludeOrderLineChanges` | smallint | No | If 1, items with order lines changed in the window are also returned. |\n\n- Read-only; all permanent tables are read with `NOLOCK`, so values may reflect uncommitted data.\n- Passing `1900-01-01` (value 0) as `Since` turns it into NULL; the window filter then matches nothing and the result is empty.\n- Settings read at runtime: `StockExportUsePhysicalStock` (if not `0`, no order or reservation quantities are subtracted), `ReservePrepaymentOrders` and `ExportAvailableStock_WhenReservationsAreEnabled` (choose between open order quantities and reservation count), `HalOrdersActiveDays` (0 means 7; if the setting is missing, `HAL` lines are not counted). `ExportStock_locations` is read but not used.\n- Reservation counts are only applied to items that also have open `ANG`/`HAL` order lines, because of the way the intermediate results are joined.\n- `AvailableStock` for non-bundles uses all locations without special stock, regardless of `LocID`; only `PhysicalStockLoc`, `MinStockQty` and the candidate selection respect `LocID`.\n- For paging, increase `Start` by `Rowcount` for the next page; the returned `RowNr` always starts at 1. Because `UpdateDate` ascending is the sort key, new changes during paging can shift positions.\n\nDocumentation: https://pixi-api-docs.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": "Returns items whose stock changed in a time window, with physical, available and per-location stock, reorder level and open supplier order quantity, with paging.\n\nDelta export of stock changes, typically used to sync shop stock levels.\n\n**1. Locations.** All locations, or only `LocID` if it is set.\n\n**2. Changed items.** Non-bundle items with entries in the bin item log (`InvBinItemLog`) whose `UpdateDate` is between `Since` and `DateTo` in the selected locations.\n- `StockChange` is the sum of the logged quantities in the window.\n- `UpdateDate` is the latest log date.\n- `OriginalUpdateDate` is the item's `LastCalculateStockDate`, or the latest log date if that is empty.\n\n**3. Order line changes.** With `IncludeOrderLineChanges = 1`, items with order lines that were updated in the window are added if they are not already candidates. The line's `LocationID` must be one of the selected locations, and the item must have bin log entries in those locations.\n- For these items `StockChange` is the sum of **all** log entries in those locations, not only those in the window.\n- `UpdateDate` is `LastCalculateStockDate`, otherwise the latest log date, otherwise the current time.\n\n**4. Bundles.** For every changed component, the bundle items that contain it are added (`BundleItem = 1`). Their `StockChange` is the largest component change divided (integer division) by the component quantity in the bundle. Items that are bundle heads are only returned as bundle rows.\n\n**5. Sorting and paging.** Candidates are numbered by `UpdateDate` ascending, then by the highest log key. Rows with a number of at least `Start + 1` are returned, at most `Rowcount` of them.\n\n**6. Stock figures.**\n- `PhysicalStock`: `items.Quantity`.\n- `MinStockQty`: sum of the non-negative `MinStockQty` values in `ItemLocationSpecific` for `LocID`, or for all locations.\n- For non-bundles:\n - `AvailableStock` = the sum of `LocationQuantity` over all locations that are not special stock, minus the reserved quantity (see notes).\n - `OpenSupplierOrderQTY` = sum of `Qty - DeliveredQty - UndeliveredQty` over supplier orders whose status has `IsAllOpen = 1`.\n - `EstimatedDelivery` comes from `Item_EstimatedDelivery.ExportEstimatedDelivery`.\n- For bundles, `AvailableStock` stays `items.Quantity`, `OpenSupplierOrderQTY` is 0 and `EstimatedDelivery` is empty.\n\n**7. Excluded bin groups.** If `ExcludeBinGroups` is set, the quantity in bins of these groups is subtracted from `PhysicalStock`, `AvailableStock` and `StockChange`. This quantity is the sum of all log entries up to `DateTo`. For bundles it is derived from the components. `PhysicalStockLoc` is then the sum of the bin quantities in the selected locations, without the excluded bin groups.\n\nWithout `ExcludeBinGroups`, `PhysicalStockLoc` is the sum of `LocationQuantity` in the selected locations, for non-bundles only.\n\nThe returned `RowNr` is renumbered from 1 within the returned page.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | Yes | Start of the change window. Bin log entries and, if enabled, order line changes from this time on are considered. |\n| `Rowcount` | int | No | Maximum number of rows returned (page size). |\n| `LocID` | varchar(3) | No | Location ID to restrict changes, reorder level and `PhysicalStockLoc`. Empty means all locations. |\n| `DateTo` | datetime | No | End of the change window. NULL, 0 or a date up to 1990-01-01 means the current time. |\n| `Start` | int | No | Number of candidate rows to skip (paging offset). 0 starts with the first row. |\n| `ExcludeBinGroups` | varchar(max) | No | Comma-separated list of bin groups whose quantities are subtracted from the stock figures. Empty or NULL disables the exclusion. |\n| `IncludeOrderLineChanges` | smallint | No | If 1, items with order lines updated in the window are also returned. |\n\n- Read-only. All reads use `NOLOCK`, so results can contain uncommitted data.\n\n**Settings read at runtime:**\n- `StockExportUsePhysicalStock`: only if `0`, open order quantities and reservations are subtracted from `AvailableStock`.\n- `ReservePrepaymentOrders` and `ExportAvailableStock_WhenReservationsAreEnabled`:\n - If reservations are off, or both settings are `1`, the subtracted quantity is the sum of order lines in status `ANG`, plus `HAL` lines with an order date within the last `HalOrdersActiveDays` days (default 7).\n - Otherwise it is the number of reservations whose order line has a non-final status other than `EIN`, `FUT` and `FUS`. Because of the join, reservations only count if the item also has `ANG`/`HAL` lines.\n- `ExportStock_locations` is read but not used.\n\n**Pitfalls:**\n- `Since` must be a real date. The value 0 (1900-01-01) is turned into NULL and then no log entries match.\n- `DateTo` values up to 1990-01-01 are replaced by the current time.\n- The base for `AvailableStock` covers all non-special locations, even when `LocID` is set.\n- The bin group exclusion considers bins of all locations.\n- For the next page, increase `Start` by the number of rows received, or continue with a later `Since`. The returned `RowNr` is page-relative.\n- The comment in the code says bundles use `LocationQuantity`, but the code updates `PhysicalStockLoc` only for non-bundles; for bundles it stays 0.\n\nDocumentation: https://pixi-api-docs.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": "Returns items whose stock changed in a time window, with physical, available and per-location stock, reorder level and open supplier order quantity, with paging.\n\nDelta export of stock changes, typically used to sync shop stock levels.\n\n**1. Locations.** All locations, or only `LocID` if it is set.\n\n**2. Changed items.** Non-bundle items with entries in the bin item log (`InvBinItemLog`) whose `UpdateDate` is between `Since` and `DateTo` in the selected locations.\n- `StockChange` is the sum of the logged quantities in the window.\n- `UpdateDate` is the latest log date.\n- `OriginalUpdateDate` is the item's `LastCalculateStockDate`, or the latest log date if that is empty.\n\n**3. Order line changes.** With `IncludeOrderLineChanges = 1`, items with order lines that were updated in the window are added if they are not already candidates. The line's `LocationID` must be one of the selected locations, and the item must have bin log entries in those locations.\n- For these items `StockChange` is the sum of **all** log entries in those locations, not only those in the window.\n- `UpdateDate` is `LastCalculateStockDate`, otherwise the latest log date, otherwise the current time.\n\n**4. Bundles.** For every changed component, the bundle items that contain it are added (`BundleItem = 1`). Their `StockChange` is the largest component change divided (integer division) by the component quantity in the bundle. Items that are bundle heads are only returned as bundle rows.\n\n**5. Sorting and paging.** Candidates are numbered by `UpdateDate` ascending, then by the highest log key. Rows with a number of at least `Start + 1` are returned, at most `Rowcount` of them.\n\n**6. Stock figures.**\n- `PhysicalStock`: `items.Quantity`.\n- `MinStockQty`: sum of the non-negative `MinStockQty` values in `ItemLocationSpecific` for `LocID`, or for all locations.\n- For non-bundles:\n - `AvailableStock` = the sum of `LocationQuantity` over all locations that are not special stock, minus the reserved quantity (see notes).\n - `OpenSupplierOrderQTY` = sum of `Qty - DeliveredQty - UndeliveredQty` over supplier orders whose status has `IsAllOpen = 1`.\n - `EstimatedDelivery` comes from `Item_EstimatedDelivery.ExportEstimatedDelivery`.\n- For bundles, `AvailableStock` stays `items.Quantity`, `OpenSupplierOrderQTY` is 0 and `EstimatedDelivery` is empty.\n\n**7. Excluded bin groups.** If `ExcludeBinGroups` is set, the quantity in bins of these groups is subtracted from `PhysicalStock`, `AvailableStock` and `StockChange`. This quantity is the sum of all log entries up to `DateTo`. For bundles it is derived from the components. `PhysicalStockLoc` is then the sum of the bin quantities in the selected locations, without the excluded bin groups.\n\nWithout `ExcludeBinGroups`, `PhysicalStockLoc` is the sum of `LocationQuantity` in the selected locations, for non-bundles only.\n\nThe returned `RowNr` is renumbered from 1 within the returned page.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | Yes | Start of the change window. Bin log entries and, if enabled, order line changes from this time on are considered. |\n| `Rowcount` | int | No | Maximum number of rows returned (page size). |\n| `LocID` | varchar(3) | No | Location ID to restrict changes, reorder level and `PhysicalStockLoc`. Empty means all locations. |\n| `DateTo` | datetime | No | End of the change window. NULL, 0 or a date up to 1990-01-01 means the current time. |\n| `Start` | int | No | Number of candidate rows to skip (paging offset). 0 starts with the first row. |\n| `ExcludeBinGroups` | varchar(max) | No | Comma-separated list of bin groups whose quantities are subtracted from the stock figures. Empty or NULL disables the exclusion. |\n| `IncludeOrderLineChanges` | smallint | No | If 1, items with order lines updated in the window are also returned. |\n\n- Read-only. All reads use `NOLOCK`, so results can contain uncommitted data.\n\n**Settings read at runtime:**\n- `StockExportUsePhysicalStock`: only if `0`, open order quantities and reservations are subtracted from `AvailableStock`.\n- `ReservePrepaymentOrders` and `ExportAvailableStock_WhenReservationsAreEnabled`:\n - If reservations are off, or both settings are `1`, the subtracted quantity is the sum of order lines in status `ANG`, plus `HAL` lines with an order date within the last `HalOrdersActiveDays` days (default 7).\n - Otherwise it is the number of reservations whose order line has a non-final status other than `EIN`, `FUT` and `FUS`. Because of the join, reservations only count if the item also has `ANG`/`HAL` lines.\n- `ExportStock_locations` is read but not used.\n\n**Pitfalls:**\n- `Since` must be a real date. The value 0 (1900-01-01) is turned into NULL and then no log entries match.\n- `DateTo` values up to 1990-01-01 are replaced by the current time.\n- The base for `AvailableStock` covers all non-special locations, even when `LocID` is set.\n- The bin group exclusion considers bins of all locations.\n- For the next page, increase `Start` by the number of rows received, or continue with a later `Since`. The returned `RowNr` is page-relative.\n- The comment in the code says bundles use `LocationQuantity`, but the code updates `PhysicalStockLoc` only for non-bundles; for bundles it stays 0.\n\nDocumentation: https://pixi-api-docs.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": "Returns items whose stock changed in a time window, with physical and available stock, optionally restricted to one location and excluding bin groups.\n\nDelta stock export per location. The call collects changed items, calculates their stock figures and returns one page of rows.\n\n**1. Candidate items**\n\n- Candidates are non-bundle items that have entries in the stock movement log `InvBinItemLog`.\n- The change date is `COALESCE(items.LastCalculateStockDate, InvBinItemLog.UpdateDate, now)`. It must lie between `Since` and `DateTo`.\n- If `LocID` is not empty, only log entries of that location count.\n- `StockChange` is the sum of the logged quantities.\n\n**2. Bundles**\n\n- For every changed component, the bundle (parent) items it belongs to are added with `BundleItem = 1`.\n- Their `StockChange` is the component change divided by the component quantity in the bundle (integer division).\n\n**3. Paging**\n\n- Rows are numbered (`RowNr`) by change date ascending, then by the highest log key.\n- `Start` is a zero-based offset. Rows from `Start + 1` onward are kept, and at most `Rowcount` rows are returned.\n\n**4. Cleanup**\n\n- Rows for items that no longer exist are removed.\n- Rows for items that are now bundles but were collected as non-bundles are removed.\n\n**5. Item data**\n\n- `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `Enabled` and `MinStockQty` come from the item master.\n- `PhysicalStock` is the sum of all positive `LocationQuantity` values when `LocID` is empty, otherwise the location quantity of `LocID`.\n- `AvailableStock` is first set to `items.Quantity`.\n\n**6. Non-bundle items only**\n\n`AvailableStock` is recalculated as the sum of bin quantities (`InvBinItem`) in the location (or all locations), minus a deduction:\n\n- If setting `ReservePrepaymentOrders` is not `1`: the order line quantities with status `ANG` or `HAL` are subtracted.\n- Otherwise: the **number** of reservation records is subtracted, counting order lines in non-final statuses except `EIN`, `FUT` and `FUS`.\n- Both deductions apply only when setting `StockExportUsePhysicalStock` is `0`.\n\nThe call also fills:\n\n- `OpenSupplierOrderQTY`: open quantity of supplier order lines whose status has `IsAllOpen = 1`.\n- `EstimatedDelivery`: from `Item_EstimatedDelivery.ExportEstimatedDelivery`.\n\n**7. Excluded bin groups**\n\n- If `ExcludeBinGroups` is set (comma-separated list), the logged quantities of all bins in these groups are summed per item. Only log entries up to `DateTo` count.\n- For bundles, the result is converted to bundle units.\n- This quantity is subtracted from `AvailableStock`, `PhysicalStock` and `StockChange`.\n\n**8. Result**\n\nThe result is sorted by `RowNr`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | Yes | Start of the change window (inclusive). `0` results in an empty result. |\n| `Rowcount` | int | No | Maximum number of rows returned (page size). |\n| `LocID` | varchar(3) | No | Location ID to restrict changes and stock to. Empty or NULL means all locations. |\n| `DateTo` | datetime | No | End of the change window (inclusive). NULL, `0` or a date on or before 1990-01-01 means the current time. |\n| `Start` | int | No | Zero-based offset for paging. Rows with `RowNr` greater than `Start` are returned. |\n| `ExcludeBinGroups` | varchar(max) | No | Comma-separated list of bin groups whose quantities are subtracted from the stock figures. Empty or NULL disables the exclusion. |\n\n**Side effect**\n\n- Every call writes one entry into `LogTable` with `Since`, `Rowcount` and the duration. The entry is labelled `pipiGetChangedItemStock`.\n\n**Locking**\n\n- All reads use `NOLOCK`, so results may include uncommitted data.\n\n**Pitfalls**\n\n- `Since` = `0` / `1900-01-01` is turned into NULL. The date filter then matches nothing and the result is empty.\n- `DateTo` values that are NULL, `0` or on or before `1990-01-01` are replaced by the current time.\n- The time window is mainly based on `items.LastCalculateStockDate`, not on the individual log entry date.\n- The `HAL` order line filter subtracts a datetime from a datetime. With setting `HalOrdersActiveDays` (default 7 if `0`), this effectively includes practically all `HAL` lines instead of only the last N days.\n- When reservations are enabled, the number of reservation rows is subtracted, not a quantity.\n- Items without any `ItemLocationSpecific` row (or none for `LocID`) keep empty item numbers, `0` stock and NULL `Enabled`.\n- `PhysicalStock` can be NULL if there is no positive location quantity and `LocID` is empty.\n- The bin group exclusion is not restricted to `LocID`.\n- For bundles, `OpenSupplierOrderQTY` stays `0` and `EstimatedDelivery` stays NULL.\n- Settings `ShowLocationStockInItemSearch` and `OldStockExport` are read but not used.\n\nDocumentation: https://pixi-api-docs.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": "Returns items whose stock changed in a time window, with physical and available stock, optionally restricted to one location and excluding bin groups.\n\nDelta stock export per location. The call collects changed items, calculates their stock figures and returns one page of rows.\n\n**1. Candidate items**\n\n- Candidates are non-bundle items that have entries in the stock movement log `InvBinItemLog`.\n- The change date is `COALESCE(items.LastCalculateStockDate, InvBinItemLog.UpdateDate, now)`. It must lie between `Since` and `DateTo`.\n- If `LocID` is not empty, only log entries of that location count.\n- `StockChange` is the sum of the logged quantities.\n\n**2. Bundles**\n\n- For every changed component, the bundle (parent) items it belongs to are added with `BundleItem = 1`.\n- Their `StockChange` is the component change divided by the component quantity in the bundle (integer division).\n\n**3. Paging**\n\n- Rows are numbered (`RowNr`) by change date ascending, then by the highest log key.\n- `Start` is a zero-based offset. Rows from `Start + 1` onward are kept, and at most `Rowcount` rows are returned.\n\n**4. Cleanup**\n\n- Rows for items that no longer exist are removed.\n- Rows for items that are now bundles but were collected as non-bundles are removed.\n\n**5. Item data**\n\n- `ItemNrInt`, `EANUPC`, `ItemNrSuppl`, `Enabled` and `MinStockQty` come from the item master.\n- `PhysicalStock` is the sum of all positive `LocationQuantity` values when `LocID` is empty, otherwise the location quantity of `LocID`.\n- `AvailableStock` is first set to `items.Quantity`.\n\n**6. Non-bundle items only**\n\n`AvailableStock` is recalculated as the sum of bin quantities (`InvBinItem`) in the location (or all locations), minus a deduction:\n\n- If setting `ReservePrepaymentOrders` is not `1`: the order line quantities with status `ANG` or `HAL` are subtracted.\n- Otherwise: the **number** of reservation records is subtracted, counting order lines in non-final statuses except `EIN`, `FUT` and `FUS`.\n- Both deductions apply only when setting `StockExportUsePhysicalStock` is `0`.\n\nThe call also fills:\n\n- `OpenSupplierOrderQTY`: open quantity of supplier order lines whose status has `IsAllOpen = 1`.\n- `EstimatedDelivery`: from `Item_EstimatedDelivery.ExportEstimatedDelivery`.\n\n**7. Excluded bin groups**\n\n- If `ExcludeBinGroups` is set (comma-separated list), the logged quantities of all bins in these groups are summed per item. Only log entries up to `DateTo` count.\n- For bundles, the result is converted to bundle units.\n- This quantity is subtracted from `AvailableStock`, `PhysicalStock` and `StockChange`.\n\n**8. Result**\n\nThe result is sorted by `RowNr`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | Yes | Start of the change window (inclusive). `0` results in an empty result. |\n| `Rowcount` | int | No | Maximum number of rows returned (page size). |\n| `LocID` | varchar(3) | No | Location ID to restrict changes and stock to. Empty or NULL means all locations. |\n| `DateTo` | datetime | No | End of the change window (inclusive). NULL, `0` or a date on or before 1990-01-01 means the current time. |\n| `Start` | int | No | Zero-based offset for paging. Rows with `RowNr` greater than `Start` are returned. |\n| `ExcludeBinGroups` | varchar(max) | No | Comma-separated list of bin groups whose quantities are subtracted from the stock figures. Empty or NULL disables the exclusion. |\n\n**Side effect**\n\n- Every call writes one entry into `LogTable` with `Since`, `Rowcount` and the duration. The entry is labelled `pipiGetChangedItemStock`.\n\n**Locking**\n\n- All reads use `NOLOCK`, so results may include uncommitted data.\n\n**Pitfalls**\n\n- `Since` = `0` / `1900-01-01` is turned into NULL. The date filter then matches nothing and the result is empty.\n- `DateTo` values that are NULL, `0` or on or before `1990-01-01` are replaced by the current time.\n- The time window is mainly based on `items.LastCalculateStockDate`, not on the individual log entry date.\n- The `HAL` order line filter subtracts a datetime from a datetime. With setting `HalOrdersActiveDays` (default 7 if `0`), this effectively includes practically all `HAL` lines instead of only the last N days.\n- When reservations are enabled, the number of reservation rows is subtracted, not a quantity.\n- Items without any `ItemLocationSpecific` row (or none for `LocID`) keep empty item numbers, `0` stock and NULL `Enabled`.\n- `PhysicalStock` can be NULL if there is no positive location quantity and `LocID` is empty.\n- The bin group exclusion is not restricted to `LocID`.\n- For bundles, `OpenSupplierOrderQTY` stays `0` and `EstimatedDelivery` stays NULL.\n- Settings `ShowLocationStockInItemSearch` and `OldStockExport` are read but not used.\n\nDocumentation: https://pixi-api-docs.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": "Returns items whose stock was recalculated since a given point in time, with physical and available stock, estimated delivery and open supplier order quantity, paged.\n\nDelta export of item stock based on the item column `LastCalculateStockDate`.\n\n1. If `Since` is `NULL`, it is treated as `0` (1900-01-01), so all items qualify. A `NULL` `Start` is treated as `0`.\n2. The first `Start + Rowcount` items with `LastCalculateStockDate >= Since` are collected, ordered by `LastCalculateStockDate`, then `ItemKey`. Each row gets a sequential `RowNr` in this order.\n3. For the rows with `RowNr > Start` the item data is filled in: item numbers, EAN, physical stock (`Quantity`), minimum stock, enabled flag, bundle flag, the estimated delivery date from the estimated delivery table and the available stock.\n4. **Available stock** is the export stock of the item's locations minus a deduction that depends on settings:\n - If `StockExportUsePhysicalStock` is `'1'`, nothing is deducted.\n - Otherwise, if reservations (`ReservePrepaymentOrders` = `'1'`) are disabled, or they are enabled and `ExportAvailableStock_WhenReservationsAreEnabled` = `1`, the quantity of open order lines is deducted.\n - Otherwise, if reservations are enabled, the quantity of open reservations is deducted.\n - Bundle items never get a deduction.\n5. The open supplier order quantity is calculated per item as the sum of ordered minus delivered minus undelivered quantity over supplier order lines whose supplier order has a status flagged as open (`IsAllOpen = 1`) and whose consideration start date is empty or not in the future.\n6. Up to `Rowcount` rows with `RowNr > Start` are returned, sorted by `RowNr`.\n\nPaging: `Start` is the number of rows to skip, `Rowcount` the page size. For the next page pass `Start + Rowcount` with the same `Since`, or start over with the last `UpdateDate` as new `Since`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | Yes | Lower bound (inclusive) for the item's last stock calculation date. `NULL` returns all items. |\n| `Rowcount` | int | No | Maximum number of rows to return (page size). |\n| `Start` | int | No | Number of rows to skip; only rows with `RowNr > Start` are returned. `NULL` is treated as `0`. |\n\n- All reads use `NOLOCK`; results may contain uncommitted data and can shift between paging calls if stock is recalculated meanwhile (the order depends on `LastCalculateStockDate`).\n- The filter is `>= Since`; when continuing with the last `UpdateDate` as `Since`, items with exactly that timestamp are returned again.\n- The column `OpenSupplierOrderQTY` is never filled and is always `0`. The actual open supplier order quantity is in `OpenSupplOrdersQty`, which is `NULL` if the item has no open supplier order lines.\n- `Rowcount` must not be `NULL`; `TOP` with `NULL` causes an SQL error.\n- Settings are read via `fpixi_GetSetting`; missing settings count as `'0'`. The setting `ExportAvailableStock_WhenReservationsAreEnabled` is converted to `int`, a non-numeric value causes a conversion error.\n- Cost grows with `Start`, because `Start + Rowcount` rows are prepared on every call.\n\nDocumentation: https://pixi-api-docs.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": "Returns items whose stock was recalculated since a given point in time, with physical and available stock, estimated delivery and open supplier order quantity, paged.\n\nDelta export of item stock based on the item column `LastCalculateStockDate`.\n\n1. If `Since` is `NULL`, it is treated as `0` (1900-01-01), so all items qualify. A `NULL` `Start` is treated as `0`.\n2. The first `Start + Rowcount` items with `LastCalculateStockDate >= Since` are collected, ordered by `LastCalculateStockDate`, then `ItemKey`. Each row gets a sequential `RowNr` in this order.\n3. For the rows with `RowNr > Start` the item data is filled in: item numbers, EAN, physical stock (`Quantity`), minimum stock, enabled flag, bundle flag, the estimated delivery date from the estimated delivery table and the available stock.\n4. **Available stock** is the export stock of the item's locations minus a deduction that depends on settings:\n - If `StockExportUsePhysicalStock` is `'1'`, nothing is deducted.\n - Otherwise, if reservations (`ReservePrepaymentOrders` = `'1'`) are disabled, or they are enabled and `ExportAvailableStock_WhenReservationsAreEnabled` = `1`, the quantity of open order lines is deducted.\n - Otherwise, if reservations are enabled, the quantity of open reservations is deducted.\n - Bundle items never get a deduction.\n5. The open supplier order quantity is calculated per item as the sum of ordered minus delivered minus undelivered quantity over supplier order lines whose supplier order has a status flagged as open (`IsAllOpen = 1`) and whose consideration start date is empty or not in the future.\n6. Up to `Rowcount` rows with `RowNr > Start` are returned, sorted by `RowNr`.\n\nPaging: `Start` is the number of rows to skip, `Rowcount` the page size. For the next page pass `Start + Rowcount` with the same `Since`, or start over with the last `UpdateDate` as new `Since`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | Yes | Lower bound (inclusive) for the item's last stock calculation date. `NULL` returns all items. |\n| `Rowcount` | int | No | Maximum number of rows to return (page size). |\n| `Start` | int | No | Number of rows to skip; only rows with `RowNr > Start` are returned. `NULL` is treated as `0`. |\n\n- All reads use `NOLOCK`; results may contain uncommitted data and can shift between paging calls if stock is recalculated meanwhile (the order depends on `LastCalculateStockDate`).\n- The filter is `>= Since`; when continuing with the last `UpdateDate` as `Since`, items with exactly that timestamp are returned again.\n- The column `OpenSupplierOrderQTY` is never filled and is always `0`. The actual open supplier order quantity is in `OpenSupplOrdersQty`, which is `NULL` if the item has no open supplier order lines.\n- `Rowcount` must not be `NULL`; `TOP` with `NULL` causes an SQL error.\n- Settings are read via `fpixi_GetSetting`; missing settings count as `'0'`. The setting `ExportAvailableStock_WhenReservationsAreEnabled` is converted to `int`, a non-numeric value causes a conversion error.\n- Cost grows with `Start`, because `Start + Rowcount` rows are prepared on every call.\n\nDocumentation: https://pixi-api-docs.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": "Returns the total bin stock of an item at one location and the quantity still available after subtracting open future (FUT) order lines.\n\nCalculates the stock of a single item for direct fulfillment (DF) purposes, as stated in the code comment: *stock based on open DF orders*.\n\nSteps:\n\n1. Sums `BinItemQty` of all bin entries in `InvBinItem` for the item `@ItemKey` whose bin (`InvBin`) belongs to the location `@Location` (`BinLocId`). This sum is returned as `TotalQty` (0 if there are no matching bins).\n2. Sums `Qty` of all order lines in `Orderlines` for the item that\n - have status `FUT`,\n - have `Qty > 0`, and\n - have **no** entry in `OrderHistory` with status `FUT` and `ClientNotified = 'N'`.\n3. Returns `TotalQty` minus the order line sum as `FulfillmentAvailableQty`, together with the passed `@Location`.\n\nThe call always returns exactly one row, because the query aggregates without grouping.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Yes | Internal key of the item whose stock is calculated (matched against `InvBinItem.BinItemRef` and `Orderlines.ItemRef`). |\n| `Location` | char(3) | No | Location code (`InvBin.BinLocId`) whose bins are summed. Also echoed in the result. If NULL, no bins match and the stock is 0. |\n\n- If `@Location` is omitted (NULL), the comparison `BinLocId = NULL` never matches, so `TotalQty` is always 0 and `FulfillmentAvailableQty` is 0 or negative. Always pass a location.\n- The open order line quantity is **not** filtered by location: FUT order lines of all locations are subtracted from the stock of the given location.\n- `FulfillmentAvailableQty` can become negative when open FUT quantities exceed the bin stock.\n- An unknown `@ItemKey` does not cause an error; the call returns a row with 0 values.\n- All tables are read with `NOLOCK`, so the result may include uncommitted data.\n\nDocumentation: https://pixi-api-docs.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": "Returns the total bin stock of an item at one location and the quantity still available after subtracting open future (FUT) order lines.\n\nCalculates the stock of a single item for direct fulfillment (DF) purposes, as stated in the code comment: *stock based on open DF orders*.\n\nSteps:\n\n1. Sums `BinItemQty` of all bin entries in `InvBinItem` for the item `@ItemKey` whose bin (`InvBin`) belongs to the location `@Location` (`BinLocId`). This sum is returned as `TotalQty` (0 if there are no matching bins).\n2. Sums `Qty` of all order lines in `Orderlines` for the item that\n - have status `FUT`,\n - have `Qty > 0`, and\n - have **no** entry in `OrderHistory` with status `FUT` and `ClientNotified = 'N'`.\n3. Returns `TotalQty` minus the order line sum as `FulfillmentAvailableQty`, together with the passed `@Location`.\n\nThe call always returns exactly one row, because the query aggregates without grouping.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | Yes | Internal key of the item whose stock is calculated (matched against `InvBinItem.BinItemRef` and `Orderlines.ItemRef`). |\n| `Location` | char(3) | No | Location code (`InvBin.BinLocId`) whose bins are summed. Also echoed in the result. If NULL, no bins match and the stock is 0. |\n\n- If `@Location` is omitted (NULL), the comparison `BinLocId = NULL` never matches, so `TotalQty` is always 0 and `FulfillmentAvailableQty` is 0 or negative. Always pass a location.\n- The open order line quantity is **not** filtered by location: FUT order lines of all locations are subtracted from the stock of the given location.\n- `FulfillmentAvailableQty` can become negative when open FUT quantities exceed the bin stock.\n- An unknown `@ItemKey` does not cause an error; the call returns a row with 0 values.\n- All tables are read with `NOLOCK`, so the result may include uncommitted data.\n\nDocumentation: https://pixi-api-docs.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": "Returns the items stored on a stock bin or a bin group, with stock level, batch number and best-before date.\n\nLists the bin stock (`InvBinItem`) of one stock bin or of all bins of a bin group, joined with item master data.\n\n- Empty strings in `BinName`, `LocID` and `BinGroup` are treated as `NULL`.\n- At least one of `BinName` or `BinGroup` must be set. If both are empty, the call returns an empty result set.\n- `BinName` filters on the exact bin name, `BinGroup` on the exact bin group, and `LocID` restricts the bins to one location. All filters that are set are combined with AND.\n- The internal item number in `InternalItemNumber` comes from the item codes with code type `3`. It is empty if the item has no such code.\n\nThe parameter `GroupItems` controls how rows are grouped:\n\n- `0` (default): one row per item, bin, batch number, best-before date **and** update date of the bin stock entry. Rows are sorted by `UpdateDate` in ascending order.\n- `1`: one row per item, bin, batch number and best-before date. The quantities are summed up and `UpdateDate` holds the latest update date. Rows are sorted by this latest date in ascending order.\n\n`StockLevel` is the sum of the bin quantities within each group.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BinName` | varchar(50) | No | Exact name of the stock bin. Empty string is treated as NULL. Either this or `BinGroup` must be set. |\n| `LocID` | varchar(3) | No | Location ID; restricts the bins to this location. Empty or NULL means all locations. |\n| `GroupItems` | bit | No | Controls whether bin stock entries with different update dates are combined into one row. |\n| `BinGroup` | varchar(20) | No | Exact bin group; returns the items of all bins in this group. Empty string is treated as NULL. Either this or `BinName` must be set. |\n\n- All tables are read with `NOLOCK`, so the result can contain uncommitted data.\n- With `GroupItems = 0` the same item can appear several times on the same bin if its bin stock entries have different update dates. Use `GroupItems = 1` for one row per item, bin, batch and best-before date.\n- If an item has more than one item code of type `3`, it appears once per code.\n- When only `BinName` is given without `LocID`, bins with the same name in different locations are all returned. The location is not part of the output, so pass `LocID` if bin names are not unique across locations.\n- Any non-zero value of `GroupItems` behaves like `1`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the items stored on a stock bin or a bin group, with stock level, batch number and best-before date.\n\nLists the bin stock (`InvBinItem`) of one stock bin or of all bins of a bin group, joined with item master data.\n\n- Empty strings in `BinName`, `LocID` and `BinGroup` are treated as `NULL`.\n- At least one of `BinName` or `BinGroup` must be set. If both are empty, the call returns an empty result set.\n- `BinName` filters on the exact bin name, `BinGroup` on the exact bin group, and `LocID` restricts the bins to one location. All filters that are set are combined with AND.\n- The internal item number in `InternalItemNumber` comes from the item codes with code type `3`. It is empty if the item has no such code.\n\nThe parameter `GroupItems` controls how rows are grouped:\n\n- `0` (default): one row per item, bin, batch number, best-before date **and** update date of the bin stock entry. Rows are sorted by `UpdateDate` in ascending order.\n- `1`: one row per item, bin, batch number and best-before date. The quantities are summed up and `UpdateDate` holds the latest update date. Rows are sorted by this latest date in ascending order.\n\n`StockLevel` is the sum of the bin quantities within each group.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BinName` | varchar(50) | No | Exact name of the stock bin. Empty string is treated as NULL. Either this or `BinGroup` must be set. |\n| `LocID` | varchar(3) | No | Location ID; restricts the bins to this location. Empty or NULL means all locations. |\n| `GroupItems` | bit | No | Controls whether bin stock entries with different update dates are combined into one row. |\n| `BinGroup` | varchar(20) | No | Exact bin group; returns the items of all bins in this group. Empty string is treated as NULL. Either this or `BinName` must be set. |\n\n- All tables are read with `NOLOCK`, so the result can contain uncommitted data.\n- With `GroupItems = 0` the same item can appear several times on the same bin if its bin stock entries have different update dates. Use `GroupItems = 1` for one row per item, bin, batch and best-before date.\n- If an item has more than one item code of type `3`, it appears once per code.\n- When only `BinName` is given without `LocID`, bins with the same name in different locations are all returned. The location is not part of the output, so pass `LocID` if bin names are not unique across locations.\n- Any non-zero value of `GroupItems` behaves like `1`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the items stored on a bin, the items from that bin on open pick lists and in boxes, plus a combined status code.\n\nLooks up the bin by `BinName` and `LocID` in `InvBin` and then returns four result sets.\n\n1. **Items on the bin** from `InvBinItem` joined with `Items`, with EAN, internal and supplier item number and the summed quantity as `StockLevel`.\n - `GroupItems = 0` (default): one row per item and `UpdateDate` of the bin entry, sorted by `UpdateDate`.\n - `GroupItems = 1`: one row per item; `UpdateDate` is the latest update date, sorted by it.\n2. **Pick list entries** from `PLitem` for this bin that are not expired (`Expired = 0`) and whose order line status is not `AUS`, `NLB`, `RET`, `STO` or `EIN`. Grouped by item and pick list; `Sum_PickListItem` is the number of pick list positions. No explicit sort order.\n3. **Box contents**: pick list entries for this bin that are not expired and whose order line has status `EIN`, joined with `boxitems` and `boxes`. Grouped by item and box number; `sum_box_item` is the summed box quantity. No explicit sort order.\n4. **Status** row with a four-digit code:\n - `1000`: no items on the bin (regardless of pick lists and boxes)\n - `1100`: items found, none on pick lists, none in boxes\n - `1101`: items found, none on pick lists, some in boxes\n - `1110`: items found, some on pick lists, none in boxes\n - `1111`: items found, on pick lists and in boxes\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BinName` | varchar(50) | Yes | Name of the bin to inspect. |\n| `LocID` | varchar(3) | No | Location ID of the bin. Effectively required, because NULL does not match any bin. |\n| `GroupItems` | bit | No | Controls grouping of the first result set. |\n\n- The bin lookup compares `BinLocID = @LocID`. If `LocID` is omitted (NULL), no bin is found under standard NULL comparison, all result sets are empty and the status is `1000`. Always pass `LocID`.\n- If the status is `1000`, pick list and box rows may still have been returned; the code does not evaluate them in that case.\n- All reads use `NOLOCK`, so the data can include uncommitted changes.\n- The second result set repeats the requested `BinName` in every row.\n\nDocumentation: https://pixi-api-docs.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": "Returns the items stored on a bin, the items from that bin on open pick lists and in boxes, plus a combined status code.\n\nLooks up the bin by `BinName` and `LocID` in `InvBin` and then returns four result sets.\n\n1. **Items on the bin** from `InvBinItem` joined with `Items`, with EAN, internal and supplier item number and the summed quantity as `StockLevel`.\n - `GroupItems = 0` (default): one row per item and `UpdateDate` of the bin entry, sorted by `UpdateDate`.\n - `GroupItems = 1`: one row per item; `UpdateDate` is the latest update date, sorted by it.\n2. **Pick list entries** from `PLitem` for this bin that are not expired (`Expired = 0`) and whose order line status is not `AUS`, `NLB`, `RET`, `STO` or `EIN`. Grouped by item and pick list; `Sum_PickListItem` is the number of pick list positions. No explicit sort order.\n3. **Box contents**: pick list entries for this bin that are not expired and whose order line has status `EIN`, joined with `boxitems` and `boxes`. Grouped by item and box number; `sum_box_item` is the summed box quantity. No explicit sort order.\n4. **Status** row with a four-digit code:\n - `1000`: no items on the bin (regardless of pick lists and boxes)\n - `1100`: items found, none on pick lists, none in boxes\n - `1101`: items found, none on pick lists, some in boxes\n - `1110`: items found, some on pick lists, none in boxes\n - `1111`: items found, on pick lists and in boxes\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BinName` | varchar(50) | Yes | Name of the bin to inspect. |\n| `LocID` | varchar(3) | No | Location ID of the bin. Effectively required, because NULL does not match any bin. |\n| `GroupItems` | bit | No | Controls grouping of the first result set. |\n\n- The bin lookup compares `BinLocID = @LocID`. If `LocID` is omitted (NULL), no bin is found under standard NULL comparison, all result sets are empty and the status is `1000`. Always pass `LocID`.\n- If the status is `1000`, pick list and box rows may still have been returned; the code does not evaluate them in that case.\n- All reads use `NOLOCK`, so the data can include uncommitted changes.\n- The second result set repeats the requested `BinName` in every row.\n\nDocumentation: https://pixi-api-docs.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": "Returns the bin stock movement log for all items in a date range, with optional filters by location, order, delivery and relocation transaction.\n\nReturns entries of the bin item log (stock movements on bins), similar to the bin history in the Pixi client but for all items at once.\n\nSteps:\n\n1. Normalises the input: an empty or missing `DateTo` becomes the current date and time, blank `Location` and `OrderNumberExternal` become `NULL` (after trimming), `DeliveryNumber` = `0` is treated as no filter, `RowCount` defaults to `1000` and `IbilKey` to `0`.\n2. Selects log entries with:\n - `IBILkey` greater than `IbilKey` (for paging),\n - `UpdateDate` >= `DateFrom` and < `DateTo` (the upper bound is exclusive),\n - optionally `LocID` = `Location`,\n - optionally the external order number of the linked order line = `OrderNumberExternal`,\n - optionally the number of the linked supplier delivery = `DeliveryNumber`,\n - optionally the linked relocation transaction = `RelocateTransactionID`,\n - entries written by the user `AutoExport` are always excluded.\n3. Enriches each entry with item data (internal item number, EAN, supplier item number), bin name, stock movement type and operation, batch number, best-before date, relocation transaction ID, delivery number and external order number.\n4. Returns at most `RowCount` rows, sorted by `IBILkey` ascending.\n\n**Paging:** pass the highest `IBILkey` of the previous response as `IbilKey` to fetch the next page.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Yes | Start of the period (inclusive), compared with the log entry's `UpdateDate`. |\n| `DateTo` | datetime | No | End of the period (exclusive). If `NULL` or empty, the current date and time is used. |\n| `Location` | varchar(3) | No | Optional location (warehouse) ID; only entries with this `LocID` are returned. Blank means all locations. |\n| `OrderNumberExternal` | varchar(50) | No | Optional external order number; only entries linked to an order line with this `OrderNrExternal` are returned. Blank means no filter. |\n| `DeliveryNumber` | int | No | Optional supplier delivery number (`SDelHNr`); only entries linked to this delivery are returned. `0` means no filter. |\n| `RelocateTransactionID` | uniqueidentifier | No | Optional relocation transaction ID; only entries linked to this relocation transaction are returned. |\n| `RowCount` | int | No | Maximum number of rows returned. `NULL` is treated as `1000`. |\n| `IbilKey` | int | No | Paging cursor: only entries with `IBILkey` greater than this value are returned. Pass the last `IBILkey` of the previous page. |\n\n- All tables are read with `NOLOCK`, so uncommitted movements may appear and results are not guaranteed to be consistent.\n- The procedure is created `WITH RECOMPILE`; a new execution plan is built on every call.\n- Entries whose `UpdateEmp` is `AutoExport` or `NULL` are never returned (the comparison `<> 'AutoExport'` excludes `NULL`).\n- Bins are joined with a LEFT JOIN, so entries for deleted bins are returned with an empty `BinName`. Log entries whose item no longer exists in `Items` are not returned.\n- Setting `OrderNumberExternal`, `DeliveryNumber` or `RelocateTransactionID` implicitly returns only entries that are linked to an order line, delivery or relocation transaction.\n- If a log entry is linked to several relocation transactions, it can appear more than once.\n- A negative `RowCount` causes a SQL error from `TOP`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the bin stock movement log for all items in a date range, with optional filters by location, order, delivery and relocation transaction.\n\nReturns entries of the bin item log (stock movements on bins), similar to the bin history in the Pixi client but for all items at once.\n\nSteps:\n\n1. Normalises the input: an empty or missing `DateTo` becomes the current date and time, blank `Location` and `OrderNumberExternal` become `NULL` (after trimming), `DeliveryNumber` = `0` is treated as no filter, `RowCount` defaults to `1000` and `IbilKey` to `0`.\n2. Selects log entries with:\n - `IBILkey` greater than `IbilKey` (for paging),\n - `UpdateDate` >= `DateFrom` and < `DateTo` (the upper bound is exclusive),\n - optionally `LocID` = `Location`,\n - optionally the external order number of the linked order line = `OrderNumberExternal`,\n - optionally the number of the linked supplier delivery = `DeliveryNumber`,\n - optionally the linked relocation transaction = `RelocateTransactionID`,\n - entries written by the user `AutoExport` are always excluded.\n3. Enriches each entry with item data (internal item number, EAN, supplier item number), bin name, stock movement type and operation, batch number, best-before date, relocation transaction ID, delivery number and external order number.\n4. Returns at most `RowCount` rows, sorted by `IBILkey` ascending.\n\n**Paging:** pass the highest `IBILkey` of the previous response as `IbilKey` to fetch the next page.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `DateFrom` | datetime | Yes | Start of the period (inclusive), compared with the log entry's `UpdateDate`. |\n| `DateTo` | datetime | No | End of the period (exclusive). If `NULL` or empty, the current date and time is used. |\n| `Location` | varchar(3) | No | Optional location (warehouse) ID; only entries with this `LocID` are returned. Blank means all locations. |\n| `OrderNumberExternal` | varchar(50) | No | Optional external order number; only entries linked to an order line with this `OrderNrExternal` are returned. Blank means no filter. |\n| `DeliveryNumber` | int | No | Optional supplier delivery number (`SDelHNr`); only entries linked to this delivery are returned. `0` means no filter. |\n| `RelocateTransactionID` | uniqueidentifier | No | Optional relocation transaction ID; only entries linked to this relocation transaction are returned. |\n| `RowCount` | int | No | Maximum number of rows returned. `NULL` is treated as `1000`. |\n| `IbilKey` | int | No | Paging cursor: only entries with `IBILkey` greater than this value are returned. Pass the last `IBILkey` of the previous page. |\n\n- All tables are read with `NOLOCK`, so uncommitted movements may appear and results are not guaranteed to be consistent.\n- The procedure is created `WITH RECOMPILE`; a new execution plan is built on every call.\n- Entries whose `UpdateEmp` is `AutoExport` or `NULL` are never returned (the comparison `<> 'AutoExport'` excludes `NULL`).\n- Bins are joined with a LEFT JOIN, so entries for deleted bins are returned with an empty `BinName`. Log entries whose item no longer exists in `Items` are not returned.\n- Setting `OrderNumberExternal`, `DeliveryNumber` or `RelocateTransactionID` implicitly returns only entries that are linked to an order line, delivery or relocation transaction.\n- If a log entry is linked to several relocation transactions, it can appear more than once.\n- A negative `RowCount` causes a SQL error from `TOP`.\n\nDocumentation: https://pixi-api-docs.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": "Returns available and physical stock, supplier price and open order line quantities for one or more items, optionally broken down by location.\n\nLooks up items and returns their stock figures.\n\n**Item identification**\n- Empty strings are treated as `NULL`; `ItemKey = 0` is treated as `NULL`.\n- At least one of `ItemKey`, `EAN`, `ItemNrSuppl`, `ItemNrInt` or `ItemXML` is required, otherwise an error row is returned.\n- The single parameters are combined with **OR** against `pixi.ItemCode`: `EAN` matches code type 1 (barcode), `ItemNrInt` code type 2 (shop item number), `ItemNrSuppl` code type 4 (supplier item number), `ItemKey` matches the item id of any code row.\n- `ItemXML` adds further items: each `/ITEMS/ITEM` element can contain `ITEMKEY` (taken directly), `ITEMNRINT`, `ITEMNRSUPPL` or `EAN` (matched against `items.ItemNrInt`, `items.ItemNrSuppl` and `items.EANUPC`).\n- If no candidate is found, an error row is returned.\n\n**Stock calculation** (per item from `items`)\n- `AvailableStock` = `ItemQtyIBIExportStock_locations` minus, for non-bundle items and when setting `StockExportUsePhysicalStock` is `0`:\n - `ItemQtyOpenOrderLines` if reservations (`ReservePrepaymentOrders`) are disabled or `ExportAvailableStock_WhenReservationsAreEnabled` = 1,\n - otherwise `ItemQtyOpenReservations` if reservations are enabled,\n - otherwise nothing is subtracted.\n- `PhysicalStock` = stock outside special stock locations, `PhysicalStockAllLocations` = including special stock.\n- `OnlyEnabledItems = 1` restricts the output to enabled items.\n\n**Excluding bin groups**\nIf `ExcludeBinGroups` (comma-separated list) is given, the quantities in bins (`InvBin`/`InvBinItemLog`) of these bin groups are summed per item and subtracted from `AvailableStock`, `PhysicalStock` and `PhysicalStockAllLocations`. For bundles containing such components, a derived quantity (minimum over components of the excluded quantity divided by the component quantity, rounded up) is subtracted as well.\n\n**Location breakdown**\nWith `LocationStock = 1` two additional text columns are returned:\n- `Locations`: `All:; :; …` with the total quantity and the quantity per location.\n- `OpenOrderlineSumLocations`: `:; …; All:;` with open customer order quantities (ANG/FUT and recent HAL orders) per location and in total, computed by `pixi.ItemInfoStockPerLocation`.\n\nOne row is returned per found item; no explicit sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal item key. `0` is treated as not set. |\n| `EAN` | varchar(50) | No | Barcode of the item (item code type 1). |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number (item code type 4). |\n| `ItemNrInt` | varchar(50) | No | Shop item number (item code type 2). |\n| `LocationStock` | bit | No | If 1, the result additionally contains the per-location columns `Locations` and `OpenOrderlineSumLocations`. |\n| `OnlyEnabledItems` | bit | No | Restricts the result to enabled items. |\n| `ExcludeBinGroups` | varchar(max) | No | Comma-separated list of bin groups whose quantities are subtracted from the stock figures. |\n| `ItemXML` | varchar(max) | No | XML list of additional items. Each `/ITEMS/ITEM` element may contain `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL` and `EAN` (max. 13 characters). |\n\n- Read-only; all tables are read `WITH (NOLOCK)`, so values may reflect uncommitted data.\n- On errors the procedure returns code `1` in addition to the status row.\n- `ItemKey` as a single parameter only matches if the item has at least one row in `pixi.ItemCode`. `ITEMKEY` values from `ItemXML` are not validated; unknown keys count as found but produce no output row, so the result can be empty without an error row.\n- An item found both via single parameters and via `ItemXML` can appear twice in the result.\n- `EAN` in `ItemXML` is read as `varchar(13)`; longer values are truncated.\n- Passing `OnlyEnabledItems` explicitly as NULL yields no rows.\n- The bin group exclusion only affects items that have a shop item number (code type 2) and whose `ItemNrInt` equals that code.\n- The order of entries inside `Locations` and `OpenOrderlineSumLocations` is not guaranteed.\n- `pixi.ItemInfoStockPerLocation` is executed even when `LocationStock` is not 1; for many items this aggregates order lines and supplier orders and can be costly. Its result depends on the settings `HalOrdersActiveDays` and `Include_FUT_StatusInOpenOrdersForSupplierOrdering`.\n- Invalid XML in `ItemXML` causes an SQL error from `sp_xml_preparedocument`.\n\nDocumentation: https://pixi-api-docs.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": "Returns available and physical stock, supplier price and open order line quantities for one or more items, optionally broken down by location.\n\nLooks up items and returns their stock figures.\n\n**Item identification**\n- Empty strings are treated as `NULL`; `ItemKey = 0` is treated as `NULL`.\n- At least one of `ItemKey`, `EAN`, `ItemNrSuppl`, `ItemNrInt` or `ItemXML` is required, otherwise an error row is returned.\n- The single parameters are combined with **OR** against `pixi.ItemCode`: `EAN` matches code type 1 (barcode), `ItemNrInt` code type 2 (shop item number), `ItemNrSuppl` code type 4 (supplier item number), `ItemKey` matches the item id of any code row.\n- `ItemXML` adds further items: each `/ITEMS/ITEM` element can contain `ITEMKEY` (taken directly), `ITEMNRINT`, `ITEMNRSUPPL` or `EAN` (matched against `items.ItemNrInt`, `items.ItemNrSuppl` and `items.EANUPC`).\n- If no candidate is found, an error row is returned.\n\n**Stock calculation** (per item from `items`)\n- `AvailableStock` = `ItemQtyIBIExportStock_locations` minus, for non-bundle items and when setting `StockExportUsePhysicalStock` is `0`:\n - `ItemQtyOpenOrderLines` if reservations (`ReservePrepaymentOrders`) are disabled or `ExportAvailableStock_WhenReservationsAreEnabled` = 1,\n - otherwise `ItemQtyOpenReservations` if reservations are enabled,\n - otherwise nothing is subtracted.\n- `PhysicalStock` = stock outside special stock locations, `PhysicalStockAllLocations` = including special stock.\n- `OnlyEnabledItems = 1` restricts the output to enabled items.\n\n**Excluding bin groups**\nIf `ExcludeBinGroups` (comma-separated list) is given, the quantities in bins (`InvBin`/`InvBinItemLog`) of these bin groups are summed per item and subtracted from `AvailableStock`, `PhysicalStock` and `PhysicalStockAllLocations`. For bundles containing such components, a derived quantity (minimum over components of the excluded quantity divided by the component quantity, rounded up) is subtracted as well.\n\n**Location breakdown**\nWith `LocationStock = 1` two additional text columns are returned:\n- `Locations`: `All:; :; …` with the total quantity and the quantity per location.\n- `OpenOrderlineSumLocations`: `:; …; All:;` with open customer order quantities (ANG/FUT and recent HAL orders) per location and in total, computed by `pixi.ItemInfoStockPerLocation`.\n\nOne row is returned per found item; no explicit sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal item key. `0` is treated as not set. |\n| `EAN` | varchar(50) | No | Barcode of the item (item code type 1). |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number (item code type 4). |\n| `ItemNrInt` | varchar(50) | No | Shop item number (item code type 2). |\n| `LocationStock` | bit | No | If 1, the result additionally contains the per-location columns `Locations` and `OpenOrderlineSumLocations`. |\n| `OnlyEnabledItems` | bit | No | Restricts the result to enabled items. |\n| `ExcludeBinGroups` | varchar(max) | No | Comma-separated list of bin groups whose quantities are subtracted from the stock figures. |\n| `ItemXML` | varchar(max) | No | XML list of additional items. Each `/ITEMS/ITEM` element may contain `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL` and `EAN` (max. 13 characters). |\n\n- Read-only; all tables are read `WITH (NOLOCK)`, so values may reflect uncommitted data.\n- On errors the procedure returns code `1` in addition to the status row.\n- `ItemKey` as a single parameter only matches if the item has at least one row in `pixi.ItemCode`. `ITEMKEY` values from `ItemXML` are not validated; unknown keys count as found but produce no output row, so the result can be empty without an error row.\n- An item found both via single parameters and via `ItemXML` can appear twice in the result.\n- `EAN` in `ItemXML` is read as `varchar(13)`; longer values are truncated.\n- Passing `OnlyEnabledItems` explicitly as NULL yields no rows.\n- The bin group exclusion only affects items that have a shop item number (code type 2) and whose `ItemNrInt` equals that code.\n- The order of entries inside `Locations` and `OpenOrderlineSumLocations` is not guaranteed.\n- `pixi.ItemInfoStockPerLocation` is executed even when `LocationStock` is not 1; for many items this aggregates order lines and supplier orders and can be costly. Its result depends on the settings `HalOrdersActiveDays` and `Include_FUT_StatusInOpenOrdersForSupplierOrdering`.\n- Invalid XML in `ItemXML` causes an SQL error from `sp_xml_preparedocument`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the bin locations (Lagerplätze) and quantities per batch and best-before date for one or more items identified by key, EAN, item numbers or an XML list.\n\nLooks up the stock per bin for one or more items.\n\n**Input normalisation**\n- `ItemKey` = `0` is treated as `NULL`.\n- String parameters are trimmed; empty strings are treated as `NULL`.\n- If no parameter is left, a status row with `Status` = `Error` is returned.\n\n**Finding the items** (all criteria are combined with OR, so the result is the union of all matches):\n- `EAN` is matched against item codes of type barcode (code type 1) in `ItemCode`.\n- `ItemNrInt` is matched against item codes of type shop item number (code type 2).\n- `ItemNrSuppl` is matched against item codes of type supplier item number (code type 4).\n- `ItemKey` is matched against the item ID in `ItemCode`.\n- `ItemXML` (element-centric XML, path `/ITEMS/ITEM`) can list several items. Per `ITEM`, `ITEMKEY` is taken directly, while `ITEMNRINT`, `ITEMNRSUPPL` and `EAN` are matched against the columns `ItemNrInt`, `ItemNrSuppl` and `EANUPC` of the `items` table.\n\nIf no candidate item is found, a status row `No items found with given parameters.` is returned.\n\n**Result**\nFor each found item, one row per bin, batch number and best-before date with the summed quantity from `InvBinItem`. Bin data (name, sort number, location, bin group, transport bin flag) comes from `InvBin`. Rows are sorted by `LocID` and then by `BinName` (case-insensitive). Items that are found but have no bin stock records produce no rows (empty result, no error).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal item key. `0` is treated as not set. Matched against the item ID in `ItemCode`. |\n| `EAN` | varchar(13) | No | Barcode/EAN of the item, matched against item codes of type barcode (code type 1). |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number, matched against item codes of type supplier item number (code type 4). |\n| `ItemNrInt` | varchar(50) | No | Internal/shop item number, matched against item codes of type shop item number (code type 2). |\n| `ItemXML` | varchar(max) | No | Optional XML list of items (`/ITEMS/ITEM`, element-centric). Per item, `ITEMKEY` is used directly; `ITEMNRINT`, `ITEMNRSUPPL` and `EAN` are matched against `items.ItemNrInt`, `items.ItemNrSuppl` and `items.EANUPC`. |\n\n- All reads use `NOLOCK`, so results may include uncommitted data.\n- The single parameter `ItemKey` is matched via the `ItemCode` table, not via `items`. An item without any entry in `ItemCode` is not found by `ItemKey`; use `ItemXML` with `ITEMKEY` instead, which is taken directly.\n- The single parameter `EAN` searches all barcodes of type 1 in `ItemCode`, whereas `EAN` inside `ItemXML` only matches the main EAN (`items.EANUPC`).\n- If the same item is found both through the single parameters and through `ItemXML`, it appears twice in the internal candidate list and its `Quantity` values are summed twice. Identify each item through only one route.\n- A non-existing `ITEMKEY` in the XML avoids the \"No items found\" error but simply yields no rows.\n- OPENXML element names are case-sensitive (`ITEMS`, `ITEM`, `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL`, `EAN`).\n- `BestBeforeDate` is returned as text in the format `yyyy-mm-dd hh:mi:ss.mmm`; an empty string means no date. `BatchNumber` is an empty string if no batch is set.\n- On error the procedure returns code 1 after the status row.\n\nDocumentation: https://pixi-api-docs.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": "Returns the bin locations (Lagerplätze) and quantities per batch and best-before date for one or more items identified by key, EAN, item numbers or an XML list.\n\nLooks up the stock per bin for one or more items.\n\n**Input normalisation**\n- `ItemKey` = `0` is treated as `NULL`.\n- String parameters are trimmed; empty strings are treated as `NULL`.\n- If no parameter is left, a status row with `Status` = `Error` is returned.\n\n**Finding the items** (all criteria are combined with OR, so the result is the union of all matches):\n- `EAN` is matched against item codes of type barcode (code type 1) in `ItemCode`.\n- `ItemNrInt` is matched against item codes of type shop item number (code type 2).\n- `ItemNrSuppl` is matched against item codes of type supplier item number (code type 4).\n- `ItemKey` is matched against the item ID in `ItemCode`.\n- `ItemXML` (element-centric XML, path `/ITEMS/ITEM`) can list several items. Per `ITEM`, `ITEMKEY` is taken directly, while `ITEMNRINT`, `ITEMNRSUPPL` and `EAN` are matched against the columns `ItemNrInt`, `ItemNrSuppl` and `EANUPC` of the `items` table.\n\nIf no candidate item is found, a status row `No items found with given parameters.` is returned.\n\n**Result**\nFor each found item, one row per bin, batch number and best-before date with the summed quantity from `InvBinItem`. Bin data (name, sort number, location, bin group, transport bin flag) comes from `InvBin`. Rows are sorted by `LocID` and then by `BinName` (case-insensitive). Items that are found but have no bin stock records produce no rows (empty result, no error).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal item key. `0` is treated as not set. Matched against the item ID in `ItemCode`. |\n| `EAN` | varchar(13) | No | Barcode/EAN of the item, matched against item codes of type barcode (code type 1). |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number, matched against item codes of type supplier item number (code type 4). |\n| `ItemNrInt` | varchar(50) | No | Internal/shop item number, matched against item codes of type shop item number (code type 2). |\n| `ItemXML` | varchar(max) | No | Optional XML list of items (`/ITEMS/ITEM`, element-centric). Per item, `ITEMKEY` is used directly; `ITEMNRINT`, `ITEMNRSUPPL` and `EAN` are matched against `items.ItemNrInt`, `items.ItemNrSuppl` and `items.EANUPC`. |\n\n- All reads use `NOLOCK`, so results may include uncommitted data.\n- The single parameter `ItemKey` is matched via the `ItemCode` table, not via `items`. An item without any entry in `ItemCode` is not found by `ItemKey`; use `ItemXML` with `ITEMKEY` instead, which is taken directly.\n- The single parameter `EAN` searches all barcodes of type 1 in `ItemCode`, whereas `EAN` inside `ItemXML` only matches the main EAN (`items.EANUPC`).\n- If the same item is found both through the single parameters and through `ItemXML`, it appears twice in the internal candidate list and its `Quantity` values are summed twice. Identify each item through only one route.\n- A non-existing `ITEMKEY` in the XML avoids the \"No items found\" error but simply yields no rows.\n- OPENXML element names are case-sensitive (`ITEMS`, `ITEM`, `ITEMKEY`, `ITEMNRINT`, `ITEMNRSUPPL`, `EAN`).\n- `BestBeforeDate` is returned as text in the format `yyyy-mm-dd hh:mi:ss.mmm`; an empty string means no date. `BatchNumber` is an empty string if no batch is set.\n- On error the procedure returns code 1 after the status row.\n\nDocumentation: https://pixi-api-docs.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": "Returns the bin stock movement history of one item, identified by item key, EAN, supplier item number or internal item number, with paging.\n\nReturns the stock movement log of an item per bin (Lagerplatz), similar to the bin history in the Pixi client.\n\n1. **Item lookup:** the item is searched in `items` with the filled identifiers combined by **OR**: `ItemKey` (if not 0/NULL), `EANUPC` = `EAN`, `ItemNrSuppl` or `ItemNrInt` (each only if not empty). The first match (`TOP 1`, no sort order) is used.\n2. If no item is found, a single status row with `Status` = `Error` is returned and the call ends.\n3. Otherwise the log entries of the item from `InvBinItemLog` are loaded, numbered newest first (descending log key), and the page given by `PageNumber` and `PageSize` is selected.\n4. For each entry the bin name is taken from the current bin (`InvBin`). If the bin no longer exists, the name comes from the bin history (`InvBinHist`) together with its history remark.\n5. Stock movement operation and type names are translated into the language given by `LanguageID`. `SMTName` consists of the type number, a space and the translated type name.\n6. Entries whose `UpdateEmp` is `AutoExport` are removed from the result after paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item. Ignored if NULL or 0. |\n| `EAN` | varchar(13) | No | EAN/UPC of the item (compared with `EANUPC`). Ignored if empty. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number. Ignored if empty. |\n| `ItemNrInt` | varchar(50) | No | Internal item number. Ignored if empty. |\n| `LanguageID` | int | No | Language used for translating stock movement operation and type names. |\n| `PageSize` | int | No | Number of log entries per page (before the `AutoExport` filter). |\n| `PageNumber` | int | No | Page to return, starting at 1. |\n\n- All reads use `NOLOCK`; results may contain uncommitted data.\n- If several identifiers are passed, they are combined with OR, so any matching item may be chosen. Pass only one identifier to get a predictable result.\n- The `AutoExport` filter is applied **after** paging, so a page can contain fewer rows than `PageSize`. `TotalPages` is calculated from all log entries, including the filtered ones.\n- `TotalPages` is computed as integer division of total lines by `PageSize` plus 1. If the total is an exact multiple of `PageSize`, one extra (empty) page is reported.\n- The final select has no explicit `ORDER BY`. Rows are typically, but not guaranteed, returned newest first.\n- `SMOName`/`SMTName` are NULL if no translation exists for the given `LanguageID`.\n- The procedure returns code 1 when no item is found.\n\nDocumentation: https://pixi-api-docs.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": "Returns the bin stock movement history of one item, identified by item key, EAN, supplier item number or internal item number, with paging.\n\nReturns the stock movement log of an item per bin (Lagerplatz), similar to the bin history in the Pixi client.\n\n1. **Item lookup:** the item is searched in `items` with the filled identifiers combined by **OR**: `ItemKey` (if not 0/NULL), `EANUPC` = `EAN`, `ItemNrSuppl` or `ItemNrInt` (each only if not empty). The first match (`TOP 1`, no sort order) is used.\n2. If no item is found, a single status row with `Status` = `Error` is returned and the call ends.\n3. Otherwise the log entries of the item from `InvBinItemLog` are loaded, numbered newest first (descending log key), and the page given by `PageNumber` and `PageSize` is selected.\n4. For each entry the bin name is taken from the current bin (`InvBin`). If the bin no longer exists, the name comes from the bin history (`InvBinHist`) together with its history remark.\n5. Stock movement operation and type names are translated into the language given by `LanguageID`. `SMTName` consists of the type number, a space and the translated type name.\n6. Entries whose `UpdateEmp` is `AutoExport` are removed from the result after paging.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item. Ignored if NULL or 0. |\n| `EAN` | varchar(13) | No | EAN/UPC of the item (compared with `EANUPC`). Ignored if empty. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number. Ignored if empty. |\n| `ItemNrInt` | varchar(50) | No | Internal item number. Ignored if empty. |\n| `LanguageID` | int | No | Language used for translating stock movement operation and type names. |\n| `PageSize` | int | No | Number of log entries per page (before the `AutoExport` filter). |\n| `PageNumber` | int | No | Page to return, starting at 1. |\n\n- All reads use `NOLOCK`; results may contain uncommitted data.\n- If several identifiers are passed, they are combined with OR, so any matching item may be chosen. Pass only one identifier to get a predictable result.\n- The `AutoExport` filter is applied **after** paging, so a page can contain fewer rows than `PageSize`. `TotalPages` is calculated from all log entries, including the filtered ones.\n- `TotalPages` is computed as integer division of total lines by `PageSize` plus 1. If the total is an exact multiple of `PageSize`, one extra (empty) page is reported.\n- The final select has no explicit `ORDER BY`. Rows are typically, but not guaranteed, returned newest first.\n- `SMOName`/`SMTName` are NULL if no translation exists for the given `LanguageID`.\n- The procedure returns code 1 when no item is found.\n\nDocumentation: https://pixi-api-docs.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": "Returns the physical and available stock of items per stock location plus an aggregated 'All' row per item, taking open orders or reservations into account.\n\nReturns one row per item and stock location (`ItemLocationSpecific` joined with `Location`) and, combined via `UNION`, one additional row per item with `Location` = `All`.\n\n**Settings read at runtime**\n- `HalOrdersActiveDays`: number of days that order lines in status `HAL` count as open. A value of `0` is replaced by `7`.\n- `ReservePrepaymentOrders`: if `1`, availability is calculated from reservations, otherwise from open order lines.\n\n**Per-location rows**\n- `PhysicalQTY` is the `LocationQuantity` of the item on that location.\n- `OpenOrders` is the sum of `Qty` of order lines of the item on that location with status `ANG`, or status `HAL` and an `OrderDate` within the last `HalOrdersActiveDays` days.\n- `ReservedOrders` is the number of reservation records of the item whose order line is on that location and has a non-final order state other than `EIN`, `FUT`, `FUS`.\n- `AvailQTY` = `PhysicalQTY` minus `ReservedOrders` (reservations enabled) or minus `OpenOrders` (reservations disabled).\n- `SpecialStock` is the special-stock flag of the location.\n- Filtered by `LocationId` if given.\n\n**'All' rows**\n- `PhysicalQTY` is the total item quantity (`Items.Quantity`).\n- `OpenOrders` and `ReservedOrders` are computed like above, but over all locations.\n- `AvailQTY` = total quantity minus the stock on special-stock locations (`Location.SpecialStock = 1`) minus `ReservedOrders` or `OpenOrders` (depending on the setting).\n- `SpecialStock` is always `0`.\n- `LocationId` is **not** applied to these rows, they are always returned for the selected items.\n\n**Item selection**\nThe item parameters `ItemKey`, `EAN`, `ItemNrSuppl` and `ItemNrInt` are combined with OR, and each condition is true when its parameter is `NULL`. See the notes for the consequences. No sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal item key. Only effective as a filter if all other item parameters are also set (see notes). |\n| `EAN` | varchar(13) | No | EAN/UPC of the item (`Items.EANUPC`). OR-combined with the other item parameters. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number (`Items.ItemNrSuppl`). OR-combined with the other item parameters. |\n| `ItemNrInt` | varchar(50) | No | Internal item number (`Items.ItemNrInt`). OR-combined with the other item parameters. |\n| `LocationId` | varchar(50) | No | Restricts the per-location rows to this location ID. `NULL` returns all locations. Does not affect the 'All' rows. |\n| `Quantity` | int | No | Output parameter that is never assigned by the code; it is returned unchanged. |\n\n- **Filter pitfall:** because the four item conditions are OR-combined and each is true when its parameter is `NULL`, leaving out *any* of `ItemKey`, `EAN`, `ItemNrSuppl`, `ItemNrInt` returns **all items**. Passing only `ItemKey` therefore does not restrict the result. Only when all four parameters are filled are the items returned that match at least one of them.\n- Without any filter the call returns rows for every item and location, which can be very large and slow because of the correlated subqueries per row.\n- The output parameter `Quantity` is never assigned by the code; it is returned unchanged.\n- `ReservedOrders` counts reservation records, not quantities.\n- If the setting `HalOrdersActiveDays` does not exist, the cut-off date is `NULL` and `HAL` order lines are never counted as open.\n- A code comment mentions 14 days for `HAL` orders, but the actual period comes from `HalOrdersActiveDays` (default 7 if set to 0).\n- All tables are read with `NOLOCK`, so values may include uncommitted data.\n\nDocumentation: https://pixi-api-docs.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": "Returns the physical and available stock of items per stock location plus an aggregated 'All' row per item, taking open orders or reservations into account.\n\nReturns one row per item and stock location (`ItemLocationSpecific` joined with `Location`) and, combined via `UNION`, one additional row per item with `Location` = `All`.\n\n**Settings read at runtime**\n- `HalOrdersActiveDays`: number of days that order lines in status `HAL` count as open. A value of `0` is replaced by `7`.\n- `ReservePrepaymentOrders`: if `1`, availability is calculated from reservations, otherwise from open order lines.\n\n**Per-location rows**\n- `PhysicalQTY` is the `LocationQuantity` of the item on that location.\n- `OpenOrders` is the sum of `Qty` of order lines of the item on that location with status `ANG`, or status `HAL` and an `OrderDate` within the last `HalOrdersActiveDays` days.\n- `ReservedOrders` is the number of reservation records of the item whose order line is on that location and has a non-final order state other than `EIN`, `FUT`, `FUS`.\n- `AvailQTY` = `PhysicalQTY` minus `ReservedOrders` (reservations enabled) or minus `OpenOrders` (reservations disabled).\n- `SpecialStock` is the special-stock flag of the location.\n- Filtered by `LocationId` if given.\n\n**'All' rows**\n- `PhysicalQTY` is the total item quantity (`Items.Quantity`).\n- `OpenOrders` and `ReservedOrders` are computed like above, but over all locations.\n- `AvailQTY` = total quantity minus the stock on special-stock locations (`Location.SpecialStock = 1`) minus `ReservedOrders` or `OpenOrders` (depending on the setting).\n- `SpecialStock` is always `0`.\n- `LocationId` is **not** applied to these rows, they are always returned for the selected items.\n\n**Item selection**\nThe item parameters `ItemKey`, `EAN`, `ItemNrSuppl` and `ItemNrInt` are combined with OR, and each condition is true when its parameter is `NULL`. See the notes for the consequences. No sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal item key. Only effective as a filter if all other item parameters are also set (see notes). |\n| `EAN` | varchar(13) | No | EAN/UPC of the item (`Items.EANUPC`). OR-combined with the other item parameters. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number (`Items.ItemNrSuppl`). OR-combined with the other item parameters. |\n| `ItemNrInt` | varchar(50) | No | Internal item number (`Items.ItemNrInt`). OR-combined with the other item parameters. |\n| `LocationId` | varchar(50) | No | Restricts the per-location rows to this location ID. `NULL` returns all locations. Does not affect the 'All' rows. |\n| `Quantity` | int | No | Output parameter that is never assigned by the code; it is returned unchanged. |\n\n- **Filter pitfall:** because the four item conditions are OR-combined and each is true when its parameter is `NULL`, leaving out *any* of `ItemKey`, `EAN`, `ItemNrSuppl`, `ItemNrInt` returns **all items**. Passing only `ItemKey` therefore does not restrict the result. Only when all four parameters are filled are the items returned that match at least one of them.\n- Without any filter the call returns rows for every item and location, which can be very large and slow because of the correlated subqueries per row.\n- The output parameter `Quantity` is never assigned by the code; it is returned unchanged.\n- `ReservedOrders` counts reservation records, not quantities.\n- If the setting `HalOrdersActiveDays` does not exist, the cut-off date is `NULL` and `HAL` order lines are never counted as open.\n- A code comment mentions 14 days for `HAL` orders, but the actual period comes from `HalOrdersActiveDays` (default 7 if set to 0).\n- All tables are read with `NOLOCK`, so values may include uncommitted data.\n\nDocumentation: https://pixi-api-docs.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": "Returns the physical stock of an item per location plus a total row 'All' with physical, available and really available quantities.\n\nReturns stock figures for **one item**, either on all locations or on a single location.\n\n1. **Item lookup**: if `ItemKey` is given, it is used directly. Otherwise the item is searched in `pixi.ItemCode` by `EAN`, `ItemNrSuppl` or `ItemNrInt`. A code matches if it equals any of the three values and has code type 1, 2 or 4. The first match is taken (`TOP 1`).\n2. **Total row**: from `items` one row with `Location` = `All` is built:\n - `PhysicalQTY` = item quantity\n - `AvailQTY` = quantity minus special stock (`ItemQtyIBISpecialStock_1`) minus open reservations\n - `RealQtyAvail` = quantity minus special stock minus open order lines\n - `SpecialStock` = 0\n3. **Location rows**: for every entry in `ItemLocationSpecific` of the item, one row with the location ID, the location quantity as `PhysicalQTY` and the `SpecialStock` flag of the location is returned. If `LocationId` is set (not empty), only the location with this `LocID` is returned.\n4. Location rows and the total row are combined with `UNION`, so identical rows are removed.\n\nThe `All` row is always part of the result as long as the item exists, even if `LocationId` is set. If no item is found, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item. If set, the code parameters are ignored. |\n| `EAN` | varchar(13) | No | EAN used to find the item when `ItemKey` is not set. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number used to find the item when `ItemKey` is not set. |\n| `ItemNrInt` | varchar(50) | No | Internal item number used to find the item when `ItemKey` is not set. |\n| `LocationId` | varchar(50) | No | Location ID (`LocID`) to restrict the location rows to. Empty or NULL returns all locations of the item. The `All` row is returned in any case. |\n| `Quantity` | int | No | Output parameter that is never assigned by the procedure; it returns the value passed in. |\n\n- `AvailQTY` and `RealQtyAvail` are **item-level totals**; they are repeated unchanged on every location row and are not calculated per location.\n- The output parameter `Quantity` is never assigned by the procedure; it returns only the value passed in (default `NULL`).\n- The item lookup by code uses `TOP 1` without `ORDER BY`. If several items share a code, which item is used is not deterministic. The meaning of code types 1, 2 and 4 is not defined in the code.\n- No `ORDER BY` on the result: the order of rows (including the position of the `All` row) is not guaranteed.\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n\nDocumentation: https://pixi-api-docs.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": "Returns the physical stock of an item per location plus a total row 'All' with physical, available and really available quantities.\n\nReturns stock figures for **one item**, either on all locations or on a single location.\n\n1. **Item lookup**: if `ItemKey` is given, it is used directly. Otherwise the item is searched in `pixi.ItemCode` by `EAN`, `ItemNrSuppl` or `ItemNrInt`. A code matches if it equals any of the three values and has code type 1, 2 or 4. The first match is taken (`TOP 1`).\n2. **Total row**: from `items` one row with `Location` = `All` is built:\n - `PhysicalQTY` = item quantity\n - `AvailQTY` = quantity minus special stock (`ItemQtyIBISpecialStock_1`) minus open reservations\n - `RealQtyAvail` = quantity minus special stock minus open order lines\n - `SpecialStock` = 0\n3. **Location rows**: for every entry in `ItemLocationSpecific` of the item, one row with the location ID, the location quantity as `PhysicalQTY` and the `SpecialStock` flag of the location is returned. If `LocationId` is set (not empty), only the location with this `LocID` is returned.\n4. Location rows and the total row are combined with `UNION`, so identical rows are removed.\n\nThe `All` row is always part of the result as long as the item exists, even if `LocationId` is set. If no item is found, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item. If set, the code parameters are ignored. |\n| `EAN` | varchar(13) | No | EAN used to find the item when `ItemKey` is not set. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number used to find the item when `ItemKey` is not set. |\n| `ItemNrInt` | varchar(50) | No | Internal item number used to find the item when `ItemKey` is not set. |\n| `LocationId` | varchar(50) | No | Location ID (`LocID`) to restrict the location rows to. Empty or NULL returns all locations of the item. The `All` row is returned in any case. |\n| `Quantity` | int | No | Output parameter that is never assigned by the procedure; it returns the value passed in. |\n\n- `AvailQTY` and `RealQtyAvail` are **item-level totals**; they are repeated unchanged on every location row and are not calculated per location.\n- The output parameter `Quantity` is never assigned by the procedure; it returns only the value passed in (default `NULL`).\n- The item lookup by code uses `TOP 1` without `ORDER BY`. If several items share a code, which item is used is not deterministic. The meaning of code types 1, 2 and 4 is not defined in the code.\n- No `ORDER BY` on the result: the order of rows (including the position of the `All` row) is not guaranteed.\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n\nDocumentation: https://pixi-api-docs.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": "Returns master data of the stock locations, either all visible locations or one location selected by its ID.\n\nReturns one row per stock location from the `Location` table. Each row holds the address data, the shipping flag, reservation and transfer settings, and a flag that tells whether the location is used as a POS location.\n\nFiltering:\n\n- If `LocID` is omitted, `NULL` or an empty string, all locations with `ShowLocation <> 0` (visible locations) are returned.\n- If `LocID` is set, only the location with this ID is returned. The `ShowLocation` filter is **not** applied in this case, so hidden locations are returned as well.\n\n`IsPosLocation` is `'1'` if at least one record in `POSheader2` references the location through `PHlocID`. Otherwise it is `'0'`.\n\nThe result has no `ORDER BY`, so the row order is not guaranteed.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | No | ID of the location to return. Empty or `NULL` returns all visible locations. |\n\n- `Location` is read with `NOLOCK`, so uncommitted changes can appear in the result. The subquery on `POSheader2` uses no locking hint.\n- Because `AND` binds more strongly than `OR` in the `WHERE` clause, the visibility filter `ShowLocation <> 0` applies only when no `LocID` is passed. A query for a single hidden location therefore still returns that location.\n- An unknown `LocID` returns an empty result set. No error is raised.\n\nDocumentation: https://pixi-api-docs.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": "Returns master data of the stock locations, either all visible locations or one location selected by its ID.\n\nReturns one row per stock location from the `Location` table. Each row holds the address data, the shipping flag, reservation and transfer settings, and a flag that tells whether the location is used as a POS location.\n\nFiltering:\n\n- If `LocID` is omitted, `NULL` or an empty string, all locations with `ShowLocation <> 0` (visible locations) are returned.\n- If `LocID` is set, only the location with this ID is returned. The `ShowLocation` filter is **not** applied in this case, so hidden locations are returned as well.\n\n`IsPosLocation` is `'1'` if at least one record in `POSheader2` references the location through `PHlocID`. Otherwise it is `'0'`.\n\nThe result has no `ORDER BY`, so the row order is not guaranteed.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | No | ID of the location to return. Empty or `NULL` returns all visible locations. |\n\n- `Location` is read with `NOLOCK`, so uncommitted changes can appear in the result. The subquery on `POSheader2` uses no locking hint.\n- Because `AND` binds more strongly than `OR` in the `WHERE` clause, the visibility filter `ShowLocation <> 0` applies only when no `LocID` is passed. A query for a single hidden location therefore still returns that location.\n- An unknown `LocID` returns an empty result set. No error is raised.\n\nDocumentation: https://pixi-api-docs.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": "Returns items whose recommended minimum stock or minimum order quantity, based on recent sales, differs from the current setting by at least a given ratio.\n\nCalculates disposition recommendations per item for one stock location and returns only items where the change is significant. The result is sorted and paged.\n\n**Input normalisation**\n- `0` for `HistoryDays`, `SecurityDays`, `ShowChangesAbovePercentage` and `Rows` is replaced by the default value. `ConfigtypeKey` = `0` and empty strings for the text and XML parameters are treated as `NULL`.\n- If `Location` is empty, the first location with `ShowLocation = 1` is used.\n- `SortColumn` and `SortDirection` are converted to lowercase.\n\n**Sales source (`Pos` / `Shops`)**\n- Only `Shops` set: sales from order lines only.\n- Only `Pos` set: sales from closed POS receipts only.\n- Both or none set: order lines plus POS sales.\nThe content of `Pos` is never read. `Shops` is parsed, but the shop list is not used to filter the data.\n\n**Item filters**\nThe filters are applied in this order and build a list of item keys:\n1. `Categories` (`/CATS/CAT/CatId`, mapped via `TontrArten` to `items.ConfigType`).\n2. `Suppliers` (`/SUPPLIERS/SUP/SupplNr`), intersected with the previous list.\n3. `Tags` (`/TAGS/TAG` with `TAGKEY` and `TAGTYPE`): `a` = item must have all these tags, `o` = item must have at least one, `n` = item must not have the tag. Matching items are added to the list.\n4. `ConfigtypeKey` (enabled items with this `ConfigType`), intersected with the list if it is not empty.\n5. `SupplNR`, intersected with the list if it is not empty.\n\nDisabled items are then removed. If no filter is given, all enabled items are evaluated.\n\n**Calculation per item**\n- `MinStockQty` / `MinOrderQty`: current values from `ItemLocationSpecific` for `Location`.\n- `Quantity`: sum of `LocationQuantity` over the locations in `Locations` (default: all locations with `ShowLocation = 1`).\n- `DailyQty`: quantity sold in the last `HistoryDays` days at `Location` (order lines with status `AUS`, POS receipts with status `CLO`) divided by `HistoryDays`. `DailyQtyBefore`: the same for the previous period of equal length. `Trend` is `+`, `-` or a blank.\n- `RecommendedMinStockQty` = FLOOR(`DailyQty` × (delivery days + `SecurityDays`)); delivery days default to 7 if the supplier has none.\n- `RecommendedMinOrderQty` = FLOOR(`DailyQty` × `DesiredStockTurnOver`); a result of 1 is set to 0. Negative recommendations are returned as 0.\n- `ChangeMinStockQty` / `ChangeMinOrderQty`: relative change (recommended − current) / current; if the current value is 0 and a recommendation exists, 1.\n- `StockTurnover` = FLOOR(`Quantity` / `DailyQty`), 0 without sales.\n- `NumOfOrders`: number of distinct orders / POS receipts in the period over the `Locations` list.\n\n**Selection, sorting and paging**\nOnly items with ABS(`ChangeMinStockQty`) or ABS(`ChangeMinOrderQty`) ≥ `ShowChangesAbovePercentage` are kept. They are numbered (`RowNr`) by `SortColumn` / `SortDirection`, then by `ItemName` ascending. Rows with `RowNr` > `Start`, `RowNr` ≤ `Start` + `Rows` and `ItemKey` > `ItemKeyStart` are returned, together with `TotalRows` (all matching items) and `NrOfRecordsLeft` (rows after `Start` with `ItemKey` > `ItemKeyStart`).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `HistoryDays` | int | No | Length of the sales period in days used to calculate the daily quantity. The previous period of the same length is used for `DailyQtyBefore`. `0` means default. |\n| `SecurityDays` | int | No | Safety days added to the supplier delivery days when calculating the recommended minimum stock. `0` means default. |\n| `DesiredStockTurnOver` | int | No | Number of days of sales one order should cover; used for the recommended minimum order quantity. |\n| `ShowChangesAbovePercentage` | float | No | Minimum relative change (e.g. `0.1` = 10 %) of minimum stock or minimum order quantity for an item to be returned. `0` means default. |\n| `SupplNR` | varchar(4) | No | Restricts the result to items of this supplier number. |\n| `Rows` | int | No | Page size: maximum number of rows returned. `0` means default. |\n| `ItemKeyStart` | int | No | Only rows with `ItemKey` greater than this value are returned. |\n| `ConfigtypeKey` | int | No | Restricts the result to items with this `ConfigType`. `0` is treated as `NULL`. |\n| `Tags` | varchar(max) | No | XML list of tag filters `/TAGS/TAG` with `TAGKEY` and `TAGTYPE` (`a` = must have all, `o` = must have one, `n` = must not have). |\n| `SortColumn` | varchar(50) | No | Column used for sorting and `RowNr`. Case is ignored. Unknown values sort by `ItemName`. |\n| `SortDirection` | varchar(1) | No | Sort direction. Case is ignored. |\n| `Start` | int | No | Paging offset: rows with `RowNr` greater than this value are returned. |\n| `Suppliers` | varchar(max) | No | XML list of supplier numbers `/SUPPLIERS/SUP/SupplNr`; only items of these suppliers are evaluated. |\n| `Categories` | varchar(max) | No | XML list of category keys `/CATS/CAT/CatId` (`TontrArtKey`); only items whose `ConfigType` matches are evaluated. |\n| `Locations` | varchar(max) | No | XML list of location IDs `/LOCATIONS/LOC/LocationID` used for `Quantity` and `NumOfOrders`. Default: all locations with `ShowLocation = 1`. |\n| `Shops` | varchar(max) | No | XML list `/SHOPS/SHOP/ShopID`. Only its presence matters: together with `Pos` it selects the sales source (see description). The shop IDs do not filter the data. |\n| `Pos` | varchar(max) | No | Flag for POS sales: any non-empty value counts as set; the content is not read. Together with `Shops` it selects the sales source. |\n| `Location` | varchar(max) | No | Location ID for the current minimum values and the sales figures. Default: first location with `ShowLocation = 1`. |\n\n- Read-only; all permanent tables are read `WITH (NOLOCK)`, so uncommitted data can appear. The call computes several aggregates per item over `Orderlines` and `POSitem2`/`POSheader2` and can be slow on large databases; use filters.\n- **Bug:** in the default mode (order lines plus POS) `ChangeMinOrderQty` is always `NULL` because the code checks the POS-only case twice. Then only `ChangeMinStockQty` decides whether an item is returned.\n- Items without an `ItemLocationSpecific` row for `Location`, or without any row in the `Locations` list, are not returned.\n- The previous period excludes the day exactly `HistoryDays` days ago.\n- `Tags` adds items to the list instead of intersecting it with `Categories`/`Suppliers`. A filter with only `n` tags returns no items as soon as any item carries one of these tags.\n- If `Categories` or `Suppliers` match no item and no `Tags`, `ConfigtypeKey` or `SupplNR` is given, the filter is ignored and all enabled items are evaluated.\n- `SortColumn` is lowercased and compared with mixed-case names; sorting works only with a case-insensitive database collation. Unknown values sort by `ItemName`.\n- `DesiredStockTurnOver` = `0` is not replaced by the default and leads to recommended order quantities of 0.\n- Invalid XML in the XML parameters causes a SQL error from `sp_xml_preparedocument`.\n- To apply a recommendation, use `pixiSetItemBuyingInfo`.\n\nDocumentation: https://pixi-api-docs.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": "Returns items whose recommended minimum stock or minimum order quantity, based on recent sales, differs from the current setting by at least a given ratio.\n\nCalculates disposition recommendations per item for one stock location and returns only items where the change is significant. The result is sorted and paged.\n\n**Input normalisation**\n- `0` for `HistoryDays`, `SecurityDays`, `ShowChangesAbovePercentage` and `Rows` is replaced by the default value. `ConfigtypeKey` = `0` and empty strings for the text and XML parameters are treated as `NULL`.\n- If `Location` is empty, the first location with `ShowLocation = 1` is used.\n- `SortColumn` and `SortDirection` are converted to lowercase.\n\n**Sales source (`Pos` / `Shops`)**\n- Only `Shops` set: sales from order lines only.\n- Only `Pos` set: sales from closed POS receipts only.\n- Both or none set: order lines plus POS sales.\nThe content of `Pos` is never read. `Shops` is parsed, but the shop list is not used to filter the data.\n\n**Item filters**\nThe filters are applied in this order and build a list of item keys:\n1. `Categories` (`/CATS/CAT/CatId`, mapped via `TontrArten` to `items.ConfigType`).\n2. `Suppliers` (`/SUPPLIERS/SUP/SupplNr`), intersected with the previous list.\n3. `Tags` (`/TAGS/TAG` with `TAGKEY` and `TAGTYPE`): `a` = item must have all these tags, `o` = item must have at least one, `n` = item must not have the tag. Matching items are added to the list.\n4. `ConfigtypeKey` (enabled items with this `ConfigType`), intersected with the list if it is not empty.\n5. `SupplNR`, intersected with the list if it is not empty.\n\nDisabled items are then removed. If no filter is given, all enabled items are evaluated.\n\n**Calculation per item**\n- `MinStockQty` / `MinOrderQty`: current values from `ItemLocationSpecific` for `Location`.\n- `Quantity`: sum of `LocationQuantity` over the locations in `Locations` (default: all locations with `ShowLocation = 1`).\n- `DailyQty`: quantity sold in the last `HistoryDays` days at `Location` (order lines with status `AUS`, POS receipts with status `CLO`) divided by `HistoryDays`. `DailyQtyBefore`: the same for the previous period of equal length. `Trend` is `+`, `-` or a blank.\n- `RecommendedMinStockQty` = FLOOR(`DailyQty` × (delivery days + `SecurityDays`)); delivery days default to 7 if the supplier has none.\n- `RecommendedMinOrderQty` = FLOOR(`DailyQty` × `DesiredStockTurnOver`); a result of 1 is set to 0. Negative recommendations are returned as 0.\n- `ChangeMinStockQty` / `ChangeMinOrderQty`: relative change (recommended − current) / current; if the current value is 0 and a recommendation exists, 1.\n- `StockTurnover` = FLOOR(`Quantity` / `DailyQty`), 0 without sales.\n- `NumOfOrders`: number of distinct orders / POS receipts in the period over the `Locations` list.\n\n**Selection, sorting and paging**\nOnly items with ABS(`ChangeMinStockQty`) or ABS(`ChangeMinOrderQty`) ≥ `ShowChangesAbovePercentage` are kept. They are numbered (`RowNr`) by `SortColumn` / `SortDirection`, then by `ItemName` ascending. Rows with `RowNr` > `Start`, `RowNr` ≤ `Start` + `Rows` and `ItemKey` > `ItemKeyStart` are returned, together with `TotalRows` (all matching items) and `NrOfRecordsLeft` (rows after `Start` with `ItemKey` > `ItemKeyStart`).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `HistoryDays` | int | No | Length of the sales period in days used to calculate the daily quantity. The previous period of the same length is used for `DailyQtyBefore`. `0` means default. |\n| `SecurityDays` | int | No | Safety days added to the supplier delivery days when calculating the recommended minimum stock. `0` means default. |\n| `DesiredStockTurnOver` | int | No | Number of days of sales one order should cover; used for the recommended minimum order quantity. |\n| `ShowChangesAbovePercentage` | float | No | Minimum relative change (e.g. `0.1` = 10 %) of minimum stock or minimum order quantity for an item to be returned. `0` means default. |\n| `SupplNR` | varchar(4) | No | Restricts the result to items of this supplier number. |\n| `Rows` | int | No | Page size: maximum number of rows returned. `0` means default. |\n| `ItemKeyStart` | int | No | Only rows with `ItemKey` greater than this value are returned. |\n| `ConfigtypeKey` | int | No | Restricts the result to items with this `ConfigType`. `0` is treated as `NULL`. |\n| `Tags` | varchar(max) | No | XML list of tag filters `/TAGS/TAG` with `TAGKEY` and `TAGTYPE` (`a` = must have all, `o` = must have one, `n` = must not have). |\n| `SortColumn` | varchar(50) | No | Column used for sorting and `RowNr`. Case is ignored. Unknown values sort by `ItemName`. |\n| `SortDirection` | varchar(1) | No | Sort direction. Case is ignored. |\n| `Start` | int | No | Paging offset: rows with `RowNr` greater than this value are returned. |\n| `Suppliers` | varchar(max) | No | XML list of supplier numbers `/SUPPLIERS/SUP/SupplNr`; only items of these suppliers are evaluated. |\n| `Categories` | varchar(max) | No | XML list of category keys `/CATS/CAT/CatId` (`TontrArtKey`); only items whose `ConfigType` matches are evaluated. |\n| `Locations` | varchar(max) | No | XML list of location IDs `/LOCATIONS/LOC/LocationID` used for `Quantity` and `NumOfOrders`. Default: all locations with `ShowLocation = 1`. |\n| `Shops` | varchar(max) | No | XML list `/SHOPS/SHOP/ShopID`. Only its presence matters: together with `Pos` it selects the sales source (see description). The shop IDs do not filter the data. |\n| `Pos` | varchar(max) | No | Flag for POS sales: any non-empty value counts as set; the content is not read. Together with `Shops` it selects the sales source. |\n| `Location` | varchar(max) | No | Location ID for the current minimum values and the sales figures. Default: first location with `ShowLocation = 1`. |\n\n- Read-only; all permanent tables are read `WITH (NOLOCK)`, so uncommitted data can appear. The call computes several aggregates per item over `Orderlines` and `POSitem2`/`POSheader2` and can be slow on large databases; use filters.\n- **Bug:** in the default mode (order lines plus POS) `ChangeMinOrderQty` is always `NULL` because the code checks the POS-only case twice. Then only `ChangeMinStockQty` decides whether an item is returned.\n- Items without an `ItemLocationSpecific` row for `Location`, or without any row in the `Locations` list, are not returned.\n- The previous period excludes the day exactly `HistoryDays` days ago.\n- `Tags` adds items to the list instead of intersecting it with `Categories`/`Suppliers`. A filter with only `n` tags returns no items as soon as any item carries one of these tags.\n- If `Categories` or `Suppliers` match no item and no `Tags`, `ConfigtypeKey` or `SupplNR` is given, the filter is ignored and all enabled items are evaluated.\n- `SortColumn` is lowercased and compared with mixed-case names; sorting works only with a case-insensitive database collation. Unknown values sort by `ItemName`.\n- `DesiredStockTurnOver` = `0` is not replaced by the default and leads to recommended order quantities of 0.\n- Invalid XML in the XML parameters causes a SQL error from `sp_xml_preparedocument`.\n- To apply a recommendation, use `pixiSetItemBuyingInfo`.\n\nDocumentation: https://pixi-api-docs.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": "Returns the physical stock quantity of one item at one location, identifying the item by item key, EAN, supplier item number or internal item number.\n\nScalar function that returns a single integer: the value of `LocationQuantity` from the location-specific item data for the given location.\n\nSteps:\n\n1. The item identifiers are normalised: `ItemKey` = `0` and empty strings for `EAN`, `ItemNrSuppl` and `ItemNrInt` are treated as not set (`NULL`).\n2. Location-specific item records (`ItemLocationSpecific`) are joined with the item master (`Items`) and filtered on `LocID` = `LocationId`.\n3. A record matches if **any** of the supplied identifiers matches: `ItemKey`, `EANUPC` = `EAN`, `ItemNrSuppl` or `ItemNrInt`. The identifiers are combined with OR, not AND.\n4. The `LocationQuantity` of the matching record is returned as `Result`.\n\nIf no record matches, or no identifier is supplied, the result is `NULL`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item. `0` is treated as not set. |\n| `EAN` | varchar(13) | No | EAN/UPC of the item, compared with `EANUPC`. Empty string is treated as not set. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number. Empty string is treated as not set. |\n| `ItemNrInt` | varchar(50) | No | Internal item number. Empty string is treated as not set. |\n| `LocationId` | char(50) | Yes | Location (warehouse) ID, compared with `LocID` of the location-specific item data. |\n\n- Reads with `NOLOCK`, so the value may reflect uncommitted changes.\n- Because the identifiers are combined with OR, passing several identifiers that belong to different Artikel can match more than one record. In that case the function returns the quantity of one of them, and which one is not defined (no sort order). Pass only one identifier, ideally `ItemKey`, to get a deterministic result.\n- `EAN`, `ItemNrSuppl` or `ItemNrInt` may not be unique across items; the same ambiguity applies then.\n- `LocationId` has no default and must always be supplied.\n- The function returns the stored `LocationQuantity` only; it does not subtract reservations or open orders.\n\nDocumentation: https://pixi-api-docs.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": "Returns the physical stock quantity of one item at one location, identifying the item by item key, EAN, supplier item number or internal item number.\n\nScalar function that returns a single integer: the value of `LocationQuantity` from the location-specific item data for the given location.\n\nSteps:\n\n1. The item identifiers are normalised: `ItemKey` = `0` and empty strings for `EAN`, `ItemNrSuppl` and `ItemNrInt` are treated as not set (`NULL`).\n2. Location-specific item records (`ItemLocationSpecific`) are joined with the item master (`Items`) and filtered on `LocID` = `LocationId`.\n3. A record matches if **any** of the supplied identifiers matches: `ItemKey`, `EANUPC` = `EAN`, `ItemNrSuppl` or `ItemNrInt`. The identifiers are combined with OR, not AND.\n4. The `LocationQuantity` of the matching record is returned as `Result`.\n\nIf no record matches, or no identifier is supplied, the result is `NULL`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item. `0` is treated as not set. |\n| `EAN` | varchar(13) | No | EAN/UPC of the item, compared with `EANUPC`. Empty string is treated as not set. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number. Empty string is treated as not set. |\n| `ItemNrInt` | varchar(50) | No | Internal item number. Empty string is treated as not set. |\n| `LocationId` | char(50) | Yes | Location (warehouse) ID, compared with `LocID` of the location-specific item data. |\n\n- Reads with `NOLOCK`, so the value may reflect uncommitted changes.\n- Because the identifiers are combined with OR, passing several identifiers that belong to different Artikel can match more than one record. In that case the function returns the quantity of one of them, and which one is not defined (no sort order). Pass only one identifier, ideally `ItemKey`, to get a deterministic result.\n- `EAN`, `ItemNrSuppl` or `ItemNrInt` may not be unique across items; the same ambiguity applies then.\n- `LocationId` has no default and must always be supplied.\n- The function returns the stored `LocationQuantity` only; it does not subtract reservations or open orders.\n\nDocumentation: https://pixi-api-docs.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": "Returns the detail lines of a finished pick list, including its split pick lists, with bin, item, batch and order data for the Pico picking app.\n\nReturns one row per picking position of the pick list `PLHkey`. The call passes the key to an internal procedure, `Pixi_GetPickListDetailForPico`, and does not change its default filters.\n\n**Which pick lists are included**\n- The pick list header with `PLHkey` = `@PLHkey`.\n- All split pick lists whose `PLHOriginalKey` = `@PLHkey`.\n- Only headers with `ExecutionFinished = 1`.\n- Headers of every picking status.\n\n**How rows are built**\n- Pick list items (`PLitem`) are grouped into one row per combination of:\n - pick list header, order line and bin (`InvBinItem.BinRef`);\n - batch number and best-before date;\n - item (`BinItemRef`) and `pliBinRef`.\n- `Qty` is the number of pick list item records in the group; each record stands for one piece.\n- `MinPlItemKey` is the smallest `PLIkey` in the group.\n- Each row is enriched with data from:\n - the bin: name, sort number, bin group;\n - the pick list header: expiry date, creation date and employee, comment, box range, picking status code, original key;\n - the order line: order number and external order number;\n - the item: names, numbers, picture links, manufacturer (`items.Artist`), tags and packing unit.\n\n**Computed columns**\n- `ItemName` is the item name prefixed by an item number in upper case plus a space. The setting `PickListNumberColumn` selects the number: `EANUPC`, `ItemNrInt` or `ItemNrSuppl`. Any other value or no setting gives no prefix.\n- `OtherItemsCount` counts the `InvBinItem` records in the same bin that belong to a different item.\n- `DistinctBins` is the number of distinct bins over all rows of the result. It is the same value in every row.\n- `ItemTags` lists the item's tag names. Each name ends with a comma, and the names are separated by spaces, e.g. `Fragile, Heavy,`.\n- `BestBeforeDate_Text` is the best-before date formatted as `dd.mm.yyyy`.\n- `OrderUnit` is `items.OrderUnit` converted to an integer. It is `NULL` if the value is empty or not numeric.\n\n**Swapped item number columns**\n- `ItemNrInt` contains the **supplier item number** (`ItemNrSuppl`). This keeps backward compatibility.\n- `ItemNrInt1` contains the **internal item number**.\n\nIf the pick list does not exist or is not finished, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PLHkey` | int | Yes | Key of the pick list header (`PLHeader.PLHkey`). Split pick lists created from it are included. |\n\n- **Order not guaranteed:** the internal procedure sorts by `BinGroup`, `BinSortNum`, `BinItemRef` descending and then header creation date. Its rows are buffered in a temporary table, and the final `SELECT` has no `ORDER BY`, so the delivered row order is not guaranteed. Sort on the client if needed.\n- **Read-only:** all tables are read with `NOLOCK`, so uncommitted data can appear.\n- **Runtime setting:** the prefix in `ItemName` depends on the setting `PickListNumberColumn`. It is read through `fpixi_GetSetting`, whose definition is not attached.\n- **Column order:** `OrderUnit` is appended as the last column so that consumers reading by position are not affected.\n- **Truncation risk:** the intermediate temporary table limits some columns, e.g. `EanUpc` to 13 and `ItemNrSuppl` to 50 characters. Longer source values may lead to a truncation error.\n- **Other filters not exposed:** the internal picking-status filter and the option to exclude split pick lists are not available through this call.\n\nDocumentation: https://pixi-api-docs.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": "Returns the detail lines of a finished pick list, including its split pick lists, with bin, item, batch and order data for the Pico picking app.\n\nReturns one row per picking position of the pick list `PLHkey`. The call passes the key to an internal procedure, `Pixi_GetPickListDetailForPico`, and does not change its default filters.\n\n**Which pick lists are included**\n- The pick list header with `PLHkey` = `@PLHkey`.\n- All split pick lists whose `PLHOriginalKey` = `@PLHkey`.\n- Only headers with `ExecutionFinished = 1`.\n- Headers of every picking status.\n\n**How rows are built**\n- Pick list items (`PLitem`) are grouped into one row per combination of:\n - pick list header, order line and bin (`InvBinItem.BinRef`);\n - batch number and best-before date;\n - item (`BinItemRef`) and `pliBinRef`.\n- `Qty` is the number of pick list item records in the group; each record stands for one piece.\n- `MinPlItemKey` is the smallest `PLIkey` in the group.\n- Each row is enriched with data from:\n - the bin: name, sort number, bin group;\n - the pick list header: expiry date, creation date and employee, comment, box range, picking status code, original key;\n - the order line: order number and external order number;\n - the item: names, numbers, picture links, manufacturer (`items.Artist`), tags and packing unit.\n\n**Computed columns**\n- `ItemName` is the item name prefixed by an item number in upper case plus a space. The setting `PickListNumberColumn` selects the number: `EANUPC`, `ItemNrInt` or `ItemNrSuppl`. Any other value or no setting gives no prefix.\n- `OtherItemsCount` counts the `InvBinItem` records in the same bin that belong to a different item.\n- `DistinctBins` is the number of distinct bins over all rows of the result. It is the same value in every row.\n- `ItemTags` lists the item's tag names. Each name ends with a comma, and the names are separated by spaces, e.g. `Fragile, Heavy,`.\n- `BestBeforeDate_Text` is the best-before date formatted as `dd.mm.yyyy`.\n- `OrderUnit` is `items.OrderUnit` converted to an integer. It is `NULL` if the value is empty or not numeric.\n\n**Swapped item number columns**\n- `ItemNrInt` contains the **supplier item number** (`ItemNrSuppl`). This keeps backward compatibility.\n- `ItemNrInt1` contains the **internal item number**.\n\nIf the pick list does not exist or is not finished, the result set is empty.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PLHkey` | int | Yes | Key of the pick list header (`PLHeader.PLHkey`). Split pick lists created from it are included. |\n\n- **Order not guaranteed:** the internal procedure sorts by `BinGroup`, `BinSortNum`, `BinItemRef` descending and then header creation date. Its rows are buffered in a temporary table, and the final `SELECT` has no `ORDER BY`, so the delivered row order is not guaranteed. Sort on the client if needed.\n- **Read-only:** all tables are read with `NOLOCK`, so uncommitted data can appear.\n- **Runtime setting:** the prefix in `ItemName` depends on the setting `PickListNumberColumn`. It is read through `fpixi_GetSetting`, whose definition is not attached.\n- **Column order:** `OrderUnit` is appended as the last column so that consumers reading by position are not affected.\n- **Truncation risk:** the intermediate temporary table limits some columns, e.g. `EanUpc` to 13 and `ItemNrSuppl` to 50 characters. Longer source values may lead to a truncation error.\n- **Other filters not exposed:** the internal picking-status filter and the option to exclude split pick lists are not available through this call.\n\nDocumentation: https://pixi-api-docs.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": "Returns stock relocations of items between locations (take-out and put-in pairs) from the bin item log within a date range of at most 31 days, with paging.\n\nReturns stock movements created when items are relocated from one location to another.\n\n1. **Defaults and cleanup**: if `ChangeDateFrom` is empty, the start of the current month (00:00) is used; if `ChangeDateTo` is empty, the end of the current day (23:59:59.997) is used. `FromLocation` and `ToLocation` are trimmed; empty strings are treated as \"no filter\".\n2. **Validation**: if the period between `ChangeDateFrom` and `ChangeDateTo` is more than 31 days (counted as day boundaries), a single status row with `Status` = `Error` is returned and the call ends.\n3. **Candidates**: from the bin item log, all entries with `UpdateDate` within the period are read in two groups:\n - take-out entries (`SMTRef` = 19, `SMORef` = 11),\n - put-in entries (`SMTRef` = 11, `SMORef` = 12).\n Each group is numbered separately in the order of the log key.\n4. **Pairing**: the n-th take-out entry is paired with the n-th put-in entry. Only pairs where a put-in entry exists and the item of the take-out entry exists in the item master are returned. `FromLocation` is the location of the take-out entry, `ToLocation` the location of the put-in entry.\n5. **Location filters**: `FromLocation` filters on the source location, `ToLocation` on the target location; both can be combined.\n6. **Paging**: the remaining rows are numbered again (in log key order) in `RowNumber`. The call returns at most `RowCount` rows with `RowNumber` > `Offset`, sorted by `RowNumber`.\n\n`Qty` is the quantity of the take-out entry multiplied by -1, i.e. the relocated quantity as a positive number.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromLocation` | varchar(3) | No | Source location (location ID of the take-out entry). Empty or NULL means all source locations. |\n| `ToLocation` | varchar(3) | No | Target location (location ID of the put-in entry). Empty or NULL means all target locations. |\n| `ChangeDateFrom` | datetime | No | Start of the period (inclusive) on `UpdateDate`. NULL means the start of the current month. |\n| `ChangeDateTo` | datetime | No | End of the period (inclusive) on `UpdateDate`. NULL means the end of the current day. The period may not exceed 31 days. |\n| `Offset` | int | No | Number of rows to skip; rows with `RowNumber` greater than this value are returned. |\n| `RowCount` | int | No | Maximum number of rows returned. |\n\n- Take-out and put-in entries are paired **by position only** (n-th take-out with n-th put-in in log key order), not by item or relocation document. If the numbers of take-out and put-in entries in the period differ, or a relocation spans the period boundary, pairs can be shifted and `ToLocation` may belong to another movement.\n- The meaning of the codes `SMTRef`/`SMORef` (19/11 and 11/12) is not documented in the code; the interpretation as take-out/put-in comes from the temporary table names.\n- If `ChangeDateTo` is passed as a date without time, it means midnight at the start of that day, so movements later that day are excluded.\n- All reads use `NOLOCK`, so uncommitted data can appear.\n- The helper procedures `util.IndexCreate` and `util.TempTableDrop` are used for temporary tables only; their definitions are not attached.\n- `RowNumber` is computed after the location filters, so paging with `Offset` is consistent for the same filter values.\n\nDocumentation: https://pixi-api-docs.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": "Returns stock relocations of items between locations (take-out and put-in pairs) from the bin item log within a date range of at most 31 days, with paging.\n\nReturns stock movements created when items are relocated from one location to another.\n\n1. **Defaults and cleanup**: if `ChangeDateFrom` is empty, the start of the current month (00:00) is used; if `ChangeDateTo` is empty, the end of the current day (23:59:59.997) is used. `FromLocation` and `ToLocation` are trimmed; empty strings are treated as \"no filter\".\n2. **Validation**: if the period between `ChangeDateFrom` and `ChangeDateTo` is more than 31 days (counted as day boundaries), a single status row with `Status` = `Error` is returned and the call ends.\n3. **Candidates**: from the bin item log, all entries with `UpdateDate` within the period are read in two groups:\n - take-out entries (`SMTRef` = 19, `SMORef` = 11),\n - put-in entries (`SMTRef` = 11, `SMORef` = 12).\n Each group is numbered separately in the order of the log key.\n4. **Pairing**: the n-th take-out entry is paired with the n-th put-in entry. Only pairs where a put-in entry exists and the item of the take-out entry exists in the item master are returned. `FromLocation` is the location of the take-out entry, `ToLocation` the location of the put-in entry.\n5. **Location filters**: `FromLocation` filters on the source location, `ToLocation` on the target location; both can be combined.\n6. **Paging**: the remaining rows are numbered again (in log key order) in `RowNumber`. The call returns at most `RowCount` rows with `RowNumber` > `Offset`, sorted by `RowNumber`.\n\n`Qty` is the quantity of the take-out entry multiplied by -1, i.e. the relocated quantity as a positive number.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromLocation` | varchar(3) | No | Source location (location ID of the take-out entry). Empty or NULL means all source locations. |\n| `ToLocation` | varchar(3) | No | Target location (location ID of the put-in entry). Empty or NULL means all target locations. |\n| `ChangeDateFrom` | datetime | No | Start of the period (inclusive) on `UpdateDate`. NULL means the start of the current month. |\n| `ChangeDateTo` | datetime | No | End of the period (inclusive) on `UpdateDate`. NULL means the end of the current day. The period may not exceed 31 days. |\n| `Offset` | int | No | Number of rows to skip; rows with `RowNumber` greater than this value are returned. |\n| `RowCount` | int | No | Maximum number of rows returned. |\n\n- Take-out and put-in entries are paired **by position only** (n-th take-out with n-th put-in in log key order), not by item or relocation document. If the numbers of take-out and put-in entries in the period differ, or a relocation spans the period boundary, pairs can be shifted and `ToLocation` may belong to another movement.\n- The meaning of the codes `SMTRef`/`SMORef` (19/11 and 11/12) is not documented in the code; the interpretation as take-out/put-in comes from the temporary table names.\n- If `ChangeDateTo` is passed as a date without time, it means midnight at the start of that day, so movements later that day are excluded.\n- All reads use `NOLOCK`, so uncommitted data can appear.\n- The helper procedures `util.IndexCreate` and `util.TempTableDrop` are used for temporary tables only; their definitions are not attached.\n- `RowNumber` is computed after the location filters, so paging with `Offset` is consistent for the same filter values.\n\nDocumentation: https://pixi-api-docs.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": "Returns the stock bins (Lagerplätze), optionally filtered by location and bin group, with the total quantity stored on each bin and optional paging.\n\nReads the stock bins from `InvBin` and calculates for each bin the sum of `BinItemQTY` of all entries in `InvBinItem` on this bin (`NrOfItemOnBin`, 0 if the bin is empty).\n\nFilters:\n- `LocID`: only bins of this location (`BinLocID`). Empty string or NULL means all locations.\n- `BinGroup`: only bins of this bin group. Empty string or NULL means all groups.\n\nPaging:\n- If `RowCount` is 0 or NULL, all matching bins are returned without a `RowNr` column.\n- If `RowCount` is greater than 0, the rows are numbered by `BinSortNum` (`RowNr`), and at most `RowCount` rows with `RowNr` greater than `Start` are returned. `Start` is therefore the number of rows to skip.\n\nThe result is always sorted by `BinSortNum`, then `BinKey`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | No | Location ID (Lager) to filter by. NULL or empty string returns bins of all locations. |\n| `RowCount` | int | No | Maximum number of rows per page. 0 or NULL disables paging and returns all rows. |\n| `Start` | int | No | Number of rows to skip when paging is active; rows with `RowNr` greater than this value are returned. Ignored if `RowCount` is 0. |\n| `BinGroup` | varchar(20) | No | Bin group to filter by. NULL or empty string returns bins of all groups. |\n\n- All reads use `NOLOCK`, so the result can contain uncommitted data.\n- The row numbering for paging orders only by `BinSortNum`, while the output is ordered by `BinSortNum, BinKey`. If several bins share the same `BinSortNum`, the assignment of `RowNr` among them is not deterministic, so pages can overlap or skip bins. Use unique sort numbers or fetch without paging when this matters.\n- The column set differs between the two modes: `RowNr` is only present when `RowCount` > 0.\n- A negative `RowCount` is not handled and makes `TOP` fail with a SQL error.\n- `NrOfItemOnBin` is the total quantity on the bin, not the number of distinct items.\n\nDocumentation: https://pixi-api-docs.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": "Returns the stock bins (Lagerplätze), optionally filtered by location and bin group, with the total quantity stored on each bin and optional paging.\n\nReads the stock bins from `InvBin` and calculates for each bin the sum of `BinItemQTY` of all entries in `InvBinItem` on this bin (`NrOfItemOnBin`, 0 if the bin is empty).\n\nFilters:\n- `LocID`: only bins of this location (`BinLocID`). Empty string or NULL means all locations.\n- `BinGroup`: only bins of this bin group. Empty string or NULL means all groups.\n\nPaging:\n- If `RowCount` is 0 or NULL, all matching bins are returned without a `RowNr` column.\n- If `RowCount` is greater than 0, the rows are numbered by `BinSortNum` (`RowNr`), and at most `RowCount` rows with `RowNr` greater than `Start` are returned. `Start` is therefore the number of rows to skip.\n\nThe result is always sorted by `BinSortNum`, then `BinKey`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | No | Location ID (Lager) to filter by. NULL or empty string returns bins of all locations. |\n| `RowCount` | int | No | Maximum number of rows per page. 0 or NULL disables paging and returns all rows. |\n| `Start` | int | No | Number of rows to skip when paging is active; rows with `RowNr` greater than this value are returned. Ignored if `RowCount` is 0. |\n| `BinGroup` | varchar(20) | No | Bin group to filter by. NULL or empty string returns bins of all groups. |\n\n- All reads use `NOLOCK`, so the result can contain uncommitted data.\n- The row numbering for paging orders only by `BinSortNum`, while the output is ordered by `BinSortNum, BinKey`. If several bins share the same `BinSortNum`, the assignment of `RowNr` among them is not deterministic, so pages can overlap or skip bins. Use unique sort numbers or fetch without paging when this matters.\n- The column set differs between the two modes: `RowNr` is only present when `RowCount` > 0.\n- A negative `RowCount` is not handled and makes `TOP` fail with a SQL error.\n- `NrOfItemOnBin` is the total quantity on the bin, not the number of distinct items.\n\nDocumentation: https://pixi-api-docs.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": "Returns empty stock bins (Lagerplätze without any bin item record), optionally only those sorted near a reference bin.\n\nSearches for empty bins (Lagerplätze). A bin counts as empty if no row in `InvBinItem` references it (`BinRef = BinKey`).\n\n1. If both `BinName` and `LocID` are passed, the key of the bin with that name in that location is looked up and used as the reference bin (`NearBinKey`). If no such bin exists, a passed `NearBinKey` stays unchanged.\n2. `LocID` empty or `NULL` means all locations; otherwise only bins of that location (`BinLocID`) are considered.\n3. **Without a reference bin** (`NearBinKey` is `NULL` or `0`): returns the first `Rows` empty bins ordered by `BinSortNum` ascending.\n4. **With a reference bin**: reads the `BinSortNum` of the reference bin and returns up to `Rows / 2` (integer division) empty bins with `BinSortNum` less than or equal to the reference (the closest ones, i.e. the highest sort numbers below it) plus up to `Rows / 2` empty bins with a higher `BinSortNum` (the closest ones above it). The combined list is sorted by `BinSortNum` ascending.\n\nThe reference bin itself is part of the result if it is empty and matches the location filter.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | No | Location (Lager) ID to restrict the search to. `NULL` or empty searches all locations. Also required for the lookup by `BinName`. |\n| `Rows` | int | No | Maximum number of bins to return. With a reference bin, half of it (integer division) is taken below and half above the reference. |\n| `NearBinKey` | int | No | Key (`BinKey`) of the reference bin. `NULL` or `0` means no reference. Overwritten if `BinName` and `LocID` identify an existing bin. |\n| `BinName` | varchar(50) | No | Name of the reference bin; only evaluated together with `LocID`. |\n\n- All reads use `NOLOCK`, so the result may include uncommitted changes; a bin reported as empty may already be occupied.\n- Any `InvBinItem` row makes a bin non-empty, regardless of its quantity.\n- With a reference bin and an odd `Rows`, at most `Rows - 1` bins are returned (e.g. `Rows = 1` returns nothing).\n- If `NearBinKey` points to a non-existing bin, the reference sort number is `NULL` and the result is empty.\n- The location of the reference bin is not checked against `LocID`; when only `NearBinKey` is passed, its sort number is compared with bins of the filtered location.\n- `BinName` is only used together with `LocID`; on its own it is ignored.\n- `Rows` must not be `NULL` or negative, otherwise the `TOP` clause raises a SQL error.\n\nDocumentation: https://pixi-api-docs.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": "Returns empty stock bins (Lagerplätze without any bin item record), optionally only those sorted near a reference bin.\n\nSearches for empty bins (Lagerplätze). A bin counts as empty if no row in `InvBinItem` references it (`BinRef = BinKey`).\n\n1. If both `BinName` and `LocID` are passed, the key of the bin with that name in that location is looked up and used as the reference bin (`NearBinKey`). If no such bin exists, a passed `NearBinKey` stays unchanged.\n2. `LocID` empty or `NULL` means all locations; otherwise only bins of that location (`BinLocID`) are considered.\n3. **Without a reference bin** (`NearBinKey` is `NULL` or `0`): returns the first `Rows` empty bins ordered by `BinSortNum` ascending.\n4. **With a reference bin**: reads the `BinSortNum` of the reference bin and returns up to `Rows / 2` (integer division) empty bins with `BinSortNum` less than or equal to the reference (the closest ones, i.e. the highest sort numbers below it) plus up to `Rows / 2` empty bins with a higher `BinSortNum` (the closest ones above it). The combined list is sorted by `BinSortNum` ascending.\n\nThe reference bin itself is part of the result if it is empty and matches the location filter.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | No | Location (Lager) ID to restrict the search to. `NULL` or empty searches all locations. Also required for the lookup by `BinName`. |\n| `Rows` | int | No | Maximum number of bins to return. With a reference bin, half of it (integer division) is taken below and half above the reference. |\n| `NearBinKey` | int | No | Key (`BinKey`) of the reference bin. `NULL` or `0` means no reference. Overwritten if `BinName` and `LocID` identify an existing bin. |\n| `BinName` | varchar(50) | No | Name of the reference bin; only evaluated together with `LocID`. |\n\n- All reads use `NOLOCK`, so the result may include uncommitted changes; a bin reported as empty may already be occupied.\n- Any `InvBinItem` row makes a bin non-empty, regardless of its quantity.\n- With a reference bin and an odd `Rows`, at most `Rows - 1` bins are returned (e.g. `Rows = 1` returns nothing).\n- If `NearBinKey` points to a non-existing bin, the reference sort number is `NULL` and the result is empty.\n- The location of the reference bin is not checked against `LocID`; when only `NearBinKey` is passed, its sort number is compared with bins of the filtered location.\n- `BinName` is only used together with `LocID`; on its own it is ignored.\n- `Rows` must not be `NULL` or negative, otherwise the `TOP` clause raises a SQL error.\n\nDocumentation: https://pixi-api-docs.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": "Returns the available stock quantity for all items, calculated according to the stock export settings.\n\nReturns one row per item with its internal item number and an available quantity. The calculation depends on Pixi settings read at runtime.\n\n**Old stock export (`OldStockExport` = `1`)**\n\n- Returns every item from `Items` with `Quantity` as `AvailableQty`. `NULL` becomes `0`.\n\n**Default mode (any other value of `OldStockExport`)**\n\n1. The stock location is taken from the setting `ExportStock_locations`:\n - setting missing or `0`: location `001`\n - empty string: all locations (`ALL`)\n - any other value: that location ID\n2. For every item, the bin stock is the sum of `BinItemQty` over all bins of the selected location, or of all locations. Locations with `SpecialStock` = 1 are always left out.\n3. Open demand is subtracted from the bin stock:\n - **Setting `ReservePrepaymentOrders` ≠ `1`:** the summed `Qty` of order lines with status `ANG` is subtracted. Order lines with status `HAL` also count if their `OrderDate` is within the last `HalOrdersActiveDays` days. A value of `0` for that setting means 7 days.\n - **Setting `ReservePrepaymentOrders` = `1`:** the number of reservation records for the item is subtracted. Only reservations whose order line status is not a final state are counted, and the statuses `EIN`, `FUT` and `FUS` are also excluded.\n4. Negative results are returned as `0`.\n5. Bundle items (items that have entries in `BundleItems`) are added with a UNION. Their quantity is not taken from bins. It is `Items.Quantity` for `ALL`, or `LocationQuantity` from `ItemLocationSpecific` for the selected location. Nothing is subtracted for open orders or reservations, and negative values become `0`.\n\n**Filtering**\n\nIf `ExcludeZeros` = `1`, all rows with `AvailableQty` = `0` are removed before the result is returned.\n\nThe result has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ExcludeZeros` | bit | No | If `1`, items with an available quantity of `0` are removed from the result. |\n\n- All reads use `NOLOCK`, so the figures can include uncommitted data.\n- **Bundles can appear twice.** In default mode the first query covers all items, including bundles. A bundle therefore gets one row from the bin-based calculation and one row from the bundle calculation. `UNION` only removes rows that are completely identical.\n- **Missing `HalOrdersActiveDays`.** If the setting does not exist, the value is `NULL`, not `0`. In that case the 7-day fallback does not apply and `HAL` order lines are never subtracted.\n- **Reservations are counted, not summed.** With reservations enabled, the number of reservation records is subtracted, not a quantity.\n- The setting `ShowLocationStockInItemSearch` is read but has no effect on the result.\n- `ExportStock_locations` is stored in a `varchar(3)` variable, so longer values are truncated to 3 characters.\n- The call computes correlated subqueries per item over all items and can be slow on large databases.\n\nDocumentation: https://pixi-api-docs.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": "Returns the available stock quantity for all items, calculated according to the stock export settings.\n\nReturns one row per item with its internal item number and an available quantity. The calculation depends on Pixi settings read at runtime.\n\n**Old stock export (`OldStockExport` = `1`)**\n\n- Returns every item from `Items` with `Quantity` as `AvailableQty`. `NULL` becomes `0`.\n\n**Default mode (any other value of `OldStockExport`)**\n\n1. The stock location is taken from the setting `ExportStock_locations`:\n - setting missing or `0`: location `001`\n - empty string: all locations (`ALL`)\n - any other value: that location ID\n2. For every item, the bin stock is the sum of `BinItemQty` over all bins of the selected location, or of all locations. Locations with `SpecialStock` = 1 are always left out.\n3. Open demand is subtracted from the bin stock:\n - **Setting `ReservePrepaymentOrders` ≠ `1`:** the summed `Qty` of order lines with status `ANG` is subtracted. Order lines with status `HAL` also count if their `OrderDate` is within the last `HalOrdersActiveDays` days. A value of `0` for that setting means 7 days.\n - **Setting `ReservePrepaymentOrders` = `1`:** the number of reservation records for the item is subtracted. Only reservations whose order line status is not a final state are counted, and the statuses `EIN`, `FUT` and `FUS` are also excluded.\n4. Negative results are returned as `0`.\n5. Bundle items (items that have entries in `BundleItems`) are added with a UNION. Their quantity is not taken from bins. It is `Items.Quantity` for `ALL`, or `LocationQuantity` from `ItemLocationSpecific` for the selected location. Nothing is subtracted for open orders or reservations, and negative values become `0`.\n\n**Filtering**\n\nIf `ExcludeZeros` = `1`, all rows with `AvailableQty` = `0` are removed before the result is returned.\n\nThe result has no defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ExcludeZeros` | bit | No | If `1`, items with an available quantity of `0` are removed from the result. |\n\n- All reads use `NOLOCK`, so the figures can include uncommitted data.\n- **Bundles can appear twice.** In default mode the first query covers all items, including bundles. A bundle therefore gets one row from the bin-based calculation and one row from the bundle calculation. `UNION` only removes rows that are completely identical.\n- **Missing `HalOrdersActiveDays`.** If the setting does not exist, the value is `NULL`, not `0`. In that case the 7-day fallback does not apply and `HAL` order lines are never subtracted.\n- **Reservations are counted, not summed.** With reservations enabled, the number of reservation records is subtracted, not a quantity.\n- The setting `ShowLocationStockInItemSearch` is read but has no effect on the result.\n- `ExportStock_locations` is stored in a `varchar(3)` variable, so longer values are truncated to 3 characters.\n- The call computes correlated subqueries per item over all items and can be slow on large databases.\n\nDocumentation: https://pixi-api-docs.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": "Returns all stock movements (bin item log entries) booked for a given order line, together with the bin they refer to.\n\nReads the stock movement log `InvBinItemLog` and returns every entry whose `ForOrderline` equals `OrderlineKey`.\n\n- Each log entry is joined to the bin table `InvBin` on the bin reference (`BinKey = BinRef`). The join is an inner join, so log entries whose bin no longer exists in `InvBin` are not returned.\n- For each movement the call returns the quantity, the item reference, the employee and date of the booking, the reason and the bin data (`BinKey`, `LocID`, `BinName`).\n- No sort order is defined; the rows come back in the order SQL Server delivers them.\n- There is no paging; all matching rows are returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Yes | Key of the order line whose stock movements are returned. Compared with `InvBinItemLog.ForOrderline`. |\n\n- If no movement exists for the order line (or the key does not exist), an empty result set is returned; no error is raised.\n- The header comment of the procedure is a generic template text and does not describe this call.\n- The query uses no `NOLOCK` hints. The column types are not declared in the code and depend on the table definitions of `InvBinItemLog` and `InvBin`.\n- The sign convention of `Qty` (e.g. negative for outgoing stock) is not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns all stock movements (bin item log entries) booked for a given order line, together with the bin they refer to.\n\nReads the stock movement log `InvBinItemLog` and returns every entry whose `ForOrderline` equals `OrderlineKey`.\n\n- Each log entry is joined to the bin table `InvBin` on the bin reference (`BinKey = BinRef`). The join is an inner join, so log entries whose bin no longer exists in `InvBin` are not returned.\n- For each movement the call returns the quantity, the item reference, the employee and date of the booking, the reason and the bin data (`BinKey`, `LocID`, `BinName`).\n- No sort order is defined; the rows come back in the order SQL Server delivers them.\n- There is no paging; all matching rows are returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderlineKey` | int | Yes | Key of the order line whose stock movements are returned. Compared with `InvBinItemLog.ForOrderline`. |\n\n- If no movement exists for the order line (or the key does not exist), an empty result set is returned; no error is raised.\n- The header comment of the procedure is a generic template text and does not describe this call.\n- The query uses no `NOLOCK` hints. The column types are not declared in the code and depend on the table definitions of `InvBinItemLog` and `InvBin`.\n- The sign convention of `Qty` (e.g. negative for outgoing stock) is not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns the stock movement operations defined for one application, with names translated into the requested language.\n\nReads the stock movement operations (table `StockMovementOperations`) that belong to the application given in `Application`. Typical use is filling a selection list of movement reasons in a client such as Picco.\n\n- Only operations whose stored `Application` value equals `@Application` exactly are returned. The filter uses the raw, untranslated value.\n- The application name and the operation name are translated through the `Translation` table, using the language from `@LanguageID`:\n - The application name uses the `DBObjectName` `ApplicationNames`.\n - The operation name uses `StockMovementOperations`, matched on `SMOKey`.\n- If no translation exists, the untranslated value from `StockMovementOperations` is returned.\n- `App_SMOName` combines both texts in the form `Application - Name`.\n- The original, untranslated operation name is always available in `NameId`.\n\nThe rows are sorted by application, then by the translated operation name.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LanguageID` | int | No | Language used to translate the application and operation names via the `Translation` table. |\n| `Application` | varchar(100) | No | Application whose stock movement operations are returned. The value is compared exactly with the untranslated `Application` value in `StockMovementOperations`. |\n\n- The meaning of the language IDs (e.g. which language `2` stands for) is defined by the Pixi language master data, not by this procedure.\n- `@Application` must match the untranslated application key stored in `StockMovementOperations`, not a translated display name.\n- If no operation exists for the application, an empty result set is returned. No error is raised.\n- The data types of `SMOKey`, `NameId`, `AskInGUI` and `Editable` come from the table definition, which is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Returns the stock movement operations defined for one application, with names translated into the requested language.\n\nReads the stock movement operations (table `StockMovementOperations`) that belong to the application given in `Application`. Typical use is filling a selection list of movement reasons in a client such as Picco.\n\n- Only operations whose stored `Application` value equals `@Application` exactly are returned. The filter uses the raw, untranslated value.\n- The application name and the operation name are translated through the `Translation` table, using the language from `@LanguageID`:\n - The application name uses the `DBObjectName` `ApplicationNames`.\n - The operation name uses `StockMovementOperations`, matched on `SMOKey`.\n- If no translation exists, the untranslated value from `StockMovementOperations` is returned.\n- `App_SMOName` combines both texts in the form `Application - Name`.\n- The original, untranslated operation name is always available in `NameId`.\n\nThe rows are sorted by application, then by the translated operation name.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LanguageID` | int | No | Language used to translate the application and operation names via the `Translation` table. |\n| `Application` | varchar(100) | No | Application whose stock movement operations are returned. The value is compared exactly with the untranslated `Application` value in `StockMovementOperations`. |\n\n- The meaning of the language IDs (e.g. which language `2` stands for) is defined by the Pixi language master data, not by this procedure.\n- `@Application` must match the untranslated application key stored in `StockMovementOperations`, not a translated display name.\n- If no operation exists for the application, an empty result set is returned. No error is raised.\n- The data types of `SMOKey`, `NameId`, `AskInGUI` and `Editable` come from the table definition, which is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Returns all stock movement types defined in Pixi with their key, name and system flag, sorted by name.\n\nReturns the complete list of stock movement types from the table `StockMovementTypes`.\n\n- The call has no parameters and applies no filter.\n- Each row contains the key `SMTKey`, the type name `Type` and the flag `IsSystemType` (the source column `System`), which marks types that are predefined by the system.\n- Rows are sorted by `Type` in ascending order.\n\nUse the call as a lookup to translate the stock movement type keys that other stock-related calls return or expect.\n\nThe table is read with `NOLOCK`, so uncommitted changes may be visible. The SQL data types of the columns are not visible in the code; the types given are assumptions based on the column names.\n\nDocumentation: https://pixi-api-docs.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": "Returns all stock movement types defined in Pixi with their key, name and system flag, sorted by name.\n\nReturns the complete list of stock movement types from the table `StockMovementTypes`.\n\n- The call has no parameters and applies no filter.\n- Each row contains the key `SMTKey`, the type name `Type` and the flag `IsSystemType` (the source column `System`), which marks types that are predefined by the system.\n- Rows are sorted by `Type` in ascending order.\n\nUse the call as a lookup to translate the stock movement type keys that other stock-related calls return or expect.\n\nThe table is read with `NOLOCK`, so uncommitted changes may be visible. The SQL data types of the columns are not visible in the code; the types given are assumptions based on the column names.\n\nDocumentation: https://pixi-api-docs.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": "Returns the stock movement types assigned to the stock movement operations of an application, with translated names and the default-type flag.\n\nReturns the stock movement types that are linked to stock movement operations through the matching table `StockMovementMatching`.\n\n- Only operations whose `Application` equals `@Application` are returned. The default is `Picco`.\n- If `@SMOKey` is given, only the movement types of that single operation are returned. If `@SMOKey` is `NULL`, the types of all operations of the application are returned.\n- The name of each movement type (`SMTName`) comes from the `Translation` table (object `StockMovementTypes.Name`) in the language `@LanguageID`. The default language ID is `2`.\n- Each row is one combination of movement type and operation. A movement type that is assigned to several operations appears once per operation.\n\nThe result has no explicit sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Application` | varchar(100) | No | Application whose stock movement operations are evaluated. It is compared with `StockMovementOperations.Application`. |\n| `SMOKey` | int | No | Key of a stock movement operation to restrict the result to. `NULL` (or `0`) returns all operations of the application. |\n| `LanguageID` | int | No | Language ID used to read the translated movement type name from `Translation`. |\n\n- All tables are read with `NOLOCK`, so uncommitted data can appear.\n- The filter on `Application` removes rows without an assigned operation. Despite the `LEFT JOIN`s, movement types that are not assigned to any operation are therefore never returned.\n- The code checks `@SMOKey` with `COALESCE(@SMOKey, '') = ''`. Because the parameter is an `int`, the empty string is converted to `0`. Passing `0` therefore behaves like `NULL` and returns all operations of the application.\n- If no translation exists for the requested language, `SMTName` is `NULL`. The procedure does not fall back to another language.\n- The code does not document which language `@LanguageID = 2` stands for. This depends on the language IDs configured in the Pixi database.\n\nDocumentation: https://pixi-api-docs.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": "Returns the stock movement types assigned to the stock movement operations of an application, with translated names and the default-type flag.\n\nReturns the stock movement types that are linked to stock movement operations through the matching table `StockMovementMatching`.\n\n- Only operations whose `Application` equals `@Application` are returned. The default is `Picco`.\n- If `@SMOKey` is given, only the movement types of that single operation are returned. If `@SMOKey` is `NULL`, the types of all operations of the application are returned.\n- The name of each movement type (`SMTName`) comes from the `Translation` table (object `StockMovementTypes.Name`) in the language `@LanguageID`. The default language ID is `2`.\n- Each row is one combination of movement type and operation. A movement type that is assigned to several operations appears once per operation.\n\nThe result has no explicit sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Application` | varchar(100) | No | Application whose stock movement operations are evaluated. It is compared with `StockMovementOperations.Application`. |\n| `SMOKey` | int | No | Key of a stock movement operation to restrict the result to. `NULL` (or `0`) returns all operations of the application. |\n| `LanguageID` | int | No | Language ID used to read the translated movement type name from `Translation`. |\n\n- All tables are read with `NOLOCK`, so uncommitted data can appear.\n- The filter on `Application` removes rows without an assigned operation. Despite the `LEFT JOIN`s, movement types that are not assigned to any operation are therefore never returned.\n- The code checks `@SMOKey` with `COALESCE(@SMOKey, '') = ''`. Because the parameter is an `int`, the empty string is converted to `0`. Passing `0` therefore behaves like `NULL` and returns all operations of the application.\n- If no translation exists for the requested language, `SMTName` is `NULL`. The procedure does not fall back to another language.\n- The code does not document which language `@LanguageID = 2` stands for. This depends on the language IDs configured in the Pixi database.\n\nDocumentation: https://pixi-api-docs.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": "Returns the Artikel that must be moved from a source location to a target location to cover minimum stock and open customer orders, with the source Lagerplätze to pick from.\n\nBuilds a replenishment (refill) list between two warehouse locations. The call passes all parameters to the internal procedure `CR_InventoryItemsToRefill`, which does the work.\n\n**Demand in the target location (`ToLocID`)**\n- *Open customer orders*: sum of `Orderlines.Qty` per Artikel in `ToLocID` with status `ANG`, `BES`, `BOR` and `HAL`. `HAL` is left out when the setting `InventoryItemsToRefill_NoHAL` is `1`.\n- *Orders on hold*: sum of `Qty` of order lines with status `HAL` in `ToLocID`. This value is returned for information only.\n- Stock per location comes from `ItemLocationSpecific` (`LocationQuantity`, `MinStockQty`, `TargetStock`).\n\n**Which Artikel are selected**\n- The Artikel has an `ItemLocationSpecific` record for `ToLocID`.\n- `FromLocID` differs from `ToLocID`.\n- Positive minimum stock plus open customer order quantity is greater than the stock in `ToLocID`.\n- The Artikel is stored on at least one Lagerplatz (`InvBin`) of `FromLocID`.\n\n**Missing quantity**\n\nIt is calculated as positive `MinStockQty` + open customer order quantity − stock in `ToLocID` − stock in `AdditionalLocID` (the last term only if `AdditionalLocID` is set).\n\n**Allocation to source bins**\n- All bin entries (`InvBinItem`) of the Artikel in `FromLocID` are used. Entries that are referenced by a non-expired picklist item (`PLitem`) are skipped.\n- The entries are numbered oldest first (`CreateDate`). Only the first *MissingQty* entries are kept.\n- The result has one row per Artikel and source Lagerplatz. `MissingQty` is the number of entries taken from that bin. `FromBinqty` is the total quantity of the Artikel on that bin.\n- `ToLocIDbinName`/`ToLocIDbinSortNum` show one Lagerplatz of the Artikel in `ToLocID`, if there is one.\n\n**Sort order**\n\nWith `SortBy = '1'` the rows are sorted by `ToLocIDbinSortNum`, otherwise by `FromLocIDbinSortNum`. Within that, rows are sorted by `ItemName`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromLocID` | varchar(3) | Yes | Source location (Lager) from whose Lagerplätze the goods are taken. |\n| `ToLocID` | varchar(3) | Yes | Target location to be refilled. Stock, minimum stock and open customer orders are evaluated for this location. |\n| `AdditionalLocID` | varchar(3) | No | Optional additional location whose stock is subtracted from the missing quantity. If NULL or empty, no additional location is considered. |\n| `SortBy` | varchar(1) | No | Sort order of the result. |\n\n- Read-only. All tables are read `WITH (NOLOCK)`, so the result can contain uncommitted data.\n- The allocation counts bin entries (`InvBinItem` rows), not quantities. The `MissingQty` returned per bin is therefore the number of entries taken from that bin. Its sum over all bins of an Artikel can be lower than the calculated shortage if there are fewer entries.\n- The selection filter does not subtract the stock of `AdditionalLocID`, but the missing quantity does. If the additional location covers the shortage, the missing quantity is 0 or less and the Artikel does not appear.\n- `ToLocIDbinName` is taken with `TOP 1` without an `ORDER BY`. If the Artikel has several Lagerplätze in `ToLocID`, which one is shown is not defined.\n- The setting is read through `fpixi_GetSetting`, whose definition is not attached. If it returns `NULL` instead of an empty value, `HAL` is also excluded.\n- `FromLocQty` and `MinStockQty` can be empty if no matching `ItemLocationSpecific` value exists.\n- If `FromLocID` equals `ToLocID`, the result is always empty.\n\nDocumentation: https://pixi-api-docs.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": "Returns the Artikel that must be moved from a source location to a target location to cover minimum stock and open customer orders, with the source Lagerplätze to pick from.\n\nBuilds a replenishment (refill) list between two warehouse locations. The call passes all parameters to the internal procedure `CR_InventoryItemsToRefill`, which does the work.\n\n**Demand in the target location (`ToLocID`)**\n- *Open customer orders*: sum of `Orderlines.Qty` per Artikel in `ToLocID` with status `ANG`, `BES`, `BOR` and `HAL`. `HAL` is left out when the setting `InventoryItemsToRefill_NoHAL` is `1`.\n- *Orders on hold*: sum of `Qty` of order lines with status `HAL` in `ToLocID`. This value is returned for information only.\n- Stock per location comes from `ItemLocationSpecific` (`LocationQuantity`, `MinStockQty`, `TargetStock`).\n\n**Which Artikel are selected**\n- The Artikel has an `ItemLocationSpecific` record for `ToLocID`.\n- `FromLocID` differs from `ToLocID`.\n- Positive minimum stock plus open customer order quantity is greater than the stock in `ToLocID`.\n- The Artikel is stored on at least one Lagerplatz (`InvBin`) of `FromLocID`.\n\n**Missing quantity**\n\nIt is calculated as positive `MinStockQty` + open customer order quantity − stock in `ToLocID` − stock in `AdditionalLocID` (the last term only if `AdditionalLocID` is set).\n\n**Allocation to source bins**\n- All bin entries (`InvBinItem`) of the Artikel in `FromLocID` are used. Entries that are referenced by a non-expired picklist item (`PLitem`) are skipped.\n- The entries are numbered oldest first (`CreateDate`). Only the first *MissingQty* entries are kept.\n- The result has one row per Artikel and source Lagerplatz. `MissingQty` is the number of entries taken from that bin. `FromBinqty` is the total quantity of the Artikel on that bin.\n- `ToLocIDbinName`/`ToLocIDbinSortNum` show one Lagerplatz of the Artikel in `ToLocID`, if there is one.\n\n**Sort order**\n\nWith `SortBy = '1'` the rows are sorted by `ToLocIDbinSortNum`, otherwise by `FromLocIDbinSortNum`. Within that, rows are sorted by `ItemName`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromLocID` | varchar(3) | Yes | Source location (Lager) from whose Lagerplätze the goods are taken. |\n| `ToLocID` | varchar(3) | Yes | Target location to be refilled. Stock, minimum stock and open customer orders are evaluated for this location. |\n| `AdditionalLocID` | varchar(3) | No | Optional additional location whose stock is subtracted from the missing quantity. If NULL or empty, no additional location is considered. |\n| `SortBy` | varchar(1) | No | Sort order of the result. |\n\n- Read-only. All tables are read `WITH (NOLOCK)`, so the result can contain uncommitted data.\n- The allocation counts bin entries (`InvBinItem` rows), not quantities. The `MissingQty` returned per bin is therefore the number of entries taken from that bin. Its sum over all bins of an Artikel can be lower than the calculated shortage if there are fewer entries.\n- The selection filter does not subtract the stock of `AdditionalLocID`, but the missing quantity does. If the additional location covers the shortage, the missing quantity is 0 or less and the Artikel does not appear.\n- `ToLocIDbinName` is taken with `TOP 1` without an `ORDER BY`. If the Artikel has several Lagerplätze in `ToLocID`, which one is shown is not defined.\n- The setting is read through `fpixi_GetSetting`, whose definition is not attached. If it returns `NULL` instead of an empty value, `HAL` is also excluded.\n- `FromLocQty` and `MinStockQty` can be empty if no matching `ItemLocationSpecific` value exists.\n- If `FromLocID` equals `ToLocID`, the result is always empty.\n\nDocumentation: https://pixi-api-docs.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": "Returns the items with positive stock on a bin (or on all bins), including tags, supplier numbers, open picklists and packed box quantities.\n\nLists every item that currently has stock on a bin, intended for the Mobix mobile warehouse client.\n\n**Bin stock**\n- Bins (`InvBin`) are joined with the bin item log (`InvBinItemLog`, matched on bin and location) and the item master (`items`).\n- If `BinName` is given, only bins with exactly that name are considered (bins with this name in any location). If it is omitted or `NULL`, all bins are evaluated.\n- Quantities are summed per bin and item; only combinations with a sum greater than 0 are returned.\n\n**Additional item information**\n- `Tags`: names of the item tags assigned to the item, sorted alphabetically, separated by commas.\n- `ItemNrSuppls`: distinct supplier item numbers from `additems`.\n- `SupplNrs`: supplier numbers from `additems`.\n\n**Picklist information**\n- Order lines of the item that are on a non-expired picklist item (`PLitem.Expired = 0`) and whose status is not `AUS`, `NLB`, `RET`, `STO` or `EIN` are counted per picklist.\n- `PicklistsUsed` lists the picklist header references, `QtyOnPiclists` the number of picklist items.\n\n**Box information**\n- Order lines with status `EIN` that are packed into boxes (`boxitems`, `boxes`) are summed per box.\n- `BoxesUsed` lists the box numbers, `QtyInBoxes` the packed quantity.\n\n`LocId` only restricts the picklist and box information to order lines of that location (`Orderlines.LocationID`). An empty value or `NULL` means all locations. The bin stock itself is **not** filtered by `LocId`.\n\nNo explicit sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BinName` | varchar(50) | No | Name of the bin to evaluate. `NULL` or omitted returns all bins with positive stock. |\n| `LocId` | varchar(3) | No | Location ID used to restrict the picklist and box information to order lines of this location. `NULL` or empty means all locations. Does not filter the bin stock. |\n\n- All tables are read with `NOLOCK`; results can include uncommitted data.\n- `QtyOnPiclists` and `QtyInBoxes` are calculated with scalar subqueries. If an item is on more than one picklist or in more than one box, SQL Server raises error 512 (subquery returned more than one value) and the call fails.\n- If the same item lies on several bins in the result, the picklist count is multiplied by the number of these bins because of the join with the bin list.\n- The lists in `Tags`, `ItemNrSuppls`, `SupplNrs`, `PicklistsUsed` and `BoxesUsed` are built by string concatenation and usually end with a trailing comma; separators may contain extra spaces.\n- The status filter for picklists uses an unqualified `Status` column; it is most likely the order line status.\n- Without `BinName` all bins with stock are evaluated, which can be slow and return many rows.\n\nDocumentation: https://pixi-api-docs.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": "Returns the items with positive stock on a bin (or on all bins), including tags, supplier numbers, open picklists and packed box quantities.\n\nLists every item that currently has stock on a bin, intended for the Mobix mobile warehouse client.\n\n**Bin stock**\n- Bins (`InvBin`) are joined with the bin item log (`InvBinItemLog`, matched on bin and location) and the item master (`items`).\n- If `BinName` is given, only bins with exactly that name are considered (bins with this name in any location). If it is omitted or `NULL`, all bins are evaluated.\n- Quantities are summed per bin and item; only combinations with a sum greater than 0 are returned.\n\n**Additional item information**\n- `Tags`: names of the item tags assigned to the item, sorted alphabetically, separated by commas.\n- `ItemNrSuppls`: distinct supplier item numbers from `additems`.\n- `SupplNrs`: supplier numbers from `additems`.\n\n**Picklist information**\n- Order lines of the item that are on a non-expired picklist item (`PLitem.Expired = 0`) and whose status is not `AUS`, `NLB`, `RET`, `STO` or `EIN` are counted per picklist.\n- `PicklistsUsed` lists the picklist header references, `QtyOnPiclists` the number of picklist items.\n\n**Box information**\n- Order lines with status `EIN` that are packed into boxes (`boxitems`, `boxes`) are summed per box.\n- `BoxesUsed` lists the box numbers, `QtyInBoxes` the packed quantity.\n\n`LocId` only restricts the picklist and box information to order lines of that location (`Orderlines.LocationID`). An empty value or `NULL` means all locations. The bin stock itself is **not** filtered by `LocId`.\n\nNo explicit sort order is applied.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BinName` | varchar(50) | No | Name of the bin to evaluate. `NULL` or omitted returns all bins with positive stock. |\n| `LocId` | varchar(3) | No | Location ID used to restrict the picklist and box information to order lines of this location. `NULL` or empty means all locations. Does not filter the bin stock. |\n\n- All tables are read with `NOLOCK`; results can include uncommitted data.\n- `QtyOnPiclists` and `QtyInBoxes` are calculated with scalar subqueries. If an item is on more than one picklist or in more than one box, SQL Server raises error 512 (subquery returned more than one value) and the call fails.\n- If the same item lies on several bins in the result, the picklist count is multiplied by the number of these bins because of the join with the bin list.\n- The lists in `Tags`, `ItemNrSuppls`, `SupplNrs`, `PicklistsUsed` and `BoxesUsed` are built by string concatenation and usually end with a trailing comma; separators may contain extra spaces.\n- The status filter for picklists uses an unqualified `Status` column; it is most likely the order line status.\n- Without `BinName` all bins with stock are evaluated, which can be slow and return many rows.\n\nDocumentation: https://pixi-api-docs.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": "Returns entries of the bin location item log (InvBinItemLog), optionally filtered by date ranges and paged by log key.\n\nReads rows from the bin location item log `InvBinItemLog`. Each row describes a quantity booking of an Artikel on a Lagerplatz.\n\n**Paging**\n\n- `ItemBinLogKey` is an exclusive lower bound. Only rows with `IBILkey` greater than this value are returned. If it is omitted or NULL, `0` is used, so the call starts at the beginning of the log.\n- `RowCount` limits the number of rows. The default is 1000; NULL is also treated as 1000.\n- Rows are always sorted by `IBILkey` ascending. To read the next page, pass the highest `IBILkey` of the previous page as `ItemBinLogKey`.\n\n**Date filters**\n\nOnly one group of date filters is used. The groups are checked in this order, and the first group with at least one value set wins:\n\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: the lower bound matches if `UpdateDate` **or** `ReportedDate` is >= From. The upper bound matches if `UpdateDate` **or** `ReportedDate` is < To.\n2. `CreateDateFrom` / `CreateDateTo`: filters on the column `UpdateDate` (>= From, < To).\n3. `UpdateDateFrom` / `UpdateDateTo`: filters on the column `ReportedDate` (>= From, < To).\n\nIn each group, either bound can be omitted. Upper bounds are exclusive. If no date parameter is set, the call returns the next `RowCount` rows after `ItemBinLogKey`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemBinLogKey` | int | No | Exclusive lower bound for `IBILkey`. Only rows with a greater key are returned. NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Returns rows with `UpdateDate` >= this value. Ignored if a combined date filter is set. |\n| `CreateDateTo` | datetime | No | Returns rows with `UpdateDate` < this value (exclusive). Ignored if a combined date filter is set. |\n| `UpdateDateFrom` | datetime | No | Returns rows with `ReportedDate` >= this value. Used only if no combined or create date filter is set. |\n| `UpdateDateTo` | datetime | No | Returns rows with `ReportedDate` < this value (exclusive). Used only if no combined or create date filter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound of the combined filter. A row matches if `UpdateDate` or `ReportedDate` is >= this value. This group has the highest priority. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound of the combined filter (exclusive). A row matches if `UpdateDate` or `ReportedDate` is < this value. |\n| `RowCount` | int | No | Maximum number of rows returned. NULL is treated as 1000. |\n\n- The table is read `WITH (NOLOCK)`. Rows that are not yet committed can appear, and rows can be missing or appear twice.\n- `ItemBinLogKey` cannot fetch a single entry. Passing a key returns the rows **after** that key, never the row with that key. The code contains branches for an exact key lookup and for an empty result, but they are never reached, because `ItemBinLogKey` and `RowCount` are replaced with non-NULL values at the start.\n- The parameter names do not match the column names. `CreateDate*` filters on `UpdateDate`, and `UpdateDate*` filters on `ReportedDate`.\n- In the combined filter, the From and To conditions are evaluated independently. A row can match the lower bound through one column and the upper bound through the other.\n- Date parameters of a lower-priority group are ignored as soon as a higher-priority group has a value.\n- The column data types are not visible in the code, except `IBILkey` (compared with an int) and the date columns (compared with datetime values).\n\nDocumentation: https://pixi-api-docs.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": "Returns entries of the bin location item log (InvBinItemLog), optionally filtered by date ranges and paged by log key.\n\nReads rows from the bin location item log `InvBinItemLog`. Each row describes a quantity booking of an Artikel on a Lagerplatz.\n\n**Paging**\n\n- `ItemBinLogKey` is an exclusive lower bound. Only rows with `IBILkey` greater than this value are returned. If it is omitted or NULL, `0` is used, so the call starts at the beginning of the log.\n- `RowCount` limits the number of rows. The default is 1000; NULL is also treated as 1000.\n- Rows are always sorted by `IBILkey` ascending. To read the next page, pass the highest `IBILkey` of the previous page as `ItemBinLogKey`.\n\n**Date filters**\n\nOnly one group of date filters is used. The groups are checked in this order, and the first group with at least one value set wins:\n\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: the lower bound matches if `UpdateDate` **or** `ReportedDate` is >= From. The upper bound matches if `UpdateDate` **or** `ReportedDate` is < To.\n2. `CreateDateFrom` / `CreateDateTo`: filters on the column `UpdateDate` (>= From, < To).\n3. `UpdateDateFrom` / `UpdateDateTo`: filters on the column `ReportedDate` (>= From, < To).\n\nIn each group, either bound can be omitted. Upper bounds are exclusive. If no date parameter is set, the call returns the next `RowCount` rows after `ItemBinLogKey`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemBinLogKey` | int | No | Exclusive lower bound for `IBILkey`. Only rows with a greater key are returned. NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Returns rows with `UpdateDate` >= this value. Ignored if a combined date filter is set. |\n| `CreateDateTo` | datetime | No | Returns rows with `UpdateDate` < this value (exclusive). Ignored if a combined date filter is set. |\n| `UpdateDateFrom` | datetime | No | Returns rows with `ReportedDate` >= this value. Used only if no combined or create date filter is set. |\n| `UpdateDateTo` | datetime | No | Returns rows with `ReportedDate` < this value (exclusive). Used only if no combined or create date filter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound of the combined filter. A row matches if `UpdateDate` or `ReportedDate` is >= this value. This group has the highest priority. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound of the combined filter (exclusive). A row matches if `UpdateDate` or `ReportedDate` is < this value. |\n| `RowCount` | int | No | Maximum number of rows returned. NULL is treated as 1000. |\n\n- The table is read `WITH (NOLOCK)`. Rows that are not yet committed can appear, and rows can be missing or appear twice.\n- `ItemBinLogKey` cannot fetch a single entry. Passing a key returns the rows **after** that key, never the row with that key. The code contains branches for an exact key lookup and for an empty result, but they are never reached, because `ItemBinLogKey` and `RowCount` are replaced with non-NULL values at the start.\n- The parameter names do not match the column names. `CreateDate*` filters on `UpdateDate`, and `UpdateDate*` filters on `ReportedDate`.\n- In the combined filter, the From and To conditions are evaluated independently. A row can match the lower bound through one column and the upper bound through the other.\n- Date parameters of a lower-priority group are ignored as soon as a higher-priority group has a value.\n- The column data types are not visible in the code, except `IBILkey` (compared with an int) and the date columns (compared with datetime values).\n\nDocumentation: https://pixi-api-docs.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": "Removes a given quantity of an item, identified by barcode, from a bin on a picklist and returns a status row.\n\nRemoves picklist positions for one item and one bin from a picklist.\n\nSteps:\n\n1. `Quantity` must be at least 1. `NULL` or smaller values return an error.\n2. The bin is looked up by its name (`BinName`) in `InvBin`.\n3. The item is looked up by its barcode (`EanUpc`), using the item codes with code type 1 (barcode).\n4. The call counts the picklist positions (`PLitem` rows linked to an order line) on the picklist for this bin and item. **Each position counts as one piece.**\n5. If no position is found, the call checks why and returns a specific error: the picklist does not exist, the picklist has no positions from this bin, or the item is not on the picklist in this bin.\n6. If fewer positions exist than `Quantity`, an error is returned and nothing is deleted.\n7. Otherwise, `Quantity` positions are removed, starting with the newest positions (highest position key, i.e. the bottom of the picklist). For the affected order lines the picklist reference (`PickListNrUsed`) is reset to `NULL`. All picking progress entries for this picklist, item and bin are deleted. After that, a cleanup of assigned boxes runs for picklists that are now empty.\n8. A `SUCCESS` row reports how many positions were deleted.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PickListNr` | int | Yes | Number (key) of the picklist (`PLHkey`). |\n| `EanUpc` | varchar(50) | Yes | Barcode (EAN/UPC) of the item. It is matched against the item codes with code type 1 (barcode). |\n| `BinName` | varchar(50) | Yes | Name of the bin from which the item is picked. |\n| `Quantity` | int | Yes | Number of picklist positions (pieces) to remove. Must be at least 1 and must not exceed the number of matching positions. |\n\n- The deletion runs in its own transaction, or in a savepoint if a transaction is already open. If a database error occurs, the changes are rolled back and the error is written to the error log via `log.InsertError`. **The call still returns `SUCCESS` in that case**, with the message `0 items deleted from picklist.` Treat a count of 0 as a failure.\n- All picking progress entries (`PL_ItemPickingProgress`) for the picklist, item and bin are deleted, not only the entries for the removed quantity.\n- The box cleanup is done by `dbo.pixi_RemoveAssignedBoxesFromEmptyPicklist`. Its definition is not attached, so its exact effects are not documented here.\n- The lookups and counts use `NOLOCK`. If several bins share the same name, or several items share the same barcode, it is not defined which one is used.\n\nDocumentation: https://pixi-api-docs.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": "Removes a given quantity of an item, identified by barcode, from a bin on a picklist and returns a status row.\n\nRemoves picklist positions for one item and one bin from a picklist.\n\nSteps:\n\n1. `Quantity` must be at least 1. `NULL` or smaller values return an error.\n2. The bin is looked up by its name (`BinName`) in `InvBin`.\n3. The item is looked up by its barcode (`EanUpc`), using the item codes with code type 1 (barcode).\n4. The call counts the picklist positions (`PLitem` rows linked to an order line) on the picklist for this bin and item. **Each position counts as one piece.**\n5. If no position is found, the call checks why and returns a specific error: the picklist does not exist, the picklist has no positions from this bin, or the item is not on the picklist in this bin.\n6. If fewer positions exist than `Quantity`, an error is returned and nothing is deleted.\n7. Otherwise, `Quantity` positions are removed, starting with the newest positions (highest position key, i.e. the bottom of the picklist). For the affected order lines the picklist reference (`PickListNrUsed`) is reset to `NULL`. All picking progress entries for this picklist, item and bin are deleted. After that, a cleanup of assigned boxes runs for picklists that are now empty.\n8. A `SUCCESS` row reports how many positions were deleted.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `PickListNr` | int | Yes | Number (key) of the picklist (`PLHkey`). |\n| `EanUpc` | varchar(50) | Yes | Barcode (EAN/UPC) of the item. It is matched against the item codes with code type 1 (barcode). |\n| `BinName` | varchar(50) | Yes | Name of the bin from which the item is picked. |\n| `Quantity` | int | Yes | Number of picklist positions (pieces) to remove. Must be at least 1 and must not exceed the number of matching positions. |\n\n- The deletion runs in its own transaction, or in a savepoint if a transaction is already open. If a database error occurs, the changes are rolled back and the error is written to the error log via `log.InsertError`. **The call still returns `SUCCESS` in that case**, with the message `0 items deleted from picklist.` Treat a count of 0 as a failure.\n- All picking progress entries (`PL_ItemPickingProgress`) for the picklist, item and bin are deleted, not only the entries for the removed quantity.\n- The box cleanup is done by `dbo.pixi_RemoveAssignedBoxesFromEmptyPicklist`. Its definition is not attached, so its exact effects are not documented here.\n- The lookups and counts use `NOLOCK`. If several bins share the same name, or several items share the same barcode, it is not defined which one is used.\n\nDocumentation: https://pixi-api-docs.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": "Returns a pick list of items to move from a source location to a target location, with the quantity per source bin, computed by one of three refill modes.\n\nThe call passes all parameters unchanged to the internal report procedure `Report_InventoryItemsToRefillMinStock` and returns its result.\n\n**Step 1 – candidate items**\n\nAn item is a candidate only if:\n- `FromLocID` and `ToLocID` are different,\n- the item has an `ItemLocationSpecific` record for both `FromLocID` and `ToLocID`,\n- the item is assigned to at least one bin (`InvBinItem`/`InvBin`) at `FromLocID`,\n- the calculated missing quantity is greater than 0.\n\nOpen order quantities are summed from `Orderlines` of the item at an *order location*. The order location is `ToLocID` for `Type` 1 and 3 and `FromLocID` otherwise. Statuses `ANG`, `BES` and `BOR` count as open customer orders, `HAL` counts as orders on hold. If the setting `InventoryItemsToRefill_NoHAL` is `1`, on-hold quantities are ignored in the calculations.\n\nThe **available stock** at the source is the location quantity at `FromLocID`, minus the minimum stock of `FromLocID` (only if `MinStock` = 1 and `Type` = 2), minus the open customer order quantity (only if the order location is `FromLocID`), minus the on-hold quantity (unless the setting excludes it).\n\nThe **missing quantity at the additional location** is minimum stock minus location quantity at `AdditionalLocID`, or 0 if it is not below minimum.\n\nThe missing quantity depends on `Type`:\n- `1`: demand = open customer orders at `ToLocID` + on-hold quantity + minimum stock of `ToLocID` (only if `MinStock` = 1). If the demand fits into the available stock, the target is missing quantity at the additional location + demand, otherwise the available stock. The result is the target minus the current stock at `ToLocID`, never below 0.\n- `2`: the missing quantity at the additional location, limited to the available stock at the source.\n- `3`: only if the minimum stock at `ToLocID` is 0, the stock at `AdditionalLocID` is 0, the stock at `FromLocID` is greater than 0 and there are open customer orders at `ToLocID`. The result is the smaller value of open customer orders and stock at `FromLocID`.\n\n**Step 2 – distribution over bins**\n\nFor each candidate, the item's `InvBinItem` records in bins at `FromLocID` are numbered by `InvBinItemKey`. Only the first *n* records are used, where *n* is the missing quantity. The rows are grouped per source bin. In the output, `MissingQty` is the number of these records in that bin. This equals a piece count if each bin record stands for one piece. One bin at `ToLocID` is added as the target bin, if there is one.\n\n**Sort order**\n\nIf `SortBy` = `1`, rows are sorted by the sort number of the target bin, otherwise by the sort number of the source bin. Within that, rows are sorted by `ItemName`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromLocID` | varchar(3) | Yes | Source location from which stock is taken. The item must have bins and an `ItemLocationSpecific` record here. |\n| `MinStock` | bit | No | Controls whether minimum stock is considered. For `Type` 1, the minimum stock of `ToLocID` is added to the demand. For `Type` 2, the minimum stock of `FromLocID` is kept back from the available stock. No effect for `Type` 3. |\n| `ToLocID` | varchar(3) | Yes | Target location to be refilled. Must differ from `FromLocID`, otherwise no rows are returned. The item must have an `ItemLocationSpecific` record here. |\n| `AdditionalLocID` | varchar(3) | No | Additional location whose shortfall below minimum stock is included (`Type` 1 and 2). For `Type` 3, its stock must be 0. |\n| `SortBy` | varchar(1) | No | Sort order of the result. The value is also returned in the `SortBy` column. |\n| `Type` | int | No | Calculation mode for the missing quantity. Without a valid value, no rows are returned. |\n\n- The header comment of the wrapper describes it as *calling the 1SS Report for billing purposes*.\n- `Type` defaults to `NULL` in the wrapper. With `NULL` or any value other than 1, 2 or 3, the missing quantity is `NULL` and the call returns no rows. Always pass `Type`.\n- The missing quantity at the additional location comes from an outer join. If `AdditionalLocID` is `NULL` or the item has no `ItemLocationSpecific` record there, the value is `NULL`, not 0:\n - `Type` 2 and `Type` 3 then return no row for the item.\n - `Type` 1 only returns a row if the demand exceeds the available stock.\n- The target bin is taken with `TOP 1` without an `ORDER BY`. For items with several bins at `ToLocID`, the bin shown is not deterministic.\n- The value of the setting `InventoryItemsToRefill_NoHAL` is read at runtime via `fPIXI_GetSetting`; that function is not attached.\n- All reads use `NOLOCK`, so results can include uncommitted data.\n- The call only reads data. It uses a temporary table internally.\n\nDocumentation: https://pixi-api-docs.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": "Returns a pick list of items to move from a source location to a target location, with the quantity per source bin, computed by one of three refill modes.\n\nThe call passes all parameters unchanged to the internal report procedure `Report_InventoryItemsToRefillMinStock` and returns its result.\n\n**Step 1 – candidate items**\n\nAn item is a candidate only if:\n- `FromLocID` and `ToLocID` are different,\n- the item has an `ItemLocationSpecific` record for both `FromLocID` and `ToLocID`,\n- the item is assigned to at least one bin (`InvBinItem`/`InvBin`) at `FromLocID`,\n- the calculated missing quantity is greater than 0.\n\nOpen order quantities are summed from `Orderlines` of the item at an *order location*. The order location is `ToLocID` for `Type` 1 and 3 and `FromLocID` otherwise. Statuses `ANG`, `BES` and `BOR` count as open customer orders, `HAL` counts as orders on hold. If the setting `InventoryItemsToRefill_NoHAL` is `1`, on-hold quantities are ignored in the calculations.\n\nThe **available stock** at the source is the location quantity at `FromLocID`, minus the minimum stock of `FromLocID` (only if `MinStock` = 1 and `Type` = 2), minus the open customer order quantity (only if the order location is `FromLocID`), minus the on-hold quantity (unless the setting excludes it).\n\nThe **missing quantity at the additional location** is minimum stock minus location quantity at `AdditionalLocID`, or 0 if it is not below minimum.\n\nThe missing quantity depends on `Type`:\n- `1`: demand = open customer orders at `ToLocID` + on-hold quantity + minimum stock of `ToLocID` (only if `MinStock` = 1). If the demand fits into the available stock, the target is missing quantity at the additional location + demand, otherwise the available stock. The result is the target minus the current stock at `ToLocID`, never below 0.\n- `2`: the missing quantity at the additional location, limited to the available stock at the source.\n- `3`: only if the minimum stock at `ToLocID` is 0, the stock at `AdditionalLocID` is 0, the stock at `FromLocID` is greater than 0 and there are open customer orders at `ToLocID`. The result is the smaller value of open customer orders and stock at `FromLocID`.\n\n**Step 2 – distribution over bins**\n\nFor each candidate, the item's `InvBinItem` records in bins at `FromLocID` are numbered by `InvBinItemKey`. Only the first *n* records are used, where *n* is the missing quantity. The rows are grouped per source bin. In the output, `MissingQty` is the number of these records in that bin. This equals a piece count if each bin record stands for one piece. One bin at `ToLocID` is added as the target bin, if there is one.\n\n**Sort order**\n\nIf `SortBy` = `1`, rows are sorted by the sort number of the target bin, otherwise by the sort number of the source bin. Within that, rows are sorted by `ItemName`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromLocID` | varchar(3) | Yes | Source location from which stock is taken. The item must have bins and an `ItemLocationSpecific` record here. |\n| `MinStock` | bit | No | Controls whether minimum stock is considered. For `Type` 1, the minimum stock of `ToLocID` is added to the demand. For `Type` 2, the minimum stock of `FromLocID` is kept back from the available stock. No effect for `Type` 3. |\n| `ToLocID` | varchar(3) | Yes | Target location to be refilled. Must differ from `FromLocID`, otherwise no rows are returned. The item must have an `ItemLocationSpecific` record here. |\n| `AdditionalLocID` | varchar(3) | No | Additional location whose shortfall below minimum stock is included (`Type` 1 and 2). For `Type` 3, its stock must be 0. |\n| `SortBy` | varchar(1) | No | Sort order of the result. The value is also returned in the `SortBy` column. |\n| `Type` | int | No | Calculation mode for the missing quantity. Without a valid value, no rows are returned. |\n\n- The header comment of the wrapper describes it as *calling the 1SS Report for billing purposes*.\n- `Type` defaults to `NULL` in the wrapper. With `NULL` or any value other than 1, 2 or 3, the missing quantity is `NULL` and the call returns no rows. Always pass `Type`.\n- The missing quantity at the additional location comes from an outer join. If `AdditionalLocID` is `NULL` or the item has no `ItemLocationSpecific` record there, the value is `NULL`, not 0:\n - `Type` 2 and `Type` 3 then return no row for the item.\n - `Type` 1 only returns a row if the demand exceeds the available stock.\n- The target bin is taken with `TOP 1` without an `ORDER BY`. For items with several bins at `ToLocID`, the bin shown is not deterministic.\n- The value of the setting `InventoryItemsToRefill_NoHAL` is read at runtime via `fPIXI_GetSetting`; that function is not attached.\n- All reads use `NOLOCK`, so results can include uncommitted data.\n- The call only reads data. It uses a temporary table internally.\n\nDocumentation: https://pixi-api-docs.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": "Returns the stock per item, bin, batch number and best-before date for items with batch management, based on the pixi* report \"Items on stock with BN/BBD\".\n\nExposes the pixi* report *Items on stock with BN/BBD* (batch number / best-before date) as an API call.\n\n1. **Normalisation:** empty strings are treated as `NULL` for all text filters. `ItemTag` = `0` is treated as `NULL`. If `BestBeforeDateFrom` or `BestBeforeDateTo` is missing (or `1900-01-01`), it defaults to the start or end of the **current day**.\n2. **Prechecks:** each given filter is validated. The call stops with an `Error` row if:\n - `LocId` is not in `Location`,\n - `ItemTag` is not `-6` or `-7`,\n - `Ean` is not a barcode (code type 1) in `pixi.ItemCode`,\n - `ItemNrInt` is not a shop item number (code type 2) in `pixi.ItemCode`,\n - `BinGroup` is not in `InvBin`,\n - `SupplierNr` is not in `Suppliers`,\n - `Category` matches neither `TontrArt` nor `TontrText` in `TontrArten`,\n - `BatchNumber` is not in `InvBinItem`.\n3. **Report:** the internal report procedure `Report_ItemsOnStockWithBatchManagement` is executed:\n - Only items tagged with tag `-6` (batch number) or `-7` (best-before date) are considered.\n - Bin stock from `InvBinItem` is summed per item, bin, batch number and best-before date (`QtyInBin`).\n - The best-before date filter is always applied. Rows whose `BestBeforeDate` lies between the two dates are included, and so are rows without a best-before date.\n - Optional filters:\n - `BatchNumber`: exact batch number.\n - `LocId`: location of the bin.\n - `Ean`: barcode of the item.\n - `ItemNrInt`: shop item number.\n - `ItemTag`: the item must carry this tag.\n - `SupplierNr`: the item is assigned to this supplier in `AddItems`.\n - `BinGroup`: bin group.\n - `Category`: the item's `ConfigType`, matched by code or text.\n4. The rows are sorted by `ItemName`, then `BinName`, and returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BatchNumber` | varchar(50) | No | Filter by exact batch number. Must exist in `InvBinItem`. Empty means no filter. |\n| `BestBeforeDateFrom` | datetime | No | Start of the best-before date range. Defaults to the start of the current day; only the date part is used. |\n| `BestBeforeDateTo` | datetime | No | End of the best-before date range. Defaults to the end of the current day; only the date part is used. |\n| `LocId` | varchar(3) | No | Location ID. Only bins of this location are included. Must exist in `Location`. |\n| `Ean` | varchar(13) | No | Barcode (item code type 1) of the item. Must exist in `pixi.ItemCode`. |\n| `ItemTag` | int | No | Restricts to items carrying this tag. `0` or empty means no filter. |\n| `SupplierNr` | varchar(4) | No | Supplier number. Only items assigned to this supplier (`AddItems`) are included. Must exist in `Suppliers`. |\n| `BinGroup` | varchar(20) | No | Bin group. Only bins of this group are included. Must exist in `InvBin`. |\n| `Category` | varchar(50) | No | Item category, given as code (`TontrArt`) or text (`TontrText`) from `TontrArten`. Matches the item's `ConfigType`. |\n| `ItemNrInt` | varchar(50) | No | Shop item number (item code type 2). Must exist in `pixi.ItemCode`. |\n\n- **Default date range is today only.** Without `BestBeforeDateFrom`/`BestBeforeDateTo`, only stock expiring today or without a best-before date is returned. Pass a wide range to get all batches.\n- The dates are passed to the inner report as `DATE`, so the time part is dropped. A `BestBeforeDate` on the end day with a time after midnight may be excluded.\n- The prechecks only test whether a matching record exists anywhere. For example, the `Ean` check accepts any existing barcode, not only barcodes of batch-managed items. Without a filter value, they still require at least one row in the respective table. An empty database or empty table therefore produces the corresponding error with an empty value.\n- The inner report builds its `WHERE` clause as dynamic SQL. Any SQL error raised there is caught and returned as an `Error` row with the original error text.\n- All reads use `NOLOCK`, so uncommitted data may appear.\n- The report internally also produces parameter echo columns (`ParamBatchNumber` etc.). These are not returned to the caller.\n\nDocumentation: https://pixi-api-docs.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": "Returns the stock per item, bin, batch number and best-before date for items with batch management, based on the pixi* report \"Items on stock with BN/BBD\".\n\nExposes the pixi* report *Items on stock with BN/BBD* (batch number / best-before date) as an API call.\n\n1. **Normalisation:** empty strings are treated as `NULL` for all text filters. `ItemTag` = `0` is treated as `NULL`. If `BestBeforeDateFrom` or `BestBeforeDateTo` is missing (or `1900-01-01`), it defaults to the start or end of the **current day**.\n2. **Prechecks:** each given filter is validated. The call stops with an `Error` row if:\n - `LocId` is not in `Location`,\n - `ItemTag` is not `-6` or `-7`,\n - `Ean` is not a barcode (code type 1) in `pixi.ItemCode`,\n - `ItemNrInt` is not a shop item number (code type 2) in `pixi.ItemCode`,\n - `BinGroup` is not in `InvBin`,\n - `SupplierNr` is not in `Suppliers`,\n - `Category` matches neither `TontrArt` nor `TontrText` in `TontrArten`,\n - `BatchNumber` is not in `InvBinItem`.\n3. **Report:** the internal report procedure `Report_ItemsOnStockWithBatchManagement` is executed:\n - Only items tagged with tag `-6` (batch number) or `-7` (best-before date) are considered.\n - Bin stock from `InvBinItem` is summed per item, bin, batch number and best-before date (`QtyInBin`).\n - The best-before date filter is always applied. Rows whose `BestBeforeDate` lies between the two dates are included, and so are rows without a best-before date.\n - Optional filters:\n - `BatchNumber`: exact batch number.\n - `LocId`: location of the bin.\n - `Ean`: barcode of the item.\n - `ItemNrInt`: shop item number.\n - `ItemTag`: the item must carry this tag.\n - `SupplierNr`: the item is assigned to this supplier in `AddItems`.\n - `BinGroup`: bin group.\n - `Category`: the item's `ConfigType`, matched by code or text.\n4. The rows are sorted by `ItemName`, then `BinName`, and returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `BatchNumber` | varchar(50) | No | Filter by exact batch number. Must exist in `InvBinItem`. Empty means no filter. |\n| `BestBeforeDateFrom` | datetime | No | Start of the best-before date range. Defaults to the start of the current day; only the date part is used. |\n| `BestBeforeDateTo` | datetime | No | End of the best-before date range. Defaults to the end of the current day; only the date part is used. |\n| `LocId` | varchar(3) | No | Location ID. Only bins of this location are included. Must exist in `Location`. |\n| `Ean` | varchar(13) | No | Barcode (item code type 1) of the item. Must exist in `pixi.ItemCode`. |\n| `ItemTag` | int | No | Restricts to items carrying this tag. `0` or empty means no filter. |\n| `SupplierNr` | varchar(4) | No | Supplier number. Only items assigned to this supplier (`AddItems`) are included. Must exist in `Suppliers`. |\n| `BinGroup` | varchar(20) | No | Bin group. Only bins of this group are included. Must exist in `InvBin`. |\n| `Category` | varchar(50) | No | Item category, given as code (`TontrArt`) or text (`TontrText`) from `TontrArten`. Matches the item's `ConfigType`. |\n| `ItemNrInt` | varchar(50) | No | Shop item number (item code type 2). Must exist in `pixi.ItemCode`. |\n\n- **Default date range is today only.** Without `BestBeforeDateFrom`/`BestBeforeDateTo`, only stock expiring today or without a best-before date is returned. Pass a wide range to get all batches.\n- The dates are passed to the inner report as `DATE`, so the time part is dropped. A `BestBeforeDate` on the end day with a time after midnight may be excluded.\n- The prechecks only test whether a matching record exists anywhere. For example, the `Ean` check accepts any existing barcode, not only barcodes of batch-managed items. Without a filter value, they still require at least one row in the respective table. An empty database or empty table therefore produces the corresponding error with an empty value.\n- The inner report builds its `WHERE` clause as dynamic SQL. Any SQL error raised there is caught and returned as an `Error` row with the original error text.\n- All reads use `NOLOCK`, so uncommitted data may appear.\n- The report internally also produces parameter echo columns (`ParamBatchNumber` etc.). These are not returned to the caller.\n\nDocumentation: https://pixi-api-docs.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": "Sets the stock quantity of an item on a bin to an absolute value by booking the difference as a scan-in or take-out stock movement.\n\nSets the quantity of one item on one bin to `NewStockQty`. The call does not overwrite the quantity directly. It calculates the difference to the current quantity and books that difference as a stock movement.\n\nSteps:\n\n1. Checks the setting `API_Stock_Movements`. If it is not enabled, the call returns a status row with `Status` = `ERROR` and stops.\n2. Checks that `SMORef` is a stock movement operation (`StockMovementOperations.SMOKey`) whose `Application` is `API`. If not, an error is raised.\n3. Looks up the item by `EANUPC` = `EanUpc`.\n4. Reads whether the item requires batch numbers or best-before dates (item tags `-6` and `-7`). If the item does not require them, `BatchNumber` and `BestBeforeDate` are ignored. If it requires them, they must be filled; otherwise nothing is booked.\n5. Looks up the bin by `BinName`. If `LocId` is given, only bins of that location are considered; otherwise the first bin with that name in any location is used, and its location is used for the booking.\n6. Calculates the difference: `NewStockQty` minus the sum of `BinItemQTY` of the item on that bin (all rows, regardless of batch or best-before date).\n - Difference > 0: books a scan-in (`Pixi_InvBinScanIn`) of the difference.\n - Difference < 0: books a take-out (`Pixi_InvBinTakeOut`) of the absolute difference.\n - Difference = 0: no booking.\n7. Before booking, the combination of `SMORef` and `SMTref` must exist in `StockMovementMatching`; otherwise an error is logged and raised.\n - If `SMTref` is not given, the call replaces **both** values: for a scan-in it uses the API operation `PutToStock` and movement type `0201`, for a take-out the API operation `TakeOut` and movement type `0301`.\n - If `SMTref` is given, the passed `SMORef` and `SMTref` are used.\n8. Finally the item is queued for stock recalculation and shop export (`Pixi_ExportItemChangesToShop`), also when nothing was booked.\n\nThe procedure has a return code: `0` = processed, `1` = item not found or required batch number / best-before date missing, `2` = bin not found. On success no result set is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `EanUpc` | varchar(13) | Yes | EAN/UPC of the item (`Items.EANUPC`). |\n| `BinName` | varchar(50) | Yes | Name of the bin (`InvBin.BinName`) whose stock is set. |\n| `LocId` | varchar(3) | No | Location (warehouse) ID of the bin. If `NULL`, the first bin with the given name in any location is used. |\n| `NewStockQty` | int | Yes | Target quantity of the item on the bin. |\n| `Username` | varchar(50) | No | User name recorded for the stock movement. |\n| `SMORef` | int | No | Key of the stock movement operation (`StockMovementOperations.SMOKey`). Must belong to application `API`; effectively required. Replaced by `PutToStock`/`TakeOut` if `SMTref` is not given. |\n| `SMTref` | int | No | Key of the stock movement type (`StockMovementTypes.SMTKey`). Must be matched to `SMORef` in `StockMovementMatching`. If `NULL`, type `0201` (scan-in) or `0301` (take-out) is used. |\n| `BatchNumber` | varchar(50) | No | Batch number (Charge). Required for items with the batch number tag, ignored otherwise. |\n| `BestBeforeDate` | datetime | No | Best-before date. Required for items with the best-before date tag, ignored otherwise. The default `''` equals `1900-01-01` and counts as empty. |\n\n- `SMORef` has the default `NULL`, but the call always fails with *SMO is not assigned to API* if it is left out. Pass the key of an API stock movement operation.\n- The return codes `1` and `2` are only the procedure's return value; no status row is returned. Depending on the client, a missing item or bin may therefore look like a success.\n- If `SMTref` is omitted, the passed `SMORef` is only used for the initial check and then replaced by the `PutToStock`/`TakeOut` operation.\n- The difference is calculated over all batches and best-before dates on the bin, but booked with the given `BatchNumber`/`BestBeforeDate`. For items with batches the result per batch may differ from what is expected.\n- `BestBeforeDate` defaults to `''`, which SQL Server converts to `1900-01-01`. This value is treated as empty, so items with a best-before date tag need a real date.\n- Without `LocId`, `TOP 1` without `ORDER BY` is used to pick the bin; if the bin name exists in several locations the choice is not deterministic.\n- Lookups use `NOLOCK`.\n- The called procedures `Pixi_InvBinScanIn`/`Pixi_InvBinTakeOut` reject quantities above the setting `MaxStockOperationLimit` and run in their own transaction; their base procedures are not attached. Errors inside the base procedures are logged via `log.InsertError` and may not reach the caller.\n- Errors raised by the called procedures end in the CATCH block of this call, which writes an entry to `LogTable` and raises an error with the content of the internal error variable. For errors not produced by this procedure itself, that message is empty, so the original error text is lost.\n- For the *SMT is not matched* error, `LogTable` receives two entries (one before raising, one in the CATCH block).\n- Every call that passes the initial checks inserts a row into `pixi.ItemRecalculateStockQueue`, even if no booking was made or the item was not found.\n\nDocumentation: https://pixi-api-docs.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": "Sets the stock quantity of an item on a bin to an absolute value by booking the difference as a scan-in or take-out stock movement.\n\nSets the quantity of one item on one bin to `NewStockQty`. The call does not overwrite the quantity directly. It calculates the difference to the current quantity and books that difference as a stock movement.\n\nSteps:\n\n1. Checks the setting `API_Stock_Movements`. If it is not enabled, the call returns a status row with `Status` = `ERROR` and stops.\n2. Checks that `SMORef` is a stock movement operation (`StockMovementOperations.SMOKey`) whose `Application` is `API`. If not, an error is raised.\n3. Looks up the item by `EANUPC` = `EanUpc`.\n4. Reads whether the item requires batch numbers or best-before dates (item tags `-6` and `-7`). If the item does not require them, `BatchNumber` and `BestBeforeDate` are ignored. If it requires them, they must be filled; otherwise nothing is booked.\n5. Looks up the bin by `BinName`. If `LocId` is given, only bins of that location are considered; otherwise the first bin with that name in any location is used, and its location is used for the booking.\n6. Calculates the difference: `NewStockQty` minus the sum of `BinItemQTY` of the item on that bin (all rows, regardless of batch or best-before date).\n - Difference > 0: books a scan-in (`Pixi_InvBinScanIn`) of the difference.\n - Difference < 0: books a take-out (`Pixi_InvBinTakeOut`) of the absolute difference.\n - Difference = 0: no booking.\n7. Before booking, the combination of `SMORef` and `SMTref` must exist in `StockMovementMatching`; otherwise an error is logged and raised.\n - If `SMTref` is not given, the call replaces **both** values: for a scan-in it uses the API operation `PutToStock` and movement type `0201`, for a take-out the API operation `TakeOut` and movement type `0301`.\n - If `SMTref` is given, the passed `SMORef` and `SMTref` are used.\n8. Finally the item is queued for stock recalculation and shop export (`Pixi_ExportItemChangesToShop`), also when nothing was booked.\n\nThe procedure has a return code: `0` = processed, `1` = item not found or required batch number / best-before date missing, `2` = bin not found. On success no result set is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `EanUpc` | varchar(13) | Yes | EAN/UPC of the item (`Items.EANUPC`). |\n| `BinName` | varchar(50) | Yes | Name of the bin (`InvBin.BinName`) whose stock is set. |\n| `LocId` | varchar(3) | No | Location (warehouse) ID of the bin. If `NULL`, the first bin with the given name in any location is used. |\n| `NewStockQty` | int | Yes | Target quantity of the item on the bin. |\n| `Username` | varchar(50) | No | User name recorded for the stock movement. |\n| `SMORef` | int | No | Key of the stock movement operation (`StockMovementOperations.SMOKey`). Must belong to application `API`; effectively required. Replaced by `PutToStock`/`TakeOut` if `SMTref` is not given. |\n| `SMTref` | int | No | Key of the stock movement type (`StockMovementTypes.SMTKey`). Must be matched to `SMORef` in `StockMovementMatching`. If `NULL`, type `0201` (scan-in) or `0301` (take-out) is used. |\n| `BatchNumber` | varchar(50) | No | Batch number (Charge). Required for items with the batch number tag, ignored otherwise. |\n| `BestBeforeDate` | datetime | No | Best-before date. Required for items with the best-before date tag, ignored otherwise. The default `''` equals `1900-01-01` and counts as empty. |\n\n- `SMORef` has the default `NULL`, but the call always fails with *SMO is not assigned to API* if it is left out. Pass the key of an API stock movement operation.\n- The return codes `1` and `2` are only the procedure's return value; no status row is returned. Depending on the client, a missing item or bin may therefore look like a success.\n- If `SMTref` is omitted, the passed `SMORef` is only used for the initial check and then replaced by the `PutToStock`/`TakeOut` operation.\n- The difference is calculated over all batches and best-before dates on the bin, but booked with the given `BatchNumber`/`BestBeforeDate`. For items with batches the result per batch may differ from what is expected.\n- `BestBeforeDate` defaults to `''`, which SQL Server converts to `1900-01-01`. This value is treated as empty, so items with a best-before date tag need a real date.\n- Without `LocId`, `TOP 1` without `ORDER BY` is used to pick the bin; if the bin name exists in several locations the choice is not deterministic.\n- Lookups use `NOLOCK`.\n- The called procedures `Pixi_InvBinScanIn`/`Pixi_InvBinTakeOut` reject quantities above the setting `MaxStockOperationLimit` and run in their own transaction; their base procedures are not attached. Errors inside the base procedures are logged via `log.InsertError` and may not reach the caller.\n- Errors raised by the called procedures end in the CATCH block of this call, which writes an entry to `LogTable` and raises an error with the content of the internal error variable. For errors not produced by this procedure itself, that message is empty, so the original error text is lost.\n- For the *SMT is not matched* error, `LogTable` receives two entries (one before raising, one in the CATCH block).\n- Every call that passes the initial checks inserts a row into `pixi.ItemRecalculateStockQueue`, even if no booking was made or the item was not found.\n\nDocumentation: https://pixi-api-docs.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": "Sets or changes the stock of items on Lagerplätze (bins) from an XML document and returns one result row per processed bin entry.\n\nProcesses a list of items with bin entries and books stock movements (put to stock / take out) for each entry.\n\n**Steps**\n\n1. Checks the setting `API_Stock_Movements`. If it is not enabled, a single `ERROR` row is returned and nothing else happens.\n2. If `ParameterXML` is not empty, it replaces `XML`. The whole XML text is converted to upper case (element names **and** values).\n3. The XML is read from `/ITEMSTOCK/ITEM/INVBINS/INVBIN`. Per `ITEM`: `ITEMKEY`, `ITEMNRINT`, `EANUPC`, `OVERWRITESTOCK`. Per `INVBIN`: `BINNAME`, `STOCK`, `STOCKADD`, `STOCKREMOVE`, `NEUTRALINVENTORY`, `SMTREF`, `SMOREF`, `BATCHNUMBER`, `BESTBEFOREDATE`. Empty `SMTREF`, `SMOREF`, `BATCHNUMBER` and `BESTBEFOREDATE` are treated as NULL.\n4. The item is resolved in this order: by `ITEMKEY`, then by `ITEMNRINT`, then by `EANUPC`. Item key, item number and EAN of the found item are filled in.\n5. If `OVERWRITESTOCK` = 1, an additional entry with target stock 0 is added for every other bin (by bin name) that holds a positive stock of the item and is not listed in the XML – so the item's stock is cleared there.\n6. If the highest `STOCK` (or `STOCKADD` when `STOCK` is empty) exceeds the setting `MaxStockOperationLimit`, the call aborts with an error before any stock is changed.\n7. Each entry with a found item and an existing bin name is processed:\n - If the item is tagged for Charge/batch number (tag -6) but no `BATCHNUMBER` is given, or tagged for best-before date (tag -7) but no `BESTBEFOREDATE` is given, the entry is skipped. If the item has no such tag, the value is ignored.\n - If `STOCK` is set, the difference to the current stock on all bins with this name is calculated. A positive difference becomes a put-to-stock quantity, a negative difference a take-out quantity; a difference of 0 yields the success message `No stock change needed`.\n - Otherwise `STOCKADD` / `STOCKREMOVE` are booked as given.\n - If `SMOREF` or `SMTREF` is missing, defaults are used: stock movement operation `API`/`PutToStock` with stock movement type `0201` for additions, `API`/`TakeOut` with type `0301` for removals.\n - The SMO/SMT combination must exist in the stock movement matching table; otherwise the entry fails with an error message.\n - The booking is done by `Pixi_InvBinScanIn` (addition) or `Pixi_InvBinTakeOut` (removal) with the given `Username`, Charge and best-before date.\n8. One result row per entry is returned: processed entries with their success or error message, entries whose item or bin was not found, and remaining unprocessed entries with the batch/best-before message.\n9. All resolved items are added to `pixi.ItemRecalculateStockQueue` for stock recalculation and export.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | No | XML document with items and their bin entries (root `ITEMSTOCK`). Ignored if `ParameterXML` is not empty. |\n| `ParameterXML` | varchar(max) | No | Alternative to `XML` with the same structure. If not empty, it is used instead of `XML`. |\n| `Username` | varchar(50) | No | User name recorded for the stock movements. NULL is replaced by `pipiSetStockMultiple`. |\n\n- **No overall transaction:** every booking is committed separately by `Pixi_InvBinScanIn` / `Pixi_InvBinTakeOut`. A call can succeed partially; check `status` per row.\n- The XML is converted to upper case completely, so bin names and batch numbers (Charge) are processed in upper case.\n- Omit numeric elements instead of sending them empty: an empty `STOCK` may be read as 0 and would then set the stock to 0.\n- Bins are identified by `BINNAME` only. If the same bin name exists in several locations, the current stock is summed over all of them and the location is taken from an arbitrary matching bin (`TOP 1`). The setting `FilterStockOperationsWithLocation` is read but not used.\n- `OVERWRITESTOCK` = 1 clears the item on all other bins with positive stock, in all locations.\n- `MaxStockOperationLimit` is checked here only for `STOCK`/`STOCKADD`. The called procedures check the quantity again (also for take-outs); such an error is caught, logged and returned as a row with `status` 0 and an empty `Error`.\n- Do not combine `STOCK` with `STOCKADD`/`STOCKREMOVE` in the same entry: the explicit values may still be booked in addition. The calculated difference is also not reset between entries, which can affect entries without `STOCK`.\n- If the SMO is not assigned to application `API`, only an informational message (severity 10) is sent; the row is then reported with the misleading batch/best-before message.\n- Entries without any quantity to book (e.g. only `NEUTRALINVENTORY`, which is read but not used) also receive the batch/best-before message.\n- In the result, `STOCKADD`/`STOCKREMOVE`/`SMOREF`/`SMTREF` show the input values, not the calculated or default values. `Reason` is empty for XML entries and holds the bin item reason for entries added by `OVERWRITESTOCK`. The result has no defined sort order.\n- SMT/SMO mismatches and caught errors are written to `LogTable`. Texts returned by the booking procedures come from `Pixi_InvBinScanIn_Base` / `Pixi_InvBinTakeOut_Base`, which are not attached.\n- Lookups use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Sets or changes the stock of items on Lagerplätze (bins) from an XML document and returns one result row per processed bin entry.\n\nProcesses a list of items with bin entries and books stock movements (put to stock / take out) for each entry.\n\n**Steps**\n\n1. Checks the setting `API_Stock_Movements`. If it is not enabled, a single `ERROR` row is returned and nothing else happens.\n2. If `ParameterXML` is not empty, it replaces `XML`. The whole XML text is converted to upper case (element names **and** values).\n3. The XML is read from `/ITEMSTOCK/ITEM/INVBINS/INVBIN`. Per `ITEM`: `ITEMKEY`, `ITEMNRINT`, `EANUPC`, `OVERWRITESTOCK`. Per `INVBIN`: `BINNAME`, `STOCK`, `STOCKADD`, `STOCKREMOVE`, `NEUTRALINVENTORY`, `SMTREF`, `SMOREF`, `BATCHNUMBER`, `BESTBEFOREDATE`. Empty `SMTREF`, `SMOREF`, `BATCHNUMBER` and `BESTBEFOREDATE` are treated as NULL.\n4. The item is resolved in this order: by `ITEMKEY`, then by `ITEMNRINT`, then by `EANUPC`. Item key, item number and EAN of the found item are filled in.\n5. If `OVERWRITESTOCK` = 1, an additional entry with target stock 0 is added for every other bin (by bin name) that holds a positive stock of the item and is not listed in the XML – so the item's stock is cleared there.\n6. If the highest `STOCK` (or `STOCKADD` when `STOCK` is empty) exceeds the setting `MaxStockOperationLimit`, the call aborts with an error before any stock is changed.\n7. Each entry with a found item and an existing bin name is processed:\n - If the item is tagged for Charge/batch number (tag -6) but no `BATCHNUMBER` is given, or tagged for best-before date (tag -7) but no `BESTBEFOREDATE` is given, the entry is skipped. If the item has no such tag, the value is ignored.\n - If `STOCK` is set, the difference to the current stock on all bins with this name is calculated. A positive difference becomes a put-to-stock quantity, a negative difference a take-out quantity; a difference of 0 yields the success message `No stock change needed`.\n - Otherwise `STOCKADD` / `STOCKREMOVE` are booked as given.\n - If `SMOREF` or `SMTREF` is missing, defaults are used: stock movement operation `API`/`PutToStock` with stock movement type `0201` for additions, `API`/`TakeOut` with type `0301` for removals.\n - The SMO/SMT combination must exist in the stock movement matching table; otherwise the entry fails with an error message.\n - The booking is done by `Pixi_InvBinScanIn` (addition) or `Pixi_InvBinTakeOut` (removal) with the given `Username`, Charge and best-before date.\n8. One result row per entry is returned: processed entries with their success or error message, entries whose item or bin was not found, and remaining unprocessed entries with the batch/best-before message.\n9. All resolved items are added to `pixi.ItemRecalculateStockQueue` for stock recalculation and export.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | No | XML document with items and their bin entries (root `ITEMSTOCK`). Ignored if `ParameterXML` is not empty. |\n| `ParameterXML` | varchar(max) | No | Alternative to `XML` with the same structure. If not empty, it is used instead of `XML`. |\n| `Username` | varchar(50) | No | User name recorded for the stock movements. NULL is replaced by `pipiSetStockMultiple`. |\n\n- **No overall transaction:** every booking is committed separately by `Pixi_InvBinScanIn` / `Pixi_InvBinTakeOut`. A call can succeed partially; check `status` per row.\n- The XML is converted to upper case completely, so bin names and batch numbers (Charge) are processed in upper case.\n- Omit numeric elements instead of sending them empty: an empty `STOCK` may be read as 0 and would then set the stock to 0.\n- Bins are identified by `BINNAME` only. If the same bin name exists in several locations, the current stock is summed over all of them and the location is taken from an arbitrary matching bin (`TOP 1`). The setting `FilterStockOperationsWithLocation` is read but not used.\n- `OVERWRITESTOCK` = 1 clears the item on all other bins with positive stock, in all locations.\n- `MaxStockOperationLimit` is checked here only for `STOCK`/`STOCKADD`. The called procedures check the quantity again (also for take-outs); such an error is caught, logged and returned as a row with `status` 0 and an empty `Error`.\n- Do not combine `STOCK` with `STOCKADD`/`STOCKREMOVE` in the same entry: the explicit values may still be booked in addition. The calculated difference is also not reset between entries, which can affect entries without `STOCK`.\n- If the SMO is not assigned to application `API`, only an informational message (severity 10) is sent; the row is then reported with the misleading batch/best-before message.\n- Entries without any quantity to book (e.g. only `NEUTRALINVENTORY`, which is read but not used) also receive the batch/best-before message.\n- In the result, `STOCKADD`/`STOCKREMOVE`/`SMOREF`/`SMTREF` show the input values, not the calculated or default values. `Reason` is empty for XML entries and holds the bin item reason for entries added by `OVERWRITESTOCK`. The result has no defined sort order.\n- SMT/SMO mismatches and caught errors are written to `LogTable`. Texts returned by the booking procedures come from `Pixi_InvBinScanIn_Base` / `Pixi_InvBinTakeOut_Base`, which are not attached.\n- Lookups use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Sets, adds or removes stock for several items and bins (Lagerplätze) in one call, based on an XML document with stock levels per bin.\n\nProcesses an XML document with one or more items and their bins and books the stock changes as stock movements.\n\n**Input**\n- If `ParameterXML` is not empty, it replaces `XML`.\n- The whole XML text is converted to upper case before parsing. This applies to element names and to all values, including bin names and batch numbers.\n- Rows are read from `/ITEMSTOCK/ITEM/INVBINS/INVBIN`. Each `INVBIN` becomes one row. The item fields `ITEMNRINT`, `ITEMKEY`, `EANUPC` and `OVERWRITESTOCK` are read from the parent `ITEM`.\n- Empty `SMTREF`, `SMOREF`, `BATCHNUMBER` and `BESTBEFOREDATE` are treated as NULL.\n\n**Item lookup**\nThe item is resolved in this order:\n1. by `ITEMKEY`\n2. by `ITEMNRINT`, if no key was found\n3. by `EANUPC`, if still no key was found\n\nItem key, item number and EAN are then taken from the item master.\n\n**Overwrite mode**\nIf `OVERWRITESTOCK` = 1 for an item, the call adds a row with target stock 0 for every other bin of that item that currently holds stock (sum of quantities > 0) and is not listed in the XML. These bins are emptied.\n\n**Processing per row**\nOnly rows with a resolved item and an existing bin name are processed, one by one:\n- If the item has the batch number tag but the row has no `BATCHNUMBER`, the row is skipped without any message. If the item has no batch tag, a given batch number is ignored. The same rule applies to the best-before-date tag and `BESTBEFOREDATE`.\n- If `STOCK` is given, the difference to the current quantity in the bin is calculated. A positive difference becomes `StockAdd`, a negative one becomes `StockRemove`. With no difference, a row with status 1 and `No stock change needed` is recorded.\n- If `SMOREF` or `SMTREF` is missing, defaults are used:\n - for additions: operation `API`/`PutToStock` and movement type `0201`\n - for removals: operation `API`/`TakeOut` and movement type `0301`\n- The stock movement operation must belong to application `API`, and the operation/type pair must exist in the stock movement matching table. Otherwise the row is not booked.\n- For `StockAdd` > 0 the stock is booked in with `Pixi_InvBinScanIn`. Otherwise, for `StockRemove` > 0, it is taken out with `Pixi_InvBinTakeOut`. The location is the `BinLocID` of the first bin with that name.\n\n**Result and follow-up**\n- The final result set lists the processed rows with their status and message.\n- Rows whose item or bin could not be found are added with status 0.\n- All resolved items are inserted into `pixi.ItemRecalculateStockQueue` for stock recalculation and export.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | No | XML document with items and their bins and stock values. Ignored if `ParameterXML` is not empty. |\n| `ParameterXML` | varchar(max) | No | Alternative input with the same structure as `XML`. Takes precedence over `XML` if not empty. |\n| `Username` | varchar(50) | No | User name recorded for the stock movements. |\n\n- **Extra result sets:** for every processed row the code runs an unaliased `SELECT` of the current `SMTREF` value. Each of these is returned as its own result set. The actual status result set therefore comes last, after one extra result set per processed row. Read the last `SqlRowSetN`.\n- **Upper case:** because the XML is upper-cased, batch numbers are booked in upper case.\n- **`STOCK` element:** an empty `` is converted to 0 and empties the bin. Leave the element out if no absolute value is intended.\n- **Combining fields:** when `STOCK` is given, the computed difference overwrites only one of `StockAdd`/`StockRemove`. A `STOCKADD` sent in the XML can therefore still trigger a scan-in when the difference is negative or zero. Do not combine `STOCK` with `STOCKADD`/`STOCKREMOVE`.\n- **Variable `@delta` is not reset per row:** for rows without `STOCK`, the validation checks use the difference of the previous row. For the first such row the value is NULL, so the SMO check is skipped.\n- **Rows missing from the result:** rows skipped because of a missing batch number or best-before date, and rows failing the \"SMO not assigned to API\" check, produce no result row.\n- **What is ignored:** `NEUTRALINVENTORY` is read but not used. The setting `FilterStockOperationsWithLocation` is read but not passed on.\n- **Current quantity:** the difference is calculated over all bins with the same name and over all batches. The location is taken with `TOP 1` without ordering, so duplicate bin names across locations can lead to unexpected bookings.\n- **Transactions:** there is no overall transaction. Each booking runs in its own transaction inside `Pixi_InvBinScanIn`/`Pixi_InvBinTakeOut`. A failing row does not roll back earlier rows.\n- **Called procedures:** `Pixi_InvBinScanIn_Base` and `Pixi_InvBinTakeOut_Base` are not attached, so their exact checks and messages are unknown. The quantity limit `MaxStockOperationLimit` applies.\n- Master data reads use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Sets, adds or removes stock for several items and bins (Lagerplätze) in one call, based on an XML document with stock levels per bin.\n\nProcesses an XML document with one or more items and their bins and books the stock changes as stock movements.\n\n**Input**\n- If `ParameterXML` is not empty, it replaces `XML`.\n- The whole XML text is converted to upper case before parsing. This applies to element names and to all values, including bin names and batch numbers.\n- Rows are read from `/ITEMSTOCK/ITEM/INVBINS/INVBIN`. Each `INVBIN` becomes one row. The item fields `ITEMNRINT`, `ITEMKEY`, `EANUPC` and `OVERWRITESTOCK` are read from the parent `ITEM`.\n- Empty `SMTREF`, `SMOREF`, `BATCHNUMBER` and `BESTBEFOREDATE` are treated as NULL.\n\n**Item lookup**\nThe item is resolved in this order:\n1. by `ITEMKEY`\n2. by `ITEMNRINT`, if no key was found\n3. by `EANUPC`, if still no key was found\n\nItem key, item number and EAN are then taken from the item master.\n\n**Overwrite mode**\nIf `OVERWRITESTOCK` = 1 for an item, the call adds a row with target stock 0 for every other bin of that item that currently holds stock (sum of quantities > 0) and is not listed in the XML. These bins are emptied.\n\n**Processing per row**\nOnly rows with a resolved item and an existing bin name are processed, one by one:\n- If the item has the batch number tag but the row has no `BATCHNUMBER`, the row is skipped without any message. If the item has no batch tag, a given batch number is ignored. The same rule applies to the best-before-date tag and `BESTBEFOREDATE`.\n- If `STOCK` is given, the difference to the current quantity in the bin is calculated. A positive difference becomes `StockAdd`, a negative one becomes `StockRemove`. With no difference, a row with status 1 and `No stock change needed` is recorded.\n- If `SMOREF` or `SMTREF` is missing, defaults are used:\n - for additions: operation `API`/`PutToStock` and movement type `0201`\n - for removals: operation `API`/`TakeOut` and movement type `0301`\n- The stock movement operation must belong to application `API`, and the operation/type pair must exist in the stock movement matching table. Otherwise the row is not booked.\n- For `StockAdd` > 0 the stock is booked in with `Pixi_InvBinScanIn`. Otherwise, for `StockRemove` > 0, it is taken out with `Pixi_InvBinTakeOut`. The location is the `BinLocID` of the first bin with that name.\n\n**Result and follow-up**\n- The final result set lists the processed rows with their status and message.\n- Rows whose item or bin could not be found are added with status 0.\n- All resolved items are inserted into `pixi.ItemRecalculateStockQueue` for stock recalculation and export.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `XML` | varchar(max) | No | XML document with items and their bins and stock values. Ignored if `ParameterXML` is not empty. |\n| `ParameterXML` | varchar(max) | No | Alternative input with the same structure as `XML`. Takes precedence over `XML` if not empty. |\n| `Username` | varchar(50) | No | User name recorded for the stock movements. |\n\n- **Extra result sets:** for every processed row the code runs an unaliased `SELECT` of the current `SMTREF` value. Each of these is returned as its own result set. The actual status result set therefore comes last, after one extra result set per processed row. Read the last `SqlRowSetN`.\n- **Upper case:** because the XML is upper-cased, batch numbers are booked in upper case.\n- **`STOCK` element:** an empty `` is converted to 0 and empties the bin. Leave the element out if no absolute value is intended.\n- **Combining fields:** when `STOCK` is given, the computed difference overwrites only one of `StockAdd`/`StockRemove`. A `STOCKADD` sent in the XML can therefore still trigger a scan-in when the difference is negative or zero. Do not combine `STOCK` with `STOCKADD`/`STOCKREMOVE`.\n- **Variable `@delta` is not reset per row:** for rows without `STOCK`, the validation checks use the difference of the previous row. For the first such row the value is NULL, so the SMO check is skipped.\n- **Rows missing from the result:** rows skipped because of a missing batch number or best-before date, and rows failing the \"SMO not assigned to API\" check, produce no result row.\n- **What is ignored:** `NEUTRALINVENTORY` is read but not used. The setting `FilterStockOperationsWithLocation` is read but not passed on.\n- **Current quantity:** the difference is calculated over all bins with the same name and over all batches. The location is taken with `TOP 1` without ordering, so duplicate bin names across locations can lead to unexpected bookings.\n- **Transactions:** there is no overall transaction. Each booking runs in its own transaction inside `Pixi_InvBinScanIn`/`Pixi_InvBinTakeOut`. A failing row does not roll back earlier rows.\n- **Called procedures:** `Pixi_InvBinScanIn_Base` and `Pixi_InvBinTakeOut_Base` are not attached, so their exact checks and messages are unknown. The quantity limit `MaxStockOperationLimit` applies.\n- Master data reads use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Synchronises the stock of one supplier's items on a bin with a list of supplier item numbers and quantities, then returns the resulting bin stock.\n\nTakes a list of supplier item numbers with target quantities and tries to make the stock of the given bin match it.\n\n1. The XML in `Items` is parsed: each `/ITEMS/ITEM` node gives `ItemNrSuppl` and `Quantity`.\n2. The bin is looked up in `InvBin` by `Location` (`BinLocID`) and `BinName`. If no bin is found, a single row with `Code` = `500` and `Message` = `Bin Not Found` is returned and nothing else happens.\n3. The items to change are determined:\n - Items from the XML whose `ItemNrSuppl` matches an `AddItems` entry of supplier `SupplNr`, whose article is enabled (`Items.Enabled = 1`), and whose target quantity differs from the current total quantity on the bin (missing stock counts as 0).\n - Items of the same supplier that currently have stock on the bin but are **not** listed in the XML. Their target quantity is 0, so they are meant to be cleared from the bin. The `Enabled` flag is not checked for these.\n4. For every such item, `pixiSetStock` is executed with the article's `EANUPC`, the `BinName`, the target quantity and `Username`.\n5. Finally one row per article is returned with the supplier item number and the total quantity that is now on the bin, restricted to articles that have an `AddItems` entry for `SupplNr`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Items` | xml | Yes | List of supplier item numbers with target quantities for the bin. Root `ITEMS`, one `ITEM` per article with `ItemNrSuppl` and `Quantity` (integer). |\n| `SupplNr` | varchar(4) | No | Supplier number (`AddItems.SupplNr`) used to resolve the supplier item numbers and to restrict the items on the bin. |\n| `Location` | varchar(3) | No | Location ID (`InvBin.BinLocID`) used to find the bin. It is not passed on to `pixiSetStock`. |\n| `BinName` | varchar(50) | Yes | Name of the bin (`InvBin.BinName`) whose stock is synchronised. |\n| `Username` | varchar(50) | No | User name passed to `pixiSetStock` for the stock movements. |\n\n- **Stock is in practice not changed.** A comment in the code states that the call to `pixiSetStock` always fails because no `SMORef` is passed. `pixiSetStock` raises `Error Message: API pipiSetStockMultiple: SMO is not assigned to API!` whenever `SMORef` is NULL, writes an entry to `LogTable` and re-raises the error. The outer procedure has no error handling, so it continues with the next item and the error messages reach the caller as `SqlMessage` entries next to the final result set.\n- If the setting `API_Stock_Movements` is disabled, `pixiSetStock` returns an extra status row (`Status`/`StatusMessage`) for every item to change instead of raising an error. These rows arrive as additional result sets before the final stock list, which shifts the numbering of `SqlRowSet`.\n- `pixiSetStock` is called without a location. It looks up the bin by `BinName` only, so if the same bin name exists in several locations, a different bin than the one checked here may be used.\n- Articles are passed to `pixiSetStock` by `EANUPC`. Articles without an EAN or with a duplicate EAN cannot be addressed reliably.\n- If any `ITEM` in the XML has no `ItemNrSuppl`, the `NOT IN` check returns no rows, so no items are cleared from the bin.\n- Items whose `Quantity` is missing or not numeric are ignored for the update.\n- All reads use `NOLOCK`. There is no transaction around the loop.\n\nDocumentation: https://pixi-api-docs.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": "Synchronises the stock of one supplier's items on a bin with a list of supplier item numbers and quantities, then returns the resulting bin stock.\n\nTakes a list of supplier item numbers with target quantities and tries to make the stock of the given bin match it.\n\n1. The XML in `Items` is parsed: each `/ITEMS/ITEM` node gives `ItemNrSuppl` and `Quantity`.\n2. The bin is looked up in `InvBin` by `Location` (`BinLocID`) and `BinName`. If no bin is found, a single row with `Code` = `500` and `Message` = `Bin Not Found` is returned and nothing else happens.\n3. The items to change are determined:\n - Items from the XML whose `ItemNrSuppl` matches an `AddItems` entry of supplier `SupplNr`, whose article is enabled (`Items.Enabled = 1`), and whose target quantity differs from the current total quantity on the bin (missing stock counts as 0).\n - Items of the same supplier that currently have stock on the bin but are **not** listed in the XML. Their target quantity is 0, so they are meant to be cleared from the bin. The `Enabled` flag is not checked for these.\n4. For every such item, `pixiSetStock` is executed with the article's `EANUPC`, the `BinName`, the target quantity and `Username`.\n5. Finally one row per article is returned with the supplier item number and the total quantity that is now on the bin, restricted to articles that have an `AddItems` entry for `SupplNr`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Items` | xml | Yes | List of supplier item numbers with target quantities for the bin. Root `ITEMS`, one `ITEM` per article with `ItemNrSuppl` and `Quantity` (integer). |\n| `SupplNr` | varchar(4) | No | Supplier number (`AddItems.SupplNr`) used to resolve the supplier item numbers and to restrict the items on the bin. |\n| `Location` | varchar(3) | No | Location ID (`InvBin.BinLocID`) used to find the bin. It is not passed on to `pixiSetStock`. |\n| `BinName` | varchar(50) | Yes | Name of the bin (`InvBin.BinName`) whose stock is synchronised. |\n| `Username` | varchar(50) | No | User name passed to `pixiSetStock` for the stock movements. |\n\n- **Stock is in practice not changed.** A comment in the code states that the call to `pixiSetStock` always fails because no `SMORef` is passed. `pixiSetStock` raises `Error Message: API pipiSetStockMultiple: SMO is not assigned to API!` whenever `SMORef` is NULL, writes an entry to `LogTable` and re-raises the error. The outer procedure has no error handling, so it continues with the next item and the error messages reach the caller as `SqlMessage` entries next to the final result set.\n- If the setting `API_Stock_Movements` is disabled, `pixiSetStock` returns an extra status row (`Status`/`StatusMessage`) for every item to change instead of raising an error. These rows arrive as additional result sets before the final stock list, which shifts the numbering of `SqlRowSet`.\n- `pixiSetStock` is called without a location. It looks up the bin by `BinName` only, so if the same bin name exists in several locations, a different bin than the one checked here may be used.\n- Articles are passed to `pixiSetStock` by `EANUPC`. Articles without an EAN or with a duplicate EAN cannot be addressed reliably.\n- If any `ITEM` in the XML has no `ItemNrSuppl`, the `NOT IN` check returns no rows, so no items are cleared from the bin.\n- Items whose `Quantity` is missing or not numeric are ignored for the update.\n- All reads use `NOLOCK`. There is no transaction around the loop.\n\nDocumentation: https://pixi-api-docs.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": "Resets the shop stock export marker in InvBinItemLog so that all stock changes since a given date are reported to the shop again.\n\nControls which stock changes in the stock change log `InvBinItemLog` count as not yet reported to the shop.\n\n1. If `Since` is not passed, the current date and time (`GETDATE()`) is used. Every entry is then marked as reported.\n2. All entries with `UpdateDate` before `Since` that are not yet reported (`ReportedDate IS NULL`) are marked as reported. `ReportedDate` is set to their `UpdateDate`.\n3. All entries with `UpdateDate` on or after `Since` are marked as not reported. `ReportedDate` is set to `NULL`, even if they were reported before.\n4. The call returns the number of log entries that are now not reported. This is the number of stock changes that are still to be exported to the shop.\n\nOnly normal items are handled. A code comment says that bundles are not supported yet.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | No | Point in time from which stock changes are reported to the shop again. Changes before this time are marked as reported. If omitted or `NULL`, the current date and time is used. |\n\n- Without `Since`, the call marks the complete log as reported. Afterwards no pending stock change is left for the shop export.\n- The two `UPDATE` statements do not run in an explicit transaction.\n- The final count is read with `NOLOCK` and can therefore include uncommitted changes.\n- The count refers to log entries, not to distinct items or bins.\n- On large logs the updates can touch many rows and may take some time.\n\nDocumentation: https://pixi-api-docs.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": "Resets the shop stock export marker in InvBinItemLog so that all stock changes since a given date are reported to the shop again.\n\nControls which stock changes in the stock change log `InvBinItemLog` count as not yet reported to the shop.\n\n1. If `Since` is not passed, the current date and time (`GETDATE()`) is used. Every entry is then marked as reported.\n2. All entries with `UpdateDate` before `Since` that are not yet reported (`ReportedDate IS NULL`) are marked as reported. `ReportedDate` is set to their `UpdateDate`.\n3. All entries with `UpdateDate` on or after `Since` are marked as not reported. `ReportedDate` is set to `NULL`, even if they were reported before.\n4. The call returns the number of log entries that are now not reported. This is the number of stock changes that are still to be exported to the shop.\n\nOnly normal items are handled. A code comment says that bundles are not supported yet.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `Since` | datetime | No | Point in time from which stock changes are reported to the shop again. Changes before this time are marked as reported. If omitted or `NULL`, the current date and time is used. |\n\n- Without `Since`, the call marks the complete log as reported. Afterwards no pending stock change is left for the shop export.\n- The two `UPDATE` statements do not run in an explicit transaction.\n- The final count is read with `NOLOCK` and can therefore include uncommitted changes.\n- The count refers to log entries, not to distinct items or bins.\n- On large logs the updates can touch many rows and may take some time.\n\nDocumentation: https://pixi-api-docs.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": "Returns the available stock quantity of all items for the shop stock export, optionally without zero stock and without stock in excluded bin groups.\n\nReturns one row per item with the internal item number and the quantity that can be exported to the shop.\n\nThe behaviour depends on the setting `OldStockExport`:\n\n- **`OldStockExport` = 1:** the procedure collects `Quantity` from `Items` into a temporary table, but **returns no result set** (the final `SELECT` is only in the other branch).\n- **Otherwise (default):** the available quantity is calculated per item as `ItemQtyIBIExportStock_locations` minus a deduction:\n - `ItemQtyOpenOrderLines` if reservations are disabled (`ReservePrepaymentOrders` <> `1`) or `ExportAvailableStock_WhenReservationsAreEnabled` = 1, and `StockExportUsePhysicalStock` = `0` and the item is not a bundle;\n - `ItemQtyOpenReservations` if reservations are enabled, `StockExportUsePhysicalStock` = `0` and the item is not a bundle;\n - nothing (0) in all other cases (physical stock export or bundle items).\n\nFiltering and corrections (non-legacy branch):\n\n1. If `ExcludeZeros` = 1, only items with a calculated quantity greater than 0 are kept. `NULL` is treated as 0 (all items).\n2. If `ExcludeBinGroups` is given (comma-separated list of bin groups), the stock of each item in bins of these groups is summed from `InvBinItemLog` and subtracted. For bundles whose components lie in these bins, the deduction is the minimum over the components of `CEILING(component qty / bundle component qty)`. The matching to the result row is done via the item code with `CodeTypeId` = 2 (shop item number) against `ItemNrInt`.\n3. Negative quantities are set to 0.\n\nThe rows are returned without a defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ExcludeZeros` | bit | No | If 1, only items with a calculated quantity greater than 0 are returned. NULL is treated as 0. |\n| `ExcludeBinGroups` | varchar(max) | No | Comma-separated list of bin groups (`InvBin.BinGroup`) whose stock is subtracted from the available quantity. Empty entries are ignored, spaces around entries are trimmed. |\n\n- If the setting `OldStockExport` is 1, the call returns **no rows at all**; `ExcludeZeros` and `ExcludeBinGroups` have no visible effect in that case.\n- `ExcludeZeros` is applied **before** the bin group deduction and the clamping to 0. Items can therefore still appear with `AvailableQty` = 0 when `ExcludeZeros` = 1 and `ExcludeBinGroups` is used.\n- The bin group deduction matches `pixi.ItemCode.Code` (code type 2, shop item number) against `Items.ItemNrInt`. If these numbers differ for an item, no deduction is applied to it.\n- Settings are read via `fpixi_GetSetting`; a missing setting counts as `0`.\n- All tables are read `WITH (NOLOCK)`, so the result may contain uncommitted data.\n- Without paging the call returns every item, which can be a large response for big catalogues.\n- A large block of older logic is commented out in the code and is not executed.\n\nDocumentation: https://pixi-api-docs.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": "Returns the available stock quantity of all items for the shop stock export, optionally without zero stock and without stock in excluded bin groups.\n\nReturns one row per item with the internal item number and the quantity that can be exported to the shop.\n\nThe behaviour depends on the setting `OldStockExport`:\n\n- **`OldStockExport` = 1:** the procedure collects `Quantity` from `Items` into a temporary table, but **returns no result set** (the final `SELECT` is only in the other branch).\n- **Otherwise (default):** the available quantity is calculated per item as `ItemQtyIBIExportStock_locations` minus a deduction:\n - `ItemQtyOpenOrderLines` if reservations are disabled (`ReservePrepaymentOrders` <> `1`) or `ExportAvailableStock_WhenReservationsAreEnabled` = 1, and `StockExportUsePhysicalStock` = `0` and the item is not a bundle;\n - `ItemQtyOpenReservations` if reservations are enabled, `StockExportUsePhysicalStock` = `0` and the item is not a bundle;\n - nothing (0) in all other cases (physical stock export or bundle items).\n\nFiltering and corrections (non-legacy branch):\n\n1. If `ExcludeZeros` = 1, only items with a calculated quantity greater than 0 are kept. `NULL` is treated as 0 (all items).\n2. If `ExcludeBinGroups` is given (comma-separated list of bin groups), the stock of each item in bins of these groups is summed from `InvBinItemLog` and subtracted. For bundles whose components lie in these bins, the deduction is the minimum over the components of `CEILING(component qty / bundle component qty)`. The matching to the result row is done via the item code with `CodeTypeId` = 2 (shop item number) against `ItemNrInt`.\n3. Negative quantities are set to 0.\n\nThe rows are returned without a defined sort order.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ExcludeZeros` | bit | No | If 1, only items with a calculated quantity greater than 0 are returned. NULL is treated as 0. |\n| `ExcludeBinGroups` | varchar(max) | No | Comma-separated list of bin groups (`InvBin.BinGroup`) whose stock is subtracted from the available quantity. Empty entries are ignored, spaces around entries are trimmed. |\n\n- If the setting `OldStockExport` is 1, the call returns **no rows at all**; `ExcludeZeros` and `ExcludeBinGroups` have no visible effect in that case.\n- `ExcludeZeros` is applied **before** the bin group deduction and the clamping to 0. Items can therefore still appear with `AvailableQty` = 0 when `ExcludeZeros` = 1 and `ExcludeBinGroups` is used.\n- The bin group deduction matches `pixi.ItemCode.Code` (code type 2, shop item number) against `Items.ItemNrInt`. If these numbers differ for an item, no deduction is applied to it.\n- Settings are read via `fpixi_GetSetting`; a missing setting counts as `0`.\n- All tables are read `WITH (NOLOCK)`, so the result may contain uncommitted data.\n- Without paging the call returns every item, which can be a large response for big catalogues.\n- A large block of older logic is commented out in the code and is not executed.\n\nDocumentation: https://pixi-api-docs.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": "Returns the exportable available stock quantity and minimum stock of items, paged by item key, for synchronising shop stock levels.\n\nReturns one row per item with its available quantity for a stock export to a shop. The behaviour depends on the settings `OldStockExport`, `StockExportUsePhysicalStock`, `ReservePrepaymentOrders` and `ExportAvailableStock_WhenReservationsAreEnabled`. A missing setting counts as `0`.\n\nParameter defaults: `FromItemKey` NULL becomes `0`, `RowCount` NULL becomes `1000`, `ExcludeZeros` NULL becomes `0`.\n\n**Standard mode** (`OldStockExport` is not `1`):\n\n- Only items with `ItemKey >= FromItemKey` are read. At most `RowCount` rows are returned, sorted by `ItemKey` ascending.\n- `AvailableQty` is the precomputed export stock of the item (`ItemQtyIBIExportStock_locations`) minus a deduction:\n - The open order line quantity (`ItemQtyOpenOrderLines`) if reservations are disabled, or if they are enabled and `ExportAvailableStock_WhenReservationsAreEnabled` = `1`. This applies only if `StockExportUsePhysicalStock` = `0` and the item is not a bundle.\n - The open reservation quantity (`ItemQtyOpenReservations`) if reservations are enabled and the other setting is not `1`. This also applies only if `StockExportUsePhysicalStock` = `0` and the item is not a bundle.\n - Nothing in all other cases: physical stock is used, or the item is a bundle.\n- With `ExcludeZeros` = `1`, only items with `AvailableQty > 0` are returned.\n- With `ExcludeZeros` = `0`, all items in the range are returned and negative quantities are set to `0`.\n\n**Old mode** (`OldStockExport` = `1`):\n\n- Returns `ItemNrInt`, `Quantity` as `AvailableQty` (NULL becomes 0) and `MinStockQty` for all items.\n- There is no `ItemKey` column, no paging and no sort order.\n- With `ExcludeZeros` = `1`, items with a quantity of `0` are left out.\n\n**Paging:** in standard mode, call again with `FromItemKey` = last returned `ItemKey` + 1 until fewer than `RowCount` rows come back.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromItemKey` | int | No | Smallest `ItemKey` to return (inclusive). NULL means `0`. Ignored in old mode. |\n| `RowCount` | int | No | Maximum number of rows to return. NULL means `1000`. Ignored in old mode. |\n| `ExcludeZeros` | bit | No | Controls whether items without stock are left out. NULL means `0`. |\n\n- All reads use `NOLOCK`, so results may include uncommitted data.\n- The quantities come from precomputed columns of `Items` (`ItemQtyIBIExportStock_locations`, `ItemQtyOpenOrderLines`, `ItemQtyOpenReservations`). Which stock locations or bins they include is defined elsewhere and is not visible in this procedure.\n- **Old mode differences:**\n - `FromItemKey` and `RowCount` are ignored and all items are returned in one call.\n - `ItemKey` is missing from the result.\n - With `ExcludeZeros` = `1`, negative quantities are still returned.\n - With `ExcludeZeros` = `0`, negative quantities are not set to 0.\n- In standard mode with `ExcludeZeros` = `1`, items whose computed quantity is NULL are also left out.\n- `RowCount` = `0` returns no rows. A negative value causes a SQL error from `TOP`.\n- The value of `OldStockExport` is converted to `int`. A non-numeric setting value would cause a conversion error.\n- The large commented-out legacy block in the source has no effect.\n\nDocumentation: https://pixi-api-docs.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": "Returns the exportable available stock quantity and minimum stock of items, paged by item key, for synchronising shop stock levels.\n\nReturns one row per item with its available quantity for a stock export to a shop. The behaviour depends on the settings `OldStockExport`, `StockExportUsePhysicalStock`, `ReservePrepaymentOrders` and `ExportAvailableStock_WhenReservationsAreEnabled`. A missing setting counts as `0`.\n\nParameter defaults: `FromItemKey` NULL becomes `0`, `RowCount` NULL becomes `1000`, `ExcludeZeros` NULL becomes `0`.\n\n**Standard mode** (`OldStockExport` is not `1`):\n\n- Only items with `ItemKey >= FromItemKey` are read. At most `RowCount` rows are returned, sorted by `ItemKey` ascending.\n- `AvailableQty` is the precomputed export stock of the item (`ItemQtyIBIExportStock_locations`) minus a deduction:\n - The open order line quantity (`ItemQtyOpenOrderLines`) if reservations are disabled, or if they are enabled and `ExportAvailableStock_WhenReservationsAreEnabled` = `1`. This applies only if `StockExportUsePhysicalStock` = `0` and the item is not a bundle.\n - The open reservation quantity (`ItemQtyOpenReservations`) if reservations are enabled and the other setting is not `1`. This also applies only if `StockExportUsePhysicalStock` = `0` and the item is not a bundle.\n - Nothing in all other cases: physical stock is used, or the item is a bundle.\n- With `ExcludeZeros` = `1`, only items with `AvailableQty > 0` are returned.\n- With `ExcludeZeros` = `0`, all items in the range are returned and negative quantities are set to `0`.\n\n**Old mode** (`OldStockExport` = `1`):\n\n- Returns `ItemNrInt`, `Quantity` as `AvailableQty` (NULL becomes 0) and `MinStockQty` for all items.\n- There is no `ItemKey` column, no paging and no sort order.\n- With `ExcludeZeros` = `1`, items with a quantity of `0` are left out.\n\n**Paging:** in standard mode, call again with `FromItemKey` = last returned `ItemKey` + 1 until fewer than `RowCount` rows come back.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `FromItemKey` | int | No | Smallest `ItemKey` to return (inclusive). NULL means `0`. Ignored in old mode. |\n| `RowCount` | int | No | Maximum number of rows to return. NULL means `1000`. Ignored in old mode. |\n| `ExcludeZeros` | bit | No | Controls whether items without stock are left out. NULL means `0`. |\n\n- All reads use `NOLOCK`, so results may include uncommitted data.\n- The quantities come from precomputed columns of `Items` (`ItemQtyIBIExportStock_locations`, `ItemQtyOpenOrderLines`, `ItemQtyOpenReservations`). Which stock locations or bins they include is defined elsewhere and is not visible in this procedure.\n- **Old mode differences:**\n - `FromItemKey` and `RowCount` are ignored and all items are returned in one call.\n - `ItemKey` is missing from the result.\n - With `ExcludeZeros` = `1`, negative quantities are still returned.\n - With `ExcludeZeros` = `0`, negative quantities are not set to 0.\n- In standard mode with `ExcludeZeros` = `1`, items whose computed quantity is NULL are also left out.\n- `RowCount` = `0` returns no rows. A negative value causes a SQL error from `TOP`.\n- The value of `OldStockExport` is converted to `int`. A non-numeric setting value would cause a conversion error.\n- The large commented-out legacy block in the source has no effect.\n\nDocumentation: https://pixi-api-docs.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": "Creates a supplier delivery (goods receipt) with status NEW, either from a confirmed purchase order or from item lines passed as XML.\n\nThe call creates a delivery header in `SDelHeader` (status `NEW`) and its lines in `SDelDetail`. There are two modes, selected by `OrderNr`.\n\n**Header values**\n- Without `ParameterXML` the plain parameters are used.\n- With `ParameterXML` the values of the single `/CREATE_DELIVERY/Delivery` node replace `LocID` (default `001`), `OrderNr` (default `0`), `UserName` (default `API`), the note and the external order number. `SupplNr` from the XML wins, otherwise the `SupplNr` parameter is used. `ExternalReceiptNr` can only be passed in the XML. If `LocID` does not exist, an error row is returned.\n\n**Mode 1: `OrderNr` <> 0 (template from purchase order)**\n1. The supplier is taken from the purchase order (`pixi.SupplierOrder.InternalNumber` = `OrderNr`), which must have its delivery location at `LocID`.\n2. The order must be in a deliverable status: confirmed (`IsConfirmed`) when the setting `ConfirmOrderedDocumentOnDelivery` is `0`, ordered or confirmed (`IsOrderedConfirmed`) when it is `1`.\n3. No delivery with status `NEW` may already reference the order number.\n4. The delivery is created by `Pixi_CreateSDeliveryByTemplate`. It gets one line per order line with an open quantity (ordered minus delivered minus undelivered). Delivered quantity is `0`, and price and discount come from the order line.\n\n**Mode 2: `OrderNr` = 0 (free delivery / XML lines)**\n1. The supplier (`SupplNr`) must be given and must exist.\n2. Each `ITEMS/Item` node is resolved to an Artikel through `AddItems` of this supplier, by `ItemNrInt`, `EAN` or `ItemNrSuppl`. Lines that match no Artikel are reported as failed.\n3. A line with `InternalNumber` is matched to the purchase order with that internal number. A line with only `ExternalCode` is matched to the purchase order with that external code. Only orders delivered to `LocID` count, and the Artikel is looked up on the order lines.\n4. Lines that break a matching rule (`Error01`–`Error07`) are reported as failed and are not delivered. Lines without `InternalNumber` and `ExternalCode` are delivered without a link to an order line.\n5. For each remaining line:\n - `Ordered` is the XML value if it is not 0, otherwise the order line quantity.\n - `SupplPrice` is the XML value, otherwise the order line price.\n - `Delivered` is multiplied by the Artikel's order unit if the supplier has `UsePackingUnitAtCreateDelivery` set.\n - Discount is 0.\n6. The header field `PurchaseOrderNr` holds a comma-separated list of all matched order numbers. If no order was matched, it holds the external order number with a trailing `;` removed.\n7. If lines failed, a block `Failed To Import Line Items:` listing them is appended to the delivery note. The note is limited to 8000 characters in total.\n8. Without any items, only a header is created.\n\n**Result**\n- Result set 1: the created delivery header.\n- Result set 2: its lines, with the identifiers from the request echoed back.\n- Result set 3 (only when XML items were passed in mode 2): the failed lines.\n\nValidation errors return a single row with column `ERROR` instead of these result sets.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | No | Location (Lager) of the delivery. Overridden by `LocID` in the XML. |\n| `OrderNr` | int | No | Internal number of the purchase order. `0` creates a free delivery from XML items; any other value creates the delivery from that order as a template. Overridden by `OrderNr` in the XML. |\n| `SupplNr` | varchar(4) | No | Supplier number. Required for `OrderNr` = 0 unless given in the XML. With `OrderNr` <> 0 the supplier of the purchase order is used. |\n| `SuplierOrderNRExternal` | varchar(8000) | No | External order number, used as fallback for `PurchaseOrderNr` when no purchase order is matched. A trailing `;` is removed. Effectively only used without XML. |\n| `UserName` | varchar(50) | No | User stored as creator and last editor. Overridden by `Username` in the XML. |\n| `Note` | ntext | No | Delivery note, truncated to 8000 characters. With XML it is replaced by the XML note; in template mode it is the fallback if the XML note is empty. |\n| `ParameterXML` | xml | No | Optional XML with exactly one `CREATE_DELIVERY/Delivery` header and, for `OrderNr` = 0, item lines under `ITEMS/Item`. |\n\n- **No transaction.** The header and the lines are inserted one after another without an explicit transaction in this procedure. A runtime error in the middle can leave a header with only part of its lines. The template path uses its own transaction for the lines only.\n- **Template path changes the order status.** When `ConfirmOrderedDocumentOnDelivery` = `1`, `Pixi_CreateSDeliveryByTemplate` sets the purchase order to the confirmed status. Errors in that procedure are raised as `ERROR --- …`.\n- **Open-delivery check is a substring match.** The check for an existing `NEW` delivery searches the order number as text inside `SDelHextOrderNr`. Order `123` is therefore also blocked by an open delivery for order `1234`.\n- **`ExternalReceiptNr`** is only read from the XML. Duplicates per supplier are rejected.\n- **`SuplierOrderNRExternal` is mostly overridden.** With XML it is set to `NULL` when `OrderNr` = 0. With `OrderNr` <> 0 it is not passed on at all. So it only takes effect without XML, as fallback for `PurchaseOrderNr`.\n- **Note precedence.** With XML, the note from the XML (or an empty string) replaces `Note`. In template mode an empty XML note falls back to the `Note` parameter.\n- **`LocID` is only validated on the XML path.** Without XML and with `OrderNr` = 0, a header is created even for an unknown `LocID`.\n- **Ignored XML elements.** `ItemName` and `ItemKey` in the XML items are read but ignored. Name and key always come from the Artikel master data.\n- **One request line can produce several delivery lines.** If the Artikel appears on several lines of the matched purchase order, one delivery line is created per order line, each with the full delivered quantity.\n- **Error02 on shared external codes.** Matching by `ExternalCode` also finds orders of other suppliers at the same location, and such lines are rejected with `Error02`.\n- **Dirty reads.** Most reads use `NOLOCK`.\n- **Comment numbering.** Comments in the code call the failed-lines set \"result set 4\", but it is the third result set returned.\n\nDocumentation: https://pixi-api-docs.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": "Creates a supplier delivery (goods receipt) with status NEW, either from a confirmed purchase order or from item lines passed as XML.\n\nThe call creates a delivery header in `SDelHeader` (status `NEW`) and its lines in `SDelDetail`. There are two modes, selected by `OrderNr`.\n\n**Header values**\n- Without `ParameterXML` the plain parameters are used.\n- With `ParameterXML` the values of the single `/CREATE_DELIVERY/Delivery` node replace `LocID` (default `001`), `OrderNr` (default `0`), `UserName` (default `API`), the note and the external order number. `SupplNr` from the XML wins, otherwise the `SupplNr` parameter is used. `ExternalReceiptNr` can only be passed in the XML. If `LocID` does not exist, an error row is returned.\n\n**Mode 1: `OrderNr` <> 0 (template from purchase order)**\n1. The supplier is taken from the purchase order (`pixi.SupplierOrder.InternalNumber` = `OrderNr`), which must have its delivery location at `LocID`.\n2. The order must be in a deliverable status: confirmed (`IsConfirmed`) when the setting `ConfirmOrderedDocumentOnDelivery` is `0`, ordered or confirmed (`IsOrderedConfirmed`) when it is `1`.\n3. No delivery with status `NEW` may already reference the order number.\n4. The delivery is created by `Pixi_CreateSDeliveryByTemplate`. It gets one line per order line with an open quantity (ordered minus delivered minus undelivered). Delivered quantity is `0`, and price and discount come from the order line.\n\n**Mode 2: `OrderNr` = 0 (free delivery / XML lines)**\n1. The supplier (`SupplNr`) must be given and must exist.\n2. Each `ITEMS/Item` node is resolved to an Artikel through `AddItems` of this supplier, by `ItemNrInt`, `EAN` or `ItemNrSuppl`. Lines that match no Artikel are reported as failed.\n3. A line with `InternalNumber` is matched to the purchase order with that internal number. A line with only `ExternalCode` is matched to the purchase order with that external code. Only orders delivered to `LocID` count, and the Artikel is looked up on the order lines.\n4. Lines that break a matching rule (`Error01`–`Error07`) are reported as failed and are not delivered. Lines without `InternalNumber` and `ExternalCode` are delivered without a link to an order line.\n5. For each remaining line:\n - `Ordered` is the XML value if it is not 0, otherwise the order line quantity.\n - `SupplPrice` is the XML value, otherwise the order line price.\n - `Delivered` is multiplied by the Artikel's order unit if the supplier has `UsePackingUnitAtCreateDelivery` set.\n - Discount is 0.\n6. The header field `PurchaseOrderNr` holds a comma-separated list of all matched order numbers. If no order was matched, it holds the external order number with a trailing `;` removed.\n7. If lines failed, a block `Failed To Import Line Items:` listing them is appended to the delivery note. The note is limited to 8000 characters in total.\n8. Without any items, only a header is created.\n\n**Result**\n- Result set 1: the created delivery header.\n- Result set 2: its lines, with the identifiers from the request echoed back.\n- Result set 3 (only when XML items were passed in mode 2): the failed lines.\n\nValidation errors return a single row with column `ERROR` instead of these result sets.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocID` | varchar(3) | No | Location (Lager) of the delivery. Overridden by `LocID` in the XML. |\n| `OrderNr` | int | No | Internal number of the purchase order. `0` creates a free delivery from XML items; any other value creates the delivery from that order as a template. Overridden by `OrderNr` in the XML. |\n| `SupplNr` | varchar(4) | No | Supplier number. Required for `OrderNr` = 0 unless given in the XML. With `OrderNr` <> 0 the supplier of the purchase order is used. |\n| `SuplierOrderNRExternal` | varchar(8000) | No | External order number, used as fallback for `PurchaseOrderNr` when no purchase order is matched. A trailing `;` is removed. Effectively only used without XML. |\n| `UserName` | varchar(50) | No | User stored as creator and last editor. Overridden by `Username` in the XML. |\n| `Note` | ntext | No | Delivery note, truncated to 8000 characters. With XML it is replaced by the XML note; in template mode it is the fallback if the XML note is empty. |\n| `ParameterXML` | xml | No | Optional XML with exactly one `CREATE_DELIVERY/Delivery` header and, for `OrderNr` = 0, item lines under `ITEMS/Item`. |\n\n- **No transaction.** The header and the lines are inserted one after another without an explicit transaction in this procedure. A runtime error in the middle can leave a header with only part of its lines. The template path uses its own transaction for the lines only.\n- **Template path changes the order status.** When `ConfirmOrderedDocumentOnDelivery` = `1`, `Pixi_CreateSDeliveryByTemplate` sets the purchase order to the confirmed status. Errors in that procedure are raised as `ERROR --- …`.\n- **Open-delivery check is a substring match.** The check for an existing `NEW` delivery searches the order number as text inside `SDelHextOrderNr`. Order `123` is therefore also blocked by an open delivery for order `1234`.\n- **`ExternalReceiptNr`** is only read from the XML. Duplicates per supplier are rejected.\n- **`SuplierOrderNRExternal` is mostly overridden.** With XML it is set to `NULL` when `OrderNr` = 0. With `OrderNr` <> 0 it is not passed on at all. So it only takes effect without XML, as fallback for `PurchaseOrderNr`.\n- **Note precedence.** With XML, the note from the XML (or an empty string) replaces `Note`. In template mode an empty XML note falls back to the `Note` parameter.\n- **`LocID` is only validated on the XML path.** Without XML and with `OrderNr` = 0, a header is created even for an unknown `LocID`.\n- **Ignored XML elements.** `ItemName` and `ItemKey` in the XML items are read but ignored. Name and key always come from the Artikel master data.\n- **One request line can produce several delivery lines.** If the Artikel appears on several lines of the matched purchase order, one delivery line is created per order line, each with the full delivered quantity.\n- **Error02 on shared external codes.** Matching by `ExternalCode` also finds orders of other suppliers at the same location, and such lines are rejected with `Error02`.\n- **Dirty reads.** Most reads use `NOLOCK`.\n- **Comment numbering.** Comments in the code call the failed-lines set \"result set 4\", but it is the third result set returned.\n\nDocumentation: https://pixi-api-docs.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": "Adds a new item line to an open supplier delivery, identified by delivery key or number, and returns the created delivery line.\n\nCreates one new line (`SDelDetail`) in a supplier delivery (`SDelHeader`).\n\n1. **Normalisation:** empty values are treated as not given. For the numeric parameters this means that `0` counts as empty: `SDelHKey = 0` and `SDelHNr = 0` become `NULL`. Quantities and prices that are not given become `0`.\n2. **Mandatory input:** either `SDelHKey` or `SDelHNr`, and either `EANUPC` or `ItemNrInternal`, must be set.\n3. **Item lookup:** the item is searched with `COALESCE(EANUPC, ItemNrInternal)` among the *scannable* item codes (`pixi.ItemCode` joined with `ItemCodeType`, `Scannable = 1`). If `EANUPC` is set, `ItemNrInternal` is ignored.\n4. **Delivery lookup:** if `SDelHKey` is empty, the key is taken from the first delivery with `SDelHNr`. If both are given, `SDelHKey` wins.\n5. **Checks:**\n - The delivery must exist and must not have the status `CLS` (closed) or `INV` (invoiced).\n - The delivery must not be locked by Picco (`LockedByPicco = 'Y'`).\n - `LocID` must be empty, or at least one supplier delivery with `SDelHLocationID = LocID` must exist.\n6. **Insert:** the item name is taken from `items` and the supplier from the delivery header. A new line is always inserted, with the ordered and delivered quantities, purchase price, final price, batch number and best-before date. There is no order line reference. Discounts and the mid price are set to `0`.\n7. **Price fallback:** if `SupplPrice` is `0` or not given and the delivery has a supplier, the purchase price is taken from the supplier item record (`AddItems.SupplPrice`). This value is used for the price, the mid price and the final price. In this case a given `SupplFinalPrice` is overwritten as well.\n8. **Result:** the newly created delivery line is returned with additional information:\n - quantity matched to supplier order lines\n - open customers, open orders and open quantity for the item in the delivery's location\n - supplier item number and internal item number from the supplier item record\n\nAll errors are raised with `RAISERROR` (severity 16). No line is created in that case.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | No | Internal key of the supplier delivery. Takes precedence over `SDelHNr`; `0` counts as not given. |\n| `SDelHNr` | int | No | Delivery number. Used only if `SDelHKey` is empty. Either this parameter or `SDelHKey` is required. |\n| `UserName` | varchar(50) | No | User name stored as creator and last editor of the line. |\n| `ItemNrInternal` | varchar(50) | No | Item code used for the lookup if `EANUPC` is empty. It is matched against the scannable item codes. |\n| `EANUPC` | varchar(13) | No | EAN/UPC of the item, looked up among the scannable item codes. Takes precedence over `ItemNrInternal`. |\n| `SupplPrice` | money | No | Purchase price of the line. If `0` or not given, the price is taken from the supplier item record. |\n| `SupplFinalPrice` | money | No | Final purchase price. It is overwritten by the fallback price if `SupplPrice` is `0`. |\n| `SDelHSupplNr` | varchar(4) | No | Not used (DEV-4203). The supplier is taken from the delivery header. |\n| `OrderdQty` | money | No | Ordered quantity of the line. |\n| `DeliverdQty` | money | No | Delivered quantity of the line. |\n| `LocID` | varchar(255) | No | Optional location ID. If set, at least one supplier delivery with this location ID must exist, otherwise an error is raised. |\n| `PiccoUser` | varchar(59) | No | Not used by the code. |\n| `BatchNumber` | varchar(50) | No | Batch number stored on the delivery line. |\n| `BestBeforeDate` | datetime | No | Best-before date stored on the delivery line. |\n\n- `SDelHSupplNr` and `PiccoUser` are accepted but not used; `SDelHSupplNr` is marked as unused in the code (DEV-4203). The supplier always comes from the delivery header.\n- **Location check:** the `LocID` check does not compare against the location of the target delivery. It only checks whether *any* supplier delivery with this location ID exists.\n- **Duplicate lines:** calling the procedure again for the same item creates an additional line. Existing lines are never updated; the error text points to `pixiUpdateDeliveryItem` for updates.\n- **Supplier item creation:** if the setting `InsertAddItemOnSOrdersDragDrop` is `1` and no supplier item record (`AddItems`) exists for the delivery's supplier and the item, the internal procedure `Pixi_InsertAddItemOnDelivery` is called. That procedure is not attached, so its exact effects are not documented here; it presumably creates such a record.\n- **Price may be NULL:** with the price fallback, the price becomes `NULL` if the supplier has no supplier item record for the item.\n- **Duplicated error text:** if only the delivery reference is missing, the validation logic concatenates the message twice, so the error text appears twice.\n- **User name:** if `UserName` is sent as an empty string, it becomes `NULL` and is stored as `NULL` creator/updater.\n- Reads use `NOLOCK`. No explicit transaction is used.\n\nDocumentation: https://pixi-api-docs.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": "Adds a new item line to an open supplier delivery, identified by delivery key or number, and returns the created delivery line.\n\nCreates one new line (`SDelDetail`) in a supplier delivery (`SDelHeader`).\n\n1. **Normalisation:** empty values are treated as not given. For the numeric parameters this means that `0` counts as empty: `SDelHKey = 0` and `SDelHNr = 0` become `NULL`. Quantities and prices that are not given become `0`.\n2. **Mandatory input:** either `SDelHKey` or `SDelHNr`, and either `EANUPC` or `ItemNrInternal`, must be set.\n3. **Item lookup:** the item is searched with `COALESCE(EANUPC, ItemNrInternal)` among the *scannable* item codes (`pixi.ItemCode` joined with `ItemCodeType`, `Scannable = 1`). If `EANUPC` is set, `ItemNrInternal` is ignored.\n4. **Delivery lookup:** if `SDelHKey` is empty, the key is taken from the first delivery with `SDelHNr`. If both are given, `SDelHKey` wins.\n5. **Checks:**\n - The delivery must exist and must not have the status `CLS` (closed) or `INV` (invoiced).\n - The delivery must not be locked by Picco (`LockedByPicco = 'Y'`).\n - `LocID` must be empty, or at least one supplier delivery with `SDelHLocationID = LocID` must exist.\n6. **Insert:** the item name is taken from `items` and the supplier from the delivery header. A new line is always inserted, with the ordered and delivered quantities, purchase price, final price, batch number and best-before date. There is no order line reference. Discounts and the mid price are set to `0`.\n7. **Price fallback:** if `SupplPrice` is `0` or not given and the delivery has a supplier, the purchase price is taken from the supplier item record (`AddItems.SupplPrice`). This value is used for the price, the mid price and the final price. In this case a given `SupplFinalPrice` is overwritten as well.\n8. **Result:** the newly created delivery line is returned with additional information:\n - quantity matched to supplier order lines\n - open customers, open orders and open quantity for the item in the delivery's location\n - supplier item number and internal item number from the supplier item record\n\nAll errors are raised with `RAISERROR` (severity 16). No line is created in that case.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | No | Internal key of the supplier delivery. Takes precedence over `SDelHNr`; `0` counts as not given. |\n| `SDelHNr` | int | No | Delivery number. Used only if `SDelHKey` is empty. Either this parameter or `SDelHKey` is required. |\n| `UserName` | varchar(50) | No | User name stored as creator and last editor of the line. |\n| `ItemNrInternal` | varchar(50) | No | Item code used for the lookup if `EANUPC` is empty. It is matched against the scannable item codes. |\n| `EANUPC` | varchar(13) | No | EAN/UPC of the item, looked up among the scannable item codes. Takes precedence over `ItemNrInternal`. |\n| `SupplPrice` | money | No | Purchase price of the line. If `0` or not given, the price is taken from the supplier item record. |\n| `SupplFinalPrice` | money | No | Final purchase price. It is overwritten by the fallback price if `SupplPrice` is `0`. |\n| `SDelHSupplNr` | varchar(4) | No | Not used (DEV-4203). The supplier is taken from the delivery header. |\n| `OrderdQty` | money | No | Ordered quantity of the line. |\n| `DeliverdQty` | money | No | Delivered quantity of the line. |\n| `LocID` | varchar(255) | No | Optional location ID. If set, at least one supplier delivery with this location ID must exist, otherwise an error is raised. |\n| `PiccoUser` | varchar(59) | No | Not used by the code. |\n| `BatchNumber` | varchar(50) | No | Batch number stored on the delivery line. |\n| `BestBeforeDate` | datetime | No | Best-before date stored on the delivery line. |\n\n- `SDelHSupplNr` and `PiccoUser` are accepted but not used; `SDelHSupplNr` is marked as unused in the code (DEV-4203). The supplier always comes from the delivery header.\n- **Location check:** the `LocID` check does not compare against the location of the target delivery. It only checks whether *any* supplier delivery with this location ID exists.\n- **Duplicate lines:** calling the procedure again for the same item creates an additional line. Existing lines are never updated; the error text points to `pixiUpdateDeliveryItem` for updates.\n- **Supplier item creation:** if the setting `InsertAddItemOnSOrdersDragDrop` is `1` and no supplier item record (`AddItems`) exists for the delivery's supplier and the item, the internal procedure `Pixi_InsertAddItemOnDelivery` is called. That procedure is not attached, so its exact effects are not documented here; it presumably creates such a record.\n- **Price may be NULL:** with the price fallback, the price becomes `NULL` if the supplier has no supplier item record for the item.\n- **Duplicated error text:** if only the delivery reference is missing, the validation logic concatenates the message twice, so the error text appears twice.\n- **User name:** if `UserName` is sent as an empty string, it becomes `NULL` and is stored as `NULL` creator/updater.\n- Reads use `NOLOCK`. No explicit transaction is used.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new supplier delivery (status NEW) from one or more confirmed supplier orders and then runs a delivery header list query.\n\nLegacy wrapper that creates a supplier delivery document (`SDelHeader` / `SDelDetail`) using supplier orders as a template, then calls a paged list of delivery headers.\n\n**Step 1 – create the delivery** (via `Pixi_CreateSDeliveryByTemplate`):\n\n1. `OrderNr` is split at `;`. Each element is matched against the internal number (`InternalNumber`) of a supplier order.\n2. Only supplier orders in a suitable status are used. This depends on the setting `ConfirmOrderedDocumentOnDelivery`:\n - `0`: orders whose status is flagged as confirmed (`IsConfirmed = 1`).\n - `1`: orders whose status is flagged as ordered-confirmed (`IsOrderedConfirmed = 1`). These orders are then switched to the first confirmed status. Confirmation date, confirming user, modification date and modifying user are also set.\n3. If no order qualifies, nothing is created.\n4. Otherwise one delivery header is inserted with these values:\n - status `NEW` and location `LocID`\n - the supplier number of one of the found orders\n - the full `OrderNr` string as external order number\n - `UserName` as creating and updating employee, and the current date\n5. For every supplier order line with an open quantity > 0, one delivery line is created. Open quantity is `Qty - DeliveredQty - UndeliveredQty`.\n - Delivered quantity is `0` and the ordered quantity is the open quantity.\n - Supplier price and discount are taken from the order line. A percentage discount is used directly; an amount discount is converted to a percentage per unit.\n - Final price and mid price are the price minus the discount amount.\n\n**Step 2 – list query** (via `Pixi_GetSDelHeaderByPage`): the code queries delivery headers of location `LocID` with status `NEW` or `INV` (the `ShowInv = NULL` argument becomes `1`). The call passes page number `0`, so the row window is `RowNum BETWEEN -PerPage+1 AND 0`. As a result the returned result set never contains rows.\n\nThe ID of the new delivery is not returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | varchar(1000) | Yes | Internal numbers of the supplier orders to use as template, separated by `;`. The full string is also stored as external order number of the delivery. |\n| `LocID` | varchar(3) | Yes | Location (warehouse) ID for the new delivery. The list query is also filtered by this location. |\n| `UserName` | varchar(50) | Yes | User name stored as creating/updating employee. It is also used to confirm the orders when the setting is `1`. NULL becomes `TemplateFromBuying`. |\n\n- A code comment states that this API call is **no longer maintained**.\n- The returned result set is always empty because page `0` is requested. Do not rely on it to find the new delivery. Query the delivery headers separately, for example by location, status `NEW` and external order number.\n- Only the detail insert runs inside a transaction. These steps run before it and are **not** rolled back if the detail insert fails:\n - the status update of the supplier orders (setting `1`)\n - the header insert\n \n A failure can therefore leave a delivery header without lines.\n- If the setting `ConfirmOrderedDocumentOnDelivery` has a value other than `0` or `1`, no order qualifies and nothing is created.\n- If the orders belong to different suppliers, the header gets the supplier number of one arbitrary order (`TOP (1)` without `ORDER BY`). The lines of all orders are still added.\n- If `UserName` is NULL, the inner procedure uses `TemplateFromBuying`.\n- `CONTEXT_INFO` is set to `0x10005` during the line insert to bypass the `SDelDetail_IUD` trigger.\n- Order data is read with `NOLOCK`.\n- The page size of the list query comes from the setting `BuyingShowPerTab` (fallback 500).\n- `OrderNr` is limited to 1000 characters in this wrapper.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new supplier delivery (status NEW) from one or more confirmed supplier orders and then runs a delivery header list query.\n\nLegacy wrapper that creates a supplier delivery document (`SDelHeader` / `SDelDetail`) using supplier orders as a template, then calls a paged list of delivery headers.\n\n**Step 1 – create the delivery** (via `Pixi_CreateSDeliveryByTemplate`):\n\n1. `OrderNr` is split at `;`. Each element is matched against the internal number (`InternalNumber`) of a supplier order.\n2. Only supplier orders in a suitable status are used. This depends on the setting `ConfirmOrderedDocumentOnDelivery`:\n - `0`: orders whose status is flagged as confirmed (`IsConfirmed = 1`).\n - `1`: orders whose status is flagged as ordered-confirmed (`IsOrderedConfirmed = 1`). These orders are then switched to the first confirmed status. Confirmation date, confirming user, modification date and modifying user are also set.\n3. If no order qualifies, nothing is created.\n4. Otherwise one delivery header is inserted with these values:\n - status `NEW` and location `LocID`\n - the supplier number of one of the found orders\n - the full `OrderNr` string as external order number\n - `UserName` as creating and updating employee, and the current date\n5. For every supplier order line with an open quantity > 0, one delivery line is created. Open quantity is `Qty - DeliveredQty - UndeliveredQty`.\n - Delivered quantity is `0` and the ordered quantity is the open quantity.\n - Supplier price and discount are taken from the order line. A percentage discount is used directly; an amount discount is converted to a percentage per unit.\n - Final price and mid price are the price minus the discount amount.\n\n**Step 2 – list query** (via `Pixi_GetSDelHeaderByPage`): the code queries delivery headers of location `LocID` with status `NEW` or `INV` (the `ShowInv = NULL` argument becomes `1`). The call passes page number `0`, so the row window is `RowNum BETWEEN -PerPage+1 AND 0`. As a result the returned result set never contains rows.\n\nThe ID of the new delivery is not returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | varchar(1000) | Yes | Internal numbers of the supplier orders to use as template, separated by `;`. The full string is also stored as external order number of the delivery. |\n| `LocID` | varchar(3) | Yes | Location (warehouse) ID for the new delivery. The list query is also filtered by this location. |\n| `UserName` | varchar(50) | Yes | User name stored as creating/updating employee. It is also used to confirm the orders when the setting is `1`. NULL becomes `TemplateFromBuying`. |\n\n- A code comment states that this API call is **no longer maintained**.\n- The returned result set is always empty because page `0` is requested. Do not rely on it to find the new delivery. Query the delivery headers separately, for example by location, status `NEW` and external order number.\n- Only the detail insert runs inside a transaction. These steps run before it and are **not** rolled back if the detail insert fails:\n - the status update of the supplier orders (setting `1`)\n - the header insert\n \n A failure can therefore leave a delivery header without lines.\n- If the setting `ConfirmOrderedDocumentOnDelivery` has a value other than `0` or `1`, no order qualifies and nothing is created.\n- If the orders belong to different suppliers, the header gets the supplier number of one arbitrary order (`TOP (1)` without `ORDER BY`). The lines of all orders are still added.\n- If `UserName` is NULL, the inner procedure uses `TemplateFromBuying`.\n- `CONTEXT_INFO` is set to `0x10005` during the line insert to bypass the `SDelDetail_IUD` trigger.\n- Order data is read with `NOLOCK`.\n- The page size of the list query comes from the setting `BuyingShowPerTab` (fallback 500).\n- `OrderNr` is limited to 1000 characters in this wrapper.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new supplier delivery (status NEW) at a location from one or more confirmed supplier orders and returns its header.\n\nCreates a supplier delivery document (`SDelHeader` with `SDelDetail` lines) using one or more supplier orders as a template.\n\n1. `OrderNr` is split at `;` into supplier order numbers (the `InternalNumber` of the supplier order, e.g. a BES number). Leading and trailing spaces are trimmed.\n2. If a delivery with status `NEW` already exists at location `LocID` whose `SDelHextOrderNr` contains any of the given numbers, the call stops and returns a single row with the column `ERROR`.\n3. Otherwise the internal procedure `Pixi_CreateSDeliveryByTemplate` is executed:\n - Only supplier orders whose status counts as confirmed are used. Which status flag is checked depends on the setting `ConfirmOrderedDocumentOnDelivery`: `0` requires `IsConfirmed = 1`, `1` requires `IsOrderedConfirmed = 1`.\n - If no supplier order qualifies, nothing is created.\n - With setting `1`, the qualifying supplier orders that are not yet confirmed are set to the confirmed status (confirmation date and user are set).\n - One delivery header is inserted with status `NEW`, the given location, the supplier of one of the orders, `SDelHextOrderNr` = the full `OrderNr` string, and `UserName` as creating/updating user (default `TemplateFromBuying` if NULL).\n - For every supplier order line with an open quantity (`Qty - DeliveredQty - UndeliveredQty > 0`) a delivery line is inserted with delivered quantity 0, the open quantity as ordered quantity, the supplier price and the discount converted to percent and final price.\n4. Finally the header of the created delivery is returned (`SDelHKey`, date, location, number, status, external order number, supplier).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | varchar(1000) | Yes | One or more supplier order numbers (`InternalNumber`), separated by `;`. |\n| `LocID` | varchar(3) | Yes | Location (warehouse) ID for which the delivery is created; also used for the open-delivery check. |\n| `UserName` | varchar(50) | Yes | User stored as creator/editor of the delivery; if NULL, `TemplateFromBuying` is used. |\n\n- The code comment states that this API call is **no longer maintained**.\n- The duplicate check uses a substring match (`CHARINDEX`) on `SDelHextOrderNr`: a number such as `BES100` is also found inside `BES1000`, so the check can report false positives.\n- If no supplier order qualifies (unknown number, wrong status, or the setting `ConfirmOrderedDocumentOnDelivery` has a value other than `0`/`1`), no delivery is created and the header result set is empty; no error is returned.\n- If the orders belong to different suppliers, the header gets the supplier of an arbitrary one of them (`TOP (1)` without order), while lines from all orders are added.\n- The header insert and the optional status update of the supplier orders run **outside** the transaction; only the line insert is transactional. If the line insert fails, the header remains without lines and the error is raised as `ERROR --- `.\n- `CONTEXT_INFO` is set during the line insert to suppress the trigger on `SDelDetail`.\n- Reads use `NOLOCK`. The user ID for confirmation is resolved via `inf.UserGetByName`, which is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new supplier delivery (status NEW) at a location from one or more confirmed supplier orders and returns its header.\n\nCreates a supplier delivery document (`SDelHeader` with `SDelDetail` lines) using one or more supplier orders as a template.\n\n1. `OrderNr` is split at `;` into supplier order numbers (the `InternalNumber` of the supplier order, e.g. a BES number). Leading and trailing spaces are trimmed.\n2. If a delivery with status `NEW` already exists at location `LocID` whose `SDelHextOrderNr` contains any of the given numbers, the call stops and returns a single row with the column `ERROR`.\n3. Otherwise the internal procedure `Pixi_CreateSDeliveryByTemplate` is executed:\n - Only supplier orders whose status counts as confirmed are used. Which status flag is checked depends on the setting `ConfirmOrderedDocumentOnDelivery`: `0` requires `IsConfirmed = 1`, `1` requires `IsOrderedConfirmed = 1`.\n - If no supplier order qualifies, nothing is created.\n - With setting `1`, the qualifying supplier orders that are not yet confirmed are set to the confirmed status (confirmation date and user are set).\n - One delivery header is inserted with status `NEW`, the given location, the supplier of one of the orders, `SDelHextOrderNr` = the full `OrderNr` string, and `UserName` as creating/updating user (default `TemplateFromBuying` if NULL).\n - For every supplier order line with an open quantity (`Qty - DeliveredQty - UndeliveredQty > 0`) a delivery line is inserted with delivered quantity 0, the open quantity as ordered quantity, the supplier price and the discount converted to percent and final price.\n4. Finally the header of the created delivery is returned (`SDelHKey`, date, location, number, status, external order number, supplier).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OrderNr` | varchar(1000) | Yes | One or more supplier order numbers (`InternalNumber`), separated by `;`. |\n| `LocID` | varchar(3) | Yes | Location (warehouse) ID for which the delivery is created; also used for the open-delivery check. |\n| `UserName` | varchar(50) | Yes | User stored as creator/editor of the delivery; if NULL, `TemplateFromBuying` is used. |\n\n- The code comment states that this API call is **no longer maintained**.\n- The duplicate check uses a substring match (`CHARINDEX`) on `SDelHextOrderNr`: a number such as `BES100` is also found inside `BES1000`, so the check can report false positives.\n- If no supplier order qualifies (unknown number, wrong status, or the setting `ConfirmOrderedDocumentOnDelivery` has a value other than `0`/`1`), no delivery is created and the header result set is empty; no error is returned.\n- If the orders belong to different suppliers, the header gets the supplier of an arbitrary one of them (`TOP (1)` without order), while lines from all orders are added.\n- The header insert and the optional status update of the supplier orders run **outside** the transaction; only the line insert is transactional. If the line insert fails, the header remains without lines and the error is raised as `ERROR --- `.\n- `CONTEXT_INFO` is set during the line insert to suppress the trigger on `SDelDetail`.\n- Reads use `NOLOCK`. The user ID for confirmation is resolved via `inf.UserGetByName`, which is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new supplier together with its main contact and returns a status row with ReturnCode and Message.\n\nCreates one new supplier record in `Suppliers` and one main contact record in `pixi.Contact`, linked via `ContactId`.\n\nSteps:\n\n1. Every string parameter passed as an empty string is treated as `NULL`. `SupplCtry` is trimmed first.\n2. If `CurrencyId` is not passed, the database currency is used. This is the currency from the `HomeCurrency` setting, read via `pixi.GetDatabaseCurrency`.\n3. `CanDoDirectFulfillment` is converted to a bit: `Y` becomes 1. `N` and any other value become 0.\n4. Validation runs in this order and stops at the first error:\n - `SupplNr` must be given.\n - `SupplName` must be given.\n - `CanDoDirectFulfillment` must not be `NULL`.\n - No supplier with the same `SupplNr` may already exist.\n5. If all checks pass, a contact row is inserted. Contact fields that are not passed are stored as empty strings. The supplier is then inserted with:\n - `ContactId` set to the new contact's identity\n - `CreateDate` set to the current time\n - `CreateEmp` set to `API`\n - `MailBox` set to `eMail`\n - `SupplComment` set to `SupplierComment`\n\nThe call always returns exactly one status row. `ReturnCode` is `OK` on success and `Error` on a validation error or an unexpected SQL error.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | No | Supplier number (key). Functionally mandatory; must not exist yet. |\n| `SupplName` | varchar(60) | No | Supplier name. Functionally mandatory. |\n| `SupplNameExt` | varchar(50) | No | Name extension. |\n| `SupplGroup` | varchar(4) | No | Supplier group code (not validated). |\n| `DefaultDeliveryDays` | int | No | Default delivery time in days. The value 0 is stored as NULL. |\n| `SupplFaxNR` | varchar(100) | No | Supplier fax number. |\n| `CustNR` | varchar(20) | No | Own customer number at the supplier. |\n| `eMail` | varchar(60) | No | General e-mail address; stored in column `MailBox`. |\n| `SupAnrede` | varchar(20) | No | Salutation of the supplier address. |\n| `SupName2` | varchar(60) | No | Second name line of the address. |\n| `SupAddress` | varchar(50) | No | Street and house number. |\n| `SupZip` | varchar(20) | No | Postal code. |\n| `SupPhone1` | varchar(50) | No | First phone number. |\n| `CanDoDirectFulfillment` | varchar(1) | No | Whether the supplier can do direct fulfillment (drop shipping). Functionally mandatory (must not be NULL). |\n| `SupCity` | varchar(50) | No | City. |\n| `SupPhone2` | varchar(50) | No | Second phone number. |\n| `SupplCtry` | varchar(3) | No | Country code; trimmed, not validated. |\n| `CurrencyId` | smallint | No | Currency ID of the supplier. If not passed, the database currency (setting `HomeCurrency`) is used. |\n| `eMailSupplOrder` | varchar(255) | No | E-mail address for supplier orders. |\n| `HomePageUrl` | nvarchar(2000) | No | Website of the supplier. |\n| `MainContact_Title` | nvarchar(100) | No | Title of the main contact. |\n| `MainContact_FirstName` | nvarchar(20) | No | First name of the main contact. |\n| `MainContact_LastName` | nvarchar(200) | No | Last name of the main contact. |\n| `MainContact_JobTitle` | nvarchar(200) | No | Job title of the main contact. |\n| `MainContact_JobFunction` | nvarchar(200) | No | Job function of the main contact. |\n| `MainContact_Phone` | varchar(200) | No | Phone number of the main contact. |\n| `MainContact_MobilePhone` | varchar(200) | No | Mobile phone number of the main contact. |\n| `MainContact_Fax` | nvarchar(200) | No | Fax number of the main contact. |\n| `MainContact_Email` | nvarchar(200) | No | E-mail address of the main contact. |\n| `SupplierComment` | varchar(8000) | No | Comment on the supplier; stored in `SupplComment`. |\n\n- Everything runs in the named transaction `CreateSupplier`. On an SQL error the transaction is rolled back and `ErrorMessage` contains the SQL error text. Validation errors are not SQL errors: the transaction is committed, but nothing has been written.\n- The duplicate check on `SupplNr` uses `NOLOCK`. Two parallel calls with the same number can therefore both pass the check. In that case a unique constraint on the table, if one exists, would produce the generic error.\n- `RowsAffected` is never updated and is always `0`.\n- `DefaultDeliveryDays` is compared to an empty string. As an `int`, the value `0` is therefore stored as `NULL`.\n- An empty string for `CanDoDirectFulfillment` passes the mandatory check and is stored as 0.\n- `SupplGroup`, `SupplCtry` and `CurrencyId` are not validated against master data.\n- If no database currency can be determined, `CurrencyId` stays `NULL`.\n- A contact row is always created, even if no `MainContact_*` parameter is passed.\n- Values longer than the declared parameter length (e.g. `SupplNr` with more than 4 characters) may be truncated silently.\n\nDocumentation: https://pixi-api-docs.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": "Creates a new supplier together with its main contact and returns a status row with ReturnCode and Message.\n\nCreates one new supplier record in `Suppliers` and one main contact record in `pixi.Contact`, linked via `ContactId`.\n\nSteps:\n\n1. Every string parameter passed as an empty string is treated as `NULL`. `SupplCtry` is trimmed first.\n2. If `CurrencyId` is not passed, the database currency is used. This is the currency from the `HomeCurrency` setting, read via `pixi.GetDatabaseCurrency`.\n3. `CanDoDirectFulfillment` is converted to a bit: `Y` becomes 1. `N` and any other value become 0.\n4. Validation runs in this order and stops at the first error:\n - `SupplNr` must be given.\n - `SupplName` must be given.\n - `CanDoDirectFulfillment` must not be `NULL`.\n - No supplier with the same `SupplNr` may already exist.\n5. If all checks pass, a contact row is inserted. Contact fields that are not passed are stored as empty strings. The supplier is then inserted with:\n - `ContactId` set to the new contact's identity\n - `CreateDate` set to the current time\n - `CreateEmp` set to `API`\n - `MailBox` set to `eMail`\n - `SupplComment` set to `SupplierComment`\n\nThe call always returns exactly one status row. `ReturnCode` is `OK` on success and `Error` on a validation error or an unexpected SQL error.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | No | Supplier number (key). Functionally mandatory; must not exist yet. |\n| `SupplName` | varchar(60) | No | Supplier name. Functionally mandatory. |\n| `SupplNameExt` | varchar(50) | No | Name extension. |\n| `SupplGroup` | varchar(4) | No | Supplier group code (not validated). |\n| `DefaultDeliveryDays` | int | No | Default delivery time in days. The value 0 is stored as NULL. |\n| `SupplFaxNR` | varchar(100) | No | Supplier fax number. |\n| `CustNR` | varchar(20) | No | Own customer number at the supplier. |\n| `eMail` | varchar(60) | No | General e-mail address; stored in column `MailBox`. |\n| `SupAnrede` | varchar(20) | No | Salutation of the supplier address. |\n| `SupName2` | varchar(60) | No | Second name line of the address. |\n| `SupAddress` | varchar(50) | No | Street and house number. |\n| `SupZip` | varchar(20) | No | Postal code. |\n| `SupPhone1` | varchar(50) | No | First phone number. |\n| `CanDoDirectFulfillment` | varchar(1) | No | Whether the supplier can do direct fulfillment (drop shipping). Functionally mandatory (must not be NULL). |\n| `SupCity` | varchar(50) | No | City. |\n| `SupPhone2` | varchar(50) | No | Second phone number. |\n| `SupplCtry` | varchar(3) | No | Country code; trimmed, not validated. |\n| `CurrencyId` | smallint | No | Currency ID of the supplier. If not passed, the database currency (setting `HomeCurrency`) is used. |\n| `eMailSupplOrder` | varchar(255) | No | E-mail address for supplier orders. |\n| `HomePageUrl` | nvarchar(2000) | No | Website of the supplier. |\n| `MainContact_Title` | nvarchar(100) | No | Title of the main contact. |\n| `MainContact_FirstName` | nvarchar(20) | No | First name of the main contact. |\n| `MainContact_LastName` | nvarchar(200) | No | Last name of the main contact. |\n| `MainContact_JobTitle` | nvarchar(200) | No | Job title of the main contact. |\n| `MainContact_JobFunction` | nvarchar(200) | No | Job function of the main contact. |\n| `MainContact_Phone` | varchar(200) | No | Phone number of the main contact. |\n| `MainContact_MobilePhone` | varchar(200) | No | Mobile phone number of the main contact. |\n| `MainContact_Fax` | nvarchar(200) | No | Fax number of the main contact. |\n| `MainContact_Email` | nvarchar(200) | No | E-mail address of the main contact. |\n| `SupplierComment` | varchar(8000) | No | Comment on the supplier; stored in `SupplComment`. |\n\n- Everything runs in the named transaction `CreateSupplier`. On an SQL error the transaction is rolled back and `ErrorMessage` contains the SQL error text. Validation errors are not SQL errors: the transaction is committed, but nothing has been written.\n- The duplicate check on `SupplNr` uses `NOLOCK`. Two parallel calls with the same number can therefore both pass the check. In that case a unique constraint on the table, if one exists, would produce the generic error.\n- `RowsAffected` is never updated and is always `0`.\n- `DefaultDeliveryDays` is compared to an empty string. As an `int`, the value `0` is therefore stored as `NULL`.\n- An empty string for `CanDoDirectFulfillment` passes the mandatory check and is stored as 0.\n- `SupplGroup`, `SupplCtry` and `CurrencyId` are not validated against master data.\n- If no database currency can be determined, `CurrencyId` stays `NULL`.\n- A contact row is always created, even if no `MainContact_*` parameter is passed.\n- Values longer than the declared parameter length (e.g. `SupplNr` with more than 4 characters) may be truncated silently.\n\nDocumentation: https://pixi-api-docs.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": "Creates supplier (purchase) orders from a stored supplier order suggestion profile and returns the numbers of the created orders.\n\nRuns the supplier order suggestion (Bestellvorschlag) for a saved profile and confirms the result in one step, which creates or extends supplier orders.\n\nSteps:\n1. Checks that `ProfileId` is given and that a Pixi user named `API` exists. This user is passed on as the acting user.\n2. Reads the profile XML from `pixi.SupplierOrderSuggestionProfile.Data` for the given `Id`. If there is no profile or no data, an error row is returned.\n3. Maps the profile settings below `/SuggestionProfileDbo` to the suggestion parameters:\n - `OrderMethod`: `OrderOnDemand` = 1, `OrderForTargetStock` = 2, `OrderOnStockTurnover` = 3.\n - `SupplierPriority`: `LowestPrice` = 1 (default), `FastestDelivery` = 2, `LatestDelivery` = 3.\n - `CalculationSuggestionLocation`: `CalculateSuggestionForEachLocationSeparately` = 0 (default), `CalculateSuggestionsBasedOnSummarizedParametersForSelectedLocations` = 1.\n - `ConsiderationOfSuppliers`: `FromSelectedSuppliers` = 0 (default), `IfSelectedSupplierIsOptimal` = 1.\n - `SupplierOrdersCreation`: `CreateOnlyNewSupplierOrders` = 0 (default), `AddSuggestedItemsToOpenSupplierOrders` = 1.\n - `SelectedLocations/int`, `SelectedSuppliers/int` and the tag ids in `TagKeysOr`, `TagKeysAnd`, `TagKeysNot` are joined to comma-separated lists.\n - `ConsiderPackagingUnit`, `ConsiderMinimumOrderAmount`, `DeliveryLocationId`, `OrderLocationId`, `ExcludeSuppliersWithZeroPrice` and `IncludeOversoldItems` are taken over directly.\n - Only for `OrderOnStockTurnover`: `TurnoverInDays`, `ConsiderReorderLevel` and the sales period. With `StockTurnoverSalesOption` = `SalesPerDayForLastXDays` the period is the last `SalesForLastXDays` days up to now; otherwise `SalesFrom`/`SalesTo` are used.\n4. Generates a suggestion run number from the current time (`yyMMddHHmmss`) and calls `pixi.SupplierOrderSuggestionPrepareData` and then `pixi.SupplierOrderSuggestionConfirmData`. Validation is skipped in the confirm step.\n5. Returns one row per supplier order linked to this run, with the order's internal number and the supplier number. If no order was linked, an `INFO` row is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ProfileId` | smallint | No | Id of the supplier order suggestion profile in `pixi.SupplierOrderSuggestionProfile`. Functionally mandatory; without it an error row is returned. |\n\n- The actual creation of supplier orders happens in `pixi.SupplierOrderSuggestionPrepareData` and `pixi.SupplierOrderSuggestionConfirmData`. Their definitions are not attached, so the tables they write and their exact rules are not documented here. Both are called with `@ShowOutputSet = 0`, which presumably suppresses their own result sets.\n- All work runs in a transaction. If the caller already has an open transaction, a savepoint is used instead. On an exception the work is rolled back and an `ERROR` row is returned instead of a SQL error.\n- The user `API` must exist in `UCS_USERS`. There is no fallback to another user.\n- The run number is derived from the current time to the second. Two calls started in the same second may get the same number and mix up their results.\n- Values in the profile that do not match the listed texts leave the defaults in place. An unknown `OrderMethod` leaves the order method `NULL`.\n- Without any tags in a tag list, `NULL` (not an empty string) is passed for that list.\n- Profile and result reads use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Creates supplier (purchase) orders from a stored supplier order suggestion profile and returns the numbers of the created orders.\n\nRuns the supplier order suggestion (Bestellvorschlag) for a saved profile and confirms the result in one step, which creates or extends supplier orders.\n\nSteps:\n1. Checks that `ProfileId` is given and that a Pixi user named `API` exists. This user is passed on as the acting user.\n2. Reads the profile XML from `pixi.SupplierOrderSuggestionProfile.Data` for the given `Id`. If there is no profile or no data, an error row is returned.\n3. Maps the profile settings below `/SuggestionProfileDbo` to the suggestion parameters:\n - `OrderMethod`: `OrderOnDemand` = 1, `OrderForTargetStock` = 2, `OrderOnStockTurnover` = 3.\n - `SupplierPriority`: `LowestPrice` = 1 (default), `FastestDelivery` = 2, `LatestDelivery` = 3.\n - `CalculationSuggestionLocation`: `CalculateSuggestionForEachLocationSeparately` = 0 (default), `CalculateSuggestionsBasedOnSummarizedParametersForSelectedLocations` = 1.\n - `ConsiderationOfSuppliers`: `FromSelectedSuppliers` = 0 (default), `IfSelectedSupplierIsOptimal` = 1.\n - `SupplierOrdersCreation`: `CreateOnlyNewSupplierOrders` = 0 (default), `AddSuggestedItemsToOpenSupplierOrders` = 1.\n - `SelectedLocations/int`, `SelectedSuppliers/int` and the tag ids in `TagKeysOr`, `TagKeysAnd`, `TagKeysNot` are joined to comma-separated lists.\n - `ConsiderPackagingUnit`, `ConsiderMinimumOrderAmount`, `DeliveryLocationId`, `OrderLocationId`, `ExcludeSuppliersWithZeroPrice` and `IncludeOversoldItems` are taken over directly.\n - Only for `OrderOnStockTurnover`: `TurnoverInDays`, `ConsiderReorderLevel` and the sales period. With `StockTurnoverSalesOption` = `SalesPerDayForLastXDays` the period is the last `SalesForLastXDays` days up to now; otherwise `SalesFrom`/`SalesTo` are used.\n4. Generates a suggestion run number from the current time (`yyMMddHHmmss`) and calls `pixi.SupplierOrderSuggestionPrepareData` and then `pixi.SupplierOrderSuggestionConfirmData`. Validation is skipped in the confirm step.\n5. Returns one row per supplier order linked to this run, with the order's internal number and the supplier number. If no order was linked, an `INFO` row is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ProfileId` | smallint | No | Id of the supplier order suggestion profile in `pixi.SupplierOrderSuggestionProfile`. Functionally mandatory; without it an error row is returned. |\n\n- The actual creation of supplier orders happens in `pixi.SupplierOrderSuggestionPrepareData` and `pixi.SupplierOrderSuggestionConfirmData`. Their definitions are not attached, so the tables they write and their exact rules are not documented here. Both are called with `@ShowOutputSet = 0`, which presumably suppresses their own result sets.\n- All work runs in a transaction. If the caller already has an open transaction, a savepoint is used instead. On an exception the work is rolled back and an `ERROR` row is returned instead of a SQL error.\n- The user `API` must exist in `UCS_USERS`. There is no fallback to another user.\n- The run number is derived from the current time to the second. Two calls started in the same second may get the same number and mix up their results.\n- Values in the profile that do not match the listed texts leave the defaults in place. An unknown `OrderMethod` leaves the order method `NULL`.\n- Without any tags in a tag list, `NULL` (not an empty string) is passed for that list.\n- Profile and result reads use `NOLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Deletes a supplier delivery (delivery header and lines) with status NEW, identified by delivery reference or delivery number.\n\nDeletes a supplier delivery from `SDelHeader` together with its lines in `SDelDetail`.\n\n1. At least one of `SDelHkey` or `DeliveryNumber` must be given; otherwise an error is raised and the procedure returns `-1`.\n2. If only `DeliveryNumber` is given, the delivery key is looked up in `SDelHeader` by `SDelHNr` (first match, no defined order). If `SDelHkey` is given, it is used and `DeliveryNumber` is ignored; the two values are not checked against each other.\n3. The delivery is only deleted if it\n - is not locked by Picco (`LockedByPicco` is not `Y`), **or** is locked by Picco for the same user passed in `PiccoUser`, and\n - has status `NULL` or `NEW`.\n4. If these conditions are met, the internal delete routine runs:\n - all delivery lines (`SDelDetail`) of the delivery are deleted,\n - entries in `InvBinItemLog_In_Price` that reference the delivery (via `DeliveryId` or `DeliveryId_Assigned`) are unlinked: delivery references and `SupplierId` are set to `NULL`, `Price` to `0`, `QuerySource` to `7` and `RecordModifiedOn` to the current time,\n - the delivery header (`SDelHeader`) is deleted.\n The call then returns the row `ReturnMSG` = `Deleting was successfull`.\n5. Otherwise the row `ReturnMSG` = `Delivery Header does not exists` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHkey` | int | No | Internal key of the supplier delivery (`SDelHeader.SDelHKey`). Takes precedence over `DeliveryNumber`. Either this or `DeliveryNumber` is required. |\n| `DeliveryNumber` | int | No | Delivery number (`SDelHeader.SDelHNr`). Used to look up the delivery key if `SDelHkey` is not given. |\n| `PiccoUser` | varchar(50) | No | Picco user name. A delivery locked by Picco can only be deleted if this value equals the user stored in `SDelHeader.PiccoUser`. |\n\n- The check for missing values uses `ISNULL(..., '')`; for `int` parameters the value `0` is treated the same as \"not provided\".\n- The message `Delivery Header does not exists` is also returned when the delivery exists but is locked by Picco for another user or has a status other than `NULL`/`NEW`.\n- The pre-check accepts status `NULL`, but the internal delete routine only deletes deliveries with status exactly `NEW`. For a delivery with status `NULL` nothing is deleted, yet `Deleting was successfull` is returned.\n- The internal delete runs in its own transaction (or a savepoint if a transaction is already open). Errors are caught, rolled back and written to the error log via `log.InsertError`; they are **not** passed to the caller, and the success message is returned anyway. Verify the result if needed.\n- The delivery and its lines are read with `NOLOCK` before deletion; the deletes and updates use `ROWLOCK`.\n- When looking up by `DeliveryNumber`, duplicate numbers lead to an arbitrary delivery being chosen.\n\nDocumentation: https://pixi-api-docs.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": "Deletes a supplier delivery (delivery header and lines) with status NEW, identified by delivery reference or delivery number.\n\nDeletes a supplier delivery from `SDelHeader` together with its lines in `SDelDetail`.\n\n1. At least one of `SDelHkey` or `DeliveryNumber` must be given; otherwise an error is raised and the procedure returns `-1`.\n2. If only `DeliveryNumber` is given, the delivery key is looked up in `SDelHeader` by `SDelHNr` (first match, no defined order). If `SDelHkey` is given, it is used and `DeliveryNumber` is ignored; the two values are not checked against each other.\n3. The delivery is only deleted if it\n - is not locked by Picco (`LockedByPicco` is not `Y`), **or** is locked by Picco for the same user passed in `PiccoUser`, and\n - has status `NULL` or `NEW`.\n4. If these conditions are met, the internal delete routine runs:\n - all delivery lines (`SDelDetail`) of the delivery are deleted,\n - entries in `InvBinItemLog_In_Price` that reference the delivery (via `DeliveryId` or `DeliveryId_Assigned`) are unlinked: delivery references and `SupplierId` are set to `NULL`, `Price` to `0`, `QuerySource` to `7` and `RecordModifiedOn` to the current time,\n - the delivery header (`SDelHeader`) is deleted.\n The call then returns the row `ReturnMSG` = `Deleting was successfull`.\n5. Otherwise the row `ReturnMSG` = `Delivery Header does not exists` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHkey` | int | No | Internal key of the supplier delivery (`SDelHeader.SDelHKey`). Takes precedence over `DeliveryNumber`. Either this or `DeliveryNumber` is required. |\n| `DeliveryNumber` | int | No | Delivery number (`SDelHeader.SDelHNr`). Used to look up the delivery key if `SDelHkey` is not given. |\n| `PiccoUser` | varchar(50) | No | Picco user name. A delivery locked by Picco can only be deleted if this value equals the user stored in `SDelHeader.PiccoUser`. |\n\n- The check for missing values uses `ISNULL(..., '')`; for `int` parameters the value `0` is treated the same as \"not provided\".\n- The message `Delivery Header does not exists` is also returned when the delivery exists but is locked by Picco for another user or has a status other than `NULL`/`NEW`.\n- The pre-check accepts status `NULL`, but the internal delete routine only deletes deliveries with status exactly `NEW`. For a delivery with status `NULL` nothing is deleted, yet `Deleting was successfull` is returned.\n- The internal delete runs in its own transaction (or a savepoint if a transaction is already open). Errors are caught, rolled back and written to the error log via `log.InsertError`; they are **not** passed to the caller, and the success message is returned anyway. Verify the result if needed.\n- The delivery and its lines are read with `NOLOCK` before deletion; the deletes and updates use `ROWLOCK`.\n- When looking up by `DeliveryNumber`, duplicate numbers lead to an arbitrary delivery being chosen.\n\nDocumentation: https://pixi-api-docs.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": "Deletes one or more item lines from a supplier delivery, identified by delivery line key, internal item number or EAN.\n\nRemoves item lines (`SDelDetail`) from a supplier delivery (`SDelHeader`).\n\n**Identifying the delivery.** Pass either `SDelHKey` or `DeliveryNumber`, which is matched against `SDelHNr`. If only `DeliveryNumber` is given, the first matching `SDelHKey` is used.\n\n**Identifying the lines.** Pass at least one of `SDelDKey`, `ItemNrInternal` or `EANUPC`.\n\n**Validation, in this order:**\n1. A delivery reference or number is present.\n2. An item identifier is present.\n3. The delivery is not locked by Picco (`LockedByPicco` is NULL).\n4. The `SDelDKey` exists in `SDelDetail`, if given.\n5. The `EANUPC` exists in `Items`, if given.\n6. The `ItemNrInternal` exists in `Items` (`ItemNrInt`), if given.\n7. The delivery exists and its status is not `CLS` (closed) or `INV` (invoiced).\n\nIf a check fails, the call raises an error and nothing is deleted.\n\n**Deletion.**\n- If `SDelDKey` is given, exactly that delivery line is deleted. `ItemNrInternal` and `EANUPC` are then ignored for the deletion.\n- Otherwise the call deletes all lines of the delivery whose item matches `ItemNrInternal` **or** `EANUPC`. This can remove several lines.\n\nThe call returns no result set.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | No | Internal key of the supplier delivery (`SDelHeader.SDelHKey`). Either this or `DeliveryNumber` is required. |\n| `DeliveryNumber` | int | No | Delivery number (`SDelHeader.SDelHNr`). Used to look up the delivery key when `SDelHKey` is not given. |\n| `SDelDKey` | int | No | Key of the delivery line (`SDelDetail.SDelDkey`) to delete. If given, only this line is deleted. |\n| `ItemNrInternal` | varchar(50) | No | Internal item number (`Items.ItemNrInt`). All lines of the delivery with this item are deleted when `SDelDKey` is not given. |\n| `EANUPC` | varchar(13) | No | EAN/UPC of the item (`Items.EANUPC`). All lines of the delivery with this item are deleted when `SDelDKey` is not given. |\n\n- **Line key not checked against the delivery.** When deleting by `SDelDKey`, the code does not check that the line belongs to the given delivery. The status and lock checks apply to the delivery passed in, but the line with that key is deleted even if it belongs to another delivery.\n- **Unknown delivery number gives a misleading error.** If `DeliveryNumber` does not match any delivery, the key stays NULL. The call then fails with `You cant delete items from closed or invoiced deliveries.`\n- **Item checks are global.** The `EANUPC` and `ItemNrInternal` checks only test that the item exists in `Items`. If the item exists but is not on the delivery, nothing is deleted and no error is raised.\n- **Both identifiers match with OR.** If both `ItemNrInternal` and `EANUPC` are given without `SDelDKey`, lines matching either value are deleted.\n- **Zero counts as empty.** Empty values are converted to NULL. Because the integer parameters are compared with `''`, the value `0` for `SDelHKey`, `DeliveryNumber` or `SDelDKey` is also treated as not provided.\n- **No transaction and loose lock read.** The procedure does not use an explicit transaction. The lock flag `LockedByPicco` is read `WITH (NOLOCK)`.\n- **Return code.** On errors the procedure returns `-1` after `RAISERROR` with severity 16.\n\nDocumentation: https://pixi-api-docs.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": "Deletes all lines and then the empty supplier orders with status NEW that were created by the given user.\n\nCleans up supplier orders (disposition) that are still in status NEW (`StatusId = 1`) for one creating user.\n\n1. Reads the setting `LogControl_DoNotDeleteOrderlinesOnNew`. If it is `1`, the call does nothing.\n2. Resolves `@CreateEmp` to a user ID using `inf.UserGetByName`. No fallback user is used.\n3. Deletes all rows in `pixi.SupplierOrderLine` that belong to supplier orders with `StatusId = 1` and `RecordCreatedByUserId` equal to that user ID.\n4. Deletes the supplier orders with `StatusId = 1`, created by that user, that no longer have any order lines.\n\nOnly orders created by the given user are affected. Orders of other users and orders in any other status stay unchanged. The call returns no result set.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `CreateEmp` | varchar(50) | No | User name (from `UCS_USERS`) whose NEW supplier orders and their lines are deleted. |\n\n- If `@CreateEmp` does not exist in `UCS_USERS`, the user ID is `NULL` and nothing is deleted. The call gives no feedback in this case.\n- If the setting `LogControl_DoNotDeleteOrderlinesOnNew` does not exist, it counts as `0`, so the deletion runs.\n- Both `DELETE` statements run without an explicit transaction. The subqueries read with `NOLOCK`.\n- The orders are deleted with a `NOT IN` check against all `SupplierOrderId` values of `pixi.SupplierOrderLine`. If any line has a `NULL` `SupplierOrderId`, no order is deleted.\n- An earlier deletion of history rows (`SOrderlinesHist`) is commented out and does not run.\n- The deletion is permanent. The call returns no rows and no row counts.\n\nDocumentation: https://pixi-api-docs.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": "Returns open supplier order lines and order lines with status ANG, with open quantity and estimated delivery date, paged by line key.\n\nCollects open purchase quantities for disposition (replenishment planning) from two sources and returns them as one list.\n\n**Type `1200` – supplier order lines** (`pixi.SupplierOrderLine`):\n- Only lines whose supplier order has a status with `IsOrderedConfirmed = 1` (ordered or confirmed).\n- Only lines with an open quantity other than 0. The open quantity is `Qty - DeliveredQty - UndeliveredQty`, with missing values counted as 0.\n- `EstimatedDeliveryDate` is the line's estimated delivery date, or `'0'` if none is set.\n- `SupplOrderNR` is the internal number of the supplier order. `SupplOrderDate` is the creation date of the line.\n\n**Type `2200` – order lines with status `ANG`** (`Orderlines`):\n- Only lines with `Status = 'ANG'` and a quantity other than 0.\n- `Qty` and `QtyOrdered` are the line quantity. `QtyReceived` and `QtyNotDelivered` are always 0.\n- `EstimatedDeliveryDate` is today plus the supplier's `DefaultDeliveryDays`. If the supplier has no value, 1 day is used.\n- `SupplOrderNR` is the order number. `SupplOrderDate` is the creation date of the line.\n\nFor both types, item data (`SupplNr`, `ItemNrInt`, `ItemNrSuppl`) comes from `Items` via a left join. `ItemNrSuppl` falls back to `ItemNrInt` when the item has no supplier item number.\n\n**Paging:** only lines whose key is greater than `SOrderlineKeyStart` are returned. The combined list is sorted by `SOrderlineKey` in ascending order and limited to `RowCount` rows. To get the next page, pass the last `SOrderlineKey` you received as the new `SOrderlineKeyStart`.\n\nAll dates are returned as text in the format `dd.mm.yyyy`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SOrderlineKeyStart` | int | No | Only lines with a key greater than this value are returned. Used for paging; NULL is treated as 0. |\n| `RowCount` | int | No | Maximum number of rows returned. NULL is treated as 10000. |\n\n- All tables are read with `NOLOCK`, so the result can include uncommitted data.\n- `SOrderlineKey` comes from two different key spaces: `SupplierOrderLine.Id` for type `1200` and `Orderlines.OrderlineKey` for type `2200`. The same key value can therefore appear in both types.\n - Paging uses a single threshold for both sources.\n - If a page ends in the middle of such a duplicate key, the remaining row with that key is skipped on the next page.\n - Always evaluate `Type` together with `SOrderlineKey`.\n- The two sources are combined with `UNION`, so rows that are completely identical are returned only once.\n- If `RowCount` is NULL, 10000 is used.\n- `EstimatedDeliveryDate` for type `2200` is calculated from the current server date at the time of the call.\n\nDocumentation: https://pixi-api-docs.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": "Returns open supplier order lines and order lines with status ANG, with open quantity and estimated delivery date, paged by line key.\n\nCollects open purchase quantities for disposition (replenishment planning) from two sources and returns them as one list.\n\n**Type `1200` – supplier order lines** (`pixi.SupplierOrderLine`):\n- Only lines whose supplier order has a status with `IsOrderedConfirmed = 1` (ordered or confirmed).\n- Only lines with an open quantity other than 0. The open quantity is `Qty - DeliveredQty - UndeliveredQty`, with missing values counted as 0.\n- `EstimatedDeliveryDate` is the line's estimated delivery date, or `'0'` if none is set.\n- `SupplOrderNR` is the internal number of the supplier order. `SupplOrderDate` is the creation date of the line.\n\n**Type `2200` – order lines with status `ANG`** (`Orderlines`):\n- Only lines with `Status = 'ANG'` and a quantity other than 0.\n- `Qty` and `QtyOrdered` are the line quantity. `QtyReceived` and `QtyNotDelivered` are always 0.\n- `EstimatedDeliveryDate` is today plus the supplier's `DefaultDeliveryDays`. If the supplier has no value, 1 day is used.\n- `SupplOrderNR` is the order number. `SupplOrderDate` is the creation date of the line.\n\nFor both types, item data (`SupplNr`, `ItemNrInt`, `ItemNrSuppl`) comes from `Items` via a left join. `ItemNrSuppl` falls back to `ItemNrInt` when the item has no supplier item number.\n\n**Paging:** only lines whose key is greater than `SOrderlineKeyStart` are returned. The combined list is sorted by `SOrderlineKey` in ascending order and limited to `RowCount` rows. To get the next page, pass the last `SOrderlineKey` you received as the new `SOrderlineKeyStart`.\n\nAll dates are returned as text in the format `dd.mm.yyyy`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SOrderlineKeyStart` | int | No | Only lines with a key greater than this value are returned. Used for paging; NULL is treated as 0. |\n| `RowCount` | int | No | Maximum number of rows returned. NULL is treated as 10000. |\n\n- All tables are read with `NOLOCK`, so the result can include uncommitted data.\n- `SOrderlineKey` comes from two different key spaces: `SupplierOrderLine.Id` for type `1200` and `Orderlines.OrderlineKey` for type `2200`. The same key value can therefore appear in both types.\n - Paging uses a single threshold for both sources.\n - If a page ends in the middle of such a duplicate key, the remaining row with that key is skipped on the next page.\n - Always evaluate `Type` together with `SOrderlineKey`.\n- The two sources are combined with `UNION`, so rows that are completely identical are returned only once.\n- If `RowCount` is NULL, 10000 is used.\n- `EstimatedDeliveryDate` for type `2200` is calculated from the current server date at the time of the call.\n\nDocumentation: https://pixi-api-docs.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": "Returns supplier delivery headers (goods receipts), filtered by supplier, delivery number, item, location, status, dates and Picco lock, with key-based paging.\n\nReturns rows from the supplier delivery header table (`SDelHeader`) together with the supplier name from `Suppliers` (left join on `SDelHSupplNr`).\n\n**Parameter handling**\n- Empty strings are treated as `NULL` for all text filters. For `SDelHKey` and `DeliveryNumber`, the value `0` is treated as \"no filter\".\n- `RowCount` defaults to 100. `NULL` and `0` also mean 100.\n- `Offset` is **not** a row offset. It is a key cursor: only deliveries with `SDelHKey` > `Offset` are returned. `0` or `NULL` means no cursor.\n\n**Filters (all combined with AND)**\n- `SDelHKey`, `SupplNr`, `DeliveryNumber` (`SDelHNr`), `LocID` (`SDelHLocationID`) and `ExternalReceiptNr`: exact match.\n- Status: by default, closed deliveries (`SDelHStatus` = `CLS`) and invoiced deliveries (`SDelHStatus` = `INV`) are excluded. Set `Closed` = 1 and/or `Invoice` = 1 to include them.\n- Creation date: `SDelHCreateDate` between `CreateDateFrom` and `CreateDateTo`. If `CreateDateTo` has the time 00:00:00, it is moved to the end of that day.\n- Update date: `SDelHUpdateDate` between `UpdateDateFrom` and `UpdateDateTo`, with the same end-of-day rule.\n- Item filter: if at least one of `ItemNrInt`, `ItemNrSuppl`, `EANUPC` or `ItemName` is set, only deliveries that contain at least one delivery line (`SDelDetail`) for a matching item are returned. All given item values must match exactly on the same item.\n- Picco user: if `PiccoUser` is set, deliveries locked by Picco (`LockedByPicco` = `Y`) for a different Picco user are excluded. Unlocked deliveries and deliveries locked by the given user are returned.\n\n**Sorting and paging**\nThe result is sorted by `SDelHKey` ascending, and at most `RowCount` rows are returned. To read the next page, pass the last `SDelHKey` received as `Offset`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | No | Internal key of a supplier delivery. `0` or NULL means no filter. |\n| `SupplNr` | varchar(200) | No | Supplier number (`SDelHSupplNr`), exact match. |\n| `DeliveryNumber` | int | No | Delivery number (`SDelHNr`). `0` or NULL means no filter. |\n| `ItemNrInt` | varchar(200) | No | Internal item number. Returns only deliveries with a line for this item. |\n| `ItemNrSuppl` | varchar(200) | No | Supplier item number. Returns only deliveries with a line for a matching item. |\n| `EANUPC` | varchar(200) | No | EAN/UPC of the item. Returns only deliveries with a line for a matching item. |\n| `ItemName` | varchar(200) | No | Item name, exact match. Returns only deliveries with a line for a matching item. |\n| `RowCount` | int | No | Maximum number of rows. NULL or `0` means 100. |\n| `Offset` | int | No | Key cursor for paging: only deliveries with `SDelHKey` greater than this value are returned. Pass the last `SDelHKey` of the previous page. |\n| `Closed` | bit | No | Include closed deliveries (status `CLS`). |\n| `Invoice` | bit | No | Include invoiced deliveries (status `INV`). |\n| `LocID` | varchar(3) | No | Location ID (`SDelHLocationID`), exact match. |\n| `PiccoUser` | varchar(50) | No | Picco user. If set, deliveries locked by Picco for another user are excluded. |\n| `CreateDateFrom` | datetime | No | Start of the creation date range. Must be used together with `CreateDateTo`. |\n| `CreateDateTo` | datetime | No | End of the creation date range. If the time is 00:00:00, it is moved to the end of that day. |\n| `UpdateDateFrom` | datetime | No | Start of the update date range. Must be used together with `UpdateDateTo`. |\n| `UpdateDateTo` | datetime | No | End of the update date range. If the time is 00:00:00, it is moved to the end of that day. |\n| `ExternalReceiptNr` | varchar(50) | No | External receipt number, exact match. |\n\n- All tables are read `WITH (NOLOCK)`. Results can contain uncommitted data.\n- Date ranges need **both** bounds. If only `CreateDateFrom` or only `CreateDateTo` is set, the comparison uses `BETWEEN` with `NULL` and no rows are returned. The same applies to the update date pair.\n- The end-of-day adjustment uses `fPixi_GetDateEndOfDay`. Its definition is not attached, so the exact end-of-day time is not known. `CreateDateFrom`/`UpdateDateFrom` are used as passed; they are not moved to the start of the day.\n- Deliveries locked by Picco with an empty `PiccoUser` value are also excluded when `PiccoUser` is passed.\n- A negative `RowCount` causes a SQL error from `TOP`.\n- The item filter uses exact equality; `ItemName` does not support wildcards.\n\nDocumentation: https://pixi-api-docs.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": "Returns supplier delivery headers (goods receipts), filtered by supplier, delivery number, item, location, status, dates and Picco lock, with key-based paging.\n\nReturns rows from the supplier delivery header table (`SDelHeader`) together with the supplier name from `Suppliers` (left join on `SDelHSupplNr`).\n\n**Parameter handling**\n- Empty strings are treated as `NULL` for all text filters. For `SDelHKey` and `DeliveryNumber`, the value `0` is treated as \"no filter\".\n- `RowCount` defaults to 100. `NULL` and `0` also mean 100.\n- `Offset` is **not** a row offset. It is a key cursor: only deliveries with `SDelHKey` > `Offset` are returned. `0` or `NULL` means no cursor.\n\n**Filters (all combined with AND)**\n- `SDelHKey`, `SupplNr`, `DeliveryNumber` (`SDelHNr`), `LocID` (`SDelHLocationID`) and `ExternalReceiptNr`: exact match.\n- Status: by default, closed deliveries (`SDelHStatus` = `CLS`) and invoiced deliveries (`SDelHStatus` = `INV`) are excluded. Set `Closed` = 1 and/or `Invoice` = 1 to include them.\n- Creation date: `SDelHCreateDate` between `CreateDateFrom` and `CreateDateTo`. If `CreateDateTo` has the time 00:00:00, it is moved to the end of that day.\n- Update date: `SDelHUpdateDate` between `UpdateDateFrom` and `UpdateDateTo`, with the same end-of-day rule.\n- Item filter: if at least one of `ItemNrInt`, `ItemNrSuppl`, `EANUPC` or `ItemName` is set, only deliveries that contain at least one delivery line (`SDelDetail`) for a matching item are returned. All given item values must match exactly on the same item.\n- Picco user: if `PiccoUser` is set, deliveries locked by Picco (`LockedByPicco` = `Y`) for a different Picco user are excluded. Unlocked deliveries and deliveries locked by the given user are returned.\n\n**Sorting and paging**\nThe result is sorted by `SDelHKey` ascending, and at most `RowCount` rows are returned. To read the next page, pass the last `SDelHKey` received as `Offset`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | No | Internal key of a supplier delivery. `0` or NULL means no filter. |\n| `SupplNr` | varchar(200) | No | Supplier number (`SDelHSupplNr`), exact match. |\n| `DeliveryNumber` | int | No | Delivery number (`SDelHNr`). `0` or NULL means no filter. |\n| `ItemNrInt` | varchar(200) | No | Internal item number. Returns only deliveries with a line for this item. |\n| `ItemNrSuppl` | varchar(200) | No | Supplier item number. Returns only deliveries with a line for a matching item. |\n| `EANUPC` | varchar(200) | No | EAN/UPC of the item. Returns only deliveries with a line for a matching item. |\n| `ItemName` | varchar(200) | No | Item name, exact match. Returns only deliveries with a line for a matching item. |\n| `RowCount` | int | No | Maximum number of rows. NULL or `0` means 100. |\n| `Offset` | int | No | Key cursor for paging: only deliveries with `SDelHKey` greater than this value are returned. Pass the last `SDelHKey` of the previous page. |\n| `Closed` | bit | No | Include closed deliveries (status `CLS`). |\n| `Invoice` | bit | No | Include invoiced deliveries (status `INV`). |\n| `LocID` | varchar(3) | No | Location ID (`SDelHLocationID`), exact match. |\n| `PiccoUser` | varchar(50) | No | Picco user. If set, deliveries locked by Picco for another user are excluded. |\n| `CreateDateFrom` | datetime | No | Start of the creation date range. Must be used together with `CreateDateTo`. |\n| `CreateDateTo` | datetime | No | End of the creation date range. If the time is 00:00:00, it is moved to the end of that day. |\n| `UpdateDateFrom` | datetime | No | Start of the update date range. Must be used together with `UpdateDateTo`. |\n| `UpdateDateTo` | datetime | No | End of the update date range. If the time is 00:00:00, it is moved to the end of that day. |\n| `ExternalReceiptNr` | varchar(50) | No | External receipt number, exact match. |\n\n- All tables are read `WITH (NOLOCK)`. Results can contain uncommitted data.\n- Date ranges need **both** bounds. If only `CreateDateFrom` or only `CreateDateTo` is set, the comparison uses `BETWEEN` with `NULL` and no rows are returned. The same applies to the update date pair.\n- The end-of-day adjustment uses `fPixi_GetDateEndOfDay`. Its definition is not attached, so the exact end-of-day time is not known. `CreateDateFrom`/`UpdateDateFrom` are used as passed; they are not moved to the start of the day.\n- Deliveries locked by Picco with an empty `PiccoUser` value are also excluded when `PiccoUser` is passed.\n- A negative `RowCount` causes a SQL error from `TOP`.\n- The item filter uses exact equality; `ItemName` does not support wildcards.\n\nDocumentation: https://pixi-api-docs.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": "Returns the lines of supplier deliveries (goods receipts) with item data, prices, tags and batch details, filtered by delivery, item and date range.\n\nReads delivery lines from `SDelDetail` together with their delivery header (`SDelHeader`) and returns one row per line.\n\n**Parameter normalisation**\n- `0` for `SDelHKey`/`DeliveryNumber` and empty strings for `ItemNrInternal`/`EANUPC` are treated as not set.\n- `RowCount` defaults to 100 and `Offset` to 0 if passed as NULL.\n\n**Resolving the filters**\n- **Item:** `ItemNrInternal` is looked up as an internal item number and `EANUPC` as an EAN code in the item code table. If both are given, the first item that matches *either* code is used.\n- **Delivery:** if `SDelHKey` is not set, `DeliveryNumber` is resolved to the key of the first delivery with that number. If `SDelHKey` is set, `DeliveryNumber` is ignored.\n- **Start date:** if `DateFrom` is empty and a delivery is known, the start date is the day of the oldest line of that delivery. Otherwise it defaults to 700 days before today.\n- **End date:** `DateTo` defaults to 365 days after today.\n\n**Selection**\nLines are selected when all of these apply:\n- `SDelDkey` > `Offset`.\n- They belong to the resolved delivery, if any.\n- They belong to the resolved item, if any.\n- Their creation date is in the range `DateFrom` (inclusive) to `DateTo` (exclusive).\n\nThe first `RowCount` lines in ascending `SDelDkey` order are taken. Only lines that also exist in the goods receipt view `pvGoodsReceiptItemDbo` are returned; that view supplies the internal supplier order number.\n\n**Enrichment**\n- Item master data (internal and supplier item number, EAN, picture links) comes from `items`.\n- `DeliveryItemNrSuppl` is the supplier item number of the delivering supplier from `AddItems`.\n- `ItemTAGs` lists all tag names of the item, separated by `|` and sorted alphabetically.\n- `BatchManagementDetails` is filled only for items tagged with tag `-6` or `-7` (batch/best-before management). It contains an XML fragment with one `row` element per bin item log entry of that delivery and item that carries a batch number or best-before date. Each `row` has the attribute `BinItemLogId` and the child elements `BinItemLogId`, `LocationId`, `BinRef`, `ItemRef`, `DeliveredQty`, `BatchNumber` and `BestBeforeDate`.\n\n**Paging**\nPaging is keyset-based. To get the next page, pass the highest `SDelDkey` of the previous page as `Offset`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | No | Internal key of the supplier delivery (goods receipt header). `0` or NULL means no delivery filter. Takes precedence over `DeliveryNumber`. |\n| `DeliveryNumber` | int | No | Delivery number (`SDelHNr`). Used only if `SDelHKey` is not set and is resolved to the first matching delivery. If no delivery matches, no delivery filter is applied. |\n| `ItemNrInternal` | varchar(50) | No | Internal item number used to filter by item. An empty string means no filter. If the number is not found, no item filter is applied. |\n| `EANUPC` | varchar(13) | No | EAN/UPC code used to filter by item. If combined with `ItemNrInternal`, the first item matching either code is used. |\n| `RowCount` | int | No | Maximum number of delivery lines to return (page size). NULL is treated as 100. |\n| `Offset` | int | No | Keyset paging cursor. Only lines with `SDelDkey` greater than this value are returned; pass the last `SDelDkey` of the previous page. |\n| `DateFrom` | datetime | No | Lower bound (inclusive) for the line creation date. Default: the day of the oldest line of the given delivery, otherwise 700 days before today. |\n| `DateTo` | datetime | No | Upper bound (exclusive) for the line creation date. Default: 365 days after today. |\n\n- All reads use `NOLOCK`, so uncommitted data can appear.\n- **Unresolved filters:** if `DeliveryNumber`, `ItemNrInternal` or `EANUPC` cannot be resolved, the corresponding filter is silently dropped. In that case the call returns lines of all deliveries or items in the date range instead of an empty result.\n- **Delivery without lines:** if a delivery key is known but `DateFrom` is empty and the delivery has no lines, the start date becomes NULL and no rows are returned.\n- **`DateTo` is exclusive and not extended to the end of the day.** A date-only value such as `2024-05-31` excludes that day.\n- **Default start date:** the default is 700 days back, not exactly two years.\n- **`Offset` is not a row count to skip.** It is compared with `SDelDkey`.\n- **Sort order:** the final result has no `ORDER BY`, so the output order is not guaranteed. Sort by `SDelDkey` on the client side if needed.\n- **Fewer rows than `RowCount`:** lines whose item does not exist in `items` are dropped after the `RowCount` limit has been applied, so a page can contain fewer rows.\n- **Duplicate rows:** if `AddItems` holds several rows for the same item and supplier, a line can be returned more than once.\n- **Batch details per delivery, not per line:** bin item log entries are matched by delivery and item only. If an item occurs on several lines of one delivery, each line shows all entries. `DeliveredQty` inside the XML is converted to an integer.\n\nDocumentation: https://pixi-api-docs.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": "Returns the lines of supplier deliveries (goods receipts) with item data, prices, tags and batch details, filtered by delivery, item and date range.\n\nReads delivery lines from `SDelDetail` together with their delivery header (`SDelHeader`) and returns one row per line.\n\n**Parameter normalisation**\n- `0` for `SDelHKey`/`DeliveryNumber` and empty strings for `ItemNrInternal`/`EANUPC` are treated as not set.\n- `RowCount` defaults to 100 and `Offset` to 0 if passed as NULL.\n\n**Resolving the filters**\n- **Item:** `ItemNrInternal` is looked up as an internal item number and `EANUPC` as an EAN code in the item code table. If both are given, the first item that matches *either* code is used.\n- **Delivery:** if `SDelHKey` is not set, `DeliveryNumber` is resolved to the key of the first delivery with that number. If `SDelHKey` is set, `DeliveryNumber` is ignored.\n- **Start date:** if `DateFrom` is empty and a delivery is known, the start date is the day of the oldest line of that delivery. Otherwise it defaults to 700 days before today.\n- **End date:** `DateTo` defaults to 365 days after today.\n\n**Selection**\nLines are selected when all of these apply:\n- `SDelDkey` > `Offset`.\n- They belong to the resolved delivery, if any.\n- They belong to the resolved item, if any.\n- Their creation date is in the range `DateFrom` (inclusive) to `DateTo` (exclusive).\n\nThe first `RowCount` lines in ascending `SDelDkey` order are taken. Only lines that also exist in the goods receipt view `pvGoodsReceiptItemDbo` are returned; that view supplies the internal supplier order number.\n\n**Enrichment**\n- Item master data (internal and supplier item number, EAN, picture links) comes from `items`.\n- `DeliveryItemNrSuppl` is the supplier item number of the delivering supplier from `AddItems`.\n- `ItemTAGs` lists all tag names of the item, separated by `|` and sorted alphabetically.\n- `BatchManagementDetails` is filled only for items tagged with tag `-6` or `-7` (batch/best-before management). It contains an XML fragment with one `row` element per bin item log entry of that delivery and item that carries a batch number or best-before date. Each `row` has the attribute `BinItemLogId` and the child elements `BinItemLogId`, `LocationId`, `BinRef`, `ItemRef`, `DeliveredQty`, `BatchNumber` and `BestBeforeDate`.\n\n**Paging**\nPaging is keyset-based. To get the next page, pass the highest `SDelDkey` of the previous page as `Offset`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | No | Internal key of the supplier delivery (goods receipt header). `0` or NULL means no delivery filter. Takes precedence over `DeliveryNumber`. |\n| `DeliveryNumber` | int | No | Delivery number (`SDelHNr`). Used only if `SDelHKey` is not set and is resolved to the first matching delivery. If no delivery matches, no delivery filter is applied. |\n| `ItemNrInternal` | varchar(50) | No | Internal item number used to filter by item. An empty string means no filter. If the number is not found, no item filter is applied. |\n| `EANUPC` | varchar(13) | No | EAN/UPC code used to filter by item. If combined with `ItemNrInternal`, the first item matching either code is used. |\n| `RowCount` | int | No | Maximum number of delivery lines to return (page size). NULL is treated as 100. |\n| `Offset` | int | No | Keyset paging cursor. Only lines with `SDelDkey` greater than this value are returned; pass the last `SDelDkey` of the previous page. |\n| `DateFrom` | datetime | No | Lower bound (inclusive) for the line creation date. Default: the day of the oldest line of the given delivery, otherwise 700 days before today. |\n| `DateTo` | datetime | No | Upper bound (exclusive) for the line creation date. Default: 365 days after today. |\n\n- All reads use `NOLOCK`, so uncommitted data can appear.\n- **Unresolved filters:** if `DeliveryNumber`, `ItemNrInternal` or `EANUPC` cannot be resolved, the corresponding filter is silently dropped. In that case the call returns lines of all deliveries or items in the date range instead of an empty result.\n- **Delivery without lines:** if a delivery key is known but `DateFrom` is empty and the delivery has no lines, the start date becomes NULL and no rows are returned.\n- **`DateTo` is exclusive and not extended to the end of the day.** A date-only value such as `2024-05-31` excludes that day.\n- **Default start date:** the default is 700 days back, not exactly two years.\n- **`Offset` is not a row count to skip.** It is compared with `SDelDkey`.\n- **Sort order:** the final result has no `ORDER BY`, so the output order is not guaranteed. Sort by `SDelDkey` on the client side if needed.\n- **Fewer rows than `RowCount`:** lines whose item does not exist in `items` are dropped after the `RowCount` limit has been applied, so a page can contain fewer rows.\n- **Duplicate rows:** if `AddItems` holds several rows for the same item and supplier, a line can be returned more than once.\n- **Batch details per delivery, not per line:** bin item log entries are matched by delivery and item only. If an item occurs on several lines of one delivery, each line shows all entries. `DeliveredQty` inside the XML is converted to an integer.\n\nDocumentation: https://pixi-api-docs.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": "Returns FIFO-matched supplier purchase prices and selling prices for stock movements of one or all items within a date range of up to 31 days.\n\nReturns the historical FIFO matching between stock receipts (with their supplier price) and stock issues (with their selling price), based on the inventory bin item log.\n\n**Parameter validation**\n- `DateFrom` and `DateTo` must both be passed, even though they are declared with a `NULL` default.\n- Both values are reduced to their date part. The end of the range is `DateTo` + 1 day.\n- The range from `DateFrom` to `DateTo` + 1 day must not exceed 31 days.\n- `DateTo` must be at most yesterday; data for the current day cannot be requested.\n\n**Selection**\n- If `ItemKey` is passed, only that item is returned; otherwise all items.\n- A receipt is included if its creation date or the modification date of its supplier price record lies between `DateFrom` and `DateTo` + 1 day (both bounds inclusive, compared as dates at midnight).\n- Receipts are combined with issues in two ways, and the results of both are added together:\n 1. issues that reference the receipt record directly,\n 2. issues that match the receipt by item and FIFO row number.\n- For each match the supplier price, the selling price, the source descriptions of both prices, the delivery (own delivery or assigned delivery) and the sales document line (invoice line or POS line) are collected.\n\n**Output**\n- If no rows were found, a single row with `Staus` = `Warning` is returned.\n- Otherwise the data rows are returned, sorted by `InvBinItemLogId`. The supplier delivery note number is looked up from the supplier delivery; the sell document date and number come from the invoice or, if there is none, from the POS receipt.\n- Any error, including the validation errors, is returned as a row with `Staus` = `Error` and the error text in `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Key of the item to restrict the result to. `NULL` returns data for all items. |\n| `DateFrom` | datetime | No | Start of the date range (date part only). Mandatory in practice: if omitted, an error row is returned. |\n| `DateTo` | datetime | No | End of the date range (date part only, inclusive). Must be at most yesterday, and the range from `DateFrom` to `DateTo` + 1 day must not exceed 31 days. Mandatory in practice. |\n\n- The status column is spelled `Staus` (not `Status`) in both the warning and the error row.\n- Errors are never returned as `SqlMessage`; the `RAISERROR` calls are caught and returned as a normal row. Check the first column name of the result to distinguish data from status rows.\n- The upper bound is inclusive at midnight of `DateTo` + 1 day, so records created exactly at 00:00 on the following day are also included.\n- If `DateFrom` is later than `DateTo`, no validation error occurs; the call simply returns the `Warning` row.\n- A receipt/issue pair may appear twice if it matches both join paths (direct reference and item + row number); rows are not de-duplicated.\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- The temporary table is dropped via `util.TempTableDrop`, whose definition is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Returns FIFO-matched supplier purchase prices and selling prices for stock movements of one or all items within a date range of up to 31 days.\n\nReturns the historical FIFO matching between stock receipts (with their supplier price) and stock issues (with their selling price), based on the inventory bin item log.\n\n**Parameter validation**\n- `DateFrom` and `DateTo` must both be passed, even though they are declared with a `NULL` default.\n- Both values are reduced to their date part. The end of the range is `DateTo` + 1 day.\n- The range from `DateFrom` to `DateTo` + 1 day must not exceed 31 days.\n- `DateTo` must be at most yesterday; data for the current day cannot be requested.\n\n**Selection**\n- If `ItemKey` is passed, only that item is returned; otherwise all items.\n- A receipt is included if its creation date or the modification date of its supplier price record lies between `DateFrom` and `DateTo` + 1 day (both bounds inclusive, compared as dates at midnight).\n- Receipts are combined with issues in two ways, and the results of both are added together:\n 1. issues that reference the receipt record directly,\n 2. issues that match the receipt by item and FIFO row number.\n- For each match the supplier price, the selling price, the source descriptions of both prices, the delivery (own delivery or assigned delivery) and the sales document line (invoice line or POS line) are collected.\n\n**Output**\n- If no rows were found, a single row with `Staus` = `Warning` is returned.\n- Otherwise the data rows are returned, sorted by `InvBinItemLogId`. The supplier delivery note number is looked up from the supplier delivery; the sell document date and number come from the invoice or, if there is none, from the POS receipt.\n- Any error, including the validation errors, is returned as a row with `Staus` = `Error` and the error text in `Message`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Key of the item to restrict the result to. `NULL` returns data for all items. |\n| `DateFrom` | datetime | No | Start of the date range (date part only). Mandatory in practice: if omitted, an error row is returned. |\n| `DateTo` | datetime | No | End of the date range (date part only, inclusive). Must be at most yesterday, and the range from `DateFrom` to `DateTo` + 1 day must not exceed 31 days. Mandatory in practice. |\n\n- The status column is spelled `Staus` (not `Status`) in both the warning and the error row.\n- Errors are never returned as `SqlMessage`; the `RAISERROR` calls are caught and returned as a normal row. Check the first column name of the result to distinguish data from status rows.\n- The upper bound is inclusive at midnight of `DateTo` + 1 day, so records created exactly at 00:00 on the following day are also included.\n- If `DateFrom` is later than `DateTo`, no validation error occurs; the call simply returns the `Warning` row.\n- A receipt/issue pair may appear twice if it matches both join paths (direct reference and item + row number); rows are not de-duplicated.\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- The temporary table is dropped via `util.TempTableDrop`, whose definition is not attached.\n\nDocumentation: https://pixi-api-docs.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": "Returns the FIFO supplier prices of stock-in movements for one or all items within a date range of at most 31 days.\n\nReturns the supplier prices that Pixi assigned to stock-in movements (FIFO pricing), together with the item, the quantity, the supplier and the reference document.\n\n**Validation** (each failure returns a single `Error` row, see errors):\n- `DateFrom` and `DateTo` are mandatory although they default to `NULL`.\n- Both values are reduced to their date part. The end of the range is the day after `DateTo`, so `DateTo` is inclusive.\n- The range from `DateFrom` to `DateTo` may cover at most 31 calendar days (inclusive).\n- `DateTo` must be yesterday or earlier; data for the current day cannot be requested.\n\n**Selection**:\n- If `ItemKey` is given, only movements of that item are returned; otherwise all items.\n- A record is included if either the stock-in date of the movement (`DatePutToStock`) or the last modification date of its price record lies within the range. Records whose price was recalculated in the range are therefore returned even if the item was put to stock earlier.\n- `RefType` describes the source the price was taken from; `RefDocumentNumber` is the number of the linked supplier delivery (the directly assigned delivery, or as fallback the delivery assigned later), if any.\n\n**Result**: the rows are sorted by `InvBinItemLogId`. If nothing matches, a single `Warning` row is returned instead.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal item key (`ItemRef` of the stock movement). `NULL` returns movements of all items. |\n| `DateFrom` | datetime | No | Start of the date range (inclusive, time part is ignored). Effectively mandatory: if omitted, an `Error` row is returned. |\n| `DateTo` | datetime | No | End of the date range (inclusive, time part is ignored). Effectively mandatory; must be yesterday or earlier and at most 31 days (inclusive) after `DateFrom`. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may appear.\n- Errors are not returned as `SqlMessage`: validation errors and any other runtime error are caught and returned as a normal row with the columns `Staus` (sic, misspelled) and `Message`. Check for a `Staus` column before reading data rows.\n- If `DateFrom` is later than `DateTo`, no validation error occurs; the call simply returns the `Warning` row.\n- The range end is compared with `<=` against midnight of the day after `DateTo`, so records stamped exactly at that midnight are included as well.\n- Whether a stock-in movement can have more than one price record (and thus appear in several rows) depends on the data in `InvBinItemLog_In_Price` and cannot be seen from the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns the FIFO supplier prices of stock-in movements for one or all items within a date range of at most 31 days.\n\nReturns the supplier prices that Pixi assigned to stock-in movements (FIFO pricing), together with the item, the quantity, the supplier and the reference document.\n\n**Validation** (each failure returns a single `Error` row, see errors):\n- `DateFrom` and `DateTo` are mandatory although they default to `NULL`.\n- Both values are reduced to their date part. The end of the range is the day after `DateTo`, so `DateTo` is inclusive.\n- The range from `DateFrom` to `DateTo` may cover at most 31 calendar days (inclusive).\n- `DateTo` must be yesterday or earlier; data for the current day cannot be requested.\n\n**Selection**:\n- If `ItemKey` is given, only movements of that item are returned; otherwise all items.\n- A record is included if either the stock-in date of the movement (`DatePutToStock`) or the last modification date of its price record lies within the range. Records whose price was recalculated in the range are therefore returned even if the item was put to stock earlier.\n- `RefType` describes the source the price was taken from; `RefDocumentNumber` is the number of the linked supplier delivery (the directly assigned delivery, or as fallback the delivery assigned later), if any.\n\n**Result**: the rows are sorted by `InvBinItemLogId`. If nothing matches, a single `Warning` row is returned instead.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal item key (`ItemRef` of the stock movement). `NULL` returns movements of all items. |\n| `DateFrom` | datetime | No | Start of the date range (inclusive, time part is ignored). Effectively mandatory: if omitted, an `Error` row is returned. |\n| `DateTo` | datetime | No | End of the date range (inclusive, time part is ignored). Effectively mandatory; must be yesterday or earlier and at most 31 days (inclusive) after `DateFrom`. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may appear.\n- Errors are not returned as `SqlMessage`: validation errors and any other runtime error are caught and returned as a normal row with the columns `Staus` (sic, misspelled) and `Message`. Check for a `Staus` column before reading data rows.\n- If `DateFrom` is later than `DateTo`, no validation error occurs; the call simply returns the `Warning` row.\n- The range end is compared with `<=` against midnight of the day after `DateTo`, so records stamped exactly at that midnight are included as well.\n- Whether a stock-in movement can have more than one price record (and thus appear in several rows) depends on the data in `InvBinItemLog_In_Price` and cannot be seen from the code.\n\nDocumentation: https://pixi-api-docs.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": "Returns the ordered or confirmed supplier order lines of an item with supplier number, quantity and estimated delivery date.\n\nLooks up incoming supplier deliveries for an item.\n\n1. Empty strings in `EAN`, `ItemNrSuppl` and `ItemNrInt` and the value `0` in `ItemKey` are treated as not set.\n2. The item is identified by any of the given identifiers. The criteria are combined with **OR**: a supplier order line is returned if its item matches `ItemKey`, **or** the EAN/UPC (`EANUPC`), **or** the supplier item number, **or** the internal item number.\n3. Only supplier order lines are returned whose supplier order has a status flagged as ordered/confirmed (`IsOrderedConfirmed = 1`, i.e. the statuses `BES` and `BGT`) and whose quantity is greater than 0.\n4. For each line the supplier order number, the supplier number, the ordered quantity and the estimated delivery date are returned.\n\nSort order: lines with an estimated delivery date come first, sorted ascending by that date; lines without a delivery date come last.\n\nIf no identifier is passed, no rows are returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item (`ItemKey`). `0` is treated as not set. |\n| `EAN` | varchar(13) | No | EAN/UPC of the item, compared with `EANUPC`. An empty string is treated as not set. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number of the item (`ItemNrSuppl`). An empty string is treated as not set. |\n| `ItemNrInt` | varchar(50) | No | Internal item number (`ItemNrInt`). An empty string is treated as not set. |\n\n- All tables are read with `NOLOCK`; uncommitted data may appear.\n- Because the identifiers are combined with OR, passing several identifiers that belong to different Artikel returns the lines of all of them. The result contains no item column, so the rows cannot be assigned to an item afterwards. Pass only one identifier to get unambiguous results.\n- `SupplierOrderQty` is the quantity of the supplier order line as stored; the code does not subtract quantities that have already been received.\n- `EstimatedDelivery` is converted to `datetime` and is empty if the line has no estimated delivery date.\n\nDocumentation: https://pixi-api-docs.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": "Returns the ordered or confirmed supplier order lines of an item with supplier number, quantity and estimated delivery date.\n\nLooks up incoming supplier deliveries for an item.\n\n1. Empty strings in `EAN`, `ItemNrSuppl` and `ItemNrInt` and the value `0` in `ItemKey` are treated as not set.\n2. The item is identified by any of the given identifiers. The criteria are combined with **OR**: a supplier order line is returned if its item matches `ItemKey`, **or** the EAN/UPC (`EANUPC`), **or** the supplier item number, **or** the internal item number.\n3. Only supplier order lines are returned whose supplier order has a status flagged as ordered/confirmed (`IsOrderedConfirmed = 1`, i.e. the statuses `BES` and `BGT`) and whose quantity is greater than 0.\n4. For each line the supplier order number, the supplier number, the ordered quantity and the estimated delivery date are returned.\n\nSort order: lines with an estimated delivery date come first, sorted ascending by that date; lines without a delivery date come last.\n\nIf no identifier is passed, no rows are returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal key of the item (`ItemKey`). `0` is treated as not set. |\n| `EAN` | varchar(13) | No | EAN/UPC of the item, compared with `EANUPC`. An empty string is treated as not set. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier item number of the item (`ItemNrSuppl`). An empty string is treated as not set. |\n| `ItemNrInt` | varchar(50) | No | Internal item number (`ItemNrInt`). An empty string is treated as not set. |\n\n- All tables are read with `NOLOCK`; uncommitted data may appear.\n- Because the identifiers are combined with OR, passing several identifiers that belong to different Artikel returns the lines of all of them. The result contains no item column, so the rows cannot be assigned to an item afterwards. Pass only one identifier to get unambiguous results.\n- `SupplierOrderQty` is the quantity of the supplier order line as stored; the code does not subtract quantities that have already been received.\n- `EstimatedDelivery` is converted to `datetime` and is empty if the line has no estimated delivery date.\n\nDocumentation: https://pixi-api-docs.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": "Returns the supplier assignments of items (supplier item number, EAN, purchase price, minimum order quantity, delivery times), filtered by item or supplier.\n\nReads the item/supplier assignments from `AddItems` joined with the master data in `Suppliers`. Only assignments whose supplier exists in `Suppliers` are returned.\n\n**Parameter normalisation**\n- `ItemKey` = `0` and empty strings for `EAN`, `ItemNrSuppl`, `ItemNrInt` and `SupplNr` count as *not set*.\n\n**Validation**\n1. At least one of `ItemKey`, `EAN`, `ItemNrSuppl`, `ItemNrInt` or `SupplNr` must be set. `OnlyActiveSuppliers` alone is not enough. Otherwise an error row is returned.\n2. If `SupplNr` is set, the supplier must exist. Otherwise an error row is returned.\n\n**Filter logic**\n- The item filters `ItemKey`, `EAN`, `ItemNrSuppl` and `ItemNrInt` are combined with **OR**. A row matches if any of the given values matches. Each filter is compared with its column in `AddItems`: `ItemRef`, `EANUPC`, `ItemNrSuppl` and `ItemNrInt`.\n- `SupplNr` is combined with **AND**. It restricts the result to this one supplier.\n- If only `SupplNr` is given, all items assigned to that supplier are returned.\n- If `OnlyActiveSuppliers` = `1`, only rows are returned where the supplier is not disabled and the item/supplier assignment is active (`AddItems.Active` = `1`).\n\nNo sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal item key (`AddItems.ItemRef`). `0` counts as not set. |\n| `EAN` | varchar(13) | No | EAN/UPC of the supplier assignment (`AddItems.EANUPC`). An empty string counts as not set. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier's item number (`AddItems.ItemNrSuppl`). An empty string counts as not set. |\n| `ItemNrInt` | varchar(50) | No | Internal item number (`AddItems.ItemNrInt`). An empty string counts as not set. |\n| `OnlyActiveSuppliers` | bit | No | If `1`, only assignments are returned whose supplier is not disabled and whose assignment is active. |\n| `SupplNr` | varchar(4) | No | Supplier number. Restricts the result to this supplier and must exist in `Suppliers`. An empty string counts as not set. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- `EAN` is compared with the supplier-specific EAN `AddItems.EANUPC`, not with any other EAN field of the item.\n- Errors are not raised as SQL errors. They come back as a normal row with the columns `Error` and `ErrorMsg`. Check for the column `Error` before you read the data columns.\n- If several item filters are given, the result is the union of all matches, not their intersection.\n- Calling the procedure with only `SupplNr` can return a large result set for suppliers with many items. No paging is available.\n\nDocumentation: https://pixi-api-docs.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": "Returns the supplier assignments of items (supplier item number, EAN, purchase price, minimum order quantity, delivery times), filtered by item or supplier.\n\nReads the item/supplier assignments from `AddItems` joined with the master data in `Suppliers`. Only assignments whose supplier exists in `Suppliers` are returned.\n\n**Parameter normalisation**\n- `ItemKey` = `0` and empty strings for `EAN`, `ItemNrSuppl`, `ItemNrInt` and `SupplNr` count as *not set*.\n\n**Validation**\n1. At least one of `ItemKey`, `EAN`, `ItemNrSuppl`, `ItemNrInt` or `SupplNr` must be set. `OnlyActiveSuppliers` alone is not enough. Otherwise an error row is returned.\n2. If `SupplNr` is set, the supplier must exist. Otherwise an error row is returned.\n\n**Filter logic**\n- The item filters `ItemKey`, `EAN`, `ItemNrSuppl` and `ItemNrInt` are combined with **OR**. A row matches if any of the given values matches. Each filter is compared with its column in `AddItems`: `ItemRef`, `EANUPC`, `ItemNrSuppl` and `ItemNrInt`.\n- `SupplNr` is combined with **AND**. It restricts the result to this one supplier.\n- If only `SupplNr` is given, all items assigned to that supplier are returned.\n- If `OnlyActiveSuppliers` = `1`, only rows are returned where the supplier is not disabled and the item/supplier assignment is active (`AddItems.Active` = `1`).\n\nNo sort order is defined.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal item key (`AddItems.ItemRef`). `0` counts as not set. |\n| `EAN` | varchar(13) | No | EAN/UPC of the supplier assignment (`AddItems.EANUPC`). An empty string counts as not set. |\n| `ItemNrSuppl` | varchar(50) | No | Supplier's item number (`AddItems.ItemNrSuppl`). An empty string counts as not set. |\n| `ItemNrInt` | varchar(50) | No | Internal item number (`AddItems.ItemNrInt`). An empty string counts as not set. |\n| `OnlyActiveSuppliers` | bit | No | If `1`, only assignments are returned whose supplier is not disabled and whose assignment is active. |\n| `SupplNr` | varchar(4) | No | Supplier number. Restricts the result to this supplier and must exist in `Suppliers`. An empty string counts as not set. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- `EAN` is compared with the supplier-specific EAN `AddItems.EANUPC`, not with any other EAN field of the item.\n- Errors are not raised as SQL errors. They come back as a normal row with the columns `Error` and `ErrorMsg`. Check for the column `Error` before you read the data columns.\n- If several item filters are given, the result is the union of all matches, not their intersection.\n- Calling the procedure with only `SupplNr` can return a large result set for suppliers with many items. No paging is available.\n\nDocumentation: https://pixi-api-docs.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": "Returns the supplier order lines that are matched to one item line of a supplier delivery document, with ordered, received, open and matched quantities.\n\nReturns the matches (`BuyingMatch` records) between one line of a supplier delivery document and the supplier order lines it was booked against.\n\n- Only matches whose delivery reference equals `SDelDkey` are considered.\n- Each match is joined to its supplier order line and the supplier order. Matches without an existing order line or order are not returned.\n- The rows are grouped by order date and supplier order line, so there is one row per matched order line:\n - `OrderNr` is the internal number of the supplier order, `OrderId` its ID.\n - `OrderQty`, `QtyReceived` and `QtyNotDelivered` come from the order line (`QtyNotDelivered` is `0` if no value is stored).\n - `BuyingMatchQty` is the sum of all matched quantities of this delivery line for the order line.\n - `SupplName` is the name of the supplier taken from the supplier number stored on the match.\n\nThe call is a wrapper: it runs the internal procedure `Pixi_Buy_GetMatchesForDeliveredItem`, buffers its rows in a temporary table and returns them.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelDkey` | int | No | Key of the supplier delivery document line (item line) whose matches to supplier order lines are returned. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- If `SDelDkey` is omitted (default `NULL`), no rows are returned because the filter compares with `=`.\n- The internal procedure sorts by order date and ordered quantity, but the wrapper selects from its temporary table without `ORDER BY`. The row order is therefore not guaranteed; sort on the client if needed.\n- All quantity columns are stored as `int` in the buffer table; decimal quantities would be truncated.\n\nDocumentation: https://pixi-api-docs.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": "Returns the supplier order lines that are matched to one item line of a supplier delivery document, with ordered, received, open and matched quantities.\n\nReturns the matches (`BuyingMatch` records) between one line of a supplier delivery document and the supplier order lines it was booked against.\n\n- Only matches whose delivery reference equals `SDelDkey` are considered.\n- Each match is joined to its supplier order line and the supplier order. Matches without an existing order line or order are not returned.\n- The rows are grouped by order date and supplier order line, so there is one row per matched order line:\n - `OrderNr` is the internal number of the supplier order, `OrderId` its ID.\n - `OrderQty`, `QtyReceived` and `QtyNotDelivered` come from the order line (`QtyNotDelivered` is `0` if no value is stored).\n - `BuyingMatchQty` is the sum of all matched quantities of this delivery line for the order line.\n - `SupplName` is the name of the supplier taken from the supplier number stored on the match.\n\nThe call is a wrapper: it runs the internal procedure `Pixi_Buy_GetMatchesForDeliveredItem`, buffers its rows in a temporary table and returns them.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelDkey` | int | No | Key of the supplier delivery document line (item line) whose matches to supplier order lines are returned. |\n\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- If `SDelDkey` is omitted (default `NULL`), no rows are returned because the filter compares with `=`.\n- The internal procedure sorts by order date and ordered quantity, but the wrapper selects from its temporary table without `ORDER BY`. The row order is therefore not guaranteed; sort on the client if needed.\n- All quantity columns are stored as `int` in the buffer table; decimal quantities would be truncated.\n\nDocumentation: https://pixi-api-docs.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": "Returns the lines of a supplier order with item, price, delivery and stock data plus customer demand and sales figures per item.\n\nReturns all lines of the supplier order whose ID is passed in `SOrderRef`. Internally the call runs `Pixi_GetSorderlines` with all optional fields enabled, buffers the rows in a temporary table and returns them unchanged.\n\nFor each line the result contains:\n\n- **Line data**: item name, ordered quantity, status code of the supplier order, comment, estimated delivery date, creator and last editor with timestamps.\n- **Item data**: EAN (`ArtNr`), supplier item number and internal item number from the supplier-specific item data of the order's supplier, sales price (`VKPrice`), order unit, VAT percentage valid at the line's creation date.\n- **Purchase prices**: `EKprice` is the supplier price stored on the line. If the order status is flagged as *new* and the line price is 0 or empty, the supplier price from the supplier-specific item data is used instead. `EKValue` is quantity × `EKprice`. `FinalPrice` is supplier price × quantity minus the line discount.\n- **Delivery data**: delivered and undelivered quantity of the line and the total received quantity summed over all delivery details (`TotalQtyReceived`).\n- **Stock and demand at the delivery location** of the order: location stock, minimum order and minimum stock quantity, quantity in customer order lines with status `HAL` (`Hal_Cust_O`) or `ANG`, `BES`, `BOR` (`Open_Cust_O`), quantity in other open, ordered/confirmed supplier orders (`Open_Suppl_O`), and sold quantities of the last 30, 120 and 365 days (`L30`, `L120`, `L365`, all customer order lines except status `STO`).\n\nIf `OpenOrderlines` = 1, only lines are returned whose ordered quantity is greater than delivered plus undelivered quantity. Lines are produced in order of the line ID.\n\nOnly lines are returned for which the item, the item's location-specific record at the order's delivery location, the supplier and both the creating and modifying user exist (inner joins).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SOrderRef` | int | No | ID of the supplier order whose lines are returned. NULL is treated as 0. |\n| `LocID` | char(3) | No | Location ID. Passed on internally but has no effect on the result; location figures always refer to the order's delivery location. |\n| `OpenOrderlines` | bit | No | Restricts the result to lines that are not yet fully delivered. NULL is treated as 0. |\n\n- `LocID` is passed to the inner procedure but not used in the query. Location-related figures always refer to the delivery location of the supplier order, regardless of `LocID`.\n- If the setting `Include_FUT_StatusInOpenOrdersForSupplierOrdering` is `1`, customer order lines with status `FUT` are also counted in `Open_Cust_O`.\n- All reads use `NOLOCK`, so figures may include uncommitted data.\n- The query is built as dynamic SQL; the many correlated subqueries (sales of 30/120/365 days, open orders) can make the call slow for large orders.\n- Fixed values: `Detail`, `Detail2` and `Price` are always 0, `ReceiveDate` is always empty. `StockQty` equals `SummaryQuantity`.\n- `SOrderlineNr` actually contains the ID of the supplier order (same as `SOrderRef`), not a line number. Use `SOrderlineKey` to identify a line.\n- The ordering by line ID is applied in the inner query; the final select from the temporary table has no explicit `ORDER BY`.\n- Several columns of the internal temporary table are declared `NOT NULL` (e.g. `VKPrice`, `FinalPrice`). If the source data contains NULL there (e.g. a line without supplier price), the insert may fail with an SQL error.\n- If `SOrderRef` is left out (default 0), no rows are returned.\n\nDocumentation: https://pixi-api-docs.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": "Returns the lines of a supplier order with item, price, delivery and stock data plus customer demand and sales figures per item.\n\nReturns all lines of the supplier order whose ID is passed in `SOrderRef`. Internally the call runs `Pixi_GetSorderlines` with all optional fields enabled, buffers the rows in a temporary table and returns them unchanged.\n\nFor each line the result contains:\n\n- **Line data**: item name, ordered quantity, status code of the supplier order, comment, estimated delivery date, creator and last editor with timestamps.\n- **Item data**: EAN (`ArtNr`), supplier item number and internal item number from the supplier-specific item data of the order's supplier, sales price (`VKPrice`), order unit, VAT percentage valid at the line's creation date.\n- **Purchase prices**: `EKprice` is the supplier price stored on the line. If the order status is flagged as *new* and the line price is 0 or empty, the supplier price from the supplier-specific item data is used instead. `EKValue` is quantity × `EKprice`. `FinalPrice` is supplier price × quantity minus the line discount.\n- **Delivery data**: delivered and undelivered quantity of the line and the total received quantity summed over all delivery details (`TotalQtyReceived`).\n- **Stock and demand at the delivery location** of the order: location stock, minimum order and minimum stock quantity, quantity in customer order lines with status `HAL` (`Hal_Cust_O`) or `ANG`, `BES`, `BOR` (`Open_Cust_O`), quantity in other open, ordered/confirmed supplier orders (`Open_Suppl_O`), and sold quantities of the last 30, 120 and 365 days (`L30`, `L120`, `L365`, all customer order lines except status `STO`).\n\nIf `OpenOrderlines` = 1, only lines are returned whose ordered quantity is greater than delivered plus undelivered quantity. Lines are produced in order of the line ID.\n\nOnly lines are returned for which the item, the item's location-specific record at the order's delivery location, the supplier and both the creating and modifying user exist (inner joins).\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SOrderRef` | int | No | ID of the supplier order whose lines are returned. NULL is treated as 0. |\n| `LocID` | char(3) | No | Location ID. Passed on internally but has no effect on the result; location figures always refer to the order's delivery location. |\n| `OpenOrderlines` | bit | No | Restricts the result to lines that are not yet fully delivered. NULL is treated as 0. |\n\n- `LocID` is passed to the inner procedure but not used in the query. Location-related figures always refer to the delivery location of the supplier order, regardless of `LocID`.\n- If the setting `Include_FUT_StatusInOpenOrdersForSupplierOrdering` is `1`, customer order lines with status `FUT` are also counted in `Open_Cust_O`.\n- All reads use `NOLOCK`, so figures may include uncommitted data.\n- The query is built as dynamic SQL; the many correlated subqueries (sales of 30/120/365 days, open orders) can make the call slow for large orders.\n- Fixed values: `Detail`, `Detail2` and `Price` are always 0, `ReceiveDate` is always empty. `StockQty` equals `SummaryQuantity`.\n- `SOrderlineNr` actually contains the ID of the supplier order (same as `SOrderRef`), not a line number. Use `SOrderlineKey` to identify a line.\n- The ordering by line ID is applied in the inner query; the final select from the temporary table has no explicit `ORDER BY`.\n- Several columns of the internal temporary table are declared `NOT NULL` (e.g. `VKPrice`, `FinalPrice`). If the source data contains NULL there (e.g. a line without supplier price), the insert may fail with an SQL error.\n- If `SOrderRef` is left out (default 0), no rows are returned.\n\nDocumentation: https://pixi-api-docs.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": "Returns supplier orders (purchase orders) of one location, filtered by status, overdue/missing delivery dates, status change date and external order numbers.\n\nReturns supplier orders from `pixi.SupplierOrder` together with supplier, status, location, creating/modifying user and the related goods receipts. The statement is built as dynamic SQL and executed with `sp_executesql`.\n\n**Filters**\n- Only orders whose delivery location has `LocID` = `LocationID` (default `001`).\n- At most `RLimit` rows are returned (`TOP (@RLimit)`). The default `0` returns **no rows**, so a positive value must be passed.\n- **Status filter:**\n - If `ShowDueDate` and `ShowNoDate` are both `0`, the flags are combined with OR: `ShowNew` → status flag `IsNew`, `ShowOrd` → `IsOrdered`, `ShowCon` → `IsConfirmed`, `ShowCls` → `IsClosed`.\n - If `ShowNoDate` = `1`, only ordered orders (`IsOrdered`) with at least one order line without an estimated delivery date are returned. This takes precedence over `ShowDueDate`.\n - If `ShowDueDate` = `1` (and `ShowNoDate` = `0`), only ordered orders with at least one line whose estimated delivery date is earlier than now are returned.\n - In both date modes the flags `ShowNew`, `ShowOrd`, `ShowCon` and `ShowCls` are ignored.\n - If all six flags are `0`, no status filter is applied.\n- **Status change date:** if `StatusChangeDateFrom` and/or `StatusChangeDateTo` is set, only orders whose latest audit entry in `hist.pixi_SupplierOrder` (`MAX(AuditDate)`) lies in the range `>= From` and `< To` are returned.\n- **External order numbers:** if `ExtOrderNrs` is set (an XML list), only orders whose `ExternalCode` matches one of the listed numbers are returned.\n\n**Goods receipts**\nFor each goods receipt in `SDelHeader`, the field `SDelHextOrderNr` is split at `;`. Numeric parts are matched to the order's `InternalNumber`. The goods receipt numbers (`SDelHNr`) are returned in `GoodsReceipts` as a list separated by `; `.\n\nRows are sorted by `OrderDate` descending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocationID` | varchar(3) | No | Location code (`LocID`) of the delivery location. Only orders for this location are returned. |\n| `RLimit` | int | No | Maximum number of rows (`TOP`). `0` returns no rows, so a positive value must be passed. |\n| `ShowNew` | bit | No | Include orders with a new status (`IsNew`). Only used if `ShowDueDate` and `ShowNoDate` are `0`. |\n| `ShowOrd` | bit | No | Include ordered orders (`IsOrdered`, status BES). Only used if `ShowDueDate` and `ShowNoDate` are `0`. |\n| `ShowCon` | bit | No | Include confirmed orders (`IsConfirmed`, status CON). Only used if `ShowDueDate` and `ShowNoDate` are `0`. |\n| `ShowCls` | bit | No | Include closed orders (`IsClosed`, status CLS). Only used if `ShowDueDate` and `ShowNoDate` are `0`. |\n| `ShowDueDate` | bit | No | If `1` (and `ShowNoDate` = `0`): only ordered orders with at least one line whose estimated delivery date is in the past. |\n| `ShowNoDate` | bit | No | If `1`: only ordered orders with at least one line without an estimated delivery date. Takes precedence over `ShowDueDate`. |\n| `StatusChangeDateFrom` | datetime | No | Lower bound (inclusive) for the latest change in the order history. Passed alone, it returns no rows (see notes). |\n| `StatusChangeDateTo` | datetime | No | Upper bound (exclusive) for the latest change in the order history. |\n| `ExtOrderNrs` | varchar(max) | No | Optional XML list of external order numbers. Only orders whose `ExternalCode` matches are returned. |\n\n- **Pitfall `RLimit`:** the default `0` leads to `TOP (0)` and an empty result. There is no \"unlimited\" value.\n- **Pitfall status change date:** if only `StatusChangeDateFrom` is passed, the upper bound falls back to `MAX(AuditDate)`. The condition `MAX(AuditDate) < MAX(AuditDate)` is never true, so no orders are returned. Pass `StatusChangeDateTo` as well, or only `StatusChangeDateTo`. The upper bound is exclusive.\n- `NULL` values for the flags, `LocationID` and `RLimit` are replaced by their defaults. An empty or whitespace-only `ExtOrderNrs` is treated as `NULL`.\n- `ExtOrderNrs` is parsed element-centric with `OPENXML` at path `/ExtOrders/ExtOrder`, reading the child element `ExtOrderNr`. The XML document is not released with `sp_xml_removedocument`.\n- All tables are read with `NOLOCK`, so uncommitted data can appear.\n- Orders are joined with `INNER JOIN` to supplier, status, location and to `ucs_users` for both the creating and the modifying user. Orders without a matching record are not returned.\n- `GoodsReceipts` is built with a `varchar(100)` conversion, so long lists are truncated. The goods receipt list is computed over the whole `SDelHeader` table on every call, which can be slow on large databases.\n- `RecordBatchNr` and `PixiOrderCreated` are always `NULL`. They are kept for compatibility.\n\nDocumentation: https://pixi-api-docs.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": "Returns supplier orders (purchase orders) of one location, filtered by status, overdue/missing delivery dates, status change date and external order numbers.\n\nReturns supplier orders from `pixi.SupplierOrder` together with supplier, status, location, creating/modifying user and the related goods receipts. The statement is built as dynamic SQL and executed with `sp_executesql`.\n\n**Filters**\n- Only orders whose delivery location has `LocID` = `LocationID` (default `001`).\n- At most `RLimit` rows are returned (`TOP (@RLimit)`). The default `0` returns **no rows**, so a positive value must be passed.\n- **Status filter:**\n - If `ShowDueDate` and `ShowNoDate` are both `0`, the flags are combined with OR: `ShowNew` → status flag `IsNew`, `ShowOrd` → `IsOrdered`, `ShowCon` → `IsConfirmed`, `ShowCls` → `IsClosed`.\n - If `ShowNoDate` = `1`, only ordered orders (`IsOrdered`) with at least one order line without an estimated delivery date are returned. This takes precedence over `ShowDueDate`.\n - If `ShowDueDate` = `1` (and `ShowNoDate` = `0`), only ordered orders with at least one line whose estimated delivery date is earlier than now are returned.\n - In both date modes the flags `ShowNew`, `ShowOrd`, `ShowCon` and `ShowCls` are ignored.\n - If all six flags are `0`, no status filter is applied.\n- **Status change date:** if `StatusChangeDateFrom` and/or `StatusChangeDateTo` is set, only orders whose latest audit entry in `hist.pixi_SupplierOrder` (`MAX(AuditDate)`) lies in the range `>= From` and `< To` are returned.\n- **External order numbers:** if `ExtOrderNrs` is set (an XML list), only orders whose `ExternalCode` matches one of the listed numbers are returned.\n\n**Goods receipts**\nFor each goods receipt in `SDelHeader`, the field `SDelHextOrderNr` is split at `;`. Numeric parts are matched to the order's `InternalNumber`. The goods receipt numbers (`SDelHNr`) are returned in `GoodsReceipts` as a list separated by `; `.\n\nRows are sorted by `OrderDate` descending.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `LocationID` | varchar(3) | No | Location code (`LocID`) of the delivery location. Only orders for this location are returned. |\n| `RLimit` | int | No | Maximum number of rows (`TOP`). `0` returns no rows, so a positive value must be passed. |\n| `ShowNew` | bit | No | Include orders with a new status (`IsNew`). Only used if `ShowDueDate` and `ShowNoDate` are `0`. |\n| `ShowOrd` | bit | No | Include ordered orders (`IsOrdered`, status BES). Only used if `ShowDueDate` and `ShowNoDate` are `0`. |\n| `ShowCon` | bit | No | Include confirmed orders (`IsConfirmed`, status CON). Only used if `ShowDueDate` and `ShowNoDate` are `0`. |\n| `ShowCls` | bit | No | Include closed orders (`IsClosed`, status CLS). Only used if `ShowDueDate` and `ShowNoDate` are `0`. |\n| `ShowDueDate` | bit | No | If `1` (and `ShowNoDate` = `0`): only ordered orders with at least one line whose estimated delivery date is in the past. |\n| `ShowNoDate` | bit | No | If `1`: only ordered orders with at least one line without an estimated delivery date. Takes precedence over `ShowDueDate`. |\n| `StatusChangeDateFrom` | datetime | No | Lower bound (inclusive) for the latest change in the order history. Passed alone, it returns no rows (see notes). |\n| `StatusChangeDateTo` | datetime | No | Upper bound (exclusive) for the latest change in the order history. |\n| `ExtOrderNrs` | varchar(max) | No | Optional XML list of external order numbers. Only orders whose `ExternalCode` matches are returned. |\n\n- **Pitfall `RLimit`:** the default `0` leads to `TOP (0)` and an empty result. There is no \"unlimited\" value.\n- **Pitfall status change date:** if only `StatusChangeDateFrom` is passed, the upper bound falls back to `MAX(AuditDate)`. The condition `MAX(AuditDate) < MAX(AuditDate)` is never true, so no orders are returned. Pass `StatusChangeDateTo` as well, or only `StatusChangeDateTo`. The upper bound is exclusive.\n- `NULL` values for the flags, `LocationID` and `RLimit` are replaced by their defaults. An empty or whitespace-only `ExtOrderNrs` is treated as `NULL`.\n- `ExtOrderNrs` is parsed element-centric with `OPENXML` at path `/ExtOrders/ExtOrder`, reading the child element `ExtOrderNr`. The XML document is not released with `sp_xml_removedocument`.\n- All tables are read with `NOLOCK`, so uncommitted data can appear.\n- Orders are joined with `INNER JOIN` to supplier, status, location and to `ucs_users` for both the creating and the modifying user. Orders without a matching record are not returned.\n- `GoodsReceipts` is built with a `varchar(100)` conversion, so long lists are truncated. The goods receipt list is computed over the whole `SDelHeader` table on every call, which can be slow on large databases.\n- `RecordBatchNr` and `PixiOrderCreated` are always `NULL`. They are kept for compatibility.\n\nDocumentation: https://pixi-api-docs.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": "Returns confirmed supplier orders of one supplier for a delivery location, or the list of suppliers with such orders, as a basis for delivery templates.\n\nThe call forwards both parameters to the internal procedure `Pixi_GetSOrdersBySupplier`. It helps select supplier orders from which a delivery template (supplier delivery) can be created.\n\n**Pre-filter:** Supplier orders that already have at least one order line referenced by a supplier delivery in status `NEW` (`SDelHeader.SDelHStatus = 'NEW'`) are excluded in both modes.\n\n**Status filter:** Only orders whose status has `IsConfirmed = 1` are considered. If the setting `ConfirmOrderedDocumentOnDelivery` is `1`, orders whose status has `IsOrderedConfirmed = 1` are included as well.\n\n**Location filter:** The delivery location of the order (`DeliveryLocationId`) must match `LocID`.\n\n**Mode depends on `SupplNr`:**\n- `SupplNr` is set: returns the matching orders of this supplier (`OrderNr`, `ExternalCode`, `Code`, `OrderDate`), sorted by internal order number descending. The status code `BES` is returned as `ORD`.\n- `SupplNr` is `NULL`: returns the distinct suppliers (`SupplNr`, `SupplName`) that have at least one matching order at the location.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Yes | Supplier number. If set, the orders of this supplier are returned; if NULL, the list of suppliers with matching orders is returned. |\n| `LocID` | varchar(3) | Yes | Location ID of the delivery location of the supplier orders. |\n\n- Both parameters have no default in this wrapper, so they must be sent. The supplier-list mode is only reached if `SupplNr` is explicitly passed as NULL; an empty string is not NULL and returns no orders.\n- If `LocID` is NULL, no rows are returned, because the comparison `lo.LocID = @LocID` never matches NULL.\n- The wrapper does not pass `@LanguageID`, so the inner procedure always uses `1`: `BES` becomes `ORD`; the translation of `CON` to `BGT` (language 2) never applies.\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- The setting `ConfirmOrderedDocumentOnDelivery` is read at runtime via `fpixi_GetSetting`.\n\nDocumentation: https://pixi-api-docs.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": "Returns confirmed supplier orders of one supplier for a delivery location, or the list of suppliers with such orders, as a basis for delivery templates.\n\nThe call forwards both parameters to the internal procedure `Pixi_GetSOrdersBySupplier`. It helps select supplier orders from which a delivery template (supplier delivery) can be created.\n\n**Pre-filter:** Supplier orders that already have at least one order line referenced by a supplier delivery in status `NEW` (`SDelHeader.SDelHStatus = 'NEW'`) are excluded in both modes.\n\n**Status filter:** Only orders whose status has `IsConfirmed = 1` are considered. If the setting `ConfirmOrderedDocumentOnDelivery` is `1`, orders whose status has `IsOrderedConfirmed = 1` are included as well.\n\n**Location filter:** The delivery location of the order (`DeliveryLocationId`) must match `LocID`.\n\n**Mode depends on `SupplNr`:**\n- `SupplNr` is set: returns the matching orders of this supplier (`OrderNr`, `ExternalCode`, `Code`, `OrderDate`), sorted by internal order number descending. The status code `BES` is returned as `ORD`.\n- `SupplNr` is `NULL`: returns the distinct suppliers (`SupplNr`, `SupplName`) that have at least one matching order at the location.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | Yes | Supplier number. If set, the orders of this supplier are returned; if NULL, the list of suppliers with matching orders is returned. |\n| `LocID` | varchar(3) | Yes | Location ID of the delivery location of the supplier orders. |\n\n- Both parameters have no default in this wrapper, so they must be sent. The supplier-list mode is only reached if `SupplNr` is explicitly passed as NULL; an empty string is not NULL and returns no orders.\n- If `LocID` is NULL, no rows are returned, because the comparison `lo.LocID = @LocID` never matches NULL.\n- The wrapper does not pass `@LanguageID`, so the inner procedure always uses `1`: `BES` becomes `ORD`; the translation of `CON` to `BGT` (language 2) never applies.\n- All reads use `NOLOCK`, so uncommitted data may be returned.\n- The setting `ConfirmOrderedDocumentOnDelivery` is read at runtime via `fpixi_GetSetting`.\n\nDocumentation: https://pixi-api-docs.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": "Returns supplier orders line by line, optionally filtered by supplier, order number, date range and status, with simple row-based paging.\n\nReturns one row per **supplier order line**, together with header data of the supplier order, the supplier, the item, the delivery location and the users who created and last modified the records.\n\n**Filters** (all combined with AND):\n- `SupplNr`: only orders of this supplier. Empty string counts as not set.\n- `SupplOrderNr`: only the order with this internal number (`InternalNumber`). `0` counts as not set.\n- `Status`: only orders whose status code matches, e.g. `NEW`, `CLS`, `BES`, `CON`. Empty string counts as not set.\n- `DateFrom` / `DateTo`: the order date is compared; if an order has no order date, its creation date is used instead.\n - `DateFrom` is rounded down to the start of the day. If it is missing or before 1970-01-01, 1970-01-01 00:00 is used.\n - `DateTo` is extended to the end of the day (23:59:59.997). If it is missing or before 1970-01-01, the current date and time is used.\n\n**Paging**: the rows are numbered by `RowNr` in ascending order of the internal supplier order ID. Only rows with `RowNr` greater than `Start` are returned, at most `RowCount` rows. To fetch the next page, increase `Start` by `RowCount`.\n\n**Calculated columns**:\n- `OrderQty` is the still open quantity: ordered quantity minus undelivered quantity minus delivered quantity.\n- `SupplPrice` is the price of the order line; if it is 0 or empty, the supplier price from the additional supplier data of the item for this supplier is used, otherwise the supplier price of the item master record.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | No | Supplier number. Only orders of this supplier are returned. NULL or empty string: all suppliers. |\n| `SupplOrderNr` | int | No | Internal supplier order number. NULL or 0: all orders. |\n| `DateFrom` | datetime | No | Start of the date range (order date, or creation date if no order date). Rounded down to the start of the day; NULL or before 1970-01-01 means 1970-01-01. |\n| `DateTo` | datetime | No | End of the date range. Extended to the end of the given day; NULL or before 1970-01-01 means the current date and time. |\n| `Status` | varchar(3) | No | Status code of the supplier order. NULL or empty string: all statuses. The code comment lists NEW, CLS, BES and CON. |\n| `RowCount` | int | No | Maximum number of rows (order lines) to return. |\n| `Start` | int | No | Paging offset: only rows with `RowNr` greater than this value are returned. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- Paging counts **order lines**, not orders: an order with several lines can be split across two pages.\n- `RowNr` is ordered only by the supplier order ID; lines of the same order get numbers in no defined order, and the final result has no `ORDER BY`. Paging across lines of one order is therefore not strictly deterministic.\n- All joins are inner joins: orders without lines, and orders or lines whose type, status, delivery location, supplier, item or creating/modifying user cannot be resolved, are not returned.\n- If `DateTo` is omitted, the current time (not the end of the day) is the upper bound.\n- The column name `SupplierOrderLineUpateUser` contains a typo (`Upate`) and must be read exactly like that.\n- `SupplierOrderlineKey` and `SupplierOrderlineId` contain the same value, as do `SupplierOrderNRExternal` and `ExtOrderNr`.\n- The fallback price from the additional supplier data is taken with `TOP 1` without sort order; if several entries exist for item and supplier, the chosen one is not defined.\n- The status values `NEW`, `CLS`, `BES`, `CON` are only listed in a code comment; the actual codes come from the supplier order status table.\n\nDocumentation: https://pixi-api-docs.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": "Returns supplier orders line by line, optionally filtered by supplier, order number, date range and status, with simple row-based paging.\n\nReturns one row per **supplier order line**, together with header data of the supplier order, the supplier, the item, the delivery location and the users who created and last modified the records.\n\n**Filters** (all combined with AND):\n- `SupplNr`: only orders of this supplier. Empty string counts as not set.\n- `SupplOrderNr`: only the order with this internal number (`InternalNumber`). `0` counts as not set.\n- `Status`: only orders whose status code matches, e.g. `NEW`, `CLS`, `BES`, `CON`. Empty string counts as not set.\n- `DateFrom` / `DateTo`: the order date is compared; if an order has no order date, its creation date is used instead.\n - `DateFrom` is rounded down to the start of the day. If it is missing or before 1970-01-01, 1970-01-01 00:00 is used.\n - `DateTo` is extended to the end of the day (23:59:59.997). If it is missing or before 1970-01-01, the current date and time is used.\n\n**Paging**: the rows are numbered by `RowNr` in ascending order of the internal supplier order ID. Only rows with `RowNr` greater than `Start` are returned, at most `RowCount` rows. To fetch the next page, increase `Start` by `RowCount`.\n\n**Calculated columns**:\n- `OrderQty` is the still open quantity: ordered quantity minus undelivered quantity minus delivered quantity.\n- `SupplPrice` is the price of the order line; if it is 0 or empty, the supplier price from the additional supplier data of the item for this supplier is used, otherwise the supplier price of the item master record.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | No | Supplier number. Only orders of this supplier are returned. NULL or empty string: all suppliers. |\n| `SupplOrderNr` | int | No | Internal supplier order number. NULL or 0: all orders. |\n| `DateFrom` | datetime | No | Start of the date range (order date, or creation date if no order date). Rounded down to the start of the day; NULL or before 1970-01-01 means 1970-01-01. |\n| `DateTo` | datetime | No | End of the date range. Extended to the end of the given day; NULL or before 1970-01-01 means the current date and time. |\n| `Status` | varchar(3) | No | Status code of the supplier order. NULL or empty string: all statuses. The code comment lists NEW, CLS, BES and CON. |\n| `RowCount` | int | No | Maximum number of rows (order lines) to return. |\n| `Start` | int | No | Paging offset: only rows with `RowNr` greater than this value are returned. |\n\n- All tables are read with `NOLOCK`, so uncommitted data may be returned.\n- Paging counts **order lines**, not orders: an order with several lines can be split across two pages.\n- `RowNr` is ordered only by the supplier order ID; lines of the same order get numbers in no defined order, and the final result has no `ORDER BY`. Paging across lines of one order is therefore not strictly deterministic.\n- All joins are inner joins: orders without lines, and orders or lines whose type, status, delivery location, supplier, item or creating/modifying user cannot be resolved, are not returned.\n- If `DateTo` is omitted, the current time (not the end of the day) is the upper bound.\n- The column name `SupplierOrderLineUpateUser` contains a typo (`Upate`) and must be read exactly like that.\n- `SupplierOrderlineKey` and `SupplierOrderlineId` contain the same value, as do `SupplierOrderNRExternal` and `ExtOrderNr`.\n- The fallback price from the additional supplier data is taken with `TOP 1` without sort order; if several entries exist for item and supplier, the chosen one is not defined.\n- The status values `NEW`, `CLS`, `BES`, `CON` are only listed in a code comment; the actual codes come from the supplier order status table.\n\nDocumentation: https://pixi-api-docs.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": "Returns supplier master data including the main contact person, optionally limited to active suppliers or to one supplier number.\n\nReads the supplier master records from `Suppliers`. Each supplier is joined with its main contact in `pixi.Contact` via `ContactId`.\n\nFiltering:\n\n- An empty `SupplNr` is treated like `NULL`.\n- If `SupplNr` is set, only the supplier with this number is returned. It is returned **regardless of its active state**, so `OnlyActive` has no effect in this case.\n- If `SupplNr` is not set and `OnlyActive` is `0`, all suppliers are returned, including inactive ones.\n- If `SupplNr` is not set and `OnlyActive` has any other value (default `1`), only suppliers with `Disabled = 0` are returned.\n\nThe result is sorted by `SupplName`.\n\nThe main contact fields (`MainContact_*`) are returned as empty strings if the supplier has no contact or the contact field is empty. The column `SupplierIsInactive` contains the `Disabled` flag of the supplier.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OnlyActive` | int | No | `0` returns all suppliers including inactive ones; any other value returns only active suppliers. Ignored if `SupplNr` is set. |\n| `SupplNr` | varchar(4) | No | Supplier number. If set, only this supplier is returned, even if it is inactive. Empty string or `NULL` returns all suppliers matching `OnlyActive`. |\n\n- Both tables are read with `NOLOCK`, so uncommitted changes may be visible.\n- Any non-zero value of `OnlyActive` acts like `1`. With this filter, suppliers whose `Disabled` value is `NULL` are not returned.\n- Some columns are renamed compared to the table: `SupplFaxNr` → `SupplFaxNR`, `CustNr` → `CustNR`, `MailBox` → `eMail`, `Disabled` → `SupplierIsInactive`, `SupplComment` → `SupplierComment`.\n- The column types are not visible in the code; they are taken from the `Suppliers` and `pixi.Contact` tables.\n\nDocumentation: https://pixi-api-docs.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": "Returns supplier master data including the main contact person, optionally limited to active suppliers or to one supplier number.\n\nReads the supplier master records from `Suppliers`. Each supplier is joined with its main contact in `pixi.Contact` via `ContactId`.\n\nFiltering:\n\n- An empty `SupplNr` is treated like `NULL`.\n- If `SupplNr` is set, only the supplier with this number is returned. It is returned **regardless of its active state**, so `OnlyActive` has no effect in this case.\n- If `SupplNr` is not set and `OnlyActive` is `0`, all suppliers are returned, including inactive ones.\n- If `SupplNr` is not set and `OnlyActive` has any other value (default `1`), only suppliers with `Disabled = 0` are returned.\n\nThe result is sorted by `SupplName`.\n\nThe main contact fields (`MainContact_*`) are returned as empty strings if the supplier has no contact or the contact field is empty. The column `SupplierIsInactive` contains the `Disabled` flag of the supplier.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `OnlyActive` | int | No | `0` returns all suppliers including inactive ones; any other value returns only active suppliers. Ignored if `SupplNr` is set. |\n| `SupplNr` | varchar(4) | No | Supplier number. If set, only this supplier is returned, even if it is inactive. Empty string or `NULL` returns all suppliers matching `OnlyActive`. |\n\n- Both tables are read with `NOLOCK`, so uncommitted changes may be visible.\n- Any non-zero value of `OnlyActive` acts like `1`. With this filter, suppliers whose `Disabled` value is `NULL` are not returned.\n- Some columns are renamed compared to the table: `SupplFaxNr` → `SupplFaxNR`, `CustNr` → `CustNR`, `MailBox` → `eMail`, `Disabled` → `SupplierIsInactive`, `SupplComment` → `SupplierComment`.\n- The column types are not visible in the code; they are taken from the `Suppliers` and `pixi.Contact` tables.\n\nDocumentation: https://pixi-api-docs.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": "Returns supplier delivery headers from `SDelHeader`, paged by key and optionally filtered by creation and/or update date.\n\nReads delivery header records (supplier deliveries / goods receipts) from the table `SDelHeader`.\n\n**Preparation**\n- If `SDelHKey` is not passed, it is set to `0`.\n- If `RowCount` is NULL, it is set to `1000`.\n\n**Filter selection** – exactly one filter mode is applied, in this priority:\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: a record matches the lower bound if its creation date **or** its update date is `>=` the From value, and the upper bound if its creation date **or** its update date is `<` the To value.\n2. `CreateDateFrom` / `CreateDateTo`: filter on `SDelHCreateDate` (From inclusive, To exclusive).\n3. `UpdateDateFrom` / `UpdateDateTo`: filter on `SDelHUpdateDate` (From inclusive, To exclusive).\n4. No date parameter: all records.\n\nParameters of a lower-priority mode are ignored as soon as a higher-priority mode is used (e.g. `CreateDateFrom` is ignored if `CreateAndUpdateDateFrom` is set).\n\n**Paging**\nIn every mode only records with `SDelHKey` **greater than** `SDelHKey` are returned, at most `RowCount` rows, sorted by `SDelHKey` ascending. To read the next page, pass the highest `SDelHKey` of the previous page.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | No | Paging cursor: only delivery headers with a key greater than this value are returned. NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for `SDelHCreateDate`. Ignored if a CreateAndUpdate date is set. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for `SDelHCreateDate`. Ignored if a CreateAndUpdate date is set. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for `SDelHUpdateDate`. Only used if no CreateAndUpdate and no Create date is set. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for `SDelHUpdateDate`. Only used if no CreateAndUpdate and no Create date is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive): matches if creation date or update date is on or after this value. Has the highest priority among the date filters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (exclusive): matches if creation date or update date is before this value. Has the highest priority among the date filters. |\n| `RowCount` | int | No | Maximum number of rows returned. NULL is treated as 1000. |\n\n- `SDelHKey` is **not** an exact-match filter: passing a key returns the records *after* that key. The code contains a branch for an exact key lookup and an empty-result branch, but both are unreachable because `SDelHKey` and `RowCount` are never NULL after the initial defaults. To read one specific header, pass `SDelHKey` = key − 1 and `RowCount` = 1 and check the returned key.\n- The combined create/update filter uses OR on both bounds, so it is wider than a strict range: e.g. a record created before From but updated after To can still match both bounds.\n- The table is read with `NOLOCK`; uncommitted data may be returned.\n- A negative `RowCount` causes a SQL error in `TOP`; `0` returns no rows.\n- Column `SDelHfinalDicsount` is spelled this way in the database.\n\nDocumentation: https://pixi-api-docs.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": "Returns supplier delivery headers from `SDelHeader`, paged by key and optionally filtered by creation and/or update date.\n\nReads delivery header records (supplier deliveries / goods receipts) from the table `SDelHeader`.\n\n**Preparation**\n- If `SDelHKey` is not passed, it is set to `0`.\n- If `RowCount` is NULL, it is set to `1000`.\n\n**Filter selection** – exactly one filter mode is applied, in this priority:\n1. `CreateAndUpdateDateFrom` / `CreateAndUpdateDateTo`: a record matches the lower bound if its creation date **or** its update date is `>=` the From value, and the upper bound if its creation date **or** its update date is `<` the To value.\n2. `CreateDateFrom` / `CreateDateTo`: filter on `SDelHCreateDate` (From inclusive, To exclusive).\n3. `UpdateDateFrom` / `UpdateDateTo`: filter on `SDelHUpdateDate` (From inclusive, To exclusive).\n4. No date parameter: all records.\n\nParameters of a lower-priority mode are ignored as soon as a higher-priority mode is used (e.g. `CreateDateFrom` is ignored if `CreateAndUpdateDateFrom` is set).\n\n**Paging**\nIn every mode only records with `SDelHKey` **greater than** `SDelHKey` are returned, at most `RowCount` rows, sorted by `SDelHKey` ascending. To read the next page, pass the highest `SDelHKey` of the previous page.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | No | Paging cursor: only delivery headers with a key greater than this value are returned. NULL is treated as 0. |\n| `CreateDateFrom` | datetime | No | Lower bound (inclusive) for `SDelHCreateDate`. Ignored if a CreateAndUpdate date is set. |\n| `CreateDateTo` | datetime | No | Upper bound (exclusive) for `SDelHCreateDate`. Ignored if a CreateAndUpdate date is set. |\n| `UpdateDateFrom` | datetime | No | Lower bound (inclusive) for `SDelHUpdateDate`. Only used if no CreateAndUpdate and no Create date is set. |\n| `UpdateDateTo` | datetime | No | Upper bound (exclusive) for `SDelHUpdateDate`. Only used if no CreateAndUpdate and no Create date is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Lower bound (inclusive): matches if creation date or update date is on or after this value. Has the highest priority among the date filters. |\n| `CreateAndUpdateDateTo` | datetime | No | Upper bound (exclusive): matches if creation date or update date is before this value. Has the highest priority among the date filters. |\n| `RowCount` | int | No | Maximum number of rows returned. NULL is treated as 1000. |\n\n- `SDelHKey` is **not** an exact-match filter: passing a key returns the records *after* that key. The code contains a branch for an exact key lookup and an empty-result branch, but both are unreachable because `SDelHKey` and `RowCount` are never NULL after the initial defaults. To read one specific header, pass `SDelHKey` = key − 1 and `RowCount` = 1 and check the returned key.\n- The combined create/update filter uses OR on both bounds, so it is wider than a strict range: e.g. a record created before From but updated after To can still match both bounds.\n- The table is read with `NOLOCK`; uncommitted data may be returned.\n- A negative `RowCount` causes a SQL error in `TOP`; `0` returns no rows.\n- Column `SDelHfinalDicsount` is spelled this way in the database.\n\nDocumentation: https://pixi-api-docs.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": "Returns delivery item rows from SDelDetail, filtered by creation and/or update date and paged by key in ascending order.\n\nReads delivery item rows (table `SDelDetail`) and returns at most `@RowCount` rows, always sorted by `SDelDkey` ascending.\n\nPreparation:\n- If `SDelDkey` is NULL it is set to `0`.\n- If `RowCount` is NULL it is set to `1000`.\n\nOnly one filter mode is applied. The procedure checks the modes in this order and uses the first one that matches:\n1. **Create or update date**: `CreateAndUpdateDateFrom` and/or `CreateAndUpdateDateTo` is set. A row matches the lower bound if its creation date **or** its update date is `>=` the From value. It matches the upper bound if its creation date **or** its update date is `<` the To value.\n2. **Create date**: `CreateDateFrom` and/or `CreateDateTo` is set. The filter uses `SDelDcreateDate >= From` and `SDelDcreateDate < To`.\n3. **Update date**: `UpdateDateFrom` and/or `UpdateDateTo` is set. The filter uses `SDelDupdateDate >= From` and `SDelDupdateDate < To`.\n4. **Key range**: no date parameter is set. The call returns the next rows after `SDelDkey`.\n\nIn every mode only rows with `SDelDkey > @SDelDkey` are returned. To page through the data, pass the highest `SDelDkey` of the previous response as `SDelDkey` in the next call. Stop when fewer than `RowCount` rows come back.\n\nThe upper bounds of the date ranges are exclusive. Parameters of a lower-priority mode are ignored when a higher-priority mode is active.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelDkey` | int | No | Exclusive lower bound for the key of the delivery item. Only rows with a greater `SDelDkey` are returned. NULL is treated as `0`. Use the last key of the previous page for paging. |\n| `CreateDateFrom` | datetime | No | Inclusive lower bound for `SDelDcreateDate`. Used only if neither combined create/update date parameter is set. |\n| `CreateDateTo` | datetime | No | Exclusive upper bound for `SDelDcreateDate`. Used only if neither combined create/update date parameter is set. |\n| `UpdateDateFrom` | datetime | No | Inclusive lower bound for `SDelDupdateDate`. Used only if no combined date parameter and no create date parameter is set. |\n| `UpdateDateTo` | datetime | No | Exclusive upper bound for `SDelDupdateDate`. Used only if no combined date parameter and no create date parameter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Inclusive lower bound that matches if either `SDelDcreateDate` or `SDelDupdateDate` is on or after this value. Has the highest priority among the filter modes. |\n| `CreateAndUpdateDateTo` | datetime | No | Exclusive upper bound that matches if either `SDelDcreateDate` or `SDelDupdateDate` is before this value. Has the highest priority among the filter modes. |\n| `RowCount` | int | No | Maximum number of rows returned. NULL is treated as `1000`. |\n\n- All reads use `WITH (NOLOCK)`. Uncommitted data can be returned, and rows can be missed or appear twice while data is being changed.\n- `SDelDkey` is always used as an exclusive lower bound (`>`). Passing a specific key does **not** return that row; it returns the rows after it. The code has a branch for an exact key lookup and an empty-result branch, but neither can be reached, because `SDelDkey` and `RowCount` are never NULL after the preparation step.\n- In the combined create/update mode, the From and To checks are evaluated independently. A row can match the From bound through one date and the To bound through the other date. For example, a row created before To and updated after To is still returned.\n- A negative `RowCount` causes a SQL error in `TOP`. `RowCount = 0` returns no rows.\n\nDocumentation: https://pixi-api-docs.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": "Returns delivery item rows from SDelDetail, filtered by creation and/or update date and paged by key in ascending order.\n\nReads delivery item rows (table `SDelDetail`) and returns at most `@RowCount` rows, always sorted by `SDelDkey` ascending.\n\nPreparation:\n- If `SDelDkey` is NULL it is set to `0`.\n- If `RowCount` is NULL it is set to `1000`.\n\nOnly one filter mode is applied. The procedure checks the modes in this order and uses the first one that matches:\n1. **Create or update date**: `CreateAndUpdateDateFrom` and/or `CreateAndUpdateDateTo` is set. A row matches the lower bound if its creation date **or** its update date is `>=` the From value. It matches the upper bound if its creation date **or** its update date is `<` the To value.\n2. **Create date**: `CreateDateFrom` and/or `CreateDateTo` is set. The filter uses `SDelDcreateDate >= From` and `SDelDcreateDate < To`.\n3. **Update date**: `UpdateDateFrom` and/or `UpdateDateTo` is set. The filter uses `SDelDupdateDate >= From` and `SDelDupdateDate < To`.\n4. **Key range**: no date parameter is set. The call returns the next rows after `SDelDkey`.\n\nIn every mode only rows with `SDelDkey > @SDelDkey` are returned. To page through the data, pass the highest `SDelDkey` of the previous response as `SDelDkey` in the next call. Stop when fewer than `RowCount` rows come back.\n\nThe upper bounds of the date ranges are exclusive. Parameters of a lower-priority mode are ignored when a higher-priority mode is active.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelDkey` | int | No | Exclusive lower bound for the key of the delivery item. Only rows with a greater `SDelDkey` are returned. NULL is treated as `0`. Use the last key of the previous page for paging. |\n| `CreateDateFrom` | datetime | No | Inclusive lower bound for `SDelDcreateDate`. Used only if neither combined create/update date parameter is set. |\n| `CreateDateTo` | datetime | No | Exclusive upper bound for `SDelDcreateDate`. Used only if neither combined create/update date parameter is set. |\n| `UpdateDateFrom` | datetime | No | Inclusive lower bound for `SDelDupdateDate`. Used only if no combined date parameter and no create date parameter is set. |\n| `UpdateDateTo` | datetime | No | Exclusive upper bound for `SDelDupdateDate`. Used only if no combined date parameter and no create date parameter is set. |\n| `CreateAndUpdateDateFrom` | datetime | No | Inclusive lower bound that matches if either `SDelDcreateDate` or `SDelDupdateDate` is on or after this value. Has the highest priority among the filter modes. |\n| `CreateAndUpdateDateTo` | datetime | No | Exclusive upper bound that matches if either `SDelDcreateDate` or `SDelDupdateDate` is before this value. Has the highest priority among the filter modes. |\n| `RowCount` | int | No | Maximum number of rows returned. NULL is treated as `1000`. |\n\n- All reads use `WITH (NOLOCK)`. Uncommitted data can be returned, and rows can be missed or appear twice while data is being changed.\n- `SDelDkey` is always used as an exclusive lower bound (`>`). Passing a specific key does **not** return that row; it returns the rows after it. The code has a branch for an exact key lookup and an empty-result branch, but neither can be reached, because `SDelDkey` and `RowCount` are never NULL after the preparation step.\n- In the combined create/update mode, the From and To checks are evaluated independently. A row can match the From bound through one date and the To bound through the other date. For example, a row created before To and updated after To is still returned.\n- A negative `RowCount` causes a SQL error in `TOP`. `RowCount = 0` returns no rows.\n\nDocumentation: https://pixi-api-docs.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": "Updates the supplier price and supplier of a historical inbound price record (InvBinItemLog_In_Price) that has no delivery assigned yet.\n\nManually sets the supplier price of one historical (FIFO) inbound price record, identified by `InvBinItemLogId`.\n\nSteps:\n\n1. All four parameters are mandatory. If any of them is missing, an error row is returned.\n2. A negative `SupplierPrice` is rejected.\n3. `SupplierId` must exist as `SuppliersKey` in `Suppliers`.\n4. `UserName` must exist as `USER_NAME` in `UCS_USERS`. The matching user ID is stored as the modifying user.\n5. The record `InvBinItemLogId` must exist in `InvBinItemLog_In_Price`.\n6. Only records without a `DeliveryId` can be changed. Records already linked to a delivery are rejected.\n7. The record is updated:\n - `Price` is set to `SupplierPrice`.\n - `SupplierId` is set to `SupplierId`.\n - `DeliveryId` and `DeliveryId_Assigned` are set to NULL.\n - `QuerySource` is set to `5` (manual update via API).\n - `RecordModifiedByUserId` and `RecordModifiedOn` are set; the timestamp is the current time as `smalldatetime`.\n\nThe call returns exactly one row with a status and a message, either an error or a success confirmation.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvBinItemLogId` | int | No | ID of the historical inbound price record in `InvBinItemLog_In_Price`. Effectively mandatory. |\n| `SupplierPrice` | money | No | New supplier price. Must not be negative. Effectively mandatory. |\n| `SupplierId` | int | No | Supplier key (`SuppliersKey`) to store on the record. Must exist. Effectively mandatory. |\n| `UserName` | varchar(30) | No | Pixi user name (`USER_NAME` in `UCS_USERS`) recorded as the modifying user. Effectively mandatory. |\n\n- **Column name pitfall:** Validation error rows use the column `Status`. The success row and the error row from the CATCH block use the misspelled column `Staus`. Clients should check both column names.\n- The header comment of the procedure (\"Returns FIFO supplier prices\") does not match its behaviour. The procedure updates data.\n- The procedure opens its own transaction, or a savepoint if the caller already has an open transaction.\n- The validation checks return before a commit or rollback. If no outer transaction exists, the call can end with the transaction still open. SQL Server may then report a transaction count mismatch.\n- If a runtime error occurs, the transaction or savepoint is rolled back. The error is logged via `log.InsertError` (not attached).\n- Lookups use `NOLOCK`. The update uses `ROWLOCK`.\n- In the success message the price is formatted as `money` cast to `varchar`, i.e. with two decimal places.\n\nDocumentation: https://pixi-api-docs.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": "Updates the supplier price and supplier of a historical inbound price record (InvBinItemLog_In_Price) that has no delivery assigned yet.\n\nManually sets the supplier price of one historical (FIFO) inbound price record, identified by `InvBinItemLogId`.\n\nSteps:\n\n1. All four parameters are mandatory. If any of them is missing, an error row is returned.\n2. A negative `SupplierPrice` is rejected.\n3. `SupplierId` must exist as `SuppliersKey` in `Suppliers`.\n4. `UserName` must exist as `USER_NAME` in `UCS_USERS`. The matching user ID is stored as the modifying user.\n5. The record `InvBinItemLogId` must exist in `InvBinItemLog_In_Price`.\n6. Only records without a `DeliveryId` can be changed. Records already linked to a delivery are rejected.\n7. The record is updated:\n - `Price` is set to `SupplierPrice`.\n - `SupplierId` is set to `SupplierId`.\n - `DeliveryId` and `DeliveryId_Assigned` are set to NULL.\n - `QuerySource` is set to `5` (manual update via API).\n - `RecordModifiedByUserId` and `RecordModifiedOn` are set; the timestamp is the current time as `smalldatetime`.\n\nThe call returns exactly one row with a status and a message, either an error or a success confirmation.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `InvBinItemLogId` | int | No | ID of the historical inbound price record in `InvBinItemLog_In_Price`. Effectively mandatory. |\n| `SupplierPrice` | money | No | New supplier price. Must not be negative. Effectively mandatory. |\n| `SupplierId` | int | No | Supplier key (`SuppliersKey`) to store on the record. Must exist. Effectively mandatory. |\n| `UserName` | varchar(30) | No | Pixi user name (`USER_NAME` in `UCS_USERS`) recorded as the modifying user. Effectively mandatory. |\n\n- **Column name pitfall:** Validation error rows use the column `Status`. The success row and the error row from the CATCH block use the misspelled column `Staus`. Clients should check both column names.\n- The header comment of the procedure (\"Returns FIFO supplier prices\") does not match its behaviour. The procedure updates data.\n- The procedure opens its own transaction, or a savepoint if the caller already has an open transaction.\n- The validation checks return before a commit or rollback. If no outer transaction exists, the call can end with the transaction still open. SQL Server may then report a transaction count mismatch.\n- If a runtime error occurs, the transaction or savepoint is rolled back. The error is logged via `log.InsertError` (not attached).\n- Lookups use `NOLOCK`. The update uses `ROWLOCK`.\n- In the success message the price is formatted as `money` cast to `varchar`, i.e. with two decimal places.\n\nDocumentation: https://pixi-api-docs.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": "Changes the status of one or more supplier orders by calling the internal procedure pixi.SupplierOrderChangeStatus and returns a status row.\n\nSets a new status (`ChangeStatusIdTo`) on supplier orders.\n\n1. **User resolution:** if `UserId` is not given, the user ID is looked up from `UserName` in `UCS_USERS`. If the name does not exist, the ID of the user `pixiAdministration` is used.\n2. **Order selection:** the orders are identified by one of these parameters:\n - `SupplierOrderId`: a single supplier order ID. The value `0` is treated like `NULL`.\n - `SupplierOrderIds`: a list of supplier order IDs, passed on unchanged to the internal procedure.\n - `SupplierOrderNR`: used only if `SupplierOrderId` and `SupplierOrderIds` are both empty. The call looks up the supplier order with this `InternalNumber`. If several orders match, the one with the highest `Id` is used.\n - If none of the three is given, the call returns `Invalid parameters`.\n3. **Status check:** if `ChangeStatusIdTo` = `3` (confirmed, CON), the single order in `SupplierOrderId` must have status `2` (ordered, BES). Otherwise an error row is returned.\n4. **Status change:** the call runs `pixi.SupplierOrderChangeStatus` through `sp_executesql`. It passes the user ID, the target status, the single ID and the ID list.\n5. The call returns one row with `ReturnCode` = `Success`. If an error occurs, the row contains `ERROR` and the error message.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Not used by the code. |\n| `UserId` | int | No | ID of the user who performs the change. If `NULL`, the ID is looked up from `UserName`. |\n| `UserName` | varchar(50) | Yes | User name used to look up the user ID when `UserId` is empty. If the name is unknown, the user `pixiAdministration` is used. |\n| `ChangeStatusIdTo` | int | Yes | ID of the target status. `3` (confirmed, CON) is only allowed if the order has status `2` (ordered, BES). Further valid values are defined in `pixi.SupplierOrderChangeStatus`. |\n| `SupplierOrderId` | int | No | ID of a single supplier order. `0` is treated as `NULL`. |\n| `SupplierOrderIds` | varchar(8000) | No | List of supplier order IDs for a bulk change, passed unchanged to `pixi.SupplierOrderChangeStatus`. The format is defined there, probably comma-separated. |\n| `SupplierOrderNR` | int | No | Internal number (`InternalNumber`) of a supplier order. Only used if `SupplierOrderId` and `SupplierOrderIds` are empty. If several orders match, the one with the highest `Id` is used. |\n\n- The actual status change is done by `pixi.SupplierOrderChangeStatus`, whose definition is not attached. Its exact logic, the tables it writes, the valid target status IDs, the expected format of `SupplierOrderIds` (probably comma-separated) and any result sets of its own are therefore unknown.\n- The CON/BES check only applies to `SupplierOrderId`, including the ID found via `SupplierOrderNR`. Orders passed only in `SupplierOrderIds` are not checked here.\n- If `SupplierOrderNR` matches no order, no error is returned. The call goes on with an empty ID.\n- The status check reads `SupplierOrder` with `NOLOCK`.\n- The call runs in its own transaction. If the caller already has an open transaction, a savepoint is used instead. On error the call rolls back to this point. A transaction that is no longer committable can cause a further error at this rollback.\n- `AppName` is declared but not used.\n- `UserName` has no default and must always be sent, even if `UserId` is given.\n\nDocumentation: https://pixi-api-docs.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": "Changes the status of one or more supplier orders by calling the internal procedure pixi.SupplierOrderChangeStatus and returns a status row.\n\nSets a new status (`ChangeStatusIdTo`) on supplier orders.\n\n1. **User resolution:** if `UserId` is not given, the user ID is looked up from `UserName` in `UCS_USERS`. If the name does not exist, the ID of the user `pixiAdministration` is used.\n2. **Order selection:** the orders are identified by one of these parameters:\n - `SupplierOrderId`: a single supplier order ID. The value `0` is treated like `NULL`.\n - `SupplierOrderIds`: a list of supplier order IDs, passed on unchanged to the internal procedure.\n - `SupplierOrderNR`: used only if `SupplierOrderId` and `SupplierOrderIds` are both empty. The call looks up the supplier order with this `InternalNumber`. If several orders match, the one with the highest `Id` is used.\n - If none of the three is given, the call returns `Invalid parameters`.\n3. **Status check:** if `ChangeStatusIdTo` = `3` (confirmed, CON), the single order in `SupplierOrderId` must have status `2` (ordered, BES). Otherwise an error row is returned.\n4. **Status change:** the call runs `pixi.SupplierOrderChangeStatus` through `sp_executesql`. It passes the user ID, the target status, the single ID and the ID list.\n5. The call returns one row with `ReturnCode` = `Success`. If an error occurs, the row contains `ERROR` and the error message.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Not used by the code. |\n| `UserId` | int | No | ID of the user who performs the change. If `NULL`, the ID is looked up from `UserName`. |\n| `UserName` | varchar(50) | Yes | User name used to look up the user ID when `UserId` is empty. If the name is unknown, the user `pixiAdministration` is used. |\n| `ChangeStatusIdTo` | int | Yes | ID of the target status. `3` (confirmed, CON) is only allowed if the order has status `2` (ordered, BES). Further valid values are defined in `pixi.SupplierOrderChangeStatus`. |\n| `SupplierOrderId` | int | No | ID of a single supplier order. `0` is treated as `NULL`. |\n| `SupplierOrderIds` | varchar(8000) | No | List of supplier order IDs for a bulk change, passed unchanged to `pixi.SupplierOrderChangeStatus`. The format is defined there, probably comma-separated. |\n| `SupplierOrderNR` | int | No | Internal number (`InternalNumber`) of a supplier order. Only used if `SupplierOrderId` and `SupplierOrderIds` are empty. If several orders match, the one with the highest `Id` is used. |\n\n- The actual status change is done by `pixi.SupplierOrderChangeStatus`, whose definition is not attached. Its exact logic, the tables it writes, the valid target status IDs, the expected format of `SupplierOrderIds` (probably comma-separated) and any result sets of its own are therefore unknown.\n- The CON/BES check only applies to `SupplierOrderId`, including the ID found via `SupplierOrderNR`. Orders passed only in `SupplierOrderIds` are not checked here.\n- If `SupplierOrderNR` matches no order, no error is returned. The call goes on with an empty ID.\n- The status check reads `SupplierOrder` with `NOLOCK`.\n- The call runs in its own transaction. If the caller already has an open transaction, a savepoint is used instead. On error the call rolls back to this point. A transaction that is no longer committable can cause a further error at this rollback.\n- `AppName` is declared but not used.\n- `UserName` has no default and must always be sent, even if `UserId` is given.\n\nDocumentation: https://pixi-api-docs.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": "Creates a supplier order or pre-order from an XML document for a supplier, delivery location and order location.\n\nCreates a supplier order (`Type` = 1) or a pre-order (`Type` = 2). The actual creation is delegated to the internal procedure `pixi.SupplierOrderCreate`. This wrapper resolves the input values and formats the response.\n\nSteps:\n\n1. Any `Type` other than `2` is treated as `1`.\n2. For supplier orders (`Type` = 1), `OrderConsiderationStartDate` must be empty. Otherwise an error row is returned and nothing is created.\n3. A transaction is started. If the caller already has an open transaction, a savepoint is set instead.\n4. `UserId` is resolved from `UserName` if not given. Unknown user names fall back to the user `pixiAdministration`.\n5. The supplier is resolved by `SupplierId` (`Suppliers.SuppliersKey`), or by `SupplierNr` (`SupplNr`) if `SupplierId` is NULL.\n6. Delivery location and order location are resolved by their key (`DeliveryLocationId`, `OrderLocationId`), or by the location code `LocID` (`DeliveryLocation`, `OrderLocation`) if the key is NULL. A given ID that does not exist resolves to NULL. The code then does not fall back to the code value.\n7. Input values are normalised:\n - `ConsiderPackageUnits` and `ConsiderMinOrderQty`: NULL becomes `0`.\n - `EstimatedDeliveryDate` and `OrderConsiderationStartDate`: the time part is removed.\n - `ExternalCode`: an empty string becomes NULL.\n8. `pixi.SupplierOrderCreate` is executed with the order document `SupplOrderDocument` and all resolved values.\n9. If `ShowDetailedReturn` = 1, a detail result set is returned. It has one row per item line of the input and shows how each line was matched. The status is one of `OK`, `Item not found`, `Item does not have the correct supplier assigned` or `Item number supplier is missing for the item`. The row also contains the created order and order line if one exists. If `ShowDetailedReturn` = 0, the inner procedure is asked to return the created IDs instead.\n10. If the call opened its own transaction, it is committed. After the commit, a `ReturnCode`/`ErrorMessage` row is returned if the supplier, delivery location or order location could not be resolved.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Not used by the code. |\n| `UserId` | int | No | ID of the Pixi user. If NULL, it is resolved from `UserName`. |\n| `UserName` | varchar(50) | Yes | Pixi user name. Used only if `UserId` is NULL. Unknown names fall back to `pixiAdministration`. |\n| `SupplierId` | int | No | Supplier key (`SuppliersKey`). Takes precedence over `SupplierNr`. |\n| `SupplierNr` | varchar(4) | No | Supplier number (`SupplNr`). Used if `SupplierId` is NULL. |\n| `DeliveryLocation` | varchar(3) | No | Location code (`LocID`) of the delivery and billing location. Used if `DeliveryLocationId` is NULL. |\n| `DeliveryLocationId` | int | No | Location key of the delivery and billing location. Takes precedence over `DeliveryLocation`. |\n| `OrderLocation` | varchar(3) | No | Location code (`LocID`) of the order location. Used if `OrderLocationId` is NULL. |\n| `OrderLocationId` | int | No | Location key of the order location. Takes precedence over `OrderLocation`. |\n| `SupplOrderDocument` | xml | Yes | XML document with the order lines. It is parsed by `pixi.SupplierOrderCreate`, which is not attached, so the exact structure is not known from this code. |\n| `ConsiderPackageUnits` | bit | No | Whether package units are taken into account for the quantities. NULL is treated as 0. |\n| `ConsiderMinOrderQty` | bit | No | Whether the minimum order quantity is taken into account. NULL is treated as 0. |\n| `ExternalCode` | nvarchar(50) | No | External reference of the order. An empty string is treated as NULL. |\n| `EstimatedDeliveryDate` | datetime | No | Estimated delivery date. The time part is removed. |\n| `ShowDetailedReturn` | bit | No | 1 returns a detail row per input line with match status. 0 lets the inner procedure return the created IDs. |\n| `Type` | int | No | Order type. Any value other than 2 is treated as 1. |\n| `OrderConsiderationStartDate` | datetime | No | Start date for order consideration. Only allowed for pre-orders (`Type` = 2). The time part is removed. |\n\n- The structure of `SupplOrderDocument` and the actual inserts are defined in `pixi.SupplierOrderCreate`, which is not attached. The XML layout, the result set with the created IDs and the tables written cannot be derived from this code. The detail output suggests that lines identify items by internal item number (matched against `pixi.ItemCode` with `CodeTypeId` = 2), by supplier item number or by item ID.\n- Supplier and locations are validated only **after** the inner procedure has run and the transaction has been committed. Their validation message is therefore not a guarantee that nothing was written.\n- If the call runs inside an outer transaction, no validation message is returned at all. The commit is then also left to the caller.\n- The validation row uses the `ReturnCode` value `Error ` with a trailing space, while other errors use `ERROR`.\n- In detailed mode, the created order is determined as `MAX(Id)` of `pixi.SupplierOrder`. Under concurrent order creation, this may refer to a different order.\n- Lookups use `NOLOCK`.\n- Errors are caught. The transaction or savepoint is rolled back, and the error is returned as a `ReturnCode` = `ERROR` row, not as a SQL error.\n- `AppName` is required but not used by the code.\n\nDocumentation: https://pixi-api-docs.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": "Creates a supplier order or pre-order from an XML document for a supplier, delivery location and order location.\n\nCreates a supplier order (`Type` = 1) or a pre-order (`Type` = 2). The actual creation is delegated to the internal procedure `pixi.SupplierOrderCreate`. This wrapper resolves the input values and formats the response.\n\nSteps:\n\n1. Any `Type` other than `2` is treated as `1`.\n2. For supplier orders (`Type` = 1), `OrderConsiderationStartDate` must be empty. Otherwise an error row is returned and nothing is created.\n3. A transaction is started. If the caller already has an open transaction, a savepoint is set instead.\n4. `UserId` is resolved from `UserName` if not given. Unknown user names fall back to the user `pixiAdministration`.\n5. The supplier is resolved by `SupplierId` (`Suppliers.SuppliersKey`), or by `SupplierNr` (`SupplNr`) if `SupplierId` is NULL.\n6. Delivery location and order location are resolved by their key (`DeliveryLocationId`, `OrderLocationId`), or by the location code `LocID` (`DeliveryLocation`, `OrderLocation`) if the key is NULL. A given ID that does not exist resolves to NULL. The code then does not fall back to the code value.\n7. Input values are normalised:\n - `ConsiderPackageUnits` and `ConsiderMinOrderQty`: NULL becomes `0`.\n - `EstimatedDeliveryDate` and `OrderConsiderationStartDate`: the time part is removed.\n - `ExternalCode`: an empty string becomes NULL.\n8. `pixi.SupplierOrderCreate` is executed with the order document `SupplOrderDocument` and all resolved values.\n9. If `ShowDetailedReturn` = 1, a detail result set is returned. It has one row per item line of the input and shows how each line was matched. The status is one of `OK`, `Item not found`, `Item does not have the correct supplier assigned` or `Item number supplier is missing for the item`. The row also contains the created order and order line if one exists. If `ShowDetailedReturn` = 0, the inner procedure is asked to return the created IDs instead.\n10. If the call opened its own transaction, it is committed. After the commit, a `ReturnCode`/`ErrorMessage` row is returned if the supplier, delivery location or order location could not be resolved.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Not used by the code. |\n| `UserId` | int | No | ID of the Pixi user. If NULL, it is resolved from `UserName`. |\n| `UserName` | varchar(50) | Yes | Pixi user name. Used only if `UserId` is NULL. Unknown names fall back to `pixiAdministration`. |\n| `SupplierId` | int | No | Supplier key (`SuppliersKey`). Takes precedence over `SupplierNr`. |\n| `SupplierNr` | varchar(4) | No | Supplier number (`SupplNr`). Used if `SupplierId` is NULL. |\n| `DeliveryLocation` | varchar(3) | No | Location code (`LocID`) of the delivery and billing location. Used if `DeliveryLocationId` is NULL. |\n| `DeliveryLocationId` | int | No | Location key of the delivery and billing location. Takes precedence over `DeliveryLocation`. |\n| `OrderLocation` | varchar(3) | No | Location code (`LocID`) of the order location. Used if `OrderLocationId` is NULL. |\n| `OrderLocationId` | int | No | Location key of the order location. Takes precedence over `OrderLocation`. |\n| `SupplOrderDocument` | xml | Yes | XML document with the order lines. It is parsed by `pixi.SupplierOrderCreate`, which is not attached, so the exact structure is not known from this code. |\n| `ConsiderPackageUnits` | bit | No | Whether package units are taken into account for the quantities. NULL is treated as 0. |\n| `ConsiderMinOrderQty` | bit | No | Whether the minimum order quantity is taken into account. NULL is treated as 0. |\n| `ExternalCode` | nvarchar(50) | No | External reference of the order. An empty string is treated as NULL. |\n| `EstimatedDeliveryDate` | datetime | No | Estimated delivery date. The time part is removed. |\n| `ShowDetailedReturn` | bit | No | 1 returns a detail row per input line with match status. 0 lets the inner procedure return the created IDs. |\n| `Type` | int | No | Order type. Any value other than 2 is treated as 1. |\n| `OrderConsiderationStartDate` | datetime | No | Start date for order consideration. Only allowed for pre-orders (`Type` = 2). The time part is removed. |\n\n- The structure of `SupplOrderDocument` and the actual inserts are defined in `pixi.SupplierOrderCreate`, which is not attached. The XML layout, the result set with the created IDs and the tables written cannot be derived from this code. The detail output suggests that lines identify items by internal item number (matched against `pixi.ItemCode` with `CodeTypeId` = 2), by supplier item number or by item ID.\n- Supplier and locations are validated only **after** the inner procedure has run and the transaction has been committed. Their validation message is therefore not a guarantee that nothing was written.\n- If the call runs inside an outer transaction, no validation message is returned at all. The commit is then also left to the caller.\n- The validation row uses the `ReturnCode` value `Error ` with a trailing space, while other errors use `ERROR`.\n- In detailed mode, the created order is determined as `MAX(Id)` of `pixi.SupplierOrder`. Under concurrent order creation, this may refer to a different order.\n- Lookups use `NOLOCK`.\n- Errors are caught. The transaction or savepoint is rolled back, and the error is returned as a `ReturnCode` = `ERROR` row, not as a SQL error.\n- `AppName` is required but not used by the code.\n\nDocumentation: https://pixi-api-docs.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": "Deletes one or more supplier orders (purchase orders), identified by ID or internal number, and returns a status row.\n\nDeletes supplier orders (purchase orders). The orders to delete can be passed in four ways, which can be **combined freely**:\n\n- `SupplierOrderId`: a single supplier order ID.\n- `SupplierOrderIds`: a comma-separated list of supplier order IDs.\n- `SupplierOrderNr`: a single internal supplier order number (`SupplierOrder.InternalNumber`). It is resolved to the matching ID.\n- `SupplierOrderNrs`: a comma-separated list of internal supplier order numbers. They are resolved to IDs.\n\nValues of `0`, `NULL` or an empty string are treated as \"not given\". All IDs collected from these parameters are merged into one candidate list. The list is passed as a comma-separated string to the internal procedure `pixi.SupplierOrderDelete`, which performs the actual deletion.\n\nThe call then checks whether any of the candidate IDs still exists in `SupplierOrder`:\n\n- If none of them exists, it returns `ReturnCode` = `SUCCESS` and an empty `ErrorMessage`.\n- If at least one still exists, it returns `ReturnCode` = `WARNING` with the message *Some Purchase Orders from list were not deleted.* The call does not say which orders were kept.\n\nIf an error occurs, the transaction is rolled back and a row with `ReturnCode` = `ERROR` and the SQL error text is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | No | Name of the calling application. Declared but not used by the code. |\n| `SupplierOrderId` | int | No | ID of a single supplier order to delete. `0` or `NULL` means not given. |\n| `SupplierOrderIds` | varchar(8000) | No | Comma-separated list of supplier order IDs to delete. Spaces around entries are trimmed. Empty means not given. |\n| `SupplierOrderNr` | int | No | Internal number (`InternalNumber`) of a single supplier order to delete. `0` or `NULL` means not given. |\n| `SupplierOrderNrs` | varchar(8000) | No | Comma-separated list of internal supplier order numbers to delete. Each entry must be an integer. Empty means not given. |\n\n- The deletion logic itself (which orders may be deleted, which dependent data is removed) lives in `pixi.SupplierOrderDelete`, which is not attached. Its rules and any result sets it might return are unknown.\n- The work runs in a transaction. If the caller already has an open transaction, a savepoint is used instead, and **no status row is returned on success**; only the error row is returned in that case. A normal SOAP call has no outer transaction and always gets a status row.\n- `AppName` is declared but not used.\n- IDs passed in `SupplierOrderIds` are not checked for existence. IDs that do not exist do not cause a warning, because the final check only looks for candidates that still exist.\n- Non-numeric entries in `SupplierOrderIds` or `SupplierOrderNrs` cause a conversion error and an `ERROR` row; nothing is deleted.\n- If no parameter identifies an order, an empty list (`NULL`) is passed to `pixi.SupplierOrderDelete`. What that procedure does with it is not visible.\n- Lookups of internal numbers and the final existence check use `NOLOCK`.\n- `SupplierOrderIds` and `SupplierOrderNrs` are limited to 8000 characters.\n\nDocumentation: https://pixi-api-docs.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": "Deletes one or more supplier orders (purchase orders), identified by ID or internal number, and returns a status row.\n\nDeletes supplier orders (purchase orders). The orders to delete can be passed in four ways, which can be **combined freely**:\n\n- `SupplierOrderId`: a single supplier order ID.\n- `SupplierOrderIds`: a comma-separated list of supplier order IDs.\n- `SupplierOrderNr`: a single internal supplier order number (`SupplierOrder.InternalNumber`). It is resolved to the matching ID.\n- `SupplierOrderNrs`: a comma-separated list of internal supplier order numbers. They are resolved to IDs.\n\nValues of `0`, `NULL` or an empty string are treated as \"not given\". All IDs collected from these parameters are merged into one candidate list. The list is passed as a comma-separated string to the internal procedure `pixi.SupplierOrderDelete`, which performs the actual deletion.\n\nThe call then checks whether any of the candidate IDs still exists in `SupplierOrder`:\n\n- If none of them exists, it returns `ReturnCode` = `SUCCESS` and an empty `ErrorMessage`.\n- If at least one still exists, it returns `ReturnCode` = `WARNING` with the message *Some Purchase Orders from list were not deleted.* The call does not say which orders were kept.\n\nIf an error occurs, the transaction is rolled back and a row with `ReturnCode` = `ERROR` and the SQL error text is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | No | Name of the calling application. Declared but not used by the code. |\n| `SupplierOrderId` | int | No | ID of a single supplier order to delete. `0` or `NULL` means not given. |\n| `SupplierOrderIds` | varchar(8000) | No | Comma-separated list of supplier order IDs to delete. Spaces around entries are trimmed. Empty means not given. |\n| `SupplierOrderNr` | int | No | Internal number (`InternalNumber`) of a single supplier order to delete. `0` or `NULL` means not given. |\n| `SupplierOrderNrs` | varchar(8000) | No | Comma-separated list of internal supplier order numbers to delete. Each entry must be an integer. Empty means not given. |\n\n- The deletion logic itself (which orders may be deleted, which dependent data is removed) lives in `pixi.SupplierOrderDelete`, which is not attached. Its rules and any result sets it might return are unknown.\n- The work runs in a transaction. If the caller already has an open transaction, a savepoint is used instead, and **no status row is returned on success**; only the error row is returned in that case. A normal SOAP call has no outer transaction and always gets a status row.\n- `AppName` is declared but not used.\n- IDs passed in `SupplierOrderIds` are not checked for existence. IDs that do not exist do not cause a warning, because the final check only looks for candidates that still exist.\n- Non-numeric entries in `SupplierOrderIds` or `SupplierOrderNrs` cause a conversion error and an `ERROR` row; nothing is deleted.\n- If no parameter identifies an order, an empty list (`NULL`) is passed to `pixi.SupplierOrderDelete`. What that procedure does with it is not visible.\n- Lookups of internal numbers and the final existence check use `NOLOCK`.\n- `SupplierOrderIds` and `SupplierOrderNrs` are limited to 8000 characters.\n\nDocumentation: https://pixi-api-docs.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": "Adds order lines to an existing purchase order (supplier order) in status NEW or BES, based on an XML document of items.\n\nAdds lines to an existing purchase order (supplier order).\n\n1. The user is resolved from `UserName`. If the name is unknown, the user `pixiAdministration` is used.\n2. `ConsiderPackageUnits` and `ConsiderMinOrderQty` are set to `0` if `NULL`.\n3. The purchase order is searched in `SupplierOrder` by `Id = SupplierOrderId` **or** `InternalNumber = SupplierOrderNr`. Exactly one order must match:\n - no match: error *Purchase order does not exist!*\n - more than one match: error *Parameters @SupplierOrderId and @SupplierOrderNr belong to different purchase order!*\n4. The order must have status `1` (NEW) or `2` (BES). Otherwise the call returns *Purchase order is not in status NEW or BES!*\n5. If all checks pass, the internal procedure `pixi.SupplierOrderLineCreate` creates the lines. It receives the order ID, the user ID, both flags and `PurchaseOrderXML`.\n\nThe call returns one result set with status rows (`Status`, `StatusDescription`, `ItemId`), sorted by `Status` and `ItemId`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplierOrderId` | int | No | Internal ID of the purchase order (`SupplierOrder.Id`). Alternative to `SupplierOrderNr`. |\n| `SupplierOrderNr` | int | No | Internal number of the purchase order (`SupplierOrder.InternalNumber`). Alternative to `SupplierOrderId`. |\n| `UserName` | varchar(50) | No | Pixi user name under which the lines are created. Falls back to `pixiAdministration` if the name is unknown. |\n| `ConsiderPackageUnits` | bit | No | Whether package units are considered when creating the lines. `NULL` is treated as `0`. |\n| `ConsiderMinOrderQty` | bit | No | Whether the minimum order quantity is considered when creating the lines. `NULL` is treated as `0`. |\n| `PurchaseOrderXML` | xml | Yes | XML document with the lines to add. It is passed unchanged to `pixi.SupplierOrderLineCreate`. Its structure is defined there and is not visible in this code, so the example is only illustrative. |\n\n- The actual line creation is done by `pixi.SupplierOrderLineCreate`, which is not attached. Several things therefore cannot be documented here:\n - the expected structure of `PurchaseOrderXML`\n - how package units and minimum order quantities are applied\n - which tables are written\n - which status and description values appear in the result on success\n- `pixi.SupplierOrderLineCreate` is called with `@pipiSupplierOrderLineCreate_ReturnInfo = 1`. Presumably it writes its per-item results into the temporary result table that this call returns.\n- Pass only one of `SupplierOrderId` or `SupplierOrderNr`, or make sure both refer to the same order. The lookup uses `OR`, so two different matches cause an error. If both are `NULL`, nothing matches and *Purchase order does not exist!* is returned.\n- The order lookup uses `NOLOCK`.\n- The call runs in its own transaction, or in a savepoint if a transaction is already open.\n- On a SQL error the transaction is rolled back and the error is logged via `log.InsertError`. Whether the error is passed on to the caller depends on that procedure, which is not attached. In that case the status result set may be missing.\n\nDocumentation: https://pixi-api-docs.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": "Adds order lines to an existing purchase order (supplier order) in status NEW or BES, based on an XML document of items.\n\nAdds lines to an existing purchase order (supplier order).\n\n1. The user is resolved from `UserName`. If the name is unknown, the user `pixiAdministration` is used.\n2. `ConsiderPackageUnits` and `ConsiderMinOrderQty` are set to `0` if `NULL`.\n3. The purchase order is searched in `SupplierOrder` by `Id = SupplierOrderId` **or** `InternalNumber = SupplierOrderNr`. Exactly one order must match:\n - no match: error *Purchase order does not exist!*\n - more than one match: error *Parameters @SupplierOrderId and @SupplierOrderNr belong to different purchase order!*\n4. The order must have status `1` (NEW) or `2` (BES). Otherwise the call returns *Purchase order is not in status NEW or BES!*\n5. If all checks pass, the internal procedure `pixi.SupplierOrderLineCreate` creates the lines. It receives the order ID, the user ID, both flags and `PurchaseOrderXML`.\n\nThe call returns one result set with status rows (`Status`, `StatusDescription`, `ItemId`), sorted by `Status` and `ItemId`.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplierOrderId` | int | No | Internal ID of the purchase order (`SupplierOrder.Id`). Alternative to `SupplierOrderNr`. |\n| `SupplierOrderNr` | int | No | Internal number of the purchase order (`SupplierOrder.InternalNumber`). Alternative to `SupplierOrderId`. |\n| `UserName` | varchar(50) | No | Pixi user name under which the lines are created. Falls back to `pixiAdministration` if the name is unknown. |\n| `ConsiderPackageUnits` | bit | No | Whether package units are considered when creating the lines. `NULL` is treated as `0`. |\n| `ConsiderMinOrderQty` | bit | No | Whether the minimum order quantity is considered when creating the lines. `NULL` is treated as `0`. |\n| `PurchaseOrderXML` | xml | Yes | XML document with the lines to add. It is passed unchanged to `pixi.SupplierOrderLineCreate`. Its structure is defined there and is not visible in this code, so the example is only illustrative. |\n\n- The actual line creation is done by `pixi.SupplierOrderLineCreate`, which is not attached. Several things therefore cannot be documented here:\n - the expected structure of `PurchaseOrderXML`\n - how package units and minimum order quantities are applied\n - which tables are written\n - which status and description values appear in the result on success\n- `pixi.SupplierOrderLineCreate` is called with `@pipiSupplierOrderLineCreate_ReturnInfo = 1`. Presumably it writes its per-item results into the temporary result table that this call returns.\n- Pass only one of `SupplierOrderId` or `SupplierOrderNr`, or make sure both refer to the same order. The lookup uses `OR`, so two different matches cause an error. If both are `NULL`, nothing matches and *Purchase order does not exist!* is returned.\n- The order lookup uses `NOLOCK`.\n- The call runs in its own transaction, or in a savepoint if a transaction is already open.\n- On a SQL error the transaction is rolled back and the error is logged via `log.InsertError`. Whether the error is passed on to the caller depends on that procedure, which is not attached. In that case the status result set may be missing.\n\nDocumentation: https://pixi-api-docs.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": "Deletes one or more supplier order lines (purchase order lines) and returns a status row with SUCCESS, WARNING or ERROR.\n\nDeletes supplier order lines (purchase order lines) by their IDs. The actual deletion is done by the internal procedure `pixi.SupplierOrderLineDelete`. According to the header comment, the supplier order itself may be updated as well.\n\nSteps:\n\n1. Opens a transaction. If the caller already has one open, a savepoint is set instead.\n2. Resolves the user. If `UserId` is not passed, the ID is looked up from `UserName` via `inf.UserGetByName`. If that name does not exist, the ID of the user `pixiAdministration` is used.\n3. Collects the lines to delete:\n - the single ID from `SupplierOrderLineId` (a value of `0` is treated like `NULL`);\n - every ID from the comma-separated list `SupplierOrderLineIds`. Elements are trimmed, empty elements are ignored and duplicates are removed.\n \n Both parameters can be combined.\n4. Calls `pixi.SupplierOrderLineDelete` with the user ID, the single ID and the ID list.\n5. Checks whether any of the requested IDs still exists in `SupplierOrderLine`. If so, the result is `WARNING` with the message `Some Purchase Orderlines items from list were not deleted.` Otherwise the result is `SUCCESS`.\n6. Commits and returns one status row with `ReturnCode` and `ErrorMessage`.\n\nIf an error occurs, the transaction is rolled back and a row with `ReturnCode` = `ERROR` and the SQL error text is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Required, but not used by the procedure. |\n| `UserId` | int | No | ID of the Pixi user who performs the deletion. If `NULL`, the ID is resolved from `UserName`. |\n| `UserName` | varchar(50) | Yes | Pixi user name. Used to determine the user ID when `UserId` is not set. If the name does not exist, the user `pixiAdministration` is used. |\n| `SupplierOrderLineId` | int | No | ID of a single supplier order line to delete. `0` is treated as `NULL`. |\n| `SupplierOrderLineIds` | varchar(8000) | No | Comma-separated list of supplier order line IDs to delete. Spaces around the elements are trimmed and empty elements are ignored. All elements must be integers. Can be combined with `SupplierOrderLineId`. |\n\n- The definition of `pixi.SupplierOrderLineDelete` is not attached. Therefore it is open:\n - which tables it changes;\n - under which conditions it refuses to delete a line, for example because goods were already received;\n - whether it updates the supplier order header.\n- `WARNING` is not a rollback. Lines that could be deleted stay deleted and the transaction is committed.\n- The existence check after the deletion reads `SupplierOrderLine` with `NOLOCK`.\n- Every non-empty element of `SupplierOrderLineIds` must be an integer. A non-numeric element causes a conversion error. The whole call is then rolled back and returns `ERROR`.\n- `AppName` is required but not used by this procedure.\n- `UserName` has no default and must always be sent, even if `UserId` is passed.\n- If the procedure runs inside an outer transaction, it returns no status row on success. This does not apply to normal SOAP calls.\n- If an error occurs inside an outer transaction that is still committable, the savepoint is not rolled back.\n\nDocumentation: https://pixi-api-docs.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": "Deletes one or more supplier order lines (purchase order lines) and returns a status row with SUCCESS, WARNING or ERROR.\n\nDeletes supplier order lines (purchase order lines) by their IDs. The actual deletion is done by the internal procedure `pixi.SupplierOrderLineDelete`. According to the header comment, the supplier order itself may be updated as well.\n\nSteps:\n\n1. Opens a transaction. If the caller already has one open, a savepoint is set instead.\n2. Resolves the user. If `UserId` is not passed, the ID is looked up from `UserName` via `inf.UserGetByName`. If that name does not exist, the ID of the user `pixiAdministration` is used.\n3. Collects the lines to delete:\n - the single ID from `SupplierOrderLineId` (a value of `0` is treated like `NULL`);\n - every ID from the comma-separated list `SupplierOrderLineIds`. Elements are trimmed, empty elements are ignored and duplicates are removed.\n \n Both parameters can be combined.\n4. Calls `pixi.SupplierOrderLineDelete` with the user ID, the single ID and the ID list.\n5. Checks whether any of the requested IDs still exists in `SupplierOrderLine`. If so, the result is `WARNING` with the message `Some Purchase Orderlines items from list were not deleted.` Otherwise the result is `SUCCESS`.\n6. Commits and returns one status row with `ReturnCode` and `ErrorMessage`.\n\nIf an error occurs, the transaction is rolled back and a row with `ReturnCode` = `ERROR` and the SQL error text is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Required, but not used by the procedure. |\n| `UserId` | int | No | ID of the Pixi user who performs the deletion. If `NULL`, the ID is resolved from `UserName`. |\n| `UserName` | varchar(50) | Yes | Pixi user name. Used to determine the user ID when `UserId` is not set. If the name does not exist, the user `pixiAdministration` is used. |\n| `SupplierOrderLineId` | int | No | ID of a single supplier order line to delete. `0` is treated as `NULL`. |\n| `SupplierOrderLineIds` | varchar(8000) | No | Comma-separated list of supplier order line IDs to delete. Spaces around the elements are trimmed and empty elements are ignored. All elements must be integers. Can be combined with `SupplierOrderLineId`. |\n\n- The definition of `pixi.SupplierOrderLineDelete` is not attached. Therefore it is open:\n - which tables it changes;\n - under which conditions it refuses to delete a line, for example because goods were already received;\n - whether it updates the supplier order header.\n- `WARNING` is not a rollback. Lines that could be deleted stay deleted and the transaction is committed.\n- The existence check after the deletion reads `SupplierOrderLine` with `NOLOCK`.\n- Every non-empty element of `SupplierOrderLineIds` must be an integer. A non-numeric element causes a conversion error. The whole call is then rolled back and returns `ERROR`.\n- `AppName` is required but not used by this procedure.\n- `UserName` has no default and must always be sent, even if `UserId` is passed.\n- If the procedure runs inside an outer transaction, it returns no status row on success. This does not apply to normal SOAP calls.\n- If an error occurs inside an outer transaction that is still committable, the savepoint is not rolled back.\n\nDocumentation: https://pixi-api-docs.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": "Creates a location-specific quantity for one supplier order line, optionally rounded to package units and the minimum order quantity.\n\nAdds a quantity for a specific location (Lagerort) to an existing supplier order line. The actual insert is done by the internal procedure `pixi.SupplierOrderLineLocQtyCreate`.\n\nSteps:\n\n1. Opens a transaction, or sets a savepoint if the caller already has an open transaction.\n2. Resolves the user: if `UserId` is empty, the user is looked up by `UserName`. If that name does not exist, the user `pixiAdministration` is used.\n3. Resolves the location in `dbo.Location`. If `LocationId` is passed, it is matched against `LocationKey`. Otherwise `Location` is matched against the location code `LocID`. `LocationId` takes priority over `Location`.\n4. Checks whether a quantity for this order line and location already exists in `pixi.SupplierOrderLineLocQty`. If so, the message `Location already exists for sent location.` is prepared.\n5. If the location was found:\n - `NULL` values of `ConsiderPackageUnits` and `ConsiderMinOrderQty` are treated as `0`.\n - The internal create procedure is called with the order line, location, quantity and both flags. It is asked to return the inserted IDs.\n6. If the location was not found, the message `Match value for parameter Location does not exists in db.` is prepared and nothing is created.\n7. If a message was prepared, a row with `ReturnCode` = `ERROR` and `ErrorMessage` is returned.\n8. Commits its own transaction.\n\nIf a SQL error occurs, the transaction is rolled back where possible and an `ERROR` row with the SQL error text is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Required, but not used by the code. |\n| `UserId` | int | No | ID of the acting user. If empty, the user is determined from `UserName`. |\n| `UserName` | varchar(50) | Yes | User name, used when `UserId` is empty. Unknown names fall back to `pixiAdministration`. |\n| `SupplierOrderLineId` | int | Yes | ID of the supplier order line that receives the location quantity. |\n| `Location` | varchar(3) | No | Location code (`LocID`). Only used when `LocationId` is empty. |\n| `LocationId` | int | No | Location key (`LocationKey`). Takes priority over `Location`. |\n| `Qty` | int | Yes | Quantity for the location. |\n| `ConsiderPackageUnits` | bit | No | Whether package units are considered by the internal create procedure. `NULL` is treated as `0`. |\n| `ConsiderMinOrderQty` | bit | No | Whether the minimum order quantity is considered by the internal create procedure. `NULL` is treated as `0`. |\n\n- **Duplicate check does not block the insert.** If a quantity for the location already exists, the error message is prepared, but the internal create procedure is still called. The caller therefore receives the result of the internal procedure followed by an `ERROR` row. Whether a duplicate is created or rejected depends on `pixi.SupplierOrderLineLocQtyCreate`, whose definition is not attached.\n- The behaviour of the internal procedure is not visible here. This covers which IDs it returns, how package units and minimum order quantity are applied, and which further tables it writes.\n- `AppName` is required but not used in the code.\n- `UserName` is required even when `UserId` is passed.\n- `dbo.Location` and `pixi.SupplierOrderLineLocQty` are read with `NOLOCK`.\n- If the caller has an outer transaction and a non-fatal error occurs, the code does not roll back. Changes made up to the error may remain in the outer transaction.\n- Success produces no explicit status row. Only the result of the internal procedure is returned.\n\nDocumentation: https://pixi-api-docs.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": "Creates a location-specific quantity for one supplier order line, optionally rounded to package units and the minimum order quantity.\n\nAdds a quantity for a specific location (Lagerort) to an existing supplier order line. The actual insert is done by the internal procedure `pixi.SupplierOrderLineLocQtyCreate`.\n\nSteps:\n\n1. Opens a transaction, or sets a savepoint if the caller already has an open transaction.\n2. Resolves the user: if `UserId` is empty, the user is looked up by `UserName`. If that name does not exist, the user `pixiAdministration` is used.\n3. Resolves the location in `dbo.Location`. If `LocationId` is passed, it is matched against `LocationKey`. Otherwise `Location` is matched against the location code `LocID`. `LocationId` takes priority over `Location`.\n4. Checks whether a quantity for this order line and location already exists in `pixi.SupplierOrderLineLocQty`. If so, the message `Location already exists for sent location.` is prepared.\n5. If the location was found:\n - `NULL` values of `ConsiderPackageUnits` and `ConsiderMinOrderQty` are treated as `0`.\n - The internal create procedure is called with the order line, location, quantity and both flags. It is asked to return the inserted IDs.\n6. If the location was not found, the message `Match value for parameter Location does not exists in db.` is prepared and nothing is created.\n7. If a message was prepared, a row with `ReturnCode` = `ERROR` and `ErrorMessage` is returned.\n8. Commits its own transaction.\n\nIf a SQL error occurs, the transaction is rolled back where possible and an `ERROR` row with the SQL error text is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Required, but not used by the code. |\n| `UserId` | int | No | ID of the acting user. If empty, the user is determined from `UserName`. |\n| `UserName` | varchar(50) | Yes | User name, used when `UserId` is empty. Unknown names fall back to `pixiAdministration`. |\n| `SupplierOrderLineId` | int | Yes | ID of the supplier order line that receives the location quantity. |\n| `Location` | varchar(3) | No | Location code (`LocID`). Only used when `LocationId` is empty. |\n| `LocationId` | int | No | Location key (`LocationKey`). Takes priority over `Location`. |\n| `Qty` | int | Yes | Quantity for the location. |\n| `ConsiderPackageUnits` | bit | No | Whether package units are considered by the internal create procedure. `NULL` is treated as `0`. |\n| `ConsiderMinOrderQty` | bit | No | Whether the minimum order quantity is considered by the internal create procedure. `NULL` is treated as `0`. |\n\n- **Duplicate check does not block the insert.** If a quantity for the location already exists, the error message is prepared, but the internal create procedure is still called. The caller therefore receives the result of the internal procedure followed by an `ERROR` row. Whether a duplicate is created or rejected depends on `pixi.SupplierOrderLineLocQtyCreate`, whose definition is not attached.\n- The behaviour of the internal procedure is not visible here. This covers which IDs it returns, how package units and minimum order quantity are applied, and which further tables it writes.\n- `AppName` is required but not used in the code.\n- `UserName` is required even when `UserId` is passed.\n- `dbo.Location` and `pixi.SupplierOrderLineLocQty` are read with `NOLOCK`.\n- If the caller has an outer transaction and a non-fatal error occurs, the code does not roll back. Changes made up to the error may remain in the outer transaction.\n- Success produces no explicit status row. Only the result of the internal procedure is returned.\n\nDocumentation: https://pixi-api-docs.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": "Deletes a location quantity record of a supplier order line and returns a status row with ReturnCode and ErrorMessage.\n\nRemoves one location quantity entry (`SupplierOrderLineLocQty`) of a supplier order (purchase order) line. The supplier order is updated accordingly by the internal procedure.\n\nSteps:\n1. Opens its own transaction, or sets a savepoint if a transaction is already open.\n2. Resolves the user: if `UserId` is empty, the user ID is looked up by `UserName`. If that name does not exist, the user `pixiAdministration` is used.\n3. Treats `NULL` for `ConsiderPackageUnits` and `ConsiderMinOrderQty` as `0`.\n4. Calls the internal procedure `pixi.SupplierOrderLineLocQtyDelete` with the user, the record ID and both flags. This procedure does the actual deletion.\n5. Checks whether the record with `SupplierOrderLineLocQtyId` still exists. If so, the result is `WARNING` with a message.\n6. Commits and returns one row with `ReturnCode` (`SUCCESS` or `WARNING`) and `ErrorMessage`.\n\nIf an error occurs, the transaction (or the savepoint) is rolled back. A row with `ReturnCode` = `ERROR` and the SQL error text is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Required, but not used by the code. |\n| `UserId` | int | No | ID of the executing user. If empty, the user is determined from `UserName`. |\n| `UserName` | varchar(50) | Yes | User name, used only if `UserId` is empty. Unknown names fall back to `pixiAdministration`. |\n| `SupplierOrderLineLocQtyId` | int | Yes | ID of the supplier order line location quantity record (`pixi.SupplierOrderLineLocQty.Id`) to delete. |\n| `ConsiderPackageUnits` | bit | No | Whether package units are considered when the supplier order is updated. `NULL` is treated as `0`. |\n| `ConsiderMinOrderQty` | bit | No | Whether minimum order quantities are considered when the supplier order is updated. `NULL` is treated as `0`. |\n\n- The deletion logic, including how package units and minimum order quantities are considered and how the supplier order is updated, is in `pixi.SupplierOrderLineLocQtyDelete`. That procedure is not attached, so its exact behaviour and the tables it changes are not documented here.\n- `AppName` is required but not used by the code.\n- The existence check after the deletion reads `pixi.SupplierOrderLineLocQty` with `NOLOCK`.\n- On success or warning, the status row is only returned if the call opened its own transaction. If the call runs inside an outer transaction, no row is returned on success. Error rows are always returned.\n- A `WARNING` does not roll back anything. Whatever the internal procedure changed is committed.\n\nDocumentation: https://pixi-api-docs.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": "Deletes a location quantity record of a supplier order line and returns a status row with ReturnCode and ErrorMessage.\n\nRemoves one location quantity entry (`SupplierOrderLineLocQty`) of a supplier order (purchase order) line. The supplier order is updated accordingly by the internal procedure.\n\nSteps:\n1. Opens its own transaction, or sets a savepoint if a transaction is already open.\n2. Resolves the user: if `UserId` is empty, the user ID is looked up by `UserName`. If that name does not exist, the user `pixiAdministration` is used.\n3. Treats `NULL` for `ConsiderPackageUnits` and `ConsiderMinOrderQty` as `0`.\n4. Calls the internal procedure `pixi.SupplierOrderLineLocQtyDelete` with the user, the record ID and both flags. This procedure does the actual deletion.\n5. Checks whether the record with `SupplierOrderLineLocQtyId` still exists. If so, the result is `WARNING` with a message.\n6. Commits and returns one row with `ReturnCode` (`SUCCESS` or `WARNING`) and `ErrorMessage`.\n\nIf an error occurs, the transaction (or the savepoint) is rolled back. A row with `ReturnCode` = `ERROR` and the SQL error text is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Required, but not used by the code. |\n| `UserId` | int | No | ID of the executing user. If empty, the user is determined from `UserName`. |\n| `UserName` | varchar(50) | Yes | User name, used only if `UserId` is empty. Unknown names fall back to `pixiAdministration`. |\n| `SupplierOrderLineLocQtyId` | int | Yes | ID of the supplier order line location quantity record (`pixi.SupplierOrderLineLocQty.Id`) to delete. |\n| `ConsiderPackageUnits` | bit | No | Whether package units are considered when the supplier order is updated. `NULL` is treated as `0`. |\n| `ConsiderMinOrderQty` | bit | No | Whether minimum order quantities are considered when the supplier order is updated. `NULL` is treated as `0`. |\n\n- The deletion logic, including how package units and minimum order quantities are considered and how the supplier order is updated, is in `pixi.SupplierOrderLineLocQtyDelete`. That procedure is not attached, so its exact behaviour and the tables it changes are not documented here.\n- `AppName` is required but not used by the code.\n- The existence check after the deletion reads `pixi.SupplierOrderLineLocQty` with `NOLOCK`.\n- On success or warning, the status row is only returned if the call opened its own transaction. If the call runs inside an outer transaction, no row is returned on success. Error rows are always returned.\n- A `WARNING` does not roll back anything. Whatever the internal procedure changed is committed.\n\nDocumentation: https://pixi-api-docs.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": "Returns location quantity data for one or more supplier orders, supplier order lines or supplier order line location quantity records.\n\nWrapper around the internal procedure `pixi.SupplierOrderLineLocQtyGet`. It returns location quantity data (quantities per location) for supplier order lines.\n\nSteps:\n\n1. Opens its own transaction, or sets a savepoint if the caller already has an open transaction.\n2. Calls `pixi.SupplierOrderLineLocQtyGet`, passing the parameters this way:\n - `SupplierOrderIds` → `@SoIds`\n - `SupplierOrderLinesIds` → `@SolIds`\n - `SupplierOrderLinesLocQtyIds` → `@SolLocQtyIds`\n3. Returns the result sets of that procedure unchanged to the caller, then commits its own transaction.\n\nIf an error occurs, the transaction or savepoint is rolled back and a single row with `ReturnCode` = `ERROR` and the SQL error text in `ErrorMessage` is returned.\n\n`AppName` is required but is not used by the code.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Required, but not used by the code. |\n| `SupplierOrderIds` | varchar(8000) | No | List of supplier order IDs, passed as `@SoIds` to `pixi.SupplierOrderLineLocQtyGet`. The list format is defined by that procedure, whose code is not available. |\n| `SupplierOrderLinesIds` | varchar(8000) | No | List of supplier order line IDs, passed as `@SolIds` to the inner procedure. |\n| `SupplierOrderLinesLocQtyIds` | varchar(8000) | No | List of IDs of supplier order line location quantity records, passed as `@SolLocQtyIds` to the inner procedure. |\n\n- The definition of `pixi.SupplierOrderLineLocQtyGet` is not available. The following points therefore cannot be derived from the code:\n - the format of the ID lists (probably comma-separated keys, not confirmed);\n - how the three filters are combined;\n - what happens when all filters are empty;\n - the columns, sort order and number of result sets returned.\n- The call runs inside a transaction (or savepoint) although it is a read call; the actual reads happen in the inner procedure.\n- If the inner procedure fails after it has already returned rows, the caller may receive those rows followed by the error row.\n\nDocumentation: https://pixi-api-docs.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": "Updates the quantity and/or undelivered quantity of one location quantity record of a supplier order line.\n\nUpdates a single supplier order line location quantity record, identified by `SupplierOrderLineLocQtyId`. The actual update is done by the internal procedure `pixi.SupplierOrderLineLocQtyUpdate`. This wrapper does the following:\n\n1. Opens a transaction. If the caller already has an open transaction, it sets a savepoint instead.\n2. Resolves the user. If `UserId` is given, it is used as is. Otherwise the user is looked up by `UserName` in `UCS_USERS`. If no user has that name, the user `pixiAdministration` is used.\n3. Normalises the parameters:\n - `ConsiderPackageUnits` and `ConsiderMinOrderQty` become `0` when they are `NULL`.\n - `Qty` and `UndeliveredQty` become `NULL` when they are `NULL` or `0`.\n4. Calls `pixi.SupplierOrderLineLocQtyUpdate` with these values. It always passes `ReturnUpdatedIds = 1`, so the internal procedure is asked to return the IDs it updated.\n5. Commits the transaction if this call opened it.\n\nOn any error the transaction or savepoint is rolled back. The call then returns one row with `ReturnCode = 'ERROR'` and the SQL error message.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Required, but not used by the code. |\n| `UserId` | int | No | ID of the acting user. If omitted, the user is determined from `UserName`. |\n| `UserName` | varchar(50) | Yes | User name, used to find the user when `UserId` is not given. If the name is not found, `pixiAdministration` is used. |\n| `SupplierOrderLineLocQtyId` | int | Yes | ID of the supplier order line location quantity record to update. |\n| `ConsiderPackageUnits` | bit | No | Whether package units are taken into account. `NULL` is treated as `0`. |\n| `ConsiderMinOrderQty` | bit | No | Whether the minimum order quantity is taken into account. `NULL` is treated as `0`. |\n| `Qty` | int | No | New ordered quantity. `0` is treated like `NULL` (not provided). |\n| `UndeliveredQty` | int | No | New undelivered (open) quantity. `0` is treated like `NULL` (not provided). |\n\n- **Internal procedure not attached:** the definition of `pixi.SupplierOrderLineLocQtyUpdate` is not available. It is therefore unknown:\n - which tables it changes,\n - which validations it performs,\n - which columns its success result set has,\n - how it handles `NULL` for `Qty` or `UndeliveredQty` (probably \"leave unchanged\").\n- **Value `0` cannot be set:** because of the check `ISNULL(@Qty, '') = ''`, the value `0` is treated like \"not provided\" and passed on as `NULL`. The same applies to `UndeliveredQty`. Setting a quantity to `0` is therefore not possible through this call.\n- **Unused parameter:** `AppName` is required but not used by the code.\n- **Rollback on error:** if an error makes the transaction uncommittable, the code rolls back to the savepoint. SQL Server does not allow this for uncommittable transactions and may raise a further error.\n\nDocumentation: https://pixi-api-docs.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": "Updates the quantity and/or undelivered quantity of one location quantity record of a supplier order line.\n\nUpdates a single supplier order line location quantity record, identified by `SupplierOrderLineLocQtyId`. The actual update is done by the internal procedure `pixi.SupplierOrderLineLocQtyUpdate`. This wrapper does the following:\n\n1. Opens a transaction. If the caller already has an open transaction, it sets a savepoint instead.\n2. Resolves the user. If `UserId` is given, it is used as is. Otherwise the user is looked up by `UserName` in `UCS_USERS`. If no user has that name, the user `pixiAdministration` is used.\n3. Normalises the parameters:\n - `ConsiderPackageUnits` and `ConsiderMinOrderQty` become `0` when they are `NULL`.\n - `Qty` and `UndeliveredQty` become `NULL` when they are `NULL` or `0`.\n4. Calls `pixi.SupplierOrderLineLocQtyUpdate` with these values. It always passes `ReturnUpdatedIds = 1`, so the internal procedure is asked to return the IDs it updated.\n5. Commits the transaction if this call opened it.\n\nOn any error the transaction or savepoint is rolled back. The call then returns one row with `ReturnCode = 'ERROR'` and the SQL error message.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Required, but not used by the code. |\n| `UserId` | int | No | ID of the acting user. If omitted, the user is determined from `UserName`. |\n| `UserName` | varchar(50) | Yes | User name, used to find the user when `UserId` is not given. If the name is not found, `pixiAdministration` is used. |\n| `SupplierOrderLineLocQtyId` | int | Yes | ID of the supplier order line location quantity record to update. |\n| `ConsiderPackageUnits` | bit | No | Whether package units are taken into account. `NULL` is treated as `0`. |\n| `ConsiderMinOrderQty` | bit | No | Whether the minimum order quantity is taken into account. `NULL` is treated as `0`. |\n| `Qty` | int | No | New ordered quantity. `0` is treated like `NULL` (not provided). |\n| `UndeliveredQty` | int | No | New undelivered (open) quantity. `0` is treated like `NULL` (not provided). |\n\n- **Internal procedure not attached:** the definition of `pixi.SupplierOrderLineLocQtyUpdate` is not available. It is therefore unknown:\n - which tables it changes,\n - which validations it performs,\n - which columns its success result set has,\n - how it handles `NULL` for `Qty` or `UndeliveredQty` (probably \"leave unchanged\").\n- **Value `0` cannot be set:** because of the check `ISNULL(@Qty, '') = ''`, the value `0` is treated like \"not provided\" and passed on as `NULL`. The same applies to `UndeliveredQty`. Setting a quantity to `0` is therefore not possible through this call.\n- **Unused parameter:** `AppName` is required but not used by the code.\n- **Rollback on error:** if an error makes the transaction uncommittable, the code rolls back to the savepoint. SQL Server does not allow this for uncommittable transactions and may raise a further error.\n\nDocumentation: https://pixi-api-docs.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": "Updates the supplier price, estimated delivery date and comment of one supplier order line.\n\nUpdates a single supplier order line identified by `SupplierOrderLineId`. The actual update is delegated to the internal procedure `pixi.SupplierOrderLineUpdate`, which is called with `ReturnUpdatedIds = 1`.\n\nSteps:\n\n1. Opens a transaction, or sets a savepoint if the caller already has an open transaction.\n2. Resolves the user: if `UserId` is given it is used directly; otherwise the user is looked up by `UserName` via `inf.UserGetByName`. If that user name does not exist, the user `pixiAdministration` is used instead.\n3. Normalises the input values:\n - `SupplierPrice`: a value that equals an empty string is converted to `NULL`.\n - `EstimatedDeliveryDate`: the time part is removed, only the date is passed on.\n - `Comment`: an empty string is converted to `NULL`.\n4. Calls `pixi.SupplierOrderLineUpdate` with the user, the line ID and the three values.\n5. Commits the transaction it opened itself.\n\nIf any error occurs, the transaction or savepoint is rolled back and a single row with `ReturnCode` = `ERROR` and the SQL error message is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Required, but not used by the code. |\n| `UserId` | int | No | ID of the Pixi user performing the change. If omitted, the user is resolved from `UserName`. |\n| `UserName` | varchar(50) | Yes | Pixi user name. Used only if `UserId` is not given; unknown names fall back to `pixiAdministration`. |\n| `SupplierOrderLineId` | int | Yes | ID of the supplier order line to update. |\n| `SupplierPrice` | money | No | New supplier (purchase) price of the line. A value of `0` is converted to `NULL`. |\n| `EstimatedDeliveryDate` | datetime | No | New estimated delivery date. The time part is removed. |\n| `Comment` | nvarchar(2000) | No | New comment for the line. An empty string is converted to `NULL`. |\n\n- The internal procedure `pixi.SupplierOrderLineUpdate` is not attached. Which tables it changes, how `NULL` values are handled (e.g. whether `NULL` means \"leave unchanged\") and the exact columns of the success result set (requested via `ReturnUpdatedIds = 1`) cannot be derived from this code.\n- Pitfall: `SupplierPrice` is a `money` value compared with an empty string; SQL Server converts the empty string to `0`. A price of `0` is therefore turned into `NULL` and cannot be set explicitly.\n- Likewise an empty `Comment` becomes `NULL`, so it may not be possible to clear a comment with an empty string.\n- `EstimatedDeliveryDate` is truncated to the date; any time part is discarded.\n- `AppName` is required but not used by the code. `UserName` is required but only evaluated when `UserId` is not supplied.\n- Uses a named transaction or savepoint, so the call can safely run inside an outer transaction; on error only its own work is rolled back (unless the transaction is uncommittable).\n\nDocumentation: https://pixi-api-docs.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": "Updates the supplier price, estimated delivery date and comment of one supplier order line.\n\nUpdates a single supplier order line identified by `SupplierOrderLineId`. The actual update is delegated to the internal procedure `pixi.SupplierOrderLineUpdate`, which is called with `ReturnUpdatedIds = 1`.\n\nSteps:\n\n1. Opens a transaction, or sets a savepoint if the caller already has an open transaction.\n2. Resolves the user: if `UserId` is given it is used directly; otherwise the user is looked up by `UserName` via `inf.UserGetByName`. If that user name does not exist, the user `pixiAdministration` is used instead.\n3. Normalises the input values:\n - `SupplierPrice`: a value that equals an empty string is converted to `NULL`.\n - `EstimatedDeliveryDate`: the time part is removed, only the date is passed on.\n - `Comment`: an empty string is converted to `NULL`.\n4. Calls `pixi.SupplierOrderLineUpdate` with the user, the line ID and the three values.\n5. Commits the transaction it opened itself.\n\nIf any error occurs, the transaction or savepoint is rolled back and a single row with `ReturnCode` = `ERROR` and the SQL error message is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `AppName` | varchar(255) | Yes | Name of the calling application. Required, but not used by the code. |\n| `UserId` | int | No | ID of the Pixi user performing the change. If omitted, the user is resolved from `UserName`. |\n| `UserName` | varchar(50) | Yes | Pixi user name. Used only if `UserId` is not given; unknown names fall back to `pixiAdministration`. |\n| `SupplierOrderLineId` | int | Yes | ID of the supplier order line to update. |\n| `SupplierPrice` | money | No | New supplier (purchase) price of the line. A value of `0` is converted to `NULL`. |\n| `EstimatedDeliveryDate` | datetime | No | New estimated delivery date. The time part is removed. |\n| `Comment` | nvarchar(2000) | No | New comment for the line. An empty string is converted to `NULL`. |\n\n- The internal procedure `pixi.SupplierOrderLineUpdate` is not attached. Which tables it changes, how `NULL` values are handled (e.g. whether `NULL` means \"leave unchanged\") and the exact columns of the success result set (requested via `ReturnUpdatedIds = 1`) cannot be derived from this code.\n- Pitfall: `SupplierPrice` is a `money` value compared with an empty string; SQL Server converts the empty string to `0`. A price of `0` is therefore turned into `NULL` and cannot be set explicitly.\n- Likewise an empty `Comment` becomes `NULL`, so it may not be possible to clear a comment with an empty string.\n- `EstimatedDeliveryDate` is truncated to the date; any time part is discarded.\n- `AppName` is required but not used by the code. `UserName` is required but only evaluated when `UserId` is not supplied.\n- Uses a named transaction or savepoint, so the call can safely run inside an outer transaction; on error only its own work is rolled back (unless the transaction is uncommittable).\n\nDocumentation: https://pixi-api-docs.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": "Updates the header of a supplier delivery (note, external numbers, status, Picco/Mobix lock) by delivery ID or delivery number.\n\nUpdates one record in `SDelHeader` (supplier delivery header) and always returns exactly one row with the column `ReturnMSG`.\n\n**Identifying the delivery**\n- `SDelHkey` and `DeliveryNumber` are treated as missing when they are `0`. At least one of them is required.\n- If `SDelHkey` is given, it is used and `DeliveryNumber` is ignored.\n- Otherwise the delivery with `SDelHNr = DeliveryNumber` and the lowest key is used.\n\n**Validation**\n- `Status` must be `NEW`, `INV` or `CLS`, or be left out (`NULL`), which keeps the current status. An empty string is rejected.\n- If `ExternalReceiptNr` is given, no other delivery of the same Lieferant may already carry this external receipt number.\n- Without `PiccoUser`: the delivery must exist and must not be locked by Picco (`LockedByPicco` is not `Y`).\n- With `PiccoUser` (Mobix/Picco client): the delivery must exist and either be assigned to this `PiccoUser` or not be locked by Picco.\n\n**Field handling**\n- `Note`, `extInvoiceNr` and `extOrderNr` are trimmed. Empty or missing values keep the value already stored.\n- `ExternalReceiptNr` and `Status`: missing or empty values keep the stored value.\n- `UserName` defaults to `API` and is stored as the last updating user; the update date is set to the current time.\n- Picco information is always rewritten:\n - Without `PiccoUser`, the delivery's `PiccoUser` and `LockedByPicco` are cleared.\n - With `PiccoUser`, the user is stored and `LockedByPicco` is set to `Y` if `LockDelivery = 1`. If `Status = CLS`, both the Picco user and the lock are cleared.\n- `SupplNr` is obsolete. The supplier is never changed.\n\nIf the status actually changes, a delivery-status-changed event is published.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHkey` | int | No | Internal key of the delivery (`SDelHKey`). `0` is treated as not given. Takes precedence over `DeliveryNumber`. |\n| `SupplNr` | varchar(4) | No | Obsolete. Ignored; the Lieferant of the delivery is read from the header and never changed. |\n| `DeliveryNumber` | int | No | Delivery number (`SDelHNr`). Used only if `SDelHkey` is not given; `0` is treated as not given. |\n| `Note` | varchar(8000) | No | New note of the delivery. Trimmed; empty or missing keeps the stored note. |\n| `extInvoiceNr` | varchar(25) | No | External invoice number of the Lieferant. Trimmed; empty or missing keeps the stored value. |\n| `extOrderNr` | varchar(8000) | No | External order number(s). Trimmed; empty or missing keeps the stored value. Effectively limited to 1000 characters. |\n| `UserName` | varchar(50) | No | User stored as last editor. Defaults to `API`. |\n| `PiccoUser` | varchar(59) | No | Picco/Mobix user working on the delivery. Empty is treated as not given. If not given, the Picco assignment and lock are cleared. |\n| `Status` | varchar(3) | No | New delivery status. Missing keeps the current status; an empty string is rejected. |\n| `LockDelivery` | bit | No | Only with `PiccoUser`: `1` locks the delivery for this Picco user (`LockedByPicco = Y`) unless `Status` is `CLS`. |\n| `ExternalReceiptNr` | varchar(50) | No | External receipt number. Must be unique per Lieferant; empty or missing keeps the stored value. |\n\n- `Note`, `extInvoiceNr`, `extOrderNr` and `ExternalReceiptNr` cannot be cleared with this call. Empty values keep the existing content.\n- `extOrderNr` is declared as `varchar(8000)`, but the internal update procedure accepts only `varchar(1000)`. Longer values are truncated.\n- A call without `PiccoUser` removes an existing Picco user assignment from the delivery.\n- For a delivery locked by Picco, a call without `PiccoUser` fails with `Delivery header does not exist`, even though the delivery exists.\n- If `DeliveryNumber` matches no delivery, the same message is returned.\n- The procedure returns `-1` as its return value on errors. Errors are reported only as a `ReturnMSG` row, not as SQL errors.\n- Existence checks read `SDelHeader` with `NOLOCK`. No explicit transaction is used.\n- On a status change, `pixi_MQ_DeliveryStatusChanged_EventPublish` is executed. Its definition is not attached, so the details of the published message are unknown.\n- The exact business meaning of the status `INV` is not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Updates the header of a supplier delivery (note, external numbers, status, Picco/Mobix lock) by delivery ID or delivery number.\n\nUpdates one record in `SDelHeader` (supplier delivery header) and always returns exactly one row with the column `ReturnMSG`.\n\n**Identifying the delivery**\n- `SDelHkey` and `DeliveryNumber` are treated as missing when they are `0`. At least one of them is required.\n- If `SDelHkey` is given, it is used and `DeliveryNumber` is ignored.\n- Otherwise the delivery with `SDelHNr = DeliveryNumber` and the lowest key is used.\n\n**Validation**\n- `Status` must be `NEW`, `INV` or `CLS`, or be left out (`NULL`), which keeps the current status. An empty string is rejected.\n- If `ExternalReceiptNr` is given, no other delivery of the same Lieferant may already carry this external receipt number.\n- Without `PiccoUser`: the delivery must exist and must not be locked by Picco (`LockedByPicco` is not `Y`).\n- With `PiccoUser` (Mobix/Picco client): the delivery must exist and either be assigned to this `PiccoUser` or not be locked by Picco.\n\n**Field handling**\n- `Note`, `extInvoiceNr` and `extOrderNr` are trimmed. Empty or missing values keep the value already stored.\n- `ExternalReceiptNr` and `Status`: missing or empty values keep the stored value.\n- `UserName` defaults to `API` and is stored as the last updating user; the update date is set to the current time.\n- Picco information is always rewritten:\n - Without `PiccoUser`, the delivery's `PiccoUser` and `LockedByPicco` are cleared.\n - With `PiccoUser`, the user is stored and `LockedByPicco` is set to `Y` if `LockDelivery = 1`. If `Status = CLS`, both the Picco user and the lock are cleared.\n- `SupplNr` is obsolete. The supplier is never changed.\n\nIf the status actually changes, a delivery-status-changed event is published.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHkey` | int | No | Internal key of the delivery (`SDelHKey`). `0` is treated as not given. Takes precedence over `DeliveryNumber`. |\n| `SupplNr` | varchar(4) | No | Obsolete. Ignored; the Lieferant of the delivery is read from the header and never changed. |\n| `DeliveryNumber` | int | No | Delivery number (`SDelHNr`). Used only if `SDelHkey` is not given; `0` is treated as not given. |\n| `Note` | varchar(8000) | No | New note of the delivery. Trimmed; empty or missing keeps the stored note. |\n| `extInvoiceNr` | varchar(25) | No | External invoice number of the Lieferant. Trimmed; empty or missing keeps the stored value. |\n| `extOrderNr` | varchar(8000) | No | External order number(s). Trimmed; empty or missing keeps the stored value. Effectively limited to 1000 characters. |\n| `UserName` | varchar(50) | No | User stored as last editor. Defaults to `API`. |\n| `PiccoUser` | varchar(59) | No | Picco/Mobix user working on the delivery. Empty is treated as not given. If not given, the Picco assignment and lock are cleared. |\n| `Status` | varchar(3) | No | New delivery status. Missing keeps the current status; an empty string is rejected. |\n| `LockDelivery` | bit | No | Only with `PiccoUser`: `1` locks the delivery for this Picco user (`LockedByPicco = Y`) unless `Status` is `CLS`. |\n| `ExternalReceiptNr` | varchar(50) | No | External receipt number. Must be unique per Lieferant; empty or missing keeps the stored value. |\n\n- `Note`, `extInvoiceNr`, `extOrderNr` and `ExternalReceiptNr` cannot be cleared with this call. Empty values keep the existing content.\n- `extOrderNr` is declared as `varchar(8000)`, but the internal update procedure accepts only `varchar(1000)`. Longer values are truncated.\n- A call without `PiccoUser` removes an existing Picco user assignment from the delivery.\n- For a delivery locked by Picco, a call without `PiccoUser` fails with `Delivery header does not exist`, even though the delivery exists.\n- If `DeliveryNumber` matches no delivery, the same message is returned.\n- The procedure returns `-1` as its return value on errors. Errors are reported only as a `ReturnMSG` row, not as SQL errors.\n- Existence checks read `SDelHeader` with `NOLOCK`. No explicit transaction is used.\n- On a status change, `pixi_MQ_DeliveryStatusChanged_EventPublish` is executed. Its definition is not attached, so the details of the published message are unknown.\n- The exact business meaning of the status `INV` is not visible in the code.\n\nDocumentation: https://pixi-api-docs.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": "Updates an existing item line of a supplier delivery (quantity, purchase price, batch, best-before date), optionally matched to a purchase order line.\n\nChanges one existing line (`SDelDetail`) of a supplier delivery. The call never adds new lines. It only updates a line that already exists for the item on the delivery.\n\n1. **Find the delivery.** Pass `SDelHKey` or `DeliveryNumber` (`SDelHNr`). `SDelHSupplNr` can narrow the search. The first matching `SDelHeader` row is used. The call stops if:\n - no delivery matches,\n - the delivery status is `CLS` or `INV`,\n - the delivery is locked by Picco (`LockedByPicco` set) and `PiccoUser` differs from the user who holds the lock.\n\n After this step the delivery's own supplier number is used for everything else.\n2. **Find the item.** `fpixi_GetItemKey` resolves the item from `EANUPC`, or from `ItemNrInternal` if no EAN is given. It looks up scannable item codes (`pixi.ItemCode` joined with `ItemCodeType` where `Scannable = 1`). If both values are given, only `EANUPC` is used.\n3. **Optional purchase order match.** This step runs only if `InternalNumber` or `ExternalCode` is given. `InternalNumber` takes priority. The call searches `pixi.SupplierOrder` by `InternalNumber` or `ExternalCode` and checks rules `Error01` to `Error07`:\n - the external code must not appear on several orders of the delivery's supplier,\n - an order must be found,\n - the order must belong to the delivery's supplier,\n - the item must be on the order,\n - the order status must be allowed for delivery.\n\n Allowed statuses depend on the setting `ConfirmOrderedDocumentOnDelivery`: `0` uses statuses with `IsConfirmed = 1`, `1` uses statuses with `IsOrderedConfirmed = 1`. The matched order line id is then used to find the delivery line whose `SDelDsorderlineRef` points to that order line.\n4. **Find the delivery line without an order match.** All lines of the delivery for the item are read, filtered by `SdelDkey` if given. If there is no line, or more than one line and no `SdelDkey`, an error is returned.\n5. **Fill in missing values.** Parameters left empty keep the existing line values: delivered quantity, batch number, best-before date and order line reference. The ordered quantity is always taken from the existing line.\n6. **Update the purchase price.** If `SupplPrice` is not 0, `Pixi_SetAddItemsSupPrice` writes the price to the supplier item data (`AddItems`). This happens only for positive prices. The line then gets price, mid price and final price = `SupplPrice`, with discounts set to 0. If `SupplPrice` is 0, the existing prices of the line are kept.\n7. **Write the line.** `GOS_SDelDetailInsertOrUpdate` updates the line and returns it in full, including order statistics for the item.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | No | Internal key of the delivery (`SDelHeader.SDelHKey`). Either this or `DeliveryNumber` is required; 0 counts as not given. |\n| `DeliveryNumber` | int | No | Delivery number (`SDelHNr`). Alternative to `SDelHKey`; both can be combined as filters. |\n| `UserName` | varchar(50) | No | User name stored as the last editor of the delivery line (`SDelDupdateEmp`). |\n| `ItemNrInternal` | varchar(50) | No | Item identifier, looked up among scannable item codes. Used only if `EANUPC` is empty. Either this or `EANUPC` is required. |\n| `EANUPC` | varchar(13) | No | EAN/UPC of the item, looked up among scannable item codes. Takes priority over `ItemNrInternal`. |\n| `SDelHSupplNr` | varchar(4) | No | Optional supplier number filter for finding the delivery. Afterwards the supplier number of the found delivery is used. |\n| `DeliverdQty` | int | No | New delivered quantity. NULL or 0 keeps the existing quantity of the line. |\n| `SupplPrice` | money | No | New purchase price. If not 0, it is written to the line (price, mid price and final price; discounts are set to 0). Positive values are also stored in `AddItems`. 0 keeps the existing line prices. |\n| `PiccoUser` | varchar(50) | No | Picco user name. Required to update a delivery locked by Picco; it must match the locking user. |\n| `InternalNumber` | int | No | Internal number of a purchase order (`pixi.SupplierOrder.InternalNumber`). Used to match the delivery line to the order line. Takes priority over `ExternalCode`; 0 counts as not given. |\n| `ExternalCode` | varchar(50) | No | External code of a purchase order (`pixi.SupplierOrder.ExternalCode`). Used only if `InternalNumber` is empty. |\n| `BatchNumber` | varchar(50) | No | Batch number (Charge) for the line. NULL or empty keeps the existing value. |\n| `BestBeforeDate` | datetime | No | Best-before date for the line. NULL keeps the existing value. |\n| `SdelDkey` | int | No | Key of the delivery line (`SDelDetail.SDelDkey`). Required if the item occurs on several lines of the delivery. |\n\n- Empty-value handling: the code applies `NULLIF(x, '')` to `int` and `datetime` parameters, which turns `0` (and `1900-01-01` for `BestBeforeDate`) into NULL. As a result:\n - `DeliverdQty = 0` does not set the quantity to 0; the existing quantity is kept.\n - `SDelHKey = 0` and `InternalNumber = 0` count as not given.\n - Batch number and best-before date cannot be cleared; NULL or empty keeps the existing value.\n- `DeliverdQty` is declared as `int`, so fractional quantities are not possible through this call.\n- If `DeliveryNumber` matches several deliveries, an arbitrary one is used (`TOP (1)` without `ORDER BY`). Pass `SDelHKey` or `SDelHSupplNr` to be unambiguous.\n- Purchase order search is not limited to the delivery's supplier. If the same `ExternalCode` or `InternalNumber` also exists on an order of another supplier, `Error02` is returned.\n- If the setting `ConfirmOrderedDocumentOnDelivery` holds a value other than `0` or `1`, no status is allowed and `Error06` is always returned. Only the first character of the setting is evaluated. A missing setting counts as `0`.\n- When the order match is used together with `SdelDkey`, the given `SdelDkey` is the line that gets updated. It is not checked against the matched order line.\n- A negative `SupplPrice` is not written to `AddItems`, but it is still written to the delivery line.\n- `Pixi_SetAddItemsSupPrice` updates `AddItems.SupplPrice` for all supplier item records with the same `IntLinkNr1` and supplier number, not only for the delivered item.\n- If the setting `InsertAddItemOnSOrdersDragDrop` = `1` and the item has no `AddItems` record for the supplier, `GOS_SDelDetailInsertOrUpdate` creates one via `Pixi_InsertAddItemOnDelivery`. That procedure is not attached, so it is unknown whether it returns an additional result set.\n- Errors are returned as rows with a column `ERROR`. The procedure also returns `1` in that case. `Error04` is returned without a column alias.\n- No explicit transaction is used. Lookups use `NOLOCK`; the update uses `ROWLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Updates an existing item line of a supplier delivery (quantity, purchase price, batch, best-before date), optionally matched to a purchase order line.\n\nChanges one existing line (`SDelDetail`) of a supplier delivery. The call never adds new lines. It only updates a line that already exists for the item on the delivery.\n\n1. **Find the delivery.** Pass `SDelHKey` or `DeliveryNumber` (`SDelHNr`). `SDelHSupplNr` can narrow the search. The first matching `SDelHeader` row is used. The call stops if:\n - no delivery matches,\n - the delivery status is `CLS` or `INV`,\n - the delivery is locked by Picco (`LockedByPicco` set) and `PiccoUser` differs from the user who holds the lock.\n\n After this step the delivery's own supplier number is used for everything else.\n2. **Find the item.** `fpixi_GetItemKey` resolves the item from `EANUPC`, or from `ItemNrInternal` if no EAN is given. It looks up scannable item codes (`pixi.ItemCode` joined with `ItemCodeType` where `Scannable = 1`). If both values are given, only `EANUPC` is used.\n3. **Optional purchase order match.** This step runs only if `InternalNumber` or `ExternalCode` is given. `InternalNumber` takes priority. The call searches `pixi.SupplierOrder` by `InternalNumber` or `ExternalCode` and checks rules `Error01` to `Error07`:\n - the external code must not appear on several orders of the delivery's supplier,\n - an order must be found,\n - the order must belong to the delivery's supplier,\n - the item must be on the order,\n - the order status must be allowed for delivery.\n\n Allowed statuses depend on the setting `ConfirmOrderedDocumentOnDelivery`: `0` uses statuses with `IsConfirmed = 1`, `1` uses statuses with `IsOrderedConfirmed = 1`. The matched order line id is then used to find the delivery line whose `SDelDsorderlineRef` points to that order line.\n4. **Find the delivery line without an order match.** All lines of the delivery for the item are read, filtered by `SdelDkey` if given. If there is no line, or more than one line and no `SdelDkey`, an error is returned.\n5. **Fill in missing values.** Parameters left empty keep the existing line values: delivered quantity, batch number, best-before date and order line reference. The ordered quantity is always taken from the existing line.\n6. **Update the purchase price.** If `SupplPrice` is not 0, `Pixi_SetAddItemsSupPrice` writes the price to the supplier item data (`AddItems`). This happens only for positive prices. The line then gets price, mid price and final price = `SupplPrice`, with discounts set to 0. If `SupplPrice` is 0, the existing prices of the line are kept.\n7. **Write the line.** `GOS_SDelDetailInsertOrUpdate` updates the line and returns it in full, including order statistics for the item.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SDelHKey` | int | No | Internal key of the delivery (`SDelHeader.SDelHKey`). Either this or `DeliveryNumber` is required; 0 counts as not given. |\n| `DeliveryNumber` | int | No | Delivery number (`SDelHNr`). Alternative to `SDelHKey`; both can be combined as filters. |\n| `UserName` | varchar(50) | No | User name stored as the last editor of the delivery line (`SDelDupdateEmp`). |\n| `ItemNrInternal` | varchar(50) | No | Item identifier, looked up among scannable item codes. Used only if `EANUPC` is empty. Either this or `EANUPC` is required. |\n| `EANUPC` | varchar(13) | No | EAN/UPC of the item, looked up among scannable item codes. Takes priority over `ItemNrInternal`. |\n| `SDelHSupplNr` | varchar(4) | No | Optional supplier number filter for finding the delivery. Afterwards the supplier number of the found delivery is used. |\n| `DeliverdQty` | int | No | New delivered quantity. NULL or 0 keeps the existing quantity of the line. |\n| `SupplPrice` | money | No | New purchase price. If not 0, it is written to the line (price, mid price and final price; discounts are set to 0). Positive values are also stored in `AddItems`. 0 keeps the existing line prices. |\n| `PiccoUser` | varchar(50) | No | Picco user name. Required to update a delivery locked by Picco; it must match the locking user. |\n| `InternalNumber` | int | No | Internal number of a purchase order (`pixi.SupplierOrder.InternalNumber`). Used to match the delivery line to the order line. Takes priority over `ExternalCode`; 0 counts as not given. |\n| `ExternalCode` | varchar(50) | No | External code of a purchase order (`pixi.SupplierOrder.ExternalCode`). Used only if `InternalNumber` is empty. |\n| `BatchNumber` | varchar(50) | No | Batch number (Charge) for the line. NULL or empty keeps the existing value. |\n| `BestBeforeDate` | datetime | No | Best-before date for the line. NULL keeps the existing value. |\n| `SdelDkey` | int | No | Key of the delivery line (`SDelDetail.SDelDkey`). Required if the item occurs on several lines of the delivery. |\n\n- Empty-value handling: the code applies `NULLIF(x, '')` to `int` and `datetime` parameters, which turns `0` (and `1900-01-01` for `BestBeforeDate`) into NULL. As a result:\n - `DeliverdQty = 0` does not set the quantity to 0; the existing quantity is kept.\n - `SDelHKey = 0` and `InternalNumber = 0` count as not given.\n - Batch number and best-before date cannot be cleared; NULL or empty keeps the existing value.\n- `DeliverdQty` is declared as `int`, so fractional quantities are not possible through this call.\n- If `DeliveryNumber` matches several deliveries, an arbitrary one is used (`TOP (1)` without `ORDER BY`). Pass `SDelHKey` or `SDelHSupplNr` to be unambiguous.\n- Purchase order search is not limited to the delivery's supplier. If the same `ExternalCode` or `InternalNumber` also exists on an order of another supplier, `Error02` is returned.\n- If the setting `ConfirmOrderedDocumentOnDelivery` holds a value other than `0` or `1`, no status is allowed and `Error06` is always returned. Only the first character of the setting is evaluated. A missing setting counts as `0`.\n- When the order match is used together with `SdelDkey`, the given `SdelDkey` is the line that gets updated. It is not checked against the matched order line.\n- A negative `SupplPrice` is not written to `AddItems`, but it is still written to the delivery line.\n- `Pixi_SetAddItemsSupPrice` updates `AddItems.SupplPrice` for all supplier item records with the same `IntLinkNr1` and supplier number, not only for the delivered item.\n- If the setting `InsertAddItemOnSOrdersDragDrop` = `1` and the item has no `AddItems` record for the supplier, `GOS_SDelDetailInsertOrUpdate` creates one via `Pixi_InsertAddItemOnDelivery`. That procedure is not attached, so it is unknown whether it returns an additional result set.\n- Errors are returned as rows with a column `ERROR`. The procedure also returns `1` in that case. `Error04` is returned without a column alias.\n- No explicit transaction is used. Lookups use `NOLOCK`; the update uses `ROWLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Updates one supplier item record (AddItems) of an article: barcode, supplier price, supplier item number, preferred flag, MOQ, delivery time, active flag.\n\nUpdates exactly one supplier item row in `AddItems`. A supplier item is the combination of article, supplier and barcode (`EANUPC`).\n\nProcessing steps:\n\n1. `SupplNr` is mandatory. An empty string is treated as missing. The supplier is looked up in `Suppliers` by `SupplNr`, and an error row is returned if it does not exist.\n2. At least one update parameter must be set: `NewEAN`, `SupplPrice`, `ItemNrSuppl`, `PreferredSupplier`, `MinOrderQty`, `OnlyPU`, `ItemDeliveryTime` or `IsActive`. For `NewEAN` and `ItemNrSuppl`, an empty string counts as not set.\n3. The article is identified from `ItemKey`, `EAN` (barcode, code type 1) and/or `ItemNrInt` (shop item number, code type 2) via `pixi.ItemCode`. Each identifier that is passed must exist, and all of them must point to the same article. `ItemKey = 0` counts as not set.\n4. If `NewEAN` is passed, it must not already exist as a scannable code of another article.\n5. All supplier items of the article are loaded. The row to update is chosen by the resolved supplier and, if `EAN` is passed, by `EANUPC = EAN`. Exactly one row must match. If the supplier has several barcodes for the article, pass `EAN` to select the right row.\n6. If `NewEAN` is passed, no other supplier item of the same article may already have this barcode for the same `SupplNr`.\n7. If `PreferredSupplier = 1`, every other supplier item of the article that is currently preferred is set to `PreferredSupplier = 0`.\n8. The update runs in a transaction.\n\nOn the target row, only the passed values are changed. Values that are not passed keep their current content. In addition:\n\n- `UpdateDate` is set to the current time.\n- `RowVersion` is increased by 1.\n- `SupplPriceUpdateDate` is set to now if the new `SupplPrice` differs from the stored price.\n\nThe call returns one status row (`Status`, `Message`). On success, `Status` is `Record updated` and `Message` contains the resulting price, supplier item number and barcode of the target row.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal article ID used to identify the article. 0 is treated as not set. |\n| `ItemNrInt` | varchar(50) | No | Shop item number (code type 2 in `pixi.ItemCode`) used to identify the article. |\n| `EAN` | varchar(13) | No | Current barcode. Identifies the article (code type 1) and selects the supplier item row by `EANUPC`. Needed when the supplier has several barcodes for the article. |\n| `NewEAN` | varchar(13) | No | New barcode for `EANUPC`. It must not exist as a scannable code of another article, nor on another supplier item of the same article and supplier. An empty string keeps the current value. |\n| `SupplNr` | varchar(4) | Yes | Supplier number. Mandatory. Must exist in `Suppliers`. |\n| `SupplPrice` | money | No | New supplier (purchase) price. If it differs from the stored price, `SupplPriceUpdateDate` is set to now. |\n| `ItemNrSuppl` | varchar(50) | No | New supplier item number. An empty string keeps the current value. |\n| `PreferredSupplier` | bit | No | Sets or clears the preferred supplier flag. |\n| `MinOrderQty` | int | No | New minimum order quantity. |\n| `OnlyPU` | bit | No | New value for `OrderOnlyPackageUnits` (order only in package units). |\n| `ItemDeliveryTime` | int | No | New supplier delivery time (`SupplDeliveryTime`). |\n| `IsActive` | bit | No | Sets the `Active` flag of the supplier item. |\n\n- **Clearing values is not possible.** Parameters that are NULL, and empty strings for `NewEAN` and `ItemNrSuppl`, keep the existing value. A field cannot be set to NULL with this call.\n- **`EAN` has two roles.** It identifies the article: it must exist as a barcode (code type 1) in `pixi.ItemCode`. It also selects the `AddItems` row by `EANUPC`.\n- **`NewEAN` changes only `AddItems.EANUPC`.** The procedure does not update `pixi.ItemCode` directly. Whether triggers sync the code is not visible in this code.\n- **`PreferredSupplier = 0`** only clears the flag on the target row. No other supplier is made preferred.\n- **`SupplPriceUpdateDate`** is not updated if the stored price was NULL, because the comparison `SupplPrice <> @SupplPrice` is not true then.\n- **NULL messages.** If no supplier item is found and `ItemKey` was not passed, the error `Message` becomes NULL because of string concatenation with NULL. The same happens with the success `Message` if the resulting `SupplPrice` is NULL.\n- **Locking.** Reads on `Suppliers`, `pixi.ItemCode` and `AddItems` use `NOLOCK`. The update uses `ROWLOCK`.\n- **Transactions.** The procedure opens its own transaction, or sets a savepoint if a transaction is already open. On error it rolls back, writes a log entry through `log.InsertError` (definition not attached) and returns `ERROR_MESSAGE()` as a status row.\n- **Supplier lookup.** It uses `TOP (1)` on `Suppliers` by `SupplNr`.\n\nDocumentation: https://pixi-api-docs.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": "Updates one supplier item record (AddItems) of an article: barcode, supplier price, supplier item number, preferred flag, MOQ, delivery time, active flag.\n\nUpdates exactly one supplier item row in `AddItems`. A supplier item is the combination of article, supplier and barcode (`EANUPC`).\n\nProcessing steps:\n\n1. `SupplNr` is mandatory. An empty string is treated as missing. The supplier is looked up in `Suppliers` by `SupplNr`, and an error row is returned if it does not exist.\n2. At least one update parameter must be set: `NewEAN`, `SupplPrice`, `ItemNrSuppl`, `PreferredSupplier`, `MinOrderQty`, `OnlyPU`, `ItemDeliveryTime` or `IsActive`. For `NewEAN` and `ItemNrSuppl`, an empty string counts as not set.\n3. The article is identified from `ItemKey`, `EAN` (barcode, code type 1) and/or `ItemNrInt` (shop item number, code type 2) via `pixi.ItemCode`. Each identifier that is passed must exist, and all of them must point to the same article. `ItemKey = 0` counts as not set.\n4. If `NewEAN` is passed, it must not already exist as a scannable code of another article.\n5. All supplier items of the article are loaded. The row to update is chosen by the resolved supplier and, if `EAN` is passed, by `EANUPC = EAN`. Exactly one row must match. If the supplier has several barcodes for the article, pass `EAN` to select the right row.\n6. If `NewEAN` is passed, no other supplier item of the same article may already have this barcode for the same `SupplNr`.\n7. If `PreferredSupplier = 1`, every other supplier item of the article that is currently preferred is set to `PreferredSupplier = 0`.\n8. The update runs in a transaction.\n\nOn the target row, only the passed values are changed. Values that are not passed keep their current content. In addition:\n\n- `UpdateDate` is set to the current time.\n- `RowVersion` is increased by 1.\n- `SupplPriceUpdateDate` is set to now if the new `SupplPrice` differs from the stored price.\n\nThe call returns one status row (`Status`, `Message`). On success, `Status` is `Record updated` and `Message` contains the resulting price, supplier item number and barcode of the target row.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `ItemKey` | int | No | Internal article ID used to identify the article. 0 is treated as not set. |\n| `ItemNrInt` | varchar(50) | No | Shop item number (code type 2 in `pixi.ItemCode`) used to identify the article. |\n| `EAN` | varchar(13) | No | Current barcode. Identifies the article (code type 1) and selects the supplier item row by `EANUPC`. Needed when the supplier has several barcodes for the article. |\n| `NewEAN` | varchar(13) | No | New barcode for `EANUPC`. It must not exist as a scannable code of another article, nor on another supplier item of the same article and supplier. An empty string keeps the current value. |\n| `SupplNr` | varchar(4) | Yes | Supplier number. Mandatory. Must exist in `Suppliers`. |\n| `SupplPrice` | money | No | New supplier (purchase) price. If it differs from the stored price, `SupplPriceUpdateDate` is set to now. |\n| `ItemNrSuppl` | varchar(50) | No | New supplier item number. An empty string keeps the current value. |\n| `PreferredSupplier` | bit | No | Sets or clears the preferred supplier flag. |\n| `MinOrderQty` | int | No | New minimum order quantity. |\n| `OnlyPU` | bit | No | New value for `OrderOnlyPackageUnits` (order only in package units). |\n| `ItemDeliveryTime` | int | No | New supplier delivery time (`SupplDeliveryTime`). |\n| `IsActive` | bit | No | Sets the `Active` flag of the supplier item. |\n\n- **Clearing values is not possible.** Parameters that are NULL, and empty strings for `NewEAN` and `ItemNrSuppl`, keep the existing value. A field cannot be set to NULL with this call.\n- **`EAN` has two roles.** It identifies the article: it must exist as a barcode (code type 1) in `pixi.ItemCode`. It also selects the `AddItems` row by `EANUPC`.\n- **`NewEAN` changes only `AddItems.EANUPC`.** The procedure does not update `pixi.ItemCode` directly. Whether triggers sync the code is not visible in this code.\n- **`PreferredSupplier = 0`** only clears the flag on the target row. No other supplier is made preferred.\n- **`SupplPriceUpdateDate`** is not updated if the stored price was NULL, because the comparison `SupplPrice <> @SupplPrice` is not true then.\n- **NULL messages.** If no supplier item is found and `ItemKey` was not passed, the error `Message` becomes NULL because of string concatenation with NULL. The same happens with the success `Message` if the resulting `SupplPrice` is NULL.\n- **Locking.** Reads on `Suppliers`, `pixi.ItemCode` and `AddItems` use `NOLOCK`. The update uses `ROWLOCK`.\n- **Transactions.** The procedure opens its own transaction, or sets a savepoint if a transaction is already open. On error it rolls back, writes a log entry through `log.InsertError` (definition not attached) and returns `ERROR_MESSAGE()` as a status row.\n- **Supplier lookup.** It uses `TOP (1)` on `Suppliers` by `SupplNr`.\n\nDocumentation: https://pixi-api-docs.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": "Updates quantity, supplier price, comment, estimated delivery date or undelivered quantity of a supplier order line and recalculates the order totals.\n\nChanges a single line of a supplier order (purchase order), identified by `SorderlineKey` (`SupplierOrderLine.Id`).\n\n**Validation** (each failure returns one row with `ReturnCode = 'Error'` and nothing is changed):\n1. The line must exist.\n2. A non-zero `QtyNotDelivered` is only accepted if the supplier order has status `CON` (confirmed).\n3. If the supplier order has status `CON` or `CLS`, neither `SupplPrice` (not NULL) nor `OrderQty` (non-zero) may be passed.\n\n**Preparation**\n- `UserName` NULL becomes `API`; the user is resolved by name for the modification stamp.\n- `EstimatedDelivery` NULL keeps the current estimated delivery date of the line.\n- `QtyNotDelivered` passed explicitly as NULL keeps the current undelivered quantity.\n\n**Update** (performed by the internal procedure `GOS_SOrderlinesUpdate`):\n- Always: comment (`Comment` = `Note`), estimated delivery date, modification user/date and row version of the line.\n- Supplier order in an editable status (internal status id 1 or 2): `Qty` (an `OrderQty` of 0 keeps the current quantity), number of packaging units (quantity divided by packaging unit, rounded up), `SupplierPrice` (only if `SupplPrice` is non-zero), discount amount/percent and line total are recalculated.\n- Supplier order with status `CON` (internal status id 3): `UndeliveredQty` is set to `QtyNotDelivered`.\n- The order header (`SupplierOrder`) is recalculated: subtotal from all line totals, header discount, freight cost (reset to 0 if the free-of-freight limit is reached), total amount including the minimum order surcharge.\n- The location quantity record of the line (`SupplierOrderLineLocQty`) gets the quantity and, for status `CON`, the undelivered quantity.\n- If the line has an estimated delivery date after the update, the item is queued for a forced export to the shop.\n\nOn success one row with `ReturnCode = 'OK'` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SorderlineKey` | int | Yes | Id of the supplier order line (`SupplierOrderLine.Id`) to update. |\n| `UserName` | varchar(50) | Yes | Pixi user name stored as modifier. NULL is replaced by `API`. |\n| `OrderQty` | int | No | New order quantity. 0 or NULL keeps the current quantity. Only allowed while the supplier order is not in status `CON` or `CLS`. |\n| `Note` | varchar(1024) | No | Comment of the line. Always written; an empty value clears the existing comment. Must not contain single quotes. |\n| `QtyReceived` | int | No | Obsolete, ignored. |\n| `QtyNotDelivered` | int | No | Undelivered quantity. A non-zero value is only allowed if the supplier order has status `CON`; there it is written to `UndeliveredQty` (also the default 0). Explicit NULL keeps the current value. |\n| `EstimatedDelivery` | datetime | No | New estimated delivery date of the line. NULL keeps the current date. |\n| `SupplPrice` | decimal(9, 2) | No | New supplier price per unit. NULL or 0 keeps the current price. Only allowed while the supplier order is not in status `CON` or `CLS`. |\n\n- **Comment is always overwritten**: `Note` defaults to an empty string, so omitting it clears the existing comment of the line. Pass the current comment to keep it.\n- **Undelivered quantity in status `CON`**: `QtyNotDelivered` defaults to 0. For a confirmed order, omitting it sets `UndeliveredQty` to 0. Send it explicitly as NULL (nil) or with the current value to keep it.\n- `QtyReceived` is obsolete and ignored.\n- The line update is built as dynamic SQL; `Note` is concatenated without escaping, so a single quote (`'`) in the comment breaks the statement. SQL errors from the internal procedure come back as `SqlMessage`; the final `OK` row may still be returned in that case.\n- Internal status ids 1, 2 and 3 are used for the update branches; id 3 corresponds to `CON` according to a code comment. For other statuses (e.g. `CLS`) only comment and estimated delivery date are changed.\n- Discount recalculation divides by quantity × price for amount-based discounts (`DiscountType = 1`); a zero price or quantity with an existing discount can cause a division-by-zero error.\n- The shop export is triggered whenever the line has an estimated delivery date, even if `EstimatedDelivery` was not passed. The export procedure `Pixi_ExportItemChangesToShop` is not attached.\n- No explicit transaction; reads use `NOLOCK`, updates use `ROWLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Updates quantity, supplier price, comment, estimated delivery date or undelivered quantity of a supplier order line and recalculates the order totals.\n\nChanges a single line of a supplier order (purchase order), identified by `SorderlineKey` (`SupplierOrderLine.Id`).\n\n**Validation** (each failure returns one row with `ReturnCode = 'Error'` and nothing is changed):\n1. The line must exist.\n2. A non-zero `QtyNotDelivered` is only accepted if the supplier order has status `CON` (confirmed).\n3. If the supplier order has status `CON` or `CLS`, neither `SupplPrice` (not NULL) nor `OrderQty` (non-zero) may be passed.\n\n**Preparation**\n- `UserName` NULL becomes `API`; the user is resolved by name for the modification stamp.\n- `EstimatedDelivery` NULL keeps the current estimated delivery date of the line.\n- `QtyNotDelivered` passed explicitly as NULL keeps the current undelivered quantity.\n\n**Update** (performed by the internal procedure `GOS_SOrderlinesUpdate`):\n- Always: comment (`Comment` = `Note`), estimated delivery date, modification user/date and row version of the line.\n- Supplier order in an editable status (internal status id 1 or 2): `Qty` (an `OrderQty` of 0 keeps the current quantity), number of packaging units (quantity divided by packaging unit, rounded up), `SupplierPrice` (only if `SupplPrice` is non-zero), discount amount/percent and line total are recalculated.\n- Supplier order with status `CON` (internal status id 3): `UndeliveredQty` is set to `QtyNotDelivered`.\n- The order header (`SupplierOrder`) is recalculated: subtotal from all line totals, header discount, freight cost (reset to 0 if the free-of-freight limit is reached), total amount including the minimum order surcharge.\n- The location quantity record of the line (`SupplierOrderLineLocQty`) gets the quantity and, for status `CON`, the undelivered quantity.\n- If the line has an estimated delivery date after the update, the item is queued for a forced export to the shop.\n\nOn success one row with `ReturnCode = 'OK'` is returned.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SorderlineKey` | int | Yes | Id of the supplier order line (`SupplierOrderLine.Id`) to update. |\n| `UserName` | varchar(50) | Yes | Pixi user name stored as modifier. NULL is replaced by `API`. |\n| `OrderQty` | int | No | New order quantity. 0 or NULL keeps the current quantity. Only allowed while the supplier order is not in status `CON` or `CLS`. |\n| `Note` | varchar(1024) | No | Comment of the line. Always written; an empty value clears the existing comment. Must not contain single quotes. |\n| `QtyReceived` | int | No | Obsolete, ignored. |\n| `QtyNotDelivered` | int | No | Undelivered quantity. A non-zero value is only allowed if the supplier order has status `CON`; there it is written to `UndeliveredQty` (also the default 0). Explicit NULL keeps the current value. |\n| `EstimatedDelivery` | datetime | No | New estimated delivery date of the line. NULL keeps the current date. |\n| `SupplPrice` | decimal(9, 2) | No | New supplier price per unit. NULL or 0 keeps the current price. Only allowed while the supplier order is not in status `CON` or `CLS`. |\n\n- **Comment is always overwritten**: `Note` defaults to an empty string, so omitting it clears the existing comment of the line. Pass the current comment to keep it.\n- **Undelivered quantity in status `CON`**: `QtyNotDelivered` defaults to 0. For a confirmed order, omitting it sets `UndeliveredQty` to 0. Send it explicitly as NULL (nil) or with the current value to keep it.\n- `QtyReceived` is obsolete and ignored.\n- The line update is built as dynamic SQL; `Note` is concatenated without escaping, so a single quote (`'`) in the comment breaks the statement. SQL errors from the internal procedure come back as `SqlMessage`; the final `OK` row may still be returned in that case.\n- Internal status ids 1, 2 and 3 are used for the update branches; id 3 corresponds to `CON` according to a code comment. For other statuses (e.g. `CLS`) only comment and estimated delivery date are changed.\n- Discount recalculation divides by quantity × price for amount-based discounts (`DiscountType = 1`); a zero price or quantity with an existing discount can cause a division-by-zero error.\n- The shop export is triggered whenever the line has an estimated delivery date, even if `EstimatedDelivery` was not passed. The export procedure `Pixi_ExportItemChangesToShop` is not attached.\n- No explicit transaction; reads use `NOLOCK`, updates use `ROWLOCK`.\n\nDocumentation: https://pixi-api-docs.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": "Updates the master data, main contact, lock and disabled flags of an existing supplier identified by its supplier number.\n\nPerforms a partial update of one supplier in `Suppliers`, identified by `SupplNr`.\n\n1. Empty strings in most parameters are converted to `NULL`. `SupplCtry` is trimmed first. A parameter that is `NULL` or empty leaves the stored value unchanged (`ISNULL(new, old)`).\n2. The supplier is looked up by `SupplNr`. If it does not exist, an error row is returned.\n3. If `IsLocked = 1` or `IsDisabled = 1`, `SupplierNote` is mandatory. If it is given, a note with the title `Supplier Locked by UserId: {id}` or `Supplier Disabled by UserId: {id}` is inserted into `SupplierNote`. The user is the Pixi user `api`, or `pixiAdministration` if `api` does not exist. If both flags are 1, two notes are created.\n4. Within a transaction (or a savepoint if the caller already has an open transaction):\n - If the supplier has no `ContactId` yet, an empty `Contact` record is created and linked.\n - The supplier fields are updated. `UpdateDate` is set to the current time and `UpdateEmp` to `API`.\n - The linked contact is updated with the `MainContact_*` values.\n5. One status row is returned with `RowsAffected`, `ReturnCode`, `Message` and `ErrorMessage`.\n\n`CanDoDirectFulfillment` accepts `Y`/`N`. Other values leave the flag unchanged. `IsLocked = 0` and `IsDisabled = 0` unlock or enable the supplier without requiring a note.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | No | Supplier number of the supplier to update. Mandatory in practice; without it an error row is returned. |\n| `SupplName` | varchar(60) | No | New supplier name (`SupplName`). Empty or NULL keeps the current value. |\n| `SupplNameExt` | varchar(50) | No | Name extension (`SupplNameExt`). |\n| `SupplGroup` | varchar(4) | No | Supplier group. Declared but not used by the code. |\n| `DefaultDeliveryDays` | int | No | Default delivery time in days (`DefaultDeliveryDays`). The value 0 is treated as not provided. |\n| `SupplFaxNR` | varchar(100) | No | Fax number (`SupplFaxNr`). |\n| `CustNR` | varchar(20) | No | Own customer number at the supplier (`CustNr`). |\n| `eMail` | varchar(60) | No | General e-mail address, stored in `MailBox`. |\n| `SupAnrede` | varchar(20) | No | Salutation (`SupAnrede`). |\n| `SupName2` | varchar(60) | No | Second name line (`SupName2`). |\n| `SupAddress` | varchar(50) | No | Street address (`SupAddress`). |\n| `SupZip` | varchar(20) | No | Postal code (`SupZip`). |\n| `SupPhone1` | varchar(50) | No | First phone number (`SupPhone1`). |\n| `CanDoDirectFulfillment` | varchar(1) | No | Whether the supplier can do direct fulfillment (drop shipping). Any other value leaves the flag unchanged. |\n| `SupCity` | varchar(50) | No | City (`SupCity`). |\n| `SupPhone2` | varchar(50) | No | Second phone number (`SupPhone2`). |\n| `SupplCtry` | varchar(3) | No | Country code (`SupplCtry`). Leading and trailing spaces are trimmed. |\n| `CurrencyId` | smallint | No | Currency ID of the supplier (`CurrencyId`). The value 0 is treated as not provided. |\n| `eMailSupplOrder` | varchar(255) | No | E-mail address for supplier orders (`eMailSupplOrder`). |\n| `HomePageUrl` | nvarchar(2000) | No | Website URL (`HomePageUrl`). |\n| `MainContact_Title` | nvarchar(100) | No | Title of the main contact (`Contact.Title`). |\n| `MainContact_FirstName` | nvarchar(20) | No | First name of the main contact. |\n| `MainContact_LastName` | nvarchar(200) | No | Last name of the main contact. |\n| `MainContact_JobTitle` | nvarchar(200) | No | Job title of the main contact. |\n| `MainContact_JobFunction` | nvarchar(200) | No | Job function of the main contact. |\n| `MainContact_Phone` | varchar(200) | No | Phone number of the main contact. |\n| `MainContact_MobilePhone` | varchar(200) | No | Mobile phone number of the main contact. |\n| `MainContact_Fax` | nvarchar(200) | No | Fax number of the main contact. |\n| `MainContact_Email` | nvarchar(200) | No | E-mail address of the main contact. |\n| `SupplierComment` | varchar(8000) | No | Supplier comment, stored in `SupplComment`. |\n| `SupplierNote` | varchar(8000) | No | Body of the supplier note. Required when `IsLocked = 1` or `IsDisabled = 1`; otherwise not used. |\n| `IsDisabled` | bit | No | Sets the `Disabled` flag. NULL leaves it unchanged. |\n| `IsLocked` | bit | No | Sets the `Locked` flag. NULL leaves it unchanged. |\n\n- **Notes outside the transaction:** the `SupplierNote` insert for locking or disabling runs before the transaction starts. It is not rolled back if the later update fails. It is also attempted when the supplier does not exist; in that case `SupplierId` is `NULL`. Database errors from this insert are not caught and come back as `SqlMessage`.\n- **Missing `SupplNr`:** the message for an empty `SupplNr` is overwritten by the \"does not exist\" message. That message is built by concatenating `NULL`, so the result is `NULL`. The caller receives `ReturnCode = Error` with an empty or `NULL` `ErrorMessage`.\n- **Error precedence:** a missing-note error for lock/disable overrides the \"does not exist\" message in `ErrorMessage`.\n- **Zero values:** `DefaultDeliveryDays` and `CurrencyId` are compared with `''`, which converts to 0. The value `0` is therefore treated as \"not provided\" and cannot be set.\n- **Fields that cannot be cleared:** an empty string never clears a field, because it is treated as \"no change\".\n- **Unused parameter:** `SupplGroup` is declared but not used.\n- **Message text:** the generic message contains the typo `conntact`.\n- **Locking:** reads use `NOLOCK`, updates use `ROWLOCK`. `XACT_ABORT` is on. On a caught error, the transaction or savepoint is rolled back and an error row is returned.\n- **Contact update:** the contact's `RowVersion` is always set to 1.\n\nDocumentation: https://pixi-api-docs.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": "Updates the master data, main contact, lock and disabled flags of an existing supplier identified by its supplier number.\n\nPerforms a partial update of one supplier in `Suppliers`, identified by `SupplNr`.\n\n1. Empty strings in most parameters are converted to `NULL`. `SupplCtry` is trimmed first. A parameter that is `NULL` or empty leaves the stored value unchanged (`ISNULL(new, old)`).\n2. The supplier is looked up by `SupplNr`. If it does not exist, an error row is returned.\n3. If `IsLocked = 1` or `IsDisabled = 1`, `SupplierNote` is mandatory. If it is given, a note with the title `Supplier Locked by UserId: {id}` or `Supplier Disabled by UserId: {id}` is inserted into `SupplierNote`. The user is the Pixi user `api`, or `pixiAdministration` if `api` does not exist. If both flags are 1, two notes are created.\n4. Within a transaction (or a savepoint if the caller already has an open transaction):\n - If the supplier has no `ContactId` yet, an empty `Contact` record is created and linked.\n - The supplier fields are updated. `UpdateDate` is set to the current time and `UpdateEmp` to `API`.\n - The linked contact is updated with the `MainContact_*` values.\n5. One status row is returned with `RowsAffected`, `ReturnCode`, `Message` and `ErrorMessage`.\n\n`CanDoDirectFulfillment` accepts `Y`/`N`. Other values leave the flag unchanged. `IsLocked = 0` and `IsDisabled = 0` unlock or enable the supplier without requiring a note.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplNr` | varchar(4) | No | Supplier number of the supplier to update. Mandatory in practice; without it an error row is returned. |\n| `SupplName` | varchar(60) | No | New supplier name (`SupplName`). Empty or NULL keeps the current value. |\n| `SupplNameExt` | varchar(50) | No | Name extension (`SupplNameExt`). |\n| `SupplGroup` | varchar(4) | No | Supplier group. Declared but not used by the code. |\n| `DefaultDeliveryDays` | int | No | Default delivery time in days (`DefaultDeliveryDays`). The value 0 is treated as not provided. |\n| `SupplFaxNR` | varchar(100) | No | Fax number (`SupplFaxNr`). |\n| `CustNR` | varchar(20) | No | Own customer number at the supplier (`CustNr`). |\n| `eMail` | varchar(60) | No | General e-mail address, stored in `MailBox`. |\n| `SupAnrede` | varchar(20) | No | Salutation (`SupAnrede`). |\n| `SupName2` | varchar(60) | No | Second name line (`SupName2`). |\n| `SupAddress` | varchar(50) | No | Street address (`SupAddress`). |\n| `SupZip` | varchar(20) | No | Postal code (`SupZip`). |\n| `SupPhone1` | varchar(50) | No | First phone number (`SupPhone1`). |\n| `CanDoDirectFulfillment` | varchar(1) | No | Whether the supplier can do direct fulfillment (drop shipping). Any other value leaves the flag unchanged. |\n| `SupCity` | varchar(50) | No | City (`SupCity`). |\n| `SupPhone2` | varchar(50) | No | Second phone number (`SupPhone2`). |\n| `SupplCtry` | varchar(3) | No | Country code (`SupplCtry`). Leading and trailing spaces are trimmed. |\n| `CurrencyId` | smallint | No | Currency ID of the supplier (`CurrencyId`). The value 0 is treated as not provided. |\n| `eMailSupplOrder` | varchar(255) | No | E-mail address for supplier orders (`eMailSupplOrder`). |\n| `HomePageUrl` | nvarchar(2000) | No | Website URL (`HomePageUrl`). |\n| `MainContact_Title` | nvarchar(100) | No | Title of the main contact (`Contact.Title`). |\n| `MainContact_FirstName` | nvarchar(20) | No | First name of the main contact. |\n| `MainContact_LastName` | nvarchar(200) | No | Last name of the main contact. |\n| `MainContact_JobTitle` | nvarchar(200) | No | Job title of the main contact. |\n| `MainContact_JobFunction` | nvarchar(200) | No | Job function of the main contact. |\n| `MainContact_Phone` | varchar(200) | No | Phone number of the main contact. |\n| `MainContact_MobilePhone` | varchar(200) | No | Mobile phone number of the main contact. |\n| `MainContact_Fax` | nvarchar(200) | No | Fax number of the main contact. |\n| `MainContact_Email` | nvarchar(200) | No | E-mail address of the main contact. |\n| `SupplierComment` | varchar(8000) | No | Supplier comment, stored in `SupplComment`. |\n| `SupplierNote` | varchar(8000) | No | Body of the supplier note. Required when `IsLocked = 1` or `IsDisabled = 1`; otherwise not used. |\n| `IsDisabled` | bit | No | Sets the `Disabled` flag. NULL leaves it unchanged. |\n| `IsLocked` | bit | No | Sets the `Locked` flag. NULL leaves it unchanged. |\n\n- **Notes outside the transaction:** the `SupplierNote` insert for locking or disabling runs before the transaction starts. It is not rolled back if the later update fails. It is also attempted when the supplier does not exist; in that case `SupplierId` is `NULL`. Database errors from this insert are not caught and come back as `SqlMessage`.\n- **Missing `SupplNr`:** the message for an empty `SupplNr` is overwritten by the \"does not exist\" message. That message is built by concatenating `NULL`, so the result is `NULL`. The caller receives `ReturnCode = Error` with an empty or `NULL` `ErrorMessage`.\n- **Error precedence:** a missing-note error for lock/disable overrides the \"does not exist\" message in `ErrorMessage`.\n- **Zero values:** `DefaultDeliveryDays` and `CurrencyId` are compared with `''`, which converts to 0. The value `0` is therefore treated as \"not provided\" and cannot be set.\n- **Fields that cannot be cleared:** an empty string never clears a field, because it is treated as \"no change\".\n- **Unused parameter:** `SupplGroup` is declared but not used.\n- **Message text:** the generic message contains the typo `conntact`.\n- **Locking:** reads use `NOLOCK`, updates use `ROWLOCK`. `XACT_ABORT` is on. On a caught error, the transaction or savepoint is rolled back and an error row is returned.\n- **Contact update:** the contact's `RowVersion` is always set to 1.\n\nDocumentation: https://pixi-api-docs.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": "Updates status, note for the supplier, external order number and estimated delivery date of a supplier order identified by its internal number.\n\nChanges a supplier order (purchase order to a Lieferant) that is identified by `SupplierOrderNR` (the order's `InternalNumber`).\n\n**Steps**\n\n1. Empty strings in `Status` and `SupplierOrderNRExtdrnal` and an empty `Note` are treated as `NULL` (not passed).\n2. `UserName` must exist in the Pixi user table; otherwise an `ERROR` row is returned and an SQL error is raised.\n3. The order and its current status are loaded. If `Status` is not passed, the current status code of the order is used.\n4. Validation (each failure returns an `ERROR` row, nothing is changed):\n - the order must exist;\n - `Status` must be `NEW`, `BES`, `CON` or `CLS`;\n - a closed order (`CLS`) accepts no new `EstimatedDeliveryDate` and no new `SupplierOrderNRExtdrnal`;\n - a confirmed order (`CON`) accepts no new `SupplierOrderNRExtdrnal`;\n - no backward change from `CLS` to `NEW`/`BES`/`CON` and from `CON` to `NEW` (`CON` → `BES` is allowed);\n - no skipping: `NEW` cannot go directly to `CON` or `CLS`, and `BES` cannot go directly to `CLS`.\n5. The order header is updated:\n - status is set (`NEW`=1, `BES`=2, `CON`=3, `CLS`=4);\n - with `BES` the order date and ordering user are set to now/the calling user, with `CON` the confirmation date and confirming user;\n - external code, note for the supplier and estimated delivery date are only overwritten when a value is passed;\n - modification user and timestamp are set.\n6. If `EstimatedDeliveryDate` is passed, it is also written to **all** lines of the supplier order.\n7. If the status actually changed, the event `SupplierOrderStatusChanged` is published with the internal order `Id`.\n8. A single row with `ReturnCode` = `Ok` is returned and the transaction is committed.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplierOrderNR` | int | Yes | Internal number (`InternalNumber`) of the supplier order to update. |\n| `Status` | varchar(3) | No | New status code. If omitted or empty, the current status is kept (and re-applied). |\n| `Note` | text | No | Note for the supplier (`NoteForSupplier`). Replaces the stored note if not empty. |\n| `EstimatedDeliveryDate` | datetime | No | Estimated delivery date; written to the order header and to all order lines. Not allowed on closed orders. |\n| `SupplierOrderNRExtdrnal` | varchar(25) | No | External order number of the supplier (`ExternalCode`). Not allowed on confirmed or closed orders. |\n| `UserName` | varchar(50) | No | Pixi user name recorded as modifying (and ordering/confirming) user. Must exist. |\n\n- **Pitfall – dates are reset:** because an omitted `Status` falls back to the current status, every call on an order in status `BES` sets `OrderDate`/`OrderedByUserId` again to now and the calling user; on an order in `CON` the same happens to `ConfirmationDate`/`ConfirmedByUserId`. This also applies when only the note or the delivery date is changed.\n- Fields cannot be cleared: an empty or omitted value keeps the stored value. An `EstimatedDeliveryDate` of `1900-01-01` is treated as not passed.\n- The note is still accepted on closed orders; only delivery date and external number are blocked.\n- The code comment says `NEW` cannot be set again, but the code only blocks `NEW` from `CON`/`CLS`; a change `BES` → `NEW` is accepted.\n- `SupplierOrderNRExtdrnal` is limited to 25 characters by the parameter type. The note is stored in a non-Unicode column, so characters outside the database code page may be lost.\n- Status IDs 1–4 are hard-coded in the procedure.\n- Because of operator precedence in the validation, a backward/skip status error can override an earlier validation message; the call still fails in either case.\n- Runs in its own transaction (or a savepoint if an outer transaction exists). Errors are caught, rolled back and written to the error log; except for the user check, no SQL error is raised, only the `ERROR` row is returned. When called inside an outer transaction, no `Ok` row is returned and no commit is done.\n- The initial lookup of the order reads with `NOLOCK`.\n- The status change event is published via `Pixi_MQ_EventPublish`; whether a message is actually sent depends on the setting `pixiMQ_Enabled` and the event configuration.\n\nDocumentation: https://pixi-api-docs.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": "Updates status, note for the supplier, external order number and estimated delivery date of a supplier order identified by its internal number.\n\nChanges a supplier order (purchase order to a Lieferant) that is identified by `SupplierOrderNR` (the order's `InternalNumber`).\n\n**Steps**\n\n1. Empty strings in `Status` and `SupplierOrderNRExtdrnal` and an empty `Note` are treated as `NULL` (not passed).\n2. `UserName` must exist in the Pixi user table; otherwise an `ERROR` row is returned and an SQL error is raised.\n3. The order and its current status are loaded. If `Status` is not passed, the current status code of the order is used.\n4. Validation (each failure returns an `ERROR` row, nothing is changed):\n - the order must exist;\n - `Status` must be `NEW`, `BES`, `CON` or `CLS`;\n - a closed order (`CLS`) accepts no new `EstimatedDeliveryDate` and no new `SupplierOrderNRExtdrnal`;\n - a confirmed order (`CON`) accepts no new `SupplierOrderNRExtdrnal`;\n - no backward change from `CLS` to `NEW`/`BES`/`CON` and from `CON` to `NEW` (`CON` → `BES` is allowed);\n - no skipping: `NEW` cannot go directly to `CON` or `CLS`, and `BES` cannot go directly to `CLS`.\n5. The order header is updated:\n - status is set (`NEW`=1, `BES`=2, `CON`=3, `CLS`=4);\n - with `BES` the order date and ordering user are set to now/the calling user, with `CON` the confirmation date and confirming user;\n - external code, note for the supplier and estimated delivery date are only overwritten when a value is passed;\n - modification user and timestamp are set.\n6. If `EstimatedDeliveryDate` is passed, it is also written to **all** lines of the supplier order.\n7. If the status actually changed, the event `SupplierOrderStatusChanged` is published with the internal order `Id`.\n8. A single row with `ReturnCode` = `Ok` is returned and the transaction is committed.\n\n| Parameter | Type | Required | Description |\n| --- | --- | --- | --- |\n| `SupplierOrderNR` | int | Yes | Internal number (`InternalNumber`) of the supplier order to update. |\n| `Status` | varchar(3) | No | New status code. If omitted or empty, the current status is kept (and re-applied). |\n| `Note` | text | No | Note for the supplier (`NoteForSupplier`). Replaces the stored note if not empty. |\n| `EstimatedDeliveryDate` | datetime | No | Estimated delivery date; written to the order header and to all order lines. Not allowed on closed orders. |\n| `SupplierOrderNRExtdrnal` | varchar(25) | No | External order number of the supplier (`ExternalCode`). Not allowed on confirmed or closed orders. |\n| `UserName` | varchar(50) | No | Pixi user name recorded as modifying (and ordering/confirming) user. Must exist. |\n\n- **Pitfall – dates are reset:** because an omitted `Status` falls back to the current status, every call on an order in status `BES` sets `OrderDate`/`OrderedByUserId` again to now and the calling user; on an order in `CON` the same happens to `ConfirmationDate`/`ConfirmedByUserId`. This also applies when only the note or the delivery date is changed.\n- Fields cannot be cleared: an empty or omitted value keeps the stored value. An `EstimatedDeliveryDate` of `1900-01-01` is treated as not passed.\n- The note is still accepted on closed orders; only delivery date and external number are blocked.\n- The code comment says `NEW` cannot be set again, but the code only blocks `NEW` from `CON`/`CLS`; a change `BES` → `NEW` is accepted.\n- `SupplierOrderNRExtdrnal` is limited to 25 characters by the parameter type. The note is stored in a non-Unicode column, so characters outside the database code page may be lost.\n- Status IDs 1–4 are hard-coded in the procedure.\n- Because of operator precedence in the validation, a backward/skip status error can override an earlier validation message; the call still fails in either case.\n- Runs in its own transaction (or a savepoint if an outer transaction exists). Errors are caught, rolled back and written to the error log; except for the user check, no SQL error is raised, only the `ERROR` row is returned. When called inside an outer transaction, no `Ok` row is returned and no commit is done.\n- The initial lookup of the order reads with `NOLOCK`.\n- The status change event is published via `Pixi_MQ_EventPublish`; whether a message is actually sent depends on the setting `pixiMQ_Enabled` and the event configuration.\n\nDocumentation: https://pixi-api-docs.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"
}
]
}
]
}
]
}