But LJ the table is overview console table only which is a bit complex one and we need to show the incidents aging in it.
On 06-Feb-2018 11:04 PM, "LJ LongWing" <[email protected]> wrote: > It's not too complicated > > 1 - Create a display only field on the form that contains the table field > 2 - Add that column as a column in the table > 3 - Write an AL Guide that loops through the table and does the > calculation needed, and sets the column in the table with the value you > want, looping through all records in the table. > > That's it....it works, I've done it before....the down side is that every > time the table is refreshed, that ALG needs to be called to populate the > table, which is time consuming....to avoid HUGE delays, you need to chunk > the table to a very small number...I would say a chunk of around 50 works > well...anything larger than that makes it take too much time to populate > the display only field on refresh. > > On Tue, Feb 6, 2018 at 11:52 AM, Abhi$hek <[email protected]> wrote: > >> Can you please provide detail on how to achieve it and show the aging in >> the overview console table . >> >> On 06-Feb-2018 10:49 PM, "Dave Shellman" <[email protected]> wrote: >> >>> If you need to make the calculation and it needs to be current, the only >>> logical trigger is with the table refresh. >>> >>> Dave >>> >>> On Tue, Feb 6, 2018 at 1:29 PM Abhi$hek <[email protected]> wrote: >>> >>>> We can consider simple hours as well. >>>> >>>> On 06-Feb-2018 10:02 PM, "Dave Shellman" <[email protected]> wrote: >>>> >>>>> Sort on Submit Date/Time will rank the records which is used in the >>>>> aging calculation. >>>>> >>>>> Should the aging calculation use business time or simple hours open? >>>>> If business time then holidays would need to be considered which leads to >>>>> regional holidays in a global environment. >>>>> >>>>> Dave >>>>> >>>>> On Tue, Feb 6, 2018 at 12:44 PM Jason Miller <[email protected]> >>>>> wrote: >>>>> >>>>>> Once case where you can see drastically different out of order Case >>>>>> ID's in a server group is if Incident(s) are created on a non-user facing >>>>>> admin server that has been up for a while (months). An example is UDM is >>>>>> used to create a bunch of request for a project and the admin server is >>>>>> used for the load. I ran across this a while ago and scratched my head >>>>>> for >>>>>> a few minutes until I realized they were created on a admin server that >>>>>> had >>>>>> been up for a while, that server rarely submits and Incident. >>>>>> >>>>>> That is edge use case but an example of how Case ID isn't a great >>>>>> option for time sensitive matters. >>>>>> >>>>>> >>>>>> Jason >>>>>> >>>>>> On Tue, Feb 6, 2018 at 4:21 AM, JD Hood <[email protected]> wrote: >>>>>> >>>>>>> Hi AA, >>>>>>> >>>>>>> Presuming I understand correctly and the main point of the business >>>>>>> requirement is to just prioritize the aged incidents first in the >>>>>>> Incident table on the overview console, then couldn't you just sort the >>>>>>> table by Incident Number? Granted with blocks of ID's and a high ticket >>>>>>> flow it is possible that a higher INC# could have a submit date slightly >>>>>>> before a lower INC#, but I would think they would be created so close >>>>>>> together that it would not be a significant difference. Or where there >>>>>>> may >>>>>>> be a bigger difference would be the rare case, if ever. Again, this is >>>>>>> if I >>>>>>> understand correctly (and I'm not 100% sure) and the business need >>>>>>> is actually just to present the tickets sorted by oldest first in the >>>>>>> table. >>>>>>> >>>>>>> So, just to be clear, disregard specific design ideas or workflow >>>>>>> specifics. There are usually different ways to meet a requirement with >>>>>>> ARS, >>>>>>> so first things first: >>>>>>> What is the business need here, or if it's easier, what problem is >>>>>>> the business is trying to solve? Something like: >>>>>>> >>>>>>> "...We're missing SLA's more often than we are meeting them because >>>>>>> support staff won't work older tickets before newer tickets. Is there >>>>>>> some >>>>>>> way Remedy can help the support staff work tickets in the order of >>>>>>> oldest >>>>>>> to newest so we have a better chance to stop missing SLA's?..." >>>>>>> >>>>>>> If the problem to be solved is as simple as that, the solution could >>>>>>> be more workflow/functionality, or perhaps just a bit of training. You'd >>>>>>> probably get more "bang for the buck" with training in that case. >>>>>>> >>>>>>> Thanks, >>>>>>> -JDHood >>>>>>> >>>>>>> On Tue, Feb 6, 2018 at 2:06 AM, Abhishek2019 <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> >>>>>>>> Thanks for your kind response. >>>>>>>> >>>>>>>> As the requirement is to show the Incident Aging in overview >>>>>>>> console table >>>>>>>> only so i doubt DB View will not suffice it. Also please could you >>>>>>>> elaborate >>>>>>>> it more as what will be the trigger point(Execute on condition) for >>>>>>>> the >>>>>>>> Custom field calculation on the DB view. >>>>>>>> >>>>>>>> Please provide detail for your DB view approach. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> AA >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Sent from: http://ars-action-request-system.1.n7.nabble.com/ >>>>>>>> -- >>>>>>>> ARSList mailing list >>>>>>>> [email protected] >>>>>>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ARSList mailing list >>>>>>> [email protected] >>>>>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>>>>> >>>>>>> >>>>>> -- >>>>>> ARSList mailing list >>>>>> [email protected] >>>>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>>>> >>>>> >>>>> -- >>>>> ARSList mailing list >>>>> [email protected] >>>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>>> >>>>> -- >>>> ARSList mailing list >>>> [email protected] >>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>> >>> >>> -- >>> ARSList mailing list >>> [email protected] >>> https://mailman.rrr.se/cgi/listinfo/arslist >>> >>> >> -- >> ARSList mailing list >> [email protected] >> https://mailman.rrr.se/cgi/listinfo/arslist >> >> > > -- > ARSList mailing list > [email protected] > https://mailman.rrr.se/cgi/listinfo/arslist > >
-- ARSList mailing list [email protected] https://mailman.rrr.se/cgi/listinfo/arslist
