API.ERP Domain Taxonomy

Purpose: Comprehensive map of all 22 ERP functional domains organized into 9 business groups, with API implementation status for FK (Finance-Accounting), WMS (Warehouse), and HR (Human Resources).

Approach: Domains are grouped by business capability, following patterns from SAP, Oracle, and Microsoft Dynamics. Master Data resources (Party, Product, Location, etc.) are shared across groups, not isolated as a separate domain.

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	✅ Implemented	`Ledger`, `LedgerAccount`, `LedgerEntry`, `BankAccount`	`/v1/ledgers`, `/v1/ledger-accounts`, `/v1/ledger-entries`, `/v1/bank-accounts`
2	Controlling	Budgeting, Forecasting, Cost Center, Internal Orders, Profitability Analysis, Management Reporting	✅ Implemented	(via Finance: Ledger, Group)	(via Finance)

API Implementation Status: ✅ READY (Phase 1)
Shared Resources: Party (vendors, customers), BankAccount, Document (financial documents), Group (accounting variants), Attribute (ledger attributes)
Dependencies: None (foundational)
Scope: Full CRUD on all resources; Invoice dedicated profile for KSeF (art. 106e) regulation; LedgerEntry for transaction records.

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)

API Implementation Status: ✅ PARTIAL (Phase 1 for WMS; Phase 2+ for Procurement)
Shared Resources: Party (vendors, warehouse operators), Product (goods), Location (warehouse zones), Document (receiving notes, delivery docs)
Dependencies: Finance Core (AP for supplier invoices), Master Data (Party, Product, Location)
Scope: - WMS: Full CRUD on InventoryDocument (PZ/WZ/transfers), Inventory state, Location, Product references. - Procurement: PR → PO lifecycle (placeholder for Phase 2). - Note: Logistics flows through InventoryDocument and Location hierarchy (not separate module).

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`

API Implementation Status: 🟡 PLACEHOLDER (Phase 2 candidate)
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`

API Implementation Status: 🟡 PLACEHOLDER (Phase 3 candidate)
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`

API Implementation Status: ✅ READY (Phase 1)
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: 🟡 IN PROGRESS (model ESM udokumentowany, OpenAPI i backend pozostaja planowane)
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`

API Implementation Status: 🟡 PLACEHOLDER (Phase 2–3 candidate)
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, warehouse, 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`

API Implementation Status: 🟡 PLACEHOLDER (Phase 3+ candidate)
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) inherit from DomainResource base class (FHIR-inspired pattern):

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "DomainResource",
  "description": "Base class for all domain resources. Provides common metadata for Kamsoft.FAIR principles (Fast Adaptive Interoperable Resources: Findable via identifier, Accessible via CRUD, Interoperable via references and coded vocabularies, Reusable via inheritance).",
  "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 inherit from DomainResource, ensuring consistency and Kamsoft.FAIR compliance (Fast, Adaptive, Interoperable, Reusable) across all modules.

API Implementation Roadmap

Phase 1: ✅ COMPLETE — FK, WMS, HR

Finance Core (Group A): Ledger, LedgerAccount, LedgerEntry, BankAccount, Invoice, Group
Warehouse (Group B): InventoryDocument, Inventory, Location, Product, ProductDefinition
HR (Group E): OrganizationUnit, Party, Employment, Position, Compensation, Payroll, etc.
Master Data (Group H): Party, Product, Location, BankAccount, Document, Attribute, Group, etc.

Phase 2: 🟡 PLANNED — Procurement, Order-to-Cash, Projects

Procurement (Group B): PurchaseOrder, PurchaseRequisition, GoodsReceipt
Order-to-Cash (Group C): SalesOrder, SalesInvoice, Customer (Party + CRM context)
Projects (Group G): Project, WBS, ProjectTask, ProjectResource

Phase 3: 🟡 PLANNED — Manufacturing, Assets, R&D/PLM

Manufacturing (Group D): ProductionOrder, Routing, BOMVersion, QualityOrder
Assets (Group F): FixedAsset, AssetComponent, FixedAssetAllocation, FundingSource, FixedAssetDocument, MaintenanceOrder, ServiceOrder, PreventiveSchedule
R&D/PLM (Group I.4): EngineeringBOM, ChangeOrder, DocumentControl

Phase 4: 🟡 FUTURE — Marketing, Sustainability, Compliance

Marketing (Group I.1): Campaign, MarketingList, LeadNurture
Sustainability (Group I.2): SustainabilityRecord, CarbonFootprint, ESGReport
Compliance (Group I.3): AuditLog integration, RegulatoryReport, GRCFramework

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 inherit from DomainResource.
Party as Master Data: Customers, vendors, employees, and warehouse operators are all Party entities with differentiating PartyRole.
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: DomainResource inheritance). Findable via identifier, Accessible via CRUD endpoints, Interoperable via references and coded vocabularies, Reusable via inheritance from DomainResource.

Revision History

2026-02-25: Initial taxonomy created; Groups A–I documented; Phase 1 (FK, WMS, HR) marked complete; Phases 2–4 outlined.