Есть 2 базы: Бух-я и Рарус.Альфа-Авто:Автосалон. Требуется выгружать проводки из Авто в Бух. В проводках присутствуют контрагенты. Проблема с тем как сопоставлять контрагентов. Так как наименование у них может заполняться по разному, в т.ч. с ошибками. Для юр.лиц использую реквизит "ИНН", а для физ.лиц как?

ФИО могут заполнять с ошибками, паспортные данные не всегда возможно заполнить. Может какой-то уникальный реквизит добавить, только от чего он должен зависеть?

(0) Пытаемся совместить несовместимое? да к тому же автоматом? чето мне подсказывает что без ВК "Опытный бухгалтер и пользователь" тутва не обойтись. Авот добавлять реквизит иль нет - вопрос чисто риторический.

(1) Ну почему? Можно синхронизировать справочники. Если не удается воспользоваться существующим реквизитом (ИНН), можно добавить свой. Технически выполнимо, проблем нет.

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

child - прав, толко если не делать "жесткое" заведение справочников в одной базе и синхронизацию при перекачке(и/или регламентно)...

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

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

Завести справочник соответствий контрагентов двух баз (соответствий ID или собственного уникального реквизита).Один раз его заполнить и пользоваться...

(+7) Завели новый, потом еще один и еще. а через полгода, эта таблица уже не актуальна...

Может лучше пересмотреть структуру ведения справочника? ну например назначить базу где заводятся новые и редактируются старые элементы. В остальных базах настроить обмен данными с центральной.
Но даже в этом случае не избежать ручной синхронизации.

(8) Если выгружается элемент, для кот нет соответствия в справочнике, можно предложить интерактивно ввести соответствующего контра, и пополнить справочник соответствий.

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

+10 Тогда в рабочем режиме мы постоянно обновляем справочник соответствий. Каждый раз это будет в худшем случае указание нескольких новых соответствий.

(+11) читать не "2-мя реквизитами" а "2-мя элементами"

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

(13) Можно предупреждать, что соответствие для этого элемента уже есть. Кроме того, можно сознательно устанавливать соответствия так, чтобы два контра одной базы выгружались в 1 контра в другой.

Я давно собираюсь написать такую обработку синхронизации контров и номенклатуры. Все руки не дойдут.

Получение GUID в 1С

(17) А как это к разным базам прикрутить?

(17) ты лучше у меня во дрове ветры попускал - высохли бы лужи...

(19) Ну вот. Пришел поручик и все изгадил. :))

в 7-ке уже есть уникальные ИД во всех справочниках... и документах...

(21) И что? Уникльные в пределах одной базы. А ведь задача изначально стоит в синхронизации справочников.

(21) Они не уникальные для разных баз, если не применяется УРБД.

Сделать их уникальными не просто, а очень просто....

Но это дятлы не поймут....

Уникальными для разных баз...

В 8-ке в качестве кодов синхронизации задействованы GUID-ы; вероятность их совпадения (при нормальных сетевых картах на каждой машине) равна строго 0.

А зачем уникальность для разных баз. Для разных баз достаточно справочника их соответствий, а в пределах базы они вроде как уникальны?

(24,25) Зато получение GUID-это ОДИН системный вызов WinAPI. И не надо лезть руками в таблицы (вот уж за что ты точно не получишь ни один сертификат).

(25) Ну тады скажи нам не сведующим, каким образом твой уникальный ключ покажет, что элемент справочника в базе А = элементу в справочнике в базе Б?

В семерке для уникальности нет гуидов...
Вероятность совпадения в одной базе равна нулю...

P.S. уже много раз налетал на сетевухи с одинаковыми мас-адресами (по науке такого быть не должно)...

Вот такой случай попадется ромиксу и будет он сушить весла...

(29) ответ на этот вопрос есть выше... Если ты его не видишь - .... новая сосна не спасет дятла...

кстати, синхронизация на этом принципе у меня работает уже лет пять...

(30) В пакете обмена достаточно передавать мак-адрес, чтобы выявить эту ошибку.
Но к сожалению не всем представителям пернатых это дано...

(29) Похоже, они о чем-то своем... Я тоже не понимаю - зачем им уникальность для разных баз.

(32) В 8-ке применили синхронизацию основанную на GUID-ах. Лично я не вижу причин чтобы не делать так же. Все равно придется переходить на нормальные системы.
(34) Чтобы при выгрузке-загрузке контрагента, который есть в разных базах под немного разными наименованиями, он не задвоился.

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

