ATMS Concepts

Terminology #

Items #

These are individual entities. For instance, drills, taps, reamers, inserts, gloves, safety shoes, etc. During the Item definition stage, each Item has to be categorised into one of the Item types explained below. This type classification is important as it defines the rules by which ATMS handles the issue and tracking of different Item types.

Item Types:
Consumable: Typically a perishable Item that once issued is not tracked and not returned to stores.

Semi-Durable: Typically an Item that has a limited life, but is tracked when issued, and MUST be returned to stores; rework; scrap.

Durable :Typically an Item with a long life that is tracked when issued, and MUST be returned to stores; rework; scrap.

Permanent Issue: An Item which is intended to be issued once, but also tracked.

Spare :A general spares Item, such as shims and screws for the clamping of inserts, etc.

Assemblies #

Cutting tools used on machines have to be held and presented to the machine in some way. The collection of Items required is known as an Assembly.

This Assembly can then be considered an entity itself, and can be stocked, tracked, re-ordered, issued and returned to the stores.

This methodology allows the Items required for one part of an operation to be specified, controlled and analysed.

Assemblies can be included in (job) Kits, allowing full process specification

Kits #

Kits can contain Items (of any type), and /or Assemblies.

Kits are normally job / operation specific, and their name (Kit ID number) is usually meaningful, in this sense.

The nesting of Items, Assemblies, into Kits, allows an effective Bill of Tools (B.O.T.) to be created for components / operations.

With this data, ATMS can then analyse, pro-actively, for tooling shortages prior to job launch. This data construction and maintenance, also lays the foundations for tool scheduling against manufacturing Master Production Schedules (M.P.S.).

Kit Lists #

Kit Lists can contain Kits and Kit Lists.

Sites #

Within ATMS, multiple (customer) sites / factories can be defined. Each site (and there may be just the one) can have one or more points of issue (see below).

Point Of Issue (POI) #

