Welcome to JRI's Help page for Auto Invoicing/Statements
Auto Invoicing/Statements is an automated process to run the Invoice Workbench (SOP9014) first implement in Nov. 2010. It runs through cron every night at 9:10 PM EST and is controlled via DSCTBL AUTO.INVOICE.
Based on the data in DSCTBL AUTO.INVOICE, Auto Invoicing will loop through the companies & warehouses as needed and process the data.To ensure that Auto Invoicing runs exactly the same way as the Invoice Workbench, the main program, SOPS9014.4 populates WORK with the same variables that the input screen would. It then calls the same subroutines that the Invoice Workbench does, thus ensuring that, right or wrong, Auto Invoicing does exactly what SOP9014 does. These subroutines have been slightly tweaked to populate other WORK variables so that any critical information that would normally go to the screen can instead be processed by Auto Invoicing.
There are 2 control records that are used for Auto Invoicing/Statements:
- DSCTBL AUTO.INVOICE &
- DSCTBL AUTO.STATEMENTS
DSCTBL AUTO.INVOICE gets updated with the date stamp every time it runs.
DSCTBL AUTO.STATEMENTS gets updated only if 1 or more companies are queued for Statements.

In a nutshell, Auto Invoicing will loop through the companies as defined in DSCTBL AUTO.INVOICE and:
-
Simulate running the Invoice Workbench SOP9014
- Populate WORK as if the user had manually answered the prompts
- Simulate hitting F2 by running the same UPDATE process SOPS9014.2 which will:
- Use the SHIPTRNs for the desired company and build ICEHDRs
- Archive the SHIPTRN to SHIPTRNHST
- Archive all ICEHDRs for the desired company (possibly picking up some additional invoices) to ICEHDRHST (simulating the printing)
- Send all invoice data via EDI to those customers set up for this (via SOP9159)
- Create PDFs and DOCATTACHs for all ICEHDRHSTs (including any manually processed invoices from earlier in the day) and E-mail them to those customers set up for this (SOP9121)1
- Bundle the snail-mail PDFs as needed and send to 3rd processing companies (i.e. Lanvera) - see "the Bundler" tab
- Collect the total dollars billed for the company
- Run Auto Statements logic (see A/R Statements tab)
- Send a detailed E-mail of all activity for the company
A final, summary E-mail is sent showing the totals for all companies processed.
Note that there is a huge log built called AUTO.INVOICE.RESULTS. This gets overwritten each night, but contains a lot of details about each step.
Also note that all of the invoice and statement PDFs that were built on the G: drive also get copied to Dayton Access where our customers can pull them up.
Auto Invoicing runs every night. Auto A/R Statements was added to this process in mid 2013. The final step for each company is to check DSCTBL AUTO.STATEMENTS. If the company in question is found in F2 of AUTO.STATEMENTS, Statements (ARM9030) will also be run for that company. If A/R Statements are run for a company, the company is removed from the DSCTBL AUTO.STATEMENTS control record to ensure it does not run again next time. After looping through all desired companies, DSCTBL AUTO.STATEMENTS is written back to disk, minus any companies that were just processed.
To trigger a company to run Auto Statements as the final part of Auto Invoicing, someone (Sharon, Colleen or Syed) must first run process ARM9020 to queue up their company.
Enter the desired company and month-ending date, then hit F2 to save the change.
To remove a company from Auto Statements, simply run ARM9020 and remove the offending company from the list.
This will save the control record DSCTBL AUTO.STATEMENTS which SOPS9014.4 (Auto Invoicing) will use to determine which (if any) companies want Auto Statements to run that night.
After building PDFs and DOCATTACHs (by SOP9121 or ARM9030), Auto Invoicing will call the Bundler. The Bundler (SYSS9111.11), does a number of key tasks that are required for sending data to the 3rd party processor (Lanvera). These are needed to ensure that we only send 1 copy of an invoice to the customer and that they get it in the format they wish. The Bundler is used to transmit both the Invoices and A/R Statements.
After initial setup, the Bundler performs the following tasks:
- Clears the contents of PDF.BUNDLE.INVOICES or PDF.BUNDLE.STATEMENTS (based on which it is bundling)
- Select all the invoice (or statement) DOCATTACHs that were just built for the current company (either by SOP9121 or ARM9030)
- Loop through the selected DOCATTACHs
- Append DOCATTACH key to DOCATTACH.KEYS array
- Call SYSS9111.12 to determine E-mail address (or not)
-
Populate DOCATTACH F20 to indicate how the document was sent & add key to associated dynamic array:
Code Description Array E E-mailed to customer (preferred) EMAILED.DOCATTACH.KEYS EDI EDI'ed to customer (rare) EDI.DOCATTACH.KEYS M Manually printed (we have to assume the user will get the invoice to the customer) MANUAL.DOCATTACH.KEYS S Staged for bundling to be sent to Lanvera STAGED.DOCATTACH.KEYS
- Save DOCATTACH.KEYS to a SAVEDLIST called PDF.BUNDLE.INVOICES.cc or PDF.BUNDLE.STATEMENTS.cc for possible debugging
- Loop through DOCATTACH.KEYS (backwards)
- Attempt to pull the PDF from the G: drive over to PDF.BUNDLE.INVOICES (or PDF.BUNDLE.STATEMENTS)
- Verify that the PDF was successfully pulled and if so:
- Remove the key from the dynamic array (thus it gets smaller with each success)
- Change the DOCATTACH BUNDLE flag from "S" to "B" (Bundled)
- Else
- Move on to the next key
- Verify that the PDF was successfully pulled and if so:
- Attempt to pull the PDF from the G: drive over to PDF.BUNDLE.INVOICES (or PDF.BUNDLE.STATEMENTS)
- If any keys left in DOCATTACH.KEYS, make another pass through the array (unless we have tried too many times)
- If any of the expected PDFs failed to be copied (and thus bundled)
- Build a SAVEDLIST called ICEHDRHST_cc_yyyy-mm-dd_hh-mm-ss or CUSTMST_cc_yyyy-mm-dd_hh-mm-ss
- You must review all available info to determine why there was a failure - past examples are:
- Optio is running sssslowly
- Samba has failed for some reason
- The folder(s) on the G: drive are bloated and Optio is taking more than the expected amount of time
- Your best source of information will likely be AUTO.INVOICE.RESULTS
- After determining why things failed and you are ready to proceed:
- Run SYSS9111.11.DRIVER
- When prompted, enter the name of the SAVEDLISTS above
- Review the results of each carefully
- If too many attempts were made, move on (if there is a problem, do not get stuck in an infinite loop)
- Send summary E-mail showing the counts
- Create a UNIX script to "zip" all the PDFs in PDF.BUNDLE.INVOICES (or PDF.BUNDLE.STATEMENTS)
- Execute the UNIX script
- Remove any prior version of the file from DLDATA
- Copy the "zipped" file to DLDATA with the normal port-based name
- Set the begining of the file name based on type and company
- Transmit the file via SYSS9002.3
- Build the new, full file name based on extract type, company, date and time (re-using date & time if already set)
- Move the port-based file from DLDATA to FTP.ARCHIVE using the new name
- Build a mini SFTP batch file to remotely "put" the file
- Parent dir
- If LIVE.DATA and DSCTBL AUTO.INVOICE<26,1> then cd AUTO.INVOICE<26,1>
- If not LIVE.DATA and DSCTBL AUTO.INVOICE<26,2> then cd AUTO.INVOICE<26,2>
- Based on the account and OPTIONS<1,10>, we may cd into a sub-sub directory
- Parent dir
- Save the batch file
- Execute the SFTP command which also runs the batch file
- Build the "counts" file
- Use the above steps to archive and transmit the "counts" file
Occationally, there is a problem with Auto Invoicing, usually with Optio failing to build the needed PDFs. The following instructions are the likely steps to fix this1:
- Always review the AUTO.INVOICE.RESULTS file.
- Determine how many PDFs were actually built:
- Go to G:\Avante Attachments\Invoices\LIVE\yyyy
- Sort the PDFs by date
- Count the PDFs that were built by Auto Invoicing (any PDF after 9:10 PM for the day in question)
- Compare this count vs. the counts reported in the Auto Invoicing emails
- Determine how many invoices were built:
- COUNT ICEHDRHST WITH INV_DATE = "mm/dd/yy" BY COMPANY
- Determine how many invoices were built w/o a PDF.DATE:
- COUNT ICEHDRHST WITH RELEASE_NBR # "0" AND WITH INV_DATE > "06/30/08" AND WITH NO PDF.DATE
- This number should agree with the # of missing PDFs
- For each invoice that still needs a PDF, set ICEHDRHST.USR PDF.DATE to null (they are probably already null)
- Create the missing PDFs:
- Go to the Avante menus
- Run process SOP9121
-
Enter a "Y" for the single prompt and hit F2
- Check on the status of the PDFs:
- Go to G:\Avante Attachments\Invoices\LIVE\yyyy
- Wait until the PDFs stop being created
- Count the number of PDFs from the manual run plus those from Auto Invoicing
- They better match the number of total invoices!
- Once all of the missing PDFs have been built:
- From TCL:
- Make sure that SYSTBL LAST.INVOICE exists (it does not matter what is in it)
-
Change DSCTBL SYSS9111.11.DRIVER F7 to match the company you wish to process:
- COMO ON JRI
- SYSS9111.11.DRIVER
- Enter the SAVEDLIST name (from the email)
- This will:
- Verify the keys in the SAVEDLIST are valid
- Give you the # of keys in the SAVEDLIST (it beeter agree with what was missing!)
- Show the PDF.DATE that will be used
- Show the time range of the PDFs
- Prompt for you to continue (must enter "Y***")
Note that this can take a while since it is doing a lot of validations -
When finished, you should see a message similar to the one below:
- COMO OFF
-
This will complete the PDF process:
- Build the PDFs on the G: drive
- Email the PDFs to customers as needed
- Bundle & FTP the "snail mail" PDFs to Lanvera
- Review the COMO file
- Change DSCTBL SYSS9111.11.DRIVER F7 back to 01
- From TCL: