Kontrakty API

Każda sekcja poniżej stanowi punkt wejścia do analizy dla danej domeny: szkielet zasobów i endpointów (ścieżki, metody, pola do doprecyzowania). Analityk wchodzi w sekcję i doprecyzowuje wymagania, pola, wartości.

Mapa domen: Patrz domain-taxonomy.md — kompletna mapa 22 domen biznesowych pogrupowanych w 9 grup.

DomainResource pattern: Wszyscy zasoby (Document, Invoice, InventoryDocument, Employment, etc.) dziedziczą z DomainResource (wzorowanie na FHIR). Patrz docs/Resources/DomainResource.md.

Konwencje (zgodne z technical-conventions.md i założeniami pharmind XF): Endpointy — rzeczowniki w liczbie mnogiej, kebab-case (np. /v1/purchase-orders, /v1/goods-receipts); liczba pojedyncza tylko dla zasobów jednoelementowych (np. /profile). Parametry zapytań — snake_case (user_id, start_date). Pola w request/response JSON — camelCase. PATCH — body zawiera tylko pola do zmiany. Operacje niestandardowe — prefiks $ (np. POST /v1/reservation/{id}/$confirm-presence).

Rozszerzalna identyfikacja (wzorowana na FHIR): Modele — niezależnie od domeny — mogą i w wielu przypadkach powinny zawierać: - Identifier(s): tablica identifiers z polami system (URI przestrzeni nazw), value, oraz opcjonalnie use, type (Coding), period, assigner — umożliwia wielozakresową identyfikację (wewnętrzny id, numer z ERP, identyfikator z systemu zewnętrznego). - Coding / CodeableConcept: pola klasyfikujące (np. status, documentType, unit, category) jako pojedynczy Coding lub CodeableConcept (coding[] + text) — kody z systemów terminologicznych z możliwością rozszerzenia.

Szczegóły struktury: technical-conventions.md. Per zasób: które pola są wymagane (np. id vs identifiers), dopuszczalne system — do doprecyzowania w toku analizy.

Struktura kontraktów: Zasób → endpoint, metody, body/query params, pola kluczowe — jako rama do wypełnienia w toku analizy, nie gotowa specyfikacja.

Status implementacji API

Grupa domen	Status	Zasoby	Specyfikacja
A. Finance Core (Group A)	✅ READY	BankAccount, Invoice, Document, Register, AccountingVariant, CostCarrier, CostAssignment	API-ERP-Canonical-EOD.yaml (docs/openapi/)
E. Procurement-to-Pay (WMS part) (Group B)	✅ READY	InventoryDocument, Inventory, Location, Product, ProductDefinition	API-ERP-Canonical-WMS.yaml (docs/openapi/)
E. Human Capital (Group E)	✅ READY	OrganizationUnit, Party, PartyRole, Employment, Position, Capability, GrantAssignment	API-ERP-Canonical-HR.yaml (docs/openapi/)
C. Order-to-Cash (Group C)	🟡 PLACEHOLDER	SalesOrder, SalesInvoice, Customer	(Phase 2)
D. Manufacturing (Group D)	🟡 PLACEHOLDER	ProductionOrder, Routing, BOMVersion, QualityOrder	(Phase 3)
F. Assets & Field (Group F)	🟡 PLACEHOLDER	Asset, MaintenanceOrder, ServiceOrder	(Phase 3)
G. Projects (Group G)	🟡 PLACEHOLDER	Project, WBS, ProjectTask	(Phase 2–3)
I. Operational Support (Group I)	🟡 PLACEHOLDER	Campaign, SustainabilityRecord, AuditLog, EngineeeringBOM	(Phase 3+)

0. API kanoniczne — EOD/FK (Finance/Accounting), WMS i HR (READY)

Źródło: Dwie specyfikacje OpenAPI 3.0 w katalogu głównym repozytorium: API-ERP-Canonical-EOD.yaml oraz API-ERP-Canonical-WMS.yaml. Modele kanoniczne zastępują wcześniejsze modele EOD (EodCustomer, EodBufferDocument itd.).

Zakres:

Canonical EOD (ścieżki /v1/...): Party (kontrahenci), BankAccount, Document (bufor EOD/FK), documents-changed-status, Register, AccountingVariant, CostCarrier, CostAssignment. Nagłówki: ks-system-identification; parametr company (NIP).
Canonical WMS (ścieżki /v1/...): Party (np. magazyny), Location, ProductDefinition, Inventory, Document (PZ, WZ, przesunięcia, zapotrzebowania). Ta sama konwencja nagłówków i parametrów.

Mapowanie na domeny (dokument domenowy): EOD i WMS obejmują m.in. domeny 1 (Finance), 2 (Controlling), 3 (Procurement), 4 (Warehouse & Inventory), 16 (Master Data).

Konwencje: Paginacja _count / _offset; błędy RFC 7807 (ProblemDetails); modele z Identifier, CodeableConcept, Reference (wzorowane na FHIR). Odniesienie do technical-conventions.md.

Wyszukiwanie po identyfikatorze biznesowym: Wszystkie kolekcyjne GET endpoints wspierają parametr ?identifier=system1|value1,system2|value2 do wyszukania zasobów po identyfikatorach z różnych systemów (OR logic między wartościami, AND z innymi filtrami). Szczegóły: technical-conventions.md#124-wyszukiwanie-po-identyfikatorze-biznesowym.

Opis zasobów i ścieżek: API kanoniczne — przegląd.