Odd behavior when excluding extension from Copy Paste

  • 13 October 2023
  • 8 replies

Userlevel 3


I have been adding fields to the INUnits table to better fit our needs, and so far it seems to be exactly what we need. I followed the example from this link: However I have ran into issue relating to copy and pasting.

When I try and copy this SKU to make a new one this happens





It makes sense that the key cannot be NULL, but why is it trying to insert the extension table row before the main row exists?

Regardless, its not the end of the world to me if I am unable to bring over all of the UOMs, so I added this code to the graph extension based on this example:

public PXSelect<INUnit, Where<INUnit.inventoryID, Equal<Current<InventoryItem.inventoryID>>>> itemunits;

And am met with this when I copy and paste:

This is able to be saved. However, I know from trying to add a base unit to base unit conversion by hand that this should not work, I am also confused as to why it is showing up in the first place, as I would expect it to be blocked by the filter, or at least show up in both scenarios as the EACH to EACH base unit conversion is not present when I do not have the filter. 

So, I have 2 paths/questiosns.

1: How can I keep the Units of Measure and ensure that it is saved in the proper order so the recordID is not null


2: How can I make sure that the “From Unit” “EACH” does not get created out of thin air on copy paste.


Thanks in advance


Best answer by AidenMission 16 October 2023, 14:36

View original

8 replies

Badge +11

Did you define the RecordID DAC field in your extension DAC?

The article does not highlight this fact very well, but I recently had an odd experience with an extension table and it was because I had the DAC key fields redefined in the extension DAC.

The article reads:

  1. The SQL table should have the same main key columns as the standard tables (these do not need to be defined in the DAC however)

I would reword this to say “These should absolutely not be redefined in the extension DAC however”

@Patrick Chen 

Userlevel 3

@darylbowman, Yeah I also had the same issue with extension tables like this the first time around the first time around. I also had a lot of issues with the primary keys and needing to rename them at the database level if anyone is going through that while reading this.


I did not have the recordID redefined in my DAC, but I found my issue. Of course it was my own fault.

1: I switched from my initial PXSelect<...> to: 

        public SelectFrom<INUnit>.Where<INUnit.inventoryID.IsEqual<InventoryItem.inventoryID.FromCurrent>.And<INUnit.fromUnit.IsNotEqual<InventoryItem.baseUnit.FromCurrent>>> itemunits;

Which seems to have fixed the issue, I also removed the [PXCopyPasteHiddenView] and now all of my extra fields and conversions are moving over nicely.

2: This needs a bit more context. As I previously noted, we cannot have the “EACH → EACH” conversion in the table, for me this means that I had to find a different way to make my extra fields available (Which is also a pain with extension tables for some reason, but thats a seperat topic). So I added another select that should just grab the base rate and allow me to edit that. However, I forgot to add [PXCopyPasteHiddenView] to it and that’s why the “EACH → EACH” conversion was showing up. I don’t know why it let me save it but that issue is outside of my knowledge.

Badge +11

I also had a lot of issues with the primary keys and needing to rename them at the database level…

I’m not quite understanding this.


Userlevel 3

I also had a lot of issues with the primary keys and needing to rename them at the database level…

I’m not quite understanding this.



That was a tangent on my part, it wasn’t affecting my original question. Just something I was dealing with when I was following the article the first time that I also felt wasn’t mentioned. However here are some more details:

When I would make a new table, say Table_1, a new key would be auto generated named something like PK_Table_1. This would give me errors when saving and referencing in Acumatica. I found that if I renamed it to Table_1_PK then it would work fine. I might be putting the cart before the horse on this, if someone has more knowledge on these things I’m not sure what the actual issue was.

Badge +11

I’ve never tried an extension table on an auto-generating identity key, but I don’t think you’d want the extension table to be auto-generating. I think you’d just want to define the same primary key name and type.

Userlevel 3

So I am not talking about a key that gets number in Acumatica, I am talking about SQL Primary keys (I think that is the correct term). 



Badge +11

Correct, I understand. If you’re saying you were getting an error because of how the key was named, I don’t believe you can have a primary key constraint with the same name anywhere in the same database. That may have been your issue.

Aside from that, I believe Acumatica handles filling in the key fields of the extension table with the values of the key fields from the original table, which is why I don’t believe you’d want it to be auto-generating, but as I said before, I don’t know this for sure.

Userlevel 3

Woops I miss read/understood your last message, I had a brain fart reading “identity key” and thought you were refencing DAC declarations.

Yeah I would also set the key fields to be the same as the original table as mentioned in the article I followed, I have since started giving them names when I create them with a script. I think you are right about overlapping key names being the main issue, I haven’t run into it for a while.


About Acumatica ERP system
Acumatica Cloud ERP provides the best business management solution for transforming your company to thrive in the new digital economy. Built on a future-proof platform with open architecture for rapid integrations, scalability, and ease of use, Acumatica delivers unparalleled value to small and midmarket organizations. Connected Business. Delivered.
© 2008 — 2024  Acumatica, Inc. All rights reserved