Drop shipments - new fields in the SupplierProduct entity

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Drop shipments - new fields in the SupplierProduct entity

Jacopo Cappellato
I'm going to implement true (yet simple) drop shipment features and I'll
need to specify which products can be drop shipped per supplier-product.

What about adding a new field, "allowDropShipments"(?), to the
SupplierProduct entity?

Jacopo
Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments - new fields in the SupplierProduct entity

cjhowe
Would drop shipment policy be based on SupplierProduct
or by supplier?  In our transactions it's always
supplier policy (or better stated our trust to take
advantage of supplier's policy).  I suppose this could
be several levels depending on how quirky the intended
industry is.

--- Jacopo Cappellato <[hidden email]> wrote:

> I'm going to implement true (yet simple) drop
> shipment features and I'll
> need to specify which products can be drop shipped
> per supplier-product.
>
> What about adding a new field,
> "allowDropShipments"(?), to the
> SupplierProduct entity?
>
> Jacopo
>

Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments - new fields in the SupplierProduct entity

David E Jones-2
In reply to this post by Jacopo Cappellato

Would this field, if set to Y, basically mean that if inventory is  
not available in the company's warehouse then drop-ship it through  
the supplier?

Or would it mean that it should always be drop-shipped regardless of  
local inventory? If not perhaps we might want a different option for  
that?

-David


On Sep 5, 2006, at 3:13 AM, Jacopo Cappellato wrote:

> I'm going to implement true (yet simple) drop shipment features and  
> I'll need to specify which products can be drop shipped per  
> supplier-product.
>
> What about adding a new field, "allowDropShipments"(?), to the  
> SupplierProduct entity?
>
> Jacopo

Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments - new fields in the SupplierProduct entity

Jacopo Cappellato
David,

thanks, these are good points. Please see my comments below:

David E Jones wrote:
>
> Would this field, if set to Y, basically mean that if inventory is not
> available in the company's warehouse then drop-ship it through the
> supplier?
>

The new field I'm proposing ("allowDropShipments"), if set to "Y", would
basically mean that we can ask to that supplier to drop ship the item.
The use case I have in mind is this: the backoffice user is entering a
sales order for product X and he discovers that its stock level is low,
so he lookups if there are suppliers that are available to drop ship the
item (allowDropShipments=Y) and selects one of them (or just check a
'drop ship' box and the system automatically try to assign it to one of
the suppliers for drop shipment).

> Or would it mean that it should always be drop-shipped regardless of
> local inventory? If not perhaps we might want a different option for that?
>

Yes, if a product is always drop shipped it should be handled in a
different way: I was thinking to use (as is now for the current
'drop-shipment' implementation - that is more a 'cross-dock' shipping
implementation, i.e. the purchased products are received and immediately
assigned to the sales order) the Product.requirementMethodEnumId field
for this.

Does it make sense?

Jacopo


> -David
>
>
> On Sep 5, 2006, at 3:13 AM, Jacopo Cappellato wrote:
>
>> I'm going to implement true (yet simple) drop shipment features and
>> I'll need to specify which products can be drop shipped per
>> supplier-product.
>>
>> What about adding a new field, "allowDropShipments"(?), to the
>> SupplierProduct entity?
>>
>> Jacopo

Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments - new fields in the SupplierProduct entity

David E Jones-2

This is sounding more like we need an enum field or something... The  
options so far could be:

- allow manual drop ship
- auto drop ship on low quantity
- only drop ship (never stock)

There may be others. I know we don't plan to support all of these  
initially, but the fact that they've already come up in casual  
discussion means that probably will... Of course, this enum is a bit  
different and should probably go on the Product rather than on the  
SupplierProduct.

On the SupplierProduct entity we should probably have a field like  
"willDropShip" that is an indicator of whether or not the supplier  
will drop-ship that particular product.

-David


On Sep 5, 2006, at 10:45 PM, Jacopo Cappellato wrote:

> David,
>
> thanks, these are good points. Please see my comments below:
>
> David E Jones wrote:
>> Would this field, if set to Y, basically mean that if inventory is  
>> not available in the company's warehouse then drop-ship it through  
>> the supplier?
>
> The new field I'm proposing ("allowDropShipments"), if set to "Y",  
> would basically mean that we can ask to that supplier to drop ship  
> the item. The use case I have in mind is this: the backoffice user  
> is entering a sales order for product X and he discovers that its  
> stock level is low, so he lookups if there are suppliers that are  
> available to drop ship the item (allowDropShipments=Y) and selects  
> one of them (or just check a 'drop ship' box and the system  
> automatically try to assign it to one of the suppliers for drop  
> shipment).
>
>> Or would it mean that it should always be drop-shipped regardless  
>> of local inventory? If not perhaps we might want a different  
>> option for that?
>
> Yes, if a product is always drop shipped it should be handled in a  
> different way: I was thinking to use (as is now for the current  
> 'drop-shipment' implementation - that is more a 'cross-dock'  
> shipping implementation, i.e. the purchased products are received  
> and immediately assigned to the sales order) the  
> Product.requirementMethodEnumId field for this.
>
> Does it make sense?
>
> Jacopo
>
>
>> -David
>> On Sep 5, 2006, at 3:13 AM, Jacopo Cappellato wrote:
>>> I'm going to implement true (yet simple) drop shipment features  
>>> and I'll need to specify which products can be drop shipped per  
>>> supplier-product.
>>>
>>> What about adding a new field, "allowDropShipments"(?), to the  
>>> SupplierProduct entity?
>>>
>>> Jacopo
>

Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments - new fields in the SupplierProduct entity

Si Chen-2
Yes, I agree with David on this kind of a setup.  Technically it  
might even better to have the drop ship properties be associated with  
ProductStore, but that's probably over-designing it.

Si

On Sep 5, 2006, at 10:19 PM, David E Jones wrote:

>
> This is sounding more like we need an enum field or something...  
> The options so far could be:
>
> - allow manual drop ship
> - auto drop ship on low quantity
> - only drop ship (never stock)
>
> There may be others. I know we don't plan to support all of these  
> initially, but the fact that they've already come up in casual  
> discussion means that probably will... Of course, this enum is a  
> bit different and should probably go on the Product rather than on  
> the SupplierProduct.
>
> On the SupplierProduct entity we should probably have a field like  
> "willDropShip" that is an indicator of whether or not the supplier  
> will drop-ship that particular product.
>
> -David
>
>
> On Sep 5, 2006, at 10:45 PM, Jacopo Cappellato wrote:
>
>> David,
>>
>> thanks, these are good points. Please see my comments below:
>>
>> David E Jones wrote:
>>> Would this field, if set to Y, basically mean that if inventory  
>>> is not available in the company's warehouse then drop-ship it  
>>> through the supplier?
>>
>> The new field I'm proposing ("allowDropShipments"), if set to "Y",  
>> would basically mean that we can ask to that supplier to drop ship  
>> the item. The use case I have in mind is this: the backoffice user  
>> is entering a sales order for product X and he discovers that its  
>> stock level is low, so he lookups if there are suppliers that are  
>> available to drop ship the item (allowDropShipments=Y) and selects  
>> one of them (or just check a 'drop ship' box and the system  
>> automatically try to assign it to one of the suppliers for drop  
>> shipment).
>>
>>> Or would it mean that it should always be drop-shipped regardless  
>>> of local inventory? If not perhaps we might want a different  
>>> option for that?
>>
>> Yes, if a product is always drop shipped it should be handled in a  
>> different way: I was thinking to use (as is now for the current  
>> 'drop-shipment' implementation - that is more a 'cross-dock'  
>> shipping implementation, i.e. the purchased products are received  
>> and immediately assigned to the sales order) the  
>> Product.requirementMethodEnumId field for this.
>>
>> Does it make sense?
>>
>> Jacopo
>>
>>
>>> -David
>>> On Sep 5, 2006, at 3:13 AM, Jacopo Cappellato wrote:
>>>> I'm going to implement true (yet simple) drop shipment features  
>>>> and I'll need to specify which products can be drop shipped per  
>>>> supplier-product.
>>>>
>>>> What about adding a new field, "allowDropShipments"(?), to the  
>>>> SupplierProduct entity?
>>>>
>>>> Jacopo
>>

Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments - new fields in the SupplierProduct entity

Jacopo Cappellato
Ok, so:

1) SupplierProduct.willDropShip: an indicator of whether or not the
supplier will drop-ship that particular product

