#0
by vva
Есть 2 базы: Бух-я и Рарус.Альфа-Авто:Автосалон. Требуется выгружать проводки из Авто в Бух. В проводках присутствуют контрагенты. Проблема с тем как сопоставлять контрагентов. Так как наименование у них может заполняться по разному, в т.ч. с ошибками. Для юр.лиц использую реквизит "ИНН", а для физ.лиц как? ФИО могут заполнять с ошибками, паспортные данные не всегда возможно заполнить. Может какой-то уникальный реквизит добавить, только от чего он должен зависеть?
#1
by child
Пытаемся совместить несовместимое? да к тому же автоматом? чето мне подсказывает что без ВК "Опытный бухгалтер и пользователь" тутва не обойтись. Авот добавлять реквизит иль нет - вопрос чисто риторический.
#2
by selenat
Ну почему? Можно синхронизировать справочники. Если не удается воспользоваться существующим реквизитом (ИНН), можно добавить свой. Технически выполнимо, проблем нет.
#3
by child
Ну добавить он реквизит. а все равно, как его заполнить, если однознчного соответствия между базами нет? конечно часть, наверное, можно булет синхронизовать по ИНН, часть может и по наименованию прокатит, но не факт, что это будет полная синхронизация. так что все равно придется часть элементов (может быть даже большую часть) синхронизировать ручками.
#4
by smaharbA
child - прав, толко если не делать "жесткое" заведение справочников в одной базе и синхронизацию при перекачке(и/или регламентно)...
#5
by selenat
"часть элементов (может быть даже большую часть) синхронизировать ручками." Никто не спорит. Придется. Ну и что? Достаточно сделать это 1 раз, а потом указывать соответствия для вновь создаваемых элементов. При регулярных выгрузках это более оправдано, чем каждый раз проделывать это вручную.
#6
by Lendy
В твоем случае никак по-другому и не сделать. Я бы посоветовал занесение данных только в одну базу, а в другую чтобы попадали только при переносе.
#7
by selenat
Завести справочник соответствий контрагентов двух баз (соответствий ID или собственного уникального реквизита).Один раз его заполнить и пользоваться...
#8
by child
(+7) Завели новый, потом еще один и еще. а через полгода, эта таблица уже не актуальна...
#9
by child
Может лучше пересмотреть структуру ведения справочника? ну например назначить базу где заводятся новые и редактируются старые элементы. В остальных базах настроить обмен данными с центральной. Но даже в этом случае не избежать ручной синхронизации.
#10
by selenat
Если выгружается элемент, для кот нет соответствия в справочнике, можно предложить интерактивно ввести соответствующего контра, и пополнить справочник соответствий.
#11
by child
Тоже вариант, но не исключает ошибок пользователей. Причем порой нелепых. как то если в родительской базе один элемент будет в дочерней определен 2-мя реквизитами.
#12
by selenat
+10 Тогда в рабочем режиме мы постоянно обновляем справочник соответствий. Каждый раз это будет в худшем случае указание нескольких новых соответствий.
#14
by selenat
Не проблема. Дать возможность пользователю интерактивно переназначать соответствие любому выбранному контру. Тогда он будет исправлять ошибки по мере их обнаружения.
#15
by selenat
Можно предупреждать, что соответствие для этого элемента уже есть. Кроме того, можно сознательно устанавливать соответствия так, чтобы два контра одной базы выгружались в 1 контра в другой.
#16
by selenat
Я давно собираюсь написать такую обработку синхронизации контров и номенклатуры. Все руки не дойдут.
#22
by child
И что? Уникльные в пределах одной базы. А ведь задача изначально стоит в синхронизации справочников.
#26
by romix
В 8-ке в качестве кодов синхронизации задействованы GUID-ы; вероятность их совпадения (при нормальных сетевых картах на каждой машине) равна строго 0.
#27
by selenat
А зачем уникальность для разных баз. Для разных баз достаточно справочника их соответствий, а в пределах базы они вроде как уникальны?
#28
by romix
(24,25) Зато получение GUID-это ОДИН системный вызов WinAPI. И не надо лезть руками в таблицы (вот уж за что ты точно не получишь ни один сертификат).
#29
by child
Ну тады скажи нам не сведующим, каким образом твой уникальный ключ покажет, что элемент справочника в базе А = элементу в справочнике в базе Б?
#30
by у лю 427
В семерке для уникальности нет гуидов... Вероятность совпадения в одной базе равна нулю... P.S. уже много раз налетал на сетевухи с одинаковыми мас-адресами (по науке такого быть не должно)... Вот такой случай попадется ромиксу и будет он сушить весла...
#31
by у лю 427
ответ на этот вопрос есть выше... Если ты его не видишь - .... новая сосна не спасет дятла...
#33
by romix
В пакете обмена достаточно передавать мак-адрес, чтобы выявить эту ошибку. Но к сожалению не всем представителям пернатых это дано...
#34
by selenat
Похоже, они о чем-то своем... Я тоже не понимаю - зачем им уникальность для разных баз.
#35
by romix
В 8-ке применили синхронизацию основанную на GUID-ах. Лично я не вижу причин чтобы не делать так же. Все равно придется переходить на нормальные системы. Чтобы при выгрузке-загрузке контрагента, который есть в разных базах под немного разными наименованиями, он не задвоился.
#36
by у лю 427
Другие представители пернатых долбят гнилые деревья, ибо достаточно передавать не мак адрес, а идентификатор базы, в которой порожден элемент. И мак адрес и совпадение маков при этом по .... барабану... P.S. Также для некоторых других представителей дятлообразных хочется заметить, что мак адрес - вещь непостоянная и при смене сетевой платы изменится... Но БАЗА - ИСТОЧНИК НЕ ИЗМЕНИЛАСЬ то.... Ладно, долбите деревья дальше... Желательно гнилые - лес будет чище...
#38
by у лю 427
синхронизация по чистому гуиду не содержит информации о базе-владельце элемента... А это важно... Чтобы инфа из некоторых баз не попадала в ненужные...
#40
by romix
Достаточно проверять уникальность мак-адресов при выгрузке ПБ-ЦБ. Префикс ИБ (НомерДок, Код должен содержать префикс ИБ).
#41
by romix
Как думаешь, почему так не сделали в 8-ке? Может быть, решили, в отличие от некоторых, не долбить гнилые деревья?
#42
by selenat
Я не знаю 8ку. Насколько я понимаю, этот метод хорош для обмена между двумя конкретными базами, для него требуется справочник соответствий ID и инструмент интерактивной установки этих соответствий. Вряд ли это стали бы делать универсальным способом, встроенным в конфигурацию.
#43
by romix
Не нужен там никакой справочник соответствий. Элементу справочника в двух разных базах присвоен один и тот же GUID - это означает, что это один и тот же элемент.
#44
by у лю 427
Префикс ИБ и есть идентификатор базы ... Префиксы в номерах доков и кодов - это об базы-владельца не зависит... а зависит только от потребностей клиента... т.к. передается префикс БД - по сути, азработчики выполнили все, что сказано в ... Но некоторые дятлы этого не понимают... "Достаточно проверять уникальность мак-адресов при выгрузке ПБ-ЦБ." ты так не шути, а то я сдохну от смеха... чуть бутерброд с маслом не уронил на клаву...
#45
by у лю 427
не копал 8 так глубоко - а можно в 8 указать свой гуид при записи элемента справочника? Если можно - то будут одни проблемы, если нет - тогда нужен справочник соответствий... P.S. в 77 указать нельзя...
#46
by romix
(44-2) В смысле чтобы мак-адреса не повторялись в разных ИБ. А то что там карты могут менять - это по барабану, адреса по любому останутся разными.
#47
by selenat
Можно так. Я делал в 7ке поиск соответствующих доков двух баз, правда по введенному мной общему уникальному реквизиту (кот совпадает в двух базах), а не ID. Но это ведь не единственный вариант.
#49
by selenat
Знаю. Просто это был первый опыт в этом направлении. Не все было продумано. Сейчас я и это стал бы делать через справочник соответствий...
#51
by romix
И почему только в 8-ке не поюзали справочник соответствий? А в любой нормальной системе можно ли представить себе такой "справочник"?
#52
by selenat
(50-51) Че-то я не понял. Если ты ведешь справочники в двух базах (а не только выгружаешь из одной), как это ты умудришься сделать у них одинаковые GUID?
#53
by у лю 427
Если записать гуид реально - тогда можно отказаться от справочника соответствий. Это удобнее... Но вот ситуация, в которой в базах АА и ББ создано по элементу с одинаковым гуидом и затем отправлено через УРБД в базу СС... В этом случае будет интересная коллизия... Причем ошибку хрен просто так найдешь... P.S. вероятность такой коллизии не нулевая... Мк адреса тоже в принципе не должны повторяться (их производителям выдает спец комитет и делит их правильно)... А по факту - есть дубликаты... И очень интересная ситуация, когда налетаешь на два одинаковых мак адреса в одной сетке...
#54
by selenat
Если я правильно понял, гуид можно назначать только новому не записанному элементу справочника. Это возможно, только если элементы справочника могут создаваться только в одной базе, а в другую выгружаться. Но если нам надо вести справочники независимо в двух базах - ничего из этого не выйдет
#55
by rsv
Да поготь ты деньги разносить в бухии на конторв :) Да погодиже когда начисления из ОУ приедут с аналитикой . Ферштейн ?
#56
by romix
Коллизии мак-адресов в пределах одной Ethernet-сети невозможны (сеть начнет выдавать ошибки, что уже есть такой мак-адрес). Для разных сетей совпадение возможно (более того, его можно выставить вручную). Поэтому центральная ИБ при загрузке может проверять мак-адреса удаленных баз на несовпадение. А как она узнает, какие там мак-адреса? В пакете обмена их можно слать.
#57
by romix
Можно либо вручную сопоставлять (что долго), либо (что лучше всего) изначально заводить элементы не руками по телефону, а методом выгрузки-загрузки из базы-источника.
#58
by selenat
Как это сопоставлять вручную? Из я так понял, что если элемент создан и записан, то его гуид уже не изменишь. А если элементы создавать только при помощи выгрузки, то это накладывает серьезные ограничения на использование базы (в базе приемнике могут быть свои элементы, кот вообще не нужны в базе источнике, не говоря уже о практических трудностях при срочности использования элемента, кот еще не было возможности выгрузить из источника).
#59
by у лю 427
можно слать МАК... но ведь не шлют.... Тогда все твои рассуждения псу под хвост.... Эти ограничения - не проблемы. Они элементарно решаются...
#60
by selenat
ИМХО Это зависит от организации работы у клиента и его (клиента) возможностей организации работы так, чтоб можно было решить эти ограничения. При работе через соответствия таких проблем вообще не возникает.
#61
by romix
Вписываешь ручками нужный GUID, и все. Чтобы просто указать, что в разных базах - один и тот же объект. Даже при общих мак-адресах вероятность коллизий очень мала (1/2^80) или 0,0000000000000000000000000827181
#63
by selenat
А не получится, что при таком вписывании образуется не уникальный гуид в пределах одной базы?
#66
by selenat
И что? ПриЗаписи определили, что гуид не уникальный. Но нам нужен именно такой, чтобы элементы справочника были синхронизированы. Вообще ненадежный по-моему способ - вмешиваться в механизм автоформирования гуид. Слишком много ситуаций надо продумывать, чтобы у нас гуид был уникальный каждый в своей базе и чтобы он был одиаковый для соответствующих друг другу элементов справочников.
#67
by romix
Мы сейчас про 1С 7.7 говорим? Так там вообще нету гуидов. А есть внутренние (скрытые от пользователя) идентификаторы, состоящие из 2 частей. Их расшифровка описана, например, здесь: Вмешиваться в них никто не собирается. ГУИД, который выглядит, например, вот так: {71602BEA-1BEA-4FB8-B03F-6C2E3390C748} может служить дополнительным средством синхронизации, чтобы программа могла находить объекты, независимо от кода или наименования, номера или даты документа. Юзера любят назначать слегка разные названия, ошибаться с кодами, править номера и даты доков и т.п., и уникальность теряется. Гуид помогает найти тот же самый объект. А почему именно гуид, а не числовой идентификатор наподобие IDD в МОД - потому что его удобнее создавать, и можно не беспокоиться насчет того, а не сбойнет ли счетчик. Т.е. больший, так сказать, запас надежности.
#68
by romix
Вероятностный подход кажется стремным. Ну что же, для таких случаев ничто не мешает комбинировать подходы GUID и IDD. Тогда они просто усилят полезные качества друг друга.
#69
by selenat
Давай немного обстрагируемся. Пусть у нас есть некоторый внутренний код для идентификации объектов. Сейчас не важно - уникален он в пределах типа метаданных (как ИД в 7ке), или уникален в пределах всех объектов метаданных (как ГУИД). Предположим даже, что мы можем сами присваивать ему какие-то значения. Если мы хотим синхронизировать элементы справочника при помощи ОДИНАКОВЫХ внутренних кодов, то в одной из баз нам придется присваивать этот внутренний код самостоятельно (чтоб он был такой же как в другой базе). Тогда возникает опасность, что этот код будет не уникален (опять же не важно - в пределах типа метаданных или среди всех объектов базы). Такая ситуация недопустима и я не увидел ответа на вопрос - как ее обходить. Если же использовать справочник соответствия элементов, то такой проблемы нет вообще, причем все очень легко реализуется. В чем я не прав? Не понял - какой вероятностный подход?
#72
by romix
Я выношу GUID-ы в отдельный справочник. Он содержит колонку GUID (она же - наименование) и ссылку на объект. В этом справочнике легко находить объект по GUID-у. Если вдруг в выгрузке придет ссылка на совершенно другой объект (например, объект не того типа, с другим кодом, с другим наименованием и т.п.) то программа имеет возможность высветить этот косяк, и прекратить обмен. Т.е. имхо резко повышается устойчивость к любым сбоям и программным и "человеческим" ошибкам. Если использовать гуид как дополнение к любой другой технологии обмена, то с этим, я думаю, никто спорить не будет, а надежность обмена резко повысится.
#73
by child
Насколько я понял - GUID есть все-го лишь уникальный ключ доступа к элементам, а где его хранить (в самом элементе или в справочнике соответствий) особо разницы нет. Но все равно, для более корректной работы необходимо справочник центролизовать, т.е. определить базу владельца данного справочника, а по другим уже рассылать?
#74
by romix
В справочниках обычно достаточно префиксов ИБ (в кодах), чтобы было видно, где создали тот или иной элемент.
#75
by child
Это понятно. Но все же как GUID поможет решить проблему в 0? Все равно необходимо установить какую либо базу как истину, а в другой провести соответствие, что является новым элементом, а что исковерканным старым.
#76
by selenat
И как ты отслеживаешь, что объект СОВЕРШЕННО ДРУГОЙ? Может возникнуть ситуация, что тип объекта тот же, а объекты разные. Код и наименование не показатель, их может изменить пользователь. "программа имеет возможность высветить этот косяк, и прекратить обмен". Да. Может. И что дальше? Не обмениваться после такой ошибки? Пользователь не справится с этим. Да и программисту повозиться придется...
Тэги:
Ответить:
Комментарии доступны только авторизированным пользователям
Похожие вопросы 1С
- Получить id и получить объект по id
- Получение id объекта и обратное преобразование id в объект
- 1С + Caller ID (определитель номера телефона звонящего)
- 1С УПП свойства в справочнике "Договоры контрагентов"
- Задвоенные записи в справочнике контрагентов
- Связь контрагентов и договоров контрагентов в УТ 11
В этой группе 1С
- ЗиК форма Т-2
- ЗУП: расчет базы для удержания
- Сдаем исправление 2-НДФЛ, нумеровать справки с 1?
- Вопрос по программе Аспект 4.5
- Попытка...Исключение. Почему посредине кода вываливается в исключение?
- Не удается перезаписать файл ХМL
- формирование «Перемещение ТМЦ» автоматически при розничной продаже
- Как по табличной части получить ссылку на документ
- Лицензия на комплексную=лицензии на ЗИК + бухия?
- V7Plus.ПолучитьКакСтроку()
- Зачет аванса от покупателя в 1С:УСН 7.7 без налоговых проводок
- выход из процедуры
- Пропали операции введенные вручную!
- Проблема с МД, как скопировать все данные в другую базу?
- 1C 7.7 + Регламентированная отчетность за I квартал 2006 года
- настройка справочника номенклатуры
- Вывод на печать таблицы справа 8.0
- 1С: Предприниматель 7.7. Раздельное списание материалов и выпуск продукции.
- пособия по уходу до 1,5 года + районный коэффициент + НДФЛ
- Как получить тип значения оле объекта