Open an accounting period in PeopleSoft, and woosh... the same accounting period is now open in E-Business Suite.
Add a Chart of Accounts value in PeopleSoft, and woosh again... the value now also exists in E-Business Suite.
Add an exchange rate in PeopleSoft, and... you guessed it!
It was the first time I got to see AIA in action, and yes, I was impressed.
Meanwhile it's the third time already that I'm implementing this solution, and the wow factor has disappeared, while I've gotten used to these applications being able to talk to each other, without them needing my help.
So this solution gets technology kids like myself excited, but why was it ever developed?
Very simple: Financial Services companies are heavy FAH users, and at the same time they are also steady fans of PeopleSoft Financial Management Solutions.
Putting two and two together:
This Process Integration Pack (PIP), integrates E-Business Suite Financials Accounting Hub with PeopleSoft General Ledger. In reality however, a lot of the integration takes place between E-Business Suite General Ledger and PeopleSoft General Ledger.
The accounting flexfield, calendar, currencies, ledgers all need to be set up in E-Business Suite, and they are simply a mirror image of the PeopleSoft General Ledger setup.
As part of the PIP implementation, the interface between FAH and E-Business Suite General Ledger is disabled. Accounting entries are sent directly from FAH to PeopleSoft General Ledger, with no transactional data (journals) ending up in E-Business Suite General Ledger.
So E-Business Suite General Ledger only acts like an empty shell. The PIP will make sure that both PeopleSoft General Ledger and E-Business Suite General Ledger remain in sync at all times.
When a user creates or updates a chartfield value in PeopleSoft, then this update will instantly be reflected in the corresponding E-Business Suite value set.
A similar real-time synchronization happens for exchange rates and opening/closing of accounting periods.
Therefore FAH knows at all times what the valid financial master data in PeopleSoft is. And it will use this information during its Create Accounting process. From an end-user perspective however, E-Business Suite General Ledger doesn’t exist, and it appears that FAH talks directly to PeopleSoft General Ledger.
As FAH's Accounting Program then builds accounting entries (by making use of the mirrored PeopleSoft chartfield values, exchange rates and accounting period statuses), it will ask PeopleSoft if the produced account combinations comply with the PeopleSoft combo rules - this is the equivalent of E-Business Suite's cross-validation rules.
You might wonder why a different approach is chosen here compared to the chartfields, exchange rates and period statuses synchronization, and why the PeopleSoft combo rules aren't synchronized directly with the E-Business Suite cross-validation rules.
This is because the structures of both rules are too different to synchronize them directly.
So instead, the Accounting Program builds the code combinations, but before committing, it sends the distinct code combinations to PeopleSoft and asks if any of the code combinations do not comply with the PeopleSoft combo rules. PeopleSoft instantly returns the answer to FAH, and the Accounting Program proceeds accordingly. It takes longer for me to write this down, then for the PIP to actually execute this.
The valid accounting entries are then teleported by ODI (Oracle Data Integrator) to PeopleSoft's Journal Generator. This Journal Generator is the PeopleSoft equivalent of E-Business Suite's Journal Import functionality.
Transferring the accounting entries is done through ODI, because it's better suited for bulk data processing, compared to the XML messaging which is used for all the other integration points.
Both combination checking and transferring of valid accounting entries is embedded directly in FAH's Create Accounting program. So the integration with PeopleSoft does not require users to run any additional processes, compared to E-Business Suite's internal FAH to GL interface.
And because all the validations take place within FAH, only valid accounting entries will be presented to PeopleSoft.
Once the accounting entries have been processed by Journal Generator, users can drill down from the PeopleSoft journal into FAH's accounting repository - similar to E-Business Suite's drilldown from General Ledger to FAH.
Lastly, in case a journal is deleted in PeopleSoft, the corresponding FAH accounting entries are reversed, and the FAH event status is updated in order to ensure PeopleSoft and FAH remain in sync.
Besides the functionality which this PIP provides to the customer, it's also just great fun to implement!
That's it for now. In a future post I'll dive deeper in how the PeopleSoft setup maps to E-Business Suite General Ledger.
EDIT: you can find this follow-up post here.
Add a Chart of Accounts value in PeopleSoft, and woosh again... the value now also exists in E-Business Suite.
Add an exchange rate in PeopleSoft, and... you guessed it!
It was the first time I got to see AIA in action, and yes, I was impressed.
Meanwhile it's the third time already that I'm implementing this solution, and the wow factor has disappeared, while I've gotten used to these applications being able to talk to each other, without them needing my help.
So this solution gets technology kids like myself excited, but why was it ever developed?
Very simple: Financial Services companies are heavy FAH users, and at the same time they are also steady fans of PeopleSoft Financial Management Solutions.
Putting two and two together:
This Process Integration Pack (PIP), integrates E-Business Suite Financials Accounting Hub with PeopleSoft General Ledger. In reality however, a lot of the integration takes place between E-Business Suite General Ledger and PeopleSoft General Ledger.
The accounting flexfield, calendar, currencies, ledgers all need to be set up in E-Business Suite, and they are simply a mirror image of the PeopleSoft General Ledger setup.
As part of the PIP implementation, the interface between FAH and E-Business Suite General Ledger is disabled. Accounting entries are sent directly from FAH to PeopleSoft General Ledger, with no transactional data (journals) ending up in E-Business Suite General Ledger.
So E-Business Suite General Ledger only acts like an empty shell. The PIP will make sure that both PeopleSoft General Ledger and E-Business Suite General Ledger remain in sync at all times.
When a user creates or updates a chartfield value in PeopleSoft, then this update will instantly be reflected in the corresponding E-Business Suite value set.
A similar real-time synchronization happens for exchange rates and opening/closing of accounting periods.
Therefore FAH knows at all times what the valid financial master data in PeopleSoft is. And it will use this information during its Create Accounting process. From an end-user perspective however, E-Business Suite General Ledger doesn’t exist, and it appears that FAH talks directly to PeopleSoft General Ledger.
As FAH's Accounting Program then builds accounting entries (by making use of the mirrored PeopleSoft chartfield values, exchange rates and accounting period statuses), it will ask PeopleSoft if the produced account combinations comply with the PeopleSoft combo rules - this is the equivalent of E-Business Suite's cross-validation rules.
You might wonder why a different approach is chosen here compared to the chartfields, exchange rates and period statuses synchronization, and why the PeopleSoft combo rules aren't synchronized directly with the E-Business Suite cross-validation rules.
This is because the structures of both rules are too different to synchronize them directly.
So instead, the Accounting Program builds the code combinations, but before committing, it sends the distinct code combinations to PeopleSoft and asks if any of the code combinations do not comply with the PeopleSoft combo rules. PeopleSoft instantly returns the answer to FAH, and the Accounting Program proceeds accordingly. It takes longer for me to write this down, then for the PIP to actually execute this.
The valid accounting entries are then teleported by ODI (Oracle Data Integrator) to PeopleSoft's Journal Generator. This Journal Generator is the PeopleSoft equivalent of E-Business Suite's Journal Import functionality.
Transferring the accounting entries is done through ODI, because it's better suited for bulk data processing, compared to the XML messaging which is used for all the other integration points.
Both combination checking and transferring of valid accounting entries is embedded directly in FAH's Create Accounting program. So the integration with PeopleSoft does not require users to run any additional processes, compared to E-Business Suite's internal FAH to GL interface.
And because all the validations take place within FAH, only valid accounting entries will be presented to PeopleSoft.
Once the accounting entries have been processed by Journal Generator, users can drill down from the PeopleSoft journal into FAH's accounting repository - similar to E-Business Suite's drilldown from General Ledger to FAH.
Lastly, in case a journal is deleted in PeopleSoft, the corresponding FAH accounting entries are reversed, and the FAH event status is updated in order to ensure PeopleSoft and FAH remain in sync.
Besides the functionality which this PIP provides to the customer, it's also just great fun to implement!
That's it for now. In a future post I'll dive deeper in how the PeopleSoft setup maps to E-Business Suite General Ledger.
EDIT: you can find this follow-up post here.
I would like to thank you for sharing your thoughts and time into the stuff you post!!
ReplyDeleteThanks :-) I appreciate the comment.
ReplyDeleteAppriciate the way you have explained,was of great help.
ReplyDelete