Программный комплекс монолит SQL Система монолит:CRM Модуль интеграции 1с 8 Описание настройки модуля интеграции (стр. 4 )

- Price и Quantity (цена и количество)

Цена и количество единицы товара. В случае если в документе используется единица измерения, отличная от штуки данные для выгрузки получаются путем пересчета с использованием коэффициента, взятого из таблицы сопоставления.

Набор данных CRMClientAddress используется для передачи данных о клиентах и торговых точках в систему «Монолит: CRM». Состав набора данных дан в файле, описывающем форматы обмена. Необязательным в данном наборе является только поле CRMClientId, все остальные поля могут быть получены из системы учета дистрибутора и являются обязательными для заполнения. Обязательно необходимо проследить за тем, чтобы каждая пара «Контрагент + Торговая точка» встречалась в наборе данных только один раз! Поскольку модуль, поставляемый в дистрибутиве, разрабатывается для типовой конфигурации, при работе с оригинальными (или достаточно сильно измененными) конфигурациями возможно появление дублей в данном наборе. Чаще всего это связано с обработкой контрагентов и торговых точек и появлением с одной стороны сочетания пары с кодом CRM, с другой стороны, появлением такой же пары, но уже не сопоставленной с каким-либо кодом CRM. При настройке модуля необходимо проверить, чтобы поиск сопоставления выполнялся всегда и только один раз. Важно также понимать, что экспорт отгрузок (и связанный с ним набор данных CRMClientAddress) никак не связан с импортом заказов, т. е отсутствие сопоставлений не говорит о том, что данный набор не может быть сформирован. На сайте компании Монолит-Инфо есть пример файла экспорта отгрузок.

ВАЖНО: при обмене отгрузками возможна ситуация, когда количество товара превышает 1000 шт. В этом случае, форматирование может быть настроено таким образом, что в отчетах и на экране выводится результат с разделением триад. В 1С версии 8 данной ошибки можно избежать путем установки в меню «Администрирование» - «Региональные установки БД» параметра «Группировка» в значение «3, 0». После чего необходимо проверить, что при выгрузке результатов значение остатков передается без разделительных символов

Для грамотного заполнения параметров AddressRegionType и SaleChannel необходимо грамотно заполнить настройки формы Exchande. epf на закладке «Параметры». Чтобы объяснить логику заполнения нужно вспомнить основные требования к модулю, а именно – невмешательство во внутреннюю структуру конфигурации дистрибутора. В данном же случае компания-поставщик рекомендует своим партнерам добавить в конфигурацию два новых параметра (предполагается, что данные аналитические признаки у контрагентов отсутствуют). При этом предполагается, что в типовой конфигурации будут просто созданы новые свойства и заполнен соответствующий регистр сведений. Если же используется сильно переработанная конфигурация или полностью оригинальная, что в справочник, содержащий перечень Торговых точек необходимо добавить два новых реквизита (канал реализации и тип региона). Тип значения данных реквизитов может быть любым, важно, что в модуле есть возможность указать сам реквизит.

ВАЖНО: необходимо четко понимать, что принцип добавления реквизитов должен быть одинаков, в противном случае средствами стандартного модуля произвести настройку не получится и придется дорабатывать ее под конкретную конфигурацию.

На рисунках 11 и 12 показаны этапы заполнения свойств торговых точек..

Рисунок 11. Выбор вида реквизита справочника для заполнения параметров «Канал реализации» и «Тип региона».

Рисунок 12. Результат выбора первого элемента из списка возможных видов реквизита справочника.

10. Настройка обмена заказами (обмен CRMOrder).

Данный обмен настраивается в последнюю очередь (часто совместно с описываемым ниже обменом CRMOrderStatus). Он позволяет получить заказы от торговых представителей с КПК, переданные при синхронизации с «Монолит: CRM». Схема прохождения заказов следующая: торговый представитель принимает заказ в торговой точке и заносит его в свой КПК, затем он соединяется посредством GPRS с системой «Монолит: CRM» и передает заказ в нее. Дистрибутор каждые 15-20 минут с помощью модуля скачивает имеющиеся заказы себе в базу данных. Полученный заказ не будет преобразован в документ только в случае, если в нем есть хотя бы один не сопоставленный товар. Если же все товары сопоставлены, то документ «Заказ покупателя» или «Реализация» (в зависимости от выбора дистрибутора) будет создан. Если по коду торговой точки, полученной в заказе, найдена сопоставленная пара кодов Контрагент + торговая точка, то документ будет создан с указанием контрагента и торговой точки, иначе необходимо будет провести процедуру сопоставления. Для этого следует нажать кнопку «Классификатор торговых точек» на закладке «Основная» внешней обработки Exchange. epf. В результате откроется форма сопоставления, которая создана, как подчиненная форма регистра сведений «Монолит таблица сопоставления контрагентов». Она состоит из двух табличных частей. В верхней выводятся записи таблицы сопоставления контрагентов с возможностью отбора сопоставленных или не сопоставленных. В нижней таблице выводятся документы, у которых не заполнен контрагент. После того, как ответственный оператор проведет сопоставление, ему достаточно нажать кнопку «Заполнить документы» и все документы, которые были созданы по заявкам с только что сопоставленными торговыми точками, заполнятся значениями контрагентов и торговых точек.

