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

At a Glance

TIOS is a cloud based BRMS (Business rules management system) WCF Service, developed in C# and utilizing the power of ASP.NET. It runs on the web as a cloud based system or can be run inhouse as an intranet service. Originally developed as a barcoding application, which is why it processes single stream data entry, however it now caters for non barcoding applications and is frequently used as a self service portal allowing user’s to resolve ERP issues which would otherwise require a help desk ticket to be raised. What makes Tios unique is it’s flexibility and it’s ability to connect to multiple platforms within any given transactions. With Today’s distributed databases it is truly a powerful feature.

What’s the difference between a TIOS and other applications ?

Generally barcoding applications are developed to speed up or enhance the manual ERP process. These systems will often be developed by a 3rd party who does the analysis, develops the code and hands over an executable (.exe) along with the documentation. When this 3rd Party walks away, it is often with critical process knowledge in their head. The executable file (.exe) is not in human readable format so the only way of knowing the process flow is by following the documentation , which hopefully is accurate. Later when changes to the process are required ,the 3rd party (if available) will be required to return and change the logic to match the new process. Over time the ERP & Barcoding system processing logic often drift apart and only come to light when anomalies appear.

TIOS takes a very different approach by allowing the logic behind each transaction to be driven by data , supplied by the business, rather than programming logic. Our .exe is basically a vehicle for the business to define the business rules behind each transaction. These rules are held in the Tios SQL database and can be validated and locked in or if necessary added to or changed by the business. The TIOS engine provides the mechanism for running these transactions which are made up of a set of sequenced individual rules combined together by a transaction name. These rules generally break down to your business process rules. If the user wants to understand the process they can simply dump the transaction rules to a spreadsheet and read through them as they would pseudocode. When a transaction needs to change , the user can simply insert the additional steps into the transaction at the required sequence. No need to call any 3rd party.

Self Service Portal V Helpdesk ticketing system

Helpdesk ticketing systems are a must for any large organization and they allow for system issues to be documented, categorized, prioritized, allocated to a resource and eventually resolved. Whilst necessary, it can all take time and if any issue is not considered to be critical it can delay the eventual resolution even further. Make no mistake – this is how it should work. However analysis of the issues being recorded in helpdesk systems show that a large percentage of tickets are “repeat offenders”. Repeat offenders have no business being recorded in a helpdesk ticketing system. Once an issue has been identified as being a repeat offender it should have a “fix” put in place to ensure that it ceases to be an ongoing issue.

Tios provides users with a self service portal to resolve these “repeat offenders” themselves at the time that they occur. Think of the time saved by giving users control over these roadblocks. No more logging the same tickets, no more waiting, no more trying to remember where you left off. Quite simply, if there is a known fix for a recurring issue then Tios will be able to convert this fix into a transaction and make it available to the appropriate users. Sometimes the “repeat offenders” are not system issues but instead they may be a request for data. (eg. Packaging/Manufacturing history report). Same difference!! Give the users the tools they require to complete their tasks by creating a Tios transactions which they can use to generate their own reports.

Below are some of the transactions which we created for Stryker to eliminate repeat offenders. You might recognize some of your own repeat offenders in here. Have a look at STORIES on this website to hear user’s feedback to get a feel of how these transactions have affected their daily work.

1. Shop Floor Control
  • 1.1 Optio Printers
  • 1.1.1 Display Printer Status
  • 1.1.2 Maintain User’s Current Printer
  • 1.1.3 Maintain User’s Default Printer
  • 1.1.4 Maintain Link to User’s Profile
  • 1.1.5 Printer Down
  • 1.1.6 Printer Fixed
  • 1.1.7 Re-print Optio Spoolfile
  • 1.2 Label Printing
  • 1.2.1 Inquire on last ILS Send
  • 1.2.2 Error 101 - Resend ILS Details
  • 1.2.3 Print Tote Labels
  • 1.3 Shop floor bookings
  • 1.3.1 Reverse Shop Order Bookings
  • 1.3.2 Outstanding Reversal Requests
  • 1.3.3 Heat Treatment Inquiry
  • 1.3.4 Make Existing FG Lot available for re-use
  • 1.3.5 Perform Shop Order Booking
  • 1.4 Shop floor reporting
  • 1.4.1 Transaction History Report
  • 1.5 Reset my BPCS password
  • 1.5.1 Transaction History Report
2. Customer Service
  • 2.1.1 Customer Preference Inquiry
  • 2.1.1.1 Inquiry by Customer No
  • 2.1.1.2 Inquiry by Customer/Preference
  • 2.1.1.3 Flip Anngrove Optional Values
  • 2.1.2 Customer Preference Inquiry
  • 2.1.3 Rename baseplate sub-assembly Lot
