I’m testing my emails and everything was working perfect on all new tickets generated. The issue I’m having is when I try to email a receipt for old tickets that were created before I added an email address to the Entity. Each ticket seems to store a copy of the Entity data at the time of the transaction.
Eg. Ticket ID 34 - Before I added email. Ticket ID 35 after I added email.
If i try to send a receipt for TID 34 using {ENTITY DATA:Email} It wont work.
I have tried the following but I cant get it to work.
And then send the email to {SETTING:ES CURRENT EMAIL}
I thought I had this working late last night but cant seem to get it working today.
Should this or could this have worked or am I going about this completely the wrong way?
This is the method used by @QMcKay in his Customer Account Statements tutorial to update the Entity Balance in the AS Set Statement Variables Rule
I guess it really depends on exactly how you have the Send Email operation configured.
Is it pulling Entity data out of the Ticket (email) and then sending? It does not appear to be the case. This is what I see:
open the ticket
update program setting with customer name
close the ticket
load the entity via program setting of customer name
read entity data email address and store it in a program setting
send email to program setting address
There should be no reason you would not be able to send e-mail to anyone, regardless of the Entity Data. I mean, you could send the email containing a receipt to yourself, or me, even if we assume neither of us are customers, and we have no Entity or Entity Data defined in your system.
The common practice for troubleshooting is the Show Message Action…
Throw a Show Message Action in just before calling the Send Email Action, to see what is actually stored in {SETTING:ES CURRENT EMAIL}.
If you find that it is empty, then do a Show Message just before updating ES CURRENT EMAIL to see what is stored in {ENTITY DATA:Customer:Email}.
If that is empty, you probably need to use simply this instead: {ENTITY DATA:Email} This might be because the system already knows you have a Customer Entity Type loaded.
The Show Message Action is your friend, and one of the best ways to troubleshoot any issue.
The email is blank before the ticket is closed as it should.
After Entity is loaded {ENTITY NAME} works but {ENTITY DATA:Email}.or {ENTITY DATA:Customer:Email}. does not.
It does work on the ticket where the email address was added before the transaction. It saves the setting after loading the entity.
I think the Load Entity should be loading the current Entity data and not the Ticket stored data once the ticket is closed but it doesn’t seem to be the case.
I know I could have a popup and type in the email address but I dont want to have to do this everytime. The only time when this will be an issue is if the email address is entered wrong and the sale put through.
I was sure I had this working last night but no way will it work today. I have tried everything
Ok, I have seen that before - you are correct - the Custom Data is not available outside of a Ticket.
There is another obscure, less-used tag to get that data outside of a Ticket. Let me find it…
EDIT: this is what you need:
{ENTITY CUSTOMDATA BY NAME:<ET>.<EN>:<FN>}
note the separators... ^ ^ ^
colon dot colon
where:
<ET> : Entity Type
<EN> : Entity Name
<FN> : Field Name of Custom Data
So in your case, if you load the Entity first:
{ENTITY CUSTOMDATA BY NAME:Customers.{ENTITY NAME}:Email}
or, if you skip loading the Entity, and just use the Stored Name from the Ticket:
{ENTITY CUSTOMDATA BY NAME:Customers.{SETTING:ES ENTITY NAME}:Email}
One or both should work.
Using that tag should eliminate the need to load the Entity at all (in which case {ENTITY NAME} will not work). You should just be able to open the ticket, store the Name, and use the above syntax with the stored Setting.
Ok this make everything alot easier. I just have to change {ENTITY DATA:Email} in my setup to {ENTITY CUSTOMDATA BY NAME:Customers.{ENTITY NAME:Customer}:Email} and it avoids all the update settings etc.
This is not necessarily true I have done this so I can email the account statements. I just added an update setting action to store the email address in the AS Set Statement Variables Rule
