OFBiz Shipment operations too buggy to use?

[Christian Carlow-OFBizzer]

I was wondering if anyone could tell me whether or not OFBiz's shipment
capabilities are sophisticated enough to work OOTB or if its considered
something too buggy to use yet.  I've tried creating shipments to
fulfill OrderItem ShipGroup schedules multiple ways and have encountered
bugs with all of them.  The majority of the bugs relate to incorrect
calculation of the OrderItemShipGroupInvRes. OrderItemShipGroupInvRes
seems to determine what is allowed to be picked, packed and shipped but
can easily contain incorrect information.

I tried disabling the Reserve Inventory option of the store but this
prevented me from shipping anything.  Does Reserve Inventory have to be
enabled to allow shipment capabilities for orders?

Is anyone using OFBiz OOTB to handle order shipments?

[Jacques Le Roux]

Which Release.revision?
Though I did not try it recently, I remember it was working in "old" releases.

Jacques

Christian Carlow wrote:

> I was wondering if anyone could tell me whether or not OFBiz's shipment
> capabilities are sophisticated enough to work OOTB or if its considered
> something too buggy to use yet.  I've tried creating shipments to
> fulfill OrderItem ShipGroup schedules multiple ways and have encountered
> bugs with all of them.  The majority of the bugs relate to incorrect
> calculation of the OrderItemShipGroupInvRes. OrderItemShipGroupInvRes
> seems to determine what is allowed to be picked, packed and shipped but
> can easily contain incorrect information.
>
> I tried disabling the Reserve Inventory option of the store but this
> prevented me from shipping anything.  Does Reserve Inventory have to be
> enabled to allow shipment capabilities for orders?
>
> Is anyone using OFBiz OOTB to handle order shipments?

[Christian Carlow-OFBizzer]

Hey Jacques,

Sorry, using 12.04 stable release.

On 10/23/2013 03:28 PM, Jacques Le Roux wrote:

> Which Release.revision?
> Though I did not try it recently, I remember it was working in "old" releases.
>
> Jacques
>
> Christian Carlow wrote:
>> I was wondering if anyone could tell me whether or not OFBiz's shipment
>> capabilities are sophisticated enough to work OOTB or if its considered
>> something too buggy to use yet.  I've tried creating shipments to
>> fulfill OrderItem ShipGroup schedules multiple ways and have encountered
>> bugs with all of them.  The majority of the bugs relate to incorrect
>> calculation of the OrderItemShipGroupInvRes. OrderItemShipGroupInvRes
>> seems to determine what is allowed to be picked, packed and shipped but
>> can easily contain incorrect information.
>>
>> I tried disabling the Reserve Inventory option of the store but this
>> prevented me from shipping anything.  Does Reserve Inventory have to be
>> enabled to allow shipment capabilities for orders?
>>
>> Is anyone using OFBiz OOTB to handle order shipments?

[Christian Carlow-OFBizzer]

IMO, the OrderItemShipGrpInvRes entity should be removed and anything
referencing it should be changed to derive quantities from the entities
that cause the quantities in OrderItemShipGrpInvRes to change.

For example, the Order Items page of the Shipments application bases the
list of items that may be issued to the Shipment on the
OrderItemShipGrpInvRes entity.  I think it should be changed to generate
the list based on the joining of the OrderItemShipGroupAssoc and
ItemIssuance entities and only list those records that have a remaining
quantity greater than 0.

OrderItemShipGroupAssoc is only used when the store "Reserve Inventory"
setting is set to "Y" and is the only way to create itemIssuance
records.  Without itemIssuances being used there is no way to ship order
items.

On 10/23/2013 03:30 PM, Christian Carlow wrote:

> Hey Jacques,
>
> Sorry, using 12.04 stable release.
>
> On 10/23/2013 03:28 PM, Jacques Le Roux wrote:
>> Which Release.revision?
>> Though I did not try it recently, I remember it was working in "old"
>> releases.
>>
>> Jacques
>>
>> Christian Carlow wrote:
>>> I was wondering if anyone could tell me whether or not OFBiz's shipment
>>> capabilities are sophisticated enough to work OOTB or if its considered
>>> something too buggy to use yet.  I've tried creating shipments to
>>> fulfill OrderItem ShipGroup schedules multiple ways and have
>>> encountered
>>> bugs with all of them.  The majority of the bugs relate to incorrect
>>> calculation of the OrderItemShipGroupInvRes. OrderItemShipGroupInvRes
>>> seems to determine what is allowed to be picked, packed and shipped but
>>> can easily contain incorrect information.
>>>
>>> I tried disabling the Reserve Inventory option of the store but this
>>> prevented me from shipping anything.  Does Reserve Inventory have to be
>>> enabled to allow shipment capabilities for orders?
>>>
>>> Is anyone using OFBiz OOTB to handle order shipments?
>

[Christian Carlow-OFBizzer]

OrderItemShipGrpInvRes seems like it was meant to track backorder
information by storing aggregate quantities that could otherwise be
calculated by subtracting ItemIssuance records from matching
InventoryItem records in the way that InventoryItem quantityOnHand and
availableToPromise fields are aggregates of the InventoryItemDetail
records.  I suppose that referencing an aggregate quantity would be much
faster way to get a value so I'll attempt to fix the without trying to
remove the entity.

I'm going to start working on this and assume the shipment operations
have not yet been completed in any version.


