Revision History UI for Label Design Version
When you have a product label version that’s in draft, you can keep revising the template file (label design version) that is used. This means that whilst the product label version is in draft, it could have several revisions of the design associated with it. You may want to go back to an earlier revision, for example, if you find the latest one not working as planned.
In 8.6, the Version History screen allows you to download an earlier revision. You can then make changes to the downloaded revision and use the Upload Template pop-up to upload it which will then become the latest revision (in the image below, the next revision would be 8).
The Version History screen also gives you a history of the design and shows who edited it and when before the version was approved.
Item Status
The image relates to the improvements that have been made to the Item Status screen related to the Bill of Materials quantities.
BoM Required Quantities
You have a BoM slot, and it may accept multiple candidates. The quantity required for a BoM slot could be defined in two places. It could be defined at the BoM slot level or at candidate level. Also, it is possible for a BoM slot’s candidates to have different quantities. For example, a candidate that’s a concentrate, may require half the volume compared to the regular candidate.
Historically, it wasn’t clear which quantity to display in Item Status. In 8.6, the Bill of Materials screen shows the Required Default Qty based on the default candidate. The Built % column shows what was already consumed from a BoM slot, taking into account any adjusted candidate requirements. In our example, using the concentrate candidate would reflect correctly in the built percentage used as it will be a higher percentage compared with just the regular candidate being used. This is best described by way of an example:
Assume you need 10 units of the regular candidate but only 5 units of the concentrate candidate. If you consume 1 of the regular candidate, then you are 10% complete. If you consume 1 of the concentrate candidate, then you are 20% complete. The Built % calculates the completion percentages in this way and therefore accounts for which candidates were used.
Furthermore, previously it wasn’t mandatory to specify the quantity on the BoM slot, even though all candidates also had to have quantities. If the BoM slot was left blank the requirement was calculated to be 0, even if required quantities were entered at candidate level. Now, the BoM slot qty has been removed and this value is now obtained from the default candidate.
Unit of Measure
In 8.6 the unit of measure has been included in the Item Status screen, based on the default candidate UoM.
User login
In 8.6, the Principal Name field maps to the User principal identifier in Azure AD. You need to populate this field to automatically federate your account with Azure AD. This is usually the same as your email address but not always.
In the past, when we federated to Azure AD, we used to map just the one email address which resulted in emails never reaching a user where their email address differed from the User principal identifier in Azure AD. For example, a password reset email would never reach the user.
In 8.6, the Principal Name field was added to support the federation with Azure AD. This keeps the email so that the system emails can reach the user even when their Email and Principal Name differ.
Note that federation now happens automatically when the Principal Name field is populated. There is no longer the required step to click the Link AzureAD button.
Public API
The APIs continue to be improved in 8.6.
Trigger on Pre-production Status
Previously, an outbound universal trigger would send a message when a recipe was approved. It did not send a trigger when a recipe was set to pre-production status.
In 8.6, a trigger would be sent for pre-production status as well. Note that the pre-production status is there to support real jobs in ERP and real work on the shop floor but is not approved to go directly into good stock (complete to hold status).
Unique ID on Build API Parameters
You can have many materials with the same serial number. What identifies them is their unique reference. The inclusion of the unique id in the build parameter now allows all material to be uniquely identified.
Updated IntegrationFunc
Allow {} within endpoint. Function will take the parameters specified in the endpoint and substitute it with the first value found with matching key within the payload.
Example:
"Endpoint":"http://v82qa-postgres.gcp.optessacloud.com/api/plants/{plantId}/parts/{part}",
it will read the payload and substitue plantId and part with the first matching value it comes across.
Workflow
The user experience on the Design Workflow screen was improved in 8.6. Now, when you hover the mouse over a workflow node flow arrow, it thickens making it an easier target to right-click to access its menu.
Translations
Previously, translations supported column labels, buttons, etc. In 8.6, translations have been extended to data returned by SQL queries. Now grid contents, not just labels, buttons, etc., on grids, can be translated.
Workstation
A workstation is always viewed in the context of a device and a device might be linked to many work centres. The list could be very long. You can now order the list of work centres, by dragging and dropping, so that the most important ones can be displayed at the top of the dropdown list. Note that the Default work centre will always be shown at the top of the list and the rest can be sequenced below it.
Rework Mode on Checklist
When you return to an action that requires that a specific checklist is completed you now have the choice of starting a new one or referencing an existing one (for an item or an operation).
In the past you could only do this if you returned to the same operation that had the checklist. If however, you routed to a different operation (for example a rework operation), there was no way of accessing and reopening the check results set.
In 8.6, an option to “Copy results from latest result set for item” allows you to copy the results from the latest check results set for the item. You can then edit those results on the new, copied checklist results set.
Example of copying results set for item: An item has been checked in a production operation and there is an issue with one of the results, so it is routed to a rework task. In the rework task the same checklist is loaded, displaying the results collected in the production operation for the operator to analyse, work on and correct. Once rework activity has taken place, the new copied results set can be updated with new results in the rework operation.
Example of copying results set for operation: A checklist is completed in a production operation and there is an issue, so it is routed to a rework operation to be fixed then back to the original production operation for rechecking. In this scenario you may want to copy and display to the operator the original non-conforming results recorded in that operation, allowing the operator to record results that are now compliant.
