| # Document Authorization Overview Overview Database Change Management (DBCM) supports Document Authorization, using ION Workflow. Document Authorization is about approving or rejecting changes made to Business Objects, in a controlled way. If a user makes changes to a Business Object in ERP Enterprise, these changes must be submitted for approval. Only when these changes are approved, the Business Object may be processed further. Example A user changes a Sales Order object, by modifying header data, or by adding, changing, and/or removing lines. The user must submit the changes for approval. After approval, the Sales Order object can be processed further. Through DBCM, two versions of the same Business Object can exist during a certain time-frame: a checked-in version and a checked-out version. If a user changes a Business Object, automatically a checked-out version is created. This checked-out version is only visible in maintain sessions for that particular Business Object. The rest of the ERP system does not know this version. This checked-out version is a kind of scratch version. A user can change anything, but the changes will not become available to the rest of the system until the user submits the changes, and someone approves these changes. It is also possible to undo these changes, and revert back to the original version. Administrators can use the Checked-out Objects (ttocm9599m000) session to view the objects that are currently checked out, and to perform corrective actions in case of errors. See Procedures for checked-out objects and the session help. Modeling and Deploying Document Authorization To support Document Authorization for a Business Object, a Model must be defined using the Object Change Management modeling sessions (ttocm0101m000). A model defines for which user actions Document Authorization is supported. A model contains multiple object types. Per object type, this information is specified: Actions Table relations, if the object contains data from multiple tables Mappings Infor delivers a predefined model. You can copy this model and customize it to your needs. You can choose for which Business Objects you want to use Document Authorization, by specifying this in a Deployment. See Overall procedure. If the Model describes two Object Types A and B, and you use Document Authorization for Object Type A, DBCM will not create checked-out versions for instances of Object Type B. Instances of Object Type A are always checked-out. Depending on the active user actions in the Deployment, one of these events occurs when changes are submitted: To get approval, the LN application logic publishes a Workflow BOD to ION. The object is automatically checked in. Prerequisites To support Document Authorization, these prerequisites must be met: ION Workflow must be installed. The workflow definitions that are specified in the actions of the object types must exist in ION Workflow. The LN application must use the DAL2 concept. The DAL of the root table must implement these hooks: on.submit() This hook is executed when changes made are submitted for approval. on.recall() This hook is executed when the submit must be recalled. Both these hooks must publish a Workflow BOD to ION Workflow. The LN application must be adapted. See Application changes. Application changes To support Document Authorization, the application must be adapted. Once a Business Object is checked-out, no changes to any related Business Objects of another Object Type are allowed. Therefore the DAL may only update tables that belong to the Business Object itself. Only during checking-in, Business Objects of other Object Types may be updated. To support this, you must use the `dbcm.object.is.being.checked.in()` function. If a session can be used to change data of a Business Object for which Document Authorization must be supported, this session must specify the selected Object Type, so the portingset knows whether to include checked-out versions when selecting data from the database. For maintain sessions this is done automatically by the 4GL Engine, based on the main table. For update sessions, you must use these funtions to achieve this: `dbcm.select.object.type()` or `dbcm.select.object.instance`. The session must indicate the user action which is being performed. For example, if the user presses the Release to Warehousing button , and this supports Document Authorization, the application must indicate that this action is being performed by the application logic. DBCM can then determine whether this action requires approval. The 4GL Engine supports these standard actions via the User Interface: Inserting Updating Deleting Any other, application-specific, actions must be selected by the application using the `dbcm.select.object.action` function. Checked-out Business Object states This table shows the states a Business Object can have:
State | Description
Draft | The object is checked-out, it can be modified and any changes can be submitted. Any changes can be undone by performing a Revert to Approved in the User Interface.
Draft (Revision) | The object is in the Draft state, for a second time; this state is equal to the Draft state, except that an object can only enter this state after a Recall of any submitted changes was successful.
Pending | Any changes to the object have been submitted and the user must wait until the changes are Approved or Rejected. The object cannot be modified.
Recall Requested | The user made a request to ignore any submitted changes, because the user, for example, wants to make more changes to the object. The object cannot be modified.
Rejected | Any submitted changes to the object were not approved. The user must either make other changes and re-submit them, or perform a Revert to Approved. The object can be modified.
Approval Received | Usually this state will not be visible to the user. It can only be visible if somehow, after receiving an Approval, the object cannot be checked-in. In this situation an administrator must force a check-in, or discard any changes and perform a Revert to Approved. The object can be modified.
Approved | Any submitted changes to the object have been Approved, and the object has been checked-in. The object can be modified.
Related topics Importing the standard model Creating a model Deploying a model Procedures for checked-out objects |