On 10/23/2013 04:28 PM, Christian Carlow wrote:

> IMO, the OrderItemShipGrpInvRes entity should be removed and anything
> referencing it should be changed to derive quantities from the
> entities that cause the quantities in OrderItemShipGrpInvRes to change.
>
> For example, the Order Items page of the Shipments application bases
> the list of items that may be issued to the Shipment on the
> OrderItemShipGrpInvRes entity.  I think it should be changed to
> generate the list based on the joining of the OrderItemShipGroupAssoc
> and ItemIssuance entities and only list those records that have a
> remaining quantity greater than 0.
>
> OrderItemShipGroupAssoc is only used when the store "Reserve
> Inventory" setting is set to "Y" and is the only way to create
> itemIssuance records.  Without itemIssuances being used there is no
> way to ship order items.
>
> On 10/23/2013 03:30 PM, Christian Carlow wrote:
>> Hey Jacques,
>>
>> Sorry, using 12.04 stable release.
>>
>> On 10/23/2013 03:28 PM, Jacques Le Roux wrote:
>>> Which Release.revision?
>>> Though I did not try it recently, I remember it was working in "old"
>>> releases.
>>>
>>> Jacques
>>>
>>> Christian Carlow wrote:
>>>> I was wondering if anyone could tell me whether or not OFBiz's
>>>> shipment
>>>> capabilities are sophisticated enough to work OOTB or if its
>>>> considered
>>>> something too buggy to use yet.  I've tried creating shipments to
>>>> fulfill OrderItem ShipGroup schedules multiple ways and have
>>>> encountered
>>>> bugs with all of them.  The majority of the bugs relate to incorrect
>>>> calculation of the OrderItemShipGroupInvRes. OrderItemShipGroupInvRes
>>>> seems to determine what is allowed to be picked, packed and shipped
>>>> but
>>>> can easily contain incorrect information.
>>>>
>>>> I tried disabling the Reserve Inventory option of the store but this
>>>> prevented me from shipping anything.  Does Reserve Inventory have
>>>> to be
>>>> enabled to allow shipment capabilities for orders?
>>>>
>>>> Is anyone using OFBiz OOTB to handle order shipments?
>>
>

[Christian Carlow-OFBizzer]

Would someone please provide scenarios where "Reserve Inventory" should
be set to "N" for a store.  It causes OrderItemShipGrpInvRes not to be
used so there's no way to ship the order item.  Does this mean that
"Reserve Inventory" is necessary anytime a store requires shipments?

I'm wondering if I should code for allowing "Reserve Inventory" set to
"N" to allow for creating shipments for order items.

On 10/24/2013 08:05 AM, Christian Carlow wrote:

> OrderItemShipGrpInvRes seems like it was meant to track backorder
> information by storing aggregate quantities that could otherwise be
> calculated by subtracting ItemIssuance records from matching
> InventoryItem records in the way that InventoryItem quantityOnHand and
> availableToPromise fields are aggregates of the InventoryItemDetail
> records.  I suppose that referencing an aggregate quantity would be
> much faster way to get a value so I'll attempt to fix the without
> trying to remove the entity.
>
> I'm going to start working on this and assume the shipment operations
> have not yet been completed in any version.
>
>
> On 10/23/2013 04:28 PM, Christian Carlow wrote:
>> IMO, the OrderItemShipGrpInvRes entity should be removed and anything
>> referencing it should be changed to derive quantities from the
>> entities that cause the quantities in OrderItemShipGrpInvRes to change.
>>
>> For example, the Order Items page of the Shipments application bases
>> the list of items that may be issued to the Shipment on the
>> OrderItemShipGrpInvRes entity.  I think it should be changed to
>> generate the list based on the joining of the OrderItemShipGroupAssoc
>> and ItemIssuance entities and only list those records that have a
>> remaining quantity greater than 0.
>>
>> OrderItemShipGroupAssoc is only used when the store "Reserve
>> Inventory" setting is set to "Y" and is the only way to create
>> itemIssuance records.  Without itemIssuances being used there is no
>> way to ship order items.
>>
>> On 10/23/2013 03:30 PM, Christian Carlow wrote:
>>> Hey Jacques,
>>>
>>> Sorry, using 12.04 stable release.
>>>
>>> On 10/23/2013 03:28 PM, Jacques Le Roux wrote:
>>>> Which Release.revision?
>>>> Though I did not try it recently, I remember it was working in
>>>> "old" releases.
>>>>
>>>> Jacques
>>>>
>>>> Christian Carlow wrote:
>>>>> I was wondering if anyone could tell me whether or not OFBiz's
>>>>> shipment
>>>>> capabilities are sophisticated enough to work OOTB or if its
>>>>> considered
>>>>> something too buggy to use yet.  I've tried creating shipments to
>>>>> fulfill OrderItem ShipGroup schedules multiple ways and have
>>>>> encountered
>>>>> bugs with all of them.  The majority of the bugs relate to incorrect
>>>>> calculation of the OrderItemShipGroupInvRes. OrderItemShipGroupInvRes
>>>>> seems to determine what is allowed to be picked, packed and
>>>>> shipped but
>>>>> can easily contain incorrect information.
>>>>>
>>>>> I tried disabling the Reserve Inventory option of the store but this
>>>>> prevented me from shipping anything.  Does Reserve Inventory have
>>>>> to be
>>>>> enabled to allow shipment capabilities for orders?
>>>>>
>>>>> Is anyone using OFBiz OOTB to handle order shipments?
>>>
>>
>

