POS Integration, another approach

We know that Business Central doesn’t have a Point of Sale so, we need to use another solution like LS Retail or Shopify with some problems and costs.

Which are those problems?

Well, LS Retail doesn’t have a “real” Saas solution, and this is because if you have a store with POS, you cannot stop your selling process just because your internet “leaves the room”, same thing with Shopify. LS Retail asks for a local server and then you sync the local info with the central system sometimes every transaction and others every X hours.

A long time ago, a friend and I talked about the problems generated by developing a point of sale in Dynamics NAV, considering that POS is a very specific “vertical area” for what it should do and what operations it carries out. Then, we make a sell that needs a POS.

The customer showed us his POS development, that POS covers his needs to 100% and works locally in each store (25~ stores at that time), SQL as DB.

So, the best approach was to make an integration between his POS and NAV.

Why this? Easy, the POS system is a vertical solution developed to make sales and collect them with cash or credit card or other payment options, an ERP makes a lot more than that but lacks some other POS functions like loyalty plans, mix and match, points, etcetera and joining both systems can get the best of both worlds.

In that time, we make some tables to allow integration between systems, POS can insert new customers, sales and returns, payments, also, can read customers, products, inventory, serials, etcetera and everything runs in SQL.

Now, we have webservices and if we have a lead or customer who wants to use POS in the daily operations, we have LS Retail or Shopify but, what happens if the customer is fine with their actual POS? can we make an integration?.

With the actual tools we can do that easily if the POS can use this API technology and keep your beloved and highly functional POS joining it with a ERP.

With this in mind, I recreate the tables and codeunits to support this integration with some new pages to use them as webservices for connection, also, I made changes because now we use queues instead NAS.

For the Setup, we added the next fields and we need to choose a Payment Template Name and a Sales Document Reason Code to “mark” those sales for easy reporting later.

We have 2 pages, one for headers and one for lines

In Codeunit POSOperations exists 3 “hard values”, 2 for the jobqueue entry and one for a payment source code, the payment source code can be modified for a setup value but you can do that later

We have more tables, for processed records and other for wrong records to avoid queue stops, if something is wrong, we need to move to other table and keep the queue processing.

I put the full code in https://github.com/fbedolla/POSInteg if you want to check it, use it or make it better.