Что такое кд 1с
В составе плана обмена в 1С 8.3 БСП есть возможность устанавливать разрешение или запрет автоматической регистрации объекта к обмену данными. Если для объекта разрешена авторегистрация, то при записи он безусловно зарегистрируется к обмену данными. В таком случае нельзя будет выполнить какие-либо проверки свойств объекта перед его регистрацией и нельзя будет управлять регистрацией объектов.
3. Правила регистрации объектов
При регистрации данных в подсистеме «Обмен данными» библиотеки стандартных подсистем 1С для каждого объекта входящего в состав обмена данными описываются правила регистрации объектов. Правила регистрации объектов используются как в обменах в формате КД 2, так и для обменов в универсальном формате. Правила регистрации объектов в 1С представляет собой текстовый макет плана обмена, содержащий описание правил регистрации в формате XML. Разработка правил регистрации объектов всегда выполняется с использованием конфигурации «Конвертация данных 2», даже если обмен выполняется в универсальном формате (КД 3).
Используя правила регистрации объектов, разработчик обмена данными получает возможность управлять составом данных отправляемых в систему корреспондент. В правилах регистрации есть возможность установить проверку свойств объектов, например, регистрировать к отправке только проведенные документы, относящиеся к определенной организации, начиная с определенной даты. В зависимости от настроек плана обмена можно ограничить регистрацию и выгрузку документов относящихся к разным подсистемам. Например, можно добавить настройку плана обмена «Выгружать банковские документы», и в зависимости от значения настройки отправлять либо не отправлять документы, относящиеся подсистеме «Банк» в систему-корреспондент.
Разработка правил регистрации
Как уже было сказано выше, правила регистрации объектов разрабатываются в конфигурации «Конвертация данных 2».
Рис. 1 Правила регистрации объектов в 1С
Чтобы добавить либо изменить существующие правила регистрации объектов необходимо выполнить следующие действия:
· Выгрузить метаданные конфигурации участвующей в обмене, с помощью специализированной обработки;
· Загрузить их в справочник «Конфигурации информационных баз»;
· Загрузить существующие правила регистрации из макета плана обмена, если требуется доработка существующих правил регистрации, а не разработка с нуля.
Примечание: Более подробно о разработке правил регистрации можно почитать в помощнике, встроенном в конфигурацию «Конвертация данных 2»
Рассмотрим основные возможности разработки правил регистрации объектов с использованием конфигурации «Конвертация данных 2». Рассмотрим, как реализован отбор документов при регистрации в обмен в большинстве типовых правил обмена объектов. В систему-корреспондент могут отправляться не все документы, а только по определенным организациям, начиная с определенной даты. Для реализации этого отбора в план обмена добавлены следующие реквизиты:
· Использовать отбор по организациям – Булево;
· Дата начала выгрузки документов – Дата;
· Организации – табличная часть. Реквизиты: Организация – Справочник «Организации».
Реквизиты выведены в форму узла для возможности изменения настроек обмена пользователем.
Рис. 2 Реквизиты в Плане обмена в 1С
Откроем правила регистрации объекта любого из документов:
Рис. 3 Правила регистрации объекта документа
На рисунке видно, что в правилах регистрации присутствует отбор по свойства узла плана обмена. Документ регистрируется к отправке в систему корреспондент при соблюдении следующих условий:
· значение реквизита документа «Дата» больше или равно реквизита плана обмена «Дата начала выгрузки объекта»;
· значение реквизита плана обмена «Использовать отбор по организации» = «Нет», т.е. флаг отбора по организациям в форме узла отключен;
· значение реквизита документа «Организация» входит в список значений в табличной части плана обмена «Организации».
Обратите внимание, что два последних условия объединены в группу с условием ИЛИ, т.е. регистрация выполняется, если соблюдено одно из этих условий: нет отбора по организации или организация документа есть в списке организаций, участвующих в обмене.
Отбор по реквизитам документов используется, когда при регистрации нет необходимости проверять какой-либо из реквизитов плана обмена, и выгрузка зависит только от значений реквизитов самого объекта. Например, нам необходимо регистрировать к отправке только проведенные документы. В этом случае настройка условий отправки будет выглядеть следующим образом:
Рис. 4 Настройка условий отправки в Плане обмена в 1С
4. Особенности регистрации данных для обменов в формате КД 2, КД 3
В формате КД 3 такая функция отсутствует, и при любой записи объекта будет выполнена его регистрация. Если для объекта выполняются условия, заданные правилами регистрации, он будет отправлен в систему-корреспондент, даже если по факту в нем не были изменены реквизиты, участвующие в обмене, и даже если изменений реквизитов объекта не было совсем.
Специалист компании «Кодерлайн»
Вас могут заинтересовать следующие статьи:
94 [PROP_CODE] => TAGS2 [TITLE] => Вас могут заинтересовать следующие семинары: ) --> 95 [PROP_CODE] => TAGS [TITLE] => Вас могут заинтересовать следующие вебинары: ) -->
Вас могут заинтересовать следующие вебинары:
В КД очень важно понять основные принципы работы. Вроде и самой КД сто лет в обед, и понаписано уже не счесть, но все как-то не так, как мне бы хотелось. Постепенно крепло желание написать эдакое послание самому себе, начинающему изучать КД, да никак руки не доходили. Последней каплей стала очередная попавшаяся на глаза "неправильная" статья, и я решил - ничего страшного, пусть будет еще одна статья, зато гештальт закрою :) Даже если я излишне самонадеян, авось кому-то она все же поможет. Скриншотов не будет, будет только унылый текст. Но я бы в свое время за него многое отдал. Чтобы не перегружать статью, в ней не освещаются особенности вроде правил регистрации, особенностей КД 3.0 и т.п.
КОНЦЕПЦИИ ОБМЕНА ДАННЫМИ
Правила конвертации. "Конвертация данных" (далее "КД") - это конфигурация/база 1С, где описываются правила, по которым данные из базы-источника (далее "источник") должны преобразовываться в данные базы-приемника (далее "приемник"). Эти правила выгружаются в xml-файл. И все. Больше КД не делает ничего. Несмотря на название, сама конвертация данных - это уже не ее забота. Это просто "конфигуратор" (или если хотите - IDE для разработки правил). Кто же выполняет саму конвертацию? Изначально за это отвечали внешние обработки выгрузки/загрузки, входящие в комплект поставки КД.
Выгрузка. Обработка выгрузки запускается в источнике, ей указывается файл с правилами из КД, некоторые дополнительные настройки выгрузки (типа отборов данных) и обработка формирует файл обмена. И тут важный момент - в файл обмена пишутся УЖЕ КОНВЕРТИРОВАННЫЕ согласно правилам конвертации данные (фактически это готовые образы объектов для загрузки в приемник) плюс информация из правил обмена о поиске нужных объектов в приемнике, плюс тексты программных обработчиков, которые должны быть выполнены при загрузке данных в приемнике (они будут выполняться в нужных местах с помощью банального "Выполнить"). Теперь повторю важный момент с другого ракурса - в нормальной ситуации ВСЯ КОНВЕРТАЦИЯ ВЫПОЛНЯЕТСЯ В ИСТОЧНИКЕ. То есть и все правила конвертации с их взаимосвязями анализируются в источнике и почти все самые важные с точки зрения конвертации программные обработчики - также выполняются в источнике. Этот момент нужно держать в голове, когда вы пишите код программных обработчиков в КД. Это обычный код 1С, который будет исполнен в источнике с помощью инструкции "Выполнить" в контексте алгоритма выгрузки данных. И, соответственно, в этом контексте вы имеете полный доступ к базе источника и можете писать любой корректный для нее код 1С. А как же упомянутые обработчики "при загрузке", спросите вы? Скажу, что в 99% случаев обработчики на стороне приемника не нужны. Но новички часто ими злоупотребляют по банальной причине - они еще не знают, как настроить правила конвертации правильно, а обработчики в приемнике как-то проще для понимания. Код - он и в Африке код :) Но такой стиль ущербен по многим причинам, так как идет в разрез с неявной идеологией КД. Плюс использование обработчиков при загрузке часто сильно замедляет эту самую загрузку. В нормальной конвертации загрузка сводится просто к поиску/созданию нужного объекта и загрузке в него готовых данных, конвертированных еще в источнике. Но если обработчики "при загрузке" вам все-таки нужны, в них, естественно, вы пишите код уже для приемника. Прямого доступа к источнику там уже нет.
Кстати! Многие не сразу понимают этот ньюанс. Ни в один момент времени не существует одновременного доступа к данным и источника и приемника. Даже для случаев обмена через COM остается четкая модель разделения процесса на выгрузку и загрузку. В обычной ситуации, данных источника и метаданных приемника вполне достаточно для правильной конвертации данных (т.е. для выполнения всей конвертации в источнике). Эта идея и заложена в основу идеологии КД. Но бывают редкие случаи, когда нужных для правильной конвертации данных в источнике нет и также нет ни одного способа их вычислить на основании имеющихся в источнике данных. Вот для таких редких случаев на выручку и приходят обработчики на стороне приемника (при загрузке).
Загрузка. В базе-приемнике запускается обработка загрузки данных, указывается файл обмена и. все. Выполняется загрузка :) Вся необходимая информация уже содержится в файле обмена. И так получилось, что почти все про загрузку я уже сказал, когда говорил про выгрузку :)
Итак, первоначально обмен данными между разными конфигурациями производился через внешние обработки. Но потребностей и задач обмена данными становилось все больше, какие-то части алгоритмов обработок выгрузки/загрузки стали засовывать в универсальные модули типовых конфигураций (предтеча БСП) плюс добавляли дополнительный функционал обмена в типовых (вроде использования планов обмена, работы через COM и прочее), потом появилась БСП где это все выделили в отдельную подсистему и навешали сверху еще плюшек, но основа остается неизменной. Просто правила конвертации, сделанные в КД, теперь засовываются в нужные места типовых на базе БСП и поверх этого накручено еще много полезных настроек, которые делаются уже в рамках подсистемы БСП "Обмен данными" (подробнее про все богатство ее функционала читайте на ИТС в документации по БСП в описании подсистемы "Обмен данными").
КОНЦЕПЦИИ РАЗРАБОТКИ ПРАВИЛ КОНВЕРТАЦИИ
Теперь, когда с процессом обмена данными с высоты птичьего полета должно быть примерно понятно, вернемся к собственно разработке правил конвертации.
Конфигурации. Очевидно, что КД должна обладать знаниями о метаданных источника и приемника. Они загружается в служебные справочники (главный из них - "Конфигурации") через xml-файлы (которые выгружаются из баз источника/приемника специальными обработками, входящими в состав поставки КД). Соответственно, если конфигурации баз источника/приемника изменяются, то описание их метаданных в КД тоже нужно обновлять. Или не нужно, если изменения не затрагивают конвертацию :)
Конвертации. В одной базе КД можно настраивать множество правил обмена между разными конфигурациями. Они идентифицируются элементами справочника "Конвертации", в каждом из которых выбираются конфигурации источника и приемника. Каждая конвертация - это по сути набор.
Правил конвертации объектов (далее ПКО). ПКО - сердце КД. Как следует из названия, каждое ПКО отвечает за конвертацию какого-то вида объекта (справочника, документа и пр). Нужно понимать, что само по себе ПКО - штука пассивная. Ему надо каким-то образом на вход подать данные, а на выходе оно "выплюнет" образ объекта-приемника для записи в файл обмена. Я обтекаемо написал про "данные" на входе, потому что не всегда в источнике есть подходящий объект (если конфигурации сильно отличаются). Это может быть и программная структура. Если случай простой, и выполняется конвертация "объект-объект", то тогда прямо в свойствах ПКО указывается исходный объект источника и это облегчает дальнейшую настройку. Но в общем случае объекта-источника может и не быть - тогда данные на вход формируются программно. Может быть несколько разных ПКО для одного и того же объекта приемника, но для разных целей.
Вернемся к основной цели ПКО - "выплюнуть" образ данных объекта приемника для записи в файл обмена. Из этого вытекает то, что у ПКО заранее и железно предопределено - это вид объекта приемника и его поля. И так как эти поля имеют смысл только вместе с правилами их заполнения/конвертации, то они называются.
Правила конвертации свойств (далее ПКС). Суть у ПКС такая же, как у ПКО, только уровнем ниже - "выплюнуть" на выход конвертированное поле объекта приемника для записи в файл обмена. Так как в процессе отработки ПКО у самого ПКО так или иначе поданы на вход какие-то данные, то по умолчанию на вход ПКС также подается одноименное свойство из этих данных. Если у ПКО явно задан источник, то можно параметрически выбрать поле источника, которое будет подано на вход (это самый простой случай). Также данные на вход можно подать программно. Итак, данные на входе есть, нужно теперь их при необходимости конвертировать. Если поле имеет примитивный тип и на вход подан такой же - то красота. Вообще ничего делать не надо. А если не примитивный? Тогда. можно параметрически выбрать готовое ПКО, по которому оно будет конвертировано! Вот ради этого красивого жеста и был весь сыр-бор. Единожды оформленное ПКО можно переиспользовать во всех ПКС всех ПКО, где это необходимо. КД по умолчанию поддерживает конвертацию по ссылкам. Это означает, что при конвертации объекта по ПКО входные данные из его ПКС будут переданы на вход указанным в них ПКО и все это рекурсивно повторяется вниз-вниз-вниз. В результате будут автоматически конвертированы и выгружены ВСЕ связанные объекты (это поведение можно изменить). Правда, красота нечеловеческая? Как-то мне пришлось самому писать похожую систему для тесной интеграции 1С с одним внешним продуктом и конвертацией по ссылкам. С тех пор я нежно люблю КД.
У ПКС, так же как и у ПКО, есть собственный набор обработчиков со своими "ручечками" и "кнопочками". Про важность этих обработчиков уже было написано выше, но для ПКС они еще важнее, чем для ПКО, так как по сути собственно конвертация часто выполняется именно на уровне ПКС. Например, в этих обработчиках можно динамически менять ПКО, по которому будет конвертироваться свойство (в зависимости от каких-то условий). Там есть доступ ко всему объекту, поданному на вход ПКО (параметр "Источник"). Можно прямо в обработчике программно назначить данные, которые будут поданы на вход ПКС (параметр "Значение") - это часто используется для конвертации примитивных типов и не только. И многое, многое другое (читайте справку по обработчикам).
Правил выгрузки данных (ПВД). Задача ПВД предельно проста - выбрать данные источника, "скормить" их на вход какого-нить ПКО и умыть руки. Можно сказать, что в отличие от пассивных ПКО, ПВД - активны. Они выбирают данные, передают их ПКО и дают отмашку на конвертацию.
В самом своем примитивном виде, при выгрузке "объект-объект" для вида выборки "стандартная выборка" достаточно параметрически указать вид объекта источника и ПКО для него. И все. В обработке выгрузки можно будет активировать это правило и указать для него стандартные отборы (при необходимости).
Для более сложных случаев предусмотрен вид выборки "произвольный алгоритм" и. правильно! ОБРАБОТЧИКИ! :) Можно, например, запросом сформировать нужную выборку данных и подать ее на вход ПКО без источника. Для произвольных выборок будут недоступны стандартные отборы обработки выгрузки, но внутри можно использовать параметры конвертации.
Вот и все. Очень многое в этой статье осталось за кадром. Конвертация значений, свойства, параметры и обработчики самой конвертации (и как их можно использовать), особенности настройки ПКГС (правил конвертаций групп свойств для табличных частей, например), приоритеты правил, особенности настроек и приоритетов правил поиска объекта в приемнике, алгоритмы (куда можно выносить повторяющийся код используемый в обработчиках), интересные приемы решения типовых задач и многое, многое другое. Но владея основными принципами, с остальным вам будет разобраться намного проще. Надеюсь :)
ЗЫ. В качестве практической части для новичков, со скриншотами и подробным руководством куда и зачем тыкать начинающему, могу порекомендовать вот эту статью.
О том, что "Конвертация данных" - это удобный инструмент и прочую нужную информацию о ней, вы можете найти в справке самой конфигурации. Я же хочу поделиться своим кратким пояснением как ею пользоваться. Речь пойдет о версии 2.1. Если кому-то пригодится, одной из лучших благодарностей будет ваш лайк.
Когда требуется из одной системы выгружать данные в другую систему, то как правило настраивается план обмена, который автоматически (по расписанию) выгружает/загружает данные по неким правилам. Эти самые правила обмена удобно написать в конфигурации 1С "Конвертация данных" 2.1 (КД 2.1).
Обменивающиеся системы могут быть совершенно разными или идентичными, ограничений нет.
Другим применением КД 2.1 может быть написание правил для "ручной" выгрузки/загрузки данных с помощью обработки "Универсальный обмен данными XML", которая есть в любой типовой конфигурации. (Если в вашей системе вы не находите эту обработку, скачайте её и воспользуйтесь как внешней).
Если между системами настроен план обмена, то объект регистрируется к выгрузке, в случае его записи или проведении, и выполнении условий регистрации для данного объекта (ниже будет подробнее).
Эти условия регистрации для объекта могут быть прописаны в самой системе непосредственно в коде с помощью режима Конфигуратор, или в правилах обмена, в файле "RegistrationRules.xml" в типовых конфигурациях на УФ.
В качестве примера рассмотрим типовой обмен на управляемых формах (УФ) между ЗУП 3.1 и БУХ 3.0.
В ЗУП 3.1 в плане обмена "ОбменЗарплата3Бухгалтерия3" в реквизитах и табличных частях можно указать условия обмена, например, выгружаем только по определенным Организациям и не выгружаем персональные данные сотрудников. А в макетах плана обмена прописаны типовые правила (от разработчиков 1С), выделила для наглядности квадратом в Рис. 1.
Пример формы плана обмена в режиме предприятия показан на Рис. 3.
Откройте Администрирование - Синхронизация данных Рис. 2:
Учить настраивать обмен не буду, как это сделать легко найти в официальной документации.
На форме Плана обмена указано, что выгружаем только по конкретной организации и сводно по сотрудникам, другими словами персональные данные не выгружаем.
Рис. 3
Правила обмена могут быть типовыми (из конфигурации) или внешними (из файла на компьютере).
Правила из конфигурации удобно сохранить в файл, который выгружается архивом, распаковать архив и загрузить в Конвертацию данных для модификации.
Для этого нажмите "Загрузить комплект правил":
Правилами выгрузки является файл "ExchangeRules.xml", после его модификации, упаковываем три файла назад в архив и загружаем. Как загрузить "ExchangeRules.xml" в конвертацию данных показано на Рис. 19.
Так же изменять можно и правила регистрации "RegistrationRules.xml", например, если нужно выгрузить документ, не взирая на условие Плана обмена. Например, одно условие действует на 4 вида документов, но нам требуется всё же один документ выгрузить. Условие по этому документу можно просто закомментировать Рис. 8.
В моём примере по документу "ВедомостьНаВыплатуЗарплатыПеречислением" игнорируется условие "НеВыгружатьПерсональныеДанныеФизическихЛиц".
Открыть "RegistrationRules.xml" в конвертации данных не получится.
Файл "CorrespondentExchangeRules.xml" является правилами выгрузки базы корреспондента. То есть правила "CorrespondentExchangeRules.xml" и "ExchangeRules.xml" базы корреспондента (в моём примере это БУХ 3.0) должны совпадать.
Далее информация по самой конвертации данных.
Регистрировать для выгрузки все справочники, связанные с документом, и прописывать по ним ПВД не нужно. По ним сформируем ПКО при конвертации свойств (реквизитов объекта и реквизитов табличных частей объекта) (возможно станет яснее, посмотрев на Рис. 11).
Стандартная выборка (стрелка 2 Рис. 9) содержит в себе все реквизиты объекта, включая табличные части.
В ПВД указано Правило конвертации объекта (ПКО) (стрелка 3 Рис. 9), в данном примере ПКО называется "НачислениеОценочныхОбязательствПоОтпускам", все ПКО располагаются на первой закладке формы настроек правил обмена.
С левой стороны имеются обработчики: "Перед обработкой", "Перед выгрузкой", "После выгрузки", "После обработки" (стрелка 4 Рис. 9). В каждом из этих обработчиков при вызове "Информации по обработчикам" (стрелка 5 Рис. 9) можно получить сведения о выполняемых в нём действиях и возможных параметрах (в каждом обработчике список параметров немного различается).
Например, обработчик "Перед обработкой":
В Информации по тексту ниже указан вот такой пример:
Можно написать своё условие: например, если реквизит "Флаг" установлен в Истину, тогда такой объект нужно выгрузить по другому ПКО:
В случае, если при выгрузке вы пользуетесь произвольным алгоритмом, вам необходимо инициировать параметр ВыборкаДанных (стрелка 6 Рис. 10).
В рис. 11 указала связь всех правил. ПВД является ключевым триггером для выгрузки объекта по правилам конвертации, поэтому начинаем с него.
ПКО
Теперь перейдем к ПКО "НачислениеОценочныхОбязательствПоОтпускам" (стрелка 7 Рис. 12), состоящему из правил конвертации свойств (ПКС):
Ссылочные свойства выгружаются по указанным ПКО (стрелка 8 Рис. 12). То есть при выгрузке реквизитов "Организация" и "Ответственный" они будут выгружены согласно правилам ПКО с названиями "Организации" и "Пользователи".
В ПКО можно указать правила поиска объекта:
Признак (Стрелка 10 Рис. 13) не задан, следовательно, в случае, если объект не найден, то он будет создан.
Дополнения:
Обратите внимание, на Рис. 11 я обозначила раздел "Важно" стрелкой 6, так вот стрелка 11 - это тот самый признак, который необходимо установить, если вы используете произвольный алгоритм для ПВД.
Не забывайте пользоваться информацией по обработчикам (стрелка 12).
Если вы решили выгружать все изменения справочников и документов, то обратите внимание в ПВД на закладку "Дополнительно", там задан "Порядок выполнения".
По ссылкам ниже вы можете почерпнуть дополнительную информацию:
Создание с нуля (кратко)
У нас есть конфигурация источник и конфигурация приемник (они могут быть идентичными).
В случае, если конфигурации различаются, в каждой из конфигураций нужно запустить обработку "MD82Exp.epf" или "MD83Exp.epf", в зависимости от версии платформы.
Как-то по особому называть файлик выгрузки не нужно. При загрузке система сама определит наименование конфигурации.
Далее выгруженную структуру (структуры) загружаем в конвертацию.
Далее выбираем на рабочем столе конвертации пиктограмму "Правила обмена данными", нажимаем "Добавить" и в открывшемся окне выбираем конфигурации.
При появлении картинки ниже, жмите или "Закрыть" или "Создать новое правило обмена данными".
Загрузка имеющихся правил (кратко)
Если структура конфигурации была загружена только правилами, то в ней может не быть многих объектов.
Чтобы объекты добавить, вам нужно выгрузить структуру метаданных (описано в пункте "Создание с нуля" немного выше).
И далее загрузить эту структуру в имеющуюся конфигурацию.
Специальные предложения
подчеркнул много интересного) но много где и туман после прочтения статьи) некоторые вещи непонятны) видимо надо ознакомиться с Быстрым освоением КД в самой конфигурации и перечитать вашу статью)
(1) Кирилл, старалась вспомнить с чем у самой возникали трудности, но работаю с конфигурацией довольно давно и многие вещи уже кажутся очевидными.
Напишите мне в личку все вопросы, я расширю статью :)
Конвертация данных - это инструмент создания переноса для ленивых. Умея пользоваться этим инструментом можно быстренько набросать правила и перекинуть из одной базы 1С в другую базу, не обязательно в 1С. Но для реально сложных и постоянных обменов я бы его не рекомендовал. У меня были случаи когда вреда от использования КД было намного больше, чем если бы, долго но качественно, написал свою выгрузку-загрузку через dbf или txt с разделителями.
1) Например обработками из состава КД не контролируется дата запрета редактирования, и можно легко завалить базу в закрытом периоде. Когда данные потащатся по ссылкам.
Найдут эту ошибку через несколько недель, когда будет поздно откатывать из архива. Потом трудозатратное восстановление затертых данных.
2) Отладиться и поймать ошибку в коде, можно, но нужно обладать опытом и сноровкой.
3) Обработки универсального обмена громоздки с плохо читаемым кодом.
4) Файл обмена громоздкий, т.к. содержит текст правил обмена. Структура файла не очень понятна простому смертному. Например Нпп - это номер по порядку и т.д.
5) В случае изменения структуры хотя бы одного реквизита приемника или источника, весь обмен перестает работать, пока заного не перегрузишь конфигурации. Это сильно напрягает, когда конфигурация громоздкая, и постоянно ведется ее доработка или обновления. Например если изменили тип реквизита "строка 100 символов" на "строка неограниченной длины", будет ошибка несоответстия типов, хотя это никак не влияет на обмен.
6) Свой самописный обмен, проще отлаживать, понятная логика и структура файла, надежнее в использовании, файл меньше размером, не нужно гонять правила в файле. Но разрабатывать дольше по времени.
Каждый выбирает свое.
(4)
1. для этого предусмотрены события вызываемые перед загрузкой объектов в целевую БД, вот там та и нужно проверять закрыт период или нет
2. ну есть сложности, однако если правила не автоматически создаются, то ошибки легко находятся, так как все своими золотыми ручками делалось
3. а где легко?
4. ну так пишите правила, которые не будут тянуть за собой все данные из базы, а только те что действительно нужны. файл на выходе не предназначен для конечного юзера, да как и для программиста, это уже из разряда хакерства туда лезть ну или с точки зрения прогера контроль результата
5. ну к слову сказать, в некоторых ситуациях выгружать конфигурацию свежую не имеет смысла, так как к реквизитам объектов можно обращаться не только, если они явно есть в структуре конфигурации, у вас же под рукой язык программирования с поздним связыванием, к реквизиту можно из кода событий обращаться
6. сталкивался я с вручную написанными обменами, ничего хорошего, люди могут еще более странным образом так на извращаться, что мама не горюй
ikalmykia; kyrasol; Алексей Воробьев; Irwin; mib7; Dementor; sys1c; red80; jif; DarkAn; Новиков; MenZurKa; perepetulichka; sergelemon; mythos; + 15 – Ответить
Я не имею права судить Ваши проф качества, но комментарий больше походит на "Я так привык, а другие делают не правильно!"
(6) Раз 20 писал правила на КД разной сложности, и несколько сотен раз свои механизмы обмена, это личной опыт, использования этого инструмента.
Про контроль даты запрета, понятно, что после того как на грабли наступишь, будешь уже втыкать проверки во все возможные обработчики. ТС написал статью для новичков, моя задача их предупредить о всех подводных камнях.
Ни слова не писал, что я так привык а другие делают не правильно, старался объективно написать все приемущества и недостатки данного инструмента, с которыми столкнутся новички.
Свой обмен - это ни какие не правила, нет там вообще правил, забудьте про термины навязываемые фирмой 1С.
По личному опыту, написал свой обмен и забыл на долгие долгие годы.
А правила обмена, постоянно требуют вмешательства, практически после каждого обновления.
А во времена медленного интернета и дорогово траффика, когда обмен работает по расписанию с интервалом 15 минут, от них больше вреда было чем пользы. Самих данных с гулькин нос, зато правила тащим туда-сюда.
Конвертация - это универсальный механизм. А за универсальность всегда приходится платить.
LuxVeritatis; Forest; AZel84; red80; jif; user761890; ice-net; DarkAn; Новиков; kild; IvanovAV; + 11 – Ответить
6) Свой самописный обмен, проще отлаживать, понятная логика и структура файла, надежнее в использовании, файл меньше размером, не нужно гонять правила в файле. Но разрабатывать дольше по времени.
Самый быстрый обмен - это прямая заливка на T-SQL из источника в приемник, без всяких промежуточных файлов и прочего. Но, чтобы напр., написать такой обмен, который бы как и КД тащил все по ссылке, предположим для какого-нибудь типового документа типа РТУ - вы потратите времени столько, сколько на разработку правил для всей конфигурации. Кроме того, в процессе оптимизации, вы придете к еще более сложному варианту когда хранимки хранятся на сервере, вьюшки имеют русские имена и их нужно актуализировать и еще много такой вот магии. Я этого говорю не на бла-бла-бла, а как чел, который ранее такие обмены и писал. Поверите ли на слово, но поддерживать такой обмен в актуальном состоянии и тем более баго-фиксить и трейсить - это задача не на, а в - В несколько раз сложнее чем на любой КД. Поэтому, в последствии, я все всем переписал на КД. Да медленнее, иногда значительно медленнее, но очень просто поддерживаемый и любые вопросы по нему, решаются относительно просто. Аналогичные вопросы на скулевом обмене решаются всегда на стороне скуля и надо обладать хорошими скилами не только в T-SQL как таковом, но и хорошем понимании "внутренней" кухни самой платформы. В итоге, я сейчас, с позиции именно практического опыта, не могу представить - когда я еще буду писать такие велосипедные обмены на скуле.
В данной статье разберем основы технологии обмена данными с помощью 1С:Конвертации данных 3.0 – как это работает, какие преимущества, актуальны ли старые технологии обмена.
Многие специалисты работали с обменами данных в КД 2.0/2.1. Конвертация 3.0 представляет совершенно новую технологию. Сейчас мы расскажем её суть.
В чем суть Конвертации данных 3.0
Конфигурация «Конвертация данных» впервые была выпущена фирмой 1С для платформы 7.7, и с тех пор механизмы обменов данными развивались в рамках одного подхода.
Все обмены между различными по структуре базами 1С требовали написания правил обмена.
При таком подходе в базе-Источнике каждый объект проходит ряд преобразований, которые описаны в правилах, созданных для этой пары баз.
Xml-узел, в который выгружается этот объект, по структуре аналогичен объекту в базе-Приемнике. При загрузке его остается только преобразовать в объект информационной базы.
Для того, чтобы создать правила, нужно знать структуру метаданных базы-Источника и базы-Приемника, и описать преобразование объектов всех нужных типов. Правила выгружаются во внешний xml-файл, который используется каждый раз при выгрузке.
Одна из проблем этого подхода заключается в том, что после каждого изменения конфигурации баз Источника или Приемника необходимо проверять правила на актуальность, что является долгим и не всегда простым процессом.
Тем более, что, если обмен выполняется в обе стороны, то таких правил двое.
В октябре 2014 года была выпущена первая версия «Конвертации данных», редакция 3.0, предназначенная для тестирования.
Новая технология, реализованная в «Конвертации данных 3.0», призвана обособить процессы выгрузки и загрузки, сделать их независимыми. Для этого создана совершенно другая концепция обмена.
Данные будут выгружаться в формат EnterpriseData, который не зависит напрямую от структуры баз Источника и Приемника.
Формат EnterpriseData – это xml-формат, который создан, чтобы стать универсальным для всех обменов как между базами 1С, так и со сторонними базами.
Он предоставляется в виде xsd схемы, на основании которой формируется механизм преобразования объектов между этим форматом и любыми объектами информационных баз. Для упрощения этих преобразований формат EnterpriseData содержит объекты, аналогичные объектам метаданных типовых конфигураций.
При обмене через универсальный формат в каждой из баз содержится только код для преобразования объектов из базы в универсальный формат EnterpriseData и обратно.
При выгрузке не используется информация о том, какую структуру имеют базы-получатели. Поэтому при изменении конфигурации каждой из баз, участвующих в обмене, нужно будет изменить этот код только в этой базе.
Этот код находится в общем модуле МенеджерОбменаЧерезУниверсальныйФормат. Там же находятся и все обработчики событий, и весь механизм преобразования объектов, благодаря чему значительно упрощается процесс отладки. Там же могут быть описаны параметры, с помощью которых можно использовать единожды описанную там логику преобразования объектов для обмена с разными базами.
При необходимости разработчик может изменить структуру формата EnterpriseData для решения более широкого круга задач.
В процессе настройки обмена сама конфигурация «Конвертация данных 3.0» выполняет на данный момент только одну функцию — на базе структуры метаданных баз, участвующих в обмене, и схемы универсального формата она формирует тексты общих модулей МенеджерОбменаЧерезУниверсальныйФормат для каждой из баз.
Удобным будет сформировать эти модули на начальных этапах настройки обмена, а дальнейшие доработки выполнять непосредственно в тексте модулей в конфигураторе.
Новый механизм обмена не исключает также использования правил регистрации. Их настройка в настоящий момент выполняется с помощью конфигурации «Конвертация данных 2.0».
Таким образом, новая технология имеет ряд преимуществ:
- Для обмена между тремя и более базами не нужно создавать отдельные правила для каждой пары баз
- Упрощается поддержка обменов данными в случае изменения конфигураций баз
- Создан новый универсальный формат, который может быть использован, в частности, для обмена со сторонними базами
- Упрощается отладка алгоритмов, используемых при выгрузке-загрузке объектов.
В ближайшей перспективе планируется постепенный перевод всех обменов между типовыми конфигурациями на новый стандарт.
Однако обмен через Универсальный формат не рассматривается как полная замена технологии обменов по правилам. «Конвертация данных» редакции 2.0/2.1 будет поддерживаться и дальше, так как для решения определенного круга задач она остается более удобным и гибким механизмом.
Чтобы узнать, как КД 3.0 выполняет обмен данными, переходите к следующей статье – Конвертация данных 3.0. Новая технология.
PDF-версия статьи для участников группы ВКонтакте
Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.
Если Вы уже участник группы – нужно просто повторно авторизоваться в ВКонтакте, чтобы скрипт Вас узнал. В случае проблем решение стандартное: очистить кеш браузера или подписаться через другой браузер.
Комментарии / обсуждение (51):
К сожалению, да, проблема еще не решена.
На партнерском форуме разработчики периодически выкладывают измененную обработку для выгрузки правил, которая подходит для новых версий конфигураций.
Добрый день!
Как выгрузить один объект в два (три и т.п.)? Например,выгрузить документ на перечисление налогов “ЗаявкаНаПереводДСВБюджет” разбив документ, где в табличной части разные получатели налогов, на соответствующее кол-во документов разбитых по получателям налогов.
Здесь самая большая проблема будет с идентификацией. Если Вы выгружаете один объект в несколько объектов одного типа, то уникальный идентификатор не получится для этого использовать. Придется настроить поиск по полям, но нужно следить, чтобы значения этих полей не менялись ни в источнике, ни в приемнике.
Ольга, добрый день.
Пытаюсь загрузить правила обмена в конвертацию 3.0 на текущих конфигурациях
Источник БП 3.0.53.39
Приемник ЕРП 2.4.1.227
Вопросы
1) Будут ли работать правила из актуальных конфигураций (октябрь 2017) в конвертации 3.0.4.3 или сразу работать 3.0.5.3
2) На сайте 1С написано что одно из отличий между версиями Конвертации 3.0 – работа с табличными частями, можно более подробно об этом, (например когда – как сейчас работает выгрузка/загрузка Табличной части). Пробывал пример с сайта 1С – не вышло.
3) В конфигурации БП 3.0 сейчас два общих модуля – МенеджерОбменаЧерезУниверсальныйФормат и МенеджерОбменаЧерезУниверсальныйФормат13, как система определяет какие правила надо использовать? Как мне определить какой модуль следует использовать для загрузки правил? Как конвертация определяет из какого модуля прочитать правила обмена?
4) Для чего нужно указывать несколько поддерживаемых версий форматов для одной конвертации, мы же ведем разработку только в одном формате, например 1.0 (как в лекциях)
5) Для конфигурации ЕРП пытаюсь загрузить правила синхронизации из файлов (причем для БП 3.0 все получилось), выбрал каталог обмена, выбрал модуль менеджера, выбрал ранее созданную конвертацию ЕРП (указал только одну версию формата – 1.4) и при загрузке ошибка – “Поле объекта не обнаружено”, как победить?
В октябре 2014 года фирма «1С» выпустила первую версию конфигурации Конвертация данных, редакция 3.0.
Эта редакция не является логическим продолжением Конфигурации данных 2.0/2.1, а представляет собой новую технологию. Ключевая идея разработчиков – упростить обмены данными между типовыми конфигурациями, а также избавится от коллизий при обменах данными.
Рассмотрим, как же работает обмен с помощью КД 3.0.
Принципы обмена с помощью Конвертации данных 3.0
Основным отличием новой технологии от существующих является использование универсального формата данных EnterpriseData, через который будут производиться обмены.
Формат EnterpriseData предоставляется в виде двух xsd-схем:
ExchangeMessage
EnterpriseData
Это основная схема, в которой описаны все объекты нового формата, их свойства и типы значений.
Объекты в этой схеме по структуре и наименованию аналогичны объектам метаданных типовых конфигураций. Это сделано для упрощения трансформации объектов типовых конфигураций в универсальный формат и обратно.
Схема содержит объекты для переноса информации трех основных типов: нормативно-справочная информация, документы и остатки на заданную дату.
Эти xsd-схемы в виде XDTO-пакетов входят в подсистему «Обмен данными» БСП начиная с версии 2.2.5.
Для разработки обмена с использованием универсального формата эти схемы должны быть выгружены во внешние файлы и загружены в конфигурацию Конвертация данных 3.0.
Далее разработчик может независимо настраивать обмен для каждой отдельно взятой базы. Он выгружает из нее описание структуры метаданных и также загружает его в Конвертацию данных 3.0. Используя специальный интерфейс, создает логику, согласно которой объекты этой базы могут преобразовываться в объекты универсального формата и обратно. Он настраивает соответствие объектов и типов, пишет обработчики событий, происходящих в разные моменты преобразования объектов.
На основании настроенной таким образом логики конфигурация Конвертация данных 3.0 формирует код, реализующий эту логику.
Он должен быть помещен в общий модуль МенеджерОбменаЧерезУниверсальныйФормат соответствующей базы. В нем содержится механизм преобразования объектов базы данных в универсальный формат и обратно, а также все обработчики событий.
После того, как модуль сформирован, разработчик обмена имеет возможность корректировать все механизмы непосредственно в этом модуле, не используя конфигурацию Конвертация данных. А также он получает возможность простой отладки в случае возникновения ошибок. Можно также загрузить правила из модуля МенеджерОбменаЧерезУниверсальныйФормат обратно в базу Конвертация данных 3.0, чтобы иметь возможность настраивать их в интерфейсе.
Когда настройка преобразования объектов одной базы завершена, разработчик может перейти к настройке обмена для следующей базы.
Разработчики фирмы “1С” регулярно выпускают новые версии формата, добавляя новые объекты и адаптируя существующие под последние версии типовых решений. При этом несколько предыдущих версий также остаются в конфигурации. Поэтому база, обновленная до последней версии типового решения, может обмениваться с базами чуть более старых версий, если в них есть совпадающие версии формата.
При необходимости разработчик может сам незначительно изменять предоставленные схемы, или разработать собственный формат, если это требуется. Для каждой версии каждого формата должна быть описана своя логика преобразования объектов.
Пользовательский интерфейс обменов через универсальный формат в БСП приближен к интерфейсу типовых обменов по правилам, что облегчает переход на новый формат с точки зрения обучения пользователя.
PDF-версия статьи для участников группы ВКонтакте
Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.
Если Вы уже участник группы – нужно просто повторно авторизоваться в ВКонтакте, чтобы скрипт Вас узнал. В случае проблем решение стандартное: очистить кеш браузера или подписаться через другой браузер.
Читайте также: