From: Eloy F. <ef...@ig...> - 2005-04-21 08:58:16
|
Hi,=20 Next, i send the analysis of the shop register that the Fisterra team will implement.=20 If you think that we should add, delete or change anything in the shop register tell us it . *********************************************************************** ANALYSIS OF THE SHOP REGISTER =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 This section specifies the requirements of the shop register that will be implemented on the Fisterra project.=20 Basically, the operation of the shop register is: a client arrives to the shop, takes a set of articles, then goes to the shop register, where a cashier, that has been identified by the system previously, passes each article by a bar code reader, the application calculates the total price, the cashier select the payment method and finally returns the remaining money to the client. The client can refund the articles in the next X days. The client must go to Information counter, where he receives a refund ticket, then he must go 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 articles, so that if the client paid with credit card the refund is with credit card.=20 The shop register contains 5 use cases:=20 * UC 1: Shop register =E2=86=92 Cashier * UC 2: Refund of articles =E2=86=92 Staff of information * UC 3: Retired of money =E2=86=92 cashier * UC 4: Checking of shop register =E2=86=92 Cashier * UC 5: Checking of shop =E2=86=92 Shop chief Use case 1: Shop register =E2=86=92 Cashier =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 This use case allows the cashier to charge the articles that a client want to purchases. The cashier passes the articles by the reader of the bar code and it will be included in the ticket. If the client takes several equal articles the cashier can pass only one by the reader of bar code and to multiply by the number of units. This use case must allow mantain tickets in deleay, so that the cashier can create other ticket and then to recover the previous ticket. The possible payment methods are: 1. In cash. 2. Credit card. 3. Gift cheque: its can not return money. 4. Combination of the previous payment methods. A client can pay of several methods, so that the cashier have to select the payment method, using a function key.=20 If the payment method is in cash, the cashier has to indicate the given quantity by the client and the application calculates the quantity to return. When a client want to refunds one or various articles has to go to Information, there he receive a refund ticket and then he has to go to the shop register, where the cashier gives him the money. there are two situations: 1. The refund ticket of the client has bar code: the cashier passes the tickect by the reader of bar code, then the application show this ticket with the articles refunded by the client, the quantity of each one and the refund method. The cashier accepts the operation and two tickects will be printed, one for the client and another is stored associated with the refund ticket. =20 2. The refund ticket of the client has not bar code: the ticket has a number associated to this refund, so that the cashier will introduce it and then the application shows the ticket just as the before case. The cashier accepts the operation and two tickects will be printed, one for the client and another is stored associated with the refund ticket. The operation of the shop register is: The code of article is readed in other window. The cashier can multiply by the number of units, introduces for example 4 * and then passes the article by the reader of bar code, so that the 4 articles appear in a new line of the ticket. The cashier can introduce in this window: the internal code, the provider reference or the bar code of the article. The cashier will pass each article by the bar code reader and it will be added to the ticket in a new line. The application will add the price of all articles and will show the total price. 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. Window 1 of UC 1 =E2=86=92 Shop register -------------------------------- This is the window of the shop register, it is divided in 3 parts. The first part shows the information: 1. Document: type of document that the cashier is managing, if the cashier is charging it is 'ticket'. But the cashier can pass a refund ticket by the reader of bar code, in this case it is 'refund ticket'. The application has to recuperate this document and to show it in the window. The documents that the cashier can read are:=20 * Ticket. * Refund ticket. 2. Date: generation date of the document 3. Cashier: name of the cashier. 4. Shop register: number of shop register. The second part of the window has the ticket lines, the data of each are: 1. Line number 2. Internal code of the article 3. Description of the article 4. Number of units 5. Price by unit 6. Total price of the line =3D Number of units * price. The third part contains the fields: 1. Article code: when the cashier passes the article by the reader of bar code its code appears in this field. If the reader of bar code can not read the article code, the cashier can introduce it in this field. If the client takes more than 1 unit of the same article, the cashier can introduce the number of units, then the multiply symbol (*) and then the article code. If the cashier doesn't specifie the number of units before to pass the article by the bar code reader it is assumed that the number of units is 1. 2. Number of items that the cashier passed by the reader of bar code. This window must allow to leave a ticket in delay, and then to recuperate, using a function key. When the cashier use this function key the application changes from a ticket to other. The cashier can delete a line of the ticket, first selects the line and then uses a function key to delete it. The cashier when recuperates a document by its code can add, delete o update it depending of the document type: 1. Tickets: can update it if it was not saved. 2. Refunds: can not update it The cashier can introduce the provider reference of the item. Is possible that the reference is the same for different providers, in this case, the cashier must select the provider of the item, using the window 4. Window 2 of UC 1 =E2=86=92 Insertion of articles ---------------------------------------- This window is used to introduce the articles and show the total price. The data are: 1. Total price of the ticket: the crek uses a function key to finish the insertion of articles. =20 2. Payment method: By default is "in cash". The client can use several payment methods simultaneously, the cashier use a key function to open the window 3, that allows to introduce the different payment methods. =20 3. Money given by the client: by default, it is shown with the total price, if the client gives other quantity the cashier must change it. =20 4. Money to return: it is calculated by the application (money given by the client - total price). =20 Window 3 of UC 1 =E2=86=92 Payment methods ---------------------------------- This window appears when the cashier indicates that the client want to pay of several methods. This window has 2 columns, the quantity to charge and the selected payment method. By default, the quantity is filled with the total price of the ticket and the cashier selects the payment method, the cashier can change the quantity and set other minor, automatically must appear a new line with the remaining quantity of the ticket and the cashier has to select the payment method of the new line. If the payment method selected is "Credit card" the cashier must pass the credit card by the card reader to obtain its data. The cashier can change a payment method, first selects the corresponding line and changes the quantity or the payment method. Window 4 of UC 1 =E2=86=92 Provider selection ------------------------------------- This window allows to select a provider, it is used when a provider reference of a item belongs to different providers, it contains the data: 1. Provider name 2. Internal code 3. Bar code 4. Article description 5. P.V.P. =20 The cashier selects the correct line and then uses a function key to add the article to ticket. Use case 2: Refund of articles =E2=86=92 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= =3D=3D=3D The client can refund the articles 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 by the reader, if the ticket has not bar code the staff must introduce the ticket number in the application.=20 The application recovers the ticket information and shows it in the monitor, the staff selects the refunded articles, the units and the reason of the refund=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 articles, 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 Window 1 =E2=86=92Selection of the articles to refund --------------------------------------------- The Information staff passes the purchase ticket by the reader or introduces the number of the ticket, the application shows this window with the ticket data. This window contains 2 parts: ticket header and the tickets lines The ticket header contains: 1. Number of ticket. 2. Date of the ticket. 3. Name of the cashier. 4. Number of shop register. 5. Payment method of the ticket. The ticket lines contains: 1. Line number 2. Bar code of the article 3. Description of the article 4. Quantity 5. Price 6. PVP 7. Refund, is a boolean field indicates that the client refunds this article 8. Refunded quantity, it can not greater than the bougth quantity The staff of information selects the articles of the ticket and the quantities that the client want to refund, then he accept the operation and the application prints the refund ticket, the client takes it and go to the shop register.=20 Use case 3: Retired of money =E2=86=92 cashier =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 This use case allows the cashier to retire money of the shop register. Window 1 of UC 3 =E2=86=92 Quantity to retire -------------------------------------- This window appear when the cashier presses a function key from the shop register window. The cashier uses this window when the shop chief indicates to the cashier that must retire money, the cashier introduces the retired quantity, it cause:=20 * Substraction in shop register of the retired quantity. * Sum in central shop register of the retired quantity This operations must be performed when the retired document is printed. The window has a field only, where the cashier introduces the retired quantity. The cashier accept the operation and the applicaton print two documents, the data are: 1. Name of the shop 2. Date and time of the retired 3. Number and description of the shop register 4. Name of the cashier 5. Retired quantity 6. Signature of the cashier, it contains the signature label and the name of the cashier 7. Signature of the shop chief =20 =20 Use case 4: Checking of shop register =E2=86=92 Cashier =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 The cashier when finish his turn has to do the shop register closing, it is:=20 The cashier counts the money of the shop register, introduces in the application the final balance, the sum of credit card payments, the sum of gift cheques, sum of payments in cash, sum of credit card refunds, sum of refunds in cash and the sum of retired quantity.=20 Window 1 of UC 4 =E2=86=92 Checking of shop register -------------------------------------------- This window is used by the cashier when want close his shop register, the data are: 1. Date and time 2. Cashier 3. Shop register 4. Final balance: the cashier introduces this quantity 5. Credit card: sum of all credit card payments and the credit card returns. The cashier introduces this quantity. 6. Gift cheques: The cahier has to sum all gift cheques and to introduce this quantity. 7. Observation: the cashier can intrduce a obserbation in this field. When the cashier has introduced this data and accepted, the application must print the close document, its data are: 1. Date and time 2. Cashier 3. Shop register 4. Place of signature of shop chief 5. Place of signature of the cashier, it must include the cashier name. Then the cashier has to give this document to the shop chief, so that checks this data and does the shop closing. Use case 5: Checking of shop =E2=86=92 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 This use case allows the shop chief to check each shop registers, after the cashiers closes the shop registers. The shop chief must have a summary for each shop register, with the initial quantity, the sales in cash, the sales with credict card, and the retired quantity. 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 ererything 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 chief shop can introduce a observation. When the shop chief finish the cheking of the shop, the application shows the generated quantity the present day. The shop chief will indicate the quantity that he want send to the bank and the application calculate the quantity that remains in the shop. Window 1 of UC 5 =E2=86=92 Listing of shop registers closings ----------------------------------------------------- The shop chief can view all shop registers closings of the present day. This windows has two parts, the filters and the table of results. The filters are: 1. Number of shop register 2. Description of the shop register 3. Name of the cashier 4. The shop chief only can view the closings of the present day, is is a filter by default. The data of the results table are: 1. Number of shop register 2. Description of shop register 3. Name of the cashier 4. Invoiced quantity by the cashier. 5. Closing time 6. Total unsquare of the closing. The shop chief has to check each closing of shop register, the checked closing has to be marked of different color. A cachier can do several closings the same day. The shop chief uses this window to view all closings of shop registers, then he must check each one using the window 2. This window must also show the not closed shop registers. When the shop chief finish the cheking of the shop, the application shows the generated quantity the present day. The shop chief will indicate the quantity that he want send to the bank and the application calculate the quantity that remains in the shop. Window 2 of UC 5 =E2=86=92 Datail of the shop register closing ------------------------------------------------------ This window shows the data of a shop register closing, the data are: 1. Cashier name 2. Number and description of shop register 3. Date and time of closing 4. Table with 3 columns, the intrduced quantity by the cashier, the calculated quantity by the application and the unsquare. This table must to have 3 rows: * First row: is the quantity in cash (refunds + Final balance). The first cell is the introduced quantity by the cashier, the second cell is the calculated quantity by the application, the tird cell is the unsquare quantity. * Second row: is the quantity of credit card operations. The first cell is the introduced quantity by the cashier, the second cell is the calculated quantity by the application, the tird cell is the unsquare quantity. This window has a button that opens other window that allows to view the detail of all credit card tickets (payments and refunds) of that closing, it is the window 3.=20 * Third row: is the gift cheques. The first cell is the introduced quantity by the cashier, the second cell is the calculated quantity by the application, the tird cell is the unsquare quantity. The shop chief can change the introduced quantity by the cachier, the application must save this change and its author. The shop chief can introduce in this window a observation relationated with a unsquare. Window 3 of UC 5 =E2=86=92 Listing of credit card tickets ------------------------------------------------- This window allows to view a listing of all credict card tickets of the cashier closing selected in the window 1. This window appears when the shop chief clicks on the button of view the credit card tickets of the window 2.=20 The shop chief use this window to associate a unsquate to a ticket, because the cashier could introduce the quantity badly in the dataphone. The shop chief introduces a unsquare quantity and select the ticket that causes the unsquare, the application saves the unsquare associated to the ticket. This window contains two parts, the first is the header, the data are: 1. Cashier name 2. Shop register 3. Date The second part contains a table with the data: 1. Number of ticket 2. Time of the ticket 3. Total price of the ticket 4. Unsquare. When the shop chief found the unsquare he annotates the unsquare quantity, accepts and retuns to the previous window. *********************************************************************** 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 |
From: Sergio V. S. <sv...@ig...> - 2005-04-21 14:24:37
|
Here are my comments about the shop register analysis: First of all, a few lexical issues: * I think we should use "barcode" instead of "bar code" * "cash withdrawal" not "retired of money" UC1 === 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. 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 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." 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". The application should show a visual item like an icon when we have a delayed ticket. 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. 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. UC3 === 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 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. UC4 === The application must check that there is no delayed ticked when trying to perform a cash audit. Are the cash additions and withdrawals specified in the "Final balance"? Is there not need of identifying them? What about the initial amount? Bye. |
From: Eloy F. <ef...@ig...> - 2005-04-22 08:48:05
|
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 |
From: jfernandez <jfe...@ig...> - 2005-04-21 17:43:39
|
I would like to add some comments about cash process analyzing : * The analysis must to be completed with a detailed document workflow, describing the states and transitions of the following documents : - Ticket - Payment - Refund - Reservation - Budget * During refund operations, it's necessary to manage offers, for checking its validity for the modified ticket. The prices of items may be changed after refund operation. -- Javier Fernández García-Boente Ingeniero en Informática mailto:jfe...@ig... Igalia S.L. http://www.igalia.com Telf. +34 981 91 39 91 Fax. +34 981 91 39 49 |
From: Eloy F. <ef...@ig...> - 2005-04-22 08:56:13
|
El jue, 21-04-2005 a las 19:43 +0200, jfernandez escribi=C3=B3: > I would like to add some comments about cash process analyzing : >=20 > * The analysis must to be completed with a detailed document=20 > workflow, describing the states and transitions of the=20 > following documents : > - Reservation > - Budget the shop register does not allow reservations and budgets. > * During refund operations, it's necessary to manage > offers, for checking its validity for the modified ticket. The > prices of items may be changed after refund operation.=20 =20 it is not needed because the returned quantity is the same that the client paid by the articles. --=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 |
From: Alejandro C. <ac...@ig...> - 2005-04-22 12:41:11
|
On Thu, Apr 21, 2005 at 10:58:59AM +0200, Eloy Froufe Pérez wrote: > > [...] > > Window 1 ???Selection of the articles to refund > --------------------------------------------- > > The Information staff passes the purchase ticket by the reader or > introduces the number of the ticket, the application shows this window > with the ticket data. This window contains 2 parts: ticket header and > the tickets lines > > The ticket header contains: > > 1. Number of ticket. > 2. Date of the ticket. > 3. Name of the cashier. > 4. Number of shop register. > 5. Payment method of the ticket. > > The ticket lines contains: > > 1. Line number > 2. Bar code of the article > 3. Description of the article > 4. Quantity > 5. Price > 6. PVP > 7. Refund, is a boolean field indicates that the client refunds > this article > 8. Refunded quantity, it can not greater than the bougth quantity > > The staff of information selects the articles of the ticket and the > quantities that the client want to refund, then he accept the operation > and the application prints the refund ticket, the client takes it and go > to the shop register. > I have some questions about this use case and its windows: can I refund a ticket more than once? I asume the selection of the article will be done adding the number of units on a column, won't it? > > [...] > > Window 1 of UC 5 ??? Listing of shop registers closings > ----------------------------------------------------- > > The shop chief can view all shop registers closings of the present day. > This windows has two parts, the filters and the table of results. The > filters are: > I would remove the restriction about the present day, I think we can keep opened shop registers without problem. It is a responsability of the cashier to hand the drawer to the chief or keep it. This would simplify the application and I think allow more options to the users. Of course the system must warn the user when he is going to close a shop leaving an opened drawer. I think we should also add a way to view all shop and register closings, sometimes we will want to browse the old movements of the money. > > [...] > > When the shop chief finish the cheking of the shop, the application > shows the generated quantity the present day. The shop chief will > indicate the quantity that he want send to the bank and the application > calculate the quantity that remains in the shop. > I think we have to define the amount of money that we will leave in the drawers, but just as a quick window process, therefore we could change it on the the window 2 of this use case. This way the drawers could have different amounts and the users could have a main shop register in order to have money to do planned payments tomorrow. This way the amount that would be withdrawed of the shop will be: total amount at the shop today - amount on the drawers. > > [...] > > The shop chief use this window to associate a unsquate to a ticket, > because the cashier could introduce the quantity badly in the dataphone. > The shop chief introduces a unsquare quantity and select the ticket that > causes the unsquare, the application saves the unsquare associated to > the ticket. > I think there should be windows to list the tickets incidents, and to point out that the problem is solved with the bank, not just in this situation but on any problem with a ticket. Maybe one use case with a list and a detail that allow the user to handle the state of the document. Greetings. -- Alejandro Garcia Castro mailto: ac...@ig... http://www.igalia.com |
From: Eloy F. <ef...@ig...> - 2005-04-25 09:39:32
|
El vie, 22-04-2005 a las 14:41 +0200, Alejandro Garc=C3=ADa Castro es= cribi=C3=B3: > I have some questions about this use case and its windows: can I re= fund a > ticket more than once?=20 yes, it is possible. > I asume the selection of the article will be done > adding the number of units on a column, won't it? yes, we can delete the boolean field that indicates the articles to refund. > > Window 1 of UC 5 ??? Listing of shop registers closings > > ----------------------------------------------------- > >=20 > > The shop chief can view all shop registers closings of the presen= t day. > > This windows has two parts, the filters and the table of results.= The > > filters are: > >=20 >=20 > I would remove the restriction about the present day, I think we ca= n keep > opened shop registers without problem. It is a responsability of th= e cashier > to hand the drawer to the chief or keep it. This would simplify the > application and I think allow more options to the users. Of course = the > system must warn the user when he is going to close a shop leaving = an opened > drawer. I think we should also add a way to view all shop and regis= ter > closings, sometimes we will want to browse the old movements of the= money. we can add a filter with the closing data. > > When the shop chief finish the cheking of the shop, the applicati= on > > shows the generated quantity the present day. The shop chief will > > indicate the quantity that he want send to the bank and the appli= cation > > calculate the quantity that remains in the shop. > >=20 >=20 > I think we have to define the amount of money that we will leave in= the > drawers, but just as a quick window process, therefore we could cha= nge it on > the the window 2 of this use case. This way the drawers could have = different > amounts and the users could have a main shop register in order to h= ave money > to do planned payments tomorrow. This way the amount that would be > withdrawed of the shop will be: total amount at the shop today - am= ount on > the drawers. i think that is better the change proposed by Sergio, it is to allow = the cashier add cash to a shop register, not only to withdraw, it solves this problem. > > The shop chief use this window to associate a unsquate to a ticke= t, > > because the cashier could introduce the quantity badly in the dat= aphone. > > The shop chief introduces a unsquare quantity and select the tick= et that > > causes the unsquare, the application saves the unsquare associate= d to > > the ticket. > >=20 >=20 > I think there should be windows to list the tickets incidents, and = to point > out that the problem is solved with the bank, not just in this situ= ation but > on any problem with a ticket. Maybe one use case with a list and a = detail > that allow the user to handle the state of the document. yes, it will be useful. 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 |