Журнал о системах электронного документооборота (СЭД)
Электронные документы и обмен ими (ЮЗЭД)

Как подружить справочники информационных систем контрагентов?

  10 комментариев Добавить в закладки

Предлагаю поговорить о синхронизации справочников в рамках межкорпоративного документооборота (все-таки МЭДО). У многих контрагентов своя информационная система (ИС), с которой они интегрируют внешний документооборот. Получается, что сервис МЭДО является интеграционным посредником между корпоративными ИС различных компаний, объединяет их в единую сеть. И важный вопрос, всегда возникающий при интеграции - как сделать так, чтобы справочники разных систем «понимали» друг друга.

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

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

Как это сделать? Решений достаточно много, и в настоящей ситуации реализация полной синхронизации справочных данных у различных контрагентов маловероятна. К примеру, можно постоянно обмениваться прайсами и справочными данными. Периодически соотносить товарные позиции по артикулу или наименованию и вести соотношение своей номенклатуры и номенклатуры контрагентов. Можно посмотреть, как делают в EDI – использование так называемых мастер данных.

Все это в разной степени эффективно и доступно. Думаю, ИТ-специалисты смогут предложить еще несколько вариантов. Но вопрос в том, есть ли универсальное решение, которое устроит всех? Знаете ли вы о таком? Сталкивались ли вы с подобными задачами у себя на практике?

Ещё материалы автора
Похожие записи
Комментарии (10)
Евгений Кочуров 29 октября 2013 г. 16:12  

Универсальные решения в сфере MDM очень дороги во внедрении и сопровождении (даже если жадность поставщика оставить за скобками), так что устраивать всех не могут по определению.

Михаил Романов 29 октября 2013 г. 16:23  
Но вопрос в том, есть ли универсальное решение, которое устроит всех?

Основная беда в этих задачах - договориться кто будет управлять справочниками, т.е. регламент. А технических решений большей или меньшей степени готовности - море.

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

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

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

Всевозможные варианты систем мастер-данных (из тех, о которых мне доводилось читать) это некоторое решение, слегка решающее проблему, точнее оставлюящую её за рамками системы обмена: у вас есть стандартизованное хранилище справочников, которое кем-то обслуживается (как правило ни о каком произвольном внесении данных участниками обмена речь не идет!). Каждая участвующая в обмене система должна уметь приводить свои классификаторы в соответсвие со справочниками в центральном хранилище - как это она делает, забота каждого участника обмена.

Сергей Бушмелев 29 октября 2013 г. 17:06  
Вот, например, гипотетическая ситуация, основанная на реальных событиях. Продавец отправляет покупателю партию резиновых сапог вместе с электронными первичными документами. Покупателю важно максимально быстро зафиксировать поступление, не зацикливаясь на документообороте. Но в накладной продавца наименование товара «сапоги резиновые», а в справочнике товарной номенклатуры принимающей стороны – «сапоги рез.» - и никак иначе! Получается, что покупатель не может занести информацию о поступлении в систему в том виде, в котором он ее получил, придется сверять позиции «ручками». Это серьезный дискомфорт, даже без учета, что таких сверок может быть сотни только за одну приемку товара.
Можно посмотреть, как делают в EDI – использование так называемых мастер данных.

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

 

Конечно, ничего не мешает это сделать на уровне МЭДО, но тогда придется реализовывать кучу всего, что уже десятилетиями практикуется  в EDI (заказы, подтверждения заказов, подтверждения отгрузки, подтверждение получения товара, инвойсы и т.п.). Плюс надо будет создать надотраслевую организацию, которая выдает GTIN и GLN (или их аналоги). Более того, "юридическая значимость" в терминах отечественного права нужна не для всех документов, а только для итоговых (Торг-12 и ЭСФ).  Учитывая растущую глобализацию, необходимость разработки каких-то моделей, альтернативных EDI, мне видится крайне сомнительной :)

Сергей Бушмелев 29 октября 2013 г. 17:14  
Получается, что покупатель не может занести информацию о поступлении в систему в том виде, в котором он ее получил, придется сверять позиции «ручками». Это серьезный дискомфорт, даже без учета, что таких сверок может быть сотни только за одну приемку товара.

Есть альтернатива: поставщик по EDI отправляет торговой сети подтверждение отгрузки, в котором есть вся информация о содержимом отправляемого транспортного средства. Товаровед заносит эту информацию в сканер, и когда транспортное средство приходит, товаровед быстренько "чикает" сканером штрих-коды на упаковках. По результатам сверки автоматом формируется подтверждение приемки. И никакой магии :)

Иван Агапов 29 октября 2013 г. 17:42  
Сейчас имеет место бум EDI, и к этой технологии подключаются даже региональные сети и их поставщики (включая ИП-шников).

На счёт бума EDI в РФ, на мой взгляд, рано говорить, он есть в Ритейле (особенно в продуктовом), но в других областях его либо нет либо совсем чуть-чуть. Достаточно посмотреть на список компаний участников ECR-rus http://ecr-all.org/russia/members. В УР EDI используют также только торговые сети (Ижтрейдинг, Айкай и др.) и их поставщики. А потребность в решении аналогичных задач есть и разные компании идут по разному пути, например, часто для этого создают специальные сайты заказов и взаимодействия с клиентами, обмениваются прайсами и т.п. (встречал такие примеры в оптовой торговле автозапчастей и фармпрепаратами). Часть компаний решили данные задачи по своему, а в EDI всё-таки свои форматы и протоколы обмена.

Ещё с учётом того, что для ФНС нужны свои форматы документов, хоть и только некоторых из общей цепочки заказа и поставки товара.

То вопрос параллельного использования EDI для решения другой части не закрытых задач становится не таким уж и очевидным, хотя, соглашусь - самым заманчивым :)

В итоге всё решит рынок - вероятно будут появляться какие-то удобные гибриды систем, которые и легитимность ЭД обеспечат и необходимые структурированные бизнес-данные смогут передавать.

 

 

 

 

Иван Агапов 29 октября 2013 г. 17:46  
Есть альтернатива: поставщик по EDI отправляет торговой сети

Ага, это у тех кто пользует EDI. А у всех остальных пока либо что-то своё (xls файлики) либо ручками, если процесс не очень критичен с точки зрения скорости обработки.

 

Сергей Бушмелев 29 октября 2013 г. 18:14  
Ещё с учётом того, что для ФНС нужны свои форматы документов, хоть и только некоторых из общей цепочки заказа и поставки товара. 


Одним из самых распространенных сценариев является формирование ТОРГ-12 и ЭСФ из информации,содержащащейся в итоговом инвойсе. Это производится автоматически при интеграции EDI и МЭДО систем.

На счёт бума EDI в РФ, на мой взгляд, рано говорить, он есть в Ритейле (особенно в продуктовом), но в других областях его либо нет либо совсем чуть-чуть. 


Учитывая, какими темпами в РФ загибается промышленность и развивается торговля, я бы сказал, что сфера применения EDI расширяется более, чем стремительно... Шутка, хоть и есть в ней доля правды. Технологии EDI долгое время топтались на месте, однако сейчас там наметилось какое-то движение, соответственно, технологии могут выйти за пределы ритейла. Чтобы убедиться, что EDI - это не только ритейл, советую глянуть список стандартных сообщений.

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

 

А потребность в решении аналогичных задач есть и разные компании идут по разному пути, например, часто для этого создают специальные сайты заказов и взаимодействия с клиентами, обмениваются прайсами и т.п. (встречал такие примеры в оптовой торговле автозапчастей и фармпрепаратами). Часть компаний решили данные задачи по своему, а в EDI всё-таки свои форматы и протоколы обмена.

Изначально в посте говорилось только про сапоги ;)

Сергей Бушмелев 29 октября 2013 г. 18:17  
либо ручками, если процесс не очень критичен с точки зрения скорости обработки. 

Тогда есть вероятность, что в этом случае ЛЮБАЯ автоматизация будет дороже, чем сохранение ручной обработки :)

 

 

Иван Агапов 30 октября 2013 г. 10:29  
Одним из самых распространенных сценариев является формирование ТОРГ-12 и ЭСФ из информации,содержащащейся в итоговом инвойсе.

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

Ещё в этой ситуации получается, что это интеграция 2-х разных систем со всеми вытекающими возможными трудностями, подписывать документы мне предлагается в другой системе, точек взаимодействия EDI и межкорпоративных ЭДО систем также может быть больше, чем просто сформировать ЭСФ на основании invoic, будет ещё и обработка расхождений и прочие нюансы. Хочется всё это пощупать в живую под нагрузкой, а не просто увидеть на картинке презентации одной из компаний Ритейла :)

 

 

Сергей Бушмелев 30 октября 2013 г. 11:34  
интеграция 2-х разных систем со всеми вытекающими возможными трудностями 

Если услуги EDI и МЭДО предлагает один оператор, то эта интеграция уже доступна в базовом варианте. Когда операторы разные, могут быть сложности, но они решаемы.

Хочется всё это пощупать в живую под нагрузкой 

Нет проблем, если представляешь торговую сеть или поставщика :)

будет ещё и обработка расхождений и прочие нюансы 

Для большинства клиентов EDI сетей транзакция заканчивается в момент получения INVOIC. Хотя да, есть клиенты, которые потом еще согласуют INVOIC. Что же касается пересортицы, недостачи, боя, усушки, утруски, то такие расхождения разрешаются раньше, на этапе получения DESADV и RECADV. Ты все это хорошо представляешь, остальным же могу порекомендовать глянуть сюда http://www.gs1ru.org/technologies/exchange/. GS1 - организация, которая выдает коды товаров GTIN и коды контрагентов GLN.

а в случае других компаний (у которых нет EDI) это не видится таким логичным 

Согласен, просто пример с сапогами (товар народного потребления, не собственного производства, не весовой) в исходном посте, а также упоминание поставщика и покупателя навело на мысль, что данную задачу лучше решать при помощи EDI. По поводу операторов МЭДО и структурированных данных задумываю грандиозный пост-статью :)

 

 

Сейчас обсуждают
Больше комментариев