Add support for barcodes

[r0xsh]

Barcode

Barcode format specification

The barcode will use the code128 specification. This format is easy to read and supported by a wide range of library and hardware barcode scanners. It also seems to be a standard in the delivery industry.

Since CoopCycle will support both internal and external barcodes, the internal ones will follow a specific format.

• 4 first bytes will be 6767 (the ASCII code for CC)
• 3 next bytes will be the instance id, this will be useful as on the long term CoopCycle will support delivery transfer between instances
• The next byte will be the entity type
  • 1 for task
  • 2 for delivery (not sure to keep it)
• The last bytes will be the entity id
• 4 last bytes will be 8076 (the ASCII code for PL)

For example here is a barcode for a the task #420 in the demo instance (instance id 001)

Internal and external barcodes can be solved via the endpoint /api/barcode

GET /api/barcode?code=676700114208076

{
    "ressource": "https://demo.coopcycle.org/api/tasks/420"
}

Scanning process

Barcode technology is crucial in delivery, reducing errors and mental strain in parcel identification. By streamlining sorting and tracking, barcodes enhance efficiency and accuracy, ensuring timely and accurate deliveries. This saves time and minimizes human error, making the delivery system more reliable.

💡 Each parcel/package should have a barcode. This way, it's possible to have multiple barcodes linked to the same delivery in case of multiple package drop-off or multiple drop-off deliveries.

The process will look like this:

1. You open the app in scan mode via a button in the app
2. This will bring a window (see bellow)
3. On scan, a feedback is done via vibration, it will display the basic info of the delivery. The operator as to check if those information are valid or if the parcel is in good conditions.
4. If they’re valid, the operator can scan another parcel; if not he’ll have to press the “warning” button to report a incident

The 📞 icon allows the operator to directly call the recipient. This enables the operator to ask if the recipient is available to receive the parcel. If necessary, the operator can report an incident to reschedule the delivery or add a note if the recipient requests the parcel to be delivered to a neighbor.

https://www.figma.com/design/onhmIUBfl7nZJ34Tou64CQ/Scanning?node-id=1-1048&m=dev

If there is nothing to report, by default the action of scanning will automatically mark the parcel as “well received without damage”

Error reporting

If issue clicking on the “warning” button will bring this screen

https://www.figma.com/design/onhmIUBfl7nZJ34Tou64CQ/Scanning?node-id=10-145&m=dev

There is two kind of report (technically they’ll all results into a incident)

Error in the task details

If there is an error in the address or the weight/volume, this will surely result in a price change. The app will prompt the operator for the changes. The operator can update the address, change the weight or volume, or select a package.

The operator can also enter a new date if the recipient informs them that they won't be available for delivery in the default time range.

https://www.figma.com/design/onhmIUBfl7nZJ34Tou64CQ/Scanning?node-id=11-146&m=dev

Report a damaged parcel

In the case of a damaged parcel, the operator can easily report it using a simple prefilled list of incident types. This list can be customized with specific failure reasons.

https://www.figma.com/design/onhmIUBfl7nZJ34Tou64CQ/Scanning?node-id=12-147&m=dev

[r0xsh]

It seems there is a industrial standard about what data to store in the barcode

• https://ref.gs1.org/ai/
• https://www.gs1.ch/fr/media/1114