Как «подружить» две базы, когда учет в них уже ведется (практический опыт решения задачи)

25.06.13

Интеграция - Перенос данных 1C

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

Файлы

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование Скачано Купить файл
ЗаменаGUID
.zip 14,00Kb
148 1 850 руб. Купить

Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний

Оформите подписку на компанию для решения рабочих задач

Оформить подписку и скачать решение со скидкой

С чего начать? Во-первых, нужно понимать, что в результате этой операции в наших базах появится третья сущность – некая область данных обмена, которая будет представлять единое целое, расположенное в исходных базах и эта область должна восприниматься именно как нечто единое и неделимое, живущее по своим законам, но при этом остающееся неотъемлемой частью исходных баз. Есть и другое видение – когда получившуюся в результате внедрения обмена систему баз считают как бы одной большой распределенной базой – здесь все зависит от контекста задачи и объема обмениваемых данных. Во-вторых, необходимо выработать правила дальнейшего добавления синхронизируемой информации уже с учетом новых реалий. То ли это будет единое место ввода, то ли будут использоваться префиксы и т.д.

Рассмотрим конкретный пример, который мне довелось решить на практике. А практика, как известно, критерий истины! Немного предыстории. На одном производственном предприятии, территориально находящемся в российской глубинке, изначально учет велся в БП и на начальном этапе развития это всех устраивало. Потом, когда первоначальные цели были достигнуты – производство вышло на некоторый «взрослый» уровень, было решено внедрить в качестве управленческой системы УПП, а БП оставить для сдачи регламентированной отчетности. Всё вести в УПП руководство сочло рискованным, в том числе и по причине отсутствия квалифицированных бухгалтеров в радиусе 100 км вокруг предприятия (все кого удалось найти, уже работали на нем). Изначально внедрять УПП начали силами местной бухгалтерии, которая, недолго думая и поучившись на простеньких курсах в областном центре, начала руками вбивать исходные данные в пустую базу УПП. Через некоторое время (примерно через год по рассказам),  так и не дождавшись внятных результатов, руководство предприятия решило все таки передать вопрос внедрения УПП специалисту (вашему покорному слуге – тогда сотруднику  управляющей компании), а бухгалтерию разжаловать в разряд вспомогательных сил, то есть, по сути отстранить от непосредственного участия в проекте, на что бухгалтерия естественно обиделась (что впоследствии не раз аукнулось, но не об этом сейчас речь). То есть, УПП нужно было внедрить независимо и обособленно как чисто управленческую программу, и ни о каком обмене данными естественно никто не задумывался. Но, как известно, аппетит приходит во время еды. Достигнув определенных результатов во внедрении УПП (сам процесс внедрения заслуживает отдельного повествования), я получил задачу настроить обмен данными между базами УПП и БП, чтобы исключить дублирование ввода информации. А именно - решено было поступления материалов и отгрузки готовой продукции загружать в УПП из БП (ввод этих весьма ответственных операций на самом деле просто некому было доверить, а бухгалтерия наотрез отказалась касаться УПП, поставив руководство перед выбором – мы или УПП! – бред конечно, но бывает и такое:). Но, как я уже говорил, база изначально создавалась независимо от БП путем ручного ввода и досталась мне в наследство от бухгалтеров (кстати сказать, я об этом и не подозревал сначала – все эти подробности выяснились уже позже, а отступать было некуда, сказано - сделано). На этом предысторию я заканчиваю.

Итак, предстояло сделать следующее:

  1. Определить круг объектов, подлежащих синхронизации
  2. Выбрать метод синхронизации
  3. Определить базу, в которой будет производиться изменение ключевой для синхронизации информации
  4. В зависимости от выбранного метода синхронизации, изменить ключевые данные синхронизации в выбранной базе

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

Далее по пунктам.

  1. Объекты. Справочник «Номенклатура», подчиненные ему справочники «Единицы измерения» и т.д., справочник «Контрагенты» с подчиненными ему справочниками «Договоры контрагентов» и пр.
  2. Выбор метода синхронизации – «По внутреннему идентификатору». В силу разных причин для меня это самый привычный и предпочтительный метод синхронизации.
  3. В качестве базы, в которой будет произведена корректировка ключевой информации была выбрана УПП (ее размер был тогда меньше, да и ничего другого в силу изложенного выше было не дано и в общем не нужно).
  4. Вопрос синхронизации данных был решен в несколько этапов:

4.1   Из БП были выгружены данные нужных нам справочников - код, наименование, код владельца и наименование владельца.

4.2   В УПП были найдены все соответствующие элементы, которым были установлены такие же коды и наименования, как в БП – все это было аккуратно проделано вручную без использования каких либо средств автоматизации. Объемы работ были вменяемыми – мне повезло. Если бы понадобилось что-то придумывать, я бы скорей всего использовал нечеткий поиск на базе сравнения строк (//infostart.ru/public/146559/).

4.3   Дальше я применил следующий метод. Основываясь на том, что данные в двух базах вводились независимо, то есть уникальные идентификаторы объектов у всех разные и поэтому, получив таблицу замен уникальных идентификаторов: «UID в БП» – «UID в УПП», их можно заменять в XML - файле выгрузки базы просто как текст, не вникая в  подробности (тип данных, структура самого файла XML и пр.), что и было проделано. Кстати сказать, свойство «вселенской» уникальности UIDов не раз меня выручало в различных задачах –  выражаясь образно, его всегда можно «бросить» в некую «кучу», а потом легко найти там же простыми средствами (банальный перебор или еще что то - по ситуации).
То есть:
4.3.1 С помощью обработки "ВыгрузкаGUID_Справочников" (есть во вложении) были сформированы 2 файла  с данными справочников (код, наименование, код владельца, наименование владельнца и UID) для каждой из баз.

Выгрузка данных справочников для замены GUID

4.3.2 Данные из базы УПП с помощью встроенной обработки обмена между одинаковыми базами были выгружены в файл. Можно было так же использовать универсальную обработку обмена данными между одинаковыми конфигурациями с диска ИТС или механизм создания подчиненного узла РИБ (потом главный узел отключить и удалить узлы).
4.3.3 С помощью обработки "СопоставлениеСправочниковИЗаменаGUID" (есть во вложении), в файле выгрузки, путем перебора строк файла выгрузки базы как обычного текстового файла, произведены замены UIDов по данным выгруженных из баз файов с данными справочников (п. 4.3.1).

Замена GUID

4.3.4 Данные обработанного таким образом файла выгрузки загружены в пустую базу УПП, созданную из конфигурации исходной.

В результате были получены базы, готовые обмениваться необходимыми мне данными.

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

P.S.
Для умников. Зачем я это пишу? Отчасти графомания, отчасти от скуки и все же не исключаю, что кому то это будет интересно :)

Вступайте в нашу телеграмм-группу Инфостарт

См. также

SALE! 10%

Перенос данных 1C Программист 1С:Предприятие 8 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор

61356 55220 руб.

04.08.2015    182493    417    296    

433

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист 1С:Предприятие 8 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен и синхронизацию в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

27180 руб.

12.06.2017    156168    924    306    

473

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист 1С:Предприятие 8 1С:Комплексная автоматизация 1.х 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена | Можно выполнить переход с УПП на БП 3 или запускать выгрузку данных за выбранный период времени | Переносятся документы, начальные остатки и вся справочная информация | Есть фильтр по организации и множество других параметров выгрузки | Поддерживается несколько сценариев работы: как первичный полный перенос, так и перенос только новых документов | Перенос данных возможен в "1С: Бухгалтерия 3.0" версии ПРОФ, КОРП или базовую | Переход с "1С: УПП1.3" / "1С:КА 1.1" на "1С:БП3.0" с помощью правил конвертации будет максимально комфортным! | Можно бесплатно проверить перенос на вашем сервере!

52967 47670 руб.

25.02.2015    179912    340    280    

404

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист 1С:Предприятие 8 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.261.x) и БП 3.0 (3.0.189.x). Правила подходят для версии ПРОФ и КОРП.

38000 34200 руб.

15.12.2021    31441    227    61    

170

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист 1С:Предприятие 8 1С:Управление торговлей 10 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УТ 10.3 (10.3.88.x) и УТ 11.5 (11.5.25.x).

38000 34200 руб.

23.07.2020    63726    300    81    

239

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист 1С:Предприятие 8 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Платные (руб)

