Начал проект, открываю всем.
Для критики особенно.
--
История: перевод работающей торговой компании с филиальной сетью на восьмерку из самописа в самопис.
Основной проблемой перевода я (и я убедил в этом руководство компании) являются КОСЯКИ.
Аксиома: они по любому будут. Найдите команду профессионалов, закажите ей переписать конфигу. В первую неделю внедрения никто ничего продавать не будет, все будут обучаться, бороться, ср%ться. Возьмите команду непрофессионалов и эта неделя растянется в несколько месяцев.
--
Альтернатива: РИБ: новая восьмерка в одном подразделении, проходит обкатку, в то же время обменивается данными с другими подразделениями.
--
Почему не просто МОД, XML обмен и проч экспорты/импорты вплоть до dbf и текста:
РИБ - штатный механизм тесно интегрированный с платформой как в 8.2 так и УРБД в 7.7, и если в 8.2 (как меня надеюсь поправят) есть в платформе некоторые возможности загрузки объекта из XML представления и возможно (как я надеюсь мне укажут) они достаточно хорошо развиты, чтобы ими пользоваться и не думать о преимуществах платформенного РИБ, то в 7.7 по части загрузки данных (с движениями) УРБД альтернатив нет. И даже в соображении, что 7.7 не должна тянуть нас в каменный век РИБ 8.2 это не каменный век, а штатный механизм с поддержкой.
---
Что сделано:
написана обработка раскрывающая посылку 7.7 в иерархическую структуру всех выгружаемых объектов (они не копятся в этой структуре, а выгружаются в XML по мере поступления, т.е. реализован некий стек), разработана модель описания соответствия метаданных 7.7 <-> 8.2, и неё сразу получаются ограничения на структуры метаданных конфигурации 8.2, которые будут участвовать в этом обмене, реализована упаковка посылки 8.2 РИБ которая всасывается в 8.2 базу и может в себе нести Иерархические справочники с периодическими реквизитами, реквизиты справочников при этом могут быть строками, числами, другими справочниками. Конкретно сегодня планирую расширить возможности посылки до справочников с подчинением и реквизитами типа "перечисление", все перечисления планирую сгруппировать в 8.2 справочник "Перечисления 7.7", далее написать обратный механизм формирования посылки 8.2 -> 7.7 и заняться документами.
--
Обработку готов выложить в интернет ресурс, который планирую посвятить проекту (у меня нет пока моего доменного имени). Или в любое другое место, если будут желающие ознакомиться или принять участие.
--
Страдаю: в 8.х я новичок, пишу плохо, хотя и получается, оптимизировать надо все, что написал.

(0) XML + КД хватает за глаза

Забываем про помеченные к выгрузке объекты! Когда в процессе работы, платформа сама добавляет их в таблицу. Этот спор из одной реплики не состоит. Я знаю о чем Вы. Знаете ли Вы о чем я?

(2)[Этот спор из одной реплики не состоит]
ты форумом ошибся
ни каких споров в голосовалке не будет
выкладывай на инфостарт - есть минимальный шанс на дискуссию

модератор?

(4) если хочешь переименовать название голосовалки - легко

Вот Вы, вроде уже и не молодой человек, чтобы так себя вести... Я русскими буквами написал, чего хочу. Повторю. Конструктивного обсуждения. Нет желания обсуждать тему - не пишите. При всем уважении к Вашим годам.

АПНУ!

расширил возможности посылки до справочников с подчинением и реквизитами типа "перечисление", все перечисления загнал в справочник "Перечисления 7.7"
Пора взяться за обратный перевод.

Прочитал дважды не вкурил точно о чем идет речь.
Смелый товарищь пишет с нуля на 1с82 и при этом мало знаком.
1991 год это год вашего рождения?
А разве нельзя обойтись без самописок?
Голосоввкла тоже не понятный бред какой-то.
Нет пункта заплати лимон баксов и мы поможем.

(9) +1

Мозг сломал.