3. HR
  • 3.1.1 Create a new operator
  • 3.1.2 Update Operators Badge Number
  • 3.1.3 Update Misc Badge Details
  • 3.1.4 Inquire on operators Badge
4. Finance
  • 4.1.1 Booking Reversals
  • 4.1.2 Pending Reversal Approvals
5. Simplex
  • 5.1.1 Packaging Verification Inquiry
  • 5.1.2 ILS Updates/Insertions
  • 5.1.2.1 ILS Inquiry
  • 5.1.2.2 Insert ILS Header Table
  • 5.1.2.3 Maintain ILS insertion items
  • 5.1.2.3.1 Inquire on Existing Items
  • 5.1.2.3.2 Delete Existing Items
  • 5.1.2.3.3 Add New Items
  • 5.1.2.4 Update ILS expiry date for re-worked orders
6. TFA
  • 6.1.1 Update TFA Batch Quantity
  • 6.1.2 Update missing Ops in TFA backflush
  • 6.1.3 Relocate Misplaced TFA Scrap Records
  • 6.1.4 Insert Missing Scrap Records
  • 6.1.5 Insert Missing Completed TFA Records
  • 6.1.6 TFA Emergency extraction
  • 6.1.7 Delete records from TFA Backflush table
  • 6.1.8 TFA SOD/SOH Backflush inq
  • 6.1.9 TFA Shop Order Audit Trail
  • 6.1.10 TFA Shop Order Force Close
7. IEC Whse Menu
  • 7.1.1 Optio Printers
  • 7.1.1.1 Display Printer Status
  • 7.1.1.2 Maintain IEC Form’s Current Printer
  • 7.1.1.3 Maintain IEC Form’s Default Printer
  • 7.1.1.4 Printer Down
  • 7.1.1.5 Printer Fixed
  • 7.1.2 BPCS User Profile
  • 7.1.3 Release In Use Order
  • 7.1.4 Reset Locked INVOICES/PICKSLIPS data area
  • 7.1.5 Remove PO from PO Waiting
  • 7.1.6 Upload Scrap Details to BPCS

Below is a simplified example of a PO receipt transaction which retrieves the purchasing limits of the signed on user and bases a purchasing decision based on the values. To get a full explanation of each line simply click on a line and the detailed explanation will be displayed. This example will give a good understanding of how Tios processes transactions.

Things to be mindful of when reviewing transaction below

  • Transactions (eg. pur0400 in this instance) run sequently in order of sequence
  • Control Only returns to the user for input when an input rule ("i") is encountered.
  • When input rules are encountered then the transaction will wait for the response from the user before continuing on to the sequence after the input.
  • If an error is encountered then control will return to the previous input statement and an error message will be displayed (eg Invalid PO number)
  • Variables within transactions are represented by <& xxxxxx> eg ( <&orderNumber> )
  • Just scanning through the Rule Description of each sequence will normally give you a good idea of what the transaction is doing. Try it yourself !!
Transaction Id. Seq No. Rule Type Rule Description Text Field Name Field Condition Field Value Tag Name Command Type Command DB Source Error Msg Keyword

pur0400

10

t

Start Tag

tag-start

clr-scr

This is a Tag line type (rule type t). Tags are used as placemarkers which we can direct logic to. We can loop back to tag-start at the end of the process. Also a clr-scr command is issued in the keywords instructing the screen to be cleared

pur0400

20

l

Rtn Users upper limit

<&userUpperLmt>

rtn-uprlmt

This is a logic line type (rule type l). Keyword rtn-uprLmt returns the logged in user’s upper limit for receipting po and places this value into variable <&userUpperLmt>

pur0400

30

l

Return Users email

<&userEmail>

rtn-usreml

This is a logic line type (rule type l). Keyword rtn-usreml returns the logged in user’s email address and places this value into variable <&userEmail>

pur0400

40

i

Input PO No

PO No:

<&poNumber>

clt-manEnt

This is an lnput line type (rule type i). Control returns to the client for a user input where the user will be prompted to enter a PO Number. Keyword Clt-ManEntM informs the client that this is a mandatory entry. The resulting entry is placed into variable <&poNumber>

pur0400

50

l

Retrieve PO Details

<&vendor>,<&vendorName>,<&poValue>

SQL

select f1,f2,f3 from POH where po=<&poNumber>

ole_con1

This is a logic line type (rule type l). Here we run an sql statement to retrieve the PO details from the PO Header file for the entered <&poNumber>. The selected values are placed into variables <&vendor>,<&vendorName> &<&poValue> respectively. The “CommandType” of SQL informs system that this is an SQL statement. The “DB_Source” of ole-con1 points to the appropriate connection string so that data can be retrieved regardless of where it resides.

