B2B home appliance wholesaler.

Situation

The wholesaler sells home appliances to businesses, not consumers. It has 1,293 products in the catalog and four price lists, because different customers buy on different terms. Sales reps visit customers and take orders on site, while Subiekt nexo (a Polish ERP) sits in the office and is the one that knows what is in stock and at what price.

The client's question was simple: can a sales rep at the customer's site see the same thing the office sees in Subiekt, without retyping orders.

What was not working

The problem was not the people, but the number of places where the same data lived.

• An order from the field came back to the office as a photo of a sheet of paper or a spreadsheet, and someone retyped it into Subiekt by hand, usually at the end of the day.
• The customer's price list was checked from memory or in a separate file; a mistake ended in a credit note and a phone call from the customer.
• A B2B customer could see neither availability nor order status without calling the office, so phone calls ate the time that should have gone into selling.

What we built

Instead of one big system, four components were built, each with a clear job, tied together by an integration hub. The hub is the only thing that talks to Subiekt nexo: a .NET 8 layer sits next to Subiekt and works on its data through Sfera, and Node.js exposes an API for the app, the portal and the chatbot.

• Sales rep app for tablets (React Native): catalog, the price list assigned to the customer, stock levels from the last sync and order entry at the customer's site, with barcodes scanned by phone. Works offline and sends orders once the network is back.
• B2B portal: the customer logs in to a company account, sees their prices, availability and order history and orders without calling the office.
• LLM chatbot for B2B customers: answers questions about availability, prices from the customer's price list and order status based on data from Subiekt, and hands the conversation over to a human when it does not know.
• Integration hub: order queue, price list mapping, creating ZK (sales order) documents in Subiekt nexo and sending statuses back to the portal, the app and the chatbot.

How it works day to day

The sales rep picks products on the tablet and the app immediately shows prices from the right price list. The order goes to the hub, which checks the customer and the line items in Subiekt and creates a ZK. The order number is generated on the tablet, so when the app sends it a second time after losing the signal, the hub recognizes the duplicate and there is only one document in Subiekt.

The customer gets a confirmation and checks the order status in the portal or asks the chatbot. The office no longer retypes anything; it handles the exceptions the hub puts on a separate list: unknown customer, price outside the price list, item out of stock.

Results

Around 180 hours of manual work less per month: retyping, checking price lists and answering the same questions about availability. Four systems work on the same data, and Subiekt nexo became the only place where stock levels, prices and documents live.

The code belongs to the wholesaler. There is no subscription for a middleman and nobody will change its limits when volume grows.

What we learned

Working in stages paid off. First the hub and the tablet app, because that hurt the most; the portal and the chatbot came later, once the data in Subiekt was already in order. The client had a working tool after the first stage, and we had fewer unknowns in the next ones.

Second thing: one owner of the data. Subiekt is the source of truth, everything else reads and reports. Without that rule each of the four components would have its own version of stock levels and we would be back to Excel, only a more expensive one.

And honestly: if the wholesaler had one price list and two sales reps working from the office, an off-the-shelf B2B portal on a subscription would probably have been enough. Here, four price lists, field work and Subiekt on the client's own server rather than in the cloud were what settled the case for custom code.