Try to be focused on trying to make the components part better in the prototype, in order to have clear separation of objects in the pages.
Let's start, as new experiment, a new menu item named "Item_v2" (that will load same "Item" v1 records table) that will introduce enhancements in the way pages are composed.
Once "Item_v2" will be done and checked as successfully, you will modify accordingly also the others (customers, contracts, ...) and will delete "Item_V1".
We saw now that in the list you have merged also the buttons to manage the details (view and add/edit).
We think it is not nice, much more better to have common and reusable components and not specific and repeated ones in all process.
It is not nice to see in the list all the buttons that are not specific to the list, example we see the list also buttons for add-edit as Cancel, Save (and others).
We see all the buttons in list overlapped and this create confusion and for sure difficulty in future modifications or maintanance.
Example we would like that the list will load the following 3 distinct components:
1) "Standard list buttons bar" component --> not specific to "Items", but general, common one (so this component must be present 1 time only and not repeated for each process)
The numbers of buttons is same as the one you have already implemented in all the list (Open, Add new, Search, Delete, Show all, Report, other action drop down, etc...)
On the left part, as now, the Simple search object.
2) "List" component --> this will be specific page of "Item_v2" (so this component will be created and present for each process)
This part will be made "only" of the grid and not the other objects, as actually done in v1
3) "Message" component --> not specific to "Items", but general, common one (so this component must be present 1 time only and not repeated for each process)
The detail for view will the following 2 distinct components:
1) "Standard view detail buttons bar" component --> --> not specific to "Items", but general, common one (so this component must be present 1 time only and not repeated for each process)
The numbers of buttons is same as the one you have already implemented in all the view detail (Navigation previous, next, Add new, Edit, Delete, Back, other action drop down, etc...)
2) "Detail" area component--> this will be specific page of "Item_v2" (so this component will be created and present for each process)
This part will be the detail itself as actually done in v1
The detail for add-edit will the following 3 distinct components:
1) "Standard add/edit detail buttons bar" component--> --> not specific to "Items", but general, common one (so this component must be present 1 time only and not repeated for each process)
The numbers of buttons is same as the one you have already implemented in all the add/edit detail (Cancel, Save, other action drop down, etc...)
2) "Detail" area component--> this will be specific page of "Item_v2" (so this component will be created and present for each process)
This part will be the detail itself as actually done in v1
3) "Message" component --> not specific to "Items", but general, common one (so this component must be present 1 time only and not repeated for each process)
The above structure should be working also if called from other process: example now user can from contract line detail open the Item process.
Once "Item_v2" will be Ok, "Item_v1" will be deleted, so from contract line detail it will be called the "Item_v2" process.
Try to be focused on trying to make the components part better in the prototype, in order to have clear separation of objects in the pages.
Let's start, as new experiment, a new menu item named "Item_v2" (that will load same "Item" v1 records table) that will introduce enhancements in the way pages are composed.
Once "Item_v2" will be done and checked as successfully, you will modify accordingly also the others (customers, contracts, ...) and will delete "Item_V1".
We saw now that in the list you have merged also the buttons to manage the details (view and add/edit). We think it is not nice, much more better to have common and reusable components and not specific and repeated ones in all process.
It is not nice to see in the list all the buttons that are not specific to the list, example we see the list also buttons for add-edit as Cancel, Save (and others). We see all the buttons in list overlapped and this create confusion and for sure difficulty in future modifications or maintanance.
Example we would like that the list will load the following 3 distinct components:
1) "Standard list buttons bar" component --> not specific to "Items", but general, common one (so this component must be present 1 time only and not repeated for each process) The numbers of buttons is same as the one you have already implemented in all the list (Open, Add new, Search, Delete, Show all, Report, other action drop down, etc...) On the left part, as now, the Simple search object.
2) "List" component --> this will be specific page of "Item_v2" (so this component will be created and present for each process) This part will be made "only" of the grid and not the other objects, as actually done in v1
3) "Message" component --> not specific to "Items", but general, common one (so this component must be present 1 time only and not repeated for each process)
The detail for view will the following 2 distinct components:
1) "Standard view detail buttons bar" component --> --> not specific to "Items", but general, common one (so this component must be present 1 time only and not repeated for each process) The numbers of buttons is same as the one you have already implemented in all the view detail (Navigation previous, next, Add new, Edit, Delete, Back, other action drop down, etc...)
2) "Detail" area component--> this will be specific page of "Item_v2" (so this component will be created and present for each process) This part will be the detail itself as actually done in v1
The detail for add-edit will the following 3 distinct components:
1) "Standard add/edit detail buttons bar" component--> --> not specific to "Items", but general, common one (so this component must be present 1 time only and not repeated for each process) The numbers of buttons is same as the one you have already implemented in all the add/edit detail (Cancel, Save, other action drop down, etc...)
2) "Detail" area component--> this will be specific page of "Item_v2" (so this component will be created and present for each process) This part will be the detail itself as actually done in v1
3) "Message" component --> not specific to "Items", but general, common one (so this component must be present 1 time only and not repeated for each process)
The above structure should be working also if called from other process: example now user can from contract line detail open the Item process. Once "Item_v2" will be Ok, "Item_v1" will be deleted, so from contract line detail it will be called the "Item_v2" process.