2) I propose to use Product.requirementMethodEnumId to list also:
- allow manual drop ship
- auto drop ship on low quantity
- only drop ship (never stock)

together with the existing requirement creation options

Is it ok?

Jacopo

Si Chen wrote:

> Yes, I agree with David on this kind of a setup.  Technically it might
> even better to have the drop ship properties be associated with
> ProductStore, but that's probably over-designing it.
>
> Si
>
> On Sep 5, 2006, at 10:19 PM, David E Jones wrote:
>
>>
>> This is sounding more like we need an enum field or something... The
>> options so far could be:
>>
>> - allow manual drop ship
>> - auto drop ship on low quantity
>> - only drop ship (never stock)
>>
>> There may be others. I know we don't plan to support all of these
>> initially, but the fact that they've already come up in casual
>> discussion means that probably will... Of course, this enum is a bit
>> different and should probably go on the Product rather than on the
>> SupplierProduct.
>>
>> On the SupplierProduct entity we should probably have a field like
>> "willDropShip" that is an indicator of whether or not the supplier
>> will drop-ship that particular product.
>>
>> -David
>>
>>
>> On Sep 5, 2006, at 10:45 PM, Jacopo Cappellato wrote:
>>
>>> David,
>>>
>>> thanks, these are good points. Please see my comments below:
>>>
>>> David E Jones wrote:
>>>> Would this field, if set to Y, basically mean that if inventory is
>>>> not available in the company's warehouse then drop-ship it through
>>>> the supplier?
>>>
>>> The new field I'm proposing ("allowDropShipments"), if set to "Y",
>>> would basically mean that we can ask to that supplier to drop ship
>>> the item. The use case I have in mind is this: the backoffice user is
>>> entering a sales order for product X and he discovers that its stock
>>> level is low, so he lookups if there are suppliers that are available
>>> to drop ship the item (allowDropShipments=Y) and selects one of them
>>> (or just check a 'drop ship' box and the system automatically try to
>>> assign it to one of the suppliers for drop shipment).
>>>
>>>> Or would it mean that it should always be drop-shipped regardless of
>>>> local inventory? If not perhaps we might want a different option for
>>>> that?
>>>
>>> Yes, if a product is always drop shipped it should be handled in a
>>> different way: I was thinking to use (as is now for the current
>>> 'drop-shipment' implementation - that is more a 'cross-dock' shipping
>>> implementation, i.e. the purchased products are received and
>>> immediately assigned to the sales order) the
>>> Product.requirementMethodEnumId field for this.
>>>
>>> Does it make sense?
>>>
>>> Jacopo
>>>
>>>
>>>> -David
>>>> On Sep 5, 2006, at 3:13 AM, Jacopo Cappellato wrote:
>>>>> I'm going to implement true (yet simple) drop shipment features and
>>>>> I'll need to specify which products can be drop shipped per
>>>>> supplier-product.
>>>>>
>>>>> What about adding a new field, "allowDropShipments"(?), to the
>>>>> SupplierProduct entity?
>>>>>
>>>>> Jacopo
>>>

Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments - new fields in the SupplierProduct entity

Daniel Kunkel
There's a couple of unexpected complication to drop shipping that might
be worth considering here during the design phase, how drop-shipped
products are returned. Some business have to take back returns while
others can have them returned to the drop-shipper. Handling/Reselling
returns correctly would be great.

Another complication is combining products from different suppliers, and
calculating shipping costs. A feature that drop-ships only orders from a
single drop-shipping supplier would be interesting.

Thanks

Daniel


On Wed, 2006-09-06 at 21:41 +0200, Jacopo Cappellato wrote:

