The user explicitly saves changes by invoking "File--> Save" from the menu, or by pressing the "Save" button on the toolbar.
Note: When the user selects a form to open from the Navigator, it is invoked in a separate database session and commit cycle. Thus, the Save action only applies to the current form from which it is applied.
Other methods of saving changes are described in the remainder of this section.
This function allows a user to save changes on the current set of records, then place the form in a mode ready to start the next transaction. Depending on the form, this may cause any of the following after the data itself is saved:
The form returns to the exact state it was when first invoked.
Navigation proceeds to the next master record currently queried.
A Find window appears if there are no more records left and if the Find window appears when the form is first entered.
A "Save and Proceed" textual button may be coded in modal windows that need the functionality.
This function is enabled when a form is opened by using the Processes tab in the Navigator. When selected, it saves any changes in the current form, closes it, and advances the current workflow process to the next sequential node.
Several types of actions require that data be saved to the database in order for the actions to be performed, or the action logically saves the changes automatically.
(OMS-76047) The user should be prompted to save changes if any are pending when an action either requires data to be saved before it can be processed, or does a save itself. If the user decides not to save, then the action is terminated.
An action may save automatically before or after it is completed if it is reasonable to assume the user expects that behavior. For example, if the user invokes the "Update Order Pricing" action, then it is reasonable to assume that they want to save that transaction upon completion. Furthermore, such an action may mimic the "Save and Proceed" function if that is the expected, and most useful, behavior of that action.
An application may save automatically as the user moves between records, but this should be avoided unless it is reasonable (that is, the user would be annoyed by having to perform the Save themselves in complex master-detail forms).
(OMS-76048) Often it is unusual to think of "saving" certain types of data, such as the parameters entered to run a report. In those cases, provide a button which replicates the save action, but is labeled consistently with the intent of the form. The "Save" entries on the menu and toolbar would, of course, perform the exact same function as the button.
Examples are:
"Submit" button on the "Submit Requests" form
"Import" button on the "Import Requisitions" form
"Transfer" button on the "Transfer Items" form