Основные концепции Конвертации данных (КД) для новичков

26.10.17

Интеграция - Обмен между базами 1C

В КД очень важно понять основные принципы работы. Вроде и самой КД сто лет в обед, и понаписано уже не счесть, но все как-то не так, как мне бы хотелось. Постепенно крепло желание написать эдакое послание самому себе, начинающему изучать КД, да никак руки не доходили. Последней каплей стала очередная попавшаяся на глаза "неправильная" статья, и я решил - ничего страшного, пусть будет еще одна статья, зато гештальт закрою :) Даже если я излишне самонадеян, авось кому-то она все же поможет. Скриншотов не будет, будет только унылый текст. Но я бы в свое время за него многое отдал. Чтобы не перегружать статью, в ней не освещаются особенности вроде правил регистрации, особенностей КД 3.0 и т.п.

КОНЦЕПЦИИ ОБМЕНА ДАННЫМИ

Правила конвертации. "Конвертация данных" (далее "КД") - это конфигурация/база 1С, где описываются правила, по которым данные из базы-источника (далее "источник") должны преобразовываться в данные базы-приемника (далее "приемник"). Эти правила выгружаются в xml-файл. И все. Больше КД не делает ничего. Несмотря на название, сама конвертация данных - это уже не ее забота. Это просто "конфигуратор" (или если хотите - IDE для разработки правил). Кто же выполняет саму конвертацию? Изначально за это отвечали внешние обработки выгрузки/загрузки, входящие в комплект поставки КД.

Выгрузка. Обработка выгрузки запускается в источнике, ей указывается файл с правилами из КД, некоторые дополнительные настройки выгрузки (типа отборов данных) и обработка формирует файл обмена. И тут важный момент - в файл обмена пишутся УЖЕ КОНВЕРТИРОВАННЫЕ согласно правилам конвертации данные (фактически это готовые образы объектов для загрузки в приемник) плюс информация из правил обмена о поиске нужных объектов в приемнике, плюс тексты программных обработчиков, которые должны быть выполнены при загрузке данных в приемнике (они будут выполняться в нужных местах с помощью банального "Выполнить"). Теперь повторю важный момент с другого ракурса - в нормальной ситуации ВСЯ КОНВЕРТАЦИЯ ВЫПОЛНЯЕТСЯ В ИСТОЧНИКЕ. То есть и все правила конвертации с их взаимосвязями анализируются в источнике и почти все самые важные с точки зрения конвертации программные обработчики - также выполняются в источнике. Этот момент нужно держать в голове, когда вы пишите код программных обработчиков в КД. Это обычный код 1С, который будет исполнен в источнике с помощью инструкции "Выполнить" в контексте алгоритма выгрузки данных. И, соответственно, в этом контексте вы имеете полный доступ к базе источника и можете писать любой корректный для нее код 1С. А как же упомянутые обработчики "при загрузке", спросите вы? Скажу, что в 99% случаев обработчики на стороне приемника не нужны. Но новички часто ими злоупотребляют по банальной причине - они еще не знают, как настроить правила конвертации правильно, а обработчики в приемнике как-то проще для понимания. Код - он и в Африке код :) Но такой стиль ущербен по многим причинам, так как идет в разрез с неявной идеологией КД. Плюс использование обработчиков при загрузке часто сильно замедляет эту самую загрузку. В нормальной конвертации загрузка сводится просто к поиску/созданию нужного объекта и загрузке в него готовых данных, конвертированных еще в источнике. Но если обработчики "при загрузке" вам все-таки нужны, в них, естественно, вы пишите код уже для приемника. Прямого доступа к источнику там уже нет.

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

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

Итак, первоначально обмен данными между разными конфигурациями производился через внешние обработки. Но потребностей и задач обмена данными становилось все больше, какие-то части алгоритмов обработок выгрузки/загрузки стали засовывать в универсальные модули типовых конфигураций (предтеча БСП) плюс добавляли дополнительный функционал обмена в типовых (вроде использования планов обмена, работы через COM и прочее), потом появилась БСП где это все выделили в отдельную подсистему и навешали сверху еще плюшек, но основа остается неизменной. Просто правила конвертации, сделанные в КД, теперь засовываются в нужные места типовых на базе БСП и поверх этого накручено еще много полезных настроек, которые делаются уже в рамках подсистемы БСП "Обмен данными" (подробнее про все богатство ее функционала читайте на ИТС в документации по БСП в описании подсистемы "Обмен данными").

КОНЦЕПЦИИ РАЗРАБОТКИ ПРАВИЛ КОНВЕРТАЦИИ

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

Конфигурации. Очевидно, что КД должна обладать знаниями о метаданных источника и приемника. Они загружается в служебные справочники (главный из них - "Конфигурации") через xml-файлы (которые выгружаются из баз источника/приемника специальными обработками, входящими в состав поставки КД). Соответственно, если конфигурации баз источника/приемника изменяются, то описание их метаданных в КД тоже нужно обновлять. Или не нужно, если изменения не затрагивают конвертацию :)

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

Правил конвертации объектов (далее ПКО). ПКО - сердце КД. Как следует из названия, каждое ПКО отвечает за конвертацию какого-то вида объекта (справочника, документа и пр). Нужно понимать, что само по себе ПКО - штука пассивная. Ему надо каким-то образом на вход подать данные, а на выходе оно "выплюнет" образ объекта-приемника для записи в файл обмена. Я обтекаемо написал про "данные" на входе, потому что не всегда в источнике есть подходящий объект (если конфигурации сильно отличаются). Это может быть и программная структура. Если случай простой, и выполняется конвертация "объект-объект", то тогда прямо в свойствах ПКО указывается исходный объект источника и это облегчает дальнейшую настройку. Но в общем случае объекта-источника может и не быть - тогда данные на вход формируются программно. Может быть несколько разных ПКО для одного и того же объекта приемника, но для разных целей.

У ПКО перечислены ряд событий при выгрузке/загрузке, для каждого из которых можно написать программный обработчик. И львиная доля гибкости КД зарыта именно в этих обработчиках. Чаще всего используется парочка первых обработчиков ("перед выгрузкой", "перед обработкой" и иже с ними). Вся хитрость в том, что обработчики выполняются в специальном контексте, из которого программно можно влиять на сценарий конвертации. Они имеют доступ к ряду заготовленных "ручек" и "кнопочек", которые позволяют реализовывать различные сценарии обмена. Все, что вам нужно для понимания глубины глубин КД после осознания концепций - это ВСТРОЕННАЯ СПРАВКА по этим обработчикам (доступна обычно по кнопке "Информация по обработчикам"). Там описаны все доступные спец-параметры, момент срабатывания события и даже даны примеры использования. Внимательное и вдумчивое чтение этой справки быстро подскажет и покажет вам все доступное многообразие возможных сценариев конвертации так полно и глубоко, как ни в одной книжке не напишут. Ну, например, с помощью параметров "ИсходящиеДанные" и "ВходящиеДанные" можно передавать данные между обработчиками и между разными ПКО, что в отдельных случаях чрезвычайно полезно и позволяет создавать гибридные ПКО ("объект-объект", но часть данных получающих как "ВходящиеДанные").

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

Правила конвертации свойств (далее ПКС). Суть у ПКС такая же, как у ПКО, только уровнем ниже - "выплюнуть" на выход конвертированное поле объекта приемника для записи в файл обмена. Так как в процессе отработки ПКО у самого ПКО так или иначе поданы на вход какие-то данные, то по умолчанию на вход ПКС также подается одноименное свойство из этих данных. Если у ПКО явно задан источник, то можно параметрически выбрать поле источника, которое будет подано на вход (это самый простой случай). Также данные на вход можно подать программно. Итак, данные на входе есть, нужно теперь их при необходимости конвертировать. Если поле имеет примитивный тип и на вход подан такой же - то красота. Вообще ничего делать не надо. А если не примитивный? Тогда... можно параметрически выбрать готовое ПКО, по которому оно будет конвертировано! Вот ради этого красивого жеста и был весь сыр-бор. Единожды оформленное ПКО можно переиспользовать во всех ПКС всех ПКО, где это необходимо. КД по умолчанию поддерживает конвертацию по ссылкам. Это означает, что при конвертации объекта по ПКО входные данные из его ПКС будут переданы на вход указанным в них ПКО и все это рекурсивно повторяется вниз-вниз-вниз. В результате будут автоматически конвертированы и выгружены ВСЕ связанные объекты (это поведение можно изменить). Правда, красота нечеловеческая? Как-то мне пришлось самому писать похожую систему для тесной интеграции 1С с одним внешним продуктом и конвертацией по ссылкам. С тех пор я нежно люблю КД.

