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.

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

           endif

       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

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







______________________________________________________________________________________

Copyright BASIS International Ltd. AddonSoftware® and Barista® Application Framework are registered trademarks.