Application Framework

Detailed Audit Trail - Workflow, BOM and Checklist

As of this release, authorised users can view a complete and detailed audit history of every change made to:

• A workflow version and its constituent entities (workflow version, operation node (including start and end nodes), operation action, flow).

• A BOM version and its constituent entities (BOM slots, candidates).

• A checklist and its constituent entities (checklist steps).

Display-name resolution, structured filtering, and export capability are included in this update, enabling auditors and quality personnel to review the full evolution of a workflow without needing cross-reference internal database identifiers.

Electronic Control History Record (eCHR)

ECHR Document Line Types - Multiple Document Type Supported

Previously, a single document type had to be specified, limiting the scope of what each eCHR line could capture.

Manufacturing an item often requires multiple supporting documents. For example, a product document line type might reference both a product drawing and a product specification.

To support this without creating a separate predefined line type for each document, a document line type can now be configured to include all document types within a selected category. For example, an issue document line type can capture all documents associated with an issue, including images, test information, and other related files.

If more control is required, the configuration can be limited to multiple selected document types within the same category.

Operation Quantity Completion Line Type

The ‘Operation Quantity Completion eCHR’ line type configuration has been updated to display source and target workflow name and version information, replacing the previous display of workflow name only. 

This update ensures that eCHR records provide a precise and unambiguous reference to the specific workflow versions involved in a quantity completion event.

Record Label Scan Metadata against eCHR Label Print line

Within a regulatory environment, it’s a requirement to create and store a scan of the label that was printed so that you can prove it’s the correct label. This can be achieved by printing a sample label, taking a photo of a label or scanning a label that can be stored electronically in blockchain.

In addition to the eCHR recording information about when a label was printed and who initiated the print, it now also records a scan against a print job that is associated with an eCHR. The system now records the scan metadata, including who scanned the label, the scan date and time, and the scanned image, to the corresponding eCHR label print line.

This ensures that the eCHR contains a complete audit trail of label verification activity, not just the print event itself.

Website Report

Printable Report

Extended Label Print Audit

Whilst label printing is on the surface a straightforward transaction, in practice things can and do fail, e.g. print jams, printer runs out of paper mid print, printer loses connection to the server. The eCHR label print audit has been extended to support multiple trigger events across the full label print lifecycle, enabling users to manage the record stored in the blockchain to support and record what actually happened, while retaining a full audit trail.

The system now captures eCHR audit records at each significant stage - initial print, scan image attachment, and subsequent updates to the print queue record (e.g. scrap, manual status change) - ensuring that the eCHR reflects the complete history of label verification activity. 

Each trigger either creates a new eCHR line or upversions an existing one, maintaining a precise and auditable record.

• A new eCHR line is created when a print job reaches Printed status and the print quantity is greater than zero, recording print quantity, printer, print timestamp, and the user who printed.

• A subsequent trigger fires when a scan image is uploaded, updating the eCHR line with the scan image and associated metadata.

• Further updates to the print queue record after printing, such as quantity changes or scrap events, trigger an additional eCHR line upversion to reflect the latest state.

• In the case of a manual override to a print job e.g. a job fails mid-way through printing and the actual printed quantity is manually set, this triggers an upversion of the eCHR line to reflect the corrected numbers (with full audit trail maintained).

• Each trigger event results in either a new eCHR line or an upversion of an existing line, preserving a full chronological audit trail.

Configurable eCHR Header

The eCHR profile header is now fully configurable through a no-code configuration tool, enabling system configurators to define the content, labels, ordering and aggregation displayed in both the eCHR listing view and the printable report without requiring developer involvement or code changes. For detailed information, refer to the eCHR Profile documentation. For detailed information see Configure Data - eCHR Profile Header documentation.

ECHR line types were always configurable to allow customers to control exactly what information was stored in the blockchain and how it was displayed in the website and in the printable report, however previously this required some complex coding and could only be done with the help of the Eyelit Services team.

In this latest release, configuration is now in the control of the end user. For almost all eCHR line types (except those that are fully customisable, such as the “generic eCHR data WF action” line type), the user can configure:

• What data is stored in blockchain records.

• How that data is labelled.

• What data is stored in the summary information including aggregation logic where applicable (e.g. list BOM slot candidates vs count of BOM slot candidates).

• What data is stored in the detailed information of the website report and printable report.

• What order the information is displayed in.

When one of these line types is added to an eCHR template, the system applies a consistent starting configuration for field sequence, labels, view visibility, mandatory status where applicable, and blockchain inclusion.

This change covers the following configurable eCHR line types:

• As Built

• Product Document

• Action Completion

• Case Data

• Checklist Document

• Checklist Step Document

• Issue Document

• Item Adjust Qty Actual

• Item Adjust Qty WIP

• Item Document

• Item Note

• Item Serial Number Change

• Item Split

• Item Summary Data

• Label Print

• Recipe Document

• Scrap Available Qty

• Tool Use

• BOM Definition

This change does not remove the option to fully customise a line type when a customer requires unique information. Administrators can override the defaults after they have been applied. However, the customisation screens are hidden by default and require specific permissions and support to view or edit. This helps prevent inadvertently creating invalid configurations.

BOM Version Consistency Within an eCHR

The system now enforces BOM version consistency within an eCHR, ensuring that each eCHR covers only items manufactured against the same BOM version. 

This safeguard preserves traceability integrity by preventing an eCHR from referencing multiple BOM versions, which would make it impossible to provide an unambiguous record of the materials used and the comparison of as built against BOM definition.

Where the eCHR profile is configured to record details of all items on a job in a single eCHR, the BOM version is fixed on the job header the moment any item on the job is started. 

Items can be transferred to a new BOM version if needed but this is 'all or nothing' - the 'transfer all' button (available in schedule manager / items) will automatically move all items to the new BOM version and ensure that the job header is consistent for all remaining unstarted items. 

If an item needs to be moved onto a different BOM version vs the other items on the eCHR, this must be split off into a new eCHR (Split eCHR button on the eCHR Listing screen).

Where the eCHR profile is configured to create an eCHR for every item on the job, there are no specific restrictions relating to eCHR when it comes to changing BOM version for any or all items.

Scheduled Workflow Version Consistency Within an eCHR Header

For jobs that record multiple items on a single eCHR, the starting workflow must be consistent across all items. The job header workflow version is therefore fixed when the first item is started. If the job has not yet started, authorised users can still update the workflow version.

The eCHR now records the workflow version used to start each individual item, rather than relying only on a header-level value copied from the job when the eCHR is created.

The eCHR header records the starting workflow specified on the job. Because items can follow different workflow paths during manufacture, subsequent workflow activity is recorded in the eCHR content for each item. This ensures that transfers to other workflow versions, such as those caused by engineering changes, routing corrections, or non-conformance processing, are captured against the affected item.

This update supports scenarios where an item moves to a different workflow version during manufacture, or where a job includes multiple items that start after the job workflow version has changed.

• The workflow version is recorded at item level where applicable within the eCHR (e.g. operation completion), providing an accurate record when items execute across more than one workflow version.

• Mid-manufacture transfers to a different workflow version are reflected in the eCHR record for the affected item.

• Jobs that include multiple items on a single eCHR record the workflow version executed for each item.

• Label Design dropdown displays human-readable design names rather than internal database identifiers.

• Only label designs with at least one approved version are available for selection.

• Label designs linked to a different product are excluded from the dropdown in product-specific workflows.

• Where the label design is a product related label design (advanced label printing only), the user then has the option to specify associated product label version logic i.e. use latest approved version vs use-specified version (latter for product specific workflows only)

• Printer selection is now optional at configuration time, allowing printer assignment to be resolved at runtime based on the operator's workstation or device and the printers assigned to the label design.

‘Label Print’ Workstation Action

The Label Print workstation action has been updated to support dynamic printer selection and flexible quantity defaulting at runtime, in line with the corresponding changes to the Label Print action configuration. 

Operators are now presented with a printer selection drop-down populated with all label printers assigned to the relevant label design, ensuring the correct printer options are always available regardless of which workstation is being used. The dropdown will always default to the printer linked to the device the user is working on (if applicable). The quantity of labels to print is pre-populated based on the quantity logic defined in the action configuration.

‘Label Print with Preview’ Workstation Action

This feature enhances the existing label print action screen to guide the operator step-by-step through variable data entry, side-by-side label preview vs. master reference, print job management with Bartender integration, and full label reconciliation, including scrap, reprint, and mandatory scan capture, with pre-completion warnings that surface any outstanding obligations before the step is signed off. The result is an action that is both more intuitive for the operator and meaningfully closes gaps against 21 CFR Part 820 / ISO 13485 traceability requirements.

The label print with preview action has been specifically designed to aid the business in adhering to strict label checks, scans and reconciliation. The operator is guided through the required steps:

1. Select a printer. If the printer is connected to your device, it will assume that’s the one you are using and will generate a preview.

2. Create a label preview. You can’t print before the label preview is created.

3. When the preview is generated, the operator will compare the preview with the verification image to make sure it is compliant.

4. The operator can then print the number of labels specified in the ‘# Labels’ field which defaults to the number specified in the print action (usually target quantity = offset + factor*quantity).

5. The screen keeps a running target of how many has been printed in the right-hand grid on the image above. It tracks what was printed as well as what’s in the print queue to prevent you from sending too many to the print queue. If you have enforced reconciliation enabled, it will prevent you from overprinting.

6. The ‘Manage’ button provides a dropdown where you can select to scan, scrap, reprint or history (shows all the print jobs that have happened).

Label Print Service Log

You can run the label print service from more than one device. Each print service runs on premises and connects to the system through its own IP endpoint, so several users in different locations can print labels at the same time.

For example, a site may use one site label print service for production printing and other print services to run test prints without affecting print management for the site - you can set up a separate print service on another device, such as your own laptop. 

In this release, the system records a detailed history of sync and label print service activity, making it straightforward to identify which service instance is running, where it is running from, and which version of the software it is using. 

Previously, service poll data was overwritten on each poll, making it impossible to determine the source of a running service when multiple instances were active simultaneously.

Populate Product Label Field from Source

Product label designers can now populate product label data fields directly from source data in the system by using the ‘Populate from source’ option. This removes the need to type values manually, which reduces errors and saves time when you enter complex values such as GTIN numbers.

You can populate fields from sources such as the following product name, product description, and product properties.

The system populates the field from the source once and then caches the value. The value stays fixed even if the source data changes later. This keeps product label data controlled and consistent with the approvals process. It allows you to populate controlled product label data fields from source data such as product name, product description, SUID and product property.

Label design fields compared with product label data fields

This option applies only to advanced label printing. It's important to understand the difference between data fields in the label design and data fields in product label data.

Label design fields map data in the MES to fields and parameters in a BarTender template. SQL-generated fields are dynamic. The SQL runs each time you print a label or create a label preview, so the field always shows the current data. An example of this sort of data might be item serial number, manufactured date or expiry.

Product label data fields store a single fixed value which has gone through an approval process. The value goes through the full product label approvals process, where approvers sign to confirm that it's compliant for the product. Later changes to data in the system do not affect the approved value. This is better suited to static controlled data such as product description.

For example, if you change a product name, a SQL-generated label design field for the product name shows the new name. A product label data field for the product name keeps the approved value.

Product Label Approval and Verification Improvements

Improvements have been made to the product label approval workflow by supporting individual label version decisions, consistent verification-image terminology, controlled document enforcement, and clearer approval traceability. 

Granular Approvals

Product label approvals are now granular. Previously, approval was all or nothing, so if one label in a batch of 200 failed approval, you had to discard the whole approval and start again. You can now record a decision against each requirement for each product label version individually.

You can't complete the final approval while it contains rejected product label versions. To handle a rejected product label version, remove it from the approval. This reverts the product label version to draft, so you can fix it and then reinstate it if you choose or leave it out of the approval.

The final approval still takes place at the end of the process. You can complete it only when every product label version in the approval is accepted or removed. Removed product label versions are excluded from the final approval.

When someone removes a product label version, all approvers working on it across all requirements can see the change. When the product label version is reinstated, the system resets all decisions recorded against it, because any part of it might have changed.

Other Enhancements

Enhancements for product label approvals include:

• Verification image terminology is used consistently across the product label version and label print preview workflows.

• Administrators can view verification images from the Product Label admin screen, and uploads are restricted to product label versions in Pending Approval status (as verification images could become invalid if linked to draft versions).

• Product label approvals can use only controlled documents as supporting documents or evidence.

• The approvals pop-up shows the decision associated with a selected product label version, making approval history easier to interpret.

Item Status – Labels Screen

A Summary section has been added to the Item Status – Labels screen, giving users an immediate overview of label print activity for a selected item without needing to inspect individual rows in the print queue grid. 

The summary section appears above the existing print queue grid and presents a consolidated view per label design, enabling operators, supervisors, and quality managers to view label status at a glance. The section is displayed only when relevant label data exists for the selected item and shows the full lifecycle of each label, from print through to scan verification.

A ‘Scan History’ button is displayed within the Item Labels section for each print queue job associated with the selected item.

• The summary section shows label type, label design, quantity printed, quantity scrapped, and the difference between quantity printed and quantity required.

• Quantity required is displayed only for label types subject to reconciliation; it is absent for non-reconciliation label types.

• Entries where the quantity printed exceeds the quantity required are visually distinguished to enable immediate identification.

Restrict Label Scrap to Printed Jobs

Production operators can now record scrapped quantities against label print jobs, ensuring that inaccurate or damaged labels are properly accounted for and removed from the active job count. 

Scrapping is restricted to jobs in 'Printed' status, enforcing process integrity and maintaining traceability throughout the label print lifecycle. Note that it is now possible (with eSignature and correct permissions), to manually manage print status and quantity. If a print job is in printing or error status it can be cancelled and an actual printed quantity manually set. This capability is in place for situations where there is a printer issue, e.g. loss of connection to the server and so the print job is in error, even though some / all labels have been successfully printed.

Upversion Mode for Linked Product Label Versions

Authorised users can now configure exactly how each group of linked product label versions is handled during a label design version up-version, with mode selection presented as a dedicated configuration step within the up-version workflow. This feature provides the flexibility and control needed to manage complex label version relationships during label design up-versioning workflows.

Configuration options are displayed only for status groups where at least one linked product label version exists, keeping the interface focused and relevant.

• The upversion mode configuration step displays only the status groups, Production Approved, Draft, and Pending Approval, for which at least one linked product label version exists; groups with no linked versions are hidden.

• Selecting 'Upversion' for the Production Approved group results in a new product label version being created for every linked product label version in that status upon completion of the up-version process.

• Per-status mode selection gives authorised users precise control over the treatment of linked product label versions across all relevant statuses during the up-version process.