We had this issue, so I wrote a couple of little modules to fix it. Please see http://youtu.be/epqqWJzg0L8 for how we have resolved the second scenario and demos of partner_address_wizard and sale_drop_ship.
Kind regards, Graeme . But I suppose if we had 1 address called 'customer to collect' and another 'customer drop ship' and worked the domains on sale_order, I geuss it is possible. Just create another field of type text On Thu, Dec 22, 2011 at 6:35 PM, David Mitchell <[email protected]>wrote: > Hi everyone, > > Regarding Drop shipping I think there are two scenarios that need to be > addressed: > > 1) When a company (e.g. Company A) has the role of seller to the end > customer. They are purchasing a good from their supplier/vendor (Supplier > A) and Company A wants Supplier A to drop-ship the item to Company A's > end-customer. The burden being on Supplier A to drop ship the goods. <-- > this is the scenario I believe Rvalyi was originally describing. > > An alternative drop ship scenario exists which we've seen is as follows: > > 2) When company (e.g. Company A) takes on the role of supplier. A retailer > (Retailer B) has placed a sales order - and they want Company A (OpenERP > user) to drop ship the order to Retailer B's customer. The challenge is > that Company A - the user of OpenERP - doesn't want to hold all of the > Retailer B's drop ship customers in the address file as well. We have this > situation in which Retailer B has 3000-4000 drop ship addresses. > > Other systems we've seen in this scenario actually write the entire drop > ship address into the Sales Order Table - versus just a reference to the > res.partner.address id. Thus keeping the "Drop Ship" address completely > independent from residing in the Address Table. Those other system actually > just "copy" the current addresses on file from the Partner record for > Invoicing Address and Shipping Address - and then allow them to be > overwritten. This also prevents the issue of overwriting historical > addresses with an address change inadvertently with an address edit - > versus entering a new address entirely to protect history. > > I just wanted to mention Use Case #2 as it is related to drop shipping as > well. Has anyone addressed #2 in this group?? > > Thanks, > > On Fri, Oct 7, 2011 at 6:29 AM, David Rinnan <[email protected]> wrote: > >> I think option B is good. >> My documentation to the supplier is the purchase order which includes >> shipping info. When they have confirmed I can "receive" the product. >> >> The good thing with option A, as I see it, is that invoice control could >> be implemented in a more flexible matter and more inline as how OpenERP >> works already. >> >> But if we assume manual invoice control or prepaid invoice settings then >> option B would be the cleanest implementation I think >> >> >> >> >> -- >> David Rinnan >> Business Consultant >> >> ASPIRIX AB >> email: [email protected] >> phone: +46 707 16 38 00 >> skype: david.rinnan >> twitter: davidrinnan >> >> Open Source Business Solutions >> >> 6 okt 2011 kl. 14.39 skrev Raphael Valyi: >> >> Hello, >> >> I will soon work on refactoring of the purchase_to_sale >> and sale_supplier_direct_delivery modules together to make a better support >> for drop shipping in OpenERP. >> >> However, I have a doubt: what do you think is better: >> >> A) drop shipping products pickings are generated upon the sale order but >> they have the supplier location as the origin. >> The corresponding purchase order line doesn't generate any reception. >> >> B) drop shipping products don't generate pickings upon the sale order. >> But when they are bought, the reception goes to the customer instead. >> Eventually there could be an invoice upon this delivery if he product >> hasn't been invoiced upon the sale order already. >> >> >> I tend to prefer B because I would say it's easier to relate the shipping >> and the purchase properly, specially if you change the supplier or the >> expedition date. >> and this is what I recently did in the purchase_to_sale module. Do you >> think A is better? >> >> >> BTW, I submitted a merge proposal of the order picking shipment >> generation in 6.1 and will soon push the equivalent for purchase, this is >> he kind of thing that will make it cleaner to properly relate the sale >> order line and purchase order line and tweak the shipping in those specific >> MTO cases. >> >> >> Regards. >> >> >> -- >> Raphaël Valyi >> Founder and consultant >> http://twitter.com/rvalyi <http://twitter.com/#%21/rvalyi> >> +55 21 2516 2954 >> www.akretion.com >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openerp-expert-accounting >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openerp-expert-accounting >> More help : https://help.launchpad.net/ListHelp >> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openerp-expert-accounting >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openerp-expert-accounting >> More help : https://help.launchpad.net/ListHelp >> >> > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-accounting > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-accounting > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-accounting Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-accounting More help : https://help.launchpad.net/ListHelp