У ПКС, так же как и у ПКО, есть собственный набор обработчиков со своими "ручечками" и "кнопочками". Про важность этих обработчиков уже было написано выше, но для ПКС они еще важнее, чем для ПКО, так как по сути собственно конвертация часто выполняется именно на уровне ПКС. Например, в этих обработчиках можно динамически менять ПКО, по которому будет конвертироваться свойство (в зависимости от каких-то условий). Там есть доступ ко всему объекту, поданному на вход ПКО (параметр "Источник"). Можно прямо в обработчике программно назначить данные, которые будут поданы на вход ПКС (параметр "Значение") - это часто используется для конвертации примитивных типов и не только. И многое, многое другое (читайте справку по обработчикам).

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

Правил выгрузки данных (ПВД). Задача ПВД предельно проста - выбрать данные источника, "скормить" их на вход какого-нить ПКО и умыть руки. Можно сказать, что в отличие от пассивных ПКО, ПВД - активны. Они выбирают данные, передают их ПКО и дают отмашку на конвертацию.

В самом своем примитивном виде, при выгрузке "объект-объект" для вида выборки "стандартная выборка" достаточно параметрически указать вид объекта источника и ПКО для него. И все. В обработке выгрузки можно будет активировать это правило и указать для него стандартные отборы (при необходимости).
Для более сложных случаев предусмотрен вид выборки "произвольный алгоритм" и... правильно! ОБРАБОТЧИКИ! :) Можно, например, запросом сформировать нужную выборку данных и подать ее на вход ПКО без источника. Для произвольных выборок будут недоступны стандартные отборы обработки выгрузки, но внутри можно использовать параметры конвертации.

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

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

КД конвертация данных концепции

См. также

SALE! 20%

Перенос данных из УПП 1.3 в ERP 2 / УТ 11 / КА 2. Переносятся документы, справочная информация и остатки

Обмен между базами 1C Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) в продаже с 2015 года, постоянно работаем над их развитием | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор

45650 36520 руб.

04.08.2015    159698    363    267    

345

SALE! 15%

[ED3] Обмен для ERP 2.5, КА 2.5, УТ 11.5 БП 3.0, Розница, УНФ и других с EnterpriseData (универсальный формат обмена), правила обмена

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

25080 22572 руб.

12.06.2017    134944    723    291    

388

SALE! 20%

Перенос данных из ERP 2 / КА 2 / УТ 11 в БП 3.0. Переносятся документы, начальные остатки и справочники

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос данных из ERP в БП 3 | из КА 2 в БП 3 | из УТ 11 в БП 3 | из ЕРП в БП 3 | В продаже с 2019г. | Воспользовались более 176 предприятий! | Сэкономьте время - используйте готовое решение для перехода! | Перенос разработан в формате КД 2 (правила конвертации данных) | Переносятся все возможные виды документов, начальных остатков и нормативно-справочная информация| Можно опционально выгружать каждую пару "номенклатура+характеристика" как отдельную номенклатуру | Есть выгрузка настроек счетов учета и зарплатных данных из ERP / КА 2 | Можно проверить на вашем сервере перед покупкой, обращайтесь!

34650 27720 руб.

15.04.2019    68425    178    138    

111

SALE! 20%

Перенос данных из ERP 2 / КА 2 в ЗУП 3. Переносятся остатки, документы и справочники

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из ERP в ЗУП 3 | из КА 2 в ЗУП | Воспользовались более 79 предприятий! | Предлагаем приобрести готовые правила конвертации данных (КД 2) для переноса остатков, документов с движениями и справочной информации 3 | В продаже с 2020г. | Оперативно обновляем правила до актуальных релизов 1С | Есть перенос начальной задолженности по зарплате и начальной штатной расстановки на выбранную дату | Обороты за прошлые годы (данные для расчета среднего) переносятся свернуто в документ "Перенос данных" | Есть фильтр по организациям | Документы за текущий период переносятся сразу с движениями, поэтому не потребуется делать перерасчеты | Перенос можно проверить перед покупкой, обращайтесь!

43450 34760 руб.

03.12.2020    34172    80    58    

78

SALE! 10%

Перенос данных из УТ 10.3 в УТ 11.5. Переносятся документы (обороты за период), справочная информация и остатки

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 10 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УТ 10.3 (10.3.87.x) и УТ 11.5 (11.5.16.x).

28000 25200 руб.