[Christian Carlow-OFBizzer]

Well I'm back to my first idea of removing the OrderItemShipGrpInvRes
entity.  If removed then "Reserve Method Enum Id" store setting would be
useless but the inventory item assignment operations it performs limits
the amount of control over inventory assignment anyways.  A better
design would be one that doesn't automatically assign new inventory
received to a specific order item like the FIFO, LIFO options.

I need to be able to choose the particular order items to which received
inventory should be assigned and the FIFO and LIFO options prevent it.  
I have complex ship groups associated with order where order items are
scheduled to be shipped in intervals throughout the year.  Therefore the
order of reservation mostly depends on the ship group due date rather
than first order in (FIFO) or last out (LIFO).  For example, I could
have two different orders for the same product and the first order is
scheduled to ship 20 in a week and then 20 more in 5 months while the
second is scheduled to ship 20 in two weeks.  In this case the
reservations should first occur on the first order schedule then the
second order schedule then the first order second schedule. Basically it
would be reserving based on the shipBeforeDate of ship groups associated
with orders.  But adding a new reserve method like FIFO or LIFO to
handle reserving based on ship groups still wont be sufficient for my
needs because there are cases when the user needs  to manually assign
received inventory to an order item regardless of the ship group
shipBeforeDate.  Therefore I think that the inventory reservation code
should be replaced with something that allows such control.

Having a view-entity that joins OrderItemShipGroupAssoc with
ItemIssuances to determine the amount has been shipped seems like the
best solution.  This would allow for a list of ship group with
quantities still left to ship to be generated and inventory could be
assigned manually during picking, packing, and shipping and instead of
automatically based on LIFO, FIFO, etc. when was received.


On 10/24/2013 08:49 AM, Christian Carlow wrote:

> Would someone please provide scenarios where "Reserve Inventory"
> should be set to "N" for a store.  It causes OrderItemShipGrpInvRes
> not to be used so there's no way to ship the order item.  Does this
> mean that "Reserve Inventory" is necessary anytime a store requires
> shipments?
>
> I'm wondering if I should code for allowing "Reserve Inventory" set to
> "N" to allow for creating shipments for order items.
>
> On 10/24/2013 08:05 AM, Christian Carlow wrote:
>> OrderItemShipGrpInvRes seems like it was meant to track backorder
>> information by storing aggregate quantities that could otherwise be
>> calculated by subtracting ItemIssuance records from matching
>> InventoryItem records in the way that InventoryItem quantityOnHand
>> and availableToPromise fields are aggregates of the
>> InventoryItemDetail records.  I suppose that referencing an aggregate
>> quantity would be much faster way to get a value so I'll attempt to
>> fix the without trying to remove the entity.
>>
>> I'm going to start working on this and assume the shipment operations
>> have not yet been completed in any version.
>>
>>
>> On 10/23/2013 04:28 PM, Christian Carlow wrote:
>>> IMO, the OrderItemShipGrpInvRes entity should be removed and
>>> anything referencing it should be changed to derive quantities from
>>> the entities that cause the quantities in OrderItemShipGrpInvRes to
>>> change.
>>>
>>> For example, the Order Items page of the Shipments application bases
>>> the list of items that may be issued to the Shipment on the
>>> OrderItemShipGrpInvRes entity.  I think it should be changed to
>>> generate the list based on the joining of the
>>> OrderItemShipGroupAssoc and ItemIssuance entities and only list
>>> those records that have a remaining quantity greater than 0.
>>>
>>> OrderItemShipGroupAssoc is only used when the store "Reserve
>>> Inventory" setting is set to "Y" and is the only way to create
>>> itemIssuance records.  Without itemIssuances being used there is no
>>> way to ship order items.
>>>
>>> On 10/23/2013 03:30 PM, Christian Carlow wrote:
>>>> Hey Jacques,
>>>>
>>>> Sorry, using 12.04 stable release.
>>>>
>>>> On 10/23/2013 03:28 PM, Jacques Le Roux wrote:
>>>>> Which Release.revision?
>>>>> Though I did not try it recently, I remember it was working in
>>>>> "old" releases.
>>>>>
>>>>> Jacques
>>>>>
>>>>> Christian Carlow wrote:
>>>>>> I was wondering if anyone could tell me whether or not OFBiz's
>>>>>> shipment
>>>>>> capabilities are sophisticated enough to work OOTB or if its
>>>>>> considered
>>>>>> something too buggy to use yet.  I've tried creating shipments to
>>>>>> fulfill OrderItem ShipGroup schedules multiple ways and have
>>>>>> encountered
>>>>>> bugs with all of them.  The majority of the bugs relate to incorrect
>>>>>> calculation of the OrderItemShipGroupInvRes.
>>>>>> OrderItemShipGroupInvRes
>>>>>> seems to determine what is allowed to be picked, packed and
>>>>>> shipped but
>>>>>> can easily contain incorrect information.
>>>>>>
>>>>>> I tried disabling the Reserve Inventory option of the store but this
>>>>>> prevented me from shipping anything.  Does Reserve Inventory have
>>>>>> to be
>>>>>> enabled to allow shipment capabilities for orders?
>>>>>>
>>>>>> Is anyone using OFBiz OOTB to handle order shipments?
>>>>
>>>
>>
>

[Christian Geisert]

