Клиент обратился к нам с задачей — настроить одностороннюю синхронизацию между 1С:Управлением нашей фирмой 3.0 (УНФ 3.0) и 1С:Бухгалтерией предприятия 3.0 (БП 3.0).
Ранее настройку обмена между программами заказчик выполнил своими силами. Сам обмен работал корректно — выгрузка и загрузка справочников и документов происходила без ошибок. Но несмотря на «работающий» обмен, документы и справочники загружались в базу-приемник некорректно. То есть с точки зрения программы — все правильно. А вот с точки зрения человека — некорректно.
Результат в УНФ 3.0:
Рис. 1 (нажмите, чтобы увеличить)
Результат в БП 3.0:
Рис. 2 (нажмите, чтобы увеличить)
Видим, что ошибок нет. Все ушло и пришло корректно.
Реализация
В результате тестирования выяснилось, что из 1С:УНФ 3.0 выгружалась Расходная накладная, по которой осуществлялась отгрузка номенклатуры «Валенки черные размер 44», а в 1С:БП 3.0 та же самая накладная приходила с номенклатурой «Ведро цинковое 10 л».
Рис. 3 (нажмите, чтобы увеличить)
Первый вывод, который напрашивался в данной ситуации — некорректное сопоставление номенклатуры при настройке синхронизации.
На вопрос «Кто и как делал сопоставление номенклатуры?», клиент ответил, что не в курсе данной необходимости, ведь предполагалось, что при настройке синхронизации все просто и понятно — иди по инструкции и жми «Далее». И на первый взгляд все прошло хорошо — синхронизация работала.
Также мы выяснили, что в справочнике номенклатуры появляются дубли. То есть не только сами накладные некорректно заполняются номенклатурой, но еще и плодится аналогичная номенклатура в справочниках.
Рис. 4 (нажмите, чтобы увеличить)
При этом, со слов заказчика, бухгалтеры использовали стандартную типовую обработку «поиск и удаление дублей» и проблема с дублями решалась. Но на самом деле проблема с некорректным заполнением в документах оставалась и приходилось вручную сверять и корректировать каждый документ. В итоге смысл автоматической синхронизации терялся, т.к. такая работа отнимала много времени.
Мы решили развернуть копии баз и разбираться в ошибках синхронизации уже на копиях, чтобы выявить возможные подводные камни после такой самостоятельной настройки.
1. Первым делом в базах почистили дубли справочника номенклатуры по признакам одновременного совпадения по Наименованию, Коду и Артикулу.
Рис. 5 (нажмите, чтобы увеличить)
2. Затем заново настроили синхронизацию, а именно — заново выгрузили справочник «Номенклатура» для сопоставления:
Примечание: когда происходит настройка синхронизации, то базы, между которыми происходит настройка, не знают о существовании друг друга. Поэтому, прежде чем осуществлять обмен данными между ними, их необходимо «познакомить». Одним из этапов такого «знакомства» является сопоставление данных. Сопоставление данных — это настройка соответствий между объектами и их реквизитами в синхронизируемых информационных базах. Цель — сделать так, чтобы при обмене данными 1С могла корректно находить, создавать и обновлять «те же» объекты в другой базе. Поэтому очень важно подойти к этому этапу ответственно. Именно от корректности данного этапа будет зависеть, будут у вас «Валенки» приходить как «Валенки» или как «Ведра».
Рис. 6 (нажмите, чтобы увеличить)
Рис. 7 (нажмите, чтобы увеличить)
Если оставить так, то «Валенки» и «Ведра» загрузятся в 1С:Бухгалтерию как новая номенклатура и возникнут дубли.
Поэтому поищем и сопоставим номенклатуру в базе-приемнике:
Рис. 8 (нажмите, чтобы увеличить)
Так как у заказчика в справочнике номенклатуры было 40 000 наименований, то такая работа заняла продолжительное время. Соответственно, чем больше у вас наименований Номенклатуры, Контрагентов и пр., тем дольше будет производиться настройка обмена, что также влияет и на стоимость работ по такой настройке.
Примечание: конечно, есть помощник автоматического сопоставления, который возьмет на себя около 90% работы по сопоставлению. НО! Во-первых, необходимо будет сверить корректность такого сопоставления, а, во-вторых, оставшиеся 10% все равно необходимо будет сопоставить самостоятельно, т.е. из 40 000 самостоятельно примерно 4000.
При сверке сопоставления номенклатуры, помимо некорректного сопоставления, еще возникла еще одна проблема — некорректные GUID* номенклатуры в базе-приемнике.
Например, номенклатуру «Плащ бежевый XXL» программа автоматически сопоставляла с номенклатурой «Клавиатура черная».
Рис. 9 (нажмите, чтобы увеличить)
Примечание: при сопоставлении номенклатуры первоначально программа сравнивает ее по *GUID — Внутреннему Уникальному Идентификатору. Внутренний уникальный идентификатор (УИД, GUID/UUID) в 1С — это значение, которое платформа автоматически присваивает каждому ссылочному объекту (элементу справочника, документу, плану видов характеристик и т. д.) при его создании. Он неизменен на протяжении всего жизненного цикла объекта в рамках конкретной информационной базы и служит для однозначной идентификации и построения ссылок между объектами, а также для сопоставления при обмене/синхронизации.
У каждого вашего элемента справочника, документа и пр. есть свой уникальный «паспорт» (или свое «ДНК»): создали Номенклатуру = выдали ей свой паспорт, новый документ — получи свой паспорт. Выглядит он примерно вот так — 8e1f9db8-4be2-11ed-a101-2c4d5450919d. И когда база-приемник получает данные по номенклатуре «Плащ бежевый XXL», то проверяет его «паспорт».
Так как вероятность того, что где-нибудь в мире будут независимо сгенерированы два идентичных GUID («паспорта»), исчезающе мала (общее количество возможных ключей составляет 2 в 128 степени = 340 282 366 920 938 463 463 374 607 431 768 211 456), то найдя у себя по такому «паспорту» номенклатуру «Клавиатура черная», программа дальше не задает вопросов и автоматом считает это одной и той же номенклатурой.
Получается, что в базе-приемнике (БП 3.0) находится номенклатура под чужим «паспортом», а именно «Клавиатура черная» живет в базе под паспортом «Плаща бежевого XXL» ,т.е. у них одинаковый GUID (Уникальный идентификатор). В таком случае обычная процедура повторного сопоставления уже не поможет. Одной из причин такой ситуации как раз может быть некорректная работа с обработкой «Поиск и удаление дублей», которую использовала бухгалтерия заказчика.
3. Чтобы определить масштаб проблемы, была написана дополнительная обработка, которая помогла выявить такую «нелегальную» номенклатуру.
В итоге из 40 000 наименований было выявлено 450 таких позиций номенклатуры. Помимо выявления номенклатуры, сразу происходила ее обработка и присвоение ей нового уникального идентификатора в базе. Простым языком, выдали 450 «нелегалам» свои новые «паспорта», а старые ликвидировали.
4. Так как уникальные идентификаторы были откорректированы в базах, то исчезла проблема некорректного автоматического сопоставления номенклатуры по «паспорту», и если такие «паспорта» не находятся, то программа дальше пробует найти и сопоставить номенклатуру по Полному наименованию. А это все равно, что искать по Имени Отчеству человека по всему миру, и надеяться, что никого не найдем. Вероятность совпадения куда выше, чем при поиске по «паспорту». Напомним, что в базе 40 000 наименований номенклатуры.
Ситуация усугублялась тем, что в базе действительно была номенклатура с одинаковым полным наименованием и она при этом не являлась дублем. Две «одинаковые», но неодинаковые номенклатуры в одной базе:
Рис.10 (нажмите, чтобы увеличить)
То есть, даже когда программа не сопоставляла номенклатуру по «паспорту», то она легко могла автоматически сопоставить ее по Полному наименованию. При этом, далеко не всегда это была именно нужная номенклатура.
Единственное, на что можно было опираться в таком случае, это на КОД номенклатуры и на ее Артикул — со слов заказчика, они сами заполняют артикул и контролируют его уникальность, а уникальность КОДа контролируется самой 1С. Но так как человеческий фактор никто не отменял, то для большей надежности рекомендуем опираться именно на одновременное их сочетание — КОД+Артикул.
Таким образом, мы доработали правила универсального обмена данных, при которых автоматическое сопоставление происходит по принципу:
1) Сперва ищется номенклатура по Уникальному идентификатору.
Если не нашлась, то:
2) По одновременному сочетанию КОД+АРТИКУЛ+НАИМЕНОВАНИЕ номенклатуры.
Если не нашлась, то:
3) Значит это новая номенклатура = переноси как есть, сопоставлять не с чем.
Результат
1. Избавились от некорректных данных по номенклатуре в обеих базах;
2. Программы сразу же на 100% корректно автоматически сопоставились между собой по всей номенклатуре из 40 000 наименований;
3. Дубли номенклатуры в базе-приемнике больше не создаются;
4. В документах базы-приемника встает корректная номенклатура.
Что сделано
