Payment Print/Export to prepare PaySelectionChecks before asking for user confirmation

Description

I would like to propose a minor modification to the workflow in Payment Print/Export (org.compiere.apps.form.PayPrint).

Current workflow is as follows:

  1. Specify your PaySelection for the print run.

  2. Click on one of the processing options (eg, print, export or process).

  3. Command is processed and in the case of print or export, the user is asked for confirmation that it completed successfully.

  4. If the user specifies that the print/export happened successfully, then it will call one of the MPaySelectionCheck.confirmPrint() variants.

There are two problems with this workflow:

  • There are circumstances in which confirmPrint() can fail (I discovered one). If this happens, you'll need to re-run the Print/Export again. This could potentially cause headaches (two sets of checks, or check numbers not aligning with the system, etc).

  • Any custom PaymentExport implementations will not have access to the final payments. This information could be useful in generating the payment files - for example the payment DocumentNo field could be useful for statement narrative and auditability (it would have been useful in my case).

To work around these problems, I suggest the following alternative workflow for consideration:

  1. Specify your PaySelection for the print run.

  2. Click on one of the processing options (eg, print, export or process).

  3. A SQL transaction is started and the appropriate MPaySelectionCheck.confirmPrint() variant is executed within that transaction, but the transaction is not committed yet.

  4. The print/export is run, and the user is asked for confirmation that it completed successfully.

  5. If the user specifies that the print/export happened successfully, then the open SQL transaction in step 2 is committed; otherwise it is rolled back.

The two advantages of this workflow are:

  • Because you've waited to the very last minute to do the Print/Export run there is less chance that something can go wrong after the run is complete to invalidate the run.

  • Payment print/export formats now have access to the final Payment information that can be included in the print/export.

Thoughts?

Environment

This issue is OS independent; however for reference I'm currently using Windows 10 with PostgreSQL 9.6.

Assignee

Unassigned

Reporter

Jeremy Krieg

Labels

Tested By

None

Time tracking

40h

Components

Affects versions

Priority

Minor
Configure