Базовый курс. Решение ДЗ №6
Представляем решение шестого домашнего задания.
К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте
— залогиньтесь.
— залогиньтесь.
Если не активировали токен — посмотрите видео-инструкцию (видео N5)
Если вы залогинены, у Вас активирован токен доступа, но вы все равно видите эту запись —
напишите нам на e-mail поддержки.
Выполнил ДЗ 6 – правда организовал связь справочника “Контактные лица” через табличную часть справочника “Контрагенты”
Имеет ли право на жизнь такой запрос на отбор контрагентов в обработке?
“ВЫБРАТЬ
| Контрагенты.Ссылка КАК Контрагент
|ИЗ
| Справочник.Контрагенты КАК Контрагенты
| ЛЕВОЕ СОЕДИНЕНИЕ Справочник.КонтактныеЛицаКонтрагентов КАК КонтактныеЛицаКонтрагентов
| ПО (КонтактныеЛицаКонтрагентов.Владелец = Контрагенты.Ссылка)
|ГДЕ
| (НЕ Контрагенты.ЭтоГруппа)
| И КонтактныеЛицаКонтрагентов.Ссылка ЕСТЬ NULL”
Да, этот вариант решения является правильным.
Понятно. Спасибо.
Здравствуйте!
Проясните, пожалуйста, положение в задании: “Обеспечьте, чтобы при записи нового элемента справочника номенклатура создавалась единица измерения с коэф. 1, соответствующая базовой единице (дублирования не нужно допускать)”. Вопрос по дублированию . Что имеется ввиду? В решении дублирование наименований новых единиц происходит.
Согласен формулировка не совсем однозначная.
Речь шла о том, что не нужно при каждой записи номенклатуры записывать единицу измерения, а только при записи нового элемента.
1. Реквизит “Телефон” сделан длиной в 30 символов.
Почему бы вообще для строк не использовать строки неограниченной длины, все равно в базе они хранятся кусочками по 10 символов? Минус, конечно, невозможность индексирования, Но в данном случае оно вряд ли будет необходимо.
2. Установка свойства “Проверка заполнения” для реквизита БазоваяЕдиница приведет к тому, что система все равно будет подчеркивать его красным, хотя заполнять-то его можно не всегда. С точки зрения пользователя, это некорректное поведение программы – ибо раз подчеркнуто, значит надо заполнить. В итоге, кто-то из пользователей будет шлепать услуги штуками, а кто-то, зная, как работает система, не будет вводить едиицу измерения. Как следствие – получаем зоопарк. Я думаю, правильнее проверять этот реквизит в обработчике “ПередЗаписью” проверяя единицу на пустоту и вид номенклатуры на услугу.
3. Не очень понятно, зачем вообще записывать базовую единицу в подчиненный справочник. Ну, если в качестве упражнения, то понятно, но в реальных условиях такое не требуется.
1. Важно понимать, что строки неограниченной длины – дополнительная нагрузка на систему.
Связано это с форматом хранения таких строк: они хранятся в отдельной таблице (для каждого объекта конфигурации есть таблица для хранения строк неограниченной длины). Таким образом, и чтение и запись строк неограниченной длины – более долгая операция, чем обращение к обычному реквизиту.
То есть, использовать такие строки нужно только при необходимости.
2. Пожалуй, да. И свойство “Проверка заполнения” нужно заполнять программно в зависимости от типа номенклатуры.
3. Базовая единица нужна в подчиненном справочнике, так как в дальнейшем она может быть выбрана в качестве единицы измерения в документах.
То есть и в реальных условиях такое требуется, все зависит от постановки задачи.
Не могли бы Вы по подробней объяснить почему нам не подходит вариант с табличнной частью в справочнике “Контрагенты”, где будет указано контактное лицо и должность.
Мне представляется слабым местом такой реализации случай, когда в документе будет требоваться указать только контактное лицо, без указания контрагента. Но ведь если контактное лицо имеет одинаковую должность в разных организациях (к примеру бухгалтер), то при выборе пользователю придется выбирать из списка выбора два элемента с одинаковым наименованием и одинаковой должностью. Что опять же приведет к необходимости сначало указать Контрагента. Если конечно пользователь не помнит с каким кодом контактное лицо соответствует конкретному контрагенту.
>Мне представляется слабым местом такой реализации случай, когда в документе будет требоваться указать только контактное лицо, без указания контрагента.
Слабым местом такой реализации является возможность выбора контактного лица в любом объекте.
Разберем на примере:
1. Контрагент Алхимов. В его табличной части 2 строки: Иванов – бухгалтер, Петров – ген. директор.
2. В некотором документе необходимо выбирать контрагента и его контактное лицо.
3. Пользователь в документе выбирает Алхимова. Как пользователю показать для выбора только двух контактных лиц?
Только программно – открывать форму выбора с отбором по списку контрагентов, а для того чтобы этот список сформировать нужно сделать запрос, а значит обращение на сервер.
4. Пользователь выбрал контактное лицо Иванов.
5. Другой пользователь редактирует данные Алхимова: удаляет обе строки из табличной части.
Теперь получается, что в документе выбрано контактное лицо не соответствующее контрагенту. А это неустойчивость системы.
Другое дело подчиненный справочник: и устойчивость обеспечивается и программировать ничего не требуется.
Все понял. Спасибо.
Прошу прощения и быть может я не верно понял, однако позвольте продолжить – если сделать подчиненный справочник “Контактные лица”, тогда мы имеем дело с двойным вводом данных, ибо исходя из текста задания видно, что ”
Иванова Мария является главным бухгалтером организации
«Альфа» и кассиром организации «Бетта»”
“, тогда как целью автоматизации, как правило, стоит исключение дублирования информации, а пункт 5 Вашего комментария можно и адресовать и к реализации с подчиненным справочником(в смысле другой пользователь очистил быстренько подчиненный справочник).
Вопрос снимается – увидел в Вашем видео решении ответ на свой комментарий
Уже успел ответить на вопрос :)
Не совсем так.
Если контактное лицо уже использовалось в документах, то удаление помеченных объектов не позволит выполнить непосредственное удаление. Так как есть ссылки.
Конечно, можно программно удалить и без контроля ссылочной целостности, но такие действия разработчик делает на свой страх и риск.
Что касается двойного ввода данных, это не так.
Ввод действительно распадается на две итерации, но двойного ввода нет.
1. В справочнике “Контактные лица”, указываем, что есть такой человек как Иванова Мария, ее год рождения, личные данные.
2. В справочнике “Контактные лица контрагентов” мы указываем должность в которой Иванова Мария работает у конкретного контрагента.
В дз7 за основу брать Вашу конфигурацию или свою
Чтобы процесс обучения был наиболее эффективным, лучше взять свою конфигурацию.
Блин. Неправильно прочитал задание и результат моего запроса в обработке работает с точностью до наоборот :)
При замене базовой единицы измерения не создается новая единица измерения, например по ошибке пользователь может не ту единицу задать.
Да, такая ситуация не обрабатывается.