Re: [Fisterra-devel] Analysis: shop register

[Eloy F. <ef...@ig...>]

El jue, 21-04-2005 a las 16:24 +0200, Sergio Villar Senin escribi=C3=B3:
> Here are my comments about the shop register analysis:
>=20
> First of all, a few lexical issues:
>    * I think we should use "barcode" instead of "bar code"
>    * "cash withdrawal" not "retired of money"

Ok, i will change it.

> UC1
> =3D=3D=3D
> Refunds: I think there is no need for identifying documents by several
> ways. I think the barcode is enough because the whole refunds are
> generated with a barcode attached.

I agree, if the shop register can't read the barcode of the article, the
cashier has to enter the barcode number using the keyboard.

> Internal code & Provider reference: the same the previous comment. I
> think it is impossible for a cashier to remember any item identification
> code so items should only be entered with a barcode, read by the shop
> register or typed with the keyboard. That is why I would also remove the
> window number 4.

I agree.

> I do not understand this piece of text: "By default, the application
> shows the given quantity with the calculated total price, if the client
> gives other quantity the cashier has to change it."

the application has a field with the quantity (money) that the client
gives to the cashier, by default the application shows the total price
in this field.

> Talking about the window appearance, what about having a text field
> where the application could show messages for the cashier?, for example,
> "Remember the customer that there is a complimentary kilogram of
> barnacles with these two tins of tomatoes" or "give the customer 100
> Fisterra points for each pair of coke bottles".

I think that it is not a requirement that all shop register should have.
Our goal is implement a general shop register, adaptable easily.

> The application should show a visual item like an icon when we have a
> delayed ticket.

i think that it is a implementation detail.

> I do not understand why the 2nd window is called "Insertion of articles"
> when this window is built for client payments. The first phrase is also
> wrong because we insert no items in this window. This window must also
> consider money outputs. In a client refund the money to return is not
> "money given by the client - total price" because it is a negative
> quantity. This does not mean that the client can not give us money in a
> refund because the client could give us some money in order to allow the
> cashier to return him only bills.

you are rigth, the name of this window should be "Client payment", and
this window appears when the cashier finish the insertion of articles.

If it is a refund the return quantity should be the total price of the
refund ticket.

> Did this analysis take into account the possibility of paying in two
> phases, I mean an advance payment? This will affect the previous window
> and also the third.

Not, the shop register does not allow advance payments

> UC3
> =3D=3D=3D
> The window 1 of the UC3 need shop chief permissions, so the application
> should show an authentication window before showing the use case window.

i agree.

> I think we have to change the name of this UC because we should also be
> allowed to add cash to a shop register, not only to withdraw.

yes, the application should allow to add cash i will add a new window to
this UC.

> UC4
> =3D=3D=3D
> The application must check that there is no delayed ticked when trying
> to perform a cash audit.

I agree.

> Are the cash additions and withdrawals specified in the "Final balance"?

yes

> Is there not need of identifying them? What about the initial amount?

i will specify more it.

--=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