1C:Enterprise 8.3. Developer Guide. Contents

BUSINESS PROCESSES AND TASKS

13.1. MAJOR CONCEPTS

Business processes in 1C:Enterprise are intended to combine separate operations into chains of interrelated actions, allowing specific goals to be attained. For example, the issuance of an invoice, acceptance of cash payment and shipment of goods from a warehouse can be combined into the Cash Sale of Goods business process.

The 1C:Enterprise business processes allow formalization of the procedure of processing various events of an organization's activities and assurance of performers' participation therein.

The use of business process mechanisms in applications makes them more effective, improves the final result and finds new opportunities.

Business processes allow for a switch to process-based management and qualitatively improve the enterprise's operation through re-engineering and automation of business processes.

Automation of key business processes that begin and end outside the organization is the most effective.

Chains of interrelated operations within a business process are presented in the business process flowchart. A flowchart describes the logic of the business process and its entire life cycle, from start to finish, in the form of a map of the passing sequence for interrelated points in the process.

This refers to a successive performance of a chain of interrelated operations as the business process progresses.

Route point reflects a stage in the life cycle of a business process, normally involving the performance of a single automatic or manual operation.

Tasks in 1C:Enterprise allow record keeping for assignments sorted by performers and reflect the progress of business processes to later points on the flowchart. In addition to business processes, tasks can be created by other infobase objects or directly by users.

13.2. GENERAL INFORMATION

The 1C:Enterprise business processes mechanism has several configurable objects:

Business processes

Tasks

Information register

Session parameter

As a rule, task addressing attributes and information register dimensions are of a reference type (e.g., CatalogRef which is why in addition to the above four types, there are also catalogs).

Fig. 276. Flowchart of Business Processes

Main objects – business processes and tasks – interact (e.g., a business process creates tasks and performance of a task results in progress in the business process).

Auxiliary objects – session parameters, information registers and catalogs – do not use each other or main objects.

When creating a business process flowchart, catalogs with predefined data (roles, departments, etc.) are used to assign values to the route points' addressing properties. Business processes create tasks when they reach further points of the flowchart and use Addressing (information register, see below) to process group points.

Upon completion of their performance, tasks notify business processes, thus further advancing them. They use the information register to select tasks for the current performer in compliance with session parameters.

13.3. ROUTING

The 1C:Enterprise business processes allow the use of the following routing types:

Hard. The business process has a strict flowchart, comprising no conditional or parallel jumps, with strictly defined recipients at each route point. This type involves no free or conditional routing.

Free. Recipients at different points of the business process flowchart are not preset. They are determined by software or interactively during the life cycle of the business process.

Conditional. The flowchart provides for a conditional test and progress along the corresponding branches. Jumps can be both binary (conditional) and multiple (switch).

Parallel. The flowchart provides for the splitting of the business process into parallel branches with subsequent joining (wait) possible. The business process progresses along each of the parallel branches separately as the tasks are performed.

In real business process flowcharts, all the above routing types are normally used.

13.4. ADDRESSING SYSTEM

The key concept in the 1C:Enterprise business processes and tasks mechanism is the addressing system. The addressing system is mainly designed to allow addressing business process participants not only personally, but also by roles.

Role-based addressing (routing) is a set of rules and conventions specified in metadata objects' settings which allow definition of the final recipient (performer) based on the assigned roles, subdivision membership and other addressing attributes.

Task addressing attributes determine the dimension of the address space as applied to the automated application domain. They are used to determine performers that own the tasks.

Specific performers are determined on the basis of the following task properties: Addressing, Main addressing attribute and Current performer.

The process for determining the key addressing attribute among all addressing attributes is referred to as dereferencing.

Addressing is a register of updated information, linking performers (the key addressing attribute) to departments, workgroups, functions, etc., i.e. all the other task addressing attributes.

One of the addressing attributes is the key attribute and it indicates a specific employee, the performer of the assignments.

Fig. 277. Flowchart of Addressing

The following example illustrates the operation of the addressing system.

Assume an information register comprises two dimensions, role and employee, with the following records:

Role	Employee
Cashier	Jones
Manager	Peters

At a certain point in a business process (e.g., Accept Cash Payment), addressing properties have only the Cashier role. When the business process reaches this point, a single task is generated:

Task Property	Value
Name	Accept cash payment
Role	Cashier
Employee	-

When employee Jones browses his task list, the addressing system displays this task, because the information register contains a record attributing the Cashier role to Jones. Employee Peters cannot see this task.

Here is an approximate sequence of operations for the creation of two different business processes.

1. Let us proceed from the assumption that the addressing system comprises three dimensions: employee, role and department.

2. Create catalogs for each of the planned addressing dimensions (Employees, Roles and Departments) and fill them in with predefined values, e.g.:

Employees	Roles	Departments
Jones	Cashier	Accounts Department
Peters	Manager	Sales Department
Smith	Head of Department Storeroom Clerk	Warehouse

3. Create an information register and add one dimension to it per the previously created catalog. Indicate the types for the dimensions as references to the corresponding catalogs, e.g.:

Dimension	Type
Employee	CatalogRef.Employees
Role	CatalogRef.Role
Department	CatalogRef.Departments

4. Create the CurrentPerformer session parameter and assign it the CatalogRef.Employees type.

5. Initialize the session parameter when starting the system, e.g.:

Procedure  SessionParametersSetting(RequiredParameters)

User = Catalogs.Employees.FindByDescription(UserName());
SessionParameters.CurrentPerformer = User;

EndProcedure

6. Create a task.

7. Set the previously created information register as a property of the Addressing task.

8. Add addressing attributes similar to dimensions of the information register:

○ Employee

○ Role

○ Department

9. Indicate the type of the task addressing attributes created in the form of a reference to the corresponding directory and set references to the information register dimension in the Addressing attributes property.

Addressing Attribute	Type	Addressing Dimension
Employee	CatalogRef.Employees	Employee
Role	CatalogRef.Role	Role
Department	CatalogRef.Departments	Department

10. Select the Employee attribute as the key addressing attribute by setting it in the corresponding task property.

11. Create the first business process with a reference to the previously created task (the Task property) within it.

Design a flowchart of the business process by setting the required addressing attributes for route points, selecting values from preset data in the corresponding catalogs.

Fig. 278. Business Process Map

12. Create the next business process with a reference to the same task.

13. Design a flowchart for the new business process. And so on.

This example is used below to comment on the key particularities of 1C:Enterprise business processes.

Let us discuss some of them in detail.

13.5. STARTING BUSINESS PROCESSES

A business process starts when you select the Start() method or click Start and ñlose in the object form.

The code fragment below is responsible for software creation, recording and startup of a business process.

BP  = BusinessProcesses.Match.CreateBusinessProcess();
BP.Date  = CurrentDate();
BP.Write();
BP.Start();

The following sequence of operations is performed during startup:

No	Internal mechanism	1C:Enterprise script handlers
1		BeforeStart handler invocation at the startup point
2	Jump to the point of action in compliance with the flowchart
3	Creation of tasks (see page 2-700)

A business process can be recorded without being starting. This option is useful if you would like the business process started later than it is created. For example, a business process can start upon occurrence of a certain event.

13.6. TASK PERFORMANCE

The ExecuteTask() method checks the performance process, then marks the task as performed and notifies the business process. If all conditions are met, the business process jumps to the next route point.

No	Internal mechanism	1C:Enterprise script handlers
1	Transaction start
2		Invocation of the task's BeforeExecute handler
3		Invocation of the BeforeExecute handler of the corresponding route point
4	The Completed task property is set to True
5		Invocation of the task's OnExecute handler
6	Task object recording
7		Invocation of the OnExecute handler of the corresponding route point
8	Business process jumps to the next route point
9	Task generation at the new route point (see page 2-700)
10	Transaction completion

13.7. SPLITTING AND JOINING

To split a business process into several branches performed in parallel (simultaneously and independently of each other), a splitting point is used. A splitting point has one input and an unlimited number of outputs.

