Basic tax is applicable at a rate of 10% on all goods, except books, food, and medical products that are exempt. Import duty is an additional tax applicable on all imported goods at a rate of 5%, with no exceptions.

When I purchase items I receive a receipt which lists the name of all the items and their price (including tax), finishing with the total cost of items, and the total amount of tax paid.

The rounding rules for tax are:

For a tax rate of n%, a shelf price of p contains (np / 100 rounded up to the nearest 0.05) amount of tax.

Write an application that prints out the receipt details for these shopping baskets:

Input 1:

1 Book at 12.49

1 Music CD at 14.99

1 Chocolate bar at 0.85

Input 2:

1 Imported box of chocolates at 10.00

1 Imported bottle of perfume at 47.50

Input 3:

1 Imported bottle of perfume at 27.99

1 Bottle of perfume at 18.99

1 Packet of paracetamol at 9.75

1 Box of imported chocolates at 11.25

Once calculated the following output should be shown.

Output 1:

1 book : 12.49

1 music CD: 16.49

1 chocolate bar: 0.85

Sales Taxes: 1.50

Total: 29.83

Output 2:

1 imported box of chocolates: 10.50

1 imported bottle of perfume: 54.65

Sales Taxes: 7.65

Total: 65.15

Output 3:

1 imported bottle of perfume: 32.19

1 bottle of perfume: 20.89

1 packet of headache pills: 9.75

1 imported box of chocolates: 11.85

Sales Taxes: 6.70

Total: 74.68

1. The product names listed in the basket do not match the product names on the receipts.

Two options:

 1.1 Confirm with 'client' that the same name is to be used (or not).

 1.2 Assume the same product has different names for different views.

A1 - have gone for option 1.2 and using 3 names - the internal product name, the till/basket product name and the receipt product name.

The overall system requirement would be for a Point of Sale (PoS) system - this relies on set of reference data.

Typically, the physical PoS (e.g. a till) will be remote and/or disconnected from a core database that holds the reference data and any transactions, stock control and accounting functions etc.

The PoS sub-system (the system working with the PoS) will have a list of reference data and its local order-header/order-line that will at some stage be sent to the core server for inclusion.

For the PoS system to work there would be a process to create a new 'basket' i.e. a new list of products that are being purchased by the customer.

Once the list is complete (e.g. all items scanned), the 'till' would do a final check on the data and then print a receipt.

However, the term 'print' could be many things - it may be an on-screen view, physical print, sms text or emailed receipt, so some inversion/injection dependency would not go amiss here.

For this 'Sales Taxes' assignment, we can assume that the 'baskets' exist and only need the tax calculation (which could have been done line by line on data entry) to be done prior to printing (it's not for the print process to calculate tax).

From an OOD point of view, the tax calculation should/could also be supplied as a service/class, since it could be looking at a different data source for the current rates of tax.

Assumption - the tax rates are available and have been supplied to the 'till' - but need to keep in mind they may be out of date and may need a db server lookup for the rates to use.

I decided on a database design to clarify in my mind how the task requirement fitted in, and in turn opted of a populated database rather than using static lists of test data.

A sample database structure has been established, and is comprised of local and remote tables - this one being used is assumed to be the local one using the tables PoS_OrderHead and PoS_OrderLine to hold the basket data (OrderHead and OrderLine not being used).

IF this was a single server implementation than all data would be 'local' and a final process after the print would be to move the till data (pos_orders) to the core data (orders) - if remote, then some data-feed process would be used in place (e.g. over-night data transfer, batch update via some service or another e.g. each transaction set pushed to a queue on a remote server for the core server to pull from).

Rather than go for the easy static data or Entity Framework option, I decided to go via the ADO route (reasons: 1. I have my own code generator to build the SQL stored procs of LUSID (List, Update, Select, Insert and Delete – or CRUD) and C# app and dal tiers; 2. to show I can use it!) NB the code generator is a kind of work in progress, so if you get that deep in the code you will see the Select is a bool Select() method rather than an obj Select() – I am aware of this ‘difference’ vs, say, the Entity Framework and the jury is still out!

Note - the table class templates are 'EF' ready and could be dropped into a dbcontext with little effort.

Once I had identified the objects, it seemed only natural to build the database and plumb it in for use. It is pre-populated with the required test data and, as stated above, I have assumed the tax rates have already been looked up. If this was a fuller system, then there would be a lookup when 'scanning' items from a basket at the till.