Projects:Multiple Sales Terminals Single Payment Terminal

Contents 1 Introduction 2 Functional requirements 3 Main goal 3.1 Use case 3.1.1 Use case flow 3.2 Restrictions, capabilities and assumptions 4 Technical design 4.1 Code flow 4.2 Application 4.3 Execution plan 5 Quality assurance 6 Questions - Open topics

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

1. Create a layaway
2. Retrieve the layaway in any store terminal of the same store (preconditions: terminal has to be online and same organization)
3. Complete or partial payment is performed

Use case flow

1. Open the menu
2. Tap on the 'Layaways' menu entry. The layaway popup is shown
3. Write a search string
4. Tap the search button
5. Select the layaway to be retrieved
6. The layaway is be shown
7. 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

1. 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
2. Orderloader: handlerpayments or procespayments pick up the payment, search for the transactions and set the cashupid
3. 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:

1. Layaway_Cre1Fin1: Create a layaway, retrieve and finish it in terminal 1001
2. Layaway_Cre1Fin2: Create a layaway in terminal 1001, finish it in terminal 1002
3. Layaway_Cre1Par1Fin2: Create a layaway with initial payment in terminal 1001, finish it in terminal 1002
4. Layaway_Cre1Par2Fin2: Create a layaway in terminal 1001, partial pay in terminal 1002, finish it in the terminal 1002
5. Layaway_Cre1Par2Fin1: Create a layaway in terminal 1001, partial pay in terminal 1002, finish it in the terminal 1001
6. Layaway_Cre1Par2Fin3: Create a layaway in terminal 1001, partial pay in terminal 1002, finish it in a terminal 1003
7. 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
8. Layaway_Cre1Voi2: Create a layaway in terminal 1001, void in terminal 1002
9. 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?