Мы как раз этим путем собираемся пойти. Т.е. на 7-ке мод для регистрации, на 8-ке УРИБ. Пока что пишем конфу на 8-ке, и лъем туда данные за период из 7-ке с помощью КД (только получатель). Заодно обкатываем движения документов. До обменов еще не дошли, так как еще конфига не готова.

Т.е. хотим пойти немного другим путем.
Сейчас филиальные базы обмениваются справочниками и некоторыми документами через одну центральную базу с помощью мода.
Планируется заменить центральную на 7-ке на базу на 8-ке. При этом в 8-ку будут литься все данные. После обкатки обменов и конифиги делаем почку от 8-ки и переводим филиал на 8-ку. Смотрим результат. И так постепенно переводим всех на 8-ку. В результате имеем консолидированную базу для руководства и почки на 8-ке на филиалах.

Значит плохо объяснил. Вот на пальцах:
В результате выгрузки данных УРБД появляются "текстовые файлы".zip
В результате выгрузки данных РИБ появляется "файл XML".zip
Я сделал перевод текстовых файлов версии 7.7 в XML файл версии 8.x
Добился чтобы он безошибочно втягивался в базу 1С 8.2.
Перевод работает для справочников.
Сейчас пишу обратный перевод.

есть КД, ты какой-то фигней страдаешь

(14) КД хорошо, но основная проблема регистрации изменений. При условии большого документооборота

В 1991 я родился как Вуглускр.
Как человек я родился в 1975.
8.2 - мне поставили такое условие Заказчик. Мол зачем ты мне вчерашний день предлагаешь.
Был бы штатный механизм обмена 7.7 <--> 8.x (заранее слышу протесты и поэтому уточню), который бы производил авторегистрацию измененных объектов так как это делают РИБ 8.х и УРБД 7.7 по отдельности) я бы конечно им воспользовался.
Я даже напишу про это так
По моим исследованиям РИБ 8.х вточности то же самое что и УРБД 7.7 (и это не общие слова, это уже реализованные модели обмена) стой лишь разницей, что правила построения распределенной системы в 8.х позволяют строить снежинки, а 7.7 нет.

(15) делаешь УРБД и базу только получатель
потом парсишь на выбор
- табличку на скуле
- текстовый файл обмена
- журнал регистрации
- ...

(17) Что автор и предлагает. Я пока до обмена не дошел. Поэтому ветка интересна, чтобы велосипед не изобретать

(18) нет, автор фигней страдает
из урбд 7-ки нужен только идентификатор объекта и вид действия (новый/ изменение / пометка удаления / удаление)

(15) У вас большой и сложный проект, вероятно уже все запланировано. Задачи те же, что и у меня... Короче нужна обработка на анализ -  пиши куда выложить, буду обновлять по мере развития.
(17) Вот текстовый файл обмена я и парсю, только база у меня не "только получатель" потому как в одну сторону я бы и КД обошелся, а мне надо и в обратную.
У меня пока 7.7 главная база.

(20) а загружать в центральную религия не позволяет?

(20) Он имеет ввиду, что для этого дела делается отдельная почка, только получатель. Куда сливаются все данные. Дальше при приходе файлы обмена он парсится, т.е. получает ID элемента + действия и эта информация сохраняется в отдельное место. (аналог РС РегистрацияИзменений из 8-ки). При необходимости с помощью КД выгружаются данные из этой базы, при этом данные для выгрузки берутся из этого отдельного места

(19) Это можно получить только влезая в таблицу _1supdts.dbf? либо навешивая обработчиков в предопределенки.
Меня не устраивает КД в направлении 8.х ---> 7.7 потому как в КД не переносятся движения регистров, и после загрузки доков их надо проводить.Или они будут проводиться во время загрузки. Кто работал в фронтфисных базах, тот знает, что XML загрузка во время работы пользователей в 7.7 невозможна.

В обратную сторону проще. Т.е. сделать в 8-ке узел обмена, КД умеет работать с планом обмена. Т.е. он может брать данные для обмена из этого узла.

(23) Не обязательно. Для этого нужно сохранить файл обмена, который приходит для загрузку в эту базу. И парсить его. Так как филиальная 1supdts.dbf может быть недоступна в центральной базе

