Second question: I showed them to be able to combine multiple deliveries with those I have already taken, but when I add the second delivery in the same custom field, I lose the traceability between the order and the address in the field. Example, I take 2 deliveries at the same time, then 1 cancels or wants to change the time, how can I understand which row of the custom field I need to delete.
I solved it by changing my approach, instead of displaying the entity’s custom fields, I put a report in display format.
<bold>$1</bold><br/>Pizze: {REPORT ORDER DETAILS:O.Quantity.Sum:(TEN.Orario=$1) AND (MG=Pizza) AND (ODI=True)}<br/>{REPORT TICKET DETAILS:[EC.Customers.Address]+'<br/>':(TEN.Orario=$1) AND (TS.Ordine=Domicilio)}
For the first problem, after restarting the PC the entities are seen correctly.
That will work however just be careful. Report tags there can be costly and slow system down. Every single entity will be executing that report everytime the screen is refreshed.
To elaborate on Jesse’s response, every time that entity screen is displayed or refreshed a db query is executed for every single entity (11 different queries in this instance). This is where the slow down can occur.
ok thanks so much for the suggestion, yesterday I tested it live, it worked very well, let’s see when it populates db if I have slowdowns I’ll go work on it.
Do you think custom fields are the right solution?
Looking at your display format, there’s two db queries per entity.
I’ve not played around with the in years as I just learned to live with the standard entity display and if I needed information on the ticket, I opened it.
To me, though, how many people at a table or where it’s destined seems to be ticket-level variables, not necessarily the entity/customer assigned.
Typically for faster performance you can use ticket level rule events to store and update entity custom data fields for better performance on the screens.
