Что такое кд2 в 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. Порядок правил выгрузки данных
Рекомендуется располагать правила выгрузки данных в таком порядке, что бы ссылки зависимых объектов были снизу вверх. то есть самыми первыми должны располагаться правила выгрузки данных, объекты которых ни на кого не ссылаются, затем должны идти правила выгрузки объектов, ссылающихся на первую группу и т.д.
Пример: Нужно выгрузить два справочника Пользователи и Физические лица. Справочник Пользователи имеет реквизит Физ. лицо - ссылка на справочник Физические лица. То есть справочник Пользователи ссылается на справочник Физические лица. Рекомендуемая последовательность правил выгрузки в этом случае: Физические лица, пользователи.
2. Выбирать данные для выгрузки одним запросом
Если в правиле конвертации нет переноса табличных частей и движений, а так же в событиях перед выгрузкой нет прямых обращений к выгружаемому объекту, рекомендуется в правиле выгрузки данных использовать режим "Выбирать данные для выгрузки одним запросом". Этот режим позволит одним запросом получить все выгружаемые данные определенного типа, а не строить отдельные запросы для выгрузки каждого объекта.
Правила Конвертации объектов
3. Использовать быстрый поиск при загрузке
Этот режим выгрузки и загрузки рекомендуется использовать для тех правил конвертации объектов, которые выгружают ссылочные типы общее количество которых сравнительно небольшое (примерно до 1000 элементов), на которые имеется множество ссылок в других объектов.
Пример: Справочник Пользователи. Практически все документы имеют ссылку на этот справочник и количество элементов справочника не превосходит 1000.
4. Не выгружать объекты свойств по ссылкам
Режим позволяет для правила конвертации объектов не выгружать все элементы на которые есть ссылки. Если режим установлен, то при выгрузке будет выгружен сам объект и информация для поиска всех его ссылок, но полная информация о зависимых элементах выгружена не будет. Эта оптимизация может в несколько раз ускорить выгрузку и загрузку данных.
5. Не запоминать выгруженные объекты
Для правил конвертации не ссылочных объектов (регистров) нужно установить флажок "Не запоминать выгруженные объекты", так как ссылаться на строки регистра нельзя, поэтому нет и смысла запоминать те строки регистров, которые были выгружены. Для ссылочных объектов этот флажок, как правило, нужен, что бы оптимизировать повторное обращение для выгрузки одного и того же объекта.
6. Не делать общих обработчиков событий для всех объектов
Не рекомендуется использовать общие обработчики событий перед выгрузкой и загрузкой данных для всех объектов. Обработки выгрузки и загрузки не знают что будет выполняться в этих обработчиках поэтому некоторые оптимизации (например, при загрузке запись только измененных объектов) действовать не будут. Если есть необходимость использовать одни и те же алгоритмы обработки данных при выгрузке и загрузке, то рекомендуется создать новый Алгоритм, а в событиях у нужных объектов его вызывать.
Обработка "Универсальный обмен данными XML"
7. Использовать оптимизированный формат для обмена данными
8. Загружать данные в режиме обмена
Позволяет отказать от излишних проверок на этапе загрузки данных
9. Записывать только измененные объекты
Позволяет производить запись только измененных объектов в информационную базу. Если объект изменен не был, то при загрузке из файла обмена он не будет перезаписан.
10. Оптимизированная запись объектов
Режим позволяет резко сократить количество обращений в информационной базе для записи объектов.
11. Записывать регистры наборами записей
Режим позволяет записывать изменения в регистрах наборами записей, а не менеджерами записей.
12. Обмен данными через COM
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Конвертация данных 2.0 и 2.1 — технологическая конфигурации фирмы 1С, реализованная на версии платформы от 8.1 до 8.3.
Главная задача инструмента — написание правил обмена между прикладными решениями 1С 8 и 7. Актуальная версия конвертации данных сегодня — 3.0.
Конвертация данных — очень полезная конфигурация, с помощью неё можно решить не только вопрос переноса информации из одной информационной базы в другую, но и, например, преобразование информации внутри одной базы.
Конфигурацию очень удобно использовать при переносе остатков в 1С.
Конвертация данных будет полезна любому программисту: наличие навыков создания правил обмена — это серьезный плюс к профессиональным навыкам.
Обучение 1C Конвертация данных 2.0
Для обучения работы с конфигурации лучше всего подойдет решение практических задач. Попробуйте придумать себе задачи, например: перенести какую-либо информацию из одной базы в другую, превратить документ реализации в документ поступления, «загнать» текущие остатки по бухгалтерскому учету в документ «ввода остатков» и другие задачки.
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
Очень полезно будет разобраться в «типовых» правилах обмена 1С 8.3, там зачастую можно найти интересные примеры реализации задач.
Для постижения основ вам потребуются материалы, рассмотрим их ниже.
Видео инструкция по конвертации
Азы настройки обмена данными в 1С с помощью конфигурации «1С Конвертации данных» на примере смотрите в видео:
Материалы, учебники для изучения 1С Конвертации данных 2.0
Материалов и документации в сети не слишком большое множество, я попробовал собрать самые важные и интересные материалы:
0. Первым делом советую бесплатный видеокурс Ильи Леонтьева, он доступен по ссылке.
1. Я бы посоветовал прежде всего пользоваться встроенной справкой в конфигурацию. Она действительно неплохо написана и грамотно реализована технически:
3. Отдельно хотелось бы выделить методичку учебник — Конвертация_данных._Методика_работы_и_примеры (автор — Ольга Кузнецова).
Другие статьи по 1С:
Видеокурс по 1С конвертации данных:
Читайте также: