This article is for functional experts to work with developers to determine the best way to place an order into rework.
- User = Pruvan Account Owner/Users
- Order Source = system sending orders to User's Pruvan accounts
A User receives an order, completes the work, and publishes the results back to Order Source.
The Order Source rejects the work and places the order into rework.
The User gets the order back into their Pruvan account with a notation of REWORK. The job is assigned back to the field. The original survey (if applicable) has previous answers or photo requirements that must be re-worked made evident to both back-office Users and the field User.
To assist the related User(s) in what to do, the Instructions and Survey Questions are clear in communicating exactly why the order is in REWORK and what is expected to correct any issue(s).
How this User Story can be accomplished:
When the Order Source gets results from a User’s Pruvan account that requires an order to be reworked, the Order Source may
- choose to update the original order into REWORK or
- create a new order
Once an order is selected for rework, the Order Source developer must decide how to send the order back to the User's Pruvan account for rework mapped to a Pruvan Project. The developer may:
- choose to update the SuryeyDynamic field with previous answers and validate related answers. This allows User to edit/update all questions using previous answers provided by Order Source, OR
- create a new dynamic Survey for the Project in Pruvan that only asks the questions and requests only the photos that are required, OR
- make the User repeat the entire workflow, re-answer all questions and retake all required photos
The developer may use SurveyDynamic to populate previous answers and validate answers given by User on file-based surveys. SurveyDynamic can act as an "overlay" to change the behavior of a file-based survey definition. The developer may also use SurveyDynamic to define the entire survey, leaving the Survey field blank.
The developer must populate all relevant fields to let the User know why the order is in rework, and what is expected to resolve the issue(s).
Order Source developers should concern themselves with what the Pruvan account report when sending orders to Pruvan accounts (see POST method results returned in API). If the order is not reported updated, the Order Source must recreate the Order with all related order details. If the Order is updated, meaning the same Project name is found in the Pruvan account’s active Project list, the order will be updated with new information according to Auto-Admin settings.
Note: If Auto-Admin is OFF in the User's Pruvan account the Project Status, Project Description, Project and Task Instruction, Due Date will not be overwritten. Auto-Admin is typically turned OFF (default is ON) for Vendor’s who perform back-office management of Pruvan Projects.
Because of the behavior of Auto-Admin, the Order Source should also update all Client (Order Source) controlled fields, such as Info, Client Instructions, Client Status, Client Due Date, Reference, and change Survey Questions to make it clear to both back-office workers and field staff the Order has changed.
To avoid Auto-Admin issues you may choose to create a new Project in Pruvan by changing the Order name (Project Name) to have a suffix called “REWORK” for example “1234567-REWORK” for fictitious order 1234567 that requires rework. This will appear in Pruvan Online if the client code is “XYZ” as “XYZ::1234567-REWORK” making it clear in Pruvan Online that a new Project has arrived that requires rework. The attributes should be set to allow the results to come back to the original order 1234567 or the proper order as needed in your Order Source rework workflow.