Using .NET to Create Objects for a Sample POS System

• Download source code - 59.3 KB
• Download executable - 82.3 KB

Introduction

ChaChing is a sample application to demonstrate how to use .NET objects. It is not a production POS system. It is merely the first of six iterations of an application to showcase how to use classes when programming with the .NET Framework.

ChaChing is an implementation of an analysis project that some classmates and I put together for a Boise State University course. We collaborated on the requirements of a POS system, and I created the design classes in C# using the Visual Studio 2005 Express Edition.

ChaChing is designed to use either one of two interfaces (boundary classes): either a web-based interface via a web browser (not included with this distribution), or a POS station interface (via the Win32 form included in the Executable folder). The application classes are designed to support either type of interface.

ChaChing is only a sample POS software application. Hardware implementation is not within the scope of the project, and there are no current plans to add hardware support. The main reason for not including hardware support within the scope of the project is that many excellent solutions exist for plug and play hardware support for POS systems. Open source solutions such as POS for .NET and Unified Point-of-Service (UPOS) currently fulfill that role.

Background

Microsoft Access is used to provide data access with the OLE DB .NET data provider. I chose Access to prototype the application because of the easy-to-use wizards for creating data tables and relationships. Porting the application to SQL Server would be the next logical step, once the entire application is completed.

The application was built on a Windows XP desktop system, though a better real-world POS application should probably be ported to support a minimal-features-set Windows Operating System.

Using the code

The application requires a Windows PC with the .NET Framework installed (2.0 or higher). Also, the MDB schema file must be installed on a PC that has Microsoft Access installed. And, the connection string for data access must be modified to point to the PC where the MDB schema is located (the Access server). The connection string for the sample executable assumes that the installation PC has MS Access installed.

The .NET 2.0 List class is used to hold multiple objects for some of the design classes. For instance, the Order object can have multiple Payment and Po (Purchase Order) objects.

An excerpt example of the C# implementation of the .NET 2.0 List object follows:

class Order
{
    // ~ some code goes here... 
    // 
    public List<Po> PoList = new List<Po>();
    public List<Payment> PaymentList = new List<Payment>();
    // 
    // ~ some more code goes here... 
    //
    // CASH payment method. 
    public bool tenderPayment(decimal theAmountPaid, 
                bool theCashBackBoolean, Int64 theAccountId)
    // CASH payment method. 
    {
        this.PaymentList.Add(new Payment(theAmountPaid, 
                             theCashBackBoolean, theAccountId)); 
        return true; 
    }  
    public bool makeNewRecordPayment()
    {
        bool success = true;
        this.PaymentList.ForEach(delegate(Payment i)
        {
            // recordPayment() uses data access to insert a new Payment record. 
            if (i.recordPayment() == false)
            {
                success = false;
            }
        });
        return success;
   }
}

Points of interest

The List class works well for design classes that contain multiple objects of a given data type, where the data type can be a custom defined data type (another class).

An old saying goes, "When the student is ready, the teacher appears". While attending the 2008 Boise Code Camp, I learned about the advantages of using the .NET 2.0 List class. And, I then decided to use the List class to build some of the classes in the project. The List class is much easier to use than the .NET 1.1 Arra<code>yList class.

History

One, of six planned iterations, has been posted for this project.

• (v0.1) Basic cash register functionality.
• Currently, the application has functionality for input of payments received from customers when making a sales order; which means that it can ring up and total a sale like the pre-electronic cash registers. And then, it records the transactions to be selected later for reporting by customer ID number, by cashier ID number, or by payment type. Although reports have not yet been created, the schema is designed to support reports.
• Remaining software functionality to be done includes: recording both inventory records and delivery records, as well as creating the user wizards and report definitions. Also, a real-world system would require that any necessary hardware drivers be written for data capture (input devices, i.e., touch-screens, barcode scanners, etc.) and business processing (cash drawers etc.).