Analytics Data Dictionary
When creating your own charts, you’ll need to select which metrics you want to include.
When you click the Add + button next to a widget panel, a menu will expand offering you all available Shoplogix metrics:
This guide explains each metric and provides examples where applicable.
The term “Dim” is frequently used, and is a short-form for “Dimension”. This is simply a technical term to refer to a common category of metrics.
Category | Measure | Definition |
|---|---|---|
Adoption | Downtime With Reason % | The total number of downtime hours with a reason divided by the total number of downtime hours |
Machines Reporting Scrap % | We have a calculated statistic called Machine-Days, whereby for example one machine over the span of two days is equal to two machine-days. This formula leverages this and calculates Scrap Usage % as the total number of machine-days with scrap reported and dividing by the total number of machine-days. | |
Machines Reporting Scrap % (Detail) | We have a calculated statistic called Machine-Days, whereby for example one machine over the span of two days is equal to two machine-days. This formula leverages this and calculates Scrap Usage % as the total number of machine-days with scrap reported and dividing by the total number of machine-days.
The detailed variant is specifically when pivoting the data range across days as opposed to larger time scopes. | |
Machines With Comments % | We have a calculated statistic called Machine-Days, whereby for example one machine over the span of two days is equal to two machine-days. This formula leverages this and calculates Comments Usage % as the total number of machine-days with at least one comment and dividing by the total number of machine-days. | |
Machines With Comments % (Detail) | We have a calculated statistic called Machine-Days, whereby for example one machine over the span of two days is equal to two machine-days. This formula leverages this and calculates Comments Usage % as the total number of machine-days with at least one comment and dividing by the total number of machine-days.
The detailed variant is specifically when pivoting the data range across days as opposed to larger time scopes. | |
Proper Rates % | GoodPerformanceHours is the amount of hours where the production rate was at or below the maximum expected rate. Proper Rates divides GoodPerformanceHours by Total Hours | |
Uptime with Job % | The sum of all uptime where the job name was not “N/A”, divided by the sum of all uptime. | |
Overall Score | The weighted average of all of the previously mentioned adoption metrics | |
Dim Areas | Division | The area levels above the Plant. Multiple levels will show only the highest 3 levels. |
Division2 | The area levels above the Plant. Multiple levels will show only the highest 3 levels. | |
Division3 | The area levels above the Plant. Multiple levels will show only the highest 3 levels. | |
Line | The area level configured as Line. | |
Line Area | The area levels below the Line. Mutiple levels will show only the highest 3 levels. | |
Line Area2 | The area levels below the Line. Mutiple levels will show only the highest 3 levels. | |
Line Area3 | The area levels below the Line. Mutiple levels will show only the highest 3 levels. | |
Plant | The area level configured as Plant. | |
Plant Area | The area levels below the Plant. Mutiple levels will show only the highest 4 levels | |
Plant Area2 | The area levels below the Plant. Mutiple levels will show only the highest 4 levels | |
Plant Area3 | The area levels below the Plant. Mutiple levels will show only the highest 4 levels | |
Plant Area4 | The area levels below the Plant. Mutiple levels will show only the highest 4 levels | |
Dim Dates | Calendar DateTime | This is, in almost all cases, your preferred Date to use – this is the machine time. If you’re looking for specific Job Start and End times, you can also use Job Start DateTime and Job End DateTime, but for 90% of your scenarios, we recommend using this Calendar DateTime. Note the Hour level is available only for the most recent 60 days of data: https://slxdev.atlassian.net/wiki/spaces/SLXDOC/pages/1186529359
All date fields in Analytics are displayed in the machine’s time zone. More information here: https://slxdev.atlassian.net/wiki/spaces/SLXDOC/pages/1480949763 |
| Day of Week | This is using the calendar day time to filter out the day of the week (for example if you do not run on weekends, this can be used to filter out Saturday and Sunday). Note - if you need to filter out for Shift instances day of week, use the Day of Week (Shift Start) measure under Dim Shift Instances. |
Dim Jobs | Job Blocked Cycle Factor | How many cavities are blocked per cycle. |
| Job Cycle Factor | The cycle factor from the job. When building widgets, use this field in the rows/groupings section of your widgets. For example, in a pivot widget, this value should go in the rows. IMPORTANT: if you are getting a very high value for your Job Cycle Factor, you may be accidentally running a SUM calculation against your Cycle Factor records. To avoid this, ensure your formula looks like MIN([Job Cycle Factor]), and NOT SUM([Job Cycle Factor]). Confirm your reports are correct carefully as you build Job reports with [Job Cycle Factor] in the values by trying the following:
If you need to understand jobs with different cycle factors in the same report we need to “blend” this value by adding all [Expected Production], then dividing by all [Expected Cycles]. This is an advanced reporting concept and you should contact your Customer Success Engineer for support. https://slxdev.atlassian.net/wiki/spaces/SLXDOC/pages/288194561 |
| Job Cycle Factor - Finished Goods | Finished Goods Cycle Factor. Multiple applied to base production counts to provide alternative reporting units |
| Job Cycle Factor - Inventory | Inventory Cycle Factor. Multiple applied to base production counts to provide alternative reporting units. |
| Job Cycle Factor - Line | Line Cycle Factor. Multiple applied to base production to convert into a common unit of measure across the line (e.g. convert chocolate bar count to lbs.) |
| Job Cycle Factor - Scrap | Factor applied to raw scrap signal to calculate base scrap counts. |
| Job Description | The Description field is used to display any extra information |
| Job Due DateTime | Date when job should be completed |
| Job End DateTime | This is the date when a Job ends running. All date fields in Analytics are displayed in the machine’s time zone. More information here: |
| Job Expected Electricity | Expected Electricity consumption per production unit. Used in energy calculations |
| Job Expected Employees | Expected, average number of employees that will be required for the duration of this job. Used in labour calculations |
| Job Expected Gas | Expected Gas consumption per production unit. Used in energy calculations |
| Job Expected Production | Expected amount of Production to be produced for the job |
| Job Expected Runspeed | Expected runspeed for job used in Variance Calculation |
| Job Expected Setup | The expected setup time for your jobs. The best way to use this field is either in a table or chart where you can separate it by Job Name. |
| Job Expected Water | Expected Water consumption per production unit. Used in energy calculations |
| Job Filter 01 - 20 | These are the same job filters that you configure when scheduling jobs |
| Job Instance | Often you will run the same Job Name multiple times. Each individual time you run a Job, Shoplogix creates a “Job Instance” record along with the job instance’s metrics. So for example, you can have a job called Job Name = “A”, and you can run Job “A” 5 times. You’ll still have a single Job Name in your analytics portal called “A”, but if you use the Job Instance field with it, you’ll be able to get the metrics and stats behind each individual time you ran Job “A”. Job Instance comes in the form of a a long, unique ID tag (example: efjk349dif9s0u30h208sfsdsf34sdf4”). Don’t worry, no one is expected to remember Job Instance IDs! The best way to understand Job Instances is by using them in conjunction with Job Name, Job Start Date, and Job End Date. This way you’ll have a better understanding of the parent job (Job Name) and you’ll be able to correlate the Job Instance with the date it ran. A great way to use Job Instance is when you’re trying to pinpoint if a job (via Job Name) always performs poorly, or if it only performed poorly during a specific Job Instance |
| Job Is Local |
|
| Job Max Run Rate | Expected run speed of job used in OEE calculations. Parts per hour. If you think in cycles, this is also equal to [Expected Cycles] * [Cycle Factor] |
| Job Name | Job Name is the human-readable name that you assign Jobs when scheduling. You’ll be very comfortable with this field as it is the same Job Name you see in Whiteboard. |
| Job Next Operation | Operation value of the machine that is to run this job after this machine. This is used to determine the flow of a job through a plant/line |
| Job Operation | Value used to validate the type of work needed for this job can be done on selected machine i.e. a stamping job should only be run on a stamping press and so the operation should be "stamping" and the machine the job is to be assigned to will have "stamping" as its configured operation value. |
| Job Pull Group | For future use |
| Job Ship DateTime | Reference date used in reporting to show when Job is required to be shipped out |
| Job Start DateTime | This is the time when each Job starts running. All date fields in Analytics are displayed in the machine’s time zone. More information here: |
| Job Status Blocked | For future use |
| Job Status Confirmed | For future use |
| Job Status Edited | For future use |
| Job Status Is Current | For future use |
| Job Status Pulled | Boolean field indicates when a job has been pulled |
| Job Timestamp | Field used internally to track the last time this record has been changed |
Dim Machines | Is Line | (field is retired in latest model) If the machine is a line or not. A Line is expressed as a machine that has this flag set to true. Since a line is expressed in the same production stats as a machine, we create an “Line Machine” with: Machine Name = Line Name Machine Id = Line_(bottleneck line machine Id) This “Line Machine” allows analytics as if the line was a single machine in native line units. |
| Machine Id | system field. |
| Machine Name | Machine Name as configured |
| Filter & Filter Labels | CS Expert can configure these with you - |
| Filter1-5 | CS Expert can configure these with you - |
| Electricity Cost per kWh | See Energy in Analytics documentation: |
| Water Cost per Litre | See Energy in Analytics documentation: |
| Gas Cost per Cubic Metre | See Energy in Analytics documentation: |
Dim Machine Security | Customer_Account | system field. |
| Security Machine Key | system field. |
Dim Pages | Page Assignee Name | Responded user of page |
| Page Created By | Page created user |
| Page Created DateTime | Created data of page |
| Page Current Status | Page Status |
| Page Department | Page Department |
| Page Id | Unique Page ID |
| Page Title | Page description/Title |
Dim Reasons | Reason Classification | Reason’s Classification as configured in the Machine’s Variables tab. For example: Performance, Capacity, Availability. |
| Reason Group1-4 | Reason Group as configured in a Machine’s Variables tab. |
| Reason Name | Reason Name |
| Reason Type | Reason Type as configured in the Machine’s Variables tab. For example: Downtime, Setup. |
Dim ReasonState | ReasonState Classification | ReasonState is a combination of Reason and State – all properties of Dim ReasonState are the Reason’s properties when a reason is present. When no reason is present, the State properties are used. |
| ReasonState Group 1-4 | “ |
| ReasonState Name | “ |
| ReasonState Type | “ |
Dim Recent Shifts | Shift Recency | Shift Recency is designed to be used for automatic scheduled emailing of standard duration reports:
This takes every shift that finished in the last 24hours or 7days or 1month. This table excludes the current in-progress partial shift. All machines must be configured with timezones for recent shifts to work properly. Consult your shoplogix configuration or customer success engineer to confirm your machine timezones. See for more info: All date fields in Analytics are displayed in the machine’s time zone. More information here: |
Dim Scrap Reasons | Scrap Group | Scrap Reason group as configured. |
| Scrap Reason | Scrap Reason as configured in the Machine’s variables tab. |
Dim Shift Instances | Shift Instance | A unique identifier to distinguish this shift from others with its name and start date. |
| Shift Name | As configured in the shift calendar |
| Shift Start DateTime | When the Shift Started. All date fields in Analytics are displayed in the machine’s time zone. More information here: |
| Shift End DateTime | When the Shift Ended. All date fields in Analytics are displayed in the machine’s time zone. More information here: |
| Shift Is Current | If the shift is the current active shift at the time of cube refreshing. |
| Shift is Last Completed | True for the most recent shift that is complete per machine. False for all other shifts.
|
| Day Of Week (Shift Start) | This is using the shift start time to filter out the day of the week (for example if you do not run on weekends, this can be used to filter out Saturday and Sunday but the actual Calendar day may be slightly offset by a few hours). Note - if you need to filter out for the calendar day of week, use the Day of Week measure under Dim Dates. |
Dim States | State Classification | Performance, Capacity, or Availability. |
| State Name | State Name as configured. |
| State Group1 |
|
| State Group2 |
|
| State Group3 |
|
| State Group4 |
|
| State Occurrences | At the beginning of a state change (Idle → Running, for example), this counter will increase by one. Will not be impacted by reason changes. |
Fact Core | Blocked | Parts blocked by blocked cavities. |
| Cycles | Cycles - * Includes unscheduled cycles. Use a measured filter to remove unscheduled production. |
| Duration for MTTR | RAW DATA required to calculate MTTR. Mean Time to Recovery is calculated by summing the time in non-failure states – this is that duration. Note: The MTTR formula is: (Duration for MTTR) / Stops |
| Duration for MTBF | RAW DATA required to calculate MTBF. Mean Time Between Failure is calculated by summing the time in failure states – this is that duration. Note: The MTBF formula is: (Duration for MTBF) / Stops |
| Expected Cycles | Expected Cycles
|
| Expected Production | Job Rate, or if there is no Job Rate, then the Machine Rate. |
| Good Production | Total Production - Scrap Does not include unscheduled production. See Good Production Including Unscheduled. |
| OeeProductive | Used to calculate OEE. Used for system calculations. Good / Rate |
| OeeRuntime | Used to calculate OEE. Used for system calculations. Total / Rate |
| OeeScrapByRate | Used to calculate OEE. Used for system calculations. Scrap / Rate |
| Reason Occurrences | Number of times the Reason was entered, for any duration. |
| ReasonState | see Dim ReasonState. |
| Scheduled Hours | Hours during scheduled shifts. Excludes capacity reasons and capacity states. |
| Scrap | Scrap in scheduled time. Note: Scrap Reason analysis is incompatible with this field. Use [Fact Scrap Reasons].[Scrap Reason Amount] when performing scrap reason based reporting. |
| Scrap Including Unscheduled | Scrap, all regardless of unscheduled time. |
| State Occurrences | Number of times the State was entered, for any duration. |
| Total Hours | Clock Time. Keep in mind you have an hourly bucket for the most recent 60 days. |
| Total Production | Parts produced in scheduled time. |
| Total Production Including Unscheduled | Parts produced including parts from unscheduled time. |
| Uptime Hours | Hours where the StateType is:
Does NOT include unscheduled. |
| Water | See Energy in Analytics documentation: |
| Gas | See Energy in Analytics documentation: |
| Electricity | See Energy in Analytics documentation: |
| Inventory Consumed | See Inventory in Analytics documentation: |
Fact Scrap Reasons | Scrap Reason Amount | Use this field when performing scrap reason based reporting. IMPORTANT: Scrap Reason Amount is the amount for just the associated scrap reason (from [Dim Scrap Reason]). If you are working with Scrap but not interested in reasons, then use [Fact Core].[Scrap]. Using both scrap field will result in unexpected scrap numbers. You must always pick between Scrap Reason analysis (this field) or total scrap analysis (See [Fact Core].[Scrap]) |
Dim Inventory | Inventory Name | Name the product being tracked. example: Coil0001. See |
| Start DateTime | Time the inventory record begins. All date fields in Analytics are displayed in the machine’s time zone. More information here: |
| End DateTime | Time the inventory record ends. All date fields in Analytics are displayed in the machine’s time zone. More information here: |
| Duration | The difference between Start DateTime and End DateTime measured in hours. * includes any unscheduled time, consider removing unscheduled time with a measured filter. |
| Start Level | Initial amount |
| End Level | final scan amount |
| Filters1-5 | As configured |
Fact Events | Event Name |
|
| Event Group |
|
| Event Start DateTime |
|
| Event Duration |
|
| Event Occurrences |
|
(Added June 2023) | Quality Check Name | Quality Inspection Name as per the Quality Module configuration. [Fact Quality Checks] joins to Fact Core and all Dimension tables - Machine, Job, Shift, Calendar Datetime. This differs from Events (see [Fact Events]). The tradeoff is we have bucketed quality data (daily, hourly) instead of full detail of every single quality check. For full detail of quality checks, see the quality audit page in whiteboard. |
Quality Last Check Date | The last time a check was completed (per machine, per check Name). | |
Quality Check Order Configuration Number | Configuration setting that defines the display order for checks. This is used when multiple are expected at the same time. | |
Quality Check Is Critical | A Configuration setting that indicates the check as critical. 1 - check is critical in the configuration. 0 - check is not critical in the configuration | |
Quality Check Stage | Configuration setting that defines when a new quality check is expected (and therefore will be displayed on screen). Possible values: AdHoc, Production, JobStart, JobEnd, Job Pulled, Shift Start, Daily. See: | |
Quality Check Part Frequency | Configuration setting only applicable when Quality Check Stage = “Production”. Defines the amount of parts produced before a new check will become expected. Existing incomplete checks will become expired and replaced by this new check. | |
Quality Check Type | Configuration setting that defines what value is needed to complete the check. Numeric values are Measurements. Boolean are PassFail, and any text is String. Possible values: Measurement, PassFail, String. | |
Quality Check Lower Limit | Configuration setting only applicable when Quality Check Type = Measurement. Lower Limit before a user will be prompted to confirm the entered value. Useful for control charts. | |
Quality Check Upper Limit | Configuration setting only applicable when Quality Check Type = Measurement. Upper Limit before a user will be prompted to confirm the entered value. Useful for control charts. | |
Quality Check Target Value | Configuration setting only applicable when Quality Check Type = Measurement. Target value. Useful for control charts. | |
Quality Check Value Min | (formula) Check Value Minimum in the given hour. | |
Quality Check Value Max | (formula) Check Value Maximum in the given hour. | |
Quality Check Value Average | (formula) Checks that report a specific value in the given hour. Averaged across the hour. | |
Quality Check Value Sum | (formula) Cumulative values of all checks in the hour. | |
Quality Checks Expected | (formula) The number of checks the configuration expected by machine and check name. | |
Quality Checks Completed | (formula) The number of checks with actual values entered. | |
Quality Checks Completed % | (formula) Completed Checks compared to Expected Checks. | |
Quality Checks Passed | (formula) Depending on configuration, this is the number of checks that pass the criteria configured. Some are pass/fail directly. Some are numeric with an upper and lower limit that defines success. | |
Quality Checks Passed % | (formula) Checks Passed as a percentage of the Completed Checks | |
Quality Checks Failed | (formula) Depending on configuration, this is the number of checks that fail the criteria configured. Some are pass/fail directly. Some are numeric with an upper and lower limit that defines success. | |
Quality Checks Failed % | (formula) Checks Failed as a percentage of the Completed Checks |
Formulas Dictionary