Page Comparison

PROD-197

https://slxdev.atlassian.net/browse/PROD-197

Context

Job upload has been configured as you specified in the previous case. Job Data is being uploaded and is on our server: D:\Shoplogix\Enterprise\XmlDataBackup\CN_CoverisHal\jobs\FR\Campine\Jobs

Job File was sent to you today too, but also can be found in the above folder.

There is only 1 area in the plant Campine https://saas126.shoplogix.com/whiteboard/#/shiftrollup/areas/45

Please could you let me know what the next steps are from our end to get the jobs uploaded to the machines

Tasks

• Custom xslt that will replicate job record to all machines when AreaID is specified in JobScheduleEdit entry

• Place xslt on saas126 in D:\Shoplogix\Enterprise\transforms

• Configure the applicable plants to use this new xslt i.e. set <JobScheduleTransform />value to new xslt name e.g. <JobScheduleTransform>CoverisJobTransform</JobScheduleTransform>

PNE-1199

https://slxdev.atlassian.net/browse/PNE-1199

Need to create sections for Area Get / Put requests similar to Machine sections so that only relevant data is being transferred / Modified.

Backend:

Need 3 API Requests:

• Area Settings

• Area Job Filters (for Job Scheduling)

• Filters for Analytics Portals

Front End:

• create models for handling new api requests for area

Current Behavior:

A full dump of AreaConfig is being sent via api request to get area.

EX: https://qa3.shoplogix.com/web/api/config/area/5

Expected Behavior:

Each API will return only relevant information and edit only relevant information

PNE-1165

https://slxdev.atlassian.net/browse/PNE-1165

Default Scrap Cycle Factor should work the same as Cycle Factor to avoid any issues with Total and Good / Total and Scrap part count.

Creating and starting job from Job List view → This should be already working as expected

1. If <AllowZeroCycleFactor>0</AllowZeroCycleFactor> and machine Scrap/Good Cycle Factor = 0 in config, Scrap Cycle Factor in the job should default to '1'.

• When new job is created Scrap Cycle Factor = 1

• Scrap Cycle Factor in Job edit can be changed and saved as '0'. However when the job is started Scrap Cycle Factor = 1.

• User cannot change Scrap Cycle Factor to '0' for Running or Completed job.

• User can change and save Scrap Cycle Factor to be > 0.

1. If <AllowZeroCycleFactor>0</AllowZeroCycleFactor> and machine Scrap/Good Cycle Factor <> 0 in config, Scrap Cycle Factor in the job should default to machine Scrap/Good Cycle Factor.

• When new job is created Scrap Cycle Factor = machine Scrap/Good Cycle Factor

• Scrap Cycle Factor in Job edit can be changed and saved as '0'. However when the job is started Scrap Cycle Factor = 1.

• User cannot change Scrap Cycle Factor to '0' for Running or Completed job.

• User can change and save Scrap Cycle Factor to be > 0.

1. If <AllowZeroCycleFactor>1</AllowZeroCycleFactor> and machine Scrap/Good Cycle Factor = 0 in config, Scrap Cycle Factor in the job should default to '1', however '0' is allowed.

• When new job is created Scrap Cycle Factor = 1

• Scrap Cycle Factor in Job edit can be changed and saved as '0'. Started job can have Scrap Cycle Factor = 0.

• User can change Scrap Cycle Factor to '0' for Running or Completed job.

• User can change and save Scrap Cycle Factor to be > 0.

1. If <AllowZeroCycleFactor>1</AllowZeroCycleFactor> and machine Scrap/Good Cycle Factor <> 0 in config, Scrap Cycle Factor in the job should default to machine Scrap/Good Cycle Factor, however '0' is allowed.

• When new job is created Scrap Cycle Factor = machine Scrap/Good Cycle Factor

• Scrap Cycle Factor in Job edit can be changed and saved as '0'. Started job can have Scrap Cycle Factor = 0.

• User can change Scrap Cycle Factor to '0' for Running or Completed job.

• User can change and save Scrap Cycle Factor to be > 0.

Job Upload using xml file - Regardless of AllowZeroCycleFactor

1. If machine Scrap/Good Cycle Factor <> 0 in config:

• When Scrap Cycle Factor is no defined in upload file (Scrap Cycle Factor =''), uploaded job Scrap Cycle Factor SHOULD = machine Scrap/Good Cycle Factor → FAIL, Current Behavior Scrap Cycle Factor = ZERO BAD

• When Scrap Cycle Factor is defined in upload file (including Scrap Cycle Factor = 0), uploaded job Scrap Cycle Factor SHOULD= Scrap Cycle Factor from the upload file → PASS

1. If machine Scrap/Good Cycle Factor = 0 in config:

• When Scrap Cycle Factor is not defined in upload file (Scrap Cycle Factor =''), uploaded job Scrap Cycle Factor = 1 → FAIL

• When Scrap Cycle Factor is defined in upload file (including Scrap Cycle Factor = 0), uploaded job Scrap Cycle Factor = Scrap Cycle Factor from the upload file. → PASS

Starting job thru OPC/PLC file - all needs to be done - ALL FAIL

NOTE: All these behaviors works correctly for CycleFactor

1. If <AllowZeroCycleFactor>0</AllowZeroCycleFactor> and machine Scrap/Good Cycle Factor = 0 in config:

• When Scrap Cycle Factor is not configured in OPC file, Scrap Cycle Factor in started job = 1

• When Scrap Cycle Factor in OPC file = 0, Scrap Cycle Factor in started job = 1

• When Scrap Cycle Factor in OPC file <> 0, Scrap Cycle Factor in started job = Scrap Cycle Factor defined in OPC file

1. If <AllowZeroCycleFactor>0</AllowZeroCycleFactor> and machine Scrap/Good Cycle Factor <> 0 in config:

• When Scrap Cycle Factor is not configured in OPC file, Scrap Cycle Factor in started job = machine Scrap Cycle Factor

• When Scrap Cycle Factor in OPC file = 0, Scrap Cycle Factor in started job = machine Scrap Cycle Factor

• When Scrap Cycle Factor in OPC file <> 0, Scrap Cycle Factor in started job = Scrap Cycle Factor defined in OPC file

1. If <AllowZeroCycleFactor>1</AllowZeroCycleFactor> and machine Scrap/Good Cycle Factor = 0 in config:

• When Scrap Cycle Factor is not configured in OPC file, Scrap Cycle Factor in started job = 1

• When Scrap Cycle Factor in OPC file = 0, Scrap Cycle Factor in started job = 0

• When Scrap Cycle Factor in OPC file <> 0, Scrap Cycle Factor in started job = Scrap Cycle Factor defined in OPC file

1. If <AllowZeroCycleFactor>1</AllowZeroCycleFactor> and machine Scrap/Good Cycle Factor <> 0 in config:

• When Scrap Cycle Factor is not configured in OPC file, Scrap Cycle Factor in started job = machine Scrap/Good Cycle Factor

• When Scrap Cycle Factor in OPC file = 0, Scrap Cycle Factor in started job = 0

• When Scrap Cycle Factor in OPC file <> 0, Scrap Cycle Factor in started job = Scrap Cycle Factor defined in OPC file

PNE-1155

https://slxdev.atlassian.net/browse/PNE-1155

PNE-860 was partially blocked by PNE-1149, this case addresses the rest of the work on the Machine States tab.

• If a new machine state is added and it has the same name as an inactive state, then the new state should replace the old one.

• Due to the change in PNE-1149, the front-end needs to make sure it's sending back the proper active status of the states being changed. So deleted machine states will be inactive, new machine states will be active.

• Micro Stop and Slow Running special states should follow the same rules, and should have validation if their name is changed to an active state.

PNE-1151

https://slxdev.atlassian.net/browse/PNE-1151

Default time span limit is 3 months, while it can be customized thru web.config settings (implemented in https://slxdev.atlassian.net/browse/PNE-932 . However, front end notification in regards to exceeding the time limit and adjusting of start time is always following the default (3 months).

Examples:

1. If TimespanRestrictionSeconds < 3 months (ex: 86400 seconds which is 24 hours) and requested time period is > 86400 seconds → Correct data is retrieved, however no warning in regards to time period limit is displayed and start time is not adjusted to show correct time from End Time (24 hours).

1. If TimespanRestrictionSeconds < 3 months (ex: 86400 seconds) and requested time period is > 3 months → Warning in regards to 3 months limit is displayed and start time is adjusted to show 3 months from End Date (should be 24 hours).

1. If TimespanRestrictionSeconds > default setting (ex: 4 months) and requested time period is between default and set limit (between 3 and 4 months) → Warning in regards to 3 months limit is displayed and start time is adjusted. There should be no warning and no Start Time adjusting.

PROD-159

https://slxdev.atlassian.net/browse/PROD-159

NFR-273 Specification

Customer Description

If a user assigns a downtime reason to a (Minor) Stop with multiple occurrences in Shift Hours or Shift rollup screen the occurrences will change to 1 and MTBF will change.

MTBF is a key metric for MDLZ. Therefore, ensuring that the number of failure occurrences measured cannot be altered by the user and thus changing the MTBF is a key priority.

Change the logic so that when the user changes the DT reason the DT occurrence count is not changed and therefore MTBF is not changing for ALL screens.

Summary of Deliverables

·         Offer a configurable option to decide whether flexible manipulation of occurrences between views or rigid consistency of occurrences between views is set per machine **should this be configurable per machine or area?**

·         The new option out of the two configurations would keep occurrences consistent throughout the entire Whiteboard and remove the option to flexibly adjust the number of occurrences in different views as described in further detail below.

Purpose and Intended Use

The purpose of this enhancement is to provide the option for Shoplogix customers to either flexibly adjust the number of occurrences based on downtime reason entry in different views in the Whiteboard or to keep occurrences the same regardless of where downtime reasons are entered.

For users who configure this change it will eliminate the opportunity for operators and other users to adjust occurrences in the Shift Hours or Shift Rollup views when entering downtime reasons and will mimic the behaviour of the Period Detail view in terms of maintaining occurrences. The desired outcome of this change is to provide a consistent number of occurrences used in the calculation of MTBF and MTTR regardless of which view downtime reasons are edited in.

Scope and Overview

The enhancement will contain changes to both the Shoplogix Whiteboard and Configuration as described in further sections and will be available for all Shoplogix servers. These changes will be in reference to the Shift Hours, Shift Rollup and Shift Chrono views as well as contain a machine specific configuration option.

Support for any customer issues with the changes described below will follow the same procedure as other cases, escalating according to internal customer policy prior to being reviewed by the Shoplogix Support Team who will determine the course of action to alleviate the issue.

Functional Requirements

User Interface: Current State

Shown below are examples of the Shift Hours, Shift Rollup and Shift Chrono views and an explanation of their current behaviour which will be the first of two configurable options in the configuration.

Shift Hours

Currently in the Shift Hours view, adding a downtime reason to a machine state with multiple occurrences in an hour long bucket will reduce the number of occurrences to 1.

Shift Rollup

Currently in the Shift Rollup view, adding a downtime reason to a machine state with multiple occurrences will decrease the number of occurrences to 1.

Period Detail, Dashboard and Shift Chrono

Currently in the Period Detail, Dashboard and Shift Chrono view, adding a downtime reason to a machine state or multiple machine states by multi-selecting several unassigned downtimes or individually selecting each occurrence will maintain the number of occurrences. This functionality will remain unchanged as a result of this enhancement.

User Interface: Future State

Shown below are examples of the Shift Hours, Shift Rollup and Shift Chrono views and an explanation of the desired future behaviour which will be the second of two configurable options in the configuration.

Shift Hours

In the Shift Hours view for a machine with the changes included in this enhancement applied, adding a downtime reason to a machine state with multiple occurrences in an hour long bucket will keep the occurrences at their previous value prior to editing.

Shift Rollup

In the Shift Rollup view for an area with the changes included in this enhancement applied, adding a downtime reason to a machine state with multiple occurrences in a shift bucket will keep the occurrences at their previous value prior to editing.

Period Detail, Dashboard and Shift Chrono

As previously stated, in the Period Detail, Dashboard and Shift Chrono view, adding a downtime reason to a machine state or multiple machine states by multi-selecting several unassigned downtimes or individually selecting each occurrence will maintain the number of occurrences. This functionality will remain unchanged as a result of this enhancement.