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

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

Если загрузка данных прошла успешно, следует сразу же провести сопоставление полученных товарных позиций с товарами, которые есть в базе данных дистрибутора. Желательно, чтобы принцип ведения справочников номенклатуры и единиц измерения у дистрибутора совпадал с таковым у поставщика. Это означает, что у одной товарной позиции может быть сколько угодно единиц измерения. В случае, если одна и та же товарная позиция присутствует в справочнике более одного раза (например, для случаев, когда отгрузка происходит «пэками» по 6 или 12 штук), то необходимо путем копирования создать еще одну запись для это позиции с единицей измерения «штука» и сопоставить ей вторую запись. Данное действие требует более подробного пояснения.

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

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

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

8. Настройка обмена остатками на складах (обмен CRMWhBalanceEx).

Обмен остатками происходит следующим образом: рассчитывается период выборки данных как разница между текущей датой и количеством дней, указанным в поле для экспорта отгрузок (реквизит «период»), далее создается запрос к базе с разбиением итогов по дням. Список складов заполняется на закладке «Обмены» внешней обработки Exchange. epf, точно такой же список должен быть передан в отдел ИТ компании-поставщика для того, чтобы передаваемые данные попадали на склады, закрепленные за дистрибутором в системе «Монолит: CRM».

Необходимо помнить, что при обмене остатками в систему «Монолит: CRM» передается полный код склада. Поэтому в случае использования дистрибутором большого количества складов, разбитых на группы, необходимо, чтобы длина полного кода не превышала 15 символов.

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

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

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

9. Настройка обмена отгрузками (обмен CRMDespatchEx).

В системе «1С Предприятие» версии 8 используется понятие проведения документа. Процедура проведения изменяет статус документа и, кроме того, осуществляет движение остатков по регистрам. Поэтому, экспорт отгрузок происходит только по проведенным документам. Документ записанный, но не проведенный будет при выборке проигнорирован.

Структурно обмен состоит из трех наборов данных.

CRMDespatchParam содержит следующую информацию: дату начала периода, за который передаются данные, параметр SkipDelete, отвечающий за удаление данных из «Монолит: CRM» и флаг сопоставления на стороне дистрибутора (всегда должен выставляться в 0). Немного подробнее следует описать суть параметра SkipDelete. Поскольку можно передавать данные за произвольное количество дней (но не превышающее разрешенное для импорта в системе CRM), то данным параметром регулируется – происходит ли полная очистка данных за указанный интервал по данному дистрибутору, или же данные будут загружены в дополнение к уже полученным ранее. В случае, когда параметр SkipDelete равен 0, данные в CRM удаляются, иначе – добавляются. Важно: для работы модуля в 1С версии 8 необходимо всегда выставлять этот параметр в 0.

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

- CompanyId, AddressId (Код контрагента и код торговой точки);

Единственной особенностью является то, что даже в случае совпадения кодов (то есть, если контрагент и торговая точка это один элемент справочника «Контрагенты»), необходимо заполнять оба поля.

- AddressRegionType (код типа региона);

Является атрибутом торговой точки. Имеет значение 1, если торговая точка относится к городу, 2 – если она расположена в области. В модуле для типовой конфигурации, поскольку там контрагент всегда совпадает с торговой точкой данный параметр заполнен только в одной ветке операторов Если – Тогда – КонецЕсли. Для нетиповых конфигураций необходимо провести анализ как именно будут получены коды контрагента и торговой точки и, соответственно, как получить тип региона. Значение свойства получается тем же запросом, что и документы для обработки.

- SaleChannel (Канал реализации)

Является атрибутом торговой точки. В модуле для типовой конфигурации, поскольку там контрагент всегда совпадает с торговой точкой данный параметр также заполнен только в одной ветке операторов Если – Тогда – КонецЕсли. Для нетиповых конфигураций необходимо провести анализ как именно будут получены коды контрагента и торговой точки и, соответственно, как получить тип региона. Значение свойства получается тем же запросом, что и документы для обработки.

- CRMOrderNumber (номер заказа, поступившего из «Монолит: CRM»)

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

- DocumentTypeId (тип документа)

Данный реквизит возник после того, как был запущен механизм работы с дистрибуторами-консигнаторами. Для того, чтобы контролировать остатки на складах ответственного хранения компании-поставщику необходимо отслеживать все возможные виды движения по этим складам. Поэтому была проведена доработка экспорта отгрузок и добавлен данный реквизит. Значения, которые он может принимать, приведены ниже:

- Despatch, для документа вида «Реализация»,

- VendReceipt, для документа вида «Поступление ТМЦ»,

- VendReturn, для документа вида «Возврат поставщику»,

- CustReturn, для документа вида «Возврат от покупателя»,

- ProdReceipt, для документа вида «Списание ТМЦ»,

- ProdReturn, для документа вида «Оприходование ТМЦ»,

- MovingNoteFrom, для документа вида “Перемещение ТМЦ» в части склада-источника,

- MovingNoteTo, для документа вида «Перемещение ТМЦ» в части склада-приемника.

ВАЖНО: по всем видам документов каждая строка выводится один раз и обозначает один вид движения, кроме документов «Перемещение ТМЦ», где по каждой строке необходимо указать два движения – расход со склада-источника и приход на склад-приемник.

- DocumentNumber и DocumentDate (номер и дата документа)

В эти реквизиты заносятся номер и дата экспортируемого документа.

- PayDate (предполагаемая дата оплаты)

В данный реквизит заносится предполагаемая дата оплаты. В типовой конфигурации она существует в документе «Заказ покупателя» в виде реквизита. Если данный реквизит документа не заполнен, то и поле набора данных не заполняется.

- WareHouseId (код склада)

Данный реквизит представляет собой полный код склада, с которого производилась отгрузка (или на который произошло поступление товара).

- WareId (код товара в «Монолит: CRM»)

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