Сокращения:
КД2 — Конвертация данных 2
КД3 — конвертация данных 3
ПОД — правило обработки данных.
ПКО — правило конвертации объекта.
ПКС — правило конвертации свойства.
ПКПД — правило конвертации предопределенных данных.
ПРО — Правило регистрации объектов.
1. Группы правил.
В КД2 разделение по объектам метаданных происходило автоматически. В КД3 для удобства необходимо создать группы правил разделив их по объектам метаданных.
2. XDTO. Ключевые свойства и обязательные поля.
В КД3 обмен настраивается через универсальный формат (EnterpriseData). И поэтому при настройке обмена нужно смотреть состав пакета XDTO EnterpriseData.
Рассмотрим для примера описание справочника Номенклатура. Первое поле это Ключевые поля. Ключевые поля определяют те данные, которые будет передаваться всегда в xml схеме при выгрузки поля. И эти поля конвертация данных будет требовать обязательно заполнить при настройке отправки данных.
Кроме ключевых полей еще есть обязательные поля которые нужно обязательно определить.
"ТипНоменклатуры" является обязательным, т.к. в свойстве поля определено мин.количество=1 макс.количество=1
"Описание" является необязательным, т.к. в свойстве поля определено мин.количество=0 макс.количество=1
3. Правило конвертации объекта (ПКО) и правило обработки данных (ПОД).
Перед созданием ПОД нужно создать ПКО.
Далее созданное ПКО нужно подвязать к ПОД
Цифрами я указал порядок заполнения ПОД. Также не забыть заполнить и поле "группа"(группа правил).
4. Иерархические справочники
В КД3, чтобы обработать для отправки иерархические справочники необходимо создать два ПКО (одно ПКО для групп элементов, а другое для элементов) и одно ПОД.
К ПОД привязать два ПКО (для этого поставить соответствующий флажок)
"При обработке" написать код, который определит когда использовать одно ПКО, а когда другое.
При получении данных необходимо создать два ПКО и два ПОД и в одном из ПОД поставить флажок "Правило для группы справочника"
5. Правило конвертации предопределенных данных (ПКПД).
В КД2 обмен настраивался между двумя конфигурациями. В КД3 обмен настраивается через универсальный формат (EnterpriseData). Может так получится что при конвертации перечислений в универсальном формате не будет таких значений как у вас в базе или не будет вообще такого перечисления как у вас.
Если в значениях формата не хватает значений, то можно ставить одинаковые и передавать значение перечислений в AdditionalInfo (про AdditionalInfo в пункте 7).
6. Табличная часть
Табличную часть можно отправить и принять только алгоритмом конвертации
При отправке делаем запрос к данным и выгружаем Таблицу значений
Для Получения тоже используется алгоритм конвертации
Алгоритмы — это часть кода, который используется в нескольких местах. В конвертации так реализован механизм Процедур и Функций. Ниже видно что вызывается функция, которая расположена во вкладке Алгоритмы. Эта функция подготавливает данные для загрузки их в "табличную часть".
7. AdditionalInfo
Если в формате нет реквизитов для конвертации реквизитов конвертации, тогда можно использовать поле AdditionalInfo.
У всех объектов (справочников, документов и др.) в EnterpriseData базовый тип Object. В описании этого типа, который находится пакете XDTO ExchangeMessage, есть свойство AdditionalInfo, которое наследуют все объекты.
Этим свойством можно пользоваться для переноса данных, которые не смогли сопоставить в формате EnterpriseData.
Принимаю признак проведен. В КД3 Если у документа установлен признак ПолученныеДанные.Проведен, то документ проводится.
(В КД2, если передать просто проведен = Истина. Документ будет с признаком проведен, но фактически движений не сделает)
8. Отправка Структуры с Значение и ИмяПКО
Если в табличной части есть реквизит составного типа. То при отправке нужно определить тип каждого элемента табличной части при помощи алгоритма. Рассмотрим на примере документа СФПолученая табличная часть "документы основания"
В алгоритме по типу документа определяем соответствующее ему ПКО.
9. Правило регистрации объектов (ПРО)
ПРО в КД3 не реализовано поэтому для настройки ПРО применяется КД2
В этом примере выгружаются только проведенные Поступления.
После сохранения правила в файл его нужно загрузить в настройку обмена базы из которой производим отправку данных.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
вполне полезно.
самое забавное — тут тот редкий случай когда обилие скринов к месту и не мешает прочтению.
обычно бестолочи накидают скринов для массовки и чтобы скрыть(за картиками) свое неумение подать материал.
тут, повторюсь, годно и вполне хорошо.
Полезный материал, спасибо. Особенно для тех, кто начинает разбираться с КД 3.0.
Небольшие дополнения:
В последних релизах КД можно просто настройкой выгрузить ТЧ, без алгоритма.
Как вариант, можно еще дополнительные свойства использовать. Они почти у каждого объекта в формате есть.
Можно использовать таблицу «КомпонентыОбмена.ПравилаКонвертацииОбъектов» и найти имя ПКО по объекту метаданных.
По-моему в тестовой КД3 уже есть возможность ПРО создавать.
Эх, вот бы на полгодика раньше такую статью мне)))) А то все пришлось через боль постигать))) Спасибо за материал. Однозначно в избранное!!!
Грамотный новичковский обзор чтобы «вкурить». Мало таких материалов мне попадается, а тут и легко читается и понятно.
Не все скриншоты отображаются, почему?
Автор статьи молодец… Но КД 3.0 — это зло…
Считаю, что обмен через универсальный формат актуален при обменах с партнерами, где нужен «черный ящик», понятный всем конфигурациям.
Но на практике, когда речь идет о внутренних обменах между базами одного клиента, или при переносе данных из одной конфигурации в другую, КД 3.0 и рядом не стояла с КД 2.0, где простейшие изменения в правила конвертации вносятся просто.
(6) Для разового обмена КД2 подходит. А если у одного клиента зоопарк конфигураций, обновляющихся в разное время и нужен постоянный обмен, КД3 предпочтительнее.
(2)
А где есть тестовая КД3? Хотелось бы глянуть.
(7) Я такой точки зрения: если множество конфигураций у одного клиента, то при обновлении одной, может поменяться формат данных для обмена, в этом случае придется обновлять все базы, участвующие в обмене, при чем нет гарантий, что во всех актуальных релизах реализован один формат. При чем эта ситуация касается и обмена между партнерами. Другими словами, если обновляется формат, то все конфигурации должны соответствовать ему. Это крайне не удобно. В случае с КД2 все решается очень быстро в контексте одного обмена между двумя узлами. К тому же, повторюсь, КД3 призвана для создания универсального формата, понятного для множества конфигураций, а значит, нацелена для обмена между партнерами.
Для обмена между своими базами такой подход не нужен, когда нужно настроить обмен для внутренних объектов, например, т.е. речи об универсальности нет. Да, это можно сделать как в КД3, так и в КД2, но стоит ли оно таких телодвижений в КД3?
(10) Видимо Вы пока не разобрались в преимуществах универсального формата обмена на практике. При обновлении одной конфигурации не требуется обновлять другие. Это основное преимущество. В каждой конфигурации поддерживается несколько форматов обмена. Чтобы не нашлось общего одинакового должно пройти лет 5, если не больше. Если есть 3 разных конфигурации, для обеспечения обмена во всех направлениях нужно написать 12 правил на КД2 или 3 на КД3. При обновлении одной базы нужно поправить 4 правила на КД2 или одно на КД3. А если баз более трёх, в случае с КД3 ничего не меняется, дорабатываем одни правила, а для КД2 — количество разных конфигураций, умноженное на 2.
(11) Как раз таки сталкивался со всеми «преимуществами» на практике, когда в одной конфигурации поменялся формат, обмен встал, требовал обновления другой базы.
Так что:
— соглашусь, если в обновлении не меняется формат, в других случаях — заблуждение, ибо если меняется формат, значит все конфигурации должны «догнать» его.
Если есть несколько конфигураций, но как правило, обмен не нужен «многие ко многим», чаще всего, у клиентов центральный узел, у которого настроен обмен с другими узлами, при чем эти другие узлы не обмениваются между собой, так что такой подход сокращает количество настраиваемых правил обмена.
Любая точка зрения имеет место быть, но все-таки считаю, что для внутреннего обмена КД2 предпочтительнее
(12)
Согласен, но 1С идёт своим путём и выпиливает обмен на КД2 из типовых.
А проблема с форматом была 3-4 года назад, когда этих форматов было два. 1.0, 1.1. Сейчас их порядка 6-ти в каждой конфигурации — последний 1.7. И повторение ситуации, что у кого-то не оказалось совместимого формата маловероятно.
>у клиентов центральный узел, у которого настроен обмен с другими узлами
Один ко многим. Если у периферийного узла поменялась конфигурация, нужно менять правила с центральной базой, а это повлияет на все остальные обмены.
Приведу пример из практики. База УТ 10.3.8 обменивается с постоянно обновляемой БП 3.0. Программиста в штате нет. После внедрения обмена на КД3 вопрос с обменом был закрыт. Работает несколько лет.
Периодически попадаю в ситуацию, когда две типовые конфиги долго не обновляются. От слова вообще. Примерно полгода. И начинают сыпаться ошибки при синхронизации. Полгода работало, никто не трогал, и тут прилетает…. Начинаешь делать обновления и ошибки уходят. Такое ощущение, что конфиги даже если не обновляются, все равно откуда-то что-то тянут. Это всё радости правил на КДv3?
(14) КД3 в отличие от других требовательна к качеству исходных данных. Бардак не распространяет. Если что-то не заполнено, сообщит и остановит выгрузку. В Вашем случае возможно был контроль отрицательных сумм, а в новой версии формата его убрали. Нужно смотреть на ошибки.