Appendix A - Report Control Automation Processing

AddonSoftware Administration - Appendix A – Report Control Automation Processing

Report Control can be set up for both batch style Jasper documents, such as Statements or Invoices, as well as stand alone DocOut or Jasper reports. The Report Control Documents table must contain an entry for each document subject to Report Control. Depending on the Recipient type specified for the document, one or more Report Control Recipients will be set up for each record in the Report Control Documents table. Details can be found in Appendix B - Batch Processing Control.

Valid Recipient Types are Customer, Vendor, or Other. If the Recipient Type for a document is Customer or Vendor, then multiple Report Control Recipient records can be defined, specifying either the Customer or Vendor ID in each record. Recipient Type Other is intended for use in stand alone reports, facilitating email/fax to a single recipient.

This document contains code snippets to illustrate how the various report types can be set up for Report Control.

Standard Batch Report Control Documents

ARR_INVOICES
ARR_STATEMENTS
OPR_INVOICES
POR_POPRINT

Traditional (non-batch) reports containing +AUTO_SEND Report Control code

AR Aging (DocOut)
AR Invoice Register + GL Recap (DocOut register/recap pair)
AP Vendor Detail Listing (Jasper report)

Batch Report Flow Example: AR Invoices

The main AR Invoice program instantiates the Report Control object and checks to see if it is subject to report control:

rem --- See if this document is set up in Addon Report Control

reportControl!=new ReportControl()

reportControl!.setDocExtension("pdf")

rpt_ctl$=reportControl!.getReportControl(rptctl_alias$)

rpt_ctl$=iff(rpt_ctl$="","NO","YES")

rpt_id$=iff(rpt_ctl$="YES",reportControl!.getReportID(),"")

If report control is defined for this document, then as each invoice is processed, the recipient info for the given customer is retrieved from the Report Control Recipients table and pertinent settings stored in a vector:

rem --- Use ReportControl object to see if customer wants print, email, or fax

add_to_print_report=1

if rpt_ctl$="YES"

found=reportControl!.getRecipientInfo(rpt_id$,are05.customer_id$,"")

if found

if reportControl!.getPrintYN()<>"Y" then add_to_print_report=0

if reportControl!.getEmailYN()="Y" or reportControl!.getFaxYN()="Y"

emailFax!.add(rpt_id$)

emailFax!.add(are05.customer_id$)

emailFax!.add(new_doc_id$)

endif

When the user dismisses the Jasper viewer, if the aforementioned vector isn't empty, they are prompted to send the documents to the Doc Queue:

if emailFax!.size()

msg_id$ = "CONF_RPTCTL"

gosub disp_message

if msg_opt$="Y"

for email_fax=0 to emailFax!.size()-1 step 3

reportControl!.addToDocQueue(emailFax!.get(email_fax),

: emailFax!.get(email_fax+1),"",emailFax!.get(email_fax+2))

next email_fax

endif

Traditional DocOut Report Flow Example: AR Aging

Prior to exiting, the application report program instantiates the Report Control object and checks to see if it is subject to report control:

rem --- see if this report is set up for report control (email/fax)

rem --- next_overlay$ (and stbl("+AUTO_SEND")) will get set only if this report is defined for automated email/faxing

if Option!<>null()

rpt_id$=Option!.getAlias()

else

rpt_id$=pgm(-2)

rpt_id$=rpt_id$(max(pos("/"="/"+rpt_id$,-1),pos("\"="\"+rpt_id$,-1)))

rpt_id$=rpt_id$(1,pos("."=rpt_id$+".")-1)

rpt_id$=cvs(rpt_id$,4)

endif

reportControl!=new ReportControl()

reportControl!.setDocExtension("pdf")

tmp$=reportControl!.getReportControl(rpt_id$)

next_overlay$=iff(tmp$<>"",tmp$,overlay$)

goto std_exit

If so, the getReportControl() method will set the +AUTO_SEND global, and return the name of the next_overlay$ program (adx_rptctl_setup.aon). Processing continues as normal, that is:
- The application program runs Barista's bas_process_end.bbj program, which in turn calls the DocOut program (bax_docout.bbj)
- DocOut looks to see if +AUTO_SEND contains any data, and if so, appends the document ID for the document it just created (this is new functionality in DocOut)
- Upon returning from DocOut, bas_process_end.bbj checks next_overlay$
- - if null, processing terminates and control returns to Barista's MDI/Menu
  - if not null, the next_overlay$ program is run and next_overlay$ is cleared
The adx_rptctl_setup.aon (next_overlay$) program:
- Prompts the user for confirmation to add the doc to the queue
- Parses the +AUTO_SEND global and uses the Report Control object to add the document to the Doc Queue
- Checks to see if overlay$ is set to run the GL Recap. For a traditional report, overlay$ isn't set, so adx_rptctl_setup.aon just calls the destroy() method on the Report Control object
- Clears next_overlay$
- Runs bas_process_end.bbj, which will return control to the Barista MDI/Menu
In summary, the processing path for a traditional report is:
- Report => DocOut => DocQueue => Menu

Register/Recap/Update Report Flow Example: AR Invoice Register

The register sets the update$, overlay$, and next_overlay$ strings as always, depending on whether or not the update will be allowed, and if GL is installed. If GL is installed, overlay$ will be set to the GL recap program:

update$=pgmdir$+"aru_invoiceentry.aon"

overlay$=update$

if gl$="Y" overlay$=pgmdir$+"glr_recap.aon"

next_overlay$=overlay$

Prior to exiting, the register instantiates the Report Control object and checks to see if it is subject to report control.

rem --- see if this report is set up for report control (email/fax)

rem --- next_overlay$ (and stbl("+AUTO_SEND")) will get set only if this report is defined for automated email/faxing

if Option!<>null()

rpt_id$=Option!.getAlias()

else

rpt_id$=pgm(-2)

rpt_id$=rpt_id$(max(pos("/"="/"+rpt_id$,-1),pos("\"="\"+rpt_id$,-1)))

rpt_id$=rpt_id$(1,pos("."=rpt_id$+".")-1)

rpt_id$=cvs(rpt_id$,4)

endif

reportControl!=new ReportControl()

reportControl!.setDocExtension("pdf")

tmp$=reportControl!.getReportControl(rpt_id$)

next_overlay$=iff(tmp$<>"",tmp$,overlay$)

goto std_exit

If so, the getReportControl() method will set the +AUTO_SEND global, and return the name of the next_overlay$ program (adx_rptctl_setup.aon), i.e., inserting the report control program in the "chain" ahead of the GL recap. Processing continues as normal, that is:
- The register runs Barista's bas_process_end.bbj program, which in turn calls the DocOut program (bax_docout.bbj).
- DocOut looks to see if +AUTO_SEND contains any data, and if so, appends the document ID for the document it just created (this is new functionality in DocOut)
- Upon returning from DocOut, bas_process_end.bbj checks next_overlay$
- - if null, processing terminates and control returns to Barista's MDI/Menu
  - if not null, the next_overlay$ program is run and next_overlay$ is cleared
The adx_rptctl_setup.aon (next_overlay$) program:
- Prompts the user for confirmation to add the doc to the queue
- Parses the +AUTO_SEND global and uses the Report Control object to create a Doc Queue object
- Checks to see if overlay$ is set to run the GL recap. Since it is, the program removes the already-processed document ID from the end of the +AUTO_SEND global
- Sets next_overlay$ = overlay$
- Runs bas_process_end.bbj, which will move on to the GL recap
The GL recap program first sets the next_overlay$ to be the update$ program, then checks to see if report control was specified for the previous register. If so, it sets overlay$ = update$, and next_overlay$ to the adx_rptctl_setup.aon program, i.e., inserting the report control program in the "chain" ahead of the update:

next_overlay: rem --- Run update overlay

if OutVect!<>null() then

next_overlay$=update$

rem --- if register was set up for automated email/fax, send recap along as well

if reportControl!<>null() and stbl("+AUTO_SEND",err=*endif)<>""

overlay$=update$

next_overlay$=reportControl!.getNextOverlay()

endif

out_action$="PRT"

goto std_exit

else

dummy$=stbl("+AUTO_SEND","")

next_overlay$=""

out_action$=""

run update$,err=remove_locks_and_exit

endif

The adx_rptctl_setup.aon (next_overlay$) program:
- Prompts the user for confirmation to add the doc to the queue
- Parses the +AUTO_SEND global and uses the Report Control object to create a Doc Queue object
- Checks to see if overlay$ is set to run the GL recap. Since the GL recap has already been processed (i.e., overlay$ is now set to be the update$ program if the update is allowed), it just calls the destroy() method on the Report Control object
- Sets next_overlay$ = overlay$ (i.e., the update program, if allowed)
- Runs bas_process_end.bbj
In summary, the processing path for a register/recap/update series is:
- Register => DocOut => DocQueue => GL recap => DocOut => DocQueue => Update => Menu

______________________________________________________________________________________