1с конвертация установить предопределенное значение справочника
Эта статья продолжает цикл статей «Первые шаги в разработке на 1С». В ней на практических примерах рассматривается механизм предопределенных данных, в т.ч. и в распределенной информационной базе.
Применимость
В статье рассматривается платформа 1С:Предприятие версии 8.3.4.465. Материал актуален и для текущих релизов платформы.
Предопределенные элементы в «1С:Предприятие 8.3»
При реализации алгоритмов разработчики часто опираются на определенные данные – элементы справочников, планов счетов, планов видов расчета и т.д.
Во встроенном языке существуют методы для поиска данных, например, НайтиПоКоду() или НайтиПоНаименованию().
Однако алгоритмы, опирающиеся на код или наименование, зачастую являются ненадежными.
Поскольку в пользовательском режиме код или наименование элемента справочника могут быть изменены, что может привести к неработоспособности алгоритмов.
Именно для решения этой проблемы и предназначены предопределенные данные – данные, созданные в конфигураторе, обратиться к которым возможно по имени, не прибегая к предварительному поиску элемента.
Таким образом, у предопределенных данных есть две “стороны”: во-первых, существует список предопределенных элементов, созданный в конфигураторе, а, во-вторых, для данных информационной базы указывается, является ли конкретный элемент предопределенным.
Предопределенные элементы могут быть созданы у:
- справочников;
- планов счетов;
- планов видов характеристик;
- планов видов расчета.
В статье рассмотрены новшества, касающиеся предопределенных данных на платформе 8.3, а также особенности работы с ними в распределенных базах (как центральных, так и периферийных) и в информационных базах в режиме разделения данных.
Для примера, создадим в справочнике Организации предопределенный элемент ОсновнаяОрганизация:
Для увеличения нажмите на изображение.
Обращение к этому элементу из программного кода будет следующим:
В платформе 8.3 реализована возможность связать предопределенные данные с элементами соответствующего типа.
Для этого у объектов, которые могут иметь предопределенные элементы (они указаны выше), добавлено новое свойство ИмяПредопределенныхДанных. Оно отображается в списке стандартных реквизитов:
Выберем при помощи запроса все поля из справочника Организации:
Для увеличения нажмите на изображение.
На рисунке видно, что в поле ИмяПредопределенныхДанных указан именно тот идентификатор, который мы ввели в режиме конфигуратора.
Предопределенный элемент в списке отображается специальной пиктограммой:
Чтобы “отсоединить” элемент данных от элемента предопределенных данных, нужно присвоить свойству ИмяПредопределенныхДанных пустую строку и записать элемент:
Пиктограмма в списке изменилась:
Теперь предопределенный элемент существует только в конфигурации и в данных нет элемента, привязанного к идентификатору ОсновнаяОрганизация:
Для увеличения нажмите на изображение.
Обращение из программного кода к предопределенному элементу вызовет исключение:
Чтобы связать предопределенный элемент с новой записью, нужно присвоить свойству ИмяПредопределенныхДанных имя предопределенного элемента:
В источнике справочник, у него реквизит - число.
В приемнике справочник1, у него реквизит - справочник2.
Задача - в зависимости от значения числа из реквизита источника, установить в реквизите приемника нужный элемент справочника2.
Подскажите как реализовать?
А для чего отправлять коллекцию?
Варианты значений числового реквизита источника мне известны, так же, как и чему они соответствуют в справочнике2 приёмника.
(3) А при чем-тут предопределенные значения справочника? В приемнике у справочника предопределенное значение должно встать?
А вообще это так делается:
1. Создаем в ПКО Источник.Справочник => Приемник.Справочник1
2. В нем создаем ПКС => Ревизит.справочник2, указываем для правила ПКО(в нем создаем только одно поле, поле поиска= Наименование/Код - по чему ты искать будешь)
3. Обработчике ПКС => Ревизит.справочник2 ПередВыгрузкой пишем, примерно так:
В ПКО не отмечены поля поиска - это потому что значение конвертируется в запись регистра сведений. У тебя справочник - ищи по коду или наименованию
(7) echo77, вроде все понятно, делал по приведенному примеру, но получаю ошибки при выгрузке из 7ки:
Ошибка получения значения свойства объекта
Объект: Хундай, свойство: ТипТС.
где Хундай - объект справочника источника, ТипТС - реквизит справочника приемника в 8.х
(9) echo77, попробовал, ошибки исчезают, но и все выгруженные элементы содержат 1 значение реквизита у всех. Пробовал в выгрузке устанавливать в ручную параметр реквизита, тогда выгружается правильно все элементы содержащие это значение реквизита.
Вариант - создать правило конвертации из числа в справочник2.
и в правиле прописать конвертацию значений.
(13) если приемник на 8ке, то в ПКС в обработчике ПередВыгрузкой есть:
Выражение - Неопределено. Может быть указано произвольное строковое выражение на встроенном языке, результат вычисления которого при загрузке будет присвоен значению свойства. Если Выражение определить в теле обработчика, то дальнейшая обработка ПКС будет прекращена. Данная возможность, используется только если конфигурация-приемник реализована на платформе V8
При разработке правил конвертации данных, нередко возникают ситуации, когда требуется заполнить определенные реквизиты конвертируемого объекта в приемнике. Рассмотрим пример. В конфигурациях (Источник, Приемник) есть справочники «Контрагенты». Отличаются они набором реквизитов. В конфигурации «Приемник» - у справочника «Контрагенты» есть обязательный для заполнения реквизит «Организация». В «Источник» такого реквизита нет, поэтому как вариант решения задачи можно заполнять реквизит «Организация» непосредственно при загрузке в приемник.
Как решить эту задачу с минимальными затратами? Есть несколько способов. Самый простой случай – передать предопределенное значение. Вариант «прокатит», если в конфигурации «Приемник» справочник «Организации» содержит нужный нам предопределенный элемент. В этом случае мы должны создать для соответствующего правила конвертации объекта (в нашем случае для ПКО «Контрагенты») обработчик события «После загрузки» и в нем обратиться к предопределенному элементу:
Либо сделать это в обработчике "При выгрузке" нужно нам свойства, воспользовавшись выражением:
Аналогичным образом можно выполнить поиск или получение значения из какого-либо другого места. Тут как душа пожелает.
Однако, бывают более сложные случаи переноса данных. Пример из реальной практикb. В базе «Приемник» у справочника есть реквизит «Подразделение», а в базе «источник» ничего похожего нет. Более того, подразделение должно ставиться элементам не одно и то же, а выбираться на основе определенного ключа. Сам же этот ключ содержится в одноименном реквизите справочника «Контрагенты» базы «Источник». На практике это может выглядеть так:
Наша задача во время конвертации брать значение из реквизита «КОНТ_Подразделение» и по нему выполнять поиск в справочнике «Подразделения» базы приемник. Для упрощения договоримся, что значение «КОНТ_Подразделение» совпадает с кодом элемента справочника «Подразделения».
Первым делом нам понадобится служебное правило конвертации объекта. Добавляем ПКО и в мастере создания заполняем:
- Объект информационной базы источника. Оставляем пустым.
- Объект информационной базы приемника. Выбираем ссылку на объект метаданных (в моем случае «СправочникСсылка.ПодразделенияОрганизаций»).
- Имя правила конвертации объектов. Указываем имя правила. Я в качестве имени указал «Агенты_ПодразделениеОрганизаций».
Нажимаем "далее" и в следующем окне мастера обязательно снимаем флажок с «Искать объект приемника по внутреннему идентификатору объекта источника». Сохраняем получившееся правило конвертации объекта.
Отлично, ПКО есть. Теперь создадим для него одно правило конвертации свойств (ПКС). В окне создания нового ПКС необходимо заполнить:
- Источник. Оставляем поле пустым.
- Приемник. Выбираем «Код».
- Ставим флаг «Поиск объекта при загрузке по свойству»;
- В обработчике события «Перед выгрузкой» пишем незамысловатую строчку кода:
Теперь остается только создать ПКС для переносимого объекта (в моем случае справочник «Агенты») и указать для свойства правило конвертации объекта, которое мы только что создали. Выбираем ПКО «Агенты» (вы можете проделать подобный трюк для другого ПКО) и добавляем новое ПКС. В окне создания ПКС заполняем:
На картинке это выглядит следующим образом:
Все, на этой ноте можно поставить жирную точку. Нестандартное правило готово и можно приступать к тестированию.
К сожалению, у Вас недостаточно прав для дальнейшего просмотра.
Если Вы приобрели курс, но еще не активировали токен — пожалуйста, активируйте доступ по инструкциям, высланным на Ваш email после покупки.
Если Вы не залогинены на сайте — залогиньтесь, вернитесь на эту страницу и обновите ее.
Если Вы залогинены, у Вас активирован токен доступа, но Вы все равно видите эту запись — напишите нам на e-mail поддержки.
Комментарии / обсуждение (143):
Здравствуйте.
При настройки отладки обработчиков при загрузке не формируется “Модуль отладки загрузки”
…
(текст комментария доступен только участникам Мастер-группы)
…
(текст комментария доступен только участникам Мастер-группы)
КонвертацияОбъектовИнформационныхБаз как найти?
Ее нет в конфигураторе Конвертации?
…
(текст комментария доступен только участникам Мастер-группы)
Извиняюсь заранее если вопросы кажутся глупыми.
Открываю Конфигуратор Конвертации
Захожу в Глобальный поиск меню Правка ввожу ПроизвестиЧтениеДанных()
Надеюсь найти все вхождения этой процедуры в Конфигурации
Результата нет
Что делаю не так и как правильно?
…
(текст комментария доступен только участникам Мастер-группы)
У меня к сожалению не получилось войти в отладчик, как было показано на уроке, хотя я повторил все действия.
Мне бы для начала зайти в отладчик при загрузке объекта.
Пока в моем представлении алгоритм работы системы такой:
Конвертация готовит XML файл содержащий Правила и Список Объектов
Этот файл мы открываем в УОД, которая его обрабатывает
Как отловить этот момент.Мне хочется на примере простой конвертации пройти по коду и посмотреть процесс.
Но не получается войти даже в отладчик.В доп материалах, есть видео, где автор показывает, как исправив ошибку в наименовании флага в форме попасть в отладку.Нашел этот фрагмент и кажется все правильно.
Но в отладчик не вхожу.Есть ли способы попасть в отладку миную штатные средства.Ведь ясно же ,что автор нашел ошибку в коде, прогнав УОД через отладку
…
(текст комментария доступен только участникам Мастер-группы)
Спасибо за терпение, в отладчик попал.
Пока через код обработки УОД.
.Конвертация 2.1.8.2
Не могу попасть в отладчик со стороны загрузки
…
(текст комментария доступен только участникам Мастер-группы)
Добрый день. В ПКО для ПланаВидовХарактеристик пишу
ОписаниеТипов = Новый ОписаниеТипов("СправочникСсылка.Сотрудники");
УзелТипы = одПолучитьXMLПредставлениеОписанияТипов(ОписаниеТипов);
ДобавитьПодчиненный(Приемник, УзелТипы);
В источнике у меня справочник называется СотрудникиПоставщиков, а в приемнике Сотрудники. Поскольку я нахожусь на стороне базы источника (в обработчике ПриВыгрузке), когда я пытаюсь передать в ОписаниеТипов СправочникСсылка.Сотрудники, пишет про несоответствие типов, и правильно, потому что в базе источнике нет такого типа. А если я в описании типов передаю СправочникСсылка.СотрудникиПоставщиков, то при выгрузке не ругается, но зато ругается при загрузке, потому что в базе приемнике нет такого типа СправочникСсылка.СотрудникиПоставщиков. Если в обеих базах справочник называется одинаково, проблемы не возникает. Если вот так:
УзелТипы = СоздатьУзел("Типы");
УзелТип = СоздатьУзел("Тип");
УзелТип.ЗаписатьТекст("СправочникСсылка.Сотрудники");
ДобавитьПодчиненный(УзелТипы, УзелТип);
ДобавитьПодчиненный(Приемник, УзелТипы);
то проблемы тоже не возникает.
Но все таки, как использовать функцию одПолучитьXMLПредставлениеОписанияТипов в случае когда справочники в разных базах называются по разному?
Я попробовал задачу 1.7.3 решить с помощью разных ПВД. В первом варианте создал ПВД и соответствующее ПКО «БухгалтерскаяОперация_ВыгрузитьПоПравилу». Во втором варианте изменил структуру ВыборкаДанных и напрямую в ПКО «БухгалтерскаяОперация_УказаниеПравила» указал соответствующее правило выгрузки. И для теста создал 2-ой документ «Инвентаризация».
В первом варианте все выгрузилось без проблем. Во втором варианте выгрузился только 1 документ (но в решении преподавателя (и его правилах) все выгрузилось, буду искать ошибку).
С точки зрения оптимальности, какое лучше ПВД применять на реальных задачах?
…
(текст комментария доступен только участникам Мастер-группы)
Добрый день!
Возникла сложность при выполнении дз 1.7.1
Я решил выполнять задачу через уже имеющееся ПВД “Контрагенты”, что бы при переносе конкретных контрагентов выгружать их значения свойств “КлассВажности” и “ОсновнойМатериал”. За исключение ПВД, остальное решение практически полностью совпадает с решением преподавателя, но по факту, при загрузке данных на стороне приемника я получаю ошибку – Ошибка при загрузке данных: : Поле объекта не обнаружено» которую не смог отловить. Но данные по первому из 2х контрагентов перенеслись.
В связи с этим возникло 3 вопроса:
1) Можно ли в данной задаче использовать ПВД “Контрагенты”?
2) Если можно использовать ПВД “Контрагенты”, как оптимальнее – использовать его или создавать новое (как в решении преподавателя) ? Плодить много ПВД мне кажется тоже не совсем правильно, раз в данном случае данные в реквизитах Контрагента, почему бы их и не перенести с ПВД “Контрагенты”.
3) Если можно использовать ПВД “Контрагенты”, не сможете подсказать, где у меня ошибка в моих правила? Потратил кучу времени, но так и не смог понять где она.
…
(текст комментария доступен только участникам Мастер-группы)
Загрузил с сайта разработанные правила и там такая же ошибка получается. Подскажите в чем проблема?
…
(текст комментария доступен только участникам Мастер-группы)
Я дописал ветку иначе стало выгружать но на 1 объект меньше чем в видео у меня 18 объектов выгружает а не 19. Кто не прав в видео дальше комментируется и вопрос просто рано возник?
…
(текст комментария доступен только участникам Мастер-группы)
Добрый день.
Делаю обмен данными договоров из 1С Документооборот (2.1.9) в 1С УПП (1.3.86).
Аналогично уроку 1.7.1 настроила ПКО: спр.ВнутренниеДокументы->спр.ДоговорыКонтрагентов (ДоговорыКонтрагентов), РС.ЗначенияСвойствОбъектов, ПВХ.СвойстваОбъектов, ПВХ.НазначенияСвойствКатегорийОбъектов, спр.ЗначенияСвойствОбъектов, а так же РС.КатегорииОбъектов, спр.КатегорииОбъектов.
Основная выгрузка ПВД – ВнутренниеДокументы->ДоговорыКонтрагентов.
В ПКО.ДоговорыКонтрагентов доп.свойстве ПКС.Сумма ПередВыгрузкой передаю данные в ПКО РС.ЗначенияСвойствОбъектов:
ИсходящиеДанные = Новый Структура("Объект, Свойство, Значение");
ИсходящиеДанные.Свойство = "10 СуммаДоговора(руб)";
ИсходящиеДанные.Значение = Источник.Сумма;
ИсходящиеДанные.Объект = Источник.Ссылка;
В ПКО РС.ЗначенияСвойствОбъектов значение ПКС.Объект (в уроке он назывался Контрагент) передается ссылка на договор контрагента и не находит в уже выгруженных данных и поэтому зацикливается.
Что нужно сделать, чтобы убрать цикличность ссылок?
…
(текст комментария доступен только участникам Мастер-группы)
Благодарю за быстрый ответ.
Использовала ПКС, поскольку аналогичные реквизиты Внутреннего документа из ДО должны загрузиться в соответствующие свойства объектов или категории объектов. Поэтому, ВыгрузитьПоПравилу() тут не подойдет. РС в РС не выгружается, а заполняется из данных справочника ВнутренниеДокументы.
Нашла свою ошибку: дописала предопределенное значение у ПВХ Назначения свойств и т.п., убрала галку запоминать выгруженные элементы для ПКО.ДоговорыКонтрагентов – из-за этого была зацикленность)).
Добрый день!
задание 1.7.1 делаю для начала по одному реквизиту по уроку 1.8.1
для Класс важности “Значение” не переносится
для Основной материал без проблем
В чем особенность? В том, что в справочнике Класс важности предопределенные значения?
каким уроком пользоваться для решения этого задания?
…
(текст комментария доступен только участникам Мастер-группы)
Так как занятие финальное для модуля, посвященного основам переноса данных, задам пару общих вопросов, приближенным к реальным условиям переноса:
1. Задача: В основной базе есть справочник “Номенклатура” – 1 млн элементов по группам. Предприятие внедряет отраслевое решение в другой ИБ и возникла необходимость синхронизации НСИ между основной базой и отраслевой ИБ. Структура метаданных идентична.
Переносить всю Номенклатуру нет смысла. Стоит задача перенести только группу “Для переноса”, в которой 500 000 элементов.
Вопрос: Есть 2 подхода:
1. Добавить условный оператор в обработчик ПКО “Перед Выгрузкой”:
Если Источник.Родитель В ИЕРАРХИИ “Для Переноса” Тогда Переносим Иначе Отказ = Истина.
2. Добавить в ПВД произвольный алгоритм выборки нужных элементов и их переносить через ПКО.
В первом подходе будут перебираться все элементы справочника. Второй по скорости должен быть оптимальнее.
Если третий вариант решения задачи, который будет также прост как первый, но также оптимален как второй.
И второй вопрос:
После переноса всех необходимых справочников нам необходимо перенести документы Поступления. Мы заранее уверены, что все ссылочные Типы свойств уже есть в конечной базе. Как нам явно указать, что необходимо переносить только ссылки на объекты без дальнейшего вызова их ПКО и обработки.
На ум приходит только в обработчике ПКС ПередВыгрузкой указать параметр = ЛОЖЬ:
ВыгрузитьОбъект – Булево – Если Истина, то объект выгружается целиком. Если Ложь, то выгружается только ссылка.
В КД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
14 Comments
самое забавное — тут тот редкий случай когда обилие скринов к месту и не мешает прочтению.
обычно бестолочи накидают скринов для массовки и чтобы скрыть(за картиками) свое неумение подать материал.
тут, повторюсь, годно и вполне хорошо.
Полезный материал, спасибо. Особенно для тех, кто начинает разбираться с КД 3.0.
В последних релизах КД можно просто настройкой выгрузить ТЧ, без алгоритма.
Если в формате нет реквизитов для конвертации реквизитов конвертации, тогда можно использовать поле AdditionalInfo.
Как вариант, можно еще дополнительные свойства использовать. Они почти у каждого объекта в формате есть.
Можно использовать таблицу «КомпонентыОбмена.ПравилаКонвертацииОбъектов» и найти имя ПКО по объекту метаданных.
По-моему в тестовой КД3 уже есть возможность ПРО создавать.
Эх, вот бы на полгодика раньше такую статью мне)))) А то все пришлось через боль постигать))) Спасибо за материал. Однозначно в избранное.
Грамотный новичковский обзор чтобы «вкурить». Мало таких материалов мне попадается, а тут и легко читается и понятно.
Не все скриншоты отображаются, почему?
Автор статьи молодец… Но КД 3.0 — это зло…
Считаю, что обмен через универсальный формат актуален при обменах с партнерами, где нужен «черный ящик», понятный всем конфигурациям.
Но на практике, когда речь идет о внутренних обменах между базами одного клиента, или при переносе данных из одной конфигурации в другую, КД 3.0 и рядом не стояла с КД 2.0, где простейшие изменения в правила конвертации вносятся просто.
(6) Для разового обмена КД2 подходит. А если у одного клиента зоопарк конфигураций, обновляющихся в разное время и нужен постоянный обмен, КД3 предпочтительнее.
А где есть тестовая КД3? Хотелось бы глянуть.
(7) Я такой точки зрения: если множество конфигураций у одного клиента, то при обновлении одной, может поменяться формат данных для обмена, в этом случае придется обновлять все базы, участвующие в обмене, при чем нет гарантий, что во всех актуальных релизах реализован один формат. При чем эта ситуация касается и обмена между партнерами. Другими словами, если обновляется формат, то все конфигурации должны соответствовать ему. Это крайне не удобно. В случае с КД2 все решается очень быстро в контексте одного обмена между двумя узлами. К тому же, повторюсь, КД3 призвана для создания универсального формата, понятного для множества конфигураций, а значит, нацелена для обмена между партнерами.
Для обмена между своими базами такой подход не нужен, когда нужно настроить обмен для внутренних объектов, например, т.е. речи об универсальности нет. Да, это можно сделать как в КД3, так и в КД2, но стоит ли оно таких телодвижений в КД3?
(11) Как раз таки сталкивался со всеми «преимуществами» на практике, когда в одной конфигурации поменялся формат, обмен встал, требовал обновления другой базы.
— соглашусь, если в обновлении не меняется формат, в других случаях — заблуждение, ибо если меняется формат, значит все конфигурации должны «догнать» его.
Если есть несколько конфигураций, но как правило, обмен не нужен «многие ко многим», чаще всего, у клиентов центральный узел, у которого настроен обмен с другими узлами, при чем эти другие узлы не обмениваются между собой, так что такой подход сокращает количество настраиваемых правил обмена.
Любая точка зрения имеет место быть, но все-таки считаю, что для внутреннего обмена КД2 предпочтительнее
Согласен, но 1С идёт своим путём и выпиливает обмен на КД2 из типовых.
А проблема с форматом была 3-4 года назад, когда этих форматов было два. 1.0, 1.1. Сейчас их порядка 6-ти в каждой конфигурации — последний 1.7. И повторение ситуации, что у кого-то не оказалось совместимого формата маловероятно.
>у клиентов центральный узел, у которого настроен обмен с другими узлами
Один ко многим. Если у периферийного узла поменялась конфигурация, нужно менять правила с центральной базой, а это повлияет на все остальные обмены.
Приведу пример из практики. База УТ 10.3.8 обменивается с постоянно обновляемой БП 3.0. Программиста в штате нет. После внедрения обмена на КД3 вопрос с обменом был закрыт. Работает несколько лет.
Периодически попадаю в ситуацию, когда две типовые конфиги долго не обновляются. От слова вообще. Примерно полгода. И начинают сыпаться ошибки при синхронизации. Полгода работало, никто не трогал, и тут прилетает…. Начинаешь делать обновления и ошибки уходят. Такое ощущение, что конфиги даже если не обновляются, все равно откуда-то что-то тянут. Это всё радости правил на КДv3?
(14) КД3 в отличие от других требовательна к качеству исходных данных. Бардак не распространяет. Если что-то не заполнено, сообщит и остановит выгрузку. В Вашем случае возможно был контроль отрицательных сумм, а в новой версии формата его убрали. Нужно смотреть на ошибки.
Читайте также: