Единая нормативно-справочная информация (НСИ)
Правильную интеграцию двух систем невозможно построить без использования единой НСИ. Сопоставление и синхронизацию справочников НСИ необходимо делать на ранней стадии проекта, так как это снизит количество ошибок на всех этапах.
На нашем проекте мы напрямую столкнулись с расхождениями в справочниках. Во-первых, во внешней системе не существовало справочника «Договоры» как такового. Во-вторых, на первых этапах эксплуатации обмена, справочник «Договоры» в двух системах существенно различался. Документы, созданные в 1С ERP посредством обмена, часто были с пустым полем «Договор», так как во внешней системе этот договор уже завели, а в 1С ERP – нет. Большое значение здесь имеет человеческий фактор, так как справочники дискретно дополняются вручную в двух системах и велика вероятность, что в одной системе уже будет заведен элемент справочника, а во второй нет. Стоить добавить, что при синхронизации справочников лучше не использовать сопоставление по наименованию, потому что в таком случае есть большая вероятность не состыковки данных. Лучше синхронизировать данные, например, по коду или номеру элемента в справочнике.
Идеальный выход в данной ситуации – это продумать метод автоматической синхронизации справочников в обоих системах. Например, при создании элемента справочника во внешней системе пересылать эти данные сразу в 1С ERP, где создастся аналогичный элемент. Это позволит решить проблему различных данных, формируемых в информационных системах и уменьшит влияние человеческого фактора.
Примеры описания объектов, используемых при интеграции:
|
1С ERP |
Внешняя система производственного учета (первичная система) |
Поля сопоставления |
Способ создания |
Ответственный |
|
Договоры с контрагентами |
Contacts |
Поиск по коду договора |
Элемент справочника приходит из документооборота |
Менеджер документооборота |
|
Контрагенты |
Vendor |
Определяется как владелец договора |
Элемент справочника приходит из документооборота |
Администратор системы |
Сверка данных
Интеграция между двумя системами предполагает необходимость сверки данных, отраженных в каждой из этих систем. Отчетные данные правильнее всего получать напрямую, обращаясь непосредственно к внешней системе. Обычно, для анализа используется отдельный отчет, который собирает данные из двух систем, но в нашем случае, из-за негибкости системы, запросить данные напрямую невозможно. В такой ситуации приходится всю сверку данных проводить в 1С ERP на основе данных, которые сторонняя система может предоставить. Это порождает дополнительный риск потери данных при передаче через промежуточную систему или при выгрузке данных вручную.
Сверочный отчет дает возможность сравнить две системы, показывает различия и корректность переданных данных. Для сверки недостаточно просто фиксировать сумму в отчете. Отчет должен предоставлять данные об ошибках обмена в информативном и понятном виде для всех пользователей системы, а не только для администраторов. Нужен инструмент, который покажет, что и почему не загрузилось в систему, как это исправить.
На нашем проекте был разработан отчет, показывающий в левой части данные из внешней системы, а в правой – созданные документы в 1С ERP. В поле «Комментарий» записывается информация, почему документ не сопоставился с левой частью или вовсе не загрузился.
Интерпретация данных
На этапе проектирования необходимо получить от заказчика все ситуации интерпретации данных и в каком формате эти данные могут приходить в 1С ERP. Только после этого следует выбирать наиболее подходящую методологию разработки.
Большое количество правил интерпретации данных ведет к тому, что пользователям и администраторам системы будет сложно ориентироваться в работе обмена. Например, на нашем проекте был реализован механизм группировок строк для документа «Реализации товаров и услуг» Правило выглядело следующим образом: если выбрана группировка строк (стоят галочки группировки в табличной части), то выводится в печатную форму «Акта выполненных работ» поле «Наименование для печати», в остальных случаях выводится поля «Содержание». Кроме этого, поле «Наименование для печати» заполнялось по пяти разным правилам, в зависимости от того, какой тип реализации загрузился из внешней системы. Пользователи постоянно задавали вопросы, почему в печатную форму попадает то или иное значение.
Необходимо стремиться закладывать наиболее универсальные правила обмена, которые будут распространены на все объекты интеграции. Документация разработки, при такой схеме интерпретации данных, будет более понятная и простая. Любой пользователь, в короткие сроки, может быстро войти в курс дела.
«Потом у нас будет так… наверное»
Нечеткое изложение требований от заказчика порождает нечеткий результат разработки. Разработка под гипотетические требования приводит к тому, что систему раз за разом приходится переделывать, адаптируя под новые правила. Чтобы избежать этой проблемы, разработку нужно вести уже по фактическим, согласованным и четким требованиям от заказчика.
Например, на нашем проекте пришлось два раза менять тип документа для отражения объекта из внешней системы, потому что заказчик менял решение о том, какая проводка должна быть в документе. Из-за этого большое количество документов загрузилось с неверными счетами учета и этот массив исправлялся руками.
«А кто это должен делать»
Каждый процесс на проекте требует владельца, который отвечает за предоставление данных, проверяет, помогает в проектировании и моделировании. Отсутствие владельца процесса ведет к постоянной нехватке данных и трате дополнительного времени при проектировании. Бонусом идет большой объем ошибок, неточностей и повторной разработки.
Помимо владельца процесса на проекте должны быть специалисты ответственные за ведение справочников. Грамотное ведение справочников избавит от головной боли в виде нехватки данных.
Например, в нашей ситуации долгое время не было ответственного за ведение справочника «Договоры». Это тормозило проведение целых цепочек документов. Как только владелец процесса появился и справочник привели в порядок, документы стали оперативно проводиться без вмешательства администраторов системы.
Масштабируемость системы
Негибкость и недорабатываемость внешней системы заставляет адаптировать большую часть интеграции на стороне 1С ERP, на что уходит гораздо больше времени и ресурсов. При проектировании необходимо обсуждать с ИТ-службой заказчика возможность добавления данных через промежуточные систему, если напрямую это сделать невозможно.
На нашем проекте, в 1С ERP для корректной цепочки приходных документов был необходим «Заказ поставщику». Из внешней системы выгружался объект, создающий в 1С ERP «Заказ поставщику», но в получаемом xml-файле не содержалась информация о процентной ставке НДС и добавить ее не было возможности. Мы реализовали заполнение ставки НДС значениями по умолчанию: для контрагентов-резидентов – Без НДС, для контрагентов-нерезидентов – 20%. Но такое правило заполнения верно не во всех случаях и часть «Заказов поставщику» создалось на стороне 1С ERP с неправильной ставкой НДС и суммой, соответственно. Документы пришлось исправлять вручную. Проблему удалось решить путем добавления информации о ставке НДС в промежуточную систему при выгрузке xml-файлов в 1С ERP. Данные стали приходить корректные.
Во внешней системе зачастую может не быть данных и аналитики для ведения финансово-экономической деятельности, ввиду специфики и негибкости системы. А для получения отчетов и финансовых результатов в 1С ERP необходимо заполнение определенной аналитики. На интерпретацию аналитики уходит дополнительное время и не всегда удается адаптировать показатели из внешней системы, что может исказить результат финансового результата на стороне 1С ERP, поэтому следует заранее продумать способ получение обязательных показателей.
Если нельзя получать аналитику напрямую, то необходимо добавить ее в промежуточную систему или проставлять по умолчанию по сочетанию определенных реквизитов.
Например, во внешней производственной системе в документах производства поле «Подразделение» было необязательно для заполнения, а в 1С ERP аналогичный документ «Заказ на производство» требует заполнение этого поля при проведении. Сложилась такая ситуация, что большое количество производственных документов на стороне 1С ERP при интеграции загрузились с пустой аналитикой «Подразделение» и не проводились автоматически. Проблема решилась на стороне системы клиента добавлением контроля заполнения этой аналитики в обязательном порядке, документы перестали иметь возможность выгружаться без заполненного поля «Подразделение».
Транспорт данных
Ввиду того, что база-источник внешней системы данных негибкая и может выгружать данные только в формате xml, было принято решение на стороне 1С ERP использовать типовую конфигурацию транспорта данных «Конвертация данных 2.1». Конфигурация позволила реализовать универсальную модель преобразования различных тэгов и правил из xml-файлов в готовые документы в 1С ERP.
Наиболее удобный вариант построения обмена между системами – это витрина данных. Витрина данных представляет собой общую структуру данных, описывающих бизнес-процессы. При таком варианте обмена база-приемник только забирает информацию из витрины, преобразование данных не происходит, что сильно упрощает интеграцию. На нашем проекте не было возможности использовать технологию витрины данных по причинам, описанным в пункте «Масштабируемость системы». Помимо этого, файлы должны были проходить через несколько внутренних систем, что осложняло использование витрины. Если бы условия позволяли использовать витрину, то это бы избавило от большей части проблем интеграции.
