Przejdź do treści

WMS (Warehouse Management)

Podkatalog WMS zawiera model kanoniczny dla magazynowania: Warehouse (jako Location z type=warehouse), Inventory (stan na lokalizacji), InventoryDocument (dokument ruchu – zmiana ilości, własności, lokalizacji). Lokalizacje są modelem ogólnym – Location w katalogu głównym; w WMS używa się Location z type=warehouse dla magazynu i partOf (hierarchia magazyn → strefa → regał → bin). Spójny z Product / ProductDefinition.

Zasoby

Zasób Opis
Warehouse Magazyn = Location (type=warehouse); identyfikator, nazwa, adres; hierarchia przez partOf
Location Zasób ogólny w katalogu głównym – miejsce (magazyn, biuro, oddział). W WMS: Location z type=warehouse dla magazynu, managingParty (Party), partOf = hierarchia, attribute[] = cechy
Inventory Stan: product (ProductDefinition lub Product) + location (Location) + quantity (Quantity); opcjonalnie period (na dzień)
PurchaseRequisition Zapotrzebowanie (rekwizycja) przekazywane z EOD do ASW/WMS – nagłówek + referencje do pozycji; bez cen
PurchaseRequisitionPosition Osobny zasób — pozycja zapotrzebowania (produkt + ilość żądana) z własną tożsamością (id/identifier); adresowalna, by móc ją referować z realizacji
InventoryDocument Jedyny zasób ruchu magazynowego — GR (receipt), GI (issue), transfer, adjustment; position[] = referencje do InventoryDocumentPosition.
InventoryDocumentPosition Osobny zasób — pozycja ruchu (product, quantity delta, fromLocation, toLocation) z własną tożsamością; basedOn = realizowane pozycje zapotrzebowań

Relacje

  • Warehouse = Location z type=warehouse; w InventoryDocument participant (Reference do Location/magazyn, dostawca, odbiorca).
  • Location – w kontekście WMS: typ=warehouse dla magazynu, hierarchia przez partOf; w InventoryDocument / InventoryDocumentPosition: fromLocation, toLocation (jawne skąd/dokąd).
  • Inventory – product, location, quantity; stan aktualizowany na podstawie InventoryDocument (ruch).
  • InventoryDocument — GR, GI, przesunięcie, korekta; model operacji magazynowych (/v1/inventory-documents).

Relacje biznesowe i realizacja procesów

Obiekty i ich rola

Obiekt Rola biznesowa
PurchaseRequisition + PurchaseRequisitionPosition Zapotrzebowanie zgłoszone przez oddział — czego i ile potrzebuje (per pozycja). Nagłówek + referencje do pozycji.
InventoryDocument (movementType = issue) + InventoryDocumentPosition Rozchód z apteki na oddział, realizujący zapotrzebowanie — co i ile faktycznie wydano (per pozycja), skąd/dokąd.
InventoryDocumentPosition.basedOn Powiązanie realizacji na poziomie linii: która pozycja rozchodu pokrywa którą pozycję zapotrzebowania.

Zasada powiązań (spójna z FHIR)

Wszystkie powiązania są jednokierunkowe (brak referencji dwukierunkowych) i zapisane po stronie „dziecka"/realizacji:

  • Dokument → pozycje: InventoryDocument.position[] i PurchaseRequisition.position[] to listy referencji do osobnych zasobów pozycji (nagłówek nie zawiera treści pozycji).
  • Rozchód → zapotrzebowanie: InventoryDocumentPosition.basedOn[] wskazuje realizowane pozycje zapotrzebowań. Kierunek zawsze realizacja → żądanie (jak SupplyDelivery.basedOn → SupplyRequest).
  • Kierunek odwrotny = zapytanie, nie pole zwrotne (patrz niżej).

Potrzeby klienta i jak są realizowane

Powiązanie zapotrzebowania z wydaniem w KS‑ASW zachodzi na poziomie pozycji, a nie nagłówka, i jest wiele‑do‑wielu. Model odwzorowuje to wprost przez InventoryDocumentPosition.basedOn:

Potrzeba klienta Realizacja w modelu
Jedna pozycja rozchodu realizuje kilka pozycji zapotrzebowań basedOn to lista referencji
Pozycje z różnych zapotrzebowań w jednym rozchodzie każda referencja niesie tożsamość pozycji (a przez nią — swojego zapotrzebowania), więc mieszają się swobodnie
Każda pozycja rozchodu do innej pozycji/zapotrzebowania basedOn jest per pozycja rozchodu
Część pozycji rozchodu bez powiązania basedOn puste dla tych pozycji
Realizacja częściowa ilość realnie wydana jest w InventoryDocumentPosition.quantity; stan pokrycia po stronie żądania śledzi PurchaseRequisitionPosition.fulfilledQuantity

Zgrubny kontekst dokumentowy (nagłówek↔nagłówek) pozostaje w InventoryDocument.relatedDocument (np. do dokumentu zapotrzebowania) — komplementarnie, nie zamiast basedOn.

Przepływ

flowchart LR
    subgraph Oddzial["Oddział — zapotrzebowanie"]
        PR["PurchaseRequisition"]
        PRP1["PurchaseRequisitionPosition #1"]
        PRP2["PurchaseRequisitionPosition #2"]
        PR --> PRP1
        PR --> PRP2
    end
    subgraph Apteka["Apteka — rozchód (issue)"]
        ID["InventoryDocument"]
        IDP1["InventoryDocumentPosition #1"]
        IDP2["InventoryDocumentPosition #2"]
        ID --> IDP1
        ID --> IDP2
    end
    IDP1 -- "basedOn" --> PRP1
    IDP1 -- "basedOn" --> PRP2
    IDP2 -- "basedOn" --> PRP2

(Przykład M:N: pozycja rozchodu #1 realizuje dwie pozycje zapotrzebowania; pozycja #2 dokłada się do PRP #2 — realizacja częściowa/współdzielona.)

Zapytania (nawigacja odwrotna)

  • Wydania realizujące dane zapotrzebowanie → filtr rozchodów po position.basedOn wskazującym pozycje tego zapotrzebowania.
  • Do którego dokumentu należy pozycja → filtr dokumentów po position wskazującym tę pozycję.
  • Pokrycie pozycji zapotrzebowania → PurchaseRequisitionPosition.fulfilledQuantity względem quantity.