To synchronize previously split branches, a join is used. A business process waits at the join until all its branches arrive. Thus, a join is a business process stage where all tasks involving the previously split branches must be completed.

Splitting and joining may be nested. If it is, each join synchronizes only the branches of its own splitting point.

IMPORTANT!

Splitting does not necessarily require joining. A business process may have several parallel branches up until its completion.

Joining is impossible without splitting. If this condition is not met, the system displays the following message when checking the flowchart: Some lines entering merge point do not leave branch point.

13.8. MANUAL CONTROL

Business process completion and task performance attributes can be assigned manually, overriding the business process mechanism. However, this should only be done if all consequences involved are known.

13.8.1. Business Process Completion Attribute

If the completion attribute is assigned, the business process will be regarded as complete, even though some of the tasks linked to it may not have been performed. When these tasks are performed, the business process will not progress.

The completion attribute can be assigned to non-started business processes as well. If it is, their startup will be impossible.

If the completion attribute is manually removed from a complete business process, tasks linked to it will remain performed. Thus, the business process will not be complete, but all its tasks will be performed. These business processes cannot be restarted because the system regards them as started (they have one or more tasks). This is why, when manually removing the completion attribute, performance attributes should also be removed from the appropriate tasks, so that the business process returns to the required route point.

13.8.2. Task Performance Attribute

If the performance attribute is manually assigned to a task, the business process does not jump to the next route point. In addition, the BeforeExecute() and OnExecute() task handlers and the corresponding route point handlers are not invoked.

Manual assignment of the performance attribute can stop the business process: it will not be complete, but neither will it be linked to any unperformed task.

Removal of the performance attribute from a task can create a parallel flow in an unfinished business process. Assume, for example, a business process is incomplete and has one performed task and one unperformed task. If the performance attribute is removed from the performed task, the business process will have two unperformed tasks. When performing each of them, the business process will progress from the point corresponding to the performed task. The business process will be considered complete when all tasks in both parallel branches have been performed.

If the performance attribute is removed from a task whose business process is already complete, the task is displayed on lists as unperformed, but its performance does not result in progress of the business process.

13.8.3. Task Removal

Removal of unperformed tasks can stop an incomplete business process. The business process will be unfinished, but all its tasks will be inactive (incomplete).

Tasks reflect the real flowchart of a business process. They show which points have been passed and which remain active (incomplete). That is why task removal can result in an incorrect and inconsistent display of passed and active points on the flowchart.

If all tasks of an incomplete business process are removed, the process will be assigned a non-started status.

13.8.4. Task Addition

If a new task is manually created for a complete business process, the latter remains complete and performance of the task does not result in its progress.

If a new task is manually created for a non-started business process, the latter starts and upon performance of the task it jumps to the next route point.

If a new task is created for a started and incomplete business process, the latter is divided into parallel branches.

13.9. CONDITIONAL JUMP

For conditional branching of business processes, conditional jump points are used. An important feature of these points is the conditional test handler, a mandatory element checked during flowchart verification before saving the business process. If the handler is missing, the system displays the following warning: Condition point does not have a "Condition Check" event handler.

This handler returns conditional test results that determine the selection of the next route point. If the result is True, the business process jumps to the Yes branch, otherwise it jumps to the No branch. The default value is False.

A sample conditional test handler is shown below:

Procedure  DiscountLimitationConditionCheck(BPRoutePoint, Result)
If GetDiscountForAccount() > GetStandardDiscount() Then
Result = True;
Else
Result = False;
EndIf;
EndProcedure

For a multiple selection, you can use several successive conditional jump points. Switch points, however, are easier to use.

13.10. SWITCH

To select one of the available paths, switch points are used. An important feature of these points is a switch handler, a mandatory element checked during flowchart verification before saving the business process. If the handler is missing, the system displays the following warning: Option selection point has no handler for event "SwitchData processor".

This handler assigns one of preset values to the Result property. A sample handler is shown below:

