Emailing Statement Quick questions - what have you done for these?


Reputable Poster

We are currently using embedded BI Publisher for emailing sales invoices (r42565) and it works great. We are using Send Method in A/R as the data selection on the R42565 to separate the emailed from printed jobs. We are using the data driven email on Sold To which references the messaging indicator on Line 0 of WhosWho. We do have some customers with multiple email addresses receiving invoices.

We are now looking into emailing statements which brings up questions on how statements and invoices coexist in BIP emailing processes. I have been looking here and Oracle Community/Support and keep finding enhancements related to the questions I have but there seems to be little action on them.

So, I have a few questions to ask the community since there will be a variety of ways to handle them.
- What field do you use in A/R for data selection on the R03B500X to separate out the email from printed into separate versions? CRMD (send method) is not on the business view.
- How do you handle the possibility that a customer will want sales invoices to go to one or more emails that differ from statements? Do you require all emails that get sales invoices to also get statements? Do you only allow a customer to have one email address for statements so you can use the functionality of fetching the email address in the UBE and putting it in the data driven variable?

Thank you for any and all suggestions / options.



Well Known Member
Have a look at the internals of R03B500X. You'll eventually find out that that is not the place to look. It is used to calculate and populate the tables used in statement printing.

In the proc options of R03B500X, there's a "Print" tab where the UBE|Version used to actually print the statements is set. That is the UBE that you want to work with.

Yes, it is entirely possible that statements and invoices are sent to different entities within organizations, or even different customers. eg. customerA places the order and gets invoiced, but customerB pays for amounts owed. So it could even be possible that customerB requires a copy of all invoices that appears on their statements the 1st time, to be sent together with the statement - no need to resend copies of past due invoices.

If you have a complex set of rules to determine which email address to use, just add a custom field to the print UBE that contains the actual email address value(s) (yup, if your variable supports it, you can string together a couple of email addresses), and use that variable instead in the data driven variable.


Reputable Poster
Hello Jileto,

Thank you for the quick response. I see what you are saying about the R03b500x being the driver and R03B5001 being the print job. However, trying to split the customer/statements at that level seems to be worse as the value the user sets in F03012 would have to travel all the way through 500X to end up in the F03B20/1 tables and less choices to do so. I would be interested in how you recommend doing that. Also, how do you cause R03B500X to fire off both versions of the R03b5001 for print and email statements?

As for the email addresses - thank you for the tip on stringing multiple emails together - I was looking for confirmation on that. Going that route will provide a lot of flexibility. Do you use ; or , between them?


Mike Mackinnon

Well Known Member
We are emailing both statements and invoices to customers. We generally don't send the invoice directly to customers email address though. We don't want the customer to receive a new email for each invoice we send to them (we want ONLY one email for each set of invoices sent to them). We save them to the network and someone selects the invoices, right clicks "email" and then manually sends the invoices to customer. Still waiting for some kind of enhancement that allows grouping of invoices by customer when bursting emailed PDFs.

Forl customer statements what we have done is create a custom program to use the AR statement information in F03B21 (and some other information like address book and F03B11). We run this after the generate statements (R03B500X) is run to place information in the F03B21 table. We created a new email address type (using F01151 - Who's Who > Email, with UDC 01/ET) to setup email address type for statements. This is included in the business view (or table SQL view) and then use the email address to determine where to send statement - if no email address exists then we print the statement and send via snail mail.

To differentiate the two methods of sending statement we run two versions - one that has email address <> blank and one where email address is not blank. Not the greatest but at least it gives us more freedom to control the layout and ability to send the statements where we want.


Reputable Poster
Thanks for the response, Mike. We had other mods to R42565, so we just added a simple level break header for Sold To on the Detail section so we could break and then burst the xml to put all the invoices for a customer into one pdf. As for the statement - interesting idea to replace the R03B5001. I hadn't thought of that, but leaving the whole R03b500 process alone sounds good.


Reputable Poster
This is just a quick post for future reference. I came across data driven printing by accident and it should be exactly what we need for statements. See document 2481322.1 for details. Basically, if you are on a high enough tools release (you may need an ESU in 9.0/9.1) there is functionality to have your UBE make a decision on if there is an email address or not and populate the data driven variable for email or printing.