Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Контактная информация почему в табличных частях?

Контактная информация почему в табличных частях?
Я
   Buckbister
 
11.01.19 - 02:08
Народ всем ку!

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

Сейчас открыл типовую торговлю 11.3, в ней у каждого справочника своя табличная часть с контактной инфой. А общего регистра нет. С чем это может быть связано?
 
 
   PR
 
1 - 11.01.19 - 02:20
(0) Скорее непонятно, почему было в РС
   Fram
 
2 - 11.01.19 - 02:34
Да, переливают из путого в порожнее..
При этом не имея инcтрументов разбора xml в запросах, хранят информацию именно в xml. Что бл.ть мешало нормализовать и сохранить в формате реляционной БД
   zva
 
3 - 11.01.19 - 07:54
(0) Если присмотреться лучше, то в ТЧ КонтакнаяИнформация есть поле ДействуетС, с типом дата.
Как рекомендует 1С - если необходимо получение среза информации на момент времени или текущего значения показателей, то для этого нужно использовать... ТЧ объекта.
   d4rkmesa
 
4 - 11.01.19 - 07:59
(0) При ближайшем рассмотрении, разницы почти никакой.
   azt-yur
 
5 - 11.01.19 - 08:01
Плюс переноса контактной информации в табличные части я заценил когда пришлось переносить объекты между базами (Выгрузка загрузка XML, и с помощью конвертации). Все находится в одном объекте и не надо думать о настройке дополнительных отборов в регистрах.
   azt-yur
 
6 - 11.01.19 - 08:03
ну и разработчики по этому вопросу отвечают следующее:

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

больше видимо дорабатывать нечего
   Мелифаро
 
8 - 11.01.19 - 08:05
Чтобы допиливальщикам работы подбросить, очевидно же :)
Не, пусть делают, лишний раз клиенты бабло заплатят.
   Звездец
 
9 - 11.01.19 - 08:28
(8) на самом деле это напрягает. Порой бабло можно получать и не зарываясь в тонны бесполезной работы. Да и довольный клиент платит лучше
   Конструктор1С
 
10 - 11.01.19 - 08:31
Так решили разработчики БСП.

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

Казалось бы, для подавляющего большинства управленческих задач такой запрос вполне подойдёт. Но нет, это не наш метод, слишком просто. Лучше мы в каждом запросе будем делать по несколько левых соединений с ТЧ контактной информации
 
 Рекламное место пустует
   Aleksey
 
11 - 11.01.19 - 08:33
(10) ИНаче 1С тормозить не будет. Видно это производители железа заносят чемоданы в 1С, чтобы они писали тормознуть код
   ДенисЧ
 
12 - 11.01.19 - 08:38
(7) Потому что при, например, неотфактурованных поставках - приобретение и  поступление - это две разные операции.
   azt-yur
 
13 - 11.01.19 - 08:45
(7) Иначе чем издевательство над пользователями и внедренцами я такое назвать не могу. То обновление заняло в разы больше времени чем положено.
Или их постоянные перетасовки процедур между модулями. В последнем обновлении КА/ERP перетасовали половину процедур проведения из модуля менеджера в общие модули. Как они представляют работу с расширениями? были замененные процедуры, теперь их нет, расширение не работает, сравнения расширений с конфигурацией нормального тоже нет.
Похоже разработчиками зарплату платят от количества выпущенных релизов и объема измененного кода, 8 релизов ERP за квартал, мне кажется это слишком.
   Конструктор1С
 
14 - 11.01.19 - 08:49
(12) можно было просто поменять синоним документа, но наверно это слишком просто
(13) видимо изобрели новый внутренний стандарт
   unregistered
 
15 - 11.01.19 - 08:50
(10) > для подавляющего большинства управленческих задач такой запрос вполне подойдёт.

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

Решение должно быть единым и универсальным. Иногда в ущерб простоте и скорости.
Пихать в каждый справочник (партнеры, физлица, сотрудники, организации, ...) несколько десятков полей различной контактной информации тоже нельзя назвать хорошим решением.
   oslokot
 
16 - 11.01.19 - 08:51
(11) чем медленнее работает система, тем более солидней она выглядит (с)
   unregistered
 
17 - 11.01.19 - 08:52
(14) > видимо изобрели новый внутренний стандарт

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

Проблема в том, что делается это (перетасовка кода) слишком часто.
   zva
 
18 - 11.01.19 - 08:54
А зачем в последней УТ11 добавили две константы?
1. НеНоваяАрхитектураВзаиморасчетов
2. НоваяАрхитектураВзаиморасчетов
Обе булево...
   PR
 
19 - 11.01.19 - 08:54
Понабежали плакальщики
Пользуйтесь экселем и УТ 10, там хрен че поменяется, раз в сто лет
   azt-yur
 
20 - 11.01.19 - 08:56
(17) Да вот если бы этот код где то еще использовался. Были процедуры в модуле менеджера документа ОтчетОРозничныхПродажах, добавили общий модуль ОтчетОРозничныхПродажахПроведение (дословно не помню может по другому называется) и перенесли туда часть процедур, в чем целесообразность этого?
   mikecool
 
21 - 11.01.19 - 08:59
(18) для функц. опций
   Конструктор1С
 
22 - 11.01.19 - 09:05
(15) это яркий пример того, как "универсальность" вставляет палки в колёса на каждом шагу. Вообще, разработчиков типовых конфигураций можно понять, они пытаются впихнуть невпихуемое - удовлетворить потребности тысяч клиентов с различной спецификой, от мала до велика. Другое дело, что подходы фирмы 1С порой очень усложняют доработку типовых конфигураций. Добавление одного нового поля в несколько документов может вылиться в неделю доработок.
   Поток сознания
 
23 - 11.01.19 - 09:26
Раньше говорили, что нужно всё в отдельных регистрах хранить, чтобы объект не утяжелять, ибо он считывается со всеми своими ТЧ. Походу концепция поменялась.
   unregistered
 
24 - 11.01.19 - 09:35
(20) > в чем целесообразность этого?

Не знаю. Но какая-то причина точно была. Нет под рукой сейчас установленной ERP, чтобы посмотреть.
   unregistered
 
25 - 11.01.19 - 09:39
(23) > Походу концепция поменялась.

B да и нет. Кардинально концепция не менялась.
Для каждого случая принимается своё решение.
Что касается единого регистра сведений КИ, то тут уже упоминали критическую проблему такого подхода. Это права доступа. RLS на такой регистр убивает производительность. Для больших баз (в особенности типа ERP) это смерти подобно.
   unregistered
 
26 - 11.01.19 - 09:44
(22) А как ты хотел? Чем более универсально и функционально решение, тем более оно сложно. Это естественный процесс. Функциональность типовой бухни 3.0 на снеговике и 4.5 на клюшках - это день и ночь. Хотя для конкретно взятого бухгалтера какого-нибудь ларька она незаметна.
   youalex
 
27 - 11.01.19 - 09:51
(10) Делать реквизитами объекта - неуниверсально. Если будет нужен новый вид КИ - рек добавлять?
   VladZ
 
28 - 11.01.19 - 10:18
(0) И зачем тебе это знать? Что ты будешь делать с этим знанием?
   Eiffil123
 
29 - 11.01.19 - 10:24
Сделано в виде табчастей, когда в 1С начали заморачиваться с сохранением конфиденциальной/персональной информации по физлицам (права на регистр сведений на чтение есть у всех, а на справочник - редактируются ролями).

(10) Для запросов в СКД работа с допреквизитами примерно так и выглядит (как будто с обычными реквизитами справочника). Только допреквизиты нужно выводить в режиме предприятия, но не думаю, что это большая сложность.
   bolder
 
30 - 11.01.19 - 10:29
(25) Спасибо.Самое верное объяснение.
   Конструктор1С
 
31 - 11.01.19 - 10:50
(27) скажем так, для 98% организаций зоопарк из контактной информации нафиг не нужен. Им достаточно адреса (ну пусть с разделением на юридический и фактический), поля для телефонов и поля для электронки. Всё.
   Buckbister
 
32 - 11.01.19 - 15:05
(28) Разрабатываем конфу с нуля. Естесственное желание - чтобы максимально соответствовать типовым. Но при этом не хочется бороться со здравым смыслом. И чтобы в долгосрочной перспективе учесть те грабли, о которых еще не знаем.
   Конструктор1С
 
33 - 11.01.19 - 15:09
(32) подсистема КИ относится к тем, которые можно и нужно не использовать.
 
 
   Buckbister
 
34 - 11.01.19 - 15:11
(33) Ну если речь о БСП - то там я вообще не нашел, что можно использовать
   Fish
 
35 - 11.01.19 - 15:13
(31) "поля для телефонов и поля для электронки" - Сколько полей для телефонов и сколько для электронки ты заложишь? По одному маловато будет.
   Конструктор1С
 
36 - 11.01.19 - 15:58
(35) что мешает все телефоны писать в одном поле? Аналогично с электронкой
   CepeLLlka
 
37 - 11.01.19 - 16:08
(0)От всех таких вот пертурбаций сразу думается что в 1С слишком много женщин на руководящих должностях..
   Ник080808
 
38 - 11.01.19 - 16:08
(36) телефон для смс рассылки, телефон оператора, телефон директора, электронка для переписки, электронка для рассылки это миниму который есть практически во всех торговых конторах
   Конструктор1С
 
39 - 11.01.19 - 16:14
(38) если так, то можно прикрутить подчиненный справочник контактных лиц, и там заполнять простое текстовое поле. И если спам по смс и электронке входит в специфику работы организации, то одним легким движением руки можно прикрутить к справочнику два текстовых поля
   Ник080808
 
40 - 11.01.19 - 16:15
(39) так для этого и есть подсистема контактной информации)))
   Ник080808
 
41 - 11.01.19 - 16:18
(34) серьезно?
   Ник080808
 
42 - 11.01.19 - 16:22
(34) то есть вам в конфигурации не нужен вообще никакой функционал, который есть в бсп?
   Конструктор1С
 
43 - 11.01.19 - 16:58
(40) использование подсистемы КИ усложняет разработку. Вместо банальных запросов типа (10) придется городить запрос, где на каждый вид нужной КИ придется делать левое соединение с ТЧ КИ. Сравни (10) и запрос из типовой конфы:

ВЫБРАТЬ
    ПодписчикиВидыКИ.ИсточникОповещения,
    ПодписчикиВидыКИ.Подписчик,
    ПодписчикиВидыКИ.Получатель,
    ПодписчикиВидыКИ.ПредставлениеПолучателя,
    ЕСТЬNULL(КонтактнаяИнформацияТелефон.Представление, "") КАК ПредставлениеТелефон,
    ПОДСТРОКА(ЕСТЬNULL(КонтактнаяИнформацияТелефон.ЗначенияПолей, ""), 1, 1024) КАК ЗначениеПолейТелефон,
    ЕСТЬNULL(КонтактнаяИнформацияПисьма.Представление, "") КАК ПредставлениеПисьмо,
    ПОДСТРОКА(ЕСТЬNULL(КонтактнаяИнформацияПисьма.ЗначенияПолей, ""), 1, 1024) КАК ЗначениеПолейПисьмо
