Re: OFBiz Shipment operations too buggy to use: Project Outline

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

Re: OFBiz Shipment operations too buggy to use: Project Outline

Christian Carlow-OFBizzer
Thank Adrian,  good idea.

Here is the project I will be working on for dev community reference.  I
will be adding more JIRA issues related to this project.  Some bugs and
improvements have already been created by me on JIRA.

On 10/25/2013 10:30 AM, Adrian Crum wrote:

> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>>