Главная Госучреждения V8: История изменения реквизитов. Кто изменил справочник или документ в базе? Версионирование объектов в 1с

V8: История изменения реквизитов. Кто изменил справочник или документ в базе? Версионирование объектов в 1с

Версионирование объектов стало доступным, начиная с редакции «3.0.35» в программе «1С Бухгалтерия 8». Новая функция позволяет отслеживать все изменения в документах и справочниках. Версионирование не просто хранит информацию об истории изменений, как это было в журнале регистрации, а позволяет бухгалтеру на правах администратора пересмотреть внесенные изменения, увидеть все версии объекта, сделать сравнительную характеристику версий между собой, а также вернуться к предыдущей версии.

Как настроить версионирование объектов в бухгалтерской программе?

Для того чтобы включить механизм версионирования объектов в программе, перейдите на закладку под названием «Администрирование», затем выберите раздел «Поддержка и обслуживание» и возле «Версионирование объектов» поставьте галочку.

Программа дает возможность установить следующие варианты:

«Не версионировать» - в этом случае история версий объекта вестись не будет;

«Версионировать при записи» - в случае создания или изменения нового документа или справочника новую запись будет занесено в историю версий;

«Версионировать при проведении» - следует отметить, что данный вариант можно использовать для документов, которым вы разрешили проведение. После первого проведения первоначальная версия будет сохранена в истории;
«Версионировать при старте» - данный вариант предназначен только для бизнес-процессов. Только после старта бизнес процесса будет записана его первая версия.

«По умолчанию» - в этом случае для справочников и документов устанавливаются рекомендованные настройки - «Не версионировать» и «Версионировать при проведении» соответственно.

Программа позволяет установить срок хранения за последнюю неделю, один, три, шесть месяцев, год или вообще бессрочно.

Для каждого вида документа и элемента справочника можно отметить свой срок хранения или вариант версионирования.

При необходимости нажмите на синюю гиперссылку и посмотрите объем и количество необходимых версий объектов, или настройте подробное расписание для ликвидации старых версий. Для этого установите галочку под названием «Автоматически удалять устаревшие версии», а затем, используя синюю гиперссылку «Настроить расписание», создайте нужное расписание. Последнее можно настроить, задав однодневное, недельное или месячное расписание.

Как просмотреть изменения объектов в бухгалтерской программе «1С Бухгалтерия 8»?

Установив галочку в разделе под названием «Версионирование объектов» в справочниках и документах, для которых действует версионирование, вы получите доступ к пиктограмме «История изменений».

Нажав на последнюю, вы получите доступ к версии конкретного объекта, где будет содержаться вся необходимая информация: кто менял объект, когда и какие изменения произошли.

В верхней части окна откроется доступ к таким клавишам:

«Открыть версию» - с помощью этой кнопки в нужный момент времени вы сможете посмотреть отчет о состоянии объекта;

«Сравнить версии» - можете посмотреть отчет по изменению состояния выделенных предварительно 2 или более версий в списке (какие реквизиты отличаются, будет видно в отчете);

«Перейти на версию» - сделает возврат к предварительно выделенной одной из версий объекта. При этом будут отменены изменения, которые были внесены после сохранения данной версии.

Обратите внимание, при изъятии объекта версионирование не поможет, так как после удаления вся история объекта также будет ликвидирована.

Каким образом получить быстрый ответ, какой пользователь мог поменять данные в программе по документу? Что именно он изменил? Чтобы ответ этот был максимально быстрым и этот ответ мог получить любой пользователь без обращения к администратору системы.

В типовой конфигурации управление производственным предприятием 1.3 (УПП) присутствует модуль по работе с версионированием объектов. Он позволяет хранить в текущей базе все изменения, которые производят пользователи со справочниками и документами. Данная подсистема позволяет выборочно указывать, по каким видам справочников и документов это использовать, а по каким нет.

