Skip to main content

Hello,

      I’d like to add 1 customized field on SOShipLineSplit dialogue,  It would be easy,  just after add controls on screen, the system would automatically generate a cs file to define the data class. User only have to define the attribute, and system maintain other codes.
    However, strangely, unlike other screen (Which means other screen are customizing perfectly) , the file generating on SOShiplineSplit data class are missing a “PX” at the beginning, the first line.


      Hence,  I get an error on Validation.

 

       This error actually existed for a long time. Although I can manually change the PX_Objects_SO_SOShipLineSplit_extensions.cs file to let it pass validation.  But is there a way to solve this issue permanently?

Has anyone else tried to customize on Soshiplinesplit screen?  And met this same issue as I have?
Can someone give me some help?


I normally do my DAC extensions in an extension library (DLL) via Visual Studio where I build the DAC  class manually.  I can try reproducing the issue tomorrow, but what version of Acumatica are you using?


Yes, it should be PX.Data.ReferentialIntegrity.Attributes. I checked it using the Visual Studio and it shows error if it is only Data.ReferentialIntegrity.Attributes so I added the PX file code and it shows no error anymore.


@Brian Stevens @palbores  Hello experts, sorry for the late reply. I am out of office for a week.
I am using 2021R1 currently. But this issue exists for a long time, probably starting from 2018.

Now, can you teach me how to fix it? I mean, how can I manully modify the “PX_Objects_SO_SOShipLineSplit_extensions.cs ” system generated. Every time, I modifiy it directly on hard disk, it would be overwirted by system during the compile process.
it looks like Acuamtica maintenace this file itself.


You don’t edit files directly in the filesystem unless you have moved the code to an extension library, i.e. into a Visual Studio project.  Since it is listed under Data Access, you do not seem to have done that.  If your DAC/cache extension is listed under Code, that is where you would updated it.

I did this in 2022.114.0029 (2022R1) with similar results.  (Refer to line 1 in the picture above.)  Look to see if you can find SOShipLineSplit under the section Code and if it has the definition for your field.  If you make the change to the first line shown above, then you should be able to save (disk icon) and publish the project to pick up the change.  This is assuming that I am looking at the same place you need to be looking.

You should attempt to reproduce the problem and fix it in a non-production environment first.  If successful, you can update in production.  The proper course at a minimum would be to update the project in a development environment, preferably publish to a quality assurance environment to test, and then publish the QA verified package in production.  I do not recommend making this change directly in the project in production because you run the risk of making an unsanctioned (erroneous) change that you did not intend and break your production environment.


@Brian Stevens  Thank you so much, you have helped me sovle my long time headace.

To whom also interested in this topic, let me summarize here.

The Issue:
1, When we cusotimize a screen, like SOshiplinesplit screen and adding customized field.  Acumatca would auomatically create Data class in the custmization project editor.  Everytime , when the custmization project is published, the Data class would automatically be converted to a file, like PX_Objects_SO_SOShipLineSplit_extensions.cs.  Normally, this could be fine. But for some screens, the auto generated file is missing key words, which can not pass compilation.


My previous little trick:
Wrong Way: I tried modify the file PX_Objects_SO_SOShipLineSplit_extensions.cs. on my publishing system, but since the file would be regenerated every time publish, it would be overwritten.
Little trick:  I delete the “So.soshiplinesplit” in the project editor, which does not let it to generate the file every time publishing. Then I prepare a correct file “PX_Objects_SO_SOShipLineSplit_extensions.cs.” and copy it into the run time code folder on the sever before publishing the customization project. It could be fine, I work with it several years.

But this trick is with limitations, others can not publish my project successfully without get my cs file. And others have to get the access to server hard disk.

The best solution:
Thanks to Brian. You can Choose the issue data class and click “Convert to extension”

 

And then, it would become a code file, which would not be overwritten anymore.
Acumatica name it automatically SOShipLineSplitExtensions.cs

 


Reply