Am 23.10.2013 21:53, schrieb Christian Carlow:

> I was wondering if anyone could tell me whether or not OFBiz's shipment
> capabilities are sophisticated enough to work OOTB or if its considered
> something too buggy to use yet.  I've tried creating shipments to
> fulfill OrderItem ShipGroup schedules multiple ways and have encountered
> bugs with all of them.  The majority of the bugs relate to incorrect
> calculation of the OrderItemShipGroupInvRes. OrderItemShipGroupInvRes
> seems to determine what is allowed to be picked, packed and shipped but
> can easily contain incorrect information.
>
> I tried disabling the Reserve Inventory option of the store but this
> prevented me from shipping anything.  Does Reserve Inventory have to be
> enabled to allow shipment capabilities for orders?
>
> Is anyone using OFBiz OOTB to handle order shipments?

Our customer is processing orders (up to 100 line items with product
quantity of 1000s) without any (known) problems.
Shipments are created with "Pack Shipment For Ship Group", sometimes
several shipments per order are created if there is not enough inventory
to fulfill. After pressing "Complete" shipments and orders are created
and everything is done.

We have done a few changes (which should make it into OFBiz) like
invoicing per ShipmentItem and not per ItemIssue and sort order on the
"Pack Order" Screen but nothing concerning shipment IIRC (I'll have a
closer look at the changes)

Christian

[Christian Carlow-OFBizzer]

Hey Christian,

I've tried using the "Pack Shipment for Ship Group" option but encounter
bugs related to OrderItemShipGrpInvRes entity having incorrect
quantities.  I get
this error when trying to Complete the form:

Attempt to pack order failed.
Packed amount does not match reserved amount for item (10211) [4 / 0.000000]

This is caused by the OrderItemShipGrpInvRes entity.  The second number
0 in the error above refers to the quantity field of that entity.  I
need to be able to pack available inventory for any ship group that
might be scheduled.  The problem with doing this is that inventory is
automatically associated with order items when inventory is received and
only those corresponding records in the OrderItemShipGrpInvRes table
with quantityNotAvailable greater than 0 are able to be packed and
associated with the shipment upon completion.

One issue I've created on JIRA explains how OrderItemShipGrpInvRes
quantities can be changed to incorrect values by receiving inventory
into the facility in a certain way:
https://issues.apache.org/jira/browse/OFBIZ-5370?filter=-2

Seems like the whole shipping module needs to be redone.  There are also
plenty of auto-invoicing issues related to shipment statusId getting
changed to Picked or Packed.


On 10/24/2013 10:32 AM, Christian Geisert wrote:

> Am 23.10.2013 21:53, schrieb Christian Carlow:
>> I was wondering if anyone could tell me whether or not OFBiz's shipment
>> capabilities are sophisticated enough to work OOTB or if its considered
>> something too buggy to use yet.  I've tried creating shipments to
>> fulfill OrderItem ShipGroup schedules multiple ways and have encountered
>> bugs with all of them.  The majority of the bugs relate to incorrect
>> calculation of the OrderItemShipGroupInvRes. OrderItemShipGroupInvRes
>> seems to determine what is allowed to be picked, packed and shipped but
>> can easily contain incorrect information.
>>
>> I tried disabling the Reserve Inventory option of the store but this
>> prevented me from shipping anything.  Does Reserve Inventory have to be
>> enabled to allow shipment capabilities for orders?
>>
>> Is anyone using OFBiz OOTB to handle order shipments?
> Our customer is processing orders (up to 100 line items with product
> quantity of 1000s) without any (known) problems.
> Shipments are created with "Pack Shipment For Ship Group", sometimes
> several shipments per order are created if there is not enough inventory
> to fulfill. After pressing "Complete" shipments and orders are created
> and everything is done.
>
> We have done a few changes (which should make it into OFBiz) like
> invoicing per ShipmentItem and not per ItemIssue and sort order on the
> "Pack Order" Screen but nothing concerning shipment IIRC (I'll have a
> closer look at the changes)
>
> Christian
>

[Christian Carlow-OFBizzer]

The auto-invoicing issues mentioned in my last post are caused by cases
where more than one ship group from the same order or items from some
order are grouped into a single shipment.  The shipment creation forms
allow for such data to be created but the configuration is not accounted
for in the invoicing seca logic that happens when Shipment statusIds are
changed to Pick or Pack.  Instead of applying shipping fees based on the
shipGroupSeqId of the order item issued to the shipment, it bases it on
the primaryShipGroupSeqId of the entire shipment.

What should constitute a shipment?  Shipments have a Shipment Route
Segment form for associating multiple destinations with a single
shipment which suggests that it shouldn't necessarily have to be
associated with only one destination but then again the code that
handles shipments references the Shipment primaryOrderId and
primaryShipGroupSeqId fields which suggests otherwise.

IMO multiple destinations should be allowed to be associate to a single
shipment.

On 10/24/2013 11:07 AM, Christian Carlow wrote:

> Hey Christian,
>
> I've tried using the "Pack Shipment for Ship Group" option but
> encounter bugs related to OrderItemShipGrpInvRes entity having
> incorrect quantities.  I get
> this error when trying to Complete the form:
>
> Attempt to pack order failed.
> Packed amount does not match reserved amount for item (10211) [4 /
> 0.000000]
>
> This is caused by the OrderItemShipGrpInvRes entity.  The second
> number 0 in the error above refers to the quantity field of that
> entity.  I need to be able to pack available inventory for any ship
> group that might be scheduled.  The problem with doing this is that
> inventory is automatically associated with order items when inventory
> is received and only those corresponding records in the
> OrderItemShipGrpInvRes table with quantityNotAvailable greater than 0
> are able to be packed and associated with the shipment upon completion.
>
> One issue I've created on JIRA explains how OrderItemShipGrpInvRes
> quantities can be changed to incorrect values by receiving inventory
> into the facility in a certain way:
> https://issues.apache.org/jira/browse/OFBIZ-5370?filter=-2
>
> Seems like the whole shipping module needs to be redone.  There are
> also plenty of auto-invoicing issues related to shipment statusId
> getting changed to Picked or Packed.
>
>
> On 10/24/2013 10:32 AM, Christian Geisert wrote:
>> Am 23.10.2013 21:53, schrieb Christian Carlow:
>>> I was wondering if anyone could tell me whether or not OFBiz's shipment
>>> capabilities are sophisticated enough to work OOTB or if its considered
>>> something too buggy to use yet.  I've tried creating shipments to
>>> fulfill OrderItem ShipGroup schedules multiple ways and have
>>> encountered
>>> bugs with all of them.  The majority of the bugs relate to incorrect
>>> calculation of the OrderItemShipGroupInvRes. OrderItemShipGroupInvRes
>>> seems to determine what is allowed to be picked, packed and shipped but
>>> can easily contain incorrect information.
>>>
>>> I tried disabling the Reserve Inventory option of the store but this
>>> prevented me from shipping anything.  Does Reserve Inventory have to be
>>> enabled to allow shipment capabilities for orders?
>>>
>>> Is anyone using OFBiz OOTB to handle order shipments?
>> Our customer is processing orders (up to 100 line items with product
>> quantity of 1000s) without any (known) problems.
>> Shipments are created with "Pack Shipment For Ship Group", sometimes
>> several shipments per order are created if there is not enough inventory
>> to fulfill. After pressing "Complete" shipments and orders are created
>> and everything is done.
>>
>> We have done a few changes (which should make it into OFBiz) like
>> invoicing per ShipmentItem and not per ItemIssue and sort order on the
>> "Pack Order" Screen but nothing concerning shipment IIRC (I'll have a
>> closer look at the changes)
>>
>> Christian
>>
>

[Christian Carlow-OFBizzer]

I've discovered other features that answer my previous questions about
what should constitute a shipment.

It seems as though the order, ship group, destination, carrier, and ship
method fields of the Shipment entity should be removed. Information such
as shipmentTypeId, statusId, and ship dates seems to be the only
information that packages in a shipment should share.  I'm not entirely
sure if the originFacilityId or partyIdFrom fields should be removed
also but generalizing to allow packages from multiple facilities to
exist in a single shipment seems like it could be valuable functionality.

Packing slip reports which can be generated from the Ship Group widgets
on Order pages list all packages of the shipment but uses the Shipment
entity fields for determining the destination, carrier, and shipping
method.  This suggests that as a rule of thumb, shipments should only
contain packages bound for a single location with a single carrier and
ship method.  However, in the Shipment application, a "Generate Shipment
Manifest Report" button exists which lists all packages of the shipment
but uses the ShipmentRouteSegment information for determining the
destination, carrier, and shipping method.

I referenced this page for determining the difference between a Shipment
Manifest and Packing slip:
http://docs.oracle.com/cd/E39583_01/fscm92pbr0/eng/fscm/sinv/task_CreatingBillsofLadingandShippingManifests-9f23e9.html

Are bills of lading and packing slips considered the same thing? If so
then I think the packing slip report should be changed to only generate
slips for those packages destined for the same location as the ship group.

On 10/24/2013 01:25 PM, Christian Carlow wrote:

