AcumatiCares
One of the great features of the Acumatica XRP Platform is that it eliminates the need for a lot of custom coding via Attributes. For example, the Stock Items screen provides attributes according to the item class of the item; the Vendor screen provides attributes based on the vendor class; and the list goes on and on. What makes this feature so incredible is that the system administrator can set up a list of attributes to be maintained according to the classification of the item, vendor, etc. While these attributes could be values that have no placeholder in the system yet, they also may vary from class to class.
The Acumatica XRP Platform holds many screen and code examples that can be copied to add attributes to custom screens. However, what if the goal is to display the attributes from ANOTHER screen… from a related object? Fear not. The process is quite easy for a developer and can be broken down into 3 easy steps as I illustrate below.
To set the stage, a business requirement has been received to display various tabs of data related to an item from the Stock Items screen, so the attribute tab on the custom screen will look to InventoryItem for attributes. Since this is intended to be defined for visibility rather than maintenance, be sure to lock down access to maintain the attributes tab via permissions or code. (Disclaimer: This 2021 R1 code has not been tested for maintaining the related attributes!)
Step 1 – Create a custom version of CRAttributeList
GIST: https://gist.github.com/BrianMRO/6e442e41e0dcaa748f6efceb8c67aeed
This code may look complicated to new developers, but it really isn’t. Most of the important code is in redefining SelectDelegate so that we retrieve the related object and fetch its attributes. The bulk of this section is because we must copy the constructor and all the internal and private methods and variables from CRAttributeList to make them accessible since their protection level makes them inaccessible through inheritance. Remember, technically inheritance lets them be inherited, but that does not mean they are accessible to you in your new class.
Taking a closer look at SelectDelegate, the current MyDAC record is retrieved from the cache, and then the related InventoryItem record referenced in MyDAC is retrieved. Passing the InventoryItem object (item) into SelectInternal will allow the rest of the attribute to function normally but based on the related InventoryItem rather than the MyDAC record of the custom screen.
Step 2 – Define the Answers view for the Attributes tab
GIST: https://gist.github.com/BrianMRO/4e78a158f7dce459395c6b5710d95a06
This mirrors the use of CRAttributeList for obvious reasons. The custom attribute is based on CRAttributeList, and the name basically is the only thing that changes here from any other screen.
Step 3 – Add the Attributes tab
GIST: https://gist.github.com/BrianMRO/ae4e7bb280477faa80a54c7b3bce6e46
This .aspx code can be copied from almost any screen that contains an attributes tab. It simply looks to the Answers view to populate the standard grid.
After compiling, updating the customization project with the new DLL, and publishing the project, the new Attributes tab should display the attributes of the related object from within the custom screen.
Happy Coding!