(24) ---> (23) проблема загрузки в 7.7 во время активной работы пользователей УРБД это то, что сегодня работает, я также слышал, что успешно работает и МОД, а вот КД и XML не попрут. КД используя план обмена легко выгрузит нужные данные. Но загрузить их в базу не прекращая торговых операций невозможно.

(25) да.

(26) с мод раньше не работал?
ты бросаешься из крайности в крайность, есть более простые методы решения

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

Ну мод я бы не сказал что успешно. Фактически ничем не отличается от загрузки с помощью обработки. Ну только что движения по регистрам может переносить. А так тоже самое при большом обмене приходиться выгонять всех из базы, так как грузиться все одним куском, а не как УРБД - порциями

(28) по МОД у меня пробел ...
(29) я сделал 7.7 --> 8.x обратно доделаю за выходные. Справочники. Дольше на документы полезу.

(29) Ну если с авторегистраций все более менее решаемо. То проблема загрузки больших объемов данных, при условии интенсивной работы пользователей ... или подсовывать данные УРБД, или организовывать стек загрузки, чтобы дать возможность работать пользователям во время загрузки данных

Я задумывал эту ветку имея неуверенность в том, что я не верблюд и делаю не велосипед. Подумал, макнут головой в это самое, пообижаюсь м.б., но решу задачу легче.
Вот только (32) - я так тоже думаю. И не вижу как это обойти. Потому упираюсь дальше.

(33) так уже макнули по самое немогу

Автор знает о функционале обмена 8.1 - 7.7 в типовых конфах? Чем его не устраивает этот велосипед?

(35) В этом и проблема, что нет типового обмена. Вот и возникает вопрос, как лучше его организовать

Стоит ли формировать свои УРБД файлы для загрузки в 7-ку или пойти другим путем (к примеру прямая запись в таблицы)

Автор знает его в сторону 7.7 --> 8.x,
знает слова КД и План обмена.
Вот что Вы можете сказать о нем из 8.х в 7.7?
Это правда XML?
Правда через XML не передаются движения регистров и документы надо проводить?
Правда ли, что во время такой загрузки пользователи попадают в "транзакцию", или же кто-то из них умудряется без мыла влезть и загрузка падает?
Половина загружена треть проведена все хотят работать клиенты разворачиваются?
Так ли это?

это поток мыслей или вопросы?

(38)  хмд это чисто формат, он к движению не имеет отношения. В частности мод тоже может обмениваться данными в xml формате. При этом прекрасно передат движения документа.

Можно попробовать заюзать центральную базу и для обратной выгрузки. Т.е. грузим в нее из 8-ки (здесь скорость не важна, мы все равно монопольно в ней сидим). А дальше с помощью УРБД грузить уже на получатель

"Вот что Вы можете сказать о нем из 8.х в 7.7?"
Со стороны восьмерки не вижу никах проблем по выгрузке данных. Штатный механизм обмена с использованием правил конвертации. КД2 достаточно.

"Это правда XML"
Если файл обмена соответствует формату XML - то это,наверное, всё таки XML :) не понял Вашего вопроса :(

"Правда через XML не передаются движения регистров и документы надо проводить"
Нет, не правда. Есть типовой функционал в конфигурации - но Вам никто и ничто не мешает устанавливать свои сообственные правила обмена. Почитайте форум - местные "умельцы" периодически наступают на грабли и передают документы без движений. Или, наоборот, - движения документа без передачи самого регистратора

"Правда ли, что во время такой загрузки..."
Правда - но не вся. Есть методики обхода и наработки решения этих проблем. Я приведу пример, который не относится к обмену:
Платформа позволяет восстанавливать последовательности документов - но требует монопольного режима. Быстро, но не удобно.
Конфигурация содержит "программную" реализацию этого-же самого - но без монопольного режима. Удобно, но тормозит работу пользователей.
Есть простое решение - проводить документы, с паузой между проведением очередного документа. И волки сыты, и овцы - целы.

(39) Все таки вопросы, тесно связанные с перенесенными травмами.
(40) Угу! И вот ещё! Сброс флагов загрузки объектов "посылка дошла". Объем информации для обмена будет расти, если не передавать по УРБД номер посылки, которая уже загружена.
Итак считаем альтернативный вариант: Помечаются объекты УРБД, выгружаются, В КД в направлении 7.7 -> 8.х в процедуру выборки объектов включаем потрошитель полученного файла и выгружаем в 8.х измененные объекты. Неким магическим образом очищаем _1SUPDTS.DBF от объектов с номером нашей посылки после их успешной загрузки в восьмерку. В направлении 8.х -> 7.7 выгружаем через КД согласно плану обмена измененные объекты (платформа позволяет после выгрузки и загрузки сбросить флаги изменения), затем в центральномонопольную базу 7.7 через КД загружаем объекты из восьмерки и далее в другие базы. При этом! Они не должны повторно пометиться для выгрузки опять в восьмерку, как это сделать - загадка.
(41) То, что предлагаю я - это ещё одна наработка и решение, его нет сейчас. Оно будет завтра, и если будут помошники, то завтра наступит быстрее. То, что Вы пишите в (32) "назвали свой стек загрузки", а ведь и правила выгрузки туда-сюда тоже надо описывать и функции выборки, и то, что предлагаю я будет удобнее, а загружаться и выгружаться будет быстрее и средства разработаны не мною, а 1С _штатгые_. Я считаю свой вариант лучшим.

(41) Т.е. то о чем я писал выше или УРБД или стек загрузки.

А кто нибудь прямыми запросами писал в дбф версию 1С? Насколько это нежелательно при интенсивном документообороте?

(0) Ты уже определился как соответствия ссылкок будешь хранить?

(42) Понял. Не очень тривиальную задачу придумал автор ветки. Если он учтет все подводные камни то возможно влетит. Но зачем придумывать себе сложную работу? Неужели не решить организационно все это?
Сколько филиалов? Как часто обмениваетесть? Какой объем? И почему самописка?
Я бы в каждом филиале научил бы обмениваться между базами 7.7 и 8.2 пусть переносять и тестят за одно. только в одну строну. А как проверять все блоки в один прекрасный день всем перейти на 8.2!

(42)+1 за "Неужели не решить организационно все это?"


(автору)
"...кто работал в фронтфисных базах, тот знает, что XML загрузка во время работы пользователей в 7.7 невозможна..."
я работал - но, почему-то, не знаю(вернее - это было первое от чего "избавились")

"фронт" - должна быть(имхо) самой "деревянной" частью корпоративных систем.
обмены с бэкофисом торговой площадки - "мгнАвенна".
во фроне никаких проведений - все на справочниках (пример Штрих-М),
тогда клиенты "отворачиватся и уходить" не будут.

...Видел однажды "махину" - на ПОСах стоит УПП - вот это круть!

Общий вывод:
в качестве общего развития и изучения проблемы с "научной" точки зрения - продолжаем "копать"
а вообще - считаю, что надо в "консерватории что-то подправить"

(45) Не получиться перейти одномоментно.
Когда у тебя куча филиалов, то боюсь если всех с понедельника резко перевести на 8-ку, то ты утонешь в шквале звонков и негатива. Обучаться им некогда, они менеджеры они деньги компании приносят их нельзя отвлекать.
Ставить копиии ... можешь хоть 20 копий поставить, все равно никто туда заглядывать почти не будет, кроме пару-тройки менеджеров которым это интересно

Есть и еще и политические вопросы. На маленьком филиал проще обкатать, обучить и застроить. И когда в центре, где руководства рядом, толпа менеджеров побежит жаловаться как им неудобно работать, верните все обратно у тебя уже будет железный аргумент, что на филиале это работает они рады, что перешли. Значит все эти слезы от того, что менеджер не хочет учиться. Иначе есть большой шанс, что руководство свернет этот проект, потому что ему нужны живые деньги, а не абстрактные преимущества 8-ке. Или как вариант придется рисовать полный аналог 7-ке с ее недочетами и цветовой гаммой

(44) в 7.7 реквизит v8UID в каждом справочнике тип строка 36
в 8.2 реквизит v7UD в каждом справочнике тип строка 14, при создании элемента в восьмерке генерируется новый v7ID с соответствующим префиксом, при загрузке созданного в семерке элемента осуществляется его поиск по v7ID и либо берется ссылка найденного, либо генерируется GUID после цикла обмена все реквизиты соответствий оказываются установлены и однозначны.
(45) Я всилу своего опыта (небольшого) не смогу написать сразу 8.2 полную (не фронтофисную деревянную = респектв (46)), поэтому мне легче написать модуль быстрых продаж справочники, цены, поступления перемещения реализации все и для этой узкой конфы сделать этот обмен. Обкатать ее работу в том филиале где сейчас загибаются продажники (он у меня один), и только после этого, если оно будет нужно перетаскивать на 8.2 другие точки, ибо это деньги, которые я пообещал сэкономить, ведь лиценз надо будет покупать в каждый филиал. А там сегодня куплена 7.7 Поэтому есть ещё шкурные соображения, на тему сэкономим и поэтому полного перевода всех на 8.2 может и не будет.
Ещё про самопис: я пришел туда несколько лет назад и конечно спросил, почему вы купив функциона "Торговля + склад" не используете его полностью, а работаете в какой-то самописной программе. Оказывается они пытались работать в ТиСе но как раз о чем писал Собеседник, на фронте должна быть дубовая конфига, а ТиС такой не является тормозило все. Поэтому она была сильно упрощена. Документ реализация разрезан пополам: на документ проводящий долг клиента и документ выдающий товар со склада. Это я считаю, они были полностью правы и не было в модулях проведения в самописе сложных расчетов. Ещё они все время работали задним числом выставляяя ТА на начало следующего месяца, а для проведения все время брали актуальные остатки. Такими способами они добились быстродействия. Потом несколько лет моей работы по развитию, и мы приходим к тому, что ни олна типовая не вписывается в существующие модели автоматизации: ценообразование, расчеты с комиссионерами, баланс предприятия, интеграция с web и т.д. - короче писать и писать за большие деньги все то, что я сделал в 7.7 для типовой 8.х из-за того, что один из филиалов превысил возможную нагрузку на терминальный сервак.

(48)
я видимо не понял орг.структуру и вид деятельности заказчика.
фронт, о котором я говорил в (46) - это в основном для ретейла.

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

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

информацию, например, об остатках и дополнительных взм. локальных клиентов(которые могли возникнуть в других филиалах) реализовать на справочниках.

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

типа как-то вот так....

чесс слово: мне кажется, что все-таки надо начать с "консерватории" :)

а мегавесч из (0) оставить на потом :)

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

(49) Помимо справочников у нас идет обмен документами (взаиморасчеты, товар, который уехал на филиал). Да даже и без документов, чисто справочники иногда обмен бывает достаточно большим Поэтому если расскажешь как без УРБД и без стека загрузки организовать быструю загрузку, будем рады услышать

(51) да я в прЫнципе не собирался ничего доказывать. :)
(0) идя имеет место быть, практическое применение возможно, но не целесообразно(имхо).

....я приводил пример сетки ритейла, где на ПОСах стояла УПП.
Не могу сказать, что те кто это придумал и поддерживал - глупые люди.
Я их не знаю. Я увидел реализацию в общих чертах. Очень удивило - что на ПОСе стоит УПП. Мой вывод - надо "подправить в консерватории".
Видел реализацию "Перемещения между подразделениями", где нагрузка при обмене приходится на ИБ "приемник", а не на ЦБ.
В задаче (0) - с первого взгляда "увиделось" лишнее напряжение разработчика.
... рекомендую все таки подумать о "консерватории" :)

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

"данные в регистре - сформировать отчет" = "данные в регистре - сформировать отчет?"

(52) тут скорее кто к чему привык и какой опыт в наличии.
Мне мой опыт в УРБД и КД подсказал это решение и я могу его сделать напрягаясь меньше, чем то вот альтернативное из (42), Если мне кроме регистров оперативного учета, пришлось бы запихивать туда расчет и бухгалтерию (в случае комплексной 7.7), то я бы может и не решился ... один.
УРБД передает фсе не только общие взаиморасчеты - поэтому раз у нас есть все мы пользуемся общими взаиморасчетами в точках реализации.
Иногда дорога только кажется короткой, иногда длинной опять же кажется.

