Обновление нетиповой конфигурации

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

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

Рассматривать решение поставленной задачи для наглядности будем на примере переноса данных из программы 1С Комплексная автоматизация в 1С Бухгалтерия 8 (КА 1.1 => БП 3.0) с использованием правил переноса, созданных по технологии Конвертации данных 2.0. Все сказанное относится к любым правилам переноса, написанным по указанной технологии.

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

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

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

Итак, начнем знакомство с новыми функциональными возможностями. Для примера будем переносить один документ Поступление товаров и услуг (см. рис.1), который содержит табличную часть из двух строк, отражает поступление товаров двух видов. Для демонстрации создадим в приемнике, в базе БП 3.0 номенклатуру с наименованием Телевизор «JVC». Конкретно в данных правилах конвертации есть возможность с помощью параметра Продолжить поиск по реквизитам если по идентификатору не нашли задать вариант поиска объекта в приемнике. Если значение параметра — Нет, поиск производится только по УИД, в приемнике ничего не будет найдено, установим значение параметра — Да, т.е. будет производиться поиск по наименованию.

Рис.1 Документ выгружаемый из источника

Обработка для загрузки Перенос_данных_с_сопоставлением_УФ_v1_1.epf имеет по сравнению с типовой обработкой две дополнительные закладки: Типы данных сопоставления и Сопоставление данных. На первой из них необходимо отметить те типы данных, которые будут участвовать в сопоставлении объектов. Это вспомогательный сервис, повышающий удобство пользования, чтобы не интересующие нас данные не отражались в окне соответствий. В нашем случае мы будем работать пока только с номенклатурой, поэтому отметим только этот тип метаданных (см. рис.2).

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

Рис.2 Отметка типов метаданных для сопоставления

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

Рис.3 Пример таблицы соответствий объектов

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

Если мы сейчас выберем команду Загрузить данные, то произойдет заполнение базы приемника. Но результат ничем (почти ничем, об этом «почти» расскажу ниже) не будет отличаться от типовой загрузки, поскольку соответствия установлены автоматически и не изменены.

Теперь создадим в приемнике еще один элемент справочника Номенклатура с наименованием Телевизор JVC (без кавычек) и отредактируем таблицу соответствий: установим загружаемому объекту Наименование=Телевизор «JVC»… в соответствие этот новый элемент. Т.е. мы осуществили подмену объекта приемника, найденного правилами конвертации, другим объектом. То же самое можно было сделать например для элемента Телевизор «SHARP»: выбрать существующий элемент и поставить его в соответствие загружаемому объекту. Теперь загрузим данные и посмотрим на результат (см. рис.4).

Рис.4. Результат загрузки данных с ручным сопоставлением объектов

Как видим, в документе присутствует элемент справочника, который мы поставили в соответствие вручную. Напоминаю, я изменил соответствие перед загрузкой. Для наглядности на рис. 4 показано, что в справочнике есть два похожих по наименованию элемента, оба были созданы в приемнике вручную. Элемент Телевизор «SHARP» появился в результате переноса. Причем, этот новый элемент находится в папке Бытовая техника, точно как в источнике и точно по правилам синхронизации.

А вот теперь обещанное выше пояснение «почти». Обратите внимание на колонку Зам (Замещать свойства объекта, существующего в базе, свойствами загружаемого объекта). Галочки в ней нет, значит свойства объекта приемника не будут перезаписаны, что и произошло. Если галочку установить и вновь загрузить данные, Телевизор JVC переместится в папку Бытовая техника, но и наименование у него поменяется на Телевизор «JVC»(наименование это ведь тоже свойство). Надеюсь этого достаточно для пояснения назначения флага Зам: если нужно подменить загружаемый объект на существующий и не изменять существующий объект, флаг не устанавливаем. Если нужно заполнить свойства существующего объекта значениями загружаемого (наименование, код, ставка НДС и т.п.), флаг устанавливаем.

Я рекомендую флаг устанавливать. И вот почему. Как уже было сказано, при загрузке данных в непустую базу существует проблема: объекты разных баз, отражающие одни и те же сущности, имеют разные уникальные идентификаторы и не совпадающие значения реквизитов. Выставив соответствия вручную, мы можем избежать дублирования. Но что если при следующем сеансе обмена мы забудем это сделать. Тогда база будет испорчена. Если же перезаписать ключевые реквизиты объекта приемника, реквизиты поиска, то при следующих загрузках соответствие загружаемому объекту будет выставлено автоматически по реквизитам. Разумеется при условии, что в правилах конвертации задан поиск по реквизитам.

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

