T210 Customized Forms and Master-Detail Relationship

In the T210 training course, we learn to setup a new screen using a Master/Detail (Parent/Child) relationship.  This is, perhaps, the most common type of screen used for data entry.  For instance, if we look at the Sales Order screen (SO301000) we see a header (master) describing the sales order itself, and then we have several tabs containing additional details.  The header of the Sales Order screen reflects a single order, and the Document Details tab shows all the line items that have been ordered.  Structurally, these are the SOOrder and SOLine DAC’s, respectively.  The T210 course teaches us the basics of how to create such a screen, continuing the progress of development of repair services for the Smart Fix company.

To get started, we learn to create a custom column in an Acumatica ERP database table, add the field to the DAC, and place a control on the screen form.  In this case, the field is added to an existing table, so we will use a DAC Extension to add the field to the DAC.  In step 1.1.4, we learn how to create classes for constants that will be used to turn our new field into a pre-defined selection list.  While the examples embed the list directly into the field definition using PXStringListAttribute, I prefer the clean structure of defining an class (i.e. MyListClass) and attribute (i.e. ListAttribute) so that the DAC field simply states [MyListClass.List()] instead of all the extra code within the field directly.  An example of this is SOOrder.Status which uses [SOOrderStatus.List()].

Next, we learn how to define the master-detail relationship between the two DAC’s using PXParent and PXDBDefault.  Interestingly enough, the master side of the relationship takes no extra effort to define.  The key fields must be defined whether it is a master-detail relationship or solo DAC.  That being said, you will want to number the lines in the DAC on the detail side of the relationship, so we will add a LineCtr (name can vary) field to the master side to help with maintaining unique line numbers.  Once your LineCtr field is setup in the master DAC and using a PXDefault(0) attribute, we define the PXParent and PXDBDefault attributes to make the relationship between DAC’s and populate the corresponding key fields in the detail (child) DAC.  We will use PXLineNbr on the key field used on the detail record for storing the line number.

Personal Note: One of the things I liked most about the early set of new training material is the constant use of FBQL.  I was excited when I saw it was coming soon, but then I never quite grasped how to leverage it.  The training teaches use of basic FBQL and reinforces it in every coding exercise.  Since I learned on BQL syntax, the transition to FBQL was a little intimidating.  However, as I learn to use it, I am once again excited about the simplicity of writing and tweaking my FBQL statements.  The pain of managing brackets on BQL should drift into a distant memory with time!

The training guide next takes us through configuring controls on the screen. One very important properties for Grids is SkinID as that defines which base controls to display. “Details” provides basic buttons for Add, Remove, Export to Excel, etc. Inquire allows exporting to excel and refreshing the screen, but excludes the add and remove buttons. Explanation of each SkinID can be found in help at: https://help-2019r2.acumatica.com/(W(1))/Help?ScreenId=ShowWiki&pageid=ce75ce73-a264-41a6-9545-68ffe2003d45

Additionally, we learn about CommitChanges, AutoRefresh, and SyncPosition. When changes to a data field must prompt some immediate action, the CommitChanges property of the data field must be set to True. AutoRefresh must be enabled when you want a selector to refresh the list before displaying the control to the user so that the user does not have to click the refresh button manually. SyncPosition is used on Grids to Synchronize the the grid row with the “Current” of the view behind the grid.

While PXSelector and PXDimensionSelector are very powerful tools for the developer, sometimes we need to restrict the options made available to a user. PXRestrictorAttribute makes this task simple. The simple syntax is:

[PXRestrictor(typeof(Where<...>), "InsertMessageHere")]

Next we learn to update fields of the same record during the FieldUpdated event as well as fields of another record during the RowUpdated event. Questions often appear on StackOverflow related to this topic. Either someone is asking how to do it or the problem posted boils down to improperly attempting to perform this function. Refer to sections 2.2.2 and 2.2.3 for examples and full explanation.

As the training nears the end, we are guided through creation of a new tab on an existing screen. This requires adding a view for the grid used on our new tab and configuring the tab, grid, and some of the fields. In some cases, the tab may not apply and carry a goal may be to hide it. If the view used on the tab is called MyView, add into the RowSelected event of the primary DAC:

MyView.Cache.AllowSelect = [condition to make visible];

In section 4.1.2, we learn to use PXFormula to sum up values from the detail lines in a master-detail view and store the sum in a field of the master/header. The first parameter is defined as null to simply add the value of the field to the value of the master field or a formula when values must be combined such as multiplying a quantity and unit cost to comprise an extended cost to be pushed to the master/header.

The training completes with insertion of a default record. In the training, we learn to define a default warranty to be attached to the item and making it unavailable for edit.

Summary

As you can see, the T210 course is loaded with training and examples of very common activities that a developer must perform to deploy a solution in Acumatica. Over the last 2 years, I’ve employed about 70% of the training in T210, and review of the new T210 course has given me some new insight for improvement. At this point in training, the only thing I’ve done with any frequency that hasn’t been trained is Actions (which have been touched upon) and Processing Screens. Fortunately for us, there are training guides dedicated to both of those as well as more on Data Entry screens and Inquiry screens.

Unless you are really pressed for time to get through the material, this is a good time to take a training break and practice what you have learned. The T220 course will go into more detail on Data Entry forms, so we will use much of what we learned in T210 but in greater detail.

Leave a Reply