API.ERP Domain Taxonomy

Cel: Mapa 22 domen funkcjonalnych ERP pogrupowanych w 9 grup biznesowych oraz zestawienie z zasobami i endpointami w opublikowanym API kanonicznym (FK/EOD, WMS, HR). Taksonomia służy do nazewnictwa i klasyfikacji; obowiązujący kontrakt HTTP dla integracji to OpenAPI w APIM i pliki YAML w repozytorium.

Ugrupowanie: Domeny są grupowane według obszarów zdolności biznesowych (wzorce znane z systemów ERP klasy enterprise). Zasoby master data (Party, Product, Location itd.) są współdzielone między grupami, bez wydzielania osobnej „domeny tylko MDM” w tej klasyfikacji.

---

Group A: Finance Core

Business Purpose: Financial accounting, ledger management, and financial control.

Contains 2 domains:

#	Domain	Functional Areas	Status	Resources	Endpoint
1	Finance	General Ledger, AP, AR, FA, Cash & Bank, Financial Closing, Treasury, Financial Reporting	✅ Częściowo w API kanonicznym	W API-ERP-Canonical-EOD (FK/obieg): m.in. Party, BankAccount, Document, Invoice (lines[] + InvoicePosition), PostingInstruction (instrukcja księgowania dla faktury), Ledger / LedgerEntry, Register, AccountingVariant, CostCarrier, CostAssignment — zgodnie z api-contracts.md i OpenAPI	/v1/parties, /v1/bank-accounts, /v1/documents, /v1/invoices, /v1/posting-instructions, /v1/ledger-entries, … (rejestry/koszty wg APIM)
2	Controlling	Budgeting, Forecasting, Cost Center, Internal Orders, Profitability Analysis, Management Reporting	🟡 Poza kontraktem EOD	Alokacje kosztów częściowo przez CostCarrier, CostAssignment w EOD; pełny controlling — osobna specyfikacja operatora	(wg publikacji APIM)

Status w kanonicznym API: ✅ READY dla zakresu API-ERP-Canonical-EOD (FK/obieg — patrz api-contracts.md); nie oznacza to pełnego modułu GL (księga główna) ani wszystkich endpointów z szerokiej taksonomii „Finance”.
Shared Resources: Party (vendors, customers), BankAccount, Document (bufor obiegu, dekret), Invoice, PostingInstruction, LedgerEntry, Register, AccountingVariant, CostCarrier, CostAssignment
Dependencies: None (foundational)
Scope: CRUD wg OpenAPI dla powyższych zasobów; faktura jako Invoice (KSeF, art. 106e) lub profil na Document.

---

Group B: Procurement-to-Pay

Business Purpose: Procurement lifecycle (PR → RFQ → PO → GR) and warehouse management of received goods.

Contains 3 domains:

#	Domain	Functional Areas	Status	Resources	Endpoint
3	Procurement	PR, RFQ, PO, Supplier Evaluation, GR, Invoice Verification	🟡 Placeholder	(candidate: PurchaseOrder, Requisition)	/v1/purchase-orders, /v1/purchase-requisitions
4	Warehouse & Inventory	Inbound, Outbound, Internal Moves, Cycle Counting, Reconciliation, Batch/Serial, Location Mgmt	✅ Implemented	InventoryDocument, Inventory, Location, Product	/v1/inventory-documents, /v1/inventories, /v1/locations, /v1/product-definitions
5	Logistics & Distribution	Picking, Packing, Shipping, TMS, Delivery Tracking	🟡 Placeholder	(via InventoryDocument)	(via WMS)

Status w kanonicznym API: ✅ READY dla WMS (InventoryDocument, Inventory, Location, Product…); zamówienia i zapotrzebowania (PurchaseOrder, PurchaseRequisition) — w specyfikacji EOD / WMS zgodnie z opublikowanym OpenAPI dla danej wersji.
Shared Resources: Party (vendors, suppliers), Product (goods), Location (warehouses, warehouse zones), Document (receiving notes, delivery docs)
Dependencies: Finance Core (AP for supplier invoices), Master Data (Party, Product, Location)
Scope:
- WMS: operacje na InventoryDocument (GR/GI/przesunięcia/korekty), stanie Inventory, Location, referencjach do produktu.
- Procesy zakupowe: w kanonie modelowane zasobami m.in. PurchaseRequisition, PurchaseOrder, InventoryDocument, Invoice — dokładny zakres operacji REST w OpenAPI.
- Logistyka: przepływy realizowane przez InventoryDocument i hierarchię Location (bez osobnego modułu „TMS” w kanonie).

