Народ всем ку!

Ранее вся контактная информация по всем (организациям, контрагентам, физикам) была в одном регистре контактная информация.

Сейчас открыл типовую торговлю 11.3, в ней у каждого справочника своя табличная часть с контактной инфой. А общего регистра нет. С чем это может быть связано?

(0) Скорее непонятно, почему было в РС

Да, переливают из путого в порожнее..
При этом не имея инcтрументов разбора xml в запросах, хранят информацию именно в xml. Что бл.ть мешало нормализовать и сохранить в формате реляционной БД

(0) Если присмотреться лучше, то в ТЧ КонтакнаяИнформация есть поле ДействуетС, с типом дата.
Как рекомендует 1С - если необходимо получение среза информации на момент времени или текущего значения показателей, то для этого нужно использовать... ТЧ объекта.

(0) При ближайшем рассмотрении, разницы почти никакой.

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

ну и разработчики по этому вопросу отвечают следующее:

0 Шамарин Олег (1С:Франчайзинг. ДАРМИКС, Москва) 30.11.2009 15:30 744828 Отвечает на
Что бы права доступа на контактную информацию совпадали с правами доступа на сам объект. То есть контактная информация - неотъемлемая часть самого объекта...

А может кто-то знает почему в ут ПоступлениеТоваровИУслуг переименовали в ПриобретениеТоваровИУслуг

больше видимо дорабатывать нечего

Чтобы допиливальщикам работы подбросить, очевидно же :)
Не, пусть делают, лишний раз клиенты бабло заплатят.

(8) на самом деле это напрягает. Порой бабло можно получать и не зарываясь в тонны бесполезной работы. Да и довольный клиент платит лучше

Так решили разработчики БСП.

ВЫБРАТЬ
Партнеры.Наименование,
Партнеры.ИНН,
Партнеры.КПП,
Партнеры.АдресФактический,
Партнеры.Email
ИЗ Справочник.Партнеры КАК Партнеры

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

(10) ИНаче 1С тормозить не будет. Видно это производители железа заносят чемоданы в 1С, чтобы они писали тормознуть код

(7) Потому что при, например, неотфактурованных поставках - приобретение и  поступление - это две разные операции.

(7) Иначе чем издевательство над пользователями и внедренцами я такое назвать не могу. То обновление заняло в разы больше времени чем положено.
Или их постоянные перетасовки процедур между модулями. В последнем обновлении КА/ERP перетасовали половину процедур проведения из модуля менеджера в общие модули. Как они представляют работу с расширениями? были замененные процедуры, теперь их нет, расширение не работает, сравнения расширений с конфигурацией нормального тоже нет.
Похоже разработчиками зарплату платят от количества выпущенных релизов и объема измененного кода, 8 релизов ERP за квартал, мне кажется это слишком.

(12) можно было просто поменять синоним документа, но наверно это слишком просто
(13) видимо изобрели новый внутренний стандарт

(10) > для подавляющего большинства управленческих задач такой запрос вполне подойдёт.

Ключевое слово "подавляющих". Для всех остальных (которых овер дофига) пришлось бы писать ректальные варианты решения, да ещё учитывать, что часть информации в самом объекте, а часть - в отдельных (табличных частях, регистрах или ещё где-то) и контролировать её дублирование.

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

(11) чем медленнее работает система, тем более солидней она выглядит (с)

(14) > видимо изобрели новый внутренний стандарт

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

Проблема в том, что делается это (перетасовка кода) слишком часто.

А зачем в последней УТ11 добавили две константы?
1. НеНоваяАрхитектураВзаиморасчетов
2. НоваяАрхитектураВзаиморасчетов
Обе булево...

Понабежали плакальщики
Пользуйтесь экселем и УТ 10, там хрен че поменяется, раз в сто лет

(17) Да вот если бы этот код где то еще использовался. Были процедуры в модуле менеджера документа ОтчетОРозничныхПродажах, добавили общий модуль ОтчетОРозничныхПродажахПроведение (дословно не помню может по другому называется) и перенесли туда часть процедур, в чем целесообразность этого?

(18) для функц. опций

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

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

(20) > в чем целесообразность этого?

Не знаю. Но какая-то причина точно была. Нет под рукой сейчас установленной ERP, чтобы посмотреть.

(23) > Походу концепция поменялась.

B да и нет. Кардинально концепция не менялась.
Для каждого случая принимается своё решение.
Что касается единого регистра сведений КИ, то тут уже упоминали критическую проблему такого подхода. Это права доступа. RLS на такой регистр убивает производительность. Для больших баз (в особенности типа ERP) это смерти подобно.

(22) А как ты хотел? Чем более универсально и функционально решение, тем более оно сложно. Это естественный процесс. Функциональность типовой бухни 3.0 на снеговике и 4.5 на клюшках - это день и ночь. Хотя для конкретно взятого бухгалтера какого-нибудь ларька она незаметна.

(10) Делать реквизитами объекта - неуниверсально. Если будет нужен новый вид КИ - рек добавлять?

(0) И зачем тебе это знать? Что ты будешь делать с этим знанием?

Сделано в виде табчастей, когда в 1С начали заморачиваться с сохранением конфиденциальной/персональной информации по физлицам (права на регистр сведений на чтение есть у всех, а на справочник - редактируются ролями).