Procedure  Switch (SwitchPoint, Result)
If PaymentType = Enums.PaymentType.Cash Then
Result = SwitchPoint.Cases.Cash;
ElseIf PaymentType = Enums.PaymentType.Check Then
Result = SwitchPoint.Cases.Check;
ElseIf PaymentType = Enums.PaymentType.Netting Then
Result = SwitchPoint.Cases.Netting;
ElseIf PaymentType = Enums.PaymentType.Credit Then
Result = SwitchPoint.Cases.Credit;
EndIf;
EndProcedure

In this handler, PaymentType is a business process attribute.

An empty value of Result during the switch handler procedure results in an error and cancels the transaction involved in the switch.

13.11. TASK GENERATION

Tasks are only generated when a business process reaches a point of action or a point of a business subprocess. When passing other points (conditional jump, splitting, joining, processing, etc.), a business process automatically performs the required operations and jumps to the next point according to the flowchart.

To illustrate this, let us discuss the way a business process jumps to the first point of action when the Start() method is invoked.

When jumping to points of action or business subprocesses points within a flowchart, a business process can create one or more tasks. Several tasks are generated if the route point is marked as a group. In this case the business process selects all records complying with the addressing attributes assigned to this point by the information register (Addressing) and generates a task for each record.

For example, if a route point is only addressed by the Cashier role and the information register contains two type records, two tasks are generated with both addressing attributes – role and final performer.

Employee	Role	Department
Jones	Cashier
Peters	Cashier

Thus, for group points on flowcharts, role-based routing is used only once, when a task list is generated.

The sequence for invocation of event handlers in the 1C:Enterprise script when jumping to the first point of the Billing flowchart is illustrated below:

No	Internal mechanism	1C:Enterprise script handlers
1	Transaction start
2		BeforeCreateTasks() handler invocation
3	Task list generation
4		OnCreateTask() handler invocation
5	Recording all the generated tasks
6		The task's BeforeWrite() handler invocation
7	Task recording
8		The task's OnWrite() handler invocation
9	Transaction completion

At the second step, the BeforeCreateTasks() handler is called. This handler is invoked by the business process before the task list is generated. This is why it obtains an empty array of tasks generated and can generate them without standard processing.

At the third step, the business process checks whether the previous handler has returned StandardProcessing = True. If it has, the addressing attributes assigned to the route point are dereferenced and a task or task list (for group points) is generated, depending on the number of dereferencing results (e.g., number of employees in a department). Each task generated includes a description, a link to the business process, the route point and appropriate addressing attributes.

At the fourth step, the OnCreateTask() handler is called. This handler obtains the task list previously generated by the BeforeCreateTasks() handler or by the business process. The tasks have not yet been recorded. In this handler, the tasks generated can be fine-tuned: check time, priority and other additional attributes can be assigned. This handler also allows new tasks to be added to the array.

At the fifth stage, normal completion of the OnCreateTask() handler is checked. If the handler returns Cancel equal to True, task generation is terminated and an exception is raised. In this example, it cancels the Start() method execution. If Cancel = False, all tasks in the array generated are recorded with BeforeWrite() and OnWrite() handlers invoked for each task (steps 6 and 8 respectively).

When a business process generates a task array, the following attributes are assigned automatically:

Description identical to the description of the corresponding route point, e.g. Billing;

Reference to an instance of the business process that generated the task;

Reference to a point on the business process flowchart;

Task addressing attributes identical to the addressing attributes of the corresponding route point. For example, if the route point is addressed to the Cashier role, the task's Role addressing attribute is also assigned the Cashier value.

13.12. PERFORMANCE CHECK

Apart from users, automated procedures can handle task performance as well. For example, if a task envisages document posting, an automatic procedure controlling such tasks can check if the document has been posted and mark the task as performed by invoking the Execute() method.

Such automatic procedures are organized using the task's CheckExecution() method and the corresponding handlers of route points.

A code in the 1C:Enterprise script and the sequence of operations it invokes is illustrated below:

