1С:Предприятие 8
Система программ

CommerceML EDI

Стандарт CommerceML EDI описывает документы основных бизнес-процессов взаимодействия сетевых операторов и их поставщиков, рекомендованные к применению межрегиональной общественной организацией «Стандартизация обмена деловой информацией».

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

В течение нескольких месяцев совместной работы специалистов компаний ТД «Перекресток», ТД «Копейка», «Седьмой континент», фирма «1С», холдинг «Марта» (сеть универсамов SPAR, «Столица»), ООО «Юнимилк», «Actis Systems» и ряда других крупных компаний были созданы стандарты основных бизнес-процессов взаимодействия участников рынка розницы.

XML-схемы стандарта CommerceML EDI включают:
  • набор повторяющихся деклараций, которые вынесены в файл cml-common3.0sodi.xsd;
  • файлы с XML-схемами документов конкретных бизнес-процессов.

Обмен данными о товаре

Стандарт описывает взаимодействие торговой розничной сети (клиента) и поставщика при предоставлении поставщиком информации о своих товарах.

Участники процесса обязаны сохранять неизменным собственный идентификатор товара на протяжении всего времени взаимодействия компаний.

Процесс взаимодействия можно представить следующей диаграммой:

CommerceML EDI

Описание процесса

Процесс обмена данными о товаре инициируется в двух случаях:
  • Процесс инициируется клиентом при возникновении у него необходимости получения каталога товаров поставщика. В этом случае клиент формирует документ «Запрос на каталог товаров» и отправляет его электронную версию поставщику.
  • Процесс инициируется поставщиком в случае, если в каталоге товаров поставщика произошли изменения, о которых необходимо сообщить клиенту.
Поставщик формирует документ, в котором содержится полный перечень предлагаемых им данному клиенту товаров и следующих его обязательных свойств:
  • Идентификатор товара в кодировке поставщика;
  • Идентификатор товара в кодировке клиента;
  • Штрих-коды единицы товара;
  • Название товара у поставщика;
  • Единица измерения товара ОКЕИ;
  • Код товара по классификации ОКП;
  • Код товара по классификации ОКВЭД;
  • Произвольное описание товара, включающее в себя свойства, отличающие товар от другого.
Дополнительно документ может содержать следующие необязательные для разных групп товаров атрибуты:
  • Название торговой марки;
  • Вес нетто;
  • Вес брутто;
  • Объем в м3;
  • Количество товара в упаковке нижнего уровня;
  • Минимальное количество товара к поставке;
  • Производитель товара;
  • Страна происхождения товара;
  • Высота товара;
  • Количество товара в одном слое на стандартной евро-паллете (1200×800);
  • Срок хранения товара с момента его изготовления в днях;
  • Оптимальная температура хранения в градусах Цельсия;
  • Вид упаковки (пл. бут, жел. банка, стекло, пакет-слим и т. д.)
  • Вид оболочки для колбасных изд (белкозин, аметан, целлофан, синюга и т. д.)
  • В случае, если набор, то перечислить весь список из набора (кондитерский или парфюмерный набор)

Электронный документ передается в информационную систему клиента, где производится его обработка, в результате которой формируется  «Список принятых к работе товаров», содержащий перечень товаров из ассортимента поставщика, с которыми согласен работать клиент.

Список принятых к работе товаров в электронном виде передается в информационную систему поставщика. Список содержит коды и наименования товаров у клиента, коэффициент пересчета (отношение учетной единицы измерения поставщика к учетной единице измерения клиента).

Обмен коммерческими предложениями

Стандарт описывает процесс взаимодействия торговой розничной сети (клиента) и поставщика при передаче информации о цене предлагаемых товаров или услуг поставщиком.

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

Процесс взаимодействия можно представить следующей диаграммой:

CommerceML EDI

Описание процесса

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

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

Прайс-лист передается клиенту в электронном виде.

Заказ товара, акцепт заказа

Стандарт описывает процесс взаимодействия торговой розничной сети (клиента) и поставщика при осуществлении заказа товара клиентом и акцепта заказа товара поставщиком.

Процесс взаимодействия можно представить следующей диаграммой:

CommerceML EDI

Описание процесса

Процесс взаимодействия клиента и поставщика при осуществлении заказа инициирует клиент, в заранее согласованный клиентом и поставщиком момент времени. В информационной системе клиента формируется заказ на товар и формируется электронный документ, содержащий сведения об этом заказе:
  • уникальный номер заказа;
  • дата поставки товара по заказу;
  • состав, количество и цены заказанного товара.
