I have a custom field on my SOOrder called "UsrProcessTypes," my goal is to have a pop up dialog when users choose this specific option "STCK." I tried the .Ask on a row selected on the base.documentcurrent on a row selected function and it was working correctly(testing purposes). When I applied it to the fieldverifying it was unsuccessful.
protected virtual void SOOrder_UsrProcessTypes_FieldVerifying(PXCache sender, PXFieldVerifyingEventArgs e)
{
SOOrder row = (SOOrder)e.Row;
SOOrderExt rowExt = sender.GetExtension<SOOrderExt>(row);
if(rowExt.UsrProcessTypes == "STCK")
{
if (Base.CurrentDocument.Ask("CONFIRM RECALCULTION",
"Confirm Recalculation",
MessageButtons.OK) != WebDialogResult.OK)
{
//
}
}
Thanks in advance
Fixed the issue, I needed to use a rowupdating event instead of field verifying to achieve my goal.
Related
I have a custom field on the CRActivity table in which I need to store the number of records in a related table. I am trying to set the field to the value when screen CR306030 opens. The user needs to be able to override the calculated number so, I'm thinking that I need logic on the calculation to check if the custom field is > 0, in which case, don't populate the custom field and assume it's already been set.
Previously, I've tried to do this in the Field_Selecting events but, this is not working. I'm thinking I might be able to use a PXFormula attribute. Any suggestions?
I tried making a custom attribute which is close but, it won't save the values to the db. The save button enables, I can click it and it looks like it saves but, no dice. Some mundane detail, I'm sure.....
Here's my custom attribute:
public class CFCountIfZeroAttribute : PXIntAttribute
{
public override void FieldSelecting(PXCache cache, PXFieldSelectingEventArgs e)
{
if (e.Row == null)
return;
CRActivity activity = (CRActivity)e.Row;
CRActivityExt activityExt = activity.GetExtension<CRActivityExt>();
if (activityExt.usrCustomField <= 0)
{
int aggregateValue = BQLToFind();
e.ReturnValue = aggregateValue;
cache.SetValue<CRActivityExt.usrCustomField>(e.Row, aggregateValue);
cache.IsDirty = true;
}
}
}
Thanks!
I don't think I've ever done a count within a PXFormula, but what if you created a custom attribute?
[DBUIInt()]
[EditableCount()]
public virtual int? CountField
public class EditableCountAttribute
{
public override void FieldSelecting(PXCache sender, PXFieldSelectingEventArgs e)
{
if (e.Row != null)
{
//if CountField is 0, lookup the count from another table
}
}
}
This is just off the top of my head. You could pass the field you're counting into the attribute if you wanted to do this elsewhere.
We have a test DAC called UsrNonRelatedScanField with two fields : OrderNbr and ScanStatus.
Here's our simple query to grab the correct ordernbr and assign it to a SOOrderExt field:
NonRelatedScanField lastScan = PXSelect<NonRelatedScanField,
Where<NonRelatedScanField.orderNbr,
Equal<Required<SOOrder.orderNbr>>>>.Select(Base, row.OrderNbr);
if(lastScan != null)
{
rowExt.UsrNonRelatedScanField = lastScan.ScanStatus;
}
This logic is held in a SOOrder_RowSelecting() method.
Full Method implementation:
protected virtual void SOOrder_RowSelecting(PXCache sender, PXRowSelectingEventArgs e)
{
SOOrder row = (SOOrder)e.Row;
if (row == null) return;
SOOrderExt rowExt = PXCache<SOOrder>.GetExtension<SOOrderExt>(row);
NonRelatedScanField lastScan = PXSelect<NonRelatedScanField,
Where<NonRelatedScanField.orderNbr,
Equal<Required<SOOrder.orderNbr>>>>.Select(Base, row.OrderNbr);
if (lastScan != null)
{
rowExt.UsrNonRelatedScanField = lastScan.ScanStatus;
}
}
Expected Results : Get the current Orders scan status from lastScan DAC
Actual Results: Will populate correctly only on the initial order opened. When selecting other orders the old value is persisting unless I manually refresh the page. When manually refreshed the correct data comes in.
I haven't had any issues in the past with BQL queries, this specific query is not behaving as expected.
Thank you
We have a simple customization that makes the Customer Order field required. But we do not know how to prevent the requirement on Transfer-type orders, which hides the Customer Order field. I found a similar article (Make Salesperson ID a Required field on SOLine) that discusses excluding a requirement for a "line" field, but I think this scenario (preventing requirement of Customer Order field for Transfer Sales orders) might be even simpler. Thanks for any help.
Change PXDefaultAttribute/PXUIFieldAttribute based on your business rules in SOOrder RowSelected event handler of SOOrderEntry graph extension:
public class SOOrderEntry_Extension:PXGraphExtension<SOOrderEntry>
{
protected void SOOrder_RowSelected(PXCache sender, PXRowSelectedEventArgs e)
{
SOOrder soOrder = e.Row as SOOrder;
if (soOrder != null)
{
bool isRequired = (soOrder.OrderType != SOOrderTypeConstants.TransferOrder);
PXDefaultAttribute.SetPersistingCheck<SOOrder.customerOrderNbr>(sender,
soOrder,
isRequired ? PXPersistingCheck.NullOrBlank : PXPersistingCheck.Nothing);
PXUIFieldAttribute.SetRequired<SOOrder.customerOrderNbr>(sender, isRequired);
}
}
}
I know it is possible to enable/disable particular fields progrmmatically. Is it also possible to disable editing of the entire row? I am referring to the Transactions (ARTran) in the Invoice Entry screen. I would want to disable changing any values in the line on particular conditions.
PXUIFieldAttribute.SetEnabled method has an overload that works on all fields of a row.
public class SOInvoiceEntry_Extension : PXGraphExtension<SOInvoiceEntry>
{
protected virtual void ARTran_RowSelected(PXCache sender, PXRowSelectedEventArgs e)
{
ARTran row = e.Row as ARTran;
if (row == null)
{
return;
}
bool myCondition = false;
PXUIFieldAttribute.SetEnabled(Base.Caches[typeof(ARTran)], row, myCondition);
}
}
I have custom code on the Sales Order form that prevents editing SOLine descriptions unless it's a specific SOLine Code. I see that my custom code is being reached, but it seems that something else is overriding my logic, enabling editing on the field after I disable it. I was wondering if there are pre-defined automations that might be doing this for the Sales Order screen, or if there is some other place I should be looking to prevent this behavior.
//I had debug code that validated that RowSelected and SetEnabled were begin called
public class SOOrderEntry_Extension:PXGraphExtension
{
#region Event Handlers
protected void SOLine_RowSelected(PXCache cache, PXRowSelectedEventArgs e, PXRowSelected InvokeBaseHandler)
{
if(InvokeBaseHandler != null)
InvokeBaseHandler(cache, e);
var row = (SOLine)e.Row;
if(row != null && row.InventoryID.HasValue) {
//Only allow editing of parts description if the partno is 'NOTE'
InventoryItem inventoryItem = PXSelect<InventoryItem, Where<InventoryItem.inventoryID, Equal<Required<InventoryItem.inventoryID>>>>.Select(this.Base, row.InventoryID);
if(inventoryItem.InventoryCD == "NOTE") {
PXUIFieldAttribute.SetEnabled<SOLine.tranDesc>(cache, row, true);
} else {
PXUIFieldAttribute.SetEnabled<SOLine.tranDesc>(cache, row, false);
}
}
}
}
Unfortunately, your RowSelected handler will make no effect on the Line Description column because of how automation steps are configured for the Sales Orders screen:
In order to keep Line Description open for editing, you should change a number of Automation Steps disabling the entire Document Details grid on Sales Orders and subscribe to RowSelected handler for the SOOrder DAC to allow editing on the cache level for the SOOrder and SOLine DACs. Below are the changes required to enable Line Description for completed sales orders (if necessary, similar changes should be made to other Automation steps defined for the Sales Orders screen):
Subscribe to SOOrder_RowSelected handler to allow editing on the cache level for the SOOrder and SOLine DACs:
public class SOOrderEntryExt : PXGraphExtension<SOOrderEntry>
{
public void SOOrder_RowSelected(PXCache sender, PXRowSelectedEventArgs e)
{
SOOrder order = e.Row as SOOrder;
if (order != null && order.Status == SOOrderStatus.Completed)
{
sender.AllowUpdate = true;
Base.Transactions.Cache.AllowUpdate = true;
}
}
}
Modify Sales Orders' SO Completed automation step to open Line Description for editing. In addition to enabled Line Description, it's necessary to enable at least one of the SOOrder fields, otherwise the Save button will never become enabled for completed sales orders: