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
