KVN
System registry
SYS-0032024-06–2025-07

Sales Distribution System

A production field-sales and distribution system connecting responsive browser workflows to SAP through a protected SOAP integration layer.

TypeSystemEngagementFormer EmploymentTierCase StudyStateDelivered To ProductionActivityEnded
01

Context

The system combines a React/Vite field-sales interface with a .NET 8 ASP.NET Core API and MariaDB operational store. It supports role-aware customer and visit workflows, SAP-authoritative materials and pricing, sales and return orders, inventory, warehouse transfers, billing and fiscal data, and Bluetooth invoice printing. Recurring backend services synchronize selected master and operational data while transactional decisions remain connected to SAP in real time.

Core engineering problem

Give field-sales teams a focused, role-aware application over SAP sales and distribution capabilities without exposing SAP credentials or generated SOAP contracts to the browser.

The application translates browser-oriented field workflows into a mixture of real-time SAP transactions and locally persisted operational processes.

  • Keep SAP SOAP credentials, generated contracts, and company-specific request data on the backend.
  • Preserve SAP as the authority for customer-specific material availability, pricing, discounts, and accepted orders.
  • Support different inventory and order paths for internal and distributor field agents.
  • Keep synchronized master data useful locally without treating snapshots as authoritative transactional state.
  • Support geolocation and portable invoice printing from a responsive browser application.
02

My role

At S-Systems, I designed and implemented the application layer across both repositories: the responsive field-sales client, ASP.NET Core backend, local operational model, authorization, workflow orchestration, background synchronization, and SAP integration.

Contribution boundaries

  • Sap ServicesA collaborating SAP engineer created and exposed the SAP services; I implemented their application-side consumption.
  • Unfinished ModulesSurvey and sales-target modules were not completed and are excluded from delivered capabilities.
  • Client IdentityThe client remains anonymous.
Architected

Application Architecture

Responsive browser client, ASP.NET Core application API, local operational model, and application workflows.

ArchitectedDesignedImplemented
Implemented

Backend And Frontend

Role-aware field-sales interface and backend application behavior across both repositories.

ImplementedMaintained

Enterprise Integration

SOAP consumption, mapping, orchestration, periodic synchronization, and application-side error handling.

IntegratedImplemented
Designed

Domain Model

Users, customers, routes, visits, orders, inventory, billing references, and synchronized master data.

DesignedModelledImplemented
Contributed

Production Delivery

Delivery of the completed core system to production during my time at S-Systems.

ContributedDeployed

Collaboration credit

  • Collaborating SAP engineerCreated and exposed the SAP SOAP services consumed by the application.
03

Architecture

Level 01 / System

System context

08 boundaries · 08 declared relationships

  1. 01Responsive React field-sales clientClient
  2. 02ASP.NET Core application APIAPI
  3. 03MariaDB operational storeDatastore
  4. 04Recurring synchronization servicesWorker
  5. 05SAP SOAP service boundaryExternal Provider
  6. 06External taxpayer lookupExternal Provider
  7. 07Geolocation and Bluetooth printer APIsExternal Provider
  8. 08IIS application runtimeInfrastructure
Relationship mapInspect 08 connections
  • Responsive React field-sales clientRequestASP.NET Core application API
  • ASP.NET Core application APIPersistenceMariaDB operational store
  • ASP.NET Core application APIIntegrationSAP SOAP service boundary
  • Recurring synchronization servicesIntegrationSAP SOAP service boundary
  • Recurring synchronization servicesSynchronizationMariaDB operational store
  • ASP.NET Core application APIIntegrationExternal taxpayer lookup
  • Responsive React field-sales clientIntegrationGeolocation and Bluetooth printer APIs
  • IIS application runtimeHostingASP.NET Core application API
04

Engineering decisions

01

Isolate SAP SOAP services behind an application API

Context

Browser field workflows needed SAP capabilities without exposing credentials or generated enterprise-service contracts.

Selected approach

Use ASP.NET Core to authorize, orchestrate, map, and persist workflows around the SAP SOAP boundary.

Rationale

Present stable application contracts to React while keeping SOAP credentials, bindings, and generated types server-side.

Trade-offs

  • Generated clients and mapping code must evolve with SAP contracts.
  • The backend owns integration failure handling as well as application workflow rules.
02

Combine periodic synchronization with real-time SAP transactions

Context

Master/reference data and commercial transactions have different freshness and authority requirements.

Selected approach

Synchronize selected data locally while keeping pricing, simulation, and order operations connected to SAP in real time.

Rationale

Support responsive local workflows without replacing SAP as the transactional authority.

Trade-offs

  • Local snapshots have explicit staleness windows.
  • Synchronizers need independent scheduling, retry, and replacement/update behavior.
03

Simulate orders before final creation

Context

Customer, channel, product, quantity, and promotion context can change commercial results.

