Address
Address (adres) to typ danych oznaczający adres pocztowy lub lokalizacyjny jako listę komponentów typu CodeableConcept. Wzorowany na FHIR Address. Używany w Party (siedziba, adres dostawy, rozliczeniowy), w OrganizationUnit (adres siedziby jednostki), w dokumentach (miejsce dostawy, wystawienia).
1. Zakres i zastosowanie
Address służy do:
- Adresów stron – w Party: siedziba, adres do faktury, adres dostawy (type / use).
- Dokumentów – miejsce dostawy, miejsce wystawienia (np. w profilu FK/CRM).
- Lokalizacji – w rozszerzeniach: współrzędne, region.
Reguła: component[] jako lista elementów adresu typu CodeableConcept – każdy składnik ma coding z kodem rodzaju składnika i text z wartością (np. kod street, text „Marszałkowska”). use i type są opcjonalne i opisywane przez CodeableConcept.
2. Zawartość (struktura)
| Nazwa | Kard. | Typ | Opis |
|---|---|---|---|
| use | 0..1 | CodeableConcept | Przeznaczenie adresu; słownik address-use nie ma jeszcze kodów – coding niesie sam system, znaczenie w text (np. „Siedziba”) |
| type | 0..1 | CodeableConcept | Typ adresu – słownik address-type: permanent (adres stały), temporary (tymczasowy), mailing (do korespondencji) |
| component | 0..* | CodeableConcept | Składniki adresu – słownik address-component-type: country, province, district, commune, locality, street, building-number, flat-number, postal-code, TERYT-code; wartość składnika w text |
3. Zgodność z systemami ERP
| System | Odpowiednik | Uwagi |
|---|---|---|
| SAP | Business Address Service (BAS), BAPIADDR3 / adres w BAPICONTACT_ADDRESSDATA | Street, city, postal code, region, country; osobne struktury na adres BP i Contact Person; adresy powiązane z relacją (np. contact person address) |
| Oracle TCA | HZ_LOCATIONS (street1/2/3, city, postal_code, state, country) + HZ_PARTY_SITES (powiązanie Party–Location) | Adres = Location; Party ma wiele Party Sites, każdy wskazuje Location; use/type przez atrybuty strony |
| UBL 2.3 | Address (AddressLine, CityName, PostalZone, CountrySubentity, Country) | AddressLine 1..*; PostalAddress jako agregat; brak use/type w bazie – kontekst z elementu nadrzędnego |
| OAGIS | Address w PartyMaster / Location; elementy adresowe w BOD | Adresy w komponencie Party; wiele lokalizacji; Contact jako osobny komponent (komunikacja) |
| FHIR | Address (use, type, line, city, district, state, postalCode, country, period, text) | use: home | work | temp | old | billing; type: postal | physical | both; line 0..*; period na ważność |
Nasz model jest zbieżny semantycznie z FHIR Address, ale reprezentuje dane jako listę komponentów (component[] jako CodeableConcept). SAP i Oracle trzymają adres w osobnych tabelach/strukturach z linkiem do strony/kontaktu; UBL/OAGIS – w strukturze dokumentu lub Party.
4. Równoważność zestawu danych
Tak – ten sam zestaw danych da się zamodelować w Twoim rozwiązaniu i w systemach ERP.
| Aspekt | Twój model / FHIR | SAP / Oracle / UBL / OAGIS |
|---|---|---|
| Linie i elementy adresu | component[] (CodeableConcept) |
street1/2/3, AddressLine 1..* – równoważne semantycznie |
| Miasto, kod, kraj | component z kodami locality/postal-code/country |
Wszędzie obecne |
| Region / województwo | component z kodem province (także district, commune, TERYT-code) |
state, CountrySubentity, region – ten sam sens |
| Przeznaczenie (billing, delivery…) | use, type w adresie | Często w kontekście (np. „adres dostawy” = miejsce w strukturze) – dane te same |
| Adres jako tekst | Składany z component[] |
FHIR ma Address.text; można go złożyć z komponentów |
Różnice to reprezentacja (use/type w obiekcie vs kontekst), nie brak informacji. Mapowanie w obie strony jest możliwe.