Как сохранить составленные соответствия для будущих обменов. Нужно создать План обмена Полный и использовать его в качестве идентификатора настройки соответствий. Выбирайте его в поле ввода Узел обмена загрузка данных и нажимайте Записать соответствия. План обмена полный создается в разделе Администрирование — Настройки синхронизации данных. Нужно установить флаг синхронизации данных с другими программами, а затем создать собственно настройку синхронизации, указав префикс и наименование. Создавать начальный образ подчиненного узла РИБ не нужно. Нам нужен только узел обмена для выбора варианта соответствий (см. рис.5), никакие возможности подсистемы распределенных информационных баз не используются.

Рис.5 Выбор узла обмена, для которого созданы соответствия

Таблица соответствий сохраняется в регистре сведений Соответствия объектов информационных баз, который есть во всех типовых конфигурациях. Если выбрать узел обмена перед загрузкой данных, то сохраненные для данного узла соответствия будут использованы в процессе загрузки. Можно предварительно прочитать соответствия из регистра в таблицу соответствий для просмотра, можно этого не делать. В любом случае, если узел обмена выбран, соответствия будут использованы. Можно прочитать соответствия из регистра, а затем изменить какие-то из них. Приоритет при загрузке данных следующий: сначала соответствие ищется в таблице соответствий обработки, затем, если не найдено, в регистре сведений.

Теперь рассмотрим особенности переноса с сопоставлением для связанных данных на примере контрагента и его договора. Создадим в приемнике вручную контрагента и договор и назовем их для наглядности Существующий контрагент и Существующий договор. Выгрузим в файл все тот же документ, показанный на рис.1. При заполнении соответствий из файла загрузки (команда Заполнить соответствия) по понятным причинам соответствия найдены не будут. Укажем их вручную как на рис.6.

Рис.6 Соответствие указано вручную

Отмечу, что флаг замещения реквизитов существующих объектов снят. После нажатия Загрузить данные в приемнике появится новый документ, но контрагент и договор в нем будут заменены на существующие (см. рис.7), новых контрагента и договора из документа создано не будет. Поясню, на рис. 6 виден еще один договор (с кодом 00078). Он никакого отношения к документу не имеет, переносится потому, что указан как основной договор у контрагента. Поскольку мы для него соответствия не указали, он запишется в базу-приемник без изменений, причем помеченным как основной договор. У Существующего контрагента таким образом будет два договора: Существующий договор и новый. Новый договор принадлежит именно Существующему контрагенту, так как контрагент Фирма «LIGHT» в процессе загрузки подменен, в том числе и там, где он является владельцем.

Рис.7 Результат переноса документа

Если установить флаг замещения реквизитов существующих объектов, то реквизиты Существующего контрагента и Существующего договора будут изменены (включая наименование). Таким образом Существующий контрагент «превратится» в Фирму «LIGHT». Важно понимать, что это ни в коем случае не новый контрагент, а уже существующий, но с перезаписанными (если конечно это позволяют правила переноса) реквизитами.

Оба варианта являются примерами правильной конвертации. Придраться тут не к чему. А теперь о «неправильностях». Предположим, что выставлено соответствие только для договора, т.е. все так же как на рис. 6, но нет соответствия Существующий контрагент. При этом замена реквизитов у договора Существующий договор также не производится. После загрузки в документе будет указан контрагент Фирма «LIGHT» и договор Существующий договор, который принадлежит другому контрагенту.

Это может быть расценено как ошибка переноса, хотя никакой ошибки конечно нет, все сделано в точном соответствии с настройками: контрагент оригинального документа сохранен, договор подменен, реквизиты существующего договора не изменены, а значит не изменен и владелец существующего договора. Если установить флаг замены реквизитов для Существующего договора, то документ будет более корректным. При записи Существующего договора изменится его владелец, он будет принадлежать отныне контрагенту Фирма «LIGHT», а также его наименование, т.е. его будет «трудно узнать». Это все тот же существующий договор, но изменивший абсолютно все реквизиты, включая наименование и своего владельца — контрагента.

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

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