P.S. Также для некоторых других представителей дятлообразных хочется заметить, что мак адрес - вещь непостоянная и при смене сетевой платы изменится...
Но БАЗА - ИСТОЧНИК НЕ ИЗМЕНИЛАСЬ то....

Ладно, долбите деревья дальше... Желательно гнилые - лес будет чище...

(35) Я же говорю, использовать справочник соответствий ID, которые в каждой базе свои.

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

(37) он не поймет... Его идея - если нужно 3 льва, то ловим 10 и потом 7 выгоняем...

(36) Достаточно проверять уникальность мак-адресов при выгрузке ПБ-ЦБ.
(38) Префикс ИБ (НомерДок, Код должен содержать префикс ИБ).

(37) Как думаешь, почему так не сделали в 8-ке? Может быть, решили, в отличие от некоторых, не долбить гнилые деревья?

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

(42) Не нужен там никакой справочник соответствий. Элементу справочника в двух разных базах присвоен один и тот же GUID - это означает, что это один и тот же элемент.

Префикс ИБ и есть идентификатор базы ... Префиксы в номерах доков и кодов - это об базы-владельца не зависит... а зависит только от потребностей клиента...

т.к. передается префикс БД - по сути, азработчики выполнили все, что сказано в (36)... Но некоторые дятлы этого не понимают...


(40) "Достаточно проверять уникальность мак-адресов при выгрузке ПБ-ЦБ."
ты так не шути, а то я сдохну от смеха... чуть бутерброд с маслом не уронил на клаву...

не копал 8 так глубоко - а можно в 8 указать свой гуид при записи элемента справочника? Если можно - то будут одни проблемы, если нет - тогда нужен справочник соответствий...


P.S. в 77 указать нельзя...

(44-2) В смысле чтобы мак-адреса не повторялись в разных ИБ. А то что там карты могут менять - это по барабану, адреса по любому останутся разными.

(43) Можно так. Я делал в 7ке поиск соответствующих доков двух баз, правда по введенному мной общему уникальному реквизиту (кот совпадает в двух базах), а не ID. Но это ведь не единственный вариант.

(47) через таблицу соответствий такое делается элементарно...

(48) Знаю. Просто это был первый опыт в этом направлении. Не все было продумано. Сейчас я и это стал бы делать через справочник соответствий...

(45) v8: v8: реально ли УСТАНОВИТЬ ГУИД для элемента справочника 1С 8.0 ?

И почему только в 8-ке не поюзали справочник соответствий?
А в любой нормальной системе можно ли представить себе такой "справочник"?

(50-51) Че-то я не понял. Если ты ведешь справочники в двух базах (а не только выгружаешь из одной), как это ты умудришься сделать у них одинаковые GUID?

(50) Если записать гуид реально - тогда можно отказаться от справочника соответствий. Это удобнее...

Но вот ситуация, в которой в базах АА и ББ создано по элементу с одинаковым гуидом и затем отправлено через УРБД в базу СС...

В этом случае будет интересная коллизия... Причем ошибку хрен просто так найдешь...

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

(53) Если я правильно понял, гуид можно назначать только новому не записанному элементу справочника. Это возможно, только если элементы справочника могут создаваться только в одной базе, а в другую выгружаться. Но если нам надо вести справочники независимо в двух базах - ничего из этого не выйдет

(0) Да поготь ты деньги разносить в бухии на конторв :) Да погодиже когда начисления из ОУ приедут с аналитикой . Ферштейн ?

(53) Коллизии мак-адресов в пределах одной Ethernet-сети невозможны (сеть начнет выдавать ошибки, что уже есть такой мак-адрес).

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

(52) Можно либо вручную сопоставлять (что долго), либо (что лучше всего) изначально заводить элементы не руками по телефону, а методом выгрузки-загрузки из базы-источника.

(57) Как это сопоставлять вручную? Из (50) я так понял, что если элемент создан и записан, то его гуид уже не изменишь. А если элементы создавать только при помощи выгрузки, то это накладывает серьезные ограничения на использование базы (в базе приемнике могут быть свои элементы, кот вообще не нужны в базе источнике, не говоря уже о практических трудностях при срочности использования элемента, кот еще не было возможности выгрузить из источника).

(56) можно слать МАК... но ведь не шлют.... Тогда все твои рассуждения псу под хвост....

(58) Эти ограничения - не проблемы. Они элементарно решаются...

(59) ИМХО Это зависит от организации работы у клиента и его (клиента) возможностей организации работы так, чтоб можно было решить эти ограничения. При работе через соответствия таких проблем вообще не возникает.

(58) Вписываешь ручками нужный GUID, и все. Чтобы просто указать, что в разных базах - один и тот же объект.

