Best Practices Naming B1UP Universal Functions

Background:

B1UP Universal Functions (UF) have several header fields that can help organize and document your definitions.  Here's a short description of these fields (see the online help for details):

• Code – Required. This is the basic identification of the UF.  It must be a unique value across all UF Types and is unique within the database.
• Name – Required. This is a 100-character field that serves as a description of the UF.
• Remarks – Optional. This is a 254-character field that can be used for additional documentation of the UF.
• Category – Optional. Provides the ability to group B1UP definitions including UFs based on user-defined Configuration Categories.
• Type – Required. Defines the type of UF (i.e., Macro, SQL Report, etc.)

Our focus in this article is the UF Code field.  When adding a UF B1UP sets the default value of the Code to UF-SSS where SSS is an incrementing sequence number.  Once created the UF Code cannot be changed even if the UF is not used anywhere else in the system. 

Tip: To rename a UF, first use the Duplicate function on the original UF applying the desired value in the UF Code field.  Second, use the 'Where is this UF used?' function to find all places that use the original name and change all UF references from the old UF Code to the new one.  Finally, Remove the original UF.

Best Practices:

Determine a naming scheme that ensures descriptive and consistent UF Code values are defined so that each UF has a unique Code across all systems where it could be used.  Here’s one example:

NNN-UU-FF-PPP-T-SSS where:

• NNN = Partner’s SAP Namespace (i.e., BOY for Boyum)
• UU = Reference to end User’s name (i.e., AE for Acme Explosives)
• FF = Reference to screen or Form (i.e., SO for Sales Orders, etc.)
• PPP = Reference to Purpose (CIT for Check Item)
• T = UF Type (i.e., M for Macro, S for SQL Report, U for UDT Handler, G for messaGe, etc.)
• SSS = Sequence (i.e., a counter or sequence number to ensure uniqueness)

The key is to have a consistent structure that gives an idea of what the definition does without needing to load the function or even look at the other UF header fields.  All-purpose values such as UT for Utility should be considered since some UFs could be used everywhere in your system (such a macro that does global functions like executing the SAP Fit Column Width option).

Another approach is to include in the Code a reference to a change request, support ticket, or other document ID.  This can also be documented in the UF Name or Remarks fields.

Pros:

• Improves documentation of UFs which can be very helpful in environments where there are many definitions.
• Ensures that the UF Code will not change when the UF is Exported from one system and imported into another. Consider this case: A UF is created in database 1 using the system-generated Code of UF-001, and another UF is created in database 2 that does something different, but it also has the system-assigned name of UF-001.  When UF-001 from database 1 is imported into database 2 it will be given the name UF-002 because UF-001 already exists in the target system.  This can become an issue since UFs are referenced by all of the commonly used B1UP definitions (Validations, IPT, Right-Click Menus, etc.)

Cons:

• Some B1UP screens that reference UFs on forms (i.e., Right-Click Menu Creator’s Simple type or the Validation screen with No Condition) show the first 8-12 characters of the UF Code. This is a cosmetic point; these fields correctly store and honor the full length of the UF Code; you can see the full value when you scroll right and left through the field.  This is not an issue with UF Codes in grids (i.e., Add and Edit Menus or Function Buttons).  You can vote for the Feature Request to widen the display of these fields here: Field size of the UF field is too narrow to handle larger UF names – Boyum Helpcenter (boyum-it.com).