> Ok, so:
>
> 1) SupplierProduct.willDropShip: an indicator of whether or not the
> supplier will drop-ship that particular product
>
> 2) I propose to use Product.requirementMethodEnumId to list also:
> - allow manual drop ship
> - auto drop ship on low quantity
> - only drop ship (never stock)
>
> together with the existing requirement creation options
>
> Is it ok?
>
> Jacopo
>
> Si Chen wrote:
> > Yes, I agree with David on this kind of a setup.  Technically it might
> > even better to have the drop ship properties be associated with
> > ProductStore, but that's probably over-designing it.
> >
> > Si
> >
> > On Sep 5, 2006, at 10:19 PM, David E Jones wrote:
> >
> >>
> >> This is sounding more like we need an enum field or something... The
> >> options so far could be:
> >>
> >> - allow manual drop ship
> >> - auto drop ship on low quantity
> >> - only drop ship (never stock)
> >>
> >> There may be others. I know we don't plan to support all of these
> >> initially, but the fact that they've already come up in casual
> >> discussion means that probably will... Of course, this enum is a bit
> >> different and should probably go on the Product rather than on the
> >> SupplierProduct.
> >>
> >> On the SupplierProduct entity we should probably have a field like
> >> "willDropShip" that is an indicator of whether or not the supplier
> >> will drop-ship that particular product.
> >>
> >> -David
> >>
> >>
> >> On Sep 5, 2006, at 10:45 PM, Jacopo Cappellato wrote:
> >>
> >>> David,
> >>>
> >>> thanks, these are good points. Please see my comments below:
> >>>
> >>> David E Jones wrote:
> >>>> Would this field, if set to Y, basically mean that if inventory is
> >>>> not available in the company's warehouse then drop-ship it through
> >>>> the supplier?
> >>>
> >>> The new field I'm proposing ("allowDropShipments"), if set to "Y",
> >>> would basically mean that we can ask to that supplier to drop ship
> >>> the item. The use case I have in mind is this: the backoffice user is
> >>> entering a sales order for product X and he discovers that its stock
> >>> level is low, so he lookups if there are suppliers that are available
> >>> to drop ship the item (allowDropShipments=Y) and selects one of them
> >>> (or just check a 'drop ship' box and the system automatically try to
> >>> assign it to one of the suppliers for drop shipment).
> >>>
> >>>> Or would it mean that it should always be drop-shipped regardless of
> >>>> local inventory? If not perhaps we might want a different option for
> >>>> that?
> >>>
> >>> Yes, if a product is always drop shipped it should be handled in a
> >>> different way: I was thinking to use (as is now for the current
> >>> 'drop-shipment' implementation - that is more a 'cross-dock' shipping
> >>> implementation, i.e. the purchased products are received and
> >>> immediately assigned to the sales order) the
> >>> Product.requirementMethodEnumId field for this.
> >>>
> >>> Does it make sense?
> >>>
> >>> Jacopo
> >>>
> >>>
> >>>> -David
> >>>> On Sep 5, 2006, at 3:13 AM, Jacopo Cappellato wrote:
> >>>>> I'm going to implement true (yet simple) drop shipment features and
> >>>>> I'll need to specify which products can be drop shipped per
> >>>>> supplier-product.
> >>>>>
> >>>>> What about adding a new field, "allowDropShipments"(?), to the
> >>>>> SupplierProduct entity?
> >>>>>
> >>>>> Jacopo
> >>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments - new fields in the SupplierProduct entity

David E Jones-2

Daniel,

You're right, there are certainly many varieties of requirements  
around drop-shipping. Following the normal contribution pattern for  
OFBiz whoever implements the initial drop-shipping stuff will have  
their requirements implemented. Over time as others have different  
needs and are willing to invest in them and contribute them back, the  
functionality will grow.

The main focus initially here is to make sure we don't design  
ourselves into a corner.

-David


On Sep 6, 2006, at 3:41 PM, Daniel Kunkel wrote:

> There's a couple of unexpected complication to drop shipping that  
> might
> be worth considering here during the design phase, how drop-shipped
> products are returned. Some business have to take back returns while
> others can have them returned to the drop-shipper. Handling/Reselling
> returns correctly would be great.
>
> Another complication is combining products from different  
> suppliers, and
> calculating shipping costs. A feature that drop-ships only orders  
> from a
> single drop-shipping supplier would be interesting.
>
> Thanks
>
> Daniel
>
>
> On Wed, 2006-09-06 at 21:41 +0200, Jacopo Cappellato wrote:
>> Ok, so:
>>
>> 1) SupplierProduct.willDropShip: an indicator of whether or not the
>> supplier will drop-ship that particular product
>>
>> 2) I propose to use Product.requirementMethodEnumId to list also:
>> - allow manual drop ship
>> - auto drop ship on low quantity
>> - only drop ship (never stock)
>>
>> together with the existing requirement creation options
>>
>> Is it ok?
>>
>> Jacopo
>>
>> Si Chen wrote:
>>> Yes, I agree with David on this kind of a setup.  Technically it  
>>> might
>>> even better to have the drop ship properties be associated with
>>> ProductStore, but that's probably over-designing it.
>>>
>>> Si
>>>
>>> On Sep 5, 2006, at 10:19 PM, David E Jones wrote:
>>>
>>>>
>>>> This is sounding more like we need an enum field or something...  
>>>> The
>>>> options so far could be:
>>>>
>>>> - allow manual drop ship
>>>> - auto drop ship on low quantity
>>>> - only drop ship (never stock)
>>>>
>>>> There may be others. I know we don't plan to support all of these
>>>> initially, but the fact that they've already come up in casual
>>>> discussion means that probably will... Of course, this enum is a  
>>>> bit
>>>> different and should probably go on the Product rather than on the
>>>> SupplierProduct.
>>>>
>>>> On the SupplierProduct entity we should probably have a field like
>>>> "willDropShip" that is an indicator of whether or not the supplier
>>>> will drop-ship that particular product.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Sep 5, 2006, at 10:45 PM, Jacopo Cappellato wrote:
>>>>
>>>>> David,
>>>>>
>>>>> thanks, these are good points. Please see my comments below:
>>>>>
>>>>> David E Jones wrote:
>>>>>> Would this field, if set to Y, basically mean that if  
>>>>>> inventory is
>>>>>> not available in the company's warehouse then drop-ship it  
>>>>>> through
>>>>>> the supplier?
>>>>>
>>>>> The new field I'm proposing ("allowDropShipments"), if set to "Y",
>>>>> would basically mean that we can ask to that supplier to drop ship
>>>>> the item. The use case I have in mind is this: the backoffice  
>>>>> user is
>>>>> entering a sales order for product X and he discovers that its  
>>>>> stock
>>>>> level is low, so he lookups if there are suppliers that are  
>>>>> available
>>>>> to drop ship the item (allowDropShipments=Y) and selects one of  
>>>>> them
>>>>> (or just check a 'drop ship' box and the system automatically  
>>>>> try to
>>>>> assign it to one of the suppliers for drop shipment).
>>>>>
>>>>>> Or would it mean that it should always be drop-shipped  
>>>>>> regardless of
>>>>>> local inventory? If not perhaps we might want a different  
>>>>>> option for
>>>>>> that?
>>>>>
>>>>> Yes, if a product is always drop shipped it should be handled in a
>>>>> different way: I was thinking to use (as is now for the current
>>>>> 'drop-shipment' implementation - that is more a 'cross-dock'  
>>>>> shipping
>>>>> implementation, i.e. the purchased products are received and
>>>>> immediately assigned to the sales order) the
>>>>> Product.requirementMethodEnumId field for this.
>>>>>
>>>>> Does it make sense?
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>>>> -David
>>>>>> On Sep 5, 2006, at 3:13 AM, Jacopo Cappellato wrote:
>>>>>>> I'm going to implement true (yet simple) drop shipment  
>>>>>>> features and
>>>>>>> I'll need to specify which products can be drop shipped per
>>>>>>> supplier-product.
>>>>>>>
>>>>>>> What about adding a new field, "allowDropShipments"(?), to the
>>>>>>> SupplierProduct entity?
>>>>>>>
>>>>>>> Jacopo
>>>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments - new fields in the SupplierProduct entity

