How to Synchronize Counterpoint Purchase Orders With Your Web Store

A connected retail operation depends on accurate movement of information between the shop floor, back office and online checkout. When Counterpoint holds supplier records, stock quantities and purchasing data while a web store manages customer orders, the connection between the two systems must be carefully defined. Otherwise, a purchase order can be duplicated, a sale can consume unavailable stock, or a buyer may receive an incorrect delivery promise.

Synchronizing purchase orders between Counterpoint and your web store is therefore less about pressing a single integration button and more about agreeing on data rules. Retailers moving away from NCR Retail Online should also remember that the product has been discontinued, so their replacement platform, connector and Counterpoint partner need to support the required workflows before any live orders are transferred.

Define what needs to move between systems

A purchase order is usually created when a retailer buys goods from a supplier. An online order is created when a customer buys from the retailer. These records are different, although they influence one another through stock availability, product status and fulfilment. A sensible integration should never treat every record as the same type of transaction.

Start by mapping the complete purchasing journey. Counterpoint may create a purchase order with a supplier, receive part of the shipment, update item costs and allocate units to stores or a warehouse. The web shop then needs the resulting stock position, product availability and estimated dispatch information. If a customer places a pre-order, the integration may also need to reserve incoming units without presenting the full purchase order as available stock.

Product identifiers are central to this process. Each item should have one reliable SKU, with consistent variations for size, colour or pack quantity. Supplier codes can remain in Counterpoint for purchasing, but the online platform needs a stable identifier that will not change when a supplier updates its catalogue. Include unit of measure, tax treatment, barcode, brand, dimensions and warehouse location in the field mapping.

Prepare Counterpoint and the online catalogue

Before activating an interface, clean the source data. Remove duplicate products, close old purchase orders and investigate negative stock balances. Confirm which Counterpoint location represents online inventory, whether stock is pooled across branches and how damaged, display or reserved items are excluded. A retailer with shops in Melbourne and Brisbane may need different replenishment rules from a single-location business in regional New South Wales.

Set a safety buffer for web availability. If a store has two units on hand, publishing both may create an overselling risk when a customer buys in person at the same time. A buffer of one or more units can be appropriate for fast-moving products, while high-value or bulky goods may require manual confirmation. This is especially useful for Australian retailers whose stock may be split between a city shop, a third-party warehouse and an interstate supplier.

Catalogue content also affects purchasing efficiency. Consistent product names, clear delivery dimensions and accurate imagery reduce customer service work when orders are delayed. A homewares seller can review its home décor range as a model for organising categories, variants and product descriptions before synchronisation begins.

Choose the direction and timing of updates

The safest design gives each system authority over the records it manages best. Counterpoint should generally remain the source for supplier details, landed cost, purchase order status, goods received and physical stock. The web store should remain the source for customer account details, online payment status, delivery address and the customer-facing order history.

The connector may send a purchase order from Counterpoint to a supplier portal rather than to the web store. More commonly, it sends receiving updates and available inventory to the online platform, while web orders travel back to Counterpoint for fulfilment and stock deduction. If a retailer wants customers to buy incoming stock, the integration can transmit expected quantities and dates as a separate availability status instead of inflating the current stock balance.

Decide whether updates are real-time, scheduled or event-based. Real-time inventory is valuable for popular products, while a five- or fifteen-minute schedule may be sufficient for a smaller Australian retailer. Consider weekend trading, public holidays and evening shopping habits: a Melbourne customer ordering after dinner should receive a truthful stock message even if the back office is closed. Every update should have a timestamp and an error status so staff can identify stale data quickly.

Test orders, receipts and exceptions

Testing should cover the ordinary path and the awkward cases. Create a supplier purchase order in Counterpoint, receive it in full, and verify that the web store shows the intended quantity. Then test a partial receipt, a cancelled line, a backordered item and a purchase order with multiple locations. Check that the connector does not publish stock before goods are physically received if that conflicts with the retailer’s policy.

Run the reverse flow as well. Place an online order, confirm that it appears in Counterpoint with the correct SKU and customer details, and check that stock is reserved or deducted only once. Test refunds, cancellations, split shipments, substitutions and orders containing both available and incoming items. A dedicated order sync test can help structure this validation when replacing an older NCR Retail Online connection.

Australian compliance belongs in the test script. Prices should handle the applicable 10 per cent GST treatment, including how tax is displayed to consumers and recorded in accounting. Returns and faulty goods must align with the Australian Consumer Law, so a cancelled or refunded order should not leave stock or payment records in an incorrect state. Delivery promises should also account for the distance between metropolitan areas and remote addresses rather than relying on a single national estimate.

Monitor the integration after launch

A successful launch needs operational monitoring, not just a completed setup. Assign someone to review failed messages, unmatched SKUs, quantity differences and purchase orders that remain open beyond their expected receipt date. Useful alerts include a sudden drop in online stock, repeated authentication failures, a duplicate order number or a price that changes unexpectedly.

Keep an audit trail for every important event. The record should show when Counterpoint created or amended a purchase order, when stock was received, when the web store accepted an update and whether the message was retried. Automatic retries are useful for temporary network problems, but they should not repeat a transaction that has already been accepted. Idempotent order numbers and duplicate checks prevent this common failure.

Security matters because the connection may carry customer names, addresses and purchasing history. Limit API permissions to the actions the connector actually needs, use strong credentials and remove access for former staff or suppliers. Retailers covered by the Privacy Act should handle personal information carefully, particularly when a web platform, fulfilment provider and integration partner all have access to the same order.

When changing domains or platforms, preserve the customer-facing paths that search engines and returning shoppers already know. Updating product, category and purchasing information is only part of the migration; sitemap and URL updates can help maintain discoverability after an NCR Retail Online transition.

A practical workflow is to make Counterpoint the authority for supplier purchasing and received stock, give the web store authority for online customer transactions, and document every field, status and exception between them. Test a complete purchase-to-sale cycle with real product scenarios, then monitor failed synchronisations daily so inaccurate availability is corrected before it becomes a customer problem.