В процессе работы с ювелирными изделиями в программе 1С:Розница Ювелирный магазин (или аналогичных решениях от компании «Рарус») одной из самых критичных ошибок является неверное сопоставление номенклатуры и уникального идентификационного номера (УИН). Это приводит к тому, что при сканировании бирки (кода DataMatrix) в чек подставляется совершенно другой товар — например, вместо дорогостоящей золотой цепи программа выбирает дешевый пирсинг. Рассмотрим подробно, почему возникает эта «мертвая привязка» и как её корректно разорвать, чтобы восстановить правильный учет.
Для начала проанализируем ситуацию: почему простая замена номенклатуры в спецификации или документе поступления не решает проблему? Дело в том, что в ювелирных конфигурациях связь между физическим изделием (идентифицируемым через УИН) и элементом справочника Номенклатура фиксируется в специальных регистрах сведений. При первом сканировании или загрузке данных из ГИИС ДМДК система создает запись в базе данных, которая «запоминает», что конкретный УИН соответствует конкретному ID номенклатуры.
Даже если вы измените данные в документе-основании, внутренняя запись в регистре останется прежней. Программа при сканировании первым делом обращается к этому регистру, находит там «связку» и моментально подставляет неверную карточку товара. Чтобы исправить ситуацию, нам необходимо удалить эту связь «на корню».
Разберем по шагам самый эффективный метод исправления, который заключается в редактировании регистра сведений Партии ГИИС ДМДК. Именно здесь в большинстве случаев хранится основная информация о сопоставлении.
Партии ГИИС ДМДК.Номенклатура (и, возможно, Характеристика) указан тот самый неверный товар.После удаления этой записи система «забудет» о связи УИН с неправильным товаром. При следующем сканировании этого изделия в документе продажи или поступления программа не найдет готовую связку и предложит вам сопоставить УИН с номенклатурой заново. В этот момент крайне важно выбрать верную карточку из справочника.
Иногда очистки одного регистра недостаточно, так как связь может дублироваться в служебных объектах. Рассмотрим подробнее, какие еще места стоит проверить, если проблема сохраняется:
Регистр «Соответствие номенклатуры ГИИС ДМДК»
В некоторых релизах отраслевых решений существует отдельный регистр, отвечающий исключительно за маппинг объектов ГИИС и 1С. Если запись в «Партиях» удалена, а здесь осталась — при очередном обмене с ГИИС система может восстановить ошибочную связь. Найдите этот регистр через поиск в функциях технического специалиста и удалите записи, касающиеся неверного товара.
Регистр «Штрихкоды упаковок и товаров»
Хотя автор темы указал, что там пусто, в стандартных версиях 1С:Розница именно здесь могут храниться связи штрихкодов DataMatrix с номенклатурой. Если вы работаете с маркированным товаром, обязательно проверьте этот регистр. Для ювелирки также могут существовать расширенные регистры штрихкодов. Если система автоматически создала внутренний штрихкод для изделия при первом сопоставлении, его нужно найти и удалить.
Проанализируем возможности стандартного интерфейса. В современных версиях конфигураций предусмотрена специализированная обработка Сопоставление номенклатуры ГИИС ДМДК. Рассмотрим, как она может помочь:
Часто ошибка кроется не в самой номенклатуре, а в неверно выбранной Характеристике (например, указан другой размер кольца или вес). Если в вашей базе включен учет по характеристикам, в регистре Партии ГИИС ДМДК необходимо проверять заполнение обоих полей: Номенклатура и Характеристика. Пустая характеристика при заполненном товаре — это тоже ошибка, которая приведет к неверному подбору в чеке.
Также посмотрим на проблему «мертвой привязки» через призму уже проведенных документов. Если УИН уже был оприходован документом Поступление товаров, то система может брать аналитику из регистров накопления (остатков). В этом случае алгоритм действий следующий:
После проведения всех манипуляций по «чистке» регистров, мы рекомендуем выполнить следующие действия:
1. Проверьте справочник Ключи аналитики учета номенклатуры. Иногда неверная связь фиксируется на уровне системных ключей аналитики. Если после удаления записей из регистров проблема остается, может потребоваться обновление этих ключей через регламентные операции обслуживания системы.
2. Протестируйте сканирование в «пустом» документе. Откройте новый документ Реализация товаров или Чек ККМ и считайте DataMatrix. Если программа вывела окно сопоставления — вы все сделали правильно. Если программа снова «подтянула» старый неверный товар — значит, связь сохранилась в одном из кэширующих регистров или в документах движения, которые нужно перепроводить.
Важный совет: Любые манипуляции с регистрами сведений через функции технического специалиста следует выполнять только после создания резервной копии информационной базы!