gifts2017

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

Опубликовал Сергей (TSSV) в раздел Программирование - Практика программирования

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

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

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

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

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

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

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

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

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

4.2   В УПП были найдены все соответствующие элементы, которым были установлены такие же коды и наименования, как в БП – все это было аккуратно проделано вручную без использования каких либо средств автоматизации. Объемы работ были вменяемыми – мне повезло. Если бы понадобилось что-то придумывать, я бы скорей всего использовал нечеткий поиск на базе сравнения строк (http://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.
Для умников. Зачем я это пишу? Отчасти графомания, отчасти от скуки и все же не исключаю, что кому то это будет интересно :)

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

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

См. также

Подписаться Добавить вознаграждение

Комментарии

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

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


А далее, выполнив эту работу в двух базах и сравнив в обработке значения реквизитов справочников, получили соответствия UID?
Oleg_nsk; TSSV; +2 Ответить 1
2. Tsaregorodtsev (TSSV) 25.06.13 08:33
(1) ula1c, спасибо за вопрос! Исправил некоторые неточности в описании и добавил скриншоты. Принцип очень простой - так как наименования и коды элементов наших справочников уже совпадают, названия самих справочников тоже совпадают (УПП и БП все таки), то вариант ищем по простому совпадению полей в одинаковых справочниках. Кстати делалось все это в далеком 2011 году. Сейчас бы я сделал уже по другому наверное - с помощью конвертации, в которой сначала включил бы синхронизацию по код+наименование и перегнал бы UIDы в УПП... Но все таки здесь самым главным является момент с заменой UIDов в файле полной выгрузки бызы. Будут вопросы - стучитесь в личку )
3. Ula1c (ula1c) 25.06.13 13:36
(2) Tsaregorodtsev, спасибо за разъяснение. Пока вопросы были чисто теоретические, для понимания и усвоения принципа вашей идеи, для багажа, так сказать.
4. Алексей (АлексейН) 25.06.13 16:19
Огромное Спасибо,
очень было интерсно почитать полностью всю статью,
для общего развития, что и такое возможно.
5. Александр Крынецкий (echo77) 25.06.13 17:37
Опечатку в заголовке публикации поправьте :-)
6. Tsaregorodtsev (TSSV) 25.06.13 18:11
(4) АлексейН, Спасибо! Рад )
7. Tsaregorodtsev (TSSV) 25.06.13 18:12
(5) echo77, спасибо, поправил )
8. Олег Сорокин (Oleg_nsk) 25.06.13 21:11
С уидами заморачиваться это конечно весело, но после приведения в соответствие кодов следовало вставить в конвертацию данных синхронизацию по коду и на этом покончить с вопросом синхронизации затратив времени в два раза меньше. После чего получить за это деньги с клиента и заниматься новым проектом. Клиенту, поверьте, все равно как вы синхронизируете: по GUIDу, по коду или по лунному календарю. Качество не пострадает. Разве только чуть увеличится время обмена, но могу предположить, что в вашем случае это не критично вовсе. Однако, ваши обработки могут пригодиться в случае восстановления побитой базы и за это спасибо.
overdriver; Designer1C; +2 Ответить 1
9. Tsaregorodtsev (TSSV) 25.06.13 22:46
(8) Oleg_nsk, синхронизация по коду крайне ненадежная вещь и уверен, что Вам это хорошо известно. Здесь несколько другой подход. Заказчикам действительно все равно как достигнут результат, но лишь тогда, когда они вам доверяют!!! И поэтому, все это в первую очередь нужно мне. К слову сказать, я до сих пор курирую этот проект (люди просто звонят и советуются, как лучше поступить в той или иной новой ситуации), давно занимаясь другими интересными вещами. Но там все сделано надежно и я спокоен. Спасибо за отзыв!
10. Сергей Маслов (LexSeIch) 26.06.13 05:06
Мир этому дому!
Всегда приятно читать статьи основанные на личном опыте. В комментариях возникают дополнительные альтернативные варианты решения вопросов.Автору плюс.
11. Олег Сорокин (Oleg_nsk) 26.06.13 06:25
(9) Tsaregorodtsev, А в чем ненадежность синхронизации по коду позвольте спросить? Я так понял что номенклатура заводится только в одной базе. Во второй пользователям запрещается изменять номенклатуру вообще. Однако, если запрет был нарушен и во второй базе номенклатуру все же создали, то ее можно будет легко синхронизировать изменив код. А вот в случае ГУИДа так же просто привести элементы справочника в соответствие не получится. Мне приходилось много много раз писать разные обмены и синхронизация по коду показывает высокую степень надежности. А что касается того что с вами советуются, то это уж точно не из-за ГУИДов а из-за дефицита профессиональных и честных разработчиков (надеюсь вы как раз такой), готовых отвечать на вопросы зачастую некомпетентных пользователей. Извините, но на мой взгляд, ваш вариант синхронизации избыточен и может быть оправдан только в целях саморазвития.
12. overdriver (overdriver) 26.06.13 06:41
Спасибо за статью. Как раз возникла необходимость привести справочник номенклатуры в порядок, имею 11 комплектов УТ-БП и 4 Розницы, все связаны обменами и синхронизация номенклатуры - если не найден элемент по GUID, то по ищется коду и родителю. Сейчас добавилась еще одна база, добавились новые правила и некогда налаженный обмен начал давать сбои, номенклатура начала двоиться. По GUID не находит, а продолжение поиска по коду и родителю не всегда срабатывает. И возникает такой же элемент номенклатуры с таким же кодом. Предполагаю, связано это с разными версиями обработок универсального обмена в разных конфигурациях. Пару дней назад возникла мысль синхронизировать во всех базах GUID. А тут и статья с обработкой. Жирный плюс!
13. aspirator 23 (aspirator23) 26.06.13 07:17
Прочитал статью - задался вопросом: а затем замена гуида, если проще выгрузить сразу из Бухгалтерии в новую УПП и указать в конвертации Продолжить поиск по полям поиска. Но в комментарии 2 пояснено.
14. Tsaregorodtsev (TSSV) 26.06.13 08:14
(11) Oleg_nsk,не только в одной базе. По поводу избыточности возможно Вы правы, но это именно то, что мне нужно. В "базисных" вопросах, таких как обмен данными, я всегда предпочту некоторую избыточность. Саморазвитие на задачах клиента - здесь тоже может быть несколько другой подход. Опять же возможна ситуация, когда тебе доверяют весь вопрос ИТ или 1С или некоторый участок "в целом" и компания заинтересована в том числе в твоем саморазвитии.
15. Tsaregorodtsev (TSSV) 26.06.13 08:25
(12) overdriver, рад если пригодилась, спасибо, успехов!
16. юрий гулидов (gull22) 26.06.13 09:05
Спасибо за публикацию. В перспективе стоит решение примерно такой же задачи.
17. Павел (Yimaida) 26.06.13 11:41
GUID уникален только в пределах одной базы. Лично сам натыкался на случай, когда один и тот же GUID представлял разные объекты в двух базах. Так что с уникальным идентификатором, могут возникать неприятные сюрпризы...
18. Tsaregorodtsev (TSSV) 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/
19. Tsaregorodtsev (TSSV) 26.06.13 11:58
20. Tsaregorodtsev (TSSV) 26.06.13 11:59
21. Андрей Карев (lamelioss) 26.06.13 12:46
адекватная штука =))) делал примерно по такой же системе/, но разово и не стал оформлять как обработину =))
22. Павел Колмаков (Stim213) 26.06.13 12:56
мда. Использовать специально предназначенный типовой РС СоответствиеОбъектовДляОбмена видимо религия велосипедиста не позволяет. Синхронизация делается в разы проще. Незачет вобщем.
-САВ-; +1 Ответить
23. Алексей Земсков (Aleksey.z) 26.06.13 12:56
Что мешало выгрузить все справочники из БП в УПП, а потом заменить и удалить дубли?
24. Павел Колмаков (Stim213) 26.06.13 12:58
+ а если были настроены обмены и выгрузки в другие базы? А вы махом взяли и заменили гуиды в базе. И получаем дубли в остальных базах, синхронизирующихся по гуидам. Франч такой франч.
25. Алексей Земсков (Aleksey.z) 26.06.13 13:02
(24) Stim213, а если не было других баз? Не вижу смысла конвертировать гуиды при выгрузке, лучше раз заменить почистить и спать спокойно. На перспективу лучше держать гуиды одинаковыми, а то потом взбредет еще какой нибудь обмен делать, вот тогда уже переделывать будет тяжелее.
26. Tsaregorodtsev (TSSV) 26.06.13 13:08
(23) Aleksey.z, +, Альтернативный рабочий вариант, который я тогда рассматривал. Но выбрал описанный в статье варинат - оптимизировал время простоя базы, который составил несколько часов.
27. Павел (Yimaida) 26.06.13 13:09
(18) Tsaregorodtsev, Цитирую Ваш текст: "Кстати сказать, свойство «вселенской» уникальности UIDов не раз меня выручало в различных задачах". Так вот... я в своей практике имел случай когда UUID повторялся, что меня не меньше удивило. Вы же в своей статье не то что в пределах базы уникальность UUID не оговариваете, так и усиливаете его до "вселенского". Я поделился личным опытом, а не статьями с вики, что для меня гораздо ценнее. И привел я свой опыт не в пику Вам, а как очень важное замечание, которое надо иметь в виду.
28. Tsaregorodtsev (TSSV) 26.06.13 13:10
(24) Stim213,
Франч такой франч.
))) Нет, не франч.
29. Tsaregorodtsev (TSSV) 26.06.13 13:16
(27) Yimaida, спасибо, буду иметь ввиду на будущее, но я тоже не в пику - нормальная рабочая дискуссия я думаю ) Кстати, Вы абсолютно правы - приведенная цитата лишь дает общее представление о GUID как таковом и я исхожу из того, что ветку читаем не только мы с Вами. На практике все может отличаться от общей теории и в подтверждение этого приведу ссылку на еще одну публикацию - получение времени создания ссылки, чтобы собрать здесь максимум полезной информации по этому вопросу: http://infostart.ru/public/164946/
30. Павел (Yimaida) 26.06.13 13:18
(29) Tsaregorodtsev, согласен. Нормальная рабочая дискуссия. Каких так не хватает на инфостарте :)
anchovy; TSSV; +2 Ответить
31. Павел Колмаков (Stim213) 26.06.13 13:50
(25) Aleksey.z, на перспективу - лучше использовать типовые проверенные средства, предназначенные разработчиками как раз для решения подобных задач.
Изобретение велосипедов оно конешн полезно - с точки зрения получения опыта, но не годится для повышения квалификации как специалиста. Знание типовых механизмов позволяет выполнять задачи с гораздо меньшими трудозатратами, и с не меньшей эффективностью.
32. Павел Колмаков (Stim213) 26.06.13 13:53
(28) Tsaregorodtsev, франч - это не только место работы, это еще и стиль подхода к решению задач. И от этого нужно избавляться по возможности.
Многие вещи в типовых конфигурациях можно сделать без топора и кувалды без программирования
33. Алексей Земсков (Aleksey.z) 26.06.13 14:07
(31) Stim213, Какой с вашей точки зрения должен быть типовой вариант проверенный проф. в ситуации как у автора?
Чем плох вариант с переносом справочников и дальнейшей обработкой "ПоискИЗаменаДублирующихсяЭлементов.epf", "ПоискИЗаменаЗначений.epf" хотя бы по ключевым элементам Организации, Валюты, различные классификаторы и т.д. Впрочем если вам предпочтительней поиметь геморрой с регистром СоответствиеОбъектовДляОбмена или промежуточным звеном которое конвертирует гуиды то дело ваше.
34. Tsaregorodtsev (TSSV) 26.06.13 14:10
(32) Stim213,
франч - это не только место работы, это еще и стиль подхода к решению задач.
ну это философский вопрос, Вам наверное просто не повезло.
35. Павел Колмаков (Stim213) 26.06.13 14:36
(33) Aleksey.z, если наиболее простое решение для вас геморрой и вы не ищете легких надежных путей - мне остается только посочувствовать вам и вашим клиентам.
36. Павел Колмаков (Stim213) 26.06.13 14:47
(34) Tsaregorodtsev, ок, давайте по конкретике.
Работу вы проделали немалую, сложную и, несомненно, интересную.
Возможно, вы даже знали про РС СоответствиеОбъектовДляОбмена и не стали его использовать по каким-то причинам.
Если не знали - ничего страшного. Если знали, но все равно не стали использовать - прошу вас назвать эти причины, чтобы наше обсуждение было более конструктивным.
37. Алексей Земсков (Aleksey.z) 26.06.13 14:48
(35) Stim213, Сопоставление по гуид самый простой, технологически надежный и легкий способ синхронизации данных, все остальное геморрой но для клиентов и в будущем поэтому прекрасно вас понимаю. Засим данную полемику считаю пустой тратой времени.
hulio; TSSV; +2 Ответить 1
38. Tsaregorodtsev (TSSV) 26.06.13 14:50
(35) Stim213, Вот что действительно вызывает сочувствие, так это Ваша манера излагать свои мысли. Ваша идея тем не менее понятна и это действительно геморрой.
39. Павел Колмаков (Stim213) 26.06.13 14:52
(37) Aleksey.z, как раз для клиентов возможность ручного редактирования настроек синхронизации в регистре была бы удобнее, чем постоянные обращения к программисту. Цель автоматизации - дать клиенту максимум настроек, чтобы он настраивал учет так, как ему надо. Если он захочет, чтобы номенклатура из БП загружалась в другую номенклатуру УПП, он просто изменит запись в регистре и ему не надо будет тратить ресурсы программиста.
40. Константин - (Kosstikk) 26.06.13 16:15
41. Александр Иванов (mjane) 26.06.13 16:43
было интересно почитать, я думаю ваш опыт пригодится
42. Макс _ (max996) 26.06.13 17:36
спасибо и за статью и за полемику в обсуждениях)
43. Денис Юрченко (biker1052) 26.06.13 17:55
Да с каждым днем способов обмена все больше, так что есть с чего выбирать.
44. г. Казань Рустем Гумеров (Rustig) 26.06.13 17:56
(31) Stim213,
Использовать специально предназначенный типовой РС СоответствиеОбъектовДляОбмена видимо религия велосипедиста не позволяет. Синхронизация делается в разы проще. Незачет вобщем.


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


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

