So what you could possibly do is look for in post process the response containing “credit hold” so you really isolate what you do this on. Then if you find that string in the message call MasterUpdate again passing those first two params as false instead of true. Dicey though as you’ll be calling MasterUpdate in post of MasterUpdate. It could go really far south on you.
Easier and safer would be to make those false on the preprocess side, but i’m not sure what other message you might suppress then.
@shobdy I confirmed if you set the lCheckForOrderChangedMsg and lcheckForResponse flags as false in preprocess and cResponseMsg as string.Empty on post process it works as expected, but again it’s hard to know what else you might be bypassing.
No that tells the BO when you call MasterUpdate that there are things it needs to be aware of. That actually needs to be false for the credit logic to be skipped. The dialog being yes or no only happens locally in the screenshot above yes and no only allows the UI to make it through the update method in oTrans. If it makes it through update without you clicking “No” or other flags returning false from oTrans.Update it calls Update again with the first two flag false.
All in all it’s a horribly inefficient design and can explain why you see UpdateMaster called a lot. It controls a lot of this nonsense.
What it’s doing right now is
adapter.MasterUpdate(true, true, “OrderDtl”,…)
That will set the cResponseMessage looking for input from the user and skip adding the order line to the database.
If you click “No” it just drops out and nothing happens, if you click “Yes” it will run master update again like this adapter.MasterUpdate(false, false, “OrderDtl”,…)
at which time it skips the checking and alerting logic and adds the order line.
@jgiese.wci Thanks for getting to the bottom of this… well done. Are all your observations made from v10.2.600.10 per your profile? I forget which version Aging Holds was released in, but if it’s after what you’re in then you should know Aging Holds get shoehorned into this mess too…
Also,
Can anyone think of any specific dangers here? Would prefer to avoid doing this now that we know how messy it could get, but on the other hand the pop-up can be so onerous for users that it may be worth the risks.
.32 pretty sure but yeah same Minor version still 600. The source I was looking at was from 400, but my debug tests were with DnSpy on my live version, doesn’t look like it has changed.
OK… this looks familiar… I think that THIS is the same approach I did in the past. By setting the credit limit message to blank, it stops the message from being displayed by the UI.
I don’t think that will work for this. The credit check is private to the SalesOrderService it wouldn’t get the pre-post BPM stuff applied to it as it happens in the magic sauce server.
Below is the whole MasterUpdate from the service
I’ve isolated line dtl update since that’s the context here anyways but it
Does the checks agaisnt OrderDtl
Checks credit limit for the line once it determines the safety net of is there a line is good
Sets the response message from the credit check to cResponseMsg
If response message is null or empty it does the internal Service.Update and finishes up the save, if cResponseMsg is set it bombs out without ever running Service.Update
Knowing that in MasterUpdate if cResponseMsg is not empty that it just skips the Update call you could in PostProcess of MasterUpdate catch if cResponseMsg contains “Credit Hold” and if it does call the SalesOrderService.Update method and pass it the DS yourself. Not sure if it would work or not but you could try it and see what you get.
Below are the contents of the final step of MasterUpdate if cResponseMsg and Agging message are empty
if (String.IsNullOrEmpty(cResponseMsg) && String.IsNullOrEmpty(cAgingMessage))
{
var proxy = Ice.Assemblies.ServiceRenderer.GetService<Erp.Contracts.SalesOrderSvcContract>(Db);
proxy.Update(ref ds);
//Update(ref ds);
if (OrderHed != null && iOrderNum == 0)
{
iOrderNum = OrderHed.OrderNum;
}
if (OrderHed == null)
{
if (iOrderNum == 0)
{
ttOrderHed = (from ttOrderHed_Row in ds.OrderHed
where modList.Lookup(ttOrderHed_Row.RowMod, ',') == -1
select ttOrderHed_Row).FirstOrDefault();
iOrderNum = ttOrderHed.OrderNum;
}
OrderHed = this.FindFirstOrderHed2(Session.CompanyID, iOrderNum);
}
if (lweLicensed == true && cTableName.Compare("OrderHed") == 0 && OrderHed.ReadyToCalc == true)
{
this.chkComplianceOrderFail(iOrderNum, out cCompliantMsg);
}
/* CheckLtrOfCrdt Logic */
bufOrderHed = this.FindFirstOrderHed2(Session.CompanyID, iOrderNum);
if (bufOrderHed == null)
{
throw new BLException(Strings.UnableToFindOrderHedRecord, "OrderHed");
}
cARLOCID = bufOrderHed.ARLOCID;
dTotalCharges = bufOrderHed.DocOrderAmt;
this.chkLtrOfCrdt(iOrderNum, cARLOCID, dTotalCharges, out cDisplayMsg);
if (orderHedUpdated == true)
{
ds = CurrentFullTableset;
}
else
{
if (ttOrderDtl != null)
cResponseMsg = ttOrderDtl.RespMessage;
else if (ttOrderMsc != null)
cResponseMsg = ttOrderMsc.RespMessage;
else if (ttOHOrderMsc != null)
cResponseMsg = ttOHOrderMsc.RespMessage;
}
}
Thanks for detailing this, I need to learn how to get this deep into a process.
I had to do something like what you are saying and just handle the call myself when it came to the “get next lot” button on receipt entry. I had to make the click call the business objects and fill out the datasets manually because there was some magic baked into the native button or server level that I couldn’t bypass by using a pre or post method.
@jgiese.wci I think it is the EpiMagic that makes it work. When the ICustomerAllowed is set to true Epicor then calls OverCreditLimitUpdateAllowed and the Credit Override gets set in green on the header which I assume makes it never check in Master Update
This is in my server log just after the bpm fires.
act=“Erp:BO:SalesOrder/SalesOrderSvcContract/OverCreditLimitUpdateAllowed”
Your BPMs would all work great for the order header annoying alerts but he is specifically talking about this one when entering lines.
All of that logic is self contained in the MasterUpdate and in private methods. I employed your BPMs noted above with the MasterUpdate modifications to hide the OrderDtl dialog and it behaves the same way.
@jgiese.wci Well that is frustrating. I just did a new order for a customer on hold and over their credit limit and not a peep on adding a new line. In our company config the Credit Aging Limit Actions are set to Warn and not Stop. Maybe that is what allows us to skate by?
We have warn order, stop shipment and additionally “ignore” under finance. Warn is what we are seeing though when it asks are you sure you want to continue so that makes sense.
Sorry to bring up an old post but I am running into the same exact issue and wondered if anyone found a work around on this?
I am currently working on a method to track reason codes for Ship By date changes and writing results to a UD table. The BPM form fires on the SalesOrder.masterupdate (Update doesn’t work constantly) When a customer is on credit hold this message will appear. If they select Yes, the masterupdate BO runs again prompting the BPM to fire again. This not only requires the reason to be selected twice, it results in double the records in the UD table storing the changes.
Thanks for the reply. That doesn’t work in this case on MasterUpdate. I have those exact settings. In the case of an On Hold customer, it suppresses the message but the update fails to run. It appears to be updated on screen but a refresh will revert to the old data. In my case, the pre process bpms invoke BO ice.ud.update runs and updates the UD table but sales order remains unchanged.
@cmulford I don’t know if this would work and it is not the best way to handle , but one of the things that @timshuwy explained about using updateExt was that an add and an update look the same. I wonder if you set the same keys, but used updateExt rather than update would it just update the record you had previously written.
Does not solve the double call or the popup, but would stop the duplication.
UpdateExt doesn’t fire and using Update has the same issues as this thread when using a BPMForm. Master seems my only choice but the hold message causing it to fire twice is causing quite a pickle.
, but one of the things that