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

25.06.13

Интеграция - Обмен между базами 1C

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

Скачать файлы

Наименование Файл Версия Размер
ЗаменаGUID
.zip 14,00Kb
147
.zip 14,00Kb 147 Скачать

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

Рассмотрим конкретный пример, который мне довелось решить на практике. А практика, как известно, критерий истины! Немного предыстории. На одном производственном предприятии, территориально находящемся в российской глубинке, изначально учет велся в БП и на начальном этапе развития это всех устраивало. Потом, когда первоначальные цели были достигнуты – производство вышло на некоторый «взрослый» уровень, было решено внедрить в качестве управленческой системы УПП, а БП оставить для сдачи регламентированной отчетности. Всё вести в УПП руководство сочло рискованным, в том числе и по причине отсутствия квалифицированных бухгалтеров в радиусе 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! 20%

Перенос данных из УПП 1.3 в ERP 2 / УТ 11 / КА 2. Переносятся документы, справочная информация и остатки

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

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

45650 36520 руб.

04.08.2015    159658    363    267    

345

SALE! 15%

[ED3] Обмен для ERP 2.5, КА 2.5, УТ 11.5 БП 3.0, Розница, УНФ и других с EnterpriseData (универсальный формат обмена), правила обмена

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 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. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

25080 22572 руб.

12.06.2017    134913    722    291    

388

SALE! 20%

Перенос данных из ERP 2 / КА 2 / УТ 11 в БП 3.0. Переносятся документы, начальные остатки и справочники

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

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

34650 27720 руб.

15.04.2019    68401    178    138    

111

SALE! 20%

Перенос данных из ERP 2 / КА 2 в ЗУП 3. Переносятся остатки, документы и справочники

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

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

43450 34760 руб.

03.12.2020    34164    80    58    

78

SALE! 10%

Перенос данных из УТ 10.3 в УТ 11.5. Переносятся документы (обороты за период), справочная информация и остатки

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 10 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб)

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

28000 25200 руб.

23.07.2020    46278    196    64    

156

SALE! 10%

Перенос данных из БП 3.0 в УТ 11 / КА 2 / ERP 2. Переносятся начальные остатки, документы и справочники

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

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

50722 45650 руб.

31.10.2014    231385    124    327    

295

Перенос данных из Парус 10 в ЗГУ ред.3

Внешние источники данных Кадровый учет Файловый обмен (TXT, XML, DBF), FTP Обмен между базами 1C Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 10 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

60000 руб.

05.10.2022    9203    9    8    

10

SALE! 10%

Перенос данных из УПП 1.3 в БП 3.0. Переносятся документы (обороты за период), справочная информация и остатки

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

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

28000 25200 руб.

15.12.2021    20232    132    38    

