Support #97 » Enhance Existing Bulk GRV → CGRN Wizard.md
Enhance Existing Bulk GRV → CGRN Wizard
I have an existing Bulk GRV Excel → CGRN creation wizard.
The wizard allows the user to upload a bulk GRV Excel file, process and validate the records, match the records with the relevant Lot Numbers that already exist, and create the corresponding CGRN records.
The wizard is already functional. I want to enhance it based on feedback received during testing.
The purpose of this task is only to improve the existing wizard's usability, clarity, reliability, and handling of the identified issues.
CRITICAL REQUIREMENT — PRESERVE ALL EXISTING FUNCTIONALITY
Before making any changes, thoroughly inspect and understand the existing code and how the wizard currently works.
Do not assume how the existing implementation works.
First understand:
- The complete wizard flow.
- Each step and its purpose.
- Excel upload and processing.
- Excel sheet/worksheet handling.
- Existing validation logic.
- Existing error handling.
- How records and their statuses are maintained.
- Existing checkbox and Select All behavior.
- Existing Retry functionality.
- Existing error-file download functionality.
- Existing CGRN creation process.
- Existing CGRN navigation.
- Frontend/backend communication.
- API calls.
- Loading and progress handling.
- Existing success and failure handling.
Do not rewrite the wizard.
Do not replace existing working logic with a new implementation unnecessarily.
Do not change existing business rules.
Do not change the existing GRV → validation → Lot Number matching → CGRN creation workflow.
Preserve all existing functionality, including existing:
- APIs.
- Backend methods.
- Field mappings.
- Excel mappings.
- Validation rules.
- Lot Number matching.
- CGRN creation logic.
- Error detection logic.
- Existing navigation.
- Existing processing behavior.
If an existing function already handles part of the required functionality, understand it and improve that existing implementation rather than creating duplicate logic.
Make only the changes required to address the issues described below and improve the user experience.
1. Fix Retry Becoming Unresponsive With Many Errors
During testing, when the uploaded Excel contains a large number of errors, clicking Retry can cause the wizard/screen to freeze or become unresponsive.
Investigate the existing Retry implementation and understand what is causing this behavior.
Fix the issue without changing what the existing Retry functionality is supposed to do.
The Retry operation should remain usable even when there are a large number of error records.
The user should be able to clearly understand that the Retry operation is currently processing and should not be left with a screen that appears frozen.
The UI should remain responsive during the operation.
Also make sure that after Retry completes, the wizard correctly reflects the resulting state using the existing application logic.
Do not solve this by simply hiding the problem or changing the underlying validation/business logic.
The goal is to make the existing Retry functionality reliable and user-friendly, especially for larger numbers of errors.
2. Improve the Error File Download
During testing, the downloaded error file currently contains records that are not actually errors along with the records that require attention.
Understand how the existing wizard determines and stores the validation/error status of each record.
Then improve the existing error-download functionality so that the file downloaded through the Download Error action represents only the records that currently require correction according to the wizard's existing validation logic.
Do not create a separate error-detection mechanism.
Do not change the existing validation rules.
Do not change the original uploaded Excel.
Do not unnecessarily change the existing Excel structure or format.
The user should be able to download the error file and immediately understand that it contains the records requiring attention.
The behavior should also remain correct after Retry, because the error state may change after a retry.
3. Improve Step 5 Instructions for CGRN Navigation
In Step 5, after CGRN creation, the wizard displays the created CGRN information.
However, it is not clear enough to the user that the CGRN shown in the wizard can be clicked to navigate to the corresponding CGRN document in Frappe.
Improve the Step 5 UI so that the user clearly understands what they need to do.
The user should be able to immediately understand that:
- The CGRN has been created.
- The CGRN displayed is clickable.
- Clicking the CGRN will open/navigate to the corresponding CGRN in Frappe.
Add clear, concise instructions in the appropriate location within Step 5.
Keep the existing CGRN creation and navigation functionality unchanged.
This is a user-guidance improvement, not a change to the CGRN functionality.
4. Handle Download Error When There Are No Errors
During testing, the Download Error action does not behave appropriately when there are no errors.
Review the existing wizard state and error-download implementation.
Improve the user experience so that the Download Error functionality behaves logically when there are no error records.
The user should not be given misleading behavior or a file that does not represent an error state.
The UI should make it clear when there is nothing available to download.
Keep this consistent with the existing wizard design and state management.
5. Make Step 2 Selection Instructions Clear and User-Friendly
There is an important usability issue in Step 2.
Currently, the user needs to use the Select All option before proceeding with the records, but the wizard does not make this sufficiently clear to the user.
The Next button itself is not the problem and should not be changed into a validation mechanism based on whether the user manually selected records.
The issue is that the wizard should make it obvious to the user what they are expected to do in Step 2.
Review the existing Step 2 UI, checkbox behavior, Select All functionality, and the way records are presented.
Improve the Step 2 experience so that a user who reaches this step can immediately understand:
- What the checkboxes represent.
- What records are currently selected.
- What the user needs to do before clicking Next.
- That the Select All action can be used to select the records intended for processing.
- Which records cannot/should not be selected because of their existing error state.
Where appropriate, make the normal/default state of the Step 2 selection intuitive so the user does not have to unnecessarily figure out what to select.
If the existing design already supports selecting all applicable records, make that behavior clear and easy to understand rather than introducing a new selection system.
The objective is that a user should reach Step 2 and naturally understand:
Select the records you want to process (or use Select All for the applicable records), then click Next.
Use wording and UI behavior that fits the existing wizard rather than adding excessive instructions.
Do not change the existing business rules regarding which records can actually be processed.
Do not alter the existing CGRN creation logic.
Do not introduce a new validation rule simply because the user did not click Select All.
This is primarily a usability and guidance improvement.
6. Excel Should Work Regardless of Worksheet Name
There is another issue found during testing.
The wizard currently expects the uploaded Excel file to contain a worksheet with a specific name, such as "DataSheet".
When a user uploads an otherwise valid Excel file where the worksheet is named something else, for example "Sheet01", the wizard throws an error instead of processing the file.
This should be fixed.
The wizard should not unnecessarily depend on a hardcoded worksheet name when processing the uploaded Excel.
Review how the existing Excel-processing logic identifies and reads the worksheet.
Modify the implementation so that users can upload valid Excel files even when the worksheet has a different name.
The wizard should identify and process the appropriate worksheet based on the existing Excel structure/content expected by the application rather than requiring the user to manually rename the worksheet to a specific name.
For example, if the uploaded workbook contains the expected data but the worksheet is named differently, the wizard should still be able to process it.
Do not change:
- Existing Excel column mappings.
- Existing data extraction logic.
- Existing validation rules.
- Existing GRV processing logic.
- Existing Lot Number matching.
- Existing CGRN creation.
Only remove the unnecessary dependency on the worksheet having one particular hardcoded name.
Also make sure this change does not break files that currently use the existing worksheet name.
The existing supported Excel files must continue to work exactly as before.
Overall User Experience
While implementing these specific fixes, review the wizard from the perspective of a normal end user.
Do not redesign the entire interface.
Do not add unnecessary features.
Do not make unrelated changes.
However, where the current wizard makes the user guess what they should do, improve the relevant UI or instructions so that the intended action is obvious.
The wizard should communicate clearly:
- What is happening.
- What the user needs to do.
- Which records require attention.
- Which records are ready for processing.
- When an operation is in progress.
- When an operation has completed.
- What Retry is doing.
- What the downloaded error file represents.
- What the user should do in Step 2.
- What happens after CGRN creation.
- How the user can open the created CGRN.
Use simple business-user-friendly language.
Do not expose technical implementation details to the user.
Important Implementation Principle
Do not implement the suggestions based only on the wording in this prompt.
Understand the intent behind each suggestion and then determine the correct implementation by studying the existing code.
The existing code is the source of truth for how the wizard currently works.
For every change:
- Understand the current behavior.
- Identify the actual cause of the reported issue.
- Preserve the existing working logic.
- Make the smallest appropriate change.
- Verify that the change solves the user's problem.
- Verify that existing functionality has not been affected.
Do not assume that a particular technical solution is required.
Choose the implementation that best fits the existing architecture.
Do Not Introduce Unnecessary Changes
Do not:
- Rewrite the wizard.
- Replace existing working functions unnecessarily.
- Create duplicate validation logic.
- Create duplicate error-state logic.
- Change existing business rules.
- Change API contracts unnecessarily.
- Change database behavior unnecessarily.
- Change Excel field mappings.
- Change Lot Number matching logic.
- Change CGRN creation logic.
- Redesign the entire UI.
- Refactor unrelated code.
- Add unnecessary dependencies.
Keep the implementation focused on the identified issues and usability improvements.
Testing
After making the changes, test the complete existing workflow.
Verify:
Excel Upload
- Existing Excel files continue to work.
- Excel files with the existing worksheet name continue to work.
- Excel files with a different worksheet name also work.
- The expected data is still read correctly.
Validation
- Existing validation rules continue to work.
- Existing error detection continues to work.
- Lot Number matching remains unchanged.
Step 2
- The user can clearly understand what to do.
- Select All behavior remains correct.
- The selection state is understandable.
- Error records are not unintentionally processed.
- The existing Next functionality continues to work.
Retry
- Retry works normally with a small number of errors.
- Retry works with a large number of errors.
- The UI does not appear frozen.
- The user can understand that processing is taking place.
- The resulting validation/error state is correctly reflected.
Error Download
- The downloaded error file represents the current error state.
- Valid/non-error records are not incorrectly included.
- The behavior remains correct after Retry.
- The no-error state is handled clearly.
Step 5
- CGRNs are still created exactly as before.
- The CGRN is still clickable.
- Clicking the CGRN still navigates to the correct Frappe document.
- The user can clearly understand that the CGRN is clickable.
Final Requirement
This is an enhancement to an existing working wizard, not a new development or rewrite.
The existing business functionality is already working and must be treated as the baseline.
Understand first. Modify second.
Do not change existing functionality simply to make the implementation easier.
The final result should be the same existing Bulk GRV → validation → Lot Number matching → CGRN workflow, but with the identified issues fixed and the wizard made significantly clearer and easier for a normal user to operate.
- « Previous
- 1
- 2
- Next »