If  Task.CheckExecution() Then
Task.ExecuteTask();
EndIf
No      Internal  mechanism                            1C:Enterprise  script handlers
1      CheckExecution() method invo-  cation  processing
2      Invocation  of the task's CheckExecutionProcessing()  handler. If Result is False, the   CheckExecution() method immediately returns False
3      Invocation of the CheckExecutionProcessing() handler of the corresponding route point
4      Return of the handler invocation result from the previous step. If the  value is True, then the ExecuteTask() method is invoked

For a description of one of the methods to use automated task performance see page 2-705.

13.13. NESTED PROCESS EXECUTION

A flowchart can provide for business subprocess startup. In this case the main business process waits for the nested process to complete before it jumps to the next route point.

When jumping to a Subprocess route point, the following sequence of operations is performed:

No	Internal mechanism	1C:Enterprise script handlers
1	Transaction start
2		BeforeCreateSubBusinessProcesses()
3		Invocation of the BeforeCreateTasks() handler for the route point
4	If StandardProcessing, then a task array is generated
5	OnCreateTask()
6	Recording of previously generated task array and creation of a business subprocess array
7	OnCreateSubBusinessProcesses()
8	Recording and startup of business processes generated
9	Transaction completion

Let us discuss this sequence in detail.

At the second step, the BeforeCreateSubBusinessProcesses() handler is called. It can be used to add custom business processes to the array of generated business processes (by default, an empty array is passed to the handler). If business processes have been added to the array, standard generation of business processes is not used.

At the third step, the BeforeCreateTasks() handler is called. An empty, nongenerated task array is passed to the handler. If the handler does not modify the standard processing, the task array it generates is cleared at the third step and filled in with a single task with the preset description and references to a business process and a route point.

At the fifth step, settings of the generated tasks can be adjusted and new tasks can be added, if necessary.

At the sixth step, the generated tasks are recorded, then a business subprocess of the type specified at the route point is created for each task. The date is specified in the new business processes and a reference to the head task is added.

At the seventh step, the OnCreateSubBusinessProcesses() handler is called. This event handler can adjust auto-generated business-processes (their number is the same as the task number after the OnCreateTask() handler) or delete some of them, as well as add new business-processes to them. The list of business processes is recorded after handler completion.

13.14. BUSINESS PROCESS COMPLETION

Completion is the last stage in the life cycle of a business process. A business process is automatically completed (Completed is set equal to True) when it reaches the point of completion, provided there are no unperformed tasks linked to this business process.

If the Head task property is enabled for the business process, meaning it is nested, when it is completed, it marks the task as performed. As a result, the main business process progresses.

When jumping to the point of completion, the OnComplete() handler is invoked. If Cancel is set equal to True, for example, if any of the business process completion conditions have not been met, processing is terminated. The task at the route point whose performance resulted in the jump to the point of completion remains unperformed.

Completed can be set equal to True (using the 1C:Enterprise script tools or in the interactive mode) in order to terminate the business process or remove it from the list of active (unfinished) business processes. In this case no handlers apart from BeforeWrite and OnWrite are invoked. The head task is not performed.

13.15. STANDARD BUSINESS PROCESS AND TASK ATTRIBUTES

The tables below list predefined fields of business processes and tasks.

The following business process attributes are standard:

Attribute	Type
DeletionMark	Boolean
Number	String or Number
Date	Date
Completed	Boolean
HeadTask	TaskRef.<Task name>
Ref	BusinessProcessRef.<Business process name>

The following task attributes are standard:

Attribute	Type
DeletionMark	Boolean
Number	String or Number
Date	Date
Description	String
Completed	Boolean
BusinessProcess	BusinessProcessRef.<Business process name>
RoutePoint	BusinessProcessRef.<Business process name>
Ref	TaskRef.<Task name>

13.16. BUSINESS PROCESSES WITH SEVERAL STARTING POINTS

The availability of several starting points implies that the selection of a starting point depends on conditions external to the business process.

If a business process has all information it needs to decide which route to choose, a single starting point, followed by a condition check or switch, is sufficient.

