vetalvr
Виталий Ф

(6) Модель не помню, подключены через СОМ порт, но данные там собираются с разных цифровых датчиков через программу trade.exe от этих поставщиков.

(2) Спасибо, попробую в этом направлении покопать.

(3) У нас разные весы есть. На большинстве норм вес получаем, на некоторых я сам распарсивал полученные данные напрямую через СОМ. К сожалению именно у этих весов такой возможности нету.

Есть авто и жд весы, данные с которых можно считать только через DDE. Как был решен этот вопрос когда то давно: в экселе через VBA подключаемся через DDE, записываем данные в экселе в определенную ячейку. Из 1С подключаемся к эксель файлу, запускаем этот скрипт, считываем данные с нужной ячейки из экселя в 1С.
Вопрос к знатокам: можно ли как-то без экселя выполнить скрипт VBA в 1С? Или же как-то из 1С считать данные через DDE?

(176) Тогда, судя по всему, штатная реструктуризация работает так: внутренние идентификаторы метаданных остаются старыми, и этот вариант не помогает. Как вариант, можно потестить разборку\сборку цф, но тут, наверное, нужно будет с бубном потанцевать, чтобы новая цф отличалась от старой. Видать самый простой способ остается только вариант с добавлением реквизита в проблемный объект.

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

(175) Изначально было не соответствие. После классического лечения с цф и отвязкой\привязкой, появилась ошибка преобразования. В след раз при не соответствии интересно будет протестировать вариант с переподключением базы. Только это ж логи слетят, что не есть хорошо. Это сначала нужно тогда еще будет логи сохранить. Это вы в центральной переподключали? Или на узле тоже?

(171) Кстати, отличная идея. Почему я сразу за нее не догадался. Тогда бы и не пришлось реквизит добавлять, возможно помогло бы просто.выполнить реструктуризацию.
sashapere, в конфигураторе Администрирование\Тестирование и исправление.

(172) Пробовал. К сожалению мне не помогло. Помогло только (169) сообщение.

(168) Победил. Хочу поделиться своим опытом, возможно кому-то поможет и сократит время танцев с бубном. Раньше при проблемах с обменами (несоответствие конфигураций) всегда помогала 1-ая методика. В данном случае после применения 1-ой методики начала вылазить ошибка "Ошибка преобразования данных xml" и номер строки/столбца. Вылазила эта ошибка попеременно то в центральной, то на периферии, в зависимости от последствий танца с бубнами. Была испробована и 2-ая методика, и добавление константы, и все, что было описано в комментариях. Ничего не помогло. Что имел в конечном варианте: данные в периферию загружаются и выгружаются, в центральную не загружаются с ошибкой "Ошибка преобразования данных xml" и номером проблемной строки в xml (изначально не грузилось ни в периферию, ни в центральную). Данные терять было нельзя, поэтому начал писать обработку по загрузке выгруженного xml из периферии в центральную. Написал. Стал загружать - вылетает при попытке загрузить справочник договоры контрагентов. Далее вспоминаю, что при типовом обмене, когда вылезала ошибка "Ошибка преобразования данных xml", там были указаны номер проблемной строки xml, и по этой строке тоже был справочник договоры контрагентов. Вспоминаю про решение проблемы с константой. Добавляю в справочник договоры контрагентов реквизит булевского типа - и типовой обмен проходит на ура без каких либо танцев с бубном. Т.е. если после 1-ой методики вылазит ошибка "Ошибка преобразования данных xml", то смотрите на номер проблемной строки в xml файле, где вылетает ошибка, и добавьте в этот объект метаданных какой-то реквизит.