This might be a newbie question, but I really appreciate your help. I’m trying to add a QR code field to the sales invoice doctype. As the qrcode should be generated from data in de invoice, and only when some conditions are met, I thought this is a use case for a virtual docfield. The field is also a custom field, as it will “extend” the fields in sales invoice provided by erpnext out of the box.
My initial thought is to use an HTML field type for the qr code custom field, mark it as “Virtual”, and include some logic in the overriding of sales invoice controller.
@property
def custom_qr_verifactu(self):
#Some logic to generate the base64 image for qrcode goes here
return "<img src='data:image/png;base64, DATAHERE'>"
For the moment, I’m just trying to return '<h1>QR goes here!</h1>'. However, the field does not render anything — neither in the form view nor in the document view of an individual invoice.
Has anyone managed to use a virtual HTML field like this successfully? Or is this a limitation of how HTML fields are rendered in Desk?
HTML fields are a bit quirky. Their most common application is just for presenting formatted text (sometimes manipulated on the client side).
What gets rendered from HTML Fields isn’t document-specific value but rather the content of the field def’s options property. Likewise, I’m not sure it’s possible to use virtual fields here.
What’s your ultimate goal? Are you trying to get a QR code to appear in a print format, or does it need to show up in the desk view too?
The qr code should be in both desk and print view. I finally managed to show it in Desk, and preview of print, with a Read Only field type and virtual. Problem arises in the final pdf, where it doesn’t show.
Hi haven’t tried Print Designer, @avc, but I’d prefer not to add another app to the product, if posible… I’m not storing the image, I use pyqrcode to generate a svg string “on the fly”, and I return that svg as a virtual field.
As I mentioned, it seems wkhtmltopdf messes up with some kind of fields… I’m playing with them and I will come back with my new findings.
Yeah, wkhtmltopdf is a major pain to work with, and what your describing here is a very familiar example of what that sometimes looks like. From what I can gather, it will do base64 rendering but is very fussy about formatting.
A new pdf backend will be available in v15, if I understand correctly, though at the moment I think it requires print designer as a dependency.