You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(22) |
Jun
(10) |
Jul
(9) |
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(2) |
Feb
|
Mar
(8) |
Apr
(11) |
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(12) |
Nov
|
Dec
|
2005 |
Jan
(4) |
Feb
(2) |
Mar
(9) |
Apr
(20) |
May
(8) |
Jun
(4) |
Jul
(9) |
Aug
(25) |
Sep
(6) |
Oct
(1) |
Nov
(3) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(1) |
Nov
(3) |
Dec
|
From: Sergio V. S. <sv...@ig...> - 2005-05-03 15:02:41
|
On Mar, 2005-05-03 at 11:53 +0200, Eloy Froufe P=E9rez wrote: > > Should we consider the incidents as another kind of Document? >=20 > yes. So If I understood ell, it will be only one incident per document with multiple lines. Bye. |
From: Eloy F. <ef...@ig...> - 2005-05-03 09:52:47
|
El mar, 03-05-2005 a las 11:35 +0200, Sergio Villar Senin escribi=C3=B3: > On Xov, 2005-04-28 at 18:36 +0200, Eloy Froufe P=C3=A9rez wrote: > > Window 1 of UC 7 =E2=86=92 Listing of incidents > > --------------------------------------- > >=20 > > The shop chief uses this window to select the incident that he want to > > manage. This windows has two parts, the filters and the table of > > results. The filters are: > >=20 > > 1. Incident date > > 2. Incident type > > 3. Incident state > > 4. Cashier name > > 5. Shop register number. > >=20 > > The data of the results table are: > >=20 > > 1. Incident date and time > > 2. Incident type > > 3. Incident state > > 4. Cashier name > > 5. Shop register number. > > 6. Shop register name. > >=20 > > The shop chief can select a incident and manage its in the window 2. > >=20 > >=20 > > Window 2 of UC 7 =E2=86=92 Detail of incident > > ------------------------------------- > >=20 > > This window allows the shop chief to manage a incident, selected in > > the > > window 1, the data of this window are: > >=20 > > 1. Time and date of the incident > > 2. Type of the incident > > 3. Number and name of the shop register and the name of the > > cashier. It is the shop register and the cashier that caused > > the > > unsquare. > > 4. Unsquared quantity > > 5. Observation: the shop chief can introduce a observation > > associated to the incident. > > 6. Incident state: The shop chief can change the state of a > > incident, the possible states are: active, in current state, > > finalized and deleted. >=20 > Should we consider the incidents as another kind of Document? yes. > What about other types of incidents? What is "in current state" state? Wh= at is "deleted" state? I changed it, i think that the states needed are: active and finished, what do you think? > Is there any schema of incident state transitions? I mean, how does an > incident change its state? active --> finished > What document are the incidents associated to?tickets tickets=20 closings of shops 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-05-03 09:35:50
|
On Xov, 2005-04-28 at 18:36 +0200, Eloy Froufe P=C3=A9rez wrote: > Window 1 of UC 7 =E2=86=92 Listing of incidents > --------------------------------------- >=20 > The shop chief uses this window to select the incident that he want to > manage. This windows has two parts, the filters and the table of > results. The filters are: >=20 > 1. Incident date > 2. Incident type > 3. Incident state > 4. Cashier name > 5. Shop register number. >=20 > The data of the results table are: >=20 > 1. Incident date and time > 2. Incident type > 3. Incident state > 4. Cashier name > 5. Shop register number. > 6. Shop register name. >=20 > The shop chief can select a incident and manage its in the window 2. >=20 >=20 > Window 2 of UC 7 =E2=86=92 Detail of incident > ------------------------------------- >=20 > This window allows the shop chief to manage a incident, selected in > the > window 1, the data of this window are: >=20 > 1. Time and date of the incident > 2. Type of the incident > 3. Number and name of the shop register and the name of the > cashier. It is the shop register and the cashier that caused > the > unsquare. > 4. Unsquared quantity > 5. Observation: the shop chief can introduce a observation > associated to the incident. > 6. Incident state: The shop chief can change the state of a > incident, the possible states are: active, in current state, > finalized and deleted. Should we consider the incidents as another kind of Document? What about other types of incidents? What is "in current state" state? What is "deleted" state? Is there any schema of incident state transitions? I mean, how does an incident change its state? What document are the incidents associated to? Bye. |
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 |
From: Alejandro C. <ac...@ig...> - 2005-05-02 17:48:28
|
On Thu, Apr 28, 2005 at 06:36:14PM +0200, Eloy Froufe Pérez wrote: > > [...] > > Use case 2: Refund of items ??? Staff of information > ================================================== > > 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. > > The application recovers the ticket information and shows it in the > monitor and the staff selects the refunded items. > > 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 > What would happen if we try to refund a ticket twice? Is it posible? How can we mananage it? > > [...] > > 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: > > 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. > > 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 cash > addition the cash quantity is substracted of his virtual shop register. > It allows has a greater control of cash flow. > Do these paragraphs mean that we have to define a special kind of register 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. > > [...] > > Use case 5: Checking of shop ??? Shop chief > ========================================= > > 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 > 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. > I think we should point out, as it is done under, that besides the observation we will create an incident. > > [...] > > Window 3 of UC 5 ??? Listing of credit card tickets > ------------------------------------------------- > Could this window be a ticket listing, we would have to add a filter if we want to find the credit card ones. > > [...] > > 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, associated > to the unsquared ticket, and with the unsquare quantity. > What do we do when we locate the ticket? Shall we mark it and introduce the quantity? > > [...] > > Use case 7: Incidents management ??? Shop chief > ============================================= > > This use case allows the shop chief to manage the incidents. There are 4 > types of incidents: > > * 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. > > * 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. > > * 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. > > * Credit card ticket unsquare: this incidents are created when the > 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. > 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. > > [...] > > This window must have a button that allows refresh the cash quantity of > each shop register > I think we should also add a button to carry out a withdrawal. Does this window has any relation with the one used to do the shop checking? Maybe in that window we have to add a way to mark the register checkings that will be added to the shop checking. Greetings. -- Alejandro Garcia Castro mailto: ac...@ig... http://www.igalia.com |
From: Eloy F. <ef...@ig...> - 2005-04-28 16:36:05
|
Hi,=20 Next, i send a new revision of the shop register requirements that th= e Fisterra Team will implement.=20 If you think that we should add, delete or change anything in the sho= p register tell us it . *********************************************************************= ** Requirements of 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 wil= l be implemented on the Fisterra project.=20 Basically, the operation of the shop register is:=20 * A client arrives to the shop, takes a set of items and goes t= o the shop register. * The cashier, that has been identified by the system previousl= y, passes each item through a bar code reader. * The application calculates the total price. * The cashier select the payment method. * Finally the cashier returns the remaining money to the client= . The client can refund the items in the next X days. The client must g= o to Information counter, where he receives a refund ticket, then he mu= st 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 items, so that if the client paid with credit card the refund is with credit card.=20 The shop register contains 7 use cases:=20 * UC 1: Shop register =E2=86=92 Cashie * UC 2: Refund of items =E2=86=92 Staff of information * UC 3: Cash management =E2=86=92 cashier * UC 4: Checking of shop register =E2=86=92 Cashier * UC 5: Checking of shop =E2=86=92 Shop chief * UC 6: Items management =E2=86=92 Shop chief * UC 7: Incidents management =E2=86=92 Shop chief * UC 8: Consult cash of the shop registers =E2=86=92 Shop chief =20 =20 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 items that a client wa= nt to purchase. The cashier passes the items through the reader of the b= ar code and it will be included in the ticket. If the client takes sever= al units of the same item the cashier can pass only one through the read= er of bar code and to multiply by the number of units. This use case must allow to mantain tickets on waiting state, so that the cashier can create other ticket and then to recover the previous ticket. The possible payment methods are: 1. Cash. 2. Credit card. 3. Gift cheque: it can not return money. 4. Combination of the previous payment methods. A client can pay with several methods, so that the cashier have to select the payment method, using a function key.=20 If the payment method is cash, the cashier has to indicate the quanti= ty handed by the client and the application calculates the quantity to return. When a client want to refund one or various items has to go to Information office, there he receive a refund ticket and then he has = to go to the shop register, where the cashier gives him the money.=20 The refund ticket of the client has a bar code, the cashier passes th= e tickect through the reader of bar code, then the application shows th= is ticket with the items refunded by the client, the quantity of each on= e 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. The operation of the shop register is: The bar code of the item is readed in other window. The cashier can multiply by the number of units, introduces for example 4 * and then passes the item through the reader of bar code, so that the 4 items appear in a new line of the ticket. The cashier will pass each item through the bar code reader and it wi= ll be added to the ticket in a new line. The application will add the pr= ice of all items and will show the total price. By default, the applicati= on shows the given quantity with the calculated total price, if the clie= nt 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 t= he cashier is charging it is 'ticket'. But the cashier can pass = a refund ticket through the reader of bar code, in this case it= is 'refund ticket'. The application has to recuperate this docum= ent 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 item 3. Description of the item 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. Bar code: when the cashier passes the item through the reader= of bar code its code appears in this field. If the client takes more than 1 unit of the same item, the cashier can introduce = the number of units, then the multiply symbol (*) and then the it= em code. If the cashier doesn't specify the number of units befo= re to pass the item through the bar code reader it is assumed th= at the number of units is 1. 2. Number of items that the cashier passed through the reader of bar code. This window must allow to leave a ticket on waiting state, and then t= o 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 a= nd then uses a function key to delete it. When the cashier recuperates a document by its code can add, delete o update it depending on the document type: 1. Tickets: can update it if it was not saved. 2. Refunds: can not update it =20 =20 Window 2 of UC 1 =E2=86=92 Client payment --------------------------------- This window is used by the cashit to charge the client ticket. The da= ta are: 1. Total price of the ticket: the cashier uses a function key to finish the insertion of items. 2. Money given by the client: by default, it is shown with the total price, if the client gives other quantity the cashier m= ust change it. 3. Payment methods: the client can use several payment methods simultaneously, by default is "cash". This window must contai= n a row for each payment method, where the cashier must introduce the quantity of each payment method that the client wants. By default, the cash quantity must be the total price of the ticket, but the cashier can change it. The cashier selects th= e payment methods using a function key for each one. If the payment method selected is "Credit card" the cashier must pas= s the credit card through the card reader to obtain its data. T= he application has to check that the sum of all payment methods quantities is equal or greater than the total price of the ticket. 4. Money to return: it is calculated by the application (money given by the client - total price). =20 If it is a refund the return quantity should be the total price of th= e refund ticket. Use case 2: Refund of items =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 The client can refund the items in the next X days. The client must g= o to Information counter where gives the purchases ticket, the staff passes the bar code of the ticket through the reader.=20 The application recovers the ticket information and shows it in the monitor and the staff selects the refunded items.=20 The application prints a refund ticket. The client takes the refund ticket and goes to the shop register where the cashier returns him th= e 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 Window 1 of UC 2 =E2=86=92Selection of the items to refund --------------------------------------------------- The Information staff passes the purchase ticket through the reader, = the application shows this window with the ticket data. This window conta= ins 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 item 3. Description of the item 4. Quantity 5. Price 6. PVP 7. Refunded quantity, it can not greater than the bougth quantit= y The staff of information selects the items of the ticket and the quantities that the client want to refund, then he accepts the operat= ion and the application prints the refund ticket, the client takes it and= go to the shop register.=20 Use case 3: Cash managment =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 This use case allows the cashier to retire or add cash to the shop register. Window 1 of UC 3 =E2=86=92 Cash management=20 ---------------------------------- The cashier uses this window when the shop chief indicates that the cashier must retire or add cash to the shop register. The cashier performs this operation using a function key from the sho= p register window. The shop chief has to enter his password before this window appear. I= f the shop chief does not enter his password the chashier can not perfo= rm this operation. The window has a 2 field only, where the cashier introduces the operation type (add or retire) and the cash quantity. The cashier accept the operation and the applicaton print two documen= ts, the data are: 1. Name of the shop 2. Date and time of the withdrawal 3. Number and description of the shop register 4. Name of the cashier 5. Operation type (adition or withdrawal) 6. Cash quantity 7. Signature of the cashier, it contains the signature label and the name of the cashier 8. Signature of the shop chief 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: 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 cas= h addition in a central shop register. 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 c= ash addition the cash quantity is substracted of his virtual shop registe= r. It allows has a greater control of cash flow. 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 this quantity, the credit card balance, the sum of gift cheques, and finally can enter a observation.=20 Window 1 of UC 4 =E2=86=92 Checking of shop register -------------------------------------------- This window is used by the cashier when he wants to close his shop register, the application must check that there is not delayed ticked when tries to close the shop register. The data are: 1. Date and time 2. Cashier 3. Shop register 4. Cash balance: the cashier introduces the cash of the shop register 5. Credit card balance: sum of all credit card payments - sum of all credit card refunds. The cashier introduces this quantity= . 6. Gift cheques quantity: The cahier has to sum all gift cheques and to introduce this quantity. 7. Observation: the cashier can introduce a observation in this field. When the cashier has introduced this data and accepted, the applicati= on must print the close document, its data are: 1. Date and time 2. Cashier 3. Shop register 4. Cash balance 5. Credit card balance 6. Gift cheque quantity 7. Place of signature of shop chief 8. Place of signature of the cashier, it must include the cashie= r name. Then the cashier has to give this document to the shop chief, so that checks this data and performs 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, aft= er the cashiers closes the shop registers. The shop chief must have a summary for each shop register, with the cash, the balance of credit card and the gift cheques. The applicatio= n 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 equa= l, and the money given by the cashier is equal to the introduced quantit= y 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 aga= in, the application must save the old data and the new data. Then if stil= l the unsquare exists, the shop chief can introduce a observation. Window 1 of UC 5 =E2=86=92 Listing of shop registers closings ----------------------------------------------------- The shop chief can view all shop registers closings of a certain day. This windows has two parts, the filters and the table of results. The filters are: 1. Closing day 2. Number of shop register 3. Description of the shop register 4. Name of the cashier 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 checke= d 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 register= s, then he must check each one using the window 2. This window must also show the not closed shop registers. 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 differences. T= his table must to have 3 rows: * First row: is the cash quantity of the shop register. The first cell is the introduced quantity by the cashier, the second cell is the calculated quantity b= y the application, the third 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 b= y the application, the third cell is the unsquare quantity. This window has a button that opens other window that allows to view the detail of all credit c= ard 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 i= s the calculated quantity by the application, the third cell is the unsquare quantity. The shop chief can change the introduced quantity by the cashier, the application must save this change and its author. The shop chief can introduce in this window an observation relationat= ed with a unsquare. When the shop chief acceps: * If the cash unsquare is not 0, the application must create a incident of 'cash unsquare' type, associated to the shop register closing. * If the credit card unsquare is not 0, the application must create a incident of 'credit card unsquare' type, associated = to the shop register closing. * If the gift cheques is not 0, the application must create a incident of 'gift cheque unsquare' type, associated to the sh= op register closing. =20 =20 Window 3 of UC 5 =E2=86=92 Listing of credit card tickets ------------------------------------------------- This window allows to view a listing of all credit card tickets of th= e cashier closing selected in the window 1. This window appears when th= e shop chief clicks on the button of view the credit card tickets of th= e 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 datapho= ne. The shop chief introduces a unsquare quantity and select the ticket t= hat 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 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, associa= ted to the unsquared ticket, and with the unsquare quantity. Use case 6: Items management =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 insert, update, delete, reactivate or consult the items that are solded in the shop and set their present sell prices. The data of each item are: 1. Internal code 2. Description 3. Trade mark 4. List of bar codes, each item can have several bar codes and o= ne by default 5. Weight in grams 6. Height, width, depth in centimeters 7. Subfamily: Each item belongs a subfamily, each subfamily belo= ngs a family and each family belongs a section 8. Type tax: each item has a type tax, it can be a percentage or= a fixed quantity 9. Present sell price. If a item has not a sell price it can not= be sold in the shop. This use case allows the shop chief: 1. Insert, update, delete, reactivate, and set the present sell price of the items using a script that reads the information from a XML file. 2. Consult the items of the shop and their present prices, it is the window 1. The script has to read the XML file and performs the indicated operations in each item contained in this file. For example, the form= at of this file can be:=20 <item action =3D "add"> <internal_code>12</internal_code> <description>Water bottle 1.5 L</description> <trade_mark>WATER MARK 1.5 L</trade_mark> <barcode_list> <barcode is_default =3D "YES">21342423</barcode> <barcode>43523143</barcode> </barcode_list> <subfamily>Waters</subfamily> <weight>1500</weigth> <heigth>30</heigth> <width>10</width> <depth>10</depth> <type_tax>IVA 16 %</type_tax> <sell_price>0.30</sell_price> </item> <item action =3D "update"> <internal_code>12</internal_code> <sell_price>0.35</description> </item> <item action =3D "delete"> <internal_code>12</internal_code> </item> <item action =3D "reactivate"> <internal_code>12</internal_code> </item> =20 =20 The add operations of the XML file has to include all item attributes= . The update operations of the XML file has to include the internal cod= e of the item and the attributes that shop chief want to change. The sh= op chief will use this operation type to set the present item price, it will be the new price until the shop chief changes it again. The delete operations of the XML file can not delete the items of the BD, only mark is as inactive, this operations contains only the inter= nal code of the item that the shop chief want to delete. The reactivate operations of the XML file allow to activate a item th= at was previously deleted, this operation contains only the internal cod= e of the item that the shop chief want to reactivate. Window 1 of UC 6 =E2=86=92 Listing of items ----------------------------------- This window allows the shop chief to consult the items of the shop an= d their prices. This windows has two parts, the filters and the table o= f results. The filters are: 1. Internal code of the item 2. Description of the item 3. Trade mark 4. Bar code 5. Item deleted: boolean that indicated if the item was deleted. 6. Section, family and subfamily, it must a tree that allows to add, delete or move sections, families and subfamilies The data of the result table are: 1. Internal code of the item. 2. Description of the item. 3. Default bar code. 4. Weight, height, width, depth. 5. Default bar code. 6. Is deleted: it indicates if the item was deleted. 7. Present sell price. 8. Type tax of the item =20 =20 Use case 7: Incidents management =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=3D=3D=3D= =3D This use case allows the shop chief to manage the incidents. There ar= e 4 types of incidents:=20 * Cash unsquare: this incidents are created when the shop chief performs a "Checking of shop" and exists an cash unsquare. Th= is incident is associated to the shop register closing. =20 * Gift cheque unsquare: this incidents are created when the sho= p 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 sho= p 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 = the 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 car= d ticket. =20 =20 Window 1 of UC 7 =E2=86=92 Listing of incidents --------------------------------------- The shop chief uses this window to select the incident that he want t= o manage. This windows has two parts, the filters and the table of results. The filters are: 1. Incident date 2. Incident type 3. Incident state 4. Cashier name 5. Shop register number. The data of the results table are: 1. Incident date and time 2. Incident type 3. Incident state 4. Cashier name 5. Shop register number. 6. Shop register name. The shop chief can select a incident and manage its in the window 2. Window 2 of UC 7 =E2=86=92 Detail of incident ------------------------------------- This window allows the shop chief to manage a incident, selected in t= he window 1, the data of this window are: 1. Time and date of the incident 2. Type of the incident 3. Number and name of the shop register and the name of the cashier. It is the shop register and the cashier that caused = the unsquare. 4. Unsquared quantity 5. Observation: the shop chief can introduce a observation associated to the incident. 6. Incident state: The shop chief can change the state of a incident, the possible states are: active, in current state, finalized and deleted. =20 =20 Use case 8: Consult cash of the shop registers =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=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 consult the present cash of th= e openeded shop registers. The shop chief uses this information to deci= de if a cashier must add or retire cash of his shop register. Window 1 of UC 8 =E2=86=92 Listing of shop registers=20 -------------------------------------------- The shop chief uses this use case to view the present cash quantity o= f each shop register. This window contains a listing with all opened sh= op registers, the data of each shop register are: * Number of shop register * Description of shop register * Name of the cashier * Present cash quantity in the shop register This window must have a button that allows refresh the cash quantity = of each 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 |
From: Sergio V. S. <sv...@ig...> - 2005-04-26 17:40:22
|
Hi, following with the document analysis I had made an initial design for a document workflow. You can found it as attachment of this mail. There is another attachment with a typical workflow design. My design was based on it. We should discuss the implementation of this design later. Bye. |
From: Sergio V. S. <sv...@ig...> - 2005-04-26 11:28:38
|
On Mar, 2005-04-26 at 13:04 +0200, Alejandro Garc=EDa Castro wrote: > What would it happen if we want to recover an old release of a document? As you can see in the picture, there is a relationship between a document and its previous version. > Why do we need two codes? Could we use just the barcode? Well it is a good question, I will justify my decission, the reason for using two identificators is that the barcode is used for physical document management, I mean, printed documents could be easily imported to the information system with a simple barcode reader.=20 The serial code is a document-recipient-oriented identifier. Some providers could demand us to issue their invoices with a particular numeration. So I thought it was a property of invoices and not of all documents. But the same requirements are met by delivery notes or even tickets for some kind of customers (big enterprises). That is the reason why I think it is a property of the document. What do you think? Bye. |
From: Alejandro C. <ac...@ig...> - 2005-04-26 11:04:19
|
On Tue, Apr 26, 2005 at 12:52:38PM +0200, Sergio Villar Senin wrote: > Hi, > > There are some things that I forgot in my first mail. > * there could be some document versions but only the last one should > be active, i.e, the other ones souldn't be taken into account for > business processes (in a production environment I mean, this does not > include other processes like data warehouse). What would it happen if we want to recover an old release of a document? > * the date and the one who performed the document transition should > be registered. > * a document could be identified with: > * a code sequentially generated which is document type depending > * a barcode which is document type depending. This is very useful > for reading documents with barcode readers. > Why do we need two codes? Could we use just the barcode? -- Alejandro Garcia Castro mailto: ac...@ig... http://www.igalia.com |
From: Sergio V. S. <sv...@ig...> - 2005-04-26 10:53:03
|
Hi, There are some things that I forgot in my first mail. * there could be some document versions but only the last one should be active, i.e, the other ones souldn't be taken into account for business processes (in a production environment I mean, this does not include other processes like data warehouse). * the date and the one who performed the document transition should be registered. * a document could be identified with: * a code sequentially generated which is document type depending * a barcode which is document type depending. This is very useful for reading documents with barcode readers. I have attached the diagram that represents the data structures into a RDBMS. There were no suggestions :( for my last mail, I hope almost one for this one. Bye. |
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 |
From: Sergio V. S. <sv...@ig...> - 2005-04-25 09:22:02
|
Hi, the Fisterra team is analyzing the document pattern that will be used in the next release of Distribution project. This analysis pattern is used for managing all actions related to documents like tickets, invoices, orders... We will evaluate also the insertion of some kind of workflow. These are the requirements I propose. I would like to encourage everybody to contribute to this process. * There are some document types and a document can be converted from a set of origin types to a set of destination types. * A document with a given type can be in different states. * A document with a given state can have different versions. * We must be able to browse the life cicle of a given document, i.e, all its ancestors. * Document transitions: a document should be transformed between two types with the following conditions * a transition is made of one or more actions * there must be almost one reponsible for each action, who will validate the action. The responsible could delegate its decission in another actor. * the action could have some constraints, for example time constraints, localization constraints. * the actions and even the transitions could have some kind of priority. * the flow could be from multiple documents to a single or even multiple documents too. For example we could create an invoice from a set of tickes. Another sample is flowing from a single ticket to a refund that will generate also a payment and an incident. Bye. |
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-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: 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: D. P. <jd...@ig...> - 2005-04-21 20:39:06
|
Hi: We've migrated the project web to the new Igalia Community portal [1] this week. Though the web design is nearly the same, it's now fully wiki, and integrates better with our development tools. Main changes are: - It's done in TWiki [2], and has been focused on increasing the easiness to add new contents for project developers. - Increased information about how to collaborate with the project, and reorganized contents. - Better integration with development tools. It now includes links to browse the code through Bonsai, the Tinderbox compilation status and shortcuts to add or query bugs. It's all in the home page, in the Fast Board section. =20 More information about the Community Portal in Igalia release announcement [3] (currently in Spanish). [1] http://community.igalia.com [2] http://twiki.org [3] http://igalia.com/content/view/full/854 --=20 Jos=E9 Dapena Paz Computer Engineer Phone: +34 981 91 39 91 Fax: +34 981 91 39 49 mailto:jd...@ig... IGALIA 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: 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-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: Alejandro C. <ac...@ig...> - 2005-04-15 10:08:20
|
On Fri, Apr 01, 2005 at 03:24:34PM +0200, Alejandro García Castro wrote: > > Hi, > > we have been working on a release policy for fisterra. I've sent you the > first proposal. Any help or comments will be appreciated :). Afterwads we > will try to write a roadmap based on the relase policy. > Ok, after this time of discussion ;-), I'll upload this paper to the documentation and assign the first unstable release numbers. Next week we will try to point out the roadmap for the first fisterra 2 stable release, although fisterra-base has a lot of features yet we will try to define the roadmap to create a simple and quickly implemented fisterra-distribution, but trying to solve an actual business. Greetings. -- Alejandro Garcia Castro mailto: ac...@ig... http://www.igalia.com |
From: Sergio V. S. <sv...@ig...> - 2005-04-07 15:11:55
|
Hi, the Fisterra team had always in their minds the idea of incorporate the Web into the Fisterra project. The most promising RPC used into Web applications is SOAP. The Fisterra architecture allows to exchange the current middleware (CORBA) by other without recoding business and client logic. We were evaluating some options and we finally decided to use the SOAP middleware. First of all we tried to automatically transform from IDL to WSDL. We use the a Mico ORB tool called idl. This translation was not fully automatic but it did not require us a lot of job. Afterwards we use the gSOAP project to build both pure C SOAP server and client only to test the transmission of Barnacles by SOAP. We found some problems but we were able to transmit a Barnacle. The Fisterra team is currently testing (among a lot of new features) a PHP client that uses SOAP to call Fisterra services. The PHP client uses the project NuSOAP. We want to generate automatically the most code. It would be nice to have a WSDL generator like our IDL generator in order to avoid translating between the two formats. Perhaps we also will need to patch some tools we used, in order not to edit the generated code manually as we have to do nowadays. If you have some knowledge about any of these topics feel free to contact Igalia people to contribute to the project. Bye. |
From: Javier F. <jfe...@ig...> - 2005-04-02 14:36:08
|
Hi, I find out a problem with use of libintl (libintl.h) in combination whith gnome library (gnome.h). When you declares this headers on any file, if gnome.h declaration is placed under libintl.h, some structures and variables are redefined an produces a strange linking error : In file included from /usr/include/libfisterra-common/util_intl.h:27, from /usr/include/libfisterra-common/util_com.h:28, from ../../../src/common/com/f_com_mapping.h:30, from f_com_corba_model_delegate.h:23, from f_com_corba_model_delegate.c:34: /usr/include/libintl.h:40: error: parse error before "const" /usr/include/libintl.h:44: error: parse error before "const" /usr/include/libintl.h:51: error: parse error before "const" /usr/include/libintl.h:81: error: parse error before "const" /usr/include/libintl.h:85: error: parse error before "const" /usr/include/libintl.h:90: error: parse error before "const" distcc[25642] ERROR: compile f_com_corba_model_delegate.c on localhost failed make[1]: *** [f_com_corba_model_delegate.lo] Error 1 To prevent this error, you must take care with header files declaration and ensure that the order is the correct : #include "f_com_mapping.h" ... ... #include "gnome.h" Not only "f_com_mapping.h" is affected by this strange situation; any file that includes, directly or not, the util_int.h is affected by this problem. You must to declare them before "gnome.h" header. The files f_client_util.h, util.h, util_com.h are examples of these files. -- 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: Alejandro C. <ac...@ig...> - 2005-04-01 13:24:47
|
Hi, we have been working on a release policy for fisterra. I've sent you the first proposal. Any help or comments will be appreciated :). Afterwads we will try to write a roadmap based on the relase policy. Greetings. -- Alejandro García Castro mailto: ac...@ig... http://www.igalia.com |
From: D. P. <jd...@ig...> - 2005-04-01 11:04:01
|
El vie, 01-04-2005 a las 11:36 +0200, Javier Fernandez escribi=F3: > There are some problems with versions of gtk-doc-tools earlier than > 1.3-3.1. P,ese, check your debian pakckages to ensure a correct > generation of fisterra dock package. It would be nice to enforce gtk-doc 1.3 in configure.in: Now: 216 GTK_DOC_CHECK(1.0) It should be 1.3. In debian package generation scripts, we should add a build depend=20 to fisterra-distribution-doc. (I have not a copy of the CVS tree now, that'= s I don't fix it on my own O:). --=20 Jos=E9 Dapena Paz <jd...@ig...> Igalia, S.L. |
From: Javier F. <jfe...@ig...> - 2005-04-01 09:36:21
|
El mi=C3=A9, 23-03-2005 a las 14:27 +0100, Eloy Froufe P=C3=A9rez escribi= =C3=B3: > The new documentation of Fisterra Distribution and Fisterra Base is > already available. >=20 There are some problems with versions of gtk-doc-tools earlier than 1.3-3.1. P,ese, check your debian pakckages to ensure a correct generation of fisterra dock package. --=20 Javier Fernndez Garca-Boente Ingeniero en Informtica =20 mailto:jfe...@ig... =20 Igalia S.L. http://www.igalia.com Telf. +34 981 91 39 91 =20 Fax. +34 981 91 39 49 |