Party/Sale delivery contact mechanism

Support User
,
#1

Most carriers require (it is also a good idea to provide) contact information related to the delivery address.

I do not see a mechanism to do this in any of the Tryton modules.

With the relevant modules installed, an address has invoice and delivery booleans, which is useful. Contact mechanism only has invoice boolean.

I have a few customers who have one person making the orders for multiple delivery addresses. When the carrier arrives they should call the person at the delivery address, not the one making the orders.

The sale.sale model has contact. I do not know how this contact is meant to be used. I assume it is the person who ordered the goods?

stock_package has labels, but I guess I should store the contact mechanism for the destination address, then it can be fetched by a label report.

I guess I could solve it by custom module associating an address with a contact mechanism belonging to the same party, but it is not so pretty.

I would appreciate your viewpoints.

Somewhat related to: use of parties_address_contact

#2

For now the UPS and DPD modules are using the first phone, mobile and email contact mechanism of the party to which the shipment is delivered.
I guess it will be good that stock_package_shipping to add a usage shipping to the contact mechanism to give more flexibility to the selection.
I’m not sure it is useful nor correct to add a shipment_contact because we may not know which kind of mechanism will be needed. So for me it is better to create a specific party in case the ordering party is different.

1 Like
#3

In my case this takes care of 84 % of customers, but a party has more than one delivery address you have to select which one anyway, then you can also select the contact manually.

I will not create more than one party per customer because this will break deduplication: I use party.party code = enterprise number, this way I know I do not have the same company twice.

I will take some time to make sure I get it right, run it internally for a while and then submit for codereview.

If I understood wrong, and it is not useful for upstream, then feel free to invalidate the issue: issue9991

In party.address model, the stock module is extending it by adding delivery usage. Ok to have party.address delivery and party.contact_mechanism shipping or is it better for both to be delivery?

#4

Same as account_invoice add “invoice” field in contact mechanism, IMHO the “delivery” field should be added at stock module (an user like to send email to delivery address or know the phone to call, or … is not required a package shipment).

2 Likes
#5

For the moment I will be using the shipping/delivery usage on contact_mechanism manually, so for me it is ok also to have it in stock.

#6

Which is the requirement to have it on stock? If it’s only used for carriers I think it makes sense to add it on stock_package_shipping so for installations that do not use the carriers to delivers product there is not need to have such flag and the UI gets simpler.

#7

shipping usage to be implemented in stock_package_shipping it is.

Manual usage, but I understand that there should be a requirement in order to include it. For the moment I will extend party.contact_mechanism with shipping usage inside stock_package_shipping module even though I will only use this module for the extra check-box, for the moment.

#8

Maybe to use in combination with notification modules.

#9

For notification it may be also usefull for more modules like purchase, sale

#10

It’s true: email, report, …

It’s for this reason I propose to add at stock module and not other modules…

#11

I agree.

I think it makes sense to use delivery, the same as in party.address model.

#12

So it will be great if somebody can contribute a patch for it.

#13

already created issue, assigned it to me
will post code review shortly.

#14

Codereview for issue 9991:

Issue for using the new delivery boolean

#15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.