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 the actual programming, 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.
Recommendations for future redesign
- Paginated 'add partner' form: It's common sense for long forms to be filled in sections/pages so that the data can be processed faster e.g. at each step. Currently, it is one huge, scrollable form, validated and submitted only at the end. Besides user convenience, this would actually lead to greater server-side efficiency of this program as the HTTP request is currently massive (with all that form data).
- Dynamic form input: Input data should be processed dynamically for smarter forms. For example, populating the Province field with Alberta should populate subsequent fields like price list with corresponding defaults. This process should also be used to validate many of the fields in real-time (upon typing or leaving the input field).
- Use of temporary tables:
- Prevents the problem as described in the previous section.
- Able to run logic on ALL form data prior to writing ANY information to tables.
- Able to have the user confirm all entered data prior to writing.
- Able to cancel and cleanup partially filled information. Currently, records are not deleted if the user cancels the process, leaving stale, blank entries in tables.
- Able to accommodate multiple users using the Add Partner form without having to 'grab first dibs' on a partner number by immediately writing a record.