В версии 2.1 появилась возможность сопоставления планов счетов. Рассмотрим на примере как и в каких случаях это можно использовать. На рис.8 показан документ, в котором используется добавленный в режиме ведения учета субсчет к счету 68. Т.е. это нетиповой, отсутствующий в типовой конфигурации счет. При переносе данных в другую информационную базу его можно также добавить к типовому плану счетов, но это не всегда правильно. Очень часто бухгалтеры злоупотребляют созданием всевозможных субсчетов, а когда понимают к каким последствиям это приводит, бывает уже поздно что-то менять.

Рис.8 Пример использования добавленного счета плана счетов в источнике

Предположим, при обмене мы захотели исправить эту ситуацию и заменить добавленный в источнике счет 68.16 на типовой счет 68.10, уже имеющийся в приемнике. Для этого при загрузке в приемник нужно установить соответствие счета 68.16 счету 68.10 как показано на рис.9. Заодно еще раз показано, как можно заменить значение справочника, в данном случае справочника Организации. Такая же необходимость может возникнуть при объединении данных из нескольких информационных баз в одну, когда возникает задача синхронизации планов счетов в источниках, которые не совпадают.

Рис.9 Установлено соответствие счетов

Результат загрузки в базу приемник показан на рис.10. Видно, что счет 68.16 заменен на 68.10. Счет 68.16 в таком варианте загрузки в приемнике вообще не будет создан. Произведена и подмена организации. Поскольку в данном случае мы записываем операцию, введенную вручную, то вместе с документом Операция производится создание набора записей регистра бухгалтерии. При этом замена организации произошла как в самом документе, так и в его движениях, что можно увидеть например с помощью консоли запросов. Что, впрочем, уже не так важно, поскольку всегда можно перезаписать документ и получить обновленные движения.

Рис. 10 Результат переноса документа

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

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

Рис.11 Конвертация документов Поступление товаров и услуг

В список полей поиска включим реквизит СуммаДокумента для того, чтобы иметь возможность не просто искать в базе приемника документ нужной даты и с нужным номером но и проверить совпадение суммы документа с документом источника. Для удобства введем параметр Поиск по сумме и реализуем алгоритм поиска вот так:
Если Параметры.ПоискПоСумме Тогда
СтрокаИменСвойствПоиска = «Дата, Номер, СуммаДокумента»;
Иначе
СтрокаИменСвойствПоиска = «Дата, Номер»;
КонецЕсли;
Т.е. при установке параметра в значение Истина («Да») поиск будет осуществляться по дате, номеру и сумме, иначе только по дате и номеру.

Теперь при заполнении соответствий, если синхронизация по сумме и суммы документов в источнике и приемнике совпадают, документ в приемнике будет найден и соответствие установлено (см. рис.12)

Рис.12 Результат поиска (сопоставления) по реквизитам при совпадении суммы

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

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

Вы можете приобрести описанную выше обработку, которая применима в конфигурациях, имеющих в своем составе обработку Универсальный обмен данными в формате XML редакции 2.1.8, т.е. работающих в режиме управляемого приложения, таких как Бухгалтерия предприятия ред.3.0, Комплексная автоматизация ред.2.0, Управление торговлей ред.11 и т.п. Вы можете также приобрести эту обработку в различных комплектах, в составе пакетов из обработок и правил обмена на нашем сайте. В составе комплектов это будет существенно дешевле.

Сравнение версий:

• 10.03.2018 — версия 3.1. Добавлена возможность отключения поиска документов по УИД для сопоставления документов по реквизитам

• 06.02.2018 — версия 2.1. Добавлена возможность сопоставления планов счетов

• 05.02.2018 — версия 1.2. Исправлена ошибка в режиме работы на клиенте

• 01.03.2017 — версия 1.1. Возможно сопоставление документов и справочников

Наименование проекта	Цена	Валюта	Покупка
Обработка для загрузки данных в формате XML с сопоставлением объектов		руб

Как обновлять свои доработки конфигурации у пользователей?

оглавление

Как настроить использование сетевых папок (дисков)

Обновлятор-1с. Автоматическое обновление доработанных конфигураций.

Обновлятор >> Инструкции 2018-11-20T17:44:21+00:00

Новая возможность

В свойствах баз обновлятора (в версиях после 3 ноября 2017 года) появилась вот такая замечательная опция:

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

Когда она может быть полезна

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

При этом все дописки вы знаете и они у вас задокументированы.

В таком случае может быть проще и быстрее:

