It’s tempting. Your third-party accounting entry interface to PeopleSoft GL is almost perfect. You designed it by the numbers:
- Clone the JGEN_ACCT_ENTRY record
- Create a new Accounting Entry Template and Journal Generator Definition
- Integrate the data into the new table (via message or app engine or SQR or other)
And then things got less perfect and more “almost”. Because testing revealed a potential issue; your third party application does not balance by business unit. It wants to. It would. But it doesn’t know how. The files it produces are in balance, but it doesn’t implement the concept of a balancing field like business unit. Nor will it any time soon.
After some negotiations with the third-party developers, it’s clear that you’ll have to invoke this logic on the PeopleSoft side. That, or load unbalanced journals. And this is where it gets tempting. The logic to balance by business unit isn’t terribly difficult. Why not simply code it into your import program?
Resist the temptation. Not only will the logic be at least a bit harder than it seems (isn’t it always?), the work has already been done. Oracle did it. It’s the Centralized Interunit Processor – the same one the delivered modules use. Simply designate an anchor business unit for each transaction, initialize some variables (PeopleBooks tells you which ones), and call the MAIN section of application engine process IU_PROCESSOR.
Not only will you have implemented Interunit balancing with less code than if you’d done it on it your own, you’ll have a flexible solution. The Centralized Interunit Processor is pure PeopleSoft. That means it respects your configuration and future-proofs you if the business changes from using an Interunit template to using mutually-defined accounting rules such as Interunit pairs. All without having to go back and change code. And isn’t that a big reason to implement ERP in the first place?