Przejdź do treści

Document

Document (dokument) to zasób reprezentujący dokument biznesowy w wielu przestrzeniach systemowych: CRM, FK (finanse/księgowość), WHS (magazyn), EOD (elektroniczny obieg dokumentów), HR oraz innych. Składa się z dwóch części: głównej (nagłówek dokumentu) oraz position (pozycje/segmenty), wzorowanych na FHIR Observation.component – dzięki temu w dedykowanej przestrzeni można modelować właściwości dla faktury, zamówienia, dokumentów księgowych, dokumentów z HR i CRM bez mnożenia typów zasobów. Identyfikacja przez Identifier, typ i przestrzeń przez CodeableConcept, uczestników (strony) przez participant – referencje do Party / PartyRole. Atrybuty dokumentu (np. podsumowanie pozycji: suma netto, VAT, brutto) w attribute[]. Wzorowany na OAGIS (BOD), UBL 2.3, SAP (nagłówek + pozycje), FHIR (Observation + component, DocumentReference, Composition), GS1.

Rozszerza DomainResource. Zasób z pakietu Kamsoft.FAIR (Fast Adaptive Interoperable Resources).

1. Dwie części dokumentu: główna i position (pozycje)

  • Część główna – dane na poziomie dokumentu: identyfikatory, typ dokumentu, przestrzeń, status, data wystawienia, uczestnicy (participant), powiązane dokumenty, attribute[] (atrybuty, np. podsumowanie pozycji). Wspólna dla wszystkich przestrzeni; profile mogą dodawać pola (np. daty, kwoty zagregowane) tylko w części głównej.
  • Position (pozycje) – tablica position (0..), każdy element to jedna pozycja lub segment dokumentu (wiersz faktury, pozycja zamówienia, dekret księgowy, linia podsumowania VAT, segment HR, segment CRM itd.). Każda pozycja ma code (CodeableConcept) – rodzaj segmentu – oraz w profilu danej przestrzeni zdefiniowaną strukturę (kwoty, ilości, konta, produkty, referencje). Podobnie jak w FHIR Observation: Observation ma component[], każdy component ma code (typ) i value[x] (wynik); tu Document ma position[], każda ma code (typ pozycji/segmentu), a szczegółowe właściwości (amount, quantity, account, product…) są definiowane w profilu dla danej przestrzeni i dla danego code*. Dzięki temu faktura, zamówienie, dokument księgowy, dokument HR/CRM używają tego samego kanonicznego Document z różnymi zestawami position i różną strukturą position w profilach.

Pozostałe elementy części głównej: identyfikacja (identifier[]), type (z DomainResource – typ dokumentu), issueDate, uczestnicy (participant), powiązane dokumenty (relatedDocument), attribute[] – jak poniżej w tabeli. Wszystkie inne daty i pola domenowe należą do profilu. Referencje do produktu, kontrahenta, magazynu itd. w pozycjach dokumentu są w position → DocumentPosition → valueReference (zob. DocumentPosition, sekcja „Referencja do produktu”).

2. Zawartość (struktura)

Oprócz elementów DomainResource (id, meta, text, comment, category, status, type, contained, attribute):

Nazwa Kard. Typ Opis
identifier 0..* Identifier Identyfikatory dokumentu (numer, origin-id, symbol systemu, numer korekty itd. – rodzaj w type)
issueDate 0..1 date Data wystawienia (wspólna dla dokumentów)
participant 0..* Reference(Party lub PartyRole) + role (CodeableConcept) Uczestnicy dokumentu (wystawca, odbiorca, płatnik…); rola przy każdej referencji lub w osobnym polu w profilu
relatedDocument 0..* Reference(Document) lub Identifier Powiązane dokumenty (korekta, źródło, zamówienie)
position 0..* DocumentPosition Pozycje / segmenty dokumentu (wiersze, dekretacje, podsumowania VAT, segmenty HR/CRM…); struktura w DocumentPosition, szczegóły per przestrzeń w profilu
attribute 0..* Attribute Atrybuty dokumentu (np. podsumowanie pozycji: suma netto, suma VAT, suma brutto dla faktury); code + value*
attachment 0..* Attachment Załączniki do dokumentu (skan, PDF, plik)
statusDate 0..1 dateTime Data ostatniej zmiany statusu (uniwersalna dla dowolnego dokumentu)
expectedDate 0..1 date Oczekiwana data (np. realizacji, dostawy – zamówienie, WHS)
realizationDate 0..1 date Data realizacji (zamówienie, dostawa, WHS)