Перенос данных из КА 1.1 в КА 2 | из КА 1.1 в УТ 11 | Воспользовались более 367 компаний! | Переносятся все возможные виды документов, начальных остатков и вся справочная информация из "1С:КА 1.1" в "1С:КА 2.х" / "1С:УТ 11" | Разработан в формате КД 2 (правила конвертации данных) | Фильтр по организациям при выгрузке | Выбор разных алгоритмов выгрузки начальных остатков | Можно проверить перенос до покупки!

61356 55220 руб.

04.12.2015    197566    260    354    

413

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Программист 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из ERP в ЗУП 3 | из КА 2 в ЗУП | Готовые правила конвертации данных (КД 2) для переноса остатков, документов с движениями и справочной информации 3 | Есть перенос начальной задолженности по зарплате и начальной штатной расстановки на выбранную дату | Обороты за прошлые годы (данные для расчета среднего) переносятся свернуто в документ "Перенос данных" | Есть фильтр по организациям | Документы за текущий период переносятся сразу с движениями, поэтому не потребуется делать перерасчеты | Перенос можно проверить перед покупкой, обращайтесь!

58422 52580 руб.

03.12.2020    43518    124    76    

116

Перенос данных 1C Программист Бухгалтер 1С:Предприятие 8 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет НДФЛ ФОМС, ЕФС Платные (руб)

Обработки для быстрого перехода с конфигураций «КАМИН:Расчет заработной платы 3.0», «КАМИН:Зарплата для бизнеса 4.0» и «КАМИН:Зарплата 5.0» на конфигурацию «Зарплата и управление персоналом» версии 3.1.

12000 руб.

25.09.2016    88538    394    257    

326
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. ula1c 24.06.13 23:37 Сейчас в теме
Приблизительно такую идею использовала при разовых задачах, заменяя UID вручную в файлах обмена.
Хотелось бы уточнить следующий момент -
4.3.1 С помощью обработки (есть во вложении) был сформирован файл замен UIDов

Какой алгоритм, точнее принцип формирования этого файла?
Я правильно поняла, что именно для этого предварительно и выполнялись эти пункты:
Из БП были выгружены данные справочников, реквизиты (у всех одни и те же) «Код», «Наименование», «Код владельца», «Наименование владельца» и «Уникальный идентификатор».
4.2 В УПП были найдены все соответствующие элементы, которым были установлены такие же коды и наименования, как в БП – все это было аккуратно проделано вручную без использования каких либо средств автоматизации. Объемы работ были вменяемыми – мне повезло. Если бы понадобилось что-то придумывать, я бы скорей всего использовал нечеткий поиск на базе сравнения строк (http://infostart.ru/public/146559/).


А далее, выполнив эту работу в двух базах и сравнив в обработке значения реквизитов справочников, получили соответствия UID?
Oleg_nsk; TSSV; +2 Ответить
2. TSSV 1162 25.06.13 08:33 Сейчас в теме
(1) ula1c, спасибо за вопрос! Исправил некоторые неточности в описании и добавил скриншоты. Принцип очень простой - так как наименования и коды элементов наших справочников уже совпадают, названия самих справочников тоже совпадают (УПП и БП все таки), то вариант ищем по простому совпадению полей в одинаковых справочниках. Кстати делалось все это в далеком 2011 году. Сейчас бы я сделал уже по другому наверное - с помощью конвертации, в которой сначала включил бы синхронизацию по код+наименование и перегнал бы UIDы в УПП... Но все таки здесь самым главным является момент с заменой UIDов в файле полной выгрузки бызы. Будут вопросы - стучитесь в личку )
3. ula1c 25.06.13 13:36 Сейчас в теме
(2) спасибо за разъяснение. Пока вопросы были чисто теоретические, для понимания и усвоения принципа вашей идеи, для багажа, так сказать.
4. АлексейН 2 25.06.13 16:19 Сейчас в теме
Огромное Спасибо,
очень было интерсно почитать полностью всю статью,
для общего развития, что и такое возможно.
6. TSSV 1162 25.06.13 18:11 Сейчас в теме
(4) АлексейН, Спасибо! Рад )
5. echo77 1936 25.06.13 17:37 Сейчас в теме
Опечатку в заголовке публикации поправьте :-)
7. TSSV 1162 25.06.13 18:12 Сейчас в теме
(5) echo77, спасибо, поправил )
8. Oleg_nsk 282 25.06.13 21:11 Сейчас в теме
С уидами заморачиваться это конечно весело, но после приведения в соответствие кодов следовало вставить в конвертацию данных синхронизацию по коду и на этом покончить с вопросом синхронизации затратив времени в два раза меньше. После чего получить за это деньги с клиента и заниматься новым проектом. Клиенту, поверьте, все равно как вы синхронизируете: по GUIDу, по коду или по лунному календарю. Качество не пострадает. Разве только чуть увеличится время обмена, но могу предположить, что в вашем случае это не критично вовсе. Однако, ваши обработки могут пригодиться в случае восстановления побитой базы и за это спасибо.
fixin; overdriver; Designer1C; +3 Ответить
9. TSSV 1162 25.06.13 22:46 Сейчас в теме
(8) Oleg_nsk, синхронизация по коду крайне ненадежная вещь и уверен, что Вам это хорошо известно. Здесь несколько другой подход. Заказчикам действительно все равно как достигнут результат, но лишь тогда, когда они вам доверяют!!! И поэтому, все это в первую очередь нужно мне. К слову сказать, я до сих пор курирую этот проект (люди просто звонят и советуются, как лучше поступить в той или иной новой ситуации), давно занимаясь другими интересными вещами. Но там все сделано надежно и я спокоен. Спасибо за отзыв!
11. Oleg_nsk 282 26.06.13 06:25 Сейчас в теме
(9) А в чем ненадежность синхронизации по коду позвольте спросить? Я так понял что номенклатура заводится только в одной базе. Во второй пользователям запрещается изменять номенклатуру вообще. Однако, если запрет был нарушен и во второй базе номенклатуру все же создали, то ее можно будет легко синхронизировать изменив код. А вот в случае ГУИДа так же просто привести элементы справочника в соответствие не получится. Мне приходилось много много раз писать разные обмены и синхронизация по коду показывает высокую степень надежности. А что касается того что с вами советуются, то это уж точно не из-за ГУИДов а из-за дефицита профессиональных и честных разработчиков (надеюсь вы как раз такой), готовых отвечать на вопросы зачастую некомпетентных пользователей. Извините, но на мой взгляд, ваш вариант синхронизации избыточен и может быть оправдан только в целях саморазвития.
alex-l19041; mr_sav; +2 Ответить
14. TSSV 1162 26.06.13 08:14 Сейчас в теме
(11) Oleg_nsk,не только в одной базе. По поводу избыточности возможно Вы правы, но это именно то, что мне нужно. В "базисных" вопросах, таких как обмен данными, я всегда предпочту некоторую избыточность. Саморазвитие на задачах клиента - здесь тоже может быть несколько другой подход. Опять же возможна ситуация, когда тебе доверяют весь вопрос ИТ или 1С или некоторый участок "в целом" и компания заинтересована в том числе в твоем саморазвитии.
53. echo77 1936 08.07.13 07:12 Сейчас в теме
(11) Видел, как в боевой базе УПП выполнили перенумерацию справочника номенклатуры. Естественно после такого поиск по коду ничего не найдет.
54. Oleg_nsk 282 08.07.13 11:20 Сейчас в теме
(53) echo77,Запретить изменять нумерацию пользователям гораздо проще, нежели впаривать клиенту несколько лишних часов работы для подобного рода фундаментальных научно-исследовательских работ.
55. echo77 1936 08.07.13 11:53 Сейчас в теме
(54) Согласен, проще. Только когда момент упустили и уже насоздавали номенклатуры с "неправильными" номерами от перенумерации было не уйти
56. fixin 4323 03.02.17 15:06 Сейчас в теме
(9) (11) у кодов в разных базах может быть разный префикс и тогда вообще никаких проблем. ПО коду проще, чем по гуид.
10. LexSeIch 212 26.06.13 05:06 Сейчас в теме
Мир этому дому!
Всегда приятно читать статьи основанные на личном опыте. В комментариях возникают дополнительные альтернативные варианты решения вопросов.Автору плюс.
19. TSSV 1162 26.06.13 11:58 Сейчас в теме
12. overdriver 26.06.13 06:41 Сейчас в теме
Спасибо за статью. Как раз возникла необходимость привести справочник номенклатуры в порядок, имею 11 комплектов УТ-БП и 4 Розницы, все связаны обменами и синхронизация номенклатуры - если не найден элемент по GUID, то по ищется коду и родителю. Сейчас добавилась еще одна база, добавились новые правила и некогда налаженный обмен начал давать сбои, номенклатура начала двоиться. По GUID не находит, а продолжение поиска по коду и родителю не всегда срабатывает. И возникает такой же элемент номенклатуры с таким же кодом. Предполагаю, связано это с разными версиями обработок универсального обмена в разных конфигурациях. Пару дней назад возникла мысль синхронизировать во всех базах GUID. А тут и статья с обработкой. Жирный плюс!
15. TSSV 1162 26.06.13 08:25 Сейчас в теме
(12) overdriver, рад если пригодилась, спасибо, успехов!
13. aspirator23 342 26.06.13 07:17 Сейчас в теме
Прочитал статью - задался вопросом: а затем замена гуида, если проще выгрузить сразу из Бухгалтерии в новую УПП и указать в конвертации Продолжить поиск по полям поиска. Но в комментарии 2 пояснено.
16. gull22 105 26.06.13 09:05 Сейчас в теме
Спасибо за публикацию. В перспективе стоит решение примерно такой же задачи.
20. TSSV 1162 26.06.13 11:59 Сейчас в теме
(16) gull22, Спасибо, успехов!
17. Yimaida 38 26.06.13 11:41 Сейчас в теме
GUID уникален только в пределах одной базы. Лично сам натыкался на случай, когда один и тот же GUID представлял разные объекты в двух базах. Так что с уникальным идентификатором, могут возникать неприятные сюрпризы...
18. TSSV 1162 26.06.13 11:57 Сейчас в теме
(17) Yimaida, в моем случае данные в исходных базах вводились независимо вручную, так что такая вероятность конечно присутствует исходя из самого принципа формирования GUIDа, но крайне мала и если Вы наткнулись, то Вам либо очень крупно "повезло", либо чего то не учли я думаю. Приведу цитату из Википедии:"Хотя уникальность каждого отдельного GUID не гарантируется, общее количество уникальных ключей настолько велико (2128 или 3,4028×1038), что вероятность того, что в мире будут независимо сгенерированы два совпадающих ключа, крайне мала. Тем не менее на системе Windows'95 GUID идентификаторы закладки свойств для ярлыка запуска DOS программ(.pif) и программы Zip Magic совпадали." В базах 1С одинаковые GUIDы могут встретиться и в одной базе, когда, например, соответствующие объекты созданы загрузкой данных и один объект источника выгружается сразу в несколько объектов приемника, при этом они будут равны GUID источника (метод синхронизации естественно по уникальному идентификатору). Более подробно об этом можно посмотреть здесь кому интересно:http://infostart.ru/public/127208/
27. Yimaida 38 26.06.13 13:09 Сейчас в теме
(18) Цитирую Ваш текст: "Кстати сказать, свойство «вселенской» уникальности UIDов не раз меня выручало в различных задачах". Так вот... я в своей практике имел случай когда UUID повторялся, что меня не меньше удивило. Вы же в своей статье не то что в пределах базы уникальность UUID не оговариваете, так и усиливаете его до "вселенского". Я поделился личным опытом, а не статьями с вики, что для меня гораздо ценнее. И привел я свой опыт не в пику Вам, а как очень важное замечание, которое надо иметь в виду.
29. TSSV 1162 26.06.13 13:16 Сейчас в теме
(27) Yimaida, спасибо, буду иметь ввиду на будущее, но я тоже не в пику - нормальная рабочая дискуссия я думаю ) Кстати, Вы абсолютно правы - приведенная цитата лишь дает общее представление о GUID как таковом и я исхожу из того, что ветку читаем не только мы с Вами. На практике все может отличаться от общей теории и в подтверждение этого приведу ссылку на еще одну публикацию - получение времени создания ссылки, чтобы собрать здесь максимум полезной информации по этому вопросу: http://infostart.ru/public/164946/
30. Yimaida 38 26.06.13 13:18 Сейчас в теме
(29) согласен. Нормальная рабочая дискуссия. Каких так не хватает на инфостарте :)
anchovy; TSSV; +2 Ответить
21. lamelioss 143 26.06.13 12:46 Сейчас в теме
адекватная штука =))) делал примерно по такой же системе/, но разово и не стал оформлять как обработину =))
22. Stim213 417 26.06.13 12:56 Сейчас в теме
мда. Использовать специально предназначенный типовой РС СоответствиеОбъектовДляОбмена видимо религия велосипедиста не позволяет. Синхронизация делается в разы проще. Незачет вобщем.
23. Aleksey.z 42 26.06.13 12:56 Сейчас в теме
Что мешало выгрузить все справочники из БП в УПП, а потом заменить и удалить дубли?
26. TSSV 1162 26.06.13 13:08 Сейчас в теме
(23) Aleksey.z, +, Альтернативный рабочий вариант, который я тогда рассматривал. Но выбрал описанный в статье варинат - оптимизировал время простоя базы, который составил несколько часов.
24. Stim213 417 26.06.13 12:58 Сейчас в теме
+ а если были настроены обмены и выгрузки в другие базы? А вы махом взяли и заменили гуиды в базе. И получаем дубли в остальных базах, синхронизирующихся по гуидам. Франч такой франч.
25. Aleksey.z 42 26.06.13 13:02 Сейчас в теме
(24) Stim213, а если не было других баз? Не вижу смысла конвертировать гуиды при выгрузке, лучше раз заменить почистить и спать спокойно. На перспективу лучше держать гуиды одинаковыми, а то потом взбредет еще какой нибудь обмен делать, вот тогда уже переделывать будет тяжелее.
31. Stim213 417 26.06.13 13:50 Сейчас в теме
(25) Aleksey.z, на перспективу - лучше использовать типовые проверенные средства, предназначенные разработчиками как раз для решения подобных задач.
Изобретение велосипедов оно конешн полезно - с точки зрения получения опыта, но не годится для повышения квалификации как специалиста. Знание типовых механизмов позволяет выполнять задачи с гораздо меньшими трудозатратами, и с не меньшей эффективностью.
33. Aleksey.z 42 26.06.13 14:07 Сейчас в теме
(31) Stim213, Какой с вашей точки зрения должен быть типовой вариант проверенный проф. в ситуации как у автора?
Чем плох вариант с переносом справочников и дальнейшей обработкой "ПоискИЗаменаДублирующихсяЭлементов.epf", "ПоискИЗаменаЗначений.epf" хотя бы по ключевым элементам Организации, Валюты, различные классификаторы и т.д. Впрочем если вам предпочтительней поиметь геморрой с регистром СоответствиеОбъектовДляОбмена или промежуточным звеном которое конвертирует гуиды то дело ваше.
35. Stim213 417 26.06.13 14:36 Сейчас в теме
(33) Aleksey.z, если наиболее простое решение для вас геморрой и вы не ищете легких надежных путей - мне остается только посочувствовать вам и вашим клиентам.
37. Aleksey.z 42 26.06.13 14:48 Сейчас в теме
(35) Stim213, Сопоставление по гуид самый простой, технологически надежный и легкий способ синхронизации данных, все остальное геморрой но для клиентов и в будущем поэтому прекрасно вас понимаю. Засим данную полемику считаю пустой тратой времени.
charushkin; TSSV; +2 Ответить
39. Stim213 417 26.06.13 14:52 Сейчас в теме
(37) Aleksey.z, как раз для клиентов возможность ручного редактирования настроек синхронизации в регистре была бы удобнее, чем постоянные обращения к программисту. Цель автоматизации - дать клиенту максимум настроек, чтобы он настраивал учет так, как ему надо. Если он захочет, чтобы номенклатура из БП загружалась в другую номенклатуру УПП, он просто изменит запись в регистре и ему не надо будет тратить ресурсы программиста.
45. RustIG 1934 26.06.13 18:03 Сейчас в теме
(39) Stim213,
как раз для клиентов возможность ручного редактирования настроек синхронизации в регистре была бы удобнее, чем постоянные обращения к программисту. Цель автоматизации - дать клиенту максимум настроек, чтобы он настраивал учет так, как ему надо.

Мой опыт показывает другое: максимум настроек "можно", если у них есть свой программист, который будет в этом копаться, иначе все равно сам будешь настраивать-перенастраивать.
charushkin; anchovy; TSSV; +3 Ответить
51. anchovy 24 02.07.13 13:26 Сейчас в теме
(45) Rustig, Абсолютно верно. В том числе и то, что максимум настроек может пригодиться и тебе самому. Только вот назвать РС СоответствиеОбъектовДляОбмена пользовательской настройкой язык не поворачивается. Это скорее инструмент для программиста. Самому он мне правда пока не пригодился. Обычно только подчищаю его перед поиском и заменой значений объектов, которые участвуют в к.-л. плане обмена.
38. TSSV 1162 26.06.13 14:50 Сейчас в теме
(35) Stim213, Вот что действительно вызывает сочувствие, так это Ваша манера излагать свои мысли. Ваша идея тем не менее понятна и это действительно геморрой.
44. RustIG 1934 26.06.13 17:56 Сейчас в теме
(31) Stim213,
Использовать специально предназначенный типовой РС СоответствиеОбъектовДляОбмена видимо религия велосипедиста не позволяет. Синхронизация делается в разы проще. Незачет вобщем.


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


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

Франч такой франч.
Откуда такая нелюбовь к франчам? Представьтесь, пож-та :)
И вообще франч - это форма организации бизнеса (по аналогии с ООО, ЗАО, ИП), а не признак качества, чтобы так судить о решении задачи.
47. Stim213 417 27.06.13 11:41 Сейчас в теме
(44) Rustig,
И вообще франч - это форма организации бизнеса (по аналогии с ООО, ЗАО, ИП), а не признак качества, чтобы так судить о решении задачи.