1. Сначала обновить конфигурацию обновлятором (установив соотв. галку в свойствах базы)
2. Затем посмотреть отчёт обновления в обновляторе (там будут указаны свойства, измененные дважды)
3. И только после этого проверить, что все доработки на месте и вернуть те, что были утеряны (об этом смотрите ниже, где я рассказываю как работает автоматическое обновление доработанных конфигураций)

При таком способе работы вам не нужно:

1. Скачивать необходимые обновления
2. Открывать конфигуратор и применять эти обновления
3. Ожидать пока выполнится обновление конфигурации
4. Ожидать пока выполнится обновление базы данных

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

И если доработки конфигурации небольшие, то в большинстве случаев вам после обновления вообще не придётся ничего делать.

Ваше вмешательство будет нужно тогда, когда в обновлении будет изменен тот же самый объект, что изменен у вас (это и называется «измененные дважды»). И вы можете легко находить такие объекты, просматривая отчёт обновлятора:

Как работает автоматическое обновление доработанных конфигураций

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

Обновление происходит с приоритетом новой конфигурации, при этом:

1. Если вы добавляли в конфигурацию новый объект — обновление его не затронет.
2. Если вы добавляли в конфигурацию новый реквизит в уже существующий объект типовой (от поставщика) — обновление его также не затронет.
3. Если вы меняли в конфигурации объект поставщика, но он не изменился в этом обновлении, то он останется как есть.
4. Но, если вы меняли в конфигурации объект поставщика, и он изменился в этом обновлении, то возьмётся версия из обновления. При этом в отчёте обновлятора этот объект будет отмечен как «дважды измененный».

При этом, при настройке по умолчанию…

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

Я очень надеюсь, что эта возможность позволит высвободить ещё немного часов от ручного, монотонного труда.

Если у вас есть замечания или пожелания по этой возможности — я всегда рад вас выслушать, пишите мне на [email protected]

Как настроить финальное объединение с эталонной конфигурацией

Чтобы стало понятнее о чём речь, приведу рабочий пример у одного из пользователей обновлятора.

У него 40 бухгалтерских баз. Все они содержат одну и ту же доработанную конфигурацию.

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

Алгоритм работы до автоматизации у него был такой:

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

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

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

И я доработал эту возможность.

Чтобы заставить обновлятор после применения обновления следом выполнить ещё и объединение с конфигурацией из файла — необходимо расположить файл с конфигурацией для объединения в папку обновления под именем MergeThisFileAfterUpdate.cf

В рассмотренном выше примере предположим, что требуется обновить все 40 конфигураций на следующие релизы (и пусть они для упрощения задачи будут ключевыми, то есть их нельзя перескакивать): 2.0.60.1, 2.0.60.2 и 2.0.60.3.

Алгоритм наших действий с учётом автоматизации обновлятором будет следующим:

1. Обновить при помощи обновлятора одну из конфигураций до версии 2.0.60.3
2. Добавить все изменения, которые были потеряны… проверить работоспособность обновлённой конфигурации.
3. Выгрузить эту конфигурацию в папку с обновлением 2.0.60.3 под именем MergeThisFileAfterUpdate.cf
4. Запустить обновление (с включенной возможностью обновления доработанных конфигураций) оставшихся 39 баз.
5. Обновлятор в этом случае для каждой из 39 баз:
   1. выполнит пакетное обновление на 2.0.60.1
   2. выполнит обработчики обновления
   3. выполнит пакетное обновление на 2.0.60.2
   4. выполнит обработчики обновления
   5. выполнит пакетное обновление на 2.0.60.3
   6. обнаружит, что в папке с обновлением 2.0.60.3 лежит файл MergeThisFileAfterUpdate.cf
   7. выполнит пакетное объединение нашей конфигурации с конфигурацией из файла MergeThisFileAfterUpdate.cf (о настройках такого объединения смотрите ниже)
   8. выполнит обработчики обновления

При этом пакетное объединение выполняется через пакетный ключик конфигуратора mergecfg и следующий файл настроек (передаётся через ключ settings):

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

Объединение с эталонной конфигурацией как отдельная операция

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

Эта возможность доступна на закладке «Скрипты» в главном окне программы.

Тип скрипта «Пакетный». Из меню следует выбрать пункт «Обновлятор»->»Методы»->»Объединить с конфигурацией из файла»:

В скрипт вставится вот такой текст:

