We have been asked so many times to print the barcodes of a product or a lot.
I would be nice to have core Barcode reports for product and lots. So you can print those reports to get the label.
We have some custom reports u-sing python-barcode which works really well.
The field to get the code for the image should be a property, to allow customization.
Don’t you think it make sense to have this? Any use case I’m not catching or that can be an addition to my suggestion?
I would suggest to add the barcode generation function into the report class itself. So you can call for the barcode with the data you want, the size and the type of barcode. The function returns an image which you can position in your report. So no new things are needed in the different models.
There are many reports for which you want a barcode. For example a form which is filled by hand and then digitized. By using OCR you can use the barcode to match with a Tryton record for example.
I use Treepoem for barcode generation. It’s a Python wrapper around BWIPP a pure Postscript barcode generator. It has basically all the barcodes available (Symbologies Reference · bwipp/postscriptbarcode Wiki · GitHub) from 1D to 2D.
I will not be against adding tools to generate barcode and qrcode in trytond. The API must be designed to be abstract from the underlying library used (because we may need to change it in the future). Of course it is a good idea to expose this API to the report context. The API must also allow to create Function field to display them in the client.
Once this API is designed we can choose the libraries. For me they must be pure Python to avoid to have to deal with non-Python dependencies. I think it is good like python-barcode to use SVG as base format and rely on Pillow (which is already an optional dependency) to generate non-vectorial image. qrcode seem to be a good option also.
Also we should be allowed to introspect the available formats and support to have fallback.
Following the proposed implementation, I think a barcode function could be added to stock.move in order to generate a Code 128 and GS1_128.
Instead of calling self.code I’d call a get_128_code() that would return the result of stdnum’s gs1_128 encode implementation. This way we can achieve modules like stock_lot to fill the 10 from the gs1_128, 17 with stock_lot_sled, etc. etc. This could be configurable on the product.product very much like the lot_required multiselection and/or maybe a global product.configuration default.
Thoughts?
For me there is nothing standard in this proposal.
More over I do not see the point to generate a barcode for a stock move.
I can’t argue about the standard on the proposal, technically speaking, but I do not agree about the idea not being standard - not sure which you’re referring to.
stdnum provides the wikipedia links and the gs1 website links about the implementation.
I do not remember the necessity about generating a barcode for a stock move, but we’ve been asked on multiple times about this feature instead of the product one. In fact, the very initial post of this thread proposes the lot barcode.
When using Code128 which is already supported by python-stdnum you can have all the information related to a move in the code. This is usefull for example to include in a package/pallet/box a barcode with the following information:
With such code, when the package is received on another place scanning the barcode will import all the information in the ERP without the need of manually entering the information.
Indeed GS1 is a global encoding system for various logistics. It could be computed for various Tryton models. But for me it is out of the supporting barcode (and qrcode) in Tryton.
GS1 system could be implemented by a module which will define a standard API to get the encoded data and apply to various model but that’s for another topic.