Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: 1c8 один контрагент содержит 10 названий
Форум программистов > Базы данных и администрирование > 1C и всё что с ней связано
KiR
Ситуация такая - у контрагента может быть несколько названий, примерно около десятка. Название может содержать в себе 100-300 символов. Как лучше реализовать данную задачу:
1. в справочник контрагентов добавить табчасть
2. создать регистр сведений
Что из этих вариантов будет работать быстрее? Если второй пункт - то что является измерением, а что ресурсом в моем случае?
AlexeyP
Может подчиненный справочник?
KiR
AlexeyP
Не вижу смысла плодить лишние справочники для такой простой задачи.
puh14
Если по этим значениям надо будет отбирать или группировать - тогда длину лучше не больше 100 символов - на 200 у меня группировка отказалась работать. И в виде подчиненного справочника. в документе у меня привязывалось альтернативное имя клиента в печати на договор
KiR
puh14 по этому значению нада будет определять контрагента.
GRblSHA
Может лучше таких контрагентов заносить разными элементами справочника в одной группе например... так вообще долбаться не придется особо.....
Isabela
Похожую задачу решала в 7.7 так : Некие данные храню в строке неограниченной длины и при вызове элемента разворачиваю в таблицу значений (можно в список), каковую можно редактировать и пополнять. При записи таблица опять сворачивается в строку
puh14
Isabela Тогда в всяких запросах и отчетах его долго искать будет.. Если этого не надо, чисто на печать - тогда да. А представьте - найдите все документы, где было данное имя контрагента, исходя из того что оно в строке. Этож всех перебирать придется.
KiR
GRblSHA не совсем понял что ты имеешь ввиду
tanat
Он имел ввиду сделать группу контрагенттакойто, внутри группы уже этого же контрагента, но с разными названиями.

Речь идет о типовой конфигурации какойто, или о вновь создаваемой?

и еще:
в любом случае будет быстрее использовать регистр сведений. Для регистров сведений, на сколько я помню,не принципиально использование ресурсов-измерений. Т.е можно создать запись с 2мя измеерниями - одно - наименование организации, второе - ПолноенаименованиеОрганизации.второе можно взять ресурсом.


Вообще как правило - Измерения в регистрах - это то, в разрезе чего хочетсяполучить информацию, а ресурс - соответственно что именно хотим получить
KiR
tanat
Спасибо. с групами не очень хорошая идея. А с реестрами вот какая фигня, может правда это нормально - не знаю:
Если делаю Контрагент - измерением, а название ресурсом то в следующем примере будет давать ошибку:

Контрагент | Организация с ограниченной ответственностью
Контрагент | ООО

Ключ не уникальный. Т.е. Вторая записть не создаться. Получается нужно ресурс поменять местаи с измерением - так?
tanat
это изза того, что у тебя регистр не переодический, следовательно ключ "контрагент" - уже есть. тут надо делать либо еще одно измерение, либо сделать регистр переодическим. т.о у тебя будет уникальная пара "момент времени+ключ"+"ресурс".
KiR
tanat
периодичность не нужна! еще одно измерение тоже в принцыпе ни к чему. можно ли просто сделать НАЗВАНИЕ - измерением, а КОНТРАГЕНТА ресурсом. На что может негативно такой вариант повлиять?
tanat
Если не изменить структуру, то не сможешь завести еще одну запись парой измерение-ресурс. набор измерений одинаков - тогда запись не пропустит, даже если будет ресурс, отличный от существующего. понятно что переодичность тут не имеет смысла, однако если ее не указывать - нужно задавать дополнительные измерения. я б предложил задать пару измерений : контрагент, Полное наименование. а в ресурс вставить к примеру представление в платежных документах.

извините за знаки препинания и орфографию), тороплюсь)
KiR
tanat Спасибо, но я опять не понял((
У меня у одного контрагента может быть несколько наименований. если в РС именно наименования (стока до 250 символов) сделать измерением, а контрагента - ресурсом - то почему это плохо? Ведь наименования у меня будет уникальными.. Что плохого при таком варианте?
tanat
а искать как? по полному наименованию?
измерение должно быть ссылочного типа, иначе получится попа при составлении запросов. но попробуйте) вполне вероятно, что получится
evgenyatam
все просто - 2 измерения например КонтрагентСсылка и КонтрагентНаименование. в ресурсах - пусто. ищем наименование простым запросом:
"ВЫБРАТЬ
| НаименованияКонтрагентов.КонтрагентСсылка
|ИЗ
| РегистрСведений.НаименованияКонтрагентов КАК НаименованияКонтрагентов
|ГДЕ
| НаименованияКонтрагентов.КонтрагентНаименование = &КонтрагентНаименование"

а дальше первый элемент выборки будет содержать ссылку на контрагента.
KiR
Цитата(evgenyatam @ 27:08:2008, 21:23 ) *
все просто - 2 измерения например КонтрагентСсылка и КонтрагентНаименование. в ресурсах - пусто. ищем наименование простым запросом:
"ВЫБРАТЬ
| НаименованияКонтрагентов.КонтрагентСсылка
|ИЗ
| РегистрСведений.НаименованияКонтрагентов КАК НаименованияКонтрагентов
|ГДЕ
| НаименованияКонтрагентов.КонтрагентНаименование = &КонтрагентНаименование"

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

Да я так и сделал. Тока КонтрагентСсылка сделал ресурсом. Какая в принцыпе разница?
kaa
А признак в ходит в холдинг не подходит?
KiR
Цитата(kaa @ 28:08:2008, 13:00 ) *
А признак в ходит в холдинг не подходит?

А это что такое?
kaa
У контрагентов в 8 есть признак флажок Входит в холдинг и открывается поле головной контрагент, тоесть по твоему примеру заводишь столько контрагентов сколько надо и ставишь у них признак про гол. контрагента. Сам не использовал поэтому надо поэксперементировать smile.gif. Но насколько я понимаю отчеты можно будет строить и по одному контрагенту и по холдингу в целом.
tanat
Ему это не нужно, т.к скорее всего по факту - организации не входят в холдинг. просто есть 1 организация, которая ведет деятельность от разных организаций.

Мне кажется что использовать полное намименование контрагента не совсем верно, хотя внятно обьяснить почему - не могу). Организовывать таким образом регистр все равно что пить чай из стакана, в котором есть ложка - и не удобно, и в глаз может воткнуться, однако пьем все и ничего).
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2009 IPS, Inc.