Using Financials Accounting Hub for GL data conversions

No, I'm not saying that you should consider licencing FAH for the sole purpose of a one-time data conversion exercise. Not-at-all. I simply wanted to avoid labeling this article as another example of a FAH implementation. But truth be told, this article is... another example of a FAH implementation, be it a somewhat interesting one :-)

This Financial Services company has systems for penions, insurances, payroll, and cash desks. These systems connect to the accounting application through an importer module which exists next to the accounting modules (similar to what we call AR, AP, GL, etc). Lastly there's a module embedded within the accounting system that deals with securities.

They were moving to PeopleSoft Financials, so in order to connect the source systems, we deployed FAH, and the FAH-to-PeopleSoft GL Integration Pack.

The source systems are now all connected to FAH, and so is the legacy accounting system. That was done because we needed to interface the data from the embedded securities system towards PeopleSoft General Ledger. We could have connected this securities system directly to FAH, by using an event based accounting approach, but at the time of implementation the customer already knew that the securities system would soon become obsolete and be replaced altogether.

So instead of an event based accounting approach, we simply connected the legacy accounting system to FAH, and used the journal pass-through approach to transform the continuous flow of securities-related journals from the legacy accounting system, onto PeopleSoft General Ledger.

This was not only a quick and easy solution to connect this soon-to-disappear securities system, but by doing this, we had instantly also covered all needs for the GL data conversion:

• mapping the old chart of accounts to the PeopleSoft chart of accounts was taken care of by FAH mapping sets, 
• passing the data trough FAH also meant it was instantly validated against the PeopleSoft GL setup,
• and the bi-directional drilldown between PeopleSoft, FAH and the legacy accounting system covered the audit requirements.

At the same time we had now also created a welcomed comfort cushion for the implementation as a whole, because we could go live with PeopleSoft GL and FAH, while still keep on using the legacy system for receivables, payables, cash management, etc. until the respective PeopleSoft modules were ready to go and take over those tasks.

Once the PeopleSoft modules had replaced the legacy submodules, and once the securities system was removed, then the legacy accounting system could be switched off in its entirety. Due to the journal pass-through connection between FAH and the legacy accounting system, this could all be done entirely at the pace the customer felt most comfortable with.

You might notice the similarity with the incremental implementation approach article, and yes the overall message is indeed alike: by first creating a journal pass-through connection between the core legacy accounting system and FAH, you can make life a lot easier.

But if we had applied that incremental approach to this implementation, then we would have first gone live with simply a connection between the legacy accounting system and FAH, and we would have left the source systems initially connected to the legacy accounting system. Such approach would look like this:

That level of comfort was not required in this case though, as we were fully ready to connect the source systems directly to FAH. But it's always good to have such backup scenario in place.