What are table fields useful for?

Discuss your general Proclaim related queries here.
Tardisgx
Posts: 30
Joined: Wed Jun 19, 2019 10:35 am
Has thanked: 10 times
Been thanked: 1 time

What are table fields useful for?

Post by Tardisgx »

My work's database maintenance does not have any Table fields so I don't use them.

I've tried to read the manuals I have (highest tech level 2 i think) but I still don't understand what a table field is, why its useful or how even that field would appear if i selected it in report creation.

Can someone explain why/ how they use table fields.

revellbikes
Posts: 488
Joined: Fri Jun 15, 2012 12:44 pm
Has thanked: 16 times
Been thanked: 51 times

Re: What are table fields useful for?

Post by revellbikes »

They're used to stored repeated information.

For example all disbursements on a case. Traditionally these were added into singular repeated fields and you were forever adding additional ones.

Tables mean you can have effectively and indefinite number of repeated values within one table.

You can also do the same for correspondents. So if there are multiple hospitals that have been attended then they are simply added into one table rather than having hospital screens 1-253

Tardisgx
Posts: 30
Joined: Wed Jun 19, 2019 10:35 am
Has thanked: 10 times
Been thanked: 1 time

Re: What are table fields useful for?

Post by Tardisgx »

revellbikes wrote:
Sat Aug 21, 2021 7:33 am
They're used to stored repeated information.
Right so case "ABC" has a table field "hospital and fees" 2 Columns, Hospital name and fee with all that info vertically showing.

Is that the type of tables we're talking about or is it a table with row names and column headers with numbers inbetween like a pivot table in excel.

revellbikes
Posts: 488
Joined: Fri Jun 15, 2012 12:44 pm
Has thanked: 16 times
Been thanked: 51 times

Re: What are table fields useful for?

Post by revellbikes »

There's no in built Row names like a pivot table. You specify your columns as fields in the DB.

You could of course label each row in the first column something specific using code if you wanted to. For example a count of each row added or group together certain rows. The world really is your oyster

steve
Posts: 470
Joined: Wed Nov 30, 2011 10:20 pm
Been thanked: 120 times

Re: What are table fields useful for?

Post by steve »

What casetype / industry area(s) do you work in? (e.g. PI/Conveyancing)
We could probably give you some examples use scenarios where tables come in handy

Tardisgx
Posts: 30
Joined: Wed Jun 19, 2019 10:35 am
Has thanked: 10 times
Been thanked: 1 time

Re: What are table fields useful for?

Post by Tardisgx »

steve wrote:
Wed Aug 25, 2021 1:19 pm
What casetype / industry area(s) do you work in? (e.g. PI/Conveyancing)
We could probably give you some examples use scenarios where tables come in handy
Yeah I had to google what a disbursement is haha.

Accident Claims handling so PIs, Fault, non fault accident and 50 other claim types under 1 case type.

We have a solicitor 1 and 2 page we don't 3rd chance a case.

Medical payments just have payment 1 and date 1 and payment 2 date 2 with a bunch of logic if the 1st is not blank and not identical to what you are trying to import put it in 2nd field.

These are the closest repeatable info I can think of but cannot actual think of a use for table, also ive not written a linked action for one, can they display on a screen or its just for reporting or not.

I saw an interesting post here talk about populating a table with audited information so everytime a field was changed it would first put that previous entry and date of change into a table. I think that would be cool viewtopic.php?t=767

Archais
Posts: 14
Joined: Wed Jul 31, 2019 2:15 pm
Location: West Yorkshire

Re: What are table fields useful for?

Post by Archais »

PI has a number of uses for tables:

Costs/Disbursements on a case
Court directions (why have 10-15 fields saying that this thing must be completed by this date when you could have an almost infinitely expandable table)
Correspondent details (where you have multiple correspondents of the same type you could create a table to hold all correspondents of that type - experts, witnesses, other drivers in the case of RTA) along with information that relates to each one (expert field, other driver registration) - note that (as of 3.3, not sure whether it's fixed in 3.4 or later as we've yet to try it) EDS to table correspondents did not work. Not a major issue if you can use maths to imitate the behaviour of EDS.


A table can be (and quite frequently is) shown on a screen - linked actions for tables can be allocated to one of the buttons (should automatically create in WFM when the table is created in DBM) or can be put onto a screen button if the other buttons are to be disabled (view only table) table entries can be either selected by a user or using a linked action (useful if you're wanting to reference something specific in a following document - a particular medical examination by an expert on a date)

Tables can be filtered within a linked action to only show results that meet a certain criteria, the results can then be referenced in a document produced by the same (or a following) linked action (eg billing - if you're raising a bill to company abc you wouldn't want costs that relate to company xyz to appear on that bill) - you'd then likely want to do something in the after-maths of that document to amend those entries to tick an option that says they have been billed, maybe fill in a field with the invoice/bill number, so that (providing you filter it properly) they won't then appear in the next bill to that company.

I should state at this point that documents that have table controls (particularly selection/filtering) on the before-maths will override anything that a user has done to that table - if someone wants line 6 from a table to print, but the document has a TABLEFIRST command in it, line 1 will print instead.

Your "Medical Payments" could benefit from being in a table if there is a large number of expected entries - rather than having a bunch of maths that checks each individual field, you could store the payment value and date as variables or in a temporary holding field, check that the table doesn't contain an identical record through a filter (TABLESELECT) and if it doesn't then create a new entry.

Some table commands need to be held as a variable/result before they can be used - when a table control is entered into maths, these ones will always start with "result = "*tablecommand*

It's not advisable to put a maths item that interacts with a table (particularly the TABLENEXT, TABLEPREVIOUS, TABLEAMEND, TABLERESET, TABLECLEAR, TABLEFIRST, and TABLELAST to name a few) on a screen as that will cause the table command to keep happening whenever the maths refreshes (new field is selected or tabbed out of/into, or the screen is entered)

I'm sure there are many more instances where a table would benefit your system, as well as the many potential pitfalls to look out for, but it's 2am and my ability to come up with possible scenarios is slipping...


For the audit, would it not be easier to tick the 'audited' checkbox against the fields you want to audit, then use the Audit Trail program / right-click the field in Proclaim Desktop/Main Case Handling and look at the change history that way?