Conducted successfully the following tests on the pull request after last commit:

• test with an approval workflow + column IsApproved

• Period open validation

  • test table with DocType

  • test table with Target DocType + DocType

  • the date for validation is assumed from DateAcct, DateTrx or today

• test assigning DocumentNo using sequence from DocType

  • test also setting DocumentNo and/or DateAcct on completion

The alternative approach is to create a delegate class with a constructor that takes a PO as parameter. A model class that implements DocAction interface can simply delegate all the DocAction calls to the delegate class (there’s potential for further automation through something like POWrapper, annotation or a smarter model class generator).

Hi, I added a pull request 736, marked as Draft as is not fully tested.

My tests until now:

• created a TestDoc table + window

• table must have DocAction, DocStatus and Processed columns

• create a workflow for the TestDoc table

  • common 4 nodes Start, Auto, Prepare, Complete and the corresponding transitions

  • the workflow is a bit tricky to create, is really important to set correctly the SeqNo of the nodes, and the transition from Start to Prepare must be marked as Std User Workflow

  • at the end set the starting node of the workflow to Start

• associate the workflow to a process

• associate the process to the DocAction button

With this test it’s working fine to create a document, prepare it, complete it and void it.

Pending tests:

• test with an approval workflow + column IsApproved

• Period open validation

  • test table with DocType

  • test table with Target DocType + DocType

  • the date for validation is assumed from DateAcct, DateTrx or today

• test assigning DocumentNo using sequence from DocType

  • test also setting DocumentNo and/or DateAcct on completion

Reactivate and reverse (both) are not implemented, those would still require model classes to manage it. Or maybe they can be enabled, and allow that to be managed via EventHandlers.

A big plus would be to create a process that set the initial workflow for the table, could be a process in the table, something like “Make Table a Document” and the process add the required columns (it could allow user to select which ones to create as parameters) - set the window to Transaction, create the workflow, etc.

Thinking beyond this, we could also create a GenericDoc class for posting empty accounting facts, that way we could enable to do the accounting using EventHandlers too.

Something to consider… If we define a generic doc action, I believe it should be as a model event. One for Prepare, one for Complete, etc…

I believe this supports the direction of all before/after… actions should be events (no models).

Please ignore if this is not relevant to this discussion.