Skip to main content

Hello all,

At our company we are interested in using RMB for E-mail invoice. We have realized that we have a “conflict of interest” with this function. We have found the F1 help helpful, and we understand how it works. The problem is following: 

Note; if entered here, value will be valid for all external communication, e.g. order confirmation and delivery note. IFS only allow for one Document address, i.e. no separate invoice address!

The F1 help shows that below hierarchy is used:

Customer contact will be retrieved according to the below hierarchy.

1. Look at the Customer/Address/Order Info tab for the document address.
2. If it is empty, take the primary contact for the customer address defined on the Customer/Contact tab.
3. If that is empty, take the primary contact for the customer in general defined on the Customer/Contact tab.
4. If it is empty, then it takes the value from the Reference field on the Customer/Order/General tab.

 

As far as we understand, the RMB for E-mail invoice will interfere if you have another email that you use for the same customer. For example order confirmation. We want the RMB to choose an invoice mail for the customer (our customers have more than one email for communication) and keep using the ones we have for other external communication. 

 

In order to trigger the event something of the above mentioned must be used. Which in turn compromises other communication email addresses due to the limitation of one document address. Is it possible to somehow change where the RMB looks for the email address and instead choose another email address, for example AR Contact that is used for reminders?

 

Hi, 

Yep, fully understand the limitation.   Years and years ago, I used to need to do a mod. The mod was get the email address and place this in one of the unused event parameters like parameter 10 for example. 

That was long ago…

Now we have at least two options. 

Option 1) is the use the report rules and static communication information. See below.

For all customers (needing emailing) you would set up a communication name (for example INVOICE and ORDER CONF).   Then in the report rules for the invoices send the email to the INVOICE and for the order confirmation send the email to ORDER CONF.     The report rules are fairly straight forward, you may need some training on that.  I’m including a screen print that worked at one time when testing. My rule was something like this. 

It worked really well. 

Option 2 was to have a event action of SQL statement for the PDF_Created event.  The SQL then created the email and sent this to the INVOICE or ORDER CONF email address.  The event was rather detailed.  I don’t have a sample, but I’ve see it working at a couple clients.   

 

I thought option 1 was not too difficult. Option 2 required more technical skills. If needed I may be able to find an example.

Best regards, 

Thomas

Thank you for the information, just what I was looking for. Do you mind sharing the Property list for email invoice & order conf as you showed? 

Hi, 

I am attaching a document - someone wrote for a client.  I used that information to create my testing solution.   I may have had to change that a bit. It’s been well over a year since last time I tested. 

This document and consulting (if needed) will assist in solving the requirement. 

Best regards, 

Thomas

Hello again,

 

I am still not sure how this helps? I want to use the RMB Email Invoice. Without changing the customer reference. Invoice to AR Contact for example and OC to Customer Reference. I don’t understand how a report rule changes this?

 

 

Hi, 

Yep, fully understand the limitation.   Years and years ago, I used to need to do a mod. The mod was get the email address and place this in one of the unused event parameters like parameter 10 for example. 

That was long ago…

Now we have at least two options. 

Option 1) is the use the report rules and static communication information. See below.

For all customers (needing emailing) you would set up a communication name (for example INVOICE and ORDER CONF).   Then in the report rules for the invoices send the email to the INVOICE and for the order confirmation send the email to ORDER CONF.     The report rules are fairly straight forward, you may need some training on that.  I’m including a screen print that worked at one time when testing. My rule was something like this. 

It worked really well. 

Option 2 was to have a event action of SQL statement for the PDF_Created event.  The SQL then created the email and sent this to the INVOICE or ORDER CONF email address.  The event was rather detailed.  I don’t have a sample, but I’ve see it working at a couple clients.   

 

I thought option 1 was not too difficult. Option 2 required more technical skills. If needed I may be able to find an example.

Best regards, 

Thomas

Hi Thomas!


Do you have an example of option 2? We’ve worked with report rules but find them a bit unreliable and rather work with events. It would be interesting to see the solution.

Hi, 

I am attaching a document - someone wrote for a client.  I used that information to create my testing solution.   I may have had to change that a bit. It’s been well over a year since last time I tested. 

This document and consulting (if needed) will assist in solving the requirement. 

Best regards, 

Thomas

Hi! Still interested in an example of option 2 if you have one :)

Terms & ConditionsCookie settings