Epicor version 10.1.400.18
I’ve added a checkbox to the Summary tab of the Sales Order Entry form. I bound the checkbox to a UD field named CheckBox14:
I created a customization to check the checkbox:
SalesOrderAdapter oAdpt = new SalesOrderAdapter(UD36Form);
oAdpt.BOConnect();
Int OrderNum = 8560;
bool GotOrder = oAdpt.GetByID(OrderNum);
if (GotOrder == true)
{
oAdpt.SalesOrderData.OrderHed.Rows[0][“CheckBox14”] = true;
oAdpt.Update();
}
oAdpt.Dispose();
This does not change the value of the checkbox.
Using the method MasterUpdate does not either.
Checking the out messages from MasterUpdate only has one value. “Continue = true”
What am I doing wrong here? A trace does not reveal anything and this worked in VB.Net before converting the code.
When I run a trace using Master Update, with or without the RowMod statement, it shows:
Table Name = OrderHed
Row Number = 0
Column Name = CheckBox14
State = Modified
Value = True
But Sales Order Entry does still shows unchecked and SQL shows a value of zero.
Looking at your original post again, I’m not sure what you’re trying to achieve.
If you’ve added a UD field to OrderHed, adding a checkbox to Sales Order Entry and binding it to your UD field shouldn’t need any code at all. It will just update with everything else when the user clicks save. Am I missing something?
Yes. Yes you are. I didn’t really want to explain the reasons but I’ll give you a short version.
This check box is to prevent any changes made to commissions. We not only have a customer on a Sales Order, but we have a customer, owner, and engineer. Each treated as a customer. Each has a Sales Person with a commission percentage which may be different from the others. We do not pay commissions on commission and we do not pay commission on freight. It’s a very complicated procedure to figure commissions. We have a customization on the sales order to figure commission for each sales person. We also have a customization on the UD36 form to run once a month. It goes through three criteria to verify the commissions are ready to pay. Then it gets the Final Freight numbers and recalculates commissions. After we save the sales order after calculating the final commission, the customization checks the CheckBox14 checkbox which stops further calculations on commissions. The reason we do it is not really the issue but I understand you asking why someone would want to do something as ridiculous at this.
Right, I get the general idea, and I know there are always cases which seem strange on the surface but are the endpoint of corporate logic!
But in this case, is there anything to stop you setting the checkbox in the EpiDataView directly then doing oTrans.Update()? From the user’s perspective there would be no difference, and it would avoid complications with row-locks etc from having the order open and trying to update it separately.
No. I guess there is nothing stopping me from moving the customization from UD36 form to the Sales Order Entry form except security. We only want the accountants to run the customization.
I guess I could make a copy of Sales Order Entry and move it to another area in the menu or check the User before running the customization. Seems odd to have to do all this to change a UD field. Almost makes me want to go ‘renegade’ and change it using SQL.
I’ve never had this issue before. I wonder if it would force an update if I change a non-UD field along with the UD field. Going to try that.
But there is a sledgehammer you can use short of the nuclear weapon that is direct SQL change, and we do fall back on it when the only thing we’re changing is a UD field or UD table.
using (var txScope = IceContext.CreateDefaultTransactionScope())
{
foreach(var UD01 in (from row in Db.UD01.With(LockHint.UpdLock) where
row.Company == Session.CompanyID && row.Key1 == "12345"
select row))
{
UD01.ShortChar01 = "abcde";
}
Db.Validate();
txScope.Complete();
}
Although thinking about it again, I think my approach to this whole problem would probably be an updateable BAQ. You could either replace the UD36 form with a deployed dashboard or bring the UBAQ into the UD36 form via DynamicQuery, which we do quite a bit. It’s probably more cumbersome, but seems to be reliable.
That’s probably the sum total of my help, I’m afraid - I get the impression you know at least as much as I do about how this stuff should normally work.
Nooooo. Don’t get that impression. I’m winging it!
Error: CS0103 - line 1247 (2355) - The name ‘IceContext’ does not exist in the current context
Error: CS0103 - line 1249 (2357) - The name ‘Db’ does not exist in the current context
Error: CS0103 - line 1249 (2357) - The name ‘LockHint’ does not exist in the current context
Error: CS0103 - line 1253 (2361) - The name ‘Db’ does not exist in the current context
Error: CS0103 - line 1249 (2357) - The name ‘Session’ does not exist in the current context
Am I missing a reference or a using statement? Is this code only for a BPM?
Yes, sorry, it occurred to me on the way home for the weekend that since that is BPM code there would be extra steps to make it work, such as making your checkbox on the UD form a UD checkbox and linking the two in a Data Directive or similar. That’s a common approach but one that, in your case, might leave a worrying disconnect between the state of the UI and whether the update has actually happened.
But the more I thought about your initial code the more it was bugging me, so I’ve recreated as close to your original situation as I can and the solution is actually fairly simple - in your new adapter, pass “oTrans” to it instead of the form. The following works for me:
private void cbxTest_CheckedChanged(object sender, System.EventArgs args)
{
// ** Place Event Handling Code Here **
SalesOrderAdapter soadptr = new SalesOrderAdapter(oTrans);
soadptr.BOConnect();
int ordernum = 123456;
if (soadptr.GetByID(ordernum))
{
soadptr.SalesOrderData.OrderHed.Rows[0]["Checkbox_c"] = cbxTest.Checked;
soadptr.Update();
}
soadptr.Dispose();
}