Would like an additional field on the job details screen for 'Comments' or 'Description' for the job that could then be pulled onto the grid. We have many use cases for the need that helps to quickly identify jobs/returns from a pool. Right now, our users are appending the job name with these various comments/descriptions and it looks very messy.
7 comments
-
Stephanie Hartje Agree. This was available in XCM and it was very helpful for our team.
-
Tiffany Roussel The field could also be rolled over in XCM which would be helpful in PE as well. The job name resets and our users appending the name think it will stick for next year but it will not.
-
Brad Podzius Hi Tiffany,
Can you provide a few examples please?
Just trying to understand the use case.
Thanks!
Brad
-
Michelle Harris Would using the Job Class help for identification purposes?
-
Tiffany Roussel That could work for the standard/frequent items. Examples of these are below which help preparers/reviewers quickly identify returns that should/should not pull from a pool.
- CHANGE OWNER (Change in Ownership)
- CLOSE BOOKS (Election to Close Books)
- FINAL
- 3115
- INITIAL (Business Began, not became a client)
- STATE (State return other than our usual IA, IL, WI)
- INSTALLMENT
- FINAL
- FOREIGN (Foreign Earned Income)
- GROUPING
- IA CAP GAIN (Iowa Capital Gains)
- MINISTER
- PART-YEAR
- NOL (Net Operating Loss)
The benefit is someone can quickly see the comment from a grid without having to dive into the notes. We have issues where a preparer may pull a return they shouldn't, then place it back to a pool, losing its "First In First Out Order". These descriptions help that.
Although, there are some instances where a free form text field would be needed. Most are to prioritize, not prioritize or provide a brief description pertaining to the status of the return.
An example would be perhaps we're holding the return for something (a form that's not available, the business return to be complete) or the return needs to be prioritized/rushed and a quick date is dropped in so someone knows the client is coming in on X day....
We have found workarounds for most of these scenarios and appending the job name does work. It just creates a cluttering look and like I said, does not retain if for some reason we'd like it to each year.
-
Brad Podzius Ahh... so for example, a 1040 might be in a pool, but it has an Installment Sale or NOL that makes it a bit more complex, therefore requiring someone with a bit more experience to handle?
You are correct in that the Job Name should ALWAYS revert to the Job Template Name for consistency, but I think with all of these possible variations, using a finite list is not efficient and could require open text.
That said, I believe that the Department should classify these into a few Job Complexity levels and have staff only take the Complexity they qualify for. Internal Due Dates (Finish Deadline on Dates panel) would be used for FIFO priority exceptions and "on Hold" workflow status with a Job Note would identify reasons to wait on a particular job.
Does this help?
Brad
-
Tiffany Roussel I certainly agree with you and we do use the complexity levels, internal due dates panel and workflow statuses that are encompassing of holding or waiting on information. Using what the system offers first is our preference and helps standardization. Even with this, we still hit situations where we need to drop in a quick note that can be seen from a grid.
The system isn't preventing us from tracking what we need by any means, just asking for a feature enhancement to provide us with a free-form text custom field that could pull on a grid. It's a wish-list items that our users miss.
Another thought, because we aren't able to lock down the editing of job name, our users will continue to edit it without the option of another spot.
I am good with things now, just would live Dev to keep in mind for the future.