(54) успехов ...нам в нашем нелегком ..... :)

Продолжаем!
Справочник "Валюты" бегает туду-сюда из центральной 7.7 в периф. 8.2 и обратно, в 8.2 он представлен как справочник + регистр сведений "Курсы валют", что конечно осложняет переброс периодических реквизитов, но не делает его невозможным.
На очереди более простые справочники (Контрагенты, Банки, Банковские счета свои, чужие, Договора и Регионы), они уже ходят из 7.7 в 8.2, ожидаю, что на их обратный трансфер не потрачу ни одной новой строчки кода. Все правила обмена описываются в табличных документах.

Дошли!
Контрагенты, Банки, Банковские счета свои, чужие, Договора и Регионы
обмениваются.

Пока набираю в выгрузку справочники, чтобы можно было хоть один документ прогрузить.
Ещё 5 справочников начали участвовать в обмене
Номенклатура, ГТД, Сертификаты, ОКЕИ, ОКСМ

(47) что-то фантастика какая-то. Неужели ты думаешь, что в филиале будут рады? Такого не бывает.

(59) Бывает. Все зависит от руководство. У нас на одном филиале руководитель - бывший военный. И если он сказал люминий, значит люминий.

Одно из наблюдений:
Не было в семерке у меня кода в справочнике ГТД
Восьмерка поругалась, ты мол не прав, код нужен, ну я задумал
вписать в семерку код какой-нибудь, и забыл.
Выгрузил данные из восьмерки, так они в семерку втянулись без ошибки, хотя был указан непустой код. Потом обратно поехал уже пустой код и все пришло к пустому коду.

Ещё одно: рисуя правила для справочников, понял,
что некоторые справочники можно не выгружать в обратную сторону, делая таким образом в разрезе именно этих справочников базу "только получателем".
Напрягая мозг, не могу придумать такую настройку через штатное УРБД 7.7

(62) Эта штатная возможность МОДа + автозамена реквизитов, или выгрузка только определенных реквизитов + выгрузка по условию (например реквизит Фирма  = Наша фирма)

Сотрудники, Фирмы, Проекты, Кассы, ПБОЮЛ, Склады, Пользователи, НаценкиМагазинов, АналогиПоКодам готовы, приступаю к обмену документами.

В свое время мне помог поиск в нете разобраться с полями в dbf файлах 1С 7.7,
вот выложу, как вижу формат записи документа в УРБД 7.7 (на примере)

{"Documents",
{8841,"1317948|VZ",0,20100128,701950000,"Vz000001",0,0,0,0,0,0,
{0,0,0,0,0,0,0,0,0,"0|","154|VZ",20100128,"","8844|","0|",
{1,"1","68035|VZ","415135135131","131|VZ",2,"Нет","28.01.10  12:00","VZ6297280110"},
{2,"1","103526|VZ","64654654798987987","131|VZ",2,"Нет","28.01.10  12:00","VZ6297280110"},
{3,"2","68035|VZ","64645654654654654654","131|VZ",2,"Нет","28.01.10  12:00","VZ6297280110"},
{4,"2","103526|VZ","64654654654987987987","131|VZ",2,"Нет","28.01.10  12:00","VZ6297280110"}},
{"Actions"}}},

