Версия создана по уже имеющемуся объекту что значит

Подсистема версионирования объектов в 1С

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

Был рассмотрен функционал Библиотеки Стандартных Подсистем — он подразумевает хранение версий целого объекта на каждый период времени. Его сочли не лучшим вариантом: зачем сохранять весь объект, когда нужно сохранить только значение изменившегося реквизита?

Было принято решение о создании собственной подсистемы. С помощью данного функционала можно видеть, когда и какие конкретные изменения вносились в объектные (справочники, документы и т.д) данные системы.

Преимущество этого подхода версионирования объектов

1. Подсистема абсолютно универсальна для всех конфигураций на управляемых формах.
2. Не изменяет типовой конфигурации (не усложняет обновление и дальнейшее сопровождение).
3. Не дает существенного увеличения базы данных, в отличие от других систем.
4. Может применяться для любых объектов (это указывается в настройках).
5. Работает быстрее аналогов.
6. Быстрое внедрение и старт (от 1 дня).

Техническая реализация хранение истории 1С «по полям»

Технически она состоит из следующих объектов:

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

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

Подсистема версионирования объектов 1С 8.3 с точки зрения пользователя

Пользователю для просмотра истории достаточно сделать две простые вещи: 1) зайти в объект:

и 2) нажать на кнопку Открыть историю:

Отчет, в отличие от журнала регистрации или подсистемы из БСП, открывается моментально, и пользователь сразу может получить результат.

Внедрение пореквизитного версионирования в 1С

Если Вам необходимо внедрение такой подсистемы, мы с радостью поможем с внедрением. Подробности на странице услуги 1С программиста.

К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.

Источник

История данных в 1С

В технологической платформе 8.3.11 был введен специальный механизм — «История данных». Этот механизм видится достаточно полезным, так как предоставляет ту функциональность, которую не редко приходится реализовывать вручную. В этой статье я попробую рассказать о том, что это за механизм, для чего он нужен и как с ним работать.

Общая информация

Начнем с общей теоретической информации о том, что такое история данных и как она устроена.

Описание и возможности

История данных — это механизм позволяющий хранить в базе данных упорядоченные по времени версии объектов конфигурации. Под версией понимаются данные, которые были в объекте на момент редактирования и состояние метаданных на момент редактирования. Хранить историю можно как для всего объекта целиком, так и для отдельных реквизитов — имеется возможность тонкой настройки работы механизма для каждого реквизита, в том числе табличные части.

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

Само по себе хранение истории достаточно бесполезная функция, поэтому с историей данных можно выполнять следующие операции:

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

На момент написания статьи (8.3.13) история данных поддерживается для следующих объектов:

• общие реквизиты;
• константы;
• справочники;
• документы;
• бизнес-процессы;
• задачи;
• регистры сведений;
• планы обмена;
• планы счетов;
• планы видов характеристик;
• планы видов расчетов;
• расширения конфигурации.

Работа с историей данных регулируется правами доступа и отражается в журнале регистрации.

Устройство механизма

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

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

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

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

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

Свойство «История данных»

По умолчанию свойство «История данных» установлено в значение «Использовать» у:

• стандартных реквизитов;
• реквизитов объектов;
• реквизитов табличных частей;
• измерений регистров сведений (без возможности отключения);
• ресурсов регистров сведений.

Использование механизма

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

Управление использованием истории данных

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

Источник

«Кто виноват», «Что делать» и чем поможет использование версионирования объектов в 1С

История 1: Кто виноват?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При нажатии на гиперссылку открывается окно с перечнем сохраненных версий документа:

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

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

1. Открыть версию и посмотреть, как выглядел документ на определенный момент времени (когда с ним работал сотрудник). Для этого установим курсор на строку с версией и нажмем на кнопку «Открыть версию».
2. Сравнить версии между собой, наглядно увидев, что изменялось в документе. Для этого, зажав клавишу Ctrl на клавиатуре, сначала щелкнем мышкой по одной версии, а затем по другой. После того, как две строки (не обязательно расположенные подряд) будут выбраны, нажмем кнопку «Сравнить версии». Откроется отчет, в котором будут показываться только изменения, сделанные в документе:

Рисунок 5. Отчет по изменениям

Мы видим, что в 10:40 утра пользователь Бахшиев зашел в Заказ покупателя, поменял в нем менеджера (указав себя) и перевел заказ в статус «Не согласован».

Восстановить старую версию объекта.

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

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

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

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

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

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

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

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

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

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

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

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

Источник