Поддержка сайта
на Битриксе
в Санкт-Петербурге

1С-Битрикс — стандарт корпоративных и интернет-магазинов в России. Полная локализация под российский рынок — НДС, документооборот, 54-ФЗ, маркировка Честный знак, ЕГАИС. Глубокая интеграция с 1С. Платная коммерческая поддержка. Большая экосистема разработчиков в России, включая северо-западный регион. Для крупных петербургских ритейлеров (Лента, ВкусВилл) и торговых компаний выбор обычно очевиден.

Полный спектр. Корпоративные сайты на «Стандарт», «Малый бизнес», «Бизнес». Интернет-магазины на «Малый бизнес» и «Бизнес». Крупные интернет-магазины на «Бизнес» и «Энтерпрайз» с десятками тысяч SKU. Корпоративные порталы (Bitrix24). B2B-платформы для оптовых клиентов петербургской промышленности. Сайты с интеграцией в комплексные торговые системы.

Да, это типовая часть работы. Интеграция Битрикс-1С — бесшовный обмен между сайтом и учетной системой. Стандартные сценарии: выгрузка каталога из 1С на сайт, загрузка заказов в 1С, двусторонний обмен статусами, обмен документами. Реализуется через CommerceML, REST API 1С, либо прямое подключение к базе. Учитываем конфигурацию 1С клиента (УТ, ERP, КА), типичную для петербургской металлургии, машиностроения, торговли.

Да. Битрикс выпускает несколько обновлений в год. Регламент: бэкап до обновления, применение на staging, функциональное тестирование, обновление на production с минимальным простоем, постмортум. Особенность Битрикс — обновления крупных версий иногда требуют изменений в кастомизациях.

Да, для интернет-магазинов на Битриксе это типовая задача. Интеграция с Wildberries, Ozon, Яндекс.Маркет, Авито. Синхронизируется: каталог товаров, цены, остатки, заказы, статусы, контент карточек. Используем готовые модули из Маркетплейс Битрикса и кастомные доработки.

Да, для всех интернет-магазинов это обязательная часть. Все интернет-продажи фискализируются через онлайн-кассу. Для интернет-магазинов используются облачные кассы (АТОЛ Онлайн, КОНТУР Касса Онлайн, Эвотор Облако). В Битриксе настраиваем интеграцию через стандартные модули или кастомные доработки.

Да. Типовые сценарии миграции на Битрикс: с самописных CMS, Joomla, Drupal, WordPress + WooCommerce, устаревших версий Битрикса, зарубежных платформ (Shopify, Magento). Миграция — серьезный проект: анализ, перенос данных, настройка обмена с 1С, тестирование, переключение DNS, контроль SEO, сопровождение в первые недели.

Базовая поддержка (для корпоративного сайта или небольшого интернет-магазина) — для малого и среднего бизнеса. Стандартная (для среднего интернет-магазина с активной торговлей и 1С-интеграцией) — для среднего бизнеса. Расширенная (для крупного интернет-магазина с большим каталогом, маркетплейсами, сложными интеграциями) — для крупного бизнеса. Премиум (для очень крупных проектов) — для крупных петербургских компаний и федеральных торговых сетей. Помимо разработки в стоимость входит продление лицензии Битрикс (~30% от стоимости лицензии ежегодно).

Только удалённо. Это касается не только текущей поддержки, но и запуска новых проектов с нуля. Настройка сервера, перенос базы, интеграции с внешними сервисами — всё делается через SSH, панель хостинга и тестовый контур без физического присутствия. Общение с командой клиента идёт через задачи и звонки с записью экрана. Часовой пояс совпадает. Рабочее окно пересекается полностью, без сдвигов по времени ответа.

Ориентир — сценарии использования, а не только число товаров. Нужен API для мобильного приложения, несколько складов с раздельными остатками или сложная структура прав доступа по отделам? «Стандарта» уже не хватает функционально, независимо от размера каталога. Каталог просто вырос количественно, а сценарии простые? Иногда достаточно оптимизации базы и кэша без смены редакции вообще. Сначала считаем задачу, потом стоимость апгрейда.

Для короткой серии мелких правок в течение недели обновлять тест перед каждой из них не обязательно. База и так близка к боевой. Обязательно обновляем контур перед задачами, которые зависят от актуальных данных: миграцией цен, проверкой сложного отчёта, интеграцией с внешним сервисом по реальным ключам. Устаревший тест иногда даёт ложное ощущение, что всё работает, хотя на бою уже другая структура каталога.

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

Да, и это оправдано, если у компании счета в разных банках или нужен резервный канал на случай сбоя одного из провайдеров. Покупатель на чекауте либо не видит разницы вообще, либо выбирает способ сам — например, если один провайдер даёт рассрочку, а остальные нет. Техническая сложность в основном на стороне настройки: у каждого провайдера свой формат подтверждения платежа и свои требования к возвратам.

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

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

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

Сначала смотрим лог ошибок PHP. Часто причина в устаревшем методе API, который новая версия ядра пометила как deprecated или удалила совсем. Держится отчёт на прямых запросах к таблицам базы данных в обход штатных методов? Риск поломки при обновлении заметно выше. Чиним через замену устаревшего вызова на актуальный, а не откатываем обновление целиком ради одного отчёта — это создаёт долг на будущее.

По специализации и загрузке, а не по очереди «кто свободен первым». Инцидент с оплатой берёт тот, кто настраивал эквайринг на проекте, инцидент с версткой — фронтенд-разработчик. Загрузку смотрим в реальном времени, а не по расписанию на неделю вперёд: если специалист занят другим критичным инцидентом, задача автоматически уходит следующему по компетенции, а не ждёт освобождения первого. Такое распределение пересматриваем раз в квартал вместе с ростом команды.

Через привязку группы пользователей к своему типу цен в каталоге. После входа в личный кабинет оптовый клиент видит свою цену автоматически, без лишнего прайс-листа файлом. Цена подставляется сама. Скидки за объём можно настроить ступенчато: чем больше количество в заказе, тем ниже цена за единицу, без ручного пересчёта менеджером. Розничный посетитель без входа продолжает видеть обычную розничную цену.

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

Число значений свойства измеряется тысячами, а не десятками, и фильтрация по нему в типовом инфоблоке ощутимо замедляет страницу каталога — вот когда перенос оправдан. Типичный пример — отзывы с рейтингом. Или подробные технические характеристики в категориях с большим ассортиментом. Каталог небольшой, свойств немного? Перенос в highload-блок только усложнит администрирование без ощутимого выигрыша в скорости. Переносить всё подряд по инерции — плохая идея.

Каждый склад в 1С должен соответствовать своему складу на сайте, а не общей сумме остатков — иначе покупатель может оформить заказ на товар, которого физически нет в ближайшем к нему складе. Обмен настраивается по каждому складу индивидуально, с собственным расписанием синхронизации. Это усложняет первичную настройку. Зато избавляет от ситуаций, когда заказ подтверждён, а отгрузить его с указанного склада нечем.