> The auto-invoicing issues mentioned in my last post are caused by
> cases where more than one ship group from the same order or items from
> some order are grouped into a single shipment.  The shipment creation
> forms allow for such data to be created but the configuration is not
> accounted for in the invoicing seca logic that happens when Shipment
> statusIds are changed to Pick or Pack. Instead of applying shipping
> fees based on the shipGroupSeqId of the order item issued to the
> shipment, it bases it on the primaryShipGroupSeqId of the entire
> shipment.
>
> What should constitute a shipment?  Shipments have a Shipment Route
> Segment form for associating multiple destinations with a single
> shipment which suggests that it shouldn't necessarily have to be
> associated with only one destination but then again the code that
> handles shipments references the Shipment primaryOrderId and
> primaryShipGroupSeqId fields which suggests otherwise.
>
> IMO multiple destinations should be allowed to be associate to a
> single shipment.
>
> On 10/24/2013 11:07 AM, Christian Carlow wrote:
>> Hey Christian,
>>
>> I've tried using the "Pack Shipment for Ship Group" option but
>> encounter bugs related to OrderItemShipGrpInvRes entity having
>> incorrect quantities.  I get
>> this error when trying to Complete the form:
>>
>> Attempt to pack order failed.
>> Packed amount does not match reserved amount for item (10211) [4 /
>> 0.000000]
>>
>> This is caused by the OrderItemShipGrpInvRes entity.  The second
>> number 0 in the error above refers to the quantity field of that
>> entity.  I need to be able to pack available inventory for any ship
>> group that might be scheduled.  The problem with doing this is that
>> inventory is automatically associated with order items when inventory
>> is received and only those corresponding records in the
>> OrderItemShipGrpInvRes table with quantityNotAvailable greater than 0
>> are able to be packed and associated with the shipment upon completion.
>>
>> One issue I've created on JIRA explains how OrderItemShipGrpInvRes
>> quantities can be changed to incorrect values by receiving inventory
>> into the facility in a certain way:
>> https://issues.apache.org/jira/browse/OFBIZ-5370?filter=-2
>>
>> Seems like the whole shipping module needs to be redone.  There are
>> also plenty of auto-invoicing issues related to shipment statusId
>> getting changed to Picked or Packed.
>>
>>
>> On 10/24/2013 10:32 AM, Christian Geisert wrote:
>>> Am 23.10.2013 21:53, schrieb Christian Carlow:
>>>> I was wondering if anyone could tell me whether or not OFBiz's
>>>> shipment
>>>> capabilities are sophisticated enough to work OOTB or if its
>>>> considered
>>>> something too buggy to use yet.  I've tried creating shipments to
>>>> fulfill OrderItem ShipGroup schedules multiple ways and have
>>>> encountered
>>>> bugs with all of them.  The majority of the bugs relate to incorrect
>>>> calculation of the OrderItemShipGroupInvRes. OrderItemShipGroupInvRes
>>>> seems to determine what is allowed to be picked, packed and shipped
>>>> but
>>>> can easily contain incorrect information.
>>>>
>>>> I tried disabling the Reserve Inventory option of the store but this
>>>> prevented me from shipping anything.  Does Reserve Inventory have
>>>> to be
>>>> enabled to allow shipment capabilities for orders?
>>>>
>>>> Is anyone using OFBiz OOTB to handle order shipments?
>>> Our customer is processing orders (up to 100 line items with product
>>> quantity of 1000s) without any (known) problems.
>>> Shipments are created with "Pack Shipment For Ship Group", sometimes
>>> several shipments per order are created if there is not enough
>>> inventory
>>> to fulfill. After pressing "Complete" shipments and orders are created
>>> and everything is done.
>>>
>>> We have done a few changes (which should make it into OFBiz) like
>>> invoicing per ShipmentItem and not per ItemIssue and sort order on the
>>> "Pack Order" Screen but nothing concerning shipment IIRC (I'll have a
>>> closer look at the changes)
>>>
>>> Christian
>>>
>>
>

[Christian Carlow-OFBizzer]

I think I have enough information about how the shipments should be
handled to start coding.

Here's the plan:

 1. Allow shipments to be created for Stores with "Reserve Inventory"
    setting set to "N"
 2. Allow order items to be issued to Shipment without
    OrderItemShipGrpInvRes entity
      * Additionally allow item issuance quantities to be changed;
        (Currently there is no way to decrement the issuance quantity
        for an item)
 3. Fix packing slip report to only list packages destined for the ship
    group location
 4. Fix auto-invoicing logic to account for different to and from
    parties, destination, carriers, and shipping methods when triggered
    during picking/packing of shipments
 5. Add a due shipments list widget that lists order item ship group
    with quantities not yet shipped and ordered by shipBeforeDate

Anyone have any thoughts about this matter?

On 10/25/2013 09:45 AM, Christian Carlow wrote:

