Postman-Collection
Reports Lesen

pixiReport_LogisticQuality

Liefert die Verteilung der Aufträge der letzten Tage nach Anzahl der Tage zwischen Auftragseingang und erster Lieferung als Logistik-Kennzahl.

Berechnet, wie viele Tage der Versand der Aufträge der letzten Tage gedauert hat, und gruppiert die Aufträge nach dieser Anzahl.

1. Auswahl der Aufträge

Ein Auftrag wird berücksichtigt, wenn:

  • sein Orderheader.CreateDate höchstens @DaysBack Tage zurückliegt;
  • er mindestens eine Auftragsposition im Status ANG oder AUS hat. Ist @ShopID nicht leer, muss zusätzlich die OrdShopId der Position passen;
  • er keine Position im Status ANG/AUS hat (angelegt innerhalb von @DaysBack Tagen, gleicher Shop-Filter), deren Artikel vor Anlage der Position keinen in InvBinItemLog gebuchten Bestand hatte;
  • der Kunde nicht gesperrt ist (HSLocked = 'Y' in CustomersHist).

Als Bezugsdatum des Auftrags gilt das früheste StatusChangeDate eines ANG-Eintrags in Orderhistory zu seinen Positionen.

2. Bestandsprüfung

Die Prozedur sammelt alle Positionen der ausgewählten Aufträge. Ein Auftrag wird entfernt, wenn für einen seiner Artikel die summierte Menge aller gesammelten Positionen höher ist als der bis zum Bezugsdatum in InvBinItemLog gebuchte Bestand. Summiert werden nur Positionen, die bis zu diesem Datum angelegt und nicht vorher (oder noch gar nicht) versendet wurden.

3. Datumsanpassungen

  • Wochenende (mit DATEFIRST 1): Aufträge von Freitag nach 14:59 Uhr werden um 3 Tage verschoben. Samstagsaufträge werden um 2 Tage, Sonntagsaufträge um 1 Tag verschoben. Die Uhrzeit bleibt gleich.
  • Tage ohne Versand: Ein Tag gilt als Versandtag, wenn es an ihm innerhalb von @DaysBack Tagen mehr als 2 Rechnungen mit total > 0 gibt. Ein Auftrag, dessen ursprünglicher Eingangstag kein Versandtag ist, erhält ein neues Bezugsdatum: den frühesten Rechnungszeitpunkt des nächsten Versandtags. Dies ersetzt die Wochenendanpassung.

4. Berechnung

Je Auftrag ist DaysToShip die ganzzahlige Anzahl von 24-Stunden-Intervallen vom angepassten Bezugsdatum bis zum frühesten ShipDate seiner Positionen. Negative Werte werden auf 0 gesetzt.

Nicht versendete Aufträge werden ausgeschlossen, sowohl aus der Gruppierung als auch aus der Gesamtzahl AllPackages.

5. Ergebnis

Eine Zeile je DaysToShip-Wert mit:

  • der Anzahl Aufträge;
  • ihrem Anteil an AllPackages;
  • der Gesamtzahl AllPackages.

Zusätzlich wird immer eine feste Zeile mit DaysToShip = 99 und 0 Aufträgen angehängt. Die Zeilen sind aufsteigend nach DaysToShip sortiert.

