This function allows you to lock a region (or slice) of data in an application. The work status setting overrides a user's member access privileges to write to a given region. A region of data is defined by three to five dimensions per application, one with a property called Owner.
When you set up work status, you define the following:
Work States – The codes that refer to a physical state of data (such as Submitted)
Level of security – The users or teams who can change data in the system, which is All, Locked (no one), Manager, or Owner. See Controlling Who Can Change Data, below.
The users or teams who can change the work state, which is Owner, Manager, or Both. See Controlling Who Can Set Work Status, below.
Method of data update – The manner in which the customer updates data. See Method of Update, below.
Push – Equivalent to the check box Include all children when setting work states, the option allows you to set one work status code to all children of a member (this does not set the selected parent member, in the NetWeaver version).
After you set up work states, users can use them to apply a label to a current view and lock its data for review, approval, and so on. For example, your month-end close business process requires that a specific set of data is locked down so that accurate month-end reports can be created. After a data submission, the owner sets the work state to Submitted. This locks the data intersection from subsequent submissions.
To use this function, you must specify in the Base Hierarchy column of the work status dimensions the hierarchy (H1, H2, H3, ..., Hn) that uses work status rules. See Setup of Work Status Dimensions.
To implement e-mail notification of work status changes in the Microsoft version of Planning and Consolidation, the application set parameters APPROVALSTATUSMAIL, APPROVALSTATUSMSG, SMTPAUTH, SMTPPASSWORD, SMTPPORT, SMTPSERVER, and SMTPUSER must be set up. To implement e-mail notification of work status changes in the NetWeaver version, the application set parameters APPROVALSTATUSMAIL and APPROVALSTATUSMSG, as well as the ABAP SMTP service, must be set up. For more information about these application set parameters, see Application Set Parameters.
Controlling Who Can Change Data
You define who can change the data in the system:
All — All users with the appropriate member access rights can change data
Locked — No one can change the data
Manager — Only managers (parents of owners) can change data
Owner — Only owners can change data
Controlling Who Can Set Work Status
You define who can set the set the work state for a region of data:
Both — The owner of the specific member ID and the owner of the parent to the specific member ID
Owner — The owner of the specific member ID
Manager — The owner of the parent to the specific member ID
Owner / Manager Determination:
Parent member owners act as an owner for that specific parent member ID
Parent member owners act as a manager for their direct children – the parent owner can change any specific direct child work state; can be both parent and base members
When using Include all children – the owner of a parent can update all children (all levels) below
Base (leaf) members owners act as owner only
Members (top of a hierarchy) that have no parent but have children act as their own manager in addition to owner
Controlled By Rule
An owner is defined by only one dimension hierarchy, the OWNER dimension
A work state can be set on a specific single member ID, where the manager does not use Include All Children
A work state can be set on a series of member IDs, where the manager uses Include All Children
Setting the Work State:
If the user is acting as an owner, they can select a work status controlled by Owner or Both
If the user is acting as an owner and the selected member has no parent, the user also acts as a manager (top of the hierarchy) and they can select a work status controlled by Owner, Manager or Both
If the user is the parent owner in the role of Manager, then they can use the Include All Children option (to push the work state to children). This option is not valid for a base member, the Owner role.
Consecutive Work State Rules
You can set work status in a forward direction (progressive) or in a backward direction (regressive)
For a user acting as an Owner, the order matters
The user can only select the next (forward) work state that is controlled by either Owner or Both
The user can select the previous (backward) work state that is controlled by either Owner or Both
The user cannot select a work state that skips a work state controlled by Manager, either forward or backward
For a user acting as a Manager, the order does not matter
The user can only select a work state that is controlled by either Manager or Both, either forward or backward
The user can select a work state that skips a work state controlled by Owner, either forward or backward
If you expand all records on the non-OWNER dimensions only, and find the current work state on each record, the application checks each and every expanded record for the rules. If one record fails, the whole request is ignored
Bottom-Up Rule
A parent work state cannot be higher than its children (order matters)
The order of work states is determined top to bottom in the work status code screen. The first code is 0, the next code is 1, and so on.
A child can have a work state that is greater than or equal to its parent
For a user acting as owner:
If a child is set to Submit, it parent cannot be set to Approve.
If one or more children have a work state that is lower than the work state being set for a parent (forward), then an error appears
If the parent's work state has a higher work state, an error appears if you attempt to regress a child's work state (backward)
The rules above also apply when the user is acting as a Manager (where Include All Children is selected or the Manager sets a specific child work state)
For all expanded records (non-OWNER dimensions), the immediate parent is checked to verify that it has a work state that is less than or equal to its children. If one child fails this rule, all fail.
Method of Update
The areas of Planning and Consolidation for which you can control the level of security are as follows:
Data Manager (DM) — Controls data input from running a Copy, Import, or Move package
Journals (JRN) — Controls data input from posting journal entries
Interface for the Web (MAN) — Controls data submissions from Live Reporting
Interface for Office (MAN) — Controls data submissions from reports and input schedules
Comments (COM) — Controls data input from posting comments (unstructured data)
Documents (DOCS) — Controls posting documents with application context to the Content Library (unstructured data)
Defining Work States
Work states (or work state “codes”) are defined for the entire application set (not per application). There is no limit to the number of codes you can create, but there is a practical limit.
For the NetWeaver version only, there is a default work state that must be first and cannot be changed. It has an internal code of 0 and is controlled by the Manager and Owner (Controlledby is set to Both). You can change the method of update for this code, but not the order or the Controlledby value. You can change the text description.
The default code allows you to have a customized behavior for the application set. For example:
LOCKED for all methods is equivalent to preventing any data update until the work status is advanced to the next state (1)
ALL for all methods is equivalent to having all data open for update – this is the current and default behavior
SETUP applies to ALL of the applications in the application set
WRITEBACK always checks for locks; if there are no locks in the lock table, the system behaves based on the setup of state (0)
Work state codes must be 20 characters or less, and their descriptions are limited to 40 characters (this is the same as a member ID).
You can change the order of work status, but once you change it, the system deletes all locks for all applications in the application set. Deleting codes also deletes all locks. Adding codes to the bottom of the list, changing a code definition, does not impact existing locks, but may impact business users. We recommend this only during the testing phase.
For information about how to set up work status dimensions, see Setup of Work Status Dimensions.
Work Status Rules
The following rules describe work status behavior:
The default method for managing work status is bottom-up. That is, the status of a parent cannot be higher than the status of its children. (NetWeaver does not support top-down)
The maximum state a parent can be set to is the lowest state of its immediate children.
If the status of a parent is set to Locked, you cannot unlock the children.
The minimum state a child can be set to is the state of its immediate parent. For example, if the parent state is Submitted, the child state must be at least Submitted.
The owner of an entity can set the work state to any state designated as an Owner state.
The manager of an entity can set the work state to any state designated as a Manager state.
A manager is the owner of a parent-level member. The owner of a parent level member is the manager of all its descendants.
When setting a lock on the parent members of multiple dimensions, locks are set for all members under all parents (specifically, the Cartesian product is stored as locked). For example, the following table shows the locks that are set when including all children for entity:p1
, category:actual
and time
2009.Q1
.
Entity |
Category |
Time |
Work State |
Child1 |
Actual |
2009.Jan |
Upload |
Child2 |
Actual |
2009.Jan |
Upload |
Child1 |
Actual |
2009.Feb |
Upload |
Child2 |
Actual |
2009.Feb |
Upload |
Child1 |
Actual |
2009.Mar |
Upload |
Child2 |
Actual |
2009.Mar |
Upload |
If you reorder work state codes in the Admin client, all locks are deleted. This also applies deleting a work state.
A parent value for a non-OWNER dimension is not stored. When the user selects a parent for a non-OWNER dimension, it is expanded to all base members, and only stores the base members.
A parent value for the OWNER dimension is stored. For example, the following table shows what is stored for entity:p1
, category:actual
and time 2009.Q1
.
Entity |
Category |
Time |
Work State |
P1 |
Actual |
2009.Jan |
Upload |
P1 |
Actual |
2009.Feb |
Upload |
P1 |
Actual |
2009.Mar |
Upload |
When applying rules, if the application encounters any error, it rejects the entire user request. In this case, no records are updated.
Sending E-mails to the Owners and Managers
The system can send an e-mail message to owners and managers of a current view intersection for which a work status and ownership dimension have been set up to notify them when a change occurs in the work status.
Work Status Validation (Microsoft version only)
To use work status validation, you must set up a validation account in the Admin console. See the WORKSTATUSVALIDATE application parameter in Application Parameters and Setup of Work Status Dimensions.
Using Business Rules with Work Status Settings (Microsoft version only — may apply to NW too)
In the Microsoft version of the system, the system checks the work status setting before running the following business rules:
Account transformation (SpRunCalcAccount)
Currency Conversion (SpRunConversion, SpRunConversion_Light)
Intercompany Booking (SpICData, SpICBooking)
Automatic Adjustment (SpRunConso)
Carry-forward (SpCopyOpening)
US Elimination (SpRunElim)
Validation rules (SpRunValid)
Summary (SpCopyCategory)
Deleting Work States
You can delete a work status that is not currently in use by accessing Work Status Tasks and choosing Delete a new work state.
You create work states to reflect the status of data as it moves through your business processes, such as unlocked, submitted, and approved. No predefined work states exist within Planning and Consolidation. From the Admin Console, chose
.You can modify the order in which work states display in the system by choosing Work Status within the Admin Console, then in the Work Status Tasks action pane choosing Reorder work states.
To set up the system to send an e-mail message to owners and managers when a work status changes, set the application set parameter APPROVALSTATUSMAIL to Yes. To customize the content of the e-mail, modify the application set parameter APPROVALSTATUSMSG. For detailed information about these application set parameters, see the prerequisites detailed above and Application Set Parameters.