> I've discovered other features that answer my previous questions about
> what should constitute a shipment.
>
> It seems as though the order, ship group, destination, carrier, and
> ship method fields of the Shipment entity should be removed.
> Information such as shipmentTypeId, statusId, and ship dates seems to
> be the only information that packages in a shipment should share.  I'm
> not entirely sure if the originFacilityId or partyIdFrom fields should
> be removed also but generalizing to allow packages from multiple
> facilities to exist in a single shipment seems like it could be
> valuable functionality.
>
> Packing slip reports which can be generated from the Ship Group
> widgets on Order pages list all packages of the shipment but uses the
> Shipment entity fields for determining the destination, carrier, and
> shipping method.  This suggests that as a rule of thumb, shipments
> should only contain packages bound for a single location with a single
> carrier and ship method.  However, in the Shipment application, a
> "Generate Shipment Manifest Report" button exists which lists all
> packages of the shipment but uses the ShipmentRouteSegment information
> for determining the destination, carrier, and shipping method.
>
> I referenced this page for determining the difference between a
> Shipment Manifest and Packing slip:
> http://docs.oracle.com/cd/E39583_01/fscm92pbr0/eng/fscm/sinv/task_CreatingBillsofLadingandShippingManifests-9f23e9.html
>
> Are bills of lading and packing slips considered the same thing? If so
> then I think the packing slip report should be changed to only
> generate slips for those packages destined for the same location as
> the ship group.
>
> On 10/24/2013 01:25 PM, Christian Carlow wrote:
>> The auto-invoicing issues mentioned in my last post are caused by
>> cases where more than one ship group from the same order or items
>> from some order are grouped into a single shipment.  The shipment
>> creation forms allow for such data to be created but the
>> configuration is not accounted for in the invoicing seca logic that
>> happens when Shipment statusIds are changed to Pick or Pack. Instead
>> of applying shipping fees based on the shipGroupSeqId of the order
>> item issued to the shipment, it bases it on the primaryShipGroupSeqId
>> of the entire shipment.
>>
>> What should constitute a shipment?  Shipments have a Shipment Route
>> Segment form for associating multiple destinations with a single
>> shipment which suggests that it shouldn't necessarily have to be
>> associated with only one destination but then again the code that
>> handles shipments references the Shipment primaryOrderId and
>> primaryShipGroupSeqId fields which suggests otherwise.
>>
>> IMO multiple destinations should be allowed to be associate to a
>> single shipment.
>>
>> On 10/24/2013 11:07 AM, Christian Carlow wrote:
>>> Hey Christian,
>>>
>>> I've tried using the "Pack Shipment for Ship Group" option but
>>> encounter bugs related to OrderItemShipGrpInvRes entity having
>>> incorrect quantities.  I get
>>> this error when trying to Complete the form:
>>>
>>> Attempt to pack order failed.
>>> Packed amount does not match reserved amount for item (10211) [4 /
>>> 0.000000]
>>>
>>> This is caused by the OrderItemShipGrpInvRes entity.  The second
>>> number 0 in the error above refers to the quantity field of that
>>> entity.  I need to be able to pack available inventory for any ship
>>> group that might be scheduled.  The problem with doing this is that
>>> inventory is automatically associated with order items when
>>> inventory is received and only those corresponding records in the
>>> OrderItemShipGrpInvRes table with quantityNotAvailable greater than
>>> 0 are able to be packed and associated with the shipment upon
>>> completion.
>>>
>>> One issue I've created on JIRA explains how OrderItemShipGrpInvRes
>>> quantities can be changed to incorrect values by receiving inventory
>>> into the facility in a certain way:
>>> https://issues.apache.org/jira/browse/OFBIZ-5370?filter=-2
>>>
>>> Seems like the whole shipping module needs to be redone. There are
>>> also plenty of auto-invoicing issues related to shipment statusId
>>> getting changed to Picked or Packed.
>>>
>>>
>>> On 10/24/2013 10:32 AM, Christian Geisert wrote:
>>>> Am 23.10.2013 21:53, schrieb Christian Carlow:
>>>>> I was wondering if anyone could tell me whether or not OFBiz's
>>>>> shipment
>>>>> capabilities are sophisticated enough to work OOTB or if its
>>>>> considered
>>>>> something too buggy to use yet.  I've tried creating shipments to
>>>>> fulfill OrderItem ShipGroup schedules multiple ways and have
>>>>> encountered
>>>>> bugs with all of them.  The majority of the bugs relate to incorrect
>>>>> calculation of the OrderItemShipGroupInvRes. OrderItemShipGroupInvRes
>>>>> seems to determine what is allowed to be picked, packed and
>>>>> shipped but
>>>>> can easily contain incorrect information.
>>>>>
>>>>> I tried disabling the Reserve Inventory option of the store but this
>>>>> prevented me from shipping anything.  Does Reserve Inventory have
>>>>> to be
>>>>> enabled to allow shipment capabilities for orders?
>>>>>
>>>>> Is anyone using OFBiz OOTB to handle order shipments?
>>>> Our customer is processing orders (up to 100 line items with product
>>>> quantity of 1000s) without any (known) problems.
>>>> Shipments are created with "Pack Shipment For Ship Group", sometimes
>>>> several shipments per order are created if there is not enough
>>>> inventory
>>>> to fulfill. After pressing "Complete" shipments and orders are created
>>>> and everything is done.
>>>>
>>>> We have done a few changes (which should make it into OFBiz) like
>>>> invoicing per ShipmentItem and not per ItemIssue and sort order on the
>>>> "Pack Order" Screen but nothing concerning shipment IIRC (I'll have a
>>>> closer look at the changes)
>>>>
>>>> Christian
>>>>
>>>
>>
>

[Adrian Crum-3]

If this is something you intend to contribute to the project, then I
suggest you copy it to the dev mailing list for further comment.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/25/2013 8:26 AM, Christian Carlow wrote:

