Information Systems:IN-NAMECHG - Business Partners
Business Partners in Infonet consists of the following programs to display and manage uniPHARM business partners (customers, shareholders, suppliers etc.):
- IN_NAMECHG.PGM
- IN_NAMEADD.PGM
- IN_NAMEDSP.PGM
- IN_NAMELST.PGM
Although green screen processes could still be used to add/change partners in ASW, the correlating programs in Infonet are the de facto standard methods for performing these tasks.
Technical information
We are testing BitBucket for documentation of actual program code, so that will not be included here (or in correlating areas of other pages dedicated to individual Infonet programs)-norwizzle (talk)
General flow of 'Add Partner' and limitations
IN_NAMEADD is called by submitting the form (e.g. clicking 'Add partner') at the top of the main Business Partners page (IN_NAMELST.PGM). This form has only two selectable parameters: customer type and account type. The program then redirects to IN_NAMECHG (Work with Partner Information), which is what presents the user with a form to complete setup. Herein lies a catch-22 and is a huge flaw in program design: because the same program is being called to both add and change partners, without having entered any information yet during 'add partner' (except customer and account types), records must already exist at this point for the program to be able to change them. Doing it this way forces the creation of preliminary records, which is exactly what is being done by IN_NAMEADD.
One example of where this design flaw has manifested itself is the specification of a price list when adding a partner. Because records have to be created in the price list files before the province is known, an arbitrarily chosen default is set instead. If the default is incorrect, the user has to submit the current change to the form, go back into it, invalidate the previous price list by expiring it, and set a new price list. It might make sense to move this routine later in the process, and say, not add records initially but instead have IN_NAMECHG do it itself. IN_NAMECHG would then only have to distinguish whether the current task is an add or a change (which can actually be done e.g. via smurfs). However, multiple price lists are possible for a partner, so there is great complexity (if even possible) to have the program:
- displaying any existing and valid price lists
- making existing records editable and track those edits
- recognize that no records exist (during 'add partner') and a new one needs to be created
- differentiate edits to existing records and new additions
- in the case of an addition, create only one initial record, prevent further additions on subsequent 'Validate' actions.
As can be seen, the logic to implement a minor change is large due to the program design.
Recommendations for future redesign
Moved here.