_validate_packing`. This validation occurs on the packing state.
---
### Author:  [@resteve](https://discuss.tryton.org/u/resteve)
#### Post date: [March 4, 2016, 7:23am UTC](https://discuss.tryton.org/t/package-shipping/63/2 "2016-03-04T07:23:25Z")
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
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [March 4, 2016, 3:39pm UTC](https://discuss.tryton.org/t/package-shipping/63/3 "2016-03-04T15:39:11Z")
> [@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](http://downloads.tryton.org/TUBA2015/design_pattern/mgp00005.html).
> [@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.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [April 1, 2016, 11:18am UTC](https://discuss.tryton.org/t/package-shipping/63/4 "2016-04-01T11:18:21Z")
> [@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 \\_create\_shipping where \ 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 `_validate_packing`
I think it is better to use suffix than prefix for methods that should have the same API.