Путь к файлу, с которым нужно выполнить автоматическое объединение, у вас, конечно, будет свой.

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

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

Вторую команду можно вставить в скрипт из меню шаблонов:

С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Обновлятор >> Инструкции

Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.

Нажмите одну из кнопок, чтобы поделиться:

				Подписывайтесь и получайте новые статьи и обработки на почту (не чаще 1 раза в неделю). Вступайте в мою группу ВКонтакте, Одноклассниках, Facebook или Google+ — самые последние обработки, исправления ошибок в 1С, всё выкладываю там в первую очередь.
Как обновлять свои доработки конфигурации у пользователей?		оглавление		Как настроить использование сетевых папок (дисков)

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

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

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

Все результаты сравнения можно просмотреть в детальном виде.

Установка соответствия объектов

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

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

Сравнение конфигураций

Результат сравнения конфигураций отображается в специальном окне:

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

Для каждого отличающегося объекта можно просмотреть детальную информацию об отличиях:

Кроме того, информация об отличиях может быть получена в виде отчета:

Объединение конфигураций

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

Установка режима объединения конфигураций возможна как для всей конфигурации в целом, так и для каждого элемента прикладного решения в отдельности:

Варианты сравнения и объединения конфигураций

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

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

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

Сохранение / загрузка настроек объединения конфигураций

Настройки объединения конфигураций (или настройки обновления конфигурации на поддержке) можно сохранять в xml файл. Также доступна и обратная операция — загрузка этих настроек из файла.

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

Использование внешней программы

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

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

25 февраля 2014 Архивный материал

Автор статьи: Дмитрий Рудаков, специалист компании ЗАО «Сибирская Аграрная Группа»
Статья о продукте: 1С:Автоматизированное обновление измененных конфигураций

Обновлять конфигурацию сразу на несколько релизов весьма опасно. Дело в том, что после каждого обновления конфигурации запускается обновление информационных баз в режиме «1С:Предприятие». Поэтому если актуализировать только последний релиз, информационные базы могут не соответствовать последней конфигурации. В статье Дмитрий Рудаков, специалист компании ЗАО «Сибирская Аграрная Группа», делится личным опытом по единовременному обновлению конфигурации на 12 релизов.

Проверка режима изменения конфигурации

Представим себе такую ситуацию. Разработчики «Управления производственным предприятием» (далее — УПП) в релизе 1 (номера релизов здесь и далее присвоены условно) измерению (показателю) регистра расчета назначили тип «СправочникСсылка.ФизическоеЛицо» с наименованием «ФизЛицо». В релизе 2 они добавили еще одно измерение — «Сотрудник» с типом «СправочникСсылка.Сотрудники». При запуске «1С:Предприятие» включается обработка, которая заполняет измерение «Сотрудник», соответствующим измерению для «ФизЛица» образом. И потом в релизе 3 разработчики «1С» удалили измерение «ФизЛицо» и оставили только «Сотрудник». Если обновить конфигурацию с релиза 1 сразу до релиза 3, то можно очистить весь регистр расчета.

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

Поэтому прежде чем приступать к обновлению, нужно определить: работаете вы в типовой конфигурации с возможностью изменения или в конфигурации без возможности изменения? Для этого зайдите в конфигуратор, где в меню выполните действия «Конфигурация — Поддержка — Настройка поддержки».

Рис.1. Вызов окна настройки поддержки конфигурации

Если установлено «На поддержке», то эта конфигурация типовая, а если «Включена возможность изменения» — конфигурация, скорее всего, изменена (по крайней мере, такая возможность заложена). Третье состояние — «Конфигурация снята с поддержки». Различные состояния конфигурации показаны на рисунках 2, 3, 4.

Рис. 2. Типовая конфигурация без возможности изменений

Рис. 3. Типовая конфигурация с включенной возможностью изменения

Рис. 4. Конфигурация, снятая с поддержки

Алгоритм обновления измененных конфигураций

Недавно передо мной встала задача обновления измененной конфигурации «Управление торговлей», релиз 10.3.13.2. Конфигурация была изменена в результате объединения с отраслевым решением «БИТ: Управление автосервисом 8» и непрерывно дорабатывалась в течение двух лет. Теперь конфигурацию нужно было обновить до релиза 10.3.25.1, то есть на 12 релизов. Я разбил всю процедуру обновления на несколько этапов.

Этап 1. Оценка стоимости и сроков процедуры обновления