> I think I have enough information about how the shipments should be
> handled to start coding.
>
> Here's the plan:
>
> 1. Allow shipments to be created for Stores with "Reserve Inventory"
>     setting set to "N"
> 2. Allow order items to be issued to Shipment without
>     OrderItemShipGrpInvRes entity
>       * Additionally allow item issuance quantities to be changed;
>         (Currently there is no way to decrement the issuance quantity
>         for an item)
> 3. Fix packing slip report to only list packages destined for the ship
>     group location
> 4. Fix auto-invoicing logic to account for different to and from
>     parties, destination, carriers, and shipping methods when triggered
>     during picking/packing of shipments
> 5. Add a due shipments list widget that lists order item ship group
>     with quantities not yet shipped and ordered by shipBeforeDate
>
> Anyone have any thoughts about this matter?
>
> On 10/25/2013 09:45 AM, Christian Carlow wrote:
>> I've discovered other features that answer my previous questions about
>> what should constitute a shipment.
>>
>> It seems as though the order, ship group, destination, carrier, and
>> ship method fields of the Shipment entity should be removed.
>> Information such as shipmentTypeId, statusId, and ship dates seems to
>> be the only information that packages in a shipment should share.  I'm
>> not entirely sure if the originFacilityId or partyIdFrom fields should
>> be removed also but generalizing to allow packages from multiple
>> facilities to exist in a single shipment seems like it could be
>> valuable functionality.
>>
>> Packing slip reports which can be generated from the Ship Group
>> widgets on Order pages list all packages of the shipment but uses the
>> Shipment entity fields for determining the destination, carrier, and
>> shipping method.  This suggests that as a rule of thumb, shipments
>> should only contain packages bound for a single location with a single
>> carrier and ship method.  However, in the Shipment application, a
>> "Generate Shipment Manifest Report" button exists which lists all
>> packages of the shipment but uses the ShipmentRouteSegment information
>> for determining the destination, carrier, and shipping method.
>>
>> I referenced this page for determining the difference between a
>> Shipment Manifest and Packing slip:
>> http://docs.oracle.com/cd/E39583_01/fscm92pbr0/eng/fscm/sinv/task_CreatingBillsofLadingandShippingManifests-9f23e9.html
>>
>>
>> Are bills of lading and packing slips considered the same thing? If so
>> then I think the packing slip report should be changed to only
>> generate slips for those packages destined for the same location as
>> the ship group.
>>
>> On 10/24/2013 01:25 PM, Christian Carlow wrote:
>>> The auto-invoicing issues mentioned in my last post are caused by
>>> cases where more than one ship group from the same order or items
>>> from some order are grouped into a single shipment.  The shipment
>>> creation forms allow for such data to be created but the
>>> configuration is not accounted for in the invoicing seca logic that
>>> happens when Shipment statusIds are changed to Pick or Pack. Instead
>>> of applying shipping fees based on the shipGroupSeqId of the order
>>> item issued to the shipment, it bases it on the primaryShipGroupSeqId
>>> of the entire shipment.
>>>
>>> What should constitute a shipment?  Shipments have a Shipment Route
>>> Segment form for associating multiple destinations with a single
>>> shipment which suggests that it shouldn't necessarily have to be
>>> associated with only one destination but then again the code that
>>> handles shipments references the Shipment primaryOrderId and
>>> primaryShipGroupSeqId fields which suggests otherwise.
>>>
>>> IMO multiple destinations should be allowed to be associate to a
>>> single shipment.
>>>
>>> On 10/24/2013 11:07 AM, Christian Carlow wrote:
>>>> Hey Christian,
>>>>
>>>> I've tried using the "Pack Shipment for Ship Group" option but
>>>> encounter bugs related to OrderItemShipGrpInvRes entity having
>>>> incorrect quantities.  I get
>>>> this error when trying to Complete the form:
>>>>
>>>> Attempt to pack order failed.
>>>> Packed amount does not match reserved amount for item (10211) [4 /
>>>> 0.000000]
>>>>
>>>> This is caused by the OrderItemShipGrpInvRes entity.  The second
>>>> number 0 in the error above refers to the quantity field of that
>>>> entity.  I need to be able to pack available inventory for any ship
>>>> group that might be scheduled.  The problem with doing this is that
>>>> inventory is automatically associated with order items when
>>>> inventory is received and only those corresponding records in the
>>>> OrderItemShipGrpInvRes table with quantityNotAvailable greater than
>>>> 0 are able to be packed and associated with the shipment upon
>>>> completion.
>>>>
>>>> One issue I've created on JIRA explains how OrderItemShipGrpInvRes
>>>> quantities can be changed to incorrect values by receiving inventory
>>>> into the facility in a certain way:
>>>> https://issues.apache.org/jira/browse/OFBIZ-5370?filter=-2
>>>>
>>>> Seems like the whole shipping module needs to be redone. There are
>>>> also plenty of auto-invoicing issues related to shipment statusId
>>>> getting changed to Picked or Packed.
>>>>
>>>>
>>>> On 10/24/2013 10:32 AM, Christian Geisert wrote:
>>>>> Am 23.10.2013 21:53, schrieb Christian Carlow:
>>>>>> I was wondering if anyone could tell me whether or not OFBiz's
>>>>>> shipment
>>>>>> capabilities are sophisticated enough to work OOTB or if its
>>>>>> considered
>>>>>> something too buggy to use yet.  I've tried creating shipments to
>>>>>> fulfill OrderItem ShipGroup schedules multiple ways and have
>>>>>> encountered
>>>>>> bugs with all of them.  The majority of the bugs relate to incorrect
>>>>>> calculation of the OrderItemShipGroupInvRes. OrderItemShipGroupInvRes
>>>>>> seems to determine what is allowed to be picked, packed and
>>>>>> shipped but
>>>>>> can easily contain incorrect information.
>>>>>>
>>>>>> I tried disabling the Reserve Inventory option of the store but this
>>>>>> prevented me from shipping anything.  Does Reserve Inventory have
>>>>>> to be
>>>>>> enabled to allow shipment capabilities for orders?
>>>>>>
>>>>>> Is anyone using OFBiz OOTB to handle order shipments?
>>>>> Our customer is processing orders (up to 100 line items with product
>>>>> quantity of 1000s) without any (known) problems.
>>>>> Shipments are created with "Pack Shipment For Ship Group", sometimes
>>>>> several shipments per order are created if there is not enough
>>>>> inventory
>>>>> to fulfill. After pressing "Complete" shipments and orders are created
>>>>> and everything is done.
>>>>>
>>>>> We have done a few changes (which should make it into OFBiz) like
>>>>> invoicing per ShipmentItem and not per ItemIssue and sort order on the
>>>>> "Pack Order" Screen but nothing concerning shipment IIRC (I'll have a
>>>>> closer look at the changes)
>>>>>
>>>>> Christian
>>>>>
>>>>
>>>
>>
>
>