pur0400

60

d

is this a valid PO

<&vendor>

ifeq/end

{EMPTY}

e2317

This is a decision line type (rule type d). Here the value of one of the retrieve variables is examined and if it contains the constant {EMPTY} this indicates that the previous SQL did NOT successfully read a valid PO Header record. If condition proves true then the error message ‘e2317’ (PO No. <&poNumber> does not exist) will be displayed and control will return back to previous input (line 40)

pur0400

70

o

Disp PO No

PO No:

<&poNumber>

This is an Output line type (rule type o). Having reached this point means that the entered PO number exists on the PO Header file. This line will display the text “PO No:” followed by the po number contained in variable <&poNumber>. It should be noted that this output will only be displayed when the next input statement is encountered.

pur0400

80

o

Disp Vendor No

Vendor:

<&vendor>

This is an Output line type (rule type o). This line will display the text “Vendor:” followed by the value contained in variable <&vendor>

pur0400

90

o

Disp Vendor Name

Name:

<&vendorName>

This is an Output line type (rule type o). This line will display the text “Name:” followed by the value contained in variable <&vendorName>

pur0400

100

o

Disp PO Value

PO Value:

<&value>

This is an Output line type (rule type o). This line will display the text “PO Value:” followed by the value contained in variable <&value>

pur0400

110

d

Validate User Limit

<&value>

ifgt

<&userUpperLmt>

This is a decision line type (rule type d). Here the total value of the PO held in variable <&value> is compared to the upper limit that the user is authorized to receive held in variable <&userUpperLmt>. If the condition proves true (value is above user’s limit) then control passed to the next line otherwise control passes to the else statement on line 130

pur0400

120

d

Disp Error msg

e2055

This is a decision line type (rule type d). Here the error message ‘e2055’ (PO No. <&poNumber> exceeds users upper limit. Please contact your supervisor) will be displayed and control will return back to previous input (line 40)

pur0400

130

d

else

else

This is a decision line type (rule type d). This is the else statement associated with the if condition on line 110. Control will pass to here when the condition proves false

pur0400

140

l

Retrieve active PO lines

<&poLine>,<&poItem>,<&poQty>,<&uom>,<&desc>,<&poLot>

SQL

select line,item,(qtyord-qtyrcd),uom,desc,lot from POD where po=<&poNumber> and status='A'

ole_con1

cpy-filToDrpDwnLst

This is a logic line type (rule type l). Here we run an sql statement to retrieve the PO details from the PO Detail file for the entered <&poNumber>. The selected values are placed into variables <&poLine>,<&poItem>,<&poqty>,<&uom>,<&Desc>,<&poLot> respectively. The keyword cpy-filToDrpDwnLst informs system that the results of this sql are to be passed back to the client so that they can be used as part of the next input in either the dropdown list or a displayed list. The “DB_Source” points to the appropriate connection string so that data can be retrieved regardless of where it resides

pur0400

150

i

Select line to receipt

PO Line:

<&poLine>

clt-dspLst,clt-manEnt

This is an lnput line type (rule type i). Control returns to the client for a user input where the user will be prompted to enter a PO Line Number. Keyword Clt-DspLst informs the client that the user is to select from a list of displayed values rather than enter a value. These value will have been passed to the client in line 140. Clt-ManEnt informs the client that this is a mandatory entry. The resulting entry is placed into variable <&poLine>

pur0400

160

l

Retrieve selected PO line

<&poLine>,<&poItem>,<&poQty>,<&uom>,<&desc>,<&poLot>

SQL

select line,item,(qtyord-qtyrcd),uom,desc,lot from POD where po=<&poNumber> and status='A'

ole_con1

This is a logic line type (rule type l). This is similar to line 140 except that now we know the line number selected and therefore we can retrieve <&poLine>, <&poItem>, <&poqty>, <&uom>, <&Desc>,<&poLot> for the selected PO Line.

pur0400

170

o

Disp PO line

PO Line:

<&poLine>

This is an Output line type (rule type o). This line will display the text “PO Line:” followed by the value contained in variable <&poLine>. It should be noted that this output will only be displayed when the next input statement is encountered.

pur0400

180

o

Disp PO Item & desc

Item:

<&poItem> - <&desc>

This is an Output line type (rule type o). This line will display the text “Item:” followed by the value contained in variables <&poItem> & <&desc>. It should be noted that this output will only be displayed when the next input statement is encountered.

pur0400

190

o

Disp PO Lot

PO Lot:

<&poLot>

This is an Output line type (rule type o). This line will display the text “PO Lot:” followed by the value contained in variable <&poLot>. It should be noted that this output will only be displayed when the next input statement is encountered.

