Dynamic Inserts – always, sometimes or never?

Okay – so I used to be in the camp of “Always dynamic insert, no questions asked”. I’ve mellowed in my old age… okay – I admit it – the clients have convinced me that sometimes the cross-validation rules just can’t be defined well enough to stop rubbish combinations occuring (especially when their chart of accounts hasn’t even got a passing acquaintence with ranging values) and that for some organisations it’s just a better business fit to turn dynamic inserts off after the conversion load and just wear that ‘bedding down’ pain…. anyone with me here? Or am I alone in the wilderness? 🙂

8 thoughts on “Dynamic Inserts – always, sometimes or never?

  1. It depends how many new combinations you need to create and how easy it is to create those new combinations. At one particular client we decided to turn it off and had to come up with a workaround for creating new combinations since on an annual basis they would create quite a few combinations. Workaround was to upload an ADI spreadsheet journal which had zero values but the appropriate combinations and then in the system delete the imported journal. This would ensure population of the account code combinations table with the new combinations required.

  2. Anonymous

    I worked in accounting at three smaller (< 250 employees) Oracle Financials sites and we eventually turned off dynamic insertion at all three sites. With all three companies, there was one person who was willing to take the time to verify an new code combination was needed. At the company I worked the longest, I shared an office with the budget manager who was the one who created the new code combinations. About half of the new combinations were unanticipated expenses and about half was some manager making crap up. If you want to be able to do accurate reporting, you really need to check "outlier" new code combinations. I found cross-validation rules to be more trouble than they are worth because you can’t anticipate all possible scenarios. For example, we had at my first company project number as a segment in the code combination and we created some cross-validation rules based upon the idea that asset and liability accounts would never be project specific. One day, we had a project where we the lead contractor and the client sent us a bunch of money to pay the other contractors with when they finished their sub-projects. When we tried to assign the unspent cash to the project, we got snagged by the cross-validation rules. People were constantly wanting to know the progress of spending out the cash and what should have been easy analysis took quite a bit of work.

  3. Anonymous

    What about clients who utilise their account combinations to track product versions and types and require new combinations to be created on the fly. How do you get around not using dynamic inserts?

    Create a new combination each time a new version / product is produced? That will become onerous in a software environment.

  4. Anonymous

    I have done what Richard Byrom did but when I come to post a journal with any of the new combinations in it just hangs and finally errors.

  5. Anonymous

    I am presently doing what Richard Byrom did, i.e. uploading with ADI to get lots of new combinations, but when I come to post a journal with one of these new, dynamically inserted combinations the posting request just hangs and finally errors. Any idea why? Is it a patch issue?

  6. The new combinations get created in GL_CODE_COMBINATIONS during Journal Import so they should be there, if the journal post is erroring you’ll need to check the specific error message in the log file and log with OWWS, if the Journal Post program completes sucessfully but the journal itself fails check the output file and see what the error code is – it’s probably that one of the segment values is no longer active or something?

  7. Anonymous

    Anything that comes out of the mouth of a Red Rock consultant, you should take with a pinch of salt. They’re as bad as Indian offshore development!

  8. Nice. Thanks for that – the first time I've been flamed! Lovely. Next time leave your name, clown. In the meantime, I repeat – this blog is my personal opinion and does not every in any way represent the view of my employer (or anyone else for that matter).

Leave a Reply

Your email address will not be published. Required fields are marked *