Patent Application
20070226210
1. Field
Embodiments of the invention relate to transaction processing. More specifically, embodiments of the invention relate to maintaining and supplying required values automatically.
2. Background
In the context of transaction processing, various mandatory values are often reused in many cases requiring reentry of the value by a user. This reentry is both inconvenient and can lead to data entry errors. Often these features never change or change very infrequently. To address these issues, some systems use variants. Variants are associated with selection screens in a particular program and display a set of input fields for database specific and program specific selections. A user can fill the input fields of the variant and subsequently need not reenter the supplied values at those selection screens. While variants are useful in that they eliminate the need to continually reenter identical values for the selection screen, they fail to make values available elsewhere in the transaction. Additionally, variants are not created on a per user basis. Accordingly, it is not possible to create defaults that can be applied on a per user basis throughout a transaction using variants.
A method and system for maintaining and supplying user defaults during transactions is disclosed. Upon initiation of a transaction, a determination is made if any mandatory values have been previously maintained. A window to accept mandatory values is generated only if either the mandatory values are not maintained or if an explicit request to change maintained values is received. Values supplied in the window are verified to determine that they satisfy requirements of the expected values. If the verification fails, the transaction is prevented from continuing. Otherwise, the supplied values are maintained in persistent storage. Those values are then made available elsewhere in the transaction without requiring reentry.
The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one.
If the transaction accepts automatic user defaults, a determination is made at block 106 whether any mandatory parameters have been configured for this transaction. For example, warehouse management transactions may have warehouse number as a mandatory parameter. A physical inventory transaction may have warehouse number and year as mandatory parameters. Numerous other possible examples exist. If no mandatory parameter are configured, the transaction continues at block 122.
If some parameters for the transaction are configured as mandatory, a determination is made at block 108 if the mandatory parameters have already been maintained by the user initiating the transaction. If the parameters have not been maintained, a pop up window is generated to accept the mandatory values at block 110. Once a user provides values via the pop up window, a determination is made at block 112 if the values satisfy the requirements of the expected values. In one embodiment, this verification may constitute merely a semantic check to make sure that the value provided is of the right type, e.g., character, integer, string, etc., or format, e.g., correct length, etc. In another embodiment, satisfaction of the requirements is determined by a strict comparison between the value entered and a subset of the possible acceptable values until a match is found.
If the values provided fail to satisfy the requirements for the expected mandatory values (either semantically or alternatively exact matching), the transaction is prevented from continuing at block 114. In one embodiment, preventing continuation is effected by maintaining the pop up window as the focal window until either acceptable values are provided or the transaction is cancelled. In some embodiment, an error message may also be presented to the user identifying what values have failed to satisfy the requirements and possibly why the requirements are not satisfied, e.g., “numeric value expected.”
If the values are determined to satisfy the requirements at block 112, the values are maintained in persistent storage at block 116. In one embodiment, the values may be maintained in the database. In another embodiment, they may be maintained in a file system. In one embodiment, the values are maintained in the database in a database table having the user identification as a key into the database table. This permits the defaults to be maintained on a per user basis and to be valid at any point within the transaction. As such, the variant requirement of association with a selection screen and the inability to create per user defaults are eliminated.
In some embodiments, the defaults can be maintained across different transaction types, as well as different transactions. In such an embodiment, the e.g., database table, may include flags indicating the transactions for which the maintained values are valid. Other ways of identifying the transactions for which the maintained values are valid are also within the scope and configuration of the invention.
At block 118, the transaction is allowed to continue. If at decision block 108 the parameters were already maintained, the transaction similarly continues at block 118. In this manner, the pop up window only occurs once on the first run of the transaction or, in the event that the user seeks to change the default values an asynchronous change event received at block 130 will trigger the generation of a pop up window at block 110 to permit the values to be changed. In one embodiment, the asynchronous change event may be the key stroke or key sequence entered by a user, for example the F4 key. In this way, the user can easily change the maintained values at any time. The underlying system insures proper notification to all interested parties once a change occurs. At block 120, the maintained values are automatically supplied to the transaction as needed.
Persistent storage 208 may be, in one embodiment, a database, such as a SQL database widely available in the industry. In another embodiment, persistent storage may be a file system for the execution environment. Persistent storage 208 may maintain a database table 230 holding previously maintained values indexed by a user identifier. Persistent 208 may also include a data structure 232 holding acceptable values for one or more of the mandatory parameters that may be maintained.
A user input device 216 is coupled to the execution environment 212. In one embodiment, user input device 216 may be a keyboard that may be used to send a change event to the execution environment 202. Alternative user input devices such as, pointing devices, audio interfaces, etc., may be used. Listener 213 listens for the change event and invokes the pop up module 212 responsive to receipt of a change event.
A display 218 is also coupled via the execution environment 202 and may display a graphical user interface of transaction window 236 having a plurality of fields 238 to receive values pertinent to the transaction. Upon entry of the first occurrence of the transaction invoked by the user or responsive to receipt of the change event in execution environment 202, pop up module 212 causes the generation of pop up window 240 within display 218. In one embodiment, pop up window 240 remains the focal window within the user interface until acceptable values have been provided for all mandatory values 242 or the transaction has been cancelled. By focal window, it is meant: the topmost window in the display and the only window in which actions can be taken.
In this example, mandatory values 242 are denoted by an asterisk and optional values 244 may also be present. Thus, the user may elect to maintain both mandatory and optional values, but is required to supply mandatory values. In this example, warehouse, number and country are designated as a mandatory values 242 and time zone is designated as an optional value 244. It should be recognized that these are merely examples of mandatory and optional values, more, fewer, and different mandatory/optional values are within the discretion of the developer of the underlying application that performs the transaction.
Also provided are soft buttons 248 to cancel the transaction and 246 to maintain the value entered. In one embodiment, responsive to actuation of the OK soft button 246, verification module 214 performs it verification whether it be semantically checking each of the mandatory fields to insure that they follow the correct semantics or performing an actual comparison between the acceptable values 232 both particular mandatory field and value entered using comparator 222. In an alternative, embodiment verification of a field value occurs when a user attempts to exit the field. In some embodiments, pop up module may generate a pop up window with e.g., pull down menus associated one or more mandatory fields. In such an embodiment, selection from the menu provides implicit verification that the value meets requirements. In some embodiments, the menus are populated at run time from the acceptable values data structure 232 in the persistent store 208. If the mandatory values are deemed acceptable from explicit on implicit verification, they can then be maintained in the database table 230. Pop up window will then vanish and the transaction window with the maintained values filled in again becomes the focal window. The maintained values are available for use down stream within the transaction as well as subsequent transactions of the same type. Because the pop up window does not recur smoother transaction processing is possible. In some embodiments, the maintained values can also be used for other transaction types. From the perspective of the transaction developer, the validity of the values is assured without requesting verification each time a value is used within a transaction.
While embodiments of the invention are discussed above in the context of flow diagrams reflecting a particular linear order, this is for convenience only. In some cases, various operations may be performed in a different order than shown or various operations may occur in parallel. It should also be recognized that some operations described with respect to one embodiment may be advantageously incorporated into another embodiment. Such incorporation is expressly contemplated.
Elements of embodiments may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, flash memory, optical disks, CD-ROMs, DVD ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, propagation media or other type of machine-readable media suitable for storing electronic instructions. For example, embodiments of the invention may be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
It should be appreciated that reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Therefore, it is emphasized and should be appreciated that two or more references to “an embodiment” or “one embodiment” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the invention.
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