В целом основной проблемой этого инструмента выступает то, что эти данные в базе вырастают настолько сильно, что объем данных становится сопоставим с размером хранения истории по ним. Для больших баз, это становится катастрофической проблемой.

Если бы только в этом была проблема. Дело еще заключается в том, что в дальнейшем эти данные достаточно трудно использовать пользователям. Оперативно посмотреть информацию, что изменилось затруднительно. Да, существует отчет «История изменений объектов». В нем можно указать объект, по которому мы хотим посмотреть историю и дальше можно сравнить по списку с одним из изменений.

Сколько потребуется времени для того, чтобы найти причину кто что изменил? Сколько нужно сделать сравнений, когда, допустим, в истории хранится, что изменили документ 30-100 раз? А ведь простая запись при групповом проведении документов сюда добавит версию изменений, а ведь по-сути ничего в документе не изменится при таком перепроведении. В целом из этого количества версий изменений от силы будут действительны 2-3-5. А остальное что же? А это избыточный мусор.

В целом система хорошая, позволяет детально зафиксировать изменения. Но вот как этими данными дальше пользоваться не очень удобно. В большинстве случаев, когда приходят пользователи на выяснить кто что в базе на менял этим отчетом пользуется администратор 1с и определяет эти вещи.

Как это превратить в быстрый инструмент для нахождения ответа кто что изменил?

«Свет мой зеркальце скажи, да всю правду доложи»…

По логике вещей наша доработка никак не отменяет блок версионирования. Разработана собственная система оперативного контроля кто что менял. Версионирование может работать параллельно. Система называется «История изменения справочников и документов». Это довольно таки простая система в использовании, необходимая для быстрого получения ответа кто изменил документ, справочник.

Как работает эта система: при записи каждого справочника или документа в регистр сведений записывается история, кто создал документ, кто его провел, удалил. При этом еще и добавлены в документы дополнительные условия: кто документ отгрузил, кто снял с отгрузки в случае использования системы контроля отгрузки. Здесь эту линейку можно расширять и дальше. Допустим для кадрового учета: кто документ отдал на подпись, и когда пришло с подписи. Еще здесь можно при желании даже организовать учет, кто когда документ распечатал и какую печатную форму. Вариантов здесь можно использовать много и хранить историю изменений статусов документов.

Собственно цель данной системы просто быстро сообщить кто менял документ и когда. Подробный ответ, что именно изменил пользователь, не всегда нужен. Другими словами здесь простой аналог «журнала регистрации», который также сообщает, когда и кто произвел действия. Вот только доступ к нему у пользователя происходит гораздо быстрее. С типовым журналом регистрации работать неудобно, а при огромном объеме данных бывает даже не реально получить быстрый ответ. А здесь регистр находится в самой базе и сразу дает ответ. Причем всего по одной кнопке «История» в самом документе (!).

Любой пользователь оперативно может посмотреть: кто с документом работал. И уже, если понадобиться ответ, что конкретно с ним сделал этот пользователь (как доказательную базу), то уже можно использовать полные данные по системе версионирования.

«Если что - то можно доказать делом, то на это незачем тратить слова»
Эзоп

«Чей туфля?»

Также в нашей системе присутствует еще одна возможность – это ведение истории изменения табличной части документов складского и производственных учета, а также документов ценообразования. В частности в большинстве случаев при ведении учета интересует история изменений табличных частей «Товары», «Материалы», «Продукция».

Протоколируются изменения в разрезе каждого документа по дате изменения, ответственному лицу кто внес изменения, номенклатуре, характеристике и серии номенклатуры, типу цен, месту хранения (если используется места хранения), количество, цена, сумма, скидка, единица измерения мест.

Как это работает? Допустим нужно получить ответ: когда какого числа установлена новая цена? Кто удалил строку в документе перемещения? Кто заменил номенклатуру на другую номенклатуру? Кто удалил количество? Кто установил скидку? Кто поменял цену? Можно увидеть, кто поменял тип цен в документе.

