Payment Request "To Email" not pulling correctly

welihayes · January 6, 2021, 2:45pm

Hello all,

We’re having an issue with the customer’s “to” email not pulling through correctly into our Payment Request forms, and the field is defaulting to the email of the user who created the customer.
I have a custom field, “customer.default_email,” on the customer record, that would be useful to fetch data from. I changed the To field to default to this customer.default_email field, as described in the screenshot below, but it is not pulling forward properly into the Payment Request form. What can I do to fix this? Do I need a more robust “if” statement in the code for fetching the default_email field? Does the default_email field need to be a different datatype than it is now (data) to show up correctly here? Thank you for your help!

kennethsequeira · January 6, 2021, 2:43pm

@welihayes

This code should be able to pull the email from the customer master if the fetch from part is written correctly.

If you need the email to be picked up in the email box, write Email in the Options section of your field. This will tell ERPNext to validate the data entered in the field as an email ID.

welihayes · January 6, 2021, 2:53pm

Hey Kenneth,
Attached is a screenshot of the customer’s default_email field (this is a test customer with some junk data for display) in screenshot 1, and in screenshot 2 is a capture of what is happening by default on a new Payment Request – it is defaulting to my email address since I was the one who created the customer. The fetch statement is as shown in the original post. Still not sure why this is happening. This customer does NOT have a primary contact linked to it, but even customers who do have a primary contact with an email address linked are not functioning correctly for us in this regard.

kennethsequeira · January 6, 2021, 3:04pm

Is there is a reason to use this custom field as a source of the email for payment request? The system will pick up the email you’ve selected in the Sales Order/Invoice belonging to the customer for this purpose by default.

Looks like this is getting overriden from the serverside itself:

github.com

frappe/erpnext/blob/9fc44f1606b6a630baf6b2128c1ff2fd08be8b2c/erpnext/accounts/doctype/payment_request/payment_request.py#L151




		if hasattr(controller, 'validate_minimum_transaction_amount'):
			controller.validate_minimum_transaction_amount(self.currency, self.grand_total)


		return controller.get_payment_url(**{
			"amount": flt(self.grand_total, self.precision("grand_total")),
			"title": data.company.encode("utf-8"),
			"description": self.subject.encode("utf-8"),
			"reference_doctype": "Payment Request",
			"reference_docname": self.name,
			"payer_email": self.email_to or frappe.session.user,
			"payer_name": frappe.safe_encode(data.customer_name),
			"order_id": self.name,
			"currency": self.currency
		})


	def set_as_paid(self):
		if self.payment_channel == "Phone":
			self.db_set("status", "Paid")


		else:

Instead of this, why don’t you create a default contact for the customer, create a new order/invoice from that and check if the payment request is picking up the correct email.

welihayes · January 6, 2021, 3:18pm

Hey Kenneth,

That fix works for new sales orders where the customer has a primary contact set up. One day when we get our own server instance set up I will make sure to go in and edit this code, but for now we’re using the online version.

I will advise my sales team that when they create a customer they will need to set up a primary contact for the customer as well as filling out those custom “default” fields that we use for other purposes.

In the meantime, is there no way to override that code that’s being run by the server when it fetches the payer_email field?

kennethsequeira · January 6, 2021, 3:42pm

While I have not tested this, using server scripts might be your best bet.

I would really suggest not to edit code directly especially for smaller use cases. This will put you in a bad habit of editing the code directly and you may eventually end up in a situation where you’ll have issues maintaining your changes and upgrading in the long run.

It is always best to start with the base system, learn the best practices for using, configuring, and developing the system/customization or hiring someone who does this for a living

welihayes · January 6, 2021, 3:46pm

Awesome, thank you so much for your help. I am a DBA/SQL developer and have only dabbled in Python but we love ERPNext. Those links are very helpful. Have a good one and thank you again for assisting in figuring out this issue!