13 Period time dimension vs UD

[GorkemSenol]

Hello everyone,

We have a client that uses 13 period time dimension in their current system that we are moving to onestream at the moment. They use period 13 to load TB' post adjustments even input disclosures  currently.

We first wanted to use a UD dimension to capture it but I'm more and more leaning towards having custom 13 period time dimension to cater that. 

I know that is something that needs to be set up during application creation so I'm guessing we need a new application. Is that something to be requested from OneStream to set up?

I also would love to hear if any of you had a similar case and how you handled it. 

[MikeG]

Hi @GorkemSenol if you go that route of a new application, step 1 is to go to the System tab > Time Dimensions and create a new Custom Time Dimension and you would specify that Q4 has 4 months.

That will give you the XML needed when you create the Application.  If Cash Flow and FX translation is needed on the data in Period 13 then that would be a solid use case for Period 13.  You could however, use the Flow dimension for tracking the YE adjustment type and put it in Period 12.  I would firstly investigate using Flow for tracking the type of adjustments before heading down the route of creating a new application.

Hope this helps.

[GorkemSenol]

Hi Mike,

Thanks for explaining. Do you have experiences working with 13 period time dimension? Does it create any problems for view dimension for example. Because you know you have that member Trailing12Months, is there going to be a Trailing13Months member created automatically?

Also the aggregation of time dimensions, when the user selects a year total the YTD data for P13 will be shown right?

[MikeG]

V#YTD will automatically work with a P13 Time Profile, because it is same Year.  There will NOT be a V#Trailing13MonthTotal that gets created.

If it were me I would not rebuild the application.  It sounds like your business case is simply to enter Year End adjustments.  You could accomplish this using the Flow dimension and a Data Entry Form that only is WF eligible in Period 12.  So that YE Form will not appear as a valid WF task in Periods 1-11.

The best use case for a Period 13 application is if you must/need to do Cash Flow and FX in that Period.  If the business simply needs to enter a plug or adjustment - create a member F#YE_Adj and promote that to a Form for manual input in Period 13 only in a WF.  The CV Row/Col in that Form could be something like V#YTD:F#YE_Adj:Name(Period 13 Adj), but your base Time would be T#|WFYear|M12.

Hope this helps.

[Nattaya]

Hi Mike,

We have a similar case with our company, where there is a P13 in Oracle and we need to perform a year end adj in OneStream as well, if we wanted to go with the flow option with the data form.  How can that be set up?

[JackLacava]

You could do it two ways:

• Have an app with a custom Time dimension, as described above, or:
• Have an app with the traditional Time, but with Scenarios set to work on a 13-period range.

There are trade-offs in complexity for each approach, choice will likely come down to personal preference of implementors.

[GorkemSenol]

Hi @JackLacava 

Are you talking about the setting below 'Number of No Input Periods Per Workflow Unit'?

Can you let me know how that works?

[JackLacava]

You don't need noinput periods. Just look up the "Range" Tracking Frequency. For example, this configuration allows you to enter monthly-level data for 13 periods.

[GorkemSenol]

I see, but then 13th period is 2024M1 which is needed for January data for next year. Still interesting.

Thank