При этом в текущей системе при записи изменений происходит сравнение с данными истории ранее записанной и в историю записываются только то, что изменилось. Нет избыточного хранения истории.

Отчет по изменениям

Весь этот протокол визуально представлен в виде отчета «Отчет по изменениям табличных частей документов». Этот отчет открывается всего лишь при нажатии одной кнопки «История» в документе и сразу показывает по какой номенклатуре, что было изменено и самое главное кем и когда. Собственно этот отчет мгновенно позволяет получать ответ на вышеуказанные вопросы. Причем без участия администратора 1с.

«Настоящие свойства человека обнаруживаются лишь тогда, когда приходит время доказать их на деле»
Л.Фейербах

Оплата труда операторов

В дальнейшем есть продолжение использования этих данных по изменениям справочников и документов. Существует отчет «Отчет по изменениям справочников и документов». Он позволяет увидеть по пользователям кто сколько со справочниками и документами произвел действий (создал новый, изменил, провел). При этом этот отчет имеет в себе заложенный функционал даже по расчету оплаты труда. Задается расценка за изменение одного объекта (для каждого в отдельности) и отчет покажет суммы, сколько, допустим, оператор заработал.

Чтобы просчитать тарифы, в отчете заложен механизм предварительной оценки. По галочке «Производить предварительный расчет» можно указать суммы ФОТ и количество участников (операторов, пользователей). После сформированных данных будет предоставлена информации, сколько может в среднем стоить изменение одного справочника или документа. Далее в закладке «Тарифы» можно конкретно заложить и уже выводить отчет-расчет для получения сумм оплаты.

Детально

«Существуют вопросы, на которые нет ответов;, но есть ответы, вызывающие массу вопросов»
Э.Севрус

Для проверки данных кто, что менял существуют в обработке следующие закладки «История изменения справочников». «История изменения документов», «История изменения табличных частей». Это и есть наши протоколы хранения истории изменений. В конце в закладке «Отчет-версии» в случае использования более детального версионирования можно смотреть какие-то спорные моменты. В целом этот АРМ используется именно для анализа объема работы пользователей и расчета оплаты по изменениям данных в базе.

Данная обработка работает в конфигурациях УПП 1.3, УТ10.3. А также может быть интегрирована в любую конфигурацию 1с, где присутствуют складской и производственный учет. Работает на обычных формах.

Вывод

На рынке существует множество вариантов хранения историй информации. Есть где даже реализовано хранение в отдельной базе. Возможно, что и реализовано гораздо лучше и универсальней. Дать быстрый ответ – вот главное для нас было условие. Так чтобы любой пользователь (кладовщик, оператор, бухгалтер) не тратил время на ответ, а получал его мгновенно. И еще одно условие – это дальнейшее использование данных в расчете оплаты труда пользователей.

Ключевые слова: Регистрация, история, изменение.

Эта статья является описанием озвученного в третьего алгоритма.

Речь о том, чтобы хранить в базе историю изменения реквизитов объектов.

Объекты в данном случае - это справочники, документы, планы обмена, планы видов характеристик и т. д., в общем то, что вводится пользователем вручную, для чего требуется хранить историю изменения реквизитов и на что можно сделать ссылку.

Состав объектов произвольный и определяется программистом, то есть можно, к примеру, настроить механизм только для всех справочников и выборочных документов.

Общая идею проста, как четыре рубля одной монетой.
А вот при ближайшем рассмотрении выяснилось пара нюансов.
А при превращении мыслей в статью и вовсе все поменялось.

Начнем по-порядку.

Для начала, делаем периодический регистр сведений "История реквизитов" без привязки к регистратору.

