Is there a way in Application Studio to set a field to stay open after the form itself has been closed?
Specifically, I have a OrderDtl UD field (string) that I’ve placed near the top of the main Order Detail Order Entry form that remains editable after the order is closed (not sure why though). I’ve got another OrderHed UD field (date) that I would like to remain editable as well. Any idea how I could go about achieving this?
Thanks for any help.
You’re going to have to describe and show this in more detail.
Yeah, like Kevin says, what’s the business problem that led you to this solution? Why are you trying to keep a field available when a form is closed? 
Probably not. I’ve gotten around this using callContextBpmData fields.
Use BPMs or app studio to copy the UD field value to the callContext field when you load the record, then another to write the changes to the call context back to the UDfield when you save.
Thanks @zwilli526. I think I can give that a try. Do you mean to add a date picker field, but not bind it to the UD or any field (which will keep it always open), and use callContext to display it in the TransView, if it already has a value? (and then write it back if changed).
The business problem is that we have a rental and, separately, a loaner program where the rental and loaner terms (the expected return date) is quite often being extended. We’ve found ourselves using the Sales Order as the main landing page for tracking these, especially useful for rentals with multiple invoices (a recurring invoice). Everything connects from there. It’s a minor inconvenience to re-open the order and then close it.
I’m sure there’s a better way, it’s just that OrderDtl.RMANum_c remaining open (which is also at times useful when creating the RMA after invoicing) got me thinking it might be worth attempting. There isn’t any BPMs doing what Zack described; could it be accomplished entirely in an application studio event maybe? It’s more my curiosity now why it’s open. The return date isn’t even business critical; our main invoice or recurring invoice does that; more to loosely keep everyone informed.
While this field may be “open”, are you positive it is doing anything?
I’d have to imagine if it is, there is some custom logic going on behind the scenes.
Good question Kevin, I had to double check, but yes, it is. It does save and update when when a closed order is saved. I’ll hunt around some more for the logic controlling this and update if/when I find it.
Thanks for helping!
We had a similar use case with freight tracking checkboxes against closed shipments. UD fields would not update once the shipments were closed. I ended up using data tags against the shipment header which don’t have these limitations:
Data Tags (SYSTAG) - an under-utilized feature in Kinetic
They can be added / removed via BPM or functions and are easily searchable using BAQs. I use them for all sorts now.
Many thanks,
Nathan
Me too. Just remember to document all that stuff lol.
Agreed! Although I tend to obscure the actual tagging behind custom buttons / checkboxes so users don’t have to remember the tag text to use.
Yes, me too. All (most) of my tags are private (user assigned is a project, group, etc not a real user), and the user never sees them.
Just a free ud field for those times when it makes sense to not add one.
Same here although I haven’t gotten round to using non-existent users yet.
What about dumb ones?
Dumb users? I couldn’t possibly comment…
I am not super well versed in this, but I believe that something called “row rules” needs to be applied to specify what can and cannot be edited at different stages… for example, I believe that it is a row rule that disallows certain fields from being edited once it is released. You have to unreleased it to edit those fields.
It might be as simple as creating a new row rule** for your field.
** (don’t ask me how to do this… as that is something I have not yet learned. If I am wrong… well, that’s the way it goes… trying to learn more every day.)
If I were you, I would try updatable dashboard if nothing falls in place and if users are willing to use it.You can set a parameter at BAQ allowing users to enter orderNum for their convenience. Then I would use base-processing BPM for this, set field to open order, open line, make changes(edit that date field), invoke BO method, close line, close order. At-least that could get you started in direction you want.
There are some similar post but for PO. That might help!
Epicor runs this Row Rule on OrderHed
{
"id": "openOrderRule",
"condition": "OpenOrder = false or FSMSendTo = true or [TransView].[SysReadOnly] = true",
"dataView": "OrderHed",
"actions": [
{
"action": "DisableRow",
"exceptTheseColumns": [
"OrderNum",
"CustomerPrintAckShape",
"ShowApplyOrderDiscountsControlShape",
"OpenOrderShape",
"ClosedOrderShape",
"InactiveCustomerShape",
"InactiveShipViaShape",
"LinkedShape",
"LinkedIssueShape",
"LOCHoldShape",
"CustOnCreditHoldShape",
"CreditOverrideShape",
"HoldSetByDemandShape",
"ERSOverrideShape",
"ExtAOEShape",
"OTSSavedShape",
"ShowKitDetails",
"CounterSaleProcessedShape",
"MakeDirectReleasesNoJobLinkShape",
"ReadyToProcessNotCheckedShape",
"AttributesRequiredShape",
"ViewTaxToolTracker",
"InactiveShipToShape"
]
}
],
"customizable": false,
"disabled": false
}
You may need to add a Row Rule but the problem is that there isnt a SettingStyle.Default Maybe if you set a condition where OrderNum = 0 then SettingStyle.Disabled perhaps it will reverse it. Or you use DisableRow and list all the columns that Epicor disabled + yours in the except, or add yours.
Other things you can try is setting Extended Property, or see if you can mark the Column a Key Field.