Проблема № 1 - квалификация программиста.
Тут на стыке - тех, кто разбирается и в вебе и в 1С - единицы.
На самом деле могут 2 программиста делать - со стороны сайта один, со стороны 1С другой.
Им был только способ взаимодействия по данным согласовать.
Но фактически работа ничем особенным не сложная, типовая вполне себе.
Делал я такую интеграцию неоднократно...
Проблема № 2 - стоимость работ.
Что бы я там не писал, что работа "обычная".
Это не означает, что обойдется она в копейки.
Это или 2 программиста - один с веба, другой с 1С.
Или 1 программист, но более квалифицированный.
Проблема №3
Возникают дополнительно еще некоторые админовские задачи - ведь если список товаров с ценами вы еще легко передадите практически любым способом (да хоть POST-запрос), то с картинками все не так просто.
В моем случае использовалась кастомная синхронизация в облако по протоколам S3, OpenSwift. Это не столько администрирование, сколько просто создать аккаунт.
И есть вариант с синхронизацией по Syncthing. А это нужно установить и настроить Syncthing на двух серверах (на веб-сервере и на сервере 1С).
Проблема № 4. Нужно четко представлять а что вы вообще собираетесь делать?
Нужна ли синхронизация в одном направлении (на сайт из 1С товары и цены)?
Или и обратно тоже (с сайта в 1С заказы)
Разовая ли эта синхронизация или на постоянной основе? Насколько оперативно должно происходить? Как уведомлять одну систему, что другая отправила ей данные?
Соответствует ли каталог товаров в 1С тому, что будет на сайте (часто фирмы упрощают под себя список товаров в 1С - все равно клиенту по барабану, а менеджерам фирмы работать с таким список удобно). Но если будет выгружаться "один-в-один" на сайт, то невнятная иерархия товаров и/или невнятные названия товаров - большая проблема. Захотят ли переделать в 1С так чтобы на сайте было удобно? В моем случае сочли более эффективным оставить для внутренней работы иерархию как она была в 1С и делать вторую альтернативную иерархию для веб-сайта. Хорошо хоть названия товаров нормальные.
А как будет отрабатывать веб сайт массовую загрузку товаров (ну например, каждые полчаса весь прайс-лист с товарами заново загружать, чтобы остатки и цены были оперативны), не будет ли это влиять на обычных посетителей сайта? Мы это специально решали - товары и цены выгружаются редко, а остатки другим файлом (компактным) - быстро. Что позволило обновлять остатки хоть раз в 5 минут. Полный прайс лист с названиями и ценами на сотни тысяч товаров загружать так часто затруднительно. Да и не нужно.
А что будет если приедет из 1С на сайт товар А, Б, В, но после этого всегда будет приезжать товар Б, В. Из 1С информация о товаре А никогда не будет поступать более (так как товар А более не закупают). Товар А будет болтаться на сайте вечно? В каком состоянии, с остатками или без, с какой ценой?
Будут ли бонусы покупателям на сайте? А как сделать так чтобы использовав свои бонусы в на сайте их нельзя было повторно использовать на сайте. И наоборот.
Как идентифицировать покупателя на сайте (для бонусов это важно), чтобы он был однозначно связан с покупателем в 1С. Тут отдельная проблема - товар, как правило создается только в 1 месте, в 1С. И едет всегда только в одном направлении - на сайт. А вот новые покупатели могут создаваться и там и там. Как эти две системы поймут, что речь идет об одном и том же покупателе при двойной его регистрации?
Будут ли вручную после загрузки корректировать товар на веб-сайте и не будет ли новые загрузки эти изменения перетерать? Или все корректировки будут делаться только в 1С?
Готовы ли для этого в 1С внести структуры хранения данных которые нужны только для сайта?
А что если нужно организовать очень оперативную выгрузку обновлений, но каталог огромен? Значит нужна выгрузка частичная. А чтобы 1С могла отслеживать что выгружено из уже измененного, а что нет - нужны дополнительные структуры данных в БД 1С.
Есть отдельная организационная проблема, когда все структуры внутри 1С хотят оставить без изменений. Тогда все нужны поля нужно хранить в очень неудобных вспомогательных структурах данных. Это решаемо, хоть и неудобно. Если вы делаете не под конкретное предприятие, а универсальную систему с целью многократной продажи и внедрения на разные предприятия - придется идти этим путем.
И т.п. и пр.
Сложный