Затем, очень хочется иметь в этом регистре сведений измерение "Объект" типа "Любая ссылка", но этого делать нельзя.
Причина та, что тогда мы теряем возможность удалять помеченные на удаление объекты, поскольку на них будут ссылки в регистре.
Если же это измерение делать ведущим, то при удалении мы потеряем всю историю по этому объекту, которая удалится вместе с самим объектом.
А с другой стороны и без этого реквизита совсем уж никуда, ни отчета сформировать, ни просто даже объект найти.
Поэтому, в каждый объект, для которого требуется регистрация изменений реквизитов, добавляем реквизит "GUID" типа "Строка (32)".
Кроме того, в регистр сведений "История реквизитов" добавляем измерение "GUID объекта" типа "Строка (32)".

Так я хотел написать сначала.

А потом хорошо подумал.

Во-первых, очень плохо делать разные соединения с таблицами объектов в запросах, чтобы получить нужный объект по реквизиту "GUID".

Во-вторых, журнал регистрации фирмой 1С реализован таким образом, что в нем в реквизите "Данные" хранится именно ссылка на объект, а никакой не GUID.
Просто при удалении объектов журнал регистрации не участвует в проверке ссылочной целостности и после удаления объекта в нем в реквизите "Данные" показывается знакомая многим надпись "<Объект не найден> ...".

В-третьих, GUID вместо ссылок придется тогда вставлять и в остальных полях, то есть в пользователе, старом значении и новом значении.

В-четвертых, дешевле сделать свой алгоритм удаления помеченных объектов, нежели так изголяться.
Тем паче, что типовой алгоритм крайне скуден.

Правда, в рамках данной статьи описывать альтернативный алгоритм удаления помеченных объектов я не буду, ограничусь лишь тем, что скажу, что этот алгоритм должен при удалении помеченных объектов в регистре сведений "История реквизитов" все ссылки на удаляемые объекты заменять пустыми ссылками.
Почему пустыми?
Да все просто, чтобы ссылочная целостность базы не нарушалась.

Поэтому добавляем измерение "Объект" типа "Любая ссылка".
Вместо типа "Любая ссылка" можно проставить галочки у конкретных объектов, без разницы.

Продолжаем.

Помимо объекта нужно иметь информацию о реквизите, который меняется.
Поэтому добавляем измерение "Реквизит" типа "Строка (25)" или "Справочник.РеквизитыОбъектов", кому как больше нравится.
Я для примера сделал строкой.

Затем добавляем информацию о пользователе, сделавшем изменения.
Для этого добавляем ресурс "Пользователь" типа "Справочник.Пользователи".
Кроме того, добавляем ресурс "Имя компьютера" типа "Строка (25)".
Кому 25 символов мало, может изменить на нужное количество.

Для того, чтобы знать, в какой распределенной базе меняли реквизит, в случае использования распределенных баз, нужно добавить ресурс "Распределенная база" типа план обмена "Распределенные базы".

И, наконец, добаляем два ресурса, "СтароеЗначение" и "НовоеЗначение" составного типа.
В составе типов "Число", "Строка", "Булево", "Дата" и "Любая ссылка".
Размерность типов "Число" и "Строка" проставляется максимальная из возможных, чтобы в нее уместилось содержимое любого реквизита.
Здесь есть досадный момент, в состав типов нельзя включить строку неограниченной длины.
Поэтому механизм нельзя будет применять для строк неограниченной длины, содержимое которых длиннее максимального размера строки в составе нашего типа.

