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 <abhi.masc...@gmail.com> 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" <adshell...@gmail.com> 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 <abhi.masc...@gmail.com> wrote: >> >>> We can consider simple hours as well. >>> >>> On 06-Feb-2018 10:02 PM, "Dave Shellman" <adshell...@gmail.com> 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 <jason.mil...@gmail.com> >>>> 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 <hood...@gmail.com> 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 <abhi.masc...@gmail.com> >>>>>> 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 >>>>>>> ARSList@arslist.org >>>>>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ARSList mailing list >>>>>> ARSList@arslist.org >>>>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>>>> >>>>>> >>>>> -- >>>>> ARSList mailing list >>>>> ARSList@arslist.org >>>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>>> >>>> >>>> -- >>>> ARSList mailing list >>>> ARSList@arslist.org >>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>> >>>> -- >>> ARSList mailing list >>> ARSList@arslist.org >>> https://mailman.rrr.se/cgi/listinfo/arslist >>> >> >> -- >> ARSList mailing list >> ARSList@arslist.org >> https://mailman.rrr.se/cgi/listinfo/arslist >> >> > -- > ARSList mailing list > ARSList@arslist.org > https://mailman.rrr.se/cgi/listinfo/arslist > >
-- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