ИЗ
    ПодписчикиВидыКИ КАК ПодписчикиВидыКИ
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Партнеры.КонтактнаяИнформация КАК КонтактнаяИнформацияПисьма
        ПО ПодписчикиВидыКИ.Получатель = КонтактнаяИнформацияПисьма.Ссылка
            И ПодписчикиВидыКИ.ВидКИДляПисем = КонтактнаяИнформацияПисьма.Вид
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Партнеры.КонтактнаяИнформация КАК КонтактнаяИнформацияТелефон
        ПО ПодписчикиВидыКИ.Получатель = КонтактнаяИнформацияТелефон.Ссылка
            И ПодписчикиВидыКИ.ВидКИДляSMS = КонтактнаяИнформацияТелефон.Вид
   Вафель
 
44 - 11.01.19 - 17:11
так сделано, что права разделять
   VladZ
 
45 - 11.01.19 - 17:13
(32) Если есть твердое желание соответствовать типовым - делать, как в типовых. И не задавать вопросов "А почему колеса квадратные?".
   Вафель
 
46 - 11.01.19 - 17:15
можно и не делать как в типовых, но потом жизнь с ними все равно столкнет. А знать то ты ничего и не будешь
   Ник080808
 
47 - 11.01.19 - 17:38
(43) зато упрощает когда нужно докинуть контактную информацию в какой нибудь допсправочник
   Buckbister
 
48 - 11.01.19 - 20:20
(42) В той логике и способе реализации как там есть - нет, ничего.
   Dzenn
 
49 - 11.01.19 - 22:39
А что тебя удивляет? Всё абсолютно логично. Кому информация принадлежит — там она и лежит. То, что виды и типы контактной информации одинаковы для различных типов данных, не говорит о том, что она должна лежать в одном месте. В конце концов, у каждого справочника есть реквизит Наименование, но это не означает, что Наименование будет лежать для всех справочников в одном месте или в отдельном справочнике. Смотри на мир ясными глазами и избавляйся от стереотипов.
 
 Рекламное место пустует
   Сияющий в темноте
 
50 - 11.01.19 - 23:09
Для выборки значений,что регистр,что табличная часть,разницы особой нет,просто,в регистр можно писать информацию сразу для нескольких справочников,а табличные части у каждого справочника свои.
опять же,например,привязка допреквизитов требует в справочнике делать табличную часть,а когда они были все в одном регистре,то нужно было только в поле владельца добавить вариант значения.
в 1с криво реализованы составные типы,и поэтому,решено максимально от них избавится.
   Злопчинский
 
51 - 11.01.19 - 23:45
(7) это связано с реализацией схемы учета товаров в пути. читайте больше ИС. они там еще в этой схеме похоже накосяпорили малость.

Ничего незнающим восьмерочникамтыкателямгалочек посвящается http://catalog.mista.ru/public/974186/
   Злопчинский
 
52 - 12.01.19 - 00:31
(17) "Чтобы не дублировать код в этих нескольких документах, когда изменив в одном, забываешь про другой."
- внезапно как в 77 ТиС решили сделать. когда в глобальном модуле штатная процедура типа глПроверкаРазрешенияРедактирования(выбдокумент)...
   Сияющий в темноте
 
53 - 12.01.19 - 01:00
(52) тут как рвз мягко подходим к обьектно ориентированной модели и возможности сложного наследования.
но в 1с еще пешком под стол ходят.
   runoff_runoff
 
54 - 12.01.19 - 03:35
(0) правильный ответ в (35)
в регистре сведений возможно только ОДНО значение с заданными ключами (объект + вид КИ).. а в табличной части сколько хочешь (адресов и телефонов одного вида у одного объекта)..
   Конструктор1С
 
55 - 12.01.19 - 04:28
(54) хрень получится, если напихать в ТЧ одинаковых видов КИ. Будет лежать там 3 юридических адреса, и получишь ты затроение информации при левом соединении с ТЧ КИ.
   Cyberhawk
 
56 - 12.01.19 - 09:48
(55) Ну для юр. адреса дублирование, возможно, недопустимо, а вот для телефона и почты - запросто


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует