click fraud detection

Типичные проблемы интеграции интернет магазина с 1С

470
0/ 5stars
0/5

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

Тогда почему же случаются ситуации, когда 1С у вас есть, сайт тоже, а результат минимальны: товары вносятся в ручную, а система подтягивает только цены и остатки? А у кого-то наоборот, получается создать полноценную экосистему из сайта, 1С и CRM. Оба примера из нашего опыта. Мы сделали некоторые выводы и хотим поделиться с вами самыми частыми проблемами, которые возникают при попытке интегрировать интернет магазин с 1С.

Содержание

  1. Отсутствие 1С программистов на стороне клиента
  2. Обмен информацией с помощью файлов вместо API
  3. Неправильная структура информации в базе клиента
  4. Интеграция после разработки сайта, а не во время
  5. Вывод

Отсутствие 1С программистов на стороне клиента

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

Еще в начале проекта мы обсуждаем все нюансы интеграции, кто за что отвечает, и как выполнять. Мы предоставляем документацию — спецификацию по обмену данными — говорим, какими данными будем обмениваться, как называются поля, как их разделять, оговариваем все моменты. Добиваемся согласия 1С программистов и надеемся на их компетенцию.

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

Обмен информацией с помощью файлов вместо API

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

Файлы обычно лежат на FTP, и если его сломать, их все можно скачать. У API работа идет через JSON запросы, и для получения информации нужен ключ — token. Сама технология http работает стабильно десятки лет, а защищенное соединение не дает злоумышленникам перехватить запросы, но даже если систему сломать, можно быстро сгенерировать новый token, передать в 1С и она будет обращаться уже с новым ключем.

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

Представим ситуацию. Допустим, обмен информацией происходит с периодичностью раз в 15 минут. На складе осталась только одна единица какого-то товара, а за эти 15 минут на нее оформили несколько заказов. Сразу возникает проблема, кому отправить, кому отказать, и как не объясняйте клиентам - ситуация неприятная. Если же обмен информацией происходит через API, любые изменения в 1С тут же приходят на сайт. И такой проблемы даже не возникнет.

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

Неправильная структура информации в базе клиента

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

Вся проблема в том, что 1С позволяет вести учет, и делать это как угодно. Нужна только номенклатура, а окружение можно строить по-разному, и это будет работать. Все можно запихнуть в один справочник. Но нужно ли?

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

Отдельно должна быть номенклатура, название, цена, бренд и так далее. Каждая характеристика - отдельно. Сюда же стоит отнести метки “распродажа”, “скидка”, “акция”... Если все это есть, то можно быстро и правильно управлять товарами, выводить акционные в отдельный раздел, реализовывать сортировки и фильтры.

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

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

А что делать с фотографиями?

Фотографии в 1С могут отсутствовать, а на сайт они нужны, и в хорошем качестве. У некоторых клиентов на старых сайтах, при обмене информацией в виде файлов, фотографии не отображаются. Мы сразу в спецификации описываем, как именно будет происходить обмен и куда загружать изображения, по ней легко все адаптировать.

Для удобства работы, мы рекомендуем назначать каждому товару уникальный идентификатор, и загружать большие качественные фотографии, подписанные им же. Если картинок несколько - нумеровать. Получается примерно так: UniqID, UniqID_1, UniqID_2 и так далее. Все они лежат в определённой папке на FTP. Когда 1С нужно загрузить или обновить изображение определенного товара, она обращается в эту папку и выгружает фото с нужным идентификатором. А дальше уже в системе мы сжимаем и обрезаем фотографии до нужных размеров, чтобы вставить в определенные блоки.

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

Интеграция после разработки сайта, а не во время

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

Мы всегда оговариваем все нюансы по поводу 1С еще на старте работ. Как только заканчиваем дизайн, сразу начинаем активное обсуждение этой темы. Первым делом делаем каталог, чтобы можно было принимать данные с 1С. Соответственно сразу есть определенные поля, под которые нужна определенная информация. Мы даем клиенту спецификацию обмена, четкое подробное ТЗ, как нужно формировать запросы на сайт. Через определенное время проводим обмен данными, и, если все друг друга поняли правильно, то сразу и выгружаем каталог на сайт. Дорабатываем мелкие детали, совершенствуем и уже в скором времени видим результат.

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

Вывод

Главное найти толковых программистов для работы с 1С. С ними мы обеспечим вам ожидаемый результат. А то и лучше. С хорошими специалистами легко найти общий язык. Бывали случаи, что мы даже учили друг друга в процессе, ведь web-разработчики не полностью знают 1С, а 1С-ники — устройство и принцип работы интернет магазинов изнутри.

Рекомендуем искать 1С программистов одновременно с запуском разработки проекта. Тогда они смогут одновременно приступить к работе и вы не потратите лишнего времени.

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

У ВАС ОСТАЛИСЬ ВОПРОСЫ?

Оставьте ваши контактные данные. Наш менеджер свяжется и проконсультирует вас.

ПОЛУЧИТЬ КОНСУЛЬТАЦИЮ

Наш менеджер свяжется с Вами в ближайшее время

0/5
Полезность
Проголосовали 0
Как вам статья?
Wezom
Wezom
Давайте начнем
беседу!
КОММЕНТАРИИ0
ОСТАВИТЬ КОММЕНТАРИЙ К СТАТЬЕ
Возможно
Эффективность ресурса YouTube в качестве маркетингового инструмента очевидна. Здесь есть большая аудитория, готовая уже сегодня…
Александр Вострецов
Александр Вострецов
Разработка интернет-магазина на онлайн рынке автомобильных шин и покрышек. Кейс о том, как создать online-market…
Wezom
Wezom
Приложения для туристов – это инструмент комфортного и эффективного взаимодействия между турагентством и путешественником.
Wezom
Wezom
ПОДПИСЫВАЙТЕСЬ НА РАССЫЛКУ АЙТЫЖБЛОГ
ХОТИТЕ ПОЛУЧАТЬ 
ИНТЕРЕСНЫЕ СТАТЬИ?
СЛЕДИТЕ ЗА НАМИ В СОЦИАЛЬНЫХ СЕТЯХ