Прежде чем приступать к самостоятельной работе, я решил получить независимую оценку специалистов в этой области. Единственная компания, располагающая возможностью обновления измененных конфигураций автоматизированными методами, это ООО «1С-ИжТиСи». Я обратился к специалистам этой компании с просьбой оценить стоимость обновления моей конфигурации. Для оценки времени и стоимости работ я предоставил текущую конфигурацию, нуждающуюся в обновлении. Через день я получил письмо с отчетом.

Отчет по итогам оценки стоимости и сроков проведения обновления конфигурации:

Конфигурация: Управление торговлей, редакция 10.3
Текущая версия конфигурации: 10.3.13.2
Обновление до версии: 10.3.25.1
Количество обновляемых модулей: 1 847
Количество контрольных релизов: 8

Результаты оценки меня удивили, поскольку на сайте компании была указана стоимость по акции — 1000 руб. за обновление на один релиз. Комментарий «1С-ИжТиСи»:

«Стоимость обновления на каждый пропущенный релиз у нас не выше 2000 рублей. Сейчас проходит акция, поэтому стоимость не превышает 1000 руб. Но окончательная цена услуг определяется по результатам оценки трудозатрат на обновление и может быть ниже 1000 руб./релиз».

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

Рис. 5. Выбор релизов, которые обязательно нужно использовать для корректного обновления конфигурации

После изучения отчета «1С-ИжТиСи» я подсчитал личные временные затраты на тот же самый объем работы. Каждая процедура обновления занимает у меня приблизительно 6 часов. Следовательно, общие временные затраты составляют 56 (9х6) рабочих часов, то есть приблизительно семь рабочих дней. Кроме того, существует вероятность, что после обновления выявятся какие-то недочеты: к примеру, пользователь пожалуется, что нужные для него изменения в конфигурации утеряны, и тогда временные затраты серьезно увеличатся. Между тем, специалисты компании «1С-ИжТиСи» предлагают проделать весь объем работы за три-четыре рабочих дня. Поэтому я решил воспользоваться их услугами.

Теперь кратко поясню, что именно было изменено в конфигурации.

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

Сильно измененные регистры:
«Партии товаров на складах»;
«Товары на складах».

Значительно измененные объекты. Объекты, в которых добавлены реквизиты, изменены либо формы объектов, либо модули объекта (как правило, проведение документа нетиповое).
Документ «Приходный кассовый ордер»;
Регистр сведений «Комплектующие номенклатуры»;
Регистр сведений «Списанные товары»;
Общие модули.

Незначительно измененные объекты. В объектах изменены только формы и добавлены реквизиты.

В разделе «Общие» изменены подписки на события, макеты, роли, общие модули. Почти все было изменено отраслевым решением.

Этап 2. Удаление конфиденциальной информации

Прежде чем предоставлять сотрудникам «1С-ИжТиСи» информационную базу для тестирования, в ней нужно удалить конфиденциальную информацию. Для таких случаев фирма «1С» рекомендует использовать обработку «Изменение конфиденциальной информации», которая не очень широко известна.

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

Обработка ИзменениеКонфиденциальнойИнформации.epf есть на диске ИТС в каталоге 1CIts\EXE\EXTREPS\UNIREPS81\UpdatePrivateInformation. Также данную обработку можно скачать по ссылке: http://its.1c.ru/db/metod81#content:1644:1.

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

• Справочники: Физические лица, Контактные лица, Контактные лица контрагентов, Контрагенты, Типы цен.
• Регистры сведений: Паспортные данные физического лица, ФИОФизЛиц.

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

Этап 3. Получение результатов обновления

Через три дня мне предоставили cf-файлы и исчерпывающие инструкции по их установке. Для контрольных релизов предоставляются cf-файлы, которые нельзя использовать для работы пользователей, так как в них обновлены только метаданные. Они предназначены только для корректного обновления на последнюю версию.

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

В результате обновления я выделил две небольшие задачи для самостоятельного решения.

Первая. В силу того, что обновление проводится с использованием механизма «Сравнение, объединение», конфигурация БД действительно обновляется, и обновляется правильно, без технических рисков благодаря учету контрольных релизов. Однако не обновляется конфигурация поставщика. Разумеется, технически грамотный специалист без проблем дополнит данную работу, однако я попросил «1С-ИжТиСи» выслать более полную инструкцию по обновлению. В соответствии с ней, обновление сможет произвести даже неопытный специалист.

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

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

