Домашнее задание №6 базового курса
11.07.2010
комментария 132
Третье задание по 1-му блоку базового курса.
Для выполнения рекомендуется изучить следующие главы 1-го блока.
Глава 9. Формы.
Глава 10. Перечисления.
Глава 11. Администрирование.
Глава 12. Роли.
Глава 13. Пользователи.
Глава 14. Параметры ИБ.
Глава 15. Резервные копии.
Глава 16. Отладка.
Глава 17. Работа с запросами к БД.
К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте — залогиньтесь. Если Вы оплачивали курс, у Вас активирован токен доступа, Вы залогинены, но Вы видите эту запись — напишите нам на e-mail поддержки.
Выполнил легко. Все получилось так же, как в вашем решении, за исключением обработки, где в запросе использовал левое соединение и группировку.
Выполнил. С контрагентами и контактными лицами был слишком зациклен на подчинении контактных лиц контрагентам – пришлось смотреть. И с событием ОбработкаЗаполнения() ступил.
выполнил. отчитываюсь за давно выполненные задания и освежаю память. смутила в задании фраза “При создании элемента справочника нужно анализировать”. поэтому ринулся в процедуру присозданиинасервере….
Выполнил. Над некоторыми вещами пришлось подумать :)
Задание выполнено!
ДЗ № 6 выполнено.
Все получилось.
Давно готово
Выполнил.
ДЗ №6 сделано
Выполнено
То же давно сделал!
Выполнено уже давно. Отчитываюсь!
От же, жадность. Не сплю, вспоминаю что когда то , что то делал.
Готова.
ПРОБЛЕМА #1: Для наследования ВидаНоменклатуры пытался сначала для ФормыЭлемента/ФормыГруппы отрабатывать событие создания формы ПриСозданииНаСервере() – не получилось, данный обработчик не отрабатывает (отладчик не ходит по этому обработчику) – что я не так делал?
Просьба прокомментировать.
ПРОБЛЕМА #2: Не рассмотрен следующий вопрос Для наследования ВидаНоменклатуры: (рассмотрим в качестве обучения): интерактивно ввели новый элемент/группу – все наследовалось ОК, не записали еще! выбираем в форме элемента/группы нового родителя – как методически правильно отработать наследование от вновь выбранного родителя? Как методически правильно определить что перевыбор родителя сделан для нового элемента/группы (с учетом что элемент м.б. скопирован)? ОбработкаВыбора(ВыбранноеЗначение, ИсточникВыбора)…? как вычислить в каком поле/что это меняем родителя?
Просьба прокомментировать.
ПРОБЛЕМА #3: Учитель ловко ушел ;-) от клинча с единицами измерения номенклатуры. Базовая единица измерения – такая же единица измерения, как и прочие – и ее место в подчиненном справочнике единиц, а не в качестве реквизита справочника Номенклатуры с типом “Классификатор единиц”. Тем более что и у базовой, наравне с остальными единицами, есть ШК, вес, габариты, прочее.
Понятно, что скорее всего, упрощение с базовой единицой, было сделано для неутяжеления решения. Но тем не менее, представляет определенный интерес решение клинчевой задачи: нельзя записать новую номенклатуру без базовой единицы (которая будет в подчиненном справочнике!), в то же время нельзя записать базовую единицу без записи элемента-владельца номенклатуры. Как выйти из этого клинча? Просьба дать хотя бы идейное описание решения… Мне видится необходимость, например, введения Константы.БазоваяЕдиницаИзмерения с типом Спр.ОКЕИ и подставления ее по умолчанию в поле ввода (какое?), а при записи новой номенклатуры – автогенерации спр.ЕдиницыИзмеренияНоменклатуры “на базе” константы. Но опять же – что делать если вместо умолчальных “штук” потребуются “бидоны” – записывать элемент-владеоец и.т.д – а если после всех этих манипуляций пользователь раздумал вносить “новый” (уже записанный!) элемент номенклатуры – надо удалять его, его подчиненную единицу… – как делать правильно методически?
Просьба прокомментировать.
Маленькая проблемка #4: нерешен вопрос когда в справочнике по сути не нужен ни код, ни наименование, например: спр.ЕдиницыИзмеренияНоменклатуры – элемент справочника однозначно идентифицируется ссылкой на ОКЕИ и коэффициентом. Что делать с основным представлением элемента – плохо получается.. искуственно “именовать/дублировать” в наименование элемента наименование ОКЕИ+Кф… – как-то неаккуратненько…
Вторая проблема в части “как узнать что перевыбор родителя в форме нового элеменат” – поднял “старую” переписку: Объект.Ссылка.Пустая() – только тут надо быть уверенным что Объект – это “элемент справочника”…
Можно и так проверить.
ПРОБЛЕМА #1. Вообще должен отладчик останавливаться на этой процедуре.
Что нужно проверить:
1. Указанный серверный метод формы действительно выбран в качестве обработчика события “ПриСозданииНаСервере” самой формы.
2. Точка останова находится в на сроке “КонецПроцедуры”.
3. Можно использовать отладочную печать, бывают случаи что точка останова не срабатывает (крайне редко, закономерности не выявил).
ПРОБЛЕМА #2. Хороший вопрос. Здесь нужно понять нужно ли вообще такой механизм реализовывать. Допустим, что нужно.
Тогда можно отслеживать изменение Родителя в обработчике ПриИзменении поля формы.
Проверку на то, что перед нами новый элемент на клиенте можно осуществлять так: Параметры.Ключ.Пустая().
Признак копирования простым путем никак не получить. Но, полагаю, что он и не нужен.
проблема1: заборол! форма не была назначена формой объекта(элемента).
.
рабочее замечание:
Конфигуратор слишком “развесист” и чтобы получить полные сведения о форме – приходится с нее “убегать”.. как, например, работая с формой (которых может быть много!) получить “исчерпывающие” данные по этой форме? – а никак! (или я не нашел?).. в палитре: нигде не сказано что форма, назначена(не назначена) в качестве формы элемента(группы, списка итд) (или я не нашел?) чтобы понять что форма куда-то назначена/не назначена – надо идти на палитру самого объекта (которому принадлежат формы). Представляется целесообразным например? в дереве метаданных в подветке форм писать не просто имя формы, а например,
.
ИмяФормы(свободная) или
ИмяФормы(форма группы) или
в заголовке инструментального окна
Справочник Номенклатура: ИмяФормы (свободная или ФормаГруппы)
.
иля вообще ничего не понимаю.. ;-)
Я основные формы открываю через контекстное меню объекта. И быстро, и точно уверен, что работаю с основной формой.
ПРОБЛЕМА #3. Клинч имеет место быть.
Для решения задачи можно применить следующий подход. Элемент в подчиненный справочник записывать в событии ПриЗаписи, когда ссылка уже есть.
Здесь же присваивать значение реквизиту ЕдиницаИзмерения. Но, если дополнительных действий не предпринять, то реквизит ЕдиницаИзмерения не будет записан.
Поэтому в ПриЗаписи, если устанавливается реквизит ЕдиницаИзмерения, нужно делать еще и принудительную запись – Записать.
У этого способа есть серьезный недостаток – события ПередЗаписью и ПриЗаписи будут вызваны дважды.
Но есть и смягчающее обстоятельство – событие ОбработкаЗаполнения будет вызывано только один раз.
Евгений, вроде же есть методы ПолучитьСсылку, УстановитьСсылкуНового как раз для таких ситуаций, так как двойная запись это очень плохо для масштабируемости.
IMHO, тема вполне заслуживает того, чтобы ее разобрать в очередной сессии мастер-группы.
Все верно, Юрий.
Рассмотрим в сегодняшней сессии МГ этот интересный вопрос.
или чего-то не понял или еще что…
расмотрим, например, когда в базовую единицу надо вписать много всего: океи, коэффициент, ШК, вес, габариты – я себе слабо представляю откуда это все возьмется в ПриЗаписи… хочется “штатно”: открылся новый элемент, вписали всякие реквизиты в базовую единицу -(в подч.справочник не впишешь – ссылки владельца нет… вписывать в некий “эмулятор подч.справочника”…? а потом ПриЗаписи(или еще где есть ссылка на владельца) – перекидывать в подч.справочник?.
.
и тут я придумал (весьма) изящное решение: 1. для спр.Номенклатуры имеем подчиненный спр.ЕдиницыИзмеренияНоменклатуры.
2. имеем для спр.Номенклатура ТЧ! полностью повторяющую структуру спр.ЕдиницыИзмеренияНоменклатуры
3. при открытии формы нового элемента на форме элемента делаем видимой ТЧ (или подменяем форму элемента на форму элемента с ТЧ) – туда можно писать все нужные единицы – а уже при записи нового элемента номенклатуры “перекачиваем” единицы из ТЧ (в ней удаляем) в подчиненный справочник единиц.
4. при открытии существующего элемента – ТЧ не показываем.
.
пройдет ли такое “решение”?
.
как вариант: вместо подчиненного справочника единиц используем соответсвующую ТЧ, а для использования единиц измерения в Документах – изворачиваемся “хитрым” приемом введения в ТЧ дополнительного “служебного” (непоказываемого) реквизита “Ссылка” (такой вариант рассматривался в комментах).
.
надеюсь увидеть интересный развернутый анализ сего интересного “академического” вопроса в МГ с разных точек зрения/решения…
Первый вариант кажется громоздим.
Второй вариант (с реквизитом табличной части Ссылка) совсем не нравиться. Так как в каждом документе придется предусматривать эту нестандартную ссылку.
Предлагаю другое решение:
1. Справочник “Единицы измерения” подчинен номенклатуре. В этом справочнике заведены все дополнительные реквизиты.
2. В форме элемента справочника “Номенклатура” создаем динамический список, который выбирает данные из подчиненного справочника.
3. Отображаем динамический список в виде таблицы формы.
4. Делаем таблицу недоступной до тех пор, пока элемент не будет записан.
Таком образом, пользователь будет сразу вводить данные в справочник “Единицы измерения”. Ничего никуда перекидывать не нужно.
хм.. а как в предложенном решается “академическая” задача клинча (если делать по уму домашнее задание)? – элемент нельзя записывать пока не задана базовая единица..?
Решение задачи “клинча” описано в последней сессии МГ.
Маленькая проблемка #4. Сергей, я давал ответ на этот вопрос в видео МГ. Воспользуйтесь поиском по сайту.
ниже комментировать можно кратко или давать “пинок” в требуемом направлении…
.
1. Наследование ВидаНоменклатуры: ОбработкаЗаполнения(ДанныеЗаполнения,…) – проверяется наличие реквизита “Родитель” – зачем это надо делать? Получается что, при выключении в конфигураторе иерархии – реквизит “Родитель” может отсутствовать? Почему проверять тогда “Родитель”, а не сам факт наличия иерархии, заданной в конфигураторе(метаданных)? или наличие иерархии в программном режиме ТОЛЬКО и определяется наличием реквизита “Родитель”…?
Просьба прокомментировать.
2. Наследование ВидаНоменклатуры: ОбработкаЗаполнения(ДанныеЗаполнения,…) в СП прямо не сказано, в прошедших уроках явно не было заострено внимание (?или я пропустил), что переход в группу ЕСТЬ ОТБОР по родителю…? Аналогично ли подчиненный справочник = отбор/фильтр по Владельцу и где это может всплыть в параметрах, аналогичных вышеописанному…?
Просьба прокомментировать.
3. Правильно ли я понял, что в управляемых формах нет никакого иного способа интерактивного перехода в подчиненный справочник с заполненным полем Владелец кроме как из панели навигации справочника-владельца?
Просьба прокомментировать.
4. Если предположить (в качестве учебы) что для номенклатуры с видом “Услуга” НЕ ДОЛЖНО ЗАДАВАТЬСЯ ЕДИНИЦ ИЗМЕРЕНИЯ ВООБЩЕ – как отключить (программно?) показ в управляемой форме панели навигации со ссылкой на подчиненный справочник единиц измерения?
Просьба прокомментировать.
5. Например, у меня получилось, что для справочника классификатора единиц измерения автоматически генерируемая форма списка выводит колонки в таком порядке: наименование-код. Где в пользовательском режиме настроить порядок вывода – нашел, а в конфигураторе чем определяется автоматический порядок колонок для автогенерируемой формы? как перейти во всех автоформах к более привычному порядку код-наименование…?
Просьба прокомментировать.
6. Почему при вызове формы элемента из формы списка форма элемента открывается модально? как “включить” режим немодальности? (наверное, я что-то тут забыл… вроде как было это?)
Просьба прокомментировать.
7. При изменении режима просмотра (пользовательского) справочника из иерархического списке в плоский список – можно создавать элементы! создает в корне, что может принести достаточно много траблов – как это запретить (в 7.7 при плоском списке – ввод новых элементов был отключен)?
Просьба прокомментировать.
Наблюдение #1: Нет необходимости анализировать есть ли родительская группа (для элемента или вложенной группы), определен ли для нее вид номенклатуры – все прекрасно сработает при тупом присвоении ВидНоменклатуры = ДанныеЗаполнения.Родитель.ВидНоменклатуры; – для любого уровня группы/элемента
Наблюдение #2: При иерархическом списке – при положении курсора на группе самого верхнего уровня – создается элемент/группа В КОРНЕ, При древововидном списке – создается элемент/группа В СООТВЕТСВУЮЩЕЙ ГРУППЕ… – чревато траблами… Как запретить в пользовательском режиме переключать режим отображения из конткстного меню? как убрать режим переключения отображения списка из “всех действий” для автогененрируемых форм?
Просьба прокомментировать.
Наблюдение #3: при назначении одной основной формы и для элемента и для группы – автоматически система при отображении формы в режиме пользователя не понимает, что не следует (имхо) отображать на форме группы те реквизиты формы, объекты которых (реквизиты справочника) – “для элемента”.. как-то ожидалось большей интеллектуальности от платформы…
Наблюдение #4: При первом открытии формы элемента справочника – не автомасштабирует размер с учетом табличной части… – приходится растягивать вниз; аналогично при наличии панели навигации для формы списка справочника – приходится растягивать вправо – как-то ожидалось большей интеллектуальности от платформы…
Замечание #5: из задания “При создании элемента справочника нужно анализировать определен ли вид номенклатуры у родительской группы. Если да, то нужно подставить данный вид для нового элемента.” – совершенно четко следует, что ДОПУСКАЕТСЯ создание групп (но не элементов!) с незаполненным ВидомНоменклатуры. При этом в конфигураторе выставлено требование “заполненения и подчеркивания красным” – что (как вариант) будет приводить к “ступору” пользователей. Поэтому требуется создать ФормуГруппы (не автогенерируемая), на реквизит “ВидНоменклатуры” снять подчеркивание красным, а ОбработкуЗаполнения модернизировать следующим образом, типа:
&НаСервере
Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
Если ЭтоГруппа
Тогда
Индекс = ПроверяемыеРеквизиты.Найти(“ВидНоменклатуры”);
Если Индекс Неопределено
Тогда
ПроверяемыеРеквизиты.Удалить(Индекс);
КонецЕсли;
Возврат;
КонецЕсли;
Если ВидНоменклатуры = Перечисления.ВидыНоменклатуры.Услуга
Тогда
Индекс = ПроверяемыеРеквизиты.Найти(“БазоваяЕдиницаИзмерения”);
Наблюдение #6: снятие требования “подчеркивать красным” не отменяет манипуляций с исключением из проверяемых реквизитов.
Наблюдение #7: при конструировании запроса синтаксис Контрагент.Ссылка НЕ В (Выбрать…) сам сабой трансформировался в НЕ(Контрагент.Ссылка В….)
1. В Обработка заполнения вот такое выражение
ТипЗнч(ДанныеЗаполнения)=Тип(“Структура”) И ДанныеЗаполнения.Свойство(“Родитель”)
возвращает Истину, когда новый элемент вводится внутри группы. То есть в этом случае нужно наследовать вид номенклатуры.
Если элемент вводится вне группы, то свойство “Родитель” в параметре ДанныеЗаполнения отсутствует.
2. Да, в СП явно не сказано. Но мы коротко об этом говорили.
По подчиненным справочникам тоже автоматически устанавливается отбор.
Если список подчиненных элементов отрывается по ссылке панели навигации из формы элемента справочника-владельца, то автоматически устанавливается отбор по владельцу.
Например, если из карточки номенклатуры открыть список единиц измерения, то будет установлен отбор (откройте Все действия – Настроить список).
3. Да, это единственный стандартный способ.
4. Такого поведения возможно добиться, но не совсем просто.
Дело в том, что в явном виде мы не можем программно управлять составом панели навигации (действий).
Для этого необходимо использовать функциональные опции. Для приведенной задачи необходимо использовать параметризуемые функциональные опции.
Где параметр задавать программно при открытии формы.
Подробно об этом механизме мы говорим в рамках 0-го блока продвинутого курса.
5. Это умолчание платформы, его не переопределить.
И дело здесь вот в чем. В большинстве случае код элемента справочника не играет для пользователя никакой роли, важно наименование.
Поэтому логично выводить наиболее значимые реквизиты первыми.
Новый подход применим только для управляемых форм, в обычных формах порядок прежний: Код – Наименование.
6. Нет этого не было в курсе.
Для достижения необходимого результата нужно в свойствах формы элемента установить РежимОткрытияОкна в значение Независимый.
7. Зачем запрещать? До сих пор помню те тяжелые времена, когда нужно было часто отвечать на вопрос так – нажмите 4-тую (уже не помню точно по счету какая она) кнопку справа в командной панели, тогда элемент создастся.
Понятно, что привычка, но нужно отвыкать от плохого. Естественно, если создается новый элемент вне группы, то он и будет находится в корне.
Но, если все же требуется запретить, то рекомендую в форме создать обработчик события ОбработкаЗаполненияНаСервере( ), где проверять текущее Отображение (свойство таблицы формы). Если его значение “Список”, то выдавать грозное предупреждение и не создавать элемент.
1. да, оказывается проверка наличия в данных заполнения “Родителя” нужна. Только на тот случай если на список УСТАНОВЛЕН какой-нибудь ОТБОР и элемент вводится ВНЕ ГРУПП.
интересное наблюдение:
.
Попутно обнаружилось, что устанавливаемый на список отбор применяется ТОЛЬКО К ЭЛЕМЕНТАМ, на группы – не действует… Применил отбор “Вид номенклатуры = Услуга” – группы с “видом номенклатуры = товар” – видны, элементы – не видны… с одной стороный вроде неправильно, а с другой – логично…
.
но вот в иерархии элементов – уже “другое” поведение, например: элемент-родитель с “вид номенклатуры = услуга”, а элемент-отпрыск с “вид номенклатуры = товар”… Применил отбор “Вид номенклатуры = товар” – не видно ни элемента-родителя с “услугой”, ни элемента-отпрыска с “товар”… – вот такие вот интересные “тонкости”.
Полагаю, что наличие отбора в данном случае значения не имеет. Главное, что элемент вводится вне групп.
.
Все верно, отбор по-разному себя ведет в разных режимах просмотра.
Нет, тут вот как раз играет роль наличие установленного отбора. Если установленного отбора нет – то при вводе вне групп “данные заполнения = неопределено” и тогда для наследования вида номенклатуры достаточно одиночного условия на проверку =Тип(“Структура”): внутри групп родитель есть всегда (находимся внутри если и наследуем вид номенклатуры), а вне групп просто не сработает условие на =Тип “Структура” и наследования не будет (что и требовалось).
.
А вот как только есть установленный отбор – то и вне групп “данныезаполнения = структура” и тут уже нужно доп.условие на наличие в струткуре свойства “Родитель”.
.
вот такая вот “тонкость”…
Согласен.
пп.2-5, ок, спсб.
п.6, ок, получается, автогенерируемые формы по умолчанию всегда открываются модально и этого – не изменить… м.б. для управляемого приложения это и имеет смысл – незачем на тонких каналах кучу форм держать на экране…
п.7, спсб за подсказку как запретить. зачастую раскладка по группам бывает важна и нельзя допускать создание вне групп…
.
Вопрос в п.7 я сформулировал нечетко, повторю: как можно запретить пользователю менять режим просмотра списка (список/иерархия/дерево)?
п.6. Да, именно такие соображения и были у разработчиков.
п.7. Не совсем понял, почему не нравиться удалить из меню “Все действия” соответствующие пункты режима просмотра?
спсб. буду исследовать.. так как для меня вопросы чисто программистского характера, построения структуры данных – практически не актуальны, а большую “ценность” представляет исследование новых возможностей среды разработки – много всего понавертели – пока в голове не уляжется стройная логика конфигуратора чтобы на ходу “интуичить” где-что использовать/смотреть – вперед лично мне тяжело будет двигаться… да и реальных задач, на которых можно применить получаемые здесь знания – предвидится слабо.. пока все что узнал – никаких особых преимуществ в подавляющем классе задач (моих) перед 7.7 не дают…
.
спсб. пошел дальше учить.
Наблюдение #1. Really?? Попробуйте создать новый элемент вне группы. У вас свойство ДанныеЗаполнение будет равно Неопределено. И все попытке обратиться через точку приведут к ошибке.
Наблюдение #2. Для автогенерируемых форм – никак.
Для созданной формы списка можно зайти в свойства таблицы формы “Список”, найти “Состав команд” и снять флаг “Дерево”. Тогда соответствующая команда не будет отображаться.
Наблюдение #3. Если честно, в этом случае я тоже ожидал от платформы более адекватного поведения. Однако, что есть, то есть.
Наблюдение #4. Вообще-то должно срабатывать автомасштабирование. Но здесь нужно помнить если хоть раз вручную меняли размер, то платформа его запоминает.
Далее, если добавили табличную часть и вывели ее на форму – она будет не видна.
Замечание #5. Принимается замечание.
Наблюдение #6. Да, это лишь интерфейсный механизм.
набл.1, да, тут я чего-то “слажал”
набл.2, ок, это есть ответ на п.7
набл.3, подтверждаю, проверил еще один раз “с нуля” – так и есть…
набл.4-6, ок.
набл.3. Я тоже подтверждаю эту “особенность”.
ДЗ#6 выполнил. Особых проблем концептуального плана не было. Все понятно, что в какие формы, объекты, менеджеры помещать. основное время занимает попытка понять как именно надо делать с прицелом на будущее – потому как стратегической линии конфигурации озвучено не было.. Приходится делать упрощенно для скорости, потом, понимая что наверняка так вряд ли – подсмотреть – точно! так и есть и переделывать… ;-) с ТЧ на подчиненные справочники (ну и прочее абсолютно незначимое по мелочи…). Основная проблема – запрос по обработке контрагентов. Самостоятельно не осилил, пришлось пошагово повтрить за Учителем. Остальное все – вполне похоже и предсказуемо. Ряд впечатлений и попутных вопросов озвучено ниже…
Делаю ДЗ#6… Получается отвратительно… в первую очередь непонятно, после какой главы следует (рекомендовано) приступить к выполнению ДЗ. Также при обучении представляет определенное неудобство разбежка в нумерации слайдов в руководстве с нумерацией файлов… плохо все, короче говоря, пошел учить дальше…
Выполнено.
Сделал.
ДЗ №6 выполнено
Задание выполнено.
Выполнено
Задание выполнено.
Выполнено
Выполнено
Было сделано
Сделано
Сделано
Сделано.
Выполнил
Выполнено.
Намучался с контактными лицами, изначально хотел их делать в виде регистра сведений
Похоже, потихоньку втягиваюсь. Информацию о связке Контрагент-Конт. лицо-Должность решила хранить в регистре сведений. Это новый для меня вид хранения данных, пытаюсь осваивать. Задание №6 сделано.
Недостаток хранения этих данных в регистре сведений я уже описывал в этой ветке. Почитайте, будет полезно.
Да-да, после выполнения ДЗ почитала.
Выполнено.
Задание выполнил.
Выполнено. Единственное, что не понял, так это чем неудобно использовать табличную часть с контактными лицами вместо самостоятельного справочника. Какие могут быть проблемы при дальнейшем использовании этих данных в документах?
Нельзя однозначно сослаться на строку табличной части.
Например, нельзя создать реквизит документа, указывающий на это контактное лицо контрагента.
Можно, конечно, сделать таким образом:
1. Создать отдельный реквизит табличной части “СтрокаСсылка”,
2. Объявить ее типом “СправочникСсылка” и создать под это отдельный справочник
3. Программно заполнять перед записью объекта с табличной частью все незаполненные поля “СтрокаСсылка”, создавая под каждое поле новый элемент справочника.
4. Ссылаться на строку табличной части указанием ключа “Объект.Ссылка”+”СтрокаСсылка”.
Но таким образом мы будем по сути имитировать автоматическое поведение системы по созданию и контролю ссылочной целостности базы. А зачем городить огород?
Приведенный мною способ помог на одном из проектов для введения понятия “Рейс” в табличной части документа “Путевой лист”. Поскольку перестраивать архитектуру рабочей БД было крайне нежелательно, а ссылаться на строки требовалось (н-р, привязка доп. затрат к рейсам, отчет о рентабельности по рейсам) пришлось решить задачу таким “хитрым” способом…
Да, желательно, таких хитрых способов не использовать.
Также в описанном способе важно контролировать удаление строки табличной части. Ведь если на нее были ссылки, то удаление нужно запрещать.
Выполнил.
6-е домашнее задание выполнил. Особых проблем не возникло. Во время выполненения связал контактные лица с контрагентами через табличную часть, при просмотре решения понял почему был не прав.
Сделал. Были небольшие трудности с запросом, нужно было просто внимательно посмотреть ))), догадливости не хватило
Готово