Repair and Return Possible Status Changes( In warranty

Jobs )

1.Open

2.Ready To Dispatch

3.Dispatched – ARC

4.Intransit ARC

5.Pending Receiving Inspection

6.Inspection Done

Repair Process
Exchange Process
7.Awaiting For Allocation If required spares are not
7. Awaiting For Exchange
available or business decided
8.Allocation In Progress to exchange
8.Exchange Unit Ready – Dummy
9.Allocated Invoiced

10.Repair In Progress

11.Spares Requested

12.Repair In Progress

If required Spares are available

13.Repaired QC Pending

Quality Check

14.Awaiting For Allocation – QC

15. Allocation In-Progress – QC

16. Awaiting For Acceptance – QC

17. QC In-Progress

18.QC Failed 18.QC Passed

19.Invoiced
 Dispatching To Store Dispatching to Customer

20.Ready To Dispatch – PUP 20.Ready To Dispatch-

Customer
21.Dispatched – PUP
21.Dispatched- Customer
22.Intransit – PUP
22.Sent - Customer
23.Delivered Awaiting
Receipt

24.Awaiting Customer
Collection

25.Customer Collected

Types of Jobs in Repair System:

1- Repair & Return – (In-Warranty, Out-Warranty)
2- OBF – Which is Out- Of Box Failure
3- CCD – Similar to Repair & Return type the difference is
that the device will be collected from Customer and
will be delivered to customer after repairing

Possible Issues in Each Process:

Repair Process:
Unable to change status from Inspection Done: ( Criticality:P1)

If the user claims that he/she cannot change the status from Inspection Done ,then there Is
an issue with Repair Order creation. Check repair_job_no column from the below depot
booking table. If there is no repair order number, please proceed to change the status to
Pending Receiving Inspection and then again to Inspection Done. This will create RO and
then status change can happened once the repair_job_no column is populated.

Unable to Allocate the Job: (Criticality:P3)

If the user claims that he cannot allocate the job, then check the OAF page from below path

SP Dr Allocator – SPM >> Handover Allocation dash Board

Check 1: Check if the RO status from RO screen and current status in Depot table are same.
If they are not same, then we cannot change the Repair status . Go to Repair Order and
change the status as in the Depot Repair table.
Check 2: Check if the ro_status AND job_status columns from the table
xxcc_dr_allocation_ho are same as depot booking table . If not change the above two
columns as depot booking table.

Check 3: If the jobo to be allocated then employee_name and employee_number columns

should be null in depot.xxcc_dr_allocation_ho table. If they are not null then make them
null for the job to be allocated.

Check 4: Check if there is any previous job booked for the job by search with IMEI in
booking table. If there is any job , please check if the repair_flag from
depot.xxcc_dr_allocation_ho table is ‘Y’ for the previous job and ‘N’ for the current one.

The OAF page accepts the jobs only with repair flag ‘N’.

Check 5: Please check if there is any duplicated in the depot.xxcc_dr_allocation_ho table. If

yes, then delete one record.

Please note: All these are identified from OAF page implementation. If the issue still cannot
be resolved, please check the OAF page for detailed process.

Unable to Access the Job: (Criticality:P2)

If the user is unable to access the job ,then he/she cannot access the Repair Order screen
due the personalization that were defined.

Check 1: Check depot.xxcc_dr_allocation_ ho table. Employee number and employee name

should be the user name. If the employee_name is defined as with one name , for example
Masondo, Miss Nompumelelo Brenda Nompumelelo , then on;y she can access the job.

Check 2: Same as above but check the job_owner column from depot booking table, and
employee name should be Masondo, Miss Nompumelelo Brenda Nompumelelo for Brenda
to access the job.

If the user asks you to change the status to some X on some Y name: (Criticality:P2)

If the user asks you to change the status like above format ,then change the status to the x
status and then update the employee_number, employee_name columens from
depot.xxcc_dr_alloctaion_ho table to name of Y.
Unable to Dispatch: (Criticality:P2)

If the user ask you to check the jobs which he cannot dispatch then check the below
scenarios

Check 1: Check if the jobs are in appropriate status to be dispatched. Ready To Dispatch
PUP, Ready To Dispatch Customer, Outsourced ERC are the status in which the user can
dispatch. If the current job status is not any of these, Change status from Backend till these
statuses.

Check2: Check courier_collection column from depot booking table. If the value is samePUP
then status should be Ready To Dispatch PUP for the job to be dispatched. Samwat, if the
courier collection column is custAddress, then the status should be Ready To Dispatch
Customer.

Check 3: If above two doesn’t work, please perform as mentioned in the attached.

Unable to Receive:

If user requests that he/she is not able to receive, then check the flags in the below tables.

update depot.xxcc_dr_book_job_dtls_tbl set process_flag='D' where

atg_job_no='MPBUR205027'

update depot.xxcc_dr_dispatch_receiving set invoice_flag='H' where job_number

='MPMID304936' and batch_no is null

QC Passed button is missed:

If the user writes a mail saying the above issue, this is because the job went to QC previously
and again they wanted to QC the device.

Delete the job record from the below table using the below query.

delete from depot.xxcc_dr_qc_t where job_number='FSSAS369076';

Exchange Process :
All the exchanges are done from custom OAF screen and the navigation is mentioned below.

SP DR Storeman – SPR >> Storeman Exchange

Check 1: Check if there are nay duplicates for the IMEI in the below table. If duplicates exist,
please delete the old one and keep the latest ones in table.

select * from depot.XXCC_DR_EXCNG_DEVICE_TBL where faulty_imei='869438046699866'

Check 2: Please check if the IMEI is previously exchanged. If it is previously exchanged, let
the user know this and act accordingly as we should not provide an exchange to the IMEI
which is already exchanged. The exchange details can be viewed from depot booking table.

Check 3: Need to check the IMEI which the user is trying to exchange is present in the
inventory or issued out. All the exchange IMEI’s will be present in SP Service sub inventory.
If the IMEI is IN-Stock then the current status will be 3 from the below query. If it is issued
out then it will be 4. If the status is 4 then user should be notified with this issue.

select last_update_date,inventory_item_id,current_organization_id,
current_subinventory_code, current_status from apps.mtl_serial_numbers where
serial_number in('867991058879596')

If there is any issue other than mentioned from this document, please refere the respective
OAF pages for the complete detailed of the process from knowing how the page is
implemented.