History in 1s 8.3 where to find. Data history

In the process of the enterprise, it is often necessary to find out who, when, and what exactly has changed in the document or program guide.

Very often they ask me questions:

• How to see the changed document in 1C 8.2?
• How to see the changed document in 1s?
• How in 1C to find out who changed documents when?
• How to find out in 1C who changed the wiring in the document?
• How to see who changed the document in 1s?

Logbook

It contains information about what events occurred in the infobase at a certain point in time or what actions a particular user performed. For each journal entry that reflects a change in data, the transaction completion status is displayed (transaction completed successfully, or transaction canceled).

The logbook is available both in 1C: Enterprise mode and in Configurator mode.

Access to the logbook is possible both from the Configurator mode (via the menu Administration - Log Book), and from the Enterprise mode (menu Service - Registration Journal) In Taxi mode ( Main menu - All functions - Standard - Logbook)

Log Type   (Ordinary Forms and Taxis):

Selection in the logbook   (Ordinary Forms and Taxis):

Using the tools for working with lists, it is possible to upload the logbook to a spreadsheet or, if necessary, a text document (through Actions - List), which can later be saved, for example, in Excel, TXT or HTML format. At the same time, it is possible to adjust the level of events that will be recorded in the logbook, as well as the frequency of log splitting into separate files (in the menu configurator mode   Administration - Configure Logging).

And there it is also possible to reduce the number of entries in this journal to a certain date, which is done to speed up work with the mechanism for analyzing and recording events in the system or for the uselessness of irrelevant information.

Where is the log kept

In the File Database:   in the base directory the folder 1Cv8Log -this is the directory containing the logbook.

If you plan to transfer the file database and want to save the history of the registration log & you definitely need to copy the 1Cv8Log folder to the category of the new 1C database. If you need to clear the 1C log in the file base, just delete the 1Cv8Log folder.

INClient-server base: C: \\ Program Files \\ 1cv8 \\ srvinfo \\<Имя кластера сервера>\<Идентификатор базы на сервере>\\ 1Cv8Log

From version 8.3.5.1068. Significantly redesigned the logbook in order to increase the speed of queries to the log and increase the reliability of data storage.

For this, including, it was required to change the storage format of the logbook. Now it is stored in a single SQLite database file. This file has the extension lgd.

Versioning Objects

In some 1C configurations, a special mechanism “Versioning of objects” is introduced.

Versioning is off by default, to enable open Service - Accounting Settings - Accounting Settings

Using the “Configure Object Versioning” button, we select which directories and documents need to be versioned (observe who changed what, when).

By default, objects of the information base are not monitored, so the sign “Do not version” is set opposite each type of document. If you want the monitoring to be carried out, you need to install "Versioning" opposite the document journal of interest.

Everything, when you close the window and click on the "OK" button, objects will be monitored.

In order to view all the changes that someone made in the document or reference book, go to the menu: Service - Object Change History

How to get a quick answer, which user could change the data in the program according to the document? What exactly did he change? So that this answer is as fast as possible and any user could get this answer without contacting the system administrator.

In a typical configuration, production enterprise 1.3 management (SCP) has a module for working with versioning of objects. It allows you to store in the current database all the changes that users make with directories and documents. This subsystem allows you to selectively indicate which types of directories and documents to use, and which not.

In general, the main problem of this tool is that this data in the database grows so strong that the amount of data becomes comparable with the size of the history storage for it. For large bases, this becomes a catastrophic problem.

How long does it take to find the reason who changed what? How many comparisons are needed when, for example, it is stored in the history that the document was changed 30-100 times? But a simple record during group holding of documents will add a version of changes here, and in fact nothing in the document will change with such a re-entry. In general, out of this number of versions, changes from force will be valid 2-3-5. What about the rest? And this is excess garbage.

In general, the system is good, it allows you to record changes in detail. But here's how to use this data further is not very convenient. In most cases, when users come to find out who in the database changed the administrator 1s, uses this report and determines these things.

How to turn this into a quick tool for finding an answer, who has changed what?

“Tell my light to the mirror, but report the whole truth” ...

By the logic of things, our refinement does not cancel the versioning block. Developed its own system of operational control of who changed what. Versioning can work in parallel. The system is called "History of the change of directories and documents." This is a pretty simple system to use, necessary to quickly get an answer who changed the document, reference.

Actually, the purpose of this system is simply to quickly inform who changed the document and when. A detailed answer of what the user has changed is not always needed. In other words, here is a simple analogue of the "logbook", which also tells when and who performed the action. But the user’s access to it is much faster. It’s inconvenient to work with a typical logbook, and with a huge amount of data it’s not even possible to get a quick answer. And here the register is in the database itself and immediately gives an answer. Moreover, just one button "History" in the document itself (!).

