The Tyre Import file is uploaded into a temporary holding area where the data can be reviewed and details amended before being released and posted. If the import identifies any errors (such as unrecognised registration numbers) then the unmatched records are presented separately for exclusion from the batch before posting. These will then need to be entered manually or received on subsequent files to ensure posted correctly.
At the point the data has been validated and any adjustments made this option is used to the post the file; this creates Maintenance History records as well as a purchase ledger entry in respect of the total invoice amount.
The tyre data details provided with each record is also required for future review and is therefore allocated to the maintenance history records.
Once the option to post is taken the system warns that the unmatched records will not be posted and will be lost if the process is continued. An opportunity to print/export these records at this stage for manual input later is offered.
Required information at point of posting is the invoice number and invoice date to be used (the individual invoice numbers and dates on the record may or may not be used as the reference). The posting routine follows the standard existing maintenance approval posting routines but includes the creation of a new tyre detail record accordingly. It should also be noted that on posting the system creates a different record for each different reason code allocated from the lookup table. For example, one record in the file could create a generic tyre record for several tyres allocated to the same reason code but create up to 5 separate records for the other cost items.
The new tyre detail record (FA.tyred) retains the detail for the tyre records where grouped to allow drill-down into this information at a later stage. This is effectively all the tyre related fields from each record with fields designed to tie the record up with the FA.maint record:
Field Occurs Description REGNO Registration Number VMAGIC Vehicle Magic Number SEQUENCE Reverse Repair Days KCCID Sequence No. REPFLAG 7 Replacement Flag TYRE 7 Tyre Detail REPLREAS 7 Replacement Reason TREAD 7 Tyre Tread Depth RECHFLAG 7 Recharge Flag TYREVAL 7 Tyre Price VALVEVAL 7 Valve Price BALVAL 7 Balance Price TYRRECHP 7 Tyre Recharge % TYRRECHV 7 Tyre Recharge Value TOTLINE 7 total Line Price
What do you want to do?
To access Tyre File Processing:
From the Master Menu, select the Maintenance Control option and Company required.
The Maintenance Control menu is displayed.
Select the Miscellaneous Options option.
The Miscellaneous Options form is displayed.
Select the Tyre Import Menu option.
The Tyre Import Menu is displayed.
Select the Tyre File Processing option.
The Tyre File Processing form is displayed.
This form is divided into four parts that are as follows:
In addition to displaying the form name the Title Bar displays other useful identification criteria and buttons.
| Menu | Icon | Description |
|---|---|---|
| File > Generate & Post Approvals |  |
Opens the Post Batch Date Entry form to enable the posting of the tyre file. This creates maintenance history records as well as a purchase ledger entry in respect of the total invoice amount. |
| File > Repost |  |
Allows the file to be reposted. |
| File > Exit |  |
Exits the Tyre File Processing form without posting tyre details. |
| Help > |  |
Provides online access to context sensitive help for the current application using the default browser. |
Simply displays a text message informing users what the process is about to do: This process will take all records in the tyimp file and convert them into approvals. Valid approvals will then be posted. Valid approvals can be posted separately.
Once the matched records are amended to a satisfactory state ready for posting then the
icon is used to process these records.
The Authorisation creation and subsequent posting are treated as one process.
Note: Although the form gives a brief description of the processing that is about to take place. A more detailed description of the processing rules is provided below:
Transactions
Only Transactions which match the Batch ID and Batch Year, are processed and are flagged as status P. Any unmatched records are deemed to be unwanted and manual posting or their inclusion on a subsequent batch assumed and are flagged as status D.
Recharge Calculation
For each Tyre and Other Replacement the recharge values are recalculated as part of the posting process and then used for posting.
Using the Tyre Replacement Code the system identifies if a recharge is applicable.
If the Recharge Flag is ticked within the Replacement Code table the check the Address Group for the Recharge Flag and recharge limits set for the customer. (If Recharge is flagged as Y in Tyre Replacement Code, Address Group and Recharge Limits are set then a Recharge is applicable).
The system calculates the Tyre Tread depth and associated Recharge %. The tyre tread depth banding process is used. The correct Recharge % is found by an iterative calculation based on the highest Tread Remaining depth <= Tread Depth.
System calculates the Total Tyre price as Total Tyre = Tyre Value + Valve + Balance.
System calculates Tyre Recharge as Tyre Recharge = Total Tyre X Recharge %
For Other Replacement Reasons, identify if a recharge is applicable. If applicable, then Recharge 100% of Item Value. Otherwise recharge is zero.
Unmatched Records
All remaining unmatched records (By Batch ID and Batch Year) are automatically to be set to For Deletion. i.e. the Matched? Flag set to Deletion.
For all Processed Records
For all Matched records processed the following fields are populated:- Processed User ID, Processed Date and Matched Flag set to P.
New Maintenance History and Pending invoice processing
The posting process differ to that currently in use on Kestrel in that it generates multiple maintenance history lines, one per tyre and recalculating any recharge values. A single Tyre import record when posted creates the following records and postings regardless of number of tyres replaced: Multiple Maintenance History Records. 1 line per tyre and multiple supplementary (Other Items) lines. A Multiple Tyre Detail Record. 1 line per tyre. The posting process utilises the Invoice Buffer fields Batch Number, Batch Item and Sequence numbering to achieve the consolidation of all the postings.
If Recharges are present then multiple Pending Invoice lines, containing the individual tyre recharge details, are created with recharge text derived from Tyre position, tyre size, Replacement Reason and % Recharge.
Consolidated Purchase Ledger Posting
All tyre import transactions are consolidated into a single Purchase Ledger posting. The posting consists of the total of all the matched and processed transactions from the processed batch. The posting total does not include unmatched items.
