openerp-expert-accounting team mailing list archive

[Graeme Gellatly <gdgellatly@xxxxxxxxx>]

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 <david@xxxxxxxxxxxxxxxxxx>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 <david@xxxxxxxxxx> 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:    david.rinnan@xxxxxxxxxx
>> 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     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-expert-accounting
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-expert-accounting
>> Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-expert-accounting
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-accounting
> Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-accounting
> More help   : https://help.launchpad.net/ListHelp
>
>