AMS – ODBC Driver

ODBC drivers are the interface used between the program data files and the Windows printer function.  We have noticed that several 3rd party software programs may overwrite the ODBC settings used by AMS32 in report printing.  These include MS Office, xx & MS Intellimous installations.    This is evidenced by an error box indicating an ‘ODBC’ error.  ODBC driver errors can be rectified by running the ODBCInstall.exe file from the ‘SETAMO’ directory or the original CD

AMS Upgrade T&T2003R14

The latest AMS program upgrade is available from Avdex and can be downloaded.
This upgrade includes various changes and fixes made over the past few months as well as report changes.
It is important to update the executable to keep up with the latest fixes and modifications, but also to allow you to upgrade user licenses.via the online licence key generation.
The new Exe download may initially be downloaded from this link and saved to Q:\Data\Setams directory.  Note that the dowloaded files are by default stored in a different directory and you might have to change this before downloading by selecting the "Save As" option. In most cases the Q: drive is the default drive for AMS programs on the server, but some installations might use a different drive.  This directory is used because it is accessable to all users and it is therefore best to save the installation file in this directory to avoid every user downloading the installation file.

Remember to make a Backup!

How to upgrade

For those users with version 2.22.00 or later, open 'Housekeeping - Config Options - Company' and select 'Download Update'.  A download window will open and the program will automatically download the latest upgrade file from the ftp site.  This download window can be closed when complete or will auto close five seconds after completion.
To start the upgrade, exit and  manually run Q:\Data\Setams\Setup.exe (where ‘Q’ is the default installation data drive).
To upgrade the report templates, open 'Housekeeping - Config Options - Company' and select 'Download Reports'.  A download window will open and the program will automatically download the latest upgrade file from the ftp site.  This download window can be closed when complete or will auto close five seconds after completion. Manually run Q:\Data\Setams\SetupReports.exe (where ‘Q’ is the data drive).

IMPORTANT

When complete, ask all users to exit AMS.  Relaunch AMS. If the file structures need updating, the program will display a warning.  Select 'File Structure' and select each file that is not OK and press ‘Update’.  When complete, Exit re launch AMS and select ‘Housekeeping - System - Data Files - Build Index’.  Un tick the box ‘Use IDK Reference’ and press ‘Start Indexing’.  Apparent data loss may appear if a re index is not done

Reports

When complete, go to ‘Housekeeping - Config Options - Company’ and download the reports upgrade by pressing ‘Download Reports’
Run the SetupReports.exe(only needs to be run once).

Using the Item Trigger feature in Status

There are a number of situations where one item is only due after the compliance of another item.  This option is now available in the schedules where a trigger value can be entered in the item beeing triggered.  Together with this feature, we have implemented an option to make items non repeat items.

The configuration of these links can be done from the Status program on Window W1500.

 

Implementation of SharedID

As we have implemented the possibility to move schedules from one data base to another, we can not assume that the ItemID field will be unique once a schedule has been move to another database.  For this reason, we have implemented a SharedID field.  It is important to keep in mind that only one server can allocate SharedID numbers and this must be the parent server.  In a user environment where a server is the only server and there is no expectation to import schedules at a later stage, the server is by default the parent server.  Users can allocate their own SharedID values for each item in a schedule. This can be done from the Schedule Window W1300.  Once SharedID fields are allocated, they will be visible on reports as well as on W1500 where schedules are edited.  Each item in a schedule has a unique ItemID followed by a Shared ID which is unique amongst all servers sharing the same Schedule.  Note the value in brackets, which is the the sharedid allocated, next to the ItemID which is unique to your database.

 

Repeat Items

Users will notice that the latest Status program makes provision for a “Repeat status” on an item.  The default is for all items to be repeat items as that is the way schedules were designed in the past.  There is however situations where an item is due within a specific period and the becomes inactive.  This was previously handled by the “Single” item type, but had the disadvantage that these items always showed with a Due status.

By marking an item as a non-repeat item, the status of the item will change to inactive once it has been complied with and an Install date was given to the item.

Trigger Items

The trigger requirement followed on the repeat item feature.  This is used where an item is activated once a previous or parent item has been complied with.  It is important that the parent item is of the type Non-repeat and must have a SharedID allocated as described above.  Simply move to the child or triggered item and enter the SharedID of the parent item in the trigger field.  You can then select the Trigger button next to the field that will check the validity of the value entered.

 

Calculation

It is important for users to understand how the calculations are done and the status of these fields are activated.  Most of the calculations are based on the presence of an Install Date.  To maintain integrity, this feature can only work automatically in one direction.  Providing am Install date will trigger the child field, but removing an Install date will not always undo the child activity as this might be incorrect.

Non-Repeat Items will automatically become inactive, once an Install date has been entered in the maintenance part of the item (W1600).  If an Install date is removed, no change will be made to the “Active” status of the item as users might want the item to remain inactive. 

A similar pricipal is followed when a child item is triggered by a parent item.  Once the Install date is supplied to the parent item, the triggered item will be made active and the parent compliance data will be carried over to the child or triggered item.  The child will therefore have the same install date, hours, cycles and landings of the parent item.  The information will depend on the type of parent item.  The exeption to this is in the event where the child was already active with  maintenance data at a later date, in which case no change will be made to the child or triggered record.

As before, this will not reverse automatically if the install date is removed from the parent item.  The reason is that there might be valid maintenance information recorded in the child item.  The child item will remain active with the data as recorded before.  Users wil manually have to remove this information from the child or triggered item if it was incorrectly allocated.

When the maintenance is calculated all triggered items without Installation dates will automatically be made inactive.

Implication of “Username” or ID fields