Франч такой франч.
Откуда такая нелюбовь к франчам? Представьтесь, пож-та :)
И вообще франч - это форма организации бизнеса (по аналогии с ООО, ЗАО, ИП), а не признак качества, чтобы так судить о решении задачи.
45. г. Казань Рустем Гумеров (Rustig) 26.06.13 18:03
(39) Stim213,
как раз для клиентов возможность ручного редактирования настроек синхронизации в регистре была бы удобнее, чем постоянные обращения к программисту. Цель автоматизации - дать клиенту максимум настроек, чтобы он настраивал учет так, как ему надо.

Мой опыт показывает другое: максимум настроек "можно", если у них есть свой программист, который будет в этом копаться, иначе все равно сам будешь настраивать-перенастраивать.
hulio; anchovy; TSSV; +3 Ответить 1
46. Павел Колмаков (Stim213) 27.06.13 11:32
Конкретики от автора так и не дождался. Печально.
47. Павел Колмаков (Stim213) 27.06.13 11:41
(44) Rustig,
И вообще франч - это форма организации бизнеса (по аналогии с ООО, ЗАО, ИП), а не признак качества, чтобы так судить о решении задачи.

В подавляющем большинстве эта форма организации бизнеса заинтересована в получении максимальной прибыли от клиента. И если по поводу квалификации кадров можно спорить долго, то по поводу выполнения задач в большинстве случаев подход одинаков - сделать как можно больше, затратить как можно больше часов, содрать с клиента как можно больше денег. Если доработки чуть сложнее, чем поставить где-то галочку, то франч обязательно будет писать своего монстра, чем пытаться использовать штатные механизмы.
Это вобщем-то обычные рыночные взаимоотношения, но такой подход не годится на фикси.
48. Евгений Фамилия (internetname) 27.06.13 18:05
49. Кикос Одинэсенко (servs) 01.07.13 13:58
Насколько мне известно, 1С гарантирует уникльность GUIDов только внутри одной таблицы (8.1.15.41)
Однажды сливал две базы в одну и было такое, что один и тот же GUID был в одной базе в разных справочниках.
50. Tsaregorodtsev (TSSV) 01.07.13 15:01
(49) servs, да, Вы правы. В (18) об этом уже шла речь, то есть одинаковые GUIDы могут быть в одной базе но в разных таблицах и это норамальная ситуация. В принципе и в таком случае можно заменять GUIDы описанным способом, так как при обмене данными помимо GUIDа передается имя таблицы (объекта метаданных).
51. Павел Парамонов (anchovy) 02.07.13 13:26
(45) Rustig, Абсолютно верно. В том числе и то, что максимум настроек может пригодиться и тебе самому. Только вот назвать РС СоответствиеОбъектовДляОбмена пользовательской настройкой язык не поворачивается. Это скорее инструмент для программиста. Самому он мне правда пока не пригодился. Обычно только подчищаю его перед поиском и заменой значений объектов, которые участвуют в к.-л. плане обмена.
52. Sergey S (stagov) 04.07.13 19:29
лет 10 назад реализовали выгрузку из ТиС 77 в бух.77. В базе источнике ТиС - UID присваивался документам и справочникам, последний номер писали в соответствующую константу. Приемник бухгалтерия его просто получал при обмене. Работало супер.
53. Александр Крынецкий (echo77) 08.07.13 07:12
(11) Видел, как в боевой базе УПП выполнили перенумерацию справочника номенклатуры. Естественно после такого поиск по коду ничего не найдет.
54. Олег Сорокин (Oleg_nsk) 08.07.13 11:20
(53) echo77,Запретить изменять нумерацию пользователям гораздо проще, нежели впаривать клиенту несколько лишних часов работы для подобного рода фундаментальных научно-исследовательских работ.
55. Александр Крынецкий (echo77) 08.07.13 11:53
(54) Согласен, проще. Только когда момент упустили и уже насоздавали номенклатуры с "неправильными" номерами от перенумерации было не уйти
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа