Scenariusze procesów
Przestrzeń do analizy procesów: każdy scenariusz poniżej to szkielet/placeholder do doprecyzowania przez analityków (kroki, uczestnicy, wywołania API). Diagramy sekwencji są szablonami do uzupełnienia.
1. Tworzenie zamówienia zakupu (domena 3. Procurement)
Opis: Od zapotrzebowania do zamówienia zakupu — kroki i wywołania API do doprecyzowania.
| Element | Placeholder (do uzupełnienia) |
|---|---|
| Uczestnicy | Analityk, system zakupów, magazyn — do doprecyzowania |
| Kroki | 1. … 2. … 3. … — lista kroków i ewentualne wywołania API |
| Wywołania API | POST /v1/purchase-requisitions (zgłoszenie zapotrzebowania), GET /v1/purchase-requisitions?status=… (śledzenie statusu), GET /v1/purchase-orders?identifier=… (odczyt zamówienia powstałego z zapotrzebowania; zamówienia zakupu są tylko do odczytu) |
| Diagram sekwencji | Szablon do uzupełnienia (np. Mermaid sequence) |
2. Przepływ P2P (Procure-to-Pay)
Opis: Pełny cykl od zapotrzebowania przez zamówienie, przyjęcie towaru, fakturę do rozliczenia — do doprecyzowania.
| Element | Placeholder (do uzupełnienia) |
|---|---|
| Kroki | Zapotrzebowanie → Zamówienie → Przyjęcie → Faktura → Płatność — szczegóły i API |
| Uczestnicy | Do doprecyzowania |
| Wywołania API | Endpointy per krok — do uzupełnienia |
| Diagram sekwencji | Szablon do uzupełnienia |
3. Przepływ O2C (Order-to-Cash)
Opis: Od zamówienia sprzedaży przez realizację, wysyłkę, fakturę do należności — do doprecyzowania.
| Element | Placeholder (do uzupełnienia) |
|---|---|
| Kroki | Zamówienie → Realizacja → Wysyłka → Faktura → Płatność — szczegóły i API |
| Uczestnicy | Do doprecyzowania |
| Wywołania API | Endpointy per krok — do uzupełnienia |
| Diagram sekwencji | Szablon do uzupełnienia |
4. Przepływ dokumentu księgowego: instrukcja księgowania → dekrety / płatności
Opis: System obiegu dokumentów (klient API) przekazuje dokument do bufora księgowego jako PostingInstruction, śledzi jego status i po zaksięgowaniu odczytuje dekrety (JournalEntry) i płatności (Payment). Weryfikacja i zatwierdzenie dokumentu odbywają się w systemie księgowym — API nie ma dla nich operacji; ich skutek widać w PostingInstruction.status.
| Element | Opis |
|---|---|
| Uczestnicy | System klienta (obieg dokumentów), API.ERP, system księgowy |
| Kroki | 1. Przekazanie dokumentu do bufora: POST /v1/posting-instructions (treść: owner z NIP firmy, identifier z id dokumentu i numerem, symbol ze słowników finance/posting-instruction-symbol i posting-instruction-document-symbol-type, issueDate, postingLine[]); ponowny POST z tym samym identyfikatorem nadpisuje bufor. 2. Śledzenie statusu: GET /v1/posting-instructions?identifier=<przestrzeń>|<id>&owner=https://gov.pl/nip|<NIP> — status ze słownika finance/posting-instruction-status (ready-for-retrieval → retrieved → …). 3. Odczyt dekretów: GET /v1/journal-entries?postingInstruction=<przestrzeń>|<id>&owner=…. 4. Odczyt płatności: GET /v1/payments?identifier=<przestrzeń>|<id>&owner=…. |
| Wywołania API | Firma przez owner=https://gov.pl/nip|<NIP> (parametr) albo owner[] w treści. Przykłady: PostingInstruction — przykłady. |
| Diagram sekwencji | Klient → API.ERP: POST /v1/posting-instructions → 200 z nadanym identyfikatorem; Klient → API.ERP: GET /v1/posting-instructions (status); Klient → API.ERP: GET /v1/journal-entries, GET /v1/payments. |
5. Inne scenariusze (szablony)
Analityk może dodać dalsze scenariusze (np. M2D, S2D, R2R, Serwis, Commerce) jako szablony do doprecyzowania — kroki, uczestnicy, wywołania API, diagramy sekwencji.
6. Przepływ e-skierowania MP (Plugin ZZL → API.ERP → system medyczny)
Opis: Cykl życia e-skierowania na badanie medycyny pracy — od wygenerowania przez Plugin ZZL, przez eksport Attachment z API.ERP na wskazane miejsce, do przetworzenia przez system medyczny (PSMP). Dokument pionowy mp — szczegóły w verticals/mp/scenarios/referral-lifecycle.md.
| Element | Opis |
|---|---|
| Uczestnicy | KS-ZZL, Plugin systemowy (KS-ZZL), API.ERP, system medyczny (PSMP) |
| Kroki | 1. Dane HR/BHP przygotowane w KS-ZZL. 2. Plugin ZZL: generacja CDA, walidacja, podpis. 3. Attachment przekazany do API.ERP. 4. API.ERP eksportuje Attachment na wskazane miejsce eksportu. 5. System medyczny pobiera dokument i rejestruje wizytę. |
| Wywołania API | REST — TBD; schemat JSON wejściowy pluginu: verticals/mp/contracts/skierowanie_mp_input.schema.json |
| Diagram sekwencji | referral-lifecycle.md (Mermaid) |
Indeks dokumentacji MP: API-ERP-MP-dokumentacja.md.
7. Przepływ orzeczenia MP (system medyczny → API.ERP → ZZL)
Opis: Cykl życia orzeczenia lekarskiego MP — od wystawienia przez Plugin PSMP po dostarczenie jako Attachment do KS-ZZL przez API.ERP. Dokument pionowy mp — szczegóły w verticals/mp/scenarios/certificate-lifecycle.md.
| Element | Opis |
|---|---|
| Uczestnicy | System kliniczny (PSMP), Plugin systemowy (PSMP), API.ERP, Plugin systemowy (KS-ZZL), KS-ZZL |
| Kroki | 1. Badanie MP przeprowadzone na podstawie skierowania. 2. Plugin PSMP: generacja CDA orzeczenia, walidacja, podpis lekarza. 3. Orzeczenie przekazane do API.ERP jako Attachment. 4. API.ERP dostarcza Attachment do KS-ZZL. 5. Plugin ZZL: parsowanie CDA, aktualizacja rejestru badań pracownika. |
| Wywołania API | REST — TBD; schemat JSON wejściowy pluginu: verticals/mp/contracts/orzeczenie_mp_input.schema.json |
| Diagram sekwencji | certificate-lifecycle.md (Mermaid) |
Indeks dokumentacji MP: API-ERP-MP-dokumentacja.md.
Szablon diagramu sekwencji (Mermaid)
sequenceDiagram
participant U as Użytownik/System
participant API as Nasze API
U->>API: (krok 1 — do uzupełnienia)
API-->>U: (odpowiedź — do uzupełnienia)
U->>API: (krok 2 — do uzupełnienia)
API-->>U: (odpowiedź — do uzupełnienia)Opis: Uzupełnić uczestników i komunikaty zgodnie z doprecyzowanym scenariuszem.