INFOSTART EVENT 2018 EDUCATION

Второй тур голосования за доклады.
Окончание 5 сентября.

Бобрышов Александр | Ведущий программист | ООО "Проф ИТ"

«Как организовать консолидацию данных из трёх десятков предприятий не привлекая программистов на местах?»

Давайте представим, что у нас есть "зоопарк" из разных конфигураций 1С, от разных организаций одного холдинга, занимающихся совершенно непохожей деятельностью (от промышленного производства до туристической деятельности). Бухгалтерские данные должны стекаться из этих предприятий в управляющую компанию, учет в которой ведется в системе, принципиально отличающейся от 1С. Некоторые дочерние организации работают на решениях без штатных программистов и находятся за 1000+ км. Я расскажу, какую архитектуру и технологии выбрать для такого обмена. Как наладить выгрузку данных по одной кнопке без изменения конфигурации предприятия. Как создавать и модифицировать правила обмена для разных предприятий из офиса управляющей компании. Как следить за состоянием обмена из единого центра управления.

Штрихкодирование документов бухгалтерии - обмен данными "Бухгалтерия предприятия" - "Документооборот"

Оборудование - Сканер штрих-кода

7
В процессе автоматизации документооборота организации возникла задача хранить сканы бумажных документов (первичных) в базе 1С Документооборот КОРП. Статья рассказывает о варианте решения.

Основная идея заключается в следующем: при печати документа в бухгалтерской базе (счет-фактура выданный, акт сверки взаиморасчетов, накладная, акт об оказании услуг и т.д.) в шапку печатной формы выводить штрихкод, по которому данный документ будет однозначно идентифицирован в базе документооборота. Файл скана (картинка JPG или PDF) прикрепляется к элементу справочника "Внутренние документы", штрихкод которого совпадает со штрихкодом печатной формы. Учитывая, что бухгалтерская база на поддержке, да к тому же еще и не одна - реализовано без доработки конфигурации бухгалтерии. В конфигурации документооборота изменения внесены, но они не столь значительны (тем более эта конфигурация к обновлениям не столь критична).

 

Реализовано это следующим образом:

  • В 1С "Бухгалтерии" (применительно к конфигурации 3.0) был создан узел плана обмена "Полный", благодаря чему появляется возможность отслеживать изменения документов.
  • В ПВХ "Дополнительные свойства" был добавлен реквизит "Штрихкод", тип строка, длина - 13 (стандарт EAN-13).

Очевидно, что необходимо синхронизировать штрихкоды в Бухгалтерии и в Документообороте. Было принято решение действовать по следующей схеме: документы из Бухгалтерии выгружаются в Документооборот. Там создаются "карточки" (элементы справочника "Внутренние документы"). Доработки конфигурации Документооборот:

  • Была добавлена новая подписка на событие "Перед записью", с помощью которой в регистре сведений "Штрихкоды" появляется необходимая запись (элемент-владелец + штрихкод).
  • После выгрузки из Бухгалтерии узел плана обмена "Полный" принудительно очищается (в целях препятствия росту объема базы).
  • Был создан новый план обмена "ШтрихкодыКВыгрузке", в состав которого включен регистр сведений "Штрихкоды". Авторегистрация отключена. План имеет реквизит "Организация".
  • Вторая подписка на событие регистрировала в узле плана "ШтрихкодыКВыгрузке" новый штрихкод.
  • Также в конфигурацию встроена простая обработка для чтения изменений указанного плана и очистки регистрации.

Обработка выгрузки документов из бухгалтерии после завершения непосредственно выгрузки подключалась к базе документооборота, запускала обработку считывания новых штрихкодов, получала их в виде таблицы значений и полученные штрихкоды прикрепляла в виде дополнительного реквизита к соответствующему документу.

Синхронизация документа в бухгалтерии и его карточки в документообороте реализована следующим образом. Учитывая, что пространство обмена включает в себя несколько бухгалтерских баз - карточки в документообороте формируются со своим, уникальным ГУИДом с помощью получения новой ссылки. Хотя 1С и утверждает, что ГУИД объекта уникален в пределах вида объекта метаданных, однако никакой гарантии, что в двух разных бухгалтерских базах не произойдет выгрузки документов с одинаковым ГУИДОМ - нет. Конечно, вероятность очень мала, но при больших объемах документооборота она возрастает... В конфигурации документооборота в справочнике "Внутренние документы" добавлен новый реквизит "УидИсточника", куда в процессе выгрузки записывается исходный идентификатор документа. Поля поиска - организация + этот реквизит. В процессе получения штрихкода при их загрузке в бухгалтерию анализируется вид документа и в рамках вида объекта метаданных производится поиск по уникальному идентификатору. Организация нужна для того, чтобы при загрузке считать изменения только той организации, объекты которой были выгружены из текущей бухгалтерской базы.

 

