5.16

[Bitnikov]

5.16Вложения:
5.16.dt

[sada]

Мой вариант 5.16Вложения:
1Cv8_sada_5_16.dt

[Filippov]

sada, По-моему склад по условиям задачи не требуется - рисунок просто скопирован с рисунка задачи 5.5. И маленькая "грешка" - в запросе надо показать ИТОГИ МАКСИМУМ(Количество) (вместо СУММА)

[ivanovnm]

Свой вариантВложения:
ivanovnm5.16.dt

[unf13]

В новом сборнике задача 5.16 полностью другая. Теперь в ней в основном проверяются знания ПВХ и программное создание элементов и реквизитов формы, как я понимаю. Кто-нибудь решал эту обновленную задачу?

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

 Добавлено (27.08.2014, 15:29)
 ---------------------------------------------
 Мда, что-то я туплю жутко или что. Не пойму, зачем вообще ПВХ у менеджера использовать,если по смыслу задачи, как я понимаю, у менеджера указываются по сути ВИДЫ свойств.  Т.е. можно по идее было бы обойтись подчиненным справочником,т.к. для хранения названий свойств составной тип данных, используемый обычно в ПВХ, не нужен.

 Никто не может подсказать по взаимосвязи объектов?

[prog_ert]

вот мое решение

 https://drive.google.com/file/d/0B6_zRdQzY9vqQ0lhckFjVXpUOHM/edit?usp=sharing

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

[Demy]

Задача простая, но писанины много. Возможно есть более оптимальное решение. Буду благодарен за критику.Вложения:
Demy_5_16.dt

[HitTheRoadJack]

Посмотрел решение demy. В принципе все сделано классно(добавил бы только пожалуй в параметры выбора добавляемых полей отбор по владельцу, когда тип значения поля = справочник значения свойств. Ну это совсем для перфекционизма ), посмотрел в ут 11 на механизм доп. реквизитов, там сделано схожим образом, но с использованием табличной части дополнительные реквизиты в справочнике, скажем контрагенты или номенклатура. Конечно куда более замороченнее (1с это любят . Посмотрев и туда, и туда, сделал что-то схожее с использованием не регистра сведений, а табличной части(как альтернативу решению demy), позаимствовав львиную часть у demy.

[filipich]

Добавлю своё решение. Отличия от предыдущих:
1) у плана видов характеристик добавлен реквизит сотрудник - этим устанавливается принадлежность вида характеристики конкретному Сотруднику (в других решениях используется ТЧ справочника Сотрудники)
2) данные доп.реквизитов контрагентов хранятся в регистре сведений - в других решениях для этого используется ТЧ справочника Контрагенты
Получается такая особенность - так как данные хранятся в регистре, то при смене менеджера у контрагента они не уничтожаются, а только не отображаются в форме - то есть, для каждого менеджера хранятся свои значения  своих доп.реквизитов по данному контрагенту - думаю, это скорее плюс, чем минус.

[axel_work]

Мой вариант. Виды свойств храню в ТЗ в форме справочника, чтобы запросом при записи их не получать

[golod]

Значения доп.реквизитов хранятся в РС (Измерения Сотрудник,Контрагент)
Менеджер-реквизит Контрагента
Не стал делать запись в РС при записи Контрагента( нет условия в задаче) но есть возможность вносить значения в РС вручную.
Проверку на наличие реквизитов при смене менеджера сделал через Конструкцию Попытка-Исключить(меньше кода)
Постарался сделать минимум кода

[fimanich]

Сделал в духе типовых
ПланыВидовХарактеристик.СвойстваОбъектов
Справочник.ДопСведения (подчинен ПВХ)
Справочник.Сотрудники.ТабличнаяЧасть.ДополнительныеСведения (набор свойств для каждого менеджера)
Справочник.Сотрудники.ТабличнаяЧасть.ДополнительныеРеквизиты - хранение значений доп. реквизитов
Справочник.Сотрудники.Форма.ФормаЭлемента - программное создание элементов формы / запись доп. реквизитов из формы

В общем, решение похоже на решение HitTheRoadJack, только в его решение идет обращение к набору свойств с помощью объектной модели Для Каждого Стр Из Объект.Менеджер.ДополнительныеРеквизиты Цикл, в моем решении набор свойств и их значения получаются одним запросом.

[bkmz]

Логика кода такая же как у fimanich (брал его код за основу). Но сделал хранение данных в регистре а на справочнике. И немного причесал

[xdd]

Мой вариант

[void127]

Эта задачка не встречается в актуальных билетах, но она из примеров, приведенных в требованиях ATT83PL.rtf , так что порешал ее на всякий, может по частям где пригодится еще.
1. Обновление элементов доп. свойств в форме Контрагента и у нового, и у существующего (и при открытии, и при смене Менеджера).
2. Значения свойств живут в регистре сведений.
3. В самих элементах ПВХ нет ссылки на Менеджера - хотя так было бы проще, возможно, но дубли видов свойств пойдут.
4. Запись в регистр при записи Контрагента из формы, причем только измененных в форме Контрагента доп. свойств.
5. Отбор по владельцу у программно добавляемых элементов для ссылочных значений доп. свойств, подчиненных ПВХ.

Вышло неплохо, но долго. Видимо, надо сокращать сервис - например, читать в форму контрагента только при открытии, а при смене Менеджера сообщать, чтобы записали и переоткрыли форму элемента - нечего баловать.