Комментарий «1С-ИжТиСи»:

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

Рис. 6. Код частично измененной конфигурации до обновления

Рис. 7. Код частично измененной конфигурации после обновления

Да, действительно, разработчики УТ 10.3 удалили лишние пробелы в конфигурации поставщика. Но что если бы разработчики удалили какие-то операторы в строчке кода? Были бы они так же сохранены?

Комментарий «1С-ИжТиСи»:

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

Выводы о результатах обновления

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

В целом, могу сказать, что данная услуга и продукт имеют не только большое будущее, но и вполне хорошее настоящее. Этим сервисом можно и нужно пользоваться. Думаю, что ни один программист не возьмется вручную обновлять конфигурацию (тем более, измененную) с 12-ю пропущенными релизами всего за 3 000 руб.

Информация о компании ЗАО «Сибирская Аграрная Группа».

Группа Компаний «Сибирская Аграрная Группа» — ведущее агропромышленное объединение Сибирского Федерального округа. Компания представляет собой холдинг с полным производственно-сбытовым циклом, где все процессы идут по замкнутой цепи — от производства комбикормов до производства мясной продукции и ее реализации. Основными направлениями деятельности являются свиноводство, растениеводство, переработка и реализация мяса. Сегодня в состав «Сибирской Аграрной Группы» входят: мясокомбинаты в Томске и Кемерово, три свиноводческих комплекса — в Томской, Свердловской областях и в республике Бурятия, комбикормовый завод, птицефабрика «Томская», а также сеть магазинов фирменной розницы.

http://www.sibagrogroup.ru/

Информация о компании ООО «1С-ИжТиСи». ООО «1С-ИжТиСи» — дочерняя компания фирмы «1С». Более 6 лет специализируется на автоматизации процессов обновления и тестирования измененных конфигураций на платформе «1С:Предприятие». В настоящее время сотрудничает более чем с 400 партнерами, клиентами и разработчиками тиражных отраслевых решений по России и СНГ.

http://1с-ижтиси.рф/

1.2. Объекты конфигурации

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

В платформе «1С: Предприятие 8.0» существуют следующие объекты конфигурации:

? Константы

В константах хранятся редко изменяемые значения, например, название организации, ИНН, ФИО руководителя и т.д.

? Справочники

В справочниках содержится условно-постоянная списковая информация, например, список материалов, список сотрудников.

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

? Перечисления

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

? Документы

Документы служат для ввода информации о фактах хозяйственной деятельности предприятия. С их помощью регистрируются операции по движению денежных средств, получению и отпуску МПЗ, начислению амортизации и т.д.

? Журналы

Журналы служат для хранения уже введенной информации. Документы, попавшие после их записи и проведения в журналы, можно редактировать, удалять, а так же непосредственно из журналов можно осуществлять ввод новых документов и операций.

? Нумераторы

Нумераторы предназначены для единой (сквозной) нумерации документов нескольких видов. Например, нумератор Кадровый используется для присвоения номеров всем кадровым приказам.

? Планы видов характеристик

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

? Регистры сведений

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

? Регистры накопления

Регистры накопления накапливают числовую информацию в разрезе заданных измерений, например, исчисленные за каждый месяц суммы ЕСН, стоимость покупок и продаж. Движения регистров накопления всегда связаны с документами (регистраторами) и обычно создаются в момент проведения документа.

? Регистры бухгалтерии

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

? Планы счетов

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

? Отчеты

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

? Обработки

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

? Интерфейсы

Представляют собой совокупность панелей интерфейса: меню и панели инструментов, например, интерфейсы «Бухгалтер», «Руководитель».

? Роли

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

В самом общем виде взаимосвязь всех объектов можно представить следующим образом:

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

Блок «Документы» включает, во-первых, документы, предназначенные для регистрации событий и операций, и, во-вторых, журналы, как средство их смысловой группировки. Например, документы «Приходный кассовый ордер», «Расходный кассовый ордер» и журнал «Кассовые документы».Документ характеризуется номером и датой. С помощью служебный объектов «Нумераторы» можно организовать «сквозную» нумерацию документов разного типа.

Блок «Регистры» предназначен для хранения информации о состояниях и количествах объектов базы данных.

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

Данный текст является ознакомительным фрагментом.
Читать книгу целиком
Поделитесь на страничке

Следующая глава >