Package Shipping

[nicoe (Nicolas Évrard)]

Rational

Trytond would definitely benefit from a module that define a generic interface to the different shipping provider (like UPS, FedEx, etc). Some effort has already been done in this direction by OpenLabs / Fulfil.io: GitHub - trytonus/trytond-shipping: Trytond Shipping Module (and other related modules)

But there are some shortcomings in their modules:

• The shipping labels are stored as attachment of a shipment
• The shipping labels are generated only in the packed or done states of the shipments
• It has its own way to compute the shipment cost
• The credentials used to be log-in on the carrier webservice are stored in the database
• The address validation feature should probably be a separate module

Proposal

We add a stock.package.shipping which will have a number Char field and a label Binary field. Specialized module might want to extend this Model to add tracking historization and so on.

stock.package object will be extended with a link to a stock.package.shipping and a function field to compute the weight of the package in kg (it will be up to the specific shipping packages to make the required conversion to other unit of measure).

stock.package.type will gain additional fields to encode the dimension of the package. Specialized module might have to extend it to provide additional information (like the package code in their proprietary system).

A new object carrier.conditions will be created in order to store all the different configurations possibilities that applies to a carrier. In the generic module only the field family which is a selection is present. Additional module will extended it if necessary with additional fields.

stock.shipment.out will also be extend to include an identification_number Char field. A button will be added to shipment in order to request from the carrier an identification number. This button will call a method named <family>_create_shipping where <family> is the family of the carrier. It’s up to additional module to define this method. Validation of the packings will also use the same schema by calling <family>_validate_packing. This validation occurs on the packing state.

[resteve]

About the name of “stock.shipping.label” I understand without read documentation, it is the carrier label (for example a PDF); but reading your proposal, I thing you like to add tracking numbrer and more information. I don’t know if the best name for this class.

Also, some carriers use more information to delivery than tracking number:

• Service: 12h/24h/72h. International, etc
• Cash On Delivery. Pay with recibe the package
• …

We developed some modules do that with some Carrier API services*, but finally decided to do at same object “Shipment” because is more simple (not use more related objects) =>see all information in shipment view (and not use function fields or related).

Also, about save label or not (pdf other files), some API services you could redownload the label. It’s not necessary to save to attachment, but you could add a bool in carrier API configuration to decide that.

Regards

[ced (Cédric Krier)]

@nicoe

We add a stock.shipping.label object that have a reference to a stock.package and a tracking_number field.

I think it should be named stock.package.shipping with some fields like label and number.

@nicoe

A method on the label will be used to return the context in which the RPC call to the carrier webservice should be executed this context is a dictionary containing the pertinent information (addresses obviously, but some carriers might request the weight or the volume or even the dimensions).

I don’t see the point for such dictionary. I think we should re-use the well tested design of if/elif.

@nicoe

An open question is whether or not to keep the label data generated and sent by the carrier as this data is transient and of no historical value.

I think it is good to store it as a Binary field which could later be cleared when the shipment is done.

@resteve

finally decided to do at same object “Shipment” because is more simple

But wrong, a shipment can have many packages which all will require a separate label. So this information must be stored and computed at this level.

@resteve

see all information in shipment view

I guess we will need to have a list of root packages with the shipping information to be able to search on it and find the related shipment.

[ced (Cédric Krier)]

@nicoe

A new object carrier.conditions will be created in order to store all the different configurations possibilities that applies to a carrier. In the generic module only the field family which is a selection is present. Additional module will extended it if necessary with additional fields.

I think the configurations should only be for company related values like the credentials etc.
Otherwise the service properties should be stored on the carrier itself.

@nicoe

stock.shipment.out will also be extend to include an identification_number Char field.

For me, we can reuse the existing reference field.

@nicoe

This button will call a method named <family>_create_shipping where <family> is the family of the carrier.

I think it is better to go with wizard for this. We can not know if some services will not require some user inputs.

@nicoe

calling <family>_validate_packing

I think it is better to use suffix than prefix for methods that should have the same API.