Hi @stephenward03,
You are right, the field values are not yet available because the record hasn’t been physically inserted in the database at this point.
The good news is that you don’t need to deal with this logic yourself, as long as you set the necessary attributes on the DAC fields.
One of the ways I learned how to program for Acumatica (beside going through the complete training curriculum) is by looking at the source code of other modules that employ a pattern similar to the one I’m looking for. In your case you already pointed out that you want a table similar to SOShipLineSplit, so you can take a look at how the DAC is declared by using the Source Code browser in Acumatica.
Let’s take a look at the ShipmentNbr field in SOShipLineSplit (I simplified it so that we can focus on the important stuff):
pPXDBString(15, IsKey = true)]
uPXDBDefault(typeof(SOShipment.shipmentNbr))]
rPXParent(typeof(FK.Shipment))]
tPXParent(typeof(FK.ShipmentLine))]
public virtual String ShipmentNbr { get; set; }
- It’s part of the key fields of the table, so it is marked with IsKey=True. This is very important, Acumatica will not let you have multiple rows with the same key values in a cache.
- PXDBDefault is how the system will default the value when it is inserted in the database; it will retrieve the value assigned to SOShipment.ShipmentNbr. You should never have to set this field yourself. Important: for LineNbr, another key field, you’ll see that PXDefault is used instead of PXDBDefault; that’s because the line number is assigned right away, not on database insertion. Don’t confuse this field with ShipLineNbr, which is there to ensure each shipment split has a unique line number.
- PXParent is there to ensure the record automatically gets deleted (cascade delete) if one of the parent records gets removed
If you need to insert a row in your table automatically when a new row is added to SOShipLine, you can insert it into the cache without setting all the fields which are defaulted by the system. I don’t remember 100% if a row becomes the current row of its respective cache automatically before RowInserted is invoked; if not you will have to make it the current row of the SOShipLine cache before you insert your row. If someone here can confirm the behaviour I would appreciate :)
Hi @stephenward03 I’m NOT sure why you wanted to insert the details into your custom table on RowInserted event.
You can event write this logic in persist delegate, while saving the this persist delegate will invoke and write a logic to fetch and insert the details into your custom table.
Please find the sample code for your reference.
public class SOShipmentEntryExt : PXGraphExtension<SOShipmentEntry>
{
public delegate void PersistDelegate();
PXOverride]
public void Persist(PersistDelegate del)
{
del();
// logic here for inserting the details into your custom table.
}
}
Hope this helps!!
Thanks for the replies.
@Naveen B I was planning to use the RowInserted event because that way I can bundle my code in with the transaction of the SOShipLine insert. If I use the Persist event then I think I might have a situation where the SOShipLine exists but my custom table is empty.
@Gabriel Michaud Some nice ideas. I had already taken a look at the code from the SOShipLineSplit but I was quite confused by the amount of things going on in there. For example, in the code you copied there are references to FK, which is also defined in the code and it looked like another complication. But it sounds like setting up parent/child links are the way to go and thanks for the tip about the LineNbr being set before it hits the DB.
I’ll try to set something up and report back, if parent/child fails then I may need to fall back onto using Persist.
Thank you both for your comments.
Steve