23.07.2020    46301    196    64    

158

SALE! 10%

Перенос данных из БП 3.0 в УТ 11 / КА 2 / ERP 2. Переносятся начальные остатки, документы и справочники

Обмен между базами 1C Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

В продаже с 2014г. | Воспользовались более 122 предприятий! | Перенос данных из БП 3.0 в УТ 11 | из БП 3.0 в КА 2 | из БП 3.0 в ERP | Сэкономьте свое время - используйте готовое решение для перехода! | Постоянно работаем над развитием переноса данных | Обновляем на новые релизы 1С | Есть фильтр выгрузки по организациям | Переносятся начальные остатки на выбранную дату, документы за период времени и вся возможная справочная информация | Перенос сделан на технологии КД 2 (правила конвертации данных)

50722 45650 руб.

31.10.2014    231425    124    327    

296

Перенос данных из Парус 10 в ЗГУ ред.3

Внешние источники данных Кадровый учет Файловый обмен (TXT, XML, DBF), FTP Обмен между базами 1C Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 10 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

60000 руб.

05.10.2022    9212    9    8    

10

SALE! 10%

Перенос данных из УПП 1.3 в БП 3.0. Переносятся документы (обороты за период), справочная информация и остатки

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.223.x) и БП 3.0 (3.0.149.x). Правила подходят для версии ПРОФ и КОРП.

28000 25200 руб.

15.12.2021    20255    132    38    

90
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. leosoft 165 17.10.17 19:31 Сейчас в теме
Супер!
Когда же разработчики научатся так качественно доносить
заложенные ими алгоритмы и идеи?
2. ekaruk 4896 18.10.17 07:38 Сейчас в теме
Отлично описано.
Кратко и сама суть.
3. babys 90 18.10.17 09:03 Сейчас в теме
Как то однобоко. Такое впечатление, что автор совсем забыл про ПКО: Перед загрузкой, При загрузке и После загрузки. Оченно нужОннеы и полезные финтифлюшки.
ИМХО, конфликты загрузки в рамках написанной статьи не решите никогда.
4. progr-2008 118 18.10.17 09:34 Сейчас в теме
Для новичков - полезно.
Eillecho; +1 Ответить
5. JaneP 14 18.10.17 10:45 Сейчас в теме
Плюсанула. Читала внимательно, поэтому простите, есть "ньюанс" :)
Eillecho; jokereinherjar; +2 Ответить
6. pm74 199 18.10.17 10:58 Сейчас в теме
что в 99% случаев обработчики на стороне приемника не нужны. Но новички часто ими злоупотребляют по банальной причине - они еще не знают, как настроить правила конвертации правильно, а обработчики в приемнике как-то проще для понимания. Код - он и в Африке код :) Но такой стиль ущербен по многим причинам, так как идет в разрез с неявной идеологией КД

да ну? ну а например заполнение счетов по регистрам в БП , деление документов 1 в 2 итд итп . Есть целый класс задач , которые просто невозможно выполнить на стороне источника
7. herfis 498 18.10.17 11:01 Сейчас в теме
(6) Единственный класс задач конвертации, которые невозможно выполнить на стороне источника, я в статье упомянул - если информацию для принятия решения невозможно получить в источнике. Все остальное - РЕШАЕТСЯ.
8. pm74 199 18.10.17 11:02 Сейчас в теме
(7) ну так это очень частое явление
9. herfis 498 18.10.17 11:08 Сейчас в теме
(8) Из моей практики - вовсе нечастое. Относительно часто требуются лишь некоторые предопределенные данные приемника. А это решается либо конвертацией значений, либо хардкодингом при выгрузке, либо таблицами соответствий.
Пример (к месту или не к месту) - если нужно выгружать ссылки на бухгалтерские счета, а в источнике тупо нет плана счетов (но коды счетов мы знаем, т.е. информации для принятия решений достаточно), то делается просто ПКО для плана счетов с признаками только поиска нужных объектов в приемнике (без создания и изменения), добавляется ПКС для кода счета (с галкой, что оно является полем поиска) и ему на вход программно подается код счета. Все. При загрузке по коду счета будет найден нужный счет и проставлена нужная ссылка.
Выгрузить два документа из одного тоже не вижу никакой проблемы. Если подробнее опишите ситуацию, приведу пример конкретного решения.
10. pm74 199 18.10.17 11:11 Сейчас в теме
(9) просто задела некоторая категоричность утверждения . мне кажется данные можно приводить к общему знаменателю на той стороне где это сделать проще (читай надежнее)
11. herfis 498 18.10.17 11:22 Сейчас в теме
(10) Эта категоричность появилась не с бухты-барахты. У меня многолетний опыт работы с КД и обмена между принципиально разными конфигурациями и самыми головоломными схемами. И количество раз, когда понадобились обработчики на стороне приемника, можно пересчитать на пальцах.
26. TerveRus 17.05.18 09:54 Сейчас в теме
(11) зачем мне что-то изобретать на стороне источника, если я на стороне приемника могу просто написать ЗаполнитьСчетаУчета(). то есть вызвать уже готовую типовую процедуру, и все? Можно категорично все решать на стороне источника, но бессмысленная и глупая трата времени и сил.
Eillecho; InfolineDV; jokereinherjar; +3 Ответить
12. 1Concept 261 18.10.17 16:49 Сейчас в теме
Спасибо за статью, очень хорошо подано.
Уважаемый Сан Саныч, выскажите экспертное мнение, относится ли одна задача к тем самым 99%, о которых вы пишите:
Есть табличная часть, и в ней один реквизит никогда не заполняется в Источнике. После первой загрузки в Приемник этот реквизит заполняется руками, но после следующих обменов Источник-Приемник реквизит очищается, флаг "Отключить" в ПКС для реквизитов ТЧ не работает.
Я решил эту задачу в обработчике ПослеЗагрузки ПКО данного документа: ищу объект и из него беру постоянно очищаемый реквизит ТЧ:
Если ОбъектНайден = Истина Тогда
    //подставляем карточку анализа
    Если Объект.Ссылка.Товары.Количество() > 0 И Объект.Товары.Количество() > 0 Тогда
        КарточкаАнализаСсылка = Объект.Ссылка.Товары[0].КарточкаАнализа;
        Если ЗначениеЗаполнено(КарточкаАнализаСсылка) Тогда
            Объект.Товары[0].КарточкаАнализа = КарточкаАнализаСсылка;
        КонецЕсли;
        Попытка
            Объект.Записать(РежимЗаписиДокумента.Запись);
        Исключение
        КонецПопытки;
    КонецЕсли;
КонецЕсли;
Показать


