In the process of 1C:Enterprise operation it is required to solve various tasks related to its administration, including:
User list maintenance
Granting user rights
Creating a technological log to analyze errors, etc.
The Designer contains administration tools intended to solve the tasks above.
For example, 1C:Enterprise supports building a list of users authorized to work with the system. This list will be used to authorize a user when logging into the system. Please, note that the list of 1C:Enterprise users is not a part of a configuration: it is created independently in a particular company that uses the software.
A password can be set for each user to log into the system. The password is used to verify the user's rights to work with 1C:Enterprise.
Backup is another important administrative task. You have to run this procedure periodically to be able to restore the source data with minimal losses in case of database corruption. The backup frequency should depend on the intensiveness of data changes. The more frequently data changes occur, the shorter the period between two backups should be.
This chapter covers 1C:Enterprise administration tasks that can be carried out in the Designer.
Use Administration – Users to open user list.
Fig. 38. User List
The user list window consists of a toolbar and a table box with two columns:
The Name column lists the users that are registered in the 1C:Enterprise 8.
The Full name column can contain the full version of the name displayed in the first column.
Users with an access password are identified by lock icons (user Storekeeper in the fig. 38).
The users without any role or authentication are identified by question icons (user Sales manager in the fig. 38).
Use the Actions menu to maintain the user list, customize list view (column selection, content, sorting order) and to save the user list as a spreadsheet or text document.
Use the Actions – Add command in the User list window to add a new user. The user parameters editing window will open.
Use the Main tab to specify the user name and full name.
Fig. 39. New User
We recommend not including ":" in the user name. The uniqueness of the infobase user guaranteed through a combination of values in three separate fields: Name, Full Name and operating system User (if the OS tools authentication is enabled). The uniqueness is supported as follows: on the basis of the first 64 characters in the Name field, on the basis of the first 128 characters in the Full Name field, and on the basis of the first 128 characters in the operating system User field. We is recommend that you do not to exceed the 64-character length of the Name field.
It's advisable to assign meaningful user names, using users' last name, position, job functions, etc. This name will be used by the employees to log in 1C:Enterprise.
You should specify the authentication method for the new user. You can choose between 1C:Enterprise and OS authentication tools. For more information on types of authentication supported by 1C:Enterprise, see page 102.
The client application run under Linux does not support operating system authentication.
Each of the authentication check boxes (1C:Enterprise Authentication, Operating system authentication, OpenID authentication) defines the authentication method for a given user. These check boxes do not affect the authentication-attempt order. When assigning the authentication type, take into account the following aspects:
If all authentication boxes are unchecked, that user is denied access to the applied solution.
To perform a successful authentication by using the OpenID protocol, set up this infobase publication on the web server accordingly (see page 167).
The user will be denied access to the applied solution if he/she is authenticated using OS tools or OpenID, but the checkbox that permits that authentication type is unchecked.
The authentication attempt via OS tools or OpenID can be disabled using the relevant keys of the client application startup string.
At least one user should exist in the system possessing administrator rights with 1C:Enterprise authentication enabled for this user.
If User cannot change password is checked, this user will be unable to edit their own password (this checkbox is used when 1C:Enterprise authentication is enabled).
If Show in List is checked, this user will be displayed in the selection list when connecting to 1C:Enterprise infobase. If 1C:Enterprise authentication is disabled for a user, the Show in List checkbox will not be available to toggle and the user will not be displayed in the selection list when connecting to the infobase.
Use the Other tab to specify available roles and language. If there are multiple roles in the configuration, you can assign multiple roles to a user. Besides, 1C:Enterprise operation mode can be specified for a user. If Auto is used as a value, the default operation mode specified in the Default run mode configuration property will be used. You can specify specific operation modes when some users need to use a specific mode. For example, it may be needed when some user works in the managed application mode. In this case you should specify Managed application in the Run mode field.
Fig. 40. Other Options for a New User
It's not necessary to fill in all the fields in the user properties edit window. You can fill in the remaining fields later.
A new user can be created by copying an existing one. With this feature it's not necessary to create a new user from scratch as you will simply need to copy one of the existing users to the list and edit their properties.
To copy, select a source line in the user list and execute the Actions – Clone command.
When you create a copy of a user, the user name can be transformed to keep it unique. Other properties (except the password) of a newly created user will be the same as those of the source user.
To make it impossible for users to login to 1C:Enterprise under different names, an access password can be specified for every user allowed to work with the system. Similarly to the user name, the password is used to confirm the user's rights to work in the system.
Enter the user password into the appropriate field. The password is an arbitrary combination of alphanumeric characters. The password should not exceed 255 characters.
The password you are entering will be displayed in asterisks, so make sure to pay close attention to what you are typing to prevent any errors during entry.
Re-enter the password in the Confirm Password field to avoid possible erratic entry. If the password confirmation does not match the originally entered password, the Password and confirmation do not match warning will be displayed when you click OK, and the password will not be set.
Click the Cancel button if you decide not to set a password.
You cannot view the user password. Therefore, you should pay extreme attention to selecting a password and remember the value.
If a user forgets their password, you have to set a new password for this user.
Users with a password are identified by a special icon in the user list (a lock in the icon, see the user Storekeeper in the fig. 38).
To delete a user, highlight the user name in the user list and select Actions – Delete command in the User list window.
To confirm your intention to delete the user, in the displayed prompt you will need to click Yes.
The Administration – Users option of the Designer menu is intended to edit user parameters. Highlight the user in the list and select Actions – Change menu option in the User list window.
The User window is intended to edit the parameters of the selected user.
Use filters to view user list conveniently. Select the Actions – Set Filter command in the user list.
Fig. 41. Filtering
Users can be filtered by role, language, operation mode and user authentication mode.
Authentication checks whether the provided identifier (name) belongs to a certain user of the system. This is a sort of verification. 1C:Enterprise supports several different authentication options, which will be described in the sections below.
User authentication in 1C:Enterprise requires you to enter the user name and password (in the authentication dialog, as command line parameters or connection string parameters for an external connection with a database or an automation server). In this scenario, 1C:Enterprise verifies whether the user exists and its password has been entered correctly.
The user can be authenticated implicitly by the operating system. To this end, a certain OS user should be assigned to the user to be verified. At system startup, 1C:Enterprise requests the OS to provide a user who is currently authenticated in the system. The SSPI interface in Windows and the GSS-API interface in Linux are used for this. Then the system verifies that this OS user is assigned to the 1C:Enterprise user. If the search is successful, the 1C:Enterprise user is authenticated successfully, and no authentication dialog is displayed.
The client application run under Linux does not support authentication by operating system tools.
No OS user authentication is supported if a client application connects to an infobase via an Apache web server under Windows.
The OS user should be specified in the following format: \\domain_name\user_name.
If you need to enforce user authentication with 1C:Enterprise tools, enter the command line key (-WA-) in the client application startup command line. Therefore, the -WA+ command line key is used for forced OS authentication with the OS tools (enabled by default).
OpenID (http://openid.net/) is a protocol that can be used by the user to authenticate on many resources, systems, etc. that are not connected with each other with the same credentials. 1C:Enterprise uses an OpenID 2.0-based protocol and the Direct Identity model.
This authentication method cannot be used to call web services published by 1C:Enterprise.
A 1C:Enterprise infobase functions as an OpenID provider.
The general process flow is as follows:
A user tries to log in to the system.
The system identifies that OpenID authentication is used in an infobase (the default.vrd publication file points to that).
An authentication query is sent to the OpenID provider.
If no interactive actions are required (the identifier is authenticated for the first time, or the authentication attribute of this identifier expires), the provider prompts the system to ask the user to provide his/her username and password. The system performs an interactive action and returns the data it obtains to an OpenID provider.
The successful user authentication attribute is stored in cookie files that are located in an individual web browser for each storage. The thin client uses its own storage.
If the provider authenticates the user, information that the user is authenticated returns to the system.
OpenID authentication only works when an infobase is accessed via HTTP/ HTTPS protocols. This means that only a web client and a thin client connected to an infobase via a web server can use OpenID authentication. OpenID authentication supports cross domain queries in the thin client and Mozilla Firefox, Google Chrome, Safari, and Microsoft Internet Explorer 8 and 9 web browsers. A window prompting the user to confirm operation opens in Microsoft Internet Explorer 6.0 and 8 after the user provides his/her user name and password. If the user confirms the operation, authentication proceeds. Otherwise, the system prompts the user to enter the user name and password again.
A 1C:Enterprise infobase functions as an OpenID provider. Names of infobase users are used as an OpenID identifier (see page 98). Such an infobase should be published on a web server (the default.vrd publication file contains a special element) and made available to the infobase that wants to perform an OpenID authentication.
Interaction with the OpenID provider is only supported via the HTTPS connection.
The Name property assigned to the user of an OpenID provider infobase is used as an OpenID identifier of that user. The user password is also set in the OpenID provider infobase. The password set in an infobase which functions as an OpenID provider client is ignored in OpenID authentication.
If you need to perform forced OpenID authentication, enter the default -OIDA+ command line key in the client application startup command line. In this way, the -OIDA- command line key can be used to expressly disable OpenID authentication.
For more details on setting up a web server for working with OpenID authentication, see page 167.
Sometimes it is good to know what users are currently working with the infobase.
Use the Administration – Active Users command to view the active user list. A window will be opened that contains a list of the users that are currently working with the database.
Fig. 42. Active Users
The active line shows the information of a user that opens this window (current session).
The current user is identified by an icon (a marked user icon).
Use the Actions menu to customize list view or to save the list as a spreadsheet or a text document.
You can sort the list of active users by any column.
1C:Enterprise makes it possible to lock user infobase sessions. You can deny a user infobase session and display a message stating the reason for the denial.
For example, this can be useful when in the administrative purposes you need current users to terminate their sessions and prevent new users from connecting to the infobase.
In the client/server mode sessions can be locked using 1C:Enterprise server cluster administration utility.
There is also a feature to connect to the infobase by bypassing the sessions lock. The /UC<access code> command line option and UC=<access code> connec-
tion string option are intended to achieve the bypass. If an access code is specified when the lock is initiated, you should enter this code in the /UC option to bypass the lock and connect to the infobase. If the access code contains any spaces, it should be enclosed in quotation marks.
If web client or thin client operating via a web server is used, it is possible to enter the access code in the UC option of the descriptor file connection string (see page 235). In this situation we recommend publishing the infobase to the web server additionally.
Using the script language
In any operation mode a lock can be enabled using 1C:Enterprise script language. Use the SessionsLock 1C:Enterprise script entity that you can create in the wizard and customize the sessions lock properties as needed.
The SetSessionsLock() global context method allows you to enable a created lock, and the GetSessionsLock() method is intended to obtain the already enabled lock.
The regional infobase settings customization mode is intended to manage the date and time formats, the format of numbers and logical constants. It also determines lines sorting order in the infobase lists. Use the Administration – Infobase Regional Settings command to initiate this mode.
Fig. 43. Regional Settings
If a property is not selected, the date, number and time formats will be defined by default settings used in the 1C:Enterprise for the specified language (country). Language (country) is specified when the infobase is created.
If Use regional settings from the current session is checked, the Number, Date, and Boolean values are displayed in compliance with the regional settings used in the current session (including in the input fields, calendar and calculator). These settings are defined based on the regional settings of the client computer but they can also be overridden by the /VL option.
The bottom part of the dialog window contains samples of number, date and time view with the selected settings applied.
Boolean values are displayed in accordance with the platform’s interface language. You can specify this value with the -L parameter.
Language (Country). Select the language (country) for the current infobase installation.
If PostgreSQL is used as the database management system, the language (country) cannot be changed for an existing infobase randomly. The defined language (country) value can only be replaced by another value that will apply the same lines sorting order (collation) of the DBMS that is used due to the existing value. For example, you can replace Russian (Russia) with Belarusian (Belarus) but replacing this value with Ukrainian (Ukraine) is impossible.
If IBM DB2 is used as the database management system, changing the value for language (country) is not supported.
Decimal separator. You pick a separator from the list or enter it manually into the appropriate input field. A sample symbol will be shown to the left of the input field.
Thousands separator. You can select the thousands group separator from the dropdown list or enter it manually into the appropriate input field. A sample symbol will be shown to the left of the input field.
Grouping. Use this option to customize the number grouping in the whole part of numbers. You can pick the format line from the dropdown list or enter it manually.
Use the following grouping format: <number of digits in a group><separator>… …<0>.
You can use any non-numeric symbol as a separator.
For example, the 3,2,0 sequence means that a number will be grouped as follows (the digits are counted from left to right and only in the whole part):
the first group consists of the first three digits;
this group is followed by a separator (specified in the operating system settings or in the Thousands separator option);
the remaining digits of a number will be grouped by two.
The zero (0) character in the end of the format line means "up to the end". So if we remove 0 in the end of the format line in our example and specify 3,2 sequence only instead, the following grouping will be applied:
the first group consists of the first three digits;
this group is followed by a separator;
the second group consists of the next two digits;
this group is followed by a separator;
the remaining digits are all grouped together.
Entering only one zero (0) into this field means that the digits in the whole part of numbers will not be grouped.
Negative number representation. You can select the negative number view from the dropdown list. Pick Auto to use the operating system settings for negative numbers.
Date format. Specifies the date format. You can use the following characters in different combinations:
The day of the month. Numbers under 10 are displayed without the leading zero.
The day of the month. Numbers under 10 are displayed with the leading zero.
The month number. The month numbers under 10 are displayed without the leading zero.
The month number. The month numbers under 10 are displayed with the leading zero.
Two last digits of the year number. Numbers under 10 are displayed without the leading zero.
Two last digits of the year number. Numbers under 10 are displayed with the leading zero.
Four-digit year number.
You can customize the above characters and characters groups to be used in any order. You can use different separators between day, month and year values.
Time format. Specifies time format. You can use the following characters in different combinations:
Hours in 12-hour (h) or 24-hour (H) format. Hours under 10 are displayed without the leading zero.
Hours in 12-hour (hh) or 24-hour (HH) format. Hours under 10 are displayed with the leading zero.
Minutes. Minutes under 10 are displayed without the leading zero.
Minutes. Minutes under 10 are displayed with the leading zero.
Seconds. Seconds under 10 are displayed without the leading zero.
Seconds. Seconds under 10 are displayed with the leading zero.
You can customize the above characters and characters groups to be used in any order. You can use different separators between hours, minutes and seconds.
When you use regional settings to customize date format for input fields, you should only use the settings supported by input fields.
Logical False, Logical True. Use this option to customize logical constants view.
You can select the constant format from the dropdown list or enter it manually.
The infobase options customization mode is intended to specify data lock timeout and select if restrictions should be applied to user passwords.
Fig. 44. Infobase Options
The following options can be customized:
Data Lock Time Out (in Seconds)
The timeout for transaction lock by database server. For example, if the current transaction must lock data but this record is already locked by another transaction, the current transaction will wait for the data to be unlocked, but the timeout will not exceed the value of this option. This option also defines the transaction lock timeout in the 1C:Enterprise managed transaction lock mode.
Minimum User Password Length
Defines a minimum length for user passwords. If the User Password Complexity Check option is checked, passwords must have at least 7 characters.
User Password Complexity Check
If this option is checked, the users' passwords should satisfy the following criteria:
The password length should not be less than the value of the Minimum User Password Length option;
The password should include characters from at least three of the following groups:
○ uppercase letters
○ lowercase letters
○ numeric characters
○ special characters
Password should not be the same as the user name; Password should not be a sequence of characters.
Applying restrictions to infobase user passwords does not affect the existing passwords. The restrictions will only be applied when an existing password is changed or a new infobase user is added. But a password is verified based on the current infobase settings. This means that when User Password Complexity Check is checked, password verification will be case-sensitive.
For example, if for some reason PaSsWoRd was set as a password for some user, with User Password Complexity Check option unchecked, a user could enter the password in any of the following manners: password, or PASSWORD, or Password with any of the entry versions enabling the user to log in. If the User Password Complexity Check option is subsequently checked, user will only be able to log in if the password is entered with case matching: PaSwWoRd.
The current infobase can be saved to a file.
Use Administration – Dump Infobase to save the data to a file. The standard file selection dialog will be displayed. Browse to the directory and specify the name for the file that will be used to dump the data.
The dumping mechanism enables you to:
obtain an image of an infobase regardless of the data storage mechanism being used.
transfer an infobase from one DBMS (or a file mode) to another DBMS (or a file mode).
Before dumping an infobase, testing (with the Designer or a special utility) and fixing any issues detected are recommended.
This method is not recommended for creating a backup copy of an infobase because:
a situation may occur when the dumped file cannot be loaded if an infobase from which the file was dumped contained errors;
creating such a backup copy in this way can be time consuming;
exclusive database access is required; the high requirements for RAM.
Infobase operation in the exclusive mode does not switch the MS SQL database to the single user mode.
Use the Administration – Restore Infobase menu option to restore an infobase from a file.
The standard file selection dialog will be displayed. Browse to the directory and specify the name for the file that will be used to record the data.
The current infobase will be completely replaced upon restoration.
To speed up infobase restoration when Microsoft SQL Server DBMS is used, it is recommended that you set the database recovery mode to the Simple restoration or Bulk logged restoration values. The mode can be changed either prior to restoration or on an ongoing basis if restoring the database at an arbitrary point of time is not necessary. Database backup must be performed before you change the database restoration mode!
Infobase dump files (.dt) generated by 1C:Enterprise 8.1 and 8.2 can be restored by 1C:Enterprise 8.3.
When you attempt to restore the configuration with an unknown compatibility mode, an error message will be returned indicating the version required. Restoration of 1cv8.dt files generated in version 8.3.1 and above is not permitted in older versions of 1C:Enterprise (older than 8.3.1), except where the Compatibility mode configuration property is set to Version 8.2.16 in version 8.3.1 and above.
6.8. CREATING A BACKUP COPY OF AN INFOBASE
A backup is required before any operations that can damage the infobase data.
No connections (including those established by the Designer) should be made to a file infobase when the backup copy of the infobase is created.
Backup can be carried out in any software for operations with files. Using the files manager open the directory containing the infobase. To create a copy of the infobase, simply copy the 1Cv8.1CD file to a separate directory. To restore the infobase (if it is damaged, corrupted, etc.), simply copy the saved file to the directory where it was previously located.
Note that you can also carry out infobase backups using special software tools designed for data backup and restoration.
A user backs up on a mobile platform by using built-in tools in iOS and specialized programs in Android.
Various abnormal situations (e.g. power failures, operating system hang-up, hardware failures, etc.) can occur when you work with 1C:Enterprise. If such situations occur at the time when changes are recorded to the 1C:Enterprise infobase (especially in the file mode), they can corrupt the infobase. There can be different signs of infobase corruption, including inability to run 1C:Enterprise.
The infobase verification and repair procedure is used for diagnostics and error correction of the infobase in various formats (file mode or client/server mode).
Use the Administration – Verify and Repair menu option to initiate this mode. The following dialog window will be displayed:
Fig. 45. Infobase Verification and Repair
Specify the required checks and modes. You can run different types of tests independently. You can reindex and compress database for a file mode of an infobase. You can also check the logical integrity of data and recalculate totals for both modes (the file mode and the client/server mode).
For certain distributed infobase that allow you to acquire the data that contain references to objects outside of the infobase under testing, unchecking the Checking infobase reference integrity option will make it possible not to create "nonexistent" data, and, consequently, will not send the data to the other nodes of the distributed infobase.
There are several groups of settings under the list of modes:
The first group is intended to select the actions required: verification only or both verification and repair. In the first case, the software will verify the infobase without making any changes. In the latter case, the software will follow the instructions from the second group of settings. Switch names describe their functions.
The settings in the second group determine the actions for when references to non-existent objects are identified or for when data in the existing objects are partly lost.
The third group of controls enables you to carry out lengthy verification and repair procedures divided into multiple sessions.
The Abort check after checkbox is intended to specify verification timeout: when this value is achieved, verification will be aborted while the verification and repair options will be saved for the next Designer session.
The Resume previously aborted testing checkbox is intended to resume the procedure from the point where it was aborted in the previous verification and repair session.
The verification and repair events are recorded in the event log.
Click the Execute button to initiate the verification procedure. Testing may be aborted by pressing Ctrl + Break.
The software will check if it is possible to switch to the exclusive mode and will turn the mode on if possible. If it is impossible to switch to the exclusive mode, the following warning will be displayed: Unable to switch access to exclusive mode. Users at work. Open the active users list (using the Administration – Active Users menu item, see page 104) to view the currently active users.
If the exclusive mode is enabled, the software will begin executing the specified actions, and the testing results dialog window will be opened.
Infobase operation in the exclusive mode does not switch the MS SQL database to the single user mode.
The exclusive mode will be switched off upon completion.
The distribution kit includes a file mode database restoration utility (chdbfl.exe). For description of this utility, see page 315.
If the master node of the distributed infobase needs to be reset, you can use the /ResetMasterNode command line option of Designer batch startup mode. This operation is equivalent to calling the SetMasterNode(Undefined) method of the ExchangePlanManager object.
This operation can become necessary, for example, if any subtree of the distributed infobase needs to be evolved into an independent infobase or when you need to change subordination of distributed infobase nodes. For details on the distributed infobase, see "1C:Enterprise 8.3. Developer Guide".
When a data area or an entire infobase has to be deleted, use the /EraseData option of the command line for Designer batch startup mode. The area to be deleted is defined with the /Z parameter of the startup command line. For detailed information about the distributed infobase, see "1C:Enterprise 8.3. Developer Guide".
To delete data, the account under which the data is being deleted must have Administration rights and be capable of getting exclusive access to the infobase.
If none of the separators is used in the session or data deletion is executed in an unseparated infobase, all infobase data will be deleted.
Administrative duties often require finding out what events have occurred at a particular time or what actions various users have executed.
The event log is used for this purpose. Various events are recorded in this log. An administrator can use it to obtain a history of users' interactions with the system.
The event log is not stored in the database and is not saved when an infobase is restored/dumped.
When users work in the 1C:Enterprise, the software registers major user actions involving infobase data modifications, scheduled operations, connection and disconnection, etc.
The event log works both in the Designer and in the 1C:Enterprise modes.
For description of handling event log in the 1C:Enterprise mode, see page 131.
Use Administration – Event Log Options to configure events registration in the log.
Fig. 46. Event Log Options
In the network mode you can save the customized settings only if no users except the administrator are working with the configuration.
Event log records are saved in files. Each file contains records for a certain period. The period itself is defined in the Divide log by periods field. A new file is opened when a new value for each of the following is reached (defined in the option value):
When a new infobase is created, a day is selected for the event log splitting period and the events of all the importance levels are selected to be recorded.
The event log can accumulate a significant number of records over time. To reduce the number of records, open the log option window and click the Reduce Size button. The following window will be displayed:
Fig. 47. Saving Event Log
The records will be truncated up to the date defined in the Delete events older than. Please, note that this will delete all the records of the event log splitting period the specified date belongs to (see above for the description of the Divide log by periods field). So if a month is selected as the splitting period and the date specified is, for example, 8/1/2013, all the event log records up to August 2013 (inclusive) will be deleted. Also note that the event log splitting period can be changed with time and the deleted period will be defined by the period used as of the date specified in the Delete events older than field instead of the current splitting period used.
If you want to save the deleted records, check the Write deleted events to file option and enter a name for the file to save records to.
If you want to reduce the log size regularly and enable viewing of the already deleted log events, check Save the log divided by periods and merge it with the previous log.
In order to preserve splitting into periods for when the Designer is launched
in the command mode, you can also use the /ReduceEventLogSize KeepSplitting command.
Use the File – Open menu item and pick the Event log (*.lgf) file type in the standard file opening dialog window to view the archived event log records. Select the required archive file and click Open.
The automatic update and update period are customized using the standard table box list customization tool.
An event in the event log is identified by a row. At that a combination of characters _$ and $_ is used to distinguish system events (e.g., _$InfoBase$_.MasterNodeUpdate or _$PerformError$_). _$InfoBase$_.MasterNodeUpdate will be displayed as a row: Infobase. Master node update. It is prohibited to use these characters combination in the names of the events recorded via the 1C:Enterprise script using the WriteLogEvent method. The events created using this method are displayed as is.
To save the event log, open it and select File – Save Copy menu item. A dialog box will be displayed to browse to the directory and the file that will be used to dump the records as well as to select the file type (the event log file extension *.lgf is assigned by default). It is also possible to dump the records to an XML file (for description of the format, see page 229).
Sample of event log dump:
<v8e:EventLog xmlns:v8e = "http://v8.1c.ru/eventLog" xmlns:xsd = "http://www.w3.org/2001/XMLSchema" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"> <v8e:Event> <v8e:Level>Warning</v8e:Level> <v8e:Date>Event date</v8e:Date> <v8e:Application>Enterprise</v8e:Application> <v8e:ApplicationPresentation> 1C:Enterprise</v8e:ApplicationPresentation> <v8e:EventName>Event name</v8e:EventName> <v8e:EventPresentation> Event presentation</v8e:EventPresentation> <v8e:UserID>00000000-0000-0000-0000-000000000001</v8e:UserID> <v8e:UserName>Ivanov</v8e:UserName> <v8e:Computer>Ivanov</v8e:Computer> <v8e:MetadataName>Catalogs.Nomenclature</v8e:MetadataName> <v8e:MetadataPresentation> Catalogs Nomenclature</v8e:MetadataPresentation> <v8e:Comment>Comment</v8e:Comment> <v8e:Data xsi:type="xsd:string">Some data</v8e:Data> <v8e:DataPresentation>Data description</v8e:DataPresentation> </v8e:Event> </v8e:EventLog>
1C:Enterprise supports the technological log functionality. This log contains information from all the 1C:Enterprise applications.
The technological log is intended to identify errors occurring in the 1C:Enterprise operation and for 1C Company technical support service to carry out diagnostics. The log is also used to analyze the software performance indicators.
The assortment of the events contained in the technological log and their properties can vary from one platform release to another.
Since the technological log is basically a collection of text files stored in various directories, it can be used by application developers to analyze various 1C:Enterprise and applications' operation modes.
The technological log can be maintained on any computer where 1C:Enterprise is installed. Maintenance of the technological log depends on the configuration file that describes:
The directory that will hold the technological log files;
The information that will be recorded in the technological log;
Storage time for technological log files;
Parameters of the dump that is created upon application failure.
This configuration file does not exist by default. This means that the technological log is enabled and is instructed to save minimum dumps upon application failures to the following directory:
%USERPROFILE%\Local Setings\Application Data\1C\1Cv8\dumps
In Windows Vista and above, the directory will appear as follows:
If required, the event log can be customized randomly using a separate configuration file. This file should be named logcfg.xml and located in the 1C:Enterprise configuration files directory. For details on the configuration file structure and features, see page 266.
For the technological log to operate under Windows, the user of the process creating a record in the log should possess full access rights to the technological log directory and read rights to the technological log directory owner.
1C:Enterprise will send requests to the program files directory regularly (every 60 seconds) to check if the configuration file exists and what its content is if any. This means that the technological log options can be modified right in the process of operation without restarting the already running 1C:Enterprise applications.
With certain settings applied, the technological log can be rather sizable so we recommend specifying storage time for the log files in the configuration file. Once this time is reached, 1C:Enterprise will delete the obsolete log files. If the directory holding these obsolete files is empty when the files are deleted, the directory itself will be deleted as well. Hence, the entire technological log directory tree will not contain any obsolete files or folders.
If the software runs under Linux, the operating system tools manage crash dumps production. At that the technological log will include the information on the process crash and the number of the alert that resulted in this failure. For details on log customization for Linux, see page 122.
Please note that the technological log directory is not intended for storing files which are not related to the technological log. So do not place dumps in it and do not use a directory that may contain files which are not related to the 1C:Enterprise technological log. If the directory specified as a technological logdirectory contains any unrelated files, specification of the directory will fail and the technological log will not be created.
Below you will find sample content of a very basic configuration file:
<config xmlns="http://v8.1c.ru/v8/tech-log"> <log location="c:\1c\logs" history="1"> <event> <eq property="name" value="conn"/> </event> </log> <dump location="c:\1c\dumps" create="1" type="2"/> </config>
Here is the meaning of the configuration file content:
All the client connections to the server and disconnections are recorded in the technological log;
The technological log files are located at c:\1c\logs;
The technological log files are stored for one hour;
The dump files are located at c:\1c\dumps;
The dump files contain all the information available (the content of the entire process memory).
When no configuration file exists, the following parameters are applied:
The technological log is disabled;
The technological log is enabled by default;
Minimum dump files;
Dumps are stored in the directory %USERPROFILE%\Local Settings\Application Data\1C\1cv8\dumps of the current user profile.
For details on the configuration file structure and features, see page 266.
Handling the configuration file under Linux is virtually similar to handling it under Windows with the following distinctions:
The file should be stored in the 1C:Enterprise configuration files directory.
The account under which the application (server, client applications, web server extensions, etc.) generating the technological log is run should have write access to the directory where the technological log will be generated.
The Default Technological Log can be used to record critical events in the 1C:Enterprise system. A fixed event filter that cannot be changed is created by the platform for this log.
The default technological log has the following settings:
A file directory of the default technological log:
○ Windows:%USERPROFILE%\Local Settings\Application Data\1C\1cv8\logs (or %LOCALAPPDATA%\1C\1cv8\logs for Windows Vista or later). ○ Linux:~/.1cv8/logs.
By default, data is deleted from the technological log after 24 hours.
SYSTEM events (Error level) are recorded in the technological log by default.
You can change these settings with the <defaultlog> element (see page 298). Rules that regulate creation of the events to be registered in the technological log by default can be set with the <system> element (see page 300).
The technological log is basically a directory with its subdirectories holding the technological data collected. The log directory structure is described below:
<log directory> <operating system process ID> <log files of an individual process>
Every log file contains the events for 1 hour. A file is named as follows:
yy – two last digits of the year number
mm – month number
dd – day number
hh – hour number
The log files are text files. In such a file the information of every individual event ending is recorded on a new line.
16:08.8750–9060,CALL,0,process=rphost,p:processName=DebugControlCenter,t:clientID=221,t:applicationName =Debugger,t:computerName=COMP1,Interface=5cf29e71–ec34–4f01–b7d1–3529a3da6a21,Method=0 16:08.8911–1,DBPOSTGRS,2,process=rphost,p:processName=Database,t:clientID=216,t:applicationName= 1CV8,t:computerName= COMP1,t:connectID=125,Usr= User2,Trans=1,dbpid=58152,Sql= "SELECT 1::INT8 FROM PG_CLASS WHERE pg_catalog.pg_table_is_visible(OID) AND RELKIND='r' AND RELNAME='params' LIMIT 1",Result=PGRES_TUPLES_OK 16:08.8913–1,DBPOSTGRS,2,process=rphost,p:processName=Database,t:clientID=216,t:applicationName= 1CV8,t:computerName= COMP1,t:connectID=125,Usr=User2,Trans=1,dbpid=58152,Sql= "SELECT Creation,Modified,Attributes,DataSize,BinaryData FROM Params WHERE FileName = 'ibparams.inf'",Result=PGRES_TUPLES_OK
Event ending line is formatted as follows: mm:ss.tttttt-d, <name>, <level>, <key properties>, where:
mm – the number of the minute of the current hour
ss – the number of the second of the current minute
tttttt – the number of the microsecond of the current second
d – the event length measured in microseconds
<name> – event name
<level> – event level in the current thread stack
<key properties> – <key property>, <key property>, …
<Key property> – <name> = <value>; <description>, <name>, <value> – arbitrary text. If the text contains any line end characters or commas, the text should be enclosed in quotation marks or apostrophes depending on what is less present in the line while the quotation marks or apostrophes contained in the text itself will be doubled.
6.13.4. Customization of Memory Dumps Generation
This section covers sample customization of a technological log configuration file (logcfg.xml) that is required to create crash memory dumps:
<config xmlns="http://v8.1c.ru/v8/tech-log"> <dump location="C:\Program Files\1cv8\dumps" create="1" type="3"/> </config>
When this setup is applied, memory dumps will be generated at C:\Program Files\1cv8\dumps and will include the entire process memory content and an extra data segment.
The user account the client application is running under should possess full rights to the following directories:
temporary files directory
technological log directory
The user account the client application is running under should possess read rights to the following directories:
configuration files directory (see page 227)
the directory holding the dumps directory
If query plan receipt is customized in the logcfg.xml file, this file must be located in the configuration files directory of the appropriate application:
For the client/server mode – in the directory of the configuration files available to the 1C:Enterprise server.
For the file mode with a direct connection – in the directory of the configuration files available to the appropriate version of the client application.
For the file mode with a web server connection – in the directory of the configuration files available to the extension of the web server supporting this infobase. For details on logcfg.xml customization, see page 266.
This section covers the steps involved in Linux setup required to provide for memory dumps generation upon application crashes.
The instructions provided in the current section are fully applicable to Fedora Core 4 operating system and its analogues. For other Linux distribution kits the commands described below can have different names and syntax. For details, see help of the used Linux distribution kit.
Generation of crash dumps is disabled by default. Linux distributors recommend enabling dumps generation only on the computers used for development (versus the computers used in actual software operation). Enabling Automatic Dumps Generation
Generation of abend dumps is configured for all processes executed by a particular user. To enable automatic generation of dumps, add the lines below to the
<username> soft core unlimited <username> hard core unlimited
Where <username> is the name of the account under which the 1C:Enterprise application is being run.
To better understand which process generated a crash dump and to locate the dumps on the hard drive, we recommend specifying a template for dump naming.
A template can be specified for a single session only or continuously.
The customization described in this section affects all processes executed by all the users of the operating system. This means that the abend dumps of other users (if their generation is enabled) will be stored according to the specified path with the selected name pattern.
The actions below should be executed under the root user account.
To specify a template for crash dumps names and paths use the following command:
sysctl -w kernel.core_pattern=/tmp/core. e. p
This setting will be valid until the computer is restarted. In this situation the dumps will be located in the /tmp directory while the names of the dumps will contain:
executable file name
ID of the process the crash dump is generated for
To specify a continuous template for the name and the path, you should add the following string to /etc/sysctl.conf:
kernel.core_pattern=/tmp/core. e. p
For the changes in the file to be applied, you will also need to execute the following command:
Accounts under which applications generating abend dumps are run should have write access to the path specified in the settings.
In the samples below we assume that 1C:Enterprise is installed by default to C:\Program Files\1cv8.
Remember that some technological log settings can result in a large volume of data being output to its directory. You should therefore ensure enough free space on the disk where you aim to locate the files from the technological log.
Below you will find some examples of logcfg.xml files demonstrating the most frequently used technological log configurations.
If no logcfg.xml file is available in the 1C:Enterprise configuration files directory (see page 227), the technological log will not be generated. If the logcfg.xml file is required for correct dumps setup, it should not contain any log elements. The example below defines generation of a full application dump upon failure. The dumps are located at: C:\v8\dumps.
<config xmlns="http://v8.1c.ru/v8/tech-log"> <dump location="C:\v8\dumps" create="1" type="3"/> </config>
The configuration file below specifies for recording of all the events along with all their properties in the technological log. The log will be stored for a week (168 hours). The volume of the information recorded will be very large with this arrangement but it can be useful for analysis of complicated exceptions. This configuration is recommended for the QA period and for errors examination.
<config xmlns="http://v8.1c.ru/v8/tech-log"> <log location="C:\v8\logs" history="168"> <event> <ne property="name" value="/> </event> <property name="all"> </property> </log> </config>
The following configuration file defines that the technological log will only contain 1C:Enterprise calls to the database management system and the information on errors. The volume of the recorded information is lower than that for full technological log maintenance but can also be very large.
<config xmlns="http://v8.1c.ru/v8/tech-log"> <log location="C:\v8\logs" history="168"> <event> <eq property="name" value="dbmssql"/> </event> <event> <eq property="name" value="dbpostgres"/> </event> <event> <eq property="name" value="db2"/> </event> <event> <eq property="name" value="dboracle"/> </event> <event> <eq property="name" value="excp"/> </event> <property name="all"> </property> </log> </config>
This configuration file creates a moderately sized technological log that will contain the information on applications startup and termination, on connecting to the 1C:Enterprise server cluster and disconnecting from it, on cluster administrator actions and the 1C:Enterprise errors. In the majority of situations this log is sufficient to investigate errors both in the configuration and in the 1C:Enterprise technological platform.
<config xmlns="http://v8.1c.ru/v8/tech-log"> <log location="C:\v8\logs" history="168"> <event> <eq property="name" value="admin"/> </event> <event> <eq property="name" value="conn"/> </event> <event> <eq property="name" value="excp"/> </event> <event> <eq property="name" value="proc"/> </event> <event> <eq property="name" value="qerr"/> </event> <event> <eq property="name" value="scom"/> </event> <property name="all"/> </log> </config>
In comparison to the previous file, this configuration file also adds all the operations lasting over 10 seconds. This may be useful to identify users' actions that took a lengthy time, for example, to subsequently optimize the operations. The events length is measured in hundreds of microseconds.
<?xml version="1.0" encoding="UTF-8"?> <config xmlns="http://v8.1c.ru/v8/tech-log"> <dump create="false"/> <log location="C:\v8\logs" history="168"> <event> <eq property="name" value="admin"/> <gt property="duration" value="10000"/> </event> <event> <eq property="name" value="conn"/> <gt property="duration" value="10000"/> </event> <event> <eq property="name" value="excp"/> <gt property="duration" value="10000"/> </event> <event> <eq property="name" value="proc"/> <gt property="duration" value="10000"/> </event> <event> <eq property="name" value="qerr"/> <gt property="duration" value="10000"/> </event> <event> <eq property="name" value="scom"/> <gt property="duration" value="10000"/> </event> <property name="all"/> </log> </config>
1C:Enterprise stores a considerable portion of data as references. For example, when documents are entered, one can fill in many document attributes by selecting their values from a list or from a document contained in a list of documents. These attributes are references to the items in corresponding lists.
Using references, you can avoid multiple corrections of the same information in various locations. For example, after a number of documents had been input and printed, it was found out that a name of a contractor was specified incorrectly in the documents. Since the contractor name had been input in the documents by selecting it from the contractors list, you can only edit the contractor’s name in the list itself and this name will be automatically corrected in the documents. The only thing you have to do is rebuild the corresponding print forms.
However, if you delete the contractor from the list, all the documents that used the company will contain invalid references, that is, references to a non-existent object.
To avoid such situations, 1C:Enterprise comes with reference integrity control that will be described in this section.
Reference integrity control divides the deletion process of referenced data objects (such as lists and documents) into two stages.
At the first stage, users mark objects for deletion. An object that is marked for deletion can be used as an ordinary object.
At the second stage, the system administrator or another person possessing appropriate rights (assigned by the Interactive delete marked right for corresponding types of lists and documents) performs a special procedure – deletion of marked objects. This procedure is implemented as the standard Delete Marked Objects feature (for details, see page 136). When this procedure is executed, all the references to the marked objects are completely analyzed and only those objects can be deleted that are either not referenced to or are referenced to from the objects that are also marked for deletion.
Actually, the deletion procedure for the marked objects is a scheduled procedure. The procedure is recommended to be performed periodically, as enough marked objects are accumulated.
1C:Enterprise makes it possible to delete unnecessary or obsolete information in two modes:
Direct deletion of objects: no analysis of the deleted object usage in other database objects;
Reference integrity control enabled: objects are first marked for deletion, followed by checking if these objects are referenced to from other objects.
Deletion rights (direct deletion or reference integrity control enabled) are assigned for every user role by every object type (lists and documents) at the stage of application designing.
If a user works in the direct deletion mode, additional responsibility is laid both on the user that deletes the objects and on the system administrator that assigns user rights and system actions with invalid references. For example, specialists debugging an application can operate the system with reference integrity control disabled. If reference integrity control is not used, objects are deleted directly (without deletion marks), and it can result in invalid references.
The most drastic approach to reference integrity control mode setup is complete disabling of objects direct deletion rights in the entire configuration. This method completely excludes the capability to directly delete objects within this application. Users will only be able to mark objects for deletion.
Rights for direct deletion of objects, marking objects for deletion and removing deletion marks should be assigned for each object type of the configuration. If Interactive delete right is selected for a given type for a selected set of rights (for a role), users who are assigned this role can directly delete objects of the given type. Rights are assigned at the application development stage.
The rights to mark objects for deletion and to remove the deletion mark, as well as that of marked objects deletion are assigned similarly.
Consistent use of reference integrity mechanism by all the users is only achieved through disabling the Interactive delete right in the configuration.
Please note that objects can be directly deleted using 1C:Enterprise script tools. Therefore, elements of a specific configuration can directly delete objects, bypassing reference integrity control. In this case, a specialist who develops the specific configuration mechanism is responsible for the data integrity.
If the reference integrity control mode is not used (the Interactive delete right is selected in the configuration for a specific user and a specific type of the configuration objects), the user can select the Delete Directly menu item (Shift + Del key or the corresponding toolbar button) to delete objects of this type from the lists of lists and document journals. This object is deleted without checking if it is referenced by other objects.
When reference integrity control is enabled, the lists of lists and document journals contain the Mark/Unmark for deletion option in the More (All Actions) menu. If this menu option is selected, an object is marked for deletion. An object that is marked for deletion will have an icon in the left column of the list; the icon shows a crossed-out object image.
If a posted document is marked for deletion, the document becomes unposted.
Selecting More – Mark/Unmark for deletion (All Actions – Mark/Unmark for deletion) menu item will mark an object for deletion while if an object is already marked for deletion, the mark will be removed instead.
If a deletion mark is removed, the document is still unposted. You should re-post the document in order for the document to become posted.
The possibility to mark for deletion or remove the deletion mark by a specific user is also regulated by access rights (marking for deletion and removing the deletion mark are regulated separately).
Objects that are marked for deletion are used in the generally similarly manner as ordinary objects. They are also displayed in the lists, they are searchable, etc. You can open and edit the objects that are marked for deletion.
A document that is marked for deletion cannot be posted. If an attempt is made to post a document that is marked for deletion, the corresponding message is displayed and the document is not posted.
When referring to "standard functions", we mean a set of system tools that are intended to carry out various service-related activities that may be needed for infobase administration.
The service functions are only accessible in the 1C:Enterprise mode. To enable access to standard functions, you will need to check the appropriate option in the settings window (Tools – Options – Show "All Functions" command).
Getting navigation links is not supported for standard functions windows so they cannot be added to user favorites.
The complete list of standard functions along with a brief description of every function is provided below:
Displays the list of the users currently logged into 1C:Enterprise. Availability of the function is determined by Active users right.
Intended to view the event log.
Availability of the function is determined by the Event log right.
Find References to Objects
Allows to find the objects with reference to a selected object.
Intended to post and repost documents for a selected period as well as to restore various sequences existing in the configuration.
Allows to delete the objects marked for deletion.
Intended to carry out scheduled operations on registers.
Full Text Search
Manages full text search.
In order to open a required standard function, open the All functions window, select the Standard branch and in the list that opens select the function you need (provided that it is available to you).
The details on all the standard functions are provided below.
The window contains a list of the users that are currently working with the database.
Fig. 48. Active Users
The user who opens the window (for the current session) is displayed in bold.
The bottom of the window will display the total number of the users working with this infobase.
Event log – opens the event log.
User actions – opens the event log filtered by the selected user.
This action can also be executed by clicking the hyperlink which contains the user name (the User column).
Administrative duties often require finding out what events have occurred at a particular time or what actions various users have executed.
The event log is used for this purpose. Various events are recorded in this log. An administrator can use it to obtain a history of users' interactions with the system.
When users work in the 1C:Enterprise, the software registers major user actions involving infobase data modifications, scheduled operations, connection and disconnection, etc.
The event log can be viewed in a dedicated form:
Every event is recorded on a separate line of the event log. The left column (Date, time) will hold an icon displaying the event type (see fig. 49). To view an event, select More – Details (All actions – Details).
The following types of events can occur in the software operation process:
Fig. 50. Event Log Event Types
If an event is related to some data, the View data option becomes available in the More menu (Or All Actions – View data). This option can be used to view the data related to the event.
Events can be either Transactional or Independent (software determined). By default, the independent mode of event recording is selected.
Please note that there is a set of predefined events generated at the system level. The transaction nature for such events is also set at the system level. Data modification events and document posting events are transactional, while session opening and closing are independent. Below is the list of predefined events.
Independent: ○ Session:
□ Authentication □ Authentication error ○ Open-ID provider:
□ Rejected ○ Infobase:
□ Changing the configuration
□ Changing the database configuration
□ Changing the master node
□ Changing event log parameters
□ Changing infobase parameters
□ Changing regional settings
□ Deleting infobase data
□ Starting background database configuration update
□ Cancelling background database configuration update
□ Suspending background database configuration update
□ Continuing background database configuration update
□ Ending background database configuration update ○ Testing and repairing:
○ Background job:
□ Successful completion
□ Execution error
□ Cancellation ○ Access:
□ Access denial
□ Access ○ Users:
□ Deleting ○ Execution error Transactional:
□ Changing the period of calculated totals
□ Posting cancellation ○ Transaction:
Information on the transaction is displayed in the Transaction and Transaction status columns. For transactional events, the transaction status can take one of the following values: Not Completed, Committed, Rolled back. Independent events have no transaction status.
On transaction startup, the corresponding Transaction.Start event is recorded in the event log and a transaction identifier is assigned to this event. When a transaction is completion (if it is committed), the Transaction.Commit event is logged, and the Transaction.Start record transaction status is updated to Committed. If a transaction is cancelled, the Transaction.Rollback event is logged, and the Transaction.Start transaction status is replaced by Rolled back. Upon emergency transaction execution completion, the transaction status remains Not Completed.
When the event log is opened, by default it is filtered by events, excluding transaction-related events.
Records corresponding to cancelled transactions and the transactions with undefined status are displayed in "pale" font color.
In addition to simply viewing the event log for the current infobase, you can also view a portion of an event log that was earlier saved as an LGF file. This is accomplished using More – Load from file (All Actions – Load from file) command.
The interval used to display log events can be selected using the More – Set period for viewing (All Actions – Set period for viewing) menu option.
Fig. 51. Period Customization Dialog
Select the required period in the customization dialog and click OK.
You can also open this dialog by double-clicking the Date, Time column content.
The log events can be filtered using the Set filter button or More – Set filter (All actions – Set filter) menu option. The filter setup window is displayed:
Fig. 52. Event Log Filter Options Dialog
This dialog is intended to configure the filter by period, by user, by event, by computer name, by connection number, by event importance, or by comment. When setting up a filter by period, take into account the following aspects:
The filter is set up subject to time.
The time must also be set when the start or end date is edited manually.
When the start or end date is selected from the calendar, the time is set automatically: when selected in the Period from field, the time is set to 00:00:00, and when selected in the to field, the time is set to 23:59:59.
When the interval is selected by means of the … option button, the time is set to the period start date for the start and to the period end date for the end.
If multiple applications were running simultaneously, you can use the application list to specify the applications for event filtering.
Use the events list to specify the event types that should be filtered.
The Data group is intended to specify the data to filter events by. The information on the events is displayed in the Metadata, Data and Data presentation columns of the event log.
The Metadata field contains the list of the metadata available in the configuration. Check the metadata types that should be used as filter criteria.
Use the Data field to select the infobase object to filter events by.
Use the Data presentation field to configure line representation.
You can set up extended filter options in the Other group.
Transaction status – transaction statuses will be selected.
Transaction – to designate a specific transaction.
Sessions – to specify session numbers (comma separated).
Working servers – central cluster servers are selected (for client/server mode).
IP ports – IP-ports of cluster manager are selected (for client/server mode).
Additional IP ports – secondary IP-ports of cluster manager are selected (for client/server mode).
Press OK to apply the filter.
The set filter presentation is displayed to the right of the Set filter button. The filter presentation is preceded by the Clear hyperlink. Clicking this hyperlink disables the filter.
Objects that are marked for deletion are deleted in several stages. The stages follow each other in strict sequence. The process can be interrupted prior to every next stage by closing the window of this mode. System and user actions at each stage are detailed below.
At the first stage the system prompts the user to select a deletion option: complete or selective deletion.
Fig. 53. Deleting Marked Objects
When Full deletion option is selected, an attempt to delete all the marked objects will be made. Reference integrity control is applied to deletion so some of the objects may not be deleted when the operation is completed because some of such objects may be referenced by objects that cannot be deleted.
The list of the objects that could not be deleted (if any) will be displayed when deletion process is completed. For details, see page 138.
When Selective deletion option is selected, the software will generate the list of the objects that are marked for deletion. At the end of this stage, a window is displayed with a list of the identified objects that are marked for deletion in the infobase.
From the list the user will be able to select the objects to be deleted.
If an object is checked in the list, this object will be deleted (see fig. 54).
Checkboxes in this dialog only apply to the marked objects deletion mode and do not affect the object marks in the system itself. If an object is unchecked in this dialog, the object will still remain marked for deletion after you leave this mode.
To open an object's form, double-click the object. Here you will be able to view the objects and decide if you should really delete them.
At this stage, the user can switch to other windows and modes and make any necessary changes without closing the window for the marked objects deletion mode.
Click the Delete button to delete the objects. In this case, the system deletes objects that are allowed for deletion. Reference integrity control is applied to deletion so some of the objects may not be deleted when the operation is completed because some of such objects may be referenced by objects that cannot be deleted.
Fig. 54. List of Objects Marked for Deletion
If the infobase contains references to the objects selected in the marked for deletion list, the system will display the following warning: Cannot delete objects: <number> because other infobase objects reference to them. These objects will not be deleted.
Clicking Next will display the list of the objects that could not be deleted accompanied by the list of the references identified. The references are displayed for a selected object.
Fig. 55. The List of Not Deleted Objects
If you select a required reference in the list, you can open it to view and edit. Thus, you can modify the object (select another reference) so that the marked object could be deleted.
Click Close to exit the deletion of marked objects mode.
This mode is intended for system administrator to find the objects containing references to a selected object.
In this mode the user can select an object and view a list of the references to this object contained in other infobase objects.
Fig. 56. Find References to Object
Select an object from the Object field and click the Find references button. The system searches for references to the selected object in all the infobase objects where they could be located (determined by the application). When search is completed, the identified references can be analyzed. To open the form of the reference, press the Open button (if available) or click the hyperlink. When you have to search for references to one of the items from the References to the object list, open the context menu (on the row selected) and execute the Find references command. A new window will open for the object reference search and the search for references to the selected object will be performed.
You can switch to other windows and modes without closing the search window.
This tool is intended to post and repost documents in batches and to restore sequences.
You can post selected types of documents belonging to a specified period using Document Posting tool.
Fig. 57. Document Posting
You should specify the period for the documents to be posted in the upper part of the dialog in the Period field. To specify a period, you should either select one of the standard period options or use Custom period and define the period manually. If in the custom period window you will clear both period boundaries, no time limitations will be applied to posting. This will also be indicated by a text to the right from the period selection field.
The dialog window contains the list of document types that can be posted. The list of available documents will only contain the documents types with Interactive Posting right selected for the current user.
The list of the selected documents that should be posted can be edited by doubleclicking or using the Add > (multiple selection available) and Add all >> buttons and the reverse buttons < Remove (multiple selection available) and << Remove all.
Specify which documents you want posted by selecting or clearing the Repost posted documents and Post unposted documents check boxes.
Click the Post button after selecting all the options necessary to execute the posting. Prior to posting the dates of the first and the last posted documents is determined (based on the posting mode and the list of posted documents).
When documents are posted in batch, those documents that are marked for deletion will not be posted even if they meet all the criteria selected in the system batch posting dialog. If an error occurs in the document posting process, the system will behave as specified by the Stop posting if an error occurs. If this option is checked, posting will be aborted upon error but if it is unchecked (default value), posting will continue and the documents posted with errors will be saved.
Once posting is completed, the number of the posted documents will be displayed. If errors occur in the posting process, a form will be displayed containing a list of documents with errors.
Fig. 58. Documents with Posting Errors
If the list only contains one Document posting error line, it indicates that an error occurred in the document posting process but the document itself has not generated any error messages.
Double-clicking the line containing document name will open the document to view it.
In the posting process the status bar will display the real documents posting period, the current posting date and the total number of posted documents.
You can interrupt the documents posting process using Ctrl + Break keyboard shortcut.
All the documents in the 1C:Enterprise form the same time sequence. To make this possible, every document has its own date and time. If two documents have the same date and time, they are still placed in a certain sequence depending on the time when they were entered into the system. You can change a document's date and time. Thus, irrespective of the input order, the documents can be ordered in sequence that reflects a real sequence of the company's business activity events.
When a document is posted in 1C:Enterprise, it performs some actions that will record the document in multiple accounting mechanisms supported by 1C:Enterprise.
The document posting algorithm usually records information contained in a document (in its attributes). However, in some cases, the document posting algorithm also analyzes current totals and uses them in posting. For example, if a document is used to write off goods or materials at average cost, the algorithm analyzes the balance of goods (or materials) at the document time. If goods or materials are written off using the LIFO or FIFO methods, the posting algorithm will analyze the current balance of goods (or materials) by lots (at the date/time of the document).
Obviously, the documents that use totals data in posting (for example, for lots) should be posted in a strict sequence. However, it often becomes necessary to input or correct some documents post factum, due to human errors or document delays. In this case, posting of register records performed by all future documents (that happened after the corrected document) will be considered incorrect. For example, if it turns out that a receipt that was entered at the beginning of the month contained the wrong amount of goods, it is necessary to re-analyze all subsequent outcome invoices that write off available lots and to re-write the register records. That is, all the documents that analyze the balance and are positioned after a corrected document should be reposted.
You should use documents sequences to check if documents should be reposted automatically. Each documents sequence that has been input in the configuration provides control of the posting order of these documents. Therefore, there may be multiple independent sequences in the system.
The Restore Sequences mode makes it possible to automatically repost all the documents related to the sequence from the current position of the sequence boundary to a specified moment. The current position of the sequence boundary is defined by the date that marks the beginning of the period where you should restore the documents posting sequence.
Fig. 59. Restoring Document Sequence
The table lists all the sequences in the configuration that the current user is granted Edit rights for. The current position of the sequence boundary is shown for each sequence in the Boundary column of the table. You can click the Restore all button to restore all the sequences.
Click the Restore button to restore sequences. The system will repost all the documents belonging to the selected sequences starting from the position of the earliest boundary of the selected sequences and up to the specified position (inclusive). If multiple sequences are selected (using multiple selection), all the selected sequences will be restored ordered same as they are in the list. If a single sequence is selected, this sequence will be restored only.
The Stop sequence restoration if an error occurs checkbox determines system behavior for when an error is discovered when a sequence is restored. If it is unchecked (by default), the error will not abort the entire process, i.e. the remaining selected sequences will be restored. Otherwise the process will be aborted when any error is discovered.
You can interrupt the sequences restoration process using Ctrl + Break keyboard shortcut.
This service is intended to enable performance of required scheduled actions on the registers available in the application. These actions include toggling use of totals on or off, totals recalculation, working with aggregates, etc.
There are two sets of possibilities in totals management:
Frequently used features (opened by default) – this mode provides simple tools to perform the most frequent actions on totals of registers;
All available features – this mode provides full access to operations on totals and application aggregates.
This list includes only the accumulation and accounting registers for which the current user has the Totals control right enabled. Another condition is mandatory to include them in the list: all separators of which they are part (if there are any separators in the applied solution) are used for these registers in the current session. Both totals management modes work with this list.
Use the hyperlink at the bottom right of the window to toggle the use mode. When the window is closed, the current mode is stored for the window to be opened in the same mode next time.
The details on both modes are provided below.
The list of frequent features includes the operations of specifying calculated totals period, enabling totals use mode, aggregates rebuilding and filling and operation of getting optimal aggregates.
Fig. 60. Totals management – frequently used features
This operation is intended to specify calculated totals period for all the accumulation and accounting registers with totals enabled. For accumulation registers the period would be specified at the last day of the previous month because accumulation registers are most frequently used to obtain current balance. At the same time for an accounting register the period would be specified at the last day of the current month because accounting registers are most frequently used to obtain turnovers for the current month.
This operation can be used in the beginning of each month to improve registers performance.
This operation is intended to enable use of totals for all the registers with disabled totals except for the turnover accumulation registers that are in the aggregates mode.
This operation may be needed when an operation of batch registers data edit that disables totals to improve processing time, fails.
This operation performs rebuild and fill actions for all the turnover accumulation registers with aggregates mode enabled and their use selected.
For details on using the aggregates, see "1C:Enterprise 8.3. Developer Guide".
This operation can be used as a scheduled operation when aggregates are used.
This operation calculates optimal aggregates for all the turnover accumulation registers with aggregates specified in the Designer.
This operation can both be used prior to enabling aggregates use and in the process of operation.
The All available features mode is intended to provide full access to all the tools involved in managing totals (Totals tab) and aggregates (Aggregates tab) of the accumulation registers and accounting registers. Totals Management
The Totals tab provides a list of information, accumulation, and accounting registers (for which the totals use is enabled) available for that user.
Fig. 61. All Totals Management Operations
The list displays the current state of the system registers. The modes that are currently enabled for every register are checked: Totals – current state of totals use
Current totals – state of current totals use
Minimum totals period – current date of minimum totals relevance period
Totals period – current totals relevance date
Totals splitting – totals splitting mode state
Aggregates/Totals – current state of aggregates or totals use for turnover accumulation registers that have aggregates specified in the Designer
Those modes that cannot be modified in the current system state are grayed out. For example, gray color in the Totals splitting column means that splitting of totals is disabled for the selected register in the Designer.
Using the required commands you can enable and disable respective modes and calculate certain totals.
Multiple selection mode is available for all the commands. This means that a command being executed will be executed for all the selected registers. If an error occurs upon command execution, further system behavior depends on the state of the Stop the data processor on the first error checkbox. If it is unchecked (default value), command execution will not be aborted (if an error occurs) and all the selected registers will be processed. Otherwise processing will be aborted.
If a register is able to operate in the aggregates mode, double-clicking the contents of the Aggregates/Totals column will take you to the Aggregates tab where the cursor will be positioned at the register named same as the one at the Totals tab. Aggregates Management
The tools available at the Aggregates tab are intended to manage aggregates of turnover accumulation registers (for details on the aggregates, see the "1C:Enterprise 8.3. Developer Guide").
Fig. 62. All Aggregates Management Operations
The upper list contains all the turnover accumulation registers of the current configuration with aggregates specified in the Designer. The lower list Register Aggregates <register name> (<register type>) contains all the aggregates specified for the register, flag of using this or that aggregate and statistics on the aggregate.
It is possible to toggle register use mode, change aggregates use flag and perform the major operations on the aggregates.
When optimal aggregates are calculated, you will be prompted to specify the directory for the file containing the list of optimal aggregates for the selected register. The register will be displayed in bold if it is recommended to replace the existing aggregates by the calculated list of optimal aggregates.
For optimal aggregates saving, the file name will be generated as follows: AggregateName.xml. For example, the file of optimal aggregates for a register named Sales in the fig. 62 will be named as Sales.xml.
1C:Enterprise allows arranging for full text search in data. Search availability and the forms to enter search criteria are designed at the configuration development stage. The system enables full text search management.
Fig. 63. Full Text Search Management Mode
The Full-text search switch enables or disables full text search. To perform this action, exclusive access to the infobase is required. This means that you can enable (or disable) full text search only when a single user works with the infobase.
After pressing the Update index button, the system generates search index. To optimize the index generation process, both the basic and additional indices are used. The additional index is generated during data input and contains the information on the data entered after the last update of the basic index.
You can clear indices (clicking the Clear index button) to delete an index, e.g. to free the disc space currently taken by the index files. After an index is cleared, indexing should be performed (if required).
The buttons in this dialog window are only available if the current user possesses the Administrative Tasks right.
The Index created on field contains start date of the last indexing.