your 1st step in building
shop floor transactions
from the bottom up.

Features

Accounts

There is no option available for new users to register on Tios. New users must be invited to join an Enterprise via an emailed invitation. There is no other mechanism of creating an account other than by invitation.

Barcoding Capability

Tios was originally designed for barcoded transaction. This is where it’s line by line processing originated from. When run on a smartphone the phone camera will double up as a barcode reader allowing transactions to be scanned rather than manually entered. However Tios will also run on a PC and if barcoding is required on the PC application then the user can (a) use a wedge scanner or (b) use their own smart phone as a bar code scanner. Just think of the savings of no longer requiring expensive RF scanners on the shop floor.

Barcode suffix/Prefix

Barcode prefixes & suffixes are often used by organizations to ensure that the correct barcode is scanned. Take an example of lot number 123456. If an item master happens to be the same number as your lot number then there is a risk that the wrong barcode can being scanned. To avoid this type of error and to prevent manual overrides of barcode scans you can add a prefix and/or suffix to you barcodes. So if we allocate $a as a prefix for item numbers and $b as a prefix for Lot numbers. So now if we scan $a123456 when expecting to scan a Lot number we can determine that it is an invalid barcode type. We can utilize the same logic for suffix. Tios allows for a prefix/suffix to be specified for every input to cater for this added security. Also prefix/suffix logic can be switched on/off at user level to cater for back office staff running the transactions without scanning labels.

Batch Processing

Lengthly transactions/reports can be submitted to run in a background thread with the completed report being sent via email once completed. Equally bulk updates can be submitted to run in the background.

Biometric Confirmation

Scanning badges is the industry norm for identifying who has performed a shop floor transaction. (booking, receipt, update etc..). Unfortunately badges can be misplaced, lost, stolen or even loaned. Tios offers the ability to confirm biometrically ,via fingerprint scan on smart phone. This offers a whole new level of security and provides "100% Certainty" where before there was just "probably". Biometric scanning is available via the free Tios mobile app.

Calendars

Tios comes with an inbuilt calendar table allow users to create their own shop floor calendars, shipping calendars etc..

Connection Strings

The powerhouse of Tios is it’s inbuilt connection strings. A company’s data is commonly distributed across multiple servers and even across multiple ERP systems. It can be difficult extracting this information let alone allowing data from different sources to interact. Tios allows you to define the connection strings for each data source and for each environment within each of these data sources. Once defined your transactions can jump seamlessly between data sources pulling them all into one transaction inquiry/report/update.

CSV & Excel sheet processing

Despite the number of ERP systems out there the humble spreadsheet still reigns supreme in the manufacturing world. Tios recognises the power of the spreadsheet and provides simple uploads and download processes that allow spreadsheet data to be incorporated into transactions and/or the results to be returned in spreadsheet format. In addition tios makes it simple to validate the data on a spreadsheet prior to processing allowing potential error to be identified prior to uploading data..

Emailed Transaction output

When users request reports from Tios the resulting reports will be emailed to the requesting user upon completion along with the report title, date/time submitted and the report selection criteria. It can be invaluable when reviewing any report to see not only the report output, but also the data used to generate the report. Tios will also email a confirmation to the user when the transaction has performed any updates.

Enterprise driven

Tios is enterprise driven and every new customer on the cloud will create a new enterprise name and invite users to join that enterprise. Each enterprise will have access only to their own enterprise transactions and data. Optionally companies may prefer to run services like this within their own Intranet site.

Environments

Tios allows users to have multiple environments. So for example one user might just have access to a UAT environment whilst another could have access to development, Test, UAT and production. Each environment will have its own connection strings to differentiate between environments. In addition a list of disallowed names can be specified for each environment. So the Test and development environment can specify the names of Production servers which are not allowed to be connected to by that environment. This serves as a safeguard against transacting outside of the designated environment. Environments can be colour coded to provide additional safeguards. This allows users to always set their production environment to Red and test environment green etc..

Keywords

Tios has the abiliy to create variables , make branching decisions based on variable values, execute subroutines and much more. However sometimes specific logic is required to perform particular tasks such as Send an Email, Download a file, Retrieve next number etc… To facilitate these tasks hundreds of keyword have been created so that you don’t have to re-invent the wheel. Where a customer identifies a new keyword that adds value to the system we will add it free of charge to our next release. Customized keyword can also be added. Keywords are divided into two types, client keywords and server keywords.

Client Keywords

These will always be prefixed with “clt-“ and are instructions to the client application from the service. Clt-drpDwnLst, Clt-drpDwnMan for example informs the client that (a) a drop down list exists and (b) that it is mandatory that the input comes from one of the values on the drop down list.

Service Keywords

These are all the remaining keywords not prefixed with “clt-“ and are keywords to perform processing on the server. An example might be rtn-usrEml which will return the signed in user’s email address. A full list of both client and server Tios keywords are available from the tios_keyword_master table.

Menu Security

