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