If the business process has several starting points, one of them should be specified when invoking the Start() method, otherwise the system displays an error message. This is why the following should be done when creating a business process with several starting points:

Define interactive start commands that select the appropriate starting point for each particular case of business process start.

If the business process is nested, the OnCreateSubBusinessProcesses() handler should be added to the appropriate route points so that all business processes from the array of generated business processes are recorded and started at the correct point.

Example:

Procedure  NestedMatchOnCreateNestedBP(BPRoutePoint, ProcessesBeingFormed, Cancel)

For each BusinessProcess from ProcessesBeingFormed Do

BusinessProcess.Write();
Points = BusinessProcesses.DocumentMatch.RoutePoints;
BusinessProcess.Start(Points.SimplifiedMatch);

EndDo
EndProcedure

In other respects, business processes with several starting points are used in precisely the same way normal business processes are used.

13.17. FEEDBACK

Other infobase objects (documents or catalog items) can be involved in business processes and influence them.

For the business process mechanism to be effective, some tasks should be performed automatically in response to corresponding operations with other infobase objects (e.g., when a document is posted, a discount is granted on an invoice, goods in stock are inventoried, etc.).

An important feature of the 1C:Enterprise business process mechanism is the fact that it does not require a substantial modification of the applications used. This is why response of business processes and tasks to modification of other infobase objects is adjustable without substantially modifying the objects.

The following example illustrates the above concept. Assume a task requires document posting. When the document is posted, the task has to be performed automatically, so that the user does not have to open the task list, search for the task and execute it.

To achieve this, perform the following sequence of operations:

Add a posting notification to the document form:

Procedure  AfterWrite(Cancel)

If Posted Then

Notify("DocumentPosting", , ThisObject.Ref);
EndIf;
EndProcedure

AttachNotificationHandler("NotificationHandler");

Invoke a method (e.g., WorkWithBusinessProcesses) of the server-side common module from the notification handler and use it to run the required checks and execute the task:

//  Notification handler in the managed application module
Procedure  NotificationHandler(EventName, Parameter, Source)
Export
If EventName = "DocumentPosting" Then

WorkWithBusinessProcesses.ExecuteTaskForDocument(Source);
EndIf;
EndProcedure

...

&AtServer
//  The WorkWithBusinessProcesses method of the server-side common module
Procedure  ExecuteTaskForDocument(DocumentRef) Export

Query = New Query;
Query.SetParameter("Param", DocumentRef);
Query.Text=
"SELECT
|Ref
|FROM
|Task.Task.TasksByExecutive
|
|WHERE
|Document  = &Param";
Selection = Query.Execute().Select();
While Selection.Next() Do

CurrentTask = Selection.Ref.GetObject();
If CurrentTask.CheckExecution() Then

CurrentTask.ExecuteTask();

EndIf;
EndDo;
EndProcedure

Another way to have tasks performed automatically is to create and enable a notification handler that will select all tasks linked to a performer, check if they should be performed and, if so, automatically perform them.

In the sections below, we will discuss the particularities of business process and task object configuration.

13.18. FLOWCHART

A flowchart describes the logic of the business process and its entire life cycle, from start to finish, in the form of a map of the passing sequence for interrelated points in the process.

To edit a flowchart, go to the Other tab in the business process editing window and click Route map (for details see page 2-1006).

13.19. BUSINESS PROCESS EDITING

Any number of business processes can be created at the configuration stage. The purpose of each business process defines its structure and properties specified in the configuration.

The Designer allows a business process structure to be described and forms and a flowchart of the business process to be created.

Business process properties can be edited in the properties palette or the object editing window (see page 1-59).

Besides the general properties that all metadata objects have, business processes also have a number of specific properties.

The Tasks property sets a reference to a previously configured task object. A task already existing in the configuration must be assigned to each business process. Business processes use tasks to generate jobs by performers and to start business subprocesses. If no task is assigned, when an attempt is made to save the database configuration, the system displays the following error message: Business process task not selected.

