More Date Functionality - Historical Data and Reporting

  • 3
  • Idea
  • Updated 3 months ago
  • Under Consideration
Hi All,


I have been looking through a number of posts using "Date range" and "Historical Information" as my search filters. I have located 3 posts that are requesting that additional date functionality be added to Replicon. There may be more, and I intend to track down as many as possible and continue to update this post

https://community.replicon.com/replicon/topics/historical-department-info
https://community.replicon.com/replicon/topics/storing-historical-data-for-employee-type-and-departm...
https://community.replicon.com/replicon/topics/add-effective-date-capabilities-to-custom-fields-in-u...

At a quick count, there seems to be 8 total customers across these three posts who require this functionality.

There have been two main responses to this issue

1) We have been told to use a user defined field upon the date change. 
To my knowledge of how reports work in Replicon, each new field would be in a separate column rather than overriding the old data. Using department as an example:
Resource department is set to "Dept1". Then on the 1/01/2017 they move departments to "Dept2". The work around suggested by the moderators would generate two columns, one with Dept1 and one with Dept2. This creates issues when importing into excel and attempting pivot tables etc. In addition, when this happen with “dept3” “Dept4” etc, which will invariably happen over time, we would need to add a second field to store the date the change occurred.

This workaround may work for only one change, but as more changes occur to more fields (perhaps Cost Centre, Location, Billing Rate etc) the reports would grow to an enormous size.


2) "This is not planned currently."
It is puzzling to see this response, as there are already fields that do use date ranges to control their values (supervisor and cost as examples).
Moreover this answer doesn't really assist in the issue we face. At minimum, a workaround that mitigates the issue should be suggested and for a problem that multiple customers have brought forth, an explanation as to why it is not being considered should be provided.

I am confident there are reasons for the above, but given that number of customers who are requesting this I am hoping that there will be a detailed response to this issue. Im am happy to share this response with those in the other threads.

Photo of Tsakis, Deon

Tsakis, Deon

  • 21 Posts
  • 0 Reply Likes
  • concerned

Posted 1 year ago

  • 3
Photo of Aashnee Kamboj

Aashnee Kamboj, Community Moderator

  • 1444 Posts
  • 103 Reply Likes
Hi Deon,

Thank you for using the Replicon Community! 

We do realize the importance of including a feature on Replicon, however, there can be other priorities that we may have been lined up with, concerning which we may not be able to conclude all the ideas input here.

Thank you for taking the time out to put together all the posts pointing to a similar issue. This will indeed help me in explaining my product management team in a much better way on how this feature can provide additional functionalities.

I will keep the thread updated in case of any progress.

Regards,
Aashnee Kamboj
Photo of Tsakis, Deon

Tsakis, Deon

  • 21 Posts
  • 0 Reply Likes
Hi Aashnee,

Thank you for taking the time to respond, just have a few more queries in regards to this

How exactly do longer term customers track data now? From our own experience using Replicon for almost a year, it has been incredibly difficult to run older reports (i.e reports looking at 3-months or more worth of data) due to Replicon's inability show historical information. Does Replicon have an expectation that their Users run reports month to month and combine them rather than running reports over large periods of time? If not, what exactly is the suggested work around?

In regards to the broader issue of idea implementation, there doesn't seem to be many ideas that actually make it into production, most being flagged as "Not Planned". This raises a few questions: How many of these customer posts actually make it to the product management team? How many are considered? What criteria is an idea weighed on? If the idea does get knocked back, why is the User not informed of the reasoning behind the rejection? The last in particular would help prevent double postings as users can find logic on why something cannot be done.

All in all, the ideas/queries section has been quite a disheartening experience. For smaller issues regarding customization that already exists the response is quick and descriptive. Any query/idea/suggestion that doesn't currently exist sees the exact opposite response however, often garnering one response with no attempt at follow up communication or assistance in solving the issue created by a feature lacking.

As a customer, its strange to see a forum where we are encouraged to share our experiences and suggestions for improvements only to have our voices ignored.
Photo of Aashnee Kamboj

Aashnee Kamboj, Community Moderator

  • 1444 Posts
  • 103 Reply Likes
Hi Deon,

