WMS (Warehouse Management)

Podkatalog WMS zawiera model kanoniczny dla magazynowania: Warehouse (profil Location, category = warehouse), Inventory (stan na lokalizacji), InventoryDocument (dokument ruchu – zmiana ilości, własności, lokalizacji), PurchaseRequisition (zapotrzebowanie) i ReturnDocument (zlecenie zwrotu). Lokalizacje są modelem ogólnym – Location w katalogu głównym; w magazynie używa się profili Warehouse i StorageLocation oraz partOf (magazyn → oddział). Spójny z ProductDefinition.

Zasoby

Zasób	Opis
Warehouse	Magazyn i miejsce składowania = Location w profilach Warehouse i StorageLocation (category); partOf = przypisanie magazynu do oddziału
Location	Zasób ogólny w katalogu głównym – miejsce (magazyn, oddział, miejsce użytkowania). W magazynie: profile Warehouse i StorageLocation, managingParty (Party), partOf = hierarchia, attribute[] = cechy
Inventory	Stan: product (ProductDefinition) + location (Location) + quantity (Quantity); opcjonalnie period (na dzień)
PurchaseRequisition	Zapotrzebowanie (rekwizycja) przekazywane z systemu zewnętrznego do magazynu – nagłówek + pozycje zagnieżdżone; bez cen
InventoryDocument	Jedyny zasób ruchu magazynowego — GR (receipt), GI (issue), transfer, adjustment; position[] = pozycje zagnieżdżone w dokumencie
ReturnDocument	Zlecenie zwrotu towaru: nagłówek (owner/participant/symbol) + pozycje zwrotu z ilością i powiązaniem do dokumentu wydania

Operacje

Zasób	Metody	Uwagi
Location	GET /v1/locations	profile Warehouse, StorageLocation, UsagePlace
Inventory	GET /v1/inventories	filtry location, product
InventoryDocument	GET /v1/inventory-documents?type=…, POST /v1/inventory-documents?type=…\|intents	type wymagany: receipt, issue-document, movement-document, issue-adjustment
PurchaseRequisition	GET, POST /v1/purchase-requisitions	zapis przyjmuje pełny dokument
ReturnDocument	POST /v1/return-documents	brak odczytu; zapis przetwarza pierwszą pozycję
ProductDefinition	GET /v1/product-definitions	katalog asortymentu

Listy mają kopertę { "items": [...], "nextToken": null } i paginację count/offset; zapis odpowiada kodem 200.

Relacje

• Warehouse = Location w profilu Warehouse; w InventoryDocument fromLocation/toLocation nagłówka wskazują magazyn, participant — miejsca składowania (Location) i dostawcę (Party).
• Location – profile Warehouse i StorageLocation, hierarchia przez partOf (pojedyncza referencja); na pozycji InventoryDocument: fromLocation, toLocation (jawne skąd/dokąd).
• Inventory – product, location, quantity; stan aktualizowany na podstawie InventoryDocument (ruch).
• PurchaseRequisition – zapotrzebowanie jednostki; realizowane rozchodem (InventoryDocument, movementType = issue).
• ReturnDocument — zlecenie zwrotu towaru; pozycje mogą wskazywać dokument i pozycję wydania źródłowego.

Relacje biznesowe i realizacja procesów

Obiekty i ich rola

Obiekt	Rola biznesowa
PurchaseRequisition + pozycje	Zapotrzebowanie zgłoszone przez oddział — czego i ile potrzebuje (per pozycja). Nagłówek + pozycje.
InventoryDocument (movementType = issue) + pozycje	Rozchód z apteki na oddział, realizujący zapotrzebowanie — co i ile faktycznie wydano (per pozycja), skąd/dokąd.
InventoryDocument.position[].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[] zawierają pozycje w treści dokumentu; pozycja nie ma własnego endpointu.
• Rozchód → zapotrzebowanie: InventoryDocument.position[].basedOn[] wskazuje realizowane pozycje zapotrzebowań referencją type = PurchaseRequisitionPosition z identyfikatorem w systemie source-purchase-requisition-position-id (identyfikator pozycji nadany po stronie magazynu; zasób PurchaseRequisition nie publikuje go w treści pozycji). Kierunek zawsze realizacja → żądanie (jak SupplyDelivery.basedOn → SupplyRequest).
• Brak nawigacji odwrotnej: API nie udostępnia parametru wyszukiwania po basedOn; pokrycie pozycji zapotrzebowania odczytuje się z PurchaseRequisition.position[].fulfilledQuantity.

Potrzeby klienta i jak są realizowane

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

Potrzeba klienta	Realizacja w modelu
Jedna pozycja rozchodu realizuje kilka pozycji zapotrzebowań	basedOn to lista referencji (dziś magazyn zwraca jedną referencję na pozycję)
Pozycje z różnych zapotrzebowań w jednym rozchodzie	każda referencja niesie tożsamość pozycji, 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 InventoryDocument.position[].quantity; stan pokrycia po stronie żądania śledzi PurchaseRequisition.position[].fulfilledQuantity

Kontekst dokumentowy nagłówek↔nagłówek (InventoryDocument.relatedDocument) jest dziś wypełniany tylko dla przyjęć (faktura zakupu) i korekt (dokument korygowany); rozchody nie niosą referencji do dokumentu zapotrzebowania.

Przepływ

flowchart LR
    subgraph Oddzial["Oddział — zapotrzebowanie"]
        PR["PurchaseRequisition"]
        PRP1["position #1"]
        PRP2["position #2"]
        PR --> PRP1
        PR --> PRP2
    end
    subgraph Apteka["Apteka — rozchód (issue)"]
        ID["InventoryDocument"]
        IDP1["position #1"]
        IDP2["position #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 pozycji #2 — realizacja częściowa/współdzielona.)