Теперь по поводу настроек в объектах.
Во всех объектах, для которых будет регистрироваться история, требуется прописать следующий код.
Переменная "НаборЗаписейИсторияОбъектов" вынесена в переменные модуля по той причине, что для нового объекта проверку реквизитов нужно делать в процедуре "ПередЗаписью", а заполнять реквизит "Объект" значением "Ссылка" в процедуре "ПриЗаписи", поскольку в процедуре "ПередЗаписью" еще нет ссылки для нового объекта.
Перем НаборЗаписейИсторияОбъектов; Процедура ПередЗаписью(Отказ) НаборЗаписейИсторияОбъектов = РегистрыСведений.ИсторияОбъектов.СоздатьНаборЗаписей(); ОбработатьИзменениеРеквизита(НаборЗаписейИсторияОбъектов, "Код "); ОбработатьИзменениеРеквизита(НаборЗаписейИсторияОбъектов, "Наименование "); ОбработатьИзменениеРеквизита(НаборЗаписейИсторияОбъектов, "Родитель "); ОбработатьИзменениеРеквизита(НаборЗаписейИсторияОбъектов, "Владелец "); Для А = 0 По ЭтотОбъект.Метаданные().Реквизиты.Количество() - 1 Цикл ОбработатьИзменениеРеквизита(НаборЗаписейИсторияОбъектов, ЭтотОбъект.Метаданные().Реквизиты[А].Имя); КонецЦикла; КонецПроцедуры Процедура ПриЗаписи(Отказ) Если НаборЗаписейИсторияОбъектов.Количество() <> 0 Тогда Для Каждого Запись Из НаборЗаписейИсторияОбъектов Цикл Запись.Объект = Ссылка; КонецЦикла; НаборЗаписейИсторияОбъектов.Записать(Ложь); КонецЕсли; КонецПроцедуры Процедура ОбработатьИзменениеРеквизита(НаборЗаписейИсторияОбъектов, ИмяРеквизита) Если ЭтотОбъект[ИмяРеквизита] <> Ссылка[ИмяРеквизита] Тогда НоваяЗапись = НаборЗаписейИсторияОбъектов.Добавить(); НоваяЗапись.Период = ТекущаяДата(); НоваяЗапись.Реквизит = ИмяРеквизита; НоваяЗапись.ИмяКомпьютера = ИмяКомпьютера(); НоваяЗапись.Пользователь = ПараметрыСеанса.ТекущийПользователь; НоваяЗапись.РаспределеннаяБаза = ПараметрыСеанса.ТекущаяРаспределеннаяБаза; НоваяЗапись.СтароеЗначение = Ссылка[ИмяРеквизита]; НоваяЗапись.НовоеЗначение = ЭтотОбъект[ИмяРеквизита]; КонецЕсли; КонецПроцедуры

Пример приведен для иерархического подчиненного справочника.
Если брать другой объект, например, документ, то состав служебных реквизитов будет другой, не "Код", "Наименование", "Родитель" и "Владелец", а "Дата" и "Номер".

В следующих статьях будут рассмотрены примеры использования механизма, описанного в данной статье.

Замаялся.

От Гения 1С : Смотрите

Менеджер Иван заходит в кабинет руководителя отдела продаж. Разговор начинается на повышенных тонах:

— Мы потеряли клиента! — возмущается менеджер, — Я оформил заказ, зарезервировал товар специально под покупателя. Но кто-то снял мой заказ с резерва! Я потерял из-за этого значительную часть месячной премии, мы упустили крупную сделку! Кто-то исправил документ, уменьшив срок резерва. Как узнать, кто виноват ?

История 2: Это не я!

Менеджер Светлана заносила в базу данных контактную информацию клиента «Колокольчик», когда раздался телефонный звонок. Позвонил новый клиент, фирма «Одуванчик». Светлана приняла заказ и зарегистрировала клиента в системе. Вернувшись к старой работе, она обнаружила, что контрагент «Колокольчик» бесследно исчез. Светлана обратилась в отдел техподдержки с жалобой на «глюк» в программе: Что же это такое, когда бесследно исчезают данные? Программа никуда не годится!

История 3: Все пропало, шеф!

Бухгалтер Татьяна анализировала документы за прошедший месяц и проставляла в них признак того, что документы сверили. Для своей работы она использовала «Групповую обработку справочников и документов», которая позволяла ей отобрать документы по определенному признаку и не заходить в каждый документ для подтверждения. Татьяна была хорошим бухгалтером, но ошибки случаются у всех. Вместо того чтобы выбрать документы за первое апреля 2014 года, она перенесла все документы за апрель на первое число (поменять дату обработка тоже позволяет).

