1) Стандартная бухгалтерия (не снятая с поддержки, постоянно обновляемая)
2) Стандартная бухгалтерия снятая с поддержки релиз отстает от номера 1 на пол года. (добавлены отчеты, добавлены реквизиты документов, подправлено проведение нескольких документов)
Задача - раз в месяц переливать доки из базы 1 в базу 2.
Делать через конвертацию данных неразумно т.к. каждый раз её нужно будет править при обновлении релиза базы 1.
Необходимо что то типа УниверсальнаяВыгрузка_ЗагрузкаВXML.epf но чтобы она не обращала внимание на несоответствие или новые реквизиты в базе 2, или отсутствие неких реквизитов в базе 2. Например делала заполнение этих реквизитов через попытки.
Очень надо !!!
Да и нужен функционал - определение периода выгружаемых документов, и фильтр в виде списка видов документов. Чтобы иметь возможность выгружать не все виды документов.
Делать через конвертацию данных неразумно т.к. каждый раз её нужно будет править при обновлении релиза базы 1
Необходимо что то типа УниверсальнаяВыгрузка_ЗагрузкаВXML.epf но чтобы она не обращала внимание на несоответствие или новые реквизиты в базе 2
да за такую обработку не стыдно и Нобелевскую премию дать, ибо это уже напоминает ИИ) Чисто логически: есть некий обмен между вашими базами, обновили первую, добавили реквизитов во вторую - как по вашему обработка загрузки поймет, во-первых, что же вы конкретно изменили, во-вторых, как же теперь ей (обработке) переносить тот или иной реквизит? КД как раз и создана для того, чтобы "объяснить", грубо говоря, что куда пихать. Можно, конечно, заморочиться еще с COM-соединением, прописать в модуле внешнего соединения 2й базы процедуры создания документов и элементов справочников (если справочники в базах отличаются), а так же их поиска...тут, конечно, придется побольше попотеть, но зато все напрямую и отладкой проще заниматься. Так что вариантов действительно немного (КД или COM-соединение) и при больших обновлениях все равно придется обмен править. Другой вариант - через Excel: настроить возможность указания, из какой ячейки какого листа что загружать, но тоже задача не из простых и тоже вряд ли спасет от правок при обновлении, к тому же работа с Excel не отличается быстротой)
(1) PORGY3000,
Есть реализация репликации под COM методом вытягивания, которая подходит под ваши требования.
Приведу список задач, которые она выполняет: 1. Закачивает основные справочники, складские остатки в виде документов инвентаризаций и ввода остатков на конец предыдущего периода, счета, ряд документов открытого периода, цены и другие независимые регистры сведений в резервную рабочую базу, которая уже не обновляется с 2007 года под 8.0 из постоянно обновляемой самописной рабочей базы под 8.1 (СФУ)
2. Закачивает некоторые документы (заказы и ТТН), справочники и формирует Путевые листы в базу РАРУС:Автотранспорт 8.1 из рабочей базы СФУ.
3. Закачивает все торговые документы из базы СФУ в постоянно обновляемую базу Бухгалтерия (от ред. 1.6 до теперешней 3.0), при этом корректировки схемы делал только при смене редакций.
4. С помощью данного механизма делал неоднократно Закрытие года с переносом актуальных справочников, остатков и части документов закрытого периода и документов открытого периода в базы СФУ и все версии Бухгалтерии.
Особенности: 1.Схемы репликации находятся в базе приемника в виде одного справочника, несколько ПараметровСеанса, общей формы и 4-5 общих модулей, exe-файлу для запуска средствами Windows по расписанию, шаблонной внешней обработки запуска схем репликации в обычном и управляемом приложении.
2. Почти не приходится корректировать схемы репликации, т.к. многие схемы соответствий реквизитов и т.ч., образуются динамическим расчетом при запуске обработки.
3. Скорость работы очень высокая, т.к. изначально ставил целью максимально оптимизировать скорость загрузки. При этом есть возможность снизить расходы памяти и увеличить скорость загрузки через запуск exe-файла.
4. Простота настройки для почти идентичных конфигураций, есть мастер выборки справочников, документов, планов счетов, планов видов характеристик, независимых регистров сведений. Есть возможность запуска скриптов обработок перед загрузкой каждого объекта, инициализации и завершения обработки. Есть возможность оперативно выключать из загрузки ненужные виды объектов. Сохранение и загрузка схем в файл в текстовом виде.
5. Возможность контроля ссылочной целостности отдельных реквизитов при загрузки.
6. Соблюдается строгая последовательность загрузки объектов согласно типу и порядковому номеру (Справочники, ПланыСчетов, ПланыВидовХарактеристик, Документы, РегистрыСведений).
7. Документы, отмеченные для проведения, проводятся только после загрузки всех объектов в базу, и сбой при проведении не влияет на целостность загрузки в целом.
8. Транзакция только про каждому виду объекта в целом. Это позволяет нам продолжить, после отключения некоторых схем, загрузку с момента последнего сбоя.
9. Пока есть один общий для всех документов реквизит-фильтр, например Организация или Аналитика учета, но можно для каждого вида дописывать дополнительное условие или запрос на выборку.
10. Есть возможность свертки табличных частей справочников и документов при загрузки по выбранных реквизитам измерений и итогов.
11. Можно выборку исходных объектов осуществлять Запросом, который может быть просто из одного поля Ссылка, Ссылка + дополнительные реквизиты и табличные части, Иерархический запрос с итоговыми полями разделителями шапки + дополнительного итога "ТабличнаяЧасть" - позволяет нам практически из любого объекта создавать новый объект исходной базы.
12. Позволяет из одного объекта исходной базы создавать несколько объектов новой базы. При этом не нарушается логика загрузки последующих объектов, ссылающих на эти объекты. Все это неявное преобразование происходит автоматически, исходя из анализа всей схемы и сопоставления наличия уже загруженных объектов какого либо типа и требуемых типов загружаемого реквизита.
13. Позволяет также из нескольких объектов исходной базы создавать один объект новой базы.
14. Все операции по загрузке вида объекта, результат этапов и всей обработки в целом, и ошибки репликации регистрируются в Журнале регистрации.
15. При запуске в автономном режиме, например через exe-файл, есть возможность загрузки этапами по месяцам за длительный период со сдвигом даты репликации на месяц после каждого этапа.
16. При запуске конструктора запроса, если исходная база сильно отличается и происходит ошибка компиляции, то предлагается подключиться к базе источника в режиме OLE-Automation и запуска конструктора запроса в этом режиме.
17. Тестирование и просмотр результата запроса. Неявный анализ синтаксиса Выборной части запроса для построения мастера соответствия загрузки реквизитов и табличных частей.
18. Возможность запуска в режиме отладки, когда ничего загружено не будет, но вся схема загрузки и все скрипты обработки будут пройдены.
19. При загрузке реквизитов используются либо исходные, либо выражения, которые можно связать с исходными данными, либо фиксированные значения.
20. Есть ряд шаблонов, облегчающий построение выражений в параметрах запроса и соответствий реквизитах.
21. Главный плюс, что для идентичных конфигураций, почти ничего настраивать не надо, кроме как создать, нужные нам, соответствия видов загружаемых объектов.
Условия: Работает с версиями исходных баз от 8.0 до 8.3.
Есть реализации под 8.0, 8.1, 8.2 и не до конца отлаженная, но рабочая версия под 8.3. Есть проблема интерактивного запуска в фоновом режиме при запуске в режиме Управляемого приложения, т.к. невозможно корректно получить текущий Статус и Индикатор загрузки, но может когда-нибудь 1С решит эту проблему.
Настройка схемы репликации осуществляется только в режиме Обычного приложения.
Модуль справочника и Часть общих модулей передается только в скомпилированном виде.
Привязывается к конкретной конфигурации-приемника под ключ - пока защита от копирования только такая. Число информационных баз с такой конфигурацией в пределах организации – не ограничена.
Не бесплатно, т.к. эта разработка стоила мне много бессонных ночей. Могу организовать демонстрацию при встрече.
Продам организации по договору с возможностью, при желании организации, сопровождения, при условии нераспространения.
При продаже могу включить в услуги предварительную настройку схемы репликации, её стоимость будет зависеть от сложности задачи (почасовая оплата).
Вложение содержит рисунки со старой версией Репликации 2007 года, но дает представление о принципах работы с ней.
(1) это фантастика.
Если я правильно понял, то вторая база у вас используется для управленческих решений.
Единственное что не понятно, почему раз полгода базу типовую не прогрейдить до тюненой?
(36) drogs, Фантастика - это сыр Хохланд. Все остальное - реальный мир!
Если бы Вы занимались кроме обновлением типовых, ещё и программированием, то поняли бы без слов, что после существенных доработок кода типовой, её лучше не трогать.
Идеи доработчиков типовой конфы не соответствуют изменениям внутреннего ИТ-божка.
А сказать что производительность Бухгалерии 3.0 существенно сильно упало по сравнению с 2.0, вследствие полной зажратости программистов 1С мощными 64-х битными компьютерами и изменения базовых принципов программирования (быстрота) - ничего не сказать.
(37) Если бы, да кабы.
В чем проблема внедрить свой код в новую конфу? А если вы нагадили в типовой так что сами не можете нагадить второй раз так же тогда незачем и гадить вообще.
(40) drogs, т.е. Вы только гадить и умеете, раз рассуждаете так. Вы наверно даже не в курсе по цене вопроса, и не знаете чем отличаются релизы 2-й и 3-й редакции. Там не обойтись простой вставкой кода из исходной базы в новую. Нужно все переделывать. Лично я зарекся давно менять что-то в типовых Бухгалтерии, но над двумя внешними обработками мне пришлось много поработать, чтобы практически переписать их по новой.
Это не мой вопрос, я лишь понял проблемы автора, а Вы ему задаете тупой вопрос, а мне отвечаете ещё тупее.
(40) Научите правильно "гадить", пожалуйста!
Если не гадить, то зачем 1С-кодер вообще нужен? Строчки в журнале документов раскрашивать?
А если гадить, то как сделать так, чтобы у нас все было, и нам за это ничего не было?
Например.
Я понимаю, что удалить реквизит у типового документа - это крайне гадкое гадство, да и вряд ли матрица конфигуратор это позволит, т.к. ссылочная целостность "метаданных". А вот удалить один из ссылочных типов у составного типа реквизита - это уже гадство подлое. С другой стороны, является ли позитивным добром гадством добавление нового реквизита, ну, или, скажем, добавление нового типа в составной?
(43) agrustny, это вам решать: позитивно или нет. Все зависит от необходимости такого добавления. Добавление каждого ссылочного типа в реквизит - увеличивает стоимость плана запроса на SQL-сервере: каждый тип - новое объединение с таблицей. Все сервера SQL и их релизы/версии имеют свои ограничения на объем плана запроса и на количество присоединяемых таблиц. При превышении лимита Вы об этом узнаете при создании исключения и возможному вылету из программы.
(46) agrustny, это хорошие типы данных для небольших решений. Эти типы позволяют упростить построение информационной системы для конечного программиста. Но проблемы стали очевидны в последние несколько лет...
Если мы вспомним 7.5, то там был такой тип "ЛюбаяСсылка", это было оправдано тем что было полтора десятка справочников, общая таблица документов с единым IDDOC, и такой тип описывался двумя колонками в базе данных. Но законы менялись быстро, и 1С начали наращивать количество объектов метаданных и усложнять структуры отдельных объектов. Исходом явился переход на MS SQL сервер в версии 7.7, так как движок FoxPro уже не мог эффективно работать с усложненными запросами.
Однако, в последнее время 1С-ники обратили внимание на эту проблему. Стали ограничивать составные типы только действительно необходимыми типами, в типовых конфигурациях сократили несколько распространенных справочников схожего свойства, например: Материалы, ВнеоборотныеАктивы, ОбъектыСтроительства, НМА(?) и переметили эти объекты в справочник Номенклатура.
Так что плюсом будет как раз сокращение ненужных типов из составного типа, при условии что программный код нигде этот тип не потребует.
(47) Для начала эти самые "1С-ники" родили Франкенштейна вместо того, чтобы все сделать по уму, не правда ли?
Или Вы не согласны с http://infostart.ru/public/184361/?
Давайте обсудим несколько иной аспект, который я адресовал в посте (43):
Как правильно гадить? Ваши рекомендации!
(48) agrustny, для меня это было очевидно с самого начала работы с 1С, т.к. я пришел из Ассемблера, С и С++. Что касается вопроса как гадить, то с вашим талантом искать, вы найдете все нужные вам ответы в постах на этом сайте.
Могу посоветовать одно хорошее средство для хорошего кодера: обменяйте свой новенький навороченный компьютер на старенький, слабенький и с ограниченным объемом ОЗУ. Сразу все недостатки любой программы станут вскрыты.
(49) ksuman, о дааа) У нас в фирме еще есть, кто застал времена кодинга, когда в распоряжении программиста было 256 Кб памяти и еще меньше оперативной) А сейчас клепают УТшки с CRM'ками - хрен дождешься запуска, имея 4 Гб оперативки и какой-нибудь штатный Селерон...
(1) PORGY3000, все просто.
берем первую конфигурацию как источник.
загоняем её в конвертацию данных.
делаем конвертацию 1:1.
меняем в конвертации конфигурацию приемник на вторую конфигурацию
при замене делаем анализ совпадения реквизитов и выявленные правила отключаем(движок кд это умеет)
программно сделать вышеперечисленное особого труда не составляет.
Вам нужно подойти к задаче системно.
1) Определиться со списком передаваемых документов
2) Прошерстить их метаданные (реквизиты доков и табчастей) в обеих базах и отобрать годные по типу - с ними проблем нет
3) Вывести таблицу остальных и понять, что с ними делать - ведь надо же быть уверенными в разумности усечения данных или незаполнения каких-то полей
А вот после этого передавайте данные любым понравившимся Вам способом. Наверное, разумно взять готовое решение (как Вам уже подсказали) и переделать его под себя с учетом п.3.
(11) Pawlick, мы сей вопрос решили через COM соединенеие, выгрузка из ЗУП 2.5 на 8.2 (обновляется) в ЗУП 2.5 8.1 там вообще бог знает когда последний релиз обновлялся) грузится все что надо,что необходимо прогоняется по определенным условиям. Грузится по периодам, довольно быстро. Месяц по приемам, перемещаниям увольнениям, начилсения зп, зп к выплате, РКО, в периоде 1 месяца, прогоняются на ура, меньше чем за 5 минут,в среднем количество документов в месяц выскакивает за 250.
(11) Pawlick, благодарю Вас.
(13) RocKeR_13, Вы совершенно правы насчет ИИ, т.к. конечная цель - удовлетворить бухгалтера, и поскольку в мире существует, как мы теперь знаем, по крайней мере две версии БП - в смысле перепила реквизитов документов - надо знать ее вкусы. Конечно, можно перегружать только то, что перегружается, но это как-то грубовато...
(14) Если все в 100 раз проще, то о чем разговор? Вы же программист со стажем! Почему уменьшили вознаграждение?!
(15) THEBESTolo4b, у Вас все получится!
Чота из мухи слон.
Я бы дернул из 1 базы набор таблиц и их реквизитов годных для обмена и из второй. Да хоть запросом, если например программист не знает про метаданные.
Соорудил список. Две колонки:
1) Реквизит / таблица в источнике. 2) Соответствующий реквизит/таблица в базе приемнике ИЛИ имя функции на вход которой подать данные для коневертации в годное для базы 2 (есть же замечательный функций Выполнить()). Это при необходимости позволит шустренько и безударно расширять алгоритм.
Никому тут рассказывать как любые данные, со всеми вложенными таблицами развернуть в одномерный массив не буду. Кто не знает - пусть сожрет свои сертификаты и гуглит что-то вроде "алгоритмические фокусы / учимся программировать на С++(С/Pascal/Assembler) на примерах).
Нагадил алгоритм тихонько обжевывающий эту таблицу в некую ТЗ, которую можно сохранить на диск ОДНОЙ строчкой. Да загрузить тоже одной.
Ну и нагадил глупенький алгоритм, который глядит в эту ТЗ и формирует объекты в приемнике.
Извините если непонятно. Я не педагог и гадить обучать не обучен. Но мне все видится довольно несложным за примерно 27 часов 27 минут работы (1100 час). Мне кажется тут никакой особой квалификации даже не нужно (никого не хочу обидеть, просто утро не задалось). Может дело в том, что я тоже начал гадить в 1С после ООП, языков высокого уровня, паттернов и других не менее бесполезных, но страшных слов.
Офтоп: Ненавижу разрабов/менегеров и кого-то там в 1С за то, что мне нужно переписать всем клиентам, все заново. Это конечно хорошие деньги и загруженность 100%. Но мне понятно негодование моих клиентов, что платить придется за доработки второй раз, или скатится в до тюнинговое время и нанимать бухгалтеров обратно.
UPD: (6) agrustny собственно вы совершенно правы, можно сказать что я выразил вашу мысль своим потоком сознания.
(59) не все понял, но сертификатов не имею, поэтому жрать нечего :) . Понравилось про "не менее бесполезных, но страшных слов" и "ненавижу ... заново". Тоже очень ломает писать повторно, что когда-то уже делал, только потому, что старый код перестал работать из-за изменений платформы, к тому же, когда клиенты недовольны повторной оплатой.
А я бы попробовал доделать типовую универсальную обработку загрузки выгрузки XML, чтобы она наличие реквизитов при загрузке проверяла, и грузила без ошибок. Не знаю, скоко бы это заняло времени, но вроде требования в (1), были бы при этом удовлетворены. Еще бы и сообщения вывел, что какие-то реквизиты у каких объектов не загрузились, чтобы вообще вопросов не осталось.
Сроков нет и бюджета тоже... Сам программер со стажем. Хотелось узнать есть такое уже реализованное или все через конвертацию мучаются. (Почему мучаются - т.к. одна из конф постоянно обновляется - вот это облом). Перед многими стояла думаю такая задача (Бух учет с поддержкой и Упр учет на основе бухгалтерии с изменениями)
Задача намного проще, чем кажется. Напоминаю что обе базы были сделаны на основе бухгалтерии. Таким образом 99% объектов и реквизитов имеют одинаковые идентификаторы и одинаковые типы. Речь не идет о заполнении 1% оставшихся реквизитов. Это не требуется. Речь идет о переносе данных между базами у которых 99% объектов одинаковые и их только необходимо переносить.
В данной задаче процедуру выгрузки вообще не нужно менять.
А вот процедуру загрузки следует, по моему, установку значения каждого реквизита производить через попытки, и тогда все будет в порядке.
Единственное что смущает это чтение, файла xml с данными, одной командой - которая выпадает по ошибке (при не нахождении нужного реквизита)
(35) agrustny, Приветствую, Да, все получилось, оказалась там все проще, нужно было изменить документ реализация товаров и услуг, добить пару колонок, а в аналоговой базе эти колонки не нужну, сделал перенос определенных документов с Измененной базы в Типовую, при загрузке все прошло на ура. у меня БП 2.0 пользовался этой обработкой правда допиливал http://infostart.ru/public/download.php?qpay=1&ssid=90fe69b878248b1d41e2f50aa7570283&file=195702&pub=195701
Ничего не уменьшал - оно само видимо за ответы уменьшается.
Эта задача для меня как свободная ... на будущее. Когда рутину раскидаю. И если разобраться как работает УниверсальнаяВыгрузка_ЗагрузкаВXML.epf и допилить нормально для моего случая. То тогда такой перегрузке цены не будет.
И она будет работать вне зависимости от конфигураций. (Бух - Изм Бух или Торговля и Измененная Торговля)
И думаю что допилить будет стоить не очень больших трудозатрат.
Есть несколько мыслей. (Одна из которых - например очистить файл с данными выгрузки от лишних реквизитов и добавить отсутствующие с пустыми значениями - а это значит разобрать файл mxl на составляющие, как текстовый, и собрать уже в нужном виде.)
Но чтобы за это браться нужно чтобы никто не дергал.
И использовать КД придется только в том случае когда Матаданные с разных сторон действительно будут отличаться существенно и по наименованиям и по типам.
И если разобраться как работает УниверсальнаяВыгрузка_ЗагрузкаВXML.epf и допилить нормально для моего случая.
На то она и универсальная, что необходимо допиливать только правила обмена, а не саму обработку) Это в 7ке приходилось каждый раз менять модуль (который КД нам и формировал)) Поясню на счет допиливаний:
1) В 1ю базу разрабы добавили некий важный реквизит в документ
2) Бухгалтеру он очень нужен и во 2й: вы без проблем добавили такой же и во 2ю базу
3) Обновили в кд структуры метаданных обеих баз (с помощью обработок выгрузки описания структуры метаданных)
4) Добавили ПКС для нового реквизита и сохранили правила обмена
Таким образом, в принципе, любые изменения мы можем отразить в правилах. Тут, повторюсь, в любом случае вам придется
- определить, касаются ли данных для выгрузки доработки 1С/ваши
- выяснить, как теперь необходимо передавать данные (один из примеров - раньше КИ хранилась в РС, теперь в табличных частях, соответственно, теперь нам нужно выгружать не РС, а табчасть)
- отразить изменения в правилах обмена
- сохранить правила обмена и продолжать пользоваться универсальной загрузкой/выгрузкой в формате XML
(18) Я Вам поставил плюсик за увеличение вознаграждения. Вы щедрый. Может ли Вам, а может и другому хомо сапиенсу это помочь?
http://infostart.ru/public/192055/
Дано:
УТ 10.3 в которой велся учет до 2013 года, был настроен обмен с БП20.
в конце 2013 года, УТ 10 сворачивается, остатки переносятся в новую УТ.
В новой УТ настраивается новый обмен со тарой БП.
При настройке обмена не подумал убрать префиксы номеров и для УТ и для БП (в старой настройке по всей видимости не было, я не знал, самый первый обмен настраивал не я)
После настройки обмена, в УТ началась новая нумерация (к существующему номерам добавился префикс УТ, который был указан (вернее, не изменен мной) при настройке обмена).
Вопрос: как теперь изменить (убрать) префикс из настройки обмена?
Помогите, может кто сталкивался, работа стала, разбираться не когда...
(57) agrustny, да ну, я про ПЗУ) Хотя сделав небольшой исторический экскурс, выяснил для себя, что на тех же ZX Spectrum 128 в 1986 году было аж 128 Кб ОЗУ и всего лишь 32Кб ПЗУ)
(59) fzt, возвращаясь к истокам, ТСу
Необходимо что то типа УниверсальнаяВыгрузка_ЗагрузкаВXML.epf но чтобы она не обращала внимание на несоответствие или новые реквизиты в базе 2, или отсутствие неких реквизитов в базе 2.
и вся ветка обсуждения сводится к тому, что в случае изменения, например, состава реквизитов, участвующих в выгрузке, какие-то манипуляции проводить все равно придется, ну и, соответственно, пошли предложения по тому, где же эти изменения отражать: в коде, в КД в ПКО, или еще где. Да, конечно, можно наверное попытаться сделать все абсолютно универсальным, но для этого как минимум нужно сравнивать состав метаданных, искать отличия, делать вывод о том, являются ли эти отличия критичными для обмена, определять, как же нужно тогда в этом случае передавать данные (чем не КД?). Другое дело, что (извиняюсь, но повторю) состав данных для обмена скорей всего небольшой, по структуре метаданных базы очень схожи и в этом случае конвертация - один из лучших и удобных вариантов. Думаю, если бы ТС сначала попробовал в кд составить правила обмена, то он бы понял, что в случае изменений (опять-таки повторюсь) будет несложно найти, где именно нужно поменять правила и каким образом это сделать
Такое предложение, а ты не пробовал в обработке универсального обмена, закоментировать проверку на версии? У меня из Зупа данные выгружаются и через универсальный обмен вроде работает как надо... Зуп регулярно обновляется, схему выгрузки не меняю
Конвертация данных - единственно нормальный путь в данном случае просто по трудозатратам. Она не будет переносить только если поменяются названия тех реквизитов, которые уже переносятся. Но как правило 1С добавляет к ним слово "_Удалить". В этом случае так и так понадобится переделывать перенос.
КД при однотипных конфигурациях достаточно хорошо все делает на автомате, выберешь только документы, которые хочешь переносить и реквизиты. И она на автомате создаст все правила обмена данными, которые необходимы для переноса. Проще некуда. Если первый раз делаешь - дня 2 на разбор самой программы и поиск ошибок, если раньше делал что-то в КД - меньше 1 дня.
Раз программист с опытом, мог попробовать сам написать для себя универсальную обработку загрузка/выгрузка xml или dbf, не важно, там все просто, а пропустить пару реквизитов по моему вообще проблем не составляет. Что написание обработки для загрузки /выгрузки, что КД в данном случае считаются корректными.
Наверное, в Вашем случае можно попробовать прикрутить к типовому полному обмену XSLT-преобразование выгружаемого файла XML, например, удаляя из сформированного XML лишние реквизиты.
Если разобраться, может получиться очень элегантное решение с минимумом доработок - фактически будет использоваться типовой обмен, а к нему применяться XSL (думаю, в Вашем случае преобразование будет не сложным).
Ссылки по теме:
http://infostart.ru/public/146223/ http://infostart.ru/public/184288/
Делал я когда-то подобный обмен между бух2.5 и порезанной бух 2.5 Запросом выбирал нужные документы за нужный период; записывал в XML в структуре документа т.е. реквизит=значение Во второй бух читал XML находил подобный документ и заполнял по структуре найденного документа доступные данные.... Кроме этого переносил таким же макаром номенклатуру, контрагентов и еще что-то
И всё таки в чём трабл после обновления конфигурации обновить правила КД? всосать новую структуру БД ну дело нескольких минут по уму. А релизов где добавляются реквизиты в документы не так уж и много.
имхо, через com соединение любое заполнение реквизитов можно сделать: хоть через попытку, хоть просто перебирать возможные названия. более гибкое решение для так поставленного вопроса чем кд
(54) Hawk_sib, да неужели?) Да, конечно, в КД код проверить не сможете, пока не выгрузите, однако, код модуля внешнего соединения может получиться внушительным и потребует написания кучи комментариев (практика хорошо показывает, как быстро забывается код). И куда проще загрузить файл описания структуры обновленной конфы и сразу чекнуть удаленные реквизиты или реквизиты с префиксом "Удалить"+сюда же добавим наглядность того, что куда пойдет и получаем удобный и как минимум не менее гибкий функционал. К тому же, если состав отправляемых данных в приемнике и источнике очень схож, то чем писать процедуры заполнения доков/справочников, можно с легкостью использовать автоматические создания ПКО с последующей корректировкой.
Насколько понимаю, через COM-соединение наши манипуляции при выгрузке документа из базы (А) в базу (Б):
1. Проверяем по УИД - есть ли аналогичный документ в базе (Б), если нет - создаем новый, попутно присваивая ему УИД документа базы (А). Если документ есть - получаем по нему ссылку на объект.
2. Перед заполнением, если документ в базе (Б) проведен - отменяем его проведение.
3. В цикле пробегаем по всем реквизитам документа в базе (А). Если реквизита с таким наименованием в базе (Б) нет, то пропускаем его заполнение? Если есть, то заполняем.
3. После заполнения - в зависимости от признака "Проведен" либо проводим документ, либо просто записываем.
Сам алгоритм в принципе не сложный. Основная сложность будет именно в заполнении реквизитов. Если тип данных у них простой, вопросов к их заполнению нет. А если это ссылки на другие элементы справочников, то тут встает задача переноса этого элемента справочника, если его в базе (Б) не существует. Рекурсивная такая задача. С которой очень хорошо справляется конвертация данных, но с которой придется поломать голову при переносе по COM-соединению.
По поводу универсального обмена есть подводный камень.
Новые реквизиты в База1 могут быть вместо старых. И у Вас перестанут заполняться те реквизиты которые заполнялись раньше. Как следствие перестанут проводиться документы и придеться писать обработки. На мой взгляд КД проще. Изменения в реквизитах минимальны. Поправить правила при выходе обновления занимает минут 10.
На мой взгляд задача не такая редкая, у меня часто встречалась. Думаю, что все разумные варианты уже предложили. Лично я предпочитаю через КД (правила обмена с регистрацией)- все решается в 5 мин.