---

Group C: Order-to-Cash

Business Purpose: Sales order fulfillment, customer management, and commercial execution.

Contains 3 domains:

#	Domain	Functional Areas	Status	Resources	Endpoint
6	Sales Execution	Sales Orders, Pricing, Discounts, ATP, Order Fulfillment, Sales Invoicing	🟡 Placeholder	(candidate: SalesOrder, SalesInvoice)	/v1/sales-orders, /v1/sales-invoices
7	Customer Domain / CRM	Lead Mgmt, Opportunity, Account/Customer 360, Case, After-Sales Service	🟡 Placeholder	(via Master Data: Party)	(via Party endpoints)
17	Commerce / Omnichannel	POS Operations, Product Catalog, Promotions, E-commerce, Order Orchestration	🟡 Placeholder	(candidate: CommerceOrder)	/v1/commerce-orders

Status w kanonicznym API: 🟡 Brak w publikowanych plikach OpenAPI — poza kontraktem tego IG.
Shared Resources: Party (customers), Product, Location (retail locations), Document (sales orders, quotes)
Dependencies: Finance Core (AR for customer invoices), Procurement-to-Pay (inventory availability), Master Data (Party, Product)
Scope: SO → Fulfillment → SI (Sales Invoicing) → GL posting via Finance Core.

---

Group D: Manufacturing

Business Purpose: Production planning, execution, and material management for manufacturing operations.

Contains 4 domains:

#	Domain	Functional Areas	Status	Resources	Endpoint
9	Manufacturing	Production Orders, Shop Floor, Material Consumption, Traceability, In-Process QA	🟡 Placeholder	(candidate: ProductionOrder)	/v1/production-orders
10	Production Planning	BOM, Routing, MRP, MPS, Scheduling, Capacity Planning	🟡 Placeholder	(ProductDefinition with BOM, candidate: Routing, BOMVersion)	/v1/product-definitions, /v1/routings
11	Supply Chain Planning	Demand Planning, Supply Planning, Inventory Optimization, Replenishment, Returns Mgmt	🟡 Placeholder	(via Warehouse & Inventory)	(via WMS)
12	Quality Management	Incoming Inspection, In-Process QA, Final QC, Non-Conformance, CAPA	🟡 Placeholder	(candidate: InspectionLot, QualityOrder)	/v1/inspection-lots, /v1/quality-orders

Status w kanonicznym API: 🟡 Brak w publikowanych plikach OpenAPI — poza kontraktem tego IG.
Shared Resources: Party (vendors for raw materials), Product (BOM structure via ProductDefinition), Location (work centers, storage), Document (production orders, inspection docs)
Dependencies: Procurement-to-Pay (raw materials), Warehouse & Inventory (consumed materials), Finance Core (variance posting)
Scope: BOM definition, Production Order execution, Material Consumption tracking, QA integration.

---

Group E: Human Capital

Business Purpose: Employee lifecycle, organizational structure, compensation, and workforce management.

Contains 1 domain:

#	Domain	Functional Areas	Status	Resources	Endpoint
15	HR / HCM	Employee Master, Org. Mgmt, Time & Attendance, Payroll, Recruitment, Talent Mgmt	✅ Implemented	Employment, Position, OrganizationUnit, OrganizationAssignment, Capability, Duty, GrantAssignment, Compensation, Payroll	/v1/employments, /v1/positions, /v1/organization-units, /v1/organization-assignments, /v1/capabilities, /v1/duties, /v1/grant-assignments, /v1/compensations, /v1/payrolls

Status w kanonicznym API: ✅ READY — specyfikacja EOD (OpenAPI).
Shared Resources: Party (employees, organizational units as parties), Location (office locations), Document (HR documents—contracts, letters, certificates)
Dependencies: Master Data (Party, Location)
Scope: Full CRUD on organizational hierarchy (OrganizationUnit, OrganizationAssignment), employee contracts (Employment), roles (Position), capabilities, compensation, and payroll. Includes time & attendance integration points.

---

Group F: Assets & Field Service

Business Purpose: Asset management, preventive/corrective maintenance, and mobile field service operations.

Contains 2 domains:

