CRM - Монолит-Инфо

ЗАО МОНОЛИТ-ИНФО
УТВЕРЖДАЮ
Начальник отдела
программирования
____________
/ К.О. Семенов /
МП
31.05.2010
Программный комплекс МОНОЛИТ SQL
Система МОНОЛИТ:CRM
Модуль интеграции 1С 7.7
Описание настройки модуля интеграции
На 30 листах
СОГЛАСОВАНО
Менеджер проекта
____________
/ Ю. М. Денисов /
МП
31.05.2010
Санкт-Петербург
2008
Настройка модуля интеграции
2
Содержание
1. ВВЕДЕНИЕ ............................................................................................................................................................. 3
2. ОБЩИЕ СВЕДЕНИЯ О МОДУЛЕ ИНТЕГРАЦИИ «МОНОЛИТ: CRM» С «1С ПРЕДПРИЯТИЕМ»
ВЕРСИИ 7.7 ................................................................................................................................................................ 4
3. ОПИСАНИЕ ПРИНЦИПА РАБОТЫ МОДУЛЯ В АВТОМАТИЧЕСКОМ РЕЖИМЕ........................... 6
4. ОПИСАНИЕ УСТАНОВКИ СЕРВИСНОЙ СЛУЖБЫ И ВНЕШНЕЙ КОМПОНЕНТЫ. ..................... 6
5. КОНФИГУРИРОВАНИЕ МОДУЛЯ ДЛЯ РАБОТЫ С 1С ПРЕДПРИЯТИЕМ ........................................ 8
6. ДОПОЛНИТЕЛЬНЫЕ ВОЗМОЖНОСТИ МОДУЛЯ.................................................................................. 14
7. ОПИСАНИЕ СЛУЖЕБНЫХ ФАЙЛОВ МОДУЛЯ ИНТЕГРАЦИИ. ....................................................... 15
8. НАСТРОЙКА ОБМЕНА ТОВАРАМИ И ЕДИНИЦАМИ ИЗМЕРЕНИЯ (ОБМЕН CRMWARE). ...... 16
9. НАСТРОЙКА ОБМЕНА ОСТАТКАМИ НА СКЛАДАХ (ОБМЕН CRMWHBALANCEEX). .............. 17
10. НАСТРОЙКА ОБМЕНА ОТГРУЗКАМИ (ОБМЕН CRMDESPATCHEX). ........................................... 18
11. НАСТРОЙКА ОБМЕНА ЗАКАЗАМИ (ОБМЕН CRMORDEREX). ........................................................ 24
12. НАСТРОЙКА ОБМЕНА СТАТУСАМИ ЗАКАЗОВ (ОБМЕН CRMORDERSTATUS). ....................... 26
13. НАСТРОЙКА ОБМЕНА ВЗАИМОРАСЧЕТАМИ (ОБМЕН CRMSALDOEX). .................................... 27
14. ВСПОМОГАТЕЛЬНЫЕ ЭЛЕМЕНТЫ МОДУЛЯ. ..................................................................................... 30
Настройка модуля интеграции
3
1. Введение
В данном документе будут рассмотрены вопросы, связанные с установкой,
настройкой и работой модуля обмена информацией между системами «Монолит: CRM» и
«1С Предприятием» версии 7.7..
Настройка модуля интеграции
4
2. Общие сведения о модуле интеграции «Монолит: CRM» с «1С Предприятием»
версии 7.7
Модуль интеграции (обмена) предназначен для передачи информации о товарах и
полученных заказах из системы «Монолит: CRM» в систему управления продажами
дистрибутора, построенную на базе «1С Предприятия» версии 7.7, а так же для передачи в
обратном направлении информации об остатках на складах, отгрузках и текущего
состояния взаиморасчетов.
Перед разработкой обмена были сформулированы следующие критерии, которым
должен был отвечать модуль:
1. Необходимо разработать программный продукт, который обеспечивал бы обмен
данными между системой управления продажами на базе 1С Предприятия версии 7.7 и
системой «Монолит: CRM».
2. Обмен происходит файлами в формате xml. Формат файлов приводится в
приложении (документ описания файлов формата доступен для ознакомления на сайте
компании Монолит-Инфо). Важно: передаваемая информация представляет собой
текстовую строку неограниченной длины, без служебных символов (таких как возврат
каретки, перевод строки и символ табуляции).
3. При установке и настройке модуля необходимо по возможности исключить
любые изменения в конфигурации партнера компании-поставщика.
4. Модуль должен обеспечивать возможность как ручного (инициированного
оператором), так и автоматического обмена информацией по заранее созданному
расписанию.
5. Обмен данными с веб-сервисом должен происходить по протоколу HTTP-POST,
что гарантирует контроль выполнения процедур обмена с возможностью
протоколирования для выявления ошибок.
В результате анализа поставленной задачи и системы управления продажами (1С
Предприятие 7.7) была разработана структура модуля:
1. Так как система 1С в базовой версии не имеет встроенной функции выполнения
заданий по расписанию и настройка ее работы с внешними приложениями в любом случае
требует дополнительного программирования, было принято решение разделить модуль на
две части:
- Сервисную службу, которая осуществляла бы контроль расписания и запуск 1С
как COM OLE-объекта;
- Набор внешних обработок, которые обеспечивали бы логику работы модуля
(выборку и форматирование данных);
2. Поскольку система 1С позволяет вносить в типовые конфигурации любые
изменения и создавать собственные (оригинальные) конфигурации, то создать модель
настройки модуля для произвольной конфигурации весьма затруднительно. Поэтому было
принято решение о том, что параметры работы модуля будут настраиваться интерактивно
(в форме), а логика работы программных процедур будет корректироваться
специалистами по 1С на местах установки (у конечных пользователей – дистрибуторов).
В настоящее время модуль состоит из двух частей. Первая, отвечающая за работу
модуля в среде операционной системы, устанавливается стандартным образом (файл
setup.exe). Вторая, обеспечивающая работу модуля в среде 1С и состоящая из набора
внешних обработок, устанавливается в любое удобное для пользователя место.
Структура модуля приведена на рисунке.
Настройка модуля интеграции
5
Рисунок 1. Структура модуля обмена
Настройка модуля интеграции
6
Не смотря на то, что модуль предназначен для работы в автоматическом режиме, в
процессе настройки и тестирования, а так же для случаев, когда автоматический обмен не
состоялся по независящим от пользователя причинам, есть возможность выполнения всех
необходимых обменов вручную. Для облегчения настройки модуля, специалистами
компании Монолит-Инфо была создана внешняя компонента для 1С, которая
обеспечивает соединение с веб-сервисом по протоколу HTTP-POST, что позволяет
ограничиться только настройками модуля под конфигурацию дистрибутора.
3. Описание принципа работы модуля в автоматическом режиме.
Последовательность действий, выполняемых модулем при выполнении обменов
можно описать следующим образом:
- При запуске сервисной службы происходит считывание текущего расписания из
файла конфигурации модуля.
- Раз в 30 секунд сервисная служба просматривает расписание обменов. Если флаг
обновления расписания установлен, то оно загружается в память, иначе продолжается
работа с имеющимся расписанием.
- Сравнивая текущее системное время со временем, установленным для элементов
расписания, сервисная служба определяет, когда запускать очередной обмен.
- Сервисная служба пытается произвести запуск 1С как COM OLE-объекта.
- В случае если запуск прошел успешно, то в систему передаются параметры для
открытия формы внешней обработки Exchange.ert, которая содержит все необходимые
процедуры для инициализации модуля и запуска обменов.
- Получив все необходимые параметры, модуль выполняет запрос к базе данных и
оформляет результат в формате xml в виде текстовой строки неограниченной длины.
- Полученные данные с использованием внешней компоненты MIOConnect.dll
передаются для обработки веб-сервисом компании-поставщика. Результат обмена
заносится в журнал.
- По завершении обмена, 1С автоматически выгружается из памяти (работа сессии
прекращается).
4. Описание установки сервисной службы и внешней компоненты.
Для того, чтобы установить модуль интеграции необходимо зайти на сайт компании
Монолит-Инфо и скачать архив на свой компьютер. Затем распаковать архив и запустить
файл setup.exe
Далее будет предложена стандартная процедура инсталляции приложения Windows,
необходимо подтверждать каждый следующий шаг, нажимая кнопку «Далее». При
желании можно указать другую папку для установки. По умолчанию предлагается путь
C:\Program Files\Monolit CRM\MI1C.
После установки модуля необходимо произвести первоначальную настройку. Для
этого необходимо, чтобы системный администратор или другой специалист ИТ открыл
окно с перечнем служб (Services) и выполнил запуск службы CRMDataExchangeService.
Кроме того, необходимо помнить, что после каждой перезагрузки выделенного
компьютера или сервера необходимо проверять и при необходимости перезапускать
данную службу или настроить автозапуск службы после перезагрузки компьютера.
Рекомендуется для работы модуля создать выделенного пользователя с
расширенными правами или с правами локального администратора. Так же желательно,
чтобы у данного пользователя была автоматическая авторизация на прокси-сервере (если
дистрибутор использует для доступа в сеть Интернет прокси-сервер с авторизацией), а так
Настройка модуля интеграции
7
же полный доступ к папкам, в которых установлены база данных и где находится файл
конфигурации модуля mioconnect.config. В случае, если автоматическую авторизацию на
прокси-сервере сделать нельзя, модуль позволяет настроить подключение к нему,
заполнив соответствующие реквизиты внешней обработки Exchange.ert. Как это сделать
будет показано ниже. Обязательно все настройки проводить под этим специально
созданным login-ом. Особое внимание следует уделить настройке сервисной службы.
Перед запуском следует открыть службу (см. рисунок 2)
Рисунок 2. Запуск сервисной службы
Затем перейти на закладку Log On (см. рисунок 3) и указать в поле полное
доменное имя пользователя. Если дистрибутор не использует доменную структуру при
организации сети, можно указать сетевого пользователя, но проследить, чтобы все
необходимые доступы у него так же были настроены.
Рисунок 3. Ввод логина пользователя, от имени которого запускается служба
Настройка модуля интеграции
8
Для того чтобы обновить модуль интеграции, необходимо выполнить следующие
действия:
- Открыть пункт меню Пуск -> Настройки -> Панель управления -> Установка и
удаление программ.
- Выбрать в списке МОНОЛИТ: CRM. Модуль интеграции 1С
- Выбрать пункт «Удалить».
После удаления модуля перезагрузка системы не требуется.
После удаления модуля необходимо запустить setup.exe новой версии. Для того, чтобы
не пришлось снова вводить все параметры настройки, действовавшие для обновляемой
версии, рекомендуется предварительно сделать копию файла mioconnect.config, чтобы
затем снова скопировать его в папку после обновления.
Возможна ситуация, когда модуль по каким-либо причинам не удаляется. Чаще всего,
это связано с тем, что была попытка установки новой версии модуля поверх уже
установленной. К сожалению, текущая версия программы-инсталлятора не поддерживает
возможность установки обновленной версии поверх текущей. Поэтому, если модуль не
удаляется и выдает сообщение об ошибке, системному администратору необходимо
произвести удаление всех записей о модуле из системного реестра и произвести
инсталляцию новой версии так, как это описано ниже.
В случае, когда необходимо удалить модуль интеграции, достаточно выполнить
следующие действия:
- Открыть пункт меню Пуск -> Настройки -> Панель управления -> Установка и
удаление программ.
- Выбрать в списке МОНОЛИТ: CRM. Модуль интеграции 1С
- Выбрать пункт «Удалить».
После удаления модуля перезагрузка системы не требуется.
5. Конфигурирование модуля для работы с 1С Предприятием
Для осуществления работы в 1С необходимо загрузить с сайта компании МонолитИнфо набор внешних обработок и распаковать их в папку, где они и будут храниться.
После этого нужно открыть рабочую базу в 1С и запустить внешнюю обработку
Exchange.ert.
Для начала работы с модулем необходимо выполнить некоторые предварительные
действия, а именно:
- Отправить в службу ИТ компании-поставщика письмо с уведомлением о том, что
дистрибутор собирается запустить у себя модуль обмена. В письме необходимо указать
полное наименование дистрибутора, контактную информацию и список полных кодов
складов, с которых будет производиться отгрузка товаров поставщика клиентам
дистрибутора, а также указать полные коды складов ответственного хранения (складов
консигнации). Так же можно заказать пароль для обменов.
- Через некоторое время от службы ИТ компании-поставщика будет получен ответ,
который будет содержать в себе код базы данных (каждая физическая база данных
должна иметь уникальный код – это связано с распределением заказов), сертификат
подключения к веб-сервису, который надо установить с помощью приложения Internet
Explorer и адрес веб-сервиса. Если дистрибутор заказывал пароль, то, помимо кода базы
данных, будет предоставлен и пароль.
Настройка модуля интеграции
9
Рисунок 4. Общий вид рабочей формы модуля интеграции
Рисунок 5. Закладка настройки параметров соединения с веб-сервером
На рисунке 5 видно, что на форме заполнены реквизиты адреса веб-сервиса и кода
базы данных. Кроме того, на этой закладке необходимо обязательно установить чек-бокс
Настройка модуля интеграции
10
«Согласование у дистрибутора», а так же заполнить реквизиты «Пользователь 1С для
робота» и «Пароль». Если дистрибутор использует для выхода в Интернет прокси-сервер,
то необходимо указать его адрес и открытый порт. Также возможно указать логин и
пароль, если автоматическую авторизацию по каким-то причинам настроить нельзя.
На данной форме можно так же заполнить расписание для автоматических
обменов, указать список адресов, куда будут приходить сообщения о результатах обмена,
выбрать режим оповещения (всегда или только об ошибках) и указать вид документа,
который будет формироваться по умолчанию в случае обработки заказов, переданных из
«Монолит: CRM».
При настройке автоматического обмена заполняется перечень процедур, которые
необходимо выполнять без участия оператора. Чтобы добавить процедуру в список,
необходимо выполнить следующие действия: нажать кнопку
нового задания:
. Откроется окно ввода
Рисунок 6. Форма для заполнения списка автообменов
В первую очередь выбирается вид автоматического обмена из списка, после чего
устанавливается время его выполнения, если он запускается единожды в сутки или
интервал, если данный обмен должен выполняться с заданной регулярностью. В качестве
периода устанавливается интервал в часах или минутах, а так же задается начало и
окончание процедуры обмена в течение суток.
ВАЖНО: помните, что автоматический обмен настраивается в пределах
суток, то есть интервал времени, который имеет смысл указывать, находится между
00:00:00 и 23:59:59, а если вы настраиваете периодический обмен, то период между
отдельными заданиями не должен быть БОЛЬШЕ указанного интервала
выполнения. Так, в частности, очень часто интервал обмена (реквизиты «Начало» и
«Окончание») указывают равным, к примеру, 8:00 и 22:00, а период обмена
Настройка модуля интеграции
11
выставляют в 24 часа. С точки зрения логики работы модуля, это означает, что
обработка не будет запущена ни разу.
Рисунок 7. Форма для заполнения списка автообменов
Рисунок 8. Форма для заполнения списка автообменов
Последним пунктом на этапе настройки параметров будет указание справочников
Контрагентов и Торговых точек на закладке «Метаданные». В случае, если дистрибутора
использует один справочник для контрагентов и торговых точек, необходимо указать его
Настройка модуля интеграции
12
наименование в обоих пунктах. Это обязательное условие правильной работы экспортаимпорта.
При заполнении формы или внесении изменений, по окончании ввода данных
необходимо обязательно нажимать кнопку «Сохранить».
После заполнения данных на закладке «Настройки», следует вернуться на закладку
«Общие» и указать склады, с которыми будет работать модуль (см. рисунок 4, правый
нижний угол формы). В текущей версии модуля склады могут быть двух видов: склады
отгрузки товаров и склады ответственного хранения (консигнации). В случае если
дистрибьютор не участвует в программе консигнации, заполняется только верхний
список. В этом случае остатки и отгрузки передаются только по указанным в списке
складам и поставщика интересуют только документы типа «Реализация», «Возврат от
покупателя» и «Поступление ТМЦ». Если же дистрибьютор является консигнатором, это
означает, что он предоставляет часть складских площадей под размещение товаров
Поставщиком. Заполнение этих площадей товаром является обязанностью логистического
и транспортного отделов Поставщика. В свою очередь консигнатор получает возможность
распоряжаться этим товаром как своим, однако это требует соблюдения формальных
процедур:
- отгрузка товаров покупателям может происходить только со складов
дистрибьютора, указанных в первом списке,
- в случае нехватки товара на складе дистрибьютора и наличия его на
консигнационном складе, можно сформировать документ внутреннего перемещения,
после чего выполнить отгрузку стандартным образом.
- так как юридически товар на складе консигнации принадлежит Поставщику, то в
конце дня все перемещенные с него на основной склад товары объединяются в одну
накладную реализации от поставщика дистрибьютору-консигнатору, данный документ
передается в бухгалтерию.
Кроме изменения списка складов для полного контроля состояния своих складов
Поставщик требует передавать информацию о всех движениях на складах дистрибьютора.
Для этого в обмене отгрузками CRMDespatchEx, набор данных CRMDespatch,
используется реквизит DocumentTypeId, который содержит тип передаваемого документа.
Каждому из типов складов соответствует свой набор типов документов. Таблица
соответствия приведена ниже:
Таблица соответствия типов документов складам.
№
п/п
Тип документа
Комментарий
Свой
склад
Склад
консигнации
1
Despatch
Документ вида «Реализация» в типовой 1С
Да
Нет
2
VendReceipt
Документ вида «Поступление ТМЦ» в типовой
1С
Да
Да
3
VendReturn
Документ вида «Возврат поставщику»
Да
Да
4
CustReturn
Документ вида «Возврат от покупателя»
Да
Нет
5
ProdReceipt
Документ вида «Списание ТМЦ»
Да
Да
6
ProdReturn
Документ вида «оприходование ТМЦ»
Да
Да
7
MovingNoteFrom
Документ вида «Перемещение ТМЦ» в части
склада-источника
Да
Да
8
MovingNoteTo
Документ вида «Перемещение ТМЦ» в части
склада-приемника
Да
Да
Настройка модуля интеграции
13
Данная таблица нуждается в пояснении. Во второй колонке указано наименование
вида документа, которое должно выгружаться модулем при обменах. Каждому виду
документа сопоставлен вид документа из конфигурации 1С (для простоты понимания
приведены наименования видов из типовой 1С «Торговли и склада»). В реальной
конфигурации у дистрибьютора каждому виду может соответствовать более одного вида
документов, что необходимо проконтролировать на этапе выборки. В двух последних
колонках указана возможность использования данного вида документов для данного типа
склада. Видно, что со складов консигнации не может выполняться отгрузка конечному
потребителю и на него не может осуществляться прием возврата от покупателей. Все
остальные виды документов могут быть как у собственных складов, так и у складов
ответственного хранения.
Отдельно надо сказать о документе «Перемещение ТМЦ». Данный документ
осуществляет внутреннее движение товара с одного склада на другой, поэтому в модуле
каждая строка такого документа описывается двумя наборами данных. MovingNoteFrom –
для склада-источника и MovingNoteTo – для склада-приемника. Важно помнить, что
единственным вариантом передачи товара со склада ответственного хранения на склад
реализации является именно документ перемещения.
Следующим шагом является указание справочников, содержащих информацию о
контрагентах и торговых точках. Для этого необходимо открыть закладку «Метаданные»
и с помощью выпадающих списков, содержащих перечень всех справочников
конфигурации, выбрать необходимые.
Рисунок 9. Заполнение информации о контрагентах и торговых точках.
Нужно не забывать, что один и тот же справочник может содержать как
информацию о контрагентах, так и о торговых точках (например, как это делается в
Настройка модуля интеграции
14
типовой конфигурации), но даже в этом случае необходимо указать наименование
справочника в обоих списках. Если какой-то справочник был выбран по ошибке или
дистрибутор перестал использовать его в работе, двойным кликом левой копки мыши
можно удалить наименование справочника из списка.
На этой же закладке можно указать контрагентов, которые должны быть
исключены из экспорта данных по отгрузкам. Это могут быть контрагенты, входящие в
холдинг дистрибьютора, или субдилеры, иными словами, отгрузки, производимые
данным контрагентам, могут продублировать данные и исказить их.
Первичная настройка модуля закончена. Прежде чем приступать к тестированию
обменов, необходимо ознакомиться со служебными файлами, которые автоматически
создаются при установке модуля и призваны обеспечить работу модуля.
6. Дополнительные возможности модуля.
В данном пункте будут описаны дополнительные возможности модуля. Для этого
необходимо открыть закладку «Сервис» (рисунок 10)
Рисунок 10. Заполнение сервисной информации.
Закладка разделена на три функциональные зоны. Слева вверху расположено
четыре кнопки для выполнения сервисных процедур, вверху справа – группы расширения
функционала по логированию обменов и работе с заказами, а внизу – группа расширения
функционала по обмену отгрузками.
Кнопка «Очистить удаленные заявки» позволяет удалить из файла order.dbf
помеченные на удаление записи. Данная процедура полезна в том случае, если очистка
файла выполняется без помощи внешнего редактора dbf-файлов и в программной
Настройка модуля интеграции
15
процедуре не указано на непосредственное удаление записей, а только проставление
пометки на удаление.
Кнопка «Переиндексация и сжатие DBF» позволяет выполнить соответствующие
действия с файлами, содержащими таблицы сопоставления и список заказов, после
удаления из них лишних записей, что ускоряет работу модуля и уменьшает вероятность
ошибок при выполнении больших обменов. Выполнение данной процедуры следует
производить между автоматическими обменами. По завершении процедуры обработку
следует закрыть. Далее модуль работает в обычном режиме.
Кнопка «Создать MIOConnect.config» позволяет записать шаблон файла
конфигурации в произвольную папку по выбору пользователя. При этом, пользователь не
избавляется от необходимости заполнить реквизиты внешней обработки Exchange.ert
заново.
Кнопка «Обновить» позволяет упростить рутинные процедуры обновления
структуры вспомогательных файлов (client.dbf, ware,dbf и order.dbf) в том случае, если
необходимо изменить количественный состав и/или тип колонок, входящих в них. При
этом сохраняются все имеющиеся там данные. Данный пункт требует более подробных
объяснений. Дело в том, что в 1С версии 7.7 обновление программных модулей в
автоматическом режиме может быть выполнено только на уровне отдельных сущностей
(документ, форма справочника, внешняя обработка), поэтому замена старой версии
внешней обработки на новую в автоматическом режиме в общем случае выполнена быть
не может. Предполагается, что замену кода в процедурах выполняет программист,
сопоставляя полученные обработки новой версии с текущей рабочей обработкой. Однако,
обновить структуру сервисных файлов можно автоматически. Для этого необходимо
запустить внешнюю обработку Exchange.ert, взятую из поставки и нажать кнопку
«Обновить». В дальнейшем, после возврата рабочей версии внешней обработки (в общем
случае считается, что изменения в нее вносились), необходимо сравнить и привести в
соответствие процедуру СоздатьФайлы(), в которой приведен список колонок с указанием
типов, а так же описание индексов.
Начиная с версии 1.0.38, появилась возможность передавать данные в сжатом виде,
для чего в интерфейс модуля добавлен параметр «Включить сжатие данных». Для работы
данного функционала необходимо, чтобы в системе дистрибьютора была установлена
версия внешней компоненты MIOConnect.dll не старше 1.0.10.32609, а так же была
установлена вспомогательная библиотека DLConnect.dll. В этом случае при установке чекбокса параметр UseCompression так же устанавливается в 1 и автоматически включается
сжатие данных в формате zip. Переданный файл так же автоматически распаковывается
web-сервисом Поставщика. Верно и обратное – при установке данного чек-бокса данные о
заказах передаются в сжатом виде и автоматически распаковываются внешней
компонентой на сервере дистрибьютора, после чего обрабатываются модулем в обычном
режиме.
На этом описание сервисной закладки завершено. Описание других групп
реквизитов выполнено в соответствующих разделах данного файла, там же, где приведено
описание функционала, с которым они связаны.
7. Описание служебных файлов модуля интеграции.
Так как модуль разработан для интеграции учетных систем, для обмена
информацией необходимо создать таблицы соответствия, которые позволили бы
установить однозначное соответствие элементов учета одной системы элементам учета
другой системы. В настоящее время в модуле применяется две таблицы соответствия –
для товаров и контрагентов (ware.dbf и client.dbf), кроме того, используется еще один
служебный файл order.dbf, в котором хранится информация о поступивших в систему
Настройка модуля интеграции
16
заказах и их статусах. Данные файлы вместе с соответствующими индексными файлами
(*.idx) создаются при открытии формы Exchange.ert в первый раз. В дальнейшем, всякий
раз при попытке запустить интерфейсную часть из 1С происходит автоматическая
проверка на наличие файлов, и если их нет, то они снова создаются. Однако следует
помнить, что файлы создаются без какой-либо информации, поэтому, для ускорения
запуска модуля после системных сбоев рекомендуется сохранять копии этих файлов в
архиве.
Структура любой таблицы сопоставления проста – с одной стороны, она содержит
минимум информации о сопоставляемых величинах из сторонней базы данных, с другой,
этой информации сопоставляется информация из собственной базы данных дистрибутора.
Так таблица соответствия товаров и единиц измерения содержит 5 полей, которые
позволяют однозначно идентифицировать товар: код в системе CRM, наименование,
единицу измерения по-русски, единицу измерения по-английски и коэффициент пересчета
по отношению к единице измерения «штука». Для однозначного сопоставления этим
полям достаточно всего двух колонок, содержащих информацию из конфигурации
дистрибутора – кода элемента справочника «Номенклатура» и кода элемента справочника
«ОКЕИ».
У таблицы сопоставления контрагентов и торговых точек структура такая же: код
торговой точки в CRM, наименование торговой точки, полное наименование торговой
точки и адрес доставки (его еще называют фактическим адресом торговой точки). Из базы
данных дистрибутора берется ссылка на элемент справочника «Контрагенты», ссылка на
элемент справочника «Торговые точки» и в явном виде – адрес доставки (фактический
адрес). Здесь важно знать, что в таблице хранится именно ссылка на элемент, а не код или
какой-либо еще идентифицирующий параметр.
Последний служебный файл order.dbf содержит номера и даты созданных в системе
дистрибутора заказов, которые были получены с помощью обмена CRMOrder модуля, а
так же результирующие статусы по этим обменам.
8. Настройка обмена товарами и единицами измерения (обмен CRMWare).
Настройки выбора наименования справочников для номенклатуры и единиц
измерения в модуле нет – они указываются прямо в коде модуля. Для товаров
используется справочник «Номенклатура», а для единиц измерения – справочник «ОКЕИ»
(элементы которого используются для заполнения справочника «Единицы», доступного
для редактирования). Поэтому, если у дистрибутора в системе справочник
«Номенклатура» имеет какое-либо иное название, то необходимо произвести замену
одного наименования на другое. То же самое следует проделать со справочником
«ОКЕИ». Помимо основной внешней обработки Exchange.ert подобную процедуру
необходимо проделать в коде внешних обработок Goods.ert, Comparision.ert и
Synchronization.ert.
После этого можно открыть 1С в режиме предприятия и запустить внешнюю
обработку Exchange.ert. На закладке «Обмены» необходимо отключить все чек-боксы,
кроме «Классификатор товаров и единиц измерения». После чего нажать кнопку
«Произвести обмен».
Если все предыдущие рекомендации выполнены правильно, то модуль попытается
соединиться с веб-сервисом и через некоторое время в табло сообщений появится
информация о результате обмена. Если обмен выполнен успешно, то можно нажать
кнопку «Соответствие товаров и единиц измерения». Откроется внешняя обработка
Goods.ert, позволяющая провести сопоставление товаров и единиц измерения.
Настройка модуля интеграции
17
Рисунок 11. Внешний вид таблицы сопоставления товаров.
Если загрузка данных прошла успешно, следует сразу же провести сопоставление
полученных товарных позиций с товарами, которые есть в базе данных дистрибутора.
Желательно, чтобы принцип ведения справочников номенклатуры и единиц измерения у
дистрибутора совпадал с таковым у поставщика. Это означает, что у одной товарной
позиции может быть сколько угодно единиц измерения. В случае если одна и та же
товарная позиция присутствует в справочнике более одного раза (например, для случаев,
когда отгрузка происходит «пэками» по 6 или 12 штук), то необходимо в любом редакторе
файлов dbf создать еще одну запись для это позиции с единицей измерения «штука» и
сопоставить ей вторую запись. Данное действие требует более подробного пояснения.
Обмен остатками может проводиться в тех единицах измерения, в которых у
дистрибутора остатки хранятся на складе. Обмен отгрузками в обязательном порядке
проводится в базовых единицах. Базовой единицей в «Монолит: CRM» принята «штука».
Поэтому, в случае, когда одному коду из «Монолит: CRM» сопоставляется несколько
номенклатурных позиций из базы данных дистрибутора, необходимо обеспечить
возможность грамотного пересчета кратных остатков в штуки. Для этого каждой
номенклатурной позиции из справочника дистрибутора необходимо сопоставить элемент
с единицей измерения «штука» системы «Монолит: CRM».
ВАЖНО: сопоставление товаров и единиц измерения необходимо провести по
всем используемым дистрибутором товарным позициям сразу. В противном случае
возможны проблемы при работе остальных процедур модуля.
ВАЖНО: сопоставление товарных позиций обязательно производить в
полном объеме, то есть с указанием номенклатуры и единицы измерения. В
противном случае даже при правильной настройке остальных параметров, обмен
данными невозможен.
9. Настройка обмена остатками на складах (обмен CRMWhBalanceEx).
Обмен остатками происходит следующим образом: рассчитывается период
выборки данных как разница между текущей датой и количеством дней, указанным в поле
для экспорта отгрузок (реквизит «период»), далее создается запрос к базе с разбиением
Настройка модуля интеграции
18
итогов по дням. Список складов заполняется на закладке «Обмены» внешней обработки
Exchange.ert, точно такой же список должен быть передан в отдел ИТ компаниипоставщика для того, чтобы передаваемые данные попадали на склады, закрепленные за
дистрибутором в системе «Монолит: CRM».
Необходимо помнить, что при обмене остатками в систему «Монолит: CRM»
передается полный код склада. Поэтому в случае использования дистрибутором
большого количества складов, разбитых на группы, необходимо, чтобы длина полного
кода не превышала 15 символов.
Формат файла обмена остатками подробно описан в документе, содержащем
информацию по всем обменам. Структурно файл состоит из двух наборов данных, один из
которых подчинен другому. Ведущий (заголовочный) набор данных CRMWhBalance
содержит информацию о дате, к которой относится передаваемая информация, полный
код склада, номер документа выгрузки и код торгового представителя. Последние два
пункта необходимо оставлять пустыми, так как данный обмен используется в «Монолит:
CRM» для выполнения нескольких процедур, но дополнительная информация из базы
данных дистрибутора при этом не запрашивается. Подчиненный набор данных
CRMWhBalanceLine содержит информацию о коде товара в системе «Монолит: CRM»,
коде единицы измерения в системе «Монолит: CRM» и количестве товара на складе в
указанных единицах.
ВАЖНО: при обмене остатками возможна ситуация, когда количество товара
на складе превышает 1000 шт. В этом случае, форматирование может быть
настроено таким образом, что в отчетах и на экране выводится результат с
разделением триад. Необходимо проследить, чтобы при выгрузке результатов
значение остатков передавалось без разделительных символов.
10. Настройка обмена отгрузками (обмен CRMDespatchEx).
В системе «1С Предприятие» версии 7.7 используется понятие проведения
документа. Процедура проведения изменяет статус документа и, кроме того, осуществляет
движение остатков по регистрам. Поэтому, экспорт отгрузок происходит только по
проведенным документам. Документ записанный, но не проведенный будет при выборке
проигнорирован.
Структурно обмен состоит из трех наборов данных.
CRMDespatchParam содержит следующую информацию: дату начала периода, за
который передаются данные, параметр SkipDelete, отвечающий за удаление данных из
«Монолит: CRM» и флаг сопоставления на стороне дистрибутора (всегда должен
выставляться в 1). Немного подробнее следует описать суть параметра SkipDelete. Дело в
том, что изначально было принято решение разрабатывать модуль обмена таким образом,
чтобы максимально использовать возможности 1С. Поэтому, в частности, для
формирования xml-файлов применяются механизмы, заложенные во внешнюю
компоненту v7plus.dll. Однако, при тестировании выяснилось, что с помощью данной
компоненты не получается отправить файл размером более 0,5 Мб. Поэтому экспорт
отгрузок, как обмен, содержащий большое количество информации, передается порциями.
Каждый элемент набора данных CRMDespatch, который подробно будет рассмотрен ниже,
представляет собой строку документа. Как только внутренний счетчик достигает значения
100, модуль добавляет в набор данных оставшиеся строки обрабатываемого документа и
передает полученную порцию данных в «Монолит: CRM», после чего начинает набирать
новую порцию данных и обнуляет внутренний счетчик. Так как при передаче информации
необходимо обеспечить возможность записи в таблицу системы «Монолит: CRM», то при
получении даты начала все данные, содержащиеся в таблице по данному дистрибутору,
начиная с указанной даты, удаляются, если параметр SkipDelete равен 0. Поэтому, при
Настройка модуля интеграции
19
передаче первой порции данных этот параметр нужно выставить в 0, тогда как для всех
последующих порций он должен быть равен 1.
Набор данных CRMDespatch подробно описан в документе, содержащем
информацию по всем форматам обмена. Однако, поскольку модуль по умолчанию
полноценно работает только с типовой конфигурацией, при использовании оригинальных
и сильно измененных типовых конфигураций необходимо понимать каким образом
извлекаются те или иные данные. В порядке следования полей в документе-описании:
- CompanyId, AddressId (Код контрагента и код торговой точки);
Единственной особенностью является то, что даже в случае совпадения кодов (то
есть, если контрагент и торговая точка это один элемент справочника «Контрагенты»),
необходимо заполнять оба поля.
- AddressRegionType (код типа региона);
Является атрибутом торговой точки. Имеет значение 1, если торговая точка
относится к городу, 2 – если она расположена в области. В модуле для типовой
конфигурации, поскольку там контрагент всегда совпадает с торговой точкой, данный
параметр заполнен только в одной ветке операторов «Если – Тогда – КонецЕсли». Для
нетиповых конфигураций необходимо провести анализ как именно будут получены коды
контрагента и торговой точки и, соответственно, как получить тип региона. Чтобы не
изменять код ключевых процедур (таких как ПолучитьТабВсехОтгрузок()), в модуль
введена специальная процедура ПолучитьТипРегионаТТ()
- SaleChannel (Канал реализации)
Является атрибутом торговой точки. В модуле для типовой конфигурации,
поскольку там контрагент всегда совпадает с торговой точкой, данный параметр также
заполнен только в одной ветке операторов «Если – Тогда – КонецЕсли». Для нетиповых
конфигураций необходимо провести анализ как именно будут получены коды контрагента
и торговой точки и, соответственно, как получить тип региона. Чтобы не изменять код
ключевых процедур, в модуле есть процедура ПолучитьКаналРеализации().
- CRMOrderNumber (номер заказа, поступившего из «Монолит: CRM»)
Данный реквизит набора данных заполняется следующим образом. Если расходная
накладная создана на основании заявки покупателя, то в файле order.dbf ищется запись с
указанием номера заявки, и если она есть, то из этой записи извлекается номер заказа в
CRM, если же накладная была создана сразу, то в файле ищется заказ по номеру
накладной. Поэтому важно, чтобы дистрибутор не нарушал нумерацию документов и
сохранял все привязки документов друг к другу. В противном случае, становится
невозможным установить создана данная реализация на основании заказа, или получена
иным способом (по звонку, личное посещение и т. д.).
- DocumentTypeId (тип документа)
Данный реквизит возник после того, как был запущен механизм работы с
дистрибуторами-консигнаторами. Для того, чтобы контролировать остатки на складах
ответственного хранения компании-поставщику необходимо отслеживать все возможные
виды движения по этим складам. Поэтому была проведена доработка экспорта отгрузок и
добавлен данный реквизит. Значения, которые он может принимать, приведены ниже:
- Despatch, для документа вида «Реализация»,
- VendReceipt, для документа вида «Поступление ТМЦ»,
- VendReturn, для документа вида «Возврат поставщику»,
Настройка модуля интеграции
20
- CustReturn, для документа вида «Возврат от покупателя»,
- ProdReceipt, для документа вида «Списание ТМЦ»,
- ProdReturn, для документа вида «Оприходование ТМЦ»,
- MovingNoteFrom, для документа вида “Перемещение ТМЦ» в части складаисточника,
- MovingNoteTo, для документа вида «Перемещение ТМЦ» в части складаприемника.
ВАЖНО: по всем видам документов каждая строка выводится один раз и
обозначает один вид движения, кроме документов «Перемещение ТМЦ», где по каждой
строке необходимо указать два движения – расход со склада-источника и приход на складприемник.
- DocumentNumber и DocumentDate (номер и дата документа)
В эти реквизиты заносятся номер и дата экспортируемого документа.
- PayDate (предполагаемая дата оплаты)
В данный реквизит заносится предполагаемая дата оплаты. В типовой
конфигурации она существует в документе «Реализация» в виде реквизита. Если данный
реквизит документа не заполнен, то и поле набора данных не заполняется.
- WareHouseId (код склада)
Данный реквизит представляет собой полный код склада, с которого производилась
отгрузка (или на который произошло поступление товара).
- WareId (код товара в «Монолит: CRM»)
Для того, чтобы данные загрузились в CRM необходимо провести перекодировку
товара из представления в виде справочника 1С к виду, принятому в классификаторе
товаров и единиц измерения в «Монолит: CRM». Для этого при получении очередной
строки документа вызывается функция перекодировки КодCRMПоТовару(), которая
возвращает код CRM, который и попадает в формируемый файл. Важно правильно
провести сопоставления, поскольку экспорт отгрузок происходит только в штуках, для
чего используется процедура пересчета из других единиц измерения. Если заполнение
таблицы сопоставления выполнено неправильно или не до конца, то при выгрузке могут
возникнуть дробные величины.
- Price и Quantity (цена и количество)
Цена и количество единицы товара. В случае, если в документе используется
единица измерения, отличная от штуки, данные для выгрузки получаются путем
пересчета с использованием коэффициента, взятого из таблицы сопоставления.
Набор данных CRMClientAddress используется для передачи данных о клиентах и
торговых точках в систему «Монолит: CRM». Состав набора данных дан в файле,
описывающем форматы обмена. Необязательным в данном наборе является только поле
CRMClientId, все остальные поля могут быть получены из системы учета дистрибутора и
являются обязательными для заполнения. Обязательно необходимо проследить за тем,
чтобы каждая пара «Контрагент + Торговая точка» встречалась в наборе данных только
один раз! Поскольку модуль, поставляемый в дистрибутиве, разрабатывается для типовой
конфигурации, при работе с оригинальными (или достаточно сильно измененными)
конфигурациями возможно появление дублей в данном наборе. Чаще всего это связано с
обработкой контрагентов и торговых точек и появлением с одной стороны сочетания пары
Настройка модуля интеграции
21
с кодом CRM, с другой стороны, появлением такой же пары, но уже не сопоставленной с
каким-либо кодом CRM. При настройке модуля необходимо проверить, чтобы поиск
сопоставления выполнялся один раз и всегда. Важно также понимать, что экспорт
отгрузок (и связанный с ним набор данных CRMClientAddress) никак не связан с
импортом заказов, т. е отсутствие сопоставлений не говорит о том, что данный набор не
может быть сформирован. На сайте компании Монолит-Инфо есть пример файла экспорта
отгрузок.
ВАЖНО: при обмене отгрузками возможна ситуация, когда количество
товара на складе превышает 1000 шт. В этом случае, форматирование может быть
настроено таким образом, что в отчетах и на экране выводится результат с
разделением триад. Необходимо проследить, чтобы при выгрузке результатов
значение остатков передавалось без разделительных символов.
Для грамотного заполнения параметров AddressRegionType и SaleChannel
необходимо грамотно заполнить настройки формы Exchande.ert на закладке «Сервис».
Чтобы объяснить логику заполнения нужно вспомнить основные требования к модулю, а
именно – невмешательство во внутреннюю структуру конфигурации дистрибутора. В
данном же случае компания-поставщик рекомендует своим партнерам добавить в
конфигурацию два новых параметра (предполагается, что данные аналитические признаки
у контрагентов отсутствуют). При этом предполагается, что если конфигурация создана на
базе типовой, то сохранен справочник «Свойства контрагентов», в котором достаточно
просто добавить два новых параметра и заполнить для них возможные значения. Если же
используется сильно переработанная конфигурация или полностью оригинальная, что в
справочник, содержащий перечень Торговых точек необходимо добавить два новых
реквизита (канал реализации и тип региона). Тип значения данных реквизитов может быть
любым, важно, что в модуле есть возможность указать сам реквизит.
ВАЖНО: необходимо четко понимать, что принцип добавления реквизитов
должен быть одинаков, в противном случае средствами стандартного модуля произвести
настройку не получится и придется дорабатывать ее под конкретную конфигурацию.
На рисунке 12 представлен первый этап настройки – выбирается тип реквизита
справочника. К двум вышеописанным вариантам в списке выбора добавлен третий – на
случай, если дистрибутор не собирается до момента полного сопоставления передавать
какую-либо информацию.
В случае, если выбран первый элемент списка, автоматически заполняется
наименование справочника, содержащего информацию о канале реализации и типе
региона (в данном случае это будет справочник «Виды свойств» - см. рисунок 13). После
чего недоступными остаются поля с наименованиями реквизитов, но появляется
возможность указать наименования реквизитов справочника «Свойства контрагентов»,
содержащие значения соответствующих реквизитов (пример см. рисунок 14). На рисунке
видно, что наименование свойства для канала реализации уже проставлено, а для типа
региона – выбирается из списка.
Настройка модуля интеграции
22
Рисунок 12. Выбор вида реквизита справочника для заполнения параметров «Канал
реализации» и «Тип региона».
Рисунок 13. Результат выбора первого элемента из списка возможных видов
реквизита справочника.
Настройка модуля интеграции
23
Рисунок 14. Заполнение наименований реквизитов справочника «Свойства контрагентов»
Рисунок 15. Заполнение наименований реквизитов справочника «Торговый точки»
Настройка модуля интеграции
24
Если выбран второй элемент списка, то необходимо указать наименование
справочника торговых точек (см. рисунок 15), после чего выбрать из выпадающих
списков наименование реквизита, содержащего значение соответствующего параметра
(см. рисунок 15)
Если выбран третий элемент списка – все поля для выбора очищаются и делаются
недоступными для редактирования.
ВАЖНО: начиная с версии 1.0.38 в модуле появилась возможность сжатия данных
при передаче в «Монолит: CRM». Для этого необходимо установить чек-бокс «Включить
сжатие данных» (см. рисунок 10). При этом данные передаются одним блоком, что
повышает надежность передачи данных.
11. Настройка обмена заказами (обмен CRMOrderEx).
Данный обмен настраивается в последнюю очередь (часто совместно с
описываемым ниже обменом CRMOrderStatus). Он позволяет получить заказы от
торговых представителей с КПК, переданные при синхронизации с «Монолит: CRM».
Схема прохождения заказов следующая: торговый представитель принимает заказ в
торговой точке и заносит его в свой КПК, затем он соединяется посредством GPRS с
системой «Монолит: CRM» и передает заказ в нее. Дистрибутор каждые 15-20 минут с
помощью модуля скачивает имеющиеся заказы себе в базу данных. Полученный заказ не
будет преобразован в документ только в случае, если в нем есть хотя бы один не
сопоставленный товар. Если же все товары сопоставлены, то документ «Заявка
покупателя» или «Реализация» (в зависимости от выбора дистрибутора) будет создан.
Если по коду торговой точки, полученной в заказе, найдена сопоставленная пара кодов
Контрагент + торговая точка, то документ будет создан с указанием контрагента и
торговой точки, иначе необходимо будет провести процедуру сопоставления. Для этого
следует нажать кнопку «Классификатор торговых точек» на закладке «Основная»
внешней обработки Exchange.ert, после чего откроется внешняя обработка Comparision.ert.
Она состоит из двух табличных частей. В верхней выводятся записи таблицы
сопоставления контрагентов с возможностью отбора сопоставленных или не
сопоставленных. В нижней таблице выводятся документы, у которых не заполнен
контрагент. После того, как ответственный оператор проведет сопоставление, ему
достаточно нажать кнопку «Заполнить документы» и все документы, которые были
созданы по заявкам с только что сопоставленными торговыми точками, заполнятся
значениями контрагентов и торговых точек.
ВАЖНО: сопоставление контрагентов обязательно проводить в полном
объеме, то есть с указанием контрагента и торговой точки. Даже в случае, когда
значения контрагента и торговой точки совпадает (как, например, это происходит в
типовой конфигурации), необходимо указывать одно и то же значение дважды: в
колонке «Наименование контрагента» и в колонке «Наименование ТТ». В
противном случае обмен работать не будет.
Поскольку каждый дистрибутор, даже пользуясь типовой конфигурацией, волен
заполнять документы ровно настолько, насколько считает это нужным, при обработке
данного набора данных проводится заполнение только тех полей, которые необходимы
для определения документа в системе. Поэтому перед запуском тестирования данной
процедуры специалисту ИТ, проводящему доработку модуля на месте, необходимо четко
определить какие еще реквизиты и какого документа будут заполняться, после чего
следует провести доработку кода во внешней обработке Exchange.ert. Отдельное внимание
надо уделить заполнению табличной части, так как в стандартной версии модуля не
Настройка модуля интеграции
25
производится выбора типа цены и соответствующих процедур пересчета. Кроме того,
очень часто оставляя нетронутой структуру табличной части, дистрибуторы
дорабатывают логику ее заполнения, что влечет за собой ошибки заполнения документов,
поэтому данную процедуру так же необходимо проконтролировать.
Рисунок 16. Внешний вид таблицы сопоставления контрагентов.
Рисунок 17. Пример проведения сопоставления.
Настройка модуля интеграции
26
Формат файла, содержащего заказы, подробно описан в файле, где представлены
все форматы обмена. Обмен CRMOrder является универсальным и используется в системе
«Монолит: CRM» для выполнения нескольких процедур импорта-экспорта, поэтому не
все его поля являются необходимыми для работы в 1С. Это учтено в модуле для типовой
конфигурации следующим образом – для обработки входящей информации используется
метод работы с xml-файлами, основанный на DOM (Data Object Model) технологии. В
этом случае xml-файл рассматривается как «дерево», и программист имеет возможность
обращаться к конкретным «ветвям» и получать значения конкретных элементов данных.
Тогда как при последовательном парсинге файла необходимо перебрать все элементы и
выделить из них необходимые.
12. Настройка обмена статусами заказов (обмен CRMOrderStatus).
Каждый принятый заказ может иметь три состояния: Transferred, Dispatched и
Rejected. После успешной попытки записи документа, информация о нем попадает в файл
order.dbf, где помимо статуса по умолчанию (Transferred) полю Export присваивается
значение 1, что гарантирует отправку нового статуса в «Монолит: CRM». В дальнейшем,
модуль выбирает все заказы со статусом Transferred и проверяет их на изменение статуса.
Если по заказу существует проведенная накладная, то статус меняется на Dispatched и
Export выставляется в 1, если накладная (или заявка) помечены на удаление, то статус
данного заказа выставляется в Rejected, а Export также выставляется в 1. Далее процедура
обработки статусов заказов просто выбирает все имеющие в ячейке Export значение 1 и
добавляет их в файл статусов, формат которого подробно описан в файле форматов.
Сформированный файл отправляется в «Монолит: CRM».
Для того чтобы лучше понимать работу с заказами, необходимо знать каким
образом формируется пакет заказов на стороне «Монолит: CRM». Происходит это
следующим образом. В настоящее время срок жизни заказа составляет 3 дня.
Соответственно, если по данному заказу не получено подтверждение того, что он создан,
он попадает в очередь заказов. После того, как заказ был отправлен дистрибутору, его
приоритет меняется и он перемещается в конец очереди заказов на отправку. Поэтому,
если дистрибутор не создает документов по получаемым заказам, у него может сложиться
впечатление, что он получает одни и те же заказы по несколько раз в день и не получает
более новые, у которых, возможно, дата отгрузки больше, чем у уже имеющихся, но не
просроченных и не принятых.
Дополнительным функционалом работы со статусами является возможность
передачи причины отказа от отгрузки, введенная в версии 1.0.25. В этом случае в файл
order.dbf добавляется поле с причиной отказа. И даже если документ отгрузки помечен на
удаление (или не существует, то есть уже удален), но комментария по этому поводу нет,
статус Rejected не будет отправлен в систему «Монолит: CRM». Для того чтобы заполнить
причину отказа ответственному оператору необходимо предоставить доступ к внешней
обработке OrderProcessing.ert (см. рисунок 19), которая содержит форму для ввода
комментариев.
При открытии формы происходит обращение к файлу order.dbf, в котором идет
поиск документов со статусом Rejected и незаполненным полем комментария. Глубина
поиска определяется параметром «Количество дней контроля» группы «Настройка ввода
комментариев» на закладке «Сервис» (см. рисунок 18). Все такие записи выводятся в
табличную часть. Для облегчения заполнения указывается так же информация о торговой
точке. В табличной части есть два дополнительных текстовых поля. В одно из них
(«Причина») нужно обязательно добавить элемент из фиксированного перечня причин, в
другое – «Комментарий» - можно занести какую-либо еще дополнительную информацию.
Настройка модуля интеграции
27
После заполнения табличной части достаточно дождаться ближайшего обмена статусами
заказов и информация о причинах будет отправлена в систему «Монолит: CRM».
Рисунок 18 . Настройка комментариев по не принятым заказам.
Рисунок 19 . Ввод причины отмены заказа.
13. Настройка обмена взаиморасчетами (обмен CRMSaldoEx).
Данный обмен предназначен для контроля состояния дебиторской задолженности у
дистрибутора.
В связи с тем, что взаиморасчеты наименее стандартизированный механизм в 1С и
чаще всего именно в него вносят изменения с целью упорядочить управленческий учет и
Настройка модуля интеграции
28
контролировать дебиторскую задолженность, поэтому реализация данного функционала в
стандартной версии модуля носит демонстрационный характер и нуждается в
обязательном контроле даже при использовании типовой конфигурации. В данном
разделе будут описаны основные принципы, использованные при формировании наборов
данных.
Обмен взаиморасчетами состоит из трех наборов данных.
Первый набор данных CRMSaldoAggregate предназначен для передачи данных по
видам долга. В типовой конфигурации 1С есть возможность сразу получить данную
информацию, поскольку в регистре «Покупатели» есть измерение «Вид долга». Все поля
данного набора данных подробно описаны в соответствующем файле, однако, необходимо
дать пояснения каким образом они использовались для заполнения набора данных.
- CompanyId, AddresId
Коды контрагента и торговой точки. Ясно из названия.
- ProductId, ProductName
Код и наименование вида расчета. Под видом расчета в типовой конфигурации
используется понятие «Договор». У каждого контрагента существует минимум один
договор (в общем случае он называется «Основным»). Большинство дистрибуторов
позволяет контрагентам заключить несколько договоров, что позволяет клиентам более
свободно оперировать своими средствами и регулировать дебиторскую задолженность.
- mCreditLimit
Сумма кредита, которую имеет контрагент по данному договору (элементу вида
расчета).
- mCustInvoice, mCustInvoiceAllow, mCustInvoiceOverdue
В данные реквизиты заносятся суммы по счетам контрагента (соответственно,
общая, по разрешенным к отгрузке счетам, по просроченным счетам)
- mCustReturn
Сумма по возвратам покупателя
- mDebtDocBank, mDebtDocCash, mDebtDocCopy
Суммы авансов, выплаченных клиентом (по банку, по кассе, по копиям платежных
поручений – для тех систем, где возможен ввод документов по предоставленным копиям)
- mReturnableDebt
Задолженность по залоговой таре
- mVendInvoice, mVendReturn
Суммы по документам поставщика (соответственно, по счетам и возвратам).
Используется, когда клиент является поставщиком товаров или услуг
- mCredDoc
Общая кредиторская задолженность клиента перед банком
- mTotalBalance
Общее сальдо по расчетам с клиентом. Понятно, что эта сумма складывается из
нескольких, относящихся к различным, описанным выше, реквизитам.
Настройка модуля интеграции
29
Вторым набором данных экспорта взаиморасчетов является набор CRMSaldoDoc,
который содержит разложение имеющегося сальдо по составляющим его документам.
- CompanyId, AddresId, ProductId, ProductName
Данные реквизиты выполняют такие же функции, как и в предыдущем наборе.
- DocumentNumber, DocumentDate
Номер и дата документа, составляющего сальдо.
- ActionDate
Дата проведения операции. В системе 1С эта дата чаще всего совпадает с
DocumentDate.
- PaymentDate
Предполагаемая дата оплаты (используется только для документов отгрузки или
оказания услуг)
- OverduePeriod
Количество дней просрочки (используется только для документов отгрузки или
оказания услуг)
- CustInvoiceSumm
Сумма долга по документу счету.
- CustReturnSumm
Сумма долга по документу возврата от покупателя
- PayDocSumm
Свободные авансы по платежным документам.
В данном наборе необходимо отметить одну особенность. В силу того, что
используется разделитель вида учета (договор), значащая сумма может быть только по
одному из реквизитов.
Последний набор данных в этой схеме – CRMSaldoWare – относится к залоговой
таре и оборудованию. В типовой конфигурации 1С нет возможности выделить данные
элементы в отдельную область учета. Тем не менее, состав и правила заполнения
реквизитов будут описаны.
- CompanyId, AddresId
Данные реквизиты выполняют такие же функции, как и в предыдущем наборе.
- WareId
Код тары
- FACode
Инвентарный номер оборудования
- Quantity, Summ
Количество и сумма (в случае положительного значения – долг клиента)
Настройка модуля интеграции
30
14. Вспомогательные элементы модуля.
В данном разделе будут рассмотрены вспомогательные элементы модуля,
позволяющие пользователю получить информацию о том, какие и когда выполнялись
обмены, и с каким результатом они закончились.
Контроль работы модуля осуществляется на всех этапах его работы. В системе
существует три вида файлов, которые в той или иной форме содержат информацию об
обменах.
Файл MI1C.log – это файл в формате «текст», который заполняется в процессе
работы сервисной службы CRMDataExchangeService, то есть когда модуль функционирует
в автоматическом режиме. Файл содержит информацию о времени инициации очередного
обмена, список обменов (в виде форматированной текстовой строки) и результат работы
модуля. В случае, если обмен не выполнен, приводится системное сообщение об этом. В
случае возникновения проблем с настройкой модуля для работы в автоматическом
режиме, при обращении в службу поддержки необходимо предоставлять этот файл.
Файл Log.xml – файл журнала обменов. Ведется как при обмене в ручном режиме,
так и при автоматическом обмене. Содержит следующую информацию: дата и время,
наименование обмена, тип информации – сообщение или ошибка, само сообщение.
Сообщение может формироваться как в модуле, так и поступать от операционной системы
(в случае, когда попытка передать корректно обработанную информацию по каким-либо
причинам не удалась).
Файл current_request.xml – всегда содержит информацию о последнем успешно
завершенном действии. Таким действием может быть как передача запрос на импорт
заказов, экспорт информации об отгрузках, остатках или статусов обработанных заказов,
сообщение об их успешном приеме в систему «Монолит: CRM» или сообщение об
ошибке при обработке данных. В процессе настройки модуля при возникновении проблем
именно этот файл чаще всего необходимо передать специалистам ИТ, консультирующим
дистрибутора.
Так как файл current_request.xml содержит информацию о последнем успешном
действии, то иногда необходимо получить информацию о том, какая именно информация
вызвала тот или иной ответ. Например, от веб-сервиса CRM получено сообщение об
ошибке в файле – именно его и будет содержать current-request.xml, однако, для анализа
нам необходимо увидеть и проанализировать информацию, которая была отправлена от
дистрибутора. Поэтому модуль был доработан таким образом, чтобы при каждом обмене
сохранять отправляемую информацию в файл непосредственно перед обменом, создавая,
таким образом, архив логов. Настройка данного функционала выполняется следующим
образом. Открываем внешнюю обработку Exchange.ert на закладке «Сервис».
Устанавливаем чек-бокс «Сохранять обмены в файлах», указываем путь к папке, в
которой будет храниться архив и количество дней, в течение которых он будет
сохраняться. Если дистрибутор использует оригинальную конфигурацию, то ему
необходимо сравнить все процедуры импорта-экспорта в своей версии модуля и в
стандартной и перенести из последней блоки «Если – тогда», отвечающие за сохранение
логов.
Удаление файлов с датой большей, чем установлена в настройках, происходит 1 раз
в сутки (при первом обмене). Происходит это последующему алгоритму. Формат
наименования лог-файла следующий: схема обмена – дата – время. Из наименования
файла выделяется дата и если она больше, чем рассчитанная максимально допустимая
дата, то данный файл удаляется. Необходимость поиска файлов определяется по наличию
файла с текущей датой (то есть, если такой файл уже есть, то сегодня обмены уже
Настройка модуля интеграции
31
производились, и удаление файлов уже происходило, иначе производим поиск и
удаление).
Рисунок 20 . Настройка сохранения лог-файлов.
Для ускорения обработки статусов заказов в версию 1.0.29 была добавлена
возможность автоматического удаления обработанных заказов с датой большей, чем
рассчитанная. В поле «Количество дней хранения заказов» (см. рисунок 21) можно ввести
любое число, большее 0 (нуля), в этом случае модуль автоматически будет удалять из
файла order.dbf все записи с датой заказа (OrdNumDate) большей, чем текущая дата
минус введенный параметр (число). В случае, если данный параметр оставлен равным
нулю, удаления записей из order.dbf не происходит. После удаления записей о принятых
заказах, происходит сжатие и переиндексация файла order.dbf, поэтому если дистрибутор
хочет сохранять информацию о принятых заказах на случай возникновения спорных
ситуаций, то следует наладить сохранение данного файла с указанием даты средствами
операционной системы.
Настройка модуля интеграции
32
Рисунок 21 . Настройка удаления обработанных заказов из order.dbf.