I would like to look through the issues you are facing in running reports for historical data. Ideally you should be able to capture the historical data through reports without any issues and concerns.

To answer the next part of your question, we would like to tell you that all the ideas/suggestions reach our product management team without fail. Like we said, there can already be planned things up in the list that need to be implemented. Having said that, marking an Idea/ Suggestion as not planned does not mean that we will not consider it ever. All we specify by marking them as not planned is that we don't have plans to work on the idea/suggestion immediately and will consider it in later time. 

The reason why we cannot specify a time line or may sometimes not be able to stick to one is because developing and implementing a solution/Idea/feature requires a series of designing/configuration/testing. We continue to believe that this forum is primarily for all our users to help us make Replicon a more intuitive application, we do have a list of all the ideas and suggestions reported on community and assure you that they will be looked upon based on the feasibility. 

In case there exists a feature that cannot be implemented in the product we do make sure that we reply to the same by specifying the reason why it can never make it up to our list of Ideas.

Thanks,
Aashnee
Photo of Tsakis, Deon

Tsakis, Deon

  • 21 Posts
  • 0 Reply Likes
Hi Aashnee,


Thank you for the detailed response, that does indeed clear things up a fair bit. My apologies I did not intend to come across as a skeptic, I can appreciate the time it takes to configure, test and design new functions and capabilities and how it can be pushed back based on what the current company roadmap looks like.

In regards to the first point around historical data, the issue seems to be that some fields of data will cease to exist when updated. Things like billing rate, department, location, cost centre, role etc are all fields that can and do change over periods of time which Replicon does not track older versions of, as the supervisor and cost fields do. This means that when running reports out of Replicon those fields only show the most recent data, and any transformations that rely on that information will only show most current data. This causes issues when attempting to analyze data in excess of 6 months.

Your suggested fix in other threads has been to create a custom field on the user profile to hold the newer information while leaving the older field with its original information. As a hypothetical situation, if a resource changes roles and departments three times we would have to create 4 new custom fields and add them to all existing reports, while changing any excel spreadsheets that rely on those reports to work each time a new field is created. That is a fair amount of work on the user-end and will be rife with errors over time.

The only other fix that has occurred to us, and the one we are currently using, is to run all our reports once per month and continue to add them together to create larger reports. . If a few months down the line we end up changing two or three columns in the reports, we then have to bring the older reports into the new format manually. This is a very clunky method, and does not respond well to any potential changes in reporting requirements over time.

The best method would be to add date ranges to custom fields, as was suggested in the third thread linked in the original post. Similar to the supervisor or cost fields, setting an initial value and then an effective date of when it will change (as supervisor/cost fields currently do) is a much smoother method or tracking this over time, is easier to change and keep updated from a user perspective and ultimately helps streamline reporting processes.

As stated, if this is not on Replicon's road map for the foreseeable future (12 to 18 months) that is okay, we will need assistance in figuring out a workaround that does not involve constant validation/maintenance/updating of data/reports/spreadsheets.


Thank you for your quick and detailed responses, I look forward to hearing from you again


Regards,

Deon



Photo of Aashnee Kamboj

Aashnee Kamboj, Community Moderator

  • 1444 Posts
  • 103 Reply Likes
Hi Deon,

Thank you for describing the issue in detail. I have put this forward to our Product Management team and will update the thread in case of any progress.

Thanks,
Aashnee
Photo of Richard

Richard, Design Team Manager

  • 63 Posts
  • 7 Reply Likes
From reading this I am contused about where it mentions that Cost Centers, Divisions, Locations, and Service Centers do not support historical assignments.  Department and Employee Type do not support historical assignments, but our groups (Cost Centers, Divisions, Locations, and Service Centers) are built to replace them and address many of the longstanding issues like lack of historical assignments.  



These historical assignments have been supported by groups from when they were first introduced.  The big limitation for them was that we had not rolled them out across the app, but with the recent addition of group support to projects, they should now be usable by the majority of our customers.  Are there other issues which are preventing groups from being used for historical assignments?


Billing rates on projects likewise have always supported a history of rates, I am curious to better understand the limitations being encountered here.  The billing system is an area we are currently upgrading, so it would be good understand any limitations being encountered there.