Привет!

Запустил в работу.

Изначальная идея: преобразовывать идентификатор ссылки в 7.7 в идентификатор ссылки в 8.х и за счет этого уменьшать объемы выгрузки данных. Но не просто уменьшать объемы выгрузки, ещё и не хранить соответствия идентификаторов в регистрах сведений и не запрашивать это соответствие каждый раз (забегая вперед скажу, что это реализовать невозможно, из-за разных методик учета сущностей в УТ и в ТиС, удалось же, однако, хранить сопоставления не для всех подряд объектов).

Вторая идея (исторически первая): из-за отсутствия УРБД для 7.7 среди купленных продуктов в качестве источника информации об измененных объектах использовать MLG файл.

Сегодня регламентное задание всасывает через OLE данные из ТиС в УТ, соединяя в одну восьмерку несколько разных 7-чных баз данных созданных для различных юридических лиц и находящихся в разных подразделениях.

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

Почему не КД: я уже написал достаточно много разнообразных конвертаций и из 7.7 тоже, чтобы понимать насколько сложно выбирать и подсовывать необходимые данные, и как потом тормозно работает поиск ссылок по реквизитам, промежуточные файлы и необходимость отслеживания номеров пакетов меня также не радовала.

Однако КД: разработка взяла из КД много. Вот например правила конвертации данных:
    // Справочник Проекты
    
    РегистрыСведений.ОписанияОбъектовОбмена77.УстановитьПравилоОбменаДанными77("B/796", ТекущаяБаза, "СтрМенеджерОбъекта", "Справочник.Проекты");
    РегистрыСведений.ОписанияОбъектовОбмена77.УстановитьПравилоОбменаДанными77("B/796", ТекущаяБаза, "ОписаниеРеквизитов", "B/796/Реквизиты");
    
    РегистрыСведений.ОписанияОбъектовОбмена77.УстановитьПравилоОбменаДанными77("B/796/Реквизиты", ТекущаяБаза, "Родитель", "Скрипт~ОбменСИП77СкриптыПостобработка~ЗаписатьДляНовых~Ссылка.Родитель~ТолькоДляНовых");
    РегистрыСведений.ОписанияОбъектовОбмена77.УстановитьПравилоОбменаДанными77("B/796/Реквизиты", ТекущаяБаза, "ТипГруппы", "Ссылка.ТипГруппы");
    РегистрыСведений.ОписанияОбъектовОбмена77.УстановитьПравилоОбменаДанными77("B/796/Реквизиты", ТекущаяБаза, "Телефон", "Ссылка.Телефон");
    РегистрыСведений.ОписанияОбъектовОбмена77.УстановитьПравилоОбменаДанными77("B/796/Реквизиты", ТекущаяБаза, "КодПартнера", "Ссылка.КодПартнера");

Зачем это нужно:
Чтобы не внедрять 8-ку сразу и везде, а осуществить аккуратный поэтапный переход, не нарушая уже отлаженную работу ни в голове ни в удаленных подразделениях.

Спасибо.
С уважением!

>В конечном результате вышло так, что некоторые ссылки из 7.7 при переносе в УТ должны были быть объединены в одну ссылку 8.х

лисапеда... заводим в УТ справочник "базы77" и другой справочник "СинхронизацияОбъектов" куда пишем (ОбъектУТ|База77|ИдентификаторОбъекта77).

Сохраняем обратную возможность выгрузки/синхронизации назад в 77 и не плодим дубли в УТ.

(1)+ Хотя 8-ка же поэтому не справочник а РС

И самое главное... науя OLE когда оно необходимо только для онлайна? Не проще было онлайновый на XML/JSON или еще не смогли освоить эти "текстовые файлы"?

(3) *оффлайновый

(1) Ну так и сделано, только не для всех объектов, бывает так, что преобразования идентификатора достаточно для получения ссылки.

(3) Сперва я писал JSON сериализации объектов, но потом увидел, что от каждого чиха объект разрушался. После чего я стал писать напрямую в объект, а уже заполненный чем надо стал сериализовать - дело пошло и быстрее и стабильнее.
И у меня онлайн! Люди в 7.7 делают документы, через интервал времени в несколько секунд документы появляются в 8 и проводятся.