Selected approach

Ask SAP to simulate the draft, map the authoritative result back into the application, then submit the final order.

Rationale

Keep prices, taxes, discounts, and promotions aligned with the ERP.

Trade-offs

  • Order submission requires an additional integration round trip.
  • Simulation and creation mappings must remain compatible.
04

Persist application workflow state alongside SAP

Context

Route plans, visits, user hierarchy, device workflows, and local history do not map to a single ERP transaction.

Selected approach

Store application-owned operational state locally while retaining SAP identifiers and authority at integration boundaries.

Rationale

Support field workflows without treating the local database as the commercial system of record.

Trade-offs

  • Cross-system state requires explicit mapping and error handling.
  • Synchronized records may temporarily lag external changes.
05

Use browser APIs for field context and printing

Context

Field agents need location context and portable receipt printing from a responsive application.

Selected approach

Integrate geolocation and supported Bluetooth printers directly from the browser client.

Rationale

Retain one browser delivery stack while supporting essential field-device workflows.

Trade-offs

  • Capability depends on browser/device support and user permission.
  • Bluetooth connection and printer commands must be handled in frontend code.
05

Runtime ownership

  1. 01
    Reverse Proxy

    ASP.NET Core is configured for IIS integration and in-process hosting.

  2. 02
    Storage

    MariaDB stores application-owned operational and synchronized state.

    Inspect operational detail
    • Identities, assignments, visits, routes, local order history, billing references, and stock snapshots
  3. 03
    Logging

    ASP.NET Core logging integrates with Windows Event Log outside local development.

  4. 04
    Scheduled Tasks

    Independent schedules refresh customer, material, reference, stock, billing-state, and route data.

  5. 05
    Background Jobs

    Hosted services isolate recurring synchronization responsibilities.

  6. 06
    Deployment

    The .NET 8 backend and React/Vite client were delivered to production during my time at S-Systems.

06

Current state

  1. Current

    The completed core system was deployed to production during my time at S-Systems.

  2. Lesson

    Separate completed production evidence from well-defined but unfinished product concepts.

Depth B / Technical inspection

Inspect supporting evidence

Domains, provider boundaries, and evidence classifications.

T1

Domain structure

  • Identity and accessAccount lifecycle, role-aware navigation, lockout handling, and policy-protected administration.
  • Users and sales hierarchyManagers, field agents, reporting relationships, assignments, and internal/distributor configuration.
  • Customers and business partnersAssigned customer access, geospatial selection, taxpayer lookup, and SAP business-partner creation.
  • Route planning and visitsCyclic route plans, daily customer sequences, planned/unplanned visits, geolocation, completion, and rejection reasons.
  • Materials, pricing, and inventoryCustomer-specific materials, availability, prices, discounts, free goods, stock snapshots, and catalog refresh.
  • Sales ordersDrafting, SAP simulation, authoritative commercial results, final creation, local history, and status retrieval.
  • ReturnsBilling-document selection, full and partial quantities, return reasons, and SAP return-order creation.
  • Warehouse transfersInventory selection and SAP-backed stock-transfer orders between configured locations.
  • Billing and invoice printingBilling/fiscal retrieval, printable invoice generation, QR data, reprinting, and Bluetooth receipt output.
  • Data synchronizationRecurring customer, material, reference-data, distributor-stock, and route-plan maintenance.
T2

Integrations

  • Enterprise ErpSAP sales and distribution services

    Customer and material data, pricing and order simulation, sales/return orders, stock transfers, billing/fiscal information, stock, and reference data.

    SOAP through generated WCF clients
  • Business ValidationExternal taxpayer registry

    Assist new business-partner onboarding without exposing the provider to the browser.

    Backend-mediated HTTP lookup
  • Field ContextBrowser geolocation

    Capture field context for customer and visit workflows.

    Web Geolocation API
  • Field HardwareBluetooth receipt printing

    Print invoices and stock information from supported field devices.

    Web Bluetooth API
T3

Capability evidence

  • System architectureI designed the responsive client, application API, local model, and SAP-facing boundaries.
  • API designI implemented role-aware ASP.NET Core workflows over SAP and local application state.
  • Frontend deliveryI implemented the responsive React field-sales application.
  • Systems integrationI consumed generated SAP SOAP services without exposing contracts or credentials to the browser.
  • Domain modellingI designed application-owned route, visit, user, order, billing-reference, and synchronization state.
  • Authentication and authorizationI implemented role, hierarchy, assignment, and protected administration behavior.
  • Background processingI implemented recurring master, stock, reference-data, and route synchronization services.
  • Relational persistenceI maintained MariaDB application state and schema migrations alongside SAP identifiers.
  • Field-device integrationI integrated browser geolocation and Bluetooth receipt printing.
  • Deployment and operationsI contributed to the production delivery of the completed core system.