David E Jones-2
In reply to this post by Jacopo Cappellato

Yeah, I guess combining them would work out okay... This is an  
alternative to creating purchase requirements, isn't it?

-David


On Sep 6, 2006, at 1:41 PM, Jacopo Cappellato wrote:

> Ok, so:
>
> 1) SupplierProduct.willDropShip: an indicator of whether or not the  
> supplier will drop-ship that particular product
>
> 2) I propose to use Product.requirementMethodEnumId to list also:
> - allow manual drop ship
> - auto drop ship on low quantity
> - only drop ship (never stock)
>
> together with the existing requirement creation options
>
> Is it ok?
>
> Jacopo
>
> Si Chen wrote:
>> Yes, I agree with David on this kind of a setup.  Technically it  
>> might even better to have the drop ship properties be associated  
>> with ProductStore, but that's probably over-designing it.
>> Si
>> On Sep 5, 2006, at 10:19 PM, David E Jones wrote:
>>>
>>> This is sounding more like we need an enum field or something...  
>>> The options so far could be:
>>>
>>> - allow manual drop ship
>>> - auto drop ship on low quantity
>>> - only drop ship (never stock)
>>>
>>> There may be others. I know we don't plan to support all of these  
>>> initially, but the fact that they've already come up in casual  
>>> discussion means that probably will... Of course, this enum is a  
>>> bit different and should probably go on the Product rather than  
>>> on the SupplierProduct.
>>>
>>> On the SupplierProduct entity we should probably have a field  
>>> like "willDropShip" that is an indicator of whether or not the  
>>> supplier will drop-ship that particular product.
>>>
>>> -David
>>>
>>>
>>> On Sep 5, 2006, at 10:45 PM, Jacopo Cappellato wrote:
>>>
>>>> David,
>>>>
>>>> thanks, these are good points. Please see my comments below:
>>>>
>>>> David E Jones wrote:
>>>>> Would this field, if set to Y, basically mean that if inventory  
>>>>> is not available in the company's warehouse then drop-ship it  
>>>>> through the supplier?
>>>>
>>>> The new field I'm proposing ("allowDropShipments"), if set to  
>>>> "Y", would basically mean that we can ask to that supplier to  
>>>> drop ship the item. The use case I have in mind is this: the  
>>>> backoffice user is entering a sales order for product X and he  
>>>> discovers that its stock level is low, so he lookups if there  
>>>> are suppliers that are available to drop ship the item  
>>>> (allowDropShipments=Y) and selects one of them (or just check a  
>>>> 'drop ship' box and the system automatically try to assign it to  
>>>> one of the suppliers for drop shipment).
>>>>
>>>>> Or would it mean that it should always be drop-shipped  
>>>>> regardless of local inventory? If not perhaps we might want a  
>>>>> different option for that?
>>>>
>>>> Yes, if a product is always drop shipped it should be handled in  
>>>> a different way: I was thinking to use (as is now for the  
>>>> current 'drop-shipment' implementation - that is more a 'cross-
>>>> dock' shipping implementation, i.e. the purchased products are  
>>>> received and immediately assigned to the sales order) the  
>>>> Product.requirementMethodEnumId field for this.
>>>>
>>>> Does it make sense?
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>> -David
>>>>> On Sep 5, 2006, at 3:13 AM, Jacopo Cappellato wrote:
>>>>>> I'm going to implement true (yet simple) drop shipment  
>>>>>> features and I'll need to specify which products can be drop  
>>>>>> shipped per supplier-product.
>>>>>>
>>>>>> What about adding a new field, "allowDropShipments"(?), to the  
>>>>>> SupplierProduct entity?
>>>>>>
>>>>>> Jacopo
>>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments - new fields in the SupplierProduct entity

Jacopo Cappellato
Yes,

the idea is exactly this one.

Jacopo

David E Jones wrote:

