Przejdź do treści

Attribute

Attribute (atrybut) to typ danych oznaczający cechę opisaną kodem (rodzaj) i wartością – np. jednostka miary, stawka VAT, producent, suma netto, schemat bazy. Używany w ProductDefinition (cechy definicji: jednostka, VAT, producent, grupa), DocumentReference (attribute[] – atrybuty dokumentu, np. podsumowanie pozycji: suma netto, VAT, brutto), Location (attribute[] – cechy lokalizacji) i w każdym innym zasobie przez dziedziczone attribute[] z DomainResource. Jedna struktura: code (rodzaj atrybutu) + value[] (lista ValueItem) — typ danych niosący opcjonalny rodzaj wartości (type: CodeableConcept) oraz jeden wariant: valueQuantity, valueMoney, valueString, valueInteger, valueBoolean, valueCodeableConcept lub valueReference. Wzorowany na podejściu code + value[x] z FHIR (Observation.component).

Attribute nie jest zasobem (DomainResource) – jest typem zagnieżdżonym w tablicy attribute[] zasobów. W sensie DDD to Value Object: brak własnej identyfikacji (id), tożsamość wyłącznie przez wartość (code + value), zagnieżdżenie w rodzicu.

1. Zakres i zastosowanie

Attribute służy do:

  • Cech definicji produktu – w ProductDefinition: unit-of-measure, vat-rate, producer, product-group, atc, pharmaceutical-form itd. (code + value z wariantem valueCodeableConcept, valueQuantity dla ilości/miar, valueMoney dla kwot, valueReference dla odniesień); słownik product-definition-attribute-type: wspólny · retail · warehouse.
  • Atrybuty dokumentu – w DocumentReference (attribute[]): np. podsumowanie pozycji – total-net, total-vat, total-gross (valueMoney), forma i termin płatności, daty księgowe; słownik document-attribute-type: finance · hr · warehouse.
  • Cechy lokalizacji – w Location (attribute[]): np. czy magazyn księgowy (valueBoolean), kod dla księgowości (valueString); słownik location-attribute-type: assets · warehouse.
  • Rozszerzalności – nowe rodzaje atrybutów przez code (system zależny od zasobu i dziedziny: <zasób>-attribute-type z segmentem finance/warehouse/assets/hr/retail) bez zmiany struktury.

Reguła na poziomie modelu: code (0..1) i value (0.., lista ValueItem). W każdym ValueItem jest jeden wariant value*; opcjonalnie type* precyzuje rodzaj wartości (np. net, gross). Profil konformance może zawęzić dopuszczalne warianty dla konkretnego kodu cechy.

2. Zawartość (struktura)

Nazwa Kard. Typ Opis
code 0..1 CodeableConcept Rodzaj atrybutu; URI systemu dobierany wg kontekstu zasobu (patrz code-systems i IG zasobu nadrzędnego)
value 0..* ValueItem Wartości cechy – każda z opcjonalnym type (CodeableConcept) oraz jednym wariantem value* (patrz tabela ValueItem poniżej)

ValueItem (struktura wartości)

ValueItem to typ polimorficzny: opcjonalny type precyzujący rodzaj wartości (np. net, gross) oraz jeden wariant value* (wzór jak value[x] w FHIR). W JSON Schema wszystkie warianty są opcjonalnymi polami; reguła „jeden wariant" jest konwencją, nie ograniczeniem schematu.

Nazwa Kard. Typ Opis
type 0..1 CodeableConcept Typ składnika wartości (np. net, gross) – słownik value-item-type: finance · warehouse
valueBoolean 0..1 boolean Wartość logiczna
valueString 0..1 string Tekst lub data (np. ISO 8601)
valueInteger 0..1 integer Liczba całkowita
valueQuantity 0..1 Quantity Ilość / miara niepieniężna (UCUM)
valueMoney 0..1 Money Kwota pieniężna
valueCodeableConcept 0..1 CodeableConcept Wartość kodowana (np. stawka VAT 23%, kategoria)
valueReference 0..1 Reference Odniesienie (np. producent → Party)

Reguła: jeden wariant value* w ValueItem; opcjonalnie type. Dla dat używa się valueString (ISO 8601) lub valueCodeableConcept.

3. Przykłady code (system zależny od zasobu)

  • ProductDefinition: unit-of-measure, vat-rate, producer, product-group, atc, pharmaceutical-form, strength (system product-definition-attribute-type).
  • DocumentReference: total-net, total-vat, total-gross (warehouse); payment-method, due-date, accounting-date (finance); external-system-name, operator-login (hr).
  • Location: is-accounting, warehouse-account-fk, zsmopl (warehouse); schema (assets).

4. Zgodność atrybutów z systemami ERP

Model atrybutów (code + value[]: ValueItem) pozwala uzupełnić dane z systemów ERP i odwrotnie – bez utraty informacji.

System Odpowiednik cech Mapowanie
SAP Characteristic (CLASS), Batch (Charge), Serial Number; Material master – jednostka, grupa, VAT code → Char. name / tabela; value[].valueQuantity/valueMoney/valueString → wartość; value[].valueReference → np. producent (Vendor/BP)
Oracle EBS / Fusion Descriptive Flexfields (DFF), Item Attributes; Lot/Serial; UOM, Category, VAT code → DFF segment / Item Attribute; value[].value* → wartość; value[].type → precyzja wariantu (np. net/gross)
UBL 2.3 Item Property (Name, Value); ClassifiedTaxCategory; AdditionalItemProperty code → Item Property name; value[].valueString/valueCodeableConcept/valueQuantity → Value
OAGIS Item IDs, Quantity, Amount, Classification; Lot/Serial w BOD code → Classification/Property; value[].value* → wartość; ProductDefinition.attribute ↔ Item master
FHIR Observation.component (code + value[x]); Medication (batch, expirationDate) Bezpośrednie: code + value (ValueItem odpowiada value[x] z opcjonalnym type); warianty valueQuantity, valueCodeableConcept, valueString, valueReference

Podsumowanie: Ten sam zestaw danych (jednostka, VAT, producent, grupa, cechy niestandardowe) da się wyrazić w naszym modelu i w SAP/Oracle/UBL/OAGIS. Różnice dotyczą nazewnictwa (code/system) i miejsca przechowania – mapowanie jest możliwe w obie strony; atrybuty pozwalają uzupełnić dane z ERP (import do API) i eksportować do ERP (export z API).

5. Odniesienia