Adding Change Log Entry when I change a date on the Order Release through code

We are setting up a BPM to change the Sales Order Release Need By Date when we change the related Job Req By date. These are only for our big jobs related to our major units, but I would also like the code to add an audit entry to the Order, so when someone looks at the order, they will see the related change entries. Here is the relevant code that is being run whenever the Job is changed:

// this.PublishInfoMessage("Starting Custom Code", Ice.Common.BusinessObjectMessageType.Warning, Ice.Bpm.InfoMessageDisplayMode.Individual, "Update", "Update");

//var ttJobProdRow = (from ttJobProdRowx in ttJobProd
//select ttJobProdRowx).FirstOrDefault();

var ttJobHeadRow = ttJobHead.FirstOrDefault();

if( ttJobHeadRow != null )
{
string jobNum = (string)ttJobHeadRow["JobNum"];
DateTime reqDueDate = (DateTime)ttJobHeadRow["ReqDueDate"];

// this.PublishInfoMessage("ttJobHeadRow is NOT null - " + reqDueDate.Date() , Ice.Common.BusinessObjectMessageType.Warning, Ice.Bpm.InfoMessageDisplayMode.Individual, "Update", "Update");

foreach(var result in(
        from jp_row in Db.JobProd.With(LockHint.UpdLock) 
        where jp_row.Company==Session.CompanyID && jp_row.JobNum == jobNum 
        select new {jp_row}))

if( result.jp_row != null )
{
	// if( result.jp_row != null ) result.jp_row.NeedByDate = ReqDueDate;
	    int oNum = (int)result.jp_row.OrderNum;
	    int oLine = (int)result.jp_row.OrderLine;
	    int oRel = (int)result.jp_row.OrderRelNum;
		
    // this.PublishInfoMessage("ttJobProdRow is NOT null - " + oNum, Ice.Common.BusinessObjectMessageType.Warning, Ice.Bpm.InfoMessageDisplayMode.Individual, "Update", "Update");
    
		foreach(var order in(
        from or_row in Db.OrderRel.With(LockHint.UpdLock) 
        where or_row.Company==Session.CompanyID && or_row.OrderNum==oNum && or_row.OrderLine==oLine && or_row.OrderRelNum==oRel
        select new {or_row}))

        using (var txscope = IceDataContext.CreateDefaultTransactionScope())
        {
            if( order.or_row != null )
                order.or_row.NeedByDate = reqDueDate;
    
            txscope.Complete();
        }
    
}
}

If anybody has a better way of accomplishing the same thing, I can rethink my methodology. Thanks for any comments and suggestions you can throw my way.

Hi Paul, You may be better using the Sales Order Business Object method, rather than setting the field directly. This is for two reasons, one you are ensuring that all appropriate business rules are followed when using the correct “ChangeNeedByDate” (or similar) method on the Sales Order Business Object, and also I believe the change log will then be able to track this - not sure if it will work updating the DB directly. Finally - I would add: updating fields directly is not really a recommended way of doing things. I would go the the Sales Order Form, switch trace logging on and then change the need by date before viewing the log to see the method call and replicating that in your BPM.

3 Likes

Doesn’t the ChangeNeedByDate apply to the Order Header or Order line though? I am looking at doing it that way, but I need it changed on the release. I am still working through that process.

I am not near my VM so I cant say exactly Paul. That may well be the case in that there is more than one way to skin this cat, however – just a point to note about the change logging – if you wish to track this change in release dates within Epicor then you could use a BPM Directive to do that – it might work with a Db.Validate if you update the field directly. I believe it is data directive based.

It may be that what you are doing is fine within context – but it is important to be aware that additional business logic might be triggered in the BO when that particular field is changed. It’s a “best practice” approach but ignored when updating UD fields and the like…. :wink:

I am seeing what I can do with the context and business objects, Now to search for the code to do that process. Thanks for the advice, I am always willing to learn the best practice methodology.

To be honest - I dont see anything majorly wrong with the coding conventions you have used to modify the Date at this point, (Taking into consideration the standard business logic, discussed above)

Everybody has their own style but you are generally in the right ballpark.

WRT: change logging, Or tracking the fields that are being changed, I believe that will be a data directive - in-transaction i think, due to the fact that data ios or has been changed.

@Paul_Millsaps

Silly question, but do you have the fields you want in the tracked in your Change Log BPM?

That’s what I ended up doing, I thought they were in there already, but apparently they were not. Because I could not reference 2 BO’s with the same tables in them, I had to revert to the direct database change for the date,and once I added in the Logging BPM, it started logging also, so it looks like it is solved for now. Thanks everyone for your help.

1 Like