Show TOC

Function documentationWork Status Setup Locate this document in the navigation structure

 

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.

Prerequisites

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.

Features

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.

Activities

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   Work Status   Add a new work state  .

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.