Домашнее задание. Монетизация
05.09.2010
комментариев 58
Продолжаем тему монетизации.
Теперь необходимо выполнить домашнее задание, цель которого – разработать сервисный механизм.
К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте – залогиньтесь. Если Вы оплачивали курс, у Вас активирован токен доступа, Вы залогинены, но Вы видите эту запись – напишите нам на e-mail поддержки.
Задание выполнил (без усложненного варианта)
Готов усложненный вариант, кроме 3 пункта – не совсем понятно о чем реч..
Ну и инструкция – осталась, до завтра..
Готов 3 пункт и инструкция..
Задание решено, пока еще не в усложненном варианте.
Сделано. Без усложненного варианта, и пока само не очень нравится. В Выходные думаю улучшить
Сделал. Интересная вещь, обычно обходился заглушками в конкретном месте… Будем развиваться, думать на перспективу… если время будет ))
Сделано.
Ну почему же обязательно делать некрасиво?
Вот такой небольшой кусок кода решает даже усложненную задачу, когда нужно проверять соответствие реквизита шапки реквизиту таб. части:
Если ЗначениеЗаполнено (ВыборкаПравил.ТабличнаяЧастьВедущего) Тогда
ТабличнаяЧастьПравил = ВыборкаПравил.ТабличнаяЧастьВедущего;
ИначеЕсли ЗначениеЗаполнено(ВыборкаПравил.ТабличнаяЧастьЗависимого) Тогда
ТабличнаяЧастьПравил = ВыборкаПравил.ТабличнаяЧастьЗависимого;
Иначе
ТабличнаяЧастьПравил = “”;
КонецЕсли;
Запрос.Текст =
“ВЫБРАТЬ РАЗЛИЧНЫЕ
| Т.Ссылка КАК Документ
|ИЗ
| Документ.”+ВыборкаПравил.Документ+?(ТабличнаяЧастьПравил=””,””,”.”)+ТабличнаяЧастьПравил+” КАК Т
|ГДЕ
| Т.”+?(ТабличнаяЧастьПравил”” И ВыборкаПравил.ТабличнаяЧастьВедущего=””,”Ссылка.”,””)+ВыборкаПравил.ВедущийРеквизит+” В (&ДопустимыеЗначенияВедущего)
// для разрешающих правил перечисленные значения являются единственно допустимыми, поэтому условие проверки просто инвертируется
| И (“+?(ВыборкаПравил.ВидПравила = Перечисления.ВидыПравилЗаполнения.Разрешено, “НЕ”, “”)+” Т.”+?(ТабличнаяЧастьПравил”” И ВыборкаПравил.ТабличнаяЧастьЗависимого=””,”Ссылка.”,””)+ВыборкаПравил.ЗависимыйРеквизит+” В (&ДопустимыеЗначенияЗависимого))
| И Т.”+?(ТабличнаяЧастьПравил=””,””,”Ссылка.”)+”Дата МЕЖДУ &ДатаНачала И &ДатаОкончания
| И Т.”+?(ТабличнаяЧастьПравил=””,””,”Ссылка.”)+”Проведен”;
Запрос.УстановитьПараметр(“ДопустимыеЗначенияВедущего”, ВыборкаПравил.ЗначенияВедущего.ДопустимыеЗначения.ВыгрузитьКолонку(“Значение”) );
Запрос.УстановитьПараметр(“ДопустимыеЗначенияЗависимого”,
ВыборкаПравил.ЗначенияЗависимого.ДопустимыеЗначения.ВыгрузитьКолонку(“Значение”) );
ВыборкаДокументовСОшибками = Запрос.Выполнить().Выбрать();
Для понимания приведенного кода нужно сказать, что для решения усложенного варианта реквизит ТабличнаяЧасть был разделен на 2: ТабличнаяЧастьЗависимого и ТабличнаяЧастьВедущего. Проверка, чтобы они были равны (когда соотносятся реквизиты одной таб. части) или один незаполнен (когда шапка соотносится с таб. частью) происходит в ОбработкаПроверкиЗаполнения() модуля набора записей регистра правил. Т.е. недопустимы случаи, когда обе таб. части заданы и они различны.
Сделала. Немного не поняла с табличной частью. Зачем нужно измерение “табличная часть” если есть “ведущий и зависимый” реквизиты. Буду ждать решения Евгения, он, как всегда, расставит все по полочкам.
Табличная часть – для описания множества значений.
В справочнике то понятно, для чего табличная часть, а в регистре сведений то можно варьировать значения ведущий-зависимый (ведущий1-зависимый1, ведущий1-зависимый2 и т.д.)
Немного не так.
Будет требоваться описать несколько значений для пары ведущий1-зависимый1.
Например,
Контрагент-Склад: Алхимов – Главный склад
Контрагент-Склад: Алхимов – Склад №83
Но поскольку имена реквизитов являются изменениями, то система не позволит ввести 2 одинаковые записи. Поэтому и объединяем склады в табличную часть.
Теперь пришло понимание?
Вот ОНО – просветление… :) Но переделывать не буду, дождусь вашего решения. Спасибо!
Сделано, но несколько кривовато. А эталонное решение будет?
Будет, но позже
Сделано.
М.б. и не всё красиво, но работает.
Задание выполнено, хоть и под 8.1 для начала. :)
Чесслова, как-то раньше не задумывался об этакой универсализации подобного механизма. Согласованность реквизитов в основном прописывал через доп.реквизиты в необходимых справочниках и т.д.
Задание выполнено и в усложенном варианте.
1. Работа с метаданными проблем не составила, только надо учесть, что при изменении таб. части нужно сбросить реквизит и его значение, при изменении вида документа – таб. часть и т.д.
2. Оперативный контроль несколько видоизменил алгоритм проверки – нельзя просто применить запрос к ИБ, т.к. объект еще не записан.
3. Проверка согласованности реквизитов таб. части и шапки документа привела к необходимости разделить таб. часть ведущую и зависимую. Правила “разрешено” привели к интересному фокусу: теперь после обмена местами ведущего и зависимого реквизита результат проверки меняется :) Например не одно и до же “если Контрагент = Алхимов, тогда Номенклатура = Стул” и “если Номенклатура = Стул, тогда Контрагент = Алхимов”! В первом случае правило не допустит строк без стула, если в шапке указан Алхимов. Во втором – это допустимо :)
Готово
Решая задачу с требованиями повышенной сложности столкнулся с проблемой.
Список видов документов должен появляться при нажатии на кнопку выбора. Организую перебор метаданных для формирования списка видов документов в отдельной серверной неконтекстной процедуре, которой параметром передаю список выбора элемента формы. Список в процедуре наполняется без проблем. А при возврате из серверной процедуры на клиент пишет “Поле объекта недоступно для записи (СписокВыбора)
”
В чем проблема?
Список выбора все же составляет часть формы, поэтому во внеконтекстный вызов его никак нельзя..
Решения два:
1. Возвращать список значений с сервера, а потом присваивать его списку выбора.
2. Делать контекстный вызов.
Выполнено пока в базовом варианте (без заданий повышенного уровня сложности).
1. Алгоритм состоит из 2 запросов: по каждому правилу делается запрос к документам / таб. части документов нужного вида.
2. Поначалу тоже обрабатывал только запрещающие правила, пока Евгений не разъяснил как быть с разрешающими (см. комментарии ниже). Для разрешающих просто инвертируется условие проверки значения зависимого реквизита.
3. Текст запроса, отлавливающий неправильные документы, генерируется в цикле для каждого правила.
4. По примеру коллеги Boris добавил в регистр описание ошибки. Вывел его и в табличную часть на форме обработки. Теперь видно, на что ругается система при проверке. Очень удобно, когда много правил, тем более, когда в одном документе отлавливается более одной ошибки!
P.S. Для реквизита с типом ЛюбаяСсылка (как в справочнике допустимых значений) не получается указать пустое значение какого либо типа. Когда выбираешь тип, но отказываешься от выбора значения все равно в поле (и в ИБ) остается значение Неопределено. Фишка или глюк?
>Когда выбираешь тип, но отказываешься от выбора значения все равно в поле (и в ИБ) остается значение Неопределено. Фишка или глюк?
Фишка, причем документированная.
Кажется даже я об этом в 0-вом блоке упоминал.
Нашел урок 1-3 о типе данных Неопределено и урок 1-45 о типе ЛюбаяСсылка, но там ничего не сказано о том, что нельзя, как в 8.1 выбрать тип значения и не выбрать само значение и получить пустое значение нужного типа…
Т.е. теперь для реквизита сложного типа нельзя указать в качестве значения пустое значение определенного типа?
Пустое значение для составного типа данных – Неопределено.
Боюсь показаться назойливым, но я не о том спрашивал. Я спрашивал вот о чем.
В нашей задаче при описании правил, допустим, стоит задача описать такое правило: “если контрагент Алхимов, тогда подразделение должно быть пустым!”
Когда я при заполнении правила создаю элемент справочника “Допустимые значения реквизитов” и в табличной части пытаюсь прописать ПУСТОЕ ЗНАЧЕНИЕ типа СправочникСсылка.Подразделения, я не могу это сделать, т.к. при отказе от выбора значения система оставляет в поле значение Неопределено. А в 8.1 было пустое значение выбранного типа.
Т.е. теперь в системе 8.2 для реквизитов составного типа интерактивно нельзя установить пустое значение конкретного типа, даже если это требуется для решения прикладной задачи, так?
К сожалению, такого же поведения как в 8.1 не добиться.
Однако, вы можете записывать пустую ссылку программным образом, она будет храниться именно как пустая ссылка конкретного объекта (справочника, документа).
Выполнила. В обработке 2 запроса. В первом выбираются запрещающие правила из регистра сведений и допустимые значения из справочника, затем в цикле запрос по видам документов и наложением условий согласно тем правилам, которые выбрались в первом запросе. Документы с ошибками вывела в список в форме обработки. Одним запросом не смогла сделать. Хочется посмотреть решение Евгения. Подписки на события не делала.
Основная непонятка – разрешающие правила. В тексте ДЗ не сказано, какой порядок применения правил:
1) преобладают ли запрещения над разрешениями?
2) разрешено ли все, что явно не запрещено?
Если на (2) ответ положительный, тогда зачем нужны разрешающие правила? Какой смысл они несут?
Например, “такая-то связка значений реквизитов разрешена”. А если нет этого правила – такая связка тоже будет разрешена. Более того, она даже проверяться не будет, поскольку нет правила – нет и проверки. А значит механизм проверки будет работать быстрей…
1) Хороший вопрос. Я думаю он снимется, если “Вид правила” вынести в ресурсы.
2) Нет, не так. Если правило разрешающее, то оно описывает допустимые значения для указанных реквизитов.
Если правило запрещающее, то описываются недопустимые комбинации.
Т.е. если правило разрешающее, то оно описывает все возможные значения зависимого реквизита при условии, что ведущий реквизит по значению попадает в область действия правила, так?
Получается, что разрешающие правила говорят “можно только так и больше никак”, да?
Да, предполагалось такое поведение.
Выполнил через динамический запрос. В РС добавил реквизит ОписаниеОшибки , который выводится в обработке вместе с документом.
Динамический запрос? Это такой, текст которого конструируется в модуле?
ОписаниеОшибки – супер идея!
Сделал
Сделал, но без повышенного уровня пока. В обработке два запроса – одно по регистру сведений с итогами по Документу, обходим ПоГруппировкам, для каждого типа документа формируем запрос с отбором по периоду и в цикле проверяем условия. Для проверки задал, что для поставщика Альфа тип цены разрешен Оптовая. В документе задал Розничная и обработка это несоответствие выловила))). Документацию встроил в состав Справочной Информации регистра сведений, из обработки его можно открыть. Направление интересное – реализация бизнес-правил на уровне пользователя.
Сделал, но есть сомнение в оптимальности
Сделал в виде отдельной обработки и подписок на события.
В процессе выполнения задания осознал, что платформе катастрофически не хватает подписки на события форм, но судя по всему мы их никогда не дождемся
>но судя по всему мы их никогда не дождемся
Вода камень точит. Вот уже 4 года десятки внедренцев просят у разработчиков подписки на события форм, надежда остается..
Сделала, не оптимально.
Жду варианта Евгения.
Выполнил, правда с некоторыми допущениями.
В обработке проверки запросом вытягивал только данные по РС, а дальше уж обход по правилам. Понимаю, что не оптимально и неявный запрос в цикле получается (Документы[ИмяДокумента].Выбрать()), но сложновато собрать запрос сразу с таблицами документов, да еще и учитывая ТЧ.
Хотелось бы увидеть решение тренера.
ОK
Готово.
Я чтото пропустил? Решения нужно высылать?Если да, то куда высылать решения?
Нет, решения не нужно высылать.
Это еще не финальное ДЗ :)
>Напишите документацию к обработке о том, как настраивать и использовать правила. При
этом учтите, что документацией будут пользоваться реальные люди
Увы, сам не понял что сделал…
Печально…Может быть стоит еще раз прочитать первый абзац?
Возможен другой подход проверки. Я его выслал .
Создать справочник “Правила проверки объектов” , в котором в строке прописывать условия типа “Если Ссылка.ВидОперации = Перечисления.ВидыОпераций.ПрочиеПоступленияДенежныхСредств И Ссылка.РасшифровкаПлатежа = Параметр2 Тогда ЧтоТоНеТо= Истина КонецЕсли” (это для платежки)
В этом справочнике задавать перечень параметров и текст сообщения.
Для универсальности в периодическом регистре сведений “Действующие правила” указывать ссылку на этот справочник , роль для которой правило / ограничение игнорировать и признак, что оно действует.
Проверку правил задавать в подписке на событие “Перед записью” для всех объектов.
Да, Александр, это вариант.
Только вот саму проверку лучше делать в ОбработкеЗаполнения() т.к. она выполняется до начала транзакции.
Использование обработки мне нравится больше из-за того, что ее можно использовать без доработки остальных объектов и в типовой конфигурации.
Но ведь подписка на событие это тоже изменение конфигурации, не влияющее на процесс обновления.
Так что изменения делать можно, но грамотно..
Возможно. Пока эту тему не знаю.
Про подписку на события будет информация в продвинутом курсе, как я предполагаю.
Да, конечно, все нюансы подписок – в продвинутом.
Александр, ваш вариант мне тоже понравился, куда легче в реализации, чем описанный в задании.
Со справочником то конечно программисту проще…
Только попробуй объясни даже грамотному бухгалтеру что такое “Ссылка.ВидОперации = Перечисления.ВидыОпераций.ПрочиеПоступленияДенежныхСредств И Ссылка.РасшифровкаПлатежа = Параметр2″…
Имхо, такой вариант ничем не отличается от внесения кода в конфигуратор – каждый раз когда нужно будет что-либо добавить в перечень проверямых параметров придется вызывать программиста.
Конечно с точки зрения монетизации (увеличение числа обращений) это хорошо, но на грамотное решение проблемы имхо не тянет.
Зато есть плюс, не надо ждать вечера/ночи, чтобы прийти/удаленно внести изменения.
:) А так что мешает?
Структуру метаданных править не надо, только модуль – а значит можно работать на живой базе.
Не, ИМХО, все что я делаю должно быть понятно и работать без меня. И это мне дает моральное право просить за мою работу хорошие деньги.