Электронный документ передается в информационную систему поставщика. Поставщик, получив заказ клиента, исходя из собственных возможностей и договорных отношений между клиентом и поставщиком принимает решение о полноте возможного выполнения заказа клиента. В случае если поставщик согласен выполнить заказ клиента в полном объеме по указанным клиентам ценам, в указанном количестве на указанную дату поставки, формируется документ, подтверждающий выполнение заказа в полном объеме и с выполнением указанных условий поставки — «Акцепт заказа». Формируется электронный документ, содержащий сведения о данном акцепте:
  • номер документа «Акцепт заказа»;
  • номер акцептованного заказа клиента.

Электронный документ передается в информационную систему клиента.

После получения акцепта заказа клиентом процедура «заказ товара, акцепт заказа» считается успешно завершенной.

В случае если поставщик не может выполнить заказ клиента в полном объеме, или у поставщика имеются претензии к указанным в заказе условиям поставки, формируется документ, содержащий сведения о возможностях поставщика по выполнению заказа на указанную дату поставки — «Реджект заказа». Документ так же может содержать сведения о превышении клиентом лимита по предоставляемому ему поставщиком кредиту и другие данные:
  • номер документа «Реджект заказа»;
  • номер заказа клиента;
  • состав, количество и цены товара, который возможно поставить по заказу клиента;
  • сведения о кредитном лимите клиента;

Электронный документ передается в информационную систему клиента.

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

Поставка товара

Основной задачей процесса является качественная приемка товара от Поставщика в соответствии с акцептованным заказом товара.

Процесс взаимодействия можно представить следующей диаграммой:

CommerceML EDI

Описание процесса

Процесс начинается после получения Клиентом акцептованного заказа.

Поставщик формирует электронную накладную, которая передается в информационную систему Клиента не позднее, чем  дата поставки товара.

При поставке товара Клиент осуществляет проверку соответствия накладной (и электронной, и бумажной) акцептованному заказу по номеру заказа, итоговому количеству и итоговой сумме. А также сопроводительных документов.

Результатом проверки является одно из следующих событий:

1. Документы не соответствуют. Далее выполняются функции и соответствующие события: Сформировать «Реджект» накладной, «Реджект» сформирован, Передача «Реджекта» в информационную систему Поставщика, «Реджект» передан Поставщику, Отказ от приемки товара, Товар не принят.

«Реджект» содержит:
  • номер неакцептованной накладной;
  • номер акцептованного заказа.
2. Документы соответствуют в пределах договорных отношений. Далее товар разделяется на:
  • товар с соответствующими документами, который далее принимается по количеству и качеству;
  • товар с несоответствующими документами, на который Поставщик и Клиент исправляют документы, далее выполняется функция «Приемка товара по количеству и качеству».

В результате выполнения функции «Приемка товара по количеству и качеству» возможно наступление двух событий:

1. Товар принимается по количеству, качеству и цене. Далее выполняется функция формирование акцепта накладной, в результате выполнения которой формируется электронный документ, содержащий сведения об акцепте накладной:
  • номер акцептованной накладной;
  • номер акцептованного заказа.

Электронный документ передается в информационную систему Поставщика. Товар считается принятым Клиентом.

2. Товар не принимается по количеству, качеству или цене. Далее выполняются функции и соответствующие события: Сформировать «Реджект накладной», «Реджект» сформирован, Передача «Реджекта» в информационную систему Поставщика, «Реджект» передан Поставщику, Отказ от приемки товара, Товар не принят.

Обмен данными об остатках товара и продаваемости

Стандарт описывает процесс взаимодействия клиента и поставщика при предоставлении клиентом поставщику информации об остатках и продаваемости товаров поставщика.

 Процесс взаимодействия можно представить следующей диаграммой:

CommerceML EDI

Описание процесса

Информация об остатках и продаваемости товаров у клиентов может использоваться поставщиком для планирования производства и уровня своих запасов.

Процесс обмена данными о доступности товаров инициируется в двух случаях:

1. Процесс инициируется поставщиком при возникновении у него необходимости получения информации об остатках и продаваемости своих товаров. В этом случае поставщик формирует документ «Запрос информации об остатках и продаваемости товаров» и отправляет его электронную версию клиенту.

2. Процесс регулярно инициируется клиентом в заранее оговоренные с поставщиком моменты времени.

Клиент формирует документ, в котором содержится перечень товаров поставщика и данные об их количествах и продаваемости. Документ в электронном виде передается в информационную систему поставщика.

Обмен информацией о доступности товаров

Стандарт описывает процесс взаимодействия клиента и поставщика при предоставлении поставщиком клиенту информации о доступности своих товаров.

Процесс взаимодействия можно представить следующей диаграммой:

CommerceML EDI

Описание процесса

Информация о доступности товаров — информация о том, какие товары и в каком количестве доступны к заказу данным клиентом у данного поставщика.

Процесс обмена данными о доступности товаров инициируется в двух случаях:

1. Процесс инициируется клиентом при возникновении у него необходимости получения информации о доступности товаров поставщика. В этом случае клиент формирует документ «Запрос информации о доступности товаров» и отправляет его электронную версию поставщику.

