ED HAYES

A year and a half ago, our company embarked on a project to run Oracle E-business R12. Part of that process included a manufacturing migration from our legacy systems, and the other part included a migration of financial modules from Oracle 11i.  Included in the 11i financial modules was Accounts Payable, thus our Payment process needed to be migrated to R12.  One of my responsibilities was to create the payment output for the R12 system.  Payments in Oracle R12 are rendered with BI Publisher, an Oracle tool I became very skilled with while working on the AP project.  Although limited, BI Publisher has to be one of the most powerful technologies Oracle provides and has allowed our IT organization to become more agile.

From what I heard, it took the previous business analyst two years to get a check printed in the 11i production system, starting at the beginning of that project.  The R12 Payment processing seemed like a daunting task.  But I was up for the challenge and eager to enhance my skill set.

Within the first day of working on the payment output, I was able to get a check printed out of our test system.  Two weeks later I had a check ready to send to our bank for validation.

Although my manager was impressed, he still had some doubts. I have a feeling he was thinking around the lines of, “this is too good to be true; how can someone get a check ready for approval so fast, when took so long previously?” Whatever his thinking was, the bank validation had the ability to halt my swift progress right in its tracks.

My manager believed it would take me six cycles of bank validation before we got a check approved.  I was a bit more optimistic, but still concerned.  The guidelines for check design are well documented with extremely specific and low tolerances.  With the specifications against me, the check output I designed was approved during the first round of validation! So much for six rounds of validations!

The next part of the project was the electronic output; text files for EFT and ACH payments.  That output was also quite easy to generate given the BI Publisher (XML Publisher) tool offered by Oracle.

After a swift turnaround of the payment output, and proven power of BI Publisher, I was able to convince my manager to migrate all Oracle printed/report output to the Analyst side of the development wall.  I began to work with the tool on a daily basis and have created numerous types and styles of output all generated with Oracle BI Publisher.  However, even though it was quite powerful, BI Publisher still has some weaknesses.

Powerful Features

• Templates can be split from data extracts, letting Business Analyst create the templates, and developers create the data extracts
  • Ultimately reduces time to create, correct, and enhance reports
• WYSIWYG report creation using Microsoft Word
• Can use e-text to create delimited files output in plain text
  • E-text templates can be used to create Zebra ZPL output
• Template Viewer tool can be used to preview reports using an example XML data file
• Templates can be updated via the applications, thus no code migration process is required
• Support for Language translations
• Can use custom fonts (example: MICR, Code 39 Barcode)
• Output can be sent directly to printers and viewed as PDFs
• Allows for dynamic image insertion from files located in the Unix file system
• Dynamically created charts and graphs

Limitations

• No proper NVL or decode support; must use “if” statements
• Excel output in the Oracle Applications version of BI Publisher creates non-standard Excel files
  • Files are grossly large due to the XHTML formatting, and frequently can’t even be opened
  • If too much data is generated, the Output Post Processor (OPP) fails/times out
  • Excel gives extension/file type errors when files are opened
• Error handling is extremely poor
  • Instead of skipping a section where a trivial error occurs, the entire process fails
  • Errors in the application must be viewed under the OPP processor, not the concurrent request of the report that caused the error
  • Errors are extremely vague and frequently do not reference the section in the report in which they occur
• There seems to be a bug with the way tables/borders work with RTF files.
  • At times, tables in the RTF file become corrupt, not correctly saving the border requirements
  • Reopening an RTF file for enhancement clears the saved and working border settings
  • I have found no way to accurately reproduce the error, but I have seen it happen on several occasions
• Language Translation XLF files are not user friendly to edit/maintain
• Language Translation XLF files are hard to update when a change to the template is made
  • Translations are automatically disabled in this case
  • Translation file validation does not give errors on what portion has caused the error

Version Issues

• Version Confusion
  • XML Publisher Enterprise 5.6.3 is included in Oracle E-business Applications
  • XML Publisher Enterprise 5.6.3 was renamed BI Publisher Enterprise 10.1.3.2
• BI Publisher Enterprise continues to be improved and updated
  • The XML/BI Publisher within E-business remains un-patched for many critical features, including the fix for Excel files mentioned in limitations above.
  • Patches that reference BI Publisher are not necessarily applicable to the version included with E-business applications and patch descriptions do not reflect this

One of the biggest accomplishments I have made with BI Publisher was consolidating the extracts linked to reports.  Historically, each report would require its own data extract creating a significant amount RICE component redundancy which required long development cycles.  By combining the extracts of similar reports into one program, much like the Payment Instruction extract is used for multiple types of payment types, we are able to send one component to development instead of many.

When combined with splitting the template creation as mentioned above, it allows the business analyst to work in parallel with the developer, reducing the component creation time by half.  Furthermore, each additional report that uses the same extract requires zero development time.

The only weakness of this solution, that I can see, may also be seen as a significant strength.  If the extract contains a calculation error, the error impacts all of the linked templates/reports that use the same extract.  Arguably a similar problem would arise if a substantial portion of a report was copied from one to another when developed individually.  But, with the new method of extracts/reports, the single fix to the extract would fix all of the reports. This would not be possible if each component was developed independently, where each component would have to go through its own rounds of testing and deployment.

Our organization continues to leverage the capabilities of BI Publisher within Oracle E-business applications.  At the time of writing this, we are using an extract for Discrete Job, WIP Move, and Inventory Move Order based reports. This past week we were able to add an additional report output based on our WIP Move extract to one of our inventory organizations in production in less than one business day. The agility BI publisher provides our business is astounding.