Наверх

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

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

Предлагаю поговорить о синхронизации справочников в рамках межкорпоративного документооборота (все-таки МЭДО). Как сделать так, чтобы справочники разных систем «понимали» друг друга.

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

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

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

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

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

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 10

Евгений Кочуров 29 октября 2013

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

Отредактировано 29 октября 2013
Михаил Романов 29 октября 2013
Но вопрос в том, есть ли универсальное решение, которое устроит всех?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы прокомментировать, или зарегистрируйтесь