I am trying to create a routine to import orders from our EDI service into Acumatica. I have created a skeleton action:
public PXAction<EDOrderReviewFilter> GetOrders;
[PXProcessButton()]
[PXUIField(DisplayName = "Get Orders")]
protected virtual void getOrders()
{
EDOrderReview graph = PXGraph.CreateInstance<EDOrderReview>();
graph.Filter.Current.ReviewType = "A";
throw new PXRedirectRequiredException(graph, false, "Review");
}
I can finish the code to retrieve the orders and insert the sales orders, but I cannot get this to schedule. The order review graph display would not be included in the automated retrieval. The schedule appears to only allow scheduling of Process All even though the documentation says it should be a picklist of the actions in the graph. Can anyone help? Is there a better way to schedule the order retrieval? The current thought is to check every 15 minutes and import all new orders.
=============New information============================================
I am having trouble now making the calling graph show the spinning timer while orders are being retrieved. In the code below the EDGetOrders.cs is the new processing page that simply retrieves the orders. This will eventually be hidden and scheduled. EDOrderReview.cs is the original graph that allows review and adjustment of imported orders where I would like to have a button that will initiate an order retrieve and show some feedback that the process is running and then show some indication that it is finished. Using the PressButton method processes the retrieve synchronously and then the screen refreshes via the last three lines. The LongOperation method starts the process asynchronously and immediately redraws the screen. Am I using the LongOperation correctly?
// EDGetOrders.cs Separate graph to simply retrieve the orders
// Action to retrieve orders
public PXAction<EDGetOrderFilter> GetOrders;
[PXProcessButton()]
[PXUIField(DisplayName = "")]
protected virtual void getOrders()
{
getEDIOrders();
}
// This function performs all the work and works fine
public void getEDIOrders()
{
...
}
// This function is called on Process All and works fine and shows the spinning timer
public void ProcessOrder(List<EDIGetOrder> list, string type)
{
SOOrderEntry soOrderGraph = PXGraph.CreateInstance<SOOrderEntry>();
bool errorOccured = false;
string statusText = "";
foreach (EDIGetOrder ediOrder in list)
{
PXProcessing<EDIGetOrder>.SetCurrentItem(ediOrder);
getOrders();
statusText = "Orders Retrieved";
}
if (errorOccured)
throw new PXOperationCompletedWithErrorException(statusText);
else
throw new PXOperationCompletedException(statusText);
}
//EDOrderReview.cs Original graph I want to call getOrders from and show the spinning timer
//Action to create button
public PXAction<EDOrderReviewFilter> GetOrders;
[PXProcessButton()]
[PXUIField(DisplayName = "Get Orders")]
protected virtual void getOrders()
{
EDGetOrders getOrders = PXGraph.CreateInstance<EDGetOrders>();
//getOrders.GetOrders.PressButton();
PXLongOperation.StartOperation(this, delegate () { goGetOrders(); });
//Redraw the screen with the new orders
EDOrderReview graph = PXGraph.CreateInstance<EDOrderReview>();
graph.Filter.Current.ReviewType = "A";
throw new PXRedirectRequiredException(graph, false, "Review");
}
public static void goGetOrders()
{
EDGetOrders getOrders = PXGraph.CreateInstance<EDGetOrders>();
getOrders.getEDIOrders();
}
Unfortunately, the current documentation doesn't match with the actual behavior of the Automation Schedules screen. In reality, the Action Name field always stays disabled and can only show the Process All option. Hopefully, this explains why it won't be possible to schedule order retrieval from your current processing page.
An alternative solution would be to create a stand-alone processing screen just to retrieve orders from external EDI service, which you can schedule to run the Process All action every 15 minutes. You can hide this new processing screen from users by placing it in the Hidden folder of the SiteMap.
For sure, you can still keep the Get Orders button on your current processing screen and, if you implement your method to retrieve orders from external EDI service as static, it should be possible to invoke the same method from both your current and new processing screens.
Update to answer the New Information section:
You should throw PXRedirectRequiredException to show EDOrderReview after the GetEDIOrders operation is over:
public PXAction<EDOrderReviewFilter> GetOrders;
[PXProcessButton()]
[PXUIField(DisplayName = "Get Orders")]
protected virtual void getOrders()
{
EDGetOrders getOrders = PXGraph.CreateInstance<EDGetOrders>();
//getOrders.GetOrders.PressButton();
PXLongOperation.StartOperation(this, delegate ()
{
goGetOrders();
//Redraw the screen with the new orders
EDOrderReview graph = PXGraph.CreateInstance<EDOrderReview>();
graph.Filter.Current.ReviewType = "A";
throw new PXRedirectRequiredException(graph, false, "Review");
});
}
public static void goGetOrders()
{
EDGetOrders getOrders = PXGraph.CreateInstance<EDGetOrders>();
getOrders.getEDIOrders();
}
Related
I have a custom field on an Acumatica Production Detail Operation (UsrEligibleForRoboticFulfillment) that I have created an Action to set based on criteria on the component items in the Materials tab. (code below)
I would like to call this Action to set the field as soon as the Production Order is created, but the split nature of the Production Order is such that there are no events on the Production Detail raised that I can attach to and call the Action. I've tried Row Inserted as well as Persist delegate on the Production Detail graph.
I CAN attach to either the AMProdItem Row Inserted or Persist Delegate on the Production Maint graph, but at this point in time the Operations and Materials have not yet been created.
What's the best way to update this field when a new Production Order is created?
Action code:
public PXAction<AMProdItem> UpdateEligibleForRoboticFulfillment;
[PXButton(CommitChanges = true)]
[PXUIField(DisplayName = "Update Robotic Eligibility", MapEnableRights = PXCacheRights.Select, MapViewRights = PXCacheRights.Select)]
protected void updateEligibleForRoboticFulfillment()
{
AMProdItem prodDetail = Base.ProdItemRecords.Current;
AMProdOper prodOper = Base.ProdOperRecords.Current;
InventoryItem finishedProduct = PXSelect<InventoryItem,
Where<InventoryItem.inventoryID, Equal<Current<AMProdItem.inventoryID>>>>.Select(Base).FirstOrDefault();
//Only production orders are eligible for robotic fulfillment, not disassemblies
if (prodDetail.OrderType == "MO")
{
bool wasRoboticsEligible = (prodOper.GetExtension<AMProdOperExt>().UsrEligibleForRoboticFulfillment ?? false);
//Get the current branchID
int branchID = (int)Base.Accessinfo.BranchID;
//Get the default site/warehouse for this branch.
INSite site = INTranHelper.GetDefaultSiteForItemBranch(branchID);
//Get the flag indicating whether this site is active for robotics
bool activeRobotics = site.GetExtension<INSiteExt>().UsrActiveRobotics ?? false;
//Get the flags for manual process and component robotics compatible
bool requiresManualProcess = finishedProduct.GetExtension<InventoryItemExt>().UsrManualFinishRequired ?? false;
//Gotta be prepared for the possibility that more than one component is used
//Check for any components that are NOT robotics eligible that have qty required and haven't already been fully allocated
PXResultset<AMProdMatl> components = PXSelectJoin<AMProdMatl,
InnerJoin<InventoryItem, On<InventoryItem.inventoryID, Equal<AMProdMatl.inventoryID>,
And<InventoryItemExt.usrRoboticsCompatible, Equal<False>,
And<AMProdMatl.orderType, Equal<Current<AMProdOper.orderType>>,
And<AMProdMatl.prodOrdID, Equal<Current<AMProdOper.prodOrdID>>,
And<AMProdMatl.operationID, Equal<Current<AMProdOper.operationID>>,
And<AMProdMatl.qtyActual, Less<AMProdMatl.totalQtyRequired>,
And<AMProdMatl.qtyReq, Greater<decimal0>>>>>>>>>>
.Select(Base);
bool roboticsEligible = !requiresManualProcess && activeRobotics;
//If any component is not eligible, the whole operation is not eligible
if (components.Count > 0)
{
roboticsEligible = false;
}
//If the robotics eligible flag should have changed, change it
if (wasRoboticsEligible != roboticsEligible)
{
prodOper.GetExtension<AMProdOperExt>().UsrEligibleForRoboticFulfillment = roboticsEligible;
Base.ProdOperRecords.Update(prodOper);
}
}
}
Had to open a ticket with Acumatica; got a working solution! I had to enclose the persist delegate method in a transaction scope.
Override Persist() method of graph
Call base method first so that Operations and Materials on the Production Order Detail gets created
Enclosed in transaction scope
Something like this:
public delegate void PersistDelegate();
[PXOverride]
public void Persist(PersistDelegate baseMethod)
{
if (/**/)
{
using (var ts = new PXTransactionScope())
{
//Call base method to persist
baseMethod();
/*Custom Logic here*/
ts.Complete();
}
}
else
baseMethod();
}
Within the Acumatica 19.201.0070 framework I have created a custom processing page that utilizes PXFilteredProcessing with the old style processing UI public override bool IsProcessing => false; I have defined a cancel button (below) that will clear the graph and set some values of the processing filter.
public PXCancel<NPMasterSubGeneratorFilter> Cancel;
[PXCancelButton()]
protected virtual IEnumerable cancel(PXAdapter adapter)
{
NPMasterSubGeneratorFilter row = Filter.Current;
if (row != null)
{
this.Clear();
Filter.SetValueExt<NPMasterSubGeneratorFilter.segmentID>(Filter.Current, row.SegmentID);
if (!(row.NewSegment ?? false)) Filter.SetValueExt<NPMasterSubGeneratorFilter.segmentValue>(Filter.Current, row.SegmentValue);
}
return adapter.Get();
}
This works perfectly fine except for a single use case, after processing results are shown if the user then presses the cancel button the corresponding action is never hit. ( My fellow office devs state that core Acumatica processing pages seem to operate the same. )
Setting of the processing delegate is within the filter RowSelected event.
GeneratedSubs.SetProcessDelegate(list => CreateSubaccounts(list, row));
I have implemented a few iterations of my processing method but the current is below.
protected virtual void CreateSubaccounts(List<NPGeneratedSub> subs, NPMasterSubGeneratorFilter filter)
{
if (filter.NewSegment ?? false)
{
try
{
SegmentMaint segGraph = PXGraph.CreateInstance<SegmentMaint>();
segGraph.Segment.Update(segGraph.Segment.Search<Segment.dimensionID, Segment.segmentID>(AADimension.Subaccount, filter.SegmentID.Value));
SegmentValue value = segGraph.Values.Insert(new SegmentValue() { Value = filter.SegmentValue, Descr = filter.Description });
segGraph.Actions.PressSave();
}
catch
{
throw new PXOperationCompletedSingleErrorException(NonProfitPlusMessages.SegmentValueCannotCreate);
}
}
SubAccountMaint subGraph = PXGraph.CreateInstance<SubAccountMaint>();
NPSubAccountMaintExtension subGraphExt = subGraph.GetExtension<NPSubAccountMaintExtension>();
subGraphExt.save.ConfirmSaving = false;
Sub newSub;
bool errored = false;
foreach (NPGeneratedSub sub in subs)
{
PXProcessing<NPGeneratedSub>.SetCurrentItem(sub);
try
{
newSub = subGraph.SubRecords.Insert(new Sub() { SubCD = sub.SubCD, Description = sub.Description });
subGraph.Save.Press();
subGraph.Clear();
PXProcessing<NPGeneratedSub>.SetProcessed();
}
catch (Exception e)
{
PXProcessing<NPGeneratedSub>.SetError(e);
errored = true;
}
}
if (errored)
{
throw new PXOperationCompletedWithErrorException();
}
}
What needs to be adjusted to allow the buttons action to be triggered on press after processing results have been returned?
After stepping through the javascript I discovered that it wasn't sending a request to the server when you click the cancel button on this screen after processing. The reason is because SuppressActions is getting set to true on the Cancel PXToolBarButton. I compared what I was seeing on this screen to what was happening on screens that work correctly and realized that Acumatica is supposed to set SuppressActions to true on the Schedule drop down PXToolBarButton but for some reason, on this screen, it is incorrectly setting it to true on whatever button is after the Schedule drop down button.
I looked through the code in PX.Web.UI and it looks like they set SuppressActions to true when a drop down button is disabled and PXProcessing adds a FieldSelecting event to the Schedule button which disables the button after you click process. However, I didn't notice any obvious issues as to why the code would be setting it on the wrong PXToolBarButton so someone will likely need to debug the code and see what's going on (we are unable to debug code in PX.Web.UI.dll).
I tried commenting out the other grids in the aspx file that aren't related to the PXProcessing view and this resolved the issue. So my guess would be that having multiple grids on the PXProcessing screen somehow causes a bug where it sets SuppressActions on the wrong PXToolBarButton. However, since the multiple grids are a business requirement, removing them is not a solution. Instead, I would suggest moving all buttons that are after the schedule button to be before the schedule button. To do this, just declare the PXActions before the PXFilteredProcessing view in the graph.
Please try this
Override IsDirty property
Use PXAction instead of PXCancel
Add PXUIField attribute with enable rights
action name should start from lowercase letter
delegate name should start from uppercase letter
see code below
public override bool IsDirty => false;
public override bool IsProcessing
{
get { return false;}
set { }
}
public PXAction<NPMasterSubGeneratorFilter> cancel;
[PXUIField(MapEnableRights = PXCacheRights.Select)]
[PXCancelButton]
protected virtual IEnumerable Cancel(PXAdapter adapter)
{
NPMasterSubGeneratorFilter row = Filter.Current;
if (row != null)
{
this.Clear();
Filter.SetValueExt<NPMasterSubGeneratorFilter.segmentID>(Filter.Current, row.SegmentID);
if (!(row.NewSegment ?? false)) Filter.SetValueExt<NPMasterSubGeneratorFilter.segmentValue>(Filter.Current, row.SegmentValue);
}
return adapter.Get();
}
I'm trying to display a warning every time the ShippedQty field is changed to a value < OrigOrderQty on the "Shipment - SO302000" screen, but I only want the code to be active for that specific screen/form.
I added the code below to extend the SOShipmentEntry graph, which accomplishes my original goal, but the issue is that now the code I added is also being used by the "Create Shipment" action in "Sales Orders - SO301000" screen/form.
Create Shipment Action Discussed
namespace PX.Objects.SO
{
public class SOShipmentEntry_Extension : PXGraphExtension<SOShipmentEntry>
{
#region Event Handlers
protected void SOShipLine_ShippedQty_FieldUpdated(PXCache cache,PXFieldUpdatedEventArgs e)
{
var myrow = (SOShipLine)e.Row;
if (myrow == null) return;
if (myrow.ShippedQty >= myrow.OrigOrderQty)
{
}
else
{
throw new PXSetPropertyException("The difference between the shipped-qty and the ordered-qty will be placed on a back-order", PXErrorLevel.Warning);
}
}
#endregion
}
}
While the warning allows the user to save changes to a shipment on the Shipment Screen/form SO302000 (Because the exception is set up as a warning and not an error), I get the following error when I create a shipment using the "Create Shipment" button on the "Sales Orders - SO301000" screen.
Warning works fine for form-mode
Warning becomes error when processed in background by action button
Any ideas to accomplish this? It is my understanding that if I want to make global changes to a field I must make them in the DAC, but if I want to make changes that only affect screens/forms where a graph is used, then I have to make those changes in the graph code itself. I'm guessing the "Create Shipment" action button in the Sales Orders screen is creating an instance of the graph where I added the code, so I'm wondering what are my options here.
Best regards,
-An Acumatica newbie
If you want your event logic to execute only when CreateShipment is invoked from the Shipment screen you can override the other calls to CreateShipment to dynamically remove your event handler.
The event that invokes CreateShipment action from the SalesOrderEntry graph is Action:
public PXAction<SOOrder> action;
[PXUIField(DisplayName = "Actions", MapEnableRights = PXCacheRights.Select)]
[PXButton]
protected virtual IEnumerable Action(PXAdapter adapter,
[PXInt]
[PXIntList(new int[] { 1, 2, 3, 4, 5 }, new string[] { "Create Shipment", "Apply Assignment Rules", "Create Invoice", "Post Invoice to IN", "Create Purchase Order" })]
int? actionID,
[PXDate]
DateTime? shipDate,
[PXSelector(typeof(INSite.siteCD))]
string siteCD,
[SOOperation.List]
string operation,
[PXString()]
string ActionName
)
In that method it creates a SOShipmentEntry graph to create the shipment. You can override Action and remove your handler from that graph instance:
SOShipmentEntry docgraph = PXGraph.CreateInstance<SOShipmentEntry>();
// >> Remove event handler
SOShipmentEntry_Extension docgraphExt = docgraph.GetExtension<SOShipmentEntry_Extension>();
docgraph.FieldUpdated.RemoveHandler<SOShipLine.shippedQuantity>(docgrapExt.SOShipLine_ShippedQty_FieldUpdated);
// << Remove event handler
docgraph.CreateShipment(order, SiteID, filter.ShipDate, adapter.MassProcess, operation, created);
Note that in order to reference SOShipLine_ShippedQty_FieldUpdated method from another graph you'll have to make it public:
public void SOShipLine_ShippedQty_FieldUpdated(PXCache cache,PXFieldUpdatedEventArgs e)
I have described how to do this in that answer too:
Updating custom field is ending into infinite loop
If you want your event logic to execute only when it is modified in the UI or by web service.
You can use the ExternalCall Boolean property of the PXFieldUpdatedEventArgs parameter.
This property value will be true only when the sender field is modified in the UI or by web service.
Usage example:
protected void SOShipLine_ShippedQty_FieldUpdated(PXCache cache,PXFieldUpdatedEventArgs e)
{
// If ShippedQty was updated in the UI or by a web service call
if (e.ExternalCall)
{
// The logic here won't be executed when CreateShipment is invoked
}
}
ExternalCall Property (PXFieldUpdatedEventArgs)
Gets the value specifying whether the new value of the current DAC field has been changed in the UI or through the Web Service API.
Upon deletion of my custon item LELettering in which I have a view with ARRegister lines, I want to :
- Reverse the payment application for every Invoice ARRegister lines for the payment also included in my ARRegister lines.
- Clean the LetteringCD I did put in a custom field in my ARRegister extension.
Now when I pick one or the other alone, it works.
My problem is when I do both : reverseapplication() do it's job, but this, as a side effect, updates the ARRegister records when I call the reverseapplication method from the ARPaymentEntry.
Which lead to an error : "Another process has update the ARRegister record and your changes will be lost", when I try to update the ARRegister records to clean my custom field LetteringCD.
I think my problem is my view Lines is not refreshed once reverseApplication is called, so it still has the not yet updated records of ARRegister.
I tried ClearQueryCache() but it doesnt seem to work, how to I force a refresh on my view Lines so I can update them again ?
public PXSelect<LELettering> Piece;
public PXSelect<ARRegister> Lines;
protected virtual void LELettering_RowDeleting(PXCache sender, PXRowDeletingEventArgs e)
{
// Cancel the lettering by removing every LetteringCD from the ARRegister lines and reverse application paiements
cancelLettering();
}
protected void cancelLettering()
{
reverseApplication();
eraseLetteringCD();
}
protected void reverseApplication()
{
string refNbr = "";
List<ARRegister> lines = new List<ARRegister>();
foreach (ARRegister line in PXSelect<ARRegister, Where<ARRegisterLeExt.lettrageCD,
Equal<Required<ARRegisterLeExt.lettrageCD>>>>.Select(this, Piece.Current.LetteringCD))
{
if (line.DocType == "PMT") refNbr = line.RefNbr;
else lines.Add(line);
}
ARPaymentEntry graphPmt = getGraphPayment(refNbr, "PMT");
foreach(ARAdjust line in graphPmt.Adjustments_History.Select())
{
graphPmt.Adjustments_History.Current = line;
graphPmt.reverseApplication.Press();
}
graphPmt.release.Press();
graphPmt.Actions.PressSave();
}
// Here is my problem
protected void eraseLetteringCD()
{
foreach (var line in Lines.Select())
{
line.GetItem<ARRegister>().GetExtension<ARRegisterLeExt>().LettrageCD = null;
Lines.Current = Lines.Update(line);
}
Actions.PressSave();
}
protected ARPaymentEntry getGraphPayment(string refNbr, string docType)
{
ARPaymentEntry graphPmt = CreateInstance<ARPaymentEntry>();
ARPayment pmt = PXSelect<ARPayment, Where<ARPayment.refNbr, Equal<Required<ARPayment.refNbr>>,
And<ARPayment.docType, Equal<Required<ARPayment.docType>>>>>
.Select(this, refNbr, docType);
if (pmt == null) throw new PXException(Constantes.errNotFound);
graphPmt.Document.Current = pmt;
return graphPmt;
}
Edit:
The problem comes from the fact the records ARRegister are saved two times, once with the reversepaymentapplication, and once in the eraseLetteringCD, but I dont know how to avoid this in my case.
Some things I might try...
I do see that there are multiple graphs involved. The second graph will need to refresh the results before it can process. There are a few ways of doing this that I try...
You can try to clear the query cache as shown below. My guess when you call Lines.Select it has an old cached value?
protected void cancelLettering()
{
reverseApplication();
Lines.Cache.ClearQueryCache()
eraseLetteringCD();
}
I find it helpful some items in reverse if the select is not returning the cached results to find the cached row myself. The reverse could be to use PXSelectReadonly<> as your foreach select statement as this should use the records from the DB vs any cached values.
protected void eraseLetteringCD()
{
// Also try PXSelectReadonly<> in place of Lines.Select()
foreach (ARRegister line in Lines.Select())
{
//Get cached row
var cachedRow = (ARRegister)Lines.Cache.Locate(line) ?? line;
cachedRow.GetExtension<ARRegisterLeExt>().LettrageCD = null;
Lines.Update(cachedRow );
}
Actions.PressSave();
}
After the first press save you could also try to just clear the cache and the query cache to setup for the next call. Ideally if possibly just do one persist.
If the first graph is running a long operation you can make the code pause to wait for the operation to complete. This would be useful when using multiple graphs. The second graph persist should not run until the first long running process has finished. Example using the ID of your graphPmt instance:
graphPmt.release.Press();
PXLongOperation.WaitCompletion(graphPmt.UID)
We're using the Run Project Billing screen to create records in AR / Invoice and Memo.
In the Invoice & Memo screen, we need the process to populate the header Customer Ord. number, along with a user field that has been added to the grid section on the 'Document Details' tab. At the moment, the process is not doing this.
I'd like to intercept the processing action on the screen using a technique I'm familiar with, namely using an 'AddHandler':
[PXOverride]
protected virtual IEnumerable Items (PXAdapter adapter)
{
PXGraph.InstanceCreated.AddHandler<BillingProcess>((graph) =>
{
graph.RowInserting.AddHandler<BillingProcess.ProjectsList>((sender, e) =>
{
//Custom logic goes here
});
});
return Base.action.Press(adapter);
}
I see no Base.Actions that remotely resembles 'Bill' or 'Bill All'.
This is obviously not exactly the code I need, but I would think this is the general place to start.
After reviewing the source business logic, I don't see any 'Bill' or 'Bill All' Actions - or any 'Actions' at all (baffling). I see an IEnumerable method called 'items', so that's what I started with above.
Is this the correct way to go about this?
Update: 2/14/2017
Using the answer provided re: the overridden method InsertTransaction(...) I've tried to set our ARTran user field (which is required) using the following logic:
PMProject pmproj = PXSelect<PMProject, Where<PMProject.contractID, Equal<Required<PMProject.contractID>>>>.Select(Base, tran.ProjectID);
if (pmproj == null) return;
PMProjectExt pmprojext = PXCache<PMProject>.GetExtension<PMProjectExt>(pmproj);
if (pmprojext == null) return;
ARTranExt tranext = PXCache<ARTran>.GetExtension<ARTranExt>(tran);
if (tranext == null) return;
tranext.UsrContractID = pmprojext.UsrContractID;
Even though this sets the user field to the correct value, it still gives me an error that the required field is empty when the process finishes. My limited knowledge prevents me from understanding why.
On the Run Project Billing screen, captions of Process and Process All buttons were changed to Bill and Bill All respectively in BLC constructor.
Process delegate is set for Items data view within the BillingFilter_RowSelected handler:
public class BillingProcess : PXGraph<BillingProcess>
{
...
public BillingProcess()
{
Items.SetProcessCaption(PM.Messages.ProcBill);
Items.SetProcessAllCaption(PM.Messages.ProcBillAll);
}
...
protected virtual void BillingFilter_RowSelected(PXCache cache, PXRowSelectedEventArgs e)
{
BillingFilter filter = Filter.Current;
Items.SetProcessDelegate<PMBillEngine>(
delegate (PMBillEngine engine, ProjectsList item)
{
if (!engine.Bill(item.ProjectID, filter.InvoiceDate, filter.InvFinPeriodID))
{
throw new PXSetPropertyException(Warnings.NothingToBill, PXErrorLevel.RowWarning);
}
});
}
...
}
As code snippet above confirms, all records in the AR Invoice and Memos screen are created by instance of the PMBillEngine class. Below is code snippet showing how to override InsertNewInvoiceDocument and InsertTransaction methods within the PMBillEngine BLC extension:
public class PMBillEngineExt : PXGraphExtension<PMBillEngine>
{
public delegate ARInvoice InsertNewInvoiceDocumentDel(string finPeriod, string docType, Customer customer,
PMProject project, DateTime billingDate, string docDesc);
[PXOverride]
public ARInvoice InsertNewInvoiceDocument(string finPeriod, string docType, Customer customer, PMProject project,
DateTime billingDate, string docDesc, InsertNewInvoiceDocumentDel del)
{
var result = del(finPeriod, docType, customer, project, billingDate, docDesc);
// custom logic goes here
return result;
}
[PXOverride]
public void InsertTransaction(ARTran tran, string subCD, string note, Guid[] files)
{
// the system will automatically invoke base method prior to the customized one
// custom logic goes here
}
}
Run Project Billing process invokes InsertNewInvoiceDocument method to create new record on the AR Invoice and Memos screen and InsertTransaction method to add new invoice transaction.
One important thing to mention: overridden InsertNewInvoiceDocument and InsertTransaction methods will be invoked when a user launches Run Project Billing operation either from the processing Run Project Billing screen or from the data entry Projects screen.
For more information on how to override virtual BLC methods, see Help -> Customization -> Customizing Business Logic -> Graph -> To Override a Virtual Method available in every Acumatica ERP 6.1 website