Приветствую!

Не уверен, что пост по месту, но более подходящего раздела не нашел.

Задача этого поста собрать обратную связь по вопросу актуальности на рынке сервиса по обмену документами в 1С между контрагентами. Суть сервиса - сделать обмен документами из 1С максимально простым и легким (включая сопоставление номенклатуры) подробнее в нашем блоге на эту тему

Как вы считаете, будет востребован такой сервис?

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

Безусловно - в данном конкретном случае реализация имеет критическое значение для успеха проекта, а реализация такой нетривиальной задачи, как сопоставление номенклатуры в контексте 1С тем более.
И все же. Если принять за условие, что удалось свести данную процедуру к нажатию одной кнопки, как вы считаете, этим сервисом будут пользоваться?

А точно кнопка будет одна?
Я могу себе представить сопоставление номенклатуры след. образом: справочник, где в одной колонке ссылка на свою номенклатуру, а во второй - текст с названием этой же номенклатуры контрагента (либо вести справочник номенклатуры контрагента и по ней заполнять справочник своей в случае отсутствия), и даже представляю, что номенклатуру контрагента можно заполнять загрузкой (xml-обмен, где справочинки отдельно, документы отдельно), но проставлять ссылки по существующим записям придётся вручную. В противном случае это либо перестановки слов, коих в случае наличия 5 слов в наименовании = 5! = 120 (что скажется на быстродействии при больших объёмах обмена). Помимо этого ещё бывают сокращения типа "Конф. карам. "Раковая шейка" Рос, РотФронт" - в этом случае я не вижу корректного автоматического алгоритма сопоставления номенклатуры.

Ну и ещё: пользователи, желающие, чтоб всё делалось по одной кнопке, рискуют, что эту кнопку вынесут на стул и придавят кирпичом.

Я думаю что это сделать не удастся.
Либо придется индивидуально дописывать что то для каждого контрагента.
А это уже совсем другой порядок цены. Плюс проверять все равно придется.

Тут согласен.
У номенклатуры нет какого-то единого критерия уникальности, как скажем ИНН/КПП у контрагента.
И поэтому уникальность номенклатуры возможна только в контексте некоей договоренности между максимум 2-мя партнерами. И то очень сложно ей следовать. Поэтому это начинание нереально.
Пробовали такое замутить еще в далеком 2004 году. Не вышло.

Вы далеко не первый кто пробует такое реализовать, проблем достаточно много с синхронизацией, как быть когда номенклатуры 50-100тыр позиций ? Как быть если 20 тыр из нее покупается у разных поставщиков ? Кто это будет синхронизировать ? Как быть с вычерками в накладных? Как эта обработка будет работать с разными конфигурациями 1с ? Как вы собираетесь это поддерживать? То что вы предлагаете реализовать одной кнопкой не реально. Безусловно, есть решения где налажен обмен с поставщиками в той или иной форме, в основном через эксель, но как правило всегда у всех это индивидуально.
Резюме, как самостоятельный продукт который будет подходить всем нереально, как доп услуга которую можно предложить при обслуживании по 1с вполне себе живая идея, но тратить на нее много ресурсов чтобы получить "вундервафлю" я бы не стал.

Галинка, Naaatta, craxx - огромное спасибо! ...и особенно Beck, за резюме по существу поставленного вопроса в первом посте.

Постараюсь вкартце прокоментировать мысли участников этой темы.

Когда я предложил принять за условие, что сопоставление реализовано в "одной кнопке", я намеренно утрировал решение, дабы смоделировать идеальную реализацию сервиса. Цель проста - собрать мнения людей "в теме" об актуальности проблемы сопоставления в частности и обмена документами в общем. История знает немало примеров, когда очень близко к идеалу реализованное решение проблемы не получило отклика у целевой аудитории.

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

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

Резюме. Задача очень не проста и этим самым чертовски интересна! Но эта мысль не отвечат на вопрос ))
Будут ли использовать такой сервис при надлежащей (удачной и т.д.) его реализации?
Или другими словами. Как сильно проблема обмена документами задолбала пользователей 1С? )

Конструктив, идеи, критика приветствуются.

Таким образом каждый участник сервиса будет проходить процедуру сопоставления один раз, не зависимо от количества контрагентов

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

Система артикулов? Типа отраслевой......
Все равно это не удешевит процесс, просто перераспределит денежные потоки от операторов 1С к ТС.

у каждых поставщиков своя система артикулов, которые могут пересекаться.
поставщики импортные.
номенклатуры порядка 50000 позиций. и количество постоянно растет

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

Точно! И этот нюанс есть. Есть еще такая вещь, как "сезонная номенклатура", которая вносится в базу 1С, и через 3-6 месяцев становится неактуальной, а количество позиций "сезонки" доходит до тысяч. Как быть и в этом случае? Перспектива неоправданного разбухания и зашлаковывания глобального справочника, по меньшей мере настараживает )

Ответ: искать способ решения с минимальным вмешательством клиента в процесс добавления/изменения позиций.

На первый взгляд решение на поверхности - мержить по ходу их редактирования/добавления на стороне клиента. Это чревато полным включением клиента в процесс.
Можно синхронизировать номеклатуру на стороне сервиса по мере поступления документа с измененными/новыми позициями. Здесь не понятно кто будет делать сопоставление.
А можно подойти к реализации "глобального справочника" гибко и лишить его функции "однозначности", забить на объем баз (предприняв соответсвующие дейтсвия в реализации учитывающие нюанс размера)

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

Скажем так, реально абсолютно все, но сколько коленей нужно будет разбить чтобы прийти к этому реально ?Смысл то колени бить есть ?
Добавлю, пробуйте бейте, мы посмотримПолучится что то хорошее, возможно предложим своим клиентам

Да, типа того... "артикул" = "уникальный идентификатор" с множественными звязями

Скажем так, реально абсолютно все, но сколько коленей нужно будет разбить чтобы прийти к этому реально ?Смысл то колени бить есть ?
Добавлю, пробуйте бейте, мы посмотримПолучится что то хорошее, возможно предложим своим клиентам

Огромное спасибо за обратную связь и мнение!
Эта тема и есть один из инструментов выяснения смысла в разбитых коленях.

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

- ввести всегда проще, чем проверить и исправить введенное кем-то (ну есть такое свойство у человеческой натуры).
Если проверка потребует больше времени, чем ввод, да еще и за ввод платить....нафик-нафик такой сервис, пусть он будет самым передовым и суперкрутым.

Супер! Вы добавили нам еще один "акцент" в реализацию интерфейса на стороне 1С. Спасибо за отзыв!

Так эта......а процентик.......

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

Неее, работать я не хочу. Я хочу за ИДЕЮ процентик получать......

Тут согласен.
У номенклатуры нет какого-то единого критерия уникальности, как скажем ИНН/КПП у контрагента.
И поэтому уникальность номенклатуры возможна только в контексте некоей договоренности между максимум 2-мя партнерами. И то очень сложно ей следовать. Поэтому это начинание нереально.
Пробовали такое замутить еще в далеком 2004 году. Не вышло.

а штрихкод, например?

а штрихкод, например?

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

Неее, работать я не хочу. Я хочу за ИДЕЮ процентик получать......

а вот это уже фантастика

Это для кодировки EAN13. а есть еще куча других кодировок для штрихкодов

Задача достаточно интересная и востребованная, но только для крупных компаний, обладающих своими ИТ отделами, которые решают данную проблему (либо подстраивается поставщик, либо подстраивается покупатель - кто больше тот и прав, как правило). Тот кто "не прав" ведет в своем справочнике номенклатурном код своего товара и код товара контрагента и подстраивается под форматы того, кто "прав".

Есть сервисы по обмену документами (фактурами) которые действуют уже на данный момент и предоставляют описанную вами услугу. (например Корус консалт система EDI представляет такие сервисы, но сами они естественно не ведут номенклатурные справочники (сопоставление номенклатуры - проблема контрагентов, решаемая в их системах между собой).

по привязке к штриховым кодам - смысл полностью отсутствует. Кроме EAN особого распространения не получил другой тип штрихового кода, а по ЕАН есть нюанс - диапазоны номеров выкупаются и за них ежегодно платится денежка. Платить перестал - диапазон не твой (конечно это будет лаг во времени 3-5 лет, но есть товары и с таким сроком жизни).

У проблемы сопоставления номенклатурных справочников есть много подводных камней, которые не могут быть решены стандартизацией (стандарты в каждой Компании свои вплоть до неодносначного соответствия номенклатуры одной компании - номенклатуре другой (Например в продуктах - у компании продавца - номенклатура более детализирована (сырок серый, сырок белый, сырок синий) а у компании покупателя просто - сырок в ассортименте и все. И вы не заставите покупателя завести у себя в справочнике 10 наименований вместо одного, потому что у нее 100 магазинов и номенклатура при таком подходе распухнет в несколько раз...

В таких проектах для успешной их реализации нужны якорные заказчики. Когда им будет интересно и они заплатят за разработку сервиса - тогда есть вероятность, что сервис будет интересен многим при его "допиливании" и стандартизации. Без этого проект на 0 стадии обречен на лишние, никому не нужные трудозатраты.

У меня нет слов, что бы точно выразить свою благодарность за этот пост... не буду придумывать. Большое спасибо!

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

Мне кажется, я что-то упустил, но не пойму что именно. Прокомментируйте пожалуйста.
Еще раз спасибо за пост!

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

ммм... получается, что первое рпедположение о востребованности у крупных игроков, еще не говорит о применении сервиса массово.
Другими словами, все-таки не факт, что сервис востребован )) Так?

Я же высказала свое мнение, да и не только я.....
Сделать одной кнопкой, правильно и дешевле, чем стоит оператор - маловероятно.
Это больше индивидуальная вещь. ИМХО.
Тем более проект еще не реализован и никто не может предсказать результат - даже вы.

1. Как я уже отметил - сервис востребован, но востребован Крупными компаниями со СВОИМИ ИТ ОТДЕЛАМИ
2. задача сопоставления номенклатуры решается индивидуально. Решение задачи обусловлено сокращением трудозатрат со стороны "Правого " контрагента, при этом трудозатраты второго контрагента в расчет не берутся. (посмотрите пример работы с поставщиками таких компаний как Лента).
3. Доработки программного обеспечения при наличии своего ИТ отдела (пусть состоящего из 1-го разработчика) задача не сложная и будет решена с трудозатратами по разработке за 1- 5 часов.


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

Оптимальный вариант для вас - это взять большую компанию и для нее разработать сервис, впоследствии подключая к этому сервису мелких поставщиков, у которых нет возможности/желания допилить свою 1с-ку и брать свои % за предоставляемый сервис. При этом на начальном этапе в качестве того, кому это может понадобиться может выступить небольшая компания (желательно производитель чего либо), которая впринципе может поставлять продукцию в ту же Ленту, МЕТРО, Ашан (или кого вы там выберете), но не связывается с этим из за условий поставки т.к. не хотят заморачиваться с оформлением документов и сопровождением (таких поставщиков много, но их придется поискать хорошенько т.к. если бы они этого хотели то двигались в этом направлении, а т.к. не двигаются (и это ваш клиент) то явной заинтересованности не проявляют.) Деньги на стартапе не поднимите большие(вам главное заказчик, на основании которого вы получите все требования для работы), но выбрав правильную политику и объединив в возможности системы поставки для нескольких крупных торговых сетей сможете постепенно отбить трудозатраты и выйти в плюс.

Ритеил выбран как наиболее массовый сектор с высокой конкуренцией и развитием ИТ. В другие сектора лезть смысла особого нет в связи с корпоративными особенностями таких поставок (там рынок b2b и на стартапе без денежки и не являясь реальным поставщиком вы туда не пролезите)

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

Хм, чёто я не понял, студенты прикалываются чтоли?
Во первых о какой конфигурации 1С идёт речь?
Во вторых чем не устраивает то что уже есть в 1С?

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

как это оформить - думайте сами. от этого будущее вашего прожекта зависит ))

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