Tios assigns a security level (0-9) to each user depending on their system requirements. Operators might be level 1 security whilst supervisors level 2 etc.. Tios also assigns a security level to each menu and transaction belonging to the enterprise. User will only have access to menu options and transactions within their own security level. Menus can be configured to show all options and disallow access to secured options or just show menu options that the signed on user has access to.

Multiple Language capability

In today’s global village we can have users whose first language is different from the language used by the enterprise. Tios has the ability to display transaction text and prompt in multiple languages. So by changing the users language preference on the customer master this user can see transactions in their preferred language whilst everyone else see the same transaction in the standard language.

Next Numbering system

Unique Next numbers are a vital part of every enterprise. Whether it is a batch number, Invoice number, transaction number, they all require the ability to be unique. Tios has a flexible next numbering system which allows unique number to be generated by use of a keyword whenever they are required.

Remote Procedure calls

Just like connections strings, remote procedures can be called on remote systems/platforms. This give Tios the power to run jobs on remote systems. So for example Tios can populate a remote database file with multiple transaction records and then call the remote procedure which will process these transactions. A powerful interface to any remote system.

Self Service Web Portal System

The shop floor users who work an ERP system are often the most knowledgable of the strengths and weaknesses of that system and yet often their complaints/recommendations are ignored. There is nothing more disempowering than having to park your work whilst you wait for an IT Ticket to resolve a known issue, not to mention the lost productivity. Tios has evolved as a problem fixer. Within minutes a transaction can be created which will unlock a locked record, insert a missing record, delete an invalid record, reverse a mistaken entry, reset a password. There is no limit to the scanarios that can be "fixed" and with full audit trails. The best part of all is giving these fixes to the people that require them so that when production stops at 4am , they have the tools to identify and fix the issue themselves. This has proved to be one of the best features of Tios to date.

Security

Users are designated a security level between 1 – 9 which will determine the options that they are allowed to access. Transactions are also given a security code between 1 -9. Menu options will look at bothe user and transaction security to determine which transactions the signed on user is allowed to access

Smartphone Scanning

Tios can operate as a stand alone application running on a laptop, PC, or Mobile device. However the Tios mobile app (free from IOS & Android stores) enhanses the capability of Tios by allowing your smartphone to double up as a barcode scanner and/or Biometric scanner. The Tios app can be used to scan 1D and 2D barcodes and eliminates the need for expensive RF Scanners. Download IOS version of app here Download IOS version of Tios app and download Android version here Download Android version of Tios app

SQL queries/reports

This is the "bread & butter" of Tios processing. With its powerful connection strings and its batch processing capability it can return the require information along with an audit trail of your data selection criteria.

Training Requirements

Transactions and menus can be linked to training requirements via the transactions header. If training is specified for a transaction then the training history file is checked for the logged on user. If this user has not completed the required training then they will be prevented from transacting. An override exists at the user master level to allow specific users (back office/technical) get around this requirement.

Transaction Audit trail

All transactions are audit trailed. So it is possible to see who transacted, when they transacted and what they transacted.

Transaction Header

Every transaction defined in TIOS will have a transaction header.

Transaction history maintained

When data is the driver of you transaction then it is vital that any changes to this data is recorded and can be retrieved. Whenever a transaction is updated in Tios a complete copy of the original transaction data is copied to a transaction history file and date/time stamped.

Transaction Prompting

Tios provides the ability at user level to switch on/off transaction prompting. This feature is particularly useful when training new users. A complete narrative can be display for every input the user is required to make.

Transaction Security

Like menu security, transaction security is based on a comparison between the users security level and the security level on the transaction header. If the transaction security level is higher than the user’s security level then they will not be allowed to transact.

User Defined Codes

A fantastic concept which allows users to effectively define their own datasets which can be used in any transaction. User defined code are made up of two tables. The 1st table gives a description to the code being defined, key length, Alpha/numeric etc.. The 2nd file contains that actual codes being defined. User codes can be grouped together under system codes. These are well worth understanding as they can provide great flexibility and functionality.

Unique Identifiers

Every enterprise will have some processes which call for a unique identifier. Whether it be a unique pallet or shipping number, a sterile lot number or a trace code. The Tios unique identifier engine has the ability to generate unique identifiers in many different ways.

User Level logging

Logging can be switched on at user level, for all users within an enterprise or just one user. This provides the ability to debug issues affecting one user without disrupting or slowing down the remaining users. It also facilitates transaction development

Validated Transactions

Many enterprises are highly regulated and need to ensure that once a transaction has been validated , that it remains validated. Because our transactions are data driven, changing a setting on one of the rules could result in a change to a validated process. To prevent this from happening Tios provides the ability to validate transaction so that even the addition of a space on an existing transaction line would result in the transaction being locked until such time as it is re-validated. The validation process gives a weighting to every character (including whitespace) within a transaction and therefore any change to that transaction can be detected and actioned.

Variables

One of the most powerful features of the Tios system is it’s ability to create, change and manipulate variables within transactions. One of the advanced Tios features is the ability to display variable values whilst stepping through a transaction. This feature allows transaction developers to review the status of every variable defined at every input point of a transaction.

