In a few recent EPM Cloud Planning implementations I have had the ability to control the format of the data load files and all of them have required some form on multi-period loads (multiple months and/or multiple years). I generally like using Data Management as I have used it enough where I can set it up quickly and it gives me the ability to map should I need it. Yes, it is slow on large data loads, but for smaller – medium loads it does provide a lot of benefit. For those larger loads I typically am automating metadata builds so I just run it via an essbase load. But I digress…
Previously I had always just set multi-period loads up with the year in one column and the period in another. Then you have to setup a custom calendar and refer all your data imports to it etc. It can be a hassle down the road, especially when trying to troubleshoot why a load isn’t working all of a sudden.
As I controlled the format of the file, I was recently testing new ways to load and I stumbled across a better way to load multi-periods. Not sure if this was just common knowledge and I had no idea, but this has simplified my load processes greatly.
Just have a column with the DM period in it (usually something like “Jan-20”).
Typically if you control of the format (or can request an update) this is usually pretty simple to build as a column (i.e. MS SQL is FORMAT(<Date Column>,’MMM-yy’)).
Then in your import format add a Source Period Row (Period) and refer to the correct column
Works like a charm, as long as you specify in your Load Rule the correct period range you are loading (Start / End Period), the record will load to the correct Data management period. Also if a record is NOT in your period range you specified it will throw an import kickout of “INVALID_PERIOD” — this is not treated as an error so your process won’t fail. You can argue both sides whether it should or not, but I prefer it not to fail.
Hope this helps someone out there!