#	Domain	Functional Areas	Status	Resources	Endpoint
8	Field Service	Work Orders, Technician Scheduling, Asset Servicing, Mobile Execution	🟡 Placeholder	(candidate: ServiceOrder, ServiceAppointment, Technician)	/v1/service-orders, /v1/service-appointments
13	Asset Management / Maintenance	Fixed assets, asset allocations, asset documents, preventive maintenance, corrective maintenance	🟡 Documented	FixedAsset, AssetComponent, FixedAssetAllocation, FundingSource, FixedAssetDocument	/v1/fixed-assets, /v1/asset-components, /v1/fixed-asset-allocations, /v1/funding-sources, /v1/fixed-asset-documents

API Implementation Status: modele ESM opisane w Implementation Guide; kontrakt HTTP (ścieżki, operacje) dla ESM — wyłącznie zgodnie z publikacją w APIM i plikiem OpenAPI przekazanym integratorowi dla danej wersji API.
Shared Resources: Party (technicians, vendors), Location (asset locations), Product (spare parts), Document (work orders, maintenance logs)
Dependencies: HR (technician scheduling), Finance Core (cost posting for maintenance), Master Data (Party, Location, Product)
Scope: Asset registry, multi-dimensional allocations (location, cost center, responsible party, funding source), asset document lifecycle, and future maintenance / mobile execution tracking.

---

Group G: Projects

Business Purpose: Project planning, budgeting, resource allocation, and delivery management.

Contains 1 domain:

#	Domain	Functional Areas	Status	Resources	Endpoint
14	Project System	WBS, Project Planning, Budgeting, Resource Allocation, Time & Cost Tracking, Project Billing	🟡 Placeholder	(candidate: Project, WBS, ProjectTask, ProjectResource)	/v1/projects, /v1/wbs, /v1/project-tasks

Status w kanonicznym API: 🟡 Brak w publikowanych plikach OpenAPI — poza kontraktem tego IG.
Shared Resources: Party (resources, customers), Location (project sites), Document (project documents, invoices), Product (deliverables)
Dependencies: Finance Core (budget posting, cost tracking), HR (resource allocation), Master Data (Party, Location)
Scope: Project setup, WBS hierarchy, Resource planning, Time tracking, Cost allocation, Project invoicing.

---

Group H: Master Data / Core Resources

Business Purpose: Shared, foundational data entities that support all other domains.

Contains 1 super-domain (distributed):

#	Super-Domain	Entities	Status	Endpoints
16	Master Data / Core Resources	Party, PartyRole, PartyRelationship, BankAccount, Location, Product, ProductDefinition, Attribute, Group, Document, DocumentPosition	✅ Implemented	/v1/parties, /v1/party-roles, /v1/party-relationships, /v1/bank-accounts, /v1/locations, /v1/products, /v1/product-definitions, /v1/attributes, /v1/documents, /v1/document-positions

API Implementation Status: ✅ READY (foundational for all groups)
Resource Definitions:

• Party: Universal entity representing any stakeholder (customer, vendor, employee, internal organization, etc.). Role determined by PartyRole.
• PartyRole: Classifies Party relationships (customer, vendor, employee, supplier, etc.).
• PartyRelationship: Models relationships between parties (hierarchy, partnerships).
• Product: Master product record; extended by ProductDefinition with BOM, routing, attributes.
• Location: Physical or logical location (warehouse zone, office, work center, service site).
• BankAccount: Financial account for Party (payments, collections).
• Document: Universal document container (supports type variants: invoice, SO, PO, payslip, inspection report, etc.); JSON representation, not legal document itself.
• DocumentPosition: Line items within Document.
• Attribute: Dynamic attributes for any resource (extensibility mechanism).
• Group: Logical grouping (accounting variants, product families, cost center hierarchies).

Dependencies: None (foundational)
Scope: Full CRUD. Shared across all domains. Distributed in each module's API spec (FK, WMS, HR) rather than isolated as separate domain.

---

Group I: Operational Support

Business Purpose: Cross-cutting concerns: marketing automation, sustainability reporting, regulatory compliance, and product engineering.

Contains 4 domains:

#	Domain	Functional Areas	Status	Resources	Endpoint
18	Marketing Automation	Campaign Mgmt, Segmentation, Lead Nurturing, Marketing Analytics	🟡 Placeholder	(candidate: Campaign, MarketingList)	/v1/campaigns, /v1/marketing-lists
20	Sustainability / ESG	Carbon Footprint, Energy Mgmt, ESG Reporting, Sustainable Sourcing, Waste & Circular Economy	🟡 Placeholder	(candidate: SustainabilityRecord, CarbonFootprint)	/v1/sustainability-records
21	Compliance & Regulatory	Internal Controls, Audit Trail, Regulatory Reporting, GRC, Document Retention	🟡 Placeholder	(integrated: audit logs, Document retention, Attribute classification)	(via Party, Document audit endpoints)
22	R&D / Engineering — PLM	Engineering BOM, Change Mgmt/ECN, Product Lifecycle Mgmt, Doc Mgmt, Collaboration	🟡 Placeholder	(candidate: EngineeringBOM, ChangeOrder, DocStorage)	/v1/engineering-boms, /v1/change-orders

