When deploying the FAH to PeopleSoft General Ledger integration, the aim should be to have external feeds to PeopleSoft General Ledger flow via FAH. If not then... there's no point in implementing FAH in the first place.
Just like implementing FAH against E-Business Suite General Ledger serves the purpose of having external feeds to E-Business Suite General Ledger flow via FAH.
There is one difference though:
When using E-Business Suite General Ledger, Subledger Accounting (SLA) connects the E-Business Suite subledgers with the E-Business Suite General Ledger. Hence (as explained in this post) all subledger data (both E-Business and non-E-Business) is flowing through the common XLA framework, towards E-Business Suite General Ledger (XLA = FAH/SLA):
But in the FAH + PeopleSoft General Ledger scenario, the PeopleSoft sub-ledgers continue feeding PeopleSoft General Ledger directly, without any FAH/SLA involvement what-so-ever:
Sure, you could connect the PeopleSoft sub-ledgers through FAH. That would definitely be an entertaining project. But from cost/benefit perspective it wouldn't make much sense.
So when using FAH in combination with PeopleSoft General Ledger, the integration between PeopleSoft sub-ledgers and PeopleSoft General Ledger remains untouched, and the PeopleSoft sub-ledgers continue feeding PeopleSoft General Ledger just like they've always been doing: without FAH.
If you bye-pass FSAH/SLA, will you be able to have all those drill-down features starting from GL ? For me, this seems to be a stop-gap measure from Oracle's side minimizing investment on PeopleSoft applications to make it SLA compliant
ReplyDeleteHi Ajith,
ReplyDeleteYes, there’s the internal drilldown from PeopleSoft General Ledger to PeopleSoft sub-ledgers. This PeopleSoft drilldown is similar to the E-Business Suite drilldown from the pre-SLA area i.e. in E-Business Suite 11i we also went straight from GL into the sub-ledger.
Regards,
Sven