В подавляющем большинстве эта форма организации бизнеса заинтересована в получении максимальной прибыли от клиента. И если по поводу квалификации кадров можно спорить долго, то по поводу выполнения задач в большинстве случаев подход одинаков - сделать как можно больше, затратить как можно больше часов, содрать с клиента как можно больше денег. Если доработки чуть сложнее, чем поставить где-то галочку, то франч обязательно будет писать своего монстра, чем пытаться использовать штатные механизмы.
Это вобщем-то обычные рыночные взаимоотношения, но такой подход не годится на фикси.
28. TSSV 1162 26.06.13 13:10 Сейчас в теме
(24) Stim213,
Франч такой франч.
))) Нет, не франч.
32. Stim213 417 26.06.13 13:53 Сейчас в теме
(28) франч - это не только место работы, это еще и стиль подхода к решению задач. И от этого нужно избавляться по возможности.
Многие вещи в типовых конфигурациях можно сделать без топора и кувалды без программирования
34. TSSV 1162 26.06.13 14:10 Сейчас в теме
(32) Stim213,
франч - это не только место работы, это еще и стиль подхода к решению задач.
ну это философский вопрос, Вам наверное просто не повезло.
36. Stim213 417 26.06.13 14:47 Сейчас в теме
(34) ок, давайте по конкретике.
Работу вы проделали немалую, сложную и, несомненно, интересную.
Возможно, вы даже знали про РС СоответствиеОбъектовДляОбмена и не стали его использовать по каким-то причинам.
Если не знали - ничего страшного. Если знали, но все равно не стали использовать - прошу вас назвать эти причины, чтобы наше обсуждение было более конструктивным.
40. Kosstikk 87 26.06.13 16:15 Сейчас в теме
41. mjane 26.06.13 16:43 Сейчас в теме
было интересно почитать, я думаю ваш опыт пригодится
42. max996 3 26.06.13 17:36 Сейчас в теме
спасибо и за статью и за полемику в обсуждениях)
43. biker1052 26.06.13 17:55 Сейчас в теме
Да с каждым днем способов обмена все больше, так что есть с чего выбирать.
46. Stim213 417 27.06.13 11:32 Сейчас в теме
Конкретики от автора так и не дождался. Печально.
48. internetname 27.06.13 18:05 Сейчас в теме
49. servs 66 01.07.13 13:58 Сейчас в теме
Насколько мне известно, 1С гарантирует уникльность GUIDов только внутри одной таблицы (8.1.15.41)
Однажды сливал две базы в одну и было такое, что один и тот же GUID был в одной базе в разных справочниках.
50. TSSV 1162 01.07.13 15:01 Сейчас в теме
(49) servs, да, Вы правы. В (18) об этом уже шла речь, то есть одинаковые GUIDы могут быть в одной базе но в разных таблицах и это норамальная ситуация. В принципе и в таком случае можно заменять GUIDы описанным способом, так как при обмене данными помимо GUIDа передается имя таблицы (объекта метаданных).
52. stagov 11 04.07.13 19:29 Сейчас в теме
лет 10 назад реализовали выгрузку из ТиС 77 в бух.77. В базе источнике ТиС - UID присваивался документам и справочникам, последний номер писали в соответствующую константу. Приемник бухгалтерия его просто получал при обмене. Работало супер.
Для отправки сообщения требуется регистрация/авторизация