DB Tools
Recall_and_Clone_Ticket.zip (1.5 KB)
… reserved for updates …
I thought this tutorial has been around for a while, as I’ve implemented it before. Has something changed, other than all the new screenshots?
He more than likely just updated it for v5. Previously it was archived in v4 and its slightly harder to browse those tutorials now considering the categories are hidden on first navigation.
1 Like
It has been around for a long time.
I simply updated it to add some small tweaks to make it more robust. It should work in V4 or V5.
This is “Method 2” from the original V4 Topic, but I removed that post from that thread and replaced it with a re-direct to this new Tutorial.
1 Like
I am not sure what the problem please have a look to the screen print below
I think the problem its from [:customerName] in the first image I think this because the primary field is phone in the second image
You didn’t show the rule but if you have historic orders where name used to be customer name and not primary (entity name) is now number it wouldn’t work.
Interesting to use program setting over a entity custom field for last ticket…
You would need to either update program sting names to numbers OR change the rule so it searches for entity data:name rather than entity name.
1 Like
sorry I don’t understand
What @JTRTech is saying is about what you mentioned:
The Rules search and set data for a Customer based on {ENTITY NAME:Customers} or [:EntityName]. So whenever you see one of those variables being used in the Rules, you might need to change that to use instead:
{ENTITY DATA:Customers:Phone}
But to be sure, show a screenshot of your Customer Entity Type configuration of the Custom Data Fields, and a screenshot of one of the Customers to see what type of data is stored in each field.
Ok, so your Primary Field is “Phone”. That means {ENTITY NAME:Customers} or [:EntityName] used in the Rules will show you the Customer Phone Number, and {ENTITY DATA:Customers:Name} can be used to display the Custom Data field called “Name” which contains the Customer Name.
I think the issue is that your Entity Type Name is not “Customers”… it is " Customers E T ". So in your Rules, anywhere you see this:
{ENTITY NAME:Customers}
… you need to change it to this:
{ENTITY NAME:Customers E T}
For example…
RULE: LT Display Last Customer Ticket
Constraint: '{SETTING:{ENTITY NAME:Customers}_CLastTicketId}' == ''
CHANGETO: '{SETTING:{ENTITY NAME:Customers E T}_CLastTicketId}' == ''
MessageToDisplay: Cannot find Previous Ticket for\r{ENTITY NAME:Customers}\r{ENTITY NAME:Tables}
CHANGETO: Cannot find Previous Ticket for\r{ENTITY NAME:Customers E T}\r{ENTITY NAME:Tables}
Constraint: '{SETTING:{ENTITY NAME:Customers}_CLastTicketId}' != ''
CHANGETO: '{SETTING:{ENTITY NAME:Customers E T}_CLastTicketId}' != ''
ticketId: [=TN('{SETTING:{ENTITY NAME:Customers}_CLastTicketId}')]
CHANGETO: [=TN('{SETTING:{ENTITY NAME:Customers E T}_CLastTicketId}')]
RULE: LT Entity Selected - Load CLastTicketId from Entity State and Store in Memory
entityTypeName: Customers
CHANGETO: Customers E T
RULE: LT Ticket Closing - Store Entity State CLastTicketId
Custom Constraint: {ENTITY NAME:Customers} Is Not Null
CHANGETO: {ENTITY NAME:Customers E T} Is Not Null
customerName: {ENTITY NAME:Customers}
CHANGETO:: {ENTITY NAME:Customers E T}
1 Like
still not working i make sure that its > Customers E T
what i think maybe because of custom field format ### ## ### ###
when the samba try to find the tiket the format of the phone
I think no Ticket Number has ever been stored to the Entity because the Rules were not working as expected to be able to store the Ticket Number in the Entity State.
Try creating a Ticket for a Customer and Settle it. This is when the Ticket Id is stored in the Entity’s State named CLastTicketId.
Then select the same Customer again, and try to Load Last Ticket.
I’m pretty sure it is because it has been changed from primary field of name to number.
Obviously the program settings based on entity name (when was ‘customer name’) won’t match what entity name now is which is customer number. These are not backdateadble and either need amending or adjusting for.
If the other topics are for same system it wouldn’t be entity name but data:name or manual change system settings from name to number.
That was where my comment about storing ‘last ticket’ as another custom entity field over using program settings came in.
Believe options are either use entity data:name would be option one HOWEVER this was changed to number for primary field due to name duplicates which will cause issues if using name, Alternativly manual updating stored program value names to customer number in place of name, or MY recommendation would be a ‘from this point forward’ solution of switching to an extra entity data field of last ticket id and use entity data rather than program setting and bite the bullet of from this point forward - that is dependent on number of values stored over time to update vs companies of this point forward inconvenience.
It could be stored in a Custom Data Field, yes. The Ticket Id is stored in the Entity State, not a Program Setting. The Program Setting used in the Tutorial is just temporary storage that carries the Ticket Id over multiple Rules that cannot access the Entity directly. I don’t remember exactly why I chose to use an Entity State as opposed to Custom Data Field, but I feel there must have been some reason at the time.
It does not matter if the Primary Field is called Phone or MemberId or whatever. {ENTITY NAME:Customers} (or in his case {ENTITY NAME:Customers E T}) will return the value stored in the Primary Field, no matter what the name of the Primary Field is, because that tag refers to the [Name] field in the [Entities] table in the DB. The name of the Primary field is moot. The only thing that is important is that the Field data is unique between the Entities. Yes, if the Phone was a Custom Field, and the Primary field was actually the customer name, we could do a search based on Entity Data, but in this case, we don’t need to do so - the Primary Field (Phone) should continue to work fine.
It might be possible that we have a problem here with the Primary Field Format. If you look at a previous screenshot, we can see the Phone on the Ticket Header in the format #### # ### ###. The same screenshot shows a message where the Entity Name is shown without the format (ie. ###########) so it is missing the spaces. We would need to look at how the [Name] field in the [Entities] table in the DB has the data recorded… with or without spaces. I have a feeling that it is stored without spaces, and the Formatting is for display purposes only. It might not matter, but it also could depend on what the Tag returns … does it return exactly what is in the DB? Or does it return a formatted version of it?
1 Like
Ok, I saw program setting using entity name and saw that a a mismatch like with his other topic where template was reversed after switching from name to number as primary field. Should have read it all, was basing it on the misunderstanding on how changing primary field on other topic for template effected the tags used… 
I’m sorry if I misunderstood the issue and it is unrelated but I recently added this for tomorrow’s 5.1.61 refresh.
2 Likes
Hi i have problem after doing this setup when i click on display last ticket i get error ( cannot find previous ticket ).