Information Systems:IN-NAMECHG - Business Partners - Revision history

Norwinu at 21:37, 16 November 2017

2017-11-16T21:37:08Z

Norwinu at 21:29, 16 November 2017

2017-11-16T21:29:54Z

Norwinu at 21:29, 16 November 2017

2017-11-16T21:29:33Z

Norwinu: /* General flow of 'Add Partner' and limitations */

2017-11-16T21:27:22Z

General flow of 'Add Partner' and limitations

Norwinu at 20:21, 16 November 2017

2017-11-16T20:21:33Z

Norwinu: Created page with "Business Partners in Infonet consists of the following programs to display and manage uniPHARM business partners (customers, shareholders, suppliers etc.): * IN_NAMECHG.PGM *..."

2017-11-16T20:09:10Z

Created page with "Business Partners in Infonet consists of the following programs to display and manage uniPHARM business partners (customers, shareholders, suppliers etc.): * IN_NAMECHG.PGM *..."

New page

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)-[[User:Norwinu|norwizzle]] ([[User talk:Norwinu|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.

@@ Line 15: / Line 15: @@
 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
+* displaying any existing and valid price lists
- * making existing records editable and track those edits
+* making existing records editable and track those edits
- * recognize that no records exist (during 'add partner') and a new one needs to be created
+* recognize that no records exist (during 'add partner') and a new one needs to be created
- * differentiate edits to existing records and new additions
+* 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.
+* 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.

← Older revision		Revision as of 21:29, 16 November 2017
Line 26:		Line 26:

	Moved [[Information Systems: Infonet_Feedback_and_Recommendations \| here]].		Moved [[Information Systems: Infonet_Feedback_and_Recommendations \| here]].
		+
		+	[[Category: Infonet Programs]]

← Older revision		Revision as of 20:21, 16 November 2017
Line 15:		Line 15:
	==Recommendations for future redesign==		==Recommendations for future redesign==

		+	Moved [[Information Systems: Infonet_Feedback_and_Recommendations \| here]].
−	* 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.

@@ Line 6: / Line 6: @@
 * 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)-[[User:Norwinu|norwizzle]] ([[User talk:Norwinu|talk]])
+ 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)-[[User:Norwinu|norwizzle]] ([[User talk:Norwinu|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.