Uwaga: W rdzeniu Document są tylko pola uniwersalne dla wszystkich typów dokumentów (CRM, FK, WHS, EOD, HR). Pola specyficzne dla danej przestrzeni (np. faktury, PZ/WZ) definiuje profil – zob. sekcja 2a poniżej.

2a. Pola w profilach (nie w rdzeniu)
Dla dokumentów FK (faktura, dokument kasowy itd.) profil może dodawać m.in.: paymentMethod, paymentAccount (Reference BankAccount), accountingDate, dueDate, receiptDate, saleDate, vatDate, ksefAcquisitionDate, totalAmount, splitPayment, register (CodeableConcept). Szczegółowe mapowanie faktury na Document oraz pola wynikające z przepisów prawa (art. 106e ustawy o VAT) i struktury FA używanej przy KSeF — jako weryfikacja, że format mieści się w obiekcie — opisuje Faktura i KSeF (Document). Dla zamówień i dokumentów HR stosuje się rdzeń Document i odpowiedni zestaw position oraz attribute[] / profil. W kontekście WMS kanonicznym dokumentem ruchu (PZ, WZ, przesunięcie, korekta) jest InventoryDocument – zasób zorientowany na zmianę (ilość, własność, lokalizacja) z movementType i jawnymi fromLocation/toLocation na pozycjach.

3. Przestrzenie (CRM, FK, WHS, EOD, HR)

Przestrzeń Przykłady typów dokumentów Position (segment) – przykłady code
CRM Oferta, zamówienie sprzedaży, umowa order-line, offer-line, contact-segment – w profilu: produkt, ilość, cena, termin realizacji
FK Faktura, dokument kasowy, dokument przychodzący, dekret invoice-line, decree-line, vat-summary-line – w profilu: kwoty, konta, VAT, rejestr
WHS Zapotrzebowania oraz powiązania z procesami magazynowymi; ruch magazynowy (PZ, WZ, przesunięcie) → InventoryDocument order-line, request-line; dla ruchu magazynowego: InventoryDocument z movementType i from/to
EOD Dokument w obiegu, zatwierdzenie, wersja workflow-segment – powiązania z dokumentami źródłowymi
HR Dokument kadrowy, umowa o pracę, szkolenie hr-segment – w profilu: właściwości dla danej kategorii dokumentu HR

Dokument może być identyfikowany w więcej niż jednej domenie (np. faktura w FK i jej „kopia” w EOD) – wtedy identifier[] (np. wiele identyfikatorów z różnymi systemami) odzwierciedla te konteksty. W każdej domenie position z odpowiednim code i strukturą (attribute / profil) modeluje pozycje i segmenty właściwe dla faktury, zamówienia, dokumentów księgowych, HR i CRM; attribute[] służy m.in. do podsumowania pozycji (sumy netto, VAT, brutto).

4. Zgodność z systemami wzorcowymi

System Odpowiednik Uwagi
OAGIS BOD (ApplicationArea + Noun) Noun = typ dokumentu (PurchaseOrder, Invoice…); ApplicationArea = identyfikatory, daty, nadawca
UBL 2.3 Invoice, Order, DespatchAdvice, OrderResponse… Wspólne: ID, IssueDate, Party (AccountingSupplierParty, BuyerCustomerParty…), DocumentReference, LineItems
SAP Dokument FI/MM/SD Nagłówek (numer, typ, daty, odniesienia) + pozycje; typ dokumentu (BLART itd.)
FHIR DocumentReference, Composition DocumentReference = metadane + odniesienie do treści; Composition = struktura treści; Document u nas = dokument biznesowy (transakcja)
GS1 Business Document (Invoice itd.) + SBDH Treść dokumentu (identyfikatory, strony, wiersze) + nagłówek routingu (SBDH)

5. Odniesienia