(59) Даже при общих мак-адресах вероятность коллизий очень мала (1/2^80) или 0,0000000000000000000000000827181

(+61) Хотя конечно нормальная сетевуха сводит это вероятность вообще до 0.

(61) А не получится, что при таком вписывании образуется не уникальный гуид в пределах одной базы?

А если в станции (сервере) 2 сетевухи ?????????????

(63) Контроль в ПриЗаписи() надо поставить, чтобы GUID был уникальный.
(64) Первую наверное берет.

(65) И что? ПриЗаписи определили, что гуид не уникальный. Но нам нужен именно такой, чтобы элементы справочника были синхронизированы. Вообще ненадежный по-моему способ - вмешиваться в механизм автоформирования гуид. Слишком много ситуаций надо продумывать, чтобы у нас гуид был уникальный каждый в своей базе и чтобы он был одиаковый для соответствующих друг другу элементов справочников.

(66) Мы сейчас про 1С 7.7 говорим? Так там вообще нету гуидов. А есть внутренние (скрытые от пользователя) идентификаторы, состоящие из 2 частей. Их расшифровка описана, например, здесь:

Нетипичное использование компоненты УРБД в системе 1С:Предприятие 7.7

Вмешиваться в них никто не собирается.

ГУИД, который выглядит, например, вот так:
{71602BEA-1BEA-4FB8-B03F-6C2E3390C748}
может служить дополнительным средством синхронизации, чтобы программа могла находить объекты, независимо от кода или наименования, номера или даты документа. Юзера любят назначать слегка разные названия, ошибаться с кодами, править номера и даты доков и т.п., и уникальность теряется. Гуид помогает найти тот же самый объект. А почему именно гуид, а не числовой идентификатор наподобие IDD в МОД - потому что его удобнее создавать, и можно не беспокоиться насчет того, а не сбойнет ли счетчик. Т.е. больший, так сказать, запас надежности.

Вероятностный подход кажется стремным. Ну что же, для таких случаев ничто не мешает комбинировать подходы GUID и IDD. Тогда они просто усилят полезные качества друг друга.

(67) Давай немного обстрагируемся. Пусть у нас есть некоторый внутренний код для идентификации объектов. Сейчас не важно - уникален он в пределах типа метаданных (как ИД в 7ке), или уникален в пределах всех объектов метаданных (как ГУИД). Предположим даже, что мы можем сами присваивать ему какие-то значения. Если мы хотим синхронизировать элементы справочника при помощи ОДИНАКОВЫХ внутренних кодов, то в одной из баз нам придется присваивать этот внутренний код самостоятельно (чтоб он был такой же как в другой базе). Тогда возникает опасность, что этот код будет не уникален (опять же не важно - в пределах типа метаданных или среди всех объектов базы). Такая ситуация недопустима и я не увидел ответа на вопрос - как ее обходить. Если же использовать справочник соответствия элементов, то такой проблемы нет вообще, причем все очень легко реализуется. В чем я не прав?
(68) Не понял - какой вероятностный подход?

ночь была тяжелой?

(70) Спал как убитый. Ты это кому?

(69) Я выношу GUID-ы в отдельный справочник. Он содержит колонку GUID (она же - наименование) и ссылку на объект. В этом справочнике легко находить объект по GUID-у. Если вдруг в выгрузке придет ссылка на совершенно другой объект (например, объект не того типа, с другим кодом, с другим наименованием и т.п.) то программа имеет возможность высветить этот косяк, и прекратить обмен. Т.е. имхо резко повышается устойчивость к любым сбоям и программным и "человеческим" ошибкам. Если использовать гуид как дополнение к любой другой технологии обмена, то с этим, я думаю, никто спорить не будет, а надежность обмена резко повысится.

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

(73) В справочниках обычно достаточно префиксов ИБ (в кодах), чтобы было видно, где создали тот или иной элемент.

(74) Это понятно. Но все же как GUID поможет решить проблему в 0? Все равно необходимо установить какую либо базу как истину, а в другой провести соответствие, что является новым элементом, а что исковерканным старым.

(72) И как ты отслеживаешь, что объект СОВЕРШЕННО ДРУГОЙ? Может возникнуть ситуация, что тип объекта тот же, а объекты разные. Код и наименование не показатель, их может изменить пользователь.
"программа имеет возможность высветить этот косяк, и прекратить обмен". Да. Может.  И что дальше? Не обмениваться после такой ошибки? Пользователь не справится с этим. Да и программисту повозиться придется...

Ну вот. Дошли руки. :)