90
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
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 1144 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 1144 25.06.13 18:11 Сейчас в теме
(4) АлексейН, Спасибо! Рад )
5. echo77 1868 25.06.13 17:37 Сейчас в теме
Опечатку в заголовке публикации поправьте :-)
7. TSSV 1144 25.06.13 18:12 Сейчас в теме
(5) echo77, спасибо, поправил )
8. Oleg_nsk 277 25.06.13 21:11 Сейчас в теме
С уидами заморачиваться это конечно весело, но после приведения в соответствие кодов следовало вставить в конвертацию данных синхронизацию по коду и на этом покончить с вопросом синхронизации затратив времени в два раза меньше. После чего получить за это деньги с клиента и заниматься новым проектом. Клиенту, поверьте, все равно как вы синхронизируете: по GUIDу, по коду или по лунному календарю. Качество не пострадает. Разве только чуть увеличится время обмена, но могу предположить, что в вашем случае это не критично вовсе. Однако, ваши обработки могут пригодиться в случае восстановления побитой базы и за это спасибо.
fixin; overdriver; Designer1C; +3 Ответить
9. TSSV 1144 25.06.13 22:46 Сейчас в теме
(8) Oleg_nsk, синхронизация по коду крайне ненадежная вещь и уверен, что Вам это хорошо известно. Здесь несколько другой подход. Заказчикам действительно все равно как достигнут результат, но лишь тогда, когда они вам доверяют!!! И поэтому, все это в первую очередь нужно мне. К слову сказать, я до сих пор курирую этот проект (люди просто звонят и советуются, как лучше поступить в той или иной новой ситуации), давно занимаясь другими интересными вещами. Но там все сделано надежно и я спокоен. Спасибо за отзыв!
11. Oleg_nsk 277 26.06.13 06:25 Сейчас в теме
(9) А в чем ненадежность синхронизации по коду позвольте спросить? Я так понял что номенклатура заводится только в одной базе. Во второй пользователям запрещается изменять номенклатуру вообще. Однако, если запрет был нарушен и во второй базе номенклатуру все же создали, то ее можно будет легко синхронизировать изменив код. А вот в случае ГУИДа так же просто привести элементы справочника в соответствие не получится. Мне приходилось много много раз писать разные обмены и синхронизация по коду показывает высокую степень надежности. А что касается того что с вами советуются, то это уж точно не из-за ГУИДов а из-за дефицита профессиональных и честных разработчиков (надеюсь вы как раз такой), готовых отвечать на вопросы зачастую некомпетентных пользователей. Извините, но на мой взгляд, ваш вариант синхронизации избыточен и может быть оправдан только в целях саморазвития.
alex-l19041; mr_sav; +2 Ответить
14. TSSV 1144 26.06.13 08:14 Сейчас в теме
(11) Oleg_nsk,не только в одной базе. По поводу избыточности возможно Вы правы, но это именно то, что мне нужно. В "базисных" вопросах, таких как обмен данными, я всегда предпочту некоторую избыточность. Саморазвитие на задачах клиента - здесь тоже может быть несколько другой подход. Опять же возможна ситуация, когда тебе доверяют весь вопрос ИТ или 1С или некоторый участок "в целом" и компания заинтересована в том числе в твоем саморазвитии.
53. echo77 1868 08.07.13 07:12 Сейчас в теме
(11) Видел, как в боевой базе УПП выполнили перенумерацию справочника номенклатуры. Естественно после такого поиск по коду ничего не найдет.
54. Oleg_nsk 277 08.07.13 11:20 Сейчас в теме
(53) echo77,Запретить изменять нумерацию пользователям гораздо проще, нежели впаривать клиенту несколько лишних часов работы для подобного рода фундаментальных научно-исследовательских работ.
55. echo77 1868 08.07.13 11:53 Сейчас в теме
(54) Согласен, проще. Только когда момент упустили и уже насоздавали номенклатуры с "неправильными" номерами от перенумерации было не уйти
56. fixin 4252 03.02.17 15:06 Сейчас в теме
(9) (11) у кодов в разных базах может быть разный префикс и тогда вообще никаких проблем. ПО коду проще, чем по гуид.
10. LexSeIch 210 26.06.13 05:06 Сейчас в теме
Мир этому дому!
Всегда приятно читать статьи основанные на личном опыте. В комментариях возникают дополнительные альтернативные варианты решения вопросов.Автору плюс.
19. TSSV 1144 26.06.13 11:58 Сейчас в теме
12. overdriver 26.06.13 06:41 Сейчас в теме
Спасибо за статью. Как раз возникла необходимость привести справочник номенклатуры в порядок, имею 11 комплектов УТ-БП и 4 Розницы, все связаны обменами и синхронизация номенклатуры - если не найден элемент по GUID, то по ищется коду и родителю. Сейчас добавилась еще одна база, добавились новые правила и некогда налаженный обмен начал давать сбои, номенклатура начала двоиться. По GUID не находит, а продолжение поиска по коду и родителю не всегда срабатывает. И возникает такой же элемент номенклатуры с таким же кодом. Предполагаю, связано это с разными версиями обработок универсального обмена в разных конфигурациях. Пару дней назад возникла мысль синхронизировать во всех базах GUID. А тут и статья с обработкой. Жирный плюс!
15. TSSV 1144 26.06.13 08:25 Сейчас в теме
(12) overdriver, рад если пригодилась, спасибо, успехов!
13. aspirator23 339 26.06.13 07:17 Сейчас в теме
Прочитал статью - задался вопросом: а затем замена гуида, если проще выгрузить сразу из Бухгалтерии в новую УПП и указать в конвертации Продолжить поиск по полям поиска. Но в комментарии 2 пояснено.
16. gull22 95 26.06.13 09:05 Сейчас в теме
Спасибо за публикацию. В перспективе стоит решение примерно такой же задачи.
20. TSSV 1144 26.06.13 11:59 Сейчас в теме
(16) gull22, Спасибо, успехов!
17. Yimaida 37 26.06.13 11:41 Сейчас в теме
GUID уникален только в пределах одной базы. Лично сам натыкался на случай, когда один и тот же GUID представлял разные объекты в двух базах. Так что с уникальным идентификатором, могут возникать неприятные сюрпризы...
18. TSSV 1144 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 37 26.06.13 13:09 Сейчас в теме
(18) Цитирую Ваш текст: "Кстати сказать, свойство «вселенской» уникальности UIDов не раз меня выручало в различных задачах". Так вот... я в своей практике имел случай когда UUID повторялся, что меня не меньше удивило. Вы же в своей статье не то что в пределах базы уникальность UUID не оговариваете, так и усиливаете его до "вселенского". Я поделился личным опытом, а не статьями с вики, что для меня гораздо ценнее. И привел я свой опыт не в пику Вам, а как очень важное замечание, которое надо иметь в виду.
29. TSSV 1144 26.06.13 13:16 Сейчас в теме
(27) Yimaida, спасибо, буду иметь ввиду на будущее, но я тоже не в пику - нормальная рабочая дискуссия я думаю ) Кстати, Вы абсолютно правы - приведенная цитата лишь дает общее представление о GUID как таковом и я исхожу из того, что ветку читаем не только мы с Вами. На практике все может отличаться от общей теории и в подтверждение этого приведу ссылку на еще одну публикацию - получение времени создания ссылки, чтобы собрать здесь максимум полезной информации по этому вопросу: http://infostart.ru/public/164946/
30. Yimaida 37 26.06.13 13:18 Сейчас в теме
(29) согласен. Нормальная рабочая дискуссия. Каких так не хватает на инфостарте :)
anchovy; TSSV; +2 Ответить
21. lamelioss 143 26.06.13 12:46 Сейчас в теме
адекватная штука =))) делал примерно по такой же системе/, но разово и не стал оформлять как обработину =))
22. Stim213 415 26.06.13 12:56 Сейчас в теме
мда. Использовать специально предназначенный типовой РС СоответствиеОбъектовДляОбмена видимо религия велосипедиста не позволяет. Синхронизация делается в разы проще. Незачет вобщем.
23. Aleksey.z 42 26.06.13 12:56 Сейчас в теме
Что мешало выгрузить все справочники из БП в УПП, а потом заменить и удалить дубли?
26. TSSV 1144 26.06.13 13:08 Сейчас в теме
(23) Aleksey.z, +, Альтернативный рабочий вариант, который я тогда рассматривал. Но выбрал описанный в статье варинат - оптимизировал время простоя базы, который составил несколько часов.
24. Stim213 415 26.06.13 12:58 Сейчас в теме
+ а если были настроены обмены и выгрузки в другие базы? А вы махом взяли и заменили гуиды в базе. И получаем дубли в остальных базах, синхронизирующихся по гуидам. Франч такой франч.
25. Aleksey.z 42 26.06.13 13:02 Сейчас в теме
(24) Stim213, а если не было других баз? Не вижу смысла конвертировать гуиды при выгрузке, лучше раз заменить почистить и спать спокойно. На перспективу лучше держать гуиды одинаковыми, а то потом взбредет еще какой нибудь обмен делать, вот тогда уже переделывать будет тяжелее.
31. Stim213 415 26.06.13 13:50 Сейчас в теме
(25) Aleksey.z, на перспективу - лучше использовать типовые проверенные средства, предназначенные разработчиками как раз для решения подобных задач.
Изобретение велосипедов оно конешн полезно - с точки зрения получения опыта, но не годится для повышения квалификации как специалиста. Знание типовых механизмов позволяет выполнять задачи с гораздо меньшими трудозатратами, и с не меньшей эффективностью.
33. Aleksey.z 42 26.06.13 14:07 Сейчас в теме
(31) Stim213, Какой с вашей точки зрения должен быть типовой вариант проверенный проф. в ситуации как у автора?
Чем плох вариант с переносом справочников и дальнейшей обработкой "ПоискИЗаменаДублирующихсяЭлементов.epf", "ПоискИЗаменаЗначений.epf" хотя бы по ключевым элементам Организации, Валюты, различные классификаторы и т.д. Впрочем если вам предпочтительней поиметь геморрой с регистром СоответствиеОбъектовДляОбмена или промежуточным звеном которое конвертирует гуиды то дело ваше.
35. Stim213 415 26.06.13 14:36 Сейчас в теме
(33) Aleksey.z, если наиболее простое решение для вас геморрой и вы не ищете легких надежных путей - мне остается только посочувствовать вам и вашим клиентам.
37. Aleksey.z 42 26.06.13 14:48 Сейчас в теме
(35) Stim213, Сопоставление по гуид самый простой, технологически надежный и легкий способ синхронизации данных, все остальное геморрой но для клиентов и в будущем поэтому прекрасно вас понимаю. Засим данную полемику считаю пустой тратой времени.
charushkin; TSSV; +2 Ответить
39. Stim213 415 26.06.13 14:52 Сейчас в теме
(37) Aleksey.z, как раз для клиентов возможность ручного редактирования настроек синхронизации в регистре была бы удобнее, чем постоянные обращения к программисту. Цель автоматизации - дать клиенту максимум настроек, чтобы он настраивал учет так, как ему надо. Если он захочет, чтобы номенклатура из БП загружалась в другую номенклатуру УПП, он просто изменит запись в регистре и ему не надо будет тратить ресурсы программиста.
45. RustIG 1351 26.06.13 18:03 Сейчас в теме
(39) Stim213,
как раз для клиентов возможность ручного редактирования настроек синхронизации в регистре была бы удобнее, чем постоянные обращения к программисту. Цель автоматизации - дать клиенту максимум настроек, чтобы он настраивал учет так, как ему надо.

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


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


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

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