2. Процесс регулярно инициируется поставщиком в заранее оговоренные с клиентом моменты времени.

Поставщик формирует документ, в котором содержится полный перечень доступных к заказу клиентом товаров и их количеств. Документ в электронном виде передается в информационную систему клиента.

Передача счетов-фактур

Основной задачей процесса является получение счета-фактуры от Поставщика, соответствующего ранее акцептованной Клиентом накладной (накладных в случае непрерывных поставок) на поставку товара.

CommerceML EDI

Описание процесса

Процесс начинается после получения Поставщиком акцепта накладной на поставленный Клиенту товар или после получения акцепта последней накладной из непрерывной поставки.

Поставщик формирует счет-фактуру, который должен по позиционно соответствовать акцепту накладной (накладных) с учетом сделанных изменений по факту приемки. После чего счет-фактура в бумажной и  электронной форме передается Клиенту в течение 5-ти дней от даты акцепта накладной (последней накладной из непрерывной поставки) на поставку товара.

После поступления счета-фактуры Клиент осуществляет проверку соответствия счета-фактуры (и электронной, и бумажной) акцептованной накладной (накладным) по номеру (номерам) накладной (накладных), по итоговой сумме налогов, по итоговой сумме. Кроме того, осуществляется проверка счета-фактуры по каждой позиции по количеству, ставке налога, сумме налога, сумме позиции.

Результатом проверки является одно из следующих событий:

1. Документы соответствуют в пределах договорных отношений.

При этом далее выполняются функции и соответствующие события: Сформировать Акцепт счета-фактуры, Акцепт сформирован, Передача Акцепт Поставщику, Акцепт передан Поставщику.

Акцепт содержит:
  • номер неакцептованного счета-фактуры;
  • номер (номера) акцептованного (акцептованных) накладных.

2. Документы не соответствуют. Далее выполняются функции и соответствующие события: Сформировать Реджект счета-фактуры, Реджект сформирован, Передача Реджекта Поставщику, Реджект передан Поставщику.

Реджект содержит:
  • номер неакцептованного счета-фактуры;
  • номер (номера) акцептованного (акцептованных) накладных.

Бизнес-процесс «Создание актов сверки, взаиморасчеты»

Основной задачей процесса является сверка взаиморасчетов между клиентом и поставщиком.

CommerceML EDI

Описание процесса

Процесс может начинаться одним и/или другим из нижеперечисленных событий:
  • за определенный/установленный в финансово-хозяйственной деятельности компании/согласованный между клиентом и поставщиком/указанный в договоре отчетный период;
  • при условии закрытия договора-контракта.

Инициатором процесса может являться и клиент, и поставщик.

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

Пример отчета     

Данные инициатора — черные цифры

Данные Контрагента — красные цифры

Акт сверки — черные и красные совместно 

Дата Операция/Документ По данным Инициатора По данным Контрагента
Дебет Кредит Дебет Кредит
Сальдо на 01\01\07    0 0 0 0
1   поступление товара сч\фактура от 10.01.07 № 1   200  200  
2   оплата товара платежное поручение № 1 от 11.01.07 (включая НДС) 60     60
Оборот 60 200 200  
Сальдо на 01\02\07   140 140  

Электронный документ передается в ИС Контрагента, после чего Контрагент формирует свои данные по поставкам и платежам. После формирования данных Контрагент заполняет графы в Акте сверки По данным Контрагента.  Тем самым заканчивается формирование Акта сверки. 

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

 Далее Контрагент формирует в ИС электронный Акцепт Акта сверки и отправляет его в ИС Инициатора — процесс завершен, стороны согласовали взаиморасчеты, либо, в случае некорректного с точки зрения Контрагента Акта, Контрагент формирует в ИС Реджект Акта сверки, в котором указывает номер отвергнутого акта сверки. 

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

Обмен данными о товарных сертификатах

Стандарт описывает процесс взаимодействия клиента и поставщика при предоставлении поставщиком клиенту данных о товарных сертификатах.

CommerceML EDI

Описание процесса

Данные о товарных сертификатах — данные о товарных сертификатах выданных государственными сертифицирующими органами на товары, поставляемые поставщиком. Данные о товарных сертификатах содержат сведения о:
  • учетном номере сертификата;
  • органах, выдавших сертификат;
  • дате выдачи сертификата;
  • дате окончания действия сертификата.

Процесс обмена данными о товарных сертификатах инициируется в случаях:

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

2. Процесс инициируется поставщиком в момент предоставления им данных о поставке товаров клиенту.

3. Процесс инициируется поставщиком в момент предоставления им данных о товаре.

Поставщик формирует документ, в котором содержится полный перечень сертификатов на соответствующие инициирующему случаю товары. Данные о товарных сертификатах в электронном виде передаются в информационную систему клиента.