Get in Touch
← Back to case studies

E-commerce · Wholesale operations

Getting wholesale products from the back office to the buyer

Shinetech restored a broken catalog-indexing path, refined warehouse receiving rules, and improved reporting within an operating wholesale commerce platform.

  • Product search
  • Warehouse rules
  • Operational recovery
  • Legacy modernization

At a glance

Business need
Keep catalog changes and warehouse work reliable
Product
Wholesale storefront and back-office services
Delivery
Continuous improvement and support
Technology
Web commerce, search, and data services

The business context

Saving a product was not the same as making it available to buy.

For a fashion and accessories wholesaler, the online catalog is where retailers discover merchandise for their own stores. Product collections, available stock, and order fulfillment are closely connected. An item can exist in the administration system yet still be missing from the buying experience if a downstream update fails.

The client already ran its business on a custom commerce platform. Storefronts, administration screens, background jobs, and related sites shared core code and data. Shinetech’s work focused on keeping that established operation usable while improving the parts that were creating manual intervention: product discovery, receiving, and large operational exports.

Reconstructed wholesale product administration showing jewelry records, search visibility, and a receiving-bin assignment.
System view

From catalog record to warehouse task

A product record ties a catalog update to its search status and receiving context. Product images, SKUs, quantities, and times are invented; this reconstruction illustrates the workflow, not the client’s interface. View full-size interface (new tab)

The operating challenge

The visible symptom was in the storefront. The cause was elsewhere.

Product and category changes stopped reaching the storefront because the search index was no longer updating successfully. The failure crossed several layers. A deleted log file was still held open by a running process, so deleting it had not released the occupied disk space. The disk filled, indexing failed, and a scheduled restart had also been ineffective because of its execution environment.

Fixing the edit screen would not have repaired this chain. The team traced the path from saved product data through the background process and search service, addressed the storage and restart problems, and restored indexing. The business check was whether an updated product could make it through to the buyer-facing catalog again.

The delivery decisions

Repair the operating path, including the exceptions.

  1. 01

    Verify the result where the buyer sees it

    The recovery connected server investigation to catalog behavior. Restoring a background process was a necessary step; confirming that changed product data reached the search index established what the repair meant for operations. This kept the work focused on the full route from a merchandise update to a discoverable item.

  2. 02

    Let receiving continue when the preferred bins are full

    Warehouse allocation needed a specific fallback: use a small bin first, use an extra-small bin when that preferred capacity is exhausted, and return to the original preference when small bins become available. Shinetech implemented that sequence in the existing workflow. The recovery condition matters as much as the fallback; otherwise a temporary shortage can turn into a permanent allocation habit.

  3. 03

    Make larger exports practical

    Operational reports had another constraint: assembling a large CSV in memory could make exporting unreliable. The team changed the export to write data progressively and refined inventory-report presentation and sorting. Staff could retrieve the operating data through the established reporting workflow without the application having to retain the entire export at once.

How the workflow holds together

The platform could not be treated as an isolated website.

Working across dependencies

A deployment change could affect the storefront, administration, background tasks, and related sites together. Infrastructure work therefore included configuration compatibility, checks in separate environments, gradual switching, and a rollback path. The objective was to improve the system with an understanding of the dependencies that were already carrying orders and warehouse work.

This engagement combined fault investigation with smaller business-rule changes. Those activities addressed the same practical concern: whether the next person in the process could complete their task. A saved category change had to become visible; a received item needed an available location; an operations report needed to finish exporting.

The delivered result

Catalog visibility, receiving, and reporting had working paths again.

Catalog recovery

Product and category changes could reach the search index after the interrupted update path was restored.

Receiving continuity

Explicit bin priorities handle shortages and return to the preferred type when capacity is available.

Progressive exports

Large CSV output is written in stages, reducing the need to hold all rows in memory.

Development and maintenance continue on the existing platform. The case documents operational repairs and capabilities, without attributing sales growth or a zero-downtime outcome to them.

Case taxonomy

Searchable by industry, technology, product, and business need.

Industry and product

  • E-commerce & Retail
  • Wholesale operations
  • B2B commerce

Technology and delivery

  • Web commerce
  • Search indexing
  • Data services
  • Legacy modernization

Business need

  • Product search
  • Warehouse rules
  • Operational recovery
  • Inventory receiving
  • Reporting