{[IDDOCDEF],[IDDOC],[IDJOURNAL],[DATE],[TIME],[DOCNO],[CLOSED],[Есть дв. журн расчетов],[Есть проводки],[ISMARK],[APPCODE],[ACTCNT],
{[Есть дв. регистра №1],....,[Есть дв. регистра №Последний],[Общий рекв №1],...,[Общий рекв № Последний],[Рекв шапки №1],
{1, далее понятно

Вот выяснил, что в файле обмена РИБ 9 могут быть описаны изменения движений документа, без содержания самого документа, т.е. узла <DocumentObject> нет, а движения его есть.
Скорости ради не буду обрабатывать такие ситуации, думаю, что разрабатывая конфигу, не допущу изменений движений не связанных с изменением документа или статуса "Проведен".

Ёхохо!
Выгружаем документы их восьмерки, с регистрами, конвертим в формат 7.7. УРБД и они загружаются в семерку.
Теперь займусь обратным.

Вот возникла дыра в протоколе...
в 7.7 как и в 8 если идентификатор-ссылка есть, а объекта нет, то пишется "объект не найден".
А вот сопоставление в 8 идентификатора не найденного объекта известному идентификатору из 7.7 прям логическая дыра.

Документы:
Было из 8.х --> 7.7
Стало: 8.х --> 7.7, 7.7 --> 8.x
-----------------
Первая партия документов успешно загрузилась, неся в себе табличную часть и движения регистров.

Система прошла боевое крещение на справочниках из 7.7 --> 8.2.
Выгружал всю неделю м вот какие вышли доработки:
1) При больших объемах периодически необходимо сбрасывать XML DOM на диск и потом заново перечитывать, оптимально 33 000 текстовых строк из файла УРБД 7.7 период сброса DOMа на диск.
2) Средний размер XML файла - 2 000 000 строк ~ 80 Мегабайт. Критический размер DOMа после которого его формирование заткнулось - 5 000 000 строк = 250Мб.
3) Иногда формируя строки в DOMе платформа почему-то не конвертит '<' --> '&lt;' и '>' --> '&gt;' На миллион строк было много правильно отконверченных, но одну-две приходилось пилить руками.

(68+) Дыру в протоколе заткнул созданием документа v7НеизвестныйВидДок, который будет помнить ссылку, если аналогичного объекта метаданных в 8.2 не обнаружится.
Чтобы полностью замкнуть миграцию оперативного учета (для очистки совести в основном), хочется понять почему движения документа могут быть неактивными и как этого достигают?
Искал на форуме, нашел только 1 вопрос связанный с УППырищем, но механизма возникновения неактивных движений там не обсуждалось. Интерактивно в действиях мне доступна отмена проведения, но движения стираются при этом.
Может быть как раз в этом и дело, если я буду отменять проведение в документах, где отключена автоочистка ...

(70) а зачем тебе каждый раз перегружать весь справочник? перегружай только измененные элементы. Ну максимум будет 2-3 мб в день.

(72) А так и будет, это был тот самый первый раз. Дальше все легче и проще.

(0) Я бы решал через КД. С таблицей изменений 7.7 работал бы напрямую.
Выгрузка из 7.7 через КД была бы проста как дверь:
Одно ПВД, в котором обход таблицы изменений и ВыгрузитьПоПравилу() для каждого объекта (при отключенной выгрузке по ссылкам).
В 8-ке вообще всё штатно решается через КД, включая регистрацию изменений.
А твою задумку если вылизать, то выигрыш будет только в скорости загрузки/выгрузки в 7.7
Упираться ради этого в доп. временные затраты ради временного решения смысла не вижу никакого.

(74) Есть в протоколах РИБ такие вещи как номер принятой посылки и номер отправленной посылки. Есть автоочищение этой таблицы после того, как становится известно, что посылка NN достигла адресата. Эта функциональность есть и в 7.7 и в 8.2 и она тоже дорого стоит в процессе её переписывания с учетом КД.
Задумка вылизана, прокачаны огромные объемы данных.
Выигрыш, которого я ожидал в начале проекта достигнут.
И кса! В восьмерке тоже выигрыш в скорости загрузки /выгрузки.
Решение может и не быть временным в случае, если Заказчик не станет закупать 8 во все свои филиалы.
И, как я уже писал, я хотел хоть как-то это решение довести до вида, в котором его смогут использовать другие люди. И искал соратников.
До сих пор готов выложить выгрузку и писать объяснения на тему как пользоваться.
Если кому-то надо.

(75) Думаю, надо. Работа проделана немалая. Кому-нить да пригодится. Насколько я понимаю, это будет самая большая из наработок по разбору файлов УРБД 7.7
В этом качестве еще много кому может пригодиться. Я бы с интересом посмотрел.
Что потребителей немного будет - это другой вопрос...
Выложишь "как есть" - уже спасибо.