Any user can quickly see who worked with the document. And already, if you need an answer what exactly this user did with it (as an evidence base), then you can already use the full data on the versioning system.

“If something can be proved by deed, then there is no need to waste words”
Aesop

“Whose shoe?”

Also in our system there is one more possibility - it is maintaining the history of changes in the tabular part of warehouse and production accounting documents, as well as pricing documents. In particular, in most cases, when keeping records, the history of changes in the tabular parts “Goods”, “Materials”, “Products” is of interest.

How it works? Suppose you want to get the answer: when what date is the new price set? Who deleted the line in the move document? Who replaced the nomenclature with another nomenclature? Who removed the quantity? Who set the discount? Who changed the price? You can see who changed the type of prices in the document.

In this case, in the current system, when recording changes, a comparison is made with the data of the history previously recorded and only what has changed is recorded in the history. No redundant history storage.

Change Report

This entire protocol is visually presented in the form of a report “Report on changes in the tabular parts of documents”. This report opens only by pressing one button “History” in the document and immediately shows by what nomenclature what was changed and most importantly by whom and when. Actually this report instantly allows you to get an answer to the above questions. And without the participation of the administrator 1s.

« The true properties of man are discovered only when the time comes to prove them in practice. ”
L. Feuerbach

Remuneration of operators

In the future, there is continued use of this data on changes to directories and documents. There is a report “Report on changes to directories and documents”. It allows you to see by users who how many actions with directories and documents (created a new, changed, spent). Moreover, this report has inherent functionality even in calculating wages. The rate for changing one object is set (for each separately) and the report will show the amount of, for example, how much the operator has earned.

In detail

“There are questions for which there are no answers; but there are answers that cause a lot of questions”
E. Sevrus

This processing works in configurations of soft starters 1.3, UT10.3. And it can also be integrated into any 1c configuration, where there are warehouse and production records. Works on regular forms.

Conclusion

There are many options for storing information histories on the market. There is where even storage is implemented in a separate database. It is possible that it is implemented much better and more universally. To give a quick answer was the main thing for us. So that any user (storekeeper, operator, accountant) does not waste time answering, but receives it instantly. And one more condition is the further use of data in calculating the wages of users.

The log in 1C 8.3 is very useful in that it displays events that occurred in the infobase with the time, computer name and user name and links to mutable data. When authenticating users, logs are also created in the log indicating the way to enter the program. This mechanism allows you to answer one of the most common questions - who last made changes to a particular object.

Where to find the registration log in 1C 8.3? Through the menu “All functions” - “Standard” or, in typical configurations 1C, in the menu “Administration” - “Support and maintenance”.

Setup of the logbook is performed in the configurator mode. In the "Administration" menu, select "Configure logging."

Here you can configure the events that will be displayed in the log.

Selecting the first setting item allows you to not keep a log at all. The remaining settings are arranged in increasing order of importance. With a large number of users, it is not recommended to register notes so as not to clutter the database.

When creating a new infobase, the default mode is to register all events.

View and search entries

When you open the registration journal itself, at first glance it may seem that there is a lot of information and finding it is simply unrealistic. This is actually not the case.

By default, 200 entries are displayed in the logbook. Displaying a large number of records can adversely affect the performance of your program or it will simply hang.

In the form of a list of the logbook, you can set the selection and use the search. The search is superimposed only on records that are already displayed (in this case, the last 200 events). Selection applies to all records.

The search is carried out according to the displayed data in the tabular part, so when using it, you only need to specify the column and the data that you need to find.

The selection allows you to select data for specific users, computer names, events, etc. Also, you have the opportunity to display log entries only for specific metadata, data (a link to the desired object, for example, a specific document is indicated) and other settings.

This example shows the settings of the log for the selection of all events of the Admin user, starting from 06/20/2017.

Where is the 1cv8.lgd log file stored

The location of the physical storage of the log is directly dependent on whether the file base or the client is server.

File base

With this placement mode, the logbook is located in the folder with the database itself. Its location can be found either from the list of databases, or from the Help "About the program."

If you go to this address, you will find a folder with the name "1Cv8Log". This is where the log data in the 1Cv8.lgd file is located.

If you need to transfer the database from one place to another, you can copy this directory in the same way, then the data in the logbook will be transferred along with the database.

If you delete this directory, the log will be cleared.

Client-server base

In this mode, everything is the same as in the previous one, only the 1C log data is stored on the server. Most often, its location is as follows:

• C: \\ Program Files \\ 1cv8 \\ srvinfo \\<место расположения информационной базы>\\ 1Cv8Log

Optimization

The registration log can be optimized if necessary, especially when a large number of events occur in the database.

One way is to configure only certain events to be recorded above. For example, there is no need to track notes if you simply do not need them.

In older releases of the platform, in the settings of the logbook, separation of the logbook by periods was available. The entire magazine could be divided into separate files with the specified frequency (day, month, year, etc.).

Starting from the platform version 1C 8.3.5.1068, the log is stored in the sqlite database file with the extension * .lgd, and this setting has become unavailable. This method of storing the logbook is much more productive than the old one.

How to reduce or delete the log in 1C

If it is necessary to partially or completely clear the log entries in the settings window, click on the “Reduce” button. In the window that appears, specify the date by which all entries must be deleted. Also deleted records can be saved to a file just in case.

How often does your company need look who modified the 1C document?

Or how to find out which of the workers changed one or another props   Document 1s 8?

How to watch 1C document change history?

Module “History of changes” based on 1C 8

Convenient and quick tool   analysis and control   user actions 1C.

Tasks solved by the module “Change History”   1C 8:

• Exception of opportunity   fraud   retroactive users of documents;
• Identification of the culprit erroneous data   into documents;
• Identification Capability program malfunctioning   in terms of automatic change or resubmission of documents;
• Identification intentional distortion (change) of data, for example, entering incorrect customer contact information by unscrupulous managers;
• Opportunity   see what happened   with a document or directory before changing it and, if necessary, return everything back.

The advantages of the mechanism “Change History”   1C 8:

• All data is stored inside the 1C database, which ensures   high search speed   necessary information and building the necessary reports.
• Module 1C 8 “Change History” has minimal impact on performance. You will practically not feel the difference when working with and without our subsystem.
• Module   universal   and easy to integrate   in any, even standard, system-based configuration « 1C: Enterprise   version 8.2   and versions 8.3 including version.

Module features:

The module allows you to flexibly configure objects for which control will be conducted.

Viewing the history of data changes is possible directly from the document or directory form and is available to users who have the appropriate rights.

Changes in the details of directories and documents fall into the control mechanism. At the same time, both the old and the new value of the props are preserved.

A mechanism for controlling changes in the lines of 1C documents is available. For example, changes in prices, quantities, and other data are displayed on a particular line.

There is the ability to see deleted and added lines in the tabular parts of documents. In this case, the program will ignore the change in the sorting of lines within the document, which is actually not a change in data. For clarity, in the report on the changed data, the added lines are colored in blue and the deleted ones in pink.

Registration Journal 1C 8.

How to find out who changed the 1C document?

It would seem that everything is simple - you can see who modified the 1C document in "Journal of registration". Indeed, it records events related to changes in the database objects, as well as events that occur when working with the database (user input and output, errors, reporting). So the magazine gets very a lot of extra entries, because of which the volume of the magazine is growing rapidly and having problems   and with the storage of the magazine, and with the search in it for really useful and necessary information.

But the biggest minus of a standard magazine   registration- the inability to find out what exactly was changed in the object: the requisite or line in the tabular part - you will not find the answer. And you certainly won’t know what data was before the change and what became after.

It is also impossible to configure the built-in log so that from an open document or directory it would be possible to see the entire history of changes in 1C 8 with the click of a button. Such manipulations require a rather complicated, for an unprepared user, setting up selections in the log.

Module   “Change History”   - This is a convenient and operational tool for analyzing and monitoring the actions of 1C users.

To Module "History of changes" 1C 8 started to do his job, it needs to be set up once. The setup does not require much time and involves the selection of documents, directories, as well as their details, which will be monitored and stored history of changes.

The cost of the module depends on the need for services for its installation and configuration. FROM contact us in any convenient way and find out the cost.

This article is an announcement of new functionality.
   It is not recommended to use the contents of this article to learn new functionality.
   A full description of the new functionality will be given in the documentation for the corresponding version.
   A complete list of changes in the new version is provided in the file v8Update.htm.

Implemented in version 8.3.11.2867.

We have implemented a new mechanism, data history, which compactly stores the history of changes in application data by users. Using ready-made interface solutions or using the built-in language, you can now flexibly analyze data changes, compare different versions and restore the data to the state that they had in the selected version.

What scenarios do you need to work with data history

Most often, accessing the data history is required in order to identify the user who made some change. For example, a product was sold to a counterparty with too much discount, and now I want to understand who established such a discount. Or another situation where the price of the goods looks right, but in the past there was a sale of this product at a lower price. You need to find out who changed the price, and then returned it to its previous value.

Another situation in which a history of data is needed is that at the moment, the value of a certain attribute in the accounting system is set so that it leads to negative consequences. It is necessary to find out when exactly this value was installed, and which user installed it.

For further analysis of the situation, you may need to find out all the changes that were made by a certain user who once did something wrong. Because in other cases, he could have made a similar mistake.

Finally, after all inappropriate changes are found, there may be a natural desire to restore the previous, correct, state of the data, or even restore data that was directly deleted.

In all of these scenarios, I want these features to be achieved with minimal loss of performance and disk space.

So that it doesn’t turn out that the history of changes in objects takes up more space than the useful objects you work with. Or so that it doesn’t work out that providing this functionality leads to a significant slowdown in user experience.

It is clear that it is impossible to completely remove performance losses, because instead of one action, you must perform two: save the object and still save its history. But at the same time, I want these losses to be imperceptible.

There is another feature that is not related to functionality, and not to technical requirements, but to the specifics of the 1C: Enterprise market. You can come up with a very good mechanism, which will work quickly, and the functionality will be great. But if significant technical knowledge is needed to configure, enable and maintain it, this can negate all its advantages.

Therefore, the administration of such a mechanism should not be difficult for both the developer and the administrator of the information base. Indeed, in small file deployments, the administrator is often one of the users, and sometimes the only user of this application solution.

What opportunities for analyzing history already exist in the platform

The main tool that you can use to analyze what is happening in the system is the logbook. Among other things, it records facts of data changes. That is, you can find out who and when changed the data of an object. But his possibilities in the area under discussion end there, because according to the registration log it is impossible to understand exactly which props were changed, what was his previous state. And even more so, it is impossible to restore the previous state of the props or the entire object using the registration log.

Another tool that has existed for a long time and is in all circulation solutions is BSP - a library of standard subsystems. It has a subsystem for versioning objects. This subsystem contains all of the listed functions, but it has some practical limitations.

Firstly, it is part of the library, so its implementation in the application solution requires the participation of a qualified developer. It is good if BSP is initially present in the application solution. But if it is not there, the administrator, or, especially, a qualified user, will not be able to implement it on their own.

Secondly, the task of maintaining a history of data itself is a low-level task, and it is more efficient to solve it in the technological layer of the platform.

Platform Advantages

When we analyzed the current situation, the experience of using BSP, weighed the pros and cons, we came to the conclusion that the most effective solution would be to implement the data history within the technological platform itself. This will achieve the following benefits:

• To use this mechanism, the administrator or user does not have to change the configuration; everything necessary is already in the platform. You just need to turn it on.
• This mechanism will work faster than the analogues implemented as part of the configuration, as he will use features not available from the built-in language.
• The data history itself will take up less space, since not a copy of the data will be stored, but only their difference with the previous version. In addition, versioning itself can not be applied to all the details, but only to those that are of interest. This will also provide additional savings.
• It will be possible to support versioning of not only those objects that have a unique reference (directories, documents, etc.), but also objectless entities, such as records of information registers, for example.

Mechanism Basics

The data history mechanism is fully implemented within the platform, does not require any installation of additional software, is ready to work at any time, but, by default, is not turned on.

You can enable it both in the configurator and in 1C: Enterprise mode. In the configurator, this can be done by the developer, in 1C: Enterprise user mode, using processing written in the embedded language.

The “inclusion” of the mechanism is to indicate for which particular configuration objects the change history will be kept. Moreover, the history can be included not only for the whole object, but also for its individual components: details, measurements, resources. Including for details of tabular parts. Thus, you can choose: store full information, or save space.

We implemented the storage of history for directories, documents, tasks, business processes and information registers. Perhaps in the future we will expand this list.

We store historical data in separate tables of the infobase. For efficiency, we only store the difference between the versions of the data. If you have a “heavy” document with a large number of lines in the tabular section, and you change only one attribute in the document itself, then only this change will be saved in the data history. That is, you will not be stored many copies of this object, and take up disk space.

In addition to data changes, we also store object metadata at the time of writing the version. This is necessary in order to correctly build reports on objects that were recorded in a different configuration state. For example, when some details were called differently, there were no other details, and still others were present, but were subsequently deleted.

Data Change Processing

The process of creating a data version consists of two steps. First, when you record an object (for example, a document), a special message is generated, which is placed in the queue. This stage is performed by the platform, the developer is not involved in it.

But the second stage is initiated by the developer. The second stage is that when processing the queue, this data is extracted, placed in the version store, and becomes available for working with them.

In order to process the queue in this way, the data history manager ( ManagerData Stories) there is a method Refresh History (). We assume that you will use it in the same way as a similar method designed to update the full-text search index. That is, you will update the history in a certain scheduled task, which is carried out with a certain frequency.

We believe that as a result of such asynchronous operation both efficient recording of objects and minimization of performance losses will be provided.

User interface

In the 1C: Enterprise user interface, a new mechanism is called Change history. It includes several forms that allow you to perform the actions that were listed at the beginning of this article.

List of versions for a specific object

If history recording is enabled for an object, a new command appears among the standard commands of the object Change history.

It allows you to see a list of all changes (versions) of the object.

In a collumn A source changes   the exchange plan node may also be indicated if the change was made in the node and “arrived” to this database as a result of data exchange.

In this list, in the column