Supply Chain E-Collaboration Portals for Retail Networks

Summary

We build supply chain e-collaboration portals for large retail networks running hypermarkets, supermarkets and e-commerce across many countries. The portal is the shared workspace between buyers and vendors: a single searchable catalog of stock-keeping units, role-specific views for category managers, buyers, store managers, merchandise managers, accountants and vendor staff, automated issuing and tracking of purchase orders, and reporting that all parties read from one source. Its commercial purpose is preventing out-of-stocks by making vendors active participants in stock monitoring rather than passive order recipients.

The Challenge

Every feeding system has its own product identifiers, so the hardest work is identity resolution: mapping vendor article numbers, internal SKUs and barcodes onto one catalog entry, and keeping that mapping correct as assortments change. Without it the portal shows plausible numbers nobody trusts, which is the failure state that ends adoption. Vendor-facing systems are internet-exposed and carry commercially sensitive pricing, so a vendor must see its own items, orders and stock positions and nothing belonging to a competitor. Availability expectations run around the clock and across time zones, because vendors work when they work. Volume is unforgiving: SKU counts and daily movement records in a national chain break naive queries and unbounded exports first.

The Solution

Core platform

• A relational core holding the SKU master, hierarchies, vendor agreements, order documents and movement history, with the catalog searchable by category, manufacturer, price, quantity and other parameters.
• A Java enterprise application tier with explicit transaction boundaries and a mapped persistence layer, deployed on an application server.
• A role and permission model that is genuinely multi-tenant at the vendor boundary, with row-level authorization enforced at the data layer rather than the screen.
• A document engine producing templated purchase orders and vendor correspondence, tracked through issue, acknowledgement, dispatch and receipt.
• A reporting layer serving real-time operational reports alongside heavier analytical extracts on separate read paths, so a large report cannot stall order entry.

Feeds and integration

The portal is an aggregation point, not an island. It consumes point-of-sale movement from checkouts, on-hand and receipt data from store systems, replenishment signals from the warehouse layer, financial records from accounting, and confirmations and advance shipping notices from vendors over structured message exchange in XML or an EDI dialect. Feeds are built idempotent and replayable with staging tables and reconciliation reports, so a late or duplicated file corrects itself rather than corrupting stock figures. Machine-to-machine paths exist beside the screens, because a portal that demands double entry alongside a vendor's own system is abandoned.

Build approach

The domain is modelled before screens are drawn, establishing SKU, vendor, agreement and order entities and their lifecycles, then layering role-specific workflows on top. Indexing strategy, pagination and asynchronous report generation belong in the initial design rather than in a later performance exercise. Test coverage runs at the service layer and through data-driven scenarios that exercise ordering against realistic assortment volumes. Build, dependency and logging tooling is set up so a production data question can be answered from logs without a code change. Timeliness is stated honestly per feed, since a report labelled real time that is actually a nightly extract destroys confidence in the whole platform.

What This Delivers

Buyers and vendors work from the same catalog and the same numbers, so ordering conversations start from agreed facts instead of reconciled spreadsheets. Vendors monitor their own stock positions and respond before shelves empty, which is the point of the exercise. Purchase orders are issued and tracked automatically, accounting sees consistent documents, and each role reaches the view it needs without ever seeing another vendor's commercial data. Auditability becomes a property of the platform rather than a reporting exercise.

Technologies and Tools

• Oracle Database for the SKU master, agreements, orders and movement history
• JEE with servlets and JSP, Spring and Hibernate on Oracle Application Server
• XML and EDI message exchange with vendor, store and warehouse systems
• JUnit, Ant and log4j for testing, build and operational logging