Im currently working on a retail project that will use LS retail (backoffice) they use ALOHA POS’s on the front end, which will eventually be replaced with LS POS. I have to give some smart input into how to get the transaction data from Aloha pos into LS retail on a daily basis until Aloha is replaced.
Does someone have any experiance in moving sales transaction data from Aloha pos into LS retail 5.0 (SQL DB)
I have identified the LS retail tables (Transaction Header, Trans. Sales Entry and Trans. Payment Entry) and can get the Aloha data into some sql staging tables.
I would appreciate, any recommendations, comments, hints experiences etc. with 3rd party Alhoa POS
Personally I would do it in such a way that it’s “invisible” to LS Back office. That way it woudl be easy to do the transition, and further more you can transition POS stations accross progressively.
Is this two way? I.e. do you need LS to update Items, prices barcodes etc? Or are you doing that some other way?
I would recomend creating a new seperate databse that interfaces to the Alhoa POS, and gets data in a format the same as it is in LS. Then use the LS Replicator to pull the Data in to LS Retal Back office. Personally I would create the tables in that staging database using Navision table designer, so that you get all the formats correct.
David, Thanks for the suggestions and quick response.
Fortunately,this will only be a one-way process, pulling Sales, and payment transaction data from the pos only, i.e. no updating back to the POS.
When you say “invisible” to LS back office what do you mean? Aloha creates consolidated daily feed of all the POS’s The plan is then take that data and pump it into SQL and use LS DD. I think designing the tables in NAV is a great Idea, The big job now is mapping the Aloha data to match the LS fields,
By invisible, I mean create a process that converts the Aloha data to look exactly like LS Retail POS, so that backoffice just sees this as a normal LS Retail POS. That way you dont make any changes to LS Back office.
Your plan seems fine, Djoeg and pretty typical of what folks do when migrating from a large POS install base.
I don’t think you’re going to have a problem mapping the fields – POS tables are really very similar.
There is something you should bear in mind – LS transactions are “large” in the sense that they do in several tables what many systems do in just one. You should be aware of the number of transactions you are pulling into the db and how it will effect size when you convert it into a LS transactions. The databases can get very big, very quickly.
How will the stores know what their current inventory levels are?
Sorry to bring up an old post. Were you ever able to find a guide as to the table structure of Aloha? We use Aloha in one of our restaurants but Dynamics GP for accounting. I’m not looking to import the data into GP but am looking to import it into SQL Server in or to do some dashboards. I have a folder of the data from one day and did learn that the tables beginning with “G” are the daily summaries. I was thinking of adding the data as a linked server but also considering SSIS to import into a new table in the GP company database.