If you ship with TCS across Pakistan, you already know the daily friction: staff re-key every order into the TCS portal, copy consignment numbers back into Odoo by hand, print labels from a separate screen, and reconcile COD collections against a spreadsheet at month-end. Odoo's native stock.picking and the standard "Delivery Methods" (delivery.carrier) framework give you generic shippers and flat/rule-based rates, but there is no TCS provider out of the box — no consignment booking against the TCS API, no city serviceability check, no AWB in the TCS load-sheet format, and no COD amount flowing back to reconciliation. That gap is exactly where a manual, error-prone process creeps in.

ECOSIRE builds a dedicated TCS provider that plugs into Odoo's carrier framework. We add a delivery.carrier of type tcs with its own credential fields (account number, API user/password/token, cost centre) stored on the carrier and, where you have multiple entities, on res.company. When a picking is validated, a book_shipment() implementation calls the TCS consignment-booking endpoint over its JSON/REST API, writes the returned CN/tracking number back onto the stock.picking (custom tcs_consignment_no, tcs_tracking_url fields defined on models.Model with proper ir.model.access.csv grants and record rules so only warehouse users see them), and stores the raw response for audit. City and service-area validation runs before booking so an un-serviceable destination is caught at the counter, not at the TCS hub.

Labelling is handled as a QWeb report: we generate the AWB/airway-bill and the TCS load-sheet as PDFs sized for your thermal or A5 printer, populated from the booked consignment data so what prints always matches what TCS has on record. COD is first-class — the order's COD amount is carried onto the consignment at booking, and we add reconciliation fields plus a view (and optional mail.activity/automated action) so finance can match TCS remittances back to the originating sale order and mark them settled. Tracking updates flow back either by a scheduled ir.cron that polls the TCS tracking endpoint or via an inbound webhook, updating delivery state on the picking so customer-service sees live status without leaving Odoo. Everything is exposed through Odoo's XML-RPC/JSON-RPC API too, so your storefront or a warehouse app can trigger a booking programmatically.

Because this is build-to-order, you are not downloading a generic app and hoping it fits. We start from a short scoping call to confirm your TCS account setup (COD vs non-COD, weight/piece rules, single vs multi-warehouse, Community or Enterprise, and your exact Odoo version — 17.0, 18.0 or 19.0), then build against those requirements, test on a staging copy of your database, and hand over installable source plus a git repository. Typical delivery is one working week from confirmed scope. You get a version-matched module, documentation, a training session for your dispatch and finance teams, and a post-go-live support window — not a black box.