Introduction:
In Oracle Fusion HCM and ERP implementations, outbound third-party integrations frequently demand flat-file text formats rather than standard visual layouts like PDF or Excel. The most prominent example is generating Electronic Funds Transfer (EFT) payment files for global financial institutions.
Banks enforce rigid formatting structures—such as specific record lengths, padding characters, and delimiter rules—to process direct deposits safely. Within the Oracle ecosystem, the most efficient way to generate these files is by building BI Publisher eText Templates. This technical guide explains how to design, construct, and validate an upgrade-safe, delimiter-based eText structure directly within Microsoft Word.
eText Layout:
Unlike standard Rich Text Format (RTF) templates that focus on visual design elements, an eText template acts as a data translator. It tells the BI Publisher layout engine exactly how to map raw XML data structures into flat ASCII text configurations.
An enterprise eText template consists of two major operational tables.
- The Setup Table (Command Block): Defines global parameters like the output character set, dynamic delimiters (e.g., commas or tabs), and record end characters (e.g., Carriage Return/Line Feed).
- The Record Layout Table (Data Block): Defines the exact sequence, maximum length, and alignment padding rules for individual database attributes mapped from the underlying XML payload.
Template Implementation:
Command Setup Block:
To get started, open Microsoft Word and create a single two-column table. This block instructs the layout compiler on how to format the macro structure of the final text document.
Data Record Block:
Next, define how your employee bank records will print. Create a separate five-column table in Word. This table maps directly to your data model group element (for example, /DATA_DS/G_1).
The table requires a specific header structure to pass the engine's translation process.
Key Functions for Advanced Banking Logic:
When dealing with production payment configurations, raw data fields often require transformation rules before hitting the text interface. Here are three critical built-in eText functions to maximize formatting control.
TRUNCATE Logic: Banks will reject lines if an employee's name exceeds field parameters. Setting a maximum length in column two automatically caps string extractions safely.
Number Formatting (9999.99): Financial networks frequently mandate that decimal points be completely removed from numeric values (e.g., $1,250.45 must print as 000000125045). Define an explicit format mask of 99999D99 with a custom decimal setting to handle currency conversions smoothly.
Conditional Displays: Use DISPLAY_CONDITION lines inside command blocks to skip rendering payment rows if bank routing fields are missing, preventing runtime file corruption.
Testing and Validation:
Once your Word document layout is complete, save the file as a Rich Text Format (.rtf) document. Upload it to your target BI Publisher report interface and apply the eText template type attribute.
While performing testing, please do the below additional checks to avoid errors.
- Check for Hidden Truncations: Open the generated .txt file in an editor like Notepad++ and turn on hidden characters. Ensure that total record lengths match the bank's schema requirements exactly.
- Validate the XML Tag Casing: BI Publisher is strictly case-sensitive. If your data model SQL prints person_number in lowercase, but your eText table declares PERSON_NUMBER, the compiler will output a blank string without throwing an explicit syntax error.
Conclusion:
Mastering custom eText templates allows technical teams to build dependable, secure, and upgrade-safe bank integrations by embedding logic directly within BI Publisher, eliminating the need for external, complex parsing scripts. This approach ensures compliant, precise, and lightweight file formatting while maintaining 100% standard functionality that survives system updates.
Top comments (0)