ВАЖНО: сопоставление контрагентов обязательно проводить в полном объеме, то есть с указанием контрагента и торговой точки. Даже в случае, когда значения контрагента и торговой точки совпадает (как, например, это происходит в типовой конфигурации), необходимо указывать одно и то же значение дважды: в колонке «Наименование контрагента» и в колонке «Наименование ТТ». В противном случае обмен работать не будет.

Поскольку каждый дистрибутор, даже пользуясь типовой конфигурацией, волен заполнять документы ровно настолько, насколько считает это нужным, при обработке данного набора данных проводится заполнение только тех полей, которые необходимы для определения документа в системе. Поэтому перед запуском тестирования данной процедуры специалисту ИТ, проводящему доработку модуля на месте, необходимо четко определить какие еще реквизиты и какого документа будут заполняться, после чего следует провести доработку кода во внешней обработке Exchange. epf. Отдельное внимание надо уделить заполнению табличной части, так как в стандартной версии модуля не производится выбора типа цены и соответствующих процедур пересчета. Кроме того, очень часто оставляя нетронутой структуру табличной части, дистрибуторы дорабатывают логику ее заполнения, что влечет за собой ошибки заполнения документов, поэтому данную процедуру так же необходимо проконтролировать.

Рисунок 13. Внешний вид таблицы сопоставления контрагентов.

Рисунок 14. Пример проведения сопоставления.

Формат файла, содержащего заказы, подробно описан в файле, где представлены все форматы обмена. Обмен CRMOrder является универсальным и используется в системе «Монолит: CRM» для выполнения нескольких процедур импорта-экспорта, поэтому не все его поля являются необходимыми для работы в 1С. Это учтено в модуле для типовой конфигурации следующим образом – для обработки входящей информации используется метод работы с xml-файлами, основанный на DOM (Data Object Model) технологии. В этом случае xml-файл рассматривается как «дерево», и программист имеет возможность обращаться к конкретным «ветвям» и получать значения конкретных элементов данных. Тогда как при последовательном парсинге файла необходимо перебрать все элементы и выделить из них необходимые.

11. Настройка обмена статусами заказов (обмен CRMOrderStatus). .

Каждый принятый заказ может иметь три состояния: Transferred, Despatched и Rejected. После успешной попытки записи документа, информация о нем попадает в регистр сведений «Монолит таблица заказов», где помимо статуса по умолчанию (Transferred) полю Export присваивается значение 1, что гарантирует отправку нового статуса в «Монолит: CRM». В дальнейшем, модуль выбирает все заказы со статусом Transferred и проверяет их на изменение статуса. Если по заказу существует проведенная накладная, то статус меняется на Despatched и Export снова выставляется в 1, если накладная (или заявка) помечена на удаление или отсутствует, то статус данного заказа выставляется в Rejected, а Export также выставляется в 1. Далее процедура обработки статусов заказов просто выбирает все имеющие в ячейке Export значение 1 и добавляет их в файл статусов, формат которого подробно описан в файле форматов. Сформированный файл отправляется в «Монолит: CRM».

Для того чтобы лучше понимать работу с заказами, необходимо знать каким образом формируется пакет заказов на стороне «Монолит: CRM». Происходит это следующим образом. В настоящее время срок жизни заказа составляет 3 дня. Соответственно, если по данному заказу не получено подтверждение того, что он создан, он попадает в очередь заказов. После того, как заказ был отправлен дистрибутору, его приоритет меняется и он перемещается в конец очереди заказов на отправку. Поэтому, если дистрибутор не создает документов по получаемым заказам, у него может сложиться впечатление, что он получает одни и те же заказы по несколько раз в день и не получает более новые, у которых, возможно, дата отгрузки больше, чем у уже имеющихся, но не просроченных и не принятых.

Дополнительным функционалом работы со статусами является возможность передачи причины отказа от отгрузки, введенная в версии 8-1.0.11. В этом случае в регистр сведений «Монолит таблица заказов» добавляется поле с причиной отказа. И даже если документ отгрузки помечен на удаление (или не существует, то есть уже удален), но комментария по этому поводу нет, статус Rejected не будет отправлен в систему «Монолит: CRM». Для того, чтобы заполнить причину отказа необходимо ответственному оператору предоставить доступ к форме, подчиненной регистру сведений «Монолит таблица заказов» (см. рисунок 16), которая содержит форму для ввода комментариев.