SambaPOS IT best practices

V5 Question
1

I am an IT SambaPOS Reseller. I work for some restaurants customizing SambaPOS for their needs.

Sometimes I do quite few changes for a restaurant. What I do is implement the changes at home and then apply them into my customer’s restaurants.

I use the “Export to file” button at database tools. This allows me to export Entity Types, Entity Screens, Actions, Rules, States, etc. This is very good. I import these file into the Restaurats’ databases and it works well.

Well… sometimes I wish that some more things could be exported like: Entities, Products, Menus, etc.

This is my workflow:

  1. Take a backup of the restaurant’s database home.
  2. Implement my solution (create rules, entities, states, entity types, entity screens, products, menus, terminals, etc, etc,… ) and test it.
  3. Export to a file as many of the items created in step 2.
  4. Painfully recreate by hand some items I know were not exported like: Menus, Entities, etc.
  5. Import the file into the Restaurat’s database.
  6. Painfully copy the remaining items by hand (my laptop screen to my customer’s PC… line by line, item by item).
  7. Re-Test
  8. Pray it works!!!

Does anyone have a better workflow? Can anyone in the SambaPOS team suggest a set of best practices?

2

You can just backup the whole database through MS SQL Server Manegment Studio? Then import it at home and you have exactly the same setup. Then make your changes and import that database back into the restaurant server.

3

What if the time you need to investigate and implement is two days or more?

In my case I would have to get a copy of the database at 1:30 am (when restaurants close) and return it before 6:30 pm (when restaurants open). This gives me a small window of time for development some times.

4

I would…

  1. Take a back-up of the cleints database with you
  2. Do what you can with DB-Tools imports
  3. Work out what else needs to be implemented
  4. Write specific SQL scripts to alter the DB for the other elements that cannot be done via DB-Tools
  5. Test it
  6. Test it again
  7. Go to the client, take another backup
  8. Deploy you DB-Tools and SQL scripts
  9. Test it, if it works, leave it. If not, roll back to the DB you just backed up

I am working out something similar to streamline the process of setting up the SambaPOS implementation I have built for my business. For example, I need to add a sales tax…

#Using DB-Tools I create…

  • A tax template called “IVA”
  • A transaction type called "SALES Tax - IVA

#Using SQL…

I map this tax to the apropriate product categories

BEGIN TRANSACTION
   DECLARE @NewID int;
   DECLARE @TransactionTypeID int;
   DECLARE @SalesTicketID int;
   SET @TransactionTypeID = (SELECT ID FROM AccountTransactionTypes WHERE Name = 'SALES Tax - IVA')
   SET @SalesTicketID = (SELECT ID FROM TicketTypes WHERE Name = 'SALES Ticket')
   INSERT INTO TaxTemplates (SortOrder,Rate,Rounding,Name,AccountTransactionType_Id) VALUES (0,16,0,'IVA',@TransactionTypeID);
   SELECT @NewID = scope_identity();
   INSERT INTO TaxTemplateMaps (TaxTemplateId,MenuItemGroupCode,MenuItemId,TerminalId,DepartmentId,UserRoleId,TicketTypeId) VALUES (@NewID,'BCDs',0,0,0,0,@SalesTicketID)
   INSERT INTO TaxTemplateMaps (TaxTemplateId,MenuItemGroupCode,MenuItemId,TerminalId,DepartmentId,UserRoleId,TicketTypeId) VALUES (@NewID,'Courses',0,0,0,0,@SalesTicketID)
   INSERT INTO TaxTemplateMaps (TaxTemplateId,MenuItemGroupCode,MenuItemId,TerminalId,DepartmentId,UserRoleId,TicketTypeId) VALUES (@NewID,'Diving',0,0,0,0,@SalesTicketID)
   INSERT INTO TaxTemplateMaps (TaxTemplateId,MenuItemGroupCode,MenuItemId,TerminalId,DepartmentId,UserRoleId,TicketTypeId) VALUES (@NewID,'Masks',0,0,0,0,@SalesTicketID)
   INSERT INTO TaxTemplateMaps (TaxTemplateId,MenuItemGroupCode,MenuItemId,TerminalId,DepartmentId,UserRoleId,TicketTypeId) VALUES (@NewID,'Rental',0,0,0,0,@SalesTicketID)
   INSERT INTO TaxTemplateMaps (TaxTemplateId,MenuItemGroupCode,MenuItemId,TerminalId,DepartmentId,UserRoleId,TicketTypeId) VALUES (@NewID,'Wetsuits',0,0,0,0,@SalesTicketID)
COMMIT

This is risky to apply at whim, but if you already have the customer’s DB, then you know exactly what valeus you will be altering.

This is also probably terribly inefficient SQL and @QMcKay can probably give you some good tips on improving this type of thing.

5

I have 2 businesses. I develop and test on my Laptop at home.

I do take backups home with me, load one of them, and start making changes.

I save everything as DB Tools files when I am confident all my tests are good.

The problem with simply restoring the DB is that it could take days for me to do my testing, during which time many transactions would have occurred, so restoring is out of the question.

DB Tools is the only way to go for me most of the time.

And yes, in some cases, I need to do manual modifications “live” on the Production DB for certain things that are not supported in DB Tools, but this is usually rare for me.

My biggest pain was Inventory. I spent weeks getting it “just right” on my Laptop, and there is no facility in DB Tools for Inventory, for what I believe to be obvious reasons (at least Transaction-wise). So in the end, I spent hours changing Inventory on a live Prod system. Scary, but had to be done… there is no other way.

1 Like