Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support more n-to-date options #262

Open
sbidoul opened this issue Feb 25, 2020 · 2 comments
Open

Support more n-to-date options #262

sbidoul opened this issue Feb 25, 2020 · 2 comments
Labels
enhancement no stale Use this label to prevent the automated stale action from closing this PR/Issue.

Comments

@sbidoul
Copy link
Member

sbidoul commented Feb 25, 2020

We currently support Year-To-Date, which is from 1/1 of the year of the selected period until the last day of the selected period.

There is demand for more options: Month-To-Date, Fiscal Year-To-Date, etc.

So maybe we should generalize the ytd flag with some sort of start period? Not sure about the best UI.

@svalaeys
Copy link

svalaeys commented Mar 8, 2020

For consistency's sake, I propose that both start date and end date be configured in the same way, independently from one another, with the following two options:

  • A determined date, possibly adjusted
  • The pivot date, possibly adjusted

I recently needed Fiscal-Year-To-Date periods. I went back and forth for a while about transforming the ytd_flag to a selection field that would allow the user to choose between calendar year-to-date and fiscal year-to-date. In the end, I couldn't think of a single use-case where some company which had a fiscal year that did not overlap with calendar year would also need dynamic date handling for a calendar year, or, at least, a use-case strong enough that would be worth complicating the UI.

I did however notice that I would eventually run into issues the day I would consolidate data between companies that didn't have the same fiscal year dates. We could of course have a dropdown to let the user choose the company fiscal year to consider, but it seems like again it would be complicating the UI. At the end of the day, the user knows which date he's looking for.

In my particular case, I was trying to configure a report so that the dates of its ten columns would adjust based only on the pivot date. Simplifying, columns where of two types : realized from fiscal year start to pivot date, and budget columns from pivot date + 1 to fiscal year end. So far, I have not found out how to do the second part with the current setup.

With my proposal, the configuration for the report I just described would therefore end up as follows, with real dates to simplify the example:

Column type 1
Source: Realized
Date From: Determined, 01/05/2029, not adjusted
Date To: Pivot Date, not adjusted

Column type 2:
Source: Budget
Date From: Pivot Date, Adjusted +1 Day, Offset 0
Date To : Determined, 30.04.2020, not adjusted

Every month, solely changing the pivot date would take care of everything.

I don't know if my train of thought has covered all the possible scenarios, but to me it seems like the most consistent and simple UI to cover all the cases.

@github-actions
Copy link

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

@github-actions github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Feb 20, 2022
@sbidoul sbidoul added no stale Use this label to prevent the automated stale action from closing this PR/Issue. and removed stale PR/Issue without recent activity, it'll be soon closed automatically. labels Feb 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement no stale Use this label to prevent the automated stale action from closing this PR/Issue.
Projects
None yet
Development

No branches or pull requests

2 participants