A point of issue may be a TPS Vending machine, a stores, a satellite stores, etc.
Budgets may be assigned to a specific POI (each one can have its own unique budget, or share with other(s).

System Administration Terminology #

Access rights: A user can be granted different levels of functionality within the many functions that can be performed within ATMS.

User profile : A user profile is a definition of a user and the access rights he/she has within ATMS.

The concept of POI’s and, managing multiple sites and locations #

ATMS has been developed to allow users to manage multiple stores and / or vending units centrally. It facilitates centralised purchasing and goods receiving.

The POI creation / amendment process #

Users first of all define their site(s), to which they want to assign their POI’s. This is achieved by updating the Site tab in references.

Next the individual POI’s are defined on the Locations tab, and assigned to a particular site.

A POI could be a satellite stores, a cell store, a vending unit, or indeed the main factory tool stores. A meaningful name can be applied.

User profiles are then created or amended to grant or deny the user access to each specific POI. The user can also be given a default POI to which their login automatically assigns them to upon login.

Once logged in, this default POI is displayed in the combo box on the bottom of the main menu. Providing the user has been granted the right to do so, they can change the POI to another, and then enter the ATMS menu required.

All stores activities relate to Items that are located in the specified POI.

Purchasing and Item data management activities are not necessarily specific to a single POI. Item definition allows the user to amend location data. That is, an Item can be assigned / de-assigned to another POI, and its location within the POI specified / altered.

This is achieved by editing the Item definition, locations tab.

Prices/Cost Analysis #

There are 4 categories of prices / costs in ATMS:

Analysis price
Rework cost
Supplier XXX Price 1… ? / Supplier YYY Price 1… ? etc. (Where there can be anything from none upwards supplier prices assigned to each supplier assigned to the Item.)
Cost per edge – this is for reference only, and is NOT written to the transactionlog table.

Each time a transaction is undertaken in ATMS, an entry gets written into the TransactionLog table for reference and to make them traceable.
Hence usage / costs / activity can be analysed and reported.

A partial extract from the TransactionLog table is shown below:

Transaction_Date_Time Transaction_Code Description Unit_ID Unit_Description Unit_ Cost Rework_ Cost
16/03/01 13:51 101 Issue DM005 Standard drill 8.00mm long series drill 11.22 5.01
16/03/01 13:51 101 Issue DM005 Standard drill 8.00mm long series drill 11.22 5.01
16/03/01 13:52 103 Return to Rework DM005 Standard drill 8.00mm long series drill 11.22 5.01
16/03/01 13:52 105 Return from Rework DM005 Standard drill 8.00mm long series drill 11.22 5.01

For all stores activities, the unit cost written to the database is the current (at the time of the transaction) analysis price for the Item. Likewise, so is the current (at the time of the transaction) rework cost for the Item.
As can be seen from above, for both issue, return (from in use) to rework, and return from rework (to stores / scrap) transactions, both price values are written to the database, and the user can select which one to analyse.

Within ATMS, the standard reports are available, and they offer the following options:
Transaction Analysis Reporting: Options of:

The transaction analysis price – the analysis price at the time the transaction was undertaken.

The current analysis price – the analysis price that is currently saved in the database for the specified Item (it may have been modified since the transaction was undertaken).

The transaction rework cost – the rework cost at the time the transaction was undertaken.

The current rework cost– the rework cost that is currently saved in the database for the specified Item (it may have been modified since the transaction was undertaken).

Purchasing Price/Cost Considerations
All prices applied in the purchasing module are written to the database, and permanently archived for audit purposes. (I.e. The user cannot apply the current analysis price to requisitions and purchase orders.)
ATMS allows multiple suppliers to be assigned to Items.
For each supplier, ATMS allows multiple prices to be saved, allowing automatic price breaks at the purchasing stage.
That is, you may have a price of £10.00 for buying unit quantities of 1-9, and a discounted price of £8.50 for buying unit quantities of 10-50, etc.
The ATMS purchasing module, defaults to the price for the relevant quantity (price break), for the preferred supplier.
It will however, allow it to be changed at the ordering / requisition stage.
Packet size rounds up the suggested order requirement to a multiple of the packet size (i.e. order in multiples of…), and the price is the individual unit price not the price for the packet quantity.

Record Deletion Rules #

Record type Deletion Rules
Items: Only deleted when:
Not in use
Not in rework
Not in any orders
Not in any requisitions
Not in any GRN’s
Not a spare for a durable
Not in an Assembly
Not in a Kit

Records deleted:
Cutting conditions
Geometry
Item
Item Suppliers
Item Supplier Prices
Locations
Spare Items
Unit ID
Period usage data

Assemblies: Only deleted when:
Not in use
Not in a Kit

Records deleted:
Assembly
Assembly build list
Presetting data
Cutting conditions
Geometry
Period usage data
Locations
Unit ID

Kits: Only deleted when:
No checks to be made before deletion

Records deleted:
Kit
Kit build list
Period usage data
Unit ID

Transaction Log #

Introduction #

ATMS has a fully traceable system for all transactions performed within the software. For stores type transactions, ATMS maintains a separate table within the database. This is called “TransactionLog”.
For a purchasing history, then the relevant requisition and order tables provide the means for recording database activity.

Stores transactions #

Whenever a stores transaction is committed, a line (or lines) is appended to the table with a code that identifies the transaction type.

These codes are summarised below.

The transaction log can be a very powerful source of management information, and this table can be exported or interrogated using the ATMS Export routine.

Code Description
101 Issue of an Item, Assembly or Kit
102 Return of an Item, Assembly or Kit to the tool stores
103 Return to Rework
104 Return to Scrap
105 Return from Rework
106 Scrap from Rework
107 Send to Rework
108 Build an Assembly
109 Dismantle a Stored Assembly
110 Inventory Transfer from one location to another location
111 Add an ordered Item or Assembly into the tool stores
112 SPS Vending machine re-stock event
113 Send to Calibration
114 Return from Calibration
115 Return to Calibration
116 Scrap from Calibration
117 Stock Adjustment
118 Issue for Build
119 Index
120 Transfer From
121 Transfer To
122 Return to Rework Holding Area
123 Send to Rework Holding Area
124 Pick Up Rework
130 Receive unordered Items
131 Receive Items from Supplier
132 Return Items to Supplier
201 Create an Item, Assembly or Kit record
202 Delete an Item, Assembly or Kit record
203 Edit and Item, Assembly or Kit record