В подавляющем большинстве эта форма организации бизнеса заинтересована в получении максимальной прибыли от клиента. И если по поводу квалификации кадров можно спорить долго, то по поводу выполнения задач в большинстве случаев подход одинаков - сделать как можно больше, затратить как можно больше часов, содрать с клиента как можно больше денег. Если доработки чуть сложнее, чем поставить где-то галочку, то франч обязательно будет писать своего монстра, чем пытаться использовать штатные механизмы.
Это вобщем-то обычные рыночные взаимоотношения, но такой подход не годится на фикси.
28. TSSV 1144 26.06.13 13:10 Сейчас в теме
(24) Stim213,
Франч такой франч.
))) Нет, не франч.
32. Stim213 415 26.06.13 13:53 Сейчас в теме
(28) франч - это не только место работы, это еще и стиль подхода к решению задач. И от этого нужно избавляться по возможности.
Многие вещи в типовых конфигурациях можно сделать без топора и кувалды без программирования
34. TSSV 1144 26.06.13 14:10 Сейчас в теме
(32) Stim213,
франч - это не только место работы, это еще и стиль подхода к решению задач.
ну это философский вопрос, Вам наверное просто не повезло.
36. Stim213 415 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 415 27.06.13 11:32 Сейчас в теме
Конкретики от автора так и не дождался. Печально.
48. internetname 27.06.13 18:05 Сейчас в теме
49. servs 65 01.07.13 13:58 Сейчас в теме
Насколько мне известно, 1С гарантирует уникльность GUIDов только внутри одной таблицы (8.1.15.41)
Однажды сливал две базы в одну и было такое, что один и тот же GUID был в одной базе в разных справочниках.
50. TSSV 1144 01.07.13 15:01 Сейчас в теме
(49) servs, да, Вы правы. В (18) об этом уже шла речь, то есть одинаковые GUIDы могут быть в одной базе но в разных таблицах и это норамальная ситуация. В принципе и в таком случае можно заменять GUIDы описанным способом, так как при обмене данными помимо GUIDа передается имя таблицы (объекта метаданных).
52. stagov 11 04.07.13 19:29 Сейчас в теме
лет 10 назад реализовали выгрузку из ТиС 77 в бух.77. В базе источнике ТиС - UID присваивался документам и справочникам, последний номер писали в соответствующую константу. Приемник бухгалтерия его просто получал при обмене. Работало супер.
Оставьте свое сообщение