Добрый день!
Полное наименование номенклатуры бывает и 150 знаков, бывает и больше. В справочнике полное наименование можно внести целиком, а просто наименование количество символов ограничивается 100 символами, изменить не могу. Как это исправить?
И как настроить список справочника номенклатуры, чтобы показывал полное наименование.
Идеология неправильная. Наименование - должно быть коротким и информативным для ваших сотрудников. Начинаться должно с какого-нибудь кода-номера-артикула, чтобы сразу можно было понимать, о каком товаре речь. В разнообразных списках товаров, в документах, в формах подбора и т.п. - должно быть в этом поле видно самое главное.
Конкретно например в приведенном примере - в наименовании первые слова "трехслойная сендвич-панель" лишние. У вас что, манагеры не знают, что это за товар? Зачем им эти слова? Они не несут смысловой нагрузки для тех, кому они адресованы. Но в любой таблице с товарами именно эти слова будут первыми попадаться на глаза.
Полное наименование - для клиентов, для документов продажи. Там должно быть все полностью.
Увеличить можно в конфигураторе, 150 знаков по-моему ограничение. Но не нужно.
(2)
Идеология м.б. единственная: во всех документах д.б. правильное наименование.
Загружая в базу документ из ЭДО, номенклатура поставщика сопоставляется с номенклатурой базы. Полное наименование в документе поставщика не будет сопоставляться с коротким наименованием базы.
Будет теряться время на подбор. При большом объёме документов и незначительных отличиях наименований, могут быть ошибки.
Соответствие полного и краткого наименования сведёт ошибки и затраты раб. времени к минимуму.
(4) это все совсем не так работает, номенклатура поставщика не имеет никакого отношения к наименованию и так далее. Вы хотите подложить огромную свинью вашим манагерам и складу, руководствуясь неправильно понятыми принципами работы в программе.
Впрочем вы не одиноки )))
При загрузки электронного документа в базу, номенклатура сопоставляется: либо выбирается из уже существующей, либо создаётся по наименованию контрагента. В документе штук 30ть строк, номенклатура новая и вся свыше 100 символов.
Ваш вариант обойтись "без свиньи"?
(7) ну смотрите. Загрузка номенклатуры это операция одного раза. Загрузили - дальше пользуемся. Сколько новой номенклатуры загружается в день? В месяц?
Дальнейшее использование созданных элементов справочника - подбор в документы, поиск в остатках, сборка заказов на складе, инвентаризации и т.п. - это постоянная работа каждого дня.
Вы пытаетесь оптимизировать разовую операцию, усложнив ежедневную работу многих сотрудников. Логика в чем?
Вариантов решения может быть много, для этого надо погружаться в подробности - много ли поставщиков, есть ли у них какие-то правила формирования названий, есть ли артикулы, сколько новых в день/неделю/месяц и так далее, смотреть надо по месту.
ЗЫ у меня есть один такой клиент, там ответственный за новую номенклатуру именно так и делает, 150 знаков наименование, смысловые последние 10, первые 140 не нужны, ну это выглядит мягко говоря странно, а сколько времени теряют на этом сотрудники, никто не считал. Но он там непрошибаемый совершенно )
(9)
Примерно так и представляла Ваш ответ. Не ошиблась.
Извините, но Вы вообще не о том говорите.
Автоматизация труда (любого) - это повышение производительности труда. О какой производительности можно говорить, если наименование номенклатуры приходится править вручную, только потому, что кто-то решил - 100 знаков и не больше! Даже если это одна-две новые номенклатуры - всё равно тратится доп. раб. время.
Позволив пользователю менять кол-во символов, или вести карточки номенклатуры на выбор - краткое/полное наименование или только полное - повышается производительность обработки документов.
П.С. у нас в справочнике номенклатуры идеальный порядок, но пришли к этому не сразу. Лучше быть непрошибаемой, чем с бардаком в учёте.
П.П.С. свою проблему я решила.
Автоматизация труда (любого) - это повышение производительности труда.
Я вам скажу одну простую вещь, вы только не обжайтесь.
Автоматизация труда - это роботизация.
А мы здесь занимаемся автоматизацией учета. А цель автоматизации учета - вовсе не повышение производительности или снижение затрат на персонал! А вовсе даже повышение качества информации и качества принимаемых управленческих решений. Что влечет за собой повышение требований к персоналу, работающему с данной информацией.
А вот уже потом, во вторую очередь, можно поговорить и об автоматизации рабочих процедур.
Ваша задача решается совсем по-другому. Разграничением прав НСИ, загрузкой прайс-листов поставщиков (совместно с сопоставлением номенклатуры поставщиков со своей собственной в отдельном регистре).
Лучше день потерять, зато потом целый год за пять минут долетать, птичка.
(10)я правильно понимаю, что при поиске номенклатуры по наименованию, вы будете искать именно "трехслойная сендвич-панель" и не важно, что их может быть больше десятка, скажем, различающихся последними циферками/буковками? По этим самым циферкам и буковкам вы товар различаете плохо, либо совсем не различаете?
Действительно, 150 символов - максимум в Наименовании.
Конечно, странно как-то решать за пользователя и ставить лимит. Почему не 100 или 250? Вопрос риторический:)
(13)вопрос совсем не риторический.
Полное наименование никак не ограничено, оно используется в печатных формах, короткое наименование - это наименование в списках, чтобы найти нужный элемент среди миллионов других
Как по-вашему продуктивнее искать в таком случае: по первым уникальным символам или последним?
Как по-вашему продуктивнее искать в таком случае: по первым уникальным символам или последним?
вопрос как искать не стоит совсем - это плоскость конкретной применимости 1с
Вопрос в том, что стандартный реквизит Наименование с лимитом в 150 символов превращается в подобие UID, а разработчик должен заводить свои реквизиты НименованиеКраткое и НаименованиеПолное, которые и использовать.
Или ничего не создавать, а просто принять как есть)) Пусть потребитель страдает или радуется.
Прям с языка сняли! Уже начал писать, как всех бухов учу писать наименования контров не "Общество с ограниченной ответственностью "Рога и Копыта"", а "Рога и Копыта ООО". Соответственно, вопрос к не терпящему "ограничений" оппоненту - сколько символов необходимо для таких наименований?
сколько символов необходимо для таких наименований?
вы путаете использование в конкретной задаче и ограничение для разработчика
А если в конкретной задаче Наименование это некий UID с длиной 500 символов? Всо, заводите доп реквизит, а Наименование стандартное просто не используйте вовсе)
(24) А вот так. Справочники предназначены для интерактивной работы пользователей, и они должны быть эргономичны именно по отношению к ним.
Если вам нужны некие 500-символьные UID-ы, с которыми не работает пользователь - то вам нафиг не нужны справочники с их наименованиями. Вы вполне можете обойтись невидимыми для пользователя регистрами сведений.
UPD. Ну то есть все просто - если вам нужен UID, а не ссылка - то вам не нужны справочники. Уникальность справочников поддерживается ссылками. Ссылки используются в качестве типов полей в других объектах.
Если вам нужен UID - ну так и используйте свой 500-символьный UID в качестве поля в других объектах.
(15)Разработчик и так завел реквизиты и использует их, а пользователи превращают Наименование в подобие UID, причем делают это абсолютно не правильно с точки зрения поиска данных по этому самому UID.
(15)Разработчик и так завел реквизиты и использует их, а пользователи превращают Наименование в подобие UID, причем делают это абсолютно не правильно с точки зрения поиска данных по этому самому UID.
я понимаю, что быстрый поиск (при вводе) по началу Наименования - это фича 1с
и если не пользоваться ничем кроме 1с, то кажется интересным
но это пережиток, сейчас быстрый поиск должен работать по всему содержимому поля, а не только по его началу
сейчас быстрый поиск должен работать по всему содержимому поля, а не только по его началу
Ахха, построение и обновление индекса полнотекстового поиска для строк неограниченной длины (по сути, вы именно это предлагаете) - ну ооочень быстрый поиск получится! :-)
Ахха, построение и обновление индекса полнотекстового поиска для строк неограниченной длины (по сути, вы именно это предлагаете) - ну ооочень быстрый поиск получится! :-)
зачем же так?))
ограниченной разработчиком для конкретного круга задач
Пример приведите? Отмазки не катят - ведь "конкретная задача" же!
ок, вот задача с которой сегодня полез в эти лимиты (на сейчас бы хватило 500)
Для того, чтобы Краткое и Полное наименование были идентичными.
Так называемый быстрый поиск по началу наименования не используется совсем по причине его полной неюзабельности.
У вас пользователи каким мониторами пользуются? Хотя бы у кого-то такое наименование отобразится полностью?
влазит, везде разрешение не менее фулл хд
Сейчас используется КраткоеНименование для поиска и отображения в документах, ПолноеНаимнование для печати
Поэтому лимит в 150 видится здесь странным. Но это не единственная боль 1с, вот еще одна из - https://forum.infostart.ru/forum9/topic281653 Примените там свои знания и красноречия))
Вижу - это уже не первая ваша попытка натянуть сову на глобус. И опять вам "странно", что после этого сова не в состоянии летать, а по глобусу нельзя учить географию.
Примените там свои знания и красноречия))
С меня достаточно и тут, чтобы понять полную бесперспективность ваших претензий к... изготовителю глобуса. :-P
а вы знаете какая у нас конфигурация и как что где реализовано?
В любой конфигурации есть формы списка, в них в том числе выводится наименование.
Наименование отображается как представление в других формах в полях ввода.
Поэтому не важно какая у вас конфигурация.
Делать поле, в котором будет отображаться представление в 500 символов, а потом говорить, что у вас все помещается на всех формах и этим удобно пользоваться... Не верю я в такие утверждения.
Ограничение 150 символов весьма странное. Явно из прошлого века.
В прошлом веке было ограничение 255 символов в MS SQL Server 6.5 для CHAR, VARCHAR.
Но уже в MS SQL Server 7.0 (тоже прошлый век) стало 8000 символов.