[jira] [Comment Edited] (OFBIZ-5761) Allow to edit ship groups contents after and order has been created

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

[jira] [Comment Edited] (OFBIZ-5761) Allow to edit ship groups contents after and order has been created

Nicolas Malin (Jira)

    [ https://issues.apache.org/jira/browse/OFBIZ-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14130655#comment-14130655 ]

Jacques Le Roux edited comment on OFBIZ-5761 at 9/11/14 8:32 PM:
-----------------------------------------------------------------

Mmm, some time ago I noticed something I since forgot to tackle in addOrderItemShipGroup service.

I guess because of setEstimatedDeliveryDates service (a ProductionRunService) and initMrpEvents, the addon had this block
{code}
        //shipByDate is mandatory
        if (context.get("estimatedShipDate") == null) {
            context.put("shipByDate", UtilDateTime.nowTimestamp());
        } else {
            context.put("shipByDate", context.get("estimatedShipDate"));
        }
       
        // set estimatedDeliveryDate with estimatedShipDate
        context.put("estimatedDeliveryDate", context.get("estimatedShipDate"));
{code}

The shipByDate field is *NOT mandatory* and why would we want to ship "now"? This does not make any sense to me. I guess it was needed in older OFBiz versions of OFBiz manufacturing,  but is no longer (I checked). We could set now to shipAfterDate, but I see no reasons to force one or the other. I thought about adapting that block in a new patch with this block:

{code}
        // set estimatedDeliveryDate and shipByDate with estimatedShipDate if it exists
        Timestamp estimatedShipDate = (Timestamp) context.get("estimatedShipDate");
        if (estimatedShipDate != null) {
            context.put("estimatedDeliveryDate", estimatedShipDate);
            context.put("shipByDate", estimatedShipDate);
        }
{code}

But when you look at it there are no existing ways to pass an estimatedShipDate to the addOrderItemShipGroup service. So I believe we should simply remove the block, opinions?


was (Author: jacques.le.roux):
Mmm, some time ago I noticed something I since forgot to tackle in addOrderItemShipGroup service.

I guess because of setEstimatedDeliveryDates service (a ProductionRunService) and initMrpEvents, the addon had this block
{code}
        //shipByDate is mandatory
        if (context.get("estimatedShipDate") == null) {
            context.put("shipByDate", UtilDateTime.nowTimestamp());
        } else {
            context.put("shipByDate", context.get("estimatedShipDate"));
        }
       
        // set estimatedDeliveryDate with estimatedShipDate
        context.put("estimatedDeliveryDate", context.get("estimatedShipDate"));
{code}

The shipByDate field is *NOT mandatory* and why would we want to ship "now"? This does not make any sense to me. I guess it was needed in older OFBiz versions of OFBiz manufacturing,  but is no longer (I checked). We could set now to shipAfterDate, but I see no reasons to force one or the other. I thought about adapting that block in a new patch with this block:

{code}
        // set estimatedDeliveryDate and shipByDate with estimatedShipDate if it exists
        if (context.get("estimatedShipDate") == null) {
            context.put("estimatedDeliveryDate", context.get("cv"));
            context.put("shipByDate", context.get("estimatedShipDate"));
        }
{code}

But when you look at it there are no existing ways to pass an estimatedShipDate to the addOrderItemShipGroup service. So I believe we should simply remove the block, opinions?

> Allow to edit ship groups contents after and order has been created
> -------------------------------------------------------------------
>
>                 Key: OFBIZ-5761
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-5761
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: order
>    Affects Versions: Trunk
>            Reporter: Jacques Le Roux
>            Assignee: Jacques Le Roux
>             Fix For: Upcoming Branch
>
>         Attachments: OFBIZ-5761 - OISG Management.patch, OFBIZ-5761 - OISG Management.patch, OFBIZ-5761 - OISG Management.patch.change
>
>
> Currently you can only move order items between ship groups while you create an order. I needed to do it after order creation. When I met Olivier (Heintz) at the RMLL 2014 in July, I found the Neogia team has developed a such feature and had it as an addon (named oisg-management) for R12.04. Then exchanging with Nicolas (Malin), and Pierre (Gaudin) I decided to give it a go. I will quickly explain the following history, for the Neogia team to know the current situation and what has changed.
> After updating the code to work with current trunk (instead of R12.04) I found it was working well but some minor issues. I then exchanged with Leila (Mekika) from the Neogia team and we could quickly fix the minor issues:
> * text harcoded, no labels. I began to fix them, thanks to Leila who completed the major part and explained me some tricks about the oisg-management addon.
> * A redundant button associated with the new addOrderItemShipGroup service.  I removed it because the current button calls createOrderItemShipGroup which is enough. We could BTW consider using addOrderItemShipGroup instead. It's more complete (see below for instance) but that"s rather a matter of taste.
> There was a mechanism to merge sales taxes to get them grouped by ship groups in order adjustments. I removed it because this can be done dynamically (see invoice.pdf) and it was removing the shipGroupSeqId from the order adjustments.
> I sorted (DESC) the OrderItemShipGroup in addOrderItemShipGroup in order to use the 1st ship group when copying shipmentMethodTypeId, carrierPartyId, carrierRoleTypeId, contactMechId when shipmentMethodTypeId and carrierPartyId are not passed to the service.
> I later fixed a bug I found in loadCartForUpdate service when removing the adjustments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)