IProcessor for GMD Stores: From Vendor Invoice to Store Shelf in One Web App

Part 1 of 2. This post introduces the product and walks through the web application. Part 2 covers the invoice-parsing engine, the technology stack and the CI/CD pipeline.

What is IProcessor?

IProcessor is an internal operations platform built for GMD Stores, a multi-store retail business that buys from dozens of import vendors and ships goods through its own warehouse. Every week the business receives a flood of vendor invoices as PDF attachments, has to reconcile them against purchase orders, receive the goods, split them by store, verify pick-and-pack, and account for margins.

Before IProcessor, most of this was manual data entry and spreadsheets. IProcessor turns it into a single flow:

1. A vendor emails an invoice PDF to a shared mailbox.
2. A background service picks it up, identifies the vendor, extracts every line item and saves it to the database. No human touches it.
3. Buyers and accounting review and approve the invoice in the web app.
4. Warehouse staff receive containers, scan items out, verify pick-and-pack with RFID, and print Zebra labels from the same screens.
5. Accounting gets margin and cost-change reports straight from the data.

The platform has two main pieces:

• IProcessorWebsite: the ASP.NET MVC web application that everyone uses day to day. This post is about it.
• IProcessorPdfParser: an always-on Azure WebJob that listens to the mailbox and parses invoices. Covered in Part 2.

Who uses it

Access is role based. Each role sees a different default landing page and a different menu:

Role	Typical tasks
Admin	Everything, plus user and role management, vendor configuration, system settings
Buyer	Review parsed invoices, approve or reject, adjust order quantities
Accounting	Accounting reports, margin reports, cost-change history, invoice history
Warehouse Manager	Container items, scan outgoing, pick-and-pack verification, RFID, label printing
Store Manager	Print invoices for their store, look up items and invoices

Feature tour of IProcessorWebsite

1. Invoice management

This is the heart of the app. Every invoice that the parser extracts lands here with its status:

• Processed: freshly parsed, waiting for review. Users open the line items, compare them with the original PDF (served from Azure Blob Storage), and fix anything the parser got wrong.
• Approved: signed off by a buyer or accounting. Approved invoices feed inventory and the store print queue.
• Disabled / Deleted: rejected or duplicate invoices, kept for audit.
• History: a full change log per invoice, so you can see who edited what and when.

Admins can also check whether the parser service is alive and restart it from the browser, which is handy when the mailbox connection drops.

2. Upload invoices and Excel files

Not every vendor emails a clean PDF. The Upload screen lets a user drag in an invoice PDF manually and push it through the same parsing pipeline. A second uploader accepts Excel files (order lists, master item lists, container manifests) and imports them with ExcelDataReader and EPPlus, so bulk updates never need a developer.

3. Inventory

The inventory module shows current stock per item and per store, backed by the DBInventory and purchase-history tables. Inventory updates are logged in an update-history table so every quantity change can be traced back to an invoice, a scan or a manual edit.

4. Container items

Goods from overseas vendors arrive in shipping containers. The Container Items screen lets the warehouse upload the container manifest, view its line items, mark items as received, and print labels for each carton as it comes off the truck. Items scanned out of a container are tracked separately for China-sourced shipments.

5. Scan outgoing

When an order leaves the warehouse for a store, staff scan each item’s barcode or RFID tag. The system records what went out, to which store and by whom, and keeps a searchable history. Mistaken scans can be removed by a manager.

6. Pick-and-pack verify with RFID

This is where RFID pays off. After an order is packed, the packer scans the whole pallet or box. The app compares the list of scanned RFID tags with the approved invoice and shows a pass or fail per line. Managers can force-verify an order when a tag is missing or damaged. Results are stored in PickAndPackResults for later audit.

7. RFID lookup and stationary RFID

• Search by RFID: type or scan a tag and instantly see which item, invoice and store it belongs to. A separate path handles tags from the Young International product line, which use a different numbering scheme.
• Stationary RFID: generates and manages fixed RFID numbers for shelves, bins and fixtures, and prints their labels.

8. Zebra label printing in the browser

Label printing is built into the invoice, container, and RFID screens using Zebra BrowserPrint. The page talks directly to the Zebra printer connected to the user’s PC, so there is no print dialog and no driver fiddling. One click prints item labels, carton labels or RFID tags with the right barcode, description and store code.

9. Print invoice for store

Store managers see only the invoices for their location. They can print a packing list, mark an invoice as received, and adjust order quantities when the store received more or less than expected. Those adjustments flow back into inventory and accounting.

10. Search

Three dedicated search screens cover the most common questions on the warehouse floor: find by invoice number, find by item number, and find by RFID. Each one returns the item, its vendor, the invoice it came in on, and where it is now.

11. Accounting and margin reports

Accounting gets a consolidated report per period with invoice totals, approved versus received quantities, and payment status. A Margin Report compares vendor cost against selling price per item, and a Cost Change Report flags items whose vendor price moved between invoices. All reports export to Excel.

12. Vendor configuration: headers and keywords

Two small but critical admin screens make the parser smarter without redeploying code:

• Header Configuration for Vendors: tells the parser which column titles a vendor uses for item number, description, quantity, unit price and total. When a vendor changes its invoice layout, an admin updates the header mapping and the next invoice parses correctly.
• Vendor Keywords: unique words or phrases that identify a vendor on the first page of a PDF, and text that should be ignored (footers, terms, disclaimers). Both tables keep a history so changes can be rolled back.

13. Users, roles and settings

Built on ASP.NET Identity. Admins create users, assign one or more roles, reset passwords and see login history. A Settings screen holds runtime configuration such as notification recipients, file paths and email templates, so most tuning happens in the UI rather than in config files.

14. Email templates and notifications

Every automated email (parse failure, vendor not found, totals mismatch, daily summary) uses an editable template stored in the database. Accounting can change the wording or recipients themselves.

What it feels like to use

The UI is a responsive Bootstrap 4 admin theme with a left sidebar that changes by role. Most screens are jQuery DataTables with server-side JSON, so lists of tens of thousands of line items stay fast. Forms use unobtrusive validation and AJAX partial updates, which matters on a warehouse tablet over Wi-Fi.

Results

• Invoice data entry dropped from hours per day to review-only.
• Over 60 vendors are parsed automatically, each with its own layout.
• Pick-and-pack errors are caught before the truck leaves, not at the store.
• Accounting reports come from one database instead of several spreadsheets.

In Part 2 we open the hood: how the invoice-parsing WebJob works, which libraries we picked and why, and how the GitLab pipeline deploys to Azure with zero-downtime slot swaps.