>
> Yeah, I guess combining them would work out okay... This is an
> alternative to creating purchase requirements, isn't it?
>
> -David
>
>
> On Sep 6, 2006, at 1:41 PM, Jacopo Cappellato wrote:
>
>> Ok, so:
>>
>> 1) SupplierProduct.willDropShip: an indicator of whether or not the
>> supplier will drop-ship that particular product
>>
>> 2) I propose to use Product.requirementMethodEnumId to list also:
>> - allow manual drop ship
>> - auto drop ship on low quantity
>> - only drop ship (never stock)
>>
>> together with the existing requirement creation options
>>
>> Is it ok?
>>
>> Jacopo
>>
>> Si Chen wrote:
>>> Yes, I agree with David on this kind of a setup.  Technically it
>>> might even better to have the drop ship properties be associated with
>>> ProductStore, but that's probably over-designing it.
>>> Si
>>> On Sep 5, 2006, at 10:19 PM, David E Jones wrote:
>>>>
>>>> This is sounding more like we need an enum field or something... The
>>>> options so far could be:
>>>>
>>>> - allow manual drop ship
>>>> - auto drop ship on low quantity
>>>> - only drop ship (never stock)
>>>>
>>>> There may be others. I know we don't plan to support all of these
>>>> initially, but the fact that they've already come up in casual
>>>> discussion means that probably will... Of course, this enum is a bit
>>>> different and should probably go on the Product rather than on the
>>>> SupplierProduct.
>>>>
>>>> On the SupplierProduct entity we should probably have a field like
>>>> "willDropShip" that is an indicator of whether or not the supplier
>>>> will drop-ship that particular product.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Sep 5, 2006, at 10:45 PM, Jacopo Cappellato wrote:
>>>>
>>>>> David,
>>>>>
>>>>> thanks, these are good points. Please see my comments below:
>>>>>
>>>>> David E Jones wrote:
>>>>>> Would this field, if set to Y, basically mean that if inventory is
>>>>>> not available in the company's warehouse then drop-ship it through
>>>>>> the supplier?
>>>>>
>>>>> The new field I'm proposing ("allowDropShipments"), if set to "Y",
>>>>> would basically mean that we can ask to that supplier to drop ship
>>>>> the item. The use case I have in mind is this: the backoffice user
>>>>> is entering a sales order for product X and he discovers that its
>>>>> stock level is low, so he lookups if there are suppliers that are
>>>>> available to drop ship the item (allowDropShipments=Y) and selects
>>>>> one of them (or just check a 'drop ship' box and the system
>>>>> automatically try to assign it to one of the suppliers for drop
>>>>> shipment).
>>>>>
>>>>>> Or would it mean that it should always be drop-shipped regardless
>>>>>> of local inventory? If not perhaps we might want a different
>>>>>> option for that?
>>>>>
>>>>> Yes, if a product is always drop shipped it should be handled in a
>>>>> different way: I was thinking to use (as is now for the current
>>>>> 'drop-shipment' implementation - that is more a 'cross-dock'
>>>>> shipping implementation, i.e. the purchased products are received
>>>>> and immediately assigned to the sales order) the
>>>>> Product.requirementMethodEnumId field for this.
>>>>>
>>>>> Does it make sense?
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>>>> -David
>>>>>> On Sep 5, 2006, at 3:13 AM, Jacopo Cappellato wrote:
>>>>>>> I'm going to implement true (yet simple) drop shipment features
>>>>>>> and I'll need to specify which products can be drop shipped per
>>>>>>> supplier-product.
>>>>>>>
>>>>>>> What about adding a new field, "allowDropShipments"(?), to the
>>>>>>> SupplierProduct entity?
>>>>>>>
>>>>>>> Jacopo
>>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments - new fields in the SupplierProduct entity

Si Chen-2
Jacopo,

So what process will be followed during a drop shipment?

1.  Would it automatically happen when the order is placed, or would  
it be a manual link [Drop Ship Order] like [Quick Ship Order]?
2.  Would a Shipment be created from the vendor to the customer?
3.  Would a sales and a purchase invoice be created?
4.  If so, what Shipment status would trigger the sales and purchase  
invoice to be created?
5.  Would automatic payment capture happen for the sales invoice with  
checkInvoicePaymentApplications as is now?

Just curious :)

Si


On Sep 6, 2006, at 10:03 PM, Jacopo Cappellato wrote:

> Yes,
>
> the idea is exactly this one.
>
> Jacopo
>
> David E Jones wrote:
>> Yeah, I guess combining them would work out okay... This is an  
>> alternative to creating purchase requirements, isn't it?
>> -David
>> On Sep 6, 2006, at 1:41 PM, Jacopo Cappellato wrote:
>>> Ok, so:
>>>
>>> 1) SupplierProduct.willDropShip: an indicator of whether or not  
>>> the supplier will drop-ship that particular product
>>>
>>> 2) I propose to use Product.requirementMethodEnumId to list also:
>>> - allow manual drop ship
>>> - auto drop ship on low quantity
>>> - only drop ship (never stock)
>>>
>>> together with the existing requirement creation options
>>>
>>> Is it ok?
>>>
>>> Jacopo
>>>
>>> Si Chen wrote:
>>>> Yes, I agree with David on this kind of a setup.  Technically it  
>>>> might even better to have the drop ship properties be associated  
>>>> with ProductStore, but that's probably over-designing it.
>>>> Si
>>>> On Sep 5, 2006, at 10:19 PM, David E Jones wrote:
>>>>>
>>>>> This is sounding more like we need an enum field or  
>>>>> something... The options so far could be:
>>>>>
>>>>> - allow manual drop ship
>>>>> - auto drop ship on low quantity
>>>>> - only drop ship (never stock)
>>>>>
>>>>> There may be others. I know we don't plan to support all of  
>>>>> these initially, but the fact that they've already come up in  
>>>>> casual discussion means that probably will... Of course, this  
>>>>> enum is a bit different and should probably go on the Product  
>>>>> rather than on the SupplierProduct.
>>>>>
>>>>> On the SupplierProduct entity we should probably have a field  
>>>>> like "willDropShip" that is an indicator of whether or not the  
>>>>> supplier will drop-ship that particular product.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Sep 5, 2006, at 10:45 PM, Jacopo Cappellato wrote:
>>>>>
>>>>>> David,
>>>>>>
>>>>>> thanks, these are good points. Please see my comments below:
>>>>>>
>>>>>> David E Jones wrote:
>>>>>>> Would this field, if set to Y, basically mean that if  
>>>>>>> inventory is not available in the company's warehouse then  
>>>>>>> drop-ship it through the supplier?
>>>>>>
>>>>>> The new field I'm proposing ("allowDropShipments"), if set to  
>>>>>> "Y", would basically mean that we can ask to that supplier to  
>>>>>> drop ship the item. The use case I have in mind is this: the  
>>>>>> backoffice user is entering a sales order for product X and he  
>>>>>> discovers that its stock level is low, so he lookups if there  
>>>>>> are suppliers that are available to drop ship the item  
>>>>>> (allowDropShipments=Y) and selects one of them (or just check  
>>>>>> a 'drop ship' box and the system automatically try to assign  
>>>>>> it to one of the suppliers for drop shipment).
>>>>>>
>>>>>>> Or would it mean that it should always be drop-shipped  
>>>>>>> regardless of local inventory? If not perhaps we might want a  
>>>>>>> different option for that?
>>>>>>
>>>>>> Yes, if a product is always drop shipped it should be handled  
>>>>>> in a different way: I was thinking to use (as is now for the  
>>>>>> current 'drop-shipment' implementation - that is more a 'cross-
>>>>>> dock' shipping implementation, i.e. the purchased products are  
>>>>>> received and immediately assigned to the sales order) the  
>>>>>> Product.requirementMethodEnumId field for this.
>>>>>>
>>>>>> Does it make sense?
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>>>>>>> -David
>>>>>>> On Sep 5, 2006, at 3:13 AM, Jacopo Cappellato wrote:
>>>>>>>> I'm going to implement true (yet simple) drop shipment  
>>>>>>>> features and I'll need to specify which products can be drop  
>>>>>>>> shipped per supplier-product.
>>>>>>>>
>>>>>>>> What about adding a new field, "allowDropShipments"(?), to  
>>>>>>>> the SupplierProduct entity?
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>
>>>

Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments - new fields in the SupplierProduct entity