Rule Types

There are various types of rules that make up a transaction.

Rule type Description

C

Constant Rule type

D

Decision Rule type

i

input Rule type

J

Join Rule type

L

Logic Rule type

M

Menu Rule type

o

Output Rule type

T

Tag Rule type




Each of the above rule types provide transactions with the means to perform various types of logic. For example when a transaction is to output to either a screen or some other output device the (O)utput rule will be specified which informs the application that the information on this line is to be output. Equally when performing Inputs we would use the (i)nput rule type. When general logic is required we would select a (L)ogic rule type and if a branching decision is required we would select the (D)ecision rule type etc. etc..

All Tios transactions are made up of sequenced rules with each rule belonging to one of the rule types shown above. If, for example, we wanted to create a very simple transaction which allowed the user to input their name and sends the user a message I could do the following:

Transaction Name Seq No. Rule Type Rule Description Text Field Name Field Condition Field Value Tag Name Command Type Command DB Source Error Msg Keyword

Test1

010

i

Input user name

Your Name:

<&name>

clt-manEnt,

Test1

020

l

Include name in message

<&msg>

Hello <&name>

add-alpVal

Test1

030

o

Display message

<&msg>

  1. an input rule ( i ) prompts the user to enter their Name and makes it a mandatory entry (ie. Blanks not allowed) by adding keyword Clt-manEnt. The value entered is assigned to variable <&name>.
  2. a logic rule ( l ) appends the input name to constant “Hello” and assigns the result to variable <&msg>.
  3. an Output rule ( o ) displays the contents of variable <&msg> on the screen.

This is the basis of how all Tios transactions are created. It is simple and easy to understand. Users can define their own customized transaction types if they wish.

Rule Type Sequencing

The above example shows the sequence in which the transaction (Test1) will be executed (010, 020 & 030). However there is another set of sequences to consider which are no so obvious. Take the 1st line of our example. This input rule calls for the user to input their name, executes a keyword to ensure that a value was entered and issues an error message if nothing entered and finally the entered value is assigned to variable <&name>. That is 4 tasks (input value,process keyword,check for errors, assign value) that the i rule is undertaking in this example. The sequencing of these tasks is just as important as the sequencing of the rules within the transaction.

you have just seen, each rule type is capable of doing more than just 1 task. In our example we saw that our (i)nput rule has 4 tasks to perform. In total, between all of the different rule types, there are 11 potential tasks or actions that a Tios transaction may be required to take. These are:

  • Decisions (branching decisions)
  • Assignment (assign values)
  • Commands (running SQL statements or remote procedures)
  • Prompts (Prompting user at time of input)
  • Messages (sending messages)
  • Inputs (user inputs)
  • Outputs (outputs to screen or devices)
  • Keywords (process keywords)
  • Errors (process errors)
  • Goto Tags (branching)
  • Subroutines (Execute sub-routines)

Once we introduce the concept of multiple tasks per rule type then we must have some mechanism of defining the sequence in which the tasks are run. If in our example above the input rule performed the input task before performing the process keywords task, then it would be too late to check for blanks or if the check for errors task was performed before the process keywords task again we would have a different outcome. This is where the Tios ruletype operation sequence table comes into play. It determines the sequence of operation for each rule type. If you create a new rule they you must define it operation sequence in this table.

DCR_ruletype_opseq table
Enterprise Trans Rule Type Rule Description Decisions Assignments Commands Prompts Messages Inputs Outputs Keywords Errors Goto Tags Subroutines Op Seq

stryker

C

Constant Rule

2

3

1

4

5

6

KACEGS

stryker

D

Decision Rule

1

3

2

4

5

6

DKCEGS

stryker

i

input Rule

3

4

5

6

1

2

KECPMI

stryker

J

Join Rule

1

K

stryker

L

Logic Rule

1

3

2

4

5

6

DKCEGS

stryker

M

Menu Rule

1

K

stryker

O

Output Rule

2

4

5

1

4

KCEMO

stryker

T

Tag Rule

3

1

K

Above the ruletype_opseq table allows us to allocate the operation sequence for each of the rule types. Continuing with our example using rule type ‘i’ we can see that the default operation sequence is KECPMI. This means that when rule type ‘i’ is executed the keywords are processed first, followed by the error check and the final task is the input.

The same logic applies to each of the rule types which provide transactions with a lot of flexibility. However you should be aware that operation sequences should be changed using extreme caution as they can change the logic flow of existing transactions. It is advised that these operation sequences be set up once only before any transactions are defined. If the user has a requirement to change the operation sequence for a transaction line or a transaction then there are Keywords which will provide this type of functionality (see OvrOpSeq and OvrTrSeq keywords). Alternatively create a new rule type (eg L1,D1 etc.. and apply new operation sequenes to this new type)

Operation sequences can be set up at 3 different levels

  1. Company & Transaction Level
  2. Company Level
  3. Global Level