Autonumbering. When this property is selected, new business processes are numbered automatically. An automatically assigned number can be corrected.

Number length. This property defines the maximum length of a business process number. The Designer allows this length to be set to 0 if numbers are not used in this type of business process.

Number type. This property allows to select a value type for the business process number, Number or String. It is similar to the document Number format property.

The string type is useful when a sophisticated numbering system is used and the document number contains not only digits, but also letters and delimiters.

Check uniqueness. If this property is selected, when a new business process is added, the uniqueness of its number is checked within the limits set in the Periodicity property.

Periodicity. This property defines the scope of document number uniqueness verification and the number recycling period. If Check uniqueness is selected, then Periodicity defines the limits of control.

If Autonumbering is selected, 1C:Enterprise assigns the next consecutive number to each new business process. Upon completion of the cycle defined in Periodicity, business process numbering restarts from 1.

The Rights tab can be used to set a privileged mode for task creation (the Privileged mode for task creation property):

If this property is set, the system always generates tasks in the privileged mode (at the server side and in file mode version). However, the privileged mode is not set if tasks are generated in the client/server mode at the thick client side.

When new business processes are created, this property is set to True if the managed application mode is selected as the main run mode in the configuration properties; otherwise if the ordinary application mode is selected, the property is set to False.

In addition to the main attributes, a set of attributes storing additional information can be created.

If the application domain object to which the business process corresponds has both basic properties, such as date, number, importance and check time and complex (list) properties, such as a list of documents submitted for approval, a list of resolutions or a list of business process participants, a set of tabular sections can be created for the business process.

13.20. TASK EDITING

Tasks-type objects are designed to distribute assignments among system users and to have them performed. Assignments can be generated by both users and business processes.

Tasks can be used on their own or support business processes of different types.

Configuration allows creation of any number of task types. However, one task is normally created for all types of business processes.

The task structure and properties described in the configuration depend on specifics of the application domain being automated.

You can create multiple list, selection, view and editing forms for each task.

Each task is characterized by its number, date, time and description. When a task is generated by a business process, it is assigned the description of the corresponding point on the business process flowchart.

Task properties can be edited in the properties palette or the object editing window (see page 1-59).

In addition to the general properties that all metadata objects have, tasks also have a number of specific properties.

Addressing. A task can be assigned a non-periodical information register whose dimensions can be linked with task addressing attributes. The links are used to define the value of the main task addressing attribute based on the data stored in the corresponding information register. Therefore, task addressing can be both performer-specific and role-based.

Main addressing attribute. One of the task addressing attributes can be declared as main. In this case this is the addressing attribute that points to a specific performer. If no performer is specified, the value of this attribute is determined on the basis of the information register linked to this task (see the Addressing property).

Current performer. Here, a link can be added to the session parameter where the current performer is stored. This property is used, for example, as the default value for the Performer property of the task list table box.

Autoprefix. It can be set to None and Business process number. If this property is set to Business process number, a new task number is automatically appended with the number of the corresponding business process.

A group of subordinate objects, Addressing attributes, defines a set of attributes that determine the type and dimension of the addressing system for this type of tasks, as used for the application domain being automated. One of these attributes can be declared as main (see the Main addressing attribute property). The addressing attributes can be linked to the information register's dimensions. The system uses these links to determine the value of the main addressing attribute if it is not specified. Links enable both direct and role-based addressing. Number length. This property determines the maximum length of a task number.

Number type. This property allows selection of a value type for the task number, Number or String. The string type is useful when a sophisticated numbering system is used and the document number contains not only digits, but also letters and delimiters.

Check uniqueness. If this property is selected, when a new task is added, the uniqueness of its number is checked.

Autonumbering. Check this property if you want a number to be assigned automatically to the task at its creation. An automatically assigned number can be corrected.

If the application domain object to which the task corresponds has both basic properties, such as date, number, importance and check time and complex (list) properties, such as a list of documents submitted for approval, a set of tabular sections can be created.

1C:Enterprise 8.3. Developer Guide. Chapter 13. Business Processes and Tasks