What the solution is
k-eCommerce is a B2B commerce platform from k-eCommerce, today part of the Canadian group mdf commerce. The storefront, the backend and the integration come from the same vendor, and everything is hosted in the vendor's own cloud, which is PCI-DSS certified. That last point is worth noting, because it moves part of the card data responsibility away from you.
The solution is built for the smaller and mid-sized company, and that shows in the subscription tiers. Business Central is named on the entry tier alongside Dynamics GP, NAV and SAP Business One, and the more advanced capabilities such as quote management and automated returns handling sit on the upper tiers.
How the integration works
The integration is the vendor's own synchronisation technology, and it is not a separate connector you install and maintain. It reads and writes Business Central data, and the vendor points out itself that it does so without adding traffic load to the ERP. This is the opposite trade-off to the solutions that look prices up live: the store becomes fast and independent of the ERP's response time, but data in the store is as fresh as the synchronisation is set to be.
Because the ERP is not asked along the way, the solution works both against Business Central online and against the older installations on your own servers. That GP and NAV appear on the list of supported ERPs is itself a sign that the synchronisation can work against a local environment.
The thing to settle early is how often what is synchronised. Stock and prices tolerate different intervals, and it is a decision with consequences both for the customer experience and for how often someone has to clean up after a transfer.
Prices, discounts and agreements
Customer-specific prices, multi-level prices and customer-specific catalogues come from Business Central. They are not calculated in the storefront, but they are not calculated in the ERP while the buyer is on the page either. They are transferred as a result, meaning a finished price per customer per item.
It is a well-proven model, and for most companies it works. It does carry a scaling trap worth knowing: a flat price matrix is the number of customers times the number of items. Two thousand customers and ten thousand items is twenty million rows that have to be kept fresh. That is a common reason a synchronised solution slows down after a couple of years, and it is a question to put directly to the vendor with your own figures on the table.
For campaigns the storefront has its own engine, including buy one get one. That is why the solution carries the label for logic set up in two places. If the campaign is meant as an ERP-driven agreed price, it belongs in Business Central. If it is meant as a marketing push with an end date, it belongs in the storefront. Decide that beforehand, not along the way.
The order and the finance function
The order lands as a sales order in Business Central, and from there it follows the ERP's ordinary flow with picking, shipping and invoicing. Partial shipments and back orders are therefore handled by Business Central itself.
Automated returns handling exists, but on the top subscription tier. That is an item easy to overlook in a quotation comparison, and expensive to discover afterwards if you have many returns.
Payment is charged at checkout through the vendor's own payment component. The aggregated settlement from the payment provider still has to be matched against the general ledger, and fees vary per transaction. Ask to see what one day's settlement looks like in Business Central before counting that job as solved.
Who the solution fits
The solution fits a smaller or mid-sized wholesaler or manufacturer selling to known customers, and which wants a predictable subscription rather than an open-ended project. The public price list makes it possible to set a budget before talking to a salesperson, and not many in the catalogue allow that.
It also fits if you value card data and the payment flow sitting with the vendor in a certified environment, rather than being something you have to document to an auditor yourself.
The solution fits less well if the pricing logic in Business Central is very large or very dynamic, meaning many thousand customers times many thousand items, or prices that depend on the contents of the basket. There, live lookups in the ERP are the better model, and that is a different kind of solution.
What to settle before you decide
Pricing is public, and that is an advantage. The entry tier stands at around twelve hundred dollars a month, the most-sold tier at just over two thousand, and the top standard tier just under twenty-five hundred. Implementation is not in those figures, and a number of capabilities are sold as add-ons with both a one-off and a monthly amount.
Read the add-on list before comparing. Quote management, promotions and returns handling stand as separate items, and a setup that on paper sits on the entry tier can end up a whole tier higher once the necessary add-ons are counted.
Ask about the number of rows in the price matrix at your own size, and ask what happens to response times as that number grows. That is the one technical risk worth spending a meeting on with this solution.