An extensible, on-premises inventory and ordering module that integrates heterogeneous POS and supplier systems through a connector-based architecture.
Small and medium-sized enterprises (SMEs) in the hospitality sector face persistent operational challenges in inventory management and supplier order coordination. Manual workflows, fragmented supplier communication across heterogeneous channels, and underutilised point-of-sale (POS) data create repeated media breaks and substantial administrative overhead. Full enterprise solutions such as ERP systems are frequently unsuitable for SMEs due to their complexity and resource requirements.
InvMan is a lightweight, extensible inventory management module designed specifically for SME gastronomy. Rather than replacing existing POS or supplier systems, it acts as an integration layer that bridges them through a unified inventory and ordering workflow. The system runs as a local on-premises solution: its core data and workflow execution remain available even during temporary internet outages, while external supplier communication is handled as a separate, connector-based transmission step.
This repository contains the prototype implementation developed as part of a bachelor thesis at the UAS Technikum Wien (see Academic Context).
- Key Features
- System Architecture
- Technology Stack
- Getting Started
- Configuration
- REST API
- Connectors
- Evaluation
- Scope and Limitations
- Academic Context
- License
- Unified inventory overview with real-time stock levels derived from POS sales events.
- Automated POS data ingestion — sales are translated into signed inventory transactions, including bill-of-materials deduction for composite products.
- Replenishment support — products below their minimum stock threshold are surfaced as alerts, and replenishment orders can be prepared and reviewed before submission.
- Multi-channel supplier ordering through pluggable outbound connectors (e.g. email, WhatsApp), with an explicit confirmation safeguard before any order leaves the system.
- Goods receipt handling — confirm delivered quantities against ordered quantities and adjust inventory where actual deliveries differ.
- Extensible connector framework — adding a new POS system or supplier channel only requires a new connector and its runtime configuration; the canonical core and order logic remain unchanged.
- Offline-capable core — inventory overview, stock adjustments, order preparation and goods receipt recording work locally, independent of internet connectivity.
InvMan is built around a canonical data model that serves as a vendor-neutral, internal representation of products, stock levels and replenishment intent. External system formats never leak into the core: POS product identifiers, supplier SKUs, packaging descriptions and unit conversions are isolated in dedicated mapping/translation structures. The canonical data model spans 14 tables organised into 5 layers, separating the canonical core from demand-side (POS) and supply-side (supplier) integration.
At the functional runtime level the system is organised into four modules with clearly separated responsibilities, plus a deployable application module that wires them together:
| Module | Responsibility |
|---|---|
common |
Shared entities, repositories, DTOs and connector contracts (OutboundConnector, InboundConnector, OrderProcessor, ConnectorResult, SupplierOrderPayload, PosInvoicePayload). |
data-processing-module |
REST controllers, application services (stock calculation, alert evaluation, replenishment, master data, settings) and the inbound webhook endpoint. |
inbound-connector-module |
POS data ingestion: polling scheduler, inbound connector registry, POS event mapping and the inbound orchestrator. |
outbound-connector-module |
Supplier order transmission: connector orchestrator, registry, order splitting, status aggregation and concrete outbound connectors. |
app |
Deployable Spring Boot entry point that aggregates all modules and provides cross-cutting configuration (@EntityScan, @EnableJpaRepositories, mail configuration). |
The connector framework is theoretically grounded in Enterprise Integration Patterns (Hohpe, 2002), adapting selected patterns — Content-Based Router, Splitter, Aggregator, Message Transformation, Envelope Wrapper/Unwrapper, Message Header — to a lightweight, application-local architecture suitable for SME conditions. Connector logic is separated from runtime configuration, so that the same connector implementation can be reconfigured without code changes. Both inbound transport paths (polling and webhook/push) converge on a single canonical representation, so transport-level heterogeneity does not propagate into the processing pipeline. Inbound processing is idempotent: invoices are deduplicated against previously recorded reference identifiers to prevent double-counting across overlapping polling windows.
- Language: Java 21
- Framework: Spring Boot
- Build: Maven (multi-module project)
- Persistence: Spring Data JPA / Hibernate
- Database: PostgreSQL
- Frontend: React (operational evaluation interface)
- Deployment: On-premises; the
appmodule builds an executable JAR
git clone [https://github.com/JohannesVora/prototyp-Inventory_Management_Module.git]
cd
cp .env.example .env # fill in your values
docker compose up --buildThe frontend is then available at http://localhost, and the backend on port 8080 — verify with curl http://localhost:8080/api/health## Getting Started
Runtime credentials and environment-specific settings are provided via environment variables
(see .env.example). Connector-level settings (Ready2Order, SMTP, WPPConnect) can
additionally be managed at runtime through the /api/settings/* endpoints.
Typical configuration values include:
- Database connection (host, port, name, user, password)
- Ready2Order POS API credentials / token
- SMTP server settings for the email connector
- WPPConnect endpoint and token for the WhatsApp connector
The data-processing module exposes a REST API on port 8080. Selected endpoints:
| Method | Path | Description |
|---|---|---|
GET |
/api/health |
Liveness check; returns the schema version. |
GET |
/api/inventory |
All inventory items with current stock levels. |
GET |
/api/inventory/alerts |
Products below the minimum stock threshold. |
GET |
/api/suppliers |
All configured suppliers. |
POST |
/api/orders/replenishment |
Create a replenishment order. |
GET |
/api/orders/replenishment/{id} |
Retrieve a specific replenishment order. |
POST |
/api/inbound/r2o/webhook |
Inbound webhook for Ready2Order POS events. |
GET |
/api/settings/r2o |
Read Ready2Order connector settings. |
GET/PUT |
/api/settings/smtp |
Read/update SMTP (email connector) settings. |
GET/PUT |
/api/settings/wppconnect |
Read/update WhatsApp (WPPConnect) settings. |
Inbound (POS → InvMan)
- Ready2Order — sales events are ingested via polling or webhook, mapped to the canonical model, and translated into signed inventory transactions. Composite products are resolved via their bill of materials; direct products via a one-to-one mapping.
Outbound (InvMan → Supplier)
- Email connector (SMTP) — transmits supplier orders by email.
- WhatsApp connector (WPPConnect) — transmits supplier orders via WhatsApp.
New connectors implement the connector contracts defined in the common module and are
registered with the corresponding orchestrator/registry, requiring no changes to the
canonical core.
The prototype was evaluated in a mixed-methods study based on an hospitality SME case study, following the Design Science Research Methodology (Peffers et al., 2007). Within the evaluated scenario, the prototype achieved a 90.8% reduction in ordering-phase staff effort and removed the observed user-facing media breaks during order submission, compared with the established manual process. These results are context-bound to the case study but provide concrete operational evidence that the design met its intended purpose within the prototype scope.
The canonical data model deliberately prioritises simplicity and maintainability over completeness. The following are explicit, out-of-scope boundaries reflecting the operational reality of the SME case-study context:
- Multi-level packaging hierarchies
- Multi-location inventory tracking
- Lot-level traceability
As a research prototype, the system is intended to demonstrate and evaluate the proposed architecture rather than to serve as a production-ready product.
This repository accompanies the bachelor thesis:
Concept and Prototype Implementation of a Lightweight, Extensible Inventory Management Module with Connectors for Heterogeneous POS and Supplier Systems in the Hospitality Industry
Johannes Voraberger — University of Applied Sciences Technikum Wien, Degree Program Business Informatics
Supervisor: Dr. Christian Nebenführ
Vienna, 2026
The work follows the Design Science Research Methodology (Peffers et al., 2007) and comprises requirements analysis, canonical data model design, connector framework architecture, and a mixed-methods evaluation.
The full thesis is available in docs/BachelorPaper_Johannes_Voraberger.pdf
Until a license is added, this code is provided for academic and demonstration purposes only. Please contact the author before reuse.