bernhardbln / opensourcecashregister Goto Github PK

== Current state ==

Currently, an entity bean of type AbstractPersistentObjectWithContinuance does not check the consistency of its history.

== Definition of Consistency ==

The natural key consists of the validFrom date (which is immutable) and one or several attributes of the actual bean. Those attributes (let's call them "natural object key") are as well expected to be immutable.

A consistent history would be like this:

|| '''natural object key''' || '''validFrom''' || '''validTo''' ||
|| '''object1''' || null || 01.05.2010 ||
|| object1 || 02.05.2010 || 01.09.2010 ||
|| object1 || 05.10.2010 || null ||
|| '''object2''' || 01.01.2010 || 01.09.2011 ||
|| object2 || 05.10.2011 || null ||

An inconsistent history would be like that:

1. Overlapping time spans:

|| object1 || 01.01.2010 || 01.12.2010 ||
|| object1 || 01.05.2010 || 01.09.2010 ||

1. More than one instance of the same object, where all of those instances existed since the creation of the universe:

|| object1 || null || 01.05.2010 ||
|| object1 || null || 01.09.2010 ||

1. More than one instance of the same object, where all of those instances are valid until the end of all times:

|| object1 || 01.05.2010 || null ||
|| object1 || 01.09.2010 || null ||

== What is to be done? ==

The following rules need to be checked by the entity bean or directly by the database. With "the same object" we mean "having the same natural object key", not considering the validFrom date.

1. There is no or only one instance of the same object with validFrom = null
2. There is no or only one instance of the same object with validTo = null
3. It always holds that if for an object, validFrom is <= validTo (if both are not null)
4. It holds for any two instances of the same objects o1 and o2, that either o1.validTo < o2.validFrom or vice versa (from the first two rules it follows that there is an ordering where validTo and validFrom are both not null).

Income, spendings, money lost, VAT, ...

'''-> Split into sub tasks!'''

At the beginning, the cash register will be loaded with a certain amount of change.

Every then and now, one of the following things will happen:

• the money that is earned is taken out from the drawer and brought to the bank
• money is taken out and replaced by smaller or larger change (e.g. a 10-euro note comes out and 10 1-euro-coins come in) - '''that actually does not need to be registered at all!'''
• more change money is put into the register
• some of the change money is taken out

There should be a functionality which shows how much money is in the register, and how this splits into change money (not containing VAT) and income (containing different VAT). Further more, there should be a functionality to load/unload change and to take out income in order to bring it to the bank.

The history should look like this:

{{{
Init - put 100 EUR of change into the drawer

(selling 10 espressi for (total) 10,70 EUR, including 7% vat, and 10 cappuccini for 23,80 EUR, incl. 19% vat)

Check - in the drawer we have:

• 100 EUR of change
• 10,70 EUR of gross income with 7% VAT (10 EUR net income + 0,70 EUR VAT)
• 23,80 EUR of gross income with 19% VAT (20 EUR net income + 3,80 EUR VAT)
• total amount of money in drawer: 134,50 EUR

In order to avoid confusion, we only allow those options:

• take out 10,70 EUR from the drawer and bring to bank
• take out 23,80 EUR from the drawer and bring to bank
• take out 34,50 EUR from the drawer and bring to bank (then there is only 100 EUR change left)
• take out any amount of change <= 100 EUR
• add any amount of change

Now we take out 23,80 EUR (20 EUR + 3,80 EUR VAT) and add 50 EUR of change.

Check - in the drawer we have:

• 150 EUR of change
• 10,70 EUR of gross income with 7% VAT (10 EUR net income + 0,70 EUR VAT)
• total amount of money in drawer: 160,70 EUR

(We sell another 10 espressi for 10,70 EUR and another 10 cappuccini for 23,80 EUR, with same vat as above)

Check - in the drawer we have:

• 150 EUR of change
• 21,40 EUR of gross income with 7% VAT (20 EUR net income + 1,40 EUR VAT)
• 23,80 EUR of gross income with 19% VAT (20 EUR net income + 3,80 EUR VAT)
• total amount of money in drawer: 195,20 EUR

}}}

This can be achieved by keeping booking records for each bill and each cash load/unload. The current amount of money in the drawer would be equal to {{{select sum(grossAmount) from bookings where bookingArchived=false}}}.

At the end of the year, one probably wants to archive all booking records from that year and create a single transfer record "sum of all records of year xxxx".

The money in the drawer might be counted every evening after the shop gets closed, and in case money gets lost or additional money appears, there should be a way to register that. It should be booked as "lost money" / "extra money", together with the current user, but it should be booked against the change money, as the tax office is not going to give up claims on the vat just because someone dropped a coin somewhere.

Save a password in the db which is used to zip, encrypt and export the database into the file system (for example into a dropbox folder)

Open the cash register as a user, enter current amount of change in the register.

Close the cash register - enter current amount.

Display receipt: opening amount, closing amount, income, spendings, money taken out and brought to bank, expected closing amount, missing amount.

• MVC style
• Swing code and controller separated

In Bill and AbstractSalesItem, there is a reference to a taxInfo.

Check which Hibernate cascade types are actually needed and make sense.

• Instructions how to secure the software
• Security measures in case this becomes a client server thing

-> UTF8-issue in mysql?

See DataStorageTest or MoneyFormatterTest. Maybe the formatter shouldn't be in the money class as well?

Currently uses Locale to determine currency.

Better make this a setting that is saved in the DB and can be changed by the user.