Si Chen-2
Hey, by the way, I created this a long time ago:
http://jira.undersunconsulting.com/browse/OFBIZ-539

May be we should close it and create an ASF JIRA issue for it?

Si


On Sep 7, 2006, at 9:23 AM, Si Chen wrote:

> Jacopo,
>
> So what process will be followed during a drop shipment?
>
> 1.  Would it automatically happen when the order is placed, or  
> would it be a manual link [Drop Ship Order] like [Quick Ship Order]?
> 2.  Would a Shipment be created from the vendor to the customer?
> 3.  Would a sales and a purchase invoice be created?
> 4.  If so, what Shipment status would trigger the sales and  
> purchase invoice to be created?
> 5.  Would automatic payment capture happen for the sales invoice  
> with checkInvoicePaymentApplications as is now?
>
> Just curious :)
>
> Si
>
>
> On Sep 6, 2006, at 10:03 PM, Jacopo Cappellato wrote:
>
>> Yes,
>>
>> the idea is exactly this one.
>>
>> Jacopo
>>
>> David E Jones wrote:
>>> Yeah, I guess combining them would work out okay... This is an  
>>> alternative to creating purchase requirements, isn't it?
>>> -David
>>> On Sep 6, 2006, at 1:41 PM, Jacopo Cappellato wrote:
>>>> Ok, so:
>>>>
>>>> 1) SupplierProduct.willDropShip: an indicator of whether or not  
>>>> the supplier will drop-ship that particular product
>>>>
>>>> 2) I propose to use Product.requirementMethodEnumId to list also:
>>>> - allow manual drop ship
>>>> - auto drop ship on low quantity
>>>> - only drop ship (never stock)
>>>>
>>>> together with the existing requirement creation options
>>>>
>>>> Is it ok?
>>>>
>>>> Jacopo
>>>>
>>>> Si Chen wrote:
>>>>> Yes, I agree with David on this kind of a setup.  Technically  
>>>>> it might even better to have the drop ship properties be  
>>>>> associated with ProductStore, but that's probably over-
>>>>> designing it.
>>>>> Si
>>>>> On Sep 5, 2006, at 10:19 PM, David E Jones wrote:
>>>>>>
>>>>>> This is sounding more like we need an enum field or  
>>>>>> something... The options so far could be:
>>>>>>
>>>>>> - allow manual drop ship
>>>>>> - auto drop ship on low quantity
>>>>>> - only drop ship (never stock)
>>>>>>
>>>>>> There may be others. I know we don't plan to support all of  
>>>>>> these initially, but the fact that they've already come up in  
>>>>>> casual discussion means that probably will... Of course, this  
>>>>>> enum is a bit different and should probably go on the Product  
>>>>>> rather than on the SupplierProduct.
>>>>>>
>>>>>> On the SupplierProduct entity we should probably have a field  
>>>>>> like "willDropShip" that is an indicator of whether or not the  
>>>>>> supplier will drop-ship that particular product.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Sep 5, 2006, at 10:45 PM, Jacopo Cappellato wrote:
>>>>>>
>>>>>>> David,
>>>>>>>
>>>>>>> thanks, these are good points. Please see my comments below:
>>>>>>>
>>>>>>> David E Jones wrote:
>>>>>>>> Would this field, if set to Y, basically mean that if  
>>>>>>>> inventory is not available in the company's warehouse then  
>>>>>>>> drop-ship it through the supplier?
>>>>>>>
>>>>>>> The new field I'm proposing ("allowDropShipments"), if set to  
>>>>>>> "Y", would basically mean that we can ask to that supplier to  
>>>>>>> drop ship the item. The use case I have in mind is this: the  
>>>>>>> backoffice user is entering a sales order for product X and  
>>>>>>> he discovers that its stock level is low, so he lookups if  
>>>>>>> there are suppliers that are available to drop ship the item  
>>>>>>> (allowDropShipments=Y) and selects one of them (or just check  
>>>>>>> a 'drop ship' box and the system automatically try to assign  
>>>>>>> it to one of the suppliers for drop shipment).
>>>>>>>
>>>>>>>> Or would it mean that it should always be drop-shipped  
>>>>>>>> regardless of local inventory? If not perhaps we might want  
>>>>>>>> a different option for that?
>>>>>>>
>>>>>>> Yes, if a product is always drop shipped it should be handled  
>>>>>>> in a different way: I was thinking to use (as is now for the  
>>>>>>> current 'drop-shipment' implementation - that is more a  
>>>>>>> 'cross-dock' shipping implementation, i.e. the purchased  
>>>>>>> products are received and immediately assigned to the sales  
>>>>>>> order) the Product.requirementMethodEnumId field for this.
>>>>>>>
>>>>>>> Does it make sense?
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>
>>>>>>>> -David
>>>>>>>> On Sep 5, 2006, at 3:13 AM, Jacopo Cappellato wrote:
>>>>>>>>> I'm going to implement true (yet simple) drop shipment  
>>>>>>>>> features and I'll need to specify which products can be  
>>>>>>>>> drop shipped per supplier-product.
>>>>>>>>>
>>>>>>>>> What about adding a new field, "allowDropShipments"(?), to  
>>>>>>>>> the SupplierProduct entity?
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>
>>>>

Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments -Processing ---- was new fields in the SupplierProduct entity

BJ Freeman
In reply to this post by David E Jones-2
Sorry I wasn't online when this took place.
I have implemented Drop shipping with in the framework of Ofbiz with a
few kinks.
First I have a dropshipper party group. this if a party is in this
group, then the Drop shipping logic I added is implemented.
Each has it's facilities, this is because some items are at different
locations and the shipping rate will be determine by which facility.
the Product is set to require inventory for those that that provide
inventory updates electronically.

The only change to ofbiz is the services that now look for the drop
shipping group to make alternative changes to the processes.

One of those hooks is the format to send an order in.
I accomplished this by putting the template in the contactmechs, with it
s own type.

