По моему опыту при любом внедрении информационной системы так или иначе возникает проблема обменов и конфигурация ERP не исключение.
В зависимости от того, с чем приходится интегрироваться и какова компетенция разработчиков на проекте, чаще всего используются обмены в формате EnterpriseData (КД 3) или Конвертации данных 2. И если Вы не планируете регулярное обновление конфигурации, то это отличные и, главное, понятные решения. Доработали, отладили и забыли.
Но что делать, если планируется регулярное обновление ERP и сдача регламентированной отчетности внутри этой базы? Если Вам необходимо получать большую часть документов по движению ТМЦ, банковских и других из других конфигураций на базе 1С, таких как УПП, ТОИР, ЗУП, Розница?
В таких условиях задача существенно усложняется, так как дорабатывать и тестировать механизмы обмена становится регулярной и крайне ресурсоемкой задачей, потому что:
- при нахождении ошибки в отражении документа в бух. учете на стороне ERP нужно понять - это ошибка обмена, ввода данных или типового релиза. Разбор подобных ошибок занимает длительное время.
- При подготовке обновления каждый релиз необходимо тестировать на корректность обменов, закрытия месяца и правильного формирования бухгалтерской отчетности на выходе.
- На этапе тестирования обмена, например в формате EnterpriseData, необходимо каждый раз для всех возможных вариантов заполнения документов/справочников проверять, что реквизиты перегруженного документа заполнены точно так же, как если бы мы вводили его вручную, чтобы максимально исключить возможно появление ошибок из-за программного ввода.
В результате подготовка и тестирование релиза ERP перед установкой занимает колоссальное количество времени.
А если отказаться от программного ввода документов при обмене и уйти на интерактивный с помощью Vanessa Automation? В этом случае при поиске ошибок мы исключаем ошибки программного ввода, нам уже не нужно сравнивать реквизитный состав объектов – объекты введены интерактивно. Т. о. мы исключаем примерно половину трудозатрат на подготовку релиза.
Минусы такой схемы очевидны – скорость обмена значительно ниже привычных обменов, но если количество передаваемых объектов не велико и не важна высокая степень оперативности, то почему бы и нет.
И первый вопрос который встает при организации подобного обмена – как решить проблему синхронизации объектов? При программном обмене предпочтительна синхронизация по внутреннему идентификатору объекта, при интерактивном вводе это так же возможно. Для этого можно завести общий реквизит, куда передавать внутренний идентификатор объекта, и перед записью нового справочника или документа подменять ссылку.
Концептуальная техническая реализация подобного обмена может быть довольно проста.
На стороне базы – отправителя нужно:
- Создать план обмена для регистрации изменений
- Создать общий метод или справочник, где хранить процедуры генерации feature – файлов. Можно для каждого объекта метаданных создать свою процедуру и тогда выгрузка упростится.
- Если необходимы дополнительные отборы выгрузки объектов, то реализовать это также можно различными способами, например, для каждого узла и объекта метаданных прописать условие, которое будет выполняться перед записью объекта.
- В качестве транспорта сообщений можно использовать web-сервис. Если для каждого узла прописать его адрес публикации соответствующей базы, то это позволит выгружать сообщения обмена корректно.
На стороне базы – приемника нужно:
- Обеспечить место хранения пришедших сообщений и их статусов (если необходимо)
- Написать обработку, которая бы в бесконечном цикле читала сообщения обмена и отправляла их на исполнение в Vanessa Automation
- Создать регламентное задание, которое бы просматривало обработанные сообщения обмена и либо снимало бы их с регистрации в базе-источнике, либо регистрировало их повторно на обмен в случае необходимости. Это также можно производить посредством Web-сервиса.
Способы ускорения подобного обмена:
- Иметь больше сеансов, в которых запущена Vanessa, и при получении сообщения от базы источника передавать его на исполнение тому сеансу, который менее всего загружен.
- Работа с формами в клиенте тестирования. Так как нам необходимо обеспечить синхронизацию данных по внутреннему идентификатору, то 1-ый очевидный вариант настроить формы списков так, чтобы был виден внутренний идентификатор и по нему можно было бы осуществлять поиск, но это довольно муторная задача. Можно пойти по пути установки «программного» отбора в динамических списках или установки параметров выбора реквизитов. В данном случае мы немного отступим от интерактивности ввода, но тут главное, чтобы после выбора значения все обработчики формы отработали, заполнив различные служебные реквизиты.
И в заключении: да - это работает.
