Projects:Multiple Sales Terminals Single Payment Terminal
Contents |
Introduction
- Project Owner: Rafa Alonso
- Project Stakeholders: Dmitry Mezentsev, Ismael Ciordia
- Project Timeline:
- Part of 2015 Q2 delivery
- End of development incl automated tests end of Feb 2015
- Documentation: Feb 2015
- Feature request in Mantis: https://issues.openbravo.com/view.php?id=28130
Functional requirements
Main goal
- Separate the sales and payment functions: this development will make it possible to create a ticket in one terminal and add items or pay it in another terminal. This gives new possibilities for our customers in organizing their stores and terminals
Use case
- Create a layaway
- Retrieve the layaway in any store terminal of the same store (preconditions: terminal has to be online and same organization)
- Complete or partial payment is performed
Use case flow
- Open the menu
- Tap on the 'Layaways' menu entry. The layaway popup is shown
- Write a search string
- Tap the search button
- Select the layaway to be retrieved
- The layaway is be shown
- Partial or complete the payment of the layaway
Restrictions, capabilities and assumptions
- Available within the same store (aka organization)
- Terminals can read each others tickets
- Each terminal which has payment methods defined can pay the ticket of another terminal
- Document number: the number assigned to the first receipt will be the definitive document number
- If a terminal has no payment methods then the pay button should be hidden, or another elegant solution should be chosen to prevent paying
- The availability of this functionality will not be controlled by a preference
- Authorizations/approval mechanisms are not needed
- The layaway will maintain the first POS terminal and sales representative
Technical design
Code flow
- Create layaway
- < User creates a layaway >
- Send the layaway to the backend
- Create an entry in the order table
- If the layaway has an initial payment, add the transaction to the fin_finacc_transaction table. Set the cashupId to this terminal's cashupId
- Partial layaway payment
- < User retrieves a layaway >
- < User partial pay a layaway >
- Send the layaway to the backend
- Add the transaction to the fin_finacc_transaction table. Set the cashupId to this terminal's cashupId
- Close layaway payment
- < User retrieves a layaway >
- < User completely pay a layaway >
- Send the layaway to the backend
- Add the transaction to the fin_finacc_transaction table. Set the cashupId to this last terminal's cashupId
- Set the order's cashupId to this last terminal's cashupId
Application
- This functionality will be delivered as part of the core retail solution (mobile.core)
- Masterdata: all terminals will have the required masterdata because the organization scope
- The required 'em_obpos_app_cashup_id' field was already created when the Cash Management was updated to track the cashupId in which the cash management movement was done.
Execution plan
- Layaway retrieval: break the terminal restriction of the query that retrieves the layaways from the server. Change it to organization. Related java classes: PaidReceiptsHeader and PaidReceipts
- Orderloader: handlerpayments or procespayments pick up the payment, search for the transactions and set the cashupid
- Modify and add indexes to the cashup queries. cashcloseprocessor. simplify the query as we have all the transaction. maybe the actual cash management query is valid
Quality assurance
- Existing tests will be fixed to support this functionality
- Several automated tests will be created, testing the complete flow
Suggested tests:
- Layaway_Cre1Fin1: Create a layaway, retrieve and finish it in terminal 1001
- Layaway_Cre1Fin2: Create a layaway in terminal 1001, finish it in terminal 1002
- Layaway_Cre1Par1Fin2: Create a layaway with initial payment in terminal 1001, finish it in terminal 1002
- Layaway_Cre1Par2Fin2: Create a layaway in terminal 1001, partial pay in terminal 1002, finish it in the terminal 1002
- Layaway_Cre1Par2Fin1: Create a layaway in terminal 1001, partial pay in terminal 1002, finish it in the terminal 1001
- Layaway_Cre1Par2Fin3: Create a layaway in terminal 1001, partial pay in terminal 1002, finish it in a terminal 1003
- Layaway_Cre1Par1Par2Fin3PaymentMethodsTaxModels: Create a layaway with initial payment in terminal 1001, partial pay in terminal 1002, finish it in terminal 1003 mixing payment methods and tax models
- Layaway_Cre1Voi2: Create a layaway in terminal 1001, void in terminal 1002
- Layaway_Cre1Par2Void3: Create a layaway in terminal 1001, partial pay in terminal 1002, void in terminal 1003
- Verify cashup in all tests
- Verify server transactions in all tests
Questions - Open topics
- A cashup is required before applying these project changesets. Should we inform the user? add compatibility? add modulescript?