(6)+ Вероятно про экранирование символов (в XML/JSON) не дочитали вот и разрушалось от \" или \{ или \} и т.д.

(7) Нет, символы экранировал, с этим все впорядке, Объект разрушался из-за порядка следования полей, пустых таблиц, значений неопределенного типа ... Попробуйте вместо объекта заполнить структуру, из структуры создать сериализованный JSON объект и загрузить его в прикладной объект. Окажется, что структура сортирует свойства по ключу по алфавиту, а в объекте свойства идут в произвольном порядке и при работе с конфигурацией этот порядок изменяется легко, а сериализованный объект будет разрушен.

(8) Неправильная сериализация была значит, не понимаю какая разница в каком порядке реквизиты объекта читать/записывать по именам их.

Это что - подсистема (конфигурация) или внешняя база? На какой платформе, в каком интерфейсе, в каком режиме совместимости?

(10) Это просто лисапед, всех преимуществ что самодельный (устройство известно ТС в деталях) и ездит.

(11)+ Хотя еще огромный + что ТС терь зная камешки ваяния подобного обмена и изучив КД влегкую на правилах КД (исключая обратную загрузку данных из 8 в 77) наваяет аналог, причем в 10 раз примерно быстрее.

(10) Это подсистема, с тремя привилегированными серверными модулями, будет работать для обычного и управляемого режимов, для файлового и клиент-серверного режимов. Не будет работать в линуксе из-за OLE и в тех операционных системах, которые настроены так, что не позволяют запуск 1С 7.7.

(0)  использовать млг файл очень нехорошо, там решится автоматом только интерактивное

Первый серверный модуль является общим для работы механизмов конвертации и не содержит специфики конвертируемых решений, только самое общее: из 7.7 в 8.х пр помощи OLE.
Второй серверный модуль содержит скрипты и алгоритмы позднего связывания данных внутри объектов,
тут как раз первую скрипку играют алгоритмы учета методики прикладных решений в моем случае это УТ 10.3. Он кстати называется "ОбменСИП77СкриптыПостобработка", что можно увидеть в примере правил.

(14) угу, мне пришлось в модули проведения засовывать свой код или даже о "контрольный код" делать для справочников/документов, чтобы изменения отслеживать когда то

Прикольно вышло для всех реквизитов объекта считается CRC32 или другой хеш и определяем изменено или нет.
Минимизация заодно объема передаваемых данных но вычислительная нагрузка на компы.

(13) Это все _только_ для баз-источников на платформе 7.7?

(14) Не знаю, почему, но если мне надо загрузить много документов, я обработкой UCHOICE из набора с ИТС изменяю ... например ставку НП в реализациях и в MLG все записывается. Причем записывается и название обработки, которая изменила реквизиты.

(17) Да. Для 8-ки есть узлы обменов РИБ и КД.

Третий серверный модуль выполняет функции стандартизации реквизитов контрагентов из базы ЕГРЮЛ / ЕГРИП, стандартизацию и геокодирование адресов посредством ФИАС и dadata.ru. Стандартизацию ОКСМ, единиц измерений, банков ... на входе иногда мусор попадается, типа валюта руб с кодом 1.

(18) ЗаписьЖурналаРегистрации

(21) Возможно, я не смотрел. Не споткнулся - не упал и не поднялся. Опыт с контрольным кодом из (16) интересный, но я пока не вижу в нашем случае ситуации, в которой он бы стал необходим.

(16) а если поднять УРБД, и смотреть VerStamp ? не проще?

(23) 1. УРБД не бесплатная
2. Не совсем штатная работа, не средствами чисто 1С (dbf|sql разные базы)

(24)+ Но и с УРБД в 77 когда то приходилось извращаться в разных видах ))

(12) Я сейчас думаю о том, как сделать некоторую унивесализацию из этого проекта: поскольку он построен на ТиС и УТ 10 он мог бы иметь спрос, если бы волна переходов с 7 на 8 не ушла в прошлое.