[ringorocks08]

I have a general question and I'm pretty sure this has already been asked,but I could not find it. Basically, I am developing a cashier software. There are two main features of the program. One would be for actually ringing transactions on the store floor like a cash register. The second portion deals with the app configuration, running reports, monitoring user accounts etc. and will be run only within the store office. I've completed all of the configuration and account maintenance forms and am looking to move on to building the cash register portion of the software.
So... I guess my question is what would be "best practices" for building the cash register software. Do I want to build an entirely separate project that accesses the same database, since they will be running on separate machines. Or should I build it in the same Solution as a different project. Any input or suggestions would be greatly, greatly appreciated.

Thanks All!

[Skydiver]

I believe the normal term used for the class of software you are looking for is "Point of Sale" or POS software. Ironically, when such software is poorly written, POS also stands for Piece of Sh*t.

Anyway, you should try to learn from the experiences of others. As I recall, the major leak of credit card information from the TJ Maxx/Marshalls was by taking advantage of weaknesses in the POS software.

[macosxnerd101]

Check out tlhIn`toq's tutorials on designing a POS system.

http://www.dreaminco...ister-part-one/
http://www.dreaminco...ister-part-two/

[tlhIn`toq]

Personally I'm a fan of user privileges for this sort of thing.

• A clerk can ring sales but not returns.
  
• A Customer Service rep can do both.
  
• A manager can also
  
  • put an item on 24 hour hold,
    
  • make new clerk IDs,
    
  • correct inventory levels

I have a large concern about how you are approaching this project based on this statement:

Quote

I've completed all of the configuration and account maintenance forms

How? How could you have completed all the config and maintenance forms if you haven't architected how the program(s) are going to work?

To me this screams of someone that does the easy part of drag-n-dropping a bunch of controls from the toolbox to a form FIRST because its easy and gives them confidence. Then starts thinking about how all of this is really going to function under the hood.

Have you worked out how all of this is going to work? Do you have plans for all your objects and their interaction? Have you designed your Product class, Transaction class, SKU class, Vendor class and so on? Do you know how these are going to interact with each other?

If you did the GUI first and are now trying to work out the guts of the project: STOP - You've already boned yourself and need to read this article.

This post has been edited by tlhIn`toq: 27 January 2013 - 07:14 PM

[ringorocks08]

Thanks for the responses. However, tlhIn`toq, I never said that I haven't "architectured" the project out. Maybe, my reference to "account" maintenance forms should have been described better as User Account forms. Basically, I have tables and interfaces for the application for User accounts, Product, Inventory, Employee info, and a few more...

I have yet to create the tables and interfaces for the Transactions, and TimeCard portions as that is where my question comes into play with the "Cashier" code. Although I do have a road map as to how those pieces will function. The reports piece will also be accessed from the "Office/Management" portion of the software, but cannot really be built until the transactions section is complete.

I am pretty experienced with programming, but have yet to build a program that will run in part on multiple machines. So, I guess my primary question would be: Should I code the Cashier portion of the POS as another Project within the same solution or should I make this a new solution that simply uses the same DB?

When all is said and done, I would like to create an installer. I've looked into it further and it seems that the best option may be to use the same solution. From what I've read, I could have an option in the installer as to which program to install.

Any further advice would be greatly appreciated.
Thanks!

[modi123_1]

Quote

Should I code the Cashier portion of the POS as another Project within the same solution or should I make this a new solution that simply uses the same DB?

This seems like unnecessary hair splitting. Either option leaves you with two different executables..

If you never foresee the client machine needing to access a report or the 'office part' needing to enter an order then make two.. if you don't then make one with two separate group roles that users will be assigned to.

