Получить цену из 1С мало: сайт должен сопоставить ее с правильным товаром и нужным видом цены. На Joomla это зависит в том числе от компонента, в котором хранится каталог. Разберем, какие правила обмена нужно описать до выбора модуля и как проверить их на повторной загрузке.
Как определить компонент Joomla и конфигурацию 1С
Для интеграции Joomla с 1С нужно определить, какие системы предстоит связать. Joomla управляет сайтом, а товары, варианты и заказы могут храниться в отдельном компоненте магазина. Поэтому модуль выбирают для конкретного сочетания платформы, компонента каталога и учетной системы.
Сначала запишите версии Joomla и компонента, название и версию конфигурации 1С, а также доработки, которые затрагивают каталог. Уточните, где сейчас хранятся цены, остатки и заказы, работает ли какой-либо обмен и кто его обслуживает. Если на сайте уже есть товары, нужно отдельно проверить, сохранилась ли их связь с учетными записями: новый модуль не обязательно распознает ее сам.
Совместимость модуля проверяют по документации и уточняют у поставщика. Важны не только названия систем, но и нужные операции: обновление вариантов, несколько видов цен, остатки по складам, отправку заказов. Поддержка передачи товаров еще не означает поддержку всех этих сценариев.
Составьте список данных, которые должны переходить между сайтом и учетом. Общие вопросы к учетной системе разобраны в материале про обмен с 1С; здесь их нужно привязать к устройству конкретного магазина.
Какая система отвечает за каждое поле
Источник данных назначают по полям, а не сразу для всей карточки. Например, учетная система передает цену и доступное количество, а редактор на сайте ведет описание и заголовок для поиска. Это возможная схема, которую нужно подтвердить для своего каталога, а не обязательное поведение любого модуля.
Таблица ниже — заготовка требований. В ней важно заполнить не только состав передаваемых данных, но и наблюдаемый результат проверки: тогда обещание «обмен поддерживается» можно проверить на конкретных действиях.
| Объект или поле | Что зафиксировать до выбора решения | Как проверить |
|---|---|---|
| Товар и вариант | Источник устойчивого ключа, связь варианта с товаром | Переименовать позицию и повторить передачу: обновляется прежняя запись |
| Название и описание | Источник каждого поля, перечень защищенных от обмена полей | Изменить описание на сайте и убедиться, что загрузка его сохраняет |
| Цена | Вид цены, валюта, единица продажи, правила пустого значения | Передать две цены и проверить нужную цену в карточке и корзине |
| Остаток | Какие склады учитывать, как трактовать резерв и нулевое количество | Передать согласованные значения и проверить доступность покупки |
| Свойства | Справочники, единицы измерения, соответствия полям компонента | Проверить значение в карточке и в фильтре, если он использует это поле |
| Заказ и статус | Направление передачи, ключ заказа, разрешенные изменения | Повторно отправить заказ: второй документ не появляется |
| Снятие с продажи | Явный признак, действие на сайте, судьба адреса карточки | Передать признак и проверить видимость товара и доступность страницы |
| Сбой и повтор | Правило применения пакета, точка возобновления, ответственный | Прервать тестовую загрузку и проверить результат повторного запуска |
Отдельно различайте пустое значение, ноль и отсутствие поля в сообщении. Для цены это могут быть три разных события: цена не задана, цена равна нулю или цена в этом обмене вообще не обновляется. Если их объединить, неполная выгрузка способна стереть корректное значение.
Для остатков недостаточно написать «передавать количество». Нужно решить, показывает ли сайт физический остаток, свободный остаток после резервов или доступность по выбранным складам. На приемке сравнивают именно согласованный показатель, иначе обе системы могут показывать разные, но по-своему правильные числа.
Как сопоставить товары, варианты и виды цен
Название товара удобно человеку, но плохо подходит для постоянной связи записей. Его исправляют, сокращают и дополняют; у двух разных позиций оно может совпасть. Артикул тоже нельзя назначать ключом без проверки: в конкретном каталоге он может повторяться или отсутствовать.
Для связи нужен устойчивый идентификатор, уникальность и сохранность которого подтверждены на обеих сторонах. Часто основой служит идентификатор записи учетной системы, который сохраняют рядом с товаром сайта. Важно проверить, что он не теряется при повторной передаче, смене модуля или восстановлении базы.
У существующего каталога сначала составляют таблицу соответствий. В ней видно, какой товар сайта связан с какой записью 1С, где связь отсутствует и где одному ключу отвечают несколько товаров. Неоднозначные совпадения разбирают до загрузки: правило «берем первый товар с таким названием» лишь скрывает проблему.
Вариант товара требует отдельного внимания. Условная футболка одного цвета и размера должна получить свой остаток и свою цену, если учет ведется на этом уровне. Нужно описать связь родительского товара с вариантами и проверить, как компонент магазина хранит эти сущности; обмен не должен создавать отдельную карточку там, где нужен вариант существующей.
Для видов цен задают явные соответствия и условия показа покупателям. Одного совпадения названий недостаточно. При проверке смотрят цену для нужной группы покупателей в карточке и корзине, а не только значение в управлении каталогом.
Для проверки загрузите два товара с одинаковыми названиями и разными ключами, затем измените цену только у одного. После повтора обновиться должен только он. Затем переименуйте товар и проверьте, что связь с прежней карточкой сохранилась.
Как выбрать направление, формат и расписание обмена
Направление описывают отдельно для каждого потока. Каталог может идти из 1С на сайт, заказы — с сайта в учет, а изменения статусов — обратно. Двусторонний обмен не означает, что любая сторона может свободно перезаписать любое поле: правила владельца данных продолжают действовать.
Формат выбирают после проверки возможностей обеих систем. Название XML или JSON само по себе не подтверждает совместимость: должны совпасть структура сообщения, значения полей, способы передачи и подтверждения результата. Отдельно согласуют доступ к обмену и место хранения учетных данных, чтобы доступ не зависел от личной учетной записи сотрудника.
Частоту привязывают к допустимому возрасту данных. Если цены разрешено обновлять реже, чем остатки, этим потокам не обязательно работать по одному расписанию. Для заказов определяют, сколько времени они могут ожидать передачи и как сотрудник увидит, что заказ еще не принят учетной системой.
Полная выгрузка и передача изменений решают разные задачи. Для первой нужно понимать, как обозначается завершение полного набора; для второй — с какого момента выбираются изменения и когда эта отметка сдвигается. Если считать данные переданными до подтверждения приема, при сбое часть изменений можно пропустить.
Проверьте обмен на согласованном объеме каталога и предусмотрите защиту от наложения запусков. Несколько тестовых карточек не покажут, укладывается ли загрузка в отведенное время.
Как проверить повтор, удаление и прерванную загрузку
Первый успешный запуск подтверждает только то, что данные удалось принять один раз. В работе будут повторы, неполные пакеты и исправления уже переданных записей. Поэтому приемка должна включать действия, после которых проверяют состояние каталога, а не только сообщение об успешной загрузке.
Проверки проводят на тестовой копии с отдельным подключением, исключив отправку заказов в рабочий учет. Сохраните исходное состояние и запишите ожидаемый результат каждого сценария.
- Повторить один пакет без изменений. Число товаров и заказов не растет, значения остаются прежними.
- Изменить один вариант товара. Цена или остаток соседних вариантов не меняются.
- Передать нулевой остаток. Сайт применяет согласованное правило доступности, а не удаляет карточку автоматически.
- Не включить товар в частичный пакет. Его отсутствие не считается командой снять позицию с продажи.
- Передать явный признак снятия с продажи. Сайт выполняет согласованное действие с товаром и его страницей.
- Прервать загрузку и запустить ее снова. Принятые данные не дублируются, непринятые не теряются.
Для прерванной загрузки заранее выбирают допустимый результат. Один вариант — применять пакет только после проверки целиком; другой — принимать записи по частям и точно учитывать, какие из них уже обработаны. Важно, чтобы выбранное поведение было реализуемо в данном решении и позволяло восстановить согласованное состояние данных.
Как принять обмен и организовать журнал ошибок
В таблицу требований добавляют фактический результат каждой проверки, идентификатор запуска и значения до и после. Это помогает отличить ошибку сопоставления от неверной исходной цены в 1С.
В журнале нужны время начала и окончания, направление передачи, количество обработанных и отклоненных записей, причина отказа и идентификатор проблемного объекта. Пароли и полные данные покупателей туда выводить не следует. Журнал должен помогать найти конкретную запись, не превращаясь в неконтролируемую копию учетной базы.
Отдельно фиксируют время последнего успешного обмена и допустимую задержку. Если новых запусков нет, ошибок в журнале тоже может не быть, хотя данные уже устарели. Поэтому уведомление нужно и при явном отказе, и при превышении согласованного интервала без успешной передачи.
Назначьте ответственного за уведомления и опишите порядок восстановления: кто исправляет данные и когда допустим повтор. Если обмен меняет устройство каталога, эти договоренности входят в требования к разработке сайта.
Принимать связку Joomla и 1С стоит после проверки согласованных сценариев: от первой загрузки до восстановления после сбоя. Укажите компонент магазина, конфигурацию 1С и нужные данные — составим требования к обмену и приемке.