Menu
▾
▴
Re: [Fisterra-devel] Revision: requirements of shop register
|
From: Eloy F. <ef...@ig...> - 2005-05-03 07:55:40
|
El lun, 02-05-2005 a las 19:48 +0200, Alejandro Garc=C3=ADa Castro escribi= =C3=B3: > On Thu, Apr 28, 2005 at 06:36:14PM +0200, Eloy Froufe P=C3=A9rez wrote: > > > > [...] > >=20 > > Use case 2: Refund of items ??? Staff of information > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >=20 > > The client can refund the items in the next X days. The client must go > > to Information counter where gives the purchases ticket, the staff > > passes the bar code of the ticket through the reader.=20 > >=20 > > The application recovers the ticket information and shows it in the > > monitor and the staff selects the refunded items.=20 > >=20 > > The application prints a refund ticket. The client takes the refund > > ticket and goes to the shop register where the cashier returns him the > > money. The method of refund is the same that the client used when he > > bougth the items, so that, if the client paid with credit card the > > refund is with credit card. The refund ticket must have the refund > > method, it is obtained from purchase ticket=20 > >=20 >=20 > What would happen if we try to refund a ticket twice? Is it posible? How = can > we mananage it? Yes, it is possible, the second time the application allows only to refund the items that the client has not refunded the first time. > > [...] > >=20 > > If the shop has a shop register central, it can be implemented as a > > special shop register, in this case the cash management will be: > >=20 > > 1. Add of cash: The shop chief performs a operation of cash > > withdrawall of central shop register and a operation of cash > > addition in a certain shop register. > > 2. Retire of cash: The shop chief performs a operation of cash > > withdrawall of a certain shop register and a operation of cash > > addition in a central shop register. > >=20 > > Other possibility is that the shop chief has a virtual shop register > > associated, when he performs a cash withdrawal the cash quantity is > > added to his virtual shop register and if the shop chief performs a cas= h > > addition the cash quantity is substracted of his virtual shop register. > > It allows has a greater control of cash flow. > >=20 >=20 > Do these paragraphs mean that we have to define a special kind of registe= r > in order to have a main register? I think we can implement the exchanges > between registers just with one type. The virtual register case is > different, maybe that kind of register should have special operations, > because we don't want generate exchange tickets for them. No, it is only two ideas, the fisrst is how could be implemented a central shop register (we suppose that does not exist a central shop register) and second is has a virtual shop register associated to shop chief but is a idea of implementation that allows has a greater control of cash flow. =20 > > [...] > >=20 > > Use case 5: Checking of shop ??? Shop chief > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > This use case allows the shop chief to check each shop registers, after > > the cashiers closes the shop registers. > >=20 > > The shop chief must have a summary for each shop register, with the > > cash, the balance of credit card and the gift cheques. The application > > must show the data introduced by the cashier and the data calculated by > > the application. The shop chief has to check that these data are equal, > > and the money given by the cashier is equal to the introduced quantity > > by the cashier in the application. If everything is correct the shop > > chief accepts and the shop register is closed definitively. If exists a > > unsquare can be that the cashier counted badly the money of the shop > > register, in this case the shop chief must introduce the quantity again= , > > the application must save the old data and the new data. Then if still > > the unsquare exists, the shop chief can introduce a observation. > >=20 >=20 > I think we should point out, as it is done under, that besides the > observation we will create an incident. Yes, it is explained in the "Window 2 of UC 5" section > > [...] > > > > Window 3 of UC 5 ??? Listing of credit card tickets > > ------------------------------------------------- > > >=20 > Could this window be a ticket listing, we would have to add a filter if w= e > want to find the credit card ones. No, because this window must allow to enter the unsquared quantity of each ticket. > > [...] > >=20 > > When the shop chief founds the unsquare he annotates the unsquare > > quantity, accepts and retuns to the previous window. The application > > must create a incident of 'credit card ticket unsquare' type, associate= d > > to the unsquared ticket, and with the unsquare quantity. > >=20 >=20 > What do we do when we locate the ticket? Shall we mark it and introduce t= he > quantity? Yes, the shop chief enter the unsquared quantity, accepts and the application creates a incident. > > [...] > > =20 > > Use case 7: Incidents management ??? Shop chief > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > This use case allows the shop chief to manage the incidents. There are = 4 > > types of incidents:=20 > >=20 > > * Cash unsquare: this incidents are created when the shop chief > > performs a "Checking of shop" and exists an cash unsquare. This > > incident is associated to the shop register closing. > > =20 > > * Gift cheque unsquare: this incidents are created when the shop > > chief performs a "Checking of shop" and exists an gift cheque > > unsquare. This incident is associated to the shop register > > closing. > > =20 > > * Credit card unsquare: this incidents are created when the shop > > chief performs a "Checking of shop" and exists an credit card > > unsquare. This incident is associated to the shop register > > closing. > > =20 > > * Credit card ticket unsquare: this incidents are created when th= e > > chief performs a "Checking of shop", exists an credit card > > unsquare, and the shop chief select a credit card ticket that > > has a unsquare, this incident is associated to the credit card > > ticket. > > >=20 > How can we manage each kind of incident? Maybe we should also add the > requirements of the window used to manage the incidents properly, maybe a > button to confirm the change of the state. Yes, it is the window 2 of UC 7. > > [...] > > > > This window must have a button that allows refresh the cash quantity of > > each shop register > >=20 >=20 > I think we should also add a button to carry out a withdrawal.=20 Not, because the shop chief can not perform withdrawals of cash, only the cashier can perform it. > Does this window has any relation with the one used to do the shop checki= ng? Maybe in > that window we have to add a way to mark the register checkings that will= be > added to the shop checking. Not, it has not relation with the shop checking, the shop chief uses this window to decide if the cashier must add or retire cash of its shop register. Greetings. --=20 Eloy Froufe P=C3=A9rez Computer Science Engineer Telf: +34 981 91 39 91 Fax: +34 981 91 39 49 mailto: ef...@ig... IGALIA, S.L. http://www.igalia.com |