[tlhIn`toq]

ringorocks08, on 28 January 2013 - 07:23 PM, said:

Should I code the Cashier portion of the POS as another Project within the same solution or should I make this a new solution that simply uses the same DB?

Do you have classes that are best shared? Namespaces best shared?

I find it fairly easy/helpful to have a solution with multiple projects that share namespaces & classes that go together. If one is going to be a client and one a server then they both have to use the same definition of a... ReceiptLineItem class. So that would be in a common namespace that both projects use.

                                Namespace RingoRocks
                                 Class transaction
                                 Class product
                                 Class Person
             ____________________|          |_________________
             |                                               |
 Namespace RingoSalesStation                Namespace RingoManagement
  Easily references RingoRocks.product    Also references RingoRocks.product

This post has been edited by tlhIn`toq: 28 January 2013 - 07:28 PM

[Skydiver]

Also beware of having two code bases accessing the same database directly. Ideally, you would have a single component that acts as the data access layer that sits in front of the database, and your client and admin code bases use that single data access layer. If you decide access the database directly, now you'll have to make sure that both the client and admin pieces are always perfectly in sync whenever you modify the database schema, or do some thing trick with the way the data is the database is used or stored.

[lordofduct]

What SkyDiver says.

You don't have a program running across two machines. You have a database that multiple pieces of software can access.

First put a facade on that data. So the data is consistent on all machines, and if the way that data is stored every changes, you only change the internals of the facade, and as long as the interface to it is the same all your software will continue to work.

This is easily done by just having a simple code library project that other programs can reference. So say if it was .Net, it'd create a dll that is referenced by every point of entry.

It could also be done as a service api that is directly accessed across the network. I used WCF to do this before, it's pretty nice, and allows updating the service side very easily with the user side never needing recompiling or anything.

This was also nice because we wrapped around both SQL and PICK databases. This meant that I could configure a server to be either or, and the client never noticed the difference either way. (note SQL is relational db, where as PICK is a multi-dimensional db)



tlhIn'toq brought up a good point about the users. In a piece of POS software I wrote I created a user group permissions system. Then any protectable operation could have groups associated with them that are allowed. And there is always a single super user that can modify this security from the backend (in case some dingle putz blows out user group that they designate to access said security config). I felt this allowed the users of the software to create their own security tiers beyond just 'clerk/manager'. For instance maybe an assistant manager group that's allowed to perform refunds... but not any other managerial task. You'd just create a group and flag them as being allowed to do any refund stuff, then place clerks into that group.



As for should you have multiple projects for the backend and frontend?

Yeah, I'd say so. This create a physical level of security. Now say I'm an employee who finds out that the manager is an idiot and uses their dogs birthday as their password. I go to MY register and easily just login as my manager and start fiddeling away with all the backend stuff.

Now of course afterwards they will find out whose register did the login... that's IF they find out I made changes, and also if I use my own register and not Sally's 2 registers down.

Where as if the backend software only exists on the manager's computer in the back (or another computer they designate), I have to not just get their password, but also get myself into said manager's office and computer... that's probably watched by cameras.

This post has been edited by lordofduct: 29 January 2013 - 02:29 PM

[ringorocks08]

Thanks again for all the great responses! I have a Proxy folder with all of my Database queries, inserts, updates, etc, I think I can fairly easily make that a .dll.

I went back and forth with making the management GUI available on the same machines as the registers. But, after hearing lordofduct's scenario, I think I will definitely keep them as separate applications. I also think adding a more customizable User Role/permissions system would be beneficial (enumerations here I come!)

So, if I were to have the database located on the "Office" computer, and I were to map a drive on the remote computers ("Registers") to point to the database's path, how would I get that path each time the application were opened. My initial thought would be to prompt for the path the first time the application loads and store the path in a file. The application could then look for the path in the file and then look in the path for the database. If it finds the database, the program is happy and moves on, if not, it prompts the user again and asks for the path. Does that sound like a typical solution for such a scenario?

[tlhIn`toq]

From my FAQ

Q: ... save data, save properties, save environmental variables, serialize my data/class?
A:

• Separating data from GUI - PLUS - serializing the data to XML
  
• Working with environmental variables
  
• Writing a text file tutorial.
  
• Reading a text file tutorial.
  
• Easy Application Settings example

[Skydiver]

ringorocks08, on 31 January 2013 - 10:12 PM, said:

I went back and forth with making the management GUI available on the same machines as the registers. But, after hearing lordofduct's scenario, I think I will definitely keep them as separate applications. I also think adding a more customizable User Role/permissions system would be beneficial (enumerations here I come!)

Enums is not the way to go for the user groups. That would mean you would have to churn the code each time a new group is created. Enums for the privileges of a group on the other hand would be appropriate.

ringorocks08, on 31 January 2013 - 10:12 PM, said:

So, if I were to have the database located on the "Office" computer, and I were to map a drive on the remote computers ("Registers") to point to the database's path, how would I get that path each time the application were opened. My initial thought would be to prompt for the path the first time the application loads and store the path in a file. The application could then look for the path in the file and then look in the path for the database. If it finds the database, the program is happy and moves on, if not, it prompts the user again and asks for the path. Does that sound like a typical solution for such a scenario?

Danger! Danger, Will Robinson! Danger!
Mapping paths to the database is bad. That means you'll need read-write access to that path if you expect the remote computers to update the database. That then means that anybody can just open a command prompt and type in "del *.*" on that path, and no more database.

The correct thing to do is for the connection to the database be via your database's established communications port(s), or by creating a web service (with appropriate authentication and authorization). If can have the host and port in a config file that you as the installer hand tweak, or have your remote computers configure the first time by interviewing the administrator installing the software.

[tlhIn`toq]

Skydiver, on 01 February 2013 - 09:36 AM, said:

Enums is not the way to go for the user groups. That would mean you would have to churn the code each time a new group is created. Enums for the privileges of a group on the other hand would be appropriate.

Personally I don't like user groups all that much. There always seems to be one guy that is supposed to be a supervisor but needs one extra privilege of ... OpenTill or DoEndOfShift.

I prefer a Privileges object with plenty of permissions.

You can always code a generic template of permissions for a Supervisor or a Manager, but you should allow someone to gain extra needs if their duties require it.

[lordofduct]

But you can be a member of multiple groups...

They both have their pros and cons. I like the configuration ease of groups when adding new users, and updating pools of users.

"A new operation was added today, who can use it? All members of the cashier group, that's who."

I also like the ease of testing it.

"What groups can perform this action? Is the current user a member of any of those groups? Done."

Privileges aren't that complicated either.

I guess its a difference between preferring granularity vs abstraction. I always go for abstraction before granularity...