AMS users are identified on the PC workstation by the “UserName” field.  This field is widely used through the AMS database as an unique key and is linked to a specific staff member.  The “FullName” field can be edited as this is purely used for display and not linked to the database records.

We recently received a call from a client complaining that a technician loaded on the AMS Labour system seemed to have been linked to an entire history of jobcard activity and edits as well as a default signature, all of which were not his.  On investigation, it was found that on joining the company, the new user had merely edited an existing data entry for a technician who is no longer in the employ of the Company to add his name to the system.

This raises the question of data integrity in the AMS program.  It must be understood that data appearing on computer screens (especially in AMS) is not just a display of a name, but a data record that is cross linked to many other data records.  These include Customers, Suppliers, Parts orders, Job numbers, Sub-con numbers, Technicians, Part numbers as well as individual Parts receipts(Inventory).  In a number of AMS windows, the data record name is protected and can only be edited by pressing the button to the left of the data field.  These include the Aircraft Registration, Customers name, Supplier name as well as the Part number.  Part number editing can be very disruptive as two data entries with the same part number will never show up as the program always stops searching on finding the first entry.  In this case use should rather be made of the 'Replace' function.

Use should always be made of the 'Blue Page' at the top of all AMS windows when adding a new record.  Never edit an existing data record to add a new entity.  One can imagine the chaos if fifteen years of purchases are suddenly attributed to another supplier!  Users will notice that most windows shows an ID field.  This field is not normally used by AMS users, but this ID key field link to all child records in the database.  By changing the name or description associated to the ID, users will change the description associated with all other child records!

We encourage users to limit access to editing in AMS to qualified users who understand the implications of the editing they are undertaking.

Jobcard–Parts link

AMS32 allows for parts to be linked to Jobcard defects, each with a specific Card ID on issue.  These are not always correctly linked at the time of issue and the need has arisen to allow for re linking of these parts to the defects prior to Job closing.   The method up until now has been to return the part to stock and re-issue, but this is time consuming.  A new link window W520 has been developed to make this re-link process more user friendly.

Menu: Management | Jobcard

To be able to use this new feature, AMS32 v 2.23.15 must be installed and the data re-indexed. To re-link parts issued on a Job, whether linked to defects on issue or not, go to W510.  Select the required job and then select 'Allocate Parts' button. (Only available on open jobs)  This will open window W520.   All the parts are listed in date order together with the linked Defect or Card ID.  To change the linking, select the 'Card ID' field to highlight and click a second time.  This will then show a drop-down list of all defect Card ID's  in sequence.  Select the correct ID to re-link the part.  There is no need to save the changes.  Part quantities can also be checked at this stage, but no other editing can be done from this window.

A previous version of AMS32, incorporated a safety feature to prohibited the deleting of Jobcard Defects while parts are linked.  This is a good place to check and re-link parts to another Card ID prior to deleting a defect ID from a Job.

Index key file IDK

AMS uses a dBase file system.  The speed of this system depends on the accurate index files.  The default index file system used in AMS are CDX files due to their robust nature and flexible application capabilities.  The dBase system is fairly robust and faster than most other flat file systems.  The nature of the implementation of the shared client server processing makes the file system subject to corruption when power failures or network interruptions are experienced during operation.

AMS has been designed with an additional safety element.  This system simply keeps the last record ID in a Ascii file with an IDK extension.  When new records are added the new ID’s are checked against the ID stored in the Ascii file.  This simple method provides additional safety as it is immediately clear when an index file is potentially corrupt.

IDK files are created from the normal data re-index window.  Simply check the “Use IDK Reference” on the re-index window.  This will create the IDK files during re-indexing.  This will be the default as long as IDK files are found in the data directory.  Un-tick this check box to delete all the IDK files during the next re-indexing and the program will operate without this feature.

The IDK file system is an additional check that could assist with early detection of corrupt indexes and will in no way change the operation of the program.  These files can therefore be deleted at any time and it is not required to back them up as they can be generated during indexing.

Parts Receiving – Automatic Verification & Selling Price

When a part is received from an order, a number of basic checks are performed to assist the user identifying possible data errors.  Various options are available to the user to ensure the store prices are maintained at a relevant level.

Warnings that will prevent receiving of the part

• Users must provide the following compulsary fields:
• GRV number
• Release reference
• Values that are checked
• Quantity received must be greater than zero
• Quantity received must be equal or less than the outstanding order quantity
• If a part is immediately issued to a job, the job must be open

Warnings that will allow the part to be received

• Parts received at zero cost
• Part selling price calculated above the current store price

Calculation of selling price

• When users specify a “List Price” for a part, the selling price is calculated, using the “List Price” as supplied multiplied by the transaction forex rate if appliacble.
• If no “List Price” is supplied, the calculated selling price will be based on cost plus the standard handling fee.
• If the part falls in a Part group with a factor defined, the factor will be applied to the selling price calculated with the normal handling fee.  Note that a Group factor is also applied to “List Price” that might be provided.
• Should the calculated selling price exceeds the current selling price, as recorded in the store, a warning will be generated to increase the selling price.  Users will be prompted with the old and suggested new selling price for the part.  This can be acccepted or rejected by the user.

Batch calculation of Selling Prices

Selling prices as recorded in the store will reflect prices calculated on parts that might no longer be in stock.  To achieve the best accuracy of selling prices, users could calculate stock prices on the Calculation Window (W911) by selecting the “Store Prices” option.  This will ensure that prices are based on inventory in stock.  These calculations will also use the current exchange rates as provided in the Foreign tables.  When there is no stock in the store of a specific part, the cost for the most recent received ltransaction for the part will be used for the store “Selling Price”.