VPE Management and Configuration Enhancements
aPriori 2019 R2 includes several improvements to the Cost Model Work Bench (CMWB) which make it faster and easier for customers, aPriori Partners, and aPriori employees to update VPE data and develop or configure cost models.
• aPriori 2019 R2 provides a new approach for managing and updating the Labor Rate data which is used to calculate Labor Costs for all process cost models. This enhancement enables VPE Administrators to update labor rates much more quickly and easily than was possible in previous releases, and also provides end users more insight into the assumptions which drive labor rates. Previously, the Labor Rate field for every machine for every process had to be populated and managed individually. Updating the labor rates for an entire VPE therefore required entering updated values for thousands of machines, even though typically many or all of the machines for the same process use the same labor rate value. Indeed, typically there are less than 20 unique labor rate values across a VPE.
Now, labor rate management is greatly centralized and streamlined through the use of several new VPE tables. The Wage Grades table is used to specify the labor rates corresponding to different worker skill levels and process types. Skill levels are defined and described in a separate Skill Levels table. Both the Wage Grades table and the Skill Levels table apply to an entire VPE and are located at the VPE level within the VPE Manager. A specific wage grade then can be associated with each process, using the new Wage Grade Associations table for each Process Group. Machines will use the wage grade specified for the process, unless a different Wage Grade is specified for that individual machine using the new Wage Grade Name field. Pictures of these tables are shown below.
Benefits of the new Labor Rate data architecture include:
o Greatly streamlined data update process – this new data architecture reduces the number of fields that typically need to be updated by ~ 99%.
o Improved ability to leverage and inherit from aPriori Regional Data Libraries (RDLs) – Previously, if a company and its suppliers used a different skill-level operator for a given process than assumed in the aPriori RDLs, they would have to enter a different labor rate value at the machine level. This updated labor rate then no longer was associated with the RDL data, necessitating manual updates from that point forward. With the new data architecture, you can simply update the wage grade level associated with that process and maintain inheritance to the RDLs, so that future RDL labor rate updates automatically will continue to apply to the process and its machines.
o Visibility into Labor Rate assumptions – Users can see the Skill Level assumed for a given labor rate in the Formula Dependencies dialog, providing transparency that can be useful during cost estimate validation and fact-based negotiation
Note: if desired, labor rates still can be managed in the previous manner, in which you update the Labor Rate field for each individual machine. This provides your company the flexibility to convert to the new data architecture at a convenient time.
Note: in order to update an existing VPE which is using per-machine Labor Rate fields so that it uses Wage Grade Associations instead, you must clear the per-machine values to establish the Wage Grade Associations. For more information on how to do this, see the section titled “To assign a wage grade to a process” in the 2019 R2 version of the aPriori VPE Administration Guide.
Note: A new Wage Grades report is available from within the VPE Manager by selecting File è Export è Wage Grades. This report is an Excel spreadsheet with one row for each machine in the VPE, grouped by process group and process; it displays Labor Rate, Skill Level, and Wage Grade field values for each machine. When you are ready to update your VPEs to use wage grades rather than labor rates for individual machines, you can use this report to review the spectrum of labor rates assigned to different processes and machines within a given process. You can even convert the report to a pivot table using standard functionality in Microsoft Excel, to help analyze the data. This can help you to determine how many wage grades should be established, and which wage grade should be associated with each process or machine.
You also can use this report to determine if a machine has a labor rate or wage grade specified in its machine field or if it is inheriting a labor wage grade association specified at the process level. If the labor rate or wage grade is specified for an individual machine, the Labor Rate, Skill Level, and/or Wage Grade columns will be populated in the row for that machine. If the machine is inheriting its values from the wage grade association at the process level, those fields will be blank.
.
• Two usability enhancements were made to the Search CSL feature within Cost Model Workbench.
o The Search CSL tool (invoked from the Tools menu) now can search for filenames which contain the specified search string, as well as file content which contains the search string. This is particularly useful when looking for a specific library file in a cost model which contains many library files, and you recall only a portion of the library file name of interest. For example, to identify which library file in the Machining cost model contains logic related to achievable tolerance capability when all you recall is that it contains the string gtol, you could enter gtol in the Search String field and set the Search Type field to Filename, as shown below:
This search will return the names of any library files containing that string, and in this case would include the desired file (libGtolProcessCapabilities.csl)
o When using the Search CSL tool, files returned as search results now can be opened directly in the CSL Editor, enabling the user to easily inspect or edit the file of interest. Previously there was no direct way to open the file of interest; instead users had to browse through the cost model hierarchy displayed in the CMWB navigation pane to find it, which required knowledge of the cost model structure and many mouse clicks. Now the correct file can be opened with a single click via the new button Open in Workbench, located at the bottom of the Search Results pane as shown below.
o 
o
• The cost model artifacts Process Setup Options and Zero-or-More Routing Nodes were enhanced to provide additional control and simplify cost model configuration:
o For process setup option modes of type “List”, the expression for the available values now can be provided as a formula. Previously the values in the list had to be defined either from a custom CSL expression defined just for that node or from a comma-separated list of hard coded values. This improvement means that code can be simplified for list type PSOs.
o It now is possible to specify whether end-users can manually override the number of occurrences of “zero-or-more nodes” in a routing. These are routing nodes which can appear multiple times in succession as needed depending on part geometry and other factors, such as the Die Station operation for the Progressive Die process. This control is useful for situations where the calculation of number of occurrences is defined by another input or set of inputs, so that allowing manual override is not ideal for overall cost model behavior. For example, Core Refractory Coat instances are driven by the number of cores that require refractory coating, so the override should be made on individual cores not on the number of instances. To disallow manual override of the number of instances, set the value of the node attribute allowNumOccurrencesOverride to false on the zero-or-more node.
• Several new built-in CSL functions were implemented:
o logAndReturn(label, expression) – evaluates the given expression and writes the result to the aPriori log before returning it. The log entry takes the following form: <label>: <value>. This is particularly useful for places where CSL can be used to but debugging capabilities are limited, such as in CAD Attribute Mapping Files or Access Control.
o repeatString(string, count) – returns a string created by repeating the given string parameter count times. An empty string is returned if the string parameter is null or count is zero.
o isCollection(object) – returns true if the object passed in is a collection (e.g. a list)
o trim(string) – removes any whitespace from the start and end of a provided string
• Several existing functions were updated to be null-safe; for these functions null string parameter values are now treated as equivalent to an empty string:
o index(str1, str2, [index])
o lastIndex(str1, str2, [index])
o mid(string, startIdx, [endIdx])
o prefix(string, separator)
o suffix(string, separator)
o suffix2(string, separator)