//Закладка

Выложу на этой неделе.
Причешу, сколь смогу, описалово накидаю.
И тест-конфигурации.

(78) Будем ждать :)

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

Тема! Не умирай, февраль выгружаю ... скоро сделаю.

Да ждём, ждём :)

И ещё раз отмечусь.
Сегодня сдам и спину разогну.

1. Обмен через файловую систему очень не надежен при больших объемах. В свое время делали кучу вариантов обменов с соответствующими замерами. Если Вы хотели выиграть в надежности - не завидую Вам. Это утверждение можно проверить понаблюдав за эволюцией баз, сначала файлы ноунэйм, потом дбф, потом СКЛ.
2. Разработка транспорта, борьба с коллизиями, нюансы предопределенных реквизитов и еще много-много всего КД или МОД берет на себя. Как правило разработчик подобных систем тратит львиную долю на изобретение давно изобретенного. В общем Ваш случай 100% проигрыш во времени разработки/изменений
3. Если Вы хотели выиграть в скорости работы механизма, то тут опять же проигрыш: как будет свободное время, поглядите на сколько быстрее обмен через индексированный ДБФ, а потом попробуйте через СКЛ таблицу.
В общем подобное нафиг ни кому не нужно кроме Вас (конечно, ИМХО)

(84) раз нашлись лохи, которые заплатят бабки, значит, всё в порядке.

(84) Никто бы велосипед бы не изобретал, если бы был нормальный стандартный механизм переноса 7.7 <-> 8.х

(84) 1)Да, все правильно. Именно такова ретроспектива. И я не претендую на новое направление в выгрузке. Я занимаюсь частным случаем, семерки, dbf. Для которого у меня нет МОДа и опыта работы с МОДом + МОД стоит денег, + по МОДу знающме люди писали + все уже решено и написано. Поэтому просто, в мозаике появилась ещё одна деталь. И она на своем месте.
2) А не будет изменений. Все новое делается в 8 и никуда не выгружается, внедряется лишь там, где оно надо. Часты вы меняете фронт-конфигу? Было бы это кем-то другим написано - я бы использовал.
3) Что такое обмен через индексированный dbf? Я не всеведущь однозначно, но могу сказать, что быстрее УРИБа в семерке я не видел ничего. Про SKL смешно даже говорить - не наш случай. У нас нет SKL и даже если к dfb прикручивать skl выигрыша в скорости не будет.
(85) Мои заказчики читают эту ветку. Я оставил им ссылку. Я понимаю, вы сейчас в бутылку полезете, и тем не меннее: Озвучьте ваш вариант бюджета "обмен 7.7 <--> 8.2 под ключ"

(87+) Для расчета бюджета:
26 видов справочников
22 видов документов
Реквизиты неопределенного тпиа, периодические с регистратором и без.

http://217.149.181.74/v7/index.html
Здравствуйте, Все!
вот оно ... если кто конечно ждал.

что-то ничего не открывается по ссылке...

Юзайте сами свою v8...

(90) Прошу прощения, был в отпуске,будупосмотреть извне, а то у меня открывается ..
(91) Вам, похоже, все открылось сразу.

(0) какой маразм, автор тебе наверно и ОтСтаТыщ не платят за ЭТО

(93) Нет, не платят. Да и трачу я поменьше, чем там, где вы прожигаете. Обратите внимание на все посты, есть люди, которые задачу поняли, не смотря на все усилия с моей стороны.

риб предполагает идентичность.
а значит, это уже не РИБ.
а все, что не РИБ, имеет в своей основе некий набор частностей, который и гробит любое начинание

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

(89) По поводу ссылки из поста.
Пошел в терминальном сеансе у клиента в инет, проверил, ссылка рабочая.
Что не так то?

http://217.149.181.74/v7/index.html
Обновил обработку, если кому интересно.

(98) Сенк. Положил в кладовочку. Может, и не пропадет твой скорбный труд :)

(98): не работает ссылка.

(100) Интернет подкачал, второй день проблему решаю.
Сейчас есть.