(10) Для запросов в СКД работа с допреквизитами примерно так и выглядит (как будто с обычными реквизитами справочника). Только допреквизиты нужно выводить в режиме предприятия, но не думаю, что это большая сложность.

(25) Спасибо.Самое верное объяснение.

(27) скажем так, для 98% организаций зоопарк из контактной информации нафиг не нужен. Им достаточно адреса (ну пусть с разделением на юридический и фактический), поля для телефонов и поля для электронки. Всё.

(28) Разрабатываем конфу с нуля. Естесственное желание - чтобы максимально соответствовать типовым. Но при этом не хочется бороться со здравым смыслом. И чтобы в долгосрочной перспективе учесть те грабли, о которых еще не знаем.

(32) подсистема КИ относится к тем, которые можно и нужно не использовать.

(33) Ну если речь о БСП - то там я вообще не нашел, что можно использовать

(31) "поля для телефонов и поля для электронки" - Сколько полей для телефонов и сколько для электронки ты заложишь? По одному маловато будет.

(35) что мешает все телефоны писать в одном поле? Аналогично с электронкой

(0)От всех таких вот пертурбаций сразу думается что в 1С слишком много женщин на руководящих должностях..

(36) телефон для смс рассылки, телефон оператора, телефон директора, электронка для переписки, электронка для рассылки это миниму который есть практически во всех торговых конторах

(38) если так, то можно прикрутить подчиненный справочник контактных лиц, и там заполнять простое текстовое поле. И если спам по смс и электронке входит в специфику работы организации, то одним легким движением руки можно прикрутить к справочнику два текстовых поля

(39) так для этого и есть подсистема контактной информации)))

(34) серьезно?

(34) то есть вам в конфигурации не нужен вообще никакой функционал, который есть в бсп?

(40) использование подсистемы КИ усложняет разработку. Вместо банальных запросов типа (10) придется городить запрос, где на каждый вид нужной КИ придется делать левое соединение с ТЧ КИ. Сравни (10) и запрос из типовой конфы:

ВЫБРАТЬ
    ПодписчикиВидыКИ.ИсточникОповещения,
    ПодписчикиВидыКИ.Подписчик,
    ПодписчикиВидыКИ.Получатель,
    ПодписчикиВидыКИ.ПредставлениеПолучателя,
    ЕСТЬNULL(КонтактнаяИнформацияТелефон.Представление, "") КАК ПредставлениеТелефон,
    ПОДСТРОКА(ЕСТЬNULL(КонтактнаяИнформацияТелефон.ЗначенияПолей, ""), 1, 1024) КАК ЗначениеПолейТелефон,
    ЕСТЬNULL(КонтактнаяИнформацияПисьма.Представление, "") КАК ПредставлениеПисьмо,
    ПОДСТРОКА(ЕСТЬNULL(КонтактнаяИнформацияПисьма.ЗначенияПолей, ""), 1, 1024) КАК ЗначениеПолейПисьмо
ИЗ
    ПодписчикиВидыКИ КАК ПодписчикиВидыКИ
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Партнеры.КонтактнаяИнформация КАК КонтактнаяИнформацияПисьма
        ПО ПодписчикиВидыКИ.Получатель = КонтактнаяИнформацияПисьма.Ссылка
            И ПодписчикиВидыКИ.ВидКИДляПисем = КонтактнаяИнформацияПисьма.Вид
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Партнеры.КонтактнаяИнформация КАК КонтактнаяИнформацияТелефон
        ПО ПодписчикиВидыКИ.Получатель = КонтактнаяИнформацияТелефон.Ссылка
            И ПодписчикиВидыКИ.ВидКИДляSMS = КонтактнаяИнформацияТелефон.Вид

так сделано, что права разделять

(32) Если есть твердое желание соответствовать типовым - делать, как в типовых. И не задавать вопросов "А почему колеса квадратные?".

можно и не делать как в типовых, но потом жизнь с ними все равно столкнет. А знать то ты ничего и не будешь

(43) зато упрощает когда нужно докинуть контактную информацию в какой нибудь допсправочник

(42) В той логике и способе реализации как там есть - нет, ничего.

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

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

(7) это связано с реализацией схемы учета товаров в пути. читайте больше ИС. они там еще в этой схеме похоже накосяпорили малость.

Ничего незнающим восьмерочникамтыкателямгалочек посвящается http://catalog.mista.ru/public/974186/

(17) "Чтобы не дублировать код в этих нескольких документах, когда изменив в одном, забываешь про другой."
- внезапно как в 77 ТиС решили сделать. когда в глобальном модуле штатная процедура типа глПроверкаРазрешенияРедактирования(выбдокумент)...

(52) тут как рвз мягко подходим к обьектно ориентированной модели и возможности сложного наследования.
но в 1с еще пешком под стол ходят.

(0) правильный ответ в (35)
в регистре сведений возможно только ОДНО значение с заданными ключами (объект + вид КИ).. а в табличной части сколько хочешь (адресов и телефонов одного вида у одного объекта)..

(54) хрень получится, если напихать в ТЧ одинаковых видов КИ. Будет лежать там 3 юридических адреса, и получишь ты затроение информации при левом соединении с ТЧ КИ.

(55) Ну для юр. адреса дублирование, возможно, недопустимо, а вот для телефона и почты - запросто