У Татьяны паника: определить потерянные даты документов невозможно, а значит, нельзя исправить ситуацию. Что делать ?

Это совершенно реальные истории из практики наших сотрудников. Заметим сразу, что во всех трех историях все закончилось хорошо. Как и благодаря чему — Вы узнаете из этой статьи.

Итак, «Кто виноват?» и «Что делать?». На эти вопросы, давным-давно заданные классиками, до сих пор находятся все новые и новые ответы. Секрет в их универсальности, какую сферу человеческой деятельности не рассматривай, всегда найдется виноватый, и всегда будут вопросы, что делать с последствиями. Не исключение и сфера автоматизации торговли.

При работе с системами учета, на любом предприятии, где в базе данных работает более одного человека, регулярно возникает множество историй сходных с приведенными выше.

Спорных ситуаций можно избежать, если в системе подробно регистрируется информация о том, кто, когда и какие изменения внес в систему.

В данной статье мы рассмотрим использование механизма версионирования объектов на примере конфигурации 1С: Предприятие Управление Торговлей (УТ) версии 11.1 . Данный механизм позволяет сохранить историю изменения документа или справочника, проанализировать, кто виноват в возникновении ошибки учета, а так же ответить на вопрос, что делать, чтобы вернуть «испорченному» документу (или справочнику) его первоначальный вид.

Как настроить версионирование в УТ 11.1?

Возможность сохранения истории объектов включается в разделе Администрирование — Общие настройки:

Рисунок 1. Включение версионирования объектов

Теперь, когда сама возможность версионирования включена, необходимо настроить, изменения каких именно документов и справочников будут сохраняться. Эта настройка важна, так как с одной стороны, включение лишних объектов в систему версионирования может излишне увеличить размеры баз данных, а с другой стороны, нам нужно сохранять изменения всех важных объектов, чтобы избежать спорных ситуаций в работе. Нажмем гиперссылку «Версионируемые объекты» (правее флага включения версионирования) и перейдем в окно настройки:

Рисунок 2. Настройка версионирования объектов

В левой колонке мы видим список объектов системы: справочников и документов. В правой колонке, дважды щелкнув по ячейке, мы можем указать вариант версионирования объекта:

Не версионировать :
История изменений сохраняться не будет
Версионировать при записи :
Изменения будут фиксироваться каждый раз при сохранении документа или справочника. Изменения документов, в которых предусмотрено проведение, будут сохраняться даже в непроведенных документах
Версионировать при проведении :
Изменения будут фиксироваться при сохранении справочников и документов. Для документов, в которых предусмотрено проведение, изменения будут сохраняться? только если документ проведен (при первом проведении и в дальнейшем при записи).

Укажем для Заказа покупателя вариант «Версионировать при записи». А для Заказа поставщику — «Версионировать при проведении».

Как посмотреть историю изменений объекта?

Историю изменений объекта можно увидеть, открыв объект и перейдя по гиперссылке «История изменений» на панели навигации:

Рисунок 3. Переход к истории изменений

Рисунок 4. Список сохраненных версий документа

Из этого окна мы можем:

Как вернуться к сохраненному варианту объекта?

Для того, чтобы отменить все сделанные в справочнике и документе изменения и вернуться к какой-либо из более ранних версий, зайдем в окно истории изменения документов, установим курсор на версии, к которой хотим вернуться (предварительно посмотрев ее и уточнив необходимость возврата) и нажмем на кнопку «Перейти на версию» на панели инструментов.

База сообщит, что переход на версию был выполнен успешно:

Рисунок 6. Возврат к старой версии

Если все же мы ошиблись, и более корректной является версия документа до перехода, то можно выполнить переход к предыдущему варианту документа (в нашем примере — к 4-й версии).

Итак, мы рассмотрели основной функционал системы Версионирования. Мы увидели, как можно избежать конфликтных ситуаций в работе с базой, если имеется возможность посмотреть историю изменения объектов, сравнить версии документа или справочника на разные даты (время) между собой и даже вернуться к любой сохраненной версии объекта

А что же герои историй, рассказанных в начале статьи?

Как уже говорилось, все закончилось хорошо.

Иван посмотрел историю изменений своего заказа и увидел, что в 9:25 утра его отредактировала менеджер Катя. Ей срочно нужно было выписать заказ на клиента, а свободного остатка товара не хватало. Она извинилась перед Иваном, и он, конечно, простил ее. Тем более что заказ Кати можно было перенести на более поздний срок, а покупателю Ивана отгрузили товар в тот же день.

Сотрудник отдела техподдержки, к которому обратилась Светлана, проверил историю изменения контрагента «Одуванчик» и выяснил, что вместо того, чтобы занести в базу новую карточку клиента, Светлана записала информацию в карточку контрагента «Колокольчик», удалив старые данные. Карточку фирмы «Колокольчик» вернули, репутация программы и отдела техподдержки была восстановлена, а Светлана стала внимательнее относиться к своей работе.

Что же касается бухгалтера Татьяны, то с помощью механизма версионирования, ей удалось не только узнать, какие даты были раньше у документов, но и вернуть им первоначальный вид.

Желаем Вам успехов в работе!

В статье рассмотрен механизм версионирования объектов, реализованный в прикладном решении «Управление торговлей, ред.11» для сохранения истории всех изменений документов и справочников. Данный механизм позволяет восстановить измененные данные в случае ошибочных действий пользователей.

Применимость

Статья написана для редакции УТ 11.1 . Если вы используете эту редакцию, отлично - прочтите статью и внедряйте рассмотренный функционал.

Если Вы работаете со старшими версиями УТ 11, то данный функционал является актуальным . В актуальных версиях для доступа к рассмотренному функционалу используйте команду Настройки хранения в разделе Поддержка и обслуживание (история хранения) подсистемы Администрирование .

Наиболее заметным отличием УТ 11.3/11.4 от редакции 11.1 является интерфейс Такси. Поэтому, чтобы освоить материал статьи - воспроизведите представленный пример на своей базе УТ 11. Таким образом Вы закрепите материал практикой:)

– Кто испортил документ?! – крикнул Василий.
– Сегодня должен был получить премию за продажу товара. Прихожу к фин. менеджеру, а он мне говорит: «Какая премия? Вы не выполнили план продаж». Но как так? Помню, что провел реализацию на одну сумму, а сегодня сумма уже совсем другая. Что делать? Кто виноват?
Сердитый Василий берет телефон и набирает телефон тех. поддержки, которая обслуживает программу в компании и просит помощи: «Найдите виновных, надеялся премию получить!»
Трубку поднял оператор тех. поддержки и начал успокаивать Василия: «Не волнуйтесь, сейчас все выясним».
Как же повезло Василию, что в их компании использовалось УТ 11 и был включен функционал «Версионирование объектов». Оператор тех. поддержки без особого труда узнал кто, когда и что именно изменил в документах Василия.
Виновные были найдены и Василий в итоге получил премию.

Что же это за функционал такой, который помогает «разруливать» спорные моменты связаны с тем, кто именно из пользователей неверно заполнил и провел документ, установил не ту цену, склад, клиента, организацию и т.д?

В программе «Управление торговлей 11» присутствует отличная возможность для просмотра истории изменений (редактирования) справочников и документов под названием «Версионирование объектов». Давайте же рассмотрим как она работает.

Для включения использования этого функционала перейдем на закладку программы «Администрирование» пункт «Общие настройки» и установим галочку «Версионирование объектов».

Далее настроим список справочников и документов, по которым мы планируем видеть историю изменений. Нажмем на пункт «Версионируемые объекты» (находится возле галочки «Версионирование объектов»). Перед нами появится следующее окно: