Location (lokalizacja)
Location (lokalizacja) to zasób reprezentujący dowolne miejsce fizyczne – niezależnie od kontekstu: magazyn, strefa/regał/półka w magazynie, biuro, oddział, budynek, piętro, pomieszczenie itd. Location ma managingParty (Reference Party – podmiot zarządzający miejscem) i dziedziczone owner (Reference Party – właściciel organizacyjny). Hierarchia miejsc jest budowana przez partOf (Location nadrzędny). Dodatkowe cechy w attribute[] (Attribute). Pojedynczy model dla magazynu, kadr, majątku, organizacji, nieruchomości.
Rozszerza DomainResource.
1. Zakres i zastosowanie
Location = pojedyncze miejsce: identifier, name, managingParty (0..1 Reference do Party – zarządca miejsca: firma, organizacja, osoba, jednostka organizacyjna), owner (0.. Reference do Party – właściciel; z DomainResource), partOf (0..1 Reference do Location – hierarchia miejsc), attribute[] (0.. Attribute – cechy miejsca). type lub category (z DomainResource) określają rodzaj: np. magazyn, miejsce składowania (magazyn); biuro, oddział, budynek, piętro, pomieszczenie (organizacja/kadry); w ewidencji majątku miejsce użytkowania oznaczamy kodem usage-place.
- Magazyn – magazyn to Location w profilu
Warehouse(category=warehouse), miejsce składowania (apteka centralna, oddział) w profiluStorageLocation(category=storage-location); partOf = przypisanie magazynu do oddziału; managingParty = Party prowadząca miejsce. Szczegóły: Warehouse. - Hierarchia – partOf = Location nadrzędna (brak partOf = szczebel najwyższy); tożsamość (identifier, name) bezpośrednio w Location.
- Biuro / oddział – Location jako biuro lub centrala: owner = Party (organizacja/oddział), partOf = budynek → piętro → pomieszczenie. Employment, Position mogą referować Location (miejsce pracy).
- Majątek (miejsce użytkowania) – Location w profilu
UsagePlace(category=usage-place); alokacja środka do miejsca odbywa się przez FixedAssetAllocation. Gdy alokacja dotyczy lokalizacji, osoby odpowiedzialne są przekazywane osobno wparticipant[]po stronie FixedAssetAllocation. - Ruch magazynowy – w pozycjach InventoryDocument (
position[]) pola fromLocation / toLocation referują Location; uczestnicy magazynu także przez InventoryDocument.participant.
2. Struktura (pola)
Poza polami z DomainResource (id, resourceType, meta, owner, comment, category, status, type, contained, attribute):
| Nazwa | Kard. | Typ | Opis |
|---|---|---|---|
| identifier | 0..* | Identifier | Identyfikatory lokalizacji: id lokalizacji lub magazynu w przestrzeni ResourceLocation.Id (klucz referencyjny; system z NamingSystem) |
| managingParty | 0..1 | Reference(Party) | Strona zarządzająca – referencja do Party zarządzającej lokalem (firma, organizacja, osoba, jednostka organizacyjna) |
| name | 0..1 | string | Nazwa lokalizacji (np. „Strefa A – regał 1", „Biuro 301", „Magazyn główny – półka A-02-15") |
| partOf | 0..1 | Reference(Location) | Lokalizacja nadrzędna (hierarchia: magazyn → strefa → regał lub budynek → piętro → pomieszczenie) |
Uwaga: owner (0.., z DomainResource) wskazuje właściciela / podmiot organizacyjny (firma, organizacja, oddział). category (z DomainResource) niesie profil: warehouse, storage-location, usage-place (słowniki location-category: warehouse · assets). type* doprecyzowuje rodzaj miejsca (warehouse/location-type). Atrybuty (attribute[]) – location-attribute-type: assets · warehouse.
2a. Profile lokalizacji
Jeden zasób Location ma trzy profile (StructureDefinition): Warehouse (magazyn), StorageLocation (miejsce składowania) i UsagePlace (miejsce użytkowania środka trwałego). Profil rozpoznaje się po meta.profile oraz po category (warehouse, storage-location, usage-place), które nadaje API.ERP; w schematach profili category jest wymagane. Schematy profili: profile kanoniczne.
GET /v1/locations?profile=https://api-erp.kamsoft.pl/ns/StructureDefinition/Warehouse
GET /v1/locations?profile=https://api-erp.kamsoft.pl/ns/StructureDefinition/UsagePlace
Bez profile odpowiedź zawiera lokalizacje wszystkich obsługiwanych profili.
3. Operacje
Parametry filtrów mają postać system|value (attribute: code|value); podany filtr zawęża odpowiedź albo kończy się 400, gdy jego przestrzeń nie należy do słowników zasobu (konwencje §8.1). Odpowiedź to koperta { "items": [...], "nextToken": null }, stronicowana parametrami count (domyślnie 20) i offset (domyślnie 0).
| Operacja | Parametry | Odpowiedź |
|---|---|---|
GET /v1/locations |
profile, identifier, owner, attribute[], contained, type, category, count, offset |
200 koperta z Location[] |
Filtry kodowane type i category rozpoznaje się po trzech słownikach zadeklarowanych dla zasobu: warehouse/location-type, warehouse/location-category i assets/location-category. Przestrzeń spoza nich kończy żądanie statusem 400 z nazwą parametru.
Zasób jest tylko do odczytu; brak POST/PATCH i tras z {id}.
4. Użycie międzymodułowe
- Magazyn: Strefy magazynowe, półki, lokalizacje składowania
- Kadry: Lokalizacje biur, oddziały
- Księgowość: Adresy biur, centra operacyjne
- Majątek: Miejsca użytkowania środków trwałych
- CRM: Lokalizacje biur sprzedaży, centra serwisowe
5. Mapowanie na systemy ERP
| System | Odpowiednik magazynowy | Odpowiednik Org/Biuro | Uwagi |
|---|---|---|---|
| SAP EWM | Storage Section, Storage Bin | Jednostka organizacyjna, Miejsce pracy, Lokalizacja MPK | owner / managingParty = Party (magazyn/org); partOf = hierarchia |
| Oracle WMS | Location, Subinventory | HR Location, Facility | Location z parent; owner = Facility/Party |
| D365 | Location (strefa, alejka, regał, półka) | Jednostka operacyjna, Oddział | Pojedynczy Location dla obu kontekstów; type rozróżnia |
| FHIR | – | Location (miejsce) | partOf; nasz model rozszerza o owner, managingParty, attribute |
6. Powiązane zasoby
→ Party — Informacje o właścicielu/zarządcy
→ Core Master Data Overview — Wspólne dane główne