Итак:

  1. В бухгалтерии при создании или изменении документа происходит его регистрация в плане "Полный".
  2. С помощью регламентного задания запускается обработка выгрузки. Правила обмена встроены в макет обработки в виде двоичных данных, что позволяет не хранить их отдельно в локальной сети. Обработка выгружает документы, зарегистрированные к изменению, в документообороте происходит создание карточек и формирование штрихкодов. Выгрузка сделана с помощью COM. Нюанс: чтобы COM работал на 64-х битном сервере, пришлось использовать COM+оснастку для объекта компоненты COM 1C. Статьи, как это сделать - есть в просторах интернета.
  3. Обработка выгрузки считывает в документообороте вновь сформированные штрихкоды с отбором по выгружаемой организации (план обмена штрихкодов имеет реквизит "организация"), после чего регистрация штрихкодов очищается.
  4. Производится поиск исходных документов и запись в регистр сведений дополнительных свойств штрихкода (документ-владелец + штрихкод). Узел плана "Полный" очищается.

Самая сложная часть выполнена - осталось реализовать печать штрихкода. Создаем внешнюю печатную форму.

  • Учитывая, что все базы работают в клиент-серверном  варианте - компоненты печати штрихкодов загрузим в регистр сведений "Шаблоны машиночитаемых форм" (можно любой другой, также имеющий ресурс с типом "Хранилище значений"). С помощью метода получения навигационной ссылки в печатной форме будем получать ссылку на ресурс регистра, используя ключ записи, а затем выполнять подключение внешней компоненты. Таким образом, на клиенте мы получаем  возможность использования компоненты печати штрихкодов без встраивания ее в макеты конфигурации (то есть без ее доработки). Если бы наша база работала в файловом варианте, то компоненту печати можно хранить просто в файловой системе.
  • Из регистра сведений дополнительных свойств получаем штрихкод, используя отбор по текущему документу на печати.
  • Картинку штрихкода помещаем на макет печатной формы обработки ВПФ.
  • Готово.

Далее, напечатанный документ вместе со штрихкодом будет отсканирован. Сканы таких документов с помощью обработки потокового сканирования загружаются в Документооборот и там распознаются, происходит прикрепление файлов к уже созданным  карточкам. Необходимо отметить, что встроенная в документооборот компонента распознавания работает нестабильно. Из 10 документов со штрихкодами распознается порой не более 3-4. Что говорить, если даже в книге описания конфигурации написано, цитирую: "для возможности распознавания штрихкодов необходимо использования ABBY Recognition server". ABBY Recognition server действительно с задачей распознавания справляется на "ура" (выяснено в результате тестирования) и распознает штрихкоды как только что отсканированных напрямую со сканера документов, так уже и готовых картинок JPG или документов PDF. В документообороте есть возможность работать с этим ПО, однако стоит  продукт ABBY весьма недешево...

 

Прилагаю к статье обработку выгрузки и одну из внешних печатных форм. Правила обмена встроены в макет обработки выгрузки, их можно сохранить и проанализировать в "Конвертации данных".

 

Параллельно разрабатывались правила и для БП 2.0. Отличие только в том, что для того, чтобы реализовать автоматический запуск обработки выгрузки без доработки конфигурации необходимо использовать настройку запуска обмена:

//infostart.ru/public/178760/

7

Скачать файлы

Наименование Файл Версия Размер
АвансовыйОтчет (внешняя).epf
.epf 29,38Kb
20.04.13
19
.epf 29,38Kb 19 Скачать
ВыгрузкаДляБП30.epf
.epf 273,87Kb
20.04.13
15
.epf 273,87Kb 15 Скачать

См. также

Комментарии
Сортировка: Древо
1. alex_davydov 80 24.04.13 11:31 Сейчас в теме
За идею +, но, к сожалению, проверить у меня возможности нет. :(
2. Vladimir_Konyrev 212 26.05.14 09:34 Сейчас в теме
Автору "+" за реализацию.

Скажите пожалуйста, а почему Вы не использовали возможность встраивания в БП 3.0 библиотеки интеграции с ДО, которая идет вместе с поставкой ДО. Библиотека интеграции с ДО работает через Web сервисы - это более надежно и быстрее, к тому же работает как через тонкий, так и через Web клиент.
3. Dach 100 29.05.14 17:14 Сейчас в теме
(2) Vladimir_Konyrev, да, и еще и не ест лицензии, в отличии от COM ))) в последующем на веб-сервисы и переделали.
Оставьте свое сообщение