Support Multiple Stores

Have a great idea or code for PHP Point Of Sale? Discuss ideas here!

Do you want multiple store support by the system?

Poll ended at Tue Jun 22, 2010 9:22 am

Yes
5
83%
No
1
17%
 
Total votes : 6

Support Multiple Stores

Postby joshuu » Sun Mar 14, 2010 9:22 am

Is there a possibilty that multiple store can be included for a an individual company which has many outlet sales locations.
joshuu
 
Posts: 2
Joined: Sun Mar 14, 2010 9:15 am

Re: Support Multiple Stores

Postby robot » Tue Mar 16, 2010 3:10 pm

just run separate databases for each store eg. www.store.com/pos1 = store 1 and www.store.com/pos2
robot
 
Posts: 45
Joined: Sat Jan 30, 2010 2:06 pm

Re: Support Multiple Stores

Postby jmremis » Mon Jun 21, 2010 10:21 pm

What about consolidated report for the stores?

Regards
jmremis
 
Posts: 1
Joined: Mon Jun 21, 2010 10:03 pm

Re: Support Multiple Stores

Postby varchars » Wed Jun 23, 2010 6:00 am

Basically it can be done one of two ways.

1. You can have a stand-alone installation in each store and the store will take care of its own local stock. For periodic accounting the numbers from the reports are sent to head office where they are consolidated with input from other branches.

On receipts the store name and address can either be the local details or the ead office details. Many larger retail chains show head office details on all receipts and invoices.


2. You can use one installation which is the central databse and log into it over the network from different "tills".

This is the same principle used with the osCommerce version of PHP POS, and the same as the online demonstration version of PHP POS: where two or more clients can access the same database. The web server system should prevent more than one user writing to the database at the same time.

Employees should be set up correctly so only authorised users can make changes.

From the program:

"Employee Permissions and Access

Check the boxes below to grant access to modules

* Customers: Add, Update, Delete, and Search customers
* Items: Add, Update, Delete, and Search items
* Reports: View and generate reports
* Suppliers: Add, Update, Delete, and Search suppliers
* Sales: Process sales and returns
* Employees: Add, Update, Delete, and Search employees
* Store Config: Change the store's configuration"

For example, only a head office staff member will be able to change the store's configuration, prices, suppliers.
Only authorised empoyees will be able to generate reports. This is an important security consideration because we don't want competitors to know our secrets.

Logically, receipts from such a central database will show the head office details regardless of which branch they were printed at.

Reports will show all transactions regardless of which branch machine they were entered on.

To distinguish items sold at different branches or tills the employee name can contain an identifier. For example, Fred-NY is a login name used at the Big Apple branch, Ingrid-SK is at the Stockholm branch, etc. User names can be allocated to branches by head office and made unique to a branch so there is no confusion and for security reasons. Branch managers will be sworn not to divulge passwords to anyone outside the branch. Any hint of a leak and passwords should be changed.

You can try different inputs by installing PHP-POS on a local server, opening two or more browsers and accessing the program from each of them, eg http://127.0.0.1/phppos/. Obviously, with only one input device you can only do one sale at a time.

To use it over a network (private or public) all you need is the correct server address.

If you can network two or more machines for experimenting with, you can get someone else to access the program at the same time you do to see how it works out.

To network two machines you should only need a crossover cable. That works with both Microsoft and Linux operating systems.

Establish what the server address is for PHP POS and bang away.

Hope it makes sense!
varchars
 
Posts: 30
Joined: Sun Mar 28, 2010 2:36 pm

Re: Support Multiple Stores

Postby anirow » Mon Jun 28, 2010 11:15 am

I think second approach would be the best,its nice to have a central database with many clients accessing it rather than several systems executing and then reports from them being merged at the central place.
anirow
 
Posts: 65
Joined: Thu Apr 22, 2010 6:28 am


Return to Feature Requests

Who is online

Users browsing this forum: No registered users and 1 guest