pur0400

200

o

Disp PO Qty

PO Qty:

<&poQty>

This is an Output line type (rule type o). This line will display the text “PO Qty:” followed by the value contained in variable <&poQty>. It should be noted that this output will only be displayed when the next input statement is encountered.

pur0400

210

i

Input receipt Qty

Receipt Qty:

<&receiptQty>

clt-manEnt

This is an lnput line type (rule type i). Control returns to the client for a user input where the user will be prompted to enter the Quantity being receipted against this PO Line Number. Keyword Clt-ManEnt informs the client that this is a mandatory entry. The resulting entry is placed into variable <&receiptQty>

pur0400

220

d

Validate receipt Qty <= PO Qty

<&receiptQty>

ifgt/end

<&poQty>

e2311

This is a decision line type (rule type d). Here the value of variable <&receiptQty> is checked to see if it exceeds the value of variable <&poQty> . If true then error message ‘e2311’ (Receipt Qty cannot be greater than ordered Qty.) will be displayed and control will return back to previous input (line 210)

pur0400

230

l

Update receipted Qty to PO detail file

SQL

update POD set QtyRcv=QtyRcv+<&receiptQty> where po=<&poNumber> and status='A'

ole_con1

This is a Logic line type (rule type l). Having reached this point means that the entered receipt Quantity <&receiptQty> was valid. Here we run an sql statement to update the PO details file with the quantity receipted. The “CommandType” of SQL informs system that this is an SQL statement. The “DB_Source” points to the appropriate connection string so that data can be retrieved regardless of where it resides.

pur0400

240

l

Update Inventory to reflect receipted qty

SQL

update INV set Qoh=Qoh+<&receiptQty> where item='<&poItem>' and lot='<&poLot>'

This is a Logic line type (rule type l). Here we run an sql statement to update the Inventory file Quantity on Hand with the quantity receipted. The “CommandType” of SQL informs system that this is an SQL statement. The “DB_Source” points to the appropriate connection string so that data can be retrieved regardless of where it resides.

pur0400

250

l

Retrieve Next Number

<&uti>

pur,<&nextNo>

rtn-nxtNum

This is a Logic line type (rule type l). Here we execute keyword rtn_NxtNum which will take the 1st element of FieldValue (ie. pur) and look for the next available number for this code. The unique number is returned to variable <&nextNo> and subsequently moved to variable <&uti>.

pur0400

260

l

Set Transaction UTI to next number

<&uti>

set-trnOutUti

This is a Logic line type (rule type l). Here we execute keyword set_TrnOutUti which will take the value in FieldValue (ie.<&uti> ) and apply it as the unique transaction id of the transaction output file. The transaction output file is the audit file for all transactions.

pur0400

270

l

Set Transaction Status

c

set-trnOutSts

This is a Logic line type (rule type l). Here we execute keyword set_TrnOutSts which will take the value in FieldValue (ie. c ) and apply it as the status of the transaction output file. The transaction output file is the audit file for all transactions.

pur0400

280

l

Create the transction

crt-trn

This is a Logic line type (rule type l). Here we execute keyword crt_Trn which will write a record to the transaction output file containing details of the transaction just completed. The transaction output file is the audit file for all transactions.

pur0400

290

o

Output ReceiptConfirmation Msg

PO <&poNumber> line <&poLine> -'<&desc>' Quantity <&receiptQty> of <&poQty> successfully received

This is an Output line type (rule type o). This line will display the following confirmation message to the user: “PO 123 line 1 –Spare Parts quantity 1200 of 1800 successfully received” It should be noted that this output will only be displayed when the next input statement is encountered.

pur0400

300

l

Set the TO email address

<&userEmail>

set-toEmlAdr

This is a Logic line type (rule type l). Here we execute keyword set-ToEmlAdr which will take the value in FieldValue (ie.<&userEmail> ) and apply it as the “TO” email address.

pur0400

310

l

Send email confirmation

wrt-eml

This is a Logic line type (rule type l). Here we execute keyword snd-Eml which will send a confirmation email to the user. The contents of the email are defined in the transaction header file and will similar to “PO 123 line 1 –Spare Parts quantity 1200 of 1800 successfully received”

pur0400

320

i

Press any key to continue

Press any key to continue

This is an lnput line type (rule type i). Control returns to the client for a user input where the user will be prompted to enter any value to continue. The reason for this “Dummy” input is to allow user to receive confirmation message before proceeding to the next receipt.

pur0400

330

d

endif

end

This is the end statement of the condition specified in line 110

pur0400

340

d

goto Start

tag-start

Control is returned to the beginning of the transaction. User can exit by click PREV button or proceed with next purchase order receipt