I guess its my week for being stumped by odd kinetic problems. We have a BPM that calculates the weight of a sales order and stores it in a UD field on the order header. Occasionally, for 2 users, the routine starts maxing at 99,999, so it will store the order weight as 99,999 when it ought to be, for example, 233,000 or something like that. The last time this happened, I had them clear the cache, and the calculation started working properly again. Now, a month or so later, it has suddenly started happening again (and clearing the cache has fixed it again).
If I could trigger the BPM to calculate incorrectly on my computer, I feel like I could get to the bottom of this, but since its not reproducible I am left with speculation (or perhaps some better logging).
The UD field is decimal(20,9). The total weight variable in the BPM is also decimal (but you can’t set any particulars in a BPM variable). The code part of the BPM that is actually calculating the weight is:
var TotalWeight = (from orderDtl in Db.OrderDtl
join part in Db.Part on new { orderDtl.PartNum, orderDtl.Company } equals new { part.PartNum, part.Company }
where orderDtl.OrderNum == callContextBpmData.Number04 && orderDtl.VoidLine == false
select orderDtl.OrderQty * part.NetWeight
).ToList().Sum();
using (var txScope = IceContext.CreateDefaultTransactionScope()){
var OrderHed = Db.OrderHed.With(LockHint.UpdLock).Where(x=>
x.Company == Session.CompanyID &&
x.OrderNum == callContextBpmData.Number04).FirstOrDefault();
if (OrderHed != null){
OrderHed.Number02 = Convert.ToDecimal(TotalWeight);
}
Db.Validate();
txScope.Complete();
}
CallContext field can be overwritten if a In-Tran Directive fires and utilizes them. I would check to see where else you may be using Number04. It could also be a BO that the BASE may be triggering.
What I mean, if you set it inside of a PRE and try to use it in a POST but however a In-Tran fires in between, it can override it.
Not sure, shouldn’t. Your code looks good. I spent a decent amount of time in studying Epicor’s decimal precision, there is nothing I see that could be causing it besides another BPM overwriting it, a Customization overwriting it or Number04 pointing somehow to the wrong order.
So just out of curiosity, I ran my own query to calculate the weight of every sales order in the system. There are zero sales orders with a calculated weight of 99,999, so I don’t think that it is somehow calculating the weight of some other order. I also can’t find any references to Number04 in any of the directives on OrderDtl.
I also don’t believe another BPM is overwriting the UD field, because at the time the problem is occurring, I can watch on the user’s computer and see the calculation happening incorrectly (so its not like it was correct, and then later we come back and the number was changed and we don’t know how).
Do you have any suggestions for what logging I could add to the code that might provide any sort of clue the next time it happens?
Its Erp.BO.SalesOrder.Update. I’ve changed it to just get the ordernum directly in post instead of using Number04. I guess nothing to do but wait and see if it happens again.
Probably better than relying on Number04 since it can be “adjusted” for you by another BPM or even another process. I experienced this in the past, and don’t like to rely on those because some other programmer can break your bpm without touching it.
If the BPM is creating/altering the value in the UD field and does the Number04 field have a default value of 99,999? It could be that the math is failing, and the default value is not getting overwritten by the correct value.
Specifically where clearing the cache makes the problem go away? Or just the general problem of the bpm context data getting overwritten.
As I’ve described above, I can’t conceive of how Number04 getting overwritten would produce what I’m seeing - for that theory to work, then there must be some OTHER order in the system where the weight calculates to 99,999, and all these other orders are somehow accidentally calculating the weight for that order instead of the correct one, yet somehow updating the UD field for the correct order number? It doesn’t make any sense.
Im with you because if your Number04 changed then it would have updated the total for the wrong OrderNum. I am not sure, what could be the culprit. If you are using the Kinetic UI maybe there is some Angular/JS form bug with it. If you are using the Classic, I’ve never seen it. Stumped for sure.
The first step in the post processing directive is to set the value of the total weight variable to 0, the idea being that if the calculation fails, then the order weight should still get set to zero.
I don’t see that there is a default on that column in the table but I don’t know if there could be a default somewhere else that I’m missing?
The order weight never calculated properly before either (when we were using classic) but at that time it was being done with UI code, so its hard to compare as the two things changed at the same time.
Out of curiosity on the Kinetic UI, what do you have your input box set to, does it have a format setting. Feels a bit as if it is setting the format/mask as the value, 99,999, or does it also set the value in the database? (then I guess we can rule out a input)
True - sorry if I missed that earlier. As for default value, UD Column Maintenance and Extended Properties can contain a default Init value (from when you created the column.
