Как проверить совместимость в конфигураторе

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

Определите границы совместимости

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

Отдельно назовите то, чего конфигуратор не проверяет. Например, он может сопоставлять размеры из каталога, но не учитывать состояние объекта у заказчика. В таком случае результат следует обозначить как предварительный подбор в заданных границах. Нельзя превращать отсутствие найденного запрета в универсальное заключение о безопасности или пригодности.

Не смешивайте четыре причины исключения. Технически несовместимый вариант нарушает правило. Недоступный товар отсутствует в продаже. Дорогой вариант не проходит бюджет. Менее предпочтительный допускается, но уступает по выбранному критерию. Если всё показывать одним серым пунктом «не подходит», сотрудник не сможет понять, что исправлять и можно ли предложить альтернативу.

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

Запишите правило вместе с основанием и направлением

Каждая строка реестра должна отвечать: при каком условии что разрешено или запрещено, откуда это известно и кто подтверждает изменение. «Серия А подходит к серии Б» слишком неопределённо. Укажите конкретные версии, параметры, единицы и область применения. В публичной инструкции не требуется раскрывать внутренний каталог, но в рабочем реестре основания должны быть доступны проверяющему.

Полезный состав записи: идентификатор правила, условие, требование, действие при нарушении, объяснение пользователю, источник, владелец и версия. Если два источника противоречат друг другу, пометьте правило как требующее решения специалиста. Алгоритм не должен выбирать удобный документ случайно или скрывать противоречие за уверенным зелёным статусом.

У зависимости есть направление. «Если выбран модуль А, нужен адаптер Б» не означает «при наличии Б обязательно выбрать А». В документации JSON Schema об условной валидации отдельно показано, что зависимость наличия свойств не становится двусторонней автоматически. Это полезный пример формализации, но он не доказывает, что конкретный конфигуратор использует JSON Schema или проверяет инженерные характеристики.

Названия и число 100 здесь условные и не относятся к реальному оборудованию. В рабочей версии замените их подтверждёнными значениями. Для каждого правила определите, можно ли исправить выбор автоматически или нужно объяснить конфликт. Автозамена существенной позиции без предупреждения меняет решение пользователя и затрудняет последующее сравнение.

Составьте контрольные комплекты независимо от программы

Ожидаемый результат определяйте по согласованному правилу, а не копируйте из самого конфигуратора. Иначе проверка подтвердит только повторяемость ошибки. Попросите специалиста составить несколько комплектов вручную и записать причину решения до запуска интерфейса. Для спорного случая допустим ожидаемый ответ «требуется уточнение», если исходников действительно недостаточно.

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

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

Не путайте контроль совместимости с проверкой стоимости. Допустимый комплект может иметь неверную сумму, а запрещённый — арифметически верную. Расчёты проверяют отдельно; пригодится методика контрольных примеров для формул калькулятора. Низкая цена не должна повышать неподходящий вариант над техническим запретом.

Проверьте границы и взаимодействие нескольких условий

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

Условный пример с вместимостью показывает, почему проверки каждой позиции отдельно недостаточно. Два элемента занимают по 60 единиц, лимит комплекта — 100. Каждый по отдельности проходит, вместе получается 120 и нужен отказ. Два элемента по 50 дают ровно 100 и проходят только по этому правилу; другие ограничения всё ещё могут запретить сочетание. Это учебная арифметика, не характеристика товара.

Проверяйте и наборы из трёх и более позиций. Пара А–Б может быть допустима и пара Б–В тоже, но полный набор не проходить общее условие. Простая матрица пар полезна, однако не заменяет ограничение суммы, обязательного состава или версии всего комплекта. Если система поддерживает лишь парные правила, это должно быть явно отражено в её границах.

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

Повторите выбор в другом порядке и после изменения

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

При смене базового варианта старые дочерние позиции могут стать недопустимыми. Определите ожидаемое поведение: явно снять зависимую позицию с пояснением, предложить замену или оставить конфликт до исправления, запретив подтверждение результата. Ни один вариант не стоит считать правильным для всех процессов; он должен быть согласован с владельцем каталога и понятен человеку.

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

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

Сделайте отказ объяснимым, а неизвестность заметной

Хорошее сообщение называет конфликтующие позиции или параметр, объясняет условие и предлагает допустимый следующий шаг. «Ошибка конфигурации» ничего не говорит о решении. «Для выбранного варианта требуется дополнительный элемент; добавьте его или измените базовый выбор» помогает продолжить, если именно это правило подтверждено.

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

Неизвестный параметр требует отдельного состояния. «Данных недостаточно для проверки» честнее, чем «совместимо» из-за пустого поля. Укажите, что именно нужно уточнить и кому передать запрос. Не предлагайте клиенту самостоятельно угадывать техническую характеристику, если для неё требуется документация или измерение специалистом.

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

Примите правила и закрепите проверку обновлений

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

B2B-конфигуратор Nazara опубликован как демонстрация подбора по таблицам и правилам. Он помогает обсуждать интерфейс и логику, но не подтверждает совместимость произвольного оборудования из Вашего каталога. Для своего проекта через Умную форму можно описать один спорный комплект без закрытых данных и приложить формулировку правила.

После изменения справочника повторяйте связанные контрольные примеры. Запишите дату, версию, фактический результат и принятое решение. Чек-лист ниже фиксирует Вашу работу в этом браузере; он не анализирует оборудование, документы или действующий конфигуратор автоматически.

Частые вопросы

Можно ли начать с матрицы пар

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

Что делать, если специалист и программа расходятся

Зафиксировать исходные параметры и основания обеих сторон. Не считать программу правой по умолчанию, но и не менять правило по памяти. Сначала найдите подтверждённый источник и воспроизводимый пример расхождения.

Нужно ли проверять все возможные комплекты

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

Может ли ИИ определить совместимость по фотографии

Фотография может подсказать направление поиска, но не гарантирует версию, допуски и внутренние характеристики. Для решения нужны подтверждённые данные и правила. При нехватке сведений требуется уточнение, а не уверенный ответ модели.

Как проверять импортированную комплектацию

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

Можно ли оставить предупреждение вместо запрета

Только если согласованное правило допускает продолжение. Жёсткий запрет нельзя превращать в рекомендацию ради удобства. Для допустимого, но нежелательного варианта объясните последствия и не смешивайте его со статусом несовместимости.