Warehouse and logistics teams live and die by proof of delivery. When a customer disputes a shipment, claims goods never arrived, or a driver's paper delivery slip is lost, smudged or forged, the business absorbs the chargeback and the argument. Odoo's stock.picking model records who validated a transfer and when, but there is no native signature capture on delivery orders or receipts in Community, and even Enterprise's sign integration is document-centric rather than wired into the actual inventory operation. That leaves a gap between "the system says it was delivered" and "here is the recipient's signature proving it."

This module closes that gap. We extend stock.picking with signature fields (x_pod_signature as a binary image, plus x_signer_name, x_signed_datetime, and geolocation x_signed_latitude/x_signed_longitude) and add an OWL-based signature pad widget to the picking form so a recipient can sign directly on a tablet or phone at the point of handover. When the transfer is validated, the signature, the typed signer name, a server-side UTC timestamp, and the captured coordinates are persisted against that exact operation — receipts (incoming), delivery orders (outgoing), and internal transfers alike. A @api.depends-driven compute flags whether a picking still needs a signature, so dispatchers can filter unsigned deliveries from a list view. The captured image is then rendered into the delivery slip QWeb report (stock.report_deliveryslip inherited via xpath), so every printed or PDF proof-of-delivery carries the recipient's signature block, name and time. Access is governed by ir.model.access.csv and record rules so drivers can sign but not alter historical signatures, and the fields are exposed over Odoo's XML-RPC/JSON-RPC API so a driver mobile app or third-party TMS can read and write proof-of-delivery data programmatically.

Because it is built on Odoo's native ORM and inventory flow rather than bolted on, the signature travels with the operation through backorders, returns and multi-step routes, and prints consistently whether the document is generated on screen, emailed, or produced by a scheduled action. We target Community and Enterprise on Odoo 17.0, 18.0 and 19.0, and adapt the widget and report inheritance to whichever version and edition you run.

This is a build-to-order module, not an instant download. After a short scoping call we confirm exactly which operation types need signatures, whether geolocation is mandatory or optional, how the signature block should appear on your document template, and any TMS or driver-app integration. We then build against a copy of your configuration, validate on a staging database, and deploy to production with a rollback plan. Typical delivery is one working week from confirmed scope.