Hinweise

  • Die Parameter @OnlyItemsOnStock und @MinutesSinceRefresh sind deklariert, werden im Code aber nicht verwendet.
  • @ShopID filtert auf das Positionsfeld OrdShopId, nicht auf den Auftragskopf.
  • Laut Code-Kommentar gilt Freitag ab 14:00 Uhr. Der Code prüft hour > 14, die Wochenendverschiebung beginnt also erst ab 15:00 Uhr.
  • Der Kommentar bezeichnet die ermittelten Tage als „Feiertage“ (Tage ohne Versand). Tatsächlich enthält die Tabelle Tage mit mehr als 2 Rechnungen. Aufträge von allen anderen Tagen werden auf den ersten Rechnungszeitpunkt des nächsten solchen Tags verschoben. Gibt es keinen späteren Versandtag, wird das Bezugsdatum NULL und der Auftrag zählt als nicht versendet.
  • Enthält CustomersHist.HCustRef NULL-Werte, schließt der NOT IN-Filter alle Aufträge aus.
  • Die Zeile mit DaysToShip = 99 ist eine feste Markierungszeile mit NRofORders = 0 und Percentage = 0. Sie wird immer geliefert, auch wenn kein Auftrag die Bedingungen erfüllt.
  • Percentage ist ein Anteil zwischen 0 und 1, kein Prozentwert.
  • Die meisten Lesezugriffe nutzen NOLOCK, die Zahlen können daher nicht festgeschriebene Daten enthalten. Der erste Zugriff auf Orderheader erfolgt ohne NOLOCK.
  • Die Prozedur verwendet viele korrelierte Unterabfragen auf Orderhistory, Orderlines und InvBinItemLog. Große Werte für @DaysBack können langsam sein.
  • Die Prozedur schreibt nur in temporäre Tabellen.

Parameter

Parameter Typ Standardwert Beschreibung
DaysBack
int 14

Anzahl Tage ab heute rückwärts. Ältere Aufträge, Auftragspositionen und Rechnungen werden nicht berücksichtigt.

Beispiel: 14

OnlyItemsOnStock
bit
boolean
1

Deklariert, aber im Code nicht verwendet. Die Bestandsprüfungen werden immer angewendet.

Beispiel: 1

ShopID
varchar(3)
string
–

Shop-Filter auf OrdShopId der Auftragspositionen. Leer oder NULL bedeutet alle Shops.

Beispiel: SH1

MinutesSinceRefresh
int NULL

Deklariert, aber im Code nicht verwendet.

Antwort

Result-Set 1 · Immer

Verteilung der versendeten Aufträge nach Versandtagen. Eine feste Markierungszeile mit DaysToShip = 99 ist immer enthalten. Aufsteigend nach DaysToShip sortiert.

Spalte Typ Beschreibung
DaysToShip
Kann leer sein
int

Ganze Tage (24-Stunden-Intervalle) vom angepassten Auftragseingang bis zur ersten Lieferung. 99 kennzeichnet die feste Zusatzzeile.

The NULL case is theoretically possible via the 999 fallback but rows with NULL are filtered out.

Hinweis: NULL-Werte werden ausgefiltert.

NRofORders int

Anzahl Aufträge, die nach dieser Anzahl Tage versendet wurden. In der Markierungszeile immer 0.

Percentage float
decimal

Anteil an AllPackages als Bruch zwischen 0 und 1. In der Markierungszeile immer 0.

AllPackages
Kann leer sein
float
decimal

Gesamtzahl der ausgewerteten, versendeten Aufträge.

Beispiele

POST https://apigateway.descartes.com/tms/pixi/
Content-Type: text/xml; charset=utf-8
Authorization: Basic BASE64(USERNAME:PASSWORD)

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="https://apigateway.descartes.com/tms/pixi/">
  <SOAP-ENV:Body>
    <ns1:pixiReport_LogisticQuality>
      <!-- <DaysBack>14</DaysBack> -->
      <!-- <OnlyItemsOnStock>1</OnlyItemsOnStock> -->
      <!-- <ShopID>SH1</ShopID> -->
      <!-- <MinutesSinceRefresh>?</MinutesSinceRefresh> -->
    </ns1:pixiReport_LogisticQuality>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Verwendete Tabellen

Orderheader · Lesen Orderhistory · Lesen Orderlines · Lesen Items · Lesen InvBinItemLog · Lesen CustomersHist · Lesen Invoices · Lesen
SQL-Objekt:
dbo.pipiReport_LogisticQuality
Prozedur zuletzt geändert am 2026-10-05
Dokumentation von claude-opus-5-5 am 2026-10-30 geschrieben