Вендор добавил в документ ТЧ и реквизит. Вместо ссылки на справочник сделал текстовый реквизит. Значение текста в реквизите почти равно наименованию справочника.
Т.е чтобы обратиться к реквизитам справочника надо искать его по наименованию.
Какие аргументы можно привести, чтобы переделали на справочник (позиция - ну работает же) ?
На какие стандарты разработки можно сослаться ?

Переименуйте элементы справочника и сошлитесь что ничего не работает

(0) поменяйте все русские с на латинские

При разработке (если не используется технология ХХП) надо проектировать решение с учетом гибкости и надежности на будущее
Если нет жестких ограничений по быстродействию

Аргумент один

Не переделайте идёте на хххххх

(4) Не получится, он не имеет вероятно подобного влияния на вендора.
А те кто имеют им похрен, работает же.

(0) > На какие стандарты разработки можно сослаться ?

Релятивистскую природу СУБД.

(0)удали часть справочника

https://habr.com/ru/post/31632/

(0) А более внятно сформулировать можно? Что значит "Значение текста в реквизите почти равно наименованию справочника"? Для начала непонятно, что значит "Почти", типа Розовый - это Почти Красный? Далее непонятно мы имеем равенство "НАИМЕНОВАНИЮ" справочника, или наименованию Элемента справочника? Это как-бы сильно разные вещи. Наименование справочника фиксировано и к нему без проблем обращаться по наименованию, например "Контрагенты", "Номенклатура", а наименование элемента - это совсем другое.

(9) Наверняка: привычка работать в EXEL.

Приведу пример. Есть предприятие, есть отдел снабжения и есть подразделения. Фишка в том, что продукция зачастую не типовая и требует постоянных доработок. Подразделения формируют заказ снабженцам. Например, конструктора написали: "резистор 5 ОМ +/-12%", а в базе такого нет, да и вообще может в природе такого не существует и надо подбирать аналоги у поставщиков, или написать "резистор 5 ОМ +/-12%,  но вы там посмотрите: может на складе есть резистор 6 ОМ — то же сойдет".

По большому счету все упирается в службу НСИ на предприятии.

З.Ы. Так же отмечу, что EXCEL зачастую удобнее 1С если идет связка условно говоря Конструктор-Снабженец. Можно тупо распечатать и пометить маркером: это отгрузили со склада, это есть в запасах но не отгрузили, это заказали. Если надо что-то поменять, удалить подошел Конструктор на бумажке вычеркнул вписал и рядом расписался. В 1С:ERP — это геморрой.

И только если сюда начинают включатся другие люди: начальник снабжения следит за исполнением заказов, производственники за соответствие спецификации, это зарезервировано и хотя есть на склада кладовщик не отдаст и т.п. 1С становится лучше EXCEL

У меня так сделано например ссылка на справочник маршруты в заявки превращается в текстовый реквизит в реализации. Сделано для того чтоб если кто то решит переименовать маршрут (типа мы туда все равно 3 года уже не ездим, а давайте переименуем его и будем использовать для другого направления), то это не "попортит" статистику прошлых годов

(10) То о чем говорите Вы это фактически справочник аналогов в 1С. Но, в (0) сформулировано так, что вендор предлагает искать именно по "наименованию справочника", еще раз, не элемента, а именно справочника. Поиск по наименованию справочника в ряде случаев вполне нормальное программное решение, емнип даже в типовых конфах от 1С вполне себе встречается... Поэтому и переспрашиваю, что хотел сказать автор...

(13) > Вы это фактически справочник аналогов в 1С.

В 1С:ERP аналог ты ДОЛЖЕН выбрать в момент формирования потребности. Попросить у снабженца: "давай вот этот, но и тот сойдет" — насколько я знаю нельзя.

(12) ИМХО слишком избыточно. Проще ограничить права на изменение имени маршрутов вменяемыми людьми.

(14) Это уже проблемы самих конфигураций. А проблем много. Некоторые тянутся еще со времен семерки, а то и раньше. Например, не знаю почему, но 1С никак не может догадаться, что во многих случаях на момент заказа у клиента нельзя определить Точную цену, по которой происходит заказ. По сути, для очень многих удобно заказывать количество, а уж цена товара будет известна только на момент прихода. Из-за подобного подхода конфы корежились начиная с семерки, но 1С продолжает настаивать...

(15) ну тем самым данные будут "пухнуть", а так можно смело удалить маршрут и ты знаешь что отчеты у тебя продолжат работать

(16) На момент заказа есть или цена текущего прайса или предыдущая цена или поставьте цену примерно.
Разрешить не указывать цену в заказах поставщику или указывать 0-ю это тоже не очень решение.
Ибо планирование/бюджетирование страдает.

(12) организационно такое должно решаться, а не костылями

(6) > Релятивистскую природу СУБД.

А в данном случае применяется ОТО или СТО?

(20) Ну, применят реляционную, значит )

(0)А ты там кто?) Раз устраивает, пусть так живут)