in http://issues.apache.org/jira/browse/OFBIZ-143
i have provide contactmechs that relate to different ways to
communication with suppliers.
One of those is for the template to use for converting their data.

David E Jones sent the following on 9/6/2006 3:44 PM:

>
> Daniel,
>
> You're right, there are certainly many varieties of requirements around
> drop-shipping. Following the normal contribution pattern for OFBiz
> whoever implements the initial drop-shipping stuff will have their
> requirements implemented. Over time as others have different needs and
> are willing to invest in them and contribute them back, the
> functionality will grow.
>
> The main focus initially here is to make sure we don't design ourselves
> into a corner.
>
> -David
>
>
> On Sep 6, 2006, at 3:41 PM, Daniel Kunkel wrote:
>
>> There's a couple of unexpected complication to drop shipping that might
>> be worth considering here during the design phase, how drop-shipped
>> products are returned. Some business have to take back returns while
>> others can have them returned to the drop-shipper. Handling/Reselling
>> returns correctly would be great.
>>
>> Another complication is combining products from different suppliers, and
>> calculating shipping costs. A feature that drop-ships only orders from a
>> single drop-shipping supplier would be interesting.
>>
>> Thanks
>>
>> Daniel
>>
>>
>> On Wed, 2006-09-06 at 21:41 +0200, Jacopo Cappellato wrote:
>>> Ok, so:
>>>
>>> 1) SupplierProduct.willDropShip: an indicator of whether or not the
>>> supplier will drop-ship that particular product
>>>
>>> 2) I propose to use Product.requirementMethodEnumId to list also:
>>> - allow manual drop ship
>>> - auto drop ship on low quantity
>>> - only drop ship (never stock)
>>>
>>> together with the existing requirement creation options
>>>
>>> Is it ok?
>>>
>>> Jacopo
>>>
>>> Si Chen wrote:
>>>> Yes, I agree with David on this kind of a setup.  Technically it might
>>>> even better to have the drop ship properties be associated with
>>>> ProductStore, but that's probably over-designing it.
>>>>
>>>> Si
>>>>
>>>> On Sep 5, 2006, at 10:19 PM, David E Jones wrote:
>>>>
>>>>>
>>>>> This is sounding more like we need an enum field or something... The
>>>>> options so far could be:
>>>>>
>>>>> - allow manual drop ship
>>>>> - auto drop ship on low quantity
>>>>> - only drop ship (never stock)
>>>>>
>>>>> There may be others. I know we don't plan to support all of these
>>>>> initially, but the fact that they've already come up in casual
>>>>> discussion means that probably will... Of course, this enum is a bit
>>>>> different and should probably go on the Product rather than on the
>>>>> SupplierProduct.
>>>>>
>>>>> On the SupplierProduct entity we should probably have a field like
>>>>> "willDropShip" that is an indicator of whether or not the supplier
>>>>> will drop-ship that particular product.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Sep 5, 2006, at 10:45 PM, Jacopo Cappellato wrote:
>>>>>
>>>>>> David,
>>>>>>
>>>>>> thanks, these are good points. Please see my comments below:
>>>>>>
>>>>>> David E Jones wrote:
>>>>>>> Would this field, if set to Y, basically mean that if inventory is
>>>>>>> not available in the company's warehouse then drop-ship it through
>>>>>>> the supplier?
>>>>>>
>>>>>> The new field I'm proposing ("allowDropShipments"), if set to "Y",
>>>>>> would basically mean that we can ask to that supplier to drop ship
>>>>>> the item. The use case I have in mind is this: the backoffice user is
>>>>>> entering a sales order for product X and he discovers that its stock
>>>>>> level is low, so he lookups if there are suppliers that are available
>>>>>> to drop ship the item (allowDropShipments=Y) and selects one of them
>>>>>> (or just check a 'drop ship' box and the system automatically try to
>>>>>> assign it to one of the suppliers for drop shipment).
>>>>>>
>>>>>>> Or would it mean that it should always be drop-shipped regardless of
>>>>>>> local inventory? If not perhaps we might want a different option for
>>>>>>> that?
>>>>>>
>>>>>> Yes, if a product is always drop shipped it should be handled in a
>>>>>> different way: I was thinking to use (as is now for the current
>>>>>> 'drop-shipment' implementation - that is more a 'cross-dock' shipping
>>>>>> implementation, i.e. the purchased products are received and
>>>>>> immediately assigned to the sales order) the
>>>>>> Product.requirementMethodEnumId field for this.
>>>>>>
>>>>>> Does it make sense?
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>>>>>>> -David
>>>>>>> On Sep 5, 2006, at 3:13 AM, Jacopo Cappellato wrote:
>>>>>>>> I'm going to implement true (yet simple) drop shipment features and
>>>>>>>> I'll need to specify which products can be drop shipped per
>>>>>>>> supplier-product.
>>>>>>>>
>>>>>>>> What about adding a new field, "allowDropShipments"(?), to the
>>>>>>>> SupplierProduct entity?
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>
>>>
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments - new fields in the SupplierProduct entity

BJ Freeman
In reply to this post by cjhowe
yes I think keep the supplier process generic for all suppliers.
for instances one product may have multiple suppliers, some
dropshippers. Some of the current services will be expanded to make
which supplier based on shipping history and Agreements.



Chris Howe sent the following on 9/5/2006 2:16 AM:

