Munu Data Store (MDS)

Munu Data Store is a service hosting customer data in Microsoft Azure. It provides a database replica of transactions (orders) and related data to enable external systems to fetch sales and related data for analytics purposes. The data is accumulated at regular intervals (normally once a day) from operational sub-systems.

Data Domains

Domain	Description	Documentation
Master Data	Core reference entities (customers, articles, terminals, users, accounts)	masterdata/
Sales Data	Transaction data including orders, line items, and payments	salesdata/
Article Waste	Waste tracking and reporting	articlewaste/
Labor Data	Workforce management: shifts, costs, and scheduling	labordata/
Inventory Data	Stock management, recipes, suppliers, and transactions	inventorydata/
Booking	Reservation and table management	booking/

Azure Blob Storage Access

MDS data is stored in Azure Blob Storage containers. Each customer has their own container identified by the customer ID.

Container Structure

{storage_account}.blob.core.windows.net/{customer_id}/
├── 0-payment_type.json                    # Global payment types
├── {customer_id}-account.json             # Account master data
├── {customer_id}-article.json             # Article master data
├── {customer_id}-article_dynamic_status.json
├── {customer_id}-business_unit.json       # Business unit master data
├── {customer_id}-customer.json            # Customer master data
├── {customer_id}-customer_client.json     # Customer client (loyalty/invoice) data
├── {customer_id}-installation.json        # Installation master data
├── {customer_id}-order_type.json          # Order type master data
├── {customer_id}-order_type_group.json    # Order type group master data
├── {customer_id}-revenue_unit.json        # Revenue unit master data
├── {customer_id}-terminal.json            # Terminal master data
├── {customer_id}-user.json                # User master data
├── {customer_id}-waste_reason.json        # Waste reason master data
├── {customer_id}/
│   ├── order/
│   │   └── {year}/{month}/{yyyymmdd}.json # Daily order data
│   └── article_waste/
│       └── {year}/{month}/{yyyymmdd}.json # Daily waste data

Authentication

Access to blob storage requires a SAS (Shared Access Signature) token with read and list permissions at the container level.

Listing Container Contents

# List all blobs in a container
curl "https://{storage}.blob.core.windows.net/{customer_id}?{sas_token}&restype=container&comp=list"

Fetching Data

# Fetch master data file
curl "https://{storage}.blob.core.windows.net/{customer_id}/{customer_id}-article.json?{sas_token}"

# Fetch daily transaction data
curl "https://{storage}.blob.core.windows.net/{customer_id}/{customer_id}/order/2026/01/20260120.json?{sas_token}"

Data Model Overview

The data model centers around the Order entity, which represents a sales transaction from a POS terminal.

Entity Relationships

Customer (tenant)
├── BusinessUnit (legal/organizational entity)
│   └── Installation (physical location)
│       └── Terminal (POS unit)
│           └── Order (transaction)
│               ├── Lines (items sold)
│               └── Payments (payment transactions)
├── RevenueUnit (reporting unit/cost center)
├── Article (products)
├── Account (GL accounts)
├── User (operators)
└── CustomerClient (loyalty/invoice customers)

Key Entities

• Customer - The top-level tenant/organization. All data is partitioned by customer_id.
• Order - Sales transaction containing lines (items) and payments.
• Terminal - POS device that commits orders. Links to Installation and BusinessUnit.
• Article - Products sold, organized in groups and sub-groups.
• Account - General ledger accounts for financial mapping.
• User - POS/Backoffice users who commit orders.

Design Principles

1. Tenant Isolation - All data is partitioned by customer_id
2. Denormalization - Key reference data (names, descriptions) is embedded for query convenience
3. Daily Granularity - Transaction data organized by business date (year/month/day)
4. snake_case Convention - All JSON property names use snake_case
5. Incremental Loading - Use high-water marks (soid) for incremental data fetching
6. Master Data Refresh - Basis data is updated completely each 24 hours