Относится ли моя задача к оставшемуся 1% или её тоже можно как-то решить на стороне приемника?
p.s. в моем случае в ТЧ всегда будет одна строка, поэтому не критикуйте мой неуниверсальный подход.
13. herfis 498 18.10.17 17:02 Сейчас в теме
(12) Авторитетно заявляю - фиг его знает! Всегда как-то удавалось избегать частичного обновления объектов в приемнике. Так что увы - навскидку ничего путного не присоветую. Надо бы исследовать вопрос, но руки не стоят. Пару раз на заре КД и возникновении подобных затыков, которые касались явных недоработок КД в части редко используемой функциональности, мне было проще пропатчить КД :)
16. Vladimir_Konyrev 255 18.10.17 21:14 Сейчас в теме
(13) (14) (15) Коллеги, премного благодраен.
14. pm74 199 18.10.17 17:08 Сейчас в теме
(12) вобще у пкс есть галка - не замещать значение в приемнике, на обычных реквизитах срабатывает, но в случае ТЧ не факт , надежнее ручками вписать как вы делаете
15. herfis 498 18.10.17 17:18 Сейчас в теме
(12) Немного подумав... Изначально в КД вообще было плохо с частичным обновлением объектов. Потом вроде допилили. Но боюсь, что с обновлением табличных частей там вообще не заморачивались. Ведь мало того, что для этого нужно приложить значительные усилия - непонятно как решать вопрос с однозначной идентификацией строк табличной части. Поэтому при такой постановке задачи особых вариантов я не вижу.
В идеале - заполнять в источнике. При невозможности - как раз попадаем на вариант, когда в источнике нет необходимых данных :(
17. OgelO 1 20.10.17 09:28 Сейчас в теме
Толковый материал, спасибо!
18. Zoomby 20.10.17 09:47 Сейчас в теме
19. nvv1970 22.10.17 00:15 Сейчас в теме
Плюс использование обработчиков при загрузке часто сильно замедляет эту самую загрузку
Дельное замечание.
Стоило бы пояснить читателям, что сама по себе нагрузка здесь погоды не делает. Как бы тратим процессорное время в любом случае: или при загрузке или при выгрузке - в общем случае одинаково, но зависит от алгоритмов.
А вот наиболее болезненным моментом загрузки может быть наличие транзакции и следовательно блокировок. Дольше выполняем - дольше блокируем.
20. herfis 498 23.10.17 09:11 Сейчас в теме
(19)
А вот наиболее болезненным моментом загрузки может быть наличие транзакции и следовательно блокировок. Дольше выполняем - дольше блокируем

Все верно. В обработчиках мало кто заморачивается специальным кэшированием и типичный код сплошь и рядом полон явных и неявных обращений к БД, по факту выполняемых в цикле и никак не оптимизированных. При выгрузке подобное редко становится критичным. Загрузка же гораздо более чувствительна, так как выполняет запись в БД и даже чистая запись в БД может занимать значительное время сама по себе. Про накладные расходы на "Выполнить" я уже не упоминаю. Если же удается всю конвертацию выполнить в источнике - то при загрузке выполняются только оптимизированные алгоритмы КД по записи конвертированных образов.
21. gucci76 364 26.10.17 12:24 Сейчас в теме
Было бы здорово выложить самый примитивный пример правил конвертации.
Теория, которую можно пощупать на практике усваиваются намного лучше!!!!
22. herfis 498 26.10.17 13:06 Сейчас в теме
(21) Такие статьи уже есть, цель моей статьи была другая.
Вот, например, хорошее подробное практическое руководство для новичков, куда тыкать на практике.
Должно отлично зайти в качестве практической части :)
ЗЫ. Добавил ссылку на нее в мою статью, чтобы новичкам было проще переходить от теории к практике :)
23. Eriksson 23.12.17 02:16 Сейчас в теме
Теперь повторю важный момент с другого ракурса - в нормальной ситуации ВСЯ КОНВЕРТАЦИЯ ВЫПОЛНЯЕТСЯ В ИСТОЧНИКЕ. То есть и все правила конвертации с их взаимосвязями анализируются в источнике и почти все самые важные с точки зрения конвертации программные обработчики - также выполняются в источнике. Этот момент нужно держать в голове, когда вы пишите код программных обработчиков в КД.


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

Я, к примеру, не занимаюсь постоянно конвертацией, из памяти некоторые вещи улетают. Время, которое я могу потратить на рытье в старых правилах или чтении статей по конвертации для сложных случаев обмена заменяю на время обработки компьютером во время загрузки. Это характерно только для задач разовой выгрузки-загрузки данных.
24. herfis 498 27.12.17 13:52 Сейчас в теме
(23)
Следует отметить, что существует два основных варианта применения конвертации

Лично мне кажется, что достаточно один раз разобраться с принципами, чтобы больше не иметь особых проблем с КД. Поэтому и сподвигся на написание статьи. Я ведь тоже нечасто с ней работаю и на память жалуюсь. Но спорить над цена/качество не готов. Всем приходилось что-то писать на скорую руку. Это дело такое. Но объявлять это прям отдельным направлением программирования я бы не стал :)
25. mitia.mackarevich 72 26.01.18 18:11 Сейчас в теме
"Вот для таких редких случаев на выручку и приходят обработчики на стороне приемника (при загрузке)." М да....они настолько редкие что встречаются почти в каждом нормально обмене (объектов так на 150),а не поделках. Разумнее применять обработчики там где это необходимо (да КЭП где то близко), с точки зрения производительности, логики, архитектуры самого решения. Не стоит забывать что блокировки возникают не только при загрузке, но и при выгрузке.
27. aegoncharov 18.02.22 12:59 Сейчас в теме
Добрый день.
Проведите маленький ликбез, пожалуйста.
Что концептуально нужно, чтобы настроить двусторонний обмен между разными конфигурациями при помощи правил обмена на КД2?
Нужно разработать отдельно правила Конф1 -> Конф2 и отдельно Конф2 -> Конф1?
Они напрямую не взаимосвязаны и могут быть разработаны независимо? Главное, чтобы конфигурации для них использовались одинаковые?
28. herfis 498 18.02.22 13:58 Сейчас в теме
(27)
Нужно разработать отдельно правила Конф1 -> Конф2 и отдельно Конф2 -> Конф1?

Да.
(27)
Они напрямую не взаимосвязаны и могут быть разработаны независимо?

Да.
aegoncharov; +1 Ответить
Оставьте свое сообщение