(9) есть справочник усКонтейнеры. Наименование у элемента 123, реквизит Штрихкод у этого элемента имеет значение 190000000123. В документах вместо ссылки на элемент справочника добавлен текстовый реквизит Штрихкод, который имеет значение 190000000123.
Если оставить как есть, то в запросах, когда надо обратиться к усКонтейнеры, придется подзапром делать через реквизиты ШтрихКод.
Это не удобно.
И большие сомнения по производительности.
В диспуте нужны аргументы, что так делать не надо

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

(0) Если этого требует специфика учета, то почему нет?
У меня, в моей конфигурации для медцентра есть одна такая табличная часть в которой идет работа с анализами. Там сложная система связей из 5 справочников (анализ, тесты в нем, пробирки, биоматериалы). Сегодня вся это структура имеет один вид, завтра другой, причем меняется даже наименование. И важно что бы в прошлых приемах все оставалось как было на момент приема, поэтому все поля в ТЧ строковые и в них пишется наименование/код нужных элементов справочника.

(0) Нарушается/изменяется/теряется ссылочная целостность при изменении наименования позиции справочника - что явно не должно быть. Должно быть, имхо, ссылка и наименование. В типовых конфигурациях так, например работа с услугами организована: в электронном документе услуга указывается по ссылке, но её наименование тоже хранится в документе и может быть там оно в любой момент изменено.

(23) Возможно есть причины почему сделано именно так

(23) штрихкоды всегда хранились в регистре сведений, что за справочник штриходов?

(23) Завтра захотят наименование поправить на 1234 с 123, Вам придется во всех документах заходить и править это строковое поле.
Послезавтра, кто-то введет ручками неправильное наименование и вы потом в запросе получите не корректные данные
ПослеПослеЗавтра, захотят добавить новую сущность для этого справочника, например Артикул и его вывод в ТЧ документа, вам придется добавлять новый реквизит и хранить его в базе, а так же учесть все события изменения основной позиции, вместо того, чтобы прописать путь до артикула у этого поля.
И эти неудобства будут с каждым разом нарастать.

(0) Начиная с уникальности, заканчивая непосредственно ссылкой по смыслу. Предположим что это текстовое поле уникально, но завтра менеджер исправляет "Яйцо куриное С0" на "Яйцо куриное С0 - НЕ ИСПОЛЬЗОВАТЬ" и заводит новое "Яйцо куриное С0". Если у тебя по такой логике будут подвязаны продажи или закупки то пойдёт по звезде вся отчетность.

Есть вариант сделать этот реквизит по принципу идентификатора - что бы пользователь не мог его менять и что бы он был уникальным. Тогда ключевой вопрос - на кой хрен, когда УЖЕ есть ссылка?

(30) Странно, что ТС с 13 летним стажем сам не может сформулировать аргументированный ответ, тем более зная бизнес - процессы предприятия.

(29) Такие решения не применяют, когда нужен анализ и сбор данных. Хранение выбираемого из справочника значения в текстовом поле - это осознанное решение, когда справочник является лишь классификатором для ускорения ввода, но не является хранилищем внешних ключей.

(23) >>реквизит Штрихкод у этого элемента имеет значение 190000000123. В документах вместо ссылки на элемент справочника добавлен текстовый реквизит Штрихкод, который имеет значение 190000000123.

А вот хуже этой хрени вообще ничего не придумаешь)
Во-первых, штрих-коды не уникальны в принципе, по своей природе.
Во-вторых, если программа учёта берёт данные не из источника НСИ с качественной верификацией, а просто из документов закупки и\или позволяет на приёмке эти штрих-коды добавлять, то исполнители будут заносить какие угодно данные, но не верные. И чем дольше такая система будет работать без двойного-тройного контроля, тем больше будет лажи в справочнике и документах

(32) Можете пример из типовой конфы привести, где такой подход используется?

(34) Например КЛАДР. Классификатор отдельно (он может быть вообще внешним в интернете), а адресная информация хранится непосредственно в виде декста.

(35) С адресным классификатором хоть понятно, почему именно так реализовано. А тут речь, про ТЧ и штрихкоды и скорее всего есть необходимость к частому обращению к самому справочнику, иначе бы этой ветки не было.

(23) А по этикеткам грузомест\контейнеров\палетомест - если у тебя контейнер не справочник и его никак нельзя ввести вручную или изменить, нигде нет на него проверок, то принципиальной разницы нет. Тогда он как справочник в общем-то и не нужен. И тут зависит от конкретной реализации. Если же справочник нужен, а ты хочешь сделать такой костыль для ускорения, то это некорректно и может сыграть злую шутку в запросах по табличной части справочника - индекс по ссылке всегда есть и везде, а в случае реквизита придётся делать на одно соединение больше, у которого не будет правильного индекса.

(34) Банки и классификатор банков.
Сами банки не хранят ссылку на классификатор, но при этом при обновлении классификатора банк ищется по коду и обновляется автоматом