Status w kanonicznym API: 🟡 Brak w publikowanych plikach OpenAPI — poza kontraktem tego IG.
Shared Resources: Document, Party, Product, Attribute
Dependencies: All other groups (cross-cutting)
Scope: - Marketing: Campaign execution, lead tracking. - Sustainability: Carbon tracking, ESG metrics. - Compliance: Audit trail (via Document + API logging), regulatory reporting, GRC documentation (via Document). - R&D/PLM: Engineering BOM variants, ECN (Engineering Change Notice) workflow, document control.

---

Master Data / Core Resources Detail

All resources in Group H (and used across other groups) extend the shared DomainResource shape (FHIR-inspired pattern):

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "DomainResource",
  "description": "Shared structure for domain resources in Kamsoft.FAIR (Fast Adaptive Interoperable Resources: findable identifiers, CRUD access, interoperable references and coded values, reusable common fields).",
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "Unique identifier within the domain API"
    },
    "resourceType": {
      "type": "string",
      "description": "Type discriminator (e.g., 'Party', 'Document', 'Ledger')"
    },
    "identifier": {
      "type": "array",
      "description": "External identifiers (business keys, SKU, Tax ID, etc.)"
    },
    "meta": {
      "type": "object",
      "description": "Metadata: createdDate, modifiedDate, createdBy, modifiedBy, version"
    },
    "attribute": {
      "type": "array",
      "description": "Extensibility: typed business attributes without schema modification"
    }
  }
}

Key Pattern: Resources like Invoice, Document, InventoryDocument, Employment share the DomainResource structure, ensuring consistency and Kamsoft.FAIR compliance (Fast, Adaptive, Interoperable, Reusable) across all modules.

---

Udostępnienie API poza kanonem FK / WMS / HR

Grupy i domeny oznaczone w tabelach jako Placeholder nie mają w tym Implementation Guide przypisanego kontraktu REST w plikach kanonicznych API-ERP-Canonical-*.yaml. Integracja w tych obszarach — wyłącznie na podstawie osobnej specyfikacji udostępnionej przez operatora API dla projektu.

---

Cross-Domain Integration Points

From Domain	To Domain	Via	Example
Finance	Procurement	Document, Party (vendor)	Invoice received from vendor
Finance	HR	Party (employee), Document	Payroll posting to GL
Finance	WMS	Inventory, Product	COGS posting from inventory transactions
WMS	Procurement	InventoryDocument, Location	GR (Goods Receipt) → Inventory
WMS	Manufacturing	Product, InventoryDocument	Material Consumption → GL
WMS	Order-to-Cash	Inventory state, Location	ATP (Available-to-Promise) check
HR	Finance	Party (employee), Document (payroll)	Compensation posting to GL
Projects	Finance	Document, Party (resources)	Time tracking → Cost posting
Manufacturing	Finance	ProductionOrder, Document	Variance posting to GL
Assets	Finance	Document (work order), Party (technician)	Maintenance cost posting

---

Notes

• Document vs. Invoice: Document is a universal JSON representation for any document type (with type discriminator). Invoice is a specialized document type with KSeF compliance (art. 106e) and dedicated endpoints. Both build on the same DomainResource foundation.
• Party as Master Data: Customers, vendors, and employees are Party entities with differentiating PartyRole. Warehouses are represented as Location (type=warehouse).
• Location Hierarchy: Warehouse zones, office locations, work centers, and service sites all use Location with hierarchical relationships.
• Master Data Distribution: Core resources (Group H) are not isolated but distributed in each domain's API spec (FK, WMS, HR) for clarity and RBAC separation.
• FAIR Principles: All resources follow Kamsoft.FAIR (Fast: spójne struktury; Adaptive: rozszerzalne; Interoperable: Reference/CodeableConcept/Attribute; Reusable: wspólny rdzeń DomainResource). Findable via identifier, Accessible via CRUD endpoints, Interoperable via references and coded vocabularies, Reusable through the shared DomainResource layout.

---

Revision History

• 2026-02-25: Utworzenie taksonomii; dokumentacja grup A–I; powiązanie z API kanonicznymi FK, WMS, HR.