When Your Ticket System Doesn't Come With You

ICSIS runs on the corporate network. The ticket you need to acknowledge, update with arrival, log activity against, and close — that sequence exists in a system that assumes you have a laptop and a VPN connection. In the field, standing in a server room in a branch location with a dead WAN link, you have neither.

The IPA Field Service application built in Memento solves the documentation problem on the mobile side: log the complete ticket interaction locally, then push or transcribe when you have connectivity. The structure is not a simplified version of the ICSIS workflow. It mirrors the full ticket lifecycle with the same coded fields, the same billing classifications, and the same analysis codes that the back-end system expects — so reconciliation is clean rather than interpretive.

Travel Time as a Calculated Billing Field

The Departure Time and Arrival Time fields feed three calculated outputs. Travel Time (min) rounds up to the nearest 15-minute billing increment — the standard Bell ATS billing rounding convention. Actual Travel (min) gives the raw elapsed time in minutes. Billing Times assembles a formatted string showing all three values simultaneously: Travel minutes, Work minutes, and total Billed minutes, formatted as T:XX | W:XX | B:XX.

The Charged Minutes field adds the 15-minute-rounded activity time to the 15-minute-rounded travel time, giving the billable total that feeds the ICSIS entry. Both rounding calculations handle the negative-result edge case — if the arrival time is earlier than the departure time due to a data entry error, the field returns a blank rather than a negative number.

The job code (WR: Work Request, TM: Time and Materials, ST, CT) and billing classifications (Billing 1: Exclude or Time and Material; Billing 2: Regular, Continuous, or Without 48 Hours) are the fields that determine how the time is actually invoiced. A Continuous billing classification on a TM job code behaves differently in the billing system than Regular billing on the same job code, and having these committed to the record at closure prevents revision arguments with billing later.

Hold and Resume as a Complete Code Set

The H1 through H8 and R1 through R8 hold and resume reason codes are the operational intelligence of the ticket lifecycle. H1 (Hold for Bell-ATS Parts) means the job is on the supplier's timeline. H2 (Client Unavailable) means the delay is on the client side. H4 (Client OK; Temporary Service — Hardware) means you left a loaner in place while waiting for the actual part, which triggers different billing treatment than H1. H7 (Client Not OK; Provided Loaner) means the client has a device but is not happy about it — a flag for expedited follow-up.

The corresponding Resume codes (R1 through R8) close each hold with the matching code, creating a paired record of why work stopped and why it restarted. Across a month of tickets, the distribution of H-codes tells you where your delays are coming from: parts supply, client scheduling, or quote approvals.

Hardware Codes and Closed Analysis Codes

The HC hardware code set — HCAA through HCPX, covering adapter types, drive types, memory types, cable types, printer types, and peripherals — is the component-level classification that turns a closed analysis code of HC (Hardware Code) into a specific part category. HCDH (Drive Hard) means a failed HDD. HCPF (Printer Fuser) means a fuser replacement. HCMD (Memory DIMM) means a RAM module. These codes feed defect trend analysis at the component level — which is only possible if techs are selecting codes consistently in the field rather than approximating after the fact.

The Closed Analysis code set covers 37 classifications from AM (Account Maintenance) through WD (Wrong Dispatch), with important entries like NT (No Trouble Found), CE (Created in Error), and ROEX (Referred Out to External Group). NT is the code that tracks phantom tickets — calls where the equipment was functioning correctly when the tech arrived. A high NT rate at a specific customer site indicates a training or expectation issue that needs addressing before it consumes more dispatch hours.

The XML export calc fields — [ESPP], [Actions], [Activity], [Suppliment], [Parts] — assemble the structured output that feeds the back-end system. The ESPP field bundles version, datetime, operator code, ESPP state (In/Out/Dest), GPS coordinates, address, and email into an XML block. Actions bundles ticket number, action, hold reason, analysis code, and summary. The entire ticket record can be exported as structured XML without any additional formatting step.

The barcode fields for Part Number and Serial Number use the device camera to scan manufacturer barcodes at the hardware level — eliminating transcription errors on 15-character serial numbers entered manually in a dim server room while crouched behind a rack.