> Would drop shipment policy be based on SupplierProduct
> or by supplier?  In our transactions it's always
> supplier policy (or better stated our trust to take
> advantage of supplier's policy).  I suppose this could
> be several levels depending on how quirky the intended
> industry is.
>
> --- Jacopo Cappellato <[hidden email]> wrote:
>
>> I'm going to implement true (yet simple) drop
>> shipment features and I'll
>> need to specify which products can be drop shipped
>> per supplier-product.
>>
>> What about adding a new field,
>> "allowDropShipments"(?), to the
>> SupplierProduct entity?
>>
>> Jacopo
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Drop shipments -Processing ---- was new fields in the SupplierProduct entity

BJ Freeman
In reply to this post by BJ Freeman
I have a client that has commissioned a back order process
this is for suppliers that have electronic communication about the order.
This is particularly important for drop shipping since they inventory
they provide is usually daily, or less and in not up to the minute. Or
the drop shipper that provides no inventory and you don't know till the
order goes in.
so the item may be back ordered by the time the order is sent to them.

this process takes care of generating the order task, notifying the
customer and doing the same as the inventory available service, but to
the supplier.

It has one more step that keeps the customer in the loop so they can
come to order history and change the order like delete the item that is
back ordered or do a split ship.

target for this is Feb 07



BJ Freeman sent the following on 10/9/2006 4:20 PM:

> Sorry I wasn't online when this took place.
> I have implemented Drop shipping with in the framework of Ofbiz with a
> few kinks.
> First I have a dropshipper party group. this if a party is in this
> group, then the Drop shipping logic I added is implemented.
> Each has it's facilities, this is because some items are at different
> locations and the shipping rate will be determine by which facility.
> the Product is set to require inventory for those that that provide
> inventory updates electronically.
>
> The only change to ofbiz is the services that now look for the drop
> shipping group to make alternative changes to the processes.
>
> One of those hooks is the format to send an order in.
> I accomplished this by putting the template in the contactmechs, with it
> s own type.
>
> in http://issues.apache.org/jira/browse/OFBIZ-143
> i have provide contactmechs that relate to different ways to
> communication with suppliers.
> One of those is for the template to use for converting their data.
>
> David E Jones sent the following on 9/6/2006 3:44 PM:
>>
>> Daniel,
>>
>> You're right, there are certainly many varieties of requirements
>> around drop-shipping. Following the normal contribution pattern for
>> OFBiz whoever implements the initial drop-shipping stuff will have
>> their requirements implemented. Over time as others have different
>> needs and are willing to invest in them and contribute them back, the
>> functionality will grow.
>>
>> The main focus initially here is to make sure we don't design
>> ourselves into a corner.
>>
>> -David
>>
>>
>> On Sep 6, 2006, at 3:41 PM, Daniel Kunkel wrote:
>>
>>> There's a couple of unexpected complication to drop shipping that might
>>> be worth considering here during the design phase, how drop-shipped
>>> products are returned. Some business have to take back returns while
>>> others can have them returned to the drop-shipper. Handling/Reselling
>>> returns correctly would be great.
>>>
>>> Another complication is combining products from different suppliers, and
>>> calculating shipping costs. A feature that drop-ships only orders from a
>>> single drop-shipping supplier would be interesting.
>>>
>>> Thanks
>>>
>>> Daniel
>>>
>>>
>>> On Wed, 2006-09-06 at 21:41 +0200, Jacopo Cappellato wrote:
>>>> Ok, so:
>>>>
>>>> 1) SupplierProduct.willDropShip: an indicator of whether or not the
>>>> supplier will drop-ship that particular product
>>>>
>>>> 2) I propose to use Product.requirementMethodEnumId to list also:
>>>> - allow manual drop ship
>>>> - auto drop ship on low quantity
>>>> - only drop ship (never stock)
>>>>
>>>> together with the existing requirement creation options
>>>>
>>>> Is it ok?
>>>>
>>>> Jacopo
>>>>
>>>> Si Chen wrote:
>>>>> Yes, I agree with David on this kind of a setup.  Technically it might
>>>>> even better to have the drop ship properties be associated with
>>>>> ProductStore, but that's probably over-designing it.
>>>>>
>>>>> Si
>>>>>
>>>>> On Sep 5, 2006, at 10:19 PM, David E Jones wrote:
>>>>>
>>>>>>
>>>>>> This is sounding more like we need an enum field or something... The
>>>>>> options so far could be:
>>>>>>
>>>>>> - allow manual drop ship
>>>>>> - auto drop ship on low quantity
>>>>>> - only drop ship (never stock)
>>>>>>
>>>>>> There may be others. I know we don't plan to support all of these
>>>>>> initially, but the fact that they've already come up in casual
>>>>>> discussion means that probably will... Of course, this enum is a bit
>>>>>> different and should probably go on the Product rather than on the
>>>>>> SupplierProduct.
>>>>>>
>>>>>> On the SupplierProduct entity we should probably have a field like
>>>>>> "willDropShip" that is an indicator of whether or not the supplier
>>>>>> will drop-ship that particular product.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Sep 5, 2006, at 10:45 PM, Jacopo Cappellato wrote:
>>>>>>
>>>>>>> David,
>>>>>>>
>>>>>>> thanks, these are good points. Please see my comments below:
>>>>>>>
>>>>>>> David E Jones wrote:
>>>>>>>> Would this field, if set to Y, basically mean that if inventory is
>>>>>>>> not available in the company's warehouse then drop-ship it through
>>>>>>>> the supplier?
>>>>>>>
>>>>>>> The new field I'm proposing ("allowDropShipments"), if set to "Y",
>>>>>>> would basically mean that we can ask to that supplier to drop ship
>>>>>>> the item. The use case I have in mind is this: the backoffice
>>>>>>> user is
>>>>>>> entering a sales order for product X and he discovers that its stock
>>>>>>> level is low, so he lookups if there are suppliers that are
>>>>>>> available
>>>>>>> to drop ship the item (allowDropShipments=Y) and selects one of them
>>>>>>> (or just check a 'drop ship' box and the system automatically try to
>>>>>>> assign it to one of the suppliers for drop shipment).
>>>>>>>
>>>>>>>> Or would it mean that it should always be drop-shipped
>>>>>>>> regardless of
>>>>>>>> local inventory? If not perhaps we might want a different option
>>>>>>>> for
>>>>>>>> that?
>>>>>>>
>>>>>>> Yes, if a product is always drop shipped it should be handled in a
>>>>>>> different way: I was thinking to use (as is now for the current
>>>>>>> 'drop-shipment' implementation - that is more a 'cross-dock'
>>>>>>> shipping
>>>>>>> implementation, i.e. the purchased products are received and
>>>>>>> immediately assigned to the sales order) the
>>>>>>> Product.requirementMethodEnumId field for this.
>>>>>>>
>>>>>>> Does it make sense?
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>
>>>>>>>> -David
>>>>>>>> On Sep 5, 2006, at 3:13 AM, Jacopo Cappellato wrote:
>>>>>>>>> I'm going to implement true (yet simple) drop shipment features
>>>>>>>>> and
>>>>>>>>> I'll need to specify which products can be drop shipped per
>>>>>>>>> supplier-product.
>>>>>>>>>
>>>>>>>>> What about adding a new field, "allowDropShipments"(?), to the
>>>>>>>>> SupplierProduct entity?
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>
>>>>
>>>
>>
>>
>